All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
@ 2006-12-23  1:02 OGAWA Hirofumi
  2006-12-23 10:20 ` Arjan van de Ven
  0 siblings, 1 reply; 7+ messages in thread
From: OGAWA Hirofumi @ 2006-12-23  1:02 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, OGAWA Hirofumi

Current -mm's mmconfig has some problems of remapped range.

a) In the case of broken MCFG tables on Asus etc., we need to remap
256M range, but currently only remap 1M.

b) The base address always corresponds to bus number 0, but currently
we are assuming it corresponds to start bus number.

This patch fixes the above problems.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 arch/x86_64/pci/mmconfig.c |   48 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 35 insertions(+), 13 deletions(-)

diff -puN arch/x86_64/pci/mmconfig.c~pci-mmconfig-ioremap-range-fix arch/x86_64/pci/mmconfig.c
--- linux-2.6/arch/x86_64/pci/mmconfig.c~pci-mmconfig-ioremap-range-fix	2006-12-23 08:52:15.000000000 +0900
+++ linux-2.6-hirofumi/arch/x86_64/pci/mmconfig.c	2006-12-23 09:35:37.000000000 +0900
@@ -24,6 +24,39 @@ struct mmcfg_virt {
 };
 static struct mmcfg_virt *pci_mmcfg_virt;
 
+static inline int mcfg_broken(void)
+{
+	struct acpi_table_mcfg_config *cfg = &pci_mmcfg_config[0];
+
+	/* Handle more broken MCFG tables on Asus etc.
+	   They only contain a single entry for bus 0-0. Assume
+ 	   this applies to all busses. */
+	if (pci_mmcfg_config_num == 1 &&
+	    cfg->pci_segment_group_number == 0 &&
+	    (cfg->start_bus_number | cfg->end_bus_number) == 0)
+		return 1;
+	return 0;
+}
+
+static void __iomem *mcfg_ioremap(struct acpi_table_mcfg_config *cfg)
+{
+	void __iomem *addr;
+	u32 size;
+
+	if (mcfg_broken())
+		size = 256 << 20;
+	else
+		size = (cfg->end_bus_number + 1) << 20;
+
+	addr = ioremap_nocache(cfg->base_address, size);
+	if (addr) {
+		printk(KERN_INFO "PCI: Using MMCONFIG at %x - %x\n",
+		       cfg->base_address,
+		       cfg->base_address + size - 1);
+	}
+	return addr;
+}
+
 static char __iomem *get_virt(unsigned int seg, unsigned bus)
 {
 	int cfg_num = -1;
@@ -41,13 +74,7 @@ static char __iomem *get_virt(unsigned i
 			return pci_mmcfg_virt[cfg_num].virt;
 	}
 
-	/* Handle more broken MCFG tables on Asus etc.
-	   They only contain a single entry for bus 0-0. Assume
- 	   this applies to all busses. */
-	cfg = &pci_mmcfg_config[0];
-	if (pci_mmcfg_config_num == 1 &&
-		cfg->pci_segment_group_number == 0 &&
-		(cfg->start_bus_number | cfg->end_bus_number) == 0)
+	if (mcfg_broken())
 		return pci_mmcfg_virt[0].virt;
 
 	/* Fall back to type 0 */
@@ -139,19 +166,14 @@ int __init pci_mmcfg_arch_init(void)
 	}
 
 	for (i = 0; i < pci_mmcfg_config_num; ++i) {
-		u32 size = (pci_mmcfg_config[0].end_bus_number - pci_mmcfg_config[0].start_bus_number + 1) << 20;
 		pci_mmcfg_virt[i].cfg = &pci_mmcfg_config[i];
-		pci_mmcfg_virt[i].virt = ioremap_nocache(pci_mmcfg_config[i].base_address,
-							 size);
+		pci_mmcfg_virt[i].virt = mcfg_ioremap(&pci_mmcfg_config[i]);
 		if (!pci_mmcfg_virt[i].virt) {
 			printk(KERN_ERR "PCI: Cannot map mmconfig aperture for "
 					"segment %d\n",
 			       pci_mmcfg_config[i].pci_segment_group_number);
 			return 0;
 		}
-		printk(KERN_INFO "PCI: Using MMCONFIG at %x-%x\n",
-		       pci_mmcfg_config[i].base_address,
-		       pci_mmcfg_config[i].base_address + size - 1);
 	}
 
 	raw_pci_ops = &pci_mmcfg;
_

-- 
OGAWA Hirofumi <hogawa@miraclelinux.com>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
  2006-12-23  1:02 [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address OGAWA Hirofumi
@ 2006-12-23 10:20 ` Arjan van de Ven
  2006-12-23 11:49   ` OGAWA Hirofumi
  0 siblings, 1 reply; 7+ messages in thread
From: Arjan van de Ven @ 2006-12-23 10:20 UTC (permalink / raw)
  To: OGAWA Hirofumi; +Cc: Andrew Morton, linux-kernel, OGAWA Hirofumi

On Sat, 2006-12-23 at 10:02 +0900, OGAWA Hirofumi wrote:
> Current -mm's mmconfig has some problems of remapped range.
> 
> a) In the case of broken MCFG tables on Asus etc., we need to remap
> 256M range, but currently only remap 1M.


Hi,

I respectfully disagree. If the MCFG table is broken, we should not use
it AT ALL. It's either a correct table, and we can use it, or it's so
broken that we know it never has been tested etc etc, we're just better
of to not trust it in that case.

Greetings,
   Arjan van de Ven


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
  2006-12-23 10:20 ` Arjan van de Ven
