May 2024 - Linux-stable-mirror

[PATCH v2] i2c: ocores: set IACK bit after core is enabled

by Grygorii Tertychnyi

Setting IACK bit when core is disabled does not clear the "Interrupt Flag" bit in the status register, and the interrupt remains pending. Sometimes it causes failure for the very first message transfer, that is usually a device probe. Hence, set IACK bit after core is enabled to clear pending interrupt. Fixes: 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller") Signed-off-by: Grygorii Tertychnyi <grygorii.tertychnyi(a)leica-geosystems.com> Acked-by: Peter Korsgaard <peter(a)korsgaard.com> Cc: stable(a)vger.kernel.org --- V1 -> V2: Added "Acked-by:", "Fixes:" and "Cc:" tags drivers/i2c/busses/i2c-ocores.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c index e106af83cef4..350ccfbe8634 100644 --- a/drivers/i2c/busses/i2c-ocores.c +++ b/drivers/i2c/busses/i2c-ocores.c @@ -442,8 +442,8 @@ static int ocores_init(struct device *dev, struct ocores_i2c *i2c) oc_setreg(i2c, OCI2C_PREHIGH, prescale >> 8); /* Init the device */ - oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK); oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN); + oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK); return 0; } -- 2.43.0

3 months, 4 weeks

5
5
0 0

[PATCH AUTOSEL 6.9 01/23] drm/amd/display: Exit idle optimizations before HDCP execution

by Sasha Levin

From: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> [ Upstream commit f30a3bea92bdab398531129d187629fb1d28f598 ] [WHY] PSP can access DCN registers during command submission and we need to ensure that DCN is not in PG before doing so. [HOW] Add a callback to DM to lock and notify DC for idle optimization exit. It can't be DC directly because of a potential race condition with the link protection thread and the rest of DM operation. Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Charlene Liu <charlene.liu(a)amd.com> Acked-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c | 10 ++++++++++ drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h | 8 ++++++++ 2 files changed, 18 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c index 5e01c6e24cbc8..9a5a1726acaf8 100644 --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c @@ -88,6 +88,14 @@ static uint8_t is_cp_desired_hdcp2(struct mod_hdcp *hdcp) !hdcp->connection.is_hdcp2_revoked; } +static void exit_idle_optimizations(struct mod_hdcp *hdcp) +{ + struct mod_hdcp_dm *dm = &hdcp->config.dm; + + if (dm->funcs.exit_idle_optimizations) + dm->funcs.exit_idle_optimizations(dm->handle); +} + static enum mod_hdcp_status execution(struct mod_hdcp *hdcp, struct mod_hdcp_event_context *event_ctx, union mod_hdcp_transition_input *input) @@ -543,6 +551,8 @@ enum mod_hdcp_status mod_hdcp_process_event(struct mod_hdcp *hdcp, memset(&event_ctx, 0, sizeof(struct mod_hdcp_event_context)); event_ctx.event = event; + exit_idle_optimizations(hdcp); + /* execute and transition */ exec_status = execution(hdcp, &event_ctx, &hdcp->auth.trans_input); trans_status = transition( diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h b/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h index a4d344a4db9e1..cdb17b093f2b8 100644 --- a/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h +++ b/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h @@ -156,6 +156,13 @@ struct mod_hdcp_ddc { } funcs; }; +struct mod_hdcp_dm { + void *handle; + struct { + void (*exit_idle_optimizations)(void *handle); + } funcs; +}; + struct mod_hdcp_psp { void *handle; void *funcs; @@ -272,6 +279,7 @@ struct mod_hdcp_display_query { struct mod_hdcp_config { struct mod_hdcp_psp psp; struct mod_hdcp_ddc ddc; + struct mod_hdcp_dm dm; uint8_t index; }; -- 2.43.0

4 months

4
27
0 0

[PATCH AUTOSEL 6.9 01/35] ssb: Fix potential NULL pointer dereference in ssb_device_uevent()

by Sasha Levin

