From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Shuah Khan <shuah@kernel.org>
Cc: cocci@inria.fr, "Mark Brown" <broonie@kernel.org>,
"Nicolas Palix" <nicolas.palix@imag.fr>,
kernelci@lists.linux.dev, "Julia Lawall" <Julia.Lawall@inria.fr>,
"Bjorn Andersson" <andersson@kernel.org>,
kernel@collabora.com, "Guenter Roeck" <groeck@chromium.org>,
"Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: [RFC PATCH 0/2] Add a test to catch unprobed Devicetree devices
Date: Thu, 10 Aug 2023 16:23:49 -0400 [thread overview]
Message-ID: <20230810202413.1780286-1-nfraprado@collabora.com> (raw)
Regressions that cause a device to no longer be probed by a driver can
have a big impact on the platform's functionality, and despite being
relatively common there isn't currently any generic test to detect them.
As an example, bootrr [1] does test for device probe, but it requires
defining the expected probed devices for each platform.
Given that the Devicetree already provides a static description of
devices on the system, it is a good basis for building such a test on
top.
This series introduces a test to catch regressions that prevent devices
from probing.
Patch 1 introduces a script to parse the kernel source using Coccinelle
and extract all compatibles that can be matched by a Devicetree node to
a driver. Patch 2 adds a kselftest that walks over the Devicetree nodes
on the current platform and compares the compatibles to the ones on the
list, and on an ignore list, to point out devices that failed to be
probed.
A compatible list is needed because not all compatibles that can show up
in a Devicetree node can be used to match to a driver, for example the
code for that compatible might use "OF_DECLARE" type macros and avoid
the driver framework, or the node might be controlled by a driver that
was bound to a different node.
An ignore list is needed for the few cases where it's common for a
driver to match a device but not probe, like for the "simple-mfd"
compatible, where the driver only probes if that compatible is the
node's first compatible.
Even though there's already scripts/dtc/dt-extract-compatibles that does
a similar job, it didn't seem to find all compatibles, returning ~3k,
while Coccinelle found ~11k. Besides that, Coccinelle actually parses
the C files, so it should be a more robust solution than relying on
regexes.
The reason for parsing the kernel source instead of relying on
information exposed by the kernel at runtime (say, looking at modaliases
or introducing some other mechanism), is to be able to catch issues
where a config was renamed or a driver moved across configs, and the
.config used by the kernel not updated accordingly. We need to parse the
source to find all compatibles present in the kernel independent of the
current config being run.
Feedback is very much welcome.
Thanks,
Nícolas
[1] https://github.com/kernelci/bootrr
Nícolas F. R. A. Prado (2):
scripts/dtc: Add script to extract matchable DT compatibles
kselftest: Add Devicetree unprobed devices test
scripts/dtc/extract-matchable-dt-compatibles | 33 +++++++++++
scripts/dtc/matchable_dt_compatibles.cocci | 58 +++++++++++++++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/dt/.gitignore | 1 +
tools/testing/selftests/dt/Makefile | 17 ++++++
.../selftests/dt/compatible_ignore_list | 3 +
.../selftests/dt/test_unprobed_devices.sh | 58 +++++++++++++++++++
7 files changed, 171 insertions(+)
create mode 100755 scripts/dtc/extract-matchable-dt-compatibles
create mode 100644 scripts/dtc/matchable_dt_compatibles.cocci
create mode 100644 tools/testing/selftests/dt/.gitignore
create mode 100644 tools/testing/selftests/dt/Makefile
create mode 100644 tools/testing/selftests/dt/compatible_ignore_list
create mode 100755 tools/testing/selftests/dt/test_unprobed_devices.sh
--
2.41.0
next reply other threads:[~2023-08-10 20:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 20:23 Nícolas F. R. A. Prado [this message]
2023-08-10 20:23 ` [RFC PATCH 1/2] scripts/dtc: Add script to extract matchable DT compatibles Nícolas F. R. A. Prado
2023-08-10 21:43 ` [RFC PATCH 0/2] Add a test to catch unprobed Devicetree devices Rob Herring
2023-08-10 21:54 ` Rob Herring
2023-08-11 13:17 ` Nícolas F. R. A. Prado
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=20230810202413.1780286-1-nfraprado@collabora.com \
--to=nfraprado@collabora.com \
--cc=Julia.Lawall@inria.fr \
--cc=andersson@kernel.org \
--cc=broonie@kernel.org \
--cc=cocci@inria.fr \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=groeck@chromium.org \
--cc=kernel@collabora.com \
--cc=kernelci@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nicolas.palix@imag.fr \
--cc=robh+dt@kernel.org \
--cc=shuah@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;
as well as URLs for NNTP newsgroup(s).