Since the FORCE_EJECT symbol is never defined, the
#ifndef FORCE_EJECT in acpi_eject_store() is always true, so drop it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
Tested-by: NToshi Kani <toshi.kani@hp.com>

When acpi_device_install_notify_handler() failed in acpi_device_probe(),
it calls acpi_drv->ops.remove() and fails the probe.  However, the ACPI
driver is left bound to the acpi_device.  Fix it by clearing the driver
and driver_data fields.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Changed sysfs eject, acpi_eject_store(), so that it doesn't return
error codes for devices nodes with ACPI scan handlers attached and
no ACPI drivers.

[rjw: Changelog]
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The IDs of ACPI device nodes stored in their pnp.ids member arrays
are sorted by decreasing priority (i.e. the highest-priority ID is
the first entry).  This means that when matching scan handlers to
device nodes, the namespace scanning code should walk the list of
scan handlers for each device node ID instead of walking the list
of device node IDs for each handler (the latter causes the first
handler matching any of the device node IDs to be chosen, although
there may be another handler matching an ID of a higher priority
which should be preferred).  Make the code follow this observation.

This change has been suggested and justified by Toshi Kani.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

Trivial changes to replace printk(KERN_xxx) with pr_xxx().
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

acpi_bus_get_device() returns int not acpi_status.

The patch change not to apply ACPI_SUCCESS() to the return value of
acpi_bus_get_device().
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Make acpi_bus_get_parent() more straightforward and remove an
unnecessary local variable ret from it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Currently, the ACPI namespace scanning code creates platform device
objects for ACPI device nodes whose IDs match the contents of the
acpi_platform_device_ids[] table.  However, this adds a superfluous
special case into acpi_bus_device_attach() and makes it more
difficult to follow than it has to be.  It also will make it more
difficult to implement removal code for those platform device objects
in the future.

For the above reasons, introduce a struct acpi_scan_handler object
for creating platform devices and move the code related to that from
acpi_bus_device_attach() to the .attach() callback of that object.
Also move the acpi_platform_device_ids[] table to acpi_platform.c.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Make the ACPI PCI IRQ link driver use struct acpi_scan_handler
for representing the object used to set up ACPI interrupt links and
to remove data structures used for this purpose before unregistering
the corresponding ACPI device nodes.

This simplifies the code slightly and reduces the kernel's memory
footprint by avoiding the registration of a struct device_driver
object with the driver core and creation of its sysfs directory
which is unnecessary.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>

