The x86-android-tablets handling for the Chuwi Hi8 is only necessary with
the Android BIOS and it is causing problems with the Windows BIOS version.
Specifically when trying to register the already present touchscreen
x86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks
the working of the touchscreen and also leads to an oops:
[ 14.248946] ------------[ cut here ]------------
[ 14.248954] remove_proc_entry: removing non-empty directory 'irq/75', leaking at least 'MSSL0001:00'
[ 14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry
...
[ 14.249293] unregister_irq_proc+0xe0/0x100
[ 14.249305] free_desc+0x29/0x70
[ 14.249312] irq_free_descs+0x4b/0x80
[ 14.249320] mp_unmap_irq+0x5c/0x60
[ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40
[ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets]
[ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets]
Add an init callback for the Chuwi Hi8, which detects when the Windows BIOS
is in use and exits with -ENODEV in that case, fixing this.
Fixes: 84c2dcdd47 ("platform/x86: x86-android-tablets: Add an init() callback to struct x86_dev_info")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220810141934.140771-1-hdegoede@redhat.com
variable 'mode' is used uninitialized whenever switch default is taken
in sps.c which leads to the following clang warning.
drivers/platform/x86/amd/pmf/sps.c:96:2: error: variable 'mode' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized]
default:
^~~~~~~
drivers/platform/x86/amd/pmf/sps.c:101:9: note: uninitialized use occurs here
return mode;
^~~~
drivers/platform/x86/amd/pmf/sps.c:84:9: note: initialize the variable 'mode' to silence this warning
u8 mode;
^
= '\0'
1 error generated.
Fix it by returning -EOPNOTSUPP in default case and also change the return
type of the function amd_pmf_get_pprof_modes() to keep it similar like
other drivers which implement platform_profile.
Fixes: 4c71ae4144 ("platform/x86/amd/pmf: Add support SPS PMF feature")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220822062917.4061503-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Its reported that amd-pmf driver when built with config which does not
have ACPI_PLATFORM_PROFILE set/enabled throws a undefined references to
symbols used.
ld: vmlinux.o: in function `amd_pmf_init_sps':
drivers/platform/x86/amd/pmf/sps.c:132: undefined reference to `platform_profile_register'
ld: vmlinux.o: in function `amd_pmf_deinit_sps':
drivers/platform/x86/amd/pmf/sps.c:142: undefined reference to `platform_profile_remove'
Fix it by adding a "select" to the Kconfig.
Fixes: da5ce22df5 ("platform/x86/amd/pmf: Add support for PMF core layer")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Link: https://lore.kernel.org/r/20220819083858.3987590-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Pull sound fixes from Takashi Iwai:
"The only significant core change is ASoC DPCM fix for asymmetric
setup; other remaining changes are device-specific fixes, including
the hardening of string manipulations.
One change in platform/x86 is the patch I forgot to apply from a
series for CS35L41 codec"
* tag 'sound-6.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (21 commits)
ALSA: hda/realtek: Add quirk for Clevo NS50PU, NS70PU
ALSA: info: Fix llseek return value when using callback
ALSA: hda/cs8409: Support new Dolphin Variants
platform/x86: serial-multi-instantiate: Add CLSA0101 Laptop
ALSA: hda/realtek: Add quirk for Lenovo Yoga7 14IAL7
ALSA: hda: cs35l41: Clarify support for CSC3551 without _DSD Properties
ALSA: hda/realtek: Add quirks for ASUS Zenbooks using CS35L41
ASoC: codec: tlv320aic32x4: fix mono playback via I2S
ASoC: rt5640: Fix the JD voltage dropping issue
ASoC: tas2770: Fix handling of mute/unmute
ASoC: tas2770: Drop conflicting set_bias_level power setting
ASoC: tas2770: Allow mono streams
ASoC: tas2770: Set correct FSYNC polarity
ASoC: Intel: fix sof_es8336 probe
ASoC: DPCM: Don't pick up BE without substream
ASoC: SOF: ipc3-topology: Fix clang -Wformat warning
ASoC: sh: rz-ssi: Improve error handling in rz_ssi_probe() error path
ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()
ASoC: SOF: debug: Fix potential buffer overflow by snprintf()
ASoC: Intel: avs: Fix potential buffer overflow by snprintf()
...
This feature has 3 modes quiet, balanced, performance
The objective of this feature is to track the moving average of system
power over the time period specified and switch to the subsequent mode.
In order to do this, PMF driver will get the moving average of APU power
from PMFW and power threshold, time constants, system config parameters
from OEM inputs.
System power as read by PMF driver from PMFW is the filtered value over
the sampling window. Every sampling window, moving average of system power
is computed. At the end of the monitoring window, the moving average is
compared against the threshold for mode switch for decision making.
With AMD managing the system config limits, any mode switch within
auto-mode will result in limits of fPPT/sPPT/STAPM or STT being scaled
down.
When "auto mode" is enabled, the static slider control remains out of
the PMF driver, so the platform_profile registration would not
happen in PMF driver.
The transition to auto-mode only happens when the APMF fn5 is enabled
in BIOS, platform_profile set to "balanced" and a AMT
(Auto Mode transition) is received.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220802151149.2123699-9-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
PMF has a generic interface defined via PMF ACPI fn9 for influencing fan
policy during mode switch.
PMF ACPI fn9 will normally be invoked when AMDPMF needs to change the fan
table index for the EC. When AMDPMF is loaded this function will be invoked
to change fan speed. OEM can also choose to report the actual fan table
index and fan RPM to PMF through OEM structure.
This information will be communicated by PMF driver to customer BIOS.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220802151149.2123699-7-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
PMF driver can send periodic heartbeat signals to OEM BIOS. When BIOS does
not receive the signal after a period of time, it can infer that AMDPMF
has hung or failed to load.
In this situation, BIOS can fallback to legacy operations. OEM can modify
the time interval of the signal or completely disable signals through
ACPI Method.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220802151149.2123699-6-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
SPS (a.k.a. Static Power Slider) gives a feel of Windows performance
power slider for the Linux users, where the user selects a certain
mode (like "balanced", "low-power" or "performance") and the thermals
associated with each selected mode gets applied from the silicon
side via the mailboxes defined through PMFW.
PMF driver hooks to platform_profile by reading the PMF ACPI fn9 to
see if the support is being advertised by ACPI interface.
If supported, the PMF driver reacts to platform_profile selection choices
made by the user and adjust the system thermal behavior.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220802151149.2123699-4-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
PMF driver implements the ACPI methods as defined by AMD for PMF Support.
The ACPI layer acts as a glue that helps in providing the infrastructure
for OEMs customization.
OEMs can refer to PMF support documentation to decide on the list of
functions to be supported on their specific platform model.
AMD mandates that PMF ACPI fn0 and fn1 to be implemented which
provides the set of functions, params and the notifications that
would be sent to PMF driver so that PMF driver can adapt and
react.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220802151149.2123699-3-Shyam-sundar.S-k@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The x86-android-tablets handling for the Chuwi Hi8 is only necessary with
the Android BIOS and it is causing problems with the Windows BIOS version.
Specifically when trying to register the already present touchscreen
x86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks
the working of the touchscreen and also leads to an oops:
[ 14.248946] ------------[ cut here ]------------
[ 14.248954] remove_proc_entry: removing non-empty directory 'irq/75', leaking at least 'MSSL0001:00'
[ 14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry
...
[ 14.249293] unregister_irq_proc+0xe0/0x100
[ 14.249305] free_desc+0x29/0x70
[ 14.249312] irq_free_descs+0x4b/0x80
[ 14.249320] mp_unmap_irq+0x5c/0x60
[ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40
[ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets]
[ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets]
Add an init callback for the Chuwi Hi8, which detects when the Windows BIOS
is in use and exits with -ENODEV in that case, fixing this.
Fixes: 84c2dcdd47 ("platform/x86: x86-android-tablets: Add an init() callback to struct x86_dev_info")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220810141934.140771-1-hdegoede@redhat.com
Pull x86 platform driver updates from Hans de Goede:
- Microsoft Surface:
- SSAM hot unplug support
- Surface Pro 8 keyboard cover support
- Tablet mode switch support for Surface Pro 8 and Surface Laptop
Studio
- thinkpad_acpi:
- AMD Automatice Mode Transitions (AMT) support
- Mellanox:
- Vulcan chassis COMe NVSwitch management support
- XH3000 support
- New generic/shared Intel P2SB (Primary to Sideband) support
- Lots of small cleanups
- Various small bugfixes
- Various new hardware ids / quirks additions
* tag 'platform-drivers-x86-v6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (105 commits)
platform/x86/intel/vsec: Fix wrong type for local status variables
platform/x86: p2sb: Move out of X86_PLATFORM_DEVICES dependency
platform/x86: pmc_atom: Fix comment typo
platform/surface: gpe: Add support for 13" Intel version of Surface Laptop 4
platform/olpc: Fix uninitialized data in debugfs write
platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity
platform/x86: pmc_atom: Match all Lex BayTrail boards with critclk_systems DMI table
platform/x86: sony-laptop: Remove useless comparisons in sony_pic_read_possible_resource()
tools/power/x86/intel-speed-select: Remove unneeded semicolon
tools/power/x86/intel-speed-select: Fix off by one check
platform/surface: tabletsw: Fix __le32 integer access
Documentation/ABI: Add new attributes for mlxreg-io sysfs interfaces
Documentation/ABI: mlxreg-io: Fix contact info
platform/mellanox: mlxreg-io: Add locking for io operations
platform/x86: mlx-platform: Add COME board revision register
platform/x86: mlx-platform: Add support for new system XH3000
platform/x86: mlx-platform: Introduce support for COMe NVSwitch management module for Vulcan chassis
platform/x86: mlx-platform: Add support for systems equipped with two ASICs
platform/x86: mlx-platform: Add cosmetic changes for alignment
platform/x86: mlx-platform: Make activation of some drivers conditional
...
The local status variables in intel_vsec_pci_error_detected()
and intel_vsec_pci_slot_reset() should have pci_ers_result_t as type
(and not pci_channel_state_t).
Also fix a whitespace error as well as intel_vsec_pci_err_handlers not
being marked static.
This fixes the following sparse errors:
drivers/platform/x86/intel/vsec.c:429:38: sparse: sparse: incorrect type in initializer (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@
drivers/platform/x86/intel/vsec.c:429:38: sparse: expected restricted pci_channel_state_t [usertype] status
drivers/platform/x86/intel/vsec.c:429:38: sparse: got restricted pci_ers_result_t
drivers/platform/x86/intel/vsec.c:434:24: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@
drivers/platform/x86/intel/vsec.c:434:24: sparse: expected restricted pci_channel_state_t [usertype] status
drivers/platform/x86/intel/vsec.c:434:24: sparse: got restricted pci_ers_result_t
drivers/platform/x86/intel/vsec.c:438:16: sparse: sparse: incorrect type in return expression (different base types) @@ expected restricted pci_ers_result_t @@ got restricted pci_channel_state_t [usertype] status @@
drivers/platform/x86/intel/vsec.c:438:16: sparse: expected restricted pci_ers_result_t
drivers/platform/x86/intel/vsec.c:438:16: sparse: got restricted pci_channel_state_t [usertype] status
drivers/platform/x86/intel/vsec.c:444:38: sparse: sparse: incorrect type in initializer (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@
drivers/platform/x86/intel/vsec.c:444:38: sparse: expected restricted pci_channel_state_t [usertype] status
drivers/platform/x86/intel/vsec.c:444:38: sparse: got restricted pci_ers_result_t
drivers/platform/x86/intel/vsec.c:457:16: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted pci_channel_state_t [usertype] status @@ got restricted pci_ers_result_t @@
drivers/platform/x86/intel/vsec.c:457:16: sparse: expected restricted pci_channel_state_t [usertype] status
drivers/platform/x86/intel/vsec.c:457:16: sparse: got restricted pci_ers_result_t
drivers/platform/x86/intel/vsec.c:472:16: sparse: sparse: incorrect type in return expression (different base types) @@ expected restricted pci_ers_result_t @@ got restricted pci_channel_state_t [usertype] status @@
drivers/platform/x86/intel/vsec.c:472:16: sparse: expected restricted pci_ers_result_t
drivers/platform/x86/intel/vsec.c:472:16: sparse: got restricted pci_channel_state_t [usertype] status
drivers/platform/x86/intel/vsec.c:480:33: sparse: sparse: symbol 'intel_vsec_pci_err_handlers' was not declared. Should it be static?
Reported-by: kernel test robot <lkp@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Cc: David E Box <david.e.box@intel.com>
Cc: Gayatri Kammela <gayatri.kammela@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220801145536.172410-1-hdegoede@redhat.com
Merge ACPI device object management changes for v5.20-rc1.
- Use the facilities provided by the driver core and some additional
helpers to handle the children of a given ACPI device object in
multiple places instead of using the children and node list heads in
struct acpi_device which is error prone (Rafael Wysocki).
- Fix ACPI-related device reference counting issue in the hisi_lpc bus
driver (Yang Yingliang).
- Drop the children and node list heads that are not needed any more
from struct acpi_device (Rafael Wysocki).
- Drop driver member from struct acpi_device (Uwe Kleine-König).
- Drop redundant check from acpi_device_remove() (Uwe Kleine-König).
* acpi-bus:
ACPI: bus: Drop unused list heads from struct acpi_device
hisi_lpc: Use acpi_dev_for_each_child()
bus: hisi_lpc: fix missing platform_device_put() in hisi_lpc_acpi_probe()
ACPI: bus: Drop driver member of struct acpi_device
ACPI: bus: Drop redundant check in acpi_device_remove()
mfd: core: Use acpi_dev_for_each_child()
ACPI / MMC: PM: Unify fixing up device power
soundwire: Use acpi_dev_for_each_child()
platform/x86/thinkpad_acpi: Use acpi_dev_for_each_child()
ACPI: scan: Walk ACPI device's children using driver core
ACPI: bus: Introduce acpi_dev_for_each_child_reverse()
ACPI: video: Use acpi_dev_for_each_child()
ACPI: bus: Export acpi_dev_for_each_child() to modules
ACPI: property: Use acpi_dev_for_each_child() for child lookup
ACPI: container: Use acpi_dev_for_each_child()
USB: ACPI: Replace usb_acpi_find_port() with acpi_find_child_by_adr()
thunderbolt: ACPI: Replace tb_acpi_find_port() with acpi_find_child_by_adr()
ACPI: glue: Introduce acpi_find_child_by_adr()
ACPI: glue: Introduce acpi_dev_has_children()
ACPI: glue: Use acpi_dev_for_each_child()
The critclk_systems[] DMI match table already contains 2 Lex BayTrail
boards and patches were just submitted to add 3 more entries for the
following models: 3I380NX, 3I380A, 3I380CW.
Looking at: https://www.lex.com.tw/products/embedded-ipc-board/
we can see that Lex BayTrail makes many embedded boards with
multiple ethernet boards and none of their products are battery
powered so we don't need to worry (too much) about power consumption
when suspended.
Add a new DMI match which simply matches all Lex BayTrail boards and drop
the 2 existing board specific quirks.
Fixes: 648e921888 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Reported-by: Michael Schöne <michael.schoene@rhebo.com>
Reported-by: Paul Spooren <paul.spooren@rhebo.com>
Reported-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Local variable 'p' is initialized by an address
of field of acpi_resource structure, so it does
not make sense to compare 'p' with NULL.
Local variable 'io' is initialized by an address
of field of acpi_resource structure, so it does
not make sense to compare 'io' with NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Andrey Strachuk <strochuk@ispras.ru>
Link: https://lore.kernel.org/r/20220719110341.7239-1-strochuk@ispras.ru
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The Vulcan is chassis containing Nvidia's Hopper dGPU (GH100), NVswitch
(LS10) based HGX baseboard and COMe NVSwitch management module.
The system is built for artificial intelligence and accelerated
analytics applications. Vulcan is offered as an HGX product to cloud
service providers and OEMs, who intend to build fully interconnected
GPU systems for large scale deployments.
Driver is extended to support new COMe NVSwitch management module.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Oleksandr Shamray <oleksandrs@nvidia.com>
Link: https://lore.kernel.org/r/20220711084559.62447-5-vadimp@nvidia.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In some new ASUS devices, hotkey Fn+F13 is used for mic mute. If mic-mute
LED is present by checking WMI ASUS_WMI_DEVID_MICMUTE_LED, we will add a
mic-mute LED classdev, asus::micmute, in the asus-wmi driver to control
it. The binding of mic-mute LED controls will be swithched with LED
trigger.
Signed-off-by: PaddyKP_Yao <PaddyKP_Yao@asus.com>
Link: https://lore.kernel.org/r/20220711115125.2072508-1-PaddyKP_Yao@asus.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On Apollo Lake the pinctrl drivers will now come up without ACPI. Use
that instead of open coding it.
Create a new driver for that which can later be filled with more GPIO
based models, and which has different dependencies.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee@kernel.org>
SoC features such as GPIO are accessed via a reserved MMIO area,
we don't know its address but can obtain it from the BAR of
the P2SB device, that device is normally hidden so we have to
temporarily unhide it, read address and hide it back.
There are already a few users and at least one more is coming which
require an access to Primary to Sideband (P2SB) bridge in order
to get IO or MMIO BAR hidden by BIOS.
Create a library to access P2SB for x86 devices in a unified way.
Background information
======================
Note, the term "bridge" is used in the documentation and it has nothing
to do with a PCI (host) bridge as per the PCI specifications.
The P2SB is an interesting device by its nature and hardware design.
First of all, it has several devices in the hardware behind it. These
devices may or may not be represented as ACPI devices by a firmware.
It also has a hardwired (to 0s) the least significant bits of the
base address register which is represented by the only 64-bit BAR0.
It means that OS mustn't reallocate the BAR.
On top of that in some cases P2SB is represented by function 0 on PCI
slot (in terms of B:D.F) and according to the PCI specification any
other function can't be seen until function 0 is present and visible.
In the PCI configuration space of P2SB device the full 32-bit register
is allocated for the only purpose of hiding the entire P2SB device. As
per [3]:
3.1.39 P2SB Control (P2SBC)—Offset E0h
Hide Device (HIDE): When this bit is set, the P2SB will return 1s on
any PCI Configuration Read on IOSF-P. All other transactions including
PCI Configuration Writes on IOSF-P are unaffected by this. This does
not affect reads performed on the IOSF-SB interface.
This doesn't prevent MMIO accesses, although preventing the OS from
assigning these addresses. The firmware on the affected platforms marks
the region as unusable (by cutting it off from the PCI host bridge
resources) as depicted in the Apollo Lake example below:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0070-0x0077]
pci_bus 0000:00: root bus resource [io 0x0000-0x006f window]
pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x7c000001-0x7fffffff window]
pci_bus 0000:00: root bus resource [mem 0x7b800001-0x7bffffff window]
pci_bus 0000:00: root bus resource [mem 0x80000000-0xcfffffff window]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff window]
pci_bus 0000:00: root bus resource [bus 00-ff]
The P2SB 16MB BAR is located at 0xd0000000-0xd0ffffff memory window.
The generic solution
====================
The generic solution for all cases when we need to access to the information
behind P2SB device is a library code where users ask for necessary resources
by demand and hence those users take care of not being run on the systems
where this access is not required.
The library provides the p2sb_bar() API to retrieve the MMIO of the BAR0 of
the device from P2SB device slot.
P2SB unconditional unhiding awareness
=====================================
Technically it's possible to unhide the P2SB device and devices on
the same PCI slot and access them at any time as needed. But there are
several potential issues with that:
- the systems were never tested against such configuration and hence
nobody knows what kind of bugs it may bring, especially when we talk
about SPI NOR case which contains Intel FirmWare Image (IFWI) code
(including BIOS) and already known to be problematic in the past for
end users
- the PCI by its nature is a hotpluggable bus and in case somebody
attaches a driver to the functions of a P2SB slot device(s) the
end user experience and system behaviour can be unpredictable
- the kernel code would need some ugly hacks (or code looking as an
ugly hack) under arch/x86/pci in order to enable these devices on
only selected platforms (which may include CPU ID table followed by
a potentially growing number of DMI strings
The future improvements
=======================
The future improvements with this code may go in order to gain some kind
of cache, if it's possible at all, to prevent unhiding and hiding many
times to take static information that may be saved once per boot.
Links
=====
[1]: https://lab.whitequark.org/notes/2017-11-08/accessing-intel-ich-pch-gpios/
[2]: https://cdrdv2.intel.com/v1/dl/getContent/332690?wapkw=332690
[3]: https://cdrdv2.intel.com/v1/dl/getContent/332691?wapkw=332691
[4]: https://medium.com/@jacksonchen_43335/bios-gpio-p2sb-70e9b829b403
Signed-off-by: Jonathan Yong <jonathan.yong@intel.com>
Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Henning Schild <henning.schild@siemens.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee@kernel.org>
