On 05/14/2018 11:05 AM, Maxime Ripard wrote: > On Sat, May 12, 2018 at 02:12:43PM +0200, Marek Vasut wrote: >>>>>>> Since the first post of these patches, you've asked to rework in a >>>>>>> significant manner the driver already, including doing a new PHY >>>>>>> driver to use the device model, and making other substantial changes >>>>>>> to it. >>>>>> >>>>>> Well yes, because it was crap at the beginning and I don't want to see >>>>>> the crap accumulating. It has become much better since, as you can see I >>>>>> only had a few minor comments. >>>>> >>>>> And that's totally your role, but at the same time, the point of this >>>>> series is not to fix the whole world, but rather add support for one >>>>> particular SoC that is using pretty much the same design than any of >>>>> our other SoCs' USB phy before. And here we are, 35 patches and >>>>> counting. >>>> >>>> If I said "yes" to every single patch adding just a minor additional bit >>>> of crap to the codebase, we'd be in the state in which we were in 2012, >>>> sinking under the boatload of ifdeffery and ad-hoc solutions. So I think >>>> some push is needed to avoid that situation. >>> >>> I don't have any issue with the end goal, and your willingness to have >>> the code ported over to new APIs. But if from one day to another every >>> maintainer goes like this, this will simply not fly. This is not just >>> about having just a simple clock driver, but also a pinctrl one, and >>> converting all the consumer drivers to the device model, oh, and btw, >>> the DM doesn't fit in the SPL anymore, so we would probably need to do >>> an SPL driver as well. Probably with some painful Kconfig conversions >>> all over the tree even. >> >> You are massively exaggerating right there. I recently did such a >> conversion for a platform and it didn't take nearly as much effort as >> you describe and/or it could be well segmented. > > rmobile? The scale isn't quite the same. It looks like there's 4 > similar SoCs, with a dozen of boards supported. We have a dozen of > SoCs supported, and around 120-130 boards. The clock tree looks much > simpler too, and it seems like it has less drivers.
Aha :) > And I don't really know what the constraints are on the SPL side, but > it's really tight on our end. So maybe I'm exagerating, but you're > definitely understating it too. You can fit into 16k , can you not ? >>> This is no longer a simple request, but some huge spaghetti changes >>> that need to be done, mostly by volunteers. >> >> I am not sure this "volunteers" argument really works in this >> discussion, since this looks like a commercial contribution to me. > > I have no idea to be honest. The maintainance however is volunteering > on my side, and I'm getting a bit tired to see that every one has an > agenda without any consideration about who has the time and resources > to actually do it. My agenda is to make sure upstream doesn't become a swamp. >> But if you want to discuss volunteering, did you ever consider that I >> also do the USB maintaining in my free time and the bulk of >> communication is random people demanding random stuff ? I also don't see >> people coming up saying "oh, hey, I'll spend some of my own free time to >> help out maintaining this piece of code". It tends to make people >> stressed and burnt out ... > > I definitely understand and appreciate that, trust me. But the point > here is that you were asking too much I was asking a question, is that too much nowadays ? I thought we cleared that point in this thread before. >, so I guess my point is that you > should spend *less* time reviewing stuff, which tends to make people > less stressed :) Not sure I understand this remark. I guess it doesn't fit my agenda. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
