On Sun, Oct 13, 2013 at 09:31:25PM -0500, Felipe Contreras wrote: > On Sun, Oct 13, 2013 at 10:17 AM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > > The spec doesn't seem to constrain it to physical addresses (it just > > refers to "Control Methods read and write data to locations in address > > spaces (for example, System memory and System I/O)", so I'd lean towards > > changing the behaviour of acpica rather than adding virt_to_phys(). > > And I assume you are not going to do that. Isn't acpica code outside > of the scope of Linux kernel development? If not, how do I go about > adding that capability. I wasn't planning on it, no. Just write the code and submit it to linux-acpi, and Cc: Bob Moore. > Also, I find it weird that this the first driver that needs this. The normal way to do this would be for the ASL to just define a buffer within the argument, rather than assigning it to an operation region. I haven't seen anyone take this approach before. > Finally, I'm much more interested on what happens next, because I want > to link this driver to the thermal framework, so when temperature gets > too high, the fan gets an increased speed, because right now it seems > it's always on low speed, temperature gets high, and instead the CPU > gets throttled, which is not desirable. It wouldn't be appropriate to alter the firmware behaviour by default, but yeah, that's the kind of thing that the thermal framework exists to do. > Maybe this driver should be added to the staging area. I don't think you can easily register multiple drivers for the same WMI device. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
