[PATCH] rpaphp.patch -- multi-function devices not handled correctly

John Rose johnrose at austin.ibm.com
Fri May 21 01:56:20 EST 2004


Hi Linda-

Nice work.  I have a couple of comments.

> Along with above changes,  I added LDRSLOT(logical I/O slot) support.
> We need LDRSLOT support for DLPAR I/O.  A card in a LDRSLOT can't
> be physically removed, but can be logically removed  from one partiton and
> reassinged to another partition.
>

This handles the case of internal or "embedded" slots, right?  It might
be more clear, both in your code and comments, to use "embedded" rather
than "logical DR".

I also think it's necessary to add a new attribute "embedded" or
"phys_removable" or whatever, that tells userspace whether physical
removal is possible.  This allows the userspace tool to say "The slot
exists, but is not hotplug capable", rather than "bad slot name".

> @@ -155,7 +158,10 @@
>  	/*  have to go through this */
>  	switch (slot->dev_type) {
>  	case PCI_DEV:
> -		retval = rpaphp_get_pci_adapter_status(slot, 0, value);
> +		if (slot->type != LDRSLOT)
> +			retval = rpaphp_get_pci_adapter_status(slot, 0, value);
> +		else
> +			retval = -EINVAL; /* n/a for LDRSLOT */
>  		break;
>  	case VIO_DEV:
>  		retval = rpaphp_get_vio_adapter_status(slot, 0, value);

I don't agree with this.  The user should still be able to check the
adapter status of an embedded slot.  You could change
rpaphp_get_pci_adapter_status() to always assume PRESENT for the
get-sensor-state call. Then check the pci_funcs list just like in the
normal case.

Another thing I noticed is that the Logical DR/embedded case is ignored
for the rpaphp_get_power_level() call.  When a user cats the power file,
it should give a valid answer for an embedded slot.  Since these slots
don't have power-domain values, and you can't turn them off, this
function should always return "POWER_ON" for these cases.

> +
> +static int is_dr_dn(struct device_node *dn, int **indexes, int **names, int **types,
> +	  int **power_domains, int **my_drc_index)
> +{
> +	if (!is_hotplug_capable(dn))
> +		return (0);
> +
> +	*my_drc_index = (int *) get_property(dn, "ibm,my-drc-index", NULL);
> +	if(!*my_drc_index)
> +		return (0);
> +
> +	if (!dn->parent)
> +		return (0);
> +
> +	return get_dn_properties(dn->parent, indexes, names, types, power_domains);
>  }

This will fail for embedded slots, right?  Embedded slots won't have
drc-indexes, types, or domains.

> -	int err = -EINVAL;
> +	int err = -EINVAL;;

Is this a typo?

> +	/* remove the devices from the pci core */
> +	list_for_each (ln, &slot->dev.pci_funcs) {
> +		struct rpaphp_pci_func *func;
> +
> +		func = list_entry(ln, struct rpaphp_pci_func, sibling);
> +		if (func->pci_dev) {
> +			rpaphp_eeh_remove_bus_device(func->pci_dev);
> +			pci_remove_bus_device(func->pci_dev);
> +		}

list_for_each() isn't safe to use when removing members of the list in
question.  There are functions list_for_each_safe() and/or
list_for_each_entry_safe() that address this problem.

> -
> +	/* should not try to register the same slot twice */
> +	if (is_registered(slot)) { /* should't be here */
> +		err("register_slot: slot[%s] is already registered\n", slot->name);
> +		rpaphp_release_slot(slot->hotplug_slot);
> +		return (1);
> +	}

Good idea, this will save us alot of headaches :)


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc64-dev mailing list