[PATCH v3 1/4] HID: core: move the dynamic quirks handling in core

[Benjamin Tissoires]

usbhid has a list of dynamic quirks in addition to a list of static quirks.
There is not much USB specific in that, so move this part of the module
in core so we can have one central place for quirks.

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

---
changes in v3:
- rebased on top of for-next (MCS_GAMEPADBLOCK added)

changes in v2:
- add missing EXPORT_SYMBOL[_GPL] for separate module compilation
---
 drivers/hid/Makefile  |   2 +-
 drivers/hid/hid-core.c|  10 +-
 drivers/hid/{usbhid => }/hid-quirks.c | 493 +-
 drivers/hid/usbhid/Makefile   |   2 +-
 drivers/hid/usbhid/hid-core.c |  10 +-
 include/linux/hid.h   |  10 +-
 6 files changed, 264 insertions(+), 263 deletions(-)
 rename drivers/hid/{usbhid => }/hid-quirks.c (11%)

diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 235bd2a7b333..2be460d44c69 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -2,7 +2,7 @@
 #
 # Makefile for the HID driver
 #
-hid-y  := hid-core.o hid-input.o
+hid-y  := hid-core.o hid-input.o hid-quirks.o
 hid-$(CONFIG_DEBUG_FS) += hid-debug.o
 
 obj-$(CONFIG_HID)  += hid.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f3fcb836a1f9..e11caea05f8d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1597,8 +1597,8 @@ int hid_input_report(struct hid_device *hid, int type, u8 
*data, int size, int i
 }
 EXPORT_SYMBOL_GPL(hid_input_report);
 
-static bool hid_match_one_id(struct hid_device *hdev,
-   const struct hid_device_id *id)
+bool hid_match_one_id(const struct hid_device *hdev,
+ const struct hid_device_id *id)
 {
return (id->bus == HID_BUS_ANY || id->bus == hdev->bus) &&
(id->group == HID_GROUP_ANY || id->group == hdev->group) &&
@@ -1606,7 +1606,7 @@ static bool hid_match_one_id(struct hid_device *hdev,
(id->product == HID_ANY_ID || id->product == hdev->product);
 }
 
-const struct hid_device_id *hid_match_id(struct hid_device *hdev,
+const struct hid_device_id *hid_match_id(const struct hid_device *hdev,
const struct hid_device_id *id)
 {
for (; id->bus; id++)
@@ -2613,6 +2613,7 @@ static struct bus_type hid_bus_type = {
.remove = hid_device_remove,
.uevent = hid_uevent,
 };
+EXPORT_SYMBOL(hid_bus_type);
 
 /* a list of devices that shouldn't be handled by HID core at all */
 static const struct hid_device_id hid_ignore_list[] = {
@@ -2931,6 +2932,8 @@ int hid_add_device(struct hid_device *hdev)
if (WARN_ON(hdev->status & HID_STAT_ADDED))
return -EBUSY;
 
+   hdev->quirks = hid_lookup_quirk(hdev);
+
/* we need to kill them here, otherwise they will stay allocated to
 * wait for coming driver */
if (hid_ignore(hdev))
@@ -3117,6 +3120,7 @@ static void __exit hid_exit(void)
hid_debug_exit();
hidraw_exit();
bus_unregister(_bus_type);
+   hid_quirks_exit(HID_BUS_ANY);
 }
 
 module_init(hid_init);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/hid-quirks.c
similarity index 11%
rename from drivers/hid/usbhid/hid-quirks.c
rename to drivers/hid/hid-quirks.c
index 331f7f34ec14..ffb513a82581 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -1,5 +1,5 @@
 /*
- *  USB HID quirks support for Linux
+ *  HID quirks support for Linux
  *
  *  Copyright (c) 1999 Andreas Gal
  *  Copyright (c) 2000-2005 Vojtech Pavlik <vojt...@suse.cz>
@@ -18,247 +18,238 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "../hid-ids.h"
+#include "hid-ids.h"
 
 /*
- * Alphabetically sorted blacklist by quirk type.
+ * Alphabetically sorted by vendor then product.
  */
 
-static const struct hid_blacklist {
-   __u16 idVendor;
-   __u16 idProduct;
-   __u32 quirks;
-} hid_blacklist[] = {
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_CHIC, USB_DEVICE_ID_CHIC_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER, 
HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET },
-   { USB_VENDOR_ID_MOJO, USB_DEVICE_ID_RETRO_ADAPTER, 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_NATSU, USB_DEVICE_ID_NATSU_GAMEPAD, HID

[PATCH v3 3/4] HID: core: move the list of ignored devices in hid-quirks.c

[Benjamin Tissoires]

Better having all the devices quirks in one place.

Note that this change introduces an initial lookup for the device in
hid_gets_squirk(), which should not theoretically be required, but which
actually allows to not have to reparse the list of ignored devices
if we call hid_lookup_quirks twice.

Signed-off-by: Benjamin Tissoires 

---
no changes in v3

no changes in v2
---
 drivers/hid/hid-core.c   | 309 --
 drivers/hid/hid-quirks.c | 312 +++
 2 files changed, 312 insertions(+), 309 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 1c8d10724203..e6d586a22bbd 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2080,315 +2080,6 @@ static struct bus_type hid_bus_type = {
 };
 EXPORT_SYMBOL(hid_bus_type);
 
-/* a list of devices that shouldn't be handled by HID core at all */
-static const struct hid_device_id hid_ignore_list[] = {
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_FLAIR) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_302) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ADS_TECH, 
USB_DEVICE_ID_ADS_TECH_RADIO_SI470X) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_20) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_21) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_22) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_23) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_24) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIRCABLE, USB_DEVICE_ID_AIRCABLE1) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ALCOR, USB_DEVICE_ID_ALCOR_USBRS232) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM)},
-   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM2)},
-   { HID_USB_DEVICE(USB_VENDOR_ID_AVERMEDIA, USB_DEVICE_ID_AVER_FM_MR800) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_AXENTIA, USB_DEVICE_ID_AXENTIA_FM_RADIO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, 
USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, 
USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CMEDIA, USB_DEVICE_ID_CM109) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, 
USB_DEVICE_ID_CYPRESS_ULTRAMOUSE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DEALEXTREAME, 
USB_DEVICE_ID_DEALEXTREAME_RADIO_SI4701) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, 
USB_DEVICE_ID_DELORME_EARTHMATE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) 
},
-   { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) },
-   { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, 
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0001) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0002) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0004) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_SUPER_Q2) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_GOGOPEN) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_PENPOWER) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRETAGMACBETH, 
USB_DEVICE_ID_GRETAGMACBETH_HUEY) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_POWERMATE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_SOUNDKNOB) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_RADIOSHARK) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_90) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_100) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_101) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_103) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_104) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_105) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_106) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_107) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_108) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_200) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_201) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_202

[PATCH v3 0/4] Quirks cleanup and hid-generic niceness

[Benjamin Tissoires]

Hi,

this is v3 rebased on top of for-next.
There are no other changes.

Cheers,
Benjamin

Benjamin Tissoires (4):
  HID: core: move the dynamic quirks handling in core
  HID: quirks: move the list of special devices into a quirk
  HID: core: move the list of ignored devices in hid-quirks.c
  HID: core: remove the absolute need of hid_have_special_driver[]

 drivers/hid/Makefile|2 +-
 drivers/hid/hid-core.c  |  932 ++---
 drivers/hid/hid-generic.c   |   68 ++-
 drivers/hid/hid-quirks.c| 1248 +++
 drivers/hid/usbhid/Makefile |2 +-
 drivers/hid/usbhid/hid-core.c   |   10 +-
 drivers/hid/usbhid/hid-quirks.c |  402 -
 include/linux/hid.h |   21 +-
 net/bluetooth/hidp/core.c   |2 +-
 9 files changed, 1395 insertions(+), 1292 deletions(-)
 create mode 100644 drivers/hid/hid-quirks.c
 delete mode 100644 drivers/hid/usbhid/hid-quirks.c

-- 
2.14.3

[PATCH v3 1/4] HID: core: move the dynamic quirks handling in core

[Benjamin Tissoires]

usbhid has a list of dynamic quirks in addition to a list of static quirks.
There is not much USB specific in that, so move this part of the module
in core so we can have one central place for quirks.

Signed-off-by: Benjamin Tissoires 

---
changes in v3:
- rebased on top of for-next (MCS_GAMEPADBLOCK added)

changes in v2:
- add missing EXPORT_SYMBOL[_GPL] for separate module compilation
---
 drivers/hid/Makefile  |   2 +-
 drivers/hid/hid-core.c|  10 +-
 drivers/hid/{usbhid => }/hid-quirks.c | 493 +-
 drivers/hid/usbhid/Makefile   |   2 +-
 drivers/hid/usbhid/hid-core.c |  10 +-
 include/linux/hid.h   |  10 +-
 6 files changed, 264 insertions(+), 263 deletions(-)
 rename drivers/hid/{usbhid => }/hid-quirks.c (11%)

diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 235bd2a7b333..2be460d44c69 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -2,7 +2,7 @@
 #
 # Makefile for the HID driver
 #
-hid-y  := hid-core.o hid-input.o
+hid-y  := hid-core.o hid-input.o hid-quirks.o
 hid-$(CONFIG_DEBUG_FS) += hid-debug.o
 
 obj-$(CONFIG_HID)  += hid.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f3fcb836a1f9..e11caea05f8d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1597,8 +1597,8 @@ int hid_input_report(struct hid_device *hid, int type, u8 
*data, int size, int i
 }
 EXPORT_SYMBOL_GPL(hid_input_report);
 
