* Re: [PATCH 1/2] drivers: base: swnode: link devices to software nodes
From: Dmitry Torokhov @ 2019-07-29 13:15 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Linus Walleij, Rafael J . Wysocki,
Enrico Weigelt, metux IT consult, linux-input, linux-gpio,
linux-kernel, Andy Shevchenko
In-Reply-To: <20190729120715.GA28600@kuha.fi.intel.com>
On Mon, Jul 29, 2019 at 03:07:15PM +0300, Heikki Krogerus wrote:
> On Sat, Jul 13, 2019 at 12:52:58AM -0700, Dmitry Torokhov wrote:
> > It is helpful to know what device, if any, a software node is tied to, so
> > let's store a pointer to the device in software node structure. Note that
> > children software nodes will inherit their parent's device pointer, so we
> > do not have to traverse hierarchy to see what device the [sub]tree belongs
> > to.
> >
> > We will be using the device pointer to locate GPIO lookup tables for
> > devices with static properties.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> > drivers/base/property.c | 1 +
> > drivers/base/swnode.c | 35 ++++++++++++++++++++++++++++++++++-
> > include/linux/property.h | 5 +++++
> > 3 files changed, 40 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > index 348b37e64944..3bc93d4b35c4 100644
> > --- a/drivers/base/property.c
> > +++ b/drivers/base/property.c
> > @@ -527,6 +527,7 @@ int device_add_properties(struct device *dev,
> > if (IS_ERR(fwnode))
> > return PTR_ERR(fwnode);
> >
> > + software_node_link_device(fwnode, dev);
> > set_secondary_fwnode(dev, fwnode);
> > return 0;
> > }
> > diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> > index 7fc5a18e02ad..fd12eea539b6 100644
> > --- a/drivers/base/swnode.c
> > +++ b/drivers/base/swnode.c
> > @@ -24,6 +24,9 @@ struct software_node {
> >
> > /* properties */
> > const struct property_entry *properties;
> > +
> > + /* device this node is associated with */
> > + struct device *dev;
> > };
>
> Let's not do that! The nodes can be, and in many cases are, associated
> with multiple devices.
They do? Where? I see that set of properties can be shared between
several devices, but when we instantiate SW node we create a new
instance for device. This is also how ACPI and OF properties work; they
not shared between devices (or, rather, the kernel creates distinct _and
single_ devices for instance of ACPI or OF node). I do not think we want
swnodes work differently from the other firmware nodes.
>
> Every device is already linked with the software node kobject, so
> isn't it possible to simply walk trough those links in order to check
> the devices associated with the node?
No, we need to know the exact instance of a device, not a set of
devices, because even though some properties can be shared, others can
not. For example, even if 2 exactly same touch controllers in the system
have "reset-gpios" property, they won't be the same GPIO for the both of
them.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: applespi - register touchpad device synchronously in probe
From: Dmitry Torokhov @ 2019-07-29 13:22 UTC (permalink / raw)
To: Ronald Tschalär
Cc: Andy Shevchenko, Mao Wenan, Federico Lorenzi, linux-input,
linux-kernel
In-Reply-To: <20190721070523.24695-1-ronald@innovation.ch>
Hi Ronald,
On Sun, Jul 21, 2019 at 12:05:23AM -0700, Ronald Tschalär wrote:
> This allows errors during registration to properly fail the probe
> function.
>
> Doing this requires waiting for a response from the device inside the
> probe function. While this generally takes about 15ms, in case of errors
> it could be arbitrarily long, and hence a 3 second timeout is used.
>
> This also adds 3 second timeouts to the drain functions to avoid the
> potential for suspend or remove hanging forever.
Question: is it possible to read command response synchronously as well?
I.e. I was wondering if we could add 2 (or 1?) more read xfers for the
actual result that is coming after the status response, and then we
could use spi_sync() to send the command and read the whole thing.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: applespi - Fix build error
From: Dmitry Torokhov @ 2019-07-29 14:04 UTC (permalink / raw)
To: YueHaibing; +Cc: ronald, nikolas, linux-kernel, linux-input
In-Reply-To: <20190729031455.59400-1-yuehaibing@huawei.com>
On Mon, Jul 29, 2019 at 11:14:55AM +0800, YueHaibing wrote:
> If CONFIG_KEYBOARD_APPLESPI=y but CONFIG_LEDS_CLASS=m
> building fails:
>
> drivers/input/keyboard/applespi.o: In function `applespi_probe':
> applespi.c:(.text+0x1fcd): undefined reference to `devm_led_classdev_register_ext'
>
> Wrap it in LEDS_CLASS macro to fix this.
No, we should add "depends on LEDS_CLASS" to the Konfig instead.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] input: misc: soc_button_array: use platform_device_register_resndata()
From: Enrico Weigelt, metux IT consult @ 2019-07-29 14:26 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, linux-input
From: Enrico Weigelt <info@metux.net>
The registration of gpio-keys device can be written much shorter
by using the platform_device_register_resndata() helper.
Signed-off-by: Enrico Weigelt <info@metux.net>
---
drivers/input/misc/soc_button_array.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 5e59f8e5..f5e148b 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -110,25 +110,21 @@ static int soc_button_lookup_gpio(struct device *dev, int acpi_index)
gpio_keys_pdata->nbuttons = n_buttons;
gpio_keys_pdata->rep = autorepeat;
- pd = platform_device_alloc("gpio-keys", PLATFORM_DEVID_AUTO);
- if (!pd) {
- error = -ENOMEM;
+ pd = platform_device_register_resndata(NULL,
+ "gpio-keys",
+ PLATFORM_DEVID_AUTO,
+ NULL,
+ 0,
+ gpio_keys_pdata,
+ sizeof(*gpio_keys_pdata));
+
+ if (IS_ERR(pd)) {
+ dev_err(&pdev->dev, "failed registering gpio-keys: %ld\n", PTR_ERR(pd));
goto err_free_mem;
}
- error = platform_device_add_data(pd, gpio_keys_pdata,
- sizeof(*gpio_keys_pdata));
- if (error)
- goto err_free_pdev;
-
- error = platform_device_add(pd);
- if (error)
- goto err_free_pdev;
-
return pd;
-err_free_pdev:
- platform_device_put(pd);
err_free_mem:
devm_kfree(&pdev->dev, gpio_keys_pdata);
return ERR_PTR(error);
--
1.9.1
^ permalink raw reply related
* Re: [Regression] 5.3-rc1: hid_llogitech_dj does not work
From: Hans de Goede @ 2019-07-29 15:49 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing, Benjamin Tissoires, Jiri Kosina,
linux-input
In-Reply-To: <1dddedba-ca02-1014-36e0-ba4e3631f28b@redhat.com>
Hi Rafael,
On 25-07-19 17:50, Hans de Goede wrote:
> Hi Rafael,
>
> On 25-07-19 12:07, Rafael J. Wysocki wrote:
>> Hi Hans,
>>
>> This is similar to a problem I reported some time ago:
>>
>> https://lore.kernel.org/lkml/2268131.Lc39eCoc3j@kreacher/
>>
>> and the device affected by it is the same.
>>
>> The symptom is simply that the mouse just doesn't work (no reaction). If I do
>> "rmmod hid_llogitech_dj", it says "Killed", but the module does go away and
>> the mouse starts to work (through the generic code I suppose), but then
>> the machine hangs on attempts to suspend (nasty).
>>
>> Reverting all of the hid_llogitech_dj changes between 5.2 and 5.3-rc1:
>>
>> dbcbabf7da92 HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices
>> 39d21e7e0043 HID: logitech-dj: make const array template static
>> 423dfbc362b7 HID: logitech-dj: Add usb-id for the 27MHz MX3000 receiver
>>
>> helps here, but the first two don't really look like they can make any difference,
>> so I guess I'm an unlucky owner of a MX3000 that doesn't quite work as expected.
>>
>> Any help will be appreciated. :-)
>
> Actually we received another bug report about this and the reporter there
> has come up with a patch with points to
>
> dbcbabf7da92 HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices
>
> Being the culprit, can you try just reverting that one?
>
> I will take a closer look at this soonish.
Thank you for reporting this.
After upgrading to 5.3-rc2 I can reproduce this myself and the dbcbabf7da92 commit
indeed is the culprit. I've prepared a fix for this which I'm about to submit upstream.
I've put you in the Cc of the fix.
Regards,
Hans
^ permalink raw reply
* [PATCH 1/2] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Enrico Weigelt, metux IT consult @ 2019-07-29 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, linux-input
From: Enrico Weigelt <info@metux.net>
Support the recently introduced gpio lookup tables for
attaching to gpio lines. So, harcoded gpio numbers aren't
needed anymore.
changes v3:
* fix printf string in gpio_keys_polled_get_gpiod()
* fix unused variable 'error' in gpio_keys_polled_get_gpiod()
* fix uninitialized variable in gpio_keys_polled_get_gpiod_fwnode()
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Enrico Weigelt <info@metux.net>
---
drivers/input/keyboard/gpio_keys_polled.c | 166 +++++++++++++++++++++---------
1 file changed, 118 insertions(+), 48 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 465eecf..91754de 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -21,6 +21,7 @@
#include <linux/platform_device.h>
#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
+#include <linux/gpio/machine.h>
#include <linux/gpio_keys.h>
#include <linux/property.h>
@@ -226,6 +227,118 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
};
MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
+static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
+ struct device *dev,
+ int idx,
+ const char *desc)
+{
+ struct gpio_desc *gpiod;
+ struct fwnode_handle *child;
+ int x = idx;
+
+ /* get the idx'th child node */
+ child = device_get_next_child_node(dev, NULL);
+ while (child && x) {
+ child = device_get_next_child_node(dev, child);
+ x--;
+ }
+
+ if (!child) {
+ dev_err(dev, "missing oftree child node #%d\n", idx);
+ return ERR_PTR(-EINVAL);
+ }
+
+ gpiod = devm_fwnode_get_gpiod_from_child(dev,
+ NULL,
+ child,
+ GPIOD_IN,
+ desc);
+ if (IS_ERR(gpiod)) {
+ if (PTR_ERR(gpiod) != -EPROBE_DEFER)
+ dev_err(dev,
+ "failed to get gpio: %ld\n",
+ PTR_ERR(gpiod));
+ fwnode_handle_put(child);
+ return gpiod;
+ }
+
+ return gpiod;
+}
+
+static struct gpio_desc *gpio_keys_polled_get_gpiod_legacy(
+ struct device *dev,
+ int idx,
+ const struct gpio_keys_button *button)
+{
+ /*
+ * Legacy GPIO number so request the GPIO here and
+ * convert it to descriptor.
+ */
+ unsigned int flags = GPIOF_IN;
+ struct gpio_desc *gpiod;
+ int error;
+
+ dev_info(dev, "hardcoded gpio IDs are deprecated.\n");
+
+ if (button->active_low)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ error = devm_gpio_request_one(dev, button->gpio,
+ flags, button->desc ? : DRV_NAME);
+ if (error) {
+ dev_err(dev,
+ "unable to claim gpio %u, err=%d\n",
+ button->gpio, error);
+ return ERR_PTR(error);
+ }
+
+ gpiod = gpio_to_desc(button->gpio);
+ if (!gpiod) {
+ dev_err(dev,
+ "unable to convert gpio %u to descriptor\n",
+ button->gpio);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return gpiod;
+}
+
+static struct gpio_desc *gpio_keys_polled_get_gpiod(
+ struct device *dev,
+ int idx,
+ const struct gpio_keys_button *button)
+{
+ struct gpio_desc *gpiod = NULL;
+
+ /* No legacy static platform data - use oftree */
+ if (!dev_get_platdata(dev)) {
+ return gpio_keys_polled_get_gpiod_fwnode(
+ dev, idx, button->desc);
+ }
+
+ gpiod = devm_gpiod_get_index(dev, NULL, idx, GPIOF_IN);
+
+ if (!IS_ERR(gpiod)) {
+ dev_info(dev, "picked gpiod idx %d from gpio table\n", idx);
+ gpiod_set_consumer_name(gpiod, button->desc ? : DRV_NAME);
+ return gpiod;
+ }
+
+ if (PTR_ERR(gpiod) != -ENOENT) {
+ dev_err(dev, "failed fetching gpiod #%d: %ld\n",
+ idx, PTR_ERR(gpiod));
+ return gpiod;
+ }
+
+ /* Use legacy gpio id, if defined */
+ if (gpio_is_valid(button->gpio)) {
+ return gpio_keys_polled_get_gpiod_legacy(
+ dev, idx, button);
+ }
+
+ return ERR_PTR(-ENOENT);
+}
+
static int gpio_keys_polled_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -288,57 +401,14 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
if (button->wakeup) {
dev_err(dev, DRV_NAME " does not support wakeup\n");
- fwnode_handle_put(child);
return -EINVAL;
}
- if (!dev_get_platdata(dev)) {
- /* No legacy static platform data */
- child = device_get_next_child_node(dev, child);
- if (!child) {
- dev_err(dev, "missing child device node\n");
- return -EINVAL;
- }
-
- bdata->gpiod = devm_fwnode_get_gpiod_from_child(dev,
- NULL, child,
- GPIOD_IN,
- button->desc);
- if (IS_ERR(bdata->gpiod)) {
- error = PTR_ERR(bdata->gpiod);
- if (error != -EPROBE_DEFER)
- dev_err(dev,
- "failed to get gpio: %d\n",
- error);
- fwnode_handle_put(child);
- return error;
- }
- } else if (gpio_is_valid(button->gpio)) {
- /*
- * Legacy GPIO number so request the GPIO here and
- * convert it to descriptor.
- */
- unsigned flags = GPIOF_IN;
-
- if (button->active_low)
- flags |= GPIOF_ACTIVE_LOW;
-
- error = devm_gpio_request_one(dev, button->gpio,
- flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
-
- bdata->gpiod = gpio_to_desc(button->gpio);
- if (!bdata->gpiod) {
- dev_err(dev,
- "unable to convert gpio %u to descriptor\n",
- button->gpio);
- return -EINVAL;
- }
+ bdata->gpiod = gpio_keys_polled_get_gpiod(dev, i, button);
+
+ if (IS_ERR(bdata->gpiod)) {
+ dev_err(dev, "failed to fetch gpiod #%d\n", i);
+ return PTR_ERR(bdata->gpiod);
}
bdata->last_state = -1;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] input: keyboard: gpio-keys-polled: skip oftree code when CONFIG_OF disabled
From: Enrico Weigelt, metux IT consult @ 2019-07-29 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <1564415994-22871-1-git-send-email-info@metux.net>
we don't need to build in oftree probing stuff when oftree isn't
enabled at all.
changes v2: use of_match_ptr() macro instead of ifdef's
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
drivers/input/keyboard/gpio_keys_polled.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 91754de..d8123ad 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -144,6 +144,7 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
static struct gpio_keys_platform_data *
gpio_keys_polled_get_devtree_pdata(struct device *dev)
{
+#ifdef CONFIG_OF
struct gpio_keys_platform_data *pdata;
struct gpio_keys_button *button;
struct fwnode_handle *child;
@@ -199,6 +200,9 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
}
return pdata;
+#else /* CONFIG_OF */
+ return ERR_PTR(-ENOENT);
+#endif /* CONFIG_OF */
}
static void gpio_keys_polled_set_abs_params(struct input_dev *input,
@@ -221,11 +225,13 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
input_set_abs_params(input, code, min, max, 0, 0);
}
+#ifdef CONFIG_OF
static const struct of_device_id gpio_keys_polled_of_match[] = {
{ .compatible = "gpio-keys-polled", },
{ },
};
MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
+#endif /* CONFIG_OF */
static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
struct device *dev,
@@ -448,7 +454,7 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
.probe = gpio_keys_polled_probe,
.driver = {
.name = DRV_NAME,
- .of_match_table = gpio_keys_polled_of_match,
+ .of_match_table = of_match_ptr(gpio_keys_polled_of_match),
},
};
module_platform_driver(gpio_keys_polled_driver);
--
1.9.1
^ permalink raw reply related
* WARNING in usbtouch_open
From: syzbot @ 2019-07-29 16:38 UTC (permalink / raw)
To: allison, andreyknvl, dmitry.torokhov, gregkh, kstewart,
linux-input, linux-kernel, linux-usb, mpe, rydberg,
syzkaller-bugs, tglx
Hello,
syzbot found the following crash on:
HEAD commit: 7f7867ff usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1503f4ec600000
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=199ea16c7f26418b4365
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=173e4442600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=115482b2600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+199ea16c7f26418b4365@syzkaller.appspotmail.com
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 0 PID: 1724 at kernel/locking/mutex.c:912 __mutex_lock_common
kernel/locking/mutex.c:912 [inline]
WARNING: CPU: 0 PID: 1724 at kernel/locking/mutex.c:912
__mutex_lock+0xd31/0x1360 kernel/locking/mutex.c:1077
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 1724 Comm: syz-executor025 Not tainted 5.3.0-rc2+ #23
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
panic+0x2a3/0x6da kernel/panic.c:219
__warn.cold+0x20/0x4a kernel/panic.c:576
report_bug+0x262/0x2a0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272
do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1026
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:912 [inline]
RIP: 0010:__mutex_lock+0xd31/0x1360 kernel/locking/mutex.c:1077
Code: d2 0f 85 f6 05 00 00 44 8b 05 bb 99 0a 02 45 85 c0 0f 85 0a f4 ff ff
48 c7 c6 00 87 a6 85 48 c7 c7 a0 84 a6 85 e8 f4 24 b8 fb <0f> 0b e9 f0 f3
ff ff 65 48 8b 1c 25 00 ef 01 00 be 08 00 00 00 48
RSP: 0018:ffff8881d29cf740 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff812830fd RDI: ffffed103a539eda
RBP: ffff8881d29cf8b0 R08: ffff8881d3e84800 R09: fffffbfff0d5eb25
R10: fffffbfff0d5eb24 R11: ffffffff86af5923 R12: 0000000000000000
R13: dffffc0000000000 R14: ffff8881d33cdbc8 R15: ffff8881d3e97140
usbtouch_open+0x101/0x310 drivers/input/touchscreen/usbtouchscreen.c:1537
input_open_device+0x170/0x280 drivers/input/input.c:607
evdev_open_device drivers/input/evdev.c:433 [inline]
evdev_open+0x3fe/0x510 drivers/input/evdev.c:518
chrdev_open+0x219/0x5c0 fs/char_dev.c:414
do_dentry_open+0x494/0x1120 fs/open.c:797
do_last fs/namei.c:3416 [inline]
path_openat+0x1430/0x3f50 fs/namei.c:3533
do_filp_open+0x1a1/0x280 fs/namei.c:3563
do_sys_open+0x3c0/0x580 fs/open.c:1089
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4011f0
Code: 01 f0 ff ff 0f 83 00 0b 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 83 3d 9d 4b 2d 00 00 75 14 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 d4 0a 00 00 c3 48 83 ec 08 e8 3a 00 00 00
RSP: 002b:00007ffc88d90d38 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 0000000000000124 RCX: 00000000004011f0
RDX: 0000000000000000 RSI: 0000000000020000 RDI: 00007ffc88d90d40
RBP: 6666666666666667 R08: 000000000000000f R09: 0000000000000023
R10: 0000000000000075 R11: 0000000000000246 R12: 0000000000402150
R13: 00000000004021e0 R14: 0000000000000000 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] input: misc: soc_button_array: use platform_device_register_resndata()
From: Dmitry Torokhov @ 2019-07-29 17:23 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult; +Cc: linux-kernel, linux-input
In-Reply-To: <1564410372-18506-1-git-send-email-info@metux.net>
On Mon, Jul 29, 2019 at 04:26:12PM +0200, Enrico Weigelt, metux IT consult wrote:
> From: Enrico Weigelt <info@metux.net>
>
> The registration of gpio-keys device can be written much shorter
> by using the platform_device_register_resndata() helper.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
> ---
> drivers/input/misc/soc_button_array.c | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
> index 5e59f8e5..f5e148b 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -110,25 +110,21 @@ static int soc_button_lookup_gpio(struct device *dev, int acpi_index)
> gpio_keys_pdata->nbuttons = n_buttons;
> gpio_keys_pdata->rep = autorepeat;
>
> - pd = platform_device_alloc("gpio-keys", PLATFORM_DEVID_AUTO);
> - if (!pd) {
> - error = -ENOMEM;
> + pd = platform_device_register_resndata(NULL,
I wonder if we should pass &pdev->dev instead of NULL here to form
proper device hierarchy, now that we have this option.
> + "gpio-keys",
> + PLATFORM_DEVID_AUTO,
> + NULL,
> + 0,
> + gpio_keys_pdata,
> + sizeof(*gpio_keys_pdata));
> +
> + if (IS_ERR(pd)) {
> + dev_err(&pdev->dev, "failed registering gpio-keys: %ld\n", PTR_ERR(pd));
> goto err_free_mem;
Since you did not assign 'error' value here this goto will result in the
function returning 0 even if platform_device_register_resndata() failed.
I'd doing:
pd = platform_device_register_resndata(NULL, ...);
error = PTR_ERR_OR_ZERO(pd);
if (error) {
dev_err(...);
goto err_free_mem;
}
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Dmitry Torokhov @ 2019-07-29 17:26 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult; +Cc: linux-kernel, linux-input
In-Reply-To: <1564415994-22871-1-git-send-email-info@metux.net>
Hi Enrico,
On Mon, Jul 29, 2019 at 05:59:53PM +0200, Enrico Weigelt, metux IT consult wrote:
> From: Enrico Weigelt <info@metux.net>
>
> Support the recently introduced gpio lookup tables for
> attaching to gpio lines. So, harcoded gpio numbers aren't
> needed anymore.
>
> changes v3:
> * fix printf string in gpio_keys_polled_get_gpiod()
> * fix unused variable 'error' in gpio_keys_polled_get_gpiod()
> * fix uninitialized variable in gpio_keys_polled_get_gpiod_fwnode()
As I think I mentioned a while back I would prefer to get gpiolob
support swnode-backed properties so that the driver would not need to
know about differences between ACPI, DT and static board files.
I just recently re-posted patches for this, let's see if we can get them
landed in the kernel.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Enrico Weigelt, metux IT consult @ 2019-07-29 18:14 UTC (permalink / raw)
To: Dmitry Torokhov, Enrico Weigelt, metux IT consult
Cc: linux-kernel, linux-input
In-Reply-To: <20190729172607.GB755@penguin>
On 29.07.19 19:26, Dmitry Torokhov wrote:
Hi,
> As I think I mentioned a while back I would prefer to get gpiolob > support swnode-backed properties so that the driver would not need
to> know about differences between ACPI, DT and static board files.
Indeed would be nice. But I think we should get rid of raw gpio IDs in
favour of gpiod lookup tables first.
> I just recently re-posted patches for this, let's see if we can get them > landed in the kernel.
Can you give me a pointer ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 1/2] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Dmitry Torokhov @ 2019-07-29 18:43 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Enrico Weigelt, metux IT consult, linux-kernel, linux-input
In-Reply-To: <b2912c1d-a6d8-ad2a-3e37-19e4d3d1bd3b@metux.net>
On Mon, Jul 29, 2019 at 08:14:52PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 29.07.19 19:26, Dmitry Torokhov wrote:
>
> Hi,
>
> > As I think I mentioned a while back I would prefer to get gpiolob >
> > support swnode-backed properties so that the driver would not need
> to> know about differences between ACPI, DT and static board files.
> Indeed would be nice. But I think we should get rid of raw gpio IDs in
> favour of gpiod lookup tables first.
>
> > I just recently re-posted patches for this, let's see if we can get them > landed in the kernel.
> Can you give me a pointer ?
https://patchwork.kernel.org/cover/11042915/
I tried putting you on CC list there, did you not get them?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 5/7] mfd: ioc3: Add driver for SGI IOC3 chip
From: Thomas Bogendoerfer @ 2019-07-29 18:45 UTC (permalink / raw)
To: Lee Jones
Cc: Ralf Baechle, Paul Burton, James Hogan, Dmitry Torokhov,
David S. Miller, Srinivas Kandagatla, Alessandro Zummo,
Alexandre Belloni, Greg Kroah-Hartman, Jiri Slaby, linux-mips,
linux-kernel, linux-input, netdev, linux-rtc, linux-serial
In-Reply-To: <20190725114716.GB23883@dell>
On Thu, 25 Jul 2019 12:47:16 +0100
Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 13 Jun 2019, Thomas Bogendoerfer wrote:
> > +/*
> > + * On IP30 the RTC (a DS1687) is behind the IOC3 on the generic
> > + * ByteBus regions. We have to write the RTC address of interest to
> > + * IOC3_BYTEBUS_DEV1, then read the data from IOC3_BYTEBUS_DEV2.
> > + * rtc->regs already points to IOC3_BYTEBUS_DEV1.
> > + */
> > +#define IP30_RTC_ADDR(rtc) (rtc->regs)
> > +#define IP30_RTC_DATA(rtc) ((rtc->regs) + IOC3_BYTEBUS_DEV2 - IOC3_BYTEBUS_DEV1)
> > +
> > +static u8 ip30_rtc_read(struct ds1685_priv *rtc, int reg)
> > +{
> > + writeb((reg & 0x7f), IP30_RTC_ADDR(rtc));
> > + return readb(IP30_RTC_DATA(rtc));
> > +}
> > +
> > +static void ip30_rtc_write(struct ds1685_priv *rtc, int reg, u8 value)
> > +{
> > + writeb((reg & 0x7f), IP30_RTC_ADDR(rtc));
> > + writeb(value, IP30_RTC_DATA(rtc));
> > +}
>
> Why is this not in the RTC driver?
because rtc1685 is used in different systems and accessing the chip
differs between those systems.
> > +static struct ds1685_rtc_platform_data ip30_rtc_platform_data = {
> > + .bcd_mode = false,
> > + .no_irq = false,
> > + .uie_unsupported = true,
> > + .alloc_io_resources = true,
>
> > + .plat_read = ip30_rtc_read,
> > + .plat_write = ip30_rtc_write,
>
> Call-backs in a non-subsystem API is pretty ugly IMHO.
I agree
> Where are these called from?
drivers/rtc/rtc-ds1685.c
I could do the same as done for serial8250 and add an additional .c file
in drivers/rtc which handles this for SGI-IP30. Alexandre would this work
for you as well ?
> > +#define IOC3_SID(_name, _sid, _setup) \
> > + { \
> > + .name = _name, \
> > + .sid = (PCI_VENDOR_ID_SGI << 16) | IOC3_SUBSYS_ ## _sid, \
> > + .setup = _setup, \
> > + }
> > +
> > +static struct {
> > + const char *name;
> > + u32 sid;
> > + int (*setup)(struct ioc3_priv_data *ipd);
> > +} ioc3_infos[] = {
>
> IMHO it's neater if you separate the definition and static data part.
I don't quite understand what you mean here. Should I move the #define at
the beginning of the file ? Why is it neater ?
Thomas.
--
SUSE Linux GmbH
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2] Input: applespi - register touchpad device synchronously in probe
From: Life is hard, and then you die @ 2019-07-30 6:56 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andy Shevchenko, Mao Wenan, Federico Lorenzi, linux-input,
linux-kernel
In-Reply-To: <20190729132203.GB1201@penguin>
Hi Dmitry,
On Mon, Jul 29, 2019 at 03:22:03PM +0200, Dmitry Torokhov wrote:
> Hi Ronald,
>
> On Sun, Jul 21, 2019 at 12:05:23AM -0700, Ronald Tschalär wrote:
> > This allows errors during registration to properly fail the probe
> > function.
> >
> > Doing this requires waiting for a response from the device inside the
> > probe function. While this generally takes about 15ms, in case of errors
> > it could be arbitrarily long, and hence a 3 second timeout is used.
> >
> > This also adds 3 second timeouts to the drain functions to avoid the
> > potential for suspend or remove hanging forever.
>
> Question: is it possible to read command response synchronously as well?
> I.e. I was wondering if we could add 2 (or 1?) more read xfers for the
> actual result that is coming after the status response, and then we
> could use spi_sync() to send the command and read the whole thing.
Yes'ish. But you still need to wait for the GPE to know when to read
the response, and while you're doing so any number of keyboard and
trackpad events may arrive (i.e. you may need to do any number of read
xfers). I suppose those events could all just be discarded, though. So
something like this:
assemble-info-cmd(write_msg)
spi_sync(write_msg)
while (1) {
wait_event_timeout(wait_queue, gpe_received, timeout)
spi_sync(read_msg)
if (is-info-cmd-response(read_msg))
break
}
and also modify the gpe-handler to wake the wait_queue instead of
issuing an spy_async() while doing the above.
I guess the advantage would certainly be the need to avoid the
spi-flushing in case of a timeout, at the expense of some slight
duplication of some of the received-message handling logic (would
refactor make most re-usable, of course).
So would this be the preferred approach then?
Cheers,
Ronald
^ permalink raw reply
* Re: [PATCH] Input: applespi - Fix build error
From: Yuehaibing @ 2019-07-30 7:22 UTC (permalink / raw)
To: Life is hard, and then you die, Dmitry Torokhov
Cc: nikolas, linux-kernel, linux-input
In-Reply-To: <20190730070117.GB20206@innovation.ch>
On 2019/7/30 15:01, Life is hard, and then you die wrote:
>
> On Mon, Jul 29, 2019 at 04:04:38PM +0200, Dmitry Torokhov wrote:
>> On Mon, Jul 29, 2019 at 11:14:55AM +0800, YueHaibing wrote:
>>> If CONFIG_KEYBOARD_APPLESPI=y but CONFIG_LEDS_CLASS=m
>>> building fails:
>>>
>>> drivers/input/keyboard/applespi.o: In function `applespi_probe':
>>> applespi.c:(.text+0x1fcd): undefined reference to `devm_led_classdev_register_ext'
>>>
>>> Wrap it in LEDS_CLASS macro to fix this.
>>
>> No, we should add "depends on LEDS_CLASS" to the Konfig instead.
>
> While the loss of keyboard-backlight functionality is certainly not
> critical, in practice when building a kernel for desktops/laptops
> (i.e. where this module would be used) I see no real reason why you'd
> not have/want LEDS_CLASS enabled. So I'd agree with Dmitry that a
> Kconfig depends-on is probably the preferred approach.
Thanks, will send v2 as suggestion.
>
>
> Cheers,
>
> Ronald
>
>
> .
>
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Michal Vokáč @ 2019-07-30 9:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <20190727073156.GA795@penguin>
On 27. 07. 19 9:31, Dmitry Torokhov wrote:
> On Fri, Jul 26, 2019 at 01:31:31PM +0200, Michal Vokáč wrote:
>> On 25. 07. 19 16:40, Dmitry Torokhov wrote:
>>> On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
>>>> On 25. 07. 19 10:57, Dmitry Torokhov wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
>>>>>> On 21. 05. 19 7:37, Dmitry Torokhov wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have to deal with a situation where we have a custom i.MX6 based
>>>>>>>> platform in production that uses the MPR121 touchkey controller.
>>>>>>>> Unfortunately the chip is connected using only the I2C interface.
>>>>>>>> The interrupt line is not used. Back in 2015 (Linux v3.14), my
>>>>>>>> colleague modded the existing mpr121_touchkey.c driver to use polling
>>>>>>>> instead of interrupt.
>>>>>>>>
>>>>>>>> For quite some time yet I am in a process of updating the product from
>>>>>>>> the ancient Freescale v3.14 kernel to the latest mainline and pushing
>>>>>>>> any needed changes upstream. The DT files for our imx6dl-yapp4 platform
>>>>>>>> already made it into v5.1-rc.
>>>>>>>>
>>>>>>>> I rebased and updated our mpr121 patch to the latest mainline.
>>>>>>>> It is created as a separate driver, similarly to gpio_keys_polled.
>>>>>>>>
>>>>>>>> The I2C device is quite susceptible to ESD. An ESD test quite often
>>>>>>>> causes reset of the chip or some register randomly changes its value.
>>>>>>>> The [PATCH 3/4] adds a write-through register cache. With the cache
>>>>>>>> this state can be detected and the device can be re-initialied.
>>>>>>>>
>>>>>>>> The main question is: Is there any chance that such a polled driver
>>>>>>>> could be accepted? Is it correct to implement it as a separate driver
>>>>>>>> or should it be done as an option in the existing driver? I can not
>>>>>>>> really imagine how I would do that though..
>>>>>>>>
>>>>>>>> There are also certain worries that the MPR121 chip may no longer be
>>>>>>>> available in nonspecifically distant future. In case of EOL I will need
>>>>>>>> to add a polled driver for an other touchkey chip. May it be already
>>>>>>>> in mainline or a completely new one.
>>>>>>>
>>>>>>> I think that my addition of input_polled_dev was ultimately a wrong
>>>>>>> thing to do. I am looking into enabling polling mode for regular input
>>>>>>> devices as we then can enable polling mode in existing drivers.
>>>>>>
>>>>>> OK, that sounds good. Especially when one needs to switch from one chip
>>>>>> to another that is already in tree, the need for a whole new polling
>>>>>> driver is eliminated.
>>>>>
>>>>> Could you please try the patch below and see if it works for your use
>>>>> case? Note that I have not tried running it, but it compiles so it must
>>>>> be good ;)
>>>>
>>>> Hi Dmitry,
>>>> Thank you very much for the patch!
>>>> I gave it a shot and it seems you forgot to add the input-poller.h file
>>>> to the patch.. it does not compile on my side :(
>>>
>>> Oops ;) Please see the updated patch below.
>>
>> Thank you, now it is (almost) good as you said :D
>>
>>>>
>>>>> Input: add support for polling to input devices
>>>>>
>>>>> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>>>
>>>>> Separating "normal" and "polled" input devices was a mistake, as often we want
>>>>> to allow the very same device work on both interrupt-driven and polled mode,
>>>>> depending on the board on which the device is used.
>>>>>
>>>>> This introduces new APIs:
>>>>>
>>>>> - input_setup_polling
>>>>> - input_set_poll_interval
>>>>> - input_set_min_poll_interval
>>>>> - input_set_max_poll_interval
>>>>>
>>>>> These new APIs allow switching an input device into polled mode with sysfs
>>>>> attributes matching drivers using input_polled_dev APIs that will be eventually
>>>>> removed.
>>>>
>>>> After reading this I am not really sure what else needs to be done
>>>> to test/use the poller. I suspect I need to modify the input device
>>>> driver (mpr121_touchkey.c in my case) like this:
>>>>
>>>> If the interrupt gpio is not provided in DT, the device driver probe
>>>> function should:
>>>> - not request the threaded interrupt
>>>> - call input_setup_polling and provide it with poll_fn
>>>> Can the mpr_touchkey_interrupt function be used as is for this
>>>> purpose? The only problem I see is it returns IRQ_HANDLED.
>>>
>>> I'd factor out code suitable for polling from mpr_touchkey_interrupt()
>>> and then do
>>>
>>> static irqreturn_t mpr_touchkey_interrupt(...)
>>> {
>>> mpr_touchkey_report(...);
>>> return IRQ_HANDLED;
>>> }
>>>
>>
>> Probably a trivial problem for experienced kernel hacker but I can not
>> wrap my head around this - the interrupt handler takes the mpr121
>> device id as an argument while the poller poll_fn takes struct input_dev.
>>
>> I fail to figure out how to get the device id from the input device.
>>
Thanks for the hints Dmitry. I am trying my best but still have some
issues with the input_set/get_drvdata.
The kernel Oopses on NULL pointer dereference in mpr_touchkey_report.
Here is the backtrace:
[ 2.916960] 8<--- cut here ---
[ 2.920022] Unable to handle kernel NULL pointer dereference at virtual address 000001d0
[ 2.928138] pgd = (ptrval)
[ 2.930851] [000001d0] *pgd=00000000
[ 2.934439] Internal error: Oops: 5 [#1] SMP ARM
[ 2.939065] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc1-00001-g7278b7c3986c-dirty #2
[ 2.947503] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 2.954044] PC is at mpr_touchkey_report+0x18/0x1bc
[ 2.958932] LR is at input_dev_poller_start+0x30/0x3c
[ 2.963987] pc : [<80728c50>] lr : [<8071f444>] psr: 20000013
[ 2.970255] sp : e8131c10 ip : e8131c68 fp : e8131c64
[ 2.975480] r10: 000000c9 r9 : 8108339c r8 : 81083340
[ 2.980707] r7 : 00000000 r6 : e86cf574 r5 : e86b8480 r4 : e86b8040
[ 2.987236] r3 : 80728c38 r2 : e8128000 r1 : 00000000 r0 : 00000000
[ 2.993767] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 3.000906] Control: 10c5387d Table: 1000404a DAC: 00000051
[ 3.006656] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
[ 3.012667] Stack: (0xe8131c10 to 0xe8132000)
[ 3.017033] 1c00: 60000013 8017f290 e8131c64 e8131c28
[ 3.025219] 1c20: 8017f290 8017f098 80e7eb04 e8131cd4 0000013d 00000000 80bc6ba4 e86b8040
[ 3.033403] 1c40: e86b8480 e86cf574 00000000 81083340 8108339c 000000c9 e8131c7c e8131c68
[ 3.041587] 1c60: 8071f444 80728c44 e86cf400 e86b8480 e8131c9c e8131c80 8071d230 8071f420
[ 3.049769] 1c80: e86b8480 00000000 e86cf400 8106baa4 e8131cbc e8131ca0 80591b00 8071d1a0
[ 3.057951] 1ca0: 80c567c4 e86cf400 8106baa4 8106baa4 e8131cdc e8131cc0 8071d75c 80591a98
[ 3.066136] 1cc0: e86cf400 00000000 e86ba1c0 8106baa4 e8131d04 e8131ce0 8071df50 8071d6cc
[ 3.074320] 1ce0: 00000000 e834a400 e86cf400 e86ba0c0 e834a420 51eb851f e8131d54 e8131d08
[ 3.082502] 1d00: 807291c4 8071dbc0 00000000 00000000 00000000 0d3abafe 00325aa0 81006548
[ 3.090686] 1d20: 000003e8 0d3abafe 8063907c e834a420 80728e34 81083950 e834a400 00000000
[ 3.098867] 1d40: 00000000 00000000 e8131d7c e8131d58 80747410 80728e40 81123a00 e834a420
[ 3.107051] 1d60: 81123b0c 00000000 81083950 00000000 e8131dac e8131d80 8061f684 807471c4
[ 3.115233] 1d80: 00000000 e834a420 81083950 81083950 81006548 00000000 80f8c83c 80f008ac
[ 3.123415] 1da0: e8131de4 e8131db0 8061fca8 8061f590 e8131dcc e8131dc0 8080e234 8061ed70
[ 3.131599] 1dc0: e834a420 00000000 81083950 81006548 00000000 80f8c83c e8131e04 e8131de8
[ 3.139784] 1de0: 8061ffcc 8061fc44 81083950 e834a420 8061ffd4 81006548 e8131e24 e8131e08
[ 3.147969] 1e00: 80620040 8061ff70 00000000 81083950 8061ffd4 81006548 e8131e54 e8131e28
[ 3.156151] 1e20: 8061d974 8061ffe0 e8131e60 e821b758 e83413b4 0d3abafe 81083950 e8697f00
[ 3.164333] 1e40: 81084b4c 00000000 e8131e64 e8131e58 806200e0 8061d8fc e8131e8c e8131e68
[ 3.172517] 1e60: 8061e314 806200c0 80e7f9a0 e8131e78 81083950 81006548 80f4a898 ffffe000
[ 3.180699] 1e80: e8131ea4 e8131e90 80620ce4 8061e1b8 81083934 81006548 e8131ebc e8131ea8
[ 3.188882] 1ea0: 80748e18 80620c64 810c0660 81006548 e8131ecc e8131ec0 80f4a8bc 80748dd8
[ 3.197065] 1ec0: e8131f44 e8131ed0 80f01330 80f4a8a4 00000000 80e12924 80e12904 80e12900
[ 3.205250] 1ee0: 80e24610 81006548 00000000 80e128dc 00000006 00000006 00000000 80f008ac
[ 3.213433] 1f00: 80e7eac0 80ee9234 8016f4d4 ebfffb37 ebfffb3f 0d3abafe e8131f44 0d3abafe
[ 3.220284] g_ether gadget: high-speed config #1: CDC Ethernet (ECM)
[ 3.221616] 1f20: 810c0660 00000007 810c0660 80fc21f0 810c5980 810c5980 e8131f94 e8131f48
[ 3.236147] 1f40: 80f0174c 80f01274 00000006 00000006 00000000 80f008ac 801346cc 80133d54
[ 3.244330] 1f60: 80ee9234 00000154 e8131f8c 00000000 80bdb670 00000000 00000000 00000000
[ 3.252512] 1f80: 00000000 00000000 e8131fac e8131f98 80bdb688 80f0146c 00000000 80bdb670
[ 3.260695] 1fa0: 00000000 e8131fb0 801010e8 80bdb67c 00000000 00000000 00000000 00000000
[ 3.268878] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.277061] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 3.285237] Backtrace:
[ 3.287699] [<80728c38>] (mpr_touchkey_report) from [<8071f444>] (input_dev_poller_start+0x30/0x3c)
[ 3.296753] r10:000000c9 r9:8108339c r8:81083340 r7:00000000 r6:e86cf574 r5:e86b8480
[ 3.304584] r4:e86b8040
[ 3.307128] [<8071f414>] (input_dev_poller_start) from [<8071d230>] (input_open_device+0x9c/0xc4)
[ 3.316002] r5:e86b8480 r4:e86cf400
[ 3.319590] [<8071d194>] (input_open_device) from [<80591b00>] (kbd_connect+0x74/0x90)
[ 3.327510] r7:8106baa4 r6:e86cf400 r5:00000000 r4:e86b8480
[ 3.333180] [<80591a8c>] (kbd_connect) from [<8071d75c>] (input_attach_handler+0x9c/0xd0)
[ 3.341361] r7:8106baa4 r6:8106baa4 r5:e86cf400 r4:80c567c4
[ 3.347029] [<8071d6c0>] (input_attach_handler) from [<8071df50>] (input_register_device+0x39c/0x40c)
[ 3.356251] r7:8106baa4 r6:e86ba1c0 r5:00000000 r4:e86cf400
[ 3.361923] [<8071dbb4>] (input_register_device) from [<807291c4>] (mpr_touchkey_probe+0x390/0x4d4)
[ 3.370974] r9:51eb851f r8:e834a420 r7:e86ba0c0 r6:e86cf400 r5:e834a400 r4:00000000
[ 3.378727] [<80728e34>] (mpr_touchkey_probe) from [<80747410>] (i2c_device_probe+0x258/0x27c)
[ 3.387344] r10:00000000 r9:00000000 r8:00000000 r7:e834a400 r6:81083950 r5:80728e34
[ 3.395174] r4:e834a420
[ 3.397715] [<807471b8>] (i2c_device_probe) from [<8061f684>] (really_probe+0x100/0x2d8)
[ 3.405810] r9:00000000 r8:81083950 r7:00000000 r6:81123b0c r5:e834a420 r4:81123a00
[ 3.413562] [<8061f584>] (really_probe) from [<8061fca8>] (driver_probe_device+0x70/0x180)
[ 3.421832] r10:80f008ac r9:80f8c83c r8:00000000 r7:81006548 r6:81083950 r5:81083950
[ 3.429662] r4:e834a420 r3:00000000
[ 3.433245] [<8061fc38>] (driver_probe_device) from [<8061ffcc>] (device_driver_attach+0x68/0x70)
[ 3.442121] r9:80f8c83c r8:00000000 r7:81006548 r6:81083950 r5:00000000 r4:e834a420
[ 3.449872] [<8061ff64>] (device_driver_attach) from [<80620040>] (__driver_attach+0x6c/0xe0)
[ 3.458399] r7:81006548 r6:8061ffd4 r5:e834a420 r4:81083950
[ 3.464071] [<8061ffd4>] (__driver_attach) from [<8061d974>] (bus_for_each_dev+0x84/0xc4)
[ 3.472251] r7:81006548 r6:8061ffd4 r5:81083950 r4:00000000
[ 3.477920] [<8061d8f0>] (bus_for_each_dev) from [<806200e0>] (driver_attach+0x2c/0x30)
[ 3.485926] r7:00000000 r6:81084b4c r5:e8697f00 r4:81083950
[ 3.491594] [<806200b4>] (driver_attach) from [<8061e314>] (bus_add_driver+0x168/0x1ec)
[ 3.499604] [<8061e1ac>] (bus_add_driver) from [<80620ce4>] (driver_register+0x8c/0x124)
[ 3.507697] r7:ffffe000 r6:80f4a898 r5:81006548 r4:81083950
[ 3.513366] [<80620c58>] (driver_register) from [<80748e18>] (i2c_register_driver+0x4c/0x8c)
[ 3.521804] r5:81006548 r4:81083934
[ 3.525394] [<80748dcc>] (i2c_register_driver) from [<80f4a8bc>] (mpr_touchkey_driver_init+0x24/0x28)
[ 3.534616] r5:81006548 r4:810c0660
[ 3.538203] [<80f4a898>] (mpr_touchkey_driver_init) from [<80f01330>] (do_one_initcall+0xc8/0x1f8)
[ 3.547169] [<80f01268>] (do_one_initcall) from [<80f0174c>] (kernel_init_freeable+0x2ec/0x380)
[ 3.555872] r8:810c5980 r7:810c5980 r6:80fc21f0 r5:810c0660 r4:00000007
[ 3.562587] [<80f01460>] (kernel_init_freeable) from [<80bdb688>] (kernel_init+0x18/0x120)
[ 3.570856] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:80bdb670
[ 3.578685] r4:00000000
[ 3.581230] [<80bdb670>] (kernel_init) from [<801010e8>] (ret_from_fork+0x14/0x2c)
[ 3.588802] Exception stack(0xe8131fb0 to 0xe8131ff8)
[ 3.593859] 1fa0: 00000000 00000000 00000000 00000000
[ 3.602042] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.610222] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 3.616839] r5:80bdb670 r4:00000000
[ 3.620422] Code: e24cb004 e24dd02c e52de004 e8bd4000 (e59051d0)
[ 3.626572] ---[ end trace eb840c8cb957e159 ]---
I can confirm the poller mechanism works fine if I leave the
mpr_touchkey_report function empty and just return.
I can also confirm the interrupt mechanism works as fine if I bodge
a wire from some available GPIO (commented lines in dtsi).
Here is my code:
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index e8d800fec637..7516da441915 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
+++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/input/input.h>
#include <dt-bindings/pwm/pwm.h>
/ {
@@ -330,6 +331,21 @@
vcc-supply = <&sw2_reg>;
status = "disabled";
};
+
+ touchkeys: keys@5a {
+ compatible = "fsl,mpr121-touchkey";
+ //pinctrl-0 = <&pinctrl_key_irq>;
+ reg = <0x5a>;
+ vdd-supply = <&sw2_reg>;
+ autorepeat;
+ linux,keycodes = <KEY_1>, <KEY_2>, <KEY_3>, <KEY_4>, <KEY_5>,
+ <KEY_6>, <KEY_7>, <KEY_8>, <KEY_9>,
+ <KEY_BACKSPACE>, <KEY_0>, <KEY_ENTER>;
+ linux,poll-interval = <50>;
+ //interrupt-parent = <&gpio1>;
+ //interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
+ status = "disabled";
+ };
};
&iomuxc {
@@ -433,6 +449,12 @@
>;
};
+ pinctrl_key_irq: keyirq {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__GPIO1_IO18 0x1b098
+ >;
+ };
+
pinctrl_touch: touchgrp {
fsl,pins = <
MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b098
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-hydra.dts b/arch/arm/boot/dts/imx6dl-yapp4-hydra.dts
index f97927064750..84c275bfdd38 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4-hydra.dts
+++ b/arch/arm/boot/dts/imx6dl-yapp4-hydra.dts
@@ -45,6 +45,10 @@
status = "okay";
};
+&touchkeys {
+ status = "okay";
+};
+
&usdhc3 {
status = "okay";
};
diff --git a/drivers/input/keyboard/mpr121_touchkey.c b/drivers/input/keyboard/mpr121_touchkey.c
index e9ceaa16b46a..d6b9f6acddca 100644
--- a/drivers/input/keyboard/mpr121_touchkey.c
+++ b/drivers/input/keyboard/mpr121_touchkey.c
@@ -7,7 +7,7 @@
*
* Based on mcs_touchkey.c
*/
-
+#define DEBUG
#include <linux/bitops.h>
#include <linux/delay.h>
#include <linux/i2c.h>
@@ -54,6 +54,9 @@
/* MPR121 has 12 keys */
#define MPR121_MAX_KEY_COUNT 12
+#define MPR121_MIN_POLL_INTERVAL 10
+#define MPR121_MAX_POLL_INTERVAL 2000
+
struct mpr121_touchkey {
struct i2c_client *client;
struct input_dev *input_dev;
@@ -115,11 +118,11 @@ static struct regulator *mpr121_vdd_supply_init(struct device *dev)
return vdd_supply;
}
-static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
+static void mpr_touchkey_report(struct input_dev *dev)
{
- struct mpr121_touchkey *mpr121 = dev_id;
- struct i2c_client *client = mpr121->client;
+ struct mpr121_touchkey *mpr121 = input_get_drvdata(dev);
struct input_dev *input = mpr121->input_dev;
+ struct i2c_client *client = mpr121->client;
unsigned long bit_changed;
unsigned int key_num;
int reg;
@@ -127,14 +130,14 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
reg = i2c_smbus_read_byte_data(client, ELE_TOUCH_STATUS_1_ADDR);
if (reg < 0) {
dev_err(&client->dev, "i2c read error [%d]\n", reg);
- goto out;
+ return;
}
reg <<= 8;
reg |= i2c_smbus_read_byte_data(client, ELE_TOUCH_STATUS_0_ADDR);
if (reg < 0) {
dev_err(&client->dev, "i2c read error [%d]\n", reg);
- goto out;
+ return;
}
reg &= TOUCH_STATUS_MASK;
@@ -155,8 +158,13 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
}
input_sync(input);
+}
+
+static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
+{
+ struct mpr121_touchkey *mpr121 = dev_id;
+ mpr_touchkey_report(mpr121->input_dev);
-out:
return IRQ_HANDLED;
}
@@ -229,13 +237,10 @@ static int mpr_touchkey_probe(struct i2c_client *client,
int vdd_uv;
struct mpr121_touchkey *mpr121;
struct input_dev *input_dev;
+ u32 poll_interval = 0;
int error;
int i;
- if (!client->irq) {
- dev_err(dev, "irq number should not be zero\n");
- return -EINVAL;
- }
vdd_supply = mpr121_vdd_supply_init(dev);
if (IS_ERR(vdd_supply))
@@ -275,11 +280,13 @@ static int mpr_touchkey_probe(struct i2c_client *client,
if (device_property_read_bool(dev, "autorepeat"))
__set_bit(EV_REP, input_dev->evbit);
input_set_capability(input_dev, EV_MSC, MSC_SCAN);
+ input_set_drvdata(input_dev, mpr121);
input_dev->keycode = mpr121->keycodes;
input_dev->keycodesize = sizeof(mpr121->keycodes[0]);
input_dev->keycodemax = mpr121->keycount;
+
for (i = 0; i < mpr121->keycount; i++)
input_set_capability(input_dev, EV_KEY, mpr121->keycodes[i]);
@@ -289,13 +296,34 @@ static int mpr_touchkey_probe(struct i2c_client *client,
return error;
}
- error = devm_request_threaded_irq(dev, client->irq, NULL,
- mpr_touchkey_interrupt,
- IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
- dev->driver->name, mpr121);
- if (error) {
- dev_err(dev, "Failed to register interrupt\n");
- return error;
+ device_property_read_u32(dev, "linux,poll-interval", &poll_interval);
+
+ if (client->irq) {
+ error = devm_request_threaded_irq(dev, client->irq, NULL,
+ mpr_touchkey_interrupt,
+ IRQF_TRIGGER_FALLING |
+ IRQF_ONESHOT,
+ dev->driver->name, mpr121);
+ if (error) {
+ dev_err(dev, "Failed to register interrupt\n");
+ return error;
+ }
+ } else if (poll_interval > 0) {
+ error = input_setup_polling(input_dev, mpr_touchkey_report);
+ if (error) {
+ dev_err(dev, "Failed to setup polling\n");
+ return error;
+ }
+
+ input_set_poll_interval(input_dev, poll_interval);
+ input_set_min_poll_interval(input_dev,
+ MPR121_MIN_POLL_INTERVAL);
+ input_set_max_poll_interval(input_dev,
+ MPR121_MAX_POLL_INTERVAL);
+ } else {
+ dev_err(dev,
+ "invalid IRQ number and polling not configured\n");
+ return -EINVAL;
}
error = input_register_device(input_dev);
--
^ permalink raw reply related
* Re: WARNING in usbtouch_open
From: Oliver Neukum @ 2019-07-30 10:12 UTC (permalink / raw)
To: syzbot, rydberg, mpe, dmitry.torokhov, andreyknvl, syzkaller-bugs,
tglx, gregkh, kstewart, allison, linux-input, linux-kernel,
linux-usb
In-Reply-To: <000000000000394df0058ed48487@google.com>
Am Montag, den 29.07.2019, 09:38 -0700 schrieb syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7f7867ff usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=1503f4ec600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
> dashboard link: https://syzkaller.appspot.com/bug?extid=199ea16c7f26418b4365
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=173e4442600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=115482b2600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+199ea16c7f26418b4365@syzkaller.appspotmail.com
#syz test: https://github.com/google/kasan.git usb-fuzzer
>From 29b755588bd353d0e10ae384c2c551dffa1b3e7b Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Tue, 30 Jul 2019 12:00:27 +0200
Subject: [PATCH] usbtouchscreen: add proper initialization
Mutexes shall be initialized before they are used.
Fixes: 12e510dbc57b2 ("Input: usbtouchscreen - fix deadlock in autosuspend")
Reported-by: syzbot+199ea16c7f26418b4365@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/input/touchscreen/usbtouchscreen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index a2cec6cacf57..caacf211f51b 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -1658,6 +1658,7 @@ static int usbtouch_probe(struct usb_interface *intf,
input_dev = input_allocate_device();
if (!usbtouch || !input_dev)
goto out_free;
+ mutex_init(&usbtouch->pm_mutex);
type = &usbtouch_dev_info[id->driver_info];
usbtouch->type = type;
--
2.16.4
^ permalink raw reply related
* Re: WARNING in usbtouch_open
From: syzbot @ 2019-07-30 10:31 UTC (permalink / raw)
To: allison, andreyknvl, dmitry.torokhov, gregkh, kstewart,
linux-input, linux-kernel, linux-usb, mpe, oneukum, rydberg,
syzkaller-bugs, tglx
In-Reply-To: <1564481531.25582.22.camel@suse.com>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+199ea16c7f26418b4365@syzkaller.appspotmail.com
Tested on:
commit: 7f7867ff usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=1347ab44600000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* Re: [PATCH] hid-logitech-dj: add other Lightspeed receiver
From: Filipe Laíns @ 2019-07-30 11:08 UTC (permalink / raw)
To: Filipe Laíns
Cc: nlopezcasad, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20190718140358.9058-1-lains@archlinux.org>
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
On Thu, 2019-07-18 at 15:03 +0100, Filipe Laíns wrote:
> This receiver seems to only be used in the G305.
>
> Signed-off-by: Filipe Laíns <lains@archlinux.org>
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-logitech-dj.c | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 884356feb016..e5d0fd85e61d 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -770,6 +770,7 @@
> #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_2 0xc534
> #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED 0xc539
> #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a
> +#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_2 0xc53f
> #define USB_DEVICE_ID_SPACETRAVELLER 0xc623
> #define USB_DEVICE_ID_SPACENAVIGATOR 0xc626
> #define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-
> logitech-dj.c
> index d5b47ec1510c..0139912c3f69 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -1836,6 +1836,10 @@ static const struct hid_device_id
> logi_dj_receivers[] = {
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED),
> .driver_data = recvr_type_gaming_hidpp},
> + { /* Logitech lightspeed receiver (0xc53f) */
> + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> + USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_2),
> + .driver_data = recvr_type_gaming_hidpp},
> { /* Logitech 27 MHz HID++ 1.0 receiver (0xc513) */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_MX3000_RECEIVER),
> .driver_data = recvr_type_27mhz},
Please don't merge this as it introduces a regression. I will send a new revision.
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] gpiolib: add support for fetching descriptors from static properties
From: Heikki Krogerus @ 2019-07-30 11:30 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Rafael J . Wysocki,
Enrico Weigelt, metux IT consult, linux-input, linux-gpio,
linux-kernel, Andy Shevchenko
In-Reply-To: <20190713075259.243565-3-dmitry.torokhov@gmail.com>
Hi Dmitry,
On Sat, Jul 13, 2019 at 12:52:59AM -0700, Dmitry Torokhov wrote:
> Now that static device properties understand notion of child nodes, let's
> teach gpiolib to tie such children and machine GPIO descriptor tables.
> We will continue using a single table for entire device, but instead of
> using connection ID as a lookup key in the GPIO descriptor table directly,
> we will perform additional translation: fwnode_get_named_gpiod() when
> dealing with property_set-backed fwnodes will try parsing string property
> with name matching connection ID and use result of the lookup as the key in
> the table:
>
> static const struct property_entry dev_child1_props[] __initconst = {
> ...
> PROPERTY_ENTRY_STRING("gpios", "child-1-gpios"),
> { }
> };
>
> static struct gpiod_lookup_table dev_gpiod_table = {
> .dev_id = "some-device",
> .table = {
> ...
> GPIO_LOOKUP_IDX("B", 1, "child-1-gpios", 1, GPIO_ACTIVE_LOW),
> ...
> },
> };
We don't need struct gpiod_lookup_table anymore. We can mimic DT with
the software nodes now that we have those "reference properties". A
gpio reference with the software nodes would look something like this:
enum {
GPIO_CONTROLLER,
MY_DEVICE
};
static const struct software_node nodes[];
static const struct software_node_ref_args reset_gpio_ref = {
.node = &nodes[GPIO_CONTROLLER],
.nargs = 2,
.args = {
14, /* line number */
GPIO_ACTIVE_HIGH /* flags */
}
};
static const struct software_node_reference my_refs[] = {
{ "reset-gpios", 1, &reset_gpio_ref }
};
/* Optionally, we could support gpiochip finding by name... */
static const struct property_entry my_props[] = {
PROPERTY_ENTRY_STRING("gpio-controller", "name_of_the_controller")
};
static const struct software_node nodes[] = {
[GPIO_CONTROLLER] = { "gpio_controller" },
[MY_DEVICE] = { "my_device", NULL, my_props, my_refs }
};
void my_init(void)
{
...
ret = software_node_register_nodes(nodes);
...
}
In gpiolib we should now be able to access that reference with
fwnode_property_get_references_args():
static int gpiochip_match_fwnode(struct gpio_chip *chip, void *fwnode)
{
/* The fwnode member needs to be added to struct gpio_chip */
return chip->fwnode == fwnode;
}
static struct gpio_desc *gpiod_find(struct device *dev,
const char *con_id,
unsigned int idx,
unsigned long flags)
{
struct fwnode_reference_args args;
struct gpio_chip *chip;
struct gpio_desc *desc;
const char *name;
int ret;
ret = fwnode_property_get_refernce_args(dev_fwnode(dev), con_id,
NULL, idx, &args);
...
/* Let's find the gpiochip */
chip = gpiochip_find(args.fwnode, gpiochip_match_fwnode);
...
/* Or optionally with find_chip_by_name() */
//ret = device_property_read_string(dev, "gpio-controller", &name);
...
//chip = find_chip_by_name(name);
...
/* I'm assuming hwnum is the same as line number? */
desc = gpiochip_get_desc(chip, args.args[0]);
*flags = args.args[1];
return desc;
}
The above is just an example, but I'm pretty sure that something like
it (with a little bit of tuning) is all that we need.
thanks,
--
heikki
^ permalink raw reply
* Re: [PATCH 1/2] drivers: base: swnode: link devices to software nodes
From: Heikki Krogerus @ 2019-07-30 11:52 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Rafael J . Wysocki,
Enrico Weigelt, metux IT consult, linux-input, linux-gpio,
linux-kernel, Andy Shevchenko
In-Reply-To: <20190729131532.GA1201@penguin>
On Mon, Jul 29, 2019 at 03:15:32PM +0200, Dmitry Torokhov wrote:
> On Mon, Jul 29, 2019 at 03:07:15PM +0300, Heikki Krogerus wrote:
> > On Sat, Jul 13, 2019 at 12:52:58AM -0700, Dmitry Torokhov wrote:
> > > It is helpful to know what device, if any, a software node is tied to, so
> > > let's store a pointer to the device in software node structure. Note that
> > > children software nodes will inherit their parent's device pointer, so we
> > > do not have to traverse hierarchy to see what device the [sub]tree belongs
> > > to.
> > >
> > > We will be using the device pointer to locate GPIO lookup tables for
> > > devices with static properties.
> > >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > ---
> > > drivers/base/property.c | 1 +
> > > drivers/base/swnode.c | 35 ++++++++++++++++++++++++++++++++++-
> > > include/linux/property.h | 5 +++++
> > > 3 files changed, 40 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > index 348b37e64944..3bc93d4b35c4 100644
> > > --- a/drivers/base/property.c
> > > +++ b/drivers/base/property.c
> > > @@ -527,6 +527,7 @@ int device_add_properties(struct device *dev,
> > > if (IS_ERR(fwnode))
> > > return PTR_ERR(fwnode);
> > >
> > > + software_node_link_device(fwnode, dev);
> > > set_secondary_fwnode(dev, fwnode);
> > > return 0;
> > > }
> > > diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> > > index 7fc5a18e02ad..fd12eea539b6 100644
> > > --- a/drivers/base/swnode.c
> > > +++ b/drivers/base/swnode.c
> > > @@ -24,6 +24,9 @@ struct software_node {
> > >
> > > /* properties */
> > > const struct property_entry *properties;
> > > +
> > > + /* device this node is associated with */
> > > + struct device *dev;
> > > };
> >
> > Let's not do that! The nodes can be, and in many cases are, associated
> > with multiple devices.
>
> They do? Where? I see that set of properties can be shared between
> several devices, but when we instantiate SW node we create a new
> instance for device. This is also how ACPI and OF properties work; they
> not shared between devices (or, rather, the kernel creates distinct _and
> single_ devices for instance of ACPI or OF node). I do not think we want
> swnodes work differently from the other firmware nodes.
Having multiple devices linked to a single node is quite normal. Most
multifunctional devices will share a single node. The USB port devices
will share their node (if they have one) with any device that is
attached to them. Etc.
If you want to check how this works with ACPI, then find
"physical_node" named files from sysfs. The ACPI node folders in sysfs
have symlinks named "physical_node<n>" for every device they are bind
to. The first one is named just "physical_node", the second
"physical_node1", the third "physical_node2", and so on.
> > Every device is already linked with the software node kobject, so
> > isn't it possible to simply walk trough those links in order to check
> > the devices associated with the node?
>
> No, we need to know the exact instance of a device, not a set of
> devices, because even though some properties can be shared, others can
> not. For example, even if 2 exactly same touch controllers in the system
> have "reset-gpios" property, they won't be the same GPIO for the both of
> them.
I don't think I completely understand the use case you had in mind for
this API, but since you planned to use it with the GPIO lookup tables,
I'm going to assume it's not needed after all. Let's replace those
with the references instead like I proposed in my reply to the 2/2
patch.
Linking a single device with a node like that is in any case not
acceptable nor possible.
thanks,
--
heikki
^ permalink raw reply
* [PATCH v2] hid-logitech-dj: add the new Lightspeed receiver
From: Filipe Laíns @ 2019-07-30 12:24 UTC (permalink / raw)
Cc: nlopezcasad, Filipe Laíns, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
This patchs adds the new Lightspeed receiver. Currently it seems to only
be used in the G305.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
---
drivers/hid/hid-ids.h | 3 ++-
drivers/hid/hid-logitech-dj.c | 13 +++++++++++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index fb19eefbc0b3..61b954fcfc2e 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -768,7 +768,8 @@
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER 0xc52f
#define USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2 0xc532
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_2 0xc534
-#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED 0xc539
+#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1 0xc539
+#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1 0xc53f
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a
#define USB_DEVICE_ID_SPACETRAVELLER 0xc623
#define USB_DEVICE_ID_SPACENAVIGATOR 0xc626
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 4a68960b131f..d718f01f56d3 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -968,7 +968,12 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
break;
case 0x0c:
- device_type = "eQUAD Lightspeed";
+ device_type = "eQUAD Lightspeed 1";
+ logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
+ workitem.reports_supported |= STD_KEYBOARD;
+ break;
+ case 0x0d:
+ device_type = "eQUAD Lightspeed 1_1";
logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
workitem.reports_supported |= STD_KEYBOARD;
break;
@@ -1832,7 +1837,11 @@ static const struct hid_device_id logi_dj_receivers[] = {
.driver_data = recvr_type_hidpp},
{ /* Logitech lightspeed receiver (0xc539) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
- USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED),
+ USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1),
+ .driver_data = recvr_type_gaming_hidpp},
+ { /* Logitech lightspeed receiver (0xc53f) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1),
.driver_data = recvr_type_gaming_hidpp},
{ /* Logitech 27 MHz HID++ 1.0 receiver (0xc513) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER),
--
2.22.0
^ permalink raw reply related
* KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: syzbot @ 2019-07-30 12:28 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 7f7867ff usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=15e293c8600000
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=5a6c4ec678a0c6ee84ba
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
Read of size 1 at addr ffff8881ca981f10 by task syz-executor.4/7644
CPU: 1 PID: 7644 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #23
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
strlen+0x79/0x90 lib/string.c:525
strlen include/linux/string.h:281 [inline]
hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fed5bb22c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000020000180 RSI: 0000000080404805 RDI: 0000000000000003
RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fed5bb236d4
R13: 00000000004c21c6 R14: 00000000004d5528 R15: 00000000ffffffff
Allocated by task 1607:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
kmalloc include/linux/slab.h:552 [inline]
syslog_print kernel/printk/printk.c:1346 [inline]
do_syslog kernel/printk/printk.c:1519 [inline]
do_syslog+0x540/0x1380 kernel/printk/printk.c:1493
kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
proc_reg_read+0x1c1/0x280 fs/proc/inode.c:223
__vfs_read+0x76/0x100 fs/read_write.c:425
vfs_read+0x1ea/0x430 fs/read_write.c:461
ksys_read+0x127/0x250 fs/read_write.c:587
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 1607:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1470 [inline]
slab_free mm/slub.c:3012 [inline]
kfree+0xe4/0x2f0 mm/slub.c:3953
syslog_print kernel/printk/printk.c:1405 [inline]
do_syslog kernel/printk/printk.c:1519 [inline]
do_syslog+0x1098/0x1380 kernel/printk/printk.c:1493
kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
proc_reg_read+0x1c1/0x280 fs/proc/inode.c:223
__vfs_read+0x76/0x100 fs/read_write.c:425
vfs_read+0x1ea/0x430 fs/read_write.c:461
ksys_read+0x127/0x250 fs/read_write.c:587
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881ca981b00
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 16 bytes to the right of
1024-byte region [ffff8881ca981b00, ffff8881ca981f00)
The buggy address belongs to the page:
page:ffffea00072a6000 refcount:1 mapcount:0 mapping:ffff8881da002280
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da002280
raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881ca981e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881ca981e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881ca981f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881ca981f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881ca982000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* KASAN: user-memory-access Read in hidraw_ioctl
From: syzbot @ 2019-07-30 12:28 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 7f7867ff usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=13c21ab4600000
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=5a8c44432a51154ff6d5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5a8c44432a51154ff6d5@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: user-memory-access in _copy_to_user+0x124/0x150
lib/usercopy.c:27
Read of size 148 at addr 0000100000000000 by task syz-executor.2/19576
CPU: 1 PID: 19576 Comm: syz-executor.2 Not tainted 5.3.0-rc2+ #23
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
__kasan_report.cold+0x5/0x33 mm/kasan/report.c:486
kasan_report+0xe/0x12 mm/kasan/common.c:612
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x128/0x190 mm/kasan/generic.c:192
_copy_to_user+0x124/0x150 lib/usercopy.c:27
copy_to_user include/linux/uaccess.h:152 [inline]
hidraw_ioctl+0x39c/0xae0 drivers/hid/hidraw.c:392
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f6587cfbc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000020005640 RSI: 0000000090044802 RDI: 0000000000000004
RBP: 000000000075c070 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6587cfc6d4
R13: 00000000004c21db R14: 00000000004d5540 R15: 00000000ffffffff
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH v2] Input: applespi - register touchpad device synchronously in probe
From: Andy Shevchenko @ 2019-07-30 12:39 UTC (permalink / raw)
To: Life is hard, and then you die
Cc: Dmitry Torokhov, Mao Wenan, Federico Lorenzi, linux-input,
linux-kernel
In-Reply-To: <20190730065648.GA20206@innovation.ch>
On Mon, Jul 29, 2019 at 11:56:48PM -0700, Life is hard, and then you die wrote:
> On Mon, Jul 29, 2019 at 03:22:03PM +0200, Dmitry Torokhov wrote:
> > On Sun, Jul 21, 2019 at 12:05:23AM -0700, Ronald Tschalär wrote:
> > Question: is it possible to read command response synchronously as well?
> > I.e. I was wondering if we could add 2 (or 1?) more read xfers for the
> > actual result that is coming after the status response, and then we
> > could use spi_sync() to send the command and read the whole thing.
>
> Yes'ish. But you still need to wait for the GPE to know when to read
> the response, and while you're doing so any number of keyboard and
> trackpad events may arrive (i.e. you may need to do any number of read
> xfers). I suppose those events could all just be discarded, though. So
> something like this:
>
> assemble-info-cmd(write_msg)
> spi_sync(write_msg)
>
> while (1) {
> wait_event_timeout(wait_queue, gpe_received, timeout)
> spi_sync(read_msg)
> if (is-info-cmd-response(read_msg))
> break
> }
Just a side note if you ever going to implement such loops.
Consider in this or similar case do {} while approach with more straight exit
conditional.
Like
assemble-info-cmd(write_msg)
do {
spi_sync(read_msg)
wait_event_timeout(wait_queue, gpe_received, timeout)
} while (!is-info-cmd-response(read_msg)
> and also modify the gpe-handler to wake the wait_queue instead of
> issuing an spy_async() while doing the above.
>
> I guess the advantage would certainly be the need to avoid the
> spi-flushing in case of a timeout, at the expense of some slight
> duplication of some of the received-message handling logic (would
> refactor make most re-usable, of course).
>
> So would this be the preferred approach then?
--
With Best Regards,
Andy Shevchenko
^ 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