From: Hans de Goede <hdegoede@redhat.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
Ed W <lists@wildgooses.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 20:37:16 +0200 [thread overview]
Message-ID: <2ba7fc12-a3a7-2783-54e6-27e9eb60ec9c@redhat.com> (raw)
In-Reply-To: <e727d039-8dea-1a40-48b9-792b6053807c@metux.net>
Hi,
On 10/19/20 5:44 PM, Enrico Weigelt, metux IT consult wrote:
> On 14.10.20 10:41, Hans de Goede wrote:
>
> Hi,
>
>> Keep the current LED/gpio setup code, but make executing it conditional
>> on the BIOS version and skip the LED/gpio setup when the new BIOS is
>> present to avoid having duplicate LED entries, etc. in that case.
>>
>> I guess this would still break userspace because if I understand things
>> correctly the new ACPI based setup uses different LED names ? That
>> seems unfortunate, but I guess that from the kernel pov we can just
>> blame the BIOS for this, and since we definitely do not want duplicate
>> LED entries for the same LED, this seems the least bad choice.
>
> Sorry, but not fine. When a newer box is taken from storage into
> production (eg. replacement or new installation), application breaks.
> LED isn't the only problem, also affects buttons.
>
> The whole reaons why I invested all the time for writing general
> purpose drivers (fch-gpio is separate from board driver) and bringing
> it to mainline was having clean and generic support for these boards,
> instead of having to carry around special patch queues forever and
> in near future just using stock distro kernel. I guess that's the
> main reason for very most mainlined drivers.
Ack and that is how things should be done.
> This will be defeated
> as soon as the whole thing becomes board/bios specific again.
I hear you, but if newer BIOS versions all of a sudden start
declaring their own stuff, then we need to come up with some
solution here...
Not sure what that solution should be though.
Regards,
Hans
next prev parent reply other threads:[~2020-10-19 18:37 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
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 [this message]
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=2ba7fc12-a3a7-2783-54e6-27e9eb60ec9c@redhat.com \
--to=hdegoede@redhat.com \
--cc=andy@infradead.org \
--cc=dvhart@infradead.org \
--cc=fe@dev.tdt.de \
--cc=info@metux.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@wildgooses.com \
--cc=lkml@metux.net \
--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