summaryrefslogtreecommitdiff
path: root/drivers/platform/x86
AgeCommit message (Collapse)Author
2023-02-13platform: mellanox: Split logic in init and exit flowVadim Pasternak
Split logic in mlxplat_init()/mlxplat_exit() routines. Separate initialization of I2C infrastructure and others platform drivers. Motivation is to provide synchronization between I2C bus and mux drivers and other drivers using this infrastructure. I2C main bus and MUX busses are implemented in FPGA logic. On some new systems the numbers allocated for these busses could be variable depending on order of initialization of I2C native busses. Since bus numbers are passed to some other platform drivers during initialization flow, it is necessary to synchronize completion of I2C infrastructure drivers and activation of rest of drivers. Thus initialization flow will be performed in synchronized order. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-8-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-10platform: mellanox: Split initialization procedureVadim Pasternak
Split mlxplat_init() into two by adding mlxplat_pre_init(). Motivation is to prepare 'mlx-platform' driver to support systems equipped PCIe based programming logic device. Such systems are supposed to use different system resources, thus this commit separates resources allocation related code. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-7-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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-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/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>
2023-02-02platform/x86: acerhdf: 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> Acked-by: Peter Kaestle <peter@piie.net> Link: https://lore.kernel.org/r/20221213162359.651529-2-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: touchscreen_dmi: Add Chuwi Vi8 (CWI501) DMI matchHans de Goede
Add a DMI match for the CWI501 version of the Chuwi Vi8 tablet, pointing to the same chuwi_vi8_data as the existing CWI506 version DMI match. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230202103413.331459-1-hdegoede@redhat.com
2023-01-30platform/x86: thinkpad_acpi: Fix thinklight LED brightness returning 255Hans de Goede
Reading the thinklight LED brightnes while the LED is on returns 255 (LED_FULL) but we advertise a max_brightness of 1, so this should be 1 (LED_ON). Fixes: db5e2a4ca0a7 ("platform/x86: thinkpad_acpi: Fix max_brightness of thinklight") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230127235723.412864-1-hdegoede@redhat.com
2023-01-30platform/x86/amd: pmc: add CONFIG_SERIO dependencyArnd Bergmann
Using the serio subsystem now requires the code to be reachable: x86_64-linux-ld: drivers/platform/x86/amd/pmc.o: in function `amd_pmc_suspend_handler': pmc.c:(.text+0x86c): undefined reference to `serio_bus' Add the usual dependency: as other users of serio use 'select' rather than 'depends on', use the same here. Fixes: 8e60615e8932 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230127093950.2368575-1-arnd@kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-01-30platform/x86/amd/pmf: Ensure mutexes are initialized before useHans de Goede
As soon as the first handler or sysfs file is registered the mutex may get used. Move the initialization to before any handler registration / sysfs file creation. Likewise move the destruction of the mutex to after all the de-initialization is done. Fixes: da5ce22df5fe ("platform/x86/amd/pmf: Add support for PMF core layer") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130132554.696025-1-hdegoede@redhat.com
2023-01-30platform/x86/amd/pmf: Fix to update SPS thermals when power supply changeShyam Sundar S K
Every power mode of static power slider has its own AC and DC power settings. When the power source changes from AC to DC, corresponding DC thermals were not updated from PMF config store and this leads the system to always run on AC power settings. Fix it by registering with power_supply notifier and apply DC settings upon getting notified by the power_supply handler. Fixes: da5ce22df5fe ("platform/x86/amd/pmf: Add support for PMF core layer") Suggested-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230125095936.3292883-6-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-01-30platform/x86/amd/pmf: Fix to update SPS default pprof thermalsShyam Sundar S K
By design PMF static slider will be set to BALANCED during init, but updating to corresponding thermal values from the PMF config store was missed, leading to improper settings getting propagated to PMFW. Fixes: 4c71ae414474 ("platform/x86/amd/pmf: Add support SPS PMF feature") Suggested-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230125095936.3292883-5-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-01-30platform/x86/amd/pmf: update to auto-mode limits only after AMT eventShyam Sundar S K
Auto-mode thermal limits should be updated only after receiving the AMT event. But due to a bug in the older commit, these settings were getting applied during the auto-mode init. Fix this by removing amd_pmf_set_automode() during auto-mode initialization. Fixes: 3f5571d99524 ("platform/x86/amd/pmf: Add support for Auto mode feature") Suggested-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230125095936.3292883-4-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>