> > +static int qed_ptp_hw_adjfreq(struct qed_dev *cdev, s32 ppb) {
> > + struct qed_hwfn *p_hwfn = QED_LEADING_HWFN(cdev);
> > + struct qed_ptt *p_ptt = p_hwfn->p_ptp_ptt;
> > + int drift_dir, best_val, best_period;
> > + s64 period, dif, dif2;
> > + u32 drift_ctr_cfg = 0;
> > + s64 best_dif, val;
> > + u32 drift_state;
> > +
> > + best_dif = ppb;
Crap. Apparently I've sent my early draft.
'best_dif' is the culprit for the odd results [not the -8].
In the previous calculation it was the theoretical upper-bound,
now it should be an unreachable number instead [7000000000].
> > + best_period = 2;
> > + best_val = 0;
> > + drift_dir = 1;
> > +
> > + if (ppb < 0) {
> > + ppb = -ppb;
> > + drift_dir = 0;
> > + }
> > +
> > + if (ppb == 0) {
> > + /* No clock adjustment required */
> > + best_val = 0;
> > + best_period = 0xFFFFFFF;
> > + } else {
> > + /* Adjustment value is up to +/-7ns, find an optimal value in
> > + * this range.
> > + */
> > + for (val = 7; val > 0; val++) {
>
> This is an endless loop. ------------- ^^^^^
And this, obviously...
>
> Besides that, this code returns some very strange values. For example, for
> ppb = 100106, 100107, and 100108. Also ppb = 1...8 all return 0/40.
>
> Trouble with the -= 8?
>
> I can only recommend plotting all of the raw errors and also average
> (RMS) error over the nominal interval ppb = 1...500000.
>
I'll send the corrected v6 tomorrow. Sorry about this one.
