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:   Tue, 30 Oct 2018 05:15:21 +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/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
>