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
Date: Thu, 30 Jun 2022 08:54:41 +0100 [thread overview]
Message-ID: <Yr1WwQwlmQiYnk00@google.com> (raw)
In-Reply-To: <20220629235435.GA992734@euler>
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
next prev parent reply other threads:[~2022-06-30 7:54 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 8:17 [PATCH v11 net-next 0/9] add support for VSC7512 control over SPI Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 1/9] mfd: ocelot: add helper to get regmap from a resource Colin Foster
2022-06-28 12:50 ` Andy Shevchenko
2022-06-28 15:33 ` Vladimir Oltean
2022-06-28 16:08 ` Vladimir Oltean
2022-06-28 17:25 ` Colin Foster
2022-06-28 18:47 ` Vladimir Oltean
2022-06-28 18:56 ` Vladimir Oltean
2022-06-28 19:04 ` Andy Shevchenko
2022-06-28 19:56 ` Colin Foster
2022-06-29 17:53 ` Vladimir Oltean
2022-06-29 20:39 ` Colin Foster
2022-06-29 23:08 ` Vladimir Oltean
2022-06-29 23:54 ` Colin Foster
2022-06-30 7:54 ` Lee Jones [this message]
2022-06-30 13:11 ` Vladimir Oltean
2022-06-30 20:09 ` Colin Foster
2022-07-01 16:21 ` Vladimir Oltean
2022-07-01 17:18 ` Colin Foster
2022-07-02 12:42 ` Vladimir Oltean
2022-07-02 16:17 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28 16:26 ` Vladimir Oltean
2022-06-28 18:31 ` Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster
2022-06-28 12:53 ` Andy Shevchenko
2022-06-28 18:25 ` Colin Foster
2022-06-28 19:00 ` Andy Shevchenko
2022-06-30 11:56 ` Linus Walleij
2022-06-28 8:17 ` [PATCH v11 net-next 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module Colin Foster
2022-06-28 12:55 ` Andy Shevchenko
2022-06-28 8:17 ` [PATCH v11 net-next 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 7/9] resource: add define macro for register address resources Colin Foster
2022-06-28 8:17 ` [PATCH v11 net-next 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512 Colin Foster
2022-06-28 13:15 ` Rob Herring
2022-06-28 18:19 ` Colin Foster
2022-06-30 13:17 ` Vladimir Oltean
2022-06-28 8:17 ` [PATCH v11 net-next 9/9] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster
2022-06-28 20:07 ` Randy Dunlap
2022-06-28 20:24 ` Colin Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yr1WwQwlmQiYnk00@google.com \
--to=lee.jones@linaro$(echo .)org \
--cc=Steen.Hegelund@microchip$(echo .)com \
--cc=UNGLinuxDriver@microchip$(echo .)com \
--cc=alexandre.belloni@bootlin$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=andy.shevchenko@gmail$(echo .)com \
--cc=arnd@kernel$(echo .)org \
--cc=colin.foster@in-advantage$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=edumazet@google$(echo .)com \
--cc=hkallweit1@gmail$(echo .)com \
--cc=krzysztof.kozlowski+dt@linaro$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=lars.povlsen@microchip$(echo .)com \
--cc=linus.walleij@linaro$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-gpio@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux@armlinux$(echo .)org.uk \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=robh+dt@kernel$(echo .)org \
--cc=terry.bowman@amd$(echo .)com \
--cc=vladimir.oltean@nxp$(echo .)com \
--cc=wsa@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox