On 2018/10/29 20:40, Andrew Lunn wrote: > 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. Yes, I also would like the second one. I will reply in a few days. Cheers, Dongsheng > Andrew >
