Many DSDTs for Kaby Lake and Kaby Lake Refresh models contain a
_SB.PCI0.GEXP ACPI Device node describing an I2C attached PCA953x
GPIO expander.
This seems to be something which is copy and pasted from the DSDT
from some reference design since this ACPI Device is present even on
models where no such GPIO expander is used at all, such as on the
Microsoft Surface Go & Go 2.
This ACPI Device is a problem because it contains a SystemMemory
OperationRegion which covers the MMIO for the I2C4 I2C controller. This
causes the MFD cell for the I2C4 controller to not be instantiated due
to a resource conflict, requiring the use of acpi_enforce_resources=lax
to work around this.
I have done an extensive analysis of all the ACPI tables on the
Microsoft Surface Go and the _SB.PCI0.GEXP ACPI Device's methods are
not used by any code in the ACPI tables, neither are any of them
directly called by any Linux kernel code. This is unsurprising since
running i2cdetect on the I2C4 bus shows that there is no GPIO
expander chip present on these devices at all.
This commit adds a PCI subsystem vendor:device table listing PCI devices
where it is known to be safe to ignore resource conflicts with ACPI
declared SystemMemory regions.
This makes the I2C4 bus work out of the box on the Microsoft Surface
Go & Go 2, which is necessary for the cameras on these devices to work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20211203115108.89661-1-hdegoede@redhat.com
Software node was always created for the device if it was
supplied with additional device properties, so those nodes
might as well be constant.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
There is no point to have non-constant device properties in this driver.
Thus, constify them for good.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
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>
We now using a common macro for PM operations in Intel LPSS driver,
and, since that macro relies on the definition and macro from linux/pm.h
header file, it's logical to include it directly in intel-lpss.h.
Otherwise it's a bit fragile and requires a proper ordering
of header inclusion in C files.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Push the system suspend/resume callbacks of intel-lpss to the late
suspend/early resume stages to allow child device callbacks to be
pushed to the late/early stages of suspend/resume too, so as to
make it possible to avoid resuming the children if they are runtime-
suspended during system suspend going forward.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Johannes Stezenbach <js@sig21.net>
Tested-by: Rajat Jain <rajatja@google.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Since device_add_property_set() now always takes a copy of
the property_set, and also since the fwnode type is always
hard coded to be FWNODE_PDATA, there is no need for the
drivers to deliver the entire struct property_set. The
function can just create the instance of it on its own and
bind the properties from the drivers to it on the spot.
This renames device_add_property_set() to
device_add_properties(). The function now takes struct
property_entry as its parameter instead of struct
property_set.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If the boot firmware does not support ACPI we need a way to pass device
configuration information to the drivers. The unified device properties API
already supports passing platform data via properties so let's take
advantage of that and allow probe drivers to pass set of properties to the
host controller driver.
In order to do that we need to be able to modify the MFD cell corresponding
the host controller, so make the core driver to take copy of the cell
instead of using it directly. Then we can assign info->pset to the
resulting copy of a cell and let the MFD core to assign that to the
resulting device.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Jim Davis reported the compilation error with a random configuration which
apparently has CONFIG_PM=y and CONFIG_PM_SLEEP=n. With that conditions we have
missed definition of INTEL_LPSS_SLEEP_PM_OPS macro. Add it here.
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The new coming Intel platforms such as Skylake will contain Sunrisepoint PCH.
The main difference to the previous platforms is that the LPSS devices are
compound devices where usually main (SPI, HSUART, or I2C) and DMA IPs are
present.
This patch brings the driver for such devices found on Sunrisepoint PCH.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Hans de Goede
Heikki Krogerus
Andy Shevchenko
Thomas Gleixner
Rafael J. Wysocki
Mika Westerberg