Re: SoCFPGA ethernet broken

From: David Daney
Date: Thu Dec 03 2015 - 16:24:09 EST


On 12/03/2015 12:48 PM, Pavel Machek wrote:
On Thu 2015-10-15 13:25:59, Florian Fainelli wrote:
On 15/10/15 12:59, Dinh Nguyen wrote:
On 10/15/2015 03:03 PM, Florian Fainelli wrote:
On 15/10/15 12:09, Dinh Nguyen wrote:
Hi,

commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
the bus' parent." seems to have broken ethernet support for the SoCFPGA
platform which is using the stmmac ethernet driver.

It is not clear to me how this relates to what you are seeing yet.


It appears that during DHCP, it cannot get an IP address. This only
happens if ethernet was not used by the bootloader to tftp an kernel
image. If I use the bootloader to tftp an image then ethernet is working
fine. So I think the PHY is not getting enabled properly.

If I revert this patch, then ethernet is back to working on the platform.

Is the Device Tree source for this platform available somewhere to look at?


Yes, I'm using the DTS that is in the mainline:

arch/arm/boot/dts/socfpga.dtsi
arch/arm/boot/dts/socfpga_cyclone5.dtsi
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts

There are no PHY devices in any of these DTS files, instead there is the
non-standard "phy-addr" property which is set to 0xffffffff supposedly
to indicate that the MDIO bus should be scanned. This is likely part of
your problem. The stmmac driver seems to be looking for "snps,phy-addr"
and not "phy-addr", so I am not even clear how this is supposed to work,
and the driver mentions this custom property is deprecated anyway.

The core problem is in
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c::stmmac_mdio_register
which manually detects the PHY, that is mostly fine, except that it does
not really seem to work here for a reason that is still unclear to me.

Your Ethernet PHYs need to be declared in Device Tree, see
Documentation/devicetree/bindings/net/phy.txt

While updating DTS might be good idea, I don't think you can simply
blame this on DTS. If it worked before the change, it is supposed to
work after the change, otherwise we call that change a "regression"
and revert the change.

FWIW: My initial patch to address the failure worked with the original DTB.

Also: userspace wasn't broken. So, the commandment about not breaking userspace wasn't broken. Although admittedly, breaking the kernel isn't good either.




Plus, DTS is supposed to be ABI. Old DTS should still work on new
kernels in ideal world.

If you supply the device tree file in the kernel tree, it is not an ABI.

If the device tree is not part of the kernel, and instead comes from the boot firmware of the board, then you could make the ABI claim.

David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/