Re: [PATCH net 0/2] dpll: zl3073x: fix output pin esync and sibling notifications

[Ivan Vecera]

On 10/1/26 10:09 AM, netdev-bot+sinfo@xxxxxxxxxx wrote:
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>   - How the issue was discovered, e.g. hit in production, hit during
>     development, syzbot report, manual code inspection, LLM or static
>     analysis tool scan.
>
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Hi,

thanks, here is the missing information for both patches.

Both issues were found while developing and testing.

Patch 1 fixes a bug that was actually triggered. After changing an
output pin's frequency the embedded sync output stopped working
correctly, which I confirmed on an oscilloscope - the embedded sync ran
at the wrong frequency and duty cycle because its period and width still
matched the previous carrier. In addition, when the new carrier was
1 Hz, esync_get() returned -EOPNOTSUPP, so the stale eSync mode became
invisible and could no longer be disabled.

Patch 2 was found by code inspection rather than triggered at runtime.
Both pins of an output pair drive the same HW output, so changing e.g.
the esync configuration or phase adjustment through one pin also changes
the sibling pin's effective configuration. A dpll pin-get on the sibling
pin returns the correct current values, but because no change
notification is emitted for it, userspace is never told that the
configuration changed asynchronously through the other pin.

Regards,
Ivan