On Wed, Aug 14, 2013 at 5:32 PM, Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> wrote: > Em Wed, 14 Aug 2013 16:04:06 -0600 > Bjorn Helgaas <bhelgaas@xxxxxxxxxx> escreveu: > >> On Wed, Aug 14, 2013 at 3:45 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> > I'm working on a driver for the Sandy Bridge iMC SMBUS controller. It >> > (mostly) lives on pci device 15, function 0. So my driver registers >> > as an ordinary PCI driver for that device (8086.3ca8). >> > >> > The problem is that sb_edac also registers for 8086.3ca8. This means >> > that the drivers conflict. The sb_edac driver is actually driving >> > functionality that's split between eleven (!) different pci devices, >> > none of which overlaps the stuff I'm driving. >> > >> > What's the Right Way (tm) to handle this? Should I just modify >> > sb_edac to pick a different one of the 11 devices to probe? Is there >> > some standard way to handle this in the PCI code? > > The sb-edac driver needs to see lots of different devices in order to > work, as the memory controller registers are on different PCI IDs. > > So, there's not much that can be done there, I'm afraid. > > Btw, we almost added a code there to also access the SMBUS, in order to > enumerate the memories. We ended by not adding, because we were afraid > or risking to race with BIOS. A race while access an I2C EEPROM memory > can be very bad, as a read operation might be understood as write, thus > destroying the DIMM configuration. Do you have any more details about this issue? As far as I can tell (by experiment, not by magic reference code), it's simply not possible to control the SMBUS in CLTT mode. I can't find any evidence of BIOS, SMI code, or anything else using the SMBUS registers, so races against other software-ish things seem unlikely. --Andy -- 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
