linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Tue, 27 Sep 2022 16:01:51 -0700	[thread overview]
Message-ID: <YzOA35MxZ6S6E6qe@colin-ia-desktop> (raw)
In-Reply-To: <20220927210411.6oc3aphlyp4imgsq@skbuf>

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

  reply	other threads:[~2022-09-27 23:02 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26  0:29 [PATCH v3 net-next 00/14] add support for the the vsc7512 internal copper phys Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 01/14] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 02/14] net: mscc: ocelot: expose regfield definition to be used by other drivers Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 03/14] net: mscc: ocelot: expose stats layout " Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 04/14] net: mscc: ocelot: expose vcap_props structure Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 05/14] net: mscc: ocelot: expose ocelot_reset routine Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 06/14] net: dsa: felix: add configurable device quirks Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 07/14] net: dsa: felix: populate mac_capabilities for all ports Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 08/14] net: dsa: felix: update init_regmap to be string-based Colin Foster
2022-09-27 17:53   ` Vladimir Oltean
2022-09-27 18:43     ` Colin Foster
2022-09-27 18:56       ` Vladimir Oltean
2022-09-26  0:29 ` [PATCH v3 net-next 09/14] pinctrl: ocelot: avoid macro redefinition Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 10/14] mfd: ocelot: prepend resource size macros to be 32-bit Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 11/14] mfd: ocelot: add regmaps for ocelot_ext Colin Foster
2022-09-27 21:04   ` Vladimir Oltean
2022-09-27 23:01     ` Colin Foster [this message]
2022-09-26  0:29 ` [PATCH v3 net-next 12/14] dt-bindings: net: dsa: ocelot: add ocelot-ext documentation Colin Foster
2022-09-27 20:26   ` Vladimir Oltean
2022-09-27 22:20     ` Colin Foster
2022-10-07 22:48       ` Vladimir Oltean
2022-10-08 17:56         ` Colin Foster
2022-09-30 21:15     ` Colin Foster
2022-10-01  0:20       ` Colin Foster
2022-10-03 15:28         ` Vladimir Oltean
2022-10-07 20:44     ` Colin Foster
2022-10-07 22:38       ` Vladimir Oltean
2022-10-04 11:19   ` Krzysztof Kozlowski
2022-10-04 12:15     ` Vladimir Oltean
2022-10-04 14:59       ` Krzysztof Kozlowski
2022-10-04 16:01         ` Vladimir Oltean
2022-10-05  8:09           ` Krzysztof Kozlowski
2022-10-07 23:10             ` Vladimir Oltean
2022-10-09 15:49               ` Krzysztof Kozlowski
2022-10-05  0:08     ` Colin Foster
2022-10-05  8:03       ` Krzysztof Kozlowski
2022-10-05 15:44         ` Colin Foster
2022-10-05 16:09           ` Krzysztof Kozlowski
2022-10-08  0:00             ` Vladimir Oltean
2022-10-09 16:14               ` Krzysztof Kozlowski
2022-10-10 13:07                 ` Vladimir Oltean
2022-10-10 13:37                   ` Krzysztof Kozlowski
2022-10-10 17:48                     ` Vladimir Oltean
2022-10-10 18:47                       ` Colin Foster
2022-10-10 19:11                         ` Vladimir Oltean
2022-10-11  9:53                         ` Vladimir Oltean
2023-01-18 22:28                       ` Colin Foster
2023-01-19 20:21                         ` Vladimir Oltean
2023-01-20 18:16                           ` Colin Foster
2022-09-26  0:29 ` [PATCH v3 net-next 13/14] net: dsa: ocelot: add external ocelot switch control Colin Foster
2022-09-27 20:40   ` Vladimir Oltean
2022-09-26  0:29 ` [PATCH v3 net-next 14/14] mfd: " 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=YzOA35MxZ6S6E6qe@colin-ia-desktop \
    --to=colin.foster@in-advantage.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).