Hi! Sorry for the late reply, I had to take some time off work unexpectedly. This is normal (although not great TBH, I'm not sure we should be printing an error message for that), it's the result of fwupd trying to probe the MST hub to see if it's a specific Dell dock that can receive updates over DP aux, but it's not smart enough to know it doesn't need to poke the DP aux ranges of downstream branches or non-MST ports in general. Would definitely accept patches to make this a non-error, or at least make this a non-error when the read/writes come from userspace On Thu, 2022-02-17 at 16:54 +0100, Michel Dänzer wrote: > On 2022-02-16 15:39, Jocelyn Falempe wrote: > > Hi, > > > > When using a Lenovo dock, I often get this error message on dmesg: > > > > [drm] *ERROR* mstb 0000000057b5b857 port 1: DPCD read on addr 0x4b0 for 1 > > bytes NAKed > > > > It's caused by fwupd which tries to read from /dev/drm_dp_aux4 > > > > I opened an issue on fwupd: > > https://github.com/fwupd/fwupd/issues/4284 > > > > But it turns out, it's probably an issue in the drm mst code instead. > > > > When I connect my Dock (Lenovo Thinkpad Thunderbold 3 Gen 2), I get 3 > > drm_dp_aux[] created: > > > > /dev/drm_dp_aux[456] > > > > Reading from this devices at any address will always get the NAKed error > > above, unless there is an actual DP monitor connected (HDMI monitor or > > nothing connected gives a NAK) > > > > Each time I connect or disconnect a monitor on the dock, this 3 > > /dev/drm_dp_aux[] are destroyed and recreated. > > > > So I think the device /dev/drm_dp_aux[] should be created only if there is > > an actual monitor connected that can reply to it. > > What's the purpose of providing userspace a device which can't be read or > > written ? (or maybe just fail the open() call, like Mario suggested on the > > fwupd issue, so the devices are still there with the same numbering) > > > > On the other hand, we can also consider that it's expected to get NAck in > > drm_dp_send_dpcd_read() and replace drm_err() with drm_dbg() > > > > what do you think ? > > > > Adding Lyude, AFAIK she's looked into this before. > > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
