[RFC] [PATCH v4] can: fix handling of unmodifiable configuration options

[RFC] [PATCH v4] can: fix handling of unmodifiable configuration options

[Oliver Hartkopp]

As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
(6cfda7fbebe) it is possible to define fixed configuration options by
setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
This leads to the incovenience that the fixed configuration bits can not be
passed by netlink even when they have the correct values (e.g. non-ISO, FD).

This patch fixes that issue and not only allows fixed set bit values to be set
again but now requires(!) to provide these fixed values at configuration time.
A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
enforced by a new can_validate() function. This fix additionally removed the
inconsistency that was prohibiting the support of 'CANFD-only' controller
drivers, like the RCar CAN FD.

For this reason a new helper can_set_static_ctrlmode() has been introduced to
provide a proper interface to handle static enabled CAN controller options.

Reported-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
 drivers/net/can/dev.c         | 49 ++++++++++++++++++++++++++++++++++++++++---
 drivers/net/can/m_can/m_can.c |  2 +-
 include/linux/can/dev.h       | 22 +++++++++++++++++--
 3 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 141c2a4..854ace78 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -696,11 +696,17 @@ int can_change_mtu(struct net_device *dev, int new_mtu)
 	/* allow change of MTU according to the CANFD ability of the device */
 	switch (new_mtu) {
 	case CAN_MTU:
+		/* 'CANFD-only' controllers can not switch to CAN_MTU */
+		if (priv->ctrlmode_static & CAN_CTRLMODE_FD)
+			return -EINVAL;
+
 		priv->ctrlmode &= ~CAN_CTRLMODE_FD;
 		break;
 
 	case CANFD_MTU:
-		if (!(priv->ctrlmode_supported & CAN_CTRLMODE_FD))
+		/* check for potential CANFD ability */
+		if (!(priv->ctrlmode_supported & CAN_CTRLMODE_FD) &&
+		    !(priv->ctrlmode_static & CAN_CTRLMODE_FD))
 			return -EINVAL;
 
 		priv->ctrlmode |= CAN_CTRLMODE_FD;
@@ -782,6 +788,36 @@ static const struct nla_policy can_policy[IFLA_CAN_MAX + 1] = {
 				= { .len = sizeof(struct can_bittiming_const) },
 };
 
+static int can_validate(struct nlattr *tb[], struct nlattr *data[])
+{
+	u32 is_can_fd = 0;
+
+	/*
+	 * Make sure that valid CAN FD configurations always consist of
+	 * - nominal/arbitration bittiming
+	 * - data bittiming
+	 * - control mode with CAN_CTRLMODE_FD set
+	 */
+
+	if (data[IFLA_CAN_CTRLMODE]) {
+		struct can_ctrlmode *cm = nla_data(data[IFLA_CAN_CTRLMODE]);
+
+		is_can_fd = cm->flags & cm->mask & CAN_CTRLMODE_FD;
+	}
+
+	if (is_can_fd) {
+		if (!data[IFLA_CAN_BITTIMING] || !data[IFLA_CAN_DATA_BITTIMING])
+			return -EOPNOTSUPP;
+	}
+
+	if (data[IFLA_CAN_DATA_BITTIMING]) {
+		if (!is_can_fd || !data[IFLA_CAN_BITTIMING])
+			return -EOPNOTSUPP;
+	}
+
+	return 0;
+}
+
 static int can_changelink(struct net_device *dev,
 			  struct nlattr *tb[], struct nlattr *data[])
 {
@@ -819,8 +855,14 @@ static int can_changelink(struct net_device *dev,
 			return -EBUSY;
 		cm = nla_data(data[IFLA_CAN_CTRLMODE]);
 
-		/* check whether changed bits are allowed to be modified */
-		if (cm->mask & ~priv->ctrlmode_supported)
+		/* check whether provided bits are allowed to be passed */
+		if (cm->mask &
+		    ~(priv->ctrlmode_supported | priv->ctrlmode_static))
+			return -EOPNOTSUPP;
+
+		/* make sure static options are provided by configuration */
+		if ((cm->flags & cm->mask & priv->ctrlmode_static) !=
+		    priv->ctrlmode_static)
 			return -EOPNOTSUPP;
 
 		/* clear bits to be modified and copy the flag values */
@@ -966,6 +1008,7 @@ static struct rtnl_link_ops can_link_ops __read_mostly = {
 	.maxtype	= IFLA_CAN_MAX,
 	.policy		= can_policy,
 	.setup		= can_setup,
+	.validate	= can_validate,
 	.newlink	= can_newlink,
 	.changelink	= can_changelink,
 	.get_size	= can_get_size,
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 39cf911..195f15e 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -955,7 +955,7 @@ static struct net_device *alloc_m_can_dev(void)
 	priv->can.do_get_berr_counter = m_can_get_berr_counter;
 
 	/* CAN_CTRLMODE_FD_NON_ISO is fixed with M_CAN IP v3.0.1 */
-	priv->can.ctrlmode = CAN_CTRLMODE_FD_NON_ISO;
+	can_set_static_ctrlmode(dev, CAN_CTRLMODE_FD_NON_ISO);
 
 	/* CAN_CTRLMODE_FD_NON_ISO can not be changed with M_CAN IP v3.0.1 */
 	priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 735f9f8..098243b 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -40,8 +40,11 @@ struct can_priv {
 	struct can_clock clock;
 
 	enum can_state state;
-	u32 ctrlmode;
-	u32 ctrlmode_supported;
+
+	/* CAN controller features - see include/uapi/linux/can/netlink.h */
+	u32 ctrlmode;		/* current options setting */
+	u32 ctrlmode_supported;	/* options that can be modified by netlink */
+	u32 ctrlmode_static;	/* static enabled options for driver/hardware */
 
 	int restart_ms;
 	struct timer_list restart_timer;
@@ -108,6 +111,21 @@ static inline bool can_is_canfd_skb(const struct sk_buff *skb)
 	return skb->len == CANFD_MTU;
 }
 
+/* helper to define static CAN controller features at device creation time */
+static inline void can_set_static_ctrlmode(struct net_device *dev,
+					   const u32 static_mode)
+{
+	struct can_priv *priv = netdev_priv(dev);
+
+	/* alloc_candev() succeeded => netdev_priv() is valid at this point */
+	priv->ctrlmode = static_mode;
+	priv->ctrlmode_static = static_mode;
+
+	/* override MTU which was set by default in can_setup()? */
+	if (static_mode & CAN_CTRLMODE_FD)
+		dev->mtu = CANFD_MTU;
+}
+
 /* get data length from can_dlc with sanitized can_dlc */
 u8 can_dlc2len(u8 can_dlc);
 
-- 
2.7.0

RE: [RFC] [PATCH v4] can: fix handling of unmodifiable configuration options

[Ramesh Shanmugasundaram]

Hi Oliver,

Thanks for the patch.

> -----Original Message-----
> From: Oliver Hartkopp [mailto:socketcan@hartkopp.net]
> Sent: 19 March 2016 08:08
> To: linux-can@vger.kernel.org
> Cc: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>;
> Oliver Hartkopp <socketcan@hartkopp.net>
> Subject: [RFC] [PATCH v4] can: fix handling of unmodifiable configuration
> options
> 
> As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
> (6cfda7fbebe) it is possible to define fixed configuration options by
> setting the according bit in 'ctrlmode' and clear it in
> 'ctrlmode_supported'.
> This leads to the incovenience that the fixed configuration bits can not
> be passed by netlink even when they have the correct values (e.g. non-ISO,
> FD).
> 
> This patch fixes that issue and not only allows fixed set bit values to be
> set again but now requires(!) to provide these fixed values at
> configuration time.
> A valid CAN FD configuration consists of a nominal/arbitration bittiming,
> a data bittiming and a control mode with CAN_CTRLMODE_FD set - which is
> now enforced by a new can_validate() function. This fix additionally
> removed the inconsistency that was prohibiting the support of 'CANFD-only'
> controller drivers, like the RCar CAN FD.
> 
> For this reason a new helper can_set_static_ctrlmode() has been introduced
> to provide a proper interface to handle static enabled CAN controller
> options.
> 
> Reported-by: Ramesh Shanmugasundaram
> <ramesh.shanmugasundaram@bp.renesas.com>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> ---
>  drivers/net/can/dev.c         | 49
> ++++++++++++++++++++++++++++++++++++++++---
>  drivers/net/can/m_can/m_can.c |  2 +-
>  include/linux/can/dev.h       | 22 +++++++++++++++++--
>  3 files changed, 67 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c index
> 141c2a4..854ace78 100644
> --- a/drivers/net/can/dev.c
> +++ b/drivers/net/can/dev.c
> @@ -696,11 +696,17 @@ int can_change_mtu(struct net_device *dev, int
> new_mtu)
>  	/* allow change of MTU according to the CANFD ability of the device
> */
>  	switch (new_mtu) {
>  	case CAN_MTU:
> +		/* 'CANFD-only' controllers can not switch to CAN_MTU */
> +		if (priv->ctrlmode_static & CAN_CTRLMODE_FD)
> +			return -EINVAL;
> +
>  		priv->ctrlmode &= ~CAN_CTRLMODE_FD;
>  		break;
> 
>  	case CANFD_MTU:
> -		if (!(priv->ctrlmode_supported & CAN_CTRLMODE_FD))
> +		/* check for potential CANFD ability */
> +		if (!(priv->ctrlmode_supported & CAN_CTRLMODE_FD) &&
> +		    !(priv->ctrlmode_static & CAN_CTRLMODE_FD))
>  			return -EINVAL;
> 
>  		priv->ctrlmode |= CAN_CTRLMODE_FD;
> @@ -782,6 +788,36 @@ static const struct nla_policy
> can_policy[IFLA_CAN_MAX + 1] = {
>  				= { .len = sizeof(struct can_bittiming_const) },
> };
> 
> +static int can_validate(struct nlattr *tb[], struct nlattr *data[]) {
> +	u32 is_can_fd = 0;
> +
> +	/*
> +	 * Make sure that valid CAN FD configurations always consist of
> +	 * - nominal/arbitration bittiming
> +	 * - data bittiming
> +	 * - control mode with CAN_CTRLMODE_FD set
> +	 */

This comment style prompts WARNING in latest checkpatch.pl in case you plan to submit in linux-can-next. Otherwise

Reviewed-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>

Thanks,
Ramesh

Re: [RFC] [PATCH v4] can: fix handling of unmodifiable configuration options

[Oliver Hartkopp]

Hi Ramesh,

thanks for your feedback - also in the other thread with the wrong 
subject :-)

Indeed I feel pretty good about this solution:

1. it maintains the current behaviour for CAN2.0 controllers
2. it forces valid combinations for CAN FD
3. it forces the user to think about static ctrlmodes

The only thing I was not sure about when forcing static ctrlmodes to be 
set was the fact that you would need to set fd-non-iso for the MCAN 
controller setup - even when you only configure it for CAN2.0 traffic:

ip link set can0 type can bitrate 100000 -> ok

ip link set can0 type can bitrate 100000 one-shot on -> fail

ip link set can0 type can bitrate 100000 one-shot on fd-non-iso on -> ok

To be consistent with 'static ctrlmodes have to be provided' it looks 
ok. But from a CAN2.0 perspective it looks confusing.

I wonder if it makes sense to handle this *special* case not to force 
fd-non-iso when the controller won't get into FD mode. What do you think?

On 03/21/2016 09:37 AM, Ramesh Shanmugasundaram wrote:

>> +static int can_validate(struct nlattr *tb[], struct nlattr *data[]) {
>> +	u32 is_can_fd = 0;
>> +
>> +	/*
>> +	 * Make sure that valid CAN FD configurations always consist of
>> +	 * - nominal/arbitration bittiming
>> +	 * - data bittiming
>> +	 * - control mode with CAN_CTRLMODE_FD set
>> +	 */
>
> This comment style prompts WARNING in latest checkpatch.pl in case you plan to submit in linux-can-next. Otherwise

Ok - I'll fix that in the next version.

> Reviewed-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>

I can also add this then.

Btw. I'll wait for feedback about fd-non-iso first.

Best regards,
Oliver

RE: [RFC] [PATCH v4] can: fix handling of unmodifiable configuration options

[Ramesh Shanmugasundaram]

Hi Oliver,

> thanks for your feedback - also in the other thread with the wrong subject
> :-)
Thanks :-)

> 
> Indeed I feel pretty good about this solution:
> 
> 1. it maintains the current behaviour for CAN2.0 controllers 2. it forces
> valid combinations for CAN FD 3. it forces the user to think about static
> ctrlmodes
> 
> The only thing I was not sure about when forcing static ctrlmodes to be
> set was the fact that you would need to set fd-non-iso for the MCAN
> controller setup - even when you only configure it for CAN2.0 traffic:
> 
> ip link set can0 type can bitrate 100000 -> ok
> 
> ip link set can0 type can bitrate 100000 one-shot on -> fail

Oh! I checked for M_CAN but only the config above this. Good that you spotted.

> 
> ip link set can0 type can bitrate 100000 one-shot on fd-non-iso on -> ok
> 
> To be consistent with 'static ctrlmodes have to be provided' it looks ok.
> But from a CAN2.0 perspective it looks confusing.

Definitely.

> 
> I wonder if it makes sense to handle this *special* case not to force fd-
> non-iso when the controller won't get into FD mode. What do you think?

Yes, I agree. Non-ISO only mode will eventually phase out and having a "special" case for this sounds logical.
 
Thanks,
Ramesh

Re: [RFC] [PATCH v4] can: fix handling of unmodifiable configuration options

[Oliver Hartkopp]

On 03/21/2016 04:19 PM, Ramesh Shanmugasundaram wrote:

>> The only thing I was not sure about when forcing static ctrlmodes to be
>> set was the fact that you would need to set fd-non-iso for the MCAN
>> controller setup - even when you only configure it for CAN2.0 traffic:
>>
>> ip link set can0 type can bitrate 100000 -> ok
>>
>> ip link set can0 type can bitrate 100000 one-shot on -> fail
>
> Oh! I checked for M_CAN but only the config above this. Good that you spotted.
>
>>
>> ip link set can0 type can bitrate 100000 one-shot on fd-non-iso on -> ok
>>
>> To be consistent with 'static ctrlmodes have to be provided' it looks ok.
>> But from a CAN2.0 perspective it looks confusing.
>
> Definitely.
>
>>
>> I wonder if it makes sense to handle this *special* case not to force fd-
>> non-iso when the controller won't get into FD mode. What do you think?
>
> Yes, I agree. Non-ISO only mode will eventually phase out and having a "special" case for this sounds logical.
>

Ok. I'll put this special handling into can_changelink() and will post 
an update (v5).

Thanks,
Oliver