Guenter, > I think there is a difference between a bad driver or underlying hardware. To > me, "shipped" applies to hardware or firmware which can not be upgraded, not to > the software running on it. OK. Valuable distinction. > "board support hosted in the I2C directory". But that is exactly what I am > talking about, isn't it ? I have board specific multiplexers and a board > specific I2C controller, and that is just talking about the I2C code. Yes and no. I think I can accept that some hardware has GPIOs wired to handle I2C arbitration. I still have problems in having arbitrator drivers per board, each one with various ideas how to do it. That would be a maintenance horror and has nothing to do with I2C, strictly speaking. What I would love to see is a few generic arbitrator drivers, e.g. utilizing a timeout-based scheme (as proposed here). Or like the old SCSI method putting IDs on the wire and the lowest wins. Stuff like that. > A better example might be Kontron board support. They implement gpio, I2C mux, > and a watchdog in a PLD. They too have an access arbitration scheme where > one has to acquire a hardware mutex before accessing the pld, if I understand > correctly because some microcontroller might need to access it as well. > Leaving the actual code aside, would you reject that too if you don't like > the arbitration scheme, or because you don't want to have board support > in the i2c directory ? If I understood correctly, getting the mutex would be done in some platform code and the I2C driver will simply call the necessary function to obtain and release the mutex. Or maybe the MFD layer can help, dunno. Both are fine with me and I don't care about the actual PLD arbitration. Thanks, Wolfram -- 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
