Add a hwmon interface to report CPU/GPU temperature and fan speed.
sensors now reports an ACPI interface with the entries:

system76_acpi-acpi-0
Adapter: ACPI interface
CPU fan:        0 RPM
GPU fan:        0 RPM
CPU temp:     +47.0°C
GPU temp:      +0.0°C
Signed-off-by: NJeremy Soller <jeremy@system76.com>
Signed-off-by: NTim Crawford <tcrawford@system76.com>
Link: https://lore.kernel.org/r/20211006202202.7479-2-tcrawford@system76.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Add new registers to support systems with multiply cooling devices.
Modular systems support up-to four cooling devices. This capability
is detected according to the registers initial setting.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093609.3771576-1-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add documentation for the new attributes for line cards:
- CPLDs versioning.
- Write protection control for 'nvram' devices.
- Line card reset reasons.
- Enabling burning of FPGA and CPLDs.
- Enabling burning of FPGA and gearbox SPI flashes,
- Enabling power of whole line card.
- Enabling power of QSFP ports equipped on line card.
- The maximum powered required for line card feeding.
- Line card configuration Id.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-10-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add documentation for the new attributes:
- "bios_active_image"; "bios_auth_fail"; "bios_upgrade_fail";
  "bios_safe_mode" to represent various BIOS statuses.
- "lc{n}_enable" - for put/release the line card to/from enable state.
- "lc{n}_pwr" - for power on/off the line card.
- "lc{n}_rst_mask" - for line card reset state enforced by ASIC, when
  it sets it due to some abnormal ASIC behavior.
- "psu3_on"; "psu4_on" - for connection/disconnection power supply unit
  to/from the power source.
- "pm_mgmt_en" - for setting power management control ownership. When
  power management control is provided by hardware, it means that
  hardware will automatically power off one or more line cards in case
  system power budget is under power required for feeding all powered
  on line cards. It could be a case, when some of power units lost
  power good state.
- "shutdown_unlock" - for unlocking system after hardware or firmware
  thermal shutdown, which causes locking of the all interfaces to ASIC.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-9-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Provide support for the Nvidia MSN4800-XX line cards for MSN4800
Ethernet modular switch system, providing a high performance switching
solution for Enterprise Data Centers (EDC) for building Ethernet based
clusters, High-Performance Computing (HPC) and embedded environments.
Initial version provides support for line card type MSN4800-C16. This
type of line card is equipped with:
- Lattice CPLD device, used for system and ports control.
- four Nvidia gearbox devices, used for port splitting.
- FPGA device, used for gearboxes management.
- 16x100G QSFP28 ports.
- hotpswap controllers, voltage regulators, analog-to-digital
  convertors, nvram devices.
- status LED.

During initialization driver creates:
- line card's I2C tree through "i2c-mux-mlxcpd" driver.
- line card's LED objects through "leds-mlxreg" driver.
- line card's CPLD register space input / output "hwmon" attributes for
  line control and monitoring through "mlxreg-io" driver. These
  attributes provide CPLD and FPAG versioning, control for upgradable
  components burning, NVRAM devices write protection, line card
  revision, line card power consuming, line card reset cause
  indication, etcetera.

Lattice CPLD device and nvram devices are feeding from auxiliary power
domain and accessible, when line card is powered off. These devices
are connected by line card driver probing routine, invoked after line
card security verification is done by hardware and event lc#n_verified
is received for line card located in slot #n.

Gearboxes, FPGA, hotpswap controllers, voltage regulators,
analog-to-digital convertors are feeding from main power domain. These
devices are connected after power good event "lc#n_powered" is received
for line card located in slot #n.

