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