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
| ||
|
Date: Sat, 17 Nov 2012 13:04:00 +0900 From: Alexandre Courbot <acourbot@...dia.com> To: Mark Rutland <mark.rutland@....com> Cc: Anton Vorontsov <cbouatmailru@...il.com>, Stephen Warren <swarren@...dia.com>, Thierry Reding <thierry.reding@...onic-design.de>, Mark Zhang <markz@...dia.com>, Grant Likely <grant.likely@...retlab.ca>, "rob.herring@...xeda.com" <rob.herring@...xeda.com>, Mark Brown <broonie@...nsource.wolfsonmicro.com>, David Woodhouse <dwmw2@...radead.org>, Arnd Bergmann <arnd@...db.de>, "linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>, "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>, Leela Krishna Amudala <l.krishna@...sung.com>, "devicetree-discuss@...ts.ozlabs.org" <devicetree-discuss@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org> Subject: Re: [PATCH v8 1/3] Runtime Interpreted Power Sequences Hi Mark, On Fri, Nov 16, 2012 at 7:35 PM, Mark Rutland <mark.rutland@....com> wrote: > Given there are several ARM platforms that may have an interest in this, please > consider posting this to the ARM mailing list: > linux-arm-kernel@...ts.infradead.org. That's right. New revision on the way. >> +Similarly, each power sequence declares its steps as sub-nodes of itself. Steps >> +must be named sequentially, with the first step named step0, the second step1, >> +etc. Failure to follow this rule will result in a parsing error. > > Could we not encode the step number in the unit-address? i.e. step@N rather than > stepN. That was the way I did it initially, but it has been pointed out that doing so would require to have #address-cells and #size-cells in every power sequence, as well as a "reg" property in every step (see https://lkml.org/lkml/2012/7/31/454 ). Although I'd prefer to use the @ notation too (and neither dtc nor the kernel complained when I did it), I tend to think the current solution is less burdensome than having these redundant properties. >> +"gpio" type required properties: >> + - gpio: phandle of the GPIO to use. >> + - value: value this GPIO should take. Must be 0 or 1. > > Is there any reason for id to be a name rather than a phandle? It seems > inconsistent with the gpio case. That's another long story. But to make it short, I'd like to make it possible for power sequences to be referenced and shared between devices of the same type (as everybody knows, copy/pasting is bad). If we use phandles in steps, the power sequence becomes tied to the referred resources and thus cannot be shared with another instance of the same device. On the other hand, using an identifier that is resolved at runtime (through e.g. regulator_get(device *, char *) leverages the existing frameworks and makes things more flexible. GPIO is currently the exception. It is the only framework for which you cannot currently resolve a resource from a device and an identifier. So at the moment we have to use a phandle - but we are also working with Linus Walleij to provide an alternative GPIO API that will be more like what we have for regulators/pinctrl/PWM/etc. Another problem with phandles is that some of the functions that resolve them are not publicly exported (i.e. AFAIK there is no public function that returns a regulator from a phandle - the only to obtain one is through regulator_get) > I also see from the example below that the gpio property is not just a phandle, > as it has the gpio-specifier appended. Is there a better way of describing this > format in the documentation? This is already clearly be defined in Documentation/devicetree/bindings/gpio/, isn't it? Thanks, Alex. -- 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