About config file posting: Perhaps you could rename the configs with a “.txt” or “.rtf” extension first, and then attach them instead of pasting as a code block. Or, maybe use the “zip” program to compress if direct “.txt” file attach fails (I’d use bzip2 instead, but I don’t know if the forum spam filters allow that file extension to be attached…it’s a question of what the spam filters allow as a file attachment type…file name suffix matters for that purpose). If you own a post which already exists you can hover your mouse over the upper right corner’s “quote” icon and you’ll also see a paper clip icon…the paper clip icon lets you attach files to your preexisting post.
The PCIe has its own driver; if that driver works and enumerates a PCIe device, then it is possible for the device to continue. Enumeration is the process of taking notes on what is plugged in, and presenting a description of the device to the next stage. lspci describes what was enumerated.
If the device on PCIe is a USB HUB, the PCIe enumeration will result in USB drivers then getting a chance to claim ownership of the USB portion of the hardware (PCIe drivers told USB drivers about this device during enumeration). If a driver knows it can handle the HUB, then it will take ownership of the HUB and the HUB will work. lsusb shows which HUBS are seen, and what devices were enumerated for the next stage to work with.
If a device is plugged into USB by this HUB, then an event will be generated during enumeration; this will in turn offer any device drivers a chance to take ownership of whatever device is behind the USB pipe. If and only if a driver answers and binds to the device behind the USB pipe will the device work. lsusb can show an end device which has no driver…USB does not care if enumeration found a driver or not.
You have a chain of drivers and events to announce hardware, and if any fails, the end device fails. It is a chain of drivers, enumeratons, and new drivers being appended as the next link in the chain; this keeps going until reaching the endpoint of the chain (the final device). The chain can be left dangling without the end device having a driver, yet the previous stages are working 100%.
The kernel config is to know that drivers are present and able to take ownership of their respective devices when enumeration announces something present. Some devices are only cold-plug, and must be present upon power up to enumerate; other devices are hot-plug, and can enumerate as added (plus they have a graceful removal). If USB end devices have a driver, then the USB enumeration should have resulted in the driver loading and taking ownership of the end device, along with all of the side effects (e.g., creating a device special file or being available in some configuration). Specific end device enumeration behavior depends on the specific driver.
One cause of a failure is lack of a driver (see kernel config…a successful enumeration does not matter if there is no driver). Another cause of failure is insufficient signal quality (perhaps cables too long, power delivery insufficient quality, so on). The last category of failure would be failure to enumerate because of power up order (power on sequence matters if not hot plug; hot plug prior to a driver being available would also fail enumeration, so even hot plug has prerequisites, though it would be rare for this to occur).