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:   Wed, 29 Jun 2022 16:54:35 -0700
From:   Colin Foster <colin.foster@in-advantage.com>
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
Cc:     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>,
        Lee Jones <lee.jones@linaro.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: <20220629235435.GA992734@euler>
References: <20220628081709.829811-2-colin.foster@in-advantage.com>
 <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>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220629230805.klgcklovkkunn5cm@skbuf>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Bhx8S7iRCwNbrZBrmxXDMMWanO+xFejStn6bORAH8aIjRlWqXT31gk9JhQmz?=
 =?us-ascii?Q?ho8I3S2knyb+d0xKpuEhhuXCZvqu3itnm4t3aMG8MZ5ltzEKdKQgnybo2H3I?=
 =?us-ascii?Q?jH6HUrkhRMfB3HgmFufKHqlD0nc8PtPyUeSAk8ZzB+HAv9lEh0DZEyOmIP2R?=
 =?us-ascii?Q?x9rINGv/FscOuuNkYX0z2r8yS3WLpwLuQesmOpKulPPd17ExbQzlelSWVJ3n?=
 =?us-ascii?Q?wivsOLQKMwMqu1FPwGQFWzVRTvR3ZUG8M2HVD3f9qP+I6MsQVT6JwWUGz1KW?=
 =?us-ascii?Q?fGA7kuUZT98Q6tBfOlIEFynWZNA6kDFYtqz+9mQDO2U1qVGOOOd5aLi6y8L/?=
 =?us-ascii?Q?UScYQhwv0E6aM5FyQod1LPgFcQTePsb4zeHpietXf4Vu4Tx4L7tKql5+C9mF?=
 =?us-ascii?Q?ffGu1P7c03fOuoWmd7Xhl/w10meTrUK+4Tyahiu+OS6OxGSd4XQmzq9MPIq8?=
 =?us-ascii?Q?BMcVB7vilb0My9Yntj/X/iI744TRxmzcaeEAtU1YUsRVmm62C9OtL/8KMZuC?=
 =?us-ascii?Q?/0uAV4mfV08cAZ1yC3rnK1cOlbWdctmbI2MgPHi+QY065pazMcyNtR8dTFpN?=
 =?us-ascii?Q?1j+u1UXOtvFaJfMPjuUsy1T3etIrl5GHCq14eDI/g4isPtroKbqu000b4+xn?=
 =?us-ascii?Q?PV8mC8FwSmnvwR6Ye4KlV3Qh3WsZd9Z23BXR/4scmun0yEEEsoz7rowxyT9z?=
 =?us-ascii?Q?Bzhm/Dq/6eTUmXERVKnsE3A+90OUXPsc99qY19Or6UR/I6otkFWYXxe2VK9X?=
 =?us-ascii?Q?Wl84mTyAEIQsBus3E8X/3MMLN39IPf48K9FOzp9TABrPLntE4QoC2pG5R42O?=
 =?us-ascii?Q?Wb88uiJ/WEKpVzU4vnF0VLJGv2BeLTTb+/8MNhu5rT09/UXicOOhhiKLKwVu?=
 =?us-ascii?Q?2Ocm27Y3cdmTPDlL2QNbccRji2YsVxPXKp1m2CwBUaDOYPoQDtBphDpU2XhO?=
 =?us-ascii?Q?jF8fzGql7TpXoauNdkmw2KRbLu2FJ4b1qAyE8fP2xdwv2pA9+f2i73BV3NLX?=
 =?us-ascii?Q?m6dQvoW3sTZhhB6ccHQqcgwtREYMxJX0HTzSUlyTwX3oi52wXQsS+Pu4LTCp?=
 =?us-ascii?Q?Fn3H3kGQDc2pGeJ146CSCQrwtvktaIKz4l/tuwnqixN/5jtmDxSddJprljEz?=
 =?us-ascii?Q?d6rKRCh8rrI4gceWJP0CDIxE4+ZqggGj3mhsO1+8Id8OkTjADD6DN7gIYNyy?=
 =?us-ascii?Q?Kb40D9krsqwXVjoCyuzsKU+Jfe8f9RvvrvzHTtaBtxNI5Y+Xi2OnFFqGBx7r?=
 =?us-ascii?Q?1zCwA4FNDQ2eWeXfOghK+pZNi/RXlcwFkTPtzvNniMV6xlAS+0yrg4XYUubo?=
 =?us-ascii?Q?Wfd5fnwEhFEiy+MF8lGygPntV7CbjLuVOB/m4ksHA/zK7Ve42fLGUP38yVgX?=
 =?us-ascii?Q?Z8gKrBxSrOFMjytP+QqYLxuemS5a7PN98aPmI028qfvLxVxAedDn15JzWkFe?=
 =?us-ascii?Q?H0b1hMmeR9iL1iS+RKDLjJ4ohurGI2MRwylMy69KDCnNyU1DxSZ/dxHOxc7c?=
 =?us-ascii?Q?Td7j+nvAnp/N93EzCJCMeajN9NszStHXw/evZFkYPe79HgQdhpdXcGq499VU?=
 =?us-ascii?Q?RmvTxeBh1w7e92dRg9PvCbuXS78eog+vbqQuk56SdZeC4Lv1+dc3Cy2s9rMo?=
 =?us-ascii?Q?0g=3D=3D?=
X-OriginatorOrg: in-advantage.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2edbd7b9-4025-4ef5-ecf3-08da5a2abcce
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2351.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2022 23:54:43.4462
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 48e842ca-fbd8-4633-a79d-0c955a7d3aae
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: r4l66/jQX3Aug0BZTeHcaUZfnN3674Vjwf4Hm5U1P4F7VHHThK6HFr78bjosRjjph3QOwgTJQ+3knbyHKt0M8tz4RFvOj64spwLspwm3ds8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5567
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.