lkml.org 
[lkml]   [2022]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 4/6] dt-bindings: riscv: Add DT binding documentation for Renesas RZ/Five SoC and SMARC EVK
Hi Krzysztof,

On Wed, Jul 27, 2022 at 2:37 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 27/07/2022 14:21, Biju Das wrote:
> >> Subject: Re: [PATCH 4/6] dt-bindings: riscv: Add DT binding
> >> documentation for Renesas RZ/Five SoC and SMARC EVK
> >> On 27/07/2022 13:37, Lad, Prabhakar wrote:
> >>>>> I did run the dtbs_check test as per your suggestion (below is the
> >>>>> log) and didn't see "no matching schema error"
> >>>>>
> >>>>
> >>>> So you do not see any errors at all. Then it does not work, does it?
> >>>>
> >>> Right I reverted my changes I can see it complaining, dtb_check seems
> >>> to have returned false positive in my case.
> >>>
> >>> What approach would you suggest to ignore the schema here?
> >>
> >> I don't think currently it would work with your approach. Instead, you
> >> should select here all SoCs which the schema should match.
> >>
> >> This leads to my previous concern - you use the same SoC compatible for
> >> two different architectures and different SoCs: ARMv8 and RISC-V.
> >
> > Or is it same SoC(R9A07G043) based on two different CPU architectures (ARMv8 and RISC-V)
>
> Then it is not the same SoC! Same means same, identical. CPU
> architecture is one of the major differences, which means it is not the
> same.
>
> > Using same SoM and Carrier board?
>
> It's like saying PC with x86 and ARMv8 board are the same because they
> both use same "PC chassis".

That's not a fair comparison: the "PC chassis" is passive, while the
carrier board is an active PCB. So it is more akin to plugging
any Intel LGA 1151 processor into any motherboard with an LGA
1151 socket. Do we have compatible values for all such possible
combinations? ;-)

The classic compatible scheme of an ordered list from most-specific
to least-specific is not well-suited for this case of mere
aggregation. That's why we have been decoupling board and SoC
compatible values for a while, and identifying specific boards by a
combination of a board-specific and an SoC-specific compatible value.

New SoCs that are available with different core CPU families (and
that are pin-compatible) are just the next step in the evolution....

At the DT validation level, I think the proper solution is to
merge Documentation/devicetree/bindings/arm/renesas.yaml and
Documentation/devicetree/bindings/riscv/renesas.yaml into a single
file under Documentation/devicetree/bindings/soc/renesas/.

What do other people think?
Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

\
 
 \ /
  Last update: 2022-08-11 17:52    [W:0.322 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site