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
