Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 31 May 2023 10:12:23 +0200
From:   Oleksij Rempel <o.rempel@pengutronix.de>
To:     Lukasz Majewski <lukma@denx.de>
Cc:     Andrew Lunn <andrew@lunn.ch>, Russell King <linux@armlinux.org.uk>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC] net: dsa: slave: Advertise correct EEE capabilities at
 slave PHY setup
Message-ID: <ZHcBZ5hGTu7aBCsJ@pengutronix.de>
References: <20230530122621.2142192-1-lukma@denx.de>
 <32aa2c0f-e284-4c5e-ba13-a2ea7783c202@lunn.ch>
 <20230530154039.4552e08a@wsk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230530154039.4552e08a@wsk>
Precedence: bulk

Hi Lukasz,

On Tue, May 30, 2023 at 03:40:39PM +0200, Lukasz Majewski wrote:
> Hi Andrew,
> 
> > On Tue, May 30, 2023 at 02:26:21PM +0200, Lukasz Majewski wrote:
> > > One can disable in device tree advertising of EEE capabilities of
> > > PHY when 'eee-broken-100tx' property is present in DTS.
> > > 
> > > With DSA switch it also may happen that one would need to disable
> > > EEE due to some network issues.  
> > 
> > Is EEE actually broken in the MAC/PHY combination?
> > 
> 
> Problem is that when I connect on this project some non-manageable
> switches (which by default have EEE enabled), then I observe very rare
> and sporadic link loss and reconnection.

The interesting question is, do other link partner or local system is
broken?
In some cases, not proper tx-timer was triggering this kind of
symptoms. And timer configuration may depend on the link speed. So,
driver may be need to take care of this.

> Disabling EEE solves the problem.
> 
> > You should not be using this DT option for configuration. It is there
> > because there is some hardware which is truly broken, and needs EEE
> > turned off.
> 
> Yes, I do think that the above sentence sums up my use case.

As Andrew already described, current linux kernel EEE support is not in
the best shape, it is hard to see the difference between broken HW and
SW.

> > If EEE does work, but you need to turn it off because of latency etc,
> > then please use ethtool.
> > 
> 
> Yes, correct - it is possible to disable the EEE with 
> 
> ethtool --set-eee lan2 eee off
> 
> However, as I've stated in the mail, I cannot re-enable EEE once
> disabled with:
> 
> ethtool --set-eee lan2 eee on
> 
> ethtool --show-eee lan2
> EEE Settings for lan2:
>         EEE status: not supported
> 
> 
> As the capability register shows value of 0.

Some PHYs indeed have this issues:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/micrel.c?h=v6.4-rc4#n1402

In case of your older kernel version, you will need to fake access to
the EEE caps register.

Regards,
Oleksij