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: <2731770.KRxA6XjA2N@diego>
Date: Wed, 08 Jan 2025 23:28:44 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Alexey Charkov <alchark@...il.com>
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

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.


> 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.

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 ;-) .


Heiko

> [4] https://github.com/rockchip-linux/kernel/blob/develop-5.10/sound/soc/rockchip/rockchip_spdif.c
> [5] https://github.com/torvalds/linux/blob/master/sound/soc/rockchip/rockchip_spdif.c
>