From: Icenowy Zheng <uwu@icenowy.me>

VeriSilicon is a Silicon IP vendor, which is the current owner of
Vivante series video-related IPs and Hantro series video codec IPs.

Add a vendor prefix for this company.

Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
No changes since v4.

Changes in v3:
- Add Rob's ACK.

No changes in v2.

 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

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,.*":
-- 
2.52.0

On Fri, Jan 23, 2026 at 05:28:22PM +0800, Icenowy Zheng wrote:
> From: Icenowy Zheng <uwu@icenowy.me>
> 
> VeriSilicon is a Silicon IP vendor, which is the current owner of
> Vivante series video-related IPs and Hantro series video codec IPs.
> 
> Add a vendor prefix for this company.
> 
> Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> No changes since v4.
> 
> Changes in v3:
> - Add Rob's ACK.
> 
> No changes in v2.
> 
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> 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,.*":
> -- 
> 2.52.0
> 

I've applied the bindings patches (1, 2, 4) to thead-dt-for-next as well
so that 'make W=1 dtbs_check' won't break for the next release of
linux-next.

https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?h=thead-dt-for-next

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.

https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?h=thead-dt-v6.20-dpu-hdmi

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.

Thanks,
Drew

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 <uwu@icenowy.me>
> > 
> > VeriSilicon is a Silicon IP vendor, which is the current owner of
> > Vivante series video-related IPs and Hantro series video codec IPs.
> > 
> > Add a vendor prefix for this company.
> > 
> > Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > Acked-by: Rob Herring (Arm) <robh@kernel.org>
> > ---
> > No changes since v4.
> > 
> > Changes in v3:
> > - Add Rob's ACK.
> > 
> > No changes in v2.
> > 
> >  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > 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,.*":
> > -- 
> > 2.52.0
> > 
> 
> I've applied the bindings patches (1, 2, 4) to thead-dt-for-next as well
> so that 'make W=1 dtbs_check' won't break for the next release of
> linux-next.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?h=thead-dt-for-next
> 
> 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.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?h=thead-dt-v6.20-dpu-hdmi
> 
> 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.

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.

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.

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 <uwu@icenowy.me>
> > > 
> > > VeriSilicon is a Silicon IP vendor, which is the current owner of
> > > Vivante series video-related IPs and Hantro series video codec IPs.
> > > 
> > > Add a vendor prefix for this company.
> > > 
> > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > Acked-by: Rob Herring (Arm) <robh@kernel.org>
> > > ---
> > > No changes since v4.
> > > 
> > > Changes in v3:
> > > - Add Rob's ACK.
> > > 
> > > No changes in v2.
> > > 
> > >  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > 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,.*":
> > > -- 
> > > 2.52.0
> > > 
> > 
> > I've applied the bindings patches (1, 2, 4) to thead-dt-for-next as well
> > so that 'make W=1 dtbs_check' won't break for the next release of
> > linux-next.
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?h=thead-dt-for-next
> > 
> > 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.
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux.git/log/?h=thead-dt-v6.20-dpu-hdmi
> > 
> > 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.
> 
> 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.
> 
> 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=1 dtbs_check warning about
undocumented compatible?

Thanks,
Drew

On Wed, Jan 28, 2026 at 12:50:21PM -0800, Drew Fustini wrote:

> Are you saying it is okay to leave the dts patches in thead-dt-for-next
> even though that means next will have W=1 dtbs_check warning about
> undocumented compatible?


fwiw, I was chatting to Drew on IRC last night after this mail so didn't
reply here.

On Thu, Jan 29, 2026 at 04:50:59PM +0000, Conor Dooley wrote:
> On Wed, Jan 28, 2026 at 12:50:21PM -0800, Drew Fustini wrote:
> 
> > Are you saying it is okay to leave the dts patches in thead-dt-for-next
> > even though that means next will have W=1 dtbs_check warning about
> > undocumented compatible?
> 
> 
> fwiw, I was chatting to Drew on IRC last night after this mail so didn't
> reply here.

Thanks for your guidance, Conor! I will wait for Thomas to confirm
regarding the yaml and driver patches before I create a pull request
for the 2 dts patches.

Drew