| Message ID | 20220105031515.29276-1-luizluca@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: dsa: realtek: MDIO interface and RTL8367S | expand |
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@intel.com> > * use dsa_switch_for_each_cpu_port > * mention realtek_smi_{variant,ops} to realtek_{variant,ops} > in commit message > >
> 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? Thanks, Vladimir. OK. I'll make it automatically defined. I dug again into the realtek driver and I might be able to remove that property. There are just a couple of situations that I might select based on chip_id/version. BTW, Should I split the series in two, submitting the already consensus patch? Luiz
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. 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@intel.com> * use dsa_switch_for_each_cpu_port * mention realtek_smi_{variant,ops} to realtek_{variant,ops} in commit message