Re: [PATCH v10 31/55] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dmitry

On 2020/04/11 7:38, Dmitry Osipenko wrote:
31.03.2020 13:50, Jiada Wang пишет:
From: Nick Dyer <nick.dyer@xxxxxxxxxxx>

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



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux