* Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > On Tuesday 06 October 2009 11:51:22 am Yinghai Lu wrote: > > Bjorn Helgaas wrote: > > > On Sunday 04 October 2009 10:54:24 pm Yinghai Lu wrote: > > >> for intel system with multi IOH. we could read peer root resource from PCI conf, > > >> and don't trust _CRS again for root bus > > > > > > Ugh. Are we going to end up with amd_bus.c, intel_bus.c, nvidia_bus.c, > > > broadcom_bus.c, serverworks_bus.c, etc.? > > only needed when you have muti ... > > I think that translates to "yes, we will need all those bits as soon > as those vendors support larger systems with multiple IOHs." And I > think that's the wrong answer. Why is having cleanly separated per vendor information/driver wrong? I think it's the right answer in most cases. _Especially_ when the other option is to 'rely on the firmware'. > > again we should trust HW conf than BIOS. > > Certainly there's a tradeoff between a generic driver that relies on > the BIOS, and a platform-specific driver that uses only the hardware. > The first leaves us vulnerable to BIOS bugs, but the second leads to a > plethora of drivers that require updates as hardware changes. We do that quite well in Linux - it's one of our main strengths. Why should we have to rely on correct firmware? Why is it wrong to know about the hw's structure, to query the hardware and ignore the firmware if the hardware state tells us otherwise? 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
