All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Ying Chu <jasonchu@marvell.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Andy Yan <ayan@marvell.com>, Ke Wei <kewei@marvell.com>
Subject: Re: [PATCH 4/4] mvsas: Fine-tuned tags array for alignment
Date: Sat, 09 May 2009 09:38:19 -0500	[thread overview]
Message-ID: <1241879899.3542.6.camel@mulgrave> (raw)
In-Reply-To: <4A052820.3080802@garzik.org>

On Sat, 2009-05-09 at 02:52 -0400, Jeff Garzik wrote:
> Ying Chu wrote:
> > Hi, James
> > 
> > DECLARE_BITMAP isn't a good option for mvsas, since the tags array couldn't be global(it's chip-related) and even if we define the static tag array both in mv64xx.c and mv94xx.c, it still couldn't honor 88SE9480 as there are 2 separate cores. So if we use DECLARE_BITMAP, it's hard to maintain the corresponding tag for different core.  
> > 
> > Can we use the following replacement:
> >  -	u8 tags[MVS_SLOTS >> 3];
> >  +	unsigned long tags[MVS_SLOTS / BITS_PER_LONG];
> 
> You are doing exactly the same thing as DECLARE_BITMAP here, so just use 
> DECLARE_BITMAP :)
> 
> include/linux/types.h:
> 	#define DECLARE_BITMAP(name,bits) \
> 	        unsigned long name[BITS_TO_LONGS(bits)]

Right, it's one of those annoying definitions that's designed to be
compound, so things like

static DECLARE_BITMAP(x, y);

is legal as well as

struct {
	DECLARE_BITMAP(x,y);
};

in either case, the scope is precisely what an ordinary variable would
have had at that point.

Most of our DECLARE_XX are designed like this.

James



      parent reply	other threads:[~2009-05-09 14:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08  6:18 [PATCH 4/4] mvsas: Fine-tuned tags array for alignment Ying Chu
2009-05-08 15:19 ` James Bottomley
2009-05-08 16:22   ` Jeff Garzik
2009-05-09  6:52     ` Ying Chu
2009-05-09  6:52       ` Jeff Garzik
2009-05-09  6:59         ` Ying Chu
2009-05-09 14:38         ` James Bottomley [this message]

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=1241879899.3542.6.camel@mulgrave \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ayan@marvell.com \
    --cc=jasonchu@marvell.com \
    --cc=jeff@garzik.org \
    --cc=kewei@marvell.com \
    --cc=linux-scsi@vger.kernel.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.