Re: [RFC] can: Introducing CANFD for af_can & can-raw

[Wolfgang Grandegger <wg@grandegger.com>]

Hi,

On 03/21/2012 02:53 PM, Kurt Van Dijck wrote:
> On Wed, Mar 21, 2012 at 02:21:22PM +0100, Oliver Hartkopp wrote:
>> Hi all,
>>
>> of course i also thought about some concepts to support CAN FD ;-)
> :-)
>>
>> But then it melted down to the question what a potential CAN FD controller
>> would support:
>>
>> 1. Will it support sending of CAN frames & CAN FD frames with one config?
> At least, you'd select if it operates in CAN or CANFD mode, since the bus
> cannot switch dynamically.
> 
>> 2. Is a CAN FD frame with DLC=8 different to a CAN2.0 frame with DLC=8 ?
>>    (as we know CAN ID 0x123 (EFF) and CAN ID 0x123 (SFF) are different)
> a CANFD frame with DLC=8 is different to a CAN2.0 frame with DLC=8 on the wire,
> but they are logically equal. Since we're into software, IMO we must treat them
> equal.

As I see it, the main difference to standard CAN is the bit-rate
switching for transferring just the data bytes using alternate
bit-timing parameters.

> I think of some differences:
> * no RTR allowed.
> * ESI bit.

Also DLC=9 means 12 bytes, DLC=10 means 16 bytes, DLC=15 means 64 bytes.
This may even change in the final spec.

>> 3. Will these differences be visible in the CAN registers? Is this relevant?
> Without hardware, it's a bit early to predict. I guess it will be visible, but
> not relevant since that's driver stuff.

As CANFD controllers also supports CAN2.0 frames, they must provide the
the relevant information somehow, similar to EFF and SFF.

> I did not get into real drivers yet...
>>
>> What i got from the iCC was that when you have a partly migrated network and
>> you want to run e.g. a fast firmware upload between two CAN FD capable nodes,
>> the other (standard CAN 2.0b) nodes have to be in listen only mode to not jam
>> the bus with error frames.

Due to the bit-rate switching, a assume.

>> After the firmware upload all the CAN nodes switch back to CAN2.0b mode (which
>> has to be done by root netlink access).
> Since CANFD is not bus compatible, the chip must go down & up. It really depends
> on the chips & drivers to combine CAN2.0 & CANFD.
> As Marc already suggested, CANFD could be a ctrlmode.

I also see this problem.

>> IMO we need to introduce a new struct canfd_frame
> IMO we need not to introduce a new struct since they are logically equivalent.
> 
> I created an old can20b_frame just to compute the sizeof.
> I'd go for a combined can_frame that could hold both.

Well, I see it as an extension of the standard CAN and therefore I was
also thinking about an extra "struct canfd_frame". The size is more than
3 times larger and we may only allocate the extra space if it's really
required. I'm also thinking about the impact on queues, etc.

>> It should be no problem to move to canfd_frame inside the kernel but if we
>> come to the point that we get to the userspace ABI there should be no tricky
>> way to check lengths or flags or return values are are not needed to be
>> checked with the current ABI now.
>>
>> When there's a defined socket API that makes use of struct can_frame (like
>> can_raw, can_bcm, can_gw - but not isotp! \o/ ) we need to
>>
>> - duplicate the socket API - like CAN_RAWFD (ugly)
>> - switch the frame size (e.g. via sockopt)
>> - a third unknown idea ...
> When you look at my patch, you can see that only a recompile of candump with
> the bigger can_frame is all what is between me and a virtual CANFD bus.
> Candump does not really need to care about the CANFD mode.
> I think it can do both types of busses as in
> 
> $ candump any

Well, candump is a simple application and it does not really care about
the payload. This is different for real legacy application, I think,
which assumes a payload of 8 bytes only.

>> E.g. when having a CAN FD aware candump/cansend application, it can try to
>> switch the socket to CAN FD. 
> Since CANFD is a different bus, selecting a bus (like 'can0') implicetely selects
> the CANFD mode. IMHO, from that point on, there's no difference for candump with
> a legacy CAN2.0 bus. So why make things complicated.

See above. Also, I think CANFD has been invented to support a fast
transfer mode for special purposes which will be selected from time to
time making the bus incompatible with legacy CAN controllers.

>> on an older kernel that does not support CAN FD ...
>>
>> I think it's much more tricky to find a proper solution here.
> As I mentioned before, I just use CAN_RAW with this. Actually, I just
> ran a real CAN program that I wrote years ago. It still operates!

Would you program still run if the payload is bigger than 8 bytes?
I agree with Oliver.

Wolfgang.