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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 10 Mar 2014 09:56:49 -0700
From:	Florian Fainelli <>
To:	One Thousand Gnomes <>
Cc:	Sebastian Hesselbarth <>,
	David Miller <>,
	Rob Landley <>, Andrew Lunn <>,
	netdev <>,
	"" <>,
	"" <>
Subject: Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

2014-03-10 7:25 GMT-07:00 One Thousand Gnomes <>:
> On Mon, 10 Mar 2014 01:53:33 +0100
> Sebastian Hesselbarth <> wrote:
>> On 03/10/2014 01:41 AM, David Miller wrote:
>> > From: Sebastian Hesselbarth <>
>> > 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists