[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebc07a1b-dbf6-40d9-8f62-03d58e4b3038@quicinc.com>
Date: Tue, 3 Oct 2023 09:04:20 +0530
From: Pavan Kondeti <quic_pkondeti@...cinc.com>
To: Saravana Kannan <saravanak@...gle.com>
CC: Zhenhua Huang <quic_zhenhuah@...cinc.com>,
<gregkh@...uxfoundation.org>, <rafael@...nel.org>,
<linux-kernel@...r.kernel.org>, <quic_pkondeti@...cinc.com>,
<quic_tingweiz@...cinc.com>
Subject: Re: [RESEND PATCH] driver core: Clear FWNODE_FLAG_LINKS_ADDED in
device_links_purge()
On Mon, Oct 02, 2023 at 02:40:52PM -0700, Saravana Kannan wrote:
>
> > It usuallly happens in the case of a glue driver. Of_platform_populate()
> > allows us to populate subnodes. We may do it in ancestor node probing
> > function, then check subnode's probing status because there may be chances
> > that suppliers of subnode are not ready. We may further need to do
> > of_platform_depopulate(which purges device links) and in some time
> > of_platform_populate() again. Such case we miss fwnode links(so that device
> > links) during second time of populating subnodes.
>
> Why is the device driver for the parent device adding the child
> devices before it knows it can finish probing? Adding the child
> devices should be the last thing you do as part of your probe.
>
Is there a way how a parent device driver can know if the dependencies
of its child are met before registering the device?
Does it make sense to treat the child dependencies as parent (if it
opts) dependencies in the firmware device links? Not every child may be needed
for the parent to operate but some devices which are glue devices (SoC
specific) for children (say 3rd party IP or generic devices) would
definitely want to know if their children are ready for probe.
Thanks,
Pavan
Powered by blists - more mailing lists