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 875A3A052A; Tue, 26 Jan 2021 19:18:36 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 06BD9140F33; Tue, 26 Jan 2021 19:18:36 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by mails.dpdk.org (Postfix) with ESMTP id 8446F140F31 for ; Tue, 26 Jan 2021 19:18:34 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id 6so17504162wri.3 for ; Tue, 26 Jan 2021 10:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mayadata-io.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=1TyOU65jAbFbQ+nnB2ZH4VthpT43fBcbDQ3K6k2MeDU=; b=U1rTzQ5HGi4DTmyBgIcWV1eCKkDvGeV2O4SxwOUJ/Ra3yZ4xH2GdbqXOOKwCu8VnNX q2B/1tyNoRCHBKfq/XpQEib3LGuqzpAcDcLGSwrlKykSm2XXxiK9YjsjmfLtST2VUGeB MoE7MFow3peUfEjZMtNpG2mulGr9C48xUgsAbBG8Gu7vpn7qxvsJpN4ZzgjaZEgNRptI 6/krBfjXm8PnF0rzEMiZGMzWWHx5qBFMgVL3qzDSCtWPs707/GeypaHjMy+yQ6bjb9a6 ltWx4QVDBDutTmkkB7+1pcjnqDLaDRHRtb0ORKS4j1t1dsnwCTfY4/nRlE6AKaDxVWeU SsoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1TyOU65jAbFbQ+nnB2ZH4VthpT43fBcbDQ3K6k2MeDU=; b=R+lMvEDZ+Gffh2vIXXDF8Paf+Bw0EnnOeSZQJwApV+i4b4HlIBx+BamHY9D+8pMAd2 XGAKw///GBXmWlynPWokriLU1HAqlImnEr2FUKF0q1lIKaoRr2SjWnP819ZuVhSCOsHM KbQONYkewT0qwUBDwqlr7hAnmAxchaltVB+ao1VsNWPJsEGnwa0W3ObcVtotFugyix0c Zu/NMolP3ctpXOsjKL6WsUhLQYs6PFfLYZR+baRBmqKHVqcMvIENSjvL4dyoVL+wKzjj 48/xbLRlEqmr6FVhcCzGWer1K7aoapimWfRN4QXBVU+kVyu+X/ckaM4NdXkTygalqpRT Ra3g== X-Gm-Message-State: AOAM533Zx1g5BRuN8ZVU9w9r+6b496TFfyf6/0j2u78Zo+stysP00EDX GUzfWXl4Sz1H6dEpXrhcB5S6ONhwdt99N3Jo X-Google-Smtp-Source: ABdhPJzduZSCfHN2IgAzyNeE6Sb+74pDmJkyDawL2cmCidcZ0JuxBRnSQn/5vsSF449cw0iONl2Jqw== X-Received: by 2002:a5d:5686:: with SMTP id f6mr7332572wrv.257.1611685113675; Tue, 26 Jan 2021 10:18:33 -0800 (PST) Received: from [192.168.0.33] (cpc98320-croy25-2-0-cust77.19-2.cable.virginm.net. [80.235.134.78]) by smtp.gmail.com with ESMTPSA id a184sm4473916wme.35.2021.01.26.10.18.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Jan 2021 10:18:33 -0800 (PST) From: Nick Connolly X-Google-Original-From: Nick Connolly To: Tal Shnaiderman , "dmitry.kozliuk@gmail.com" , "pallavi.kadam@intel.com" , NBU-Contact-Thomas Monjalon Cc: "dev@dpdk.org" References: <20210125170821.11306-1-nick.connolly@mayadata.io> Message-ID: Date: Tue, 26 Jan 2021 18:18:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [dpdk-dev] [PATCH] 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" Hi Tal, Thanks for the comments. >> + /* Try and find PCI class ID */ >> + for (cp = buf; !(cp[0] == 0 && cp[1] == 0); cp++) > How about > for (cp = buf; cp[0] || cp[1]; cp++) That would be my preferred idiom, but the DPDK coding style (1.9.1) says 'do not use ! for tests unless it is a boolean' (but somewhat confusingly does so in a section on NULL pointers).  I interpreted it as a general prohibition on conditionals without an explicit operator (except for booleans).  I'd love to be corrected here! >> + if (*cp == '&' && sscanf_s(cp, "&CC_%" PRIx32, &class_id) == 1) > Could there be a case where PCI\\VEN_v(4)&DEV_d(4)&CC_c(2)s(2) exist but PCI\\VEN_v(4)&DEV_d(4)&CC_c(2)s(2)p(2) doesn't? In that case the parsing would be incorrect. The MSDN documentation says that the most specific string will be returned first, in this case &CC_c(2)s(2)p(2), so if there is a 6-digit class ID we will return it.  That left me wondering what to do if we only encounter a 4-digit class ID.  If we ignore it, then we won't be able to match on the class ID.  We could parse it as 4-digits and supply zero for the p(2) field, but that left me wondering why Windows wouldn't have already done that for us.  What I see on my own systems is that there is always a 6-digit class ID defined, even if the pci-ids repository doesn't list any values for p(2) (e.g. https://pci-ids.ucw.cz/read/PD/07/80 reports as &CC_078000). My conclusion was that was probably best just to return the first class ID that Windows reports even if it's only 4-digits.  That way the device can still be found and will match the CC_ info displayed in device manager. Thanks, Nick