Message-ID: <559c1719-f45b-48ab-93ba-b4a103d84980@notapiano>
Date: Fri, 25 Oct 2024 16:44:08 -0400
From: Nícolas F. R. A. Prado <nfraprado@...labora.com>
To: Laura Nao <laura.nao@...labora.com>
Cc: dan.carpenter@...aro.org, anders.roxell@...aro.org,
	ben.copeland@...aro.org, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, naresh.kamboju@...aro.org,
	rafael@...nel.org
Subject: Re: [RFC] driver core: add a dbg printk for successful probes

On Fri, Oct 25, 2024 at 02:58:34PM +0200, Laura Nao wrote:
> Hi Dan,
> 
> On 10/24/24 16:54, Dan Carpenter wrote:
> > Hi Laura, and Nicolas,
> > 
> > I've been thinking about the driver probing talk you gave last year.  The
> > talk was about how tricky it is sometimes to determine which drivers have
> > probed successfully.  The drivers might be built into the kernel instead of
> > as a module, for example.  The idea was that we could make a list of
> > drivers we expected to probe successfully and find regressions in probe
> > that way.
> > 
> > Why couldn't we just add a printk in call_driver_probe() and then we could
> > pass
> > 
> > 	dd.dyndbg="func call_driver_probe +p"
> > 
> > at the kernel command line.
> >
> 
> Thanks for highlighting this.
> 
> This could be useful for debugging by making sysfs information more
> accessible and easier to parse, though it may not add significant value for
> automated testing.
> 
> 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.
> 
> Our approach with the DT[2] and ACPI[3] kselftests has been to avoid using
> external reference files where possible and instead rely on stable
> information already within the kernel. We use the device tree or ACPI
> tables as sources to identify which devices are present, then scrape sysfs
> to verify whether they’ve been successfully probed. Of course, this
> approach isn’t always feasible - some information isn’t exposed by the
> kernel, such as devices on discoverable buses, and reference files may be
> necessary to cover these cases.

And just to give more information on this note, to test the devices that aren't
covered by DT or ACPI:
* We've introduced the Discoverable Devices[4] kselftest, which targets devices
  on USB and PCI buses and requires describing those devices in a reference file
  beforehand;
* And more recently we've been proposing the Device Existence[5] kselftest that
  just needs to be run once to generate a reference automatically and has the
  broadest coverage, detecting all devices on the system, although in its
  current state it does not check for driver probe, only device presence.

We've also added a short documentation page[6] comparing those tests and a
couple others.

Since for these devices the need for a reference is unavoidable, the aim of the
tests is to try to encode the system information in the most stable way possible
to reduce maintenance and false-positives.

Thanks,
Nícolas

[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/devices/probe
[5] https://lore.kernel.org/all/20240928-kselftest-dev-exist-v2-1-fab07de6b80b@collabora.com/
[6] https://lore.kernel.org/all/20241001-kselftest-device-docs-v1-1-be28b70dd855@collabora.com

Powered by blists - more mailing lists