Hi Mukesh,
This is a bug that was accidentally introduced when
adjusting the wmt driver. Now fix it
what exactly is the bug which you are fixing here ?
This bug was introduced by myself in a recent commit,
id: 4b0c0569f03261aa4c10c8f5b24df6c1ca27f889
https://patchwork.ozlabs.org/project/linux-i2c/patch/20240306212413.1850236-5-andi.shyti@xxxxxxxxxx/
The function viai2c_irq_xfer() is working in the interrupt context,
if it returns a non-0 value indicating that the current msg access
has ended, otherwise it has not ended.
Should be otherway around ? zero indicates success as per general
practices.
I understand your suggestion. The return value here indicates
whether the transfer should end or not.
0 means not, and non-0 means yes(error or successful).
Also i think accordingly your commit log should have the explanation.
Yes, I should give a more detailed commit log.
For the access that msg->len is 0, when the interruption occurs,
it means that the access has ended, it should return 1;
Otherwise wait_for_completion_timeout() will timeout.
IIUC, msg->len = 0 it indicates your transfer is completed and then you
want to return 1 indicating current message transfer is successful ?
Please ammend the logs reflecting the scenario to match with the code
changes.
No, msg->len = 0 here means this is I2C_SMBUS_QUICK access.
Yes, return 1 indicating current message transfer is successful.
Hans,
Thanks
