Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp610062ybl; Wed, 29 Jan 2020 06:32:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwxDet0+dJhcsAk/zfQscddg3+edlGXmyKP9C8edZO8gayLB8YEpZV9vHU0nfn0TYYrM+b4 X-Received: by 2002:aca:d787:: with SMTP id o129mr6683908oig.75.1580308375018; Wed, 29 Jan 2020 06:32:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580308375; cv=none; d=google.com; s=arc-20160816; b=01b/yJoesNytXpR2FNWapSkuaepc/smeDJ9+NMULewwSDWWwNXl9ZoAr/01hFrUY74 uRqSjVLdniSAPnlQhzfPoYkyHOItoRviJDa0Ompu02Fcb+EvpJr2TTL/CVEB8BeQlBkP V7n31bKqBM866jwkco3ePZHjBnrk2oRwIUf13w/oEXIfw02FqbG/W7sZ7N36pC2z2TFs 5gng4wKEo8QDamMZI/dO0xM8+K71YY4qS5OjN8EJCNAQqTefGZidauaTJStM2oipGocO UFIxsuEvdE3BhYlbYllAd0yDT6D5t7J4JqLHKC8A2Ma4weF6rPngkDgkqlaKDC4rCT9c cssQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=tqM9aR/5G9waRFEyr2/olr1EPvDZjefsaR8YrM1XMyw=; b=cSg8RR4SbR8UQjFz9lGgng0tsYEWK+TNZci6XUGNLOE6XnqPflPgi++R8Up/h5oZxh r+IpZbXFvUxlgU6Hwl2lQa2HrjjnjpjMawGDVv3stDUNu4PB39tsXle4qEoah6kZorhU 3R54oxKkGBR/AY0TtJk+e+T0nlxTPrPhfO4B+56wz8uJOVMC71GUCakSvjApqJuOi5hs dd2R/qNJarPLYQi76gLRb3IWMpLZ7H7DLe9RqFlDZTex/ZWn7iorjn5IpRwmkbIePwKO 70XOvi4z2lp2oxoQNFs6O3gk+bpLM+35iVk55P/lnoFUYH0U2b8IhNdICTMGvpjRxlre kgMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=iGOEQcM+; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h28si1268943otg.63.2020.01.29.06.32.42; Wed, 29 Jan 2020 06:32:55 -0800 (PST) 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=iGOEQcM+; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726713AbgA2ObU (ORCPT + 99 others); Wed, 29 Jan 2020 09:31:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:58080 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726617AbgA2ObR (ORCPT ); Wed, 29 Jan 2020 09:31:17 -0500 Received: from localhost (173-25-83-245.client.mchsi.com [173.25.83.245]) (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 A3CA320716; Wed, 29 Jan 2020 14:31:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580308276; bh=BDy2XckpsiwyIjp1K++dkGaIVLjtMn3ISUcR6+TLvJ4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=iGOEQcM+SaqL4k+Hp1FWzvZDGGt6RCtrtc6GQ3pBPYqrNVnOdiLlBhEPb1bJZxXC9 jp9zsNdUG7kDL6viFh2jvpPEGZfZYPm2YMMqf+QLgdLPw0+5WvZ86XlM/+Ex9TBM5g DeAiIeXemZoUvKLIRKBRlTBvwzRaiVFSZLUy7ZEk= Date: Wed, 29 Jan 2020 08:31:15 -0600 From: Bjorn Helgaas To: Bharat Kumar Gogada Cc: "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ravikiran Gummaluri Subject: Re: [PATCH v4 2/2] PCI: xilinx-cpm: Add Versal CPM Root Port driver Message-ID: <20200129143115.GA106689@google.com> 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) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 29, 2020 at 11:16:47AM +0000, Bharat Kumar Gogada wrote: > > Subject: Re: [PATCH v4 2/2] PCI: xilinx-cpm: Add Versal CPM Root Port driver > > > > On Tue, Jan 28, 2020 at 06:14:43PM +0530, Bharat Kumar Gogada wrote: > > > - Add support for Versal CPM as Root Port. > > > - The Versal ACAP devices include CCIX-PCIe Module (CPM). The integrated > > > block for CPM along with the integrated bridge can function > > > as PCIe Root Port. > > > - CPM Versal uses GICv3 ITS feature for achieving assigning MSI/MSI-X > > > vectors and handling MSI/MSI-X interrupts. > > > - Bridge error and legacy interrupts in Versal CPM are handled using > > > Versal CPM specific MISC interrupt line. > > > > > > Changes v4: > > > - change commit subject. > > > - Remove unnecessary comments and type cast. > > > - Added comments for CPM block register access using readl/writel. > > > > > > Signed-off-by: Bharat Kumar Gogada > > > ... > > > > > +static bool xilinx_cpm_pcie_valid_device(struct pci_bus *bus, > > > + unsigned int devfn) > > > +{ > > > + struct xilinx_cpm_pcie_port *port = bus->sysdata; > > > + > > > + /* Only one device down on each root port */ > > > + if (bus->number == port->root_busno && devfn > 0) > > > + return false; > > > > This whole *_valid_device() thing is a mess. We shouldn't need it at all. But if > > we *do* need it, I don't think you should check the entire devfn because that > > means you can't attach a multifunction device. > > > > Several other drivers with similar *_valid_device() implementations check only > > PCI_SLOT(): > > > > dw_pcie_valid_device() > > advk_pcie_valid_device() > > pci_dw_valid_device() > > altera_pcie_valid_device() > > mobiveil_pcie_valid_device() > > rockchip_pcie_valid_device() > > > > Even checking just PCI_SLOT() is problematic because I think an ARI device with > > more than 8 functions will not work correctly. > > > > What exactly happens if you omit this function, i.e., if we just go ahead and > > attempt config accesses when the device is not present? We > > *should* get something like an Unsupported Request completion, and that > > *should* be a recoverable error. Most hardware turns this error into read data > > of 0xffffffff. The OS should be able to figure out that there's no device there > > and continue with no ill effects. > > > Thanks Bjorn. I did test and I do not see any issue without this. > Will resend patch with this change. That's great, thanks for testing that! I wonder how many other drivers could just drop that code. Bjorn