Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 30 Jun 2022 08:54:41 +0100
From:   Lee Jones <lee.jones@linaro.org>
To:     Colin Foster <colin.foster@in-advantage.com>
Cc:     Vladimir Oltean <vladimir.oltean@nxp.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Lars Povlsen <lars.povlsen@microchip.com>,
        Steen Hegelund <Steen.Hegelund@microchip.com>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Wolfram Sang <wsa@kernel.org>,
        Terry Bowman <terry.bowman@amd.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Arnd Bergmann <arnd@kernel.org>
Subject: Re: [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap
 from a resource
Message-ID: <Yr1WwQwlmQiYnk00@google.com>
References: <20220628160809.marto7t6k24lneau@skbuf>
 <20220628172518.GA855398@euler>
 <20220628184659.sel4kfvrm2z6rwx6@skbuf>
 <20220628185638.dpm2w2rfc3xls7xd@skbuf>
 <CAHp75Ve-MF=MafvwYbFvW330-GhZM9VKKUWmSVxUQ4r_8U1mJQ@mail.gmail.com>
 <20220628195654.GE855398@euler>
 <20220629175305.4pugpbmf5ezeemx3@skbuf>
 <20220629203905.GA932353@euler>
 <20220629230805.klgcklovkkunn5cm@skbuf>
 <20220629235435.GA992734@euler>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220629235435.GA992734@euler>
Precedence: bulk

On Wed, 29 Jun 2022, Colin Foster wrote:

> 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.

Thank you Vladimir for stepping in to clarify previous points.

Well done both of you for this collaborative effort.  Great to see!

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