July 2024 - Linux-stable-mirror

by Alexey Kuznetsov

Hello! My Asus Laptop (ASUS VivoBook PRO 15 OLED M3500QA-L1072) reporting this wmi code everytime I connect power cable. I got no key code on power disconnect. [11238.502716] asus_wmi: Unknown key code 0xcf

2 months, 1 week

2
1
0 0

[git:media_stage/fixes] media: ipu-bridge: fix ipu6 Kconfig dependencies

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: ipu-bridge: fix ipu6 Kconfig dependencies Author: Arnd Bergmann <arnd(a)arndb.de> Date: Fri Jul 19 11:53:50 2024 +0200 Commit 4670c8c3fb04 ("media: ipu-bridge: Fix Kconfig dependencies") changed how IPU_BRIDGE dependencies are handled for all drivers, but the IPU6 variant was added the old way, which causes build time warnings when I2C is turned off: WARNING: unmet direct dependencies detected for IPU_BRIDGE Depends on [n]: MEDIA_SUPPORT [=m] && PCI [=y] && MEDIA_PCI_SUPPORT [=y] && (ACPI [=y] || COMPILE_TEST [=y]) && I2C [=n] Selected by [m]: - VIDEO_INTEL_IPU6 [=m] && MEDIA_SUPPORT [=m] && PCI [=y] && MEDIA_PCI_SUPPORT [=y] && (ACPI [=y] || COMPILE_TEST [=y]) && VIDEO_DEV [=m] && X86 [=y] && X86_64 [=y] && HAS_DMA [=y] To make it consistent with the other IPU drivers as well as avoid this warning, change the 'select' into 'depends on'. Fixes: c70281cc83d6 ("media: intel/ipu6: add Kconfig and Makefile") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> [Sakari Ailus: Alternatively depend on !IPU_BRIDGE.] Cc: stable(a)vger.kernel.org # for v6.10 Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/pci/intel/ipu6/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/media/pci/intel/ipu6/Kconfig b/drivers/media/pci/intel/ipu6/Kconfig index 154343080c82..b7ab24b89836 100644 --- a/drivers/media/pci/intel/ipu6/Kconfig +++ b/drivers/media/pci/intel/ipu6/Kconfig @@ -3,13 +3,13 @@ config VIDEO_INTEL_IPU6 depends on ACPI || COMPILE_TEST depends on VIDEO_DEV depends on X86 && X86_64 && HAS_DMA + depends on IPU_BRIDGE || !IPU_BRIDGE select DMA_OPS select IOMMU_IOVA select VIDEO_V4L2_SUBDEV_API select MEDIA_CONTROLLER select VIDEOBUF2_DMA_CONTIG select V4L2_FWNODE - select IPU_BRIDGE help This is the 6th Gen Intel Image Processing Unit, found in Intel SoCs and used for capturing images and video from camera sensors.

2 months, 1 week

1
0
0 0

[git:media_stage/fixes] media: v4l: Fix missing tabular column hint for Y14P format

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: v4l: Fix missing tabular column hint for Y14P format Author: Jean-Michel Hautbois <jeanmichel.hautbois(a)yoseli.org> Date: Sat Jun 8 18:41:27 2024 +0200 The original patch added two columns in the flat-table of Luma-Only Image Formats, without updating hints to latex: above it. This results in wrong column count in the output of Sphinx's latex builder. Fix it. Reported-by: Akira Yokosawa <akiyks(a)gmail.com> Closes: https://lore.kernel.org/linux-media/bdbc27ba-5098-49fb-aabf-753c81361cc7@gm… Fixes: adb1d4655e53 ("media: v4l: Add V4L2-PIX-FMT-Y14P format") Cc: stable(a)vger.kernel.org # for v6.10 Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois(a)yoseli.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst index f02e6cf3516a..74df19be91f6 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst @@ -21,9 +21,9 @@ are often referred to as greyscale formats. .. raw:: latex - \scriptsize + \tiny -.. tabularcolumns:: |p{3.6cm}|p{3.0cm}|p{1.3cm}|p{2.6cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}| +.. tabularcolumns:: |p{3.6cm}|p{2.4cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}| .. flat-table:: Luma-Only Image Formats :header-rows: 1

