From nobody Mon May 25 00:08:41 2026 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FCCF30100E for ; Wed, 20 May 2026 08:44:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779266681; cv=none; b=euAM9Q1WLjUL60K7q+xt4nBWUsBJWl1FJW4RNfn58IrtQRUZtDie4SVcg/aD6DQuutCB9G01q75+4AUbFOJAuMjjhEWeeS0oNG/VknUhpAIRXMNP12mLcVLpJ0QjdGLOYJK+ElZGg4KW5ICbU6OHl5GEnF50pRHTrNiMzS6lPJM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779266681; c=relaxed/simple; bh=DYrzTa6rU2EWRZnyHhSY6UqODMxPKiCFlFwl6f+ux0I=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=EIu8h6kalhT3DoF0clsmX9FjMxvLgILq1aDObT/y3puVpoUffp3XO7OveconkgBB4xdgziK/VpZknsJGSJ+8ZWmf/j9mJOZ4VIR4amHhxK2ckzB59c7zPTYu/O+G+P3bzAD3G2dt3Oq5K5lBIHBMLskhC+ytO0lFPW1OhUzO1Vk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=DzLbInai; arc=none smtp.client-ip=209.85.215.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="DzLbInai" Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-c801912c903so2019162a12.0 for ; Wed, 20 May 2026 01:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1779266679; x=1779871479; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=iPyYWXdv68PW8J3G+OiAfrc+NQLll7mwxfwrGsqJTr8=; b=DzLbInaikLdTZ4nBHafxgB3CaDtaxXSd3OinYbLaflynani52H84XdPpIP007uKWwE +QBcd6BesICLrDHlP/a4cN1C+J+ctQJZLdzXvVB61qqn1Q4J/fAkiD3CtzQWxado13EB p4o/QS2xH+sLulfmFkzK1S5pdKTXBlxI1YtbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779266679; x=1779871479; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iPyYWXdv68PW8J3G+OiAfrc+NQLll7mwxfwrGsqJTr8=; b=DtDne09kfqI701mKzqj3UrcgSlhAFkZdaTBheI/kilV3mghUgEyHXtDqgwPML+k/BQ dCTnlSGJSoVLMLPsh0LH2HFj0LcuJ2Fzg5VOjhWXQ8GhS6rw3nZuHZ/ay3dNtT+7FpWn zENDhVKDWiGv/+H4hmuBoOfrG123vNUcAQZVV/6w0A+K7AM12OrOpV48j3QaHcmbmTgq d2RL6+EQQ2pdOeDovPTxCSzIKhuHFwrtfDXqMucKdI4RuMiS3t0wjsz1L0g/Xc9A2OnR ZPgjEWRXqeRGR0HiIi6xOmVi4Ej7dZ1viPH6B7OFieEEW0MVB/zMue1xZrRy15ryv+15 MiHQ== X-Forwarded-Encrypted: i=1; AFNElJ8SVVuqWgXuB6VVP6xdiEuoJfT7PywSTdJCF5/eaY+JPwI5S7iVwXlHlUiMd0EnznTNDQL+8JkO+PH+0ac=@vger.kernel.org X-Gm-Message-State: AOJu0YxcMW3fS9dgxz9926/ofmnNdjluUm3FHZWk2XmOOastdfvny2Io OsX1gtaq7I9SADlSIww2rB9p5cg+WLYCTsEPWKQ7D4RYgOQItITa9uAYZKzbK5Mrlg== X-Gm-Gg: Acq92OGHTjRYqmaJ/ilvYc6wqQnebEBV161KsaNxhHcFS2t1r+dsDAtuOS2lnuuU07B RMBBP7begAovsu+cqNjrXv8kPnwFxvzZtwUZK4faL3QLU4qmPU9ZZ/bKoh9yZHB4fOozGDfGReX D/W1H5M1zyq3TOPzBBYrciT3rP5OvfA4tzk4JsZ4me6w7SxjuJk9dbmTGMPHaniuNKehgYwu9VH n2yjmr4d8Czvx0+1QnpwPYbM6ecbiBf4ME77C56KjKvLqEm+obgu2utepStzCpsXcBLIz6sgY3r zKbU81lcs3nFisZzZi+Z6j1Q8nHSkkiQpUpHuseGsdJ7cGj9mARYZBE/A/8+r5m0x2A0T7xJLZS 1aqj6lN5plfUNTMacZkIt3hkkRUc/pH3NPXy5lixt7dQXvyvt+Df8N/z5yMjFTuneCJALpMzBrW M0Ul5MNCE2GSoi42+qMUUbxo2t2D7qWrYMcmyXtKC4sSDOUbPO92u5D4pIVI9NNgmddKH9vAQ6t rdccLCO X-Received: by 2002:a05:6a20:7491:b0:3a0:b781:4c8b with SMTP id adf61e73a8af0-3b22e815a20mr26839727637.2.1779266679541; Wed, 20 May 2026 01:44:39 -0700 (PDT) Received: from wenstp920.tpe.corp.google.com ([2a00:79e0:201d:8:a6d1:2ed3:6bfb:7704]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c82bb121ccasm18614959a12.29.2026.05.20.01.44.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 01:44:39 -0700 (PDT) From: Chen-Yu Tsai To: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andy Whitcroft , Joe Perches , Dwaipayan Ray , Lukas Bulwahn Cc: Chen-Yu Tsai , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Brian Norris , Yingying Tang Subject: [PATCH v2] checkpatch: Don't emit warnings for ID-base USB & PCI DT compatibles Date: Wed, 20 May 2026 16:44:27 +0800 Message-ID: <20260520084428.257066-1-wenst@chromium.org> X-Mailer: git-send-email 2.54.0.631.ge1b05301d1-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 =3D "..."'. 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 Reviewed-by: Brian Norris Tested-by: Brian Norris --- 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@chromiu= m.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 =3D $dt_path . "vendor-prefixes.yaml"; =20 foreach my $compat (@compats) { + # Skip ID-based PCI and USB compatible patterns. + # DT validation will check them properly. + next if $compat =3D~ /^pciclass,/; + next if $compat =3D~ /^pci[a-f0-9]{2,4},/; + next if $compat =3D~ /^usb(if)?[a-f0-9]{1,4},/; + my $compat2 =3D $compat; $compat2 =3D~ s/\,[a-zA-Z0-9]*\-/\,<\.\*>\-/; my $compat3 =3D $compat; --=20 2.54.0.631.ge1b05301d1-goog