| Age | Commit message (Collapse) | Author |
|---|
|
ACPI drivers must not be bound to device objects having scan handlers
attatched to them, so make acpi_device_probe() fail with -EINVAL if the
device object being probed has an ACPI scan handler.
After this change the analogous check introduced into the ACPI video
driver by commit 8c9b7a7 (ACPI / video: Do not bind to device objects
with a scan handler) is not necessary any more and may be dropped, so
drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Tony Luck <tony.luck@gmail.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
|
|
The IA64 System Bus Adapter (SBA) I/O MMU driver uses an ACPI driver
object to look for device objects it needs in the ACPI namespace, but
that leads to an ordering issue between that driver and the container
scan handler on ia64 HP rx2600.
Namely, on that machine the SBA I/O MMU device object in the ACPI
namespace has a _HID returning its own specific device ID and a
_CID returning a generic container device ID. According to Toshi
Kani, the idea is that if a _HID is not mached by an I/O MMU driver,
the _CID should be matched by a generic container driver, so those
device IDs should be used mutually exclusively.
That is not what happens, however, because the container driver uses
an ACPI scan handler which is matched against the device object in
question before registering the SBA I/O MMU driver object. As a
result, that scan handler claims the device object first. The driver
binds to the same device object later, however, and they both happily
use it simultaneously going forward (fortunately, that doesn't cause
any real breakage to happen).
To avoid that ordering issue, make the SBA I/O MMU code use an ACPI
scan handler instead of an ACPI driver, so that it can claim the SBA
I/O MMU device object before the container driver (thanks to an
improved algorithm of matching ACPI device IDs used for ACPI scan
handlers, which matches device _HIDs against the registered scan
handlers before _CIDs).
This also reduces the kernel's memory footprint slightly by
avoiding to register a driver object that's not used after system
initialization, so having it registered (and present in sysfs)
throughout the system's life time isn't particularly useful.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Tony Luck <tony.luck@gmail.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into next/soc
From Linus Walleij:
This is a patch series that:
- Pulls the Integrator/AP PCI bridge driver into one file
- Adds full device tree support for it
- Keeps ATAG support around for the time being
* tag 'integrator-pci-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator:
ARM: integrator: basic PCIv3 device tree support
ARM: integrator: move static ioremapping into PCIv3 driver
ARM: integrator: move VGA base assignment
ARM: integrator: remap PCIv3 base dynamically
ARM: integrator: move V3 register definitions into driver
ARM: integrator: move PCI base address grab to probe
ARM: integrator: grab PCI error IRQ in probe()
ARM: integrator: convert PCIv3 bridge to platform device
ARM: integrator: merge PCIv3 driver into one file
ARM: pci: create pci_common_init_dev()
Documentation/devicetree: add a small note on PCI
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Add product id for Abbott strip port cable for Precision meter which
uses the TI 3410 chip.
Signed-off-by: Anders Hammarquist <iko@iko.pp.se>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without
_PSC during initialization) introduced a regression on some systems
with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
need to be powered up during initialization, but their device objects
in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
resources).
To work around this problem, make the ACPI LPSS driver power up
devices it knows about by using a new helper function
acpi_device_fix_up_power() that does all of the necessary
sanity checks and calls acpi_dev_pm_explicit_set() to put the
device into D0.
Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 781d737 (ACPI: Drop power resources driver) introduced a
bug in the power resources initialization error code path causing
a NULL pointer to be referenced in acpi_release_power_resource()
if there's an error triggering a jump to the 'err' label in
acpi_add_power_resource(). This happens because the list_node
field of struct acpi_power_resource has not been initialized yet
at this point and doing a list_del() on it is a bad idea.
To prevent this problem from occuring, initialize the list_node
field of struct acpi_power_resource upfront.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
USB Host PHY clock on port 2 must be configured to 19.2MHz.
Provide this information.
Cc: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
|
|
On Panda the +5V supply for DVI EDID is supplied by the
same regulator that poweres the USB Hub. Currently, the
DSS/DVI subsystem doesn't know how to manage this regulator
and so DVI EDID reads will fail if USB Hub is not enabled.
As a temporary fix we keep this regulator permanently enabled
on boot. This fixes the DVI EDID read problem.
CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
|
|
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
HACK: The reset control need to be replaced with the proper
gpio-controlled reset driver as soon it will be merged [1].
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
Signed-off-by: Roger Quadros <rogerq@ti.com>
[benoit.cousson@linaro.org: Add disclaimer about the reset control
inside changelog and code]
Cc: Florian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
|
|
Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and
memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
called under acpi_scan_lock, but currently the following scenario
violating that requirement is possible:
write_undock()
handle_eject_request()
hotplug_dock_devices()
dock_remove_acpi_device()
acpi_bus_trim()
Fix that by making write_undock() acquire acpi_scan_lock before
calling handle_eject_request() as appropriate (begin_undock() is
under the lock too in analogy with acpi_dock_deferred_cb()).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
|
|
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Extend the comment explaining the condition for discarding
out-of-range values to clarify the cases in which devices don't
provide any logical min/max.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Commit 6da7066906e977d42104a859c490f5f9a300488c introduced in 3.3
"HID: ignore absolute values which don't fit between logical min and max"
prevents some Posiflex touch screen to work because they do not provide
logical min and max for their buttons.
Thus, logical min and max are at 0, discarding the buttons events, and
preventing the device to report appropriate X Y.
Adding a check on "min < max" solves the problem.
Reported-by: Jan Kandziora <jjj@gmx.de>
Tested-by: Jan Kandziora <jjj@gmx.de>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
We are in the process of removing all the __cpuinit annotations.
While working on making that change, an existing problem was
made evident:
WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
in reference from the function cpu_init() to the function
.init.text:load_ucode_ap() The function cpu_init() references
the function __init load_ucode_ap(). This is often because cpu_init
lacks a __init annotation or the annotation of load_ucode_ap is wrong.
This now appears because in my working tree, cpu_init() is no longer
tagged as __cpuinit, and so the audit picks up the mismatch. The 2nd
hypothesis from the audit is the correct one, as there was an incorrect
__init tag on the prototype in the header (but __cpuinit was used on
the function itself.)
The audit is telling us that the prototype's __init annotation took
effect and the function did land in the .init.text section. Checking
with objdump on a mainline tree that still has __cpuinit shows that
the __cpuinit on the function takes precedence over the __init on the
prototype, but that won't be true once we make __cpuinit a no-op.
Even though we are removing __cpuinit, we temporarily align both
the function and the prototype on __cpuinit so that the changeset
can be applied to stable trees if desired.
[ hpa: build fix only, no object code change ]
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: stable <stable@vger.kernel.org> # 3.9+
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
The acpi_dev_pm_get_state() function defined in device_pm.c is quite
convoluted, which isn't really necessary, and it doesn't validate the
values returned by the ACPI methods executed by it appropriately.
To address these shortcomings modify it in the following way.
(1) Make its return value only mean whether or not it succeeded and
pass the device power states determined by it through pointers.
(2) Drop the d_max_in argument, used by only one of its callers,
from it, and move the code related to d_max_in into that caller,
acpi_pm_device_sleep_state().
(3) Make it always check the return value of acpi_evaluate_integer()
and handle failures as appropriate. Moreover, make it check if
the values returned by the executed ACPI methods are not out of
range.
(4) Make it check if the values returned by the executed ACPI
methods represent valid power states of the given device and
handle situations in which that's not the case gracefully.
Also update the kerneldoc comments of acpi_dev_pm_get_state() and
acpi_pm_device_sleep_state() to reflect the code changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The two symbols ACPI_STATE_D3 and ACPI_STATE_D3_COLD actually
represent the same number (4), but ACPI_STATE_D3 is slightly
ambigugous, because it may not be clear that it really means D3cold
and not D3hot at first sight.
Remove that ambiguity from drivers/acpi/device_pm.c by making it
use ACPI_STATE_D3_COLD everywhere instead of ACPI_STATE_D3.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is a name clash between function acpi_device_power_state()
defined in drivers/acpi/device_pm.c and structure type
acpi_device_power_state defined in include/acpi/acpi_bus.h, which
may be resolved by renaming the function. Additionally, that
funtion may be made static, because it is not used anywhere outside
of the file it is defined in.
Rename acpi_device_power_state() to acpi_dev_pm_get_state(), which
better reflects its purpose, and make it static.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since acpi_processor_suspend() and acpi_processor_resume() need not
be visible outside of the file they are defined in, make them
static.
[rjw: Changelog]
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
We piggyback on "x86/acpi: Provide registration for acpi_suspend_lowlevel."
to register a Xen version of the callback. The callback does not
do anything special - except it omits the x86_acpi_suspend_lowlevel.
This is necessary b/c during suspend the generic code tries to write
cr3 values that clashes with what the hypervisor has set up for the guest.
Signed-off-by: Liang Tang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ben Guthro <benjamin.guthro@citrix.com>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Which by default will be x86_acpi_suspend_lowlevel.
This registration allows us to register another callback
if there is a need to use another platform specific callback.
Signed-off-by: Liang Tang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ben Guthro <benjamin.guthro@citrix.com>
Acked-by: "H. Peter Anvin" <hpa@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
suprise_removal_ok and performance_manageable in struct
acpi_device_flags are not used by any code. So, remove
them.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
These local variables are all initialized at their first use, so there's
no point in initializing them earlier.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add or remove spaces that give errors or warnings from checkpatch.pl.
Signed-off-by: Nicholas Mazzuca <nicholas@mazzucastuff.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Once do_acpi_find_child() has found the first matching handle, it
makes the acpi_get_child() loop stop and return that handle. On some
platforms, though, there are multiple devices with the same value of
"_ADR" in the same namespace scope, and if one of them is enabled,
the others will be disabled. For example:
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV0
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV1
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV2
If DEV0 and DEV1 are disabled and DEV2 is enabled, the handle of DEV2
should be returned, but actually the function always returns the
handle of DEV0.
To address that issue, make do_acpi_find_child() evaluate _STA to
check the device status. If a matching device object exists, but is
disabled, acpi_get_child() will continue to walk the namespace in the
hope of finding an enabled one. If one is found, its handle will be
returned, but otherwise the function will return the handle of the
disabled object found before (in case it is enabled going forward).
[rjw: Changelog]
Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Correct the related comments for '#ifdef ... #endif'.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
User space pointer may not be dereferenced. Use get_user()/put_user()
instead and check their return codes.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch correctly distinguishes two boundary conditions:
1. When the given range is entire within the unaccounted space between
two rgrps, and
2. The range begins beyond the end of the filesystem
Also fix the unit of the returned value r.len (total trimming) to be in bytes
instead of the (incorrect) 512 byte blocks
With this patch, GFS2 passes multiple iterations of all the relevant xfstests
(251, 260, 288) with different fs block sizes.
Signed-off-by: Abhi Das <adas@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
|
|
This patch fixes a warning message introduced in the recent
"GFS2: aggressively issue revokes in gfs2_log_flush" patch.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
|
|
Local symbols accessed only in this file are made static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
It seems there is no user of the wp_gpio driver in the kernel. Let's remove it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This patch makes sure blink hardware is disabled for selected GPIO. Blink
hardware is controled by GPO_BLINK register and is available for GPIOs from 0
to 31.
Signed-off-by: Vincent Donnefort <vdonnefort@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
Signed-off-by: Mark Brown <broonie@linaro.org>
|
|
The 64xx spi driver supports partial polling mode.
Only the last chunk of the transfer length is transferred
or recieved in polling mode.
Some SoC's that adopt this controller might not have have dma
interface. This patch adds support for complete polling mode
and gives flexibity for the user to select poll/dma mode.
Signed-off-by: Girish K S <ks.giri@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
