On Fri, 2012-05-11 at 07:58 +1000, Benjamin Herrenschmidt wrote:
> >
> > Having the timeout and retries in this function is the wrong thing to do.
> > We'll resubmit this without the loop and the caller will be responsible for
> > retrying the operations.
> >
> > I would rather have the caller ced
On Thu, 2012-05-10 at 14:08 -0500, Robert Jennings wrote:
> * Benjamin Herrenschmidt (b...@kernel.crashing.org) wrote:
> > Is this meant to be called in atomic context ? If not, maybe it should
> > at the very least do a cond_resched() ?
> >
> > Else, what about ceding the processor ? Or at the v
* Benjamin Herrenschmidt (b...@kernel.crashing.org) wrote:
> Hrm... I don't like that much:
>
> > + if (op->timeout)
> > + deadline = jiffies + msecs_to_jiffies(op->timeout);
> > +
> > + while (true) {
> > + hret = plpar_hcall_norets(H_COP, op->flags,
> > +
> Else, what about ceding the processor ? Or at the very least reducing
> the thread priority for a bit ?
>
> Shouldn't we also enforce to always have a timeout ? IE. Something like
> 30s or so if nothing specified to avoid having the kernel just hard
> lock...
>
> In general I don't like that s
Hrm... I don't like that much:
> + if (op->timeout)
> + deadline = jiffies + msecs_to_jiffies(op->timeout);
> +
> + while (true) {
> + hret = plpar_hcall_norets(H_COP, op->flags,
> + vdev->resource_id,
> + op->
Add support for the Platform Facilities Option (PFO) to the VIO bus.
These devices have a separate root node in OpenFirmware which
requires additional parsing to map into the existing VIO device
structure fields. This adds the interface for PFO device drivers to
make synchronous hypervisor calls.
