All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v2 1/2] mtd: maps: physmap: Add VPP regulator control
Date: Mon, 23 Jul 2012 19:45:50 +0100	[thread overview]
Message-ID: <20120723184550.GB12438@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1343068929.19880.36.camel@hornet>

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

On Mon, Jul 23, 2012 at 07:42:09PM +0100, Pawel Moll wrote:
> On Mon, 2012-07-23 at 19:32 +0100, Mark Brown wrote:

> > The thing that's particularly bad here is that your change will just
> > silently ignore the error which is far from awesome, at the very least
> > it ought to complain (though I don't think that's a good idea).

> I know, I don't like that myself - that's probably why I don't mind
> dropping that change. Particularly that non-DT boards can always pass
> set_vpp via platform data. And that's what will probably have to happen
> here.

The MMC subsystem went down that path initially but has recently
converted to using regulators more normally.  It provides an explict
callback but uses regulators otherwise IIRC which seems sensible.

> > It shouldn't be that hard to find the in-tree users...

> It was in case of SMSC ethernet drivers ;-)

I think that's more a case of the submitters not looking than anything
else TBH.

> > Well, in the DT case it'll probably start returning -ENODEV soon if
> > there's no supply binding set up (which would get you back to your
> > current case), 

> This would be perfect. Will it happen for 3.7? If so, I'll drop the
> non-OF patch and make the OF one rely on -ENODEV.

It'll happen if anyone does the work; I've not currently got any useful
systems that run DT and don't have a particularly large amount of spare
time.  People were muttering about it, though, for much the reasons you
mentioned.

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

  reply	other threads:[~2012-07-23 18:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-18 13:21 [PATCH v2 0/2] Regulator control of physmap-ed chip's VPP Pawel Moll
2012-07-18 13:22 ` [PATCH v2 1/2] mtd: maps: physmap: Add VPP regulator control Pawel Moll
2012-07-23 17:46   ` Mark Brown
2012-07-23 18:24     ` Pawel Moll
2012-07-23 18:32       ` Mark Brown
2012-07-23 18:42         ` Pawel Moll
2012-07-23 18:45           ` Mark Brown [this message]
2012-07-23 19:04             ` Pawel Moll
2012-07-23 19:12               ` Mark Brown
2012-07-18 13:22 ` [PATCH 2/2] mtd: maps: physmap_of: " Pawel Moll
2012-07-18 16:02 ` [PATCH v2 0/2] Regulator control of physmap-ed chip's VPP Artem Bityutskiy

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=20120723184550.GB12438@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=Artem.Bityutskiy@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pawel.moll@arm.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.