- 16 Jan, 2019 40 commits
-
-
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
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:
-
Cameron Gutman authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit a1fbf5bb ] 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 authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 57b8443d ] 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 authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit c01b5e74 ] 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:
-
Pavel Rojtberg authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit a8c34e27 ] 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:
-
Daniel Tobias authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 4f88476c ] xbox one was the only device that has a *_process_buttons routine. Signed-off-by:
-
Daniel Tobias authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit c02fc1d9 ] Signed-off-by:
Daniel Tobias <dan.g.tob@gmail.com> Signed-off-by:
-
Cameron Gutman authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit ae3b4469 ] 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 authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 599b8c09 ] This is the new gamepad that ships with the Xbox One S which includes Bluetooth functionality. Signed-off-by:
-
Cameron Gutman authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit f712a5a0 ] 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 authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 540c2608 ] 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:
-
Pavel Rojtberg authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 6f49a398 ] 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/23Signed-off-by:
Pierre-Loup A. Griffais <eduke32@plagman.net> Signed-off-by:
-
Pavel Rojtberg authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 6538c3b2 ] Signed-off-by:
Thomas Debesse <dev@illwieckz.net> Signed-off-by:
aronschatz <aronschatz@aselabs.com> Signed-off-by:
-
Cameron Gutman authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit 1ff5fa3c ] 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:
-
Silvan Jegen authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit d63b0f0c ] 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:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1810967 [ Upstream commit a6ed4a18 ] 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: cae705ba ("Input: xpad - re-send LED command on present event") Signed-off-by:
-
