On Thu, Sep 28, 2017 at 10:25:34AM -0500, Brandon Streiff wrote:
> +static int mv88e6xxx_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> +{
> + if (scaled_ppm == 0)
> + return 0;
> +
> + return -EOPNOTSUPP;
> +}
We really want to have an adjustable clock here. More
On Fri, Sep 29, 2017 at 03:17:02PM +, Brandon Streiff wrote:
>
> Although now that I'm looking it over again, I'm also not certain of
> the need. Even if we're called more frequently than we expect, that
> doesn't seem to be harmful with regard to timekeeping. Hmm.
Just keep it simple and dr
On Fri, Sep 29, 2017 at 03:28:02PM +, Brandon Streiff wrote:
>
> NETWORK_PHY_TIMESTAMPING implies NET_PTP_CLASSIFY (which I do use)
> and net/core/timestamping.c (which I didn't). It probably makes more
> sense to just depend on NET_PTP_CLASSIFY directly.
Yes, that makes sense to do, if you c
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, September 28, 2017 11:57 AM
>
> It is the MAC which is doing the time stamping, not they PHY?
> So why NETWORK_PHY_TIMESTAMPING?
NETWORK_PHY_TIMESTAMPING implies NET_PTP_CLASSIFY (which I do use) and
net/core/timestamping.c (which I d
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, September 28, 2017 12:03 PM
>
> > + bool timeout = time_is_before_jiffies(chip->last_overflow_check +
> > + MV88E6XXX_TAI_OVERFLOW_PERIOD);
> > +
> > + if (timeout) {
>
> Why do you need this
> +/* The 32-bit timestamp counter overflows every ~34.3 seconds; this task
> + * forces periodic reads so that we don't miss any wraparounds.
> + */
> +#define MV88E6XXX_TAI_OVERFLOW_PERIOD (34 * HZ / 2)
> +static void mv88e6xxx_ptp_overflow_check(struct work_struct *work)
> +{
> + struct dela
On Thu, Sep 28, 2017 at 10:25:34AM -0500, Brandon Streiff wrote:
> This patch adds basic support for exposing the 32-bit timestamp counter
> inside the mv88e6xxx switch code as a ptp_clock.
>
> Signed-off-by: Brandon Streiff
> ---
> drivers/net/dsa/mv88e6xxx/Kconfig | 10 +++
> drivers/net/dsa
7 matches
Mail list logo
