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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Mar 2014 10:28:26 +0000
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	David Miller <davem@...emloft.net>
CC:	rob@...dley.net, andrew@...n.ch, f.fainelli@...il.com,
	netdev@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

On 03/10/2014 03:40 AM, David Miller wrote:
> From: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
> Date: Mon, 10 Mar 2014 01:53:33 +0100
>
>> On 03/10/2014 01:41 AM, David Miller wrote:
>>> From: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
>>> 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. But I honestly doubt that.
>> Compared to u-boot bootloader and kernel interaction, BIOS and ACPI
>> are well-defined protocols.
>>
>> I personally, would prefer everybody should update his broken
>> bootloaders, but that will just not happen.
>
> What you can do is have a test that _perhaps_ covers a "broader than
> reality" list of broken bootloader cases.
>
> Then you have something the bootloader can provide which indicates
> that it has been fixed.

I think we can just pass the workaround responsibility back to the
bootloader. You rejected both easy-to-maintain workarounds for good
reasons, both bootloaders I know of can be fixed by just resuming the
PHY by bootloader commands. Users of this two boards can prepend their
tftpboot commands with an appropriate write to BMCR.

Let's just ignore this for now and wait for a really unfixable
bootloader.

Sebastian


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

Powered by blists - more mailing lists