From nobody Mon Oct 6 03:13:59 2025 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FE95230BEE; Fri, 25 Jul 2025 22:08:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753481303; cv=none; b=kyIGXGY4FY/JtYvwscKE46OfaPE6lFWo5QDMCSxZHAtQqT4Y4CYUvDuS6cSK12ZU0IKEXaBf5hsd4rz3mKlifrrmcGmrFzAM5tQdEnvXE4fnhI+bJMFwBLpxSeRr+ieB71NKt992ir+ahbGf3omLdtBsMxWnT1ptTKcsyj3YkxE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753481303; c=relaxed/simple; bh=rUdEV/3BscSaZsG+qcyIHFIShaaDu5dTVcKo5heFN8k=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=S5LROV1kmxpRsm6aTBJXPpk134eyAR55oYqcVDHm28QMa8Nkh6btYbURYiFSMSj4S7kToZJi7Q6Pz3xeXbPR3y/3CAu/ZF+hdjS6nFbfEsvZ/H/59DWptY4DdtsMF9h+Bv9AZKggtW+5uuCHTjGSZ7mMZhbhInGT7FsfAV6m74E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=najVh8mJ; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="najVh8mJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1753481299; bh=rUdEV/3BscSaZsG+qcyIHFIShaaDu5dTVcKo5heFN8k=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=najVh8mJZUGSDn5MDFngu3Ez5JBluxoBb3ThJmejlCbMJHSo26Dv+fhaeye6ASZVz LWDOAbxhPcIXLUaPJEXkWSVN5dbqh9dyMGAgsrpEGpKv/dY2k2uFbYf/TDPiDpi7i7 FXwXmke9hj11hnHVWaSL/STKMX9gBliYSlAuSEykhxcU+AGiwTpyZMkPDqsfJh+GTb qKQ4xywm2LI12VXxPoLAwIyCiHzn+HhxFEIKa/FLMNWd/Pxvqb3MiMxtYhVHlIgcJG Ttjdv+QR4tlURlzOnWvjL+/PAwRP93vExi0LqsMAdpBAnnM+xDLHENITC4B5G4+R4S FweBT6C/BGKug== Received: from localhost (unknown [82.79.138.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with UTF8SMTPSA id 3F64617E0C8C; Sat, 26 Jul 2025 00:08:19 +0200 (CEST) From: Cristian Ciocaltea Date: Sat, 26 Jul 2025 01:08:03 +0300 Subject: [PATCH v2 01/18] usb: vhci-hcd: Prevent suspending virtually attached devices Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250726-vhci-hcd-suspend-fix-v2-1-189266dfdfaa@collabora.com> References: <20250726-vhci-hcd-suspend-fix-v2-0-189266dfdfaa@collabora.com> In-Reply-To: <20250726-vhci-hcd-suspend-fix-v2-0-189266dfdfaa@collabora.com> To: Valentina Manea , Shuah Khan , Hongren Zheng , Greg Kroah-Hartman , "Brian G. Merrell" Cc: kernel@collabora.com, Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org X-Mailer: b4 0.14.2 The VHCI platform driver aims to forbid entering system suspend when at least one of the virtual USB ports are bound to an active USB/IP connection. However, in some cases, the detection logic doesn't work reliably, i.e. when all devices attached to the virtual root hub have been already suspended, leading to a broken suspend state, with unrecoverable resume. Ensure the virtually attached devices do not enter suspend by setting the syscore PM flag. Note this is currently limited to the client side only, since the server side doesn't implement system suspend prevention. Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver") Signed-off-by: Cristian Ciocaltea --- drivers/usb/usbip/vhci_hcd.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c index e70fba9f55d6a0edf3c5fde56a614dd3799406a1..b4b0ed5d64966214636b1579684= 78600e2e4178a 100644 --- a/drivers/usb/usbip/vhci_hcd.c +++ b/drivers/usb/usbip/vhci_hcd.c @@ -765,6 +765,17 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struc= t urb *urb, gfp_t mem_flag ctrlreq->wValue, vdev->rhport); =20 vdev->udev =3D usb_get_dev(urb->dev); + /* + * FIXME: A similar operation has been done via + * USB_REQ_GET_DESCRIPTOR handler below, which is + * supposed to always precede USB_REQ_SET_ADDRESS. + * + * It's not entirely clear if operating on a different + * usb_device instance here is a real possibility, + * otherwise this call and vdev->udev assignment above + * should be dropped. + */ + dev_pm_syscore_device(&vdev->udev->dev, true); usb_put_dev(old); =20 spin_lock(&vdev->ud.lock); @@ -785,6 +796,17 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struc= t urb *urb, gfp_t mem_flag "Not yet?:Get_Descriptor to device 0 (get max pipe size)\n"); =20 vdev->udev =3D usb_get_dev(urb->dev); + /* + * Set syscore PM flag for the virtually attached + * devices to ensure they will not enter suspend on + * the client side. + * + * Note this doesn't have any impact on the physical + * devices attached to the host system on the server + * side, hence there is no need to undo the operation + * on disconnect. + */ + dev_pm_syscore_device(&vdev->udev->dev, true); usb_put_dev(old); goto out; =20 --=20 2.50.0