class_device_create() and class_interfaces ?

[Roland Dreier <rdreier@cisco.com>]

Hi Greg,

I'm trying to write some code that uses struct class_interface to do
something when a class device appears.  However, if I follow the new
world order of class_create() and class_device_create(), I seem to run
into a problem.

Because class_device_create() allocates its own struct class_device
memory, one can't use container_of() to get back to the original
driver-specific device information.  The standard solution is to use
class_set_devdata() to stash a pointer back.

However, if one has a class_interface registered for the class, then
the class_interface.add() method gets called before class_device_create()
even returns, so there's no chance to call class_set_devdata().  This
means that the class_interface can't really do much with the class_device
that it got, because it has no way to get to any interesting information
about the real device.

The situation I'm thinking of is one device that implements multiple
completely different functions -- for example an MPEG codec and a
thermometer -- through the exact same registers etc.  So I want to
have a core driver that manages real hardware access, and then
separate MPEG codec and thermometer drivers.  The design I have in
mind is that the MPEG and thermometer sub-drivers register class
interfaces with the core driver, which creates a class device for each
real hardware device it finds.  But the sub-drivers need some way of
getting from the class device to a structure that lets them call back
into the core driver.

I see several solutions:

 - Add a devdata parameter to class_device_create() so that devdata
   can be set before class_interfaces are called.
 - Create a new class_device_create_with_devdata() function to do the
   same thing without churning a bunch of existing drivers...
 - Solve the core driver/sub-driver problem in a better way that
   doesn't use class_devices or class_interfaces -- I'm open to
   suggestions here.  I could implement my own registration handling
   -- it's pretty trivial -- but duplicating what the driver model
   already has seems silly.

What are your thoughts?  I'm happy to code up a patch for 2.6.18 for
either of the first two solutions above.

Thanks,
  Roland