On Tue, Mar 05, 2024 at 09:15:06AM -0800, Dmitry Torokhov wrote: > On Tue, Mar 05, 2024 at 11:10:42AM +0100, Uwe Kleine-König wrote: > > On a PC Engines APU our admins are faced with: > > > > $ dmesg | grep -c "gpio-keys-polled gpio-keys-polled: unable to claim gpio 0, err=-517" > > 261 > > > > Such a message always appears when e.g. a new USB device is plugged in. > > > > Suppress this message which considerably clutters the kernel log for > > EPROBE_DEFER (i.e. -517). > > I'll apply this, but that seems to be a misconfiguration somewhere - we > expect deferred probes to succeed eventually, here it looks like it > stays deferred forever and each time a new devices gets plugged in we > try to resolve deferred probe again and again. > > Why doesn't gpio 0 become available? This is an x86 machine and I don't even know why the device actually exists. Also I have no idea what gpio 0 should be, there seems to be a gpio controller[1], but its GPIO numbers start at 512. I found a bug report about this this issue: https://github.com/pcengines/apu2-documentation/issues/204 Anyhow, I think my patch is fine. I forwarded the bug report to my admin who might or might not dig deeper. Best regards and thanks, Uwe [1] /sys/devices/pci0000:00/AMD0030:00/gpio/gpiochip512 -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
