[GIT PULL] HID for 4.11

[GIT PULL] HID for 4.11

[Jiri Kosina]

Linus,

please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus

to receive HID subsystem updates for 4.11:

=====
- a lot of Wacom driver updates; most notably second generation Intuos Pro
  is now supported, code from Aaron Armstrong Skomra and Jason Gerecke
- Surface 3 and 4 Type Cover Pro support from Daniel Keller, Dennis Chen 
  and Yuta Kobayashi
- hid-rmi is now generic transport driver, used by synaptics-rmi4; Support 
  the Lenovo Thinkpad X1 Tablet dock follows on top, from Andrew Duggan
- a few misc bugfixes and improvements here and there
=====

Thanks.

----------------------------------------------------------------
Aaron Armstrong Skomra (5):
      HID: wacom: generic: remove input_event_flag
      HID: wacom: generic: add support for touchring
      HID: wacom: generic: add vendor defined touch
      HID: wacom: generic: support generic touch switch
      HID: wacom: generic: support LEDs

Andrew Duggan (3):
      HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
      HID: rmi: Handle all Synaptics touchpads using hid-rmi
      HID: rmi: Support the Lenovo Thinkpad X1 Tablet dock using hid-rmi

Benjamin Tissoires (4):
      HID: wacom: release the resources before leaving despite devm
      HID: wacom: remove warning while disconnecting devices
      HID: wacom: do not attempt to switch mode while in probe
      HID: multitouch: fix LG Melfas touchscreen

Bhumika Goyal (1):
      HID: intel-ish-hid: constify device_type structure

Corentin Labbe (1):
      HID: intel-ish-hid: Remove unneeded linux/miscdevice.h include

Daniel Keller (1):
      HID: multitouch: enable Surface 4 Type Cover Pro (non-JP) to report multitouch data

Dennis Chen (2):
      HID: multitouch: enable Surface 3 Type Cover Pro to report multitouch data
      HID: whitespace cleanup

Even Xu (1):
      HID: intel-ish-hid: ipc: check FW status to distinguish ISH resume paths

Grant Grundler (1):
      HID: remove use of DRIVER_LICENSE

Jason Gerecke (4):
      HID: wacom: Enable HID_GENERIC codepath for Bluetooth devices
      HID: wacom: Move WAC_CMD_* into wacom_wac.h
      HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface
      HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range

Marcel Hasler (2):
      HID: add device ID for updated Mayflash/Dragonrise GameCube adapter
      HID: hid-mf: add force feedback support for Mayflash DolphinBar and GameCube

Nicolas Iooss (2):
      HID: intel-ish-hid: add printf attribute to print_log()
      HID: intel-ish-hid: format 32-bit integers with %X

Ping Cheng (1):
      HID: wacom: don't apply generic settings to old devices

Yuta Kobayashi (1):
      HID: multitouch: enable the Surface 4 Type Cover Pro (JP) to report multitouch data

 drivers/hid/Kconfig                         |   5 +
 drivers/hid/hid-core.c                      |  27 +-
 drivers/hid/hid-ids.h                       |  11 +-
 drivers/hid/hid-mf.c                        |  19 +-
 drivers/hid/hid-microsoft.c                 |  12 -
 drivers/hid/hid-multitouch.c                |  44 ++
 drivers/hid/hid-rmi.c                       | 975 ++++------------------------
 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h |   8 +
 drivers/hid/intel-ish-hid/ipc/hw-ish.h      |  12 +
 drivers/hid/intel-ish-hid/ipc/pci-ish.c     |  38 +-
 drivers/hid/intel-ish-hid/ishtp-hid.c       |   2 +-
 drivers/hid/intel-ish-hid/ishtp/bus.c       |   2 +-
 drivers/hid/intel-ish-hid/ishtp/hbm.c       |   1 -
 drivers/hid/intel-ish-hid/ishtp/init.c      |   1 -
 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h |   3 +-
 drivers/hid/usbhid/hid-core.c               |   3 +-
 drivers/hid/usbhid/hid-quirks.c             |  12 +-
 drivers/hid/usbhid/usbkbd.c                 |   3 +-
 drivers/hid/usbhid/usbmouse.c               |   3 +-
 drivers/hid/wacom.h                         |   5 +-
 drivers/hid/wacom_sys.c                     | 147 ++++-
 drivers/hid/wacom_wac.c                     | 289 ++++++++-
 drivers/hid/wacom_wac.h                     |  37 +-
 23 files changed, 698 insertions(+), 961 deletions(-)

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Mon, Feb 20, 2017 at 7:20 AM, Jiri Kosina <jikos@kernel.org> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
>
> to receive HID subsystem updates for 4.11:

The touchpad on my XPS13 no longer works. It might not be this pull
request, and I'll bisect the exact cause, but this pull seems the most
likely culprit.

Just an early heads-up,

                Linus

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Mon, Feb 20, 2017 at 6:48 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Feb 20, 2017 at 7:20 AM, Jiri Kosina <jikos@kernel.org> wrote:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
>>
>> to receive HID subsystem updates for 4.11:
>
> The touchpad on my XPS13 no longer works. It might not be this pull
> request, and I'll bisect the exact cause, but this pull seems the most
> likely culprit.

It's bisecting right into the HID pull request, so you can consider
that confirmed.  There's something badly broken in this pull.

I'll have a more specific commit (or range) soon.

               Linus

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Mon, Feb 20, 2017 at 7:03 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> It's bisecting right into the HID pull request, so you can consider
> that confirmed.  There's something badly broken in this pull.

Side note, the touchpad messages from a working kernel are as

  psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2a1,
caps: 0xf00223/0x840300/0x12e800/0x0, board id: 3038, fw id: 2011643
  input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio1/input/input6
  input: DLL0704:01 06CB:76AE Touchpad as
/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DLL0704:01/0018:06CB:76AE.0002/input/input19

whereas a bad kernel seems to miss that third line.

               Linus

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Mon, Feb 20, 2017 at 7:03 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'll have a more specific commit (or range) soon.

Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
touchpads using hid-rmi").

And the reason seems to be stupid: I don't have RMI enabled at all,
because that didn't use to work or make a difference.

Maybe that "let's use RMI" code should depend on RMI actually being
enabled? Because as-is, that code now breaks existing configurations.

               Linus

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Mon, Feb 20, 2017 at 8:13 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
> touchpads using hid-rmi").
>
> And the reason seems to be stupid: I don't have RMI enabled at all,
> because that didn't use to work or make a difference.
>
> Maybe that "let's use RMI" code should depend on RMI actually being
> enabled? Because as-is, that code now breaks existing configurations.

Yeah, so enabling HID_RMI makes my touchpad work again.

But this really was a stupid waste of time, and I really think that
the synaptics code should leave the HID group as generic or
multitouch-win8 _unless_ the HID RMI support is actually enabled.

IOW, something like the attached (untested) patch, perhaps?

              Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 704 bytes --]

 drivers/hid/hid-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 538ff697a4cf..41c88c50a96b 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -821,7 +821,8 @@ static int hid_scan_report(struct hid_device *hid)
 	case USB_VENDOR_ID_SYNAPTICS:
 		if (hid->group == HID_GROUP_GENERIC ||
 		    hid->group == HID_GROUP_MULTITOUCH_WIN_8)