@ 2006-12-23 11:49   ` OGAWA Hirofumi
  2006-12-25 12:36     ` Arjan van de Ven
  0 siblings, 1 reply; 7+ messages in thread
From: OGAWA Hirofumi @ 2006-12-23 11:49 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: OGAWA Hirofumi, Andrew Morton, linux-kernel

Hi,

Arjan van de Ven <arjan@infradead.org> writes:

> On Sat, 2006-12-23 at 10:02 +0900, OGAWA Hirofumi wrote:
>> Current -mm's mmconfig has some problems of remapped range.
>> 
>> a) In the case of broken MCFG tables on Asus etc., we need to remap
>> 256M range, but currently only remap 1M.
>
> I respectfully disagree. If the MCFG table is broken, we should not use
> it AT ALL. It's either a correct table, and we can use it, or it's so
> broken that we know it never has been tested etc etc, we're just better
> of to not trust it in that case.

Hm.. I see. Sounds sane to me. Well, my patch didn't add the new
workaround of broken table, it just fixes the oops of existence workaround.

Current workaround is the following (both of linus and -mm),

	if (pci_mmcfg_config_num == 1 &&
		cfg->pci_segment_group_number == 0 &&
		(cfg->start_bus_number | cfg->end_bus_number) == 0)
                /* Assume it can access 256M range */

But, if the system has bus number 0 only, it's a correct table.
We may need to detect the broken system. blacklist?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
  2006-12-23 11:49   ` OGAWA Hirofumi
@ 2006-12-25 12:36     ` Arjan van de Ven
  2006-12-25 15:49       ` Olivier Galibert
  2006-12-25 19:01       ` OGAWA Hirofumi
  0 siblings, 2 replies; 7+ messages in thread
From: Arjan van de Ven @ 2006-12-25 12:36 UTC (permalink / raw)
  To: OGAWA Hirofumi; +Cc: OGAWA Hirofumi, Andrew Morton, linux-kernel


> Current workaround is the following (both of linus and -mm),
> 
> 	if (pci_mmcfg_config_num == 1 &&
> 		cfg->pci_segment_group_number == 0 &&
> 		(cfg->start_bus_number | cfg->end_bus_number) == 0)
>                 /* Assume it can access 256M range */
> 
> But, if the system has bus number 0 only, it's a correct table.
> We may need to detect the broken system. blacklist?

or just... not assume 256Mb but assume broken?

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
  2006-12-25 12:36     ` Arjan van de Ven
@ 2006-12-25 15:49       ` Olivier Galibert
  2006-12-25 18:50         ` OGAWA Hirofumi
  2006-12-25 19:01       ` OGAWA Hirofumi
  1 sibling, 1 reply; 7+ messages in thread
From: Olivier Galibert @ 2006-12-25 15:49 UTC (permalink / raw)
  To: OGAWA Hirofumi, Andrew Morton, linux-kernel

Sorry I missed the original email, but what is the chipset (name, pci
ID) of the board(s) with the problematic bios?

  OG.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
  2006-12-25 15:49       ` Olivier Galibert
@ 2006-12-25 18:50         ` OGAWA Hirofumi
  0 siblings, 0 replies; 7+ messages in thread
From: OGAWA Hirofumi @ 2006-12-25 18:50 UTC (permalink / raw)
  To: Olivier Galibert; +Cc: Andrew Morton, linux-kernel

Olivier Galibert <galibert@pobox.com> writes:

> Sorry I missed the original email, but what is the chipset (name, pci
> ID) of the board(s) with the problematic bios?

I don't know, here is a comment of current code.

	/* Handle more broken MCFG tables on Asus etc.
	   They only contain a single entry for bus 0-0. Assume
	   this applies to all busses. */
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
  2006-12-25 12:36     ` Arjan van de Ven
  2006-12-25 15:49       ` Olivier Galibert
@ 2006-12-25 19:01       ` OGAWA Hirofumi
  1 sibling, 0 replies; 7+ messages in thread
From: OGAWA Hirofumi @ 2006-12-25 19:01 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: OGAWA Hirofumi, Andrew Morton, linux-kernel

Arjan van de Ven <arjan@infradead.org> writes:

>> Current workaround is the following (both of linus and -mm),
>> 
>> 	if (pci_mmcfg_config_num == 1 &&
>> 		cfg->pci_segment_group_number == 0 &&
>> 		(cfg->start_bus_number | cfg->end_bus_number) == 0)
>>                 /* Assume it can access 256M range */
>> 
>> But, if the system has bus number 0 only, it's a correct table.
>> We may need to detect the broken system. blacklist?
>
> or just... not assume 256Mb but assume broken?

I see. And instead, add force enable option?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2006-12-25 19:02 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-23  1:02 [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address OGAWA Hirofumi
2006-12-23 10:20 ` Arjan van de Ven
2006-12-23 11:49   ` OGAWA Hirofumi
2006-12-25 12:36     ` Arjan van de Ven
2006-12-25 15:49       ` Olivier Galibert
2006-12-25 18:50         ` OGAWA Hirofumi
2006-12-25 19:01       ` OGAWA Hirofumi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.