On Thu, Oct 27, 2022 at 2:43 PM <mcpratt@xxxxx> wrote: > > > > > > Hi Michael, > > > > Thanks a lot for submitting a patch to fix issues in fw_devlink. I > > think my other patch series[1] should fix this in a generic way for > > all such cases where the phandle doesn't actually point to the > > supplier struct device. The series itself has some bugs, but there are > > "try this if it fixes it" code snippets in the thread that I need to > > roll into a v2. > > > > Give it a shot if you can. I'll try to get back to the series soon. > > > > [1] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@xxxxxxxxxx/ > > -Saravana > > Hi Saravana, > > It's definitely good to hear that someone is working on it already :D > > It looks like the "dangling consumers" function would probably fix > the issue in Openwrt with fw_devlink. However, I noticed that in your series > the function of_get_compat_node_parent() is still there. Yeah, it's there mainly for the weird/annoying "remote-endpoint" case. Annoying because it's of zero use to fw_devlink since it always causes cyclic dependency, but I also can't ignore it because the cycle could be part of other cycles (and I can't ignore those cycles). > I'm not sure whether > or not that could be simplified as well, I don't think I can -- too long to explain and I'm not feeling it right now. But it has to do with how devices are populated and being able to use that for lazily converting dependencies in DT to device links. > since that is how I got the idea > for this patch. I understand your goal is to remove the dependency on > the "compatible" properties in total (at least for supplier devices). > > I'll try the series and let you know how it goes (unless your V2 is coming soon). It's most likely not "coming soon". Kinda busy with some stuff that I can't postpone. -Saravana > > FYI the device I test this on is Engenius EPG600 (MT7620A + QCA8337) > > -- > Thanks, > MCP
