linux-kernel - Re: [linux-usb-devel] USB deadlock after resume

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]

Message-Id: <200711212152.16066.laurent.pinchart@skynet.be>
Date:	Wed, 21 Nov 2007 21:52:15 +0100
From:	Laurent Pinchart <laurent.pinchart@...net.be>
To:	linux-usb-devel@...ts.sourceforge.net
Cc:	Oliver Neukum <oliver@...kum.org>,
	Felipe Balbi <me@...ipebalbi.com>,
	Laurent Pinchart <laurentp@...-semaphore.com>,
	Mark Lord <lkml@....ca>,
	Markus Rechberger <mrechberger@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-usb-devel] USB deadlock after resume

On Wednesday 21 November 2007, Oliver Neukum wrote:
> Am Mittwoch 21 November 2007 schrieb Felipe Balbi:
> > > Do you know any good way for performing a softreset within the driver?
> > > The video application should get a continuous datastream after
> > > resuming the notebook, so the driver shouldn't be unloaded.
> > > The driver also keeps a list of previous camera settings which should
> > > be set up again after resuming. Stopping the video application and
> > > reattaching the device using ACPI (this board supports reconnecting
> > > the device using ACPI) should be avoided.
> >
> > When you suspend, you cut off vbus (afaik, correct me if I'm wrong),
> > which means your device will get disconnected. One way to avoid this is
> > enabling CONFIG_USB_PERSIST and trying with that on.
>
> Suspend may or may not cut off power.

I've always been confused by this.

If I'm not mistaken, there are three kind of suspend modes: autosuspend, 
suspend to RAM and suspend to disk. In the first case I expect the USB hub 
(either root hub or external hub) to make the bus idle but not power it down. 
In the last case I suspect the USB bus to be powered down.

What controls the USB bus power on suspended ports ? Is it handled by the 
system (BIOS, ...) ? Is it allowed to power down the ports or keep them 
powered as it chooses ? What are the rules set in stone ?

> If it does cut off power, resume() will never be called, instead either
> disconnect() or reset_resume(). 

What is reset_resume() for ? Which one will be called on resume after a bus 
power down ?

Best regards,

Laurent Pinchart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/