linux-kernel - Re: [PATCH v5 10/10] net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170911161124.GD27599@lunn.ch>
Date:   Mon, 11 Sep 2017 18:11:24 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Corentin Labbe <clabbe.montjoie@...il.com>
Cc:     robh+dt@...nel.org, mark.rutland@....com,
        maxime.ripard@...e-electrons.com, wens@...e.org,
        linux@...linux.org.uk, catalin.marinas@....com,
        will.deacon@....com, peppe.cavallaro@...com,
        alexandre.torgue@...com, f.fainelli@...il.com,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 10/10] net: stmmac: dwmac-sun8i: Handle
 integrated/external MDIOs

On Fri, Sep 08, 2017 at 04:28:25PM +0200, Corentin Labbe wrote:
> On Fri, Sep 08, 2017 at 04:17:36PM +0200, Andrew Lunn wrote:
> > > > Do you know why the reset times out/fails?
> > > > 
> > > 
> > > Because there are nothing connected to it.
> > 
> > That should not be an issue. A read should just return 0xffff.  And it
> > should return 0xffff fast. The timing of the MDIO protocol is fixed. A
> > read or a write takes a fixed number of cycles, independent of if
> > there is a device there or not. The bus data line has a pullup, so if
> > you try to access a missing device, you automatically read 0xffff.
> > 
> 
> Perhaps, but the reality is that with nothing connected to it, the reset of the MAC timeout.
> Certainly, the MAC does not support finding no PHY.

Are you sure this is not because of the clock and reset?

+                               #address-cells = <1>;
+                               #size-cells = <0>;
+                               int_mii_phy: ethernet-phy@1 {
+                                       compatible = "ethernet-phy-ieee802.3-c22";
+                                       reg = <1>;
+                                       clocks = <&ccu CLK_BUS_EPHY>;
+                                       resets = <&ccu RST_BUS_EPHY>;

The way you describe it here, the clock and reset are for the PHY. But
maybe it is actually for the bus? I can understand a bus timing out if
it has no clock, or it is held in reset. Try enabling the clock and
reset when the internal bus is selected, not when the PHY on the bus
is selected.

	Andrew