* Re: [PATCH] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Benjamin Tissoires @ 2018-12-14 8:25 UTC (permalink / raw)
To: kernelrocks; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, mbrugger
In-Reply-To: <20181214080700.GA4189@rocks>
Hi Aleix,
On Fri, Dec 14, 2018 at 9:07 AM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
>
> Kind remminder ping :)
Hehe, I have seen the patch floating by and realized I would need more
than 2 minutes to answer it so it fell a little bit behind in my TODO
list.
Let's try to work on this now.
>
> I'm also adding my fellow Matthias in CC
>
> On Sat, Dec 01, 2018 at 08:01:53PM +0100, Aleix Roca Nonell wrote:
> > The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
> > specific UsagePage 0xff31. In consequence, some multimedia keys such as
> > brightness up and down are not working with hid-generic.
> >
> > This commit adds the T101HA dock into the supported device list of the
> > hid-asus driver. It also prevents the dock's integrated touchpad to be
> > bound with hid-asus given that it is already working fine with
> > hid-multitouch.
> >
> > Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
> > ---
> >
> > This is my very first kernel patch done in my free time (be aware of the
> > newbie!!) so please, let me know if I can improve anything and I will
> > happily do it :)
> >
> > drivers/hid/hid-asus.c | 12 ++++++++++++
> > drivers/hid/hid-ids.h | 1 +
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > index ab8bd40a77ed..d8b55dca97c6 100644
> > --- a/drivers/hid/hid-asus.c
> > +++ b/drivers/hid/hid-asus.c
> > @@ -42,6 +42,7 @@ MODULE_AUTHOR("Frederik Wenigwieser <frederik.wenigwieser@gmail.com>");
> > MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> >
> > #define T100_TPAD_INTF 2
> > +#define T101HA_TPAD_INTF 2
> >
> > #define T100CHI_MOUSE_REPORT_ID 0x06
> > #define FEATURE_REPORT_ID 0x0d
> > @@ -70,6 +71,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > #define QUIRK_T100_KEYBOARD BIT(6)
> > #define QUIRK_T100CHI BIT(7)
> > #define QUIRK_G752_KEYBOARD BIT(8)
> > +#define QUIRK_T101HA_DOCK BIT(9)
> >
> > #define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
> > QUIRK_NO_INIT_REPORTS | \
> > @@ -649,6 +651,14 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > int ret;
> > struct asus_drvdata *drvdata;
> >
> > + if (id->driver_data & QUIRK_T101HA_DOCK) {
> > + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
I know the hid-asus driver already does this for the other devices,
but it would be nice not to. USB is part of the low level transport
and HID drivers should have no reasons to assume the USB driver is
used and that it will stay forever.
What I ask when we have such a case is to check on the report
descriptor to see if there is anything we could use in it (usually the
application) to skip this HID interface.
Besides that, there is not much more to say.
For having a look at the report descriptor, you can either use printk
in the kernel, or use hid-recorder as root in
https://gitlab.freedesktop.org/libevdev/hid-tools.
Cheers,
Benjamin
> > +
> > + /* use hid-multitouch for T101HA touchpad */
> > + if (intf->altsetting->desc.bInterfaceNumber == T101HA_TPAD_INTF)
> > + return -ENODEV;
> > + }
> > +
> > drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
> > if (drvdata == NULL) {
> > hid_err(hdev, "Can't alloc Asus descriptor\n");
> > @@ -830,6 +840,8 @@ static const struct hid_device_id asus_devices[] = {
> > { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
> > QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> > + { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > + USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
> > { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> > { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 4206428c0ba2..f1eee2778b70 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -184,6 +184,7 @@
> > #define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
> > #define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
> > #define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
> > +#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
> > #define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
> > #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> > #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> > --
> > 2.19.2
> >
^ permalink raw reply
* [PATCH] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
From: Kai-Heng Feng @ 2018-12-14 9:09 UTC (permalink / raw)
To: jikos, benjamin.tissoires; +Cc: linux-input, linux-kernel, Kai-Heng Feng
While using Elan touchpads, the message floods:
[ 136.138487] i2c_hid i2c-DELL08D6:00: i2c_hid_get_input: incomplete report (14/65535)
Though the message flood is annoying, the device it self works without
any issue. I suspect that the device in question takes too much time to
pull the IRQ back to high after I2C host has done reading its data.
Since the host receives all useful data, let's ignore the input report
when there's no data.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
drivers/hid/i2c-hid/i2c-hid-core.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 8555ce7e737b..1776afa6d69c 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -50,6 +50,7 @@
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
#define I2C_HID_QUIRK_NO_RUNTIME_PM BIT(2)
#define I2C_HID_QUIRK_DELAY_AFTER_SLEEP BIT(3)
+#define I2C_HID_QUIRK_BOGUS_IRQ BIT(4)
/* flags */
#define I2C_HID_STARTED 0
@@ -179,6 +180,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
{ USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
I2C_HID_QUIRK_NO_RUNTIME_PM },
+ { USB_VENDOR_ID_ELAN, HID_ANY_ID,
+ I2C_HID_QUIRK_BOGUS_IRQ },
{ 0, 0 }
};
@@ -503,6 +506,12 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
return;
}
+ if (ihid->quirks & I2C_HID_QUIRK_BOGUS_IRQ && ret_size == 0xffff) {
+ dev_dbg(&ihid->client->dev,
+ "%s: IRQ triggered but there's no data\n", __func__);
+ return;
+ }
+
if ((ret_size > size) || (ret_size < 2)) {
dev_err(&ihid->client->dev, "%s: incomplete report (%d/%d)\n",
__func__, size, ret_size);
--
2.17.1
^ permalink raw reply related
* [PATCH v3] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
From: Enric Balletbo i Serra @ 2018-12-14 11:48 UTC (permalink / raw)
To: linux-kernel
Cc: Alessandro Zummo, linux-pwm, linux-iio, Alexandre Belloni,
linux-i2c, groeck, kernel, linux-rtc, Chanwoo Choi, Benson Leung,
Sebastian Reichel, linux-input, Dmitry Torokhov, Jonathan Cameron,
Peter Meerwald-Stadler, devicetree, Thierry Reding, linux-pm,
MyungJoo Ham, Lee Jones, Hartmut Knaack, Rob Herring, Lars
There are multiple ChromeOS EC sub-drivers spread in different
subsystems, as all of them are related to the Chrome stuff add
Benson and myself as a maintainers for all these sub-drivers.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> for iio parts.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
Changes in v3:
- Add collected acks
- Use a cros[-_]ec pattern instead of list all the files.
- Add Guenter as a reviewer.
Changes in v2:
- Fix typo in Benson email address.
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e7260191301b..437e036435d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3629,6 +3629,14 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
F: drivers/platform/chrome/
+CHROMEOS EC SUBDRIVERS
+M: Benson Leung <bleung@chromium.org>
+M: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+R: Guenter Roeck <groeck@chromium.org>
+S: Maintained
+N: cros[-_]ec
+F: drivers/power/supply/cros_usbpd-charger.c
+
CIRRUS LOGIC AUDIO CODEC DRIVERS
M: Brian Austin <brian.austin@cirrus.com>
M: Paul Handrigan <Paul.Handrigan@cirrus.com>
--
2.19.2
^ permalink raw reply related
* Re: [PATCH v3] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
From: Enric Balletbo i Serra @ 2018-12-14 11:53 UTC (permalink / raw)
To: linux-kernel
Cc: Alessandro Zummo, linux-pwm, linux-iio, Alexandre Belloni,
linux-i2c, groeck, kernel, linux-rtc, Chanwoo Choi, Benson Leung,
Sebastian Reichel, linux-input, Dmitry Torokhov, Jonathan Cameron,
Peter Meerwald-Stadler, devicetree, Thierry Reding, linux-pm,
MyungJoo Ham, Lee Jones, Hartmut Knaack, Rob Herring, Lars
In-Reply-To: <20181214114858.21231-1-enric.balletbo@collabora.com>
On 14/12/18 12:48, Enric Balletbo i Serra wrote:
> There are multiple ChromeOS EC sub-drivers spread in different
> subsystems, as all of them are related to the Chrome stuff add
> Benson and myself as a maintainers for all these sub-drivers.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Benson Leung <bleung@chromium.org>
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> for iio parts.
Ok, I resend the patch too quickly and I forget to remove the `for iio parts`.I
will wait a bit more for if I receive more acks and send a v4 to fix this.
> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>
> Changes in v3:
> - Add collected acks
> - Use a cros[-_]ec pattern instead of list all the files.
> - Add Guenter as a reviewer.
>
> Changes in v2:
> - Fix typo in Benson email address.
>
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e7260191301b..437e036435d5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3629,6 +3629,14 @@ S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
> F: drivers/platform/chrome/
>
> +CHROMEOS EC SUBDRIVERS
> +M: Benson Leung <bleung@chromium.org>
> +M: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> +R: Guenter Roeck <groeck@chromium.org>
> +S: Maintained
> +N: cros[-_]ec
> +F: drivers/power/supply/cros_usbpd-charger.c
> +
> CIRRUS LOGIC AUDIO CODEC DRIVERS
> M: Brian Austin <brian.austin@cirrus.com>
> M: Paul Handrigan <Paul.Handrigan@cirrus.com>
>
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: Lee Jones @ 2018-12-14 12:47 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1543571742-17995-1-git-send-email-p.paillet@st.com>
On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
> The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
> STMicroelectronics.
> The STPMIC1 regulators supply power to an application processor as well as
> to external system peripherals such as DDR, Flash memories and system
> devices. It also features onkey button input and an hardware watchdog.
> The STPMIC1 is controlled via I2C.
>
> Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
> irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
> as parent.
>
> STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
>
> Pascal Paillet (7):
> changes in v7:
> * rebase on regul/for-next
>
> dt-bindings: mfd: document stpmic1
> mfd: stpmic1: add stpmic1 driver
> dt-bindings: input: document stpmic1 pmic onkey
> input: stpmic1: add stpmic1 onkey driver
> dt-bindings: watchdog: document stpmic1 pmic watchdog
> watchdog: stpmic1: add stpmic1 watchdog driver
> regulator: stpmic1: fix regulator_lock usage
Could you please remove any patches which have been applied and
[RESEND]?
Also, is Dmitry planning on Acking:
dt-bindings: input: document stpmic1 pmic onkey
... or is Rob's Ack enough?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v3] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
From: Sebastian Reichel @ 2018-12-14 13:17 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: linux-kernel, Alessandro Zummo, linux-pwm, linux-iio,
Alexandre Belloni, linux-i2c, groeck, kernel, linux-rtc,
Chanwoo Choi, Benson Leung, linux-input, Dmitry Torokhov,
Jonathan Cameron, Peter Meerwald-Stadler, devicetree,
Thierry Reding, linux-pm, MyungJoo Ham, Lee Jones, Hartmut Knaack,
Rob Herring, Lars-Peter
In-Reply-To: <20181214114858.21231-1-enric.balletbo@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
Hi,
On Fri, Dec 14, 2018 at 12:48:58PM +0100, Enric Balletbo i Serra wrote:
> There are multiple ChromeOS EC sub-drivers spread in different
> subsystems, as all of them are related to the Chrome stuff add
> Benson and myself as a maintainers for all these sub-drivers.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Benson Leung <bleung@chromium.org>
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> for iio parts.
> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
>
> Changes in v3:
> - Add collected acks
> - Use a cros[-_]ec pattern instead of list all the files.
> - Add Guenter as a reviewer.
>
> Changes in v2:
> - Fix typo in Benson email address.
>
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e7260191301b..437e036435d5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3629,6 +3629,14 @@ S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
> F: drivers/platform/chrome/
>
> +CHROMEOS EC SUBDRIVERS
> +M: Benson Leung <bleung@chromium.org>
> +M: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> +R: Guenter Roeck <groeck@chromium.org>
> +S: Maintained
> +N: cros[-_]ec
> +F: drivers/power/supply/cros_usbpd-charger.c
> +
> CIRRUS LOGIC AUDIO CODEC DRIVERS
> M: Brian Austin <brian.austin@cirrus.com>
> M: Paul Handrigan <Paul.Handrigan@cirrus.com>
> --
> 2.19.2
>
>
> --
> To unsubscribe, send mail to kernel-unsubscribe@lists.collabora.co.uk.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Aleix Roca Nonell @ 2018-12-14 13:34 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, mbrugger
In-Reply-To: <CAO-hwJJRuBbHKCmW4vcmjdDkNEF0==wuLC5ymSkw8mOHnkdwwQ@mail.gmail.com>
Hi Benjamin! :D
On Fri, Dec 14, 2018 at 09:25:20AM +0100, Benjamin Tissoires wrote:
> Hi Aleix,
>
> On Fri, Dec 14, 2018 at 9:07 AM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
> >
> > Kind remminder ping :)
>
> Hehe, I have seen the patch floating by and realized I would need more
> than 2 minutes to answer it so it fell a little bit behind in my TODO
> list.
>
> Let's try to work on this now.
>
> >
> > I'm also adding my fellow Matthias in CC
> >
> > On Sat, Dec 01, 2018 at 08:01:53PM +0100, Aleix Roca Nonell wrote:
> > > The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
> > > specific UsagePage 0xff31. In consequence, some multimedia keys such as
> > > brightness up and down are not working with hid-generic.
> > >
> > > This commit adds the T101HA dock into the supported device list of the
> > > hid-asus driver. It also prevents the dock's integrated touchpad to be
> > > bound with hid-asus given that it is already working fine with
> > > hid-multitouch.
> > >
> > > Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
> > > ---
> > >
> > > This is my very first kernel patch done in my free time (be aware of the
> > > newbie!!) so please, let me know if I can improve anything and I will
> > > happily do it :)
> > >
> > > drivers/hid/hid-asus.c | 12 ++++++++++++
> > > drivers/hid/hid-ids.h | 1 +
> > > 2 files changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > > index ab8bd40a77ed..d8b55dca97c6 100644
> > > --- a/drivers/hid/hid-asus.c
> > > +++ b/drivers/hid/hid-asus.c
> > > @@ -42,6 +42,7 @@ MODULE_AUTHOR("Frederik Wenigwieser <frederik.wenigwieser@gmail.com>");
> > > MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > >
> > > #define T100_TPAD_INTF 2
> > > +#define T101HA_TPAD_INTF 2
> > >
> > > #define T100CHI_MOUSE_REPORT_ID 0x06
> > > #define FEATURE_REPORT_ID 0x0d
> > > @@ -70,6 +71,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > > #define QUIRK_T100_KEYBOARD BIT(6)
> > > #define QUIRK_T100CHI BIT(7)
> > > #define QUIRK_G752_KEYBOARD BIT(8)
> > > +#define QUIRK_T101HA_DOCK BIT(9)
> > >
> > > #define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
> > > QUIRK_NO_INIT_REPORTS | \
> > > @@ -649,6 +651,14 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > > int ret;
> > > struct asus_drvdata *drvdata;
> > >
> > > + if (id->driver_data & QUIRK_T101HA_DOCK) {
> > > + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>
> I know the hid-asus driver already does this for the other devices,
> but it would be nice not to. USB is part of the low level transport
> and HID drivers should have no reasons to assume the USB driver is
> used and that it will stay forever.
>
> What I ask when we have such a case is to check on the report
> descriptor to see if there is anything we could use in it (usually the
> application) to skip this HID interface.
>
> Besides that, there is not much more to say.
Great I will do that!
> For having a look at the report descriptor, you can either use printk
> in the kernel, or use hid-recorder as root in
> https://gitlab.freedesktop.org/libevdev/hid-tools.
Regarding the descriptor, shouldn't be ok to check
/sys/kernel/debug/hid/<dev>/rdesc ?
Thank you!
>
> Cheers,
> Benjamin
>
> > > +
> > > + /* use hid-multitouch for T101HA touchpad */
> > > + if (intf->altsetting->desc.bInterfaceNumber == T101HA_TPAD_INTF)
> > > + return -ENODEV;
> > > + }
> > > +
> > > drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
> > > if (drvdata == NULL) {
> > > hid_err(hdev, "Can't alloc Asus descriptor\n");
> > > @@ -830,6 +840,8 @@ static const struct hid_device_id asus_devices[] = {
> > > { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > > USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
> > > QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> > > + { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > > + USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
> > > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
> > > { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> > > { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
> > > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > > index 4206428c0ba2..f1eee2778b70 100644
> > > --- a/drivers/hid/hid-ids.h
> > > +++ b/drivers/hid/hid-ids.h
> > > @@ -184,6 +184,7 @@
> > > #define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
> > > #define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
> > > #define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
> > > +#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
> > > #define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
> > > #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> > > #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> > > --
> > > 2.19.2
> > >
^ permalink raw reply
* Re: [PATCH] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Benjamin Tissoires @ 2018-12-14 13:37 UTC (permalink / raw)
To: kernelrocks; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, mbrugger
In-Reply-To: <20181214133409.GB4189@rocks>
On Fri, Dec 14, 2018 at 2:34 PM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
>
> Hi Benjamin! :D
>
> On Fri, Dec 14, 2018 at 09:25:20AM +0100, Benjamin Tissoires wrote:
> > Hi Aleix,
> >
> > On Fri, Dec 14, 2018 at 9:07 AM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
> > >
> > > Kind remminder ping :)
> >
> > Hehe, I have seen the patch floating by and realized I would need more
> > than 2 minutes to answer it so it fell a little bit behind in my TODO
> > list.
> >
> > Let's try to work on this now.
> >
> > >
> > > I'm also adding my fellow Matthias in CC
> > >
> > > On Sat, Dec 01, 2018 at 08:01:53PM +0100, Aleix Roca Nonell wrote:
> > > > The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
> > > > specific UsagePage 0xff31. In consequence, some multimedia keys such as
> > > > brightness up and down are not working with hid-generic.
> > > >
> > > > This commit adds the T101HA dock into the supported device list of the
> > > > hid-asus driver. It also prevents the dock's integrated touchpad to be
> > > > bound with hid-asus given that it is already working fine with
> > > > hid-multitouch.
> > > >
> > > > Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
> > > > ---
> > > >
> > > > This is my very first kernel patch done in my free time (be aware of the
> > > > newbie!!) so please, let me know if I can improve anything and I will
> > > > happily do it :)
> > > >
> > > > drivers/hid/hid-asus.c | 12 ++++++++++++
> > > > drivers/hid/hid-ids.h | 1 +
> > > > 2 files changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > > > index ab8bd40a77ed..d8b55dca97c6 100644
> > > > --- a/drivers/hid/hid-asus.c
> > > > +++ b/drivers/hid/hid-asus.c
> > > > @@ -42,6 +42,7 @@ MODULE_AUTHOR("Frederik Wenigwieser <frederik.wenigwieser@gmail.com>");
> > > > MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > > >
> > > > #define T100_TPAD_INTF 2
> > > > +#define T101HA_TPAD_INTF 2
> > > >
> > > > #define T100CHI_MOUSE_REPORT_ID 0x06
> > > > #define FEATURE_REPORT_ID 0x0d
> > > > @@ -70,6 +71,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > > > #define QUIRK_T100_KEYBOARD BIT(6)
> > > > #define QUIRK_T100CHI BIT(7)
> > > > #define QUIRK_G752_KEYBOARD BIT(8)
> > > > +#define QUIRK_T101HA_DOCK BIT(9)
> > > >
> > > > #define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
> > > > QUIRK_NO_INIT_REPORTS | \
> > > > @@ -649,6 +651,14 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > > > int ret;
> > > > struct asus_drvdata *drvdata;
> > > >
> > > > + if (id->driver_data & QUIRK_T101HA_DOCK) {
> > > > + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> >
> > I know the hid-asus driver already does this for the other devices,
> > but it would be nice not to. USB is part of the low level transport
> > and HID drivers should have no reasons to assume the USB driver is
> > used and that it will stay forever.
> >
> > What I ask when we have such a case is to check on the report
> > descriptor to see if there is anything we could use in it (usually the
> > application) to skip this HID interface.
> >
> > Besides that, there is not much more to say.
>
> Great I will do that!
>
> > For having a look at the report descriptor, you can either use printk
> > in the kernel, or use hid-recorder as root in
> > https://gitlab.freedesktop.org/libevdev/hid-tools.
>
> Regarding the descriptor, shouldn't be ok to check
> /sys/kernel/debug/hid/<dev>/rdesc ?
Yep, that works too. I knew there was an other way from the kernel but
couldn't remember it :)
I am more used to hid-recorder as it agregates everything in a more
compact way and you can then replay the traces with hid-replay.
Cheers,
Benjamin
>
> Thank you!
>
> >
> > Cheers,
> > Benjamin
> >
> > > > +
> > > > + /* use hid-multitouch for T101HA touchpad */
> > > > + if (intf->altsetting->desc.bInterfaceNumber == T101HA_TPAD_INTF)
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
> > > > if (drvdata == NULL) {
> > > > hid_err(hdev, "Can't alloc Asus descriptor\n");
> > > > @@ -830,6 +840,8 @@ static const struct hid_device_id asus_devices[] = {
> > > > { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > > > USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
> > > > QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> > > > + { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > > > + USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
> > > > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
> > > > { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> > > > { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
> > > > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > > > index 4206428c0ba2..f1eee2778b70 100644
> > > > --- a/drivers/hid/hid-ids.h
> > > > +++ b/drivers/hid/hid-ids.h
> > > > @@ -184,6 +184,7 @@
> > > > #define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
> > > > #define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
> > > > #define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
> > > > +#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
> > > > #define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
> > > > #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> > > > #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> > > > --
> > > > 2.19.2
> > > >
^ permalink raw reply
* Re: [PATCH v3 7/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Clément VUCHENER @ 2018-12-14 13:46 UTC (permalink / raw)
To: Peter Hutterer
Cc: linux-input, Dmitry Torokhov, Jiri Kosina, Harry Cutts, torvalds,
Nestor Lopez Casado, lkml, Benjamin Tissoires
In-Reply-To: <20181205004228.10714-8-peter.hutterer@who-t.net>
Le mer. 5 déc. 2018 à 01:44, Peter Hutterer <peter.hutterer@who-t.net> a écrit :
>
> From: Harry Cutts <hcutts@chromium.org>
>
> There are three features used by various Logitech mice for
> high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0,
> and the x2120 and x2121 features in HID++ 2.0 and above. This patch
> supports all three, and uses the multiplier reported by the mouse for
> the HID++ 2.0+ features.
Hi, The G500s (and the G500 too, I think) does support the "scrolling
acceleration" bit. If I set it, I get around 8 events for each wheel
"click", this is what this driver expects, right? If I understood
correctly, I should try this patch with the
HIDPP_QUIRK_HI_RES_SCROLL_1P0 quirk set for my mouse.
^ permalink raw reply
* Re: [PATCH v3] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
From: Guenter Roeck @ 2018-12-14 14:29 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: linux-kernel, Alessandro Zummo, linux-pwm, linux-iio,
alexandre.belloni, linux-i2c, Guenter Roeck, kernel, linux-rtc,
Chanwoo Choi, Benson Leung, Sebastian Reichel, linux-input,
Dmitry Torokhov, Jonathan Cameron, Peter Meerwald-Stadler,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Thierry Reding,
linux-pm, MyungJoo Ham, Lee Jones
In-Reply-To: <20181214114858.21231-1-enric.balletbo@collabora.com>
On Fri, Dec 14, 2018 at 3:49 AM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> There are multiple ChromeOS EC sub-drivers spread in different
> subsystems, as all of them are related to the Chrome stuff add
> Benson and myself as a maintainers for all these sub-drivers.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Benson Leung <bleung@chromium.org>
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> for iio parts.
> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Guenter Roeck <groeck@chromium.org>
> ---
>
> Changes in v3:
> - Add collected acks
> - Use a cros[-_]ec pattern instead of list all the files.
> - Add Guenter as a reviewer.
>
> Changes in v2:
> - Fix typo in Benson email address.
>
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e7260191301b..437e036435d5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3629,6 +3629,14 @@ S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
> F: drivers/platform/chrome/
>
> +CHROMEOS EC SUBDRIVERS
> +M: Benson Leung <bleung@chromium.org>
> +M: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> +R: Guenter Roeck <groeck@chromium.org>
> +S: Maintained
> +N: cros[-_]ec
> +F: drivers/power/supply/cros_usbpd-charger.c
> +
> CIRRUS LOGIC AUDIO CODEC DRIVERS
> M: Brian Austin <brian.austin@cirrus.com>
> M: Paul Handrigan <Paul.Handrigan@cirrus.com>
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: Pascal PAILLET-LME @ 2018-12-14 14:36 UTC (permalink / raw)
To: Lee Jones
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <20181214124701.GZ4497@dell>
Hello Lee,
Le 12/14/2018 01:47 PM, Lee Jones a écrit :
> changes in v7:
> * rebase on regul/for-next
>
> dt-bindings: mfd: document stpmic1
> mfd: stpmic1: add stpmic1 driver
> dt-bindings: input: document stpmic1 pmic onkey
> input: stpmic1: add stpmic1 onkey driver
> dt-bindings: watchdog: document stpmic1 pmic watchdog
> watchdog: stpmic1: add stpmic1 watchdog driver
> regulator: stpmic1: fix regulator_lock usage
> Could you please remove any patches which have been applied and
> [RESEND]?
DONE, I have resent a V8 without the regulator patch.
> Also, is Dmitry planning on Acking:
>
> dt-bindings: input: document stpmic1 pmic onkey
>
> ... or is Rob's Ack enough?
>
thank you,
pascal
^ permalink raw reply
* Re: [PATCH v4 1/3] Input: atmel_mxt_ts: Add support for optional regulators
From: Paweł Chmiel @ 2018-12-14 15:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: nick, robh+dt, mark.rutland, nicolas.ferre, alexandre.belloni,
linux-input, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20181209042612.GD211094@dtor-ws>
Dnia niedziela, 9 grudnia 2018 05:26:12 CET Dmitry Torokhov pisze:
> On Fri, Dec 07, 2018 at 03:28:55PM +0100, Paweł Chmiel wrote:
> > This patch adds optional regulators, which can be used to power
> > up touchscreen. After enabling regulators, we need to wait 150msec.
> > This value is taken from official driver.
> >
> > It was tested on Samsung Galaxy i9000 (based on Samsung S5PV210 SOC).
> >
> > Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> > ---
> > Changes from v3:
> > - Fix checkpatch issues
> > - Drop sentence punctuation from subject of one of patches
> >
> > Changes from v2:
> > - Move code enabling regulators into separate method,
> > to make code more readable.
> >
> > Changes from v1:
> > - Enable regulators only if reset_gpio is present.
> > - Switch from devm_regulator_get_optional to devm_regulator_get
> > ---
> > drivers/input/touchscreen/atmel_mxt_ts.c | 65 +++++++++++++++++++++---
> > 1 file changed, 59 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> > index d3aacd534e9c..1dc8ad0da5af 100644
> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > @@ -27,6 +27,7 @@
> > #include <linux/interrupt.h>
> > #include <linux/of.h>
> > #include <linux/property.h>
> > +#include <linux/regulator/consumer.h>
> > #include <linux/slab.h>
> > #include <linux/gpio/consumer.h>
> > #include <asm/unaligned.h>
> > @@ -194,10 +195,10 @@ enum t100_type {
> >
> > /* Delay times */
> > #define MXT_BACKUP_TIME 50 /* msec */
> > -#define MXT_RESET_GPIO_TIME 20 /* msec */
> > #define MXT_RESET_INVALID_CHG 100 /* msec */
> > #define MXT_RESET_TIME 200 /* msec */
> > #define MXT_RESET_TIMEOUT 3000 /* msec */
> > +#define MXT_REGULATOR_DELAY 150 /* msec */
> > #define MXT_CRC_TIMEOUT 1000 /* msec */
> > #define MXT_FW_RESET_TIME 3000 /* msec */
> > #define MXT_FW_CHG_TIMEOUT 300 /* msec */
> > @@ -323,6 +324,8 @@ struct mxt_data {
> > struct t7_config t7_cfg;
> > struct mxt_dbg dbg;
> > struct gpio_desc *reset_gpio;
> > + struct regulator *vdd_reg;
> > + struct regulator *avdd_reg;
> >
> > /* Cached parameters from object table */
> > u16 T5_address;
> > @@ -3038,6 +3041,38 @@ static const struct dmi_system_id chromebook_T9_suspend_dmi[] = {
> > { }
> > };
> >
> > +static int mxt_regulator_enable(struct mxt_data *data)
> > +{
> > + int error;
> > +
> > + if (data->reset_gpio) {
> > + error = regulator_enable(data->vdd_reg);
> > + if (error) {
> > + dev_err(&data->client->dev,
> > + "Failed to enable vdd regulator: %d\n", error);
> > + return error;
> > + }
> > +
> > + error = regulator_enable(data->avdd_reg);
> > + if (error) {
> > + dev_err(&data->client->dev,
> > + "Failed to enable avdd regulator: %d\n", error);
>
> This leaves vdd regulator enabled.
Will be fixed in v5 version (will be today)
Thanks for review.
>
> Thanks.
>
>
^ permalink raw reply
* [PATCH v5 0/3] Input: atmel_mxt_ts: Add support for optional regulators
From: Paweł Chmiel @ 2018-12-14 15:12 UTC (permalink / raw)
To: nick
Cc: dmitry.torokhov, robh+dt, mark.rutland, nicolas.ferre,
alexandre.belloni, linux-input, devicetree, linux-arm-kernel,
linux-kernel, Paweł Chmiel
This patch series adds optional regulator support to atmel_mxt_ts.
First patch adds regulators to driver.
Second patch ensures that device is ready for communication.
Third patch updates documentation.
Changes from v4:
- Add missing regulator_disable for vdd in case of error,
when enabling avdd regulator
Changes from v3:
- Checkpatch fixes
- Drop punctuation from subject of one of patches
Changes from v2:
- Add reviewed-by to one patch
- Move code for enabling regulators into separate method,
to make code more readable.
- Add wait code, to ensure that device is ready for communication.
Changes from v1:
- Enable regulators only if reset_gpio is present.
- Switch from devm_regulator_get_optional to devm_regulator_get.
Paweł Chmiel (3):
Input: atmel_mxt_ts: Add support for optional regulators
Input: atmel_mxt_ts: Wait for device be ready for communication
Input: atmel_mxt_ts: Document optional voltage regulators
.../bindings/input/atmel,maxtouch.txt | 8 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 78 +++++++++++++++++--
2 files changed, 80 insertions(+), 6 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v5 1/3] Input: atmel_mxt_ts: Add support for optional regulators
From: Paweł Chmiel @ 2018-12-14 15:12 UTC (permalink / raw)
To: nick
Cc: dmitry.torokhov, robh+dt, mark.rutland, nicolas.ferre,
alexandre.belloni, linux-input, devicetree, linux-arm-kernel,
linux-kernel, Paweł Chmiel
In-Reply-To: <20181214151214.5391-1-pawel.mikolaj.chmiel@gmail.com>
This patch adds optional regulators, which can be used to power
up touchscreen. After enabling regulators, we need to wait 150msec.
This value is taken from official driver.
It was tested on Samsung Galaxy i9000 (based on Samsung S5PV210 SOC).
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
Changes from v4:
- Add missing regulator_disable for vdd in case of error,
when enabling avdd regulator
Changes from v3:
- Fix checkpatch issues
- Drop sentence punctuation from patch subject
Changes from v2:
- Move code enabling regulators into separate method,
to make code more readable.
Changes from v1:
- Enable regulators only if reset_gpio is present.
- Switch from devm_regulator_get_optional to devm_regulator_get
---
drivers/input/touchscreen/atmel_mxt_ts.c | 67 +++++++++++++++++++++---
1 file changed, 61 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index d3aacd534e9c..55a107fc1b73 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -27,6 +27,7 @@
#include <linux/interrupt.h>
#include <linux/of.h>
#include <linux/property.h>
+#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/gpio/consumer.h>
#include <asm/unaligned.h>
@@ -194,10 +195,10 @@ enum t100_type {
/* Delay times */
#define MXT_BACKUP_TIME 50 /* msec */
-#define MXT_RESET_GPIO_TIME 20 /* msec */
#define MXT_RESET_INVALID_CHG 100 /* msec */
#define MXT_RESET_TIME 200 /* msec */
#define MXT_RESET_TIMEOUT 3000 /* msec */
+#define MXT_REGULATOR_DELAY 150 /* msec */
#define MXT_CRC_TIMEOUT 1000 /* msec */
#define MXT_FW_RESET_TIME 3000 /* msec */
#define MXT_FW_CHG_TIMEOUT 300 /* msec */
@@ -323,6 +324,8 @@ struct mxt_data {
struct t7_config t7_cfg;
struct mxt_dbg dbg;
struct gpio_desc *reset_gpio;
+ struct regulator *vdd_reg;
+ struct regulator *avdd_reg;
/* Cached parameters from object table */
u16 T5_address;
@@ -3038,6 +3041,40 @@ static const struct dmi_system_id chromebook_T9_suspend_dmi[] = {
{ }
};
+static int mxt_regulator_enable(struct mxt_data *data)
+{
+ int error;
+
+ if (data->reset_gpio) {
+ error = regulator_enable(data->vdd_reg);
+ if (error) {
+ dev_err(&data->client->dev,
+ "Failed to enable vdd regulator: %d\n", error);
+ return error;
+ }
+
+ error = regulator_enable(data->avdd_reg);
+ if (error) {
+ regulator_disable(data->vdd_reg);
+
+ dev_err(&data->client->dev,
+ "Failed to enable avdd regulator: %d\n", error);
+ return error;
+ }
+
+ /*
+ * According to maXTouch power sequencing specification,
+ * RESET line must be kept low until some time
+ * after regulators come up to voltage
+ */
+ msleep(MXT_REGULATOR_DELAY);
+ gpiod_set_value(data->reset_gpio, 1);
+ msleep(MXT_RESET_INVALID_CHG);
+ }
+
+ return 0;
+}
+
static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct mxt_data *data;
@@ -3098,6 +3135,22 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
return error;
}
+ data->vdd_reg = devm_regulator_get(&client->dev, "vdd");
+ if (IS_ERR(data->vdd_reg)) {
+ error = PTR_ERR(data->vdd_reg);
+ dev_err(&client->dev, "Failed to get vdd regulator: %d\n",
+ error);
+ return error;
+ }
+
+ data->avdd_reg = devm_regulator_get(&client->dev, "avdd");
+ if (IS_ERR(data->avdd_reg)) {
+ error = PTR_ERR(data->avdd_reg);
+ dev_err(&client->dev, "Failed to get avdd regulator: %d\n",
+ error);
+ return error;
+ }
+
error = devm_request_threaded_irq(&client->dev, client->irq,
NULL, mxt_interrupt, IRQF_ONESHOT,
client->name, data);
@@ -3108,11 +3161,9 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
disable_irq(client->irq);
- if (data->reset_gpio) {
- msleep(MXT_RESET_GPIO_TIME);
- gpiod_set_value(data->reset_gpio, 1);
- msleep(MXT_RESET_INVALID_CHG);
- }
+ error = mxt_regulator_enable(data);
+ if (error)
+ return error;
error = mxt_initialize(data);
if (error)
@@ -3138,6 +3189,10 @@ static int mxt_remove(struct i2c_client *client)
struct mxt_data *data = i2c_get_clientdata(client);
disable_irq(data->irq);
+ if (data->reset_gpio) {
+ regulator_disable(data->avdd_reg);
+ regulator_disable(data->vdd_reg);
+ }
sysfs_remove_group(&client->dev.kobj, &mxt_attr_group);
mxt_free_input_device(data);
mxt_free_object_table(data);
--
2.17.1
^ permalink raw reply related
* [PATCH v5 2/3] Input: atmel_mxt_ts: Wait for device be ready for communication
From: Paweł Chmiel @ 2018-12-14 15:12 UTC (permalink / raw)
To: nick
Cc: dmitry.torokhov, robh+dt, mark.rutland, nicolas.ferre,
alexandre.belloni, linux-input, devicetree, linux-arm-kernel,
linux-kernel, Paweł Chmiel
In-Reply-To: <20181214151214.5391-1-pawel.mikolaj.chmiel@gmail.com>
According to documentation, device isn't ready for communication,
until firmware asserts the CHG line. Add missing wait for this.
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
Changes from v1:
- Fix checkpatch issues
---
drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 55a107fc1b73..e8949c6ceafa 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -202,6 +202,7 @@ enum t100_type {
#define MXT_CRC_TIMEOUT 1000 /* msec */
#define MXT_FW_RESET_TIME 3000 /* msec */
#define MXT_FW_CHG_TIMEOUT 300 /* msec */
+#define MXT_POWERON_DELAY 150 /* msec */
/* Command to unlock bootloader */
#define MXT_UNLOCK_CMD_MSB 0xaa
@@ -3070,6 +3071,16 @@ static int mxt_regulator_enable(struct mxt_data *data)
msleep(MXT_REGULATOR_DELAY);
gpiod_set_value(data->reset_gpio, 1);
msleep(MXT_RESET_INVALID_CHG);
+
+retry_wait:
+ reinit_completion(&data->bl_completion);
+ data->in_bootloader = true;
+ error = mxt_wait_for_completion(data, &data->bl_completion,
+ MXT_POWERON_DELAY);
+ if (error == -EINTR)
+ goto retry_wait;
+
+ data->in_bootloader = false;
}
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH v5 3/3] Input: atmel_mxt_ts: Document optional voltage regulators
From: Paweł Chmiel @ 2018-12-14 15:12 UTC (permalink / raw)
To: nick
Cc: dmitry.torokhov, robh+dt, mark.rutland, nicolas.ferre,
alexandre.belloni, linux-input, devicetree, linux-arm-kernel,
linux-kernel, Paweł Chmiel
In-Reply-To: <20181214151214.5391-1-pawel.mikolaj.chmiel@gmail.com>
Document new optional voltage regulators, which can be used
to power down/up touchscreen.
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes from v1:
- Added reviewed-by
---
.../devicetree/bindings/input/atmel,maxtouch.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
index c88919480d37..17930ecadad3 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
@@ -31,6 +31,12 @@ Optional properties for main touchpad device:
- reset-gpios: GPIO specifier for the touchscreen's reset pin (active low)
+- avdd-supply: Analog power supply. It powers up the analog channel block
+ of the controller to detect the touches.
+
+- vdd-supply: Digital power supply. It powers up the digital block
+ of the controller to enable i2c communication.
+
Example:
touch@4b {
@@ -38,4 +44,6 @@ Example:
reg = <0x4b>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&atsp_reg>;
+ vdd-supply = <&tsp_reg>;
};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Aleix Roca Nonell @ 2018-12-14 15:41 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, mbrugger
In-Reply-To: <CAO-hwJJsE0eFqYb8A9qFqohy6vXj4EB9qJ3myB_PPzbDa=Jo3Q@mail.gmail.com>
On Fri, Dec 14, 2018 at 02:37:52PM +0100, Benjamin Tissoires wrote:
> On Fri, Dec 14, 2018 at 2:34 PM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
> >
> > Hi Benjamin! :D
> >
> > On Fri, Dec 14, 2018 at 09:25:20AM +0100, Benjamin Tissoires wrote:
> > > Hi Aleix,
> > >
> > > On Fri, Dec 14, 2018 at 9:07 AM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
> > > >
> > > > Kind remminder ping :)
> > >
> > > Hehe, I have seen the patch floating by and realized I would need more
> > > than 2 minutes to answer it so it fell a little bit behind in my TODO
> > > list.
> > >
> > > Let's try to work on this now.
> > >
> > > >
> > > > I'm also adding my fellow Matthias in CC
> > > >
> > > > On Sat, Dec 01, 2018 at 08:01:53PM +0100, Aleix Roca Nonell wrote:
> > > > > The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
> > > > > specific UsagePage 0xff31. In consequence, some multimedia keys such as
> > > > > brightness up and down are not working with hid-generic.
> > > > >
> > > > > This commit adds the T101HA dock into the supported device list of the
> > > > > hid-asus driver. It also prevents the dock's integrated touchpad to be
> > > > > bound with hid-asus given that it is already working fine with
> > > > > hid-multitouch.
> > > > >
> > > > > Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
> > > > > ---
> > > > >
> > > > > This is my very first kernel patch done in my free time (be aware of the
> > > > > newbie!!) so please, let me know if I can improve anything and I will
> > > > > happily do it :)
> > > > >
> > > > > drivers/hid/hid-asus.c | 12 ++++++++++++
> > > > > drivers/hid/hid-ids.h | 1 +
> > > > > 2 files changed, 13 insertions(+)
> > > > >
> > > > > diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> > > > > index ab8bd40a77ed..d8b55dca97c6 100644
> > > > > --- a/drivers/hid/hid-asus.c
> > > > > +++ b/drivers/hid/hid-asus.c
> > > > > @@ -42,6 +42,7 @@ MODULE_AUTHOR("Frederik Wenigwieser <frederik.wenigwieser@gmail.com>");
> > > > > MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > > > >
> > > > > #define T100_TPAD_INTF 2
> > > > > +#define T101HA_TPAD_INTF 2
> > > > >
> > > > > #define T100CHI_MOUSE_REPORT_ID 0x06
> > > > > #define FEATURE_REPORT_ID 0x0d
> > > > > @@ -70,6 +71,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> > > > > #define QUIRK_T100_KEYBOARD BIT(6)
> > > > > #define QUIRK_T100CHI BIT(7)
> > > > > #define QUIRK_G752_KEYBOARD BIT(8)
> > > > > +#define QUIRK_T101HA_DOCK BIT(9)
> > > > >
> > > > > #define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
> > > > > QUIRK_NO_INIT_REPORTS | \
> > > > > @@ -649,6 +651,14 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > > > > int ret;
> > > > > struct asus_drvdata *drvdata;
> > > > >
> > > > > + if (id->driver_data & QUIRK_T101HA_DOCK) {
> > > > > + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> > >
> > > I know the hid-asus driver already does this for the other devices,
> > > but it would be nice not to. USB is part of the low level transport
> > > and HID drivers should have no reasons to assume the USB driver is
> > > used and that it will stay forever.
> > >
> > > What I ask when we have such a case is to check on the report
> > > descriptor to see if there is anything we could use in it (usually the
> > > application) to skip this HID interface.
> > >
> > > Besides that, there is not much more to say.
> >
> > Great I will do that!
> >
> > > For having a look at the report descriptor, you can either use printk
> > > in the kernel, or use hid-recorder as root in
> > > https://gitlab.freedesktop.org/libevdev/hid-tools.
> >
> > Regarding the descriptor, shouldn't be ok to check
> > /sys/kernel/debug/hid/<dev>/rdesc ?
>
> Yep, that works too. I knew there was an other way from the kernel but
> couldn't remember it :)
>
> I am more used to hid-recorder as it agregates everything in a more
> compact way and you can then replay the traces with hid-replay.
Oh right! I recall now from your slides! Thank you Benjamin! :)
> Cheers,
> Benjamin
>
> >
> > Thank you!
> >
> > >
> > > Cheers,
> > > Benjamin
> > >
> > > > > +
> > > > > + /* use hid-multitouch for T101HA touchpad */
> > > > > + if (intf->altsetting->desc.bInterfaceNumber == T101HA_TPAD_INTF)
> > > > > + return -ENODEV;
> > > > > + }
> > > > > +
> > > > > drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
> > > > > if (drvdata == NULL) {
> > > > > hid_err(hdev, "Can't alloc Asus descriptor\n");
> > > > > @@ -830,6 +840,8 @@ static const struct hid_device_id asus_devices[] = {
> > > > > { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > > > > USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
> > > > > QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> > > > > + { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> > > > > + USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
> > > > > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
> > > > > { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> > > > > { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
> > > > > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > > > > index 4206428c0ba2..f1eee2778b70 100644
> > > > > --- a/drivers/hid/hid-ids.h
> > > > > +++ b/drivers/hid/hid-ids.h
> > > > > @@ -184,6 +184,7 @@
> > > > > #define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
> > > > > #define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
> > > > > #define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
> > > > > +#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
> > > > > #define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
> > > > > #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> > > > > #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> > > > > --
> > > > > 2.19.2
> > > > >
^ permalink raw reply
* Re: [PATCH v3] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
From: Joe Perches @ 2018-12-14 17:24 UTC (permalink / raw)
To: Enric Balletbo i Serra, linux-kernel
Cc: Alessandro Zummo, linux-pwm, linux-iio, Alexandre Belloni,
linux-i2c, groeck, kernel, linux-rtc, Chanwoo Choi, Benson Leung,
Sebastian Reichel, linux-input, Dmitry Torokhov, Jonathan Cameron,
Peter Meerwald-Stadler, devicetree, Thierry Reding, linux-pm,
MyungJoo Ham, Lee Jones, Hartmut Knaack, Rob Herring, Lars
In-Reply-To: <20181214114858.21231-1-enric.balletbo@collabora.com>
On Fri, 2018-12-14 at 12:48 +0100, Enric Balletbo i Serra wrote:
> There are multiple ChromeOS EC sub-drivers spread in different
> subsystems, as all of them are related to the Chrome stuff add
> Benson and myself as a maintainers for all these sub-drivers.
[]
> Changes in v3:
> - Use a cros[-_]ec pattern instead of list all the files.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -3629,6 +3629,14 @@ S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
> F: drivers/platform/chrome/
>
> +CHROMEOS EC SUBDRIVERS
> +M: Benson Leung <bleung@chromium.org>
> +M: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> +R: Guenter Roeck <groeck@chromium.org>
> +S: Maintained
> +N: cros[-_]ec
For linux scripts/, it is unconventional to use a hyphen first
in a character class pattern so perhaps this is clearer using
two N: patterns
N: cros_
N: cros-
^ permalink raw reply
* Re: [PATCH v3 7/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Harry Cutts @ 2018-12-14 18:37 UTC (permalink / raw)
To: Clément VUCHENER
Cc: Peter Hutterer, linux-input, Dmitry Torokhov, Jiri Kosina,
torvalds, Nestor Lopez Casado, lkml, Benjamin Tissoires
In-Reply-To: <CAM4jgCqAh9Pck-9i8F5tO4-Kzpu+SjH-mQnGYThadSf-3b1ikw@mail.gmail.com>
Hi Clement,
On Fri, 14 Dec 2018 at 05:47, Clément VUCHENER
<clement.vuchener@gmail.com> wrote:
> Hi, The G500s (and the G500 too, I think) does support the "scrolling
> acceleration" bit. If I set it, I get around 8 events for each wheel
> "click", this is what this driver expects, right? If I understood
> correctly, I should try this patch with the
> HIDPP_QUIRK_HI_RES_SCROLL_1P0 quirk set for my mouse.
Thanks for the info! Yes, that should work.
Harry Cutts
Chrome OS Touch/Input team
^ permalink raw reply
* mouse driver crashed on 4.15 kernel
From: Yury Norov @ 2018-12-14 19:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: yury.norov, linux-input, linux-kernel, kernel-team
[-- Attachment #1: Type: text/plain, Size: 6329 bytes --]
Hi Dmitry,
It just happened to me on standard Ubuntu laptop (Lenovo X1 gen 5), so
I had to reboot my machine. According to logs, there was also a problem
with the wifi, but wifi driver managed to recover the hardware.
Looking at dmesg I cannot find something useful because it was wiped
with a number of identical warning messages from the mouse and SMBus
drivers.
I'm just a victim, and don't know much, but at least I can recommend to
use dev_warn_once() to avoid spamming the system log if things like this
happen.
Some system information is below, and system log is attached. Hope it
will help.
Thanks,
Yury
$ uname -a
Linux yury-thinkpad 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ dmesg|grep mouse
[ 1.089631] mousedev: PS/2 mouse device common for all mice
[ 2.553529] psmouse serio1: synaptics: queried max coordinates: x [..5676], y [..4760]
[ 2.584367] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[ 2.584370] psmouse serio1: synaptics: Trying to set up SMBus access
[ 3.115236] psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x04, buttons: 3/3
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1522.133
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1345.112
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1506.644
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1545.613
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
[-- Attachment #2: dmesg.oops.gz --]
[-- Type: application/gzip, Size: 14593 bytes --]
^ permalink raw reply
* [rfd] saving old mice -- button glitching/debouncing
From: Pavel Machek @ 2018-12-14 23:24 UTC (permalink / raw)
To: kernel list, jikos, vojtech, linux-input, dmitry.torokhov
[-- Attachment #1: Type: text/plain, Size: 6821 bytes --]
I believe I have hardware problem, but I'm kind of hoping software
could help me...?
Mouse wheel on my machine started glitching on my machine, generating
double-clicks when I click it once. Which unfortunately is quite
annoying: texts are pasted twice, two tabs are closed instead of one,
....
Event: time 1544733054.903129, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733054.903129, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1544733054.903129, -------------- EV_SYN ------------
1544733054.967251, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733054.967251, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1544733054.967251, -------------- EV_SYN ------------
Event: time 1544733054.975144, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733054.975144, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1544733054.975144, -------------- EV_SYN ------------
: time 1544733065.127190, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733065.127190, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1544733065.127190, -------------- EV_SYN ------------
Now, I could just buy a new mouse, but it seems that most optical mice
die like this... so maybe it would be nice to have an option to
debounce the buttons, so that the useful life of mice is extended a
bit?
(So... I have two mice with that fault -- cheap to replace, but button
in thinkpad X220 started doing that, too. That one will not be so
cheap to fix :-( ).
It is possible that some X versions already do something like this.
Patch is obviously not ready; but:
a) would it be useful to people
b) would it be acceptable if done properly? (cmd line option to
enable, avoiding duplicate/wrong events?)
Thanks,
Pavel
Signed-off-by: Pavel Machek <pavel@ucw.cz>
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3304aaa..ce0d081 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -40,6 +40,11 @@ static DEFINE_IDA(input_ida);
static LIST_HEAD(input_dev_list);
static LIST_HEAD(input_handler_list);
+static void input_repeat_key(struct timer_list *t);
+static void input_debounce_key(struct timer_list *t);
+
+static int debounce = 20;
+
/*
* input_mutex protects access to both input_dev_list and input_handler_list.
* This also causes input_[un]register_device and input_[un]register_handler
@@ -77,6 +82,7 @@ static void input_start_autorepeat(struct input_dev *dev, int code)
if (test_bit(EV_REP, dev->evbit) &&
dev->rep[REP_PERIOD] && dev->rep[REP_DELAY] &&
dev->timer.function) {
+ dev->timer.function = input_repeat_key;
dev->repeat_key = code;
mod_timer(&dev->timer,
jiffies + msecs_to_jiffies(dev->rep[REP_DELAY]));
@@ -88,18 +94,42 @@ static void input_stop_autorepeat(struct input_dev *dev)
del_timer(&dev->timer);
}
+static void input_start_debounce(struct input_dev *dev, int code)
+{
+ dev->timer.function = input_debounce_key;
+ dev->debounce_key = code;
+ mod_timer(&dev->timer,
+ jiffies + msecs_to_jiffies(debounce));
+}
+
+static void input_stop_debounce(struct input_dev *dev)
+{
+ del_timer(&dev->timer);
+ dev->debounce_key = -1;
+}
+
/*
* Pass event first through all filters and then, if event has not been
* filtered out, through all open handles. This function is called with
* dev->event_lock held and interrupts disabled.
*/
-static unsigned int input_to_handler(struct input_handle *handle,
+static unsigned int input_to_handler(struct input_dev *dev, struct input_handle *handle,
struct input_value *vals, unsigned int count)
{
struct input_handler *handler = handle->handler;
struct input_value *end = vals;
struct input_value *v;
+ if (!test_bit(EV_REP, dev->evbit) && test_bit(EV_KEY, dev->evbit) && debounce)
+ for (v = vals; v != vals + count; v++) {
+ if (v->type == EV_KEY && v->value == 0 && dev->debounce_key == -1) {
+ input_start_debounce(dev, v->code);
+ v->code = -2;
+ }
+ if (v->type == EV_KEY && v->value == 1 && dev->debounce_key == v->code)
+ input_stop_debounce(dev);
+ }
+
if (handler->filter) {
for (v = vals; v != vals + count; v++) {
if (handler->filter(handle, v->type, v->code, v->value))
@@ -117,8 +147,9 @@ static unsigned int input_to_handler(struct input_handle *handle,
if (handler->events)
handler->events(handle, vals, count);
else if (handler->event)
- for (v = vals; v != vals + count; v++)
+ for (v = vals; v != vals + count; v++) {
handler->event(handle, v->type, v->code, v->value);
+ }
return count;
}
@@ -141,11 +172,11 @@ static void input_pass_values(struct input_dev *dev,
handle = rcu_dereference(dev->grab);
if (handle) {
- count = input_to_handler(handle, vals, count);
+ count = input_to_handler(dev, handle, vals, count);
} else {
list_for_each_entry_rcu(handle, &dev->h_list, d_node)
if (handle->open) {
- count = input_to_handler(handle, vals, count);
+ count = input_to_handler(dev, handle, vals, count);
if (!count)
break;
}
@@ -203,6 +234,27 @@ static void input_repeat_key(struct timer_list *t)
spin_unlock_irqrestore(&dev->event_lock, flags);
}
+/*
+ * Generate software autorepeat event. Note that we take
+ * dev->event_lock here to avoid racing with input_event
+ * which may cause keys get "stuck".
+ */
+static void input_debounce_key(struct timer_list *t)
+{
+ struct input_dev *dev = from_timer(dev, t, timer);
+ unsigned long flags;
+
+ struct input_value vals[] = {
+ { EV_KEY, dev->debounce_key, 0 },
+ input_value_sync
+ };
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+ input_pass_values(dev, vals, ARRAY_SIZE(vals));
+ input_stop_debounce(dev);
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+}
+
#define INPUT_IGNORE_EVENT 0
#define INPUT_PASS_TO_HANDLERS 1
#define INPUT_PASS_TO_DEVICE 2
@@ -2109,6 +2161,8 @@ int input_register_device(struct input_dev *dev)
/* Every input device generates EV_SYN/SYN_REPORT events. */
__set_bit(EV_SYN, dev->evbit);
+ dev->debounce_key = -1;
+
/* KEY_RESERVED is not supposed to be transmitted to userspace. */
__clear_bit(KEY_RESERVED, dev->keybit);
diff --git a/include/linux/input.h b/include/linux/input.h
index 7c7516e..b2458b2 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -150,6 +150,7 @@ struct input_dev {
struct ff_device *ff;
+ int debounce_key;
unsigned int repeat_key;
struct timer_list timer;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Dmitry Torokhov @ 2018-12-15 0:19 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, jikos, Vojtech Pavlik, linux-input@vger.kernel.org
In-Reply-To: <20181214232437.GA8310@amd>
Hi Pavel,
On Fri, Dec 14, 2018 at 3:24 PM Pavel Machek <pavel@ucw.cz> wrote:
>
>
> I believe I have hardware problem, but I'm kind of hoping software
> could help me...?
>
> Mouse wheel on my machine started glitching on my machine, generating
> double-clicks when I click it once. Which unfortunately is quite
> annoying: texts are pasted twice, two tabs are closed instead of one,
> ....
>
> Event: time 1544733054.903129, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733054.903129, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1544733054.903129, -------------- EV_SYN ------------
> 1544733054.967251, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733054.967251, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1544733054.967251, -------------- EV_SYN ------------
> Event: time 1544733054.975144, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733054.975144, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1544733054.975144, -------------- EV_SYN ------------
> : time 1544733065.127190, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733065.127190, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1544733065.127190, -------------- EV_SYN ------------
>
> Now, I could just buy a new mouse, but it seems that most optical mice
> die like this... so maybe it would be nice to have an option to
> debounce the buttons, so that the useful life of mice is extended a
> bit?
>
> (So... I have two mice with that fault -- cheap to replace, but button
> in thinkpad X220 started doing that, too. That one will not be so
> cheap to fix :-( ).
>
> It is possible that some X versions already do something like this.
>
> Patch is obviously not ready; but:
>
> a) would it be useful to people
>
> b) would it be acceptable if done properly? (cmd line option to
> enable, avoiding duplicate/wrong events?)
I'd say if you are attached to failing hardware, solve it in
userspace. Have a utility/daemon that you run (from udev?) that:
- "grabs" input device with EVIOCGRAB
- does the debouncing/filtering/adjusting for the dirty sensor
- reinject events back into kernel with /dev/uinput
It will add some latency, but should be workable.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Vojtech Pavlik @ 2018-12-15 8:55 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181214232437.GA8310@amd>
On Sat, Dec 15, 2018 at 12:24:37AM +0100, Pavel Machek wrote:
> Patch is obviously not ready; but:
>
> a) would it be useful to people
Probably not.
Mice already do internal software/hardware debouncing on switches. If you
see duplicate clicks making it all the way to the kernel driver, something
is very wrong with the switch, to the point where it'll soon fail
completely.
Hence the value of doing extra processing in the kernel is very limited.
> b) would it be acceptable if done properly? (cmd line option to
> enable, avoiding duplicate/wrong events?)
Well, for one, you shouldn't be using a timer, all the debouncing can be
done by math on the event timestamps.
You'd also have a hard time distinguishing between doubleclicks and bounces.
Since the mice already filter the quick bounces and there is significant
delay (100ms on USB, similar on PS/2) between updates from the hardware, a
real doubleclick can look absolutely the same as what you observe as a
bounce.
As such, it couldn't be enabled by default.
If you really want to go this way, a userspace solution is the better choice.
--
Vojtech Pavlik
^ permalink raw reply
* [PATCH v5] Input: i8042 add i8042_is_mr_coffee() helper to avoid refconut leak
From: Yangtao Li @ 2018-12-15 9:08 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: tiny.windzz, linux-input, linux-kernel
of_find_node_by_path() acquires a reference to the node returned by
it and that reference needs to be dropped by its caller. Add
i8042_is_mr_coffee() helper to avoid refconut leak.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
---
changes in v5:
-fix typo
changes in v4:
-fix typo
changes in v3:
-add i8042_is_mr_coffee
---
drivers/input/serio/i8042-sparcio.h | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/i8042-sparcio.h b/drivers/input/serio/i8042-sparcio.h
index 796289846204..9e9e512bc432 100644
--- a/drivers/input/serio/i8042-sparcio.h
+++ b/drivers/input/serio/i8042-sparcio.h
@@ -106,11 +106,23 @@ static struct platform_driver sparc_i8042_driver = {
.remove = sparc_i8042_remove,
};
+static inline bool i8042_is_mr_coffee(void)
+{
+ struct device_node *root;
+ bool is_mr_coffee;
+
+ root = of_find_node_by_path("/");
+ is_mr_coffee = !strcmp(root->name, "SUNW,JavaStation-1");
+ of_node_put(root);
+
+ return is_mr_coffee;
+}
+
static int __init i8042_platform_init(void)
{
- struct device_node *root = of_find_node_by_path("/");
+ bool match = i8042_is_mr_coffee();
- if (!strcmp(root->name, "SUNW,JavaStation-1")) {
+ if (match) {
/* Hardcoded values for MrCoffee. */
i8042_kbd_irq = i8042_aux_irq = 13 | 0x20;
kbd_iobase = ioremap(0x71300060, 8);
@@ -138,9 +150,9 @@ static int __init i8042_platform_init(void)
static inline void i8042_platform_exit(void)
{
- struct device_node *root = of_find_node_by_path("/");
+ bool match = i8042_is_mr_coffee();
- if (strcmp(root->name, "SUNW,JavaStation-1"))
+ if (!match)
platform_driver_unregister(&sparc_i8042_driver);
}
--
2.17.0
^ permalink raw reply related
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Pavel Machek @ 2018-12-15 9:47 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181215085510.GB12930@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
Hi!
> > Patch is obviously not ready; but:
> >
> > a) would it be useful to people
>
> Probably not.
>
> Mice already do internal software/hardware debouncing on switches. If you
> see duplicate clicks making it all the way to the kernel driver, something
> is very wrong with the switch, to the point where it'll soon fail
> completely.
It seems mice normally survive 2 years under my use. This one has left
button repaired and middle button failing... If debouncing gives it
one more year, it will be success...
> > b) would it be acceptable if done properly? (cmd line option to
> > enable, avoiding duplicate/wrong events?)
>
> Well, for one, you shouldn't be using a timer, all the debouncing can be
> done by math on the event timestamps.
Not... really, right? You need to send an release some time after
button indicates release if bounce did not happen. It is similar to
autorepeat needing a timer.
Let me gain some experience with the patch. I don't think hardware
does as heavy debouncing as you describe.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ 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