From: dilinger@queued.net (Andres Salomon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 16/17] mc13xxx: mfd_cell is now implicitly available to drivers
Date: Fri, 18 Feb 2011 09:50:29 -0800 [thread overview]
Message-ID: <20110218095029.462e6ef3@queued.net> (raw)
In-Reply-To: <20110218083928.GU22310@pengutronix.de>
On Fri, 18 Feb 2011 09:39:28 +0100
Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> On Wed, Feb 16, 2011 at 09:00:36AM -0800, Andres Salomon wrote:
> > On Wed, 16 Feb 2011 10:41:54 +0100
> > Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> >
> > > On Fri, Feb 11, 2011 at 06:19:21PM -0800, Andres Salomon wrote:
> > > >
> > > > The cell's platform_data is now accessed with a helper function;
> > > > change clients to use that, and remove the now-unused data_size.
> > > >
> > > > Note that mfd-core no longer makes a copy of platform_data, but
> > > > the
> > > why was this changed and where? I'm not able to find your
> > > complete series via gmane.
> >
> > http://permalink.gmane.org/gmane.linux.kernel/1099164
> I still don't get the motivation of your patch set. For drivers that
> don't need the mfd_cells you introduce another level of indirection.
> And drivers that want to use mfd_cells as platform_data, they can
> already now.
>
> Best regards
> Uwe
>
The main motivation for making mfd_cell available to all was to be able
to provide functions within mfd-core (introduced in later
patches/patchsets) that accept platform devices and operate on their
mfd_cells. The mfd_cell used to be automatically carried by the pdevs,
and I'm not entirely sure the reason for getting rid of that. It also
(imo) cleans up a lot of things. For example, the mfd_cell API
platform_data/driver_data stuff was unclear when I first
encountered it, as various drivers were doing things completely
differently (some incorrectly, as witnessed by some of the drivers
that I modified that were using driver_data and had clients later
calling set_drvdata on the same pdev). This is clearer, and provides
a uniform way to do things that, afaict, sacrifices absolutely no
flexibility or functionality. Yes, it adds some overhead by having a
copy of the mfd_cell around in memory, but if that's really an issue it
could be optimized further by not making a full copy of the mfd_cell.
With the new wrappers (mfd_get_data/mfd_get_cell), this could be done
without having to mess with drivers.
WARNING: multiple messages have this Message-ID (diff)
From: Andres Salomon <dilinger@queued.net>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
Russell King <linux@arm.linux.org.uk>,
Samuel Ortiz <sameo@linux.intel.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
linux-kernel@vger.kernel.org, Richard Purdie <rpurdie@rpsys.net>,
Sascha Hauer <kernel@pengutronix.de>,
linux-arm-kernel@lists.infradead.org,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 16/17] mc13xxx: mfd_cell is now implicitly available to drivers
Date: Fri, 18 Feb 2011 09:50:29 -0800 [thread overview]
Message-ID: <20110218095029.462e6ef3@queued.net> (raw)
In-Reply-To: <20110218083928.GU22310@pengutronix.de>
On Fri, 18 Feb 2011 09:39:28 +0100
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> On Wed, Feb 16, 2011 at 09:00:36AM -0800, Andres Salomon wrote:
> > On Wed, 16 Feb 2011 10:41:54 +0100
> > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> >
> > > On Fri, Feb 11, 2011 at 06:19:21PM -0800, Andres Salomon wrote:
> > > >
> > > > The cell's platform_data is now accessed with a helper function;
> > > > change clients to use that, and remove the now-unused data_size.
> > > >
> > > > Note that mfd-core no longer makes a copy of platform_data, but
> > > > the
> > > why was this changed and where? I'm not able to find your
> > > complete series via gmane.
> >
> > http://permalink.gmane.org/gmane.linux.kernel/1099164
> I still don't get the motivation of your patch set. For drivers that
> don't need the mfd_cells you introduce another level of indirection.
> And drivers that want to use mfd_cells as platform_data, they can
> already now.
>
> Best regards
> Uwe
>
The main motivation for making mfd_cell available to all was to be able
to provide functions within mfd-core (introduced in later
patches/patchsets) that accept platform devices and operate on their
mfd_cells. The mfd_cell used to be automatically carried by the pdevs,
and I'm not entirely sure the reason for getting rid of that. It also
(imo) cleans up a lot of things. For example, the mfd_cell API
platform_data/driver_data stuff was unclear when I first
encountered it, as various drivers were doing things completely
differently (some incorrectly, as witnessed by some of the drivers
that I modified that were using driver_data and had clients later
calling set_drvdata on the same pdev). This is clearer, and provides
a uniform way to do things that, afaict, sacrifices absolutely no
flexibility or functionality. Yes, it adds some overhead by having a
copy of the mfd_cell around in memory, but if that's really an issue it
could be optimized further by not making a full copy of the mfd_cell.
With the new wrappers (mfd_get_data/mfd_get_cell), this could be done
without having to mess with drivers.
next prev parent reply other threads:[~2011-02-18 17:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-12 2:19 [PATCH 16/17] mc13xxx: mfd_cell is now implicitly available to drivers Andres Salomon
2011-02-12 2:19 ` Andres Salomon
2011-02-16 9:41 ` Uwe Kleine-König
2011-02-16 9:41 ` Uwe Kleine-König
2011-02-16 12:26 ` Fabio Estevam
2011-02-16 12:26 ` Fabio Estevam
2011-02-16 12:31 ` Fabio Estevam
2011-02-16 12:31 ` Fabio Estevam
2011-02-16 12:58 ` Uwe Kleine-König
2011-02-17 11:53 ` Fabio Estevam
2011-02-17 13:10 ` Uwe Kleine-König
2011-02-19 3:31 ` Fabio Estevam
2011-02-16 17:00 ` Andres Salomon
2011-02-16 17:00 ` Andres Salomon
2011-02-18 8:39 ` Uwe Kleine-König
2011-02-18 8:39 ` Uwe Kleine-König
2011-02-18 17:50 ` Andres Salomon [this message]
2011-02-18 17:50 ` 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=20110218095029.462e6ef3@queued.net \
--to=dilinger@queued.net \
--cc=linux-arm-kernel@lists.infradead.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.