linux-kernel - Re: Re: [PATCH v5 3/4] dt-bindings: display: rockchip: Add schema for RK3588 HDMI TX 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240902010948.3654-1-shimrrashai@gmail.com>
Date: Sun,  1 Sep 2024 20:09:48 -0500
From: Shimrra Shai <shimrrashai@...il.com>
To: cristian.ciocaltea@...labora.com
Cc: Laurent.pinchart@...asonboard.com,
	aarnoud@...com,
	airlied@...il.com,
	andrzej.hajda@...el.com,
	andy.yan@...k-chips.com,
	conor+dt@...nel.org,
	daniel@...ll.ch,
	devicetree@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	heiko@...ech.de,
	hjc@...k-chips.com,
	jernej.skrabec@...il.com,
	jonas@...boo.se,
	kernel@...labora.com,
	krzk+dt@...nel.org,
	krzk@...nel.org,
	ldearquer@...il.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	maarten.lankhorst@...ux.intel.com,
	markyao0591@...il.com,
	mripard@...nel.org,
	neil.armstrong@...aro.org,
	rfoss@...nel.org,
	robh@...nel.org,
	s.hauer@...gutronix.de,
	tzimmermann@...e.de
Subject: Re: Re: [PATCH v5 3/4] dt-bindings: display: rockchip: Add schema for RK3588 HDMI TX Controller

Cristian Ciocaltea wrote:
> On 8/31/24 9:13 AM, Krzysztof Kozlowski wrote:
> >
> > Please define all clocks.
>
> The other clocks are defined in the common binding, should we reiterate
> them?

I would suggest yes, they should be reduplicated, if only to maintain
consistency with all the other docs. A grep through the bridge docs
shows that there are virtually none which use a "{}" placeholder like
this. While it seems kind of like one might worry about "don't
repeat yourself" syndrome, keep in mind this is not code, but human-
used documentation. Having all the information available at a glance
would seem to be the most convenient to the end (developer) user, so
they aren't having to toggle between two separate files. Of course
there may be some questions regarding docs becoming out of sync, but
*ideally* we don't want to break backward compatibility with device
trees (esp. given how I am imagining firmware integration to work on
these platforms, as the RK3588 is at at least low-end desktop-grade
performance and UEFI packages have already been built for it), though
of course that doesn't mean adding new options is off the table.

(FWIW, this is what I did in my now-withdrawn-at-your-request
re-submission; I reduplicated the bindings as it seemed that's what
others here were pushing for and thus that felt like the quickest way
to get this important driver approved.)

- Shimrra Shai