[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150604051655.GC31158@fury.dvhart.com>
Date: Wed, 3 Jun 2015 22:16:55 -0700
From: Darren Hart <dvhart@...radead.org>
To: Pali Rohár <pali.rohar@...il.com>
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
Gabriele Mazzotta <gabriele.mzt@...il.com>,
Alex Hung <alex.hung@...onical.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Valdis.Kletnieks@...edu, Darren Hart <dvhart@...ux.intel.com>
Subject: Re: [PATCH v4 3/3] dell-laptop: Use dell-rbtn instead i8042 filter
when possible
On Wed, Jun 03, 2015 at 10:15:09AM +0200, Pali Rohár wrote:
> On Tuesday 02 June 2015 20:55:05 Darren Hart wrote:
> > On Wed, May 27, 2015 at 07:52:13PM -0700, Darren Hart wrote:
> > > On Wed, May 27, 2015 at 11:28:25PM +0200, Pali Rohár wrote:
> > > > Until now module dell-laptop registered rfkill device which used i8042
> > > > filter function for receiving HW switch rfkill events (handling special
> > > > keycode).
> > > >
> > > > But for some dell laptops there is native ACPI driver dell-rbtn which can
> > > > receive rfkill events (without i8042 hooks).
> > > >
> > > > So this patch will combine best from both sides. It will use native ACPI
> > > > driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for
> > > > enabling or disabling radio devices. If ACPI driver or device will not be
> > > > available fallback to i8042 filter function will be used.
> > > >
> > > > Patch also changes module_init() to late_initcall() to ensure that init
> > > > function will be called after initializing dell-rbtn.c driver.
> > > >
> > > > Signed-off-by: Pali Rohár <pali.rohar@...il.com>
> > > > Tested-by: Gabriele Mazzotta <gabriele.mzt@...il.com>
> > > > Signed-off-by: Darren Hart <dvhart@...ux.intel.com>
> > >
> > >
> > > Several basic checkpatch.pl errors in this one. Please always run checkpatch.pl
> > > before submitting patches, these sorts of issues should be caught before hitting
> > > the mailing list.
> > >
> > > Please provide some details on the scenarios you have tested to verify you have
> > > addressed the build and runtime issues reported.
> > >
> >
> > Checking in so this doesn't fall through the cracks. Do you have a v5 in the
> > works for the 4.2 merge window?
> >
> > Thanks,
> >
>
> In last days I did not have time to look at it... When do you need to
> see v5 if it could go to 4.2?
No rush in general, I just wanted to make sure you weren't waiting on me while I
was waiting for you.
We're at the mercy of Linus' decision regarding how many RCs before he releases
4.1. I suspect we have another week, but it could be this weekend.
I like to have new functionality in linux-next for two weeks prior to sending a
pull to Linus. To meet that, you should really have it in this weekend. If Linus
releases 4.1 this weekend, that will just barely make two weeks before the end
of the merge window.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
--
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/
Powered by blists - more mailing lists