Re: [PATCH v5] i2c: imx: honour I2C_M_IGNORE_NAK

[Haobin Jiang]

Hi Carlos,

> Why not follow community rule to make patch...?

You are right, and thank you for taking the time to point it out.

> At higher version, better commit log and put change to commit log bottom
> with extra lines like your V3 patch[2].

Agreed. When I prepared V5, I regenerated the log from the current diff
and did not carry forward the problem description, the test evidence, or
the review history from V2/V3/V4. That is my responsibility as the
submitter.

> I think V5 patch commit log should be better with shorter and clearer
> problem description, reproduction, resolution, verification based on V2
> patch[1] and V3 patch[2].

I will rewrite it that way for V6. The commit log will cover the
problem, the resolution, the reproduction/verification, and the review
history with links to V1-V5. I will put the changelog below a single
`---` line, like V3.

> But abviously, this patch is generated by AI, and it dropped most commit
> and discussion details from previous patches.

That is a fair criticism of V5. The tool produced a shorter log; I should
have caught that before sending. I will restore the AI-assistance note
from V3/V4 and describe which parts were tool-assisted and how I verified
them. I will not resend until the V6 log is self-contained and I have
re-checked the new zero-length guard. I will state clearly what was and
was not tested.

One point I want to be explicit about: the V5 guard only rejects
I2C_M_RD + I2C_M_IGNORE_NAK + len == 0. It does not fix the pre-existing
unflagged zero-length read path. That scope is a deliberate choice, and
I will document it in V6 rather than imply the general issue is fixed.

> AI-generated patches should be subject to more rigorous review and
> testing... humans must always remain in control in whole flow.

Understood. I will keep the human review and test evidence in the
changelog, and I will be the one accountable for the content.

Thanks,
Haobin