* [PATCH V2 1/2] Input: rotary_encoder - Support key events
From: Donghoon Han @ 2019-01-07 16:42 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Daniel Mack, linux-kernel, Steven Han
In-Reply-To: <20190107164249.2342-1-nazgul33@gmail.com>
From: Steven Han <nazgul33@gmail.com>
Support generating EV_KEY pair, instead of EV_REL.
Signed-off-by: Donghoon Han <nazgul33@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Daniel Mack <daniel@caiaq.de>
To: linux-input@vger.kernel.org
---
V2: added missing input_sync()
---
drivers/input/misc/rotary_encoder.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 72eee6d55527..0014a7d9f8f9 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -41,6 +41,8 @@ struct rotary_encoder {
u32 steps;
u32 axis;
bool relative_axis;
+ bool relative_keys;
+ u32 keycodes[2];
bool rollover;
enum rotary_encoder_encoding encoding;
@@ -79,6 +81,11 @@ static void rotary_encoder_report_event(struct rotary_encoder *encoder)
if (encoder->relative_axis) {
input_report_rel(encoder->input,
encoder->axis, encoder->dir);
+ } else if (encoder->relative_keys) {
+ u32 keycode = encoder->keycodes[encoder->dir > 0];
+ input_event(encoder->input, EV_KEY, keycode, 1);
+ input_sync(encoder->input);
+ input_event(encoder->input, EV_KEY, keycode, 0);
} else {
unsigned int pos = encoder->pos;
@@ -237,6 +244,16 @@ static int rotary_encoder_probe(struct platform_device *pdev)
device_property_read_u32(dev, "linux,axis", &encoder->axis);
encoder->relative_axis =
device_property_read_bool(dev, "rotary-encoder,relative-axis");
+ encoder->relative_keys =
+ device_property_read_bool(dev, "rotary-encoder,relative-keys");
+ if (encoder->relative_keys) {
+ err = device_property_read_u32_array(dev,
+ "rotary-encoder,relative-keycodes",
+ encoder->keycodes, 2);
+ if (err)
+ dev_err(dev, "unable to get keycodes: %d\n", err);
+ return err;
+ }
encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
if (IS_ERR(encoder->gpios)) {
@@ -260,9 +277,12 @@ static int rotary_encoder_probe(struct platform_device *pdev)
input->id.bustype = BUS_HOST;
input->dev.parent = dev;
- if (encoder->relative_axis)
+ if (encoder->relative_axis) {
input_set_capability(input, EV_REL, encoder->axis);
- else
+ } else if (encoder->relative_keys) {
+ input_set_capability(input, EV_KEY, encoder->keycodes[0]);
+ input_set_capability(input, EV_KEY, encoder->keycodes[1]);
+ } else
input_set_abs_params(input,
encoder->axis, 0, encoder->steps, 0, 1);
--
2.17.1
^ permalink raw reply related
* [PATCH V2 0/2] input: rotary-encoder: Support key events
From: Donghoon Han @ 2019-01-07 16:42 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Daniel Mack, linux-kernel
This patchset supports generating EV_KEY, instead of EV_REL.
An example could be a volume knob, with key events:
- KEY_VOLUMEDOWN / KEY_VOLUMEUP
[tested on imx6q platform, full period, half period]
Donghoon Han (2):
Input: rotary_encoder - Support key events
Input: rotaty-encoder - Add DT binding document
Documentation/devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
drivers/input/misc/rotary_encoder.c | 24 ++++++++++++++++++++++--
2 files changed, 34 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] Input: goodix - decouple irq and reset lines
From: Gonzalez, Alex @ 2019-01-07 16:42 UTC (permalink / raw)
To: Bastien Nocera
Cc: Dmitry Torokhov, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <6b8f757eb52eb74d9dc2c3bedbfec798a58c0ec2.camel@hadess.net>
Hi Bastien,
>Given that we do have access to the datasheet, it would also be useful
>for the patch to mention where in the datasheet it says that the reset
>line can be left pulled-up,
The pin description table on section 4, on the "Reset pin" row, contains a
remark as follows:
External 10K pull-up resistor required, active-low reset
This comes from a newer revision of the datasheet though:
http://focuslcds.com/content/GT911.pdf
I guess it's open to interpretation whether driving the reset line is
optional. The code seemed to imply it by using devm_gpiod_get_optional() to
obtain the GPIO.
>or mention on which shipping device this
>setup is already used (and if so, what the DTS or ACPI snippet that
>declares those is).
>
I am testing with an LCD application kit for the ConnectCore 6UL SBC Pro:
https://www.digi.com/products/models/cc-acc-lcdw-10
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts?h=v5.0-rc1#n120
This display in particular does not have the reset line available on the
connector. The only way to make it work seems to be to use the INT line to fix
an I2C address.
>Cheers
>
^ permalink raw reply
* Re: [PATCH] Input: goodix - decouple irq and reset lines
From: Bastien Nocera @ 2019-01-07 16:01 UTC (permalink / raw)
To: Dmitry Torokhov, Alex Gonzalez; +Cc: linux-input, linux-kernel
In-Reply-To: <6b8f757eb52eb74d9dc2c3bedbfec798a58c0ec2.camel@hadess.net>
On Mon, 2019-01-07 at 16:56 +0100, Bastien Nocera wrote:
> Given that we do have access to the datasheet, it would also be
> useful
> for the patch to mention where in the datasheet it says that the
> reset
> line can be left pulled-up, or mention on which shipping device this
> setup is already used (and if so, what the DTS or ACPI snippet that
> declares those is).
Or alternatively, and as Andreas pointed out in another thread, find
the code in the vendor driver that does support this setup:
https://github.com/goodix/gt9xx_driver_android
https://github.com/goodix/goodix_gt9xx_public
If it doesn't work with the vendor code, then we might not want to make
it work with our driver either.
Cheers
^ permalink raw reply
* Re: [PATCH] Input: goodix - decouple irq and reset lines
From: Bastien Nocera @ 2019-01-07 15:56 UTC (permalink / raw)
To: Dmitry Torokhov, Alex Gonzalez; +Cc: linux-input, linux-kernel
In-Reply-To: <20190105225147.le5fgpnvq7sctxe5@penguin>
On Sat, 2019-01-05 at 22:51 +0000, Dmitry Torokhov wrote:
> Hi Alex,
>
> On Fri, Jan 04, 2019 at 05:00:48PM +0100, Alex Gonzalez wrote:
> > The Goodix touch controller allows the use of two optional GPIOs
> > (RESET
> > and INT) to reset the touch controller, select the I2C address of
> > the
> > device and exit the device from sleep mode.
> >
> > The current implementation requires both GPIOs to be provided,
> > however,
> > it is possible to provide only the INT line and not to have the
> > RESET line
> > available but pulled-up.
> >
> > Designs that only provide the INT line are able to operate the
> > touch on
> > the default I2C address but will not be able to reset the touch via
> > software or place the device in sleep mode.
>
> I do not have a datasheet for the device, so I am not sure if reset
> line
Data sheets for a lot of the Goodix devices were shared a couple of
years ago on this list. You'll find the one for the GT911 in here:
https://drive.google.com/drive/folders/0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg?usp=sharing
You can probably translate it using Google Translate's Documents
upload, but I haven't had much luck at all...
> is actually needed to put the device into sleep mode. As far as I can
> see from the code we suspend it by pulsing INT line and then sending
> a
> command to the controller, and resuming by pulsing the INT line
> again.
> So it sounds to me INT only designs _could_ place device in sleep
> mode.
>
> As far as the patch goes, if you do not need to execute reset or put
> device into low power mode, you do not need to specify any of the
> GPIOs
> as GPIO resources. Simply specify the INT GPIO as your interrupt
> source
> (GpioInt() in ACPI world or "interrupts = <&gpio NNN
> IRQF_TRIGGER_WHATEVER>" in DT world and be done with it.
Given that we do have access to the datasheet, it would also be useful
for the patch to mention where in the datasheet it says that the reset
line can be left pulled-up, or mention on which shipping device this
setup is already used (and if so, what the DTS or ACPI snippet that
declares those is).
Cheers
^ permalink raw reply
* Re: [PATCH] Input: goodix - decouple irq and reset lines
From: Gonzalez, Alex @ 2019-01-07 10:13 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: hadess@hadess.net, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190105225147.le5fgpnvq7sctxe5@penguin>
Hi Dmitry,
Thanks for your quick reply.
>
>I do not have a datasheet for the device, so I am not sure if reset line
>is actually needed to put the device into sleep mode. As far as I can
>see from the code we suspend it by pulsing INT line and then sending a
>command to the controller, and resuming by pulsing the INT line again.
>So it sounds to me INT only designs _could_ place device in sleep mode.
>
The way I read the gt911 dataheet I also understand that only the INT line is
required to enter sleep mode but I don't other for the other supported
controllers. My comment is based on both the suspend() and resume() functions
returning in the absence of either gpiod_int or gpiod_rst and not progressing
to the sleep sequence.
>As far as the patch goes, if you do not need to execute reset or put
>device into low power mode, you do not need to specify any of the GPIOs
>as GPIO resources. Simply specify the INT GPIO as your interrupt source
>(GpioInt() in ACPI world or "interrupts = <&gpio NNN
>IRQF_TRIGGER_WHATEVER>" in DT world and be done with it.
>
That was my first impression too. However this does not work for my device. My
hypothesis is that the touch controller I2C address setting sequence is not
happening as it should, so I need at least the control of the INT line in
order to fix the I2C address.
I am unsure though whether this is a problem specific to the design I am
testing with or all designs will have problems setting the I2C address without
controlling the INT GPIO line.
Regards,
Alex
>Thanks.
>
>--
>Dmitry
^ permalink raw reply
* Re: [PATCH] Elantech Touchpad: Fix Elantech touchpad and trackpoint for Lenovo ThinkPad notebooks.
From: Benjamin Tissoires @ 2019-01-07 8:05 UTC (permalink / raw)
To: Kai Heng Feng
Cc: Philipp Kaelin, Dmitry Torokhov, open list:HID CORE LAYER, lkml
In-Reply-To: <F09EA46C-73C3-48A8-9105-F4DE55D7FBB6@canonical.com>
Hi Kai-Heng,
On Sun, Jan 6, 2019 at 10:44 AM Kai Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
> Hi Benjamin,
>
> > On Dec 29, 2018, at 1:53 AM, Philipp Kaelin <kaelinphilipp@gmail.com> wrote:
> >
> > Initial situation:
> > - The touchpad of a Lenovo ThinkPad L580 doesn't work with newer kernel versions eg. 4.20
> > - It used to work on earlier versions eg. 4.14
> >
> > Cause:
> > - The elantech driver was adapted in to support SMBus wich not all firmware versions
> > of the elantech firmware support. The SMBus is used as default.
> >
> > Solution:
> > - Previously a blacklist was introduced for devices which doesn't support the access using SMBus.
> > The ThinkPad P52 and P72 have already been fixed by adding it to such a blacklist in a prevois patch.
> > The exact same solution fixed also the issue on the mentioned ThinkPad L580.
> >
> > Change:
> > 1) The firmware id of the ThinkPad L580 was added to this blacklist.
> > 2) To not have a half baked solution the information which firmware versions are using the same driver
> > and therefore most probably have all the same issue was extracted from the Lenovo Windows driver package.
> > All these firmware versions are now also added to the blacklist.
>
> I actually have a reversed situation:
> I’d like to make Elantech touchpad defaults to SMBus on some platforms, but the firmware version does not match to ETP_NEW_IC_SMBUS_HOST_NOTIFY().
>
> Use whitelist is obviously a bad idea so I’d like to know do you have any better approach in mind?
TL;DR: I think there is no other solution than using a whitelist.
Well, that's not entirely true. There is a bit in the old touchpads
that says if it can be used by an other bus (I2C, SMBus or something
else). But the problem is that those touchpads have been around for a
quite a long time, and blindly switching them to SMBus would likely
introduce regressions on old hardware we don't want to support
anymore.
I chose to only enable the new ones because I thought it would prevent
me for having to deal with many issues, and you can see the result. At
least, all of those machines are from the latest generation (or
previous generation) so it doesn't seem to be a bad idea to try to fix
them.
So I'd say for the old touchpads that do not have
ETP_NEW_IC_SMBUS_HOST_NOTIFY(), we should likely stick with a well
defined whitelist so we can control the damages.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] Elantech Touchpad: Fix Elantech touchpad and trackpoint for Lenovo ThinkPad notebooks.
From: Benjamin Tissoires @ 2019-01-07 7:58 UTC (permalink / raw)
To: Philipp Kaelin; +Cc: Dmitry Torokhov, linux-input, linux-kernel
In-Reply-To: <20181228175327.14863-1-kaelinphilipp@gmail.com>
Hi Philipp,
On Sat, Dec 29, 2018 at 6:35 AM Philipp Kaelin <kaelinphilipp@gmail.com> wrote:
>
> Initial situation:
> - The touchpad of a Lenovo ThinkPad L580 doesn't work with newer kernel versions eg. 4.20
> - It used to work on earlier versions eg. 4.14
>
> Cause:
> - The elantech driver was adapted in to support SMBus wich not all firmware versions
> of the elantech firmware support. The SMBus is used as default.
>
> Solution:
> - Previously a blacklist was introduced for devices which doesn't support the access using SMBus.
> The ThinkPad P52 and P72 have already been fixed by adding it to such a blacklist in a prevois patch.
nitpick: you are using "prevois" instead of "previous" :)
> The exact same solution fixed also the issue on the mentioned ThinkPad L580.
>
> Change:
> 1) The firmware id of the ThinkPad L580 was added to this blacklist.
> 2) To not have a half baked solution the information which firmware versions are using the same driver
> and therefore most probably have all the same issue was extracted from the Lenovo Windows driver package.
> All these firmware versions are now also added to the blacklist.
>
> Risk assesment:
> As in prevois versions of the kernel eg. 4.14 none of the devices used to be accessed via SMBus
> (and they are reported to work at this time) it's quite safe that this blaklisting doesn't cause
> any harm on devices which have not been testes but included in the blacklist.
>
> Signed-off-by: Philipp Kaelin <kaelinphilipp@gmail.com>
> ---
> drivers/input/mouse/elantech.c | 23 +++++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 9fe075c137dc..e5fa8cfd8393 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1772,10 +1772,25 @@ static const char * const i2c_blacklist_pnp_ids[] = {
> * These are known to not be working properly as bits are missing
> * in elan_i2c.
> */
> - "LEN2131", /* ThinkPad P52 w/ NFC */
> - "LEN2132", /* ThinkPad P52 */
> - "LEN2133", /* ThinkPad P72 w/ NFC */
> - "LEN2134", /* ThinkPad P72 */
> + "LEN2131", /* Walter-3 w/ NFC ThinkPad P52 w/ NFC */
> + "LEN2132", /* Walter-3 w/o/ NFC ThinkPad P52 */
> + "LEN2133", /* Chiron w/ NFC ThinkPad P72 w/ NFC */
> + "LEN2134", /* Chiron w/o/ NFC ThinkPad P72 */
> + "LEN2037", /* Lando w/ NFC ThinkPad L580 w/ NFC */
> + "LEN2038", /* Lando w/o/ NFC ThinkPad L580 */
> + "LEN004F", /* Storm w/o/ NFC */
> + "LEN005C", /* Storm w/ NFC */
> + "LEN2030", /* Carling */
> + "LEN2031", /* Bell */
> + "LEN2032", /* Bell-2 */
> + "LEN2033", /* Storm-2 */
> + "LEN2034", /* Storm-3 */
> + "LEN2035", /* Solo w/ NFC */
> + "LEN2036", /* Solo w/o/ NFC */
> + "LEN2039", /* Leia */
> + "LEN2130", /* Kylo (Clamshell) */
> + "LEN008F", /* Kolar w/o/ NF */
> + "LEN0090", /* Kolar w/ NFC */
That is quite a list. My initial idea with this blacklist was to keep
it short and fix the initial issue to be able to remove it entirely
(or at least on the devices we can test).
So 2 questions:
- do you have the commercial names of the various PNPId you are adding?
- are you able to test all of those? Especially if we get the SMBus
driver fixed?
I am fine adding the patch as a fix for 4.21 and backport this to
stable, but I still intend to fix elan_i2c for the next cycle (4.22)
so I'd like to know if we can safely test those machine later on.
Cheers,
Benjamin
> NULL
> };
>
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH v2] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
From: kbuild test robot @ 2019-01-07 7:31 UTC (permalink / raw)
Cc: kbuild-all, jikos, benjamin.tissoires, linux-input, linux-kernel,
Kai-Heng Feng
In-Reply-To: <20190107062656.3065-1-kai.heng.feng@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 5126 bytes --]
Hi Kai-Heng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Kai-Heng-Feng/HID-i2c-hid-Ignore-input-report-if-there-s-no-data-present-on-Elan-touchpanels/20190107-142834
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/hid/i2c-hid/i2c-hid-core.c: In function 'i2c_hid_get_input':
drivers/hid/i2c-hid/i2c-hid-core.c:510:37: warning: missing terminating " character
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^
drivers/hid/i2c-hid/i2c-hid-core.c:511:15: warning: missing terminating ' character
there's no data\n", __func__);
^
drivers/hid/i2c-hid/i2c-hid-core.c:1359: error: unterminated argument list invoking macro "dev_warn_once"
MODULE_LICENSE("GPL");
>> drivers/hid/i2c-hid/i2c-hid-core.c:510:3: error: 'dev_warn_once' undeclared (first use in this function); did you mean 'dev_fwnode'?
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^~~~~~~~~~~~~
dev_fwnode
drivers/hid/i2c-hid/i2c-hid-core.c:510:3: note: each undeclared identifier is reported only once for each function it appears in
drivers/hid/i2c-hid/i2c-hid-core.c:510:16: error: expected ';' at end of input
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^
;
drivers/hid/i2c-hid/i2c-hid-core.c:1359:
MODULE_LICENSE("GPL");
drivers/hid/i2c-hid/i2c-hid-core.c:510:3: error: expected declaration or statement at end of input
dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
^~~~~~~~~~~~~
drivers/hid/i2c-hid/i2c-hid-core.c:510:3: error: expected declaration or statement at end of input
At top level:
drivers/hid/i2c-hid/i2c-hid-core.c:481:13: warning: 'i2c_hid_get_input' defined but not used [-Wunused-function]
static void i2c_hid_get_input(struct i2c_hid *ihid)
^~~~~~~~~~~~~~~~~
drivers/hid/i2c-hid/i2c-hid-core.c:441:12: warning: 'i2c_hid_hwreset' defined but not used [-Wunused-function]
static int i2c_hid_hwreset(struct i2c_client *client)
^~~~~~~~~~~~~~~
drivers/hid/i2c-hid/i2c-hid-core.c:330:12: warning: 'i2c_hid_set_or_send_report' defined but not used [-Wunused-function]
static int i2c_hid_set_or_send_report(struct i2c_client *client, u8 reportType,
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hid/i2c-hid/i2c-hid-core.c:291:12: warning: 'i2c_hid_get_report' defined but not used [-Wunused-function]
static int i2c_hid_get_report(struct i2c_client *client, u8 reportType,
^~~~~~~~~~~~~~~~~~
drivers/hid/i2c-hid/i2c-hid-core.c:195:12: warning: 'i2c_hid_lookup_quirk' defined but not used [-Wunused-function]
static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16 idProduct)
^~~~~~~~~~~~~~~~~~~~
vim +510 drivers/hid/i2c-hid/i2c-hid-core.c
480
481 static void i2c_hid_get_input(struct i2c_hid *ihid)
482 {
483 int ret;
484 u32 ret_size;
485 int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
486
487 if (size > ihid->bufsize)
488 size = ihid->bufsize;
489
490 ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
491 if (ret != size) {
492 if (ret < 0)
493 return;
494
495 dev_err(&ihid->client->dev, "%s: got %d data instead of %d\n",
496 __func__, ret, size);
497 return;
498 }
499
500 ret_size = ihid->inbuf[0] | ihid->inbuf[1] << 8;
501
502 if (!ret_size) {
503 /* host or device initiated RESET completed */
504 if (test_and_clear_bit(I2C_HID_RESET_PENDING, &ihid->flags))
505 wake_up(&ihid->wait);
506 return;
507 }
508
509 if (ihid->quirks & I2C_HID_QUIRK_BOGUS_IRQ && ret_size == 0xffff) {
> 510 dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but
511 there's no data\n", __func__);
512 return;
513 }
514
515 if ((ret_size > size) || (ret_size < 2)) {
516 dev_err(&ihid->client->dev, "%s: incomplete report (%d/%d)\n",
517 __func__, size, ret_size);
518 return;
519 }
520
521 i2c_hid_dbg(ihid, "input: %*ph\n", ret_size, ihid->inbuf);
522
523 if (test_bit(I2C_HID_STARTED, &ihid->flags))
524 hid_input_report(ihid->hid, HID_INPUT_REPORT, ihid->inbuf + 2,
525 ret_size - 2, 1);
526
527 return;
528 }
529
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56239 bytes --]
^ permalink raw reply
* [PATCH v3] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
From: Kai-Heng Feng @ 2019-01-07 7:24 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>
---
v3:
Fix compiler error/warnings.
v2:
Use dev_warn_once() to warn the user about the situation.
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..2f940c1de616 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_warn_once(&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 v2] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
From: Kai-Heng Feng @ 2019-01-07 6:26 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>
---
v2:
Use dev_warn_once() to warn the user about the situation.
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..fd3b0ddace27 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_warn_once(&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
* Re: [PATCH 1/2] Input: rotary_encoder - Support key events
From: Dmitry Torokhov @ 2019-01-07 0:38 UTC (permalink / raw)
To: nazgul33; +Cc: linux-input@vger.kernel.org, Daniel Mack, lkml
In-Reply-To: <CAEo1Rizj_HC5f+TWMP8ogrsXVhMDrxA+Nyo2h4KJJ4admtmanQ@mail.gmail.com>
On Sat, Jan 5, 2019 at 9:36 PM nazgul33 <nazgul33@gmail.com> wrote:
>
> input_sync() is there, at the end of the function.
I know. Nonetheless, you need another one between sending distinct key
events. Userspace is allowed to accumulate device state until
EV_SYN/SYN_REPORT is received, which can result in your key events
being a noop.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] [v2] Input: touchscreen: Fix a missing check on regmap_bulk_read
From: Aditya Pakki @ 2019-01-06 18:17 UTC (permalink / raw)
To: pakki001
Cc: kjlu, Michael Hennerich, Dmitry Torokhov, linux-input,
linux-kernel
regmap_bulk_read() can return a non zero value on failure. The fix
checks if the function call succeeded before calling mod_timer. The
issue was identified by a static analysis tool.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
---
drivers/input/touchscreen/ad7879.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/ad7879.c b/drivers/input/touchscreen/ad7879.c
index 6fa714c587b4..8c908572c1f2 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -246,11 +246,14 @@ static void ad7879_timer(struct timer_list *t)
static irqreturn_t ad7879_irq(int irq, void *handle)
{
struct ad7879 *ts = handle;
+ int error;
- regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
- ts->conversion_data, AD7879_NR_SENSE);
-
- if (!ad7879_report(ts))
+ error = regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
+ ts->conversion_data, AD7879_NR_SENSE);
+ if (error)
+ dev_err_ratelimited(ts->dev, "failed to read %#02x: %d\n",
+ AD7879_REG_XPLUS, error);
+ else if (!ad7879_report(ts))
mod_timer(&ts->timer, jiffies + TS_PEN_UP_TIMEOUT);
return IRQ_HANDLED;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 0/4] input: touchscreen: Add goodix GT5553 CTP support
From: Jagan Teki @ 2019-01-06 16:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
On Sat, Dec 15, 2018 at 8:48 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> This patchset support goodix GT5553 CTP.
>
> Changes for v3:
> - add cover-letter
> - s/ADVV28/AVDD28 on commit head
> - fix few typo
> Changes for v2:
> - Rename vcc-supply with AVDD28-supply
> - disable regulator in remove
> - fix to setup regulator in probe code
> - add chipdata
> - drop example node in dt-bindings
Any comments?
^ permalink raw reply
* Re: [PATCH] keyboard/mtk-pmic-keys.c: Remove duplicate header
From: Souptick Joarder @ 2019-01-06 12:02 UTC (permalink / raw)
To: Brajeswar Ghosh
Cc: lee.jones, dmitry.torokhov, linux-kernel, linux-mediatek,
linux-input, Matthias Brugger, chen.zhong, linux-arm-kernel
In-Reply-To: <20190105050907.GA2525@hp-pavilion-15-notebook-pc-brajeswar>
On Sat, Jan 5, 2019 at 10:39 AM Brajeswar Ghosh
<brajeswar.linux@gmail.com> wrote:
>
> Remove linux/kernel.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh <brajeswar.linux@gmail.com>
Acked-by: Souptick Joarder <jrdr.linux@gmail.com>
> ---
> drivers/input/keyboard/mtk-pmic-keys.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index 02c67a1749fc..5027ebb7b4e8 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
> @@ -19,7 +19,6 @@
> #include <linux/input.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> -#include <linux/kernel.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/regmap.h>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] Elantech Touchpad: Fix Elantech touchpad and trackpoint for Lenovo ThinkPad notebooks.
From: Kai Heng Feng @ 2019-01-06 9:44 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Philipp Kaelin, Dmitry Torokhov, open list:HID CORE LAYER, lkml
In-Reply-To: <20181228175327.14863-1-kaelinphilipp@gmail.com>
Hi Benjamin,
> On Dec 29, 2018, at 1:53 AM, Philipp Kaelin <kaelinphilipp@gmail.com> wrote:
>
> Initial situation:
> - The touchpad of a Lenovo ThinkPad L580 doesn't work with newer kernel versions eg. 4.20
> - It used to work on earlier versions eg. 4.14
>
> Cause:
> - The elantech driver was adapted in to support SMBus wich not all firmware versions
> of the elantech firmware support. The SMBus is used as default.
>
> Solution:
> - Previously a blacklist was introduced for devices which doesn't support the access using SMBus.
> The ThinkPad P52 and P72 have already been fixed by adding it to such a blacklist in a prevois patch.
> The exact same solution fixed also the issue on the mentioned ThinkPad L580.
>
> Change:
> 1) The firmware id of the ThinkPad L580 was added to this blacklist.
> 2) To not have a half baked solution the information which firmware versions are using the same driver
> and therefore most probably have all the same issue was extracted from the Lenovo Windows driver package.
> All these firmware versions are now also added to the blacklist.
I actually have a reversed situation:
I’d like to make Elantech touchpad defaults to SMBus on some platforms, but the firmware version does not match to ETP_NEW_IC_SMBUS_HOST_NOTIFY().
Use whitelist is obviously a bad idea so I’d like to know do you have any better approach in mind?
Kai-Heng
>
> Risk assesment:
> As in prevois versions of the kernel eg. 4.14 none of the devices used to be accessed via SMBus
> (and they are reported to work at this time) it's quite safe that this blaklisting doesn't cause
> any harm on devices which have not been testes but included in the blacklist.
>
> Signed-off-by: Philipp Kaelin <kaelinphilipp@gmail.com>
> ---
> drivers/input/mouse/elantech.c | 23 +++++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 9fe075c137dc..e5fa8cfd8393 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1772,10 +1772,25 @@ static const char * const i2c_blacklist_pnp_ids[] = {
> * These are known to not be working properly as bits are missing
> * in elan_i2c.
> */
> - "LEN2131", /* ThinkPad P52 w/ NFC */
> - "LEN2132", /* ThinkPad P52 */
> - "LEN2133", /* ThinkPad P72 w/ NFC */
> - "LEN2134", /* ThinkPad P72 */
> + "LEN2131", /* Walter-3 w/ NFC ThinkPad P52 w/ NFC */
> + "LEN2132", /* Walter-3 w/o/ NFC ThinkPad P52 */
> + "LEN2133", /* Chiron w/ NFC ThinkPad P72 w/ NFC */
> + "LEN2134", /* Chiron w/o/ NFC ThinkPad P72 */
> + "LEN2037", /* Lando w/ NFC ThinkPad L580 w/ NFC */
> + "LEN2038", /* Lando w/o/ NFC ThinkPad L580 */
> + "LEN004F", /* Storm w/o/ NFC */
> + "LEN005C", /* Storm w/ NFC */
> + "LEN2030", /* Carling */
> + "LEN2031", /* Bell */
> + "LEN2032", /* Bell-2 */
> + "LEN2033", /* Storm-2 */
> + "LEN2034", /* Storm-3 */
> + "LEN2035", /* Solo w/ NFC */
> + "LEN2036", /* Solo w/o/ NFC */
> + "LEN2039", /* Leia */
> + "LEN2130", /* Kylo (Clamshell) */
> + "LEN008F", /* Kolar w/o/ NF */
> + "LEN0090", /* Kolar w/ NFC */
> NULL
> };
>
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH 2/2] Input: rotaty-encoder - Add DT binding document
From: nazgul33 @ 2019-01-06 3:41 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org, Daniel Mack, lkml
In-Reply-To: <CAKdAkRR80M4R4bWPu4smPD5=KPWanL+EFPvDUYLNrHaFQfApPw@mail.gmail.com>
Yes, it's needed.
Even with the same encoder, adjusting steps affects rate of event generation.
(the steps defines 1 cycle of encoder rotation, and 1 cycle = 1 key event.)
On Sun, Jan 6, 2019 at 8:11 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han <nazgul33@gmail.com> wrote:
> >
> > Add DT binding document for rotary-encoder, keycode options.
> >
> > Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> > ---
> > .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > index f99fe5cdeaec..113640079de3 100644
> > --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > @@ -12,6 +12,10 @@ Optional properties:
> > - rotary-encoder,relative-axis: register a relative axis rather than an
> > absolute one. Relative axis will only generate +1/-1 events on the input
> > device, hence no steps need to be passed.
> > +- rotary-encoder,relative-keys : generate pair of key events. This setting
> > + behaves just like relative-axis, generating key events. keycode[2]
> > + corresponds -1/1 events.
> > +- rotary-encoder,relative-keycodes : keycodes for relative-keys
> > - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
> > greater than the specified steps or smaller than 0. For absolute axis only.
> > - rotary-encoder,steps-per-period: Number of steps (stable states) per period.
> > @@ -48,3 +52,11 @@ Example:
> > rotary-encoder,encoding = "binary";
> > rotary-encoder,rollover;
> > };
> > +
> > + rotary@2 {
> > + compatible = "rotary-encoder";
> > + gpios = <&gpio 21 0>, <&gpio 22 0>;
> > + rotary-encoder,relative-keys;
> > + rotary-encoder,relative-keycode = <103>, <108>;
> > + rotary-encoder,steps-per-period = <2>;
>
> Do you need steps for keys? They weren't required for the relative axis mode.
>
> Thanks.
>
> --
> Dmitry
--
한동훈 드림.
^ permalink raw reply
* Re: [PATCH 1/2] Input: rotary_encoder - Support key events
From: nazgul33 @ 2019-01-06 3:36 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org, Daniel Mack, lkml
In-Reply-To: <CAKdAkRQKnH++VuL37EGBaFSMmFPvbpCkVkZLwuMU9eWo+KsaXA@mail.gmail.com>
input_sync() is there, at the end of the function.
static void rotary_encoder_report_event(struct rotary_encoder *encoder)
{
if (encoder->relative_axis) {
input_report_rel(encoder->input,
encoder->axis, encoder->dir);
} else if (encoder->relative_keys) {
u32 keycode = encoder->keycodes[encoder->dir > 0];
input_event(encoder->input, EV_KEY, keycode, 1);
input_event(encoder->input, EV_KEY, keycode, 0);
} else {
unsigned int pos = encoder->pos;
if (encoder->dir < 0) {
/* turning counter-clockwise */
if (encoder->rollover)
pos += encoder->steps;
if (pos)
pos--;
} else {
/* turning clockwise */
if (encoder->rollover || pos < encoder->steps)
pos++;
}
if (encoder->rollover)
pos %= encoder->steps;
encoder->pos = pos;
input_report_abs(encoder->input, encoder->axis, encoder->pos);
}
input_sync(encoder->input);
}
On Sun, Jan 6, 2019 at 8:12 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han <nazgul33@gmail.com> wrote:
> >
> > From: Steven Han <nazgul33@gmail.com>
> >
> > Support generating EV_KEY pair, instead of EV_REL.
> >
> > Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> > ---
> > drivers/input/misc/rotary_encoder.c | 23 +++++++++++++++++++++--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
> > index 72eee6d55527..180e35884289 100644
> > --- a/drivers/input/misc/rotary_encoder.c
> > +++ b/drivers/input/misc/rotary_encoder.c
> > @@ -41,6 +41,8 @@ struct rotary_encoder {
> > u32 steps;
> > u32 axis;
> > bool relative_axis;
> > + bool relative_keys;
> > + u32 keycodes[2];
> > bool rollover;
> > enum rotary_encoder_encoding encoding;
> >
> > @@ -79,6 +81,10 @@ static void rotary_encoder_report_event(struct rotary_encoder *encoder)
> > if (encoder->relative_axis) {
> > input_report_rel(encoder->input,
> > encoder->axis, encoder->dir);
> > + } else if (encoder->relative_keys) {
> > + u32 keycode = encoder->keycodes[encoder->dir > 0];
> > + input_event(encoder->input, EV_KEY, keycode, 1);
>
> You need input_sync() here.
>
> > + input_event(encoder->input, EV_KEY, keycode, 0);
> > } else {
> > unsigned int pos = encoder->pos;
> >
> > @@ -237,6 +243,16 @@ static int rotary_encoder_probe(struct platform_device *pdev)
> > device_property_read_u32(dev, "linux,axis", &encoder->axis);
> > encoder->relative_axis =
> > device_property_read_bool(dev, "rotary-encoder,relative-axis");
> > + encoder->relative_keys =
> > + device_property_read_bool(dev, "rotary-encoder,relative-keys");
> > + if (encoder->relative_keys) {
> > + err = device_property_read_u32_array(dev,
> > + "rotary-encoder,relative-keycodes",
> > + encoder->keycodes, 2);
> > + if (err)
> > + dev_err(dev, "unable to get keycodes: %d\n", err);
> > + return err;
> > + }
> >
> > encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
> > if (IS_ERR(encoder->gpios)) {
> > @@ -260,9 +276,12 @@ static int rotary_encoder_probe(struct platform_device *pdev)
> > input->id.bustype = BUS_HOST;
> > input->dev.parent = dev;
> >
> > - if (encoder->relative_axis)
> > + if (encoder->relative_axis) {
> > input_set_capability(input, EV_REL, encoder->axis);
> > - else
> > + } else if (encoder->relative_keys) {
> > + input_set_capability(input, EV_KEY, encoder->keycodes[0]);
> > + input_set_capability(input, EV_KEY, encoder->keycodes[1]);
> > + } else
> > input_set_abs_params(input,
> > encoder->axis, 0, encoder->steps, 0, 1);
> >
> > --
> > 2.17.1
> >
>
> Thanks.
>
> --
> Dmitry
--
한동훈 드림.
^ permalink raw reply
* Re: [PATCH 1/2] Input: rotary_encoder - Support key events
From: Dmitry Torokhov @ 2019-01-05 23:12 UTC (permalink / raw)
To: Donghoon Han; +Cc: linux-input@vger.kernel.org, Daniel Mack, lkml
In-Reply-To: <20190105202659.20198-2-nazgul33@gmail.com>
On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han <nazgul33@gmail.com> wrote:
>
> From: Steven Han <nazgul33@gmail.com>
>
> Support generating EV_KEY pair, instead of EV_REL.
>
> Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> ---
> drivers/input/misc/rotary_encoder.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
> index 72eee6d55527..180e35884289 100644
> --- a/drivers/input/misc/rotary_encoder.c
> +++ b/drivers/input/misc/rotary_encoder.c
> @@ -41,6 +41,8 @@ struct rotary_encoder {
> u32 steps;
> u32 axis;
> bool relative_axis;
> + bool relative_keys;
> + u32 keycodes[2];
> bool rollover;
> enum rotary_encoder_encoding encoding;
>
> @@ -79,6 +81,10 @@ static void rotary_encoder_report_event(struct rotary_encoder *encoder)
> if (encoder->relative_axis) {
> input_report_rel(encoder->input,
> encoder->axis, encoder->dir);
> + } else if (encoder->relative_keys) {
> + u32 keycode = encoder->keycodes[encoder->dir > 0];
> + input_event(encoder->input, EV_KEY, keycode, 1);
You need input_sync() here.
> + input_event(encoder->input, EV_KEY, keycode, 0);
> } else {
> unsigned int pos = encoder->pos;
>
> @@ -237,6 +243,16 @@ static int rotary_encoder_probe(struct platform_device *pdev)
> device_property_read_u32(dev, "linux,axis", &encoder->axis);
> encoder->relative_axis =
> device_property_read_bool(dev, "rotary-encoder,relative-axis");
> + encoder->relative_keys =
> + device_property_read_bool(dev, "rotary-encoder,relative-keys");
> + if (encoder->relative_keys) {
> + err = device_property_read_u32_array(dev,
> + "rotary-encoder,relative-keycodes",
> + encoder->keycodes, 2);
> + if (err)
> + dev_err(dev, "unable to get keycodes: %d\n", err);
> + return err;
> + }
>
> encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
> if (IS_ERR(encoder->gpios)) {
> @@ -260,9 +276,12 @@ static int rotary_encoder_probe(struct platform_device *pdev)
> input->id.bustype = BUS_HOST;
> input->dev.parent = dev;
>
> - if (encoder->relative_axis)
> + if (encoder->relative_axis) {
> input_set_capability(input, EV_REL, encoder->axis);
> - else
> + } else if (encoder->relative_keys) {
> + input_set_capability(input, EV_KEY, encoder->keycodes[0]);
> + input_set_capability(input, EV_KEY, encoder->keycodes[1]);
> + } else
> input_set_abs_params(input,
> encoder->axis, 0, encoder->steps, 0, 1);
>
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: rotaty-encoder - Add DT binding document
From: Dmitry Torokhov @ 2019-01-05 23:11 UTC (permalink / raw)
To: Donghoon Han; +Cc: linux-input@vger.kernel.org, Daniel Mack, lkml
In-Reply-To: <20190105202659.20198-3-nazgul33@gmail.com>
On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han <nazgul33@gmail.com> wrote:
>
> Add DT binding document for rotary-encoder, keycode options.
>
> Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> ---
> .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> index f99fe5cdeaec..113640079de3 100644
> --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> @@ -12,6 +12,10 @@ Optional properties:
> - rotary-encoder,relative-axis: register a relative axis rather than an
> absolute one. Relative axis will only generate +1/-1 events on the input
> device, hence no steps need to be passed.
> +- rotary-encoder,relative-keys : generate pair of key events. This setting
> + behaves just like relative-axis, generating key events. keycode[2]
> + corresponds -1/1 events.
> +- rotary-encoder,relative-keycodes : keycodes for relative-keys
> - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
> greater than the specified steps or smaller than 0. For absolute axis only.
> - rotary-encoder,steps-per-period: Number of steps (stable states) per period.
> @@ -48,3 +52,11 @@ Example:
> rotary-encoder,encoding = "binary";
> rotary-encoder,rollover;
> };
> +
> + rotary@2 {
> + compatible = "rotary-encoder";
> + gpios = <&gpio 21 0>, <&gpio 22 0>;
> + rotary-encoder,relative-keys;
> + rotary-encoder,relative-keycode = <103>, <108>;
> + rotary-encoder,steps-per-period = <2>;
Do you need steps for keys? They weren't required for the relative axis mode.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: goodix - decouple irq and reset lines
From: Dmitry Torokhov @ 2019-01-05 22:51 UTC (permalink / raw)
To: Alex Gonzalez; +Cc: hadess, linux-input, linux-kernel
In-Reply-To: <1546617648-23445-2-git-send-email-alex.gonzalez@digi.com>
Hi Alex,
On Fri, Jan 04, 2019 at 05:00:48PM +0100, Alex Gonzalez wrote:
> The Goodix touch controller allows the use of two optional GPIOs (RESET
> and INT) to reset the touch controller, select the I2C address of the
> device and exit the device from sleep mode.
>
> The current implementation requires both GPIOs to be provided, however,
> it is possible to provide only the INT line and not to have the RESET line
> available but pulled-up.
>
> Designs that only provide the INT line are able to operate the touch on
> the default I2C address but will not be able to reset the touch via
> software or place the device in sleep mode.
I do not have a datasheet for the device, so I am not sure if reset line
is actually needed to put the device into sleep mode. As far as I can
see from the code we suspend it by pulsing INT line and then sending a
command to the controller, and resuming by pulsing the INT line again.
So it sounds to me INT only designs _could_ place device in sleep mode.
As far as the patch goes, if you do not need to execute reset or put
device into low power mode, you do not need to specify any of the GPIOs
as GPIO resources. Simply specify the INT GPIO as your interrupt source
(GpioInt() in ACPI world or "interrupts = <&gpio NNN
IRQF_TRIGGER_WHATEVER>" in DT world and be done with it.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 2/2] Input: rotaty-encoder - Add DT binding document
From: Donghoon Han @ 2019-01-05 20:26 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Daniel Mack, linux-kernel
In-Reply-To: <20190105202659.20198-1-nazgul33@gmail.com>
Add DT binding document for rotary-encoder, keycode options.
Signed-off-by: Donghoon Han <nazgul33@gmail.com>
---
.../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
index f99fe5cdeaec..113640079de3 100644
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
@@ -12,6 +12,10 @@ Optional properties:
- rotary-encoder,relative-axis: register a relative axis rather than an
absolute one. Relative axis will only generate +1/-1 events on the input
device, hence no steps need to be passed.
+- rotary-encoder,relative-keys : generate pair of key events. This setting
+ behaves just like relative-axis, generating key events. keycode[2]
+ corresponds -1/1 events.
+- rotary-encoder,relative-keycodes : keycodes for relative-keys
- rotary-encoder,rollover: Automatic rollover when the rotary value becomes
greater than the specified steps or smaller than 0. For absolute axis only.
- rotary-encoder,steps-per-period: Number of steps (stable states) per period.
@@ -48,3 +52,11 @@ Example:
rotary-encoder,encoding = "binary";
rotary-encoder,rollover;
};
+
+ rotary@2 {
+ compatible = "rotary-encoder";
+ gpios = <&gpio 21 0>, <&gpio 22 0>;
+ rotary-encoder,relative-keys;
+ rotary-encoder,relative-keycode = <103>, <108>;
+ rotary-encoder,steps-per-period = <2>;
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] Input: rotary_encoder - Support key events
From: Donghoon Han @ 2019-01-05 20:26 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Daniel Mack, linux-kernel, Steven Han
In-Reply-To: <20190105202659.20198-1-nazgul33@gmail.com>
From: Steven Han <nazgul33@gmail.com>
Support generating EV_KEY pair, instead of EV_REL.
Signed-off-by: Donghoon Han <nazgul33@gmail.com>
---
drivers/input/misc/rotary_encoder.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 72eee6d55527..180e35884289 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -41,6 +41,8 @@ struct rotary_encoder {
u32 steps;
u32 axis;
bool relative_axis;
+ bool relative_keys;
+ u32 keycodes[2];
bool rollover;
enum rotary_encoder_encoding encoding;
@@ -79,6 +81,10 @@ static void rotary_encoder_report_event(struct rotary_encoder *encoder)
if (encoder->relative_axis) {
input_report_rel(encoder->input,
encoder->axis, encoder->dir);
+ } else if (encoder->relative_keys) {
+ u32 keycode = encoder->keycodes[encoder->dir > 0];
+ input_event(encoder->input, EV_KEY, keycode, 1);
+ input_event(encoder->input, EV_KEY, keycode, 0);
} else {
unsigned int pos = encoder->pos;
@@ -237,6 +243,16 @@ static int rotary_encoder_probe(struct platform_device *pdev)
device_property_read_u32(dev, "linux,axis", &encoder->axis);
encoder->relative_axis =
device_property_read_bool(dev, "rotary-encoder,relative-axis");
+ encoder->relative_keys =
+ device_property_read_bool(dev, "rotary-encoder,relative-keys");
+ if (encoder->relative_keys) {
+ err = device_property_read_u32_array(dev,
+ "rotary-encoder,relative-keycodes",
+ encoder->keycodes, 2);
+ if (err)
+ dev_err(dev, "unable to get keycodes: %d\n", err);
+ return err;
+ }
encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
if (IS_ERR(encoder->gpios)) {
@@ -260,9 +276,12 @@ static int rotary_encoder_probe(struct platform_device *pdev)
input->id.bustype = BUS_HOST;
input->dev.parent = dev;
- if (encoder->relative_axis)
+ if (encoder->relative_axis) {
input_set_capability(input, EV_REL, encoder->axis);
- else
+ } else if (encoder->relative_keys) {
+ input_set_capability(input, EV_KEY, encoder->keycodes[0]);
+ input_set_capability(input, EV_KEY, encoder->keycodes[1]);
+ } else
input_set_abs_params(input,
encoder->axis, 0, encoder->steps, 0, 1);
--
2.17.1
^ permalink raw reply related
* [PATCH 0/2] input: rotary-encoder: Support key events
From: Donghoon Han @ 2019-01-05 20:26 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Daniel Mack, linux-kernel
This patchset supports generating EV_KEY, instead of EV_REL.
An example could be a volume knob, with key events:
- KEY_VOLUMEDOWN / KEY_VOLUMEUP
[tested on imx6q platform, full period, half period]
Donghoon Han (2):
Input: rotary_encoder - Support key events
Input: rotaty-encoder - Add DT binding document
Documentation/devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
drivers/input/misc/rotary_encoder.c | 23 +++++++++++++++++++++--
2 files changed, 33 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH] keyboard/mtk-pmic-keys.c: Remove duplicate header
From: Brajeswar Ghosh @ 2019-01-05 5:09 UTC (permalink / raw)
To: dmitry.torokhov, matthias.bgg, lee.jones, chen.zhong
Cc: jrdr.linux, linux-input, linux-arm-kernel, linux-mediatek,
linux-kernel
Remove linux/kernel.h which is included more than once
Signed-off-by: Brajeswar Ghosh <brajeswar.linux@gmail.com>
---
drivers/input/keyboard/mtk-pmic-keys.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index 02c67a1749fc..5027ebb7b4e8 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -19,7 +19,6 @@
#include <linux/input.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
-#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/regmap.h>
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox