patch
Roman Kagan
rkagan at mail.ru
Tue Feb 1 01:38:43 EST 2005
Hi Duncan,
On Mon, Jan 31, 2005 at 09:41:32PM +0100, Duncan Sands wrote:
> > On Fri, Jan 28, 2005 at 03:33:26PM +0100, Duncan Sands wrote:
> > > > + down(&usbatm_driver_list_sem);
> > > > + list_for_each_entry(driver, &usbatm_driver_list, driver_list)
> > > > + if (usb_match_id(intf, driver->id_table))
> > > > + break;
> > > > + up(&usbatm_driver_list_sem);
> > > > +
> > > > if (!driver) {
> > >
> > > if there's no matching entry, driver is not NULL, it is (more or less)
> > > the list head... I'll take care of it.
> >
> > The matching entry is there, otherwise the USB core wouldn't call
> > driver's probe, and it holds a reference to the driver's .owner so no
> > deregister can happen here.
>
> You are assuming that the usbatm_driver has the same list of ids as the usb_driver.
Yes, at the time I wrote that I hadn't yet caught up with the CVS so I
was talking of how it was done in the patch I sent. There usb_driver's
ids came from usbatm_driver's, and this condition was ensured by
usbatm_(de)register.
> > Umm, probably except for a small window between list manipulation and
> > usb_(de)register in usbatm_(de)register. It can be fixed by moving the
> > release of the semaphore after the usb_(de)register.
>
> How do you mean? If you first register the usbatm driver, and only then the usb
> driver there should be no problem (and that is how it should be done - I should
> document this).
Right, I just looked at my usbatm_deregister and didn't realize that
moving usb_deregister before deleting the usbatm_driver from the list
solves the problem.
Cheers,
Roman.
More information about the Usbatm
mailing list