public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: [Patch] bte_copy of BTE_MAX_XFER trips BUG_ON -V2
Date: Wed, 04 Feb 2009 16:47:37 +0000	[thread overview]
Message-ID: <20090204164737.GM8577@sgi.com> (raw)
In-Reply-To: <20090204004059.GM8559@sgi.com>

BTE_MAX_XFER is wrong.  It is one greater than the number of cache
lines the BTE is actually able to transfer.  If you request a transfer
of exactly BTE_MAX_XFER size, you trip a very cryptic BUG_ON() which
should certainly be made more clear.

This patch fixes that constant and also cleans up the BUG_ON()s in
arch/ia64/sn/kernel/bte.c to test one condition per line.

Signed-off-by: Robin Holt <holt@sgi.com>

---

Changes since -V1:
	Base the BTE_LEN_MASK upon a 1UL instead of 1 for correctness.


 arch/ia64/include/asm/sn/bte.h |    4 ++--
 arch/ia64/sn/kernel/bte.c      |    7 ++++---
 2 files changed, 6 insertions(+), 5 deletions(-)

Index: bte_fixup/arch/ia64/include/asm/sn/bte.h
=================================--- bte_fixup.orig/arch/ia64/include/asm/sn/bte.h	2009-02-04 10:37:29.594750841 -0600
+++ bte_fixup/arch/ia64/include/asm/sn/bte.h	2009-02-04 10:40:32.495791608 -0600
@@ -38,8 +38,8 @@
 
 /* BTE status register only supports 16 bits for length field */
 #define BTE_LEN_BITS (16)
-#define BTE_LEN_MASK ((1 << BTE_LEN_BITS) - 1)
-#define BTE_MAX_XFER ((1 << BTE_LEN_BITS) * L1_CACHE_BYTES)
+#define BTE_LEN_MASK ((1UL << BTE_LEN_BITS) - 1)
+#define BTE_MAX_XFER (BTE_LEN_MASK << L1_CACHE_SHIFT)
 
 
 /* Define hardware */
Index: bte_fixup/arch/ia64/sn/kernel/bte.c
=================================--- bte_fixup.orig/arch/ia64/sn/kernel/bte.c	2009-02-04 10:37:30.026753839 -0600
+++ bte_fixup/arch/ia64/sn/kernel/bte.c	2009-02-04 10:40:11.711701203 -0600
@@ -97,9 +97,10 @@ bte_result_t bte_copy(u64 src, u64 dest,
 		return BTE_SUCCESS;
 	}
 
-	BUG_ON((len & L1_CACHE_MASK) ||
-		 (src & L1_CACHE_MASK) || (dest & L1_CACHE_MASK));
-	BUG_ON(!(len < ((BTE_LEN_MASK + 1) << L1_CACHE_SHIFT)));
+	BUG_ON(len & L1_CACHE_MASK);
+	BUG_ON(src & L1_CACHE_MASK);
+	BUG_ON(dest & L1_CACHE_MASK);
+	BUG_ON(len > BTE_MAX_XFER);
 
 	/*
 	 * Start with interface corresponding to cpu number

      reply	other threads:[~2009-02-04 16:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-04  0:40 [Patch] bte_copy of BTE_MAX_XFER trips BUG_ON Robin Holt
2009-02-04 16:47 ` Robin Holt [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=20090204164737.GM8577@sgi.com \
    --to=holt@sgi.com \
    --cc=linux-ia64@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox