All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <khali@linux-fr.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	lm-sensors@lm-sensors.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH v2 3/4] hwmon: (adt7x10) Add alarm interrupt support
Date: Tue, 19 Feb 2013 13:05:42 +0100	[thread overview]
Message-ID: <51236A96.3040000@metafoo.de> (raw)
In-Reply-To: <20130219013933.GD25124@roeck-us.net>

On 02/19/2013 02:39 AM, Guenter Roeck wrote:
> On Mon, Feb 18, 2013 at 02:38:58PM +0100, Lars-Peter Clausen wrote:
>> This allows a userspace application to poll() on the alarm files to get notified
>> in case of an temperature threshold event.
>>
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>>
[...]
>>  
>> +static irqreturn_t adt7410_irq_handler(int irq, void *private)
>> +{
>> +	struct device *dev = private;
>> +	int status;
>> +
>> +	status = adt7410_read_byte(dev, ADT7410_STATUS);
>> +	if (status < 0)
>> +		return IRQ_HANDLED;
>> +
>> +	if (status & ADT7410_STAT_T_HIGH)
>> +		sysfs_notify(&dev->kobj, NULL, "temp1_max_alarm");
>> +	if (status & ADT7410_STAT_T_LOW)
>> +		sysfs_notify(&dev->kobj, NULL, "temp1_min_alarm");
>> +	if (status & ADT7410_STAT_T_CRIT)
>> +		sysfs_notify(&dev->kobj, NULL, "temp1_crit_alarm");
>> +
> Question about semantics: Do you want a notification on all attributes each time
> one is set during an interrupt, or do you want a notification each time an
> attribute changes state ? With the above code, the 1->0 transition does not
> result in a notification. Is that on purpose ?
> 

Now that the code uses an edge triggered IRQ and comparator mode it would
actually be possible to also generate an event for a 1->0 transition, but
I'm not sure how much sense that makes. Usually you'd only want to respond
quickly to the case where a threshold event happens.

>> +	return IRQ_HANDLED;
>> +}
>> +
>>  static int adt7410_temp_ready(struct device *dev)
>>  {
>>  	int i, status;
>> @@ -357,7 +377,7 @@ static const struct attribute_group adt7410_group = {
>>  	.attrs = adt7410_attributes,
>>  };
>>  
>> -int adt7410_probe(struct device *dev, const char *name,
>> +int adt7410_probe(struct device *dev, const char *name, int irq,
>>  	const struct adt7410_ops *ops)
>>  {
>>  	struct adt7410_data *data;
>> @@ -383,11 +403,13 @@ int adt7410_probe(struct device *dev, const char *name,
>>  	data->oldconfig = ret;
>>  
>>  	/*
>> -	 * Set to 16 bit resolution, continous conversion and comparator mode.
>> +	 * Set to 16 bit resolution and continous conversion
>>  	 */
>>  	data->config = data->oldconfig;
>> -	data->config &= ~ADT7410_MODE_MASK;
>> +	data->config &= ~(ADT7410_MODE_MASK | ADT7410_CT_POLARITY |
>> +			ADT7410_INT_POLARITY);
>>  	data->config |= ADT7410_FULL | ADT7410_RESOLUTION | ADT7410_EVENT_MODE;
>> +
>>  	if (data->config != data->oldconfig) {
>>  		ret = adt7410_write_byte(dev, ADT7410_CONFIG, data->config);
>>  		if (ret)
>> @@ -421,8 +443,18 @@ int adt7410_probe(struct device *dev, const char *name,
>>  		goto exit_remove_name;
>>  	}
>>  
>> +	if (irq > 0) {
>> +		ret = request_threaded_irq(irq, NULL, adt7410_irq_handler,
>> +				IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> +				dev_name(dev), dev);
> 
> If you use devm_request_threaded_irq, you don't have to release it on remove.

devm_request_threaded_irq is tricky, since the IRQ will only be freed after
the drivers remove callback has been run. This can cause race conditions,
since the IRQ handler often access resources already freed in the remove
callback. In this case it will work fine since sysfs_notify handles the case
where the files are already gone gracefully and just does nothing in that
case. I'd still prefer to keep the explicit free, so things are cleaned up
in the reverse order to the way they were set up.

> 
>> +		if (ret)
>> +			goto exit_hwmon_device_unregister;
>> +	}
>> +
> 
> This code should be before hwmon registration.

Why? It doesn't make sense to signal an event before userspace can actually
discover the device.

> 
>>  	return 0;
>>  
>> +exit_hwmon_device_unregister:
>> +	hwmon_device_unregister(data->hwmon_dev);
>>  exit_remove_name:
>>  	if (name)
>>  		device_remove_file(dev, &dev_attr_name);
>> @@ -434,10 +466,13 @@ exit_restore:
>>  }
>>  EXPORT_SYMBOL_GPL(adt7410_probe);

WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars@metafoo.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <khali@linux-fr.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	lm-sensors@lm-sensors.org, linux-iio@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH v2 3/4] hwmon: (adt7x10) Add alarm interrupt support
Date: Tue, 19 Feb 2013 12:05:42 +0000	[thread overview]
Message-ID: <51236A96.3040000@metafoo.de> (raw)
In-Reply-To: <20130219013933.GD25124@roeck-us.net>

On 02/19/2013 02:39 AM, Guenter Roeck wrote:
> On Mon, Feb 18, 2013 at 02:38:58PM +0100, Lars-Peter Clausen wrote:
>> This allows a userspace application to poll() on the alarm files to get notified
>> in case of an temperature threshold event.
>>
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>>
[...]
>>  
>> +static irqreturn_t adt7410_irq_handler(int irq, void *private)
>> +{
>> +	struct device *dev = private;
>> +	int status;
>> +
>> +	status = adt7410_read_byte(dev, ADT7410_STATUS);
>> +	if (status < 0)
>> +		return IRQ_HANDLED;
>> +
>> +	if (status & ADT7410_STAT_T_HIGH)
>> +		sysfs_notify(&dev->kobj, NULL, "temp1_max_alarm");
>> +	if (status & ADT7410_STAT_T_LOW)
>> +		sysfs_notify(&dev->kobj, NULL, "temp1_min_alarm");
>> +	if (status & ADT7410_STAT_T_CRIT)
>> +		sysfs_notify(&dev->kobj, NULL, "temp1_crit_alarm");
>> +
> Question about semantics: Do you want a notification on all attributes each time
> one is set during an interrupt, or do you want a notification each time an
> attribute changes state ? With the above code, the 1->0 transition does not
> result in a notification. Is that on purpose ?
> 

Now that the code uses an edge triggered IRQ and comparator mode it would
actually be possible to also generate an event for a 1->0 transition, but
I'm not sure how much sense that makes. Usually you'd only want to respond
quickly to the case where a threshold event happens.

>> +	return IRQ_HANDLED;
>> +}
>> +
>>  static int adt7410_temp_ready(struct device *dev)
>>  {
>>  	int i, status;
>> @@ -357,7 +377,7 @@ static const struct attribute_group adt7410_group = {
>>  	.attrs = adt7410_attributes,
>>  };
>>  
>> -int adt7410_probe(struct device *dev, const char *name,
>> +int adt7410_probe(struct device *dev, const char *name, int irq,
>>  	const struct adt7410_ops *ops)
>>  {
>>  	struct adt7410_data *data;
>> @@ -383,11 +403,13 @@ int adt7410_probe(struct device *dev, const char *name,
>>  	data->oldconfig = ret;
>>  
>>  	/*
>> -	 * Set to 16 bit resolution, continous conversion and comparator mode.
>> +	 * Set to 16 bit resolution and continous conversion
>>  	 */
>>  	data->config = data->oldconfig;
>> -	data->config &= ~ADT7410_MODE_MASK;
>> +	data->config &= ~(ADT7410_MODE_MASK | ADT7410_CT_POLARITY |
>> +			ADT7410_INT_POLARITY);
>>  	data->config |= ADT7410_FULL | ADT7410_RESOLUTION | ADT7410_EVENT_MODE;
>> +
>>  	if (data->config != data->oldconfig) {
>>  		ret = adt7410_write_byte(dev, ADT7410_CONFIG, data->config);
>>  		if (ret)
>> @@ -421,8 +443,18 @@ int adt7410_probe(struct device *dev, const char *name,
>>  		goto exit_remove_name;
>>  	}
>>  
>> +	if (irq > 0) {
>> +		ret = request_threaded_irq(irq, NULL, adt7410_irq_handler,
>> +				IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> +				dev_name(dev), dev);
> 
> If you use devm_request_threaded_irq, you don't have to release it on remove.

devm_request_threaded_irq is tricky, since the IRQ will only be freed after
the drivers remove callback has been run. This can cause race conditions,
since the IRQ handler often access resources already freed in the remove
callback. In this case it will work fine since sysfs_notify handles the case
where the files are already gone gracefully and just does nothing in that
case. I'd still prefer to keep the explicit free, so things are cleaned up
in the reverse order to the way they were set up.

> 
>> +		if (ret)
>> +			goto exit_hwmon_device_unregister;
>> +	}
>> +
> 
> This code should be before hwmon registration.

Why? It doesn't make sense to signal an event before userspace can actually
discover the device.

> 
>>  	return 0;
>>  
>> +exit_hwmon_device_unregister:
>> +	hwmon_device_unregister(data->hwmon_dev);
>>  exit_remove_name:
>>  	if (name)
>>  		device_remove_file(dev, &dev_attr_name);
>> @@ -434,10 +466,13 @@ exit_restore:
>>  }
>>  EXPORT_SYMBOL_GPL(adt7410_probe);

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  reply	other threads:[~2013-02-19 12:04 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18 13:38 [PATCH v2 1/4] hwmon: (adt7410) Don't re-read non-volatile registers Lars-Peter Clausen
2013-02-18 13:38 ` [lm-sensors] " Lars-Peter Clausen
2013-02-18 13:38 ` [PATCH v2 2/4] hwmon: (adt7410) Add support for the adt7310/adt7320 Lars-Peter Clausen
2013-02-18 13:38   ` [lm-sensors] [PATCH v2 2/4] hwmon: (adt7410) =?utf-8?q?Add_support_for_the_ad Lars-Peter Clausen
2013-02-19  1:30   ` [PATCH v2 2/4] hwmon: (adt7410) Add support for the adt7310/adt7320 Guenter Roeck
2013-02-19  1:30     ` [lm-sensors] " Guenter Roeck
2013-02-19 11:57     ` Lars-Peter Clausen
2013-02-19 11:57       ` [lm-sensors] " Lars-Peter Clausen
2013-02-19 16:52       ` Guenter Roeck
2013-02-19 16:52         ` [lm-sensors] " Guenter Roeck
2013-02-18 13:38 ` [PATCH v2 3/4] hwmon: (adt7x10) Add alarm interrupt support Lars-Peter Clausen
2013-02-18 13:38   ` [lm-sensors] " Lars-Peter Clausen
2013-02-19  1:39   ` Guenter Roeck
2013-02-19  1:39     ` [lm-sensors] " Guenter Roeck
2013-02-19 12:05     ` Lars-Peter Clausen [this message]
2013-02-19 12:05       ` Lars-Peter Clausen
2013-02-19 17:10       ` Guenter Roeck
2013-02-19 17:10         ` [lm-sensors] " Guenter Roeck
2013-02-18 13:38 ` [PATCH v2 4/4] staging:iio: Remove adt7410 driver Lars-Peter Clausen
2013-02-18 13:38   ` [lm-sensors] " Lars-Peter Clausen
2013-03-02 16:45   ` Jonathan Cameron
2013-03-02 16:45     ` [lm-sensors] " Jonathan Cameron
2013-03-02 17:10     ` Guenter Roeck
2013-03-02 17:10       ` [lm-sensors] " Guenter Roeck
2013-02-18 20:22 ` [PATCH v2 1/4] hwmon: (adt7410) Don't re-read non-volatile registers Hartmut Knaack
2013-02-18 20:22   ` [lm-sensors] " Hartmut Knaack
2013-02-19  1:02   ` Guenter Roeck
2013-02-19  1:02     ` [lm-sensors] " Guenter Roeck
2013-02-19 19:39     ` Hartmut Knaack
2013-02-19 19:39       ` [lm-sensors] " Hartmut Knaack
2013-02-20  1:22       ` Guenter Roeck
2013-02-20  1:22         ` [lm-sensors] " Guenter Roeck
2013-02-19  1:32 ` Guenter Roeck
2013-02-19  1:32   ` [lm-sensors] " Guenter Roeck
2013-02-23  0:45 ` Hartmut Knaack
2013-02-23 20:18   ` Guenter Roeck
2013-02-23 20:18     ` [lm-sensors] " Guenter Roeck
2013-02-25 22:03     ` Hartmut Knaack
2013-02-25 22:03       ` [lm-sensors] " Hartmut Knaack
2013-02-26  1:40       ` Guenter Roeck
2013-02-26  1:40         ` [lm-sensors] " Guenter Roeck
2013-02-25  9:54   ` Lars-Peter Clausen
2013-02-25  9:54     ` [lm-sensors] " Lars-Peter Clausen
2013-02-25 21:30     ` Hartmut Knaack
2013-02-25 21:30       ` [lm-sensors] " Hartmut Knaack
2013-02-26  1:39       ` Guenter Roeck
2013-02-26  1:39         ` [lm-sensors] " Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51236A96.3040000@metafoo.de \
    --to=lars@metafoo.de \
    --cc=jic23@cam.ac.uk \
    --cc=khali@linux-fr.org \
    --cc=knaack.h@gmx.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.