- Implement loading firmware from host in intel-ish driver, needed
  to support Lunar Lake and later (Zhang Lixu)

- PM fixes for STM and Weida Tech devices (Kenny Levinsen)

- conversion from sprintf() to sysfs_emit() (Li Zhijian)

- support for missing mappings and codes from HUT 1.5 in
  hid-debug (Thomas Kuehne)

- updates to HID-BPF infrastructure, with some of the specific
  fixes (e.g. rdesc fixups) abstracted into separate BPF programs
  for consumption by libevdev/udev-hid-bpf (Benjamin Tissoires)

- initial support for ROG Ally and ROG X13 devices (Luke D. Jones)
- other small assorted cleanups of hid-asus driver (Luke D. Jones)

- PM fix and assorted other code cleanups for amd-sfh (Basavaraj Natikar)

udev-hid-bpf is still not installed everywhere, and we should probably
not assume it is installed automatically.

Link: https://lore.kernel.org/r/20240506143612.148031-1-bentiss@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

The only interesting bit is the HAT switch, and we use a BPF program
to fix it. So ensure this works correctly.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-18-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

More in line with the other test_* files.

No code change

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-17-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

We need to slightly change base_device.py for supporting HID-BPF,
so instead of monkey patching, let's just embed it in the kernel tree.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-16-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

This tablets gets a lot of things wrong:
- the secondary button is reported through Secondary Tip Switch
- the third button is reported through Invert

We need to add some out of proximity intermediate state when moving
back and forth with the eraser mode as it can only be triggered by
physically returning the pen, meaning that the tolerated transitions
can never happen.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-15-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

The values are taken from the HID-BPF file.
Basically we are recomputing the array provided there.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-14-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

Those tablets don't need special initialization, but are reporting
the events with the wrong usages:
- tip switch is used when the eraser should be used
- eraser is used instead of the secondary barrel switch

Add tests for those so we don't regress in the future.

Currently we set x/y tilt to 0 to not trigger the bpf program
compensate_coordinates_by_tilt()

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-13-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

All the *_WITH*BUTTON states were almost identical except for the
button itself.

I need to add a new device with a third button, and adding a bunch of
states is going to be quite cumbersome.

So convert the `button` parameter of PenState as a boolean, and store
which button is the target as an argument to all functions that need it.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-12-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

few required changes:
- we need to count how many times a udev 'bind' event happens
- we need to tell `udev-hid-bpf` to not automatically attach the
  provided HID-BPF objects
- we need to manually attach the ones from the kernel tree, and wait
  for the second udev 'bind' event to happen

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-11-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

We need to slightly change base_device.py for supporting HID-BPF,
so instead of monkey patching, let's just embed it in the kernel tree.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-10-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

This device is already fixed by "HID: do not assume HAT Switch
logical max < 8", but for people without the fix already, having the
HID-BPF locally can fix the device while they wait for their
distribution to update.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-9-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

This tablets gets a lot of things wrong:
- the secondary button is reported through Secondary Tip Switch
- the third button is reported through Invert

Fortunately, before entering eraser mode, (so Invert = 1),
the tablet always sends an out-of-proximity event.
So we can detect that single event and:
- if there was none but the invert bit was toggled: this is the
  third button
- if there was this out-of-proximity event, we are entering
  eraser mode, and we will until the next out-of-proximity.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-8-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

When using the XBox Wireless Controller Elite 2 over Bluetooth,
the device exports the paddle on the back of the device as a single
bitfield value of usage "Assign Selection".

The kernel doesn't process those usages properly and report KEY_UNKNOWN
for it.

SDL doesn't know how to interprete that KEY_UNKNOWN and thus ignores the
paddles.

Given that over USB the kernel uses BTN_TRIGGER_HAPPY[5-8], we
can tweak the report descriptor to make the kernel interprete it properly:
- we need an application collection of gamepad (so we have to close the
  current Consumer Control one)
- we need to change the usage to be buttons from 0x15 to 0x18

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-7-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

This pen is compatible with multiple Wacom tablets, but we only add support
for the Intuos Pro 2 M, as this is the one our user reported the bug
against.

We can not generically add all compatible Wacom tablets as we are
writing the offsets by hand.

The point of this HID-BPF program is to work around a firmware limitation
where the pressure is repeated every other report.
Given that we know this will happen, we can change the first new pressure
information with the mean compared to the previous one. This way we
smooth the incoming pressure without losing information.

Cc: Ping Cheng <pinglinux@gmail.com>
Cc: Jason Gerecke <killertofu@gmail.com>
Cc: Aaron Armstrong Skomra <skomra@gmail.com>
Cc: Joshua Dickens <Joshua@joshua-dickens.com>
Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-6-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

Allows to export more than 5 buttons on this 12 buttons mouse.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-5-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