-static bool hid_match_one_id(struct hid_device *hdev,
-   const struct hid_device_id *id)
+bool hid_match_one_id(const struct hid_device *hdev,
+ const struct hid_device_id *id)
 {
return (id->bus == HID_BUS_ANY || id->bus == hdev->bus) &&
(id->group == HID_GROUP_ANY || id->group == hdev->group) &&
@@ -1606,7 +1606,7 @@ static bool hid_match_one_id(struct hid_device *hdev,
(id->product == HID_ANY_ID || id->product == hdev->product);
 }
 
-const struct hid_device_id *hid_match_id(struct hid_device *hdev,
+const struct hid_device_id *hid_match_id(const struct hid_device *hdev,
const struct hid_device_id *id)
 {
for (; id->bus; id++)
@@ -2613,6 +2613,7 @@ static struct bus_type hid_bus_type = {
.remove = hid_device_remove,
.uevent = hid_uevent,
 };
+EXPORT_SYMBOL(hid_bus_type);
 
 /* a list of devices that shouldn't be handled by HID core at all */
 static const struct hid_device_id hid_ignore_list[] = {
@@ -2931,6 +2932,8 @@ int hid_add_device(struct hid_device *hdev)
if (WARN_ON(hdev->status & HID_STAT_ADDED))
return -EBUSY;
 
+   hdev->quirks = hid_lookup_quirk(hdev);
+
/* we need to kill them here, otherwise they will stay allocated to
 * wait for coming driver */
if (hid_ignore(hdev))
@@ -3117,6 +3120,7 @@ static void __exit hid_exit(void)
hid_debug_exit();
hidraw_exit();
bus_unregister(_bus_type);
+   hid_quirks_exit(HID_BUS_ANY);
 }
 
 module_init(hid_init);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/hid-quirks.c
similarity index 11%
rename from drivers/hid/usbhid/hid-quirks.c
rename to drivers/hid/hid-quirks.c
index 331f7f34ec14..ffb513a82581 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -1,5 +1,5 @@
 /*
- *  USB HID quirks support for Linux
+ *  HID quirks support for Linux
  *
  *  Copyright (c) 1999 Andreas Gal
  *  Copyright (c) 2000-2005 Vojtech Pavlik 
@@ -18,247 +18,238 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "../hid-ids.h"
+#include "hid-ids.h"
 
 /*
- * Alphabetically sorted blacklist by quirk type.
+ * Alphabetically sorted by vendor then product.
  */
 
-static const struct hid_blacklist {
-   __u16 idVendor;
-   __u16 idProduct;
-   __u32 quirks;
-} hid_blacklist[] = {
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_CHIC, USB_DEVICE_ID_CHIC_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER, 
HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET },
-   { USB_VENDOR_ID_MOJO, USB_DEVICE_ID_RETRO_ADAPTER, 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_NATSU, USB_DEVICE_ID_NATSU_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_NEC, USB_

Re: [PATCH v2 0/4] Quirks cleanup and hid-generic niceness

[Benjamin Tissoires]

Hi Jiri,

On Nov 16 2017 or thereabouts, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Benjamin Tissoires wrote:
> 
> > Hi,
> > 
> > Niels found an issue with v1 of the series, while compiling the usbhid 
> > module
> > as a separate .ko.
> > 
> > Sending a v2 with the proper From: field fixed now.
> > 
> > I also use -M1 to show in 1/4 that usbhid/hid-quirks.c is basically moved to
> > hid-quirks.c.
> 
> I am planning to queue this for 4.16; do you happen to have any followups 
> since you posted v2 in october?

Cool. I did not updated it since, but if you want I can send a v3
tomorrow based on your for-next branch.

Cheers,
Benjamin

> 
> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Re: [PATCH v2 0/4] Quirks cleanup and hid-generic niceness

[Benjamin Tissoires]

Hi Jiri,

On Nov 16 2017 or thereabouts, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Benjamin Tissoires wrote:
> 
> > Hi,
> > 
> > Niels found an issue with v1 of the series, while compiling the usbhid 
> > module
> > as a separate .ko.
> > 
> > Sending a v2 with the proper From: field fixed now.
> > 
> > I also use -M1 to show in 1/4 that usbhid/hid-quirks.c is basically moved to
> > hid-quirks.c.
> 
> I am planning to queue this for 4.16; do you happen to have any followups 
> since you posted v2 in october?

Cool. I did not updated it since, but if you want I can send a v3
tomorrow based on your for-next branch.

Cheers,
Benjamin

> 
> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Re: [PATCH] HID: input: enable Totem on the Dell Canvas 27

[Benjamin Tissoires]

On Nov 14 2017 or thereabouts, Dmitry Torokhov wrote:
> On Tue, Nov 14, 2017 at 06:50:43PM +1000, Peter Hutterer wrote:
> > sorry, this one got stuck in my outbox.
> > 
> > On Fri, Nov 10, 2017 at 11:26:35AM +0100, Benjamin Tissoires wrote:
> > > The Dell Canvas 27 has a tool that can be put on the surface and acts
> > > as a dial. The firmware processes the detection of the tool and forward
> > > regular HID reports with X, Y, Azimuth, rotation, width/height.
> > > 
> > > The firmware also exports Contact ID, Countact Count which may hint that
> > > several totems can be used at the same time, but for now, only allow
> > > one totem at a time.
> > > 
> > > We also ignore scan time in hid-input.c because there is not much point
> > > to forward it now given that the indication of the tool being present
> > > is already provided through BTN_TOOL_DIAL.
> > > 
> > > We need to add a new BTN_TOOL_DIAL event because the HID mapping
> > > suggests that this tool is aimed at being used by the system and not
> > > the applications. Also this prevents current systemd heuristics to
> > > apply ID_INPUT_TOUCHSCREEN to this new type of devices.
> > > 
> > > I mapped Azimuth to ABS_WHEEL to somehow ressemble the Wacom Pads.
> > 
> > HID docs indicate this is a full tool rotation, so ABS_RZ would be more
> > appropriate?
> > 
> > "Azimuth 
> > The counter-clockwise rotation of the cursor about the Z-axis."
> 
> Right. We night also want to consider whether we need to convert HID to
> Linux values, as HID is counter-clockwise, and I suspect Linux will be
> clockwise (what do we report for joysticks?), similar to what we had for
> ABS_MT_ORIENTATION.
> 
> > 
> > But you also say it has rotation, so this is a bit confusing now :)
> > We should also use INPUT_PROP_DIRECT here.
> > 
> > > Last, both Width and Heigth are groupped together, the FW reports
> > 
> > typo: grouped
> > 
> > > similar values for both and we are out of ABS_* events.
> > > 
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846
> > > 
> > > Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> > > ---
> > > 
> > > Hi,
> > > 
> > > This is probably v4.16 material as we are close to the merge window
> > > (I wouldn't mind it applied in v4.15 though ;-P)
> > 
> > I'm going to be annoying here and say I'd like to figure out how to add this
> > to libinput first to figure out what details can go wrong before we merge it
> > and commit to this forever. Hopefully that shouldn't take that long...
> > 

I had a chat with Peter this morning. TL;DR is I'll need to rework on
this more heavily to provide the final version with MT axes, and skip
the single device implementation. I have no ideas if the Dell Canvas
can report more than one totem, but the report descriptor would say so,
so we better have a proper implementation instead of having one for
single device capable and one for multiple devices.

I'll probably send a v2 just to address the issues raised here, but it
shouldn't be merged given that user space will not be accepting such
version.

Cheers,
Benjamin

> > > The patch does the job but we probably need to decide if the mappings
> > > I chose are correct.
> > > 
> > > For the record, I uploaded some evemu-record traces and hid-recorder
> > > traces in the RH Bz linked above to keep traces of them.
> > > The interesting one is the evemu one for the totem with this patch
> > > applied:
> > > https://bugzilla.redhat.com/attachment.cgi?id=1350389
> > > 
> > > Cheers,
> > > Benjamin
> > > 
> > >  drivers/hid/hid-input.c| 28 +++-
> > >  drivers/hid/hid-multitouch.c   | 11 +++
> > >  include/linux/hid.h|  6 ++
> > >  include/uapi/linux/input-event-codes.h |  1 +
> > >  4 files changed, 45 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> > > index 04d01b57d94c..7da72b571b7d 100644
> > > --- a/drivers/hid/hid-input.c
> > > +++ b/drivers/hid/hid-input.c
> > > @@ -229,6 +229,7 @@ __s32 hidinput_calc_abs_res(const struct hid_field 
> > > *field, __u16 code)
> > >   case ABS_X:
> > >   case ABS_Y:
> > >   case ABS_Z:
> > > + case ABS_TOOL_WIDTH:
> > >   case ABS_MT_POSITION_X:
> > >   c

Re: [PATCH] HID: input: enable Totem on the Dell Canvas 27

[Benjamin Tissoires]

On Nov 14 2017 or thereabouts, Dmitry Torokhov wrote:
> On Tue, Nov 14, 2017 at 06:50:43PM +1000, Peter Hutterer wrote:
> > sorry, this one got stuck in my outbox.
> > 
> > On Fri, Nov 10, 2017 at 11:26:35AM +0100, Benjamin Tissoires wrote:
> > > The Dell Canvas 27 has a tool that can be put on the surface and acts
> > > as a dial. The firmware processes the detection of the tool and forward
> > > regular HID reports with X, Y, Azimuth, rotation, width/height.
> > > 
> > > The firmware also exports Contact ID, Countact Count which may hint that
> > > several totems can be used at the same time, but for now, only allow
> > > one totem at a time.
> > > 
> > > We also ignore scan time in hid-input.c because there is not much point
> > > to forward it now given that the indication of the tool being present
> > > is already provided through BTN_TOOL_DIAL.
> > > 
> > > We need to add a new BTN_TOOL_DIAL event because the HID mapping
> > > suggests that this tool is aimed at being used by the system and not
> > > the applications. Also this prevents current systemd heuristics to
> > > apply ID_INPUT_TOUCHSCREEN to this new type of devices.
> > > 
> > > I mapped Azimuth to ABS_WHEEL to somehow ressemble the Wacom Pads.
> > 
> > HID docs indicate this is a full tool rotation, so ABS_RZ would be more
> > appropriate?
> > 
> > "Azimuth 
> > The counter-clockwise rotation of the cursor about the Z-axis."
> 
> Right. We night also want to consider whether we need to convert HID to
> Linux values, as HID is counter-clockwise, and I suspect Linux will be
> clockwise (what do we report for joysticks?), similar to what we had for
> ABS_MT_ORIENTATION.
> 
> > 
> > But you also say it has rotation, so this is a bit confusing now :)
> > We should also use INPUT_PROP_DIRECT here.
> > 
> > > Last, both Width and Heigth are groupped together, the FW reports
> > 
> > typo: grouped
> > 
> > > similar values for both and we are out of ABS_* events.
> > > 
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846
> > > 
> > > Signed-off-by: Benjamin Tissoires 
> > > ---
> > > 
> > > Hi,
> > > 
> > > This is probably v4.16 material as we are close to the merge window
> > > (I wouldn't mind it applied in v4.15 though ;-P)
> > 
> > I'm going to be annoying here and say I'd like to figure out how to add this
> > to libinput first to figure out what details can go wrong before we merge it
> > and commit to this forever. Hopefully that shouldn't take that long...
> > 

I had a chat with Peter this morning. TL;DR is I'll need to rework on
this more heavily to provide the final version with MT axes, and skip
the single device implementation. I have no ideas if the Dell Canvas
can report more than one totem, but the report descriptor would say so,
so we better have a proper implementation instead of having one for
single device capable and one for multiple devices.

I'll probably send a v2 just to address the issues raised here, but it
shouldn't be merged given that user space will not be accepting such
version.

Cheers,
Benjamin

> > > The patch does the job but we probably need to decide if the mappings
> > > I chose are correct.
> > > 
> > > For the record, I uploaded some evemu-record traces and hid-recorder
> > > traces in the RH Bz linked above to keep traces of them.
> > > The interesting one is the evemu one for the totem with this patch
> > > applied:
> > > https://bugzilla.redhat.com/attachment.cgi?id=1350389
> > > 
> > > Cheers,
> > > Benjamin
> > > 
> > >  drivers/hid/hid-input.c| 28 +++-
> > >  drivers/hid/hid-multitouch.c   | 11 +++
> > >  include/linux/hid.h|  6 ++
> > >  include/uapi/linux/input-event-codes.h |  1 +
> > >  4 files changed, 45 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> > > index 04d01b57d94c..7da72b571b7d 100644
> > > --- a/drivers/hid/hid-input.c
> > > +++ b/drivers/hid/hid-input.c
> > > @@ -229,6 +229,7 @@ __s32 hidinput_calc_abs_res(const struct hid_field 
> > > *field, __u16 code)
> > >   case ABS_X:
> > >   case ABS_Y:
> > >   case ABS_Z:
> > > + case ABS_TOOL_WIDTH:
> > >   case ABS_MT_POSITION_X:
> > >   case ABS_MT_POSITION_Y:
> > >   case ABS_MT_TOOL

[PATCH] HID: input: enable Totem on the Dell Canvas 27

[Benjamin Tissoires]

The Dell Canvas 27 has a tool that can be put on the surface and acts
as a dial. The firmware processes the detection of the tool and forward
regular HID reports with X, Y, Azimuth, rotation, width/height.

The firmware also exports Contact ID, Countact Count which may hint that
several totems can be used at the same time, but for now, only allow
one totem at a time.

We also ignore scan time in hid-input.c because there is not much point
to forward it now given that the indication of the tool being present
is already provided through BTN_TOOL_DIAL.

We need to add a new BTN_TOOL_DIAL event because the HID mapping
suggests that this tool is aimed at being used by the system and not
the applications. Also this prevents current systemd heuristics to
apply ID_INPUT_TOUCHSCREEN to this new type of devices.

I mapped Azimuth to ABS_WHEEL to somehow ressemble the Wacom Pads.
Last, both Width and Heigth are groupped together, the FW reports
similar values for both and we are out of ABS_* events.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
---

Hi,

This is probably v4.16 material as we are close to the merge window
(I wouldn't mind it applied in v4.15 though ;-P)

The patch does the job but we probably need to decide if the mappings
I chose are correct.

For the record, I uploaded some evemu-record traces and hid-recorder
traces in the RH Bz linked above to keep traces of them.
The interesting one is the evemu one for the totem with this patch
applied:
https://bugzilla.redhat.com/attachment.cgi?id=1350389

Cheers,
Benjamin

 drivers/hid/hid-input.c| 28 +++-
 drivers/hid/hid-multitouch.c   | 11 +++
 include/linux/hid.h|  6 ++
 include/uapi/linux/input-event-codes.h |  1 +
 4 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 04d01b57d94c..7da72b571b7d 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -229,6 +229,7 @@ __s32 hidinput_calc_abs_res(const struct hid_field *field, 
__u16 code)
case ABS_X:
case ABS_Y:
case ABS_Z:
+   case ABS_TOOL_WIDTH:
case ABS_MT_POSITION_X:
case ABS_MT_POSITION_Y:
case ABS_MT_TOOL_X:
@@ -786,13 +787,24 @@ static void hidinput_configure_usage(struct hid_input 
*hidinput, struct hid_fiel
map_abs_clear(ABS_TILT_Y);
break;
 
+   case 0x3f: /* Azimuth */
+   map_abs_clear(ABS_WHEEL);
+   break;
+
case 0x33: /* Touch */
-   case 0x42: /* TipSwitch */
case 0x43: /* TipSwitch2 */
device->quirks &= ~HID_QUIRK_NOTOUCH;
map_key_clear(BTN_TOUCH);
break;
 
+   case 0x42: /* TipSwitch */
+   if (field->application == HID_GD_SYSTEM_MULTIAXIS) {
+   map_key_clear(BTN_TOOL_DIAL);
+   } else {
+   device->quirks &= ~HID_QUIRK_NOTOUCH;
+   map_key_clear(BTN_TOUCH);
+   }
+   break;
case 0x44: /* BarrelSwitch */
map_key_clear(BTN_STYLUS);
break;
@@ -806,6 +818,20 @@ static void hidinput_configure_usage(struct hid_input 
*hidinput, struct hid_fiel
map_key_clear(BTN_TOUCH);
break;
 
+   case 0x48: /* WIDTH */
+   case 0x49: /* HEIGHT */
+   map_abs_clear(ABS_TOOL_WIDTH);
+   break;
+
+   case 0x51: /* CONTACT ID */
+   goto ignore;
+
+   case 0x54: /* CONTACT COUNT */
+   goto ignore;
+
+   case 0x56: /* SCANTIME */
+   goto ignore;
+
case 0x46: /* TabletPick */
case 0x5a: /* SecondaryBarrelSwitch */
map_key_clear(BTN_STYLUS2);
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 65ea23be9677..a0b332518eaa 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -974,6 +974,7 @@ static int mt_input_mapping(struct hid_device *hdev, struct 
hid_input *hi,
field->application != HID_DG_TOUCHPAD &&
field->application != HID_GD_KEYBOARD &&
field->application != HID_GD_SYSTEM_CONTROL &&
+   field->application != HID_GD_SYSTEM_MULTIAXIS &&
field->application != HID_CP_CONSUMER_CONTROL &&
field->application != HID_GD_WIRELESS_RADIO_CTLS &&
!(field->application == HID_VD_ASUS_CUSTOM_MEDIA

[PATCH] HID: input: enable Totem on the Dell Canvas 27

[Benjamin Tissoires]

The Dell Canvas 27 has a tool that can be put on the surface and acts
as a dial. The firmware processes the detection of the tool and forward
regular HID reports with X, Y, Azimuth, rotation, width/height.

The firmware also exports Contact ID, Countact Count which may hint that
several totems can be used at the same time, but for now, only allow
one totem at a time.

We also ignore scan time in hid-input.c because there is not much point
to forward it now given that the indication of the tool being present
is already provided through BTN_TOOL_DIAL.

We need to add a new BTN_TOOL_DIAL event because the HID mapping
suggests that this tool is aimed at being used by the system and not
the applications. Also this prevents current systemd heuristics to
apply ID_INPUT_TOUCHSCREEN to this new type of devices.

I mapped Azimuth to ABS_WHEEL to somehow ressemble the Wacom Pads.
Last, both Width and Heigth are groupped together, the FW reports
similar values for both and we are out of ABS_* events.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846

Signed-off-by: Benjamin Tissoires 
---

Hi,

This is probably v4.16 material as we are close to the merge window
(I wouldn't mind it applied in v4.15 though ;-P)

The patch does the job but we probably need to decide if the mappings
I chose are correct.

For the record, I uploaded some evemu-record traces and hid-recorder
traces in the RH Bz linked above to keep traces of them.
The interesting one is the evemu one for the totem with this patch
applied:
https://bugzilla.redhat.com/attachment.cgi?id=1350389

Cheers,
Benjamin

 drivers/hid/hid-input.c| 28 +++-
 drivers/hid/hid-multitouch.c   | 11 +++
 include/linux/hid.h|  6 ++
 include/uapi/linux/input-event-codes.h |  1 +
 4 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 04d01b57d94c..7da72b571b7d 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -229,6 +229,7 @@ __s32 hidinput_calc_abs_res(const struct hid_field *field, 
__u16 code)
case ABS_X:
case ABS_Y:
case ABS_Z:
+   case ABS_TOOL_WIDTH:
case ABS_MT_POSITION_X:
case ABS_MT_POSITION_Y:
case ABS_MT_TOOL_X:
@@ -786,13 +787,24 @@ static void hidinput_configure_usage(struct hid_input 
*hidinput, struct hid_fiel
map_abs_clear(ABS_TILT_Y);
break;
 
+   case 0x3f: /* Azimuth */
+   map_abs_clear(ABS_WHEEL);
+   break;
+
case 0x33: /* Touch */
-   case 0x42: /* TipSwitch */
case 0x43: /* TipSwitch2 */
device->quirks &= ~HID_QUIRK_NOTOUCH;
map_key_clear(BTN_TOUCH);
break;
 
+   case 0x42: /* TipSwitch */
+   if (field->application == HID_GD_SYSTEM_MULTIAXIS) {
+   map_key_clear(BTN_TOOL_DIAL);
+   } else {
+   device->quirks &= ~HID_QUIRK_NOTOUCH;
+   map_key_clear(BTN_TOUCH);
+   }
+   break;
case 0x44: /* BarrelSwitch */
map_key_clear(BTN_STYLUS);
break;
@@ -806,6 +818,20 @@ static void hidinput_configure_usage(struct hid_input 
*hidinput, struct hid_fiel
map_key_clear(BTN_TOUCH);
break;
 
+   case 0x48: /* WIDTH */
+   case 0x49: /* HEIGHT */
+   map_abs_clear(ABS_TOOL_WIDTH);
+   break;
+
+   case 0x51: /* CONTACT ID */
+   goto ignore;
+
+   case 0x54: /* CONTACT COUNT */
+   goto ignore;
+
+   case 0x56: /* SCANTIME */
+   goto ignore;
+
case 0x46: /* TabletPick */
case 0x5a: /* SecondaryBarrelSwitch */
map_key_clear(BTN_STYLUS2);
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 65ea23be9677..a0b332518eaa 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -974,6 +974,7 @@ static int mt_input_mapping(struct hid_device *hdev, struct 
hid_input *hi,
field->application != HID_DG_TOUCHPAD &&
field->application != HID_GD_KEYBOARD &&
field->application != HID_GD_SYSTEM_CONTROL &&
+   field->application != HID_GD_SYSTEM_MULTIAXIS &&
field->application != HID_CP_CONSUMER_CONTROL &&
field->application != HID_GD_WIRELESS_RADIO_CTLS &&
!(field->application == HID_VD_ASUS_CUSTOM_MEDIA_KEYS &&
@@ -1003,6 +1004,14 @@ static

Re: [PATCH v2 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Benjamin Tissoires]

On Nov 10 2017 or thereabouts, Sébastien Szymanski wrote:
> When everything goes smoothly, ret is set to 0 which makes the function
> to return EIO error.
> 
> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> Signed-off-by: Sébastien Szymanski <sebastien.szyman...@armadeus.com>
> ---
> Changes in v2:
>  - rework error handling to have only one exit path as suggested by
>Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Looks good to me now. Thanks for the respin:
Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> 
>  drivers/hid/hid-cp2112.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 28e3c18..68cdc96 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -196,6 +196,8 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>HID_REQ_GET_REPORT);
>   if (ret != CP2112_GPIO_CONFIG_LENGTH) {
>   hid_err(hdev, "error requesting GPIO config: %d\n", ret);
> + if (ret >= 0)
> + ret = -EIO;
>   goto exit;
>   }
>  
> @@ -205,8 +207,10 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>   ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
>CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
>HID_REQ_SET_REPORT);
> - if (ret < 0) {
> + if (ret != CP2112_GPIO_CONFIG_LENGTH) {
>   hid_err(hdev, "error setting GPIO config: %d\n", ret);
> + if (ret >= 0)
> + ret = -EIO;
>   goto exit;
>   }
>  
> @@ -214,7 +218,7 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>  
>  exit:
>   mutex_unlock(>lock);
> - return ret < 0 ? ret : -EIO;
> + return ret;
>  }
>  
>  static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int 
> value)
> -- 
> 2.7.3
> 

Re: [PATCH v2 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Benjamin Tissoires]

On Nov 10 2017 or thereabouts, Sébastien Szymanski wrote:
> When everything goes smoothly, ret is set to 0 which makes the function
> to return EIO error.
> 
> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> Signed-off-by: Sébastien Szymanski 
> ---
> Changes in v2:
>  - rework error handling to have only one exit path as suggested by
>Benjamin Tissoires 

Looks good to me now. Thanks for the respin:
Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

> 
>  drivers/hid/hid-cp2112.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 28e3c18..68cdc96 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -196,6 +196,8 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>HID_REQ_GET_REPORT);
>   if (ret != CP2112_GPIO_CONFIG_LENGTH) {
>   hid_err(hdev, "error requesting GPIO config: %d\n", ret);
> + if (ret >= 0)
> + ret = -EIO;
>   goto exit;
>   }
>  
> @@ -205,8 +207,10 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>   ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
>CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
>HID_REQ_SET_REPORT);
> - if (ret < 0) {
> + if (ret != CP2112_GPIO_CONFIG_LENGTH) {
>   hid_err(hdev, "error setting GPIO config: %d\n", ret);
> + if (ret >= 0)
> + ret = -EIO;
>   goto exit;
>   }
>  
> @@ -214,7 +218,7 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>  
>  exit:
>   mutex_unlock(>lock);
> - return ret < 0 ? ret : -EIO;
> + return ret;
>  }
>  
>  static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int 
> value)
> -- 
> 2.7.3
> 

Re: [PATCH 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Benjamin Tissoires]

On Nov 06 2017 or thereabouts, Sébastien Szymanski wrote:
> On 11/06/2017 09:11 AM, Benjamin Tissoires wrote:
> > On Nov 02 2017 or thereabouts, Sébastien Szymanski wrote:
> >> When everything goes smoothly, ret is set to 0 which makes the function
> >> to return EIO error.
> >>
> >> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> >> Signed-off-by: Sébastien Szymanski <sebastien.szyman...@armadeus.com>
> >> ---
> >>  drivers/hid/hid-cp2112.c | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> >> index 28e3c18..f7754a6 100644
> >> --- a/drivers/hid/hid-cp2112.c
> >> +++ b/drivers/hid/hid-cp2112.c
> >> @@ -205,12 +205,13 @@ static int cp2112_gpio_direction_input(struct 
> >> gpio_chip *chip, unsigned offset)
> >>ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
> >> CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
> >> HID_REQ_SET_REPORT);
> >> -  if (ret < 0) {
> >> +  if (ret != CP2112_GPIO_CONFIG_LENGTH) {
> > 
> > Ack for this.
> 
> As explained in the interface specification, the device doesn't answer
> to set reports, so the transfer should be CP2112_GPIO_CONFIG_LENGTH (5)
> bytes.
> 
> > 
> >>hid_err(hdev, "error setting GPIO config: %d\n", ret);
> >>goto exit;
> >>}
> >>  
> >> -  ret = 0;
> >> +  mutex_unlock(>lock);
> >> +  return 0;
> > 
> > Wouldn't it be better to just turn
> > - return ret < 0 ? ret : -EIO;
> > into
> > + return ret <= 0 ? ret : -EIO;
> > at the end of the function?
> 
> Well, the commit I mentioned in the Fixes tag, changes from
> 
> - return ret <= 0 ? ret : -EIO;
> 
> to
> 
> + return ret < 0 ? ret : -EIO;
> 
> because ret being 0 could mean that one of the hid_hw_raw_request
> returned 0.

True.

So, commit 8e9faa15469e basically makes all transfert return -EIO and
should be reverted, right?

IMO, your commit should be:
if (ret != CP2112_GPIO_CONFIG_LENGTH) {
hid_err(hdev, "error setting GPIO config: %d\n", ret);
if (ret >= 0)
ret = -EIO;
goto exit;
}

ret = 0;
exit:
mutex_unlock(>lock);
return ret;

How does that sound?

Cheers,
Benjamin

> 
> Regards,
> 
> > 
> > I'd rather keep the same exit path in both cases, error or success.
> > 
> > Cheers,
> > Benjamin
> > 
> > 
> >>  
> >>  exit:
> >>mutex_unlock(>lock);
> >> -- 
> >> 2.7.3
> >>
> 
> 
> -- 
> Sébastien Szymanski
> Software engineer, Armadeus Systems
> Tel: +33 (0)9 72 29 41 44
> Fax: +33 (0)9 72 28 79 26

Re: [PATCH 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Benjamin Tissoires]

On Nov 06 2017 or thereabouts, Sébastien Szymanski wrote:
> On 11/06/2017 09:11 AM, Benjamin Tissoires wrote:
> > On Nov 02 2017 or thereabouts, Sébastien Szymanski wrote:
> >> When everything goes smoothly, ret is set to 0 which makes the function
> >> to return EIO error.
> >>
> >> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> >> Signed-off-by: Sébastien Szymanski 
> >> ---
> >>  drivers/hid/hid-cp2112.c | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> >> index 28e3c18..f7754a6 100644
> >> --- a/drivers/hid/hid-cp2112.c
> >> +++ b/drivers/hid/hid-cp2112.c
> >> @@ -205,12 +205,13 @@ static int cp2112_gpio_direction_input(struct 
> >> gpio_chip *chip, unsigned offset)
> >>ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
> >> CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
> >> HID_REQ_SET_REPORT);
> >> -  if (ret < 0) {
> >> +  if (ret != CP2112_GPIO_CONFIG_LENGTH) {
> > 
> > Ack for this.
> 
> As explained in the interface specification, the device doesn't answer
> to set reports, so the transfer should be CP2112_GPIO_CONFIG_LENGTH (5)
> bytes.
> 
> > 
> >>hid_err(hdev, "error setting GPIO config: %d\n", ret);
> >>goto exit;
> >>}
> >>  
> >> -  ret = 0;
> >> +  mutex_unlock(>lock);
> >> +  return 0;
> > 
> > Wouldn't it be better to just turn
> > - return ret < 0 ? ret : -EIO;
> > into
> > + return ret <= 0 ? ret : -EIO;
> > at the end of the function?
> 
> Well, the commit I mentioned in the Fixes tag, changes from
> 
> - return ret <= 0 ? ret : -EIO;
> 
> to
> 
> + return ret < 0 ? ret : -EIO;
> 
> because ret being 0 could mean that one of the hid_hw_raw_request
> returned 0.

True.

So, commit 8e9faa15469e basically makes all transfert return -EIO and
should be reverted, right?

IMO, your commit should be:
if (ret != CP2112_GPIO_CONFIG_LENGTH) {
hid_err(hdev, "error setting GPIO config: %d\n", ret);
if (ret >= 0)
ret = -EIO;
goto exit;
}

ret = 0;
exit:
mutex_unlock(>lock);
return ret;

How does that sound?

Cheers,
Benjamin

> 
> Regards,
> 
> > 
> > I'd rather keep the same exit path in both cases, error or success.
> > 
> > Cheers,
> > Benjamin
> > 
> > 
> >>  
> >>  exit:
> >>mutex_unlock(>lock);
> >> -- 
> >> 2.7.3
> >>
> 
> 
> -- 
> Sébastien Szymanski
> Software engineer, Armadeus Systems
> Tel: +33 (0)9 72 29 41 44
> Fax: +33 (0)9 72 28 79 26

Re: [PATCH] HID: i2c-hid: add reset gpio property

[Benjamin Tissoires]

On Oct 30 2017 or thereabouts, Brian Norris wrote:
> On Mon, Oct 30, 2017 at 03:15:19PM -0500, Rob Herring wrote:
> > On Mon, Oct 30, 2017 at 11:57 AM, Brian Norris  
> > wrote:
> > > On Mon, Oct 30, 2017 at 10:49:49AM +0800, Lin Huang wrote:
> > >> --- a/drivers/hid/i2c-hid/i2c-hid.c
> > >> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> 
> > >> @@ -793,6 +794,34 @@ struct hid_ll_driver i2c_hid_ll_driver = {
> > >>  };
> > >>  EXPORT_SYMBOL_GPL(i2c_hid_ll_driver);
> > >>
> > >> +static int i2c_hid_hw_power_on(struct i2c_hid *ihid)
> > >> +{
> > >> + int ret;
> > >> +
> > >> + ret = regulator_enable(ihid->pdata.supply);
> > >> + if (ret < 0)
> > >> + return ret;
> > >> +
> > >> + if (ihid->pdata.post_power_delay_ms)
> > >> + msleep(ihid->pdata.post_power_delay_ms);
> > >> +
> > >> + gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 1);
> > >> + usleep_range(ihid->pdata.assert_reset_us,
> > >> +  ihid->pdata.assert_reset_us);
> > 
> > You already ensure that reset is asserted before power on, so why does
> > the post_power_delay_ms not work for you? IIRC, there's already a
> > property for it.
> 
> That would be more like the equivalent of the "deassert" delay used a
> few lines below. The "assert" delay would be a different property,
> unless we want to guess at a reasonable value, or else key off something
> like 'compatible'.
> 
> But otherwise, sure, we could reuse it. We'd then want to modify the
> binding documentation to be less specific to the "vdd-supply" though.
> 
> > > What's the point of using the same value on both ends of the range? Does
> > > it make sense to give some padding to this? e.g., from X to X + 10% ?
> > > (Note that reasonable values for this are on the order of a few
> > > milliseconds.)
> > >
> > > Also, the above msleep() has a 'if non-zero' condition on it...but
> > > that's not actually necessary now that I look again, since msleep() and
> > > usleep_range() both handle zero times OK... But it feels a little
> > > inconsistent. We should probably change one or the other sometime.
> > >
> > >> + gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 0);
> > >> + usleep_range(ihid->pdata.deassert_reset_us,
> > >> +  ihid->pdata.deassert_reset_us);
> > >> +
> > >> + return ret;
> > >> +}
> > >> +
> > >> +static int i2c_hid_hw_power_off(struct i2c_hid *ihid)
> > >> +{
> > >> + gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 1);
> > >> +
> > >> + return regulator_disable(ihid->pdata.supply);
> > >> +}
> > >> +
> > >>  static int i2c_hid_init_irq(struct i2c_client *client)
> > >>  {
> > >>   struct i2c_hid *ihid = i2c_get_clientdata(client);
> > >> @@ -934,6 +963,12 @@ static int i2c_hid_of_probe(struct i2c_client 
> > >> *client,
> > >>   if (!ret)
> > >>   pdata->post_power_delay_ms = val;
> > >>
> > >> + ret = of_property_read_u32(dev->of_node, "assert-reset-us",
> > >> +>assert_reset_us);
> > >> +
> > >> + ret = of_property_read_u32(dev->of_node, "deassert-reset-us",
> > >> +>deassert_reset_us);
> > >
> > > You need to document these.
> > 
> > I'm not inclined to accept these. Sure, it's only 2 properties. No big
> > deal on their own. However, what about the next device that needs some
> > other delay. Or has another control signal with timing constraints. Or
> > has a clock with specific enable timing. The list goes on... If we
> > wanted to handle all cases of power sequencing in DT, then we'd write
> > something flexible to handle any case. But we don't because DT is not
> > a scripting language. This is why we have compatibles for each
> > specific chip.
> 
> I feel like we've had this discussion. I think the essence of the
> disagreement was that the maintainer of this driver did not want to
> support a long list of 'compatible' properties for stuff that's
> otherwise all hidden by the ACPI model -- the DT binding doc even refers
> to a Windows/ACPI spec. (A secondary concern was that the I2C subsystem
> still doesn't support multiple compatible strings with modules
> correctly, IIRC.)
> 
> I don't really know how to bridge that gap. DT-based platforms are
> inherently not ACPI, and all the device "power on" logic just has to be
> done in the kernel. Unfortunately, some ways of slicing this require
> more burden on driver maintainers...

I asked one other question to Rob in the new thread, but now that I
re-read this, I wonder:

As you said, HID over I2C is a protocol designed only for ACPI (because
Windows). It is generic enough but relies on ACPI to do its usual crap
like setting the reset lines and timing issues.
The initial OF implementation was done "because we can and it works".

Given that the OF firmware is a different world, how about we strip out
the OF part of i2c-hid, and make its own module (or compilation unit).

This way, the i2c-hid OF version would 

Re: [PATCH] HID: i2c-hid: add reset gpio property

[Benjamin Tissoires]

On Oct 30 2017 or thereabouts, Brian Norris wrote:
> On Mon, Oct 30, 2017 at 03:15:19PM -0500, Rob Herring wrote:
> > On Mon, Oct 30, 2017 at 11:57 AM, Brian Norris  
> > wrote:
> > > On Mon, Oct 30, 2017 at 10:49:49AM +0800, Lin Huang wrote:
> > >> --- a/drivers/hid/i2c-hid/i2c-hid.c
> > >> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> 
> > >> @@ -793,6 +794,34 @@ struct hid_ll_driver i2c_hid_ll_driver = {
> > >>  };
> > >>  EXPORT_SYMBOL_GPL(i2c_hid_ll_driver);
> > >>
> > >> +static int i2c_hid_hw_power_on(struct i2c_hid *ihid)
> > >> +{
> > >> + int ret;
> > >> +
> > >> + ret = regulator_enable(ihid->pdata.supply);
> > >> + if (ret < 0)
> > >> + return ret;
> > >> +
> > >> + if (ihid->pdata.post_power_delay_ms)
> > >> + msleep(ihid->pdata.post_power_delay_ms);
> > >> +
> > >> + gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 1);
> > >> + usleep_range(ihid->pdata.assert_reset_us,
> > >> +  ihid->pdata.assert_reset_us);
> > 
> > You already ensure that reset is asserted before power on, so why does
> > the post_power_delay_ms not work for you? IIRC, there's already a
> > property for it.
> 
> That would be more like the equivalent of the "deassert" delay used a
> few lines below. The "assert" delay would be a different property,
> unless we want to guess at a reasonable value, or else key off something
> like 'compatible'.
> 
> But otherwise, sure, we could reuse it. We'd then want to modify the
> binding documentation to be less specific to the "vdd-supply" though.
> 
> > > What's the point of using the same value on both ends of the range? Does
> > > it make sense to give some padding to this? e.g., from X to X + 10% ?
> > > (Note that reasonable values for this are on the order of a few
> > > milliseconds.)
> > >
> > > Also, the above msleep() has a 'if non-zero' condition on it...but
> > > that's not actually necessary now that I look again, since msleep() and
> > > usleep_range() both handle zero times OK... But it feels a little
> > > inconsistent. We should probably change one or the other sometime.
> > >
> > >> + gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 0);
> > >> + usleep_range(ihid->pdata.deassert_reset_us,
> > >> +  ihid->pdata.deassert_reset_us);
> > >> +
> > >> + return ret;
> > >> +}
> > >> +
> > >> +static int i2c_hid_hw_power_off(struct i2c_hid *ihid)
> > >> +{
> > >> + gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 1);
> > >> +
> > >> + return regulator_disable(ihid->pdata.supply);
> > >> +}
> > >> +
> > >>  static int i2c_hid_init_irq(struct i2c_client *client)
> > >>  {
> > >>   struct i2c_hid *ihid = i2c_get_clientdata(client);
> > >> @@ -934,6 +963,12 @@ static int i2c_hid_of_probe(struct i2c_client 
> > >> *client,
> > >>   if (!ret)
> > >>   pdata->post_power_delay_ms = val;
> > >>
> > >> + ret = of_property_read_u32(dev->of_node, "assert-reset-us",
> > >> +>assert_reset_us);
> > >> +
> > >> + ret = of_property_read_u32(dev->of_node, "deassert-reset-us",
> > >> +>deassert_reset_us);
> > >
> > > You need to document these.
> > 
> > I'm not inclined to accept these. Sure, it's only 2 properties. No big
> > deal on their own. However, what about the next device that needs some
> > other delay. Or has another control signal with timing constraints. Or
> > has a clock with specific enable timing. The list goes on... If we
> > wanted to handle all cases of power sequencing in DT, then we'd write
> > something flexible to handle any case. But we don't because DT is not
> > a scripting language. This is why we have compatibles for each
> > specific chip.
> 
> I feel like we've had this discussion. I think the essence of the
> disagreement was that the maintainer of this driver did not want to
> support a long list of 'compatible' properties for stuff that's
> otherwise all hidden by the ACPI model -- the DT binding doc even refers
> to a Windows/ACPI spec. (A secondary concern was that the I2C subsystem
> still doesn't support multiple compatible strings with modules
> correctly, IIRC.)
> 
> I don't really know how to bridge that gap. DT-based platforms are
> inherently not ACPI, and all the device "power on" logic just has to be
> done in the kernel. Unfortunately, some ways of slicing this require
> more burden on driver maintainers...

I asked one other question to Rob in the new thread, but now that I
re-read this, I wonder:

As you said, HID over I2C is a protocol designed only for ACPI (because
Windows). It is generic enough but relies on ACPI to do its usual crap
like setting the reset lines and timing issues.
The initial OF implementation was done "because we can and it works".

Given that the OF firmware is a different world, how about we strip out
the OF part of i2c-hid, and make its own module (or compilation unit).

This way, the i2c-hid OF version would communicate with i2c-hid (ACPI)

Re: [PATCH v2 2/2] devicetree: i2c-hid: Add reset property

[Benjamin Tissoires]

Hi Rob,

On Nov 01 2017 or thereabouts, Rob Herring wrote:
> On Tue, Oct 31, 2017 at 11:03:16AM +0800, Lin Huang wrote:
> > Document a "reset" and "assert-reset-us", it can be used for
> > driver control reset property. And reuse post-power-on-delay-ms
> > for deassert reset delay.
> 
> "dt-bindings: input: " for the subject please.
> 
> > 
> > Signed-off-by: Lin Huang 
> > ---
> >  Documentation/devicetree/bindings/input/hid-over-i2c.txt | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt 
> > b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > index 28e8bd8..6ab0eed 100644
> > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > @@ -31,7 +31,9 @@ device-specific compatible properties, which should be 
> > used in addition to the
> >  
> >  - vdd-supply: phandle of the regulator that provides the supply voltage.
> >  - post-power-on-delay-ms: time required by the device after enabling its 
> > regulators
> > -  before it is ready for communication. Must be used with 'vdd-supply'.
> > +  or deassert reset pin before it is ready for communication.
> > +- reset: phandle of the gpio that provides for hid reset pin.
> 
> The kernel api takes "reset", but the property is "reset-gpios".

In the same way the generic regulator interface handles vdd-supply, is
there any generic OF handling of reset lines? As far as I can tell,
there are 97 references of reset-gpios in my tree, and I wonder if all
the matching drivers need to rewrite the same code to set the reset line
on power on/off.

I am worried because here, 1/2 writes "arbitrary" 0 and 1 to the gpios,
and nothing prevent a manufacturer to invert the required voltages on
the reset lines, meaning there will be a need for a new OF property.

Cheers,
Benjamin

> 
> And it's not just a phandle typically.
> 
> > +- assert-reset-us: the device require reset assert time.
> >  
> >  Example:
> >  
> > -- 
> > 2.7.4
> > 

Re: [PATCH v2 2/2] devicetree: i2c-hid: Add reset property

[Benjamin Tissoires]

Hi Rob,

On Nov 01 2017 or thereabouts, Rob Herring wrote:
> On Tue, Oct 31, 2017 at 11:03:16AM +0800, Lin Huang wrote:
> > Document a "reset" and "assert-reset-us", it can be used for
> > driver control reset property. And reuse post-power-on-delay-ms
> > for deassert reset delay.
> 
> "dt-bindings: input: " for the subject please.
> 
> > 
> > Signed-off-by: Lin Huang 
> > ---
> >  Documentation/devicetree/bindings/input/hid-over-i2c.txt | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt 
> > b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > index 28e8bd8..6ab0eed 100644
> > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > @@ -31,7 +31,9 @@ device-specific compatible properties, which should be 
> > used in addition to the
> >  
> >  - vdd-supply: phandle of the regulator that provides the supply voltage.
> >  - post-power-on-delay-ms: time required by the device after enabling its 
> > regulators
> > -  before it is ready for communication. Must be used with 'vdd-supply'.
> > +  or deassert reset pin before it is ready for communication.
> > +- reset: phandle of the gpio that provides for hid reset pin.
> 
> The kernel api takes "reset", but the property is "reset-gpios".

In the same way the generic regulator interface handles vdd-supply, is
there any generic OF handling of reset lines? As far as I can tell,
there are 97 references of reset-gpios in my tree, and I wonder if all
the matching drivers need to rewrite the same code to set the reset line
on power on/off.

I am worried because here, 1/2 writes "arbitrary" 0 and 1 to the gpios,
and nothing prevent a manufacturer to invert the required voltages on
the reset lines, meaning there will be a need for a new OF property.

Cheers,
Benjamin

> 
> And it's not just a phandle typically.
> 
> > +- assert-reset-us: the device require reset assert time.
> >  
> >  Example:
> >  
> > -- 
> > 2.7.4
> > 

Re: [PATCH 2/3] HID: cp2112: add HIDRAW dependency

[Benjamin Tissoires]

On Nov 02 2017 or thereabouts, Sébastien Szymanski wrote:
> Otherwise, with HIDRAW=n, the probe function crashes because of null
> dereference of hdev->hidraw.
> 
> Fixes: 42cb6b35b9e6 ("HID: cp2112: use proper hidraw name with minor number")
> Signed-off-by: Sébastien Szymanski <sebastien.szyman...@armadeus.com>

Patches 1 and 2 (only) are:
Acked-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

> ---
>  drivers/hid/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 374301f..8c7a0ce 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -230,7 +230,7 @@ config HID_CMEDIA
>  
>  config HID_CP2112
>   tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
> - depends on USB_HID && I2C && GPIOLIB
> + depends on USB_HID && HIDRAW && I2C && GPIOLIB
>   select GPIOLIB_IRQCHIP
>   ---help---
>   Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
> -- 
> 2.7.3
> 

Re: [PATCH 2/3] HID: cp2112: add HIDRAW dependency

[Benjamin Tissoires]

On Nov 02 2017 or thereabouts, Sébastien Szymanski wrote:
> Otherwise, with HIDRAW=n, the probe function crashes because of null
> dereference of hdev->hidraw.
> 
> Fixes: 42cb6b35b9e6 ("HID: cp2112: use proper hidraw name with minor number")
> Signed-off-by: Sébastien Szymanski 

Patches 1 and 2 (only) are:
Acked-by: Benjamin Tissoires 

> ---
>  drivers/hid/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 374301f..8c7a0ce 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -230,7 +230,7 @@ config HID_CMEDIA
>  
>  config HID_CP2112
>   tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
> - depends on USB_HID && I2C && GPIOLIB
> + depends on USB_HID && HIDRAW && I2C && GPIOLIB
>   select GPIOLIB_IRQCHIP
>   ---help---
>   Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
> -- 
> 2.7.3
> 

Re: [PATCH 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Benjamin Tissoires]

On Nov 02 2017 or thereabouts, Sébastien Szymanski wrote:
> When everything goes smoothly, ret is set to 0 which makes the function
> to return EIO error.
> 
> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> Signed-off-by: Sébastien Szymanski 
> ---
>  drivers/hid/hid-cp2112.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 28e3c18..f7754a6 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -205,12 +205,13 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>   ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
>CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
>HID_REQ_SET_REPORT);
> - if (ret < 0) {
> + if (ret != CP2112_GPIO_CONFIG_LENGTH) {

Ack for this.

>   hid_err(hdev, "error setting GPIO config: %d\n", ret);
>   goto exit;
>   }
>  
> - ret = 0;
> + mutex_unlock(>lock);
> + return 0;

Wouldn't it be better to just turn
- return ret < 0 ? ret : -EIO;
into
+ return ret <= 0 ? ret : -EIO;
at the end of the function?

I'd rather keep the same exit path in both cases, error or success.

Cheers,
Benjamin


>  
>  exit:
>   mutex_unlock(>lock);
> -- 
> 2.7.3
> 

Re: [PATCH 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Benjamin Tissoires]

On Nov 02 2017 or thereabouts, Sébastien Szymanski wrote:
> When everything goes smoothly, ret is set to 0 which makes the function
> to return EIO error.
> 
> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> Signed-off-by: Sébastien Szymanski 
> ---
>  drivers/hid/hid-cp2112.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 28e3c18..f7754a6 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -205,12 +205,13 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>   ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
>CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
>HID_REQ_SET_REPORT);
> - if (ret < 0) {
> + if (ret != CP2112_GPIO_CONFIG_LENGTH) {

Ack for this.

>   hid_err(hdev, "error setting GPIO config: %d\n", ret);
>   goto exit;
>   }
>  
> - ret = 0;
> + mutex_unlock(>lock);
> + return 0;

Wouldn't it be better to just turn
- return ret < 0 ? ret : -EIO;
into
+ return ret <= 0 ? ret : -EIO;
at the end of the function?

I'd rather keep the same exit path in both cases, error or success.

Cheers,
Benjamin


>  
>  exit:
>   mutex_unlock(>lock);
> -- 
> 2.7.3
> 

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

[Benjamin Tissoires]

Hi Jason,

On Nov 03 2017 or thereabouts, Jason Gerecke wrote:
> On November 3, 2017 10:29:47 AM PDT, Benjamin Tissoires 
> <benjamin.tissoi...@redhat.com> wrote:
> >The Dell Canvas exports 2 collections for the Pen part. The only
> >difference between the 2 is that the default one has half the
> >resolution
> >of the second one.
> >
> >The Windows driver switches the tablet into the second mode, so we
> >should
> >behave the same.
> >
> >Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> >---
> >
> >Hi,
> >
> >well, this is not the cleanest way of handling this mode set, but it is
> >the
> >less intrusive AFAICT.
> >
> >I was thinking that we might want to add a new field in struct
> >wacom_feature,
> >but then it wouldn't make sense to keep the set mode specifics in
> >_wacom_query_tablet_data().
> >
> >So I am open to any better suggestion, but this one works and the
> >impact on
> >other HID generic tablets is null.
> >
> 
> Hmm. Agreed that this isn't ideal. I'd like to take a look at the descriptor, 
> if you wouldn't mind sharing it. The hardware should be similar to other 
> devices of ours and it might be possible to piggyback on existing code.
>

Sure, here it comes in the hid-replay format (and with a recording
of a single dot from the pen):

Cheers,
Benjamin

---

D: 0
R: 373 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 95 02 
75 01 81 02 95 01 75 06 81 03 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 
c0 c0 05 0d 09 02 a1 01 85 02 09 20 a1 00 09 42 09 44 09 45 09 3c 09 5a 09 32 
15 00 25 01 75 01 95 06 81 02 95 02 81 03 05 01 09 30 27 8d 74 00 00 47 1a e9 
00 00 65 11 55 0d 75 10 95 01 81 02 09 31 27 8f 41 00 00 47 1e 83 00 00 81 02 
45 00 65 00 55 00 05 0d 09 30 26 ff 0f 81 02 06 00 ff 09 04 75 08 26 ff 00 46 
ff 00 65 11 55 0e 81 02 05 0d 09 3d 75 10 16 d8 dc 26 28 23 36 d8 dc 46 28 23 
65 14 81 02 09 3e 81 02 65 00 55 00 15 00 35 00 45 00 c0 09 00 75 08 26 ff 00 
b1 12 c0 06 00 ff 09 00 a1 01 85 11 05 0d 09 20 a1 00 09 42 09 44 09 45 09 3c 
09 5a 09 32 15 00 25 01 75 01 95 06 81 02 95 02 81 03 05 01 09 30 27 1a e9 00 
00 47 1a e9 00 00 65 11 55 0d 75 10 95 01 81 02 09 31 27 1e 83 00 00 47 1e 83 
00 00 81 02 45 00 65 00 55 00 05 0d 09 30 26 ff 0f 81 02 06 00 ff 09 04 75 08 
26 ff 00 46 ff 00 65 11 55 0e 81 02 05 0d 09 3d 75 10 16 d8 dc 26 28 23 36 d8 
dc 46 28 23 65 14 81 02 09 3e 81 02 65 00 55 00 15 00 35 00 45 00 c0 09 00 75 
08 26 ff 00 95 03 b1 12 c0 05 01
N: Tablet ISD-V4
P: usb-:39:00.0-1.5/input0
I: 3 056a 4200
D: 0
E: 0.00 13 11 20 8b c8 35 47 00 00 24 00 00 00 00
E: 0.001027 13 11 20 8b c8 35 47 00 00 24 00 00 00 00
E: 0.002817 13 11 20 8b c8 35 47 00 00 22 00 00 00 00
E: 0.009885 13 11 20 8b c8 35 47 00 00 1f 00 00 00 00
E: 0.012881 13 11 20 8b c8 35 47 00 00 1b 00 00 00 00
E: 0.019914 13 11 20 96 c8 25 47 00 00 17 00 00 00 00
E: 0.022898 13 11 20 ac c8 14 47 00 00 12 00 00 00 00
E: 0.029904 13 11 20 f6 c8 c6 46 00 00 0f 00 00 00 00
E: 0.032898 13 11 20 d1 c8 f6 46 00 00 0b 00 00 00 00
E: 0.038908 13 11 21 e2 c8 de 46 21 0b 07 b8 0b d4 fe
E: 0.042902 13 11 21 f3 c8 c7 46 17 0b 04 b8 0b d4 fe
E: 0.048946 13 11 21 f3 c8 c7 46 f3 0a 04 b8 0b d4 fe
E: 0.052928 13 11 21 f3 c8 c7 46 d2 0a 04 b8 0b d4 fe
E: 0.058924 13 11 21 f3 c8 c7 46 a0 0a 02 b8 0b d4 fe
E: 0.062923 13 11 21 f3 c8 c7 46 60 0a 01 b8 0b d4 fe
E: 0.068904 13 11 21 f3 c8 c7 46 1d 0a 00 b8 0b d4 fe
E: 0.072901 13 11 21 f3 c8 c7 46 cd 09 00 b8 0b d4 fe
E: 0.078900 13 11 21 f3 c8 c7 46 8a 09 00 b8 0b d4 fe
E: 0.082900 13 11 21 f3 c8 c7 46 3c 09 00 b8 0b d4 fe
E: 0.088905 13 11 21 f3 c8 c7 46 ae 08 00 b8 0b d4 fe
E: 0.092904 13 11 21 06 c9 c4 46 e2 07 00 b8 0b d4 fe
E: 0.098904 13 11 21 18 c9 bd 46 89 06 00 b8 0b d4 fe
E: 0.102910 13 11 21 24 c9 ad 46 5e 03 00 b8 0b d4 fe
E: 0.108910 13 11 20 24 c9 ad 46 00 00 00 00 00 00 00
E: 0.109899 13 11 20 31 c9 9c 46 00 00 00 00 00 00 00
E: 0.112897 13 11 20 3a c9 8a 46 00 00 01 00 00 00 00
E: 0.118901 13 11 20 44 c9 79 46 00 00 01 00 00 00 00
E: 0.122902 13 11 20 42 c9 69 46 00 00 03 00 00 00 00
E: 0.128926 13 11 20 40 c9 5a 46 00 00 05 00 00 00 00
E: 0.132923 13 11 20 40 c9 5a 46 00 00 09 00 00 00 00
E: 0.138927 13 11 20 30 c9 54 46 00 00 10 00 00 00 00
E: 0.142922 13 11 20 0c c9 4f 46 00 00 1a 00 00 00 00
E: 0.148904 13 11 20 d4 c8 4c 46 00 00 25 00 00 00 00
E: 0.152902 13 11 20 8d c8 4b 46 00 00 32 00 00 00 00
E: 0.158911 13 11 20 36 c8 4b 46 00 00 42 00 00 00 00
E: 0.162897 13 11 20 f0 c7 4b 46 00 00 4a 00 00 00 00
E: 0.168907 13 11 20 b1 c7 4c 46 00 00 53 00 00 00 00
E: 0.172899 13 11 20 75 c7 4d 46 00 00 5c 00 00 00 00
E: 0.178893 13 11 20 3a c7 4f 46 00 00 65 00 00 00 00
E: 0.182887 13 11 20 fc c6 51 46 00 00 6f 00 00 00 00
E: 0.188912 13 11 20 bd c6 52 46 00 00 6f 00 00 00 00
E: 0.191923 13 11 20 81 c6 53 46 00 00 6f 00 00 00 00
E: 0.198924 13 11 20 47 c6 55 46 00 00 6f 00 00 00 00
E: 0.201925 13 11 20 11 c6 56 46 00 00 6f 00 00 00 00
E: 0.208907 13 11 00 11 c6 56 46 00 00 6f 00 00 00 00
 

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

[Benjamin Tissoires]

Hi Jason,

On Nov 03 2017 or thereabouts, Jason Gerecke wrote:
> On November 3, 2017 10:29:47 AM PDT, Benjamin Tissoires 
>  wrote:
> >The Dell Canvas exports 2 collections for the Pen part. The only
> >difference between the 2 is that the default one has half the
> >resolution
> >of the second one.
> >
> >The Windows driver switches the tablet into the second mode, so we
> >should
> >behave the same.
> >
> >Signed-off-by: Benjamin Tissoires 
> >---
> >
> >Hi,
> >
> >well, this is not the cleanest way of handling this mode set, but it is
> >the
> >less intrusive AFAICT.
> >
> >I was thinking that we might want to add a new field in struct
> >wacom_feature,
> >but then it wouldn't make sense to keep the set mode specifics in
> >_wacom_query_tablet_data().
> >
> >So I am open to any better suggestion, but this one works and the
> >impact on
> >other HID generic tablets is null.
> >
> 
> Hmm. Agreed that this isn't ideal. I'd like to take a look at the descriptor, 
> if you wouldn't mind sharing it. The hardware should be similar to other 
> devices of ours and it might be possible to piggyback on existing code.
>

Sure, here it comes in the hid-replay format (and with a recording
of a single dot from the pen):

Cheers,
Benjamin

---

D: 0
R: 373 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 95 02 
75 01 81 02 95 01 75 06 81 03 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 
c0 c0 05 0d 09 02 a1 01 85 02 09 20 a1 00 09 42 09 44 09 45 09 3c 09 5a 09 32 
15 00 25 01 75 01 95 06 81 02 95 02 81 03 05 01 09 30 27 8d 74 00 00 47 1a e9 
00 00 65 11 55 0d 75 10 95 01 81 02 09 31 27 8f 41 00 00 47 1e 83 00 00 81 02 
45 00 65 00 55 00 05 0d 09 30 26 ff 0f 81 02 06 00 ff 09 04 75 08 26 ff 00 46 
ff 00 65 11 55 0e 81 02 05 0d 09 3d 75 10 16 d8 dc 26 28 23 36 d8 dc 46 28 23 
65 14 81 02 09 3e 81 02 65 00 55 00 15 00 35 00 45 00 c0 09 00 75 08 26 ff 00 
b1 12 c0 06 00 ff 09 00 a1 01 85 11 05 0d 09 20 a1 00 09 42 09 44 09 45 09 3c 
09 5a 09 32 15 00 25 01 75 01 95 06 81 02 95 02 81 03 05 01 09 30 27 1a e9 00 
00 47 1a e9 00 00 65 11 55 0d 75 10 95 01 81 02 09 31 27 1e 83 00 00 47 1e 83 
00 00 81 02 45 00 65 00 55 00 05 0d 09 30 26 ff 0f 81 02 06 00 ff 09 04 75 08 
26 ff 00 46 ff 00 65 11 55 0e 81 02 05 0d 09 3d 75 10 16 d8 dc 26 28 23 36 d8 
dc 46 28 23 65 14 81 02 09 3e 81 02 65 00 55 00 15 00 35 00 45 00 c0 09 00 75 
08 26 ff 00 95 03 b1 12 c0 05 01
N: Tablet ISD-V4
P: usb-:39:00.0-1.5/input0
I: 3 056a 4200
D: 0
E: 0.00 13 11 20 8b c8 35 47 00 00 24 00 00 00 00
E: 0.001027 13 11 20 8b c8 35 47 00 00 24 00 00 00 00
E: 0.002817 13 11 20 8b c8 35 47 00 00 22 00 00 00 00
E: 0.009885 13 11 20 8b c8 35 47 00 00 1f 00 00 00 00
E: 0.012881 13 11 20 8b c8 35 47 00 00 1b 00 00 00 00
E: 0.019914 13 11 20 96 c8 25 47 00 00 17 00 00 00 00
E: 0.022898 13 11 20 ac c8 14 47 00 00 12 00 00 00 00
E: 0.029904 13 11 20 f6 c8 c6 46 00 00 0f 00 00 00 00
E: 0.032898 13 11 20 d1 c8 f6 46 00 00 0b 00 00 00 00
E: 0.038908 13 11 21 e2 c8 de 46 21 0b 07 b8 0b d4 fe
E: 0.042902 13 11 21 f3 c8 c7 46 17 0b 04 b8 0b d4 fe
E: 0.048946 13 11 21 f3 c8 c7 46 f3 0a 04 b8 0b d4 fe
E: 0.052928 13 11 21 f3 c8 c7 46 d2 0a 04 b8 0b d4 fe
E: 0.058924 13 11 21 f3 c8 c7 46 a0 0a 02 b8 0b d4 fe
E: 0.062923 13 11 21 f3 c8 c7 46 60 0a 01 b8 0b d4 fe
E: 0.068904 13 11 21 f3 c8 c7 46 1d 0a 00 b8 0b d4 fe
E: 0.072901 13 11 21 f3 c8 c7 46 cd 09 00 b8 0b d4 fe
E: 0.078900 13 11 21 f3 c8 c7 46 8a 09 00 b8 0b d4 fe
E: 0.082900 13 11 21 f3 c8 c7 46 3c 09 00 b8 0b d4 fe
E: 0.088905 13 11 21 f3 c8 c7 46 ae 08 00 b8 0b d4 fe
E: 0.092904 13 11 21 06 c9 c4 46 e2 07 00 b8 0b d4 fe
E: 0.098904 13 11 21 18 c9 bd 46 89 06 00 b8 0b d4 fe
E: 0.102910 13 11 21 24 c9 ad 46 5e 03 00 b8 0b d4 fe
E: 0.108910 13 11 20 24 c9 ad 46 00 00 00 00 00 00 00
E: 0.109899 13 11 20 31 c9 9c 46 00 00 00 00 00 00 00
E: 0.112897 13 11 20 3a c9 8a 46 00 00 01 00 00 00 00
E: 0.118901 13 11 20 44 c9 79 46 00 00 01 00 00 00 00
E: 0.122902 13 11 20 42 c9 69 46 00 00 03 00 00 00 00
E: 0.128926 13 11 20 40 c9 5a 46 00 00 05 00 00 00 00
E: 0.132923 13 11 20 40 c9 5a 46 00 00 09 00 00 00 00
E: 0.138927 13 11 20 30 c9 54 46 00 00 10 00 00 00 00
E: 0.142922 13 11 20 0c c9 4f 46 00 00 1a 00 00 00 00
E: 0.148904 13 11 20 d4 c8 4c 46 00 00 25 00 00 00 00
E: 0.152902 13 11 20 8d c8 4b 46 00 00 32 00 00 00 00
E: 0.158911 13 11 20 36 c8 4b 46 00 00 42 00 00 00 00
E: 0.162897 13 11 20 f0 c7 4b 46 00 00 4a 00 00 00 00
E: 0.168907 13 11 20 b1 c7 4c 46 00 00 53 00 00 00 00
E: 0.172899 13 11 20 75 c7 4d 46 00 00 5c 00 00 00 00
E: 0.178893 13 11 20 3a c7 4f 46 00 00 65 00 00 00 00
E: 0.182887 13 11 20 fc c6 51 46 00 00 6f 00 00 00 00
E: 0.188912 13 11 20 bd c6 52 46 00 00 6f 00 00 00 00
E: 0.191923 13 11 20 81 c6 53 46 00 00 6f 00 00 00 00
E: 0.198924 13 11 20 47 c6 55 46 00 00 6f 00 00 00 00
E: 0.201925 13 11 20 11 c6 56 46 00 00 6f 00 00 00 00
E: 0.208907 13 11 00 11 c6 56 46 00 00 6f 00 00 00 00
 

[PATCH] HID: Wacom: switch Dell canvas into highres mode

[Benjamin Tissoires]

The Dell Canvas exports 2 collections for the Pen part. The only
difference between the 2 is that the default one has half the resolution
of the second one.

The Windows driver switches the tablet into the second mode, so we should
behave the same.

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
---

Hi,

well, this is not the cleanest way of handling this mode set, but it is the
less intrusive AFAICT.

I was thinking that we might want to add a new field in struct wacom_feature,
but then it wouldn't make sense to keep the set mode specifics in
_wacom_query_tablet_data().

So I am open to any better suggestion, but this one works and the impact on
other HID generic tablets is null.

Cheers,
Benjamin

 drivers/hid/wacom_sys.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 906e654fb0ba..ee71ad9b6cc1 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -196,6 +196,13 @@ static void wacom_feature_mapping(struct hid_device *hdev,
kfree(data);
break;
}
+
+   if (hdev->vendor == USB_VENDOR_ID_WACOM &&
+   hdev->product == 0x4200 /* Dell Canvas 27 */ &&
+   field->application == HID_UP_MSVENDOR) {
+   wacom->wacom_wac.mode_report = field->report->id;
+   wacom->wacom_wac.mode_value = 2;
+   }
 }
 
 /*
-- 
2.14.3

[PATCH] HID: Wacom: switch Dell canvas into highres mode

[Benjamin Tissoires]

The Dell Canvas exports 2 collections for the Pen part. The only
difference between the 2 is that the default one has half the resolution
of the second one.

The Windows driver switches the tablet into the second mode, so we should
behave the same.

Signed-off-by: Benjamin Tissoires 
---

Hi,

well, this is not the cleanest way of handling this mode set, but it is the
less intrusive AFAICT.

I was thinking that we might want to add a new field in struct wacom_feature,
but then it wouldn't make sense to keep the set mode specifics in
_wacom_query_tablet_data().

So I am open to any better suggestion, but this one works and the impact on
other HID generic tablets is null.

Cheers,
Benjamin

 drivers/hid/wacom_sys.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 906e654fb0ba..ee71ad9b6cc1 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -196,6 +196,13 @@ static void wacom_feature_mapping(struct hid_device *hdev,
kfree(data);
break;
}
+
+   if (hdev->vendor == USB_VENDOR_ID_WACOM &&
+   hdev->product == 0x4200 /* Dell Canvas 27 */ &&
+   field->application == HID_UP_MSVENDOR) {
+   wacom->wacom_wac.mode_report = field->report->id;
+   wacom->wacom_wac.mode_value = 2;
+   }
 }
 
 /*
-- 
2.14.3

Re: [PATCH] Input: synaptics-rmi4: Limit the range of what GPIOs are buttons

[Benjamin Tissoires]

On Oct 24 2017 or thereabouts, Andrew Duggan wrote:
> By convention the first 6 bits of F30 Ctrl 2 and 3 are used to signify

I really do not like the "by convention". What if future firmware
developers are willing to add extra buttons and already have trackstick
buttons there, meaning the max 6 button count will be blown up? :/

Still, there is not much we can do (or have a whitelist, but it is a
pain), so:
Acked-By: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> GPIOs which are connected to buttons. Additional GPIOs may be used as
> input GPIOs to signal the touch controller of some event
> (ie disable touchpad). These additional GPIOs may meet the criteria of
> a button in rmi_f30_is_valid_button() but should not be considered
> buttons. This patch limits the GPIOs which are mapped to buttons to just
> the first 6.
> 
> Signed-off-by: Andrew Duggan <adug...@synaptics.com>
> Reported-by: Daniel Martin <consume.no...@gmail.com>
> ---
> I think that this patch will fix the issue with the Lenovo X1 Cover not
> being set as a buttonpad. Based on the firmware config for this touchpad
> there are additional GPIOs in Ctrl 2 and 3 position 6 and 7 unrelated to
> buttons. This is confusing F30 into thinking there are additional buttons.
> 
> https://www.spinics.net/lists/linux-input/msg53626.html
> 
>  drivers/input/rmi4/rmi_f30.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
> index 34dfee5..a8ed424 100644
> --- a/drivers/input/rmi4/rmi_f30.c
> +++ b/drivers/input/rmi4/rmi_f30.c
> @@ -232,9 +232,11 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
>   unsigned int trackstick_button = BTN_LEFT;
>   bool button_mapped = false;
>   int i;
> + int button_count = f30->gpioled_count > TRACKSTICK_RANGE_END
> + ? TRACKSTICK_RANGE_END : f30->gpioled_count;
>  
>   f30->gpioled_key_map = devm_kcalloc(>dev,
> - f30->gpioled_count,
> + button_count,
>   sizeof(f30->gpioled_key_map[0]),
>   GFP_KERNEL);
>   if (!f30->gpioled_key_map) {
> @@ -242,7 +244,7 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
>   return -ENOMEM;
>   }
>  
> - for (i = 0; i < f30->gpioled_count; i++) {
> + for (i = 0; i < button_count; i++) {
>   if (!rmi_f30_is_valid_button(i, f30->ctrl))
>   continue;
>  
> -- 
> 2.7.4
> 

Re: [PATCH] Input: synaptics-rmi4: Limit the range of what GPIOs are buttons

[Benjamin Tissoires]

On Oct 24 2017 or thereabouts, Andrew Duggan wrote:
> By convention the first 6 bits of F30 Ctrl 2 and 3 are used to signify

I really do not like the "by convention". What if future firmware
developers are willing to add extra buttons and already have trackstick
buttons there, meaning the max 6 button count will be blown up? :/

Still, there is not much we can do (or have a whitelist, but it is a
pain), so:
Acked-By: Benjamin Tissoires 

Cheers,
Benjamin

> GPIOs which are connected to buttons. Additional GPIOs may be used as
> input GPIOs to signal the touch controller of some event
> (ie disable touchpad). These additional GPIOs may meet the criteria of
> a button in rmi_f30_is_valid_button() but should not be considered
> buttons. This patch limits the GPIOs which are mapped to buttons to just
> the first 6.
> 
> Signed-off-by: Andrew Duggan 
> Reported-by: Daniel Martin 
> ---
> I think that this patch will fix the issue with the Lenovo X1 Cover not
> being set as a buttonpad. Based on the firmware config for this touchpad
> there are additional GPIOs in Ctrl 2 and 3 position 6 and 7 unrelated to
> buttons. This is confusing F30 into thinking there are additional buttons.
> 
> https://www.spinics.net/lists/linux-input/msg53626.html
> 
>  drivers/input/rmi4/rmi_f30.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
> index 34dfee5..a8ed424 100644
> --- a/drivers/input/rmi4/rmi_f30.c
> +++ b/drivers/input/rmi4/rmi_f30.c
> @@ -232,9 +232,11 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
>   unsigned int trackstick_button = BTN_LEFT;
>   bool button_mapped = false;
>   int i;
> + int button_count = f30->gpioled_count > TRACKSTICK_RANGE_END
> + ? TRACKSTICK_RANGE_END : f30->gpioled_count;
>  
>   f30->gpioled_key_map = devm_kcalloc(>dev,
> - f30->gpioled_count,
> + button_count,
>   sizeof(f30->gpioled_key_map[0]),
>   GFP_KERNEL);
>   if (!f30->gpioled_key_map) {
> @@ -242,7 +244,7 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
>   return -ENOMEM;
>   }
>  
> - for (i = 0; i < f30->gpioled_count; i++) {
> + for (i = 0; i < button_count; i++) {
>   if (!rmi_f30_is_valid_button(i, f30->ctrl))
>   continue;
>  
> -- 
> 2.7.4
> 

Re: [PATCH] HID: hidraw: Improve a size determination in two functions

[Benjamin Tissoires]

On Oct 24 2017 or thereabouts, SF Markus Elfring wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Tue, 24 Oct 2017 20:52:19 +0200
> 
> * Replace the specification of data structures by pointer dereferences
>   as the parameter for the operator "sizeof" to make the corresponding size
>   determination a bit safer according to the Linux coding style convention.
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Return directly after a call of the function "kzalloc" failed
>   at the beginning of the function "hidraw_open".
> 
> * Delete the jump target "out" which became unnecessary
>   with this refactoring.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/hid/hidraw.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
> index 5fbe0f81ab2e..26fbf9e82f84 100644
> --- a/drivers/hid/hidraw.c
> +++ b/drivers/hid/hidraw.c
> @@ -269,10 +269,9 @@ static int hidraw_open(struct inode *inode, struct file 
> *file)
>   unsigned long flags;
>   int err = 0;
>  
> - if (!(list = kzalloc(sizeof(struct hidraw_list), GFP_KERNEL))) {
> - err = -ENOMEM;
> - goto out;
> - }
> + list = kzalloc(sizeof(*list), GFP_KERNEL);

I am not sure the change from "if (!a = kzalloc())" to "a = kzalloc();
if (!a)" adds anything besides clearer code. I prefer the later, so:

Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> + if (!list)
> + return -ENOMEM;
>  
>   mutex_lock(_lock);
>   if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
> @@ -304,7 +303,6 @@ static int hidraw_open(struct inode *inode, struct file 
> *file)
>   file->private_data = list;
>  out_unlock:
>   mutex_unlock(_lock);
> -out:
>   if (err < 0)
>   kfree(list);
>   return err;
> @@ -513,7 +511,7 @@ int hidraw_connect(struct hid_device *hid)
>  
>   /* we accept any HID device, all applications */
>  
> - dev = kzalloc(sizeof(struct hidraw), GFP_KERNEL);
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>   if (!dev)
>   return -ENOMEM;
>  
> -- 
> 2.14.3
> 

Re: [PATCH] HID: hidraw: Improve a size determination in two functions

[Benjamin Tissoires]

On Oct 24 2017 or thereabouts, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 24 Oct 2017 20:52:19 +0200
> 
> * Replace the specification of data structures by pointer dereferences
>   as the parameter for the operator "sizeof" to make the corresponding size
>   determination a bit safer according to the Linux coding style convention.
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Return directly after a call of the function "kzalloc" failed
>   at the beginning of the function "hidraw_open".
> 
> * Delete the jump target "out" which became unnecessary
>   with this refactoring.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/hid/hidraw.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
> index 5fbe0f81ab2e..26fbf9e82f84 100644
> --- a/drivers/hid/hidraw.c
> +++ b/drivers/hid/hidraw.c
> @@ -269,10 +269,9 @@ static int hidraw_open(struct inode *inode, struct file 
> *file)
>   unsigned long flags;
>   int err = 0;
>  
> - if (!(list = kzalloc(sizeof(struct hidraw_list), GFP_KERNEL))) {
> - err = -ENOMEM;
> - goto out;
> - }
> + list = kzalloc(sizeof(*list), GFP_KERNEL);

I am not sure the change from "if (!a = kzalloc())" to "a = kzalloc();
if (!a)" adds anything besides clearer code. I prefer the later, so:

Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

> + if (!list)
> + return -ENOMEM;
>  
>   mutex_lock(_lock);
>   if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
> @@ -304,7 +303,6 @@ static int hidraw_open(struct inode *inode, struct file 
> *file)
>   file->private_data = list;
>  out_unlock:
>   mutex_unlock(_lock);
> -out:
>   if (err < 0)
>   kfree(list);
>   return err;
> @@ -513,7 +511,7 @@ int hidraw_connect(struct hid_device *hid)
>  
>   /* we accept any HID device, all applications */
>  
> - dev = kzalloc(sizeof(struct hidraw), GFP_KERNEL);
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>   if (!dev)
>   return -ENOMEM;
>  
> -- 
> 2.14.3
> 

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

[Benjamin Tissoires]

On Oct 18 2017 or thereabouts, Andrew Duggan wrote:
> 
> 
> On 10/18/2017 07:13 AM, Jiri Kosina wrote:
> > On Wed, 18 Oct 2017, Benjamin Tissoires wrote:
> > 
> > > > The hid-rmi driver may handle non rmi devices on composite USB devices.
> > > > Callbacks need to make sure that the current device is a RMI device 
> > > > before
> > > > calling RMI specific functions. Most callbacks already have this check, 
> > > > but
> > > > this patch adds checks to the remaining callbacks.
> > > > 
> > > > Signed-off-by: Andrew Duggan <adug...@synaptics.com>
> > > > ---
> > > > This is the patch which hopefully will address the X1 tablet dock 
> > > > freeze:
> > > > http://www.spinics.net/lists/linux-input/msg53582.html
> > > > 
> > > > I was not able to test on a composite USB device so I have not tested 
> > > > confirmed
> > > > this will fix the reported issues. But, based on the description I 
> > > > think it will.
> > > > I also added a check for rmi_raw_event() since it could be possible 
> > > > that another
> > > > hid device using one of the same report IDs as an RMI device could 
> > > > result in calling
> > > > into unitialized RMI functions. It was also the only callbacl left not 
> > > > checking the
> > > > RMI_DEVICE flag. I wonder if this explains the attach crash.
> > > > 
> > > > Anyway, I would appriciate it if Hendrik or someone else with the 
> > > > device could test this
> > > > patch to confirm it fixes the reported behavior.
> > > Shouldn't rmi_hid_reset() also get the same check?
> > I think so as well.
> 
> Since rmi_hid_reset() is only called from with in the RMI4 driver I didn't
> think that it needed a check. All of the functions set in struct hid_driver
> should  now check the RMI_DEVICE flag before calling into the RMI4 driver.
> But, if I am missing something we can add additional checks.

Oh, right, you are correct. I didn't paid enough attention and
overlooked the fact that this function was set in struct
rmi_transport_ops only.

Given Hendrick's Tested-by came in as well (thanks for the quick
tests!), this is:
Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> 
> Thanks,
> Andrew
> 
> > >  From what I can see, even if the patch doesn't fix the immediate issue,
> > > such a patch should definitively go in as those checks are clearly
> > > missing.
> > Agreed; however I'd like to get Hendrik's Tested-by: if possible in case
> > this really fixes the issue, so I am not merging it right away.
> > 
> > Hendrik, are you by any chance able to test this patch in a reasonable
> > timeframe please?
> > 
> > Thanks!
> > 
> 

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

[Benjamin Tissoires]

On Oct 18 2017 or thereabouts, Andrew Duggan wrote:
> 
> 
> On 10/18/2017 07:13 AM, Jiri Kosina wrote:
> > On Wed, 18 Oct 2017, Benjamin Tissoires wrote:
> > 
> > > > The hid-rmi driver may handle non rmi devices on composite USB devices.
> > > > Callbacks need to make sure that the current device is a RMI device 
> > > > before
> > > > calling RMI specific functions. Most callbacks already have this check, 
> > > > but
> > > > this patch adds checks to the remaining callbacks.
> > > > 
> > > > Signed-off-by: Andrew Duggan 
> > > > ---
> > > > This is the patch which hopefully will address the X1 tablet dock 
> > > > freeze:
> > > > http://www.spinics.net/lists/linux-input/msg53582.html
> > > > 
> > > > I was not able to test on a composite USB device so I have not tested 
> > > > confirmed
> > > > this will fix the reported issues. But, based on the description I 
> > > > think it will.
> > > > I also added a check for rmi_raw_event() since it could be possible 
> > > > that another
> > > > hid device using one of the same report IDs as an RMI device could 
> > > > result in calling
> > > > into unitialized RMI functions. It was also the only callbacl left not 
> > > > checking the
> > > > RMI_DEVICE flag. I wonder if this explains the attach crash.
> > > > 
> > > > Anyway, I would appriciate it if Hendrik or someone else with the 
> > > > device could test this
> > > > patch to confirm it fixes the reported behavior.
> > > Shouldn't rmi_hid_reset() also get the same check?
> > I think so as well.
> 
> Since rmi_hid_reset() is only called from with in the RMI4 driver I didn't
> think that it needed a check. All of the functions set in struct hid_driver
> should  now check the RMI_DEVICE flag before calling into the RMI4 driver.
> But, if I am missing something we can add additional checks.

Oh, right, you are correct. I didn't paid enough attention and
overlooked the fact that this function was set in struct
rmi_transport_ops only.

Given Hendrick's Tested-by came in as well (thanks for the quick
tests!), this is:
Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

> 
> Thanks,
> Andrew
> 
> > >  From what I can see, even if the patch doesn't fix the immediate issue,
> > > such a patch should definitively go in as those checks are clearly
> > > missing.
> > Agreed; however I'd like to get Hendrik's Tested-by: if possible in case
> > this really fixes the issue, so I am not merging it right away.
> > 
> > Hendrik, are you by any chance able to test this patch in a reasonable
> > timeframe please?
> > 
> > Thanks!
> > 
> 

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

[Benjamin Tissoires]

On Oct 17 2017 or thereabouts, Andrew Duggan wrote:
> The hid-rmi driver may handle non rmi devices on composite USB devices.
> Callbacks need to make sure that the current device is a RMI device before
> calling RMI specific functions. Most callbacks already have this check, but
> this patch adds checks to the remaining callbacks.
> 
> Signed-off-by: Andrew Duggan 
> ---
> This is the patch which hopefully will address the X1 tablet dock freeze:
> http://www.spinics.net/lists/linux-input/msg53582.html
> 
> I was not able to test on a composite USB device so I have not tested 
> confirmed
> this will fix the reported issues. But, based on the description I think it 
> will.
> I also added a check for rmi_raw_event() since it could be possible that 
> another
> hid device using one of the same report IDs as an RMI device could result in 
> calling
> into unitialized RMI functions. It was also the only callbacl left not 
> checking the
> RMI_DEVICE flag. I wonder if this explains the attach crash.
> 
> Anyway, I would appriciate it if Hendrik or someone else with the device 
> could test this
> patch to confirm it fixes the reported behavior.

Shouldn't rmi_hid_reset() also get the same check?

>From what I can see, even if the patch doesn't fix the immediate issue,
such a patch should definitively go in as those checks are clearly
missing.

Cheers,
Benjamin

> 
> Thanks,
> Andrew
> 
>  drivers/hid/hid-rmi.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 5b40c26..d987e02 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -368,6 +368,11 @@ static int rmi_check_sanity(struct hid_device *hdev, u8 
> *data, int size)
>  static int rmi_raw_event(struct hid_device *hdev,
>   struct hid_report *report, u8 *data, int size)
>  {
> + struct rmi_data *hdata = hid_get_drvdata(hdev);
> +
> + if (!(hdata->device_flags & RMI_DEVICE))
> + return 0;
> +
>   size = rmi_check_sanity(hdev, data, size);
>   if (size < 2)
>   return 0;
> @@ -706,9 +711,11 @@ static void rmi_remove(struct hid_device *hdev)
>  {
>   struct rmi_data *hdata = hid_get_drvdata(hdev);
>  
> - clear_bit(RMI_STARTED, >flags);
> - cancel_work_sync(>reset_work);
> - rmi_unregister_transport_device(>xport);
> + if (hdata->device_flags & RMI_DEVICE) {
> + clear_bit(RMI_STARTED, >flags);
> + cancel_work_sync(>reset_work);
> + rmi_unregister_transport_device(>xport);
> + }
>  
>   hid_hw_stop(hdev);
>  }
> -- 
> 2.7.4
> 

Re: [PATCH] HID: rmi: Check that a device is a RMI device before calling RMI functions

[Benjamin Tissoires]

On Oct 17 2017 or thereabouts, Andrew Duggan wrote:
> The hid-rmi driver may handle non rmi devices on composite USB devices.
> Callbacks need to make sure that the current device is a RMI device before
> calling RMI specific functions. Most callbacks already have this check, but
> this patch adds checks to the remaining callbacks.
> 
> Signed-off-by: Andrew Duggan 
> ---
> This is the patch which hopefully will address the X1 tablet dock freeze:
> http://www.spinics.net/lists/linux-input/msg53582.html
> 
> I was not able to test on a composite USB device so I have not tested 
> confirmed
> this will fix the reported issues. But, based on the description I think it 
> will.
> I also added a check for rmi_raw_event() since it could be possible that 
> another
> hid device using one of the same report IDs as an RMI device could result in 
> calling
> into unitialized RMI functions. It was also the only callbacl left not 
> checking the
> RMI_DEVICE flag. I wonder if this explains the attach crash.
> 
> Anyway, I would appriciate it if Hendrik or someone else with the device 
> could test this
> patch to confirm it fixes the reported behavior.

Shouldn't rmi_hid_reset() also get the same check?

>From what I can see, even if the patch doesn't fix the immediate issue,
such a patch should definitively go in as those checks are clearly
missing.

Cheers,
Benjamin

> 
> Thanks,
> Andrew
> 
>  drivers/hid/hid-rmi.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 5b40c26..d987e02 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -368,6 +368,11 @@ static int rmi_check_sanity(struct hid_device *hdev, u8 
> *data, int size)
>  static int rmi_raw_event(struct hid_device *hdev,
>   struct hid_report *report, u8 *data, int size)
>  {
> + struct rmi_data *hdata = hid_get_drvdata(hdev);
> +
> + if (!(hdata->device_flags & RMI_DEVICE))
> + return 0;
> +
>   size = rmi_check_sanity(hdev, data, size);
>   if (size < 2)
>   return 0;
> @@ -706,9 +711,11 @@ static void rmi_remove(struct hid_device *hdev)
>  {
>   struct rmi_data *hdata = hid_get_drvdata(hdev);
>  
> - clear_bit(RMI_STARTED, >flags);
> - cancel_work_sync(>reset_work);
> - rmi_unregister_transport_device(>xport);
> + if (hdata->device_flags & RMI_DEVICE) {
> + clear_bit(RMI_STARTED, >flags);
> + cancel_work_sync(>reset_work);
> + rmi_unregister_transport_device(>xport);
> + }
>  
>   hid_hw_stop(hdev);
>  }
> -- 
> 2.7.4
> 

Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

On Oct 11 2017 or thereabouts, Jiri Kosina wrote:
> On Wed, 11 Oct 2017, Benjamin Tissoires wrote:
> 
> > I am not sure if libinput even uses ABS_MT_ORIENTATION
> 
> I don't think it does, so that should be okay. However ...

I had a meeting this Peter at noon today. The summary is that libinput
doesn't uses ABS_MT_ORIENTATION, and that the documentation requires
actually 3 things:
- 0 is Y-aligned, up ("north")
- maximum should be aligned with X, pointing toward the right ("east")
- negative and out of range values are allowed

>From this, we can conclude that the minimum doesn't matter, as long as
it is 0 or -max, it is the same from the user space point of view.

One thing that the documentation suggests is that if we report [0, max],
this would indicate that out of ranges values won't be triggered, and
[-max, max] would seem to indicate that the data might be negative and
so out of range values would be acceptable.

Anyway, no changes in any cases from userspace.

> 
> > , but I'd go for fixing the documentation. And re-reading it, it's not 
> > clear that the doc tells us to have [0,90]. It mentions negative values 
> > and out of ranges too, so we might just as well simply clarify that we 
> > rather have [-90,90], with 0 being "north".
> 
> ... I'd like the documentation fix to go in together in one go with this 
> patch if possible.
> 

Sounds like a plan.

Cheers,
Benjamin

> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

On Oct 11 2017 or thereabouts, Jiri Kosina wrote:
> On Wed, 11 Oct 2017, Benjamin Tissoires wrote:
> 
> > I am not sure if libinput even uses ABS_MT_ORIENTATION
> 
> I don't think it does, so that should be okay. However ...

I had a meeting this Peter at noon today. The summary is that libinput
doesn't uses ABS_MT_ORIENTATION, and that the documentation requires
actually 3 things:
- 0 is Y-aligned, up ("north")
- maximum should be aligned with X, pointing toward the right ("east")
- negative and out of range values are allowed

>From this, we can conclude that the minimum doesn't matter, as long as
it is 0 or -max, it is the same from the user space point of view.

One thing that the documentation suggests is that if we report [0, max],
this would indicate that out of ranges values won't be triggered, and
[-max, max] would seem to indicate that the data might be negative and
so out of range values would be acceptable.

Anyway, no changes in any cases from userspace.

> 
> > , but I'd go for fixing the documentation. And re-reading it, it's not 
> > clear that the doc tells us to have [0,90]. It mentions negative values 
> > and out of ranges too, so we might just as well simply clarify that we 
> > rather have [-90,90], with 0 being "north".
> 
> ... I'd like the documentation fix to go in together in one go with this 
> patch if possible.
> 

Sounds like a plan.

Cheers,
Benjamin

> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

On Oct 10 2017 or thereabouts, Dmitry Torokhov wrote:
> On Mon, Oct 9, 2017 at 11:57 PM, Henrik Rydberg  wrote:
> > Hi Wei-Ning,
> >
> >> The current hid-multitouch driver only allow the report of two
> >> orientations, vertical and horizontal. We use the Azimuth orientation
> >> usage 0x3F under the Digitizer usage page to report orientation if the
> >> device supports it.
> >>
> >> Changelog:
> >>   v1 -> v2:
> >>- Fix commit message.
> >>- Remove resolution reporting for ABS_MT_ORIENTATION.
> >>   v2 -> v3:
> >>- Fix commit message.
> >>   v3 -> v4:
> >>- Fix ABS_MT_ORIENTATION ABS param range.
> >>- Don't set ABS_MT_ORIENTATION in ABS_DG_HEIGHT when it is already
> >>  set by ABS_DG_AZIMUTH.
> >>
> >> Signed-off-by: Wei-Ning Huang 
> >> Reviewed-by: Dmitry Torokhov 
> >> ---
> >>  drivers/hid/hid-multitouch.c | 52 
> >> 
> >>  include/linux/hid.h  |  1 +
> >>  2 files changed, 49 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> >> index 440b999304a5..3317dae64ef7 100644
> >> --- a/drivers/hid/hid-multitouch.c
> >> +++ b/drivers/hid/hid-multitouch.c
> >> @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
> >>  #define MT_IO_FLAGS_PENDING_SLOTS2
> >>
> >>  struct mt_slot {
> >> - __s32 x, y, cx, cy, p, w, h;
> >> + __s32 x, y, cx, cy, p, w, h, a;
> >>   __s32 contactid;/* the device ContactID assigned to this 
> >> slot */
> >>   bool touch_state;   /* is the touch valid? */
> >>   bool inrange_state; /* is the finger in proximity of the sensor? 
> >> */
> >>   bool confidence_state;  /* is the touch made by a finger? */
> >> + bool has_azimuth;   /* the contact reports azimuth */
> >>  };
> >>
> >>  struct mt_class {
> >> @@ -571,8 +572,15 @@ static int mt_touch_input_mapping(struct hid_device 
> >> *hdev, struct hid_input *hi,
> >>   if (!(cls->quirks & MT_QUIRK_NO_AREA)) {
> >>   set_abs(hi->input, ABS_MT_TOUCH_MINOR, field,
> >>   cls->sn_height);
> >> - input_set_abs_params(hi->input,
> >> - ABS_MT_ORIENTATION, 0, 1, 0, 0);
> >> +
> >> + /*
> >> +  * Only set ABS_MT_ORIENTATION if it is not
> >> +  * already set by the HID_DG_AZIMUTH usage.
> >> +  */
> >> + if (!test_bit(ABS_MT_ORIENTATION,
> >> + hi->input->absbit))
> >> + input_set_abs_params(hi->input,
> >> + ABS_MT_ORIENTATION, 0, 1, 0, 
> >> 0);
> >>   }
> >>   mt_store_field(usage, td, hi);
> >>   return 1;
> >> @@ -591,6 +599,21 @@ static int mt_touch_input_mapping(struct hid_device 
> >> *hdev, struct hid_input *hi,
> >>   td->cc_index = field->index;
> >>   td->cc_value_index = usage->usage_index;
> >>   return 1;
> >> + case HID_DG_AZIMUTH:
> >> + hid_map_usage(hi, usage, bit, max,
> >> + EV_ABS, ABS_MT_ORIENTATION);
> >> + /*
> >> +  * Azimuth has the range of [0, MAX) representing a 
> >> full
> >> +  * revolution. Set ABS_MT_ORIENTATION to a quarter of
> >> +  * MAX according the definition of ABS_MT_ORIENTATION
> >> +  */
> >> + input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> >> + -field->logical_maximum / 4,
> >> + field->logical_maximum / 4,
> 
> 
> So do we expect userspace to have special handling for the range when
> "min" is negative? I.e. when range is [0,1] it is understood that we
> are reporting the first quadrant only, with 0 reported when finger is
> roughly vertical and 1 is when it is horizontal. Similarly, the range
> [0-90] would describe the 1st quadrant as well. This matches the
> in-kernel documentation. However here we have [-90, 90] that describes
> 2 quadrants. Do we want to keep it as is and have userspace adapt (we
> probably will need a patch to multi-touch-protocol.txt), or should

Actually, I requested the [-90, 90] change because the only other user
in the kernel I could find that support ABS_MT_ORIENTATION with a
different range than [0,1] was hid-magicmouse and it was not following
the documentation to the letter:
https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/tree/drivers/hid/hid-magicmouse.c?h=for-next#n411


After a deeper search, we have (reporting ABS_MT_ORIENTATION different
from 

Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

On Oct 10 2017 or thereabouts, Dmitry Torokhov wrote:
> On Mon, Oct 9, 2017 at 11:57 PM, Henrik Rydberg  wrote:
> > Hi Wei-Ning,
> >
> >> The current hid-multitouch driver only allow the report of two
> >> orientations, vertical and horizontal. We use the Azimuth orientation
> >> usage 0x3F under the Digitizer usage page to report orientation if the
> >> device supports it.
> >>
> >> Changelog:
> >>   v1 -> v2:
> >>- Fix commit message.
> >>- Remove resolution reporting for ABS_MT_ORIENTATION.
> >>   v2 -> v3:
> >>- Fix commit message.
> >>   v3 -> v4:
> >>- Fix ABS_MT_ORIENTATION ABS param range.
> >>- Don't set ABS_MT_ORIENTATION in ABS_DG_HEIGHT when it is already
> >>  set by ABS_DG_AZIMUTH.
> >>
> >> Signed-off-by: Wei-Ning Huang 
> >> Reviewed-by: Dmitry Torokhov 
> >> ---
> >>  drivers/hid/hid-multitouch.c | 52 
> >> 
> >>  include/linux/hid.h  |  1 +
> >>  2 files changed, 49 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> >> index 440b999304a5..3317dae64ef7 100644
> >> --- a/drivers/hid/hid-multitouch.c
> >> +++ b/drivers/hid/hid-multitouch.c
> >> @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
> >>  #define MT_IO_FLAGS_PENDING_SLOTS2
> >>
> >>  struct mt_slot {
> >> - __s32 x, y, cx, cy, p, w, h;
> >> + __s32 x, y, cx, cy, p, w, h, a;
> >>   __s32 contactid;/* the device ContactID assigned to this 
> >> slot */
> >>   bool touch_state;   /* is the touch valid? */
> >>   bool inrange_state; /* is the finger in proximity of the sensor? 
> >> */
> >>   bool confidence_state;  /* is the touch made by a finger? */
> >> + bool has_azimuth;   /* the contact reports azimuth */
> >>  };
> >>
> >>  struct mt_class {
> >> @@ -571,8 +572,15 @@ static int mt_touch_input_mapping(struct hid_device 
> >> *hdev, struct hid_input *hi,
> >>   if (!(cls->quirks & MT_QUIRK_NO_AREA)) {
> >>   set_abs(hi->input, ABS_MT_TOUCH_MINOR, field,
> >>   cls->sn_height);
> >> - input_set_abs_params(hi->input,
> >> - ABS_MT_ORIENTATION, 0, 1, 0, 0);
> >> +
> >> + /*
> >> +  * Only set ABS_MT_ORIENTATION if it is not
> >> +  * already set by the HID_DG_AZIMUTH usage.
> >> +  */
> >> + if (!test_bit(ABS_MT_ORIENTATION,
> >> + hi->input->absbit))
> >> + input_set_abs_params(hi->input,
> >> + ABS_MT_ORIENTATION, 0, 1, 0, 
> >> 0);
> >>   }
> >>   mt_store_field(usage, td, hi);
> >>   return 1;
> >> @@ -591,6 +599,21 @@ static int mt_touch_input_mapping(struct hid_device 
> >> *hdev, struct hid_input *hi,
> >>   td->cc_index = field->index;
> >>   td->cc_value_index = usage->usage_index;
> >>   return 1;
> >> + case HID_DG_AZIMUTH:
> >> + hid_map_usage(hi, usage, bit, max,
> >> + EV_ABS, ABS_MT_ORIENTATION);
> >> + /*
> >> +  * Azimuth has the range of [0, MAX) representing a 
> >> full
> >> +  * revolution. Set ABS_MT_ORIENTATION to a quarter of
> >> +  * MAX according the definition of ABS_MT_ORIENTATION
> >> +  */
> >> + input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> >> + -field->logical_maximum / 4,
> >> + field->logical_maximum / 4,
> 
> 
> So do we expect userspace to have special handling for the range when
> "min" is negative? I.e. when range is [0,1] it is understood that we
> are reporting the first quadrant only, with 0 reported when finger is
> roughly vertical and 1 is when it is horizontal. Similarly, the range
> [0-90] would describe the 1st quadrant as well. This matches the
> in-kernel documentation. However here we have [-90, 90] that describes
> 2 quadrants. Do we want to keep it as is and have userspace adapt (we
> probably will need a patch to multi-touch-protocol.txt), or should

Actually, I requested the [-90, 90] change because the only other user
in the kernel I could find that support ABS_MT_ORIENTATION with a
different range than [0,1] was hid-magicmouse and it was not following
the documentation to the letter:
https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/tree/drivers/hid/hid-magicmouse.c?h=for-next#n411


After a deeper search, we have (reporting ABS_MT_ORIENTATION different
from [0,1]):
drivers/hid/hid-magicmouse.c -> [-32,32]

Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

On Oct 10 2017 or thereabouts, Wei-Ning Huang wrote:
> From: Wei-Ning Huang <wnhu...@chromium.org>
> 
> The current hid-multitouch driver only allow the report of two
> orientations, vertical and horizontal. We use the Azimuth orientation
> usage 0x3F under the Digitizer usage page to report orientation if the
> device supports it.
> 
> Changelog:
>   v1 -> v2:
>- Fix commit message.
>- Remove resolution reporting for ABS_MT_ORIENTATION.
>   v2 -> v3:
>- Fix commit message.
>   v3 -> v4:
>- Fix ABS_MT_ORIENTATION ABS param range.
>- Don't set ABS_MT_ORIENTATION in ABS_DG_HEIGHT when it is already
>  set by ABS_DG_AZIMUTH.
> 
> Signed-off-by: Wei-Ning Huang <wnhu...@chromium.org>
> Reviewed-by: Dmitry Torokhov <d...@chromium.org>

Looks good now:
Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> ---
>  drivers/hid/hid-multitouch.c | 52 
> 
>  include/linux/hid.h  |  1 +
>  2 files changed, 49 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..3317dae64ef7 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
>  #define MT_IO_FLAGS_PENDING_SLOTS2
>  
>  struct mt_slot {
> - __s32 x, y, cx, cy, p, w, h;
> + __s32 x, y, cx, cy, p, w, h, a;
>   __s32 contactid;/* the device ContactID assigned to this slot */
>   bool touch_state;   /* is the touch valid? */
>   bool inrange_state; /* is the finger in proximity of the sensor? */
>   bool confidence_state;  /* is the touch made by a finger? */
> + bool has_azimuth;   /* the contact reports azimuth */
>  };
>  
>  struct mt_class {
> @@ -571,8 +572,15 @@ static int mt_touch_input_mapping(struct hid_device 
> *hdev, struct hid_input *hi,
>   if (!(cls->quirks & MT_QUIRK_NO_AREA)) {
>   set_abs(hi->input, ABS_MT_TOUCH_MINOR, field,
>   cls->sn_height);
> - input_set_abs_params(hi->input,
> - ABS_MT_ORIENTATION, 0, 1, 0, 0);
> +
> + /*
> +  * Only set ABS_MT_ORIENTATION if it is not
> +  * already set by the HID_DG_AZIMUTH usage.
> +  */
> + if (!test_bit(ABS_MT_ORIENTATION,
> + hi->input->absbit))
> + input_set_abs_params(hi->input,
> + ABS_MT_ORIENTATION, 0, 1, 0, 0);
>   }
>   mt_store_field(usage, td, hi);
>   return 1;
> @@ -591,6 +599,21 @@ static int mt_touch_input_mapping(struct hid_device 
> *hdev, struct hid_input *hi,
>   td->cc_index = field->index;
>   td->cc_value_index = usage->usage_index;
>   return 1;
> + case HID_DG_AZIMUTH:
> + hid_map_usage(hi, usage, bit, max,
> + EV_ABS, ABS_MT_ORIENTATION);
> + /*
> +  * Azimuth has the range of [0, MAX) representing a full
> +  * revolution. Set ABS_MT_ORIENTATION to a quarter of
> +  * MAX according the definition of ABS_MT_ORIENTATION
> +  */
> + input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> + -field->logical_maximum / 4,
> + field->logical_maximum / 4,
> + cls->sn_move ?
> + field->logical_maximum / cls->sn_move : 0, 0);
> + mt_store_field(usage, td, hi);
> + return 1;
>   case HID_DG_CONTACTMAX:
>   /* we don't set td->last_slot_field as contactcount and
>* contact max are global to the report */
> @@ -683,6 +706,10 @@ static void mt_complete_slot(struct mt_device *td, 
> struct input_dev *input)
>   int wide = (s->w > s->h);
>   int major = max(s->w, s->h);
>   int minor = min(s->w, s->h);
> + int orientation = wide;
> +
> + if (s->has_azimuth)
> + orie

Re: [PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

On Oct 10 2017 or thereabouts, Wei-Ning Huang wrote:
> From: Wei-Ning Huang 
> 
> The current hid-multitouch driver only allow the report of two
> orientations, vertical and horizontal. We use the Azimuth orientation
> usage 0x3F under the Digitizer usage page to report orientation if the
> device supports it.
> 
> Changelog:
>   v1 -> v2:
>- Fix commit message.
>- Remove resolution reporting for ABS_MT_ORIENTATION.
>   v2 -> v3:
>- Fix commit message.
>   v3 -> v4:
>- Fix ABS_MT_ORIENTATION ABS param range.
>- Don't set ABS_MT_ORIENTATION in ABS_DG_HEIGHT when it is already
>  set by ABS_DG_AZIMUTH.
> 
> Signed-off-by: Wei-Ning Huang 
> Reviewed-by: Dmitry Torokhov 

Looks good now:
Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

> ---
>  drivers/hid/hid-multitouch.c | 52 
> 
>  include/linux/hid.h  |  1 +
>  2 files changed, 49 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..3317dae64ef7 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
>  #define MT_IO_FLAGS_PENDING_SLOTS2
>  
>  struct mt_slot {
> - __s32 x, y, cx, cy, p, w, h;
> + __s32 x, y, cx, cy, p, w, h, a;
>   __s32 contactid;/* the device ContactID assigned to this slot */
>   bool touch_state;   /* is the touch valid? */
>   bool inrange_state; /* is the finger in proximity of the sensor? */
>   bool confidence_state;  /* is the touch made by a finger? */
> + bool has_azimuth;   /* the contact reports azimuth */
>  };
>  
>  struct mt_class {
> @@ -571,8 +572,15 @@ static int mt_touch_input_mapping(struct hid_device 
> *hdev, struct hid_input *hi,
>   if (!(cls->quirks & MT_QUIRK_NO_AREA)) {
>   set_abs(hi->input, ABS_MT_TOUCH_MINOR, field,
>   cls->sn_height);
> - input_set_abs_params(hi->input,
> - ABS_MT_ORIENTATION, 0, 1, 0, 0);
> +
> + /*
> +  * Only set ABS_MT_ORIENTATION if it is not
> +  * already set by the HID_DG_AZIMUTH usage.
> +  */
> + if (!test_bit(ABS_MT_ORIENTATION,
> + hi->input->absbit))
> + input_set_abs_params(hi->input,
> + ABS_MT_ORIENTATION, 0, 1, 0, 0);
>   }
>   mt_store_field(usage, td, hi);
>   return 1;
> @@ -591,6 +599,21 @@ static int mt_touch_input_mapping(struct hid_device 
> *hdev, struct hid_input *hi,
>   td->cc_index = field->index;
>   td->cc_value_index = usage->usage_index;
>   return 1;
> + case HID_DG_AZIMUTH:
> + hid_map_usage(hi, usage, bit, max,
> + EV_ABS, ABS_MT_ORIENTATION);
> + /*
> +  * Azimuth has the range of [0, MAX) representing a full
> +  * revolution. Set ABS_MT_ORIENTATION to a quarter of
> +  * MAX according the definition of ABS_MT_ORIENTATION
> +  */
> + input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> + -field->logical_maximum / 4,
> + field->logical_maximum / 4,
> + cls->sn_move ?
> + field->logical_maximum / cls->sn_move : 0, 0);
> + mt_store_field(usage, td, hi);
> + return 1;
>   case HID_DG_CONTACTMAX:
>   /* we don't set td->last_slot_field as contactcount and
>* contact max are global to the report */
> @@ -683,6 +706,10 @@ static void mt_complete_slot(struct mt_device *td, 
> struct input_dev *input)
>   int wide = (s->w > s->h);
>   int major = max(s->w, s->h);
>   int minor = min(s->w, s->h);
> + int orientation = wide;
> +
> + if (s->has_azimuth)
> + orientation = s->a;
>  
>   /*
>* divided by two t

Re: [PATCH v3] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

Hi,

On Oct 05 2017 or thereabouts, Jiri Kosina wrote:
> 
> [ adding Benjamin to CC ]
> 
> On Thu, 28 Sep 2017, Wei-Ning Huang wrote:
> 
> > The current hid-multitouch driver only allow the report of two
> > orientations, vertical and horizontal. We use the Azimuth orientation
> > usage 0x3F under the Digitizer usage page to report orientation if the
> > device supports it.
> > 
> > Changelog:
> >   v1 -> v2:
> >- Fix commit message.
> >- Remove resolution reporting for ABS_MT_ORIENTATION.
> >   v2 -> v3:
> >- Fix commit message.
> > 
> > Signed-off-by: Wei-Ning Huang 
> > Reviewed-by: Dmitry Torokhov 
> > ---
> >  drivers/hid/hid-multitouch.c | 35 +--
> >  include/linux/hid.h  |  1 +
> >  2 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 440b999304a5..f9801d1b1eae 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
> >  #define MT_IO_FLAGS_PENDING_SLOTS  2
> >  
> >  struct mt_slot {
> > -   __s32 x, y, cx, cy, p, w, h;
> > +   __s32 x, y, cx, cy, p, w, h, a;
> > __s32 contactid;/* the device ContactID assigned to this slot */
> > bool touch_state;   /* is the touch valid? */
> > bool inrange_state; /* is the finger in proximity of the sensor? */
> > bool confidence_state;  /* is the touch made by a finger? */
> > +   bool has_azimuth;   /* the contact reports azimuth */
> >  };
> >  
> >  struct mt_class {
> > @@ -591,6 +592,20 @@ static int mt_touch_input_mapping(struct hid_device 
> > *hdev, struct hid_input *hi,
> > td->cc_index = field->index;
> > td->cc_value_index = usage->usage_index;
> > return 1;
> > +   case HID_DG_AZIMUTH:
> > +   hid_map_usage(hi, usage, bit, max,
> > +   EV_ABS, ABS_MT_ORIENTATION);
> > +   /*
> > +* Azimuth has the range of [0, MAX) representing a full
> > +* revolution. Set ABS_MT_ORIENTATION to a quarter of
> > +* MAX according the definition of ABS_MT_ORIENTATION
> > +*/
> > +   input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> > +   0, field->logical_maximum / 4,

Shouldn't this be "-field->logical_maximum / 4, field->logical_maximum / 4,"?

Also, if HID_DG_HEIGHT is seen after HID_DG_AZIMUTH, it'll change the
ABS_MT_ORIENTATION you just set here.

> > +   cls->sn_move ?
> > +   field->logical_maximum / cls->sn_move : 0, 0);
> > +   mt_store_field(usage, td, hi);
> > +   return 1;
> > case HID_DG_CONTACTMAX:
> > /* we don't set td->last_slot_field as contactcount and
> >  * contact max are global to the report */
> > @@ -683,6 +698,10 @@ static void mt_complete_slot(struct mt_device *td, 
> > struct input_dev *input)
> > int wide = (s->w > s->h);
> > int major = max(s->w, s->h);
> > int minor = min(s->w, s->h);
> > +   int orientation = wide;
> > +
> > +   if (s->has_azimuth)
> > +   orientation = s->a;
> >  
> > /*
> >  * divided by two to match visual scale of touch
> > @@ -699,7 +718,8 @@ static void mt_complete_slot(struct mt_device *td, 
> > struct input_dev *input)
> > input_event(input, EV_ABS, ABS_MT_TOOL_Y, s->cy);
> > input_event(input, EV_ABS, ABS_MT_DISTANCE,
> > !s->touch_state);
> > -   input_event(input, EV_ABS, ABS_MT_ORIENTATION, wide);
> > +   input_event(input, EV_ABS, ABS_MT_ORIENTATION,
> > +   orientation);
> > input_event(input, EV_ABS, ABS_MT_PRESSURE, s->p);
> > input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major);
> > input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor);
> > @@ -789,6 +809,17 @@ static void mt_process_mt_event(struct hid_device 
> > *hid, struct hid_field *field,
> > break;
> > case HID_DG_CONTACTCOUNT:
> > break;
> > +   case HID_DG_AZIMUTH:
> > +   /*
> > +* Azimuth is counter-clockwise and ranges from [0, MAX)
> > +* (a full revolution). Convert it to clockwise ranging
> > +* [-MAX/2, MAX/2].

It took me a while to get this right. The problem is the definition of
ABS_MT_ORIENTATION says that we report [-MAX/4, MAX/4], *but* we can go
out of range to [-MAX/2, MAX/2] to report upside down 

Re: [PATCH v3] HID: hid-multitouch: support fine-grain orientation reporting

[Benjamin Tissoires]

Hi,

On Oct 05 2017 or thereabouts, Jiri Kosina wrote:
> 
> [ adding Benjamin to CC ]
> 
> On Thu, 28 Sep 2017, Wei-Ning Huang wrote:
> 
> > The current hid-multitouch driver only allow the report of two
> > orientations, vertical and horizontal. We use the Azimuth orientation
> > usage 0x3F under the Digitizer usage page to report orientation if the
> > device supports it.
> > 
> > Changelog:
> >   v1 -> v2:
> >- Fix commit message.
> >- Remove resolution reporting for ABS_MT_ORIENTATION.
> >   v2 -> v3:
> >- Fix commit message.
> > 
> > Signed-off-by: Wei-Ning Huang 
> > Reviewed-by: Dmitry Torokhov 
> > ---
> >  drivers/hid/hid-multitouch.c | 35 +--
> >  include/linux/hid.h  |  1 +
> >  2 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 440b999304a5..f9801d1b1eae 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
> >  #define MT_IO_FLAGS_PENDING_SLOTS  2
> >  
> >  struct mt_slot {
> > -   __s32 x, y, cx, cy, p, w, h;
> > +   __s32 x, y, cx, cy, p, w, h, a;
> > __s32 contactid;/* the device ContactID assigned to this slot */
> > bool touch_state;   /* is the touch valid? */
> > bool inrange_state; /* is the finger in proximity of the sensor? */
> > bool confidence_state;  /* is the touch made by a finger? */
> > +   bool has_azimuth;   /* the contact reports azimuth */
> >  };
> >  
> >  struct mt_class {
> > @@ -591,6 +592,20 @@ static int mt_touch_input_mapping(struct hid_device 
> > *hdev, struct hid_input *hi,
> > td->cc_index = field->index;
> > td->cc_value_index = usage->usage_index;
> > return 1;
> > +   case HID_DG_AZIMUTH:
> > +   hid_map_usage(hi, usage, bit, max,
> > +   EV_ABS, ABS_MT_ORIENTATION);
> > +   /*
> > +* Azimuth has the range of [0, MAX) representing a full
> > +* revolution. Set ABS_MT_ORIENTATION to a quarter of
> > +* MAX according the definition of ABS_MT_ORIENTATION
> > +*/
> > +   input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> > +   0, field->logical_maximum / 4,

Shouldn't this be "-field->logical_maximum / 4, field->logical_maximum / 4,"?

Also, if HID_DG_HEIGHT is seen after HID_DG_AZIMUTH, it'll change the
ABS_MT_ORIENTATION you just set here.

> > +   cls->sn_move ?
> > +   field->logical_maximum / cls->sn_move : 0, 0);
> > +   mt_store_field(usage, td, hi);
> > +   return 1;
> > case HID_DG_CONTACTMAX:
> > /* we don't set td->last_slot_field as contactcount and
> >  * contact max are global to the report */
> > @@ -683,6 +698,10 @@ static void mt_complete_slot(struct mt_device *td, 
> > struct input_dev *input)
> > int wide = (s->w > s->h);
> > int major = max(s->w, s->h);
> > int minor = min(s->w, s->h);
> > +   int orientation = wide;
> > +
> > +   if (s->has_azimuth)
> > +   orientation = s->a;
> >  
> > /*
> >  * divided by two to match visual scale of touch
> > @@ -699,7 +718,8 @@ static void mt_complete_slot(struct mt_device *td, 
> > struct input_dev *input)
> > input_event(input, EV_ABS, ABS_MT_TOOL_Y, s->cy);
> > input_event(input, EV_ABS, ABS_MT_DISTANCE,
> > !s->touch_state);
> > -   input_event(input, EV_ABS, ABS_MT_ORIENTATION, wide);
> > +   input_event(input, EV_ABS, ABS_MT_ORIENTATION,
> > +   orientation);
> > input_event(input, EV_ABS, ABS_MT_PRESSURE, s->p);
> > input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major);
> > input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor);
> > @@ -789,6 +809,17 @@ static void mt_process_mt_event(struct hid_device 
> > *hid, struct hid_field *field,
> > break;
> > case HID_DG_CONTACTCOUNT:
> > break;
> > +   case HID_DG_AZIMUTH:
> > +   /*
> > +* Azimuth is counter-clockwise and ranges from [0, MAX)
> > +* (a full revolution). Convert it to clockwise ranging
> > +* [-MAX/2, MAX/2].

It took me a while to get this right. The problem is the definition of
ABS_MT_ORIENTATION says that we report [-MAX/4, MAX/4], *but* we can go
out of range to [-MAX/2, MAX/2] to report upside down ellipsis.

So this is correct, but I'd 

Re: [PATCH] HID: usbhid: Convert timers to use timer_setup()

[Benjamin Tissoires]

On Oct 04 2017 or thereabouts, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Adds pointer back to hid_device for
> multitouch.
> 
> Cc: Jiri Kosina <ji...@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> Cc: linux-in...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Thomas Gleixner <t...@linutronix.de>
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.

Looks good to me:
Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Selfish request: Jiri can you add the dependency about 686fef928bba in
the commit message too? I am just preparing in case I need to backport
this in RHEL, and having the dep explicitly mentioned would save me a
little bit of extra time :)
(if not, no worries)

Cheers,
Benjamin

> ---
>  drivers/hid/hid-multitouch.c  | 10 ++
>  drivers/hid/usbhid/hid-core.c |  8 
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..b0e3e2614b18 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -112,6 +112,7 @@ struct mt_device {
>   struct mt_slot curdata; /* placeholder of incoming data */
>   struct mt_class mtclass;/* our mt device class */
>   struct timer_list release_timer;/* to release sticky fingers */
> + struct hid_device *hdev;/* hid_device we're attached to */
>   struct mt_fields *fields;   /* temporary placeholder for storing the
>  multitouch fields */
>   unsigned long mt_io_flags;  /* mt flags (MT_IO_FLAGS_*) */
> @@ -1245,10 +1246,10 @@ static void mt_release_contacts(struct hid_device 
> *hid)
>   td->num_received = 0;
>  }
>  
> -static void mt_expired_timeout(unsigned long arg)
> +static void mt_expired_timeout(struct timer_list *t)
>  {
> - struct hid_device *hdev = (void *)arg;
> - struct mt_device *td = hid_get_drvdata(hdev);
> + struct mt_device *td = from_timer(td, t, release_timer);
> + struct hid_device *hdev = td->hdev;
>  
>   /*
>* An input report came in just before we release the sticky fingers,
> @@ -1279,6 +1280,7 @@ static int mt_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>   dev_err(>dev, "cannot allocate multitouch data\n");
>   return -ENOMEM;
>   }
> + td->hdev = hdev;
>   td->mtclass = *mtclass;
>   td->inputmode = -1;
>   td->maxcontact_report_id = -1;
> @@ -1330,7 +1332,7 @@ static int mt_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>*/
>   hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
>  
> - setup_timer(>release_timer, mt_expired_timeout, (long)hdev);
> + timer_setup(>release_timer, mt_expired_timeout, 0);
>  
>   ret = hid_parse(hdev);
>   if (ret != 0)
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 089bad8a9a21..9f9fe0e58f5b 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -101,10 +101,10 @@ static int hid_start_in(struct hid_device *hid)
>  }
>  
>  /* I/O retry timer routine */
> -static void hid_retry_timeout(unsigned long _hid)
> +static void hid_retry_timeout(struct timer_list *t)
>  {
> - struct hid_device *hid = (struct hid_device *) _hid;
> - struct usbhid_device *usbhid = hid->driver_data;
> + struct usbhid_device *usbhid = from_timer(usbhid, t, io_retry);
> + struct hid_device *hid = usbhid->hid;
>  
>   dev_dbg(>intf->dev, "retrying intr urb\n");
>   if (hid_start_in(hid))
> @@ -1363,7 +1363,7 @@ static int usbhid_probe(struct usb_interface *intf, 
> const struct usb_device_id *
>  
>   init_waitqueue_head(>wait);
>   INIT_WORK(>reset_work, hid_reset);
> - setup_timer(>io_retry, hid_retry_timeout, (unsigned long) hid);
> + timer_setup(>io_retry, hid_retry_timeout, 0);
>   spin_lock_init(>lock);
>  
>   ret = hid_add_device(hid);
> -- 
> 2.7.4
> 
> 
> -- 
> Kees Cook
> Pixel Security

Re: [PATCH] HID: usbhid: Convert timers to use timer_setup()

[Benjamin Tissoires]

On Oct 04 2017 or thereabouts, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Adds pointer back to hid_device for
> multitouch.
> 
> Cc: Jiri Kosina 
> Cc: Benjamin Tissoires 
> Cc: linux-in...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Thomas Gleixner 
> Signed-off-by: Kees Cook 
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.

Looks good to me:
Reviewed-by: Benjamin Tissoires 

Selfish request: Jiri can you add the dependency about 686fef928bba in
the commit message too? I am just preparing in case I need to backport
this in RHEL, and having the dep explicitly mentioned would save me a
little bit of extra time :)
(if not, no worries)

Cheers,
Benjamin

> ---
>  drivers/hid/hid-multitouch.c  | 10 ++
>  drivers/hid/usbhid/hid-core.c |  8 
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..b0e3e2614b18 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -112,6 +112,7 @@ struct mt_device {
>   struct mt_slot curdata; /* placeholder of incoming data */
>   struct mt_class mtclass;/* our mt device class */
>   struct timer_list release_timer;/* to release sticky fingers */
> + struct hid_device *hdev;/* hid_device we're attached to */
>   struct mt_fields *fields;   /* temporary placeholder for storing the
>  multitouch fields */
>   unsigned long mt_io_flags;  /* mt flags (MT_IO_FLAGS_*) */
> @@ -1245,10 +1246,10 @@ static void mt_release_contacts(struct hid_device 
> *hid)
>   td->num_received = 0;
>  }
>  
> -static void mt_expired_timeout(unsigned long arg)
> +static void mt_expired_timeout(struct timer_list *t)
>  {
> - struct hid_device *hdev = (void *)arg;
> - struct mt_device *td = hid_get_drvdata(hdev);
> + struct mt_device *td = from_timer(td, t, release_timer);
> + struct hid_device *hdev = td->hdev;
>  
>   /*
>* An input report came in just before we release the sticky fingers,
> @@ -1279,6 +1280,7 @@ static int mt_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>   dev_err(>dev, "cannot allocate multitouch data\n");
>   return -ENOMEM;
>   }
> + td->hdev = hdev;
>   td->mtclass = *mtclass;
>   td->inputmode = -1;
>   td->maxcontact_report_id = -1;
> @@ -1330,7 +1332,7 @@ static int mt_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>*/
>   hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
>  
> - setup_timer(>release_timer, mt_expired_timeout, (long)hdev);
> + timer_setup(>release_timer, mt_expired_timeout, 0);
>  
>   ret = hid_parse(hdev);
>   if (ret != 0)
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 089bad8a9a21..9f9fe0e58f5b 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -101,10 +101,10 @@ static int hid_start_in(struct hid_device *hid)
>  }
>  
>  /* I/O retry timer routine */
> -static void hid_retry_timeout(unsigned long _hid)
> +static void hid_retry_timeout(struct timer_list *t)
>  {
> - struct hid_device *hid = (struct hid_device *) _hid;
> - struct usbhid_device *usbhid = hid->driver_data;
> + struct usbhid_device *usbhid = from_timer(usbhid, t, io_retry);
> + struct hid_device *hid = usbhid->hid;
>  
>   dev_dbg(>intf->dev, "retrying intr urb\n");
>   if (hid_start_in(hid))
> @@ -1363,7 +1363,7 @@ static int usbhid_probe(struct usb_interface *intf, 
> const struct usb_device_id *
>  
>   init_waitqueue_head(>wait);
>   INIT_WORK(>reset_work, hid_reset);
> - setup_timer(>io_retry, hid_retry_timeout, (unsigned long) hid);
> + timer_setup(>io_retry, hid_retry_timeout, 0);
>   spin_lock_init(>lock);
>  
>   ret = hid_add_device(hid);
> -- 
> 2.7.4
> 
> 
> -- 
> Kees Cook
> Pixel Security

[PATCH v2 1/4] HID: core: move the dynamic quirks handling in core

[Benjamin Tissoires]

usbhid has a list of dynamic quirks in addition to a list of static quirks.
There is not much USB specific in that, so move this part of the module
in core so we can have one central place for quirks.

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

---
changes in v2:
- add missing EXPORT_SYMBOL[_GPL] for separate module compilation
---
 drivers/hid/Makefile  |   2 +-
 drivers/hid/hid-core.c|  10 +-
 drivers/hid/{usbhid => }/hid-quirks.c | 491 +-
 drivers/hid/usbhid/Makefile   |   2 +-
 drivers/hid/usbhid/hid-core.c |  10 +-
 include/linux/hid.h   |  10 +-
 6 files changed, 263 insertions(+), 262 deletions(-)
 rename drivers/hid/{usbhid => }/hid-quirks.c (11%)

diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 8659d7e..276094b5 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for the HID driver
 #
-hid-y  := hid-core.o hid-input.o
+hid-y  := hid-core.o hid-input.o hid-quirks.o
 hid-$(CONFIG_DEBUG_FS) += hid-debug.o
 
 obj-$(CONFIG_HID)  += hid.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c8f0c11..aaa208d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1597,8 +1597,8 @@ int hid_input_report(struct hid_device *hid, int type, u8 
*data, int size, int i
 }
 EXPORT_SYMBOL_GPL(hid_input_report);
 
-static bool hid_match_one_id(struct hid_device *hdev,
-   const struct hid_device_id *id)
+bool hid_match_one_id(const struct hid_device *hdev,
+ const struct hid_device_id *id)
 {
return (id->bus == HID_BUS_ANY || id->bus == hdev->bus) &&
(id->group == HID_GROUP_ANY || id->group == hdev->group) &&
@@ -1606,7 +1606,7 @@ static bool hid_match_one_id(struct hid_device *hdev,
(id->product == HID_ANY_ID || id->product == hdev->product);
 }
 
-const struct hid_device_id *hid_match_id(struct hid_device *hdev,
+const struct hid_device_id *hid_match_id(const struct hid_device *hdev,
const struct hid_device_id *id)
 {
for (; id->bus; id++)
@@ -2607,6 +2607,7 @@ static struct bus_type hid_bus_type = {
.remove = hid_device_remove,
.uevent = hid_uevent,
 };
+EXPORT_SYMBOL(hid_bus_type);
 
 /* a list of devices that shouldn't be handled by HID core at all */
 static const struct hid_device_id hid_ignore_list[] = {
@@ -2925,6 +2926,8 @@ int hid_add_device(struct hid_device *hdev)
if (WARN_ON(hdev->status & HID_STAT_ADDED))
return -EBUSY;
 
+   hdev->quirks = hid_lookup_quirk(hdev);
+
/* we need to kill them here, otherwise they will stay allocated to
 * wait for coming driver */
if (hid_ignore(hdev))
@@ -3111,6 +3114,7 @@ static void __exit hid_exit(void)
hid_debug_exit();
hidraw_exit();
bus_unregister(_bus_type);
+   hid_quirks_exit(HID_BUS_ANY);
 }
 
 module_init(hid_init);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/hid-quirks.c
similarity index 11%
rename from drivers/hid/usbhid/hid-quirks.c
rename to drivers/hid/hid-quirks.c
index f489a5c..a40d929 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -1,5 +1,5 @@
 /*
- *  USB HID quirks support for Linux
+ *  HID quirks support for Linux
  *
  *  Copyright (c) 1999 Andreas Gal
  *  Copyright (c) 2000-2005 Vojtech Pavlik <vojt...@suse.cz>
@@ -18,246 +18,237 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "../hid-ids.h"
+#include "hid-ids.h"
 
 /*
- * Alphabetically sorted blacklist by quirk type.
+ * Alphabetically sorted by vendor then product.
  */
 
-static const struct hid_blacklist {
-   __u16 idVendor;
-   __u16 idProduct;
-   __u32 quirks;
-} hid_blacklist[] = {
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_CHIC, USB_DEVICE_ID_CHIC_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER, 
HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET },
-   { USB_VENDOR_ID_MOJO, USB_DEVICE_ID_RETRO_ADAPTER, 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_NATSU, USB_DEVICE_ID_NATSU_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_NEC, USB_DEVICE_ID_NEC_USB_GAME_PAD, HID_QUIRK_BADPAD },
- 

[PATCH v2 1/4] HID: core: move the dynamic quirks handling in core

[Benjamin Tissoires]

usbhid has a list of dynamic quirks in addition to a list of static quirks.
There is not much USB specific in that, so move this part of the module
in core so we can have one central place for quirks.

Signed-off-by: Benjamin Tissoires 

---
changes in v2:
- add missing EXPORT_SYMBOL[_GPL] for separate module compilation
---
 drivers/hid/Makefile  |   2 +-
 drivers/hid/hid-core.c|  10 +-
 drivers/hid/{usbhid => }/hid-quirks.c | 491 +-
 drivers/hid/usbhid/Makefile   |   2 +-
 drivers/hid/usbhid/hid-core.c |  10 +-
 include/linux/hid.h   |  10 +-
 6 files changed, 263 insertions(+), 262 deletions(-)
 rename drivers/hid/{usbhid => }/hid-quirks.c (11%)

diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 8659d7e..276094b5 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for the HID driver
 #
-hid-y  := hid-core.o hid-input.o
+hid-y  := hid-core.o hid-input.o hid-quirks.o
 hid-$(CONFIG_DEBUG_FS) += hid-debug.o
 
 obj-$(CONFIG_HID)  += hid.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c8f0c11..aaa208d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1597,8 +1597,8 @@ int hid_input_report(struct hid_device *hid, int type, u8 
*data, int size, int i
 }
 EXPORT_SYMBOL_GPL(hid_input_report);
 
-static bool hid_match_one_id(struct hid_device *hdev,
-   const struct hid_device_id *id)
+bool hid_match_one_id(const struct hid_device *hdev,
+ const struct hid_device_id *id)
 {
return (id->bus == HID_BUS_ANY || id->bus == hdev->bus) &&
(id->group == HID_GROUP_ANY || id->group == hdev->group) &&
@@ -1606,7 +1606,7 @@ static bool hid_match_one_id(struct hid_device *hdev,
(id->product == HID_ANY_ID || id->product == hdev->product);
 }
 
-const struct hid_device_id *hid_match_id(struct hid_device *hdev,
+const struct hid_device_id *hid_match_id(const struct hid_device *hdev,
const struct hid_device_id *id)
 {
for (; id->bus; id++)
@@ -2607,6 +2607,7 @@ static struct bus_type hid_bus_type = {
.remove = hid_device_remove,
.uevent = hid_uevent,
 };
+EXPORT_SYMBOL(hid_bus_type);
 
 /* a list of devices that shouldn't be handled by HID core at all */
 static const struct hid_device_id hid_ignore_list[] = {
@@ -2925,6 +2926,8 @@ int hid_add_device(struct hid_device *hdev)
if (WARN_ON(hdev->status & HID_STAT_ADDED))
return -EBUSY;
 
+   hdev->quirks = hid_lookup_quirk(hdev);
+
/* we need to kill them here, otherwise they will stay allocated to
 * wait for coming driver */
if (hid_ignore(hdev))
@@ -3111,6 +3114,7 @@ static void __exit hid_exit(void)
hid_debug_exit();
hidraw_exit();
bus_unregister(_bus_type);
+   hid_quirks_exit(HID_BUS_ANY);
 }
 
 module_init(hid_init);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/hid-quirks.c
similarity index 11%
rename from drivers/hid/usbhid/hid-quirks.c
rename to drivers/hid/hid-quirks.c
index f489a5c..a40d929 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -1,5 +1,5 @@
 /*
- *  USB HID quirks support for Linux
+ *  HID quirks support for Linux
  *
  *  Copyright (c) 1999 Andreas Gal
  *  Copyright (c) 2000-2005 Vojtech Pavlik 
@@ -18,246 +18,237 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "../hid-ids.h"
+#include "hid-ids.h"
 
 /*
- * Alphabetically sorted blacklist by quirk type.
+ * Alphabetically sorted by vendor then product.
  */
 
-static const struct hid_blacklist {
-   __u16 idVendor;
-   __u16 idProduct;
-   __u32 quirks;
-} hid_blacklist[] = {
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR, 
HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_CHIC, USB_DEVICE_ID_CHIC_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER, 
HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET },
-   { USB_VENDOR_ID_MOJO, USB_DEVICE_ID_RETRO_ADAPTER, 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING, HID_QUIRK_BADPAD | 
HID_QUIRK_MULTI_INPUT },
-   { USB_VENDOR_ID_NATSU, USB_DEVICE_ID_NATSU_GAMEPAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_NEC, USB_DEVICE_ID_NEC_USB_GAME_PAD, HID_QUIRK_BADPAD },
-   { USB_VENDOR_ID_NEXTWINDOW, USB_DEVICE_

[PATCH v2 3/4] HID: core: move the list of ignored devices in hid-quirks.c

[Benjamin Tissoires]

Better having all the devices quirks in one place.

Note that this change introduces an initial lookup for the device in
hid_gets_squirk(), which should not theoretically be required, but which
actually allows to not have to reparse the list of ignored devices
if we call hid_lookup_quirks twice.

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

---
no changes in v2
---
 drivers/hid/hid-core.c   | 309 --
 drivers/hid/hid-quirks.c | 312 +++
 2 files changed, 312 insertions(+), 309 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 1c8d107..e6d586a 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2080,315 +2080,6 @@ static struct bus_type hid_bus_type = {
 };
 EXPORT_SYMBOL(hid_bus_type);
 
-/* a list of devices that shouldn't be handled by HID core at all */
-static const struct hid_device_id hid_ignore_list[] = {
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_FLAIR) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_302) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ADS_TECH, 
USB_DEVICE_ID_ADS_TECH_RADIO_SI470X) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_20) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_21) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_22) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_23) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_24) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIRCABLE, USB_DEVICE_ID_AIRCABLE1) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ALCOR, USB_DEVICE_ID_ALCOR_USBRS232) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM)},
-   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM2)},
-   { HID_USB_DEVICE(USB_VENDOR_ID_AVERMEDIA, USB_DEVICE_ID_AVER_FM_MR800) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_AXENTIA, USB_DEVICE_ID_AXENTIA_FM_RADIO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, 
USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, 
USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CMEDIA, USB_DEVICE_ID_CM109) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, 
USB_DEVICE_ID_CYPRESS_ULTRAMOUSE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DEALEXTREAME, 
USB_DEVICE_ID_DEALEXTREAME_RADIO_SI4701) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, 
USB_DEVICE_ID_DELORME_EARTHMATE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) 
},
-   { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) },
-   { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, 
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0001) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0002) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0004) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_SUPER_Q2) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_GOGOPEN) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_PENPOWER) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRETAGMACBETH, 
USB_DEVICE_ID_GRETAGMACBETH_HUEY) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_POWERMATE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_SOUNDKNOB) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_RADIOSHARK) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_90) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_100) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_101) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_103) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_104) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_105) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_106) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_107) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_108) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_200) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_201) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GT

