Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp973582rwb; Thu, 6 Oct 2022 07:02:02 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6F+v6+qVJxBT6BqDFtWCS6ji66nBkTbTzhKJu28KITyr38SsfuurnjVU+OQP7XqPBjVWty X-Received: by 2002:a17:90a:6405:b0:203:6eaa:4999 with SMTP id g5-20020a17090a640500b002036eaa4999mr10858389pjj.8.1665064911126; Thu, 06 Oct 2022 07:01:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665064911; cv=none; d=google.com; s=arc-20160816; b=vhqQQacJP6bkX40fLh3Sc6O5tGveN8a1ZYz8Q0gkbrjnjRODpqFZO3mCFx8smG6YoV YMhqG9Y3x39ZDeK/nlDI09TnfxOCzCtPqmoJF4l7KSHS65+dos5VNodxo7WQrOfSujgZ klatyJjlx2Cd/hcgVlVqRr2No1qfsBOXVYkBNGKEqkn5NAQf4PGN31ID47+Z3DhbMS1u qd0dLBBTRgombIHnXPq+QHtuVaAfwEiA/8ty8Dwq6JD8M7eK58HxpMxXztouUi7amHtA HVyzDA/h++2KaKYahxFc7kDRyCt6RcbdeeUJ0LQKwqcEKBZtnyaZBNmcF5i93TLAbBeT o0og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=6ZdDTmo4+335EbBvlEmQjT8GDpny2W8EHJfskLeQgYU=; b=BziuVnbwu2pa0eJLPfEkkmAi5gCPvoscpfE3oSQGHJgD2EIgq3DEX62KL5NSRqAeL4 I3P1TjQ5LcnDYEnyxHrGL3wl6axksTahvt7m8PWnwXSFKBatz2kK9Vb7AR+BP9thMXjl DSl/FV49yei+yc7C9xQm9fegcIGGrkuJnLkVzjxdvGBWC6ahhv2p2YpaExGx1qWmxt8x pcpgVdtiuPKUMEs+3Fx+fy9ch4kA3yr4/NKSjAnXL4fsXSmRguaKbJVDL58NFo8yBM0t cl1DT/bY0QH1A+HkylxcObG35nx9hGxFDfQFGBmvqUeIolxXPZ23D5GsftpSIgbNAGsN Cv4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=OM8dnY2t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a6-20020a056a000c8600b00546ce9189b1si20425656pfv.65.2022.10.06.07.01.32; Thu, 06 Oct 2022 07:01:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=OM8dnY2t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231177AbiJFNby (ORCPT + 99 others); Thu, 6 Oct 2022 09:31:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230447AbiJFNbu (ORCPT ); Thu, 6 Oct 2022 09:31:50 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C24BDAA374; Thu, 6 Oct 2022 06:31:26 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id u21so2802061edi.9; Thu, 06 Oct 2022 06:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=6ZdDTmo4+335EbBvlEmQjT8GDpny2W8EHJfskLeQgYU=; b=OM8dnY2tg5vevPKL7Mnvbt5ETiaM4d58uhREXqFxxKt0/V8KauGHkWTvb7x2Oqt0IQ aEejxhNdge0oFvaJY8CAdxgnWAgK4wSbysP8CQBrYZU3tVc/HUG18oqON1Qc4k0HyvmX xlO3nuv08QPmrsaC57vOL93rMqf5EgWpd8LoA0wI1km1qOGq2FaqvoFLcrHX61sGkweU UCD0Mp5xzvsFNg18sdEOvnJG0+cBg12+ROqA3DOYIVWuyz7cndaSK170EIJX7lh9BErx EWob7RD84FlsXzau9HMYQ7oaLWlnBSdFxt77whBg73BDOMcQkml0e3x8yR7IJXGg4cVc iYgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=6ZdDTmo4+335EbBvlEmQjT8GDpny2W8EHJfskLeQgYU=; b=n6kqmsHs5KkljSLHqndvoQYvwFSU+DqTroM42HQkNdIZS9bBSOSh5u1XsxEVwaIyN4 NTgnulLX2dGKARqO6nQUTZ3u0kJe+3YmkQ2sg7hzhBMRB7kHfxGFSz11kKJzj0nGrTXF 6oZ08R4Z5MY1fuQEGiGs2DhNymWRycZ95gkLxWbki856Ayw4JMAXmhk7WsatGXCStCr5 Kh28wYdvgm8ZyYEq9hgfMxXbrZg8h9Xjkl2G+xbzvMXah1h9AQ/lRlzz3rCKn4I+kHod GZTr9uQMh7J1LlwSS2607mm31XoH0KUeDp0BYTJ3lvFnyD2bfx9TprsDbmZVOACp24FR u1Tg== X-Gm-Message-State: ACrzQf2oS/ppGn/uLo9iSdCDlyLi4LciBWCc7rWiDgN92+7d1EHFmrMu Bl+3QaVOSvRqpIwwJezF+TT+4DewXXMxX1Vty2Y= X-Received: by 2002:a05:6402:524d:b0:459:3619:9cfa with SMTP id t13-20020a056402524d00b0045936199cfamr4749148edd.227.1665062993966; Thu, 06 Oct 2022 06:29:53 -0700 (PDT) MIME-Version: 1.0 References: <20221006092929.30041-1-jgross@suse.com> In-Reply-To: <20221006092929.30041-1-jgross@suse.com> From: Jason Andryuk Date: Thu, 6 Oct 2022 09:29:41 -0400 Message-ID: Subject: Re: [PATCH] xen/pcifront: move xenstore config scanning into sub-function To: Juergen Gross Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Stefano Stabellini , Oleksandr Tyshchenko , Bjorn Helgaas , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham 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, Oct 6, 2022 at 5:29 AM Juergen Gross wrote: > > pcifront_try_connect() and pcifront_attach_devices() share a large > chunk of duplicated code for reading the config information from > Xenstore, which only differs regarding a function call. > > Put that code into a new sub-function. While at it fix the error > reporting in case the root-xx node had the wrong format. > > As the return value of pcifront_try_connect() and > pcifront_attach_devices() are not used anywhere make those functions > return void. As an additional bonus this removes the dubious return > of -EFAULT in case of an unexpected driver state. > > Signed-off-by: Juergen Gross > --- > drivers/pci/xen-pcifront.c | 133 +++++++++++-------------------------- > 1 file changed, 40 insertions(+), 93 deletions(-) > > diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c > index 689271c4245c..a68e47dcdd7e 100644 > --- a/drivers/pci/xen-pcifront.c > +++ b/drivers/pci/xen-pcifront.c > @@ -819,76 +819,79 @@ static int pcifront_publish_info(struct pcifront_device *pdev) > err = xenbus_scanf(XBT_NIL, pdev->xdev->otherend, > "root_num", "%d", &num_roots); > if (err == -ENOENT) { > xenbus_dev_error(pdev->xdev, err, > "No PCI Roots found, trying 0000:00"); > - err = pcifront_scan_root(pdev, 0, 0); > + if (rescan) > + err = pcifront_rescan_root(pdev, 0, 0); > + else > + err = pcifront_scan_root(pdev, 0, 0); Early in pcifront_rescan_root(), we have: b = pci_find_bus(domain, bus); if (!b) /* If the bus is unknown, create it. */ return pcifront_scan_root(pdev, domain, bus); pcifront_scan_root() does some allocation, but the later scanning matches that of pcifront_rescan_root(). So I think we can just always call pcifront_rescan_root() and it should do the right thing. That drops the need for the rescan boolean. Regardless of the above idea: Reviewed-by: Jason Andryuk Regards, Jason