[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230801085131-mutt-send-email-mst@kernel.org>
Date: Tue, 1 Aug 2023 08:57:57 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Igor Mammedov <imammedo@...hat.com>
Cc: Bjorn Helgaas <helgaas@...nel.org>, linux-kernel@...r.kernel.org,
terraluna977@...il.com, bhelgaas@...gle.com,
linux-pci@...r.kernel.org, rafael@...nel.org,
linux-acpi@...r.kernel.org
Subject: Re: [PATCH 1/1] PCI: acpiphp:: use
pci_assign_unassigned_bridge_resources() only if bus->self not NULL
On Tue, Aug 01, 2023 at 11:57:51AM +0200, Igor Mammedov wrote:
> On Mon, 31 Jul 2023 17:54:21 -0400
> "Michael S. Tsirkin" <mst@...hat.com> 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.
Yes I was talking about unplug.
> 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.
And it's very clear that it's more efficient for removal.
> Regardless of that we can't just switch to BusCheck exclusively
> without harming existing setups which can legitimately use both
> methods.
--
MST
Powered by blists - more mailing lists