Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Taiko Controller support #9

Open
Leeo97one opened this issue May 6, 2020 · 0 comments
Open

Taiko Controller support #9

Leeo97one opened this issue May 6, 2020 · 0 comments

Comments

@Leeo97one
Copy link

Would it be possible to support the official Taiko controller for the Nintendo Switch?

mai 06 02:20:06 kernel: usb 1-4: new full-speed USB device number 7 using xhci_hcd
mai 06 02:20:06 kernel: usb 1-4: New USB device found, idVendor=0f0d, idProduct=00f0, bcdDevice= 1.00
mai 06 02:20:06 kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
mai 06 02:20:06 kernel: usb 1-4: Product: Taiko Controller
mai 06 02:20:06 kernel: usb 1-4: Manufacturer: HORI CO.,LTD.
mai 06 02:20:06 kernel: input: HORI CO.,LTD. Taiko Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/0003:0F0D:00F0.0005/input/input25
mai 06 02:20:06 kernel: hid-generic 0003:0F0D:00F0.0005: input,hidraw3: USB HID v1.11 Gamepad [HORI CO.,LTD. Taiko Controller] on usb-0000:00:14.0-4/input0

I guess it should just act as a wired Switch Pro Controller.
DanielOgorchock pushed a commit that referenced this issue Jun 6, 2020
@nhorman @gregkh
sctp: Don't add the shutdown timer if its already been added
085bb27 
[ Upstream commit 20a785a ]

This BUG halt was reported a while back, but the patch somehow got
missed:

PID: 2879   TASK: c16adaa0  CPU: 1   COMMAND: "sctpn"
 #0 [f418dd28] crash_kexec at c04a7d8c
 #1 [f418dd7c] oops_end at c0863e02
 #2 [f418dd90] do_invalid_op at c040aaca
 #3 [f418de28] error_code (via invalid_op) at c08631a5
    EAX: f34baac0  EBX: 00000090  ECX: f418deb0  EDX: f5542950  EBP: 00000000
    DS:  007b      ESI: f34ba800  ES:  007b      EDI: f418dea0  GS:  00e0
    CS:  0060      EIP: c046fa5e  ERR: ffffffff  EFLAGS: 00010286
 #4 [f418de5c] add_timer at c046fa5e
 #5 [f418de68] sctp_do_sm at f8db8c77 [sctp]
 #6 [f418df30] sctp_primitive_SHUTDOWN at f8dcc1b5 [sctp]
 #7 [f418df48] inet_shutdown at c080baf9
 #8 [f418df5c] sys_shutdown at c079eedf
 #9 [f418df70] sys_socketcall at c079fe88
    EAX: ffffffda  EBX: 0000000d  ECX: bfceea90  EDX: 0937af98
    DS:  007b      ESI: 0000000c  ES:  007b      EDI: b7150ae4
    SS:  007b      ESP: bfceea7c  EBP: bfceeaa8  GS:  0033
    CS:  0073      EIP: b775c424  ERR: 00000066  EFLAGS: 00000282

It appears that the side effect that starts the shutdown timer was processed
multiple times, which can happen as multiple paths can trigger it.  This of
course leads to the BUG halt in add_timer getting called.

Fix seems pretty straightforward, just check before the timer is added if its
already been started.  If it has mod the timer instead to min(current
expiration, new expiration)

Its been tested but not confirmed to fix the problem, as the issue has only
occured in production environments where test kernels are enjoined from being
installed.  It appears to be a sane fix to me though.  Also, recentely,
Jere found a reproducer posted on list to confirm that this resolves the
issues

Signed-off-by: Neil Horman <[email protected]>
CC: Vlad Yasevich <[email protected]>
CC: "David S. Miller" <[email protected]>
CC: [email protected]
CC: [email protected]
CC: [email protected]
Acked-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Leeo97one