All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.