On 22.10.20 17:10, Ed W wrote:
Hi,
> You are reaching the wrong conclusion I feel?
>
> a) your proposal doesn't address that ACPI and the upstream board configure
> all this stuff already.
Only for those with recent enough firmware. As already mentioned, we
can't expect users to do BIOS
Hi
>> This is followed up by the patch I really want to try and get in, which is
>> to add support for APU5
>> and APU6. Particularly APU5 is quite interesting to me and significantly
>> different to previous
>> boards in that it has a lot more mpcie slots that can be used for LTE
>> modules
On 21.10.20 23:54, Ed W wrote:
Hi,
> OK, I've just sent a new patch which conditionally configures GPIOs for
> boards with older firmware's
> (older than 4.10.0).
as mentioned in my reply to it: still breaks existing userlands as
device names and keycodes change. userland would need to become
On 14/10/2020 12:29, Hans de Goede wrote:
> Hi,
>
> On 10/14/20 1:21 PM, Ed W wrote:
>> 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
On 19.10.20 20:37, Hans de Goede wrote:
Hi folks,
> 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.
You're right. IMHO we should first get a clear
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
On 13.10.20 23:40, Ed W wrote:
> But why are users "in the field"
"field" here means litterlly field. Far away from any human being.
> updating a kernel willy nilly without also updating the userland
> software that talks to it?
Of course, we're always testing. Obviously, in the lab, not in
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
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
Hi,
On 10/14/20 1:21 PM, Ed W wrote:
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
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.
>
>
Hi,
On 10/13/20 11:40 PM, Ed W wrote:
Hans, can I ask you to look again at the history of this please. Bearing in
mind the speed kernel
stuff takes to get to end users, we are talking about a very small window of
userland changes here.
I would vote for simplifying this module and trying to
On 13/10/2020 09:48, Hans de Goede wrote:
> On 10/12/20 9:39 PM, Enrico Weigelt, metux IT consult wrote:
>> On 22.09.20 00:17, Ed W wrote:
>>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>>> variant of the APU 2-4
>>> boards
>>> with some nice features. The current
On 12/10/2020 20:39, Enrico Weigelt, metux IT consult wrote:
> On 22.09.20 00:17, Ed W wrote:
>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>> variant of the APU 2-4 boards
>> with some nice features. The current platform driver for pcengines boards
>> has some
Hi Enrico and Ed W,
Quick self intro: I have take over drivers/platform/x86
maintainership from Andy; and I'm working my way through
the backlog of old patches in patchwork:
https://patchwork.kernel.org/project/platform-driver-x86/list/
On 10/12/20 9:39 PM, Enrico Weigelt, metux IT consult
On 22.09.20 00:17, Ed W wrote:
> Hi, I've been adding support for the PC Engines APU5 board, which is a
> variant of the APU 2-4 boards
> with some nice features. The current platform driver for pcengines boards has
> some redundant
> features with regards to recent bios/firmware packages for
On 21.09.20 23:59, Ed Wildgoose wrote:
> The pcengines bios/firmware includes ACPI tables (since 4.10.0.1) which
> will cause the kernel to automatically create led + gpio_key devices for
> the platform. This means that the platform setup now creates duplicates
> of all these led/key devices.
Hi, I've been adding support for the PC Engines APU5 board, which is a variant
of the APU 2-4 boards
with some nice features. The current platform driver for pcengines boards has
some redundant
features with regards to recent bios/firmware packages for the board as they
now set the ACPI tables
The pcengines bios/firmware includes ACPI tables (since 4.10.0.1) which
will cause the kernel to automatically create led + gpio_key devices for
the platform. This means that the platform setup now creates duplicates
of all these led/key devices.
Anyone with a much older bios can use the
19 matches
Mail list logo
