On Mon, Apr 28, 2014 at 8:02 PM, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> wrote: > Sorry for late reply. My concern is that removing the "quirk_amd_nb_node()" > will affect the value of "numa_node" of the host bridge devices (i.e. > X:00.[18|19|1a|1b|1c|1d|1e|1f].X). I am not sure if any code is using this > information. But in theory, these host-bridge devices are not on the same > node as where the PCI root complex lives (e.g. 0 and 4 from the example > above). I doubt anything in the kernel uses the node number for these devices (00:[18|19|...]). The only place the PCI core uses it is to run a driver probe method on the same node as the device. Are there even drivers for these devices? They aren't PCI-to-PCI bridges, so there are no devices below them that would be affected by their node numbers. > If we want the "numa_node" to really representing the actual node, then the > quirk has to stay for now. We might need to come up with a different logic > to replace the quirks here, which would automatically determine the actual > node value for these host-bridge devices. It sounds like the numa_node for these devices in sysfs is misleading unless we have a quirk like this. If that's important, I think it could be fixed by having the BIOS provide _PXM methods for them. But I don't think it is, and I'm inclined to remove the quirk. I'm pushing hard to get rid of CPU-specific code like this because there are generic methods to do it, e.g., _PXM, and the CPU-specific code is a perennial maintenance headache. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
