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

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 21.03.2012 15:56, Wolfgang Grandegger wrote:

> Hi,
> 

> 
> 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.


Yes. You have two sets of bittiming registers one for the normal operation and
for arbitration and the second for the data &crc section in the case of
enabled FD mode.

And in the FD mode you have up to 64 byte payload.

>> 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.


Yep!

> 
>>> 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.


Yes - the 'old' controllers would put error frames on the fast payload data.


> 
>>> 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.


Yes. Additionally we need to have a proper distinction between can_frame and
canfd_frame when we play with recvmmsg in the future.


> 
>>> 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.


My words :-)

> 
>>> 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.
> 


When you have an entire CAN bus where all nodes support CAN FD this is nice
also. But the current implementation will remain the standard for years too.

>>> 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.


puh. Time for a coffee :-)

Regards,
Oliver