From: David Miller <davem@davemloft.net>
To: eric.lemoine@gmail.com
Cc: netdev@vger.kernel.org, benh@kernel.crashing.org
Subject: Re: [patch sungem] improved locking
Date: Fri, 10 Nov 2006 12:42:46 -0800 (PST) [thread overview]
Message-ID: <20061110.124246.41636039.davem@davemloft.net> (raw)
In-Reply-To: <5cac192f0611100528r4a53498emc8d866955cc36c8d@mail.gmail.com>
From: "Eric Lemoine" <eric.lemoine@gmail.com>
Date: Fri, 10 Nov 2006 14:28:41 +0100
> On 11/10/06, David Miller <davem@davemloft.net> wrote:
> >
> > Please use GREG_STAT_* instead of magic constants for the
> > interrupt mask and ACK register writes. In fact, there are
> > some questionable values you use, in particular this one:
> >
> > +static inline void gem_ack_int(struct gem *gp)
> > +{
> > + writel(0x3f, gp->regs + GREG_IACK);
> > +}
>
> This code clears bits 0 through 6, which GREG_IACK is for.
>
> > There is no bit defined in GREG_STAT_* for 0x08, but you
> > set it in this magic bitmask. It is another reason not
> > to use magic constants like this :-)
>
> Yes, the bit 4 isn't used, but I assumed clearing it shouldn't be prolem.
>
> Would you prefer that:
>
> #define GREG_STAT_IACK 0x3f
>
> static inline void gem_ack_int(struct gem *gp)
> {
> writel(GREG_STAT_IACK, gp->regs + GREG_IACK);
> }
>
> or that:
>
> #define GREG_STAT_IACK (GREG_STAT_TXINTME | GREG_STAT_TXALL | \
> GREG_STAT_RXDONE | GREG_STAT_RXNOBUF)
>
> to avoid bit 4, and bit 3 (TX_DONE) which is masked.
>
> Personnaly, I like the first way best.
I think the second way is better because it clearly states
your intentions. The GREG_STAT_IACK 0x3f macro is still
"magic" because it doesn't say what the bits actually mean.
next prev parent reply other threads:[~2006-11-10 20:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-09 21:33 [patch sungem] improved locking Eric Lemoine
2006-11-09 23:04 ` David Miller
2006-11-10 13:28 ` Eric Lemoine
2006-11-10 20:37 ` Benjamin Herrenschmidt
2006-11-10 20:42 ` David Miller [this message]
2006-11-12 23:11 ` Eric Lemoine
2006-11-14 0:46 ` David Miller
2006-11-14 7:28 ` Eric Lemoine
2006-11-14 7:44 ` David Miller
2006-11-14 21:54 ` Eric Lemoine
2006-11-28 22:49 ` David Miller
2006-11-28 22:57 ` Benjamin Herrenschmidt
2006-11-28 23:43 ` David Miller
2006-11-29 0:19 ` Benjamin Herrenschmidt
2006-11-29 10:16 ` Eric Lemoine
2006-11-29 10:56 ` Eric Lemoine
2006-11-29 22:37 ` Eric Lemoine
2006-12-13 3:12 ` Benjamin Herrenschmidt
2006-12-13 3:24 ` Benjamin Herrenschmidt
2006-12-13 4:03 ` David Miller
2006-12-13 4:07 ` Benjamin Herrenschmidt
2006-12-29 5:05 ` David Miller
2006-12-29 21:36 ` Benjamin Herrenschmidt
2006-12-29 23:20 ` David Miller
2006-12-12 1:43 ` David Miller
2006-12-12 5:33 ` Eric Lemoine
2006-12-12 5:36 ` Benjamin Herrenschmidt
2006-12-12 5:49 ` Eric Lemoine
2006-12-15 0:59 ` Benjamin Herrenschmidt
2006-12-18 1:15 ` David Miller
2006-12-18 1:41 ` Benjamin Herrenschmidt
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=20061110.124246.41636039.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=benh@kernel.crashing.org \
--cc=eric.lemoine@gmail.com \
--cc=netdev@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.