Message-ID: <795ae78b-26cf-f58d-6981-f68d7599ccdf@wildgooses.com>
Date:   Wed, 21 Oct 2020 22:54:06 +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 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 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?
>
> I'm afraid I do not have any wisdom to share here. I would use the DMI bios-version
> or bios-date strings for the detection, but I guess that is obvious. 


Hi Hans & Enrico

OK, I've just sent a new patch which conditionally configures GPIOs for boards with older firmware's
(older than 4.10.0).

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 or wifi cards. This
creates the realisation that the reset and sim-swap lines are always wired to the LTE slots, not to
the mpcie slots (although often they overlap in functionality), so naming is corrected here. That
said, I don't think the reset lines function on most iterations of boards, so possibly supporting
those lines with GPIOs is redundant anyway...

APU6 is also a special order and is essentially the same as an APU4, so I have added detection for
this also.

I don't know if it's useful, but I uploaded a couple of scripts for beeping and flashing the leds.
Here I just used globs to handle the different naming on the different boards (since I need to
handle the older Alix boards as well). Enrico, is this useful to you?

    https://github.com/nippynetworks/gpio-utils


As an aside, these boards are super easy to flash as they support flashrom. So I'm personally giving
some thought to bundling an updater into our software build. The generic bios is quite slow to
startup and I would like to prepare a customised version with shorter timeouts. Happy to work with
you on something separately if this is interesting?

Hans, thanks if you can look this over.

Regards

Ed W

Powered by blists - more mailing lists