The driver 'mlxreg-lc' is driven by 'mlxreg-hotplug' driver following
relevant "hotplug" events.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-8-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Extend structure 'mlxreg_core_data' with the field "secured". The
purpose of this field is to restrict access to some attributes, if
kernel is configured with security options, like:
LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY.
Access to some attributes, which for example, allow burning of some
hardware components, like FPGA, CPLD, SPI, etcetera can break the
system. In case user does not want to allow such access, it can disable
it by setting security options.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-7-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Extend maximum number of the attributes, exposed to 'sysfs'.
It is requires in order to support modular systems, which
provide more attributes for system control, statuses and info.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-6-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add event notifier callbacks for modular system line cards. These
callbacks are to be passed to "mlxreg-hotplug" driver by line card
driver during probing. Then, when any line card related hotplug event
is received (insertion ,power, synch, ready), hotplug driver will
invoke callback for the relevant line card.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-5-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Extend the structure 'mlxreg_hotplug_device" with platform device field
to allow transition of the register map and system interrupt line number
to underlying hotplug devices, sharing the same register map and
same interrupt line with 'mlxreg-hotplug' driver.

Extend logic for hotplug devices creation and removing according to
the action associated with the hotplug device description. Previously
hotplug driver was capable to attach / de-attach upon hotplug events
only I2C devices handled by simple I2C drivers. Now it should be able
to attach also devices handled by the platform drivers.

The motivation is to allow transition of platform data like:
- system interrupt line number, sharing with 'mlxreg-hotplug' to
  underlying hotplug devices.
- shared register map of programmable devices on main board to
  underlying hotplug devices.

Additioanlly the number of 'sysfs' attributes is increased, since
modular system defines more 'sysfs' attributes.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-4-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add initial chassis management support for Nvidia modular Ethernet
switch systems MSN4800, providing a high performance switching solution
for Enterprise Data Centers (EDC) for building Ethernet based clusters,
High-Performance Computing (HPC) and embedded environments.

This system could be equipped with the different types of replaceable
line cards and management board. The first system flavor will support
the line card type MSN4800-C16 equipped with Lattice CPLD devices aimed
for system and ASIC control, one Nvidia FPGA for gearboxes (PHYs)
management, and four Nvidia gearboxes for the port control and with
16x100GbE QSFP28 ports and also with various devices for electrical
control.

The system is equipped with eight slots for line cards, four slots for
power supplies and six slots for fans. It could be configured as fully
populated or with even only one line card. The line cards are
hot-pluggable.
In the future when more line card flavors are to be available (for
example line cards with 8x200Gb Eth port, with 4x400 Eth ports, or with
some kind of smart cards for offloading purpose), any type of line card
could be inserted at any slot.

The system is based on Nvidia Spectrum-3 ASIC. The switch height is
4U and it fits standard rack size.

System could be configured as fully populated or with even only one
line card. The line cards are hot-pluggable.

Line cards are connected to the chassis through I2C interface for the
chassis management operations and through PCIe for the networking
operations. Future line cards could be connected to the chassis through
InfiniBand fabric, instead of PCIe.

The first type of line card supports 16x100GbE QSFP28 Ethernet ports.
Those line cards equipped with the programmable devices aimed for
system control of Nvidia Ethernet switch ASIC control, Nvidia FPGA,
Nvidia gearboxes (PHYs).
The next coming  card generations are supposed to support:
- Line cards with 8x200Gbe QSFP28 Ethernet ports.
- Line cards with 4x400Gbe QSFP-DD Ethernet ports.
- Smart cards equipped with Nvidia ARM CPU for offloading and for fast
  access to the storage (EBoF).
- Fabric cards for inter-connection.

The basic system initialization flow with input signals from the
programmable device to kernel hotplug driver and with OS response
to some of these signals is depicted below.

lc#n_prsnt	*-> Input: line card presence in/out events.
		    Informational event. Required action - 'udev' event
		    generation for logging.
lc#n_verified	*-> Input: line card verification status events coming
		    after line card security signature validation by
		    hardware. Required action - connect line card
		    driver and initialized line card devices feeding
		    from system auxiliary power domain.
lc#n_pwr	<-* Output: line card power on / off from OS. Action
		    should be performed by platform power management
		    driver.
lc#n_powered	*-> Input: line card power on/off events coming after
		    line card "power good" on/off events, mean that
		    line card power up sequence has been successfully
		    completed or line card "power good" status has been
		    dropped. Required action - connect line card
		    devices feeding from system main power domain.
lc#n_synced	*-> Input: line card synchronization events, coming
		    after hardware-firmware synchronization handshake.
		    Required action - to enable line card, in case
		    lc#n_ready has been received before.
lc#n_ready	*-> Input: line card ready events, indicating line card
		    PHYs ready / unready states. Required action -
		    enable line card, in case lc#n_synced has been
		    received before.
lc#n_enable	<-* Output: line card enable from OS - release FPGA and
		    PHYs line card devices from reset state. Action
		    should be performed by platform power management
		    driver.
lc#n_active	*-> Input: when line card "active event" is received
		    for particular line card, its network, hardware
		    monitoring and thermal interfaces should be
		    configured according to the configuration obtained
		    from the firmware. When opposite "inactive event"
		    is received all the above interfaces should be
		    teared down. Required action - connect / disconnect
		    the above line card interfaces through ASIC I2C
		    chassis management driver.

For initial support:
- Define new system type 'VMOD0011' to support new modular system.
- Provide initial platform configuration for new system type.
- Extend the registers definitions.
- Add support for modular system registers related to line card
  specific events - insertion/removal, power on/off, verification
  and activation.
- Add hotplug configuration for the above events.
- Add configurations for hotplug actions for the modular system.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-3-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add new types for the Nvidia modular systems MSN4800 which could
be equipped with the different types of replaceable line cards.

Add new type to specify the kind of hotplug events for the line cards.
The line card events are generated by the programmable device located
on the main board. This device implements interrupt controller logic.
Line card interrupts are associated with different line cards states
during its initialization: insertion, security signature validation,
power good state, security validation, hardware-firmware
synchronization state, line card PHYs readiness state, firmware
availability for line card ports. Also under some circumstances
hardware can generate thermal shutdown for particular line card.

