linux-kernel - Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

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: <20140321114735.3E132C4052A@trevor.secretlab.ca>
Date:	Fri, 21 Mar 2014 11:47:35 +0000
From:	Grant Likely <grant.likely@...aro.org>
To:	Andrzej Hajda <a.hajda@...sung.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	Philipp Zabel <p.zabel@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Rob Herring <robherring2@...il.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Philipp Zabel <philipp.zabel@...il.com>
Subject: Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On Fri, 21 Mar 2014 11:44:24 +0100, Andrzej Hajda <a.hajda@...sung.com> wrote:
> On 03/20/2014 06:23 PM, Grant Likely wrote:
> > On Tue, 11 Mar 2014 14:16:37 +0100, Laurent Pinchart <laurent.pinchart@...asonboard.com> wrote:
> >> On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote:
> >>> So depending on the use case, the endpoints would point to opposite
> >>> direction from the encoder's point of view.
> >>>
> >>> And if I gathered Grant's opinion correctly (correct me if I'm wrong),
> >>> he thinks things should be explicit, i.e. the bindings for, say, an
> >>> encoder should state that the encoder's output endpoint _must_ contain a
> >>> remote-endpoint property, whereas the encoder's input endpoint _must
> >>> not_ contain a remote-endpoint property.
> >>
> >> Actually my understand was that DT links would have the same direction as the 
> >> data flow. There would be no ambiguity in that case as the direction of the 
> >> data flow is known. What happens for bidirectional data flows still need to be 
> >> discussed though. And if we want to use the of-graph bindings to describe 
> >> graphs without a data flow, a decision will need to be taken there too.
> > 
> > On further thinking, I would say linkage direction should be in the
> > direction that would be considered the dependency order... I'm going to
> > soften my position though. I think the generic pattern should still
> > recommend unidirection links in direction of device dependency, but
> 
> I am not sure what you mean by 'device dependency' but I am sure it will
> not be difficult to present problematic cases, maybe circular
> dependencies, two-way dependencies, etc.

My understanding has been that the link data would be used determine
when the controller driver can be brought up and active. Certainly both
sides of a link need to be 'live' before the link can be used. The
kernel must have a way to resolve the question of "who starts first?",
whether it be the situation of the consumer starts before the producer,
or the situation of two components need to start before the controller
driver can start. That is the dependency chain I'm talking about.

> The only problem of unidirectional links from programming point of view
> is that destination port/interface should be exposed using some
> framework and driver of source link should grab it using the same
> framework, using port/endpoint node for identification. In case of
> bi-directional links the same process should happen but DT do not
> dictates who should expose and who grabs.
> 
> So from programming point of view it should be easy to handle
> unidirectional links regardless of the direction. So I guess the best
> is to use data flow direction as it seems to be the most natural.

right.

> 
> 
> > I'm okay with allowing the bidirection option if the helper functions
> > are modified to validate the target endpoint. I think it needs to test
> > for the following:
> > - Make sure the endpoint either:
> >   - does not have a backlink, or
> >   - the backlink points back to the origin node
> > - If the target is an endpoint node, then make sure the parent doesn't
> >   have a link of any kind
> > - If the target is a port node, make sure it doesn't have any endpoint
> >   children nodes at all.
> 
> I think link validation can be done at dts compile time.

I'm firm on the opinion that the checking must also happen at runtime.
The biggest part of my objection has been how easy it would be to get a
linkage out of sync, and dtc is not necessarily the last tool to touch
the dtb before the kernel gets booted. I want the kernel to flat out
reject any linkage that is improperly formed.

g.

> 
> Regards
> Andrzej
> 
> > 
> > g.
> > 
> > 
> 

--
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/