Re: [PATCH V3 1/3] x86/PCI: Fix PCI root numa_node info on AMD family15h

From: Myron Stowe
Date: Thu May 08 2014 - 12:22:56 EST


On Thu, May 8, 2014 at 9:37 AM, Robert Richter <rric@xxxxxxxxxx> wrote:
> On 08.05.14 10:21:07, Suravee Suthikulanit wrote:
>> The reason I put it all these comments here is because it took us a while to
>> discuss what to do with this file going forward. There were some confusions.
>> Therefore, I just want to document it here.

I agree. Hopefully anyone getting into this in the future will be
able to find this thread in the archives as it has been enlightning

>>
>> Also, the check for (boot_cpu_data.x86 > 0x11) was needed because it should
>> not be done for family15h.
>
> Yes, the only functional change of this patch is adding the bridge and
> the family check, right? Basically:
>
> + { 0, 0x18, PCI_VENDOR_ID_AMD, 0x1600 },
>
> and
>
> + /*
> + * The following code is only supported until Fam11h.
> + * Newer processors will depend on ACPI MCFG table instead.
> + */
> + if (boot_cpu_data.x86 > 0x11)
> + return 0;
> +
>
> This patch should stripped down to only those changes with a
> split. And maybe this should be added to linux-stable?
>
> All other rework is a different story... Can be done on top of this,
> though I would drop it.

I understand Robert's reasoning to split out the core changes (as
denoted above). However, I *would* tend to follow on with an
additional subsequent patch that has the rest of the content as it
cleans this area up (as opposed to dropping it all together). It
makes the code a little clearer and is basically little to no risk (no
functional change).

Myron
>
> -Robert
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/