Re: fw_devlinks preventing a panel driver from probing

[Tomi Valkeinen]

Hi Dmitry,

On 27/09/2024 11:35, Dmitry Baryshkov wrote:
> On Fri, 27 Sept 2024 at 08:41, Tomi Valkeinen
> <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:
> > On 27/09/2024 02:26, Dmitry Baryshkov wrote:
> > > On Thu, Sep 26, 2024 at 02:52:35PM GMT, Tomi Valkeinen wrote:
> > > > Hi,
> > > >
> > > > On 21/09/2024 23:15, Dmitry Baryshkov wrote:
> > > > > On Mon, Sep 16, 2024 at 02:51:57PM GMT, Tomi Valkeinen wrote:
> > > > > > Hi,
> > > > > >
> > > > > > We have an issue where two devices have dependencies to each other,
> > > > > > according to drivers/base/core.c's fw_devlinks, and this prevents them from
> > > > > > probing. I've been adding debugging to the core.c, but so far I don't quite
> > > > > > grasp the issue, so I thought to ask. Maybe someone can instantly say that
> > > > > > this just won't work...
> > > > >
> > > > > Well, just 2c from my side. I consider that fw_devlink adds devlinks for
> > > > > of-graph nodes to be a bug. It doesn't know about the actual direction
> > > > > of dependencies between corresponding devices or about the actual
> > > > > relationship between drivers. It results in a loop which is then broken
> > > > > in some way. Sometimes this works. Sometimes it doesn't. Sometimes this
> > > > > hides actual dependencies between devices. I tried reverting offending
> > > > > parts of devlink, but this attempt failed.
> > > >
> > > > I was also wondering about this. The of-graphs are always two-way links, so
> > > > the system must always mark them as a cycle. But perhaps there are other
> > > > benefits in the devlinks than dependency handling?
> > > >
> > > > > > If I understand the fw_devlink code correctly, in a normal case the links
> > > > > > formed with media graphs are marked as a cycle (FWLINK_FLAG_CYCLE), and then
> > > > > > ignored as far as probing goes.
> > > > > >
> > > > > > What we see here is that when using a single-link OLDI panel, the panel
> > > > > > driver's probe never gets called, as it depends on the OLDI, and the link
> > > > > > between the panel and the OLDI is not a cycle.
> > > > >
> > > > > I think in your case you should be able to fix the issue by using the
> > > > > FWNODE_FLAG_NOT_DEVICE, which is intented to be used in such cases. You
> > > >
> > > > How would I go using FWNODE_FLAG_NOT_DEVICE? Won't this only make a
> > > > difference if the flag is there at early stage when the linux devices are
> > > > being created? I think it's too late if I set the flag when the dss driver
> > > > is being probed.
> > >
> > > I think you have the NOT_DEVICE case as the DSS device corresponds to
> > > the parent of your OLDI nodes. There is no device which corresponds to
> > > the oldi@0 / oldi@1 device nodes (which contain corresponding port
> > > nodes).
> >
> > Do you mean that I should already see FWNODE_FLAG_NOT_DEVICE set in the
> > fwnode?
>
> No, I think you should set it for you DSS links. If I understand
> correctly, this should prevent fwdevlink from waiting on the OLDI to
> materialize as a device.
> Note: my understanding is based on a quick roaming through the code
> some time ago.

Ok. Well, I did experiment with that, but I didn't figure out how to use 
it. Afaics, even if I set FWNODE_FLAG_NOT_DEVICE to the oldi nodes (just 
as an experiment I also set it to all the nodes from dss to oldi) in the 
DSS driver's probe, it doesn't help: the panel driver still doesn't probe.

I also wonder whether it would work reliably even if it did work. First 
the panel driver is prevented from probing as the oldi dependency is not 
present. Then the DSS driver probes, sets the above flag, but then it 
fails to probe as the panel is missing. At this point something should 
trigger the probing of the panel driver again, and I wonder if there's 
anything to trigger it.

 Tomi