Re: [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep

["Danilo Krummrich" <dakr@kernel.org>]

On Wed Mar 4, 2026 at 10:02 PM CET, Dave Airlie wrote:
> On Thu, 5 Mar 2026 at 03:14, Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> On Tue Feb 24, 2026 at 4:17 AM CET, Dave Airlie wrote:
>> > From: Dave Airlie <airlied@redhat.com>
>> >
>> > If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
>> > then just tell it the device is busy instead of crashing in the GSP
>> > code.
>> >
>> > WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>> > Modules linked in: overlay uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep s>
>> > snd_soc_acpi intel_rapl_msr libarc4 kvm crc8 soundwire_bus irqbypass snd_soc_sdca rapl iwlwifi snd_soc_avs uvcvideo intel_cstate think_lmi uvc firmware_attributes_class intel_uncore intel_wmi_thunderbolt wmi_bmof snd_hda_codec_conexant snd_hda_codec_nvhdmi videobuf2_vmalloc snd_soc_hda_codec cfg80211 videobu>
>> > processor_thermal_mbox sparse_keymap intel_soc_dts_iosf intel_pch_thermal platform_profile rfkill snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad joydev loop nfnetlink zram lz4hc_compress lz4_compress xfs wacom hid_microsoft ff_memless nouveau ucsi_acpi typec_ucsi>
>>
>> I'd remove the modules linked in, it seems not relevant.
>>
>> > CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
>> > Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
>> > RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>> >
>> > This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them away while fw updates are happening.
>>
>> s/away/awake/ and line length.
>>
>> > Cc: stable@vger.kernel.org
>>
>> Do we want this backported before GSP introduction?
>>
>> I.e. if it's only about the WARN_ON() and otherwise doesn't cause problems it
>> should probably be
>>
>> Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
>>
>> otherwise
>>
>> Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector")
>
> Go back to this for safety, probably won't blow up but it could still
> cause wierd register timeouts.
>
>>
>> > Signed-off-by: Dave Airlie <airlied@redhat.com<
>>
>> No need to resend, I can fix up the above (and the minor typo in the SoB) on
>> apply.

Applied to drm-misc-fixes, thanks!