linux-kernel - Re: [PATCH] usb: chipidea: Fix missing resume call after suspend

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:   Mon, 24 Apr 2017 15:25:21 +0200 (CEST)
From:   Bernhard Walle <bernhard@...lle.de>
To:     Peter Chen <peter.chen@....com>
Cc:     linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH] usb: chipidea: Fix missing resume call after suspend

Hi,

> Peter Chen <peter.chen@....com> hat am 24. April 2017 um 05:51 geschrieben:
> > 
> The current code logic is:
> - When the resume is received from host, the ci->dirver->resume is
> called, and suspended is cleared.
> - When the reset is received from host, the isr_reset_handler is called,
> and suspended is cleared by _gadget_stop_activity. Since reset is
> called, so ci->driver->resume doesn't need to be called.

My problem is that dump_stack() doesn't show the complete stackframe. What I see from debug messages is that when I plug a cable (after the host has been suspended) then _gadget_stop_activity is executed before udc_irq. 

My first attempt was to save ci->suspended at the beginning of udc_irq (i.e. before isr_reset_handler is called), but that doesn't work. Even in the beginning of udc_irq ci->suspended is 0. So isr_reset_handler is called before.

The result is that when I unplug a cable and attach it again, driver->suspended has been called but driver->resume doesn't get called.

> There is a patch to fix clear suspended even the ci->driver->resume is
> NULL at v4.12-rc1.
> 
>       usb: chipidea: udc: update gadget state after bus resume

Thanks for the hint. That makes the second part of my patch irrelevant, but the first part (removing the ci->suspended = 0) is needed in order to make my setup working.

Any idea to find the cause why reset is called before resume? According to your explanation, that shouldn't be the case?

Regards,
Bernhard