Date:   Mon, 19 Oct 2020 18:33:22 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Ed W <lists@...dgooses.com>, linux-kernel@...r.kernel.org,
        Hans de Goede <hdegoede@...hat.com>
Cc:     fe@....tdt.de, "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform
 driver

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@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists