On Wed, Jun 10, 2020 at 1:19 AM Lee Jones [off-list ref] wrote:

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.

TBC, while fine for a driver to bind on 'simple-mfd', a DT compatible
with that alone is not fine.

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.

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.

I think it is really the syscon mfd driver you want to generalize to
other buses. Though with a quick look at it, there's not really a
whole lot to share. The regmap lookup would be the main thing. You are
going to need a driver instance for each bus type.

quoted

Thus, I'd rather implement a simple-mfd.c which implement a common
I2C driver for now and populate its children using
devm_of_platform_populate(). This could be extended to support other
type of regmaps like SPI in the future.

Also some MFD drivers could be moved to this, a likely candidate is
the smsc-ece1099.c. Although I don't really understand its purpose,
if don't have CONFIG_OF.

Judging from the existing code, this simple-mfd.c wouldn't just be
"a list of compatible" strings but also additional quirks and tweaks
for particular devices in this list.

Yes, this is why specific compatible strings are required.

Hold off on the simple-mfd.c idea, as I'm not taken by it yet and
wouldn't want you to waste your time.  I have another idea which would
help.  Give me a few days to put something together.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel