linux-kernel - Re: [PATCH v2 1/2] ARM: davinci: Allocate extra interrupts

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, 20 Jan 2017 12:17:12 -0600
From:   David Lechner <david@...hnology.com>
To:     Sekhar Nori <nsekhar@...com>, linux-arm-kernel@...ts.infradead.org
Cc:     Kevin Hilman <khilman@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] ARM: davinci: Allocate extra interrupts

On 01/20/2017 05:50 AM, Sekhar Nori wrote:
> On Wednesday 18 January 2017 10:27 PM, David Lechner wrote:
>> On 01/18/2017 03:50 AM, Sekhar Nori wrote:
>>> On Saturday 14 January 2017 01:30 AM, David Lechner wrote:
>>>> This allocates extra interrupts for mach-davinci. These extra interrupts
>>>> are need for things like IIO triggers.
>>>
>>> I am not really familiar with IIO triggers. Can you give some more
>>> detail on what fails without this patch?
>>
>> A trigger is used to initiate the reading of an iio device. For example,
>> there is a mechanism for a sysfs trigger. When you write 1 to the sysfs
>> attribute, it triggers an interrupt that is handled by the iio device.
>>
>> Since these triggers use interrupts, you need to allocate spare
>> interrupts in order to set up the trigger. Otherwise, setting up the
>> trigger will fail with an error code (I forgot which one exactly)
>> because all of the allocated irqs have already been assigned to hardware
>> irqs and are not available.
>>
>> Here is where the iio subsytem actually allocates the irq:
>> http://lxr.free-electrons.com/source/drivers/iio/industrialio-trigger.c#L525
>
> Alright, I will take a look. Do note that this may not get included in
> the first batch of v4.11 changes I queue. But I promise to come back to
> it soon afterwards.
>

It is not critical at this point, so it is fine to wait a bit.