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:   Tue, 27 Sep 2022 16:01:51 -0700
From:   Colin Foster <colin.foster@in-advantage.com>
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, netdev@vger.kernel.org,
        Russell King <linux@armlinux.org.uk>,
        Linus Walleij <linus.walleij@linaro.org>,
        UNGLinuxDriver@microchip.com,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Lee Jones <lee@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Eric Dumazet <edumazet@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH v3 net-next 11/14] mfd: ocelot: add regmaps for ocelot_ext
Message-ID: <YzOA35MxZ6S6E6qe@colin-ia-desktop>
References: <20220926002928.2744638-1-colin.foster@in-advantage.com>
 <20220926002928.2744638-12-colin.foster@in-advantage.com>
 <20220927210411.6oc3aphlyp4imgsq@skbuf>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220927210411.6oc3aphlyp4imgsq@skbuf>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zXer53tKHjzkkEFZ/IOHjKOvyL40T0K8XiC91uXZ8kACiROXd4Ce1bFVp4iv?=
 =?us-ascii?Q?gAy5ASsdJzl5NxegdZmYci/eG6DQymo0MNtdrq63AfChXeZOCUt4wMupx+fk?=
 =?us-ascii?Q?YtxOZGuoyNc9Tv9TYVcBWURzNM06b9dI40oiRna0HTIRzNV1McAsiEkRFCJ7?=
 =?us-ascii?Q?WoptDZlKpP2s1Zc8kMgeQIWwf4kFptj0hQyq+Nzcg6knCgnOA+lxUOoaShyS?=
 =?us-ascii?Q?zzYhIBOcY3up1mhI/e2Mw7RYwy1Lwu5m8tLJdsw4+M0A8xd5kWVREhEf65zD?=
 =?us-ascii?Q?6BQ+dKCXAMFrYTLWjg/IEP0M+tTtMnpEmX6enKOyvLGoiZpfx++ar8HWRwl9?=
 =?us-ascii?Q?2fNAScUP7L8x7Gk1MiXp403mJD8c2qAV2dzWrZwwqduk4yORzReQ1tpvNMVx?=
 =?us-ascii?Q?c1EKQL9GnIwpQs9WHN6NIe+U+jeGbovVl1ba8c8RLu8tkcG+2HBBT9ufSj13?=
 =?us-ascii?Q?NoP6MlzXpqKJ9mvdFW2RXJn4tPU2pIKGH4H9TtwDhQ9DH1rJBQN6cU7SXMfZ?=
 =?us-ascii?Q?/uMOM9fBy88M1ePar4UVwxmB2xypHtVq5UVBXda0IWTj+OgdVhIS1nLD0Taj?=
 =?us-ascii?Q?w9UW5uTi5dXK4AvlebkWZiZTJrKnAYTCwyXIssuDDnT3pOhy5hJfAwsTh1bx?=
 =?us-ascii?Q?BvBd4/qFIePUhOFiuXli/5qAScHt0VZt6Gpj35kE2Z6cX3HOWJhicVJNBBvj?=
 =?us-ascii?Q?yO8jY8FygdCpoNO6BJG0yIwV/0yqzzBdAXbOfpfpEkgI4Y0cOKDsO7QtxKsf?=
 =?us-ascii?Q?ayeNewB3Zhkeq3oy8+Rz0jlcwO+CmzhrBq2JcsMRlGqMJMUA+iRq+o7dbfRb?=
 =?us-ascii?Q?koJ3nERLog6sY2yqt0z2and9G6+2X4PlZxUFc+Ae3fcbN6nauBzcFhtwRNP8?=
 =?us-ascii?Q?S2/FUjbExIQZIWq2TRDsk8YOqjQbOMaZRgTG/e0cNnVkBchZZipwslZOnog9?=
 =?us-ascii?Q?QgB8CizZWMnab2klSwtqexfIloGDA5vHNlgMAPS6172JeYTqGEf9cYlO5jWe?=
 =?us-ascii?Q?LK/SAjniPWBgd2Xm5PYTlHPFtMnYsE4r80n1YZtfM4s5j8irpkAkB+wsi1Xu?=
 =?us-ascii?Q?N6XPtgCE2f+p113EeGBVOlP92E25c6MIMYka9cBITvyLHIlOaNRbRD+BnieY?=
 =?us-ascii?Q?meXcjbPMk1sLKobagU3I/vpdBs9WZI++rFBhvprYI6ZRdUtRNH9H7Mo4o2wn?=
 =?us-ascii?Q?ggOmeStlKj8mhF2RYDBYAP/TcfuvQgiufMId8roJzaEUbebJg21NYEJJS+SB?=
 =?us-ascii?Q?ZiDyU2cr77QNdPlPihHgwE21uLa++jg9yonqyh8odc35wsWvN6C/iAP5UsRI?=
 =?us-ascii?Q?UVWr+LaHlbRhkU2C0HyuixXLIU99v2RJMUKjeqvW+5xkEnmp4hSc38EE74+P?=
 =?us-ascii?Q?YpysGWKni+9+oA20TI7mswmshOxR/9Ry75+Pb6C6DPkvP4E6BnMUpxVFNzvk?=
 =?us-ascii?Q?raJ9azOFTbi+BWMAcwUNjqHKWhpDejwGk2jQj2f2Uv7+RXUG2KliW5Q/iIXo?=
 =?us-ascii?Q?2qi75g7yfbGfxFxGoprpT0nhNQ/gfJw+5lliDKiZk+jMyGFmg0SMaWWqaLe3?=
 =?us-ascii?Q?Ly4FLLctbLLnuHoqH596jeP0fyW3PZaH/nmr/bExUF+J7OUPnT0cagQW4I7a?=
 =?us-ascii?Q?IjqbuuYP7zq/E2otpwaqcSc=3D?=
