The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

  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