-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Wednesday, January 29, 2020 5:34 PM
To: Madalin Bucur (OSS) <redacted>
Cc: Vladimir Oltean <olteanv@gmail.com>; Florian Fainelli
[off-list ref]; davem@davemloft.net; hkallweit1@gmail.com;
netdev@vger.kernel.org; ykaukab@suse.de; Russell King - ARM Linux admin
[off-list ref]
Subject: Re: [PATCH net-next 1/2] net: phy: aquantia: add rate_adaptation
indication

quoted

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

quoted

one supported on the system interface, do not prevent it by deleting

those

quoted

modes, as the dpaa_eth driver does now. Whether that link will be

successful

quoted

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