aboutsummaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)AuthorFilesLines
2023-02-10platform: mellanox: Introduce support of new Nvidia L1 switchVadim Pasternak1-1/+391
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 <[email protected]> Reviewed-by: Michael Shych <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform: mellanox: Introduce support for next-generation 800GB/s switchVadim Pasternak1-0/+180
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 <[email protected]> Reviewed-by: Michael Shych <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform: mellanox: Cosmetic changes - rename to more common nameVadim Pasternak1-14/+14
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 <[email protected]> Reviewed-by: Michael Shych <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform: mellanox: Change "reset_pwr_converter_fail" attributeVadim Pasternak1-1/+1
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 <[email protected]> Reviewed-by: Michael Shych <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform: mellanox: Introduce support for rack manager switchVadim Pasternak1-0/+261
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 <[email protected]> Reviewed-by: Michael Shych <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10x86/platform/uv: Make kobj_type structure constantThomas Weißschuh1-3/+3
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 <[email protected]> Reviewed-by: Justin Ernst <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86: think-lmi: Make kobj_type structure constantThomas Weißschuh1-2/+2
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 <[email protected]> Reviewed-by: Mark Pearson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86: dell-wmi-sysman: Make kobj_type structure constantThomas Weißschuh1-1/+1
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86/intel/vsec: Use mutex for ida_alloc() and ida_free()Srinivas Pandruvada1-0/+9
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 <[email protected]> Signed-off-by: Srinivas Pandruvada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86/amd: pmc: Add line break for readabilityShyam Sundar S K1-0/+1
Add a line break for the code readability. Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86/amd: pmc: differentiate STB/SMU messaging printsShyam Sundar S K1-3/+3
Modify the dynamic debug print to differentiate between the regular and spill to DRAM usage of the SMU message port. Suggested-by: Sanket Goswami <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86/amd: pmc: Write dummy postcode into the STB DRAMShyam Sundar S K1-0/+6
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 <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86/amd: pmc: Add num_samples message id support to STBShyam Sundar S K1-2/+25
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 <[email protected]> Signed-off-by: Sanket Goswami <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-10platform/x86: int3472/discrete: add LEDS_CLASS dependencyArnd Bergmann1-0/+1
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 <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-08platform/chrome: cros_ec_typec: Fix spelling mistakeColin Ian King1-1/+1
There is a spelling mistake in a dev_warn message, make it lower case and fix the spelling. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Tzung-Bi Shih <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Prashant Malani <[email protected]> [pmalani fixed up commit message based on tzungbi comment]
2023-02-06platform/x86: asus-tf103c-dock: Constify toprow keymapThomas Weißschuh1-1/+1
This structure is never modified, make it const. Signed-off-by: Thomas Weißschuh <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2023-02-06platform/x86: asus-tf103c-dock: Constify lowlevel HID driverThomas Weißschuh1-1/+1
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 <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2023-02-06platform/x86: int3472/discrete: Drop unnecessary obj->type == string checkHans de Goede1-8/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-06platform/x86/intel/vsec: Add support for Meteor LakeGayatri Kammela1-0/+9
Add Meteor Lake PMT telemetry support. Signed-off-by: Gayatri Kammela <[email protected]> Signed-off-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2023-02-06platform/x86/intel/tpmi: ADD tpmi external interface for tpmi feature driversSrinivas Pandruvada1-0/+22
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 <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-06platform/x86/intel/tpmi: Process CPU package mappingSrinivas Pandruvada1-0/+72
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 <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-06platform/x86/intel: Intel TPMI enumeration driverSrinivas Pandruvada3-0/+338
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 <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-06platform/x86/intel/vsec: Support private dataSrinivas Pandruvada1-0/+2
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 <[email protected]> Acked-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-06platform/x86/intel/vsec: Enhance and Export intel_vsec_add_aux()Srinivas Pandruvada2-5/+15
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 <[email protected]> Acked-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-06platform/x86/intel/vsec: Add TPMI IDSrinivas Pandruvada1-0/+5
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 <[email protected]> Acked-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-03platform/x86: int3472/discrete: Get the polarity from the _DSM entryHans de Goede3-4/+16
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 <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-03platform/x86: int3472/discrete: Move GPIO request to ↵Hans de Goede3-31/+30
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 <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-03platform/x86: int3472/discrete: Create a LED class device for the privacy LEDHans de Goede5-47/+106
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 <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-03platform/x86: int3472/discrete: Refactor GPIO to sensor mappingHans de Goede1-9/+36
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 <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-03platform/x86: think-lmi: Use min_t() for comparison and assignmentDeepak R Varma1-2/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-03platform/x86: dell-smo8800: Use min_t() for comparison and assignmentDeepak R Varma1-4/+1
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 <[email protected]> Acked-by: Pali Rohár <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-03platform/x86: dell-ddv: Add "force" module paramArmin Wolf1-2/+11
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-03platform/x86: dell-ddv: Replace EIO with ENOMSGArmin Wolf1-1/+1
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-03platform/x86: dell-ddv: Return error if buffer is emptyArmin Wolf1-5/+12
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-03platform/x86: dell-ddv: Add support for interface version 3Armin Wolf1-2/+4
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/x86: hp-wmi: Ignore Win-Lock key eventsRishit Bansal1-0/+2
Follow up from https://lore.kernel.org/all/[email protected]/ 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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/x86: apple_gmux: Drop no longer used ACPI_VIDEO Kconfig dependencyHans de Goede1-1/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-02platform/x86: int1092: Switch to use acpi_evaluate_dsm_typed()Andy Shevchenko1-8/+7
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/x86: intel/pmc: Switch to use acpi_evaluate_dsm_typed()Andy Shevchenko1-3/+3
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 <[email protected]> Reviewed-by: Rajneesh Bhardwaj <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: Switch to use acpi_evaluate_dsm_typed()Andy Shevchenko1-10/+3
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 <[email protected]> Reviewed-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: aggregator: Rename top-level request functions to avoid ↵Maximilian Luz5-24/+24
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: aggregator_registry: Fix target-ID of base-hubMaximilian Luz2-2/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: aggregator: Enforce use of target-ID enum in device ID macrosMaximilian Luz4-6/+6
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 <[email protected]> Acked-by: Sebastian Reichel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: dtx: Use target-ID enum instead of hard-coding valuesMaximilian Luz1-9/+9
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: aggregator_tabletsw: Use target-ID enum instead of ↵Maximilian Luz1-3/+3
hard-coding values Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: aggregator_hub: Use target-ID enum instead of hard-coding ↵Maximilian Luz1-2/+2
values Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: aggregator: Add target and source IDs to command trace eventsMaximilian Luz1-6/+67
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/surface: aggregator: Improve documentation and handling of message ↵Maximilian Luz3-13/+14
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/x86: intel: punit_ipc: Drop empty platform remove functionUwe Kleine-König1-6/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-02-02platform/x86: intel: oaktrail: Drop empty platform remove functionUwe Kleine-König1-6/+0
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>