Received-SPF: pass (google.com: domain of linux-kernel+bounces-42765-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <aec1ba8e-b609-4ec1-b6e2-8f850ab45c7f@linux.intel.com>
Date: Mon, 29 Jan 2024 21:11:53 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G
Content-Language: en-US
To: "Russell King (Oracle)" <linux@armlinux.org.uk>,
 Andrew Lunn <andrew@lunn.ch>
Cc: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
 David E Box <david.e.box@linux.intel.com>,
 Hans de Goede <hdegoede@redhat.com>, Mark Gross <markgross@kernel.org>,
 Jose Abreu <Jose.Abreu@synopsys.com>, Heiner Kallweit
 <hkallweit1@gmail.com>, "David S . Miller" <davem@davemloft.net>,
 Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>,
 Paolo Abeni <pabeni@redhat.com>, =?UTF-8?Q?Marek_Beh=C3=BAn?=
 <kabel@kernel.org>, Jean Delvare <jdelvare@suse.com>,
 Guenter Roeck <linux@roeck-us.net>,
 Giuseppe Cavallaro <peppe.cavallaro@st.com>,
 Alexandre Torgue <alexandre.torgue@foss.st.com>,
 Jose Abreu <joabreu@synopsys.com>,
 Maxime Coquelin <mcoquelin.stm32@gmail.com>,
 Richard Cochran <richardcochran@gmail.com>,
 Philipp Zabel <p.zabel@pengutronix.de>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>,
 Jesper Dangaard Brouer <hawk@kernel.org>,
 John Fastabend <john.fastabend@gmail.com>, Wong Vee Khee
 <veekhee@apple.com>, Jon Hunter <jonathanh@nvidia.com>,
 Jesse Brandeburg <jesse.brandeburg@intel.com>,
 Revanth Kumar Uppala <ruppala@nvidia.com>,
 Shenwei Wang <shenwei.wang@nxp.com>,
 Andrey Konovalov <andrey.konovalov@linaro.org>,
 Jochen Henneberg <jh@henneberg-systemdesign.com>, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
 linux-arm-kernel@lists.infradead.org, platform-driver-x86@vger.kernel.org,
 linux-hwmon@vger.kernel.org, bpf@vger.kernel.org,
 Voon Wei Feng <weifeng.voon@intel.com>,
 Tan Tee Min <tee.min.tan@linux.intel.com>,
 Michael Sit Wei Hong <michael.wei.hong.sit@intel.com>,
 Lai Peter Jun Ann <jun.ann.lai@intel.com>
References: <20230804084527.2082302-1-yong.liang.choong@linux.intel.com>
 <5bd05ba2-fd88-4e5c-baed-9971ff917484@lunn.ch>
 <f9b21a9d-4ae2-1f91-b621-2e27f746f661@linux.intel.com>
 <37fe9352-ec84-47b8-bb49-9441987ca1b9@lunn.ch>
 <ZQxPQ9t8/TKcjlo8@shell.armlinux.org.uk>
 <0098eaf3-717a-4b50-b2a0-4b28b75b0735@lunn.ch>
 <ZQxZVbmdcAN6UI2G@shell.armlinux.org.uk>
From: Choong Yong Liang <yong.liang.choong@linux.intel.com>
In-Reply-To: <ZQxZVbmdcAN6UI2G@shell.armlinux.org.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 21/9/2023 10:55 pm, Russell King (Oracle) wrote:
> On Thu, Sep 21, 2023 at 04:41:20PM +0200, Andrew Lunn wrote:
>> On Thu, Sep 21, 2023 at 03:12:19PM +0100, Russell King (Oracle) wrote:
>>> On Thu, Sep 21, 2023 at 03:21:00PM +0200, Andrew Lunn wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> After conducting a comprehensive study, it seems that implementing
>>>>> out-of-band for all link modes might not be feasible. I may have missed some
>>>>> key aspects during my analysis.
>>>>>
>>>>> Would you be open to sharing a high-level idea of how we could potentially
>>>>> make this feasible? Your insights would be greatly appreciated.
>>>>
>>>> stmmac_mac_link_up() gets passed interface, speed and duplex. That
>>>> tells you what the PHY has negotiated. Is there anything else you need
>>>> to know?
>>>
>>> The problem is... the stmmac driver is utter bollocks - that information
>>> is *not* passed to the BSP. Instead, stmmac parse and store information
>>> such as the PHY interface mode at initialisation time. BSPs also re-
>>> parse and store e.g. the PHY interface mode at initialisation time.
>>> The driver ignores what it gets from phylink.
>>>
>>> The driver is basically utter crap. That's an area I _had_ patches to
>>> clean up. I no longer do. stmmac is crap crap crap and will stay crap
>>> until they become more receptive to patches to fix it, even if the
>>> patches are not 100% to their liking but are in fact correct. Maybe
>>> if I ever decide to touch that driver in the future. Which I doubt
>>> given my recent experience.
>>
>> Hi Russell
>>
>> You pointed out the current proposal will break stuff. Do you see a
>> way forward for this patchset which does not first involve actually
>> cleaning up of this driver?
> 
> As I said in one of my replies, it would really help if the author can
> provide a table showing what is attempting to be achieved here. With
> that, we should be able to work out exactly what is required, what
> needs to change in stmmac, etc.
> 

Thank you, Russell and Andrew for the comments.

What I'm trying to achieve here is to enable interface mode switching 
between 2500basex and SGMII interfaces for Intel platforms.

I did based on the DM7052 SFP module and BCM84881 PHY to make the necessary 
changes in the new version of my patch series.

In the new patch series, the 'allow_switch_interface' flag was introduced, 
based on the 'allow_switch_interface' flag, the interface mode is 
configured to PHY_INTERFACE_MODE_NA within the 'phylink_validate_phy' 
function. This setting allows all ethtool link modes that are supported and 
advertised will be published. Then interface mode switching occurs based on
the selection of different link modes.

During the interface mode switching, the code will go through the 
`phylink_major_config` function and based on the interface mode to select 
PCS and PCS negotiation mode to configure PCS. Then, the MAC driver will 
perform SerDes configuration according to the interface mode.

I did rewrite the description for the new patch series, hoping that it is 
clear to describe the whole intention of the changes.