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-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20231123120942.33222-1-laura.nao@collabora.com>
Date:   Thu, 23 Nov 2023 13:09:42 +0100
From:   Laura Nao <laura.nao@...labora.com>
To:     dan.carpenter@...aro.org
Cc:     broonie@...nel.org, groeck@...omium.org, kernel@...labora.com,
        kernelci@...ts.linux.dev, laura.nao@...labora.com, lenb@...nel.org,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, rafael@...nel.org,
        robh+dt@...nel.org, shuah@...nel.org
Subject: Re: [RFC PATCH 0/2] Add a test to verify device probing on ACPI platforms

> Your talk was interesting at Linux Plumbers.
> 
> https://www.youtube.com/watch?v=oE73eVSyFXQ [time +2:35]
> 
> This is probably a stupid question, but why not just add something to
> call_driver_probe() which creates a sysfs directory tree with all the
> driver information?
> 

Thanks for the feedback! 

Improving the device driver model to publish driver and devices info was indeed another option we considered. We could have a debugfs entry storing this kind of information, similar to what devices_deferred does and in a standardized format. This would provide an interface that is easier to query at runtime for getting a list of devices that were probed correctly.
This would cover devices with a driver that's built into the kernel or as a module; in view of catching also those cases where a device is not probed because the relevant config is not enabled, I think we'd still need another way of building a list of devices present on the platform to be used as reference.

The solution proposed in this RFC follows the same approach used for dt
based platforms for simplicity. But if adding a new sysfs entry storing devices and driver info proves to be a viable option for upstream, we can surely explore it and improve the probe test to leverage that.

Best,

Laura

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