| 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
| ||
|
Date: Wed, 13 May 2015 15:27:31 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Daniel Thompson <daniel.thompson@...aro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@...il.com>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
Andreas Färber <afaerber@...e.de>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Rob Herring <robh+dt@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Linus Walleij <linus.walleij@...aro.org>,
Stefan Agner <stefan@...er.ch>,
Peter Meerwald <pmeerw@...erw.net>,
Paul Bolle <pebolle@...cali.nl>,
Peter Hurley <peter@...leysoftware.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Russell King <linux@....linux.org.uk>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Joe Perches <joe@...ches.com>,
Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
Lee Jones <lee.jones@...aro.org>,
Jonathan Corbet <corbet@....net>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Mauro Carvalho Chehab <mchehab@....samsung.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>,
Nicolae Rosia <nicolae.rosia@...il.com>,
Kamil Lulko <rev13@...pl>
Subject: Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU
On Wednesday 13 May 2015 13:58:05 Daniel Thompson wrote:
> On 13/05/15 12:45, Maxime Coquelin wrote:
> > 2015-05-12 23:21 GMT+02:00 Arnd Bergmann <arnd@...db.de>:
> >> On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> >>> +#include <dt-bindings/mfd/stm32f4-rcc.h>
> >>> +
> >>>
> >>
> >> Can you find a way to avoid this dependency?
> >>
> >> Maybe you can change the bindings so that the numbers you pass as
> >> arguments to the reset and clock specifiers reflect the numbers that
> >> the hardware use?
> >
> > If I understand correctly, you prefer the way I did in v7 [0]?
Yes, that looks better. I would probably not list all the possible
values in the binding though, when the intention is to use the
hardware specific values, and being able to reuse the binding
and driver for variations of the same chip.
> > Note that doing that won't break the DT binary compatibility, as the
> > raw reset values, or the ones from defines are the same.
> >
> > Daniel, could you share an example of the bindings you would use for the clocks?
>
> For the most cases, where there is a clock gate just before the
> peripheral it looks pretty much like the reset driver and I use the bit
> offset of the clock gating bit as the index.
Is this bit always the same index as the one for the reset driver?
> However there are a couple of clocks without gating just before the
> clock reaches the peripheral:
>
> 1. A hard coded /8. I think this will have to be given a synthetic
> number.
If this is just a divider, why not use a separate DT node for that,
like this:
clock {
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
clock-div = <8>;
clock-mult = <1>;
};
No need to assign a number for this.
> 2. Ungated dividers. For these I am using the bit offset of the LSB of
> the mux field.
Do these ones also come with resets?
> So I think there is only one value that is completely unrelated to the
> hardware and will use a magic constant instead.
>
> I had planned to macros similar to the STM32F4_AxB_RESET() family of
> macros in both clk driver and DT in order to reuse the bit layouts from
> dt-bindings/mfd/stm32f4-rcc.h .
>
> Normal case would have looked like this:
>
> timer3: timer@...00000 {
> compatible = "st,stm32-timer";
> reg = <0x40000000 0x400>;
> interrupts = <28>;
> resets = <&rcc STM32F4_APB1_RESET(TIM3)>;
> clocks = <&rcc STM32F4_APB1_CLK(TIM3)>;
> status = "disabled";
> };
>
> Without the macros it looks like this:
>
> timer3: timer@...00000 {
> compatible = "st,stm32-timer";
> reg = <0x40000000 0x400>;
> interrupts = <28>;
> resets = <&rcc 257>;
> clocks = <&rcc 513>;
> status = "disabled";
> };
>
> However we could perhaps be more literate even if we don't use the macros?
>
> timer3: timer@...00000 {
> compatible = "st,stm32-timer";
> reg = <0x40000000 0x400>;
> interrupts = <28>;
> resets = <&rcc ((0x20*8) + 1)>;
> clocks = <&rcc ((0x40*8) + 1)>;
> status = "disabled";
> };
How about #address-cells = <2>, so you can do
resets = <&rcc 8 1>;
clocks = <&rcc 8 1>;
with the first cell being an index for the block and the second cell the
bit number within that block.
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