Re: [PATCH net-next v12 08/12] dpll: sit9531x: add support to get and set frequency on pins

[Ali Rouhi <arouhi@sitime.com>]

On Tue, 13 Oct 2026, Ivan Vecera wrote:

> > +       /*
> > +        * An output's current rate is the one its divider produces, so read
> > +        * it rather than assume the first entry of a list of the rates the
> > +        * board supports is the one in force.  A rate taken from firmware
> > +        * that the part is not running would be reported as current and,
> > +        * worse, used as the output period the phase adjust quantizes
> > +        * against.  An output the configuration does not route has no rate
> > +        * to read, which is not an error.
> > +        */
> > +       if (dir == DPLL_PIN_DIRECTION_OUTPUT &&
> > +           index < sitdev->info->num_outputs) {
> > +               u64 hw_freq;
> > +
> > +               mutex_lock(&sitdev->multiop_lock);
> > +               rc = sit9531x_output_freq_get(sitdev, index, &hw_freq);
> > +               mutex_unlock(&sitdev->multiop_lock);
> > +               if (!rc)
> > +                       curr_freq = hw_freq;
> > +       }
> > +
> >   skip_fwnode_props:
>
> This read-back sits before the skip_fwnode_props label, so an output with
> no firmware node, or with a node that has no supported-frequencies-hz.
>
> For such an output curr_freq stays at the zero-initialized
> sitdev->out[index].freq, so the current rate is neither cached nor listed
> ahead of the 1 Hz to 1 GHz fallback range.  Was the read-back meant to
> cover outputs without a firmware frequency list as well?

Yes, it was meant for every output. An output the board describes
without a rate list, or does not describe at all, still runs at
whatever its divider produces, and that is the rate to publish. Sitting
before the label it was skipped for exactly those outputs.

In v13 the read-back sits past the label, so each output publishes the
rate its divider produces ahead of the fallback range. The two INTSYNC
early returns move above it, since neither of those pins carries a
frequency attribute and neither has a divider to read. The comment
above the read-back says this rather than the old sentence about a
routed output, which was describing the restriction rather than the
intent.

Thanks,
Ali