summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-01-27Merge tag 'block-6.2-2023-01-27' of git://git.kernel.dk/linuxLinus Torvalds
Pull block fixes from Jens Axboe: "Minor tweaks for this release: - NVMe pull request via Christoph: - Flush initial scan_work for async probe (Keith Busch) - Fix passthrough csi check (Keith Busch) - Fix nvme-fc initialization order (Ross Lagerwall) - Fix for tearing down non-started device in ublk (Ming)" * tag 'block-6.2-2023-01-27' of git://git.kernel.dk/linux: block: ublk: move ublk_chr_class destroying after devices are removed nvme: fix passthrough csi check nvme-pci: flush initial scan_work for async probe nvme-fc: fix initialization order
2023-01-27Merge tag 'hardening-v6.2-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull hardening fixes from Kees Cook: - Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST - Reorganize gcc-plugin includes for GCC 13 - Silence bcache memcpy run-time false positive warnings * tag 'hardening-v6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: bcache: Silence memcpy() run-time false positive warnings gcc-plugins: Reorganize gimple includes for GCC 13 kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST
2023-01-27Merge tag 'i2c-for-6.2-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "A bunch of driver fixes with a tiny bit of new IDs" * tag 'i2c-for-6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: rk3x: fix a bunch of kernel-doc warnings i2c: axxia: use 'struct' for kernel-doc notation dt-bindings: i2c: renesas,rzv2m: Fix SoC specific string i2c: mxs: suppress probe-deferral error message i2c: designware-pci: Add new PCI IDs for AMD NAVI GPU i2c: designware: Fix unbalanced suspended flag i2c: designware: use casting of u64 in clock multiplication to avoid overflow
2023-01-27Merge tag 'gpio-fixes-for-v6.2-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix the -c option in the gpio-event-mode user-space example program - fix the irq number translation in gpio-ep93xx and make its irqchip immutable - add a missing spin_unlock in error path in gpio-mxc - fix a suspend breakage on System76 and Lenovo Gen2a introduced in GPIO ACPI * tag 'gpio-fixes-for-v6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: tools: gpio: fix -c option of gpio-event-mon gpio: ep93xx: remove unused variable gpio: ep93xx: Make irqchip immutable gpio: ep93xx: Fix port F hwirq numbers in handler gpio: mxc: Unlock on error path in mxc_flip_edge() gpiolib-acpi: Don't set GPIOs for wakeup in S3 mode
2023-01-27Merge tag 'drm-fixes-2023-01-27' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "Fairly small this week as well, i915 has a memory leak fix and some minor changes, and amdgpu has some MST fixes, and some other minor ones: drm: - DP MST kref fix - fb_helper: check return value i915: - Fix BSC default context for Meteor Lake - Fix selftest-scheduler's modify_type - memory leak fix amdgpu: - GC11.x fixes - SMU13.0.0 fix - Freesync video fix - DP MST fixes - build fix" * tag 'drm-fixes-2023-01-27' of git://anongit.freedesktop.org/drm/drm: amdgpu: fix build on non-DCN platforms. drm/amd/display: Fix timing not changning when freesync video is enabled drm/display/dp_mst: Correct the kref of port. drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD drm/amdgpu/display/mst: limit payload to be updated one by one drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments drm/amdgpu: declare firmware for new MES 11.0.4 drm/amdgpu: enable imu firmware for GC 11.0.4 drm/amd/pm: add missing AllowIHInterrupt message mapping for SMU13.0.0 drm/amdgpu: remove unconditional trap enable on add gfx11 queues drm/fb-helper: Use a per-driver FB deferred I/O handler drm/fb-helper: Check fb_deferred_io_init() return value drm/i915/selftest: fix intel_selftest_modify_policy argument types drm/i915/mtl: Fix bcs default context drm/i915: Fix a memory leak with reused mmap_offset drm/drm_vma_manager: Add drm_vma_node_allow_once()
2023-01-27Merge tag 'acpi-6.2-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "Add ACPI backlight handling quirks for 3 machines (Hans de Goede)" * tag 'acpi-6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: video: Add backlight=native DMI quirk for Asus U46E ACPI: video: Add backlight=native DMI quirk for HP EliteBook 8460p ACPI: video: Add backlight=native DMI quirk for HP Pavilion g6-1d80nr
2023-01-27Merge tag 'thermal-6.2-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "Add locking to the Intel int340x thermal control driver to prevent its thermal zone callbacks from racing with firmware-induced thermal trip point updates (Srinivas Pandruvada, Rafael Wysocki)" * tag 'thermal-6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: intel: int340x: Add locking to int340x_thermal_get_trip_type() thermal: intel: int340x: Protect trip temperature from concurrent updates
2023-01-27Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Will Deacon: - Fix event counting regression in Arm CMN PMU driver due to broken optimisation * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: Partially revert "perf/arm-cmn: Optimise DTC counter accesses"
2023-01-27crypto: hisilicon: Wipe entire pool on errorKees Cook
To work around a Clang __builtin_object_size bug that shows up under CONFIG_FORTIFY_SOURCE and UBSAN_BOUNDS, move the per-loop-iteration mem_block wipe into a single wipe of the entire pool structure after the loop. Reported-by: Nathan Chancellor <nathan@kernel.org> Link: https://github.com/ClangBuiltLinux/linux/issues/1780 Cc: Weili Qian <qianweili@huawei.com> Cc: Zhou Wang <wangzhou1@hisilicon.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Link: https://lore.kernel.org/r/20230106041945.never.831-kees@kernel.org
2023-01-27net/i40e: Replace 0-length array with flexible arrayKees Cook
Zero-length arrays are deprecated[1]. Replace struct i40e_lump_tracking's "list" 0-length array with a flexible array. Detected with GCC 13, using -fstrict-flex-arrays=3: In function 'i40e_put_lump', inlined from 'i40e_clear_interrupt_scheme' at drivers/net/ethernet/intel/i40e/i40e_main.c:5145:2: drivers/net/ethernet/intel/i40e/i40e_main.c:278:27: warning: array subscript <unknown> is outside array bounds of 'u16[0]' {aka 'short unsigned int[]'} [-Warray-bounds=] 278 | pile->list[i] = 0; | ~~~~~~~~~~^~~ drivers/net/ethernet/intel/i40e/i40e.h: In function 'i40e_clear_interrupt_scheme': drivers/net/ethernet/intel/i40e/i40e.h:179:13: note: while referencing 'list' 179 | u16 list[0]; | ^~~~ [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Tony Nguyen <anthony.l.nguyen@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230105234557.never.799-kees@kernel.org
2023-01-27i915/gvt: Replace one-element array with flexible-array memberPaulo Miguel Almeida
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct gvt_firmware_header and refactor the rest of the code accordingly. Additionally, previous implementation was allocating 8 bytes more than required to represent firmware_header + cfg_space data + mmio data. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. To make reviewing this patch easier, I'm pasting before/after struct sizes. pahole -C gvt_firmware_header before/drivers/gpu/drm/i915/gvt/firmware.o struct gvt_firmware_header { u64 magic; /* 0 8 */ u32 crc32; /* 8 4 */ u32 version; /* 12 4 */ u64 cfg_space_size; /* 16 8 */ u64 cfg_space_offset; /* 24 8 */ u64 mmio_size; /* 32 8 */ u64 mmio_offset; /* 40 8 */ unsigned char data[1]; /* 48 1 */ /* size: 56, cachelines: 1, members: 8 */ /* padding: 7 */ /* last cacheline: 56 bytes */ }; pahole -C gvt_firmware_header after/drivers/gpu/drm/i915/gvt/firmware.o struct gvt_firmware_header { u64 magic; /* 0 8 */ u32 crc32; /* 8 4 */ u32 version; /* 12 4 */ u64 cfg_space_size; /* 16 8 */ u64 cfg_space_offset; /* 24 8 */ u64 mmio_size; /* 32 8 */ u64 mmio_offset; /* 40 8 */ unsigned char data[]; /* 48 0 */ /* size: 48, cachelines: 1, members: 8 */ /* last cacheline: 48 bytes */ }; As you can see the additional byte of the fake-flexible array (data[1]) forced the compiler to pad the struct but those bytes aren't actually used as first & last bytes (of both cfg_space and mmio) are controlled by the <>_size and <>_offset members present in the gvt_firmware_header struct. Link: https://github.com/KSPP/linux/issues/79 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/Y6Eu2604cqtryP4g@mail.google.com
2023-01-27drm/nouveau/disp: Fix nvif_outp_acquire_dp() argument sizeKees Cook
Both Coverity and GCC with -Wstringop-overflow noticed that nvif_outp_acquire_dp() accidentally defined its second argument with 1 additional element: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_pior_atomic_enable': drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error: 'nvif_outp_acquire_dp' accessing 16 bytes in a region of size 15 [-Werror=stringop-overflow=] 1813 | nvif_outp_acquire_dp(&nv_encoder->outp, nv_encoder->dp.dpcd, 0, 0, false, false); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: note: referencing argument 2 of type 'u8[16]' {aka 'unsigned char[16]'} drivers/gpu/drm/nouveau/include/nvif/outp.h:24:5: note: in a call to function 'nvif_outp_acquire_dp' 24 | int nvif_outp_acquire_dp(struct nvif_outp *, u8 dpcd[16], | ^~~~~~~~~~~~~~~~~~~~ Avoid these warnings by defining the argument size using the matching define (DP_RECEIVER_CAP_SIZE, 15) instead of having it be a literal (and incorrect) value (16). Reported-by: coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1527269 ("Memory - corruptions") Addresses-Coverity-ID: 1527268 ("Memory - corruptions") Link: https://lore.kernel.org/lkml/202211100848.FFBA2432@keescook/ Link: https://lore.kernel.org/lkml/202211100848.F4C2819BB@keescook/ Fixes: 813443721331 ("drm/nouveau/disp: move DP link config into acquire") Reviewed-by: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221127183036.never.139-kees@kernel.org
2023-01-27ice: Prevent set_channel from changing queues while RDMA activeDave Ertman
The PF controls the set of queues that the RDMA auxiliary_driver requests resources from. The set_channel command will alter that pool and trigger a reconfiguration of the VSI, which breaks RDMA functionality. Prevent set_channel from executing when RDMA driver bound to auxiliary device. Adding a locked variable to pass down the call chain to avoid double locking the device_lock. Fixes: 348048e724a0 ("ice: Implement iidc operations") Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-01-27spi: spidev: fix a recursive locking errorBartosz Golaszewski
When calling spidev_message() from the one of the ioctl() callbacks, the spi_lock is already taken. When we then end up calling spidev_sync(), we get the following splat: [ 214.047619] [ 214.049198] ============================================ [ 214.054533] WARNING: possible recursive locking detected [ 214.059858] 6.2.0-rc3-0.0.0-devel+git.97ec4d559d93 #1 Not tainted [ 214.065969] -------------------------------------------- [ 214.071290] spidev_test/1454 is trying to acquire lock: [ 214.076530] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x8e0/0xab8 [ 214.084164] [ 214.084164] but task is already holding lock: [ 214.090007] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8 [ 214.097537] [ 214.097537] other info that might help us debug this: [ 214.104075] Possible unsafe locking scenario: [ 214.104075] [ 214.110004] CPU0 [ 214.112461] ---- [ 214.114916] lock(&spidev->spi_lock); [ 214.118687] lock(&spidev->spi_lock); [ 214.122457] [ 214.122457] *** DEADLOCK *** [ 214.122457] [ 214.128386] May be due to missing lock nesting notation [ 214.128386] [ 214.135183] 2 locks held by spidev_test/1454: [ 214.139553] #0: c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8 [ 214.147524] #1: c4925e14 (&spidev->buf_lock){+.+.}-{3:3}, at: spidev_ioctl+0x70/0xab8 [ 214.155493] [ 214.155493] stack backtrace: [ 214.159861] CPU: 0 PID: 1454 Comm: spidev_test Not tainted 6.2.0-rc3-0.0.0-devel+git.97ec4d559d93 #1 [ 214.169012] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 214.175555] unwind_backtrace from show_stack+0x10/0x14 [ 214.180819] show_stack from dump_stack_lvl+0x60/0x90 [ 214.185900] dump_stack_lvl from __lock_acquire+0x874/0x2858 [ 214.191584] __lock_acquire from lock_acquire+0xfc/0x378 [ 214.196918] lock_acquire from __mutex_lock+0x9c/0x8a8 [ 214.202083] __mutex_lock from mutex_lock_nested+0x1c/0x24 [ 214.207597] mutex_lock_nested from spidev_ioctl+0x8e0/0xab8 [ 214.213284] spidev_ioctl from sys_ioctl+0x4d0/0xe2c [ 214.218277] sys_ioctl from ret_fast_syscall+0x0/0x1c [ 214.223351] Exception stack(0xe75cdfa8 to 0xe75cdff0) [ 214.228422] dfa0: 00000000 00001000 00000003 40206b00 bee266e8 bee266e0 [ 214.236617] dfc0: 00000000 00001000 006a71a0 00000036 004c0040 004bfd18 00000000 00000003 [ 214.244809] dfe0: 00000036 bee266c8 b6f16dc5 b6e8e5f6 Fix it by introducing an unlocked variant of spidev_sync() and calling it from spidev_message() while other users who don't check the spidev->spi's existence keep on using the locking flavor. Reported-by: Francesco Dolcini <francesco@dolcini.it> Fixes: 1f4d2dd45b6e ("spi: spidev: fix a race condition when accessing spidev->spi") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Max Krummenacher <max.krummenacher@toradex.com> Link: https://lore.kernel.org/r/20230116144149.305560-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-27spi: dw: Fix wrong FIFO level setting for long xfersSerge Semin
Due to using the u16 type in the min_t() macros the SPI transfer length will be cast to word before participating in the conditional statement implied by the macro. Thus if the transfer length is greater than 64KB the Tx/Rx FIFO threshold level value will be determined by the leftover of the truncated after the type-case length. In the worst case it will cause the dramatical performance drop due to the "Tx FIFO Empty" or "Rx FIFO Full" interrupts triggered on each xfer word sent/received to/from the bus. The problem can be easily fixed by specifying the unsigned int type in the min_t() macros thus preventing the possible data loss. Fixes: ea11370fffdf ("spi: dw: get TX level without an additional variable") Reported-by: Sergey Nazarov <Sergey.Nazarov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230113185942.2516-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-27Merge back thermal control material for 6.3.Rafael J. Wysocki
2023-01-27thermal: intel: int340x: Use generic trip points tableRafael J. Wysocki
Modify int340x_thermal_zone_add() to register the thermal zone along with a trip points table, which allows the trip-related zone callbacks to be dropped, because they are not needed any more. In order to consolidate the code, use ACPI trip library functions to populate generic trip points in int340x_thermal_read_trips() and to update them in int340x_thermal_update_trips(). Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Co-developed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-27thermal: intel: int340x: Use zone lock for synchronizationRafael J. Wysocki
Because the ->get_trip_temp() and ->get_trip_type() thermal zone callbacks are only invoked from __thermal_zone_get_trip() which is always called by the thermal core under the zone lock, it is sufficient for int340x_thermal_update_trips() to acquire the zone lock for mutual exclusion with those callbacks. Accordingly, modify int340x_thermal_update_trips() to use the zone lock instead of the internal trip_mutex and drop the latter which is not necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-27thermal: intel: int340x: Rework updating trip pointsRafael J. Wysocki
It is generally invalid to change the trip point indices after they have been exposed via sysfs. Moreover, the thermal objects in the ACPI namespace cannot go away and appear on the fly. In practice, the only thing that can happen when the INT3403_PERF_TRIP_POINT_CHANGED notification is sent by the platform firmware is a change of the return values of those thermal objects. For this reason, add a special function for updating the trip point temperatures after re-evaluating the respective ACPI thermal objects and change int3403_notify() to invoke it instead of int340x_thermal_read_trips() that would change the trip point indices on errors. Also remove the locking from the latter, because it is only called before registering the thermal zone and it cannot race with the zone's callbacks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-27thermal: ACPI: Initialize trips if temperature is out of rangeRafael J. Wysocki
In some cases it is still useful to register a trip point if the temperature returned by the corresponding ACPI thermal object (for example, _HOT) is invalid to start with, because the same ACPI thermal object may start to return a valid temperature after a system configuration change (for example, from an AC power source to battery an vice versa). For this reason, if the ACPI thermal object evaluated by thermal_acpi_trip_init() successfully returns a temperature value that is out of the range of values taken into account, initialize the trip point using THERMAL_TEMP_INVALID as the temperature value instead of returning an error to allow the user of the trip point to decide what to do with it. Also update pch_wpt_add_acpi_psv_trip() to reject trip points with invalid temperature values. Fixes: 7a0e39748861 ("thermal: ACPI: Add ACPI trip point routines") Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-27Merge back Intel thermal control changes for 6.3.Rafael J. Wysocki
2023-01-27dma-buf: actually set signaling bit for private stub fencesDanilo Krummrich
In dma_fence_allocate_private_stub() set the signaling bit of the newly allocated private stub fence rather than the signaling bit of the shared dma_fence_stub. Cc: <stable@vger.kernel.org> # v6.1 Fixes: c85d00d4fd8b ("dma-buf: set signaling bit for the stub fence") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230126002844.339593-1-dakr@redhat.com
2023-01-27gpio: ep93xx: remove unused variableArnd Bergmann
This one was left behind by a previous cleanup patch: drivers/gpio/gpio-ep93xx.c: In function 'ep93xx_gpio_add_bank': drivers/gpio/gpio-ep93xx.c:366:34: error: unused variable 'ic' [-Werror=unused-variable] Fixes: 216f37366e86 ("gpio: ep93xx: Make irqchip immutable") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-01-27pinctrl: single: fix potential NULL dereferenceMaxim Korotkov
Added checking of pointer "function" in pcs_set_mux(). pinmux_generic_get_function() can return NULL and the pointer "function" was dereferenced without checking against NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 571aec4df5b7 ("pinctrl: single: Use generic pinmux helpers for managing functions") Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20221118104332.943-1-korotkov.maxim.s@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-01-27pinctrl: amd: Fix debug output for debounce timeMario Limonciello
If one GPIO has debounce enabled but future GPIOs in the list don't have debounce the time never gets reset and shows wrong value. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230121134812.16637-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-01-27pinctrl: aspeed: Fix confusing types in return valueJoel Stanley
The function signature is int, but we return a bool. Instead return a negative errno as the kerneldoc suggests. Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs") Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20230119231856.52014-1-joel@jms.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-01-27vdpa: ifcvf: Do proper cleanup if IFCVF init failsTanmay Bhushan
ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. Signed-off-by: Tanmay Bhushan <007047221b@gmail.com> Message-Id: <772e9fe133f21fa78fb98a2ebe8969efbbd58e3c.camel@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Zhu Lingshan <lingshan.zhu@intel.com>
2023-01-27vhost-scsi: unbreak any layout for responseJason Wang
Al Viro said: """ Since "vhost/scsi: fix reuse of &vq->iov[out] in response" we have this: cmd->tvc_resp_iov = vq->iov[vc.out]; cmd->tvc_in_iovs = vc.in; combined with iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov, cmd->tvc_in_iovs, sizeof(v_rsp)); in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov _pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to set an iovec-backed iov_iter over the tail of vq->iov[], with length being the amount of iovecs in the tail. Now we have a copy of one element of that array. Fortunately, the members following it in the containing structure are two non-NULL kernel pointers, so copy_to_iter() will not copy anything beyond the first iovec - kernel pointer is not (on the majority of architectures) going to be accepted by access_ok() in copyout() and it won't be skipped since the "length" (in reality - another non-NULL kernel pointer) won't be zero. So it's not going to give a guest-to-qemu escalation, but it's definitely a bug. Frankly, my preference would be to verify that the very first iovec is long enough to hold rsp_size. Due to the above, any users that try to give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp) would currently get a failure in vhost_scsi_complete_cmd_work() anyway. """ However, the spec doesn't say anything about the legacy descriptor layout for the respone. So this patch tries to not assume the response to reside in a single separate descriptor which is what commit 79c14141a487 ("vhost/scsi: Convert completion path to use") tries to achieve towards to ANY_LAYOUT. This is done by allocating and using dedicate resp iov in the command. To be safety, start with UIO_MAXIOV to be consistent with the limitation that we advertise to the vhost_get_vq_desc(). Testing with the hacked virtio-scsi driver that use 1 descriptor for 1 byte in the response. Reported-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Benjamin Coddington <bcodding@redhat.com> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response") Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230119073647.76467-1-jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-27vhost/net: Clear the pending messages when the backend is removedEric Auger
When the vhost iotlb is used along with a guest virtual iommu and the guest gets rebooted, some MISS messages may have been recorded just before the reboot and spuriously executed by the virtual iommu after the reboot. As vhost does not have any explicit reset user API, VHOST_NET_SET_BACKEND looks a reasonable point where to clear the pending messages, in case the backend is removed. Export vhost_clear_msg() and call it in vhost_net_set_backend() when fd == -1. Signed-off-by: Eric Auger <eric.auger@redhat.com> Suggested-by: Jason Wang <jasowang@redhat.com> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Message-Id: <20230117151518.44725-3-eric.auger@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-26scsi: Revert "scsi: core: map PQ=1, PDT=other values to ↵Martin K. Petersen
SCSI_SCAN_TARGET_PRESENT" This reverts commit 948e922fc44611ee2de0c89583ca958cb5307d36. Not all targets that return PQ=1 and PDT=0 should be ignored. While the SCSI spec is vague in this department, there appears to be a critical mass of devices which rely on devices being accessible with this combination of reported values. Fixes: 948e922fc446 ("scsi: core: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT") Link: https://lore.kernel.org/r/yq1lelrleqr.fsf@ca-mkp.ca.oracle.com Acked-by: Bart Van Assche <bvanassche@acm.org> Acked-by: Martin Wilck <mwilck@suse.com> Acked-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-01-26scsi: core: Fix the scsi_device_put() might_sleep annotationBart Van Assche
Although most calls of scsi_device_put() happen from non-atomic context, alua_rtpg_queue() calls this function from atomic context if alua_rtpg_queue() itself is called from atomic context. alua_rtpg_queue() is always called from contexts where the caller must hold at least one reference to the scsi device in question. This means that the reference taken by alua_rtpg_queue() itself can't be the last one, and thus can be dropped without entering the code path in which scsi_device_put() might actually sleep. Hence move the might_sleep() annotation from scsi_device_put() into scsi_device_dev_release(). [1] https://lore.kernel.org/linux-scsi/b49e37d5-edfb-4c56-3eeb-62c7d5855c00@linux.ibm.com/ [2] https://lore.kernel.org/linux-scsi/55c35e64-a7d4-9072-46fd-e8eae6a90e96@linux.ibm.com/ Note: a significant part of the above description was written by Martin Wilck. Fixes: f93ed747e2c7 ("scsi: core: Release SCSI devices synchronously") Cc: Martin Wilck <mwilck@suse.com> Cc: Steffen Maier <maier@linux.ibm.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Sachin Sant <sachinp@linux.ibm.com> Cc: Benjamin Block <bblock@linux.ibm.com> Reported-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Martin Wilck <mwilck@suse.com> Link: https://lore.kernel.org/r/20230125194311.249553-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-01-27Merge tag 'drm-misc-fixes-2023-01-26' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes A fix and a preliminary patch to fix a memory leak in i915, and a use after free fix for fbdev deferred io Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230126104018.cbrcjxl5wefdbb2f@houat
2023-01-27amdgpu: fix build on non-DCN platforms.Dave Airlie
This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie <airlied@redhat.com>
2023-01-27Merge tag 'amd-drm-fixes-6.2-2023-01-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.2-2023-01-25: amdgpu: - GC11.x fixes - SMU13.0.0 fix - Freesync video fix - DP MST fixes drm: - DP MST kref fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125220153.320248-1-alexander.deucher@amd.com
2023-01-26IB/IPoIB: Fix legacy IPoIB due to wrong number of queuesDragos Tatulea
The cited commit creates child PKEY interfaces over netlink will multiple tx and rx queues, but some devices doesn't support more than 1 tx and 1 rx queues. This causes to a crash when traffic is sent over the PKEY interface due to the parent having a single queue but the child having multiple queues. This patch fixes the number of queues to 1 for legacy IPoIB at the earliest possible point in time. BUG: kernel NULL pointer dereference, address: 000000000000036b PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc+0xcb/0x450 Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202 RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00 RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40 R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000 R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000 FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_clone+0x55/0xd0 ip6_finish_output2+0x3fe/0x690 ip6_finish_output+0xfa/0x310 ip6_send_skb+0x1e/0x60 udp_v6_send_skb+0x1e5/0x420 udpv6_sendmsg+0xb3c/0xe60 ? ip_mc_finish_output+0x180/0x180 ? __switch_to_asm+0x3a/0x60 ? __switch_to_asm+0x34/0x60 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? _copy_to_user+0x21/0x30 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_ts64+0x49/0xe0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f9374f1ed14 Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14 RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030 RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc </TASK> Fixes: dbc94a0fb817 ("IB/IPoIB: Fix queue count inconsistency for PKEY child interfaces") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Link: https://lore.kernel.org/r/95eb6b74c7cf49fa46281f9d056d685c9fa11d38.1674584576.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2023-01-26drm/ssd130x: Init display before the SSD130X_DISPLAY_ON commandJavier Martinez Canillas
Commit 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the atomic helpers") changed the driver to just use the atomic helpers instead of the simple KMS abstraction layer. But the commit also made a subtle change on the display power sequence and initialization order, by moving the ssd130x_power_on() call to the encoder .atomic_enable handler and the ssd130x_init() call to CRTC .reset handler. Before this change, both ssd130x_power_on() and ssd130x_init() were called in the simple display pipeline .enable handler, so the display was already initialized by the time the SSD130X_DISPLAY_ON command was sent. For some reasons, it only made the ssd130x SPI driver to fail but the I2C was still working. That is the reason why the bug was not noticed before. To revert to the old driver behavior, move the ssd130x_init() call to the encoder .atomic_enable as well. Besides fixing the panel not being turned on when using SPI, it also gets rid of the custom CRTC .reset callback. Fixes: 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the atomic helpers") Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230125184230.3343206-1-javierm@redhat.com
2023-01-26Merge tag 'nvme-6.2-2023-01-26' of git://git.infradead.org/nvme into block-6.2Jens Axboe
Pull NVMe fixes from Christoph: "nvme fixes for Linux 6.2 - flush initial scan_work for async probe (Keith Busch) - fix passthrough csi check (Keith Busch) - fix nvme-fc initialization order (Ross Lagerwall)" * tag 'nvme-6.2-2023-01-26' of git://git.infradead.org/nvme: nvme: fix passthrough csi check nvme-pci: flush initial scan_work for async probe nvme-fc: fix initialization order
2023-01-26Merge tag 'platform-drivers-x86-v6.2-3' 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: - Fix false positive apple_gmux backlight detection on older iGPU only MacBook models - Various other small fixes and hardware-id additions * tag 'platform-drivers-x86-v6.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: thinkpad_acpi: Fix profile modes on Intel platforms ACPI: video: Fix apple gmux detection platform/x86: apple-gmux: Add apple_gmux_detect() helper platform/x86: apple-gmux: Move port defines to apple-gmux.h platform/x86: hp-wmi: Fix cast to smaller integer type warning platform/x86/amd: pmc: Add a module parameter to disable workarounds platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN platform/x86: asus-wmi: Fix kbd_dock_devid tablet-switch reporting platform/x86: gigabyte-wmi: add support for B450M DS3H WIFI-CF platform/x86: hp-wmi: Handle Omen Key event platform/x86: dell-wmi: Add a keymap for KEY_MUTE in type 0x0010 table
2023-01-26Merge tag 'net-6.2-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter. Current release - regressions: - sched: sch_taprio: do not schedule in taprio_reset() Previous releases - regressions: - core: fix UaF in netns ops registration error path - ipv4: prevent potential spectre v1 gadgets - ipv6: fix reachability confirmation with proxy_ndp - netfilter: fix for the set rbtree - eth: fec: use page_pool_put_full_page when freeing rx buffers - eth: iavf: fix temporary deadlock and failure to set MAC address Previous releases - always broken: - netlink: prevent potential spectre v1 gadgets - netfilter: fixes for SCTP connection tracking - mctp: struct sock lifetime fixes - eth: ravb: fix possible hang if RIS2_QFF1 happen - eth: tg3: resolve deadlock in tg3_reset_task() during EEH Misc: - Mat stepped out as MPTCP co-maintainer" * tag 'net-6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (40 commits) net: mdio-mux-meson-g12a: force internal PHY off on mux switch docs: networking: Fix bridge documentation URL tsnep: Fix TX queue stop/wake for multiple queues net/tg3: resolve deadlock in tg3_reset_task() during EEH net: mctp: mark socks as dead on unhash, prevent re-add net: mctp: hold key reference when looking up a general key net: mctp: move expiry timer delete to unhash net: mctp: add an explicit reference from a mctp_sk_key to sock net: ravb: Fix possible hang if RIS2_QFF1 happen net: ravb: Fix lack of register setting after system resumed for Gen3 net/x25: Fix to not accept on connected socket ice: move devlink port creation/deletion sctp: fail if no bound addresses can be used for a given scope net/sched: sch_taprio: do not schedule in taprio_reset() Revert "Merge branch 'ethtool-mac-merge'" netrom: Fix use-after-free of a listening socket. netfilter: conntrack: unify established states for SCTP paths Revert "netfilter: conntrack: add sctp DATA_SENT state" netfilter: conntrack: fix bug in for_each_sctp_chunk netfilter: conntrack: fix vtag checks for ABORT/SHUTDOWN_COMPLETE ...
2023-01-26treewide: fix up files incorrectly marked executableLinus Torvalds
I'm not exactly clear on what strange workflow causes people to do it, but clearly occasionally some files end up being committed as executable even though they clearly aren't. This is a reprise of commit 90fda63fa115 ("treewide: fix up files incorrectly marked executable"), just with a different set of files (but with the same trivial shell scripting). So apparently we need to re-do this every five years or so, and Joe needs to just keep reminding me to do so ;) Reported-by: Joe Perches <joe@perches.com> Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64") Fixes: 5c439937775d ("ASoC: codecs: add support for ES8326") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-01-26Merge tag 'thermal-v6.3-rc1' of ↵Rafael J. Wysocki
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux into thermal-next Pull thermal control material for 6.3-rc1 from Daniel Lezcano: "- Fix kerneldoc format errors for Rockchip, Mediatek and Uniphier (Randy Dunlap) - Add the missing 'qcom,adc-tm7' compatible string in the dt-bindings (Krzysztof Kozlowski) - Improve the calibration routine by relying on the nvmem to read the values and provide a set of fixes for the QCom tsens driver (Dmitry Baryshkov) - Remove the duplicate interrupt setting routine in the QCom tsens driver (Daniel Lezcano) - Fix a wrong loop condition in the i.MX SC thermal driver and add the iMX8QM sensors (Viorel Suman) - Fix header inclusion asm-generic.h by asm.h for the qcom-spmi-adc-tm5 driver (Andy Shevchenko) - Use the devm_platform_get_and_ioremap_resource() combo function in all the drivers where the conversion applies (Ye Xingchen) - Replace a literal mask by an existing corresponding macro (Yangtao Li) - Add support for MT7986 and MT7981 (Daniel Golle) - Use thermal_zone_get_crit_temp() for the Armada thermal driver (Daniel Lezcano)" * tag 'thermal-v6.3-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux: (35 commits) thermal/drivers/armada: Use the thermal_zone_get_crit_temp() thermal/drivers/mtk: Add support for MT7986 and MT7981 thermal/drivers/mtk: Use function pointer for raw_to_mcelsius thermal/drivers/sun8i: Convert to use macro thermal/drivers/spear: Use devm_platform_get_and_ioremap_resource() thermal/drivers/kirkwood: Use devm_platform_get_and_ioremap_resource() thermal/drivers/thermal_mmio: Use devm_platform_get_and_ioremap_resource() thermal/drivers/rockchip: Use devm_platform_get_and_ioremap_resource() thermal/drivers/mtk_thermal: Use devm_platform_get_and_ioremap_resource() thermal/drivers/armada: Use devm_platform_get_and_ioremap_resource() thermal/drivers/dove: Use devm_platform_get_and_ioremap_resource() thermal/drivers/bcm2835: Use devm_platform_get_and_ioremap_resource() thermal/drivers/brcmstb_thermal: Use devm_platform_get_and_ioremap_resource() thermal/drivers/qcom-spmi-adc-tm5: Use asm intead of asm-generic thermal/drivers/imx_sc_thermal: Add iMX8QM sensors thermal/drivers/imx_sc_thermal: Fix the loop condition thermal/drivers/qcom: Remove duplicate set next trip point interrupt code thermal/drivers/tsens: Drop single-cell code for msm8976/msm8956 thermal/drivers/tsens: Drop single-cell code for msm8939 thermal/drivers/tsens: Drop single-cell code for mdm9607 ...
2023-01-26thermal: intel: processor_thermal_device_pci: Use generic trip pointDaniel Lezcano
Make proc_thermal_pci_probe() register the TCPU_PCI thermal zone along with the trip point used by it and drop the zone callbacks related to this trip point that are not needed any more. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-26block: ublk: move ublk_chr_class destroying after devices are removedMing Lei
The 'ublk_chr_class' is needed when deleting ublk char devices in ublk_exit(), so move it after devices(idle) are removed. Fixes the following warning reported by Harris, James R: [ 859.178950] sysfs group 'power' not found for kobject 'ublkc0' [ 859.178962] WARNING: CPU: 3 PID: 1109 at fs/sysfs/group.c:278 sysfs_remove_group+0x9c/0xb0 Reported-by: "Harris, James R" <james.r.harris@intel.com> Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Link: https://lore.kernel.org/linux-block/Y9JlFmSgDl3+zy3N@T590/T/#t Signed-off-by: Ming Lei <ming.lei@redhat.com> Tested-by: Jim Harris <james.r.harris@intel.com> Link: https://lore.kernel.org/r/20230126115346.263344-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-26Partially revert "perf/arm-cmn: Optimise DTC counter accesses"Robin Murphy
It turns out the optimisation implemented by commit 4f2c3872dde5 is totally broken, since all the places that consume hw->dtcs_used for events other than cycle count are still not expecting it to be sparsely populated, and fail to read all the relevant DTC counters correctly if so. If implemented correctly, the optimisation potentially saves up to 3 register reads per event update, which is reasonably significant for events targeting a single node, but still not worth a massive amount of additional code complexity overall. Getting it right within the current design looks a fair bit more involved than it was ever intended to be, so let's just make a functional revert which restores the old behaviour while still backporting easily. Fixes: 4f2c3872dde5 ("perf/arm-cmn: Optimise DTC counter accesses") Reported-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/b41bb4ed7283c3d8400ce5cf5e6ec94915e6750f.1674498637.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2023-01-26thermal: intel: int340x: Add production mode attributeSrinivas Pandruvada
It is possible that the system manufacturer locks down thermal tuning beyond what is usually done on the given platform. In that case user space calibration tools should not try to adjust the thermal configuration of the system. To allow user space to check if that is the case, add a new sysfs attribute "production_mode" that will be present when the ACPI DCFG method is present under the INT3400 device object in the ACPI Namespace. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-26pinctrl: mediatek: Fix the drive register definition of some PinsGuodong Liu
The drive adjustment register definition of gpio13 and gpio81 is wrong: "the start address for the range" of gpio18 is corrected to 0x000, "the start bit for the first register within the range" of gpio81 is corrected to 24. Fixes: 6cf5e9ef362a ("pinctrl: add pinctrl driver on mt8195") Signed-off-by: Guodong Liu <Guodong.Liu@mediatek.com> Link: https://lore.kernel.org/r/20230118062116.26315-1-Guodong.Liu@mediatek.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-01-26drm/vc4: hdmi: make CEC adapter name uniqueHans Verkuil
The bcm2711 has two HDMI outputs, each with their own CEC adapter. The CEC adapter name has to be unique, but it is currently hardcoded to "vc4" for both outputs. Change this to use the card_name from the variant information in order to make the adapter name unique. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/dcf1db75-d9cc-62cc-fa12-baf1b2b3bf31@xs4all.nl
2023-01-25net: mdio-mux-meson-g12a: force internal PHY off on mux switchJerome Brunet
Force the internal PHY off then on when switching to the internal path. This fixes problems where the PHY ID is not properly set. Fixes: 7090425104db ("net: phy: add amlogic g12a mdio mux support") Suggested-by: Qi Duan <qi.duan@amlogic.com> Co-developed-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20230124101157.232234-1-jbrunet@baylibre.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-25tsnep: Fix TX queue stop/wake for multiple queuesGerhard Engleder
netif_stop_queue() and netif_wake_queue() act on TX queue 0. This is ok as long as only a single TX queue is supported. But support for multiple TX queues was introduced with 762031375d5c and I missed to adapt stop and wake of TX queues. Use netif_stop_subqueue() and netif_tx_wake_queue() to act on specific TX queue. Fixes: 762031375d5c ("tsnep: Support multiple TX/RX queue pairs") Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Link: https://lore.kernel.org/r/20230124191440.56887-1-gerhard@engleder-embedded.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-25net/tg3: resolve deadlock in tg3_reset_task() during EEHDavid Christensen
During EEH error injection testing, a deadlock was encountered in the tg3 driver when tg3_io_error_detected() was attempting to cancel outstanding reset tasks: crash> foreach UN bt ... PID: 159 TASK: c0000000067c6000 CPU: 8 COMMAND: "eehd" ... #5 [c00000000681f990] __cancel_work_timer at c00000000019fd18 #6 [c00000000681fa30] tg3_io_error_detected at c00800000295f098 [tg3] #7 [c00000000681faf0] eeh_report_error at c00000000004e25c ... PID: 290 TASK: c000000036e5f800 CPU: 6 COMMAND: "kworker/6:1" ... #4 [c00000003721fbc0] rtnl_lock at c000000000c940d8 #5 [c00000003721fbe0] tg3_reset_task at c008000002969358 [tg3] #6 [c00000003721fc60] process_one_work at c00000000019e5c4 ... PID: 296 TASK: c000000037a65800 CPU: 21 COMMAND: "kworker/21:1" ... #4 [c000000037247bc0] rtnl_lock at c000000000c940d8 #5 [c000000037247be0] tg3_reset_task at c008000002969358 [tg3] #6 [c000000037247c60] process_one_work at c00000000019e5c4 ... PID: 655 TASK: c000000036f49000 CPU: 16 COMMAND: "kworker/16:2" ...:1 #4 [c0000000373ebbc0] rtnl_lock at c000000000c940d8 #5 [c0000000373ebbe0] tg3_reset_task at c008000002969358 [tg3] #6 [c0000000373ebc60] process_one_work at c00000000019e5c4 ... Code inspection shows that both tg3_io_error_detected() and tg3_reset_task() attempt to acquire the RTNL lock at the beginning of their code blocks. If tg3_reset_task() should happen to execute between the times when tg3_io_error_deteced() acquires the RTNL lock and tg3_reset_task_cancel() is called, a deadlock will occur. Moving tg3_reset_task_cancel() call earlier within the code block, prior to acquiring RTNL, prevents this from happening, but also exposes another deadlock issue where tg3_reset_task() may execute AFTER tg3_io_error_detected() has executed: crash> foreach UN bt PID: 159 TASK: c0000000067d2000 CPU: 9 COMMAND: "eehd" ... #4 [c000000006867a60] rtnl_lock at c000000000c940d8 #5 [c000000006867a80] tg3_io_slot_reset at c0080000026c2ea8 [tg3] #6 [c000000006867b00] eeh_report_reset at c00000000004de88 ... PID: 363 TASK: c000000037564000 CPU: 6 COMMAND: "kworker/6:1" ... #3 [c000000036c1bb70] msleep at c000000000259e6c #4 [c000000036c1bba0] napi_disable at c000000000c6b848 #5 [c000000036c1bbe0] tg3_reset_task at c0080000026d942c [tg3] #6 [c000000036c1bc60] process_one_work at c00000000019e5c4 ... This issue can be avoided by aborting tg3_reset_task() if EEH error recovery is already in progress. Fixes: db84bf43ef23 ("tg3: tg3_reset_task() needs to use rtnl_lock to synchronize") Signed-off-by: David Christensen <drc@linux.vnet.ibm.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20230124185339.225806-1-drc@linux.vnet.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>