linux-kernel - Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141128143823.GJ25883@leverpostej>
Date:	Fri, 28 Nov 2014 14:38:23 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Jacek Anaszewski <j.anaszewski@...sung.com>
Cc:	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kyungmin.park@...sung.com" <kyungmin.park@...sung.com>,
	"b.zolnierkie@...sung.com" <b.zolnierkie@...sung.com>,
	"pavel@....cz" <pavel@....cz>,
	"cooloney@...il.com" <cooloney@...il.com>,
	"rpurdie@...ys.net" <rpurdie@...ys.net>,
	"sakari.ailus@....fi" <sakari.ailus@....fi>,
	"s.nawrocki@...sung.com" <s.nawrocki@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is
 'flashes' property

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@...sung.com>
> >>>> Acked-by: Kyungmin Park <kyungmin.park@...sung.com>
> >>>> Cc: Sylwester Nawrocki <s.nawrocki@...sung.com>
> >>>> Cc: Rob Herring <robh+dt@...nel.org>
> >>>> Cc: Pawel Moll <pawel.moll@....com>
> >>>> Cc: Mark Rutland <mark.rutland@....com>
> >>>> Cc: Ian Campbell <ijc+devicetree@...lion.org.uk>
> >>>> Cc: Kumar Gala <galak@...eaurora.org>
> >>>> Cc: <devicetree@...r.kernel.org>
> >>>> ---
> >>>>    .../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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/