2023-12-07 20:19:12

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH v3 3/3] kselftest: Add new test for detecting unprobed Devicetree devices

On Mon, Aug 28, 2023 at 05:13:12PM -0400, N?colas F. R. A. Prado wrote:
> Introduce a new kselftest to detect devices that were declared in the
> Devicetree, and are expected to be probed by a driver, but weren't.

I've been running this in my personal CI for a little while now and I'm
finding it's pretty marginal for the 45 second default timeout in
kselftest on some platforms, especially BeagleBone Black though it's not
just that. BBB is both slow and has a comprehensive DT which won't help
matters, there's 253 devices.

I'm running it from nfsroot which is going to be part of the problem but
shouldn't be too bad since we're mainly dealing with proc and sysfs and
hopefully mostly running cached binaries, I'm also using a serial
console to get the output which is going to add overhead especially with
a large number odevices with length names. I'm not sure what the best
solution is here - a quick glance at the code doesn't ring any alarm
bells for me, this may just be a reasonable runtime for the test.


Attachments:
(No filename) (1.01 kB)
signature.asc (499.00 B)
Download all attachments

2023-12-08 13:46:20

by Nícolas F. R. A. Prado

[permalink] [raw]
Subject: Re: [PATCH v3 3/3] kselftest: Add new test for detecting unprobed Devicetree devices

On Thu, Dec 07, 2023 at 08:18:49PM +0000, Mark Brown wrote:
> On Mon, Aug 28, 2023 at 05:13:12PM -0400, N?colas F. R. A. Prado wrote:
> > Introduce a new kselftest to detect devices that were declared in the
> > Devicetree, and are expected to be probed by a driver, but weren't.
>
> I've been running this in my personal CI for a little while now and I'm
> finding it's pretty marginal for the 45 second default timeout in
> kselftest on some platforms, especially BeagleBone Black though it's not
> just that. BBB is both slow and has a comprehensive DT which won't help
> matters, there's 253 devices.
>
> I'm running it from nfsroot which is going to be part of the problem but
> shouldn't be too bad since we're mainly dealing with proc and sysfs and
> hopefully mostly running cached binaries, I'm also using a serial
> console to get the output which is going to add overhead especially with
> a large number odevices with length names. I'm not sure what the best
> solution is here - a quick glance at the code doesn't ring any alarm
> bells for me, this may just be a reasonable runtime for the test.

Thanks for reporting this. I've experimented a bit and was able to find an
effective optimization and CC'ed it to you [1]. Hopefully it is as effective for
your board and setup as it is for mine. Let me know there.

[1] https://lore.kernel.org/all/[email protected]

Thanks,
N?colas