2 months, 1 week

1
0
0 0

[git:media_stage/fixes] media: intel/ipu6: select AUXILIARY_BUS in Kconfig

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: intel/ipu6: select AUXILIARY_BUS in Kconfig Author: Bingbu Cao <bingbu.cao(a)intel.com> Date: Wed Jul 17 15:40:50 2024 +0800 Intel IPU6 PCI driver need register its devices on auxiliary bus, so it needs to select the AUXILIARY_BUS in Kconfig. Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407161833.7BEFXejx-lkp@intel.com/ Fixes: c70281cc83d6 ("media: intel/ipu6: add Kconfig and Makefile") Signed-off-by: Bingbu Cao <bingbu.cao(a)intel.com> Cc: stable(a)vger.kernel.org # for v6.10 Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/pci/intel/ipu6/Kconfig | 1 + 1 file changed, 1 insertion(+) --- diff --git a/drivers/media/pci/intel/ipu6/Kconfig b/drivers/media/pci/intel/ipu6/Kconfig index b7ab24b89836..40e20f0aa5ae 100644 --- a/drivers/media/pci/intel/ipu6/Kconfig +++ b/drivers/media/pci/intel/ipu6/Kconfig @@ -4,6 +4,7 @@ config VIDEO_INTEL_IPU6 depends on VIDEO_DEV depends on X86 && X86_64 && HAS_DMA depends on IPU_BRIDGE || !IPU_BRIDGE + select AUXILIARY_BUS select DMA_OPS select IOMMU_IOVA select VIDEO_V4L2_SUBDEV_API

2 months, 1 week

1
0
0 0

[PATCH 6.1 1/2] wifi: mac80211: Allow NSS change only up to capability

by Hauke Mehrtens

From: Rameshkumar Sundaram <quic_ramess(a)quicinc.com> [ Upstream commit 57b341e9ab13e5688491bfd54f8b5502416c8905 ] Stations can update bandwidth/NSS change in VHT action frame with action type Operating Mode Notification. (IEEE Std 802.11-2020 - 9.4.1.53 Operating Mode field) For Operating Mode Notification, an RX NSS change to a value greater than AP's maximum NSS should not be allowed. During fuzz testing, by forcefully sending VHT Op. mode notif. frames from STA with random rx_nss values, it is found that AP accepts rx_nss values greater that APs maximum NSS instead of discarding such NSS change. Hence allow NSS change only up to maximum NSS that is negotiated and capped to AP's capability during association. Signed-off-by: Rameshkumar Sundaram <quic_ramess(a)quicinc.com> Link: https://lore.kernel.org/r/20230207114146.10567-1-quic_ramess@quicinc.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de> --- net/mac80211/vht.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c index f7526be8a1c7..b3a5c3e96a72 100644 --- a/net/mac80211/vht.c +++ b/net/mac80211/vht.c @@ -637,7 +637,7 @@ u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata, enum ieee80211_sta_rx_bandwidth new_bw; struct sta_opmode_info sta_opmode = {}; u32 changed = 0; - u8 nss; + u8 nss, cur_nss; /* ignore - no support for BF yet */ if (opmode & IEEE80211_OPMODE_NOTIF_RX_NSS_TYPE_BF) @@ -648,10 +648,25 @@ u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata, nss += 1; if (link_sta->pub->rx_nss != nss) { - link_sta->pub->rx_nss = nss; - sta_opmode.rx_nss = nss; - changed |= IEEE80211_RC_NSS_CHANGED; - sta_opmode.changed |= STA_OPMODE_N_SS_CHANGED; + cur_nss = link_sta->pub->rx_nss; + /* Reset rx_nss and call ieee80211_sta_set_rx_nss() which + * will set the same to max nss value calculated based on capability. + */ + link_sta->pub->rx_nss = 0; + ieee80211_sta_set_rx_nss(link_sta); + /* Do not allow an nss change to rx_nss greater than max_nss + * negotiated and capped to APs capability during association. + */ + if (nss <= link_sta->pub->rx_nss) { + link_sta->pub->rx_nss = nss; + sta_opmode.rx_nss = nss; + changed |= IEEE80211_RC_NSS_CHANGED; + sta_opmode.changed |= STA_OPMODE_N_SS_CHANGED; + } else { + link_sta->pub->rx_nss = cur_nss; + pr_warn_ratelimited("Ignoring NSS change in VHT Operating Mode Notification from %pM with invalid nss %d", + link_sta->pub->addr, nss); + } } switch (opmode & IEEE80211_OPMODE_NOTIF_CHANWIDTH_MASK) { -- 2.45.2

