On Tuesday 06 October 2015 11:05:32 Marc Kleine-Budde wrote:
> On 10/06/2015 10:32 AM, Arnd Bergmann wrote:
> > On Monday 05 October 2015 20:51:08 Oliver Hartkopp wrote:
> >>
> >> I double checked some (more) BCM applications I have access to.
> >>
> >> E.g. https://github.com/linux-can/can-tests
> >>
> >> When you do a 'git grep ival1' there you get something like
> >>
> >> tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 1;
> >> tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
> >> tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 0;
> >> tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
> >> tst-bcm-dump.c: msg.msg_head.ival1.tv_sec = timeout / 1000000;
> >> tst-bcm-dump.c: msg.msg_head.ival1.tv_usec = timeout % 1000000;
> >> (..)
> >>
> >> So the usual way to assign values to ival1 and ival2 is NOT to assign an
> >> existing struct timeval but to directly assign its tv_[u]sec elements.
> >
> > Ok, very good.
> >
> >> I applied your bcm.h changes to my local can-tests tree and it compiles
> >> without any problems - as expected. I don't see any serious drawback with your
> >> idea. I wonder whether developers would ever notice this change ...
> >>
> >>> We could address problem a) by using '__u32' or 'int' members
> >>> rather than 'long', but that would have a more significant
> >>> downside in also breaking support for all existing 64-bit user
> >>> binaries that might be using this interface, which is likely
> >>> not acceptable.
> >>
> >> Indeed.
> >>
> >>> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
> >>> Cc: Oliver Hartkopp <socketcan(a)hartkopp.net>
> >>
> >> Thanks for your good suggestion to make the BCM API y2038 proof!
> >>
> >> Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
> >
> > Thanks.
> >
> > What is the normal path for CAN patches? Should I resend with your
> > Ack and without the RFC for Marc to pick it up?
>
> You can add my:
>
> Acked-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
>
> add upstream the 2038 fixes as a block.
Davem already picked up the first 10 of the series. If you don't
mind, I'd prefer if you could take this one into your tree so I
have it off my list.
I have 200 other patches in various states and more getting added.
Arnd
Dear Customer,
This is to confirm that one or more of your parcels has been shipped.
Shipment Label is attached to this email.
Sincerely,
Randy Caldwell,
FedEx Operation Manager.
Dear Customer,
Courier was unable to deliver the parcel to you.
Delivery Label is attached to this email.
Thanks and best regards,
Don West,
FedEx Station Agent.
Dear Customer,
We could not deliver your item.
You can review complete details of your order in the find attached.
Kind regards,
Eric Chandler,
Sr. Operation Agent.
Dear Customer,
We could not deliver your item.
Please, open email attachment to print shipment label.
Yours faithfully,
Herbert Higgins,
FedEx Operation Manager.
When trying to build a kernel with time_t commented out, I found that
the ntp subsystem still relies on timespec for its pps handling.
This series addresses this and converts all the code to use timespec64
instead, step by step. There is one device driver that interacts with
this code directly (rather than only through the ptp subsystem), so
I have to convert that driver at the same time.
The patches should ideally stay together as a series, but they do
span multiple subsystems, so I'm also looking for the right person
to merge them.
Please review.
Thanks,
Arnd
Arnd Bergmann (5):
ntp/pps: use timespec64 for hardpps()
ntp/pps: replace getnstime_raw_and_real with 64-bit version
ntp: use timespec64 in sync_cmos_clock
ntp/pps: use y2038 safe types in pps_event_time
net: sfc: avoid using timespec
drivers/net/ethernet/sfc/ptp.c | 30 +++++++++++++++---------------
drivers/pps/kapi.c | 4 ++--
include/linux/pps_kernel.h | 16 ++++++++--------
include/linux/timekeeping.h | 4 ++--
include/linux/timex.h | 2 +-
kernel/time/ntp.c | 16 ++++++++--------
kernel/time/ntp_internal.h | 2 +-
kernel/time/timekeeping.c | 14 +++++++-------
8 files changed, 44 insertions(+), 44 deletions(-)
--
2.1.0.rc2