On Wed, Mar 10, 2021 at 9:38 PM Asmaa Mnebhi <asmaa@xxxxxxxxxx> wrote: > > That's fine, the hardware description model (I guess in your case > > ACPI) should take care of that. > > > We cannot really pass it through the ACPI table because the ACPI > table is common to all BlueField-2 boards. And each board may have > a different GPIO pin associated with a particular function. This is > why we use ACPI properties instead of GpioInt(). So that the > bootloader can change the GPIO pin value based on the board > id detected at boot time. (...) > Yes. It would belong in the ACPI table if we had a different ACPI > table for each board. But unfortunately that is not the case. You have to agree with Andy about all ACPI details. Andy is the ACPI GPIO maintainer and we cannot merge a patch with any kind of ACPI support without his ACK, so hash it out as he wants it. The only people on the planet that can make me think otherwise is if Rafael Wysocki and Mika Westerberg say something else, which is *extremely* unlikely. If you need to do workarounds because of broken ACPI tables, you need to convince the ACPI maintainers that there is no way you can fix these tables so it needs to be fixed in the kernel. It is not something for the GPIO maintainers to decide. To continue that argument please mail these people in the MAINTAINERS file, Andy and Mika Westerberg and have a discussion with the kernel ACPI community: ACPI M: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> M: Len Brown <lenb@xxxxxxxxxx> L: linux-acpi@xxxxxxxxxxxxxxx Yours, Linus Walleij
