Re: [PATCH v2 2/4] pciehp: Use link change notifications for hot-plugand removal

[Rajat Jain]

On 12/05/2013 01:07 AM, Yijing Wang wrote:
> 
> handle_link_up_event() and handle_link_down_event() are almost the same,
> what about use like:
> handle_link_state_change_event(p_slot, event) to reuse the the common code ?
> 
>

Sure, I can combine both of them to make it look more like this. Let me know
it this looks all right.

static void handle_link_event(struct slot *p_slot, unsigned int req)
{
	struct controller *ctrl = p_slot->ctrl;
	struct power_work_info *info;

	info = kmalloc(sizeof(*info), GFP_KERNEL);
	if (!info) {
		ctrl_err(p_slot->ctrl, "%s: Cannot allocate memory\n",
			 __func__);
		return;
	}
	info->p_slot = p_slot;
	info->req = req;
	INIT_WORK(&info->work, pciehp_power_thread);

	switch (p_slot->state) {
	case BLINKINGON_STATE:
	case BLINKINGOFF_STATE:
		cancel_delayed_work(&p_slot->work);
		/* Fall through */
	case STATIC_STATE:
		if (req == ENABLE_REQ)
			p_slot->state = POWERON_STATE;
		else
			p_slot->state = POWEROFF_STATE;

		queue_work(p_slot->wq, &info->work);
		break;
	case POWERON_STATE:
		if (req == ENABLE_REQ) {
			ctrl_info(ctrl,
				  "Link Up ignored on slot(%s): already powering on\n",
				  slot_name(p_slot));
			kfree(info);
		} else {
			ctrl_info(ctrl,
				  "Link Down queued on slot(%s): currently getting powered on\n",
				  slot_name(p_slot));
			p_slot->state = POWEROFF_STATE;
			queue_work(p_slot->wq, &info->work);
		}
		break;
	case POWEROFF_STATE:
		if (req == ENABLE_REQ) {
			ctrl_info(ctrl,
				  "Link Up queued on slot(%s): currently getting powered off\n",
				  slot_name(p_slot));
			p_slot->state = POWERON_STATE;
			queue_work(p_slot->wq, &info->work);
		} else {
			ctrl_info(ctrl,
				  "Link Down ignored on slot(%s): already powering off\n",
				  slot_name(p_slot));
			kfree(info);
		}
		break;
	default:
		ctrl_err(ctrl, "Not a valid state on slot(%s)\n",
			 slot_name(p_slot));
		kfree(info);
		break;
	}
}

Bjorn: was wondering if you'd able to take a look at this patchset in
this or next week some time. I'm eagerly waiting to address any comments.

Also, can you please let me know what is the protocol here? Should
I resubmit just the "v3" of this patch? Or bump up the version of all
the patches in the patchset to "v3" and resubmit them all?

Thanks & Best Regards,

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