Message-ID: <f17c4eb9-a7d5-4235-1216-969337a2e665@metux.net>
Date:   Thu, 22 Oct 2020 15:20:05 +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: Conditional init of pcengines leds/keys gpios

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

Powered by blists - more mailing lists