On Thu, 2010-04-08 at 15:50 -0700, Jason Gunthorpe wrote: > On Thu, Apr 08, 2010 at 03:26:41PM -0700, Ralph Campbell wrote: > > On Thu, 2010-04-08 at 15:08 -0700, Jason Gunthorpe wrote: > > > On Thu, Apr 08, 2010 at 02:29:53PM -0700, Ralph Campbell wrote: > > > > > > > One other place that has multiple values is dumping the QSFP > > > > data from the IB cable. > > > > > > I was going to comment that building your own I2C subsystem is kinda > > > strange, can't the in-kernel stuff be used? > > > It is a bit strange but we have had this discussion before with > > the ib_ipath driver. Basically, the devices connected to the bus > > weren't really I2C compliant. Since we had to support the > > non-standard parts, it was easier to have only one set of code > > that could handle both. > > Is this still true on qib? I didn't notice anything too obviously > weird, and QSFPs are clearly standard i2c.. > > The i2c layer has a pretty flexible definition of i2c these days.. > > Jason
I would be very reluctant to change this code. One device we have doesn't have an i2c address, the "address" is the address of memory within the chip, not the address of the chip on the bus. Reading some of the QSFP cable's EEPROM caused another EEPROM on the bus to be erased. We had to put in defensive code to check for this case. I'm not the expert who wrote this code (he retired) so I would have to do a lot of work making sure the older parts and cables with these problems worked after a major rewrite of the code. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
