[PATCH v2] checkpatch: Don't emit warnings for ID-base USB & PCI DT compatibles

[PATCH v2] checkpatch: Don't emit warnings for ID-base USB & PCI DT compatibles

[Chen-Yu Tsai]

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. "pci0014,7a24.0" is not
valid either, 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(+)

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

Re: [PATCH v2] checkpatch: Don't emit warnings for ID-base USB & PCI DT compatibles

[Brian Norris]

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
>