linux-kernel - Re: [PATCH v6 3/9] drm: verisilicon: add a driver for Verisilicon display controllers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXo83Ob9LpeHd2SC@x1>
Date: Wed, 28 Jan 2026 08:44:12 -0800
From: Drew Fustini <fustini@...nel.org>
To: Icenowy Zheng <uwu@...nowy.me>
Cc: Thomas Zimmermann <tzimmermann@...e.de>,
	Andrzej Hajda <andrzej.hajda@...el.com>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Robert Foss <rfoss@...nel.org>,
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
	Jonas Karlman <jonas@...boo.se>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Guo Ren <guoren@...nel.org>,
	Fu Wei <wefu@...hat.com>, Philipp Zabel <p.zabel@...gutronix.de>,
	Dmitry Baryshkov <lumag@...nel.org>,
	Michal Wilczynski <m.wilczynski@...sung.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Han Gao <rabenda.cn@...il.com>, Yao Zi <ziyao@...root.org>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
	Han Gao <gaohan@...as.ac.cn>
Subject: Re: [PATCH v6 3/9] drm: verisilicon: add a driver for Verisilicon
 display controllers

On Thu, Jan 29, 2026 at 12:03:01AM +0800, Icenowy Zheng wrote:
> 在 2026-01-28星期三的 09:54 +0100，Thomas Zimmermann写道：
> > Hi
> > 
> > Am 28.01.26 um 09:39 schrieb Icenowy Zheng:
> > > 在 2026-01-28星期三的 08:58 +0100，Thomas Zimmermann写道：
> > > > Hi
> > > > 
> > > > Am 23.01.26 um 10:28 schrieb Icenowy Zheng:
> > > > > From: Icenowy Zheng <uwu@...nowy.me>
> > > > > 
> > > > > This is a from-scratch driver targeting Verisilicon DC-series
> > > > > display
> > > > > controllers, which feature self-identification functionality
> > > > > like
> > > > > their
> > > > > GC-series GPUs.
> > > > > 
> > > > > Only DC8200 is being supported now, and only the main
> > > > > framebuffer
> > > > > is set
> > > > > up (as the DRM primary plane). Support for more DC models and
> > > > > more
> > > > > features is my further targets.
> > > > > 
> > > > > As the display controller is delivered to SoC vendors as a
> > > > > whole
> > > > > part,
> > > > > this driver does not use component framework and extra bridges
> > > > > inside a
> > > > > SoC is expected to be implemented as dedicated bridges (this
> > > > > driver
> > > > > properly supports bridge chaining).
> > > > > 
> > > > > Signed-off-by: Icenowy Zheng <uwu@...nowy.me>
> > > > > Signed-off-by: Icenowy Zheng <zhengxingda@...as.ac.cn>
> > > > > Tested-by: Han Gao <gaohan@...as.ac.cn>
> > > > > Tested-by: Michal Wilczynski <m.wilczynski@...sung.com>
> > > > Reviewed-by: Thomas Zimmermann <tzimmermann@...e.de>
> > > > 
> > > > I only briefly looked over this revision, as v5 already seemed
> > > > quite
> > > > good. If you want to do a follow-up patch, see my other reply to
> > > > v5
> > > > on
> > > > storing hardware formats in the plane state.
> > > Well the kernel test robot found a small Kconfig problem in this
> > > revision -- DRM_DISPLAY_HELPER should be selected.
> > > 
> > > Maybe I'm going to send a v7 to address this.
> > > 
> > > Should I also make derived plane state a change in v7, or leave it
> > > as a
> > > follow-up?
> > 
> > That would require another round of review, I guess. Better leave it
> > for 
> > a separate series.
> > 
> > > 
> > > By the way, I think PATCH 1-5 should go through drm-misc tree, am I
> > > right? Who's going to pick it if going through drm-misc?
> > 
> > I can do that. In v7, you can merge patch 8 (MAINTAINERS) into patch
> > 3, 
> > so that it goes in as well.
> 
> Well then who should pick patch 9, the mailmap change?
> 
> I remember there is some tree for this kind of "trivial changes", but I
> forgot any detail about this.
> 
> > 
> > Patches 6 and 7 are small, so I can also take them into drm-misc if
> > they 
> > riscv maintainers are OK with that.
> 
> Well, I think there might be other TH1520 DT bits merged by Drew
> Fustini in this cycle?
> 
> Drew, can you read this? (I heard from Han Gao that his mail failed to
> get delivered to Drew). If you can read this, could you confirm that
> whether you want to merge DT patches?

Sorry for not giving a tag for the dts patches earlier. I'll do that
now. W=1 dtbs_check looks clean.

The dts patches should probably go through the thead-dt-for-next tree.
There were no other dts patches for the merge window so I had not
planned to send a thead-dt-for-next pull request for 6.20. Normally I
try to send the PR to Arnd by rc5.

I'm excited about this series so maybe there is still a possibility. If
the drivers changes are going into next now, then I could apply the dts
changes to thead-dt-for-next and ask the SoC maintainer team if it is
possible to accept a late dts PR. There is still the possibility of a
couple next releases before rc8 this weekend. The extra week for 6.19
might make this feasible.

Thanks,
Drew