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
