Re: [PATCH] Fix sysfs_notify and kobject_uevent in fan_alarm_notify

2019-06-21 Thread Guenter Roeck

On 6/21/19 1:30 AM, Christian Schneider wrote:

Am 19.06.2019 um 20:53 schrieb Guenter Roeck:

On Wed, Jun 19, 2019 at 12:00:37PM +0200, Christian Schneider wrote:

Ok, seems that moving that block, where fan_alarm_init is called down, isn't
a problem on master.
I need to use 4.9, cause we have an embedded device that needs patches, and
they are only available for older kernels.

In 4.9, fan_alarm_init() does fan_data->alarm = alarm;
When fan_alarm_init() is called after
devm_hwmon_device_register_with_groups(), then fan_data->alarm is not yet
set, so the sysfs attribute is not created.

when I move the fan_data->alarm = alarm; out of fan_alarm_init() before
devm_hwmon_device_register_with_groups() and the fan_alarm_init() after,
then it works, and doesn't have a race condition.

On master, populating fan_data->alarm_gpio is done in
gpio_fan_get_of_data(fan_data); as far as I understand, so moving the
fan_alarm_init() block further down shouldn't be a problem.

I don't know, how I can test this with master kernel. Unfortunately, the
device, I'm using doesn't have a recent kernel. And on my normal (desktop)
pc, I don't have a gpio fan.
How should I proceed now?



Essentially, we'll need two patches: One to move fan_alarm_init() after
devm_hwmon_device_register_with_groups(), and then the notification patch.
For the backport to v4.9, the first patch will have to be slightly modified:
The first part will a simple
fan_data->alarm = pdata->alarm;
at the location where fan_alarm_init() is called now, the second part is to move
the call to fan_alarm_init() after devm_hwmon_device_register_with_groups().

It is ok to test the result with your 4.9 based kernel; we'll just have to be
careful when reviewing the mainline patch.

Thanks,
Guenter


Ok,
it seems like it is working as expected now on my 4.9 kernel. No race-condition 
and notification is received.
I will adopt the changes to mainline kernel, but not sure if I can make it 
today. Might be Monday, till I have the patch.


No hurry.

Thanks,
Guenter


Re: [PATCH] hwmon: Convert remaining drivers to use SPDX identifier

2019-06-21 Thread Jean Delvare
On Thu, 20 Jun 2019 06:19:46 -0700, Guenter Roeck wrote:
> This gets rid of the unnecessary license boilerplate, and avoids
> having to deal with individual patches one by one.
> 
> No functional changes intended.
> 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/hwmon/adm1029.c| 10 --
>  drivers/hwmon/adt7411.c|  5 +
>  drivers/hwmon/adt7475.c|  5 +
>  drivers/hwmon/iio_hwmon.c  |  5 +
>  drivers/hwmon/max197.c |  5 +
>  drivers/hwmon/scpi-hwmon.c | 10 +-
>  6 files changed, 5 insertions(+), 35 deletions(-)
> (...)

Reviewed-by: Jean Delvare 

-- 
Jean Delvare
SUSE L3 Support


Re: [PATCH] Fix sysfs_notify and kobject_uevent in fan_alarm_notify

2019-06-21 Thread Christian Schneider

Am 19.06.2019 um 20:53 schrieb Guenter Roeck:

On Wed, Jun 19, 2019 at 12:00:37PM +0200, Christian Schneider wrote:

Ok, seems that moving that block, where fan_alarm_init is called down, isn't
a problem on master.
I need to use 4.9, cause we have an embedded device that needs patches, and
they are only available for older kernels.

In 4.9, fan_alarm_init() does fan_data->alarm = alarm;
When fan_alarm_init() is called after
devm_hwmon_device_register_with_groups(), then fan_data->alarm is not yet
set, so the sysfs attribute is not created.

when I move the fan_data->alarm = alarm; out of fan_alarm_init() before
devm_hwmon_device_register_with_groups() and the fan_alarm_init() after,
then it works, and doesn't have a race condition.

On master, populating fan_data->alarm_gpio is done in
gpio_fan_get_of_data(fan_data); as far as I understand, so moving the
fan_alarm_init() block further down shouldn't be a problem.

I don't know, how I can test this with master kernel. Unfortunately, the
device, I'm using doesn't have a recent kernel. And on my normal (desktop)
pc, I don't have a gpio fan.
How should I proceed now?



Essentially, we'll need two patches: One to move fan_alarm_init() after
devm_hwmon_device_register_with_groups(), and then the notification patch.
For the backport to v4.9, the first patch will have to be slightly modified:
The first part will a simple
fan_data->alarm = pdata->alarm;
at the location where fan_alarm_init() is called now, the second part is to move
the call to fan_alarm_init() after devm_hwmon_device_register_with_groups().

It is ok to test the result with your 4.9 based kernel; we'll just have to be
careful when reviewing the mainline patch.

Thanks,
Guenter


Ok,
it seems like it is working as expected now on my 4.9 kernel. No 
race-condition and notification is received.
I will adopt the changes to mainline kernel, but not sure if I can make 
it today. Might be Monday, till I have the patch.


BR, Christian





BR, Christian

Am 19.06.2019 um 09:47 schrieb Christian Schneider:

Hi,
unfrotunately I found a problem with my patch. It didn't appear on the
devices, where I tested, only when distributing the patch to more devices,
it occurs sometimes.

There is a possible race condition. In gpio_fan_probe, the IRQ handler for
the fan alarm is registered before the hwmon_dev is initialised.
So it is possible, that the handler executes, while fandata->hwmon_dev is
still unitialised and the handler runs in an invalid pointer dereference.

The obvious fix, moving the
/* Configure alarm GPIO if available. */
if (fan_data->alarm_gpio) {
 err = fan_alarm_init(fan_data);
 if (err)
     return err;
}
block after

/* Make this driver part of hwmon class. */
fan_data->hwmon_dev =
 devm_hwmon_device_register_with_groups(dev,
    "gpio_fan", fan_data,
    gpio_fan_groups);

doesn't work. Sysfs doesn't have a fan1_alarm attribute anymore then.

It is not yet clear to me, why creation of the attribute fails in this
case. I need to investigate further.
In the meanwhile, please revert my patch.

I'm sorry for the disturbance I created

BR, Christian


Am 17.06.2019 um 18:04 schrieb Guenter Roeck:

On Mon, Jun 17, 2019 at 11:33:43AM +0200, cschnei...@radiodata.biz wrote:

From: Christian Schneider 

sysfs_notify and kobject_uevent are passed the wrong kobject.
that why notifications can't be received and uevents have the wrong
path.
this patch fixes this.

Signed-off-by: Christian Schneider 


Applied.

In the future, please version your patches, add a change log,
and reflect the subsystem and driver in the subject line.

Thanks,
Guenter


---
   drivers/hwmon/gpio-fan.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 84753680a4e8..76377791ff0e 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -54,8 +54,8 @@ static void fan_alarm_notify(struct work_struct *ws)
   struct gpio_fan_data *fan_data =
   container_of(ws, struct gpio_fan_data, alarm_work);
-    sysfs_notify(_data->dev->kobj, NULL, "fan1_alarm");
-    kobject_uevent(_data->dev->kobj, KOBJ_CHANGE);
+    sysfs_notify(_data->hwmon_dev->kobj, NULL, "fan1_alarm");
+    kobject_uevent(_data->hwmon_dev->kobj, KOBJ_CHANGE);
   }
   static irqreturn_t fan_alarm_irq_handler(int irq, void *dev_id)