linux-kernel - Re: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via device tree

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:	Thu, 9 Aug 2012 08:40:36 -0500
From:	Matt Sealey <matt@...esi-usa.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Linux ARM Kernel Mailing List 
	<linux-arm-kernel@...ts.infradead.org>,
	Steev Klimaszewski <steev@...esi-usa.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via device tree

On Thu, Aug 9, 2012 at 5:19 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Tue, Aug 07, 2012 at 04:46:18PM -0500, Matt Sealey wrote:
>
> Yay for indentation!  It'd be good to rewrite your DT so you could cut
> down on that, at the minute it's not good for legibility.
>
>> +                                                     sw1_reg: sw1 {
>> +                                                             regulator-min-microvolt = <600000>;
>> +                                                             regulator-max-microvolt = <1375000>;
>> +                                                             regulator-boot-on;
>> +                                                             regulator-always-on;
>> +                                                     };
>
> This and many of your other regulators have voltage ranges specified but
> no consumers which doesn't make sense.  It looks awfully like you've
> just typed in the maximum range supported by the regulator which is most
> likely broken.
>
> You're also specifying both boot_on and always_on which again doesn't
> seem to make a lot of sense - boot_on mainly exists to help autoprobe,
> using it quite this routinely isn't too clever.

The reason they're set like that is legacy - that's how they're set up
in a kernel
(pre-DT) that we know works. Most of those ranges are directly from the Babbage
reference and stay like that in the Babbage DT too - so there's another broken
one nobody noticed. I know what those voltages should be, but we're
leaving that for another patch that restricts the range of voltages
(it works right
now, since there are no consumers, nothing CHANGES the voltages as
configured at U-Boot time, and anything not boot-on is just not listed
in the DT anyway, but some of them really need to stay on)

There are few consumers because the primary ones out there are the display
controllers and USB hubs and some other things. MMC should be a consumer
but since on one board we share two MMC slots with one regulator we don't
want anyone to change the voltage (it breaks spec anyway, since we can't
provide more than 3.15V with FSL's PMIC and it should be 3.3V by default)
and since you can't coordinate between MMC hosts on what the lowest voltage
both cards can support actually is.. having someone change it would be
bad.

-- 
Matt Sealey <matt@...esi-usa.com>
Product Development Analyst, Genesi USA, Inc.
--
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/