On Tue, Jun 09, 2020 at 04:38:31PM +0200, Michael Walle wrote:

  mfd-device@10 {
    compatible = "simple-regmap", "simple-mfd";
    reg = <10>;
    regmap,reg-bits = <8>;
    regmap,val-bits = <8>;
    sub-device@0 {
      compatible = "vendor,sub-device0";
      reg = <0>;
    };

A DT binding like this is not a good idea, encoding the details of the
register map into the DT binding makes it an ABI which is begging for
trouble.  I'd also suggest that any device using a generic driver like
this should have a specific compatible string for the device so we can
go back and add quirks later if we need them.

    ...
};

Or if you just want the regmap:

&soc {
  regmap: regmap@fff0000 {
    compatible = "simple-regmap";
    reg = <0xfff0000>;
    regmap,reg-bits = <16>;
    regmap,val-bits = <32>;
  };

  enet-which-needs-syscon-too@1000000 {
    vendor,ctrl-regmap = <&regmap>;
  };
};

Similar to the current syscon (which is MMIO only..).

-michael

quoted

I can't think of any reasons why not, off the top of my head.

Does Regmap only deal with shared accesses from multiple devices
accessing a single register map, or can it also handle multiple
devices communicating over a single I2C channel?

One for Mark perhaps.

quoted

quoted

The issues I wish to resolve using 'simple-mfd' are when sub-devices
register maps overlap and intertwine.

[...]

quoted

quoted

quoted

quoted

quoted

What do these bits configure?

- hardware strappings which have to be there before the board powers
up,
  like clocking mode for different SerDes settings
- "keep-in-reset" bits for onboard peripherals if you want to save
power
- disable watchdog bits (there is a watchdog which is active right
from
  the start and supervises the bootloader start and switches to
failsafe
  mode if it wasn't successfully started)
- special boot modes, like eMMC, etc.

Think of it as a 16bit configuration word.

And you wish for users to be able to view these at run-time?

And esp. change them.

quoted

Can they adapt any of them on-the-fly or will the be RO?

They are R/W but only will only affect the board behavior after a
reset.

I see.  Makes sense.  This is board controller territory.  Perhaps
suitable for inclusion into drivers/soc or drivers/platform.