Re: [PATCH 6.1 086/100] platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 4 Jan 2024, Greg Kroah-Hartman wrote:

> On Thu, Jan 04, 2024 at 07:02:52PM +0200, Ilpo Järvinen wrote:
> > On Thu, 4 Jan 2024, Shinichiro Kawasaki wrote:
> > 
> > > On Jan 04, 2024 / 09:58, Greg Kroah-Hartman wrote:
> > > > On Thu, Jan 04, 2024 at 08:54:48AM +0000, Shinichiro Kawasaki wrote:
> > > 
> > > ...
> > > 
> > > > > Greg, please drop this patch from 6.1-stable for now. Unfortunately, one issue
> > > > > has got reported [*].
> > > > > 
> > > > > [*] https://lore.kernel.org/platform-driver-x86/CABq1_vjfyp_B-f4LAL6pg394bP6nDFyvg110TOLHHb0x4aCPeg@xxxxxxxxxxxxxx/T/#u
> > > > 
> > > > What about 6.6.y, this is also queued up there too.
> > > 
> > > Please drop it from 6.6.y too.
> > > 
> > > > And when is this going to be reverted in Linus's tree?  6.7-rc8 has this
> > > > issue right now, right?
> > > 
> > > Yes. I agree that revert action is needed.
> > > 
> > > Ilpo,
> > > 
> > > As I commented to the response to the bug report, fix does not look straight
> > > forward to me. I guess fix discussion with x86 experts' will take some time
> > > (Andy is now away...). I will post a revert patch later. May I ask you to handle
> > > it?
> > 
> > I've applied the revert and made a PR out of it:
> > 
> > https://lore.kernel.org/platform-driver-x86/1a6657ef8475862e4fc282efe832fa86.=%3FUTF-8%3Fq%3FIlpo=20J=C3=A4rvinen%3F=%20%3Cilpo.jarvinen@xxxxxxxxxxxxxxx/T/#u
> > 
> > 
> > I found it a bit disappointing to hear from Greg that patches can no 
> > longer be dropped from stable-queue (it certainly used to be possible 
> > earlier) but things are to be handled indirectly through commits in Linus' 
> > tree.
> 
> They can be dropped, yes, but it's easier to add the follow-on revert so
> that all of the scripts out there don't keep resending the original
> change as part of the "hey, you missed this patch!" sweeps that people
> run.
> 
> So taking both of them is better, right?

If you want my honest answer, I don't think fix + revert "cycles" really 
belong there but I'm not going to complain that much either, I understand 
managing / keeping track of all that is not so easy (and that scripts 
tend to be stupid).

> That also ensures that Linus's tree is fixed up, which is key for 
> everyone involved.

Yes, it's important but my main worry here is it introduces latency and 
I've no knowledge if this kind of notes are enough to halt the stable 
release until the revert also makes into the stable-queue?

> For stuff that is "this should not be in the stable tree at all", we
> always drop those easily, that's never a problem.

Okay, thanks for the clarification.


-- 
 i.

[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux