mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Laura Nao <laura.nao@collabora.com>
To: laura.nao@collabora.com, dan.carpenter@linaro.org
Cc: anders.roxell@linaro.org, ben.copeland@linaro.org,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	naresh.kamboju@linaro.org, nfraprado@collabora.com,
	rafael@kernel.org
Subject: Re: [RFC] driver core: add a dbg printk for successful probes
Date: Wed, 30 Oct 2024 15:30:45 +0100	[thread overview]
Message-ID: <20241030143045.24965-1-laura.nao@collabora.com> (raw)
In-Reply-To: <20241025125834.19758-1-laura.nao@collabora.com>

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


      parent reply	other threads:[~2024-10-30 14:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-24 14:54 Dan Carpenter
2024-10-25 12:58 ` Laura Nao
2024-10-25 20:44   ` Nícolas F. R. A. Prado
2024-10-30 14:30   ` Laura Nao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241030143045.24965-1-laura.nao@collabora.com \
    --to=laura.nao@collabora.com \
    --cc=anders.roxell@linaro.org \
    --cc=ben.copeland@linaro.org \
    --cc=dan.carpenter@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=nfraprado@collabora.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®