netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcin Wojtas <mw@semihalf.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Sean Wang <sean.wang@mediatek.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Grzegorz Bernacki <gjb@semihalf.com>,
	Grzegorz Jaszczyk <jaz@semihalf.com>,
	Tomasz Nowicki <tn@semihalf.com>,
	Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>,
	upstream@semihalf.com
Subject: Re: [net-next: PATCH v3 6/8] net: core: switch to fwnode_find_net_device_by_node()
Date: Thu, 28 Jul 2022 08:47:58 +0200	[thread overview]
Message-ID: <CAPv3WKcc2i6HsraP3OSrFY0YiBOAHwBPxJUErg_0p7mpGjn3Ug@mail.gmail.com> (raw)
In-Reply-To: <20220727211112.kcpbxbql3tw5q5sx@skbuf>

śr., 27 lip 2022 o 23:11 Vladimir Oltean <olteanv@gmail.com> napisał(a):
>
> On Wed, Jul 27, 2022 at 07:40:00PM +0200, Marcin Wojtas wrote:
> > 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).
>
> Indeed, mvneta works, which is a plain old platform device that hasn't
> even been converted to fwnode, so why don't the others?
>
> Well, as it turns out, it's one of the cases where I spoke to soon,
> thinking I knew what was the problem why probing failed, before actually
> debugging.
>
> I thought there was no dmesg output from DSA at all, which would have
> indicated an eternal -EPROBE_DEFER situation. But there's one tiny line
> I had overlooked:
>
> [    5.094013] mscc_felix 0000:00:00.5: error -EINVAL: Failed to register DSA switch
>
> This comes from here:
>
> static int dsa_port_parse_fw(struct dsa_port *dp, struct fwnode_handle *fwnode)
> {
>         struct fwnode_handle *ethernet = fwnode_find_reference(fwnode, "ethernet", 0);
>         bool link = fwnode_property_present(fwnode, "link");
>         const char *name = NULL;
>         int ret;
>
>         ret = fwnode_property_read_string(fwnode, "label", &name);
> //      if (ret)
> //              return ret;
>
>         dp->fwnode = fwnode;
>
> The 'label' property of a port was optional, you've made it mandatory by accident.
> It is used only by DSA drivers that register using platform data.

Thanks for spotting that, I will make it optional again.

>
> (side note, I can't believe you actually have a 'label' property for the
> CPU port and how many people are in the same situation as you; you know
> it isn't used for anything, right? how do we stop the cargo cult?)
>

Well, given these results:
~/git/linux : git grep 'label = \"cpu\"' arch/arm/boot/dts/ | wc -l
79
~/git/linux : git grep 'label = \"cpu\"' arch/arm64/boot/dts/ | wc -l
14

It's not a surprise I also have it defined in the platforms I test. I
agree it doesn't serve any purpose in terms of creating the devices in
DSA with DT, but it IMO increases readability of the description at
least.

> > 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;
> >         }
> >
> >         return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(fwnode_find_parent_dev_match);
>
> So, nothing to do with device_match_fwnode() failing, that would have
> been strange, come to think about it. Sorry for the noise here.
>

Great, thank you for confirmation.

> But looking at the deeper implementation of dev_fwnode() as:
>
> struct fwnode_handle *dev_fwnode(struct device *dev)
> {
>         return IS_ENABLED(CONFIG_OF) && dev->of_node ?
>                 of_fwnode_handle(dev->of_node) : dev->fwnode;
> }
>
> I wonder, why did you have to modify mvpp2? It looks at dev->of_node
> prior to returning dev->fwnode. It should work.

When I boot with ACPI, the dev->of_node becomes NULL. With DT it's fine as-is.

Best regards,
Marcin

  parent reply	other threads:[~2022-07-28  6:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27  6:43 [net-next: PATCH v3 0/8] DSA: switch to fwnode_/device_ Marcin Wojtas
2022-07-27  6:43 ` [net-next: PATCH v3 1/8] net: phy: fixed_phy: switch to fwnode_ API Marcin Wojtas
2022-07-27 10:24   ` Andy Shevchenko
2022-07-27  6:43 ` [net-next: PATCH v3 2/8] net: mdio: switch fixed-link PHYs API to fwnode_ Marcin Wojtas
2022-07-27 10:28   ` Andy Shevchenko
2022-07-27  6:43 ` [net-next: PATCH v3 3/8] net: dsa: switch to device_/fwnode_ APIs Marcin Wojtas
2022-07-27 11:29   ` Andy Shevchenko
2022-07-27  6:43 ` [net-next: PATCH v3 4/8] net: mvpp2: initialize port fwnode pointer Marcin Wojtas
2022-07-27  6:43 ` [net-next: PATCH v3 5/8] device property: introduce fwnode_find_parent_dev_match Marcin Wojtas
2022-07-27 11:33   ` Andy Shevchenko
2022-07-27  6:43 ` [net-next: PATCH v3 6/8] net: core: switch to fwnode_find_net_device_by_node() Marcin Wojtas
2022-07-27 14:31   ` Vladimir Oltean
2022-07-27 15:18     ` Marcin Wojtas
2022-07-27 16:38       ` Vladimir Oltean
2022-07-27 17:40         ` Marcin Wojtas
2022-07-27 21:11           ` Vladimir Oltean
2022-07-27 21:27             ` Vladimir Oltean
2022-07-28  6:47             ` Marcin Wojtas [this message]
2022-07-28 19:56               ` Vladimir Oltean
2022-07-28 20:18                 ` Andrew Lunn
2022-07-28 21:23                   ` Marcin Wojtas
2022-07-28 22:20                     ` Andrew Lunn
2022-07-29  9:59                       ` Andy Shevchenko
     [not found]           ` <CAHp75VfGfKx1fggoE7wf4ndmUv4FEVfV=-EaO0ypescmNqDFkw@mail.gmail.com>
2022-07-28  6:52             ` Marcin Wojtas
2022-07-28  9:16               ` Vladimir Oltean
2022-07-28 16:56                 ` Marcin Wojtas
2022-07-28 19:16                   ` Vladimir Oltean
2022-07-28 19:49                     ` Marcin Wojtas
2022-07-27 17:00       ` Andy Shevchenko
2022-07-27 17:41         ` Marcin Wojtas
2022-07-27  6:43 ` [net-next: PATCH v3 7/8] net: mdio: introduce fwnode_mdiobus_register_device() Marcin Wojtas
2022-07-27 13:32   ` Andy Shevchenko
2022-07-27  6:43 ` [net-next: PATCH v3 8/8] net: dsa: mv88e6xxx: switch to device_/fwnode_ APIs Marcin Wojtas
2022-07-27 13:37   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPv3WKcc2i6HsraP3OSrFY0YiBOAHwBPxJUErg_0p7mpGjn3Ug@mail.gmail.com \
    --to=mw@semihalf.com \
    --cc=Landen.Chao@mediatek.com \
    --cc=Samer.El-Haj-Mahmoud@arm.com \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=gjb@semihalf.com \
    --cc=hkallweit1@gmail.com \
    --cc=jaz@semihalf.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    --cc=sean.wang@mediatek.com \
    --cc=tn@semihalf.com \
    --cc=upstream@semihalf.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).