netdev - Re: Re: [RFC] net: qcom/emac: mdiobus-dev fwnode should point to emac-adev

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] [day] [month] [year] [list]

Message-ID: <20180130132141.GG16547@lunn.ch>
Date:   Tue, 30 Jan 2018 14:21:41 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     "Wang, Dongsheng" <dongsheng.wang@...-semitech.com>
Cc:     Timur Tabi <timur@...eaurora.org>,
        "hpuranik@...eaurora.org" <hpuranik@...eaurora.org>,
        "Zheng, Joey" <yu.zheng@...-semitech.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Marcin Wojtas <mw@...ihalf.com>
Subject: Re: Re: [RFC] net: qcom/emac: mdiobus-dev fwnode should point to
 emac-adev

On Fri, Jan 26, 2018 at 07:20:42AM +0000, Wang, Dongsheng wrote:
> Hi, Timur && Andrew,
> 
> Please correct me if there is any problem with my understanding.
> 
> GPIO is a general property of devices, the property point to
> an entity such as device tree or ACPI table, we also can directly
> implement it in device node.
> 
> For ACPI, there is _DSD that should include GPIO property if we need it.
> No matter which devices implement it, MAC or MDIO also can implement a 
> _DSD.
> We can explicitly define a GPIO property in MDIO, but I think this
> may conflict with the existing definition of ACPI. ACPI guys may not
> agree to do this because there already has _DSD. We just need to use
> _DSD to notify GPIO layer there may have a Device Specific Data for
> this device.
> 
> So far MDIO owns external PHY "reset" as an optional feature and MDIO
> is integrated in MAC, so we need to point the MAC adev to 
> MDIO->dev.fwnode.
> And most importantly this feature does not depend on SoC, this feature
> depends on MotherBoard design.

Hi Wang

We have two different GPIO reset lines within the MDIO/PHY layer.  If
the GPIO is at the MDIO bus node of DT, the reset applies to all PHYs
connected to the bus. This is the code in__mdiobus_register().  If the
GPIO is in the PHY node, the reset applies to just that PHY. This is
the code in mdiobus_register_gpiod() & mdio_device_reset().

These resets are used at different times. The MDIO reset is used once,
before probing the MDIO bus. The PHY reset is used before probing the
individual PHY.

Does your GPIO reset one PHY, or all the PHYs? This determines where
in belongs. Is it the ACPI device which represents the MDIO bus, or
the ACPI device which represents the PHY?

You need to extend the functions i listed above to look in your ACPI
tables to find the _DSD properties which include the GPIO information.

Please work with Marcin Wojtas to achieve this. We will not accept
anything other than a generic solution which works for everybody.

	 Andrew