linux-kernel - Re: [PATCH] of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing

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]

Date: Mon, 25 Mar 2024 15:49:44 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: John Watts <contact@...kia.org>
Cc: Rob Herring <robh+dt@...nel.org>, Frank Rowand <frowand.list@...il.com>, 
	Hervé Codina <herve.codina@...tlin.com>, 
	Luca Ceresoli <luca.ceresoli@...tlin.com>, kernel-team@...roid.com, 
	Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: property: fw_devlink: Fix stupid bug in
 remote-endpoint parsing

On Sat, Mar 23, 2024 at 5:20 AM John Watts <contact@...kia.org> wrote:
>
> Hello again,
>
> On Fri, Mar 22, 2024 at 06:53:57PM -0700, Saravana Kannan wrote:
> > Hmmm.... cycle detection should work here and not enforce probe
> > ordering. I'd appreciate help with debugging that. Let me look at it
> > on Monday. Can you enabled all the debug logs in drivers/base/core.c
> > and tell me what cycle detection is telling about these nodes?
>
> Hmm. It's not saying anything more than what I've already sent.

Sorry, I was asking for the logs. But now I'm looking at this again, I
think I understand what's going on.

> I think this is because /sound/multi isn't a device, it's just a
> subnode used in audio-graph-card2.

Ok, I think I understand now what's going on. fw_devlink does not know
that "sound" device will not populate "multi" as a child device.
Typically in such situations, "sound" would probe as a device and add
its child DT nodes devices. At that point, the cycle is only between
"multi" and "test_codec" and fw_devlink will detect that and not
enforce any ordering. However, in this case, "sound" doesn't have any
child devices and just depends on the remote endpoints directly.

We already have "ports", "in-ports" and "out-ports". Is there a reason
none of them will work for your use case and it has to be "multi"?
When you use one of those 3 recognized node names, things are handled
correctly.

Btw, between "test_codec" and "sound", which one is supposed to probe
first? I'm guessing "test_codec" needs to probe first for "sound" to
probe?

> Removing the multi { } section and using direct graph connections
> 'fixes' this.

I think the right fix is the use of post-init-providers. Because even
if you do the above, all it does is let fw_devlink see that there's a
cyclic dependency in DT. And it'll stop enforcing the probe and
suspend/resume ordering. Ideally we want to enforce a specific order
here. test_codec first and then sound.

> I think this might be because usually in a graph each node containing
> ports is a device, such as a display panel, a bridge, an LCD
> controller. These kind of form a dependency chain.
>
> In this case all the ports in multi act as a way to glue multiple
> ports together for the audio-graph-card2.
>
> Does that help?

Maybe. But the logs would be more helpful.

>
> > But the better fix would be to use the new "post-init-providers"
> > property. See below.
> >
> > >
> > > / {
> > >         ...
> > >
> > >
> > >         test_codec {
> > >                 compatible = "test-codec";
> > >                 prefix = "Test codec";
> > >                 #sound-dai-cells = <0>;
> >
> > post-init-provider = <&multi>;

Did you try this? Did it help?

-Saravana

> >
> > Right now there's a cyclic dependency between test_codec and multi and
> > this tells the kernel that test codec needs to probe first.
> >
> > Similar additions to the other nodes blocked on multi.
> >
> > Thanks,
> > Saravana
>
> John.