X-OriginatorOrg: in-advantage.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c06d40f-ee39-40fe-b0a1-08daa0dc45f2
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2351.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2022 23:01:55.8440
 (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: TSsAqPQKCAsJUwbZqlRLydI1LDi+ZBAyRB0xIXm7YmhI9aC7NVf11B57oxEmnaxioNhzTRu1FLdEeSqx4yXlkj/FmGfYwEXLRPt1e/tvKOI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB5657
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
        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, Sep 28, 2022 at 12:04:11AM +0300, Vladimir Oltean wrote:
> On Sun, Sep 25, 2022 at 05:29:25PM -0700, Colin Foster wrote:
> > The Ocelot switch core driver relies heavily on a fixed array of resources
> > for both ports and peripherals. This is in contrast to existing peripherals
> > - pinctrl for example - which have a one-to-one mapping of driver <>
> > resource. As such, these regmaps must be created differently so that
> > enumeration-based offsets are preserved.
> > 
> > Register the regmaps to the core MFD device unconditionally so they can be
> > referenced by the Ocelot switch / Felix DSA systems.
> > 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> > 
> > v3
> >     * No change
> > 
> > v2
> >     * Alignment of variables broken out to a separate patch
> >     * Structs now correctly use EXPORT_SYMBOL*
> >     * Logic moved and comments added to clear up conditionals around
> >       vsc7512_target_io_res[i].start
> > 
> > v1 from previous RFC:
> >     * New patch
> > 
> > ---
> >  drivers/mfd/ocelot-core.c  | 87 ++++++++++++++++++++++++++++++++++++++
> >  include/linux/mfd/ocelot.h |  5 +++
> >  2 files changed, 92 insertions(+)
> > 
> > diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
> > index 013e83173062..702555fbdcc5 100644
> > --- a/drivers/mfd/ocelot-core.c
> > +++ b/drivers/mfd/ocelot-core.c
> > @@ -45,6 +45,45 @@
> >  #define VSC7512_SIO_CTRL_RES_START	0x710700f8
> >  #define VSC7512_SIO_CTRL_RES_SIZE	0x00000100
> >  
> > +#define VSC7512_HSIO_RES_START		0x710d0000
> > +#define VSC7512_HSIO_RES_SIZE		0x00000128
> 
> I don't think you should give the HSIO resource to the switching driver.
> In drivers/net/ethernet/mscc/ocelot_vsc7514.c, there is this comment:
> 
> static void ocelot_pll5_init(struct ocelot *ocelot)
> {
> 	/* Configure PLL5. This will need a proper CCF driver
> 	 * The values are coming from the VTSS API for Ocelot
> 	 */
> 
> I believe CCF stands for Common Clock Framework.

It does stand for common clock framework. And this function / comment
keeps me up at night.

Agreed that the HSIO resource isn't currently used, and should be
dropped from this set. The resource will be brought back in as soon as I
add in phy-ocelot-serdes support during the third and final (?) patch
set of adding 7512 copper ethernet support.

My fear is that the lines:

if (ocelot->targets[HSIO])
    ocelot_pll5_init(ocelot);

won't fly inside felix_setup(), and I'm not sure how far that scope will
creep. Maybe it is easier than I suspect.


But I'm getting ahead of myself. I'll remove this for now.

> 
> > +
> > +#define VSC7512_ANA_RES_START		0x71880000
> > +#define VSC7512_ANA_RES_SIZE		0x00010000
> > +
> > +#define VSC7512_QS_RES_START		0x71080000
> > +#define VSC7512_QS_RES_SIZE		0x00000100
> > +
> > +#define VSC7512_QSYS_RES_START		0x71800000
> > +#define VSC7512_QSYS_RES_SIZE		0x00200000
> > +
> > +#define VSC7512_REW_RES_START		0x71030000
> > +#define VSC7512_REW_RES_SIZE		0x00010000
> > +
> > +#define VSC7512_SYS_RES_START		0x71010000
> > +#define VSC7512_SYS_RES_SIZE		0x00010000
> > +
> > +#define VSC7512_S0_RES_START		0x71040000
> > +#define VSC7512_S1_RES_START		0x71050000
> > +#define VSC7512_S2_RES_START		0x71060000
> > +#define VSC7512_S_RES_SIZE		0x00000400
> 
> VCAP_RES_SIZE?

I'll change this name to VCAP_RES_SIZE.

> 
> > +
> > +#define VSC7512_GCB_RES_START		0x71070000
> > +#define VSC7512_GCB_RES_SIZE		0x0000022c
> 
> Again, I don't think devcpu_gcb should be given to a switching-only
> driver. There's nothing switching-related about it.

Yes, this is no longer necessary and I missed this. I think you caught
them all, but I'll do another sweep just in case.

> > +const struct resource vsc7512_target_io_res[TARGET_MAX] = {
> > +	[ANA] = DEFINE_RES_REG_NAMED(VSC7512_ANA_RES_START, VSC7512_ANA_RES_SIZE, "ana"),
> > +	[QS] = DEFINE_RES_REG_NAMED(VSC7512_QS_RES_START, VSC7512_QS_RES_SIZE, "qs"),
> > +	[QSYS] = DEFINE_RES_REG_NAMED(VSC7512_QSYS_RES_START, VSC7512_QSYS_RES_SIZE, "qsys"),
> > +	[REW] = DEFINE_RES_REG_NAMED(VSC7512_REW_RES_START, VSC7512_REW_RES_SIZE, "rew"),
> > +	[SYS] = DEFINE_RES_REG_NAMED(VSC7512_SYS_RES_START, VSC7512_SYS_RES_SIZE, "sys"),
> > +	[S0] = DEFINE_RES_REG_NAMED(VSC7512_S0_RES_START, VSC7512_S_RES_SIZE, "s0"),
> > +	[S1] = DEFINE_RES_REG_NAMED(VSC7512_S1_RES_START, VSC7512_S_RES_SIZE, "s1"),
> > +	[S2] = DEFINE_RES_REG_NAMED(VSC7512_S2_RES_START, VSC7512_S_RES_SIZE, "s2"),
> > +	[GCB] = DEFINE_RES_REG_NAMED(VSC7512_GCB_RES_START, VSC7512_GCB_RES_SIZE, "devcpu_gcb"),
> > +	[HSIO] = DEFINE_RES_REG_NAMED(VSC7512_HSIO_RES_START, VSC7512_HSIO_RES_SIZE, "hsio"),
> > +};
> > +EXPORT_SYMBOL_NS(vsc7512_target_io_res, MFD_OCELOT);
> > +
> > +const struct resource vsc7512_port_io_res[] = {
> 
> I hope you will merge these 2 arrays now.

Yep. And with that I should be able to add them via the standard
.num_resources, .resources method all the other drivers use. As
mentioned, without the GCB and HSIO entries.

> >  int ocelot_core_init(struct device *dev)
> >  {
> > +	const struct resource *port_res;
> >  	int i, ndevs;
> >  
> >  	ndevs = ARRAY_SIZE(vsc7512_devs);
> > @@ -151,6 +221,23 @@ int ocelot_core_init(struct device *dev)
> >  	for (i = 0; i < ndevs; i++)
> >  		ocelot_core_try_add_regmaps(dev, &vsc7512_devs[i]);
> >  
> > +	/*
> > +	 * Both the target_io_res and the port_io_res structs need to be referenced directly by
> > +	 * the ocelot_ext driver, so they can't be attached to the dev directly and referenced by
> > +	 * offset like the rest of the drivers. Instead, create these regmaps always and allow any
> > +	 * children look these up by name.
> > +	 */
> > +	for (i = 0; i < TARGET_MAX; i++)
> > +		/*
> > +		 * The target_io_res array is sparsely populated. Use .start as an indication that
> > +		 * the entry isn't defined
> > +		 */
> > +		if (vsc7512_target_io_res[i].start)
> > +			ocelot_core_try_add_regmap(dev, &vsc7512_target_io_res[i]);
> > +
> > +	for (port_res = vsc7512_port_io_res; port_res->start; port_res++)
> > +		ocelot_core_try_add_regmap(dev, port_res);
> > +
> 
> Will need to be updated.

Yep. I think it can all go away for the above
ocelot_core_try_add_regmaps() call now.

> 
> >  	return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs, ndevs, NULL, 0, NULL);
> >  }
> >  EXPORT_SYMBOL_NS(ocelot_core_init, MFD_OCELOT);
> > diff --git a/include/linux/mfd/ocelot.h b/include/linux/mfd/ocelot.h
> > index dd72073d2d4f..439ff5256cf0 100644
> > --- a/include/linux/mfd/ocelot.h
> > +++ b/include/linux/mfd/ocelot.h
> > @@ -11,8 +11,13 @@
> >  #include <linux/regmap.h>
> >  #include <linux/types.h>
> >  
> > +#include <soc/mscc/ocelot.h>
> > +
> 
> Is this the problematic include that makes it necessary to have the
> pinctrl hack? Can we drop the #undef REG now?

Yes, this include was specifically for TARGET_MAX below. That undef REG
should not be necessary anymore. I'll drop it.

> 
> >  struct resource;
> >  
> > +extern const struct resource vsc7512_target_io_res[TARGET_MAX];
> > +extern const struct resource vsc7512_port_io_res[];
> > +
> 
> Will need to be removed.

Gladly :-)

> 
> >  static inline struct regmap *
> >  ocelot_regmap_from_resource_optional(struct platform_device *pdev,
> >  				     unsigned int index,
> > -- 
> > 2.25.1
> >