- 01 Aug, 2022 3 commits
-
-
Hans de Goede authored
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
-
Andy Shevchenko authored
The P2SB library is used for various drivers, including server platforms. That's why the dependency on X86_PLATFORM_DEVICES seems superfluous. Reported-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Hans de Goede authored
Immutable branch between MFD, EDAC, I2C, LEDs, PinCtrl, Platform and Watchdog due for the v5.20 merge window
-
- 28 Jul, 2022 8 commits
-
-
Xin Gao authored
The double `of' is duplicated in line 50, remove one. Signed-off-by:
Xin Gao <gaoxin@cdjrlc.com> Link: https://lore.kernel.org/r/20220722022337.15903-1-gaoxin@cdjrlc.comSigned-off-by:
-
Maximilian Luz authored
The 13" Intel version of the Surface Laptop 4 uses the same GPE as the Surface Laptop Studio for wakeups via the lid. Set it up accordingly. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220721121120.2002430-1-luzmaximilian@gmail.comSigned-off-by:
-
Dan Carpenter authored
The call to: size = simple_write_to_buffer(cmdbuf, sizeof(cmdbuf), ppos, buf, size); will succeed if at least one byte is written to the "cmdbuf" buffer. The "*ppos" value controls which byte is written. Another problem is that this code does not check for errors so it's possible for the entire buffer to be uninitialized. Inintialize the struct to zero to prevent reading uninitialized stack data. Debugfs is normally only writable by root so the impact of this bug is very minimal. Fixes: 6cca83d4 ("Platform: OLPC: move debugfs support from x86 EC driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YthIKn+TfZSZMEcM@kiliReviewed-by:
-
Vadim Pasternak authored
Fix error flow: - Clean-up client object in case of probing failure. - Prevent running remove routine in case of probing failure. Probing and removing are invoked by hotplug events raised upon line card insertion and removing. If probing procedure failed all data is cleared and there is nothing to do in remove routine. Fixes: 62f9529b ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices") Signed-off-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20220719153540.61304-1-vadimp@nvidia.comReviewed-by:
-
Hans de Goede authored
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: 648e9218 ("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:
-
Andrey Strachuk authored
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.ruReviewed-by:
-
Xin Gao authored
Remove an unneeded semicolon. Signed-off-by:
-
Dan Carpenter authored
Change > MAX_DIE_PER_PACKAGE to >= MAX_DIE_PER_PACKAGE to prevent accessing one element beyond the end of the array. Fixes: 7fd786df ("tools/power/x86/intel-speed-select: OOB daemon mode") Signed-off-by:
-
- 17 Jul, 2022 1 commit
-
-
Maximilian Luz authored
The sources.count field is a __le32 inside a packed struct. So use the proper functions to access it. Reported-by:
-
- 14 Jul, 2022 24 commits
-
-
Vadim Pasternak authored
Add documentation for the new attributes: - "asic2_health" - health of 2-nd ASIC for system equipped with two ASICs. - "asic_reset" and "asic2_reset" - ASICs reset control. - "comm_chnl_ready" - communication channel indication to remote end (BMC). - "config3" - indication of system minor BOM changes. Signed-off-by:
-
Vadim Pasternak authored
Fix e-mail in contact fields. Signed-off-by:
-
Vadim Pasternak authored
Add lock to protect user read/write access to the registers. Signed-off-by:
-
Vadim Pasternak authored
Extend COME CPLD with board configuration register for getting board revision. The value of this register is pushed by hardware through GPIO pins. The purpose of it is to expose some minor BOM changes. Signed-off-by:
Oleksandr Shamray <oleksandrs@nvidia.com> Link: https://lore.kernel.org/r/20220711084559.62447-7-vadimp@nvidia.comReviewed-by:
-
Vadim Pasternak authored
Add support for new system type XH3000, which is a water cooling Ethernet switch blade equipped with 32x200G Ethernet ports. The system is recognized by "DMI_BOARD_NAME" and "DMI_PRODUCT_SKU" matches, when these fields are set to "VMOD0005" and "HI139" respectively. Signed-off-by:
Felix Radensky <fradensky@nvidia.com> Link: https://lore.kernel.org/r/20220711084559.62447-6-vadimp@nvidia.comReviewed-by:
-
Vadim Pasternak authored
platform/x86: mlx-platform: Introduce support for COMe NVSwitch management module for Vulcan chassis 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 authored
Motivation is to support new systems equipped with two ASICs. Extend driver with: - The second ASIC health event. - Per ASIC reset control, triggering reset of ASIC internal resources and restarting ASIC initialization flow. Signed-off-by:
-
Vadim Pasternak authored
Align the first argument with open parenthesis for platform_device_register_resndata() calls. Signed-off-by:
-
Vadim Pasternak authored
Current assumption in driver that any system is capable of LED, hotplug or watchdog support. It could be not true for some new coming systems. Add validation for LED, hotplug, watchdog configuration and skip activation of relevant drivers if not configured. Signed-off-by:
-
PaddyKP_Yao authored
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.comReviewed-by:
-
Lukas Bulwahn authored
Commit 9f794056 ("platform/surface: Add KIP/POS tablet-mode switch driver") adds the section MICROSOFT SURFACE AGGREGATOR TABLET-MODE SWITCH with a file entry, but the file that is added with this commit is actually named slightly differently. file entry name: drivers/platform/surface/surface_aggregator_tablet_switch.c added file name: drivers/platform/surface/surface_aggregator_tabletsw.c Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Repair this file entry to the actual file name added with the commit above. Fixes: 9f794056 ("platform/surface: Add KIP/POS tablet-mode switch driver") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
-
Hans de Goede authored
Commit 3a0cf7ab ("ACPI: video: Change how we determine if brightness key-presses are handled") made acpi_video_handles_brightness_key_presses() report false when none of the ACPI Video Devices support backlight control. But it turns out that at least on a Dell Inspiron N4010 there is no ACPI backlight control, yet brightness hotkeys are still reported through the ACPI Video Bus; and since acpi_video_handles_brightness_key_presses() now returns false, brightness keypresses are now reported twice. To fix this rename the has_backlight flag to may_report_brightness_keys and also set it the first time a brightness key press event is received. Depending on the delivery of the other ACPI (WMI) event vs the ACPI Video Bus event this means that the first brightness key press might still get reported twice, but all further keypresses will be filtered as before. Note that this relies on other drivers reporting brightness key events calling acpi_video_handles_brightness_key_presses() when delivering the events (rather then once during driver probe). This is already required and documented in include/acpi/video.h: /* * Note: The value returned by acpi_video_handles_brightness_key_presses() * may change over time and should not be cached. */ Fixes: 3a0cf7ab ("ACPI: video: Change how we determine if brightness key-presses are handled") Link: https://lore.kernel.org/regressions/CALF=6jEe5G8+r1Wo0vvz4GjNQQhdkLT5p8uCHn6ZXhg4nsOWow@mail.gmail.com/Reported-and-tested-by:
Ben Greening <bgreening@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220713211101.85547-2-hdegoede@redhat.com
-
Henning Schild authored
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:
Lee Jones <lee@kernel.org>
-
Henning Schild authored
The two drivers that used to use this have been switched over to the common P2SB accessor, so this code is not needed any longer. Signed-off-by:
-
Henning Schild authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
-
Henning Schild authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Andy Shevchenko authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Andy Shevchenko authored
The driver uses rather voodoo kind of castings and I/O accessors. Replace it with proper __iomem annotation and readl()/readq() calls. Signed-off-by:
-
Andy Shevchenko authored
Since we have a common P2SB accessor in tree we may use it instead of open coded variants. Replace custom code by p2sb_bar() call. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Acked-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Tan Jui Nee authored
Add support for non-ACPI systems, such as system that uses Advanced Boot Loader (ABL) whereby a platform device has to be created in order to bind with pin control and GPIO. At the moment, Intel Apollo Lake In-Vehicle Infotainment (IVI) system requires a driver to hide and unhide P2SB to lookup P2SB BAR and pass the PCI BAR address to GPIO. Signed-off-by:
Tan Jui Nee <jui.nee.tan@intel.com> Co-developed-by:
-
Andy Shevchenko authored
Instead of open coding p2sb_bar() functionality we are going to use generic library. There is one more user en route. This is more than just a clean-up. It also fixes a potential issue seen when SPI BAR is 64-bit. The current code works if and only if the PCI BAR of the hidden device is inside 4G address space. In case when firmware decides to go above 4G, we will get a wrong address. Signed-off-by:
-
Andy Shevchenko authored
Factor out duplicate code to lpc_ich_enable_spi_write() helper function. Signed-off-by:
-
Andy Shevchenko authored
In some cases we may get a platform device that has ACPI companion which is different to the pin control described in the ACPI tables. This is primarily happens when device is instantiated by board file. In order to allow this device being enumerated, refactor intel_pinctrl_get_soc_data() to check the matching data instead of ACPI companion. Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
-
Jonathan Yong authored
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-70e9b829b403Signed-off-by:
Jonathan Yong <jonathan.yong@intel.com> Co-developed-by:
-
- 10 Jul, 2022 4 commits
-
-
Hans de Goede authored
Like the Asus T100TA the Asus T100TAF has a camera LED which is always on by default and both also use the same GPIO for the LED. Relax the DMI match for the Asus T100TA so that it also matches the T100TAF. Signed-off-by:
-
Andy Shevchenko authored
It's easier to maintain the sorted table. Keep the sorting order in sync with one in drivers/acpi/scan.c. Signed-off-by:
-
Andy Shevchenko authored
In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. Signed-off-by:
-
Andy Shevchenko authored
Use more natural while (i--) patter to clean up allocated resources. Signed-off-by:
-
