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:     "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
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>
 <e727d039-8dea-1a40-48b9-792b6053807c@metux.net>
From:   Hans de Goede <hdegoede@redhat.com>
Message-ID: <2ba7fc12-a3a7-2783-54e6-27e9eb60ec9c@redhat.com>
Date:   Mon, 19 Oct 2020 20:37:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <e727d039-8dea-1a40-48b9-792b6053807c@metux.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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