linux-kernel - Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

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]

Date:	Wed, 23 Sep 2015 23:29:30 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ray Jui <rjui@...adcom.com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Florian Fainelli <f.fainelli@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	linux-kernel@...r.kernel.org,
	bcm-kernel-feedback-list@...adcom.com,
	Kumar Gala <galak@...eaurora.org>
Subject: Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

On Friday 18 September 2015 15:11:27 Ray Jui wrote:
> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
> > On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> >> +       soc {
> >> +               compatible = "simple-bus";
> >> +               ranges;
> >> +               #address-cells = <1>;
> >> +               #size-cells = <1>;
> > 
> >> +               pinctrl: pinctrl@...1d0c8 {
> >>
> > 
> > Similarly to the core bus, this seems to have address ranges 0x03xxxxxx and
> > 0x18xxxxxx on it, so put those into the ranges.
> >
> 
> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
> decided to put registers for the same block in random locations. We see
> similar issues in all of our other iProc based SoCs. We have
> communicated this to our ASIC team, and hopefully they can revert the
> trend for the next SoC.
> 
> For example, the gpio_ccm has registers in the following regions:
> 
> gpio_ccm: gpio@...0a000 {
>     compatible = "brcm,cygnus-ccm-gpio";
>     reg = <0x1800a000 0x50>,
>           <0x0301d164 0x20>;
> 
> NAND is worse, it has registers in 3 different separate regions:
> 
> nand: nand@...46000 {
>     compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>                  "brcm,brcmnand";
>     reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>           <0x18046f00 0x20>;
> 
> As you can see, this makes it impossible to define a proper address
> range for the bus; therefore, I'll have to keep the ranges undefined and
> a simple 1:1 mapping under this bus.

Hmm, you could still try to list them as non-overlapping with other
buses on the root node like

	ranges = <0x03000000 0x03000000 0x01000000>,
		 <0x18000000 0x18000000 0x01000000>,
		 <0xf8000000 0xf8000000 0x01000000>;

which clarifies how the bus is wired up in hardware.

Alternatively, you could make a more elaborate mapping, if there
are in fact multiple hardware ranges, like

	#address-cells = <2>; # space:offset
	ranges = <1 0  0x03000000 0x01000000>,
		 <2 0  0x18000000 0x01000000>,
		 <3 0  0xf8000000 0x01000000>;

It really depends on what the hardware designers were thinking. If
the AXI bus actually decodes the entire 32-bit address range and devices
are just located at random addresses in there, your current scheme is
probably closest to reality.

> > It probably also makes sense to name the bus according to what kind of
> > bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
> > (e.g. an ahb connected to an axi bus,) then model both of them in the DT.
> 
> Based on the block diagram from the ASIC team, it looks like all of them
> are connected to one major AXI fabric. I can rename the bus to AXI.

Ok.

	Arnd
--
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/