[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110715182954.GB2833@ponder.secretlab.ca>
Date: Fri, 15 Jul 2011 12:29:54 -0600
From: Grant Likely <grant.likely@...retlab.ca>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: Greg KH <greg@...ah.com>,
Dimitris Papastamos <dp@...nsource.wolfsonmicro.com>,
Liam Girdwood <lrg@...com>,
Samuel Oritz <sameo@...ux.intel.com>,
Graeme Gregory <gg@...mlogic.co.uk>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] regulator: Convert tps65023 to use regmap API
On Fri, Jul 15, 2011 at 01:48:05PM +0900, Mark Brown wrote:
> On Thu, Jul 14, 2011 at 08:53:28PM -0600, Grant Likely wrote:
> > On Sat, Jul 09, 2011 at 01:50:44PM +0900, Mark Brown wrote:
>
> > > - mutex_init(&tps->io_lock);
> > > + tps->regmap = regmap_init(&client->dev, &tps65023_regmap_config);
>
> > Yeah, if this usage is typical, the caller will always know exactly
> > what kind of regmap it needs to set up because it had an i2c_client or
> > an spi_device instance. I think it would be better to drop the
> > central registration of regmap bus types and use bus-specific init
> > variant. It just makes for one more bit of registration
> > infrastructure that needs to be setup before any drivers us it.
>
> Right, the driver is always going to know exactly what bus it registered
> on but for many drivers we don't really have any bus-specific code once
> we factor out the register I/O.
Exactly my point. The only time a global registration list is needed
is at setup time. Once the regmap structure is initialized, it
doesn't need to reference the list. I far prefer the simplicity of an
explicit bus type initialization than the implicit method with the
extra indirection code needed to implement it, by my measure, ~60-70
lines of code.
Also, making is explicit guarantees that there is no question about
the i2c or spi module of regmap getting loaded before it gets used.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists