linux-kernel - Re: [PATCH v2] platform: x86: asus-wmi: add fan control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131014155254.GB20187@srcf.ucam.org>
Date:	Mon, 14 Oct 2013 16:52:54 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	"corentin.chary@...il.com" <corentin.chary@...il.com>,
	"acpi4asus-user@...ts.sourceforge.net" 
	<acpi4asus-user@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [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@...f.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@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/