[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200525084719.GJ1551@shell.armlinux.org.uk>
Date: Mon, 25 May 2020 09:47:19 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Nicolas Ferre <nicolas.ferre@...rochip.com>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>, f.fainelli@...il.com,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
antoine.tenart@...tlin.com, linux-kernel@...r.kernel.org,
harini.katakam@...inx.com,
Claudiu Beznea <claudiu.beznea@...rochip.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 1/5] net: macb: fix wakeup test in runtime
suspend/resume routines
On Mon, May 25, 2020 at 10:18:16AM +0200, Nicolas Ferre wrote:
> On 07/05/2020 at 12:03, Nicolas Ferre wrote:
> > On 06/05/2020 at 22:18, Jakub Kicinski wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > On Wed, 6 May 2020 13:37:37 +0200 nicolas.ferre@...rochip.com wrote:
> > > > From: Nicolas Ferre <nicolas.ferre@...rochip.com>
> > > >
> > > > Use the proper struct device pointer to check if the wakeup flag
> > > > and wakeup source are positioned.
> > > > Use the one passed by function call which is equivalent to
> > > > &bp->dev->dev.parent.
> > > >
> > > > It's preventing the trigger of a spurious interrupt in case the
> > > > Wake-on-Lan feature is used.
> > > >
> > > > Fixes: bc1109d04c39 ("net: macb: Add pm runtime support")
> > >
> > > Fixes tag: Fixes: bc1109d04c39 ("net: macb: Add pm runtime support")
> > > Has these problem(s):
> > > - Target SHA1 does not exist
> >
> > Indeed, it's:
> > Fixes: d54f89af6cc4 ("net: macb: Add pm runtime support")
> >
> > David: do I have to respin or you can modify it?
>
> David, all, I'm about to resend this series (alternative to "ping"),
> however:
>
> 1/ Now that it's late in the cycle, I'd like that you tell me if I rebase on
> net-next because it isn't not sensible to queue such (non urgeent) changes
> at rc7
>
> 2/ I didn't get answers from Russell and can't tell if there's a better way
> of handling underlying phylink error of phylink_ethtool_set_wol() in patch
> 3/5
I think you could have answered your own questions there, but I seemed
easier to send an email. I've just read the code, typed out an
appropriate description of the code's behaviour, and then derived the
answer to your questions without anything else.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
Powered by blists - more mailing lists