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. >>> 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. Regards, -- Mateusz Zalega Samsung R&D Institute Poland _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
