[<prev] [next>] [day] [month] [year] [list]
Message-Id: <200608211404.16122.ossthema@de.ibm.com>
Date: Mon, 21 Aug 2006 14:04:15 +0200
From: Jan-Bernd Themann <ossthema@...ibm.com>
To: Nathan Lynch <ntl@...ox.com>
Cc: netdev <netdev@...r.kernel.org>, Thomas Klein <tklein@...ibm.com>,
linux-ppc <linuxppc-dev@...abs.org>,
Christoph Raisch <raisch@...ibm.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Marcus Eder <meder@...ibm.com>
Subject: Re: [PATCH 2/6] ehea: pHYP interface
Hi Nathan,
sorry for the delayed answer.
On Friday 11 August 2006 23:19, Nathan Lynch wrote:
> > +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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists