class_device_create() and class_interfaces ?

class_device_create() and class_interfaces ?

[Roland Dreier]

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

Re: class_device_create() and class_interfaces ?

[Greg KH]

On Tue, Apr 18, 2006 at 04:46:27PM -0700, Roland Dreier wrote:
> 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.

Yes, you are correct.  class_interfaces are a pain :)

> 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.

I think we already have enough paramaters in that function call...

>  - 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.

I'm working toward getting rid of class_devices entirely.  What you can
do is use a struct device heirachy, right?  If so, take a look at this
patch:
	http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-class.patch
which implements the start of this changeover.  So, if you were to do
this, you can just create a separate "bus" and drivers for these
different devices, and everything should bind just fine.

Yeah, it is hard to create a bus today, but I'm also working on making
that easier too.  You can always just use the platform device interface
now to mock something up to see how well it works out.

thanks,

greg k-h

Re: class_device_create() and class_interfaces ?

[Roland Dreier]

    Greg> I'm working toward getting rid of class_devices entirely.
    Greg> What you can do is use a struct device heirachy, right?  If
    Greg> so, take a look at this patch:
    Greg> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-class.patch
    Greg> which implements the start of this changeover.  So, if you
    Greg> were to do this, you can just create a separate "bus" and
    Greg> drivers for these different devices, and everything should
    Greg> bind just fine.

Hmm, that seems a lot more complicated that what I need.  And it seems
I end up needing to handle some sort of registration myself anyway,
because someone has to create the virtual devices when a real device
shows up (since multiple drivers can't bind to the same device).

I think I'll just code my own simple registration for sub-drivers of
the combo device -- it will just take a list_head, a mutex and a few
of lines of code.  That seems simpler to me than creating a fake bus
and fake devices for each combo device.

Thanks,
  Roland