linux-kernel - Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

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]

Message-Id: <20150728145752.43F676C81B65@dd34104.kasserver.com>
Date:	Tue, 28 Jul 2015 16:57:52 +0200 (CEST)
From:	"Timo Sigurdsson" <public_timo.s@...entcreek.de>
To:	maxime.ripard@...e-electrons.com
Cc:	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	linux@....linux.org.uk, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-sunxi@...glegroups.com, hdegoede@...hat.com, wens@...e.org
Subject: Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

Hi,

Maxime Ripard schrieb am 28.07.2015 14:55:
>> > I plan to submit this for 4.3.
>>
>> Ok, then I guess we can drop my patch.
> 
> Please don't.

Ok.

> It was used in mainline, and reverted because it was not stable
> enough.

Well, the explanation given was, it was not stable because of the missing
regulator support. I don't know whether anyboady actually ever reported
it wouldn't run fine at 1008MHz with 1.45V. So the actual point should be
whether we wan't voltages that are out of the specified range in the
official kernel. The consensus seems to be no, with good reasons for that.
So, I won't object this.

> There's a lot of things we do differently in mainline, it's one of
> them. If someone can provide an OPP for 1008MHz that is stable for all
> the boards and within the operating limits of the SoC, I'd be totally
> fine with that, but we didn't find it so far.
> 
>> For those who don't want to use that setting, it's easier to
>> limit the maximum in userspace compared to compiling a new device
>> tree blob.
> 
> Except that the kernel should not rely on the userspace to be stable
> and harmless for the hardware. It should just work reliably by itself.

Same as above.

Regards,

Timo
--
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/