On Fri, Jan 26, 2018 at 07:20:42AM +, 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
> imple
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 prope
On 01/25/2018 09:59 AM, Andrew Lunn wrote:
I expect we will implement something like acpi_mdiobus_register(), and
it will take a pointer to an ACPI node. And maybe on top of
of_mdiobus_register() and of_mdiobus_register() we will add a
device_mdiobus_register().
Makes sense. If you remember, p
On Thu, Jan 25, 2018 at 09:40:45AM -0600, Timur Tabi wrote:
> On 01/25/2018 08:15 AM, Andrew Lunn wrote:
> >If i'm reading your patch correctly, you are looking for the MDIO
> >reset in the MAC node. This is wrong. It is an MDIO property, so
> >should be in the MDIO device. Once we have figured out
On 01/25/2018 08:15 AM, Andrew Lunn wrote:
If i'm reading your patch correctly, you are looking for the MDIO
reset in the MAC node. This is wrong. It is an MDIO property, so
should be in the MDIO device. Once we have figured out how to
represent MDIO busses in ACPI, the reset will be in the MDIO
On 01/25/2018 12:14 AM, Wang Dongsheng wrote:
mdiobus always try to get a GPIO "reset" consumer, based on ACPI
the GPIO should be described in emac-adev _DSD or _CRS.
Are you talking about this:
/* de-assert bus level PHY GPIO reset */
gpiod = devm_gpiod_get_optional(&bus->dev,
On Wed, Jan 24, 2018 at 10:14:39PM -0800, Wang Dongsheng wrote:
> mdiobus always try to get a GPIO "reset" consumer, based on ACPI
> the GPIO should be described in emac-adev _DSD or _CRS.
>
> ACPI uses mido common API to register, however mdio->dev->fwnode is not
> pointing to any adev. So the "r
mdiobus always try to get a GPIO "reset" consumer, based on ACPI
the GPIO should be described in emac-adev _DSD or _CRS.
ACPI uses mido common API to register, however mdio->dev->fwnode is not
pointing to any adev. So the "reset" consumer can never be found.
OF has done this by using an of_mdiobu