From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Richard Cochran <richardcochran@gmail.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
paul.arola@telus.com, scott.roberts@telus.com
Subject: Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: enable support for 88E6361 switch
Date: Thu, 18 May 2023 11:11:03 +0200 [thread overview]
Message-ID: <ee281c0f-5e8b-8453-08bf-858c5503dc22@bootlin.com> (raw)
In-Reply-To: <9a836863-c279-490f-a49a-de4db5de9fd4@lunn.ch>
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@bootlin.com wrote:
>> From: Alexis Lothoré <alexis.lothore@bootlin.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
next prev parent reply other threads:[~2023-05-18 9:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 20:34 [PATCH net-next 0/2] net: dsa: mv88e6xxx: add 88E6361 support alexis.lothore
2023-05-17 20:34 ` [PATCH net-next 1/2] dt-bindings: net: dsa: marvell: add MV88E6361 switch to compatibility list alexis.lothore
2023-05-17 20:39 ` Andrew Lunn
2023-05-18 21:43 ` Conor Dooley
2023-08-24 18:49 ` airat.gl
2023-08-24 22:11 ` Andrew Lunn
2023-08-25 8:21 ` Alexis Lothoré
2023-05-17 20:34 ` [PATCH net-next 2/2] net: dsa: mv88e6xxx: enable support for 88E6361 switch alexis.lothore
2023-05-17 20:51 ` Andrew Lunn
2023-05-18 9:11 ` Alexis Lothoré [this message]
2023-05-18 12:58 ` Andrew Lunn
2023-05-19 12:38 ` Marek Behún
2023-05-19 13:16 ` Alexis Lothoré
2023-05-19 13:30 ` Andrew Lunn
2023-05-19 13:32 ` Marek Behún
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee281c0f-5e8b-8453-08bf-858c5503dc22@bootlin.com \
--to=alexis.lothore@bootlin.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=paul.arola@telus.com \
--cc=richardcochran@gmail.com \
--cc=scott.roberts@telus.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®