linux-kernel - Re: [PATCH v2 2/3] arm64: dts: rockchip: Add SPDIF nodes to RK3588(s) device trees

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: <CABjd4Yy48dwZA83XRps_L_sowA_e95PcXYqvAo2J+xVydSA44A@mail.gmail.com>
Date: Fri, 10 Jan 2025 19:30:33 +0400
From: Alexey Charkov <alchark@...il.com>
To: Heiko Stübner <heiko@...ech.de>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] arm64: dts: rockchip: Add SPDIF nodes to RK3588(s)
 device trees

On Thu, Jan 9, 2025 at 2:28 AM Heiko Stübner <heiko@...ech.de> wrote:
>
> Hi Alexey,
>
> Am Mittwoch, 8. Januar 2025, 16:30:35 CET schrieb Alexey Charkov:
> > On Wed, Jan 8, 2025 at 2:01 PM Heiko Stübner <heiko@...ech.de> wrote:
> > >
> > > Hi Alexey,
> > >
> > > Am Mittwoch, 8. Januar 2025, 10:09:07 CET schrieb Alexey Charkov:
> > > > RK3588s has four SPDIF transmitters, and the full RK3588 has six.
> > > > They are fully compatible to RK3568 ones. Add respective nodes
> > > > to .dtsi files.
> > >
> > > While it may seem that way, we still want soc-specific compatibles,
> > > to future-proof this.
> > >
> > > I.e. going the the
> > >         compatible = "rockchip,rk3588-spdif", "rockchip,rk3568-spdif";
> > > way, so that now things can just match against the rk3568, but if some
> > > fault emerges later on the code can be fixed with the DT staying just
> > > compatible.
> > >
> > > The spdif also has an example already for all the spdif variants that are
> > > compatible to the rk3066 [3], so it'd need another "items" block for things
> > > being compatible with the rk3568.
> >
> > Hmm, if we are to believe the driver ([4], [5]), they are all the same
> > as the good old RK3366, which in turn is software compatible to the
> > good old RK3066. Same seems to apply to RK3576, given that its current
> > .dtsi just references the "rockchip,rk3568-spdif" compatible.
>
> I was for a short while afraid that something slipped into mainline :-)
> But I guess that "rockchip,rk3568-spdif" compatible on the rk3576 is
> only used in the vendor-kernel.

Sorry, didn't mean to give you a heart attack :-)

> > Does it mean that the binding needs to be restructured so that the
> > required fallback compatible ("rockchip,rk3066-spdif") applies to all
> > variants? Or shall the existing ones be left alone, and just RK3588
> > and RK3576 added inside that "items" block?
>
> I noticed that the spdif binding has had an interestings growth over
> the years, with some socs being outliers.
>
> I wouldn't change the whole binding, especially as that then touches
> established stuff.

Noted, thanks.

> The question would be weather to add the rk3588 + rk3576 to the
> existing enum marking them as compatible with the rk3066, or create
> a separate items block and just saying the rk3588-spdif is compatible with
> the rk3568 one, like:
>
> [...]
>       - const: rockchip,rk3568-spdif
>       - items:
>           - enum:
>               - rockchip,rk3128-spdif
>               - rockchip,rk3188-spdif
>               - rockchip,rk3288-spdif
>               - rockchip,rk3308-spdif
>           - const: rockchip,rk3066-spdif
>       - items:
>           - enum:
>               - rockchip,rk3576-spdif
>               - rockchip,rk3588-spdif
>           - const: rockchip,rk3568-spdif
> [...]
>
> With the RK3066 being released in 2012, part of me is amazed that that
> block survived that long, on the other hand going with the above snippet
> somehow feels saver ;-) .

Let me first submit a short series dealing with RK3588 alone, as
that's the only one I can test at the moment.

Best,
Alexey