On 28/01/2025 09:57, Jens Schmidt wrote:

This is on Debian testing with the following kernel, built from the tarball on kernel.org:

Linux sappc1 6.12.10 #4 SMP PREEMPT_DYNAMIC Fri Jan 17 22:17:45 CET 2025 x86_64 GNU/Linux

More by chance than anything else I noticed this sysfs entry:

/devices/pci0000:00/0000:00:02.0/rc/rc0/input33                                                ^^ immediately after a reboot.  After letting the system run for a while the file name counter may well be in the thousands.

I instrumented function drm_dp_cec_attach to dump the values of the expressions involved in the following test:

if (aux->cec.adap->capabilities == cec_caps &&       aux->cec.adap->available_log_addrs == num_las) {

The result was that on every call I have

aux->cec.adap->capabilities == 0b1101111110   cec_caps                    == 0b0101111110   aux->cec.adap->available_log_addrs == 4   num_las                            == 4

which triggers recreation of the sysfs entry.

So the capabilities differ in CEC_CAP_REPLY_VENDOR_ID.  If I clear that bit in above test, I am back to normal, getting only

/devices/pci0000:00/0000:00:02.0/rc/rc0/input1

and keeping that throughout the runtime of the system.

Could this be related to commit 613f21505b25a4f43f33de00f11afc059bedde2b?

Well spotted! Yes, it is related to that commit.

I'll take a closer look at this tomorrow since this test against cec_caps needs work.

Regards,

Hans