netdev - Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code

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:   Thu, 8 Nov 2018 07:55:47 +0000
From:   "Wang, Dongsheng" <dongsheng.wang@...-semitech.com>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
CC:     "andrew@...n.ch" <andrew@...n.ch>,
        "timur@...nel.org" <timur@...nel.org>,
        "Zheng, Joey" <yu.zheng@...-semitech.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code

On 2018/11/8 15:44, Rafael J. Wysocki wrote:
> On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
>> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
>> The current implementation depend on mdio bus scan.
>> With _DSD device properties we can finally do this:
>>
>>     Device (MDIO) {
>>         Name (_DSD, Package () {
>>             ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>>             Package () { Package () { "ethernet-phy@0", PHY0 }, }
>>         })
>>         Name (PHY0, Package() {
>>             ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>             Package () { Package () { "reg", 0x0 }, }
>>         })
>>     }
>>
>>     Device (MACO) {
>>         Name (_DSD, Package () {
>>             ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>             Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
>>         })
>>     }
>>
>> Documentations:
>>     The DT "phy-handle" binding that we reuse for ACPI is documented in
>>     Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>>     Documentation/acpi/dsd/data-node-references.txt
>>     Documentation/acpi/dsd/graph.txt
>>
>> Signed-off-by: Wang Dongsheng <dongsheng.wang@...-semitech.com>
>> ---
>>  drivers/acpi/Kconfig       |   6 ++
>>  drivers/acpi/Makefile      |   1 +
>>  drivers/acpi/acpi_mdio.c   | 167 +++++++++++++++++++++++++++++++++++++
>>  drivers/net/phy/mdio_bus.c |   3 +
>>  include/linux/acpi_mdio.h  |  82 ++++++++++++++++++
>>  5 files changed, 259 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 9705fc986da9..0fefa3410ce9 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
>>  config ACPI_MCFG
>>  	bool
>>  
>> +config ACPI_MDIO
>> +	def_tristate PHYLIB
>> +	depends on PHYLIB
>> +	help
>> +	  ACPI MDIO bus (Ethernet PHY) accessors
>> +
>>  config ACPI_CPPC_LIB
>>  	bool
>>  	depends on ACPI_PROCESSOR
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 6d59aa109a91..ec7461a064fc 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -41,6 +41,7 @@ acpi-y				+= ec.o
>>  acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
>>  acpi-y				+= pci_root.o pci_link.o pci_irq.o
>>  obj-$(CONFIG_ACPI_MCFG)		+= pci_mcfg.o
>> +acpi-$(CONFIG_ACPI_MDIO)	+= acpi_mdio.o
>>  acpi-y				+= acpi_lpss.o acpi_apd.o
>>  acpi-y				+= acpi_platform.o
>>  acpi-y				+= acpi_pnp.o
>> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
>> new file mode 100644
>> index 000000000000..293bf9a63197
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_mdio.c
>> @@ -0,0 +1,167 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +// Lots of code in this file is copy from drivers/of/of_mdio.c
> Would it be possible to re-factor that code and share it instead?

I thought about it, we can actually do it with fwnode.

But I don't have a lot of concentrate to do this. I'm going to focus on
a few other things...:(

Maybe in the second half of 2019 I can re-factor them if there is no one
re-factor them.


Cheers,

Dongsheng


> Thanks,
> Rafael
>
>