On Wed, 9 Apr 2014 17:59:03 +0000, Matthew Garrett wrote: > On Wed, 2014-04-09 at 13:55 -0400, Prarit Bhargava wrote: > > > > On 04/09/2014 01:37 PM, Matthew Garrett wrote: > > > Right. It's dangerous, which is why we forbid it by default. How do we > > > benefit from having a driver that's no safer? > > > > We have yet to see where the existing case exhibits the behaviour of a race. In > > fact, AFAICT, all we've seen is stability. So it's no safer? Yep. It's as > > equally not racy as the existing workaround. > > So... why add the driver at all? Refusing to permit the kernel to touch > these resources is a deliberate design choice, because of the potential > for these races. (...) So it is a deliberate design choice to prevent the user from accessing his/her own hardware? I want to be able to read the SPD EEPROMs and the temperature sensors on my memory modules, and this requires SMBus access. The ACPI interface to hardware monitoring chips is horribly limited. Until the ACPI people come up with something which really exposes most of the features of the hardware monitoring chips currently provide, native access it required. At the moment, when a full-featured hardware monitoring chip monitors 5 to 10 voltage inputs, 5 fans and 3 temperature sensors, ACPI will show 2 thermal zones at best, not always updated in real-time, with limited resolution, and the fans are shown without their speed. That simply sucks. So we need either proper ACPI interfaces to all the useful features, or low-level, safe access to the registers through ACPI. Until we have that, we are condemned to live dangerously in an hostile world :( -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
