A large number of the comments made before were solved with the latest changeset (3). Please review this changeset, it is no longer specific to thunderbolt 3 devices but encompases any PCI express hotplug bridges.
Patch Set #1, Line 1:
USB4 is the new hotness. […]
Patch Set #1, Line 25:
static void slot_dev_read_resources(struct device *dev)
that code should be shared with the existing southbridge code.
Patch Set #1, Line 30:
These should be using the PCI macros for the registers.
Patch Set #1, Line 31:
1 << 28
256 * MiB
Patch Set #1, Line 33:
resource->gran = 22;
Where did the alignment come from?
Patch Set #1, Line 51:
resource->flags |= IORESOURCE_IO;
sounds good to me
Patch Set #1, Line 59:
return PCI_SLOT(dev->path.pci.devfn) == 1;
What does the device tree look like to support this device? I assume this is the router? Are there m […]
Patch Set #1, Line 69:
dev->hotplug_buses = 32;
I also like the hotplug_buses approach and it's rather noninvasive
might be worth putting this into the device tree and only defaulting to 32 when there's no setting i […]
Patch Set #1, Line 73:
That's assuming thunderbolt links are already provisioned and pcie tunneling is happening. […]
Patch Set #1, Line 80:
slot = alloc_dev(dev->link_list, &slot_path);
> IIRC the 256MiB was what the vendor firmware does; not sure if this is mandated by the TB spec. […]
Patch Set #1, Line 93:
.init = 0,
Patch Set #1, Line 94:
.scan_bus = tbt_pciexp_scan_bridge,
I believe thunderbolt and usb4 controllers need to export capabilities in pci config space. […]
Patch Set #1, Line 95:
.enable = 0,
Patch Set #1, Line 102:
move to pci_ids. […]
To view, visit change 35946. To unsubscribe, or for help writing mail filters, visit settings.