<p><br>
On Sep 14, 2011 3:40 PM, "David Daney" <<a href="mailto:david.daney@cavium.com">david.daney@cavium.com</a>> wrote:<br>
><br>
> Well, I would really like to get an official maintainer's take on the name of the parent MDIO bus property. Prehaps Grant or Rob could opine on the matter.<br>
><br>
> Sooner would be better than later as I am about to start shipping boards with this burnt into the bootloader. If it needs changing, I could do it in the next couple of days, but after that it escapes into the wild.</p>
<p>Considering that the parent bus should be either implicit in the node topology, or if not then part of something like an i2c controlled bus multiplexer, I don't think this is even remotely a big deal. Each bus multiplexer will still likely have it's own binding, and therefore her to make its own decision.</p>
<p>That said, in the interest of commonality, I think mdio-parent-bus would be just fine. parent-bus is probably too generic.</p>
<p>g.</p>
<p>><br>
> Thanks in advance,<br>
> David Daney<br>
><br>
><br>
> On 09/14/2011 01:42 PM, Kumar Gala wrote:<br>
>><br>
>><br>
>> On Sep 13, 2011, at 6:23 PM, David Daney wrote:<br>
>><br>
>>> On 09/13/2011 04:07 PM, Kumar Gala wrote:<br>
>>>><br>
>>>><br>
>>>>> diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt<br>
>>>>> new file mode 100644<br>
>>>>> index 0000000..a908312<br>
>>>>> --- /dev/null<br>
>>>>> +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt<br>
>>>>> @@ -0,0 +1,132 @@<br>
>>>>> +Common MDIO bus multiplexer/switch properties.<br>
>>>>> +<br>
>>>>> +An MDIO bus multiplexer/switch will have several child busses that are<br>
>>>>> +numbered uniquely in a device dependent manner. The nodes for an MDIO<br>
>>>>> +bus multiplexer/switch will have one child node for each child bus.<br>
>>>>> +<br>
>>>>> +Required properties:<br>
>>>>> +- parent-bus : phandle to the parent MDIO bus.<br>
>>>><br>
>>>><br>
>>>> Should probably be mdio-parent-bus<br>
>>><br>
>>><br>
>>> Why? We know it is MDIO.<br>
>>><br>
>>> Serial bus multiplexing is not a concept limited to MDIO. We would want to use "parent-bus" for some I2C multiplexers as well.<br>
>><br>
>><br>
>>> From many years of dealing with device trees. We typically don't name things overlay generically unless they will be used over and over again as a common idiom (like reg, interrupt, etc.).<br>
>><br>
>><br>
>> We don't really use 'bus' generically today.<br>
>><br>
>>><br>
>>>><br>
>>>>> +<br>
>>>>> +Optional properties:<br>
>>>>> +- Other properties specific to the multiplexer/switch hardware.<br>
>>>>> +<br>
>>>>> +Required properties for child nodes:<br>
>>>>> +- #address-cells =<1>;<br>
>>>>> +- #size-cells =<0>;<br>
>>>>> +- cell-index : The sub-bus number.<br>
>>>><br>
>>>><br>
>>>> What does sub-bus number mean?<br>
>>><br>
>>><br>
>>> There are N child buses (or sub-buses) coming out of the multiplexer. The cell-index is used as a handle or identifier for each of these.<br>
>>><br>
>>> The concrete example in Patch 3/3 is a multiplexer with four child buses. The happen to have cell-indexes of 0, 1, 2 and 3.<br>
>>><br>
>>> In the GPIO case of patch 3/3, these directly correspond the the state of the two GPIO pins controlling the multiplexer. The driver then uses the cell-index property to determine the state of the GPIO to connect any given child.<br>
>>><br>
>>> It is possible that the documentation part of the patch could be made more clear about this.<br>
>>><br>
>>>><br>
>>>>> +<br>
>>>>> +<br>
>>>>> +Example :<br>
>>>><br>
>>>><br>
>>> [...]<br>
>>>>><br>
>>>>> +<br>
>>>>> +int mdio_mux_probe(struct platform_device *pdev,<br>
>>>>> + int (*switch_fn)(int cur, int desired, void *data),<br>
>>>>> + void *data)<br>
>>>>> +{<br>
>>>>> + struct device_node *parent_bus_node;<br>
>>>>> + struct device_node *child_bus_node;<br>
>>>>> + int r, n, ret_val;<br>
>>>>> + struct mii_bus *parent_bus;<br>
>>>>> + struct mdio_mux_parent_bus *pb;<br>
>>>>> + struct mdio_mux_child_bus *cb;<br>
>>>>> +<br>
>>>>> + if (!pdev->dev.of_node)<br>
>>>>> + return -ENODEV;<br>
>>>>> +<br>
>>>>> + parent_bus_node = of_parse_phandle(pdev->dev.of_node, "parent-bus", 0);<br>
>>>>> +<br>
>>>>> + if (!parent_bus_node)<br>
>>>>> + return -ENODEV;<br>
>>>>> +<br>
>>>>> + parent_bus = of_mdio_find_bus(parent_bus_node);<br>
>>>><br>
>>>><br>
>>>><br>
>>>> So what happens if the parent bus probe happens after the mux probe?<br>
>>>><br>
>>><br>
>>> The whole house of cards collapses.<br>
>>><br>
>>> Grant Likely has a patch to deal with this by retrying the probing, but as far as I know, it has not been merged yet.<br>
>><br>
>><br>
>> - k--<br>
>> To unsubscribe from this list: send the line "unsubscribe netdev" in<br>
>> the body of a message to <a href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</a><br>
>> More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a><br>
>><br>
><br>
</p>