All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: "Sascha Hauer" <s.hauer@pengutronix.de>,
	linux-kernel@vger.kernel.org,
	"Wolfram Sang" <w.sang@pengutronix.de>,
	thierry.nolf.barco@gmail.com,
	"Huang Shijie" <b32955@freescale.com>,
	linux-mtd@lists.infradead.org,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Lothar Waßmann" <LW@karo-electronics.de>
Subject: Re: [PATCH] new helper to define common struct resource constructs
Date: Wed, 13 Jul 2011 23:42:18 +0200	[thread overview]
Message-ID: <201107132342.18648.arnd@arndb.de> (raw)
In-Reply-To: <20110713141849.b8cbf675.akpm@linux-foundation.org>

On Wednesday 13 July 2011 23:18:49 Andrew Morton wrote:
> > On Monday 11 July 2011, Uwe Kleine-K__nig wrote:
> > > resource definitions that just define start, end and flags = IORESOURCE_MEM
> > > or IORESOURCE_IRQ (with start=end) are quite common. So introduce a shortcut
> > > for them. Also make available a macro to specify named resources of both
> > > types which are less common.
> > > 
> > > Signed-off-by: Uwe Kleine-K____nig <u.kleine-koenig@pengutronix.de>
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > What do others think, is this worthwhile?
> > Should we also define macros for IORESOURCE_IO and IORESOURCE_DMA?
> > 
> 
> It would help if we could see some usage examples (ie: sample
> conversions), to get a better idea of the value of this.

Uwe posted a patch '[PATCH] ARM: mxc: use new helpers to define
common struct resource entries' that converts one ARM platform to use
it, with reasonable outcome:

26 files changed, 72 insertions(+), 308 deletions(-)

This platform has 72 definitions of static resources, in total there
are well over 2000 such defintions in ARM alone, and the number is
growing. Some platforms have started creating their own macros for
this purpose, which is why I suggested doing it globally (or alternatively
removing the macros from these platforms if we conclude that they
are harmful).

> Also, DEFINE_RES_NAMED() is going to need a bunch of argument
> parentheses to make it bulletproof.

Right.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] new helper to define common struct resource constructs
Date: Wed, 13 Jul 2011 23:42:18 +0200	[thread overview]
Message-ID: <201107132342.18648.arnd@arndb.de> (raw)
In-Reply-To: <20110713141849.b8cbf675.akpm@linux-foundation.org>

On Wednesday 13 July 2011 23:18:49 Andrew Morton wrote:
> > On Monday 11 July 2011, Uwe Kleine-K__nig wrote:
> > > resource definitions that just define start, end and flags = IORESOURCE_MEM
> > > or IORESOURCE_IRQ (with start=end) are quite common. So introduce a shortcut
> > > for them. Also make available a macro to specify named resources of both
> > > types which are less common.
> > > 
> > > Signed-off-by: Uwe Kleine-K____nig <u.kleine-koenig@pengutronix.de>
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > What do others think, is this worthwhile?
> > Should we also define macros for IORESOURCE_IO and IORESOURCE_DMA?
> > 
> 
> It would help if we could see some usage examples (ie: sample
> conversions), to get a better idea of the value of this.

Uwe posted a patch '[PATCH] ARM: mxc: use new helpers to define
common struct resource entries' that converts one ARM platform to use
it, with reasonable outcome:

26 files changed, 72 insertions(+), 308 deletions(-)

This platform has 72 definitions of static resources, in total there
are well over 2000 such defintions in ARM alone, and the number is
growing. Some platforms have started creating their own macros for
this purpose, which is why I suggested doing it globally (or alternatively
removing the macros from these platforms if we conclude that they
are harmful).

> Also, DEFINE_RES_NAMED() is going to need a bunch of argument
> parentheses to make it bulletproof.

Right.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Wolfram Sang" <w.sang@pengutronix.de>,
	linux-kernel@vger.kernel.org, thierry.nolf.barco@gmail.com,
	"Huang Shijie" <b32955@freescale.com>,
	linux-mtd@lists.infradead.org,
	" Uwe Kleine-König " <u.kleine-koenig@pengutronix.de>,
	"Lothar Waßmann" <LW@karo-electronics.de>
Subject: Re: [PATCH] new helper to define common struct resource constructs
Date: Wed, 13 Jul 2011 23:42:18 +0200	[thread overview]
Message-ID: <201107132342.18648.arnd@arndb.de> (raw)
In-Reply-To: <20110713141849.b8cbf675.akpm@linux-foundation.org>

