ACPI: PNP: Introduce list of known non-PNP devices

In some cases, PNP device IDs from acpi_pnp_device_ids[] are returned by
_CID for devices for which matching platform drivers are present in the
kernel and should be bound to them. However, the IDs coming from _CID
cause the PNP scan handler to attach to those devices which prevents
platform device objects from being created for them.

Address this by introducing a list of known non-PNP device IDs into
acpi_pnp.c such that if a device ID is there in that list, it cannot be
attached to by the PNP scan handler and add the platform runtime update
and telemetry device IDs to that list to start with.

Reported-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Zhang Yang <Yang5.zhang@intel.com>

ACPI: PNP: remove duplicated BRI0A49 and BDP3336 entries

BRI0A49 and BDP3336 are already on the list.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI: PNP: compare the string length in the matching_id()

Recently we met a touchscreen problem on some Thinkpad machines, the
touchscreen driver (i2c-hid) is not loaded and the touchscreen can't
work.

An i2c ACPI device with the name WACF2200 is defined in the BIOS, with
the current rule in matching_id(), this device will be regarded as
a PNP device since there is WACFXXX in the acpi_pnp_device_ids[] and
this PNP device is attached to the acpi device as the 1st
physical_node, this will make the i2c bus match fail when i2c bus
calls acpi_companion_match() to match the acpi_id_table in the i2c-hid
driver.

WACF2200 is an i2c device instead of a PNP device, after adding the
string length comparing, the matching_id() will return false when
matching WACF2200 and WACFXXX, and it is reasonable to compare the
string length when matching two IDs.

Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

PNP: ACPI: Fix missing-prototypes in acpi_pnp.c

Fix the following warnings.
drivers/acpi/acpi_pnp.c:382:13: warning: no previous prototype
for ‘acpi_pnp_init’ [-Wmissing-prototypes].

Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI / PNP: constify device IDs

Instead of re-creating the array on the stack each time
is_cmos_rtc_device() gets called, make the array 'static const'.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / scan: constify first argument of struct acpi_scan_handler::match

One wouldn't expect a "match" function modify the string it searches
for, and indeed the only instance of the struct
acpi_scan_handler::match callback, acpi_pnp_match, can easily be
changed. While there, update its helper matching_id().

This is also preparation for constifying struct acpi_hardware_id::id.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ipmi: Convert the IPMI SI ACPI handling to a platform device

The IPMI SI driver was using direct PNP, but that was not really
ideal because the IPMI device is a platform device. There was
some special handling in the acpi_pnp.c code for making this work,
but that was breaking ACPI handling for the IPMI SSIF driver.

So without this patch there were significant issues getting the
SSIF driver to work with ACPI.

So use a platform device for ACPI detection and remove the
entry from acpi_pnp.c.

Signed-off-by: Corey Minyard <cminyard@mvista.com>

serial: 8250: bind to ALi Fast Infrared Controller (ALI5123)

This way this device can be used with irtty-sir -
at least on Toshiba Satellite A20-S103 it is not configured by default
and needs PNP activation before it starts to respond on I/O ports.

This device has actually its own driver (ali-ircc),
but this driver seems to be non-functional for a very long time
(see http://permalink.gmane.org/gmane.linux.irda.general/484
http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ).

Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI / PNP: add two IDs to list for PNPACPI device enumeration

Commit eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device
enumeration) changed the way how ACPI devices are enumerated and when
they are added to the PNP bus.

However, it broke the sound card support on (at least) a vintage
IBM ThinkPad 600E: with said commit applied, two of the necessary
"CSC01xx" devices are not added to the PNP bus and hence can not be
found during the initialization of the "snd-cs4236" module. As a
consequence, loading "snd-cs4236" causes null pointer exceptions.
The attached patch fixes the problem end re-enables sound on the
IBM ThinkPad 600E.

Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Input: soc_button_array - convert to platform bus

ACPI device enumeration mechanism changed a lot since 3.16-rc1.
ACPI device objects with _HID will be enumerated to platform bus by default.
For the existing PNP drivers that probe the PNPACPI devices, the device ids
are listed explicitly in drivers/acpi/acpi_pnp.c.
But ACPI folks will continue their effort on shrinking this id list by
converting the PNP drivers to platform drivers, for the devices that don't
belong to PNP bus in nature.

Signed-off-by: Jin Yao <yao.jin@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

ACPI / PNP: remove Fujitsu device IDs from ACPI PNP ID list

Fujitsu backlight and hotkey devices have ACPI drivers.

The PNP MODULE_DEVICE_TABLE in fujitsu-laptop driver is just used as an
indicator for module autoloading, but this is wrong because what we
need is ACPI module device table instead, because the driver is probing
ACPI devices.

Thus remove those IDs from ACPI PNP scan handler list as we don't
have a PNP driver for them, and convert the fujitsu-laptop PNP
MODULE_DEVICE_TABLE to ACPI MODULE_DEVICE_TABLE.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Dirk Griesbach <spamthis@freenet.de>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / PNP: Replace faulty is_hex_digit() by isxdigit()

0 is ascii for NULL. Hex digit matching should be from '0'.
Faulty version returns true for #,$,%,& etc.

Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / PNP: add soc_button_array device ID to PNP IDs list

The soc_button_array PNP driver was introduced in 3.15.
But in commit eec15edbb0e1 (ACPI / PNP: use device ID list for
PNPACPI device enumeration), when reworking the PNPACPI device
enumeration, we missed the soc_button_array device ID.

This results in a regression in 3.16-rc1 that soc_button_array
pnp device fails to be enumerated.

Fix the problem by adding soc_button_array device ID into the
acpi_pnp scan handler's ID list.

Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / scan: drop unsupported serial IDs from PNP ACPI scan handler ID list

The "serial" PNP driver supports some "unknown" PNP modems
(PNPCXXX/PNPDXXX) by matching magic strings in the PNP device name
or the PNP device card name.

ACPI enumerated PNP devices neither are PNP cards, nor have those
magic strings in device names, so this mechamism never actually works
for ACPI enumerated PNPCXXX/PNPDXXX devices.

Consequently, it is safe to remove those two IDs from the PNP ACPI scan
handler's device ID list.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

ACPI / scan: drop IDs that do not comply with the ACPI PNP ID rule

The PNP ACPI scan handler device ID list includes all the IDs from
all of the struct pnp_device_id instances in the tree, but some of
them do not follow the ACPI PNP ID rule (3 letters + 4 hex digits).

For those IDs, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove them from the PNP ACPI ID list.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

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

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 <rui.zhang@intel.com>
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>