[PATCH v2 3/4] HID: core: move the list of ignored devices in hid-quirks.c

[Benjamin Tissoires]

Better having all the devices quirks in one place.

Note that this change introduces an initial lookup for the device in
hid_gets_squirk(), which should not theoretically be required, but which
actually allows to not have to reparse the list of ignored devices
if we call hid_lookup_quirks twice.

Signed-off-by: Benjamin Tissoires 

---
no changes in v2
---
 drivers/hid/hid-core.c   | 309 --
 drivers/hid/hid-quirks.c | 312 +++
 2 files changed, 312 insertions(+), 309 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 1c8d107..e6d586a 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2080,315 +2080,6 @@ static struct bus_type hid_bus_type = {
 };
 EXPORT_SYMBOL(hid_bus_type);
 
-/* a list of devices that shouldn't be handled by HID core at all */
-static const struct hid_device_id hid_ignore_list[] = {
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_FLAIR) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_302) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ADS_TECH, 
USB_DEVICE_ID_ADS_TECH_RADIO_SI470X) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_20) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_21) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_22) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_23) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_24) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_AIRCABLE, USB_DEVICE_ID_AIRCABLE1) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ALCOR, USB_DEVICE_ID_ALCOR_USBRS232) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM)},
-   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM2)},
-   { HID_USB_DEVICE(USB_VENDOR_ID_AVERMEDIA, USB_DEVICE_ID_AVER_FM_MR800) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_AXENTIA, USB_DEVICE_ID_AXENTIA_FM_RADIO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, 
USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, 
USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CMEDIA, USB_DEVICE_ID_CM109) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, 
USB_DEVICE_ID_CYPRESS_ULTRAMOUSE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DEALEXTREAME, 
USB_DEVICE_ID_DEALEXTREAME_RADIO_SI4701) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, 
USB_DEVICE_ID_DELORME_EARTHMATE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) 
},
-   { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) },
-   { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, 
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0001) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0002) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GENERAL_TOUCH, 0x0004) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_SUPER_Q2) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_GOGOPEN) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_PENPOWER) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRETAGMACBETH, 
USB_DEVICE_ID_GRETAGMACBETH_HUEY) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_POWERMATE) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_SOUNDKNOB) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_RADIOSHARK) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_90) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_100) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_101) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_103) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_104) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_105) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_106) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_107) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_108) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_200) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_201) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_202) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_GTCO

