Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp88541pxb; Tue, 2 Feb 2021 23:54:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJyEvguKXZ52OhrY6K0AynnACdcKi5G3eFcJeXV7VK9PwHAZw1TWlOYA0/cCmQYIyHAVqZzP X-Received: by 2002:a17:906:d18e:: with SMTP id c14mr1448641ejz.302.1612338868180; Tue, 02 Feb 2021 23:54:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612338868; cv=none; d=google.com; s=arc-20160816; b=jHLLE0bcixZRKqZ7VY2dfbmhRUAISQrt2fTdXM25oIGklmMJ//YkH66MI2D3mGwUh3 HKhkcXRZgumfKwzkP7WO6EvN26BJeTDLgtSug1qV0vJLRai1ihRlOUVDFUFHfspOvST7 g/RODJk1MZrJXa9kaLA+sF5STsAQQtnTqbW5vOIf0aZIbNtDCMsvT/lIx+OX+9VGSFfh 2L9kR82DN2mb1f7TBkcxmagv7VUAAdNb5n5oxL5tkDeO/zrPYL7I89qdLi+Scv7Fscmd 2RGedtu7rrCldZG3Dgn/lXN4PpYupw27N+eg6oQo9y9OUsyKCyp+DdbKqYoliD0/SOlE xk6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ODL2aWes9PfW60Q8xgYbo2WmcUJ3/hPUCXeL4++GPHc=; b=LaNNqGdNIzjoGXzlzCTY2/hbbjdMScZYo1oSDk3bGYYEBVdU6wsrkpqos50sQE7igO 0bLvLPxq2zbTNbrfpuZOyjVDJ30Rf618BmQk97Qk+De0Wn0SVco8u5QEKkvUwA7ZdMmV 2HftTcGGVuS7rXuWlscpiDi+19t35oFT4hYhiXeGj5v81CDAO1j5pmqq7t7nBeZBa/fo 5ZFWSLFsdqnJEtdpIoZVaCzs0DFPSGCY4BmgmNSZ1MFi12DoeQVGWoOJF/bGXIGwL3Cg DKBf6fnTMX/1Yh/Q5EbpaVzXbe5ZicxHYattiUSOETQhcN6+U8vFhLGPplVBtBWjE8sM BZ0A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l13si953269ejg.426.2021.02.02.23.54.03; Tue, 02 Feb 2021 23:54:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232250AbhBCHvu (ORCPT + 99 others); Wed, 3 Feb 2021 02:51:50 -0500 Received: from bmailout3.hostsharing.net ([176.9.242.62]:47027 "EHLO bmailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232238AbhBCHvt (ORCPT ); Wed, 3 Feb 2021 02:51:49 -0500 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id B2F08100DA1A7; Wed, 3 Feb 2021 08:51:03 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 82B4A22451; Wed, 3 Feb 2021 08:51:03 +0100 (CET) Date: Wed, 3 Feb 2021 08:51:03 +0100 From: Lukas Wunner To: Gustavo Pimentel Cc: "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" , Bjorn Helgaas Subject: Re: [PATCH v2 04/15] PCI: Add pci_find_vsec_capability() to find a specific VSEC Message-ID: <20210203075103.GA18742@wunner.de> References: <2ecb33dfee5dc05efc05de0731b0cb77bc246f54.1612269537.git.gustavo.pimentel@synopsys.com> <20210202180855.GA3571@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 03, 2021 at 01:54:49AM +0000, Gustavo Pimentel wrote: > On Tue, Feb 2, 2021 at 18:8:55, Lukas Wunner wrote: > > As the name implies, the capability is "vendor-specific", so it is > > perfectly possible that two vendors use the same VSEC ID for different > > things. > > > > To make sure you're looking for the right capability, you need to pass > > a u16 vendor into this function and bail out if dev->vendor is different. > > This function will be called by the driver that will pass the correct > device which will be already pointing to the config space associated with > the endpoint for instance. Because the driver is already attached to the > endpoint through the vendor ID and device ID specified, there is no need > to do that validation, it will be redundant. Okay. Please amend the kernel-doc to make it explicit that it's the caller's responsibility to check the vendor ID. Thanks, Lukas