| Message ID | 1233765552.16414.6.camel@localhost.localdomain (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
* Ed Swierk <eswierk@aristanetworks.com> wrote: > +static const char __init *pci_mmcfg_nvidia_mcp55(void) > +{ > + u32 extcfg; > + > + raw_pci_ops->read(0, 0, PCI_DEVFN(0, 0), 0x90, 4, &extcfg); > + > + if (!(extcfg & 0x80000000)) > + return NULL; > + pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL); > + if (!pci_mmcfg_config) > + return NULL; > + pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > + pci_mmcfg_config[0].pci_segment = 0; > + pci_mmcfg_config[0].start_bus_number = 0; > + pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) & 3))) - 1; > + pci_mmcfg_config_num = 1; > + > + return "nVidia MCP55"; Looks good in principle, but here are a few code cleanliness observations: 1) Please introduce a helper variable to: struct acpi_mcfg_allocation *config; Which you can allocate, initialize - and then set pci_mmcfg_config to it. Does not change the end result but makes the code structure cleaner and shortens the lines. 2) Please use vertical spaces when initializing structure fields. Instead of the messy looking (and over-long-line generating) construct of: pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; pci_mmcfg_config[0].pci_segment = 0; pci_mmcfg_config[0].start_bus_number = 0; pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) & 3))) - 1; pci_mmcfg_config_num = 1; You will get something like: config->address = (extcfg & 0x00007fff) << 25; config->pci_segment = 0; config->start_bus_number = 0; config->end_bus_number = (1 << (8 - ((extcfg >> 28) & 3))); pci_mmcfg_config = config; pci_mmcfg_config_num = 1; Which makes it more structured, more reviewable - and more pleasant to look at as well. 3) Please use newlines in a more structured way, instead of: raw_pci_ops->read(0, 0, PCI_DEVFN(0, 0), 0x90, 4, &extcfg); if (!(extcfg & 0x80000000)) return NULL; pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL); if (!pci_mmcfg_config) return NULL; pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; Do something like: raw_pci_ops->read(0, 0, PCI_DEVFN(0, 0), 0x90, 4, &extcfg); if (!(extcfg & 0x80000000)) return NULL; config = kzalloc(sizeof(*config), GFP_KERNEL); if (!config) return NULL; config->address = (extcfg & 0x00007fff) << 25; Note how the grouping of statements made the code flow really apparent and straightforward, and made the returns and error conditions stand out. 4) Also, there's 6 magic constants in this patch: 0x90, 4, 0x80000000, 0x00007fff, 28, 3 Wherever you know already existing symbols for these in the PCI code please use them - and where not, add a const u32 to introduce them. For example 0x80000000 means 'mmconf already enabled' - a suitable symbol should be used. That way the code becomes self-explanatory at a glance - even years down the line when everyone has forgotten what it's all about. If a constant is very specific to the nVidia MCP55 chipset register layout, you can define it straight before the pci_mmcfg_nvidia_mcp55() function, no need to separate the definitions from the function by moving it into some header file. Also, if possible and if it exists, add information (URLs if they exist) about the chipset documentation that was the basis for this change. 5) Finally, some testing info and motivation-for-change info would be nice as well. Which specific system/model encountered problems with non-enabled mmconfig, and did it work well after you enabled it via this chipset quirk? Thanks! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/04/2009 11:39 AM, Ed Swierk wrote: > Detect and enable memory-mapped PCI configuration space on the nVidia > MCP55 southbridge even if the ACPI MCFG table is missing or wrong. > > Minor question: there are motherboards with two MCP55 southbridges. Would the patch support mmconfig for both? Loic -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 4, 2009 at 9:07 AM, Loic Prylli <loic@myri.com> wrote: > Minor question: there are motherboards with two MCP55 southbridges. Would > the patch support mmconfig for both? Can you point me to such a motherboard? I have only seen boards with one MCP55 plus a C51 companion chip providing extra PCIe lanes. --Ed -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 4, 2009 at 9:37 AM, Ed Swierk <eswierk@aristanetworks.com> wrote: > On Wed, Feb 4, 2009 at 9:07 AM, Loic Prylli <loic@myri.com> wrote: >> Minor question: there are motherboards with two MCP55 southbridges. Would >> the patch support mmconfig for both? > > Can you point me to such a motherboard? I have only seen boards with > one MCP55 plus a C51 companion chip providing extra PCIe lanes. > nvidia CRB YH -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 4, 2009 at 8:39 AM, Ed Swierk <eswierk@aristanetworks.com> wrote: > Detect and enable memory-mapped PCI configuration space on the nVidia > MCP55 southbridge even if the ACPI MCFG table is missing or wrong. > > Signed-off-by: Ed Swierk <eswierk@aristanetworks.com> > > --- > Index: linux-2.6.27.4/arch/x86/pci/mmconfig-shared.c > =================================================================== > --- linux-2.6.27.4.orig/arch/x86/pci/mmconfig-shared.c > +++ linux-2.6.27.4/arch/x86/pci/mmconfig-shared.c > @@ -155,6 +155,26 @@ static const char __init *pci_mmcfg_amd_ > return "AMD Family 10h NB"; > } > > +static const char __init *pci_mmcfg_nvidia_mcp55(void) > +{ > + u32 extcfg; > + > + raw_pci_ops->read(0, 0, PCI_DEVFN(0, 0), 0x90, 4, &extcfg); > + > + if (!(extcfg & 0x80000000)) > + return NULL; > + pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL); > + if (!pci_mmcfg_config) > + return NULL; > + pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > + pci_mmcfg_config[0].pci_segment = 0; > + pci_mmcfg_config[0].start_bus_number = 0; > + pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) & 3))) - 1; > + pci_mmcfg_config_num = 1; > + > + return "nVidia MCP55"; > +} > + > struct pci_mmcfg_hostbridge_probe { > u32 bus; > u32 devfn; > @@ -172,6 +192,8 @@ static struct pci_mmcfg_hostbridge_probe > 0x1200, pci_mmcfg_amd_fam10h }, > { 0xff, PCI_DEVFN(0, 0), PCI_VENDOR_ID_AMD, > 0x1200, pci_mmcfg_amd_fam10h }, > + { 0, PCI_DEVFN(0, 0), PCI_VENDOR_ID_NVIDIA, > + 0x0369, pci_mmcfg_nvidia_mcp55 }, may break amd family 10h + mcp55 system. because some system have setting in AMD cpu and mcp55 it will find setting in CPU nb, and your code will partially overwrite those setting. YH -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Yinghai Lu <yinghai@kernel.org> wrote: > On Wed, Feb 4, 2009 at 8:39 AM, Ed Swierk <eswierk@aristanetworks.com> wrote: > > Detect and enable memory-mapped PCI configuration space on the nVidia > > MCP55 southbridge even if the ACPI MCFG table is missing or wrong. > > > > Signed-off-by: Ed Swierk <eswierk@aristanetworks.com> > > > > --- > > Index: linux-2.6.27.4/arch/x86/pci/mmconfig-shared.c > > =================================================================== > > --- linux-2.6.27.4.orig/arch/x86/pci/mmconfig-shared.c > > +++ linux-2.6.27.4/arch/x86/pci/mmconfig-shared.c > > @@ -155,6 +155,26 @@ static const char __init *pci_mmcfg_amd_ > > return "AMD Family 10h NB"; > > } > > > > +static const char __init *pci_mmcfg_nvidia_mcp55(void) > > +{ > > + u32 extcfg; > > + > > + raw_pci_ops->read(0, 0, PCI_DEVFN(0, 0), 0x90, 4, &extcfg); > > + > > + if (!(extcfg & 0x80000000)) > > + return NULL; > > + pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL); > > + if (!pci_mmcfg_config) > > + return NULL; > > + pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > > + pci_mmcfg_config[0].pci_segment = 0; > > + pci_mmcfg_config[0].start_bus_number = 0; > > + pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) & 3))) - 1; > > + pci_mmcfg_config_num = 1; > > + > > + return "nVidia MCP55"; > > +} > > + > > struct pci_mmcfg_hostbridge_probe { > > u32 bus; > > u32 devfn; > > @@ -172,6 +192,8 @@ static struct pci_mmcfg_hostbridge_probe > > 0x1200, pci_mmcfg_amd_fam10h }, > > { 0xff, PCI_DEVFN(0, 0), PCI_VENDOR_ID_AMD, > > 0x1200, pci_mmcfg_amd_fam10h }, > > + { 0, PCI_DEVFN(0, 0), PCI_VENDOR_ID_NVIDIA, > > + 0x0369, pci_mmcfg_nvidia_mcp55 }, > > may break amd family 10h + mcp55 system. because some system have setting > in AMD cpu and mcp55 it will find setting in CPU nb, and your code will > partially overwrite those setting. That's a good point ... We could do something like: if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD && boot_cpu_data.x86 >= 0x10) { u64 mmconf_val; rdmsrl(MSR_FAM10H_MMIO_CONF_BASE, mmconf_val); if (mmconf_val & FAM10H_MMIO_CONF_ENABLE) return; } To detect enabled on-CPU mmconf support. We could even put this into a helper function as other places might want to use it too. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 04 February 2009 17:04:40 Ingo Molnar wrote: > 2) Please use vertical spaces when initializing structure fields. Instead > of the messy looking (and over-long-line generating) construct of: > > pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > pci_mmcfg_config[0].pci_segment = 0; > pci_mmcfg_config[0].start_bus_number = 0; > pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) & > 3))) - 1; pci_mmcfg_config_num = 1; > > You will get something like: > > config->address = (extcfg & 0x00007fff) << 25; > config->pci_segment = 0; > config->start_bus_number = 0; > config->end_bus_number = (1 << (8 - ((extcfg >> 28) & > 3))); > > pci_mmcfg_config = config; > pci_mmcfg_config_num = 1; > > Which makes it more structured, more reviewable - and more pleasant to > look at as well. Is this in CodingStyle now? Since I have noticed you are pushing for this quite a lot lately. And only for structure initialisation and not also for example for variable declarations? I find it a matter of personal preference whether it is more pleasant to look at and whether it is more or less readable. It is also worse from diff/patch point of view since it can happen in the future that what would be a one line change now becomes multiline. Regards, Tvrtko -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote: > On Wednesday 04 February 2009 17:04:40 Ingo Molnar wrote: > > 2) Please use vertical spaces when initializing structure fields. Instead > > of the messy looking (and over-long-line generating) construct of: > > > > pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > > pci_mmcfg_config[0].pci_segment = 0; > > pci_mmcfg_config[0].start_bus_number = 0; > > pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) & > > 3))) - 1; pci_mmcfg_config_num = 1; > > > > You will get something like: > > > > config->address = (extcfg & 0x00007fff) << 25; > > config->pci_segment = 0; > > config->start_bus_number = 0; > > config->end_bus_number = (1 << (8 - ((extcfg >> 28) & > > 3))); > > > > pci_mmcfg_config = config; > > pci_mmcfg_config_num = 1; > > > > Which makes it more structured, more reviewable - and more pleasant to > > look at as well. It is arch/x86/ and scheduler / etc. policy for new code - and we follow that principle when we clean up code as well. Same goes for static structure initializers. We do: static const struct file_operations perf_fops = { .release = perf_release, .read = perf_read, .poll = terf_poll, .unlocked_ioctl = perf_ioctl, .compat_ioctl = perf_ioctl, }; And not: static const struct file_operations perf_fops = { .release = perf_release, .read = perf_read, .poll = perf_poll, .unlocked_ioctl = perf_ioctl, .compat_ioctl = pert_ioctl, }; Beyond the prettiness and fun to look at factor, there are other advantages of vertical spaces as well: Trivia: you play the role of the code reviewer. I have hidden two typos in the initializers above, one in each initializer block. The typos are of the same type but are in difference places so both need to be found individually. Try to find the typos, and record the number of seconds it took for you to find them. Which typo took less time to find? I'd suspect that for most people block#1 is the winner. [ Note, you have a look at it as real source code with fixed width fonts and you'll see the difference. You seem to be using KMail or so: there's weird line wraps and other corruption of the code in your quote above - have you really looked at the real code how it looks like to developers? ] > I find it a matter of personal preference whether it is more pleasant to > look at and whether it is more or less readable. Is your argument that to you it is less pleasant to look at? Differences in taste is OK in borderline issues, but i think this one is far from being borderline, it's a basic typographic and aesthetic principle. I'm not sure vertical spaces can be properly described via more rigid CodingStyle rules - for example vertical spaces look ugly if there's just two field initializations for example - but in the above case they are clearly the right thing to do. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 05 February 2009 18:00:19 Ingo Molnar wrote: > * Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote: > > On Wednesday 04 February 2009 17:04:40 Ingo Molnar wrote: > > > 2) Please use vertical spaces when initializing structure fields. > > > Instead of the messy looking (and over-long-line generating) construct > > > of: > > > > > > pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > > > pci_mmcfg_config[0].pci_segment = 0; > > > pci_mmcfg_config[0].start_bus_number = 0; > > > pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) > > > & 3))) - 1; pci_mmcfg_config_num = 1; > > > > > > You will get something like: > > > > > > config->address = (extcfg & 0x00007fff) << 25; > > > config->pci_segment = 0; > > > config->start_bus_number = 0; > > > config->end_bus_number = (1 << (8 - ((extcfg >> 28) & > > > 3))); > > > > > > pci_mmcfg_config = config; > > > pci_mmcfg_config_num = 1; > > > > > > Which makes it more structured, more reviewable - and more pleasant > > > to look at as well. > > It is arch/x86/ and scheduler / etc. policy for new code - and we follow > that principle when we clean up code as well. You also didn't say anything about variable declarations I asked about? And I can add structure definition to that question as well. > Beyond the prettiness and fun to look at factor, there are other advantages > of vertical spaces as well: > > Trivia: you play the role of the code reviewer. I have hidden two typos in > the initializers above, one in each initializer block. The typos are of the > same type but are in difference places so both need to be found > individually. > > Try to find the typos, and record the number of seconds it took for you to > find them. Which typo took less time to find? Actually test was invalidated by me looking for two typos in each block for a long long time. Therefore by providing interesting visual things to look at you made me skip the important bit with instructions. :) But I personally think it is not such a big difference. And please remember that the part I originally commented on was different in a way that it had expressions on the right hand side. There with a huge gap between left and right you then break to logical association and make brain evaluate it as two separate groups which perhaps doesn't always makes sense. And how could you say that not vertically aligning increases maximum line length is beyond me. > I'd suspect that for most people block#1 is the winner. _You_ think it's fun to look at and you suspect it is the winner, which is basically my point. I think you are going to far. Either you specify the rules in CodingStyle or you don't have it as a reason to send patches for rework. Until then you can't say it is a policy, it can at least depend on circumstances. > [ Note, you have a look at it as real source code with fixed width fonts > and you'll see the difference. You seem to be using KMail or so: there's > weird line wraps and other corruption of the code in your quote above - > have you really looked at the real code how it looks like to developers? ] Yes I have, it looks like ordinary word wrap when replying. I don't see any other corruptions though - have you added that just to make it sound more dramatic together with suggesting I am not a developer? > > I find it a matter of personal preference whether it is more pleasant to > > look at and whether it is more or less readable. > > Is your argument that to you it is less pleasant to look at? No, my argument is that in this case it is a personal preference what is more pleasant to look at. > Differences in taste is OK in borderline issues, but i think this one is > far from being borderline, it's a basic typographic and aesthetic > principle. While for some cases I also like vertical alignment, for the original code I think it was borderline _at most_. > I'm not sure vertical spaces can be properly described via more rigid > CodingStyle rules - for example vertical spaces look ugly if there's just > two field initializations for example - but in the above case they are > clearly the right thing to do. Well I don't wish to argue on this subject very much. I just thought it is unfair to criticise on an issue which cannot be a hard rule and in a particular example was not an improvement. Since you also agree it is not possible to describe it as a hard rule, why bother people with it? Tvrtko -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote: > On Thursday 05 February 2009 18:00:19 Ingo Molnar wrote: > > * Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote: > > > On Wednesday 04 February 2009 17:04:40 Ingo Molnar wrote: > > > > 2) Please use vertical spaces when initializing structure fields. > > > > Instead of the messy looking (and over-long-line generating) construct > > > > of: > > > > > > > > pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > > > > pci_mmcfg_config[0].pci_segment = 0; > > > > pci_mmcfg_config[0].start_bus_number = 0; > > > > pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) > > > > & 3))) - 1; pci_mmcfg_config_num = 1; > > > > > > > > You will get something like: > > > > > > > > config->address = (extcfg & 0x00007fff) << 25; > > > > config->pci_segment = 0; > > > > config->start_bus_number = 0; > > > > config->end_bus_number = (1 << (8 - ((extcfg >> 28) & > > > > 3))); > > > > > > > > pci_mmcfg_config = config; > > > > pci_mmcfg_config_num = 1; > > > > > > > > Which makes it more structured, more reviewable - and more pleasant > > > > to look at as well. > > > > It is arch/x86/ and scheduler / etc. policy for new code - and we follow > > that principle when we clean up code as well. > > You also didn't say anything about variable declarations I asked about? > And I can add structure definition to that question as well. Firstly, when posting on lkml please use proper line length breaks. Your email was almost unreadable in my mailer, so i had to stop reading it. Also, i'm surprised you see the need to try to influence things here - i dont see a single upstream contribution from you in the past ~4 years of git log so how can you have any knowledge and experience about such details? Both of those issues pretty materially weaken your standing to be taken seriously when it comes to fine details of Linux kernel coding style. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 06 February 2009 15:42:31 Ingo Molnar wrote: > * Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote: > > On Thursday 05 February 2009 18:00:19 Ingo Molnar wrote: > > > * Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote: > > > > On Wednesday 04 February 2009 17:04:40 Ingo Molnar wrote: > > > > > 2) Please use vertical spaces when initializing structure fields. > > > > > Instead of the messy looking (and over-long-line generating) > > > > > construct of: > > > > > > > > > > pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; > > > > > pci_mmcfg_config[0].pci_segment = 0; > > > > > pci_mmcfg_config[0].start_bus_number = 0; > > > > > pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> > > > > > 28) & 3))) - 1; pci_mmcfg_config_num = 1; > > > > > > > > > > You will get something like: > > > > > > > > > > config->address = (extcfg & 0x00007fff) << > > > > > 25; config->pci_segment = 0; > > > > > config->start_bus_number = 0; > > > > > config->end_bus_number = (1 << (8 - ((extcfg >> > > > > > 28) & 3))); > > > > > > > > > > pci_mmcfg_config = config; > > > > > pci_mmcfg_config_num = 1; > > > > > > > > > > Which makes it more structured, more reviewable - and more > > > > > pleasant to look at as well. > > > > > > It is arch/x86/ and scheduler / etc. policy for new code - and we > > > follow that principle when we clean up code as well. > > > > You also didn't say anything about variable declarations I asked about? > > And I can add structure definition to that question as well. > > Firstly, when posting on lkml please use proper line length breaks. Your > email was almost unreadable in my mailer, so i had to stop reading it. > > Also, i'm surprised you see the need to try to influence things here - i > dont see a single upstream contribution from you in the past ~4 years of > git log so how can you have any knowledge and experience about such > details? > > Both of those issues pretty materially weaken your standing to be taken > seriously when it comes to fine details of Linux kernel coding style. Sorry about the line length, I was trying not to word wrap code this time. Apart from that, frankly, I find your reply a bit childish. I haven't realised I need special talking points to express my opinion on a public mailing list. Especially since in my previous reply I said that I don't want to argue about this very much and that I am just expressing my opinion. Tvrtko -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6.27.4/arch/x86/pci/mmconfig-shared.c =================================================================== --- linux-2.6.27.4.orig/arch/x86/pci/mmconfig-shared.c +++ linux-2.6.27.4/arch/x86/pci/mmconfig-shared.c @@ -155,6 +155,26 @@ static const char __init *pci_mmcfg_amd_ return "AMD Family 10h NB"; } +static const char __init *pci_mmcfg_nvidia_mcp55(void) +{ + u32 extcfg; + + raw_pci_ops->read(0, 0, PCI_DEVFN(0, 0), 0x90, 4, &extcfg); + + if (!(extcfg & 0x80000000)) + return NULL; + pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL); + if (!pci_mmcfg_config) + return NULL; + pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25; + pci_mmcfg_config[0].pci_segment = 0; + pci_mmcfg_config[0].start_bus_number = 0; + pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28) & 3))) - 1; + pci_mmcfg_config_num = 1; + + return "nVidia MCP55"; +} + struct pci_mmcfg_hostbridge_probe { u32 bus; u32 devfn; @@ -172,6 +192,8 @@ static struct pci_mmcfg_hostbridge_probe 0x1200, pci_mmcfg_amd_fam10h }, { 0xff, PCI_DEVFN(0, 0), PCI_VENDOR_ID_AMD, 0x1200, pci_mmcfg_amd_fam10h }, + { 0, PCI_DEVFN(0, 0), PCI_VENDOR_ID_NVIDIA, + 0x0369, pci_mmcfg_nvidia_mcp55 }, }; static int __init pci_mmcfg_check_hostbridge(void)
Detect and enable memory-mapped PCI configuration space on the nVidia MCP55 southbridge even if the ACPI MCFG table is missing or wrong. Signed-off-by: Ed Swierk <eswierk@aristanetworks.com> --- -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html