linux-stable.git/drivers/pnp, branch linux-3.19.y

PNP: replace strnicmp with strncasecmp

2014-10-14T00:18:25+00:00

The kernel used to contain two functions for length-delimited,
case-insensitive string comparison, strnicmp with correct semantics and
a slightly buggy strncasecmp.  The latter is the POSIX name, so strnicmp
was renamed to strncasecmp, and strnicmp made into a wrapper for the new
strncasecmp to avoid breaking existing users.

To allow the compat wrapper strnicmp to be removed at some point in the
future, and to avoid the extra indirection cost, do
s/strnicmp/strncasecmp/g.

Signed-off-by: Rasmus Villemoes 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ACPI / PNP: Use ACPI_COMPANION() instead of ACPI_HANDLE()

2014-07-22T23:03:06+00:00

The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
return the handle of the device's ACPI companion, so it is much
more straightforward and efficient to use ACPI_COMPANION()
directly to obtain the device's ACPI companion object instead of
using ACPI_HANDLE() and acpi_bus_get_device() on the returned
handle for the same thing.

Do that in several places in the ACPI PNP core code.

Also use acpi_device_set_power() and acpi_device_power_manageable()
instead of acpi_bus_set_power() and acpi_bus_power_manageable(),
respectively, because the former two are more efficient if the
ACPI device object is already available.

Signed-off-by: Rafael J. Wysocki

ACPI / PNP: do ACPI binding directly

2014-07-07T12:07:38+00:00

PNPACPI uses acpi_bus_type to do ACPI binding for the PNPACPI devices.

This is overkill because PNPACPI code already knows which ACPI
device object to bind during PNPACPI device enumeration.

This patch removes acpi_pnp_bus and does the binding by invoking
acpi_bind_one() directly after device enumerated.

This also fixes a bug in the previous code that some PNPACPI devices failed
to be bound because
 1. the ACPI device _HID is not pnpid, e.g. "MSFT0001", but its _CID is,
    e.g. "PNP0303", thus ACPI _CID is used as the pnp device device id.
 2. device is bound only if the pnp device id matches the ACPI device _HID.

Tested-by: Prigent Christophe 
Signed-off-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki

Merge branches 'pnp', 'powercap', 'pm-runtime' and 'pm-opp'

2014-06-03T21:13:00+00:00

* pnp:
  MAINTAINERS: Remove Bjorn Helgaas as PNP maintainer
  PNP / resources: remove positive test on unsigned values

* powercap:
  powercap / RAPL: add new CPU IDs
  powercap / RAPL: further relax energy counter checks

* pm-runtime:
  PM / runtime: Update documentation to reflect the current code flow

* pm-opp:
  PM / OPP: discard duplicate OPPs
  PM / OPP: Make OPP invisible to users in Kconfig
  PM / OPP: fix incorrect OPP count handling in of_init_opp_table

ACPI / PNP: use device ID list for PNPACPI device enumeration

2014-05-30T14:04:35+00:00

ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently.  Namely, if an ACPI device
object
 1. Has a _CRS method,
 2. Has an identification of
    "three capital characters followed by four hex digits",
 3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it).  This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.

However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them).  As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices.  That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.

To address that problem it is better to enumerate _HID devices
as platform devices by default.  To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.

The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers.  Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.

Signed-off-by: Zhang Rui 
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg

PNP / resources: remove positive test on unsigned values

2014-05-10T11:46:37+00:00

irq and dma are both resource_size_t (derived from phys_addr_t <-> unsigned)

Signed-off-by: Fabian Frederick 
Signed-off-by: Rafael J. Wysocki

asmlinkage: Add explicit __visible to drivers/, lib/, kernel/*

2014-05-05T23:07:46+00:00

As requested by Linus add explicit __visible to the asmlinkage users.
This marks functions visible to assembler.

Tree sweep for rest of tree.

Signed-off-by: Andi Kleen 
Link: http://lkml.kernel.org/r/1398984278-29319-4-git-send-email-andi@firstfloor.org
Signed-off-by: H. Peter Anvin

PNP / ACPI: Do not return errors if _DIS or _SRS are not present

2014-04-30T20:36:33+00:00

The ACPI PNP subsystem returns errors from pnpacpi_set_resources()
and pnpacpi_disable_resources() if the _SRS or _DIS methods are not
present, respectively, but it should not do that, because those
methods are optional.  For this reason, modify pnpacpi_set_resources()
and pnpacpi_disable_resources(), respectively, to ignore missing _SRS
or _DIS.

This problem has been uncovered by commit 202317a573b2 (ACPI / scan:
Add acpi_device objects for all device nodes in the namespace) and
manifested itself by causing serial port suspend to fail on some
systems.

Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
References: https://bugzilla.kernel.org/show_bug.cgi?id=74371
Reported-by: wxg4net 
Reported-and-tested-by: 
Cc: 3.14+  # 3.14+
Signed-off-by: Rafael J. Wysocki

PNP: Fix compile error in quirks.c

2014-04-29T21:31:15+00:00

Fix the compile error:

drivers/pnp/quirks.c:393:2: error: implicit declaration of function 'pcibios_bus_to_resource'

that occurs when building with CONFIG_PCI unset.  The quirk is only
relevent to Intel devices, so we could use "#if defined(CONFIG_X86) &&
defined(CONFIG_PCI)" instead, but testing CONFIG_X86 is not strictly
necessary.

Fixes: cb171f7abb9a (PNP: Work around BIOS defects in Intel MCH area reporting)
Reported-by: Randy Dunlap 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Rafael J. Wysocki

PNP: Work around BIOS defects in Intel MCH area reporting

2014-04-24T00:39:40+00:00

Work around BIOSes that don't report the entire Intel MCH area.

MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a
PNP0C02 resource.  The MCH space was once 16KB, but is 32KB in newer parts.
Some BIOSes still report a PNP0C02 resource that is only 16KB, which means
the rest of the MCH space is consumed but unreported.

This can cause resource map sanity check warnings or (theoretically) a
device conflict if we assigned the unreported space to another device.

The Intel perf event uncore driver tripped over this when it claimed the
MCH region:

  resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
  Info: mapping multiple BARs. Your kernel is fine.

To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.

References: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic
Reported-and-tested-by: Borislav Petkov 
Signed-off-by: Bjorn Helgaas 
Acked-by: Borislav Petkov 
Acked-by: Stephane Eranian 
Signed-off-by: Rafael J. Wysocki