On Wednesday 13 July 2011 23:18:49 Andrew Morton wrote:
> > On Monday 11 July 2011, Uwe Kleine-K__nig wrote:
> > > resource definitions that just define start, end and flags = IORESOURCE_MEM
> > > or IORESOURCE_IRQ (with start=end) are quite common. So introduce a shortcut
> > > for them. Also make available a macro to specify named resources of both
> > > types which are less common.
> > > 
> > > Signed-off-by: Uwe Kleine-K____nig <u.kleine-koenig@pengutronix.de>
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > What do others think, is this worthwhile?
> > Should we also define macros for IORESOURCE_IO and IORESOURCE_DMA?
> > 
> 
> It would help if we could see some usage examples (ie: sample
> conversions), to get a better idea of the value of this.

Uwe posted a patch '[PATCH] ARM: mxc: use new helpers to define
common struct resource entries' that converts one ARM platform to use
it, with reasonable outcome:

26 files changed, 72 insertions(+), 308 deletions(-)

This platform has 72 definitions of static resources, in total there
are well over 2000 such defintions in ARM alone, and the number is
growing. Some platforms have started creating their own macros for
this purpose, which is why I suggested doing it globally (or alternatively
removing the macros from these platforms if we conclude that they
are harmful).

> Also, DEFINE_RES_NAMED() is going to need a bunch of argument
> parentheses to make it bulletproof.

Right.

	Arnd

  reply	other threads:[~2011-07-13 21:42 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 16:12 reply: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28 Huang Shijie-B32955
2011-06-30 16:12 ` Huang Shijie-B32955
2011-06-30 22:29 ` Arnd Bergmann
2011-06-30 22:29   ` Arnd Bergmann
2011-07-01  6:44   ` Uwe Kleine-König
2011-07-01  6:44     ` Uwe Kleine-König
2011-07-01  8:57   ` Huang Shijie
2011-07-01  8:57     ` Huang Shijie
2011-07-01  9:09     ` Arnd Bergmann
2011-07-01  9:09       ` Arnd Bergmann
2011-07-07  8:56       ` Huang Shijie
2011-07-07  8:56         ` Huang Shijie
2011-07-07 15:57         ` Arnd Bergmann
2011-07-07 15:57           ` Arnd Bergmann
2011-07-07 20:48           ` reply: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for?imx23/imx28 Uwe Kleine-König
2011-07-07 20:48             ` Uwe Kleine-König
2011-07-07 21:04             ` Arnd Bergmann
2011-07-07 21:04               ` Arnd Bergmann
2011-07-11 14:40               ` [PATCH] new helper to define common struct resource constructs Uwe Kleine-König
2011-07-11 14:40                 ` Uwe Kleine-König
2011-07-11 15:03                 ` [PATCH] ARM: mxc: use new helpers to define common struct resource entries Uwe Kleine-König
2011-07-11 15:03                   ` Uwe Kleine-König
2011-07-12 13:29                 ` [PATCH] new helper to define common struct resource constructs Arnd Bergmann
2011-07-12 13:29                   ` Arnd Bergmann
2011-07-12 13:29                   ` Arnd Bergmann
2011-07-12 17:13                   ` H Hartley Sweeten
2011-07-12 17:13                     ` H Hartley Sweeten
2011-07-12 18:31                     ` [PATCH v2] " Uwe Kleine-König
2011-07-12 18:31                       ` Uwe Kleine-König
2011-07-12 18:31                       ` Uwe Kleine-König
2011-07-13 21:18                   ` [PATCH] " Andrew Morton
2011-07-13 21:18                     ` Andrew Morton
2011-07-13 21:18                     ` Andrew Morton
2011-07-13 21:42                     ` Arnd Bergmann [this message]
2011-07-13 21:42                       ` Arnd Bergmann
2011-07-13 21:42                       ` Arnd Bergmann
2011-07-13 22:15                       ` H Hartley Sweeten
2011-07-13 22:15                         ` H Hartley Sweeten
2011-07-14  8:11                     ` [PATCH v3] " Uwe Kleine-König
2011-07-14  8:11                       ` Uwe Kleine-König
2011-07-14  8:11                       ` Uwe Kleine-König
2011-07-14 11:34                       ` Lothar Waßmann
2011-07-14 11:34                         ` Lothar Waßmann
2011-07-14 11:34                         ` Lothar Waßmann
2011-07-01 14:52     ` reply: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28 Arnd Bergmann
2011-07-01 14:52       ` Arnd Bergmann

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=201107132342.18648.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=LW@karo-electronics.de \
    --cc=akpm@linux-foundation.org \
    --cc=b32955@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    --cc=thierry.nolf.barco@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=w.sang@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.