On 08/05/2015 09:25 PM, Yinghai Lu wrote:
On Wed, Aug 5, 2015 at 7:22 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On 08/05/2015 06:38 PM, Yinghai Lu wrote:
On Wed, Aug 5, 2015 at 6:14 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
It only can avoid warning with bridge, and still have warning on
devices under the bridge.
also would have problem on transparent bridges, like
BRIDGE_A ---- BRIDGE_AA----DEVICE_AA
|
\-- BRIDGE_AB ---DEVICE_AB
if only BRIDGE_A and BRIDGE_AA are transparent, and BRIDGE_AB is not.
and if pci_bridge_supports_io() return false for BRIDGE_A.
We will have all three bridges have PCI_BUS_FLAGS_SUPPORTS_IO cleared.
so all will not been sized and will not get assigned io port resource.
later DEVICE_AA could root bus io port as parent, and get io resource
assigned.
but DEVICE_AB will not get assigned.
so we should get rid of pci_bridge_supports_io(), and just check root
resource IO port.
I would suggest this version instead:
Subject: [PATCH] PCI: Only try to assign io port only if root bus support
that
Bjorn had asked me to move the IO support check out of
pci_bridge_check_ranges().
It looks like you want to keep it there.
Can you explain your reasons ? Sorry, I just don't understand.
in pci_alloc_child_bus(), child bus's bus_flags will be assigned with
parent's bus_flags.
so if one parent bus has bridge's io bar can not changed, then all
children bus will also
have same bus_flags, and their bridge io bar will not used.
then if BRIDGE_AB is not transparent, we do need to use it's bridge io bar.
If I understand you correctly, we might need to change the code
in pci_read_bridge_io() as follows.
From
if (!(child->bus_flags & PCI_BUS_FLAGS_SUPPORTS_IO))
return;
to something like
if (!(child->bus_flags & PCI_BUS_FLAGS_SUPPORTS_IO)) {
if (dev->transparent)
return;
child->bus_flags |= PCI_BUS_FLAGS_SUPPORTS_IO;
}
Would that solve the problem you are concerned about ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
