Re: [PATCH net-next v13 05/12] dpll: sit9531x: register DPLL devices and pins

[Ali Rouhi]

On Wed, 14 Oct 2026, sashiko-bot@xxxxxxxxxx wrote:

Reply inline.

> >                 rc = sit9531x_chan_state_fetch(sitdev, i);
>
> [Severity: Low] sit9531x_chan_state_fetch() explicitly invokes
> sit9531x_prio_table_read(), which is documented as requiring the
> caller to hold sitdev->multiop_lock to protect paged I2C register
> accesses. Is it intentional to omit the lock acquisition here? The
> adjacent loops in this initialization sequence acquire the lock
> before calling the state fetchers.

Not intentional, and v14 takes the lock here.

The lock was present one patch later: from 06/12 onwards this loop
runs under multiop_lock.  Read on its own, 05/12 reaches
sit9531x_prio_table_read() without the lock its kernel-doc requires,
next to two fetchers in the same sequence that take it.  v14 moves the
lock to the patch that introduces the caller.

No second thread can reach these registers in either arrangement.
Probe runs before the DPLL devices are registered, before the periodic
work is queued and before the interrupt is enabled, so it is the only
code touching the device at that point.  The point stands regardless:
the function states the rule, and this caller did not follow it.

> > +   pin = kzalloc_obj(*pin, GFP_KERNEL);
>
> [Severity: Low] Is kzalloc_obj defined somewhere in the tree? It does
> not appear to exist in the standard kernel API, which will result in
> a build failure during compilation. Should this be replaced with
> kzalloc(sizeof(*pin), GFP_KERNEL)?

It exists.  kzalloc_obj() is in include/linux/slab.h, alongside
kmalloc_obj() and kzalloc_objs().  The series is based on 45ad84d2800e,
which has it, and every patch builds there with W=1 and sparse.

The same applies to the second instance on sitdpll.