Re: [PATCH v3 2/2] net: qcom/emac: add phy-handle support for ACPI

[Andrew Lunn <andrew@lunn.ch>]

On Mon, Oct 29, 2018 at 02:39:36AM +0000, Wang, Dongsheng wrote:
> On 2018/10/26 21:12, Andrew Lunn wrote:
> > On Fri, Oct 26, 2018 at 03:04:25AM +0000, Wang, Dongsheng wrote:
> >> On 2018/10/26 10:37, Timur Tabi wrote:
> >>> On 10/25/18 9:18 PM, Wang, Dongsheng wrote:
> >>>> But when I was reading Documentation/acpi/DSD-properties-rules.txt, my
> >>>> understanding is we should try to conform to DT bindings. So maybe ACPI
> >>>> doesn't have such a document, just DT bindings.
> >>> There was an attempt to document DSDs, but it was abandoned after a while.
> >>>
> >>> https://github.com/ahs3/dsd
> >>>
> >> Yes, here's a database concept, and I asked some Intel guys, the answer
> >> I got was there is no such database or document. :(
> > Hi Dongsheng
> >
> > If there is no clear documentation for ACPI, it becomes even more
> > important that the xgene code is refactored into a central location,
> > and you make use of it. We really need to avoid every ACPI ethernet
> > driver doing its own thing.
> 
> However, without a document specifying MDIO and phy-handle, it is almost
> difficult for us to do this. Because maybe the ACPI device or property
> corresponding to each platform is different.
> Just like APM looks different to us. APM's MDIO adev doesn't describe
> the concept of port, and our platform does. Besides, I cannot get the
> ACPI table of APM or other manufacturers.
> The table of ACPI cannot be obtained from kernel source as easily as DT.
> We can't know without a platform to do ACPI dump. Unless some of the
> manufacturers have pushed the table to upstream.
> So I think we might have a hard time doing this without a document. And
> it's likely that this work involves code modifications by BIOS vendors.

Hi Dongsheng

There are two different options here.

1) Everybody does their own thing, ignoring what everybody else has
done, and invents their own wheel. There is no shared code, no shared
description, everybody has their own bugs, etc. ACPI as a standard is
pointless for Ethernet MDIOs and PHYs because it is not a standard,
everybody does something different.

2) Somebody takes the time to design a concept for Ethernet PHYs and
MDIO busses using ACPI. They implement the common code, try to modify
any existing users if possible, and submit the whole thing to become
part of ACPI 6.3.

I would really prefer we go the second route here. It is more initial
effort, but in the long run, everybody benefits.

	Andrew