All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	Magnus Damm <magnus.damm@gmail.com>,
	Simon Horman <horms@verge.net.au>,
	Vinod Koul <vinod.koul@intel.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Subject: Re: [PATCH v2 08/15] DMA: shdma: move two macros to a header
Date: Mon, 22 Jul 2013 23:30:07 +0000	[thread overview]
Message-ID: <1823005.aq6zISvliy@avalon> (raw)
In-Reply-To: <Pine.LNX.4.64.1307220834520.7852@axis700.grange>

Hi Guennadi,

On Monday 22 July 2013 08:40:42 Guennadi Liakhovetski wrote:
> On Mon, 22 Jul 2013, Laurent Pinchart wrote:
> > On Friday 19 July 2013 18:29:33 Guennadi Liakhovetski wrote:
> > > Move two generic pointer-conversion macros to a header for common shdma
> > > use.
> > > 
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
> > > ---
> > > 
> > >  drivers/dma/sh/shdma-base.c |    3 ---
> > >  drivers/dma/sh/shdma-of.c   |    2 --
> > >  include/linux/shdma-base.h  |    3 +++
> > >  3 files changed, 3 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
> > > index c5ea256..5b92e72 100644
> > > --- a/drivers/dma/sh/shdma-base.c
> > > +++ b/drivers/dma/sh/shdma-base.c
> > > @@ -36,9 +36,6 @@ enum shdma_desc_status {
> > > 
> > >  #define NR_DESCS_PER_CHANNEL 32
> > > 
> > > -#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan)
> > > -#define to_shdma_dev(d) container_of(d, struct shdma_dev, dma_dev)
> > > -
> > > 
> > >  /*
> > >  
> > >   * For slave DMA we assume, that there is a finite number of DMA slaves
> > >   in
> > > 
> > > the * system, and that each such slave can only use a finite number of
> > > channels. diff --git a/drivers/dma/sh/shdma-of.c
> > > b/drivers/dma/sh/shdma-of.c index 2acf7b6..80d07b5 100644
> > > --- a/drivers/dma/sh/shdma-of.c
> > > +++ b/drivers/dma/sh/shdma-of.c
> > > @@ -17,8 +17,6 @@
> > > 
> > >  #include <linux/platform_device.h>
> > >  #include <linux/shdma-base.h>
> > > 
> > > -#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan)
> > > -
> > > 
> > >  static struct dma_chan *shdma_of_xlate(struct of_phandle_args
> > >  *dma_spec,
> > >  
> > >  				       struct of_dma *ofdma)
> > >  
> > >  {
> > > 
> > > diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
> > > index 31cf89f..45191d7 100644
> > > --- a/include/linux/shdma-base.h
> > > +++ b/include/linux/shdma-base.h
> > > @@ -114,6 +114,9 @@ struct shdma_dev {
> > > 
> > >  #define shdma_for_each_chan(c, d, i) for (i = 0, c = (d)->schan[0]; \
> > >  
> > >  				i < (d)->dma_dev.chancnt; c = (d)->schan[++i])
> > > 
> > > +#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan)
> > > +#define to_shdma_dev(d) container_of(d, struct shdma_dev, dma_dev)
> > > +
> > 
> > While you're at it, it might be a good idea to turn the macros into static
> > inline functions. This would help catching type errors at compilation
> > time.
> 
> Doesn't container_of() already catch all the possible type mismatches in
> this case? E.g. to_shdma_chan() can only work for arguments of the same
> type as the .dma_chan member of struct shdma_chan. Similar for
> to_shdma_dev().

Hmmm... You're right. I recall that a static inline would bring additional 
safety compared to directly using container_of() but I can't recall why. Never 
mind then.

> > >  int shdma_request_irq(struct shdma_chan *, int,
> > >  
> > >  			   unsigned long, const char *);
> > >  
> > >  bool shdma_reset(struct shdma_dev *sdev);

-- 
Regards,

Laurent Pinchart


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	Magnus Damm <magnus.damm@gmail.com>,
	Simon Horman <horms@verge.net.au>,
	Vinod Koul <vinod.koul@intel.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Subject: Re: [PATCH v2 08/15] DMA: shdma: move two macros to a header
Date: Tue, 23 Jul 2013 01:30:07 +0200	[thread overview]
Message-ID: <1823005.aq6zISvliy@avalon> (raw)
In-Reply-To: <Pine.LNX.4.64.1307220834520.7852@axis700.grange>

Hi Guennadi,

On Monday 22 July 2013 08:40:42 Guennadi Liakhovetski wrote:
> On Mon, 22 Jul 2013, Laurent Pinchart wrote:
> > On Friday 19 July 2013 18:29:33 Guennadi Liakhovetski wrote:
> > > Move two generic pointer-conversion macros to a header for common shdma
> > > use.
> > > 
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
> > > ---
> > > 
> > >  drivers/dma/sh/shdma-base.c |    3 ---
> > >  drivers/dma/sh/shdma-of.c   |    2 --
> > >  include/linux/shdma-base.h  |    3 +++
> > >  3 files changed, 3 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
> > > index c5ea256..5b92e72 100644
> > > --- a/drivers/dma/sh/shdma-base.c
> > > +++ b/drivers/dma/sh/shdma-base.c
> > > @@ -36,9 +36,6 @@ enum shdma_desc_status {
> > > 
> > >  #define NR_DESCS_PER_CHANNEL 32
> > > 
> > > -#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan)
> > > -#define to_shdma_dev(d) container_of(d, struct shdma_dev, dma_dev)
> > > -
> > > 
> > >  /*
> > >  
> > >   * For slave DMA we assume, that there is a finite number of DMA slaves
> > >   in
> > > 
> > > the * system, and that each such slave can only use a finite number of
> > > channels. diff --git a/drivers/dma/sh/shdma-of.c
> > > b/drivers/dma/sh/shdma-of.c index 2acf7b6..80d07b5 100644
> > > --- a/drivers/dma/sh/shdma-of.c
> > > +++ b/drivers/dma/sh/shdma-of.c
> > > @@ -17,8 +17,6 @@
> > > 
> > >  #include <linux/platform_device.h>
> > >  #include <linux/shdma-base.h>
> > > 
> > > -#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan)
> > > -
> > > 
> > >  static struct dma_chan *shdma_of_xlate(struct of_phandle_args
> > >  *dma_spec,
> > >  
> > >  				       struct of_dma *ofdma)
> > >  
> > >  {
> > > 
> > > diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
> > > index 31cf89f..45191d7 100644
> > > --- a/include/linux/shdma-base.h
> > > +++ b/include/linux/shdma-base.h
> > > @@ -114,6 +114,9 @@ struct shdma_dev {
> > > 
> > >  #define shdma_for_each_chan(c, d, i) for (i = 0, c = (d)->schan[0]; \
> > >  
> > >  				i < (d)->dma_dev.chancnt; c = (d)->schan[++i])
> > > 
> > > +#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan)
> > > +#define to_shdma_dev(d) container_of(d, struct shdma_dev, dma_dev)
> > > +
> > 
> > While you're at it, it might be a good idea to turn the macros into static
> > inline functions. This would help catching type errors at compilation
> > time.
> 
> Doesn't container_of() already catch all the possible type mismatches in
> this case? E.g. to_shdma_chan() can only work for arguments of the same
> type as the .dma_chan member of struct shdma_chan. Similar for
> to_shdma_dev().

Hmmm... You're right. I recall that a static inline would bring additional 
safety compared to directly using container_of() but I can't recall why. Never 
mind then.

> > >  int shdma_request_irq(struct shdma_chan *, int,
> > >  
> > >  			   unsigned long, const char *);
> > >  
> > >  bool shdma_reset(struct shdma_dev *sdev);

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2013-07-22 23:30 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-19 16:29 [PATCH v2 00/15] ARM: shmobile: move DMAC configuration data in the driver Guennadi Liakhovetski
2013-07-19 16:29 ` Guennadi Liakhovetski
2013-07-19 16:29 ` [PATCH v2 01/15] DMA: shdma: add support for DMAC configuration data, supplied via device ID Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-19 16:29 ` [PATCH v2 02/15] DMA: shdma: add r8a7740 DMAC data to the device ID table Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-19 16:29 ` [PATCH v2 03/15] DMA: shdma: add r8a73a4 " Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-19 16:29 ` [PATCH v2 04/15] DMA: shdma: make a pointer const Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-21 21:54   ` Laurent Pinchart
2013-07-21 21:54     ` Laurent Pinchart
2013-07-22  7:53     ` Guennadi Liakhovetski
2013-07-22  7:53       ` Guennadi Liakhovetski
2013-07-22 23:37       ` Laurent Pinchart
2013-07-22 23:37         ` Laurent Pinchart
2013-07-19 16:29 ` [PATCH v2 05/15] DMA: shdma: pass SoC-specific configuration to the driver via OF matching Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-21 22:12   ` Laurent Pinchart
2013-07-21 22:12     ` Laurent Pinchart
2013-07-22  7:29     ` Guennadi Liakhovetski
2013-07-22  7:29       ` Guennadi Liakhovetski
2013-07-22 23:23       ` Laurent Pinchart
2013-07-22 23:23         ` Laurent Pinchart
2013-07-19 16:29 ` [PATCH v2 06/15] DMA: shdma: make multiplexer platform data optional Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-19 16:29 ` [PATCH v2 07/15] DMA: shdma: add sh73a0 DMAC data to the device ID table Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-20 11:28   ` [PATCH v3 " Guennadi Liakhovetski
2013-07-20 11:28     ` Guennadi Liakhovetski
2013-07-23  1:29     ` Simon Horman
2013-07-23  1:29       ` Simon Horman
2013-07-19 16:29 ` [PATCH v2 08/15] DMA: shdma: move two macros to a header Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-21 22:16   ` Laurent Pinchart
2013-07-21 22:16     ` Laurent Pinchart
2013-07-22  6:40     ` Guennadi Liakhovetski
2013-07-22  6:40       ` Guennadi Liakhovetski
2013-07-22 23:30       ` Laurent Pinchart [this message]
2013-07-22 23:30         ` Laurent Pinchart
2013-07-19 16:29 ` [PATCH v2 09/15] DMA: shdma: support referencing specific DMACs within a multiplexer in DT Guennadi Liakhovetski
2013-07-19 16:29   ` Guennadi Liakhovetski
2013-07-21 22:23   ` Laurent Pinchart
2013-07-21 22:23     ` Laurent Pinchart
2013-07-22  6:34     ` Guennadi Liakhovetski
2013-07-22  6:34       ` Guennadi Liakhovetski
2013-07-22 23:35       ` Laurent Pinchart
2013-07-22 23:35         ` Laurent Pinchart
2013-07-19 20:22 ` [PATCH v2 10/15] ARM: shmobile: r8a73a4: add a DMAC platform device and clock for it Guennadi Liakhovetski
2013-07-19 20:22   ` Guennadi Liakhovetski
2013-07-19 20:22 ` [PATCH v2 11/15] ARM: shmobile: r8a7740: switch DMAC controllers to using device ID data Guennadi Liakhovetski
2013-07-19 20:22   ` Guennadi Liakhovetski
2013-07-19 20:22 ` [PATCH v2 12/15] ARM: shmobile: r8a7740: add DT nodes and clock aliases for three DMAC instances Guennadi Liakhovetski
2013-07-19 20:22   ` Guennadi Liakhovetski
2013-07-19 20:22 ` [PATCH v2 13/15] ARM: shmobile: r8a73a4: add a DT node and a clock alias for the DMAC Guennadi Liakhovetski
2013-07-19 20:22   ` Guennadi Liakhovetski
2013-07-19 20:22 ` [PATCH v2 14/15] ARM: shmobile: sh73a0: switch DMAC controllers to using device ID data Guennadi Liakhovetski
2013-07-19 20:22   ` Guennadi Liakhovetski
2013-07-19 20:22 ` [PATCH v2 15/15] ARM: shmobile: r8a7740: add support for 2 RTDMACs Guennadi Liakhovetski
2013-07-19 20:22   ` Guennadi Liakhovetski

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=1823005.aq6zISvliy@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=horms@verge.net.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=vinod.koul@intel.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 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.