Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 8月, 2010 1 次提交
  3. 28 5月, 2010 4 次提交
  5. 10 12月, 2009 4 次提交
    • H
      hwmon: (f71882fg) Add support for the f71889fg (version 2) · 7669896f
      由 Hans de Goede 提交于 
      This adds support for the Fintek f71889fg to the f71882fg driver,
many thanks to Gerd v. Egidy for providing (remote) access to a
machine which such an ic.

Note that this bit of the patch:
-	val = SENSORS_LIMIT(val, 0, 255);
+
+	if (data->type == f71889fg)
+		val = SENSORS_LIMIT(val, -128, 127);
+	else
+		val = SENSORS_LIMIT(val, 0, 127);

Changes behaviour for already supported models, the new behaviour is correct
as the already supported models have bit 7 of the involved registers fixed at
0, so the previous behaviour which allowed setting temp zone limits > 127
was not correct.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      7669896f
    • H
      hwmon: (f71882fg) Fix sysfs file removal · fc16c56e
      由 Hans de Goede 提交于 
      There is a bug in the old sysfs file removal, as it uses fxxxx_in_temp_attr
to remove the in and temp sysfs attributes, but fxxxx_in_temp_attr has
temp#_alarm, where as f71858fg_in_temp_attr has temp#_max_alarm, so
the temp#_max_alarm attributes for the f71858fg never get removed.

This patch fixes this by doing the sysfs removal exactly the same way as
the creation instead of being (too) clever, this will also avoid similar
bugs in the future.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      fc16c56e
    • H
      hwmon: (f71882fg) Cleanup sysfs attr creation 2/2 · b69b0399
      由 Hans de Goede 提交于 
      This patch merges the f71882fg_auto_pwm_attr array into the
fxxxx_fan_attr resp. fxxxx_auto_pwm_attr array, as the f71882fg_auto_pwm_attr
array was merely extending these 2 with entries for a 4th fan, it also makes
these 2 arrays 2 dimensional so that the rest of the code can choose to
add attr for 3 or 4 fans without needing to know the nr of attr per fan.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      b69b0399
    • H
      hwmon: (f71882fg) Cleanup sysfs attr creation 1/2 · 66344aa6
      由 Hans de Goede 提交于 
      This patch makes a number of cleanups to the sysfs attr creation
in the f71882fg driver, this is a preparation patch for adding f71889fg
support:

* Add some comments to explain why some models need separate sysfs attr
  arrays for in / temp / fan / pwm
* Rename a number of sysfs attr arrays to make their function clearer
* Move the pwm#_auto_channels_temp attribute from the common to all
  models fan attr array to the per model auto mode pwm attr arrays, so
  that all the auto mode pwm attr are grouped together, and thus can be
  left out on models where we don't support auto pwm mode
* Put fan_beep attr in their own array, so that only auto mode pwm attr
  remain in the per model pwm sysfs attr arrays.
* Put the 4th special fan input for the f8000 in its own array, so that only
  auto mode pwm attr remain in the per model pwm sysfs attr arrays.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      66344aa6
  7. 16 6月, 2009 5 次提交
  9. 18 2月, 2009 2 次提交
  11. 07 1月, 2009 18 次提交
  13. 07 8月, 2008 1 次提交
  15. 08 2月, 2008 1 次提交
    • J
      hwmon: Let the user override the detected Super-I/O device ID · 67b671bc
      由 Jean Delvare 提交于 
      While it is possible to force SMBus-based hardware monitoring chip
drivers to drive a not officially supported device, we do not have this
possibility for Super-I/O-based drivers. That's unfortunate because
sometimes newer chips are fully compatible and just forcing the driver
to load would work. Instead of that we have to tell the users to
recompile the kernel driver, which isn't an easy task for everyone.

So, I propose that we add a module parameter to all Super-I/O based
hardware monitoring drivers, letting advanced users force the driver
to load on their machine. The user has to provide the device ID of a
supposedly compatible device. This requires looking at the source code or
a datasheet, so I am confident that users can't randomly force a driver
without knowing what they are doing. Thus this should be relatively safe.

As you can see from the code, the implementation is pretty simple and
unintrusive.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NHans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: NMark M. Hoffman <mhoffman@lightlink.com>
      67b671bc
  17. 10 10月, 2007 3 次提交