Thread (39 messages) 39 messages, 5 authors, 2018-11-13

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

From: Andrew Lunn <andrew@lunn.ch>
Date: 2018-10-29 12:40:44
Also in: linux-acpi

On Mon, Oct 29, 2018 at 02:39:36AM +0000, Wang, Dongsheng wrote:
On 2018/10/26 21:12, Andrew Lunn wrote:
quoted
On Fri, Oct 26, 2018 at 03:04:25AM +0000, Wang, Dongsheng wrote:
quoted
On 2018/10/26 10:37, Timur Tabi wrote:
quoted
On 10/25/18 9:18 PM, Wang, Dongsheng wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help