All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Bordug <vitb@kernel.crashing.org>
To: "Grant Likely" <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
Date: Fri, 23 Nov 2007 00:51:21 +0300	[thread overview]
Message-ID: <20071123005121.4d38d877@kernel.crashing.org> (raw)
In-Reply-To: <fa686aa40711221036n6438c252lde71cffdaff97ea9@mail.gmail.com>

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

  reply	other threads:[~2007-11-22 21:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-22 17:24 [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers Jochen Friedrich
2007-11-22 18:36 ` Grant Likely
2007-11-22 21:51   ` Vitaly Bordug [this message]
2007-11-24 17:53     ` Jochen Friedrich
2007-11-24 21:47       ` Vitaly Bordug
2007-11-26 16:24     ` Scott Wood
2007-11-26 21:22       ` Vitaly Bordug
2007-11-26 21:41         ` Scott Wood
2007-11-27  8:08           ` Vitaly Bordug

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071123005121.4d38d877@kernel.crashing.org \
    --to=vitb@kernel.crashing.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.