From: Greg Ungerer <gerg@kernel.org>
To: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: phylink: require supported_interfaces to be filled
Date: Wed, 22 Nov 2023 00:19:38 +1000 [thread overview]
Message-ID: <13087238-6a57-439e-b7cb-b465b9e27cd6@kernel.org> (raw)
In-Reply-To: <E1q0K1u-006EIP-ET@rmk-PC.armlinux.org.uk>
Hi Russell,
On 20/5/23 20:41, Russell King (Oracle) wrote:
> We have been requiring the supported_interfaces bitmap to be filled in
> by MAC drivers that have a mac_select_pcs() method. Now that all MAC
> drivers fill in the supported_interfaces bitmap, it is time to enforce
> this. We have already required supported_interfaces to be set in order
> for optical SFPs to be configured in commit f81fa96d8a6c ("net: phylink:
> use phy_interface_t bitmaps for optical modules").
>
> Refuse phylink creation if supported_interfaces is empty, and remove
> code to deal with cases where this mask is empty.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> I believe what I've said above is indeed the case, but there is always
> the chance that something has been missed and this will cause breakage.
> I would post as RFC and ask for testing, but in my experience that is
> a complete waste of time as it doesn't result in any testing feedback.
> So, it's probably better to get it merged into net-next and then wait
> for any reports of breakage.
This commit breaks a platform I have with a Marvell 88e6350 switch.
During boot up it now fails with:
...
mv88e6085 d0072004.mdio-mii:11: switch 0x3710 detected: Marvell 88E6350, revision 2
mv88e6085 d0072004.mdio-mii:11: phylink: error: empty supported_interfaces
error creating PHYLINK: -22
mv88e6085: probe of d0072004.mdio-mii:11 failed with error -22
...
The 6350 looks to be similar to the 6352 in many respects, though it lacks
a SERDES interface, but it otherwise mostly seems compatible. Using the 6352
phylink_get_caps function instead of the 6185 one fixes this:
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -5418,7 +5418,7 @@ static const struct mv88e6xxx_ops mv88e6350_ops = {
.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
.stu_getnext = mv88e6352_g1_stu_getnext,
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
- .phylink_get_caps = mv88e6185_phylink_get_caps,
+ .phylink_get_caps = mv88e6352_phylink_get_caps,
};
static const struct mv88e6xxx_ops mv88e6351_ops = {
The story doesn't quite end here though. With this fix in place support
for the 6350 is then again broken by commit b92143d4420f ("net: dsa:
mv88e6xxx: add infrastructure for phylink_pcs"). This results in a dump
on boot up:
...
mv88e6085 d0072004.mdio-mii:11: switch 0x3710 detected: Marvell 88E6350, revision 2
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 8 Comm: kworker/u2:0 Not tainted 6.7.0-rc2-dirty #26
Hardware name: Marvell Armada 370/XP (Device Tree)
Workqueue: events_unbound deferred_probe_work_func
PC is at mv88e6xxx_port_setup+0x1c/0x44
LR is at dsa_port_devlink_setup+0x74/0x154
pc : [<c057ea24>] lr : [<c0819598>] psr: a0000013
sp : c184fce0 ip : c542b8f4 fp : 00000000
r10: 00000001 r9 : c542a540 r8 : c542bc00
r7 : c542b838 r6 : c5244580 r5 : 00000005 r4 : c5244580
r3 : 00000000 r2 : c542b840 r1 : 00000005 r0 : c1a02040
...
I can see that the mv88e6350_ops struct doesn't have an initializer for
pcs_ops. Based on the similarity with the 6352 again I tried using the
mv88e6352_pcs_ops for that:
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -5069,7 +5069,8 @@ static const struct mv88e6xxx_ops mv88e6350_ops = {
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
.stu_getnext = mv88e6352_g1_stu_getnext,
.stu_loadpurge = mv88e6352_g1_stu_loadpurge,
- .phylink_get_caps = mv88e6185_phylink_get_caps,
+ .phylink_get_caps = mv88e6352_phylink_get_caps,
+ .pcs_ops = &mv88e6352_pcs_ops,
};
This gets the 6350 switch back to working again (on current linux 6.7-rc2).
I am not entirely sure if this needs a dedicated phylink_get_caps
and pcs_ops for the 6350, or if it is safe to use the 6352 ones?
Looking at the mv88e6351_ops I am guessing it is going to suffer the
same problems too.
Regards
Greg
> drivers/net/phy/phylink.c | 26 +++++++++++---------------
> 1 file changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index a4dd5197355a..093b7b6e0263 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -712,14 +712,11 @@ static int phylink_validate(struct phylink *pl, unsigned long *supported,
> {
> const unsigned long *interfaces = pl->config->supported_interfaces;
>
> - if (!phy_interface_empty(interfaces)) {
> - if (state->interface == PHY_INTERFACE_MODE_NA)
> - return phylink_validate_mask(pl, supported, state,
> - interfaces);
> + if (state->interface == PHY_INTERFACE_MODE_NA)
> + return phylink_validate_mask(pl, supported, state, interfaces);
>
> - if (!test_bit(state->interface, interfaces))
> - return -EINVAL;
> - }
> + if (!test_bit(state->interface, interfaces))
> + return -EINVAL;
>
> return phylink_validate_mac_and_pcs(pl, supported, state);
> }
> @@ -1513,19 +1510,18 @@ struct phylink *phylink_create(struct phylink_config *config,
> struct phylink *pl;
> int ret;
>
> - if (mac_ops->mac_select_pcs &&
> - mac_ops->mac_select_pcs(config, PHY_INTERFACE_MODE_NA) !=
> - ERR_PTR(-EOPNOTSUPP))
> - using_mac_select_pcs = true;
> -
> /* Validate the supplied configuration */
> - if (using_mac_select_pcs &&
> - phy_interface_empty(config->supported_interfaces)) {
> + if (phy_interface_empty(config->supported_interfaces)) {
> dev_err(config->dev,
> - "phylink: error: empty supported_interfaces but mac_select_pcs() method present\n");
> + "phylink: error: empty supported_interfaces\n");
> return ERR_PTR(-EINVAL);
> }
>
> + if (mac_ops->mac_select_pcs &&
> + mac_ops->mac_select_pcs(config, PHY_INTERFACE_MODE_NA) !=
> + ERR_PTR(-EOPNOTSUPP))
> + using_mac_select_pcs = true;
> +
> pl = kzalloc(sizeof(*pl), GFP_KERNEL);
> if (!pl)
> return ERR_PTR(-ENOMEM);
next prev parent reply other threads:[~2023-11-21 14:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-20 10:41 [PATCH net-next] net: phylink: require supported_interfaces to be filled Russell King (Oracle)
2023-05-21 15:23 ` Andrew Lunn
2023-05-23 2:20 ` patchwork-bot+netdevbpf
2023-11-21 14:19 ` Greg Ungerer [this message]
2023-11-21 14:29 ` Andrew Lunn
2023-11-22 4:12 ` Greg Ungerer
2023-11-22 9:27 ` Russell King (Oracle)
2023-11-22 13:10 ` Greg Ungerer
2023-11-21 14:41 ` Russell King (Oracle)
2023-11-22 4:41 ` Greg Ungerer
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=13087238-6a57-439e-b7cb-b465b9e27cd6@kernel.org \
--to=gerg@kernel.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rmk+kernel@armlinux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).