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, 08 Nov 2018 09:01:24 +0100
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     "Wang, Dongsheng" <dongsheng.wang@...-semitech.com>
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 Thursday, November 8, 2018 8:55:47 AM CET Wang, Dongsheng wrote:
> 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.

Well, I'd rather avoid code duplication upfront if possible.

Thanks,
Rafael