- 16 Jan, 2019 40 commits
-
-
Dmitry Safonov authored
BugLink: https://bugs.launchpad.net/bugs/1791758 As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter. Simplify math by increasing the counter after reinit success. Cc: Jiri Slaby <jslaby@suse.com> Link: lkml.kernel.org/r/<20180829022353.23568-2-dima@arista.com> Suggested-by:
Jiri Slaby <jslaby@suse.com> Reviewed-by:
Jiri Slaby <jslaby@suse.cz> Tested-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit cf62a1a1) Signed-off-by:
Guilherme G. Piccoli <gpiccoli@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Kleber Souza <kleber.souza@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Dmitry Safonov authored
BugLink: https://bugs.launchpad.net/bugs/1791758 There might be situations where tty_ldisc_lock() has blocked, but there is already IO on tty and it prevents line discipline changes. It might theoretically turn into dead-lock. Basically, provide more priority to pending tty_ldisc_lock() than to servicing reads/writes over tty. User-visible issue was reported by Mikulas where on pa-risc with Debian 5 reboot took either 80 seconds, 3 minutes or 3:25 after proper locking in tty_reopen(). Cc: Jiri Slaby <jslaby@suse.com> Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Dmitry Safonov authored
BugLink: https://bugs.launchpad.net/bugs/1791758 tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup() nor set_ldisc() nor tty_ldisc_release() as they use tty lock. But it races with anyone who expects line discipline to be the same after hoding read semaphore in tty_ldisc_ref(). We've seen the following crash on v4.9.108 stable: BUG: unable to handle kernel paging request at 0000000000002260 IP: [..] n_tty_receive_buf_common+0x5f/0x86d Workqueue: events_unbound flush_to_ldisc Call Trace: [..] n_tty_receive_buf2 [..] tty_ldisc_receive_buf [..] flush_to_ldisc [..] process_one_work [..] worker_thread [..] kthread [..] ret_from_fork tty_ldisc_reinit() should be called with ldisc_sem hold for writing, which will protect any reader against line discipline changes. Cc: Jiri Slaby <jslaby@suse.com> Cc: stable@vger.kernel.org # b027e229 ("tty: fix data race between tty_init_dev and flush of buf") Reviewed-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Tycho Andersen <tycho@tycho.ws> Signed-off-by:
-
Dmitry Safonov authored
BugLink: https://bugs.launchpad.net/bugs/1791758 In case of tty_ldisc_reinit() failure, tty->count should be decremented back, otherwise we will never release_tty(). Tetsuo reported that it fixes noisy warnings on tty release like: pts pts4033: tty_release: tty->count(10529) != (#fd's(7) + #kopen's(0)) Fixes: commit 892d1fa7 ("tty: Destroy ldisc instance on hangup") Cc: stable@vger.kernel.org # v4.6+ Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Reviewed-by:
-
Gaurav Kohli authored
BugLink: https://bugs.launchpad.net/bugs/1791758 There can be a race, if receive_buf call comes before tty initialization completes in n_tty_open and tty->disc_data may be NULL. CPU0 CPU1 ---- ---- 000|n_tty_receive_buf_common() n_tty_open() -001|n_tty_receive_buf2() tty_ldisc_open.isra.3() -002|tty_ldisc_receive_buf(inline) tty_ldisc_setup() Using ldisc semaphore lock in tty_init_dev till disc_data initializes completely. Signed-off-by:
Gaurav Kohli <gkohli@codeaurora.org> Reviewed-by:
Alan Cox <alan@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1810967Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Thomas Zimmermann authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 5478ad10 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=1112963Signed-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:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Janosch Frank authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 1843abd0 upstream. Userspace could have munmapped the area before doing unmapping from the gmap. This would leave us with a valid vmaddr, but an invalid vma from which we would try to zap memory. Let's check before using the vma. Fixes: 1e133ab2 ("s390/mm: split arch/s390/mm/pgtable.c") Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Message-Id: <20180816082432.78828-1-frankja@linux.ibm.com> Signed-off-by:
-
Salvatore Mesoraca authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 30aba665 upstream. Disallows open of FIFOs or regular files not owned by the user in world writable sticky directories, unless the owner is the same as that of the directory or the file is opened without the O_CREAT flag. The purpose is to make data spoofing attacks harder. This protection can be turned on and off separately for FIFOs and regular files via sysctl, just like the symlinks/hardlinks protection. This patch is based on Openwall's "HARDEN_FIFO" feature by Solar Designer. This is a brief list of old vulnerabilities that could have been prevented by this feature, some of them even allow for privilege escalation: CVE-2000-1134 CVE-2007-3852 CVE-2008-0525 CVE-2009-0416 CVE-2011-4834 CVE-2015-1838 CVE-2015-7442 CVE-2016-7489 This list is not meant to be complete. It's difficult to track down all vulnerabilities of this kind because they were often reported without any mention of this particular attack vector. In fact, before hardlinks/symlinks restrictions, fifos/regular files weren't the favorite vehicle to exploit them. [s.mesoraca16@gmail.com: fix bug reported by Dan Carpenter] Link: https://lkml.kernel.org/r/20180426081456.GA7060@mwanda Link: http://lkml.kernel.org/r/1524829819-11275-1-git-send-email-s.mesoraca16@gmail.com [keescook@chromium.org: drop pr_warn_ratelimited() in favor of audit changes in the future] [keescook@chromium.org: adjust commit subjet] Link: http://lkml.kernel.org/r/20180416175918.GA13494@beastSigned-off-by:
Salvatore Mesoraca <s.mesoraca16@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Suggested-by:
Solar Designer <solar@openwall.com> Suggested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Loic <hackurx@opensec.fr> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 896bbb25 upstream. When priority inheritance was added back in 2.6.18 to sched_setscheduler(), it added a path to taking an rt-mutex wait_lock, which is not IRQ safe. As PI is not a common occurrence, lockdep will likely never trigger if sched_setscheduler was called from interrupt context. A BUG_ON() was added to trigger if __sched_setscheduler() was ever called from interrupt context because there was a possibility to take the wait_lock. Today the wait_lock is irq safe, but the path to taking it in sched_setscheduler() is the same as the path to taking it from normal context. The wait_lock is taken with raw_spin_lock_irq() and released with raw_spin_unlock_irq() which will indiscriminately enable interrupts, which would be bad in interrupt context. The problem is that normalize_rt_tasks, which is called by triggering the sysrq nice-all-RT-tasks was changed to call __sched_setscheduler(), and this is done from interrupt context! Now __sched_setscheduler() takes a "pi" parameter that is used to know if the priority inheritance should be called or not. As the BUG_ON() only cares about calling the PI code, it should only bug if called from interrupt context with the "pi" parameter set to true. Reported-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Tested-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@osdl.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: dbc7f069 ("sched: Use replace normalize_task() with __sched_setscheduler()") Link: http://lkml.kernel.org/r/20170308124654.10e598f2@gandalf.local.homeSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Qu Wenruo authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 6ba9fc8e upstream. [BUG] fstrim on some btrfs only trims the unallocated space, not trimming any space in existing block groups. [CAUSE] Before fstrim_range passed to btrfs_trim_fs(), it gets truncated to range [0, super->total_bytes). So later btrfs_trim_fs() will only be able to trim block groups in range [0, super->total_bytes). While for btrfs, any bytenr aligned to sectorsize is valid, since btrfs uses its logical address space, there is nothing limiting the location where we put block groups. For filesystem with frequent balance, it's quite easy to relocate all block groups and bytenr of block groups will start beyond super->total_bytes. In that case, btrfs will not trim existing block groups. [FIX] Just remove the truncation in btrfs_ioctl_fitrim(), so btrfs_trim_fs() can get the unmodified range, which is normally set to [0, U64_MAX]. Reported-by:
Chris Murphy <lists@colorremedies.com> Fixes: f4c697e6 ("btrfs: return EINVAL if start > total_bytes in fitrim ioctl") CC: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Aaron Ma authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 958c0bd8 upstream. Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3, after clear port reset it works fine. Since this device is registered on USB3 roothub at boot, when port status reports not superspeed, xhci_get_port_status will call an uninitialized completion in bus_state[0]. Kernel will hang because of NULL pointer. Restrict the USB2 resume status check in USB2 roothub to fix hang issue. 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 authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit b97b3d9f 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:
-
Linus Torvalds authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit c9a8e5fc upstream. After we are done with the tty buffer, zero it out. Reported-by:
-
Emmanuel Grumbach authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 82715ac7 upstream. When the firmware starts, it doesn't have any regulatory information, hence it uses the world wide limitations. The driver can feed the firmware with previous knowledge that was kept in the driver, but the firmware may still not update its internal tables. This happens when we start a BSS interface, and then the firmware can change the regulatory tables based on our location and it'll use more lenient, location specific rules. Then, if the firmware is shut down (when the interface is brought down), and then an AP interface is created, the firmware will forget the country specific rules. The host will think that we are in a certain country that may allow channels and will try to teach the firmware about our location, but the firmware may still not allow to drop the world wide limitations and apply country specific rules because it was just re-started. In this case, the firmware will reply with MCC_RESP_ILLEGAL to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let the upper layers (cfg80211 / hostapd) know that the channel list they know about has been updated. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105 Cc: stable@vger.kernel.org Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Mauricio Faria de Oliveira authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 04dfaa53 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:
-
Subhash Jadavani authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit afa3dfd4 upstream. If ufshcd pltfrm/pci driver's probe fails for some reason then ensure that scsi host is released to avoid memory leak but managed memory allocations (via devm_* calls) need not to be freed explicitly on probe failure as memory allocated with these functions is automatically freed on driver detach. Reviewed-by:
Sahitya Tummala <stummala@codeaurora.org> Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
Subhash Jadavani authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 30fc33f1 upstream. UFS devfreq clock scaling work may require clocks to be ON if it need to execute some UFS commands hence it may request for clock hold before issuing the command. But if UFS clock gating work is already running in parallel, ungate work would end up waiting for the clock gating work to finish and as clock gating work would also wait for the clock scaling work to finish, we would enter in deadlock state. Here is the call trace during this deadlock state: Workqueue: devfreq_wq devfreq_monitor __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work ufshcd_hold ufshcd_send_uic_cmd ufshcd_dme_get_attr ufs_qcom_set_dme_vs_core_clk_ctrl_clear_div ufs_qcom_clk_scale_notify ufshcd_scale_clks ufshcd_devfreq_target update_devfreq devfreq_monitor process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_gate_work __switch_to __schedule schedule schedule_preempt_disabled __mutex_lock_slowpath mutex_lock devfreq_monitor_suspend devfreq_simple_ondemand_handler devfreq_suspend_device ufshcd_gate_work process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_ungate_work __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work __cancel_work_timer cancel_delayed_work_sync ufshcd_ungate_work process_one_work worker_thread kthread ret_from_fork This change fixes this deadlock by doing this in devfreq work (devfreq_wq): Try cancelling clock gating work. If we are able to cancel gating work or it wasn't scheduled, hold the clock reference count until scaling is in progress. If gate work is already running in parallel, let's skip the frequecy scaling at this time and it will be retried once next scaling window expires. Reviewed-by:
-
Venkat Gopalakrishnan authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit f2a785ac 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:
-
Yaniv Gardi authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit e3ce73d6 upstream. In this change there are a few fixes of possible NULL pointer access and possible access to index that exceeds array boundaries. Signed-off-by:
Yaniv Gardi <ygardi@codeaurora.org> Signed-off-by:
-
Liping Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 58c78e10 upstream. Dalegaard says: The following ruleset, when loaded with 'nft -f bad.txt' ----snip---- flush ruleset table ip inlinenat { map sourcemap { type ipv4_addr : verdict; } chain postrouting { ip saddr vmap @sourcemap accept } } add chain inlinenat test add element inlinenat sourcemap { 100.123.10.2 : jump test } ----snip---- results in a kernel oops: BUG: unable to handle kernel paging request at 0000000000001344 IP: [<ffffffffa07bf704>] nf_tables_check_loops+0x114/0x1f0 [nf_tables] [...] Call Trace: [<ffffffffa07c2aae>] ? nft_data_init+0x13e/0x1a0 [nf_tables] [<ffffffffa07c1950>] nft_validate_register_store+0x60/0xb0 [nf_tables] [<ffffffffa07c74b5>] nft_add_set_elem+0x545/0x5e0 [nf_tables] [<ffffffffa07bfdd0>] ? nft_table_lookup+0x30/0x60 [nf_tables] [<ffffffff8132c630>] ? nla_strcmp+0x40/0x50 [<ffffffffa07c766e>] nf_tables_newsetelem+0x11e/0x210 [nf_tables] [<ffffffff8132c400>] ? nla_validate+0x60/0x80 [<ffffffffa030d9b4>] nfnetlink_rcv+0x354/0x5a7 [nfnetlink] Because we forget to fill the net pointer in bind_ctx, so dereferencing it may cause kernel crash. Reported-by:
Dalegaard <dalegaard@gmail.com> Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Karthik D A authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 3d8bd85c upstream. Marvell p2p device disappears from the list of p2p peers on the other p2p device after disconnection. It happens due to a bug in driver. When interface is changed from p2p to station, certain variables(bss_type, bss_role etc.) aren't correctly updated. This patch corrects them to fix the issue. Signed-off-by:
Karthik D A <karthida@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> [AmitP: Refactored to fix driver file path in linux-4.4.y] Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit c44c0403 upstream. At couple of places in cleanup path, we are just going through the skb queue and freeing them without unlinking. This leads to a crash when other thread tries to do skb_dequeue() and use already freed node. The problem is freed by unlinking skb before freeing it. Signed-off-by:
-
Johannes Thumshirn authored
BugLink: https://bugs.launchpad.net/bugs/1810967 commit 9afdd612 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:
-
Ramses Ramírez authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 9735082a ] 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:
-
Enno Boland authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit dd6bee81 ] 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: c1ba0839 ("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:
-
Ethan Lee authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit c1ba0839 ] 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:
-
Marcus Folkesson authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit a0130803 ] 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:
-
Leo Sperling authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 68c78d01 ] 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:
-
Francis Therien authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit c6c84857 ] 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:
-
Mark Furneaux authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit e5c9c6a8 ] 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:
-
Cameron Gutman authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 122d6a34 ] 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:
-
Cameron Gutman authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit f5308d1b ] 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-313904867Reported-by:
Kyle Beauchamp <kyleabeauchamp@gmail.com> Tested-by:
-
Arvind Yadav authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 94aef061 ] 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:
-
Benjamin Valentin authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit be19788c ] 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.htmlReviewed-by:
Benjamin Valentin <benpicco@googlemail.com> Signed-off-by:
-
Benjamin Valentin authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit c225370e ] 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/xbox360bbReviewed-by:
-
Benjamin Valentin authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 4706aa07 ] 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 authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 44bc7225 ] 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=ischSigned-off-by:
-
Benjamin Valentin authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 873cb582 ] 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:
-
Cameron Gutman authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 81093c98 ] 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/360ControllerSigned-off-by:
-
