lkml.org 
[lkml]   [2004]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PPC64: vio_find_node removal?
Date
On Thursday 01 July 2004 05:26 pm, Hollis Blanchard wrote:
> 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().
>

Ah, I see.. I missed the call to vio_register_device_node in
probe_bus_pseries...

Ok, so if we add call to kobject_get in kset_find_obj we can just add
kobject_put right in vio_find_name because there can be only one-to-one
match between a slot and a vio device and we don't need refcounting there,
right?

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.824 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site