From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Daniel Scally <djrscally@gmail.com>,
Felipe Balbi <balbi@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2 1/3] software node: Introduce device_add_software_node()
Date: Thu, 14 Jan 2021 16:24:15 +0200 [thread overview]
Message-ID: <20210114142415.GC2864731@kuha.fi.intel.com> (raw)
In-Reply-To: <20210114131948.GA2864731@kuha.fi.intel.com>
On Thu, Jan 14, 2021 at 03:19:52PM +0200, Heikki Krogerus wrote:
> On Wed, Jan 13, 2021 at 05:30:03PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 13, 2021 at 01:39:18PM +0200, Heikki Krogerus wrote:
> > > On Wed, Jan 13, 2021 at 12:40:03AM +0000, Daniel Scally wrote:
> > > > On 11/01/2021 14:10, Heikki Krogerus wrote:
> >
> > ...
> >
> > > > > +/**
> > > > > + * device_remove_software_node - Remove device's software node
> > > > > + * @dev: The device with the software node.
> > > > > + *
> > > > > + * This function will unregister the software node of @dev.
> > > > > + */
> > > > > +void device_remove_software_node(struct device *dev)
> > > > > +{
> > > > > + struct swnode *swnode;
> > > > > +
> > > > > + swnode = dev_to_swnode(dev);
> > > > > + if (!swnode)
> > > > > + return;
> > > > > +
> > > > > + kobject_put(&swnode->kobj);
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(device_remove_software_node);
> > > >
> > > > I wonder if this also ought to set dev_fwnode(dev)->secondary back to
> > > > ERR_PTR(-ENODEV)?
> >
> > Actually it's a good question.
> >
> > > We can't do that here unfortunately. Other places still have a
> > > reference to the swnode at this point and they may still need to
> > > access it using the dev_fwnode(dev)->secondary pointer.
> >
> > Yeah, but in this case we potentially leave a dangling pointer when last of the
> > user gone and kobject_put() will call for release.
>
> The caller has to be responsible of setting the secondary back to
> ERR_PTR(-ENODEV). We can not do anything here like I explained. We can
> not even do that in software_node_notify() when the association to the
> struct device is removed, because the fwnode->secondary is still
> accessed after that. The caller needs to remove both the node and the
> device, and only after that it is safe to set the secondary back to
> ERR_PTR(-ENODEV).
I studied the code again, and it actually looks like this is only a
problem when device_add_properties() is used and there is an
expectation that the node/properties are removed automatically in
device_del().
When this new API is used, the only place that needs to access the
swnode using the secondary pointer is software_node_notify(), so if we
simply handle that separately here, we should be able to clear the
secondary pointer after all. It would look something like this:
void device_remove_software_node(struct device *dev)
{
struct swnode *swnode;
swnode = dev_to_swnode(dev);
if (!swnode)
return;
software_node_notify(dev, KOBJ_REMOVE);
set_secondary_fwnode(dev, NULL);
kobject_put(&swnode->kobj);
}
I'll test that, and if it works, and you guys don't see any problems
with it, I'll use it in v3.
Br,
--
heikki
next prev parent reply other threads:[~2021-01-14 14:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 14:10 [PATCH v2 0/3] Remove one more platform_device_add_properties() call Heikki Krogerus
2021-01-11 14:10 ` [PATCH v2 1/3] software node: Introduce device_add_software_node() Heikki Krogerus
2021-01-13 0:40 ` Daniel Scally
2021-01-13 11:39 ` Heikki Krogerus
2021-01-13 15:30 ` Andy Shevchenko
2021-01-14 13:19 ` Heikki Krogerus
2021-01-14 14:24 ` Heikki Krogerus [this message]
2021-01-13 15:55 ` Andy Shevchenko
2021-01-13 15:58 ` Andy Shevchenko
2021-01-14 14:00 ` Heikki Krogerus
2021-01-11 14:10 ` [PATCH v2 2/3] usb: dwc3: pci: Register a software node for the dwc3 platform device Heikki Krogerus
2021-01-11 14:10 ` [PATCH v2 3/3] usb: dwc3: pci: ID for Tiger Lake CPU Heikki Krogerus
2021-01-12 8:46 ` [PATCH v2 0/3] Remove one more platform_device_add_properties() call Felipe Balbi
2021-01-12 11:49 ` Greg KH
2021-01-15 15:01 ` Greg KH
2021-01-15 15:05 ` Greg KH
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=20210114142415.GC2864731@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=balbi@kernel.org \
--cc=djrscally@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/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