On Thu, Aug 12, 2021 at 03:54:26PM +0000, Asmaa Mnebhi wrote:
> Hi Andy,
Thanks for prompt response!
My first question, is it already firmware in the wild that does this?
I.o.w. is there any time to amend it if needed?
> We have 1 image common to all our board types. The ACPI tables are selected
> based on the board id. Some board types have PHY_INT pin connected to GPIO
> pin 9 and other boards have it connected to GPIO pin 12. So we have 2
> ssdt.asl files:
Okay (You may have one and actually choose it based on some [NVS] variable)
> // first file: PHY_INT -> GPIO pin 12
> Device(OOB) {
> Name(_HID, "MLNXBF17")
> Name(_UID, 0)
> Name(_CCA, 1)
> Name (_CRS, ResourceTemplate () {
> // OOB Ethernet
> Memory32Fixed (ReadWrite, 0x03000000, 0x00000600)
> // mdio[9]
> Memory32Fixed (ReadWrite, 0x028004C8, 0x00000008)
> // gpio[0]
> Memory32Fixed (ReadWrite, 0x0280c000, 0x00000100)
> // OOB LLU
> Memory32Fixed (ReadWrite, 0x039C0000, 0x0000A100)
> // OOB PLU
> Memory32Fixed (ReadWrite, 0x04000000, 0x00001100)
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { BF_RSH0_DEVICE_OOB_INT }
> Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive) { BF_RSH0_DEVICE_OOB_LLU_INT }
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { BF_RSH0_DEVICE_OOB_PLU_INT }
> Interrupt (ResourceConsumer, Edge, ActiveHigh, Shared) { BF_RSH0_DEVICE_YU_INT }
>
> // GPIO PHY interrupt
> GpioInt (Edge, ActiveHigh, Exclusive, PullUp, , " \\_SB.GPI0") {12}
PullUp with Edge/Rise seems a bit awkward. Recently I have added a
corresponding paragraph to the
https://www.kernel.org/doc/html/latest/firmware-guide/acpi/gpio-properties.html.
But it's just to double check that you got the idea how your hardware works
(maybe it uses open-drain or so and it's indeed the correct setting).
What I have seen here is a regular GpioInt() resource with a single pin.
As far as I can see in the code it has the flaw that it actually will use the
last GpioInt() resource available in _CRS.
Besides that, why do you need to know the pin name and can't simply request an
IRQ as every other driver does (the exception is only yours in the entire
kernel)? The acpi_dev_gpio_irq_get() call can get Linux vIRQ for you same way
you have got it for Interrupt() resources via platform_get_irq().
To understand better this piece, can you point out to the GPIO driver code,
which implements the driver for _SB.GPI0 in the kernel?
> }) // Name(_CRS)
>
> // Second file: PHY_INT -> GPIO pin 9
> Device(OOB) {
> Name(_HID, "MLNXBF17")
> Name(_UID, 0)
> Name(_CCA, 1)
> Name (_CRS, ResourceTemplate () {
> // OOB Ethernet
> Memory32Fixed (ReadWrite, 0x03000000, 0x00000600)
> // mdio[9]
> Memory32Fixed (ReadWrite, 0x028004C8, 0x00000008)
> // gpio[0]
> Memory32Fixed (ReadWrite, 0x0280c000, 0x00000100)
> // OOB LLU
> Memory32Fixed (ReadWrite, 0x039C0000, 0x0000A100)
> // OOB PLU
> Memory32Fixed (ReadWrite, 0x04000000, 0x00001100)
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { BF_RSH0_DEVICE_OOB_INT }
> Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive) { BF_RSH0_DEVICE_OOB_LLU_INT }
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { BF_RSH0_DEVICE_OOB_PLU_INT }
> Interrupt (ResourceConsumer, Edge, ActiveHigh, Shared) { BF_RSH0_DEVICE_YU_INT }
>
> // GPIO PHY interrupt
> GpioInt (Edge, ActiveHigh, Exclusive, PullUp, , " \\_SB.GPI0") {9}
> }) // Name(_CRS)
>
> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> Sent: Thursday, August 12, 2021 10:14 AM
> To: Linux GPIO <linux-gpio@xxxxxxxxxxxxxxx>; linux-acpi@xxxxxxxxxxxxxxx; Rafael J. Wysocki <rjw@xxxxxxxxxxxxx>; Linus Walleij <linus.walleij@xxxxxxxxxx>; Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
> Cc: David Thompson <davthompson@xxxxxxxxxx>; Asmaa Mnebhi <asmaa@xxxxxxxxxx>; Liming Sun <limings@xxxxxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>
> Subject: Possible ACPI abuse in Mellanox BlueField Gigabit Ethernet driver
>
> Hi!
>
> From time to time I do grep kernel for ACPI_RESOURCE_TYPE_GPIO usage.
> Recently the drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_gpio.c
> caught my eye.
>
> Looking into the code I see that it looks like misunderstanding of how ACPI works with GPIOs. First of all, I would like to inform that this code has been properly reviewed neither by GPIO nor by ACPI maintainers. Second, before going it to the real conclusions (and potential revert of this), I would like to see the real ACPI tables for this and some explanations from the authors of the driver about GPIO usage here (from hw and sw perspectives).
>
> It makes sense to discuss ASAP, otherwise I would really want to revert it.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
With Best Regards,
Andy Shevchenko
