[PATCH 0/3] Updating lenovo-sl-laptop driver
stefan.bader at canonical.com
Wed Aug 26 14:56:07 UTC 2009
Tim Gardner wrote:
> Ike Panhc wrote:
>> Updating lenovo-sl-laptop driver with 2 patches. The first patch is pulled from
>> upstream, the author rewrite it to make it works at 2.6.31 and add WWAN UWB
>> supportting with rfkill. The second patch is for a feedback from linux-acpi
>> mailing list, using event-driving method for detecting hotkey event instead of
>> using kthread to scan. This will save some CPU time and power consumption. The
>> third patches is not to keep this driver from building.
>> The following changes since commit 8cc00dba85d31a342be634160257f81304cee8fd:
>> Leann Ogasawara (1):
>> UBUNTU: [Upstream] (drop after 2.6.31) drm/i915: increase default latency constant
>> are available in the git repository at:
>> git://kernel.ubuntu.com/ikepanhc/ike-karmic.git lenovo-sl-laptop
>> Ike Panhc (3):
>> UBUNTU: [Upstream] Pull lastest updating of lenovo-sl-laptop
>> UBUNTU: Using event driving method hotkey function
>> UBUNTU: [Config] Let lenovo-sl-laptop build
>> ubuntu/Makefile | 2 +-
>> ubuntu/lenovo-sl-laptop/README | 3 +-
>> ubuntu/lenovo-sl-laptop/lenovo-sl-laptop.c | 589 ++++++++++++++++------------
>> 3 files changed, 336 insertions(+), 258 deletions(-)
> NACK - How about some test results? This driver _will_ get loaded on the
> Lenovo laptops referenced in the MODULE_ALIAS statements, so I want
> assurance that users have successfully used this driver, _and_ that
> their kittens are still alive. It seems that a Launchpad bug might be in
> order to track status.
> I would also like the patch 'UBUNTU: Using event driving method hotkey
> function' to come directly from the upstream developer as it could use
> some peer review. Its almost certain that this gem wouldn't pass muster:
> + if (0 <= --level)
> as well as a number of formatting problems. scripts/checkpatch.pl is
> your friend.
> In general, there are a number of formatting issues with both patches.
> Has Alexandre Rostovtsev made any attempt to get this driver into the
> mainline kernel?
The general problem with Alexandre is that he sometimes responds and often not.
So Hugh and me suggested that Ike goes ahead and will try to upstream these
changes but also tries to get them into karmic as this is something that set
Ubuntu ahead (*wink*).
He likely can supply you with test results as he has the hardware in question
But surely formatting should be checkpatch-happy and a tracking bug might be
When all other means of communication fail, try words!
More information about the kernel-team