Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp5448402imm; Tue, 16 Oct 2018 10:22:16 -0700 (PDT) X-Google-Smtp-Source: ACcGV635sGNn6etKsi6zU4Q+TDQ+S/pB8baGWDSHF5CKD1LBao+PyZBIRQzjT9YZjH2Mly4ZhKOb X-Received: by 2002:a17:902:b182:: with SMTP id s2-v6mr22211965plr.84.1539710535984; Tue, 16 Oct 2018 10:22:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539710535; cv=none; d=google.com; s=arc-20160816; b=mOWzJZQWePsWOIs/FT4kk1anPavc/H+DMZK0zNB8fQM/cCIMxLUf/KfcczQ22RZnyM 22ElPXGrobgl8awbJhk4jXWv/iojYD0s23R20rbg1FWOnKYmmPwDHxR/x+5ZgFG9fP2v tRUi0LjWM1tjnwlv5b/+EgkVfkUoYnT9W+U69XckWMp9FwoXqQS/Owse3IH8YNyNsNxd xXghUN99A6Tm0mLJ9GU8fM+aS00KSSlV4IbBShnx5v+cIxAOBB1HqgCFHXAXMfrjE4eB kYNMFBvJixHynACXZCERjocsDZUTXY5ojqyUO6AjsMJrXoRYsMbU1T7baRQcCBO4q26j YChA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=hkNW3+zhE3K/9P1Z/COs+UEjs7Pp4ZWIDmlATzk6Gtw=; b=KJOBlPy2DZFIX2pIImdzZ66Ie6EelGTSXtCrML8nYT0A3Q4uDvox1wFzRyNIE1nQhp 8pnJPHNeducb5YVGv4dMITlGAptHxQ4sKIgo90HeFCquP8B1MMzYKDGmoLO7dm3KmcMC JTr8EI5h8PjvgqJpGYmIIHWWtxXorDulknPfe0gJAxPdEf7d1i3QCee2Rm6EXFxaGjbz PTlukAKN7K4NTHKgtnKOc1W7YUlgodyLvmAyjrMNheZNAFt7ryPj2p2oXHgXc/nME8LF 76Ubly4C5h2mEz5Fkz+0XUSn8xRoMDeKfLfJN88dL8yi5xao+BDeFkhV59DLrISWnqmT XP1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ilYwzq0Q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m75-v6si14907940pga.481.2018.10.16.10.22.00; Tue, 16 Oct 2018 10:22:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ilYwzq0Q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730397AbeJQBK6 (ORCPT + 99 others); Tue, 16 Oct 2018 21:10:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:56132 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727562AbeJQBK6 (ORCPT ); Tue, 16 Oct 2018 21:10:58 -0400 Received: from localhost (ip-213-127-77-176.ip.prioritytelecom.net [213.127.77.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B4C4120866; Tue, 16 Oct 2018 17:19:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539710373; bh=qmJhRaWiopWyaICIvc97IVvNZYU7HQcCja4uVqfx6QQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ilYwzq0Q1OmzZPAr0HbbDeQlVk/a5b4cNM2LAWxd/73Lc+Wfts3aR76ckFkKv/yCP A7aErUhrZrAILoCQJv3XrOhgr2p3J6VDDYbnots+H1N5/qKwHCLFOKWHrgrHh+cfjn idUFin5QKvXuhfH6uNEVBkvMOxw7L0sUr07LwFl4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephen Hemminger , "David S. Miller" , Sasha Levin Subject: [PATCH 4.14 056/109] PCI: hv: support reporting serial number as slot information Date: Tue, 16 Oct 2018 19:05:24 +0200 Message-Id: <20181016170527.955865574@linuxfoundation.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181016170524.530541524@linuxfoundation.org> References: <20181016170524.530541524@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stephen Hemminger [ Upstream commit a15f2c08c70811f120d99288d81f70d7f3d104f1 ] The Hyper-V host API for PCI provides a unique "serial number" which can be used as basis for sysfs PCI slot table. This can be useful for cases where userspace wants to find the PCI device based on serial number. When an SR-IOV NIC is added, the host sends an attach message with serial number. The kernel doesn't use the serial number, but it is useful when doing the same thing in a userspace driver such as the DPDK. By having /sys/bus/pci/slots/N it provides a direct way to find the matching PCI device. There maybe some cases where serial number is not unique such as when using GPU's. But the PCI slot infrastructure will handle that. This has a side effect which may also be useful. The common udev network device naming policy uses the slot information (rather than PCI address). Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/pci/host/pci-hyperv.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) --- a/drivers/pci/host/pci-hyperv.c +++ b/drivers/pci/host/pci-hyperv.c @@ -100,6 +100,9 @@ static enum pci_protocol_version_t pci_p #define STATUS_REVISION_MISMATCH 0xC0000059 +/* space for 32bit serial number as string */ +#define SLOT_NAME_SIZE 11 + /* * Message Types */ @@ -516,6 +519,7 @@ struct hv_pci_dev { struct list_head list_entry; refcount_t refs; enum hv_pcichild_state state; + struct pci_slot *pci_slot; struct pci_function_description desc; bool reported_missing; struct hv_pcibus_device *hbus; @@ -1481,6 +1485,34 @@ static void prepopulate_bars(struct hv_p spin_unlock_irqrestore(&hbus->device_list_lock, flags); } +/* + * Assign entries in sysfs pci slot directory. + * + * Note that this function does not need to lock the children list + * because it is called from pci_devices_present_work which + * is serialized with hv_eject_device_work because they are on the + * same ordered workqueue. Therefore hbus->children list will not change + * even when pci_create_slot sleeps. + */ +static void hv_pci_assign_slots(struct hv_pcibus_device *hbus) +{ + struct hv_pci_dev *hpdev; + char name[SLOT_NAME_SIZE]; + int slot_nr; + + list_for_each_entry(hpdev, &hbus->children, list_entry) { + if (hpdev->pci_slot) + continue; + + slot_nr = PCI_SLOT(wslot_to_devfn(hpdev->desc.win_slot.slot)); + snprintf(name, SLOT_NAME_SIZE, "%u", hpdev->desc.ser); + hpdev->pci_slot = pci_create_slot(hbus->pci_bus, slot_nr, + name, NULL); + if (!hpdev->pci_slot) + pr_warn("pci_create slot %s failed\n", name); + } +} + /** * create_root_hv_pci_bus() - Expose a new root PCI bus * @hbus: Root PCI bus, as understood by this driver @@ -1504,6 +1536,7 @@ static int create_root_hv_pci_bus(struct pci_lock_rescan_remove(); pci_scan_child_bus(hbus->pci_bus); pci_bus_assign_resources(hbus->pci_bus); + hv_pci_assign_slots(hbus); pci_bus_add_devices(hbus->pci_bus); pci_unlock_rescan_remove(); hbus->state = hv_pcibus_installed; @@ -1787,6 +1820,7 @@ static void pci_devices_present_work(str */ pci_lock_rescan_remove(); pci_scan_child_bus(hbus->pci_bus); + hv_pci_assign_slots(hbus); pci_unlock_rescan_remove(); break; @@ -1895,6 +1929,9 @@ static void hv_eject_device_work(struct list_del(&hpdev->list_entry); spin_unlock_irqrestore(&hpdev->hbus->device_list_lock, flags); + if (hpdev->pci_slot) + pci_destroy_slot(hpdev->pci_slot); + memset(&ctxt, 0, sizeof(ctxt)); ejct_pkt = (struct pci_eject_response *)&ctxt.pkt.message; ejct_pkt->message_type.type = PCI_EJECTION_COMPLETE;