[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YWAFP/Uf4LPK2oe6@Ansuel-xps.localdomain>
Date: Fri, 8 Oct 2021 10:45:51 +0200
From: Ansuel Smith <ansuelsmth@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Rob Herring <robh+dt@...nel.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net PATCH v2 01/15] drivers: net: phy: at803x: fix resume for
QCA8327 phy
On Thu, Oct 07, 2021 at 07:23:04PM -0700, Jakub Kicinski wrote:
> On Fri, 8 Oct 2021 02:22:11 +0200 Ansuel Smith wrote:
> > From Documentation phy resume triggers phy reset and restart
> > auto-negotiation. Add a dedicated function to wait reset to finish as
> > it was notice a regression where port sometime are not reliable after a
> > suspend/resume session. The reset wait logic is copied from phy_poll_reset.
> > Add dedicated suspend function to use genphy_suspend only with QCA8337
> > phy and set only additional debug settings for QCA8327. With more test
> > it was reported that QCA8327 doesn't proprely support this mode and
> > using this cause the unreliability of the switch ports, especially the
> > malfunction of the port0.
> >
> > Fixes: 52a6cdbe43a3 ("net: phy: at803x: add resume/suspend function to qca83xx phy")
>
> Strange, checkpatch catches the wrong hash being used, but the
> verify_fixes script doesn't. Did you mean:
>
> Fixes: 15b9df4ece17 ("net: phy: at803x: add resume/suspend function to qca83xx phy")
>
> Or is 52a6cdbe43a3 the correct commit hash? Same question for patch 2.
>
>
> The fixes have to be a _separate_ series.
Hi,
this series contains changes that depends on the fixes. (the 4th patch
that rename the define is based on this 2 patch) How to handle that?
I know it was wrong to put net and net-next patch in the same series but
I don't know how to handle this strange situation. Any hint about that?
About the wrong hash, yes I wrongly took the hash from my local branch.
--
Ansuel
Powered by blists - more mailing lists