devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Marc Zyngier <maz@kernel.org>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Martin Kaiser <martin@kaiser.cx>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Len Brown <lenb@kernel.org>
Cc: Saravana Kannan <saravanak@google.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-acpi@vger.kernel.org, kernel-team@android.com
Subject: [PATCH v2 0/3] Make fw_devlink=on more forgiving
Date: Mon,  1 Feb 2021 20:33:41 -0800	[thread overview]
Message-ID: <20210202043345.3778765-1-saravanak@google.com> (raw)

This patch series solves two general issues with fw_devlink=on

Patch 1/3 and 3/3 addresses the issue of firmware nodes that look like
they'll have struct devices created for them, but will never actually
have struct devices added for them. For example, DT nodes with a
compatible property that don't have devices added for them.

Patch 2/2 address (for static kernels) the issue of optional suppliers
that'll never have a driver registered for them. So, if the device could
have probed with fw_devlink=permissive with a static kernel, this patch
should allow those devices to probe with a fw_devlink=on. This doesn't
solve it for the case where modules are enabled because there's no way
to tell if a driver will never be registered or it's just about to be
registered. I have some other ideas for that, but it'll have to come
later thinking about it a bit.

Marek, Geert,

I don't expect v2 to do any better for your cases.

This series not making any difference for Marek is still a mystery to
me. I guess one of the consumers doesn't take too well to its probe (and
it's consumers' probe) being delayed till late_initcall(). I'll continue
looking into it.

Marc,

This v2 should do better than v1 with gpiolib stub driver reverted. I
forgot to take care of the case where more suppliers could link after I
went and deleted some of the links. v2 handles that now.

Tudor,

You should still make the clock driver fix (because it's a bug), but I
think this series will fix your issue too (even without the clock driver
fix). Can you please give this a shot?

Martin,

If you tested this series, can you please give a Tested-by?

Thanks,
Saravana

v1 -> v2:
Patch 1: Added a flag to fwnodes that aren't devices.
Patch 3: New patch to ise the flag set in patch 1 to not create bad links.

Saravana Kannan (3):
  driver core: fw_devlink: Detect supplier devices that will never be
    added
  driver core: fw_devlink: Handle missing drivers for optional suppliers
  of: property: Don't add links to absent suppliers

 drivers/base/base.h    |   2 +
 drivers/base/core.c    | 135 +++++++++++++++++++++++++++++++++++------
 drivers/base/dd.c      |   5 ++
 drivers/of/property.c  |   4 +-
 include/linux/fwnode.h |   2 +
 5 files changed, 127 insertions(+), 21 deletions(-)

-- 
2.30.0.365.g02bc693789-goog


             reply	other threads:[~2021-02-02  4:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02  4:33 Saravana Kannan [this message]
2021-02-02  4:33 ` [PATCH v2 1/3] driver core: fw_devlink: Detect supplier devices that will never be added Saravana Kannan
2021-02-02 14:12   ` Rafael J. Wysocki
2021-02-02 19:35     ` Saravana Kannan
2021-02-02  4:33 ` [PATCH v2 2/3] driver core: fw_devlink: Handle missing drivers for optional suppliers Saravana Kannan
2021-02-02 14:34   ` Rafael J. Wysocki
2021-02-02 19:46     ` Saravana Kannan
2021-02-04 18:41       ` Rafael J. Wysocki
2021-02-04 19:03         ` Saravana Kannan
2021-02-02  4:33 ` [PATCH v2 3/3] of: property: Don't add links to absent suppliers Saravana Kannan
2021-02-04 19:17   ` Saravana Kannan
2021-02-02 16:52 ` [PATCH v2 0/3] Make fw_devlink=on more forgiving Tudor.Ambarus
2021-02-02 17:41   ` Rob Herring
2021-02-02 18:28     ` Saravana Kannan
2021-02-02 21:22 ` Martin Kaiser
2021-02-02 22:43   ` Saravana Kannan
2021-02-03  7:54     ` Geert Uytterhoeven
2021-02-03  8:11       ` Saravana Kannan
2021-02-03  8:15         ` Geert Uytterhoeven
2021-02-03 22:02       ` Martin Kaiser
2021-02-03 21:57     ` Martin Kaiser
2021-02-03 22:03       ` Saravana Kannan

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=20210202043345.3778765-1-saravanak@google.com \
    --to=saravanak@google.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=lenb@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=martin@kaiser.cx \
    --cc=maz@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    /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).