2 months, 1 week

1
1
0 0

[PATCH v3 0/3] ALSA: firewire-lib: restore process context workqueue to prevent deadlock

by Edmund Raile

This patchset serves to prevent an AB/BA deadlock: thread 0: * (lock A) acquire substream lock by snd_pcm_stream_lock_irq() in snd_pcm_status64() * (lock B) wait for tasklet to finish by calling tasklet_unlock_spin_wait() in tasklet_disable_in_atomic() in ohci_flush_iso_completions() of ohci.c thread 1: * (lock B) enter tasklet * (lock A) attempt to acquire substream lock, waiting for it to be released: snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed() in update_pcm_pointers() in process_ctx_payloads() in process_rx_packets() of amdtp-stream.c ? tasklet_unlock_spin_wait </NMI> <TASK> ohci_flush_iso_completions firewire_ohci amdtp_domain_stream_pcm_pointer snd_firewire_lib snd_pcm_update_hw_ptr0 snd_pcm snd_pcm_status64 snd_pcm ? native_queued_spin_lock_slowpath </NMI> <IRQ> _raw_spin_lock_irqsave snd_pcm_period_elapsed snd_pcm process_rx_packets snd_firewire_lib irq_target_callback snd_firewire_lib handle_it_packet firewire_ohci context_tasklet firewire_ohci The issue has been reported as a regression of kernel 5.14: Link: https://lore.kernel.org/regressions/kwryofzdmjvzkuw6j3clftsxmoolynljztxqwg7… ("[REGRESSION] ALSA: firewire-lib: snd_pcm_period_elapsed deadlock with Fireface 800") Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context") removed the process context workqueue from amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove its overhead. Commit b5b519965c4c ("ALSA: firewire-lib: obsolete workqueue for period update") belongs to the same patch series and removed the now-unused workqueue entirely. Though being observed on RME Fireface 800, this issue would affect all Firewire audio interfaces using ohci amdtp + pcm streaming. ALSA streaming, especially under intensive CPU load will reveal this issue the soonest due to issuing more hardIRQs, with time to occurrence ranging from 2 secons to 30 minutes after starting playback. to reproduce the issue: direct ALSA playback to the device: mpv --audio-device=alsa/sysdefault:CARD=Fireface800 Spor-Ignition.flac Time to occurrence: 2s to 30m Likelihood increased by: - high CPU load stress --cpu $(nproc) - switching between applications via workspaces tested with i915 in Xfce PulsaAudio / PipeWire conceal the issue as they run PCM substream without period wakeup mode, issuing less hardIRQs. Cc: stable(a)vger.kernel.org Backport note: Also applies to and fixes on (tested): 6.10.2, 6.9.12, 6.6.43, 6.1.102, 5.15.164 Edmund Raile (3): Revert "ALSA: firewire-lib: obsolete workqueue for period update" Revert "ALSA: firewire-lib: operate for period elapse event in process context" ALSA: firewire-lib: amdtp-stream work queue inline description sound/firewire/amdtp-stream.c | 38 ++++++++++++++++++++++------------- sound/firewire/amdtp-stream.h | 1 + 2 files changed, 25 insertions(+), 14 deletions(-) -- 2.45.2

2 months, 1 week

1
3
0 0

[PATCH v3 0/3] ALSA: firewire-lib: restore process context workqueue to prevent deadlock

by Edmund Raile

