* Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Wed, Jun 20, 2012 at 11:46 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > > > As far as I can tell, here's Yinghai's recommendation: the > > user argument should not override BIOS _PXM because if the > > BIOS gets the _PXM wrong, the user won't be able to work > > around it with the argument, which will force the vendor to > > fix the BIOS. > > > > I'm not buying it. The convention that user-supplied > > arguments always take precedence is useful, easy to > > document, and matches user expectations. It allows the user > > to work around both missing _PXM and incorrect _PXM. > > if the vendor provide _PXM, that _PXM should be right and be > trusted. > > if the vendor does not provide _PXM, we can have command line > to input it before user can get one updated BIOS from vendor. So how about an incorrect _PXM, or a slightly inefficient one? Why shouldn't it be possible for the user to override it? I mean, if we create a parameter space that tweaks data then why not make it complete and allow *all* firmware data to be (optionally) modified, from the kernel boot line? Thanks, Ingo -- 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
