Devicetree
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Chen-Yu Tsai <wenst@chromium.org>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>,
	Dwaipayan Ray <dwaipayanray1@gmail.com>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yingying Tang <yingying.tang@oss.qualcomm.com>
Subject: Re: [PATCH v2] checkpatch: Don't emit warnings for ID-base USB & PCI DT compatibles
Date: Wed, 20 May 2026 15:26:49 -0700	[thread overview]
Message-ID: <ag41KWtNpU1ZZs6m@google.com> (raw)
In-Reply-To: <20260520084428.257066-1-wenst@chromium.org>

Hi Chen-Yu,

On Wed, May 20, 2026 at 04:44:27PM +0800, Chen-Yu Tsai wrote:
> The USB and PCI device bindings define some compatible patterns based
> on device IDs that use the comma to separate vendor and product IDs.
> 
> These prefix patterns include:
> 
>   - ^usb(if)?[0-9a-f]{1,4},
>   - ^pci[0-9a-f]{2,4},
>   - ^pciclass,
> 
> These are not real vendor prefixes. Don't emit warnings for them.
> Instead just skip over the DT compatible check altogether, and leave
> the real check to the DT validator. This avoids false positive warnings
> about undocumented DT vendor prefixes and compatibles.
> 
> Note that the script mostly only checks the first compatible string of
> each node, as it processes the source file line-by-line, and the check
> only matches on the line with 'compatible = "..."'. Otherwise there
> would be more warnings from arch/mips/boot/dts/loongson/ls7a-pch.dtsi
> since that file also includes compatibles like "pciclass0c0310" and
> "pciclass0c03" which are not accepted either.

Looking at IEEE Std 1275-1994 (PCI Bus Binding), you're right, that's
incorrect.

> "pci0014,7a24.0" is not
> valid either,

It's possible that's trying to follow the "pciVVVV,DDDD.RR" format
mentioned in the spec, although it's not clear if it should require 2
digits after the dot/period. Notably, the dt-schema does *not* include
the "dot" option at all, so maybe there's room for improvement.

Anyway, that just adds to why this is a good choice:

> but this patch leaves the real check to the DT validator.

> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v1:
> - Moved check earlier and match against full compatible string to avoid
>   false positives for undocumented compatibles as well
> - Added comma to patterns as they are now matched against the full
>   compatible string
> - Fixed patterns in commit message to just cover the prefix portion
> 
> This is a simplified version of what Brian Norris previously posted [1],
> but more comprehensive and more perl-y than what Yingying Tang posted
> [2], which only covered the second pattern.
> 
> This is based on next-20260519.
> 
> Also, odd observation: the other regex patterns in this script escape
> the comma ',', but AFAIK this is not needed.
> 
> [1] https://lore.kernel.org/all/20190223022440.146915-1-briannorris@chromium.org/
> [2] https://lore.kernel.org/all/20251210073812.1380803-1-yingying.tang@oss.qualcomm.com/
> ---
>  scripts/checkpatch.pl | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>

> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 0d18771f1b01..d4ee9d88ad07 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3783,6 +3783,12 @@ sub process {
>  			my $vp_file = $dt_path . "vendor-prefixes.yaml";
>  
>  			foreach my $compat (@compats) {
> +				# Skip ID-based PCI and USB compatible patterns.
> +				# DT validation will check them properly.
> +				next if $compat =~ /^pciclass,/;
> +				next if $compat =~ /^pci[a-f0-9]{2,4},/;
> +				next if $compat =~ /^usb(if)?[a-f0-9]{1,4},/;
> +
>  				my $compat2 = $compat;
>  				$compat2 =~ s/\,[a-zA-Z0-9]*\-/\,<\.\*>\-/;
>  				my $compat3 = $compat;
> -- 
> 2.54.0.631.ge1b05301d1-goog
> 

      reply	other threads:[~2026-05-20 22:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20  8:44 [PATCH v2] checkpatch: Don't emit warnings for ID-base USB & PCI DT compatibles Chen-Yu Tsai
2026-05-20 22:26 ` Brian Norris [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=ag41KWtNpU1ZZs6m@google.com \
    --to=briannorris@chromium.org \
    --cc=apw@canonical.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dwaipayanray1@gmail.com \
    --cc=joe@perches.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=robh@kernel.org \
    --cc=wenst@chromium.org \
    --cc=yingying.tang@oss.qualcomm.com \
    /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