[PATCH v2 4/4] HID: core: remove the absolute need of hid_have_special_driver[]

[Benjamin Tissoires]

Most HID devices behave properly when they are used with hid-generic.
Since kernel v4.12, we do not poll for input reports at plug in, so
hid-generic should behave properly with all HID devices.

There has been a long standing list of HID devices that have a special
driver. It used to be just a few, but with time, this list went too big,
and we can not ask users to know which HID special driver will pick up
their device.

We can teach hid-generic to be nice with others. If a device is not
explicitly marked with HID_QUIRK_HAVE_SPECIAL_DRIVER, we can allow
hid-generic to pick up the device as long as no other loaded HID driver
will match the device.

When the special driver appears, hid-generic can step back and let
the special driver handling the device. In case this special driver
is removed, this good old pal of hid-generic will rebind to the device.

This basically makes the list hid_have_special_driver[] useless. It
still allows to not see a hid-generic driver bound and removed during
boot, so we can keep it around.

This will also help other people to have a special HID driver without
the need of recompiling hid-core.

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

---
no changes in v2
---
 drivers/hid/hid-core.c| 76 ++-
 drivers/hid/hid-generic.c | 68 +-
 include/linux/hid.h   | 10 +++
 3 files changed, 125 insertions(+), 29 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e6d586a..7297b1d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -830,31 +830,6 @@ static int hid_scan_report(struct hid_device *hid)
