Thread (5 messages) 5 messages, 2 authors, 2022-07-28

Re: [net-next: PATCH v3 6/8] net: core: switch to fwnode_find_net_device_by_node()

From: Marcin Wojtas <hidden>
Date: 2022-07-28 06:52:24
Also in: linux-acpi, lkml

śr., 27 lip 2022 o 23:15 Andy Shevchenko [off-list ref] napisał(a):


On Wednesday, July 27, 2022, Marcin Wojtas [off-list ref] wrote:
quoted
śr., 27 lip 2022 o 18:38 Vladimir Oltean [off-list ref] napisał(a):
quoted
On Wed, Jul 27, 2022 at 05:18:16PM +0200, Marcin Wojtas wrote:
quoted
Do you mean a situation analogous to what I addressed in:
[net-next: PATCH v3 4/8] net: mvpp2: initialize port fwnode pointer
?
Not sure if "analogous" is the right word. My estimation is that the
overwhelmingly vast majority of DSA masters can be found by DSA simply
due to the SET_NETDEV_DEV() call that the Ethernet drivers need to make
anyway.  I see that mvpp2 also needed commit c4053ef32208 ("net: mvpp2:
initialize port of_node pointer"), but that isn't needed in general, and
I can't tell you exactly why it is needed there, I don't know enough
about the mvpp2 driver.
SET_NETDEV_DEV() fills net_device->dev.parent with &pdev->dev
and in most cases it is sufficient apparently it is sufficient for
fwnode_find_parent_dev_match (at least tests with mvneta case proves
it's fine).

We have some corner cases though:
* mvpp2 -> single controller can handle up to 3 net_devices and
therefore we need device_set_node() to make this work. I think dpaa2
is a similar case
* PCIE drivers with extra DT description (I think that's the case of enetc).
quoted
quoted
I found indeed a couple of drivers that may require a similar change
(e.g. dpaa2).
There I can tell you why the dpaa2-mac code mangles with net_dev->dev.of_node,
but I'd rather not go into an explanation that essentially doesn't matter.
The point is that you'd be mistaken to think that only the drivers which
touch the net device's ->dev->of_node are the ones that need updating
for your series to not cause regressions.
As above - SET_NETDEV_DEV() should be fine in most cases, but we can
never be 100% sure untils it's verified.
quoted
quoted
IMO we have 2 options:
- update these drivers
- add some kind of fallback? If yes, I am wondering about an elegant
solution - maybe add an extra check inside
fwnode_find_parent_dev_match?

What would you suggest?
Fixing fwnode_find_parent_dev_match(), of course.


Fixing how?!

quoted

This change broke DSA
quoted
on my LS1028A system (master in drivers/net/ethernet/freescale/enetc/)
and LS1021A (master in drivers/net/ethernet/freescale/gianfar.c).
Can you please check applying following diff:
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -695,20 +695,22 @@ EXPORT_SYMBOL_GPL(fwnode_get_nth_parent);
  * The routine can be used e.g. as a callback for class_find_device().
  *
  * Returns: %1 - match is found
  *          %0 - match not found
  */
 int fwnode_find_parent_dev_match(struct device *dev, const void *data)
 {
        for (; dev; dev = dev->parent) {
                if (device_match_fwnode(dev, data))
                        return 1;
+               else if (device_match_of_node(dev, to_of_node(data))
+                       return 1;
        }
This adds a piece of dead code. device_match_fwnode() covers this already.
Yes, indeed. After recent update, I think we can assume the current
implementation of fwnode_find_parent_dev_match should work fine with
all existing cases.

Thank you for all remarks and comments, I'll address them in v4 later today.

Best regards,
Marcin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help