linux-kernel - Re: fw_devlinks preventing a panel driver from probing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <wsg6abva53o3qxr2yycym7nubgr5rrvbmkq3oaf3zkqmmnaczs@a46rfhcxky6e>
Date: Sat, 19 Oct 2024 18:13:33 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Linux Kernel List <linux-kernel@...r.kernel.org>, 
	Saravana Kannan <saravanak@...gle.com>, Aradhya Bhatia <aradhya.bhatia@...ux.dev>, 
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, Devarsh Thakkar <devarsht@...com>
Subject: Re: fw_devlinks preventing a panel driver from probing

On Fri, Oct 04, 2024 at 02:52:24PM +0300, Tomi Valkeinen wrote:
> Hi Dmitry,
> 
> On 27/09/2024 11:35, Dmitry Baryshkov wrote:
> > On Fri, 27 Sept 2024 at 08:41, Tomi Valkeinen
> > <tomi.valkeinen@...asonboard.com> 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.

My thought was that the flag should be set before panel / DSS drivers
being probed.

-- 
With best wishes
Dmitry