* [dtor-input:for-linus] BUILD SUCCESS 2479191c30fe90c368fd6c8842e9846959466ccd
From: kernel test robot @ 2023-07-06 11:00 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: 2479191c30fe90c368fd6c8842e9846959466ccd Input: cpcap-pwrbutton - replace GPLv2 boilerplate with SPDX
elapsed time: 721m
configs tested: 131
configs skipped: 4
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-r012-20230706 gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r043-20230706 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm at91_dt_defconfig gcc
arm defconfig clang
arm defconfig gcc
arm exynos_defconfig gcc
arm randconfig-r046-20230706 clang
arm socfpga_defconfig clang
arm tegra_defconfig gcc
arm vt8500_v6_v7_defconfig clang
arm64 allyesconfig gcc
arm64 defconfig gcc
csky defconfig gcc
hexagon alldefconfig clang
hexagon randconfig-r002-20230706 clang
hexagon randconfig-r013-20230706 clang
hexagon randconfig-r041-20230706 clang
hexagon randconfig-r045-20230706 clang
i386 allyesconfig gcc
i386 buildonly-randconfig-r004-20230706 clang
i386 buildonly-randconfig-r005-20230706 clang
i386 buildonly-randconfig-r006-20230706 clang
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-i001-20230706 clang
i386 randconfig-i002-20230706 clang
i386 randconfig-i003-20230706 clang
i386 randconfig-i004-20230706 clang
i386 randconfig-i005-20230706 clang
i386 randconfig-i006-20230706 clang
i386 randconfig-i011-20230706 gcc
i386 randconfig-i012-20230706 gcc
i386 randconfig-i013-20230706 gcc
i386 randconfig-i014-20230706 gcc
i386 randconfig-i015-20230706 gcc
i386 randconfig-i016-20230706 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r016-20230706 gcc
m68k allmodconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k q40_defconfig gcc
m68k sun3_defconfig gcc
microblaze randconfig-r005-20230706 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips ip32_defconfig gcc
mips malta_defconfig clang
mips randconfig-r022-20230706 clang
mips rs90_defconfig clang
nios2 defconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-r001-20230706 gcc
parisc randconfig-r021-20230706 gcc
parisc randconfig-r032-20230705 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc currituck_defconfig gcc
powerpc iss476-smp_defconfig gcc
powerpc lite5200b_defconfig clang
powerpc mpc83xx_defconfig gcc
powerpc randconfig-r011-20230706 gcc
powerpc randconfig-r024-20230706 gcc
powerpc randconfig-r036-20230705 gcc
powerpc sam440ep_defconfig gcc
powerpc tqm8541_defconfig gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv nommu_virt_defconfig clang
riscv randconfig-r014-20230706 gcc
riscv randconfig-r015-20230706 gcc
riscv randconfig-r042-20230706 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-r004-20230706 clang
s390 randconfig-r025-20230706 gcc
s390 randconfig-r031-20230705 gcc
s390 randconfig-r044-20230706 gcc
sh allmodconfig gcc
sh espt_defconfig gcc
sh se7751_defconfig gcc
sh sh03_defconfig gcc
sh sh7724_generic_defconfig gcc
sh sh7785lcr_defconfig gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc64 randconfig-r035-20230705 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-r023-20230706 clang
um randconfig-r026-20230706 clang
um x86_64_defconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-r001-20230706 clang
x86_64 buildonly-randconfig-r002-20230706 clang
x86_64 buildonly-randconfig-r003-20230706 clang
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-x001-20230706 gcc
x86_64 randconfig-x002-20230706 gcc
x86_64 randconfig-x003-20230706 gcc
x86_64 randconfig-x004-20230706 gcc
x86_64 randconfig-x005-20230706 gcc
x86_64 randconfig-x006-20230706 gcc
x86_64 randconfig-x011-20230706 clang
x86_64 randconfig-x012-20230706 clang
x86_64 randconfig-x013-20230706 clang
x86_64 randconfig-x014-20230706 clang
x86_64 randconfig-x015-20230706 clang
x86_64 randconfig-x016-20230706 clang
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa iss_defconfig gcc
xtensa randconfig-r006-20230706 gcc
xtensa randconfig-r034-20230705 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 1/4] Input: ts-overlay - Add touchscreen overlay object handling
From: Jeff LaBundy @ 2023-07-06 2:26 UTC (permalink / raw)
To: Javier Carrasco
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch, linux-kernel,
linux-input, devicetree
In-Reply-To: <ed1f627b-1713-b273-c083-c98d88f885d2@wolfvision.net>
Hi Javier,
On Sat, Jul 01, 2023 at 10:58:54PM +0200, Javier Carrasco wrote:
> Hi Jeff,
>
> On 26.06.23 04:35, Jeff LaBundy wrote:
> >> +
> >> + dev_info(dev, "Added button at (%u, %u), size %ux%u, code=%u\n",
> >> + btn[j].shape.x_origin, btn[j].shape.y_origin,
> >> + btn[j].shape.x_size, btn[j].shape.y_size, btn[j].key);
> >
> > This seems like a dev_dbg() to me.
> >
> >> + j++;
> >> + }
> >> +
> >> + return 0;
> >> +
> >> +button_prop_cleanup:
> >> + fwnode_handle_put(child_btn);
> >> + return rc;
> >> +}
> >> +
> >> +void ts_overlay_set_button_caps(struct ts_overlay_map *map,
> >> + struct input_dev *dev)
> >> +{
> >> + int i;
> >> +
> >> + for (i = 0; i < map->button_count; i++)
> >> + input_set_capability(dev, EV_KEY, map->buttons[i].key);
> >> +}
> >> +EXPORT_SYMBOL(ts_overlay_set_button_caps);
> >
> > I don't see a need to expose this function and require participating drivers
> > to call it; we should just have one over-arching function for processing the
> > overlay(s), akin to touchscreen_parse_properties but for the button input
> > device in case the driver separates the button and touchscreen input devices.
> >
> > That one function would then be responsible for parsing the overlay(s) and
> > calling input_set_capability() on each button.
> >
> I just realized that I did not reply anything about this, even though
> there is a reason why I exposed this function and now that I am working
> on the v4, some clarification might be required.
>
> After it was decided that this feature should work with two different
> devices (a touchscreen and a keypad), I registered a keypad in the
> st1232.c probe function if overlay buttons were defined. I did not
> register the device inside the new functions because I thought that I
> would be hiding too much magic from the driver.
>
> Instead I provided a function to check if a keypad was defined and
> another one to set the capabilities (the one we are discussing). The
> driver could just set any parameters it wants before registering the
> device and use this function within that process. The parsing is not
> missing, it is carried out before and the programmer does not need to
> know the key capabilities to call this function.
I looked back at patch [3/4] with these points in mind, but I still feel
there is too much burden placed on the consuming driver. I imagine that
almost every driver would call ts_overlay_set_button_caps() if
ts_overlay_mapped_buttons() returned true; this would result in a lot of
repeated code that your module should simply do on the driver's behalf.
I think modeling after the touchscreen helpers is a good start and would
be most natural for future customers. Where we have this:
void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
struct touchscreen_properties *prop)
Perhaps we need something like this:
int touch_overlay_parse_properties(struct input_dev *input,
struct list_head overlay_head)
The latter would do the following:
1. Walk the parent node of *input to find each overlay/button ("segment")
2. Allocate sizeof(struct touch_segment)'s worth of memory and add it to
the linked list
3. Parse the dimensions and keycode (if present)
4. Call input_set_capability() on *input with the given keycode
5. Return to step (2) for all remaining button(s)
There are two problems with this:
1. *input needs to be allocated ahead-of-time, but you don't know whether
or not you actually needed it until after the function returns.
2. After the function returns, you need to know whether or not the input
device is empty (i.e. no childen defined); otherwise there is no point
in registering the second device.
Part (2) seems pretty easy to solve; the consuming driver could simply call
list_empty() on overlay_head and then decide whether to proceed to populate
the rest of the *input struct and register the device.
Perhaps one way to solve part (1) would be to simply expect the consuming
driver to allocate *input ahead-of-time, as is the case for the touchscreen
helpers. If the same call to list_empty() above returns false, the driver
can call devm_free() on it instead of registering it.
Please note that this complexity only exists for the case where the driver
elects to separate the touchscreen and button devices. Both problems go
away for the simple case where the driver clubs all functions into a single
input device.
>
> So the process is as follows:
> 1.- Map overlay objects if they are defined.
> 2.- If there is a keypad, set the device properties you want it to have
> (name, etc). The event keys were already parsed and can be set with
> touch_overlay_set_button_caps()
> 3.- Register the device whenever and under the circumstances you like.
>
> That is the current implementation, not necessarily the best one or the
> one the community would prefer.
> If that is preferred, the mapping function could for example register
> the keypad and return a pointer to the keyboard, inferring the device
> properties from the "main" device that will be registered anyways (e.g.
> using its name + "-keypad") or passing them as parameters, which might
> look a bit artificial. In that case the key capabilities would be
> automatically set and this function would not be exposed any more.
>
> The question is if we would be missing flexibility when setting the
> device properties prior its registration and if the participating
> drivers want this to be done under the hood. My solution is the one I
> found less intrusive for the driver (at the cost of doing the
> registration itself), but if there are good reasons for a different
> implementation, I will be alright with it. If not, the driver will
> control the keypad registration and will use this function to set the
> key caps.
I think we should stick with the existing model where the consuming driver
is responsible for allocating and registering the input device as you have
done; this is the correct and common pattern. touch_overlay_parse_properties()
or its equivalent should not be managing memory or manipulating properties
of *input beyond those it is immediately concerned with (i.e. key reporting
capabilities).
What I do recommend to change, however, is to absorb what is currently called
ts_overlay_set_button_caps() into the existing parsing code. The consuming
driver will always call it if buttons are defined, and the parsing code knows
whether any are defined.
>
> Sorry for the late reply to this particular point and especially for the
> long text. But a clarification here might save us from another
> discussion later on :)
>
> Best regards,
> Javier Carrasco
Kind regards,
Jeff LaBundy
^ permalink raw reply
* Re: [PATCH v6 1/1] Input: gameport: add ISA and HAS_IOPORT dependencies
From: Dmitry Torokhov @ 2023-07-06 0:34 UTC (permalink / raw)
To: Niklas Schnelle; +Cc: Arnd Bergmann, linux-input, linux-kernel
In-Reply-To: <20230703152355.3897456-2-schnelle@linux.ibm.com>
Hi Niklas,
On Mon, Jul 03, 2023 at 05:23:55PM +0200, Niklas Schnelle wrote:
> +static void gameport_setup_default_handlers(struct gameport *gameport)
> +{
> + if (gameport->trigger && gameport->read)
> + return;
> +
> + if (!IS_ENABLED(CONFIG_HAS_IOPORT))
> + dev_err(&gameport->dev,
> + "I/O port access is required for %s (%s) but is not available\n",
> + gameport->phys, gameport->name);
I combined these 2 conditions into one and applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND] input: cpcap-pwrbutton: remove initial kernel-doc notation
From: Dmitry Torokhov @ 2023-07-05 21:51 UTC (permalink / raw)
To: Sebastian Reichel; +Cc: Randy Dunlap, linux-kernel, linux-input
In-Reply-To: <20230705212845.w2yhqb75fqx6psim@mercury.elektranox.org>
On Wed, Jul 05, 2023 at 11:28:45PM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Jul 05, 2023 at 12:28:50PM -0700, Dmitry Torokhov wrote:
> > On Tue, Jul 04, 2023 at 02:08:21AM +0200, Sebastian Reichel wrote:
> > > Hi,
> > >
> > > On Mon, Jul 03, 2023 at 04:00:05PM -0700, Randy Dunlap wrote:
> > > > Change the beginning "/**" in the file to "/*" since it is not a
> > > > kernel-doc comment. This prevents a kernel-doc warning:
> > > >
> > > > drivers/input/misc/cpcap-pwrbutton.c:2: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
> > > > * CPCAP Power Button Input Driver
> > > >
> > > > Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > > > Cc: Sebastian Reichel <sre@kernel.org>
> > > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > Cc: linux-input@vger.kernel.org
> > > > ---
> > >
> > > Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> >
> > Applied, thank you.
> >
> > BTW, the driver is missing SPDX annotation, Sebastian I wonder if you
> > could send a patch addressing this (given you are the author it is
> > better coming from you).
>
> DONE: https://lore.kernel.org/all/20230705212231.631525-1-sre@kernel.org/
Thank you, much appreciated.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1] Input: cpcap-pwrbutton - replace GPLv2 boilerplate with SPDX
From: Dmitry Torokhov @ 2023-07-05 21:51 UTC (permalink / raw)
To: Sebastian Reichel; +Cc: linux-kernel, linux-input
In-Reply-To: <20230705212231.631525-1-sre@kernel.org>
On Wed, Jul 05, 2023 at 11:22:31PM +0200, Sebastian Reichel wrote:
> Replace the GPLv2 boilerplate text with a nice and short
> SPDX header.
>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: exc3000 - Support power supply regulators
From: Dmitry Torokhov @ 2023-07-05 21:49 UTC (permalink / raw)
To: Mike Looijmans
Cc: devicetree, linux-input, Uwe Kleine-König, linux-kernel
In-Reply-To: <20230703084536.8429-2-mike.looijmans@topic.nl>
Hi Mike,
On Mon, Jul 03, 2023 at 10:45:36AM +0200, Mike Looijmans wrote:
> Add power supply regulator support to the exc3000 devices.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>
> ---
>
> drivers/input/touchscreen/exc3000.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/touchscreen/exc3000.c b/drivers/input/touchscreen/exc3000.c
> index 4af4c1e5d0da..3e50af8a4a2d 100644
> --- a/drivers/input/touchscreen/exc3000.c
> +++ b/drivers/input/touchscreen/exc3000.c
> @@ -18,6 +18,7 @@
> #include <linux/interrupt.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/sizes.h>
> #include <linux/timer.h>
> #include <asm/unaligned.h>
> @@ -360,6 +361,12 @@ static int exc3000_probe(struct i2c_client *client)
> if (IS_ERR(data->reset))
> return PTR_ERR(data->reset);
>
> + /* For proper reset sequence, enable power while reset asserted */
> + error = devm_regulator_get_enable_optional(&client->dev, "vdd");
> + if (error && error != -ENODEV)
> + dev_err_probe(&client->dev, error,
> + "failed to request vdd regulator\n");
If there is a regulator described in the firmware we should not continue
with initializing the device if we fail to grab/enable it. Think about
what happens if you get -EPROBE_DEFER here. You should return here.
Also, why are you using the _optional() variant? VDD is not an optional
for the controller. regulator_get_optional() is needed when you need to
alter the behavior of the device/driver depending on the presence of an
optional supply, whereas here it should work fine with a sub supply that
will be created if you simply call devm_regulator_get_enable() and there
is not regulator mentioned in DT/ACPI for the board.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND] input: cpcap-pwrbutton: remove initial kernel-doc notation
From: Sebastian Reichel @ 2023-07-05 21:28 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Randy Dunlap, linux-kernel, linux-input
In-Reply-To: <ZKXEcr+43Qkj8Y4m@google.com>
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
Hi,
On Wed, Jul 05, 2023 at 12:28:50PM -0700, Dmitry Torokhov wrote:
> On Tue, Jul 04, 2023 at 02:08:21AM +0200, Sebastian Reichel wrote:
> > Hi,
> >
> > On Mon, Jul 03, 2023 at 04:00:05PM -0700, Randy Dunlap wrote:
> > > Change the beginning "/**" in the file to "/*" since it is not a
> > > kernel-doc comment. This prevents a kernel-doc warning:
> > >
> > > drivers/input/misc/cpcap-pwrbutton.c:2: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
> > > * CPCAP Power Button Input Driver
> > >
> > > Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > > Cc: Sebastian Reichel <sre@kernel.org>
> > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Cc: linux-input@vger.kernel.org
> > > ---
> >
> > Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>
> Applied, thank you.
>
> BTW, the driver is missing SPDX annotation, Sebastian I wonder if you
> could send a patch addressing this (given you are the author it is
> better coming from you).
DONE: https://lore.kernel.org/all/20230705212231.631525-1-sre@kernel.org/
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v1] Input: cpcap-pwrbutton - replace GPLv2 boilerplate with SPDX
From: Sebastian Reichel @ 2023-07-05 21:22 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov; +Cc: linux-kernel, linux-input
Replace the GPLv2 boilerplate text with a nice and short
SPDX header.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
Based on afbc67a90c7ccef304796af15477b43de5555b07
("Input: cpcap-pwrbutton - remove initial kernel-doc notation")
---
drivers/input/misc/cpcap-pwrbutton.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/input/misc/cpcap-pwrbutton.c b/drivers/input/misc/cpcap-pwrbutton.c
index 5aff5a7d6a35..85cddb84717a 100644
--- a/drivers/input/misc/cpcap-pwrbutton.c
+++ b/drivers/input/misc/cpcap-pwrbutton.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-only
/*
* CPCAP Power Button Input Driver
*
* Copyright (C) 2017 Sebastian Reichel <sre@kernel.org>
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License. See the file "COPYING" in the main directory of this
- * archive for more details.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/module.h>
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v2] Input: exc3000 - add ACPI support for EXC80H60
From: Dmitry Torokhov @ 2023-07-05 19:32 UTC (permalink / raw)
To: Andreas Helbech Kleist; +Cc: linux-input, linux-kernel
In-Reply-To: <20230705091817.1300928-1-andreaskleist@gmail.com>
On Wed, Jul 05, 2023 at 11:18:16AM +0200, Andreas Helbech Kleist wrote:
> EXC80H60 is used in Ambu aBox2 with ACPI _HID "EGA00001".
>
> Snippet of from "apcidump -b; iasl ssdt2.dat" on target:
>
> Device (TPL2)
> {
> Name (HID2, Zero)
> Name (_HID, "EGA00001") // _HID: Hardware ID
> Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */)
> // _CID: Compatible ID
> Name (_S0W, 0x04) // _S0W: S0 Device Wake State
> Name (SBFB, ResourceTemplate ()
>
> Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND] input: cpcap-pwrbutton: remove initial kernel-doc notation
From: Dmitry Torokhov @ 2023-07-05 19:28 UTC (permalink / raw)
To: Sebastian Reichel; +Cc: Randy Dunlap, linux-kernel, linux-input
In-Reply-To: <20230704000821.z3tx4chw7x6pn6nq@mercury.elektranox.org>
On Tue, Jul 04, 2023 at 02:08:21AM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Jul 03, 2023 at 04:00:05PM -0700, Randy Dunlap wrote:
> > Change the beginning "/**" in the file to "/*" since it is not a
> > kernel-doc comment. This prevents a kernel-doc warning:
> >
> > drivers/input/misc/cpcap-pwrbutton.c:2: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
> > * CPCAP Power Button Input Driver
> >
> > Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > Cc: Sebastian Reichel <sre@kernel.org>
> > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Cc: linux-input@vger.kernel.org
> > ---
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Applied, thank you.
BTW, the driver is missing SPDX annotation, Sebastian I wonder if you
could send a patch addressing this (given you are the author it is
better coming from you).
Thanks!
--
Dmitry
^ permalink raw reply
* [PATCH] HID: hyperv: avoid struct memcpy overrun warning
From: Arnd Bergmann @ 2023-07-05 14:02 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Arnd Bergmann, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Paulo Miguel Almeida, Michael Kelley, Dawei Li,
Yang Yingliang, Thomas Weißschuh, linux-hyperv, linux-input,
linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
A previous patch addressed the fortified memcpy warning for most
builds, but I still see this one with gcc-9:
In file included from include/linux/string.h:254,
from drivers/hid/hid-hyperv.c:8:
In function 'fortify_memcpy_chk',
inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:
include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
583 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My guess is that the WARN_ON() itself is what confuses gcc, so it no
longer sees that there is a correct range check. Rework the code in a
way that helps readability and avoids the warning.
Fixes: 542f25a944715 ("HID: hyperv: Replace one-element array with flexible-array member")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/hid/hid-hyperv.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 49d4a26895e76..f33485d83d24f 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -258,19 +258,17 @@ static void mousevsc_on_receive(struct hv_device *device,
switch (hid_msg_hdr->type) {
case SYNTH_HID_PROTOCOL_RESPONSE:
+ len = struct_size(pipe_msg, data, pipe_msg->size);
+
/*
* While it will be impossible for us to protect against
* malicious/buggy hypervisor/host, add a check here to
* ensure we don't corrupt memory.
*/
- if (struct_size(pipe_msg, data, pipe_msg->size)
- > sizeof(struct mousevsc_prt_msg)) {
- WARN_ON(1);
+ if (WARN_ON(len > sizeof(struct mousevsc_prt_msg)))
break;
- }
- memcpy(&input_dev->protocol_resp, pipe_msg,
- struct_size(pipe_msg, data, pipe_msg->size));
+ memcpy(&input_dev->protocol_resp, pipe_msg, len);
complete(&input_dev->wait_event);
break;
--
2.39.2
^ permalink raw reply related
* [PATCH HID v1] HID:hid-magicmouse:Fix repeated initialization
From: Wang Ming @ 2023-07-05 13:46 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
Cc: opensource.kernel, Wang Ming
If the first report returns NULL,
there is no need to execute the
hid_register_report function a
second time.
Signed-off-by: Wang Ming <machel@vivo.com>
---
drivers/hid/hid-magicmouse.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index c9c968d4b36a..ae3c78ebb986 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -857,8 +857,10 @@ static int magicmouse_probe(struct hid_device *hdev,
} else { /* USB_DEVICE_ID_APPLE_MAGICTRACKPAD */
report = hid_register_report(hdev, HID_INPUT_REPORT,
TRACKPAD_REPORT_ID, 0);
- report = hid_register_report(hdev, HID_INPUT_REPORT,
- DOUBLE_REPORT_ID, 0);
+ if (report) {
+ report = hid_register_report(hdev, HID_INPUT_REPORT,
+ DOUBLE_REPORT_ID, 0);
+ }
}
if (!report) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] Input: exc3000 - add ACPI support for EXC80H60
From: kernel test robot @ 2023-07-05 10:08 UTC (permalink / raw)
To: Andreas Helbech Kleist, Dmitry Torokhov
Cc: oe-kbuild-all, Andreas Helbech Kleist, linux-input, linux-kernel
In-Reply-To: <20230704105021.898555-1-andreaskleist@gmail.com>
Hi Andreas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.4]
[also build test WARNING on linus/master next-20230705]
[cannot apply to dtor-input/next dtor-input/for-linus]
[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/Andreas-Helbech-Kleist/Input-exc3000-add-ACPI-support-for-EXC80H60/20230704-185127
base: v6.4
patch link: https://lore.kernel.org/r/20230704105021.898555-1-andreaskleist%40gmail.com
patch subject: [PATCH] Input: exc3000 - add ACPI support for EXC80H60
config: i386-randconfig-i062-20230703 (https://download.01.org/0day-ci/archive/20230705/202307051716.GC4vKJUY-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce: (https://download.01.org/0day-ci/archive/20230705/202307051716.GC4vKJUY-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202307051716.GC4vKJUY-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/input/touchscreen/exc3000.c:460:51: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned long [usertype] driver_data @@ got struct eeti_dev_info * @@
drivers/input/touchscreen/exc3000.c:460:51: sparse: expected unsigned long [usertype] driver_data
drivers/input/touchscreen/exc3000.c:460:51: sparse: got struct eeti_dev_info *
vim +460 drivers/input/touchscreen/exc3000.c
457
458 #ifdef CONFIG_ACPI
459 static const struct acpi_device_id exc3000_acpi_match[] = {
> 460 { "EGA00001", .driver_data = &exc3000_info[EETI_EXC80H60] },
461 { }
462 };
463 MODULE_DEVICE_TABLE(acpi, exc3000_acpi_match);
464 #endif
465
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] Input: exc3000 - add ACPI support for EXC80H60
From: Andreas Helbech Kleist @ 2023-07-05 9:18 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Andreas Helbech Kleist, linux-input, linux-kernel
EXC80H60 is used in Ambu aBox2 with ACPI _HID "EGA00001".
Snippet of from "apcidump -b; iasl ssdt2.dat" on target:
Device (TPL2)
{
Name (HID2, Zero)
Name (_HID, "EGA00001") // _HID: Hardware ID
Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */)
// _CID: Compatible ID
Name (_S0W, 0x04) // _S0W: S0 Device Wake State
Name (SBFB, ResourceTemplate ()
Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com>
---
v2:
- Fixed compiler warning reported by kernel test robot
drivers/input/touchscreen/exc3000.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/input/touchscreen/exc3000.c b/drivers/input/touchscreen/exc3000.c
index 69eae79e2087..7a52879d8ac3 100644
--- a/drivers/input/touchscreen/exc3000.c
+++ b/drivers/input/touchscreen/exc3000.c
@@ -7,6 +7,7 @@
* minimal implementation based on egalax_ts.c and egalax_i2c.c
*/
+#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/delay.h>
#include <linux/device.h>
@@ -454,10 +455,19 @@ static const struct of_device_id exc3000_of_match[] = {
MODULE_DEVICE_TABLE(of, exc3000_of_match);
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id exc3000_acpi_match[] = {
+ { "EGA00001", .driver_data = (kernel_ulong_t)&exc3000_info[EETI_EXC80H60] },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, exc3000_acpi_match);
+#endif
+
static struct i2c_driver exc3000_driver = {
.driver = {
.name = "exc3000",
.of_match_table = of_match_ptr(exc3000_of_match),
+ .acpi_match_table = ACPI_PTR(exc3000_acpi_match),
},
.id_table = exc3000_id,
.probe_new = exc3000_probe,
--
2.34.1
^ permalink raw reply related
* RE: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit functions.
From: Jingle.Wu @ 2023-07-05 6:09 UTC (permalink / raw)
To: 'Dmitry Torokhov'
Cc: linux-kernel, linux-input, phoenix, josh.chen, dave.wang
In-Reply-To: <ZJ4MVbTnBT5sM5XR@google.com>
HI Dmitry:
1.
> +static void elan_input_lid_event(struct input_handle *handle,
> +unsigned
int type,
> + unsigned int code, int value) {
> + struct elan_tp_data *data, *n;
> +
> + if (type == EV_SW && code == SW_LID) {
> + list_for_each_entry_safe(data, n,
&elan_devices_with_lid_handler,
> +list) {
Why do you need the "_safe()" variant here?
-> Because I took the above link as reference.
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3
578852/7/drivers/hid/hid-multitouch.c#394
2.
> + data->lid_switch = true;
> + INIT_LIST_HEAD(&data->list);
> + INIT_WORK(&data->lid_work, lid_work_handler);
> + list_add_tail(&data->list, &elan_devices_with_lid_handler);
It looks like you call elan_create_lid_handler() from elan_probe() which
means it can be called several times (we should not assume there is only one
controller), I do not see it being destroyed in remove() either, so it will
break if you bind/unbind the driver.
I also not sure why you need the list of you have a handler per device.
-> If the elan_create_lid_handler() function not be put into probe(), the
lid
handler would be invalid in elan private data("struct elan_tp_data *data").
Or do you have any suggestions for it? Thanks.
3.
> + error = elan_create_lid_handler(data);
> + if (error)
> + dev_err(dev, "failed to create lid handler: %d\n", error);
Do we need this on _ALL_ devices with ELan controllers, or just certain
ones? If we need this on all devices how did it work before?
-> Yes, we need this on all device.
In Chromeos kernel v5.4 before, the elan_inhibit()/uninhibit function was
built and worked
successfully in elan_i2c_driver.
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads
/chromeos-5.4/drivers/input/mouse/elan_i2c_core.c#353
Thanks
JINGLE
-----Original Message-----
From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
Sent: Friday, June 30, 2023 6:57 AM
To: jingle.wu <jingle.wu@emc.com.tw>
Cc: linux-kernel@vger.kernel.org; linux-input@vger.kernel.org;
phoenix@emc.com.tw; josh.chen@emc.com.tw; dave.wang@emc.com.tw
Subject: Re: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit
functions.
Hi Jingle,
On Wed, May 31, 2023 at 05:03:40PM +0800, jingle.wu wrote:
> Add inhibit/uninhibit functions.
You need to provide justification for this change, i.e. explain why you need
this/what is currently not working or working sub-optimally.
>
> Signed-off-by: Jingle.wu <jingle.wu@emc.com.tw>
> ---
> drivers/input/mouse/elan_i2c_core.c | 207
> ++++++++++++++++++++++++++++
> 1 file changed, 207 insertions(+)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index 5f0d75a45c80..4ea57f4c7bd4 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -56,6 +56,7 @@ struct elan_tp_data {
> struct input_dev *input;
> struct input_dev *tp_input; /* trackpoint input node */
> struct regulator *vcc;
> + struct list_head list; /* for list of devices needing input handler
*/
>
> const struct elan_transport_ops *ops;
>
> @@ -63,6 +64,11 @@ struct elan_tp_data {
> struct completion fw_completion;
> bool in_fw_update;
>
> + struct work_struct lid_work;
> + bool lid_switch;
> + int lid_value;
> + bool in_inhibit;
> +
> struct mutex sysfs_mutex;
>
> unsigned int max_x;
> @@ -96,6 +102,9 @@ struct elan_tp_data {
> u32 quirks; /* Various quirks */
> };
>
> +static struct workqueue_struct *elan_mode_wq; static
> +LIST_HEAD(elan_devices_with_lid_handler);
> +
> static u32 elan_i2c_lookup_quirks(u16 ic_type, u16 product_id) {
> static const struct {
> @@ -329,6 +338,74 @@ static int elan_initialize(struct elan_tp_data *data,
bool skip_reset)
> return error;
> }
>
> +static int elan_reactivate(struct elan_tp_data *data) {
> + struct device *dev = &data->client->dev;
> + int error;
> +
> + error = elan_set_power(data, true);
> + if (error)
> + dev_err(dev, "failed to restore power: %d\n", error);
> +
> + error = data->ops->sleep_control(data->client, false);
> + if (error) {
> + dev_err(dev,
> + "failed to wake device up: %d\n", error);
> + return error;
> + }
> +
> + return error;
> +}
> +
> +static int elan_inhibit(struct input_dev *input_dev)
I would rather you did not call it inhibit/uninhibit because this is not
what it does.
Please split the logic for recalibration from logic of powering on and off
the device. I also hope in the future firmware revisions the distinction
will be more clear (i.e. have a separate method/command to recalibrate
baseline on demand).
> +{
> + struct elan_tp_data *data = input_get_drvdata(input_dev);
> + struct i2c_client *client = data->client;
> + int error;
> +
> + dev_dbg(&client->dev, "inhibiting\n");
> + /*
> + * We are taking the mutex to make sure sysfs operations are
> + * complete before we attempt to bring the device into low[er]
> + * power mode.
> + */
> + error = mutex_lock_interruptible(&data->sysfs_mutex);
> + if (error)
> + return error;
> +
> + disable_irq(client->irq);
> +
> + error = elan_set_power(data, false);
> + if (error)
> + enable_irq(client->irq);
> +
> + data->in_inhibit = true;
> + mutex_unlock(&data->sysfs_mutex);
> +
> + return error;
> +}
> +
> +static int elan_uninhibit(struct input_dev *input_dev) {
> + struct elan_tp_data *data = input_get_drvdata(input_dev);
> + struct i2c_client *client = data->client;
> + int error;
> +
> + dev_dbg(&client->dev, "uninhibiting\n");
> + error = mutex_lock_interruptible(&data->sysfs_mutex);
> + if (error)
> + return error;
> +
> + error = elan_reactivate(data);
> + if (error == 0)
> + enable_irq(client->irq);
> +
> + data->in_inhibit = false;
> + mutex_unlock(&data->sysfs_mutex);
> +
> + return error;
> +}
> +
> static int elan_query_device_info(struct elan_tp_data *data) {
> int error;
> @@ -1187,6 +1264,124 @@ static void elan_disable_regulator(void *_data)
> regulator_disable(data->vcc);
> }
>
> +static void lid_work_handler(struct work_struct *work) {
> + struct elan_tp_data *data = container_of(work, struct elan_tp_data,
> + lid_work);
> +
> + if (data->lid_value)
> + elan_inhibit(data->input);
> + else
> + elan_uninhibit(data->input);
> +
> +}
> +
> +static void elan_input_lid_event(struct input_handle *handle, unsigned
int type,
> + unsigned int code, int value) {
> + struct elan_tp_data *data, *n;
> +
> + if (type == EV_SW && code == SW_LID) {
> + list_for_each_entry_safe(data, n,
&elan_devices_with_lid_handler,
> +list) {
Why do you need the "_safe()" variant here?
> + data->lid_value = value;
> + queue_work(elan_mode_wq, &data->lid_work);
> + }
> + }
> +
> +}
> +
> +struct elan_input_lid {
> + struct input_handle handle;
> +};
> +
> +static int elan_input_lid_connect(struct input_handler *handler,
> + struct input_dev *dev,
> + const struct input_device_id *id) {
> + struct elan_input_lid *lid;
> + char *name;
> + int error;
> +
> + lid = kzalloc(sizeof(*lid), GFP_KERNEL);
> + if (!lid)
> + return -ENOMEM;
> + name = kasprintf(GFP_KERNEL, "elan-i2c-lid-%s",
dev_name(&dev->dev));
> + if (!name) {
> + error = -ENOMEM;
> + goto err_free_lid;
> + }
> + lid->handle.dev = dev;
> + lid->handle.handler = handler;
> + lid->handle.name = name;
> + lid->handle.private = lid;
> + error = input_register_handle(&lid->handle);
> + if (error)
> + goto err_free_name;
> + error = input_open_device(&lid->handle);
> + if (error)
> + goto err_unregister_handle;
> + return 0;
> +err_unregister_handle:
> + input_unregister_handle(&lid->handle);
> +err_free_name:
> + kfree(name);
> +err_free_lid:
> + kfree(lid);
> + return error;
> +}
> +
> +static void elan_input_lid_disconnect(struct input_handle *handle) {
> + struct elan_input_lid *lid = handle->private;
> +
> + input_close_device(handle);
> + input_unregister_handle(handle);
> + kfree(handle->name);
> + kfree(lid);
> +}
> +
> +static const struct input_device_id elan_input_lid_ids[] = {
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_SWBIT,
> + .evbit = { BIT_MASK(EV_SW) },
> + .swbit = { [BIT_WORD(SW_LID)] = BIT_MASK(SW_LID) },
> + },
> + { },
> +};
> +
> +static struct input_handler elan_input_lid_handler = {
> + .event = elan_input_lid_event,
> + .connect = elan_input_lid_connect,
> + .disconnect = elan_input_lid_disconnect,
> + .name = "elan-i2c-lid",
> + .id_table = elan_input_lid_ids,
> +};
> +
> +static int elan_create_lid_handler(struct elan_tp_data *data) {
> + int error = 0;
> +
> + elan_mode_wq = create_singlethread_workqueue("elan-i2c-lid");
> + if (elan_mode_wq == NULL)
> + return -ENOMEM;
> + error = input_register_handler(&elan_input_lid_handler);
> + if (error)
> + goto remove_wq;
> +
> + data->lid_switch = true;
> + INIT_LIST_HEAD(&data->list);
> + INIT_WORK(&data->lid_work, lid_work_handler);
> + list_add_tail(&data->list, &elan_devices_with_lid_handler);
It looks like you call elan_create_lid_handler() from elan_probe() which
means it can be called several times (we should not assume there is only one
controller), I do not see it being destroyed in remove() either, so it will
break if you bind/unbind the driver.
I also not sure why you need the list of you have a handler per device.
> +
> + return 0;
> +
> +remove_wq:
> + data->lid_switch = false;
> + destroy_workqueue(elan_mode_wq);
> + elan_mode_wq = NULL;
> + return error;
> +}
> +
> static int elan_probe(struct i2c_client *client) {
> const struct elan_transport_ops *transport_ops; @@ -1325,6 +1520,10
> @@ static int elan_probe(struct i2c_client *client)
> }
> }
>
> + error = elan_create_lid_handler(data);
> + if (error)
> + dev_err(dev, "failed to create lid handler: %d\n", error);
Do we need this on _ALL_ devices with ELan controllers, or just certain
ones? If we need this on all devices how did it work before?
> +
> return 0;
> }
>
> @@ -1334,6 +1533,10 @@ static int elan_suspend(struct device *dev)
> struct elan_tp_data *data = i2c_get_clientdata(client);
> int ret;
>
> + /* Wait for switch on completion */
> + if (data->lid_switch)
> + flush_workqueue(elan_mode_wq);
> +
> /*
> * We are taking the mutex to make sure sysfs operations are
> * complete before we attempt to bring the device into low[er] @@
> -1371,6 +1574,10 @@ static int elan_resume(struct device *dev)
> struct elan_tp_data *data = i2c_get_clientdata(client);
> int error;
>
> + /* Wait for switch on completion */
> + if (data->lid_switch)
> + flush_workqueue(elan_mode_wq);
> +
> if (!device_may_wakeup(dev)) {
> error = regulator_enable(data->vcc);
> if (error) {
> --
> 2.34.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH HID v1] HID: nvidia-shield: Pack inner/related declarations in HOSTCMD reports
From: Rahul Rameshbabu @ 2023-07-05 6:04 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rahul Rameshbabu, kernel test robot
Match alignment information in composite type declarations used by packed
HOSTCMD report structures. Compiler packing attribute is not recursive for
inner declarations. Mismatched alignment information can cause undefined
behavior in code generated for accessing composite type members. struct
pointers passed to thunderstrike_parse_board_info_payload and
thunderstrike_parse_haptics_payload are an example of this being
potentially problematic since alignment information from the packed HOSTCMD
report is lost.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202307041500.6bKn7nCl-lkp@intel.com/
Link: https://github.com/llvm/llvm-project/issues/55520#issuecomment-1128617570
Link: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Common-Type-Attributes.html#index-packed-type-attribute
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
---
drivers/hid/hid-nvidia-shield.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-nvidia-shield.c b/drivers/hid/hid-nvidia-shield.c
index 85700cec5eac..a928ad2be62d 100644
--- a/drivers/hid/hid-nvidia-shield.c
+++ b/drivers/hid/hid-nvidia-shield.c
@@ -63,12 +63,12 @@ static_assert(sizeof(enum thunderstrike_led_state) == 1);
struct thunderstrike_hostcmd_board_info {
__le16 revision;
__le16 serial[7];
-};
+} __packed;
struct thunderstrike_hostcmd_haptics {
u8 motor_left;
u8 motor_right;
-};
+} __packed;
struct thunderstrike_hostcmd_resp_report {
u8 report_id; /* THUNDERSTRIKE_HOSTCMD_RESP_REPORT_ID */
@@ -81,7 +81,7 @@ struct thunderstrike_hostcmd_resp_report {
__le16 fw_version;
enum thunderstrike_led_state led_state;
u8 payload[30];
- };
+ } __packed;
} __packed;
static_assert(sizeof(struct thunderstrike_hostcmd_resp_report) ==
THUNDERSTRIKE_HOSTCMD_REPORT_SIZE);
@@ -92,15 +92,15 @@ struct thunderstrike_hostcmd_req_report {
u8 reserved_at_10;
union {
- struct {
+ struct __packed {
u8 update;
enum thunderstrike_led_state state;
} led;
- struct {
+ struct __packed {
u8 update;
struct thunderstrike_hostcmd_haptics motors;
} haptics;
- };
+ } __packed;
u8 reserved_at_30[27];
} __packed;
static_assert(sizeof(struct thunderstrike_hostcmd_req_report) ==
--
2.40.1
^ permalink raw reply related
* [PATCH 10/10] Input: lpc32xx_ts - Convert to use devm_* api
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov, Vladimir Zapolskiy
Cc: Yangtao Li, linux-input, linux-arm-kernel, linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Use devm_* api to simplify code, this makes it unnecessary to explicitly
release resources.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/touchscreen/lpc32xx_ts.c | 75 +++++---------------------
1 file changed, 14 insertions(+), 61 deletions(-)
diff --git a/drivers/input/touchscreen/lpc32xx_ts.c b/drivers/input/touchscreen/lpc32xx_ts.c
index ffdd748a9992..d30ce1380f72 100644
--- a/drivers/input/touchscreen/lpc32xx_ts.c
+++ b/drivers/input/touchscreen/lpc32xx_ts.c
@@ -198,54 +198,34 @@ static void lpc32xx_ts_close(struct input_dev *dev)
static int lpc32xx_ts_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct lpc32xx_tsc *tsc;
struct input_dev *input;
- struct resource *res;
- resource_size_t size;
int irq;
int error;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Can't get memory resource\n");
- return -ENOENT;
- }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
- tsc = kzalloc(sizeof(*tsc), GFP_KERNEL);
- input = input_allocate_device();
+ tsc = devm_kzalloc(dev, sizeof(*tsc), GFP_KERNEL);
+ input = devm_input_allocate_device(dev);
if (!tsc || !input) {
dev_err(&pdev->dev, "failed allocating memory\n");
- error = -ENOMEM;
- goto err_free_mem;
+ return -ENOMEM;
}
tsc->dev = input;
tsc->irq = irq;
- size = resource_size(res);
-
- if (!request_mem_region(res->start, size, pdev->name)) {
- dev_err(&pdev->dev, "TSC registers are not free\n");
- error = -EBUSY;
- goto err_free_mem;
- }
-
- tsc->tsc_base = ioremap(res->start, size);
- if (!tsc->tsc_base) {
- dev_err(&pdev->dev, "Can't map memory\n");
- error = -ENOMEM;
- goto err_release_mem;
- }
+ tsc->tsc_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(tsc->tsc_base))
+ return PTR_ERR(tsc->tsc_base);
- tsc->clk = clk_get(&pdev->dev, NULL);
+ tsc->clk = devm_clk_get(dev, NULL);
if (IS_ERR(tsc->clk)) {
dev_err(&pdev->dev, "failed getting clock\n");
- error = PTR_ERR(tsc->clk);
- goto err_unmap;
+ return PTR_ERR(tsc->clk);
}
input->name = MOD_NAME;
@@ -267,58 +247,31 @@ static int lpc32xx_ts_probe(struct platform_device *pdev)
input_set_drvdata(input, tsc);
- error = request_irq(tsc->irq, lpc32xx_ts_interrupt,
- 0, pdev->name, tsc);
+ error = devm_request_irq(dev, tsc->irq, lpc32xx_ts_interrupt,
+ 0, pdev->name, tsc);
if (error) {
dev_err(&pdev->dev, "failed requesting interrupt\n");
- goto err_put_clock;
+ return error;
}
error = input_register_device(input);
if (error) {
dev_err(&pdev->dev, "failed registering input device\n");
- goto err_free_irq;
+ return error;
}
platform_set_drvdata(pdev, tsc);
- device_init_wakeup(&pdev->dev, 1);
+ device_init_wakeup(&pdev->dev, true);
return 0;
-
-err_free_irq:
- free_irq(tsc->irq, tsc);
-err_put_clock:
- clk_put(tsc->clk);
-err_unmap:
- iounmap(tsc->tsc_base);
-err_release_mem:
- release_mem_region(res->start, size);
-err_free_mem:
- input_free_device(input);
- kfree(tsc);
-
- return error;
}
static int lpc32xx_ts_remove(struct platform_device *pdev)
{
struct lpc32xx_tsc *tsc = platform_get_drvdata(pdev);
- struct resource *res;
lpc32xx_stop_tsc(tsc);
- free_irq(tsc->irq, tsc);
-
- input_unregister_device(tsc->dev);
-
- clk_put(tsc->clk);
-
- iounmap(tsc->tsc_base);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, resource_size(res));
-
- kfree(tsc);
-
return 0;
}
--
2.39.0
^ permalink raw reply related
* [PATCH 09/10] Input: lpc32xx_ts - stop_tsc when driver remove
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov, Vladimir Zapolskiy, Kevin Wells,
Durgesh Pattamatta
Cc: Yangtao Li, Dmitry Torokhov, linux-input, linux-arm-kernel,
linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
When the driver is removed, we need to close the device.
Fixes: 3045a5f5202a ("Input: add LPC32xx touchscreen controller driver")
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/touchscreen/lpc32xx_ts.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/lpc32xx_ts.c b/drivers/input/touchscreen/lpc32xx_ts.c
index 15b5cb763526..ffdd748a9992 100644
--- a/drivers/input/touchscreen/lpc32xx_ts.c
+++ b/drivers/input/touchscreen/lpc32xx_ts.c
@@ -305,6 +305,8 @@ static int lpc32xx_ts_remove(struct platform_device *pdev)
struct lpc32xx_tsc *tsc = platform_get_drvdata(pdev);
struct resource *res;
+ lpc32xx_stop_tsc(tsc);
+
free_irq(tsc->irq, tsc);
input_unregister_device(tsc->dev);
--
2.39.0
^ permalink raw reply related
* [PATCH 08/10] Input: nomadik-ske-keypad - Convert to use devm_* api
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Yangtao Li, linux-input, linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Use devm_* api to simplify code, this makes it unnecessary to explicitly
release resources.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/keyboard/nomadik-ske-keypad.c | 76 +++++----------------
1 file changed, 18 insertions(+), 58 deletions(-)
diff --git a/drivers/input/keyboard/nomadik-ske-keypad.c b/drivers/input/keyboard/nomadik-ske-keypad.c
index 970f2a671c2e..93318324e9e0 100644
--- a/drivers/input/keyboard/nomadik-ske-keypad.c
+++ b/drivers/input/keyboard/nomadik-ske-keypad.c
@@ -225,9 +225,9 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
{
const struct ske_keypad_platform_data *plat =
dev_get_platdata(&pdev->dev);
+ struct device *dev = &pdev->dev;
struct ske_keypad *keypad;
struct input_dev *input;
- struct resource *res;
int irq;
int error;
@@ -238,20 +238,14 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq < 0)
- return -EINVAL;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "missing platform resources\n");
- return -EINVAL;
- }
+ return irq;
- keypad = kzalloc(sizeof(struct ske_keypad), GFP_KERNEL);
- input = input_allocate_device();
+ keypad = devm_kzalloc(dev, sizeof(struct ske_keypad),
+ GFP_KERNEL);
+ input = devm_input_allocate_device(dev);
if (!keypad || !input) {
dev_err(&pdev->dev, "failed to allocate keypad memory\n");
- error = -ENOMEM;
- goto err_free_mem;
+ return -ENOMEM;
}
keypad->irq = irq;
@@ -259,31 +253,20 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
keypad->input = input;
spin_lock_init(&keypad->ske_keypad_lock);
- if (!request_mem_region(res->start, resource_size(res), pdev->name)) {
- dev_err(&pdev->dev, "failed to request I/O memory\n");
- error = -EBUSY;
- goto err_free_mem;
- }
-
- keypad->reg_base = ioremap(res->start, resource_size(res));
- if (!keypad->reg_base) {
- dev_err(&pdev->dev, "failed to remap I/O memory\n");
- error = -ENXIO;
- goto err_free_mem_region;
- }
+ keypad->reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(keypad->reg_base))
+ return PTR_ERR(keypad->reg_base);
- keypad->pclk = clk_get(&pdev->dev, "apb_pclk");
+ keypad->pclk = devm_clk_get(dev, "apb_pclk");
if (IS_ERR(keypad->pclk)) {
dev_err(&pdev->dev, "failed to get pclk\n");
- error = PTR_ERR(keypad->pclk);
- goto err_iounmap;
+ return PTR_ERR(keypad->pclk);
}
- keypad->clk = clk_get(&pdev->dev, NULL);
+ keypad->clk = devm_clk_get(dev, NULL);
if (IS_ERR(keypad->clk)) {
dev_err(&pdev->dev, "failed to get clk\n");
- error = PTR_ERR(keypad->clk);
- goto err_pclk;
+ return PTR_ERR(keypad->clk);
}
input->id.bustype = BUS_HOST;
@@ -295,7 +278,7 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
keypad->keymap, input);
if (error) {
dev_err(&pdev->dev, "Failed to build keymap\n");
- goto err_clk;
+ return error;
}
input_set_capability(input, EV_MSC, MSC_SCAN);
@@ -305,7 +288,7 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
error = clk_prepare_enable(keypad->pclk);
if (error) {
dev_err(&pdev->dev, "Failed to prepare/enable pclk\n");
- goto err_clk;
+ return error;
}
error = clk_prepare_enable(keypad->clk);
@@ -314,7 +297,6 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
goto err_pclk_disable;
}
-
/* go through board initialization helpers */
if (keypad->board->init)
keypad->board->init();
@@ -325,8 +307,8 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
goto err_clk_disable;
}
- error = request_threaded_irq(keypad->irq, NULL, ske_keypad_irq,
- IRQF_ONESHOT, "ske-keypad", keypad);
+ error = devm_request_threaded_irq(dev, keypad->irq, NULL, ske_keypad_irq,
+ IRQF_ONESHOT, "ske-keypad", keypad);
if (error) {
dev_err(&pdev->dev, "allocate irq %d failed\n", keypad->irq);
goto err_clk_disable;
@@ -336,7 +318,7 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
if (error) {
dev_err(&pdev->dev,
"unable to register input device: %d\n", error);
- goto err_free_irq;
+ goto err_clk_disable;
}
if (plat->wakeup_enable)
@@ -346,34 +328,16 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
return 0;
-err_free_irq:
- free_irq(keypad->irq, keypad);
err_clk_disable:
clk_disable_unprepare(keypad->clk);
err_pclk_disable:
clk_disable_unprepare(keypad->pclk);
-err_clk:
- clk_put(keypad->clk);
-err_pclk:
- clk_put(keypad->pclk);
-err_iounmap:
- iounmap(keypad->reg_base);
-err_free_mem_region:
- release_mem_region(res->start, resource_size(res));
-err_free_mem:
- input_free_device(input);
- kfree(keypad);
return error;
}
static int ske_keypad_remove(struct platform_device *pdev)
{
struct ske_keypad *keypad = platform_get_drvdata(pdev);
- struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- free_irq(keypad->irq, keypad);
-
- input_unregister_device(keypad->input);
clk_disable_unprepare(keypad->clk);
clk_put(keypad->clk);
@@ -381,10 +345,6 @@ static int ske_keypad_remove(struct platform_device *pdev)
if (keypad->board->exit)
keypad->board->exit();
- iounmap(keypad->reg_base);
- release_mem_region(res->start, resource_size(res));
- kfree(keypad);
-
return 0;
}
--
2.39.0
^ permalink raw reply related
* [PATCH 07/10] Input: sun4i-lradc-keys - Convert to devm_platform_ioremap_resource()
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland
Cc: Yangtao Li, linux-input, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/keyboard/sun4i-lradc-keys.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c b/drivers/input/keyboard/sun4i-lradc-keys.c
index 15c15c0958b0..95d927cc8b7e 100644
--- a/drivers/input/keyboard/sun4i-lradc-keys.c
+++ b/drivers/input/keyboard/sun4i-lradc-keys.c
@@ -307,8 +307,7 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
input_set_drvdata(lradc->input, lradc);
- lradc->base = devm_ioremap_resource(dev,
- platform_get_resource(pdev, IORESOURCE_MEM, 0));
+ lradc->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(lradc->base))
return PTR_ERR(lradc->base);
--
2.39.0
^ permalink raw reply related
* [PATCH 06/10] Input: pxa27x_keypad - Convert to devm_platform_ioremap_resource()
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Yangtao Li, linux-input, linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/keyboard/pxa27x_keypad.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/pxa27x_keypad.c b/drivers/input/keyboard/pxa27x_keypad.c
index 871f858d0ba7..3724363d140e 100644
--- a/drivers/input/keyboard/pxa27x_keypad.c
+++ b/drivers/input/keyboard/pxa27x_keypad.c
@@ -717,7 +717,6 @@ static int pxa27x_keypad_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct pxa27x_keypad *keypad;
struct input_dev *input_dev;
- struct resource *res;
int irq, error;
/* Driver need build keycode from device tree or pdata */
@@ -728,12 +727,6 @@ static int pxa27x_keypad_probe(struct platform_device *pdev)
if (irq < 0)
return -ENXIO;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(&pdev->dev, "failed to get I/O memory\n");
- return -ENXIO;
- }
-
keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad),
GFP_KERNEL);
if (!keypad)
@@ -747,7 +740,7 @@ static int pxa27x_keypad_probe(struct platform_device *pdev)
keypad->input_dev = input_dev;
keypad->irq = irq;
- keypad->mmio_base = devm_ioremap_resource(&pdev->dev, res);
+ keypad->mmio_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(keypad->mmio_base))
return PTR_ERR(keypad->mmio_base);
--
2.39.0
^ permalink raw reply related
* [PATCH 05/10] Input: opencores-kbd - Convert to devm_platform_ioremap_resource()
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Yangtao Li, linux-input, linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/keyboard/opencores-kbd.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/opencores-kbd.c b/drivers/input/keyboard/opencores-kbd.c
index b0ea387414c1..7ffe1a70c856 100644
--- a/drivers/input/keyboard/opencores-kbd.c
+++ b/drivers/input/keyboard/opencores-kbd.c
@@ -39,15 +39,8 @@ static int opencores_kbd_probe(struct platform_device *pdev)
{
struct input_dev *input;
struct opencores_kbd *opencores_kbd;
- struct resource *res;
int irq, i, error;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "missing board memory resource\n");
- return -EINVAL;
- }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return -EINVAL;
@@ -65,7 +58,7 @@ static int opencores_kbd_probe(struct platform_device *pdev)
opencores_kbd->input = input;
- opencores_kbd->addr = devm_ioremap_resource(&pdev->dev, res);
+ opencores_kbd->addr = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(opencores_kbd->addr))
return PTR_ERR(opencores_kbd->addr);
--
2.39.0
^ permalink raw reply related
* [PATCH 04/10] Input: omap4-keyad - Convert to devm_platform_ioremap_resource()
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Yangtao Li, linux-input, linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/keyboard/omap4-keypad.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
index 9f085d5679db..773e55eed88b 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -341,17 +341,10 @@ static int omap4_keypad_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct omap4_keypad *keypad_data;
struct input_dev *input_dev;
- struct resource *res;
unsigned int max_keys;
int irq;
int error;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "no base address specified\n");
- return -EINVAL;
- }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
@@ -370,7 +363,7 @@ static int omap4_keypad_probe(struct platform_device *pdev)
if (error)
return error;
- keypad_data->base = devm_ioremap_resource(dev, res);
+ keypad_data->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(keypad_data->base))
return PTR_ERR(keypad_data->base);
--
2.39.0
^ permalink raw reply related
* [PATCH 03/10] Input: nspire-keypad - Use devm_platform_get_and_ioremap_resource()
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Yangtao Li, linux-input, linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/keyboard/nspire-keypad.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/nspire-keypad.c b/drivers/input/keyboard/nspire-keypad.c
index e9fa1423f136..096c18d7bca1 100644
--- a/drivers/input/keyboard/nspire-keypad.c
+++ b/drivers/input/keyboard/nspire-keypad.c
@@ -186,8 +186,7 @@ static int nspire_keypad_probe(struct platform_device *pdev)
return PTR_ERR(keypad->clk);
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- keypad->reg_base = devm_ioremap_resource(&pdev->dev, res);
+ keypad->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(keypad->reg_base))
return PTR_ERR(keypad->reg_base);
--
2.39.0
^ permalink raw reply related
* [PATCH 02/10] Input: lpc32xx-keys - Convert to devm_platform_ioremap_resource()
From: Yangtao Li @ 2023-07-05 5:23 UTC (permalink / raw)
To: Dmitry Torokhov, Vladimir Zapolskiy
Cc: Yangtao Li, linux-input, linux-arm-kernel, linux-kernel
In-Reply-To: <20230705052346.39337-1-frank.li@vivo.com>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
drivers/input/keyboard/lpc32xx-keys.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/lpc32xx-keys.c b/drivers/input/keyboard/lpc32xx-keys.c
index 911e1181cd6f..322a87807159 100644
--- a/drivers/input/keyboard/lpc32xx-keys.c
+++ b/drivers/input/keyboard/lpc32xx-keys.c
@@ -160,17 +160,10 @@ static int lpc32xx_kscan_probe(struct platform_device *pdev)
{
struct lpc32xx_kscan_drv *kscandat;
struct input_dev *input;
- struct resource *res;
size_t keymap_size;
int error;
int irq;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "failed to get platform I/O memory\n");
- return -EINVAL;
- }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return -EINVAL;
@@ -221,7 +214,7 @@ static int lpc32xx_kscan_probe(struct platform_device *pdev)
input_set_drvdata(kscandat->input, kscandat);
- kscandat->kscan_base = devm_ioremap_resource(&pdev->dev, res);
+ kscandat->kscan_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(kscandat->kscan_base))
return PTR_ERR(kscandat->kscan_base);
--
2.39.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