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, 12 Sep 2012 12:47:12 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Daniel Mack <zonque@...il.com>
CC:	devicetree-discuss@...ts.ozlabs.org, lrg@...com,
	broonie@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] regulator: gpio-regulator: add DT bindings

On 09/12/2012 02:57 AM, Daniel Mack wrote:
> On 10.09.2012 21:40, Stephen Warren wrote:
>> On 09/10/2012 09:03 AM, Daniel Mack wrote:
>>> Add DT bindings for the gpio-regulator driver and some documentation on
>>> how to use it.
...
>>> +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
...
>>> +	- "gpios":		bitfield of gpio target-states for the value
>>> +				The n-th bit in the bitfield describes the
>>> +				state of the n-th GPIO from the gpios-array
>>
>> "gpios" sounds like the name of a property that defines which GPIOs are
>> used, rather than the value of those GPIOs. Perhaps "gpio-values" instead?
>>
>> Actually, I wonder if we really even need to represent that values
>> explicitly; rather than have a big set of nodes, perhaps you can instead
>> have a single property that lists the voltage (or current) that each
>> combination of GPIO values gives; something like:
>>
>> reg_gpio {
>>     ...
>>     gpios = <&ggpio 23 0 &gpio 24 0>;
>>     voltages = <0 1000000 2000000 3000000>;
>> };
>>
>> (As inspiration for that, I looked at
>> Documentation/devicetree/bindings/net/mdio-mux-gpio.txt which doesn't
>> have a property defining the value of the GPIOs for each combination,
>> but rather a node per valid combination).
>>
>> Perhaps represent and invalid GPIO combination with 0xffffffff?
> 
> Sorry, I don't follow you on this one. How would you specify the
> voltages that way? And The driver allows for arbitrary GPIO patterns to
> be set on the GPIOs in order to reach a specific voltage. Could you give
> me another example how that would look like in your approach?
> 
> Once that topic is agreed on, I'll send out a new version.

The idea is that you treat the GPIOs as an array of bits. so, two
entries in the gpios property and you've got two bits in your values.
Use that value as the index into the "voltages" property. For each
combination of GPIO values, you have an entry in "voltages" that
indicates what voltage will be produced. This is much more compact than
having a node per setting, but perhaps is more wordy if the subset of
legal GPIO value is much more sparse than all possible 2^n GPIO values.

Put another way,

GPIO0=0, GPIO1=0 -> index 0 -> voltage 0 in the example above
GPIO0=0, GPIO1=1 -> index 1 -> voltage 1000000 in the example above
GPIO0=1, GPIO1=0 -> index 2 -> voltage 2000000 in the example above
GPIO0=1, GPIO1=1 -> index 3 -> voltage 3000000 in the example above
--
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