| Age | Commit message (Collapse) | Author |
|---|
|
Add sys_process_vm_readv and sys_process_vm_writev to Alpha.
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Acked-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Currently we export SOCK_NONBLOCK to user space but that conflicts with
the definition from glibc leading to compilation errors in user programs
(e.g. see Debian bug #658460).
The generic socket.h restricts the definition of SOCK_NONBLOCK to the
kernel, as does the MIPS specific socket.h, so let's do the same on
Alpha.
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Acked-by: Matt Turner <mattst88@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
commit af7f2158fde was done against master, and clashed with structured
logging's change of KERN_LEVEL to SOH.
Bisected and fixed by Markus Trippelsdorf.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jason Baron <jbaron@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Pull ARM fixes from Russell King:
"The largest thing in this set of changes is bringing back some of the
ARMv3 code to fix a compile problem noticed on RiscPC, which we still
support, even though we only support ARMv4 there.
(The reason is that the system bus doesn't support ARMv4 half-word
accesses, so we need the ARMv3 library code for this platform.)
The rest are all quite minor fixes."
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7490/1: Drop duplicate select for GENERIC_IRQ_PROBE
ARM: Bring back ARMv3 IO and user access code
ARM: 7489/1: errata: fix workaround for erratum #720789 on UP systems
ARM: 7488/1: mm: use 5 bits for swapfile type encoding
ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present
ARM: 7486/1: sched_clock: update epoch_cyc on resume
ARM: 7484/1: Don't enable GENERIC_LOCKBREAK with ticket spinlocks
ARM: 7483/1: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled
ARM: 7482/1: topology: fix section mismatch warning for init_cpu_topology
|
|
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael J. Wysocki:
- Fixes for three obscure problems in the runtime PM core code found
recently.
- Two fixes for the new "coupled" cpuidle code from Colin Cross and Jon
Medhurst.
- intel_idle driver fix from Konrad Rzeszutek Wilk.
* tag 'pm-for-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it.
cpuidle: Prevent null pointer dereference in cpuidle_coupled_cpu_notify
cpuidle: coupled: fix sleeping while atomic in cpu notifier
PM / Runtime: Check device PM QoS setting before "no callbacks" check
PM / Runtime: Clear power.deferred_resume on success in rpm_suspend()
PM / Runtime: Fix rpm_resume() return value for power.no_callbacks set
|
|
Some of the arguments to {g,s}etsockopt are passed in userland pointers.
If we try to use the 64bit entry point, we end up sometimes failing.
For example, dhcpcd doesn't run in x32:
# dhcpcd eth0
dhcpcd[1979]: version 5.5.6 starting
dhcpcd[1979]: eth0: broadcasting for a lease
dhcpcd[1979]: eth0: open_socket: Invalid argument
dhcpcd[1979]: eth0: send_raw_packet: Bad file descriptor
The code in particular is getting back EINVAL when doing:
struct sock_fprog pf;
setsockopt(s, SOL_SOCKET, SO_ATTACH_FILTER, &pf, sizeof(pf));
Diving into the kernel code, we can see:
include/linux/filter.h:
struct sock_fprog {
unsigned short len;
struct sock_filter __user *filter;
};
net/core/sock.c:
case SO_ATTACH_FILTER:
ret = -EINVAL;
if (optlen == sizeof(struct sock_fprog)) {
struct sock_fprog fprog;
ret = -EFAULT;
if (copy_from_user(&fprog, optval, sizeof(fprog)))
break;
ret = sk_attach_filter(&fprog, sk);
}
break;
arch/x86/syscalls/syscall_64.tbl:
54 common setsockopt sys_setsockopt
55 common getsockopt sys_getsockopt
So for x64, sizeof(sock_fprog) is 16 bytes. For x86/x32, it's 8 bytes.
This comes down to the pointer being 32bit for x32, which means we need
to do structure size translation. But since x32 comes in directly to
sys_setsockopt, it doesn't get translated like x86.
After changing the syscall table and rebuilding glibc with the new kernel
headers, dhcp runs fine in an x32 userland.
Oddly, it seems like Linus noted the same thing during the initial port,
but I guess that was missed/lost along the way:
https://lkml.org/lkml/2011/8/26/452
[ hpa: tagging for -stable since this is an ABI fix. ]
Bugzilla: https://bugs.gentoo.org/423649
Reported-by: Mads <mads@ab3.no>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Link: http://lkml.kernel.org/r/1345320697-15713-1-git-send-email-vapier@gentoo.org
Cc: H. J. Lu <hjl.tools@gmail.com>
Cc: <stable@vger.kernel.org> v3.4..v3.5
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
the way it abuses ->d_fsdata still needs to be killed, but that's
a separate story.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
The CONFIG_PM doesn't actually enable any of the PM callbacks, it
only allows to enable CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME.
This means if CONFIG_PM is used to protect system sleep callbacks
then it may end up unreferenced if only runtime PM is enabled.
Hence protecting sleep callbacks with CONFIG_PM_SLEEP.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
Pull vfs fixes from Miklos Szeredi.
This mainly fixes some confusion about whether the open 'mode' variable
passed around should contain the full file type (S_IFREG etc)
information or just the permission mode. In particular, the lack of
proper file type information had confused fuse.
* 'vfs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
vfs: fix propagation of atomic_open create error on negative dentry
fuse: check create mode in atomic open
vfs: pass right create mode to may_o_create()
vfs: atomic_open(): fix create mode usage
vfs: canonicalize create mode in build_open_flags()
|
|
The master_xfer function returns 0 on success. It should return the number of
successful transactions.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
|
In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
failure.
Without this, after a failed xfer, the runtime PM usecount will have
been incremented, but not decremented causing the usecount to never
reach zero after a failure. This keeps the device always runtime PM
enabled which keeps the enclosing power domain active, and prevents
full-chip retention/off from happening during idle.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
|
At this moment in time there is only one known configuration for the
Nomadik I2C driver. By not holding that configuration in the driver
adds some unnecessary overhead in platform code. The configuration
has already been removed from platform code, this patch checks for any
over-riding configurations. If there aren't any, the default is used.
[LinusW says: "Right now this is causing boot regressions so we need it
badly..."]
Acked-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
|
If a device specifies zero endpoints in its interface descriptor,
the kernel oopses in acm_probe(). Even though that's clearly an
invalid descriptor, we should test wether we have all endpoints.
This is especially bad as this oops can be triggered by just
plugging a USB device in.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Pavel Machek <pavel@ucw.cz>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: "John W. Linville" <linville@tuxdriver.com>
CC: Eliad Peller <eliad@wizery.com>
CC: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Forest Bond <forest@alittletooquiet.net>
CC: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Jesper Juhl <jj@chaosbits.net>
CC: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Herton Ronaldo Krzesinski <herton@canonical.com>
CC: Hin-Tak Leung <htl10@users.sourceforge.net>
CC: Larry Finger <Larry.Finger@lwfinger.net>
CC: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Christian Lamparter <chunkeey@googlemail.com>
CC: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Hans de Goede <hdegoede@redhat.com>
CC: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Hans de Goede <hdegoede@redhat.com>
CC: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.
Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Mauro Carvalho Chehab <mchehab@infradead.org>
CC: Michael Krufky <mkrufky@linuxtv.org>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Doron Cohen <doronc@siano-ms.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Pull md fixes from NeilBrown:
"2 fixes for md, tagged for -stable"
* tag 'md-3.6-fixes' of git://neil.brown.name/md:
md/raid10: fix problem with on-stack allocation of r10bio structure.
md: Don't truncate size at 4TB for RAID0 and Linear
|
|
This patch fixes a regression bug with the handling of zero-length
data CDBs within transport_generic_new_cmd() code. The bug was introduced
with the following commit as part of the single task conversion work:
commit 4101f0a89d4eb13f04cb0344d59a335b862ca5f9
Author: Christoph Hellwig <hch@infradead.org>
Date: Tue Apr 24 00:25:03 2012 -0400
target: always allocate a single task
where the zero-length check for SCF_SCSI_DATA_SG_IO_CDB was incorrectly
changed to SCF_SCSI_CONTROL_SG_IO_CDB because of the seperate comment
in transport_generic_new_cmd() wrt to control CDBs zero-length handling
introduced in:
commit 91ec1d3535b2acf12c599045cc19ad9be3c6a47b
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Fri Jan 13 12:01:34 2012 -0800
target: Add workaround for zero-length control CDB handling
So go ahead and change transport_generic_new_cmd() to handle control+data
zero-length CDBs in the same manner for this special case.
Tested with iscsi-target + loopback fabric port LUNs on 3.6-rc0 code.
This patch will also need to be picked up for 3.5-stable.
(hch: Add proper comment in transport_generic_new_cmd)
Cc: Christoph Hellwig <hch@lst.de>
Cc: Roland Dreier <roland@purestorage.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|
|
A 'struct r10bio' has an array of per-copy information at the end.
This array is declared with size [0] and r10bio_pool_alloc allocates
enough extra space to store the per-copy information depending on the
number of copies needed.
So declaring a 'struct r10bio on the stack isn't going to work. It
won't allocate enough space, and memory corruption will ensue.
So in the two places where this is done, declare a sufficiently large
structure and use that instead.
The two call-sites of this bug were introduced in 3.4 and 3.5
so this is suitable for both those kernels. The patch will have to
be modified for 3.4 as it only has one bug.
Cc: stable@vger.kernel.org
Reported-by: Ivan Vasilyev <ivan.vasilyev@gmail.com>
Tested-by: Ivan Vasilyev <ivan.vasilyev@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
functions
Suspend and resume functions call spi_master_get() without matching
spi_master_put(). The extra references are unnecessary and cause
subsequent module unload attempts to fail, so drop the calls.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The call sequence spi_alloc_master/spi_register_master/spi_unregister_master is
complete; it reduces the device reference count to zero, which and results in
device memory being freed. The subsequent call to spi_master_put is unnecessary
and results in an access to free memory. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
amba drivers does not need to enable pm runtime at probe.
amba_probe already enables pm runtime.
This rids this warning in the ux500 boot log:
ssp-pl022 ssp0: Unbalanced pm_runtime_enable!
Signed-off-by: Michel JAOUEN <michel.jaouen@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The capture volume increases with the register value so it shouldn't be
flagged as inverted.
Reported-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Currently the microphone input source is not selectable as while there is
a DAPM widget it's not connected to anything so it won't be properly
instantiated. Add something more correct for the input structure to get
things going, even though it's not hooked into the rest of the routing
map and so won't actually achieve anything except allowing the relevant
register bits to be written.
Reported-by: Christop Fritz <chf.fritz@googlemail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
|
|
It will be removed from future device revisions.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2 evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event.
So in order to read the tablet sensor data as it happens we need to
ensure that we always call input_sync() after input_report_switch()
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.
Test on V490u
=============
== After the patch ==
[ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/
[ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown
[ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX
[ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled
[ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode
[ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
[ 1350.307082] Registered led device: tpacpi::thinklight
[ 1350.307215] Registered led device: tpacpi::power
[ 1350.307255] Registered led device: tpacpi::standby
[ 1350.307294] Registered led device: tpacpi::thinkvantage
[ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
[ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
[ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14
== Before the patch ==
sudo modprobe thinkpad_acpi
FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device
Test on B485
=============
This patch was also test in a B485 where the thinkpad_acpi module does not
have any issues loading. But, I tested it to make sure this patch does not
break on already functioning models of Lenovo products.
[13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/
[13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown
[13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01
[13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
[13486.752883] Registered led device: tpacpi::thinklight
[13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
[13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
[13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
Fixed the typo introduced from the below commit
5f1e88f dell-laptop: Add 6 machines to touchpad led quirk
Reported-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
This callback is a no-op in nouveau, and the upcoming apple-gmux
switcheroo support won't require it either. Rather than forcing drivers
to stub it out, just make it optional and remove the callback from
nouveau.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
vga_switcheroo assumes that the handler will be registered before the
last client, otherwise switching will not be enabled. Likewise it's
assumed that the handler will not be unregistered without at least one
client also being unregistered, otherwise switching will remain enabled
despite no longer having a handler. These assumptions cannot be enforced
if the handler is in a separate driver from both clients, as with the
gmux found in Apple laptops. Remove this assumption.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
Add support for the gmux display muxing functionality and register a mux
handler with vga_switcheroo.
Signed-off-by: Andreas Heider <andreas@meetr.de>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
Fix the dependencies of apple-gmux to prevent it from being built-in
when one or more of its dependencies is built as a module. Otherwise it
can fail to build due to missing symbols.
v2: Add dependency on ACPI to fix build failure when ACPI=n
Reported-by: Arun Raghavan <arun.raghavan@collabora.co.uk>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
If the user bit is set, that mean BIOS can't set and record the wlan
status, it will report the value read from id ASUS_WMI_DEVID_WLAN_LED
(0x00010012) while we query the wlan status by id ASUS_WMI_DEVID_WLAN
(0x00010011) through WMI.
So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED
(0x00010012) while setting the wlan status through WMI.
This is also the behavior that windows app will do.
Quote from ASUS application engineer
===
When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return
(1) 0x00050001 (On)
(2) 0x00050000 (Off)
(3) 0x00030001 (On)
(4) 0x00030000 (Off)
(5) 0x00000002 (Unknown)
(1), (2) means that the model has hardware GPIO for WLAN, you can call
WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off.
(3), (4) means that the model doesn’t have hardware GPIO, you need to use
API or driver library to turn WLAN on/off, and call
WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status.
After you set WLAN LED status, you can see the WLAN status is changed with
WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly
(ex: Windows), you can use it for synchronization.
(5) means that the model doesn’t have WLAN device.
WLAN is the ONLY special case with upper rule.
For other device, like Bluetooth, you just need use
WMIMethod(DSTS, 0x00010013) to get, and WMIMethod(DEVS, 0x00010013, 1 or 0)
to set.
===
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
We were only calling acpi_video_unregister() if ACPI video support was built
in, not if it was a module.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
New gmux devices have a different method for accessing the registers.
Update the driver to cope. Incorporates feedback from Bernhard Froemel.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Bernhard Froemel <froemel@vmars.tuwien.ac.at>
Cc: Seth Forshee <seth.forshee@canonical.com>
|
|
Move the special-cased backlight update function to a generic gmux_write32
function.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
Pull infiniband/rdma fixes from Roland Dreier:
"Grab bag of InfiniBand/RDMA fixes:
- IPoIB fixes for regressions introduced by path database conversion
- mlx4 fixes for bugs with large memory systems and regressions from
SR-IOV patches
- RDMA CM fix for passing bad event up to userspace
- Other minor fixes"
* tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/mlx4: Check iboe netdev pointer before dereferencing it
mlx4_core: Clean up buddy bitmap allocation
mlx4_core: Fix integer overflow issues around MTT table
mlx4_core: Allow large mlx4_buddy bitmaps
IB/srp: Fix a race condition
IB/qib: Fix error return code in qib_init_7322_variables()
IB: Fix typos in infiniband drivers
IB/ipoib: Fix RCU pointer dereference of wrong object
IB/ipoib: Add missing locking when CM object is deleted
RDMA/ucma.c: Fix for events with wrong context on iWARP
RDMA/ocrdma: Don't call vlan_dev_real_dev() for non-VLAN netdevs
IB/mlx4: Fix possible deadlock on sm_lock spinlock
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull TTY fixes from Greg Kroah-Hartman:
"Here are 4 tiny patches, each fixing a serial driver problem that
people have reported.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'tty-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
pmac_zilog,kdb: Fix console poll hook to return instead of loop
serial: mxs-auart: fix the wrong RTS hardware flow control
serial: ifx6x60: fix paging fault on spi_register_driver
serial: Change Kconfig entry for CLPS711X-target
|
|
If the machine is booted without any cpu_idle driver set
(b/c disable_cpuidle() has been called) we should follow
other users of cpu_idle API and check the return value
for NULL before using it.
Reported-and-tested-by: Mark van Dijk <mark@internecto.net>
Suggested-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
When a kernel is built to support multiple hardware types it's possible
that CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is set but the hardware the
kernel is run on doesn't support cpuidle and therefore doesn't load a
driver for it. In this case, when the system is shut down,
cpuidle_coupled_cpu_notify() gets called with cpuidle_devices set to
NULL. There are quite possibly other circumstances where this
situation can also occur and we should check for it.
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
The cpu hotplug notifier gets called in both atomic and non-atomic
contexts, it is not always safe to lock a mutex. Filter out all events
except the six necessary ones, which are all sleepable, before taking
the mutex.
Signed-off-by: Colin Cross <ccross@android.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If __dev_pm_qos_read_value(dev) returns a negative value,
rpm_suspend() should return -EPERM for dev even if its
power.no_callbacks flag is set. For this to happen, the device's
power.no_callbacks flag has to be checked after the PM QoS check,
so move the PM QoS check to rpm_check_suspend_allowed() (this will
make it cover idle notifications as well as runtime suspend too).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
|
|
The power.deferred_resume can only be set if the runtime PM status
of device is RPM_SUSPENDING and it should be cleared after its
status has been changed, regardless of whether or not the runtime
suspend has been successful. However, it only is cleared on
suspend failure, while it may remain set on successful suspend and
is happily leaked to rpm_resume() executed in that case.
That shouldn't happen, so if power.deferred_resume is set in
rpm_suspend() after the status has been changed to RPM_SUSPENDED,
clear it before calling rpm_resume(). Then, it doesn't need to be
cleared before changing the status to RPM_SUSPENDING any more,
because it's always cleared after the status has been changed to
either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
|
|
For devices whose power.no_callbacks flag is set, rpm_resume()
should return 1 if the device's parent is already active, so that
the callers of pm_runtime_get() don't think that they have to wait
for the device to resume (asynchronously) in that case (the core
won't queue up an asynchronous resume in that case, so there's
nothing to wait for anyway).
Modify the code accordingly (and make sure that an idle notification
will be queued up on success, even if 1 is to be returned).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
|
