On Wed, 10 Jun 2020, Michael Walle wrote:

Am 2020-06-10 09:56, schrieb Lee Jones:

quoted

On Wed, 10 Jun 2020, Michael Walle wrote:

quoted

Am 2020-06-10 09:19, schrieb Lee Jones:

quoted

On Wed, 10 Jun 2020, Michael Walle wrote:

quoted

Am 2020-06-09 21:45, schrieb Lee Jones:

quoted

On Tue, 09 Jun 2020, Michael Walle wrote:

quoted

quoted

We do not need a 'simple-regmap' solution for your use-case.

Since your device's registers are segregated, just split up the
register map and allocate each sub-device with it's own slice.

I don't get it, could you make a device tree example for my
use-case? (see also above)

    &i2cbus {
        mfd-device@10 {
            compatible = "simple-mfd";
            reg = <10>;

            sub-device@10 {
                compatible = "vendor,sub-device";
                reg = <10>;
            };
   };

The Regmap config would be present in each of the child devices.

Each child device would call devm_regmap_init_i2c() in .probe().

Ah, I see. If I'm not wrong, this still means to create an i2c
device driver with the name "simple-mfd".

Yes, it does.

quoted

Besides that, I don't like this, because:
 - Rob already expressed its concerns with "simple-mfd" and so on.

Where did this take place?  I'd like to read up on this.

In this thread:
https://lore.kernel.org/linux-devicetree/20200604211039.12689-1-michael@walle.cc/T/#m16fdba5962069e7cd4aa817582ee358c9fe2ecbf (local)

quoted

quoted

 - you need to duplicate the config in each sub device

You can have a share a single config.

quoted

 - which also means you are restricting the sub devices to be
   i2c only (unless you implement and duplicate other regmap configs,
   too). For this driver, SPI and MMIO may be viable options.

You could also have a shared implementation to choose between different
busses.

Then what is the difference between to have this shared config in the
parent driver only and use the functions which are already there, i.e.
dev_get_regmap(parent). But see, below, I'll wait with what you're
coming up.

The difference is the omission of an otherwise pointless/superfluous
driver.  Actually, it's the difference between the omission of 10
pointless drivers!

If you want to omit anything generic in the device tree - and as far as
I understand it - that should be the way to go, the specific compatible
string of the parent device has to go somewhere. Thus I'd appreciate
a consolidated (MFD) driver which holds all these, as you say it
pointless drivers.
Because IMHO they are not pointless, rather they are
the actual drivers for the MFD. Its sub nodes are just an implementation
detail to be able to use the OF bindings
(like your clock example or
a phandle to a PWM controller). Just because it is almost nothing there
except the regmap instantiation doesn't mean it is not a valid MFD driver.

A valid MFD driver is whatever we (the Linux community at large)
define it to be.  An MFD is not a real thing.  We made it up.  It's
MFD which is the implementation detail, not the child devices.  If a
driver a) does very little, and b) the very little it does do can be
resolved in a different way, is not a valid driver.  It's a waste of
disk space.

And there is also additional stuff, like clock enable, version checks, etc.

As more functionality is added *then* we can justify a driver.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog