On 15.05.2012 12:03, Kurt Van Dijck wrote:

On Tue, May 15, 2012 at 11:19:33AM +0200, Oliver Hartkopp wrote:

quoted

quoted

quoted

2. in any case legacy applications must not get CAN frames with a DLC > 8

Or cut the DLC to 8, and drop the remainder of the message? This changes
the actual can(fd)_frame. That is acceptable since you're running legacy apps
on CANFD bus.

An alternative could be to drop CANFD frames in can_recv() itself.
This may sound inefficient, but remind you're running legacy apps on CANFD busses
_WITH_ CANFD frames on it.

I have a patch for that later in this mail.

waaw. You're running _with_ HDR bit on :-) ?

The effect is when you use legacy can_frames the canfd_frame.flags is not set
explicitly. Therefore you need a (per device?) setting how to deal with the
short CAN_MTU frames. Assuming HDR bit settings in CAN_MTU sized frames is wrong.

(..)

quoted

Yes. Especially we need to specify how the CAN controller should send
can_frames passed to its CAN driver. Should it been send with or without
EDL bit, and should it been send with high data rate or not.

This is what i wanted to suggest with the global CANFD driver settings.

netlink-wise, I would have considered this a device setting.

Yep! It's a job for drivers/net/can/dev.c :-)

quoted

Here's my patch:

quoted

Changes to the previous version:

CANFD aware apps set CAN_RAW_FD_FRAMES to enable longer MTUs (not new).

1. CANFD aware apps may get CAN_MTU and CANFD_MTU frames on rx
2. CANFD aware apps may send CAN_MTU and CANFD_MTU frames on tx
3. legacy apps can receive CAN_MTU and CANFD_MTU frames if the DLC <= 8
   (the possible CANFD_MTU is cut down to CAN_MTU to preserve the ABI)

Effects to the CAN netdev driver:

Legacy operation (CAN_MTU)
- send and receive struct can_frames

CANFD operation (CANFD_MTU and CAN_MTU)
- you can send CANFD_MTU and CAN_MTU frames
  (a default setting (EDL, HDR) for CAN_MTU frames needs to be specified)
- the driver generates always canfd_frames on reception

Interesting.
How does a driver makes the difference between received
CAN2.0B frames & CANFD frames?

As you always generate canfd_frames in this operating mode you can express
this information within canfd_frame.flags.

I think it makes sense, equally to the send() path, to allow the driver
to generate can_frame _or_ canfd_frame on reception, depending on the
bitstream (if possible).

As written above this can be done with a singe canfd_frame.

A legacy app would get the can_frame as-is when DLC <= 8
A CANFD frame can evaluate the bits if they are at least interesting for the
app. For a detailed 'candump' output this could be interesting ;-)

A CANFD application will then be able to distinguish between them based
on the return value of recv_msg (CAN_MTU or CANFD_MTU, even with payload <= 8).

There's no reason to provide a CAN_MTU frame to a CANFD application once the
driver is switched to CANFD-mode.

The CANFD app only gets the old-style CAN_MTU frames when the CAN interface is
not in CANFD mode.

Did I mention I very much like this additional patch?
Well done.

Thanks to you! I was not really happy with the hard exclusive-or switch and
your remarks made me thinking about the simultaneous access with new and
legacy apps again. I think cutting the canfd_frames down to can_frames when
the content is generally usable for the legacy app makes the migration pretty
handy :-)

Will send a v4 patch for the ongoing discussion.

Regards,
Oliver