-			if ((parser->scan_flags & HID_SCAN_FLAG_VENDOR_SPECIFIC)
+			if (IS_ENABLED(CONFIG_HID_RMI)
+			    && (parser->scan_flags & HID_SCAN_FLAG_VENDOR_SPECIFIC)
 			    && (parser->scan_flags & HID_SCAN_FLAG_GD_POINTER))
 				/*
 				 * hid-rmi should take care of them,

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Mon, Feb 20, 2017 at 8:37 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Yeah, so enabling HID_RMI makes my touchpad work again.

.. so I just noticed something: it works subtly differently.

When I drag something around, I mostly just double-tap and move, and
that still works fine.

But sometimes I click (and hold) with one finger, and then move around
with another. That's occasionally very useful when you move longer
distances, because you can just raise and move that other finger
multiple times.

That doesn't seem to work with the RMI driver. I seem to get scroll
events instead.

I'm sure there's some setting for mouse gestures. But it's a bit odd
when they change just because the driver changes. And gnome certainly
doesn't believe in settings, because these things are obviously
"intuitive".

Ideas? Or am I just dreaming, and the click-and-move never worked?
Because I'm pretty sure it did, but sometimes the meds kick in.

                 Linus

Re: [GIT PULL] HID for 4.11

[Andrew Duggan]

On 02/28/2017 04:56 PM, Linus Torvalds wrote:
> On Mon, Feb 20, 2017 at 8:37 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> Yeah, so enabling HID_RMI makes my touchpad work again.
> .. so I just noticed something: it works subtly differently.
>
> When I drag something around, I mostly just double-tap and move, and
> that still works fine.
>
> But sometimes I click (and hold) with one finger, and then move around
> with another. That's occasionally very useful when you move longer
> distances, because you can just raise and move that other finger
> multiple times.
>
> That doesn't seem to work with the RMI driver. I seem to get scroll
> events instead.
>
> I'm sure there's some setting for mouse gestures. But it's a bit odd
> when they change just because the driver changes. And gnome certainly
> doesn't believe in settings, because these things are obviously
> "intuitive".
>
> Ideas? Or am I just dreaming, and the click-and-move never worked?
> Because I'm pretty sure it did, but sometimes the meds kick in.
>
>                   Linus

The RMI driver does report input events a little differently then the 
hid-multitouch driver. It may report different min / max values for 
axis, different resolution values, and it also reports ABS_MT_PRESSURE. 
Also, depending on how the touchpad's firmware was configured it may 
also report additional fingers. It probably also reports a few other 
properties which hid-multitouch does not. Since it is the input handling 
libraries in userspace which interpret the input events and decide what 
is a drag and what is a scroll I suspect the issue may be in userspace. 
The additional properties reported by the input device may be causing 
the input handler to potentially misidentify the device and treat it 
differently. That's at least where I would start looking.

For what it's worth, I'm using libinput and the RMI driver on my 
touchpad. Click and drag works well with libinput's "ClickMethod" 
parameter set to "clickfinger".

Andrew

Re: [GIT PULL] HID for 4.11

[Peter Hutterer]

On Tue, Feb 28, 2017 at 06:31:10PM -0800, Andrew Duggan wrote:
> On 02/28/2017 04:56 PM, Linus Torvalds wrote:
> > On Mon, Feb 20, 2017 at 8:37 PM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > > Yeah, so enabling HID_RMI makes my touchpad work again.
> > .. so I just noticed something: it works subtly differently.
> > 
> > When I drag something around, I mostly just double-tap and move, and
> > that still works fine.
> > 
> > But sometimes I click (and hold) with one finger, and then move around
> > with another. That's occasionally very useful when you move longer
> > distances, because you can just raise and move that other finger
> > multiple times.
> > 
> > That doesn't seem to work with the RMI driver. I seem to get scroll
> > events instead.

fwiw, scroll events are implemented in userspace, so this would be a bug in
libinput or the synaptics driver if you're using that one.

> > I'm sure there's some setting for mouse gestures. But it's a bit odd
> > when they change just because the driver changes. And gnome certainly
> > doesn't believe in settings, because these things are obviously
> > "intuitive".
> > 
> > Ideas? Or am I just dreaming, and the click-and-move never worked?
> > Because I'm pretty sure it did, but sometimes the meds kick in.

it definitely should work and it shouldn't be affected much by these kernel
driver changes. more specifically, scrolling should never happen while
BTN_LEFT is down.

> The RMI driver does report input events a little differently then the
> hid-multitouch driver. It may report different min / max values for axis,
> different resolution values, and it also reports ABS_MT_PRESSURE. Also,
> depending on how the touchpad's firmware was configured it may also report
> additional fingers. It probably also reports a few other properties which
> hid-multitouch does not. Since it is the input handling libraries in
> userspace which interpret the input events and decide what is a drag and
> what is a scroll I suspect the issue may be in userspace. The additional
> properties reported by the input device may be causing the input handler to
> potentially misidentify the device and treat it differently. That's at least
> where I would start looking.
> 
> For what it's worth, I'm using libinput and the RMI driver on my touchpad.
> Click and drag works well with libinput's "ClickMethod" parameter set to
> "clickfinger".

fwiw, should work with software buttons as well. but as I said above, scroll
events should never trigger as long as a button is down, at least not with
only two fingers on the touchpad.

I suspect you're just triggering a bug that wasn't triggered by the ps/2
emulation. you can run linput-debug-events --verbose and have a look at the
various state debugging information, that may hint at what's going on (e.g.
a finger mistaken as palm touch, or something). Or record one such
interaction with evemu-record and send it to me (preferrably here [1], if
you're using libinput). Also, what version of libinput/synaptics are you on?

Cheers,
   Peter

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=wayland&component=libinput

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
>
> I suspect you're just triggering a bug that wasn't triggered by the ps/2
> emulation. you can run linput-debug-events --verbose and have a look at the
> various state debugging information, that may hint at what's going on (e.g.
> a finger mistaken as palm touch, or something). Or record one such
> interaction with evemu-record and send it to me (preferrably here [1], if
> you're using libinput). Also, what version of libinput/synaptics are you on?

bug reported (it's bug 100014).

This is libinput-1.5.4 on Fedora 24. I attached both the
libinput-debug-events output as well as evemu-report output, which
hopefully fills in all the details.

                 Linus

Re: [GIT PULL] HID for 4.11

[Andrew Duggan]

On 02/28/2017 09:05 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
>> I suspect you're just triggering a bug that wasn't triggered by the ps/2
>> emulation. you can run linput-debug-events --verbose and have a look at the
>> various state debugging information, that may hint at what's going on (e.g.
>> a finger mistaken as palm touch, or something). Or record one such
>> interaction with evemu-record and send it to me (preferrably here [1], if
>> you're using libinput). Also, what version of libinput/synaptics are you on?
> bug reported (it's bug 100014).
>
> This is libinput-1.5.4 on Fedora 24. I attached both the
> libinput-debug-events output as well as evemu-report output, which
> hopefully fills in all the details.
>
>                   Linus

Actually, it looks like this is a regression which was introduced by 
bf3e8502eefd ("Input: synaptics-rmi4 - clean up F30 implementation"). 
 From the bug report I noticed that the INPUT_PROP_BUTTONPAD property 
was not set for the touchpad. The previous behavior was to set 
INPUT_PROP_BUTTONPAD if F30 detected only one valid button (or if there 
was a flag in the platform data). But, now INPUT_PROP_BUTTONPAD is not 
being set and libinput does not know that the touchpad is a clickpad. 
After updating I was able to reproduce the issue with bf3e8502eefd applied.

Andrew

Re: [GIT PULL] HID for 4.11

[Benjamin Tissoires]

On Feb 28 2017 or thereabouts, Linus Torvalds wrote:
> On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> >
> > I suspect you're just triggering a bug that wasn't triggered by the ps/2
> > emulation. you can run linput-debug-events --verbose and have a look at the
> > various state debugging information, that may hint at what's going on (e.g.
> > a finger mistaken as palm touch, or something). Or record one such
> > interaction with evemu-record and send it to me (preferrably here [1], if
> > you're using libinput). Also, what version of libinput/synaptics are you on?
> 
> bug reported (it's bug 100014).
> 

Thanks for the report.

As Peter mentioned in the bug, there is a missing property on the kernel
node (INPUT_PROP_BUTTONPAD). 

The thing is this property is solely driven in the current driver by the
provided platform_data, so there is no way we ever set it through
hid-rmi. I wonder how we missed that.

Anyway, the good news is that the evemu record shows only one exportted
button, so we can infer the property quite easily in the module. Would
something like that work for you?

>From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Wed, 1 Mar 2017 09:57:00 +0100
Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the
 button count

INPUT_PROP_BUTTONPAD is currently only set through the platform data.
The RMI4 header doc says that this property is there to force the
buttonpad property, so we also need to detect it by looking at
the exported buttons count.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
 drivers/input/rmi4/rmi_f30.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
index 3422464..1986786 100644
--- a/drivers/input/rmi4/rmi_f30.c
+++ b/drivers/input/rmi4/rmi_f30.c
@@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
 
 	/*
 	 * Buttonpad could be also inferred from f30->has_mech_mouse_btns,
-	 * but I am not sure, so use only the pdata info.
+	 * but I am not sure, so use only the pdata info and the number of
+	 * mapped buttons.
 	 */
-	if (pdata->f30_data.buttonpad)
+	if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
 		__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
 
 	return 0;
-- 
2.9.3

Dmitry, Andrew, would this work for you too?

Cheers,
Benjamin

Re: [GIT PULL] HID for 4.11

[Benjamin Tissoires]

[I forgot to add Dmitry in the loop, sorry for the noise.]

On Mar 01 2017 or thereabouts, Benjamin Tissoires wrote:
> On Feb 28 2017 or thereabouts, Linus Torvalds wrote:
> > On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
> > <peter.hutterer@who-t.net> wrote:
> > >
> > > I suspect you're just triggering a bug that wasn't triggered by the ps/2
> > > emulation. you can run linput-debug-events --verbose and have a look at the
> > > various state debugging information, that may hint at what's going on (e.g.
> > > a finger mistaken as palm touch, or something). Or record one such
> > > interaction with evemu-record and send it to me (preferrably here [1], if
> > > you're using libinput). Also, what version of libinput/synaptics are you on?
> > 
> > bug reported (it's bug 100014).
> > 
> 
> Thanks for the report.
> 
> As Peter mentioned in the bug, there is a missing property on the kernel
> node (INPUT_PROP_BUTTONPAD). 
> 
> The thing is this property is solely driven in the current driver by the
> provided platform_data, so there is no way we ever set it through
> hid-rmi. I wonder how we missed that.
> 
> Anyway, the good news is that the evemu record shows only one exportted
> button, so we can infer the property quite easily in the module. Would
> something like that work for you?
> 
> From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Wed, 1 Mar 2017 09:57:00 +0100
> Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the
>  button count
> 
> INPUT_PROP_BUTTONPAD is currently only set through the platform data.
> The RMI4 header doc says that this property is there to force the
> buttonpad property, so we also need to detect it by looking at
> the exported buttons count.
> 
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>  drivers/input/rmi4/rmi_f30.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
> index 3422464..1986786 100644
> --- a/drivers/input/rmi4/rmi_f30.c
> +++ b/drivers/input/rmi4/rmi_f30.c
> @@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
>  
>  	/*
>  	 * Buttonpad could be also inferred from f30->has_mech_mouse_btns,
> -	 * but I am not sure, so use only the pdata info.
> +	 * but I am not sure, so use only the pdata info and the number of
> +	 * mapped buttons.
>  	 */
> -	if (pdata->f30_data.buttonpad)
> +	if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
>  		__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
>  
>  	return 0;
> -- 
> 2.9.3
> 
> Dmitry, Andrew, would this work for you too?
> 
> Cheers,
> Benjamin

Re: [GIT PULL] HID for 4.11

[Dmitry Torokhov]

Hi Benjamin,

On Wed, Mar 01, 2017 at 10:06:35AM +0100, Benjamin Tissoires wrote:
> [I forgot to add Dmitry in the loop, sorry for the noise.]
> 
> On Mar 01 2017 or thereabouts, Benjamin Tissoires wrote:
> > On Feb 28 2017 or thereabouts, Linus Torvalds wrote:
> > > On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer
> > > <peter.hutterer@who-t.net> wrote:
> > > >
> > > > I suspect you're just triggering a bug that wasn't triggered by the ps/2
> > > > emulation. you can run linput-debug-events --verbose and have a look at the
> > > > various state debugging information, that may hint at what's going on (e.g.
> > > > a finger mistaken as palm touch, or something). Or record one such
> > > > interaction with evemu-record and send it to me (preferrably here [1], if
> > > > you're using libinput). Also, what version of libinput/synaptics are you on?
> > > 
> > > bug reported (it's bug 100014).
> > > 
> > 
> > Thanks for the report.
> > 
> > As Peter mentioned in the bug, there is a missing property on the kernel
> > node (INPUT_PROP_BUTTONPAD). 
> > 
> > The thing is this property is solely driven in the current driver by the
> > provided platform_data, so there is no way we ever set it through
> > hid-rmi. I wonder how we missed that.
> > 
> > Anyway, the good news is that the evemu record shows only one exportted
> > button, so we can infer the property quite easily in the module. Would
> > something like that work for you?
> > 
> > From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001
> > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Date: Wed, 1 Mar 2017 09:57:00 +0100
> > Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the
> >  button count
> > 
> > INPUT_PROP_BUTTONPAD is currently only set through the platform data.
> > The RMI4 header doc says that this property is there to force the
> > buttonpad property, so we also need to detect it by looking at
> > the exported buttons count.
> > 
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > ---
> >  drivers/input/rmi4/rmi_f30.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
> > index 3422464..1986786 100644
> > --- a/drivers/input/rmi4/rmi_f30.c
> > +++ b/drivers/input/rmi4/rmi_f30.c
> > @@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
> >  
> >  	/*
> >  	 * Buttonpad could be also inferred from f30->has_mech_mouse_btns,
> > -	 * but I am not sure, so use only the pdata info.
> > +	 * but I am not sure, so use only the pdata info and the number of
> > +	 * mapped buttons.
> >  	 */
> > -	if (pdata->f30_data.buttonpad)
> > +	if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
> >  		__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);

Would prefer if we changed button_mapped to n_buttons_mapped counter and
used that, instead of doing calculations on event code.

Thanks.

-- 
Dmitry

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Wed, Mar 1, 2017 at 1:03 AM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> As Peter mentioned in the bug, there is a missing property on the kernel
> node (INPUT_PROP_BUTTONPAD).
>
> The thing is this property is solely driven in the current driver by the
> provided platform_data, so there is no way we ever set it through
> hid-rmi. I wonder how we missed that.
>
> Anyway, the good news is that the evemu record shows only one exportted
> button, so we can infer the property quite easily in the module. Would
> something like that work for you?
>
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Wed, 1 Mar 2017 09:57:00 +0100
> Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the button count

Yes, this fixes the problem for me. My click-and-drag works again, so
you can add a

  Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>

I see that Dmitry doesn't love the patch, but I'm assuming I'll get
that or something equivalent soon. In the meantime, I'll just keep it
on my laptop as a workaround.

Thanks,

                   Linus

Re: [GIT PULL] HID for 4.11

[Dmitry Torokhov]

On Wed, Mar 01, 2017 at 09:54:07AM -0800, Linus Torvalds wrote:
> On Wed, Mar 1, 2017 at 1:03 AM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> >
> > As Peter mentioned in the bug, there is a missing property on the kernel
> > node (INPUT_PROP_BUTTONPAD).
> >
> > The thing is this property is solely driven in the current driver by the
> > provided platform_data, so there is no way we ever set it through
> > hid-rmi. I wonder how we missed that.
> >
> > Anyway, the good news is that the evemu record shows only one exportted
> > button, so we can infer the property quite easily in the module. Would
> > something like that work for you?
> >
> > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Date: Wed, 1 Mar 2017 09:57:00 +0100
> > Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the button count
> 
> Yes, this fixes the problem for me. My click-and-drag works again, so
> you can add a
> 
>   Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> I see that Dmitry doesn't love the patch, but I'm assuming I'll get
> that or something equivalent soon. In the meantime, I'll just keep it
> on my laptop as a workaround.

Given that it does work for you just apply it. The objections I raised
was more of a bikeshedding.

Thanks.

-- 
Dmitry

Re: [GIT PULL] HID for 4.11

[Linus Torvalds]

On Wed, Mar 1, 2017 at 9:58 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Given that it does work for you just apply it. The objections I raised
> was more of a bikeshedding.

Ok. Patch applied directly and in my tree now,

                  Linus

[PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Jiri Kosina]

On Mon, 20 Feb 2017, Linus Torvalds wrote:

> > I'll have a more specific commit (or range) soon.
> 
> Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
> touchpads using hid-rmi").
> 
> And the reason seems to be stupid: I don't have RMI enabled at all,
> because that didn't use to work or make a difference.
> 
> Maybe that "let's use RMI" code should depend on RMI actually being
> enabled? Because as-is, that code now breaks existing configurations.

I agree; that's in line with what we usually try to stick to (force 
specific drivers if the device doesn't work with the generic at all and 
switch over to generic in compile-time for devices that have limited 
functionality with the generic driver).

Andrew, Benjamin, how about the patch below?




From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built

Commit 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
unconditionally switches over handling of all Synaptics touchpads to hid-rmi
(to make use of extended features of the HW); in case CONFIG_HID_RMI is
disabled though this renders the touchpad unusable, as the

	HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID)

