On Sun, Nov 17, 2013 at 05:53:29PM +0100, Andreas Werner wrote: > On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote: > > > > > Is there another reason why pch_i2c_getack returned EPROTO? > > > May be ENXIO was introduced later? > > > > Imperfect review :) > > > > > I think we can just replace the -EIO with -ENXIO or do you want to pick > > > up the return > > > vale of pch_i2c_getack and return that ? > > > > The latter. As a rule of thumb, it is usually more sustainable to pass > > through error codes. Overloading them should only be done when really > > necessary IMO. > > > Ok, if that will be ok in pch_i2c_wait_for_check_xfer i will resend > the patch. > > ret = pch_i2c_getack(adap); > > if (ret) > pch_dbg(adap, "Receive NACK for slave address setting\n"); > > return (int)ret;
Hmm, the cast looks ugly. Looking at the driver more closely, my
preferred solution would be to elimiate the getack function and just do
that directly in wait_for_check_xfer:
if (ioread32(adap->pch_base_address + PCH_I2CSR) & PCH_GETACK) {
pch_dbg ...
return -ENXIO;
}
Something like that...
signature.asc
Description: Digital signature
