On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote:
quoted text
> --- a/arch/x86/pci/mmconfig_32.c
> +++ b/arch/x86/pci/mmconfig_32.c
> @@ -30,10 +30,6 @@ static u32 get_base_addr(unsigned int seg, int
> bus, unsigned devfn) struct acpi_mcfg_allocation *cfg;
>  	int cfg_num;
>  
> -	if (seg == 0 && bus < PCI_MMCFG_MAX_CHECK_BUS &&
> -	    test_bit(PCI_SLOT(devfn) + 32*bus,
> pci_mmcfg_fallback_slots))
> -		return 0;
> -
>  	for (cfg_num = 0; cfg_num < pci_mmcfg_config_num; cfg_num++)
> { cfg = &pci_mmcfg_config[cfg_num];
>  		if (cfg->pci_segment == seg &&
> @@ -68,13 +64,16 @@ static int pci_mmcfg_read(unsigned int seg,
> unsigned int bus, u32 base;
>  
>  	if ((bus > 255) || (devfn > 255) || (reg > 4095)) {
> -		*value = -1;
> +err:		*value = -1;
>  		return -EINVAL;
>  	}
>  
> +	if (reg < 256)
> +		return pci_conf1_read(seg,bus,devfn,reg,len,value);
> +


btw this is my main objection to your patch; it intertwines the conf1 and mmconfig code even more.
When (and I'm saying "when" not "if") systems arrive that only have MMCONFIG for some of the devices,
we'll have to detangle this again, and I'm really not looking forward to that.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/