All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>,
	Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>,
	Andres Salomon <dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
	khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org,
	ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
	Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org>,
	Mauro Carvalho Chehab
	<mchehab-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	David Brownell
	<dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	Mocean Laboratories
	<info-l7gf1WXxx3uGw+nKnLezzg@public.gmane.org>
Subject: Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
Date: Thu, 7 Apr 2011 11:06:50 -0700	[thread overview]
Message-ID: <20110407180650.GA3261@angua.secretlab.ca> (raw)
In-Reply-To: <20110407150322.GB3923@sortiz-mobl>

On Thu, Apr 07, 2011 at 05:03:23PM +0200, Samuel Ortiz wrote:
> On Thu, Apr 07, 2011 at 07:35:15AM -0700, Grant Likely wrote:
> > > Below is a patch for the Xilinx SPI example. Although this would fix the
> > > issue, we'd still have to do that on device per device basis. I had a similar
> > > solution where MFD drivers would set a flag for sub drivers that don't need
> > > any of the MFD bits. In that case the MFD core code would just forward the
> > > platform data, instead of embedding it through an MFD cell.
> > 
> > platform_data is already a fiddly bit where you don't know what
> > structure type platform_data points at; it is implicitly known and
> > easy to get wrong.  This solution makes me *very* nervous
> > because it would become even easier to get a mismatch on the
> > platform_data pointer type.
> How would that be more error prone than say a board file instantiating a
> platform device after having set the platform_data pointer to point to an
> implicitely know structure reference ?

Yes, platform_data is already troublesome, but at least current
convention is a 1:1 relationship between driver and platform_data
type.  I still hate it and want something better, but it is what we
have.  The problem with what having a different platform_data pointer
depending on the instantiation means that it adds yet another level of
decision that needs to be made and is very easy to get wrong.

So, yes, platform_data is bad.  I don't want to see it get any worse.

> 
> Cheers,
> Samuel.
> 
> P.S.: Would you be ok with something like the patch below ?

Not really because it requires the driver to make the correct decision
about the platform_data type depending on the driver name.  It is easy
to get wrong and the compiler cannot help you catch it.

I've talked with Greg, and adding the mfd_cell pointer to
platform_device will be okay in the short term.  In the long term I'm
looking at creating a better way of attaching type-safe data to
devices that will pretty much eliminate this issue.

