mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Rosen Penev <rosenp@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com,
	linux@armlinux.org.uk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arch: arm: kirkwood: support nvmem mac address
Date: Tue, 1 Oct 2024 03:53:01 +0200	[thread overview]
Message-ID: <e729da5b-3964-4cdc-bdf4-2352be5b093e@lunn.ch> (raw)
In-Reply-To: <20240930215934.349238-1-rosenp@gmail.com>

On Mon, Sep 30, 2024 at 02:59:34PM -0700, Rosen Penev wrote:
> of_get_ethdev_address gets called too early for nvmem. If EPROBE_DEFER
> gets called, skip so that the ethernet driver can adjust the MAC address
> through nvmem.

Is this from code analysis or do you have a board with real issues? Do
we want to add a Fixed: so it gets back ported in stable?

> 
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  arch/arm/mach-mvebu/kirkwood.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
> index 73b2a86d6489..da347f66900b 100644
> --- a/arch/arm/mach-mvebu/kirkwood.c
> +++ b/arch/arm/mach-mvebu/kirkwood.c
> @@ -86,13 +86,18 @@ static void __init kirkwood_dt_eth_fixup(void)
>  		void __iomem *io;
>  		u8 *macaddr;
>  		u32 reg;
> +		int err;
>  
>  		if (!pnp)
>  			continue;
>  
> -		/* skip disabled nodes or nodes with valid MAC address*/
> -		if (!of_device_is_available(pnp) ||
> -		    !of_get_mac_address(np, tmpmac))
> +		/* skip disabled nodes */
> +		if (!of_device_is_available(pnp))
> +			goto eth_fixup_skip;
> +
> +		/* skip nodes with valid MAC address*/
> +		err = of_get_mac_address(np, tmpmac);
> +		if (err == -EPROBE_DEFER || !err)
>  			goto eth_fixup_skip;

I'm wondering about ordering here. What exactly does EPROBE_DEFER
mean? Does it mean we know there is a MAC address in nvmem, but the
nvmem has not probed yet? Or can it mean, the nvmem has not probed
yet, and maybe there is a MAC address in it, maybe not?

In the maybe not case, we should still be trying to read the MAC from
the hardware and storing it way safe for later use.

	Andrew

  reply	other threads:[~2024-10-01  1:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-30 21:59 Rosen Penev
2024-10-01  1:53 ` Andrew Lunn [this message]
2024-10-01  2:50   ` Rosen Penev
2024-10-01 13:20     ` Andrew Lunn

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=e729da5b-3964-4cdc-bdf4-2352be5b093e@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=gregory.clement@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rosenp@gmail.com \
    --cc=sebastian.hesselbarth@gmail.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®