Re: [linux-usb-devel] Re: [RFC] Changes to the driver model class code.

[David Brownell]

On Tuesday 15 March 2005 2:05 pm, Dmitry Torokhov wrote:
> I think I was shopping around for the examples of proper driver model
> integration in 2.6.2 - 2.6.3 timeframe for the serio bus. I was
> looking at how USB was working around the fact that one can not
> add/remove children from the probe/remove methods.

Yes, the constraints on when children can be added/removed aren't
always useful.  In fact they can seem nastily arbitrary, and some
of them need careful workarounds elsewhere in USB.  The current
usbcore code should behave well in all common cases outside of
suspend/resume.  (Yes, it's routine to unplug USB devices when
the system is suspended.  That's not wholly worked around yet.
By the time World Domination is achieved, it'll be fixed!)


> I can not tell you 
> what exactly gave me the impression that conversion is still in
> progress, probably the comments like this:
> 
>      /* FIXME should device_bind_driver() */
>          iface->driver = driver;
>          usb_set_intfdata(iface, priv);
>          return 0;
> 
> Now I see it was changed shortly after I looked there. And I see that
> my impression was wrong, it _is_ tightly integrated with the driver
> model now.

That was a FIXME that I added, and indeed it's now fixed.  The
patch had a dry run around 2.6.0 but had some issues, and they
took time to fix/test properly given more pressing issues.  The
drivers that used those APIs needed changes/retesting too.  :)


> >  If you think those changes can easily be
> > reversed, I suggest you think again ... they enabled a LOT of
> > likewise-overdue cleanups.
> 
> Note that I am arguing for keeping existing interface, not removing it.

Those particular interfaces still exist even after Greg's patches
for the class support... he didn't change the physical device tree.

I tend to think the class support really does need to be treated
differently from the driver model core.  It's all sort of separate
anyway, since class devices aren't "real" ones.  They don't show up
in the physical device tree, and I understand the main reason to use
them is to mask that physical view behind a more "logical" view of
the hardware.  Keeping those views separate makes sense to me,
although I've not paid close attention to class device support.

- Dave

> -- 
> Dmitry
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/