From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9DFB8A00C2; Sun, 28 Feb 2021 15:38:26 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41A4E22A23D; Sun, 28 Feb 2021 15:38:26 +0100 (CET) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by mails.dpdk.org (Postfix) with ESMTP id 3C58A4069E for ; Sun, 28 Feb 2021 15:38:25 +0100 (CET) Received: by mail-lj1-f174.google.com with SMTP id p15so7403374ljc.13 for ; Sun, 28 Feb 2021 06:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=oBYGEac4iecdr4f4k2yhUwakp5r1P6vtp4ItAJtLEqc=; b=epcCUkQa10r5+pMknjbqC9Woc8mAdaDlwKVxp6JFppMOv/qGrt4Tv6/II6GGtvXKsp q85oguOqV1LpMQvmIoH/rrT92n7jiH/7igWGp+f+D30aryp0V0+WP5SI1K/3dPnox2MJ ay19kBHpYKCx9PAmbq3kbfX/TvPClpFdNoKLxMoUZoX9W1T3BoXZDIej5DPG+adiRdu8 SjrT32H/Wagc5Q3N1HbhdW02l2FvPJ1Sq/dPeoLwGQYzGs392+31I/5J9V22KlYp6fFb IXJbDZrW6KLQYT5NiuWU/Lgq2Yrt/l/HZQio8ASoFSCruaRs7p4d6ZbBPYPhgwriwJ2P 6nFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oBYGEac4iecdr4f4k2yhUwakp5r1P6vtp4ItAJtLEqc=; b=X8A0TsGTptqdjd7bgYDzhq+UPEvUbAZ8VTBPNhE3ZPxGxycW893mDjA6qWG3As7I/S v+KgnbGezHf98NH2yi5074Z6ThUr+G45zXxd0XWbmfFcndwLdve7yOMy//ok/JnmkaLP DA/ZJjPSzmrwXdEY2S1NTMUejnXF0n7mR2bdjMJ1G/zrBFYuOn37jWwA3BOHUOjFNC+c /6P6kMy1I8YaW8gDI7d6AU7G7CyaKxmSL6C+vySWz8qovu9GLW2Ud9UMeMIKTamZbRA7 12bV1XpzdaBOLXbm5HvXFqjV+s2AeWHUUX0/mVbCGWQ8td1K3F9JvZCqmMjYcTlkalel 4tFQ== X-Gm-Message-State: AOAM533o5VpneoK5SQPJsNCNu/p2ZxNoe+8XLi8McvKMjUOoTopYdfOh QzJpZ1wOGwNKK467DufR0ck= X-Google-Smtp-Source: ABdhPJzcPVWZEfaRaEpNpzNHKQezWtleC5RJHtFl2VMsW6tdy5Hqdojp9skfT6Vh5X/esgfG4xkUQw== X-Received: by 2002:a2e:8184:: with SMTP id e4mr6715339ljg.43.1614523104838; Sun, 28 Feb 2021 06:38:24 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id r5sm2125832ljh.128.2021.02.28.06.38.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Feb 2021 06:38:24 -0800 (PST) Date: Sun, 28 Feb 2021 17:38:22 +0300 From: Dmitry Kozlyuk To: Nick Connolly Cc: talshn@nvidia.com, pallavi.kadam@intel.com, thomas@monjalon.net, dev@dpdk.org Message-ID: <20210228173822.69a09b0f@sovereign> In-Reply-To: <20210223181857.2516-1-nick.connolly@mayadata.io> References: <20210125170821.11306-1-nick.connolly@mayadata.io> <20210223181857.2516-1-nick.connolly@mayadata.io> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6] bus/pci: nvme on Windows requires class id and bus X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2021-02-23 18:18, Nick Connolly: > Attaching to an NVMe disk on Windows using SPDK requires the > PCI class ID and device.bus fields. Decode the class ID from the PCI > device info strings if it is present and set device.bus. > > Signed-off-by: Nick Connolly > Acked-by: Tal Shnaiderman > --- > v6: > * no changes - resending to resolve spurious iol-testing failure > > v5: > * Add missing version history > > v4: > * Use #define to determine length of Class ID > > v3: > * Put version history at top - v2 mistakenly had it after the diffs > > v2: > * If only a 4-digit class ID is available, convert it to 6-digit format > > drivers/bus/pci/windows/pci.c | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c > index f66258452..dceb0f4b2 100644 > --- a/drivers/bus/pci/windows/pci.c > +++ b/drivers/bus/pci/windows/pci.c > @@ -23,6 +23,9 @@ DEFINE_DEVPROPKEY(DEVPKEY_Device_Numa_Node, 0x540b947e, 0x8b40, 0x45bc, > * the registry hive for PCI devices. > */ > > +/* Class ID consists of hexadecimal digits */ > +#define RTE_PCI_DRV_CLASSID_DIGIT "0123456789abcdefABCDEF" > + > /* The functions below are not implemented on Windows, > * but need to be defined for compilation purposes > */ > @@ -280,17 +283,29 @@ parse_pci_hardware_id(const char *buf, struct rte_pci_id *pci_id) > { > int ids = 0; > uint16_t vendor_id, device_id; > - uint32_t subvendor_id = 0; > + uint32_t subvendor_id = 0, class_id = 0; > + const char *cp; > > ids = sscanf_s(buf, "PCI\\VEN_%" PRIx16 "&DEV_%" PRIx16 "&SUBSYS_%" > PRIx32, &vendor_id, &device_id, &subvendor_id); > if (ids != 3) > return -1; > > + /* Try and find PCI class ID */ > + for (cp = buf; !(cp[0] == 0 && cp[1] == 0); cp++) > + if (*cp == '&' && sscanf_s(cp, > + "&CC_%" PRIx32, &class_id) == 1) { > + /* Convert 4-digit class IDs to 6-digit format */ > + if (strspn(cp + 4, RTE_PCI_DRV_CLASSID_DIGIT) == 4) > + class_id <<= 8; > + break; > + } > + Is "4/6-digit format" used commonly for class ID, subclass ID, and optional programming interface code? If not, I suggest sticking to official terminology, something like "Assume zero programming interface code if unspecified". In general, a link to format reference would be useful in commit message or function comment, for readers to understand what's being parsed: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/identifiers-for-pci-devices With above nits, Acked-by: Dmitry Kozlyuk