linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xu Yang <xu.yang_2@nxp.com>
To: Saravana Kannan <saravanak@google.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Android Kernel Team <kernel-team@android.com>
Subject: RE: [EXT] Re: [PATCH] driver core: improve cycle detection on fwnode graph
Date: Thu, 25 Jan 2024 04:21:24 +0000	[thread overview]
Message-ID: <DU2PR04MB8822047A07680596415A61358C7A2@DU2PR04MB8822.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAGETcx9h8gA8EenyR0B0OPa23uw_8dk-Kft8c8+F3StfpyMtaw@mail.gmail.com>

Hi Saravana,

> 
> On Wed, Jan 24, 2024 at 12:40 AM Xu Yang <xu.yang_2@nxp.com> wrote:
> >
> > Currently, cycle detection on fwnode graph is still defective.
> > Such as fwnode link A.EP->B is not marked as cycle in below case:
> >
> >                  +-----+
> >                  |     |
> >  +-----+         |  +--|
> >  |     |<-----------|EP|
> >  |--+  |         |  +--|
> >  |EP|----------->|     |
> >  |--+  |         |  B  |
> >  |     |         +-----+
> >  |  A  |            ^
> >  +-----+   +-----+  |
> >     |      |     |  |
> >     +----->|  C  |--+
> >            |     |
> >            +-----+
> >
> > 1. Node C is populated as device C. But nodes A and B are still not
> >    populated. When do cycle detection with device C, no cycle is found.
> > 2. Node B is populated as device B. When do cycle detection with device
> >    B, it found a link cycle B.EP->A->C->B. Then, fwnode link B.EP->A,
> >    A->C and C->B are marked as cycle. The fwnode link C->B is converted
> >    to device link too.
> > 3. Node A is populated as device A. When do cycle detection with device
> >    A, it find A->C is marked as cycle and convert it to device link. It
> >    also find B.EP->A is marked as cycle but will not convert it to device
> >    link since node B.EP is not a device.
> 
> Your example doesn't sound correct (I'l explain further down) and it
> is vague. Need a couple of clarifications first.
> 
> 1. What is the ---> representing? Is it references in DT or fwnode
> links? Which end of the arrow is the consumer? The tail or the pointy
> end? I typically use the format consumer --> supplier.

Sorry, I represent "-->" as "supplier --> consumer" and it's a fwnode link.

> 
> 2. You say "link" sometimes but it's not clear if you mean fwnode
> links or device links. So please be explicit about it.

It’s fwnode link by default.

> 
> 3. Your statement "Such as fwnode link A.EP->B is not marked as cycle"
> doesn't sound correct. When remote-endpoint properties are parsed, the
> fwnode is created from the device node with compatible property to the
> destination. So A.EP ----> B can't exist if I assume the consumer -->
> supplier format.

The fwnode is not created from the device node with compatible property
since below commit. The endpoint node is the supplier. No, you can see my
case later.

4a032827daa8 (of: property: Simplify of_link_to_phandle(), 2023-02-06)

> 
> 4. Has this actually caused an issue? If so, what is it? And give me
> an example in an upstream DT.

Yes, there are two cycles (B.EP->A->C->B and B.EP->A/A.EP->B) in above
example. But only one cycle (B.EP->A->C->B) is recognized.

My real case as below:
---
tcpc@50 {
    compatible = "nxp,ptn5110";
    ...

    port {
        typec_dr_sw: endpoint {
            remote-endpoint = <&usb3_drd_sw>;
        };
    };    
};

usb@38100000 {
    compatible = "snps,dwc3";
    phys = <&usb3_phy0>, <&usb3_phy0>;
    ...

    port {
        usb3_drd_sw: endpoint {
            remote-endpoint = <&typec_dr_sw>;
        };
    };
};

usb3_phy0: usb-phy@381f0040 {
    compatible = "fsl,imx8mp-usb-phy";

    ...
};

And fwnode links are created as below:
---
[    0.059553] /soc@0/bus@30800000/i2c@30a30000/tcpc@50 Linked as a fwnode consumer to /soc@0/usb@32f10100/usb@38100000/port/endpoint
[    0.066365] /soc@0/usb-phy@381f0040 Linked as a fwnode consumer to /soc@0/bus@30800000/i2c@30a30000/tcpc@50
[    0.066624] /soc@0/usb@32f10100/usb@38100000 Linked as a fwnode consumer to /soc@0/usb-phy@381f0040
[    0.066702] /soc@0/usb@32f10100/usb@38100000 Linked as a fwnode consumer to /soc@0/bus@30800000/i2c@30a30000/tcpc@50/port/endpoint

> 
> Btw, I definitely don't anticipate ACKing this patch because the cycle
> detection code shouldn't be having property specific logic. It's not
> even DT specific in this place. If there is an issue and it needs
> fixing, it should be where the fwnode links are created. But then
> again I'm not sure what the actual symptom we are trying to solve is.

Sorry for the inconvenience. I saw that you push some patches about fwnode
link and device link handling, so I think you may understand this issue
well and give some suggestions.

Thanks,
Xu Yang

 


  reply	other threads:[~2024-01-25  4:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24  8:46 [PATCH] driver core: improve cycle detection on fwnode graph Xu Yang
2024-01-25  2:55 ` Saravana Kannan
2024-01-25  4:21   ` Xu Yang [this message]
2024-01-26  2:08     ` [EXT] " Saravana Kannan
2024-01-26  9:00       ` Xu Yang
2024-01-30  3:10         ` Saravana Kannan
2024-01-30  3:39           ` Xu Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DU2PR04MB8822047A07680596415A61358C7A2@DU2PR04MB8822.eurprd04.prod.outlook.com \
    --to=xu.yang_2@nxp.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=saravanak@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).