mbox series

[net-next,00/11] New DSA driver for VSC9953 Seville switch

Message ID 20200527234113.2491988-1-olteanv@gmail.com
Headers show
Series New DSA driver for VSC9953 Seville switch | expand

Message

Vladimir Oltean May 27, 2020, 11:41 p.m. UTC
Looking at the Felix and Ocelot drivers, Maxim asked if it would be
possible to use them as a base for a new driver for the switch inside
NXP T1040. Turns out, it is! The result is a driver eerily similar to
Felix.

The biggest challenge seems to be getting register read/write API
generic enough to cover such wild bitfield variations between hardware
generations. There is a patch on the regmap core which I would like to
get in through the networking subsystem, if possible (and if Mark is
ok), since it's a trivial addition.

Maxim Kochetkov (4):
  soc/mscc: ocelot: add MII registers description
  net: mscc: ocelot: convert SYS_PAUSE_CFG register access to regfield
  net: mscc: ocelot: extend watermark encoding function
  net: dsa: ocelot: introduce driver for Seville VSC9953 switch

Vladimir Oltean (7):
  regmap: add helper for per-port regfield initialization
  net: mscc: ocelot: unexport ocelot_probe_port
  net: mscc: ocelot: convert port registers to regmap
  net: mscc: ocelot: convert QSYS_SWITCH_PORT_MODE and SYS_PORT_MODE to
    regfields
  net: dsa: ocelot: create a template for the DSA tags on xmit
  net: mscc: ocelot: split writes to pause frame enable bit and to
    thresholds
  net: mscc: ocelot: disable flow control on NPI interface

 drivers/net/dsa/ocelot/Kconfig           |   12 +
 drivers/net/dsa/ocelot/Makefile          |    6 +
 drivers/net/dsa/ocelot/felix.c           |   49 +-
 drivers/net/dsa/ocelot/felix_vsc9959.c   |   72 +-
 drivers/net/dsa/ocelot/seville.c         |  742 +++++++++++++++
 drivers/net/dsa/ocelot/seville.h         |   50 +
 drivers/net/dsa/ocelot/seville_vsc9953.c | 1064 ++++++++++++++++++++++
 drivers/net/ethernet/mscc/ocelot.c       |   87 +-
 drivers/net/ethernet/mscc/ocelot.h       |    9 +-
 drivers/net/ethernet/mscc/ocelot_board.c |   21 +-
 drivers/net/ethernet/mscc/ocelot_io.c    |   18 +-
 drivers/net/ethernet/mscc/ocelot_regs.c  |   57 ++
 include/linux/regmap.h                   |    8 +
 include/soc/mscc/ocelot.h                |   68 +-
 include/soc/mscc/ocelot_dev.h            |   78 --
 include/soc/mscc/ocelot_qsys.h           |   13 -
 include/soc/mscc/ocelot_sys.h            |   23 -
 net/dsa/tag_ocelot.c                     |   21 +-
 18 files changed, 2196 insertions(+), 202 deletions(-)
 create mode 100644 drivers/net/dsa/ocelot/seville.c
 create mode 100644 drivers/net/dsa/ocelot/seville.h
 create mode 100644 drivers/net/dsa/ocelot/seville_vsc9953.c

Comments

Mark Brown May 29, 2020, 4:51 p.m. UTC | #1
On Thu, 28 May 2020 02:41:02 +0300, Vladimir Oltean wrote:
> Looking at the Felix and Ocelot drivers, Maxim asked if it would be
> possible to use them as a base for a new driver for the switch inside
> NXP T1040. Turns out, it is! The result is a driver eerily similar to
> Felix.
> 
> The biggest challenge seems to be getting register read/write API
> generic enough to cover such wild bitfield variations between hardware
> generations. There is a patch on the regmap core which I would like to
> get in through the networking subsystem, if possible (and if Mark is
> ok), since it's a trivial addition.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next

Thanks!

[1/1] regmap: add helper for per-port regfield initialization
      commit: 8baebfc2aca26e3fa67ab28343671b82be42b22c

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
Mark Brown May 29, 2020, 4:59 p.m. UTC | #2
On Fri, May 29, 2020 at 05:51:52PM +0100, Mark Brown wrote:

> [1/1] regmap: add helper for per-port regfield initialization
>       commit: 8baebfc2aca26e3fa67ab28343671b82be42b22c

Let me know if you need a pull request for this, I figured it was too
late to deal with the cross tree issues for the merge window.
Vladimir Oltean May 29, 2020, 5:28 p.m. UTC | #3
Hi Mark,

On Fri, 29 May 2020 at 19:59, Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 29, 2020 at 05:51:52PM +0100, Mark Brown wrote:
>
> > [1/1] regmap: add helper for per-port regfield initialization
> >       commit: 8baebfc2aca26e3fa67ab28343671b82be42b22c
>
> Let me know if you need a pull request for this, I figured it was too
> late to deal with the cross tree issues for the merge window.

Thanks a lot for merging this. I plan to resend this series again (on
the last mile!) during the weekend, with the feedback collected so
far, so I'm not sure what is the best path to make sure Dave also has
this patch in his tree so I don't break net-next.

-Vladimir
Mark Brown May 29, 2020, 5:34 p.m. UTC | #4
On Fri, May 29, 2020 at 08:28:01PM +0300, Vladimir Oltean wrote:

> Thanks a lot for merging this. I plan to resend this series again (on
> the last mile!) during the weekend, with the feedback collected so
> far, so I'm not sure what is the best path to make sure Dave also has
> this patch in his tree so I don't break net-next.

That was what the pull request would be for, though if you need to
resend the chances are it'll be after the merge window before it gets
applied in which case he'll get the patch through Linus' tree which
makes things easier (that was part of the reason I just went ahead and
applied).
Vladimir Oltean May 29, 2020, 5:49 p.m. UTC | #5
On Fri, 29 May 2020 at 20:34, Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 29, 2020 at 08:28:01PM +0300, Vladimir Oltean wrote:
>
> > Thanks a lot for merging this. I plan to resend this series again (on
> > the last mile!) during the weekend, with the feedback collected so
> > far, so I'm not sure what is the best path to make sure Dave also has
> > this patch in his tree so I don't break net-next.
>
> That was what the pull request would be for, though if you need to
> resend the chances are it'll be after the merge window before it gets
> applied in which case he'll get the patch through Linus' tree which
> makes things easier (that was part of the reason I just went ahead and
> applied).

Yeah, well, I was hoping I could get this in for 5.8, since the
changes requested so far aren't radical (and neither are the patches
themselves). If it's too much of a hassle I can wait for the merge
window to close, sure.

Thanks,
-Vladimir