On Mon, Jan 25, 2016 at 12:00:05AM +0100, Marek Vasut wrote: > On Sunday, January 24, 2016 at 11:21:51 PM, Tom Rini wrote: > > On Sun, Jan 24, 2016 at 11:07:30PM +0100, Marek Vasut wrote: > > > On Sunday, January 24, 2016 at 08:33:57 PM, Tom Rini wrote: > > > > On Sun, Jan 24, 2016 at 06:22:10PM +0100, Marek Vasut wrote: > > > > > On Sunday, January 24, 2016 at 06:18:23 PM, Stefano Babic wrote: > > > > > > On 24/01/2016 18:11, Marek Vasut wrote: > > > > > > > It is not clear when the wait_for_bit() will be applied, I am > > > > > > > certain there will be another round for so. I do not want to > > > > > > > wait for it and I don't see a reason why those patches should > > > > > > > block this if the conversion can be done afterward. > > > > > > > > > > > > Just wait for a while - if it takes too much, I reconsider to apply > > > > > > this first and factorize wait_for_bit() in a follow-up patch. > > > > > > > > > > I have waited for over a month and I fail to see a reason why patches > > > > > which will be applied at uncertain point in the future shall block > > > > > this patchset. The wait_for_bit() can be removed by a subsequent > > > > > patch, it is already pulled out explicitly in the code, so I don't > > > > > see a problem with applying this. > > > > > > > > Did I miss something or isn't v4 of wait_for_bit good to go? > > > > > > I don't really know if it's good to go, but this patch does not depend on > > > it in any way. A subsequent patch can drop the wait_for_bit() from here, > > > it's the same as the wait_for_bit() in dwc2 and other wait_for_bit() > > > anywhere else, but I don't see a reason why this patch should not be > > > applied now. > > > > > > If I follow the logic in this thread, it would also be possible to say > > > that this patch should wait until Eric submits the MX6S DDR support for > > > example. We could indefinitelly wait for new and new stuff which might > > > possibly block this. > > > > Why don't you ack/test/review the wait_for_bit series and post a > > follow-up to this one that uses the common function, which can be > > squashed into the original and then this gets picked up? > > Why ? I can send subsequent patch which removes the duplicate wait_for_bit() > from this code once the wait_for_bit series is applied. I don't see a problem > with that and the wait_for_bit() being so explicitly pulled out from the code > is done with that in mind. But that does not block this patch from being > applied > now. Does it?
If I tell you I'm probably going to have the wait_for_bit stuff applied before the next imx PR is ready... ? -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
