Jens Stroebel wrote: > Bryan Kadzban wrote: >> I'd like to see the results of: > >> grep -H . <stuff> > > <stuff>
OK, so it looks like the top-level device is an Intel (0x8086) "82801 mobile PCI bridge" (0x2448); I suspect that device is a PCI->miniPCI bridge, but I'm not quite sure. Anyway, next in line is an O2 Micro (0x1217) Cardbus bridge (0x7135). Next is an Abocom Systems (0x13d1) RTL8139 Cardbus NIC (0xab06). (And it turns out that the subvendor/subdevice didn't matter in any of these cases, but I figured it'd be better to ask and not need them than need them and not ask. :-) ) Still surprises me a bit that Cardbus/PCMCIA are similar enough to PCI that they don't show up as a separate type of bus -- but it does look like path_id (with the patch) can handle this layout. Also, after recreating most of this sysfs tree in a test directory on my machine and running the patched path_id against it, I see that the ID that gets printed is just "pci-0000:04:00.0" -- so it doesn't look like path_id cares what's higher in the tree. However, then I realized that the PCI location IDs are unique across a machine anyway: that's why the second field is the bus number. Your PCMCIA NIC is device 0, function 0, on bus 4 (and domain 0000): so long as that doesn't change, it'll work fine. (I should note that my current motherboard does some strange things with PCI bus numbers, though. If my onboard SATA2 chip is disabled in the BIOS, then the AGP bus is bus number 3 (PCIe takes buses 1 and 2, and yes it has both). If the SATA2 chip is turned on, then another PCIe bus is created at number 3, the SATA2 chip is put on that bus, and the AGP bus moves to 4. Hopefully these laptops don't do anything similar.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
