linux-kernel - [PATCH v1 0/2] Make fw_devlink=on more forgiving

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20210130040344.2807439-1-saravanak@google.com>
Date:   Fri, 29 Jan 2021 20:03:42 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Marc Zyngier <maz@...nel.org>,
        Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     Saravana Kannan <saravanak@...gle.com>,
        linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: [PATCH v1 0/2] Make fw_devlink=on more forgiving

This patch series solves two general issues with fw_devlink=on

Patch 1/2 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.

These two patches might remove the need for several other patches that
went in as fixes for commit e590474768f1 ("driver core: Set
fw_devlink=on by default"), but I think all those fixes are good
changes. So I think we should leave those in.

Marek, Geert,

Can you try this series on a static kernel with your OF_POPULATED
changes reverted? I just want to make sure these patches can identify
and fix those cases.

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?

Marc,

Can you try this series with the gpiolib fix reverted please? I'm pretty
sure this will fix that case.

Linus,

This series very likely removes the need for the gpiolib patch (we can
wait for Marc to confirm). I'm split on whether we should leave it in or
not. Thoughts?

Thanks,
Saravana

Saravana Kannan (2):
  driver core: fw_devlink: Detect supplier devices that will never be
    added
  driver core: fw_devlink: Handle missing drivers for optional suppliers

 drivers/base/base.h |   2 +
 drivers/base/core.c | 134 +++++++++++++++++++++++++++++++++++++-------
 drivers/base/dd.c   |   5 ++
 3 files changed, 121 insertions(+), 20 deletions(-)

-- 
2.30.0.365.g02bc693789-goog