Thread (59 messages) flat view 59 messages, 9 authors, 2008-08-29

Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver

From: Grant Likely <hidden>
Date: 2008-07-17 20:50:13
Also in: lkml

On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
On Thu, 17 Jul 2008, Grant Likely wrote:
quoted
Alternately, I would also be okay with a scheme where all LED nodes
have a common parent and an of_platform driver would bind against the
parent node; not the individual children.  Then the leds-gpio driver
could be refactored to have both platform and of_platform bus
bindings.
Basically what I did then in my patch then, refactor leds-gpio so most of
it is shared and there is a block of code that does platform binding and
another block that does of_platform binding.
Yes
I didn't change the OF platform binding syntax so as not to complicate the
example, but that's easy to do.  Something like:

leds {
 	compatible = "gpio-led";
 	gpios = <&mpc8572 6 0
 	         &mpc8572 7 0>;
 	labels = "red", "green";
};

Or like this, which needs a little more code to parse:

leds {
 	compatible = "gpio-led";
 	led@6 {
 		gpios = <&mpc8572 6 0>;
 		label = "red";
 	};
 	led@7 {
 		gpios = <&mpc8572 7 0>;
 		label = "green";
 	};
};
I kind of like the second option better, because there is less chance
of doing bad stuff if the gpio specifier was buggered up; but I'm cool
with either.

However, if the second option is chosen then something like the following
might be better as it eliminates the meaningless @<number> specifier.

leds {
	compatible = "gpio-led";
	red {
		gpios = <&mpc8572 6 0>;
	};
	green {
		gpios = <&mpc8572 7 0>;
	};
};

Cheers,
g.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help