Messages in this thread | | | Date | Mon, 26 Apr 2021 12:54:08 +0200 | From | Michael Walle <> | Subject | Re: [PATCH net-next v4 2/2] of: net: fix of_get_mac_addr_nvmem() for non-platform devices |
| |
Am 2021-04-16 17:19, schrieb Rob Herring: > On Fri, Apr 16, 2021 at 2:30 AM Michael Walle <michael@walle.cc> wrote: >> >> Am 2021-04-16 05:24, schrieb Benjamin Herrenschmidt: >> > On Mon, 2021-04-12 at 19:47 +0200, Michael Walle wrote: >> >> >> >> /** >> >> * of_get_phy_mode - Get phy mode for given device_node >> >> @@ -59,15 +60,39 @@ static int of_get_mac_addr(struct device_node *np, >> >> const char *name, u8 *addr) >> >> static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr) >> >> { >> >> struct platform_device *pdev = of_find_device_by_node(np); >> >> + struct nvmem_cell *cell; >> >> + const void *mac; >> >> + size_t len; >> >> int ret; >> >> >> >> - if (!pdev) >> >> - return -ENODEV; >> >> + /* Try lookup by device first, there might be a >> >> nvmem_cell_lookup >> >> + * associated with a given device. >> >> + */ >> >> + if (pdev) { >> >> + ret = nvmem_get_mac_address(&pdev->dev, addr); >> >> + put_device(&pdev->dev); >> >> + return ret; >> >> + } >> >> + >> > >> > This smells like the wrong band aid :) >> > >> > Any struct device can contain an OF node pointer these days. >> >> But not all nodes might have an associated device, see DSA for >> example. > > I believe what Ben is saying and what I said earlier is going from dev > -> OF node is right and OF node -> dev is wrong. If you only have an > OF node, then use an of_* function. > >> And as the name suggests of_get_mac_address() operates on a node. So >> if a driver calls of_get_mac_address() it should work on the node. >> What >> is wrong IMHO, is that the ethernet drivers where the corresponding >> board >> has a nvmem_cell_lookup registered is calling >> of_get_mac_address(node). >> It should rather call eth_get_mac_address(dev) in the first place. >> >> One would need to figure out if there is an actual device (with an >> assiciated of_node), then call eth_get_mac_address(dev) and if there >> isn't a device call of_get_mac_address(node). > > Yes, I think we're all in agreement. > >> But I don't know if that is easy to figure out. Well, one could start >> with just the device where nvmem_cell_lookup is used. Then we could >> drop the workaround above. > > Start with the ones just passing dev.of_node directly: > > $ git grep 'of_get_mac_address(.*of_node)'
[..]
Before I'll try to come up with a patch for this, I'd like to get your opinion on it.
(1) replacing of_get_mac_address(node) with eth_get_mac_address(dev) might sometimes lead to confusing comments like in drivers/net/ethernet/allwinner/sun4i-emac.c:
/* Read MAC-address from DT */ ret = of_get_mac_address(np, ndev->dev_addr);
Do we live with that or should the new name somehow reflect that it is taken from the device tree.
(2) What do you think of eth_get_mac_address(ndev). That is, the second argument is missing and ndev->dev_addr is used. I'm unsure about it. We'd still need a second function for drivers which don't write ndev->dev_addr directly, but have some custom logic in between. OTOH it would be like eth_hw_addr_random(ndev).
-michael
| |