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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).