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@xxxxxxxxxxxx>
> ---
> 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@xxxxxxxxxxxx/
> [2] https://lore.kernel.org/all/20251210073812.1380803-1-yingying.tang@xxxxxxxxxxxxxxxx/
> ---
>  scripts/checkpatch.pl | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Brian Norris <briannorris@xxxxxxxxxxxx>
Tested-by: Brian Norris <briannorris@xxxxxxxxxxxx>

> 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
>