linux-kernel - Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

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]

Date:	Sat, 8 Mar 2014 11:35:38 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Grant Likely <grant.likely@...aro.org>,
	Philipp Zabel <p.zabel@...gutronix.de>
CC:	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>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	<linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
	<devicetree@...r.kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@....de>
Subject: Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 07/03/14 20:11, Grant Likely wrote:

>>> Any board not using that port can just leave the endpoint disconnected.
>>
>> Hmm I see. I'm against that.
>>
>> I think the SoC dtsi should not contain endpoint node, or even port node
>> (at least usually). It doesn't know how many endpoints, if any, a
>> particular board has. That part should be up to the board dts.
> 
> Why? We have established precedence for unused devices still being in
> the tree. I really see no issue with it.

I'm fine with having ports defined in the SoC dtsi. A port is a physical
thing, a group of pins, for example.

But an endpoint is a description of the other end of a link. To me, a
single endpoint makes no sense, there has to be a pair of endpoints. The
board may need 0 to n endpoints, and the SoC dtsi cannot know how many
are needed.

If the SoC dtsi defines a single endpoint for a port, and the board
needs to use two endpoints for that port, it gets really messy: one
endpoint is defined in the SoC dtsi, and used in the board dts. The
second endpoint for the same port needs to be defined separately in the
board file. I.e. something like:

/* the first ep */
&port1_ep {
	remote-endpoint = <&..>;
};

&port1 {
	/* the second ep */
	endpoint@2 {
		remote-endpoint = <&..>;
	};
};

Versus:

&port1 {
	/* the first ep */
	endpoint@1 {
		remote-endpoint = <&..>;
	};

	/* the second ep */
	endpoint@2 {
		remote-endpoint = <&..>;
	};
};

 Tomi



Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)