IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIVAwUAY5JD7aZi849r7WBJAQJtHw//WSKVFMKLq5P0PatMFBusJspse2ZsGFpI
fumeGoNxd2/Gbj2eRrer5/1D5XU2VXC6Ot9/Rz3oIaOGWQkShjntoWhdpOxPCFI6
bm2s78iPFSCubwi986vgI4/IOWsqWFcDbIWgn8i9q+ZkUDykIiIsbUAo7FyoX53i
J34H8+NpQy5gPHXcSpWf83XBBidYC1uPtOk4k+W/SMOgS4UaVn3NAI2W/eKharlG
kfepb6WRPiFDT/9opMb+PFmp62UeZyImQCxh/S0AjZArCg0A6u01Ou5moizprE2q
qMgGk1MhruxVmSaCkSnYXn/xbW2JucyU7V2IPWTaBG5IGDUsdAibCD7YblPG/Gm5
KZ4mz7zazc6gwn63/bxmBMbcfEHg1TUuH5EUW+tY9I/yAVlvYndS76WFCpaiqZfT
uwq4aOVwZ2lPtmww/D0EZsTKtilhGTaSUW+/XdbGWLm4X9dKB+QJNzr8n00FeUDb
g+pdqK6+oTviKd6WDIgU7PwBTED8aYF9krknl7U61scTAod5pivdk2GEX+7mAiYq
ir/Hhrl0h2bO3XGNA5ViW2yNMVLFeFi4jAP5Wwk9X1polyMBicaqVe0M+IK2XCoT
U8yhHYPnxrjfei8cd0gY56lzxKmI+Np6EVTVFA3big/wZ2jmjenFdgMLVP8Cw0H+
RkfkW7pqZpQ=
=eEFh
-----END PGP SIGNATURE-----
Merge tag 'for-linus-2022120801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:
"A regression fix for handling Logitech HID++ devices and memory
corruption fixes:
- regression fix (revert) for catch-all handling of Logitech HID++
Bluetooth devices; there are devices that turn out not to work with
this, and the root cause is yet to be properly understood. So we
are dropping it for now, and it will be revisited for 6.2 or 6.3
(Benjamin Tissoires)
- memory corruption fix in HID core (ZhangPeng)
- memory corruption fix in hid-lg4ff (Anastasia Belova)
- Kconfig fix for I2C_HID (Benjamin Tissoires)
- a few device-id specific quirks that piggy-back on top of the
important fixes above"
* tag 'for-linus-2022120801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
Revert "HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices"
Revert "HID: logitech-hidpp: Remove special-casing of Bluetooth devices"
HID: usbhid: Add ALWAYS_POLL quirk for some mice
HID: core: fix shift-out-of-bounds in hid_report_raw_event
HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk
HID: fix I2C_HID not selected when I2C_HID_OF_ELAN is
HID: hid-lg4ff: Add check for empty lbuf
HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10
HID: uclogic: Fix frame templates for big endian architectures
This reverts commit 532223c8ac57605a10e46dc0ab23dcf01c9acb43.
As reported in [0], hid-logitech-hidpp now binds on all bluetooth mice,
but there are corner cases where hid-logitech-hidpp just gives up on
the mouse. This leads the end user with a dead mouse.
Given that we are at -rc8, we are definitively too late to find a proper
fix. We already identified 2 issues less than 24 hours after the bug
report. One in that ->match() was never designed to be used anywhere else
than in hid-generic, and the other that hid-logitech-hidpp has corner
cases where it gives up on devices it is not supposed to.
So we have no choice but postpone this patch to the next kernel release.
[0] https://lore.kernel.org/linux-input/CAJZ5v0g-_o4AqMgNwihCb0jrwrcJZfRrX=jv8aH54WNKO7QB8A@mail.gmail.com/
Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 8544c812e43ab7bdf40458411b83987b8cba924d.
We need to revert commit 532223c8ac57 ("HID: logitech-hidpp: Enable HID++
for all the Logitech Bluetooth devices") because that commit might make
hid-logitech-hidpp bind on mice that are not well enough supported by
hid-logitech-hidpp, and the end result is that the probe of those mice
is now returning -ENODEV, leaving the end user with a dead mouse.
Given that commit 8544c812e43a ("HID: logitech-hidpp: Remove special-casing
of Bluetooth devices") is a direct dependency of 532223c8ac57, revert it
too.
Note that this also adapt according to commit 908d325e1665 ("HID:
logitech-hidpp: Detect hi-res scrolling support") to re-add support of
the devices that were removed from that commit too.
I have locally an MX Master and I tested this device with that revert,
ensuring we still have high-res scrolling.
Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The U2F zero apparently has a real TRNG in it with maximum quality, not
one with quality of "1", which was likely a misinterpretation of the
field as a boolean. So remove the assignment entirely, so that we get
the default quality setting.
In the u2f-zero firmware, the 0x21 RNG command used by this driver is
handled as such [1]:
case U2F_CUSTOM_GET_RNG:
if (atecc_send_recv(ATECC_CMD_RNG,ATECC_RNG_P1,ATECC_RNG_P2,
NULL, 0,
appdata.tmp,
sizeof(appdata.tmp), &res) == 0 )
{
memmove(msg->pkt.init.payload, res.buf, 32);
U2FHID_SET_LEN(msg, 32);
usb_write((uint8_t*)msg, 64);
}
else
{
U2FHID_SET_LEN(msg, 0);
usb_write((uint8_t*)msg, 64);
}
This same call to `atecc_send_recv(ATECC_CMD_RNG,ATECC_RNG_P1,
ATECC_RNG_P2,...)` is then also used in the token's cryptographically
critical "u2f_new_keypair" function, as its rather straightforward
source of random bytes [2]:
int8_t u2f_new_keypair(uint8_t * handle, uint8_t * appid, uint8_t * pubkey)
{
struct atecc_response res;
uint8_t private_key[36];
int i;
watchdog();
if (atecc_send_recv(ATECC_CMD_RNG,ATECC_RNG_P1,ATECC_RNG_P2,
NULL, 0,
appdata.tmp,
sizeof(appdata.tmp), &res) != 0 )
{
return -1;
}
So it seems rather plain that the ATECC RNG is considered to provide
good random numbers.
[1] https://github.com/conorpp/u2f-zero/blob/master/firmware/src/custom.c
[2] https://github.com/conorpp/u2f-zero/blob/master/firmware/src/u2f_atecc.c
Cc: Andrej Shadura <andrew.shadura@collabora.co.uk>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
HUTRR72 added 3 new usage codes for keys that are supposed to enable,
disable and toggle camera access. These are useful, considering many
laptops today have key(s) for toggling access to camera.
This patch adds new key definitions for KEY_CAMERA_ACCESS_ENABLE,
KEY_CAMERA_ACCESS_DISABLE and KEY_CAMERA_ACCESS_TOGGLE. Additionally
hid-debug is adjusted to recognize this new usage codes as well.
Signed-off-by: Eray Orçunus <erayorcunus@gmail.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Link: https://lore.kernel.org/r/20221029120311.11152-3-erayorcunus@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The I2C hid driver is currently manually managing the wake
IRQ. This change removes the explicit enable_irq_wake/disable_irq_wake
and instead relies on the PM subsystem. This is done by calling
dev_pm_set_wake_irq.
i2c_device_probe already calls dev_pm_set_wake_irq when using device
tree, and i2c_device_remove also already calls dev_pm_clear_wake_irq.
There could be some device tree systems that have incorrectly declared
`wake` capabilities, so this change will set the wake irq if one is
missing. This matches the previous behavior.
I tested this on an ACPI system that has a HID touchscreen and verified
the IRQ was armed for wake on suspend.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20220929093200.v6.1.Id4b4bdfe06e2caf2d5a3c9dd4a9b1080c38b539c@changeid
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Some additional USB mouse devices are needing ALWAYS_POLL quirk without
which they disconnect and reconnect every 60s.
Add below devices to the known quirk list.
CHERRY VID 0x046a, PID 0x000c
MICROSOFT VID 0x045e, PID 0x0783
PRIMAX VID 0x0461, PID 0x4e2a
Signed-off-by: Ankit Patel <anpatel@nvidia.com>
Signed-off-by: Haotien Hsu <haotienh@nvidia.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
According to docs a SwID should be sent for GetProtocolVersion.
> 0x10.DeviceIndex.0x00.0x1n
where n is SwID.
Signed-off-by: Andreas Bergmeier <abergmeier@gmx.net>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid_device_remove() will call hid_hw_stop() as default .remove function
if no function is specified.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid_device_remove() will call hid_hw_stop() as default .remove function
if no function is specified.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This is no bugfix (so no Fixes: tag is necessary) as it is
taken care of in hid_sensor_custom_add_attributes().
The motivation for this patch is that:
hid_sensor_custom_field.attr_name and
hid_sensor_custom_field.attrs
has the size of HID_CUSTOM_TOTAL_ATTRS and used in same context.
We compare against HID_CUSTOM_TOTAL_ATTRS when
looping through hid_custom_attrs.
We will silent the smatch error:
hid_sensor_custom_add_attributes() error: buffer overflow
'hid_custom_attrs' 8 <= 10
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Syzbot reported shift-out-of-bounds in hid_report_raw_event.
microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
snto32 drivers/hid/hid-core.c:1323 [inline]
hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
hid_process_report drivers/hid/hid-core.c:1665 [inline]
hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
__usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers+0x76a/0x980 kernel/time/timer.c:1790
run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
__do_softirq+0x277/0x75b kernel/softirq.c:571
__irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
======================================================================
If the size of the integer (unsigned n) is bigger than 32 in snto32(),
shift exponent will be too large for 32-bit type 'int', resulting in a
shift-out-of-bounds bug.
Fix this by adding a check on the size of the integer (unsigned n) in
snto32(). To add support for n greater than 32 bits, set n to 32, if n
is greater than 32.
Reported-by: syzbot+8b1641d2f14732407e23@syzkaller.appspotmail.com
Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID-RMI is special in the sense that it does not carry HID events
directly, but rather uses HID protocol as a wrapper/transport for RMI
protocol. Therefore we should not assume that all data coming from the
device via interrupt is associated with user activity and report wakeup
event indiscriminately, but rather let HID-RMI do that when appropriate.
HID-RMI devices tag responses to the commands issued by the host as
RMI_READ_DATA_REPORT_ID whereas motion and other input events from the
device are tagged as RMI_ATTN_REPORT_ID. Change hid-rmi to report wakeup
events when receiving the latter packets. This allows ChromeOS to
accurately identify wakeup source and make correct decision on the mode
of the resume the system should take ("dark" where the display stays off
vs normal one).
Fixes: d951ae1ce803 ("HID: i2c-hid: Report wakeup events")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In most configurations, INPUT is actually a boolean: either y or disabled,
but when it's disabled, you can't do much on your average laptop.
But it turns out that there is a possibility to have INPUT as a module:
you have to disable VT and TTY (of course), but also enable EXPERT.
I'll leave how to disable VT and TTY as an exercise for the bravest.
Anyway, if INPUT is m, we can still configure HID as y, which is not
correct because hid-input.c depends on the input API, meaning that
vmlinuz can not link.
So: add depends on INPUT too at the HID level, to ensure that if INPUT=m,
HID can only be m or disabled.
Fixes: 25621bcc8976 ("HID: Kconfig: split HID support and hid-core compilation")
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202211181742.QYJY6Gug-lkp@intel.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit f7d8e387d9ae ("HID: uclogic: Switch to Digitizer usage for
styluses") changed the usage used in UCLogic from "Pen" to "Digitizer".
However, the IS_INPUT_APPLICATION() macro evaluates to false for
HID_DG_DIGITIZER causing issues with the XP-Pen Star G640 tablet.
Add the HID_QUIRK_HIDINPUT_FORCE quirk to bypass the
IS_INPUT_APPLICATION() check.
Reported-by: Torge Matthies <openglfreak@googlemail.com>
Reported-by: Alexander Zhang <alex@alexyzhang.dev>
Tested-by: Alexander Zhang <alex@alexyzhang.dev>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver was by accident reading the CRC directly from a hardware
structure instead of using get_unaligned_le32.
Fixes: 2d77474a2392 ("HID: playstation: add DualShock4 bluetooth support.")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The size of the output buffer used for output reports was not updated
to the larger size needed for Bluetooth. This ultimately resulted
in memory corruption of surrounding structures e.g. due to memsets.
Fixes: 2d77474a2392 ("HID: playstation: add DualShock4 bluetooth support.")
Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add a new tracepoint hid_bpf_rdesc_fixup() so we can trigger a
report descriptor fixup in the bpf world.
Whenever the program gets attached/detached, the device is reconnected
meaning that userspace will see it disappearing and reappearing with
the new report descriptor.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This function can not be called under IRQ, thus it is only available
while in SEC("syscall").
For consistency, this function requires a HID-BPF context to work with,
and so we also provide a helper to create one based on the HID unique
ID.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
changes in v12:
- variable dereferenced before check 'ctx'
|Reported-by: kernel test robot <lkp@intel.com>
|Reported-by: Dan Carpenter <error27@gmail.com>
no changes in v11
no changes in v10
changes in v9:
- fixed kfunc declaration aaccording to latest upstream changes
no changes in v8
changes in v7:
- hid_bpf_allocate_context: remove unused variable
- ensures buf is not NULL
changes in v6:
- rename parameter size into buf__sz to teach the verifier about
the actual buffer size used by the call
- remove the allocated data in the user created context, it's not used
new-ish in v5
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We need to also be able to change the size of the report.
Reducing it is easy, because we already have the incoming buffer that is
big enough, but extending it is harder.
Pre-allocate a buffer that is big enough to handle all reports of the
device, and use that as the primary buffer for BPF programs.
To be able to change the size of the buffer, we change the device_event
API and request it to return the size of the buffer.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Kind of a hack, but works for now:
Instead of listening for any close of eBPF program, we now
decrement the refcount when we insert it in our internal
map of fd progs.
This is safe to do because:
- we listen to any call of destructor of programs
- when a program is being destroyed, we disable it by removing
it from any RCU list used by any HID device (so it will never
be called)
- we then trigger a job to cleanup the prog fd map, but we overwrite
the removal of the elements to not do anything on the programs, just
remove the allocated space
This is better than previously because we can remove the map of known
programs and their usage count. We now rely on the refcount of
bpf, which has greater chances of being accurate.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Declare an entry point that can use fmod_ret BPF programs, and
also an API to access and change the incoming data.
A simpler implementation would consist in just calling
hid_bpf_device_event() for any incoming event and let users deal
with the fact that they will be called for any event of any device.
The goal of HID-BPF is to partially replace drivers, so this situation
can be problematic because we might have programs which will step on
each other toes.
For that, we add a new API hid_bpf_attach_prog() that can be called
from a syscall and we manually deal with a jump table in hid-bpf.
Whenever we add a program to the jump table (in other words, when we
attach a program to a HID device), we keep the number of time we added
this program in the jump table so we can release it whenever there are
no other users.
HID devices have an RCU protected list of available programs in the
jump table, and those programs are called one after the other thanks
to bpf_tail_call().
To achieve the detection of users losing their fds on the programs we
attached, we add 2 tracing facilities on bpf_prog_release() (for when
a fd is closed) and bpf_free_inode() (for when a pinned program gets
unpinned).
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently, we step into drivers/hid/ based on the value of
CONFIG_HID.
However, that value is a tristate, meaning that it can be a module.
As per the documentation, if we jump into the subdirectory by
following an obj-m, we can not compile anything inside that
subdirectory in vmlinux. It is considered as a bug.
To make things more friendly to HID-BPF, split HID (the HID core
parameter) from HID_SUPPORT (do we want any kind of HID support in the
system?), and make this new config a boolean.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When I2C_HID_OF_ELAN is set, we need to turn on I2C_HID_CORE to
ensure we get all the HID requirements.
Fixes: bd3cba00dcc6 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If an empty buf is received, lbuf is also empty. So lbuf is
accessed by index -1.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: f31a2de3fe36 ("HID: hid-lg4ff: Allow switching of Logitech gaming wheels between compatibility modes")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Acer Aspire Switch V 10 (SW5-017)'s keyboard-dock uses the same
ITE controller setup as other Acer Switch 2-in-1's.
This needs special handling for the wifi on/off toggle hotkey as well as
to properly report touchpad on/off keypresses.
Add the USB-ids for the SW5-017's keyboard-dock with a quirk setting of
QUIRK_TOUCHPAD_ON_OFF_REPORT to fix both issues.
Cc: Rudolf Polzer <rpolzer@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch allows users to swap the control and command keys. This can be
useful for the Mac users who are used to using Command instead of Control
in macOS for various commonly used shortcuts.
Signed-off-by: Aditya Garg <gargaditya08@live.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The variable rb_count is being incremented but it
is never referenced, it is redundant and can be removed.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 961bcdf956a4 ("drm/tests: Change "igt_" prefix to "drm_test_"")
introduced a new naming convention for the KUnit tests present in the
DRM subsystem: "drm_test_<module>_<test name>".
This naming convention is very convenient because it allows to easily
run all subsystem tests or all driver tests using kunit.py's wildcards.
Follow the naming conventions used in the DRM subsystem adapted to the
HID subsystem: "hid_test_<module>_<test name>".
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When parsing a frame template with a placeholder indicating the number
of buttons present on the frame its value was incorrectly set on big
endian architectures due to double little endian conversion.
In order to reproduce the issue and verify the fix, run the HID KUnit
tests on the PowerPC architecture:
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/hid \
--arch=powerpc --cross_compile=powerpc64-linux-gnu-
Fixes: 867c89254425 ("HID: uclogic: Allow to generate frame templates")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some devices has two sets of accelerometers and the sensor hub exports
two hinge angle 'sensors' based on accelerometer values. To allow more
than one sensor of the same type, use PLATFORM_DEVID_AUTO instead of
PLATFORM_DEVID_NONE when registering platform device for it.
Checked on the Lenovo Yoga Book YB1-X91L tablet.
Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix 'cast to restricted' sparse warnings reported by kernel test robot
in https://lore.kernel.org/all/202211021607.ssjymlKi-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When writing into a slow device like an EEPROM chip, the
controller may exit the busy state before the device releases
the bus. In this case, the ft260_xfer_status returns success
before the data transfer completion.
The patch fixes it by returning from the ft260_xfer_status()
with the "-EAGAIN" on both controller and bus busy status when
appropriate.
It does not apply to the i2c combined transactions when after
the write IO, the controller keeps the bus busy until the read
IO and then between reading IOs to ensure an atomic operation.
Co-developed-by: Germain Hebert <germain.hebert@ca.abb.com>
Signed-off-by: Germain Hebert <germain.hebert@ca.abb.com>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The zero-length passed into the ft260_i2c_write() triggered the
NULL pointer dereference in the debug message on data[0] access.
Since the controller does not support a write of zero length,
let's not allow it.
Before:
$ sudo i2ctransfer -y 13 w0@0x51
Killed
After:
$ sudo i2ctransfer -y 13 w0@0x51
Error: Sending messages failed: Invalid argument
Reported-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
