* Re: [PATCH 0/5] HID: playstation: various DS4 and DualSense fixes
From: Jiri Kosina @ 2023-01-18 9:13 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander
In-Reply-To: <20230106015910.3031670-1-roderick.colenbrander@sony.com>
On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
> Hi,
>
> This patch set contains a number of small fixes and stability improvements.
>
> The stability patches are most critical as they prevent kernel crashes.
> Over the years there have been various buggy devices usually clone devices,
> but now apparently some official devices with wiped calibration data.
> It is hard to handle all permutations of devices as some have constants,
> some have broken constants (e.g. wrong sign of a coefficient). We disable
> calibration when we see an invalid 0 denominator. The patch adds the same
> logic to both the DualShock4 and DualSense code.
>
> As part of the calibration stability improvements, a thorough review was
> performed of the calibration code as it was suspected it was potentially
> incorrect. It was found to be only slightly wrong for the handling of the
> bias of the gyroscopes. Two patches fix this for both DualShock4 and DualSense.
> There is only a marginal impact on practical values as the bias values
> tend to be quite small.
>
> Thanks,
> Roderick Colenbrander
> Sony Interactive Entertainment, LLC
I am splitting the stability ones (for 6.2) from the small improvements /
cleanups (for 6.3).
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: amd_sfh: Add support for tablet-mode-switch sensor
From: Adrian Freund @ 2023-01-18 9:13 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-input, linux-kernel, Basavaraj Natikar, Benjamin Tissoires,
Luke D. Jones, Ivan Dovgal
In-Reply-To: <nycvar.YFH.7.76.2301180948450.1734@cbobk.fhfr.pm>
On 1/18/23 09:49, Jiri Kosina wrote:
> On Sun, 18 Dec 2022, Adrian Freund wrote:
>
>> This patch adds support for the tablet mode switch sensors on
>> convertible devices where that sensor is managed by AMD SFH, like the
>> Asus Flow X13 and the Lenovo ThinkPad L13 Yoga Gen2 (AMD).
>>
>> Co-developed-by: Ivan Dovgal <iv.dovg@gmail.com>
>> Signed-off-by: Ivan Dovgal <iv.dovg@gmail.com>
>> Co-developed-by: Luke D. Jones <luke@ljones.dev>
>> Signed-off-by: Luke D. Jones <luke@ljones.dev>
>> Signed-off-by: Adrian Freund <adrian@freund.io>
> Basavaraj, could you please review this? Thanks,
>
I think this doesn't need a review right now. I recently found some big
problems with the patch recently and am working on an updated version. I
think reviewing once I send v3 should be enough.
In short: This patch generates nonsensical HID messages that don't even
contain the sensor state.
It still makes the tablet-mode-switch work on some but not all devices
due to a mechanism I don't fully understand yet. Somehow ACPI devices
that previously did nothing suddenly work with this patch and are then
getting picked up by various platform drivers depending on the device.
This driver however doesn't properly handle the actual data directly
from the sensor.
---
Adrian
^ permalink raw reply
* Re: [PATCH 1/5] HID: playstation: fix DualShock4 unreachable calibration code.
From: Jiri Kosina @ 2023-01-18 9:11 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander,
Abaci Robot, Jiapeng Chong, kernel test robot, Dan Carpenter
In-Reply-To: <20230106015910.3031670-2-roderick.colenbrander@sony.com>
On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
> Reported-by: Abaci Robot <abaci@linux.alibaba.com>
> Reported-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <error27@gmail.com>
> Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Applied to for-6.3/sony.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: enable trackstick of Asus ExpertBook B2502
From: Benjamin Tissoires @ 2023-01-18 9:49 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <20221219105521.73467-1-benjamin.tissoires@redhat.com>
On Mon, Dec 19, 2022 at 11:55 AM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> This device has a trackstick that is sent through the same HID device
> than the touchpad.
> Unfortunately there are 2 mice attached to that device descriptor, with
> the first one for the touchpad when the second is for the trackstick.
>
> Force all devices to be exported.
>
> Cc: stable@vger.kernel.org # 5.8+
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2154204
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
FTR, this patch was already taken through
4eab1c2fe06c98a4dff258dd64800b6986c101e9, so we can safely ditch it.
Cheers,
Benjamin
> ---
> drivers/hid/hid-multitouch.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 91a4d3fc30e0..91ac72b32d45 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -1860,6 +1860,12 @@ static const struct hid_device_id mt_devices[] = {
> USB_VENDOR_ID_ASUSTEK,
> USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD) },
>
> + /* Asus ExpertBook with trackstick */
> + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> + USB_VENDOR_ID_ELAN,
> + 0x3148) },
> +
> /* Atmel panels */
> { .driver_data = MT_CLS_SERIAL,
> MT_USB_DEVICE(USB_VENDOR_ID_ATMEL,
> --
> 2.38.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] HID: i2c-hid: acpi: Drop unneded NULL check of adev
From: Andy Shevchenko @ 2023-01-18 10:00 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, Raul E Rangel, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <nycvar.YFH.7.76.2301181006170.1734@cbobk.fhfr.pm>
On Wed, Jan 18, 2023 at 10:06:32AM +0100, Jiri Kosina wrote:
> On Mon, 16 Jan 2023, Andy Shevchenko wrote:
>
> > The driver is enumerated on ACPI platforms, so adev is valid.
> > Since there is no valid I²C ID table provided, there is no
> > possibility to bind a device to this driver via user space.
> > Hence, drop unneeded NULL check of adev.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Applied both to hid.git#for-6.3/i2c-hid. Thanks,
Thank you and HNY!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: remove arch/sh
From: Rob Landley @ 2023-01-18 11:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Christoph Hellwig, John Paul Adrian Glaubitz, Yoshinori Sato,
Rich Felker, Arnd Bergmann, Greg Kroah-Hartman, Laurent Pinchart,
Kieran Bingham, Geert Uytterhoeven, linux-kernel, linux-watchdog,
devicetree, linux-arch, dmaengine, dri-devel, linux-renesas-soc,
linux-i2c, linux-input, linux-media, linux-mmc, linux-mtd, netdev,
linux-gpio, linux-rtc, linux-spi, linux-serial, linux-usb,
linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <CAMuHMdXo3iR2C=CAaXO5tBRCncnQAAMR6BMPLOm_nBpFAeVhrA@mail.gmail.com>
On 1/18/23 01:46, Geert Uytterhoeven wrote:
> Again, I think you're talking about something different.
> Does kexec work for you?
Sorry, got woken up several hours early by sirens and flashy lights this morning
(duplex on the corner caught fire, Austin has a LOT of emergency vehicles), been
a bit underclocked all day.
No, I haven't tried kexec on sh4. I'll add it to the todo heap.
>> > I tried working my way up from 2.6.22, but gave up around 2.6.29.
>> > Probably I should do this with r2d and qemu instead ;-)
>>
>> I have current running there. I've had current running there for years. Config
>> attached...
>>
>> > Both r2d and landisk are SH7751.
>>
>> Cool. Shouldn't be hard to get landisk running current then.
>
> Current kernels work fine on landisk with an old Debian userspace
> on CF. The 8139cp driver is a bit flaky: last time I tried nfsroot,
> that didn't work well.
I've never had luck with NFS, I was using NBD. Hadn't noticed the flake but
haven't stress tested it too hard either?
Mostly new userspace is what I'm testing...
Rob
^ permalink raw reply
* Re: [PATCH 1/2] HID: core: Provide new max_buffer_size attribute to over-ride the default
From: Lee Jones @ 2023-01-18 11:09 UTC (permalink / raw)
To: Jiri Kosina
Cc: benjamin.tissoires, avid.rheinsberg, linux-kernel, linux-input
In-Reply-To: <nycvar.YFH.7.76.2301181002550.1734@cbobk.fhfr.pm>
On Wed, 18 Jan 2023, Jiri Kosina wrote:
> On Fri, 13 Jan 2023, Lee Jones wrote:
>
> > Presently, when a report is processed, its size is compared solely
> > against the value specified by user-space.
>
> While I am generally fine with the idea, I don't understand this sentence.
> What exactly do you mean by 'specified by user-space'? It's defined as a
> compile-time constant.
>
> > If the received report ends up being smaller than this, the
> > remainder of the buffer is zeroed.
Apologies for any ambiguity.
"its size" == "compile-time constant"
Would "its maximum size" read better?
These sentences are an attempt to describe this statement:
if (csize < rsize) {
dbg_hid("report %d is too short, (%d < %d)\n", report->id,
csize, rsize);
memset(cdata + csize, 0, rsize - csize);
}
Where csize is "the [size of the] received report" and rsize is the
"value [size] specified by user-space". Thus, if user-space says the
report will be 8-Bytes (rsize) and it actually only only submits 6-Bytes
(csize), then the subsystem will complain that the "report is too short"
and it will attempt to zero the seemingly unused 2-Bytes.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 1/2] HID: core: Provide new max_buffer_size attribute to over-ride the default
From: Jiri Kosina @ 2023-01-18 14:55 UTC (permalink / raw)
To: Lee Jones; +Cc: benjamin.tissoires, avid.rheinsberg, linux-kernel, linux-input
In-Reply-To: <Y8fTd0VJXqKkPIuo@google.com>
On Wed, 18 Jan 2023, Lee Jones wrote:
> > > Presently, when a report is processed, its size is compared solely
> > > against the value specified by user-space.
> >
> > While I am generally fine with the idea, I don't understand this sentence.
> > What exactly do you mean by 'specified by user-space'? It's defined as a
> > compile-time constant.
> >
> > > If the received report ends up being smaller than this, the
> > > remainder of the buffer is zeroed.
>
> Apologies for any ambiguity.
>
> "its size" == "compile-time constant"
>
> Would "its maximum size" read better?
I think that the confusion comes from the fact that the changelog is
written solely with the UHID usercase on mind ... ? (which is dealt with
in the independent followup patch).
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Alps touchpad intermittently recognized as generic mouse
From: Jonathan Denose @ 2023-01-18 15:01 UTC (permalink / raw)
To: linux-input
Hello,
I have a Dell Vostro 3550 which fails to initialize the AlpsPS/2
driver for its touchpad and then falls back to the generic PS/2 driver
which doesn't allow for two finger vertical scrolling. I have looked
through the driver code and found the failure to happen for address
0x0006 on this line in some cases and this other line in other cases.
Sometimes the initialize doesn't fail at all and the AlpsPS/2 driver
is used and the touchpad works correctly with vertical scroll.
I have found that this touchpad and driver work fine on the same
device running Ubuntu. I am currently using kernel 5.10 running
ChromeOS.
Some more info for the touchpad:
E6 report: 00 00 64
E7 report: 73 02 64
EC report: 88 07 9d
Any help in resolving this issue would be greatly appreciated!
Thank you,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/2] HID: core: Provide new max_buffer_size attribute to over-ride the default
From: Lee Jones @ 2023-01-18 15:11 UTC (permalink / raw)
To: Jiri Kosina
Cc: benjamin.tissoires, avid.rheinsberg, linux-kernel, linux-input
In-Reply-To: <nycvar.YFH.7.76.2301181554370.1734@cbobk.fhfr.pm>
On Wed, 18 Jan 2023, Jiri Kosina wrote:
> On Wed, 18 Jan 2023, Lee Jones wrote:
>
> > > > Presently, when a report is processed, its size is compared solely
> > > > against the value specified by user-space.
> > >
> > > While I am generally fine with the idea, I don't understand this sentence.
> > > What exactly do you mean by 'specified by user-space'? It's defined as a
> > > compile-time constant.
> > >
> > > > If the received report ends up being smaller than this, the
> > > > remainder of the buffer is zeroed.
> >
> > Apologies for any ambiguity.
> >
> > "its size" == "compile-time constant"
> >
> > Would "its maximum size" read better?
>
> I think that the confusion comes from the fact that the changelog is
> written solely with the UHID usercase on mind ... ? (which is dealt with
> in the independent followup patch).
Quite possibly, yes. Since this is the way the bug was reported to me
and how I presently view it. However, I suppose reports do not always
originate from user-space. Good point.
How would you like me to move forward? Would you like me to re-write
the commit log to be more generic?
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH] hid: stop drivers from selecting CONFIG_HID
From: Jiri Kosina @ 2023-01-18 15:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Basavaraj Natikar, Benjamin Tissoires, Srinivas Pandruvada,
Greg Kroah-Hartman, Arnd Bergmann, Douglas Anderson,
Dmitry Torokhov, linux-input, linux-kernel
In-Reply-To: <20230117172121.2715953-1-arnd@kernel.org>
On Tue, 17 Jan 2023, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> There is a mix of drivers using either 'depends on HID' or 'select HID',
> which causes both circular dependencies and missed dependencies for
> a 'select':
>
> WARNING: unment direct dependencies for HID
> Depends on [m]: HID_SUPPORT [=y] && INPUT [=m]
> Selected by [y]:
> - AMD_SFH_HID [=y] && HID_SUPPORT [=y] && (X86_64 || COMPILE_TEST [=y]) && PCI [=y]
> Selected by [m]:
> - I2C_HID_CORE [=m] && HID_SUPPORT [=y]
>
> WARNING: unmet direct dependencies detected for INPUT_FF_MEMLESS
> Depends on [m]: INPUT [=m]
> Selected by [y]:
> - DRAGONRISE_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_DRAGONRISE [=y]
> - HID_MICROSOFT [=y] && HID_SUPPORT [=y] && HID [=y]
> - GREENASIA_FF [=y] && HID_SUPPORT [=y] && HID [=y] && HID_GREENASIA [=y]
> Selected by [m]:
> - INPUT_ARIZONA_HAPTICS [=m] && INPUT [=m] && INPUT_MISC [=y] && MFD_ARIZONA [=y] && SND_SOC [=m]
> - INPUT_PM8XXX_VIBRATOR [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_PM8XXX [=m] || MFD_SPMI_PMIC [=n])
> - INPUT_MAX8997_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y] && MFD_MAX8997 [=y]
> - INPUT_GPIO_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> - INPUT_REGULATOR_HAPTIC [=m] && INPUT [=m] && INPUT_MISC [=y] && REGULATOR [=y]
> - INPUT_TWL6040_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && TWL6040_CORE [=y]
> - INPUT_PWM_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && PWM [=y]
> - INPUT_DRV260X_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> - INPUT_DRV2665_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
> - INPUT_DRV2667_HAPTICS [=m] && INPUT_MISC [=y] && INPUT [=m] && I2C [=y]
> - INPUT_SC27XX_VIBRA [=m] && INPUT [=m] && INPUT_MISC [=y] && (MFD_SC27XX_PMIC [=y] || COMPILE_TEST [=y])
> - HID_MAYFLASH [=m] && HID_SUPPORT [=y] && HID [=y]
>
> Avoid this by changing all HID client drivers to use 'depends on HID'.
> For I2C_HID, this requires a larger rework of the Kconfig description,
> but it hopefully becomes easier to understand without the complex
> I2C_HID_CORE definition.
>
> Fixes: 25621bcc8976 ("HID: Kconfig: split HID support and hid-core compilation")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to hid.git#for-6.3/hid-bpf. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/5] HID: playstation: various DS4 and DualSense fixes
From: Roderick Colenbrander @ 2023-01-18 18:42 UTC (permalink / raw)
To: Jiri Kosina
Cc: Roderick Colenbrander, Benjamin Tissoires, linux-input,
Roderick Colenbrander
In-Reply-To: <nycvar.YFH.7.76.2301181013030.1734@cbobk.fhfr.pm>
On Wed, Jan 18, 2023 at 2:12 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
>
> > Hi,
> >
> > This patch set contains a number of small fixes and stability improvements.
> >
> > The stability patches are most critical as they prevent kernel crashes.
> > Over the years there have been various buggy devices usually clone devices,
> > but now apparently some official devices with wiped calibration data.
> > It is hard to handle all permutations of devices as some have constants,
> > some have broken constants (e.g. wrong sign of a coefficient). We disable
> > calibration when we see an invalid 0 denominator. The patch adds the same
> > logic to both the DualShock4 and DualSense code.
> >
> > As part of the calibration stability improvements, a thorough review was
> > performed of the calibration code as it was suspected it was potentially
> > incorrect. It was found to be only slightly wrong for the handling of the
> > bias of the gyroscopes. Two patches fix this for both DualShock4 and DualSense.
> > There is only a marginal impact on practical values as the bias values
> > tend to be quite small.
> >
> > Thanks,
> > Roderick Colenbrander
> > Sony Interactive Entertainment, LLC
>
> I am splitting the stability ones (for 6.2) from the small improvements /
> cleanups (for 6.3).
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
Thanks, that's how the patches were kind of set up. I wasn't sure due
to timing where they would land, but thanks for pulling in the
stability fixes!
Thanks,
Roderick
^ permalink raw reply
* Re: [PATCH HID for-next v2 0/9] HID-BPF LLVM fixes, no more hacks
From: Jiri Kosina @ 2023-01-18 21:12 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Greg KH, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Dmitry Torokhov, Tero Kristo, linux-kernel, linux-input, netdev,
bpf, linux-kselftest
In-Reply-To: <20230113090935.1763477-1-benjamin.tissoires@redhat.com>
On Fri, 13 Jan 2023, Benjamin Tissoires wrote:
> Hi,
>
> So this is the fix for the bug that actually prevented me to integrate
> HID-BPF in v6.2.
>
> While testing the code base with LLVM, I realized that clang was smarter
> than I expected it to be, and it sometimes inlined a function or not
> depending on the branch. This lead to segfaults because my current code
> in linux-next is messing up the bpf programs refcounts assuming that I
> had enough observability over the kernel.
>
> So I came back to the drawing board and realized that what I was missing
> was exactly a bpf_link, to represent the attachment of a bpf program to
> a HID device. This is the bulk of the series, in patch 6/9.
>
> The other patches are cleanups, tests, and also the addition of the
> vmtests.sh script I run locally, largely inspired by the one in the bpf
> selftests dir. This allows very fast development of HID-BPF, assuming we
> have tests that cover the bugs :)
>
>
> changes in v2:
> - took Alexei's remarks into account and renamed the indexes into
> prog_table_index and hid_table_index
> - fixed unused function as reported by the Intel kbuild bot
I've now applied this on top of the previous work in
hid.git#for-6.3/hid-bpf
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH 2/3] Input: add ABS_SND_PROFILE
From: Gergo Koteles @ 2023-01-18 23:46 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Jiri Kosina,
Benjamin Tissoires
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree,
Caleb Connolly, Gergo Koteles
In-Reply-To: <20230118234638.189098-1-soyer@irl.hu>
ABS_SND_PROFILE used to describe the state of a multi-value sound profile
switch. This will be used for the tri-state key on OnePlus phones or other
phones.
Signed-off-by: Gergo Koteles <soyer@irl.hu>
---
Documentation/input/event-codes.rst | 6 ++++++
drivers/hid/hid-debug.c | 1 +
include/uapi/linux/input-event-codes.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
index b4557462edd7..d43336e64d6a 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -241,6 +241,12 @@ A few EV_ABS codes have special meanings:
emitted only when the selected profile changes, indicating the newly
selected profile value.
+* ABS_SND_PROFILE:
+
+ - Used to describe the state of a multi-value sound profile switch.
+ An event is emitted only when the selected profile changes,
+ indicating the newly selected profile value.
+
* ABS_MT_<name>:
- Used to describe multitouch input events. Please see
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index e213bdde543a..76fb2ecbbc51 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -1018,6 +1018,7 @@ static const char *absolutes[ABS_CNT] = {
[ABS_DISTANCE] = "Distance", [ABS_TILT_X] = "XTilt",
[ABS_TILT_Y] = "YTilt", [ABS_TOOL_WIDTH] = "ToolWidth",
[ABS_VOLUME] = "Volume", [ABS_PROFILE] = "Profile",
+ [ABS_SND_PROFILE] = "SoundProfile",
[ABS_MISC] = "Misc",
[ABS_MT_TOUCH_MAJOR] = "MTMajor",
[ABS_MT_TOUCH_MINOR] = "MTMinor",
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 022a520e31fc..e765a8f9a3ae 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -866,6 +866,7 @@
#define ABS_VOLUME 0x20
#define ABS_PROFILE 0x21
+#define ABS_SND_PROFILE 0x22
#define ABS_MISC 0x28
--
2.39.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: qcom: sdm845-oneplus: add tri-state-key
From: Gergo Koteles @ 2023-01-18 23:46 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Jiri Kosina,
Benjamin Tissoires
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree,
Caleb Connolly, Gergo Koteles
In-Reply-To: <20230118234638.189098-1-soyer@irl.hu>
The tri-state-key is a sound profile switch found on the OnePlus 6,
Android maps the states to "mute", "vibrate" and "ring", expose them as
ABS_SND_PROFILE events.
The previous GPIO numbers were wrong, the patch updates them to the correct
ones.
Co-developed-by: Caleb Connolly <caleb@connolly.tech>
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Signed-off-by: Gergo Koteles <soyer@irl.hu>
---
.../boot/dts/qcom/sdm845-oneplus-common.dtsi | 43 ++++++++++++++++++-
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 42cf4dd5ea28..33215ad17513 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -49,6 +49,44 @@ key-vol-up {
};
};
+ tri-state-key {
+ compatible = "gpio-keys";
+ label = "Tri-state key";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tri_state_key_default>;
+
+ state-top {
+ label = "Tri-state key top";
+ linux,input-type = <EV_ABS>;
+ linux,code = <ABS_SND_PROFILE>;
+ linux,input-value = <0>;
+ gpios = <&tlmm 126 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ linux,can-disable;
+ };
+
+ state-middle {
+ label = "Tri-state key middle";
+ linux,input-type = <EV_ABS>;
+ linux,code = <ABS_SND_PROFILE>;
+ linux,input-value = <1>;
+ gpios = <&tlmm 52 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ linux,can-disable;
+ };
+
+ state-bottom {
+ label = "Tri-state key bottom";
+ linux,input-type = <EV_ABS>;
+ linux,code = <ABS_SND_PROFILE>;
+ linux,input-value = <2>;
+ gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ linux,can-disable;
+ };
+ };
+
reserved-memory {
/*
* The rmtfs_mem needs to be guarded due to "XPU limitations"
@@ -588,9 +626,10 @@ &usb_1_hsphy {
&tlmm {
gpio-reserved-ranges = <0 4>, <81 4>;
- tri_state_key_default: tri_state_key_default {
+ // The GPIOs have a hardware pullup.
+ tri_state_key_default: tri-state-pins {
mux {
- pins = "gpio40", "gpio42", "gpio26";
+ pins = "gpio126", "gpio52", "gpio24";
function = "gpio";
drive-strength = <2>;
bias-disable;
--
2.39.0
^ permalink raw reply related
* [PATCH 0/3] Add tri-state-key for oneplus
From: Gergo Koteles @ 2023-01-18 23:46 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Jiri Kosina,
Benjamin Tissoires
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree,
Caleb Connolly, Gergo Koteles
Gergo Koteles (3):
Input: gpio-keys - add support for linux,input-value dts property
Input: add ABS_SND_PROFILE
arm64: dts: qcom: sdm845-oneplus: add tri-state-key
Documentation/input/event-codes.rst | 6 +++
.../boot/dts/qcom/sdm845-oneplus-common.dtsi | 43 ++++++++++++++++++-
drivers/hid/hid-debug.c | 1 +
drivers/input/keyboard/gpio_keys.c | 3 ++
include/uapi/linux/input-event-codes.h | 1 +
5 files changed, 52 insertions(+), 2 deletions(-)
--
2.39.0
^ permalink raw reply
* [PATCH 1/3] Input: gpio-keys - add support for linux,input-value dts property
From: Gergo Koteles @ 2023-01-18 23:46 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Jiri Kosina,
Benjamin Tissoires
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree,
Caleb Connolly, Gergo Koteles
In-Reply-To: <20230118234638.189098-1-soyer@irl.hu>
Allows setting the value of EV_ABS events from dts.
This property is included in the gpio-keys.yaml scheme, but was only
implemented for gpio-keys-polled.
Signed-off-by: Gergo Koteles <soyer@irl.hu>
---
drivers/input/keyboard/gpio_keys.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 5496482a38c1..c42f86ad0766 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -770,6 +770,9 @@ gpio_keys_get_devtree_pdata(struct device *dev)
&button->type))
button->type = EV_KEY;
+ fwnode_property_read_u32(child, "linux,input-value",
+ (u32 *)&button->value);
+
button->wakeup =
fwnode_property_read_bool(child, "wakeup-source") ||
/* legacy name */
--
2.39.0
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: qcom: sdm845-oneplus: add tri-state-key
From: Krzysztof Kozlowski @ 2023-01-19 11:29 UTC (permalink / raw)
To: Gergo Koteles, Dmitry Torokhov, Jonathan Corbet, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree,
Caleb Connolly
In-Reply-To: <20230118234638.189098-4-soyer@irl.hu>
On 19/01/2023 00:46, Gergo Koteles wrote:
> The tri-state-key is a sound profile switch found on the OnePlus 6,
> Android maps the states to "mute", "vibrate" and "ring", expose them as
> ABS_SND_PROFILE events.
> The previous GPIO numbers were wrong, the patch updates them to the correct
> ones.
>
> Co-developed-by: Caleb Connolly <caleb@connolly.tech>
> Signed-off-by: Caleb Connolly <caleb@connolly.tech>
> Signed-off-by: Gergo Koteles <soyer@irl.hu>
> ---
> .../boot/dts/qcom/sdm845-oneplus-common.dtsi | 43 ++++++++++++++++++-
> 1 file changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> index 42cf4dd5ea28..33215ad17513 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> @@ -49,6 +49,44 @@ key-vol-up {
> };
> };
>
> + tri-state-key {
> + compatible = "gpio-keys";
> + label = "Tri-state key";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&tri_state_key_default>;
> +
> + state-top {
Does not look like you tested the DTS against bindings. Please run `make
dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst
for instructions).
> + label = "Tri-state key top";
> + linux,input-type = <EV_ABS>;
> + linux,code = <ABS_SND_PROFILE>;
> + linux,input-value = <0>;
> + gpios = <&tlmm 126 GPIO_ACTIVE_LOW>;
> + debounce-interval = <50>;
> + linux,can-disable;
> + };
> +
> + state-middle {
> + label = "Tri-state key middle";
> + linux,input-type = <EV_ABS>;
> + linux,code = <ABS_SND_PROFILE>;
> + linux,input-value = <1>;
> + gpios = <&tlmm 52 GPIO_ACTIVE_LOW>;
> + debounce-interval = <50>;
> + linux,can-disable;
> + };
> +
> + state-bottom {
> + label = "Tri-state key bottom";
> + linux,input-type = <EV_ABS>;
> + linux,code = <ABS_SND_PROFILE>;
> + linux,input-value = <2>;
> + gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
> + debounce-interval = <50>;
> + linux,can-disable;
> + };
> + };
> +
> reserved-memory {
> /*
> * The rmtfs_mem needs to be guarded due to "XPU limitations"
> @@ -588,9 +626,10 @@ &usb_1_hsphy {
> &tlmm {
> gpio-reserved-ranges = <0 4>, <81 4>;
>
> - tri_state_key_default: tri_state_key_default {
> + // The GPIOs have a hardware pullup.
> + tri_state_key_default: tri-state-pins {
> mux {
You need to rebase.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] driver: input: matric-keypad: switch to gpiod API
From: Gireesh.Hiremath @ 2023-01-19 11:47 UTC (permalink / raw)
To: andriy.shevchenko
Cc: linux-input, linux-kernel, dmitry.torokhov, Jonathan.Cameron,
lis8215, Gireesh.Hiremath, sjoerd.simons, VinayKumar.Shettar,
Govindaraji.Sivanantham, anaclaudia.dias
In-Reply-To: <20230113062538.1537-1-Gireesh.Hiremath@in.bosch.com>
From: Gireesh Hiremath <Gireesh.Hiremath@in.bosch.com>
Hi Andy Shevchenko,
I will correct it as
>Thank you for the patch, my comments below.
>
>> switch to new gpio descriptor based API
Switch to GPIO descriptor based API.
>
>Please, respect English grammar and punctuation.
>
>Also, you have a typo in the Subject besides the fact that the template for
>Input subsystem is different. So prefix has to be changed as well.
and template as
Input: matrix_keypad - switch to gpiod API
>
>...
>
>> bool level_on = !pdata->active_low;
>>
>> if (on) {
>> - gpio_direction_output(pdata->col_gpios[col], level_on);
>> + gpiod_direction_output(pdata->col_gpios[col], level_on);
>> } else {
>> - gpio_set_value_cansleep(pdata->col_gpios[col], !level_on);
>> + gpiod_set_value_cansleep(pdata->col_gpios[col], !level_on);
>> }
>
>I believe it's not so trivial. The GPIO descriptor already has encoded the
>level information and above one as below are not clear now.
>
>> - return gpio_get_value_cansleep(pdata->row_gpios[row]) ?
>> + return gpiod_get_value_cansleep(pdata->row_gpios[row]) ?
>> !pdata->active_low : pdata->active_low;
>
if GPIO from I2C or SPI IO expander, which may sleep,
so it is safer to use the gpiod_set_value_cansleep() and
gpiod_get_value_cansleep().
>...
>
>> - err = gpio_request(pdata->col_gpios[i], "matrix_kbd_col");
>> + err = gpiod_direction_output(pdata->col_gpios[i], !pdata->active_low);
>
>> while (--i >= 0)
>> - gpio_free(pdata->row_gpios[i]);
>> + gpiod_put(pdata->row_gpios[i]);
>
>This looks like an incorrect change.
>
>> while (--i >= 0)
>> - gpio_free(pdata->col_gpios[i]);
>> + gpiod_put(pdata->col_gpios[i]);
>
>So does this.
>
>Since you dropped gpio_request() you need to drop gpio_free() as well,
>and not replace it.
gpio_request() equalent api gpiod_request() is alredy called inside gpiod_get_index(...).
gpiod_put() is required to free GPIO.
>
>...
>
>> for (i = 0; i < nrow; i++) {
>> - ret = of_get_named_gpio(np, "row-gpios", i);
>> - if (ret < 0)
>
>> - return ERR_PTR(ret);
>
>(1)
>
>> - gpios[i] = ret;
>> + desc = gpiod_get_index(dev, "row", i, GPIOD_IN);
>> + if (IS_ERR(desc))
>
>> + return ERR_PTR(-EINVAL);
>
>Why?! How will it handle deferred probe, for example?
shall I update it as
return ERR_CAST(desc);
>
>> + gpios[i] = desc;
>> }
>
>...
>
>> for (i = 0; i < ncol; i++) {
>> - ret = of_get_named_gpio(np, "col-gpios", i);
>> - if (ret < 0)
>> - return ERR_PTR(ret);
>> - gpios[nrow + i] = ret;
>> + desc = gpiod_get_index(dev, "col", i, GPIOD_IN);
>> + if (IS_ERR(desc))
>> + return ERR_PTR(-EINVAL);
>
>Ditto.
>
>> + gpios[nrow + i] = desc;
>> }
Thanks,
Gireesh Hiremath
^ permalink raw reply
* [regression] Bug 216946 - Toshiba satellite click mini l9w-b: touchscreen: no touch events with kernel 6.1.4
From: Linux kernel regression tracking (Thorsten Leemhuis) @ 2023-01-19 15:06 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Dmitry Torokhov
Cc: open list:HID CORE LAYER, LKML, Linux kernel regressions list,
Gé Koerkamp
Hi, this is your Linux kernel regression tracker.
I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developer don't keep an eye on it, I decided to forward it by
mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216946 :
> Gé Koerkamp 2023-01-17 20:21:51 UTC
>
> Created attachment 303619 [details]
> Kernel configuration for v6.1.4/ journalctl (dmesg)/ ACPIdump/lsmod
>
> Overview:
> The touchscreen does not react on touch events.
> Touchscreen display and touchpad are working.
>
> Step to reproduce:
> Open any UI page
> Try to use touch on relevant UI controls (buttons etc.)
>
> Result:
> No reaction on screen touches
>
> Expected result:
> Reaction on touched control, same as when using the touch pad or connected mouse (which do work).
>
> Build information:
> The error happens with kernel version 6.1.4
> After rebuilding with different kernel versions, it appears that it first fails with kernel 5.16
>
> Additional builds:
> The click mini l9w-b still works with kernel 5.10.y LTS and 5.15.y LTS.
>
> Important remark:
> Touchscreen still works fine with kernel 6.1.4 using
> - an HP x2 detachable 10-p0xx or
> - a Lenovo yoga 520-14ikb
>
> So it could be a hardware dependent issue
See the ticket for more details.
[TLDR for the rest of this mail: I'm adding this report to the list of
tracked Linux kernel regressions; the text you find below is based on a
few templates paragraphs you might have encountered already in similar
form.]
BTW, let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:
#regzbot introduced: v5.15..v5.16
https://bugzilla.kernel.org/show_bug.cgi?id=216946
#regzbot title: hid: touchscreen broken with Toshiba satellite click
mini l9w-b
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (e.g. the buzgzilla ticket and maybe this mail as well, if
this thread sees some discussion). See page linked in footer for details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
^ permalink raw reply
* Re: [PATCH v8 0/6] Add MediaTek MT6357 PMIC support
From: Matthias Brugger @ 2023-01-19 17:27 UTC (permalink / raw)
To: Alexandre Mergnat, Mark Brown, Tianping Fang, Alessandro Zummo,
Dmitry Torokhov, Alexandre Belloni, Fabien Parent, Lee Jones,
Krzysztof Kozlowski, Chen Zhong, Pavel Machek, Rob Herring,
Sean Wang, Flora Fu, Liam Girdwood
Cc: Mattijs Korpershoek, Krzysztof Kozlowski, linux-rtc, linux-leds,
Rob Herring, devicetree, Fabien Parent, linux-input,
linux-mediatek, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-kernel
In-Reply-To: <20221005-mt6357-support-v8-0-560caaafee53@baylibre.com>
Given the ACK in the series I took the bindings and driver through v6.2-next/soc
and the DTS changes through v6.2-next/dts64
Thanks!
On 02/01/2023 17:06, Alexandre Mergnat wrote:
> Hi,
> This patch series adds MFD, PMIC keys, and regulator support for MT6357.
> MT6357 is a MediaTek PMIC very similar to MT6358.
>
> Currently, MTK bindings related to the PMICs are not converted yet (still .txt):
>
> soc/mediatek/pwrap.txt (all PMIC parent)
> |
> V
> mfd/mt6397.txt (support lot of mt63XX PMIC)
> +---------------+----------------+---...
> V V V
> regulator/... rtc/... codec/...
>
> 1) Convert pwrap to yaml is ok.
>
> 2) For the PMIC bindings, there are two option:
> - Convert mt6397.txt to mediatek,mt6397.yaml and continue to support multiple
> PMIC with only one file. IMO, the file will be hard to read because
> the supported features aren't the same for each PMIC.
>
> - Make a binding file for each PMIC ref:
> - mfd/mediatek,mt6357.yaml
> - mfd/mediatek,mt6358.yaml
> - ...
>
> 3) All PMIC daughter bindings (regulator, rtc, codec, led, ...) aren't fully
> converted yet. Refering to the two PMIC convertion options above:
> - To be clean, all daughter bindings should be converted. This is hard because
> a good understanding of each device is requiered to write efficient bindings.
> - Only daughter bindings supported by the added PMIC should be converted, that
> allows to do the task conversion step by step.
>
> In the V4 of this serie, I chose the second option.
>
> Regards,
> Alex
>
> Changes in v8:
> - Remove the 2 applied patches (v6.2-rc1) from the serie.
> - regulator: dt-bindings: Add binding schema for mt6357 regulators
> - regulator: add mt6357 regulator
> - Rebase from v6.2-tmp/soc branch, got from kernel/git/matthias.bgg/linux.git
> - Link to v7: https://lore.kernel.org/r/20221005-mt6357-support-v7-0-477e60126749@baylibre.com
>
> Changes in v7:
> - Drop mt6397 RTC schema conversion.
> - Integrate mt6357 RTC schema directly in mediatek,mt6357.yaml.
> - Fix unit address in mediatek,pwrap.yaml.
> - Link to v6: https://lore.kernel.org/r/20221005-mt6357-support-v6-0-4f589756befa@baylibre.com
>
> Changes in v6:
> - Fix typo in documentations.
> - Remove mediatek,mt6397-rtc.yaml example.
> - Align pwrap convertion with the original .txt file.
> - Remove unecessary include in the mt6357-regulator driver.
> - Link to v5: https://lore.kernel.org/r/20221005-mt6357-support-v5-0-8210d955dd3d@baylibre.com
>
> Changes in v5:
> - Add missing maintainers
> - Improve RTC binding by adding rtc.yaml ref and start-year property
> - Split the txt->yaml conversion in one commit and the addition of the
> new mt6357-rtc compatible in another commit.
> - Improve PWRAP binding:
> - clocks and clock-name have been refactored.
> - reset-names is now properly dependent to resets.
> - additionalProperties change from true to false.
> - change example for a most recent and popular SoC.
> - "allOf" part has been simplified.
> - Pass binding tests with the updated tools. Here the command:
> "make DT_CHECKER_FLAGS=-m dt_binding_check"
> - Link to v4: https://lore.kernel.org/r/20221005-mt6357-support-v4-0-5d2bb58e6087@baylibre.com
>
> Changes in v4:
> - "dt-bindings: mfd: mt6397: add binding for MT6357" has been applied
> by Lee Jones
> - All fixed regulator are now refering to fixed-regulator.yaml
> - vfe28 and vcamio18 regulators have been added
> - pwrap binding has been converted and mt8365 support has been added
> - mt6357 PMIC binding has been created
> - mt6397 RTC binding has been converted and mt6357 support has been added
> - Link to v3: https://lore.kernel.org/r/20221005-mt6357-support-v3-0-7e0bd7c315b2@baylibre.com
>
> Changes in v3:
> - To be consistent with regulator/driver.h and helper.c, shift
> variables have been removed and the mask values have been directly shifted.
> - Remove index tables and rework volt tables to use set/get helper functions.
> - Add comment to structure and function.
> - Fix Fabien Parent mail address.
> - Link to v2: https://lore.kernel.org/r/20221005-mt6357-support-v2-0-f17ba2d2d0a9@baylibre.com
>
> Changes in v2:
> - Rebase
> - Fix typo
> - Remove dependencies with https://lore.kernel.org/all/20220415153629.1817202-1-fparent@baylibre.com/
> which is no longer relevant.
>
> Previous versions:
> v1 - https://lore.kernel.org/all/20220531124959.202787-1-fparent@baylibre.com/
>
> To: Lee Jones <lee@kernel.org>
> To: Rob Herring <robh+dt@kernel.org>
> To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> To: Chen Zhong <chen.zhong@mediatek.com>
> To: Liam Girdwood <lgirdwood@gmail.com>
> To: Mark Brown <broonie@kernel.org>
> To: Fabien Parent <fabien.parent@linaro.org>
> To: Alessandro Zummo <a.zummo@towertech.it>
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>
> To: Sean Wang <sean.wang@mediatek.com>
> To: Pavel Machek <pavel@ucw.cz>
> To: Tianping Fang <tianping.fang@mediatek.com>
> To: Flora Fu <flora.fu@mediatek.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: Fabien Parent <fparent@baylibre.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: linux-rtc@vger.kernel.org
> Cc: linux-leds@vger.kernel.org
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
>
> ---
> Alexandre Mergnat (4):
> dt-bindings: soc: mediatek: convert pwrap documentation
> dt-bindings: mfd: mediatek: Add bindings for MT6357 PMIC
> arm64: dts: mt6358: change node names
> arm64: dts: mt8173: change node name
>
> Fabien Parent (2):
> dt-bindings: input: mtk-pmic-keys: add binding for MT6357 PMIC
> Input: mtk-pmic-keys: add MT6357 support
>
> .../bindings/input/mediatek,pmic-keys.yaml | 1 +
> .../devicetree/bindings/leds/leds-mt6323.txt | 2 +-
> .../devicetree/bindings/mfd/mediatek,mt6357.yaml | 111 ++++++++++++++++
> Documentation/devicetree/bindings/mfd/mt6397.txt | 2 +-
> .../bindings/soc/mediatek/mediatek,pwrap.yaml | 147 +++++++++++++++++++++
> .../devicetree/bindings/soc/mediatek/pwrap.txt | 75 -----------
> arch/arm64/boot/dts/mediatek/mt6358.dtsi | 6 +-
> arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 2 +-
> drivers/input/keyboard/mtk-pmic-keys.c | 17 +++
> 10 files changed, 283 insertions(+), 82 deletions(-)
> ---
> base-commit: e32caddfc737a96f6593754c2a08be6b8c1e0cec
> change-id: 20221005-mt6357-support-55308b82e33f
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v2] drivers/mfd: simple-mfd-i2c: Add generic compatible
From: Rob Herring @ 2023-01-19 17:51 UTC (permalink / raw)
To: Jesse Taube; +Cc: linux-kernel, linux-input, lee, lee.jones
In-Reply-To: <20221202113226.114465-1-Mr.Bossman075@gmail.com>
On Fri, Dec 02, 2022 at 06:32:26AM -0500, Jesse Taube wrote:
> Some devices may want to use this driver without having a specific
> compatible string. Add a generic compatible string to allow this.
What devices need this?
Is that no specific compatible string at all or just in the kernel?
Because the former definitely goes against DT requirements. The latter
enables the former without a schema.
>
> Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
> ---
> drivers/mfd/simple-mfd-i2c.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c
> index f4c8fc3ee463..0bda0dd9276e 100644
> --- a/drivers/mfd/simple-mfd-i2c.c
> +++ b/drivers/mfd/simple-mfd-i2c.c
> @@ -73,6 +73,7 @@ static const struct simple_mfd_data silergy_sy7636a = {
> };
>
> static const struct of_device_id simple_mfd_i2c_of_match[] = {
> + { .compatible = "simple-mfd-i2c-generic" },
Simple and generic? There is no such device. Anywhere.
This is also not documented which is how I found it (make
dt_compatible_check). But this should be reverted or dropped rather than
documented IMO.
Rob
^ permalink raw reply
* [PATCH] HID: elecom: add support for TrackBall 056E:011C
From: Takahiro Fujii @ 2023-01-19 18:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel, Takahiro Fujii
Make function buttons on ELECOM M-HT1DRBK trackball mouse work. This model
has two devices with different device IDs (010D and 011C). Both of
them misreports the number of buttons as 5 in the report descriptor, even
though they have 8 buttons. hid-elecom overwrites the report to fix them,
but supports only on 010D and does not work on 011C. This patch fixes
011C in the similar way but with specialized position parameters.
In fact, it is sufficient to rewrite only 17th byte (05 -> 08). However I
followed the existing way.
Signed-off-by: Takahiro Fujii <fujii@xaxxi.net>
---
drivers/hid/hid-elecom.c | 16 ++++++++++++++--
drivers/hid/hid-ids.h | 3 ++-
drivers/hid/hid-quirks.c | 3 ++-
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-elecom.c b/drivers/hid/hid-elecom.c
index e59e9911fc37..4fa45ee77503 100644
--- a/drivers/hid/hid-elecom.c
+++ b/drivers/hid/hid-elecom.c
@@ -12,6 +12,7 @@
* Copyright (c) 2017 Alex Manoussakis <amanou@gnu.org>
* Copyright (c) 2017 Tomasz Kramkowski <tk@the-tk.com>
* Copyright (c) 2020 YOSHIOKA Takuma <lo48576@hard-wi.red>
+ * Copyright (c) 2022 Takahiro Fujii <fujii@xaxxi.net>
*/
/*
@@ -89,7 +90,7 @@ static __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
case USB_DEVICE_ID_ELECOM_M_DT1URBK:
case USB_DEVICE_ID_ELECOM_M_DT1DRBK:
case USB_DEVICE_ID_ELECOM_M_HT1URBK:
- case USB_DEVICE_ID_ELECOM_M_HT1DRBK:
+ case USB_DEVICE_ID_ELECOM_M_HT1DRBK_010D:
/*
* Report descriptor format:
* 12: button bit count
@@ -99,6 +100,16 @@ static __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
*/
mouse_button_fixup(hdev, rdesc, *rsize, 12, 30, 14, 20, 8);
break;
+ case USB_DEVICE_ID_ELECOM_M_HT1DRBK_011C:
+ /*
+ * Report descriptor format:
+ * 22: button bit count
+ * 30: padding bit count
+ * 24: button report size
+ * 16: button usage maximum
+ */
+ mouse_button_fixup(hdev, rdesc, *rsize, 22, 30, 24, 16, 8);
+ break;
}
return rdesc;
}
@@ -112,7 +123,8 @@ static const struct hid_device_id elecom_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1URBK) },
- { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_010D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_011C) },
{ }
};
MODULE_DEVICE_TABLE(hid, elecom_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 82713ef3aaa6..86692aecf36d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -429,7 +429,8 @@
#define USB_DEVICE_ID_ELECOM_M_DT1URBK 0x00fe
#define USB_DEVICE_ID_ELECOM_M_DT1DRBK 0x00ff
#define USB_DEVICE_ID_ELECOM_M_HT1URBK 0x010c
-#define USB_DEVICE_ID_ELECOM_M_HT1DRBK 0x010d
+#define USB_DEVICE_ID_ELECOM_M_HT1DRBK_010D 0x010d
+#define USB_DEVICE_ID_ELECOM_M_HT1DRBK_011C 0x011c
#define USB_VENDOR_ID_DREAM_CHEEKY 0x1d34
#define USB_DEVICE_ID_DREAM_CHEEKY_WN 0x0004
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 0e9702c7f7d6..0e7b4e6a5b2d 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -394,7 +394,8 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1URBK) },
- { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_010D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_HT1DRBK_011C) },
#endif
#if IS_ENABLED(CONFIG_HID_ELO)
{ HID_USB_DEVICE(USB_VENDOR_ID_ELO, 0x0009) },
base-commit: 7c698440524117dca7534592db0e7f465ae4d0bb
--
2.39.0
^ permalink raw reply related
* Improvement for Joystick and Force Feedback section
From: Hiran Chaudhuri @ 2023-01-19 19:27 UTC (permalink / raw)
To: linux-input
Hello there,
I am neither developer nor committer on the linux kernel. But trying to
figure out the kernel support for my Microsoft Sidewinder Force
Feedback 2 joystick I found two things that might get improved in the
kernel documentation. Maybe someone could update it with below
information:
1)
https://www.kernel.org/doc/html/latest/input/joydev/joystick.html#microsoft-sidewinder-joysticks
The Microsoft Sidewinder Force Feedback 2 joystick is not listed at
all, but after playing around I was able to make it work. So it makes
sense to extend the list with that model.
2) https://www.kernel.org/doc/html/latest/input/ff.html#does-it-work
When trying fftest it is important to use the correct device node
/dev/input/eventXX. Unfortunately I was fiddling for a long time with
the wrong node (it may even change depending on the hot-plugging of the
USB devices).
Therefore first run the command `evtest`, which scans all
/dev/input/event* nodes and will print the devices found. From that
pick the correct file, then run `fftest`.
Also the command `ffcfstress` is a very nice test to verify the
joystick works.
Best regards
Hiran
^ permalink raw reply
* Re: [PATCH v2] drivers/mfd: simple-mfd-i2c: Add generic compatible
From: Lee Jones @ 2023-01-19 20:54 UTC (permalink / raw)
To: Rob Herring; +Cc: Jesse Taube, linux-kernel, linux-input, lee.jones
In-Reply-To: <20230119175135.GA2085792-robh@kernel.org>
On Thu, 19 Jan 2023, Rob Herring wrote:
> On Fri, Dec 02, 2022 at 06:32:26AM -0500, Jesse Taube wrote:
> > Some devices may want to use this driver without having a specific
> > compatible string. Add a generic compatible string to allow this.
>
> What devices need this?
>
> Is that no specific compatible string at all or just in the kernel?
> Because the former definitely goes against DT requirements. The latter
> enables the former without a schema.
>
> >
> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
> > ---
> > drivers/mfd/simple-mfd-i2c.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c
> > index f4c8fc3ee463..0bda0dd9276e 100644
> > --- a/drivers/mfd/simple-mfd-i2c.c
> > +++ b/drivers/mfd/simple-mfd-i2c.c
> > @@ -73,6 +73,7 @@ static const struct simple_mfd_data silergy_sy7636a = {
> > };
> >
> > static const struct of_device_id simple_mfd_i2c_of_match[] = {
> > + { .compatible = "simple-mfd-i2c-generic" },
>
> Simple and generic? There is no such device. Anywhere.
>
> This is also not documented which is how I found it (make
> dt_compatible_check). But this should be reverted or dropped rather than
> documented IMO.
I thought it would be better than having a huge list here.
Devices should *also* be allocated a specific compatible string.
$ git grep simple-mfd -- arch
--
Lee Jones [李琼斯]
^ permalink raw reply
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