linux-kernel - Re: [PATCH 3/7] i2c: Add the ability to match device to compatible string without an of

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 6 Jun 2014 09:10:26 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Grant Likely <grant.likely@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	wsa@...-dreams.de, linux-i2c@...r.kernel.org,
	devicetree@...r.kernel.org, linus.walleij@...aro.org
Subject: Re: [PATCH 3/7] i2c: Add the ability to match device to compatible
 string without an of_node

On Thu, 05 Jun 2014, Grant Likely wrote:

> On Wed,  4 Jun 2014 13:09:52 +0100, Lee Jones <lee.jones@...aro.org> wrote:
> > A great deal of I2C devices are currently matched via DT node name, and
> > as such the compatible naming convention of '<vendor>,<device>' has gone
> > somewhat awry - some nodes don't supply one, some supply an arbitrary
> > string and others the correct device name with an arbitrary vendor prefix.
> > 
> > In an effort to correct this problem we have to supply a mechanism to
> > match a device by compatible string AND by simple device name.  This
> > function strips off the '<vendor>,' part of a supplied compatible string
> > and attempts to match without it.
> > 
> > The plan is to remove this function once all of the compatible strings
> > for each device have been brought into line.
> > 
> > Signed-off-by: Lee Jones <lee.jones@...aro.org>
> > ---
> >  drivers/i2c/i2c-core.c | 25 +++++++++++++++++++++++++
> >  include/linux/i2c.h    | 10 ++++++++++
> >  2 files changed, 35 insertions(+)
> > 
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index d3802dc..7dcd5c3 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -1090,6 +1090,31 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
> >  	return i2c_verify_adapter(dev);
> >  }
> >  EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
> > +
> > +const struct of_device_id
> > +*i2c_of_match_device_strip_vendor(const struct of_device_id *matches,
> > +				  struct device *dev)
> > +{
> > +	const struct i2c_client *client = i2c_verify_client(dev);
> > +	const char *name;
> > +
> > +	if (!(client && matches))
> > +		return NULL;
> > +
> > +	for (; matches->compatible[0]; matches++) {
> > +		name = strchr(matches->compatible, ',');
> > +		if (!name)
> > +			name = matches->compatible;
> > +		else
> > +			name++;
> > +
> > +		if (!strncmp(client->name, name, strlen(client->name)))
> > +			return matches;
> > +	}
> 
> Is it actually necessary to strip off the vendor name? It would be fine
> to make users include the vendor prefix when creating the device in
> sysfs. In fact that would be preferrable for new drivers so that vendor
> prefixes start getting used correctly.

I see a few issues with this strategy.  Firstly, there are already
users registering their devices via sysfs, some are taking their
device names from an EEPROM which would require reprogramming in order
to prefix the vendor ID.  I'm keen not to break existing systems -
which not stripping off the vendor name would inevitably do.
Secondly, I'm not sure how Wolfram would feel about the client->name
containing a DT compatible string. And finally, other than looking
at the kernel source, there is no real way for a user to know if the
device supports ACPI or OF, or neither and if an i2c_device_table is
supplied or not.

Remember that the idea of this set is to remove i2c_device_table's,
doing so will break any devices which are still registering via sysfs
with only the model number of the device.  I think the sysfs
interface should be a black-box.  I think requiring users to have
kernel knowledge is a sub-optimal idea.

> If you're worried about preserving exisiting ABI, then I would make
> striping the prefix an option that drivers can enable, but by default
> only match on the full string.
> 
> g.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/