[U-Boot] [PATCH v7 06/35] musb: sunxi: Add OTG device clkgate and reset for H3/H5

[Marek Vasut]

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