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  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 12:41:55 +0200
From:	Tomi Valkeinen <>
To:	Philipp Zabel <>
CC:	Russell King - ARM Linux <>,
	Mauro Carvalho Chehab <>,
	Grant Likely <>,
	Rob Herring <>,
	Sylwester Nawrocki <>,
	Laurent Pinchart <>,
	Kyungmin Park <>,
	<>, <>,
	Guennadi Liakhovetski <>
Subject: Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 27/02/14 12:52, Philipp Zabel wrote:

> This is a bit verbose, and if your output port is on an encoder device
> with multiple inputs, the correct port number would become a bit
> unintuitive. For example, we'd have to use port@4 as the output encoder
> units that have a 4-port input multiplexer and port@1 for those that
> don't.

Hmm, sorry, I don't follow...

The port numbers should be fixed for a particular device. If the device
has 4 input ports, the output port would always be port@4, no matter how
many of the input ports are actually used.

I don't have anything against having the ports described in the SoC
dtsi. But I do think it may make it a bit unclear that the ports are
from the same device, and share things like pinmuxing. Both approaches
should work fine, afaics.

However, if, instead, we could have the pinmuxing and other relevant
information in the port or endpoint nodes, making the ports independent
of each other and of the device behind them, I argument above would

Also, while I'm all for making the dts files clear, I do think the one
writing the dts still needs to go carefully through the binding docs.
Say, a device may need a gpio list with a bunch of gpios. The developer
just needs to read the docs and know that gpio #3 on the list is GPIO_XYZ.

So I don't see it as a major problem that the board developer needs to
know that port@1 on OMAP3's DSS is SDI output.

>> Here I guess I could have:
>> &dss {
>> 	status = "ok";
>> 	pinctrl-names = "default";
>> 	pinctrl-0 = <&dss_sdi_pins>;
>> 	vdds_sdi-supply = <&vaux1>;
>> };
> What is supplied by this regulator. Is it the PHY?


>> 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.
> I have a usecase for this the other way around. The i.MX6 DISP0 parallel
> display pads can be connected to two different display controllers via
> multiplexers in the pin control block.
> parallel-display {
> 	compatible = "fsl,imx-parallel-display";
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> 	port@0 {
> 		endpoint {
> 			remote-endpoint = <&ipu1_di0>;
> 		};
> 	};
> 	port@1 {
> 		endpoint {
> 			remote-endpoint = <&ipu2_di0>;
> 		};
> 	};
> 	disp0: port@2 {
> 		endpoint {
> 			pinctrl-names = "0", "1";
> 			pinctrl-0 = <&pinctrl_disp0_ipu1>;
> 			pinctrl-1 = <&pinctrl_disp0_ipu2>;
> 			remote-endpoint = <&lcd_in>;
> 		};
> 	}
> };
> Here, depending on the active input port, the corresponding pin control
> on the output port could be set. This is probably quite driver specific,
> so I don't see yet how the framework should help with this. In any case,
> maybe this is a bit out of scope for the generic graph bindings.

Hmm, why wouldn't you have the pinctrl definitions in the ports 0 and 1,
then, if it's about selecting the active input pins?

I think the pinctrl framework could offer ways to have pinctrl
definitions anywhere in the DT structure. It'd be up to the driver to
point to the pinctrl in the DT, ask the framework to parse them, and
eventually enable/disable the pins.

But yes, it's a bit out of scope =).


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

Powered by blists - more mailing lists