Thread (38 messages) 38 messages, 8 authors, 2014-06-07

[PATCH 7/7] OF/ACPI/I2C: Add generic match function for the aforementioned systems

From: Grant Likely <hidden>
Date: 2014-06-05 17:38:09
Also in: linux-devicetree, linux-i2c, lkml

On Thu, Jun 5, 2014 at 4:55 PM, Lee Jones [off-list ref] wrote:
On Thu, 05 Jun 2014, Grant Likely wrote:
quoted
On Thu, Jun 5, 2014 at 11:37 AM, Lee Jones [off-list ref] wrote:
quoted
On Thu, 05 Jun 2014, Grant Likely wrote:
quoted
On Wed,  4 Jun 2014 13:09:56 +0100, Lee Jones [off-list ref] wrote:
quoted
Currently this is a helper function for the I2C subsystem to aid the
matching of non-standard compatible strings and devices which use DT
and/or ACPI, but do not supply any nodes (see: [1] Method 4).  However,
it has been made more generic as it can be used to only make one call
for drivers which support any mixture of OF, ACPI and/or I2C matching.

The initial aim is for of_match_device() to be replaced by this call
in all I2C device drivers.

[1] Documentation/i2c/instantiating-devices

Signed-off-by: Lee Jones <redacted>
I don't like this. It drops all type safety on the match entry
and the caller has no idea what it got back.
Okay, so what's the best way forward?

Introduce a i2c_of_match_device() call instead?
I still think the way to do it is to emulate the missing i2c_device_id
when calling the drivers .probe() hook by having a temporary copy on
the stack and filling it with data from the OF or ACPI table....
That's the opposite of what I'm trying to achieve.  I'm trying to get
rid of unused i2c_device_id tables, rather than reinforce their
mandatory existence.  I think an i2c_of_match_device() with knowledge
of how to match via pure DT principles (of_node/compatible) and a
fall-back, which is able to match on a provided of_device_id table
alone i.e. without the requirement of an existing of_node.
What I'm suggesting does allow all those tables to be removed, but
without a painful API breakage... having said that, it is only the
drivers that drop their i2c_device_id tables that need to support the
fallback behaviour, so it would be fine to pass null into the
i2c_device_id argument and make the driver call the new function that
returns an of_device_id regardless of whether a node is attached.
I've also been mulling over the idea of removing the second probe()
parameter, as suggested by Wolfram.  However, this has quite deep
ramifications which would require a great deal of driver adaptions.
That is of course the ideal. It would be a lot of work (I count 633
users), but it would get i2c exactly where you want it to be. I did
that kind of work when I merge platform_bus_type with
of_platform_bus_type.

You can mitigate it though by creating a .probe2 hook that doesn't
have the parameter and then change over all the users in separate
commits, finally removing the old hook when safe to do so.

g.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help