This patch series contain the below updates,
- Adds support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface in the
  net/ethernet/oa_tc6.c.
  Link to the spec:
  -----------------
  https://opensig.org/download/document/OPEN_Alliance_10BASET1x_MAC-PHY_Serial_Interface_V1.1.pdf

- Adds driver support for Microchip LAN8650/1 Rev.B1 10BASE-T1S MACPHY
  Ethernet driver in the net/ethernet/microchip/lan865x/lan865x.c.
  Link to the product:
  --------------------
  https://www.microchip.com/en-us/product/lan8650

Testing Details:
----------------
The driver performance was tested using iperf3 in the below two setups
separately.

Setup 1:
--------
Node 0 - Raspberry Pi 4 with LAN8650 MAC-PHY 
Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick

Setup 2:
--------
Node 0 - SAMA7G54-EK with LAN8650 MAC-PHY 
Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick

Achieved maximum of 9.4 Mbps.

Some systems like Raspberry Pi 4 need performance mode enabled to get the
proper clock speed for SPI. Refer below link for more details.

https://github.com/raspberrypi/linux/issues/3381#issuecomment-1144723750

Changes:
v2:
- Removed RFC tag.
- OA TC6 framework configured in the Kconfig and Makefile to compile as a
  module.
- Kerneldoc headers added for all the API methods exposed to MAC driver.
- Odd parity calculation logic updated from the below link,
  https://elixir.bootlin.com/linux/latest/source/lib/bch.c#L348
- Control buffer memory allocation moved to the initial function.
- struct oa_tc6 implemented as an obaque structure.
- Removed kthread for handling mac-phy interrupt instead threaded irq is
  used.
- Removed interrupt implementation for soft reset handling instead of
  that polling has been implemented.
- Registers name in the defines changed according to the specification
  document.
- Registers defines are arranged in the order of offset and followed by
  register fields.
- oa_tc6_write_register() implemented for writing a single register and
  oa_tc6_write_registers() implemented for writing multiple registers.
- oa_tc6_read_register() implemented for reading a single register and
  oa_tc6_read_registers() implemented for reading multiple registers.
- Removed DRV_VERSION macro as git hash provided by ethtool.
- Moved MDIO bus registration and PHY initialization to the OA TC6 lib.
- Replaced lan865x_set/get_link_ksettings() functions with
  phy_ethtool_ksettings_set/get() functions.
- MAC-PHY's standard capability register values checked against the
  user configured values.
- Removed unnecessary parameters validity check in various places.
- Removed MAC address configuration in the lan865x_net_open() function as
  it is done in the lan865x_probe() function already.
- Moved standard registers and proprietary vendor registers to the
  respective files.
- Added proper subject prefixes for the DT bindings.
- Moved OA specific properties to a separate DT bindings and corrected the
  types & mistakes in the DT bindings.
- Inherited OA specific DT bindings to the LAN865x specific DT bindings.
- Removed sparse warnings in all the places.
- Used net_err_ratelimited() for printing the error messages.
- oa_tc6_process_rx_chunks() function and the content of oa_tc6_handler()
  function are split into small functions.
- Used proper macros provided by network layer for calculating the
  MAX_ETH_LEN.
- Return value of netif_rx() function handled properly.
- Removed unnecessary NULL initialization of skb in the
  oa_tc6_rx_eth_ready() function removed.
- Local variables declaration ordered in reverse xmas tree notation.

v3:
- Completely redesigned all the patches.
- Control and data interface patches are divided into multiple small
  patches.
- Device driver APIs added in the oa-tc6-framework.rst file.
- Code readability improved in all the patches.
- Defined macros wherever is possible.
- Changed RESETC to STATUS0_RESETC for improving the readability.
- Removed OA specific DT bindings.
- Used default configurations defined in the OA spec.
- All variables are named properly as per OA spec for more redability.
- Bigger functions are split into multiple smaller functions.
- DT binding check is done.
- Phy mask is removed in phy scanning.
- Used NET_RX_DROP to compare the rx packet submission status.
- Indentation in the Kconfig file corrected.
- Removed CONFIG_OF and CONFIG_ACPI ifdefs.
- Removed MODULE_ALIAS().

v4:
- Fixed indentation in oa-tc6-framework.rst file.
- Replaced ENODEV error code with EPROTO in the
  oa_tc6_check_ctrl_write_reply and oa_tc6_check_ctrl_read_reply()
  functions.
- Renamed oa_tc6_read_sw_reset_status() function as
  oa_tc6_read_status0().
- Changed software reset polling delay as 1ms and polling timeout as 1s.
- Implemented clause 45 registers direct access.
- Replaced ENODEV error code with ENOMEM in the
  oa_tc6_mdiobus_register() function.
- Changed transmit skbs queue size as 2.
- Added skb_linearize() function to convert contiguous packet data.
- Checked kthread_should_stop() in the oa_tc6_spi_thread_handler()
  function before proceeding for the oa_tc6_try_spi_transfer().
- Removed netdev_err() print in the oa_tc6_allocate_rx_skb() function.
- Added spi-peripheral-props reference in the dt-bindings.
- Changed the fallback order in the dt-bindings.
- Replaced netif_start_queue() with netif_wake_queue().
- Empty data transfer performed in the oa_tc6_init() function to clear
  the reset complete interrupt.
- ZARFE bit in the CONFIG0 register is set to 1 to avoid lan865x halt
  based on the recommendation in the lan865x errata.

Parthiban Veerasooran (12):
  Documentation: networking: add OPEN Alliance 10BASE-T1x MAC-PHY serial
    interface
  net: ethernet: oa_tc6: implement register write operation
  net: ethernet: oa_tc6: implement register read operation
  net: ethernet: oa_tc6: implement software reset
  net: ethernet: oa_tc6: implement error interrupts unmasking
  net: ethernet: oa_tc6: implement internal PHY initialization
  net: ethernet: oa_tc6: enable open alliance tc6 data communication
  net: ethernet: oa_tc6: implement transmit path to transfer tx ethernet
    frames
  net: ethernet: oa_tc6: implement receive path to receive rx ethernet
    frames
  net: ethernet: oa_tc6: implement mac-phy interrupt
  microchip: lan865x: add driver support for Microchip's LAN865X MAC-PHY
  dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY

 .../bindings/net/microchip,lan865x.yaml       |   80 +
 Documentation/networking/oa-tc6-framework.rst |  491 ++++++
 MAINTAINERS                                   |   15 +
 drivers/net/ethernet/Kconfig                  |   11 +
 drivers/net/ethernet/Makefile                 |    1 +
 drivers/net/ethernet/microchip/Kconfig        |    1 +
 drivers/net/ethernet/microchip/Makefile       |    1 +
 .../net/ethernet/microchip/lan865x/Kconfig    |   19 +
 .../net/ethernet/microchip/lan865x/Makefile   |    6 +
 .../net/ethernet/microchip/lan865x/lan865x.c  |  384 +++++
 drivers/net/ethernet/oa_tc6.c                 | 1321 +++++++++++++++++
 drivers/net/phy/microchip_t1s.c               |   30 +
 include/linux/oa_tc6.h                        |   23 +
 include/uapi/linux/mdio.h                     |    1 +
 14 files changed, 2384 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan865x.yaml
 create mode 100644 Documentation/networking/oa-tc6-framework.rst
 create mode 100644 drivers/net/ethernet/microchip/lan865x/Kconfig
 create mode 100644 drivers/net/ethernet/microchip/lan865x/Makefile
 create mode 100644 drivers/net/ethernet/microchip/lan865x/lan865x.c
 create mode 100644 drivers/net/ethernet/oa_tc6.c
 create mode 100644 include/linux/oa_tc6.h

-- 
2.34.1

On Thu, Apr 18, 2024 at 06:26:36PM +0530, Parthiban Veerasooran wrote:
> This patch series contain the below updates,
> - Adds support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface in the
>   net/ethernet/oa_tc6.c.
>   Link to the spec:
>   -----------------
>   https://opensig.org/download/document/OPEN_Alliance_10BASET1x_MAC-PHY_Serial_Interface_V1.1.pdf
> 
> - Adds driver support for Microchip LAN8650/1 Rev.B1 10BASE-T1S MACPHY
>   Ethernet driver in the net/ethernet/microchip/lan865x/lan865x.c.
>   Link to the product:
>   --------------------
>   https://www.microchip.com/en-us/product/lan8650

The patchset did not apply cleanly to net-next:

https://patchwork.kernel.org/project/netdevbpf/list/?series=&submitter=206056&state=*&q=&archive=&delegate=

Which means it did not get any of the standard automatic testing :-(

      Andrew

> Testing Details:
> ----------------
> The driver performance was tested using iperf3 in the below two setups
> separately.
> 
> Setup 1:
> --------
> Node 0 - Raspberry Pi 4 with LAN8650 MAC-PHY 
> Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick
> 
> Setup 2:
> --------
> Node 0 - SAMA7G54-EK with LAN8650 MAC-PHY 
> Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick

Would it be possible to chain these two setups together by adding two
USB dongles to one of the Ri 4s? If i remember correctly, there were
reports of issues when two devices were using the framework at once.

Thanks
	Andrew

On Mon, Apr 22, 2024 at 10:08:23PM +0200, Andrew Lunn wrote:
> > Testing Details:
> > ----------------
> > The driver performance was tested using iperf3 in the below two setups
> > separately.
> > 
> > Setup 1:
> > --------
> > Node 0 - Raspberry Pi 4 with LAN8650 MAC-PHY 
> > Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick
> > 
> > Setup 2:
> > --------
> > Node 0 - SAMA7G54-EK with LAN8650 MAC-PHY 
> > Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick
> 
> Would it be possible to chain these two setups together by adding two
> USB dongles to one of the Ri 4s? If i remember correctly, there were
> reports of issues when two devices were using the framework at once.

Sorry, that makes no sense. Your USB device is unlikely to be doing
USB->SPI->MAC-PHY. Do you have two LAN8650 MAC-PHY you can connect to
one host?

    Andrew

Hi Andrew,

On 23/04/24 4:53 am, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Mon, Apr 22, 2024 at 10:08:23PM +0200, Andrew Lunn wrote:
>>> Testing Details:
>>> ----------------
>>> The driver performance was tested using iperf3 in the below two setups
>>> separately.
>>>
>>> Setup 1:
>>> --------
>>> Node 0 - Raspberry Pi 4 with LAN8650 MAC-PHY
>>> Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick
>>>
>>> Setup 2:
>>> --------
>>> Node 0 - SAMA7G54-EK with LAN8650 MAC-PHY
>>> Node 1 - Raspberry Pi 4 with EVB-LAN8670-USB USB Stick
>>
>> Would it be possible to chain these two setups together by adding two
>> USB dongles to one of the Ri 4s? If i remember correctly, there were
>> reports of issues when two devices were using the framework at once.
> 
> Sorry, that makes no sense. Your USB device is unlikely to be doing
> USB->SPI->MAC-PHY. Do you have two LAN8650 MAC-PHY you can connect to
> one host?
Yes. I tried this test. It works as expected.

Setup:
------

-------------------      ---------------------------
|     RPI4 1      |      |           RPI4 2        |
| --------------- | N/W 1| ----------------------- |
| | 1st LAN8651 | |<---->| | 1st EVB-LAN8670-USB | |
| --------------- |      | ----------------------- |
|                 |      |                         |
| --------------- | N/W 2| ----------------------- |
| | 2nd LAN8651 | |<---->| | 2nd EVB-LAN8670-USB | |
| --------------- |      | ----------------------- |
-------------------      ---------------------------

        |---> 1st LAN8651 ---> IP: 192.168.5.100
RPI4 1 |
        |---> 2nd LAN8651 ---> IP: 192.168.5.100

        |---> 1st EVB-LAN8670-USB ---> IP: 192.168.5.101
RPI4 2 |
        |---> 2nd EVB-LAN8670-USB ---> IP: 192.168.6.101

Test case 1:
------------
  RPI4 1 (Sender):
  ----------------
   $ iperf3 -c 192.168.5.101 -u -b 5M -i 1 -t 0 -p 5001
   $ iperf3 -c 192.168.6.101 -u -b 5M -i 1 -t 0 -p 5002
  RPI4 2 (Receiver):
  ------------------
   $ iperf3 -s -p 5001
  RPI4 3 (Receiver):
  ------------------
   $ iperf3 -s -p 5002
  Result on RPI4 side:
  --------------------
   Each LAN8651 transmits 5Mbps without any error.

Test case 2:
------------
  RPI4 1 (Sender):
  ----------------
   $ iperf3 -c 192.168.5.101 -u -b 10M -i 1 -t 0 -p 5001
   $ iperf3 -c 192.168.6.101 -u -b 10M -i 1 -t 0 -p 5002
  RPI4 2 (Receiver):
  ------------------
   $ iperf3 -s -p 5001
  RPI4 3 (Receiver):
  ------------------
   $ iperf3 -s -p 5002
  Result on RPI4 side:
  --------------------
   Each LAN8651 transmitting approximately 5 or 6Mbps without any error.

Test case 3:
-----------------------
  RPI4 1 (Receiver):
  ----------------
   $ iperf3 -s -p 5001
   $ iperf3 -s -p 5002
  RPI4 2 (Sender):
  ----------------
   $ iperf3 -c 192.168.5.100 -u -b 5M -i 1 -t 0 -p 5001
  RPI4 3 (Sender):
  ----------------
   $ iperf3 -c 192.168.6.100 -u -b 5M -i 1 -t 0 -p 5002
  Result on RPI4 side:
  --------------------
   Each LAN8651 received 5Mbps without any error.

Test case 4:
-----------------------
  RPI4 1 (Receiver):
  ------------------
   $ iperf3 -s -p 5001
   $ iperf3 -s -p 5002
  RPI4 2 (Sender):
  ----------------
   $ iperf3 -c 192.168.5.100 -u -b 10M -i 1 -t 0 -p 5001
  RPI4 3 (Sender):
  ----------------
   $ iperf3 -c 192.168.6.100 -u -b 10M -i 1 -t 0 -p 5002
  Result on RPI4 side:
  --------------------
   Each LAN8651 received approximately 3Mbps with lot of "Receive buffer 
overflow error". I think it is expected as the single SPI master has to 
serve both LAN8651 at the same time and both LAN8651 will be receiving 
10Mbps on each.

Please let me know if I have any misunderstanding here or you need more 
details on the test cases.

Best regards,
Parthiban V
> 
>      Andrew
> 

> Yes. I tried this test. It works as expected.

>    Each LAN8651 received approximately 3Mbps with lot of "Receive buffer 
> overflow error". I think it is expected as the single SPI master has to 
> serve both LAN8651 at the same time and both LAN8651 will be receiving 
> 10Mbps on each.

Thanks for testing this.

This also shows the "Receive buffer overflow error" needs to go away.
Either we don't care at all, and should not enable the interrupt, or
we do care and should increment a counter.

	Andrew

Hi Andrew,

On 08/05/24 10:34 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> Yes. I tried this test. It works as expected.
> 
>>     Each LAN8651 received approximately 3Mbps with lot of "Receive buffer
>> overflow error". I think it is expected as the single SPI master has to
>> serve both LAN8651 at the same time and both LAN8651 will be receiving
>> 10Mbps on each.
> 
> Thanks for testing this.
> 
> This also shows the "Receive buffer overflow error" needs to go away.
> Either we don't care at all, and should not enable the interrupt, or
> we do care and should increment a counter.
Thanks for your comments. I think, I would go for your 2nd proposal 
because having "Receive buffer overflow error" enabled will indicate the 
cause of the poor performance.

Already we have,
tc6->netdev->stats.rx_dropped++;
to increment the rx dropped counter in case of receive buffer overflow.

May be we can remove the print,
net_err_ratelimited("%s: Receive buffer overflow error\n", 
tc6->netdev->name);
as it might lead to additional poor performance by adding some delay.

Could you please provide your opinion on this?

Best regards,
Parthiban V
> 
>          Andrew
> 

On Thu, May 09, 2024 at 01:04:52PM +0000, Parthiban.Veerasooran@microchip.com wrote:
> Hi Andrew,
> 
> On 08/05/24 10:34 pm, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> >> Yes. I tried this test. It works as expected.
> > 
> >>     Each LAN8651 received approximately 3Mbps with lot of "Receive buffer
> >> overflow error". I think it is expected as the single SPI master has to
> >> serve both LAN8651 at the same time and both LAN8651 will be receiving
> >> 10Mbps on each.
> > 
> > Thanks for testing this.
> > 
> > This also shows the "Receive buffer overflow error" needs to go away.
> > Either we don't care at all, and should not enable the interrupt, or
> > we do care and should increment a counter.
> Thanks for your comments. I think, I would go for your 2nd proposal 
> because having "Receive buffer overflow error" enabled will indicate the 
> cause of the poor performance.
> 
> Already we have,
> tc6->netdev->stats.rx_dropped++;
> to increment the rx dropped counter in case of receive buffer overflow.
> 
> May be we can remove the print,
> net_err_ratelimited("%s: Receive buffer overflow error\n", 
> tc6->netdev->name);
> as it might lead to additional poor performance by adding some delay.
> 
> Could you please provide your opinion on this?

This is your code. Ideally you should decide. I will only add review
comments if i think it is wrong. Any can decide between any correct
option.

	Andrew

Hi Andrew,

On 10/05/24 2:09 am, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, May 09, 2024 at 01:04:52PM +0000, Parthiban.Veerasooran@microchip.com wrote:
>> Hi Andrew,
>>
>> On 08/05/24 10:34 pm, Andrew Lunn wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>>> Yes. I tried this test. It works as expected.
>>>
>>>>      Each LAN8651 received approximately 3Mbps with lot of "Receive buffer
>>>> overflow error". I think it is expected as the single SPI master has to
>>>> serve both LAN8651 at the same time and both LAN8651 will be receiving
>>>> 10Mbps on each.
>>>
>>> Thanks for testing this.
>>>
>>> This also shows the "Receive buffer overflow error" needs to go away.
>>> Either we don't care at all, and should not enable the interrupt, or
>>> we do care and should increment a counter.
>> Thanks for your comments. I think, I would go for your 2nd proposal
>> because having "Receive buffer overflow error" enabled will indicate the
>> cause of the poor performance.
>>
>> Already we have,
>> tc6->netdev->stats.rx_dropped++;
>> to increment the rx dropped counter in case of receive buffer overflow.
>>
>> May be we can remove the print,
>> net_err_ratelimited("%s: Receive buffer overflow error\n",
>> tc6->netdev->name);
>> as it might lead to additional poor performance by adding some delay.
>>
>> Could you please provide your opinion on this?
> 
> This is your code. Ideally you should decide. I will only add review
> comments if i think it is wrong. Any can decide between any correct
> option.
Sure, thanks for your advice. Let me stick with the above proposal until 
I get any others opinion.

Best regards,
Parthiban V
> 
>          Andrew
> 

On Thu, Apr 18, 2024 at 06:26:36PM +0530, Parthiban Veerasooran wrote:
> This patch series contain the below updates,
> - Adds support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface in the
>   net/ethernet/oa_tc6.c.
>   Link to the spec:
>   -----------------
>   https://opensig.org/download/document/OPEN_Alliance_10BASET1x_MAC-PHY_Serial_Interface_V1.1.pdf
> 
> - Adds driver support for Microchip LAN8650/1 Rev.B1 10BASE-T1S MACPHY
>   Ethernet driver in the net/ethernet/microchip/lan865x/lan865x.c.
>   Link to the product:
>   --------------------
>   https://www.microchip.com/en-us/product/lan8650

I will get around to reviewing this soon, i promise.

To the OnSemi people: Have you tried your driver/device using this
framework? It would be good to have a second vendors device using it,
just to show no vendor specific code has slipped into the framework.

Thanks
	Andrew