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