On Thu, Jun 5, 2014 at 11:37 AM, Lee Jones <lee.jones@xxxxxxxxxx> wrote: > On Thu, 05 Jun 2014, Grant Likely wrote: > >> On Wed, 4 Jun 2014 13:09:56 +0100, Lee Jones <lee.jones@xxxxxxxxxx> wrote: >> > 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 <lee.jones@xxxxxxxxxx> >> >> 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.... Actually I would completely skip trying to get the data from ACPI. Since all of this is to continue supporting instantiating devices from sysfs, having a fallback to the OF table completely solves that use case. Anticipating an objection of: "what do we do with drivers that are ACPI only?"... That will be an incredibly rare case. If that ever does happen then we'll solve it by simply adding an of_device_id table. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
