[lm-sensors] Re: sclhi retval not tested in i2c-algo-bit.c

[lm-sensors] Re: sclhi retval not tested in i2c-algo-bit.c

[Jean Delvare]

Hi Karel,

> Hello Simon,

I wouldn't expect an answer from Simon. He left the i2c & lm_sensors
projects long ago. The lm_sensors mailing-list is the best place for
this kind of questions.

> drivers/i2c/algos/i2c-algo-bit.c sometimes tests return value of sclhi
> function and sometimes not. Shouldn't this always be tested?

I would guess so.

> I have a problem that I have an parport adapter which is optically
> isolated, and the isolated half is powered separately. The adapter
> supports SDA and SCL bidirectionally.
> 
> When the other half is not powered, the SDA/SCL readback doesn't of
> course work, neither the devices connected react. But I discovered
> that although the .timeout in the driver is HZ (=1sec), the delay
> introduced on kernel startup is 90 seconds.
> 
> That means that the timeout is left to timeout 90 times before the
> driver returns. I should that first timeout should cause the parport
> to be considered not mentally present and all operations on it
> immediately fail.

Is this with or without i2c_algo_bit.bit_test=1?

Without it, loading the i2c-parport driver should not introduce any kind
of delay. Trying access it would, but then the repeated timeouts you
observe could be caused by the process accessing it, whatever it is,
rather than i2c-algo-bit. I never experienced such long delays myself.
Can you please describe the devices found on the parallel port adapter,
and what is done to them at boot time?

> Looking into the driver, I am not wondering it is working this way :)
> I would like just to know your opinion if there isn't some deeper
> logic hidden behind what seems to me like omission.

I don't think so. Most probably it is that way just because it worked
for everyone so far. Patches to make it behave better are welcome.

Thanks,
-- 
Jean Delvare

[lm-sensors] Re: sclhi retval not tested in i2c-algo-bit.c

[Jean Delvare]

Hi Karel,

Please answer to the mailing-list rather than to me only.

> The device is I2C2P http://i2c2p.twibright.com
> It's an optically isolated parport <-> I2C converter which is
> bidirectional in both SDA and SCL. The half near PC is powered from
> the parallel port, the other half externally.
> 
> Normally, the adapter supports SCL readback. However when the remote
> part is not powered, SCL readback doesn't work. As the power applied
> to the remote half is independent from PC power (typical use is to
> hook it up to some device with 24C16 inside and using it for
> brainwashing the device), this can normally happen.

Except that you should not load a driver for unpowered hardware, as the
i2c subsystem doesn't support any kind of hotplugging.

You mentioned the fact that you had a long delay at boot time when the
"second half" was not powered on. This shouldn't happen. Even without
anything plugged on the parport, i2c-parport loads without any delay, I
just tested. This is quite logical because neither sda nor scl are read
back at i2c-parport load time (unless you set i2c_algo_bit.test_bit to
1). So I suspect that you additionally load i2c chip drivers, or run
user-space commands which generate traffic on the adapter, and this is
what causes the long delay. Please investigate in this direction.

> I have already sent you my newest patch for I2C2P which incorporated
> this. Please look at it.

Yes, I got it. BTW, it would be better if you could send patches to this
mailing-list rather than to me only. More eyes is better, and I am
rather busy myself (as you must have noticed by now). Especially the
proposed changes to i2c-algo-bit need an in-deep review (and should
really be a separate patch). This code is used by 69 drivers in the
kernel only, which I wouldn't want to break.

Thanks,
-- 
Jean Delvare