Re: [PATCH net-next v2 1/2] dt-bindings: net: adin: document a phy link status inversion property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux