linux-kernel - Re: [PATCH 2/5] dt-bindings: phy: rockchip-inno-csi-dphy: add rk3588 variant

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: <17533727.geO5KgaWL5@phil>
Date: Thu, 19 Jun 2025 22:11:49 +0200
From: Heiko Stuebner <heiko@...ech.de>
To: Neil Armstrong <neil.armstrong@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
 Philipp Zabel <p.zabel@...gutronix.de>,
 Jagan Teki <jagan@...rulasolutions.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Collabora Kernel Team <kernel@...labora.com>,
 Michael Riesch <michael.riesch@...labora.com>
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-phy@...ts.infradead.org
Subject:
 Re: [PATCH 2/5] dt-bindings: phy: rockchip-inno-csi-dphy: add rk3588 variant

Am Mittwoch, 18. Juni 2025, 08:32:25 Mitteleuropäische Sommerzeit schrieb Michael Riesch:
> Hi Neil,
> 
> Thanks for your comments!
> 
> On 6/17/25 11:31, neil.armstrong@...aro.org wrote:
> > On 17/06/2025 10:54, Michael Riesch via B4 Relay wrote:
> >> From: Michael Riesch <michael.riesch@...labora.com>
> >>
> >> The Rockchip RK3588 variant of the CSI-2 DPHY features two reset lines.
> >> Add the variant and allow for the additional reset.
> > 
> > No names for the new resets on the RK3588 ?
> 
> I left the names away because TBH I don't see the value in them (in that
> case).
> 
> Downstream uses reset-names = "srst_csiphy0", "srst_p_csiphy0"; and
> there is no better description. One could guess that the second reset
> corresponds to "apb" but this is just guessing and we would still have
> to guess/find a proper name for the first reset.
> 
> Amazingly the mainline driver does not seem to do anything with the
> resets (unless I overlooked some implicit magic). Downstream does a
> simple reset_control_{assert,deassert} before configuring the PHY. Now
> if the different resets are handled in bulk mode, does it really make
> sense to address each reset individually?

it might not make sense now, but possibly in the future?

A binding and the attached devicetrees are meant to be "forever", i.e. a
new kernel _should_ support all those old devicetrees you throw at it - 
if they conform to (at some time) established bindings.

So while all drivers might not need the specific resets now, you don't
know what quirks you'll have discovered in two years ;-)

And instead of trying to update the binding and then carrying both the
new and the fallback code for the old binding around, why not do it now.

Then when you find a need for a specific reset, things magically just work.


Heiko