netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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);

  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).