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)

Changes v7:
- Fix devm_dsa_register_switch wrong export symbol
Changes v6:
- Drop standard MIB and handle with ethtool OPs (as requested by Jakub)
- Cosmetic: use bool instead of 0 or 1
Changes v5:
- Add devm_dsa_register_switch() patch
- Add Reviewed-by tag for DT patch
Changes v4:
- Set regmap readable_table static (mute compilation warning)
- Add support for port_bridge flags (LEARNING, FLOOD)
- Reset fdb struct in fdb_dump
- Drop support_asym_pause in port_enable
- Add define for get_phy_flags
- Fix bug for port not inititially part of a bridge
  (in an8855_setup the port matrix was always cleared but
   the CPU port was never initially added)
- Disable learning and flood for user port by default
- Set CPU port to flood and learning by default
- Correctly AND force duplex and flow control in an8855_phylink_mac_link_up
- Drop RGMII from pcs_config
- Check ret in "Disable AN if not in autoneg"
- Use devm_mutex_init
- Fix typo for AN8855_PORT_CHECK_MODE
- Better define AN8855_STP_LISTENING = AN8855_STP_BLOCKING
- Fix typo in AN8855_PHY_EN_DOWN_SHIFT
- Use paged helper for PHY
- Skip calibration in config_init if priv not defined
Changes v3:
- Out of RFC
- Switch PHY code to select_page API
- Better describe masks and bits in PHY driver for ADC register
- Drop raw values and use define for mii read/write
- Switch to absolute PHY address
- Replace raw values with mask and bits for pcs_config
- Fix typo for ext-surge property name
- Drop support for relocating Switch base PHY address on the bus
Changes v2:
- Drop mutex guard patch
- Drop guard usage in DSA driver
- Use __mdiobus_write/read
- Check return condition and return errors for mii read/write
- Fix wrong logic for EEE
- Fix link_down (don't force link down with autoneg)
- Fix forcing speed on sgmii autoneg
- Better document link speed for sgmii reg
- Use standard define for sgmii reg
- Imlement nvmem support to expose switch EFUSE
- Rework PHY calibration with the use of NVMEM producer/consumer
- Update DT with new NVMEM property
- Move aneg validation for 2500-basex in pcs_config
- Move r50Ohm table and function to PHY driver

Christian Marangi (4):
  net: dsa: add devm_dsa_register_switch()
  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       |  242 ++
 MAINTAINERS                                   |   11 +
 drivers/net/dsa/Kconfig                       |    9 +
 drivers/net/dsa/Makefile                      |    1 +
 drivers/net/dsa/an8855.c                      | 2233 +++++++++++++++++
 drivers/net/dsa/an8855.h                      |  693 +++++
 drivers/net/phy/Kconfig                       |    5 +
 drivers/net/phy/Makefile                      |    1 +
 drivers/net/phy/air_an8855.c                  |  267 ++
 include/net/dsa.h                             |    1 +
 net/dsa/dsa.c                                 |   19 +
 11 files changed, 3482 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

-- 
2.45.2

Hi Christian,

On Sun, Nov 17, 2024 at 02:27:55PM +0100, Christian Marangi wrote:
> 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)

Have you run the scripts in tools/testing/selftests/drivers/net/dsa/?
Could you post the results?

On Mon, Nov 18, 2024 at 04:48:59PM +0200, Vladimir Oltean wrote:
> Hi Christian,
> 
> On Sun, Nov 17, 2024 at 02:27:55PM +0100, Christian Marangi wrote:
> > 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)
> 
> Have you run the scripts in tools/testing/selftests/drivers/net/dsa/?
> Could you post the results?

Any test in particular? I'm working on adding correct support for them
in OpenWrt. Should I expect some to fail?

-- 
	Ansuel

On 11/18/24 19:35, Christian Marangi wrote:
> On Mon, Nov 18, 2024 at 04:48:59PM +0200, Vladimir Oltean wrote:
>> On Sun, Nov 17, 2024 at 02:27:55PM +0100, Christian Marangi wrote:
>>> 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)
>>
>> Have you run the scripts in tools/testing/selftests/drivers/net/dsa/?
>> Could you post the results?
> 
> Any test in particular? I'm working on adding correct support for them
> in OpenWrt. Should I expect some to fail?

Unfortunatelly this landed on netdev too close to the merge window. I'll
unable to apply it on time and process the net-next PR as expected even
if it would receive ack from the DSA crew right now.

@Christian, you will have to repost it after the merge window.

Thanks,

Paolo

On Tue, Nov 19, 2024 at 12:10:19PM +0100, Paolo Abeni wrote:
> On 11/18/24 19:35, Christian Marangi wrote:
> > On Mon, Nov 18, 2024 at 04:48:59PM +0200, Vladimir Oltean wrote:
> >> On Sun, Nov 17, 2024 at 02:27:55PM +0100, Christian Marangi wrote:
> >>> 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)
> >>
> >> Have you run the scripts in tools/testing/selftests/drivers/net/dsa/?
> >> Could you post the results?
> > 
> > Any test in particular? I'm working on adding correct support for them
> > in OpenWrt. Should I expect some to fail?
> 
> Unfortunatelly this landed on netdev too close to the merge window. I'll
> unable to apply it on time and process the net-next PR as expected even
> if it would receive ack from the DSA crew right now.
> 
> @Christian, you will have to repost it after the merge window.
>

It's ok, just any timeframe? Guess 2 weeks till net-next reopens? (just
to put a remainder on the calendar so I won't forget)

-- 
	Ansuel