On 13.10.20 23:40, Ed W wrote: > But why are users "in the field" "field" here means litterlly field. Far away from any human being. > updating a kernel willy nilly without also updating the userland > software that talks to it? Of course, we're always testing. Obviously, in the lab, not in the field. And we don't wanna have to adapt existing, well tested, embedded applications for dozens of BIOS versions, which might or might not have certain functionality (it's not just for LEDs, but all the other gpio-attached devices, eg. keys, mpcie reset, simsw, ...), etc. > Why is the kernel upgrade trivial, but the fw upgrade is not an option? Because technicians have to fly out to the installations and replace the whole board (no, certainly no remote updates of the BIOS). The costs per installation are a factor of the board price. > Why not also update the app or setup a udev rule? Again, BIOS version specific. And it's a not just a udev rule, it's a lot of paper work in the application qualification. This is an embedded device, not an cheap office pc. > I would understand if we were talking something fairly major, > but it's the case of matching a > filename that YOU changed from an old name to the current name and it's now changing back to the > original name? I did not change anything, I wrote a completely new driver with full gpio support and attached devices. pcengine folks ignored it for a long time, suddenly the started adding incompatible stuff to their newer firmware. > That's extremely disingenuous!! No, its correct. The apuv1 board (more precisely its SoC) has a completely different FCH. The old driver had some rudimentary support just for the front leds, which actually worked properly on none of my testing boards. I've did several surveys in the apu community - everybody was using some userland program doing raw iomem access (/dev/mem). Haven't found a single Distro that ever shipped that old driver. > It USED to work for the APU2-4 except that YOU removed support for APU2-4 from that module!! Yes, I've proposed removing it, because I could not find a single person who actually used it on apu2/3/4 boards. This might have to with the fact that folks were happy that they now could use other gpio-connected devices, too. And, BTW, it did conflict with the new driver. Note: the old driver is *only* for LEDs, not gpios as such, nor other gpio-attached devices. <skipping stuff that already had been answered> > - Your LED based SIM toggle HAS already gone. So you have another example of userspace being broken > right there. (Seems that this rule isn't so concrete?). Without my knowledge and ackknowledge as the maintainer ! > So you already need to (significantly?) > adjust your userspace code - I'm not seeing how/why the LED change is such a blocker? simsw isn't actively used in the field, the other gpio-consumers (leds, keys, reset, ...) are used in the field. litterally field. simsw was a quick shot on purpose, planned to be replaced by rfkill or portmux. Both still experimental and nothing ready for mainline yet. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
