From: Vincent Mailhol <hidden> Date: 2021-10-09 13:13:36
The main purpose of this series is to report the CAN controller
capabilities. The proposed method reuses the existing struct
can_ctrlmode and thus do not need a new IFLA_CAN_* entry.
While doing so, I also realized that can_priv::ctrlmode_static could
actually be derived from the other ctrlmode fields. So I added two
extra patches to the series: one to replace that field with a function
and one to repack struct can_priv and fill the hole created after
removing can_priv::ctrlmode_priv.
Please note that the first two patches are not required by the third
one. I am just grouping everything in the same series because the
patches all revolve around the controller modes.
** Changelog **
v1 -> v2:
- Add a first patch to replace can_priv::ctrlmode_static by the
inline function can_get_static_ctrlmode()
- Add a second patch to reorder the fields of struct can_priv for
better packing (save eight bytes on x86_64 \o/)
- Rewrite the comments of the third patch "can: netlink: report the
CAN controller mode supported flags" (no changes on the code
itself).
Vincent Mailhol (3):
can: dev: replace can_priv::ctrlmode_static by
can_get_static_ctrlmode()
can: dev: reorder struct can_priv members for better packing
can: netlink: report the CAN controller mode supported flags
drivers/net/can/dev/dev.c | 5 +++--
drivers/net/can/dev/netlink.c | 7 +++++--
include/linux/can/dev.h | 18 +++++++++++++-----
include/uapi/linux/can/netlink.h | 5 ++++-
4 files changed, 25 insertions(+), 10 deletions(-)
--
2.32.0
From: Vincent Mailhol <hidden> Date: 2021-10-09 13:13:36
The statically enabled features of a CAN controller can be retrieved
using below formula:
| u32 ctrlmode_static = priv->ctrlmode & ~priv->ctrlmode_supported;
As such, there is no need to store this information. This patch remove
the field ctrlmode_static of struct can_priv and provides, in
replacement, the inline function can_get_static_ctrlmode() which
returns the same value.
A condition sine qua non for this to work is that the controller
static modes should never be set in can_priv::ctrlmode_supported. This
is already the case for existing drivers, however, we added a warning
message in can_set_static_ctrlmode() to check that.
Signed-off-by: Vincent Mailhol <redacted>
---
drivers/net/can/dev/dev.c | 5 +++--
drivers/net/can/dev/netlink.c | 2 +-
include/linux/can/dev.h | 12 ++++++++++--
3 files changed, 14 insertions(+), 5 deletions(-)
@@ -300,6 +300,7 @@ EXPORT_SYMBOL_GPL(free_candev);intcan_change_mtu(structnet_device*dev,intnew_mtu){structcan_priv*priv=netdev_priv(dev);+u32ctrlmode_static=can_get_static_ctrlmode(priv);/* Do not allow changing the MTU while running */if(dev->flags&IFF_UP)
@@ -309,7 +310,7 @@ int can_change_mtu(struct net_device *dev, int new_mtu)switch(new_mtu){caseCAN_MTU:/* 'CANFD-only' controllers can not switch to CAN_MTU */-if(priv->ctrlmode_static&CAN_CTRLMODE_FD)+if(ctrlmode_static&CAN_CTRLMODE_FD)return-EINVAL;priv->ctrlmode&=~CAN_CTRLMODE_FD;
@@ -318,7 +319,7 @@ int can_change_mtu(struct net_device *dev, int new_mtu)caseCANFD_MTU:/* check for potential CANFD ability */if(!(priv->ctrlmode_supported&CAN_CTRLMODE_FD)&&-!(priv->ctrlmode_static&CAN_CTRLMODE_FD))+!(ctrlmode_static&CAN_CTRLMODE_FD))return-EINVAL;priv->ctrlmode|=CAN_CTRLMODE_FD;
@@ -69,7 +69,6 @@ struct can_priv {/* CAN controller features - see include/uapi/linux/can/netlink.h */u32ctrlmode;/* current options setting */u32ctrlmode_supported;/* options that can be modified by netlink */-u32ctrlmode_static;/* static enabled options for driver/hardware */intrestart_ms;structdelayed_workrestart_work;
@@ -104,14 +103,23 @@ static inline void can_set_static_ctrlmode(struct net_device *dev,structcan_priv*priv=netdev_priv(dev);/* alloc_candev() succeeded => netdev_priv() is valid at this point */+if(priv->ctrlmode_supported&static_mode){+netdev_warn(dev,+"Controller features can not be supported and static at the same time\n");+return;+}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;}+staticinlineu32can_get_static_ctrlmode(structcan_priv*priv)+{+returnpriv->ctrlmode&~priv->ctrlmode_supported;+}+voidcan_setup(structnet_device*dev);structnet_device*alloc_candev_mqs(intsizeof_priv,unsignedintecho_skb_max,
@@ -64,6 +64,9 @@ struct can_priv {structgpio_desc*termination_gpio;u16termination_gpio_ohms[CAN_TERMINATION_GPIO_MAX];+unsignedintecho_skb_max;+structsk_buff**echo_skb;+enumcan_statestate;/* CAN controller features - see include/uapi/linux/can/netlink.h */
From: Vincent Mailhol <hidden> Date: 2021-10-09 13:14:27
This patch introduces a method for the user to check both the
supported and the static capabilities. The proposed method reuses the
existing struct can_ctrlmode and thus do not need a new IFLA_CAN_*
entry.
Currently, the CAN netlink interface provides no easy ways to check
the capabilities of a given controller. The only method from the
command line is to try each CAN_CTRLMODE_ individually to check
whether the netlink interface returns an -EOPNOTSUPP error or not
(alternatively, one may find it easier to directly check the source
code of the driver instead...)
It appears that, can_ctrlmode::mask is only used in one direction:
from the userland to the kernel. So we can just reuse this field in
the other direction (from the kernel to userland). But, because the
semantic is different, we use a union to give this field a proper
name: supported.
Below table explains how the two fields can_ctrlmode::supported and
can_ctrlmode::flags, when masked with any of the CAN_CTRLMODE_* bit
flags, allow us to identify both the supported and the static
capabilities:
supported & flags & Controller capabilities
CAN_CTRLMODE_* CAN_CTRLMODE_*
-----------------------------------------------------------------------
false false Feature not supported (always disabled)
false true Static feature (always enabled)
true false Feature supported but disabled
true true Feature supported and enabled
Signed-off-by: Vincent Mailhol <redacted>
---
Please refer to below link for the iproute2-next counterpart of this
patch:
https://lore.kernel.org/linux-can/20211003050147.569044-1-mailhol.vincent@wanadoo.fr/T/#t
---
drivers/net/can/dev/netlink.c | 5 ++++-
include/uapi/linux/can/netlink.h | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-10-24 20:25:33
On 09.10.2021 22:13:02, Vincent Mailhol wrote:
The statically enabled features of a CAN controller can be retrieved
using below formula:
| u32 ctrlmode_static = priv->ctrlmode & ~priv->ctrlmode_supported;
As such, there is no need to store this information. This patch remove
the field ctrlmode_static of struct can_priv and provides, in
replacement, the inline function can_get_static_ctrlmode() which
returns the same value.
A condition sine qua non for this to work is that the controller
static modes should never be set in can_priv::ctrlmode_supported. This
is already the case for existing drivers, however, we added a warning
message in can_set_static_ctrlmode() to check that.
Please make the can_set_static_ctrlmode to return an error in case of a
problem. Adjust the drivers using the function is this patch, too.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
From: Vincent MAILHOL <hidden> Date: 2021-10-25 17:22:51
Hi Marc,
Welcome back on the mailing list, hope you had some nice
holidays! And also thanks a lot for your support over the last
few months on my other series to introduce the TDC netlink
interface :)
Le lun. 25 oct. 2021 à 03:30, Marc Kleine-Budde [off-list ref] a écrit :
On 09.10.2021 22:13:02, Vincent Mailhol wrote:
quoted
The statically enabled features of a CAN controller can be retrieved
using below formula:
| u32 ctrlmode_static = priv->ctrlmode & ~priv->ctrlmode_supported;
As such, there is no need to store this information. This patch remove
the field ctrlmode_static of struct can_priv and provides, in
replacement, the inline function can_get_static_ctrlmode() which
returns the same value.
A condition sine qua non for this to work is that the controller
static modes should never be set in can_priv::ctrlmode_supported. This
is already the case for existing drivers, however, we added a warning
message in can_set_static_ctrlmode() to check that.
Please make the can_set_static_ctrlmode to return an error in case of a
problem. Adjust the drivers using the function is this patch, too.
I didn't do so initially because this is more a static
configuration issue that should only occur during
development. Nonetheless, what you suggest is really simple.
I will just split the patch in two: one of the setter and one for
the getter and address your comments.
Yours sincerely,
Vincent Mailhol
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-10-25 19:06:59
On 26.10.2021 02:22:36, Vincent MAILHOL wrote:
Welcome back on the mailing list, hope you had some nice
holidays!
Thanks was really nice, good weather, 1000km of cycling and hanging
around in Vienna. :D
And also thanks a lot for your support over the last
few months on my other series to introduce the TDC netlink
interface :)
The pleasure is on my side, working with you!
Le lun. 25 oct. 2021 à 03:30, Marc Kleine-Budde [off-list ref] a écrit :
quoted
On 09.10.2021 22:13:02, Vincent Mailhol wrote:
quoted
The statically enabled features of a CAN controller can be retrieved
using below formula:
| u32 ctrlmode_static = priv->ctrlmode & ~priv->ctrlmode_supported;
As such, there is no need to store this information. This patch remove
the field ctrlmode_static of struct can_priv and provides, in
replacement, the inline function can_get_static_ctrlmode() which
returns the same value.
A condition sine qua non for this to work is that the controller
static modes should never be set in can_priv::ctrlmode_supported. This
is already the case for existing drivers, however, we added a warning
message in can_set_static_ctrlmode() to check that.
Please make the can_set_static_ctrlmode to return an error in case of a
problem. Adjust the drivers using the function is this patch, too.
I didn't do so initially because this is more a static
configuration issue that should only occur during
development. Nonetheless, what you suggest is really simple.
I will just split the patch in two: one of the setter and one for
the getter and address your comments.
Fine with me. Most important thing is, that the kernel compiles after
each patch.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
From: Vincent MAILHOL <hidden> Date: 2021-10-26 01:36:33
On Tue. 26 Oct 2021 at 04:06, Marc Kleine-Budde [off-list ref] wrote:
On 26.10.2021 02:22:36, Vincent MAILHOL wrote:
quoted
Welcome back on the mailing list, hope you had some nice
holidays!
Thanks was really nice, good weather, 1000km of cycling and hanging
around in Vienna. :D
quoted
And also thanks a lot for your support over the last
few months on my other series to introduce the TDC netlink
interface :)
The pleasure is on my side, working with you!
quoted
Le lun. 25 oct. 2021 à 03:30, Marc Kleine-Budde [off-list ref] a écrit :
quoted
On 09.10.2021 22:13:02, Vincent Mailhol wrote:
quoted
The statically enabled features of a CAN controller can be retrieved
using below formula:
| u32 ctrlmode_static = priv->ctrlmode & ~priv->ctrlmode_supported;
As such, there is no need to store this information. This patch remove
the field ctrlmode_static of struct can_priv and provides, in
replacement, the inline function can_get_static_ctrlmode() which
returns the same value.
A condition sine qua non for this to work is that the controller
static modes should never be set in can_priv::ctrlmode_supported. This
is already the case for existing drivers, however, we added a warning
message in can_set_static_ctrlmode() to check that.
Please make the can_set_static_ctrlmode to return an error in case of a
problem. Adjust the drivers using the function is this patch, too.
I didn't do so initially because this is more a static
configuration issue that should only occur during
development. Nonetheless, what you suggest is really simple.
I will just split the patch in two: one of the setter and one for
the getter and address your comments.
Fine with me. Most important thing is, that the kernel compiles after
each patch.