On Tue, Apr 19, 2016 at 03:31:41PM +0200, Lars-Peter Clausen wrote:
> It adds a standard API for dealing with devices that have more than one
> address. It uses the normal way of specifying multiple (named) address in DT.
>
> reg = <0xa>, <0xb>, <0xc>;
> reg-names = "main", "aux1", "aux2";
>
> The function the new i2c_new_secondary_device() function takes the name of
> the address region and allocates a dummy I2C client for it, which can be
> used to access that I2C part of the device that responds to that region. The
> name is used to lookup the address from the name to address map.
Thanks for the explanation.
Yes, I think we can support this in ACPI using both _DSD and built-in
properties so we do not need to add new fields to struct acpi_device
like we did with GPIOs. If _DSD does not have "reg-names" property we
can provide built-in version in a driver:
static const char *mydev_reg_names[] = { "main", "aux1", "aux2" };
static struct property_entry mydev_properties[] = {
PROPERTY_ENTRY_STRING_ARRAY("reg-names", mydev_reg_names),
{ },
};
Then call device_add_properties() for the "primary" I2C client to make
them available to the unified properties API.
The i2c_new_secondary_device() would then look like:
struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
const char *name, u16 default_addr)
{
struct device_node *np = client->dev.of_node;
u32 addr = default_addr;
int i;
i = device_property_match_string(&client->dev, "reg-names", name);
if (i >= 0) {
if (np) {
of_property_read_u32_index(np, "reg", i, &addr);
} else if (has_acpi_companion(&client->dev)) {
/* Look for the ith I2cSerialBus() in _CRS */
}
}
dev_dbg(&client->adapter->dev, "Address for %s : 0x%x\n", name, addr);
return i2c_new_dummy(client->adapter, addr);
}
EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
The above should work with both DT and ACPI so I'm OK with the current
patch. We can add ACPI parts later when needed.
Srinivas, do you think this works with the sensor stuff?
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
