On 08/10/2022 02:00, Vladimir Oltean wrote:

On Wed, Oct 05, 2022 at 06:09:59PM +0200, Krzysztof Kozlowski wrote:

quoted

quoted

quoted

I don't understand how your answer relates to "reg=<0 0>;". How is it
going to become 0x71010000 if there is no other reg/ranges set in parent
nodes. The node has only one IO address, but you say the switch has 20
addresses...

Are we talking about same hardware?

Yes. The switch driver for both the VSC7512 and VSC7514 use up to ~20 regmaps
depending on what capabilities it is to have. In the 7514 they are all
memory-mapped from the device tree. While the 7512 does need these
regmaps, they are managed by the MFD, not the device tree. So there
isn't a _need_ for them to be here, since at the end of the day they're
ignored.

The "reg=<0 0>;" was my attempt to indicate that they are ignored, but I
understand that isn't desired. So moving forward I'll add all the
regmaps back into the device tree.

You need to describe the hardware. If hardware has IO address space, how
does it matter that some driver needs or needs not something?

What do you mean by IO address space exactly? It is a SPI device with registers.
Does that constitute an IO address space to you?

By IO I meant MMIO (or similar) which resides in reg (thus in unit
address). The SPI devices have only chip-select as reg, AFAIR.

The driver need matters because you don't usually see DT nodes of SPI,
I2C, MDIO devices describing the address space of their registers, and
having child nodes with unit addresses in that address space. Only when
those devices are so complex that the need arises to identify smaller
building blocks is when you will end up needing that. And this is an
implementation detail which shapes how the dt-bindings will look like.

So probably I misunderstood here. If this is I2C or SPI device, then of
course reg and unit address do not represent registers.

quoted

You mentioned that address space is mapped to regmaps. Regmap is Linux
specific implementation detail, so this does not answer at all about
hardware.

On the other hand, if your DTS design requires this is a child of
something else and by itself it does not have address space, it would be
understandable to skip unit address entirely... but so far it is still
confusing, especially that you use arguments related to implementation
to justify the DTS.

If Colin skips the unit address entirely, then how could he distinguish
between the otherwise identical MDIO controllers mdio@7107009c and
mdio@710700c0 from Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml?
The ethernet-switch node added here is on the same hierarchical level
with the MDIO controller nodes, so it must have a unit address just like
them.

So what is @710700c0? It's not chip-select, but MMIO or some other bus
(specific to the device), right?

The mscc,ocelot.yaml has a soc@0 SPI device. Children of soc@0 use unit
addresses/reg meaningful for that soc@0.

But I don't support Colin's choice of "reg=<0 0>;" either. A choice must
be made between 2 options:
- mapping all 20 regions of the SPI address space into "reg" values
- mapping a single region from the smallest until the largest address of
  those 20, and hope nothing overlaps with some other peripheral, or
  worse, that this region will never need to be expanded to the left.

Yeah, at least to my limited knowledge of this hardware.

What information do you need to provide some best practices that can be
applied here and are more useful than "you need to describe the
hardware"? 

Describe the hardware properties in terms of it fit in to the whole
system - so some inputs (clocks, GPIOs), outputs (interrupts),
characteristics of a device (e.g. clock provider -> clock cells) and
properties configuring hardware per specific implementation.

But mostly this argument "describe hardware" should be understood like:
do not describe software (Linux drivers) and software policies (driver
choices)...

Verilog/VHDL is what the hardware description that's
independent of software implementation is, good luck parsing that.

Best regards,
Krzysztof