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:6.578 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site