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]
Message-ID: <12a6a2f8-9ff6-a4f0-c9a2-c7de037019ef@kernel.org>
Date:   Sun, 5 Mar 2017 12:13:36 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Rob Herring <robh@...nel.org>,
        Fabrice Gasnier <fabrice.gasnier@...com>
Cc:     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 05/03/17 11:43, Jonathan Cameron wrote:
> On 03/03/17 06:21, 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 
>> interrupt name. So the question is whether this extra level of 
>> indirection is needed? 
> 
> First thing to note here, is that Fabrice's use of the generic interrupt
> trigger is an extremely 'unusual' one! Normal use case is that we have
> a random gpio pin providing interrupts to driver triggering on random
> devices - there need be no association between the two whatsoever.
> So what we are doing here is 'allowing' an interrupt to provide a trigger.
> It's not necessarily the one going to be used by any particular device
> driver.  The decision of which trigger to use is definitely one for
> userspace, not something that should be configured in to the device tree.
> 
> For this particular case you could in theory just do it by using an interrupt
> as you describe.  Ultimately though we should be able to play more complex
> games with this device and having it able to handle any trigger - which 
> includes those not using the direct hardware route.  It'll be up to the
> driver to figure out when it can use the fast method and when it can't.
> 
> Conversely, even when we are using this hardware route to drive the
> triggering it should be possible to hang off a device to be triggered
> by the interrupt via the kernel rather than directly. 
> 
> So from a device tree point of view we are just describing the fact that
> there is a pin, which may be used to trigger something.  What that something
> is, is a question for userspace not the device tree.
> 
Ah, I'm half asleep this morning.  Clearly there is a more general follow
up question.  If we are arguing these are generic, why are we setting
up the mapping in device tree?

My gut feeling is we shouldn't be.  So I think we need the first chunk
above but the latter part should be a job for userspace not the devicetree.

Jonathan
> Jonathan
>>
>> Rob
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>