Messages in this thread | | | Subject | Re: [PATCH v10 31/55] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators | From | "Wang, Jiada" <> | Date | Wed, 15 Apr 2020 23:44:21 +0900 |
| |
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
| |