From: Pavan Kondeti <quic_pkondeti@quicinc.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Zhenhua Huang <quic_zhenhuah@quicinc.com>, <rafael@kernel.org>,
<linux-kernel@vger.kernel.org>, <quic_pkondeti@quicinc.com>,
<quic_tingweiz@quicinc.com>, <saravanak@google.com>
Subject: Re: [RESEND PATCH] driver core: Clear FWNODE_FLAG_LINKS_ADDED in device_links_purge()
Date: Thu, 5 Oct 2023 16:19:44 +0530 [thread overview]
Message-ID: <50508cf9-fd4f-4199-9df3-e42ebb489499@quicinc.com> (raw)
In-Reply-To: <2023100501-entourage-bounce-3364@gregkh>
On Thu, Oct 05, 2023 at 11:32:22AM +0200, Greg KH wrote:
> On Wed, Sep 27, 2023 at 10:30:10AM +0800, Zhenhua Huang wrote:
> > Flag FWNODE_FLAG_LINKS_ADDED stops fwnode links creation. Current kernel
> > only adds it once after fwnode links creation in fw_devlink_parse_fwnode().
> > After that even device links being purged, the flag will not be cleared.
> >
> > Fwnode links are converted to device links and will not be added back
> > forever in normal case. Essentially if a device is registered and
> > unregisted (also deleted) before it is probed (due to missing fwlink
> > dependencies, abort in device_links_check_suppliers), the fwlink is not
> > setup next when device is newly created again. This means the probe gets
> > called without meeting all dependencies.
> >
> > It usuallly happens in the case of a glue driver.
>
> What exact glue driver is causing this to happen? Why can't we fix that
> up instead?
>
Yes, we are looking at fixing the glue driver and/or the probe order of drivers
involed by controlling modules load order. To answer your question,
It is observed with dwc3-qcom on a downstream kernel based on
Android GKI 6.1 kernel.
usb_1: usb@a6f8800 {
...
usb_1_dwc3: usb@a600000 {
compatible = "snps,dwc3";
iommus = <&apps_smmu 0x40 0x0>;
...
};
};
The parent device has no dependency on IOMMU but the child has
dependency. The parent probe gets called before IOMMU is probed.
The parent glue driver adds the child device and removes it since its
probe is not completed. Once the child is unregistered, all the fwlinks
are lost. Next time when the child is added, its probe gets called
before IOMMU is ready (since the fwlinks are lost).
Thanks,
Pavan
prev parent reply other threads:[~2023-10-05 16:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 2:30 Zhenhua Huang
2023-09-27 5:57 ` Greg KH
2023-09-27 6:32 ` Zhenhua Huang
2023-09-27 8:08 ` Greg KH
2023-09-27 5:57 ` Greg KH
2023-09-27 6:34 ` Zhenhua Huang
2023-09-27 8:08 ` Greg KH
2023-09-27 9:53 ` Zhenhua Huang
2023-10-02 21:40 ` Saravana Kannan
2023-10-03 3:34 ` Pavan Kondeti
2023-10-05 9:32 ` Greg KH
2023-10-05 10:49 ` Pavan Kondeti [this message]
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=50508cf9-fd4f-4199-9df3-e42ebb489499@quicinc.com \
--to=quic_pkondeti@quicinc.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_tingweiz@quicinc.com \
--cc=quic_zhenhuah@quicinc.com \
--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
all inboxes | Powered by JetHome®