linux-kernel - Re: [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445

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: <201401151410.39112.arnd@arndb.de>
Date:	Wed, 15 Jan 2014 14:10:38 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Marc Carino <marc.ceeeee@...il.com>
Cc:	Christian Daudt <bcm@...thebug.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Matt Porter <matt.porter@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445

On Wednesday 15 January 2014, Marc Carino wrote:
> +       gen-ctrl {
> +               compatible = "brcm,brcmstb-gen-ctrl-v1";
> +               reg = <0xf0404304 0x4
> +                      0xf0404308 0x4
> +                      0xf03e2578 0x4
> +                      0xf03e2488 0x10
> +                      0xf0452000 0x20>;
> +       };

Sorry I didn't get back to you on this when we discussed the previous
version. I'm actually less happy with this DT representation than the
original. What I take from your description is that you have multiple
register ranges that basically combine more-or-less random registers
that belong into different Linux subsystems.

I think the best way to deal with this is to have the "syscon" driver
handle the multiplexing between the various drivers that need access
to the registers. It would look something like (taking the numbers
from your previous patch):

	ahb {
		ranges = <0 0xf0000000 0x1000000>; /* 16 MB remapped registers */

		hif-cpubuictrl: syscon@...400 {
			compatible = "brcm,7445-cpubioctrl", "syscon";
			reg = <0x3e2000, 0x1000>;
		};

		hif-continuation: syscon@...00 {
			compatible = "brcm,7445-hif-continuation", "syscon";
			reg = <0x452000, 0x1000>;
		};

		sun-top-ctrl: ...
	};

This lets the syscon driver find and map the three register areas.
Drivers that need access to the registers then do 

	reset {
		compatible = "brcm,7445-reset-ctrl";
		syscon = <&sun-top-ctrl 0x300 0x100>;
		#reset-cells = <1>;
	};

And then you can add a regular device driver to drivers/reset that provides
a device_reset() API to other drivers, or a system-reset function to be
registered as arm_pm_restart. This driver would use
syscon_regmap_lookup_by_phandle() to get access to a regmap pointer,
and then use either hardcoded offsets into the regmap, or get those
offsets from numbers in the devicetree, as provided in the example
above.

	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/