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