Make the ACPI PCI root bridge driver use struct acpi_scan_handler
for representing the object used to enumerate the PCI busses under
PCI host bridges found in the ACPI namespace (and to tear down data
structures representing the bus and devices on it before
unregistering the host bridges' ACPI device nodes).

This simplifies the code slightly and reduces the kernel's memory
footprint by avoiding the registration of a struct device_driver
object with the driver core and creation of its sysfs directory
which is unnecessary.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>

Introduce struct acpi_scan_handler for representing objects that
will do configuration tasks depending on ACPI device nodes'
hardware IDs (HIDs).

Currently, those tasks are done either directly by the ACPI namespace
scanning code or by ACPI device drivers designed specifically for
this purpose.  None of the above is desirable, however, because
doing that directly in the namespace scanning code makes that code
overly complicated and difficult to follow and doing that in
"special" device drivers leads to a great deal of confusion about
their role and to confusing interactions with the driver core (for
example, sysfs directories are created for those drivers, but they
are completely unnecessary and only increase the kernel's memory
footprint in vain).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

Make acpi_bus_scan_fixed() use device_attach() directly to attach
drivers, if any, to the fixed devices in analogy with how
acpi_bus_scan() works, which allows the last argument of
acpi_add_single_object() to be dropped and the manipulation of the
flags.match_driver bit to be moved to acpi_init_device_object()
and acpi_device_add_finalize().

After these changes all of the functions for the initialization
and registration of struct acpi_device objects work in the same
way for all of them.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Fix /proc/acpi/wakeup for devices without bus or parent

This patch fixes printing the wakeup status for devices without a bus
or parent, such as laptop lid switches and sleep buttons. These devices
have an empty physical_node_list, because acpi_bind_one is never run
for them.

[rjw: White space and coding style.]
Signed-off-by: NAndreas Fleig <andreasfleig@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is no guarantee that acpi_bus_scan() and acpi_bus_trim() will
not be run in parallel for the same scope of the ACPI namespace,
which may lead to a great deal of confusion, so introduce a new mutex
to prevent that from happening.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

The second argument of ACPI driver .remove() operation is only used
by the ACPI processor driver and the value passed to that driver
through it is always available from the given struct acpi_device
object's removal_type field.  For this reason, the second ACPI driver
.remove() argument is in fact useless, so drop it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NJiang Liu <jiang.liu@huawei.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Since acpi_bus_trim() cannot fail, change its definition to a void
function, so that its callers don't check the return value in vain
and update the callers.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>

During system resume we check if there are power resources that have
been turned off by the BIOS, but our reference counters for them
are nonzero (they need to be turned on then).  It turns out, however,
that we also need to check the opposite, i.e. if there are power
resources that have been turned on by the BIOS, but our reference
counters for them are zero (which means that no devices are going
to need them any time soon) and we should turn them off.

Make the power resources resume code do the additional check and
turn off the unused power resources as appropriate.

This change has been tested on HP nx6325.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since ACPI power resources are going to be used more extensively on
new hardware platforms, it is necessary to allow user space (powertop
in particular) to look at the lists of power resources corresponding
to different power states of devices for diagnostics and control
purposes.

For this reason, for each power state of an ACPI device node using
power resources create a special attribute group under the device
node's directory in sysfs containing links to sysfs directories
representing the power resources in that list.  The names of the
new attribute groups are "power_resources_<state>", where <state>
is the state name i.e. "D0", "D1", "D2", or "D3hot".
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The vexpress-sysreg driver does not have to be initialized
early, when the platform doesn't require this. Unfortunately
in such case it wasn't initialized correctly - master site
lookup and config bridge registration were missing. Fixed now.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>

Since ACPI power resources are going to be used more extensively on
new hardware platforms, it becomes necessary for user space (powertop
in particular) to observe some properties of those resources for
diagnostics purposes.

For this reason, expose the current status of each ACPI power
resource to user space via sysfs by adding a new resource_in_use
attribute to the sysfs directory representing the given power
resource.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make it possible to retrieve the current power state of a device with
ACPI power management from user space via sysfs by adding two new
attributes, power_state and real_power_state, to the sysfs directory
associated with the struct acpi_device object representing the
device's ACPI node.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI core adds sysfs device files after the given devices have been
registered with device_register(), which is not appropriate, because
it may lead to race conditions with user space tools using those
files.

Fix the problem by delaying the KOBJ_ADD uevent for ACPI devices
until after all of the devices' sysfs files have been created.

This also fixes a use-after-free in acpi_device_unregister().
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel Lynxpoint LPSS peripheral drivers depend on LPSS clock tree being
created in order to function properly. The clock tree is exposed as a
platform driver that binds to a device named 'clk-lpt'.

To support this we modify the acpi_create_platform_device() to take one
additional parameter called flags. This is passed from
acpi_platform_device_ids[] array when acpi_create_platform_device() is
called.

We then introduce a new flag ACPI_PLATFORM_CLK which is used to tell
acpi_create_platform_device() to create the platform clocks as well.

Finally we set the ACPI_PLATFORM_CLK flags for all the Lynxpoint LPSS
devices and make sure that when this flag is set we create the
corresponding clock tree platform device.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Intel Lynxpoint Low Power Subsystem hosts peripherals like UART, I2C and
SPI controllers. For most of these there is a configuration register that
allows software to enable and disable the functional clock. Disabling the
clock while the peripheral is not used saves power.

In order to take advantage of this we add a new clock gate of type
lpss_gate that just re-uses the ordinary clk_gate but in addition is able
to enumerate the base address register of the device using ACPI.

We then create a clock tree that models the Lynxpoint LPSS clocks using
these gates and fixed clocks so that we can pass clock rate to the drivers
as well.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch (as1643b) fixes a build error in ehci-hcd when compiling for
ARM with allmodconfig:

drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used [-Wunused-variable]
drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition

The fix is to convert ehci-mxc over to the new "ehci-hcd is a library"
scheme so that it can coexist peacefully with the ehci-platform
driver.  As part of the conversion the ehci_mxc_priv data structure,
which was allocated dynamically, is now placed where it belongs: in
the private area at the end of struct ehci_hcd.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit eccf2979.

The reason is that it broke TI WiLink shared transport on Panda.
Also, callback functions should not be added to board files anymore,
so revert to implementing the power functions in the driver itself.

Additionally, changed a variable name ('status' to 'err') so that this
revert compiles properly.

Cc: stable <stable@vger.kernel.org> [3.7]
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are a number of bugs in the error paths of this driver.  Make
use of devm_ functions to simplify the cleanup on error.

Based on a patch by Russell King.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

the variable cpuclk and clk_name should be properly freed when error happens.
Signed-off-by: NCong Ding <dinggnu@gmail.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The acpi core will call request_module("acpi-cpufreq") on subsystem init,
but this will fail if the module isn't available at that stage of boot.
Add some module aliases to ensure that udev can load the module on Intel
and AMD systems with the appropriate feature bits - I /think/ that this
will also work on VIA systems, but haven't verified that.

References: http://lkml.kernel.org/r/1448223.sdUJnNSRz4@vostro.rjw.lanSigned-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
Tested-by: NLeonid Isaev <lisaev@umail.iu.edu>
Acked-by: NBorislav Petkov <bp@suse.de>
Cc: 3.7+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch (as1642) adds an ehci->priv field for private use by EHCI
platform drivers.  The space was provided some time ago, but it didn't
have a name.

Until now none of the platform drivers has used this private space,
but that's about to change in the next patch of this series.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1641) fixes a minor bug in ehci-hcd left over from when
the Chipidea driver was converted to the "ehci-hcd is a library"
scheme.  The test for whether the Chipidea platform driver is active
should be IS_ENABLED(), not defined().
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Without this, platform drivers e.g. ehci-omap.c will see a
different version of struct ehci_hcd than ehci-hcd.c and
break reference to 'debug_dir' and 'priv' members when
CONFIG_USB_DEBUG is enabled.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1644) fixes a race that occurs during startup in
uhci-hcd.  If the IRQ line is shared with other devices, it's possible
for the handler routine to be called before the data structures are
fully initialized.

