* Re: [PATCH v3 1/2] dt-bindings: input: touchscreen: Add 'goodix-hold-in-reset' property to Goodix
From: Krzysztof Kozlowski @ 2023-03-19 14:09 UTC (permalink / raw)
To: Jan Jasper de Kroon
Cc: alexandre.belloni, broonie, devicetree, dmitry.torokhov, kernel,
krzysztof.kozlowski+dt, linux-input, robh+dt
In-Reply-To: <57b22a4f-3b7e-d62d-d9a7-f9f4e052c253@gmail.com>
On 17/03/2023 11:39, Jan Jasper de Kroon wrote:
>
> Op 16-03-2023 om 20:25 schreef Krzysztof Kozlowski:
>> On 16/03/2023 16:29, Jan Jasper de Kroon wrote:
>>> Add an optional 'goodix-hold-in-reset', to the Goodix touchscreen
>>> device tree binding. When set to true, the touchscreen controller will
>>> be held in reset mode during system suspend, reducing power consumption.
>>> If not present, the property defaults to false.
>>>
>>> Signed-off-by: Jan Jasper de Kroon <jajadekroon@gmail.com>
>> Don't attach new patchsets to some other threads. It messes with our
>> tools and reading/reviewing process.
> Thank you for bringing this to my attention. I apologize for any
> inconvenience caused by attaching the patchset to the wrong threads. As a
> new user of LKML, I'm still learning the appropriate protocol for
> submitting patches. Going forward, I will ensure to attach patchsets to
> the correct threads.
>>> ---
>>> Changes from v2 to v3:
>>> - Used imperative mood instead of "This patch adds".
>>> - Dropped "I am submitting this patch to..." as it is redundant.
>>> - Removed the paragraph related to the related patch sent to the
>>> linux-input mailing list as it is not necessary.
>>> - Renamed the hold-in-reset-in-suspend function to
>>> goodix-hold-in-reset to prevent potential naming conflicts with other
>>> functions in the codebase. No functional changes were made.
>>>
>>> Changes from v1 to v2:
>>> - Updated subject prefix to match subsystem.
>>> - Added more detailed description of the change.
>>> - Fixed formatting issues in commit message.
>>> .../devicetree/bindings/input/touchscreen/goodix.yaml | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
>>> index 3d016b87c8df..197f8db9acc2 100644
>>> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
>>> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
>>> @@ -56,6 +56,13 @@ properties:
>>> touchscreen-size-y: true
>>> touchscreen-swapped-x-y: true
>>>
>>> + goodix-hold-in-reset:
>> That's not a vendor prefix... missing coma.
> Thank you for pointing out the mistake in the vendor prefix. I appreciate
> your feedback and apologize for any inconvenience caused. I wasn't aware
> of the correct vendor prefix style, but I've learned from developer Hans
> de Goede that it should be "goodix,hold-in-reset." I will make sure to
> correct this in my local branch and ensure that it is applied correctly in
> the future. Thanks again for bringing this to my attention.
>>> + description: |
>>> + When set to true, the touchscreen controller will be held in reset mode
>>> + during system suspend. This can help reduce power consumption, but may
>>> + cause the touchscreen to take longer to resume when the system is woken
>>> + up from suspend.
>> Anyway, my concerns were not answered, so to be clear:
>>
>> NAK till you answer them. Do not send new versions without answering
>> existing concerns and discussion.
> Thank you again for reviewing my patchset and providing feedback. I
> appreciate your time and effort in ensuring the quality and suitability
> of the DeviceTree.
>
> Regarding the concerns you raised about the proposed feature, I would
> like to address them directly. You mentioned that the property does not
> look suitable for Devicetree because it describes system policies that are
> not within the scope of Devicetree. While I understand your point, I
> believe this property is appropriate for Devicetree for the following
> reasons:
>
> - The property directly relates to the hardware configuration of the
> device, specifically the touchscreen controller, and is not a software
> policy.
Keeping device in reset state is not hardware configuration but driver
behavior. You did not Cc us on all patches for some reason, so it's
difficult to judge what exactly your driver is doing.
>
> - The property is required for proper system operation and is not optional
> in specific device use cases. To be more specific in the case of the
> PinePhone Original and Pro. The original commit message of the driver
> implementation in driver/input/touchscreen contained the following:
> "It consumes quite a bit of power (~40mW) during system sleep, and more
> when the screen is touched."
> Because the phone is usually kept in your pocket, so prone to a lot of
> screen touches, this is highly undesired behavior for the touchscreen in
> this case. This in my opinion makes it a mandatory property in this
> situation.
Why then the touchscree should not be kept in reset for other devices?
IOW, this should be always used. If you now say "I prefer to keep or not
keep it in reset for my device" - it's a policy.
>
> - The property is not a user-facing configuration option and is not meant
> to be changed by the end-user.
Does not matter.
>
> - The property, although in separate device specific kernel, and still
> called 'poweroff-in-suspend' is already in use on specific devices,
> including the PinePhone Original and PinePhone Pro.
I could not find such property in the kernel.
>
> However, I understand your concern that Devicetree should not be used for
> policies. To address this concern, I would like to propose the following
> changes to the property description:
> 1. Remove the sentence about reducing power consumption, as this could be
> considered a policy.
> 2. Emphasize that the property is a required hardware configuration and
> not an optional feature on certain devices.
> 3. Recommend that any changes to the property value should only be made by
> experienced system administrators and not end-users.
Please answer - why this should not be enabled always.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] input: alps: fix compatibility with -funsigned-char
From: msizanoen @ 2023-03-19 9:56 UTC (permalink / raw)
To: Pali Rohár, Dmitry Torokhov, Hans de Goede
Cc: stable, linux-input, linux-kernel
In-Reply-To: <20230318144206.14309-1-msizanoen@qtmlabs.xyz>
Patch confirmed working as expected on real hardware.
Tested-by: msizanoen <msizanoen@qtmlabs.xyz>
On 3/18/23 21:42, msizanoen wrote:
> The AlpsPS/2 code previously relied on the assumption that `char` is a
> signed type, which was true on x86 platforms (the only place where this
> driver is used) before kernel 6.2. However, on 6.2 and later, this
> assumption is broken due to the introduction of -funsigned-char as a new
> global compiler flag.
>
> Fix this by explicitly specifying the signedness of `char` when sign
> extending the values received from the device.
>
> Fixes: f3f33c677699 ("Input: alps - Rushmore and v7 resolution support")
> Cc: stable@vger.kernel.org
> Signed-off-by: msizanoen <msizanoen@qtmlabs.xyz>
> ---
> drivers/input/mouse/alps.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 989228b5a0a4..1c570d373b30 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -2294,20 +2294,20 @@ static int alps_get_v3_v7_resolution(struct psmouse *psmouse, int reg_pitch)
> if (reg < 0)
> return reg;
>
> - x_pitch = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> + x_pitch = (signed char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> x_pitch = 50 + 2 * x_pitch; /* In 0.1 mm units */
>
> - y_pitch = (char)reg >> 4; /* sign extend upper 4 bits */
> + y_pitch = (signed char)reg >> 4; /* sign extend upper 4 bits */
> y_pitch = 36 + 2 * y_pitch; /* In 0.1 mm units */
>
> reg = alps_command_mode_read_reg(psmouse, reg_pitch + 1);
> if (reg < 0)
> return reg;
>
> - x_electrode = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> + x_electrode = (signed char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> x_electrode = 17 + x_electrode;
>
> - y_electrode = (char)reg >> 4; /* sign extend upper 4 bits */
> + y_electrode = (signed char)reg >> 4; /* sign extend upper 4 bits */
> y_electrode = 13 + y_electrode;
>
> x_phys = x_pitch * (x_electrode - 1); /* In 0.1 mm units */
^ permalink raw reply
* Re: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit functions.
From: kernel test robot @ 2023-03-19 2:17 UTC (permalink / raw)
To: jingle.wu, linux-kernel, linux-input, dmitry.torokhov
Cc: oe-kbuild-all, phoenix, josh.chen, dave.wang, jingle.wu
In-Reply-To: <20230317071646.977357-1-jingle.wu@emc.com.tw>
Hi jingle.wu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus hid/for-next linus/master v6.3-rc2 next-20230317]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/jingle-wu/Input-elan_i2c-Implement-inhibit-uninhibit-functions/20230317-152004
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20230317071646.977357-1-jingle.wu%40emc.com.tw
patch subject: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit functions.
config: nios2-randconfig-m031-20230319 (https://download.01.org/0day-ci/archive/20230319/202303191024.mbwWRV3A-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 12.1.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303191024.mbwWRV3A-lkp@intel.com/
smatch warnings:
drivers/input/mouse/elan_i2c_core.c:342 elan_reactivate() warn: inconsistent indenting
vim +342 drivers/input/mouse/elan_i2c_core.c
331
332 static int elan_reactivate(struct elan_tp_data *data)
333 {
334 struct device *dev = &data->client->dev;
335 int ret;
336
337 ret = elan_set_power(data, true);
338 if (ret)
339 dev_err(dev, "failed to restore power: %d\n", ret);
340
341 ret = data->ops->sleep_control(data->client, false);
> 342 if (ret) {
343 dev_err(dev,
344 "failed to wake device up: %d\n", ret);
345 return ret;
346 }
347
348 return ret;
349 }
350
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* [PATCH] Input: iqs62x-keys - Suppress duplicated error message in .remove()
From: Uwe Kleine-König @ 2023-03-18 22:51 UTC (permalink / raw)
To: Dmitry Torokhov, Mattijs Korpershoek, Jeff LaBundy; +Cc: linux-input, kernel
If a platform driver's remove callback returns non-zero the driver core
emits an error message. In such a case however iqs62x_keys_remove()
already issued a (better) message. So return zero to suppress the
generic message.
This patch has no other side effects as platform_remove() ignores the
return value of .remove() after the warning.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/input/keyboard/iqs62x-keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/iqs62x-keys.c b/drivers/input/keyboard/iqs62x-keys.c
index db793a550c25..02ceebad7bda 100644
--- a/drivers/input/keyboard/iqs62x-keys.c
+++ b/drivers/input/keyboard/iqs62x-keys.c
@@ -320,7 +320,7 @@ static int iqs62x_keys_remove(struct platform_device *pdev)
if (ret)
dev_err(&pdev->dev, "Failed to unregister notifier: %d\n", ret);
- return ret;
+ return 0;
}
static struct platform_driver iqs62x_keys_platform_driver = {
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v3] Fix incorrectly applied patch for MAP_PROFILE_BUTTON
From: Andi Shyti @ 2023-03-18 18:00 UTC (permalink / raw)
To: Matthias Benkmann
Cc: linux-input, dmitry.torokhov, Nate Yocom, hadess,
benjamin.tissoires, linux-kernel, Pavel Rojtberg
In-Reply-To: <20230318162106.0aef4ba5@ninja>
On Sat, Mar 18, 2023 at 04:21:06PM +0100, Matthias Benkmann wrote:
> When the linked patch was applied,
Please refer to the patch as "commit fff1011a26d6 ("Input: xpad -
add X-Box Adaptive Profile button")" and not as "linked patch".
> one hunk ended up in the wrong function. This patch moves it to where
> it probably belongs.
probably? We need to be sure here :)
Besides, please, use the imperative form, not "this patch moves"
but "move what where", please be more specific.
Andi
> Link: https://lore.kernel.org/all/20220908173930.28940-6-nate@yocom.org/
> Fixes: fff1011a26d6 (Input: xpad - add X-Box Adaptive Profile button)
> Signed-off-by: Matthias Benkmann <matthias.benkmann@gmail.com>
>
> ---
> drivers/input/joystick/xpad.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index f642ec8e92dd..29131f1a2f06 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -781,9 +781,6 @@ static void xpad_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char *d
> input_report_key(dev, BTN_C, data[8]);
> input_report_key(dev, BTN_Z, data[9]);
>
> - /* Profile button has a value of 0-3, so it is reported as an axis */
> - if (xpad->mapping & MAP_PROFILE_BUTTON)
> - input_report_abs(dev, ABS_PROFILE, data[34]);
>
> input_sync(dev);
> }
> @@ -1061,6 +1058,10 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
> (__u16) le16_to_cpup((__le16 *)(data + 8)));
> }
>
> + /* Profile button has a value of 0-3, so it is reported as an axis */
> + if (xpad->mapping & MAP_PROFILE_BUTTON)
> + input_report_abs(dev, ABS_PROFILE, data[34]);
> +
> /* paddle handling */
> /* based on SDL's SDL_hidapi_xboxone.c */
> if (xpad->mapping & MAP_PADDLES) {
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] Input: focaltech - use explicitly signed char type
From: Hans de Goede @ 2023-03-18 16:43 UTC (permalink / raw)
To: Jason A. Donenfeld, dmitry.torokhov, linux-input, linux-kernel,
regressions
Cc: stable, regressions, barry
In-Reply-To: <20230318133010.1285202-1-Jason@zx2c4.com>
Hi,
On 3/18/23 14:30, Jason A. Donenfeld wrote:
> The recent change of -funsigned-char causes additions of negative
> numbers to become additions of large positive numbers, leading to wrong
> calculations of mouse movement. Change these casts to be explictly
> signed, to take into account negative offsets.
>
> Fixes: 3bc753c06dd0 ("kbuild: treat char as always unsigned")
> Cc: stable@vger.kernel.org
> Cc: regressions@leemhuis.info
> Cc: barry@messagefor.me.uk
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> Wrote this patch from my phone, untested, so it would be nice if
> somebody with hardware could confirm it works.
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
>
> drivers/input/mouse/focaltech.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/focaltech.c b/drivers/input/mouse/focaltech.c
> index 6fd5fff0cbff..3dbad0d8e8c9 100644
> --- a/drivers/input/mouse/focaltech.c
> +++ b/drivers/input/mouse/focaltech.c
> @@ -202,8 +202,8 @@ static void focaltech_process_rel_packet(struct psmouse *psmouse,
> state->pressed = packet[0] >> 7;
> finger1 = ((packet[0] >> 4) & 0x7) - 1;
> if (finger1 < FOC_MAX_FINGERS) {
> - state->fingers[finger1].x += (char)packet[1];
> - state->fingers[finger1].y += (char)packet[2];
> + state->fingers[finger1].x += (signed char)packet[1];
> + state->fingers[finger1].y += (signed char)packet[2];
> } else {
> psmouse_err(psmouse, "First finger in rel packet invalid: %d\n",
> finger1);
> @@ -218,8 +218,8 @@ static void focaltech_process_rel_packet(struct psmouse *psmouse,
> */
> finger2 = ((packet[3] >> 4) & 0x7) - 1;
> if (finger2 < FOC_MAX_FINGERS) {
> - state->fingers[finger2].x += (char)packet[4];
> - state->fingers[finger2].y += (char)packet[5];
> + state->fingers[finger2].x += (signed char)packet[4];
> + state->fingers[finger2].y += (signed char)packet[5];
> }
> }
>
^ permalink raw reply
* Re: [PATCH] input: alps: fix compatibility with -funsigned-char
From: Hans de Goede @ 2023-03-18 16:25 UTC (permalink / raw)
To: msizanoen, Pali Rohár, Dmitry Torokhov
Cc: stable, linux-input, linux-kernel
In-Reply-To: <20230318144206.14309-1-msizanoen@qtmlabs.xyz>
Hi,
On 3/18/23 15:42, msizanoen wrote:
> The AlpsPS/2 code previously relied on the assumption that `char` is a
> signed type, which was true on x86 platforms (the only place where this
> driver is used) before kernel 6.2. However, on 6.2 and later, this
> assumption is broken due to the introduction of -funsigned-char as a new
> global compiler flag.
>
> Fix this by explicitly specifying the signedness of `char` when sign
> extending the values received from the device.
>
> Fixes: f3f33c677699 ("Input: alps - Rushmore and v7 resolution support")
> Cc: stable@vger.kernel.org
> Signed-off-by: msizanoen <msizanoen@qtmlabs.xyz>
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> drivers/input/mouse/alps.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 989228b5a0a4..1c570d373b30 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -2294,20 +2294,20 @@ static int alps_get_v3_v7_resolution(struct psmouse *psmouse, int reg_pitch)
> if (reg < 0)
> return reg;
>
> - x_pitch = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> + x_pitch = (signed char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> x_pitch = 50 + 2 * x_pitch; /* In 0.1 mm units */
>
> - y_pitch = (char)reg >> 4; /* sign extend upper 4 bits */
> + y_pitch = (signed char)reg >> 4; /* sign extend upper 4 bits */
> y_pitch = 36 + 2 * y_pitch; /* In 0.1 mm units */
>
> reg = alps_command_mode_read_reg(psmouse, reg_pitch + 1);
> if (reg < 0)
> return reg;
>
> - x_electrode = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> + x_electrode = (signed char)(reg << 4) >> 4; /* sign extend lower 4 bits */
> x_electrode = 17 + x_electrode;
>
> - y_electrode = (char)reg >> 4; /* sign extend upper 4 bits */
> + y_electrode = (signed char)reg >> 4; /* sign extend upper 4 bits */
> y_electrode = 13 + y_electrode;
>
> x_phys = x_pitch * (x_electrode - 1); /* In 0.1 mm units */
^ permalink raw reply
* Re: [regression] focaltech touchpad driver misbehaves due to "kbuild: treat char as always unsigned"
From: msizanoen @ 2023-03-18 15:54 UTC (permalink / raw)
To: Linux regressions mailing list, Jason A. Donenfeld,
Dmitry Torokhov
Cc: LKML, open list:HID CORE LAYER, barry
In-Reply-To: <e20db4c4-b2a8-bc88-232f-d1213733d20c@leemhuis.info>
[-- Attachment #1: Type: text/plain, Size: 4099 bytes --]
Seems like the AlpsPS/2 driver also got hit with the exact same issue:
https://gitlab.freedesktop.org/libinput/libinput/-/issues/871#note_1829296
I submitted a patch for that:
https://lore.kernel.org/linux-input/20230318144206.14309-1-msizanoen@qtmlabs.xyz/
On 3/18/23 19:08, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker.
>
> I noticed a regression report in bugzilla.kernel.org. Jason, apparently
> it's caused by a change of yours (3bc753c06dd0 ("kbuild: treat char as
> always unsigned")), which apparently caused a problem in
> drivers/input/mouse/focaltech.c to surface. Someone provided a patch
> already to fix it here: https://bugs.archlinux.org/task/77733?getfile=22498
>
> Back to the bug. As many (most?) kernel developer don't keep an eye on
> bugzilla, I decided to forward it by mail. Quoting from
> https://bugzilla.kernel.org/show_bug.cgi?id=217211 :
>
>> Barry 2023-03-17 13:51:10 UTC
>>
>> Created attachment 303972 [details] Kernel bisect result
>>
>> O/S: Archlinux.
>>
>> On any kernel release from 6.2 onwards I have found that the touchpad
>> doesn't respond to multi finger touches properly. The pad works fine for
>> single finger movement and single finger tap to click. If I click and
>> hold the pad button and then use another finger to move such as for text
>> selection, drag and drop, moving or resizing a window etc. Or if I try
>> to use 2 finger scrolling then the mouse pointer jumps to the top or
>> right or into the top right of the screen. All of this functionality
>> worked as expected up to kernel 6.1.19.
>>
>> I have bisected the kernel and got the attached result.
>>
>>
>> I have checked out kernel 6.2.6 and removed the `-funsigned-char` from
>> the Makefile. Kernel 6.2.6 built with the modified Makefile restores the
>> correct functionality. I believe the touchpad uses the psmouse driver so
>> maybe the new build option has broken this driver.>
>> I have bisected the kernel and got the attached result.
>>
>>
>> I have checked out kernel 6.2.6 and removed the `-funsigned-char`
>> from the Makefile. Kernel 6.2.6 built with the modified Makefile
>> restores the correct functionality. I believe the touchpad uses the
>> psmouse driver so maybe the new build option has broken this driver.
>>
>> [...]
>>
>> barry@messagefor.me.uk 2023-03-18 11:49:27 UTC
>>
>> Hi. If you check this link which is my report of the same bug on the
>> arch bug tracker there is a patch attached which fixes the issue.
>>
>> https://bugs.archlinux.org/task/77733#comment216336
> 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: 3bc753c06dd0
> https://bugzilla.kernel.org/show_bug.cgi?id=217211
> #regzbot title: kbuild/input: focaltech touchpad driver misbehaves due
> to a checke how to treat char
> #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.
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4494 bytes --]
^ permalink raw reply
* [PATCH v3] Fix incorrectly applied patch for MAP_PROFILE_BUTTON
From: Matthias Benkmann @ 2023-03-18 15:21 UTC (permalink / raw)
To: linux-input
Cc: dmitry.torokhov, Nate Yocom, hadess, benjamin.tissoires,
linux-kernel, Pavel Rojtberg
In-Reply-To: <CAK4gqCCk7ipRbZ=LM8Nsj+nE2S6v6QN39ziYSr3d2NmVMHULYg@mail.gmail.com>
When the linked patch was applied,
one hunk ended up in the wrong function. This patch moves it to where
it probably belongs.
Link: https://lore.kernel.org/all/20220908173930.28940-6-nate@yocom.org/
Fixes: fff1011a26d6 (Input: xpad - add X-Box Adaptive Profile button)
Signed-off-by: Matthias Benkmann <matthias.benkmann@gmail.com>
---
drivers/input/joystick/xpad.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index f642ec8e92dd..29131f1a2f06 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -781,9 +781,6 @@ static void xpad_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char *d
input_report_key(dev, BTN_C, data[8]);
input_report_key(dev, BTN_Z, data[9]);
- /* Profile button has a value of 0-3, so it is reported as an axis */
- if (xpad->mapping & MAP_PROFILE_BUTTON)
- input_report_abs(dev, ABS_PROFILE, data[34]);
input_sync(dev);
}
@@ -1061,6 +1058,10 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
(__u16) le16_to_cpup((__le16 *)(data + 8)));
}
+ /* Profile button has a value of 0-3, so it is reported as an axis */
+ if (xpad->mapping & MAP_PROFILE_BUTTON)
+ input_report_abs(dev, ABS_PROFILE, data[34]);
+
/* paddle handling */
/* based on SDL's SDL_hidapi_xboxone.c */
if (xpad->mapping & MAP_PADDLES) {
--
2.25.1
^ permalink raw reply related
* [PATCH] input: alps: fix compatibility with -funsigned-char
From: msizanoen @ 2023-03-18 14:42 UTC (permalink / raw)
To: Pali Rohár, Dmitry Torokhov, Hans de Goede
Cc: msizanoen, stable, linux-input, linux-kernel
The AlpsPS/2 code previously relied on the assumption that `char` is a
signed type, which was true on x86 platforms (the only place where this
driver is used) before kernel 6.2. However, on 6.2 and later, this
assumption is broken due to the introduction of -funsigned-char as a new
global compiler flag.
Fix this by explicitly specifying the signedness of `char` when sign
extending the values received from the device.
Fixes: f3f33c677699 ("Input: alps - Rushmore and v7 resolution support")
Cc: stable@vger.kernel.org
Signed-off-by: msizanoen <msizanoen@qtmlabs.xyz>
---
drivers/input/mouse/alps.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 989228b5a0a4..1c570d373b30 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2294,20 +2294,20 @@ static int alps_get_v3_v7_resolution(struct psmouse *psmouse, int reg_pitch)
if (reg < 0)
return reg;
- x_pitch = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
+ x_pitch = (signed char)(reg << 4) >> 4; /* sign extend lower 4 bits */
x_pitch = 50 + 2 * x_pitch; /* In 0.1 mm units */
- y_pitch = (char)reg >> 4; /* sign extend upper 4 bits */
+ y_pitch = (signed char)reg >> 4; /* sign extend upper 4 bits */
y_pitch = 36 + 2 * y_pitch; /* In 0.1 mm units */
reg = alps_command_mode_read_reg(psmouse, reg_pitch + 1);
if (reg < 0)
return reg;
- x_electrode = (char)(reg << 4) >> 4; /* sign extend lower 4 bits */
+ x_electrode = (signed char)(reg << 4) >> 4; /* sign extend lower 4 bits */
x_electrode = 17 + x_electrode;
- y_electrode = (char)reg >> 4; /* sign extend upper 4 bits */
+ y_electrode = (signed char)reg >> 4; /* sign extend upper 4 bits */
y_electrode = 13 + y_electrode;
x_phys = x_pitch * (x_electrode - 1); /* In 0.1 mm units */
--
2.39.2
^ permalink raw reply related
* [PATCH v2] Fix incorrectly applied patch for MAP_PROFILE_BUTTON
From: Matthias Benkmann @ 2023-03-18 14:41 UTC (permalink / raw)
To: linux-input
Cc: dmitry.torokhov, Nate Yocom, hadess, benjamin.tissoires,
linux-kernel, Pavel Rojtberg
When the linked patch was applied,
one hunk ended up in the wrong function. This patch moves it to where
it probably belongs.
Link: https://lore.kernel.org/all/20220908173930.28940-6-nate@yocom.org/
Fixes: fff1011a26d6 (Input: xpad - add X-Box Adaptive Profile button)
Signed-off-by: Matthias Benkmann <matthias.benkmann@gmail.com>
---
drivers/input/joystick/xpad.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index f642ec8e92dd..29131f1a2f06 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -781,9 +781,6 @@ static void xpad_process_packet(struct usb_xpad
*xpad, u16 cmd, unsigned char *d
input_report_key(dev, BTN_C, data[8]);
input_report_key(dev, BTN_Z, data[9]);
- /* Profile button has a value of 0-3, so it is reported as an axis */
- if (xpad->mapping & MAP_PROFILE_BUTTON)
- input_report_abs(dev, ABS_PROFILE, data[34]);
input_sync(dev);
}
@@ -1061,6 +1058,10 @@ static void xpadone_process_packet(struct
usb_xpad *xpad, u16 cmd, unsigned char
(__u16) le16_to_cpup((__le16
*)(data + 8)));
}
+ /* Profile button has a value of 0-3, so it is
reported as an axis */
+ if (xpad->mapping & MAP_PROFILE_BUTTON)
+ input_report_abs(dev, ABS_PROFILE, data[34]);
+
/* paddle handling */
/* based on SDL's SDL_hidapi_xboxone.c */
if (xpad->mapping & MAP_PADDLES) {
--
2.25.1
^ permalink raw reply related
* [PATCH] Input: focaltech - use explicitly signed char type
From: Jason A. Donenfeld @ 2023-03-18 13:30 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel, regressions
Cc: Jason A. Donenfeld, stable, regressions, barry
In-Reply-To: <e20db4c4-b2a8-bc88-232f-d1213733d20c@leemhuis.info>
The recent change of -funsigned-char causes additions of negative
numbers to become additions of large positive numbers, leading to wrong
calculations of mouse movement. Change these casts to be explictly
signed, to take into account negative offsets.
Fixes: 3bc753c06dd0 ("kbuild: treat char as always unsigned")
Cc: stable@vger.kernel.org
Cc: regressions@leemhuis.info
Cc: barry@messagefor.me.uk
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
Wrote this patch from my phone, untested, so it would be nice if
somebody with hardware could confirm it works.
drivers/input/mouse/focaltech.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/focaltech.c b/drivers/input/mouse/focaltech.c
index 6fd5fff0cbff..3dbad0d8e8c9 100644
--- a/drivers/input/mouse/focaltech.c
+++ b/drivers/input/mouse/focaltech.c
@@ -202,8 +202,8 @@ static void focaltech_process_rel_packet(struct psmouse *psmouse,
state->pressed = packet[0] >> 7;
finger1 = ((packet[0] >> 4) & 0x7) - 1;
if (finger1 < FOC_MAX_FINGERS) {
- state->fingers[finger1].x += (char)packet[1];
- state->fingers[finger1].y += (char)packet[2];
+ state->fingers[finger1].x += (signed char)packet[1];
+ state->fingers[finger1].y += (signed char)packet[2];
} else {
psmouse_err(psmouse, "First finger in rel packet invalid: %d\n",
finger1);
@@ -218,8 +218,8 @@ static void focaltech_process_rel_packet(struct psmouse *psmouse,
*/
finger2 = ((packet[3] >> 4) & 0x7) - 1;
if (finger2 < FOC_MAX_FINGERS) {
- state->fingers[finger2].x += (char)packet[4];
- state->fingers[finger2].y += (char)packet[5];
+ state->fingers[finger2].x += (signed char)packet[4];
+ state->fingers[finger2].y += (signed char)packet[5];
}
}
--
2.40.0
^ permalink raw reply related
* [regression] focaltech touchpad driver misbehaves due to "kbuild: treat char as always unsigned"
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-03-18 12:08 UTC (permalink / raw)
To: Jason A. Donenfeld, Dmitry Torokhov
Cc: Linux kernel regressions list, LKML, open list:HID CORE LAYER,
barry
Hi, Thorsten here, the Linux kernel's regression tracker.
I noticed a regression report in bugzilla.kernel.org. Jason, apparently
it's caused by a change of yours (3bc753c06dd0 ("kbuild: treat char as
always unsigned")), which apparently caused a problem in
drivers/input/mouse/focaltech.c to surface. Someone provided a patch
already to fix it here: https://bugs.archlinux.org/task/77733?getfile=22498
Back to the bug. As many (most?) kernel developer don't keep an eye on
bugzilla, I decided to forward it by mail. Quoting from
https://bugzilla.kernel.org/show_bug.cgi?id=217211 :
> Barry 2023-03-17 13:51:10 UTC
>
> Created attachment 303972 [details] Kernel bisect result
>
> O/S: Archlinux.
>
> On any kernel release from 6.2 onwards I have found that the touchpad
> doesn't respond to multi finger touches properly. The pad works fine for
> single finger movement and single finger tap to click. If I click and
> hold the pad button and then use another finger to move such as for text
> selection, drag and drop, moving or resizing a window etc. Or if I try
> to use 2 finger scrolling then the mouse pointer jumps to the top or
> right or into the top right of the screen. All of this functionality
> worked as expected up to kernel 6.1.19.
>
> I have bisected the kernel and got the attached result.
>
>
> I have checked out kernel 6.2.6 and removed the `-funsigned-char` from
> the Makefile. Kernel 6.2.6 built with the modified Makefile restores the
> correct functionality. I believe the touchpad uses the psmouse driver so
> maybe the new build option has broken this driver.>
> I have bisected the kernel and got the attached result.
>
>
> I have checked out kernel 6.2.6 and removed the `-funsigned-char`
> from the Makefile. Kernel 6.2.6 built with the modified Makefile
> restores the correct functionality. I believe the touchpad uses the
> psmouse driver so maybe the new build option has broken this driver.
>
> [...]
>
> barry@messagefor.me.uk 2023-03-18 11:49:27 UTC
>
> Hi. If you check this link which is my report of the same bug on the
> arch bug tracker there is a patch attached which fixes the issue.
>
> https://bugs.archlinux.org/task/77733#comment216336
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: 3bc753c06dd0
https://bugzilla.kernel.org/show_bug.cgi?id=217211
#regzbot title: kbuild/input: focaltech touchpad driver misbehaves due
to a checke how to treat char
#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
* [dtor-input:for-linus] BUILD SUCCESS 8a0432bab6ea3203d220785da7ab3c7677f70ecb
From: kernel test robot @ 2023-03-18 8:42 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 8a0432bab6ea3203d220785da7ab3c7677f70ecb Input: goodix - add Lenovo Yoga Book X90F to nine_bytes_report DMI table
elapsed time: 1245m
configs tested: 234
configs skipped: 11
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r001-20230313 gcc
alpha randconfig-r011-20230313 gcc
alpha randconfig-r016-20230312 gcc
alpha randconfig-r016-20230313 gcc
alpha randconfig-r021-20230312 gcc
alpha randconfig-r025-20230312 gcc
alpha randconfig-r026-20230313 gcc
alpha randconfig-r034-20230313 gcc
arc allyesconfig gcc
arc axs103_smp_defconfig gcc
arc buildonly-randconfig-r004-20230312 gcc
arc defconfig gcc
arc randconfig-r006-20230313 gcc
arc randconfig-r012-20230312 gcc
arc randconfig-r014-20230312 gcc
arc randconfig-r021-20230312 gcc
arc randconfig-r022-20230313 gcc
arc randconfig-r026-20230312 gcc
arc randconfig-r032-20230312 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm buildonly-randconfig-r001-20230313 gcc
arm buildonly-randconfig-r005-20230313 gcc
arm defconfig gcc
arm randconfig-c002-20230312 gcc
arm randconfig-r013-20230313 gcc
arm randconfig-r025-20230313 gcc
arm randconfig-r026-20230313 gcc
arm randconfig-r036-20230312 gcc
arm randconfig-r046-20230312 clang
arm64 allyesconfig gcc
arm64 buildonly-randconfig-r004-20230313 gcc
arm64 buildonly-randconfig-r006-20230313 gcc
arm64 defconfig gcc
arm64 randconfig-r005-20230313 gcc
arm64 randconfig-r015-20230312 gcc
csky defconfig gcc
csky randconfig-r002-20230312 gcc
csky randconfig-r002-20230313 gcc
csky randconfig-r026-20230312 gcc
csky randconfig-r033-20230313 gcc
csky randconfig-r036-20230312 gcc
hexagon buildonly-randconfig-r004-20230312 clang
hexagon buildonly-randconfig-r005-20230313 clang
hexagon randconfig-r015-20230312 clang
hexagon randconfig-r041-20230312 clang
hexagon randconfig-r041-20230313 clang
hexagon randconfig-r045-20230312 clang
hexagon randconfig-r045-20230313 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r002-20230313 gcc
i386 buildonly-randconfig-r003-20230313 gcc
i386 debian-10.3-func gcc
i386 debian-10.3-kselftests gcc
i386 debian-10.3-kunit gcc
i386 debian-10.3-kvm gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230313 gcc
i386 randconfig-a002-20230313 gcc
i386 randconfig-a002 clang
i386 randconfig-a003-20230313 gcc
i386 randconfig-a004-20230313 gcc
i386 randconfig-a004 clang
i386 randconfig-a005-20230313 gcc
i386 randconfig-a006-20230313 gcc
i386 randconfig-a006 clang
i386 randconfig-a011-20230313 clang
i386 randconfig-a012-20230313 clang
i386 randconfig-a013-20230313 clang
i386 randconfig-a014-20230313 clang
i386 randconfig-a015-20230313 clang
i386 randconfig-a016-20230313 clang
i386 randconfig-c001 gcc
i386 randconfig-r004-20230313 gcc
i386 randconfig-r032-20230313 gcc
i386 randconfig-r035-20230313 gcc
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r005-20230312 gcc
ia64 defconfig gcc
ia64 randconfig-r013-20230313 gcc
ia64 randconfig-r031-20230312 gcc
ia64 randconfig-r032-20230313 gcc
ia64 randconfig-r036-20230313 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r002-20230313 gcc
loongarch defconfig gcc
loongarch randconfig-r021-20230313 gcc
loongarch randconfig-r022-20230312 gcc
loongarch randconfig-r026-20230312 gcc
loongarch randconfig-r031-20230313 gcc
m68k allmodconfig gcc
m68k defconfig gcc
m68k randconfig-r004-20230312 gcc
m68k randconfig-r005-20230312 gcc
m68k randconfig-r011-20230312 gcc
m68k randconfig-r011-20230313 gcc
m68k randconfig-r013-20230312 gcc
m68k randconfig-r025-20230313 gcc
m68k randconfig-r031-20230313 gcc
m68k randconfig-r033-20230313 gcc
m68k randconfig-r034-20230313 gcc
microblaze buildonly-randconfig-r002-20230312 gcc
microblaze buildonly-randconfig-r006-20230312 gcc
microblaze randconfig-r006-20230312 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips malta_defconfig clang
mips randconfig-r001-20230312 gcc
mips randconfig-r003-20230312 gcc
mips randconfig-r013-20230312 clang
nios2 buildonly-randconfig-r001-20230313 gcc
nios2 buildonly-randconfig-r003-20230312 gcc
nios2 defconfig gcc
nios2 randconfig-r005-20230312 gcc
nios2 randconfig-r013-20230312 gcc
nios2 randconfig-r023-20230313 gcc
nios2 randconfig-r026-20230312 gcc
nios2 randconfig-r032-20230312 gcc
openrisc buildonly-randconfig-r001-20230312 gcc
openrisc buildonly-randconfig-r003-20230312 gcc
openrisc buildonly-randconfig-r005-20230313 gcc
openrisc randconfig-r015-20230312 gcc
openrisc randconfig-r023-20230312 gcc
openrisc randconfig-r035-20230313 gcc
parisc buildonly-randconfig-r006-20230312 gcc
parisc defconfig gcc
parisc randconfig-r004-20230313 gcc
parisc randconfig-r005-20230313 gcc
parisc randconfig-r013-20230312 gcc
parisc randconfig-r014-20230313 gcc
parisc randconfig-r026-20230313 gcc
parisc randconfig-r033-20230312 gcc
parisc randconfig-r034-20230313 gcc
parisc randconfig-r036-20230313 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r001-20230313 clang
powerpc buildonly-randconfig-r004-20230313 clang
powerpc kilauea_defconfig clang
powerpc motionpro_defconfig gcc
powerpc randconfig-r011-20230312 gcc
powerpc randconfig-r012-20230312 gcc
powerpc randconfig-r023-20230312 gcc
powerpc randconfig-r036-20230313 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r001-20230312 gcc
riscv defconfig gcc
riscv randconfig-r003-20230313 gcc
riscv randconfig-r004-20230313 gcc
riscv randconfig-r005-20230318 clang
riscv randconfig-r012-20230312 gcc
riscv randconfig-r024-20230312 gcc
riscv randconfig-r031-20230313 gcc
riscv randconfig-r042-20230313 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r016-20230312 gcc
s390 randconfig-r021-20230312 gcc
s390 randconfig-r025-20230312 gcc
s390 randconfig-r044-20230313 clang
sh allmodconfig gcc
sh buildonly-randconfig-r006-20230313 gcc
sh migor_defconfig gcc
sh randconfig-r015-20230312 gcc
sh randconfig-r016-20230312 gcc
sh randconfig-r021-20230313 gcc
sh randconfig-r023-20230313 gcc
sh randconfig-r035-20230312 gcc
sh se7712_defconfig gcc
sparc defconfig gcc
sparc randconfig-r002-20230313 gcc
sparc randconfig-r015-20230313 gcc
sparc randconfig-r016-20230313 gcc
sparc randconfig-r024-20230312 gcc
sparc randconfig-r035-20230313 gcc
sparc64 randconfig-r001-20230313 gcc
sparc64 randconfig-r004-20230312 gcc
sparc64 randconfig-r006-20230313 gcc
sparc64 randconfig-r013-20230312 gcc
sparc64 randconfig-r014-20230312 gcc
sparc64 randconfig-r014-20230313 gcc
sparc64 randconfig-r024-20230312 gcc
sparc64 randconfig-r025-20230312 gcc
sparc64 randconfig-r025-20230313 gcc
sparc64 randconfig-r034-20230312 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230313 gcc
x86_64 randconfig-a002-20230313 gcc
x86_64 randconfig-a003-20230313 gcc
x86_64 randconfig-a004-20230313 gcc
x86_64 randconfig-a005-20230313 gcc
x86_64 randconfig-a006-20230313 gcc
x86_64 randconfig-a011-20230313 clang
x86_64 randconfig-a012-20230313 clang
x86_64 randconfig-a013-20230313 clang
x86_64 randconfig-a014-20230313 clang
x86_64 randconfig-a015-20230313 clang
x86_64 randconfig-a016-20230313 clang
x86_64 randconfig-c001 gcc
x86_64 randconfig-k001-20230313 clang
x86_64 randconfig-k001 clang
x86_64 randconfig-r002-20230313 gcc
x86_64 randconfig-r016-20230313 clang
x86_64 randconfig-r033-20230313 gcc
x86_64 rhel-8.3-bpf gcc
x86_64 rhel-8.3-kunit gcc
x86_64 rhel-8.3-kvm gcc
x86_64 rhel-8.3-syz gcc
x86_64 rhel-8.3 gcc
xtensa buildonly-randconfig-r004-20230312 gcc
xtensa randconfig-r001-20230312 gcc
xtensa randconfig-r001-20230313 gcc
xtensa randconfig-r003-20230312 gcc
xtensa randconfig-r005-20230312 gcc
xtensa randconfig-r011-20230312 gcc
xtensa randconfig-r015-20230313 gcc
xtensa randconfig-r023-20230312 gcc
xtensa randconfig-r024-20230313 gcc
xtensa randconfig-r032-20230313 gcc
xtensa randconfig-r033-20230312 gcc
xtensa randconfig-r034-20230312 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS f1e96f0617fc578f74319a5ba46473773035594f
From: kernel test robot @ 2023-03-18 0:00 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: f1e96f0617fc578f74319a5ba46473773035594f Input: bcm_iproc_tsc - drop of_match_ptr for ID table
elapsed time: 723m
configs tested: 110
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r001-20230313 gcc
alpha randconfig-r034-20230313 gcc
arc allyesconfig gcc
arc buildonly-randconfig-r004-20230312 gcc
arc defconfig gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm buildonly-randconfig-r001-20230313 gcc
arm buildonly-randconfig-r005-20230313 gcc
arm defconfig gcc
arm randconfig-r046-20230312 clang
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r005-20230313 gcc
csky defconfig gcc
csky randconfig-r002-20230313 gcc
hexagon buildonly-randconfig-r004-20230312 clang
hexagon buildonly-randconfig-r005-20230313 clang
hexagon randconfig-r041-20230312 clang
hexagon randconfig-r041-20230313 clang
hexagon randconfig-r045-20230312 clang
hexagon randconfig-r045-20230313 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r002-20230313 gcc
i386 buildonly-randconfig-r003-20230313 gcc
i386 debian-10.3-func gcc
i386 debian-10.3-kselftests gcc
i386 debian-10.3-kunit gcc
i386 debian-10.3-kvm gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230313 gcc
i386 randconfig-a002-20230313 gcc
i386 randconfig-a003-20230313 gcc
i386 randconfig-a004-20230313 gcc
i386 randconfig-a005-20230313 gcc
i386 randconfig-a006-20230313 gcc
i386 randconfig-a011-20230313 clang
i386 randconfig-a012-20230313 clang
i386 randconfig-a013-20230313 clang
i386 randconfig-a014-20230313 clang
i386 randconfig-a015-20230313 clang
i386 randconfig-a016-20230313 clang
i386 randconfig-c001 gcc
i386 randconfig-r032-20230313 gcc
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r005-20230312 gcc
ia64 defconfig gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
m68k allmodconfig gcc
m68k defconfig gcc
m68k randconfig-r004-20230312 gcc
m68k randconfig-r031-20230313 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips randconfig-r003-20230312 gcc
nios2 buildonly-randconfig-r003-20230312 gcc
nios2 defconfig gcc
openrisc buildonly-randconfig-r001-20230312 gcc
parisc buildonly-randconfig-r006-20230312 gcc
parisc defconfig gcc
parisc randconfig-r004-20230313 gcc
parisc randconfig-r036-20230313 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r001-20230313 clang
powerpc buildonly-randconfig-r004-20230313 clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv defconfig gcc
riscv randconfig-r003-20230313 gcc
riscv randconfig-r042-20230313 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r044-20230313 clang
sh allmodconfig gcc
sh buildonly-randconfig-r006-20230313 gcc
sparc defconfig gcc
sparc randconfig-r035-20230313 gcc
sparc64 randconfig-r006-20230313 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230313 gcc
x86_64 randconfig-a002-20230313 gcc
x86_64 randconfig-a003-20230313 gcc
x86_64 randconfig-a004-20230313 gcc
x86_64 randconfig-a005-20230313 gcc
x86_64 randconfig-a006-20230313 gcc
x86_64 randconfig-a011-20230313 clang
x86_64 randconfig-a012-20230313 clang
x86_64 randconfig-a013-20230313 clang
x86_64 randconfig-a014-20230313 clang
x86_64 randconfig-a015-20230313 clang
x86_64 randconfig-a016-20230313 clang
x86_64 randconfig-k001-20230313 clang
x86_64 randconfig-k001 clang
x86_64 randconfig-r033-20230313 gcc
x86_64 rhel-8.3 gcc
xtensa randconfig-r005-20230312 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [PATCH] Fix incorrectly applied patch for MAP_PROFILE_BUTTON
From: Bastien Nocera @ 2023-03-17 22:36 UTC (permalink / raw)
To: Matthias Benkmann, linux-input; +Cc: Nate Yocom
In-Reply-To: <CAK4gqCBiDiVQ-q8x_JjZ4ZY5UKr81foA_aa5YwZsE0yFarBtzA@mail.gmail.com>
On Fri, 2023-03-17 at 17:00 +0100, Matthias Benkmann wrote:
> Original
> patch can be seen here:
>
> https://lore.kernel.org/all/20220908173930.28940-6-nate@yocom.org/ The
> hunk
> in question was supposed to go into xpad**ONE**_process_packet(),
> but ended
> up in xpad_process_packet(). This fix is based on visual inspection
> only. I
> do not have the hardware to verify that it works. I CAN confidently
> say,
> however, that the old code could not possibly have worked, because
In the future, please don't use "old code", we don't know what "old
code" you could be referring to.
However you can remove this whole section, and either Nate or I will
test you v2.
> the
> function xpad_process_packet() is not called for the Microsoft X-Box
> Adaptive
> Controller since it is tagged as XTYPE_XBOXONE. So at least this fix
> does not
> break something that worked.
You need to use a Fixes tag, as well as a Signed-off-by tag, as per:
https://docs.kernel.org/process/submitting-patches.html
Please send a v2 with those and make sure to CC: the folks mentioned in
the original patch (that is, Nate and myself), as well as the
maintainers of the tree in question.
Good catch!
Cheers
>
> ---
> drivers/input/joystick/xpad.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/joystick/xpad.c
> b/drivers/input/joystick/xpad.c
> index f642ec8e92dd..29131f1a2f06 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -781,9 +781,6 @@ static void xpad_process_packet(struct usb_xpad
> *xpad, u16 cmd, unsigned char *d
> input_report_key(dev, BTN_C, data[8]);
> input_report_key(dev, BTN_Z, data[9]);
>
> - /* Profile button has a value of 0-3, so it is reported as an axis
> */
> - if (xpad->mapping & MAP_PROFILE_BUTTON)
> - input_report_abs(dev, ABS_PROFILE, data[34]);
>
> input_sync(dev);
> }
> @@ -1061,6 +1058,10 @@ static void xpadone_process_packet(struct
> usb_xpad *xpad, u16 cmd, unsigned char
> (__u16) le16_to_cpup((__le16 *)(data + 8)));
> }
>
> + /* Profile button has a value of 0-3, so it is reported as an axis
> */
> + if (xpad->mapping & MAP_PROFILE_BUTTON)
> + input_report_abs(dev, ABS_PROFILE, data[34]);
> +
> /* paddle handling */
> /* based on SDL's SDL_hidapi_xboxone.c */
> if (xpad->mapping & MAP_PADDLES) {
^ permalink raw reply
* [PATCH] Fix incorrectly applied patch for MAP_PROFILE_BUTTON
From: Matthias Benkmann @ 2023-03-17 16:00 UTC (permalink / raw)
To: linux-input
Original
patch can be seen here:
https://lore.kernel.org/all/20220908173930.28940-6-nate@yocom.org/ The hunk
in question was supposed to go into xpad**ONE**_process_packet(), but ended
up in xpad_process_packet(). This fix is based on visual inspection only. I
do not have the hardware to verify that it works. I CAN confidently say,
however, that the old code could not possibly have worked, because the
function xpad_process_packet() is not called for the Microsoft X-Box Adaptive
Controller since it is tagged as XTYPE_XBOXONE. So at least this fix does not
break something that worked.
---
drivers/input/joystick/xpad.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index f642ec8e92dd..29131f1a2f06 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -781,9 +781,6 @@ static void xpad_process_packet(struct usb_xpad
*xpad, u16 cmd, unsigned char *d
input_report_key(dev, BTN_C, data[8]);
input_report_key(dev, BTN_Z, data[9]);
- /* Profile button has a value of 0-3, so it is reported as an axis */
- if (xpad->mapping & MAP_PROFILE_BUTTON)
- input_report_abs(dev, ABS_PROFILE, data[34]);
input_sync(dev);
}
@@ -1061,6 +1058,10 @@ static void xpadone_process_packet(struct
usb_xpad *xpad, u16 cmd, unsigned char
(__u16) le16_to_cpup((__le16 *)(data + 8)));
}
+ /* Profile button has a value of 0-3, so it is reported as an axis */
+ if (xpad->mapping & MAP_PROFILE_BUTTON)
+ input_report_abs(dev, ABS_PROFILE, data[34]);
+
/* paddle handling */
/* based on SDL's SDL_hidapi_xboxone.c */
if (xpad->mapping & MAP_PADDLES) {
--
2.25.1
^ permalink raw reply related
* Re: BUG: hid-sensor-ids code includes binary data in device name
From: Todd Brandt @ 2023-03-17 15:37 UTC (permalink / raw)
To: Xu, Even, Philipp Jungkamp, srinivas pandruvada,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Jonathan.Cameron@huawei.com, jkosina@suse.cz, Brandt, Todd E
In-Reply-To: <DM6PR11MB2618B71FCDD70813404F570FF4BD9@DM6PR11MB2618.namprd11.prod.outlook.com>
On Fri, 2023-03-17 at 05:49 +0000, Xu, Even wrote:
> Hi, All,
>
> Sorry for response later.
>
> From below description, it seems not a buffer overrun issue, it's
> just caused by NULL terminated string, right?
>
Correct, the subject may be a bit misleading, it's just a for loop
reading past the end of a string because of the lack of a NULL char.
The patch adds the NULL char.
> Best Regards,
> Even Xu
>
> -----Original Message-----
> From: Todd Brandt <todd.e.brandt@linux.intel.com>
> Sent: Saturday, March 11, 2023 7:36 AM
> To: Philipp Jungkamp <p.jungkamp@gmx.net>; srinivas pandruvada
> <srinivas.pandruvada@linux.intel.com>; linux-input@vger.kernel.org;
> linux-kernel@vger.kernel.org; Xu, Even <even.xu@intel.com>
> Cc: Jonathan.Cameron@huawei.com; jkosina@suse.cz; Brandt, Todd E
> <todd.e.brandt@intel.com>
> Subject: Re: BUG: hid-sensor-ids code includes binary data in device
> name
>
> On Fri, 2023-03-10 at 15:35 +0100, Philipp Jungkamp wrote:
> > Hello,
> >
> > on v3 of the patchset I had this comment on the 'real_usage'
> > initialization:
> >
> > > > - char real_usage[HID_SENSOR_USAGE_LENGTH] = { 0 };
> > > > + char real_usage[HID_SENSOR_USAGE_LENGTH];
> > > > struct platform_device *custom_pdev;
> > > > const char *dev_name;
> > > > char *c;
> > > >
> > > > - /* copy real usage id */
> > > > - memcpy(real_usage, known_sensor_luid[index], 4);
> > > > + memcpy(real_usage, match->luid, 4);
> > > > + real_usage[4] = '\0';
> > >
> > > Why the change in approach for setting the NULL character?
> > > Doesn't seem relevant to main purpose of this patch.
> >
> > Based on the comment, I changed that in the final v4 revision to:
> >
> > > - char real_usage[HID_SENSOR_USAGE_LENGTH] = { 0 };
> > > + char real_usage[HID_SENSOR_USAGE_LENGTH];
> > > struct platform_device *custom_pdev;
> > > const char *dev_name;
> > > char *c;
> > >
> > > - /* copy real usage id */
> > > - memcpy(real_usage, known_sensor_luid[index], 4);
> > > + memcpy(real_usage, match->luid, 4);
> >
> > I ommitted the line adding the null terminator to the string but
> > kept
> > that I didn't initialize the 'real_usage' as { 0 } anymore. The
> > string
> > now misses the null terminator which leads to the broken utf-8.
> >
> > The simple fix is to reintroduce the 0 initialization in
> > hid_sensor_register_platform_device. E.g.
> >
> > - char real_usage[HID_SENSOR_USAGE_LENGTH];
> > + char real_usage[HID_SENSOR_USAGE_LENGTH] = { 0 };
> >
>
> I didn't realize that the issue was a buffer overrun. I tested the
> kernel built with this simple fix and it works ok now. i.e. this
> patch is is all that's needed:
>
> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-
> sensor- custom.c index 3e3f89e01d81..d85398721659 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
> @@ -940,7 +940,7 @@ hid_sensor_register_platform_device(struct
> platform_device *pdev,
> struct hid_sensor_hub_device
> *hsdev,
> const struct
> hid_sensor_custom_match *match) {
> - char real_usage[HID_SENSOR_USAGE_LENGTH];
> + char real_usage[HID_SENSOR_USAGE_LENGTH] = { 0 };
> struct platform_device *custom_pdev;
> const char *dev_name;
> char *c;
>
> > Where do I need to submit a patch for this? And on which tree
> > should I
> > base the patch?
> >
>
> The change is so small it shouldn't require any rebasing. Just send
> the
> patch to these emails (from MAINTAINERS):
>
> HID SENSOR HUB DRIVERS
> M: Jiri Kosina <jikos@kernel.org>
> M: Jonathan Cameron <jic23@kernel.org>
> M: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> L: linux-input@vger.kernel.org
> L: linux-iio@vger.kernel.org
>
> > I'm sorry for the problems my patch caused.
> >
>
> No problem. It actually made sleepgraph better because it exposed a
> bug
> in the ftrace processing code. I wasn't properly handling the corner
> case where ftrace had binary data in it.
>
> > Regards,
> > Philipp Jungkamp
> >
> > On Fri, 2023-03-10 at 01:51 -0800, srinivas pandruvada wrote:
> > > +Even
> > >
> > > On Thu, 2023-03-09 at 15:33 -0800, Todd Brandt wrote:
> > > > Hi all, I've run into an issue in 6.3.0-rc1 that causes
> > > > problems
> > > > with
> > > > ftrace and I've bisected it to this commit:
> > > >
> > > > commit 98c062e8245199fa9121141a0bf1035dc45ae90e (HEAD,
> > > > refs/bisect/bad)
> > > > Author: Philipp Jungkamp p.jungkamp@gmx.net
> > > > Date: Fri Nov 25 00:38:38 2022 +0100
> > > >
> > > > HID: hid-sensor-custom: Allow more custom iio sensors
> > > >
> > > > The known LUID table for established/known custom HID
> > > > sensors
> > > > was
> > > > limited to sensors with "INTEL" as manufacturer. But some
> > > > vendors
> > > > such
> > > > as Lenovo also include fairly standard iio sensors (e.g.
> > > > ambient
> > > > light)
> > > > in their custom sensors.
> > > >
> > > > Expand the known custom sensors table by a tag used for the
> > > > platform
> > > > device name and match sensors based on the LUID as well as
> > > > optionally
> > > > on model and manufacturer properties.
> > > >
> > > > Signed-off-by: Philipp Jungkamp p.jungkamp@gmx.net
> > > > Reviewed-by: Jonathan Cameron Jonathan.Cameron@huawei.com
> > > > Acked-by: Srinivas Pandruvada
> > > > srinivas.pandruvada@linux.intel.com
> > > > Signed-off-by: Jiri Kosina jkosina@suse.cz
> > > >
> > > > You're using raw data as part of the devname in the
> > > > "real_usage"
> > > > string, but it includes chars other than ASCII, and those chars
> > > > end
> > > > up being printed out in the ftrace log which is meant to be
> > > > ASCII
> > > > only.
> > > >
> > > > - /* HID-SENSOR-INT-REAL_USAGE_ID */
> > > > - dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-INT-%s",
> > > > real_usage);
> > > > + /* HID-SENSOR-TAG-REAL_USAGE_ID */
> > > > + dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-%s-%s",
> > > > + match->tag, real_usage);
> > > >
> > > > My sleepgraph tool started to crash because it read these lines
> > > > from
> > > > ftrace:
> > > >
> > > > device_pm_callback_start: platform HID-SENSOR-INT-
> > > > 020b?.39.auto,
> > > > parent: 001F:8087:0AC2.0003, [suspend]
> > > > device_pm_callback_end: platform HID-SENSOR-INT-020b?.39.auto,
> > > > err=0
> > > >
> > >
> > > Here tag is:
> > > .tag = "INT",
> > > .luid = "020B000000000000",
> > >
> > >
> > > The LUID is still a string. Probably too long for a dev_name.
> > >
> > > Even,
> > >
> > > Please check.
> > >
> > > Thanks.
> > > Srinivas
> > >
> > >
> > > > The "HID-SENSOR-INT-020b?.39.auto" string includes a binary
> > > > char
> > > > that
> > > > kills
> > > > python3 code that loops through an ascii file as such:
> > > >
> > > > File "/usr/bin/sleepgraph", line 5579, in executeSuspend
> > > > for line in fp:
> > > > File "/usr/lib/python3.10/codecs.py", line 322, in decode
> > > > (result, consumed) = self._buffer_decode(data, self.errors,
> > > > final)
> > > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in
> > > > position
> > > > 1568: invalid start byte
> > > >
> > > > I've updated sleepgraph to handle random non-ascii chars, but
> > > > other
> > > > tools
> > > > may suffer the same fate. Can you rewrite this to ensure that
> > > > no
> > > > binary
> > > > chars make it into the devname?
> > > >
> >
> >
>
^ permalink raw reply
* [lvc-project] [PATCH v2] Input: trackpoint - remove unreachable code
From: Igor Artemiev @ 2023-03-17 13:39 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Igor Artemiev, linux-input, linux-kernel, lvc-project
In-Reply-To: <ZBQ+bJQkcZREArAq@google.com>
The trackpoint_sync() function always returns 0.
And there is no need to check its result.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Igor Artemiev <Igor.A.Artemiev@mcst.ru>
---
v2: make the trackpoint_sync() a void function
as Andi Shyti <andi.shyti@kernel.org> suggested.
drivers/input/mouse/trackpoint.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
index 4a86b3e31d3b..2c381377ad4b 100644
--- a/drivers/input/mouse/trackpoint.c
+++ b/drivers/input/mouse/trackpoint.c
@@ -300,7 +300,7 @@ static int trackpoint_start_protocol(struct psmouse *psmouse,
* power-on reset was run). If so, values will only be
* written to TP if they differ from power-on default.
*/
-static int trackpoint_sync(struct psmouse *psmouse, bool in_power_on_state)
+static void trackpoint_sync(struct psmouse *psmouse, bool in_power_on_state)
{
struct trackpoint_data *tp = psmouse->private;
@@ -340,8 +340,6 @@ static int trackpoint_sync(struct psmouse *psmouse, bool in_power_on_state)
TRACKPOINT_UPDATE(in_power_on_state, psmouse, tp, press_to_select);
TRACKPOINT_UPDATE(in_power_on_state, psmouse, tp, skipback);
TRACKPOINT_UPDATE(in_power_on_state, psmouse, tp, ext_dev);
-
- return 0;
}
static void trackpoint_defaults(struct trackpoint_data *tp)
@@ -386,9 +384,7 @@ static int trackpoint_reconnect(struct psmouse *psmouse)
was_reset = tp->variant_id == TP_VARIANT_IBM &&
trackpoint_power_on_reset(&psmouse->ps2dev) == 0;
- error = trackpoint_sync(psmouse, was_reset);
- if (error)
- return error;
+ trackpoint_sync(psmouse, was_reset);
return 0;
}
--
2.30.2
^ permalink raw reply related
* Re: [PATCH] Input: zinitix: Use of_property_present() for testing DT property presence
From: Dmitry Torokhov @ 2023-03-17 11:21 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-input, linux-kernel
In-Reply-To: <20230310144708.1542682-1-robh@kernel.org>
On Fri, Mar 10, 2023 at 08:47:08AM -0600, Rob Herring wrote:
> It is preferred to use typed property access functions (i.e.
> of_property_read_<type> functions) rather than low-level
> of_get_property/of_find_property functions for reading properties. As
> part of this, convert of_get_property/of_find_property calls to the
> recently added of_property_present() helper when we just want to test
> for presence of a property and nothing more.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: Use of_property_read_bool() for boolean properties
From: Dmitry Torokhov @ 2023-03-17 11:21 UTC (permalink / raw)
To: Rob Herring
Cc: Laxman Dewangan, Thierry Reding, Jonathan Hunter, devicetree,
linux-input, linux-kernel, linux-tegra
In-Reply-To: <20230310144708.1542751-1-robh@kernel.org>
On Fri, Mar 10, 2023 at 08:47:08AM -0600, Rob Herring wrote:
> It is preferred to use typed property access functions (i.e.
> of_property_read_<type> functions) rather than low-level
> of_get_property/of_find_property functions for reading properties.
> Convert reading boolean properties to to of_property_read_bool().
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 4/4] Input: bcm_iproc_tsc: drop of_match_ptr for ID table
From: Dmitry Torokhov @ 2023-03-17 11:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ray Jui, Scott Branden, Broadcom internal kernel review list,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-input,
linux-kernel, linux-arm-kernel, linux-sunxi
In-Reply-To: <20230312131514.351603-4-krzysztof.kozlowski@linaro.org>
On Sun, Mar 12, 2023 at 02:15:14PM +0100, Krzysztof Kozlowski wrote:
> The driver can match only via the DT table so the table should be always
> used and the of_match_ptr does not have any sense (this also allows ACPI
> matching via PRP0001, even though it might not be relevant here). This
> also fixes !CONFIG_OF error:
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] Input: sun4i-ts: drop of_match_ptr for ID table
From: Dmitry Torokhov @ 2023-03-17 11:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ray Jui, Scott Branden, Broadcom internal kernel review list,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-input,
linux-kernel, linux-arm-kernel, linux-sunxi
In-Reply-To: <20230312131514.351603-3-krzysztof.kozlowski@linaro.org>
On Sun, Mar 12, 2023 at 02:15:13PM +0100, Krzysztof Kozlowski wrote:
> The driver can match only via the DT table so the table should be always
> used and the of_match_ptr does not have any sense (this also allows ACPI
> matching via PRP0001, even though it might not be relevant here). This
> also fixes !CONFIG_OF error:
>
> drivers/input/touchscreen/sun4i-ts.c:392:34: error: ‘sun4i_ts_of_match’ defined but not used [-Werror=unused-const-variable=]
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/4] Input: tm2-touchkey: drop of_match_ptr for ID table
From: Dmitry Torokhov @ 2023-03-17 11:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ray Jui, Scott Branden, Broadcom internal kernel review list,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-input,
linux-kernel, linux-arm-kernel, linux-sunxi
In-Reply-To: <20230312131514.351603-2-krzysztof.kozlowski@linaro.org>
On Sun, Mar 12, 2023 at 02:15:12PM +0100, Krzysztof Kozlowski wrote:
> The driver will match mostly by DT table (even thought there is regular
> ID table) so there is little benefit in of_match_ptr (this also allows
> ACPI matching via PRP0001, even though it might not be relevant here).
> This also fixes !CONFIG_OF error:
>
> drivers/input/keyboard/tm2-touchkey.c:335:34: error: ‘tm2_touchkey_of_match’ defined but not used [-Werror=unused-const-variable=]
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/4] Input: st-keyscan: drop of_match_ptr for ID table
From: Dmitry Torokhov @ 2023-03-17 11:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ray Jui, Scott Branden, Broadcom internal kernel review list,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-input,
linux-kernel, linux-arm-kernel, linux-sunxi
In-Reply-To: <20230312131514.351603-1-krzysztof.kozlowski@linaro.org>
On Sun, Mar 12, 2023 at 02:15:11PM +0100, Krzysztof Kozlowski wrote:
> The driver can match only via the DT table so the table should be always
> used and the of_match_ptr does not have any sense (this also allows ACPI
> matching via PRP0001, even though it might not be relevant here). This
> also fixes !CONFIG_OF error:
>
> drivers/input/keyboard/st-keyscan.c:251:34: error: ‘keyscan_of_match’ defined but not used [-Werror=unused-const-variable=]
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Applied, thank you.
--
Dmitry
^ 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