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

[Heiko Stuebner <heiko@sntech.de>]

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@linaro.org wrote:
> > On 17/06/2025 10:54, Michael Riesch via B4 Relay wrote:
> >> From: Michael Riesch <michael.riesch@collabora.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