mbox series

[net-next,RFC,0/4] net: dsa: Add Airoha AN8855 support

Message ID 20241021130209.15660-1-ansuelsmth@gmail.com (mailing list archive)
Headers show
Series net: dsa: Add Airoha AN8855 support | expand

Message

Christian Marangi Oct. 21, 2024, 1:01 p.m. UTC 
This small series add the initial support for the Airoha AN8855 Switch.

It's a 5 port Gigabit Switch with SGMII/HSGMII upstream port.

This is starting to get in the wild and there are already some router
having this switch chip.

It's conceptually similar to mediatek switch but register and bits
are different. And there is that massive Hell that is the PCS
configuration.
Saddly for that part we have absolutely NO documentation currently.

There is this special thing where PHY needs to be calibrated with values
from the switch efuse. (the thing have a whole cpu timer and MCU)

Some cleanup API are used and one extra patch for mdio_mutex_nested is
introduced. As suggested some time ago, the use of such API is limited
to scoped variants and not the guard ones.

Posting as RFC as I expect in later version to add additional feature
but this is already working and upstream-ready. So this is really to
have a review of the very basic features and if I missed anything in
recent implementation of DSA.

Christian Marangi (4):
  net: mdio: implement mdio_mutex_nested guard() variant
  dt-bindings: net: dsa: Add Airoha AN8855 Gigabit Switch documentation
  net: dsa: Add Airoha AN8855 5-Port Gigabit DSA Switch driver
  net: phy: Add Airoha AN8855 Internal Switch Gigabit PHY

 .../bindings/net/dsa/airoha,an8855.yaml       |  146 ++
 MAINTAINERS                                   |   11 +
 drivers/net/dsa/Kconfig                       |    9 +
 drivers/net/dsa/Makefile                      |    1 +
 drivers/net/dsa/an8855.c                      | 2008 +++++++++++++++++
 drivers/net/dsa/an8855.h                      |  492 ++++
 drivers/net/phy/Kconfig                       |    5 +
 drivers/net/phy/Makefile                      |    1 +
 drivers/net/phy/air_an8855.c                  |  187 ++
 include/linux/mdio.h                          |    4 +
 10 files changed, 2864 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/airoha,an8855.yaml
 create mode 100644 drivers/net/dsa/an8855.c
 create mode 100644 drivers/net/dsa/an8855.h
 create mode 100644 drivers/net/phy/air_an8855.c

Comments

Vladimir Oltean Oct. 21, 2024, 1:36 p.m. UTC | #1 
On Mon, Oct 21, 2024 at 03:01:55PM +0200, Christian Marangi wrote:
> It's conceptually similar to mediatek switch but register and bits
> are different.

Is it impractical to use struct regmap_field to abstract those
differences away and reuse the mt7530 driver's control flow? What is the
relationship between the Airoha and Mediatek IP anyway? The mt7530
maintainers should also be consulted w.r.t. whether code sharing is in
the common interest (I copied them).
Christian Marangi Oct. 21, 2024, 1:39 p.m. UTC | #2 
On Mon, Oct 21, 2024 at 04:36:05PM +0300, Vladimir Oltean wrote:
> On Mon, Oct 21, 2024 at 03:01:55PM +0200, Christian Marangi wrote:
> > It's conceptually similar to mediatek switch but register and bits
> > are different.
> 
> Is it impractical to use struct regmap_field to abstract those
> differences away and reuse the mt7530 driver's control flow? What is the
> relationship between the Airoha and Mediatek IP anyway? The mt7530
> maintainers should also be consulted w.r.t. whether code sharing is in
> the common interest (I copied them).

Some logic are similar for ATU or VLAN handling but then they added bits
in the middle of the register and moved some in other place.

Happy of being contradicted but from what I checked adapting the mtk
code would introduce lots of condition and wrapper and I feel it would
be actually worse than keeping the 2 codebase alone.

Would love some help by mt7530 to catch some very common case.
Vladimir Oltean Oct. 21, 2024, 1:50 p.m. UTC | #3 
On Mon, Oct 21, 2024 at 03:39:26PM +0200, Christian Marangi wrote:
> On Mon, Oct 21, 2024 at 04:36:05PM +0300, Vladimir Oltean wrote:
> > On Mon, Oct 21, 2024 at 03:01:55PM +0200, Christian Marangi wrote:
> > > It's conceptually similar to mediatek switch but register and bits
> > > are different.
> > 
> > Is it impractical to use struct regmap_field to abstract those
> > differences away and reuse the mt7530 driver's control flow? What is the
> > relationship between the Airoha and Mediatek IP anyway? The mt7530
> > maintainers should also be consulted w.r.t. whether code sharing is in
> > the common interest (I copied them).
> 
> Some logic are similar for ATU or VLAN handling but then they added bits
> in the middle of the register and moved some in other place.
> 
> Happy of being contradicted but from what I checked adapting the mtk
> code would introduce lots of condition and wrapper and I feel it would
> be actually worse than keeping the 2 codebase alone.
> 
> Would love some help by mt7530 to catch some very common case.

As long as the control flow is reasonably similar, the REG_FIELD() macro
is able to deal with register fields which have moved from one place to
another between hardware variants.
Russell King (Oracle) Oct. 21, 2024, 2:11 p.m. UTC | #4 
On Mon, Oct 21, 2024 at 04:36:05PM +0300, Vladimir Oltean wrote:
> On Mon, Oct 21, 2024 at 03:01:55PM +0200, Christian Marangi wrote:
> > It's conceptually similar to mediatek switch but register and bits
> > are different.
> 
> Is it impractical to use struct regmap_field to abstract those
> differences away and reuse the mt7530 driver's control flow? What is the
> relationship between the Airoha and Mediatek IP anyway? The mt7530
> maintainers should also be consulted w.r.t. whether code sharing is in
> the common interest (I copied them).

That thought crossed my mind while reviewing patch 3. I compared the
PMCR and PMSR, a lot of the bits are in completely different places
between the two. I didn't check further, but I got the feeling that
would invite more complexity.