Message ID | 20210919115725.29064-1-chunkeey@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 029497e66bdc762e001880e4c85a91f35a54b1e2 |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [net,v2] net: bgmac-bcma: handle deferred probe error due to mac-address | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Clearly marked for net |
netdev/subject_prefix | success | Link |
netdev/cc_maintainers | fail | 2 blamed authors not CCed: nbd@nbd.name john@phrozen.org; 2 maintainers not CCed: nbd@nbd.name john@phrozen.org |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
netdev/header_inline | success | Link |
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Sun, 19 Sep 2021 13:57:25 +0200 you wrote: > Due to the inclusion of nvmem handling into the mac-address getter > function of_get_mac_address() by > commit d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") > it is now possible to get a -EPROBE_DEFER return code. Which did cause > bgmac to assign a random ethernet address. > > This exact issue happened on my Meraki MR32. The nvmem provider is > an EEPROM (at24c64) which gets instantiated once the module > driver is loaded... This happens once the filesystem becomes available. > > [...] Here is the summary with links: - [net,v2] net: bgmac-bcma: handle deferred probe error due to mac-address https://git.kernel.org/netdev/net/c/029497e66bdc You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c index 85fa0ab7201c..9513cfb5ba58 100644 --- a/drivers/net/ethernet/broadcom/bgmac-bcma.c +++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c @@ -129,6 +129,8 @@ static int bgmac_probe(struct bcma_device *core) bcma_set_drvdata(core, bgmac); err = of_get_mac_address(bgmac->dev->of_node, bgmac->net_dev->dev_addr); + if (err == -EPROBE_DEFER) + return err; /* If no MAC address assigned via device tree, check SPROM */ if (err) {
Due to the inclusion of nvmem handling into the mac-address getter function of_get_mac_address() by commit d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") it is now possible to get a -EPROBE_DEFER return code. Which did cause bgmac to assign a random ethernet address. This exact issue happened on my Meraki MR32. The nvmem provider is an EEPROM (at24c64) which gets instantiated once the module driver is loaded... This happens once the filesystem becomes available. With this patch, bgmac_probe() will propagate the -EPROBE_DEFER error. Then the driver subsystem will reschedule the probe at a later time. Cc: Petr Štetiar <ynezz@true.cz> Cc: Michael Walle <michael@walle.cc> Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") Signed-off-by: Christian Lamparter <chunkeey@gmail.com> --- changes: v1 -> v2: rewrote commit message based on net (commit 02319bf15ac) [Andrew Lunn] "net" tag [Andrew Lunn] added "CCs" of the previous authors in that area --- drivers/net/ethernet/broadcom/bgmac-bcma.c | 2 ++ 1 file changed, 2 insertions(+)