[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161209085752.GB16009@localhost.localdomain>
Date: Fri, 9 Dec 2016 09:57:52 +0100
From: Richard Cochran <richardcochran@...il.com>
To: Harini Katakam <harinikatakamlinux@...il.com>
Cc: Andrei Pistirica <Andrei.Pistirica@...rochip.com>,
netdev@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
David Miller <davem@...emloft.net>,
Nicolas Ferre <nicolas.ferre@...el.com>,
Harini Katakam <harini.katakam@...inx.com>,
Punnaiah Choudary Kalluri <punnaia@...inx.com>,
"michals@...inx.com" <michals@...inx.com>,
Anirudha Sarangi <anirudh@...inx.com>,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
alexandre.belloni@...e-electrons.com, tbultel@...elsurmer.com,
Rafal Ozieblo <rafalo@...ence.com>
Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence
GEM.
On Fri, Dec 09, 2016 at 11:07:23AM +0530, Harini Katakam wrote:
> I'm afraid I don't get why we are choosing the most limited max adj..
> Sorry if I'm missing something - could you please help me understand?
This max_adj is only important when the local clock offset is large
and user space chooses not to step the time value. In that case, user
space will want to run the clock as fast (or as slow) as possible in
order to catch up with the remote clock.
The driver must provide a max_adj that is always safe for user space
to apply via the clock_adjtime() system call.
HTH,
Richard
Powered by blists - more mailing lists