Re: [PATCH v6 1/4] mfd: add support for Diolan DLN-2 devices

[Johan Hovold]

On Mon, Oct 06, 2014 at 03:17:22PM +0300, Octavian Purdila wrote:
> On Fri, Oct 3, 2014 at 8:12 PM, Johan Hovold <johan@xxxxxxxxxx> wrote:
> >
> > On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
> > > This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
> > > Master Adapter DLN-2. Details about the device can be found here:
> > >
> 
> <snip>
> 
> > > +
> > > +             ret = dln2_submit_urb(dln2, dln2->rx_urb[i], GFP_KERNEL);
> > > +             if (ret < 0)
> > > +                     return ret;
> >
> > Is it really worth having this helper only to save a couple of lines on
> > a dev_err? If you do all resubmissions on completion inline in the
> > handler, you only have three places where usb_submit_urb is called.
> >
> 
> I moved the completion in the handler as you suggested. I have kept
> the helper, would you prefer to remove it?

Moved the "completion"? I was suggesting that the URB resubmission
should be done inline the URB completion handler.

[ "Completion" may be a little ambiguous. The URB callback is called an
URB completion handler. Not be confused with the completion structures
you use to wait for responses. ]

It's fine to keep the helper as long as it's clear that the urb has been
"cached" and should not be resubmitted (inline) in the completion
handler in that case.
 
> <snip>
> 
> > > +     id = dln2->usb_dev->bus->busnum << 8 | dln2->usb_dev->devnum;
> >
> > After giving this some more thought, I think you should just
> > use PLATFORM_DEVID_AUTO as id. I have submitted a series to fix the
> > other USB MFD drivers and add a convenience helper to register
> > hotpluggable MFDs here:
> >
> 
> OK, I will use PLATFORM_DEVID_AUTO for now. If your series merges
> first and I have to resubmit mine, I will switch to using
> mfd_add_hotplug_devices.

Lee merged the helper function earlier today.

Johan
--
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/