> 
> > > ---
> > >  drivers/mfd/timberdale.c |    8 ++++----
> > >  drivers/spi/xilinx_spi.c |   19 ++++++++++++++++++-
> > >  include/linux/mfd/core.h |    3 +++
> > >  3 files changed, 25 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
> > > index 94c6c8a..c9220ce 100644
> > > --- a/drivers/mfd/timberdale.c
> > > +++ b/drivers/mfd/timberdale.c
> > > @@ -416,7 +416,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg0[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > @@ -476,7 +476,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg1[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > @@ -526,7 +526,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg2[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > @@ -570,7 +570,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg3[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> > > index c69c6f2..3287b84 100644
> > > --- a/drivers/spi/xilinx_spi.c
> > > +++ b/drivers/spi/xilinx_spi.c
> > > @@ -471,7 +471,11 @@ static int __devinit xilinx_spi_probe(struct platform_device *dev)
> > >  	struct spi_master *master;
> > >  	u8 i;
> > >  
> > > -	pdata = mfd_get_data(dev);
> > > +	if (platform_get_device_id(dev) &&
> > > +	    platform_get_device_id(dev)->driver_data & MFD_PLATFORM_DEVICE)
> > > +		pdata = mfd_get_data(dev);
> > > +	else
> > > +		pdata = dev->dev.platform_data;
> > >  	if (pdata) {
> > >  		num_cs = pdata->num_chipselect;
> > >  		little_endian = pdata->little_endian;
> > > @@ -530,6 +534,18 @@ static int __devexit xilinx_spi_remove(struct platform_device *dev)
> > >  /* work with hotplug and coldplug */
> > >  MODULE_ALIAS("platform:" XILINX_SPI_NAME);
> > >  
> > > +static const struct platform_device_id xilinx_spi_id_table[] = {
> > > +	{
> > > +		.name	= XILINX_SPI_NAME,
> > > +	},
> > > +	{
> > > +		.name	= "mfd_xilinx_spi",
> > > +		.driver_data = MFD_PLATFORM_DEVICE,
> > > +	},
> > > +	{  },	/* Terminating Entry */
> > > +};
> > > +MODULE_DEVICE_TABLE(platform, xilinx_spi_id_table);
> > > +
> > >  static struct platform_driver xilinx_spi_driver = {
> > >  	.probe = xilinx_spi_probe,
> > >  	.remove = __devexit_p(xilinx_spi_remove),
> > > @@ -538,6 +554,7 @@ static struct platform_driver xilinx_spi_driver = {
> > >  		.owner = THIS_MODULE,
> > >  		.of_match_table = xilinx_spi_of_match,
> > >  	},
> > > +	.id_table	= xilinx_spi_id_table,
> > >  };
> > >  
> > >  static int __init xilinx_spi_pltfm_init(void)
> > > diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> > > index ad1b19a..13f31f4 100644
> > > --- a/include/linux/mfd/core.h
> > > +++ b/include/linux/mfd/core.h
> > > @@ -89,6 +89,9 @@ static inline const struct mfd_cell *mfd_get_cell(struct platform_device *pdev)
> > >  	return pdev->dev.platform_data;
> > >  }
> > >  
> > > +/* */
> > > +#define MFD_PLATFORM_DEVICE BIT(0)
> > > +
> > >  /*
> > >   * Given a platform device that's been created by mfd_add_devices(), fetch
> > >   * the .mfd_data entry from the mfd_cell that created it.
> > > 
> > > 
> > > -- 
> > > Intel Open Source Technology Centre
> > > http://oss.intel.com/
> 
> -- 
> Intel Open Source Technology Centre
> http://oss.intel.com/

WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: Samuel Ortiz <sameo@linux.intel.com>
Cc: Felipe Balbi <balbi@ti.com>, Greg KH <gregkh@suse.de>,
	Andres Salomon <dilinger@queued.net>,
	linux-kernel@vger.kernel.org,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	khali@linux-fr.org, ben-linux@fluff.org,
	Peter Korsgaard <jacmet@sunsite.dk>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	David Brownell <dbrownell@users.sourceforge.net>,
	linux-i2c@vger.kernel.org, linux-media@vger.kernel.org,
	netdev@vger.kernel.org, spi-devel-general@lists.sourceforge.net,
	Mocean Laboratories <info@mocean-labs.com>
Subject: Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
Date: Thu, 7 Apr 2011 11:06:50 -0700	[thread overview]
Message-ID: <20110407180650.GA3261@angua.secretlab.ca> (raw)
In-Reply-To: <20110407150322.GB3923@sortiz-mobl>

On Thu, Apr 07, 2011 at 05:03:23PM +0200, Samuel Ortiz wrote:
> On Thu, Apr 07, 2011 at 07:35:15AM -0700, Grant Likely wrote:
> > > Below is a patch for the Xilinx SPI example. Although this would fix the
> > > issue, we'd still have to do that on device per device basis. I had a similar
> > > solution where MFD drivers would set a flag for sub drivers that don't need
> > > any of the MFD bits. In that case the MFD core code would just forward the
> > > platform data, instead of embedding it through an MFD cell.
> > 
> > platform_data is already a fiddly bit where you don't know what
> > structure type platform_data points at; it is implicitly known and
> > easy to get wrong.  This solution makes me *very* nervous
> > because it would become even easier to get a mismatch on the
> > platform_data pointer type.
> How would that be more error prone than say a board file instantiating a
> platform device after having set the platform_data pointer to point to an
> implicitely know structure reference ?

Yes, platform_data is already troublesome, but at least current
convention is a 1:1 relationship between driver and platform_data
type.  I still hate it and want something better, but it is what we
have.  The problem with what having a different platform_data pointer
depending on the instantiation means that it adds yet another level of
decision that needs to be made and is very easy to get wrong.

So, yes, platform_data is bad.  I don't want to see it get any worse.

> 
> Cheers,
> Samuel.
> 
> P.S.: Would you be ok with something like the patch below ?

Not really because it requires the driver to make the correct decision
about the platform_data type depending on the driver name.  It is easy
to get wrong and the compiler cannot help you catch it.

I've talked with Greg, and adding the mfd_cell pointer to
platform_device will be okay in the short term.  In the long term I'm
looking at creating a better way of attaching type-safe data to
devices that will pretty much eliminate this issue.

> 
> > > ---
> > >  drivers/mfd/timberdale.c |    8 ++++----
> > >  drivers/spi/xilinx_spi.c |   19 ++++++++++++++++++-
> > >  include/linux/mfd/core.h |    3 +++
> > >  3 files changed, 25 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
> > > index 94c6c8a..c9220ce 100644
> > > --- a/drivers/mfd/timberdale.c
> > > +++ b/drivers/mfd/timberdale.c
> > > @@ -416,7 +416,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg0[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > @@ -476,7 +476,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg1[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > @@ -526,7 +526,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg2[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > @@ -570,7 +570,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg3[] = {
> > >  		.mfd_data = &timberdale_radio_platform_data,
> > >  	},
> > >  	{
> > > -		.name = "xilinx_spi",
> > > +		.name = "mfd_xilinx_spi",
> > >  		.num_resources = ARRAY_SIZE(timberdale_spi_resources),
> > >  		.resources = timberdale_spi_resources,
> > >  		.mfd_data = &timberdale_xspi_platform_data,
> > > diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> > > index c69c6f2..3287b84 100644
> > > --- a/drivers/spi/xilinx_spi.c
> > > +++ b/drivers/spi/xilinx_spi.c
> > > @@ -471,7 +471,11 @@ static int __devinit xilinx_spi_probe(struct platform_device *dev)
> > >  	struct spi_master *master;
> > >  	u8 i;
> > >  
> > > -	pdata = mfd_get_data(dev);
> > > +	if (platform_get_device_id(dev) &&
> > > +	    platform_get_device_id(dev)->driver_data & MFD_PLATFORM_DEVICE)
> > > +		pdata = mfd_get_data(dev);
> > > +	else
> > > +		pdata = dev->dev.platform_data;
> > >  	if (pdata) {
> > >  		num_cs = pdata->num_chipselect;
> > >  		little_endian = pdata->little_endian;
> > > @@ -530,6 +534,18 @@ static int __devexit xilinx_spi_remove(struct platform_device *dev)
> > >  /* work with hotplug and coldplug */
> > >  MODULE_ALIAS("platform:" XILINX_SPI_NAME);
> > >  
> > > +static const struct platform_device_id xilinx_spi_id_table[] = {
> > > +	{
> > > +		.name	= XILINX_SPI_NAME,
> > > +	},
> > > +	{
> > > +		.name	= "mfd_xilinx_spi",
> > > +		.driver_data = MFD_PLATFORM_DEVICE,
> > > +	},
> > > +	{  },	/* Terminating Entry */
> > > +};
> > > +MODULE_DEVICE_TABLE(platform, xilinx_spi_id_table);
> > > +
> > >  static struct platform_driver xilinx_spi_driver = {
> > >  	.probe = xilinx_spi_probe,
> > >  	.remove = __devexit_p(xilinx_spi_remove),
> > > @@ -538,6 +554,7 @@ static struct platform_driver xilinx_spi_driver = {
> > >  		.owner = THIS_MODULE,
> > >  		.of_match_table = xilinx_spi_of_match,
> > >  	},
> > > +	.id_table	= xilinx_spi_id_table,
> > >  };
> > >  
> > >  static int __init xilinx_spi_pltfm_init(void)
> > > diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> > > index ad1b19a..13f31f4 100644
> > > --- a/include/linux/mfd/core.h
> > > +++ b/include/linux/mfd/core.h
> > > @@ -89,6 +89,9 @@ static inline const struct mfd_cell *mfd_get_cell(struct platform_device *pdev)
> > >  	return pdev->dev.platform_data;
> > >  }
> > >  
> > > +/* */
> > > +#define MFD_PLATFORM_DEVICE BIT(0)
> > > +
> > >  /*
> > >   * Given a platform device that's been created by mfd_add_devices(), fetch
> > >   * the .mfd_data entry from the mfd_cell that created it.
> > > 
> > > 
> > > -- 
> > > Intel Open Source Technology Centre
> > > http://oss.intel.com/
> 
> -- 
> Intel Open Source Technology Centre
> http://oss.intel.com/

  reply	other threads:[~2011-04-07 18:06 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03  3:54 [RFC] [PATCH 0/19] mfd sharing support Andres Salomon
2011-02-03  3:55 ` [PATCH 01/19] mfd-core: unconditionally add mfd_cell to every platform_device Andres Salomon
2011-02-03  3:58 ` [lm-sensors] [PATCH 02/19] jz4740: mfd_cell is now implicitly Andres Salomon
2011-02-03  3:58   ` [PATCH 02/19] jz4740: mfd_cell is now implicitly available to drivers Andres Salomon
2011-02-03  8:09   ` [lm-sensors] [PATCH 02/19] jz4740: mfd_cell is now implicitly Jean Delvare
2011-02-03  8:09     ` [PATCH 02/19] jz4740: mfd_cell is now implicitly available to drivers Jean Delvare
2011-02-03  4:01 ` [PATCH 03/19] ab3550: " Andres Salomon
2011-02-03  4:01   ` Andres Salomon
2011-02-04  8:20   ` Mattias Wallin
2011-02-04  8:20     ` Mattias Wallin
2011-02-03  4:03 ` [PATCH 04/19] ab3100: " Andres Salomon
2011-02-03  4:03   ` Andres Salomon
2011-02-03 12:52   ` Linus Walleij
2011-02-03 12:52     ` Linus Walleij
2011-02-03  4:04 ` [PATCH 05/19] asic3: " Andres Salomon
2011-02-03  4:05 ` [PATCH 06/19] htc-pasic3: " Andres Salomon
     [not found] ` <20110202195417.228e2656-pFFUokh25LWsTnJN9+BGXg@public.gmane.org>
2011-02-03  4:08   ` [PATCH 07/19] timberdale: " Andres Salomon
2011-02-03  4:08     ` Andres Salomon
2011-03-31 23:05     ` Grant Likely
     [not found]       ` <20110331230522.GI437-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-04-01 11:20         ` Samuel Ortiz
2011-04-01 11:20           ` Samuel Ortiz
2011-04-01 17:47           ` Andres Salomon
2011-04-01 17:47             ` Andres Salomon
2011-04-01 17:56             ` Grant Likely
2011-04-01 17:56               ` Grant Likely
2011-04-01 18:00               ` Grant Likely
     [not found]               ` <BANLkTi=bCd_+f=EG-O=U5VH_ZNjFhxkziQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-04-01 23:52                 ` Samuel Ortiz
2011-04-01 23:52                   ` Samuel Ortiz
2011-04-01 23:58                   ` Grant Likely
2011-04-01 23:58                     ` Grant Likely
     [not found]                     ` <BANLkTi=bq=OGzXFp7qiBr7x_BnGOWf=DRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-04-02  0:10                       ` Andres Salomon
2011-04-02  0:10                         ` Andres Salomon
2011-04-04 10:03                       ` Samuel Ortiz
2011-04-04 10:03                         ` Samuel Ortiz
2011-04-05  3:04                         ` Grant Likely
2011-04-06 15:23                           ` Samuel Ortiz
2011-04-06 15:58                             ` Greg KH
2011-04-06 15:58                               ` Greg KH
2011-04-06 17:05                               ` Samuel Ortiz
2011-04-06 17:16                                 ` Ben Hutchings
2011-04-06 17:51                                   ` Samuel Ortiz
2011-04-06 17:51                                     ` Samuel Ortiz
2011-04-06 18:07                                     ` Ben Hutchings
2011-04-06 18:07                                       ` Ben Hutchings
2011-04-06 17:56                                 ` Greg KH
2011-04-06 18:25                                   ` Andres Salomon
2011-04-06 18:38                                     ` Greg KH
2011-04-06 18:38                                       ` Greg KH
     [not found]                                       ` <20110406183854.GA10058-l3A5Bk7waGM@public.gmane.org>
2011-04-07  8:04                                         ` Grant Likely
2011-04-07  8:04                                           ` Grant Likely
2011-04-06 18:47                                   ` Samuel Ortiz
2011-04-06 18:59                                     ` Felipe Balbi
2011-04-06 18:59                                       ` Felipe Balbi
     [not found]                                       ` <20110406185902.GN25654-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2011-04-06 22:09                                         ` Greg KH
2011-04-06 22:09                                           ` Greg KH
2011-04-07  8:09                                           ` Felipe Balbi
2011-04-07 13:40                                         ` Samuel Ortiz
2011-04-07 13:40                                           ` Samuel Ortiz
2011-04-07 14:35                                           ` Grant Likely
     [not found]                                             ` <20110407143515.GC26452-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2011-04-07 15:03                                               ` Samuel Ortiz
2011-04-07 15:03                                                 ` Samuel Ortiz
2011-04-07 18:06                                                 ` Grant Likely [this message]
2011-04-07 18:06                                                   ` Grant Likely
2011-04-07 16:24                           ` Grant Likely
2011-04-01 18:26             ` Samuel Ortiz
2011-02-03  4:09 ` [PATCH 08/19] t7166xb: " Andres Salomon
2011-02-03  4:11 ` [PATCH 09/19] wl1273: " Andres Salomon
2011-02-03  4:12 ` [PATCH 10/19] sh_mobile_sdhi: " Andres Salomon
2011-02-03  4:13 ` [PATCH 11/19] tc6393xb: " Andres Salomon
2011-02-03  4:15 ` [PATCH 12/19] twl4030: " Andres Salomon
2011-02-03  6:05   ` Dmitry Torokhov
2011-02-03  6:39     ` Andres Salomon
2011-02-03  6:53       ` Dmitry Torokhov
2011-02-03  7:03         ` Andres Salomon
2011-02-03  7:03           ` Andres Salomon
2011-02-03  9:31           ` Mark Brown
2011-02-03  9:31             ` Mark Brown
2011-02-05  2:39             ` Andres Salomon
2011-02-05  3:25               ` Andres Salomon
2011-02-03 12:23           ` Peter Ujfalusi
2011-02-03 12:23             ` Peter Ujfalusi
2011-02-04 10:41           ` Uwe Kleine-König
2011-02-03  4:16 ` [PATCH 13/19] tc6387xb: " Andres Salomon
2011-02-03  4:17 ` [PATCH 14/19] janz: " Andres Salomon
2011-02-03  4:20 ` [PATCH 15/19] mc13xxx: " Andres Salomon
2011-02-03  4:20   ` Andres Salomon
2011-02-04  9:34   ` Uwe Kleine-König
2011-02-04  9:34     ` Uwe Kleine-König
2011-02-04 10:13     ` Uwe Kleine-König
2011-02-04 10:13       ` Uwe Kleine-König
2011-02-04 10:16     ` Andres Salomon
2011-02-04 10:16       ` Andres Salomon
2011-02-03  4:21 ` [PATCH 16/19] mfd-core: drop platform_data/data_size from core mfd_cell struct Andres Salomon
2011-02-03  4:22 ` [PATCH 17/19] mfd-core: add refcounting support to mfd_cells Andres Salomon
2011-02-03  4:23 ` [PATCH 18/19] mfd-core: add platform_device sharing support for mfd Andres Salomon
2011-02-03  4:26 ` [PATCH 19/19] cs5535-mfd: add sharing for acpi/pms cells Andres Salomon

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=20110407180650.GA3261@angua.secretlab.ca \
    --to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
    --cc=balbi-l0cyMroinI0@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org \
    --cc=gregkh-l3A5Bk7waGM@public.gmane.org \
    --cc=info-l7gf1WXxx3uGw+nKnLezzg@public.gmane.org \
    --cc=jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mchehab-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /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.