match doesn't exist and generic/multitouch doesn't bind to it either (due
to hid group mismatch).

Fix this by switching over to hid-rmi only if it has been actually built.

Fixes: 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 drivers/hid/hid-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 538ff697a4cf..e9e87d337446 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -827,7 +827,8 @@ static int hid_scan_report(struct hid_device *hid)
 				 * hid-rmi should take care of them,
 				 * not hid-generic
 				 */
-				hid->group = HID_GROUP_RMI;
+				if (IS_ENABLED(CONFIG_HID_RMI))
+					hid->group = HID_GROUP_RMI;
 		break;
 	}
 

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Linus Torvalds]

On Tue, Feb 21, 2017 at 6:17 AM, Jiri Kosina <jikos@kernel.org> wrote:
>
> I agree; that's in line with what we usually try to stick to (force
> specific drivers if the device doesn't work with the generic at all and
> switch over to generic in compile-time for devices that have limited
> functionality with the generic driver).

.. and maybe we should do this same thing for the WACOM case a couple
of lines up from your patch?

              Linus

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Jiri Kosina]

On Tue, 21 Feb 2017, Linus Torvalds wrote:

> > I agree; that's in line with what we usually try to stick to (force
> > specific drivers if the device doesn't work with the generic at all and
> > switch over to generic in compile-time for devices that have limited
> > functionality with the generic driver).
> 
> .. and maybe we should do this same thing for the WACOM case a couple
> of lines up from your patch?

