* Re: Wrong inputs on DualSense Edge Wireless Controller
From: Roderick Colenbrander @ 2023-11-28 2:30 UTC (permalink / raw)
To: Alexander Koskovich; +Cc: Colenbrander, Roelof, linux-input
In-Reply-To: <CAEc3jaCrpbBADiAgSy-kTXqOj_XLy8QuV88GxqY38=2BvG0QZw@mail.gmail.com>
Many applications use SDL2 and don't use evdev directly. Latest SDL2
from git doesn't have the mappings for dualsense edge, but only
regular dualsense. Though usually on SDL2 it would use hidraw.
Depending on what version of the library was used, it may not support
the controller.
See e.g. https://github.com/libsdl-org/SDL/blob/8d47e3bb82288321eb15a0708d1311cbd25a11d6/src/joystick/SDL_gamecontrollerdb.h#L765
On Mon, Nov 27, 2023 at 6:25 PM Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
>
> Hi Alexander,
>
> Thanks for testing. This indeed confirms the kernel side mapping
> (hid-playstation) is right. Different software layers e.g. SDL2 and
> others tend to do their own mappings. This type of mapping seems to be
> incorrect (or even missing for DualSense Edge resulting in a default
> fallback).
>
> Thanks,
> Roderick
>
> On Mon, Nov 27, 2023 at 5:50 PM Alexander Koskovich
> <AKoskovich@protonmail.com> wrote:
> >
> > I tested in evtest, and it's reporting sane results (cross south, square west, etc). So this seems to be an issue outside of the playstation driver itself?
> >
> >
> > On Monday, November 27th, 2023 at 2:40 PM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
> >
> >
> > > This seems a little weird to me. Would you be able to test in using evtest? It would rule out some of the other middle layers which can do their own remapping.
> > > Thanks,
> > > Roderick
> > >
> > > On Mon, Nov 27, 2023, 6:42 AM Alexander Koskovich <AKoskovich@protonmail.com> wrote:
> > >
> > > > I was testing this in the Steam controller test, Cyberpunk 2077 (through GOG, not through Steam), and SuperTuxKart. All of these have wrong mappings for the Edge controller exclusively.
> > > > For additional context I have a PS5 controller (non Edge) and it works out of the box. This just seems to be an issue with the Edge variant.
> > > >
> > > >
> > > > On Monday, November 27th, 2023 at 9:37 AM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > > Hi Alexander,
> > > > >
> > > > > Sorry for the late reply, but I have been out for a few days. I'm not
> > > > > aware of any button/axis mapping change between Edge and regular
> > > > > DualSense. The HID reports stayed the same.
> > > > >
> > > > > I just did a quick check on my laptop also on Fedora 38 / kernel 6.5
> > > > > and the mapping seems to be fine. In evtest, triangle reports
> > > > > BTN_NORTH, square BTN_WEST, etcetera.
> > > > >
> > > > > The sticks, triggers and buttons seem to be fine as well. How are you
> > > > > testing this?
> > > > >
> > > > > Thanks,
> > > > > Roderick
> > > > >
> > > > > On Wed, Nov 22, 2023 at 4:18 PM Alexander Koskovich
> > > > > AKoskovich@protonmail.com wrote:
> > > > >
> > > > > > [Resending email due to lack HTML message rejected]
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I am currently on Fedora 39 (6.5.12-300.fc39.x86_64) and I am noticing that the inputs for this controller are wrong primarily on the right side of the controller.
> > > > > >
> > > > > > playstation 0005:054C:0DF2.000C: hidraw11: BLUETOOTH HID v1.00 Gamepad [DualSense Edge Wireless Controller] on 10:3d:1c:fd:30:bc
> > > > > > playstation 0005:054C:0DF2.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
> > > > > >
> > > > > > This is the current mapping that I'm seeing with the hid_playstation module loaded:
> > > > > > "X" is actually "Square"
> > > > > > "Square" is "Triangle"
> > > > > > "Triangle" is "Circle"
> > > > > > "Circle" is "X"
> > > > > >
> > > > > > Also the right joystick seems to be controlling "R2" instead of the right joystick. "L2" and "R2" triggers control the joystick instead. It's overall very weird. Has there been any similar reports to this?
^ permalink raw reply
* Re: [PATCH 1/1] hid-playstation: Fix button maps for the DualSense Edge controller
From: Rahul Rameshbabu @ 2023-11-28 2:34 UTC (permalink / raw)
To: Alexander Koskovich
Cc: roderick.colenbrander, jikos, benjamin.tissoires, linux-input,
linux-kernel
On Tue, 28 Nov, 2023 02:19:42 +0000 "Alexander Koskovich" <AKoskovich@pm.me> wrote:
> To clarify, I did test this patch locally on Fedora Rawhide and confirm it works with games. It does resolve the issue, and is a workaround.
> It's not just Steam/Proton I'm seeing this issue in, I'm seeing it in native Linux games like SuperTuxKart.
>
Thanks for confirming. I am not that familiar with stk but I believe it
uses SDL2, which might be your common culprit.
https://github.com/supertuxkart/stk-code/blob/a57ac415bbaf8e22a1c35f3ac0949c4dca322637/src/input/sdl_controller.cpp#L288
>
>
> On Monday, November 27th, 2023 at 9:16 PM, Rahul Rameshbabu <sergeantsagara@protonmail.com> wrote:
>
>
>>
>>
>> On Sun, 26 Nov, 2023 00:15:49 +0000 "Alexander Koskovich" AKoskovich@pm.me wrote:
>>
>> > This brings functionality of the DualSense Edge controller inline
>> > with the stock PS5 controller.
>> >
>> > Signed-off-by: Alexander Koskovich akoskovich@pm.me
>> > ---
>>
>>
>> Will provide a follow-up to the relevant discussion.
>>
>> https://lore.kernel.org/linux-input/P8jVfYBAwiM_8MIgshN0osVVfshfBH2-oZCQuqoqh0Hy76_031zuZvYXWl0edtfTUwDOSNlc5priSRXI3G5dboVh5VPbcdxzAcEF7EvUVgo=@protonmail.com/T/#t
>>
>> Since I assume this patch was not actually tested to resolve the issue
>> based on the evtest results, I think we should drop this patch. Will
>> mention some details I might have with regards to the behavior you are
>> seeing with Steam/Proton specifically.
>>
>> --
>> Thanks,
>>
>> Rahul Rameshbabu
^ permalink raw reply
* Re: [PATCH 1/1] hid-playstation: Fix button maps for the DualSense Edge controller
From: Roderick Colenbrander @ 2023-11-28 2:36 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Rahul Rameshbabu, roderick.colenbrander, jikos,
benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <7gnt80t5c023J-Vo_c1TvJFYJ3OOpw3iaxcEtXDhFQQLmnE4eKK4VZH_sjd6hzrTtG5GwLwvgC0lD6UAeEAxJwA7N9qGsxmgONPCyDD03IM=@pm.me>
Supertuxkart uses SDL2, which doesn't have the proper evdev (or for
Windows dinput) mappings when not using the native hidapi/hidraw
backends.
Thanks,
Roderick
On Mon, Nov 27, 2023 at 6:19 PM Alexander Koskovich <AKoskovich@pm.me> wrote:
>
> To clarify, I did test this patch locally on Fedora Rawhide and confirm it works with games. It does resolve the issue, and is a workaround.
> It's not just Steam/Proton I'm seeing this issue in, I'm seeing it in native Linux games like SuperTuxKart.
>
>
>
> On Monday, November 27th, 2023 at 9:16 PM, Rahul Rameshbabu <sergeantsagara@protonmail.com> wrote:
>
>
> >
> >
> > On Sun, 26 Nov, 2023 00:15:49 +0000 "Alexander Koskovich" AKoskovich@pm.me wrote:
> >
> > > This brings functionality of the DualSense Edge controller inline
> > > with the stock PS5 controller.
> > >
> > > Signed-off-by: Alexander Koskovich akoskovich@pm.me
> > > ---
> >
> >
> > Will provide a follow-up to the relevant discussion.
> >
> > https://lore.kernel.org/linux-input/P8jVfYBAwiM_8MIgshN0osVVfshfBH2-oZCQuqoqh0Hy76_031zuZvYXWl0edtfTUwDOSNlc5priSRXI3G5dboVh5VPbcdxzAcEF7EvUVgo=@protonmail.com/T/#t
> >
> > Since I assume this patch was not actually tested to resolve the issue
> > based on the evtest results, I think we should drop this patch. Will
> > mention some details I might have with regards to the behavior you are
> > seeing with Steam/Proton specifically.
> >
> > --
> > Thanks,
> >
> > Rahul Rameshbabu
>
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 936e4d49ecbc8c404790504386e1422b599dec39
From: kernel test robot @ 2023-11-28 6:43 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 936e4d49ecbc8c404790504386e1422b599dec39 Input: atkbd - skip ATKBD_CMD_GETID in translated mode
elapsed time: 2807m
configs tested: 310
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc axs103_defconfig gcc
arc defconfig gcc
arc haps_hs_defconfig gcc
arc nsimosci_hs_smp_defconfig gcc
arc randconfig-001-20231126 gcc
arc randconfig-001-20231127 gcc
arc randconfig-002-20231126 gcc
arc randconfig-002-20231127 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm assabet_defconfig gcc
arm clps711x_defconfig gcc
arm defconfig clang
arm h3600_defconfig gcc
arm integrator_defconfig gcc
arm lpc18xx_defconfig gcc
arm mmp2_defconfig clang
arm omap2plus_defconfig gcc
arm pxa910_defconfig gcc
arm qcom_defconfig gcc
arm randconfig-001-20231126 clang
arm randconfig-001-20231127 gcc
arm randconfig-002-20231126 clang
arm randconfig-002-20231127 gcc
arm randconfig-003-20231126 clang
arm randconfig-003-20231127 gcc
arm randconfig-004-20231126 clang
arm randconfig-004-20231127 gcc
arm shmobile_defconfig gcc
arm spear3xx_defconfig clang
arm spear6xx_defconfig gcc
arm sunxi_defconfig gcc
arm tegra_defconfig gcc
arm vf610m4_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20231126 clang
arm64 randconfig-001-20231127 gcc
arm64 randconfig-002-20231126 clang
arm64 randconfig-002-20231127 gcc
arm64 randconfig-003-20231126 clang
arm64 randconfig-003-20231127 gcc
arm64 randconfig-004-20231126 clang
arm64 randconfig-004-20231127 gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20231126 gcc
csky randconfig-001-20231127 gcc
csky randconfig-002-20231126 gcc
csky randconfig-002-20231127 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20231126 clang
hexagon randconfig-002-20231126 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20231126 clang
i386 buildonly-randconfig-002-20231126 clang
i386 buildonly-randconfig-003-20231126 clang
i386 buildonly-randconfig-004-20231126 clang
i386 buildonly-randconfig-005-20231126 clang
i386 buildonly-randconfig-006-20231126 clang
i386 defconfig gcc
i386 randconfig-001-20231126 clang
i386 randconfig-002-20231126 clang
i386 randconfig-003-20231126 clang
i386 randconfig-004-20231126 clang
i386 randconfig-005-20231126 clang
i386 randconfig-006-20231126 clang
i386 randconfig-011-20231126 gcc
i386 randconfig-011-20231127 clang
i386 randconfig-012-20231126 gcc
i386 randconfig-012-20231127 clang
i386 randconfig-013-20231126 gcc
i386 randconfig-013-20231127 clang
i386 randconfig-014-20231126 gcc
i386 randconfig-014-20231127 clang
i386 randconfig-015-20231126 gcc
i386 randconfig-015-20231127 clang
i386 randconfig-016-20231126 gcc
i386 randconfig-016-20231127 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch allyesconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231126 gcc
loongarch randconfig-001-20231127 gcc
loongarch randconfig-002-20231126 gcc
loongarch randconfig-002-20231127 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k bvme6000_defconfig gcc
m68k defconfig gcc
m68k m5249evb_defconfig gcc
m68k m5275evb_defconfig gcc
m68k mac_defconfig gcc
m68k mvme147_defconfig gcc
m68k mvme16x_defconfig gcc
m68k stmark2_defconfig gcc
m68k sun3_defconfig gcc
m68k virt_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
microblaze mmu_defconfig gcc
mips allmodconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips bigsur_defconfig gcc
mips bmips_be_defconfig gcc
mips decstation_64_defconfig gcc
mips decstation_defconfig gcc
mips jazz_defconfig gcc
mips loongson3_defconfig gcc
mips maltaup_xpa_defconfig gcc
mips omega2p_defconfig clang
mips rs90_defconfig clang
mips rt305x_defconfig gcc
mips vocore2_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231126 gcc
nios2 randconfig-001-20231127 gcc
nios2 randconfig-002-20231126 gcc
nios2 randconfig-002-20231127 gcc
openrisc allmodconfig gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc generic-32bit_defconfig gcc
parisc randconfig-001-20231126 gcc
parisc randconfig-001-20231127 gcc
parisc randconfig-002-20231126 gcc
parisc randconfig-002-20231127 gcc
parisc64 defconfig gcc
powerpc adder875_defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc bamboo_defconfig gcc
powerpc cm5200_defconfig gcc
powerpc ep8248e_defconfig gcc
powerpc gamecube_defconfig clang
powerpc holly_defconfig gcc
powerpc klondike_defconfig gcc
powerpc maple_defconfig gcc
powerpc mgcoge_defconfig gcc
powerpc mpc834x_itx_defconfig gcc
powerpc mpc836x_rdk_defconfig clang
powerpc mpc837x_rdb_defconfig gcc
powerpc pcm030_defconfig gcc
powerpc randconfig-001-20231126 clang
powerpc randconfig-001-20231127 gcc
powerpc randconfig-002-20231126 clang
powerpc randconfig-002-20231127 gcc
powerpc randconfig-003-20231126 clang
powerpc randconfig-003-20231127 gcc
powerpc sam440ep_defconfig gcc
powerpc stx_gp3_defconfig gcc
powerpc warp_defconfig gcc
powerpc64 alldefconfig gcc
powerpc64 randconfig-001-20231126 clang
powerpc64 randconfig-001-20231127 gcc
powerpc64 randconfig-002-20231126 clang
powerpc64 randconfig-002-20231127 gcc
powerpc64 randconfig-003-20231126 clang
powerpc64 randconfig-003-20231127 gcc
riscv alldefconfig clang
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv nommu_k210_defconfig gcc
riscv randconfig-001-20231126 clang
riscv randconfig-001-20231127 gcc
riscv randconfig-002-20231126 clang
riscv randconfig-002-20231127 gcc
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20231126 gcc
s390 randconfig-002-20231126 gcc
sh alldefconfig gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh dreamcast_defconfig gcc
sh kfr2r09-romimage_defconfig gcc
sh migor_defconfig gcc
sh polaris_defconfig gcc
sh r7785rp_defconfig gcc
sh randconfig-001-20231126 gcc
sh randconfig-001-20231127 gcc
sh randconfig-002-20231126 gcc
sh randconfig-002-20231127 gcc
sh rsk7269_defconfig gcc
sh rts7751r2d1_defconfig gcc
sh rts7751r2dplus_defconfig gcc
sh sdk7786_defconfig gcc
sh se7206_defconfig gcc
sh se7750_defconfig gcc
sh sh2007_defconfig gcc
sh sh7785lcr_32bit_defconfig gcc
sh shmin_defconfig gcc
sh shx3_defconfig gcc
sh titan_defconfig gcc
sparc allmodconfig gcc
sparc allyesconfig gcc
sparc64 alldefconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20231126 gcc
sparc64 randconfig-001-20231127 gcc
sparc64 randconfig-002-20231126 gcc
sparc64 randconfig-002-20231127 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20231126 clang
um randconfig-001-20231127 gcc
um randconfig-002-20231126 clang
um randconfig-002-20231127 gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20231126 clang
x86_64 buildonly-randconfig-001-20231127 gcc
x86_64 buildonly-randconfig-002-20231126 clang
x86_64 buildonly-randconfig-002-20231127 gcc
x86_64 buildonly-randconfig-003-20231126 clang
x86_64 buildonly-randconfig-003-20231127 gcc
x86_64 buildonly-randconfig-004-20231126 clang
x86_64 buildonly-randconfig-004-20231127 gcc
x86_64 buildonly-randconfig-005-20231126 clang
x86_64 buildonly-randconfig-005-20231127 gcc
x86_64 buildonly-randconfig-006-20231126 clang
x86_64 buildonly-randconfig-006-20231127 gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-001-20231126 gcc
x86_64 randconfig-002-20231126 gcc
x86_64 randconfig-003-20231126 gcc
x86_64 randconfig-004-20231126 gcc
x86_64 randconfig-005-20231126 gcc
x86_64 randconfig-006-20231126 gcc
x86_64 randconfig-011-20231126 clang
x86_64 randconfig-011-20231127 gcc
x86_64 randconfig-012-20231126 clang
x86_64 randconfig-012-20231127 gcc
x86_64 randconfig-013-20231126 clang
x86_64 randconfig-013-20231127 gcc
x86_64 randconfig-014-20231126 clang
x86_64 randconfig-014-20231127 gcc
x86_64 randconfig-015-20231126 clang
x86_64 randconfig-015-20231127 gcc
x86_64 randconfig-016-20231126 clang
x86_64 randconfig-016-20231127 gcc
x86_64 randconfig-071-20231126 clang
x86_64 randconfig-071-20231127 gcc
x86_64 randconfig-072-20231126 clang
x86_64 randconfig-072-20231127 gcc
x86_64 randconfig-073-20231126 clang
x86_64 randconfig-073-20231127 gcc
x86_64 randconfig-074-20231126 clang
x86_64 randconfig-074-20231127 gcc
x86_64 randconfig-075-20231126 clang
x86_64 randconfig-075-20231127 gcc
x86_64 randconfig-076-20231126 clang
x86_64 randconfig-076-20231127 gcc
x86_64 rhel-8.3-bpf gcc
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa alldefconfig gcc
xtensa allnoconfig gcc
xtensa allyesconfig gcc
xtensa generic_kc705_defconfig gcc
xtensa iss_defconfig gcc
xtensa nommu_kc705_defconfig gcc
xtensa randconfig-001-20231126 gcc
xtensa randconfig-001-20231127 gcc
xtensa randconfig-002-20231126 gcc
xtensa randconfig-002-20231127 gcc
xtensa smp_lx200_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [RFC PATCH v3 0/5] platform/chrome: Introduce DT hardware prober
From: Chen-Yu Tsai @ 2023-11-28 8:42 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih
Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
Hi everyone,
This is v3 of my "of: Introduce hardware prober driver" [1] series.
v2 continued Doug's "of: device: Support 2nd sources of probeable but
undiscoverable devices" [2] series, but follows the scheme suggested by Rob, marking all second
source component device nodes as "fail-needs-probe", and having a
hardware prober driver enable the one of them. I tried to include
everyone from the original Cc: list. Please let me know if you would
like to be dropped from future submissions.
Changes since v2:
- Added of_changeset_update_prop_string()
- Moved generic I2C code to the I2C core
- Moved remaining platform specific code to platform/chrome/
- Switched to of_node_is_available() to check if node is enabled.
- Switched to OF changeset API to update status property
- I2C probe helper function now accepts "struct device *dev" instead to
reduce line length and dereferences
- Moved "ret = 0" to just before for_each_child_of_node(i2c_node, node)
- Depend on rather than select CONFIG_I2C
- Copied machine check to driver init function
- Explicitly mentioned "device tree" or OF in driver name, description
and Kconfig symbol
- Dropped filename from inside the file
- Made loop variable size_t (instead of unsigned int as Andy asked)
- Switched to PLATFORM_DEVID_NONE instead of raw -1
- Switched to standard goto error path pattern in hw_prober_driver_init()
- Dropped device class from status property
Patches removed from v3 and saved for later:
- of: base: Add of_device_is_fail
- of: hw_prober: Support Chromebook SKU ID based component selection
- dt-bindings: arm: mediatek: Remove SKU specific compatibles for Google Krane
- arm64: dts: mediatek: mt8183-kukui: Merge Krane device trees
For the I2C component (touchscreens and trackpads) case from the
original series, the hardware prober driver finds the particular
class of device in the device tree, gets its parent I2C adapter,
and tries to initiate a simple I2C read for each device under that
I2C bus. When it finds one that responds, it considers that one
present, marks it as "okay", and returns, letting the driver core
actually probe the device.
This works fine in most cases since these components are connected
via ribbon cable and always have the same resources. The driver as
implemented currently doesn't deal with regulators or GPIO pins,
since in the existing device trees they are either always on for
regulators, or have GPIO hogs or pinmux and pinconfig directly
tied to the pin controller.
The other case, selecting a display panel to use based on the SKU ID
from the firmware, hit a bit of an issue with fixing the OF graph.
I've left it out of v3 for now.
Patch 1 adds of_changeset_update_prop_string(), as requested by Rob.
Patch 2 implements probing the I2C bus for presence of components as
a helper function in the I2C core.
Patch 3 adds a ChromeOS specific DT hardware prober. This initial
version targets the Hana Chromebooks, probing its I2C trackpads and
touchscreens.
Patch 4 modifies the Hana device tree and marks the touchscreens
and trackpads as "fail-needs-probe", ready for the driver to probe.
Patch 5 adds a missing touchscreen variant to Hana. This patch
conflicts with another one in flight [3] that is almost the same.
Assuming this is acceptable to folks, because there are compile
time dependencies, I think it would be easier for the code bits
(patches 1 through 4) to go through either the OF tree or I2C
tree. Patches 5 and 6 can go through the soc tree via the mediatek
tree.
Thanks
ChenYu
Background as given in Doug's cover letter:
Support for multiple "equivalent" sources for components (also known
as second sourcing components) is a standard practice that helps keep
cost down and also makes sure that if one component is unavailable due
to a shortage that we don't need to stop production for the whole
product.
Some components are very easy to second source. eMMC, for instance, is
fully discoverable and probable so you can stuff a wide variety of
similar eMMC chips on your board and things will work without a hitch.
Some components are more difficult to second source, specifically
because it's difficult for software to probe what component is present
on any given board. In cases like this software is provided
supplementary information to help it, like a GPIO strap or a SKU ID
programmed into an EEPROM. This helpful information can allow the
bootloader to select a different device tree. The various different
"SKUs" of different Chromebooks are examples of this.
Some components are somewhere in between. These in-between components
are the subject of this patch. Specifically, these components are
easily "probeable" but not easily "discoverable".
A good example of a probeable but undiscoverable device is an
i2c-connected touchscreen or trackpad. Two separate components may be
electrically compatible with each other and may have compatible power
sequencing requirements but may require different software. If
software is told about the different possible components (because it
can't discover them), it can safely probe them to figure out which
ones are present.
On systems using device tree, if we want to tell the OS about all of
the different components we need to list them all in the device
tree. This leads to a problem. The multiple sources for components
likely use the same resources (GPIOs, interrupts, regulators). If the
OS tries to probe all of these components at the same time then it
will detect a resource conflict and that's a fatal error.
The fact that Linux can't handle these probeable but undiscoverable
devices well has had a few consequences:
1. In some cases, we've abandoned the idea of second sourcing
components for a given board, which increases cost / generates
manufacturing headaches.
2. In some cases, we've been forced to add some sort of strapping /
EEPROM to indicate which component is present. This adds difficulty
to manufacturing / refurb processes.
3. In some cases, we've managed to make things work by the skin of our
teeth through slightly hacky solutions. Specifically, if we remove
the "pinctrl" entry from the various options then it won't
conflict. Regulators inherently can have more than one consumer, so
as long as there are no GPIOs involved in power sequencing and
probing devices then things can work. This is how
"sc8280xp-lenovo-thinkpad-x13s" works and also how
"mt8173-elm-hana" works.
End of background from Doug's cover letter.
[1] https://lore.kernel.org/linux-arm-kernel/20231109100606.1245545-1-wenst@chromium.org/
[2] https://lore.kernel.org/all/20230921102420.RFC.1.I9dddd99ccdca175e3ceb1b9fa1827df0928c5101@changeid/
[3] https://lore.kernel.org/linux-mediatek/20231115043511.2670477-1-treapking@chromium.org/
Chen-Yu Tsai (5):
of: dynamic: Add of_changeset_update_prop_string
i2c: of: Introduce component probe function
platform/chrome: Introduce device tree hardware prober
arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads
as fail
arm64: dts: mediatek: mt8173-elm-hana: Add G2touch G7500 touchscreen
.../boot/dts/mediatek/mt8173-elm-hana.dtsi | 20 ++++
drivers/i2c/i2c-core-of.c | 110 ++++++++++++++++++
drivers/of/dynamic.c | 47 ++++++++
drivers/platform/chrome/Kconfig | 11 ++
drivers/platform/chrome/Makefile | 1 +
.../platform/chrome/chromeos_of_hw_prober.c | 89 ++++++++++++++
include/linux/i2c.h | 4 +
include/linux/of.h | 3 +
8 files changed, 285 insertions(+)
create mode 100644 drivers/platform/chrome/chromeos_of_hw_prober.c
--
2.43.0.rc1.413.gea7ed67945-goog
^ permalink raw reply
* [RFC PATCH v3 1/5] of: dynamic: Add of_changeset_update_prop_string
From: Chen-Yu Tsai @ 2023-11-28 8:42 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih
Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
In-Reply-To: <20231128084236.157152-1-wenst@chromium.org>
Add a helper function to add string property updates to an OF changeset.
This is similar to of_changeset_add_prop_string(), but instead of adding
the property (and failing if it exists), it will update the property.
This shall be used later in the DT hardware prober.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
New patch added in v3.
---
drivers/of/dynamic.c | 47 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 3 +++
2 files changed, 50 insertions(+)
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index f63250c650ca..d22aad938667 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -1039,3 +1039,50 @@ int of_changeset_add_prop_u32_array(struct of_changeset *ocs,
return ret;
}
EXPORT_SYMBOL_GPL(of_changeset_add_prop_u32_array);
+
+static int of_changeset_update_prop_helper(struct of_changeset *ocs,
+ struct device_node *np,
+ const struct property *pp)
+{
+ struct property *new_pp;
+ int ret;
+
+ new_pp = __of_prop_dup(pp, GFP_KERNEL);
+ if (!new_pp)
+ return -ENOMEM;
+
+ ret = of_changeset_update_property(ocs, np, new_pp);
+ if (ret) {
+ kfree(new_pp->name);
+ kfree(new_pp->value);
+ kfree(new_pp);
+ }
+
+ return ret;
+}
+
+/**
+ * of_changeset_update_prop_string - Add a string property update to a changeset
+ *
+ * @ocs: changeset pointer
+ * @np: device node pointer
+ * @prop_name: name of the property to be updated
+ * @str: pointer to null terminated string
+ *
+ * Create a string property to be updated and add it to a changeset.
+ *
+ * Return: 0 on success, a negative error value in case of an error.
+ */
+int of_changeset_update_prop_string(struct of_changeset *ocs,
+ struct device_node *np,
+ const char *prop_name, const char *str)
+{
+ struct property prop;
+
+ prop.name = (char *)prop_name;
+ prop.length = strlen(str) + 1;
+ prop.value = (void *)str;
+
+ return of_changeset_update_prop_helper(ocs, np, &prop);
+}
+EXPORT_SYMBOL_GPL(of_changeset_update_prop_string);
diff --git a/include/linux/of.h b/include/linux/of.h
index 6a9ddf20e79a..c69bc7da380e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1601,6 +1601,9 @@ static inline int of_changeset_add_prop_u32(struct of_changeset *ocs,
{
return of_changeset_add_prop_u32_array(ocs, np, prop_name, &val, 1);
}
+int of_changeset_update_prop_string(struct of_changeset *ocs,
+ struct device_node *np,
+ const char *prop_name, const char *str);
#else /* CONFIG_OF_DYNAMIC */
static inline int of_reconfig_notifier_register(struct notifier_block *nb)
--
2.43.0.rc1.413.gea7ed67945-goog
^ permalink raw reply related
* [RFC PATCH v3 2/5] i2c: of: Introduce component probe function
From: Chen-Yu Tsai @ 2023-11-28 8:42 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih
Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
In-Reply-To: <20231128084236.157152-1-wenst@chromium.org>
Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.
This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.
Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component probe. function For a
given class of devices on the same I2C bus, it will go through all of
them, doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.
This requires some minor modifications in the existing device tree. The
status for all the device nodes for the component options must be set
to "failed-needs-probe". This makes it clear that some mechanism is
needed to enable one of them, and also prevents the prober and device
drivers running at the same time.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- New patch split out from "of: Introduce hardware prober driver"
- Addressed Rob's comments
- Move i2c prober to i2c subsystem
- Use of_node_is_available() to check if node is enabled.
- Use OF changeset API to update status property
- Addressed Andy's comments
- Probe function now accepts "struct device *dev" instead to reduce
line length and dereferences
- Move "ret = 0" to just before for_each_child_of_node(i2c_node, node)
---
drivers/i2c/i2c-core-of.c | 110 ++++++++++++++++++++++++++++++++++++++
include/linux/i2c.h | 4 ++
2 files changed, 114 insertions(+)
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index a6c407d36800..3a0b4986c585 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -217,4 +217,114 @@ static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
struct notifier_block i2c_of_notifier = {
.notifier_call = of_i2c_notify,
};
+
+/*
+ * Some devices, such as Google Hana Chromebooks, are produced by multiple
+ * vendors each using their preferred components. Such components are all
+ * in the device tree. Instead of having all of them enabled and having each
+ * driver separately try and probe its device while fighting over shared
+ * resources, they can be marked as "fail-needs-probe" and have a prober
+ * figure out which one is actually used beforehand.
+ *
+ * This prober assumes such drop-in parts are on the same I2C bus, have
+ * non-conflicting addresses, and can be directly probed by seeing which
+ * address responds.
+ *
+ * TODO:
+ * - Support handling common regulators and GPIOs.
+ * - Support I2C muxes
+ */
+
+/**
+ * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
+ * @dev: &struct device of the caller, only used for dev_* printk messages
+ * @type: a string to match the device node name prefix to probe for
+ *
+ * Probe for possible I2C components of the same "type" on the same I2C bus
+ * that have their status marked as "fail".
+ */
+int i2c_of_probe_component(struct device *dev, const char *type)
+{
+ struct device_node *node, *i2c_node;
+ struct i2c_adapter *i2c;
+ struct of_changeset *ocs = NULL;
+ int ret;
+
+ node = of_find_node_by_name(NULL, type);
+ if (!node)
+ return dev_err_probe(dev, -ENODEV, "Could not find %s device node\n", type);
+
+ i2c_node = of_get_next_parent(node);
+ if (!of_node_name_eq(i2c_node, "i2c")) {
+ of_node_put(i2c_node);
+ return dev_err_probe(dev, -EINVAL, "%s device isn't on I2C bus\n", type);
+ }
+
+ for_each_child_of_node(i2c_node, node) {
+ if (!of_node_name_prefix(node, type))
+ continue;
+ if (of_device_is_available(node)) {
+ /*
+ * Device tree has component already enabled. Either the
+ * device tree isn't supported or we already probed once.
+ */
+ of_node_put(node);
+ of_node_put(i2c_node);
+ return 0;
+ }
+ }
+
+ i2c = of_get_i2c_adapter_by_node(i2c_node);
+ if (!i2c) {
+ of_node_put(i2c_node);
+ return dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
+ }
+
+ ret = 0;
+ for_each_child_of_node(i2c_node, node) {
+ union i2c_smbus_data data;
+ u32 addr;
+
+ if (!of_node_name_prefix(node, type))
+ continue;
+ if (of_property_read_u32(node, "reg", &addr))
+ continue;
+ if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
+ continue;
+
+ dev_info(dev, "Enabling %pOF\n", node);
+
+ ocs = kzalloc(sizeof(*ocs), GFP_KERNEL);
+ if (!ocs) {
+ ret = -ENOMEM;
+ goto err_put_node;
+ }
+
+ /* Found a device that is responding */
+ of_changeset_init(ocs);
+ ret = of_changeset_update_prop_string(ocs, node, "status", "okay");
+ if (ret)
+ goto err_free_ocs;
+ ret = of_changeset_apply(ocs);
+ if (ret)
+ goto err_destroy_ocs;
+
+ of_node_put(node);
+ break;
+ }
+
+ i2c_put_adapter(i2c);
+ of_node_put(i2c_node);
+
+ return 0;
+
+err_destroy_ocs:
+ of_changeset_destroy(ocs);
+err_free_ocs:
+ kfree(ocs);
+err_put_node:
+ of_node_put(node);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i2c_of_probe_component);
#endif /* CONFIG_OF_DYNAMIC */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 0dae9db27538..75fbbd5a4b15 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -997,6 +997,10 @@ const struct of_device_id
int of_i2c_get_board_info(struct device *dev, struct device_node *node,
struct i2c_board_info *info);
+#if IS_ENABLED(CONFIG_OF_DYNAMIC)
+int i2c_of_probe_component(struct device *dev, const char *type);
+#endif
+
#else
static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
--
2.43.0.rc1.413.gea7ed67945-goog
^ permalink raw reply related
* [RFC PATCH v3 3/5] platform/chrome: Introduce device tree hardware prober
From: Chen-Yu Tsai @ 2023-11-28 8:42 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih
Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
In-Reply-To: <20231128084236.157152-1-wenst@chromium.org>
Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.
This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.
Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component prober. For any given
class of devices on the same I2C bus, it will go through all of them,
doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.
This requires some minor modifications in the existing device tree.
The status for all the device nodes for the component options must be
set to "failed-needs-probe". This makes it clear that some mechanism is
needed to enable one of them, and also prevents the prober and device
drivers running at the same time.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- Addressed Rob's comments
- Move remaining driver code to drivers/platform/chrome/
- Depend on rather than select CONFIG_I2C
- Copy machine check to driver init function
- Addressed Andy's comments
- Explicitly mention "device tree" or OF in driver name, description
and Kconfig symbol
- Drop filename from inside the file
- Switch to passing "struct device *" to shorten lines
- Move "ret = 0" to just before for_each_child_of_node(i2c_node, node)
- Make loop variable size_t (instead of unsigned int as Andy asked)
- Use PLATFORM_DEVID_NONE instead of raw -1
- Use standard goto error path pattern in hw_prober_driver_init()
- Changes since v1:
- New patch
---
drivers/platform/chrome/Kconfig | 11 +++
drivers/platform/chrome/Makefile | 1 +
.../platform/chrome/chromeos_of_hw_prober.c | 89 +++++++++++++++++++
3 files changed, 101 insertions(+)
create mode 100644 drivers/platform/chrome/chromeos_of_hw_prober.c
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index 7a83346bfa53..aa161f2f09e3 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -61,6 +61,17 @@ config CHROMEOS_TBMC
To compile this driver as a module, choose M here: the
module will be called chromeos_tbmc.
+config CHROMEOS_OF_HW_PROBER
+ bool "ChromeOS Device Tree Hardware Prober"
+ depends on OF
+ depends on I2C
+ select OF_DYNAMIC
+ default OF
+ help
+ This option enables the device tree hardware prober for ChromeOS
+ devices. The driver will probe the correct component variant in
+ devices that have multiple drop-in options for one component.
+
config CROS_EC
tristate "ChromeOS Embedded Controller"
select CROS_EC_PROTO
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 2dcc6ccc2302..21a9d5047053 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CHROMEOS_ACPI) += chromeos_acpi.o
obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN) += chromeos_privacy_screen.o
obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
+obj-$(CONFIG_CHROMEOS_OF_HW_PROBER) += chromeos_of_hw_prober.o
obj-$(CONFIG_CHROMEOS_TBMC) += chromeos_tbmc.o
obj-$(CONFIG_CROS_EC) += cros_ec.o
obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
diff --git a/drivers/platform/chrome/chromeos_of_hw_prober.c b/drivers/platform/chrome/chromeos_of_hw_prober.c
new file mode 100644
index 000000000000..13aaad6382aa
--- /dev/null
+++ b/drivers/platform/chrome/chromeos_of_hw_prober.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ChromeOS Device Tree Hardware Prober
+ *
+ * Copyright (c) 2023 Google LLC
+ */
+
+#include <linux/array_size.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define DRV_NAME "chromeos_of_hw_prober"
+
+/**
+ * struct hw_prober_entry - Holds an entry for the hardware prober
+ *
+ * @compatible: compatible string to match against the machine
+ * @prober: prober function to call when machine matches
+ * @data: extra data for the prober function
+ */
+struct hw_prober_entry {
+ const char *compatible;
+ int (*prober)(struct device *dev, const void *data);
+ const void *data;
+};
+
+static int chromeos_i2c_component_prober(struct device *dev, const void *data)
+{
+ const char *type = data;
+
+ return i2c_of_probe_component(dev, type);
+}
+
+static const struct hw_prober_entry hw_prober_platforms[] = {
+ { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = "touchscreen" },
+ { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = "trackpad" },
+};
+
+static int chromeos_of_hw_prober_probe(struct platform_device *pdev)
+{
+ for (size_t i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
+ if (of_machine_is_compatible(hw_prober_platforms[i].compatible)) {
+ int ret;
+
+ ret = hw_prober_platforms[i].prober(&pdev->dev,
+ hw_prober_platforms[i].data);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct platform_driver chromeos_of_hw_prober_driver = {
+ .probe = chromeos_of_hw_prober_probe,
+ .driver = {
+ .name = DRV_NAME,
+ },
+};
+
+static int __init chromeos_of_hw_prober_driver_init(void)
+{
+ struct platform_device *pdev;
+ size_t i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
+ if (of_machine_is_compatible(hw_prober_platforms[i].compatible))
+ break;
+ if (i == ARRAY_SIZE(hw_prober_platforms))
+ return 0;
+
+ ret = platform_driver_register(&chromeos_of_hw_prober_driver);
+ if (ret)
+ return ret;
+
+ pdev = platform_device_register_simple(DRV_NAME, PLATFORM_DEVID_NONE, NULL, 0);
+ if (IS_ERR(pdev))
+ goto err;
+
+ return 0;
+
+err:
+ platform_driver_unregister(&chromeos_of_hw_prober_driver);
+
+ return PTR_ERR(pdev);
+}
+device_initcall(chromeos_of_hw_prober_driver_init);
--
2.43.0.rc1.413.gea7ed67945-goog
^ permalink raw reply related
* [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail
From: Chen-Yu Tsai @ 2023-11-28 8:42 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih
Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
In-Reply-To: <20231128084236.157152-1-wenst@chromium.org>
Instead of having them all available, mark them all as "fail-needs-probe"
and have the implementation try to probe which one is present.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- Drop class from status
---
arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
index bdcd35cecad9..1d68bc6834e4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
@@ -15,6 +15,7 @@ touchscreen2: touchscreen@34 {
reg = <0x34>;
interrupt-parent = <&pio>;
interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
+ status = "fail-needs-probe";
};
/*
@@ -28,6 +29,7 @@ touchscreen3: touchscreen@20 {
hid-descr-addr = <0x0020>;
interrupt-parent = <&pio>;
interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
+ status = "fail-needs-probe";
};
};
@@ -44,6 +46,7 @@ trackpad2: trackpad@2c {
reg = <0x2c>;
hid-descr-addr = <0x0020>;
wakeup-source;
+ status = "fail-needs-probe";
};
};
@@ -68,3 +71,11 @@ pins_wp {
};
};
};
+
+&touchscreen {
+ status = "fail-needs-probe";
+};
+
+&trackpad {
+ status = "fail-needs-probe";
+};
--
2.43.0.rc1.413.gea7ed67945-goog
^ permalink raw reply related
* [RFC PATCH v3 5/5] arm64: dts: mediatek: mt8173-elm-hana: Add G2touch G7500 touchscreen
From: Chen-Yu Tsai @ 2023-11-28 8:42 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih
Cc: Chen-Yu Tsai, chrome-platform, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold,
Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
In-Reply-To: <20231128084236.157152-1-wenst@chromium.org>
This introduces yet another second-source touchscreen found on Hana.
This is a G2touch G7500 touchscreen, which is compatible with HID over
I2C.
Add a device node for it. In keeping with the new scheme for second
source components, mark it as "failed-needs-probe".
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v2:
- Drop class from status
---
arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
index 1d68bc6834e4..216d8b43be05 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
@@ -31,6 +31,15 @@ touchscreen3: touchscreen@20 {
interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
status = "fail-needs-probe";
};
+
+ touchscreen4: touchscreen@40 {
+ compatible = "hid-over-i2c";
+ reg = <0x40>;
+ hid-descr-addr = <0x0001>;
+ interrupt-parent = <&pio>;
+ interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
+ status = "fail-needs-probe";
+ };
};
&i2c4 {
--
2.43.0.rc1.413.gea7ed67945-goog
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: input: touchscreen: goodix: clarify irq-gpios misleading text
From: Luca Ceresoli @ 2023-11-28 9:21 UTC (permalink / raw)
To: Rob Herring
Cc: linux-input, linux-kernel, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Thomas Petazzoni, Jeff LaBundy, devicetree,
Conor Dooley
In-Reply-To: <169565910910.1468857.379234431707593994.robh@kernel.org>
Hello Rob,
On Mon, 25 Sep 2023 11:25:09 -0500
Rob Herring <robh@kernel.org> wrote:
> Acked-by: Rob Herring <robh@kernel.org>
I can't find this patch in your for-next, is there any blocker I should
handle?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: input: touchscreen: goodix: clarify irq-gpios misleading text
From: Krzysztof Kozlowski @ 2023-11-28 9:22 UTC (permalink / raw)
To: Luca Ceresoli, Rob Herring
Cc: linux-input, linux-kernel, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Thomas Petazzoni, Jeff LaBundy, devicetree,
Conor Dooley
In-Reply-To: <20231128102105.4d901b3a@booty>
On 28/11/2023 10:21, Luca Ceresoli wrote:
> Hello Rob,
>
> On Mon, 25 Sep 2023 11:25:09 -0500
> Rob Herring <robh@kernel.org> wrote:
>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> I can't find this patch in your for-next, is there any blocker I should
> handle?
This was an Ack, not applied from Rob. Intention is that bindings go via
subsystem maintainer (here: Dmitry).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: input: touchscreen: goodix: clarify irq-gpios misleading text
From: Luca Ceresoli @ 2023-11-28 11:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, linux-input, linux-kernel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Thomas Petazzoni, Jeff LaBundy,
devicetree, Conor Dooley
In-Reply-To: <729e43fb-bc01-4d68-ba1c-5874b5428b63@linaro.org>
Hello Krzysztof,
On Tue, 28 Nov 2023 10:22:27 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> On 28/11/2023 10:21, Luca Ceresoli wrote:
> > Hello Rob,
> >
> > On Mon, 25 Sep 2023 11:25:09 -0500
> > Rob Herring <robh@kernel.org> wrote:
> >
> >> Acked-by: Rob Herring <robh@kernel.org>
> >
> > I can't find this patch in your for-next, is there any blocker I should
> > handle?
>
> This was an Ack, not applied from Rob. Intention is that bindings go via
> subsystem maintainer (here: Dmitry).
Thanks for the clarification!
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH v3 2/5] i2c: of: Introduce component probe function
From: Andy Shevchenko @ 2023-11-28 16:22 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih, chrome-platform, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, Douglas Anderson,
Johan Hovold, Hsin-Yi Wang, Dmitry Torokhov, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
In-Reply-To: <20231128084236.157152-3-wenst@chromium.org>
On Tue, Nov 28, 2023 at 04:42:31PM +0800, Chen-Yu Tsai wrote:
> Some devices are designed and manufactured with some components having
> multiple drop-in replacement options. These components are often
> connected to the mainboard via ribbon cables, having the same signals
> and pin assignments across all options. These may include the display
> panel and touchscreen on laptops and tablets, and the trackpad on
> laptops. Sometimes which component option is used in a particular device
> can be detected by some firmware provided identifier, other times that
> information is not available, and the kernel has to try to probe each
> device.
>
> This change attempts to make the "probe each device" case cleaner. The
> current approach is to have all options added and enabled in the device
> tree. The kernel would then bind each device and run each driver's probe
> function. This works, but has been broken before due to the introduction
> of asynchronous probing, causing multiple instances requesting "shared"
> resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> time, with only one instance succeeding. Work arounds for these include
> moving the pinmux to the parent I2C controller, using GPIO hogs or
> pinmux settings to keep the GPIO pins in some fixed configuration, and
> requesting the interrupt line very late. Such configurations can be seen
> on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> Lenovo Thinkpad 13S.
>
> Instead of this delicate dance between drivers and device tree quirks,
> this change introduces a simple I2C component probe. function For a
> given class of devices on the same I2C bus, it will go through all of
> them, doing a simple I2C read transfer and see which one of them responds.
> It will then enable the device that responds.
>
> This requires some minor modifications in the existing device tree. The
> status for all the device nodes for the component options must be set
> to "failed-needs-probe". This makes it clear that some mechanism is
> needed to enable one of them, and also prevents the prober and device
> drivers running at the same time.
...
> +/**
> + * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
> + * @dev: &struct device of the caller, only used for dev_* printk messages
> + * @type: a string to match the device node name prefix to probe for
> + *
> + * Probe for possible I2C components of the same "type" on the same I2C bus
> + * that have their status marked as "fail".
Definitely you haven't run kernel-doc validation.
> + */
...
> + return dev_err_probe(dev, -ENODEV, "Could not find %s device node\n", type);
I haven't noticed clear statement in the description that this API is only for
the ->probe() stages.
...
> + if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
> + continue;
This will require the device to be powered on. Are you sure it will be always
the case?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC PATCH v3 3/5] platform/chrome: Introduce device tree hardware prober
From: Andy Shevchenko @ 2023-11-28 16:25 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Wolfram Sang,
Benson Leung, Tzung-Bi Shih, chrome-platform, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, Douglas Anderson,
Johan Hovold, Hsin-Yi Wang, Dmitry Torokhov, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, rafael, tglx, Jeff LaBundy, linux-input, linux-i2c
In-Reply-To: <20231128084236.157152-4-wenst@chromium.org>
On Tue, Nov 28, 2023 at 04:42:32PM +0800, Chen-Yu Tsai wrote:
> Some devices are designed and manufactured with some components having
> multiple drop-in replacement options. These components are often
> connected to the mainboard via ribbon cables, having the same signals
> and pin assignments across all options. These may include the display
> panel and touchscreen on laptops and tablets, and the trackpad on
> laptops. Sometimes which component option is used in a particular device
> can be detected by some firmware provided identifier, other times that
> information is not available, and the kernel has to try to probe each
> device.
>
> This change attempts to make the "probe each device" case cleaner. The
> current approach is to have all options added and enabled in the device
> tree. The kernel would then bind each device and run each driver's probe
> function. This works, but has been broken before due to the introduction
> of asynchronous probing, causing multiple instances requesting "shared"
> resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> time, with only one instance succeeding. Work arounds for these include
> moving the pinmux to the parent I2C controller, using GPIO hogs or
> pinmux settings to keep the GPIO pins in some fixed configuration, and
> requesting the interrupt line very late. Such configurations can be seen
> on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> Lenovo Thinkpad 13S.
>
> Instead of this delicate dance between drivers and device tree quirks,
> this change introduces a simple I2C component prober. For any given
> class of devices on the same I2C bus, it will go through all of them,
> doing a simple I2C read transfer and see which one of them responds.
> It will then enable the device that responds.
>
> This requires some minor modifications in the existing device tree.
> The status for all the device nodes for the component options must be
> set to "failed-needs-probe". This makes it clear that some mechanism is
> needed to enable one of them, and also prevents the prober and device
> drivers running at the same time.
...
> +#include <linux/array_size.h>
> +#include <linux/i2c.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
init.h for init calls.
> +static int chromeos_of_hw_prober_probe(struct platform_device *pdev)
> +{
> + for (size_t i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
> + if (of_machine_is_compatible(hw_prober_platforms[i].compatible)) {
> + int ret;
Perhaps
if (!of_machine_is_compatible(hw_prober_platforms[i].compatible))
continue;
?
> + ret = hw_prober_platforms[i].prober(&pdev->dev,
> + hw_prober_platforms[i].data);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH AUTOSEL 6.6 24/40] HID: mcp2221: Set driver data before I2C adapter add
From: Sasha Levin @ 2023-11-28 21:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hamish Martin, Jiri Kosina, Sasha Levin, gupt21, jikos,
benjamin.tissoires, linux-i2c, linux-input
In-Reply-To: <20231128210615.875085-1-sashal@kernel.org>
From: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
[ Upstream commit f2d4a5834638bbc967371b9168c0b481519f7c5e ]
The process of adding an I2C adapter can invoke I2C accesses on that new
adapter (see i2c_detect()).
Ensure we have set the adapter's driver data to avoid null pointer
dereferences in the xfer functions during the adapter add.
This has been noted in the past and the same fix proposed but not
completed. See:
https://lore.kernel.org/lkml/ef597e73-ed71-168e-52af-0d19b03734ac@vigem.de/
Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-mcp2221.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index 72883e0ce7575..b95f31cf0fa21 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -1157,12 +1157,12 @@ static int mcp2221_probe(struct hid_device *hdev,
snprintf(mcp->adapter.name, sizeof(mcp->adapter.name),
"MCP2221 usb-i2c bridge");
+ i2c_set_adapdata(&mcp->adapter, mcp);
ret = devm_i2c_add_adapter(&hdev->dev, &mcp->adapter);
if (ret) {
hid_err(hdev, "can't add usb-i2c adapter: %d\n", ret);
return ret;
}
- i2c_set_adapdata(&mcp->adapter, mcp);
#if IS_REACHABLE(CONFIG_GPIOLIB)
/* Setup GPIO chip */
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 25/40] HID: mcp2221: Allow IO to start during probe
From: Sasha Levin @ 2023-11-28 21:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hamish Martin, Jiri Kosina, Sasha Levin, gupt21, jikos,
benjamin.tissoires, linux-i2c, linux-input
In-Reply-To: <20231128210615.875085-1-sashal@kernel.org>
From: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
[ Upstream commit 73ce9f1f2741a38f5d27393e627702ae2c46e6f2 ]
During the probe we add an I2C adapter and as soon as we add that adapter
it may be used for a transfer (e.g via the code in i2cdetect()).
Those transfers are not able to complete and time out. This is because the
HID raw_event callback (mcp2221_raw_event) will not be invoked until the
HID device's 'driver_input_lock' is marked up at the completion of the
probe in hid_device_probe(). This starves the driver of the responses it
is waiting for.
In order to allow the I2C transfers to complete while we are still in the
probe, start the IO once we have completed init of the HID device.
This issue seems to have been seen before and a patch was submitted but
it seems it was never accepted. See:
https://lore.kernel.org/all/20221103222714.21566-3-Enrik.Berkhan@inka.de/
Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-mcp2221.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index b95f31cf0fa21..aef0785c91cc2 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -1142,6 +1142,8 @@ static int mcp2221_probe(struct hid_device *hdev,
if (ret)
return ret;
+ hid_device_io_start(hdev);
+
/* Set I2C bus clock diviser */
if (i2c_clk_freq > 400)
i2c_clk_freq = 400;
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 26/40] HID: apple: add Jamesdonkey and A3R to non-apple keyboards list
From: Sasha Levin @ 2023-11-28 21:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Yihong Cao, Jiri Kosina, Sasha Levin, jikos, benjamin.tissoires,
linux-input
In-Reply-To: <20231128210615.875085-1-sashal@kernel.org>
From: Yihong Cao <caoyihong4@outlook.com>
[ Upstream commit 113f736655e4f20633e107d731dd5bd097d5938c ]
Jamesdonkey A3R keyboard is identified as "Jamesdonkey A3R" in wired
mode, "A3R-U" in wireless mode and "A3R" in bluetooth mode. Adding them
to non-apple keyboards fixes function key.
Signed-off-by: Yihong Cao <caoyihong4@outlook.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-apple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 3ca45975c686e..d9e9829b22001 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -345,6 +345,8 @@ static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
{ "AONE" },
{ "GANSS" },
{ "Hailuck" },
+ { "Jamesdonkey" },
+ { "A3R" },
};
static bool apple_is_non_apple_keyboard(struct hid_device *hdev)
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 27/40] HID: glorious: fix Glorious Model I HID report
From: Sasha Levin @ 2023-11-28 21:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brett Raye, Jiri Kosina, Sasha Levin, jikos, benjamin.tissoires,
linux-input
In-Reply-To: <20231128210615.875085-1-sashal@kernel.org>
From: Brett Raye <braye@fastmail.com>
[ Upstream commit a5e913c25b6b2b6ae02acef6d9400645ac03dfdf ]
The Glorious Model I mouse has a buggy HID report descriptor for its
keyboard endpoint (used for programmable buttons). For report ID 2, there
is a mismatch between Logical Minimum and Usage Minimum in the array that
reports keycodes.
The offending portion of the descriptor: (from hid-decode)
0x95, 0x05, // Report Count (5) 30
0x75, 0x08, // Report Size (8) 32
0x15, 0x00, // Logical Minimum (0) 34
0x25, 0x65, // Logical Maximum (101) 36
0x05, 0x07, // Usage Page (Keyboard) 38
0x19, 0x01, // Usage Minimum (1) 40
0x29, 0x65, // Usage Maximum (101) 42
0x81, 0x00, // Input (Data,Arr,Abs) 44
This bug shifts all programmed keycodes up by 1. Importantly, this causes
"empty" array indexes of 0x00 to be interpreted as 0x01, ErrorRollOver.
The presence of ErrorRollOver causes the system to ignore all keypresses
from the endpoint and breaks the ability to use the programmable buttons.
Setting byte 41 to 0x00 fixes this, and causes keycodes to be interpreted
correctly.
Also, USB_VENDOR_ID_GLORIOUS is changed to USB_VENDOR_ID_SINOWEALTH,
and a new ID for Laview Technology is added. Glorious seems to be
white-labeling controller boards or mice from these vendors. There isn't a
single canonical vendor ID for Glorious products.
Signed-off-by: Brett Raye <braye@fastmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-glorious.c | 16 ++++++++++++++--
drivers/hid/hid-ids.h | 11 +++++++----
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-glorious.c b/drivers/hid/hid-glorious.c
index 558eb08c19ef9..281b3a7187cec 100644
--- a/drivers/hid/hid-glorious.c
+++ b/drivers/hid/hid-glorious.c
@@ -21,6 +21,10 @@ MODULE_DESCRIPTION("HID driver for Glorious PC Gaming Race mice");
* Glorious Model O and O- specify the const flag in the consumer input
* report descriptor, which leads to inputs being ignored. Fix this
* by patching the descriptor.
+ *
+ * Glorious Model I incorrectly specifes the Usage Minimum for its
+ * keyboard HID report, causing keycodes to be misinterpreted.
+ * Fix this by setting Usage Minimum to 0 in that report.
*/
static __u8 *glorious_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
@@ -32,6 +36,10 @@ static __u8 *glorious_report_fixup(struct hid_device *hdev, __u8 *rdesc,
rdesc[85] = rdesc[113] = rdesc[141] = \
HID_MAIN_ITEM_VARIABLE | HID_MAIN_ITEM_RELATIVE;
}
+ if (*rsize == 156 && rdesc[41] == 1) {
+ hid_info(hdev, "patching Glorious Model I keyboard report descriptor\n");
+ rdesc[41] = 0;
+ }
return rdesc;
}
@@ -44,6 +52,8 @@ static void glorious_update_name(struct hid_device *hdev)
model = "Model O"; break;
case USB_DEVICE_ID_GLORIOUS_MODEL_D:
model = "Model D"; break;
+ case USB_DEVICE_ID_GLORIOUS_MODEL_I:
+ model = "Model I"; break;
}
snprintf(hdev->name, sizeof(hdev->name), "%s %s", "Glorious", model);
@@ -66,10 +76,12 @@ static int glorious_probe(struct hid_device *hdev,
}
static const struct hid_device_id glorious_devices[] = {
- { HID_USB_DEVICE(USB_VENDOR_ID_GLORIOUS,
+ { HID_USB_DEVICE(USB_VENDOR_ID_SINOWEALTH,
USB_DEVICE_ID_GLORIOUS_MODEL_O) },
- { HID_USB_DEVICE(USB_VENDOR_ID_GLORIOUS,
+ { HID_USB_DEVICE(USB_VENDOR_ID_SINOWEALTH,
USB_DEVICE_ID_GLORIOUS_MODEL_D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LAVIEW,
+ USB_DEVICE_ID_GLORIOUS_MODEL_I) },
{ }
};
MODULE_DEVICE_TABLE(hid, glorious_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e4d2dfd5d2536..9ed9ec03ad1bf 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -510,10 +510,6 @@
#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
-#define USB_VENDOR_ID_GLORIOUS 0x258a
-#define USB_DEVICE_ID_GLORIOUS_MODEL_D 0x0033
-#define USB_DEVICE_ID_GLORIOUS_MODEL_O 0x0036
-
#define I2C_VENDOR_ID_GOODIX 0x27c6
#define I2C_DEVICE_ID_GOODIX_01F0 0x01f0
@@ -744,6 +740,9 @@
#define USB_VENDOR_ID_LABTEC 0x1020
#define USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD 0x0006
+#define USB_VENDOR_ID_LAVIEW 0x22D4
+#define USB_DEVICE_ID_GLORIOUS_MODEL_I 0x1503
+
#define USB_VENDOR_ID_LCPOWER 0x1241
#define USB_DEVICE_ID_LCPOWER_LC1000 0xf767
@@ -1159,6 +1158,10 @@
#define USB_VENDOR_ID_SIGMATEL 0x066F
#define USB_DEVICE_ID_SIGMATEL_STMP3780 0x3780
+#define USB_VENDOR_ID_SINOWEALTH 0x258a
+#define USB_DEVICE_ID_GLORIOUS_MODEL_D 0x0033
+#define USB_DEVICE_ID_GLORIOUS_MODEL_O 0x0036
+
#define USB_VENDOR_ID_SIS_TOUCH 0x0457
#define USB_DEVICE_ID_SIS9200_TOUCH 0x9200
#define USB_DEVICE_ID_SIS817_TOUCH 0x0817
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 28/40] HID: add ALWAYS_POLL quirk for Apple kb
From: Sasha Levin @ 2023-11-28 21:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Oliver Neukum, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, linux-input
In-Reply-To: <20231128210615.875085-1-sashal@kernel.org>
From: Oliver Neukum <oneukum@suse.com>
[ Upstream commit c55092187d9ad7b2f8f5a8645286fa03997d442f ]
These devices disconnect if suspended without remote wakeup. They can operate
with the standard driver.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 3983b4f282f8f..0384384120c9f 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -33,6 +33,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_AKAI, USB_DEVICE_ID_AKAI_MPKMINI2), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD), HID_QUIRK_BADPAD },
{ HID_USB_DEVICE(USB_VENDOR_ID_AMI, USB_DEVICE_ID_AMI_VIRT_KEYBOARD_AND_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_REVB_ANSI), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_2PORTKVM), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM), HID_QUIRK_NOGET },
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 30/40] HID: hid-asus: reset the backlight brightness level on resume
From: Sasha Levin @ 2023-11-28 21:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Denis Benato, Luke D . Jones, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, linux-input
In-Reply-To: <20231128210615.875085-1-sashal@kernel.org>
From: Denis Benato <benato.denis96@gmail.com>
[ Upstream commit 546edbd26cff7ae990e480a59150e801a06f77b1 ]
Some devices managed by this driver automatically set brightness to 0
before entering a suspended state and reset it back to a default
brightness level after the resume:
this has the effect of having the kernel report wrong brightness
status after a sleep, and on some devices (like the Asus RC71L) that
brightness is the intensity of LEDs directly facing the user.
Fix the above issue by setting back brightness to the level it had
before entering a sleep state.
Signed-off-by: Denis Benato <benato.denis96@gmail.com>
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-asus.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index fd61dba882338..194a86cf30db4 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1000,6 +1000,24 @@ static int asus_start_multitouch(struct hid_device *hdev)
return 0;
}
+static int __maybe_unused asus_resume(struct hid_device *hdev) {
+ struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
+ int ret = 0;
+
+ if (drvdata->kbd_backlight) {
+ const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
+ drvdata->kbd_backlight->cdev.brightness };
+ ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
+ if (ret < 0) {
+ hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
+ goto asus_resume_err;
+ }
+ }
+
+asus_resume_err:
+ return ret;
+}
+
static int __maybe_unused asus_reset_resume(struct hid_device *hdev)
{
struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
@@ -1294,6 +1312,7 @@ static struct hid_driver asus_driver = {
.input_configured = asus_input_configured,
#ifdef CONFIG_PM
.reset_resume = asus_reset_resume,
+ .resume = asus_resume,
#endif
.event = asus_event,
.raw_event = asus_raw_event
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 31/40] HID: multitouch: Add quirk for HONOR GLO-GXXX touchpad
From: Sasha Levin @ 2023-11-28 21:05 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Aoba K, Jiri Kosina, Sasha Levin, jikos, benjamin.tissoires,
linux-input
In-Reply-To: <20231128210615.875085-1-sashal@kernel.org>
From: Aoba K <nexp_0x17@outlook.com>
[ Upstream commit 9ffccb691adb854e7b7f3ee57fbbda12ff70533f ]
Honor MagicBook 13 2023 has a touchpad which do not switch to the multitouch
mode until the input mode feature is written by the host. The touchpad do
report the input mode at touchpad(3), while itself working under mouse mode. As
a workaround, it is possible to call MT_QUIRE_FORCE_GET_FEATURE to force set
feature in mt_set_input_mode for such device.
The touchpad reports as BLTP7853, which cannot retrive any useful manufacture
information on the internel by this string at present. As the serial number of
the laptop is GLO-G52, while DMI info reports the laptop serial number as
GLO-GXXX, this workaround should applied to all models which has the GLO-GXXX.
Signed-off-by: Aoba K <nexp_0x17@outlook.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-multitouch.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 8db4ae05febc8..5ec1f174127a3 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -2048,6 +2048,11 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_HANVON_ALT,
USB_DEVICE_ID_HANVON_ALT_MULTITOUCH) },
+ /* HONOR GLO-GXXX panel */
+ { .driver_data = MT_CLS_VTL,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ 0x347d, 0x7853) },
+
/* Ilitek dual touch panel */
{ .driver_data = MT_CLS_NSMU,
MT_USB_DEVICE(USB_VENDOR_ID_ILITEK,
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 18/25] HID: glorious: fix Glorious Model I HID report
From: Sasha Levin @ 2023-11-28 21:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brett Raye, Jiri Kosina, Sasha Levin, jikos, benjamin.tissoires,
linux-input
In-Reply-To: <20231128210750.875945-1-sashal@kernel.org>
From: Brett Raye <braye@fastmail.com>
[ Upstream commit a5e913c25b6b2b6ae02acef6d9400645ac03dfdf ]
The Glorious Model I mouse has a buggy HID report descriptor for its
keyboard endpoint (used for programmable buttons). For report ID 2, there
is a mismatch between Logical Minimum and Usage Minimum in the array that
reports keycodes.
The offending portion of the descriptor: (from hid-decode)
0x95, 0x05, // Report Count (5) 30
0x75, 0x08, // Report Size (8) 32
0x15, 0x00, // Logical Minimum (0) 34
0x25, 0x65, // Logical Maximum (101) 36
0x05, 0x07, // Usage Page (Keyboard) 38
0x19, 0x01, // Usage Minimum (1) 40
0x29, 0x65, // Usage Maximum (101) 42
0x81, 0x00, // Input (Data,Arr,Abs) 44
This bug shifts all programmed keycodes up by 1. Importantly, this causes
"empty" array indexes of 0x00 to be interpreted as 0x01, ErrorRollOver.
The presence of ErrorRollOver causes the system to ignore all keypresses
from the endpoint and breaks the ability to use the programmable buttons.
Setting byte 41 to 0x00 fixes this, and causes keycodes to be interpreted
correctly.
Also, USB_VENDOR_ID_GLORIOUS is changed to USB_VENDOR_ID_SINOWEALTH,
and a new ID for Laview Technology is added. Glorious seems to be
white-labeling controller boards or mice from these vendors. There isn't a
single canonical vendor ID for Glorious products.
Signed-off-by: Brett Raye <braye@fastmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-glorious.c | 16 ++++++++++++++--
drivers/hid/hid-ids.h | 11 +++++++----
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-glorious.c b/drivers/hid/hid-glorious.c
index 558eb08c19ef9..281b3a7187cec 100644
--- a/drivers/hid/hid-glorious.c
+++ b/drivers/hid/hid-glorious.c
@@ -21,6 +21,10 @@ MODULE_DESCRIPTION("HID driver for Glorious PC Gaming Race mice");
* Glorious Model O and O- specify the const flag in the consumer input
* report descriptor, which leads to inputs being ignored. Fix this
* by patching the descriptor.
+ *
+ * Glorious Model I incorrectly specifes the Usage Minimum for its
+ * keyboard HID report, causing keycodes to be misinterpreted.
+ * Fix this by setting Usage Minimum to 0 in that report.
*/
static __u8 *glorious_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
@@ -32,6 +36,10 @@ static __u8 *glorious_report_fixup(struct hid_device *hdev, __u8 *rdesc,
rdesc[85] = rdesc[113] = rdesc[141] = \
HID_MAIN_ITEM_VARIABLE | HID_MAIN_ITEM_RELATIVE;
}
+ if (*rsize == 156 && rdesc[41] == 1) {
+ hid_info(hdev, "patching Glorious Model I keyboard report descriptor\n");
+ rdesc[41] = 0;
+ }
return rdesc;
}
@@ -44,6 +52,8 @@ static void glorious_update_name(struct hid_device *hdev)
model = "Model O"; break;
case USB_DEVICE_ID_GLORIOUS_MODEL_D:
model = "Model D"; break;
+ case USB_DEVICE_ID_GLORIOUS_MODEL_I:
+ model = "Model I"; break;
}
snprintf(hdev->name, sizeof(hdev->name), "%s %s", "Glorious", model);
@@ -66,10 +76,12 @@ static int glorious_probe(struct hid_device *hdev,
}
static const struct hid_device_id glorious_devices[] = {
- { HID_USB_DEVICE(USB_VENDOR_ID_GLORIOUS,
+ { HID_USB_DEVICE(USB_VENDOR_ID_SINOWEALTH,
USB_DEVICE_ID_GLORIOUS_MODEL_O) },
- { HID_USB_DEVICE(USB_VENDOR_ID_GLORIOUS,
+ { HID_USB_DEVICE(USB_VENDOR_ID_SINOWEALTH,
USB_DEVICE_ID_GLORIOUS_MODEL_D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LAVIEW,
+ USB_DEVICE_ID_GLORIOUS_MODEL_I) },
{ }
};
MODULE_DEVICE_TABLE(hid, glorious_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9a17e5cc3539b..2b9141e8388ba 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -502,10 +502,6 @@
#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
-#define USB_VENDOR_ID_GLORIOUS 0x258a
-#define USB_DEVICE_ID_GLORIOUS_MODEL_D 0x0033
-#define USB_DEVICE_ID_GLORIOUS_MODEL_O 0x0036
-
#define I2C_VENDOR_ID_GOODIX 0x27c6
#define I2C_DEVICE_ID_GOODIX_01F0 0x01f0
@@ -728,6 +724,9 @@
#define USB_VENDOR_ID_LABTEC 0x1020
#define USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD 0x0006
+#define USB_VENDOR_ID_LAVIEW 0x22D4
+#define USB_DEVICE_ID_GLORIOUS_MODEL_I 0x1503
+
#define USB_VENDOR_ID_LCPOWER 0x1241
#define USB_DEVICE_ID_LCPOWER_LC1000 0xf767
@@ -1130,6 +1129,10 @@
#define USB_VENDOR_ID_SIGMATEL 0x066F
#define USB_DEVICE_ID_SIGMATEL_STMP3780 0x3780
+#define USB_VENDOR_ID_SINOWEALTH 0x258a
+#define USB_DEVICE_ID_GLORIOUS_MODEL_D 0x0033
+#define USB_DEVICE_ID_GLORIOUS_MODEL_O 0x0036
+
#define USB_VENDOR_ID_SIS_TOUCH 0x0457
#define USB_DEVICE_ID_SIS9200_TOUCH 0x9200
#define USB_DEVICE_ID_SIS817_TOUCH 0x0817
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 19/25] HID: add ALWAYS_POLL quirk for Apple kb
From: Sasha Levin @ 2023-11-28 21:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Oliver Neukum, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, linux-input
In-Reply-To: <20231128210750.875945-1-sashal@kernel.org>
From: Oliver Neukum <oneukum@suse.com>
[ Upstream commit c55092187d9ad7b2f8f5a8645286fa03997d442f ]
These devices disconnect if suspended without remote wakeup. They can operate
with the standard driver.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index f8f20a7c24b17..5c3c65b524b5b 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -33,6 +33,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_AKAI, USB_DEVICE_ID_AKAI_MPKMINI2), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD), HID_QUIRK_BADPAD },
{ HID_USB_DEVICE(USB_VENDOR_ID_AMI, USB_DEVICE_ID_AMI_VIRT_KEYBOARD_AND_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_REVB_ANSI), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_2PORTKVM), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM), HID_QUIRK_NOGET },
--
2.42.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 21/25] HID: hid-asus: reset the backlight brightness level on resume
From: Sasha Levin @ 2023-11-28 21:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Denis Benato, Luke D . Jones, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, linux-input
In-Reply-To: <20231128210750.875945-1-sashal@kernel.org>
From: Denis Benato <benato.denis96@gmail.com>
[ Upstream commit 546edbd26cff7ae990e480a59150e801a06f77b1 ]
Some devices managed by this driver automatically set brightness to 0
before entering a suspended state and reset it back to a default
brightness level after the resume:
this has the effect of having the kernel report wrong brightness
status after a sleep, and on some devices (like the Asus RC71L) that
brightness is the intensity of LEDs directly facing the user.
Fix the above issue by setting back brightness to the level it had
before entering a sleep state.
Signed-off-by: Denis Benato <benato.denis96@gmail.com>
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-asus.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index d1094bb1aa429..88dfa688f560d 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1012,6 +1012,24 @@ static int asus_start_multitouch(struct hid_device *hdev)
return 0;
}
+static int __maybe_unused asus_resume(struct hid_device *hdev) {
+ struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
+ int ret = 0;
+
+ if (drvdata->kbd_backlight) {
+ const u8 buf[] = { FEATURE_KBD_REPORT_ID, 0xba, 0xc5, 0xc4,
+ drvdata->kbd_backlight->cdev.brightness };
+ ret = asus_kbd_set_report(hdev, buf, sizeof(buf));
+ if (ret < 0) {
+ hid_err(hdev, "Asus failed to set keyboard backlight: %d\n", ret);
+ goto asus_resume_err;
+ }
+ }
+
+asus_resume_err:
+ return ret;
+}
+
static int __maybe_unused asus_reset_resume(struct hid_device *hdev)
{
struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
@@ -1303,6 +1321,7 @@ static struct hid_driver asus_driver = {
.input_configured = asus_input_configured,
#ifdef CONFIG_PM
.reset_resume = asus_reset_resume,
+ .resume = asus_resume,
#endif
.event = asus_event,
.raw_event = asus_raw_event
--
2.42.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox