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

[Wolfgang Grandegger <wg@grandegger.com>]

On 03/22/2012 10:24 AM, Kurt Van Dijck wrote:
> On Wed, Mar 21, 2012 at 04:05:28PM +0100, Oliver Hartkopp wrote:
>> On 21.03.2012 15:56, Wolfgang Grandegger wrote:
>>
>>> 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!
> 
> Although the precise coding is not final yet, I'd propose to not use that coding
> in the ABI for these reasons:
> * The reason of fitting a DLC in 4 bits makes sense on the wire
>   but not on the ABI. We still use an u8!
> * Decoding & encoding between real length & DLC IMO is best done next to the
>   chips register access.

I was speaking of the frame's DLC field. The app/abi should support any
integer length, of course.

>>>>> 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 doubt this.
> EFF & SFF share the same bus. CANFD vs. CAN2.0 is not a per-frame thing. You
> have configured it yourself at chip initialization time...

Why not? A CANFD capable controller should be able to distinguish
between a legacy and a CANFD frame by looking to the BRS bit in the frame.

Wolfgang.