break;
}
 
-   /* fall back to generic driver in case specific driver doesn't exist */
-   switch (hid->group) {
-   case HID_GROUP_MULTITOUCH_WIN_8:
-   /* fall-through */
-   case HID_GROUP_MULTITOUCH:
-   if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_SENSOR_HUB:
-   if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_RMI:
-   if (!IS_ENABLED(CONFIG_HID_RMI))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_WACOM:
-   if (!IS_ENABLED(CONFIG_HID_WACOM))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_LOGITECH_DJ_DEVICE:
-   if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   }
vfree(parser);
return 0;
 }
@@ -1928,8 +1903,8 @@ static void hid_free_dynids(struct hid_driver *hdrv)
spin_unlock(>dyn_lock);
 }
 
-static const struct hid_device_id *hid_match_device(struct hid_device *hdev,
-   struct hid_driver *hdrv)
+const struct hid_device_id *hid_match_device(struct hid_device *hdev,
+struct hid_driver *hdrv)
 {
struct hid_dynid *dynid;
 
@@ -1944,6 +1919,7 @@ static const struct hid_device_id 
*hid_match_device(struct hid_device *hdev,
 
return hid_match_id(hdev, hdrv->id_table);
 }
+EXPORT_SYMBOL_GPL(hid_match_device);
 
 static int hid_bus_match(struct device *dev, struct device_driver *drv)
 {
@@ -1973,6 +1949,23 @@ static int hid_device_probe(struct device *dev)
goto unlock;
}
 
+   if (hdrv->match) {
+   if (!hdrv->match(hdev, hid_ignore_special_drivers)) {
+   ret = -ENODEV;
+   goto unlock;
+   }
+   } else {
+   /*
+* hid-generic implements .match(), so if
+* hid_ignore_special_drivers is set, we can safely
+* return.
+*/
+   if (hid_ignore_special_drivers) {
+   ret = -ENODEV;
+   goto unlock;
+   }
+   }
+
hdev->driver = hdrv;
if (hdrv->probe) {
ret = hdrv->probe(hdev, id);
@@ -2069,7 +2062,7 @@ static int hid_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
-static struct bus_type hid_bus_type = {
+struct bus_type hid_bus_type = {
.name   = "hid",
.dev_groups = hid_dev_groups,
.drv_groups = hid_drv_groups,
@@ -2203,6 +2196,29 @@ void hid_destroy_device(struct hid_device *hdev)
 }
 EXPORT_SYMBOL_GPL(hid_destroy_device);
 
+
+static int __bus_add_driver(struct device_driver *drv, void *data)
+{
+

[PATCH v2 4/4] HID: core: remove the absolute need of hid_have_special_driver[]

[Benjamin Tissoires]

Most HID devices behave properly when they are used with hid-generic.
Since kernel v4.12, we do not poll for input reports at plug in, so
hid-generic should behave properly with all HID devices.

There has been a long standing list of HID devices that have a special
driver. It used to be just a few, but with time, this list went too big,
and we can not ask users to know which HID special driver will pick up
their device.

We can teach hid-generic to be nice with others. If a device is not
explicitly marked with HID_QUIRK_HAVE_SPECIAL_DRIVER, we can allow
hid-generic to pick up the device as long as no other loaded HID driver
will match the device.

When the special driver appears, hid-generic can step back and let
the special driver handling the device. In case this special driver
is removed, this good old pal of hid-generic will rebind to the device.

This basically makes the list hid_have_special_driver[] useless. It
still allows to not see a hid-generic driver bound and removed during
boot, so we can keep it around.

This will also help other people to have a special HID driver without
the need of recompiling hid-core.

Signed-off-by: Benjamin Tissoires 

---
no changes in v2
---
 drivers/hid/hid-core.c| 76 ++-
 drivers/hid/hid-generic.c | 68 +-
 include/linux/hid.h   | 10 +++
 3 files changed, 125 insertions(+), 29 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e6d586a..7297b1d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -830,31 +830,6 @@ static int hid_scan_report(struct hid_device *hid)
break;
}
 
-   /* fall back to generic driver in case specific driver doesn't exist */
-   switch (hid->group) {
-   case HID_GROUP_MULTITOUCH_WIN_8:
-   /* fall-through */
-   case HID_GROUP_MULTITOUCH:
-   if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_SENSOR_HUB:
-   if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_RMI:
-   if (!IS_ENABLED(CONFIG_HID_RMI))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_WACOM:
-   if (!IS_ENABLED(CONFIG_HID_WACOM))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   case HID_GROUP_LOGITECH_DJ_DEVICE:
-   if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
-   hid->group = HID_GROUP_GENERIC;
-   break;
-   }
vfree(parser);
return 0;
 }
@@ -1928,8 +1903,8 @@ static void hid_free_dynids(struct hid_driver *hdrv)
spin_unlock(>dyn_lock);
 }
 
-static const struct hid_device_id *hid_match_device(struct hid_device *hdev,
-   struct hid_driver *hdrv)
+const struct hid_device_id *hid_match_device(struct hid_device *hdev,
+struct hid_driver *hdrv)
 {
struct hid_dynid *dynid;
 
@@ -1944,6 +1919,7 @@ static const struct hid_device_id 
*hid_match_device(struct hid_device *hdev,
 
return hid_match_id(hdev, hdrv->id_table);
 }
+EXPORT_SYMBOL_GPL(hid_match_device);
 
 static int hid_bus_match(struct device *dev, struct device_driver *drv)
 {
@@ -1973,6 +1949,23 @@ static int hid_device_probe(struct device *dev)
goto unlock;
}
 
+   if (hdrv->match) {
+   if (!hdrv->match(hdev, hid_ignore_special_drivers)) {
+   ret = -ENODEV;
+   goto unlock;
+   }
+   } else {
+   /*
+* hid-generic implements .match(), so if
+* hid_ignore_special_drivers is set, we can safely
+* return.
+*/
+   if (hid_ignore_special_drivers) {
+   ret = -ENODEV;
+   goto unlock;
+   }
+   }
+
hdev->driver = hdrv;
if (hdrv->probe) {
ret = hdrv->probe(hdev, id);
@@ -2069,7 +2062,7 @@ static int hid_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
-static struct bus_type hid_bus_type = {
+struct bus_type hid_bus_type = {
.name   = "hid",
.dev_groups = hid_dev_groups,
.drv_groups = hid_drv_groups,
@@ -2203,6 +2196,29 @@ void hid_destroy_device(struct hid_device *hdev)
 }
 EXPORT_SYMBOL_GPL(hid_destroy_device);
 
+
+static int __bus_add_driver(struct device_driver *drv, void *data)
+{
+   struct hid_driver *added_hdrv = data;
+ 

[PATCH v2 2/4] HID: quirks: move the list of special devices into a quirk

[Benjamin Tissoires]

It is better to centralize the information of special devices in one
single file. Instead of manually parsing the list of devices that
have a special driver or those that need to be ignored, introduce
HID_QUIRK_HAVE_SPECIAL_DRIVER and set the correct quirks while fetching
those quirks.

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

---
no changes in v2
---
 drivers/hid/hid-core.c| 531 +---
 drivers/hid/hid-quirks.c  | 552 +-
 include/linux/hid.h   |   1 +
 net/bluetooth/hidp/core.c |   2 +-
 4 files changed, 546 insertions(+), 540 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index aaa208d..1c8d107 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1862,535 +1862,6 @@ void hid_hw_close(struct hid_device *hdev)
 }
 EXPORT_SYMBOL_GPL(hid_hw_close);
 
-/*
- * A list of devices for which there is a specialized driver on HID bus.
- *
- * Please note that for multitouch devices (driven by hid-multitouch driver),
- * there is a proper autodetection and autoloading in place (based on presence
- * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
- * as we are doing the right thing in hid_scan_usage().
- *
- * Autodetection for (USB) HID sensor hubs exists too. If a collection of type
- * physical is found inside a usage page of type sensor, hid-sensor-hub will be
- * used as a driver. See hid_scan_report().
- */
-static const struct hid_device_id hid_have_special_driver[] = {
-#if IS_ENABLED(CONFIG_HID_A4TECH)
-   { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
-   { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ACRUX)
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ALPS)
-   { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_ALPS_JP, 
HID_DEVICE_ID_ALPS_U1_DUAL) },
-#endif
-#if IS_ENABLED(CONFIG_HID_APPLE)
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_MINI_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_MINI_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_MINI_JIS) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS) },
-   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI) },
-   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO) },
-   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING2_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING2_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING3_ANSI) },
-   { HID_USB_

[PATCH v2 2/4] HID: quirks: move the list of special devices into a quirk

[Benjamin Tissoires]

It is better to centralize the information of special devices in one
single file. Instead of manually parsing the list of devices that
have a special driver or those that need to be ignored, introduce
HID_QUIRK_HAVE_SPECIAL_DRIVER and set the correct quirks while fetching
those quirks.

Signed-off-by: Benjamin Tissoires 

---
no changes in v2
---
 drivers/hid/hid-core.c| 531 +---
 drivers/hid/hid-quirks.c  | 552 +-
 include/linux/hid.h   |   1 +
 net/bluetooth/hidp/core.c |   2 +-
 4 files changed, 546 insertions(+), 540 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index aaa208d..1c8d107 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1862,535 +1862,6 @@ void hid_hw_close(struct hid_device *hdev)
 }
 EXPORT_SYMBOL_GPL(hid_hw_close);
 
-/*
- * A list of devices for which there is a specialized driver on HID bus.
- *
- * Please note that for multitouch devices (driven by hid-multitouch driver),
- * there is a proper autodetection and autoloading in place (based on presence
- * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
- * as we are doing the right thing in hid_scan_usage().
- *
- * Autodetection for (USB) HID sensor hubs exists too. If a collection of type
- * physical is found inside a usage page of type sensor, hid-sensor-hub will be
- * used as a driver. See hid_scan_report().
- */
-static const struct hid_device_id hid_have_special_driver[] = {
-#if IS_ENABLED(CONFIG_HID_A4TECH)
-   { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
-   { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ACRUX)
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
-#endif
-#if IS_ENABLED(CONFIG_HID_ALPS)
-   { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_ALPS_JP, 
HID_DEVICE_ID_ALPS_U1_DUAL) },
-#endif
-#if IS_ENABLED(CONFIG_HID_APPLE)
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_MINI_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_MINI_ISO) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_MINI_JIS) 
},
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS) },
-   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI) },
-   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO) },
-   { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING2_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING2_JIS) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_WELLSPRING3_ANSI) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_APPLE

[PATCH v2 0/4] Quirks cleanup and hid-generic niceness

[Benjamin Tissoires]

Hi,

Niels found an issue with v1 of the series, while compiling the usbhid module
as a separate .ko.

Sending a v2 with the proper From: field fixed now.

I also use -M1 to show in 1/4 that usbhid/hid-quirks.c is basically moved to
hid-quirks.c.

Cheers,
Benjamin

Benjamin Tissoires (4):
  HID: core: move the dynamic quirks handling in core
  HID: quirks: move the list of special devices into a quirk
  HID: core: move the list of ignored devices in hid-quirks.c
  HID: core: remove the absolute need of hid_have_special_driver[]

 drivers/hid/Makefile|2 +-
 drivers/hid/hid-core.c  |  926 ++---
 drivers/hid/hid-generic.c   |   68 ++-
 drivers/hid/hid-quirks.c| 1244 +++
 drivers/hid/usbhid/Makefile |2 +-
 drivers/hid/usbhid/hid-core.c   |   10 +-
 drivers/hid/usbhid/hid-quirks.c |  401 -
 include/linux/hid.h |   21 +-
 net/bluetooth/hidp/core.c   |2 +-
 9 files changed, 1391 insertions(+), 1285 deletions(-)
 create mode 100644 drivers/hid/hid-quirks.c
 delete mode 100644 drivers/hid/usbhid/hid-quirks.c

-- 
2.9.5

[PATCH v2 0/4] Quirks cleanup and hid-generic niceness

[Benjamin Tissoires]

Hi,

Niels found an issue with v1 of the series, while compiling the usbhid module
as a separate .ko.

Sending a v2 with the proper From: field fixed now.

I also use -M1 to show in 1/4 that usbhid/hid-quirks.c is basically moved to
hid-quirks.c.

Cheers,
Benjamin

Benjamin Tissoires (4):
  HID: core: move the dynamic quirks handling in core
  HID: quirks: move the list of special devices into a quirk
  HID: core: move the list of ignored devices in hid-quirks.c
  HID: core: remove the absolute need of hid_have_special_driver[]

 drivers/hid/Makefile|2 +-
 drivers/hid/hid-core.c  |  926 ++---
 drivers/hid/hid-generic.c   |   68 ++-
 drivers/hid/hid-quirks.c| 1244 +++
 drivers/hid/usbhid/Makefile |2 +-
 drivers/hid/usbhid/hid-core.c   |   10 +-
 drivers/hid/usbhid/hid-quirks.c |  401 -
 include/linux/hid.h |   21 +-
 net/bluetooth/hidp/core.c   |2 +-
 9 files changed, 1391 insertions(+), 1285 deletions(-)
 create mode 100644 drivers/hid/hid-quirks.c
 delete mode 100644 drivers/hid/usbhid/hid-quirks.c

-- 
2.9.5

Re: [PATCH 0/4] Quirks cleanup and hid-generic niceness

[Benjamin Tissoires]

On Mon, Oct 2, 2017 at 10:18 PM, Fedora Kernel Team
<kernel-t...@fedoraproject.org> wrote:

Ouch, I happen to be in a git tree of the Fedora kernel, so git
send-email decided to rewrite the 'from:' field.
I'll add this to my check list before sending :/

Cheers,
Benjamin

> From: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
>
> Hi,
>
> This is the series I was talking about earlier[1].
>
> Basically, Jiri, I'd like to see 1-3 applied in for-next at your earliest
> convenience, and we can discuss about 4/4 without any rush.
>
> I have this in my local tree since June, but I made some late minute
> changes before sending, though the tests showed they are fine (I wouldn't
> mind a second pair of eyes on it).
>
> I am pretty sure we can optimize the things more, but for now this should be
> just fine and just convert the quirks mechanism in hid-core.
> For instance, there is a second call of hid_lookup_quirk() in 
> usbhid/hid-core.c
> that I am not sure about the absolute need.
>
> Niels, please have a look at this and tell me if you are OK to rebase your
> series on top of it.
>
> Cheers,
> Benjamin
>
>
> [1] https://patchwork.kernel.org/patch/9980443/
>
> Benjamin Tissoires (4):
>   HID: core: move the dynamic quirks handling in core
>   HID: quirks: move the list of special devices into a quirk
>   HID: core: move the list of ignored devices in hid-quirks.c
>   HID: core: remove the absolute need of hid_have_special_driver[]
>
>  drivers/hid/Makefile|2 +-
>  drivers/hid/hid-core.c  |  925 ++---
>  drivers/hid/hid-generic.c   |   68 ++-
>  drivers/hid/hid-quirks.c| 1242 
> +++
>  drivers/hid/usbhid/Makefile |2 +-
>  drivers/hid/usbhid/hid-core.c   |   10 +-
>  drivers/hid/usbhid/hid-quirks.c |  401 -
>  include/linux/hid.h |   21 +-
>  net/bluetooth/hidp/core.c   |2 +-
>  9 files changed, 1388 insertions(+), 1285 deletions(-)
>  create mode 100644 drivers/hid/hid-quirks.c
>  delete mode 100644 drivers/hid/usbhid/hid-quirks.c
>
> --
> 2.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] Quirks cleanup and hid-generic niceness

[Benjamin Tissoires]

On Mon, Oct 2, 2017 at 10:18 PM, Fedora Kernel Team
 wrote:

Ouch, I happen to be in a git tree of the Fedora kernel, so git
send-email decided to rewrite the 'from:' field.
I'll add this to my check list before sending :/

Cheers,
Benjamin

> From: Benjamin Tissoires 
>
> Hi,
>
> This is the series I was talking about earlier[1].
>
> Basically, Jiri, I'd like to see 1-3 applied in for-next at your earliest
> convenience, and we can discuss about 4/4 without any rush.
>
> I have this in my local tree since June, but I made some late minute
> changes before sending, though the tests showed they are fine (I wouldn't
> mind a second pair of eyes on it).
>
> I am pretty sure we can optimize the things more, but for now this should be
> just fine and just convert the quirks mechanism in hid-core.
> For instance, there is a second call of hid_lookup_quirk() in 
> usbhid/hid-core.c
> that I am not sure about the absolute need.
>
> Niels, please have a look at this and tell me if you are OK to rebase your
> series on top of it.
>
> Cheers,
> Benjamin
>
>
> [1] https://patchwork.kernel.org/patch/9980443/
>
> Benjamin Tissoires (4):
>   HID: core: move the dynamic quirks handling in core
>   HID: quirks: move the list of special devices into a quirk
>   HID: core: move the list of ignored devices in hid-quirks.c
>   HID: core: remove the absolute need of hid_have_special_driver[]
>
>  drivers/hid/Makefile|2 +-
>  drivers/hid/hid-core.c  |  925 ++---
>  drivers/hid/hid-generic.c   |   68 ++-
>  drivers/hid/hid-quirks.c| 1242 
> +++
>  drivers/hid/usbhid/Makefile |2 +-
>  drivers/hid/usbhid/hid-core.c   |   10 +-
>  drivers/hid/usbhid/hid-quirks.c |  401 -
>  include/linux/hid.h |   21 +-
>  net/bluetooth/hidp/core.c   |2 +-
>  9 files changed, 1388 insertions(+), 1285 deletions(-)
>  create mode 100644 drivers/hid/hid-quirks.c
>  delete mode 100644 drivers/hid/usbhid/hid-quirks.c
>
> --
> 2.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] HID: hid-multitouch: forward MSC_TIMESTAMP

[Benjamin Tissoires]

On Oct 02 2017 or thereabouts, Jiri Kosina wrote:
> On Tue, 22 Aug 2017, Nicolas Boichat wrote:
> 
> > Computes and forwards the device timestamp according to the
> > specification.
> > 
> > Many devices use a 16-bit timestamp field, with a resolution
> > of 100us, therefore rolling around very frequently (every
> > 6.5 seconds). To make sure there is no ambiguity, the
> > timestamp reported to the input stack reset to 0 whenever
> > the time between 2 received events is greater than
> > MAX_TIMESTAMP_INTERVAL (1 second).
> > 
> > Signed-off-by: Nicolas Boichat <drink...@chromium.org>
> 
> > ---
> > 
> > Inspired from Benjamin Tissoires's patch here:
> > https://patchwork.kernel.org/patch/1742181/, and changing the
> > logic to resynchronize the timestamps to use received time
> > instead of a potentially more fragile difference between
> > the 2 deltas.
> 
> Benjamin, any objections on merging this one for 4.15? I like it.
> 

No objections from my side.

Acked-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Re: [PATCH] HID: hid-multitouch: forward MSC_TIMESTAMP

[Benjamin Tissoires]

On Oct 02 2017 or thereabouts, Jiri Kosina wrote:
> On Tue, 22 Aug 2017, Nicolas Boichat wrote:
> 
> > Computes and forwards the device timestamp according to the
> > specification.
> > 
> > Many devices use a 16-bit timestamp field, with a resolution
> > of 100us, therefore rolling around very frequently (every
> > 6.5 seconds). To make sure there is no ambiguity, the
> > timestamp reported to the input stack reset to 0 whenever
> > the time between 2 received events is greater than
> > MAX_TIMESTAMP_INTERVAL (1 second).
> > 
> > Signed-off-by: Nicolas Boichat 
> 
> > ---
> > 
> > Inspired from Benjamin Tissoires's patch here:
> > https://patchwork.kernel.org/patch/1742181/, and changing the
> > logic to resynchronize the timestamps to use received time
> > instead of a potentially more fragile difference between
> > the 2 deltas.
> 
> Benjamin, any objections on merging this one for 4.15? I like it.
> 

No objections from my side.

Acked-by: Benjamin Tissoires 

Cheers,
Benjamin

> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Re: [PATCH 1/1] Revert "HID: multitouch: Support ALPS PTP stick with pid 0x120A"

[Benjamin Tissoires]

On Oct 02 2017 or thereabouts, Kai-Heng Feng wrote:
> This reverts commit fcaa4a07d2a4b541e91da7a55d8b3331f96d1865.
> 
> As noted by Masaki [1], 0x120A + trackpoint will not be used in mass
> production machines, so remove the ID accordingly.
> 
> [1] http://www.spinics.net/lists/linux-input/msg53222.html
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.f...@canonical.com>

