[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e953f3ee-2db1-1523-cd84-6acb26751a15@wildgooses.com>
Date: Wed, 14 Oct 2020 12:21:07 +0100
From: Ed W <lists@...dgooses.com>
To: Hans de Goede <hdegoede@...hat.com>,
"Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
linux-kernel@...r.kernel.org
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: Remove led/gpio setup from pcengines platform
driver
On 14/10/2020 09:41, Hans de Goede wrote:
>
> So I have a suggested compromise:
>
> 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.
>
> Enrico, would that work for you ?
I'm cool with this. Enrico?
I may have some time imminently to have a stab at a new patch. Obviously any help structuring this
would be appreciated - it feels clumsy using the existing detection mechanism, I think whatever I
come up with you should kick back and recommend a new board detection structure, but perhaps we can
shortcut that step with a few comments up front?
Cheers
Ed W
Powered by blists - more mailing lists