[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181211224436.GA27976@amd>
Date: Tue, 11 Dec 2018 23:44:37 +0100
From: Pavel Machek <pavel@....cz>
To: Rob Herring <robh@...nel.org>
Cc: Jacek Anaszewski <jacek.anaszewski@...il.com>,
Linux LED Subsystem <linux-leds@...r.kernel.org>,
devicetree@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Baolin Wang <baolin.wang@...aro.org>,
Daniel Mack <daniel@...que.org>, Dan Murphy <dmurphy@...com>,
Linus Walleij <linus.walleij@...aro.org>,
Oleh Kravchenko <oleg@....org.ua>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Simon Shields <simon@...eageos.org>
Subject: Re: [PATCH 04/24] dt-bindings: leds: Add function and color
properties
Hi!
> > >> Basically every single device could have a LED associated with it
> > >> ("activity"). Would doing it like this mean we'd have to modify every
> > >> single driver to parse leds / led-names properties?
> > >
> > > Normally, that's how properties like this would work. A driver is also
> > > what knows how the leds should function.
> >
> > This is not true in case of associations where LED controller is
> > an independent device, as in Pavel's example [0].
>
> I'm not really following how the HDD example is different. The parent
> of an LED would be the controller. The link to the led node would be
> in the disk controller node. Though maybe if things get complicated
> enough, we'd want to describe the drives or drive bays in DT.
We were talking case where the LED is on GPIO somewhere. And yes,
drive bays would be similar.
And.. often you have a single LED for multiple harddrives, too. Fun
:-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists