[PATCH 1/4 v2] powerpc: document max-speed and interface-type properties

[Segher Boessenkool]

>>> ..but I'm not interested in specifying what interfaces the PHY
>>> supports.
>>
>> But you *have* to.  The device tree describes the hardware,
>> it is not a configuration file for Linux to use as it sees fit.
>
> not for the purposes of this patch; ucc_geth passes interface_type,

It doesn't matter what the Linux code does.  The device tree
describes the hardware, it is not a configuration file for
Linux to use as it sees fit.

> a
> property of the board describing the connection between the MAC and PHY
> (not a list of what connection types the PHY is capable of) to the
> phylib, and the phylib is left to probe, identify, and configure the 
> PHY
> appropriately.

Sure there's an argument for describing what type of
interface the PHY is connected on, if it supports more
than one -- but that should be a property in the PHY
node, not the controller node, since you can have multiple
PHYs connected to the same controller, possibly on
different interfaces each.

The m88e11x1 phylib code seems to ignore the "interface"
parameter completely btw.

>>>>> Again, max-speed is exclusively for configuring the UCC itself,
>>>>> regardless of the connection speed.
>>>>
>>>> If that is really true, and the value of that property
>>>> has nothing to do with the MAC<->PHY data channel, it should
>>>> have a different (not that generic) name.
>>>
>>> can you elaborate on why, including an example of what you'd think
>>> would
>>> be a better one?
>>
>> Very generic names should only be used by very generic bindings.
>
> it's intentionally generic; UCCs are Universal Communications
> Controllers and implement many communications protocols.

So?  That doesn't put the UCC device binding on the same
level as, say, PCI or the base OF definition.

>> If a very specific device binding (like yours) uses a property
>> name like that, there is a high chance it will clash with a more
>> generic binding it uses (PCI, ethernet, network, ...) -- perhaps
>> with a *future* version of such a binding.
>>
> I'm sure future versions will be able to adjust accordingly :)

Do you really think that when future changes are made to
base OF, or the PCI binding, or similar, that people will
even stop to consider what you did in your (unofficial)
binding and try to stay compatible to it?  Can I have
some of those pills?

>> Also, it isn't a great name /an sich/: "max-speed" -- maximum
>> speed of what?
>
> ?  it's fine - it's in the context of a communications device.
> Can you come up with something better?

Sure.  "ucc,max-speed" solves one problem; "max-comm-speed"
solves another.  I'm sure there are better names possible,
so please find one.  Giving good names to things is hard,
so good luck.


Segher