From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: "open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH] staging: new asus fan driver
Date: Tue, 5 Nov 2013 07:16:09 -0800 [thread overview]
Message-ID: <20131105151609.GA20950@kroah.com> (raw)
In-Reply-To: <CAMP44s0i-xCNHW_PPyO57p9yt0X_9OaYSQDkVPoNKum=nEHQbw@mail.gmail.com>
On Tue, Nov 05, 2013 at 08:29:40AM -0600, Felipe Contreras wrote:
> On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote:
> >> Simple driver to enable control of the fan in ASUS laptops. So far this
> >> has only been tested in ASUS Zenbook Prime UX31A, but according to some
> >> online reference [1], it should work in other models as well.
> >>
> >> The implementation is very straight-forward, the only caveat is that the
> >> fan speed needs to be saved after it has been manually changed because
> >> it won't be reported properly until it goes back to 'auto' mode.
> >>
> >> [1] http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html
> >>
> >> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> >> ---
> >>
> >> Two incarnations of this code exists [1][2], one that used ACPI methods
> >> directly, and one through WMI. Unfortunately the WMI version needs us to pass
> >> physicall addresses which is not exactly clean, and that's the only reason the
> >> code is proposed for staging.
> >>
> >> Most likely this cannot graduate until acpica gets support to receive virtual
> >> addresses.
> >
> > When is that going to happen?
>
> I don't know. Presumably when I get it done, which might be never, or
> a few days from now. Most likely it will take some time.
Then why not just merge this to the proper place, instead of relying on
staging? I don't want to have to have a staging driver that is waiting
on external things to get it merged, instead of issues with the driver
itself, as you are now putting the burden of maintenance on me, for no
good reason other than you being too "lazy" to get other stuff done :)
So, I really don't want this driver, sorry, please merge it to the
"proper" place in the kernel itself, fixing up the ACPI core to do so,
or just living with the driver as-is if you don't want to do that
work...
greg k-h
next prev parent reply other threads:[~2013-11-05 15:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 8:59 [PATCH] staging: new asus fan driver Felipe Contreras
2013-11-05 12:52 ` Greg Kroah-Hartman
2013-11-05 14:29 ` Felipe Contreras
2013-11-05 15:16 ` Greg Kroah-Hartman [this message]
2013-11-05 19:54 ` Felipe Contreras
2013-11-06 2:19 ` Greg Kroah-Hartman
2013-11-06 2:52 ` Felipe Contreras
2013-11-06 8:55 ` Greg Kroah-Hartman
2013-11-06 14:30 ` Matthew Garrett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131105151609.GA20950@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=devel@driverdev.osuosl.org \
--cc=felipe.contreras@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox