Thread (24 messages) 24 messages, 8 authors, 2020-04-01

Re: [PATCH v2] ARM: imx: allow to disable board specific PHY fixups

From: Vladimir Oltean <olteanv@gmail.com>
Date: 2020-03-31 15:40:29
Also in: lkml, netdev

Hi Russell,

On Tue, 31 Mar 2020 at 18:15, Russell King - ARM Linux admin
[off-list ref] wrote:
On Tue, Mar 31, 2020 at 02:54:33PM +0200, Andrew Lunn wrote:
quoted
quoted
 - Disable the SmartEEE feature of the phy. The comment in the code implies
   that for some reason it doesn't work, but the reason itself is not given.
   Anyway, disabling SmartEEE should IMHO opinion be controlled by a DT
   setting. There is no reason to believe this problem is specific to the
   i.MX6. Besides, it is a feature of the phy, so it seems logical to expose
   that via the DT. Once that is done, it has no place here.
The device tree properties are defined:

bindings/net/ethernet-phy.yaml:  eee-broken-100tx:
bindings/net/ethernet-phy.yaml:  eee-broken-1000t:
bindings/net/ethernet-phy.yaml:  eee-broken-10gt:
bindings/net/ethernet-phy.yaml:  eee-broken-1000kx:
bindings/net/ethernet-phy.yaml:  eee-broken-10gkx4:
bindings/net/ethernet-phy.yaml:  eee-broken-10gkr:

And there is a helper:

void of_set_phy_eee_broken(struct phy_device *phydev)
Disabling the advertisement may solve it, but that is not known.
What the quirk is doing is disabling the SmartEEE feature only
(which is where the PHY handles the EEE so-called "transparently"
to the MAC).

It's all very well waving arms years later and saying we don't
like code that was merged, but unless someone can prove that an
alternative way is better and doesn't regress anything, there
won't be a way forward.
For what it's worth, your position on these device tree bindings for
broken EEE seems to have changed from the one that you expressed in
this thread:
https://www.spinics.net/lists/arm-kernel/msg703453.html
To quote from that:
quoted
There is no "advertisement of SmartEEE" - it's just EEE.  That is
because as far as the link partner is concerned, SmartEEE is just
EEE.
[...]

Otherwise, using the existing "eee-broken-*" properties to disable the
link modes where EEE fails would be the correct way forward, and should
be used in preference to disabling SmartEEE.

However, no one has mentioned what the problem that is trying to be
addressed.  Is it data corruption?  Is it that the link fails?  Is it
lost packets?  Is it that the MAC supports EEE?  I think there needs to
be some better understanding of the problem at hand before trying to
address it.
Regards,
-Vladimir

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help