On 03/08/2016 01:48 PM, Ramesh Shanmugasundaram wrote:

quoted

In fact you provided a CAN driver which is "CAN-FD-only".

Yes. That's the status of current submission.

quoted

We did not had that before but there's a solution for this kind of setup.

There is a similar case with CAN_CTRLMODE_FD_NON_ISO we had on the M_CAN
driver which only provides non-ISO configuration for the supported IP core
and _no_ option to _change_ this value:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id
=6cfda7fbebe8a4fd33ea5722fa0212f98f643c35

If you would do it similar in rcar_canfd.c with

/* CAN_CTRLMODE_FD is fixed with R-Car CAN FD */
priv->can.ctrlmode = CAN_CTRLMODE_FD;

and remove CAN_CTRLMODE_FD from the priv->can.ctrlmode_supported
assignment then it should do the entire configuration process correctly
for you.
Including the proper tests for the two bitrates.
(see open_candev() in linux/drivers/net/can/dev.c)

Right?

I did try this option earlier but there are two problems with this method.

1) Below configuration is not possible

ip link set can0 up type can bitrate 1000000 dbitrate 1000000 fd on

"fd on" -> This is not allowed because CAN_CTRLMODE_FD bit is not set in ctrlmode_supported.

2) If I ignore "fd on", my interface MTU stays as CAN_MTU only. If I have to change the MTU alone to CANFD_MTU using another netlink message, it again checks ctrlmode_supported where it would fail. I have the option of providing my own change_mtu function & ignore this check but two configuration messages are required for my driver alone :-(.

Both these anomalies are addressed with the current check I have. 

Oh - you are right with complaining about this inconsistency.

Can you check my RFC patch for Linux stable I just sent on the mailing list?
http://marc.info/?l=linux-can&m=145745724917976&w=2

Many thanks,
Oliver