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] [day] [month] [year] [list]
Date:	Wed,  7 Oct 2015 19:58:40 +0200 (CEST)
From:	"Timo Sigurdsson" <public_timo.s@...entcreek.de>
To:	maxime.ripard@...e-electrons.com
Cc:	khilman@...nel.org, 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,
	wens@...e.org, tyler.baker@...aro.org, olof@...om.net
Subject: Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

Hi Maxime,

Maxime Ripard schrieb am 07.10.2015 19:49:

> Hi Timo,
> 
> On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote:
>> Hi Kevin,
>> Hi Maxime,
>> 
>> Kevin Hilman schrieb am 07.10.2015 16:36:
>> 
>> > "Timo Sigurdsson" <public_timo.s@...entcreek.de> writes:
>> >> I still think that the lower voltages may be the cause of your problem
>> >> with that specific board, so could you please test the attached patch on
>> >> top of my patch that you first experienced the problem with? Please let 
>> >> us know whether this solves your issue or whether we need to dig deeper.
>> > 
>> > Thanks for the patch.  Looks like it's the OPPs.
>> > 
>> > I went back to next-20150923 and verified it still fails.  Then, I
>> > applied your patch and saw that it boots just fine.
>> 
>> Good. Then we can easily fix this, I guess.
>> 
>> @Maxime: How should we handle this? In its current form, the patch applies
>> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
>> In an earlier discussion, it was said that this can be done, even though it
>> might not be the most elegant approach. But then again, I think it
>> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
>> boards since this is - to my knowledge - the first and only report that an
>> A20 board has stability issues at the lower voltages (although not too many
>> boards use voltage scaling yet).
> 
> If you count only the number of boards, indeed, but if you count the
> number of devices actually used in the field, we cover already a
> significant portion of them.
> 
>> So, would you prefer to keep this as a patch for BananaPi only, or
>> change the dtsi for all A20 devices instead?
> 
> Yeah, we probably can keep that for bananapi only at the moment, and
> try to generalize that afterwards.

Ok.

> 
>> In case we keep it as it is, what is the correct commit to point to as
>> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
>> that's where these voltages were defined. But then again, if we don't
>> change the dtsi, should I point to my regulator patch instead?
> 
> I don't think it fixes anything at this point. We droped your commit
> that was using the A20 OPPs, so in the history so far we don't have
> anything to fix, just enable cpufreq again.

Ok. I'll send a third version of the regulator patch then with the
updated opp included.

Thanks,

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