This patchset serves to prevent an AB/BA deadlock: thread 0: * (lock A) acquire substream lock by snd_pcm_stream_lock_irq() in snd_pcm_status64() * (lock B) wait for tasklet to finish by calling tasklet_unlock_spin_wait() in tasklet_disable_in_atomic() in ohci_flush_iso_completions() of ohci.c thread 1: * (lock B) enter tasklet * (lock A) attempt to acquire substream lock, waiting for it to be released: snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed() in update_pcm_pointers() in process_ctx_payloads() in process_rx_packets() of amdtp-stream.c ? tasklet_unlock_spin_wait </NMI> <TASK> ohci_flush_iso_completions firewire_ohci amdtp_domain_stream_pcm_pointer snd_firewire_lib snd_pcm_update_hw_ptr0 snd_pcm snd_pcm_status64 snd_pcm ? native_queued_spin_lock_slowpath </NMI> <IRQ> _raw_spin_lock_irqsave snd_pcm_period_elapsed snd_pcm process_rx_packets snd_firewire_lib irq_target_callback snd_firewire_lib handle_it_packet firewire_ohci context_tasklet firewire_ohci The issue has been reported as a regression of kernel 5.14: Link: https://lore.kernel.org/regressions/kwryofzdmjvzkuw6j3clftsxmoolynljztxqwg7… ("[REGRESSION] ALSA: firewire-lib: snd_pcm_period_elapsed deadlock with Fireface 800") Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context") removed the process context workqueue from amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove its overhead. Commit b5b519965c4c ("ALSA: firewire-lib: obsolete workqueue for period update") belongs to the same patch series and removed the now-unused workqueue entirely. Though being observed on RME Fireface 800, this issue would affect all Firewire audio interfaces using ohci amdtp + pcm streaming. ALSA streaming, especially under intensive CPU load will reveal this issue the soonest due to issuing more hardIRQs, with time to occurrence ranging from 2 secons to 30 minutes after starting playback. to reproduce the issue: direct ALSA playback to the device: mpv --audio-device=alsa/sysdefault:CARD=Fireface800 Spor-Ignition.flac Time to occurrence: 2s to 30m Likelihood increased by: - high CPU load stress --cpu $(nproc) - switching between applications via workspaces tested with i915 in Xfce PulsaAudio / PipeWire conceal the issue as they run PCM substream without period wakeup mode, issuing less hardIRQs. Cc: stable(a)vger.kernel.org Backport note: Also applies to and fixes on (tested): 6.10.2, 6.9.12, 6.6.43, 6.1.102, 5.15.164 Edmund Raile (3): Revert "ALSA: firewire-lib: obsolete workqueue for period update" Revert "ALSA: firewire-lib: operate for period elapse event in process context" ALSA: firewire-lib: amdtp-stream work queue inline description sound/firewire/amdtp-stream.c | 38 ++++++++++++++++++++++------------- sound/firewire/amdtp-stream.h | 1 + 2 files changed, 25 insertions(+), 14 deletions(-) -- 2.45.2

2 months, 1 week

1
3
0 0

