Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rob Herring wrote:

>>>+- reg : Offset and length of the register regions for the device
>>>+- reg-names : Register region names referenced in 'reg' above.
>>>+       Required register resource entries are:
>>>+       "base"   : EMAC controller base register block.
>>>+       "csr"    : EMAC wrapper register block.
>>>+       Optional register resource entries are:
>>>+       "ptp"    : EMAC PTP (1588) register block.
>>>+                  Required if 'qcom,emac-tstamp-en' is present.
>>>+       "sgmii"  : EMAC SGMII PHY register block.
>>>+- interrupts : Interrupt numbers used by this controller
>>>+- interrupt-names : Interrupt resource names referenced in 'interrupts'
>>>above.
>>>+       Required interrupt resource entries are:
>>>+       "emac_core0"   : EMAC core0 interrupt.
>>>+       "sgmii_irq"   : EMAC SGMII interrupt.
>>>+- qcom,emac-gpio-mdc  : GPIO pin number of the MDC line of MDIO bus.
>>>+- qcom,emac-gpio-mdio : GPIO pin number of the MDIO line of MDIO bus.
>>
>>
>>Use the standard binding for GPIO controlled MDIO bus.
>
>
>I'm not familiar with that one.  Are you talking about
>bindings/net/mdio-gpio.txt?

Yes.


>>>+- phy-addr            : Specifies phy address on MDIO bus.
>>>+                       Required if the optional property
>>>"qcom,no-external-phy"
>>>+                       is not specified.
>>
>>
>>Don't you think you will need to know the specific phy device or other
>>properties of the phy?
>
>
>That, I can't answer.  Aren't all MDIO devices basically the same?  It's
>been a while since I've worked on them.

No. There was some discussion just this week about needing to require
phy devices to have compatible strings.

I'm back to working on this driver, and I need some more help with how to handle the phy. mdio-gpio.txt doesn't really tell me much. I'm actually working on an ACPI system and not DT. I don't want to strip out the DT code, but I can't really test it. I want to keep changes to Gilad's patch to a minimum.

Part of the problem with the Emac (and Gilad tried to explain this) is that it has an internal phy. Technically, you can connect this internal phy directly to another internal phy on another SOC, and use this as an SOC interconnect. However, I don't know of anyone actually doing that.

Instead, most systems have the internal phy connect to an external phy. This connection is how the Emac receives packets from the external phy.

So I don't understand how I'm supposed to use the binding in mdio-gpio.txt. For one thing, there is no such binding on ACPI systems. On my ACPI system, firmware has set up the GPIOs. The driver never actually makes any gpio_xxx calls. At this point, I'm tempted to just remove all the GPIO stuff from Gilad's patch, if I can't help enough help to figure out how to modify the driver the way you think I should.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation collaborative project.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux