Re: [PATCH 2/6] ehea: pHYP interface

Hi Nathan,

sorry for the delayed answer.

On Friday 11 August 2006 23:19, Nathan Lynch wrote:

quoted

+static inline long ehea_hcall_9arg_9ret(unsigned long opcode,
+					unsigned long arg1,
+					unsigned long arg2,
+					unsigned long arg3,
+					unsigned long arg4,
+					unsigned long arg5,
+					unsigned long arg6,
+					unsigned long arg7,
+					unsigned long arg8,
+					unsigned long arg9,
+					unsigned long *out1,
+					unsigned long *out2,
+					unsigned long *out3,
+					unsigned long *out4,
+					unsigned long *out5,
+					unsigned long *out6,
+					unsigned long *out7,
+					unsigned long *out8,
+					unsigned long *out9)
+{
+	long hret = H_SUCCESS;
+	int i, sleep_msecs;
+
+	EDEB_EN(7, "opcode=%lx arg1=%lx arg2=%lx arg3=%lx arg4=%lx "
+		"arg5=%lx arg6=%lx arg7=%lx arg8=%lx arg9=%lx",
+		opcode, arg1, arg2, arg3, arg4, arg5, arg6, arg7,
+		arg8, arg9);
+
+
+	for (i = 0; i < 5; i++) {
+		hret = plpar_hcall_9arg_9ret(opcode,
+					    arg1, arg2, arg3, arg4,
+					    arg5, arg6, arg7, arg8,
+					    arg9,
+					    out1, out2, out3, out4,
+					    out5, out6, out7, out8,
+					    out9);
+
+		if (H_IS_LONG_BUSY(hret)) {
+			sleep_msecs = get_longbusy_msecs(hret);
+			msleep_interruptible(sleep_msecs);
+			continue;
+		}

Looping five times before giving up seems arbitrary and failure-prone
on busy systems.

This is the number we came up with after having talked to the H_CALL
developers

Is msleep_interruptible (as opposed to msleep) really appropriate?

Hope all the callers of this function are in non-atomic context (but I
wasn't able to find any callers?).

That's our intention.
We did not find a place where it is used in an atomic context. 

And this function is too big to be inline.

Ok, function is no longer inline