linux-kernel - [RFC PATCH v1] driver core: Set fw_devlink to "permissive" behavior by default

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: <20200321210305.28937-1-saravanak@google.com>
Date:   Sat, 21 Mar 2020 14:03:05 -0700
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>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        devicetree@...r.kernel.org, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org
Subject: [RFC PATCH v1] driver core: Set fw_devlink to "permissive" behavior
 by default

Set fw_devlink to "permissive" behavior by default so that device links
are automatically created (with DL_FLAG_SYNC_STATE_ONLY) by scanning the
firmware.

This ensures suppliers get their sync_state() calls only after all their
consumers have probed successfully. Without this, suppliers will get
their sync_state() calls at late_initcall_sync() even if their consuer

Ideally, we'd want to set fw_devlink to "on" or "rpm" by default. But
that needs more testing as it's known to break some corner case
drivers/platforms.

Cc: Rob Herring <robh+dt@...nel.org>
Cc: Frank Rowand <frowand.list@...il.com>
Cc: devicetree@...r.kernel.org
Signed-off-by: Saravana Kannan <saravanak@...gle.com>
---

I think it's time to soak test this and see if anything fails or if
anyone complains. Definitely not ready for 5.6. But pulling it in for
5.7 and having it go through all the rc testing would be helpful.

I'm sure there'll be reports where some DT properties are ambiguously
names and is breaking downstream or even some upstream platform. For
example, a DT property like "nr-gpios" would have a dmesg log about
parsing error because it looks like a valid "-gpios" DT binding. It'll
be good to catch those case and fix them.

Also, is there no way to look up current value of early_params? It'd be
nice if there was a way to do that.

-Saravana

 drivers/base/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 5e3cc1651c78..9fabf9749a06 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2345,7 +2345,7 @@ static int device_private_init(struct device *dev)
 	return 0;
 }

-static u32 fw_devlink_flags;
+static u32 fw_devlink_flags = DL_FLAG_SYNC_STATE_ONLY;
 static int __init fw_devlink_setup(char *arg)
 {
 	if (!arg)
-- 
2.25.1.696.g5e7596f4ac-goog