Merge tag 'platform-drivers-x86-v6.3-1' of... (69308402) · Commits · EulixOS / Software / Kernel

Documentation/ABI/stable/sysfs-driver-mlxreg-io

+121 −1

Original line number	Diff line number	Diff line
		@@ -522,7 +522,6 @@ Description: These files allow to each of ASICs by writing 1.

		The files are write only.


		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/comm_chnl_ready
		Date: July 2022
		KernelVersion: 5.20
		@@ -542,3 +541,124 @@ Description: The file indicates COME module hardware configuration.
		The purpose is to expose some minor BOM changes for the same system SKU.

		The file is read only.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_pwr_converter_fail
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: This file shows the system reset cause due to power converter
		devices failure.
		Value 1 in file means this is reset cause, 0 - otherwise.

		The file is read only.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_ap_reset
		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_ap_reset
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: These files aim to monitor the status of the External Root of Trust (EROT)
		processor's RESET output to the Application Processor (AP).
		By reading this file, could be determined if the EROT has invalidated or
		revoked AP Firmware, at which point it will hold the AP in RESET until a
		valid firmware is loaded. This protects the AP from running an
		unauthorized firmware. In the normal flow, the AP reset should be released
		after the EROT validates the integrity of the FW, and it should be done so
		as quickly as possible so that the AP boots before the CPU starts to
		communicate to each ASIC.

		The files are read only.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_recovery
		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_recovery
		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_reset
		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_reset
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: These files aim to perform External Root of Trust (EROT) recovery
		sequence after EROT device failure.
		These EROT devices protect ASICs from unauthorized access and in normal
		flow their reset should be released with system power – earliest power
		up stage, so that EROTs can begin boot and authentication process before
		CPU starts to communicate to ASICs.
		Issuing a reset to the EROT while asserting the recovery signal will cause
		the EROT Application Processor to enter recovery mode so that the EROT FW
		can be updated/recovered.
		For reset/recovery the related file should be toggled by 1/0.

		The files are read/write.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_wp
		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_wp
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: These files allow access to External Root of Trust (EROT) for reset
		and recovery sequence after EROT device failure.
		Default is 0 (programming disabled).
		If the system is in locked-down mode writing this file will not be allowed.

		The files are read/write.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/spi_chnl_select
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: This file allows SPI chip selection for External Root of Trust (EROT)
		device Out-of-Band recovery.
		File can be written with 0 or with 1. It selects which EROT can be accessed
		through SPI device.

		The file is read/write.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_pg_fail
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak vadimp@nvidia.com
		Description: This file shows ASIC Power Good status.
		Value 1 in file means ASIC Power Good failed, 0 - otherwise.

		The file is read only.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd1_boot_fail
		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd2_boot_fail
		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_fail
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak vadimp@nvidia.com
		Description: These files are related to clock boards status in system.
		- clk_brd1_boot_fail: warning about 1-st clock board failed to boot from CI.
		- clk_brd2_boot_fail: warning about 2-nd clock board failed to boot from CI.
		- clk_brd_fail: error about common clock board boot failure.

		The files are read only.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_prog_en
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: This file enables programming of clock boards.
		Default is 0 (programming disabled).
		If the system is in locked-down mode writing this file will not be allowed.

		The file is read/write.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_converter_prog_en
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: This file enables programming of power converters.
		Default is 0 (programming disabled).
		If the system is in locked-down mode writing this file will not be allowed.

		The file is read/write.

		What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_ac_ok_fail
		Date: February 2023
		KernelVersion: 6.3
		Contact: Vadim Pasternak <vadimp@nvidia.com>
		Description: This file shows the system reset cause due to AC power failure.
		Value 1 in file means this is reset cause, 0 - otherwise.

		The file is read only.

Documentation/driver-api/surface_aggregator/client.rst

+6 −6

