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: <61E0E2A7-F7FC-4397-8E92-06CC409912B9@gmail.com>
Date:	Wed, 15 Jan 2014 10:22:07 -0800
From:	Marc <marc.ceeeee@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
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-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445

Hi Arnd,

Thank you for the suggestion - it's exactly what we were looking for!

Regards,
Marc

Sent from my phone

> On Jan 15, 2014, at 5:10 AM, Arnd Bergmann <arnd@...db.de> wrote:
> 
>> 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