linux-kernel - Re: [PATCH] dwc3: gadget: Defer starting the gadget device until gadget is power on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2016 17:59:24 +0800
From:	Baolin Wang <baolin.wang@...aro.org>
To:	Felipe Balbi <balbi@...nel.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Mark Brown <broonie@...nel.org>,
	USB <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dwc3: gadget: Defer starting the gadget device until
 gadget is power on

Hi Felipe,

On 17 May 2016 at 18:47, Baolin Wang <baolin.wang@...aro.org> wrote:
> On 17 May 2016 at 17:25, Felipe Balbi <balbi@...nel.org> wrote:
>>
>> Hi,
>>
>> Baolin Wang <baolin.wang@...aro.org> writes:
>>>>>>> Make sense.
>>>>>>
>>>>>> cool, if you wanna work on it, let me know and I can give some details
>>>>>> of what I have in mind.
>>>>>
>>>>> Could you explain details to me, and I wanna continue to optimize the
>>>>> power management things. Thanks.
>>>>
>>>> I have it half-way done. Have a look at my dwc3-fix-suspend branch on
>>>> k.org. I haven't sent because I'm not getting a PME event. Can you test
>>>> on your end and let me know what happens?

I applied some patches (showing below) about suspend/resume at your
dwc3-fix-suspend branch with my glue layer runtime_* callbacks on my
testing platform.
usb: dwc3: implement runtime PM
usb: dwc3: core: simplify suspend/resume operations
usb: dwc3: core: re-factor init and exit paths
usb: dwc3: core: get rid of DWC3_PM_OPS macro
usb: dwc3: gadget: fix gadget suspend/resume
usb: dwc3: gadget: re-factor ->udc_start and ->udc_stop

Then I tested the cable connect/disconnect action to see the dwc core
resume/suspend. It looks work well on my platform, except that I did
some extra 2 modifications like below:
(1)
@@ -1485,16 +1490,11 @@ static int dwc3_gadget_run_stop(struct dwc3
*dwc, int is_on, int suspend)
 {
        u32                     reg;
        u32                     timeout = 500, i;

+       if (pm_runtime_suspended(dwc->dev))
+               return 0;

(2)
@@ -1748,15 +1754,25 @@ static int dwc3_gadget_start(struct usb_gadget *g,
         * even though host mode might be active. Don't actually perform
         * device-specific initialization until device mode is activated.
         */

+       if (pm_runtime_suspended(dwc->dev)) {
+               spin_unlock_irqrestore(&dwc->lock, flags);
+               return 0;
+       }

+       ret = __dwc3_gadget_start(dwc);
+       if (ret)
+               goto err1;

So I think the dwc3 core can enter suspend mode before gadget function
is ready to call the 'usb_gadget_udc_start()' and
'usb_udc_connect_control()', then if the dwc3 core has entered
suspended mode, we need to return success when starting the gadget,
and leave the gadget starting action from gadget resume. What do you
think about that? Thanks.

>>>
>>> OK. I try to test on my platform to see what will happen.
>>
>> great, thanks. You might need to patch your glue layer with proper
>> runtime_* callbacks, btw.
>
> Make sense. Thanks.
>
>>
>> --
>> balbi
>
>
>
> --
> Baolin.wang
> Best Regards



-- 
Baolin.wang
Best Regards