netdev - RE: [PATCH v1 5/6] TODO: gpio: mlxbf2: Introduce IRQ support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CH2PR12MB38954F84310BE1D749CBECAAD7C09@CH2PR12MB3895.namprd12.prod.outlook.com>
Date:   Thu, 19 Aug 2021 12:28:34 +0000
From:   Asmaa Mnebhi <asmaa@...dia.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC:     David Thompson <davthompson@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Liming Sun <limings@...dia.com>
Subject: RE: [PATCH v1 5/6] TODO: gpio: mlxbf2: Introduce IRQ support

Thank you Andrew and Andy! I will prepare 2 patches (one for gpio-mlxbf2.c and one for mlxbf-gige) and send it your way.

-----Original Message-----
From: Andrew Lunn <andrew@...n.ch> 
Sent: Wednesday, August 18, 2021 6:40 PM
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Asmaa Mnebhi <asmaa@...dia.com>; David Thompson <davthompson@...dia.com>; linux-kernel@...r.kernel.org; linux-gpio@...r.kernel.org; netdev@...r.kernel.org; linux-acpi@...r.kernel.org; Linus Walleij <linus.walleij@...aro.org>; Bartosz Golaszewski <bgolaszewski@...libre.com>; David S. Miller <davem@...emloft.net>; Jakub Kicinski <kuba@...nel.org>; Rafael J. Wysocki <rjw@...ysocki.net>; Liming Sun <limings@...dia.com>
Subject: Re: [PATCH v1 5/6] TODO: gpio: mlxbf2: Introduce IRQ support
Importance: High

Hi Asmaa

> > And I will need to add GpioInt to the GPI0 ACPI table as follows:
> 
> But you told me that it's already on the market, how are you suppose 
> to change existing tables?

BIOSes have as many bugs a the kernel. So your product should be designed so you can upgrade the kernel and upgrade the BIOS.

phylib itself does not care if there is an interrupt or not. It will fall back to polling. So if your driver finds itself running with old tables, it does not matter. Just print a warning to the kernel logs suggesting the user upgrades their BIOS firmware.

> > // GPIO Controller
> >       Device(GPI0) {
> >        Name(_HID, "MLNXBF22")
> >         Name(_UID, Zero)
> >         Name(_CCA, 1)
> >         Name(_CRS, ResourceTemplate() {
> >           // for gpio[0] yu block
> >          Memory32Fixed(ReadWrite, 0x0280c000, 0x00000100)
> >          GpioInt (Level, ActiveLow, Exclusive, PullDefault, , " \\_SB.GPI0") {9}
> >         })
> >         Name(_DSD, Package() {
> >           ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >           Package() {
> >             Package () { "phy-gpios", Package() {^GPI0, 0, 0, 0 }},
> >             Package () { "rst-pin", 32 }, // GPIO pin triggering soft reset on BlueSphere and PRIS
> >           }
> >         })
> >       }
> 
> No, it's completely wrong. The resources are provided by GPIO 
> controller and consumed by devices.

In the device tree world, you list the interrupt in the PHY node.
Documentation/devicetree/bindings/net/ethernet-phy.yaml gives an
example:

    ethernet {
        #address-cells = <1>;
        #size-cells = <0>;

        ethernet-phy@0 {
            compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c45";
            interrupt-parent = <&PIC>;
            interrupts = <35 1>;
            reg = <0>;

            resets = <&rst 8>;
            reset-names = "phy";
            reset-gpios = <&gpio1 4 1>;
            reset-assert-us = <1000>;
            reset-deassert-us = <2000>;
        };
    };

You need to do something similar in the ACPI world. There was a very long discussion in this area recently, and some patches merged. You probably need to build on that. See:

firmware-guide/acpi/dsd/phy.rst

	Andrew