offset %u >= %pa\n",
+ }
+
+ offset = dfl_res & PCI_VNDR_DFLS_RES_OFF_MASK;
+ if (offset >= len) {
+ dev_err(&pcidev->dev, "%s bad
a+ __func__, offset, &len);
+ return -EINVAL;
+ }
+
+ dev_dbg(&pcidev->dev, "%s BAR %d offset 0x%x\n",
__func__, bar, offset);
+
+ len -= offset;
+
+ start = pci_resource_start(pcidev, bar) + offset;
+
+ dfl_fpga_enum_info_add_dfl(info, start, len);
That means everytime, we pass [start, endofbar] region to dfl core
for enumeration, if there are multiple DFLs in one bar, then each range
ends at the same endofbar, it seems fine as enumeration can be done
one by one, but ideally the best case is that this capability can provide
end address or size too, right? It is possible that information can be
added to the capability as well? then we don't have such limitation.
Hao
I am not sure having more than one DFL in a bar serves any purpose over
single DFL. Regardless, I think the consistency of just having Offset/BIR
in the VSEC is better than adding more infomation that has little or no
added value.
Agreed. Can't you just link the DFLs in that case?
I didn't see the value of more DFLs in one bar either. So I think we'd better
document it.
Yes, it needs to be documented well, otherwise users may have their own
choices, e.g. link 100 queues together by modify DFH registers of the
queues one by one, or just have them done together in the VSEC. I am not
sure which one is the easier way for logic developer, but at least we need to
document what driver can support.
Thanks
Hao
Thanks,
Yilun