Original line number	Diff line number	Diff line
		@@ -19,7 +19,7 @@
		.. \|ssam_notifier_unregister\| replace:: :c:func:`ssam_notifier_unregister`
		.. \|ssam_device_notifier_register\| replace:: :c:func:`ssam_device_notifier_register`
		.. \|ssam_device_notifier_unregister\| replace:: :c:func:`ssam_device_notifier_unregister`
		.. \|ssam_request_sync\| replace:: :c:func:`ssam_request_sync`
		.. \|ssam_request_do_sync\| replace:: :c:func:`ssam_request_do_sync`
		.. \|ssam_event_mask\| replace:: :c:type:`enum ssam_event_mask <ssam_event_mask>`


		@@ -191,7 +191,7 @@ data received from it is converted from little-endian to host endianness.
		* they do not correspond to an actual SAM/EC request.
		*/
		rqst.target_category = SSAM_SSH_TC_SAM;
		rqst.target_id = 0x01;
		rqst.target_id = SSAM_SSH_TID_SAM;
		rqst.command_id = 0x02;
		rqst.instance_id = 0x03;
		rqst.flags = SSAM_REQUEST_HAS_RESPONSE;
		@@ -209,12 +209,12 @@ data received from it is converted from little-endian to host endianness.
		* with the SSAM_REQUEST_HAS_RESPONSE flag set in the specification
		* above.
		*/
		status = ssam_request_sync(ctrl, &rqst, &resp);
		status = ssam_request_do_sync(ctrl, &rqst, &resp);

		/*
		* Alternatively use
		*
		* ssam_request_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
		* ssam_request_do_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
		*
		* to perform the request, allocating the message buffer directly
		* on the stack as opposed to allocation via kzalloc().
		@@ -230,7 +230,7 @@ data received from it is converted from little-endian to host endianness.
		return status;
		}

		Note that \|ssam_request_sync\| in its essence is a wrapper over lower-level
		Note that \|ssam_request_do_sync\| in its essence is a wrapper over lower-level
		request primitives, which may also be used to perform requests. Refer to its
		implementation and documentation for more details.

		@@ -241,7 +241,7 @@ one of the generator macros, for example via:

		SSAM_DEFINE_SYNC_REQUEST_W(__ssam_tmp_perf_mode_set, __le32, {
		.target_category = SSAM_SSH_TC_TMP,
		.target_id = 0x01,
		.target_id = SSAM_SSH_TID_SAM,
		.command_id = 0x03,
		.instance_id = 0x00,
		});

Documentation/driver-api/surface_aggregator/ssh.rst

+19 −17

Original line number	Diff line number	Diff line
		@@ -13,6 +13,7 @@
		.. \|DATA_NSQ\| replace:: ``DATA_NSQ``
		.. \|TC\| replace:: ``TC``
		.. \|TID\| replace:: ``TID``
		.. \|SID\| replace:: ``SID``
		.. \|IID\| replace:: ``IID``
		.. \|RQID\| replace:: ``RQID``
		.. \|CID\| replace:: ``CID``
		@@ -219,13 +220,13 @@ following fields, packed together and in order:
		- \|u8\|
		- Target category.

		* - \|TID\| (out)
		* - \|TID\|
		- \|u8\|
		- Target ID for outgoing (host to EC) commands.
		- Target ID for commands/messages.

		* - \|TID\| (in)
		* - \|SID\|
		- \|u8\|
		- Target ID for incoming (EC to host) commands.
		- Source ID for commands/messages.

		* - \|IID\|
		- \|u8\|
		@@ -286,19 +287,20 @@ general, however, a single target category should map to a single reserved
		event request ID.

		Furthermore, requests, responses, and events have an associated target ID
		(``TID``). This target ID is split into output (host to EC) and input (EC to
		host) fields, with the respecting other field (e.g. output field on incoming
		messages) set to zero. Two ``TID`` values are known: Primary (``0x01``) and
		secondary (``0x02``). In general, the response to a request should have the
		same ``TID`` value, however, the field (output vs. input) should be used in
		accordance to the direction in which the response is sent (i.e. on the input
		field, as responses are generally sent from the EC to the host).

		Note that, even though requests and events should be uniquely identifiable
		by target category and command ID alone, the EC may require specific
		target ID and instance ID values to accept a command. A command that is
		accepted for ``TID=1``, for example, may not be accepted for ``TID=2``
		and vice versa.
		(``TID``) and source ID (``SID``). These two fields indicate where a message
		originates from (``SID``) and what the intended target of the message is
		(``TID``). Note that a response to a specific request therefore has the source
		and target IDs swapped when compared to the original request (i.e. the request
		target is the response source and the request source is the response target).
		See (:c:type:`enum ssh_request_id <ssh_request_id>`) for possible values of
		both.

		Note that, even though requests and events should be uniquely identifiable by
		target category and command ID alone, the EC may require specific target ID and
		instance ID values to accept a command. A command that is accepted for
		``TID=1``, for example, may not be accepted for ``TID=2`` and vice versa. While
		this may not always hold in reality, you can think of different target/source
		IDs indicating different physical ECs with potentially different feature sets.


		Limitations and Observations

MAINTAINERS

+8 −1

Original line number	Diff line number	Diff line
		@@ -5773,7 +5773,6 @@ F: Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
		F: drivers/platform/x86/dell/dell-wmi-ddv.c

		DELL WMI SYSMAN DRIVER
		M: Divya Bharathi <divya.bharathi@dell.com>
		M: Prasanth Ksr <prasanth.ksr@dell.com>
		L: Dell.Client.Kernel@dell.com
		L: platform-driver-x86@vger.kernel.org
		@@ -10535,6 +10534,13 @@ S: Maintained
		F: arch/x86/include/asm/intel_telemetry.h
		F: drivers/platform/x86/intel/telemetry/

		INTEL TPMI DRIVER
		M: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
		L: platform-driver-x86@vger.kernel.org
		S: Maintained
		F: drivers/platform/x86/intel/tpmi.c
		F: include/linux/intel_tpmi.h

		INTEL UNCORE FREQUENCY CONTROL
		M: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
		L: platform-driver-x86@vger.kernel.org
		@@ -22480,6 +22486,7 @@ S: Maintained
		T: git git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
		F: drivers/platform/olpc/
		F: drivers/platform/x86/
		F: include/linux/platform_data/x86/

		X86 PLATFORM DRIVERS - ARCH
		R: Darren Hart <dvhart@infradead.org>

drivers/hid/surface-hid/surface_hid.c

+4 −4

Original line number	Diff line number	Diff line
		@@ -80,7 +80,7 @@ static int ssam_hid_get_descriptor(struct surface_hid_device *shid, u8 entry, u8

		rsp.length = 0;

		status = ssam_retry(ssam_request_sync_onstack, shid->ctrl, &rqst, &rsp,
		status = ssam_retry(ssam_request_do_sync_onstack, shid->ctrl, &rqst, &rsp,
		sizeof(*slice));
		if (status)
		return status;
		@@ -131,7 +131,7 @@ static int ssam_hid_set_raw_report(struct surface_hid_device *shid, u8 rprt_id,

		buf[0] = rprt_id;

		return ssam_retry(ssam_request_sync, shid->ctrl, &rqst, NULL);
		return ssam_retry(ssam_request_do_sync, shid->ctrl, &rqst, NULL);
		}

		static int ssam_hid_get_raw_report(struct surface_hid_device shid, u8 rprt_id, u8 buf, size_t len)
		@@ -151,7 +151,7 @@ static int ssam_hid_get_raw_report(struct surface_hid_device *shid, u8 rprt_id,
		rsp.length = 0;
		rsp.pointer = buf;

		return ssam_retry(ssam_request_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(rprt_id));
		return ssam_retry(ssam_request_do_sync_onstack, shid->ctrl, &rqst, &rsp, sizeof(rprt_id));
		}

		static u32 ssam_hid_event_fn(struct ssam_event_notifier nf, const struct ssam_event event)
		@@ -230,7 +230,7 @@ static void surface_hid_remove(struct ssam_device *sdev)
		}

		static const struct ssam_device_id surface_hid_match[] = {
		{ SSAM_SDEV(HID, SSAM_ANY_TID, SSAM_ANY_IID, 0x00) },
		{ SSAM_SDEV(HID, ANY, SSAM_SSH_IID_ANY, 0x00) },
		{ },
		};
		MODULE_DEVICE_TABLE(ssam, surface_hid_match);