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. Would you be okay with changing the PCI ID that the sb_edac driver binds to? That is, let it claim any of the other mess of devices it talks to. Alternatively, I could shove the whole thing into the edac-sbridge module. > > > 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. The controller is, indeed, amazingly racy. But I have access to (NDAed) reference code for this, and I need it for NVDIMM support, which is a real thing that AFAICT Intel's trying to support, so this stuff is really supposed to work. (The reference code performs undocumented incantations that I can't (yet?) talk about.) Is there any way to get sb_edac to expose, for each DIMM, the physical address range that the DIMM maps to (or at least the range that contains all the interleaved bits of it). That would give me a nice sanity check to validate that the firmware isn't lying about the NVDIMM aperture. (Don't use my old i2c_imc submission as a valid sample -- it blows up terribly when closed-loop thermal throttling is on.) --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