The problem is fixed by adding a check to the IRQ handler routine.  If
the initialization hasn't finished yet, the routine will return
immediately.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDon Zickus <dzickus@redhat.com>
Tested-by: N"Huang, Adrian (ISS Linux TW)" <adrian.huang@hp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver can also be built as a module so add MODULE_LICENSE for it. In
addition add MODULE_DESCRIPTION as well.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

Commit 0bdfe0cb (i2c: omap: sanitize
exit path) changed the interrupt handler to exit early and complete
the transfer after the draining IRQ is handled. As a result, the ARDY
may not be cleared properly, and it may cause all future I2C transfers
to timeout with "timeout waiting for bus ready". This is reproducible
at least with N900 when twl4030_gpio makes a long write (> FIFO size)
during the probe (http://marc.info/?l=linux-omap&m=135818882610432&w=2).

The fix is to continue until we get ARDY interrupt that completes the
transfer. Tested with 3.8-rc4 + N900: 20 boots in a row without errors;
without the patch the problem triggers after few reboots.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

The errata handling function acks wrong interrupt in case of "Arbitration
lost". Fix it.

Discovered during code review, the real impact of the bug is unknown.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

To fix incorrect P-state frequencies which can happen on
some AMD systems f594065f
   "ACPI: Add fixups for AMD P-state figures"
introduced a quirk to obtain the correct values by reading
from AMD specific MSRs.

This did cause a regression when running a kernel using that
quirk under Xen which does (currently) not pass through MSR
reads to the HW. Instead the guest gets a 0 in return.
And this seems to cause a failure to initialize the ondemand
governour (hard to say for sure as all P-states appear to run
at the same frequency).

While this should also be fixed in the hypervisor (to allow
a guest to read that MSR), this patch is intended to work
around the issue in the meantime. In discussion it turned out
that indeed real HW/BIOSes may choose to not set the valid bit
and thus mark the P-state as invalid. So this could be considered
a fix for broken BIOSes that also works around the issue on Xen.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Cc: 3.7+ <stable@vger.kernel.org>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

OPP pointers cannot be expected to be valid beyond the boundary
of rcu_read_lock and rcu_read_unlock. Unfortunately, the current
exynos4 busfreq driver does not honor the usage constraint and stores
the OPP pointer in struct busfreq_data. This could potentially
become invalid later such as: across devfreq opp change decisions,
resulting in unpredictable behavior.

To fix this, we introduce a busfreq specific busfreq_opp_info
structure which is used to handle OPP information. OPP information
is de-referenced to voltage and frequency pairs as needed into
busfreq_opp_info structure and used as needed.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

OPP pointers are protected by RCU locks, the pointer validity is
permissible only under the section of rcu_read_lock to rcu_read_unlock

Add documentation to the effect.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

OPP pointer is RCU protected, hence after finding it, de-reference
also should be protected with the same RCU context else the OPP
pointer may become invalid.
Reported-by: NJack Mitchell <jack@embed.me.uk>
Tested-by: NAlexander Holler <holler@ahsoftware.de>
Tested-by: NJack Mitchell <jack@embed.me.uk>
Acked-by: NAlexander Holler <holler@ahsoftware.de>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>