On 12/31/20 2:40 PM, Chuck Tuffli wrote: > On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan <n...@neelc.org> wrote: >> >> Hi Chuck, >> >> On 2020-12-30 10:04, Chuck Tuffli wrote: >>> What is the output from >>> # pciconf -rb pci0:0:14:0 0x40:0x48 >> >> The output is: >> >> 01 00 00 00 01 2e 68 02 00 > > Perfect. The Linux driver says the 8086:9a0b device you have "... may > provide root port configuration information which limits bus > numbering" which causes the code to read the VM Capability register > (0x40) and the VM Configuration register (0x44). Here, VMCAP = 0x0001 > where bit 0 set appears to mean the config register has starting bus > number information. VMCFG = 0x2e01 where bits 5:4 give the coded start > number of bus 224 or 0xe0 which matches the PCI bridge shown in the > lspci output (i.e. 10000:e0:06.0). > > I wonder if mirroring the logic in [1] and setting > bus->rman.rm_start = 224; > in vmd_attach() might help. > >> I was also able to stop kernel panics by adding: >> >> rman_fini(&sc->vmd_bus.rman); >> >> In the fail: statement in vmd_attach(). >> >> But I still cannot detect the SSD. > > [1] > https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L507
You will also need to subtract that starting bus number from the bus number used to compute the offset into the PCI-express region for config register read/write as this code does: https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L339 Also, that means the vm_bus.c can't hardcode reading from bus 0. Instead, vmd(4) might need to export an IVAR to vmd_bus(4) that is the starting bus number and vm_bus needs to use that instead of hardcoding 0. -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
