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.
Hi, any idea? how to move forward? we can dynmatic create of_node for it. Frank > > Frank > > > > > - Mani > > > > -- > > மணிவண்ணன் சதாசிவம்
