Re: [PATCH net 2/3] net: dsa: mv88e6xxx: read cycle counter period from hardware

[Andrew Lunn <andrew@lunn.ch>]

> +static const struct mv88e6xxx_cc_coeffs *
> +mv88e6xxx_cc_coeff_get(struct mv88e6xxx_chip *chip)
> +{
> +	u16 period_ps;
> +	int err;
> +
> +	err = mv88e6xxx_tai_read(chip, MV88E6XXX_TAI_CLOCK_PERIOD, &period_ps, 1);
> +	if (err) {
> +		dev_warn(chip->dev, "failed to read cycle counter period");
> +		return chip->info->ops->ptp_ops->default_cc_coeffs;
> +	}
> +
> +	switch (period_ps) {
> +	case 8000:
> +		return &mv88e6xxx_cc_8ns_coeffs;
> +	case 10000:
> +		return &mv88e6xxx_cc_10ns_coeffs;
> +	default:
> +		dev_warn(chip->dev, "unexpected cycle counter period of %u ps",
> +			 period_ps);
> +		return chip->info->ops->ptp_ops->default_cc_coeffs;

This chip mv88e6xxx_cc_coeffs vs ptp_ops mv88e6xxx_cc_coeffs all seems
a bit messy.

The mv88e6xxx_tai_read() MV88E6XXX_TAI_CLOCK_PERIOD is not going to
fail, except for the hardware is dead. There is nothing you can do
about that, so return the error code and let the probe fail.

What you are more worried about is if the value you get back is not
what you expect. It is not 8000 or 10000. I would do a dev_err() and
return -ENODEV, and let the probe fail. The datasheets suggests this
should not happen. But if it does, we should get reports from users
that PTP is issuing an error and the switch is not probing. We can
then fix the problem.

You can then drop mv88e6xxx_cc_coeffs from ptp_ops.

    Andrew

---
pw-bot: cr