Well, that's far more questionable. I am pretty sure Wacom devices are 
completely dysfunctional without a specific driver, as they have their own 
protocol.

Adding Ping and Jason to CC.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Linus Torvalds]

On Tue, Feb 21, 2017 at 7:46 AM, Jiri Kosina <jikos@kernel.org> wrote:
> On Tue, 21 Feb 2017, Linus Torvalds wrote:
>>
>> .. and maybe we should do this same thing for the WACOM case a couple
>> of lines up from your patch?
>
> Well, that's far more questionable. I am pretty sure Wacom devices are
> completely dysfunctional without a specific driver, as they have their own
> protocol.

Ah, ok. Never mind then.

            Linus

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Benjamin Tissoires]

On Feb 21 2017 or thereabouts, Linus Torvalds wrote:
> On Tue, Feb 21, 2017 at 7:46 AM, Jiri Kosina <jikos@kernel.org> wrote:
> > On Tue, 21 Feb 2017, Linus Torvalds wrote:
> >>
> >> .. and maybe we should do this same thing for the WACOM case a couple
> >> of lines up from your patch?
> >
> > Well, that's far more questionable. I am pretty sure Wacom devices are
> > completely dysfunctional without a specific driver, as they have their own
> > protocol.
> 
> Ah, ok. Never mind then.
> 
>             Linus

Well, Wacom devices use to need a special driver, but the latest
generation should somewhat be able to work without a driver (IIRC).
The only thing I can think of is that Wacom devices require
HID_QUIRK_NO_INIT_REPORTS, so they might not work out of the box after
all.

Let's see what Ping and Jason think about the question.

Cheers,
Benjamin

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Jiri Kosina]

On Tue, 21 Feb 2017, Benjamin Tissoires wrote:

> Well, Wacom devices use to need a special driver, but the latest 
> generation should somewhat be able to work without a driver (IIRC). 

I vaguely recall this wasn't the case at all for the older generations 
I've had my hands on, and it wasn't just the matter of 
HID_QUIRK_NO_INIT_REPORTS quirk.

But anyway ... that wasn't reported as a regression for quite some time, 
so let's defer to what Ping and Jason have to say regarding 
protocol/driver compatibility.

I'll be pushing the RMI fix to Linus soon.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Jason Gerecke]

One of the main reasons Wacom devices have historically required a
special driver is that the HID descriptors on their branded devices are
useless. A generic driver would only know the length of a report; no
information about the contents or layout is actually provided by the
hardware. The latest generation of Wacom tablets somewhat improves the
situation, but its still not good enough for the devices to be at all
useful with an e.g. hid-generic fallback. The hardware now provides a
full descriptor, but every usage is in a Vendor Defined usage page. We
can use Wacom's usage table definitions to implement "generic Wacom"
support for these new devices (which is exactly what we did in 4.10),
but no vendor-agnostic generic driver will understand the usages.

Wacom's embedded tablet PC sensors are a different story. These devices
*do* provide generic HID descriptors and it should be possible to have
hid-generic power them as a fallback. That said, it seems that Wacom is
moving away from their 0x56A vendor ID for these embedded sensors to a
new 0x2D1F vendor ID. This VID isn't recognized by any of the existing
Wacom kernel drivers and is (as I understand) intended be a way to allow
new hardware to work with the hid-generic driver.

Jason Gerecke, Linux Software Engineer
Wacom Technology Corporation
tel: 360-896-9833 ext. 229 (direct) / fax: 360-896-9724
http://www.wacom.com

On 02/21/2017 01:03 PM, Jiri Kosina wrote:
> On Tue, 21 Feb 2017, Benjamin Tissoires wrote: > >> Well, Wacom devices use to need a special driver, but the latest
>> generation should somewhat be able to work without a driver (IIRC).
>> > > I vaguely recall this wasn't the case at all for the older >
generations I've had my hands on, and it wasn't just the matter of >
HID_QUIRK_NO_INIT_REPORTS quirk. > > But anyway ... that wasn't reported
as a regression for quite some > time, so let's defer to what Ping and
Jason have to say regarding > protocol/driver compatibility. > > I'll be
pushing the RMI fix to Linus soon. > > Thanks, >

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Benjamin Tissoires]

On Feb 21 2017 or thereabouts, Jiri Kosina wrote:
> On Mon, 20 Feb 2017, Linus Torvalds wrote:
> 
> > > I'll have a more specific commit (or range) soon.
> > 
> > Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
> > touchpads using hid-rmi").
> > 
> > And the reason seems to be stupid: I don't have RMI enabled at all,
> > because that didn't use to work or make a difference.
> > 
> > Maybe that "let's use RMI" code should depend on RMI actually being
> > enabled? Because as-is, that code now breaks existing configurations.
> 
> I agree; that's in line with what we usually try to stick to (force 
> specific drivers if the device doesn't work with the generic at all and 
> switch over to generic in compile-time for devices that have limited 
> functionality with the generic driver).
> 
> Andrew, Benjamin, how about the patch below?
> 

Hi,

Sorry, I am on PTO for the rest of the week with limited internet
access.

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

