adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

Hello, on a laptop where I installed Debian testing about 8 months ago, I noticed that the logs are continuously flooded with call traces like the attached snippet (taken from /var/log/kern.log ).

It seems to me that it also used to happen with previous versions of the Linux kernel, but I am under the impression that, with Linux kernel 6.9.7, it got worse. I have upgraded the Linux kernel several times (kernel package provided by the distro, which is Debian testing, as I said), but the bug is still reproducible:

$ uname -srvmo
Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 GNU/Linux

$ uname -srvmo
Linux 6.9.10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.10-1 (2024-07-19) x86_64 GNU/Linux

and with other successive versions.

I see at least 12 of these call traces just after boot, before even starting X (with 'startx'). More of these call traces are sent to the logs after starting X, or after invoking 'xrandr', or after locking the X session (with XScreenSaver), ... I always see these call traces (I mean the bug is always reproducible: each time I boot, each time I call xrandr, ...).

They seem to correspond to no actual issue, as far as I can tell, but they are flooding the logs with a significant flow of text... which is worrying by itself.

What's wrong? How can I stop this log-filling flood? Should I black-list some module, for instance?

The outputs of

# lspci -vnn -d :*:0300

and of

# dmidecode

are attached. Also, I booted with kernel parameters 'drm.debug=0xe log_buf_len=4M ignore_loglevel' and logged in as root right after the boot. The output of

# dmesg

is attached.

Some additional information may be found on the Debian bug report I had previously filed.

Please note that the VBT claims that the laptop has 1 USB-C and 3 legacy DP connectors.

I think the laptop does have 1 USB-C connector (and dmidecode seems to see it).

On the other hand, I cannot spot any external DisplayPort connectors. I cannot see any set of three identical connectors on the "outer surface" of the laptop case, actually. However, the graphics software stack sees them, as confirmed by the output of 'xrandr' (attached).

Could they be internal (unused) connectors?

Or maybe they are not really present in the hardware, and the Linux kernel wrongly thinks they are there, because of some bug...? Could this happen?!?

The DMI in BIOS says:

DMI: Notebook NLxxPUx/NLxxPUx, BIOS 1.07.09 11/17/2023

The label on the bottom of the laptop case says:

MODEL: NL41PU

and

PRODUCT CODE: NL41PU2

According to the same label, the brand should be Clevo.

I bought the laptop from an Italian shop which, among other things, assembles customized laptops, that can be configured through a web configurator (unfortunately, it seems that the website is in Italian only...).

The notebook that I selected (along with other components) is identified as "Work14 i5-1235U DDR4 M.2 14" FullHD" The provided description (translated into English by me) is attached.

I think the Clevo NL41PU laptop is the same as the one described here.

I checked whether there is a BIOS upgrade available. Following from the Clevo support site, I think I found the relevant download server folder, but it seems to me that there is no upgrade later than "1.07.09 11/17/2023"... Actually, I cannot even see that version, which is awkward. Maybe I am misunderstanding something... :-( Or maybe not: I have also asked the shop about possible BIOS upgrades, and they replied to me that there are no BIOS upgrades yet for that model, as far as they can tell.

Please investigate and fix this bug. Thanks a lot for your time and for any help you may provide!

dmesg.out.gz

dmidecode.out.gz

lspci.out.gz

snip_kern.log

work14_description.txt.gz

xrandr.out.gz