Re: [RFC v3] CAN FD support

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 15.05.2012 15:37, Kurt Van Dijck wrote:

> On Tue, May 15, 2012 at 03:01:28PM +0200, Oliver Hartkopp wrote:

>>>>
>>>> I have a patch for that later in this mail.
>>> waaw. You're running _with_ HDR bit on :-) ?
>>
> I meant you have a "High data rate" yourself. It was meant as some form
> of humor to indicate my supprise of you generating a new patch very quick ...


Ah - ok :-)

Indeed i'm on vacancy this week and my wife pimps her garden so i need to
surveillance the dog in the house  8-)


>> There's no reason to provide a CAN_MTU frame to a CANFD application once the
>> driver is switched to CANFD-mode.
> I think there is a reason. If a CAN2.0B frame was on the wire, generating
> a can_frame rather than a canfd_frame better reflects what was on the wire.
> 
> I still think a can_frame & canfd_frame with same data differ on the wire.


Yes. But you can express this difference with the CANFD_NOEDL bit in
canfd_frame.flags:

CANFD_NOEDL == 1 => standard CAN 2.0B frame
CANFD_NOEDL == 0 => CAN FD frame (whatever DLC 0-F is used)

The distinction of this bit is only relevant to CANFD aware apps anyway.

>> 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.
> You're not tired of me then :-)


No. You are sometimes pretty brutal with your suggestions which makes me wake
up from sleep. ;-)

>> 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 :-)
> My first suggestion was to also cut longer CANFD frames down to 8 bytes
> (thereby loosing data!).
> Remember it's still a compatibility mode. I think that would be acceptable.


At the point where CAN FD frames with a DLC > 8 become relevant for
applications a new CANFD aware application *should* come into service.

Silently cutting payload data is a bad idea.

Regards,
Oliver