Sorry for the waste of time :(

Cheers,
Benjamin

> 
> 
> 
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built
> 
> Commit 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
> unconditionally switches over handling of all Synaptics touchpads to hid-rmi
> (to make use of extended features of the HW); in case CONFIG_HID_RMI is
> disabled though this renders the touchpad unusable, as the
> 
> 	HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID)
> 
> match doesn't exist and generic/multitouch doesn't bind to it either (due
> to hid group mismatch).
> 
> Fix this by switching over to hid-rmi only if it has been actually built.
> 
> Fixes: 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>  drivers/hid/hid-core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 538ff697a4cf..e9e87d337446 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -827,7 +827,8 @@ static int hid_scan_report(struct hid_device *hid)
>  				 * hid-rmi should take care of them,
>  				 * not hid-generic
>  				 */
> -				hid->group = HID_GROUP_RMI;
> +				if (IS_ENABLED(CONFIG_HID_RMI))
> +					hid->group = HID_GROUP_RMI;
>  		break;
>  	}
>  
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built (was Re: [GIT PULL] HID for 4.11)

[Andrew Duggan]

On 02/21/2017 06:17 AM, Jiri Kosina wrote:
> On Mon, 20 Feb 2017, Linus Torvalds wrote:
>
>>> I'll have a more specific commit (or range) soon.
>> Hmm. It's commit 279967a65b32 ("HID: rmi: Handle all Synaptics
>> touchpads using hid-rmi").
>>
>> And the reason seems to be stupid: I don't have RMI enabled at all,
>> because that didn't use to work or make a difference.
>>
>> Maybe that "let's use RMI" code should depend on RMI actually being
>> enabled? Because as-is, that code now breaks existing configurations.
> I agree; that's in line with what we usually try to stick to (force
> specific drivers if the device doesn't work with the generic at all and
> switch over to generic in compile-time for devices that have limited
> functionality with the generic driver).
>
> Andrew, Benjamin, how about the patch below?
>

I tested this patch and hid-core now correctly binds hid-mulitouch to 
the touchpad if CONFIG_HID_RMI is disabled. Sorry, about the oversight.

Tested-by: Andrew Duggan <aduggan@synaptics.com>

Thanks,
Andrew

>
>
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is not built
>
> Commit 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
> unconditionally switches over handling of all Synaptics touchpads to hid-rmi
> (to make use of extended features of the HW); in case CONFIG_HID_RMI is
> disabled though this renders the touchpad unusable, as the
>
> 	HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID)
>
> match doesn't exist and generic/multitouch doesn't bind to it either (due
> to hid group mismatch).
>
> Fix this by switching over to hid-rmi only if it has been actually built.
>
> Fixes: 279967a65b32 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>   drivers/hid/hid-core.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 538ff697a4cf..e9e87d337446 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -827,7 +827,8 @@ static int hid_scan_report(struct hid_device *hid)
>   				 * hid-rmi should take care of them,
>   				 * not hid-generic
>   				 */
> -				hid->group = HID_GROUP_RMI;
> +				if (IS_ENABLED(CONFIG_HID_RMI))
> +					hid->group = HID_GROUP_RMI;
>   		break;
>   	}
>   
>

ath10k regression on XPS13

[Kalle Valo]

(Changing subject, adding Dave and relevant lists)

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, Feb 20, 2017 at 7:20 AM, Jiri Kosina <jikos@kernel.org> wrote:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
>>
>> to receive HID subsystem updates for 4.11:
>
> The touchpad on my XPS13 no longer works. It might not be this pull
> request, and I'll bisect the exact cause, but this pull seems the most
> likely culprit.
>
> Just an early heads-up,

While talking about XPS13 also a heads-up from me as we have a nasty
regression in ath10k on XPS13 with QCA6174 (though not sure if you have
QCA6174, recent models seem to have that) which completely breaks driver
initialisation an error:

"ath10k_pci 0000:3a:00.0: failed to fetch board data for
bus=pci,vendor=168c,device=003e,subsystem-vendor=1a56,subsystem-device=1535,variant=RV_0520
from ath10k/QCA6174/hw3.0/board-2.bin"

https://bugzilla.kernel.org/show_bug.cgi?id=185621#c9

This is caused by this commit which I believe Dave will be sending to
you soon:

f2593cb1b291 ath10k: Search SMBIOS for OEM board file extension

As a workaround I recommend updating ath10k/QCA6174/hw3.0/board-2.bin
from this link _before_ updating the kernel:

https://github.com/kvalo/ath10k-firmware/blob/8d15818b0f9c7b09f743538ac2d3e1409779f52a/QCA6174/hw3.0/board-2.bin

We are working on a fix so that ath10k continues to work with older
board-2.bin, but that might take a day or two still.

-- 
Kalle Valo

Re: ath10k regression on XPS13

[David Miller]

From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 21 Feb 2017 11:32:49 +0200

> We are working on a fix so that ath10k continues to work with older
> board-2.bin, but that might take a day or two still.

Kalle I really wanted to send my net-next pull request to Linus later
today.  But I guess I have to wait for this ath10k first.

Please get this to me as soon as possible, thanks.

Re: ath10k regression on XPS13

[Kalle Valo]

David Miller <davem@davemloft.net> writes:

> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Tue, 21 Feb 2017 11:32:49 +0200
>
>> We are working on a fix so that ath10k continues to work with older
>> board-2.bin, but that might take a day or two still.
>
> Kalle I really wanted to send my net-next pull request to Linus later
> today.  But I guess I have to wait for this ath10k first.
>
> Please get this to me as soon as possible, thanks.

We have a fix now but it's not really tested that well so I'm reluctant
to submit it yet. As I don't want to make you wait I think I'll submit
you a patch reverting f2593cb1b291 in an hour or two. And later in the
week I send you a properly fixed (and tested) version of f2593cb1b291.

Does that sound ok to you?

-- 
Kalle Valo

Re: ath10k regression on XPS13

[David Miller]

From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 21 Feb 2017 20:38:48 +0200

> David Miller <davem@davemloft.net> writes:
> 
>> From: Kalle Valo <kvalo@codeaurora.org>
>> Date: Tue, 21 Feb 2017 11:32:49 +0200
>>
>>> We are working on a fix so that ath10k continues to work with older
>>> board-2.bin, but that might take a day or two still.
>>
>> Kalle I really wanted to send my net-next pull request to Linus later
>> today.  But I guess I have to wait for this ath10k first.
>>
>> Please get this to me as soon as possible, thanks.
> 
> We have a fix now but it's not really tested that well so I'm reluctant
> to submit it yet. As I don't want to make you wait I think I'll submit
> you a patch reverting f2593cb1b291 in an hour or two. And later in the
> week I send you a properly fixed (and tested) version of f2593cb1b291.
> 
> Does that sound ok to you?

Sure.

Re: ath10k regression on XPS13

[Kalle Valo]

David Miller <davem@davemloft.net> writes:

> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Tue, 21 Feb 2017 20:38:48 +0200
>
>> David Miller <davem@davemloft.net> writes:
>> 
>>> From: Kalle Valo <kvalo@codeaurora.org>
>>> Date: Tue, 21 Feb 2017 11:32:49 +0200
>>>
>>>> We are working on a fix so that ath10k continues to work with older
>>>> board-2.bin, but that might take a day or two still.
>>>
>>> Kalle I really wanted to send my net-next pull request to Linus later
>>> today.  But I guess I have to wait for this ath10k first.
>>>
>>> Please get this to me as soon as possible, thanks.
>> 
>> We have a fix now but it's not really tested that well so I'm reluctant
>> to submit it yet. As I don't want to make you wait I think I'll submit
>> you a patch reverting f2593cb1b291 in an hour or two. And later in the
>> week I send you a properly fixed (and tested) version of f2593cb1b291.
>> 
>> Does that sound ok to you?
>
> Sure.

Here's the revert:

https://patchwork.ozlabs.org/patch/730735/

I didn't send a pull request because that felt overkill to do just for
one patch.

-- 
Kalle Valo

Re: ath10k regression on XPS13

[David Miller]

From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 21 Feb 2017 21:49:09 +0200

> David Miller <davem@davemloft.net> writes:
> 
>> From: Kalle Valo <kvalo@codeaurora.org>
>> Date: Tue, 21 Feb 2017 20:38:48 +0200
>>
>>> David Miller <davem@davemloft.net> writes:
>>> 
>>>> From: Kalle Valo <kvalo@codeaurora.org>
>>>> Date: Tue, 21 Feb 2017 11:32:49 +0200
>>>>
>>>>> We are working on a fix so that ath10k continues to work with older
>>>>> board-2.bin, but that might take a day or two still.
>>>>
>>>> Kalle I really wanted to send my net-next pull request to Linus later
>>>> today.  But I guess I have to wait for this ath10k first.
>>>>
>>>> Please get this to me as soon as possible, thanks.
>>> 
>>> We have a fix now but it's not really tested that well so I'm reluctant
>>> to submit it yet. As I don't want to make you wait I think I'll submit
>>> you a patch reverting f2593cb1b291 in an hour or two. And later in the
>>> week I send you a properly fixed (and tested) version of f2593cb1b291.
>>> 
>>> Does that sound ok to you?
>>
>> Sure.
> 
> Here's the revert:
> 
> https://patchwork.ozlabs.org/patch/730735/
> 
> I didn't send a pull request because that felt overkill to do just for
> one patch.

Yep, that's fine.

Re: ath10k regression on XPS13

[Linus Torvalds]

On Tue, Feb 21, 2017 at 10:18 AM, David Miller <davem@davemloft.net> wrote:
>
> Kalle I really wanted to send my net-next pull request to Linus later
> today.  But I guess I have to wait for this ath10k first.

Feel free to send it to me - it sounds like the regression is
 (a) easy to work around
and
 (b) has a fix coming up.

And it won't even be something that I personally notice, since I have
the prev-gen XPS13 that has intel wireless.

              Linus

Re: ath10k regression on XPS13

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 21 Feb 2017 10:52:33 -0800

> On Tue, Feb 21, 2017 at 10:18 AM, David Miller <davem@davemloft.net> wrote:
>>
>> Kalle I really wanted to send my net-next pull request to Linus later
>> today.  But I guess I have to wait for this ath10k first.
> 
> Feel free to send it to me - it sounds like the regression is
>  (a) easy to work around
> and
>  (b) has a fix coming up.
> 
> And it won't even be something that I personally notice, since I have
> the prev-gen XPS13 that has intel wireless.

I have the revert in my tree, it's all good.

I'll let my tree sit quietly for a few hours then send a pull
request out later tonight.