[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20241030143045.24965-1-laura.nao@collabora.com>
Date: Wed, 30 Oct 2024 15:30:45 +0100
From: Laura Nao <laura.nao@...labora.com>
To: laura.nao@...labora.com,
dan.carpenter@...aro.org
Cc: anders.roxell@...aro.org,
ben.copeland@...aro.org,
gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org,
naresh.kamboju@...aro.org,
nfraprado@...labora.com,
rafael@...nel.org
Subject: Re: [RFC] driver core: add a dbg printk for successful probes
Hi all,
On 10/25/24 14:58, Laura Nao wrote:
> The main challenge with these tests is building a list of devices expected
> to be probed on a given platform, rather than knowing if a certain driver
> was probed. From our experience with KernelCI and bootrr[1], manually
> creating and maintaining such lists can become a high-maintenance task.
> Relying on kernel output with the suggested debug prints as a reference
> file would still require significant upkeep - generating, storing, and
> updating the reference for each platform over time. Additionally, there's a
> risk that some failures could go undetected, if for example a driver is
> missing from the kernel config at the time the reference is created or
> updated.
>
Building on this, what do you think about adding a sysfs attribute to
identify devices that aren’t meant to be probed by a driver?
I can think of a few cases, like class devices or devices not assigned to a
subsystem, but there are likely many more.
A recent example I encountered is with I2C adapters: while the device for
the I2C controller itself is expected to bind to a driver, the devices
created for each I2C bus segment are managed by the same driver but
don’t have a driver symlink in sysfs. From userspace, looking at all
devices in sysfs, it’s difficult to tell which ones represent actual
hardware and which are software abstractions managed by the same driver
but not directly probed. Having a specific sysfs attribute for these
cases would make it much easier to tell them apart.
Any thoughts on this?
Best,
Laura
Powered by blists - more mailing lists