From: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
To: Jack Mitchell <ml@embed.me.uk>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>
Cc: Phillip Karls <prkarls@gmail.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: RK3288 dwc2 USB OTG + macOS
Date: Thu, 28 Nov 2019 11:29:03 +0000 [thread overview]
Message-ID: <3e45e70d-1e59-373d-76b7-b6a8a6320514@synopsys.com> (raw)
In-Reply-To: <bcda1da2-fcdf-2c5b-d07b-5cf397571eb7@embed.me.uk>
Hi Jack,
On 8/30/2019 2:49 PM, Jack Mitchell wrote:
> On 22/08/2019 17:06, Jack Mitchell wrote:
>> I'm having issues on a Firefly rk3288 board when trying to use USB
>> gadget ethernet on macOS. The dr_mode is set to "otg" and it works fine
>> with my Linux desktop.
>>
>> If I set the dr_mode to "peripheral" macOS will work, but still takes
>> around 10 seconds to enumerate the device which makes me think it's only
>> just working. However, I need the port to be in "otg" mode as it will
>> switch between peripheral/host use cases.
>>
>> I've attached a log from the dwc2 driver from mainline Linux 5.2 when
>> being plugged into the macOS device for 30 seconds, then removed. The
>> mac in this case is a 2013 macbook pro. Any pointers in the right
>> direction would be greatly appreciated.
>>
>> Regards,
>> Jack.
>>
Sorry, for late response.
Could you please apply recently submitted patch "[PATCH] usb: dwc2: Fix
SET/CLEAR_FEATURE and GET_STATUS flows" and test again.
>
> I've been poking about with this some more and I've managed to bisect
> the issue down to the following commit
>
> 729cac693eecfebdb9e152eaddddd358ae2decb7 usb: dwc2: Change ISOC DDMA flow
>
> If I build before this commit everything works fine with a g_ether
> gadget device on mac. Unfortunately it's a rather large change which I
> can't just revert in master as it's got multiple dependant commits
> later. So, any advice on what could be causing this or how to help debug
> it would be much appreciated, as at the moment I've just forward ported
> the working 4.16 version of the driver over the 5.3-rc6 broken driver
> which isn't very sustainable in the long run.
I don't think that issue root cause coming from mentioned by you above
patch. Based on log you provided, SET_FEATURE control transfer not
completed by gadget - ZLP on status stage not sent to host.
>
> Regards,
> Jack.
>
next prev parent reply other threads:[~2019-11-28 11:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 16:06 RK3288 dwc2 USB OTG + macOS Jack Mitchell
2019-08-30 10:49 ` Jack Mitchell
2019-11-28 11:29 ` Minas Harutyunyan [this message]
[not found] ` <8a2341be-7b34-54d1-83aa-d8961d2c1618@embed.me.uk>
2019-12-13 11:55 ` Minas Harutyunyan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e45e70d-1e59-373d-76b7-b6a8a6320514@synopsys.com \
--to=minas.harutyunyan@synopsys.com \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=ml@embed.me.uk \
--cc=prkarls@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).