Hi Roelof,
You are correct that "Auto-detection" from the MAC_CR does not have anything to
do with the PHY Auto-negotiation or with access to the PHY's registers being
done by the MAC over MDIO. Auto-detection just a way for the MAC to
automatically set it's speed and duplex mode, determined by ***passively***
looking at standard Rx RGMII signals and at the state (high or low) of a
non-standard (but often available - think of a signal driving a duplex LED
coming from a real PHY) "duplex" signal. As you said when using this feature
the driver/MCU does not need to do any register access (except maybe a one-time
init write to ADP in MAC_CR) to keep the LAN7431 MAC in sync with whatever
speed/duplex the PHY is operating at.
Regarding your conclusions:
ASD should be pretty safe to use all the time I think, because in all
implementations you use a LAN7431 you will always have the standard RGMII Rx
signals coming in, so the speed detection should always be accurate.
ADD is not a given will be usable in all implementations though, it relies on
the existence of a signal you can input into the LAN7431 that will accurately
tell it what the current duplex is (0/1<->half/full; or 0/1<->full/half does
not matter, polarity is configurable). This is not a standard signal so it may
not be available.
I'd say there are three cases:
- If the duplex mode is permanently fixed in your design, you can use
ADD: just tie the duplex pin of LAN7431 (i.e.: Keep the ADP =1 default in
MAC_CR; tie the pin low if half duplex, tie the pin high if full duplex)
- If your duplex mode can change and you have a signal like this
available in your design you can use ADD, just connect that signal to the
duplex pin of LAN7431 and configure the proper ADP for the signal polarity in
MAC_CR
- If your duplex mode can change and you don’t have a signal like this
available in your design you cannot use ADD.
Hope this helps.
Regards,
Ronnie
-----Original Message-----
From: Roelof Berg <[email protected]>
Sent: Tuesday, May 19, 2020 12:43 PM
To: Andrew Lunn <[email protected]>
Cc: Bryan Whitehead - C21958 <[email protected]>; UNGLinuxDriver
<[email protected]>; David S. Miller <[email protected]>;
[email protected]; [email protected]
Subject: Re: [PATCH] lan743x: Added fixed link support
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
Hi Andrew,
thank you for the example, your input got me further. Sorry if my e-mails made
the impression that the MAC is sending MDIO on its own. It can issue MDIO but I
assume it will do this only on request of the MCU.
I read the data sheets again and found what might have confused us. There is:
a) Auto Negotiation (Phy-Phy)
b) Automatic Speed Detection, ASD (Mac-Phy)
c) Automatic Duplex Detection, ADD (Mac-Phy)
My current hypothesis is: When Phy-Phy auto negotiation is done, the ASD and
ADD of the MAC will implicitly catch up the new mode of the Phy on a low level
(clocks, pins). A dumb silicon would need the MCU to re-configure the MAC after
MDIO told the MCU about a change in the Phy mode. But this ultra smart silicon
would neither need MDIO, nor an MCU to understand what’s going on on the busses
:)
If this hypothesis is correct, I should change in the driver all comments that
mention „auto negoriation“ to „ADD, ASD“, and future readers will not be
confused anymore.
Conclusion:
- Maybe I can leave ASD and ADD even active in fixed-link scenarios, when in
the device tree an empty fixed-link node is present.
- And I need to disable ASD and/or ADD only if speed and/or duplex is
configured inside the fixed-link mode.
I need to verify this hypothesis.
Thank you for reviewing and sharing topics we need to consider, Roelof
> Am 18.05.2020 um 22:34 schrieb Andrew Lunn <[email protected]>:
>
>> I double checked the vendor documentation and according to the data
>> sheet in this device the MAC detects speed and duplex mode. It uses
>> PINs, traces clocks … Also according to an application note of the
>> vendor duplex and speed detection should be enabled in the MAC
>> registers.
>
> In general, the MAC should not perform MDIO requests on the PHY. The
> MAC has no access to the mutex which phylib users. So if the MAC
> directly accesses registers in the PHY, it could do it at the wrong
> time, when the PHY driver is active.
>
> This can be particularly bad when Marvell PHYs are used. They have
> paged registers. One example is the page with the temperature sensor.
> This can be selected due to a read on the hwmon device. If the MAC
> tried to read the speed/duplex which the temperature sensor is
> selected, it would wrongly read the temperature sensor registers, not
> the link state.
>
> There is no need for the MAC to directly access the PHY. It will get
> told what the result of auto-neg is. So please turn this off all the
> time.
>
> Andrew
>
