From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: linux-next: IO BAR sizing warning Date: Wed, 6 May 2009 09:24:18 -0700 Message-ID: <20090506092418.3fffab6b@hobbes> References: <20090506143007.c0ef2340.sfr@canb.auug.org.au> <4A013A70.30101@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from outbound-mail-32.bluehost.com ([69.89.18.152]:33887 "HELO outbound-mail-32.bluehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752248AbZEFQbA (ORCPT ); Wed, 6 May 2009 12:31:00 -0400 In-Reply-To: <4A013A70.30101@kernel.org> Sender: linux-next-owner@vger.kernel.org List-ID: To: Yinghai Lu Cc: Stephen Rothwell , linux-next@vger.kernel.org, "Wilcox, Matthew R" , Benjamin Herrenschmidt On Wed, 06 May 2009 00:21:20 -0700 Yinghai Lu wrote: > Stephen Rothwell wrote: > > Hi Jesse, > > > > Today's linux-next build (powerpc ppc64_defconfig) produced this > > warning: > > > > drivers/pci/probe.c: In function '__pci_read_base': > > drivers/pci/probe.c:196: warning: large integer implicitly > > truncated to unsigned type > > > > Probably introduced by commit > > 82160fd142cdf6956a677120426bf5baefcc7cf9 ("PCI/x86: don't assume > > prefetchable ranges are 64bit"). > > > > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -193,7 +193,7 @@ int __pci_read_base(struct pci_dev *dev, enum > pci_bar_type type, res->flags |= pci_calc_resource_flags(l) | > IORESOURCE_SIZEALIGN; if (type == pci_bar_io) { > l &= PCI_BASE_ADDRESS_IO_MASK; > - mask = PCI_BASE_ADDRESS_IO_MASK & 0xffff; > + mask = PCI_BASE_ADDRESS_IO_MASK & > IO_SPACE_LIMIT; > > > and > > for x86: > #define IO_SPACE_LIMIT 0xffff > > for powerpc > arch/powerpc/include/asm/io.h:#define IO_SPACE_LIMIT ~(0UL) > > maybe we need to change back that line... Yeah that would be easy enough. Though really it seems like IO_SPACE_LIMIT should be applied, with an appropriate cast. Looks like this code has been there for a long time, and maybe there are devices that allow the upper 16 bits of their IO BARs to be set even though they don't honor them (they should hardwire them to 0 in that case), but spec-wise allowing the full size should be fine... Matthew & Ben, any comments? -- Jesse Barnes, Intel Open Source Technology Center