linux-kernel - Re: [PATCH] Staging: iio: meter: Use devm functions

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: <alpine.DEB.2.11.1510041809250.26738@shraddha-370R4E-370R4V-370R5E-3570RE-370R5V>
Date:	Sun, 4 Oct 2015 18:13:37 +0530 (IST)
From:	Shraddha Barke <shraddha.6596@...il.com>
To:	Jonathan Cameron <jic23@...nel.org>
cc:	Shraddha Barke <shraddha.6596@...il.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Staging: iio: meter: Use devm functions



On Sun, 4 Oct 2015, Jonathan Cameron wrote:

> On 04/10/15 05:34, Shraddha Barke wrote:
>> Introduce use of managed resource function devm_iio_trigger_alloc
>> instead of iio_trigger_alloc and devm_request_irq instead of request_irq
>> Remove corresponding calls to iio_trigger_free and free_irq in the probe
>> and remove functions.
>> The now unnecessary labels error_free_trig and err_free_irq are dropped.
>>
>> Signed-off-by: Shraddha Barke <shraddha.6596@...il.com>
>> ---
>>
>>  drivers/staging/iio/meter/ade7758_trigger.c | 26 ++++++++++----------------
>>  1 file changed, 10 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/staging/iio/meter/ade7758_trigger.c b/drivers/staging/iio/meter/ade7758_trigger.c
>> index 5b35a7f..e313b37 100644
>> --- a/drivers/staging/iio/meter/ade7758_trigger.c
>> +++ b/drivers/staging/iio/meter/ade7758_trigger.c
>> @@ -63,21 +63,21 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
>>  	struct ade7758_state *st = iio_priv(indio_dev);
>>  	int ret;
>>
>> -	st->trig = iio_trigger_alloc("%s-dev%d",
>> -					spi_get_device_id(st->us)->name,
>> -					indio_dev->id);
>> +	st->trig = devm_iio_trigger_alloc(&indio_dev->id, "%s-dev%d",
>> +					  spi_get_device_id(st->us)->name,
>> +					  indio_dev->id);
>>  	if (!st->trig) {
>>  		ret = -ENOMEM;
>>  		goto error_ret;
>>  	}
>>
>> -	ret = request_irq(st->us->irq,
>> -			  ade7758_data_rdy_trig_poll,
>> -			  IRQF_TRIGGER_LOW,
>> -			  spi_get_device_id(st->us)->name,
>> -			  st->trig);
>> +	ret = devm_request_irq(&indio_dev->dev, st->us->irq,
>> +			       ade7758_data_rdy_trig_poll,
>> +			       IRQF_TRIGGER_LOW,
>> +			       spi_get_device_id(st->us)->name,
>> +			       st->trig);
>>  	if (ret)
>> -		goto error_free_trig;
>> +		goto error_ret
>>
>>  	st->trig->dev.parent = &st->us->dev;
>>  	st->trig->ops = &ade7758_trigger_ops;
>> @@ -87,14 +87,10 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
>>  	/* select default trigger */
>>  	indio_dev->trig = iio_trigger_get(st->trig);
>>  	if (ret)
>> -		goto error_free_irq;
>> +		goto error_ret;
>>
>>  	return 0;
>>
>> -error_free_irq:
>> -	free_irq(st->us->irq, st->trig);
>> -error_free_trig:
>> -	iio_trigger_free(st->trig);
>>  error_ret:
>>  	return ret;
> Whilst you are here, direct returns are preferred when there is no unwinding to do
> so if you could just return the error from anywhere it does the goto error_ret
> that would be great!

I was a little skeptical about the change from request_irq to 
devm_request_irq because I'm not sure whether the things that are
freed by the function are needed by the interrupt handler.  Do you 
think it's correct?

Shraddha
>
> Thanks,
>
> Jonathan
>>  }
>> @@ -104,6 +100,4 @@ void ade7758_remove_trigger(struct iio_dev *indio_dev)
>>  	struct ade7758_state *st = iio_priv(indio_dev);
>>
>>  	iio_trigger_unregister(st->trig);
>> -	free_irq(st->us->irq, st->trig);
>> -	iio_trigger_free(st->trig);
>>  }
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/