On 2023/06/01 22:36, Andrew Lunn wrote: >> But in this case, LINK_ST is also connected to MII_RXLINK pin of >> the MAC module in SoC. MII_RXLINK also expects low-active signal input. >> (though I only wrote about LED, sorry) > > This is why the Commit message should contain the answer to 'Why?'. > The code tells us 'What', but without knowing the 'Why', it is hard to > say if you are doing the right or wrong thing. Yes, then how about this? --- The LINK_ST is active-high by default. This can be inverted by the GE_LNK_STAT_INV_REG register, meaning that link up is indicated by setting LINK_ST low. LINK_ST is not a generic LED signal but a dedicated signal for the link status. So use device specific propery instead of a LED subsystem. --- > O.K. so the signal is also connected to the SoC. Why? This is very > unusual. The MAC does not really care if there is link or not, it just > sends a bitstream to the PHY. phylib will be monitoring the PHY and > when it detects the link is down it will tell the MAC via the > adjust_link callback. > > What SoC is this? PRU in TI Sitara SoC. This is actually a Software MAC controlled by TI firmware. So unusual. Please look at a block diagram in this page: https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU-ICSS_Ethernet.html I don't know why it needs MII_RXLINK signal... --- Atsushi Nemoto
