From patchwork Mon Nov 15 12:09:59 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Heikki Krogerus X-Patchwork-Id: 12619447 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49DBEC433F5 for ; Mon, 15 Nov 2021 12:10:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 336296322E for ; Mon, 15 Nov 2021 12:10:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230438AbhKOMNC (ORCPT ); Mon, 15 Nov 2021 07:13:02 -0500 Received: from mga09.intel.com ([134.134.136.24]:14027 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230436AbhKOMNA (ORCPT ); Mon, 15 Nov 2021 07:13:00 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10168"; a="233266319" X-IronPort-AV: E=Sophos;i="5.87,236,1631602800"; d="scan'208";a="233266319" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Nov 2021 04:10:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,236,1631602800"; d="scan'208";a="644818589" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 15 Nov 2021 04:10:01 -0800 From: Heikki Krogerus To: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , Bjorn Helgaas , Andy Shevchenko , Zhangfei Gao , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org Subject: [PATCH v4 1/3] PCI: Convert to device_create_managed_software_node() Date: Mon, 15 Nov 2021 15:09:59 +0300 Message-Id: <20211115121001.77041-2-heikki.krogerus@linux.intel.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20211115121001.77041-1-heikki.krogerus@linux.intel.com> References: <20211115121001.77041-1-heikki.krogerus@linux.intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org In quirk_huawei_pcie_sva(), device_add_properties() is used to inject additional device properties, but there is no device_remove_properties() call anywhere to remove those properties. The assumption is most likely that the device is never removed, and the properties therefore do not also never need to be removed. Even though it is unlikely that the device is ever removed in this case, it is safer to make sure that the properties are also removed if the device ever does get unregistered. To achieve this, instead of adding a separate quirk for the case of device removal where device_remove_properties() is called, using device_create_managed_software_node() instead of device_add_properties(). Both functions create a software node (a type of fwnode) that holds the device properties, which is then assigned to the device very much the same way. The difference between the two functions is, that device_create_managed_software_node() guarantees that the software node (together with the properties) is removed when the device is removed. The function device_add_property() does not guarantee that, so the properties added with it should always be removed with device_remove_properties(). Reviewed-by: Andy Shevchenko Acked-by: Zhangfei Gao Acked-by: Bjorn Helgaas Signed-off-by: Heikki Krogerus --- drivers/pci/quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 003950c738d26..b4cb658cce2b1 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1850,7 +1850,7 @@ static void quirk_huawei_pcie_sva(struct pci_dev *pdev) * can set it directly. */ if (!pdev->dev.of_node && - device_add_properties(&pdev->dev, properties)) + device_create_managed_software_node(&pdev->dev, properties, NULL)) pci_warn(pdev, "could not add stall property"); } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);