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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <55FDCC7F.10601@gmail.com>
Date:	Sat, 19 Sep 2015 13:58:39 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Phil Reid <preid@...ctromag.com.au>, netdev@...r.kernel.org,
	Andrew Lunn <andrew@...n.ch>
Subject: Re: rfi: stmmac: creating an of mdio bus for attached dsa

+Andrew,

Le 09/18/15 00:26, Phil Reid a écrit :
> G'day All,
> 
> Prior to submitting a patch I'd just like to get an idea on what the
> correct way is to create and register an mdio bus for use by the marvell
> dsa driver.
> On our system the cpu ethernet port is connected directly to a switch
> with a fixed link (1Gbit).
> So the driver needs to create and persist the mdio bus for the dsa
> driver using of_mdiobus_register.
> The trunk stmmac driver currently doesn't create the mdio bus if a fixed
> link is found.
> stmmac_probe_config_dt does hte following check.
>     if (plat->phy_node || plat->phy_bus_name)
>         plat->mdio_bus_data = NULL;
> phy_node is set because a fixed-link is found above and setting
> mdio_bus_data to null skips mdio bus creation.
> removing the phy_node check gets things working.

It seems to me like you should have the stmmac driver always register
its MDIO bus driver, whether or not it will end-up being used depends on
the information provided via OF/platform_data.

Even in topologies where a stmmac block is unused, you would expect
power/clock gating to be applied for the Ethernet MAC, but still have
the ability to use the MDIO bus of this stmmac instance if it connects
to a particular device. In your case, I would assume that the stmmac
Ethernet MAC and MDIO will be used, so this make even more sense.

> 
> I've also modified stmmac_mdio_register to use of_mdiobus_register and
> setup the dt to probe for a phy (that doesn't really exist, the switch
> is on the mdio).
> This cause a fair bit of log spamming but does seem to work as the
> switch is detected.
> eg: eth0: PHY ID 00000000 at 27 IRQ POLL (stmmac-0:1b)
> Currently if no phy is found the mdio bus gets de registered so this
> seems to be required.
> 
> In summary what is the correct way to make sure the mdio bus stays
> registered when a fixed-link is in use?
> Am I configuring the link to the switch incorrectly?

This seems reasonable to me. One of the problems with DSA right now is
that you need to provide a fixed-link emulated PHY for your Ethernet MAC
controller to keep "working" (that is: get link status/parameters etc.),
while the switch sits on the MDIO bus and does not look like (yet) a PHY
device.

The "problem" here is that the STMMAC driver treats fixed link as there
is no MDIO device connected here, so why bother with registering a MDIO
bus driver in the first place, which is a valid design shortcut, but not
in the case of DSA right now.

In the future, I hope we can have DSA switch devices look like almost
regular PHY devices, such that we do not have to use the fixed PHY to
keep having the Ethernet MAC controller be happy with link parameters
to/from the switch, see [1].

[1]: https://lwn.net/Articles/643149/
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