Hi Miquel,
Thanks for taking a look at what I have so far.
On Monday, February 5th, 2024 at 10:00, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
>
>
> Hi Michael,
>
> mcpratt@xxxxx wrote on Tue, 23 Jan 2024 01:46:40 +0000:
>
> > If a fwnode is flagged as FWNODE_FLAG_NOT_DEVICE
> > by the time a device link is to be made with it,
> > but not flagged as FWNODE_FLAG_PARENT_IS_DEV,
> > the link is dropped, otherwise the device link
> > is still made with the original supplier fwnode.
> > Theoretically, we can also handle linking to an ancestor
> > of the supplier fwnode when forming device links, but there
> > are still cases where the necessary fwnode flags are still missing
> > because the real supplier device did not probe yet.
>
>
> I am not sure I follow this. In the following case, I would expect any
> dependency towards node-c to be made against node-a. But the above
> paragraph seems to tell otherwise: that the link would be dropped
> (and thus, not enforced) because recursively searching for a parent
> that would be a device could be endless? It feels wrong, so I probably
> mis
>
> node-a {
> # IS DEV
> node-b {
> # PARENT IS DEV
> node-c {
> # PARENT IS DEV
> };
> };
>};
>
> Besides that, the commit feels like a good idea.
The link is dropped _in order to_ make the dependency towards node-c
become a dependency towards node-a instead.
The "recursive searching" happens after links are dropped in order to
create the new fwnode links, and it depends on the new flag
being placed when the supplier device (node-a) probes, which can happen
before the links are re-attempted, or after a single probe defer of the consumer.
I placed all the logic that decides whether to drop links and retry linking
to the consumer immediately before a probe defer of the consumer would occur.
That logic could be distributed around multiple functions for fw_devlink,
but I'm concerned about false positives. The only reason I didn't use or make
a new function in order to "move" the links is that in this position in the driver core
which I believe is the right place to do the fixup function, we don't have direct access
to the fwnode that the links should go to, it would have to be discovered by recursively
walking up the tree looking for the flag in the new fixup function
instead of where the fwnode links are made.
To me, it doesn't matter which order we call the functions,
but if we are starting with fwnode links that refuse
to be converted to device links, we need to do more than just move the fwnode links
because after a probe defer there is no hook to automatically try switching them
to device links again. Driver core expects that to have already happened by then.
I imagine that without having to add a lot more code in a lot of places,
I would have to call fw_devlink_link_device() after "moving" links anyway...
It's possible to call that function only when the bad link is still a fwnode_link
and do a "move" function when the bad link is a device_link, that is,
if "moving" a finished device_link is possible or good practice at all
since it would be skipping quite a few checks that occur before a device_link is made.
It seems to me that making a device_link is a multiple-step process, so a new function
to only move the supplier of a device_link might be a big one as well.
I tend to try to reuse as many core functions as I could.
>
> Thanks,
> Miquèl
--
MCP
