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

On August 17, 2016 8:27:19 PM PDT, Timur Tabi [off-list ref] wrote:

Florian Fainelli wrote:

quoted

quoted

     emac_sgmii: ethernet-phy@410400 {
         compatible = "qcom,qdf2432-emac-phy";
         reg = <0x0 0x00410400 0x0 0x100>;
         interrupts = <0 0x104 0>;
     };

Is this register range relative to the emac0 node here, or is this
really a separate node, within the same adress space as your emac0

node?

It's a separate node within the same address space.  We can't guarantee

that it's adjacent to any other EMAC register -- it could be anywhere
in 
memory. 0x00410400 is the real physical address of those registers.

Ok

quoted

Answer largely depends on whether your device is really located

outside

quoted

of the emac, if it located outside, then a platform device matching

the

quoted

compatible string would get you what you want. If the emac_sgmii

block

quoted

is a sub-block within the EMAC, then a few things need fixing:

- your emac_sgmii node should be a sub-node of the emac node, not a

sibling

quoted

- the emac0 node should have a "ranges" property that indicates how

to

quoted

translate the sub-nodes' "reg" property based on the base register
address of the emac0 block
- you would have to call of_platform_populate from the EMAC driver to
ensure that the emac_sgmii child node and therefore platform device

gets

quoted

created

Even if the emac_sgmii block were a sub-block, wouldn't it conflict
with 
the ethernet-phy@4 node?  The #address-cells and #size-cells properties

cannot be valid for both the emac_sgmii and ethernet-phy@4 nodes.

These two properties apply to subnodes within the emac0 and emac_sgmii nodes, this is standard DT stuff here.

The larger issue is that the emac_sgmii node in the form you posted is going to be backed by a platform device in Linux while you want a PHY device with a reg property that describes a MDIO address (#address-cells = 1, #size-cells = 0). 

IIRC the amd xgbe driver mainline had a similar design but still implemented a PHY device anyway although it may not have been using Device Tree. It should still be possible to implement a PHY driver that you manually register and bind to its device_node pointer such that of_phy_find_device and friends still work. You would do this from the emac_sgmii platform device driver and parent devices in a way that satisfy the PHY device driver lifecycle as well.

Hope this helps.

NB: another way to do this is to give the SGMII PHY device a MDIO address, provided that it has one, and you pass the memory mapped register range as a syscon property pointing to the emac_sgmii register range. This is not really clean through.


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html