On Wed, 06 May 2009 00:21:20 -0700
Yinghai Lu <yinghai@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
