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:	Thu, 27 Feb 2014 10:08:52 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Philipp Zabel <p.zabel@...gutronix.de>
CC:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Grant Likely <grant.likely@...aro.org>,
	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 26/02/14 17:47, Philipp Zabel wrote:

> Ok, that looks compact enough. I still don't see the need to change make
> the remote-endpoint property required to achieve this, though. On the
> other hand, I wouldn't object to making it mandatory either.

Sure, having remote-endpoint as required doesn't achieve anything
particular as such. I just feel it's cleaner. If you have an endpoint,
it must point to somewhere. Maybe it makes the code a tiny bit simpler.

If we do already have users for this that do not have the
remote-endpoint, then we're stuck with having it as optional. If we
don't, I'd rather have it as mandatory.

In any case, it's not a very important thing either way.

>> Of course, it's up to the developer how his dts looks like. But to me it
>> makes sense to require the remote-endpoint property, as the endpoint, or
>> even the port, doesn't make much sense if there's nothing to connect to.
> 
> Please let's not make it mandatory for a port node to contain an
> endpoint. For any device with multiple ports we can't use the simplified
> form above, and only adding the (correctly numbered) port in all the
> board device trees would be a pain.

That's true. I went with having the ports in the board file, for example
on omap3 the dss has two ports, and N900 board uses the second one:

&dss {
	status = "ok";

	pinctrl-names = "default";
	pinctrl-0 = <&dss_sdi_pins>;

	vdds_sdi-supply = <&vaux1>;

	ports {
		#address-cells = <1>;
		#size-cells = <0>;

		port@1 {
			reg = <1>;

			sdi_out: endpoint {
				remote-endpoint = <&lcd_in>;
				datapairs = <2>;
			};
		};
	};
};

Here I guess I could have:

&dss {
	status = "ok";

	pinctrl-names = "default";
	pinctrl-0 = <&dss_sdi_pins>;

	vdds_sdi-supply = <&vaux1>;
};

&dss_sdi_port {
	sdi_out: endpoint {
		remote-endpoint = <&lcd_in>;
		datapairs = <2>;
	};
};

But I didn't like that as it splits the pincontrol and regulator supply
from the port/endpoint, which are functionally linked together.

Actually, somewhat aside the subject, I'd like to have the pinctrl and
maybe regulator supply also per endpoint, but I didn't see how that
would be possible with the current framework. If a board would need to
endpoints for the same port, most likely it would also need to different
sets of pinctrls.

 Tomi

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