Re: [PATCH RFC] can fd: Add separate bittiming infrastructure

[Stephane Grosjean <s.grosjean@peak-system.com>]

Hi,

Some questions:

Le 15/01/2014 18:54, Oliver Hartkopp a écrit :
> diff --git a/include/uapi/linux/can/netlink.h b/include/uapi/linux/can/netlink.h
> index df944ed..bd0493a2 100644
> --- a/include/uapi/linux/can/netlink.h
> +++ b/include/uapi/linux/can/netlink.h
> @@ -96,6 +96,7 @@ struct can_ctrlmode {
>   #define CAN_CTRLMODE_3_SAMPLES		0x04	/* Triple sampling mode */
>   #define CAN_CTRLMODE_ONE_SHOT		0x08	/* One-Shot mode */
>   #define CAN_CTRLMODE_BERR_REPORTING	0x10	/* Bus-error reporting */
> +#define CAN_CTRLMODE_FD			0x20	/* CAN FD mode */

- What is exactly the goal of this new CAN_CTRLMODE_FD please? Did you 
define it to allow user to enable the CANFD function into the hardware, 
for example? If yes, isn't it redundant with setting the MTU to 72 bytes?

- Moreover, how a CANFD -able driver has to handle a CANFD frame read 
from the CANFD controller, when its network device MTU *ISNOT* == 72 ??? 
Should it discard the CANFD frame?

>   
>   /*
>    * CAN device statistics
> @@ -122,6 +123,9 @@ enum {
>   	IFLA_CAN_RESTART_MS,
>   	IFLA_CAN_RESTART,
>   	IFLA_CAN_BERR_COUNTER,
> +	IFLA_CAN_DATA_BITTIMING,
> +	IFLA_CAN_DATA_BITTIMING_CONST,
> +	IFLA_CAN_DATA_CLOCK,
>   	__IFLA_CAN_MAX
>   };

- by defining another clock for the data bitrate, do you suppose that 
some hardwares could use different clocks for both arbitration and data 
bitrates?

Regards,

Stéphane

--
PEAK-System Technik GmbH, Otto-Roehm-Strasse 69, D-64293 Darmstadt 
Geschaeftsleitung: A.Gach/U.Wilhelm,St.Nr.:007/241/13586 FA Darmstadt 
HRB-9183 Darmstadt, Ust.IdNr.:DE 202220078, WEE-Reg.-Nr.: DE39305391 
Tel.+49 (0)6151-817320 / Fax:+49 (0)6151-817329, info@peak-system.com