Re: [PATCH] checkpatch: Don't emit warnings for USB & PCI device DT compatible prefixes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The commit introduces a hardcoded bypass for `pciclass` based on a false premise, masking an underlying bug in checkpatch.pl.
- [Medium] The code implementation silently supports the `usbif` prefix, introducing a meaningful mismatch with the commit message.
--

commit 771fab4f035f631c7cd034c709f25afb0f1dc11b
Author: Chen-Yu Tsai <wenst@chromium.org>

checkpatch: Don't emit warnings for USB & PCI device DT compatible prefixes

The USB and PCI device bindings define some compatible patterns based
on device IDs that use the comma to separate vendor and product IDs.
This commit skips these prefixes when checking vendor prefixes in
checkpatch.pl.

>     These patterns include:
>     
>       - usb[0-9a-f]{1,4},[0-9a-f]{1,4}
>       - pci[0-9a-f]{2,4},[0-9a-f]{1,4}
>       - pciclass,[01][0-9a-f]{3}([0-9a-f]{2})?
>     
>     These are not real vendor prefixes. Don't emit warnings for them.

Is this description accurate regarding pciclass? The commit message assumes
pciclass is not a real vendor prefix. However, looking at
vendor-prefixes.yaml, it is actually defined as part of a grouped regex:

"^(pciclass|pinctrl-single|#pinctrl-single|PowerPC),.*": true

The reason the check fails in checkpatch.pl isn't because it is a fake prefix,
but because the grep command below uses a literal match:

grep -Eq "\"^\Q$vendor\E,\.*\":" $vp_file;

Does this workaround paper over the underlying issue with the grep
command not matching grouped regexes, which would also affect other valid
prefixes like pinctrl-single or exynos?

> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3727156e4ccad..ccedf152acfd7 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3795,6 +3795,9 @@ sub process {
>  
>  				next if $compat !~ /^([a-zA-Z0-9\-]+)\,/;
>  				my $vendor = $1;
> +				next if $vendor eq "pciclass";
> +				next if $vendor =~ /^pci[a-f0-9]{2,4}$/;
> +				next if $vendor =~ /^usb(if)?[a-f0-9]{1,4}$/;

The commit message explicitly lists usb[0-9a-f]{1,4},[0-9a-f]{1,4} as the
supported pattern for USB, but the implementation here silently supports the
usbif prefix as well.

While usbif is a valid prefix for USB interface bindings, could the commit
message be updated to reflect its undocumented inclusion in this regex?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514105151.2771474-1-wenst@chromium.org?part=1