linux-kernel - [PATCH v1 0/5] Enable fw

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: <20201218031703.3053753-1-saravanak@google.com>
Date:   Thu, 17 Dec 2020 19:16:58 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Saravana Kannan <saravanak@...gle.com>, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org,
        Jisheng Zhang <Jisheng.Zhang@...aptics.com>,
        Kevin Hilman <khilman@...libre.com>,
        John Stultz <john.stultz@...aro.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Marc Zyngier <maz@...nel.org>
Subject: [PATCH v1 0/5] Enable fw_devlink=on by default

As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
be broken using logic was one of the last remaining reasons
fw_devlink=on couldn't be set by default.

This series changes fw_devlink so that when a cyclic dependency is found
in firmware, the links between those devices fallback to permissive mode
behavior. This way, the rest of the system still benefits from
fw_devlink, but the ambiguous cases fallback to permissive mode.

Setting fw_devlink=on by default brings a bunch of benefits (currently,
only for systems with device tree firmware):
* Significantly cuts down deferred probes.
* Device probe is effectively attempted in graph order.
* Makes it much easier to load drivers as modules without having to
  worry about functional dependencies between modules (depmod is still
  needed for symbol dependencies).

Greg/Rafael,

Can we get this pulled into 5.11-rc1 or -rc2 soon please? I expect to
see some issues due to device drivers that aren't following best
practices (they don't expose the device to driver core). Want to
identify those early on and try to have them fixed before 5.11 release.
See [1] for an example of such a case.

If we do end up have to revert anything, it'll just be Patch 5/5 (a one
liner).

Marc,

You had hit issues with fw_devlink=on before on some of your systems.
Want to give this a shot?

Jisheng,

Want to fix up one of those gpio drivers you were having problems with?

Thanks,
Saravana

[1] - https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com/

Cc: Jisheng Zhang <Jisheng.Zhang@...aptics.com>
Cc: Kevin Hilman <khilman@...libre.com>
Cc: John Stultz <john.stultz@...aro.org>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
Cc: Marc Zyngier <maz@...nel.org>

Saravana Kannan (5):
  driver core: Add debug logs for device link related probe deferrals
  driver core: Add device link support for INFERRED flag
  driver core: Have fw_devlink use DL_FLAG_INFERRED
  driver core: Handle cycles in device links created by fw_devlink
  driver core: Set fw_devlink=on by default

 drivers/base/core.c    | 101 +++++++++++++++++++++++++++++++++++------
 include/linux/device.h |   2 +
 2 files changed, 90 insertions(+), 13 deletions(-)

-- 
2.29.2.684.gfbc64c5ab5-goog