Received-SPF: pass (google.com: domain of linux-kernel+bounces-110195-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 21 Mar 2024 16:04:13 +0100
From: Greg KH <gregkh@linuxfoundation.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org,
	llvm@lists.linux.dev
Subject: Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
Message-ID: <2024032107-upstart-dragonfly-e346@gregkh>
References: <Zfwv2y7P7BneKqMZ@kroah.com>
 <20240321134831.GA2762840@dev-arch.thelio-3990X>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240321134831.GA2762840@dev-arch.thelio-3990X>

On Thu, Mar 21, 2024 at 06:48:31AM -0700, Nathan Chancellor wrote:
> On Thu, Mar 21, 2024 at 02:02:19PM +0100, Greg KH wrote:
> > All of these have been in linux-next for a long time with no reported
> > issue, other than a build warning with some older versions of gcc for a
> > speakup driver, fix for that will come in a few days when I catch up
> > with my pending patch queues.
> ...
> > Samuel Thibault (2):
> >       speakup: Fix 8bit characters from direct synth
> >       speakup: Add /dev/synthu device
> 
> That build warning actually happens with clang, not GCC as far as I am
> aware, and it is actually a hard build error with older versions of
> clang, as Arnd points out in his patch to fix this (although the warning
> is a hard error with CONFIG_WERROR too, which causes allmodconfig to
> break):
> 
> https://lore.kernel.org/20240313100413.875280-1-arnd@kernel.org/
> 
> Samuel's patch was even simpler:
> 
> https://lore.kernel.org/20240309203549.jj2l6epnznyjsrje@begin/
> 
> Why was one of these changes not applied before this was sent? I am
> aware you were on vacation recently but you are now adding a known issue
> to -rc1, which can proliferate to other maintainer's trees and makes
> testing for us more difficult :/

You answered it yourself here, I'm supposed to still be on vacation and
this came in while I was supposed to be ignoring emails, AND it works
fine for me here, which is why I didn't queue it up to my tree for
inclusion in this pull request.

And sorry for the confusion with gcc/clang, I got that mixed up.

> -next has been broken for the entire
> merge window over this, which is usually when there is a chance we can
> get maybe a week of green builds...

Stuff will always slip up at times, given the low-stakes of this, I
didn't think it was needed right now, again, because my local testing
was just fine.  I can go add it to the queue or if it affects Linus's
builds, he can take one of the above changes before I get a chance to
get through my todo mbox:

	$ mdfrm -c ~/mail/todo/
	1776 messages in /home/gregkh/mail/todo/

thanks,

greg "I need a vacation from my vacation..." k-h