On Saturday 21 March 2015, Richard Cochran wrote:
> On Sat, Mar 21, 2015 at 02:16:41AM +0100, Arnd Bergmann wrote:
> > This was the first idea, but it seems a bit silly when all the drivers
> > use a 64-bit nanosecond value just like ktime_t.
>
> Not true of all drivers. In fact, the most
On Sat, Mar 21, 2015 at 08:24:09AM +0100, Richard Cochran wrote:
>
> I disagree with the approach presented here. The problem at hand is
> the 2038 issue. Let's fix that first, in the easiest way, with the
> least churn, namely by using timespec64 in place of timespec. Once
> that is done, we
On Fri, Mar 20, 2015 at 05:49:51PM +0100, Richard Cochran wrote:
> There is really no need for any dancing around here. There are
> seventeen users total.
>
> drivers/net/ethernet/adi/bfin_mac.c
> drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>
On Sat, Mar 21, 2015 at 02:16:41AM +0100, Arnd Bergmann wrote:
> This was the first idea, but it seems a bit silly when all the drivers
> use a 64-bit nanosecond value just like ktime_t.
Not true of all drivers. In fact, the most capable devices (phyter
and i210) have a split representation.
>
On Sat, Mar 21, 2015 at 02:16:41AM +0100, Arnd Bergmann wrote:
This was the first idea, but it seems a bit silly when all the drivers
use a 64-bit nanosecond value just like ktime_t.
Not true of all drivers. In fact, the most capable devices (phyter
and i210) have a split representation.
On Fri, Mar 20, 2015 at 05:49:51PM +0100, Richard Cochran wrote:
There is really no need for any dancing around here. There are
seventeen users total.
drivers/net/ethernet/adi/bfin_mac.c
drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
On Sat, Mar 21, 2015 at 08:24:09AM +0100, Richard Cochran wrote:
I disagree with the approach presented here. The problem at hand is
the 2038 issue. Let's fix that first, in the easiest way, with the
least churn, namely by using timespec64 in place of timespec. Once
that is done, we can
On Saturday 21 March 2015, Richard Cochran wrote:
On Sat, Mar 21, 2015 at 02:16:41AM +0100, Arnd Bergmann wrote:
This was the first idea, but it seems a bit silly when all the drivers
use a 64-bit nanosecond value just like ktime_t.
Not true of all drivers. In fact, the most capable
On Friday 20 March 2015, Richard Cochran wrote:
> Instead of changing to ktime_t, just use timespec64 instead. That
> way, each change will be a couple of lines per file.
This was the first idea, but it seems a bit silly when all the drivers
use a 64-bit nanosecond value just like ktime_t. While
On Fri, Mar 20, 2015 at 02:43:42PM +0100, Arnd Bergmann wrote:
> Doing gettime separately from settime would be rather silly here, so trying
> to avoid the conditional would mean doing a single large patch across all
> drivers.
There is really no need for any dancing around here. There are
On Friday 20 March 2015, Richard Cochran wrote:
> On Fri, Mar 20, 2015 at 09:54:05AM +0800, Baolin Wang wrote:
> > Next patch series will contain all of the drivers which need to be changed.
> > But i think the conditional in ptp_clock.c can still in there.
>
> Why?
>
> > Because our plan is
On Fri, Mar 20, 2015 at 09:54:05AM +0800, Baolin Wang wrote:
> Next patch series will contain all of the drivers which need to be changed.
> But i think the conditional in ptp_clock.c can still in there.
Why?
> Because our plan is once all the drivers are converted, i will remove the
>
On Fri, Mar 20, 2015 at 09:54:05AM +0800, Baolin Wang wrote:
Next patch series will contain all of the drivers which need to be changed.
But i think the conditional in ptp_clock.c can still in there.
Why?
Because our plan is once all the drivers are converted, i will remove the
conditional,
On Friday 20 March 2015, Richard Cochran wrote:
Instead of changing to ktime_t, just use timespec64 instead. That
way, each change will be a couple of lines per file.
This was the first idea, but it seems a bit silly when all the drivers
use a 64-bit nanosecond value just like ktime_t. While
On Friday 20 March 2015, Richard Cochran wrote:
On Fri, Mar 20, 2015 at 09:54:05AM +0800, Baolin Wang wrote:
Next patch series will contain all of the drivers which need to be changed.
But i think the conditional in ptp_clock.c can still in there.
Why?
Because our plan is once all the
On Fri, Mar 20, 2015 at 02:43:42PM +0100, Arnd Bergmann wrote:
Doing gettime separately from settime would be rather silly here, so trying
to avoid the conditional would mean doing a single large patch across all
drivers.
There is really no need for any dancing around here. There are
On Thu, Mar 19, 2015 at 01:45:07PM +0800, Baolin Wang wrote:
> diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
> index 296b0ec..46425ad 100644
> --- a/drivers/ptp/ptp_clock.c
> +++ b/drivers/ptp/ptp_clock.c
> @@ -106,14 +106,30 @@ static int ptp_clock_getres(struct posix_clock *pc,
On Thu, Mar 19, 2015 at 01:45:07PM +0800, Baolin Wang wrote:
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index 296b0ec..46425ad 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -106,14 +106,30 @@ static int ptp_clock_getres(struct posix_clock *pc,
This patch introduces another two options to get/set time with "ktime_t"
type in ptp clock operation.
Original code will set/get time through the settime/gettime interfaces
with "timespec" type, that will cause break issue in year 2038. And now
introducing the new setktime/getktime interfaces
This patch introduces another two options to get/set time with ktime_t
type in ptp clock operation.
Original code will set/get time through the settime/gettime interfaces
with timespec type, that will cause break issue in year 2038. And now
introducing the new setktime/getktime interfaces with
20 matches
Mail list logo
