netdev - Re: [RFC PATCH v3 net-next 2/6] net: phylink: introduce a generic method for querying PHY in-band autoneg capability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210923095817.7s74g2fqkzqn6wgn@skbuf>
Date:   Thu, 23 Sep 2021 09:58:18 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Antoine Tenart <atenart@...nel.org>,
        Michael Walle <michael@...le.cc>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Maxim Kochetkov <fido_max@...ox.ru>,
        Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
        Steen Hegelund <steen.hegelund@...rochip.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "bcm-kernel-feedback-list@...adcom.com" 
        <bcm-kernel-feedback-list@...adcom.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>
Subject: Re: [RFC PATCH v3 net-next 2/6] net: phylink: introduce a generic
 method for querying PHY in-band autoneg capability

On Thu, Sep 23, 2021 at 09:19:21AM +0100, Russell King (Oracle) wrote:
> On Wed, Sep 22, 2021 at 11:50:34PM +0000, Vladimir Oltean wrote:
> > On Thu, Sep 23, 2021 at 12:03:22AM +0100, Russell King (Oracle) wrote:
> > > On Wed, Sep 22, 2021 at 09:48:28PM +0000, Vladimir Oltean wrote:
> > > > On Thu, Sep 23, 2021 at 12:31:16AM +0300, Vladimir Oltean wrote:
> > > > > On Wed, Sep 22, 2021 at 10:22:19PM +0100, Russell King (Oracle) wrote:
> > > > > > On Wed, Sep 22, 2021 at 09:14:42PM +0300, Vladimir Oltean wrote:
> > > > > > > +static unsigned int phylink_fixup_inband_aneg(struct phylink *pl,
> > > > > > > +					      struct phy_device *phy,
> > > > > > > +					      unsigned int mode)
> > > > > > > +{
> > > > > > > +	int ret;
> > > > > > > +
> > > > > > > +	ret = phy_validate_inband_aneg(phy, pl->link_interface);
> > > > > > > +	if (ret == PHY_INBAND_ANEG_UNKNOWN) {
> > > > > > > +		phylink_dbg(pl,
> > > > > > > +			    "PHY driver does not report in-band autoneg capability, assuming %s\n",
> > > > > > > +			    phylink_autoneg_inband(mode) ? "true" : "false");
> > > > > > > +
> > > > > > > +		return mode;
> > > > > > > +	}
> > > > > > > +
> > > > > > > +	if (phylink_autoneg_inband(mode) && !(ret & PHY_INBAND_ANEG_ON)) {
> > > > > > > +		phylink_err(pl,
> > > > > > > +			    "Requested in-band autoneg but driver does not support this, disabling it.\n");
> > > > > >
> > > > > > If we add support to the BCM84881 driver to work with
> > > > > > phy_validate_inband_aneg(), then this will always return
> > > > > > PHY_INBAND_ANEG_OFF and never PHY_INBAND_ANEG_ON. Consequently,
> > > > > > this will always produce this "error". It is not an error in the
> > > > > > SFP case, but it is if firmware is misconfigured.
> > > > > >
> > > > > > So, this needs better handling - we should not be issuing an error-
> > > > > > level kernel message for something that is "normal".
> > > > >
> > > > > Is this better?
> > > > >
> > > > > 		phylink_printk(phy_on_sfp(phy) ? KERN_DEBUG : KERN_ERR, pl,
> > > > > 			       "Requested in-band autoneg but driver does not support this, disabling it.\n");
> > > >
> > > > Ah, not sure whether that was a trick question or not, but
> > > > phylink_fixup_inband_aneg function does not get called for the SFP code
> > > > path, I even noted this in the commit message but forgot:
> > >
> > > No it wasn't a trick question. I thought you were calling
> > > phylink_fixup_inband_aneg() from phylink_sfp_config(), but I see now
> > > that you don't. That's what happens when you try and rush to review.
> >
> > How did I "rush to review" exactly? I waited for 24 days since the v2
> > for even a single review comment, with even a ping in between, before
> > resending the series largely unaltered, just with an extra patch appended.
>
> FFS. Are you intentionally trying to misinterpret everything I say?
> Who here is doing a review? You or me?
>
> "That's what happens when you try and rush to review." is a form of
> speech - clearly the "you" is not aimed at you Vladimir, but me.
> Let's put this a different way.
>
> I am blaming myself for rushing to review this last night.
>
> Is that more clear for you?

Apologies for misinterpreting, even though that was still the only
interpretation I could give that would make logical sense. Why would you
rush to review an RFC in the middle of the night if it wasn't me who was
rushing you, and pinging earlier? And why mention it in the first place?

Anyway... I will keep posting this as an RFC until you feel that all
corner cases are covered reasonably enough, including in-band autoneg
handling in MAC drivers. So there is no risk of it getting applied,
there is no need to rush to review.