linux-kernel - Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: enable support for 88E6361 switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee281c0f-5e8b-8453-08bf-858c5503dc22@bootlin.com>
Date:   Thu, 18 May 2023 11:11:03 +0200
From:   Alexis Lothoré <alexis.lothore@...tlin.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Richard Cochran <richardcochran@...il.com>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
        paul.arola@...us.com, scott.roberts@...us.com
Subject: Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: enable support for
 88E6361 switch

Hello Andrew, thanks for the prompt review !

On 5/17/23 22:51, Andrew Lunn wrote:
> On Wed, May 17, 2023 at 10:34:30PM +0200, alexis.lothore@...tlin.com wrote:
>> From: Alexis Lothoré <alexis.lothore@...tlin.com>
>>
>> Marvell 88E6361 is an 8-port switch derived from the
>> 88E6393X/88E9193X/88E6191X switches family. It can benefit from the
>> existing mv88e6xxx driver by simply adding the proper switch description in
>> the driver. Main differences with other switches from this
>> family are:
>> - 8 ports exposed (instead of 11): ports 1, 2 and 8 not available
>> - No 5GBase-x nor SFI/USXGMII support
> 
> So what exactly is supported for link modes?
> 
> The way you reuse the 6393 ops, are these differences actually
> enforced? It looks like mv88e6393x_phylink_get_caps() will allow
> 2500BaseX, 5GBaseX and 10GBaseR for port 10.

You are right, mv88e6393x_phylink_get_caps is currently too "generous" with
capabilities for 88E6361. With this chip, supported links modes are the following:
- port 0: MII, RMII, RGMII, 1000BaseX, 2500BaseX
- port 3 to 7: triple speed internal phys
- port 9 and 10: 1000BaseX, 25000BaseX
I'll add those specifications in cover letter for next revision for this series.
So indeed reported capabilities are wrong, I will update it. Taking a quick look
at other ops, I guess I'll have to fix some others too like
mv88e6393x_port_max_speed_mode
> 
>> +	[MV88E6361] = {
>> +		.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6361,
>> +		.family = MV88E6XXX_FAMILY_6393,
>> +		.name = "Marvell 88E6361",
>> +		.num_databases = 4096,
>> +		.num_macs = 16384,
>> +		.num_ports = 11,
>> +		/* Ports 1, 2 and 8 are not routed */
>> +		.invalid_port_mask = BIT(1) | BIT(2) | BIT(8),
>> +		.num_internal_phys = 5,
> 
> Which ports have internal PHYs? 2, 3, 4, 5, 6, 7 ?  What does
> mv88e6xxx_phy_is_internal() return for these ports, and
> mv88e6xxx_get_capsmv88e6xxx_get_caps()? I'm wondering if you actually
> need to list 8 here?

Indeed there is something wrong here too. I need to tune
mv88e6393x_phylink_get_caps to reflect 88E6361 differences.

As stated above, port 3 to 7 are the ones with internal PHY.
For mv88e6xxx_phy_is_internal, I see that it is merely comparing the port index
to the number of internal phys, so in this case it would advertise (wrongly)
that ports 0 to 4 have internal phys. I also see that your suggestion (setting
num_interal_phys to max internal phy index + 1) is already in use for this
family (6393X has 8 internal phys but defines num_internal_phys to 9), so if
it's acceptable I will do as you suggest and set it to 8.

Thanks,
Alexis

> 
>      Andrew

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com