summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-11-17drm/amdgpu/dm/dp_mst: Don't grab mst_mgr->lock when computing DSC stateLyude Paul
Now that we've fixed the issue with using the incorrect topology manager, we're actually grabbing the topology manager's lock - and consequently deadlocking. Luckily for us though, there's actually nothing in AMD's DSC state computation code that really should need this lock. The one exception is the mutex_lock() in dm_dp_mst_is_port_support_mode(), however we grab no locks beneath &mgr->lock there so that should be fine to leave be. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu/dm/mst: Use the correct topology mgr pointer in amdgpu_dm_connectorLyude Paul
This bug hurt me. Basically, it appears that we've been grabbing the entirely wrong mutex in the MST DSC computation code for amdgpu! While we've been grabbing: amdgpu_dm_connector->mst_mgr That's zero-initialized memory, because the only connectors we'll ever actually be doing DSC computations for are MST ports. Which have mst_mgr zero-initialized, and instead have the correct topology mgr pointer located at: amdgpu_dm_connector->mst_port->mgr; I'm a bit impressed that until now, this code has managed not to crash anyone's systems! It does seem to cause a warning in LOCKDEP though: [ 66.637670] DEBUG_LOCKS_WARN_ON(lock->magic != lock) This was causing the problems that appeared to have been introduced by: commit 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state") This wasn't actually where they came from though. Presumably, before the only thing we were doing with the topology mgr pointer was attempting to grab mst_mgr->lock. Since the above commit however, we grab much more information from mst_mgr including the atomic MST state and respective modesetting locks. This patch also implies that up until now, it's quite likely we could be susceptible to race conditions when going through the MST topology state for DSC computations since we technically will not have grabbed any lock when going through it. So, let's fix this by adjusting all the respective code paths to look at the right pointer and skip things that aren't actual MST connectors from a topology. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/display/dp_mst: Fix drm_dp_mst_add_affected_dsc_crtcs() return codeLyude Paul
Looks like that we're accidentally dropping a pretty important return code here. For some reason, we just return -EINVAL if we fail to get the MST topology state. This is wrong: error codes are important and should never be squashed without being handled, which here seems to have the potential to cause a deadlock. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs") Cc: <stable@vger.kernel.org> # v5.6+ Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu/mst: Stop ignoring error codes and deadlockingLyude Paul
It appears that amdgpu makes the mistake of completely ignoring the return values from the DP MST helpers, and instead just returns a simple true/false. In this case, it seems to have come back to bite us because as a result of simply returning false from compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a deadlock happened from these helpers. This could definitely result in some kernel splats. V2: * Address Wayne's comments (fix another bunch of spots where we weren't passing down return codes) Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: Harry Wentland <harry.wentland@amd.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amd/display: Align dcn314_smu logging with other DCNsRoman Li
[Why] Assert on non-OK response from SMU is unnecessary. It was replaced with respective log message on other asics in the past with commit: "drm/amd/display: Removing assert statements for Linux" [How] Remove assert and add dbg logging as on other DCNs. Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Saaem Rizvi <SyedSaaem.Rizvi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amd/display: fix the build when DRM_AMD_DC_DCN is not setAlex Deucher
Move the new callback outside of the guard. Fixes: dc55b106ad47 ("drm/amd/display: Disable phantom OTG after enable for plane disable") CC: Alvin Lee <Alvin.Lee2@amd.com> CC: Alan Liu <HaoPing.Liu@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-16tracing: Fix warning on variable 'struct trace_array'Aashish Sharma
Move the declaration of 'struct trace_array' out of #ifdef CONFIG_TRACING block, to fix the following warning when CONFIG_TRACING is not set: >> include/linux/trace.h:63:45: warning: 'struct trace_array' declared inside parameter list will not be visible outside of this definition or declaration Link: https://lkml.kernel.org/r/20221107160556.2139463-1-shraash@google.com Fixes: 1a77dd1c2bb5 ("scsi: tracing: Fix compile error in trace_array calls when TRACING is disabled") Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Arun Easi <aeasi@marvell.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Aashish Sharma <shraash@google.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-11-16tracing: Fix memory leak in tracing_read_pipe()Wang Yufen
kmemleak reports this issue: unreferenced object 0xffff888105a18900 (size 128): comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150 [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0 [<0000000065629d9d>] trace_event_printf+0xb6/0xf0 [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0 [<00000000d22db172>] print_trace_line+0x73c/0x1480 [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0 [<0000000015b58459>] vfs_read+0x17b/0x7c0 [<000000004aeee8ed>] ksys_read+0xed/0x1c0 [<0000000063d3d898>] do_syscall_64+0x3b/0x90 [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd iter->fmt alloced in tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not freed, to fix, add free in tracing_release_pipe() Link: https://lkml.kernel.org/r/1667819090-4643-1-git-send-email-wangyufen@huawei.com Cc: stable@vger.kernel.org Fixes: efbbdaa22bb7 ("tracing: Show real address for trace event arguments") Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-11-16ring-buffer: Include dropped pages in counting dirty patchesSteven Rostedt (Google)
The function ring_buffer_nr_dirty_pages() was created to find out how many pages are filled in the ring buffer. There's two running counters. One is incremented whenever a new page is touched (pages_touched) and the other is whenever a page is read (pages_read). The dirty count is the number touched minus the number read. This is used to determine if a blocked task should be woken up if the percentage of the ring buffer it is waiting for is hit. The problem is that it does not take into account dropped pages (when the new writes overwrite pages that were not read). And then the dirty pages will always be greater than the percentage. This makes the "buffer_percent" file inaccurate, as the number of dirty pages end up always being larger than the percentage, event when it's not and this causes user space to be woken up more than it wants to be. Add a new counter to keep track of lost pages, and include that in the accounting of dirty pages so that it is actually accurate. Link: https://lkml.kernel.org/r/20221021123013.55fb6055@gandalf.local.home Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-11-16dm-log-writes: set dma_alignment limit in io_hintsKeith Busch
This device mapper needs bio vectors to be sized and memory aligned to the logical block size. Set the minimum required queue limit accordingly. Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Mike Snitzer <snitzer@kernel.org> Link: https://lore.kernel.org/r/20221110184501.2451620-6-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-11-16dm-integrity: set dma_alignment limit in io_hintsKeith Busch
This device mapper needs bio vectors to be sized and memory aligned to the logical block size. Set the minimum required queue limit accordingly. Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Mike Snitzer <snitzer@kernel.org> Link: https://lore.kernel.org/r/20221110184501.2451620-5-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-11-16block: make blk_set_default_limits() privateKeith Busch
There are no external users of this function. Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20221110184501.2451620-4-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-11-16dm-crypt: provide dma_alignment limit in io_hintsKeith Busch
This device mapper needs bio vectors to be sized and memory aligned to the logical block size. Set the minimum required queue limit accordingly. Link: https://lore.kernel.org/linux-block/20221101001558.648ee024@xps.demsh.org/ Fixes: b1a000d3b8ec5 ("block: relax direct io memory alignment") Reportred-by: Eric Biggers <ebiggers@kernel.org> Reported-by: Dmitrii Tcvetkov <me@demsh.org> Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Mike Snitzer <snitzer@kernel.org> Link: https://lore.kernel.org/r/20221110184501.2451620-3-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-11-16block: make dma_alignment a stacking queue_limitKeith Busch
Device mappers had always been getting the default 511 dma mask, but the underlying device might have a larger alignment requirement. Since this value is used to determine alloweable direct-io alignment, this needs to be a stackable limit. Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20221110184501.2451620-2-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-11-16tracing/ring-buffer: Have polling block on watermarkSteven Rostedt (Google)
Currently the way polling works on the ring buffer is broken. It will return immediately if there's any data in the ring buffer whereas a read will block until the watermark (defined by the tracefs buffer_percent file) is hit. That is, a select() or poll() will return as if there's data available, but then the following read will block. This is broken for the way select()s and poll()s are supposed to work. Have the polling on the ring buffer also block the same way reads and splice does on the ring buffer. Link: https://lkml.kernel.org/r/20221020231427.41be3f26@gandalf.local.home Cc: Linux Trace Kernel <linux-trace-kernel@vger.kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Primiano Tucci <primiano@google.com> Cc: stable@vger.kernel.org Fixes: 1e0d6714aceb7 ("ring-buffer: Do not wake up a splice waiter when page is not full") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-11-16Merge tag 'imx-fixes-6.1-2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.1, 2nd round: - Switch to usb-role-switch for fixing USB device mode on tqma8mqml-mba8mx board, so that Dual Role is fully functional. - A series from Marek Vasut to fix dt-schema warning caused by NAND controller size-cells. - Fix file permission of imx93-pinfunc header. - Enable OCOTP clock in soc-imx8m driver to fix a kexec kernel hang issue. * tag 'imx-fixes-6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: soc: imx8m: Enable OCOTP clock before reading the register arm64: dts: imx93-pinfunc: drop execution permission arm64: dts: imx8mn: Fix NAND controller size-cells arm64: dts: imx8mm: Fix NAND controller size-cells ARM: dts: imx7: Fix NAND controller size-cells arm64: dts: imx8mm-tqma8mqml-mba8mx: Fix USB DR Link: https://lore.kernel.org/r/20221116090402.GA1274@T480 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-11-16Merge tag 'hisi-maintainer-fix' of https://github.com/hisilicon/linux-hisi ↵Arnd Bergmann
into arm/fixes MAINTAINERS file updates for HiSilicon sections - Use https instead of git for the git trees listed * tag 'hisi-maintainer-fix' of https://github.com/hisilicon/linux-hisi: MAINTAINERS: git://github.com -> https://github.com for HiSilicon Link: https://lore.kernel.org/r/63744BAB.5020307@hisilicon.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-11-16drm/etnaviv: switch to PFN mappingsLucas Stach
There is no reason to use page based mappings, as the established mappings are special driver mappings anyways and should not be handled like normal pages. Be consistent with what other drivers do and use raw PFN based mappings. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2022-11-16drm/etnaviv: add HWDB entry for GC7000 r6203Marco Felsch
The GPU is found on the NXP i.MX8MN SoC. The feature bits are taken from the NXP downstream kernel driver 6.4.3.p2. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2022-11-16netdevsim: Fix memory leak of nsim_dev->fa_cookieWang Yufen
kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove(). Fixes: d3cbb907ae57 ("netdevsim: add ACL trap reporting cookie as a metadata") Signed-off-by: Wang Yufen <wangyufen@huawei.com> Cc: Jiri Pirko <jiri@mellanox.com> Link: https://lore.kernel.org/r/1668504625-14698-1-git-send-email-wangyufen@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-16Merge tag 'for-linus-6.1-rc6-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: "Two trivial cleanups, and three simple fixes" * tag 'for-linus-6.1-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/platform-pci: use define instead of literal number xen/platform-pci: add missing free_irq() in error path xen-pciback: Allow setting PCI_MSIX_FLAGS_MASKALL too xen/pcpu: fix possible memory leak in register_pcpu() x86/xen: Use kstrtobool() instead of strtobool()
2022-11-16Merge tag 'pinctrl-v6.1-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Aere is a hopefully final round of pin control fixes. Nothing special, driver fixes and we caught a potential NULL pointer exception. - Fix a potential NULL dereference in the core! - Fix all pin mux routes in the Rockchop PX30 driver - Fix the UFS pins in the Qualcomm SC8280XP driver - Fix bias disabling in the Mediatek driver - Fix debounce time settings in the Mediatek driver" * tag 'pinctrl-v6.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: mediatek: Export debounce time tables pinctrl: mediatek: Fix EINT pins input debounce time configuration pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map pinctrl: mediatek: common-v2: Fix bias-disable for PULL_PU_PD_RSEL_TYPE pinctrl: qcom: sc8280xp: Rectify UFS reset pins pinctrl: rockchip: list all pins in a possible mux route for PX30
2022-11-16Merge tag 'platform-drivers-x86-v6.1-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: - Surface Pro 9 and Surface Laptop 5 kbd, battery, etc support (this is just a few hw-id additions) - A couple of other hw-id / DMI-quirk additions - A few small bug fixes + 1 build fix * tag 'platform-drivers-x86-v6.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: ideapad-laptop: Add module parameters to match DMI quirk tables platform/x86: ideapad-laptop: Fix interrupt storm on fn-lock toggle on some Yoga laptops platform/x86: hp-wmi: Ignore Smart Experience App event platform/surface: aggregator_registry: Add support for Surface Laptop 5 platform/surface: aggregator_registry: Add support for Surface Pro 9 platform/surface: aggregator: Do not check for repeated unsequenced packets platform/x86: acer-wmi: Enable SW_TABLET_MODE on Switch V 10 (SW5-017) platform/x86: asus-wmi: add missing pci_dev_put() in asus_wmi_set_xusb2pr() platform/x86/intel: pmc: Don't unconditionally attach Intel PMC when virtualized platform/x86: thinkpad_acpi: Enable s2idle quirk for 21A1 machine type platform/x86/amd: pmc: Add new ACPI ID AMDI0009 platform/x86/amd: pmc: Remove more CONFIG_DEBUG_FS checks
2022-11-16cifs: add check for returning value of SMB2_set_info_initAnastasia Belova
If the returning value of SMB2_set_info_init is an error-value, exit the function. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 0967e5457954 ("cifs: use a compound for setting an xattr") Signed-off-by: Anastasia Belova <abelova@astralinux.ru> Signed-off-by: Steve French <stfrench@microsoft.com>
2022-11-16drm/i915/guc: add the GSC CS to the GuC capture listDaniele Ceraolo Spurio
For the GSC engine we only want to capture the instance regs. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221111001832.4144910-1-daniele.ceraolospurio@intel.com
2022-11-16drm/i915/pxp: Separate PXP FW interface structures for both v42 and 43Alan Previn
Previously, we only used PXP FW interface version-42 structures for PXP arbitration session on ADL/TGL products and version-43 for HuC authentication on DG2. That worked fine despite not differentiating such versioning of the PXP firmware interaction structures. This was okay back then because the only commands used via version 42 was not used via version 43 and vice versa. With MTL, we'll need both these versions side by side for the same commands (PXP-session) with the older platform feature support. That said, let's create separate files to define the structures and definitions for both version-42 and 43 of PXP FW interfaces. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221108045628.4187260-2-alan.previn.teres.alexis@intel.com
2022-11-16USB: serial: option: add u-blox LARA-L6 modemDavide Tronchin
Add LARA-L6 PIDs for three different USB compositions. LARA-L6 module can be configured (by AT interface) in three different USB modes: * Default mode (Vendor ID: 0x1546 Product ID: 0x1341) with 4 serial interfaces * RmNet mode (Vendor ID: 0x1546 Product ID: 0x1342) with 4 serial interfaces and 1 RmNet virtual network interface * CDC-ECM mode (Vendor ID: 0x1546 Product ID: 0x1343) with 4 serial interface and 1 CDC-ECM virtual network interface In default mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parser/alternative functions In RmNet mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parset/alternative functions If 4: RMNET interface In CDC-ECM mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parset/alternative functions If 4: CDC-ECM interface Signed-off-by: Davide Tronchin <davide.tronchin.94@gmail.com> [ johan: drop PID defines in favour of comments ] Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2022-11-16USB: serial: option: add u-blox LARA-R6 00B modemDavide Tronchin
The official LARA-R6 (00B) modem uses 0x908b PID. LARA-R6 00B does not implement a QMI interface on port 4, the reservation (RSVD(4)) has been added to meet other companies that implement QMI on that interface. LARA-R6 00B USB composition exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parser/alternative functions Signed-off-by: Davide Tronchin <davide.tronchin.94@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2022-11-16USB: serial: option: remove old LARA-R6 PIDDavide Tronchin
Remove the UBLOX_PRODUCT_R6XX 0x90fa association since LARA-R6 00B final product uses a new USB composition with different PID. 0x90fa PID used only by LARA-R6 internal prototypes. Move 0x90fa PID directly in the option_ids array since used by other Qualcomm based modem vendors as pointed out in: https://lore.kernel.org/all/6572c4e6-d8bc-b8d3-4396-d879e4e76338@gmail.com Signed-off-by: Davide Tronchin <davide.tronchin.94@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2022-11-16mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()Xiongfeng Wang
pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case. Fixes: 659c9bc114a8 ("mmc: sdhci-pci: Build o2micro support in the same module") Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221114083100.149200-1-wangxiongfeng2@huawei.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-11-16drm/tests: helpers: Add module infosMaxime Ripard
The MODULE_LICENSE macro is missing from the kunit helpers file, thus leading to a build error. Let's introduce it along with MODULE_AUTHOR. Fixes: 44a3928324e9 ("drm/tests: Add Kunit Helpers") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Maíra Canal <mairacanal@riseup.net> Link: https://lore.kernel.org/r/20221116091712.1309651-2-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-16drm/tests: Include helpers headerMaxime Ripard
The kunit helpers code weren't including its header, leading to a warning that no previous prototype had been defined for public functions. Include the matching header to fix the warning. Fixes: 44a3928324e9 ("drm/tests: Add Kunit Helpers") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Maíra Canal <mairacanal@riseup.net> Link: https://lore.kernel.org/r/20221116091712.1309651-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-16tcp: configurable source port perturb table sizeGleb Mazovetskiy
On embedded systems with little memory and no relevant security concerns, it is beneficial to reduce the size of the table. Reducing the size from 2^16 to 2^8 saves 255 KiB of kernel RAM. Makes the table size configurable as an expert option. The size was previously increased from 2^8 to 2^16 in commit 4c2c8f03a5ab ("tcp: increase source port perturb table to 2^16"). Signed-off-by: Gleb Mazovetskiy <glex.spb@gmail.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-16mmc: sdhci-pci-o2micro: fix card detect fail issue caused by CD# debounce ↵Chevron Li
timeout The SD card is recognized failed sometimes when resume from suspend. Because CD# debounce time too long then card present report wrong. Finally, card is recognized failed. Signed-off-by: Chevron Li <chevron.li@bayhubtech.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221104095512.4068-1-chevron.li@bayhubtech.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-11-16mmc: core: properly select voltage range without power cycleYann Gautier
In mmc_select_voltage(), if there is no full power cycle, the voltage range selected at the end of the function will be on a single range (e.g. 3.3V/3.4V). To keep a range around the selected voltage (3.2V/3.4V), the mask shift should be reduced by 1. This issue was triggered by using a specific SD-card (Verbatim Premium 16GB UHS-1) on an STM32MP157C-DK2 board. This board cannot do UHS modes and there is no power cycle. And the card was failing to switch to high-speed mode. When adding the range 3.2V/3.3V for this card with the proposed shift change, the card can switch to high-speed mode. Fixes: ce69d37b7d8f ("mmc: core: Prevent violation of specs while initializing cards") Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221028073740.7259-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-11-16drm/edid/firmware: stop using a throwaway platform deviceJani Nikula
We've used a temporary platform device for firmware EDID loading since it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as firmware to override broken monitor"), but there's no explanation why. Using a temporary device does not play well with CONFIG_FW_CACHE=y, which caches firmware images (e.g. on suspend) so that drivers can request firmware when the system is not ready for it, and return the images from the cache (e.g. during resume). This works automatically for regular devices, but obviously not for a temporarily created device. Stop using the throwaway platform device, and use the drm device instead. Note that this may still be problematic for cases where the display was plugged in during suspend, and the firmware wasn't loaded and therefore not cached before suspend. References: https://lore.kernel.org/r/20220727074152.43059-1-matthieu.charette@gmail.com Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061 Reported-by: Matthieu CHARETTE <matthieu.charette@gmail.com> Tested-by: Matthieu CHARETTE <matthieu.charette@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221114111709.434979-1-jani.nikula@intel.com
2022-11-16l2tp: Serialize access to sk_user_data with sk_callback_lockJakub Sitnicki
sk->sk_user_data has multiple users, which are not compatible with each other. Writers must synchronize by grabbing the sk->sk_callback_lock. l2tp currently fails to grab the lock when modifying the underlying tunnel socket fields. Fix it by adding appropriate locking. We err on the side of safety and grab the sk_callback_lock also inside the sk_destruct callback overridden by l2tp, even though there should be no refs allowing access to the sock at the time when sk_destruct gets called. v4: - serialize write to sk_user_data in l2tp sk_destruct v3: - switch from sock lock to sk_callback_lock - document write-protection for sk_user_data v2: - update Fixes to point to origin of the bug - use real names in Reported/Tested-by tags Cc: Tom Parkin <tparkin@katalix.com> Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core") Reported-by: Haowei Yan <g1042620637@gmail.com> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-16fbdev: Add support for the nomodeset kernel parameterThomas Zimmermann
Support the kernel's nomodeset parameter for all PCI-based fbdev drivers that use aperture helpers to remove other, hardware-agnostic graphics drivers. The parameter is a simple way of using the firmware-provided scanout buffer if the hardware's native driver is broken. The same effect could be achieved with per-driver options, but the importance of the graphics output for many users makes a single, unified approach worthwhile. With nomodeset specified, the fbdev driver module will not load. This unifies behavior with similar DRM drivers. In DRM helpers, modules first check the nomodeset parameter before registering the PCI driver. As fbdev has no such module helpers, we have to modify each driver individually. The name 'nomodeset' is slightly misleading, but has been chosen for historical reasons. Several drivers implemented it before it became a general option for DRM. So keeping the existing name was preferred over introducing a new one. v2: * print a warning if a driver does not init (Helge) * wrap video_firmware_drivers_only() in helper Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221111133024.9897-3-tzimmermann@suse.de
2022-11-16drm: Move nomodeset kernel parameter to drivers/videoThomas Zimmermann
Move the nomodeset kernel parameter to drivers/video to make it available to non-DRM drivers. Adapt the interface, but keep the DRM interface drm_firmware_drivers_only() to avoid churn within DRM. The function should later be inlined into callers. The parameter disables any DRM graphics driver that would replace a driver for firmware-provided scanout buffers. It is an option to easily fallback to basic graphics output if the hardware's native driver is broken. Moving it to a more prominent location wil make it available to fbdev as well. v2: * clarify the meaning of the nomodeset parameter (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221111133024.9897-2-tzimmermann@suse.de
2022-11-16drm/fb-helper: Remove damage workerThomas Zimmermann
The fbdev damage worker is unused, so remove it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-7-tzimmermann@suse.de
2022-11-16drm/fb-helper: Schedule deferred-I/O worker after writing to framebufferThomas Zimmermann
Schedule the deferred-I/O worker instead of the damage worker after writing to the fbdev framebuffer. The deferred-I/O worker then performs the dirty-fb update. The fbdev emulation will initialize deferred I/O for all drivers that require damage updates. It is therefore a valid assumption that the deferred-I/O worker is present. It would be possible to perform the damage handling directly from within the write operation. But doing this could increase the overhead of the write or interfere with a concurrently scheduled deferred-I/O worker. Instead, scheduling the deferred-I/O worker with its regular delay of 50 ms removes load off the write operation and allows the deferred-I/O worker to handle multiple write operations that arrived during the delay time window. v3: * remove unused variable (lkp) v2: * keep drm_fb_helper_damage() (Daniel) * use fb_deferred_io_schedule_flush() (Daniel) * clarify comments (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-6-tzimmermann@suse.de
2022-11-16drm/fb-helper: Perform damage handling in deferred-I/O helperThomas Zimmermann
Call fb_dirty directly from drm_fb_helper_deferred_io() to avoid the latency of running the damage worker. The deferred-I/O helper drm_fb_helper_deferred_io() runs in a worker thread at regular intervals as part of writing to mmaped framebuffer memory. It used to schedule the fbdev damage worker to flush the framebuffer. Changing this to flushing the framebuffer directly avoids the latency introduced by the damage worker. v2: * remove fb_dirty from defio in separate patch (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-5-tzimmermann@suse.de
2022-11-16drm/fb-helper: Remove test for fb_dirty callback from deferred-I/O helperThomas Zimmermann
The helper for processing deferred I/O on pages has no dependency on the fb_dirty damge-handling callback; so remove the test. In practice, deferred I/O is only used with damage handling and the damage worker already guarantees the presence of the fb_dirty callback. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-4-tzimmermann@suse.de
2022-11-16drm/fb-helper: Move dirty-fb update into helper functionThomas Zimmermann
Move the dirty-fb update from the damage-worker callback into the new helper drm_fb_helper_fb_dirty(), so that it can run outside the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-3-tzimmermann@suse.de
2022-11-16drm/fb-helper: Set damage-clip area in helperThomas Zimmermann
Set the damage area in the new helper drm_fb_helper_add_damage_clip(). It can now be updated without scheduling the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-2-tzimmermann@suse.de
2022-11-16drm/fourcc: Fix vsub/hsub for Q410 and Q401Brian Starkey
These formats are not subsampled, but that means hsub and vsub should be 1, not 0. Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats") Reported-by: George Kennedy <george.kennedy@oracle.com> Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com> Signed-off-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220913144306.17279-1-brian.starkey@arm.com
2022-11-16s390: avoid using global register for current_stack_pointerVasily Gorbik
Commit 30de14b1884b ("s390: current_stack_pointer shouldn't be a function") made current_stack_pointer a global register variable like on many other architectures. Unfortunately on s390 it uncovers old gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87 ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")] and backported to gcc-8.4 and later. Due to this bug gcc versions prior to 8.4 generate broken code which leads to stack corruptions. Current minimal gcc version required to build the kernel is declared as 5.1. It is not possible to fix all old gcc versions, so work around this problem by avoiding using global register variable for current_stack_pointer. Fixes: 30de14b1884b ("s390: current_stack_pointer shouldn't be a function") Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2022-11-16s390/dcssblk: fix deadlock when adding a DCSSGerald Schaefer
After the rework from commit 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT"), when calling device_add_disk(), dcssblk will end up in disk_scan_partitions(), and not break out early w/o GENHD_FL_NO_PART. This will trigger implicit open/release via blkdev_get/put_whole() later. dcssblk_release() will then deadlock on dcssblk_devices_sem semaphore, which is already held from dcssblk_add_store() when calling device_add_disk(). dcssblk does not support partitions (DCSSBLK_MINORS_PER_DISK == 1), and never scanned partitions before. Therefore restore the previous behavior, and explicitly disallow partition scanning by setting the GENHD_FL_NO_PART flag. This will also prevent this deadlock scenario. Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT") Cc: <stable@vger.kernel.org> # 5.17+ Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2022-11-16powerpc: Fix writable sections being moved into the rodata regionNicholas Piggin
.data.rel.ro* catches .data.rel.root_cpuacct, and the kernel crashes on a store in css_clear_dir. At least we know read-only data protection is working... Fixes: b6adc6d6d3272 ("powerpc/build: move .data.rel.ro, .sdata2 to read-only") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20221116043954.3307852-1-npiggin@gmail.com
2022-11-16drm/arm/malidp: remove calls to drm_mode_config_cleanup()Danilo Krummrich
drm_mode_config_init() simply calls drmm_mode_config_init(), hence cleanup is automatically handled through registering drm_mode_config_cleanup() with drmm_add_action_or_reset(). While at it, get rid of the deprecated drm_mode_config_init() and replace it with drmm_mode_config_init() directly. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026155934.125294-6-dakr@redhat.com
generated by cgit (git 2.34.1) at 2025-09-11 16:38:48 +0000