lkml.org 
[lkml]   [2020]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v10 31/55] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators
From
Date
Hi Dmitry

On 2020/04/11 7:38, Dmitry Osipenko wrote:
> 31.03.2020 13:50, Jiada Wang пишет:
>> From: Nick Dyer <nick.dyer@itdev.co.uk>
>>
>> The path of enabling the IRQ in the probe function is not safe in level
>> triggered operation, if it was already powered up and there is a message
>> waiting on the device (eg finger down) because the object table has not yet
>> been read. This forces the ISR into a hard loop.
>>
>> Delay enabling the interrupt until it is first needed.
>
>
>>
>> - if (data->use_retrigen_workaround) {
>> + /* Presence of data->irq means IRQ initialised */
>> + data->irq = data->client->irq;
>
> IIRC, IRQ=0 could be a valid interrupt since this is a "virtual"
> interrupt number.
>
> ...
>> init_completion(&data->chg_completion);
>> @@ -3826,26 +3842,22 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
>> return error;
>> }
>
> What about just to tell the IRQ core not to enable the interrupt
> handling during of the devm_request_threaded_irq()?
>
> To achieve that, add this line here:
>
> irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
>
>> - error = devm_request_threaded_irq(&client->dev, client->irq,
>> - NULL, mxt_interrupt, IRQF_ONESHOT,
>> - client->name, data);
> ...
>
> Then the interrupt will be requested in the disabled state and it will
> be enabled only after the first enable_irq() invocation.
>
thanks, I think your solution makes more sense,
I will replace with your suggested solution in next version

Thanks,
Jiada

\
 
 \ /
  Last update: 2020-04-15 16:45    [W:0.089 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site