lkml.org 
[lkml]   [2013]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] platform: x86: asus-wmi: add fan control
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@srcf.ucam.org> 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@srcf.ucam.org


\
 
 \ /
  Last update: 2013-10-14 19:01    [W:0.097 / U:5.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site