All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Ospite <ospite@studenti.unina.it>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	openezx-devel@lists.openezx.org,
	spi-devel-general@lists.sourceforge.net
Subject: Re: [PATCH v3] mmc_spi.c: add support for the regulator framework
Date: Wed, 18 May 2011 19:23:20 +0200	[thread overview]
Message-ID: <20110518192320.9dd69cb5.ospite@studenti.unina.it> (raw)
In-Reply-To: <20110511205703.GA24486@opensource.wolfsonmicro.com>

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

On Wed, 11 May 2011 22:57:04 +0200
Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> On Wed, May 11, 2011 at 10:53:37PM +0200, Antonio Ospite wrote:
> 
> > OK, avoiding some duplication will be good, I agree.
> 
> > I am resending a v4 with the equivalent code:
> > 
> > 	if (host->vcc) {
> > 		int ret;
> > 
> > 		if (power_mode == MMC_POWER_OFF)
> > 			vdd = 0;
> > 
> 
> This isn't really what I meant - what I meant was that all this logic
> looks like it's generic to multiple drivers.  We either set a regulator
> or call a pdata callback to set power, both of which are completely
> external to the controller.
>

So you mean something like the following:

mmc_regulator_set_power(...)
{
	if (host->vcc) {
		...
	}

	if (host->pdata && host->pdata->setpower)
		host->pdata->setpower(mmc_dev(host->mmc), vdd);
}

I like  the idea, the only concern I have is that the mmc host drivers 
can call 'vcc' and 'pdata' and 'setpower' with arbitrary names, what is 
the kernel practice in cases like this where we want to use some common 
code accessing driver-specific structures? I can think to three 
alternatives right now:

  1. Consider only code currently in mainline (names are consistently 
     vcc, pdata and setpower) and use a _macro_ based on that, assuming 
     than future patches are going to copy the var names anyways.

  2. Add a proper function with all the needed parameters to abstract
     the actual var names, this would be something like:
     mmc_regulator_set_power(mmc, power_mode, vdd, vcc, pdata)
     and yet checking for pdata->setpower can be tricky as 'setpower' 
     is an arbitrary name.

  3. Move stuff from driver structures to subsystem structures, which I 
     don't think is needed in this case.

  4. (The hidden lazy one) make the code equal across all the drivers
     so new drivers copying it will be consistent, but still leave it 
     duplicate.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2011-05-18 17:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-21 18:46 [PATCH 0/4] mmc_spi: Add support for regulator framework Antonio Ospite
2011-03-21 18:46 ` [PATCH 1/4] mmc_spi.c: factor out the check for power capability Antonio Ospite
2011-03-21 18:46 ` [PATCH 2/4] mmc_spi.c: factor out the SD card shutdown sequence Antonio Ospite
2011-03-21 18:46 ` [PATCH 3/4] mmc_spi.c: factor out a mmc_spi_setpower() function Antonio Ospite
2011-03-21 18:46 ` [PATCH 4/4] mmc_spi.c: add support for the regulator framework Antonio Ospite
2011-04-04  9:56 ` [PATCH 0/4] mmc_spi: Add support for " Antonio Ospite
2011-04-05  3:05   ` Grant Likely
2011-04-05  8:43     ` Antonio Ospite
2011-04-05 13:46       ` Grant Likely
2011-04-21 12:27 ` [RESEND PATCH " Antonio Ospite
2011-04-21 12:27   ` [RESEND PATCH 1/4] mmc_spi.c: factor out the check for power capability Antonio Ospite
2011-04-21 12:27   ` [RESEND PATCH 2/4] mmc_spi.c: factor out the SD card shutdown sequence Antonio Ospite
2011-04-21 12:27   ` [RESEND PATCH 3/4] mmc_spi.c: factor out a mmc_spi_setpower() function Antonio Ospite
2011-04-21 12:27   ` [RESEND PATCH 4/4] mmc_spi.c: add support for the regulator framework Antonio Ospite
2011-04-21 12:40     ` Mark Brown
2011-04-21 12:49       ` Antonio Ospite
2011-04-26 21:21         ` Daniel Ribeiro
2011-04-22 12:43       ` [PATCH v2 " Antonio Ospite
2011-05-06 14:30         ` Antonio Ospite
2011-05-11 10:39         ` [PATCH v3] " Antonio Ospite
     [not found]           ` <1305110379-17218-1-git-send-email-ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn@public.gmane.org>
2011-05-11 13:08             ` Mark Brown
2011-05-11 20:53               ` Antonio Ospite
2011-05-11 20:57                 ` Mark Brown
2011-05-18 17:23                   ` Antonio Ospite [this message]
2011-05-18 19:42                     ` Mark Brown
2011-05-23 15:10                       ` Antonio Ospite
2011-05-30  9:07                         ` Antonio Ospite
2011-05-30 10:14                           ` Mark Brown
2011-05-30 10:57                             ` Antonio Ospite
2011-05-31 10:05                               ` Mark Brown

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=20110518192320.9dd69cb5.ospite@studenti.unina.it \
    --to=ospite@studenti.unina.it \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=cjb@laptop.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-mmc@vger.kernel.org \
    --cc=openezx-devel@lists.openezx.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /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.