aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-10-27net: hns3: add more string spaces for dumping packets number of queue info in debugfsJie Wang1-2/+2
As the width of packets number registers is 32 bits, they needs at most 10 characters for decimal data printing, but now the string spaces is not enough, so this patch fixes it. Fixes: e44c495d95e ("net: hns3: refactor queue info of debugfs") Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-27net: hns3: fix data endian problem of some functions of debugfsJie Wang1-16/+14
The member data in struct hclge_desc is type of __le32, it needs endian conversion before using it, and some functions of debugfs didn't do that, so this patch fixes it. Fixes: c0ebebb9ccc1 ("net: hns3: Add "dcb register" status information query function") Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-27net: hns3: ignore reset event before initialization process is doneGuangbin Huang3-0/+5
Currently, if there is a reset event triggered by RAS during device in initialization process, driver may run reset process concurrently with initialization process. In this case, it may cause problem. For example, the RSS indirection table may has not been alloc memory in initialization process yet, but it is used in reset process, it will cause a call trace like this: [61228.744836] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... [61228.897677] Workqueue: hclgevf hclgevf_service_task [hclgevf] [61228.911390] pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) [61228.918670] pc : hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf] [61228.927812] lr : hclgevf_set_rss_indir_table+0x90/0x190 [hclgevf] [61228.937248] sp : ffff8000162ebb50 [61228.941087] x29: ffff8000162ebb50 x28: ffffb77add72dbc0 x27: ffff0820c7dc8080 [61228.949516] x26: 0000000000000000 x25: ffff0820ad4fc880 x24: ffff0820c7dc8080 [61228.958220] x23: ffff0820c7dc8090 x22: 00000000ffffffff x21: 0000000000000040 [61228.966360] x20: ffffb77add72b9c0 x19: 0000000000000000 x18: 0000000000000030 [61228.974646] x17: 0000000000000000 x16: ffffb77ae713feb0 x15: ffff0820ad4fcce8 [61228.982808] x14: ffffffffffffffff x13: ffff8000962eb7f7 x12: 00003834ec70c960 [61228.991990] x11: 00e0fafa8c206982 x10: 9670facc78a8f9a8 x9 : ffffb77add717530 [61229.001123] x8 : ffff0820ad4fd6b8 x7 : 0000000000000000 x6 : 0000000000000011 [61229.010249] x5 : 00000000000cb1b0 x4 : 0000000000002adb x3 : 0000000000000049 [61229.018662] x2 : ffff8000162ebbb8 x1 : 0000000000000000 x0 : 0000000000000480 [61229.027002] Call trace: [61229.030177] hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf] [61229.039009] hclgevf_rss_init_hw+0x128/0x1b4 [hclgevf] [61229.046809] hclgevf_reset_rebuild+0x17c/0x69c [hclgevf] [61229.053862] hclgevf_reset_service_task+0x4cc/0xa80 [hclgevf] [61229.061306] hclgevf_service_task+0x6c/0x630 [hclgevf] [61229.068491] process_one_work+0x1dc/0x48c [61229.074121] worker_thread+0x15c/0x464 [61229.078562] kthread+0x168/0x16c [61229.082873] ret_from_fork+0x10/0x18 [61229.088221] Code: 7900e7f6 f904a683 d503201f 9101a3e2 (38616b43) [61229.095357] ---[ end trace 153661a538f6768c ]--- To fix this problem, don't schedule reset task before initialization process is done. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-27net: hns3: change hclge/hclgevf workqueue to WQ_UNBOUND modeYufeng Mo3-31/+6
Currently, the workqueue of hclge/hclgevf is executed on the CPU that initiates scheduling requests by default. In stress scenarios, the CPU may be busy and workqueue scheduling is completed after a long period of time. To avoid this situation and implement proper scheduling, use the WQ_UNBOUND mode instead. In this way, the workqueue can be performed on a relatively idle CPU. Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-27net: hns3: fix pause config problem after autoneg disabledGuangbin Huang5-10/+57
If a TP port is configured by follow steps: 1.ethtool -s ethx autoneg off speed 100 duplex full 2.ethtool -A ethx rx on tx on 3.ethtool -s ethx autoneg on(rx&tx negotiated pause results are off) 4.ethtool -s ethx autoneg off speed 100 duplex full In step 3, driver will set rx&tx pause parameters of hardware to off as pause parameters negotiated with link partner are off. After step 4, the "ethtool -a ethx" command shows both rx and tx pause parameters are on. However, pause parameters of hardware are still off and port has no flow control function actually. To fix this problem, if autoneg is disabled, driver uses its saved parameters to restore pause of hardware. If the speed is not changed in this case, there is no link state changed for phy, it will cause the pause parameter is not taken effect, so we need to force phy to go down and up. Fixes: aacbe27e82f0 ("net: hns3: modify how pause options is displayed") Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-27USB: serial: keyspan: fix memleak on probe errorsWang Hai1-8/+7
I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888258228440 (size 64): comm "kworker/7:2", pid 2005, jiffies 4294989509 (age 824.540s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490 [<ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470 [<ffffffffa02ac0e4>] keyspan_port_probe+0xa4/0x5d0 [keyspan] [<ffffffffa0294c07>] usb_serial_device_probe+0x97/0x1d0 [usbserial] [<ffffffff82b50ca7>] really_probe+0x167/0x460 [<ffffffff82b51099>] __driver_probe_device+0xf9/0x180 [<ffffffff82b51173>] driver_probe_device+0x53/0x130 [<ffffffff82b516f5>] __device_attach_driver+0x105/0x130 [<ffffffff82b4cfe9>] bus_for_each_drv+0x129/0x190 [<ffffffff82b50a69>] __device_attach+0x1c9/0x270 [<ffffffff82b518d0>] device_initial_probe+0x20/0x30 [<ffffffff82b4f062>] bus_probe_device+0x142/0x160 [<ffffffff82b4a4e9>] device_add+0x829/0x1300 [<ffffffffa0295fda>] usb_serial_probe.cold+0xc9b/0x14ac [usbserial] [<ffffffffa02266aa>] usb_probe_interface+0x1aa/0x3c0 [usbcore] [<ffffffff82b50ca7>] really_probe+0x167/0x460 If keyspan_port_probe() fails to allocate memory for an out_buffer[i] or in_buffer[i], the previously allocated memory for out_buffer or in_buffer needs to be freed on the error handling path, otherwise a memory leak will result. Fixes: bad41a5bf177 ("USB: keyspan: fix port DMA-buffer allocations") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20211015085543.1203011-1-wanghai38@huawei.com Cc: stable@vger.kernel.org # 3.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-10-27USB: serial: cp210x: use usb_control_msg_recv() and usb_control_msg_send()Himadri Pandya1-78/+31
The new wrapper functions for usb_control_msg() can accept data from stack and treat short reads as errors. Hence use the wrappers functions. Please note that because of this change, cp210x_read_reg_block() will no longer log the length of short reads. Signed-off-by: Himadri Pandya <himadrispandya@gmail.com> Link: https://lore.kernel.org/r/20211001065720.21330-3-himadrispandya@gmail.com [ johan: style changes ] Signed-off-by: Johan Hovold <johan@kernel.org>
2021-10-27USB: serial: ch314: use usb_control_msg_recv()Himadri Pandya1-59/+26
usb_control_msg_recv() is a new wrapper function for usb_control_msg() that has error checks for short reads. This function also accepts data buffer on stack. Hence use this function to simplify error handling for short reads. Short reads will now get reported as -EREMOTEIO with no indication of how short the transfer was. Signed-off-by: Himadri Pandya <himadrispandya@gmail.com> Link: https://lore.kernel.org/r/20211001065720.21330-2-himadrispandya@gmail.com [ johan: fix quirk-detection breakage, style changes ] Signed-off-by: Johan Hovold <johan@kernel.org>
2021-10-27drm/etnaviv: replace dma_resv_get_excl_unlockedChristian König1-1/+1
We certainly hold the reservation lock here, no need for the RCU dance. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025080532.177424-3-christian.koenig@amd.com
2021-10-27drm/etnaviv: use new iterator in etnaviv_gem_describeChristian König1-20/+11
Instead of hand rolling the logic. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025080532.177424-2-christian.koenig@amd.com
2021-10-27drm/i915: Revert 'guc_id' from i915_request tracepointJoonas Lahtinen1-5/+2
Avoid adding backend specific data to the tracepoints outside of the LOW_LEVEL_TRACEPOINTS kernel config protection. These bits of information are bound to change depending on the selected submission method per platform and are not necessarily possible to maintain in the future. Fixes: dbf9da8d55ef ("drm/i915/guc: Add trace point for GuC submit") Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027093255.66489-1-joonas.lahtinen@linux.intel.com
2021-10-27drm/i915: Nuke PIPE_CONFIG_QUIRK_BIGJOINER_SLAVEVille Syrjälä2-59/+47
Now that the bigjoiner state readout/computation has been made to do the right thing nuke the related state checker quirk. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-10-ville.syrjala@linux.intel.com
2021-10-27drm/i915: Reduce bigjoiner special casingVille Syrjälä2-111/+41
Try to make bigjoiner pipes less special. The main things here are that each pipe now does full clock computation/readout with its own shared_dpll reference. Also every pipe's cpu_transcoder always points correctly at the master transcoder. Due to the above changes state readout is now complete and all the related hacks can go away. The actual modeset sequence code is still a mess, but I think in order to clean that up properly we're probably going to have to redesign the modeset logic to treat transcoders vs. pipes separately. That is going to require significant amounts of work. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-9-ville.syrjala@linux.intel.com
2021-10-27drm/i915: Perform correct cpu_transcoder readout for bigjoinerVille Syrjälä1-0/+66
Read out cpu_transcoder correctly for the bigjoiner slave pipes. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-8-ville.syrjala@linux.intel.com
2021-10-27drm/i915: Split PPS write from DSC enableVille Syrjälä6-31/+39
The PPS SDP is fed into the transcoder whereas the DSC block is (or at least can be) per pipe. Let's split these into two distinct operations in an effort to untagle the bigjoiner mess where we have two pipes feeding a single transcoder. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-7-ville.syrjala@linux.intel.com
2021-10-27drm/i915: Simplify intel_crtc_copy_uapi_to_hw_state_nomodeset()Ville Syrjälä1-10/+7
Rewrite intel_crtc_copy_uapi_to_hw_state_nomodeset() in a slightly more straightforward manner. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-6-ville.syrjala@linux.intel.com
2021-10-27drm/i915: Introduce intel_master_crtc()Ville Syrjälä2-30/+33
Add a helper to determine the master crtc for bigjoiner usage. Also name the variables consistently. Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-5-ville.syrjala@linux.intel.com
2021-10-27drm/i915: Disable all planes before modesetting any pipesVille Syrjälä1-15/+13
Let's disable planes on all pipes affected by the modeset before we start doing the actual modeset. This means we have less random planes enabled during the modeset, and it also mirrors what we already do when enabling pipes on skl+ since we enable planes on all pipes as the very last step. As a bonus we also nuke a bunch og bigjoiner special casing. I've occasionally pondered about going even furher here and doing the pre_plane_update() stuff for all pipes first, then actually disabling the planes, and finally running the rest of the modeset sequence. This would potentially allow parallelizing all the extra vblank waits across multiple pipes, and would make the plane disable even more atomic. But let's go one step a time here. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-4-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-10-27Revert "drm/i915/display: Disable audio, DRRS and PSR before planes"Ville Syrjälä4-59/+13
Disabling planes in the middle of the modeset seuqnece does not make sense since userspace can anyway disable planes before the modeset even starts. So when the modeset seuqence starts the set of enabled planes is entirely arbitrary. Trying to sprinkle the plane disabling into the modeset sequence just means more randomness and potential for hard to reproduce bugs. So it makes most sense to just disable all planes first so that the rest of the modeset sequence remains identical regardless of which planes happen to be enabled by userspace at the time. This reverts commit 84030adb9e27d202a66022488bf0349a8bd45213. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-10-27drm/i915/psr: Disable PSR before modesets turn off all planesVille Syrjälä3-18/+13
PSR2 apparently requires some planes to be enabled for some silly reason, and so we are now trying to turn PSR off before planes go off. Except during a full modeset that is handled less clearly through reorganization of the modeset sequence. That is not great as it makes the code mode complex, and prevents us from doing nice things such as just turning off all the planes at the very start of the modeset. So let's move the PSR pre_plane_update() thing to a spot where it will handle both full modesets and everything else. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-2-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2021-10-27spi: fsi: Fix contention in the FSI2SPI engineEddie James1-22/+53
There was nothing to protect multiple SPI controllers on the same FSI2SPI device from being accessed through the FSI2SPI device at the same time. For example, multiple writes to the command and data registers might occur for different SPI controllers, resulting in complete chaos in the SPI engine. To prevent this, add a FSI2SPI device level mutex and lock it in the SPI register read and write functions. Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20211026193327.52420-1-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-27drm/i915/dp: fix integer overflow in 128b/132b data rate calculationJani Nikula1-1/+1
The intermediate value 1000000 * 10 * 9671 overflows 32 bits, so force promotion to a bigger type. From the logs: [drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available -580783288 v2: Use mul_u32_u32() (Ville) Fixes: 48efd014f0ea ("drm/i915/dp: add max data rate calculation for UHBR rates") Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211026093407.11381-1-jani.nikula@intel.com (cherry picked from commit bf0d608b55d9b7f426031dfd9f08d9df36c94728) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-10-27drm/i915/guc: Fix recursive lock in GuC submissionMatthew Brost1-1/+2
Use __release_guc_id (lock held) rather than release_guc_id (acquires lock), add lockdep annotations. 213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr [ 213.283459] ============================================ [ 213.283462] WARNING: possible recursive locking detected {{[ 213.283466] 5.15.0-rc6+ #18 Tainted: G U W }} [ 213.283470] -------------------------------------------- [ 213.283472] kworker/u24:0/8 is trying to acquire lock: [ 213.283475] ffff8ffc4f6cc1e8 (&guc->submission_state.lock){....}-{2:2}, at: destroyed_worker_func+0x2df/0x350 [i915] {{[ 213.283618] }} {{ but task is already holding lock:}} [ 213.283621] ffff8ffc4f6cc1e8 (&guc->submission_state.lock){....}-{2:2}, at: destroyed_worker_func+0x4f/0x350 [i915] {{[ 213.283720] }} {{ other info that might help us debug this:}} [ 213.283724] Possible unsafe locking scenario:[ 213.283727] CPU0 [ 213.283728] ---- [ 213.283730] lock(&guc->submission_state.lock); [ 213.283734] lock(&guc->submission_state.lock); {{[ 213.283737] }} {{ *** DEADLOCK ***}}[ 213.283740] May be due to missing lock nesting notation[ 213.283744] 3 locks held by kworker/u24:0/8: [ 213.283747] #0: ffff8ffb80059d38 ((wq_completion)events_unbound){..}-{0:0}, at: process_one_work+0x1f3/0x550 [ 213.283757] #1: ffffb509000e3e78 ((work_completion)(&guc->submission_state.destroyed_worker)){..}-{0:0}, at: process_one_work+0x1f3/0x550 [ 213.283766] #2: ffff8ffc4f6cc1e8 (&guc->submission_state.lock){....}-{2:2}, at: destroyed_worker_func+0x4f/0x350 [i915] {{[ 213.283860] }} {{ stack backtrace:}} [ 213.283863] CPU: 8 PID: 8 Comm: kworker/u24:0 Tainted: G U W 5.15.0-rc6+ #18 [ 213.283868] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 213.283873] Workqueue: events_unbound destroyed_worker_func [i915] [ 213.283957] Call Trace: [ 213.283960] dump_stack_lvl+0x57/0x72 [ 213.283966] __lock_acquire.cold+0x191/0x2d3 [ 213.283972] lock_acquire+0xb5/0x2b0 [ 213.283978] ? destroyed_worker_func+0x2df/0x350 [i915] [ 213.284059] ? destroyed_worker_func+0x2d7/0x350 [i915] [ 213.284139] ? lock_release+0xb9/0x280 [ 213.284143] _raw_spin_lock_irqsave+0x48/0x60 [ 213.284148] ? destroyed_worker_func+0x2df/0x350 [i915] [ 213.284226] destroyed_worker_func+0x2df/0x350 [i915] [ 213.284310] process_one_work+0x270/0x550 [ 213.284315] worker_thread+0x52/0x3b0 [ 213.284319] ? process_one_work+0x550/0x550 [ 213.284322] kthread+0x135/0x160 [ 213.284326] ? set_kthread_struct+0x40/0x40 [ 213.284331] ret_from_fork+0x1f/0x30 and a bit later in the trace: {{ 227.499864] do_raw_spin_lock+0x94/0xa0}} [ 227.499868] _raw_spin_lock_irqsave+0x50/0x60 [ 227.499871] ? guc_flush_destroyed_contexts+0x4f/0xf0 [i915] [ 227.499995] guc_flush_destroyed_contexts+0x4f/0xf0 [i915] [ 227.500104] intel_guc_submission_reset_prepare+0x99/0x4b0 [i915] [ 227.500209] ? mark_held_locks+0x49/0x70 [ 227.500212] intel_uc_reset_prepare+0x46/0x50 [i915] [ 227.500320] reset_prepare+0x78/0x90 [i915] [ 227.500412] __intel_gt_set_wedged.part.0+0x13/0xe0 [i915] [ 227.500485] intel_gt_set_wedged.part.0+0x54/0x100 [i915] [ 227.500556] intel_gt_set_wedged_on_fini+0x1a/0x30 [i915] [ 227.500622] intel_gt_driver_unregister+0x1e/0x60 [i915] [ 227.500694] i915_driver_remove+0x4a/0xf0 [i915] [ 227.500767] i915_pci_probe+0x84/0x170 [i915] [ 227.500838] local_pci_probe+0x42/0x80 [ 227.500842] pci_device_probe+0xd9/0x190 [ 227.500844] really_probe+0x1f2/0x3f0 [ 227.500847] __driver_probe_device+0xfe/0x180 [ 227.500848] driver_probe_device+0x1e/0x90 [ 227.500850] __driver_attach+0xc4/0x1d0 [ 227.500851] ? __device_attach_driver+0xe0/0xe0 [ 227.500853] ? __device_attach_driver+0xe0/0xe0 [ 227.500854] bus_for_each_dev+0x64/0x90 [ 227.500856] bus_add_driver+0x12e/0x1f0 [ 227.500857] driver_register+0x8f/0xe0 [ 227.500859] i915_init+0x1d/0x8f [i915] [ 227.500934] ? 0xffffffffc144a000 [ 227.500936] do_one_initcall+0x58/0x2d0 [ 227.500938] ? rcu_read_lock_sched_held+0x3f/0x80 [ 227.500940] ? kmem_cache_alloc_trace+0x238/0x2d0 [ 227.500944] do_init_module+0x5c/0x270 [ 227.500946] __do_sys_finit_module+0x95/0xe0 [ 227.500949] do_syscall_64+0x38/0x90 [ 227.500951] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 227.500953] RIP: 0033:0x7ffa59d2ae0d [ 227.500954] Code: c8 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3b 80 0c 00 f7 d8 64 89 01 48 [ 227.500955] RSP: 002b:00007fff320bbf48 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 227.500956] RAX: ffffffffffffffda RBX: 00000000022ea710 RCX: 00007ffa59d2ae0d [ 227.500957] RDX: 0000000000000000 RSI: 00000000022e1d90 RDI: 0000000000000004 [ 227.500958] RBP: 0000000000000020 R08: 00007ffa59df3a60 R09: 0000000000000070 [ 227.500958] R10: 00000000022e1d90 R11: 0000000000000246 R12: 00000000022e1d90 [ 227.500959] R13: 00000000022e58e0 R14: 0000000000000043 R15: 00000000022e42c0 v2: (CI build) - Fix build error Fixes: 1a52faed31311 ("drm/i915/guc: Take GT PM ref when deregistering context") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020192147.8048-1-matthew.brost@intel.com (cherry picked from commit 12a9917e9e84fef4efa73c09b32870df0b1ed795) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-10-27drm/i915/cdclk: put the cdclk vtables in const dataJani Nikula1-22/+22
Add the const that was accidentally left out from the vtables. Fixes: 6b4cd9cba620 ("drm/i915: constify the cdclk vtable") Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211021133408.32166-1-jani.nikula@intel.com (cherry picked from commit 877d074939a5f82b099da2db3bcccc6c418b9c39) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-10-27Revert "drm/i915/bios: gracefully disable dual eDP for now"Jani Nikula1-47/+0
This reverts commit 05734ca2a8f76c9eb3890b3c9dfc3467f03105c1. It's not graceful, instead it leads to boot time warning splats in the case it is supposed to handle gracefully. Apparently the BIOS/GOP enabling the port we end up skipping leads to state readout problems. Back to the drawing board. References: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/bat-adlp-4/boot0.txt Fixes: 05734ca2a8f7 ("drm/i915/bios: gracefully disable dual eDP for now") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211019114334.24643-1-jani.nikula@intel.com (cherry picked from commit 171c555c2c2664a250cd35680c34c31a6d233dc7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-10-27drm/i915/dp: Ensure max link params are always validImre Deak1-8/+10
Atm until the DPCD for a connector is read the max link rate and lane count params are invalid. If the connector is modeset, in intel_dp_compute_config(), intel_dp_common_len_rate_limit(max_link_rate) will return 0, leading to a intel_dp->common_rates[-1] access. Fix the above by making sure the max link params are always valid. The above access leads to an undefined behaviour by definition, though not causing a user visible problem to my best knowledge, see the previous patch why. Nevertheless it is an undefined behaviour and it triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-4-imre.deak@intel.com (cherry picked from commit 9ad87de4735620ffc555592e8c5f580478fa3ed0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-10-27drm/i915/dp: Ensure sink rate values are always validImre Deak1-0/+11
Atm, there are no sink rate values set for DP (vs. eDP) sinks until the DPCD capabilities are successfully read from the sink. During this time intel_dp->num_common_rates is 0 which can lead to a intel_dp->common_rates[-1] (*) access, which is an undefined behaviour, in the following cases: - In intel_dp_sync_state(), if the encoder is enabled without a sink connected to the encoder's connector (BIOS enabled a monitor, but the user unplugged the monitor until the driver loaded). - In intel_dp_sync_state() if the encoder is enabled with a sink connected, but for some reason the DPCD read has failed. - In intel_dp_compute_link_config() if modesetting a connector without a sink connected on it. - In intel_dp_compute_link_config() if modesetting a connector with a a sink connected on it, but before probing the connector first. To avoid the (*) access in all the above cases, make sure that the sink rate table - and hence the common rate table - is always valid, by setting a default minimum sink rate when registering the connector before anything could use it. I also considered setting all the DP link rates by default, so that modesetting with higher resolution modes also succeeds in the last two cases above. However in case a sink is not connected that would stop working after the first modeset, due to the LT fallback logic. So this would need more work, beyond the scope of this fix. As I mentioned in the previous patch, I don't think the issue this patch fixes is user visible, however it is an undefined behaviour by definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. v2: Clear the default sink rates, before initializing these for eDP. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com (cherry picked from commit 3f61ef9777c0ab0f03f4af0ed6fd3e5250537a8d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-10-27HID: u2fzero: properly handle timeouts in usb_submit_urbAndrej Shadura1-1/+1
The wait_for_completion_timeout function returns 0 if timed out or a positive value if completed. Hence, "less than zero" comparison always misses timeouts and doesn't kill the URB as it should, leading to re-sending it while it is active. Fixes: 42337b9d4d95 ("HID: add driver for U2F Zero built-in LED and RNG") Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: u2fzero: clarify error check and length calculationsAndrej Shadura1-3/+5
The previous commit fixed handling of incomplete packets but broke error handling: offsetof returns an unsigned value (size_t), but when compared against the signed return value, the return value is interpreted as if it were unsigned, so negative return values are never less than the offset. To make the code easier to read, calculate the minimal packet length once and separately, and assign it to a signed int variable to eliminate unsigned math and the need for type casts. It then becomes immediately obvious how the actual data length is calculated and why the return value cannot be less than the minimal length. Fixes: 22d65765f211 ("HID: u2fzero: ignore incomplete packets without data") Fixes: 42337b9d4d95 ("HID: add driver for U2F Zero built-in LED and RNG") Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: u2fzero: Support NitroKey U2F revision of the deviceAndrej Shadura2-9/+39
NitroKey produced a clone of U2F Zero with a different firmware, which moved extra commands into the vendor range. Disambiguate hardware revisions and select the correct configuration in u2fzero_probe. Link: https://github.com/Nitrokey/nitrokey-fido-u2f-firmware/commit/a93c16b41f Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: wacom: Make use of the helper function devm_add_action_or_reset()Cai Huoqing1-4/+2
The helper function devm_add_action_or_reset() will internally call devm_add_action(), and if devm_add_action() fails then it will execute the action mentioned and return the error code. So use devm_add_action_or_reset() instead of devm_add_action() to simplify the error handling, reduce the code. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: wacom: Shrink critical section in `wacom_add_shared_data`Jason Gerecke1-5/+4
The size of the critical section in this function appears to be larger than necessary. The `wacom_udev_list_lock` exists to ensure that one interface cannot begin checking if a shared object exists while a second interface is doing the same (otherwise both could determine that no object exists yet and create their own independent objects rather than sharing just one). It should be safe for the critical section to end once a fresly-allocated shared object would be found by other threads (i.e., once it has been added to `wacom_udev_list`, which is looped over by `wacom_get_hdev_data`). This commit is a necessary pre-requisite for a later change to swap the use of `devm_add_action` with `devm_add_action_or_reset`, which would otherwise deadlock in its error case. Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27iommu/dart: Initialize DART_STREAMS_ENABLESven Peter1-0/+5
DART has an additional global register to control which streams are isolated. This register is a bit redundant since DART_TCR can already be used to control isolation and is usually initialized to DART_STREAM_ALL by the time we get control. Some DARTs (namely the one used for the audio controller) however have some streams disabled initially. Make sure those work by initializing DART_STREAMS_ENABLE during reset. Reported-by: Martin Povišer <povik@protonmail.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Reviewed-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20211019162253.45919-1-sven@svenpeter.dev Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-10-27HID: nintendo: prevent needless queueing of the rumble workerDaniel J. Ogorchock1-1/+17
This patch adds a check for if the rumble queue ringbuffer is empty prior to queuing the rumble workqueue. If the current rumble setting is using a non-zero amplitude though, it will queue the worker anyway. This is because the controller will automatically disable the rumble effect if it isn't "refreshed". This change improves bluetooth communication reliability with the controller, since it reduces the amount of traffic. Note that we still send a few periodic zero packets to avoid scenarios where the controller fails to process the zero amplitude packet. Without sending a few to be sure, the rumble could get stuck on until the controller times out. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: ratelimit subcommands and rumbleDaniel J. Ogorchock1-20/+49
It has been found that sending subcommands and rumble data packets at too great a rate can result in controller disconnects. This patch limits the rate of subcommands/rumble to once every 25 milliseconds. Similar to sending subcommands, it is more reliable to send the rumble data packets immediately after we've received an input report from the controller. This results in far fewer bluetooth disconnects for the controller. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: improve rumble performance and stabilityDaniel J. Ogorchock1-1/+37
This patch alters the method that the rumble data is sent to the controller. Rather than using the enable rumble subcommand for this purpose, the driver now employs the RUMBLE_ONLY output report. This has the advantage of not needing to receive a subcommand reply (to the major benefit of reducing IMU latency) and also seems to make the rumble vibrations more continuous. Perhaps most importantly it reduces disconnects during times of heavy rumble. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add IMU supportDaniel J. Ogorchock2-12/+501
This patch adds support for the controller's IMU. The accelerometer and gyro data are both provided to userspace using a second input device. The devices can be associated using their uniq value (set to the controller's MAC address). A large part of this patch's functionality was provided by Carl Mueller. The IMU device is blacklisted from the joydev input handler. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add support for reading user calibrationDaniel J. Ogorchock1-58/+148
If the controller's SPI flash contains user stick calibration(s), they should be prioritized over the factory calibrations. The user calibrations have 2 magic bytes preceding them. If the bytes are the correct magic values, the user calibration is used. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add support for charging gripDaniel J. Ogorchock2-13/+55
This patch adds support for the joy-con charging grip. The peripheral essentially behaves the same as a pro controller, but with two joy-cons attached to the grip. However the grip exposes the two joy-cons as separate hid devices, so extra handling is required. The joy-con is queried to check if it is a right or left joy-con (since the product ID is identical between left/right when using the grip). Since controller model detection is now more complicated, the various checks for hid product values have been replaced with helper macros to reduce code duplication. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: set controller uniq to MACDaniel J. Ogorchock1-0/+45
This patch sets the input device's uniq identifier to the controller's MAC address. This is useful for future association between an IMU input device with the normal input device as well as associating the controller with any serial joy-con driver. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: reduce device removal subcommand errorsDaniel J. Ogorchock1-2/+22
This patch fixes meaningless error output from trying to send subcommands immediately after controller removal. It now disables subcommands as soon as possible on removal. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: patch hw version for userspace HID mappingsDaniel J. Ogorchock1-0/+9
This patch sets the most significant bit of the hid hw version to allow userspace to distinguish between this driver's input mappings vs. the default hid mappings. This prevents breaking userspace applications that use SDL2 for gamepad input, allowing them to distinguish the mappings based on the version. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: send subcommands after receiving input reportDaniel J. Ogorchock1-0/+33
Waiting to send subcommands until right after receiving an input report drastically improves subcommand reliability. If the driver has finished initial controller configuration, it now waits until receiving an input report for all subcommands. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: improve subcommand reliabilityDaniel J. Ogorchock1-24/+42
The controller occasionally doesn't respond to subcommands. It appears that it's dropping them. To improve reliability, this patch attempts one retry in the case of a synchronous send timeout. In testing, this has resolved all timeout failures (most common for LED setting and rumble setting subcommands). The 1 second timeout is excessively long for rumble and LED subcommands, so the timeout has been made a param for joycon_hid_send_sync. Most subcommands continue to use the 1s timeout, since they can result in long response times. Rumble and LED setting subcommands have been reduced to 250ms, since response times for them are much quicker (and this significantly reduces the observable impact in the case of a retry being required). Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add rumble supportDaniel J. Ogorchock2-3/+356
This patch adds support for controller rumble. The ff_effect weak magnitude is associated with the pro controller's right motor (or with a right joy-con). The strong magnitude is associated with the pro's left motor (or a left joy-con). The rumble data is sent periodically (currently configured for every 50 milliseconds). If the controller receives no rumble data for too long a time period, it will stop vibrating. The data is also sent every time joycon_set_rumble is called to avoid latency of up to 50ms. Because the rumble subcommands are sent in a deferred workqueue (they can't be sent in the play_effect function due to the hid send sleeping), the effects are queued. This ensures that no rumble effect is missed due to them arriving in too quick of succession. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add home led supportDaniel J. Ogorchock1-4/+68
This patch adds the ability to set the intensity level of the home button's LED. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add power supply supportDaniel J. Ogorchock2-0/+135
This patch adds power_supply functionality to the switch controller driver for its battery. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add player led supportDaniel J. Ogorchock2-2/+97
This patch adds led_classdev functionality to the switch controller driver. It adds support for the 4 player LEDs. The Home Button LED still needs to be supported on the pro controllers and right joy-con. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: nintendo: add nintendo switch controller driverDaniel J. Ogorchock4-0/+884
The hid-nintendo driver supports the Nintendo Switch Pro Controllers and the Joy-Cons. The Pro Controllers can be used over USB or Bluetooth. The Joy-Cons each create their own, independent input devices, so it is up to userspace to combine them if desired. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-10-27HID: playstation: fix return from dualsense_player_led_set_brightness()Jiri Kosina1-0/+2
brightness_set_blocking() callback expects function returning int. This fixes the follwoing build failure: drivers/hid/hid-playstation.c: In function ‘dualsense_player_led_set_brightness’: drivers/hid/hid-playstation.c:885:1: error: no return statement in function returning non-void [-Werror=return-type] } ^ Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.