[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id:
<168932102112.13275.16065030882031894328.git-patchwork-notify@kernel.org>
Date: Fri, 14 Jul 2023 07:50:21 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Daniel Golle <daniel@...rotopia.org>
Cc: netdev@...r.kernel.org, linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
nbd@....name, john@...ozen.org, sean.wang@...iatek.com,
Mark-MC.Lee@...iatek.com, lorenzo@...nel.org, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
matthias.bgg@...il.com, angelogioacchino.delregno@...labora.com,
igvtee@...il.com
Subject: Re: [PATCH] net: ethernet: mtk_eth_soc: handle probe deferral
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@...emloft.net>:
On Thu, 13 Jul 2023 03:42:29 +0100 you wrote:
> Move the call to of_get_ethdev_address to mtk_add_mac which is part of
> the probe function and can hence itself return -EPROBE_DEFER should
> of_get_ethdev_address return -EPROBE_DEFER. This allows us to entirely
> get rid of the mtk_init function.
>
> The problem of of_get_ethdev_address returning -EPROBE_DEFER surfaced
> in situations in which the NVMEM provider holding the MAC address has
> not yet be loaded at the time mtk_eth_soc is initially probed. In this
> case probing of mtk_eth_soc should be deferred instead of falling back
> to use a random MAC address, so once the NVMEM provider becomes
> available probing can be repeated.
>
> [...]
Here is the summary with links:
- net: ethernet: mtk_eth_soc: handle probe deferral
https://git.kernel.org/netdev/net/c/1d6d537dc55d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists