Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource

[Colin Foster <colin.foster@in-advantage.com>]

On Wed, Jun 29, 2022 at 11:08:05PM +0000, Vladimir Oltean wrote:
> On Wed, Jun 29, 2022 at 01:39:05PM -0700, Colin Foster wrote:
> > I liked the idea of the MFD being "code complete" so if future regmaps
> > were needed for the felix dsa driver came about, it wouldn't require
> > changes to the "parent." But I think that was a bad goal - especially
> > since MFD requires all the resources anyway.
> > 
> > Also at the time, I was trying a hybrid "create it if it doesn't exist,
> > return it if was already created" approach. I backed that out after an
> > RFC.
> > 
> > Focusing only on the non-felix drivers: it seems trivial for the parent
> > to create _all_ the possible child regmaps, register them to the parent
> > via by way of regmap_attach_dev().
> > 
> > At that point, changing things like drivers/pinctrl/pinctrl-ocelot.c to
> > initalize like (untested, and apologies for indentation):
> > 
> > regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> > if (IS_ERR(regs)) {
> >     map = dev_get_regmap(dev->parent, name);
> > } else {
> >     map = devm_regmap_init_mmio(dev, regs, config);
> > }
> 
> Again, those dev_err(dev, "invalid resource\n"); prints you were
> complaining about earlier are self-inflicted IMO, and caused exactly by
> this pattern. I get why you prefer to call larger building blocks if
> possible, but in this case, devm_platform_get_and_ioremap_resource()
> calls exactly 2 sub-functions: platform_get_resource() and
> devm_ioremap_resource(). The IS_ERR() that you check for is caused by
> devm_ioremap_resource() being passed a NULL pointer, and same goes for
> the print. Just call them individually, and put your dev_get_regmap()
> hook in case platform_get_resource() returns NULL, rather than passing
> NULL to devm_ioremap_resource() and waiting for that to fail.

I see that now. Hoping this next version removes a lot of this
unnecessary complexity.

> 
> > In that case, "name" would either be hard-coded to match what is in
> > drivers/mfd/ocelot-core.c. The other option is to fall back to
> > platform_get_resource(pdev, IORESOURCE_REG, 0), and pass in
> > resource->name. I'll be able to deal with that when I try it. (hopefully
> > this evening)
> 
> I'm not exactly clear on what you'd do with the REG resource once you
> get it. Assuming you'd get access to the "reg = <0x71070034 0x6c>;"
> from the device tree, what next, who's going to set up the SPI regmap
> for you?

The REG resource would only get the resource name, while the MFD core
driver would set up the regmaps.

e.g. drivers/mfd/ocelot-core.c has (annotated):
static const struct resource vsc7512_sgpio_resources[] = {
    DEFINE_RES_REG_NAMED(start, size, "gcb_gpio") };

Now, the drivers/pinctrl/pinctrl-ocelot.c expects resource 0 to be the
gpio resource, and gets the resource by index.

So for this there seem to be two options:
Option 1:
drivers/pinctrl/pinctrl-ocelot.c:
res = platform_get_resource(pdev, IORESOURCE_REG, 0);
map = dev_get_regmap(dev->parent, res->name);


OR Option 2:
include/linux/mfd/ocelot.h has something like:
#define GCB_GPIO_REGMAP_NAME "gcb_gpio"

and drivers/pinctrl/pinctrl-ocelot.c skips get_resource and jumps to:
map = dev_get_regmap(dev->parent, GCB_GPIO_REGMAP_NAME);

(With error checking, macro reuse, etc.)


I like option 1, since it then makes ocelot-pinctrl.c have no reliance
on include/linux/mfd/ocelot.h. But in both cases, all the regmaps are
set up in advance during the start of ocelot_core_init, just before
devm_mfd_add_devices is called.


I should be able to test this all tonight.

> 
> > This seems to be a solid design that I missed! As you mention, it'll
> > require changes to felix dsa... but not as much as I had feared. And I
> > think it solves all my fears about modules to boot. This seems too good
> > to be true - but maybe I was too deep and needed to take this step back.

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