* [PATCH v2 16/19] platform/x86/wireless-hotkey: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-28 19:49 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Robert Moore, Dmitry Torokhov,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Benson Leung, Tzung-Bi Shih, Corentin Chary, Luke D. Jones,
Hans de Goede, Ilpo Järvinen, Thadeu Lima de Souza Cascardo,
Pali Rohár, Matan Ziv-Av, Mattia Dongili, Azael Avalos,
Ajay Kaher, Alexey Makhalov, VMware PV-Drivers Reviewers,
Richard Cochran, Theodore Ts'o, Jason A. Donenfeld
Cc: linux-acpi, linux-kernel, acpica-devel, linux-input, netdev,
chrome-platform, platform-driver-x86, Rafael J. Wysocki,
Krzysztof Kozlowski
In-Reply-To: <20240328-b4-module-owner-acpi-v2-0-1e5552c2c69f@linaro.org>
ACPI bus core already sets the .owner, so driver does not need to.
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/platform/x86/wireless-hotkey.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platform/x86/wireless-hotkey.c b/drivers/platform/x86/wireless-hotkey.c
index 4422863f47bb..e95cdbbfb708 100644
--- a/drivers/platform/x86/wireless-hotkey.c
+++ b/drivers/platform/x86/wireless-hotkey.c
@@ -110,7 +110,6 @@ static void wl_remove(struct acpi_device *device)
static struct acpi_driver wl_driver = {
.name = "wireless-hotkey",
- .owner = THIS_MODULE,
.ids = wl_ids,
.ops = {
.add = wl_add,
--
2.34.1
^ permalink raw reply related
* [PATCH v2 17/19] ptp: vmw: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-28 19:49 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Robert Moore, Dmitry Torokhov,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Benson Leung, Tzung-Bi Shih, Corentin Chary, Luke D. Jones,
Hans de Goede, Ilpo Järvinen, Thadeu Lima de Souza Cascardo,
Pali Rohár, Matan Ziv-Av, Mattia Dongili, Azael Avalos,
Ajay Kaher, Alexey Makhalov, VMware PV-Drivers Reviewers,
Richard Cochran, Theodore Ts'o, Jason A. Donenfeld
Cc: linux-acpi, linux-kernel, acpica-devel, linux-input, netdev,
chrome-platform, platform-driver-x86, Rafael J. Wysocki,
Krzysztof Kozlowski
In-Reply-To: <20240328-b4-module-owner-acpi-v2-0-1e5552c2c69f@linaro.org>
ACPI bus core already sets the .owner, so driver does not need to.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/ptp/ptp_vmw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/ptp/ptp_vmw.c b/drivers/ptp/ptp_vmw.c
index 27c5547aa8a9..7ec90359428a 100644
--- a/drivers/ptp/ptp_vmw.c
+++ b/drivers/ptp/ptp_vmw.c
@@ -120,7 +120,6 @@ static struct acpi_driver ptp_vmw_acpi_driver = {
.add = ptp_vmw_acpi_add,
.remove = ptp_vmw_acpi_remove
},
- .owner = THIS_MODULE
};
static int __init ptp_vmw_init(void)
--
2.34.1
^ permalink raw reply related
* [PATCH v2 18/19] virt: vmgenid: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-28 19:49 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Robert Moore, Dmitry Torokhov,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Benson Leung, Tzung-Bi Shih, Corentin Chary, Luke D. Jones,
Hans de Goede, Ilpo Järvinen, Thadeu Lima de Souza Cascardo,
Pali Rohár, Matan Ziv-Av, Mattia Dongili, Azael Avalos,
Ajay Kaher, Alexey Makhalov, VMware PV-Drivers Reviewers,
Richard Cochran, Theodore Ts'o, Jason A. Donenfeld
Cc: linux-acpi, linux-kernel, acpica-devel, linux-input, netdev,
chrome-platform, platform-driver-x86, Rafael J. Wysocki,
Krzysztof Kozlowski
In-Reply-To: <20240328-b4-module-owner-acpi-v2-0-1e5552c2c69f@linaro.org>
ACPI bus core already sets the .owner, so driver does not need to.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/virt/vmgenid.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
index b67a28da4702..8f6880c3a87f 100644
--- a/drivers/virt/vmgenid.c
+++ b/drivers/virt/vmgenid.c
@@ -88,7 +88,6 @@ static const struct acpi_device_id vmgenid_ids[] = {
static struct acpi_driver vmgenid_driver = {
.name = "vmgenid",
.ids = vmgenid_ids,
- .owner = THIS_MODULE,
.ops = {
.add = vmgenid_add,
.notify = vmgenid_notify
--
2.34.1
^ permalink raw reply related
* [PATCH v2 19/19] ACPI: drop redundant owner from acpi_driver
From: Krzysztof Kozlowski @ 2024-03-28 19:49 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Robert Moore, Dmitry Torokhov,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Benson Leung, Tzung-Bi Shih, Corentin Chary, Luke D. Jones,
Hans de Goede, Ilpo Järvinen, Thadeu Lima de Souza Cascardo,
Pali Rohár, Matan Ziv-Av, Mattia Dongili, Azael Avalos,
Ajay Kaher, Alexey Makhalov, VMware PV-Drivers Reviewers,
Richard Cochran, Theodore Ts'o, Jason A. Donenfeld
Cc: linux-acpi, linux-kernel, acpica-devel, linux-input, netdev,
chrome-platform, platform-driver-x86, Rafael J. Wysocki,
Krzysztof Kozlowski
In-Reply-To: <20240328-b4-module-owner-acpi-v2-0-1e5552c2c69f@linaro.org>
Once all .owner is removed from all acpi_driver instances, drop it from
the structure.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
This depends on all previous patches. It could go next cycle, after
things got merged.
---
include/acpi/acpi_bus.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 7453be56f855..32aae3ee99ac 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -170,7 +170,6 @@ struct acpi_driver {
unsigned int flags;
struct acpi_device_ops ops;
struct device_driver drv;
- struct module *owner;
};
/*
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V1] Input: synaptics-rmi4 - Enable support for F3A by default.
From: Dmitry Torokhov @ 2024-03-28 20:13 UTC (permalink / raw)
To: Marge Yang
Cc: linux-input, linux-kernel, david.chiu, derek.cheng, sam.tsai,
vincent.huang, Jiri Kosina, Benjamin Tissoires
In-Reply-To: <20231110082148.1032629-1-marge.yang@tw.synaptics.com>
Hi Marge,
On Fri, Nov 10, 2023 at 08:21:48AM +0000, Marge Yang wrote:
> RMI4 F3A supports the touchpad GPIO function, it's designed to
> support more GPIOs and used on new touchpad. This patch will
> enable support of touchpad button.
>
> Signed-off-by: Marge Yang <marge.yang@tw.synaptics.com>
This should go to Jiri or Benjamin (CCed).
> ---
> drivers/hid/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index e11c1c8..f3a989e 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1082,6 +1082,7 @@ config HID_RMI
> select RMI4_F11
> select RMI4_F12
> select RMI4_F30
> + select RMI4_F3A
> help
> Support for Synaptics RMI4 touchpads.
> Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
> --
> 2.7.4
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 1/7] regulator: devres: add APIs for reference supplies
From: Dmitry Torokhov @ 2024-03-28 20:17 UTC (permalink / raw)
To: Mark Brown
Cc: David Lechner, Jonathan Corbet, Liam Girdwood, Jean Delvare,
Guenter Roeck, Support Opensource, Cosmin Tanislav,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Antoniu Miclaus, Greg Kroah-Hartman, linux-doc, linux-kernel,
linux-hwmon, linux-iio, linux-staging, linux-input
In-Reply-To: <043b347b-2652-4ffb-a8e0-954a89899ade@sirena.org.uk>
On Thu, Mar 28, 2024 at 06:18:32PM +0000, Mark Brown wrote:
> On Thu, Mar 28, 2024 at 11:03:23AM -0700, Dmitry Torokhov wrote:
>
> > So because we decided that we could not have devm_regulator_enable()
> > because of (IMO) contrived example of someone totally mixing up the devm
> > and non-devm APIs we now have to make more and more devm- variants
> > simply because we do not have access to the regulator structure with
> > devm_regulator_get_enable() and so all normal APIs are not available.
>
> I don't follow what you're saying here? What normal APIs are not
> available? AFAICT this has nothing to do with a devm enable, it's a
> combined operation which reports the voltage for the regulator if one is
> available which would still be being added even if it used a devm
> enable.
You can not do devm_regulator_get_enable() and then call
regulator_get_voltage(), you need a new combined API.
>
> > This is quite bad honestly. Mark, could we please reverse this
> > shortsighted decision and have normal devm_regulator_enable() operating
> > on a regulator?
>
> Nothing has changed here.
Yes, unfortunately. We could have:
reg = devm_regulator_get(...);
...
err = devm_regulator_enable(dev, reg);
...
err = regulator_get_voltage(reg);
and not multiply APIs, but we do not have devm_regulator_enable().
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RESEND PATCH v6 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support
From: Dmitry Torokhov @ 2024-03-28 20:24 UTC (permalink / raw)
To: Fenglin Wu
Cc: Dmitry Baryshkov, linux-arm-msm, linux-kernel,
krzysztof.kozlowski+dt, robh+dt, agross, andersson, Konrad Dybcio,
linux-input, quic_collinsd, quic_subbaram, quic_kamalw, jestar,
Luca Weiss
In-Reply-To: <98c668b6-7595-2c0a-ebe5-2f729d29b618@quicinc.com>
Hi Fenglin,
On Thu, Mar 28, 2024 at 02:52:32PM +0800, Fenglin Wu wrote:
>
>
> On 2023/10/1 0:17, Dmitry Torokhov wrote:
> > On Mon, Sep 25, 2023 at 10:54:45AM +0800, Fenglin Wu wrote:
> > >
> > >
> > > On 9/24/2023 3:07 AM, Dmitry Baryshkov wrote:
> > > > > +
> > > > > + switch (vib->data->hw_type) {
> > > > > + case SSBI_VIB:
> > > > > mask = SSBI_VIB_DRV_LEVEL_MASK;
> > > > > shift = SSBI_VIB_DRV_SHIFT;
> > > > > + break;
> > > > > + case SPMI_VIB:
> > > > > + mask = SPMI_VIB_DRV_LEVEL_MASK;
> > > > > + shift = SPMI_VIB_DRV_SHIFT;
> > > > > + break;
> > > > > + case SPMI_VIB_GEN2:
> > > > > + mask = SPMI_VIB_GEN2_DRV_MASK;
> > > > > + shift = SPMI_VIB_GEN2_DRV_SHIFT;
> > > > > + break;
> > > > > + default:
> > > > > + return -EINVAL;
> > > > Could you please move the switch to the previous patch? Then it would
> > > > be more obvious that you are just adding the SPMI_VIB_GEN2 here.
> > > >
> > > > Other than that LGTM.
> > >
> > > Sure, I can move the switch to the previous refactoring patch.
> >
> > Actually, the idea of having a const "reg" or "chip", etc. structure is
> > to avoid this kind of runtime checks based on hardware type and instead
> > use common computation. I believe you need to move mask and shift into
> > the chip-specific structure and avoid defining hw_type.
> >
> > Thanks.
>
> Hi Dmitry,
>
> The v7 changes have been pending for a while, I am not sure if you are still
> insist on this. As I explained, I actually did it this way in v2 and it got
> updated to this by following other comments.
>
> Can you respond and tell me if you prefer changes similar to v2? I can
> update and push v8 by following your suggestion.
>
> v7: https://lore.kernel.org/linux-arm-msm/20231108-pm8xxx-vibrator-v7-0-632c731d25a8@quicinc.com/
>
> v2: https://lore.kernel.org/linux-arm-msm/20230718062639.2339589-3-quic_fenglinw@quicinc.com/
Yes, I believe what you had in v2 was better, and Dmitry Baryshkov's
comments on v2 were also great.
You can have 2 styles of code - you have a hw type for each regulator
and then use it to do conditional logic in the code. If you do it this
way you and you need to add a new device type or model you have to go
through the code and validate all the checks. Or you could have a
structure that is defined flexibly enough to cover all existing
permutations, and you rely on the data in it to control the behavior.
You should not mix the 2 styles, as this just makes the code more
confusing.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 1/7] regulator: devres: add APIs for reference supplies
From: Mark Brown @ 2024-03-28 20:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: David Lechner, Jonathan Corbet, Liam Girdwood, Jean Delvare,
Guenter Roeck, Support Opensource, Cosmin Tanislav,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Antoniu Miclaus, Greg Kroah-Hartman, linux-doc, linux-kernel,
linux-hwmon, linux-iio, linux-staging, linux-input
In-Reply-To: <ZgXQcGlMiewRzki5@google.com>
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On Thu, Mar 28, 2024 at 01:17:52PM -0700, Dmitry Torokhov wrote:
> On Thu, Mar 28, 2024 at 06:18:32PM +0000, Mark Brown wrote:
> > I don't follow what you're saying here? What normal APIs are not
> > available? AFAICT this has nothing to do with a devm enable, it's a
> > combined operation which reports the voltage for the regulator if one is
> > available which would still be being added even if it used a devm
> > enable.
> You can not do devm_regulator_get_enable() and then call
> regulator_get_voltage(), you need a new combined API.
I think the theory here is that there are so many instances of this
reference voltage pattern that it's useful to have a helper for that
reason alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 17/19] Input: ambakmi - drop owner assignment
From: Dmitry Torokhov @ 2024-03-28 20:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Miquel Raynal, Michal Simek, Eric Auger, Alex Williamson,
linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-17-4517b091385b@linaro.org>
On Tue, Mar 26, 2024 at 09:23:47PM +0100, Krzysztof Kozlowski wrote:
> Amba bus core already sets owner, so driver does not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 6/9] Input: IMS: fix printf string overflow
From: Dmitry Torokhov @ 2024-03-28 20:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: llvm, Nathan Chancellor, Arnd Bergmann, Nick Desaulniers,
Bill Wendling, Justin Stitt, ye xingchen, linux-input,
linux-kernel
In-Reply-To: <20240326223825.4084412-7-arnd@kernel.org>
On Tue, Mar 26, 2024 at 11:38:05PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> clang warns about a string overflow in this driver
>
> drivers/input/misc/ims-pcu.c:1802:2: error: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Werror,-Wformat-truncation]
> drivers/input/misc/ims-pcu.c:1814:2: error: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Werror,-Wformat-truncation]
>
> Make the buffer a little longer to ensure it always fits.
>
> Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: PS/2 - add support for Lenovo Xiaoxin keyboard
From: Dmitry Torokhov @ 2024-03-28 20:34 UTC (permalink / raw)
To: WangYuli
Cc: rrangel, shaoyang, helugang, linux-input, linux-kernel, huangbibo
In-Reply-To: <593C1A73FB93BACE+20240326131718.20497-1-wangyuli@uniontech.com>
Hi,
On Tue, Mar 26, 2024 at 09:17:18PM +0800, WangYuli wrote:
> Modified keyboard_ids in function ps2_is_keyboard_id
> for Lenovo Xiaoxin keyboard.
>
> Signed-off-by: yuanjianye <yuanjianye@uniontech.com>
> Signed-off-by: shaoyang <shaoyang@uniontech.com>
> Reviewed-by: huangbibo <huangbibo@uniontech.com>
> Signed-off-by: helugang <helugang@uniontech.com>
> Signed-off-by: WangYuli <wangyuli@uniontech.com>
> ---
> drivers/input/serio/libps2.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
> index 6d78a1fe00c1..39d46526c56a 100644
> --- a/drivers/input/serio/libps2.c
> +++ b/drivers/input/serio/libps2.c
> @@ -189,6 +189,7 @@ bool ps2_is_keyboard_id(u8 id_byte)
> 0x5d, /* Trust keyboard */
> 0x60, /* NMB SGI keyboard, translated */
> 0x47, /* NMB SGI keyboard */
> + 0x83, /* Lenovo Xiaoxin keyboard */
Could you please tell me more about the keyboard? What ID does it use?
Majority of keyboards are using 0xab83, does your device forget to send
0xab by chance?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: adafruit-seesaw - only report buttons that changed state
From: Dmitry Torokhov @ 2024-03-28 20:37 UTC (permalink / raw)
To: Anshul Dalal; +Cc: Thomas Weißschuh, linux-input, linux-kernel
In-Reply-To: <ZZ-U_bmZpIdoYA6c@google.com>
On Wed, Jan 10, 2024 at 11:13:01PM -0800, Dmitry Torokhov wrote:
> If a button has not changed its state when we poll the device the
> driver does not need to report it. While duplicate events will be
> filtered out by the input core anyway we can do it very cheaply
> directly in the driver.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
I guess there's no objections so I am applying it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: In kernel virtual HID devices (was Future handling of complex RGB devices on Linux v3)
From: Werner Sembach @ 2024-03-28 23:52 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Hans de Goede, Lee Jones, jikos, linux-kernel, Jelle van der Waa,
Miguel Ojeda, dri-devel@lists.freedesktop.org, linux-input, ojeda,
linux-leds, Pavel Machek, Gregor Riepl
In-Reply-To: <qsfdhmss6tyk6momjh65rwpqdoxhdi3l4takqy6u5c4iactcuf@gecjc364qmsn>
Hi Benjamin,
Am 27.03.24 um 12:03 schrieb Benjamin Tissoires:
> On Mar 26 2024, Werner Sembach wrote:
>> Hi all,
>>
>> Am 26.03.24 um 16:39 schrieb Benjamin Tissoires:
>>> On Mar 26 2024, Werner Sembach wrote:
>>>> Hi all,
>>>>
>>>> Am 25.03.24 um 19:30 schrieb Hans de Goede:
>>>>
>>>> [snip]
>>>>>>> If the kernel already handles the custom protocol into generic HID, the
>>>>>>> work for userspace is not too hard because they can deal with a known
>>>>>>> protocol and can be cross-platform in their implementation.
>>>>>>>
>>>>>>> I'm mentioning that cross-platform because SDL used to rely on the
>>>>>>> input, LEDs, and other Linux peculiarities and eventually fell back on
>>>>>>> using hidraw only because it's way more easier that way.
>>>>>>>
>>>>>>> The other advantage of LampArray is that according to Microsoft's
>>>>>>> document, new devices are going to support it out of the box, so they'll
>>>>>>> be supported out of the box directly.
>>>>>>>
>>>>>>> Most of the time my stance is "do not add new kernel API, you'll regret
>>>>>>> it later". So in that case, given that we have a formally approved
>>>>>>> standard, I would suggest to use it, and consider it your API.
>>>>>> The only new UAPI would be the use_leds_uapi switch to turn on/off the backwards compatibility.
>>> I have my reserves with such a kill switch (see below).
>>>
>>>>> Actually we don't even need that. Typically there is a single HID
>>>>> driver handling both keys and the backlight, so userspace cannot
>>>>> just unbind the HID driver since then the keys stop working.
>>> I don't think Werner meant unbinding the HID driver, just a toggle to
>>> enable/disable the basic HID core processing of LampArray.
>>>
>>>>> But with a virtual LampArray HID device the only functionality
>>>>> for an in kernel HID driver would be to export a basic keyboard
>>>>> backlight control interface for simple non per key backlight control
>>>>> to integrate nicely with e.g. GNOME's backlight control.
>>>> Don't forget that in the future there will be devices that natively support
>>>> LampArray in their firmware, so for them it is the same device.
>>> Yeah, the generic LampArray support will not be able to differentiate
>>> "emulated" devices from native ones.
>>>
>>>> Regards,
>>>>
>>>> Werner
>>>>
>>>>> And then when OpenRGB wants to take over it can just unbind the HID
>>>>> driver from the HID device using existing mechanisms for that.
>>> Again no, it'll be too unpredicted.
>>>
>>>>> Hmm, I wonder if that will not also kill hidraw support though ...
>>>>> I guess getting hidraw support back might require then also manually
>>>>> binding the default HID input driver. Bentiss any input on this?
>>> To be able to talk over hidraw you need a driver to be bound, yes. But I
>>> had the impression that LampArray would be supported by default in
>>> hid-input.c, thus making this hard to remove. Having a separate driver
>>> will work, but as soon as the LampArray device will also export a
>>> multitouch touchpad, we are screwed and will have to make a choice
>>> between LampArray and touch...
>>>
>>>>> Background info: as discussed earlier in the thread Werner would like
>>>>> to have a basic driver registering a /sys/class/leds/foo::kbd_backlight/
>>>>> device, since those are automatically supported by GNOME (and others)
>>>>> and will give basic kbd backlight brightness control in the desktop
>>>>> environment. This could be a simple HID driver for
>>>>> the hid_allocate_device()-ed virtual HID device, but userspace needs
>>>>> to be able to move that out of the way when it wants to take over
>>>>> full control of the per key lighting.
>>> Do we really need to entirely unregister the led class device? Can't we
>>> snoop on the commands and get some "mean value"?
>>>
>>>>> Regards,
>>>>>
>>>>> Hans
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The control flow for the whole system would look something like this:
>>>>>>
>>>>>> - System boots
>>>>>>
>>>>>> - Kernel driver initializes keyboard (maybe stops rainbowpuke boot effects, sets brightness to a default value, or initializes a solid color)
>>>>>>
>>>>>> - systemd-backlight restores last keyboard backlight brightness
>>>>>>
>>>>>> - UPower sees sysfs leds entry and exposes it to DBus for DEs to do keyboard brightness handling
>>>>>>
>>>>>> - If the user wants more control they (auto-)start OpenRGB
>>>>>>
>>>>>> - OpenRGB disables sysfs leds entry via use_leds_uapi to prevent double control of the same device by UPower
>>>>>>
>>>>>> - OpenRGB directly interacts with hidraw device via LampArray API to give fine granular control of the backlight
>>>>>>
>>>>>> - When OpenRGB closes it should reenable the sysfs leds entry
>>> That's where your plan falls short: if OpenRGB crashes, or is killed it
>>> will not reset that bit.
>>>
>>> Next question: is OpenRGB supposed to keep the hidraw node opened all
>>> the time or not?
>> TBH I didn't look at the OpenRGB code yet and LampArray there is currently
>> only planned. I somewhat hope that until the kernel driver is ready someone
>> else already picked up implementing LampArray in OpenRGB.
>>> If it has to keep it open, we should be able to come up with a somewhat
>>> similar hack that we have with hid-steam: when the hidraw node is
>>> opened, we disable the kernel processing of LampArray. When the node is
>>> closed, we re-enable it.
>>>
>>> But that also means we have to distinguish steam/SDL from OpenRGB...
>> My first thought here also: What is if something else is reading hidraw devices?
>>
>> Especially for hidraw devices that are not just LampArray.
>>
>>> I just carefully read the LampArray spec. And it's simpler than what
>>> I expected. But the thing that caught my attention was that it's
>>> mentioned that there is no way for the host to query the current
>>> color/illumination of the LEDs when the mode is set to
>>> AutonomousMode=false. Which means that the kernel should be able to
>>> snoop into any commands sent from OpenRGB to the device, compute a mean
>>> value and update its internal state.
>>>
>>> Basically all we need is the "toggle" to put the led class in read-only
>>> mode while OpenRGB kicks in. Maybe given that we are about to snoop on
>>> the commands sent, we can detect that there is a LampArray command
>>> emitted, attach this information to the struct file * in hidraw, and
>>> then re-enable rw when that user closes the hidraw node.
>> I think a read-only mode is not part of the current led class UAPI. Also I
>> don't want to associate AutonomousMode=true with led class is used.
>> AutonomousMode=true could for example mean that it is controlled via
>> keyboard shortcuts that are directly handled in the keyboard firmware, aka a
>> case where you want neither OpenRGB nor led class make any writes to the
>> keyboard.
>>
>> Or AutonomousMode=true could mean that on a device that implements both a
>> LampArray interface as well as a proprietary legacy interface is currently
>> controlled via the proprietary legacy interface (a lot of which are
>> supported by OpenRGB).
> Then how is the kernel supposed to handle LampArrays?
>
> If you need the kernel to use a ledclass, the kernel will have to set
> the device into AutonomousMode=false. When the kernel is done
> configuring the leds, it can not switch back to AutonomousMode=true or
> its config will likely be dumped by the device.
Yes, the kernel leds class driver will set AutonomousMode=false and keep it that
way.
The userspace driver/OpenRGB will most likely do the same unless there is a
proprietary API active in AutonomousMode=true it wants to use.
>
> OpenRGB can open the device, switch it to AutonomousMode=false and we
> can rely on it to do the right things as long as it is alive. But I do
> not see how the kernel could do the same.
AutonomousMode=false ^= LampArray API is used, AutonomousMode=true something
else (if I read the HID docs correctly).
Both the kernel leds class driver as well as OpenRGB probably will interact with
these devices via the LampArray API => AutonomousMode=false.
The kernel leds class driver is the fallback as long as userspace don't want to
control the lighting. Userspace should get priority over kernel space here. So
only kernel needs to know if userspace is controlling the device, not the other
way around. So from this perspective checking in kernel if the fd is in use
could be used, but what about userspace programs that open the hidraw device for
not controlling the leds?
So imho userspace needs some way to explicitly signal it's intentions, e.g. via
a sysfs attribute.
Best regards,
Werner
>
> FWIW, I also have a couple of crazy ideas currently boiling in my head
> to "solve" that but I'd rather have a consensus on the high level side
> of things before we go too deep into the technical workaround.
>
> Cheers,
> Benjamin
>
>> Regards,
>>
>> Werner
>>
>>> Cheers,
>>> Benjamin
>>>
>>>>>> - System shutdown
>>>>>>
>>>>>> - Since OpenRGB reenables the sysfs leds entry, systemd-backlight can correctly store a brightness value for next boot
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>> Side note to self: I really need to resurrect the hidraw revoke series
>>>>>>> so we could export those hidraw node to userspace with uaccess through
>>>>>>> logind...
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Benjamin
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 8984e0b569236c8581901efce2f1f4d03cd3dec1
From: kernel test robot @ 2024-03-29 9:52 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 8984e0b569236c8581901efce2f1f4d03cd3dec1 Input: adafruit-seesaw - only report buttons that changed state
elapsed time: 728m
configs tested: 141
configs skipped: 2
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 defconfig gcc
arc randconfig-001-20240329 gcc
arc randconfig-002-20240329 gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm defconfig clang
arm randconfig-001-20240329 gcc
arm randconfig-002-20240329 clang
arm randconfig-003-20240329 clang
arm randconfig-004-20240329 gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 allyesconfig clang
arm64 defconfig gcc
arm64 randconfig-001-20240329 gcc
arm64 randconfig-002-20240329 clang
arm64 randconfig-003-20240329 clang
arm64 randconfig-004-20240329 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240329 gcc
csky randconfig-002-20240329 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240329 clang
hexagon randconfig-002-20240329 clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240329 gcc
i386 buildonly-randconfig-002-20240329 clang
i386 buildonly-randconfig-003-20240329 clang
i386 buildonly-randconfig-004-20240329 clang
i386 buildonly-randconfig-005-20240329 clang
i386 buildonly-randconfig-006-20240329 clang
i386 defconfig clang
i386 randconfig-001-20240329 clang
i386 randconfig-002-20240329 clang
i386 randconfig-003-20240329 clang
i386 randconfig-004-20240329 clang
i386 randconfig-005-20240329 clang
i386 randconfig-006-20240329 clang
i386 randconfig-011-20240329 clang
i386 randconfig-012-20240329 clang
i386 randconfig-013-20240329 gcc
i386 randconfig-014-20240329 gcc
i386 randconfig-015-20240329 gcc
i386 randconfig-016-20240329 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240329 gcc
loongarch randconfig-002-20240329 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240329 gcc
nios2 randconfig-002-20240329 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240329 gcc
parisc randconfig-002-20240329 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc randconfig-001-20240329 clang
powerpc randconfig-002-20240329 gcc
powerpc randconfig-003-20240329 clang
powerpc64 randconfig-001-20240329 gcc
powerpc64 randconfig-002-20240329 clang
powerpc64 randconfig-003-20240329 gcc
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240329 gcc
riscv randconfig-002-20240329 clang
riscv rv32_defconfig clang
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 defconfig clang
s390 randconfig-001-20240329 clang
s390 randconfig-002-20240329 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh randconfig-001-20240329 gcc
sh randconfig-002-20240329 gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240329 gcc
sparc64 randconfig-002-20240329 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um randconfig-001-20240329 clang
um randconfig-002-20240329 gcc
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 defconfig gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20240329 gcc
xtensa randconfig-002-20240329 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH AUTOSEL 6.8 04/98] Input: synaptics-rmi4 - fail probing if memory allocation for "phys" fails
From: Sasha Levin @ 2024-03-29 12:36 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kunwu Chan, Dmitry Torokhov, Sasha Levin, minipli, linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Kunwu Chan <chentao@kylinos.cn>
[ Upstream commit bc4996184d56cfaf56d3811ac2680c8a0e2af56e ]
While input core can work with input->phys set to NULL userspace might
depend on it, so better fail probing if allocation fails. The system must
be in a pretty bad shape for it to happen anyway.
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Link: https://lore.kernel.org/r/20240117073124.143636-1-chentao@kylinos.cn
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/rmi4/rmi_driver.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 42eaebb3bf5cc..ef9ea295f9e03 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -1196,7 +1196,11 @@ static int rmi_driver_probe(struct device *dev)
}
rmi_driver_set_input_params(rmi_dev, data->input);
data->input->phys = devm_kasprintf(dev, GFP_KERNEL,
- "%s/input0", dev_name(dev));
+ "%s/input0", dev_name(dev));
+ if (!data->input->phys) {
+ retval = -ENOMEM;
+ goto err;
+ }
}
retval = rmi_init_functions(data);
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 61/98] HID: input: avoid polling stylus battery on Chromebook Pompom
From: Sasha Levin @ 2024-03-29 12:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dmitry Torokhov, Jiri Kosina, Sasha Levin, jikos,
benjamin.tissoires, linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[ Upstream commit 9a5b1521e2d0d7ace70c6e5eed073babcec91409 ]
Internal touchscreen on Trogdor Pompom (AKA Dynabook Chromebook C1)
supports USI stylus. Unfortunately the HID descriptor for the stylus
interface does not contain "Stylus" physical collection, which makes
the kernel to try and pull battery information, resulting in errors.
Apply HID_BATTERY_QUIRK_AVOID_QUERY to the device.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 828a5c022c640..175b6680087e0 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -430,6 +430,7 @@
#define I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V1 0x2BED
#define I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V2 0x2BEE
#define I2C_DEVICE_ID_HP_ENVY_X360_15_EU0556NG 0x2D02
+#define I2C_DEVICE_ID_CHROMEBOOK_TROGDOR_POMPOM 0x2F81
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index c8b20d44b1472..e03d300d2bac4 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -411,6 +411,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
HID_BATTERY_QUIRK_IGNORE },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_ENVY_X360_15_EU0556NG),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_CHROMEBOOK_TROGDOR_POMPOM),
+ HID_BATTERY_QUIRK_AVOID_QUERY },
{}
};
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 76/98] input/touchscreen: imagis: Correct the maximum touch area value
From: Sasha Levin @ 2024-03-29 12:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Markuss Broks, Karel Balej, Dmitry Torokhov, Sasha Levin,
linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Markuss Broks <markuss.broks@gmail.com>
[ Upstream commit 54a62ed17a705ef1ac80ebca2b62136b19243e19 ]
As specified in downstream IST3038B driver and proved by testing,
the correct maximum reported value of touch area is 16.
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Signed-off-by: Karel Balej <balejk@matfyz.cz>
Link: https://lore.kernel.org/r/20240301164659.13240-2-karelb@gimli.ms.mff.cuni.cz
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/touchscreen/imagis.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/imagis.c b/drivers/input/touchscreen/imagis.c
index 07111ca244556..e67fd30110278 100644
--- a/drivers/input/touchscreen/imagis.c
+++ b/drivers/input/touchscreen/imagis.c
@@ -210,7 +210,7 @@ static int imagis_init_input_dev(struct imagis_ts *ts)
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_X);
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_Y);
- input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0, 16, 0, 0);
touchscreen_parse_properties(input_dev, true, &ts->prop);
if (!ts->prop.max_x || !ts->prop.max_y) {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 77/98] input/touchscreen: imagis: Add support for Imagis IST3038B
From: Sasha Levin @ 2024-03-29 12:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Markuss Broks, Karel Balej, Dmitry Torokhov, Sasha Levin,
linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Markuss Broks <markuss.broks@gmail.com>
[ Upstream commit 10ad7d7a428f7bb336c3cb226ab8aa0e6a947dac ]
Imagis IST3038B is another variant of Imagis IST3038 IC, which has
a different register interface from IST3038C (possibly firmware defined).
This should also work for IST3044B (though untested), however other
variants using this interface/protocol(IST3026, IST3032, IST3026B,
IST3032B) have a different format for coordinates, and they'd need
additional effort to be supported by this driver.
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Signed-off-by: Karel Balej <balejk@matfyz.cz>
Link: https://lore.kernel.org/r/20240301164659.13240-4-karelb@gimli.ms.mff.cuni.cz
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/touchscreen/imagis.c | 58 ++++++++++++++++++++++++------
1 file changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/input/touchscreen/imagis.c b/drivers/input/touchscreen/imagis.c
index e67fd30110278..9af8a6332ae67 100644
--- a/drivers/input/touchscreen/imagis.c
+++ b/drivers/input/touchscreen/imagis.c
@@ -11,9 +11,13 @@
#include <linux/property.h>
#include <linux/regulator/consumer.h>
+#define IST3038B_REG_STATUS 0x20
+#define IST3038B_REG_CHIPID 0x30
+#define IST3038B_WHOAMI 0x30380b
+
#define IST3038C_HIB_ACCESS (0x800B << 16)
#define IST3038C_DIRECT_ACCESS BIT(31)
-#define IST3038C_REG_CHIPID 0x40001000
+#define IST3038C_REG_CHIPID (0x40001000 | IST3038C_DIRECT_ACCESS)
#define IST3038C_REG_HIB_BASE 0x30000100
#define IST3038C_REG_TOUCH_STATUS (IST3038C_REG_HIB_BASE | IST3038C_HIB_ACCESS)
#define IST3038C_REG_TOUCH_COORD (IST3038C_REG_HIB_BASE | IST3038C_HIB_ACCESS | 0x8)
@@ -31,8 +35,17 @@
#define IST3038C_FINGER_COUNT_SHIFT 12
#define IST3038C_FINGER_STATUS_MASK GENMASK(9, 0)
+struct imagis_properties {
+ unsigned int interrupt_msg_cmd;
+ unsigned int touch_coord_cmd;
+ unsigned int whoami_cmd;
+ unsigned int whoami_val;
+ bool protocol_b;
+};
+
struct imagis_ts {
struct i2c_client *client;
+ const struct imagis_properties *tdata;
struct input_dev *input_dev;
struct touchscreen_properties prop;
struct regulator_bulk_data supplies[2];
@@ -84,8 +97,7 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
int i;
int error;
- error = imagis_i2c_read_reg(ts, IST3038C_REG_INTR_MESSAGE,
- &intr_message);
+ error = imagis_i2c_read_reg(ts, ts->tdata->interrupt_msg_cmd, &intr_message);
if (error) {
dev_err(&ts->client->dev,
"failed to read the interrupt message: %d\n", error);
@@ -104,9 +116,13 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
finger_pressed = intr_message & IST3038C_FINGER_STATUS_MASK;
for (i = 0; i < finger_count; i++) {
- error = imagis_i2c_read_reg(ts,
- IST3038C_REG_TOUCH_COORD + (i * 4),
- &finger_status);
+ if (ts->tdata->protocol_b)
+ error = imagis_i2c_read_reg(ts,
+ ts->tdata->touch_coord_cmd, &finger_status);
+ else
+ error = imagis_i2c_read_reg(ts,
+ ts->tdata->touch_coord_cmd + (i * 4),
+ &finger_status);
if (error) {
dev_err(&ts->client->dev,
"failed to read coordinates for finger %d: %d\n",
@@ -261,6 +277,12 @@ static int imagis_probe(struct i2c_client *i2c)
ts->client = i2c;
+ ts->tdata = device_get_match_data(dev);
+ if (!ts->tdata) {
+ dev_err(dev, "missing chip data\n");
+ return -EINVAL;
+ }
+
error = imagis_init_regulators(ts);
if (error) {
dev_err(dev, "regulator init error: %d\n", error);
@@ -279,15 +301,13 @@ static int imagis_probe(struct i2c_client *i2c)
return error;
}
- error = imagis_i2c_read_reg(ts,
- IST3038C_REG_CHIPID | IST3038C_DIRECT_ACCESS,
- &chip_id);
+ error = imagis_i2c_read_reg(ts, ts->tdata->whoami_cmd, &chip_id);
if (error) {
dev_err(dev, "chip ID read failure: %d\n", error);
return error;
}
- if (chip_id != IST3038C_WHOAMI) {
+ if (chip_id != ts->tdata->whoami_val) {
dev_err(dev, "unknown chip ID: 0x%x\n", chip_id);
return -EINVAL;
}
@@ -343,9 +363,25 @@ static int imagis_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(imagis_pm_ops, imagis_suspend, imagis_resume);
+static const struct imagis_properties imagis_3038b_data = {
+ .interrupt_msg_cmd = IST3038B_REG_STATUS,
+ .touch_coord_cmd = IST3038B_REG_STATUS,
+ .whoami_cmd = IST3038B_REG_CHIPID,
+ .whoami_val = IST3038B_WHOAMI,
+ .protocol_b = true,
+};
+
+static const struct imagis_properties imagis_3038c_data = {
+ .interrupt_msg_cmd = IST3038C_REG_INTR_MESSAGE,
+ .touch_coord_cmd = IST3038C_REG_TOUCH_COORD,
+ .whoami_cmd = IST3038C_REG_CHIPID,
+ .whoami_val = IST3038C_WHOAMI,
+};
+
#ifdef CONFIG_OF
static const struct of_device_id imagis_of_match[] = {
- { .compatible = "imagis,ist3038c", },
+ { .compatible = "imagis,ist3038b", .data = &imagis_3038b_data },
+ { .compatible = "imagis,ist3038c", .data = &imagis_3038c_data },
{ },
};
MODULE_DEVICE_TABLE(of, imagis_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 78/98] input/touchscreen: imagis: add support for IST3032C
From: Sasha Levin @ 2024-03-29 12:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Karel Balej, Markuss Broks, Dmitry Torokhov, Sasha Levin,
linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Karel Balej <balejk@matfyz.cz>
[ Upstream commit 90cb57a6c5717b83a110c0da720a03ee32ed255e ]
IST3032C is a touchscreen chip used for instance in the
samsung,coreprimevelte smartphone, with which this was tested. Add the
chip specific information to the driver.
Reviewed-by: Markuss Broks <markuss.broks@gmail.com>
Signed-off-by: Karel Balej <balejk@matfyz.cz>
Link: https://lore.kernel.org/r/20240301164659.13240-6-karelb@gimli.ms.mff.cuni.cz
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/touchscreen/imagis.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/input/touchscreen/imagis.c b/drivers/input/touchscreen/imagis.c
index 9af8a6332ae67..e1fafa561ee38 100644
--- a/drivers/input/touchscreen/imagis.c
+++ b/drivers/input/touchscreen/imagis.c
@@ -11,6 +11,8 @@
#include <linux/property.h>
#include <linux/regulator/consumer.h>
+#define IST3032C_WHOAMI 0x32c
+
#define IST3038B_REG_STATUS 0x20
#define IST3038B_REG_CHIPID 0x30
#define IST3038B_WHOAMI 0x30380b
@@ -363,6 +365,13 @@ static int imagis_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(imagis_pm_ops, imagis_suspend, imagis_resume);
+static const struct imagis_properties imagis_3032c_data = {
+ .interrupt_msg_cmd = IST3038C_REG_INTR_MESSAGE,
+ .touch_coord_cmd = IST3038C_REG_TOUCH_COORD,
+ .whoami_cmd = IST3038C_REG_CHIPID,
+ .whoami_val = IST3032C_WHOAMI,
+};
+
static const struct imagis_properties imagis_3038b_data = {
.interrupt_msg_cmd = IST3038B_REG_STATUS,
.touch_coord_cmd = IST3038B_REG_STATUS,
@@ -380,6 +389,7 @@ static const struct imagis_properties imagis_3038c_data = {
#ifdef CONFIG_OF
static const struct of_device_id imagis_of_match[] = {
+ { .compatible = "imagis,ist3032c", .data = &imagis_3032c_data },
{ .compatible = "imagis,ist3038b", .data = &imagis_3038b_data },
{ .compatible = "imagis,ist3038c", .data = &imagis_3038c_data },
{ },
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 86/98] Input: make input_class constant
From: Sasha Levin @ 2024-03-29 12:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ricardo B. Marliere, Greg Kroah-Hartman, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: "Ricardo B. Marliere" <ricardo@marliere.net>
[ Upstream commit a4735d40a5da96a637af6e5bf9f6ec8b9d996acd ]
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the input_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://lore.kernel.org/r/20240305-class_cleanup-input-v1-1-0c3d950c25db@marliere.net
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/input.c | 2 +-
include/linux/input.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index f71ea4fb173fd..c3fa43514dc6f 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -1918,7 +1918,7 @@ static char *input_devnode(const struct device *dev, umode_t *mode)
return kasprintf(GFP_KERNEL, "input/%s", dev_name(dev));
}
-struct class input_class = {
+const struct class input_class = {
.name = "input",
.devnode = input_devnode,
};
diff --git a/include/linux/input.h b/include/linux/input.h
index de6503c0edb8e..c22ac465254ba 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -514,7 +514,7 @@ void input_enable_softrepeat(struct input_dev *dev, int delay, int period);
bool input_device_enabled(struct input_dev *dev);
-extern struct class input_class;
+extern const struct class input_class;
/**
* struct ff_device - force-feedback part of an input device
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 87/98] Input: imagis - use FIELD_GET where applicable
From: Sasha Levin @ 2024-03-29 12:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Duje Mihanović, Dmitry Torokhov, Sasha Levin, markuss.broks,
linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Duje Mihanović <duje.mihanovic@skole.hr>
[ Upstream commit c0ca3dbd03d66c6b9e044f48720e6ab5cef37ae5 ]
Instead of manually extracting certain bits from registers with binary
ANDs and shifts, the FIELD_GET macro can be used. With this in mind, the
*_SHIFT macros can be dropped.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20240306-b4-imagis-keys-v3-1-2c429afa8420@skole.hr
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/touchscreen/imagis.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/input/touchscreen/imagis.c b/drivers/input/touchscreen/imagis.c
index e1fafa561ee38..fe65e083fd49b 100644
--- a/drivers/input/touchscreen/imagis.c
+++ b/drivers/input/touchscreen/imagis.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/bitfield.h>
#include <linux/bits.h>
#include <linux/delay.h>
#include <linux/i2c.h>
@@ -29,12 +30,9 @@
#define IST3038C_I2C_RETRY_COUNT 3
#define IST3038C_MAX_FINGER_NUM 10
#define IST3038C_X_MASK GENMASK(23, 12)
-#define IST3038C_X_SHIFT 12
#define IST3038C_Y_MASK GENMASK(11, 0)
#define IST3038C_AREA_MASK GENMASK(27, 24)
-#define IST3038C_AREA_SHIFT 24
#define IST3038C_FINGER_COUNT_MASK GENMASK(15, 12)
-#define IST3038C_FINGER_COUNT_SHIFT 12
#define IST3038C_FINGER_STATUS_MASK GENMASK(9, 0)
struct imagis_properties {
@@ -106,8 +104,7 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
goto out;
}
- finger_count = (intr_message & IST3038C_FINGER_COUNT_MASK) >>
- IST3038C_FINGER_COUNT_SHIFT;
+ finger_count = FIELD_GET(IST3038C_FINGER_COUNT_MASK, intr_message);
if (finger_count > IST3038C_MAX_FINGER_NUM) {
dev_err(&ts->client->dev,
"finger count %d is more than maximum supported\n",
@@ -115,7 +112,7 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
goto out;
}
- finger_pressed = intr_message & IST3038C_FINGER_STATUS_MASK;
+ finger_pressed = FIELD_GET(IST3038C_FINGER_STATUS_MASK, intr_message);
for (i = 0; i < finger_count; i++) {
if (ts->tdata->protocol_b)
@@ -136,12 +133,11 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER,
finger_pressed & BIT(i));
touchscreen_report_pos(ts->input_dev, &ts->prop,
- (finger_status & IST3038C_X_MASK) >>
- IST3038C_X_SHIFT,
- finger_status & IST3038C_Y_MASK, 1);
+ FIELD_GET(IST3038C_X_MASK, finger_status),
+ FIELD_GET(IST3038C_Y_MASK, finger_status),
+ true);
input_report_abs(ts->input_dev, ABS_MT_TOUCH_MAJOR,
- (finger_status & IST3038C_AREA_MASK) >>
- IST3038C_AREA_SHIFT);
+ FIELD_GET(IST3038C_AREA_MASK, finger_status));
}
input_mt_sync_frame(ts->input_dev);
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 88/98] Input: imagis - add touch key support
From: Sasha Levin @ 2024-03-29 12:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Duje Mihanović, Dmitry Torokhov, Sasha Levin, markuss.broks,
linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Duje Mihanović <duje.mihanovic@skole.hr>
[ Upstream commit 2d77f70bb7180060072b9c2406d67e4b3872af15 ]
IST3032C (and possibly some other models) has touch keys. Add support
for them to the imagis driver.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20240306-b4-imagis-keys-v3-3-2c429afa8420@skole.hr
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/touchscreen/imagis.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/imagis.c b/drivers/input/touchscreen/imagis.c
index fe65e083fd49b..074dd6c342ecb 100644
--- a/drivers/input/touchscreen/imagis.c
+++ b/drivers/input/touchscreen/imagis.c
@@ -34,6 +34,7 @@
#define IST3038C_AREA_MASK GENMASK(27, 24)
#define IST3038C_FINGER_COUNT_MASK GENMASK(15, 12)
#define IST3038C_FINGER_STATUS_MASK GENMASK(9, 0)
+#define IST3032C_KEY_STATUS_MASK GENMASK(20, 16)
struct imagis_properties {
unsigned int interrupt_msg_cmd;
@@ -41,6 +42,7 @@ struct imagis_properties {
unsigned int whoami_cmd;
unsigned int whoami_val;
bool protocol_b;
+ bool touch_keys_supported;
};
struct imagis_ts {
@@ -49,6 +51,8 @@ struct imagis_ts {
struct input_dev *input_dev;
struct touchscreen_properties prop;
struct regulator_bulk_data supplies[2];
+ u32 keycodes[5];
+ int num_keycodes;
};
static int imagis_i2c_read_reg(struct imagis_ts *ts,
@@ -93,7 +97,7 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
{
struct imagis_ts *ts = dev_id;
u32 intr_message, finger_status;
- unsigned int finger_count, finger_pressed;
+ unsigned int finger_count, finger_pressed, key_pressed;
int i;
int error;
@@ -140,6 +144,12 @@ static irqreturn_t imagis_interrupt(int irq, void *dev_id)
FIELD_GET(IST3038C_AREA_MASK, finger_status));
}
+ key_pressed = FIELD_GET(IST3032C_KEY_STATUS_MASK, intr_message);
+
+ for (int i = 0; i < ts->num_keycodes; i++)
+ input_report_key(ts->input_dev, ts->keycodes[i],
+ key_pressed & BIT(i));
+
input_mt_sync_frame(ts->input_dev);
input_sync(ts->input_dev);
@@ -225,6 +235,23 @@ static int imagis_init_input_dev(struct imagis_ts *ts)
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_X);
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_Y);
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0, 16, 0, 0);
+ if (ts->tdata->touch_keys_supported) {
+ ts->num_keycodes = of_property_read_variable_u32_array(
+ ts->client->dev.of_node, "linux,keycodes",
+ ts->keycodes, 0, ARRAY_SIZE(ts->keycodes));
+ if (ts->num_keycodes <= 0) {
+ ts->keycodes[0] = KEY_APPSELECT;
+ ts->keycodes[1] = KEY_BACK;
+ ts->num_keycodes = 2;
+ }
+
+ input_dev->keycodemax = ts->num_keycodes;
+ input_dev->keycodesize = sizeof(ts->keycodes[0]);
+ input_dev->keycode = ts->keycodes;
+ }
+
+ for (int i = 0; i < ts->num_keycodes; i++)
+ input_set_capability(input_dev, EV_KEY, ts->keycodes[i]);
touchscreen_parse_properties(input_dev, true, &ts->prop);
if (!ts->prop.max_x || !ts->prop.max_y) {
@@ -366,6 +393,7 @@ static const struct imagis_properties imagis_3032c_data = {
.touch_coord_cmd = IST3038C_REG_TOUCH_COORD,
.whoami_cmd = IST3038C_REG_CHIPID,
.whoami_val = IST3032C_WHOAMI,
+ .touch_keys_supported = true,
};
static const struct imagis_properties imagis_3038b_data = {
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 90/98] Input: allocate keycode for Display refresh rate toggle
From: Sasha Levin @ 2024-03-29 12:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Gergo Koteles, Dmitry Torokhov, Ilpo Järvinen, Sasha Levin,
linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Gergo Koteles <soyer@irl.hu>
[ Upstream commit cfeb98b95fff25c442f78a6f616c627bc48a26b7 ]
Newer Lenovo Yogas and Legions with 60Hz/90Hz displays send a wmi event
when Fn + R is pressed. This is intended for use to switch between the
two refresh rates.
Allocate a new KEY_REFRESH_RATE_TOGGLE keycode for it.
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/15a5d08c84cf4d7b820de34ebbcf8ae2502fb3ca.1710065750.git.soyer@irl.hu
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/uapi/linux/input-event-codes.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 022a520e31fc2..03edf2ccdf6c8 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -602,6 +602,7 @@
#define KEY_ALS_TOGGLE 0x230 /* Ambient light sensor */
#define KEY_ROTATE_LOCK_TOGGLE 0x231 /* Display rotation lock */
+#define KEY_REFRESH_RATE_TOGGLE 0x232 /* Display refresh rate toggle */
#define KEY_BUTTONCONFIG 0x240 /* AL Button Configuration */
#define KEY_TASKMANAGER 0x241 /* AL Task/Project Manager */
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 93/98] platform/x86: touchscreen_dmi: Add an extra entry for a variant of the Chuwi Vi8 tablet
From: Sasha Levin @ 2024-03-29 12:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alban Boyé, Ilpo Järvinen, Sasha Levin, hdegoede,
linux-input, platform-driver-x86
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Alban Boyé <alban.boye@protonmail.com>
[ Upstream commit 1266e2efb7512dbf20eac820ca2ed34de6b1c3e7 ]
Signed-off-by: Alban Boyé <alban.boye@protonmail.com>
Link: https://lore.kernel.org/r/20240227223919.11587-1-alban.boye@protonmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/platform/x86/touchscreen_dmi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index 975cf24ae359a..c6a10ec2c83f6 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -1217,6 +1217,15 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_BIOS_VERSION, "CHUWI.D86JLBNR"),
},
},
+ {
+ /* Chuwi Vi8 dual-boot (CWI506) */
+ .driver_data = (void *)&chuwi_vi8_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Insyde"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "i86"),
+ DMI_MATCH(DMI_BIOS_VERSION, "CHUWI2.D86JHBNR02"),
+ },
+ },
{
/* Chuwi Vi8 Plus (CWI519) */
.driver_data = (void *)&chuwi_vi8_plus_data,
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.8 97/98] Input: xpad - add support for Snakebyte GAMEPADs
From: Sasha Levin @ 2024-03-29 12:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Matt Scialabba, Dmitry Torokhov, Sasha Levin, vi, maxwell.nguyen,
appsforartists, swyterzone, matthias_berndt, linux-input
In-Reply-To: <20240329123919.3087149-1-sashal@kernel.org>
From: Matt Scialabba <matt.git@fastmail.fm>
[ Upstream commit 81c32343d04f8ca974681d5fb5d939d2e1f58851 ]
Add Snakebyte GAMEPAD BASE X and Snakebyte GAMEPAD RGB X to the list
of supported devices.
Signed-off-by: Matt Scialabba <matt.git@fastmail.fm>
Link: https://lore.kernel.org/r/efbfb428-06b0-48f9-8701-db291c2a9d65@app.fastmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/joystick/xpad.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 14c828adebf78..1fad51b51b0e1 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -366,6 +366,8 @@ static const struct xpad_device {
{ 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 },
{ 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x2563, 0x058d, "OneXPlayer Gamepad", 0, XTYPE_XBOX360 },
+ { 0x294b, 0x3303, "Snakebyte GAMEPAD BASE X", 0, XTYPE_XBOXONE },
+ { 0x294b, 0x3404, "Snakebyte GAMEPAD RGB X", 0, XTYPE_XBOXONE },
{ 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE },
{ 0x2dc8, 0x3106, "8BitDo Pro 2 Wired Controller", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
@@ -507,6 +509,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA controllers */
XPAD_XBOX360_VENDOR(0x2563), /* OneXPlayer Gamepad */
XPAD_XBOX360_VENDOR(0x260d), /* Dareu H101 */
+ XPAD_XBOXONE_VENDOR(0x294b), /* Snakebyte */
XPAD_XBOX360_VENDOR(0x2c22), /* Qanba Controllers */
XPAD_XBOX360_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller */
XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */
--
2.43.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