On 2023/06/01 23:45, Andrew Lunn wrote: > We are now getting close to having all the pieces of the puzzle to > decide if this is the right or wrong way to do this. > > This appears to be the 'Vendor Crap' driver. You are patching mainline > here, so it is the mainline PRU driver we care about: > > https://lore.kernel.org/netdev/20230424053233.2338782-1-danishanwar@xxxxxx/T/ > > Looking at the device tree binding, it uses the standard phy-handle, > phy-mode properties. There is also emac_adjust_link() which is used by > phylib to tell the MAC driver the link is down. > > So you now need to convince me this change is actually needed in > mainline. Looking for purpose of MII_RXLINK signal, it seems like just for EtherCAT's "enhanced link detection" feature. refer: https://software-dl.ti.com/processor-industrial-sw/esd/docs/indsw/EtherCAT_Slave/PRU_ICSS_EtherCAT_firmware_API_guide.html#pru-icss-mdio-host-side-apis So maybe standard linux driver can ignore this. Then, what really needed is controlling just an LED, i.e. could be done using the LED subsystem as your advice. I will try it if I use this combination of devices in the future. Please drop this patch series for now. --- Atsushi Nemoto
