From: Bjorn Helgaas <helgaas@kernel.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: linux-kernel@vger.kernel.org, terraluna977@gmail.com,
bhelgaas@google.com, linux-pci@vger.kernel.org, mst@redhat.com,
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
Date: Fri, 4 Aug 2023 18:27:09 -0500 [thread overview]
Message-ID: <20230804232709.GA174043@bhelgaas> (raw)
In-Reply-To: <20230726123518.2361181-2-imammedo@redhat.com>
On Wed, Jul 26, 2023 at 02:35:18PM +0200, Igor Mammedov wrote:
> Commit [1] switched acpiphp hotplug to use
> pci_assign_unassigned_bridge_resources()
> which depends on bridge being available, however in some cases
> when acpiphp is in use, enable_slot() can get a slot without
> bridge associated.
acpiphp is *always* in use if we get to enable_slot(), so that doesn't
really add information here.
> 1. legitimate case of hotplug on root bus
> (likely not exiting on real hw, but widely used in virt world)
> 2. broken firmware, that sends 'Bus check' events to non
> existing root ports (Dell Inspiron 7352/0W6WV0), which somehow
> endup at acpiphp:enable_slot(..., bridge = 0) and with bus
> without bridge assigned to it.
IIUC, the Inspiron problem happens when:
- acpiphp_context->bridge is NULL, so hotplug_event() calls
enable_slot() instead of acpiphp_check_bridge(), AND
- acpiphp_slot->bus->self is also NULL, because enable_slot() calls
pci_assign_unassigned_bridge_resources() with that NULL pointer,
which dereferences "bridge->subordinate"
But I can't figure out why acpiphp_context->bridge is NULL for RP07
and RP08 (which don't exist), but not for RP03 (which does).
I guess all the acpiphp_contexts (RP03, RP07, RP08) must be allocated in
acpiphp_add_context() by acpiphp_init_context().
Woody's lspci from [1] shows only one Root Port:
00:1c.0 Wildcat Point-LP PCI Express Root Port #3
The DSDT.DSL includes:
Device (RP01) _ADR 0x001C0000 # 1c.0
Device (RP02) _ADR 0x001C0001 # 1c.1
Device (RP03) _ADR 0x001C0002 # 1c.2
Device (RP04) _ADR 0x001C0003 # 1c.3
Device (RP05) _ADR 0x001C0004 # 1c.4
Device (RP06) _ADR 0x001C0005 # 1c.5
Device (RP07) _ADR 0x001C0006 # 1c.6
Device (RP08) _ADR 0x001C0007 # 1c.7
I can see why we might need a Bus Check after resume to see if
something got added while we were suspended. But I don't see why we
handle RP03 differently from RP07 and RP08.
Can you help me out? I'm lost in a maze of twisty passages, all
alike.
Bjorn
[1] https://lore.kernel.org/r/92150d8d-8a3a-d600-a996-f60a8e4c876c@gmail.com
next prev parent reply other threads:[~2023-08-04 23:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 12:35 [PATCH 0/1] PCI: acpiphp: fix regression introduced by 'Reassign resources on bridge if necessary' Igor Mammedov
2023-07-26 12:35 ` [PATCH 1/1] PCI: acpiphp:: use pci_assign_unassigned_bridge_resources() only if bus->self not NULL Igor Mammedov
2023-07-26 14:24 ` Rafael J. Wysocki
2023-07-27 6:04 ` Michael S. Tsirkin
2023-07-27 17:41 ` Bjorn Helgaas
2023-07-28 9:32 ` Igor Mammedov
2023-07-29 21:50 ` Bjorn Helgaas
2023-07-31 12:44 ` Igor Mammedov
2023-07-31 21:42 ` Bjorn Helgaas
2023-07-31 21:54 ` Michael S. Tsirkin
2023-08-01 9:57 ` Igor Mammedov
2023-08-01 12:57 ` Michael S. Tsirkin
2023-08-04 14:11 ` Igor Mammedov
2023-07-31 12:46 ` [PATCH QEMU] acpiphp: hack to send BusCheck to missing device on root bus Igor Mammedov
2023-08-04 23:27 ` Bjorn Helgaas [this message]
2023-08-07 13:07 ` [PATCH 1/1] PCI: acpiphp:: use pci_assign_unassigned_bridge_resources() only if bus->self not NULL Igor Mammedov
2023-08-07 17:28 ` Bjorn Helgaas
2023-08-08 11:47 ` Igor Mammedov
2023-08-08 9:25 ` Michal Koutný
2023-08-08 19:35 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230804232709.GA174043@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=imammedo@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mst@redhat.com \
--cc=rafael@kernel.org \
--cc=terraluna977@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.