On Fri, Jul 24, 2020 at 09:14:36PM +0200, Andrew Lunn wrote:

quoted

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?

I understand your concerns here. But as I mentioned in other email in
the same thread, it is very tricky problem to solve as no one is ready
to take up and maintain these.

For an example, see

https://patchwork.ozlabs.org/project/netdev/patch/1595417547-18957-3-git-send-email-vikas.singh@puresoftware.com/

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?

My guess is that similar products running on other architectures(namely
x86) might be running ACPI and hence the push to have ACPI on such ARM
systems. It may weak argument for that and I agree with it. I want to
think it as legitimate use here but I am well aware and afraid that this
may become front door instead of escape hatch.

Sorry, I am not helpful at all, but I am just sharing my personal opinion
on this matter.

--
Regards,
Sudeep