Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform
 driver
To:     Hans de Goede <hdegoede@redhat.com>,
        "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
        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
References: <20200921215919.3072-1-lists@wildgooses.com>
 <d4b2045c-769b-4998-64cc-682c01c105fb@wildgooses.com>
 <8058a804-a793-a5f8-d086-0bb0f600aef9@metux.net>
 <65efe44a-bbef-f982-462a-385fffe493a0@wildgooses.com>
 <0de126c4-f2aa-a817-0a38-32bf3ede84d1@redhat.com>
 <e953f3ee-2db1-1523-cd84-6acb26751a15@wildgooses.com>
 <d0d91191-cad2-94a1-6373-0f3ff4e38376@redhat.com>
From:   Ed W <lists@wildgooses.com>
Message-ID: <795ae78b-26cf-f58d-6981-f68d7599ccdf@wildgooses.com>
Date:   Wed, 21 Oct 2020 22:54:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.3.3
MIME-Version: 1.0
In-Reply-To: <d0d91191-cad2-94a1-6373-0f3ff4e38376@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-GB
Precedence: bulk

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 condition=
al
>>> 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 thin=
gs
>>> 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 duplicat=
e
>>> 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. Obvious=
ly any help structuring this
>> would be appreciated - it feels clumsy using the existing detection me=
chanism, 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.=20


Hi Hans & Enrico

OK, I've just sent a new patch which conditionally configures GPIOs for b=
oards 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 i=
s 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 mod=
ules or wifi cards. This
creates the realisation that the reset and sim-swap lines are always wire=
d 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 beepi=
ng and flashing the leds.
Here I just used globs to handle the different naming on the different bo=
ards (since I need to
handle the older Alix boards as well). Enrico, is this useful to you?

=C2=A0=C2=A0=C2=A0 https://github.com/nippynetworks/gpio-utils


As an aside, these boards are super easy to flash as they support flashro=
m. 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 tim=
eouts. Happy to work with
you on something separately if this is interesting?

Hans, thanks if you can look this over.

Regards

Ed W