[U-Boot] [PATCH v3 06/13] USB: gadget: added a saner gadget downloader registration API

[Marek Vasut]

On Tuesday, April 15, 2014 at 01:04:57 PM, Mateusz Zalega wrote:
> On 04/11/14 14:02, Marek Vasut wrote:
> >> Existing code relied on boolean value returned from
> >> usb_cable_connected(), but there was no way to signal that it's
> >> impossible to tell whether cable is connected or not. If you prefer an
> >> enum with USBCNT_DONTKNOW as a return value, make a decision.
> > 
> > Did I say anything about "USBCNT_DONTKNOW" above please?
> > 
> > Sorry, I also lost context of this thread as it was dead for more than a
> > month.
> 
> As I described on the IRC. We've got to have a way to signal U-Boot code
> that our hardware isn't capable of knowing if cable is connected, thus
> #ifdef all related code or introduce 3-valued enum.

OK, so I guess a weak default implementation returning -ENOTSUP would work.

> >>> The whole patchset is a mix of completely unrelated things which should
> >>> go through different trees. Can the patchset be reordered/split in some
> >>> reasonable chunks ? There are fixes which should go in immediatelly and
> >>> then features which should go in for -next.
> >> 
> >> Not exactly unrelated, most of it should be applied in this particular
> >> order. It would be less chaotic had it been accepted in one piece.
> > 
> > Please elaborate why can the fixes not go first and features second.
> > Thank you.
> 
> It's because of silly relationships between some of these patches. ie.
> am335x SPL build process just blew (too little ROM), leaving its
> codebase in unbisectable state, after I added some more code to DFU
> implementation. am335x's SPL had to be disabled first, and I consider it
> a change on the feature list.
> 
> I've reordered the fixes I could, but I guess it doesn't matter anymore,
> now that -next is out.
> 
> Please ack applicable USB patches on the next patchset version or
> propose a different solution.

Will check.

Best regards,
Marek Vasut