Upstream commit ba61a8d9d780980e8284355a0be750897e7af212
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=ba61a8d9d780980e8284355a0be750897e7af212
The can subsystem communicates with user space using a bcm_msg_head
header, which contains two timestamps. This is problematic for
multiple reasons:
a) The structure layout is currently incompatible between 64-bit
user space and 32-bit user space, and cannot work in compat
mode (other than x32).
b) The timeval structure layout will change in 32-bit user
space when we fix the y2038 overflow problem by redefining
time_t to 64-bit, making new 32-bit user space incompatible
with the current kernel interface.
Cars last a long time and often use old kernels, so the actual
users of this code are the most likely ones to migrate to y2038
safe user space.
This tries to work around part of the problem by changing the
publicly visible user interface in the header, but not the binary
interface. Fortunately, the values passed around in the structure
are relative times and do not actually suffer from the y2038
overflow, so 32-bit is enough here.
We replace the use of 'struct timeval' with a newly defined
'struct bcm_timeval' that uses the exact same binary layout
as before and that still suffers from problem a) but not problem
b).
The downside of this approach is that any user space program
that currently assigns a timeval structure to these members
rather than writing the tv_sec/tv_usec portions individually
will suffer a compile-time error when built with an updated
kernel header. Fixing this error makes it work fine with old
and new headers though.
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.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org
Cc: linux-api@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Similar to referencing iptables rules by their line number this UID allows to
reference created routing jobs, e.g. to alter configured data modifications.
The UID is an optional non-zero value which can be provided at routing job
creation time. When the UID is set the UID replaces the data modification
configuration as job identification attribute e.g. at job removal time.
The UID option is provided by mainline Linux 4.2+
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CAN_RAW socket can set multiple CAN identifier specific filters that lead
to multiple filters in the af_can.c filter processing. These filters are
indenpendent from each other which leads to logical OR'ed filters when applied.
This socket option joines the given CAN filters in the way that only CAN frames
are passed to user space that matched *all* given CAN filters. The semantic for
the applied filters is therefore changed to a logical AND.
This is useful especially when the filterset is a combination of filters where
the CAN_INV_FILTER flag is set in order to notch single CAN IDs or CAN ID
ranges from the incoming traffic.
Example:
candump can0,100~7FF,200~7FF,400~7FF (logical OR'ed filters)
candump can0,100~7FF,200~7FF,400~7FF,J (logical AND'ed filters)
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
As requested by Laurent Vaudoit the extended address can be different in the
tx and he rx path:
(..) how can i have a segmented transfer like this:
0x6a7 0x55 0x10 0x08 ........
0x687 0xAA 0x30 0x00 0x00
0x6a7 0x55 0x21 .....
The connection i need is between two ECU, using IDs 0x6a7/687 and one has
adress extension 0x55, the other 0xAA (this adressing method is used on some
FIAT ECUs for example).
http://marc.info/?l=linux-can&m=140354647413513&w=2
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This comment was added to the kernel in patch:
391ac12 can: gw: add a per rule limitation of frame hops
The corresponding can-utils commit is:
ad7f44095a (cangw: add an option for the per rule limitation of frame hops)
which somehow introduced the difference even though it referenced commit
391ac12.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch adds the typedef for __kernel_sa_family_t that was introduced in
Linux v3.1-rc2 (commit 6602a4b net: Make userland include of netlink.h more sane)
in <linux/socket.h>. It must be duplicated here to make the CAN headers
self-contained.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch remove the include of version.h, as it's not used and also not
present in the kernel headers.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch fixes paths mentioned in the files which are wrong now, due the move
of the files in the previous patch.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This makes it possible to import header from the kernel more easily, e.g.:
cd $path_to_linux_repo
make headers_install
rsync -a --exclude .\* usr/include/linux/can* $path_to_can_utils/include/linux
[mkl: also move isotp.h although Uwe skipped it as it is not
part of the upstream kernel; adapt commit log accordingly]
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
These seem to have never been used. They entered can-utils in commit
77de10356f (include: import kernel header files into tree) and already
back then only consisted in an #include of a non-existing file.
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Oleksij Rempel
Oliver Hartkopp
Marc Kleine-Budde
Kurt Van Dijck
Uwe Kleine-König