[U-Boot] [PATCH] usb: sunxi: ohci: make ohci_t the first member in private data

[Jagan Teki]

On Mon, Jun 18, 2018 at 12:49 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
> On 06/18/2018 08:15 AM, Jagan Teki wrote:
>> On Mon, Jun 18, 2018 at 6:44 AM, Marek Vasut <marex at denx.de> wrote:
>>> On 06/17/2018 06:13 PM, Vasily Khoruzhick wrote:
>>>> ohci-hcd casts priv_data pointer to (ohci_t *), thus it must be
>>>> the first member in private data struct.
>>>>
>>>> Fixes 831cc98b1 ("usb: sunxi: Simplify ccm reg base code")
>>>>
>>>> Signed-off-by: Vasily Khoruzhick <anarsoul at gmail.com>
>>>
>>> Sigh, I really wonder how (or if at all!) the original series was
>>> tested. And then I get flak for scrutinizing patches, right ...
>>
>> APAIK, I did basic sanity with possible tests.
>
> >From what I see in the other thread, the USB never worked with the
> series. If the controller returns 0s as EHCI version, something is
> obviously broken and I don't even understand how that could be an
> acceptable positive test result. The USB HCD version register can NOT
> EVER contain zeroes as per the specification. I am really unhappy here.

This is untrue, the controller returns 0's only when single node
enabled not with both ehci0 and echi1 atleast on BPI-M64. and we do
enable both controller on dts even with other boards too. having
single node enablement is not a proper test or not with my dts
atleast.

>
>> But one thing for sure is, you should have to wait for sometime to
>> apply this patch. Applying fast (that to during weekend) making
>> reviewers or maintainers not giving enough room to work.
>
> Putting my USB maintainer hat on, I am quite sure I can evaluate such a
> simple yet critical bugfix, if only by spending those two minutes to
> look at the code in ohci_register() .
>
> And since you complain about the rate patches get in again, let me
> remind you how much flak I got for taking my time reviewing your series
> and not applying it right away. Now I am getting flak for applying stuff
> too quickly instead. You know, maybe if you spend more time testing the
> patches you send thoroughly instead of lecturing people on the MLs, we
> wouldn't be having this conversation.

Again we do testing based on our usage scenario's and we're done with
that and good to go. And giving room for 3 releases time and sending
till v10 expecting other boards or usage scenario's can be verified by
other people in the ML. for your words on 'lecturing people on the
MLs' we are here to work like other developers in ML not to give
lecture like in training organizations, better be clear before framing
your words.

Jagan.

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.