On Wed Oct 21 11:34, Mika Westerberg wrote: > On Wed, Oct 21, 2015 at 01:21:16AM -0700, Dustin Byford wrote: > > On Wed Oct 21 11:12, Mika Westerberg wrote: > > > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > > > I considered it, but I thought a default that fairly closely matches the > > > > old behavior was more convenient. > > > > > > > > On the other hand, leaving it up to the controllers makes it all very > > > > explicit and perhaps simpler to reason about. > > > > > > > > > > > > I could be convinced either way. But, if we move it to the controller > > > > drivers, which ones need the change? > > > > > > > > grep -i acpi drivers/i2c/busses/i2c* > > > > > > > > shows 18 drivers that might care. > > > > > > I'm quite confident the designware I2C is enough for now. Intel uses it > > > for all SoCs with LPSS and I think AMD has the same block for their I2C > > > solution. > > > > I certainly care about i801, ismt, and isch. Doesn't this affect any > > i2c controller with clients that may be enumerated through ACPI? > > Yes, but so far I haven't seen any other devices being used for this > than the I2C designware. > > Which hardware you are testing this patch on? I'm working with a number of x86-based network switch platforms. Mostly rangeley at the moment, but I'm sure others are in the works. Have a look at: http://www.opencompute.org/wiki/Networking/SpecsAndDesigns for examples. My goal, hence the recent patches, is to help the network switch industry move a lot of platform description into ACPI. That means lots of complicated I2C trees; switches are full of I2C devices. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
