From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f194.google.com (mail-qt0-f194.google.com [209.85.216.194]) by dpdk.org (Postfix) with ESMTP id 7FED55F18 for ; Mon, 26 Mar 2018 21:13:49 +0200 (CEST) Received: by mail-qt0-f194.google.com with SMTP id w12so13181091qti.4 for ; Mon, 26 Mar 2018 12:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=OKjEITHabzQ2N57d0yRDPuGNJdkIEhZGO+kOe/hvcRM=; b=gBk8SpGOSN0bvYkqZ4tEo+H8TWr4+fQOrOnFNiTpKN05qtPKOMel8FWYLq6br77SH/ bKcsixffm01bzkvwxsorQMlcE/+U7KtOQyqveR8PSvUVgbeg0ZtAjlpov2XJXer777Er jfKMy3aNfl1L8UFiGyE2B7rQcR+pXlOWfQ4ts= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=OKjEITHabzQ2N57d0yRDPuGNJdkIEhZGO+kOe/hvcRM=; b=NQGGJsBdFYjcsAlrwWlKFKYJRkKvp/Fa73pEKMY+ZNd7QJk/Ix6ZFzBUtWduyfWc4k j8wPYbymdqH17lWqsvPyOtd4D6ciuHN2mHGKBcEHqvIkJsTeQPA2rcnFEmFMoA2mmuDv pvBEjl0vLdwWX73XWZZNsV6XJE0/COYsBdaX/D9VGkZLSUMLgeGnWsqm2oGaoHfoEkoQ uRd5V8lFkicpb8L0APeGD6XuOmxyGTJfrzyHL9fDN1o2OzE9XdcMWaSiuCMTyYtGEiR7 OpNa1lL4MYOCF9vCD/dNBvOGyzAuWgHfknnOmV0dmP+yO8HToVP4qOf25iWuvUH1dyK9 IZkw== X-Gm-Message-State: AElRT7GRjmLYzhI2jd0P8+FoaKBzOZBZPjNiZkCP72c6ztL1Re3uP0b4 munxmPpxsmP6NxFGAHwYJFdE6g== X-Google-Smtp-Source: AG47ELtCC7T1nTmv2sUjI7VePUsRIBVv6Gz5pBDYorhPnk70FKUBMKvtsAMLcBGj1ZVseN2Q87pyQA== X-Received: by 10.200.18.198 with SMTP id b6mr58269744qtj.34.1522091628525; Mon, 26 Mar 2018 12:13:48 -0700 (PDT) Received: from [10.136.13.65] ([192.19.224.250]) by smtp.gmail.com with ESMTPSA id b194sm8519413qkc.63.2018.03.26.12.13.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 12:13:47 -0700 (PDT) To: Ferruh Yigit , Ajit Khaparde , dev@dpdk.org Cc: Darren Edamura , Rahul Gupta References: <20180321180629.58318-1-ajit.khaparde@broadcom.com> <20180321180629.58318-5-ajit.khaparde@broadcom.com> <9c01c36e-b2a3-db28-f9b8-ccae8f33e71d@intel.com> <5fa0e9d9-9c64-c1e8-423d-e9d4441d5b3c@intel.com> From: Scott Branden Message-ID: <44f03664-8677-1a71-1e3e-c538bde877bb@broadcom.com> Date: Mon, 26 Mar 2018 12:13:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5fa0e9d9-9c64-c1e8-423d-e9d4441d5b3c@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH 4/4] igb_uio: bind error if pcie bridge X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 19:13:50 -0000 On 18-03-26 11:20 AM, Ferruh Yigit wrote: > On 3/26/2018 7:05 PM, Scott Branden wrote: >> Hi Ferruh, >> >> >> On 18-03-26 10:24 AM, Ferruh Yigit wrote: >>> On 3/21/2018 6:06 PM, Ajit Khaparde wrote: >>>> From: Darren Edamura >>>> >>>> Probe function should exit immediately if pcie bridge detected >>>> >>>> Signed-off-by: Darren Edamura >>>> Signed-off-by: Rahul Gupta >>>> Signed-off-by: Scott Branden >>>> Signed-off-by: Ajit Khaparde >>>> --- >>>> lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 3 +++ >>>> 1 file changed, 3 insertions(+) >>>> >>>> diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c >>>> index 4cae4dd27..3fabbfc4d 100644 >>>> --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c >>>> +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c >>>> @@ -473,6 +473,9 @@ igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) >>>> void *map_addr; >>>> int err; >>>> >>>> + if (pci_is_bridge(dev)) >>>> + return -ENODEV; >>> What do you think printing a log here? >> I think it brings little value.  ENODEV is already returned? > User should not provide bridge address at first place, I guess this is a > protection in case user provides bridge address by mistake. > In that case no device will be probed and user won't have any idea why. > I think a log in dmesg saying bridge device is provided may help to the user. I'll add a dev_warn as we actually encounter this issue on old silicon revisions due to bridge address equaling a PF. It's not a user error in such case and just needs to be ignored.  So adding this generic check allows such to occur. For other use cases like you mentioned it would be a user mistake. >>>> + >>>> udev = kzalloc(sizeof(struct rte_uio_pci_dev), GFP_KERNEL); >>>> if (!udev) >>>> return -ENOMEM; >>>> >> Regards, >>  Scott >>