[PATCH 1/2] mfd: max8925: request resource region
Arnd Bergmann
arnd at arndb.de
Wed May 9 12:26:27 EDT 2012
On Wednesday 09 May 2012, Russell King - ARM Linux wrote:
> Instead, we should be having per-device resources trees. So, for instance,
> an I2C device with two functions, function 1 say owns register indices
> 0-0x3f and function 2 owns 0x40-0x7f. We should have:
>
> struct i2c_blah_driver_info {
> struct resource reg_res;
> };
>
> priv->reg_res.start = 0;
> priv->reg_res.end = 0x7f;
> priv->reg_res.flags = 0;
>
> subdev1->resource[0].start = 0;
> subdev1->resource[0].end = 0x3f;
> subdev1->resource[0].flags = 0;
>
> ret = request_resource(&priv->reg_res, &subdev1->resource[0]);
> /* check ret */
>
> subdev2->resource[0].start = 0x40;
> subdev2->resource[0].end = 0x7f;
> subdev2->resource[0].flags = 0;
>
> ret = request_resource(&priv->reg_res, &subdev2->resource[0]);
> /* check ret */
>
> This means that we end up with lots of per-device resource trees rooted
> at the top-level-device driver, each effectively with their own separate
> name spaces.
Ah, I had not realized that this is possible. In this case, it certainly
makes sense to have a separate space for each device that provides a
register range.
> Do we care about making them appear in procfs? I suspect at this stage
> that would be wrong. If we care at all, they should probably be per-
> top-level-device sysfs files - and we should have a function which sysfs
> can use along with the root resource to create that output.
If the resources have separate roots, I see no way how to make them
all appear in the same procfs file. Having them represented in sysfs
the way you describe sounds useful but not important.
Arnd
More information about the linux-arm-kernel
mailing list