Duplicate of commit 0db11735 ("HID: add quirk for 03f0:464a HP Elite
Presenter Mouse"), but in a slightly better way.

This time we actually change the application collection, making clearer
for userspace what the second mouse is.

Note that having both hid-quirks fix and this HID-BPF fix is not a
problem at all.

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-4-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

Same problem than the Artist 24: the second button on the pen is treated
like an eraser.
But the problem is even worse this time. There is an actual eraser at
the tail of the pen.

The compensation of the coordinates was done by Martin
Signed-off-by: Martin Sivak <mars@montik.net>
Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-3-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

This commit adds a fix for XPPen Artist 24 where the second button on
the pen is used as an eraser.

It's a "feature" from Microsoft, but it turns out that it's actually
painful for artists. So we ship here a HID-BPF program that turns this
second button into an actual button.

Note that the HID-BPF program is not directly loaded by the kernel itself
but by udev-hid-bpf[0]. But having the sources here allows us to also
integrate tests into tools/testing/selftests/hid to ensure the HID-BPF
program are actually tested.

[0] https://gitlab.freedesktop.org/libevdev/udev-hid-bpf

Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-2-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

Turns out that the code can handle a greater range, but the data stored
can not. This is problematic on the Raptor Mach 2 joystick which
logical max is 239. The kernel interprets it as `-15` and thus ignores
the Hat Switch handling.

Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/issues/17
Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-1-a8bf16033ef8@kernel.orgReviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

Newer processors support various MP2 register sets. Therefore, to ensure
compatibility and obtain C2P data, use the amd_get_c2p_val().
Co-developed-by: Patil Rajesh Reddy <patreddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <patreddy@amd.com>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Resume or suspend each sensor device based on the num_hid_devices.
Therefore, add a check to handle the special case where no sensors are
present.

Fixes: 93ce5e02 ("HID: amd_sfh: Implement SFH1.1 functionality")
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Modify log messages, but only log errors when sensors are missing or a
true failure occurs to avoid misleading "failed" messages.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Change device type because
a. it is exactly a mouse, with left/right buttons and scroll wheel;
b. it does not have visible marks or crosshairs, thus does not provide
higher accuracy than stylus.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

This label was left behind when the wake-up logic was moved from
i2c_hid_set_power to i2c_hid_probe_address. Clean it up as it causes
warnings-as-errors builds to fail.

Fixes: bb1033c8a3ea ("HID: i2c-hid: Use address probe to wake on resume")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Add a check for the return value of pci_alloc_irq_vectors() and return
error if it fails.

[jkosina@suse.com: reworded changelog based on Srinivas' suggestion]
Fixes: 74fbc7d3 ("HID: intel-ish-hid: add MSI interrupt support")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

This patch enhances the firmware reset handler in the Intel Integrated
Sensor Hub (ISH) driver. Previously, the ISH firmware would send a
MNG_RESET_NOTIFY message in response to an empty IPC message from the
ish_wakeup function. With the introduction of the feature to load ISH
firmware from the host on the LunarLake platform, the ISH bootloader
now involves the IPC function. This results in an additional
MNG_RESET_NOTIFY message being sent by ISH bootloader after power on.
Consequently, the driver receives two MNG_RESET_NOTIFY messages during
system boot up. This can disrupt the dev->dev_state during the first
reset flow due to the subsequent reset notify message.

To address this, the patch modifies the fw_reset_work_fn function to skip
the execution of ishtp_reset_compl_handler during the first reset flow if
a reset is pending. The ishtp_reset_compl_handler will then be executed
during the second reset flow, ensuring the dev->dev_state is not disrupted.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Starting from the Lunar Lake generation, the ISH firmware has been
divided into two components for better space optimization and increased
flexibility. These components include a bootloader that is integrated
into the BIOS, and a main firmware that is stored within the operating
system's file system.

Introduce support for loading ISH main firmware from host. This feature is
applicable for Lunar Lake and later generation.

Current intel-ishtp-loader, is designed for Chrome OS based systems which
uses core boot and has different firmware loading method. For non chrome
systems the ISH firmware loading uses different method.

Key differences include:
1. The new method utilizes ISHTP capability/fixed client to enumerate the
firmware loader function. It does not require a connection or flow control,
unlike the method used in Chrome OS, which is enumerated as an ISHTP
dynamic client driver, necessitating connect/disconnect operations and flow
control.

2. The new method employs a table to describe firmware fragments, which are
sent to ISH in a single operation. Conversely, the Chrome OS method sends
firmware fragments in multiple operations within a loop, sending only one
fragment at a time.

Additionally, address potential error scenarios to ensure graceful failure
handling.
- Firmware Not Found: Triggers if request_firmware() fails, leaving ISH in
  a waiting state.
  Recovery: Re-insmod the ISH drivers to retry.

- DMA Buffer Allocation Failure: Occurs during prepare_dma_bufs(), leading
  to ISH waiting state. Allocated resources are released.
  Recovery: Re-insmod the ISH drivers to retry.

- Incorrect Firmware Image: Causes ISH to refuse loading after three failed
  attempts.
  Recovery: A platform reset is required.

Please refer to the [Documentation](Documentation/hid/intel-ish-hid.rst)
for the details on flows.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Introduces a new structure, ishtp_driver_data, to hold driver-specific
data, including the firmware filename for different hardware variants of
the Intel Integrated Sensor Hub (ISH).
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Add a section to describe the ISH firmware loading process for Lunar Lake
and later generations.
Signed-off-by: Qianru Huang <qianru.huang@intel.com>
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Remove section numbering from the Intel Integrated Sensor Hub (ISH)
documentation to simplify the structure, making it easier to maintain
and update in the future.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Qianru Huang <qianru.huang@intel.com>
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Certain devices, both from STM and Weida Tech, need to be woken up after
having entered a deeper sleep state. The relevant places to wake up such
device is during our initial HID probe, and after resuming.

A retry for power commands was previously added to i2c_hid_set_power to
wake up Weida Tech devices, but lacked sufficient sleep for STM devices.
Replace the power command retry with the same address probe we using
during our initial HID probe.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Signed-off-by: Jiri Kosina <jkosina@suse.com>

Some STM microcontrollers need 400µs after rising clock edge in order to
come out of their deep sleep state. This in turn means that our address
probe will fail as the device is not ready to service it.

Retry the probe once after a delay to see if the device came alive,
otherwise treat the device as missing.

Link: https://lore.kernel.org/all/20240405102436.3479210-1-lma@chromium.org/#tCo-developed-by: Radoslaw Biernacki <rad@chromium.org>
Co-developed-by: Lukasz Majczak <lma@chromium.org>
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Signed-off-by: Jiri Kosina <jkosina@suse.com>