New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xone: add support for Elite Controller from steamos_kernel #23

Closed
paroj opened this Issue Jan 24, 2016 · 15 comments

Comments

4 participants
@paroj
Owner

paroj commented Jan 24, 2016

cherry-pick this commit ValveSoftware/steamos_kernel@76e4b04

@btegs

This comment has been minimized.

Contributor

btegs commented Apr 19, 2016

So... do we have an update on this? By you not supporting the Xbox One Elite controller, it is keeping it out of the Linux kernel as they tend to use this version instead of the more up to date SteamOS one. Please merge this code in as it is almost 3 months late.

@Schroedingers-Cat

This comment has been minimized.

Schroedingers-Cat commented Apr 24, 2016

So what is the status of this one?

@dantob

This comment has been minimized.

Contributor

dantob commented Apr 26, 2016

Looks like it should work; minus the back paddles; if you just add the ID. Give it a try.

patch -Np1 -i add-xbox-one-elite-id.txt
add-xbox-one-elite-id.txt

@dantob

This comment has been minimized.

Contributor

dantob commented Apr 26, 2016

I'll assume were still talking about the Xbox One Elite controller. The patch is based on what steamos is using, whether the device is actually working with steamos idk. Patch just adds the usb ID. The rest of the code just appears to allow the paddles to be mapped separately from ABXY and not necessary to get the device to work. Possibly more of the steamos initialization packets are needed.

You should hopefully see something in dmesg
input: Microsoft X-Box One pad (Firmware 2015) as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/input/input48

Try the jstest tool that comes from this repository https://sourceforge.net/projects/linuxconsole/
jstest /dev/input/js0 (for first joystick device)

Should see output something like this, press the buttons and make sure they respond correctly.
Driver version is 2.1.0. Joystick (Microsoft X-Box One pad (Firmware 2015)) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y) and 11 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR). Testing ... (interrupt to exit) Axes: 0: 2009 1: 1031 2:-32767 3: 266 4: 0 5:-32767 6: 0 7: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off

@Schroedingers-Cat

This comment has been minimized.

Schroedingers-Cat commented Apr 26, 2016

Yes, I'm using an Xbox One Elite version of the controller.
This is from dmesg:

[ 4477.543744] usb 1-1.2: new full-speed USB device number 11 using ehci-pci
[ 4477.639219] usb 1-1.2: New USB device found, idVendor=045e, idProduct=02e3
[ 4477.639223] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4477.639226] usb 1-1.2: Product: Controller
[ 4477.639227] usb 1-1.2: Manufacturer: Microsoft
[ 4477.639229] usb 1-1.2: SerialNumber: 7EED85BA111B
[ 4477.639817] input: Microsoft X-Box One Elite pad as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input21
[ 4477.640672] xpad 1-1.2:1.0: xpad_prepare_next_out_packet - found pending output packet 0
[ 4477.652840] xpad 1-1.2:1.0: xpad_irq_in - nonzero urb status received: -75
[ 4477.665890] xpad 1-1.2:1.0: xpad_irq_in - urb shutting down with status: -2
[ 4477.699830] xpad 1-1.2:1.0: xpad_prepare_next_out_packet - found pending output packet 0
[ 4477.733892] xpad 1-1.2:1.0: xpad_irq_in - urb shutting down with status: -2
[ 4478.667857] xpad 1-1.2:1.0: xpad_prepare_next_out_packet - found pending output packet 0
[ 4478.680900] xpad 1-1.2:1.0: xpad_irq_in - nonzero urb status received: -75
[ 4478.689935] xpad 1-1.2:1.0: xpad_irq_in - urb shutting down with status: -2

With jstest, I get the following output:

$ jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (Microsoft X-Box One Elite pad) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y)
and 11 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR).
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:-32767  3:     0  4:     0  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 

However, moving an axis or pressing a button doesn't change any of the values.

@paroj

This comment has been minimized.

Owner

paroj commented Apr 26, 2016

just adding the id is not enough. The steamos patch also increases the packet size and adds a 3 packet init sequence. (I will remove the clrf discussion as it is not relevant here)

@dantob

This comment has been minimized.

Contributor

dantob commented Apr 26, 2016

The steamos patch also increases the packet size

nonzero urb status received: -75
EOVERFLOW, looks like it is needed.

and adds a 3 packet init sequence

The other two init packets look the same as those initially used (and deemed unnecessary) for the xbox one controller. It's possible the windows driver just tries all init packets for all device types and doesn't filter by ID.

@paroj

This comment has been minimized.

Owner

paroj commented Apr 26, 2016

so in theory 744b785 should do it? could somebody with the elite controller test current master?

The other two init packets look the same as those initially used (and deemed unnecessary) for the xbox one controller.

nice catch btw

@dantob

This comment has been minimized.

Contributor

dantob commented Apr 27, 2016

https://franticrain.github.io/sniffs/XboxOneSniff.html has some good info. It appears to show the packets are (odly) 33 bytes long?

@Schroedingers-Cat

This comment has been minimized.

Schroedingers-Cat commented Apr 27, 2016

I just tried the latest master and it works! jstes, steam and games react to input from the controller! Thank you for your work!

Some games however treat the controller as a "nonstandard" controller, i guess because they do not know that the Xbox One Elite controller basically works the same as the Xbox 360 controller.
I just checked and realized they have one tiny difference. On the Xbox360, the D Pad is reported as both, as button (11-14) and axis (6 and 7), while the Xbox One Elite only sends the D Pad as Axis (6 and 7). Do you think it would be possible to allow a special mode where the Xbox One Elite controller is reported to be an Xbox 360 controller? And in that mode, the Elite controller would also report its D Pad axes as buttons, just to be safe?

@paroj

This comment has been minimized.

Owner

paroj commented Apr 27, 2016

On the Xbox360, the D Pad is reported as both, as button (11-14) and axis (6 and 7), while the Xbox One Elite only sends the D Pad as Axis (6 and 7).

this is only the case for the wireless controller see 8be1d4a

@paroj paroj closed this Apr 27, 2016

paroj added a commit that referenced this issue Apr 27, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

paroj added a commit that referenced this issue Apr 27, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

paroj added a commit that referenced this issue Apr 27, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

paroj added a commit that referenced this issue Apr 27, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

Signed-off-by:  Pierre-Loup A. Griffais <eduke32@plagman.net>
@Schroedingers-Cat

This comment has been minimized.

Schroedingers-Cat commented Apr 27, 2016

Thanks for the info!
But what about an option to trick the games into thinking that the Xbox One Elite Controller is a Xbox 360 controller? Again, several games just look if it is an xbox 360 controller and if it's not they treat it as an unknown gamepad where you have the map the controls manually (for instance Fez).

@paroj

This comment has been minimized.

Owner

paroj commented Apr 27, 2016

The kernel driver is the wrong place to handle such quirks. See the discussion in #21. Maybe Fez can be "fixed" by adding the elite controller to the SDL2 database.

paroj added a commit that referenced this issue Apr 28, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

Signed-off-by:  Pierre-Loup A. Griffais <eduke32@plagman.net>
@dantob

This comment has been minimized.

Contributor

dantob commented Apr 29, 2016

@Schroedingers-Cat Do the elite paddles work at all, do they map to they same buttons as ABXY?

@Schroedingers-Cat

This comment has been minimized.

Schroedingers-Cat commented May 2, 2016

The elite paddles are mapped as buttons 0-3, from paddle 1-4.

However, I don't use the configuration app for the elite controller as I don't want to use a Microsoft account. So maybe the mapping configured with that app is saved into a memory on the controller.

paroj added a commit that referenced this issue May 3, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>

paroj added a commit that referenced this issue May 26, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>

dtor added a commit to dtor/input that referenced this issue May 28, 2016

Input: xpad - xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

paroj added a commit that referenced this issue Jun 5, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: #23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>

dirty-hank added a commit to dirty-hank/frankenclark that referenced this issue Sep 3, 2016

Input: xpad: xbox one elite controller support
added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>

UpInTheAir added a commit to UpInTheAir/Exynos-7420-MM that referenced this issue Mar 24, 2017

xpad.c: squash of commits from Linux
Signed-off-by: UpInTheAir <upintheair.xda@gmail.com>

Input: xpad - remove unused function

There are two definitions of xpad_identify_controller(), one is used
when CONFIG_JOYSTICK_XPAD_LEDS is set, but the other one is empty
and never used, and we get a gcc warning about it:

drivers/input/joystick/xpad.c:1210:13: warning: 'xpad_identify_controller' defined but not used [-Wunused-function]

This removes the second definition.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: cae705baa40b ("Input: xpad - re-send LED command on present event")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - add Mad Catz FightStick TE 2 VID/PID

This adds the VID/PID combination for the Xbox One version of the Mad
Catz FightStick TE 2.

The functionality that this provides is about on par with what the
Windows drivers for the stick manage to deliver.

What works:
- Digital stick
- 6 main buttons
- Xbox button
- The two buttons on the back
- The locking buttons (preventing accidental Xbox button press)

What doesn't work:
- Two of the main buttons (don't work on Windows either)
- The "Haptic" button setting does not have an effect (not sure if it
  works on Windows)

I added the MAP_TRIGGERS_TO_BUTTONS option but in my (limited) testing
there was no practical difference with or without. The FightStick does
not have triggers though so adding it makes sense.

Signed-off-by: Silvan Jegen <s.jegen@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - move pending clear to the correct location

otherwise we lose ff commands: paroj/xpad#27

Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - prevent spurious input from wired Xbox 360 controllers

After initially connecting a wired Xbox 360 controller or sending it
a command to change LEDs, a status/response packet is interpreted as
controller input. This causes the state of buttons represented in
byte 2 of the controller data packet to be incorrect until the next
valid input packet. Wireless Xbox 360 controllers are not affected.

Writing a new value to the LED device while holding the Start button
and running jstest is sufficient to reproduce this bug. An event will
come through with the Start button released.

Xboxdrv also won't attempt to read controller input from a packet
where byte 0 is non-zero. It also checks that byte 1 is 0x14, but
that value differs between wired and wireless controllers and this
code is shared by both. I think just checking byte 0 is enough to
eliminate unwanted packets.

The following are some examples of 3-byte status packets I saw:
01 03 02
02 03 00
03 03 03
08 03 00

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - add more third-party controllers

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Signed-off-by: aronschatz <aronschatz@aselabs.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - xbox one elite controller support

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

UpInTheAir added a commit to UpInTheAir/Exynos-7420-MM that referenced this issue Mar 24, 2017

xpad.c: squash of commits from Linux
Signed-off-by: UpInTheAir <upintheair.xda@gmail.com>

Input: xpad - remove unused function

There are two definitions of xpad_identify_controller(), one is used
when CONFIG_JOYSTICK_XPAD_LEDS is set, but the other one is empty
and never used, and we get a gcc warning about it:

drivers/input/joystick/xpad.c:1210:13: warning: 'xpad_identify_controller' defined but not used [-Wunused-function]

This removes the second definition.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: cae705baa40b ("Input: xpad - re-send LED command on present event")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - add Mad Catz FightStick TE 2 VID/PID

This adds the VID/PID combination for the Xbox One version of the Mad
Catz FightStick TE 2.

The functionality that this provides is about on par with what the
Windows drivers for the stick manage to deliver.

What works:
- Digital stick
- 6 main buttons
- Xbox button
- The two buttons on the back
- The locking buttons (preventing accidental Xbox button press)

What doesn't work:
- Two of the main buttons (don't work on Windows either)
- The "Haptic" button setting does not have an effect (not sure if it
  works on Windows)

I added the MAP_TRIGGERS_TO_BUTTONS option but in my (limited) testing
there was no practical difference with or without. The FightStick does
not have triggers though so adding it makes sense.

Signed-off-by: Silvan Jegen <s.jegen@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - move pending clear to the correct location

otherwise we lose ff commands: paroj/xpad#27

Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - prevent spurious input from wired Xbox 360 controllers

After initially connecting a wired Xbox 360 controller or sending it
a command to change LEDs, a status/response packet is interpreted as
controller input. This causes the state of buttons represented in
byte 2 of the controller data packet to be incorrect until the next
valid input packet. Wireless Xbox 360 controllers are not affected.

Writing a new value to the LED device while holding the Start button
and running jstest is sufficient to reproduce this bug. An event will
come through with the Start button released.

Xboxdrv also won't attempt to read controller input from a packet
where byte 0 is non-zero. It also checks that byte 1 is 0x14, but
that value differs between wired and wireless controllers and this
code is shared by both. I think just checking byte 0 is enough to
eliminate unwanted packets.

The following are some examples of 3-byte status packets I saw:
01 03 02
02 03 00
03 03 03
08 03 00

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - add more third-party controllers

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Signed-off-by: aronschatz <aronschatz@aselabs.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: xpad - xbox one elite controller support

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

corsicanu pushed a commit to corsicanu/android_kernel_samsung_universal7880 that referenced this issue Dec 1, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

mydongistiny added a commit to BenzoRom/kernel_google_marlin that referenced this issue Dec 1, 2018

Linux: 3.18.128-rc1
commit 1db527abf726d5f4cc45698654cc9761b566725c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Nov 29 15:01:36 2018 +0100

    Linux 3.18.128-rc1

    Change-Id: I0e65f1781d8bbc6e2cb456544f4aee6eeac73491
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 6062d7ff33eaaaecc150bef8f6fb3e1aedc83ffd
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Thu Nov 15 11:42:16 2018 +0100

    drm/ast: Remove existing framebuffers before loading driver

    commit 5478ad10e7850ce3d8b7056db05ddfa3c9ddad9a upstream.

    If vesafb attaches to the AST device, it configures the framebuffer memory
    for uncached access by default. When ast.ko later tries to attach itself to
    the device, it wants to use write-combining on the framebuffer memory, but
    vesefb's existing configuration for uncached access takes precedence. This
    results in reduced performance.

    Removing the framebuffer's configuration before loding the AST driver fixes
    the problem. Other DRM drivers already contain equivalent code.

    Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: <stable@vger.kernel.org>
    Tested-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Tested-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9c8d3cea52fa9bc96b56aadd94d21c312589741b
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Mon Jan 23 11:17:35 2017 -0800

    af_unix: move unix_mknod() out of bindlock

    commit 0fb44559ffd67de8517098b81f675fa0210f13f0 upstream.

    Dmitry reported a deadlock scenario:

    unix_bind() path:
    u->bindlock ==> sb_writer

    do_splice() path:
    sb_writer ==> pipe->mutex ==> u->bindlock

    In the unix_bind() code path, unix_mknod() does not have to
    be done with u->bindlock held, since it is a pure fs operation,
    so we can just move unix_mknod() out.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Petr Vorel <pvorel@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 4622d0fdeecf63728b7013f96de89ca161ec5068
Author: Greg Kroah-Hartman <greg@kroah.com>
Date:   Thu Oct 4 11:06:14 2018 -0700

    tty: wipe buffer if not echoing data

    commit b97b3d9fb57860a60592859e332de7759fd54c2e upstream.

    If we are not echoing the data to userspace or the console is in icanon
    mode, then perhaps it is a "secret" so we should wipe it once we are
    done with it.

    This mirrors the logic that the audit code has.

    Reported-by: aszlig <aszlig@nix.build>
    Tested-by: Milan Broz <gmazyland@gmail.com>
    Tested-by: Daniel Zatovic <daniel.zatovic@gmail.com>
    Tested-by: aszlig <aszlig@nix.build>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Change-Id: I29075af365fe48bb1a6afebd7ba964564c66d3be
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 21a512825d32ecc0871b95396b8e981483d6bbe5
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Oct 4 11:06:13 2018 -0700

    tty: wipe buffer.

    commit c9a8e5fce009e3c601a43c49ea9dbcb25d1ffac5 upstream.

    After we are done with the tty buffer, zero it out.

    Reported-by: aszlig <aszlig@nix.build>
    Tested-by: Milan Broz <gmazyland@gmail.com>
    Tested-by: Daniel Zatovic <daniel.zatovic@gmail.com>
    Tested-by: aszlig <aszlig@nix.build>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 2d4893fbdcd04575726dcab6d9e876a0a0417ba1
Author: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Date:   Mon Nov 7 17:53:30 2016 -0200

    scsi: qla2xxx: do not queue commands when unloading

    commit 04dfaa53a0b6e66b328a5bc549e3af8f8b6eac02 upstream.

    When the driver is unloading, in qla2x00_remove_one(), there is a single
    call/point in time to abort ongoing commands, qla2x00_abort_all_cmds(),
    which is still several steps away from the call to scsi_remove_host().

    If more commands continue to arrive and be processed during that
    interval, when the driver is tearing down and releasing its structures,
    it might potentially hit an oops due to invalid memory access:

        Unable to handle kernel paging request for data at address 0x00000138
        <...>
        NIP [d000000004700a40] qla2xxx_queuecommand+0x80/0x3f0 [qla2xxx]
        LR [d000000004700a10] qla2xxx_queuecommand+0x50/0x3f0 [qla2xxx]

    So, fail commands in qla2xxx_queuecommand() if the UNLOADING bit is set.

    Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
    Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 837fd1cdc8110ada3b2a76995bdc4f7b4304e2fb
Author: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Date:   Mon Oct 17 17:10:53 2016 -0700

    scsi: ufshcd: Fix race between clk scaling and ungate work

    commit f2a785ac23125fa0774327d39e837e45cf28fe92 upstream.

    The ungate work turns on the clock before it exits hibern8, if the link
    was put in hibern8 during clock gating work.  There occurs a race
    condition when clock scaling work calls ufshcd_hold() to make sure low
    power states cannot be entered, but that returns by checking only
    whether the clocks are on.  This causes the clock scaling work to issue
    UIC commands when the link is in hibern8 causing failures. Make sure we
    exit hibern8 state before returning from ufshcd_hold().

    Callstacks for race condition:

     ufshcd_scale_gear
     ufshcd_devfreq_scale
     ufshcd_devfreq_target
     update_devfreq
     devfreq_monitor
     process_one_work
     worker_thread
     kthread
     ret_from_fork

     ufshcd_uic_hibern8_exit
     ufshcd_ungate_work
     process_one_work
     worker_thread
     kthread
     ret_from_fork

    Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
    Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 3868c24b13584fc43829ed6fb6b50d67b24e901d
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date:   Fri Sep 30 14:39:17 2016 +0200

    cw1200: Don't leak memory if krealloc failes

    commit 9afdd6128c39f42398041bb2e017d8df0dcebcd1 upstream.

    The call to krealloc() in wsm_buf_reserve() directly assigns the newly
    returned memory to buf->begin. This is all fine except when krealloc()
    failes we loose the ability to free the old memory pointed to by
    buf->begin. If we just create a temporary variable to assign memory to
    and assign the memory to it we can mitigate the memory leak.

    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit b6123f76c15bce57c776ba519b8adcc94e8fd7f8
Author: Ramses Ramírez <ramzeto@gmail.com>
Date:   Fri Sep 28 16:59:26 2018 -0700

    Input: xpad - add support for Xbox1 PDP Camo series gamepad

    [ Upstream commit 9735082a7cbae572c2eabdc45acecc8c9fa0759b ]

    The "Xbox One PDP Wired Controller - Camo series" has a different
    product-id than the regular PDP controller and the PDP stealth series,
    but it uses the same initialization sequence. This patch adds the
    product-id of the camo series to the structures that handle the other
    PDP Xbox One controllers.

    Signed-off-by: Ramses Ramírez <ramzeto@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e268b3b310a8161275a2517b335fa7d5ef49fc9d
Author: Enno Boland <gottox@voidlinux.eu>
Date:   Tue Jun 19 11:55:33 2018 -0700

    Input: xpad - fix GPD Win 2 controller name

    [ Upstream commit dd6bee81c942c0ea01030da9356026afb88f9d18 ]

    This fixes using the controller with SDL2.

    SDL2 has a naive algorithm to apply the correct settings to a controller.
    For X-Box compatible controllers it expects that the controller name
    contains a variation of a 'XBOX'-string.

    This patch changes the identifier to contain "X-Box" as substring.  Tested
    with Steam and C-Dogs-SDL which both detect the controller properly after
    adding this patch.

    Fixes: c1ba08390a8b ("Input: xpad - add GPD Win 2 Controller USB IDs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Enno Boland <gottox@voidlinux.eu>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1874062f89632e15a22f0b849b843ec132f881f1
Author: Ethan Lee <flibitijibibo@gmail.com>
Date:   Fri Jun 1 11:46:08 2018 -0700

    Input: xpad - add GPD Win 2 Controller USB IDs

    [ Upstream commit c1ba08390a8bb13c927e699330896adc15b78205 ]

    GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp

    Tested on a unit from the first production run sent to Indiegogo backers

    Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 0034247db3340ad95703980b625c2456098d4ace
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Tue May 8 15:17:07 2018 -0700

    Input: xpad - avoid using __set_bit() for capabilities

    [ Upstream commit a01308031c2647ed5f1c845104b73a8820a958a9 ]

    input_set_capability() and input_set_abs_param() will do it for you.

    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 8d569063a324c9c7de642c0051d0f21177193ea9
Author: Leo Sperling <leosperling97@gmail.com>
Date:   Wed Aug 3 17:31:09 2016 -0700

    Input: xpad - fix some coding style issues

    [ Upstream commit 68c78d0155e37992268664e134996d2b140ddf38 ]

    Fix some coding style issues reported by checkpatch.pl. Mostly brackets
    in macros, spacing and comment style.

    Signed-off-by: Leo Sperling <leosperling97@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 8d34e98fb5bae8632a838d396043209acf587d76
Author: Francis Therien <frtherien@gmail.com>
Date:   Mon Mar 26 15:59:00 2018 -0700

    Input: xpad - add PDP device id 0x02a4

    [ Upstream commit c6c848572f4da0e34ffe0a35364b4db871e13e42 ]

    Adds support for a PDP Xbox One controller with device ID
    (0x06ef:0x02a4). The Product string for this device is "PDP Wired
    Controller for Xbox One - Stealth Series | Phantom Black".

    Signed-off-by: Francis Therien <frtherien@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit c621992d7b0571b34b241db848efd7b710706f6a
Author: Mark Furneaux <mark@furneaux.ca>
Date:   Mon Jan 22 11:24:17 2018 -0800

    Input: xpad - add support for PDP Xbox One controllers

    [ Upstream commit e5c9c6a885fad00aa559b49d8fc23a60e290824e ]

    Adds support for the current lineup of Xbox One controllers from PDP
    (Performance Designed Products). These controllers are very picky with
    their initialization sequence and require an additional 2 packets before
    they send any input reports.

    Signed-off-by: Mark Furneaux <mark@furneaux.ca>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e9957b6304bf96ebce65701aa3ed0255bffe9a4e
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Tue Sep 12 11:27:44 2017 -0700

    Input: xpad - validate USB endpoint type during probe

    [ Upstream commit 122d6a347329818419b032c5a1776e6b3866d9b9 ]

    We should only see devices with interrupt endpoints. Ignore any other
    endpoints that we find, so we don't send try to send them interrupt URBs
    and trigger a WARN down in the USB stack.

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: <stable@vger.kernel.org> # c01b5e7464f0 Input: xpad - don't depend on endpoint order
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 2adf59a5bc2af42e7e6f9fde2fb488cc3061490f
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Thu Aug 31 11:52:20 2017 -0700

    Input: xpad - fix PowerA init quirk for some gamepad models

    [ Upstream commit f5308d1b83eba20e69df5e0926ba7257c8dd9074 ]

    The PowerA gamepad initialization quirk worked with the PowerA
    wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
    that it didn't work for him, even though our gamepads shared the
    same vendor and product IDs.

    When I initially implemented the PowerA quirk, I wanted to avoid
    actually triggering the rumble action during init. My tests showed
    that my gamepad would work correctly even if it received a rumble
    of 0 intensity, so that's what I went with.

    Unfortunately, this apparently isn't true for all models (perhaps
    a firmware difference?). This non-working gamepad seems to require
    the real magic rumble packet that the Microsoft driver sends, which
    actually vibrates the gamepad. To counteract this effect, I still
    send the old zero-rumble PowerA quirk packet which cancels the
    rumble effect before the motors can spin up enough to vibrate.

    [0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867

    Reported-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
    Tested-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
    Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads")
    Cc: stable@vger.kernel.org # v4.12
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 5573f0cb36016e15e45d20b521b40480170ac98a
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Mon Aug 7 20:04:13 2017 -0700

    Input: xpad - constify usb_device_id

    [ Upstream commit 94aef061c796d3d47f1a2eed41e651ffaaade402 ]

    usb_device_id are not supposed to change at runtime. All functions
    working with usb_device_id provided by <linux/usb.h> work with
    const usb_device_id. So mark the non-const structs as const.

    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d7fd20d19c61a8085ac4ce8011345062f9bbfc16
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun Jun 18 15:41:20 2017 -0700

    Input: xpad - sync supported devices with XBCD

    [ Upstream commit be19788c73d382f66dd3fba3c5ccef59cf12a126 ]

    XBCD [0][1] is an OpenSource driver for Xbox controllers on Windows.
    Later it also started supporting Xbox360 controllers (presumably before
    the official Windows driver was released).

    It contains a couple device IDs unknown to the Linux driver, so I extracted
    those from xbcd.inf and added them to our list.

    It has a special type for Wheels and I have the feeling they might need
    some extra handling. They all have 'Wheel' in their name, so that
    information is available for future improvements.

    [0] https://www.s-config.com/xbcd-original-xbox-controllers-win10/
    [1] http://www.redcl0ud.com/xbcd.html

    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 73eff63b2d49a72f79912bb5208d6fb6e7feec4e
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun Jun 18 15:40:37 2017 -0700

    Input: xpad - sync supported devices with 360Controller

    [ Upstream commit c225370e01b87d3c4ef40d98295ac0bb1e5a3116 ]

    360Controller [0] is an OpenSource driver for Xbox/Xbox360/XboxOne
    controllers on macOS.

    It contains a couple device IDs unknown to the Linux driver, so I wrote a
    small Python script [1] to extract them and feed them into my previous
    script [2] to compare them with the IDs known to Linux.

    For most devices, this information is not really needed as xpad is able to
    automatically detect the type of an unknown Xbox Controller at run-time.
    I've therefore stripped all the generic/vague entries.

    I've excluded the Logitech G920, it's handled by a HID driver already.
    I've also excluded the Scene It! Big Button IR, it's handled by an
    out-of-tree driver. [3]

    [0] https://github.com/360Controller/360Controller
    [1] http://codepad.org/v9GyLKMq
    [2] http://codepad.org/qh7jclpD
    [3] https://github.com/micolous/xbox360bb

    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 18dfc9d2ef06407b7588ef597867430c6f206b91
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun May 7 14:49:09 2017 -0700

    Input: xpad - add USB IDs for Mad Catz Brawlstick and Razer Sabertooth

    [ Upstream commit 4706aa075662fe3cad29c3f49b50878de53f4f3b ]

    Add USB IDs for two more Xbox 360 controllers.

    I found them in the pull requests for the xboxdrv userspace driver, which
    seems abandoned.

    Thanks to psychogony and mkaito for reporting the IDs there!

    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d20d73dab83588fe3652c6bdb9bd064e1bcdfae8
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun May 7 14:48:14 2017 -0700

    Input: xpad - sync supported devices with xboxdrv

    [ Upstream commit 44bc722593201da43862b7200ee0b98155410b07 ]

    The userspace xboxdrv driver [0] contains some USB IDs unknown to the
    kernel driver. I have created a simple script [1] to extract the missing
    devices and add them to xpad.

    A quick google search confirmed that all the new devices called
    Fightstick/pad are Arcade-type devices [2] where the
    MAP_TRIGGERS_TO_BUTTONS option should apply.

    There are some similar devices in the existing device table where this
    flag is not set, but I did refrain from changing those.

    [0] https://github.com/xboxdrv/xboxdrv/blob/stable/src/xpad_device.cpp
    [1] http://codepad.org/CHV98BNH
    [2] https://www.google.com/search?q=SFxT+Fightstick+Pro&tbm=isch

    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 35e63f4f00700f4f039d1f68752a6e1959ab3fed
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun May 7 14:45:08 2017 -0700

    Input: xpad - sort supported devices by USB ID

    [ Upstream commit 873cb582738fde338ecaeaca594560cde2ba42c3 ]

    Some entries in the table of supported devices are out of order.
    To not create a mess when adding new ones using a script, sort them first.

    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1a60b4b313ee218d9e78d3f98bf4c4c2bba66d6d
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Mon Apr 10 20:43:04 2017 -0700

    Input: xpad - support some quirky Xbox One pads

    [ Upstream commit 81093c9848a781b85163d06de92ef8f84528cf6a ]

    There are several quirky Xbox One pads that depend on initialization
    packets that the Microsoft pads don't require. To deal with these,
    I've added a mechanism for issuing device-specific initialization
    packets using a VID/PID-based quirks list.

    For the initial set of init quirks, I have added quirk handling from
    Valve's Steam Link xpad driver[0] and the 360Controller project[1] for
    macOS to enable some new pads to work properly.

    This should enable full functionality on the following quirky pads:
    0x0e6f:0x0165 - Titanfall 2 gamepad (previously fully non-functional)
    0x0f0d:0x0067 - Hori Horipad (analog sticks previously non-functional)
    0x24c6:0x541a - PowerA Xbox One pad (previously fully non-functional)
    0x24c6:0x542a - PowerA Xbox One pad (previously fully non-functional)
    0x24c6:0x543a - PowerA Xbox One pad (previously fully non-functional)

    [0]: https://github.com/ValveSoftware/steamlink-sdk/blob/master/kernel/drivers/input/joystick/xpad.c
    [1]: https://github.com/360Controller/360Controller

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f403691991bfab3d456d4e2173cf0932541eaee2
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Mon Feb 6 17:03:03 2017 -0800

    Input: xpad - restore LED state after device resume

    [ Upstream commit a1fbf5bbef025b4844162b3b8868888003a7ee9c ]

    Set the LED_CORE_SUSPENDRESUME flag on our LED device so the
    LED state will be automatically restored by LED core on resume.

    Since Xbox One pads stop flashing only when reinitialized, we'll
    send them the initialization packet so they calm down too.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 4f446c52b8d143263a169ea04f3583db63f8e235
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Mon Feb 6 13:56:10 2017 -0800

    Input: xpad - fix stuck mode button on Xbox One S pad

    [ Upstream commit 57b8443d3e5bd046a519ff714ca31c64c7f04309 ]

    The Xbox One S requires an ack to its mode button report, otherwise it
    continuously retransmits the report. This makes the mode button appear to
    be stuck down after it is pressed for the first time.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f4f604511c9a94b1357203f95399758e069323e6
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Tue Jan 3 22:40:38 2017 -0800

    Input: xpad - don't depend on endpoint order

    [ Upstream commit c01b5e7464f0cf20936d7467c7528163c4e2782d ]

    The order of endpoints is well defined on official Xbox pads, but
    we have found at least one 3rd-party pad that doesn't follow the
    standard ("Titanfall 2 Xbox One controller" 0e6f:0165).

    Fortunately, we get lucky with this specific pad because it uses
    endpoint addresses that differ only by direction. We know that
    there are other pads out where this is not true, so let's go
    ahead and fix this.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d44f236694148c05dec00f1a75d754ac4706fc57
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:26:33 2016 -0700

    Input: xpad - simplify error condition in init_output

    [ Upstream commit a8c34e27fb1ece928ec728bfe596aa6ca0b1928a ]

    Replace first goto with simple returns as we really are just returning
    one error code.

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 47fc8b0deacebf9a5f8f9fd3ebf6627793b52001
Author: Daniel Tobias <dan.g.tob@gmail.com>
Date:   Fri May 27 16:25:32 2016 -0700

    Input: xpad - move reporting xbox one home button to common function

    [ Upstream commit 4f88476c75429ba9ab71c428b4cd2f67575bc9c1 ]

    xbox one was the only device that has a *_process_buttons routine.

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit baf0442a7f323546b85f7590a23286951365368a
Author: Daniel Tobias <dan.g.tob@gmail.com>
Date:   Fri May 27 16:25:10 2016 -0700

    Input: xpad - correctly sort vendor id's

    [ Upstream commit c02fc1d9e5d9f093296e43e13ec7f35f140784bd ]

    Signed-off-by: Daniel Tobias <dan.g.tob@gmail.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e0a9326f57796cb0a7fe204c327c4c8d6857f6ca
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Tue Dec 27 11:44:51 2016 -0800

    Input: xpad - use correct product id for x360w controllers

    [ Upstream commit b6fc513da50c5dbc457a8ad6b58b046a6a68fd9d ]

    currently the controllers get the same product id as the wireless
    receiver. However the controllers actually have their own product id.

    The patch makes the driver expose the same product id as the windows
    driver.

    This improves compatibility when running applications with WINE.

    see https://github.com/paroj/xpad/issues/54

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f22ec1c5f0d4a987db4bf74c2c80c5af2bd8f8fa
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Sun Nov 27 20:37:56 2016 -0800

    Input: xpad - fix Xbox One rumble stopping after 2.5 secs

    [ Upstream commit ae3b4469dbcd3b842a9fd20940946e4d092d8731 ]

    Unlike previous Xbox pads, the Xbox One pad doesn't have "sticky" rumble
    packets. The duration is encoded into the command and expiration is handled
    by the pad firmware.

    ff-memless needs pseudo-sticky behavior for rumble effects to behave
    properly for long duration effects. We already specify the maximum rumble
    on duration in the command packets, but it's still only good for about 2.5
    seconds of rumble. This is easily reproducible running fftest's sine
    vibration test.

    It turns out there's a repeat count encoded in the rumble command. We can
    abuse that to get the pseudo-sticky behavior needed for rumble to behave as
    expected for effects with long duration.

    By my math, this change should allow a single ff_effect to rumble for 10
    minutes straight, which should be more than enough for most needs.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit bfbe5d63a18d0ce8c367fdd7822abf746f3cfe46
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Sun Nov 27 20:37:31 2016 -0800

    Input: xpad - add product ID for Xbox One S pad

    [ Upstream commit 599b8c09d974d6e4d85a8f7bc8ed7442977866a8 ]

    This is the new gamepad that ships with the Xbox One S which
    includes Bluetooth functionality.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit b18dbae0fc2ec4bfe9ba81c6f2b242b535cfecf5
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Wed Jul 27 14:24:55 2016 -0700

    Input: xpad - power off wireless 360 controllers on suspend

    [ Upstream commit f712a5a05228058f6b74635546549d4a46e117fc ]

    When the USB wireless adapter is suspended, the controllers
    lose their connection. This causes them to start flashing
    their LED rings and searching for the wireless adapter
    again, wasting the controller's battery power.

    Instead, we will tell the controllers to power down when
    we suspend. This mirrors the behavior of the controllers
    when connected to the console itself and how the official
    Xbox One wireless adapter behaves on Windows.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f87be35d750ae8d60a88356e0d9e491cc5b7f887
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Thu Jun 23 10:24:42 2016 -0700

    Input: xpad - fix oops when attaching an unknown Xbox One gamepad

    [ Upstream commit c7f1429389ec1aa25e042bb13451385fbb596f8c ]

    Xbox One controllers have multiple interfaces which all have the
    same class, subclass, and protocol. One of the these interfaces
    has only a single endpoint. When Xpad attempts to bind to this
    interface, it causes an oops when trying initialize the output URB
    by trying to access the second endpoint's descriptor.

    This situation was avoided for known Xbox One devices by checking
    the XTYPE constant associated with the VID and PID tuple. However,
    this breaks when new or previously unknown Xbox One controllers
    are attached to the system.

    This change addresses the problem by deriving the XTYPE for Xbox
    One controllers based on the interface protocol before checking
    the interface number.

    Fixes: 1a48ff81b391 ("Input: xpad - add support for Xbox One controllers")
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f8e0c9ab2eedcae4c9c892eda56b00eb63a6bef5
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Wed Jun 1 11:32:51 2016 -0700

    Input: xpad - fix rumble on Xbox One controllers with 2015 firmware

    [ Upstream commit 540c26087bfbad6ea72758b76b16ae6282a73fea ]

    Xbox One controllers that shipped with or were upgraded to the 2015
    firmware discard the current rumble packets we send. This patch changes
    the Xbox One rumble packet to a form that both the newer and older
    firmware will accept.

    It is based on changes made to support newer Xbox One controllers in
    the SteamOS brewmaster-4.1 kernel branch.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 01c8355393a28249d83217ffd8bde6e3bfcd9f52
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:24:40 2016 -0700

    Input: xpad - xbox one elite controller support

    [ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

    added the according id and incresed XPAD_PKT_LEN to 64 as the elite
    controller sends at least 33 byte messages [1].
    Verified to be working by [2].

    [1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
    [2]: https://github.com/paroj/xpad/issues/23

    Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9b896d497204db7bffe8dbcaf960a2c39ee99a19
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:24:20 2016 -0700

    Input: xpad - add more third-party controllers

    [ Upstream commit 6538c3b2d2d220a974e47928b165ea09b9cfa6b4 ]

    Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
    Signed-off-by: Thomas Debesse <dev@illwieckz.net>
    Signed-off-by: aronschatz <aronschatz@aselabs.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 4affab94869bbe865deda288b4986c7db90614f1
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Fri May 27 16:23:50 2016 -0700

    Input: xpad - prevent spurious input from wired Xbox 360 controllers

    [ Upstream commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 ]

    After initially connecting a wired Xbox 360 controller or sending it
    a command to change LEDs, a status/response packet is interpreted as
    controller input. This causes the state of buttons represented in
    byte 2 of the controller data packet to be incorrect until the next
    valid input packet. Wireless Xbox 360 controllers are not affected.

    Writing a new value to the LED device while holding the Start button
    and running jstest is sufficient to reproduce this bug. An event will
    come through with the Start button released.

    Xboxdrv also won't attempt to read controller input from a packet
    where byte 0 is non-zero. It also checks that byte 1 is 0x14, but
    that value differs between wired and wireless controllers and this
    code is shared by both. I think just checking byte 0 is enough to
    eliminate unwanted packets.

    The following are some examples of 3-byte status packets I saw:
    01 03 02
    02 03 00
    03 03 03
    08 03 00

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9e182eae9d257ec50806fb2c2ac650a4502113a2
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:22:25 2016 -0700

    Input: xpad - move pending clear to the correct location

    [ Upstream commit 4efc6939a83c54fb3417541be48991afd0290ba3 ]

    otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 5a2c70c201578ec59644fab6060c006dd2305795
Author: Silvan Jegen <s.jegen@gmail.com>
Date:   Thu Mar 17 17:15:01 2016 -0700

    Input: xpad - add Mad Catz FightStick TE 2 VID/PID

    [ Upstream commit d63b0f0c0f19dc8687387ead5a28148dcad1a4b9 ]

    This adds the VID/PID combination for the Xbox One version of the Mad
    Catz FightStick TE 2.

    The functionality that this provides is about on par with what the
    Windows drivers for the stick manage to deliver.

    What works:
    - Digital stick
    - 6 main buttons
    - Xbox button
    - The two buttons on the back
    - The locking buttons (preventing accidental Xbox button press)

    What doesn't work:
    - Two of the main buttons (don't work on Windows either)
    - The "Haptic" button setting does not have an effect (not sure if it
      works on Windows)

    I added the MAP_TRIGGERS_TO_BUTTONS option but in my (limited) testing
    there was no practical difference with or without. The FightStick does
    not have triggers though so adding it makes sense.

    Signed-off-by: Silvan Jegen <s.jegen@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 98232ecdabace3736ec622af92058d0ebb64bb54
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 27 15:42:25 2016 -0800

    Input: xpad - remove unused function

    [ Upstream commit a6ed4a18ba6a6f5a01e024b9d221d6439bf6ca4c ]

    There are two definitions of xpad_identify_controller(), one is used
    when CONFIG_JOYSTICK_XPAD_LEDS is set, but the other one is empty
    and never used, and we get a gcc warning about it:

    drivers/input/joystick/xpad.c:1210:13: warning: 'xpad_identify_controller' defined but not used [-Wunused-function]

    This removes the second definition.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: cae705baa40b ("Input: xpad - re-send LED command on present event")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1a4c2bc9e4092181919126dd18aa60c779b9671f
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Tue Jan 12 14:35:51 2016 -0800

    Input: xpad - correct xbox one pad device name

    [ Upstream commit 95162dc8493ed92e5f7dcc8874e58c2ba3836b43 ]

    Apparently the Covert Forces ID is not Covert Forces pad exclusive, but
    rather denotes a new firmware version that can be found on all new
    controllers and can be also updated on old hardware using Windows 10.

    see: https://github.com/paroj/xpad/issues/19

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 686e17db0512c6d9f3c5106dac59ad638a51e981
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Dec 16 14:24:58 2015 -0800

    Input: xpad - use LED API when identifying wireless controllers

    [ Upstream commit d9be398afb2c3333716324352d062c50112e4e86 ]

    When lighting up the segment identifying wireless controller, Instead of
    sending command directly to the controller, let's do it via LED API (usinf
    led_set_brightness) so that LED object state is in sync with controller
    state and we'll light up the correct segment on resume as well.

    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit cbf5ece0fad9789d59e51dddbc21d9b2abd95795
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Wed Dec 9 13:30:34 2015 -0800

    Input: xpad - workaround dead irq_out after suspend/ resume

    [ Upstream commit 4220f7db1e424f2a086ad41217b5770cc9f003a9 ]

    The irq_out urb is dead after suspend/ resume on my x360 wr pad. (also
    reproduced by Zachary Lund [0]) Work around this by implementing
    suspend, resume, and reset_resume callbacks and properly shutting down
    URBs on suspend and restarting them on resume.

    [0]: https://github.com/paroj/xpad/issues/6

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9c46ae68a03c33e5b46e8f2aa6e7d61a2dc4cf54
Author: Pierre-Loup A. Griffais <githubpublic@plagman.net>
Date:   Wed Dec 9 13:40:37 2015 -0800

    Input: xpad - update Xbox One Force Feedback Support

    [ Upstream commit 2a6d7527b35cf987260800807e328d167aef22ac ]

    There's apparently a serial number woven into both input and output
    packets; neglecting to specify a valid serial number causes the controller
    to ignore the rumble packets.

    The scale of the rumble was also apparently halved in the packets.

    The initialization packet had to be changed to allow force feedback to
    work.

    see https://github.com/paroj/xpad/issues/7 for details.

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 718428c464767eb28951e5265698ab779d830220
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Wed Dec 9 11:57:01 2015 -0800

    Input: xpad - correctly handle concurrent LED and FF requests

    [ Upstream commit 7fc595f4c02636eadaeeecfe7bbc45b57c173004 ]

    Track the status of the irq_out URB to prevent submission iof new requests
    while current one is active. Failure to do so results in the "URB submitted
    while active" warning/stack trace.

    Store pending brightness and FF effect in the driver structure and replace
    it with the latest requests until the device is ready to process next
    request. Alternate serving LED vs FF requests to make sure one does not
    starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer
    [2].

    [1]: http://www.spinics.net/lists/linux-input/msg40708.html
    [2]: http://www.spinics.net/lists/linux-input/msg31450.html

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 521855f27a891e5c4cff423341f31bdfa5e10e85
Author: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
Date:   Wed Dec 9 11:46:25 2015 -0800

    Input: xpad - handle "present" and "gone" correctly

    [ Upstream commit 09c8b00ae3e16c8d0fd4beb2ca064502a76c0f17 ]

    Handle the "a new device is present" message properly by dynamically
    creating the input device at this point in time. This means we now do not
    "preallocate" all 4 devices when a single wireless base station is seen.
    This requires a workqueue as we are in interrupt context when we learn
    about this.

    Also properly disconnect any devices that we are told are removed.

    Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit ed2cb8c96e48d8ebfd899ea58eb060f096dd6610
Author: Clement Calmels <clement.calmels@free.fr>
Date:   Sat Dec 12 21:20:11 2015 -0800

    Input: xpad - remove spurious events of wireless xpad 360 controller

    [ Upstream commit 93a017aa2f77291752e637bfd83f2459dba714cb ]

    When powering up a wireless xbox 360 controller, some wrong joystick
    events are generated. It is annoying because, for example, it makes
    unwanted moves in Steam big picture mode's menu.

    When my controller is powering up, this packet is received by the
    driver:
    00000000: 00 0f 00 f0 00 cc ff cf 8b e0 86 6a 68 f0 00 20  ...........jh..
    00000010: 13 e3 20 1d 30 03 40 01 50 01 ff ff              .. .0.@.P...

    According to xboxdrv userspace driver source code, this packet is only
    dumping a serial id and should not be interpreted as joystick events.
    This issue can be easily seen with jstest:
    $ jstest --event /dev/input/js0

    This patch only adds a way to filter out this "serial" packet and as a
    result it removes the spurous events.

    Signed-off-by: Clement Calmels <clement.calmels@free.fr>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e28f5effbc06a220072a6d19a3a4c372daa88794
Author: Greg Hackmann <ghackmann@android.com>
Date:   Tue Nov 27 11:15:20 2018 -0800

    arm64: remove no-op -p linker flag

    (commit 1a381d4a0a9a0f999a13faaba22bf6b3fc80dcb9 upstream)

    Linking the ARM64 defconfig kernel with LLVM lld fails with the error:

      ld.lld: error: unknown argument: -p
      Makefile:1015: recipe for target 'vmlinux' failed

    Without this flag, the ARM64 defconfig kernel successfully links with
    lld and boots on Dragonboard 410c.

    After digging through binutils source and changelogs, it turns out that
    -p is only relevant to ancient binutils installations targeting 32-bit
    ARM.  binutils accepts -p for AArch64 too, but it's always been
    undocumented and silently ignored.  A comment in
    ld/emultempl/aarch64elf.em explains that it's "Only here for backwards
    compatibility".

    Since this flag is a no-op on ARM64, we can safely drop it.

    Acked-by: Will Deacon <will.deacon@arm.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Hackmann <ghackmann@google.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit dd0f30f6b78e4810da7a7bb2af4c9e5b2cffb22c
Author: Yufen Yu <yuyufen@huawei.com>
Date:   Fri Nov 16 15:08:39 2018 -0800

    tmpfs: make lseek(SEEK_DATA/SEK_HOLE) return ENXIO with a negative offset

    [ Upstream commit 1a413646931cb14442065cfc17561e50f5b5bb44 ]

    Other filesystems such as ext4, f2fs and ubifs all return ENXIO when
    lseek (SEEK_DATA or SEEK_HOLE) requests a negative offset.

    man 2 lseek says

    :      EINVAL whence  is  not  valid.   Or: the resulting file offset would be
    :             negative, or beyond the end of a seekable device.
    :
    :      ENXIO  whence is SEEK_DATA or SEEK_HOLE, and the file offset is  beyond
    :             the end of the file.

    Make tmpfs return ENXIO under these circumstances as well.  After this,
    tmpfs also passes xfstests's generic/448.

    [akpm@linux-foundation.org: rewrite changelog]
    Link: http://lkml.kernel.org/r/1540434176-14349-1-git-send-email-yuyufen@huawei.com
    Signed-off-by: Yufen Yu <yuyufen@huawei.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 077359e1c7aa9d8c060dc5664ed32d9526be19d7
Author: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Date:   Thu Nov 8 10:47:56 2018 +0530

    powerpc/numa: Suppress "VPHN is not supported" messages

    [ Upstream commit 437ccdc8ce629470babdda1a7086e2f477048cbd ]

    When VPHN function is not supported and during cpu hotplug event,
    kernel prints message 'VPHN function not supported. Disabling
    polling...'. Currently it prints on every hotplug event, it floods
    dmesg when a KVM guest tries to hotplug huge number of vcpus, let's
    just print once and suppress further kernel prints.

    Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d635d44ec07b13e094eabac6a122c4aeddfead03
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Thu Sep 20 08:59:14 2018 -0400

    kdb: Use strscpy with destination buffer size

    [ Upstream commit c2b94c72d93d0929f48157eef128c4f9d2e603ce ]

    gcc 8.1.0 warns with:

    kernel/debug/kdb/kdb_support.c: In function ‘kallsyms_symbol_next’:
    kernel/debug/kdb/kdb_support.c:239:4: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
         strncpy(prefix_name, name, strlen(name)+1);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    kernel/debug/kdb/kdb_support.c:239:31: note: length computed here

    Use strscpy() with the destination buffer size, and use ellipses when
    displaying truncated symbols.

    v2: Use strscpy()

    Change-Id: Ie2ea7c43fec7acc88291e95689a9067faeb4207e
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Cc: Jonathan Toppins <jtoppins@redhat.com>
    Cc: Jason Wessel <jason.wessel@windriver.com>
    Cc: Daniel Thompson <daniel.thompson@linaro.org>
    Cc: kgdb-bugreport@lists.sourceforge.net
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f3f84ce028b833168d9f15141bc1f90612d76319
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Nov 12 16:06:51 2018 -0500

    SUNRPC: Fix a bogus get/put in generic_key_to_expire()

    [ Upstream commit e3d5e573a54dabdc0f9f3cb039d799323372b251 ]

    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1005de7e0a8f03096109bc29fa39b21333b4acf4
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Thu Jul 19 11:42:36 2018 +0100

    ARM: make lookup_processor_type() non-__init

    [ Upstream commit 899a42f836678a595f7d2bc36a5a0c2b03d08cbc ]

    Move lookup_processor_type() out of the __init section so it is callable
    from (eg) the secondary startup code during hotplug.

    Reviewed-by: Julien Thierry <julien.thierry@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit be2bcc4e7613b705621657a8f5b3c9b8ce67e9e8
Author: Anson Huang <anson.huang@nxp.com>
Date:   Mon Nov 5 00:59:28 2018 +0000

    cpufreq: imx6q: add return value check for voltage scale

    [ Upstream commit 6ef28a04d1ccf718eee069b72132ce4aa1e52ab9 ]

    Add return value check for voltage scale when ARM clock
    rate change fail.

    Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 0682307f4d6a2728aabdb0de86d2d1dfa9571b12
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 14:15:13 2018 +0100

    can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb

    commit 7da11ba5c5066dadc2e96835a6233d56d7b7764a upstream.

    Prior to echoing a successfully transmitted CAN frame (by calling
    can_get_echo_skb()), CAN drivers have to put the CAN frame (by calling
    can_put_echo_skb() in the transmit function). These put and get function
    take an index as parameter, which is used to identify the CAN frame.

    A driver calling can_get_echo_skb() with a index not pointing to a skb
    is a BUG, so add an appropriate error message.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit eabcdcea7413feb1a20006e4ac9a51ead83b2512
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 14:05:26 2018 +0100

    can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb is accessed out of bounds

    commit e7a6994d043a1e31d5b17706a22ce33d2a3e4cdc upstream.

    If the "struct can_priv::echo_skb" is accessed out of bounds would lead
    to a kernel crash. Better print a sensible warning message instead and
    try to recover.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 0a94a66631d897ece3269120a9d6db8e722f09a0
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 11:08:21 2018 +0100

    can: dev: __can_get_echo_skb(): replace struct can_frame by canfd_frame to access frame length

    commit 200f5c49f7a2cd694436bfc6cb0662b794c96736 upstream.

    This patch replaces the use of "struct can_frame::can_dlc" by "struct
    canfd_frame::len" to access the frame's length. As it is ensured that
    both structures have a compatible memory layout for this member this is
    no functional change. Futher, this compatibility is documented in a
    comment.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 003bc538cb7189efc32e2edbfa21696d142921af
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 10:37:46 2018 +0100

    can: dev: can_get_echo_skb(): factor out non sending code to __can_get_echo_skb()

    commit a4310fa2f24687888ce80fdb0e88583561a23700 upstream.

    This patch factors out all non sending parts of can_get_echo_skb() into
    a seperate function __can_get_echo_skb(), so that it can be re-used in
    an upcoming patch.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit b06021a26ed1a5f3c4dfbcd10c708cf5aa3f4930
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Wed Oct 3 14:57:47 2018 +0800

    drm/ast: change resolution may cause screen blurred

    commit 1a37bd823891568f8721989aed0615835632d81a upstream.

    The value of pitches is not correct while calling mode_set.
    The issue we found so far on following system:
    - Debian8 with XFCE Desktop
    - Ubuntu with KDE Desktop
    - SUSE15 with KDE Desktop

    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Cc: <stable@vger.kernel.org>
    Tested-by: Jean Delvare <jdelvare@suse.de>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 8b53725600bdeb001448f16fbf14592996d84dfa
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Tue Oct 30 11:34:46 2018 +0800

    drm/ast: fixed cursor may disappear sometimes

    commit 7989b9ee8bafe5cc625381dd0c3c4586de27ca26 upstream.

    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit c0c8c416a8c830507d02f18463bccd92b6e572f4
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Oct 22 09:24:27 2018 -0700

    llc: do not use sk_eat_skb()

    commit 604d415e2bd642b7e02c80e719e0396b9d4a77a6 upstream.

    syzkaller triggered a use-after-free [1], caused by a combination of
    skb_get() in llc_conn_state_process() and usage of sk_eat_skb()

    sk_eat_skb() is assuming the skb about to be freed is only used by
    the current thread. TCP/DCCP stacks enforce this because current
    thread holds the socket lock.

    llc_conn_state_process() wants to make sure skb does not disappear,
    and holds a reference on the skb it manipulates. But as soon as this
    skb is added to socket receive queue, another thread can consume it.

    This means that llc must use regular skb_unlink() and kfree_skb()
    so that both producer and consumer can safely work on the same skb.

    [1]
    BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
    BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:43 [inline]
    BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:967 [inline]
    BUG: KASAN: use-after-free in kfree_skb+0xb7/0x580 net/core/skbuff.c:655
    Read of size 4 at addr ffff8801d1f6fba4 by task ksoftirqd/1/18

    CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0-rc8+ #295
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
     print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
     kasan_report_error mm/kasan/report.c:354 [inline]
     kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
     check_memory_region_inline mm/kasan/kasan.c:260 [inline]
     check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
     kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
     atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
     refcount_read include/linux/refcount.h:43 [inline]
     skb_unref include/linux/skbuff.h:967 [inline]
     kfree_skb+0xb7/0x580 net/core/skbuff.c:655
     llc_sap_state_process+0x9b/0x550 net/llc/llc_sap.c:224
     llc_sap_rcv+0x156/0x1f0 net/llc/llc_sap.c:297
     llc_sap_handler+0x65e/0xf80 net/llc/llc_sap.c:438
     llc_rcv+0x79e/0xe20 net/llc/llc_input.c:208
     __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
     __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
     process_backlog+0x218/0x6f0 net/core/dev.c:5829
     napi_poll net/core/dev.c:6249 [inline]
     net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
     __do_softirq+0x30c/0xb03 kernel/softirq.c:292
     run_ksoftirqd+0x94/0x100 kernel/softirq.c:653
     smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
     kthread+0x35a/0x420 kernel/kthread.c:246
     ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413

    Allocated by task 18:
     save_stack+0x43/0xd0 mm/kasan/kasan.c:448
     set_track mm/kasan/kasan.c:460 [inline]
     kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
     kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
     kmem_cache_alloc_node+0x144/0x730 mm/slab.c:3644
     __alloc_skb+0x119/0x770 net/core/skbuff.c:193
     alloc_skb include/linux/skbuff.h:995 [inline]
     llc_alloc_frame+0xbc/0x370 net/llc/llc_sap.c:54
     llc_station_ac_send_xid_r net/llc/llc_station.c:52 [inline]
     llc_station_rcv+0x1dc/0x1420 net/llc/llc_station.c:111
     llc_rcv+0xc32/0xe20 net/llc/llc_input.c:220
     __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
     __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
     process_backlog+0x218/0x6f0 net/core/dev.c:5829
     napi_poll net/core/dev.c:6249 [inline]
     net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
     __do_softirq+0x30c/0xb03 kernel/softirq.c:292

    Freed by task 16383:
     save_stack+0x43/0xd0 mm/kasan/kasan.c:448
     set_track mm/kasan/kasan.c:460 [inline]
     __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
     kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
     __cache_free mm/slab.c:3498 [inline]
     kmem_cache_free+0x83/0x290 mm/slab.c:3756
     kfree_skbmem+0x154/0x230 net/core/skbuff.c:582
     __kfree_skb+0x1d/0x20 net/core/skbuff.c:642
     sk_eat_skb include/net/sock.h:2366 [inline]
     llc_ui_recvmsg+0xec2/0x1610 net/llc/af_llc.c:882
     sock_recvmsg_nosec net/socket.c:794 [inline]
     sock_recvmsg+0xd0/0x110 net/socket.c:801
     ___sys_recvmsg+0x2b6/0x680 net/socket.c:2278
     __sys_recvmmsg+0x303/0xb90 net/socket.c:2390
     do_sys_recvmmsg+0x181/0x1a0 net/socket.c:2466
     __do_sys_recvmmsg net/socket.c:2484 [inline]
     __se_sys_recvmmsg net/socket.c:2480 [inline]
     __x64_sys_recvmmsg+0xbe/0x150 net/socket.c:2480
     do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe

    The buggy address belongs to the object at ffff8801d1f6fac0
     which belongs to the cache skbuff_head_cache of size 232
    The buggy address is located 228 bytes inside of
     232-byte region [ffff8801d1f6fac0, ffff8801d1f6fba8)
    The buggy address belongs to the page:
    page:ffffea000747dbc0 count:1 mapcount:0 mapping:ffff8801d9be7680 index:0xffff8801d1f6fe80
    flags: 0x2fffc0000000100(slab)
    raw: 02fffc0000000100 ffffea0007346e88 ffffea000705b108 ffff8801d9be7680
    raw: ffff8801d1f6fe80 ffff8801d1f6f0c0 000000010000000b 0000000000000000
    page dumped because: kasan: bad access detected

    Memory state around the buggy address:
     ffff8801d1f6fa80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
     ffff8801d1f6fb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff8801d1f6fb80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
                                   ^
     ffff8801d1f6fc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8801d1f6fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 6512aeaf1997f13fcbe02862aee5476a864704c9
Author: Andrew Price <anprice@redhat.com>
Date:   Mon Oct 8 07:52:43 2018 -0500

    gfs2: Don't leave s_fs_info pointing to freed memory in init_sbd

    commit 4c62bd9cea7bcf10292f7e4c57a2bca332942697 upstream.

    When alloc_percpu() fails, sdp gets freed but sb->s_fs_info still points
    to the same address. Move the assignment after that error check so that
    s_fs_info can only point to a valid sdp or NULL, which is checked for
    later in the error path, in gfs2_kill_super().

    Reported-by: syzbot+dcb8b3587445007f5808@syzkaller.appspotmail.com
    Signed-off-by: Andrew Price <anprice@redhat.com>
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 377052c7115933f96c5bfbd49eedd163c28c8022
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Oct 29 23:10:29 2018 +0800

    sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer

    commit df132eff463873e14e019a07f387b4d577d6d1f9 upstream.

    If a transport is removed by asconf but there still are some chunks with
    this transport queuing on out_chunk_list, later an use-after-free issue
    will be caused when accessing this transport from these chunks in
    sctp_outq_flush().

    This is an old bug, we fix it by clearing the transport of these chunks
    in out_chunk_list when removing a transport in sctp_assoc_rm_peer().

    Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e8b986b8b57add839a8d149860051e99c296ec06
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri Nov 2 15:48:42 2018 -0700

    bfs: add sanity check at bfs_fill_super()

    commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e upstream.

    syzbot is reporting too large memory allocation at bfs_fill_super() [1].
    Since file system image is corrupted such that bfs_sb->s_start == 0,
    bfs_fill_super() is trying to allocate 8MB o…

mydongistiny added a commit to BenzoRom/kernel_google_marlin that referenced this issue Dec 1, 2018

Linux: 3.18.128-rc1
commit 1db527abf726d5f4cc45698654cc9761b566725c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Nov 29 15:01:36 2018 +0100

    Linux 3.18.128-rc1

    Change-Id: I0e65f1781d8bbc6e2cb456544f4aee6eeac73491
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 6062d7ff33eaaaecc150bef8f6fb3e1aedc83ffd
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Thu Nov 15 11:42:16 2018 +0100

    drm/ast: Remove existing framebuffers before loading driver

    commit 5478ad10e7850ce3d8b7056db05ddfa3c9ddad9a upstream.

    If vesafb attaches to the AST device, it configures the framebuffer memory
    for uncached access by default. When ast.ko later tries to attach itself to
    the device, it wants to use write-combining on the framebuffer memory, but
    vesefb's existing configuration for uncached access takes precedence. This
    results in reduced performance.

    Removing the framebuffer's configuration before loding the AST driver fixes
    the problem. Other DRM drivers already contain equivalent code.

    Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: <stable@vger.kernel.org>
    Tested-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Tested-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9c8d3cea52fa9bc96b56aadd94d21c312589741b
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Mon Jan 23 11:17:35 2017 -0800

    af_unix: move unix_mknod() out of bindlock

    commit 0fb44559ffd67de8517098b81f675fa0210f13f0 upstream.

    Dmitry reported a deadlock scenario:

    unix_bind() path:
    u->bindlock ==> sb_writer

    do_splice() path:
    sb_writer ==> pipe->mutex ==> u->bindlock

    In the unix_bind() code path, unix_mknod() does not have to
    be done with u->bindlock held, since it is a pure fs operation,
    so we can just move unix_mknod() out.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Petr Vorel <pvorel@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 4622d0fdeecf63728b7013f96de89ca161ec5068
Author: Greg Kroah-Hartman <greg@kroah.com>
Date:   Thu Oct 4 11:06:14 2018 -0700

    tty: wipe buffer if not echoing data

    commit b97b3d9fb57860a60592859e332de7759fd54c2e upstream.

    If we are not echoing the data to userspace or the console is in icanon
    mode, then perhaps it is a "secret" so we should wipe it once we are
    done with it.

    This mirrors the logic that the audit code has.

    Reported-by: aszlig <aszlig@nix.build>
    Tested-by: Milan Broz <gmazyland@gmail.com>
    Tested-by: Daniel Zatovic <daniel.zatovic@gmail.com>
    Tested-by: aszlig <aszlig@nix.build>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Change-Id: I29075af365fe48bb1a6afebd7ba964564c66d3be
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 21a512825d32ecc0871b95396b8e981483d6bbe5
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Oct 4 11:06:13 2018 -0700

    tty: wipe buffer.

    commit c9a8e5fce009e3c601a43c49ea9dbcb25d1ffac5 upstream.

    After we are done with the tty buffer, zero it out.

    Reported-by: aszlig <aszlig@nix.build>
    Tested-by: Milan Broz <gmazyland@gmail.com>
    Tested-by: Daniel Zatovic <daniel.zatovic@gmail.com>
    Tested-by: aszlig <aszlig@nix.build>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 2d4893fbdcd04575726dcab6d9e876a0a0417ba1
Author: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Date:   Mon Nov 7 17:53:30 2016 -0200

    scsi: qla2xxx: do not queue commands when unloading

    commit 04dfaa53a0b6e66b328a5bc549e3af8f8b6eac02 upstream.

    When the driver is unloading, in qla2x00_remove_one(), there is a single
    call/point in time to abort ongoing commands, qla2x00_abort_all_cmds(),
    which is still several steps away from the call to scsi_remove_host().

    If more commands continue to arrive and be processed during that
    interval, when the driver is tearing down and releasing its structures,
    it might potentially hit an oops due to invalid memory access:

        Unable to handle kernel paging request for data at address 0x00000138
        <...>
        NIP [d000000004700a40] qla2xxx_queuecommand+0x80/0x3f0 [qla2xxx]
        LR [d000000004700a10] qla2xxx_queuecommand+0x50/0x3f0 [qla2xxx]

    So, fail commands in qla2xxx_queuecommand() if the UNLOADING bit is set.

    Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
    Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 837fd1cdc8110ada3b2a76995bdc4f7b4304e2fb
Author: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Date:   Mon Oct 17 17:10:53 2016 -0700

    scsi: ufshcd: Fix race between clk scaling and ungate work

    commit f2a785ac23125fa0774327d39e837e45cf28fe92 upstream.

    The ungate work turns on the clock before it exits hibern8, if the link
    was put in hibern8 during clock gating work.  There occurs a race
    condition when clock scaling work calls ufshcd_hold() to make sure low
    power states cannot be entered, but that returns by checking only
    whether the clocks are on.  This causes the clock scaling work to issue
    UIC commands when the link is in hibern8 causing failures. Make sure we
    exit hibern8 state before returning from ufshcd_hold().

    Callstacks for race condition:

     ufshcd_scale_gear
     ufshcd_devfreq_scale
     ufshcd_devfreq_target
     update_devfreq
     devfreq_monitor
     process_one_work
     worker_thread
     kthread
     ret_from_fork

     ufshcd_uic_hibern8_exit
     ufshcd_ungate_work
     process_one_work
     worker_thread
     kthread
     ret_from_fork

    Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
    Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 3868c24b13584fc43829ed6fb6b50d67b24e901d
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date:   Fri Sep 30 14:39:17 2016 +0200

    cw1200: Don't leak memory if krealloc failes

    commit 9afdd6128c39f42398041bb2e017d8df0dcebcd1 upstream.

    The call to krealloc() in wsm_buf_reserve() directly assigns the newly
    returned memory to buf->begin. This is all fine except when krealloc()
    failes we loose the ability to free the old memory pointed to by
    buf->begin. If we just create a temporary variable to assign memory to
    and assign the memory to it we can mitigate the memory leak.

    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit b6123f76c15bce57c776ba519b8adcc94e8fd7f8
Author: Ramses Ramírez <ramzeto@gmail.com>
Date:   Fri Sep 28 16:59:26 2018 -0700

    Input: xpad - add support for Xbox1 PDP Camo series gamepad

    [ Upstream commit 9735082a7cbae572c2eabdc45acecc8c9fa0759b ]

    The "Xbox One PDP Wired Controller - Camo series" has a different
    product-id than the regular PDP controller and the PDP stealth series,
    but it uses the same initialization sequence. This patch adds the
    product-id of the camo series to the structures that handle the other
    PDP Xbox One controllers.

    Signed-off-by: Ramses Ramírez <ramzeto@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e268b3b310a8161275a2517b335fa7d5ef49fc9d
Author: Enno Boland <gottox@voidlinux.eu>
Date:   Tue Jun 19 11:55:33 2018 -0700

    Input: xpad - fix GPD Win 2 controller name

    [ Upstream commit dd6bee81c942c0ea01030da9356026afb88f9d18 ]

    This fixes using the controller with SDL2.

    SDL2 has a naive algorithm to apply the correct settings to a controller.
    For X-Box compatible controllers it expects that the controller name
    contains a variation of a 'XBOX'-string.

    This patch changes the identifier to contain "X-Box" as substring.  Tested
    with Steam and C-Dogs-SDL which both detect the controller properly after
    adding this patch.

    Fixes: c1ba08390a8b ("Input: xpad - add GPD Win 2 Controller USB IDs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Enno Boland <gottox@voidlinux.eu>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1874062f89632e15a22f0b849b843ec132f881f1
Author: Ethan Lee <flibitijibibo@gmail.com>
Date:   Fri Jun 1 11:46:08 2018 -0700

    Input: xpad - add GPD Win 2 Controller USB IDs

    [ Upstream commit c1ba08390a8bb13c927e699330896adc15b78205 ]

    GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp

    Tested on a unit from the first production run sent to Indiegogo backers

    Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 0034247db3340ad95703980b625c2456098d4ace
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Tue May 8 15:17:07 2018 -0700

    Input: xpad - avoid using __set_bit() for capabilities

    [ Upstream commit a01308031c2647ed5f1c845104b73a8820a958a9 ]

    input_set_capability() and input_set_abs_param() will do it for you.

    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 8d569063a324c9c7de642c0051d0f21177193ea9
Author: Leo Sperling <leosperling97@gmail.com>
Date:   Wed Aug 3 17:31:09 2016 -0700

    Input: xpad - fix some coding style issues

    [ Upstream commit 68c78d0155e37992268664e134996d2b140ddf38 ]

    Fix some coding style issues reported by checkpatch.pl. Mostly brackets
    in macros, spacing and comment style.

    Signed-off-by: Leo Sperling <leosperling97@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 8d34e98fb5bae8632a838d396043209acf587d76
Author: Francis Therien <frtherien@gmail.com>
Date:   Mon Mar 26 15:59:00 2018 -0700

    Input: xpad - add PDP device id 0x02a4

    [ Upstream commit c6c848572f4da0e34ffe0a35364b4db871e13e42 ]

    Adds support for a PDP Xbox One controller with device ID
    (0x06ef:0x02a4). The Product string for this device is "PDP Wired
    Controller for Xbox One - Stealth Series | Phantom Black".

    Signed-off-by: Francis Therien <frtherien@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit c621992d7b0571b34b241db848efd7b710706f6a
Author: Mark Furneaux <mark@furneaux.ca>
Date:   Mon Jan 22 11:24:17 2018 -0800

    Input: xpad - add support for PDP Xbox One controllers

    [ Upstream commit e5c9c6a885fad00aa559b49d8fc23a60e290824e ]

    Adds support for the current lineup of Xbox One controllers from PDP
    (Performance Designed Products). These controllers are very picky with
    their initialization sequence and require an additional 2 packets before
    they send any input reports.

    Signed-off-by: Mark Furneaux <mark@furneaux.ca>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e9957b6304bf96ebce65701aa3ed0255bffe9a4e
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Tue Sep 12 11:27:44 2017 -0700

    Input: xpad - validate USB endpoint type during probe

    [ Upstream commit 122d6a347329818419b032c5a1776e6b3866d9b9 ]

    We should only see devices with interrupt endpoints. Ignore any other
    endpoints that we find, so we don't send try to send them interrupt URBs
    and trigger a WARN down in the USB stack.

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: <stable@vger.kernel.org> # c01b5e7464f0 Input: xpad - don't depend on endpoint order
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 2adf59a5bc2af42e7e6f9fde2fb488cc3061490f
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Thu Aug 31 11:52:20 2017 -0700

    Input: xpad - fix PowerA init quirk for some gamepad models

    [ Upstream commit f5308d1b83eba20e69df5e0926ba7257c8dd9074 ]

    The PowerA gamepad initialization quirk worked with the PowerA
    wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
    that it didn't work for him, even though our gamepads shared the
    same vendor and product IDs.

    When I initially implemented the PowerA quirk, I wanted to avoid
    actually triggering the rumble action during init. My tests showed
    that my gamepad would work correctly even if it received a rumble
    of 0 intensity, so that's what I went with.

    Unfortunately, this apparently isn't true for all models (perhaps
    a firmware difference?). This non-working gamepad seems to require
    the real magic rumble packet that the Microsoft driver sends, which
    actually vibrates the gamepad. To counteract this effect, I still
    send the old zero-rumble PowerA quirk packet which cancels the
    rumble effect before the motors can spin up enough to vibrate.

    [0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867

    Reported-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
    Tested-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
    Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads")
    Cc: stable@vger.kernel.org # v4.12
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 5573f0cb36016e15e45d20b521b40480170ac98a
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Mon Aug 7 20:04:13 2017 -0700

    Input: xpad - constify usb_device_id

    [ Upstream commit 94aef061c796d3d47f1a2eed41e651ffaaade402 ]

    usb_device_id are not supposed to change at runtime. All functions
    working with usb_device_id provided by <linux/usb.h> work with
    const usb_device_id. So mark the non-const structs as const.

    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d7fd20d19c61a8085ac4ce8011345062f9bbfc16
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun Jun 18 15:41:20 2017 -0700

    Input: xpad - sync supported devices with XBCD

    [ Upstream commit be19788c73d382f66dd3fba3c5ccef59cf12a126 ]

    XBCD [0][1] is an OpenSource driver for Xbox controllers on Windows.
    Later it also started supporting Xbox360 controllers (presumably before
    the official Windows driver was released).

    It contains a couple device IDs unknown to the Linux driver, so I extracted
    those from xbcd.inf and added them to our list.

    It has a special type for Wheels and I have the feeling they might need
    some extra handling. They all have 'Wheel' in their name, so that
    information is available for future improvements.

    [0] https://www.s-config.com/xbcd-original-xbox-controllers-win10/
    [1] http://www.redcl0ud.com/xbcd.html

    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 73eff63b2d49a72f79912bb5208d6fb6e7feec4e
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun Jun 18 15:40:37 2017 -0700

    Input: xpad - sync supported devices with 360Controller

    [ Upstream commit c225370e01b87d3c4ef40d98295ac0bb1e5a3116 ]

    360Controller [0] is an OpenSource driver for Xbox/Xbox360/XboxOne
    controllers on macOS.

    It contains a couple device IDs unknown to the Linux driver, so I wrote a
    small Python script [1] to extract them and feed them into my previous
    script [2] to compare them with the IDs known to Linux.

    For most devices, this information is not really needed as xpad is able to
    automatically detect the type of an unknown Xbox Controller at run-time.
    I've therefore stripped all the generic/vague entries.

    I've excluded the Logitech G920, it's handled by a HID driver already.
    I've also excluded the Scene It! Big Button IR, it's handled by an
    out-of-tree driver. [3]

    [0] https://github.com/360Controller/360Controller
    [1] http://codepad.org/v9GyLKMq
    [2] http://codepad.org/qh7jclpD
    [3] https://github.com/micolous/xbox360bb

    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 18dfc9d2ef06407b7588ef597867430c6f206b91
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun May 7 14:49:09 2017 -0700

    Input: xpad - add USB IDs for Mad Catz Brawlstick and Razer Sabertooth

    [ Upstream commit 4706aa075662fe3cad29c3f49b50878de53f4f3b ]

    Add USB IDs for two more Xbox 360 controllers.

    I found them in the pull requests for the xboxdrv userspace driver, which
    seems abandoned.

    Thanks to psychogony and mkaito for reporting the IDs there!

    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d20d73dab83588fe3652c6bdb9bd064e1bcdfae8
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun May 7 14:48:14 2017 -0700

    Input: xpad - sync supported devices with xboxdrv

    [ Upstream commit 44bc722593201da43862b7200ee0b98155410b07 ]

    The userspace xboxdrv driver [0] contains some USB IDs unknown to the
    kernel driver. I have created a simple script [1] to extract the missing
    devices and add them to xpad.

    A quick google search confirmed that all the new devices called
    Fightstick/pad are Arcade-type devices [2] where the
    MAP_TRIGGERS_TO_BUTTONS option should apply.

    There are some similar devices in the existing device table where this
    flag is not set, but I did refrain from changing those.

    [0] https://github.com/xboxdrv/xboxdrv/blob/stable/src/xpad_device.cpp
    [1] http://codepad.org/CHV98BNH
    [2] https://www.google.com/search?q=SFxT+Fightstick+Pro&tbm=isch

    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 35e63f4f00700f4f039d1f68752a6e1959ab3fed
Author: Benjamin Valentin <benpicco@googlemail.com>
Date:   Sun May 7 14:45:08 2017 -0700

    Input: xpad - sort supported devices by USB ID

    [ Upstream commit 873cb582738fde338ecaeaca594560cde2ba42c3 ]

    Some entries in the table of supported devices are out of order.
    To not create a mess when adding new ones using a script, sort them first.

    Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
    Reviewed-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1a60b4b313ee218d9e78d3f98bf4c4c2bba66d6d
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Mon Apr 10 20:43:04 2017 -0700

    Input: xpad - support some quirky Xbox One pads

    [ Upstream commit 81093c9848a781b85163d06de92ef8f84528cf6a ]

    There are several quirky Xbox One pads that depend on initialization
    packets that the Microsoft pads don't require. To deal with these,
    I've added a mechanism for issuing device-specific initialization
    packets using a VID/PID-based quirks list.

    For the initial set of init quirks, I have added quirk handling from
    Valve's Steam Link xpad driver[0] and the 360Controller project[1] for
    macOS to enable some new pads to work properly.

    This should enable full functionality on the following quirky pads:
    0x0e6f:0x0165 - Titanfall 2 gamepad (previously fully non-functional)
    0x0f0d:0x0067 - Hori Horipad (analog sticks previously non-functional)
    0x24c6:0x541a - PowerA Xbox One pad (previously fully non-functional)
    0x24c6:0x542a - PowerA Xbox One pad (previously fully non-functional)
    0x24c6:0x543a - PowerA Xbox One pad (previously fully non-functional)

    [0]: https://github.com/ValveSoftware/steamlink-sdk/blob/master/kernel/drivers/input/joystick/xpad.c
    [1]: https://github.com/360Controller/360Controller

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f403691991bfab3d456d4e2173cf0932541eaee2
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Mon Feb 6 17:03:03 2017 -0800

    Input: xpad - restore LED state after device resume

    [ Upstream commit a1fbf5bbef025b4844162b3b8868888003a7ee9c ]

    Set the LED_CORE_SUSPENDRESUME flag on our LED device so the
    LED state will be automatically restored by LED core on resume.

    Since Xbox One pads stop flashing only when reinitialized, we'll
    send them the initialization packet so they calm down too.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 4f446c52b8d143263a169ea04f3583db63f8e235
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Mon Feb 6 13:56:10 2017 -0800

    Input: xpad - fix stuck mode button on Xbox One S pad

    [ Upstream commit 57b8443d3e5bd046a519ff714ca31c64c7f04309 ]

    The Xbox One S requires an ack to its mode button report, otherwise it
    continuously retransmits the report. This makes the mode button appear to
    be stuck down after it is pressed for the first time.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f4f604511c9a94b1357203f95399758e069323e6
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Tue Jan 3 22:40:38 2017 -0800

    Input: xpad - don't depend on endpoint order

    [ Upstream commit c01b5e7464f0cf20936d7467c7528163c4e2782d ]

    The order of endpoints is well defined on official Xbox pads, but
    we have found at least one 3rd-party pad that doesn't follow the
    standard ("Titanfall 2 Xbox One controller" 0e6f:0165).

    Fortunately, we get lucky with this specific pad because it uses
    endpoint addresses that differ only by direction. We know that
    there are other pads out where this is not true, so let's go
    ahead and fix this.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d44f236694148c05dec00f1a75d754ac4706fc57
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:26:33 2016 -0700

    Input: xpad - simplify error condition in init_output

    [ Upstream commit a8c34e27fb1ece928ec728bfe596aa6ca0b1928a ]

    Replace first goto with simple returns as we really are just returning
    one error code.

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 47fc8b0deacebf9a5f8f9fd3ebf6627793b52001
Author: Daniel Tobias <dan.g.tob@gmail.com>
Date:   Fri May 27 16:25:32 2016 -0700

    Input: xpad - move reporting xbox one home button to common function

    [ Upstream commit 4f88476c75429ba9ab71c428b4cd2f67575bc9c1 ]

    xbox one was the only device that has a *_process_buttons routine.

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit baf0442a7f323546b85f7590a23286951365368a
Author: Daniel Tobias <dan.g.tob@gmail.com>
Date:   Fri May 27 16:25:10 2016 -0700

    Input: xpad - correctly sort vendor id's

    [ Upstream commit c02fc1d9e5d9f093296e43e13ec7f35f140784bd ]

    Signed-off-by: Daniel Tobias <dan.g.tob@gmail.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e0a9326f57796cb0a7fe204c327c4c8d6857f6ca
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Tue Dec 27 11:44:51 2016 -0800

    Input: xpad - use correct product id for x360w controllers

    [ Upstream commit b6fc513da50c5dbc457a8ad6b58b046a6a68fd9d ]

    currently the controllers get the same product id as the wireless
    receiver. However the controllers actually have their own product id.

    The patch makes the driver expose the same product id as the windows
    driver.

    This improves compatibility when running applications with WINE.

    see https://github.com/paroj/xpad/issues/54

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f22ec1c5f0d4a987db4bf74c2c80c5af2bd8f8fa
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Sun Nov 27 20:37:56 2016 -0800

    Input: xpad - fix Xbox One rumble stopping after 2.5 secs

    [ Upstream commit ae3b4469dbcd3b842a9fd20940946e4d092d8731 ]

    Unlike previous Xbox pads, the Xbox One pad doesn't have "sticky" rumble
    packets. The duration is encoded into the command and expiration is handled
    by the pad firmware.

    ff-memless needs pseudo-sticky behavior for rumble effects to behave
    properly for long duration effects. We already specify the maximum rumble
    on duration in the command packets, but it's still only good for about 2.5
    seconds of rumble. This is easily reproducible running fftest's sine
    vibration test.

    It turns out there's a repeat count encoded in the rumble command. We can
    abuse that to get the pseudo-sticky behavior needed for rumble to behave as
    expected for effects with long duration.

    By my math, this change should allow a single ff_effect to rumble for 10
    minutes straight, which should be more than enough for most needs.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit bfbe5d63a18d0ce8c367fdd7822abf746f3cfe46
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Sun Nov 27 20:37:31 2016 -0800

    Input: xpad - add product ID for Xbox One S pad

    [ Upstream commit 599b8c09d974d6e4d85a8f7bc8ed7442977866a8 ]

    This is the new gamepad that ships with the Xbox One S which
    includes Bluetooth functionality.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit b18dbae0fc2ec4bfe9ba81c6f2b242b535cfecf5
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Wed Jul 27 14:24:55 2016 -0700

    Input: xpad - power off wireless 360 controllers on suspend

    [ Upstream commit f712a5a05228058f6b74635546549d4a46e117fc ]

    When the USB wireless adapter is suspended, the controllers
    lose their connection. This causes them to start flashing
    their LED rings and searching for the wireless adapter
    again, wasting the controller's battery power.

    Instead, we will tell the controllers to power down when
    we suspend. This mirrors the behavior of the controllers
    when connected to the console itself and how the official
    Xbox One wireless adapter behaves on Windows.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f87be35d750ae8d60a88356e0d9e491cc5b7f887
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Thu Jun 23 10:24:42 2016 -0700

    Input: xpad - fix oops when attaching an unknown Xbox One gamepad

    [ Upstream commit c7f1429389ec1aa25e042bb13451385fbb596f8c ]

    Xbox One controllers have multiple interfaces which all have the
    same class, subclass, and protocol. One of the these interfaces
    has only a single endpoint. When Xpad attempts to bind to this
    interface, it causes an oops when trying initialize the output URB
    by trying to access the second endpoint's descriptor.

    This situation was avoided for known Xbox One devices by checking
    the XTYPE constant associated with the VID and PID tuple. However,
    this breaks when new or previously unknown Xbox One controllers
    are attached to the system.

    This change addresses the problem by deriving the XTYPE for Xbox
    One controllers based on the interface protocol before checking
    the interface number.

    Fixes: 1a48ff81b391 ("Input: xpad - add support for Xbox One controllers")
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f8e0c9ab2eedcae4c9c892eda56b00eb63a6bef5
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Wed Jun 1 11:32:51 2016 -0700

    Input: xpad - fix rumble on Xbox One controllers with 2015 firmware

    [ Upstream commit 540c26087bfbad6ea72758b76b16ae6282a73fea ]

    Xbox One controllers that shipped with or were upgraded to the 2015
    firmware discard the current rumble packets we send. This patch changes
    the Xbox One rumble packet to a form that both the newer and older
    firmware will accept.

    It is based on changes made to support newer Xbox One controllers in
    the SteamOS brewmaster-4.1 kernel branch.

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 01c8355393a28249d83217ffd8bde6e3bfcd9f52
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:24:40 2016 -0700

    Input: xpad - xbox one elite controller support

    [ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

    added the according id and incresed XPAD_PKT_LEN to 64 as the elite
    controller sends at least 33 byte messages [1].
    Verified to be working by [2].

    [1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
    [2]: https://github.com/paroj/xpad/issues/23

    Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9b896d497204db7bffe8dbcaf960a2c39ee99a19
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:24:20 2016 -0700

    Input: xpad - add more third-party controllers

    [ Upstream commit 6538c3b2d2d220a974e47928b165ea09b9cfa6b4 ]

    Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
    Signed-off-by: Thomas Debesse <dev@illwieckz.net>
    Signed-off-by: aronschatz <aronschatz@aselabs.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 4affab94869bbe865deda288b4986c7db90614f1
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Fri May 27 16:23:50 2016 -0700

    Input: xpad - prevent spurious input from wired Xbox 360 controllers

    [ Upstream commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 ]

    After initially connecting a wired Xbox 360 controller or sending it
    a command to change LEDs, a status/response packet is interpreted as
    controller input. This causes the state of buttons represented in
    byte 2 of the controller data packet to be incorrect until the next
    valid input packet. Wireless Xbox 360 controllers are not affected.

    Writing a new value to the LED device while holding the Start button
    and running jstest is sufficient to reproduce this bug. An event will
    come through with the Start button released.

    Xboxdrv also won't attempt to read controller input from a packet
    where byte 0 is non-zero. It also checks that byte 1 is 0x14, but
    that value differs between wired and wireless controllers and this
    code is shared by both. I think just checking byte 0 is enough to
    eliminate unwanted packets.

    The following are some examples of 3-byte status packets I saw:
    01 03 02
    02 03 00
    03 03 03
    08 03 00

    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9e182eae9d257ec50806fb2c2ac650a4502113a2
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Fri May 27 16:22:25 2016 -0700

    Input: xpad - move pending clear to the correct location

    [ Upstream commit 4efc6939a83c54fb3417541be48991afd0290ba3 ]

    otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 5a2c70c201578ec59644fab6060c006dd2305795
Author: Silvan Jegen <s.jegen@gmail.com>
Date:   Thu Mar 17 17:15:01 2016 -0700

    Input: xpad - add Mad Catz FightStick TE 2 VID/PID

    [ Upstream commit d63b0f0c0f19dc8687387ead5a28148dcad1a4b9 ]

    This adds the VID/PID combination for the Xbox One version of the Mad
    Catz FightStick TE 2.

    The functionality that this provides is about on par with what the
    Windows drivers for the stick manage to deliver.

    What works:
    - Digital stick
    - 6 main buttons
    - Xbox button
    - The two buttons on the back
    - The locking buttons (preventing accidental Xbox button press)

    What doesn't work:
    - Two of the main buttons (don't work on Windows either)
    - The "Haptic" button setting does not have an effect (not sure if it
      works on Windows)

    I added the MAP_TRIGGERS_TO_BUTTONS option but in my (limited) testing
    there was no practical difference with or without. The FightStick does
    not have triggers though so adding it makes sense.

    Signed-off-by: Silvan Jegen <s.jegen@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 98232ecdabace3736ec622af92058d0ebb64bb54
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 27 15:42:25 2016 -0800

    Input: xpad - remove unused function

    [ Upstream commit a6ed4a18ba6a6f5a01e024b9d221d6439bf6ca4c ]

    There are two definitions of xpad_identify_controller(), one is used
    when CONFIG_JOYSTICK_XPAD_LEDS is set, but the other one is empty
    and never used, and we get a gcc warning about it:

    drivers/input/joystick/xpad.c:1210:13: warning: 'xpad_identify_controller' defined but not used [-Wunused-function]

    This removes the second definition.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: cae705baa40b ("Input: xpad - re-send LED command on present event")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1a4c2bc9e4092181919126dd18aa60c779b9671f
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Tue Jan 12 14:35:51 2016 -0800

    Input: xpad - correct xbox one pad device name

    [ Upstream commit 95162dc8493ed92e5f7dcc8874e58c2ba3836b43 ]

    Apparently the Covert Forces ID is not Covert Forces pad exclusive, but
    rather denotes a new firmware version that can be found on all new
    controllers and can be also updated on old hardware using Windows 10.

    see: https://github.com/paroj/xpad/issues/19

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 686e17db0512c6d9f3c5106dac59ad638a51e981
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Dec 16 14:24:58 2015 -0800

    Input: xpad - use LED API when identifying wireless controllers

    [ Upstream commit d9be398afb2c3333716324352d062c50112e4e86 ]

    When lighting up the segment identifying wireless controller, Instead of
    sending command directly to the controller, let's do it via LED API (usinf
    led_set_brightness) so that LED object state is in sync with controller
    state and we'll light up the correct segment on resume as well.

    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit cbf5ece0fad9789d59e51dddbc21d9b2abd95795
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Wed Dec 9 13:30:34 2015 -0800

    Input: xpad - workaround dead irq_out after suspend/ resume

    [ Upstream commit 4220f7db1e424f2a086ad41217b5770cc9f003a9 ]

    The irq_out urb is dead after suspend/ resume on my x360 wr pad. (also
    reproduced by Zachary Lund [0]) Work around this by implementing
    suspend, resume, and reset_resume callbacks and properly shutting down
    URBs on suspend and restarting them on resume.

    [0]: https://github.com/paroj/xpad/issues/6

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 9c46ae68a03c33e5b46e8f2aa6e7d61a2dc4cf54
Author: Pierre-Loup A. Griffais <githubpublic@plagman.net>
Date:   Wed Dec 9 13:40:37 2015 -0800

    Input: xpad - update Xbox One Force Feedback Support

    [ Upstream commit 2a6d7527b35cf987260800807e328d167aef22ac ]

    There's apparently a serial number woven into both input and output
    packets; neglecting to specify a valid serial number causes the controller
    to ignore the rumble packets.

    The scale of the rumble was also apparently halved in the packets.

    The initialization packet had to be changed to allow force feedback to
    work.

    see https://github.com/paroj/xpad/issues/7 for details.

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 718428c464767eb28951e5265698ab779d830220
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Wed Dec 9 11:57:01 2015 -0800

    Input: xpad - correctly handle concurrent LED and FF requests

    [ Upstream commit 7fc595f4c02636eadaeeecfe7bbc45b57c173004 ]

    Track the status of the irq_out URB to prevent submission iof new requests
    while current one is active. Failure to do so results in the "URB submitted
    while active" warning/stack trace.

    Store pending brightness and FF effect in the driver structure and replace
    it with the latest requests until the device is ready to process next
    request. Alternate serving LED vs FF requests to make sure one does not
    starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer
    [2].

    [1]: http://www.spinics.net/lists/linux-input/msg40708.html
    [2]: http://www.spinics.net/lists/linux-input/msg31450.html

    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 521855f27a891e5c4cff423341f31bdfa5e10e85
Author: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
Date:   Wed Dec 9 11:46:25 2015 -0800

    Input: xpad - handle "present" and "gone" correctly

    [ Upstream commit 09c8b00ae3e16c8d0fd4beb2ca064502a76c0f17 ]

    Handle the "a new device is present" message properly by dynamically
    creating the input device at this point in time. This means we now do not
    "preallocate" all 4 devices when a single wireless base station is seen.
    This requires a workqueue as we are in interrupt context when we learn
    about this.

    Also properly disconnect any devices that we are told are removed.

    Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit ed2cb8c96e48d8ebfd899ea58eb060f096dd6610
Author: Clement Calmels <clement.calmels@free.fr>
Date:   Sat Dec 12 21:20:11 2015 -0800

    Input: xpad - remove spurious events of wireless xpad 360 controller

    [ Upstream commit 93a017aa2f77291752e637bfd83f2459dba714cb ]

    When powering up a wireless xbox 360 controller, some wrong joystick
    events are generated. It is annoying because, for example, it makes
    unwanted moves in Steam big picture mode's menu.

    When my controller is powering up, this packet is received by the
    driver:
    00000000: 00 0f 00 f0 00 cc ff cf 8b e0 86 6a 68 f0 00 20  ...........jh..
    00000010: 13 e3 20 1d 30 03 40 01 50 01 ff ff              .. .0.@.P...

    According to xboxdrv userspace driver source code, this packet is only
    dumping a serial id and should not be interpreted as joystick events.
    This issue can be easily seen with jstest:
    $ jstest --event /dev/input/js0

    This patch only adds a way to filter out this "serial" packet and as a
    result it removes the spurous events.

    Signed-off-by: Clement Calmels <clement.calmels@free.fr>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e28f5effbc06a220072a6d19a3a4c372daa88794
Author: Greg Hackmann <ghackmann@android.com>
Date:   Tue Nov 27 11:15:20 2018 -0800

    arm64: remove no-op -p linker flag

    (commit 1a381d4a0a9a0f999a13faaba22bf6b3fc80dcb9 upstream)

    Linking the ARM64 defconfig kernel with LLVM lld fails with the error:

      ld.lld: error: unknown argument: -p
      Makefile:1015: recipe for target 'vmlinux' failed

    Without this flag, the ARM64 defconfig kernel successfully links with
    lld and boots on Dragonboard 410c.

    After digging through binutils source and changelogs, it turns out that
    -p is only relevant to ancient binutils installations targeting 32-bit
    ARM.  binutils accepts -p for AArch64 too, but it's always been
    undocumented and silently ignored.  A comment in
    ld/emultempl/aarch64elf.em explains that it's "Only here for backwards
    compatibility".

    Since this flag is a no-op on ARM64, we can safely drop it.

    Acked-by: Will Deacon <will.deacon@arm.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Hackmann <ghackmann@google.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit dd0f30f6b78e4810da7a7bb2af4c9e5b2cffb22c
Author: Yufen Yu <yuyufen@huawei.com>
Date:   Fri Nov 16 15:08:39 2018 -0800

    tmpfs: make lseek(SEEK_DATA/SEK_HOLE) return ENXIO with a negative offset

    [ Upstream commit 1a413646931cb14442065cfc17561e50f5b5bb44 ]

    Other filesystems such as ext4, f2fs and ubifs all return ENXIO when
    lseek (SEEK_DATA or SEEK_HOLE) requests a negative offset.

    man 2 lseek says

    :      EINVAL whence  is  not  valid.   Or: the resulting file offset would be
    :             negative, or beyond the end of a seekable device.
    :
    :      ENXIO  whence is SEEK_DATA or SEEK_HOLE, and the file offset is  beyond
    :             the end of the file.

    Make tmpfs return ENXIO under these circumstances as well.  After this,
    tmpfs also passes xfstests's generic/448.

    [akpm@linux-foundation.org: rewrite changelog]
    Link: http://lkml.kernel.org/r/1540434176-14349-1-git-send-email-yuyufen@huawei.com
    Signed-off-by: Yufen Yu <yuyufen@huawei.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 077359e1c7aa9d8c060dc5664ed32d9526be19d7
Author: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Date:   Thu Nov 8 10:47:56 2018 +0530

    powerpc/numa: Suppress "VPHN is not supported" messages

    [ Upstream commit 437ccdc8ce629470babdda1a7086e2f477048cbd ]

    When VPHN function is not supported and during cpu hotplug event,
    kernel prints message 'VPHN function not supported. Disabling
    polling...'. Currently it prints on every hotplug event, it floods
    dmesg when a KVM guest tries to hotplug huge number of vcpus, let's
    just print once and suppress further kernel prints.

    Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit d635d44ec07b13e094eabac6a122c4aeddfead03
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Thu Sep 20 08:59:14 2018 -0400

    kdb: Use strscpy with destination buffer size

    [ Upstream commit c2b94c72d93d0929f48157eef128c4f9d2e603ce ]

    gcc 8.1.0 warns with:

    kernel/debug/kdb/kdb_support.c: In function ‘kallsyms_symbol_next’:
    kernel/debug/kdb/kdb_support.c:239:4: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
         strncpy(prefix_name, name, strlen(name)+1);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    kernel/debug/kdb/kdb_support.c:239:31: note: length computed here

    Use strscpy() with the destination buffer size, and use ellipses when
    displaying truncated symbols.

    v2: Use strscpy()

    Change-Id: Ie2ea7c43fec7acc88291e95689a9067faeb4207e
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Cc: Jonathan Toppins <jtoppins@redhat.com>
    Cc: Jason Wessel <jason.wessel@windriver.com>
    Cc: Daniel Thompson <daniel.thompson@linaro.org>
    Cc: kgdb-bugreport@lists.sourceforge.net
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit f3f84ce028b833168d9f15141bc1f90612d76319
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Nov 12 16:06:51 2018 -0500

    SUNRPC: Fix a bogus get/put in generic_key_to_expire()

    [ Upstream commit e3d5e573a54dabdc0f9f3cb039d799323372b251 ]

    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 1005de7e0a8f03096109bc29fa39b21333b4acf4
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Thu Jul 19 11:42:36 2018 +0100

    ARM: make lookup_processor_type() non-__init

    [ Upstream commit 899a42f836678a595f7d2bc36a5a0c2b03d08cbc ]

    Move lookup_processor_type() out of the __init section so it is callable
    from (eg) the secondary startup code during hotplug.

    Reviewed-by: Julien Thierry <julien.thierry@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit be2bcc4e7613b705621657a8f5b3c9b8ce67e9e8
Author: Anson Huang <anson.huang@nxp.com>
Date:   Mon Nov 5 00:59:28 2018 +0000

    cpufreq: imx6q: add return value check for voltage scale

    [ Upstream commit 6ef28a04d1ccf718eee069b72132ce4aa1e52ab9 ]

    Add return value check for voltage scale when ARM clock
    rate change fail.

    Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 0682307f4d6a2728aabdb0de86d2d1dfa9571b12
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 14:15:13 2018 +0100

    can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb

    commit 7da11ba5c5066dadc2e96835a6233d56d7b7764a upstream.

    Prior to echoing a successfully transmitted CAN frame (by calling
    can_get_echo_skb()), CAN drivers have to put the CAN frame (by calling
    can_put_echo_skb() in the transmit function). These put and get function
    take an index as parameter, which is used to identify the CAN frame.

    A driver calling can_get_echo_skb() with a index not pointing to a skb
    is a BUG, so add an appropriate error message.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit eabcdcea7413feb1a20006e4ac9a51ead83b2512
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 14:05:26 2018 +0100

    can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb is accessed out of bounds

    commit e7a6994d043a1e31d5b17706a22ce33d2a3e4cdc upstream.

    If the "struct can_priv::echo_skb" is accessed out of bounds would lead
    to a kernel crash. Better print a sensible warning message instead and
    try to recover.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 0a94a66631d897ece3269120a9d6db8e722f09a0
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 11:08:21 2018 +0100

    can: dev: __can_get_echo_skb(): replace struct can_frame by canfd_frame to access frame length

    commit 200f5c49f7a2cd694436bfc6cb0662b794c96736 upstream.

    This patch replaces the use of "struct can_frame::can_dlc" by "struct
    canfd_frame::len" to access the frame's length. As it is ensured that
    both structures have a compatible memory layout for this member this is
    no functional change. Futher, this compatibility is documented in a
    comment.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 003bc538cb7189efc32e2edbfa21696d142921af
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Oct 31 10:37:46 2018 +0100

    can: dev: can_get_echo_skb(): factor out non sending code to __can_get_echo_skb()

    commit a4310fa2f24687888ce80fdb0e88583561a23700 upstream.

    This patch factors out all non sending parts of can_get_echo_skb() into
    a seperate function __can_get_echo_skb(), so that it can be re-used in
    an upcoming patch.

    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit b06021a26ed1a5f3c4dfbcd10c708cf5aa3f4930
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Wed Oct 3 14:57:47 2018 +0800

    drm/ast: change resolution may cause screen blurred

    commit 1a37bd823891568f8721989aed0615835632d81a upstream.

    The value of pitches is not correct while calling mode_set.
    The issue we found so far on following system:
    - Debian8 with XFCE Desktop
    - Ubuntu with KDE Desktop
    - SUSE15 with KDE Desktop

    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Cc: <stable@vger.kernel.org>
    Tested-by: Jean Delvare <jdelvare@suse.de>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 8b53725600bdeb001448f16fbf14592996d84dfa
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Tue Oct 30 11:34:46 2018 +0800

    drm/ast: fixed cursor may disappear sometimes

    commit 7989b9ee8bafe5cc625381dd0c3c4586de27ca26 upstream.

    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit c0c8c416a8c830507d02f18463bccd92b6e572f4
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Oct 22 09:24:27 2018 -0700

    llc: do not use sk_eat_skb()

    commit 604d415e2bd642b7e02c80e719e0396b9d4a77a6 upstream.

    syzkaller triggered a use-after-free [1], caused by a combination of
    skb_get() in llc_conn_state_process() and usage of sk_eat_skb()

    sk_eat_skb() is assuming the skb about to be freed is only used by
    the current thread. TCP/DCCP stacks enforce this because current
    thread holds the socket lock.

    llc_conn_state_process() wants to make sure skb does not disappear,
    and holds a reference on the skb it manipulates. But as soon as this
    skb is added to socket receive queue, another thread can consume it.

    This means that llc must use regular skb_unlink() and kfree_skb()
    so that both producer and consumer can safely work on the same skb.

    [1]
    BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
    BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:43 [inline]
    BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:967 [inline]
    BUG: KASAN: use-after-free in kfree_skb+0xb7/0x580 net/core/skbuff.c:655
    Read of size 4 at addr ffff8801d1f6fba4 by task ksoftirqd/1/18

    CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0-rc8+ #295
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
     print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
     kasan_report_error mm/kasan/report.c:354 [inline]
     kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
     check_memory_region_inline mm/kasan/kasan.c:260 [inline]
     check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
     kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
     atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
     refcount_read include/linux/refcount.h:43 [inline]
     skb_unref include/linux/skbuff.h:967 [inline]
     kfree_skb+0xb7/0x580 net/core/skbuff.c:655
     llc_sap_state_process+0x9b/0x550 net/llc/llc_sap.c:224
     llc_sap_rcv+0x156/0x1f0 net/llc/llc_sap.c:297
     llc_sap_handler+0x65e/0xf80 net/llc/llc_sap.c:438
     llc_rcv+0x79e/0xe20 net/llc/llc_input.c:208
     __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
     __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
     process_backlog+0x218/0x6f0 net/core/dev.c:5829
     napi_poll net/core/dev.c:6249 [inline]
     net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
     __do_softirq+0x30c/0xb03 kernel/softirq.c:292
     run_ksoftirqd+0x94/0x100 kernel/softirq.c:653
     smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
     kthread+0x35a/0x420 kernel/kthread.c:246
     ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413

    Allocated by task 18:
     save_stack+0x43/0xd0 mm/kasan/kasan.c:448
     set_track mm/kasan/kasan.c:460 [inline]
     kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
     kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
     kmem_cache_alloc_node+0x144/0x730 mm/slab.c:3644
     __alloc_skb+0x119/0x770 net/core/skbuff.c:193
     alloc_skb include/linux/skbuff.h:995 [inline]
     llc_alloc_frame+0xbc/0x370 net/llc/llc_sap.c:54
     llc_station_ac_send_xid_r net/llc/llc_station.c:52 [inline]
     llc_station_rcv+0x1dc/0x1420 net/llc/llc_station.c:111
     llc_rcv+0xc32/0xe20 net/llc/llc_input.c:220
     __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
     __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
     process_backlog+0x218/0x6f0 net/core/dev.c:5829
     napi_poll net/core/dev.c:6249 [inline]
     net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
     __do_softirq+0x30c/0xb03 kernel/softirq.c:292

    Freed by task 16383:
     save_stack+0x43/0xd0 mm/kasan/kasan.c:448
     set_track mm/kasan/kasan.c:460 [inline]
     __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
     kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
     __cache_free mm/slab.c:3498 [inline]
     kmem_cache_free+0x83/0x290 mm/slab.c:3756
     kfree_skbmem+0x154/0x230 net/core/skbuff.c:582
     __kfree_skb+0x1d/0x20 net/core/skbuff.c:642
     sk_eat_skb include/net/sock.h:2366 [inline]
     llc_ui_recvmsg+0xec2/0x1610 net/llc/af_llc.c:882
     sock_recvmsg_nosec net/socket.c:794 [inline]
     sock_recvmsg+0xd0/0x110 net/socket.c:801
     ___sys_recvmsg+0x2b6/0x680 net/socket.c:2278
     __sys_recvmmsg+0x303/0xb90 net/socket.c:2390
     do_sys_recvmmsg+0x181/0x1a0 net/socket.c:2466
     __do_sys_recvmmsg net/socket.c:2484 [inline]
     __se_sys_recvmmsg net/socket.c:2480 [inline]
     __x64_sys_recvmmsg+0xbe/0x150 net/socket.c:2480
     do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe

    The buggy address belongs to the object at ffff8801d1f6fac0
     which belongs to the cache skbuff_head_cache of size 232
    The buggy address is located 228 bytes inside of
     232-byte region [ffff8801d1f6fac0, ffff8801d1f6fba8)
    The buggy address belongs to the page:
    page:ffffea000747dbc0 count:1 mapcount:0 mapping:ffff8801d9be7680 index:0xffff8801d1f6fe80
    flags: 0x2fffc0000000100(slab)
    raw: 02fffc0000000100 ffffea0007346e88 ffffea000705b108 ffff8801d9be7680
    raw: ffff8801d1f6fe80 ffff8801d1f6f0c0 000000010000000b 0000000000000000
    page dumped because: kasan: bad access detected

    Memory state around the buggy address:
     ffff8801d1f6fa80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
     ffff8801d1f6fb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff8801d1f6fb80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
                                   ^
     ffff8801d1f6fc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8801d1f6fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 6512aeaf1997f13fcbe02862aee5476a864704c9
Author: Andrew Price <anprice@redhat.com>
Date:   Mon Oct 8 07:52:43 2018 -0500

    gfs2: Don't leave s_fs_info pointing to freed memory in init_sbd

    commit 4c62bd9cea7bcf10292f7e4c57a2bca332942697 upstream.

    When alloc_percpu() fails, sdp gets freed but sb->s_fs_info still points
    to the same address. Move the assignment after that error check so that
    s_fs_info can only point to a valid sdp or NULL, which is checked for
    later in the error path, in gfs2_kill_super().

    Reported-by: syzbot+dcb8b3587445007f5808@syzkaller.appspotmail.com
    Signed-off-by: Andrew Price <anprice@redhat.com>
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit 377052c7115933f96c5bfbd49eedd163c28c8022
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Oct 29 23:10:29 2018 +0800

    sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer

    commit df132eff463873e14e019a07f387b4d577d6d1f9 upstream.

    If a transport is removed by asconf but there still are some chunks with
    this transport queuing on out_chunk_list, later an use-after-free issue
    will be caused when accessing this transport from these chunks in
    sctp_outq_flush().

    This is an old bug, we fix it by clearing the transport of these chunks
    in out_chunk_list when removing a transport in sctp_assoc_rm_peer().

    Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: mydongistiny <jaysonedson@gmail.com>

commit e8b986b8b57add839a8d149860051e99c296ec06
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri Nov 2 15:48:42 2018 -0700

    bfs: add sanity check at bfs_fill_super()

    commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e upstream.

    syzbot is reporting too large memory allocation at bfs_fill_super() [1].
    Since file system image is corrupted such that bfs_sb->s_start == 0,
    bfs_fill_super() is trying to allocate 8MB o…

woodsts pushed a commit to woodsts/linux-stable that referenced this issue Dec 1, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a39 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

woodsts pushed a commit to woodsts/linux-stable that referenced this issue Dec 1, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a39 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

arghyac35 added a commit to arghyac35/android_kernel_lenovo_msm8953 that referenced this issue Dec 1, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Arghya Chanda <arghyac35@gmail.com>

miraclestars added a commit to miraclestars/android_kernel_samsung_msm8996 that referenced this issue Dec 1, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

miraclestars added a commit to miraclestars/android_kernel_samsung_msm8996 that referenced this issue Dec 1, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

Enzaik added a commit to DireWolfKernel/Direwolf_unified that referenced this issue Dec 1, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 1a9409ebba38fbafb01ab55a2f4abe76c8ddcde7)
Signed-off-by: Enzaik <imernestodiaz@gmail.com>

psndna88 added a commit to psndna88/AGNi_pureMIUI that referenced this issue Dec 2, 2018

Merge kernel.org 4.4.166
usb: core: Fix hub port connection events lost

commit 22454b79e6de05fa61a2a72d00d2eed798abbb75 upstream.

This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset
only if a device is was attached to the hub port before resetting the hub port.

Using a Lenovo T480s attached to the ultra dock it was not possible to detect
some usb-c devices at the dock usb-c ports because the hub_port_reset code
will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset.
Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the
actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit.
This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the
new device was attached such that it was not detected.

This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is
currently no device attached to the port before the hub port reset.
This will avoid clearing the connection bit for new attached devices.

Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: xhci: fix timeout for transition from RExit to U0

commit a5baeaeabcca3244782a9b6382ebab6f8a58f583 upstream.

This definition is used by msecs_to_jiffies in milliseconds.
According to the comments, max rexit timeout should be 20ms.
Align with the comments to properly calculate the delay.

Verified on Sunrise Point-LP and Cannon Lake.

Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MAINTAINERS: Add Sasha as a stable branch maintainer

commit cb5d21946d2a2f4687c482ab4604af1d29dac35a upstream.

Sasha has somehow been convinced into helping me with the stable kernel
maintenance.  Codify this slip in good judgement before he realizes what
he really signed up for :)

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: support sta_statistics() even on older firmware

commit ec484d03ef0df8d34086b95710e355a259cbe1f2 upstream.

The oldest firmware supported by iwlmvm do support getting
the average beacon RSSI. Enable the sta_statistics() call
from mac80211 even on older firmware versions.

Fixes: 33cef92 ("iwlwifi: mvm: support beacon statistics for BSS client")
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
v9fs_dir_readdir: fix double-free on p9stat_read error

commit 81c99089bce693b94b775b6eb888115d2d540086 upstream.

p9stat_read will call p9stat_free on error, we should only free the
struct content on success.

There also is no need to "p9stat_init" st as the read function will
zero the whole struct for us anyway, so clean up the code a bit while
we are here.

Link: http://lkml.kernel.org/r/1535410108-20650-1-git-send-email-asmadeus@codewreck.org
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bfs: add sanity check at bfs_fill_super()

commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e upstream.

syzbot is reporting too large memory allocation at bfs_fill_super() [1].
Since file system image is corrupted such that bfs_sb->s_start == 0,
bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix
this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and
printf().

[1] https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96

Link: http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+71c6b5d68e91149fc8a4@syzkaller.appspotmail.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Tigran Aivazian <aivazian.tigran@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer

commit df132eff463873e14e019a07f387b4d577d6d1f9 upstream.

If a transport is removed by asconf but there still are some chunks with
this transport queuing on out_chunk_list, later an use-after-free issue
will be caused when accessing this transport from these chunks in
sctp_outq_flush().

This is an old bug, we fix it by clearing the transport of these chunks
in out_chunk_list when removing a transport in sctp_assoc_rm_peer().

Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gfs2: Don't leave s_fs_info pointing to freed memory in init_sbd

commit 4c62bd9cea7bcf10292f7e4c57a2bca332942697 upstream.

When alloc_percpu() fails, sdp gets freed but sb->s_fs_info still points
to the same address. Move the assignment after that error check so that
s_fs_info can only point to a valid sdp or NULL, which is checked for
later in the error path, in gfs2_kill_super().

Reported-by: syzbot+dcb8b3587445007f5808@syzkaller.appspotmail.com
Signed-off-by: Andrew Price <anprice@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
llc: do not use sk_eat_skb()

commit 604d415e2bd642b7e02c80e719e0396b9d4a77a6 upstream.

syzkaller triggered a use-after-free [1], caused by a combination of
skb_get() in llc_conn_state_process() and usage of sk_eat_skb()

sk_eat_skb() is assuming the skb about to be freed is only used by
the current thread. TCP/DCCP stacks enforce this because current
thread holds the socket lock.

llc_conn_state_process() wants to make sure skb does not disappear,
and holds a reference on the skb it manipulates. But as soon as this
skb is added to socket receive queue, another thread can consume it.

This means that llc must use regular skb_unlink() and kfree_skb()
so that both producer and consumer can safely work on the same skb.

[1]
BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:43 [inline]
BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:967 [inline]
BUG: KASAN: use-after-free in kfree_skb+0xb7/0x580 net/core/skbuff.c:655
Read of size 4 at addr ffff8801d1f6fba4 by task ksoftirqd/1/18

CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0-rc8+ #295
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
 atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
 refcount_read include/linux/refcount.h:43 [inline]
 skb_unref include/linux/skbuff.h:967 [inline]
 kfree_skb+0xb7/0x580 net/core/skbuff.c:655
 llc_sap_state_process+0x9b/0x550 net/llc/llc_sap.c:224
 llc_sap_rcv+0x156/0x1f0 net/llc/llc_sap.c:297
 llc_sap_handler+0x65e/0xf80 net/llc/llc_sap.c:438
 llc_rcv+0x79e/0xe20 net/llc/llc_input.c:208
 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
 process_backlog+0x218/0x6f0 net/core/dev.c:5829
 napi_poll net/core/dev.c:6249 [inline]
 net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
 __do_softirq+0x30c/0xb03 kernel/softirq.c:292
 run_ksoftirqd+0x94/0x100 kernel/softirq.c:653
 smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
 kthread+0x35a/0x420 kernel/kthread.c:246
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413

Allocated by task 18:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
 kmem_cache_alloc_node+0x144/0x730 mm/slab.c:3644
 __alloc_skb+0x119/0x770 net/core/skbuff.c:193
 alloc_skb include/linux/skbuff.h:995 [inline]
 llc_alloc_frame+0xbc/0x370 net/llc/llc_sap.c:54
 llc_station_ac_send_xid_r net/llc/llc_station.c:52 [inline]
 llc_station_rcv+0x1dc/0x1420 net/llc/llc_station.c:111
 llc_rcv+0xc32/0xe20 net/llc/llc_input.c:220
 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
 process_backlog+0x218/0x6f0 net/core/dev.c:5829
 napi_poll net/core/dev.c:6249 [inline]
 net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
 __do_softirq+0x30c/0xb03 kernel/softirq.c:292

Freed by task 16383:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
 __cache_free mm/slab.c:3498 [inline]
 kmem_cache_free+0x83/0x290 mm/slab.c:3756
 kfree_skbmem+0x154/0x230 net/core/skbuff.c:582
 __kfree_skb+0x1d/0x20 net/core/skbuff.c:642
 sk_eat_skb include/net/sock.h:2366 [inline]
 llc_ui_recvmsg+0xec2/0x1610 net/llc/af_llc.c:882
 sock_recvmsg_nosec net/socket.c:794 [inline]
 sock_recvmsg+0xd0/0x110 net/socket.c:801
 ___sys_recvmsg+0x2b6/0x680 net/socket.c:2278
 __sys_recvmmsg+0x303/0xb90 net/socket.c:2390
 do_sys_recvmmsg+0x181/0x1a0 net/socket.c:2466
 __do_sys_recvmmsg net/socket.c:2484 [inline]
 __se_sys_recvmmsg net/socket.c:2480 [inline]
 __x64_sys_recvmmsg+0xbe/0x150 net/socket.c:2480
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff8801d1f6fac0
 which belongs to the cache skbuff_head_cache of size 232
The buggy address is located 228 bytes inside of
 232-byte region [ffff8801d1f6fac0, ffff8801d1f6fba8)
The buggy address belongs to the page:
page:ffffea000747dbc0 count:1 mapcount:0 mapping:ffff8801d9be7680 index:0xffff8801d1f6fe80
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0007346e88 ffffea000705b108 ffff8801d9be7680
raw: ffff8801d1f6fe80 ffff8801d1f6f0c0 000000010000000b 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8801d1f6fa80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
 ffff8801d1f6fb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8801d1f6fb80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
                               ^
 ffff8801d1f6fc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8801d1f6fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc

Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/ast: change resolution may cause screen blurred

commit 1a37bd823891568f8721989aed0615835632d81a upstream.

The value of pitches is not correct while calling mode_set.
The issue we found so far on following system:
- Debian8 with XFCE Desktop
- Ubuntu with KDE Desktop
- SUSE15 with KDE Desktop

Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
Cc: <stable@vger.kernel.org>
Tested-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/ast: fixed cursor may disappear sometimes

commit 7989b9ee8bafe5cc625381dd0c3c4586de27ca26 upstream.

Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: dev: can_get_echo_skb(): factor out non sending code to __can_get_echo_skb()

commit a4310fa2f24687888ce80fdb0e88583561a23700 upstream.

This patch factors out all non sending parts of can_get_echo_skb() into
a seperate function __can_get_echo_skb(), so that it can be re-used in
an upcoming patch.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: dev: __can_get_echo_skb(): replace struct can_frame by canfd_frame to access frame length

commit 200f5c49f7a2cd694436bfc6cb0662b794c96736 upstream.

This patch replaces the use of "struct can_frame::can_dlc" by "struct
canfd_frame::len" to access the frame's length. As it is ensured that
both structures have a compatible memory layout for this member this is
no functional change. Futher, this compatibility is documented in a
comment.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb is accessed out of bounds

commit e7a6994d043a1e31d5b17706a22ce33d2a3e4cdc upstream.

If the "struct can_priv::echo_skb" is accessed out of bounds would lead
to a kernel crash. Better print a sensible warning message instead and
try to recover.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb

commit 7da11ba5c5066dadc2e96835a6233d56d7b7764a upstream.

Prior to echoing a successfully transmitted CAN frame (by calling
can_get_echo_skb()), CAN drivers have to put the CAN frame (by calling
can_put_echo_skb() in the transmit function). These put and get function
take an index as parameter, which is used to identify the CAN frame.

A driver calling can_get_echo_skb() with a index not pointing to a skb
is a BUG, so add an appropriate error message.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: xhci: Prevent bus suspend if a port connect change or polling state is detected

commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream.

USB3 roothub might autosuspend before a plugged USB3 device is detected,
causing USB3 device enumeration failure.

USB3 devices don't show up as connected and enabled until USB3 link trainig
completes. On a fast booting platform with a slow USB3 link training the
link might reach the connected enabled state just as the bus is suspending.

If this device is discovered first time by the xhci_bus_suspend() routine
it will be put to U3 suspended state like the other ports which failed to
suspend earlier.

The hub thread will notice the connect change and resume the bus,
moving the port back to U0

This U0 -> U3 -> U0 transition right after being connected seems to be
too much for some devices, causing them to first go to SS.Inactive state,
and finally end up stuck in a polling state with reset asserted

Fix this by failing the bus suspend if a port has a connect change or is
in a polling state in xhci_bus_suspend().

Don't do any port changes until all ports are checked, buffer all port
changes and only write them in the end if suspend can proceed

Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KVM: PPC: Move and undef TRACE_INCLUDE_PATH/FILE

[ Upstream commit 28c5bcf74fa07c25d5bd118d1271920f51ce2a98 ]

TRACE_INCLUDE_PATH and TRACE_INCLUDE_FILE are used by
<trace/define_trace.h>, so like that #include, they should
be outside #ifdef protection.

They also need to be #undefed before defining, in case multiple trace
headers are included by the same C file.  This became the case on
book3e after commit cf4a6085151a ("powerpc/mm: Add missing tracepoint for
tlbie"), leading to the following build error:

   CC      arch/powerpc/kvm/powerpc.o
In file included from arch/powerpc/kvm/powerpc.c:51:0:
arch/powerpc/kvm/trace.h:9:0: error: "TRACE_INCLUDE_PATH" redefined
[-Werror]
  #define TRACE_INCLUDE_PATH .
  ^
In file included from arch/powerpc/kvm/../mm/mmu_decl.h:25:0,
                  from arch/powerpc/kvm/powerpc.c:48:
./arch/powerpc/include/asm/trace.h:224:0: note: this is the location of
the previous definition
  #define TRACE_INCLUDE_PATH asm
  ^
cc1: all warnings being treated as errors

Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Scott Wood <oss@buserror.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq: imx6q: add return value check for voltage scale

[ Upstream commit 6ef28a04d1ccf718eee069b72132ce4aa1e52ab9 ]

Add return value check for voltage scale when ARM clock
rate change fail.

Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
SUNRPC: Fix a bogus get/put in generic_key_to_expire()

[ Upstream commit e3d5e573a54dabdc0f9f3cb039d799323372b251 ]

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
kdb: Use strscpy with destination buffer size

[ Upstream commit c2b94c72d93d0929f48157eef128c4f9d2e603ce ]

gcc 8.1.0 warns with:

kernel/debug/kdb/kdb_support.c: In function ‘kallsyms_symbol_next’:
kernel/debug/kdb/kdb_support.c:239:4: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
     strncpy(prefix_name, name, strlen(name)+1);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kernel/debug/kdb/kdb_support.c:239:31: note: length computed here

Use strscpy() with the destination buffer size, and use ellipses when
displaying truncated symbols.

v2: Use strscpy()

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Jonathan Toppins <jtoppins@redhat.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: kgdb-bugreport@lists.sourceforge.net
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
powerpc/numa: Suppress "VPHN is not supported" messages

[ Upstream commit 437ccdc8ce629470babdda1a7086e2f477048cbd ]

When VPHN function is not supported and during cpu hotplug event,
kernel prints message 'VPHN function not supported. Disabling
polling...'. Currently it prints on every hotplug event, it floods
dmesg when a KVM guest tries to hotplug huge number of vcpus, let's
just print once and suppress further kernel prints.

Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tmpfs: make lseek(SEEK_DATA/SEK_HOLE) return ENXIO with a negative offset

[ Upstream commit 1a413646931cb14442065cfc17561e50f5b5bb44 ]

Other filesystems such as ext4, f2fs and ubifs all return ENXIO when
lseek (SEEK_DATA or SEEK_HOLE) requests a negative offset.

man 2 lseek says

:      EINVAL whence  is  not  valid.   Or: the resulting file offset would be
:             negative, or beyond the end of a seekable device.
:
:      ENXIO  whence is SEEK_DATA or SEEK_HOLE, and the file offset is  beyond
:             the end of the file.

Make tmpfs return ENXIO under these circumstances as well.  After this,
tmpfs also passes xfstests's generic/448.

[akpm@linux-foundation.org: rewrite changelog]
Link: http://lkml.kernel.org/r/1540434176-14349-1-git-send-email-yuyufen@huawei.com
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Hugh Dickins <hughd@google.com>
Cc: William Kucharski <william.kucharski@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
of: add helper to lookup compatible child node

[ Upstream commit 36156f9241cb0f9e37d998052873ca7501ad4b36 ]

Add of_get_compatible_child() helper that can be used to lookup
compatible child nodes.

Several drivers currently use of_find_compatible_node() to lookup child
nodes while failing to notice that the of_find_ functions search the
entire tree depth-first (from a given start node) and therefore can
match unrelated nodes. The fact that these functions also drop a
reference to the node they start searching from (e.g. the parent node)
is typically also overlooked, something which can lead to use-after-free
bugs.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
NFC: nfcmrvl_uart: fix OF child-node lookup

[ Upstream commit 5bf59773aaf36dd62117dc83d50e1bbf9ef432da ]

Use the new of_get_compatible_child() helper to lookup the nfc child
node instead of using of_find_compatible_node(), which searches the
entire tree from a given start node and thus can return an unrelated
(i.e. non-child) node.

This also addresses a potential use-after-free (e.g. after probe
deferral) as the tree-wide helper drops a reference to its first
argument (i.e. the parent node).

Fixes: e097dc6 ("NFC: nfcmrvl: add UART driver")
Fixes: d8e018c ("NFC: nfcmrvl: update device tree bindings for Marvell NFC")
Cc: stable <stable@vger.kernel.org>     # 4.2
Cc: Vincent Cuissard <cuissard@marvell.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: bcmgenet: fix OF child-node lookup

[ Upstream commit d397dbe606120a1ea1b11b0020c3f7a3852da5ac ]

Use the new of_get_compatible_child() helper to lookup the mdio child
node instead of using of_find_compatible_node(), which searches the
entire tree from a given start node and thus can return an unrelated
(i.e. non-child) node.

This also addresses a potential use-after-free (e.g. after probe
deferral) as the tree-wide helper drops a reference to its first
argument (i.e. the node of the device being probed).

Fixes: aa09677 ("net: bcmgenet: add MDIO routines")
Cc: stable <stable@vger.kernel.org>     # 3.15
Cc: David S. Miller <davem@davemloft.net>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
x86/entry: spell EBX register correctly in documentation

[ Upstream commit 75ca5b22260ef7b5ce39c6d521eee8b4cba44703 ]

As EBS does not mean anything reasonable in the context it is used, it
seems like a misspelling for EBX.

Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
x86/entry/64: Remove %ebx handling from error_entry/exit

[ Upstream commit b3681dd548d06deb2e1573890829dff4b15abf46 ]

error_entry and error_exit communicate the user vs. kernel status of
the frame using %ebx.  This is unnecessary -- the information is in
regs->cs.  Just use regs->cs.

This makes error_entry simpler and makes error_exit more robust.

It also fixes a nasty bug.  Before all the Spectre nonsense, the
xen_failsafe_callback entry point returned like this:

        ALLOC_PT_GPREGS_ON_STACK
        SAVE_C_REGS
        SAVE_EXTRA_REGS
        ENCODE_FRAME_POINTER
        jmp     error_exit

And it did not go through error_entry.  This was bogus: RBX
contained garbage, and error_exit expected a flag in RBX.

Fortunately, it generally contained *nonzero* garbage, so the
correct code path was used.  As part of the Spectre fixes, code was
added to clear RBX to mitigate certain speculation attacks.  Now,
depending on kernel configuration, RBX got zeroed and, when running
some Wine workloads, the kernel crashes.  This was introduced by:

    commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts, to reduce speculation attack surface")

With this patch applied, RBX is no longer needed as a flag, and the
problem goes away.

I suspect that malicious userspace could use this bug to crash the
kernel even without the offending patch applied, though.

[ Historical note: I wrote this patch as a cleanup before I was aware
  of the bug it fixed. ]

[ Note to stable maintainers: this should probably get applied to all
  kernels.  If you're nervous about that, a more conservative fix to
  add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should
  also fix the problem. ]

Reported-and-tested-by: M. Vefa Bicakci <m.v.b@runbox.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts, to reduce speculation attack surface")
Link: http://lkml.kernel.org/r/b5010a090d3586b2d6e06c7ad3ec5542d1241c45.1532282627.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ath10k: fix kernel panic due to race in accessing arvif list

commit ebaa4b1620bf69f2bc43cb45ea85fbafdaec23c3 upstream.

arvifs list is traversed within data_lock spin_lock in tasklet
context to fill channel information from the corresponding vif.
This means any access to arvifs list for add/del operations
should also be protected with the same spin_lock to avoid the
race. Fix this by performing list add/del on arvfis within the
data_lock. This could fix kernel panic something like the below.

 LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core]
 PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core]
 Internal error: Oops: 17 [#1] PREEMPT SMP ARM
 [<bf4857f4>] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core])
 [<bf487540>] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core])
 [<c00312d4>] (tasklet_action+0x8c/0xec)
 [<c00309a8>] (__do_softirq+0xdc/0x208)
 [<c0030d6c>] (irq_exit+0x84/0xe0)
 [<c005db04>] (__handle_domain_irq+0x80/0xa0)
 [<c00085c4>] (gic_handle_irq+0x38/0x5c)
 [<c0009640>] (__irq_svc+0x40/0x74)

(gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0)
0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769)
764		struct cfg80211_chan_def def;
765
766		lockdep_assert_held(&ar->data_lock);
767
768		list_for_each_entry(arvif, &ar->arvifs, list) {
769			if (arvif->vdev_id == vdev_id &&
770			    ath10k_mac_vif_chan(arvif->vif, &def) == 0)
771				return def.chan;
772		}
773

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: xpad - remove spurious events of wireless xpad 360 controller

[ Upstream commit 93a017aa2f77291752e637bfd83f2459dba714cb ]

When powering up a wireless xbox 360 controller, some wrong joystick
events are generated. It is annoying because, for example, it makes
unwanted moves in Steam big picture mode's menu.

When my controller is powering up, this packet is received by the
driver:
00000000: 00 0f 00 f0 00 cc ff cf 8b e0 86 6a 68 f0 00 20  ...........jh..
00000010: 13 e3 20 1d 30 03 40 01 50 01 ff ff              .. .0.@.P...

According to xboxdrv userspace driver source code, this packet is only
dumping a serial id and should not be interpreted as joystick events.
This issue can be easily seen with jstest:
$ jstest --event /dev/input/js0

This patch only adds a way to filter out this "serial" packet and as a
result it removes the spurous events.

Signed-off-by: Clement Calmels <clement.calmels@free.fr>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - handle "present" and "gone" correctly

[ Upstream commit 09c8b00ae3e16c8d0fd4beb2ca064502a76c0f17 ]

Handle the "a new device is present" message properly by dynamically
creating the input device at this point in time. This means we now do not
"preallocate" all 4 devices when a single wireless base station is seen.
This requires a workqueue as we are in interrupt context when we learn
about this.

Also properly disconnect any devices that we are told are removed.

Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - update Xbox One Force Feedback Support

[ Upstream commit 2a6d7527b35cf987260800807e328d167aef22ac ]

There's apparently a serial number woven into both input and output
packets; neglecting to specify a valid serial number causes the controller
to ignore the rumble packets.

The scale of the rumble was also apparently halved in the packets.

The initialization packet had to be changed to allow force feedback to
work.

see paroj/xpad#7 for details.

Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - workaround dead irq_out after suspend/ resume

[ Upstream commit 4220f7db1e424f2a086ad41217b5770cc9f003a9 ]

The irq_out urb is dead after suspend/ resume on my x360 wr pad. (also
reproduced by Zachary Lund [0]) Work around this by implementing
suspend, resume, and reset_resume callbacks and properly shutting down
URBs on suspend and restarting them on resume.

[0]: paroj/xpad#6

Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - use LED API when identifying wireless controllers

[ Upstream commit d9be398afb2c3333716324352d062c50112e4e86 ]

When lighting up the segment identifying wireless controller, Instead of
sending command directly to the controller, let's do it via LED API (usinf
led_set_brightness) so that LED object state is in sync with controller
state and we'll light up the correct segment on resume as well.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - correct xbox one pad device name

[ Upstream commit 95162dc8493ed92e5f7dcc8874e58c2ba3836b43 ]

Apparently the Covert Forces ID is not Covert Forces pad exclusive, but
rather denotes a new firmware version that can be found on all new
controllers and can be also updated on old hardware using Windows 10.

see: paroj/xpad#19

Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - remove unused function

[ Upstream commit a6ed4a18ba6a6f5a01e024b9d221d6439bf6ca4c ]

There are two definitions of xpad_identify_controller(), one is used
when CONFIG_JOYSTICK_XPAD_LEDS is set, but the other one is empty
and never used, and we get a gcc warning about it:

drivers/input/joystick/xpad.c:1210:13: warning: 'xpad_identify_controller' defined but not used [-Wunused-function]

This removes the second definition.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: cae705b ("Input: xpad - re-send LED command on present event")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - add Mad Catz FightStick TE 2 VID/PID

[ Upstream commit d63b0f0c0f19dc8687387ead5a28148dcad1a4b9 ]

This adds the VID/PID combination for the Xbox One version of the Mad
Catz FightStick TE 2.

The functionality that this provides is about on par with what the
Windows drivers for the stick manage to deliver.

What works:
- Digital stick
- 6 main buttons
- Xbox button
- The two buttons on the back
- The locking buttons (preventing accidental Xbox button press)

