From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D7ED630AAA9; Wed, 28 Jan 2026 20:50:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769633423; cv=none; b=QRwg0OqzxjGInbdc+IJzx3DA95kjKknAk7ILB7eBo9n9nbV7KRguXVOuqnT+cUunrGXE60Bf/gA0ihH+g/qEsHWXwYS6CwUXwJ1WoCFgMYU5py9iYUCmlayd7wJbDJtCz3SbPH/E+APM1c7EzAn6ukK9M6OpNv2Z/fcVTbKYvUY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769633423; c=relaxed/simple; bh=cX69s2o4o62ZvAs8fXmfN8sDkaWTmiMI+MiDnGzbd28=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o844KJgiEeQlCpDCdSpf3SkAPfkTQawKuch+j3e4Rtb832vUDdE6ZghkP1ih4MC9HS0PdhZWO5ycRC7YA5hO+gv4oKVR4Cs2eylv3Ss7ZupqipK9ScZCqSJKG+1Bm06xQAE3RJxSVl8ZI9ZKHtfozwahlYCjTiTSlQUxd148Rtg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CLQlIWub; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CLQlIWub" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D7B9C4CEF1; Wed, 28 Jan 2026 20:50:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769633423; bh=cX69s2o4o62ZvAs8fXmfN8sDkaWTmiMI+MiDnGzbd28=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CLQlIWubeB/tZOlihSrax7xkShRBHnwfcxFU4OBaOyVPjOzOqzjUGO036naQZHT35 MGAJMlUgLXVujeneiDcPG+LaI9ByNlFLcS5HIOQgqXwbHn6t4jnkbLyXQZT4mEMo6Z XdT3zSvLHoXtMiV/cIU6BBPQCWr7wusHMx4yNNAIP73FlJxY+x5vBTJjCQ8/42/Pfp u3WVlpxUAho677bcxUo/ItWEQ8s9NuJGRg7ZS0dIPyNjN1FZ7Q0XQTjZCBOHJeXOsA cpAkau1y+3pTzwsVkBqdR779vBextOLMsJ+yebClfa0lEvNTHdn8AJRseqf7uwt0/T bcHS4ko2JXaIg== Date: Wed, 28 Jan 2026 12:50:21 -0800 From: Drew Fustini To: Conor Dooley Cc: Icenowy Zheng , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Guo Ren , Fu Wei , Philipp Zabel , Dmitry Baryshkov , Michal Wilczynski , Luca Ceresoli , Han Gao , Yao Zi , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, Icenowy Zheng Subject: Re: [PATCH v6 1/9] dt-bindings: vendor-prefixes: add verisilicon Message-ID: References: <20260123092830.4046009-1-zhengxingda@iscas.ac.cn> <20260123092830.4046009-2-zhengxingda@iscas.ac.cn> <20260128-smokeless-angular-cff7e16ff8dc@spud> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="39FyjRiqT1aLZNV0" Content-Disposition: inline In-Reply-To: <20260128-smokeless-angular-cff7e16ff8dc@spud> --39FyjRiqT1aLZNV0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2026 at 08:42:11PM +0000, Conor Dooley wrote: > On Wed, Jan 28, 2026 at 12:22:40PM -0800, Drew Fustini wrote: > > On Fri, Jan 23, 2026 at 05:28:22PM +0800, Icenowy Zheng wrote: > > > From: Icenowy Zheng > > >=20 > > > VeriSilicon is a Silicon IP vendor, which is the current owner of > > > Vivante series video-related IPs and Hantro series video codec IPs. > > >=20 > > > Add a vendor prefix for this company. > > >=20 > > > Signed-off-by: Icenowy Zheng > > > Signed-off-by: Icenowy Zheng > > > Acked-by: Rob Herring (Arm) > > > --- > > > No changes since v4. > > >=20 > > > Changes in v3: > > > - Add Rob's ACK. > > >=20 > > > No changes in v2. > > >=20 > > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > > > 1 file changed, 2 insertions(+) > > >=20 > > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b= /Documentation/devicetree/bindings/vendor-prefixes.yaml > > > index c7591b2aec2a7..18f931f369198 100644 > > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > > @@ -1745,6 +1745,8 @@ patternProperties: > > > description: Variscite Ltd. > > > "^vdl,.*": > > > description: Van der Laan b.v. > > > + "^verisilicon,.*": > > > + description: VeriSilicon Microelectronics (Shanghai) Co., Ltd. > > > "^vertexcom,.*": > > > description: Vertexcom Technologies, Inc. > > > "^via,.*": > > > --=20 > > > 2.52.0 > > >=20 > >=20 > > I've applied the bindings patches (1, 2, 4) to thead-dt-for-next as well > > so that 'make W=3D1 dtbs_check' won't break for the next release of > > linux-next. > >=20 > > https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?= h=3Dthead-dt-for-next > >=20 > > I wouldn't normally pick bindings patches but it is a short timeline if > > we want to get some testing done in linux-next before sending v6.20 pull > > requests. I have created an immutable branch thead-dt-v6.20-dpu-hdmi in > > case that helps. > >=20 > > https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?= h=3Dthead-dt-v6.20-dpu-hdmi > >=20 > > I can drop the yaml patches from thead-dt-for-next if people think that > > was the wrong thing to do. If we think that the driver changes won't > > actually be ready for the merge window, then I can drop all these > > patches from thead-dt-for-next. >=20 > If you're taking the binding patches, it means the driver hasn't been > applied, and therefore there's not much reason to do something abnormal > like this? I'm not sure what the benefit of getting the dts patches > applied if the driver hasn't been accepted yet. >=20 > If this is only about linux-next, and the driver /is/ going to land in > v6.20 (or v7.0, w/e it ends up being), then the warnings don't warrant > doing something abnormal either, as long as whatever Linus ends up with > at -rc1 is clean. Okay, thanks for the guidance. I felt the urgency as I had the impression that Thomas Zimmermann might take those driver changes for the next merge window. I will drop the bindings patches from thead-dt-for-next right now. Are you saying it is okay to leave the dts patches in thead-dt-for-next even though that means next will have W=3D1 dtbs_check warning about undocumented compatible? Thanks, Drew --39FyjRiqT1aLZNV0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSy8G7QpEpV9aCf6Lbb7CzD2SixDAUCaXp2iAAKCRDb7CzD2Six DH1JAQCzvcGMBy9B4A47b6gXkVcbNsZzVI7DY0W0YDyZcS3zvgEA4W535byDQFen E4YKTUPt3ZHKwbQEu0qezexVhwj3cgY= =I5FU -----END PGP SIGNATURE----- --39FyjRiqT1aLZNV0--