Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1032714iob; Fri, 13 May 2022 20:23:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzx06T5oKtCkP3oamWNuxXBG5Y71AAPiN8t6BkeoEZ7po1710RFHz3YSHk7bTI0dD7v1/lT X-Received: by 2002:a05:600c:1c0e:b0:394:66af:ef0f with SMTP id j14-20020a05600c1c0e00b0039466afef0fmr17168705wms.48.1652498615076; Fri, 13 May 2022 20:23:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652498615; cv=none; d=google.com; s=arc-20160816; b=G42pwpWPL6XZjdLzODowU2mo57B516S2WQh1j1v/9kyV2iO/Jp2SBZqTuRpXBIcZSu 6nojDKvRBhKnDxX4+dEtGQkgkLyLumzjfDi0qkbUJ56cHzVZBhVojHvPAAe8FLPP91GQ /oKd4yQYmSbrIPWFI0OSBZ8QV2jqVq0fTxuGJrWYHBI9+cLIeYb38lPLRza0UmmUb6Fg Bx1aDmN5PWfzKk2ZGg4j+ChTlZGgDNv9ekCiZXkk61W+vejL9r2kTFoxBDMWbAIAiAER Onv1VifAGPQf+HvdY9hDk8sz5bA62A1KKJyudaepqLy1vw66wUPe7VgRtzlEiUuLwAcr 0uJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=1/pCANrZyETTsoofnG0/B/4Yepi2qlfi75H1VY6UUsc=; b=kkdg309hYKHhfMBFY3drXo0RyPb1cWLQ3Tmkiey14otn1VOEBHUUaLFyUHNapz0rpE ivfPwAjW/rIktp85V9PBbApzJynZxk2b43iTkyWSdj1S1OCVvlL7j54csvGww15ntJ/9 xsb407gRFIoUMbBRtlnz1HjUVIfwFV2jIE1IrEptxdZYh/treUbgI6XuIKKz0aAQRLZm N8dkmLZISWVSAfGb1X9YJfOFfz8krCoOXXRjw6TnW2a8xJZrftD6u8zdvo91Hlb/lvNr si95Uk8gs882x2rqw2T+mbPya2lYat4HT5MOl8uholuxcIoNlDt6RYahnaLn8K4dWqlC nONw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Zrk377rY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id u14-20020a5d6dae000000b0020acdeacad0si4219138wrs.1014.2022.05.13.20.23.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 20:23:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Zrk377rY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8DE6940524D; Fri, 13 May 2022 17:01:11 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232614AbiEMOHe (ORCPT + 99 others); Fri, 13 May 2022 10:07:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229788AbiEMOH2 (ORCPT ); Fri, 13 May 2022 10:07:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F32450B0E; Fri, 13 May 2022 07:07:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CF4DF6203F; Fri, 13 May 2022 14:07:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7CE8C34100; Fri, 13 May 2022 14:07:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652450845; bh=JHGmg8HELW1l/NvkzMwcz7ZBqd9Xb6Lnpfs7ZKtiCY4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=Zrk377rYFyGd1DKEgPcrB9U2j9iCZcIVPSjX3G4yXLEfiYpGZy5dx2KMZOtOZ0yNr NCoJXvvNbST2JWJjySL0hS2bH2g4g0XE7V+Gm1NKCEdd9QvmqMast/6QrQI/KEDfMi WorsvflMykUMERYcoyJYSOpC8+l5LMCOzs2YBBRmSJoUTzGKf0scl5FddkBQWOaIhT GwnqFB1VZwZplQZt3NTcK3a/KMcSRjIo0CKbfTxNhXSfdEwnYuPerD7pwFFJGJFJA3 hyQLhJjridnveTZ/DfiPT9rpVPxjE9kNvIpfOa4uQeptvK60qVAzKlySyll0t2HMRY 5It/PFzyhHP4Q== Date: Fri, 13 May 2022 09:07:23 -0500 From: Bjorn Helgaas To: Niklas Schnelle Cc: Bjorn Helgaas , Jan Kiszka , Matthew Rosato , Pierre Morel , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-s390@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH RESEND v5 1/4] PCI: Clean up pci_scan_slot() Message-ID: <20220513140723.GA947754@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 12, 2022 at 04:56:42PM +0200, Niklas Schnelle wrote: > On Thu, 2022-05-05 at 10:38 +0200, Niklas Schnelle wrote: > > While determining the next PCI function is factored out of > > pci_scan_slot() into next_fn() the former still handles the first > > function as a special case. This duplicates the code from the scan loop. > > > > Furthermore the non ARI branch of next_fn() is generally hard to > > understand and especially the check for multifunction devices is hidden > > in the handling of NULL devices for non-contiguous multifunction. It > > also signals that no further functions need to be scanned by returning > > 0 via wraparound and this is a valid function number. > > > > Improve upon this by transforming the conditions in next_fn() to be > > easier to understand. > > > > By changing next_fn() to return -ENODEV instead of 0 when there is no > > next function we can then handle the initial function inside the loop > > and deduplicate the shared handling. This also makes it more explicit > > that only function 0 must exist. > > > > No functional change is intended. > > > > Cc: Jan Kiszka > > Signed-off-by: Niklas Schnelle > > --- > > Friendly ping :-) Thanks and sorry for the delay. I'm off today for my daughter's wedding reception but will get back to it next week. Just to expose some of my thought process (and not to request more work from you!) I've been wondering whether b1bd58e448f2 ("PCI: Consolidate "next-function" functions") is really causing us more trouble than it's worth. In some ways that makes the single next-function harder to read. But I guess the hypervisor special case is not exactly a "next-function" thing -- it's a "keep scanning even if there's no fn 0" thing. Bjorn