The ohci driver uses the get_seconds() function to implement the 32-bit CSR_BUS_TIME register. This was added in 2010 commit a48777e03ad5 ("firewire: add CSR BUS_TIME support").
As get_seconds() returns a 32-bit value (on 32-bit architectures), it seems like a good fit for that register, but it is also deprecated because of the y2038/y2106 overflow problem, and should be replaced throughout the kernel with either ktime_get_real_seconds() or ktime_get_seconds().
I'm using the latter here, which uses monotonic time. This has the advantage of behaving better during concurrent settimeofday() updates or leap second adjustments and won't overflow a 32-bit integer, but the downside of using CLOCK_MONOTONIC instead of CLOCK_REALTIME is that the observed values are not related to external clocks.
If we instead need UTC but can live with clock jumps or overflows, then we should use ktime_get_real_seconds() instead, retaining the existing behavior.
Reviewed-by: Clemens Ladisch clemens@ladisch.de Signed-off-by: Arnd Bergmann arnd@arndb.de --- I notice that Stefan Richter has not been active on the mailing lists since February 2018.
Andrew, could you pick it up in the meantime? --- drivers/firewire/ohci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 45c048751f3b..5125841ea338 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -1765,7 +1765,7 @@ static u32 update_bus_time(struct fw_ohci *ohci)
if (unlikely(!ohci->bus_time_running)) { reg_write(ohci, OHCI1394_IntMaskSet, OHCI1394_cycle64Seconds); - ohci->bus_time = (lower_32_bits(get_seconds()) & ~0x7f) | + ohci->bus_time = (lower_32_bits(ktime_get_seconds()) & ~0x7f) | (cycle_time_seconds & 0x40); ohci->bus_time_running = true; }
On Jul 11 Arnd Bergmann wrote:
The ohci driver uses the get_seconds() function to implement the 32-bit CSR_BUS_TIME register. This was added in 2010 commit a48777e03ad5 ("firewire: add CSR BUS_TIME support").
As get_seconds() returns a 32-bit value (on 32-bit architectures), it seems like a good fit for that register, but it is also deprecated because of the y2038/y2106 overflow problem, and should be replaced throughout the kernel with either ktime_get_real_seconds() or ktime_get_seconds().
I'm using the latter here, which uses monotonic time. This has the advantage of behaving better during concurrent settimeofday() updates or leap second adjustments and won't overflow a 32-bit integer, but the downside of using CLOCK_MONOTONIC instead of CLOCK_REALTIME is that the observed values are not related to external clocks.
If we instead need UTC but can live with clock jumps or overflows, then we should use ktime_get_real_seconds() instead, retaining the existing behavior.
Reviewed-by: Clemens Ladisch clemens@ladisch.de Signed-off-by: Arnd Bergmann arnd@arndb.de
I notice that Stefan Richter has not been active on the mailing lists since February 2018.
Thanks Arnd and Clemens.
I resurrected and updated one of my FireWire enabled PCs, and try to get pack to reasonable response times to firewire driver patches.
The switch from CLOCK_REALTIME to CLOCK_MONOTONIC looks good to me, but I'll have another look at the context.
Andrew, could you pick it up in the meantime?
drivers/firewire/ohci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 45c048751f3b..5125841ea338 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -1765,7 +1765,7 @@ static u32 update_bus_time(struct fw_ohci *ohci) if (unlikely(!ohci->bus_time_running)) { reg_write(ohci, OHCI1394_IntMaskSet, OHCI1394_cycle64Seconds);
ohci->bus_time = (lower_32_bits(get_seconds()) & ~0x7f) |
ohci->bus_time_running = true; }ohci->bus_time = (lower_32_bits(ktime_get_seconds()) & ~0x7f) | (cycle_time_seconds & 0x40);