All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roelof Berg <rberg@berg-solutions.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Bryan Whitehead <bryan.whitehead@microchip.com>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lan743x: Added fixed link support
Date: Tue, 19 May 2020 18:42:33 +0200	[thread overview]
Message-ID: <F241F806-3A08-4086-9739-361538FD246B@berg-solutions.de> (raw)
In-Reply-To: <20200518203447.GF624248@lunn.ch>

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 <andrew@lunn.ch>:
> 
>> 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
> 


  reply	other threads:[~2020-05-19 16:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16 19:24 [PATCH] lan743x: Added fixed link support Roelof Berg
2020-05-17 18:37 ` Andrew Lunn
2020-05-17 20:44   ` Roelof Berg
2020-05-17 23:50     ` Andrew Lunn
2020-05-18 19:31       ` Roelof Berg
2020-05-18 20:34         ` Andrew Lunn
2020-05-19 16:42           ` Roelof Berg [this message]
2020-05-19 22:06             ` Ronnie.Kunin
2020-05-18 20:53     ` Bryan.Whitehead
2020-05-18 20:01   ` Roelof Berg
  -- strict thread matches above, loose matches on Subject: below --
2020-05-20 17:10 Roelof Berg
2020-05-21 14:04 ` Andrew Lunn
2020-05-13 19:06 Roelof Berg
2020-05-13 19:17 ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F241F806-3A08-4086-9739-361538FD246B@berg-solutions.de \
    --to=rberg@berg-solutions.de \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=bryan.whitehead@microchip.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.