[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90ebf1eb-89b9-3059-a6b8-87c197032e4c@gmail.com>
Date: Thu, 7 Oct 2021 11:12:48 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Ansuel Smith <ansuelsmth@...il.com>, Andrew Lunn <andrew@...n.ch>
Cc: Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH 09/13] net: dsa: qca8k: check rgmii also on port
6 if exchanged
On 10/7/21 6:31 AM, Ansuel Smith wrote:
> On Thu, Oct 07, 2021 at 02:24:08AM +0200, Andrew Lunn wrote:
>> On Thu, Oct 07, 2021 at 12:35:59AM +0200, Ansuel Smith wrote:
>>> Port 0 can be exchanged with port6. Handle this special case by also
>>> checking the port6 if present.
>>
>> This is messy.
>>
>> The DSA core has no idea the ports have been swapped, so the interface
>> names are going to be taken from DT unswaped. Now you appear to be
>> taking phy-mode from the other port in DT. That is inconsistent. All
>> the configuration for a port should come from the same place, nothing
>> gets swapped. Or everything needs to swap, which means you need to
>> change the DSA core.
>>
>> Andrew
>
> The swap is internal. So from the dts side we still use port0 as port0,
> it's just swapped internally in the switch.
> The change here is required as this scan the rgmii delay and sets the
> value to be set later in the phylink mac config.
> We currently assume that only one cpu port is supported and that can be
> sgmii or rgmii. This specific switch have 2 cpu port and we can have one
> config with cpu port0 set to sgmii and cpu port6 set to rgmii-id.
> This patch is to address this and to add the delay function to scan also
> for the secondary cpu port. (again the real value will be set in the mac
> config function)
> Honestly i think we should just rework this and move the delay logic
> directly in the mac_config function and scan there directly. What do you
> think? That way we should be able to generalize this and drop the extra
> if.
Agreed, the whole port swapping business is really hairy and seems like
it will led to unpleasant surprises down the road.
--
Florian
Powered by blists - more mailing lists