Hi Thomas,
2014-05-15 6:39 GMT-07:00 Thomas Petazzoni
<thomas.petazzoni@xxxxxxxxxxxxxxxxxx>:
> Dear Grant Likely,
>
> Sorry for bringing back this old topic, but I'm working on this again,
> hopefully reaching an acceptable solution this time. One question for
> you below.
>
> On Sat, 08 Mar 2014 05:50:33 +0000, Grant Likely wrote:
>
>> > +Example:
>> > +
>> > +ethernet@0 {
>> > + ...
>> > + phy = <&phy0>;
>> > + phy0: phy@0 {
>> > + fixed-link;
>> > + speed = <1000>;
>> > + full-duplex;
>> > + };
>>
>> The phy phandle to a child node is superfluous. A phandle to a fixed
>> child node doesn't make a whole lot of sense.
>
> [...]
>
>> There should be no address portion in the node name. It isn't a child
>> device, the node is merely more configuration data for the parent.
>>
>> Example:
>>
>> ethernet@0 {
>> ...
>> fixed-link {
>> speed = <1000>;
>> full-duplex;
>> };
>
> For my current use case, I'm personally fine with that. But that
> doesn't work well with Florian Fainelli's which to potentially have the
> "fixed-link" node as part of another node in the DT, in the case the
> PHY is configurable through some separate SPI/I2C bus. See his comment
> in http://article.gmane.org/gmane.linux.network/306789:
I just re-read Grant's comments, and I don't think we contradict with
each other here. Since the data-path is symetrical by nature, whether
you place the 'fixed-link' property on one end (Ethernet MAC) or the
other (SPI/I2C/GPIO node) does make a huge difference, except you want
it to be placed where it makes the most sense: in the Ethernet MAC
node. Properties like the speed, duplex, pause are definitively
Ethernet MAC only properties.
In case we need to specifically associate these two nodes with each
other, a phandle property to the Ethernet MAC node, or e.g: the SPI
node can be used.
That said, I think we should go with Grant's proposal of having the
following representation:
ethernet@0 {
...
fixed-link {
speed = <1000>;
full-duplex;
};
we might want to use 'max-speed' instead of speed, but that's debatable.
>
> """
> Another problem with that "old" 'fixed-link' property is that we are
> not properly capturing and representing Ethernet switches/PHYs whose
> data-path are isolated from the control path. For instance such
> devices will traditionally expose their control path as a
> MMIO/GPIO/I2C/SPI interface. Using the 5-digit 'fixed-link' property
> we are not representing this, on one side the Ethernet MAC is just
> told to hardcode the link parameters with some parameters, and on
> other side, any MMIO/GPIO/I2C/SPI device is not equipped with the
> correct properties to express the fact that is also has a data-path
> connected to an Ethernet MAC.
>
> What I like about this new binding is that we could place the
> 'fixed-link' related properties in e.g: a SPI slave node, and have the
> Ethernet MAC be pointed at it by a phandle to tell it: look this is
> your PHY, it might not be one you could address on a MDIO bus, so I
> have been providing additional properties to help you with the link
> configuration.
> """
>
> What is your opinion about this?
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
