mbox series

[v5,net-next,00/13] add support for the the vsc7512 internal copper phys

Message ID 20230127193559.1001051-1-colin.foster@in-advantage.com
Headers show
Series add support for the the vsc7512 internal copper phys | expand

Message

Colin Foster Jan. 27, 2023, 7:35 p.m. UTC 
This patch series is a continuation to add support for the VSC7512:
https://patchwork.kernel.org/project/netdevbpf/list/?series=674168&state=*

That series added the framework and initial functionality for the
VSC7512 chip. Several of these patches grew during the initial
development of the framework, which is why v1 will include changelogs.
It was during v9 of that original MFD patch set that these were dropped.

With that out of the way, the VSC7512 is mainly a subset of the VSC7514
chip. The 7512 lacks an internal MIPS processor, but otherwise many of
the register definitions are identical. That is why several of these
patches are simply to expose common resources from
drivers/net/ethernet/mscc/*.

This patch only adds support for the first four ports (swp0-swp3). The
remaining ports require more significant changes to the felix driver,
and will be handled in the future.


***
Note on V5: This driver triggers a bug in phy_device.c. A fix has been
sent to 'net': https://lkml.org/lkml/2023/1/27/1105
***

v5
    * Documentation overhauled to use
      /schemas/net/mscc,vsc7514-switch.yaml instead of
      /schemas/net/dsa/mscc,ocelot.yaml
    * Two patches were applied elsewhere, so have been dropped:
      "net: dsa: felix: populate mac_capabilities for all ports" and
      "dt-bindings: mfd: ocelot: remove spi-max-frequency from required
       properties"
    * stats_layout changes are no longer necessary, so the patch
      "net: mscc: ocelot: expose stats layout definition to be used by
       other drivers" has been dropped
    * Common naming macros has been dropped:
      "mfd: ocelot: add shared resource names for switch functionality".
      This changed patches 12-13 slightly.
    * Patch 12 had some small changes due to the rebase - more info there

v4
    * Update documentation to include all ports / modes (patch 15)
    * Fix dt_bindings_check warnings (patch 13, 14, 15)
    * Utilize new "resource_names" reference (patch 9, 12, 16)
    * Drop unnecessary #undef REG patch in pinctl: ocelot
    * Utilize standard MFD resource addition (patch 17)
    * Utilize shared vsc7514_regmap (new patch 6)
    * Allow forward-compatibility on fully-defined device trees
      (patch 10,14)

v3
    * Fix allmodconfig build (patch 8)
    * Change documentation wording (patch 12)
    * Import module namespace (patch 13)
    * Fix array initializer (patch 13)

v2
    * Utilize common ocelot_reset routine (new patch 5, modified patch 13)
    * Change init_regmap() routine to be string-based (new patch 8)
    * Split patches where necessary (patches 9 and 14)
    * Add documentation (patch 12) and MAINTAINERS (patch 13)
    * Upgrade to PATCH status

v1 (from RFC v8 suggested above):
    * Utilize the MFD framework for creating regmaps, as well as
      dev_get_regmap() (patches 7 and 8 of this series)


Colin Foster (13):
  net: mscc: ocelot: expose ocelot wm functions
  net: mscc: ocelot: expose regfield definition to be used by other
    drivers
  net: mscc: ocelot: expose vcap_props structure
  net: mscc: ocelot: expose ocelot_reset routine
  net: mscc: ocelot: expose vsc7514_regmap definition
  net: dsa: felix: add configurable device quirks
  net: dsa: felix: add support for MFD configurations
  net: dsa: felix: add functionality when not all ports are supported
  mfd: ocelot: prepend resource size macros to be 32-bit
  dt-bindings: net: mscc,vsc7514-switch: add dsa binding for the vsc7512
  dt-bindings: mfd: ocelot: add ethernet-switch hardware support
  net: dsa: ocelot: add external ocelot switch control
  mfd: ocelot: add external ocelot switch control

 .../devicetree/bindings/mfd/mscc,ocelot.yaml  |   9 +
 .../bindings/net/mscc,vsc7514-switch.yaml     | 113 ++++++++---
 MAINTAINERS                                   |   1 +
 drivers/mfd/ocelot-core.c                     |  68 ++++++-
 drivers/net/dsa/ocelot/Kconfig                |  20 ++
 drivers/net/dsa/ocelot/Makefile               |   2 +
 drivers/net/dsa/ocelot/felix.c                |  25 ++-
 drivers/net/dsa/ocelot/felix.h                |   2 +
 drivers/net/dsa/ocelot/felix_vsc9959.c        |   1 +
 drivers/net/dsa/ocelot/ocelot_ext.c           | 163 +++++++++++++++
 drivers/net/dsa/ocelot/seville_vsc9953.c      |   1 +
 drivers/net/ethernet/mscc/ocelot.c            |  48 ++++-
 drivers/net/ethernet/mscc/ocelot_devlink.c    |  31 +++
 drivers/net/ethernet/mscc/ocelot_vsc7514.c    | 190 +-----------------
 drivers/net/ethernet/mscc/vsc7514_regs.c      | 117 +++++++++++
 include/soc/mscc/ocelot.h                     |   6 +
 include/soc/mscc/vsc7514_regs.h               |   6 +
 17 files changed, 582 insertions(+), 221 deletions(-)
 create mode 100644 drivers/net/dsa/ocelot/ocelot_ext.c

Comments

Florian Fainelli Jan. 27, 2023, 7:53 p.m. UTC | #1 
On 1/27/2023 11:35 AM, Colin Foster wrote:
> Add control of an external VSC7512 chip.
> 
> Currently the four copper phy ports are fully functional. Communication to
> external phys is also functional, but the SGMII / QSGMII interfaces are
> currently non-functional.
> 
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Jakub Kicinski Jan. 31, 2023, 7:45 p.m. UTC | #2 
On Tue, 31 Jan 2023 09:06:22 +0000 Lee Jones wrote:
> Please don't do that.  The commits do not have proper Acked-by tags.
> 
> The plan is to merge these via MFD and send out a pull-request to an
> immutable branch.  However, if you're prepared to convert all of the:
> 
>   Acked-for-MFD-by: Lee Jones <lee@kernel.org>
> 
> to
> 
>   Acked-by: Lee Jones <lee@kernel.org>

Sorry, I must have been blind yesterday because I definitely double
checked this doesn't touch mfd code. And it does :/

The patches should not be sent for net-next if they are not supposed 
to be applied directly. Or at the very least says something about
merging in the cover letter!

> ... and send out a pull request to a succinct (only these patches) and
> immutable branch then that is also an acceptable solution.
> 
> Please let me know what works best for you.

Sorry for messing up again. Stable branch would obviously had been best.
Do we have to take action now, or can we just wait for the trees to
converge during the merge window?