linux-kernel - Re: [PATCH v2 13/14] ARM: STi: DT: STiH410: Add usb2 picophy dt nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141114133425.GA28680@griffinp-ThinkPad-X1-Carbon-2nd>
Date:	Fri, 14 Nov 2014 13:34:25 +0000
From:	Peter Griffin <peter.griffin@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	srinivas.kandagatla@...il.com, patrice.chotard@...com,
	linux-kernel@...r.kernel.org, lee.jones@...aro.org,
	maxime.coquelin@...com
Subject: Re: [PATCH v2 13/14] ARM: STi: DT: STiH410: Add usb2 picophy dt nodes

Hi Arnd,

Thanks for taking the time to explain this.

On Fri, 14 Nov 2014, Arnd Bergmann wrote:
<snip>
> > 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
> driver.

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? 

regards,

Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/