On Wed, Jul 02, 2025 at 11:19:36AM -0400, Frank Li wrote:
On Wed, Jul 02, 2025 at 08:25:17PM +0530, Manivannan Sadhasivam wrote:
On Wed, Jul 02, 2025 at 10:40:53AM GMT, Frank Li wrote:
On Wed, Jul 02, 2025 at 04:30:48PM +0530, Manivannan Sadhasivam wrote:
On Mon, Jun 09, 2025 at 12:34:13PM GMT, Frank Li wrote:
Set device ID as 'vfunc_no << 3 | func_no' and use 'device_set_of_node_from_dev()' to set 'of_node' the same as the EPC parent device.
Currently, EPF 'of_node' is NULL, but many functions depend on 'of_node' settings, such as DMA, IOMMU, and MSI. At present, all DMA allocation functions use the EPC's device node, but they should use the EPF one. For multiple function drivers, IOMMU/MSI should be different for each function driver.
We don't define OF node for any function, so device_set_of_node_from_dev() also ends up reusing the EPC node. So how can you make use of it in multi EPF setup?
In mfd devices, children devices reuse parent's of_node drivers/gpio/gpio-adp5585.c drivers/input/keyboard/adp5589-keys.c drivers/pwm/pwm-adp5585.c
multi EPF should be similar to create multi children devices of mfd.
No, they are not similar. MFD are real physical devices, but EPFs are (so far) software based entities.
I don't understand.
If multiple function devices share the same EPC device, there will be no isolation between them. Setting the ID and 'of_node' prepares for proper support.
Only share the same of_node.
Actually pci host bridge have similar situation, all pci ep devices reuse bridge's of node. framework use rid to distringuish it. EPF can use device::id to do similar things.
Actually iommu face the similar problem. So far, there are not EP device enable iommu yet, because it needs special mapping.
Prevously, I consider create dymatic of_node for each EPF and copy iommu/msi information to each children. But when I see adp5585 case, I think direct use parent's of_node should be simple and good enough.
In future, I suggest add children dt binding for it. For example: EPF provide a mailbox interface. how other dts node to refer to this mailbox's phandle?
As I said above, EPFs are not real devices. There is currently only one exception, MHI, which is backed by a hardware entity. So we cannot add devicetree nodes for EPF, unless each EPF is a hardware entity.
But how resolve this problem, if a DT device need phandle to a EPF? anyway this is off topic. let go back this doorbell.
It needs an of_node for EPF device, I tried many method before.
Create dymatic of_node for it? MSI framework still go through to parent of_node to get such information. not big differnece as my view.
Actually, DMA have simular issues, just 'workaround' it now.
pci_epf_test_read() { ... struct device *dma_dev = epf->epc->dev.parent; ... dst_phys_addr = dma_map_single(dma_dev, buf, map_size, DMA_FROM_DEVICE); ^^^ [1] ... }
[1] here direct use epc->dev.parent's of node implicy. If IOMMU enable, two EPF will share one IOMMU space without isolation. If add of_node(may dyamatic create one). we should resolve this problem by use epf device here. Difference EPF will use difference IOMMU space like MSI.
Frank
Frank
- Mani
-- மணிவண்ணன் சதாசிவம்