| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Some HP BIOS has dummy WMI 0x05 cmd and it causes wireless set cmd to fail.
This patch fixes the problem by detecting "2009 BIOS or later" flag which
determines whether WMI 0x1b is supported and is used to replace WMI 0x05.
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Emitting an OOM message isn't necessary after input_allocate_device
as there's a generic OOM and a dump_stack already done.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Signed-off-by: Stephen Gildea <stepheng+linux@gildea.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Some BIOS versions/Vaio models apparently ship with two nearly identical
functions to handle backlight related controls.
The only difference seems to be:
If (LEqual (BUF1, 0x40))
{
Store (0x40, P80H)
Store (BUF2, Local0)
- And (Local0, One, Local0)
+ And (Local0, 0x03, Local0)
Store (Local0, ^^H_EC.KLPC)
}
Avoid erroring out on initialization and messing things up on cleanup
for now since we never call into these methods with anything different
than 1 or 0.
This issue was found on a Sony VPCSE1V9E/BIOS R2087H4.
Cc: Marco Krüger <krgsch@gmail.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
All my testing has been on laptops with a hw killswitch, so to be on the
safe side disable rfkill functionality on models without a hw killswitch for
now. Once we gather some feedback on laptops without a hw killswitch this
decision maybe reconsidered.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Setting force_rfkill will cause the dell-laptop rfkill code to skip its
whitelist checks, this will allow individual users to override the whitelist,
as well as to gather info from users to improve the checks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Some time is needed for the BIOS to do its work, but 250ms should be plenty.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Instead when hw-blocked always write 1 to the blocked bit for the radio in
question. This is necessary to properly set all the blocked bits for hw-switch
controlled radios to 1 after power-on and resume.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
This is necessary for 3 reasons:
1) To apply sw_state changes made while hw-blocked
2) To set all the blocked bits for hw-switch controlled radios to 1 when the
switch gets changed to off, this is necessary on some models to actually
turn the radio status LEDs off.
3) On some models non hw-switch controlled radios will have their block bit
cleared (potentially undoing a soft-block) on hw-switch toggle, this
restores the sw-block in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
This makes dell-laptop's rfkill code consistent with other drivers which
allow sw_state changes while hw blocked.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
On machines with a hardware switch, the blocking settings can not be changed
through a Fn + wireless-key combo, so there is no reason to read back the
blocking state from the BIOS.
Reading back is not only not necessary it is actually harmful, since on some
machines the blocking state will be cleared to all 0 after a wireless switch
toggle, even for radios not controlled by the hw-switch (yeah firmware bugs).
This causes "magic" changes to the sw_state. This is inconsistent with other
rfkill drivers which preserve the sw_state over a hw kill on / off.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
The query callback should only update the hw_state, see the comment in
net/rfkill/core.c in rfkill_set_block, which is its only caller.
rfkill_set_block will modify the sw_state directly after calling query so
calling set_sw_state is an expensive NOP.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
To ensure we don't enter any hw-switch related code paths on machines without
a hw-switch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
The rfkill functionality was removed from the dell-laptop driver because it
was causing problems on various non Latitude models, and the blacklist kept
growing and growing. In the thread discussing this Dell mentioned that they
only QA the rfkill acpi interface on Latitudes and indeed there have been
no blacklist entries for Latitudes.
Note that the blacklist contained no Vostros either, and most Vostros have
a hardware switch too, so we could consider supporting Vostros with a
hardware switch too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Without rfkill functionality in dell-laptop I have the following problems:
-If the hardware radio switch is set to disable the radio, then userspace
will still think it can use wireless and bluetooth.
-The wwan / 3g modem cannot be soft blocked without the dell-laptop rfkill
functionality
I know the rfkill functionality was removed from the dell-laptop driver because
it caused more problems then it fixed, and the blacklist for it was growing out
of control.
But in the thread discussing this Dell mentioned that they only QA the rfkill
acpi interface on Latitudes and indeed there have been no blacklist entries
for Latitudes. Therefor I would like to bring the rfkill functionality back
only for Latitudes. This patch is a straight-forward revert. The next patch
in this set will drop the blacklist and replace it with a Latitude check.
This reverts commit a6c2390cd6d2083d27a2359658e08f2d3df375ac.
Conflicts:
drivers/platform/x86/dell-laptop.c
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
This reverts commit ea1e7ed33708c7a760419ff9ded0a6cb90586a50.
Al points out that while the commit *does* actually create a separate
slab for the page->ptl allocation, that slab is never actually used, and
the code continues to use kmalloc/kfree.
Damien Wyart points out that the original patch did have the conversion
to use kmem_cache_alloc/free, so it got lost somewhere on its way to me.
Revert the half-arsed attempt that didn't do anything. If we really do
want the special slab (remember: this is all relevant just for debug
builds, so it's not necessarily all that critical) we might as well redo
the patch fully.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Kirill A Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Note that pmds[i] is simply uninitialized at that point...
Granted, it's very hard to hit (you need split page locks *and*
kmalloc(sizeof(spinlock_t), GFP_KERNEL) failing), but the code is
obviously bogus.
Introduced by commit 09ef4939850a ("x86: add missed
pgtable_pmd_page_ctor/dtor calls for preallocated pmds")
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
I've finally tracked down why my CR signal-unwind test case still
fails on little-endian. The problem turned to be that the kernel
installs a signal trampoline in the vDSO, and provides a DWARF CFI
record for that trampoline. This CFI describes the save location
for CR:
rsave (70, 38*RSIZE + (RSIZE - CRSIZE))
which is correct for big-endian, but points to the wrong word on
little-endian. This is wrong no matter which ABI.
In addition, for the ELFv2 ABI, we should not only provide a CFI
record for register 70 (cr2), but for all CR fields separately.
Strictly speaking, I guess this would mean providing two separate
vDSO images, one for ELFv1 processes and one for ELFv2 processes (or
maybe playing some tricks with conditional DWARF expressions).
However, having CFI records for the other CR fields in ELFv1 is not
actually wrong, they just will be ignored. So it seems the simplest
fix would be just to always provide CFI for all the fields.
Signed-off-by: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
Alex Hung
Joe Perches
Stephen Gildea
Mattia Dongili
Hans de Goede
Linus Torvalds
Al Viro
Ulrich Weigand