FAILED: patch "[PATCH] fuse: verify {g,u}id mount options correctly" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 525bd65aa759ec320af1dc06e114ed69733e9e23 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072914-sierra-aflutter-e231@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 525bd65aa759 ("fuse: verify {g,u}id mount options correctly") 84c215075b57 ("fuse: name fs_context consistently") 1dd539577c42 ("virtiofs: add a mount option to enable dax") f4fd4ae354ba ("virtiofs: get rid of no_mount_options") b330966f79fb ("fuse: reject options on reconfigure via fsconfig(2)") e8b20a474cf2 ("fuse: ignore 'data' argument of mount(..., MS_REMOUNT)") 0189a2d367f4 ("fuse: use ->reconfigure() instead of ->remount_fs()") 7fd3abfa8dd7 ("virtiofs: do not use fuse_fill_super_common() for device installation") c9d35ee049b4 ("Merge branch 'merge.nfs-fs_parse.1' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 525bd65aa759ec320af1dc06e114ed69733e9e23 Mon Sep 17 00:00:00 2001 From: Eric Sandeen <sandeen(a)redhat.com> Date: Tue, 2 Jul 2024 17:22:41 -0500 Subject: [PATCH] fuse: verify {g,u}id mount options correctly As was done in 0200679fc795 ("tmpfs: verify {g,u}id mount options correctly") we need to validate that the requested uid and/or gid is representable in the filesystem's idmapping. Cribbing from the above commit log, The contract for {g,u}id mount options and {g,u}id values in general set from userspace has always been that they are translated according to the caller's idmapping. In so far, fuse has been doing the correct thing. But since fuse is mountable in unprivileged contexts it is also necessary to verify that the resulting {k,g}uid is representable in the namespace of the superblock. Fixes: c30da2e981a7 ("fuse: convert to use the new mount API") Cc: stable(a)vger.kernel.org # 5.4+ Signed-off-by: Eric Sandeen <sandeen(a)redhat.com> Link: https://lore.kernel.org/r/8f07d45d-c806-484d-a2e3-7a2199df1cd2@redhat.com Reviewed-by: Christian Brauner <brauner(a)kernel.org> Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Christian Brauner <brauner(a)kernel.org> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index 99e44ea7d875..32fe6fa72f46 100644 --- a/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -755,6 +755,8 @@ static int fuse_parse_param(struct fs_context *fsc, struct fs_parameter *param) struct fs_parse_result result; struct fuse_fs_context *ctx = fsc->fs_private; int opt; + kuid_t kuid; + kgid_t kgid; if (fsc->purpose == FS_CONTEXT_FOR_RECONFIGURE) { /* @@ -799,16 +801,30 @@ static int fuse_parse_param(struct fs_context *fsc, struct fs_parameter *param) break; case OPT_USER_ID: - ctx->user_id = make_kuid(fsc->user_ns, result.uint_32); - if (!uid_valid(ctx->user_id)) + kuid = make_kuid(fsc->user_ns, result.uint_32); + if (!uid_valid(kuid)) return invalfc(fsc, "Invalid user_id"); + /* + * The requested uid must be representable in the + * filesystem's idmapping. + */ + if (!kuid_has_mapping(fsc->user_ns, kuid)) + return invalfc(fsc, "Invalid user_id"); + ctx->user_id = kuid; ctx->user_id_present = true; break; case OPT_GROUP_ID: - ctx->group_id = make_kgid(fsc->user_ns, result.uint_32); - if (!gid_valid(ctx->group_id)) + kgid = make_kgid(fsc->user_ns, result.uint_32);; + if (!gid_valid(kgid)) return invalfc(fsc, "Invalid group_id"); + /* + * The requested gid must be representable in the + * filesystem's idmapping. + */ + if (!kgid_has_mapping(fsc->user_ns, kgid)) + return invalfc(fsc, "Invalid group_id"); + ctx->group_id = kgid; ctx->group_id_present = true; break;

2 months, 1 week

2
1
0 0

[PATCH] arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity

by Dragan Simic

All batches of the Pine64 Pinebook Pro, except the latest batch (as of 2024) whose hardware design was revised due to the component shortage, use a 1S lithium battery whose nominal/design capacity is 10,000 mAh, according to the battery datasheet. [1][2] Let's correct the design full-charge value in the Pinebook Pro board dts, to improve the accuracy of the hardware description, and to hopefully improve the accuracy of the fuel gauge a bit on all units that don't belong to the latest batch. The above-mentioned latest batch uses a different 1S lithium battery with a slightly lower capacity, more precisely 9,600 mAh. To make the fuel gauge work reliably on the latest batch, a sample battery would need to be sent to CellWise, to obtain its proprietary battery profile, whose data goes into "cellwise,battery-profile" in the Pinebook Pro board dts. Without that data, the fuel gauge reportedly works unreliably, so changing the design capacity won't have any negative effects on the already unreliable operation of the fuel gauge in the Pinebook Pros that belong to the latest batch. According to the battery datasheet, its voltage can go as low as 2.75 V while discharging, but it's better to leave the current 3.0 V value in the dts file, because of the associated Pinebook Pro's voltage regulation issues. [1] https://wiki.pine64.org/index.php/Pinebook_Pro#Battery [2] https://files.pine64.org/doc/datasheet/pinebook/40110175P%203.8V%2010000mAh… Fixes: c7c4d698cd28 ("arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts") Cc: stable(a)vger.kernel.org Cc: Marek Kraus <gamiee(a)pine64.org> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts index 294eb2de263d..c918968714e4 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts @@ -37,7 +37,7 @@ backlight: edp-backlight { bat: battery { compatible = "simple-battery"; - charge-full-design-microamp-hours = <9800000>; + charge-full-design-microamp-hours = <10000000>; voltage-max-design-microvolt = <4350000>; voltage-min-design-microvolt = <3000000>; };

2 months, 1 week

2
1
0 0

Re: Patch "drm: zynqmp_dpsub: Always register bridge" has been added to the 6.9-stable tree

by Sean Anderson

Hi Sasha, Please also pick [1] when it is applied. --Sean [1] https://lore.kernel.org/all/974d1b062d7c61ee6db00d16fa7c69aa1218ee02.171619… On 6/3/24 07:46, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm: zynqmp_dpsub: Always register bridge > > to the 6.9-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-zynqmp_dpsub-always-register-bridge.patch > and it can be found in the queue-6.9 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit d6817dc61b3b6a1e4f098b25109e7f2ecaaf0ee8 > Author: Sean Anderson <sean.anderson(a)linux.dev> > Date: Fri Mar 8 15:47:41 2024 -0500 > > drm: zynqmp_dpsub: Always register bridge > > [ Upstream commit be3f3042391d061cfca2bd22630e0d101acea5fc ] > > We must always register the DRM bridge, since zynqmp_dp_hpd_work_func > calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be > initialized. We do this before zynqmp_dpsub_drm_init since that calls > drm_bridge_attach. This fixes the following lockdep warning: > > [ 19.217084] ------------[ cut here ]------------ > [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) > [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 > [ 19.241696] Modules linked in: > [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 > [ 19.252046] Hardware name: xlnx,zynqmp (DT) > [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func > [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 19.269104] pc : __mutex_lock+0x4bc/0x550 > [ 19.273364] lr : __mutex_lock+0x4bc/0x550 > [ 19.277592] sp : ffffffc085c5bbe0 > [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 > [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 > [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 > [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 > [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 > [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 > [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 > [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 > [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 > [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 > [ 19.356581] Call trace: > [ 19.359160] __mutex_lock+0x4bc/0x550 > [ 19.363032] mutex_lock_nested+0x24/0x30 > [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c > [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 > [ 19.376364] process_one_work+0x3ac/0x988 > [ 19.380660] worker_thread+0x398/0x694 > [ 19.384736] kthread+0x1bc/0x1c0 > [ 19.388241] ret_from_fork+0x10/0x20 > [ 19.392031] irq event stamp: 183 > [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 > [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 > [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c > [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c > [ 19.432614] ---[ end trace 0000000000000000 ]--- > > Fixes: eb2d64bfcc17 ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") > Signed-off-by: Sean Anderson <sean.anderson(a)linux.dev> > Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> > Reviewed-by: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> > Link: https://patchwork.freedesktop.org/patch/msgid/20240308204741.3631919-1-sean… > (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae) > Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c > index 88eb33acd5f0d..face8d6b2a6fb 100644 > --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c > +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c > @@ -256,12 +256,12 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev) > if (ret) > goto err_dp; > > + drm_bridge_add(dpsub->bridge); > + > if (dpsub->dma_enabled) { > ret = zynqmp_dpsub_drm_init(dpsub); > if (ret) > goto err_disp; > - } else { > - drm_bridge_add(dpsub->bridge); > } > > dev_info(&pdev->dev, "ZynqMP DisplayPort Subsystem driver probed"); > @@ -288,9 +288,8 @@ static void zynqmp_dpsub_remove(struct platform_device *pdev) > > if (dpsub->drm) > zynqmp_dpsub_drm_cleanup(dpsub); > - else > - drm_bridge_remove(dpsub->bridge); > > + drm_bridge_remove(dpsub->bridge); > zynqmp_disp_remove(dpsub); > zynqmp_dp_remove(dpsub); >

2 months, 1 week

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024