[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200509073256.GZ1551@shell.armlinux.org.uk>
Date: Sat, 9 May 2020 08:32:56 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Matteo Croce <mcroce@...hat.com>,
David Miller <davem@...emloft.net>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net v2 0/2] Fix 88x3310 leaving power save mode
On Sat, May 09, 2020 at 08:36:31AM +0200, Greg Kroah-Hartman wrote:
> On Fri, May 08, 2020 at 10:38:16PM +0100, Russell King - ARM Linux admin wrote:
> > On Fri, May 08, 2020 at 11:32:39PM +0200, Matteo Croce wrote:
> > > On Wed, Apr 15, 2020 at 1:48 AM David Miller <davem@...emloft.net> wrote:
> > > >
> > > > From: Russell King - ARM Linux admin <linux@...linux.org.uk>
> > > > Date: Tue, 14 Apr 2020 20:47:53 +0100
> > > >
> > > > > This series fixes a problem with the 88x3310 PHY on Macchiatobin
> > > > > coming out of powersave mode noticed by Matteo Croce. It seems
> > > > > that certain PHY firmwares do not properly exit powersave mode,
> > > > > resulting in a fibre link not coming up.
> > > > >
> > > > > The solution appears to be to soft-reset the PHY after clearing
> > > > > the powersave bit.
> > > > >
> > > > > We add support for reporting the PHY firmware version to the kernel
> > > > > log, and use it to trigger this new behaviour if we have v0.3.x.x
> > > > > or more recent firmware on the PHY. This, however, is a guess as
> > > > > the firmware revision documentation does not mention this issue,
> > > > > and we know that v0.2.1.0 works without this fix but v0.3.3.0 and
> > > > > later does not.
> > > >
> > > > Series applied, thanks.
> > > >
> > >
> > > Hi,
> > >
> > > should we queue this to -stable?
> > > The 10 gbit ports don't work without this fix.
> >
> > It has a "Fixes:" tag, so it should be backported automatically.
>
> That is a wild guess that it might happen sometime in the future.
> Please use the cc: stable@ tag as is documented for the past 15+ years
> instead of relying on us to randomly notice a Fixes: tag.
Not for netdev material. Netdev has its own rules:
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
Q: I see a network patch and I think it should be backported to stable.
various stable releases?
A: Normally Greg Kroah-Hartman collects stable commits himself, but
for networking, Dave collects up patches he deems critical for the
networking subsystem, and then hands them off to Greg.
...
Q: I see a network patch and I think it should be backported to stable.
Should I request it via "stable@...r.kernel.org" like the references in
the kernel's Documentation/process/stable-kernel-rules.rst file say?
A: No, not for networking. Check the stable queues as per above 1st to see
if it is already queued. If not, then send a mail to netdev, listing
the upstream commit ID and why you think it should be a stable candidate.
...
Q: I have created a network patch and I think it should be backported to
stable. Should I add a "Cc: stable@...r.kernel.org" like the references
in the kernel's Documentation/ directory say?
A: No. See above answer. In short, if you think it really belongs in
stable, then ensure you write a decent commit log that describes who
gets impacted by the bugfix and how it manifests itself, and when the
bug was introduced. If you do that properly, then the commit will
get handled appropriately and most likely get put in the patchworks
stable queue if it really warrants it.
...
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
Powered by blists - more mailing lists