On Fri, Nov 28, 2014 at 02:11:04PM +0000, Jacek Anaszewski wrote: > On 11/28/2014 01:30 PM, Mark Rutland wrote: > > On Fri, Nov 28, 2014 at 12:09:14PM +0000, Jacek Anaszewski wrote: > >> On 11/28/2014 12:14 PM, Mark Rutland wrote: > >>> On Fri, Nov 28, 2014 at 09:18:00AM +0000, Jacek Anaszewski wrote: > >>>> This patch adds a description of 'flashes' property > >>>> to the samsung-fimc.txt. > >>>> > >>>> Signed-off-by: Jacek Anaszewski <j.anaszewski@xxxxxxxxxxx> > >>>> Acked-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> > >>>> Cc: Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx> > >>>> Cc: Rob Herring <robh+dt@xxxxxxxxxx> > >>>> Cc: Pawel Moll <pawel.moll@xxxxxxx> > >>>> Cc: Mark Rutland <mark.rutland@xxxxxxx> > >>>> Cc: Ian Campbell <ijc+devicetree@xxxxxxxxxxxxxx> > >>>> Cc: Kumar Gala <galak@xxxxxxxxxxxxxx> > >>>> Cc: <devicetree@xxxxxxxxxxxxxxx> > >>>> --- > >>>> .../devicetree/bindings/media/samsung-fimc.txt | 7 +++++++ > >>>> 1 file changed, 7 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt > >>>> index 922d6f8..4b7ed03 100644 > >>>> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt > >>>> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt > >>>> @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated > >>>> and the port B deactivated and for the state "active-b" it should be the other > >>>> way around. > >>>> > >>>> +Optional properties: > >>>> + > >>>> +- flashes - array of strings with flash led names; the name has to > >>>> + be same with the related led label > >>>> + (see Documentation/devicetree/bindings/leds/common.txt) > >>>> + > >>> > >>> Why is this not an array of phandles to the LED nodes? That's much > >>> better than strings. > >> > >> This is because a single flash led device can control many sub-leds, > >> which are represented by child nodes in the Device Tree. > >> Every sub-led is registered as a separate LED Flash class device > >> in the LED subsystem, but in fact they share the same struct device > >> and thus have access only to the parent's phandle. > > > > But that's a Linux infrastrcture issue, no? You don't have to use the > > node from the struct device to find the relevant phandle. > > Right. > > >> The LED Flash > >> class devices are wrapped by V4L2 sub-devices and register > >> asynchronously within a media device. Since the v4l2_subdev structure > >> has a 'name' field, it is convenient to initialize it with > >> parsed 'label' property of a child led node and match the > >> sub-devices in the media device basing on it. > > > > While that might be convenient, I don't think it's fantastic to use that > > to describe the relationship, as this leaks Linux internals (e.g. I can > > refer to a name that doesn't exist in the DT but happens to be what > > Linux used, and it would work). Also, are the labels guaranteed to be > > globally unique? > > The labels are used for initializing class device name and kernel > doesn't allow to initialize two devices with same names. > This implies that labels are guaranteed to be globally unique. On Linux, yes, but that's an implementation detail, not a property of the binding· Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
