[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160711141407.GA25042@rob-hp-laptop>
Date: Mon, 11 Jul 2016 09:14:07 -0500
From: Rob Herring <robh@...nel.org>
To: Stephen Warren <swarren@...dotorg.org>
Cc: Sivaram Nair <sivaramn@...dia.com>, Joseph Lo <josephl@...dia.com>,
Thierry Reding <thierry.reding@...il.com>,
Alexandre Courbot <gnurou@...il.com>,
linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Mark Rutland <mark.rutland@....com>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Matthew Longnecker <MLongnecker@...dia.com>,
devicetree@...r.kernel.org, Jassi Brar <jassisinghbrar@...il.com>,
linux-kernel@...r.kernel.org,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>
Subject: Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add
binding for HSP mailbox
On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote:
> On 07/07/2016 12:13 PM, Sivaram Nair wrote:
> >On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote:
> >>Add DT binding for the Hardware Synchronization Primitives (HSP). The
> >>HSP is designed for the processors to share resources and communicate
> >>together. It provides a set of hardware synchronization primitives for
> >>interprocessor communication. So the interprocessor communication (IPC)
> >>protocols can use hardware synchronization primitive, when operating
> >>between two processors not in an SMP relationship.
>
> >>diff --git a/include/dt-bindings/mailbox/tegra186-hsp.h b/include/dt-bindings/mailbox/tegra186-hsp.h
>
> >>+#define HSP_MBOX_TYPE_DB 0x0
> >>+#define HSP_MBOX_TYPE_SM 0x1
> >>+#define HSP_MBOX_TYPE_SS 0x2
> >>+#define HSP_MBOX_TYPE_AS 0x3
> >>+
> >>+#define HSP_DB_MASTER_CCPLEX 17
> >>+#define HSP_DB_MASTER_BPMP 19
> >>+
> >>+#define HSP_MBOX_ID(type, ID) \
> >>+ (HSP_MBOX_TYPE_##type << 16 | ID)
> >
> >It will be nicer if you avoid the macro glue magic '##' for 'type'. I
> >would also suggest to use braces around 'type' and 'ID'.
>
> This technique been used without issue in quite a few other places without
> issue, and has the benefit of simplifying the text wherever the macro is
> used. What issue do you foresee?
I'm not a fan of using the macros to begin with and less so anything
more complex than a single constant value. I'd rather see 2 cells here
with the first being the id and the 2nd being the type.
An issue with token pasting is grepping for DB, SM, etc. in kernel tree
is probably noisy. Not such a big deal here, but a major PIA when you
have more complex sets of includes.
Rob
Powered by blists - more mailing lists