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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 26 Feb 2014 11:35:09 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	netdev <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH] net: phy: add suspend_halted module param

2014-02-26 11:10 GMT-08:00 Andrew Lunn <andrew@...n.ch>:
>> > As to the comment from davem about not using a kernel parameter. How
>> > about turning it all around. Put a boolean parameter into DT PHY node
>> > to indicate when it is safe to power down an idle phy?
>>
>> Ah ah, nice try, but I do not think this belongs in DT, this is purely
>> a software issue here, powering up/down the PHY itself works as
>> expected.
>>
>> How about we have this knob a sysfs parameter? This should be easy
>> enough to tweak at runtime and debug in case thing go wrong.
>
> With a kernel parameter i can place it into the bootargs of the chosen
> node in DT. Solves the problem for everybody with a QNAP box. Same
> goes for topkick and any other board which has a broken u-boot. A
> sysfs parameter needs setting from user space, so it is not something
> we can solve within the kernel.

David objected to a module parameter, a kernel parameter is not too
different right?

The only case we need to handle is when the interface is brought down,
suspend_halted=true will also power down the PHY, you reboot into
u-boot, and you attempt a network boot right after that, in that case
the PHY interface is still powered down and this does not work.

That could be worked around by putting the interface up again before
you reboot into u-boot right, that specific logic being gated by
reading the board model. Agreed, you need to duplicate that workaround
in all affected user-space....
-- 
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