Message-ID: <20220120143630.rimb2y74h2hxueg5@skbuf>
Date:   Thu, 20 Jan 2022 16:36:30 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Luiz Angelo Daros de Luca <luizluca@...il.com>
Cc:     netdev@...r.kernel.org, linus.walleij@...aro.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        alsi@...g-olufsen.dk, arinc.unal@...nc9.com,
        frank-w@...lic-files.de
Subject: Re: [PATCH net-next v4 00/11] net: dsa: realtek: MDIO interface and
 RTL8367S

On Wed, Jan 05, 2022 at 12:15:04AM -0300, Luiz Angelo Daros de Luca wrote:
> The old realtek-smi driver was linking subdrivers into a single
> realtek-smi.ko After this series, each subdriver will be an independent
> module required by either realtek-smi (platform driver) or the new
> realtek-mdio (mdio driver). Both interface drivers (SMI or MDIO) are
> independent, and they might even work side-by-side, although it will be
> difficult to find such device. The subdriver can be individually
> selected but only at buildtime, saving some storage space for custom
> embedded systems.
> 
> Existing realtek-smi devices continue to work untouched during the
> tests. The realtek-smi was moved into a realtek subdirectory, but it
> normally does not break things.
> 
> I couldn't identify a fixed relation between port numbers (0..9) and
> external interfaces (0..2), and I'm not sure if it is fixed for each
> chip version or a device configuration. Until there is more info about
> it, there is a new port property "realtek,ext-int" that can inform the
> external interface.

Generally it isn't a good idea to put in the device tree things that you
don't understand. The reason being that you'd have to support those
device tree bindings even when you do understand those things. A device
tree blob has a separate lifetime compared to the kernel image, so a new
kernel image would have to support the device trees in circulation which
have this realtek,ext-int property.

Can you use a fixed relationship between the port number and the
external interface in the driver, until it is proven that this info
cannot be known statically or by reading some device configuration?

> The rtl8365mb might now handle multiple CPU ports and extint ports not
> used as CPU ports. RTL8367S has an SGMII external interface, but my test
> device (TP-Link Archer C5v4) uses only the second RGMII interface. We
> need a test device with more external ports to test these features.
> The driver still cannot handle SGMII ports.
> 
> The rtl8365mb was tested with a MDIO-connected RTL8367S (TP-Link Acher
> C5v4) and a SMI-connected RTL8365MB-VC switch (Asus RT-AC88U)
> 
> The rtl8366rb subdriver was not tested with this patch series, but it
> was only slightly touched. It would be nice to test it, especially in an
> MDIO-connected switch.
> 
> Best,
> 
> Luiz
> 
> Changelog:
> 
> v1-v2)
> - formatting fixes
> - dropped the rtl8365mb->rtl8367c rename
> - other suggestions
> 	
> v2-v3)
> * realtek-mdio.c:
>   - cleanup realtek-mdio.c (BUG_ON, comments and includes)   
>   - check devm_regmap_init return code
>   - removed realtek,rtl8366s string from realtek-mdio
> * realtek-smi.c:
>   - removed void* type cast
> * rtl8365mb.c:
>   - using macros to identify EXT interfaces
>   - rename some extra extport->extint cases
>   - allow extint as non cpu (not tested)
>   - allow multple cpu ports (not tested)
>   - dropped cpu info from struct rtl8365mb
> * dropped dt-bindings changes (dealing outside this series)
> * formatting issues fixed
> 
> v3-v4)
> * fix cover message numbering 0/13 -> 0/11
> * use static for realtek_mdio_read_reg
>   - Reported-by: kernel test robot <lkp@...el.com>
> * use dsa_switch_for_each_cpu_port
> * mention realtek_smi_{variant,ops} to realtek_{variant,ops}
>   in commit message
> 
> 

Powered by blists - more mailing lists