[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46e0b0cf-63f1-4b46-dc3e-0e6610e72d75@gmail.com>
Date: Sat, 11 Apr 2020 01:38:07 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Jiada Wang <jiada_wang@...tor.com>, nick@...anahar.org,
dmitry.torokhov@...il.com, jikos@...nel.org,
benjamin.tissoires@...hat.com, bsz@...ihalf.com
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
erosca@...adit-jv.com, Andrew_Gabbasov@...tor.com
Subject: Re: [PATCH v10 31/55] Input: atmel_mxt_ts - delay enabling IRQ when
not using regulators
31.03.2020 13:50, Jiada Wang пишет:
> From: Nick Dyer <nick.dyer@...ev.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.
Powered by blists - more mailing lists