[PATCH v2 13/14] ARM: STi: DT: STiH410: Add usb2 picophy dt nodes
peter.griffin at linaro.org
Fri Nov 14 05:34:25 PST 2014
Thanks for taking the time to explain this.
On Fri, 14 Nov 2014, Arnd Bergmann wrote:
> > address of the device's resources within the address space defined by its parent bus").
> You will also have to add an appropriate 'ranges' property then.
> > Or maybe you meant, if I want to keep the picophy node where it is (under soc), I need to stop using the reg
> > property?
> That would also be possible, just put the register numbers into your 'st,syscfg'
> property after the phandle, and leave the reg property empty then.
I think this is the best approach and whay I will do, as it would also extend well to devices with sysconfig
registers in different banks.
> > The other problem I was describing is a device with some memory mapped registers and some
> > sysconfig registers you can find examples already upstream in stih416.dtsi file with the
> > ethernet0 and miphy365x_phy nodes.
> > Here the first 1/2 reg properties are expressed as a 32 bit physical address and size (meets the spec definition),
> > and the last is expressed as a sysconfig offset and size (which AFAIK doesn't match the spec definition).
> > This change in address space is however documented in the bindings documentation.
> > How should devices which have multiple address spaces ideally be handled?
> There should at most be one 'reg' address space, so put it under the node whose
> bus these refer to. Put all offsets that are relative to a syscon link into
> the phandle that refers to the syscon device, or hardcode the offsets in the
Ok makes sense.
> > From looking around in the source I see a few different ways people have done this: -
> > 1) Some drivers encode the data statically into the source and make a decision based on compatible string.
> > 2) Some drivers add a couple of extra dt properties to encode the offset (spifsm in stih416)
> > 3) Some drivers mix address spaces in the reg properties (examples given above)
> > 3) Probably some other ways I've not found yet
> > Is there a blessed way of doing this? It would be nice at least for all the drivers in STI to be doing
> > it the same as currently there seems to be a mix of implementations.
> You can do 1 or 2, not 3.
Yep got it.
One last question, what are the rules about updating ethernet and miphy365 over to using this method for there sysconfig registers?
More information about the linux-arm-kernel