Acked-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> ---
>  drivers/hid/hid-ids.h| 1 -
>  drivers/hid/hid-multitouch.c | 4 
>  2 files changed, 5 deletions(-)
> 
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 832897d4a849..a98919199858 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -75,7 +75,6 @@
>  
>  #define USB_VENDOR_ID_ALPS_JP0x044E
>  #define HID_DEVICE_ID_ALPS_U1_DUAL   0x120B
> -#define HID_DEVICE_ID_ALPS_U1_PTP_2  0x120A
>  #define HID_DEVICE_ID_ALPS_U1_DUAL_PTP   0x121F
>  #define HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP  0x1220
>  
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index c78625dceced..9e8c4d2ba11d 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -1419,10 +1419,6 @@ static const struct hid_device_id mt_devices[] = {
>   HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
>   USB_VENDOR_ID_ALPS_JP,
>   HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP) },
> - { .driver_data = MT_CLS_WIN_8_DUAL,
> - HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> - USB_VENDOR_ID_ALPS_JP,
> - HID_DEVICE_ID_ALPS_U1_PTP_2) },
>  
>   /* Lenovo X1 TAB Gen 2 */
>   { .driver_data = MT_CLS_WIN_8_DUAL,
> -- 
> 2.14.2
> 

Re: [PATCH 1/1] Revert "HID: multitouch: Support ALPS PTP stick with pid 0x120A"

[Benjamin Tissoires]

On Oct 02 2017 or thereabouts, Kai-Heng Feng wrote:
> This reverts commit fcaa4a07d2a4b541e91da7a55d8b3331f96d1865.
> 
> As noted by Masaki [1], 0x120A + trackpoint will not be used in mass
> production machines, so remove the ID accordingly.
> 
> [1] http://www.spinics.net/lists/linux-input/msg53222.html
> 
> Signed-off-by: Kai-Heng Feng 

Acked-by: Benjamin Tissoires 

Cheers,
Benjamin

> ---
>  drivers/hid/hid-ids.h| 1 -
>  drivers/hid/hid-multitouch.c | 4 
>  2 files changed, 5 deletions(-)
> 
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 832897d4a849..a98919199858 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -75,7 +75,6 @@
>  
>  #define USB_VENDOR_ID_ALPS_JP0x044E
>  #define HID_DEVICE_ID_ALPS_U1_DUAL   0x120B
> -#define HID_DEVICE_ID_ALPS_U1_PTP_2  0x120A
>  #define HID_DEVICE_ID_ALPS_U1_DUAL_PTP   0x121F
>  #define HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP  0x1220
>  
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index c78625dceced..9e8c4d2ba11d 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -1419,10 +1419,6 @@ static const struct hid_device_id mt_devices[] = {
>   HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
>   USB_VENDOR_ID_ALPS_JP,
>   HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP) },
> - { .driver_data = MT_CLS_WIN_8_DUAL,
> - HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> - USB_VENDOR_ID_ALPS_JP,
> - HID_DEVICE_ID_ALPS_U1_PTP_2) },
>  
>   /* Lenovo X1 TAB Gen 2 */
>   { .driver_data = MT_CLS_WIN_8_DUAL,
> -- 
> 2.14.2
> 

Re: [PATCH] Input: synaptics - Disable kernel tracking on SMBus devices

[Benjamin Tissoires]

On Sep 28 2017 or thereabouts, Andrew Duggan wrote:
> In certain situations kernel tracking seems to be getting confused
> and incorrectly reporting the slot of a contact. On example is when
> the user does a three finger click or tap and then places two fingers
> on the touchpad in the same area. The kernel tracking code seems to
> continue to think that there are three contacts on the touchpad and
> incorrectly alternates the slot of one of the contacts. The result that
> is the input subsystem reports a stream of button press and release
> events as the reported slot changes.
> 
> Kernel tracking was originally enabled to prevent cursor jumps, but it
> is unclear how much of an issue kernel jumps actually are. This patch
> simply disabled kernel tracking for now.
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1482640
> 
> Signed-off-by: Andrew Duggan <adug...@synaptics.com>
> Tested-by: Kamil Páral <kpa...@redhat.com>

Acked-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Thanks Andrew for the patch!

Cheers,
Benjamin

> ---
>  drivers/input/mouse/synaptics.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 5af0b7d..ee5466a 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1709,8 +1709,7 @@ static int synaptics_create_intertouch(struct psmouse 
> *psmouse,
>   .sensor_pdata = {
>   .sensor_type = rmi_sensor_touchpad,
>   .axis_align.flip_y = true,
> - /* to prevent cursors jumps: */
> - .kernel_tracking = true,
> + .kernel_tracking = false,
>   .topbuttonpad = topbuttonpad,
>   },
>   .f30_data = {
> -- 
> 2.7.4
> 

Re: [PATCH] Input: synaptics - Disable kernel tracking on SMBus devices

[Benjamin Tissoires]

On Sep 28 2017 or thereabouts, Andrew Duggan wrote:
> In certain situations kernel tracking seems to be getting confused
> and incorrectly reporting the slot of a contact. On example is when
> the user does a three finger click or tap and then places two fingers
> on the touchpad in the same area. The kernel tracking code seems to
> continue to think that there are three contacts on the touchpad and
> incorrectly alternates the slot of one of the contacts. The result that
> is the input subsystem reports a stream of button press and release
> events as the reported slot changes.
> 
> Kernel tracking was originally enabled to prevent cursor jumps, but it
> is unclear how much of an issue kernel jumps actually are. This patch
> simply disabled kernel tracking for now.
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1482640
> 
> Signed-off-by: Andrew Duggan 
> Tested-by: Kamil Páral 

Acked-by: Benjamin Tissoires 

Thanks Andrew for the patch!

Cheers,
Benjamin

> ---
>  drivers/input/mouse/synaptics.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 5af0b7d..ee5466a 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1709,8 +1709,7 @@ static int synaptics_create_intertouch(struct psmouse 
> *psmouse,
>   .sensor_pdata = {
>   .sensor_type = rmi_sensor_touchpad,
>   .axis_align.flip_y = true,
> - /* to prevent cursors jumps: */
> - .kernel_tracking = true,
> + .kernel_tracking = false,
>   .topbuttonpad = topbuttonpad,
>   },
>   .f30_data = {
> -- 
> 2.7.4
> 

Re: [PATCH] Input: synaptics-rmi4 - pr_err() strings should end with newlines

[Benjamin Tissoires]

Hi Arvind,

On Sep 26 2017 or thereabouts, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/input/rmi4/rmi_f11.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
> index bc5e37f..28296a9 100644
> --- a/drivers/input/rmi4/rmi_f11.c
> +++ b/drivers/input/rmi4/rmi_f11.c
> @@ -596,7 +596,7 @@ static void rmi_f11_finger_handler(struct f11_data *f11,
>   /* Possible of having 4 fingers per f_state register */
>   finger_state = rmi_f11_parse_finger_state(f_state, i);
>   if (finger_state == F11_RESERVED) {
> - pr_err("Invalid finger state[%d]: 0x%02x", i,
> + pr_err("Invalid finger state[%d]: 0x%02x\n", i,

I am pretty sure not having the '\n' is the correct behavior.

Linus recently complained[1] about people trying to "fix" the printk
behavior, and it resulted that any printk will be shown on its own line
(unless there is an other printk with a KERN_CONT marker, which is
unlikely to happen). So basically such patch doesn't add much.

I am also pretty sure there has already been a thread[2 and others]
about these '\n' and from what I can remember, the end result was that
not having the line termination was the preferred syntax.

Cheers,
Benjamin

[1] https://lkml.org/lkml/2017/8/29/504
[2] https://lkml.org/lkml/2010/11/23/394

>   finger_state);
>   continue;
>   }
> -- 
> 1.9.1
> 

Re: [PATCH] Input: synaptics-rmi4 - pr_err() strings should end with newlines

[Benjamin Tissoires]

Hi Arvind,

On Sep 26 2017 or thereabouts, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/input/rmi4/rmi_f11.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
> index bc5e37f..28296a9 100644
> --- a/drivers/input/rmi4/rmi_f11.c
> +++ b/drivers/input/rmi4/rmi_f11.c
> @@ -596,7 +596,7 @@ static void rmi_f11_finger_handler(struct f11_data *f11,
>   /* Possible of having 4 fingers per f_state register */
>   finger_state = rmi_f11_parse_finger_state(f_state, i);
>   if (finger_state == F11_RESERVED) {
> - pr_err("Invalid finger state[%d]: 0x%02x", i,
> + pr_err("Invalid finger state[%d]: 0x%02x\n", i,

I am pretty sure not having the '\n' is the correct behavior.

Linus recently complained[1] about people trying to "fix" the printk
behavior, and it resulted that any printk will be shown on its own line
(unless there is an other printk with a KERN_CONT marker, which is
unlikely to happen). So basically such patch doesn't add much.

I am also pretty sure there has already been a thread[2 and others]
about these '\n' and from what I can remember, the end result was that
not having the line termination was the preferred syntax.

Cheers,
Benjamin

[1] https://lkml.org/lkml/2017/8/29/504
[2] https://lkml.org/lkml/2010/11/23/394

>   finger_state);
>   continue;
>   }
> -- 
> 1.9.1
> 

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

[Benjamin Tissoires]

On Jul 24 2017 or thereabouts, Lyude Paul wrote:
> On Mon, 2017-07-24 at 10:15 +0200, Benjamin Tissoires wrote:
> > On Jul 22 2017 or thereabouts, Lyude wrote:
> > > So it looks like that suspend/resume has actually always been
> > > broken on
> > > hid-rmi. The fact it worked was a rather silly coincidence that was
> > > relying on the HID device to already be opened upon resume. This
> > > means
> > > that so long as anything was reading the /dev/input/eventX node for
> > > for
> > > an RMI device, it would suspend and resume correctly. As well, if
> > > nothing happened to be keeping the HID device away it would shut
> > > off,
> > > then the RMI driver would get confused on resume when it stopped
> > > responding and explode.
> > 
> > Oh, good finding. However, given that there are few other drivers not
> > calling hid_hw_open during their .reset_resume() callback and those
> > drivers also are communicating with the device, I wonder if we should
> > not have something more generic, that will call hid_hw_open/close in
> > the
> > transport layer directly.
> This sounds like a good idea, especially since a call like this is
> rather easy to miss. I will look into doing that for v2

I know I requested a v2, but meanwhile some users are experiencing
delays at resume:
https://bugzilla.kernel.org/show_bug.cgi?id=196851

Jiri, could you take this one in v4.14 (maybe with @stable) and we'll
figure out a way to fix this properly later (looks like the .resume and
.reset_resume are called from the transport drivers, not hid-core, so we
might need a little bit of testing).

In its current form (with the nitpick Andy noticed):
Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> > 
> > I do not recall having seen bugs for Wacom devices, so maybe this is
> > something i2c-hid related, but it wouldn't hurt I guess to open/close
> > the device before calling reset_resume.
> > 
> > Cheers,
> > Benjamin
> > 
> > > 
> > > So, call hid_hw_open() in rmi_post_resume() so we make sure that
> > > the
> > > device is alive before we try talking to it.
> > > 
> > > This fixes RMI device suspend/resume over HID.
> > > 
> > > Signed-off-by: Lyude <ly...@redhat.com>
> > > Cc: Andrew Duggan <adug...@synaptics.com>
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/hid/hid-rmi.c | 15 +++
> > >  1 file changed, 11 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> > > index 5b40c2614599..e7d124f9a27f 100644
> > > --- a/drivers/hid/hid-rmi.c
> > > +++ b/drivers/hid/hid-rmi.c
> > > @@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device
> > > *hdev)
> > >  {
> > >   struct rmi_data *data = hid_get_drvdata(hdev);
> > >   struct rmi_device *rmi_dev = data->xport.rmi_dev;
> > > - int ret;
> > > + int ret = 0;
> > >  
> > >   if (!(data->device_flags & RMI_DEVICE))
> > >   return 0;
> > >  
> > > - ret = rmi_reset_attn_mode(hdev);
> > > + /* Make sure the HID device is ready to receive events */
> > > + ret = hid_hw_open(hdev);
> > >   if (ret)
> > >   return ret;
> > >  
> > > + ret = rmi_reset_attn_mode(hdev);
> > > + if (ret)
> > > + goto out;
> > > +
> > >   ret = rmi_driver_resume(rmi_dev, false);
> > >   if (ret) {
> > >   hid_warn(hdev, "Failed to resume device: %d\n",
> > > ret);
> > > - return ret;
> > > + goto out;
> > >   }
> > >  
> > > - return 0;
> > > +out:
> > > + hid_hw_close(hdev);
> > > + return ret;
> > >  }
> > >  #endif /* CONFIG_PM */
> > >  
> > > -- 
> > > 2.13.3
> > > 

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

[Benjamin Tissoires]

On Jul 24 2017 or thereabouts, Lyude Paul wrote:
> On Mon, 2017-07-24 at 10:15 +0200, Benjamin Tissoires wrote:
> > On Jul 22 2017 or thereabouts, Lyude wrote:
> > > So it looks like that suspend/resume has actually always been
> > > broken on
> > > hid-rmi. The fact it worked was a rather silly coincidence that was
> > > relying on the HID device to already be opened upon resume. This
> > > means
> > > that so long as anything was reading the /dev/input/eventX node for
> > > for
> > > an RMI device, it would suspend and resume correctly. As well, if
> > > nothing happened to be keeping the HID device away it would shut
> > > off,
> > > then the RMI driver would get confused on resume when it stopped
> > > responding and explode.
> > 
> > Oh, good finding. However, given that there are few other drivers not
> > calling hid_hw_open during their .reset_resume() callback and those
> > drivers also are communicating with the device, I wonder if we should
> > not have something more generic, that will call hid_hw_open/close in
> > the
> > transport layer directly.
> This sounds like a good idea, especially since a call like this is
> rather easy to miss. I will look into doing that for v2

I know I requested a v2, but meanwhile some users are experiencing
delays at resume:
https://bugzilla.kernel.org/show_bug.cgi?id=196851

Jiri, could you take this one in v4.14 (maybe with @stable) and we'll
figure out a way to fix this properly later (looks like the .resume and
.reset_resume are called from the transport drivers, not hid-core, so we
might need a little bit of testing).

In its current form (with the nitpick Andy noticed):
Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

> > 
> > I do not recall having seen bugs for Wacom devices, so maybe this is
> > something i2c-hid related, but it wouldn't hurt I guess to open/close
> > the device before calling reset_resume.
> > 
> > Cheers,
> > Benjamin
> > 
> > > 
> > > So, call hid_hw_open() in rmi_post_resume() so we make sure that
> > > the
> > > device is alive before we try talking to it.
> > > 
> > > This fixes RMI device suspend/resume over HID.
> > > 
> > > Signed-off-by: Lyude 
> > > Cc: Andrew Duggan 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/hid/hid-rmi.c | 15 +++
> > >  1 file changed, 11 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> > > index 5b40c2614599..e7d124f9a27f 100644
> > > --- a/drivers/hid/hid-rmi.c
> > > +++ b/drivers/hid/hid-rmi.c
> > > @@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device
> > > *hdev)
> > >  {
> > >   struct rmi_data *data = hid_get_drvdata(hdev);
> > >   struct rmi_device *rmi_dev = data->xport.rmi_dev;
> > > - int ret;
> > > + int ret = 0;
> > >  
> > >   if (!(data->device_flags & RMI_DEVICE))
> > >   return 0;
> > >  
> > > - ret = rmi_reset_attn_mode(hdev);
> > > + /* Make sure the HID device is ready to receive events */
> > > + ret = hid_hw_open(hdev);
> > >   if (ret)
> > >   return ret;
> > >  
> > > + ret = rmi_reset_attn_mode(hdev);
> > > + if (ret)
> > > + goto out;
> > > +
> > >   ret = rmi_driver_resume(rmi_dev, false);
> > >   if (ret) {
> > >   hid_warn(hdev, "Failed to resume device: %d\n",
> > > ret);
> > > - return ret;
> > > + goto out;
> > >   }
> > >  
> > > - return 0;
> > > +out:
> > > + hid_hw_close(hdev);
> > > + return ret;
> > >  }
> > >  #endif /* CONFIG_PM */
> > >  
> > > -- 
> > > 2.13.3
> > > 

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[Benjamin Tissoires]

On Aug 11 2017 or thereabouts, JamChen wrote:
> From: Jam Chen 
> 
> The vendor used the same PID(0x0001) for multiple touch IC controllers.
> The newer ICs can support HID class and report the multitouch collection
> in the descriptor. So they were handled by the hid-multitouch driver.
> But some customized firmwares don't support multitouch protocol even if
> driver have got the Win8 blob data.
> 
> Actually, those ICs only support the single touch function, and report
> the mouse protocol by default. We can assign usbhid to handle them all.
> 
> Signed-off-by: Jam Chen 
> ---

Him

FYI, I'd rather see a full working solution such as the one presented here:
https://patchwork.kernel.org/patch/9876649/

Because this solution is half working as it regresses on some devices
while solving others.

Cheers,
Benjamin

>  drivers/hid/hid-core.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9017dcc14502..df4696022488 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
>*/
>   hid->group = HID_GROUP_RMI;
>   break;
> + case USB_VENDOR_ID_DWAV:
> + if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
> + hid->group = HID_GROUP_GENERIC;
> + break;
>   }
>  
>   /* fall back to generic driver in case specific driver doesn't exist */
> -- 
> 2.11.0
> 

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[Benjamin Tissoires]

On Aug 11 2017 or thereabouts, JamChen wrote:
> From: Jam Chen 
> 
> The vendor used the same PID(0x0001) for multiple touch IC controllers.
> The newer ICs can support HID class and report the multitouch collection
> in the descriptor. So they were handled by the hid-multitouch driver.
> But some customized firmwares don't support multitouch protocol even if
> driver have got the Win8 blob data.
> 
> Actually, those ICs only support the single touch function, and report
> the mouse protocol by default. We can assign usbhid to handle them all.
> 
> Signed-off-by: Jam Chen 
> ---

Him

FYI, I'd rather see a full working solution such as the one presented here:
https://patchwork.kernel.org/patch/9876649/

Because this solution is half working as it regresses on some devices
while solving others.

Cheers,
Benjamin

>  drivers/hid/hid-core.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9017dcc14502..df4696022488 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
>*/
>   hid->group = HID_GROUP_RMI;
>   break;
> + case USB_VENDOR_ID_DWAV:
> + if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
> + hid->group = HID_GROUP_GENERIC;
> + break;
>   }
>  
>   /* fall back to generic driver in case specific driver doesn't exist */
> -- 
> 2.11.0
> 

Re: [PATCH] Input: synaptics - Lenovo Carbon X1 Gen5 (2017) devices should use RMI

[Benjamin Tissoires]

On Aug 18 2017 or thereabouts, Dmitry Torokhov wrote:
> The touchpad on Lenovo Carbon X1 Gen 5 (2017 - Kabylake) is accessible over
> SMBUS/RMI, so let's activate it by default.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com>
> ---

Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

>  drivers/input/mouse/synaptics.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 9a8d81efd329..248c7c9dcbaa 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -172,6 +172,7 @@ static const char * const smbus_pnp_ids[] = {
>   "LEN0048", /* X1 Carbon 3 */
>   "LEN0046", /* X250 */
>   "LEN004a", /* W541 */
> + "LEN0072", /* X1 Carbon Gen 5 (2017) */
>   "LEN200f", /* T450s */
>   NULL
>  };
> -- 
> 2.14.1.480.gb18f417b89-goog
> 
> 
> -- 
> Dmitry

Re: [PATCH] Input: synaptics - Lenovo Carbon X1 Gen5 (2017) devices should use RMI

[Benjamin Tissoires]

On Aug 18 2017 or thereabouts, Dmitry Torokhov wrote:
> The touchpad on Lenovo Carbon X1 Gen 5 (2017 - Kabylake) is accessible over
> SMBUS/RMI, so let's activate it by default.
> 
> Signed-off-by: Dmitry Torokhov 
> ---

Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

>  drivers/input/mouse/synaptics.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 9a8d81efd329..248c7c9dcbaa 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -172,6 +172,7 @@ static const char * const smbus_pnp_ids[] = {
>   "LEN0048", /* X1 Carbon 3 */
>   "LEN0046", /* X250 */
>   "LEN004a", /* W541 */
> + "LEN0072", /* X1 Carbon Gen 5 (2017) */
>   "LEN200f", /* T450s */
>   NULL
>  };
> -- 
> 2.14.1.480.gb18f417b89-goog
> 
> 
> -- 
> Dmitry

Re: [PATCH] HID: asus: Add support for Fn keys on Asus ROG G752

[Benjamin Tissoires]

On Aug 20 2017 or thereabouts, Maxime Bellengé wrote:
> This patch adds support for Fn keys on Asus ROG G752 laptop.
> The report descriptor is broken so I fixed it.
> 
> Tested on an Asus G752VT.
> 
> Signed-off-by: Maxime Bellengé <maxime.belle...@gmail.com>
> ---

Looks good to me:
Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

>  drivers/hid/hid-asus.c | 29 +
>  drivers/hid/hid-core.c |  2 +-
>  drivers/hid/hid-ids.h  |  1 +
>  3 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index a4a3c38bc145..2a03ed842186 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -70,6 +70,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>  #define QUIRK_NO_CONSUMER_USAGES BIT(4)
>  #define QUIRK_USE_KBD_BACKLIGHT  BIT(5)
>  #define QUIRK_T100_KEYBOARD  BIT(6)
> +#define QUIRK_G752_KEYBOARD  BIT(7)
>  
>  #define I2C_KEYBOARD_QUIRKS  (QUIRK_FIX_NOTEBOOK_REPORT | \
>QUIRK_NO_INIT_REPORTS | \
> @@ -568,6 +569,11 @@ static void asus_remove(struct hid_device *hdev)
>   hid_hw_stop(hdev);
>  }
>  
> +static const __u8 asus_g752_fixed_rdesc[] = {
> +0x19, 0x00, /*   Usage Minimum (0x00)   */
> +0x2A, 0xFF, 0x00,   /*   Usage Maximum (0xFF)   */
> +};
> +
>  static __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
>   unsigned int *rsize)
>  {
> @@ -583,6 +589,27 @@ static __u8 *asus_report_fixup(struct hid_device *hdev, 
> __u8 *rdesc,
>   hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
>   rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
>   }
> +if (drvdata->quirks & QUIRK_G752_KEYBOARD &&
> +  *rsize == 75 && rdesc[61] == 0x15 && rdesc[62] == 0x00) {
> +/* report is missing usage mninum and maximum */
> +__u8 *new_rdesc;
> +size_t new_size = *rsize + sizeof(asus_g752_fixed_rdesc);
> +
> +new_rdesc = devm_kzalloc(>dev, new_size, GFP_KERNEL);
> +if (new_rdesc == NULL)
> + return rdesc;
> +
> +hid_info(hdev, "Fixing up Asus G752 keyb report 
> descriptor\n");
> +/* copy the valid part */
> +memcpy(new_rdesc, rdesc, 61);
> +/* insert missing part */
> +memcpy(new_rdesc + 61, asus_g752_fixed_rdesc, 
> sizeof(asus_g752_fixed_rdesc));
> +/* copy remaining data */
> +memcpy(new_rdesc + 61 + sizeof(asus_g752_fixed_rdesc), rdesc 
> + 61, *rsize - 61);
> +
> +*rsize = new_size;
> +rdesc = new_rdesc;
> + }
>  
>   return rdesc;
>  }
> @@ -596,6 +623,8 @@ static const struct hid_device_id asus_devices[] = {
>   USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
>   USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD2), QUIRK_USE_KBD_BACKLIGHT },
> +{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> +USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD3), QUIRK_G752_KEYBOARD },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
>   USB_DEVICE_ID_ASUSTEK_T100_KEYBOARD),
> QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9017dcc14502..45369f5dad6e 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1979,6 +1979,7 @@ static const struct hid_device_id 
> hid_have_special_driver[] = {
>   { HID_I2C_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD2) },
> +{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD3) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_T100_KEYBOARD) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> @@ -3125,4 +3126,3 @@ MODULE_AUTHOR("Andreas Gal");
>  MODULE_AUTHOR("Vojtech Pavlik");
>  MODULE_AUTHOR("Jiri Kosina");
>  MODULE_LICENSE("GPL");
> -
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index c9ba4c6db74c..602409663743 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -180,6 +180,7 @@
>  #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD   0x0101
>  #define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1 0x1854
>  #define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD2 0x1837
> +#define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD3 0x1822
>  
>  #define USB_VENDOR_ID_ATEN   0x0557
>  #define USB_DEVICE_ID_ATEN_UC100KM   0x2004
> -- 
> 2.13.5
> 

Re: [PATCH] HID: asus: Add support for Fn keys on Asus ROG G752

[Benjamin Tissoires]

On Aug 20 2017 or thereabouts, Maxime Bellengé wrote:
> This patch adds support for Fn keys on Asus ROG G752 laptop.
> The report descriptor is broken so I fixed it.
> 
> Tested on an Asus G752VT.
> 
> Signed-off-by: Maxime Bellengé 
> ---

Looks good to me:
Reviewed-by: Benjamin Tissoires 

>  drivers/hid/hid-asus.c | 29 +
>  drivers/hid/hid-core.c |  2 +-
>  drivers/hid/hid-ids.h  |  1 +
>  3 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index a4a3c38bc145..2a03ed842186 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -70,6 +70,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>  #define QUIRK_NO_CONSUMER_USAGES BIT(4)
>  #define QUIRK_USE_KBD_BACKLIGHT  BIT(5)
>  #define QUIRK_T100_KEYBOARD  BIT(6)
> +#define QUIRK_G752_KEYBOARD  BIT(7)
>  
>  #define I2C_KEYBOARD_QUIRKS  (QUIRK_FIX_NOTEBOOK_REPORT | \
>QUIRK_NO_INIT_REPORTS | \
> @@ -568,6 +569,11 @@ static void asus_remove(struct hid_device *hdev)
>   hid_hw_stop(hdev);
>  }
>  
> +static const __u8 asus_g752_fixed_rdesc[] = {
> +0x19, 0x00, /*   Usage Minimum (0x00)   */
> +0x2A, 0xFF, 0x00,   /*   Usage Maximum (0xFF)   */
> +};
> +
>  static __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
>   unsigned int *rsize)
>  {
> @@ -583,6 +589,27 @@ static __u8 *asus_report_fixup(struct hid_device *hdev, 
> __u8 *rdesc,
>   hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
>   rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
>   }
> +if (drvdata->quirks & QUIRK_G752_KEYBOARD &&
> +  *rsize == 75 && rdesc[61] == 0x15 && rdesc[62] == 0x00) {
> +/* report is missing usage mninum and maximum */
> +__u8 *new_rdesc;
> +size_t new_size = *rsize + sizeof(asus_g752_fixed_rdesc);
> +
> +new_rdesc = devm_kzalloc(>dev, new_size, GFP_KERNEL);
> +if (new_rdesc == NULL)
> + return rdesc;
> +
> +hid_info(hdev, "Fixing up Asus G752 keyb report 
> descriptor\n");
> +/* copy the valid part */
> +memcpy(new_rdesc, rdesc, 61);
> +/* insert missing part */
> +memcpy(new_rdesc + 61, asus_g752_fixed_rdesc, 
> sizeof(asus_g752_fixed_rdesc));
> +/* copy remaining data */
> +memcpy(new_rdesc + 61 + sizeof(asus_g752_fixed_rdesc), rdesc 
> + 61, *rsize - 61);
> +
> +*rsize = new_size;
> +rdesc = new_rdesc;
> + }
>  
>   return rdesc;
>  }
> @@ -596,6 +623,8 @@ static const struct hid_device_id asus_devices[] = {
>   USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
>   USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD2), QUIRK_USE_KBD_BACKLIGHT },
> +{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> +USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD3), QUIRK_G752_KEYBOARD },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
>   USB_DEVICE_ID_ASUSTEK_T100_KEYBOARD),
> QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9017dcc14502..45369f5dad6e 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1979,6 +1979,7 @@ static const struct hid_device_id 
> hid_have_special_driver[] = {
>   { HID_I2C_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD2) },
> +{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD3) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, 
> USB_DEVICE_ID_ASUSTEK_T100_KEYBOARD) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> @@ -3125,4 +3126,3 @@ MODULE_AUTHOR("Andreas Gal");
>  MODULE_AUTHOR("Vojtech Pavlik");
>  MODULE_AUTHOR("Jiri Kosina");
>  MODULE_LICENSE("GPL");
> -
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index c9ba4c6db74c..602409663743 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -180,6 +180,7 @@
>  #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD   0x0101
>  #define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1 0x1854
>  #define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD2 0x1837
> +#define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD3 0x1822
>  
>  #define USB_VENDOR_ID_ATEN   0x0557
>  #define USB_DEVICE_ID_ATEN_UC100KM   0x2004
> -- 
> 2.13.5
> 

Re: [PATCH 2/2] HID: multitouch: Support Asus T304UA media keys

[Benjamin Tissoires]

On Aug 02 2017 or thereabouts, Jiri Kosina wrote:
> On Mon, 24 Jul 2017, João Paulo Rechi Vita wrote:
> 
> > The Asus T304UA convertible sports a magnetic detachable keyboard with
> > touchpad, which is connected over USB. Most of the keyboard hotkeys are
> > exposed through the same USB interface as the touchpad, defined in the
> > report descriptor as follows:
> > 
> > 0x06, 0x31, 0xFF,  // Usage Page (Vendor Defined 0xFF31)
> > 0x09, 0x76,// Usage (0x76)
> > 0xA1, 0x01,// Collection (Application)
> > 0x05, 0xFF,//   Usage Page (Reserved 0xFF)
> > 0x85, 0x5A,//   Report ID (90)
> > 0x19, 0x00,//   Usage Minimum (0x00)
> > 0x2A, 0xFF, 0x00,  //   Usage Maximum (0xFF)
> > 0x15, 0x00,//   Logical Minimum (0)
> > 0x26, 0xFF, 0x00,  //   Logical Maximum (255)
> > 0x75, 0x08,//   Report Size (8)
> > 0x95, 0x0F,//   Report Count (15)
> > 0xB1, 0x02,//   Feature (Data,Var,Abs,No Wrap,Linear,Preferred 
> > State,No Null Position,Non-volatile)
> > 0x05, 0xFF,//   Usage Page (Reserved 0xFF)
> > 0x85, 0x5A,//   Report ID (90)
> > 0x19, 0x00,//   Usage Minimum (0x00)
> > 0x2A, 0xFF, 0x00,  //   Usage Maximum (0xFF)
> > 0x15, 0x00,//   Logical Minimum (0)
> > 0x26, 0xFF, 0x00,  //   Logical Maximum (255)
> > 0x75, 0x08,//   Report Size (8)
> > 0x95, 0x02,//   Report Count (2)
> > 0x81, 0x02,//   Input (Data,Var,Abs,No Wrap,Linear,Preferred 
> > State,No Null Position)
> > 0xC0,  // End Collection
> > 
> > This UsagePage is declared as a variable, but we need to treat it as an
> > array to be able to map each Usage we care about to its corresponding
> > input key.
> > 
> > Signed-off-by: João Paulo Rechi Vita 
> > ---
> >  drivers/hid/hid-ids.h|  1 +
> >  drivers/hid/hid-multitouch.c | 44 
> > +++-
> >  include/linux/hid.h  |  2 ++
> >  3 files changed, 46 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 3d911bfd91cf..6b7f9707076e 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -176,6 +176,7 @@
> >  #define USB_DEVICE_ID_ASUSTEK_LCM  0x1726
> >  #define USB_DEVICE_ID_ASUSTEK_LCM2 0x175b
> >  #define USB_DEVICE_ID_ASUSTEK_T100_KEYBOARD0x17e0
> > +#define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD0x184a
> >  #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> >  #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> >  #define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1 0x1854
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 152d33120a55..6b3de7b01571 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -72,6 +72,7 @@ MODULE_LICENSE("GPL");
> >  #define MT_QUIRK_FIX_CONST_CONTACT_ID  BIT(14)
> >  #define MT_QUIRK_TOUCH_SIZE_SCALINGBIT(15)
> >  #define MT_QUIRK_STICKY_FINGERSBIT(16)
> > +#define MT_QUIRK_ASUS_CUSTOM_UPBIT(17)
> >  
> >  #define MT_INPUTMODE_TOUCHSCREEN   0x02
> >  #define MT_INPUTMODE_TOUCHPAD  0x03
> > @@ -169,6 +170,7 @@ static void mt_post_parse(struct mt_device *td);
> >  #define MT_CLS_GENERALTOUCH_TWOFINGERS 0x0108
> >  #define MT_CLS_GENERALTOUCH_PWT_TENFINGERS 0x0109
> >  #define MT_CLS_LG  0x010a
> > +#define MT_CLS_ASUS0x010b
> >  #define MT_CLS_VTL 0x0110
> >  #define MT_CLS_GOOGLE  0x0111
> >  
> > @@ -290,6 +292,10 @@ static struct mt_class mt_classes[] = {
> > MT_QUIRK_IGNORE_DUPLICATES |
> > MT_QUIRK_HOVERING |
> > MT_QUIRK_CONTACT_CNT_ACCURATE },
> > +   { .name = MT_CLS_ASUS,
> > +   .quirks = MT_QUIRK_ALWAYS_VALID |
> > +   MT_QUIRK_CONTACT_CNT_ACCURATE |
> > +   MT_QUIRK_ASUS_CUSTOM_UP },
> > { .name = MT_CLS_VTL,
> > .quirks = MT_QUIRK_ALWAYS_VALID |
> > MT_QUIRK_CONTACT_CNT_ACCURATE |
> > @@ -905,6 +911,8 @@ static int mt_touch_input_configured(struct hid_device 
> > *hdev,
> > return 0;
> >  }
> >  
> > +#define mt_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, \
> > +   max, EV_KEY, (c))
> >  static int mt_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> > struct hid_field *field, struct hid_usage *usage,
> > unsigned long **bit, int *max)
> > @@ -923,10 +931,35 @@ static int mt_input_mapping(struct hid_device *hdev, 
> > struct hid_input *hi,
> > field->application != HID_DG_TOUCHPAD &&
> > field->application != HID_GD_KEYBOARD &&
> > field->application != HID_CP_CONSUMER_CONTROL &&
> > -   field->application != HID_GD_WIRELESS_RADIO_CTLS)
> > +   field->application != 

