On 22.10.20 11:38, Ed W wrote: Hi, > As a compromise can you change your userland to cope with dynamic names? I see two simple ways: > > 1) udev rule to set name as you wish can you give an example of udev rule depending on bios version ? > To recap though, the situation for many years was that the naming convention was board specific. Yes, I perhaps should have changed them to something like "frontpanel:...", but I left them just like they were for apu1. Don't see any need to have them separate between board revisions. (nobody ever complained about it, couldn't even find a user of this old led-only driver on apu>=2 boards - everybody seemed to either ignore it completely or use raw gpios via /dev/mem - maybe because the driver did not support and even prevented using the key or other gpios). BTW: Pcengines folks officially recommended that "userland driver" via /dev/mem. And I couldn't find a single distro that shipped the old leds-only driver. Now pcengines folks came around with yet another different naming. No idea why the had to put in the word "led" into led names. Oh, hell, we ca be lucky their didn't use the schematics signal names ... > There is then just a small window (less than a year I think?) where users saw the name change to be > non board specific (ie your new module). I would hazard a guess that given the speed of mainstream > releases, few end users actually saw this change yet, or would notice? Those who did already > accommodated the name change, so I would hazard a guess they can cope with the revert? (or not even > notice?) It has been communicated and discussed in APU community (and directly to pcengines, too) Most of the responses were happy to have a proper driver now, the existance of the old driver wasn't actually well-known. > I just want to get APU5/6 > support in, which is affecting some real boards I want to use in volume. I don't feel the current > situation of duplicate devices should stay though. As already mentioned, for APU5/6 I don't mind if LED name changes (again, assuming all boards in the field already have recent enough fw). BTW: I wonder why you're so keen on changing things for apu2..4, if you're only interested on apu5/6. > My opinion is that we punt "this breaks userland" to being the board vendors problem now. > The board is configured largely through ACPI, so if the upstream > changes the ACPI, then it's on them, not us. And what's the board vendor going to do about that ? Practically ? They didn't even talk to me (known I'm the maintainer of the driver for their boards) - sorry, I don't think they ever do anything. In the end, responsibility for the whole operating system is ours, the kernel maintainer's. It's always been that way - just have a look at the thousands of board or device specific quirks all around the kernel. This one of the major points where Linux is different from Windows. Interface/protocol stability never has been a virtue of hw vendors, even in heavily standardized fields like USB. (okay, I have to stop myself from ranting against hw vendors, otherwise I'd have to write an 1k pages book about that :o) We, the kernel maintainers, are the ones who get blamed if anything breaks. Linux has a long history of stability and consistency (one of the major reaons for picking Linux in professional fields, especially for embedded). We put *a lot* of efforts into that, this takes up a *huge* portion of kernel maintenance work. > This seems to be the direction the kernel is heading, with ACPI and device trees being used to > configure the boards, in preference to heavy platform drivers? Device tree is very different from ACPI (not just technically). We've got coordinated, contigious standardization processes here. Not by corporate committees, but the folks on the basis, who're doing the actual work and know the actual requirements and environments. Most of the work is actually coming from the Linux kernel community. And DT is designed to be easily customized (eg. rewriting in by the bootloader, dynamic overlays, ...). Ever tried that w/ ACPI ? --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
