linux-kernel - Re: [PATCH v3 1/6] dt-bindings: iio: introduce trigger providers, consumers

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:   Fri, 3 Mar 2017 00:21:26 -0600
From:   Rob Herring <robh@...nel.org>
To:     Fabrice Gasnier <fabrice.gasnier@...com>
Cc:     jic23@...nel.org, linux@...linux.org.uk,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
        mark.rutland@....com, mcoquelin.stm32@...il.com,
        alexandre.torgue@...com, lars@...afoo.de, knaack.h@....de,
        pmeerw@...erw.net, benjamin.gaignard@...aro.org,
        benjamin.gaignard@...com, linus.walleij@...aro.org
Subject: Re: [PATCH v3 1/6] dt-bindings: iio: introduce trigger providers,
 consumers

On Tue, Feb 28, 2017 at 05:51:14PM +0100, Fabrice Gasnier wrote:
> Document iio provider and consumer bindings.
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@...com>
> ---
>  .../devicetree/bindings/iio/iio-bindings.txt       | 38 ++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> index 68d6f8c..01765e9 100644
> --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -95,3 +95,41 @@ vdd channel is connected to output 0 of the &ref device.
>  		io-channels = <&adc 10>, <&adc 11>;
>  		io-channel-names = "adc1", "adc2";
>  	};
> +
> +==IIO trigger providers==
> +Sources of IIO triggers can be represented by any node in the device
> +tree. Those nodes are designated as IIO trigger providers. IIO trigger
> +consumer uses a phandle and an IIO trigger specifier to connect to an
> +IIO trigger provider.
> +An IIO trigger specifier is an array of one or more cells identifying
> +the IIO trigger output on a device. The length of an IIO trigger
> +specifier is defined by the value of a #io-trigger-cells property in
> +the IIO trigger provider node.
> +
> +Required properties:
> +#io-trigger-cells:
> +		Number of cells in an IIO trigger specifier; Typically
> +		0 for nodes with a simple IIO trigger output.
> +
> +Example:
> +	trig0: interrupt-trigger0 {
> +		#io-trigger-cells = <0>;
> +		compatible = "interrupt-trigger";
> +		interrupts = <11 0>;
> +		interrupt-parent = <&gpioa>;
> +	}
> +
> +==IIO trigger consumers==
> +Required properties:
> +- io-triggers:	List of phandle representing the IIO trigger specifier.
> +
> +Optional properties:
> +- io-trigger-names :
> +		List of IIO trigger name strings that matches elements
> +		in 'io-triggers' list property.
> +
> +Example:
> +	some_trigger_consumer {
> +		io-triggers = <&trig0>;
> +		io-trigger-names = "mytrig";
> +	}

I have some reservations about this. We could just as easily add the 
interrupt directly to the consumer node and use "trigger" for a standard 
interrupt name. So the question is whether this extra level of 
indirection is needed? 

Rob