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: <CALszF6Ad93BgT4UsJudVKpfhhL2dbtKTTRno1XqQ5=eANkwXzA@mail.gmail.com>
Date:	Fri, 13 Feb 2015 17:41:43 +0100
From:	Maxime Coquelin <mcoquelin.stm32@...il.com>
To:	Philipp Zabel <p.zabel@...gutronix.de>
Cc:	Jonathan Corbet <corbet@....net>, Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>, Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Joe Perches <joe@...ches.com>, Antti Palosaari <crope@....fi>,
	Tejun Heo <tj@...nel.org>, Will Deacon <will.deacon@....com>,
	Nikolay Borisov <Nikolay.Borisov@....com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Kees Cook <keescook@...omium.org>,
	Michal Marek <mmarek@...e.cz>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"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>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>
Subject: Re: [PATCH 12/14] ARM: dts: Introduce STM32F429 MCU

2015-02-13 17:25 GMT+01:00 Philipp Zabel <p.zabel@...gutronix.de>:
> Hi Maxime,
>
> Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
>> Hi Philipp,
>>
>> 2015-02-13 12:47 GMT+01:00 Philipp Zabel <p.zabel@...gutronix.de>:
>> > Hi Maxime,
>> >
>> > Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
>> > [...]
>> >> +     soc {
>> >> +             reset_ahb1: reset@...23810 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023810 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_ahb2: reset@...23814 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023814 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_ahb3: reset@...23818 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023818 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_apb1: reset@...23820 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023820 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_apb2: reset@...23824 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023824 0x4>;
>> >> +             };
>> >
>> > These are mostly consecutive, single registers. I wonder if these are
>> > part of the same IP block and thus should be grouped together into the
>> > same reset controller node?
>>
>> What I could to is to have two instances. One for AHB and one for APB domain.
>> Doing this, I will have one instance per domain, and only consecutive registers.
>> Is it fine for you?
>
> Looking at
> http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
> Table 34 (RCC register map and reset values), I'd say there is a single
> "Reset and Clock Control" device at 0x40023800 - 0x40023884:
>
>         soc {
>                 rcc: rcc@...23800 {
>                         #clock-cells = <1>;
>                         #reset-cells = <1>;
>                         compatible = "st,stm32-rcc";
>                         reg = <0x40023800 0x84>;
>                 };
>
>                 ...
>
> If you really want to describe the reset controller parts (offsets +0x10
> to +0x24) in a separate node, I won't argue against it too long,
> although this is a somewhat arbitrary decision.
>
> In any case, the whole register at offset +0x1c is reserved, so there is
> no reason to split the reset controller. It is ok to have unused ranges
> as is already the case with reserved bits inside the used registers.

Ok. I understand your point.
But it will be more difficult at usage, because the node referencing
the fourth reset bit of apb2 register will have to pass 164 as
parameter.
It is error prone IMHO.

Other solution would be to add some defines for each reset line in the
DT-Bindings, as we do today for STi platform.
But it is giving an unneeded constraint between DT and reset trees.

Br,
Maxime

>
> regards
> Philipp
>
--
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