From: Hollis Blanchard <hollisb@us.ibm.com>
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: linuxppc64-dev@lists.linuxppc.org, linux-kernel@vger.kernel.org
Subject: Re: PPC64: vio_find_node removal?
Date: Thu, 01 Jul 2004 17:26:12 -0500 [thread overview]
Message-ID: <1088720772.22742.21.camel@localhost> (raw)
In-Reply-To: <200407011454.55440.dtor_core@ameritech.net>
On Thu, 2004-07-01 at 14:54, Dmitry Torokhov wrote:
> kset_find_obj that is now only used by vio_find_name/vio_find_node needs to
> take kobject reference otherwise use of this function is generally unsafe.
>
> I was looking at vio_find_name users and it is only used in rpaphp hotplug
> driver. When creating a hotplug slot the function first tries to find already
> existing vio node and if unsuccessfull tries to create a new one. The only
> time when vio node would already exist if previous call to register_vio_slot
> failed (the function does not do cleanup of created vio device node and it's
> the only place where vio devices are created). So it seems to me that if
> register_vio_slot would do proper cleanup we can get rid of vio_find_name/
> vio_find_node.
At boot time, all the virtual IO devices are registered and matched with
their drivers (or not). Later on (possibly when loading a module),
rpaphp initializes. rpaphp needs a reference to the already-registered
VIO devices so that it can hotplug-remove them later by calling
vio_unregister_device().
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2004-07-01 22:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-01 19:54 PPC64: vio_find_node removal? Dmitry Torokhov
2004-07-01 22:26 ` Hollis Blanchard [this message]
2004-07-01 22:51 ` Dmitry Torokhov
2004-07-02 14:28 ` Hollis Blanchard
2004-07-04 2:27 ` Dmitry Torokhov
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=1088720772.22742.21.camel@localhost \
--to=hollisb@us.ibm.com \
--cc=dtor_core@ameritech.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@lists.linuxppc.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.