On Tue, May 05, 2015 at 06:36:00PM -0400, Benjamin Romer wrote:
> +/** This is called automatically upon adding a visor_device (device_add), or
> + *  adding a visor_driver (visorbus_register_visor_driver), but only after
> + *  visorbus_match has returned 1 to indicate a successful match between
> + *  driver and device.
> + */
> +static int
> +visordriver_probe_device(struct device *xdev)
> +{
> +     int rc;
> +     struct visor_driver *drv;
> +     struct visor_device *dev;
> +
> +     drv = to_visor_driver(xdev->driver);
> +     dev = to_visor_device(xdev);
> +     down(&dev->visordriver_callback_lock);
> +     dev->being_removed = FALSE;
> +     /*
> +      * ensure that the dev->being_removed flag is cleared before
> +      * we start the probe
> +      */
> +     wmb();
> +     get_device(&dev->device);
> +     if (!drv->probe) {
> +             up(&dev->visordriver_callback_lock);
> +             rc = -1;
> +             goto away;
> +     }
> +     rc = drv->probe(dev);
> +     if (rc < 0)
> +             goto away;
> +
> +     fix_vbus_dev_info(dev);
> +     up(&dev->visordriver_callback_lock);
> +     rc = 0;
> +away:
> +     if (rc != 0)
> +             put_device(&dev->device);
> +     /*  We could get here more than once if the child driver module is
> +      *  unloaded and re-loaded while devices are present.  That's why we
> +      *  need a flag to be sure that we only respond to the device_create
> +      *  once.  We cannot respond to the device_create prior to here,
> +      *  because until we call drv->probe() above, the channel has not been
> +      *  initialized.
> +      */
> +     if (!dev->responded_to_device_create) {
> +             dev->responded_to_device_create = TRUE;
> +             if (chipset_responders.device_create)
> +                     (*chipset_responders.device_create)(dev->chipset_bus_no,
> +                                                         dev->chipset_dev_no,
> +                                                         rc);
> +     }
> +     return rc;
> +}

The error handling in this function looks kind of weird.  Also if
drv->probe() fails then we need to unlock.  One err bug.

regards,
dan carpenter

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to