linux-kernel - Re: [PATCH v7 00/10] Add support for RK3588 DisplayPort Controller

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] [day] [month] [year] [list]

Message-ID: <3ygqnj4idey7u4m7ltlv7pnfhkkvcepmpfdijdszctaeopq3ky@qteg33comjl3>
Date: Tue, 2 Sep 2025 19:07:25 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Thomas Zimmermann <tzimmermann@...e.de>, Andy Yan <andyshrk@....com>, 
	heiko@...ech.de, hjc@...k-chips.com, naoki@...xa.com, stephen@...xa.com, 
	cristian.ciocaltea@...labora.com, neil.armstrong@...aro.org, Laurent.pinchart@...asonboard.com, 
	yubing.zhang@...k-chips.com, krzk+dt@...nel.org, devicetree@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org, robh@...nel.org, 
	sebastian.reichel@...labora.com, Andy Yan <andy.yan@...k-chips.com>
Subject: Re: [PATCH v7 00/10] Add support for RK3588 DisplayPort Controller

On Thu, Aug 28, 2025 at 03:56:21PM +0300, Dmitry Baryshkov wrote:
> On Thu, Aug 28, 2025 at 10:05:28AM +0200, Maxime Ripard wrote:
> > On Thu, Aug 28, 2025 at 09:50:34AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > > 
> > > Am 28.08.25 um 00:24 schrieb Dmitry Baryshkov:
> > > > On Fri, Aug 22, 2025 at 02:39:44PM +0800, Andy Yan wrote:
> > > > > From: Andy Yan <andy.yan@...k-chips.com>
> > > > > 
> > > > > 
> > > > > There are two DW DPTX based DisplayPort Controller on rk3588 which
> > > > > are compliant with the DisplayPort Specification Version 1.4 with
> > > > > the following features:
> > > > > 
> > > > > * DisplayPort 1.4a
> > > > > * Main Link: 1/2/4 lanes
> > > > > * Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and 8.1Gbps
> > > > > * AUX channel 1Mbps
> > > > > * Single Stream Transport(SST)
> > > > > * Multistream Transport (MST)
> > > > > * Type-C support (alternate mode)
> > > > > * HDCP 2.2, HDCP 1.3
> > > > > * Supports up to 8/10 bits per color component
> > > > > * Supports RBG, YCbCr4:4:4, YCbCr4:2:2, YCbCr4:2:0
> > > > > * Pixel clock up to 594MHz
> > > > > * I2S, SPDIF audio interface
> > > > > 
> > > > > The current version of this patch series only supports basic display outputs.
> > > > > I conducted tests with DP0 in 1080p and 4K@60 YCbCr4:2:0 modes; the ALT/Type-C
> > > > > mode was tested on Rock 5B, DP1 was tested on Rock 5 ITX by Stephen and Piotr.
> > > > > HDCP and audio features remain unimplemented.
> > > > > For RK3588, it's only support SST, while in the upcoming RK3576, it can support
> > > > > MST output.
> > > > > 
> > > > [skipped changelog]
> > > > 
> > > > > Andy Yan (10):
> > > > >    dt-bindings: display: rockchip: Add schema for RK3588 DPTX Controller
> > > > >    drm/bridge: synopsys: Add DW DPTX Controller support library
> > > > >    drm/rockchip: Add RK3588 DPTX output support
> > > > >    MAINTAINERS: Add entry for DW DPTX Controller bridge
> > > > I tried pushing patches 1-4, but got the following error:
> > > > 
> > > > dim: ERROR: 5a68dcf5837a ("MAINTAINERS: Add entry for DW DPTX Controller bridge"): Mandatory Maintainer Acked-by missing., aborting
> > > > 
> > > > I'm not sure how to handle MAINTAINERS changes (or whether it's fine for
> > > > me or not), so I will probably push patches 1-3 in a few days, if nobody
> > > > beats me (or unless somebody points out a correct process for
> > > > MAINTAINERS changes).
> > > 
> > > That warning has been added recently to make sure that patches do not get in
> > > without sufficient review. It's overly pedantic, though.
> > 
> > It's not "overly pedantic", it follows the contribution rules. I'd argue
> > that, if anything, we've been overly tolerant with that kind of
> > practices.
> > 
> > We do have a bug with handling MAINTAINERS changes at the moment. But
> > everything else shouldn't be ignored: either patch MAINTAINERS to
> > reflect the actual contribution path, or get the maintainers Ack.
> 
> For me that points out that MAINTAINERS changes should be integrated
> into the corresponding driver patch rather than being a separate patch.

Not really. It's really just a bug in dim, there's no hidden intent :)

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)