summaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)Author
2023-02-10platform: mellanox: Introduce support of new Nvidia L1 switchVadim Pasternak
Add support for new L1 switch nodes providing L1 connectivity for multi-node networking chassis. The purpose is to provide compute server with full management and IO subsystems with connections to L1 switches. System contains the following components: - COMe module based on Intel Coffee Lake CPU - Switch baseboard with two ASICs, while 24 ports of each ASICs are connected to one backplane connector 32 ports of each ASIC are connected to 8 OSFPs - Integrated 60mm dual-rotor FANs inside L1 node (N+2 redundancy) - Support 48V or 54V DC input from the external power server. Add the structures related to the new systems to allow proper activation of the all required platform driver. Add poweroff callback to support deep power cycle flow, which should include special actions against CPLD device for performing graceful operation. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-6-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform: mellanox: Introduce support for next-generation 800GB/s switchVadim Pasternak
Introduce support for Nvidia next-generation 800GB/s ethernet switch SN5600. SN5600 is 51.2 Tbps Ethernet switch based on Nvidia Spectrum-4 ASIC. It can provide up to 64x800Gb/s (ETH) full bidirectional bandwidth per port using PAM-4 modulations. The system supports 64 Belly to Belly 2x4 OSFP cages. The switch was designed to fit standard 2U racks. Features: - 64 OSFP ports support 800GbE - 10GbE speed. - Additional 25GbE - 1GbE service port on the front panel. - Air-cooled with 3 + 1 redundant fan units. - 1 + 1 redundant 3000W or 3600W PSUs. - System management board is based on Intel Coffee-lake CPU E-2276 with secure-boot support. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-5-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform: mellanox: Cosmetic changes - rename to more common nameVadim Pasternak
Rename 'nvlink_blade' in several declaration to more common name "chassis_blade", since these names are going to be used for different kinds of blades. Fix 'swicth' to 'switch' in comment. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-4-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform: mellanox: Change "reset_pwr_converter_fail" attributeVadim Pasternak
Change "reset_voltmon_upgrade_fail" attribute name to "reset_pwr_converter_fail". For systems using "mlxplat_mlxcpld_default_ng_regs_io_data", relevant CPLD 'register.bit' indicates the failure of power converter, while on older systems same 'register.bit' indicates failure of voltage monitor devices upgrade failure. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-3-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform: mellanox: Introduce support for rack manager switchVadim Pasternak
The rack switch is designed to provide high bandwidth, low latency connectivity using optical fiber as the primary interconnect. System supports 32 OSFP ports, non-blocking switching capacity of 25.6Tbps. System equipped with: - 2 replaceable power supplies (AC) with 1+1 redundancy model. - 7 replaceable fan drawers with 6+1 redundancy model. - 2 External Root of Trust or EROT (Glacier) devices for securing ASICs firmware. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-2-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10x86/platform/uv: Make kobj_type structure constantThomas Weißschuh
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Justin Ernst <justin.ernst@hpe.com> Link: https://lore.kernel.org/r/20230207-kobj_type-pdx86-v1-3-8e2c4fb83105@weissschuh.net Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86: think-lmi: Make kobj_type structure constantThomas Weißschuh
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230207-kobj_type-pdx86-v1-2-8e2c4fb83105@weissschuh.net Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86: dell-wmi-sysman: Make kobj_type structure constantThomas Weißschuh
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230207-kobj_type-pdx86-v1-1-8e2c4fb83105@weissschuh.net Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86/intel/vsec: Use mutex for ida_alloc() and ida_free()Srinivas Pandruvada
ID alloc and free functions don't have in built protection for parallel invocation of ida_alloc() and ida_free(). With the current flow in the vsec driver, there is no such scenario. But add mutex protection for potential future changes. Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20230207125821.3837799-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86/amd: pmc: Add line break for readabilityShyam Sundar S K
Add a line break for the code readability. 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/20230206150855.1938810-5-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86/amd: pmc: differentiate STB/SMU messaging printsShyam Sundar S K
Modify the dynamic debug print to differentiate between the regular and spill to DRAM usage of the SMU message port. Suggested-by: Sanket Goswami <Sanket.Goswami@amd.com> 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/20230206150855.1938810-4-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86/amd: pmc: Write dummy postcode into the STB DRAMShyam Sundar S K
Based on the recommendation from the PMFW team in order to get the recent telemetry data present on the STB DRAM the driver is required to send one dummy write to the STB buffer, so it internally triggers the PMFW to emit the latest telemetry data in the STB DRAM region. 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/20230206150855.1938810-3-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86/amd: pmc: Add num_samples message id support to STBShyam Sundar S K
Recent PMFWs have the support for S2D_NUM_SAMPLES message ID that can tell the current number of samples present within the STB DRAM. num_samples returned would let the driver know the start of the read from the last push location. This way, the driver would emit the top most region of the STB DRAM. Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20230206150855.1938810-2-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform/x86: int3472/discrete: add LEDS_CLASS dependencyArnd Bergmann
int3472 now fails to link when the LED support is disabled: x86_64-linux-ld: drivers/platform/x86/intel/int3472/led.o: in function `skl_int3472_register_pled': led.c:(.text+0xf4): undefined reference to `led_classdev_register_ext' x86_64-linux-ld: led.c:(.text+0x131): undefined reference to `led_add_lookup' x86_64-linux-ld: drivers/platform/x86/intel/int3472/led.o: in function `skl_int3472_unregister_pled': led.c:(.text+0x16b): undefined reference to `led_remove_lookup' x86_64-linux-ld: led.c:(.text+0x177): undefined reference to `led_classdev_unregister' Add an explicit Kconfig dependency. Fixes: 5ae20a8050d0 ("platform/x86: int3472/discrete: Create a LED class device for the privacy LED") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230208163658.2129009-1-arnd@kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-08platform/chrome: cros_ec_typec: Fix spelling mistakeColin Ian King
There is a spelling mistake in a dev_warn message, make it lower case and fix the spelling. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230207091443.143995-1-colin.i.king@gmail.com Signed-off-by: Prashant Malani <pmalani@chromium.org> [pmalani fixed up commit message based on tzungbi comment]
2023-02-06platform/x86: asus-tf103c-dock: Constify toprow keymapThomas Weißschuh
This structure is never modified, make it const. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-8-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06platform/x86: asus-tf103c-dock: Constify lowlevel HID driverThomas Weißschuh
Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-7-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-02-06platform/x86: int3472/discrete: Drop unnecessary obj->type == string checkHans de Goede
acpi_evaluate_dsm_typed() already verifies the type is the requested type, so this error check is a no-op, drop it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230204110223.54625-1-hdegoede@redhat.com
2023-02-06platform/x86/intel/vsec: Add support for Meteor LakeGayatri Kammela
Add Meteor Lake PMT telemetry support. Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20230203011716.1078003-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86/intel/tpmi: ADD tpmi external interface for tpmi feature driversSrinivas Pandruvada
Add interface to get resources and platform data. This will avoid code duplication. These interfaces includes: - Get resource count - Get resource at an index Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-7-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86/intel/tpmi: Process CPU package mappingSrinivas Pandruvada
There is one Intel Out-of-Band (OOB) PCI device per CPU package. Since TPMI feature is exposed via OOB PCI device, there will be multiple TPMI device instances on a multi CPU package system. There are several PM features, which needs to associate APIC based CPU package ID information to a TPMI instance. For example if Intel Speed Select feature requires control of a CPU package, it needs to identify right TPMI device instance. There is one special TPMI ID (ID = 0x81) in the PFS. The MMIO region of this TPMI ID points to a mapping table: - PCI Bus ID - PCI Device ID - APIC based Package ID This mapping information can be used by any PM feature driver which requires mapping from a CPU package to a TPMI device instance. Unlike other TPMI features, device node is not created for this feature ID (0x81). Instead store the mapping information as platform data, which is part of the per PCI device TPMI instance (struct intel_tpmi_info). Later the TPMI feature drivers can get the mapping information using an interface "tpmi_get_platform_data()" Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-6-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86/intel: Intel TPMI enumeration driverSrinivas Pandruvada
The TPMI (Topology Aware Register and PM Capsule Interface) provides a flexible, extendable and PCIe enumerable MMIO interface for PM features. For example Intel RAPL (Running Average Power Limit) provides a MMIO interface using TPMI. This has advantage over traditional MSR (Model Specific Register) interface, where a thread needs to be scheduled on the target CPU to read or write. Also the RAPL features vary between CPU models, and hence lot of model specific code. Here TPMI provides an architectural interface by providing hierarchical tables and fields, which will not need any model specific implementation. The TPMI interface uses a PCI VSEC structure to expose the location of MMIO region. This VSEC structure is present in the PCI configuration space of the Intel Out-of-Band (OOB) device, which is handled by the Intel VSEC driver. The Intel VSEC driver parses VSEC structures present in the PCI configuration space of the given device and creates an auxiliary device object for each of them. In particular, it creates an auxiliary device object representing TPMI that can be bound by an auxiliary driver. Introduce a TPMI driver that will bind to the TPMI auxiliary device object created by the Intel VSEC driver. The TPMI specification defines a PFS (PM Feature Structure) table. This table is present in the TPMI MMIO region. The starting address of PFS is derived from the tBIR (Bar Indicator Register) and "Address" field from the VSEC header. Each TPMI PM feature has one entry in the PFS with a unique TPMI ID and its access details. The TPMI driver creates device nodes for the supported PM features. The names of the devices created by the TPMI driver start with the "intel_vsec.tpmi-" prefix which is followed by a specific name of the given PM feature (for example, "intel_vsec.tpmi-rapl.0"). The device nodes are create by using interface "intel_vsec_add_aux()" provided by the Intel VSEC driver. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-5-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86/intel/vsec: Support private dataSrinivas Pandruvada
Add fields to struct intel_vsec_device, so that core module (which creates aux bus devices) can pass private data to the client drivers. For example there is one vsec device instance per CPU package. On a multi package system, this private data can be used to pass the package ID. This package id can be used by client drivers to change power settings for a specific CPU package by targeting MMIO space of the correct PCI device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-4-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86/intel/vsec: Enhance and Export intel_vsec_add_aux()Srinivas Pandruvada
Remove static for intel_vsec_add_aux() and export this interface so that it can be used by other vsec related modules. This driver creates aux devices by parsing PCI-VSEC, which allows individual drivers to load on those devices. Those driver may further create more devices on aux bus by parsing the PCI MMIO region. For example, TPMI (Topology Aware Register and PM Capsule Interface) creates device nodes for power management features by parsing MMIO region. When TPMI driver creates devices, it can reuse existing function intel_vsec_add_aux() to create aux devices with TPMI device as the parent. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-3-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-06platform/x86/intel/vsec: Add TPMI IDSrinivas Pandruvada
Add TPMI (Topology Aware Register and PM Capsule Interface) VSEC ID to create an aux device. This will allow TPMI driver to enumerate on this aux device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-03platform/x86: int3472/discrete: Get the polarity from the _DSM entryHans de Goede
According to: https://github.com/intel/ipu6-drivers/blob/master/patch/int3472-support-independent-clock-and-LED-gpios-5.17%2B.patch Bits 31-24 of the _DSM pin entry integer value codes the active-value, that is the actual physical signal (0 or 1) which needs to be output on the pin to turn the sensor chip on (to make it active). So if bits 31-24 are 0 for a reset pin, then the actual value of the reset pin needs to be 0 to take the chip out of reset. IOW in this case the reset signal is active-high rather then the default active-low. And if bits 31-24 are 0 for a clk-en pin then the actual value of the clk pin needs to be 0 to enable the clk. So in this case the clk-en signal is active-low rather then the default active-high. IOW if bits 31-24 are 0 for a pin, then the default polarity of the pin is inverted. Add a check for this and also propagate this new polarity to the clock registration. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-6-hdegoede@redhat.com
2023-02-03platform/x86: int3472/discrete: Move GPIO request to ↵Hans de Goede
skl_int3472_register_clock() Move the requesting of the clk-enable GPIO to skl_int3472_register_clock() (and move the gpiod_put to unregister). This mirrors the GPIO handling in skl_int3472_register_regulator() and allows removing skl_int3472_map_gpio_to_clk() from discrete.c. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-5-hdegoede@redhat.com
2023-02-03platform/x86: int3472/discrete: Create a LED class device for the privacy LEDHans de Goede
On some systems, e.g. the Lenovo ThinkPad X1 Yoga gen 7 and the ThinkPad X1 Nano gen 2 there is no clock-enable pin, triggering the: "No clk GPIO. The privacy LED won't work" warning and causing the privacy LED to not work. Fix this by modeling the privacy LED as a LED class device rather then integrating it with the registered clock. Note this relies on media subsys changes to actually turn the LED on/off when the sensor's v4l2_subdev's s_stream() operand gets called. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-4-hdegoede@redhat.com
2023-02-03platform/x86: int3472/discrete: Refactor GPIO to sensor mappingHans de Goede
Add a helper function to map the type returned by the _DSM method to a function name + the default polarity for that function. And fold the INT3472_GPIO_TYPE_RESET and INT3472_GPIO_TYPE_POWERDOWN cases into a single generic case. This is a preparation patch for further GPIO mapping changes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-3-hdegoede@redhat.com
2023-02-03platform/x86: think-lmi: Use min_t() for comparison and assignmentDeepak R Varma
Simplify code by using min_t helper macro for logical evaluation and value assignment. Use the _t variant of min macro since the variable types are not same. This issue is identified by coccicheck using the minmax.cocci file. Signed-off-by: Deepak R Varma <drv@mailo.com> Link: https://lore.kernel.org/r/Y9QupEMPFoZpWIiM@ubun2204.myguest.virtualbox.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-03platform/x86: dell-smo8800: Use min_t() for comparison and assignmentDeepak R Varma
Simplify code by using min_t helper macro for logical evaluation and value assignment. Use the _t variant of min macro since the variable types are not same. This issue is identified by coccicheck using the minmax.cocci file. Signed-off-by: Deepak R Varma <drv@mailo.com> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/Y9P8debIztOZXazW@ubun2204.myguest.virtualbox.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-03platform/x86: dell-ddv: Add "force" module paramArmin Wolf
Until now, the dell-wmi-ddv driver needs to be manually patched and compiled to test compatibility with unknown DDV WMI interface versions. Add a module param to allow users to force loading even when a unknown interface version was detected. Since this might cause various unwanted side effects, the module param is marked as unsafe. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230126194021.381092-5-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-03platform/x86: dell-ddv: Replace EIO with ENOMSGArmin Wolf
When the ACPI WMI interface returns a valid ACPI object which has the wrong type, then ENOMSG instead of EIO should be returned, since the WMI method was still successfully evaluated. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230126194021.381092-4-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-03platform/x86: dell-ddv: Return error if buffer is emptyArmin Wolf
In several cases, the DDV WMI interface can return buffers with a length of zero. Return -ENODATA in such a case for proper error handling. Also replace some -EIO errors with more specialized ones. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230126194021.381092-3-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-03platform/x86: dell-ddv: Add support for interface version 3Armin Wolf
While trying to solve a bugreport on bugzilla, i learned that some devices (for example the Dell XPS 17 9710) provide a more recent DDV WMI interface (version 3). Since the new interface version just adds an additional method, no code changes are necessary apart from whitelisting the version. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230126194021.381092-2-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/x86: hp-wmi: Ignore Win-Lock key eventsRishit Bansal
Follow up from https://lore.kernel.org/all/20230120221214.24426-1-rishitbansal0@gmail.com/ There is a "Win-Lock" key on HP Omen Laptops which supports enabling and disabling the Windows key, which trigger commands 0x21a4 and 0x121a4 respectively. Currently the hp-wmi driver throws warnings for this event. These can be ignored using KE_IGNORE as the functionality is handled by the keyboard firmware itself. Signed-off-by: Rishit Bansal <rishitbansal0@gmail.com> Link: https://lore.kernel.org/r/20230123214150.62597-1-rishitbansal0@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/x86: apple_gmux: Drop no longer used ACPI_VIDEO Kconfig dependencyHans de Goede
The apple_gmux code no longer uses any symbols from the ACPI_VIDEO code, so that dependency can be dropped. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230123154512.852921-1-hdegoede@redhat.com
2023-02-02platform/x86: int1092: Switch to use acpi_evaluate_dsm_typed()Andy Shevchenko
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230119180904.78446-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/x86: intel/pmc: Switch to use acpi_evaluate_dsm_typed()Andy Shevchenko
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20230118095440.41634-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: Switch to use acpi_evaluate_dsm_typed()Andy Shevchenko
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20230118093823.39679-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: aggregator: Rename top-level request functions to avoid ↵Maximilian Luz
ambiguities We currently have a struct ssam_request_sync and a function ssam_request_sync(). While this is valid C, there are some downsides to it. One of these is that current Sphinx versions (>= 3.0) cannot disambiguate between the two (see disucssion and pull request linked below). It instead emits a "WARNING: Duplicate C declaration" and links for the struct and function in the resulting documentation link to the same entry (i.e. both to either function or struct documentation) instead of their respective own entries. While we could just ignore that and wait for a fix, there's also a point to be made that the current naming can be somewhat confusing when searching (e.g. via grep) or trying to understand the levels of abstraction at play: We currently have struct ssam_request_sync and associated functions ssam_request_sync_[alloc|free|init|wait|...]() operating on this struct. However, function ssam_request_sync() is one abstraction level above this. Similarly, ssam_request_sync_with_buffer() is not a function operating on struct ssam_request_sync, but rather a sibling to ssam_request_sync(), both using the struct under the hood. Therefore, rename the top level request functions: ssam_request_sync() -> ssam_request_do_sync() ssam_request_sync_with_buffer() -> ssam_request_do_sync_with_buffer() ssam_request_sync_onstack() -> ssam_request_do_sync_onstack() Link: https://lore.kernel.org/all/085e0ada65c11da9303d07e70c510dc45f21315b.1656756450.git.mchehab@kernel.org/ Link: https://github.com/sphinx-doc/sphinx/pull/8313 Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221220175608.1436273-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: aggregator_registry: Fix target-ID of base-hubMaximilian Luz
The target ID of the base hub is currently set to KIP (keyboard/ peripherals). However, even though it manages such devices with the KIP target ID, the base hub itself is actually accessed via the SAM target ID. So set it accordingly. Note that the target ID of the hub can be chosen arbitrarily and does not directly correspond to any physical or virtual component of the EC. This change is only a code improvement intended for consistency and clarity, it does not fix an actual bug. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221202223327.690880-10-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: aggregator: Enforce use of target-ID enum in device ID macrosMaximilian Luz
Similar to the target category (TC), the target ID (TID) can be one value out of a small number of choices, given in enum ssam_ssh_tid. In the device ID macros, SSAM_SDEV() and SSAM_VDEV() we already use text expansion to, both, remove some textual clutter for the target category values and enforce that the value belongs to the known set. Now that we know the names for the target IDs, use the same trick for them as well. Also rename the SSAM_ANY_x macros to SSAM_SSH_x_ANY to better fit in. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20221202223327.690880-9-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: dtx: Use target-ID enum instead of hard-coding valuesMaximilian Luz
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221202223327.690880-7-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: aggregator_tabletsw: Use target-ID enum instead of ↵Maximilian Luz
hard-coding values Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221202223327.690880-6-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: aggregator_hub: Use target-ID enum instead of hard-coding ↵Maximilian Luz
values Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221202223327.690880-5-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: aggregator: Add target and source IDs to command trace eventsMaximilian Luz
Add command source and target IDs to trace events. Tracing support for the Surface Aggregator driver was originally implemented at a time when only two peers were known: Host and SAM. We now know that there are at least five, with three actively being used (Host, SAM, KIP; four with Debug if you want to count manually enabling that interface). So it makes sense to also explicitly name the peers involved when tracing. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221202223327.690880-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/surface: aggregator: Improve documentation and handling of message ↵Maximilian Luz
target and source IDs The `tid_in` and `tid_out` fields of the serial hub protocol command struct (struct ssh_command) are actually source and target IDs, indicating the peer from which the message originated and the peer for which it is intended. Change the naming of those fields accordingly and improve the protocol documentation. Additionally, introduce an enum containing all currently known peers, i.e. targets and sources. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221202223327.690880-3-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/x86: intel: punit_ipc: Drop empty platform remove functionUwe Kleine-König
A remove callback just returning 0 is equivalent to no remove callback at all. So drop the useless function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221213162359.651529-4-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-02platform/x86: intel: oaktrail: Drop empty platform remove functionUwe Kleine-König
A remove callback just returning 0 is equivalent to no remove callback at all. So drop the useless function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221213162359.651529-3-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 11:40:03 +0000