> example, lots of graphics drivers provide i2c busses, and those busses > often contain eeproms, and, in theory, things should know that the > eeprom is associated with a particular graphics port, for example. > Unfortunately, the i2c core does not know that, things like > decode-dimms will try to decode it, sensors-detect will scan graphics > ports for motherboard sensors, etc. ACPI does now try to describe what is on an i²c bus. We perhaps don't use that information well but on a modern PC class box at least for onboard devices most of the info is there for the munching. > For extra fun, there could be drivers for different types of i2c_port. > One of them could be the "DIMM bus" driver, which would know how to > probe the i2c adapter associated with a DIMM port. Another could be > the graphics port driver, which (maybe with some extra configuration > hints from the graphics driver) could look for EDID-related things. Busses are not necessarily that tidily organised. There isn't anything saying you can't sneak multiple things on the same bus. In the graphics case its unlikely but I wouldn't rule even that out for a display panel. Once you get onto phones and tablets it seems anything goes 8) > I wonder if this would fit in well with the device tree stuff, too -- > DT has ways to say "this node links to that one", right? ACPI basically tries to describe the heirarchy of devices on the bus, but as you say the "real" device can be a rambling mix of GPIO, I²C, SPI, PCI (quite probably fake PCI at that) and other resources. If there is a legitimate use case for poking around with memory dimm i2c on these boards then really there needs to be a proper defined interface for doing so that covers firmware and OS users. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
