On Fri, Nov 2, 2012 at 2:03 PM, Corentin Chary <[email protected]> wrote: > On Fri, Nov 2, 2012 at 12:45 PM, Olof Johansson <[email protected]> wrote: >> On Fri, Oct 26, 2012 at 10:30 AM, Corentin Chary >> <[email protected]> wrote: >> >>> Looks better, but I'm curious, what is the final purpose of this driver ? >>> What ABI will be exposed, who will use it ? >>> >>> If it is going to be bigger, it may be a good idea to convert it to a >>> real platform driver (platform_drivers/platform_device stuff). >> >> It's not a driver per se. It's platform glue that, based on the DMI >> table, registers platform and i2c devices (at this time only i2c >> devices). >> >> Unfortunately there's no way to do this nicely from userspace after >> boot, since there's limits to how much data you can provide with the >> simpler userspace-driven i2c probing protocol. >> >> So, there's no user-facing ABI on this, and no one is expected to use >> it from userspace. It's just there to make sure that the un-probably >> devices on this kind of hardware gets bound to drivers properly. >> >> If it's converted to a platform_driver, how do you expect that to >> probe, where would the platform_device be registered? > > I guess I would check dmi in the module init method, and then use the > probe callback of platform_create_bundle to do more probing if > necessary.
Maybe I'm dense but I don't see how that could possibly be better than what the code does today. It would just add more overhead and clutter by creating a unnecessary dummy device/driver setup just to, in the end, register the same i2c devices. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
