linux-kernel - Re: [PATCH v2] i2c: Add generic support passing secondary devices addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Apr 2016 17:40:27 +0300
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Jean-Michel Hautbois <jhautbois@...il.com>,
	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	devicetree@...r.kernel.org, galak@...eaurora.org,
	ijc+devicetree@...lion.org.uk, mark.rutland@....com,
	pawel.moll@....com, robh+dt@...nel.org, wsa@...-dreams.de,
	laurent.pinchart@...asonboard.com,
	Jean-Michel Hautbois <jean-michel.hautbois@...-labs.com>
Subject: Re: [PATCH v2] i2c: Add generic support passing secondary devices
 addresses

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?