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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Oct 2018 02:39:36 +0000
From:   "Wang, Dongsheng" <dongsheng.wang@...-semitech.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Timur Tabi <timur@...nel.org>,
        "Zheng, Joey" <yu.zheng@...-semitech.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "robert.moore@...el.com" <robert.moore@...el.com>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] net: qcom/emac: add phy-handle support for ACPI

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.

Cheers,
Dongsheng