This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |6 +-
1 file changed, 1 insertion(+), 5
a fractional nanosecond field
that accumulates the low order bits.
Reported-by: Janusz Użycki j.uzy...@elproma.com.pl
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/mellanox/mlx4/en_clock.c |4 ++--
include/linux/timecounter.h | 19
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/freescale/fec_ptp.c | 16 +---
1 file changed, 1 insertion(+), 15
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/ti/cpts.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/amd/xgbe/xgbe-ptp.c |8 +---
1 file changed, 1 insertion(+), 7 deletions
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 11 +--
1 file changed, 1 insertion(+), 10
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/mellanox/mlx4/en_clock.c |5 +
1 file changed, 1 insertion(+), 4 deletions
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/igb/igb_ptp.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers
routine to help drivers implement the adjtime
method.
Suggested-by: Janusz Użycki j.uzy...@elproma.com.pl
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
include/linux/timecounter.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/timecounter.h b/include/linux
On Sun, Dec 21, 2014 at 07:46:59PM +0100, Richard Cochran wrote:
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
BTW, I noticed that this driver does not serialize access to the
timecounter in any way, but probably it should. Ariel
On Tue, Dec 16, 2014 at 10:31:47AM +0200, Catalin Crenguta wrote:
It seems that because the ribbon cable has both the analog and digital
signals, the analog signals are affected by the digital ones (hence
the touchscreen was working OK when the display was disabled). Putting
decoupling
On Tue, Oct 14, 2014 at 04:11:18AM -0700, Thomas Shao wrote:
In current hyper-v time sync service,it only gets the initial clock time
from the host. It didn't process the following time samples. This change
introduced a module parameter called host_time_sync. If it is set to true,
the guest
On Tue, Oct 14, 2014 at 01:04:35PM +, Thomas Shao wrote:
+ /*
+ * Use the Hyper-V time sample to adjust the guest time. The
+ * algorithm is: If the sample offsets exceeds 1 second, we
+ * directly set the clock to the server time. If the offset is
On Tue, Oct 14, 2014 at 01:04:35PM +, Thomas Shao wrote:
I really don't see the need for this. We have NTP. If the guests want to,
they
may use it. Otherwise, they have a free running clock, just like real
machines.
Sometimes the user can't setup NTP. For example the guest OS
On Tue, Oct 14, 2014 at 02:16:34PM +0100, Mike Surcouf wrote:
What is your expected value for TICK_USEC? I cant make the arithmetic work.
You double the check time if you are close but you never reduce the
check time if you are not.
Adjusting the tick count is a coarse adjustment of the
Maybe John Stultz should also go onto CC.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Tue, Oct 14, 2014 at 03:14:21PM +0100, Mike Surcouf wrote:
Even with networking I think there are other senarios where this would
be useful such as no access to an NTP server due to firewall rules or
no internal NTP or simply an admin without much knowledge of NTP.
Perhaps, but ...
On Tue, Oct 14, 2014 at 04:33:46PM +0200, Richard Cochran wrote:
IMHO, you should let the guest steer its own clock. That gives the end
user the most flexibility. Just provide the offset information, and
let a dedicated service (like ntpd or linuxptp's phc2sys) do the rest.
So if it really
On Mon, Nov 03, 2014 at 05:11:53PM -0800, John Stultz wrote:
On Mon, Nov 3, 2014 at 4:58 PM, Andy Lutomirski l...@amacapital.net wrote:
If you're going to add double-stamped packets, can you also add a
syscall to read multiple clocks at once, atomically? Or can you
otherwise add a non-perf
On Tue, Nov 04, 2014 at 09:01:31AM +0100, Arnd Bergmann wrote:
On Monday 03 November 2014 17:11:53 John Stultz wrote:
I've got some thoughts on what a possible interface that wouldn't be
awful could look like, but I'm still hesitant because I don't really
know if exposing this sort of data
On Fri, Nov 28, 2014 at 02:40:44PM +0100, Laurent Georget wrote:
@@ -101,7 +99,19 @@ combination of zero or more of the following bits:
Ordinary users are restricted to a zero value for
.IR modes .
Only the superuser may set any parameters.
+.PP
+Support for TAI (Atomic International
On Sat, Nov 29, 2014 at 12:02:33AM +0100, Laurent Georget wrote:
Thank you for your comments. Below is a new version of the patch. Less
unrelevant chit-chat, more useful information (hopefully).
Looks better to me.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Dec 30, 2014 at 06:32:01PM -0500, David Miller wrote:
Series applied, thanks Richard.
I got an automated email from
kbuild test robot fengguang...@intel.com
showing new warnings and errors introduced by this series. I'll follow
up with fixes soon.
Thanks,
Richard
--
To unsubscribe
There is no need for users of the timecounter/cyclecounter code to include
clocksource.h just for a single macro.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
include/linux/timecounter.h |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux
The timecounter/cyclecounter code has moved, so users need the new include.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
arch/microblaze/kernel/timer.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index
This driver uses the function, clocksource_khz2mult, and so it really must
include clocksource.h.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/mellanox/mlx4/en_clock.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 2c95132
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index 47c29ea..79c00f5
where possible.
Thanks,
Richard
Richard Cochran (7):
timecounter: provide a macro to initialize the cyclecounter mask
field.
bnx2x: convert to CYCLECOUNTER_MASK macro.
e1000e: convert to CYCLECOUNTER_MASK macro.
igb: convert to CYCLECOUNTER_MASK macro.
ixgbe: convert
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/igb/igb_ptp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c
b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 1d27f2d..5e7a4e3 100644
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/e1000e/netdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index e14fd85..332a298 100644
On Thu, Jan 01, 2015 at 08:41:20PM -0600, Jeff Epler wrote:
Like Laurent Georget, I found by reading ntpd source
the scale is 2^16 (i.e., 1 ~= 1.5e-5 ppm, 65536 = 1ppm)
Yep, you wont find this documented in prose anywhere, not even at
ntp.org.
-long freq;/* Frequency offset, as
On Fri, Jan 02, 2015 at 10:37:09AM -0800, John Stultz wrote:
Though, this does start to sound like issues the timekeeping code had
to resolve, so while its probably time to let some flowers bloom and
see what happens, we should be somewhat watchful for too much logic
duplication.
You took the
On Fri, Jan 02, 2015 at 05:39:17PM +0100, Laurent Georget wrote:
Ah, ok, I finally understood what you meant by fractional part.
Perhaps we could explicit it in the man page like in the following patch?
Much improved. Looks good to me.
Thanks,
Richard
--
To unsubscribe from this list: send the
On Sat, Jan 03, 2015 at 06:53:20AM -0800, Guenter Roeck wrote:
Microblaze build in linux-next fails with
arch/microblaze/kernel/timer.c:224:2: error:
implicit declaration of function 'timecounter_init'
Caused by missing include file in microblaze timer code.
Already fixed in
On Sat, Jan 24, 2015 at 12:48:56PM -0500, Daniel Church wrote:
+/*
+ * Updates a timer's overrun count while capping it to delaytimer_max
+ */
+static void posix_timer_update_overrun_count(struct k_itimer *timer,
+ unsigned int overruns)
+{
+
,
+ tkr-mask);
Coding style is strange here. It would look nicer it were like the
debug version, above.
+}
#endif
Series looks fine to me.
Acked-by: Richard Cochran richardcoch...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Tue, Feb 03, 2015 at 10:57:38AM -0800, John Stultz wrote:
Unfortunately the patch used LONG_MAX/MIN instead of
LLONG_MAX/MIN, which was fine on 64bit systems, but being
much smaller on 32bit systems caused false positives
resulting in most direct frequency adjustments to fail w/
EINVAL.
On Mon, Feb 16, 2015 at 12:18:22PM +0100, Sebastian Andrzej Siewior wrote:
- CPU hotplug works in general. Steven's test script however
deadlocks usually on the second invocation.
Where can I find Steve's hotplug test script?
Thanks,
Richard
--
To unsubscribe from this list: send
On Tue, Feb 17, 2015 at 02:03:30PM +, Stathis Voukelatos wrote:
The command string for packet matching is stored in module RAM
and consists of a sequence of 16-bit entries. Each entry includes
an 8-bit command code and and 8-bit data value. Valid command
codes are:
0 - Don't care
1 -
On Wed, Jan 28, 2015 at 03:32:58PM +0530, Preeti U Murthy wrote:
Thomas ping. Would you be posting this patch?
FYI, Thomas is temporarily out of action, in bed with the flu.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Mon, Jan 05, 2015 at 01:20:57PM +, David Laight wrote:
+/* simplify initialization of mask field */
+#define CYCLECOUNTER_MASK(bits) (cycle_t)((bits) 64 ? ((1ULL(bits))-1)
: -1)
That has me chasing through the C integer promotion rules.
Better might be:
((bits) 64 ?
On Mon, Jan 05, 2015 at 12:52:12AM -0800, Guenter Roeck wrote:
On Sat, Jan 03, 2015 at 06:01:18PM +0100, Richard Cochran wrote:
On Sat, Jan 03, 2015 at 06:53:20AM -0800, Guenter Roeck wrote:
Microblaze build in linux-next fails with
arch/microblaze/kernel/timer.c:224:2: error
On Mon, Jan 05, 2015 at 02:52:59PM +0100, Richard Cochran wrote:
Nope. It probably needs just one line:
+ #include linux/timecounter.h
A better fix would be to add this one line into
include/clocksource/arm_arch_timer.h
because that will fix
virt/kvm/arm/arch_timer.c
which
-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/clocksource/arm_arch_timer.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 6a79fc4..8e67e72 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b
On Mon, Jan 05, 2015 at 03:43:22PM +0100, Richard Cochran wrote:
A better fix would be to add this one line into
include/clocksource/arm_arch_timer.h
On second glance, this is not right. I just posted the correct fix.
Thanks,
Richard
--
To unsubscribe from this list: send the line
This series added:
+ /* Return 50% of the actual maximum, so we can detect bad values */
+ max_nsecs = 1;
and then...
On Fri, Jan 09, 2015 at 04:34:21PM -0800, John Stultz wrote:
@@ -760,7 +746,8 @@ void __clocksource_updatefreq_scale(struct clocksource
*cs, u32 scale, u32 freq)
On Fri, Jan 09, 2015 at 04:34:18PM -0800, John Stultz wrote:
So this series is the result of earlier discussions with Linus
and his suggestions around improvements to clocksource validation
in the hope we can more easily catch bad hardware.
Why penalize most users just because of a random
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard protections to prevent a multiplciation
overflow from ocurring.
This is just papering over the problem. The hard protection should
be having a tick
On Sun, Jan 11, 2015 at 11:41:03AM -0800, David Decotigny wrote:
From: David Decotigny de...@googlers.com
FYI, patches for 'net-next' need to be addressed to both the
networking list and to the maintainer.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Mon, Jan 12, 2015 at 10:36:58AM -0800, John Stultz wrote:
So, the first patch had a cleanup which removed case where the max
mult value was being calculated assuming nanoseconds was a s64 instead
of a u64, which resulted in the max_idle_ns to be halved. So this
doesn't actually cost us more
On Mon, Jan 12, 2015 at 09:30:07PM +0100, Richard Cochran wrote:
On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote:
You say the tick should be scheduled before the clocksource wraps -
but we have logic to do that.
Well that is a shame.
Arg, I mean, not a shame that we have logic
On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote:
On Sun, Jan 11, 2015 at 4:41 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard
On Tue, Jan 13, 2015 at 08:02:53AM +1300, Linus Torvalds wrote:
Indeed. It's making things more robust in the face of _known_ issues.
Even with a perfectly designed timer (which we so far have never
seen), interrupts get delayed etc, so trying to stretch it to the
limit of the timer is simply
On Mon, Jan 12, 2015 at 10:22:11AM -0800, John Stultz wrote:
Yea, I've not looked at the actual performance impact yet, but things
like the read-time capping (which is in the hot path) could be put
under a debug config. Thanks for the suggestion!
Having a broken clock is like having a broken
On Sun, Mar 22, 2015 at 03:28:46AM +0100, Arnd Bergmann wrote:
I think it would be good to replace the open-coded
ns = ts-tv_sec * 10ULL;
ns += ts-tv_nsec;
here with a call to ns_to_timespec64(), here and in other drivers that you
are already touching.
Yes, I'll
On Sun, Mar 22, 2015 at 03:36:31AM +0100, Arnd Bergmann wrote:
On Saturday 21 March 2015, Richard Cochran wrote:
mutex_lock(clock-extreg_lock);
- err = tdr_write(1, phydev, ts, PTP_LOAD_CLK);
+ err = tdr_write(1, phydev, ts, PTP_LOAD_CLK);
mutex_unlock
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:06PM +0800, Baolin Wang wrote:
diff --git a/include/linux/ptp_clock_kernel.h
b/include/linux/ptp_clock_kernel.h
index 0d8ff3f..86decc2 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -105,7 +105,9 @@ struct
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 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
the
maintainers for a review.
Thanks,
Richard
Richard Cochran (22):
ptp: introduce get/set time methods with explicit 64 bit seconds.
ptp: use the 64 bit gettime method for the SYS_OFFSET ioctl.
ptp: blackfin: convert to the 64 bit get/set time methods.
ptp: xgbe: convert to the 64 bit get/set
This device stores the number of seconds in a 32 bit register. So
more work is needed on this driver before the year 2038 comes around.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8
1 file
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 26 +-
1 file
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 +++---
1 file changed, 7 insertions
The device uses 64 bit nanoseconds register, and so with this patch the
driver is ready for the year 2038.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/adi/bfin_mac.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net
The device features a 64 bit nanoseconds register, and so with this
patch the driver is ready for the year 2038.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/fm10k/fm10k_ptp.c | 12 ++--
1 file changed, 6
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++--
1 file changed, 7 insertions
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8
1 file changed, 4 insertions
This device stores the number of seconds in a 32 bit register. So
more work is needed on this driver before the year 2038 comes around.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 12 +++-
1 file changed, 7 insertions
This patch changes the driver to use the newer API.
Depending on how the hardware represents a time value, this driver may
or may not yet be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/sfc/ptp.c | 22
comes around.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/igb/igb_ptp.c | 41 +++---
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c
b/drivers/net
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/freescale/fec_ptp.c |8
1 file changed, 4 insertions(+), 4
The device has a 64 bit clock register, where each clock tick is 32
nanoseconds, and so with this patch the driver is ready for the year
2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp/ptp_pch.c |8
1 file changed, 4 insertions
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/e1000e/ptp.c | 16
1 file changed, 8 insertions
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 11 ++-
1 file changed, 6 insertions
This patch changes the code to use the new method whenever implemented by
the PHC driver.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp/ptp_chardev.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c b
The device has a 64 bit clock register, where each clock tick is 16
nanoseconds, and so with this patch the driver is ready for the year
2038.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp/ptp_ixp46x.c |8
1 file changed, 4 insertions(+), 4 deletions
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/ti/cpts.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions
This driver calls code (via gxio_mpipe_get/set_timestamp) that makes
the assumption that the tv_sec field is 64 bits wide. So apparently
this driver is 64 bit only. So maybe this driver and device are ready
for 2038, but maybe not.
Not even compile tested.
Signed-off-by: Richard Cochran
.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp/ptp_chardev.c|8 +---
drivers/ptp/ptp_clock.c | 12 ++--
include/linux/ptp_clock_kernel.h |8
3 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/broadcom/tg3.c | 10 +-
1 file changed, 5 insertions
Converting the PHC drivers over to the new methods is one step along the
way to making them ready for 2038. Once all the drivers are up to date,
then the old methods will be removed.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
include/linux/ptp_clock_kernel.h | 12
On Sat, Mar 21, 2015 at 09:59:52PM +0100, Richard Cochran wrote:
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index 296b0ec..2665360 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -107,13 +107,21 @@ static int ptp_clock_getres(struct posix_clock *pc
This driver calls code (via gxio_mpipe_get/set_timestamp) that makes
the assumption that the tv_sec field is 64 bits wide. So apparently
this driver is 64 bit only. So maybe this driver and device are ready
for 2038, but maybe not.
Not even compile tested.
Signed-off-by: Richard Cochran
.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp/ptp_chardev.c|8 +---
drivers/ptp/ptp_clock.c | 15 ---
include/linux/ptp_clock_kernel.h |8
3 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/ptp
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/fm10k/fm10k_ptp.c | 12 ++--
1 file changed, 6
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 26 +-
1 file
The device uses 64 bit nanoseconds register, and so with this patch the
driver is ready for the year 2038.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/adi/bfin_mac.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net
Converting the PHC drivers over to the new methods is one step along the
way to making them ready for 2038. Once all the drivers are up to date,
then the old methods will be removed.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
include/linux/ptp_clock_kernel.h | 12
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/broadcom/tg3.c | 10 +-
1 file changed, 5 insertions
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/freescale/fec_ptp.c |8
1 file changed, 4 insertions(+), 4
The device features a 64 bit nanoseconds register, and so with this
patch the driver is ready for the year 2038.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/e1000e/ptp.c | 16
1 file changed, 8 insertions
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8
1 file changed, 4 insertions
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 +++---
1 file changed, 7 insertions
This device stores the number of seconds in a 32 bit register. So
more work is needed on this driver before the year 2038 comes around.
Compile tested only.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 12 +++-
1 file changed, 7 insertions
201 - 300 of 1647 matches
Mail list logo
