Subject: Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers

From: Vitaly Bordug <[email-masked]>
Date: Fri, 23 Nov 2007 00:51:21 +0300

On Thu, 22 Nov 2007 11:36:29 -0700
Grant Likely wrote:

> > +int cpm_command(u32 command, u8 opcode)
> > +{
> > +       int i;
> > +
> > +       if (command & 0xffffff0f)
> > +               return -EINVAL;
> > +
> > +       out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode <<
> > 8));
> > +       for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> > +               if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
> > +                       return 0;
> > +
> > +       printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> > +               __FUNCTION__);
> > +       return -EIO;  
> 
> Do these need to be protected with a spin lock?
Even that might be not enough - we may have simultaneous call of this func in non-smp case...
I was thinking of some kind of refcount, so one that is going to issue CPM command, must do say pq_cpmp_get()
and another driver won't be able to mangle with cpcr while it's not done with previous request.

Yet I am not telling it was better the way it used to be - this approach looks okay but needs some efforts to defend against
deadlocks while we are at it.

-- 
Sincerely, Vitaly