Re: [PATCH net-next v2 8/9] microchip: lan865x: add driver support for Microchip's LAN865X MACPHY

[<Parthiban.Veerasooran@microchip.com>]

Hi Ramon,

On 02/11/23 5:50 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Mon, Oct 23, 2023 at 09:16:48PM +0530, Parthiban Veerasooran wrote:
>> The LAN8650/1 is designed to conform to the OPEN Alliance 10BASE‑T1x
>> MAC‑PHY Serial Interface specification, Version 1.1. The IEEE Clause 4
>> MAC integration provides the low pin count standard SPI interface to any
>> microcontroller therefore providing Ethernet functionality without
>> requiring MAC integration within the microcontroller. The LAN8650/1
>> operates as an SPI client supporting SCLK clock rates up to a maximum of
>> 25 MHz. This SPI interface supports the transfer of both data (Ethernet
>> frames) and control (register access).
>>
>> By default, the chunk data payload is 64 bytes in size. A smaller payload
>> data size of 32 bytes is also supported and may be configured in the
>> Chunk Payload Size (CPS) field of the Configuration 0 (OA_CONFIG0)
>> register. Changing the chunk payload size requires the LAN8650/1 be reset
>> and shall not be done during normal operation.
>>
>> The Ethernet Media Access Controller (MAC) module implements a 10 Mbps
>> half duplex Ethernet MAC, compatible with the IEEE 802.3 standard.
>> 10BASE-T1S physical layer transceiver integrated into the LAN8650/1. The
>> PHY and MAC are connected via an internal Media Independent Interface
>> (MII).
>>
>> Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
> 
> Hi Parthiban
> 
> I've been testing the v2 patches out a bit, at Ferroamp we're planning
> on using a dual LAN8650 setup in a product.
I understand that you are using two LAN8650, isn't it? if so are they 
both running simultaneously? or you are doing the testing with one alone?
> 
> First let me say that we'd be happy to assist with testing and
> development.
Thank you for your support on this.
> 
> I got some observations that I think this patch is the resonable place
> to discuss it, since they seem to be MAC/PHY related.
> 
> In order to get a reliable link I'm using the dts snippet below (for an
> imx8 cpu)
> 
> &ecspi1 {
>          pinctrl-names = "default";
>          pinctrl-0 = <&pinctrl_ecspi1>;
>          cs-gpios = <0> , <&gpio5 9 GPIO_ACTIVE_LOW>;
>          status = "okay";
> 
>          spe1: ethernet@1{
>                  compatible = "microchip,lan865x";
>                  reg = <1>;
>                  interrupt-parent = <&gpio5>;
>                  interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
>                  spi-max-frequency = <50000000>;
>                  oa-tc6{
>                          #address-cells = <1>;
>                          #size-cells = <0>;
>                          oa-cps = <32>;
>                          oa-prote;
>                          oa-dprac;
>                  };
>          };
> };
> 
> With this setup I'm getting a maximum throughput of about 90kB/s.
> If I increase the chunk size / oa-cps to 64 I get a might higher
> throughput ~900kB/s, but after 0-2s I get dump below (or similar).
Did you or possible to try a test case with below configuration?

- Single LAN8650 enabled
- UDP
- oa_cps = 64
- spi-max-frequency = 15000000,

Did you run iperf3 test? or any other tool?
If iperf3 then can you share the configuration you used?

I don't know whether these may audiences are needed in the CC for this 
thread. Let's see what's Andrew Lunn thinks about it?

Best Regards,
Parthiban V
> 
> [  363.444460] eth0: Transmit protocol error
> [  363.448527] eth0: Transmit buffer underflow
> [  363.452740] eth0: Receive buffer overflow
> [  363.456780] eth0: Header error
> [  363.459869] eth0: Footer frame drop
> [  363.463379] eth0: SPI transfer failed
> [  363.470590] eth0: Receive buffer overflow
> [  363.474631] eth0: Header error
> [  363.477776] eth0: SPI transfer failed
> [  363.482596] eth0: Footer frame drop
> [  369.884680] ------------[ cut here ]------------
> [  369.889336] NETDEV WATCHDOG: eth0 (lan865x): transmit queue 0 timed out 6448 ms
> [  369.896726] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x22c/0x234
> [  369.905023] Modules linked in:
> [  369.908091] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.4.16-gc5e8aa9586d6 #3
> [  369.915241] Hardware name: <Ferroamp dev kit>
> [  369.921169] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [  369.928146] pc : dev_watchdog+0x22c/0x234
> [  369.932168] lr : dev_watchdog+0x22c/0x234
> [  369.936190] sp : ffff80000800be20
> [  369.939510] x29: ffff80000800be20 x28: 0000000000000101 x27: ffff80000800bf00
> [  369.946665] x26: ffff8000092469c0 x25: 0000000000001930 x24: ffff800009246000
> [  369.953817] x23: 0000000000000000 x22: ffff000000e883dc x21: ffff000000e88000
> [  369.960971] x20: ffff0000010dc000 x19: ffff000000e88488 x18: ffffffffffffffff
> [  369.968124] x17: 383434362074756f x16: 2064656d69742030 x15: 0720072007200720
> [  369.975276] x14: 0720072007200720 x13: ffff80000925fe88 x12: 0000000000000444
> [  369.982431] x11: 000000000000016c x10: ffff8000092b7e88 x9 : ffff80000925fe88
> [  369.989584] x8 : 00000000ffffefff x7 : ffff8000092b7e88 x6 : 80000000fffff000
> [  369.996738] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> [  370.003890] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000000dd400
> [  370.011044] Call trace:
> [  370.013496]  dev_watchdog+0x22c/0x234
> [  370.017173]  call_timer_fn.constprop.0+0x24/0x80
> [  370.021802]  __run_timers.part.0+0x1f8/0x244
> [  370.026080]  run_timer_softirq+0x3c/0x74
> [  370.030012]  __do_softirq+0x10c/0x280
> [  370.033683]  ____do_softirq+0x10/0x1c
> [  370.037357]  call_on_irq_stack+0x24/0x4c
> [  370.041292]  do_softirq_own_stack+0x1c/0x28
> [  370.045484]  __irq_exit_rcu+0xe4/0x100
> [  370.049244]  irq_exit_rcu+0x10/0x1c
> [  370.052744]  el1_interrupt+0x38/0x68
> [  370.056331]  el1h_64_irq_handler+0x18/0x24
> [  370.060439]  el1h_64_irq+0x64/0x68
> [  370.063851]  cpuidle_enter_state+0x134/0x2e0
> [  370.068133]  cpuidle_enter+0x38/0x50
> [  370.071719]  do_idle+0x1f4/0x264
> [  370.074960]  cpu_startup_entry+0x24/0x2c
> [  370.078895]  secondary_start_kernel+0x130/0x150
> [  370.083440]  __secondary_switched+0xb8/0xbc
> [  370.087634] ---[ end trace 0000000000000000 ]---
> 
> 
> Additionally when hotplugging cables, which might not be a realworld
> scenario I'm also seeing intermittent watchdog timeouts.
> 
> In both scenarios the driver does not recover.
>