summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2023-10-25i40e: Fix wrong check for I40E_TXR_FLAGS_WB_ON_ITRIvan Vecera1-1/+1
The I40E_TXR_FLAGS_WB_ON_ITR is i40e_ring flag and not i40e_pf one. Fixes: 8e0764b4d6be42 ("i40e/i40evf: Add support for writeback on ITR feature for X722") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20231023212714.178032-1-jacob.e.keller@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-24fpga: Fix memory leak for fpga_region_test_class_find()Jinjie Ruan1-0/+2
fpga_region_class_find() in fpga_region_test_class_find() will call get_device() if the data is matched, which will increment refcount for dev->kobj, so it should call put_device() to decrement refcount for dev->kobj to free the region, because fpga_region_unregister() will call fpga_region_dev_release() only when the refcount for dev->kobj is zero but fpga_region_test_init() call device_register() in fpga_region_register_full(), which also increment refcount. So call put_device() after calling fpga_region_class_find() in fpga_region_test_class_find(). After applying this patch, the following memory leak is never detected. unreferenced object 0xffff88810c8ef000 (size 1024): comm "kunit_try_catch", pid 1875, jiffies 4294715298 (age 836.836s) hex dump (first 32 bytes): b8 d1 fb 05 81 88 ff ff 08 f0 8e 0c 81 88 ff ff ................ 08 f0 8e 0c 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff817ebad7>] kmalloc_trace+0x27/0xa0 [<ffffffffa02385e1>] fpga_region_register_full+0x51/0x430 [fpga_region] [<ffffffffa0228e47>] 0xffffffffa0228e47 [<ffffffff829c479d>] kunit_try_run_case+0xdd/0x250 [<ffffffff829c9f2a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81238b85>] kthread+0x2b5/0x380 [<ffffffff81097ded>] ret_from_fork+0x2d/0x70 [<ffffffff810034d1>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff888105fbd1b8 (size 8): comm "kunit_try_catch", pid 1875, jiffies 4294715298 (age 836.836s) hex dump (first 8 bytes): 72 65 67 69 6f 6e 30 00 region0. backtrace: [<ffffffff817ec023>] __kmalloc_node_track_caller+0x53/0x150 [<ffffffff82995590>] kvasprintf+0xb0/0x130 [<ffffffff83f713b1>] kobject_set_name_vargs+0x41/0x110 [<ffffffff8304ac1b>] dev_set_name+0xab/0xe0 [<ffffffffa02388a2>] fpga_region_register_full+0x312/0x430 [fpga_region] [<ffffffffa0228e47>] 0xffffffffa0228e47 [<ffffffff829c479d>] kunit_try_run_case+0xdd/0x250 [<ffffffff829c9f2a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81238b85>] kthread+0x2b5/0x380 [<ffffffff81097ded>] ret_from_fork+0x2d/0x70 [<ffffffff810034d1>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff88810b3b8a00 (size 256): comm "kunit_try_catch", pid 1875, jiffies 4294715298 (age 836.836s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 8a 3b 0b 81 88 ff ff ..........;..... 08 8a 3b 0b 81 88 ff ff e0 ac 04 83 ff ff ff ff ..;............. backtrace: [<ffffffff817ebad7>] kmalloc_trace+0x27/0xa0 [<ffffffff83056d7a>] device_add+0xa2a/0x15e0 [<ffffffffa02388b1>] fpga_region_register_full+0x321/0x430 [fpga_region] [<ffffffffa0228e47>] 0xffffffffa0228e47 [<ffffffff829c479d>] kunit_try_run_case+0xdd/0x250 [<ffffffff829c9f2a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81238b85>] kthread+0x2b5/0x380 [<ffffffff81097ded>] ret_from_fork+0x2d/0x70 [<ffffffff810034d1>] ret_from_fork_asm+0x11/0x20 Fixes: 64a5f972c93d ("fpga: add an initial KUnit suite for the FPGA Region") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Marco Pagani <marpagan@redhat.com> Acked-by: Xu Yilun <yilun.xu@intel.com> Link: https://lore.kernel.org/r/20231007094321.3447084-1-ruanjinjie@huawei.com [yilun.xu@intel.com: slightly changes the commit message] Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com> Link: https://lore.kernel.org/r/20231023032857.902699-3-yilun.xu@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-24drm/i915/perf: Determine context valid in OA reportsUmesh Nerlige Ramappa1-2/+2
When supporting OA for TGL, it was seen that the context valid bit in the report ID was not defined, however revisiting the spec seems to have this bit defined. The bit is used to determine if a context is valid on a context switch and is essential to determine active and idle periods for a context. Re-enable the context valid bit for gen12 platforms. BSpec: 52196 (description of report_id) v2: Include BSpec reference (Ashutosh) Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230802202854.1224547-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 7eeaedf79989a8f131939782832e21e9218ed2a0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-10-24gtp: fix fragmentation needed check with gsoPablo Neira Ayuso1-2/+3
Call skb_gso_validate_network_len() to check if packet is over PMTU. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-24Fix NULL pointer dereference in cn_filter()Anjali Kulkarni1-1/+1
Check that sk_user_data is not NULL, else return from cn_filter(). Could not reproduce this issue, but Oliver Sang verified it has fixed the "Closes" problem below. Fixes: 2aa1f7a1f47c ("connector/cn_proc: Add filtering to fix some bugs") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202309201456.84c19e27-oliver.sang@intel.com/ Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Link: https://lore.kernel.org/r/20231020234058.2232347-1-anjali.k.kulkarni@oracle.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-10-24sfc: cleanup and reduce netlink error messagesPieter Jansen van Vuuren1-19/+19
Reduce the length of netlink error messages as they are likely to be truncated anyway. Additionally, reword netlink error messages so they are more consistent with previous messages. Fixes: 9dbc8d2b9a02 ("sfc: add decrement ipv6 hop limit by offloading set hop limit actions") Fixes: 3c9561c0a5b9 ("sfc: support TC decap rules matching on enc_ip_tos") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310202136.4u7bv0hp-lkp@intel.com/ Signed-off-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/20231020140149.30490-1-pieter.jansen-van-vuuren@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-23Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds10-30/+109
Pull virtio fixes from Michael Tsirkin: "A collection of small fixes that look like worth having in this release" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: virtio_pci: fix the common cfg map size virtio-crypto: handle config changed by work queue vhost: Allow null msg.size on VHOST_IOTLB_INVALIDATE vdpa/mlx5: Fix firmware error on creation of 1k VQs virtio_balloon: Fix endless deflation and inflation on arm64 vdpa/mlx5: Fix double release of debugfs entry virtio-mmio: fix memory leak of vm_dev vdpa_sim_blk: Fix the potential leak of mgmt_dev tools/virtio: Add dma sync api for virtio test
2023-10-23EDAC/versal: Add a Xilinx Versal memory controller driverShubhrajyoti Datta3-0/+1082
Add a EDAC driver for the RAS capabilities on the Xilinx integrated DDR Memory Controllers (DDRMCs) which support both DDR4 and LPDDR4/4X memory interfaces. It has four programmable Network-on-Chip (NoC) interface ports and is designed to handle multiple streams of traffic. The driver reports correctable and uncorrectable errors, and also creates debugfs entries for testing through error injection. [ bp: - Add a pointer to the documentation about the register unlock code. - Squash in a fix for a Smatch static checker issue as reported by Dan Carpenter: https://lore.kernel.org/r/a4db6f93-8e5f-4d55-a7b8-b5a987d48a58@moroto.mountain ] Co-developed-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231005101242.14621-3-shubhrajyoti.datta@amd.com
2023-10-23drm/amdkfd: reserve a fence slot while locking the BOChristian König1-1/+1
Looks like the KFD still needs this. Signed-off-by: Christian König <christian.koenig@amd.com> Fixes: 8abc1eb2987a ("drm/amdkfd: switch over to using drm_exec v3") Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231020123306.43978-1-christian.koenig@amd.com
2023-10-23Merge tag 'v6.6-rc7' into sched/core, to pick up fixesIngo Molnar400-1727/+3275
Pick up recent sched/urgent fixes merged upstream. Signed-off-by: Ingo Molnar <mingo@kernel.org>
2023-10-23isdn: mISDN: hfcsusb: Spelling fix in commentKunwu Chan1-1/+1
protocoll -> protocol Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22Merge tag 'phy-fixes-6.6' of ↵Linus Torvalds9-48/+57
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy fixes from Vinod Koul: - mapphone-mdm6600 runtime pm & pinctrl handling fixes - Qualcomm qmp usb pcs register fixes, qmp pcie register size warning fix, m31 fixes for wrong pointer in PTR_ERR and dropping wrong vreg check, qmp combo fix for 8550 power config register - realtek usb fix for debugfs_create_dir() and kconfig dependency * tag 'phy-fixes-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: realtek: Realtek PHYs should depend on ARCH_REALTEK phy: qualcomm: Fix typos in comments phy: qcom-qmp-combo: initialize PCS_USB registers phy: qcom-qmp-combo: Square out 8550 POWER_STATE_CONFIG1 phy: qcom: m31: Remove unwanted qphy->vreg is NULL check phy: realtek: usb: Drop unnecessary error check for debugfs_create_dir() phy: qcom: phy-qcom-m31: change m31_ipq5332_regs to static phy: qcom: phy-qcom-m31: fix wrong pointer pass to PTR_ERR() dt-bindings: phy: qcom,ipq8074-qmp-pcie: fix warning regarding reg size phy: qcom-qmp-usb: split PCS_USB init table for sc8280xp and sa8775p phy: qcom-qmp-usb: initialize PCS_USB registers phy: mapphone-mdm6600: Fix pinctrl_pm handling for sleep pins phy: mapphone-mdm6600: Fix runtime PM for remove phy: mapphone-mdm6600: Fix runtime disable on probe
2023-10-22Merge tag 'efi-fixes-for-v6.6-3' of ↵Linus Torvalds4-10/+71
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "The boot_params pointer fix uses a somewhat ugly extern struct declaration but this will be cleaned up the next cycle. - don't try to print warnings to the console when it is no longer available - fix theoretical memory leak in SSDT override handling - make sure that the boot_params global variable is set before the KASLR code attempts to hash it for 'randomness' - avoid soft lockups in the memory acceptance code" * tag 'efi-fixes-for-v6.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/unaccepted: Fix soft lockups caused by parallel memory acceptance x86/boot: efistub: Assign global boot_params variable efi: fix memory leak in krealloc failure handling x86/efistub: Don't try to print after ExitBootService()
2023-10-22ACPI: NFIT: Install Notify() handler before getting NFIT tableXiang Chen1-11/+11
If there is no NFIT at startup, it will return 0 immediately in function acpi_nfit_add() and will not install Notify() handler. If hotplugging a nvdimm device later, it will not be identified as there is no Notify() handler. Install the handler before getting NFI table in function acpi_nfit_add() to avoid above issue. Fixes: dcca12ab62a2 ("ACPI: NFIT: Install Notify() handler directly") Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-22r8152: Block future register access if register access failsDouglas Anderson1-31/+176
Even though the functions to read/write registers can fail, most of the places in the r8152 driver that read/write register values don't check error codes. The lack of error code checking is problematic in at least two ways. The first problem is that the r8152 driver often uses code patterns similar to this: x = read_register() x = x | SOME_BIT; write_register(x); ...with the above pattern, if the read_register() fails and returns garbage then we'll end up trying to write modified garbage back to the Realtek adapter. If the write_register() succeeds that's bad. Note that as of commit f53a7ad18959 ("r8152: Set memory to all 0xFFs on failed reg reads") the "garbage" returned by read_register() will at least be consistent garbage, but it is still garbage. It turns out that this problem is very serious. Writing garbage to some of the hardware registers on the Ethernet adapter can put the adapter in such a bad state that it needs to be power cycled (fully unplugged and plugged in again) before it can enumerate again. The second problem is that the r8152 driver generally has functions that are long sequences of register writes. Assuming everything will be OK if a random register write fails in the middle isn't a great assumption. One might wonder if the above two problems are real. You could ask if we would really have a successful write after a failed read. It turns out that the answer appears to be "yes, this can happen". In fact, we've seen at least two distinct failure modes where this happens. On a sc7180-trogdor Chromebook if you drop into kdb for a while and then resume, you can see: 1. We get a "Tx timeout" 2. The "Tx timeout" queues up a USB reset. 3. In rtl8152_pre_reset() we try to reinit the hardware. 4. The first several (2-9) register accesses fail with a timeout, then things recover. The above test case was actually fixed by the patch ("r8152: Increase USB control msg timeout to 5000ms as per spec") but at least shows that we really can see successful calls after failed ones. On a different (AMD) based Chromebook with a particular adapter, we found that during reboot tests we'd also sometimes get a transitory failure. In this case we saw -EPIPE being returned sometimes. Retrying worked, but retrying is not always safe for all register accesses since reading/writing some registers might have side effects (like registers that clear on read). Let's fully lock out all register access if a register access fails. When we do this, we'll try to queue up a USB reset and try to unlock register access after the reset. This is slightly tricker than it sounds since the r8152 driver has an optimized reset sequence that only works reliably after probe happens. In order to handle this, we avoid the optimized reset if probe didn't finish. Instead, we simply retry the probe routine in this case. When locking out access, we'll use the existing infrastructure that the driver was using when it detected we were unplugged. This keeps us from getting stuck in delay loops in some parts of the driver. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLEDouglas Anderson1-48/+48
Whenever the RTL8152_UNPLUG is set that just tells the driver that all accesses will fail and we should just immediately bail. A future patch will use this same concept at a time when the driver hasn't actually been unplugged but is about to be reset. Rename the flag in preparation for the future patch. This is a no-op change and just a search and replace. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en()Douglas Anderson1-0/+4
If the adapter is unplugged while we're looping in r8153b_ups_en() / r8153c_ups_en() we could end up looping for 10 seconds (20 ms * 500 loops). Add code similar to what's done in other places in the driver to check for unplug and bail. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Check for unplug in rtl_phy_patch_request()Douglas Anderson1-0/+3
If the adapter is unplugged while we're looping in rtl_phy_patch_request() we could end up looping for 10 seconds (2 ms * 5000 loops). Add code similar to what's done in other places in the driver to check for unplug and bail. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Release firmware if we have an error in probeDouglas Anderson1-0/+1
The error handling in rtl8152_probe() is missing a call to release firmware. Add it in to match what's in the cleanup code in rtl8152_disconnect(). Fixes: 9370f2d05a2a ("r8152: support request_firmware for RTL8153") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Cancel hw_phy_work if we have an error in probeDouglas Anderson1-0/+1
The error handling in rtl8152_probe() is missing a call to cancel the hw_phy_work. Add it in to match what's in the cleanup code in rtl8152_disconnect(). Fixes: a028a9e003f2 ("r8152: move the settings of PHY to a work queue") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Run the unload routine if we have errors during probeDouglas Anderson1-0/+2
The rtl8152_probe() function lacks a call to the chip-specific unload() routine when it sees an error in probe. Add it in to match the cleanup code in rtl8152_disconnect(). Fixes: ac718b69301c ("net/usb: new driver for RTL8152") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Increase USB control msg timeout to 5000ms as per specDouglas Anderson1-3/+4
According to the comment next to USB_CTRL_GET_TIMEOUT and USB_CTRL_SET_TIMEOUT, although sending/receiving control messages is usually quite fast, the spec allows them to take up to 5 seconds. Let's increase the timeout in the Realtek driver from 500ms to 5000ms (using the #defines) to account for this. This is not just a theoretical change. The need for the longer timeout was seen in testing. Specifically, if you drop a sc7180-trogdor based Chromebook into the kdb debugger and then "go" again after sitting in the debugger for a while, the next USB control message takes a long time. Out of ~40 tests the slowest USB control message was 4.5 seconds. While dropping into kdb is not exactly an end-user scenario, the above is similar to what could happen due to an temporary interrupt storm, what could happen if there was a host controller (HW or SW) issue, or what could happen if the Realtek device got into a confused state and needed time to recover. This change is fairly critical since the r8152 driver in Linux doesn't expect register reads/writes (which are backed by USB control messages) to fail. Fixes: ac718b69301c ("net/usb: new driver for RTL8152") Suggested-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22net: usb: smsc95xx: Fix uninit-value access in smsc95xx_read_regShigeru Yoshida1-1/+3
syzbot reported the following uninit-value access issue [1]: smsc95xx 1-1:0.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x00000030: -32 smsc95xx 1-1:0.0 (unnamed net_device) (uninitialized): Error reading E2P_CMD ===================================================== BUG: KMSAN: uninit-value in smsc95xx_reset+0x409/0x25f0 drivers/net/usb/smsc95xx.c:896 smsc95xx_reset+0x409/0x25f0 drivers/net/usb/smsc95xx.c:896 smsc95xx_bind+0x9bc/0x22e0 drivers/net/usb/smsc95xx.c:1131 usbnet_probe+0x100b/0x4060 drivers/net/usb/usbnet.c:1750 usb_probe_interface+0xc75/0x1210 drivers/usb/core/driver.c:396 really_probe+0x506/0xf40 drivers/base/dd.c:658 __driver_probe_device+0x2a7/0x5d0 drivers/base/dd.c:800 driver_probe_device+0x72/0x7b0 drivers/base/dd.c:830 __device_attach_driver+0x55a/0x8f0 drivers/base/dd.c:958 bus_for_each_drv+0x3ff/0x620 drivers/base/bus.c:457 __device_attach+0x3bd/0x640 drivers/base/dd.c:1030 device_initial_probe+0x32/0x40 drivers/base/dd.c:1079 bus_probe_device+0x3d8/0x5a0 drivers/base/bus.c:532 device_add+0x16ae/0x1f20 drivers/base/core.c:3622 usb_set_configuration+0x31c9/0x38c0 drivers/usb/core/message.c:2207 usb_generic_driver_probe+0x109/0x2a0 drivers/usb/core/generic.c:238 usb_probe_device+0x290/0x4a0 drivers/usb/core/driver.c:293 really_probe+0x506/0xf40 drivers/base/dd.c:658 __driver_probe_device+0x2a7/0x5d0 drivers/base/dd.c:800 driver_probe_device+0x72/0x7b0 drivers/base/dd.c:830 __device_attach_driver+0x55a/0x8f0 drivers/base/dd.c:958 bus_for_each_drv+0x3ff/0x620 drivers/base/bus.c:457 __device_attach+0x3bd/0x640 drivers/base/dd.c:1030 device_initial_probe+0x32/0x40 drivers/base/dd.c:1079 bus_probe_device+0x3d8/0x5a0 drivers/base/bus.c:532 device_add+0x16ae/0x1f20 drivers/base/core.c:3622 usb_new_device+0x15f6/0x22f0 drivers/usb/core/hub.c:2589 hub_port_connect drivers/usb/core/hub.c:5440 [inline] hub_port_connect_change drivers/usb/core/hub.c:5580 [inline] port_event drivers/usb/core/hub.c:5740 [inline] hub_event+0x53bc/0x7290 drivers/usb/core/hub.c:5822 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2703 worker_thread+0xf45/0x1490 kernel/workqueue.c:2784 kthread+0x3e8/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Local variable buf.i225 created at: smsc95xx_read_reg drivers/net/usb/smsc95xx.c:90 [inline] smsc95xx_reset+0x203/0x25f0 drivers/net/usb/smsc95xx.c:892 smsc95xx_bind+0x9bc/0x22e0 drivers/net/usb/smsc95xx.c:1131 CPU: 1 PID: 773 Comm: kworker/1:2 Not tainted 6.6.0-rc1-syzkaller-00125-ge42bebf6db29 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Workqueue: usb_hub_wq hub_event ===================================================== Similar to e9c65989920f ("net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg"), this issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested. sysbot reported similar uninit-value access issue [2]. The root cause is the same as mentioned above, and this patch addresses it as well. Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver") Reported-and-tested-by: syzbot+c74c24b43c9ae534f0e0@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+2c97a98a5ba9ea9c23bd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c74c24b43c9ae534f0e0 [1] Closes: https://syzkaller.appspot.com/bug?extid=2c97a98a5ba9ea9c23bd [2] Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22net: chelsio: cxgb4: add an error code check in t4_load_phy_fwSu Hui1-0/+2
t4_set_params_timeout() can return -EINVAL if failed, add check for this. Signed-off-by: Su Hui <suhui@nfschina.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22net: ieee802154: adf7242: Fix some potential buffer overflow in ↵Christophe JAILLET1-2/+3
adf7242_stats_show() strncat() usage in adf7242_debugfs_init() is wrong. The size given to strncat() is the maximum number of bytes that can be written, excluding the trailing NULL. Here, the size that is passed, DNAME_INLINE_LEN, does not take into account the size of "adf7242-" that is already in the array. In order to fix it, use snprintf() instead. Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22drm/amdgpu: Remove redundant call to priority_is_valid()Luben Tuikov1-7/+8
Remove a redundant call to amdgpu_ctx_priority_is_valid() from amdgpu_ctx_priority_permit(), which is called from amdgpu_ctx_init() which is called from amdgpu_ctx_alloc() which is called from amdgpu_ctx_ioctl(), where we've called amdgpu_ctx_priority_is_valid() already first thing in the function. Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20231018010359.30393-1-luben.tuikov@amd.com
2023-10-21Merge tag 'gpio-fixes-for-v6.6-rc7' of ↵Linus Torvalds2-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix interrupt handling in suspend and wakeup in gpio-vf610 - fix a bug on setting direction to output in gpio-vf610 - add a missing memset() in gpio ACPI code * tag 'gpio-fixes-for-v6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpiolib: acpi: Add missing memset(0) to acpi_get_gpiod_from_data() gpio: vf610: set value before the direction to avoid a glitch gpio: vf610: mask the gpio irq in system suspend and support wakeup
2023-10-21i2c: stm32f7: Fix PEC handling in case of SMBUS transfersAlain Volmat1-3/+6
In case of SMBUS byte read with PEC enabled, the whole transfer is split into two commands. A first write command, followed by a read command. The write command does not have any PEC byte and a PEC byte is appended at the end of the read command. (cf Read byte protocol with PEC in SMBUS specification) Within the STM32 I2C controller, handling (either sending or receiving) of the PEC byte is done via the PECBYTE bit in register CR2. Currently, the PECBYTE is set at the beginning of a transfer, which lead to sending a PEC byte at the end of the write command (hence losing the real last byte), and also does not check the PEC byte received during the read command. This patch corrects the function stm32f7_i2c_smbus_xfer_msg in order to only set the PECBYTE during the read command. Fixes: 9e48155f6bfe ("i2c: i2c-stm32f7: Add initial SMBus protocols support") Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> Acked-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-21i2c: muxes: i2c-mux-gpmux: Use of_get_i2c_adapter_by_node()Herve Codina1-1/+1
i2c-mux-gpmux uses the pair of_find_i2c_adapter_by_node() / i2c_put_adapter(). These pair alone is not correct to properly lock the I2C parent adapter. Indeed, i2c_put_adapter() decrements the module refcount while of_find_i2c_adapter_by_node() does not increment it. This leads to an underflow of the parent module refcount. Use the dedicated function, of_get_i2c_adapter_by_node(), to handle correctly the module refcount. Fixes: ac8498f0ce53 ("i2c: i2c-mux-gpmux: new driver") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Cc: stable@vger.kernel.org Acked-by: Peter Rosin <peda@axentia.se> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-21i2c: muxes: i2c-demux-pinctrl: Use of_get_i2c_adapter_by_node()Herve Codina1-1/+1
i2c-demux-pinctrl uses the pair of_find_i2c_adapter_by_node() / i2c_put_adapter(). These pair alone is not correct to properly lock the I2C parent adapter. Indeed, i2c_put_adapter() decrements the module refcount while of_find_i2c_adapter_by_node() does not increment it. This leads to an underflow of the parent module refcount. Use the dedicated function, of_get_i2c_adapter_by_node(), to handle correctly the module refcount. Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Cc: stable@vger.kernel.org Acked-by: Peter Rosin <peda@axentia.se> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-21i2c: muxes: i2c-mux-pinctrl: Use of_get_i2c_adapter_by_node()Herve Codina1-1/+1
i2c-mux-pinctrl uses the pair of_find_i2c_adapter_by_node() / i2c_put_adapter(). These pair alone is not correct to properly lock the I2C parent adapter. Indeed, i2c_put_adapter() decrements the module refcount while of_find_i2c_adapter_by_node() does not increment it. This leads to an underflow of the parent module refcount. Use the dedicated function, of_get_i2c_adapter_by_node(), to handle correctly the module refcount. Fixes: c4aee3e1b0de ("i2c: mux: pinctrl: remove platform_data") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Cc: stable@vger.kernel.org Acked-by: Peter Rosin <peda@axentia.se> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2023-10-21Merge tag 's390-6.6-4' of ↵Linus Torvalds1-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Fix IOMMU bitmap allocation in s390 PCI to avoid out of bounds access when IOMMU pages aren't a multiple of 64 - Fix kasan crashes when accessing DCSS mapping in memory holes by adding corresponding kasan zero shadow mappings - Fix a memory leak in css_alloc_subchannel in case dma_set_coherent_mask fails * tag 's390-6.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/pci: fix iommu bitmap allocation s390/kasan: handle DCSS mapping in memory holes s390/cio: fix a memleak in css_alloc_subchannel
2023-10-21Merge tag 'platform-drivers-x86-v6.6-5' of ↵Linus Torvalds9-31/+43
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: - Fix spurious brightness down presses on newer Asus laptop models - Fix backlight control not working on T2 Mac Pro all-in-ones - Add Armin Wolf as new maintainer for the WMI bus driver and change its status from orphaned to maintained - A few other small fixes * tag 'platform-drivers-x86-v6.6-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/mellanox: mlxbf-tmfifo: Fix a warning message apple-gmux: Hard Code max brightness for MMIO gmux platform/surface: platform_profile: Propagate error if profile registration fails platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events platform/x86: asus-wmi: Only map brightness codes when using asus-wmi backlight control platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2e platform/x86: wmi: Update MAINTAINERS entry platform/x86: msi-ec: Fix the 3rd config platform/x86: intel-uncore-freq: Conditionally create attribute for read frequency platform: mellanox: Fix a resource leak in an error handling path in probing flow
2023-10-21Merge tag 'usb-6.6-rc7' of ↵Linus Torvalds2-4/+13
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt fixes and ids from Greg KH: "Here are four small patches for USB and Thunderbolt for 6.6-rc7 that do the following: - new usb-serial device ids - thunderbolt driver fix for reported issue All of these have been in linux-next with no reported problems" * tag 'usb-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: serial: option: add Fibocom to DELL custom modem FM101R-GL USB: serial: option: add entry for Sierra EM9191 with new firmware USB: serial: option: add Telit LE910C4-WWX 0x1035 composition thunderbolt: Call tb_switch_put() once DisplayPort bandwidth request is finished
2023-10-21Merge tag 'iio-fixes-for-6.6b' of ↵Greg Kroah-Hartman4-39/+45
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: 2nd set of IIO fixes for the 6.6 cycle. Note, given timing my expectation is these will be queued for the 6.7 merge window but they could go quicker if the 6.6 cycle ends up being extended. afe: * Allow for channels with offset but no scale. In this case the scale can be assumed to be 1. adi,ad74115: * Add missing dt-binding constraint on number of reset-gpios. samsung,exynos: * Don't request touchscreen interrupt if it is not going to be used, getting rid of an incorrect resulting warning message. xilinx,xadc: * Avoid changing preset voltage and themperature thresholds as they are typicaly set as part of FPGA image building so should be left alone. * Fix wrong temperature offset and scale for some devices. * tag 'iio-fixes-for-6.6b' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: afe: rescale: Accept only offset channels iio: exynos-adc: request second interupt only when touchscreen mode is used iio: adc: xilinx-xadc: Correct temperature offset/scale for UltraScale iio: adc: xilinx-xadc: Don't clobber preset voltage/temperature thresholds dt-bindings: iio: add missing reset-gpios constrain
2023-10-21net: ethernet: adi: adin1110: Fix uninitialized variableDell Jin1-1/+1
The spi_transfer struct has to have all it's fields initialized to 0 in this case, since not all of them are set before starting the transfer. Otherwise, spi_sync_transfer() will sometimes return an error. Fixes: a526a3cc9c8d ("net: ethernet: adi: adin1110: Fix SPI transfers") Signed-off-by: Dell Jin <dell.jin.code@outlook.com> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-21net: stmmac: update MAC capabilities when tx queues are updatedMichael Sit Wei Hong1-4/+13
Upon boot up, the driver will configure the MAC capabilities based on the maximum number of tx and rx queues. When the user changes the tx queues to single queue, the MAC should be capable of supporting Half Duplex, but the driver does not update the MAC capabilities when it is configured so. Using the stmmac_reinit_queues() to check the number of tx queues and set the MAC capabilities accordingly. Fixes: 0366f7e06a6b ("net: stmmac: add ethtool support for get/set channels") Cc: <stable@vger.kernel.org> # 5.17+ Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> Signed-off-by: Gan, Yi Fang <yi.fang.gan@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-21net: xgene: Fix unused xgene_enet_of_match warning for !CONFIG_OFRob Herring1-1/+1
Commit b0377116decd ("net: ethernet: Use device_get_match_data()") dropped the unconditional use of xgene_enet_of_match resulting in this warning: drivers/net/ethernet/apm/xgene/xgene_enet_main.c:2004:34: warning: unused variable 'xgene_enet_of_match' [-Wunused-const-variable] The fix is to drop of_match_ptr() which is not necessary because DT is always used for this driver (well, it could in theory support ACPI only, but CONFIG_OF is always enabled for arm64). Fixes: b0377116decd ("net: ethernet: Use device_get_match_data()") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310170627.2Kvf6ZHY-lkp@intel.com/ Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-21fpga: disable KUnit test suites when module support is enabledMarco Pagani1-2/+2
The fpga core currently assumes that all manager, bridge, and region devices have a parent device associated with a driver that can be used to take the module's refcount. This behavior causes the fpga test suites to crash with a null-ptr-deref since parent fake devices do not have a driver. This patch disables all fpga KUnit test suites when loadable module support is enabled until the fpga core is fixed. Test suites can still be run using the KUnit default UML kernel. Signed-off-by: Marco Pagani <marpagan@redhat.com> Acked-by: Xu Yilun <yilun.xu@intel.com> Fixes: ccbc1c302115 ("fpga: add an initial KUnit suite for the FPGA Manager") Link: https://lore.kernel.org/r/20231018163814.100803-1-marpagan@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-21i40e: sync next_to_clean and next_to_process for programming status descTirthendu Sarkar1-1/+8
When a programming status desc is encountered on the rx_ring, next_to_process is bumped along with cleaned_count but next_to_clean is not. This causes I40E_DESC_UNUSED() macro to misbehave resulting in overwriting whole ring with new buffers. Update next_to_clean to point to next_to_process on seeing a programming status desc if not in the middle of handling a multi-frag packet. Also, bump cleaned_count only for such case as otherwise next_to_clean buffer may be returned to hardware on reaching clean_threshold. Fixes: e9031f2da1ae ("i40e: introduce next_to_process to i40e_ring") Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reported-by: hq.dev+kernel@msdfc.xyz Reported by: Solomon Peachy <pizza@shaftnet.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217678 Tested-by: hq.dev+kernel@msdfc.xyz Tested by: Indrek Järve <incx@dustbite.net> Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com> Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://lore.kernel.org/r/20231019203852.3663665-1-jacob.e.keller@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-21igc: Fix ambiguity in the ethtool advertisingSasha Neftin1-10/+25
The 'ethtool_convert_link_mode_to_legacy_u32' method does not allow us to advertise 2500M speed support and TP (twisted pair) properly. Convert to 'ethtool_link_ksettings_test_link_mode' to advertise supported speed and eliminate ambiguity. Fixes: 8c5ad0dae93c ("igc: Add ethtool support") Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Suggested-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20231019203641.3661960-1-jacob.e.keller@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-20Merge tag 'acpi-6.6-rc7' of ↵Linus Torvalds2-2/+7
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix the ACPI initialization ordering on ARM and ACPI IRQ management in the cases when irq_create_fwspec_mapping() fails. Specifics: - Fix ACPI initialization ordering on ARM that was changed incorrectly during the 6.5 development cycle (Hanjun Guo) - Make acpi_register_gsi() return an error code as appropriate when irq_create_fwspec_mapping() returns 0 on failure (Sunil V L)" * tag 'acpi-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: bus: Move acpi_arm_init() to the place of after acpi_ghes_init() ACPI: irq: Fix incorrect return value in acpi_register_gsi()
2023-10-20Merge tag 'scsi-fixes' of ↵Linus Torvalds2-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two small fixes, both in drivers. The mptsas one is really fixing an error path issue where it can leave the misc driver loaded even though the sas driver fails to initialize" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: qla2xxx: Fix double free of dsd_list during driver load scsi: mpt3sas: Fix in error path
2023-10-20Merge tag 'pinctrl-v6.6-3' of ↵Linus Torvalds2-15/+18
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Concurrent register updates in the Qualcomm LPASS pin controller gets a proper lock. - revert a mutex fix that was causing problems: contention on the mutex or something of the sort lead to probe reordering and MMC block devices start to register in a different order, which unsuspecting userspace is not ready to handle * tag 'pinctrl-v6.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: Revert "pinctrl: avoid unsafe code pattern in find_pinctrl()" pinctrl: qcom: lpass-lpi: fix concurrent register updates
2023-10-20Merge tag 'mtd/fixes-for-6.6-rc7' of ↵Linus Torvalds9-5/+67
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "In the raw NAND subsystem, the major fix prevents using cached reads with devices not supporting it. There was two bug reports about this. Apart from that, three drivers (pl353, arasan and marvell) could sometimes hide page program failures due to their their own program page helper not being fully compliant with the specification (many drivers use the default helpers shared by the core). Adding a missing check prevents these situation. Finally, the Qualcomm driver had a broken error path. In the SPI-NAND subsystem one Micron device used a wrong bitmak reporting possibly corrupted ECC status. Finally, the physmap-core got stripped from its map_rom fallback by mistake, this feature is added back" * tag 'mtd/fixes-for-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: Ensure the nand chip supports cached reads mtd: rawnand: qcom: Unmap the right resource upon probe failure mtd: rawnand: pl353: Ensure program page operations are successful mtd: rawnand: arasan: Ensure program page operations are successful mtd: spinand: micron: correct bitmask for ecc status mtd: physmap-core: Restore map_rom fallback mtd: rawnand: marvell: Ensure program page operations are successful
2023-10-20Merge tag 'mmc-v6.6-rc3' of ↵Linus Torvalds6-54/+98
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: "MMC core: - Capture correct oemid-bits for eMMC cards - Fix error propagation for some ioctl commands - Hold retuning if SDIO is in 1-bit mode MMC host: - mtk-sd: Use readl_poll_timeout_atomic to not "schedule while atomic" - sdhci-msm: Correct minimum number of clocks - sdhci-pci-gli: Fix LPM negotiation so x86/S0ix SoCs can suspend - sdhci-sprd: Fix error code in sdhci_sprd_tuning()" * tag 'mmc-v6.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: core: Capture correct oemid-bits for eMMC cards mmc: mtk-sd: Use readl_poll_timeout_atomic in msdc_reset_hw mmc: core: Fix error propagation for some ioctl commands mmc: sdhci-sprd: Fix error code in sdhci_sprd_tuning() mmc: sdhci-pci-gli: fix LPM negotiation so x86/S0ix SoCs can suspend mmc: core: sdio: hold retuning if sdio in 1-bit mode dt-bindings: mmc: sdhci-msm: correct minimum number of clocks
2023-10-20Merge tag 'block-6.6-2023-10-20' of git://git.kernel.dk/linuxLinus Torvalds6-14/+22
Pull block fixes from Jens Axboe: "A fix for a regression with sed-opal and saved keys, and outside of that an NVMe pull request fixing a few minor issues on that front" * tag 'block-6.6-2023-10-20' of git://git.kernel.dk/linux: nvme-pci: add BOGUS_NID for Intel 0a54 device nvmet-auth: complete a request only after freeing the dhchap pointers nvme: sanitize metadata bounce buffer for reads block: Fix regression in sed-opal for a saved key. nvme-auth: use chap->s2 to indicate bidirectional authentication nvmet-tcp: Fix a possible UAF in queue intialization setup nvme-rdma: do not try to stop unallocated queues
2023-10-20Merge tag 'drm-fixes-2023-10-20' of git://anongit.freedesktop.org/drm/drmLinus Torvalds21-68/+106
Pull drm fixes from Dave Airlie: "Regular fixes for the week, amdgpu, i915, nouveau, with some other scattered around, nothing major. amdgpu: - Fix possible NULL pointer dereference - Avoid possible BUG_ON in GPUVM updates - Disable AMD_CTX_PRIORITY_UNSET i915: - Fix display issue that was blocking S0ix - Retry gtt fault when out of fence registers bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup mediatek: - Correctly free sg_table in gem prime vmap" * tag 'drm-fixes-2023-10-20' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: Reserve fences for VM update drm/amdgpu: Fix possible null pointer dereference accel/ivpu: Extend address range for MMU mmap Revert "accel/ivpu: Use cached buffers for FW loading" accel/ivpu: Don't enter d0i3 during FLR drm/i915: Retry gtt fault when out of fence registers drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET drm/amdgpu: Unset context priority is now invalid drm/mediatek: Correctly free sg_table in gem prime vmap drm/edid: add 8 bpc quirk to the BenQ GW2765 drm/ttm: Reorder sys manager cleanup step drm/nouveau/disp: fix DP capable DSM connectors drm/nouveau: exec: fix ioctl kernel-doc warning drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device
2023-10-20Merge 3rd batch of EFI fixes into efi/urgentArd Biesheuvel4-10/+71
2023-10-20efi/unaccepted: Fix soft lockups caused by parallel memory acceptanceKirill A. Shutemov1-4/+60
Michael reported soft lockups on a system that has unaccepted memory. This occurs when a user attempts to allocate and accept memory on multiple CPUs simultaneously. The root cause of the issue is that memory acceptance is serialized with a spinlock, allowing only one CPU to accept memory at a time. The other CPUs spin and wait for their turn, leading to starvation and soft lockup reports. To address this, the code has been modified to release the spinlock while accepting memory. This allows for parallel memory acceptance on multiple CPUs. A newly introduced "accepting_list" keeps track of which memory is currently being accepted. This is necessary to prevent parallel acceptance of the same memory block. If a collision occurs, the lock is released and the process is retried. Such collisions should rarely occur. The main path for memory acceptance is the page allocator, which accepts memory in MAX_ORDER chunks. As long as MAX_ORDER is equal to or larger than the unit_size, collisions will never occur because the caller fully owns the memory block being accepted. Aside from the page allocator, only memblock and deferered_free_range() accept memory, but this only happens during boot. The code has been tested with unit_size == 128MiB to trigger collisions and validate the retry codepath. Fixes: 2053bc57f367 ("efi: Add unaccepted memory support") Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Michael Roth <michael.roth@amd.com Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Tested-by: Michael Roth <michael.roth@amd.com> [ardb: drop unnecessary cpu_relax() call] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>