What doesn't work:
- Two of the main buttons (don't work on Windows either)
- The "Haptic" button setting does not have an effect (not sure if it
  works on Windows)

I added the MAP_TRIGGERS_TO_BUTTONS option but in my (limited) testing
there was no practical difference with or without. The FightStick does
not have triggers though so adding it makes sense.

Signed-off-by: Silvan Jegen <s.jegen@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - prevent spurious input from wired Xbox 360 controllers

[ Upstream commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 ]

After initially connecting a wired Xbox 360 controller or sending it
a command to change LEDs, a status/response packet is interpreted as
controller input. This causes the state of buttons represented in
byte 2 of the controller data packet to be incorrect until the next
valid input packet. Wireless Xbox 360 controllers are not affected.

Writing a new value to the LED device while holding the Start button
and running jstest is sufficient to reproduce this bug. An event will
come through with the Start button released.

Xboxdrv also won't attempt to read controller input from a packet
where byte 0 is non-zero. It also checks that byte 1 is 0x14, but
that value differs between wired and wireless controllers and this
code is shared by both. I think just checking byte 0 is enough to
eliminate unwanted packets.

The following are some examples of 3-byte status packets I saw:
01 03 02
02 03 00
03 03 03
08 03 00

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - add more third-party controllers

[ Upstream commit 6538c3b2d2d220a974e47928b165ea09b9cfa6b4 ]

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Signed-off-by: aronschatz <aronschatz@aselabs.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - xbox one elite controller support

[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - fix rumble on Xbox One controllers with 2015 firmware

[ Upstream commit 540c26087bfbad6ea72758b76b16ae6282a73fea ]

Xbox One controllers that shipped with or were upgraded to the 2015
firmware discard the current rumble packets we send. This patch changes
the Xbox One rumble packet to a form that both the newer and older
firmware will accept.

It is based on changes made to support newer Xbox One controllers in
the SteamOS brewmaster-4.1 kernel branch.

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - power off wireless 360 controllers on suspend

[ Upstream commit f712a5a05228058f6b74635546549d4a46e117fc ]

When the USB wireless adapter is suspended, the controllers
lose their connection. This causes them to start flashing
their LED rings and searching for the wireless adapter
again, wasting the controller's battery power.

Instead, we will tell the controllers to power down when
we suspend. This mirrors the behavior of the controllers
when connected to the console itself and how the official
Xbox One wireless adapter behaves on Windows.

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - add product ID for Xbox One S pad

[ Upstream commit 599b8c09d974d6e4d85a8f7bc8ed7442977866a8 ]

This is the new gamepad that ships with the Xbox One S which
includes Bluetooth functionality.

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - fix Xbox One rumble stopping after 2.5 secs

[ Upstream commit ae3b4469dbcd3b842a9fd20940946e4d092d8731 ]

Unlike previous Xbox pads, the Xbox One pad doesn't have "sticky" rumble
packets. The duration is encoded into the command and expiration is handled
by the pad firmware.

ff-memless needs pseudo-sticky behavior for rumble effects to behave
properly for long duration effects. We already specify the maximum rumble
on duration in the command packets, but it's still only good for about 2.5
seconds of rumble. This is easily reproducible running fftest's sine
vibration test.

It turns out there's a repeat count encoded in the rumble command. We can
abuse that to get the pseudo-sticky behavior needed for rumble to behave as
expected for effects with long duration.

By my math, this change should allow a single ff_effect to rumble for 10
minutes straight, which should be more than enough for most needs.

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - correctly sort vendor id's

[ Upstream commit c02fc1d9e5d9f093296e43e13ec7f35f140784bd ]

Signed-off-by: Daniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - move reporting xbox one home button to common function

[ Upstream commit 4f88476c75429ba9ab71c428b4cd2f67575bc9c1 ]

xbox one was the only device that has a *_process_buttons routine.

Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - simplify error condition in init_output

[ Upstream commit a8c34e27fb1ece928ec728bfe596aa6ca0b1928a ]

Replace first goto with simple returns as we really are just returning
one error code.

Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - don't depend on endpoint order

[ Upstream commit c01b5e7464f0cf20936d7467c7528163c4e2782d ]

The order of endpoints is well defined on official Xbox pads, but
we have found at least one 3rd-party pad that doesn't follow the
standard ("Titanfall 2 Xbox One controller" 0e6f:0165).

Fortunately, we get lucky with this specific pad because it uses
endpoint addresses that differ only by direction. We know that
there are other pads out where this is not true, so let's go
ahead and fix this.

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - fix stuck mode button on Xbox One S pad

[ Upstream commit 57b8443d3e5bd046a519ff714ca31c64c7f04309 ]

The Xbox One S requires an ack to its mode button report, otherwise it
continuously retransmits the report. This makes the mode button appear to
be stuck down after it is pressed for the first time.

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - restore LED state after device resume

[ Upstream commit a1fbf5bbef025b4844162b3b8868888003a7ee9c ]

Set the LED_CORE_SUSPENDRESUME flag on our LED device so the
LED state will be automatically restored by LED core on resume.

Since Xbox One pads stop flashing only when reinitialized, we'll
send them the initialization packet so they calm down too.

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - support some quirky Xbox One pads

[ Upstream commit 81093c9848a781b85163d06de92ef8f84528cf6a ]

There are several quirky Xbox One pads that depend on initialization
packets that the Microsoft pads don't require. To deal with these,
I've added a mechanism for issuing device-specific initialization
packets using a VID/PID-based quirks list.

For the initial set of init quirks, I have added quirk handling from
Valve's Steam Link xpad driver[0] and the 360Controller project[1] for
macOS to enable some new pads to work properly.

This should enable full functionality on the following quirky pads:
0x0e6f:0x0165 - Titanfall 2 gamepad (previously fully non-functional)
0x0f0d:0x0067 - Hori Horipad (analog sticks previously non-functional)
0x24c6:0x541a - PowerA Xbox One pad (previously fully non-functional)
0x24c6:0x542a - PowerA Xbox One pad (previously fully non-functional)
0x24c6:0x543a - PowerA Xbox One pad (previously fully non-functional)

[0]: https://github.com/ValveSoftware/steamlink-sdk/blob/master/kernel/drivers/input/joystick/xpad.c
[1]: https://github.com/360Controller/360Controller

Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - sort supported devices by USB ID

[ Upstream commit 873cb582738fde338ecaeaca594560cde2ba42c3 ]

Some entries in the table of supported devices are out of order.
To not create a mess when adding new ones using a script, sort them first.

Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - sync supported devices with xboxdrv

[ Upstream commit 44bc722593201da43862b7200ee0b98155410b07 ]

The userspace xboxdrv driver [0] contains some USB IDs unknown to the
kernel driver. I have created a simple script [1] to extract the missing
devices and add them to xpad.

A quick google search confirmed that all the new devices called
Fightstick/pad are Arcade-type devices [2] where the
MAP_TRIGGERS_TO_BUTTONS option should apply.

There are some similar devices in the existing device table where this
flag is not set, but I did refrain from changing those.

[0] https://github.com/xboxdrv/xboxdrv/blob/stable/src/xpad_device.cpp
[1] http://codepad.org/CHV98BNH
[2] https://www.google.com/search?q=SFxT+Fightstick+Pro&tbm=isch

Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - add USB IDs for Mad Catz Brawlstick and Razer Sabertooth

[ Upstream commit 4706aa075662fe3cad29c3f49b50878de53f4f3b ]

Add USB IDs for two more Xbox 360 controllers.

I found them in the pull requests for the xboxdrv userspace driver, which
seems abandoned.

Thanks to psychogony and mkaito for reporting the IDs there!

Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - sync supported devices with 360Controller

[ Upstream commit c225370e01b87d3c4ef40d98295ac0bb1e5a3116 ]

360Controller [0] is an OpenSource driver for Xbox/Xbox360/XboxOne
controllers on macOS.

It contains a couple device IDs unknown to the Linux driver, so I wrote a
small Python script [1] to extract them and feed them into my previous
script [2] to compare them with the IDs known to Linux.

For most devices, this information is not really needed as xpad is able to
automatically detect the type of an unknown Xbox Controller at run-time.
I've therefore stripped all the generic/vague entries.

I've excluded the Logitech G920, it's handled by a HID driver already.
I've also excluded the Scene It! Big Button IR, it's handled by an
out-of-tree driver. [3]

[0] https://github.com/360Controller/360Controller
[1] http://codepad.org/v9GyLKMq
[2] http://codepad.org/qh7jclpD
[3] https://github.com/micolous/xbox360bb

Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - sync supported devices with XBCD

[ Upstream commit be19788c73d382f66dd3fba3c5ccef59cf12a126 ]

XBCD [0][1] is an OpenSource driver for Xbox controllers on Windows.
Later it also started supporting Xbox360 controllers (presumably before
the official Windows driver was released).

It contains a couple device IDs unknown to the Linux driver, so I extracted
those from xbcd.inf and added them to our list.

It has a special type for Wheels and I have the feeling they might need
some extra handling. They all have 'Wheel' in their name, so that
information is available for future improvements.

[0] https://www.s-config.com/xbcd-original-xbox-controllers-win10/
[1] http://www.redcl0ud.com/xbcd.html

Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - constify usb_device_id

[ Upstream commit 94aef061c796d3d47f1a2eed41e651ffaaade402 ]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - fix PowerA init quirk for some gamepad models

[ Upstream commit f5308d1b83eba20e69df5e0926ba7257c8dd9074 ]

The PowerA gamepad initialization quirk worked with the PowerA
wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
that it didn't work for him, even though our gamepads shared the
same vendor and product IDs.

When I initially implemented the PowerA quirk, I wanted to avoid
actually triggering the rumble action during init. My tests showed
that my gamepad would work correctly even if it received a rumble
of 0 intensity, so that's what I went with.

Unfortunately, this apparently isn't true for all models (perhaps
a firmware difference?). This non-working gamepad seems to require
the real magic rumble packet that the Microsoft driver sends, which
actually vibrates the gamepad. To counteract this effect, I still
send the old zero-rumble PowerA quirk packet which cancels the
rumble effect before the motors can spin up enough to vibrate.

[0]: paroj/xpad#48 (comment)

Reported-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
Tested-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads")
Cc: stable@vger.kernel.org # v4.12
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

DirtyUnicorn pushed a commit to DirtyUnicorns/android_kernel_google_marlin that referenced this issue Dec 2, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

mcdachpappe added a commit to mcdachpappe/android_kernel_oneplus_msm8996-eas that referenced this issue Dec 2, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

Sajidjnl added a commit to LiquidRemixSanders/android_kernel_motorola_msm8953_sanders that referenced this issue Dec 2, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a39 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

limoniumstatice added a commit to limoniumstatice/fini_kernel_marlin that referenced this issue Dec 4, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

mcdachpappe added a commit to mcdachpappe/android_kernel_oneplus_msm8996-eas that referenced this issue Dec 4, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

scafroglia93 added a commit to HardcoreKernel/freezerfhd that referenced this issue Dec 5, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

MasterAwesome added a commit to MasterAwesome/android_kernel_motorola_msm8953 that referenced this issue Dec 5, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a39 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

followmsi added a commit to followmsi/android_kernel_tegra that referenced this issue Dec 5, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

followmsi added a commit to followmsi/android_kernel_tegra that referenced this issue Dec 5, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

jollaman999 added a commit to jollaman999/jolla-kernel_joan that referenced this issue Dec 5, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

00day0 added a commit to 00day0/idle_kernel_xiaomi_msm8996 that referenced this issue Dec 5, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

miraclestars added a commit to miraclestars/android_kernel_samsung_msm8996 that referenced this issue Dec 6, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

zaherr added a commit to zaherr/franco that referenced this issue Dec 7, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

limoniumstatice added a commit to limoniumstatice/luna_kernel_mata that referenced this issue Dec 8, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

tnakamur added a commit to tnakamur/linux-stable that referenced this issue Dec 8, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

tnakamur added a commit to tnakamur/linux-stable that referenced this issue Dec 8, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

mvaisakh pushed a commit to mvaisakh/kernel-msm that referenced this issue Dec 8, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a39 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

TR-76 added a commit to TR-76/OP3-HDK that referenced this issue Dec 9, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

SahilSonar added a commit to SahilSonar/android_kernel_lenovo_k5fpr that referenced this issue Dec 11, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

dcionline pushed a commit to dcionline/eco_kernel_hi3650_eva that referenced this issue Dec 12, 2018

Input: xpad - xbox one elite controller support
[ Upstream commit 6f49a398b266d4895bd7e041db77a2b2ee1482a6 ]

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: paroj/xpad#23

Signed-off-by: Pierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment