All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Foster <colin.foster@in-advantage.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Terry Bowman <terry.bowman@amd.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Wolfram Sang <wsa@kernel.org>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	Steen Hegelund <Steen.Hegelund@microchip.com>,
	Lars Povlsen <lars.povlsen@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Russell King <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Lee Jones <lee.jones@linaro.org>,
	katie.morris@in-advantage.com
Subject: Re: [PATCH v15 mfd 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
Date: Wed, 3 Aug 2022 08:56:28 -0700	[thread overview]
Message-ID: <YuqarB067s+rqFKe@euler> (raw)
In-Reply-To: <CAHp75Vc30VW_dYGodyw4mrMwFgTVyDFaMP2ZJXQEB2nFOB2RWw@mail.gmail.com>

On Wed, Aug 03, 2022 at 01:45:04PM +0200, Andy Shevchenko wrote:
> On Wed, Aug 3, 2022 at 7:48 AM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> >
> > The VSC7512 is a networking chip that contains several peripherals. Many of
> > these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> > controlled externally.
> >
> > Utilize the existing drivers by referencing the chip as an MFD. Add support
> > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.
> 
> 
> ...
> 
> > +#include <asm/byteorder.h>
> 
> Not sure I see the user of this header.

Interesting. And I think you uncovered one more issue.

I'd used byteorder at one time to modify the SPI payload (addr is always
big-endian, payload should always be native).

When I migrated to using the spi_bus_read() instead of spi_reg_read(),
this became handled much more elegantly in regmap itself. So this isn't
needed anymore.

I also have byteorder in include/linux/mfd/ocelot.h, where it also isn't
needed. It is checking:

#ifdef __LITTLE_ENDIAN
#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_LE
#else
#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_BE
#endif


That file should be replaced with
#include <linux/kconfig.h>

> 
> ...
> 
> > +struct regmap *ocelot_spi_init_regmap(struct device *dev, const struct resource *res)
> > +{
> > +       struct regmap_config regmap_config;
> > +
> > +       memcpy(&regmap_config, &ocelot_spi_regmap_config, sizeof(regmap_config));
> > +
> > +       regmap_config.name = res->name;
> 
> > +       regmap_config.max_register = res->end - res->start;
> 
> Hmm... First of all, resource_size() is for that (with - 1 to the
> result). But don't you need to use stride in the calculations?

DEFINE_RES_NAMED populates the resource .end with (_start) + (_size) - 1
so I don't think resource_size is correct to use here.

reg_stride gets handled at the top of regmap_read(), so I don't think
that's really needed either.


For reference:

#define VSC7512_DEVCPU_ORG_RES_START    0x71000000
#define VSC7512_DEVCPU_ORG_RES_SIZE     0x38


# pwd
/sys/kernel/debug/regmap/spi0.0-devcpu_org
# cat range
0-34
# cat registers
00: 00000000
04: 02000001
08: 00000001
0c: 00000000
10: 00000fff
14: 00000000
18: 00000000
1c: 00000000
20: 00000000
24: 00000000
28: 00000001
2c: 00000004
30: 00000001
34: 00000004


> 
> > +       regmap_config.reg_base = res->start;
> > +
> > +       return devm_regmap_init(dev, &ocelot_spi_regmap_bus, dev, &regmap_config);
> > +}
> 
> -- 
> With Best Regards,
> Andy Shevchenko

WARNING: multiple messages have this Message-ID (diff)
From: Colin Foster <colin.foster@in-advantage.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Terry Bowman <terry.bowman@amd.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Wolfram Sang <wsa@kernel.org>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	Steen Hegelund <Steen.Hegelund@microchip.com>,
	Lars Povlsen <lars.povlsen@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Russell King <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Lee Jones <lee.jones@linaro.org>,
	katie.morris@in-advantage.com
Subject: Re: [PATCH v15 mfd 9/9] mfd: ocelot: add support for the vsc7512 chip via spi
Date: Wed, 3 Aug 2022 08:56:28 -0700	[thread overview]
Message-ID: <YuqarB067s+rqFKe@euler> (raw)
In-Reply-To: <CAHp75Vc30VW_dYGodyw4mrMwFgTVyDFaMP2ZJXQEB2nFOB2RWw@mail.gmail.com>

On Wed, Aug 03, 2022 at 01:45:04PM +0200, Andy Shevchenko wrote:
> On Wed, Aug 3, 2022 at 7:48 AM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> >
> > The VSC7512 is a networking chip that contains several peripherals. Many of
> > these peripherals are currently supported by the VSC7513 and VSC7514 chips,
> > but those run on an internal CPU. The VSC7512 lacks this CPU, and must be
> > controlled externally.
> >
> > Utilize the existing drivers by referencing the chip as an MFD. Add support
> > for the two MDIO buses, the internal phys, pinctrl, and serial GPIO.
> 
> 
> ...
> 
> > +#include <asm/byteorder.h>
> 
> Not sure I see the user of this header.

Interesting. And I think you uncovered one more issue.

I'd used byteorder at one time to modify the SPI payload (addr is always
big-endian, payload should always be native).

