From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Ed W <lists@wildgooses.com>, Hans de Goede <hdegoede@redhat.com>,
linux-kernel@vger.kernel.org
Cc: fe@dev.tdt.de, "Enrico Weigelt,
metux IT consult" <info@metux.net>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform driver
Date: Mon, 19 Oct 2020 16:28:15 +0200 [thread overview]
Message-ID: <4a6fe2bc-a4a5-c214-e7fd-2a429dc960e1@metux.net> (raw)
In-Reply-To: <2ecbe677-8f80-17a1-dbf9-dfffa867805c@wildgooses.com>
On 13.10.20 23:46, Ed W wrote:
> The original naming was board specific. Then Enrico (not unreasonably - I actually prefer his
> naming) changed the naming to be non board specific. Then within 2 months PC Engines introduced ACPI
> based config using the old names.
Which "old names" are you referring to ?
The really old apuv1 led-only driver ?
> So if we are holding "userspace breakage" as the gold standard, then the original (also the current)
> names have actually been around longest and likely cause the least userspace breakage.
Exactly. Linus often stated "dont break userland" as a primary goal, and
that with really good reasons: the kernel is *the* hardware abstraction
layer. Having userland to deal with thousands of hardware details in
userland would cause extreme management complexity.
> Also, some other pieces of this module have already been removed (SIM Swap), so there is an existing
> precedent for "userspace breakage" and trimming down this platform driver.
Not quite. SIM swap hasn't been actually used in the field (at least as
far as I know). And we're planning to put it into different subsystem
(probably rfkill) anyways.
> In big picture terms, changing the name of the LED device doesn't seem a huge concern to me... A
> udev rule can setup compatibility forwards/backwards quite trivially I think?
Small kernel update causes existing applications to FAIL. Applications
now have to be changed to deal with *different* configuration, based on
factors like BIOS version.
We're dealing with embedded applications. There is no operator of these
boxes. Maybe some times an operator of the machinary comes around - and
needs to rely on the LEDs. Not as critial as an direction indicator in
a car, but still important.
--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@metux.net -- +49-151-27565287
next prev parent reply other threads:[~2020-10-19 14:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 21:59 [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform driver Ed Wildgoose
2020-09-21 21:59 ` [PATCH 2/2] x86: Support APU5 in PCEngines " Ed Wildgoose
2020-09-21 22:17 ` [PATCH 1/2] x86: Remove led/gpio setup from pcengines " Ed W
2020-10-12 19:39 ` Enrico Weigelt, metux IT consult
2020-10-13 8:48 ` Hans de Goede
2020-10-13 21:46 ` Ed W
2020-10-19 14:28 ` Enrico Weigelt, metux IT consult [this message]
2020-10-13 21:40 ` Ed W
2020-10-14 8:41 ` Hans de Goede
2020-10-14 11:21 ` Ed W
2020-10-14 11:29 ` Hans de Goede
2020-10-21 21:54 ` Ed W
2020-10-22 11:48 ` Enrico Weigelt, metux IT consult
2020-10-22 15:10 ` Ed W
2020-10-22 19:30 ` Enrico Weigelt, metux IT consult
2020-10-19 15:44 ` Enrico Weigelt, metux IT consult
2020-10-19 18:37 ` Hans de Goede
2020-10-21 12:18 ` Enrico Weigelt, metux IT consult
2020-10-21 21:41 ` [PATCH 1/2] x86: Conditional init of pcengines leds/keys gpios Ed Wildgoose
2020-10-21 21:41 ` [PATCH 2/2] x86: Support APU5 & APU6 in PCEngines platform driver Ed Wildgoose
2020-10-22 0:53 ` [PATCH 1/2] x86: Conditional init of pcengines leds/keys gpios kernel test robot
2020-10-22 9:22 ` Enrico Weigelt, metux IT consult
2020-10-22 9:38 ` Ed W
2020-10-22 13:20 ` Enrico Weigelt, metux IT consult
2020-10-22 12:23 ` kernel test robot
2020-10-22 12:23 ` [RFC PATCH] x86: cmp_version() can be static kernel test robot
2020-10-19 16:33 ` [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform driver Enrico Weigelt, metux IT consult
2020-10-12 19:31 ` Enrico Weigelt, metux IT consult
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a6fe2bc-a4a5-c214-e7fd-2a429dc960e1@metux.net \
--to=lkml@metux.net \
--cc=andy@infradead.org \
--cc=dvhart@infradead.org \
--cc=fe@dev.tdt.de \
--cc=hdegoede@redhat.com \
--cc=info@metux.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@wildgooses.com \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox