From: <b.brezillon@overkiz.com>
To: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Richard Genoud <richard.genoud@gmail.com>,
Ludovic Desroches <ludovic.desroches@atmel.com>,
Russell King <linux@arm.linux.org.uk>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/8] ARM: at91: move peripheral id definitions to dt-bindings include dir
Date: Tue, 20 Aug 2013 08:11:37 +0200 [thread overview]
Message-ID: <37721084ba1145097fc0dcbb8d74acb7@localhost> (raw)
In-Reply-To: <52124BD5.5060801@atmel.com>
Hello Nicolas,
On Mon, 19 Aug 2013 18:46:13 +0200, Nicolas Ferre
<nicolas.ferre@atmel.com> wrote:
> On 08/08/2013 06:09, boris brezillon :
>> Hello Arnd,
>>
>> On 07/08/2013 22:24, Arnd Bergmann wrote:
>>> On Thursday 01 August 2013, Boris BREZILLON wrote:
>>>> This patch moves peripheral id definitions from machine specific include
>>>> dir (arch/arm/mach-at91/include/mach/'soc-name'.h) to dt-bindinds include
>>>> dir (include/dt-bindings/at91/'soc-name'/peripherals.h).
>>>>
>>>> These definitions will be used inside dt to define interrupt ids and
>>>> peripheral clk ids.
>>>>
>>>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>>> This seems counterproductive, why would you do that?
>>
>> This was requested by Jean-Christophe Plagniol-Villard (and proposed by
>> Richard Genoud)
>> for the 3rd version of the "ARM: at91: move to common clk framework"
>> patch series (see
>> https://lkml.org/lkml/2013/7/29/361) and thought it was a good idea too
>> (even if I didn't know
>> where to put the macro files as there are no soc specific macro files in
>> dt-bindings include
>> dir).
>>
>> Indeed I found it much easier to detect bugs in dt definition using
>> macros because
>> the macro names and dt node names are the same (it does not protect
>> against errors
>> in the macro definitions).
>>
>> If you think these macro definitions should be dropped, I won't argue
>> against this.
>> But please, have a talk with Jean-Christophe first.
>
> [..]
>
>>> There is no sharing of identifiers across SoCs here, you just move the
>>> data around, and changing the .dts files to use the abstract macros would
>>> just end up making them harder to understand, not easier, since you then
>>> have to look up the numbers in another file.
>
> Boris, Jean-Christophe and Richard,
>
> Well, I must say that I do agree with Arnd on this point.
>
> I think that a simple numeric field in a cell has to be represented
> as a number and even if this simple information is used twice
> (interrupt number and clock bit position in PMC). The possibility of
> error is very low compared to the big amount of unneeded definitions
> added by this solution.
>
> Moreover, I had the hope to completely remove this long list of
> peripheral definitions for all SoC when we have a full DT kernel (with
> your patches about common clock framework). So I think it is not
> interesting to move in this direction and continue to build such a
> list for future full DT products...
>
> Believe me, I am sorry that I didn't entered the discussion earlier
> and avoid unnecessary work... Anyway, give me your opinion, but I do
> think that the simpler is the best.
>
As discussed with you (on IRC), I am not absolutely convinced we need
these macro definitions, and given the direction you want to take
(completely
remove the peripheral id definitions), i would say we'd rather drop
this patch.
It won't bother me at all to rework the "sama5 dt clk" patch series
(this is the
only SoC I supported in the 3rd version of the at91 common clk
transition)
to remove references to these macros.
Best Regards,
Boris
> Bye,
next prev parent reply other threads:[~2013-08-20 6:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 6:48 [PATCH 0/8] ARM: at91/dt: make use of periph id macros Boris BREZILLON
2013-08-01 6:52 ` [PATCH 1/8] ARM: at91: move peripheral id definitions to dt-bindings include dir Boris BREZILLON
2013-08-07 20:24 ` Arnd Bergmann
2013-08-08 4:09 ` boris brezillon
2013-08-19 16:46 ` Nicolas Ferre
2013-08-20 6:11 ` b.brezillon [this message]
2013-08-20 9:21 ` Richard Genoud
2013-08-01 6:53 ` [PATCH 2/8] ARM: at91/dt: use periph id macros for at91rm9200 interrupt definitions Boris BREZILLON
2013-08-01 6:54 ` [PATCH 3/8] ARM: at91/dt: use periph id macros for at91sam9260 " Boris BREZILLON
2013-08-01 6:55 ` [PATCH 4/8] ARM: at91/dt: use periph id macros for at91sam9263 " Boris BREZILLON
2013-08-01 6:57 ` [PATCH 5/8] ARM: at91/dt: use periph id macros for at91sam9g45 " Boris BREZILLON
2013-08-01 6:58 ` [PATCH 6/8] ARM: at91/dt: use periph id macros for at91sam9n12 " Boris BREZILLON
2013-08-01 7:00 ` [PATCH 7/8] ARM: at91/dt: use periph id macros for at91sam9x5 " Boris BREZILLON
2013-08-01 7:01 ` [PATCH 8/8] ARM: at91/dt: use periph id macros for sama5d3 " Boris BREZILLON
2013-08-01 7:37 ` [PATCH 0/8] ARM: at91/dt: make use of periph id macros Richard Genoud
2013-08-01 9:27 ` Richard Genoud
2013-08-01 11:06 ` boris brezillon
2013-08-01 11:13 ` Mark Brown
2013-08-01 11:20 ` boris brezillon
2013-08-02 9:04 ` boris brezillon
2013-08-02 9:28 ` Richard Genoud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37721084ba1145097fc0dcbb8d74acb7@localhost \
--to=b.brezillon@overkiz.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=ludovic.desroches@atmel.com \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.com \
--cc=richard.genoud@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox