From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED5E6386571 for ; Sun, 11 Oct 2026 21:05:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791752711; cv=none; b=nI3LN3RwGseToko2i55Csiex5FqwXY3oNpqx8uQNQhW+QY3ZJrVcAPfG3T8QscjbdiyNv7JDViEmYd8tU2ouJ3URhfDM7HM9VbngSlML9nYxYnSOf1y/8ObueZUkWW/TBYL4s+nP6uW76ClFDogv3OAXfDz4FZM/PghXubeZcU0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791752711; c=relaxed/simple; bh=XIV3Bw+meEIbEvfPttC3rmUTSBP3umIE78D+SF0fiHY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aoBbnV9Qx98D8bVHmBKqgXPTWZpIvGFemBmMCtb6QJiXIHzWBeOkbrxuOeM86p4JT3leHXsDKOIt1gBSckoW4HeYDoMjP4zL0xd/TmUj7q3PpMlY24VVmb39ycZ/keIPeZ0AuC+hIEjthJ8wHfSNxtFaT3ca9AwkZVMb3e+tCSQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iI1BieKf; arc=none smtp.client-ip=209.85.217.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iI1BieKf" Received: by mail-vs1-f50.google.com with SMTP id ada2fe7eead31-7c52caa3045so330051137.3 for ; Sun, 11 Oct 2026 14:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791752709; x=1792357509; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MZ1qIeqHrec/OIdwqoJkpql1iC1IeshUMzkQNORQJ24=; b=iI1BieKf40qd4gbYQ3F/YHbZZqUJUgjb/rXm3R4l96I3NDtuSO66RoFEh32lqKd1US JfBlLzZ3wTCljn54ZwhDrcHF+u9f2lnIkIQKXFJilrPc7jKbB2Dj5nJ/khyAuY2wbU81 SSq2Sb7p8Vrfr/Z+G6tz/98ahsm4aLkhnj1zpbyLaU8nOyi0ZDwzD4ieYo8RgKG+bE+F NogMQw+n7OrRVypTTn0Uqih73w5NeJ0CNaMoorowtLdWH+uFtlaORL96UmYKlaH0JUcT s4qfhpDjeWBHg57vsIz/MfScswfbgRffOcDRQ2gh63ZnUdvOe5GNlTT8nF+qlFrtnJZe 7z+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791752709; x=1792357509; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=MZ1qIeqHrec/OIdwqoJkpql1iC1IeshUMzkQNORQJ24=; b=BxdN4jJgpjcT6er7YPwl4TINf5oHb8FyUyggOm0HAGd+M7hMzHHJs91w7ggpEJNPxa hRq70tnr67BvuHahP0k7Q3Hr3aHFbgVJ1Q6hr7AsYhClDjYEPrEWsZWKLYaHKnJuNVzy pAJUoYJJjMsFM3JHoauaMWjfMbWLKiYMRgKdhhXDpxPwhag4DWiKREJoHR9O1B7qmz75 Urtn2o25STurey9x43wnWtHa28DiYiMtPn7PUzkX/UlLk8hxYR7l5wGmTOZXZMrh3je2 77M/bioJ8BGsAG2mXKQHpgUZwzLGB46woec4uRTDb/bSITVHBQ1pKnewydSBAPMaljLV WqcQ== X-Forwarded-Encrypted: i=1; AKwUvBxvG9xlC+xpZ6niiWUlvsIS8yULlZHR35PeBXDncG+PpkCzSPd2Jgt3jQH18So6w8L2P9lQLGFslxs=@vger.kernel.org X-Gm-Message-State: AFq9FYKYk1Ii/58mAuawsjYOYtiatFtqH+X2rHfXBggcJNoj6Fx9az3d Q7XDoRx4RRkUNf7zbUEdPBNjRSQOr9+G/dk+wXIuX2F0Xhc01YM5cNu1 X-Gm-Gg: AYBFou1wAVUeSjxnaZPeBbGZPQ7ASN1OE6rXeiIUM4v0fQh/kXe32pZz6GxaTSqGbCT wUY8/Qc3adA2CcktISLRpB50I8dcQKA6UOoArNpFCPaw0LM5j4qBmNxPIfVsQ/HuDLSq1uLyqfN yNv9BWut152ns8RGcmuGoJiYNbFuJHz0Z9pB9hDMklQ5nr6+RGnEGMTMo7rmenRBhHa5owE/ryw zwnm6fHLIWrRn87SDrCKpm46Iip6kCzLa8aP1wMw/V4YntP5IuySiFHf9kjAQNZaYuAvvsHA29m K/HbwJs/VijqwrcerZFZr4TFvyCVW+AhPZNWv0w6M5DK7SRWkCNifCgVSi6VMCBhDft6nbki7bh ZIRFMHUP1KKt19a6QS3Us6hn9QgeeHRAEHgMIKO5V4W40WB4DQB1jHqfWdYmcjpPW8OhjajKe2X utKlqlttSTlSeRJBei2UKVtf4I0gfNGq0+e/4KZwRBCsobEcMGU0AuLkWeggjtZgi/8i4RqKmm+ JEwWKVy X-Received: by 2002:a05:6102:6ce:b0:7c8:268:ecd7 with SMTP id ada2fe7eead31-7cb373a73f3mr1672500137.23.1791752708660; Sun, 11 Oct 2026 14:05:08 -0700 (PDT) Received: from maclinux ([2803:c600:9110:8ba5:1c75:eeaa:b22f:20dc]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-7cb35391722sm5636766137.4.2026.10.11.14.05.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Oct 2026 14:05:08 -0700 (PDT) From: =?UTF-8?q?Francisco=20Beltr=C3=A1n=20Millal=C3=A9n?= To: helgaas@kernel.org Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, stern@rowland.harvard.edu, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, lukas@wunner.de, alifm@linux.ibm.com, andreas.noever@gmail.com, westeri@kernel.org, YehezkelShB@gmail.com Subject: Re: [PATCH v2 2/3] PCI/PM: Do not save the config space of an inaccessible device Date: Sun, 11 Oct 2026 18:04:51 -0300 Message-ID: <20261011210451.12129-1-fbeltranmillalen@gmail.com> X-Mailer: git-send-email 2.56.0 In-Reply-To: <7ed02ff5-d7f8-42e4-bca9-b3d3ce7b6795@linux.ibm.com> References: <7ed02ff5-d7f8-42e4-bca9-b3d3ce7b6795@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Bjorn, Thanks, Farhan, for the pointer to the earlier discussion. I hadn't seen it. On Fri, Oct 09, 2026 at 10:08:15AM -0700, Farhan Ali wrote: > When I had initially looked into this, I had proposed adding the > accessibility check in pci_save_state() as well [1]. Though Lukas had > some valid concerns around the additional overhead from adding it in > pci_save_state(). But maybe its worth re-visiting again? After reading that thread I went through the callers of pci_save_state(). When a device is already inaccessible while its driver's suspend callback runs, for example because it dropped off the bus and hasn't been removed yet, returning -EIO from pci_save_state() changes what some drivers do: - Some return the error from their suspend callback, so system suspend is aborted: stmmac_pci_plat_suspend() (used by stmmac_pci, dwmac-loongson and dwmac-motorcomm), intel_eth_pci_suspend(), atl1e_suspend(), atl2_suspend() and amd_mp2_pci_suspend(). Today pci_save_state() returns 0 in that case, and these drivers go on. - Many more ignore the return value and then put the device into D3hot, for example ata_pci_device_do_suspend(), which most libata PCI drivers use. On an inaccessible device that marks it D3cold, and since state_saved is now false, pci_legacy_suspend() or pci_pm_suspend() warns once that the state was not saved. This is the same warning that patch 1 avoids for the USB HCD in suspend_noirq. I found all of this by reading the code; I can't test these drivers. I think this is what Lukas meant about callers that don't need the check. The underlying problem is that pci_save_state() doesn't check that the device answered: for an inaccessible device it fills the saved header with all ones, marks the state saved and returns 0, and pci_restore_state() later writes those values back. What I have prepared for v3 fixes it in pci_save_state() itself, with the changes you suggested: it checks once that the device is accessible and returns -EIO if it isn't, and pci_dev_save_and_disable() uses the return value. v2 2/3 returns -EIO in the same way. The drivers above are the side effect of that: they now see a failure where they never saw one before. I found this only recently, so I'd rather not send v3, and I'd ask you not to apply v2 2/3 as it is, until you've had a chance to look at this. Patch 3 doesn't depend on it. How would you like these drivers to be handled? Thanks again, Francisco [1] https://lore.kernel.org/all/aOQX6ZTMvekd6gWy@wunner.de/