linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: 3ds_debugboard: Let ethernet be functional again
Date: Mon, 27 Feb 2012 10:04:53 +0100	[thread overview]
Message-ID: <20120227090453.GE26642@pengutronix.de> (raw)
In-Reply-To: <20120216075825.GA11631@opensource.wolfsonmicro.com>

On Wed, Feb 15, 2012 at 11:58:26PM -0800, Mark Brown wrote:
> On Thu, Feb 16, 2012 at 08:32:36AM +0100, Sascha Hauer wrote:
> > On Tue, Feb 14, 2012 at 09:29:04AM -0800, Mark Brown wrote:
> 
> > > The main thing here is to avoid these driver specific bodges that people
> > > keep churning out again and again, it's quite depressing really.
> 
> > I think this churning will continue until we either make the dummy
> > regulator non optional and drop this warning that gets printed each
> > time it is used, or we at least provide a way to easily add a fixed
> 
> That's obviously not a good idea, if we do that we may as well just drop
> all error checking from the API.
> 
> > dummy regulator without adding >20 lines of code to each board just
> > for saying that we don't have a regulator for this particular device.
> 
> It's not per device, of course - there's an overhead from putting a
> fixed regulator in but then per supply it's just a line.
> 
> > +#if IS_ENABLED(CONFIG_REGULATOR_FIXED_VOLTAGE)
> > +struct platform_device *regulator_register_fixed(const char *name, int id,
> > +		int microvolts, struct regulator_consumer_supply *supplies,
> > +		int num_supplies);
> > +#else
> > +static struct platform_device *regulator_register_fixed(const char *name, int id,
> > +		int microvolts, struct regulator_consumer_supply *supplies,
> > +		int num_supplies)
> > +{
> > +	return NULL;
> > +}
> > +#endif
> 
> This is obviously not good for users, they'd still have to do error
> checking to determine if the device was created or not and then manually
> register the device with the driver core and ideally also care if that
> worked or not.  I'm not sure something like this will really save enough
> unless the device actually gets registered by the function, otherwise
> it's going to be converting data to code.
> 
> I'd also drop the microvolts and name parameters, if people are going to
> be doing enough work to describe the individual rails on the board
> they're probably not going to be put off by having to register a
> platform device.

If I drop the microvolts parameter what microvolts should I assume? I
tried 0 but the regulator core does not like it:

machine_constraints_voltage: dummy: unsupportable voltage constraints

(with max: -2147483648 min: 2147483647)

Sascha



-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  parent reply	other threads:[~2012-02-27  9:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-07 20:27 [PATCH] ARM: 3ds_debugboard: Let ethernet be functional again Fabio Estevam
2012-02-13  8:27 ` Sascha Hauer
2012-02-13 12:18   ` Fabio Estevam
2012-02-13 14:48   ` Mark Brown
2012-02-14 10:58     ` Sascha Hauer
2012-02-14 17:29       ` Mark Brown
2012-02-16  7:32         ` Sascha Hauer
2012-02-16  7:58           ` Mark Brown
2012-02-16  9:13             ` Sascha Hauer
2012-02-16 16:27               ` Mark Brown
2012-02-17  7:40                 ` Sascha Hauer
2012-02-17 16:29                   ` Mark Brown
2012-02-27  9:04             ` Sascha Hauer [this message]
2012-02-27 13:29               ` Mark Brown
2012-02-27 17:20                 ` Sascha Hauer
2012-02-27 23:54                   ` Mark Brown
2012-02-28  8:27                     ` Sascha Hauer
2012-02-28 10:52                       ` Mark Brown
2012-02-29  8:33                         ` Sascha Hauer
2012-02-29 10:00                           ` Mark Brown
2012-03-01 10:08             ` Sascha Hauer
2012-03-01 10:52               ` Mark Brown
2012-03-01 18:20                 ` Sascha Hauer
2012-03-01 18:21                   ` Mark Brown
2012-03-01 18:30                     ` Sascha Hauer

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=20120227090453.GE26642@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).