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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
