netdev - RE: [PATCH net-next 1/2] net: phy: aquantia: add rate

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 30 Jan 2020 09:40:22 +0000
From:   "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
To:     Andrew Lunn <andrew@...n.ch>,
        "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
CC:     Vladimir Oltean <olteanv@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ykaukab@...e.de" <ykaukab@...e.de>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
Subject: RE: [PATCH net-next 1/2] net: phy: aquantia: add rate_adaptation
 indication

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Wednesday, January 29, 2020 5:34 PM
> To: Madalin Bucur (OSS) <madalin.bucur@....nxp.com>
> Cc: Vladimir Oltean <olteanv@...il.com>; Florian Fainelli
> <f.fainelli@...il.com>; davem@...emloft.net; hkallweit1@...il.com;
> netdev@...r.kernel.org; ykaukab@...e.de; Russell King - ARM Linux admin
> <linux@...linux.org.uk>
> Subject: Re: [PATCH net-next 1/2] net: phy: aquantia: add rate_adaptation
> indication
> 
> > Nor do I need to know, my approach here is "non nocere", if there is a
> > chance for the PHY to link with the partner at a different speed than
> the
> > one supported on the system interface, do not prevent it by deleting
> those
> > modes, as the dpaa_eth driver does now. Whether that link will be
> successful
> > or not depends upon many variables and only some are related to rate
> adaptation.
> 
> We need to make it clear then that this bit being true just indicates
> that the device might perform rate adaptation, no guarantees, it might
> depend on firmware your board does not have, phase of the moon, etc.
> 
> I don't like this. Your board not working is your problem, you know
> the risks. But when somebody else starts using this bit, and it does
> not work, that is not so nice.

Indeed, it's of little use if you do not control your environment, this
hint (it's not more than that) can only go that far.

> Either:
> 
> We have documentary evidence that all Aquantia PHYs support this all
> the time.

There are reports that it can be disabled, so no.
 
> We add code to read registers to determine if the feature is enabled.
> 
> We add code to enable the feature.

I don't have a public document for this. If someone has it and can contribute
I'll be happy to make use of the new phy_rate_adaptation_active() api.

> You limit the scope of this to just your MAC driver. It can try to
> detect if an Aquantia phy is being used, phdev->drv can be used to
> detect this, and then you enable the extra link modes. Or add a device
> tree property, etc.
> 
> Thanks
> 	Andrew

Until someone gives me that API, I will run a check on the vendor bits in
phy_driver->phy_id and get over this.

Thanks,
Madalin