From owner-freebsd-arch Thu Dec 13 15:50:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 2C78D37B41A for ; Thu, 13 Dec 2001 15:50:25 -0800 (PST) Received: (qmail 8896 invoked by uid 0); 13 Dec 2001 23:50:23 -0000 Received: from p5086f9a0.dip.t-dialin.net (HELO forge.local) (80.134.249.160) by mail.gmx.net (mp004-rz3) with SMTP; 13 Dec 2001 23:50:23 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16EfcV-0001lI-00; Fri, 14 Dec 2001 00:50:31 +0100 Date: Fri, 14 Dec 2001 00:50:31 +0100 From: Thomas Moestl To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011214005031.B4747@crow.dom2ip.de> Mail-Followup-To: Terry Lambert , arch@FreeBSD.org References: <20011213192033.A871@crow.dom2ip.de> <3C18F78D.C537D487@mindspring.com> <20011213201213.B871@crow.dom2ip.de> <3C192C70.9A79B3C5@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C192C70.9A79B3C5@mindspring.com>; from tlambert2@mindspring.com on Thu, Dec 13, 2001 at 02:32:16PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2001/12/13 at 14:32:16 -0800, Terry Lambert wrote: > > I did this change to support the Sun APB bridge, which does not have > > base and limit registers, but uses a different mechanism to set the > > decoded ranges. So, to check resource allocations correctly, the apb > > driver needs to implement it's own alloc_resource method. The pcib > > functions which need not be 'overridden' can be directly used in the > > method table. > > I still think that the proper way is to call a function to get the > addresses of the static functions. Ideally, you would pass and/or > break out the alloc_resource method, which would make the Sun APB > brige "standard". I'll think about doing that. > > > Also in subr_rman.c, in int_rman_activate_resource(), the change from > > > 32 to 31 is not obvious... should you also change "> 0" to ">= 0"? It's > > > not clear to me what this change fixes. I'm probably just missing > > > something... > > > > 1 << 32 is out of u_int32_t range, so it just would make no sense. In > > addition, it will overflow i (which is an int) on most architectures. > > I was more concerned with the 1 << 0 not being hit at all. I agree > on the overflow fix; I was just curious why the entire range was not > shifted down 1, instead of just avoiding the overflow. If no bit from 31 to 1 was found set, an alignment of 1 (i.e. any address is valid) is assumed. This corresponds to bit 0, so both 1 and zero mean that no alignment needs to be maintained. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message