Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp5579973rwb; Tue, 1 Aug 2023 05:07:38 -0700 (PDT) X-Google-Smtp-Source: APBJJlEt7ufTv9KnnNErmtMnnckSFjeh7WVRT1tBdJ28hiYEGYvfDjvp9SKWonb166nKMU5RwICl X-Received: by 2002:a17:906:30d2:b0:99b:bd1e:b00 with SMTP id b18-20020a17090630d200b0099bbd1e0b00mr2143682ejb.25.1690891657967; Tue, 01 Aug 2023 05:07:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690891657; cv=none; d=google.com; s=arc-20160816; b=EtBSIwvRiPs3pWF7KCwzs4HwQh/Br7nQC5dMmEIBZUaKOR1J0vvA4ddqUUpT3J8hVL MmI9apdxOdjmlfqEDF9pLDagGXuOKuvPgY8VJ1cBrVwJEg1WW6URo5FoJ97dJ1Dfx07x UEf6aD+uf+y1OtkAYrepeQHgw2gtLEhl/UHF/U5y+pQX3Uw3C+0Jky6IVFLmqhXHB1cw hVtedM5/PO2wOMOXAD6Eilfozc76m2WBNcoYfANxF9UXaeGcumY6IdeeMH/C1K8Yiprx Ra4QXeJLLc3kbTP1FLE8/SbiHgPXVOuiskqqIYq96aafR9N5/ZneGnLOjTIbaq2xw380 BGSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=vEMsxra+LCWfLb2lt7tAakASo7B5mFasYRwIBBZPXNE=; fh=WkmwoH8TBTQFi1i+z7IMLLHsFynfURii2nTIZmnOQHQ=; b=ilSs3wUBVmW6mdQKvihwfpXBLV1Q3TpKViDXbSpNo99suKlN20Gb0QnEJ6lG4rNGwI aR1pF4F/uiyzXy46xi08Idw31YGI+nqjX5ojeudET9C7d/cmIGOIIKYy4WNElxYJh/Gf KfUMq0dsZ14amGVpOeH4xbthK4xDiBNOPGUxq+N+fgozZNzvFIPmT98NyFcDsxvUnBIz WvTwUMIZKwwJyVLg/Fmf5bj1GQUF/GBcBsu/o/OPSayggj1CRFxaR2UPqxJxyaznklbK cI3IoMf8fLNrGt3i6YQ2rUWdZUro+PxoR4wLK3tC/EobsnZf5jQSEugIbgy/QnLJKwAm 2rvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AM5Tj4kY; 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=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x7-20020a170906298700b009952c411261si8427986eje.192.2023.08.01.05.07.12; Tue, 01 Aug 2023 05:07:37 -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=@redhat.com header.s=mimecast20190719 header.b=AM5Tj4kY; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233591AbjHAJ71 (ORCPT + 99 others); Tue, 1 Aug 2023 05:59:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234086AbjHAJ7N (ORCPT ); Tue, 1 Aug 2023 05:59:13 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DB16E49 for ; Tue, 1 Aug 2023 02:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690883875; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vEMsxra+LCWfLb2lt7tAakASo7B5mFasYRwIBBZPXNE=; b=AM5Tj4kYwy+jUjFz0axbGW1HtNPHBR3T47oOzp/Cwca6VnG5eMNhjteX5pizC6raEeu+sE Q6ThrUQgH5p4Oek8M3JDCnhELMKIjYV2cE33IbgDqTgS6adsFJss+SVySxD22YHJhFGMew bJ3Sm7RIJnPo3cOptvzIbODQnrHuUF4= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-280-iIouigTRMii_ZQhzNMtnfA-1; Tue, 01 Aug 2023 05:57:54 -0400 X-MC-Unique: iIouigTRMii_ZQhzNMtnfA-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-98e40d91fdfso390048566b.3 for ; Tue, 01 Aug 2023 02:57:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690883873; x=1691488673; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vEMsxra+LCWfLb2lt7tAakASo7B5mFasYRwIBBZPXNE=; b=PmgJP/B0/VgbCCeo2LI0zD4w35llWjhop/YNd9kugGLb5l6HIBX3hGhDF6YD+Otn+f B0v/J2+Wu1J+tRUPxGwPlYoP9JHc0Zss/reiQcwBPgLBGGyTp2Ff5B/9ysY+GhImjf8N 3mmOOvLDm10Tx31Mg1cPEOX2yJGlMwH13fs2uurcpwhp4KgVlsPy615hAHxD6KINNjyS wbne08OqlaWF6+VsIYRz+9caP3Ki9POLEKhL0iSIqHwlK8N0ZrrNFHRZj+klmtRyatxc M9alNjhRGau4khn7P6x2giXxrX/71ExnOZjvoFJM1WLgOnNSoV2Epdzd/cUgRT8QZTG/ NzrA== X-Gm-Message-State: ABy/qLZm1p9cWXiot911fPdBGK8MBpCymAAV4YlYGnmWMiN/TmlxhvXg TyYTIr3v4Ur0V5ZfYK8aF97CRaUbmJFklZhMhLVcfGpU83LR0enl17ww+bXJhCrg7miZUA+Yan5 8ycOorb/lq5juDwc8hbJsk0+5 X-Received: by 2002:a17:907:a06a:b0:969:93f2:259a with SMTP id ia10-20020a170907a06a00b0096993f2259amr1931205ejc.73.1690883873174; Tue, 01 Aug 2023 02:57:53 -0700 (PDT) X-Received: by 2002:a17:907:a06a:b0:969:93f2:259a with SMTP id ia10-20020a170907a06a00b0096993f2259amr1931191ejc.73.1690883872780; Tue, 01 Aug 2023 02:57:52 -0700 (PDT) Received: from imammedo.users.ipa.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id q24-20020a17090622d800b0098d2f703408sm7351848eja.118.2023.08.01.02.57.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Aug 2023 02:57:52 -0700 (PDT) Date: Tue, 1 Aug 2023 11:57:51 +0200 From: Igor Mammedov To: "Michael S. Tsirkin" Cc: Bjorn Helgaas , linux-kernel@vger.kernel.org, terraluna977@gmail.com, bhelgaas@google.com, linux-pci@vger.kernel.org, rafael@kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH 1/1] PCI: acpiphp:: use pci_assign_unassigned_bridge_resources() only if bus->self not NULL Message-ID: <20230801115751.1e3b5578@imammedo.users.ipa.redhat.com> In-Reply-To: <20230731175316-mutt-send-email-mst@kernel.org> References: <20230731144418.1d9c2baf@imammedo.users.ipa.redhat.com> <20230731214251.GA25106@bhelgaas> <20230731175316-mutt-send-email-mst@kernel.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE 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 Mon, 31 Jul 2023 17:54:21 -0400 "Michael S. Tsirkin" wrote: > On Mon, Jul 31, 2023 at 04:42:51PM -0500, Bjorn Helgaas wrote: > > I would expect hot-add to be handled via a Bus Check to the *parent* > > of a new device, so the device tree would only need to describe > > hardware that's present at boot. That would mean pci_root.c would > > have some .notify() handler, but I don't see anything there. > > That has a big performance cost though - OSPM has no way to figure out > on which slot the new device is, so has to rescan the whole bus. > Spec says following about OSPM receiving DeviceCheck ACPI6.5r 5.6.6 Device Object Notifications) " If the device has appeared, OSPM will re-enumerate from the parent. If the device has disappeared, OSPM will invalidate the state of the device. OSPM may optimize out re-enumeration. ... If the device is a bridge, OSPM _may_ re-enumerate the bridge and the child bus. " The later statement is was added somewhere after 1.0b spec. According to debug logs when I was testing that hotplug still works I saw 're-enumerate from the parent', behavior. So there is space to optimize if there would be demand for that. And 6.5 spec has 'Device Light Check', though using that would require some ugly juggling with checking supported revisions & co which were never reliable in practice. I don't know what Windows does in that case. However if one has deep hierarchy, a BusCheck shall cause expensive deep scan. While for DeviceCheck it's optional 'may', and even that may is vague enough that one can read it as if it's 'a new bridge' then scan behind it while one can ignore existing bridge if it isn't DeviceCheck target. Regardless of that we can't just switch to BusCheck exclusively without harming existing setups which can legitimately use both methods.