2014-03-10 7:25 GMT-07:00 One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>: > On Mon, 10 Mar 2014 01:53:33 +0100 > Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx> wrote: > >> On 03/10/2014 01:41 AM, David Miller wrote: >> > From: Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx> >> > Date: Mon, 10 Mar 2014 01:37:32 +0100 >> > >> >> The mechanism is manual, no automatic way to determine it. >> > >> > We recognize BIOS and ACPI bugs and work around them, by looking at >> > version information and whatnot, so you really can't convince me that >> > something similar can't be done here perhaps in the platform code. >> >> Hmm, if the is a way to determine the version of that particual u-boot >> I'd be happy to exploit that information. > > If there isn't a way for a kernel to determine the U-boot version then > maybe that should get fixed instead. That also solves your problem > because if you can't find the uboot version you know its too old. Once you have fixed how to determine the u-boot version (which BTW, is probably much simpler to determine from user-space by reading from the MTD partition exposing it, and using strings on the binary blob), you are left with the other bootloaders out there which also do not clear the BMCR_PWRDOWN bit of your PHY and will fail booting off the network as well. While I agree that there should be something done to help any OS determine which bootloader version/model it got booted from (ala. x86 with type_of_bootloader), we still need a way to control this policy (auto-suspending the unused Ethernet PHYs) from Linux, regardless of whether the boot program is broken or not. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
