On Fri, Jul 24, 2020 at 9:14 PM Andrew Lunn <andrew@xxxxxxx> wrote: > > > Hence my previous comment that we should consider this an escape > > hatch rather than the last word in how to describe networking on > > ACPI/SBSA platforms. > > One problem i have is that this patch set suggests ACPI can be used to > describe complex network hardware. It is opening the door for others > to follow and add more ACPI support in networking. How long before it > is not considered an escape hatch, but the front door? > > For an example, see > > https://patchwork.ozlabs.org/project/netdev/patch/1595417547-18957-3-git-send-email-vikas.singh@xxxxxxxxxxxxxxxx/ > > It is hard to see what the big picture is here. The [0/2] patch is not > particularly good. But it makes it clear that people are wanting to > add fixed-link PHYs into ACPI. These are pseudo devices, used to make > the MAC think it is connected to a PHY when it is not. The MAC still > gets informed of link speed, etc via the standard PHYLIB API. They are > mostly used for when the Ethernet MAC is directly connected to an > Ethernet Switch, at a MAC to MAC level. > > Now i could be wrong, but are Ethernet switches something you expect > to see on ACPI/SBSA platforms? Or is this a legitimate use of the > escape hatch? I think with the rise in adoption of Smart-NICs in datacenters there will definitely be a lot more crossover between ACPI/SBSA and network appliance oriented hardware. -Jon
