lkml.org 
[lkml]   [2021]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2021-04-26 12:55    [W:0.077 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site