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 10:32:47 +0100
From:   Fabrice Gasnier <fabrice.gasnier@...com>
To:     Rob Herring <robh@...nel.org>
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 03/03/2017 07:21 AM, Rob Herring wrote:
> 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
Hi Rob,

Thanks for reviewing.

I hope I don't miss your point here... However, if I correctly
understand it:
Yes, this can be one way to get interrupt(s) directly from consumer 
node. Then, I understand consumer has to do exact same as what is being 
done in "iio_interrupt_trigger" for instance, basically:
- request irq, alloc and register trigger, do irq handling to call
trigger poll routine.

With current patchset, consumer is able to use standard trigger like
"interrupt-trigger" from DT. Please note I propose to add OF support
for it in current patchset (e.g. PATCHs 2 & 3). Currently only platform
data is supported.

-> And, please refer to PATCHs 5 & 6, I need to have some way to 
identify interrupt line (connected in HW to STM32 ADC IP). Currently,
this is best I came up with, trying to re-use, be generic, and to 
describe this HW in DT.

Of course, the other way is still valid. Also, I want to highlight,
STM32 has other IP, e.g. DAC, where same can be re-used then. This
will avoid having duplicates.

> interrupt name. So the question is whether this extra level of
> indirection is needed?

Purpose is to be able to get one or more named trigger(s) on consumer
side. Idea is to adopt similar 'philosophy' as in other bindings like
pinctrl, clk... where consumer has possibility to get them by name.
I hope this clarifies.

Please advise,
Best Regards,
Fabrice

>
> Rob
>