[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200129153349.GB25384@lunn.ch>
Date: Wed, 29 Jan 2020 16:33:49 +0100
From: Andrew Lunn <andrew@...n.ch>
To: "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
> 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.
Either:
We have documentary evidence that all Aquantia PHYs support this all
the time.
We add code to read registers to determine if the feature is enabled.
We add code to enable the feature.
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
Powered by blists - more mailing lists