linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Saravana Kannan <saravanak@google.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Len Brown <lenb@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Vladimir Oltean <olteanv@gmail.com>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v3 2/3] driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD
Date: Tue, 21 Sep 2021 19:56:08 +0200	[thread overview]
Message-ID: <YUocuMM4/VKzNMXq@lunn.ch> (raw)
In-Reply-To: <CAJZ5v0jjvf6eeEKMtRJ-XP1QbOmjEWG=DmODbMhAFuemNn4rZg@mail.gmail.com>

> The existing code attempts to "enforce" device links where the
> supplier is a direct ancestor of the consumer (e.g. its parent), which
> is questionable by itself (why do that?)

In this case, we have an Ethernet switch as the parent device. It
registers an interrupt controller, to the interrupt subsystem. It also
registers an MDIO controller to the MDIO subsystem. The MDIO subsystem
finds the Ethernet PHYs on the MDIO bus, and registers the PHYs to the
PHY subsystem.

Device tree is then used to glue all the parts together. The PHY has
an interrupt output which is connected to the interrupt controller,
and a standard DT property is used to connect the two. The MACs in the
switch are connected to the PHYs, and standard DT properties are used
to connect them together. So we have a loop. But the driver model does
not have a problem with this, at least not until fw_devlink came
along. As soon as a resource is registered with a subsystem, it can be
used. Where as fw_devlink seems to assume a resource cannot be used
until the driver providing it completes probe.

Now, we could ignore all these subsystems, re-invent the wheels inside
the switch driver, and then not have suppliers and consumers at all,
it is all internal. But that seems like a bad idea, more wheels, more
bugs.

So for me, the real fix is that fw_devlink learns that resources are
available as soon as they are registered, not when the provider device
completes probe.

	  Andrew

  reply	other threads:[~2021-09-21 17:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 17:09 [PATCH v3 0/3] fw_devlink bug fixes Saravana Kannan
2021-09-15 17:09 ` [PATCH v3 1/3] driver core: fw_devlink: Improve handling of cyclic dependencies Saravana Kannan
2021-09-18 14:38   ` Rafael J. Wysocki
2021-09-15 17:09 ` [PATCH v3 2/3] driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD Saravana Kannan
2021-09-18 15:03   ` Rafael J. Wysocki
2021-09-19  1:16     ` Andrew Lunn
2021-09-19  6:41       ` Greg Kroah-Hartman
2021-09-21 16:15       ` Greg Kroah-Hartman
2021-09-21 16:35         ` Rafael J. Wysocki
2021-09-21 17:56           ` Andrew Lunn [this message]
2021-09-21 18:56             ` Rafael J. Wysocki
2021-09-21 19:50               ` Andrew Lunn
2021-09-21 20:07                 ` Saravana Kannan
2021-09-21 21:02                   ` Andrew Lunn
2021-09-21 21:54                     ` Saravana Kannan
2021-09-21 22:04                       ` Andrew Lunn
2021-09-21 22:26                         ` Saravana Kannan
2021-09-22  0:45                           ` Andrew Lunn
2021-09-22  1:00                             ` Saravana Kannan
2021-09-22 12:52                               ` Andrew Lunn
2021-09-23 12:48                   ` Rafael J. Wysocki
2021-09-15 17:09 ` [PATCH v3 3/3] net: mdiobus: Set FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for mdiobus parents Saravana Kannan
2021-09-23 17:30 ` [PATCH v3 0/3] fw_devlink bug fixes Greg Kroah-Hartman
2021-09-23 19:44   ` Vladimir Oltean
2021-09-24  6:09     ` Greg Kroah-Hartman
2021-09-23 22:28 ` Florian Fainelli

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=YUocuMM4/VKzNMXq@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=kernel-team@android.com \
    --cc=kuba@kernel.org \
    --cc=lenb@kernel.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=rafael@kernel.org \
    --cc=saravanak@google.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).