All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Arnd Bergmann <arnd@arndb.de>, Oliver Hartkopp <socketcan@hartkopp.net>
Cc: netdev@vger.kernel.org, y2038@lists.linaro.org,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	linux-can@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH 12/12] [RFC] can: avoid using timeval for uapi
Date: Tue, 6 Oct 2015 11:05:32 +0200	[thread overview]
Message-ID: <56138EDC.8080501@pengutronix.de> (raw)
In-Reply-To: <7548522.iLToS4O3HD@wuerfel>

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

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@arndb.de>
>>> Cc: Oliver Hartkopp <socketcan@hartkopp.net>
>>
>> Thanks for your good suggestion to make the BCM API y2038 proof!
>>
>> Acked-by: Oliver Hartkopp <socketcan@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@pengutronix.de>

add upstream the 2038 fixes as a block.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2015-10-06  9:05 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-30 11:26 [Intel-wired-lan] [PATCH 00/12] net: assorted y2038 changes Arnd Bergmann
2015-09-30 11:26 ` Arnd Bergmann
2015-09-30 11:26 ` Arnd Bergmann
2015-09-30 11:26 ` Arnd Bergmann
2015-09-30 11:26 ` [PATCH 01/12] net: fec: avoid timespec use Arnd Bergmann
2015-10-01 19:08   ` Richard Cochran
2015-09-30 11:26 ` [PATCH 02/12] net: stmmac: avoid using timespec Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-10-01 19:08   ` Richard Cochran
2015-09-30 11:26 ` [Intel-wired-lan] [PATCH 03/12] net: igb: " Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-10-01 19:17   ` [Intel-wired-lan] " Richard Cochran
2015-10-01 19:17     ` Richard Cochran
2015-10-01 19:17     ` Richard Cochran
2015-10-01 20:01     ` [Intel-wired-lan] " Arnd Bergmann
2015-10-01 20:01       ` Arnd Bergmann
2015-10-01 20:01       ` Arnd Bergmann
2015-10-02  7:47       ` [Intel-wired-lan] " Richard Cochran
2015-10-02  7:47         ` Richard Cochran
2015-10-02  7:47         ` Richard Cochran
2015-09-30 11:26 ` [PATCH 04/12] mwifiex: use ktime_get_real for timestamping Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-10-09 11:36   ` Amitkumar Karwar
2015-09-30 11:26 ` [PATCH 05/12] mwifiex: avoid gettimeofday in ba_threshold setting Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-10-09 11:35   ` Amitkumar Karwar
2015-10-09 11:35     ` Amitkumar Karwar
2015-09-30 11:26 ` [PATCH 06/12] mac80211: use ktime_get_seconds Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-09-30 11:26 ` [PATCH 07/12] atm: hide 'struct zatm_t_hist' Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-09-30 15:24   ` Charles (Chas) Williams
2015-09-30 15:31     ` Arnd Bergmann
2015-09-30 15:31       ` Arnd Bergmann
2015-09-30 15:32     ` [PATCH v2] atm: remove " Arnd Bergmann
2015-09-30 11:26 ` [PATCH 08/12] nfnetlink: use y2038 safe timestamp Arnd Bergmann
2015-10-02 12:53   ` Pablo Neira Ayuso
2015-10-02 21:23     ` Arnd Bergmann
2015-10-02 21:23       ` Arnd Bergmann
2015-09-30 11:26 ` [PATCH 09/12] ipv6: use ktime_t for internal timestamps Arnd Bergmann
2015-09-30 11:26 ` [PATCH 10/12] net: sctp: avoid incorrect time_t use Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
2015-09-30 13:57   ` Neil Horman
2015-09-30 13:57     ` Neil Horman
2015-09-30 14:15     ` Marcelo Ricardo Leitner
2015-09-30 14:15       ` Marcelo Ricardo Leitner
2015-09-30 14:19       ` Neil Horman
2015-09-30 14:19         ` Neil Horman
2015-09-30 14:28   ` Marcelo Ricardo Leitner
2015-09-30 14:28     ` Marcelo Ricardo Leitner
2015-09-30 11:26 ` [PATCH 11/12] [RFC] ipv4: avoid timespec in timestamp computation Arnd Bergmann
2015-09-30 11:55   ` kbuild test robot
2015-09-30 12:39     ` [Y2038] " Arnd Bergmann
2015-09-30 12:58       ` [RFC v2] " Arnd Bergmann
2015-09-30 12:15   ` [RFC PATCH] ipv4: ktime_get_ms_of_day() can be static kbuild test robot
2015-09-30 12:15   ` [PATCH 11/12] [RFC] ipv4: avoid timespec in timestamp computation kbuild test robot
2015-09-30 12:15     ` kbuild test robot
2015-09-30 11:26 ` [PATCH 12/12] [RFC] can: avoid using timeval for uapi Arnd Bergmann
2015-09-30 11:26   ` Arnd Bergmann
     [not found]   ` <1443612402-3000775-13-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
2015-10-05 18:51     ` Oliver Hartkopp
2015-10-05 18:51       ` Oliver Hartkopp
2015-10-06  8:32       ` Arnd Bergmann
2015-10-06  8:32         ` Arnd Bergmann
2015-10-06  9:05         ` Marc Kleine-Budde [this message]
2015-10-06  9:18           ` Arnd Bergmann
2015-10-06  9:37             ` Marc Kleine-Budde
2015-10-06  9:37               ` Marc Kleine-Budde
2015-10-05 10:17 ` [Intel-wired-lan] [PATCH 00/12] net: assorted y2038 changes David Miller
2015-10-05 10:17   ` David Miller
2015-10-05 10:17   ` David Miller
2015-10-05 10:17   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56138EDC.8080501@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.