On Tue, Oct 07, 2014 at 09:01:27PM +0300, Octavian Purdila wrote: > On Tue, Oct 7, 2014 at 8:10 PM, Johan Hovold <johan@xxxxxxxxxx> wrote: > > 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. ] > > > > Sorry, I meant to say resubmission instead of completion. > > > 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. > > Not sure I follow you here. I kept the helper and I call it from the > completion handler, from free_rx_slot and from dln2_setup_rx_ubs. Ah sorry, I was referring to your other helper dln2_rx_transfer(). I still think you should do away with the dln2_submit_urb() helper as it needlessly hides what's on going without any real gain. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
