Regulator consumer and i2c device interaction.

Dear All,

Currently regulator consumers are registered and identified via a pointer to the relevant device:

e.g. via a regulator consumer supply structure:

static struct regulator_consumer_supply imote2_sensor_3_con[] = {
	{
		.dev = &sht15.dev,
		.supply = "vcc",
	},
};

static struct regulator_init_data imote2_ldo_init_data[] = {{
	{
	 	.constraints = {
		.name = "vcc_sensor_3",
		.min_uV = 2800000,
		.max_uV = 3000000,
		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
	},
	.num_consumer_supplies = ARRAY_SIZE(imote2_sensor_3_con),
	.consumer_supplies = imote2_sensor_3_con,
},

};

and relevant association with a regulator driver.

Now in the case of i2c devices, the struct device pointer is created somewhat later and isn't readily available.

I think the struct device pointer is only used as device instance specific token in the regulator framework. If so is there any reason it can't be relaxed to a void * thus allowing something else to be used in i2c drivers?

If so what could actually be used? Unfortunately all the data elements of i2c_board_info are coppied out (rather than a pointer to the original structure being used) so that's not currently available. I guess it could be made so at the cost of a single pointer in each i2c_client structure.

So the question is how would people prefer to do this?

Thanks,

--
Jonathan Cameron

On Sat, Jan 10, 2009 at 04:01:22PM +0000, Jonathan Cameron wrote:

[Regulators use a struct device and a supply name for lookup...]

That's the primary reason - this idiom is also used by at least the clock API and possibly other things. It also allows us to do things like show which devices are supplied by which regulators in sysfs.

That's doable at the cost of the diagnostic info but...

...as you say it's a bit tricky to use right now. I haven't checked but I expect that the platform data that you can supply in the i2c board info would work as a token, though it's far from ideal and there may be no other need for platform data.

As a temporary workaround note that the regulator API allows the device to be NULL at the minute, though there is a desire to remove that option. Providing your regulators have unique names you will be able to pass the supply name in as platform data and use that only. This usage is not encouraged and will hopefully become invalid over time, it's there at the minute mainly because we don't have a good idea what to use for the struct device for cpufreq drivers.

It'd be nice to be able to access the struct device for i2c devices more readily at registration time. Like I say, it's not a regulator specific issue so it'd be good to come up with a general solution.

Oops, that won't work as typically these are specified __initdata . Any suggestions for alternatives?