Re: [PATCH 2/2] HID: multitouch: Support Asus T304UA media keys

[Benjamin Tissoires]

On Aug 02 2017 or thereabouts, Jiri Kosina wrote:
> On Mon, 24 Jul 2017, João Paulo Rechi Vita wrote:
> 
> > The Asus T304UA convertible sports a magnetic detachable keyboard with
> > touchpad, which is connected over USB. Most of the keyboard hotkeys are
> > exposed through the same USB interface as the touchpad, defined in the
> > report descriptor as follows:
> > 
> > 0x06, 0x31, 0xFF,  // Usage Page (Vendor Defined 0xFF31)
> > 0x09, 0x76,// Usage (0x76)
> > 0xA1, 0x01,// Collection (Application)
> > 0x05, 0xFF,//   Usage Page (Reserved 0xFF)
> > 0x85, 0x5A,//   Report ID (90)
> > 0x19, 0x00,//   Usage Minimum (0x00)
> > 0x2A, 0xFF, 0x00,  //   Usage Maximum (0xFF)
> > 0x15, 0x00,//   Logical Minimum (0)
> > 0x26, 0xFF, 0x00,  //   Logical Maximum (255)
> > 0x75, 0x08,//   Report Size (8)
> > 0x95, 0x0F,//   Report Count (15)
> > 0xB1, 0x02,//   Feature (Data,Var,Abs,No Wrap,Linear,Preferred 
> > State,No Null Position,Non-volatile)
> > 0x05, 0xFF,//   Usage Page (Reserved 0xFF)
> > 0x85, 0x5A,//   Report ID (90)
> > 0x19, 0x00,//   Usage Minimum (0x00)
> > 0x2A, 0xFF, 0x00,  //   Usage Maximum (0xFF)
> > 0x15, 0x00,//   Logical Minimum (0)
> > 0x26, 0xFF, 0x00,  //   Logical Maximum (255)
> > 0x75, 0x08,//   Report Size (8)
> > 0x95, 0x02,//   Report Count (2)
> > 0x81, 0x02,//   Input (Data,Var,Abs,No Wrap,Linear,Preferred 
> > State,No Null Position)
> > 0xC0,  // End Collection
> > 
> > This UsagePage is declared as a variable, but we need to treat it as an
> > array to be able to map each Usage we care about to its corresponding
> > input key.
> > 
> > Signed-off-by: João Paulo Rechi Vita 
> > ---
> >  drivers/hid/hid-ids.h|  1 +
> >  drivers/hid/hid-multitouch.c | 44 
> > +++-
> >  include/linux/hid.h  |  2 ++
> >  3 files changed, 46 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 3d911bfd91cf..6b7f9707076e 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -176,6 +176,7 @@
> >  #define USB_DEVICE_ID_ASUSTEK_LCM  0x1726
> >  #define USB_DEVICE_ID_ASUSTEK_LCM2 0x175b
> >  #define USB_DEVICE_ID_ASUSTEK_T100_KEYBOARD0x17e0
> > +#define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD0x184a
> >  #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> >  #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> >  #define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1 0x1854
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 152d33120a55..6b3de7b01571 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -72,6 +72,7 @@ MODULE_LICENSE("GPL");
> >  #define MT_QUIRK_FIX_CONST_CONTACT_ID  BIT(14)
> >  #define MT_QUIRK_TOUCH_SIZE_SCALINGBIT(15)
> >  #define MT_QUIRK_STICKY_FINGERSBIT(16)
> > +#define MT_QUIRK_ASUS_CUSTOM_UPBIT(17)
> >  
> >  #define MT_INPUTMODE_TOUCHSCREEN   0x02
> >  #define MT_INPUTMODE_TOUCHPAD  0x03
> > @@ -169,6 +170,7 @@ static void mt_post_parse(struct mt_device *td);
> >  #define MT_CLS_GENERALTOUCH_TWOFINGERS 0x0108
> >  #define MT_CLS_GENERALTOUCH_PWT_TENFINGERS 0x0109
> >  #define MT_CLS_LG  0x010a
> > +#define MT_CLS_ASUS0x010b
> >  #define MT_CLS_VTL 0x0110
> >  #define MT_CLS_GOOGLE  0x0111
> >  
> > @@ -290,6 +292,10 @@ static struct mt_class mt_classes[] = {
> > MT_QUIRK_IGNORE_DUPLICATES |
> > MT_QUIRK_HOVERING |
> > MT_QUIRK_CONTACT_CNT_ACCURATE },
> > +   { .name = MT_CLS_ASUS,
> > +   .quirks = MT_QUIRK_ALWAYS_VALID |
> > +   MT_QUIRK_CONTACT_CNT_ACCURATE |
> > +   MT_QUIRK_ASUS_CUSTOM_UP },
> > { .name = MT_CLS_VTL,
> > .quirks = MT_QUIRK_ALWAYS_VALID |
> > MT_QUIRK_CONTACT_CNT_ACCURATE |
> > @@ -905,6 +911,8 @@ static int mt_touch_input_configured(struct hid_device 
> > *hdev,
> > return 0;
> >  }
> >  
> > +#define mt_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, \
> > +   max, EV_KEY, (c))
> >  static int mt_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> > struct hid_field *field, struct hid_usage *usage,
> > unsigned long **bit, int *max)
> > @@ -923,10 +931,35 @@ static int mt_input_mapping(struct hid_device *hdev, 
> > struct hid_input *hi,
> > field->application != HID_DG_TOUCHPAD &&
> > field->application != HID_GD_KEYBOARD &&
> > field->application != HID_CP_CONSUMER_CONTROL &&
> > -   field->application != HID_GD_WIRELESS_RADIO_CTLS)
> > +   field->application != HID_GD_WIRELESS_RADIO_CTLS &&
> > 

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

[Benjamin Tissoires]

On Jul 22 2017 or thereabouts, Lyude wrote:
> So it looks like that suspend/resume has actually always been broken on
> hid-rmi. The fact it worked was a rather silly coincidence that was
> relying on the HID device to already be opened upon resume. This means
> that so long as anything was reading the /dev/input/eventX node for for
> an RMI device, it would suspend and resume correctly. As well, if
> nothing happened to be keeping the HID device away it would shut off,
> then the RMI driver would get confused on resume when it stopped
> responding and explode.

Oh, good finding. However, given that there are few other drivers not
calling hid_hw_open during their .reset_resume() callback and those
drivers also are communicating with the device, I wonder if we should
not have something more generic, that will call hid_hw_open/close in the
transport layer directly.

I do not recall having seen bugs for Wacom devices, so maybe this is
something i2c-hid related, but it wouldn't hurt I guess to open/close
the device before calling reset_resume.

Cheers,
Benjamin

> 
> So, call hid_hw_open() in rmi_post_resume() so we make sure that the
> device is alive before we try talking to it.
> 
> This fixes RMI device suspend/resume over HID.
> 
> Signed-off-by: Lyude 
> Cc: Andrew Duggan 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/hid/hid-rmi.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 5b40c2614599..e7d124f9a27f 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device *hdev)
>  {
>   struct rmi_data *data = hid_get_drvdata(hdev);
>   struct rmi_device *rmi_dev = data->xport.rmi_dev;
> - int ret;
> + int ret = 0;
>  
>   if (!(data->device_flags & RMI_DEVICE))
>   return 0;
>  
> - ret = rmi_reset_attn_mode(hdev);
> + /* Make sure the HID device is ready to receive events */
> + ret = hid_hw_open(hdev);
>   if (ret)
>   return ret;
>  
> + ret = rmi_reset_attn_mode(hdev);
> + if (ret)
> + goto out;
> +
>   ret = rmi_driver_resume(rmi_dev, false);
>   if (ret) {
>   hid_warn(hdev, "Failed to resume device: %d\n", ret);
> - return ret;
> + goto out;
>   }
>  
> - return 0;
> +out:
> + hid_hw_close(hdev);
> + return ret;
>  }
>  #endif /* CONFIG_PM */
>  
> -- 
> 2.13.3
> 

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

[Benjamin Tissoires]

On Jul 22 2017 or thereabouts, Lyude wrote:
> So it looks like that suspend/resume has actually always been broken on
> hid-rmi. The fact it worked was a rather silly coincidence that was
> relying on the HID device to already be opened upon resume. This means
> that so long as anything was reading the /dev/input/eventX node for for
> an RMI device, it would suspend and resume correctly. As well, if
> nothing happened to be keeping the HID device away it would shut off,
> then the RMI driver would get confused on resume when it stopped
> responding and explode.

Oh, good finding. However, given that there are few other drivers not
calling hid_hw_open during their .reset_resume() callback and those
drivers also are communicating with the device, I wonder if we should
not have something more generic, that will call hid_hw_open/close in the
transport layer directly.

I do not recall having seen bugs for Wacom devices, so maybe this is
something i2c-hid related, but it wouldn't hurt I guess to open/close
the device before calling reset_resume.

Cheers,
Benjamin

> 
> So, call hid_hw_open() in rmi_post_resume() so we make sure that the
> device is alive before we try talking to it.
> 
> This fixes RMI device suspend/resume over HID.
> 
> Signed-off-by: Lyude 
> Cc: Andrew Duggan 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/hid/hid-rmi.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 5b40c2614599..e7d124f9a27f 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device *hdev)
>  {
>   struct rmi_data *data = hid_get_drvdata(hdev);
>   struct rmi_device *rmi_dev = data->xport.rmi_dev;
> - int ret;
> + int ret = 0;
>  
>   if (!(data->device_flags & RMI_DEVICE))
>   return 0;
>  
> - ret = rmi_reset_attn_mode(hdev);
> + /* Make sure the HID device is ready to receive events */
> + ret = hid_hw_open(hdev);
>   if (ret)
>   return ret;
>  
> + ret = rmi_reset_attn_mode(hdev);
> + if (ret)
> + goto out;
> +
>   ret = rmi_driver_resume(rmi_dev, false);
>   if (ret) {
>   hid_warn(hdev, "Failed to resume device: %d\n", ret);
> - return ret;
> + goto out;
>   }
>  
> - return 0;
> +out:
> + hid_hw_close(hdev);
> + return ret;
>  }
>  #endif /* CONFIG_PM */
>  
> -- 
> 2.13.3
> 

Re: [PATCH] HID: logitech-hidpp: fix spelling mistake, "feeback" -> "feedback"

[Benjamin Tissoires]

On Jul 14 2017 or thereabouts, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> Trivial fix to spelling mistake in hid_info message and add line break
> to split an overly long line to clean up a checkpatch warning.
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---

Acked-By: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

>  drivers/hid/hid-logitech-hidpp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 41b39464ded8..8d7a1a5ef427 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -1957,7 +1957,8 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 
> feature_index)
>   /* initialize with zero autocenter to get wheel in usable state */
>   hidpp_ff_set_autocenter(dev, 0);
>  
> - hid_info(hid, "Force feeback support loaded (firmware release %d).\n", 
> version);
> + hid_info(hid, "Force feedback support loaded (firmware release %d).\n",
> +  version);
>  
>   return 0;
>  }
> -- 
> 2.11.0
> 

Re: [PATCH] HID: logitech-hidpp: fix spelling mistake, "feeback" -> "feedback"

[Benjamin Tissoires]

On Jul 14 2017 or thereabouts, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in hid_info message and add line break
> to split an overly long line to clean up a checkpatch warning.
> 
> Signed-off-by: Colin Ian King 
> ---

Acked-By: Benjamin Tissoires 

>  drivers/hid/hid-logitech-hidpp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 41b39464ded8..8d7a1a5ef427 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -1957,7 +1957,8 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 
> feature_index)
>   /* initialize with zero autocenter to get wheel in usable state */
>   hidpp_ff_set_autocenter(dev, 0);
>  
> - hid_info(hid, "Force feeback support loaded (firmware release %d).\n", 
> version);
> + hid_info(hid, "Force feedback support loaded (firmware release %d).\n",
> +  version);
>  
>   return 0;
>  }
> -- 
> 2.11.0
> 

Re: [PATCH] HID: usbhid: fix "always poll" quirk

[Benjamin Tissoires]

On Jul 12 2017 or thereabouts, Dmitry Torokhov wrote:
> Even though the IO for devices with "always poll" quirk is already running,
> we still need to set HID_OPENED bit in usbhid->iofl so the interrupt
> handler does not ignore the data coming from the device.
> 
> Reported-by: Olof Johansson <o...@lixom.net>
> Tested-by: Olof Johansson <o...@lixom.net>
> Fixes: e399396a6b0 ("HID: usbhid: remove custom locking from usbhid_open...")
> Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com>
> ---

slightly reviewed and
Acked-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

>  drivers/hid/usbhid/hid-core.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 76013eb5cb7f..c008847e0b20 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -680,18 +680,21 @@ static int usbhid_open(struct hid_device *hid)
>   struct usbhid_device *usbhid = hid->driver_data;
>   int res;
>  
> + set_bit(HID_OPENED, >iofl);
> +
>   if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
>   return 0;
>  
>   res = usb_autopm_get_interface(usbhid->intf);
>   /* the device must be awake to reliably request remote wakeup */
> - if (res < 0)
> + if (res < 0) {
> + clear_bit(HID_OPENED, >iofl);
>   return -EIO;
> + }
>  
>   usbhid->intf->needs_remote_wakeup = 1;
>  
>   set_bit(HID_RESUME_RUNNING, >iofl);
> - set_bit(HID_OPENED, >iofl);
>   set_bit(HID_IN_POLLING, >iofl);
>  
>   res = hid_start_in(hid);
> @@ -727,19 +730,20 @@ static void usbhid_close(struct hid_device *hid)
>  {
>   struct usbhid_device *usbhid = hid->driver_data;
>  
> - if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
> - return;
> -
>   /*
>* Make sure we don't restart data acquisition due to
>* a resumption we no longer care about by avoiding racing
>* with hid_start_in().
>*/
>   spin_lock_irq(>lock);
> - clear_bit(HID_IN_POLLING, >iofl);
>   clear_bit(HID_OPENED, >iofl);
> + if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL))
> + clear_bit(HID_IN_POLLING, >iofl);
>   spin_unlock_irq(>lock);
>  
> + if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
> + return;
> +
>   hid_cancel_delayed_stuff(usbhid);
>   usb_kill_urb(usbhid->urbin);
>   usbhid->intf->needs_remote_wakeup = 0;
> -- 
> 2.13.2.932.g7449e964c-goog
> 
> 
> -- 
> Dmitry

Re: [PATCH] HID: usbhid: fix "always poll" quirk

[Benjamin Tissoires]

On Jul 12 2017 or thereabouts, Dmitry Torokhov wrote:
> Even though the IO for devices with "always poll" quirk is already running,
> we still need to set HID_OPENED bit in usbhid->iofl so the interrupt
> handler does not ignore the data coming from the device.
> 
> Reported-by: Olof Johansson 
> Tested-by: Olof Johansson 
> Fixes: e399396a6b0 ("HID: usbhid: remove custom locking from usbhid_open...")
> Signed-off-by: Dmitry Torokhov 
> ---

slightly reviewed and
Acked-by: Benjamin Tissoires 

Cheers,
Benjamin

>  drivers/hid/usbhid/hid-core.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 76013eb5cb7f..c008847e0b20 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -680,18 +680,21 @@ static int usbhid_open(struct hid_device *hid)
>   struct usbhid_device *usbhid = hid->driver_data;
>   int res;
>  
> + set_bit(HID_OPENED, >iofl);
> +
>   if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
>   return 0;
>  
>   res = usb_autopm_get_interface(usbhid->intf);
>   /* the device must be awake to reliably request remote wakeup */
> - if (res < 0)
> + if (res < 0) {
> + clear_bit(HID_OPENED, >iofl);
>   return -EIO;
> + }
>  
>   usbhid->intf->needs_remote_wakeup = 1;
>  
>   set_bit(HID_RESUME_RUNNING, >iofl);
> - set_bit(HID_OPENED, >iofl);
>   set_bit(HID_IN_POLLING, >iofl);
>  
>   res = hid_start_in(hid);
> @@ -727,19 +730,20 @@ static void usbhid_close(struct hid_device *hid)
>  {
>   struct usbhid_device *usbhid = hid->driver_data;
>  
> - if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
> - return;
> -
>   /*
>* Make sure we don't restart data acquisition due to
>* a resumption we no longer care about by avoiding racing
>* with hid_start_in().
>*/
>   spin_lock_irq(>lock);
> - clear_bit(HID_IN_POLLING, >iofl);
>   clear_bit(HID_OPENED, >iofl);
> + if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL))
> + clear_bit(HID_IN_POLLING, >iofl);
>   spin_unlock_irq(>lock);
>  
> + if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
> + return;
> +
>   hid_cancel_delayed_stuff(usbhid);
>   usb_kill_urb(usbhid->urbin);
>   usbhid->intf->needs_remote_wakeup = 0;
> -- 
> 2.13.2.932.g7449e964c-goog
> 
> 
> -- 
> Dmitry

[PATCH] HID: ortek: add one more buggy device

[Benjamin Tissoires]

The iHome keypad also requires the same tweak we are doing for other
Ortek devices.

Reported-by: Mairin Duffy <du...@redhat.com>

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
---
 drivers/hid/hid-core.c  | 1 +
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/hid-ortek.c | 6 --
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 74af0b3..b8e7d31 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2220,6 +2220,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
 #if IS_ENABLED(CONFIG_HID_ORTEK)
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_PKB1700) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_WKB2000) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, 
USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SKYCABLE, 
USB_DEVICE_ID_SKYCABLE_WIRELESS_PRESENTER) },
 #endif
 #if IS_ENABLED(CONFIG_HID_PANTHERLORD)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 021ab80..5560978 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -828,6 +828,7 @@
 #define USB_VENDOR_ID_ORTEK0x05a4
 #define USB_DEVICE_ID_ORTEK_PKB17000x1700
 #define USB_DEVICE_ID_ORTEK_WKB20000x2000
+#define USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S   0x8003
 
 #define USB_VENDOR_ID_PLANTRONICS  0x047f
 
diff --git a/drivers/hid/hid-ortek.c b/drivers/hid/hid-ortek.c
index 6620f15..8783a06 100644
--- a/drivers/hid/hid-ortek.c
+++ b/drivers/hid/hid-ortek.c
@@ -5,6 +5,7 @@
  *
  *Ortek PKB-1700
  *Ortek WKB-2000
+ *iHome IMAC-A210S
  *Skycable wireless presenter
  *
  *  Copyright (c) 2010 Johnathon Harris <jmhar...@gmail.com>
@@ -28,10 +29,10 @@ static __u8 *ortek_report_fixup(struct hid_device *hdev, 
__u8 *rdesc,
unsigned int *rsize)
 {
if (*rsize >= 56 && rdesc[54] == 0x25 && rdesc[55] == 0x01) {
-   hid_info(hdev, "Fixing up logical minimum in report descriptor 
(Ortek)\n");
+   hid_info(hdev, "Fixing up logical maximum in report descriptor 
(Ortek)\n");
rdesc[55] = 0x92;
} else if (*rsize >= 54 && rdesc[52] == 0x25 && rdesc[53] == 0x01) {
-   hid_info(hdev, "Fixing up logical minimum in report descriptor 
(Skycable)\n");
+   hid_info(hdev, "Fixing up logical maximum in report descriptor 
(Skycable)\n");
rdesc[53] = 0x65;
}
return rdesc;
@@ -40,6 +41,7 @@ static __u8 *ortek_report_fixup(struct hid_device *hdev, __u8 
*rdesc,
 static const struct hid_device_id ortek_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_PKB1700) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_WKB2000) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, 
USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SKYCABLE, 
USB_DEVICE_ID_SKYCABLE_WIRELESS_PRESENTER) },
{ }
 };
-- 
2.9.4

[PATCH] HID: ortek: add one more buggy device

[Benjamin Tissoires]

The iHome keypad also requires the same tweak we are doing for other
Ortek devices.

Reported-by: Mairin Duffy 

Signed-off-by: Benjamin Tissoires 
---
 drivers/hid/hid-core.c  | 1 +
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/hid-ortek.c | 6 --
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 74af0b3..b8e7d31 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2220,6 +2220,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
 #if IS_ENABLED(CONFIG_HID_ORTEK)
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_PKB1700) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_WKB2000) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, 
USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SKYCABLE, 
USB_DEVICE_ID_SKYCABLE_WIRELESS_PRESENTER) },
 #endif
 #if IS_ENABLED(CONFIG_HID_PANTHERLORD)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 021ab80..5560978 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -828,6 +828,7 @@
 #define USB_VENDOR_ID_ORTEK0x05a4
 #define USB_DEVICE_ID_ORTEK_PKB17000x1700
 #define USB_DEVICE_ID_ORTEK_WKB20000x2000
+#define USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S   0x8003
 
 #define USB_VENDOR_ID_PLANTRONICS  0x047f
 
diff --git a/drivers/hid/hid-ortek.c b/drivers/hid/hid-ortek.c
index 6620f15..8783a06 100644
--- a/drivers/hid/hid-ortek.c
+++ b/drivers/hid/hid-ortek.c
@@ -5,6 +5,7 @@
  *
  *Ortek PKB-1700
  *Ortek WKB-2000
+ *iHome IMAC-A210S
  *Skycable wireless presenter
  *
  *  Copyright (c) 2010 Johnathon Harris 
@@ -28,10 +29,10 @@ static __u8 *ortek_report_fixup(struct hid_device *hdev, 
__u8 *rdesc,
unsigned int *rsize)
 {
if (*rsize >= 56 && rdesc[54] == 0x25 && rdesc[55] == 0x01) {
-   hid_info(hdev, "Fixing up logical minimum in report descriptor 
(Ortek)\n");
+   hid_info(hdev, "Fixing up logical maximum in report descriptor 
(Ortek)\n");
rdesc[55] = 0x92;
} else if (*rsize >= 54 && rdesc[52] == 0x25 && rdesc[53] == 0x01) {
-   hid_info(hdev, "Fixing up logical minimum in report descriptor 
(Skycable)\n");
+   hid_info(hdev, "Fixing up logical maximum in report descriptor 
(Skycable)\n");
rdesc[53] = 0x65;
}
return rdesc;
@@ -40,6 +41,7 @@ static __u8 *ortek_report_fixup(struct hid_device *hdev, __u8 
*rdesc,
 static const struct hid_device_id ortek_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_PKB1700) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_WKB2000) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, 
USB_DEVICE_ID_ORTEK_IHOME_IMAC_A210S) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SKYCABLE, 
USB_DEVICE_ID_SKYCABLE_WIRELESS_PRESENTER) },
{ }
 };
-- 
2.9.4

Re: [PATCH] HID: hid-logitech-hidpp: add NULL check on devm_kmemdup() return value

[Benjamin Tissoires]

On Jul 07 2017 or thereabouts, Gustavo A. R. Silva wrote:
> Check return value from call to devm_kmemdup()
> in order to prevent a NULL pointer dereference.
> 
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>
> ---

Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

>  drivers/hid/hid-logitech-hidpp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 41b3946..501e16a 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2732,6 +2732,9 @@ static int hidpp_initialize_battery(struct hidpp_device 
> *hidpp)
>hidpp_battery_props,
>sizeof(hidpp_battery_props),
>GFP_KERNEL);
> + if (!battery_props)
> + return -ENOMEM;
> +
>   num_battery_props = ARRAY_SIZE(hidpp_battery_props) - 2;
>  
>   if (hidpp->capabilities & HIDPP_CAPABILITY_BATTERY_MILEAGE)
> -- 
> 2.5.0
> 

Re: [PATCH] HID: hid-logitech-hidpp: add NULL check on devm_kmemdup() return value

[Benjamin Tissoires]

On Jul 07 2017 or thereabouts, Gustavo A. R. Silva wrote:
> Check return value from call to devm_kmemdup()
> in order to prevent a NULL pointer dereference.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---

Reviewed-by: Benjamin Tissoires 

>  drivers/hid/hid-logitech-hidpp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 41b3946..501e16a 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2732,6 +2732,9 @@ static int hidpp_initialize_battery(struct hidpp_device 
> *hidpp)
>hidpp_battery_props,
>sizeof(hidpp_battery_props),
>GFP_KERNEL);
> + if (!battery_props)
> + return -ENOMEM;
> +
>   num_battery_props = ARRAY_SIZE(hidpp_battery_props) - 2;
>  
>   if (hidpp->capabilities & HIDPP_CAPABILITY_BATTERY_MILEAGE)
> -- 
> 2.5.0
> 

Re: [PATCH RESEND] HID: wacom: Remove comparison of u8 mode with zero and simplify.

[Benjamin Tissoires]

On Jul 08 2017 or thereabouts, Christos Gkekas wrote:
> Variable mode in method wacom_show_remote_mode() is defined as u8, thus
> statement (mode >= 0) is always true and should be removed, simplifying
> the logic.
> 
> Signed-off-by: Christos Gkekas <chris.ge...@gmail.com>
> ---

Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

>  drivers/hid/wacom_sys.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 838c1eb..ae2408d 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -1671,10 +1671,7 @@ static ssize_t wacom_show_remote_mode(struct kobject 
> *kobj,
>   u8 mode;
>  
>   mode = wacom->led.groups[index].select;
> - if (mode >= 0 && mode < 3)
> - return snprintf(buf, PAGE_SIZE, "%d\n", mode);
> - else
> - return snprintf(buf, PAGE_SIZE, "%d\n", -1);
> + return sprintf(buf, "%d\n", mode < 3 ? mode : -1);
>  }
>  
>  #define DEVICE_EKR_ATTR_GROUP(SET_ID)
> \
> -- 
> 2.7.4
> 

Re: [PATCH RESEND] HID: wacom: Remove comparison of u8 mode with zero and simplify.

[Benjamin Tissoires]

On Jul 08 2017 or thereabouts, Christos Gkekas wrote:
> Variable mode in method wacom_show_remote_mode() is defined as u8, thus
> statement (mode >= 0) is always true and should be removed, simplifying
> the logic.
> 
> Signed-off-by: Christos Gkekas 
> ---

Reviewed-by: Benjamin Tissoires 

>  drivers/hid/wacom_sys.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 838c1eb..ae2408d 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -1671,10 +1671,7 @@ static ssize_t wacom_show_remote_mode(struct kobject 
> *kobj,
>   u8 mode;
>  
>   mode = wacom->led.groups[index].select;
> - if (mode >= 0 && mode < 3)
> - return snprintf(buf, PAGE_SIZE, "%d\n", mode);
> - else
> - return snprintf(buf, PAGE_SIZE, "%d\n", -1);
> + return sprintf(buf, "%d\n", mode < 3 ? mode : -1);
>  }
>  
>  #define DEVICE_EKR_ATTR_GROUP(SET_ID)
> \
> -- 
> 2.7.4
> 

Re: [PATCH] HID: multitouch: do not blindly set EV_KEY or EV_ABS bits

[Benjamin Tissoires]

On Jul 11 2017 or thereabouts, Dmitry Torokhov wrote:
> Now that input core insists on having dev->absinfo when device claims to
> generate EV_ABS in its dev->evbit, we should not be blindly setting that
> bit.
> 
> The code in question might have been needed before input_set_abs_params()
> started setting EV_ABS in device's evbit, but not anymore, and is now
> breaking devices such as SMART SPNL-6075 Touchscreen.
> 
> Fixes: 6ecfe51b4082 ("Input: refuse to register absolute devices ...")
> Reported-by: Matthias Fend <matthias.f...@wolfvision.net>
> Tested-by: Matthias Fend <matthias.f...@wolfvision.net>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com>
> ---
> 
> Jiri, Benjamin, I marked it for stable as it causes regressions in 4.12
> reported by users. Please take a look.

set_bit(usage->type, input->evbit); is called by hid-input.c when the
return code is positive, so we should be safe here.

Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

> 
>  drivers/hid/hid-multitouch.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 24d5b6deb571..be5bea15ce52 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -595,16 +595,6 @@ static int mt_touch_input_mapping(struct hid_device 
> *hdev, struct hid_input *hi,
>   return 0;
>  }
>  
> -static int mt_touch_input_mapped(struct hid_device *hdev, struct hid_input 
> *hi,
> - struct hid_field *field, struct hid_usage *usage,
> - unsigned long **bit, int *max)
> -{
> - if (usage->type == EV_KEY || usage->type == EV_ABS)
> - set_bit(usage->type, hi->input->evbit);
> -
> - return -1;
> -}
> -
>  static int mt_compute_slot(struct mt_device *td, struct input_dev *input)
>  {
>   __s32 quirks = td->mtclass.quirks;
> @@ -905,8 +895,10 @@ static int mt_input_mapped(struct hid_device *hdev, 
> struct hid_input *hi,
>   return 0;
>  
>   if (field->application == HID_DG_TOUCHSCREEN ||
> - field->application == HID_DG_TOUCHPAD)
> - return mt_touch_input_mapped(hdev, hi, field, usage, bit, max);
> + field->application == HID_DG_TOUCHPAD) {
> + /* We own these mappings, tell hid-input to ignore them */
> + return -1;
> + }
>  
>   /* let hid-core decide for the others */
>   return 0;
> -- 
> 2.13.2.725.g09c95d1e9-goog
> 
> 
> -- 
> Dmitry

Re: [PATCH] HID: multitouch: do not blindly set EV_KEY or EV_ABS bits

[Benjamin Tissoires]

On Jul 11 2017 or thereabouts, Dmitry Torokhov wrote:
> Now that input core insists on having dev->absinfo when device claims to
> generate EV_ABS in its dev->evbit, we should not be blindly setting that
> bit.
> 
> The code in question might have been needed before input_set_abs_params()
> started setting EV_ABS in device's evbit, but not anymore, and is now
> breaking devices such as SMART SPNL-6075 Touchscreen.
> 
> Fixes: 6ecfe51b4082 ("Input: refuse to register absolute devices ...")
> Reported-by: Matthias Fend 
> Tested-by: Matthias Fend 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Torokhov 
> ---
> 
> Jiri, Benjamin, I marked it for stable as it causes regressions in 4.12
> reported by users. Please take a look.

set_bit(usage->type, input->evbit); is called by hid-input.c when the
return code is positive, so we should be safe here.

Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

> 
>  drivers/hid/hid-multitouch.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 24d5b6deb571..be5bea15ce52 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -595,16 +595,6 @@ static int mt_touch_input_mapping(struct hid_device 
> *hdev, struct hid_input *hi,
>   return 0;
>  }
>  
> -static int mt_touch_input_mapped(struct hid_device *hdev, struct hid_input 
> *hi,
> - struct hid_field *field, struct hid_usage *usage,
> - unsigned long **bit, int *max)
> -{
> - if (usage->type == EV_KEY || usage->type == EV_ABS)
> - set_bit(usage->type, hi->input->evbit);
> -
> - return -1;
> -}
> -
>  static int mt_compute_slot(struct mt_device *td, struct input_dev *input)
>  {
>   __s32 quirks = td->mtclass.quirks;
> @@ -905,8 +895,10 @@ static int mt_input_mapped(struct hid_device *hdev, 
> struct hid_input *hi,
>   return 0;
>  
>   if (field->application == HID_DG_TOUCHSCREEN ||
> - field->application == HID_DG_TOUCHPAD)
> - return mt_touch_input_mapped(hdev, hi, field, usage, bit, max);
> + field->application == HID_DG_TOUCHPAD) {
> + /* We own these mappings, tell hid-input to ignore them */
> + return -1;
> + }
>  
>   /* let hid-core decide for the others */
>   return 0;
> -- 
> 2.13.2.725.g09c95d1e9-goog
> 
> 
> -- 
> Dmitry

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

Hi Andy,

Thanks for the review :)

On Jun 29 2017 or thereabouts, Andy Shevchenko wrote:
> +Cc: Hans (he might give some advice regarding to the below)
> 
> On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires
> <benjamin.tissoi...@redhat.com> wrote:
> > MSHW0011 replaces the battery firmware by using ACPI operation regions.
> > The values have been obtained by reverse engineering, and are subject to
> > errors. Looks like it works on overall pretty well.
> 
> What devices (laptops, tablets) have it?
> Surface 3. What else?

So far, Surface 3 only. It's a Microsoft PNPId, so I guess they control
which device has it. Maybe the model after the Surface 3 (reduced
platform) will have such chip, but for now, it's unknown.

> 
> > I couldn't manage to get the IRQ correctly triggered, so I am using a
> > good old polling thread to check for changes.
> 
> It might be
> 
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231
> 
> > +config ACPI_SURFACE3_POWER_OPREGION
> > +   tristate "Surface 3 battery platform operation region support"
> 
> depends on ACPI ?

Good point

> 
> > +   help
> > + Select this option to enable support for ACPI operation
> > + region of the Surface 3 battery platform driver.
> 
> > +/*
> > + * Supports for the power IC on the Surface 3 tablet.
> 
> Shouldn't it go to drivers/acpi/pmic folder ?

Already answered later in the thread, so yes, I'll move it there.

> 
> And did you check if it have actual chip IP vendor name and model?
> Most likely it's a TI (based?) solution.

As mentioned, I have strictly no idea. I can not crack open the Surface
3 without breaking the warranty (I already had to return it once because
the disk crashed).

And I do not find anything brand-related under Windows either:
- it's called "Surface Platform Power Driver"
- and the driver is provided by Microsoft

> 
> > + */
> 
> > +/*
> > + * Further findings regarding the 2 chips declared in the MSHW0011 are:
> > + * - there are 2 chips declared:
> > + *   . 0x22 seems to control the ADP1 line status (and probably the 
> > charger)
> > + *   . 0x55 controls the battery directly
> > + * - the battery chip uses a SMBus protocol (using plain SMBus allows non
> > + *   destructive commands):
> > + *   . the commands/registers used are in the range 0x00..0x7F
> > + *   . if bit 8 (0x80) is set in the SMBus command, the returned value is 
> > the
> > + * same as when it is not set. There is a high chance this bit is the
> > + * read/write
> > + *   . the various registers semantic as been deduced by observing the 
> > register
> > + * dumps.
> 
> All of this sounds familiar if look at what Hans discovered while was
> doing INT33FE support.
> Hans, does above ring any bell to you?
> 
> > + */
> 
> > +static bool dump_registers;
> > +module_param_named(dump_registers, dump_registers, bool, 0644);
> > +MODULE_PARM_DESC(dump_registers,
> > +"Dump the SMBus register at probe (debugging only).");
> 
> I'm not a fan of module parameter. Why not to use debugfs?

We can probably remove this entirely actually. We used this for reverse
engineering, but now I think it's time for it to be removed.

> 
> > +#define ACPI_BATTERY_STATE_DISCHARGING 0x1
> > +#define ACPI_BATTERY_STATE_CHARGING0x2
> > +#define ACPI_BATTERY_STATE_CRITICAL0x4
> 
> BIT() ?

Yep.

> 
> > +#define MSHW0011_EV_2_50x1ff
> 
> Is it mask? GENMASK() then.

I have strictly no idea (anymore) :)
I wrote this code too long ago, and I can't remember what this was.
Looking at the other piece of code that uses it, I am not so sure :/

