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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <75f81c9a-e5ca-1382-43c9-8fd4acc36510@mentor.com>
Date:   Wed, 15 Apr 2020 23:44:21 +0900
From:   "Wang, Jiada" <jiada_wang@...tor.com>
To:     Dmitry Osipenko <digetx@...il.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

Hi Dmitry

On 2020/04/11 7:38, Dmitry Osipenko wrote:
> 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.
> 
thanks, I think your solution makes more sense,
I will replace with your suggested solution in next version

Thanks,
Jiada