Add new type specifying the action, which should be performed when
particular hotplug event is received. This action defines in which way
hotplug event should be handled by hotplug driver. There are the next
actions types:
- Connect I2C device with empty 'platform_data' field according to the
  platform topology, if device is configured (for example, power unit
  micro-controller driver, when power unit is connected to power source
  (this is what is currently supported).
- Connect device with 'platform_data' field set according to the
  platform topology. The purpose is to pass 'platform_data' through
  hotplug driver to underlying device (for example line card driver).
- No device is associated with hotplug event - just send "udev" event
 (this is what is currently supported).

Extend structure 'mlxreg_hotplug_device' with hotplug action field.

Extend structure 'mlxreg_core_data' with:
- Registers for line card power and enabling control.
- Slot number field, to indicate at which physical slot replaceable
  line card device is located.
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Reviewed-by: NMichael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-2-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

SAR information from BIOS may come in non sequential pattern.

To overcome the issue, a check is made to extract the right SAR
information using the device mode which is currently being used.

Remove .owner field if calls are used which set it automatically.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: NShravan S <s.shravan@intel.com>
Link: https://lore.kernel.org/r/20211006073525.1332925-1-s.shravan@intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>

The int3472-discrete driver can enter an error path after initialising
int3472->clock.ena_gpio, but before it has registered the clock. This will
cause a NULL pointer dereference, because clkdev_drop() is not null aware.
Instead of guarding the call to skl_int3472_unregister_clock() by checking
for .ena_gpio, check specifically for the presence of the clk_lookup, which
will guarantee clkdev_create() has already been called.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214453
Fixes: 7540599a ("platform/x86: intel_skl_int3472: Provide skl_int3472_unregister_clock()")
Signed-off-by: NDaniel Scally <djrscally@gmail.com>
Link: https://lore.kernel.org/r/20211008224608.415949-1-djrscally@gmail.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

This works just fine on my system.
Signed-off-by: NZephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211005044855.1429724-1-zephaniah@gmail.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The Surface Laptop 4 AMD has used the AMD0005 to identify this
controller instead of using the appropriate ACPI ID AMDI0005.  Include
AMD0005 in the acpi id list.

Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd
Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863
Cc: <stable@vger.kernel.org> # 5.14+
Signed-off-by: NSachi King <nakato@nakato.io>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.ioSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The comment decribing the IPC timeout hadn't been updated when the
actual timeout was changed from 3 to 5 seconds in
commit a7d53dbb ("platform/x86: intel_scu_ipc: Increase virtual
timeout from 3 to 5 seconds") .

Since the value is anyway updated to 10s now, take this opportunity to
update the value in the comment too.
Signed-off-by: NPrashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-4-pmalani@chromium.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Commit a7d53dbb ("platform/x86: intel_scu_ipc: Increase virtual
timeout from 3 to 5 seconds") states that the recommended timeout range
is 5-10 seconds. Adjust the timeout value to the higher of those i.e 10
seconds, to account for situations where the 5 seconds is insufficient
for disconnect command success.
Signed-off-by: NPrashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-3-pmalani@chromium.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The macro IPC_TIMEOUT is already in jiffies (it is also used like that
elsewhere in the file when calling wait_for_completion_timeout()). Don’t
convert it using helper functions for the purposes of calculating the
busy loop expiry time.

Fixes: e7b7ab38 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”)
Signed-off-by: NPrashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver,
so it must depend on the Kconfig option which enables the main
dell-wmi driver.

Fixes: 8af9fa37 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211011132338.407571-1-hdegoede@redhat.com

Rename the wmaa-backlight-wmi driver and associated KConfig option to
remove the remaining references to the "WMAA" ACPI handle which was
used in the previous name. The driver has already been updated to
remove internal references to "WMAA". As part of the renaming, the
components in the name have been rearranged to reflect the standard
vendor_wmi_feature pattern.
Signed-off-by: NDaniel Dadap <ddadap@nvidia.com>
Link: https://lore.kernel.org/r/20210927202359.13684-2-ddadap@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The "wmaa" in the name of the wmaa-backlight-wmi driver was named after
the ACPI method handle for EC-based backlight control on the systems
this driver was tested on during development. However, this "WMAA"
handle is generated by the WMI compilation process, and isn't actually
a part of the backlight control mechanism which this driver supports.
Since the "WMAA" handle isn't actually a part of the firmware backlight
interface, the various identifiers in this driver using "WMAA" or
"wmaa" aren't actually appropriate.

As a common denominator across the systems supported by this driver is
that they are hybrid graphics systems with NVIDIA GPUs, using "nvidia"
in the driver name seems more appropriate than "wmaa". Update the
driver to remove "wmaa" and "WMAA" in identifier names where they
appear. The kerneldoc comments for the enum wmi_brightness_method
values are replaced with the verbatim text from the decompiled BMF code
for this WMI class.
Signed-off-by: NDaniel Dadap <ddadap@nvidia.com>
Link: https://lore.kernel.org/r/20210927202359.13684-1-ddadap@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Fix shift argument for function rol32(). It should be provided in bits,
while was provided in bytes.

Fixes: 86148190 ("platform/mellanox: mlxreg-io: Add support for complex attributes")
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210927142214.2613929-3-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Change kstrtou32() argument 'base' to be zero instead of 'len'.
It works by chance for setting one bit value, but it is not supposed to
work in case value passed to mlxreg_io_attr_store() is greater than 1.

It works for example, for:
echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable
But it will fail for:
echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable,
where n > 1.

The flow for input buffer conversion is as below:
_kstrtoull(const char *s, unsigned int base, unsigned long long *res)
calls:
rv = _parse_integer(s, base, &_res);

For the second case, where n > 1:
- _parse_integer() converts 's' to 'val'.
  For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3
  'len' is set to 3 (string buffer 0x33 0x0a), etcetera.
- 'base' is equal or greater then '2' (length of input buffer).

As a result, _parse_integer() exits with result zero (rv):
	rv = 0;
	while (1) {
		...
		if (val >= base)-> (2 >= 2)
			break;
		...
		rv++;
		...
	}

And _kstrtoull() in their turn will fail:
	if (rv == 0)
		return -EINVAL;

Fixes: 5ec4a8ac ("platform/mellanox: Introduce support for Mellanox register access driver")
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210927142214.2613929-2-vadimp@nvidia.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

The ReST format requires blank lines before/after identation changes,
for it to properly detect lists.

Fixes: ee7abc10 ("platform/x86: intel_pmc_core: export platform global reset bits via etr3 sysfs file")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/3673e1a255ad4100c933af215b60d68ba126f820.1632740376.git.mchehab+huawei@kernel.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

As described at Documentation/ABI/README doesn't contain an
Attribute: field.

The way sysfs ABI is supposed to work is that each different
attribute would have a separate file. So, the right way to
map this would be like:

	/sys/.../dell_privacy_supported_type/mic_mute
	/sys/.../dell_privacy_supported_type/camera_shutter

	/sys/.../dell_privacy_current_state/mic_mute
	/sys/.../dell_privacy_current_state/camera_shutter

However, it seems to late to fix that, as this was merged already on
Kernel 5.13, and a change right now would be a regression.

So, instead, let's at least fix the entry to match the expected
format.

While here, fix the format of the contact, which is not a valid
e-mail URL.

This should also fix the current warnings produced when building the
docs:

	Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi:35: WARNING: Unexpected indentation.
	Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi:2: WARNING: Unexpected indentation.

Fixes: 8af9fa37 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/42846621fdf2bf206feb114d06b14cbc47475fb5.1632740376.git.mchehab+huawei@kernel.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values wrapping around and a smaller allocation being made than the
caller was expecting. Using those allocations could lead to linear
overflows of heap memory and other misbehaviors.

So, to avoid open-coded arithmetic in the kzalloc() call inside the
create_attr_set() function the code must be refactored. Using the
struct_size() helper is the fast solution but it is better to switch
this code to common use of attributes.

Then, remove all the custom code to manage hotkey attributes and use the
attribute_group structure instead, refactoring the code accordingly.
Also, to manage the optional hotkey attributes (hotkey_tablet_mode and
hotkey_radio_sw) use the is_visible callback from the same structure.

Moreover, now the hotkey_init_tablet_mode() function never returns a
negative number. So, the check after the call can be safely removed.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-argumentsSuggested-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLen Baker <len.baker@gmx.com>
Link: https://lore.kernel.org/r/20210926111908.6950-1-len.baker@gmx.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Adding support specifically for Ideapad 5 Pro 16ACH6-82L5 by adding a
allow list that can validate notebooks for which dytc_version
is less than 5, and seem to work fine at dytc_version 4. This code has
been tested to work properly on the specified system.
Signed-off-by: NKelly Anderson <kelly@xilka.com>
Link: https://lore.kernel.org/r/11840239.O9o76ZdvQC@comer.internalReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Signed-off-by: Mark Gross<markgross@kernel.org>
Link: https://lore.kernel.org/r/20210921135358.85143-1-markgross@kernel.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Add a message to print the resume time information obtained from the
smu_metrics structure.
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com>
Link: https://lore.kernel.org/r/20210921120020.19454-1-Sanket.Goswami@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

It was reported that the resume stats received from the firmware are
always zero. This happens because the SMU expects the driver to send the
command to dump the log data after clearing the OS_HINT.

Adjust the order of the commands sent to SMU.
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com>
Link: https://lore.kernel.org/r/20210921115910.19401-1-Sanket.Goswami@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The amd_pmc_get_smu_version() and amd_pmc_idlemask_read() functions are
used in the probe / suspend/resume code, so they are also used when
CONFIG_DEBUGFS is disabled, move them outside of the #ifdef CONFIG_DEBUGFS
block.

Note this purely moves the code to above the #ifdef CONFIG_DEBUGFS,
the code is completely unchanged.

Fixes: f6045de1 ("platform/x86: amd-pmc: Export Idlemask values based on the APU")
Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Sanket Goswami <Sanket.Goswami@amd.com>
Reported-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Adds support for:

- Dell Inspiron 2in1 tablet mode switch notifications. These are
  delivered by a type 0x0011 message with code 0xe070, followed by a
  flag (1 for laptop mode, 0 for tablet mode).

- Recognising (but not otherwise processing) the Dell Ultra Performance
  mode request switch. This is delivered by a type 0x0012 message with
  code 0x000d, followed by a parameter that is either 1 or 2. It is
  not clear what (if anything) should be done with this notification, so
  it is ignored.
Signed-off-by: NTroy Rollo <linux2021@troy.rollo.name>
Link: https://lore.kernel.org/r/20210918073131.2966942-1-linux2021@troy.rollo.nameReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Tested with a AMD Ryzen 7 5800X.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NThomas Weißschuh <thomas@weissschuh.net>
Link: https://lore.kernel.org/r/20210921100702.3838-1-tjakobi@math.uni-bielefeld.deSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Some devices, even non convertible ones, can send incorrect
SW_TABLET_MODE reports.

Add an allow list and accept such reports only from devices in it.

Bug reported for Dell XPS 17 9710 on:
https://gitlab.freedesktop.org/libinput/libinput/-/issues/662Reported-by: NTobias Gurtzick <magic@wizardtales.com>
Suggested-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NTobias Gurtzick <magic@wizardtales.com>
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Link: https://lore.kernel.org/r/20210920160312.9787-1-jose.exposito89@gmail.com
[hdegoede@redhat.com: Check dmi_switches_auto_add_allow_list only once]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

When DELL_WMI=y, DELL_WMI_PRIVACY=y, and LEDS_TRIGGER_AUDIO=m, there
is a linker error since the LEDS trigger code is built as a loadable
module. This happens because DELL_WMI_PRIVACY is a bool that depends
on a tristate (LEDS_TRIGGER_AUDIO=m), which can be dangerous.

ld: drivers/platform/x86/dell/dell-wmi-privacy.o: in function `dell_privacy_wmi_probe':
dell-wmi-privacy.c:(.text+0x3df): undefined reference to `ledtrig_audio_get'

Fixes: 8af9fa37 ("platform/x86: dell-privacy: Add support for Dell hardware privacy")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Perry Yuan <Perry.Yuan@dell.com>
Cc: Dell.Client.Kernel@dell.com
Cc: platform-driver-x86@vger.kernel.org
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mark Gross <mgross@linux.intel.com>
Link: https://lore.kernel.org/r/20210918044829.19222-1-rdunlap@infradead.orgReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The MODULE_DEVICE_TABLE already creates proper alias for ACPI driver.
Having another MODULE_ALIAS causes the alias to be duplicated.
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210916170054.136790-1-krzysztof.kozlowski@canonical.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

IdleMask is the metric used by the PM firmware to know the status of each
of the Hardware IP blocks monitored by the PM firmware.

Knowing this value is key to get the information of s2idle suspend/resume
status. This value is mapped to PMC scratch registers, retrieve them
accordingly based on the CPU family and the underlying firmware support.
Co-developed-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20210916124002.2529-1-Sanket.Goswami@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

As the PM firmware returns the status of the last s0i3 in the smu_metrics
structure, the existing name "s0i3_cyclecount" seems to be a misnomer.
Change it accordingly to "s0i3_last_entry_status".
Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com>
Acked-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20210916124130.2581-1-Sanket.Goswami@amd.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

This driver is for accessing the PSE (Programmable Service Engine) - an
Embedded Controller like IP - using ISHTP (Integratd Sensor Hub Transport
Protocol) to get battery, thermal and UCSI (USB Type-C Connector System
Software Interface) related data from the platform.
Signed-off-by: NK Naduvalath, Sumesh <sumesh.k.naduvalath@intel.com>
Reviewed-by: NMark Gross <mgross@linux.intel.com>
Link: https://lore.kernel.org/r/20210913051056.28736-1-sumesh.k.naduvalath@intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

checkpatch.pl tool warns about using __attribute__((packed))
"WARNING: __packed is preferred over __attribute__((packed))"
To fix this __attribute__((packed)) is replaced by __packed
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20210912011741.30495-1-jbi.octave@gmail.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>