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: 31+ 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 0:53 ` 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 ` kernel test robot
2020-10-22 12:23 ` [RFC PATCH] x86: cmp_version() can be static kernel test robot
2020-10-22 12:23 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.