When I migrated to using the spi_bus_read() instead of spi_reg_read(),
this became handled much more elegantly in regmap itself. So this isn't
needed anymore.

I also have byteorder in include/linux/mfd/ocelot.h, where it also isn't
needed. It is checking:

#ifdef __LITTLE_ENDIAN
#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_LE
#else
#define OCELOT_SPI_BYTE_ORDER OCELOT_SPI_BYTE_ORDER_BE
#endif


That file should be replaced with
#include <linux/kconfig.h>

> 
> ...
> 
> > +struct regmap *ocelot_spi_init_regmap(struct device *dev, const struct resource *res)
> > +{
> > +       struct regmap_config regmap_config;
> > +
> > +       memcpy(&regmap_config, &ocelot_spi_regmap_config, sizeof(regmap_config));
> > +
> > +       regmap_config.name = res->name;
> 
> > +       regmap_config.max_register = res->end - res->start;
> 
> Hmm... First of all, resource_size() is for that (with - 1 to the
> result). But don't you need to use stride in the calculations?

DEFINE_RES_NAMED populates the resource .end with (_start) + (_size) - 1
so I don't think resource_size is correct to use here.

reg_stride gets handled at the top of regmap_read(), so I don't think
that's really needed either.


For reference:

#define VSC7512_DEVCPU_ORG_RES_START    0x71000000
#define VSC7512_DEVCPU_ORG_RES_SIZE     0x38


# pwd
/sys/kernel/debug/regmap/spi0.0-devcpu_org
# cat range
0-34
# cat registers
00: 00000000
04: 02000001
08: 00000001
0c: 00000000
10: 00000fff
14: 00000000
18: 00000000
1c: 00000000
20: 00000000
24: 00000000
28: 00000001
2c: 00000004
30: 00000001
34: 00000004


> 
> > +       regmap_config.reg_base = res->start;
> > +
> > +       return devm_regmap_init(dev, &ocelot_spi_regmap_bus, dev, &regmap_config);
> > +}
> 
> -- 
> With Best Regards,
> Andy Shevchenko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-08-03 15:56 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-03  5:47 [PATCH v15 mfd 0/9] add support for VSC7512 control over SPI Colin Foster
2022-08-03  5:47 ` Colin Foster
2022-08-03  5:47 ` [PATCH v15 mfd 1/9] mfd: ocelot: add helper to get regmap from a resource Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:31   ` Andy Shevchenko
2022-08-03 11:31     ` Andy Shevchenko
2022-08-03  5:47 ` [PATCH v15 mfd 2/9] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:31   ` Andy Shevchenko
2022-08-03 11:31     ` Andy Shevchenko
2022-08-03  5:47 ` [PATCH v15 mfd 3/9] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:32   ` Andy Shevchenko
2022-08-03 11:32     ` Andy Shevchenko
2022-08-03  5:47 ` [PATCH v15 mfd 4/9] pinctrl: ocelot: add ability to be used in a non-mmio configuration Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:32   ` Andy Shevchenko
2022-08-03 11:32     ` Andy Shevchenko
2022-08-03  5:47 ` [PATCH v15 mfd 5/9] pinctrl: microchip-sgpio: allow sgpio driver to be used as a module Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:32   ` Andy Shevchenko
2022-08-03 11:32     ` Andy Shevchenko
2022-08-03  5:47 ` [PATCH v15 mfd 6/9] pinctrl: microchip-sgpio: add ability to be used in a non-mmio configuration Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:32   ` Andy Shevchenko
2022-08-03 11:32     ` Andy Shevchenko
2022-08-03  5:47 ` [PATCH v15 mfd 7/9] resource: add define macro for register address resources Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:33   ` Andy Shevchenko
2022-08-03 11:33     ` Andy Shevchenko
2022-08-03  5:47 ` [PATCH v15 mfd 8/9] dt-bindings: mfd: ocelot: add bindings for VSC7512 Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03  5:47 ` [PATCH v15 mfd 9/9] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster
2022-08-03  5:47   ` Colin Foster
2022-08-03 11:45   ` Andy Shevchenko
2022-08-03 11:45     ` Andy Shevchenko
2022-08-03 15:56     ` Colin Foster [this message]
2022-08-03 15:56       ` Colin Foster
2022-08-03 17:10       ` Andy Shevchenko
2022-08-03 17:10         ` Andy Shevchenko
2022-08-03 17:31         ` Colin Foster
2022-08-03 17:31           ` Colin Foster
2022-08-05 17:44   ` Colin Foster
2022-08-05 17:44     ` Colin Foster
2022-08-05 17:58     ` Andy Shevchenko
2022-08-05 17:58       ` Andy Shevchenko
2022-08-05 18:07       ` Colin Foster
2022-08-05 18:07         ` Colin Foster
2022-08-05 18:14         ` Andy Shevchenko
2022-08-05 18:14           ` Andy Shevchenko

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=YuqarB067s+rqFKe@euler \
    --to=colin.foster@in-advantage.com \
    --cc=Steen.Hegelund@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=andy.shevchenko@gmail.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=katie.morris@in-advantage.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lars.povlsen@microchip.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=terry.bowman@amd.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=wsa@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.