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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