From owner-freebsd-current@FreeBSD.ORG Wed Jun 18 14:08:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0983472; Wed, 18 Jun 2014 14:08:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A81F2787; Wed, 18 Jun 2014 14:08:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 71080B924; Wed, 18 Jun 2014 10:08:14 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [patch] USB after second suspend/resume on ThinkPads. Date: Wed, 18 Jun 2014 09:47:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140616192155.GE13481@brick.home> In-Reply-To: <20140616192155.GE13481@brick.home> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201406180947.53141.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Jun 2014 10:08:14 -0400 (EDT) Cc: jhibbits@freebsd.org, Edward Tomasz =?utf-8?q?Napiera=C5=82a?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 14:08:15 -0000 On Monday, June 16, 2014 3:21:55 pm Edward Tomasz Napiera=C5=82a wrote: > Hi. Patch below should fix a problem where USB stops working after > _second_ suspend/resume, which happens on various ThinkPad models. > Please test, and report both success stories and failures. If nothing > comes up, I'll commit it in a week or so. Good find. Have you thought about a more generic fix for this wherein you= =20 track power resources and flip them on during resume in ACPI before doing DEVICE_RESUME() on the root bus? Alternatively, this probably meshes well with Justin's work on multipass=20 suspend/resume in that ACPI buses (e.g. acpi_pci and acpi0 itself) should b= e=20 turning on any power sources associated with an ACPI device during the=20 bus_resume_child() callback. =2D-=20 John Baldwin