Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch

[John Baldwin]

On 12/31/20 2:40 PM, Chuck Tuffli wrote:
> On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan <neel at 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