> 
> > +
> > +static int mshw0011_i2c_read_block(struct i2c_client *client, u8 reg, u8 
> > *buf,
> > +  int len)
> > +{
> > +   int status, i;
> > +
> > +   for (i = 0; i < len; i++) {
> > +   status = i2c_smbus_read_byte_data(client, reg + i);
> > +   if (status < 0) {
> > +   buf[i] = 0xff;
> > +   continue;
> > +   }
> 
> Hmm... This looks weird. Why can you read entire block at once?

Yeah, looks like the Windows driver reads up to 32 bytes at a time. So
we should be able to have the same here.

> 
> > +
> > +   buf[i] = (u8)status;
> > +   }
> > +
> > +   return 0;
> > +}
> 
> > +static int
> > +mshw0011_notify(struct mshw0011_data *cdata, u8 arg1, u8 arg2,
> > +  

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

Hi Andy,

Thanks for the review :)

On Jun 29 2017 or thereabouts, Andy Shevchenko wrote:
> +Cc: Hans (he might give some advice regarding to the below)
> 
> On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires
>  wrote:
> > MSHW0011 replaces the battery firmware by using ACPI operation regions.
> > The values have been obtained by reverse engineering, and are subject to
> > errors. Looks like it works on overall pretty well.
> 
> What devices (laptops, tablets) have it?
> Surface 3. What else?

So far, Surface 3 only. It's a Microsoft PNPId, so I guess they control
which device has it. Maybe the model after the Surface 3 (reduced
platform) will have such chip, but for now, it's unknown.

> 
> > I couldn't manage to get the IRQ correctly triggered, so I am using a
> > good old polling thread to check for changes.
> 
> It might be
> 
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231
> 
> > +config ACPI_SURFACE3_POWER_OPREGION
> > +   tristate "Surface 3 battery platform operation region support"
> 
> depends on ACPI ?

Good point

> 
> > +   help
> > + Select this option to enable support for ACPI operation
> > + region of the Surface 3 battery platform driver.
> 
> > +/*
> > + * Supports for the power IC on the Surface 3 tablet.
> 
> Shouldn't it go to drivers/acpi/pmic folder ?

Already answered later in the thread, so yes, I'll move it there.

> 
> And did you check if it have actual chip IP vendor name and model?
> Most likely it's a TI (based?) solution.

As mentioned, I have strictly no idea. I can not crack open the Surface
3 without breaking the warranty (I already had to return it once because
the disk crashed).

And I do not find anything brand-related under Windows either:
- it's called "Surface Platform Power Driver"
- and the driver is provided by Microsoft

> 
> > + */
> 
> > +/*
> > + * Further findings regarding the 2 chips declared in the MSHW0011 are:
> > + * - there are 2 chips declared:
> > + *   . 0x22 seems to control the ADP1 line status (and probably the 
> > charger)
> > + *   . 0x55 controls the battery directly
> > + * - the battery chip uses a SMBus protocol (using plain SMBus allows non
> > + *   destructive commands):
> > + *   . the commands/registers used are in the range 0x00..0x7F
> > + *   . if bit 8 (0x80) is set in the SMBus command, the returned value is 
> > the
> > + * same as when it is not set. There is a high chance this bit is the
> > + * read/write
> > + *   . the various registers semantic as been deduced by observing the 
> > register
> > + * dumps.
> 
> All of this sounds familiar if look at what Hans discovered while was
> doing INT33FE support.
> Hans, does above ring any bell to you?
> 
> > + */
> 
> > +static bool dump_registers;
> > +module_param_named(dump_registers, dump_registers, bool, 0644);
> > +MODULE_PARM_DESC(dump_registers,
> > +"Dump the SMBus register at probe (debugging only).");
> 
> I'm not a fan of module parameter. Why not to use debugfs?

We can probably remove this entirely actually. We used this for reverse
engineering, but now I think it's time for it to be removed.

> 
> > +#define ACPI_BATTERY_STATE_DISCHARGING 0x1
> > +#define ACPI_BATTERY_STATE_CHARGING0x2
> > +#define ACPI_BATTERY_STATE_CRITICAL0x4
> 
> BIT() ?

Yep.

> 
> > +#define MSHW0011_EV_2_50x1ff
> 
> Is it mask? GENMASK() then.

I have strictly no idea (anymore) :)
I wrote this code too long ago, and I can't remember what this was.
Looking at the other piece of code that uses it, I am not so sure :/

> 
> > +
> > +static int mshw0011_i2c_read_block(struct i2c_client *client, u8 reg, u8 
> > *buf,
> > +  int len)
> > +{
> > +   int status, i;
> > +
> > +   for (i = 0; i < len; i++) {
> > +   status = i2c_smbus_read_byte_data(client, reg + i);
> > +   if (status < 0) {
> > +   buf[i] = 0xff;
> > +   continue;
> > +   }
> 
> Hmm... This looks weird. Why can you read entire block at once?

Yeah, looks like the Windows driver reads up to 32 bytes at a time. So
we should be able to have the same here.

> 
> > +
> > +   buf[i] = (u8)status;
> > +   }
> > +
> > +   return 0;
> > +}
> 
> > +static int
> > +mshw0011_notify(struct mshw0011_data *cdata, u8 arg1, u8 arg2,
> > +   unsigned int *ret_value)

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

On Jun 30 2017 or thereabouts, Hans de Goede wrote:
> Hi,
> 
> On 29-06-17 16:22, Andy Shevchenko wrote:
> > +Cc: Hans (he might give some advice regarding to the below)
> 
> Thank you for the Cc, so here we have the opposite situation as
> with the devices with the AXP288 PMIC and the Cherry Trail
> Whiskey Cove PMIC combined with the TI bq24292i charger and max17042
> fuel-gauge. In those cases we have well working native drivers
> for the used chips and we don't know the API of the custom ACPI
> OpRegion the ACPI battery and ac interface implementing ACPI nodes
> want. So for these devices we've disabled the ACPI battery and
> ac drivers and are using power_supply drivers for the used chips
> directly.
> 
> Here we've a similar setup where the ACPI nodes implementing the
> ACPI battery and ac interfaces require a custom OpRegion, but
> Benjamin has more or less figured out what the expected Opregion
> API is (and implemented it) and we do not know which chips are
> actually used.

Yeah, cracking open a Surface 3 voids the guarantee and it's a glue hell
from what I can understand. So no idea which chip is used in the end :(

> 
> Judging from the above I believe that implementing the ACPI
> OpRegion support for the MSHW0011 devices is a good solution
> in this case.

Thanks :)

> 
> > On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires
> > <benjamin.tissoi...@redhat.com> wrote:
> > > MSHW0011 replaces the battery firmware by using ACPI operation regions.
> > > The values have been obtained by reverse engineering, and are subject to
> > > errors. Looks like it works on overall pretty well.
> 
> 
> 
> > > +/*
> > > + * Further findings regarding the 2 chips declared in the MSHW0011 are:
> > > + * - there are 2 chips declared:
> > > + *   . 0x22 seems to control the ADP1 line status (and probably the 
> > > charger)
> > > + *   . 0x55 controls the battery directly
> > > + * - the battery chip uses a SMBus protocol (using plain SMBus allows non
> > > + *   destructive commands):
> > > + *   . the commands/registers used are in the range 0x00..0x7F
> > > + *   . if bit 8 (0x80) is set in the SMBus command, the returned value 
> > > is the
> > > + * same as when it is not set. There is a high chance this bit is the
> > > + * read/write
> > > + *   . the various registers semantic as been deduced by observing the 
> > > register
> > > + * dumps.
> > 
> > All of this sounds familiar if look at what Hans discovered while was
> > doing INT33FE support.
> > Hans, does above ring any bell to you?
> 
> Familiar yes, but I actually already looked at this rev-eng driver while 
> working
> on my INT33FE support and it is for different chips, and I don't know for
> which models exactly.
> 
> 
> 
> > > +static int acpi_find_i2c(struct acpi_resource *ares, void *data)
> > > +{
> > > +   struct mshw0011_lookup *lookup = data;
> > > +
> > > +   if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
> > > +   return 1;
> > > +
> > > +   if (lookup->n++ == lookup->index && !lookup->addr)
> > > +   lookup->addr = ares->data.i2c_serial_bus.slave_address;
> > > +
> > > +   return 1;
> > > +}
> > > +
> > > +static int mshw0011_i2c_resource_lookup(struct mshw0011_data *cdata,
> > > +   unsigned int index)
> > > +{
> > > +   struct i2c_client *client = cdata->adp1;
> > > +   struct acpi_device *adev = ACPI_COMPANION(>dev);
> > > +   struct mshw0011_lookup lookup = {
> > > +   .cdata = cdata,
> > > +   .index = index,
> > > +   };
> > > +   struct list_head res_list;
> > > +   int ret;
> > > +
> > > +   INIT_LIST_HEAD(_list);
> > > +
> > > +   ret = acpi_dev_get_resources(adev, _list, acpi_find_i2c, 
> > > );
> > > +   if (ret < 0)
> > > +   return ret;
> > > +
> > > +   acpi_dev_free_resource_list(_list);
> > > +
> > > +   if (!lookup.addr)
> > > +   return -ENOENT;
> > > +
> > > +   return lookup.addr;
> > > +}
> > 
> > Strange you have above functions here. It's a copy paste from I2C > core. 
> > Please, think about way of deduplicating it.
> 
> Right, this is something I can actually help with. When implementing the
> INT33

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

On Jun 30 2017 or thereabouts, Hans de Goede wrote:
> Hi,
> 
> On 29-06-17 16:22, Andy Shevchenko wrote:
> > +Cc: Hans (he might give some advice regarding to the below)
> 
> Thank you for the Cc, so here we have the opposite situation as
> with the devices with the AXP288 PMIC and the Cherry Trail
> Whiskey Cove PMIC combined with the TI bq24292i charger and max17042
> fuel-gauge. In those cases we have well working native drivers
> for the used chips and we don't know the API of the custom ACPI
> OpRegion the ACPI battery and ac interface implementing ACPI nodes
> want. So for these devices we've disabled the ACPI battery and
> ac drivers and are using power_supply drivers for the used chips
> directly.
> 
> Here we've a similar setup where the ACPI nodes implementing the
> ACPI battery and ac interfaces require a custom OpRegion, but
> Benjamin has more or less figured out what the expected Opregion
> API is (and implemented it) and we do not know which chips are
> actually used.

Yeah, cracking open a Surface 3 voids the guarantee and it's a glue hell
from what I can understand. So no idea which chip is used in the end :(

> 
> Judging from the above I believe that implementing the ACPI
> OpRegion support for the MSHW0011 devices is a good solution
> in this case.

Thanks :)

> 
> > On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires
> >  wrote:
> > > MSHW0011 replaces the battery firmware by using ACPI operation regions.
> > > The values have been obtained by reverse engineering, and are subject to
> > > errors. Looks like it works on overall pretty well.
> 
> 
> 
> > > +/*
> > > + * Further findings regarding the 2 chips declared in the MSHW0011 are:
> > > + * - there are 2 chips declared:
> > > + *   . 0x22 seems to control the ADP1 line status (and probably the 
> > > charger)
> > > + *   . 0x55 controls the battery directly
> > > + * - the battery chip uses a SMBus protocol (using plain SMBus allows non
> > > + *   destructive commands):
> > > + *   . the commands/registers used are in the range 0x00..0x7F
> > > + *   . if bit 8 (0x80) is set in the SMBus command, the returned value 
> > > is the
> > > + * same as when it is not set. There is a high chance this bit is the
> > > + * read/write
> > > + *   . the various registers semantic as been deduced by observing the 
> > > register
> > > + * dumps.
> > 
> > All of this sounds familiar if look at what Hans discovered while was
> > doing INT33FE support.
> > Hans, does above ring any bell to you?
> 
> Familiar yes, but I actually already looked at this rev-eng driver while 
> working
> on my INT33FE support and it is for different chips, and I don't know for
> which models exactly.
> 
> 
> 
> > > +static int acpi_find_i2c(struct acpi_resource *ares, void *data)
> > > +{
> > > +   struct mshw0011_lookup *lookup = data;
> > > +
> > > +   if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
> > > +   return 1;
> > > +
> > > +   if (lookup->n++ == lookup->index && !lookup->addr)
> > > +   lookup->addr = ares->data.i2c_serial_bus.slave_address;
> > > +
> > > +   return 1;
> > > +}
> > > +
> > > +static int mshw0011_i2c_resource_lookup(struct mshw0011_data *cdata,
> > > +   unsigned int index)
> > > +{
> > > +   struct i2c_client *client = cdata->adp1;
> > > +   struct acpi_device *adev = ACPI_COMPANION(>dev);
> > > +   struct mshw0011_lookup lookup = {
> > > +   .cdata = cdata,
> > > +   .index = index,
> > > +   };
> > > +   struct list_head res_list;
> > > +   int ret;
> > > +
> > > +   INIT_LIST_HEAD(_list);
> > > +
> > > +   ret = acpi_dev_get_resources(adev, _list, acpi_find_i2c, 
> > > );
> > > +   if (ret < 0)
> > > +   return ret;
> > > +
> > > +   acpi_dev_free_resource_list(_list);
> > > +
> > > +   if (!lookup.addr)
> > > +   return -ENOENT;
> > > +
> > > +   return lookup.addr;
> > > +}
> > 
> > Strange you have above functions here. It's a copy paste from I2C > core. 
> > Please, think about way of deduplicating it.
> 
> Right, this is something I can actually help with. When implementing the
> INT33FE support (*) I also was dealing with an 

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

On Jun 29 2017 or thereabouts, Rafael J. Wysocki wrote:
> On Thu, Jun 29, 2017 at 4:22 PM, Andy Shevchenko
> <andy.shevche...@gmail.com> wrote:
> > +Cc: Hans (he might give some advice regarding to the below)
> >
> > On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires
> > <benjamin.tissoi...@redhat.com> wrote:
> >> MSHW0011 replaces the battery firmware by using ACPI operation regions.
> >> The values have been obtained by reverse engineering, and are subject to
> >> errors. Looks like it works on overall pretty well.
> >
> > What devices (laptops, tablets) have it?
> > Surface 3. What else?
> >
> >> I couldn't manage to get the IRQ correctly triggered, so I am using a
> >> good old polling thread to check for changes.
> >
> > It might be
> >
> >>
> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231
> >
> >> +config ACPI_SURFACE3_POWER_OPREGION
> >> +   tristate "Surface 3 battery platform operation region support"
> >
> > depends on ACPI ?
> >
> >> +   help
> >> + Select this option to enable support for ACPI operation
> >> + region of the Surface 3 battery platform driver.
> >
> >> +/*
> >> + * Supports for the power IC on the Surface 3 tablet.
> >
> > Shouldn't it go to drivers/acpi/pmic folder ?
> 
> Surely not directly into drivers/acpi/ in any case.
> 

Yep, drivers/acpi/pmic seems like a good candidate. I will do that in
v3.

Cheers,
Benjamin

Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

On Jun 29 2017 or thereabouts, Rafael J. Wysocki wrote:
> On Thu, Jun 29, 2017 at 4:22 PM, Andy Shevchenko
>  wrote:
> > +Cc: Hans (he might give some advice regarding to the below)
> >
> > On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires
> >  wrote:
> >> MSHW0011 replaces the battery firmware by using ACPI operation regions.
> >> The values have been obtained by reverse engineering, and are subject to
> >> errors. Looks like it works on overall pretty well.
> >
> > What devices (laptops, tablets) have it?
> > Surface 3. What else?
> >
> >> I couldn't manage to get the IRQ correctly triggered, so I am using a
> >> good old polling thread to check for changes.
> >
> > It might be
> >
> >>
> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231
> >
> >> +config ACPI_SURFACE3_POWER_OPREGION
> >> +   tristate "Surface 3 battery platform operation region support"
> >
> > depends on ACPI ?
> >
> >> +   help
> >> + Select this option to enable support for ACPI operation
> >> + region of the Surface 3 battery platform driver.
> >
> >> +/*
> >> + * Supports for the power IC on the Surface 3 tablet.
> >
> > Shouldn't it go to drivers/acpi/pmic folder ?
> 
> Surely not directly into drivers/acpi/ in any case.
> 

Yep, drivers/acpi/pmic seems like a good candidate. I will do that in
v3.

Cheers,
Benjamin

[PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

MSHW0011 replaces the battery firmware by using ACPI operation regions.
The values have been obtained by reverse engineering, and are subject to
errors. Looks like it works on overall pretty well.

I couldn't manage to get the IRQ correctly triggered, so I am using a
good old polling thread to check for changes.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231

Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
Signed-off-by: Stephen Just <stephenj...@gmail.com>

---

Hi guys,

sorry for taking so long providing a v2 for this one, but it took me a while
to understand the acpica process and to get a proper PR done and merged[1].
(I must confess this felt through the crack too)
With ACPICA PR #277 merged, we now just need to have this patch included to
have proper battery reporting on the Surface 3.

I have included all the reviews Sebastian, Mika and Andy gave.

Cheers,
Benjamin

[1] https://github.com/acpica/acpica/pull/277

changes in v2:
- moved to drivers/acpi/ instead of power
- use uuid_le (guuid even)
- fix uper/lower case
- print_hex_dump() used in mshw0011_dump_registers() instead of custom dump
- removed "MSHW0011:00" in mshw0011_id
---
 drivers/acpi/Kconfig  |   6 +
 drivers/acpi/Makefile |   2 +
 drivers/acpi/surface3_power.c | 702 ++
 3 files changed, 710 insertions(+)
 create mode 100644 drivers/acpi/surface3_power.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f8..ac29170 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -488,6 +488,12 @@ config ACPI_EXTLOG
  driver adds support for that functionality with corresponding
  tracepoint which carries that information to userspace.
 
+config ACPI_SURFACE3_POWER_OPREGION
+   tristate "Surface 3 battery platform operation region support"
+   help
+ Select this option to enable support for ACPI operation
+ region of the Surface 3 battery platform driver.
+
 menuconfig PMIC_OPREGION
bool "PMIC (Power Management Integrated Circuit) operation region 
support"
help
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc..459a1aa 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -98,6 +98,8 @@ obj-$(CONFIG_ACPI_APEI)   += apei/
 
 obj-$(CONFIG_ACPI_EXTLOG)  += acpi_extlog.o
 
+obj-$(CONFIG_ACPI_SURFACE3_POWER_OPREGION) += surface3_power.o
+
 obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
 obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
diff --git a/drivers/acpi/surface3_power.c b/drivers/acpi/surface3_power.c
new file mode 100644
index 000..6d59c7f
--- /dev/null
+++ b/drivers/acpi/surface3_power.c
@@ -0,0 +1,702 @@
+/*
+ * Supports for the power IC on the Surface 3 tablet.
+ *
+ * (C) Copyright 2016-2017 Red Hat, Inc
+ * (C) Copyright 2016-2017 Benjamin Tissoires <benjamin.tissoi...@gmail.com>
+ * (C) Copyright 2016 Stephen Just <stephenj...@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+/*
+ * This driver has been reverse-engineered by parsing the DSDT of the Surface 3
+ * and looking at the registers of the chips.
+ *
+ * The DSDT allowed to find out that:
+ * - the driver is required for the ACPI BAT0 device to communicate to the chip
+ *   through an operation region.
+ * - the various defines for the operation region functions to communicate with
+ *   this driver
+ * - the DSM 3f99e367-6220-4955-8b0f-06ef2ae79412 allows to trigger ACPI
+ *   events to BAT0 (the code is all available in the DSDT).
+ *
+ * Further findings regarding the 2 chips declared in the MSHW0011 are:
+ * - there are 2 chips declared:
+ *   . 0x22 seems to control the ADP1 line status (and probably the charger)
+ *   . 0x55 controls the battery directly
+ * - the battery chip uses a SMBus protocol (using plain SMBus allows non
+ *   destructive commands):
+ *   . the commands/registers used are in the range 0x00..0x7F
+ *   . if bit 8 (0x80) is set in the SMBus command, the returned value is the
+ * same as when it is not set. There is a high chance this bit is the
+ * read/write
+ *   . the various registers semantic as been deduced by observing the register
+ * dumps.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define POLL_INTERVAL  (2 * HZ)
+
+static bool dump_registers;
+module_param_named(dump_registers, dump_registers, bool, 0644);
+MODULE_PARM_DESC(dump_registers,
+"Dump the SMBus register at probe (debugging only).");
+
+struct mshw0011_data {
+   struct i2c_client   *adp1;
+   struct i2c_client   *bat0;
+   un

[PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation

[Benjamin Tissoires]

MSHW0011 replaces the battery firmware by using ACPI operation regions.
The values have been obtained by reverse engineering, and are subject to
errors. Looks like it works on overall pretty well.

I couldn't manage to get the IRQ correctly triggered, so I am using a
good old polling thread to check for changes.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Stephen Just 

---

Hi guys,

sorry for taking so long providing a v2 for this one, but it took me a while
to understand the acpica process and to get a proper PR done and merged[1].
(I must confess this felt through the crack too)
With ACPICA PR #277 merged, we now just need to have this patch included to
have proper battery reporting on the Surface 3.

I have included all the reviews Sebastian, Mika and Andy gave.

Cheers,
Benjamin

[1] https://github.com/acpica/acpica/pull/277

changes in v2:
- moved to drivers/acpi/ instead of power
- use uuid_le (guuid even)
- fix uper/lower case
- print_hex_dump() used in mshw0011_dump_registers() instead of custom dump
- removed "MSHW0011:00" in mshw0011_id
---
 drivers/acpi/Kconfig  |   6 +
 drivers/acpi/Makefile |   2 +
 drivers/acpi/surface3_power.c | 702 ++
 3 files changed, 710 insertions(+)
 create mode 100644 drivers/acpi/surface3_power.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f8..ac29170 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -488,6 +488,12 @@ config ACPI_EXTLOG
  driver adds support for that functionality with corresponding
  tracepoint which carries that information to userspace.
 
+config ACPI_SURFACE3_POWER_OPREGION
+   tristate "Surface 3 battery platform operation region support"
+   help
+ Select this option to enable support for ACPI operation
+ region of the Surface 3 battery platform driver.
+
 menuconfig PMIC_OPREGION
bool "PMIC (Power Management Integrated Circuit) operation region 
support"
help
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc..459a1aa 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -98,6 +98,8 @@ obj-$(CONFIG_ACPI_APEI)   += apei/
 
 obj-$(CONFIG_ACPI_EXTLOG)  += acpi_extlog.o
 
+obj-$(CONFIG_ACPI_SURFACE3_POWER_OPREGION) += surface3_power.o
+
 obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
 obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
diff --git a/drivers/acpi/surface3_power.c b/drivers/acpi/surface3_power.c
new file mode 100644
index 000..6d59c7f
--- /dev/null
+++ b/drivers/acpi/surface3_power.c
@@ -0,0 +1,702 @@
+/*
+ * Supports for the power IC on the Surface 3 tablet.
+ *
+ * (C) Copyright 2016-2017 Red Hat, Inc
+ * (C) Copyright 2016-2017 Benjamin Tissoires 
+ * (C) Copyright 2016 Stephen Just 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+/*
+ * This driver has been reverse-engineered by parsing the DSDT of the Surface 3
+ * and looking at the registers of the chips.
+ *
+ * The DSDT allowed to find out that:
+ * - the driver is required for the ACPI BAT0 device to communicate to the chip
+ *   through an operation region.
+ * - the various defines for the operation region functions to communicate with
+ *   this driver
+ * - the DSM 3f99e367-6220-4955-8b0f-06ef2ae79412 allows to trigger ACPI
+ *   events to BAT0 (the code is all available in the DSDT).
+ *
+ * Further findings regarding the 2 chips declared in the MSHW0011 are:
+ * - there are 2 chips declared:
+ *   . 0x22 seems to control the ADP1 line status (and probably the charger)
+ *   . 0x55 controls the battery directly
+ * - the battery chip uses a SMBus protocol (using plain SMBus allows non
+ *   destructive commands):
+ *   . the commands/registers used are in the range 0x00..0x7F
+ *   . if bit 8 (0x80) is set in the SMBus command, the returned value is the
+ * same as when it is not set. There is a high chance this bit is the
+ * read/write
+ *   . the various registers semantic as been deduced by observing the register
+ * dumps.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define POLL_INTERVAL  (2 * HZ)
+
+static bool dump_registers;
+module_param_named(dump_registers, dump_registers, bool, 0644);
+MODULE_PARM_DESC(dump_registers,
+"Dump the SMBus register at probe (debugging only).");
+
+struct mshw0011_data {
+   struct i2c_client   *adp1;
+   struct i2c_client   *bat0;
+   unsigned short  notify_version;
+   struct task_struct  *poll_task;
+   boolkthread_running;
+

Re: [PATCH] Input: synaptics - switch t460s 20FN to use RMI4 over SMBus

[Benjamin Tissoires]

On Jun 26 2017 or thereabouts, Benjamin Tissoires wrote:
> On Jun 26 2017 or thereabouts, Christopher Bachner wrote:
> > Hello,
> > 
> > I am assuming that if the inertouch message is not showing up in dmesg,
> > then it is working. Is that a correct assumption?
> > 
> > Either way I also attached my dmesg.
> > 
> > I am not sure, though, why the scroll mode still freezes if I move the my
> > fingers quickly on the touchpad while also using the trackpoint. Is that
> > maybe a future fix and this change is just the foundation for it? Overall
> > the usage of the trackpoint is better now for sure.
> 
> Sadly, you are also hit by:
> [6.355378] i801_smbus :00:1f.4: BIOS is accessing SMBus registers
> [6.355380] i801_smbus :00:1f.4: Driver SMBus register access inhibited
> 
> Which disables entirely the RMI4 over SMBus module. And then we can not
> probe for it, meaning you are stuck with the PS/2 crappy mode.
> 
> We are aware of this bug and we'll try to fix that. I think the test you
> provides are valid (the patch works as expected), but a different bug
> prevents rmi-smbus to fully initialize the touchpad :(

Could you try applying Lyude's patch: http://patchwork.ozlabs.org/patch/780865/
(on top of mine, of course).

In the dmesg, you should see a Synaptics TM device appearing after
trying to set up the SMBus companion.

Cheers,
Benjamin

Re: [PATCH] Input: synaptics - switch t460s 20FN to use RMI4 over SMBus

[Benjamin Tissoires]

On Jun 26 2017 or thereabouts, Benjamin Tissoires wrote:
> On Jun 26 2017 or thereabouts, Christopher Bachner wrote:
> > Hello,
> > 
> > I am assuming that if the inertouch message is not showing up in dmesg,
> > then it is working. Is that a correct assumption?
> > 
> > Either way I also attached my dmesg.
> > 
> > I am not sure, though, why the scroll mode still freezes if I move the my
> > fingers quickly on the touchpad while also using the trackpoint. Is that
> > maybe a future fix and this change is just the foundation for it? Overall
> > the usage of the trackpoint is better now for sure.
> 
> Sadly, you are also hit by:
> [6.355378] i801_smbus :00:1f.4: BIOS is accessing SMBus registers
> [6.355380] i801_smbus :00:1f.4: Driver SMBus register access inhibited
> 
> Which disables entirely the RMI4 over SMBus module. And then we can not
> probe for it, meaning you are stuck with the PS/2 crappy mode.
> 
> We are aware of this bug and we'll try to fix that. I think the test you
> provides are valid (the patch works as expected), but a different bug
> prevents rmi-smbus to fully initialize the touchpad :(

Could you try applying Lyude's patch: http://patchwork.ozlabs.org/patch/780865/
(on top of mine, of course).

In the dmesg, you should see a Synaptics TM device appearing after
trying to set up the SMBus companion.

Cheers,
Benjamin

Re: [PATCH] HID: wacom:fix spelling mistake: "exising" -> "existing"

[Benjamin Tissoires]

On Jun 26 2017 or thereabouts, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> trivial fix to spelling mistake in hid_warn warning message
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---

Looks good to me:
Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>

Cheers,
Benjamin

>  drivers/hid/wacom_wac.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 1992bb0732c2..9f940293ede4 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -2110,28 +2110,28 @@ static void wacom_wac_pen_event(struct hid_device 
> *hdev, struct hid_field *field
>   return;
>   case WACOM_HID_WD_OFFSETLEFT:
>   if (features->offset_left && value != features->offset_left)
> - hid_warn(hdev, "%s: overriding exising left offset "
> + hid_warn(hdev, "%s: overriding existing left offset "
>"%d -> %d\n", __func__, value,
>features->offset_left);
>   features->offset_left = value;
>   return;
>   case WACOM_HID_WD_OFFSETRIGHT:
>   if (features->offset_right && value != features->offset_right)
> - hid_warn(hdev, "%s: overriding exising right offset "
> + hid_warn(hdev, "%s: overriding existing right offset "
>"%d -> %d\n", __func__, value,
>features->offset_right);
>   features->offset_right = value;
>   return;
>   case WACOM_HID_WD_OFFSETTOP:
>   if (features->offset_top && value != features->offset_top)
> - hid_warn(hdev, "%s: overriding exising top offset "
> + hid_warn(hdev, "%s: overriding existing top offset "
>"%d -> %d\n", __func__, value,
>features->offset_top);
>   features->offset_top = value;
>   return;
>   case WACOM_HID_WD_OFFSETBOTTOM:
>   if (features->offset_bottom && value != features->offset_bottom)
> - hid_warn(hdev, "%s: overriding exising bottom offset "
> + hid_warn(hdev, "%s: overriding existing bottom offset "
>"%d -> %d\n", __func__, value,
>features->offset_bottom);
>   features->offset_bottom = value;
> -- 
> 2.11.0
> 

Re: [PATCH] HID: wacom:fix spelling mistake: "exising" -> "existing"

[Benjamin Tissoires]

On Jun 26 2017 or thereabouts, Colin King wrote:
> From: Colin Ian King 
> 
> trivial fix to spelling mistake in hid_warn warning message
> 
> Signed-off-by: Colin Ian King 
> ---

Looks good to me:
Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

>  drivers/hid/wacom_wac.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 1992bb0732c2..9f940293ede4 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -2110,28 +2110,28 @@ static void wacom_wac_pen_event(struct hid_device 
> *hdev, struct hid_field *field
>   return;
>   case WACOM_HID_WD_OFFSETLEFT:
>   if (features->offset_left && value != features->offset_left)
> - hid_warn(hdev, "%s: overriding exising left offset "
> + hid_warn(hdev, "%s: overriding existing left offset "
>"%d -> %d\n", __func__, value,
>features->offset_left);
>   features->offset_left = value;
>   return;
>   case WACOM_HID_WD_OFFSETRIGHT:
>   if (features->offset_right && value != features->offset_right)
> - hid_warn(hdev, "%s: overriding exising right offset "
> + hid_warn(hdev, "%s: overriding existing right offset "
>"%d -> %d\n", __func__, value,
>features->offset_right);
>   features->offset_right = value;
>   return;
>   case WACOM_HID_WD_OFFSETTOP:
>   if (features->offset_top && value != features->offset_top)
> - hid_warn(hdev, "%s: overriding exising top offset "
> + hid_warn(hdev, "%s: overriding existing top offset "
>"%d -> %d\n", __func__, value,
>features->offset_top);
>   features->offset_top = value;
>   return;
>   case WACOM_HID_WD_OFFSETBOTTOM:
>   if (features->offset_bottom && value != features->offset_bottom)
> - hid_warn(hdev, "%s: overriding exising bottom offset "
> + hid_warn(hdev, "%s: overriding existing bottom offset "
>"%d -> %d\n", __func__, value,
>features->offset_bottom);
>   features->offset_bottom = value;
> -- 
> 2.11.0
>