From: Rand Deeb <rand.sec96(a)gmail.com> [ Upstream commit 789c17185fb0f39560496c2beab9b57ce1d0cbe7 ] The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rand Deeb <rand.sec96(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/20240306123028.164155-1-rand.sec96@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/ssb/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c index 9f30e0edadfe2..bdb6595ffd2d5 100644 --- a/drivers/ssb/main.c +++ b/drivers/ssb/main.c @@ -341,11 +341,13 @@ static int ssb_bus_match(struct device *dev, struct device_driver *drv) static int ssb_device_uevent(const struct device *dev, struct kobj_uevent_env *env) { - const struct ssb_device *ssb_dev = dev_to_ssb_dev(dev); + const struct ssb_device *ssb_dev; if (!dev) return -ENODEV; + ssb_dev = dev_to_ssb_dev(dev); + return add_uevent_var(env, "MODALIAS=ssb:v%04Xid%04Xrev%02X", ssb_dev->id.vendor, ssb_dev->id.coreid, -- 2.43.0

4 months

3
38
0 0

[PATCH AUTOSEL 6.9 01/15] fs/writeback: bail out if there is no more inodes for IO and queued once

by Sasha Levin

From: Kemeng Shi <shikemeng(a)huaweicloud.com> [ Upstream commit d92109891f21cf367caa2cc6dff11a4411d917f4 ] For case there is no more inodes for IO in io list from last wb_writeback, We may bail out early even there is inode in dirty list should be written back. Only bail out when we queued once to avoid missing dirtied inode. This is from code reading... Signed-off-by: Kemeng Shi <shikemeng(a)huaweicloud.com> Link: https://lore.kernel.org/r/20240228091958.288260-3-shikemeng@huaweicloud.com Reviewed-by: Jan Kara <jack(a)suse.cz> [brauner(a)kernel.org: fold in memory corruption fix from Jan in [1]] Link: https://lore.kernel.org/r/20240405132346.bid7gibby3lxxhez@quack3 [1] Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/fs-writeback.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index e4f17c53ddfcf..d31853032a931 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2069,6 +2069,7 @@ static long wb_writeback(struct bdi_writeback *wb, struct inode *inode; long progress; struct blk_plug plug; + bool queued = false; blk_start_plug(&plug); for (;;) { @@ -2111,8 +2112,10 @@ static long wb_writeback(struct bdi_writeback *wb, dirtied_before = jiffies; trace_writeback_start(wb, work); - if (list_empty(&wb->b_io)) + if (list_empty(&wb->b_io)) { queue_io(wb, work, dirtied_before); + queued = true; + } if (work->sb) progress = writeback_sb_inodes(work->sb, wb, work); else @@ -2127,7 +2130,7 @@ static long wb_writeback(struct bdi_writeback *wb, * mean the overall work is done. So we keep looping as long * as made some progress on cleaning pages or inodes. */ - if (progress) { + if (progress || !queued) { spin_unlock(&wb->list_lock); continue; } -- 2.43.0

4 months

3
18
0 0

Candidates for stable v6.9..v6.10-rc1 Use After Free

by Ronnie Sahlberg

These commits reference use.after.free between v6.9 and v6.10-rc1 These commits are not, yet, in stable/linux-rolling-stable. Let me know if you would rather me compare to a different repo/branch. The list has been manually pruned to only contain commits that look like actual issues. If they contain a Fixes line it has been verified that at least one of the commits that the Fixes tag(s) reference is in stable/linux-rolling-stable 90e823498881fb8a91d8 5c9c5d7f26acc2c669c1 573601521277119f2e2b f88da7fbf665ffdcbf5b 47a92dfbe01f41bcbf35 5bc9de065b8bb9b8dd87 5f204051d998ec3d7306 be84f32bb2c981ca6709 88ce0106a1f603bf360c -- Ronnie Sahlberg [Principal Software Engineer, Linux] P 775 384 8203 | E [email] | W ciq.com

4 months

2
1
0 0

Bug in Kernel 6.8.x, 6.9.x Causing Trace/Panic During Shutdown/Reboot

by Ilkka Naulapää

Greetings fellas, I have encountered a critical bug in the Linux vanilla kernel that leads to a kernel panic during the shutdown or reboot process. The issue arises after all services, including `journald`, have been stopped. As a result, the machine fails to complete the shutdown or reboot procedure, effectively causing the system to hang and not shut down or reboot. Here are the details of the issue: - Affected Versions: Before kernel version 6.8.10, the bug caused a quick display of a kernel trace dump before the shutdown/reboot completed. Starting from version 6.8.10 and continuing into version 6.9.0 and 6.9.1, this issue has escalated to a kernel panic, preventing the shutdown or reboot from completing and leaving the machine stuck. - Symptoms: - In normal shutdown/reboot scenarios, the kernel trace dump briefly appears as the last message on the screen. - In rescue mode, the kernel panic message is displayed. Normally it is not shown. Since `journald` is stopped before this issue occurs, no textual logs are available. However, I have captured two pictures illustrating these related issues, which I am attaching to this email for your reference. Also added my custom kernel config. Thank you for your attention to this matter. Please let me know if any additional information is required to assist in diagnosing and resolving this bug. Best regards, Ilkka Naulapää

4 months

4
23
0 0

[PATCH v4] media: venus: fix use after free in vdec_close

by Dikshita Agarwal

There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close. Cc: stable(a)vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> --- Changes since v3: - Fixed style issue with fixes tag Changes since v2: - Fixed email id Changes since v1: - Added fixes and stable tags drivers/media/platform/qcom/venus/vdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c index 29130a9..56f8a25 100644 --- a/drivers/media/platform/qcom/venus/vdec.c +++ b/drivers/media/platform/qcom/venus/vdec.c @@ -1747,6 +1747,7 @@ static int vdec_close(struct file *file) vdec_pm_get(inst); + cancel_work_sync(&inst->delayed_process_work); v4l2_m2m_ctx_release(inst->m2m_ctx); v4l2_m2m_release(inst->m2m_dev); vdec_ctrl_deinit(inst); -- 2.7.4

4 months

2
1
0 0

Re: Bluetooth kernel BUG with Intel AX211 (regression in 6.1.83)

by Linux regression tracking (Thorsten Leemhuis)

Hi stable team (and Bluetooth maintainers), I noticed a regression report about a BT problem in 6.1.y: On 21.04.24 15:54, Jeremy Lainé wrote: > > After upgrading my kernel to Debian's latest version (6.1.85), I > started encountering systematic kernel BUGs at boot, making the > bluetooth stack unusable. I initially reported this to Debian's bug > tracker: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069301 > > .. but have since confirmed that this is reproducible with vanilla > kernels, including the latest 6.1.y version (6.1.87). > > I tried various kernel versions (straight from kernel.org) to pinpoint > when the problem started occurring and the resultats are: Jeremy later wrote: > # first bad commit: [6083089ab00631617f9eac678df3ab050a9d837a] > Bluetooth: hci_conn: Consolidate code for aborting connections https://lore.kernel.org/all/8eeb980a-f04a-4e94-8065-25566cfef4dd@molgen.mpg… That's a13f316e90fdb1 ("Bluetooth: hci_conn: Consolidate code for aborting connections") [v6.6-rc1, v6.1.83 (6083089ab00631)] FWIW, there is a fix for the mainline commit under review: https://lore.kernel.org/all/20240411151929.403263-1-kovalev@altlinux.org/ But it is likely unrelated, as Jeremy later also wrote: > I'm now running 6.9-rc5 and have not been able to reproduce the issue, https://lore.kernel.org/all/CADRbXaA2yFjMo=_8_ZTubPbrrmWH9yx+aG5pUadnk395ko… Makes me wonder if 6.1.y is missing some other change a13f316e90fdb1 depends on. Ciao, Thorsten > I have included a trace below, and full system details are available > in the Debian bug listed above. Can you suggest any other tests I can > perform to help diagnose the origin of the problem? > > [ 22.660847] list_del corruption, ffff94d9f6302000->prev is > LIST_POISON2 (dead000000000122) > [ 22.660887] ------------[ cut here ]------------ > [ 22.660890] kernel BUG at lib/list_debug.c:56! > [ 22.660907] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI > [ 22.660917] CPU: 10 PID: 139 Comm: kworker/u25:0 Not tainted > 6.1.0-20-amd64 #1 Debian 6.1.85-1 > [ 22.660929] Hardware name: Dell Inc. XPS 9315/00KRKP, BIOS 1.19.1 03/14/2024 > [ 22.660936] Workqueue: hci0 hci_cmd_sync_work [bluetooth] > [ 22.661128] RIP: 0010:__list_del_entry_valid.cold+0x4b/0x6f > [ 22.661147] Code: fe ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 48 18 7a > 9f e8 14 a1 fe ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 10 18 7a 9f e8 00 > a1 fe ff <0f> 0b 48 89 fe 48 c7 c7 d8 17 7a 9f e8 ef a0 fe ff 0f 0b 48 > 89 fe > [ 22.661156] RSP: 0000:ffffae0e406efde0 EFLAGS: 00010246 > [ 22.661164] RAX: 000000000000004e RBX: ffff94d9f6302000 RCX: 0000000000000027 > [ 22.661172] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff94dfaf8a03a0 > [ 22.661177] RBP: ffff94d859392000 R08: 0000000000000000 R09: ffffae0e406efc78 > [ 22.661182] R10: 0000000000000003 R11: ffffffff9fed4448 R12: ffff94d859392000 > [ 22.661187] R13: ffff94d859392770 R14: ffff94d858cb9800 R15: dead000000000100 > [ 22.661194] FS: 0000000000000000(0000) GS:ffff94dfaf880000(0000) > knlGS:0000000000000000 > [ 22.661202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 22.661208] CR2: 00007f423c024038 CR3: 0000000799c04000 CR4: 0000000000750ee0 > [ 22.661214] PKRU: 55555554 > [ 22.661218] Call Trace: > [ 22.661225] <TASK> > [ 22.661232] ? __die_body.cold+0x1a/0x1f > [ 22.661246] ? die+0x2a/0x50 > [ 22.661257] ? do_trap+0xc5/0x110 > [ 22.661268] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661279] ? do_error_trap+0x6a/0x90 > [ 22.661289] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661298] ? exc_invalid_op+0x4c/0x60 > [ 22.661307] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661316] ? asm_exc_invalid_op+0x16/0x20 > [ 22.661328] ? __list_del_entry_valid.cold+0x4b/0x6f > [ 22.661337] hci_conn_del+0x136/0x3e0 [bluetooth] > [ 22.661466] hci_abort_conn_sync+0xaa/0x230 [bluetooth] > [ 22.661632] ? abort_conn_sync+0x3d/0x70 [bluetooth] > [ 22.661751] hci_cmd_sync_work+0x9f/0x150 [bluetooth] > [ 22.661915] process_one_work+0x1c4/0x380 > [ 22.661929] worker_thread+0x4d/0x380 > [ 22.661940] ? rescuer_thread+0x3a0/0x3a0 > [ 22.661950] kthread+0xd7/0x100 > [ 22.661959] ? kthread_complete_and_exit+0x20/0x20 > [ 22.661969] ret_from_fork+0x1f/0x30 > [ 22.661984] </TASK> > [ 22.661987] Modules linked in: ctr ccm nft_chain_nat xt_MASQUERADE > nf_nat nf_conntrack_netlink br_netfilter bridge stp llc xfrm_user > xfrm_algo nvme_fabrics rfcomm snd_seq_dummy snd_hrtimer snd_seq > snd_seq_device cmac algif_hash algif_skcipher af_alg snd_ctl_led > snd_soc_sof_sdw snd_soc_intel_hda_dsp_common snd_sof_probes > snd_soc_intel_sof_maxim_common snd_soc_rt715_sdca snd_soc_rt1316_sdw > regmap_sdw_mbq snd_hda_codec_hdmi regmap_sdw overlay ip6t_REJECT > nf_reject_ipv6 xt_hl ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 > xt_LOG qrtr nf_log_syslog nft_limit bnep ipmi_devintf ipmi_msghandler > xt_limit xt_addrtype xt_tcpudp xt_conntrack nf_conntrack > nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables libcrc32c nfnetlink > binfmt_misc nls_ascii nls_cp437 vfat fat x86_pkg_temp_thermal > intel_powerclamp coretemp snd_soc_dmic snd_sof_pci_intel_tgl > snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation > soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp > snd_sof snd_sof_utils > [ 22.662122] snd_soc_hdac_hda snd_hda_ext_core > snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core kvm_intel > snd_compress btusb soundwire_bus btrtl kvm btbcm snd_hda_intel btintel > snd_intel_dspcfg btmtk dell_laptop snd_intel_sdw_acpi irqbypass > ledtrig_audio bluetooth snd_hda_codec i915 snd_hda_core rapl mei_hdcp > intel_rapl_msr snd_hwdep processor_thermal_device_pci dell_wmi joydev > hid_sensor_als intel_cstate jitterentropy_rng processor_thermal_device > snd_pcm hid_sensor_trigger processor_thermal_rfim dell_smbios > ucsi_acpi dcdbas hid_sensor_iio_common processor_thermal_mbox > drm_buddy intel_uncore iwlmvm pcspkr drbg iTCO_wdt typec_ucsi > dell_wmi_sysman snd_timer industrialio_triggered_buffer > drm_display_helper processor_thermal_rapl mei_me dell_wmi_descriptor > firmware_attributes_class kfifo_buf wmi_bmof ansi_cprng intel_pmc_bxt > cec snd roles intel_rapl_common ecdh_generic iTCO_vendor_support > int3403_thermal watchdog ecc industrialio mei soundcore typec > int3400_thermal rc_core mac80211 > [ 22.662253] int340x_thermal_zone intel_pmc_core button intel_hid > acpi_thermal_rel sparse_keymap ttm acpi_pad acpi_tad drm_kms_helper > libarc4 igen6_edac i2c_algo_bit ac evdev hid_multitouch serio_raw > iwlwifi cfg80211 rfkill msr parport_pc ppdev lp drm parport fuse loop > efi_pstore configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 > mbcache jbd2 crc32c_generic usbhid hid_sensor_custom hid_sensor_hub > dm_crypt dm_mod intel_ishtp_hid nvme nvme_core t10_pi > crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic > crc64 ahci libahci crct10dif_pclmul crct10dif_common libata > crc32_pclmul crc32c_intel scsi_mod spi_pxa2xx_platform > ghash_clmulni_intel dw_dmac hid_generic sha512_ssse3 scsi_common > dw_dmac_core xhci_pci sha512_generic sha256_ssse3 xhci_hcd sha1_ssse3 > usbcore i2c_hid_acpi intel_lpss_pci aesni_intel video intel_ish_ipc > i2c_i801 i2c_hid intel_lpss psmouse thunderbolt crypto_simd cryptd > i2c_smbus vmd intel_ishtp usb_common idma64 hid battery wmi > [ 22.662422] ---[ end trace 0000000000000000 ]--- > > Cheers, > > Jeremy #regzbot ^introduced 6083089ab0063 #regzbot title Bluetooth kernel BUG with Intel AX211 #regzbot duplicate: https://lore.kernel.org/all/8eeb980a-f04a-4e94-8065-25566cfef4dd@molgen.mpg… #regzbot ignore-activit

4 months

5
9
0 0

[PATCH AUTOSEL 5.10 1/7] drm/amd/display: Exit idle optimizations before HDCP execution

by Sasha Levin

From: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> [ Upstream commit f30a3bea92bdab398531129d187629fb1d28f598 ] [WHY] PSP can access DCN registers during command submission and we need to ensure that DCN is not in PG before doing so. [HOW] Add a callback to DM to lock and notify DC for idle optimization exit. It can't be DC directly because of a potential race condition with the link protection thread and the rest of DM operation. Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Charlene Liu <charlene.liu(a)amd.com> Acked-by: Alex Hung <alex.hung(a)amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c | 10 ++++++++++ drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h | 8 ++++++++ 2 files changed, 18 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c index fa8aeec304ef4..c39cb4b6767cf 100644 --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c @@ -86,6 +86,14 @@ static uint8_t is_cp_desired_hdcp2(struct mod_hdcp *hdcp) !hdcp->connection.is_hdcp2_revoked; } +static void exit_idle_optimizations(struct mod_hdcp *hdcp) +{ + struct mod_hdcp_dm *dm = &hdcp->config.dm; + + if (dm->funcs.exit_idle_optimizations) + dm->funcs.exit_idle_optimizations(dm->handle); +} + static enum mod_hdcp_status execution(struct mod_hdcp *hdcp, struct mod_hdcp_event_context *event_ctx, union mod_hdcp_transition_input *input) @@ -448,6 +456,8 @@ enum mod_hdcp_status mod_hdcp_process_event(struct mod_hdcp *hdcp, memset(&event_ctx, 0, sizeof(struct mod_hdcp_event_context)); event_ctx.event = event; + exit_idle_optimizations(hdcp); + /* execute and transition */ exec_status = execution(hdcp, &event_ctx, &hdcp->auth.trans_input); trans_status = transition( diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h b/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h index eed560eecbab4..fb195276fb704 100644 --- a/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h +++ b/drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h @@ -143,6 +143,13 @@ struct mod_hdcp_ddc { } funcs; }; +struct mod_hdcp_dm { + void *handle; + struct { + void (*exit_idle_optimizations)(void *handle); + } funcs; +}; + struct mod_hdcp_psp { void *handle; void *funcs; @@ -252,6 +259,7 @@ struct mod_hdcp_display_query { struct mod_hdcp_config { struct mod_hdcp_psp psp; struct mod_hdcp_ddc ddc; + struct mod_hdcp_dm dm; uint8_t index; }; -- 2.43.0

4 months

2
7
0 0

Re: Kernel 5.15.150 black screen with AMD Raven/Picasso GPU

by Armin Wolf

Am 23.05.24 um 15:13 schrieb Barry Kauler: > On Wed, May 22, 2024 at 12:58 AM Armin Wolf <W_Armin(a)gmx.de> wrote: >> Am 20.05.24 um 18:22 schrieb Alex Deucher: >> >>> On Sat, May 18, 2024 at 8:17 PM Armin Wolf <W_Armin(a)gmx.de> wrote: >>>> Am 17.05.24 um 03:30 schrieb Barry Kauler: >>>> >>>>> Armin, Yifan, Prike, >>>>> I will top-post, so you don't have to scroll down. >>>>> After identifying the commit that causes black screen with my gpu, I >>>>> posted the result to you guys, on May 9. >>>>> It is now May 17 and no reply. >>>>> OK, I have now created a patch that reverts Yifan's commit, compiled >>>>> 5.15.158, and my gpu now works. >>>>> Note, the radeon module is not loaded, so it is not a factor. >>>>> I'm not a kernel developer. I have identified the culprit and it is up >>>>> to you guys to fix it, Yifan especially, as you are the person who has >>>>> created the regression. >>>>> I will attach my patch. >>>>> Regards, >>>>> Barry Kauler >>>> Hi, >>>> >>>> sorry for not responding to your findings. I normally do not work with GPU drivers, >>>> so i hoped one of the amdgpu developers would handle this. >>>> >>>> I CCeddri-devel(a)lists.freedesktop.org and amd-gfx(a)lists.freedesktop.org so that other >>>> amdgpu developers hear from this issue. >>>> >>>> Thanks you for you persistence in finding the offending commit. >>> Likely this patch should not have been ported to 5.15 in the first >>> place. The IOMMU requirements have been dropped from the driver for >>> the last few kernel versions so it is no longer relevant on newer >>> kernels. >>> >>> Alex >> Barry, can you verify that the latest upstream kernel works on you device? >> If yes, then the commit itself is ok and just the backporting itself was wrong. >> >> Thanks, >> Armin Wolf > Armin, > The unmodified 6.8.1 kernel works ok. > I presume that patch was applied long before 6.8.1 got released and > only got backported to 5.15.x recently. > > Regards, > Barry > Great to hear, that means we only have to revert commit 56b522f46681 ("drm/amdgpu: init iommu after amdkfd device init") from the 5.15.y series. I CCed the stable mailing list so that they can revert the offending commit. Thanks, Armin Wolf >>>> Armin Wolf >>>> >>>>> On Thu, May 9, 2024 at 4:08 PM Barry Kauler <bkauler(a)gmail.com> wrote: >>>>>> On Fri, May 3, 2024 at 9:03 PM Armin Wolf <W_Armin(a)gmx.de> wrote: >>>>>>>> ... >>>>>>>> # lspci | grep VGA >>>>>>>> 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. >>>>>>>> [AMD/ATI] Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile >>>>>>>> Series] (rev c2) >>>>>>>> 05:00.7 Non-VGA unclassified device: Advanced Micro Devices, Inc. >>>>>>>> [AMD] Raven/Raven2/Renoir Non-Sensor Fusion Hub KMDF driver >>>>>>>> >>>>>>>> # lspci -n -k >>>>>>>> ... >>>>>>>> 05:00.0 0300: 1002:15d8 (rev c2) >>>>>>>> Subsystem: 1025:1456 >>>>>>>> Kernel driver in use: amdgpu >>>>>>>> Kernel modules: amdgpu >>>>>>>> ... >>>>>>> thanks for informing us of this regression. Since there are four commits affecting >>>>>>> amdgpu in 5.15.150, i suggest that you use "git bisect" to find the faulty commits, >>>>>>> see https://docs.kernel.org/admin-guide/bug-bisect.html for details. >>>>>>> >>>>>>> I think you can speed up the bisecting process by limiting yourself to the AMD DRM >>>>>>> driver directory with "git bisect start -- drivers/gpu/drm/amd", take a look at the >>>>>>> man page of "git bisect" for details. >>>>>>> >>>>>>> Thanks, >>>>>>> Armin Wolf >>>>>> Armin, >>>>>> Thanks for the advice. I am unfamiliar with git on the commandline. >>>>>> Previously only used SmartGit gui. >>>>>> EasyOS requires aufs patch, and for a few days tried to figure out how >>>>>> to use that with git bisect, then gave up. Changed to testing with my >>>>>> "QV" distro, which is more conventional, doesn't need any kernel >>>>>> patches. Managed to get it down to one commit. Here are the steps I >>>>>> followed: >>>>>> >>>>>> # git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git >>>>>> # cd linux-stable >>>>>> # git tag -l | grep '5\.15\.150' >>>>>> v5.15.150 >>>>>> # git checkout -b my5.15.150 v5.15.150 >>>>>> Updating files: 100% (65776/65776), done. >>>>>> Switched to a new branch 'my5.15.150' >>>>>> >>>>>> Copied in my .config then... >>>>>> >>>>>> # make menuconfig >>>>>> # git bisect start -- drivers/gpu/drm/amd >>>>>> # git bisect bad >>>>>> # git bisect good v5.15.149 >>>>>> Bisecting: 1 revision left to test after this (roughly 1 step) >>>>>> [b9a61ee2bb2704e42516e3da962f99dfa98f3b20] drm/amdgpu: reset gpu for >>>>>> s3 suspend abort case >>>>>> # make >>>>>> # rm -rf /boot2 >>>>>> # mkdir -p /boot2/lib/modules >>>>>> # make INSTALL_MOD_STRIP=1 INSTALL_MOD_PATH=/boot2 modules_install >>>>>> # cp arch/x86/boot/bzImage /boot2/vmlinuz >>>>>> # sync >>>>>> ...QV on Acer laptop, with amdgpu, works! >>>>>> # git bisect good >>>>>> Bisecting: 0 revisions left to test after this (roughly 0 steps) >>>>>> [56b522f4668167096a50c39446d6263c96219f5f] drm/amdgpu: init iommu >>>>>> after amdkfd device init >>>>>> # make >>>>>> # mkdir -p /boot2/lib/modules >>>>>> # make INSTALL_MOD_STRIP=1 INSTALL_MOD_PATH=/boot2 modules_install >>>>>> # cp arch/x86/boot/bzImage /boot2/vmlinuz >>>>>> # sync >>>>>> ...QV on Acer laptop, black screen! >>>>>> >>>>>> # git bisect bad >>>>>> 56b522f4668167096a50c39446d6263c96219f5f is the first bad commit >>>>>> commit 56b522f4668167096a50c39446d6263c96219f5f >>>>>> Author: Yifan Zhang <yifan1.zhang(a)amd.com> >>>>>> Date: Tue Sep 28 15:42:35 2021 +0800 >>>>>> >>>>>> drm/amdgpu: init iommu after amdkfd device init >>>>>> >>>>>> [ Upstream commit 286826d7d976e7646b09149d9bc2899d74ff962b ] >>>>>> >>>>>> This patch is to fix clinfo failure in Raven/Picasso: >>>>>> >>>>>> Number of platforms: 1 >>>>>> Platform Profile: FULL_PROFILE >>>>>> Platform Version: OpenCL 2.2 AMD-APP (3364.0) >>>>>> Platform Name: AMD Accelerated Parallel Processing >>>>>> Platform Vendor: Advanced Micro Devices, Inc. >>>>>> Platform Extensions: cl_khr_icd cl_amd_event_callback >>>>>> >>>>>> Platform Name: AMD Accelerated Parallel Processing Number of devices: 0 >>>>>> >>>>>> Signed-off-by: Yifan Zhang <yifan1.zhang(a)amd.com> >>>>>> Reviewed-by: James Zhu <James.Zhu(a)amd.com> >>>>>> Tested-by: James Zhu <James.Zhu(a)amd.com> >>>>>> Acked-by: Felix Kuehling <Felix.Kuehling(a)amd.com> >>>>>> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> >>>>>> Signed-off-by: Sasha Levin <sashal(a)kernel.org> >>>>>> >>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++---- >>>>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>>>> >>>>>> Anything else I should do, to identify what in this commit is the >>>>>> likely culprit? >>>>>> Regards, >>>>>> Barry Kauler

4 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024