> > Rename I2C_FUNC_SMBUS_HWPEC_CALC as I2C_FUNC_SMBUS_PEC, and list that > > functionality as always available through the software implementation. > > Update documentation accordingly (and list similar requirements). > > > > The way it's currently packaged doesn't present the capability in a > > useful way. Basically, it's always available -- except when the I2C > > stack is running on SMBus hardware without PEC support in hardware. > > Actually, except when the driver does not support it (drivers could lack > PEC support while the hardware can do it.) Fair enough, although that's not very distinguishable from the case of no hardware support. Feel free to update that part of the patch comment appropriately. > > > > ioctl(file,I2C_TENBIT,long select) > > Selects ten bit addresses if select not equals 0, selects normal 7 bit > > - addresses if select equals 0. Default 0. > > + addresses if select equals 0. Default 0. This request is only valid > > + if the adapter has I2C_FUNC_10BIT_ADDR. > > > > ioctl(file,I2C_PEC,long select) > > Selects SMBus PEC (packet error checking) generation and verification > > if select not equals 0, disables if select equals 0. Default 0. > > - Used only for SMBus transactions. > > + Used only for SMBus transactions; only valid if the adapter has > > + I2C_FUNC_SMBUS_PEC. > > Not correct. PEC being optional, chip drivers (or i2c-dev users) can > declare themselves PEC-compliant and let the adapter driver decide > whether it can actually do PEC or not. This is the right way to do it. > So a better wording would be "only has an effect if..." Depends on what you mean by "valid"; from my perspective, it's not valid without efficacy. That happens to be part of the first definition in my handy dictionary.
