On Tue, Oct 24, 2023 at 11:18:26AM +0200, Johan Hovold wrote: > On Tue, Oct 24, 2023 at 02:23:57PM +0530, Krishna Kurapati PSSNV wrote: > > On 10/24/2023 12:26 PM, Johan Hovold wrote: > > > > No, you clearly did not understand [1] at all. And stop trying to game > > > the upstreaming process. Bindings and driver patches go together. The > > > devicetree changes can be sent separately in case of USB but only > > > *after* the first set has been merged. > > > > > > If the code had been in good shape from the start it would have been > > > merged by now. Just learn from your mistakes and next time things will > > > be smoother. > > > > I agree that bindings should go first. My point is core bindings are > > already approved and merged and just wanted to check if core driver > > changes can be merged without glue blocking them. Core driver changes > > have nothing to do with interrupt handling in glue. If we get the core > > changes merged separately after fixing the nits mentioned, we can take > > up this interrupt handling in glue in parallel. I am just trying to see > > if we can start merging independent portions of code. I agree that my > > glue driver changes are still not upto mark. But that has nothing to do > > with core driver changes. > > Again, no. The dwc3 glue and core bits are not independent, and ideally > the bindings should not have been merged either before having the > implementation in a decent shape either (e.g. as the messy > implementation suggested that the bindings were incomplete). > > You're again trying to sneak in an incomplete implementation. Qualcomm > has a terrible track record of doing just that and leaving others with > the task to clean up their mess. > > This should go in as one series, when it's ready, and not before. > > And we may even consider reverting the updated bindings as it appears > they are still not correct. If you can tell me what the git ids of them are, I'll be glad to do so right now, sorry for taking them "early". thanks, greg k-h
