From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 144577D043 for ; Thu, 21 Jun 2018 19:22:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754157AbeFUTWZ (ORCPT ); Thu, 21 Jun 2018 15:22:25 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:41236 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754129AbeFUTWY (ORCPT ); Thu, 21 Jun 2018 15:22:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EGrbVZB0DlhS1XKIlcWkcwmIHatxL7EHkaNy26JV3JE=; b=sqc0fKPIhb2zWzFOjcr6MHIxH zxRLR7oTXppLTAckqaCnuUj7rQuBnXSuQKPh1176RHf2O7OYKs8pEeKc4HnMTbMcathMdqIwGMCIV JfKiByajXZw7paOk70vTy+AoaPDFImBYyU7WWgofpkEeMUCQzQYzE0NJXUMyJdbz+OEVP25kpYl2Q C5VaT22aQRwE0C8gZjZ1sFjZZQCWHxFbNlq64JtkPa0o4WD/8hBraUoM9ZSSrLJqI0eUvFVTDsQAT UV3UB92Fn8u7/soOAhMz9Cm34gVip5KXec/2MmYaKCu7uM4a4wAxSWe7WsfLC8lXdfvhuMnlXXR9b cJvqgUcew==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1fW59x-0004Ea-1a; Thu, 21 Jun 2018 19:22:21 +0000 Date: Thu, 21 Jun 2018 12:22:20 -0700 From: Matthew Wilcox To: Logan Gunthorpe Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, Stephen Bates , Christoph Hellwig , Bjorn Helgaas , Jonathan Corbet , Ingo Molnar , Thomas Gleixner , "Paul E. McKenney" , Marc Zyngier , Kai-Heng Feng , Frederic Weisbecker , Dan Williams , =?iso-8859-1?B?Suly9G1l?= Glisse , Benjamin Herrenschmidt , Alex Williamson , Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH v3 2/3] PCI: Allow specifying devices using a base bus and path of devfns Message-ID: <20180621192220.GA6635@bombadil.infradead.org> References: <20180618193636.16210-1-logang@deltatee.com> <20180618193636.16210-3-logang@deltatee.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180618193636.16210-3-logang@deltatee.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Mon, Jun 18, 2018 at 01:36:35PM -0600, Logan Gunthorpe wrote: > @@ -3000,14 +3000,18 @@ > or a set of devices (). These are > specified in one of the following formats: > > - [:]:. > + [:]:.[/.][/ ...] How about: + [:]:.[/.]* > - by other kernel parameters. The second format > + by other kernel parameters. Optionally > + a path from a device through multiple I think that's "a path to a device", because you'd start by specifying the root port, then continuing down the hierarchy, right? > + * Test if a string (typically from a kernel parameter) formated as a formatted > + * path of slot/function addresses matches a PCI device. The string must > + * be of the form: > + * > + * [:]:./.[/ ...] > + * > + * A path for a device can be obtained using 'lspci -t'. Using a path > + * is more robust against renumbering of devices than using only I'd call it bus renumbering rather than device renumbering. After all, if the device got renumbered, this would fail ;-) > * pci_dev_str_match - test if a string matches a device > * @dev: the PCI device to test > * @p: string to match the device against > * @endptr: pointer to the string after the match > * > * Test if a string (typically from a kernel parameter) matches a > - * specified. The string may be of one of two forms formats: > + * specified. The string may be of one of three formats: Surely just "The string may be in one of three formats" > * > * [:]:. > + * path:[:]:./.[/ ...] > * pci::[::] I think you're dropped the "path:" prefix from your parser? > * The first format specifies a PCI bus/slot/function address which > * may change if new hardware is inserted, if motherboard firmware changes, > * or due to changes caused in kernel parameters. > * > - * The second format matches devices using IDs in the configuration > + * The second format specifies a PCI bus/slot/function root address and > + * a path of slot/function addresses to the specific device from the root. > + * The path for a device can be determined through the use of 'lspci -t'. > + * This format is more robust against renumbering issues than the first format. > + > + * The third format matches devices using IDs in the configuration > * space which may match multiple devices in the system. A value of 0 > * for any field will match all devices. > * So you probably want to reword this too. Two formats, one with optional trailing path elements? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html