Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751797AbaK1Oi2 (ORCPT ); Fri, 28 Nov 2014 09:38:28 -0500 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:36919 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751648AbaK1Oi0 (ORCPT ); Fri, 28 Nov 2014 09:38:26 -0500 Date: Fri, 28 Nov 2014 14:38:23 +0000 From: Mark Rutland To: Jacek Anaszewski Cc: "linux-leds@vger.kernel.org" , "linux-media@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kyungmin.park@samsung.com" , "b.zolnierkie@samsung.com" , "pavel@ucw.cz" , "cooloney@gmail.com" , "rpurdie@rpsys.net" , "sakari.ailus@iki.fi" , "s.nawrocki@samsung.com" , Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" Subject: Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property Message-ID: <20141128143823.GJ25883@leverpostej> References: <1417166286-27685-1-git-send-email-j.anaszewski@samsung.com> <1417166286-27685-9-git-send-email-j.anaszewski@samsung.com> <20141128111404.GB25883@leverpostej> <547865EA.5010700@samsung.com> <20141128123003.GE25883@leverpostej> <54788278.7080101@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54788278.7080101@samsung.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > >>>> Acked-by: Kyungmin Park > >>>> Cc: Sylwester Nawrocki > >>>> Cc: Rob Herring > >>>> Cc: Pawel Moll > >>>> Cc: Mark Rutland > >>>> Cc: Ian Campbell > >>>> Cc: Kumar Gala > >>>> Cc: > >>>> --- > >>>> .../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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/