* [PATCH 0/2] can: drop tx skb if the device is in listen only mode @ 2022-05-13 14:23 Vincent Mailhol 2022-05-13 14:23 ` [PATCH 1/2] can: move can_dropped_invalid_skb from skb.h to dev.h Vincent Mailhol ` (7 more replies) 0 siblings, 8 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-13 14:23 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: linux-can, linux-kernel, Max Staudt, Vincent Mailhol In listen only mode, tx CAN frames can still reach the driver if injected via the packet socket. This series add a check toward CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard such skb. The first patch does some preparation work and migrates can_dropped_invalid_skb() from skb.h to dev.h. The second and last patch is the actual change. Vincent Mailhol (2): can: move can_dropped_invalid_skb from skb.h to dev.h can: dev: drop tx skb if in listen only mode include/linux/can/dev.h | 35 +++++++++++++++++++++++++++++++++++ include/linux/can/skb.h | 28 ---------------------------- 2 files changed, 35 insertions(+), 28 deletions(-) -- 2.35.1 ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 1/2] can: move can_dropped_invalid_skb from skb.h to dev.h 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol @ 2022-05-13 14:23 ` Vincent Mailhol 2022-05-13 14:23 ` [PATCH 2/2] can: dev: drop tx skb if in listen only mode Vincent Mailhol ` (6 subsequent siblings) 7 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-13 14:23 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: linux-can, linux-kernel, Max Staudt, Vincent Mailhol This is a preparation patch for next change. We want to introduce a check towards CAN_CTRLMODE_LISTENONLY in can_dopped_invalid_skb(). To do so, we would need to include linux/can/dev.h (for struct can_priv) and uapi/linux/can/netlink.h (for the definition of CAN_CTRLMODE_LISTEONLY). Instead of adding those header and contributing to the include hell, we prever to relocate can_dropped_invalid_skb() to linux/can/dev.h where all the needed headers are already present. While doing so, do a small cleanup: re-indent the second line of the function argument and add brackets around the else block. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- include/linux/can/dev.h | 29 +++++++++++++++++++++++++++++ include/linux/can/skb.h | 28 ---------------------------- 2 files changed, 29 insertions(+), 28 deletions(-) diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h index c2ea47f30046..bbe27e22c7a7 100644 --- a/include/linux/can/dev.h +++ b/include/linux/can/dev.h @@ -156,6 +156,35 @@ static inline u32 can_get_static_ctrlmode(struct can_priv *priv) return priv->ctrlmode & ~priv->ctrlmode_supported; } +/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ +static inline bool can_dropped_invalid_skb(struct net_device *dev, + struct sk_buff *skb) +{ + const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + + if (skb->protocol == htons(ETH_P_CAN)) { + if (unlikely(skb->len != CAN_MTU || + cfd->len > CAN_MAX_DLEN)) + goto inval_skb; + } else if (skb->protocol == htons(ETH_P_CANFD)) { + if (unlikely(skb->len != CANFD_MTU || + cfd->len > CANFD_MAX_DLEN)) + goto inval_skb; + } else { + goto inval_skb; + } + + if (!can_skb_headroom_valid(dev, skb)) + goto inval_skb; + + return false; + +inval_skb: + kfree_skb(skb); + dev->stats.tx_dropped++; + return true; +} + void can_setup(struct net_device *dev); struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max, diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index fdb22b00674a..985791c84a8d 100644 --- a/include/linux/can/skb.h +++ b/include/linux/can/skb.h @@ -126,34 +126,6 @@ static inline bool can_skb_headroom_valid(struct net_device *dev, return true; } -/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ -static inline bool can_dropped_invalid_skb(struct net_device *dev, - struct sk_buff *skb) -{ - const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; - - if (skb->protocol == htons(ETH_P_CAN)) { - if (unlikely(skb->len != CAN_MTU || - cfd->len > CAN_MAX_DLEN)) - goto inval_skb; - } else if (skb->protocol == htons(ETH_P_CANFD)) { - if (unlikely(skb->len != CANFD_MTU || - cfd->len > CANFD_MAX_DLEN)) - goto inval_skb; - } else - goto inval_skb; - - if (!can_skb_headroom_valid(dev, skb)) - goto inval_skb; - - return false; - -inval_skb: - kfree_skb(skb); - dev->stats.tx_dropped++; - return true; -} - static inline bool can_is_canfd_skb(const struct sk_buff *skb) { /* the CAN specific type of skb is identified by its data length */ -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 2/2] can: dev: drop tx skb if in listen only mode 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol 2022-05-13 14:23 ` [PATCH 1/2] can: move can_dropped_invalid_skb from skb.h to dev.h Vincent Mailhol @ 2022-05-13 14:23 ` Vincent Mailhol 2022-05-13 14:42 ` [PATCH 0/2] can: drop tx skb if the device is " Marc Kleine-Budde ` (5 subsequent siblings) 7 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-13 14:23 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: linux-can, linux-kernel, Max Staudt, Vincent Mailhol Frames can be directly injected to a can driver via the packet socket. By doing that, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configure in listen only mode. Add a check in can_dropped_invalid_skb() and to discard the skb if CAN_CTRLMODE_LISTENONLY is set. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- include/linux/can/dev.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h index bbe27e22c7a7..c3ed48e54c29 100644 --- a/include/linux/can/dev.h +++ b/include/linux/can/dev.h @@ -161,6 +161,7 @@ static inline bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) { const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + struct can_priv *priv = netdev_priv(dev); if (skb->protocol == htons(ETH_P_CAN)) { if (unlikely(skb->len != CAN_MTU || @@ -174,8 +175,13 @@ static inline bool can_dropped_invalid_skb(struct net_device *dev, goto inval_skb; } - if (!can_skb_headroom_valid(dev, skb)) + if (!can_skb_headroom_valid(dev, skb)) { + goto inval_skb; + } else if (priv->ctrlmode & CAN_CTRLMODE_LISTENONLY) { + netdev_info_once(dev, + "interface in listen only mode, dropping skb\n"); goto inval_skb; + } return false; -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH 0/2] can: drop tx skb if the device is in listen only mode 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol 2022-05-13 14:23 ` [PATCH 1/2] can: move can_dropped_invalid_skb from skb.h to dev.h Vincent Mailhol 2022-05-13 14:23 ` [PATCH 2/2] can: dev: drop tx skb if in listen only mode Vincent Mailhol @ 2022-05-13 14:42 ` Marc Kleine-Budde 2022-05-13 15:20 ` Vincent MAILHOL 2022-05-13 15:36 ` [PATCH v2 " Vincent Mailhol ` (4 subsequent siblings) 7 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-13 14:42 UTC (permalink / raw) To: Vincent Mailhol; +Cc: linux-can, linux-kernel, Max Staudt [-- Attachment #1: Type: text/plain, Size: 899 bytes --] On 13.05.2022 23:23:53, Vincent Mailhol wrote: > In listen only mode, tx CAN frames can still reach the driver if > injected via the packet socket. This series add a check toward > CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard such > skb. The first patch does some preparation work and migrates > can_dropped_invalid_skb() from skb.h to dev.h. The second and last > patch is the actual change. Thanks for your quick patch! What about moving the function to a .c file? The can_dropped_invalid_skb() grew a lot over the years, since it was added to the header as a static inline function. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 0/2] can: drop tx skb if the device is in listen only mode 2022-05-13 14:42 ` [PATCH 0/2] can: drop tx skb if the device is " Marc Kleine-Budde @ 2022-05-13 15:20 ` Vincent MAILHOL 0 siblings, 0 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-13 15:20 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: linux-can, linux-kernel, Max Staudt On Fri. 13 May 2022 at 23:42, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 13.05.2022 23:23:53, Vincent Mailhol wrote: > > In listen only mode, tx CAN frames can still reach the driver if > > injected via the packet socket. This series add a check toward > > CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard such > > skb. The first patch does some preparation work and migrates > > can_dropped_invalid_skb() from skb.h to dev.h. The second and last > > patch is the actual change. > > Thanks for your quick patch! > > What about moving the function to a .c file? The > can_dropped_invalid_skb() grew a lot over the years, since it was added > to the header as a static inline function. OK. Will also migrate can_skb_headrom_valid() which is only used by can_dropped_invalid_skb(). > 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 | ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v2 0/2] can: drop tx skb if the device is in listen only mode 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol ` (2 preceding siblings ...) 2022-05-13 14:42 ` [PATCH 0/2] can: drop tx skb if the device is " Marc Kleine-Budde @ 2022-05-13 15:36 ` Vincent Mailhol 2022-05-13 15:36 ` [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol ` (2 more replies) 2022-05-14 14:16 ` [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes Vincent Mailhol ` (3 subsequent siblings) 7 siblings, 3 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-13 15:36 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: linux-can, linux-kernel, Max Staudt, Vincent Mailhol In listen only mode, tx CAN frames can still reach the driver if injected via the packet socket. This series add a check toward CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard such skb. The first patch does some preparation work and migrates can_dropped_invalid_skb() and can_skb_headroom_valid() from skb.h to skb.c. This preparation is needed because skb.h does not include linux/can/dev.h (for struct can_priv) and uapi/linux/can/netlink.h (for the definition of CAN_CTRLMODE_LISTEONLY) which we need for this change. The function being already big, better to de-inline them and move them to a .c file. The second and last patch is the actual change. * Changelog * v1 -> v2 * move can_dropped_invalid_skb() to skb.c instead of dev.h * also move can_skb_headroom_valid() to skb.c Vincent Mailhol (2): can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c can: dev: drop tx skb if in listen only mode drivers/net/can/dev/skb.c | 65 +++++++++++++++++++++++++++++++++++++++ include/linux/can/skb.h | 59 +---------------------------------- 2 files changed, 66 insertions(+), 58 deletions(-) -- 2.35.1 ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-13 15:36 ` [PATCH v2 " Vincent Mailhol @ 2022-05-13 15:36 ` Vincent Mailhol 2022-05-14 4:20 ` kernel test robot 2022-05-13 15:36 ` [PATCH v2 2/2] can: dev: drop tx skb if in listen only mode Vincent Mailhol 2022-05-13 17:40 ` [PATCH v2 0/2] can: drop tx skb if the device is " Max Staudt 2 siblings, 1 reply; 119+ messages in thread From: Vincent Mailhol @ 2022-05-13 15:36 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: linux-can, linux-kernel, Max Staudt, Vincent Mailhol The functions can_dropped_invalid_skb() and can_skb_headroom_valid() grew a lot over the years to a point which it does make much sense to have them defined as static inline in header files. Move those two functions to the .c counterpart of skb.h. can_skb_headroom_valid() only caller being can_dropped_invalid_skb(), the declaration is removed from the header. Only can_dropped_invalid_skb() gets its symbol exported. While doing so, do a small cleanup: add brackets around the else block in can_dropped_invalid_skb(). Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 58 ++++++++++++++++++++++++++++++++++++++ include/linux/can/skb.h | 59 +-------------------------------------- 2 files changed, 59 insertions(+), 58 deletions(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index 61660248c69e..8b1991130de5 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -252,3 +252,61 @@ struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf) return skb; } EXPORT_SYMBOL_GPL(alloc_can_err_skb); + +/* Check for outgoing skbs that have not been created by the CAN subsystem */ +static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) +{ + /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ + if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) + return false; + + /* af_packet does not apply CAN skb specific settings */ + if (skb->ip_summed == CHECKSUM_NONE) { + /* init headroom */ + can_skb_prv(skb)->ifindex = dev->ifindex; + can_skb_prv(skb)->skbcnt = 0; + + skb->ip_summed = CHECKSUM_UNNECESSARY; + + /* perform proper loopback on capable devices */ + if (dev->flags & IFF_ECHO) + skb->pkt_type = PACKET_LOOPBACK; + else + skb->pkt_type = PACKET_HOST; + + skb_reset_mac_header(skb); + skb_reset_network_header(skb); + skb_reset_transport_header(skb); + } + + return true; +} + +/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) +{ + const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + + if (skb->protocol == htons(ETH_P_CAN)) { + if (unlikely(skb->len != CAN_MTU || + cfd->len > CAN_MAX_DLEN)) + goto inval_skb; + } else if (skb->protocol == htons(ETH_P_CANFD)) { + if (unlikely(skb->len != CANFD_MTU || + cfd->len > CANFD_MAX_DLEN)) + goto inval_skb; + } else { + goto inval_skb; + } + + if (!can_skb_headroom_valid(dev, skb)) + goto inval_skb; + + return false; + +inval_skb: + kfree_skb(skb); + dev->stats.tx_dropped++; + return true; +} +EXPORT_SYMBOL_GPL(can_dropped_invalid_skb); diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index fdb22b00674a..182749e858b3 100644 --- a/include/linux/can/skb.h +++ b/include/linux/can/skb.h @@ -31,6 +31,7 @@ struct sk_buff *alloc_canfd_skb(struct net_device *dev, struct canfd_frame **cfd); struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf); +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb); /* * The struct can_skb_priv is used to transport additional information along @@ -96,64 +97,6 @@ static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb) return nskb; } -/* Check for outgoing skbs that have not been created by the CAN subsystem */ -static inline bool can_skb_headroom_valid(struct net_device *dev, - struct sk_buff *skb) -{ - /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ - if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) - return false; - - /* af_packet does not apply CAN skb specific settings */ - if (skb->ip_summed == CHECKSUM_NONE) { - /* init headroom */ - can_skb_prv(skb)->ifindex = dev->ifindex; - can_skb_prv(skb)->skbcnt = 0; - - skb->ip_summed = CHECKSUM_UNNECESSARY; - - /* perform proper loopback on capable devices */ - if (dev->flags & IFF_ECHO) - skb->pkt_type = PACKET_LOOPBACK; - else - skb->pkt_type = PACKET_HOST; - - skb_reset_mac_header(skb); - skb_reset_network_header(skb); - skb_reset_transport_header(skb); - } - - return true; -} - -/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ -static inline bool can_dropped_invalid_skb(struct net_device *dev, - struct sk_buff *skb) -{ - const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; - - if (skb->protocol == htons(ETH_P_CAN)) { - if (unlikely(skb->len != CAN_MTU || - cfd->len > CAN_MAX_DLEN)) - goto inval_skb; - } else if (skb->protocol == htons(ETH_P_CANFD)) { - if (unlikely(skb->len != CANFD_MTU || - cfd->len > CANFD_MAX_DLEN)) - goto inval_skb; - } else - goto inval_skb; - - if (!can_skb_headroom_valid(dev, skb)) - goto inval_skb; - - return false; - -inval_skb: - kfree_skb(skb); - dev->stats.tx_dropped++; - return true; -} - static inline bool can_is_canfd_skb(const struct sk_buff *skb) { /* the CAN specific type of skb is identified by its data length */ -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-13 15:36 ` [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol @ 2022-05-14 4:20 ` kernel test robot 2022-05-14 5:16 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: kernel test robot @ 2022-05-14 4:20 UTC (permalink / raw) To: Vincent Mailhol, Marc Kleine-Budde Cc: llvm, kbuild-all, linux-can, linux-kernel, Max Staudt, Vincent Mailhol Hi Vincent, I love your patch! Yet something to improve: [auto build test ERROR on mkl-can-next/testing] [also build test ERROR on v5.18-rc6 next-20220513] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/intel-lab-lkp/linux/commits/Vincent-Mailhol/can-skb-move-can_dropped_invalid_skb-and-can_skb_headroom_valid-to-skb-c/20220514-003707 base: https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git testing config: arm-randconfig-r021-20220512 (https://download.01.org/0day-ci/archive/20220514/202205141221.H0aZXRak-lkp@intel.com/config) compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 38189438b69ca27b4c6ce707c52dbd217583d046) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm cross compiling tool for clang build # apt-get install binutils-arm-linux-gnueabi # https://github.com/intel-lab-lkp/linux/commit/8f56e6b1b9945ea47c9f410d1254451df9d6fe22 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Vincent-Mailhol/can-skb-move-can_dropped_invalid_skb-and-can_skb_headroom_valid-to-skb-c/20220514-003707 git checkout 8f56e6b1b9945ea47c9f410d1254451df9d6fe22 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): ld.lld: warning: lld uses blx instruction, no object with architecture supporting feature detected ld.lld: warning: lld uses blx instruction, no object with architecture supporting feature detected >> ld.lld: error: undefined symbol: can_dropped_invalid_skb >>> referenced by vxcan.c:45 (drivers/net/can/vxcan.c:45) >>> net/can/vxcan.o:(vxcan_xmit) in archive drivers/built-in.a -- 0-DAY CI Kernel Test Service https://01.org/lkp ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-14 4:20 ` kernel test robot @ 2022-05-14 5:16 ` Vincent MAILHOL 2022-05-14 11:17 ` Max Staudt 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-14 5:16 UTC (permalink / raw) To: kernel test robot Cc: Marc Kleine-Budde, llvm, kbuild-all, linux-can, linux-kernel, Max Staudt On Sat. 14 May 2022 à 13:20, kernel test robot <lkp@intel.com> wrote: > Hi Vincent, > > I love your patch! Yet something to improve: > > [auto build test ERROR on mkl-can-next/testing] > [also build test ERROR on v5.18-rc6 next-20220513] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: https://github.com/intel-lab-lkp/linux/commits/Vincent-Mailhol/can-skb-move-can_dropped_invalid_skb-and-can_skb_headroom_valid-to-skb-c/20220514-003707 > base: https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git testing > config: arm-randconfig-r021-20220512 (https://download.01.org/0day-ci/archive/20220514/202205141221.H0aZXRak-lkp@intel.com/config) > compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 38189438b69ca27b4c6ce707c52dbd217583d046) > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm cross compiling tool for clang build > # apt-get install binutils-arm-linux-gnueabi > # https://github.com/intel-lab-lkp/linux/commit/8f56e6b1b9945ea47c9f410d1254451df9d6fe22 > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review Vincent-Mailhol/can-skb-move-can_dropped_invalid_skb-and-can_skb_headroom_valid-to-skb-c/20220514-003707 > git checkout 8f56e6b1b9945ea47c9f410d1254451df9d6fe22 > # save the config file > mkdir build_dir && cp config build_dir/.config > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot <lkp@intel.com> > > All errors (new ones prefixed by >>): > > ld.lld: warning: lld uses blx instruction, no object with architecture supporting feature detected > ld.lld: warning: lld uses blx instruction, no object with architecture supporting feature detected > >> ld.lld: error: undefined symbol: can_dropped_invalid_skb > >>> referenced by vxcan.c:45 (drivers/net/can/vxcan.c:45) > >>> net/can/vxcan.o:(vxcan_xmit) in archive drivers/built-in.a OK, so the issue is that VCAN and VXCAN are users of can_dropped_invalid_skb() but do not depend on CAN_DEV. Above error will appear if CONFIG_CAN_DEV is not set (or if CONFIG_V{,X}CAN is set to "yes" and CAN_DEV is set to "module"). I see three choices here: 1. move can_dropped_invalid_skb() outside of drivers/net/can (i.e. move it somewhere in net/can). 2. split CAN_DEV into one additional sub module: CAN_SKB and add a dependency to it in VCAN and VXCAN. 3. Add a dependency to CAN_DEV in VCAN and VXCAN 1. is I think the worse, 2. the best, 3. is the laziest option and is kind of acceptable. @Marc (and anyone else), what are your thoughts? Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-14 5:16 ` Vincent MAILHOL @ 2022-05-14 11:17 ` Max Staudt 0 siblings, 0 replies; 119+ messages in thread From: Max Staudt @ 2022-05-14 11:17 UTC (permalink / raw) To: Vincent MAILHOL Cc: kernel test robot, Marc Kleine-Budde, llvm, kbuild-all, linux-can, linux-kernel On Sat, 14 May 2022 14:16:09 +0900 Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > OK, so the issue is that VCAN and VXCAN are users of > can_dropped_invalid_skb() but do not depend on CAN_DEV. Above error > will appear if CONFIG_CAN_DEV is not set (or if CONFIG_V{,X}CAN is set > to "yes" and CAN_DEV is set to "module"). > I see three choices here: > 1. move can_dropped_invalid_skb() outside of drivers/net/can (i.e. > move it somewhere in net/can). > 2. split CAN_DEV into one additional sub module: CAN_SKB and add a > dependency to it in VCAN and VXCAN. > 3. Add a dependency to CAN_DEV in VCAN and VXCAN > > 1. is I think the worse, 2. the best, 3. is the laziest option and is > kind of acceptable. > @Marc (and anyone else), what are your thoughts? I think that having v(x)can depend on can-dev isn't half bad - for the user, they are CAN devices, anyway, and modprobe does the dependency resolution magic. Splitting into too many modules is something I'd avoid because of the overhead involved. Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v2 2/2] can: dev: drop tx skb if in listen only mode 2022-05-13 15:36 ` [PATCH v2 " Vincent Mailhol 2022-05-13 15:36 ` [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol @ 2022-05-13 15:36 ` Vincent Mailhol 2022-05-13 17:40 ` [PATCH v2 0/2] can: drop tx skb if the device is " Max Staudt 2 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-13 15:36 UTC (permalink / raw) To: Marc Kleine-Budde; +Cc: linux-can, linux-kernel, Max Staudt, Vincent Mailhol Frames can be directly injected to a can driver via the packet socket. By doing that, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configure in listen only mode. Add a check in can_dropped_invalid_skb() and to discard the skb if CAN_CTRLMODE_LISTENONLY is set. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index 8b1991130de5..f7420fc43b99 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,7 @@ */ #include <linux/can/dev.h> +#include <linux/can/netlink.h> /* Local echo of CAN messages * @@ -286,6 +287,7 @@ static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) { const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + struct can_priv *priv = netdev_priv(dev); if (skb->protocol == htons(ETH_P_CAN)) { if (unlikely(skb->len != CAN_MTU || @@ -299,8 +301,13 @@ bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) goto inval_skb; } - if (!can_skb_headroom_valid(dev, skb)) + if (!can_skb_headroom_valid(dev, skb)) { + goto inval_skb; + } else if (priv->ctrlmode & CAN_CTRLMODE_LISTENONLY) { + netdev_info_once(dev, + "interface in listen only mode, dropping skb\n"); goto inval_skb; + } return false; -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v2 0/2] can: drop tx skb if the device is in listen only mode 2022-05-13 15:36 ` [PATCH v2 " Vincent Mailhol 2022-05-13 15:36 ` [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol 2022-05-13 15:36 ` [PATCH v2 2/2] can: dev: drop tx skb if in listen only mode Vincent Mailhol @ 2022-05-13 17:40 ` Max Staudt 2022-05-14 3:00 ` Vincent MAILHOL 2 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-05-13 17:40 UTC (permalink / raw) To: Vincent Mailhol; +Cc: Marc Kleine-Budde, linux-can, linux-kernel From my view (I don't have the big picture here), this series looks good to me. Thanks! Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v2 0/2] can: drop tx skb if the device is in listen only mode 2022-05-13 17:40 ` [PATCH v2 0/2] can: drop tx skb if the device is " Max Staudt @ 2022-05-14 3:00 ` Vincent MAILHOL 0 siblings, 0 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-14 3:00 UTC (permalink / raw) To: Max Staudt; +Cc: Marc Kleine-Budde, linux-can, linux-kernel On Sat. 14 May 2022 at 02:40, Max Staudt <max@enpas.org> wrote: > From my view (I don't have the big picture here), this series looks good > to me. Thanks! Great! Can I add the tag below to the series? Acked-by: Max Staudt <max@enpas.org> (or any other based on your preference) If this series gets pulled, you can remove the check from your driver. ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol ` (3 preceding siblings ...) 2022-05-13 15:36 ` [PATCH v2 " Vincent Mailhol @ 2022-05-14 14:16 ` Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 1/4] can: slcan: use can_dropped_invalid_skb() instead of manual check Vincent Mailhol ` (3 more replies) 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol ` (2 subsequent siblings) 7 siblings, 4 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-14 14:16 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol In listen only mode, tx CAN frames can still reach the driver if injected via the packet socket. This series add a check toward CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard such skb. The fourth and last patch is the actual change. This goal cascaded in the need to create other patches which will be explained in reverse order. The third patch migrates can_dropped_invalid_skb() and can_skb_headroom_valid() from skb.h to skb.c. This preparation is needed because skb.h does not include linux/can/dev.h (for struct can_priv) and uapi/linux/can/netlink.h (for the definition of CAN_CTRLMODE_LISTEONLY) which we need for this change. The function being already big, better to de-inline them and move them to a .c file. The third patch would not work without some adjustment to Kbuild. VCAN and VXCAN are users of can_dropped_invalid_skb() but do not depend on CAN_DEV and thus would not see the symbols from skb.o if CONFIG_CAN_DEV is not selected. c.f. kernel test robot report on the v2 of this series [1]. The second patch modifies Kbuild to fix it. slcan does not depend of can_dropped_invalid_skb() which would make it the only driver with no dependencies on CAN_DEV. Because I wanted an excuse to move all the driver under CAN_DEV in the second patch, the first patch applies can_dropped_invalid_skb() to slcan to make it dependent. [1] https://lore.kernel.org/linux-can/202205141221.H0aZXRak-lkp@intel.com/ * Changelog * v2 -> v3 * Apply can_dropped_invalid_skb() to slcan. * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by modifying Kbuild. * fix small typos. v1 -> v2 * move can_dropped_invalid_skb() to skb.c instead of dev.h * also move can_skb_headroom_valid() to skb.c Vincent Mailhol (4): can: slcan: use can_dropped_invalid_skb() instead of manual check can: Kconfig: change CAN_DEV into a menuconfig can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c can: dev: drop tx skb if in listen only mode drivers/net/can/Kconfig | 33 +++++++++++--------- drivers/net/can/dev/skb.c | 65 +++++++++++++++++++++++++++++++++++++++ drivers/net/can/slcan.c | 4 +-- include/linux/can/skb.h | 59 +---------------------------------- 4 files changed, 87 insertions(+), 74 deletions(-) -- 2.35.1 ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v3 1/4] can: slcan: use can_dropped_invalid_skb() instead of manual check 2022-05-14 14:16 ` [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes Vincent Mailhol @ 2022-05-14 14:16 ` Vincent Mailhol 2022-05-16 20:40 ` Marc Kleine-Budde 2022-05-14 14:16 ` [PATCH v3 2/4] can: Kconfig: change CAN_DEV into a menuconfig Vincent Mailhol ` (2 subsequent siblings) 3 siblings, 1 reply; 119+ messages in thread From: Vincent Mailhol @ 2022-05-14 14:16 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol slcan does a manual check in slc_xmit() to verify if the skb is valid. This check is incomplete, use instead can_dropped_invalid_skb(). Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/slcan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c index 27783fbf011f..1879b50391ee 100644 --- a/drivers/net/can/slcan.c +++ b/drivers/net/can/slcan.c @@ -359,8 +359,8 @@ static netdev_tx_t slc_xmit(struct sk_buff *skb, struct net_device *dev) { struct slcan *sl = netdev_priv(dev); - if (skb->len != CAN_MTU) - goto out; + if (can_dropped_invalid_skb(dev, skb)) + return NETDEV_TX_OK; spin_lock(&sl->lock); if (!netif_running(dev)) { -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v3 1/4] can: slcan: use can_dropped_invalid_skb() instead of manual check 2022-05-14 14:16 ` [PATCH v3 1/4] can: slcan: use can_dropped_invalid_skb() instead of manual check Vincent Mailhol @ 2022-05-16 20:40 ` Marc Kleine-Budde 0 siblings, 0 replies; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-16 20:40 UTC (permalink / raw) To: Vincent Mailhol Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 616 bytes --] On 14.05.2022 23:16:47, Vincent Mailhol wrote: > slcan does a manual check in slc_xmit() to verify if the skb is > valid. This check is incomplete, use instead > can_dropped_invalid_skb(). > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> I've taken this patch into the latest pull request to net-next. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v3 2/4] can: Kconfig: change CAN_DEV into a menuconfig 2022-05-14 14:16 ` [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 1/4] can: slcan: use can_dropped_invalid_skb() instead of manual check Vincent Mailhol @ 2022-05-14 14:16 ` Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 4/4] can: dev: drop tx skb if in listen only mode Vincent Mailhol 3 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-14 14:16 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Currently, only slcan, vcan and vxcan do not depend on CAN_DEV. This is going to change in the next patch when can_dropped_invalid_skb() will be moved into skb.c. In prevision to that, move CAN_DEV one rank up by making it a menuconfig. The description of CAN_DEV is updated accordingly. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index fff259247d52..9bddccfaa0c5 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -1,5 +1,22 @@ # SPDX-License-Identifier: GPL-2.0-only -menu "CAN Device Drivers" + +menuconfig CAN_DEV + tristate "CAN Device Drivers" + default y + help + This section contains all the CAN device drivers including + the virtual ones. + + Saying Y here enables the common framework for platform CAN + drivers with Netlink support. This is the standard library + for CAN drivers. + + To compile as a module, choose M here: the module will be + called can_dev. + + If unsure, say Y. + +if CAN_DEV config CAN_VCAN tristate "Virtual Local CAN Interface (vcan)" @@ -48,16 +65,6 @@ config CAN_SLCAN can be changed by the 'maxdev=xx' module option. This driver can also be built as a module. If so, the module will be called slcan. -config CAN_DEV - tristate "Platform CAN drivers with Netlink support" - default y - help - Enables the common framework for platform CAN drivers with Netlink - support. This is the standard library for CAN drivers. - If unsure, say Y. - -if CAN_DEV - config CAN_CALC_BITTIMING bool "CAN bit-timing calculation" default y @@ -180,8 +187,6 @@ source "drivers/net/can/softing/Kconfig" source "drivers/net/can/spi/Kconfig" source "drivers/net/can/usb/Kconfig" -endif - config CAN_DEBUG_DEVICES bool "CAN devices debugging messages" help @@ -190,4 +195,4 @@ config CAN_DEBUG_DEVICES a problem with CAN support and want to see more of what is going on. -endmenu +endif -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-14 14:16 ` [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 1/4] can: slcan: use can_dropped_invalid_skb() instead of manual check Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 2/4] can: Kconfig: change CAN_DEV into a menuconfig Vincent Mailhol @ 2022-05-14 14:16 ` Vincent Mailhol 2022-05-15 19:17 ` Oliver Hartkopp 2022-05-14 14:16 ` [PATCH v3 4/4] can: dev: drop tx skb if in listen only mode Vincent Mailhol 3 siblings, 1 reply; 119+ messages in thread From: Vincent Mailhol @ 2022-05-14 14:16 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol The functions can_dropped_invalid_skb() and can_skb_headroom_valid() grew a lot over the years to a point which it does not make much sense to have them defined as static inline in header files. Move those two functions to the .c counterpart of skb.h. can_skb_headroom_valid() only caller being can_dropped_invalid_skb(), the declaration is removed from the header. Only can_dropped_invalid_skb() gets its symbol exported. While doing so, do a small cleanup: add brackets around the else block in can_dropped_invalid_skb(). Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 58 ++++++++++++++++++++++++++++++++++++++ include/linux/can/skb.h | 59 +-------------------------------------- 2 files changed, 59 insertions(+), 58 deletions(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index 61660248c69e..8b1991130de5 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -252,3 +252,61 @@ struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf) return skb; } EXPORT_SYMBOL_GPL(alloc_can_err_skb); + +/* Check for outgoing skbs that have not been created by the CAN subsystem */ +static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) +{ + /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ + if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) + return false; + + /* af_packet does not apply CAN skb specific settings */ + if (skb->ip_summed == CHECKSUM_NONE) { + /* init headroom */ + can_skb_prv(skb)->ifindex = dev->ifindex; + can_skb_prv(skb)->skbcnt = 0; + + skb->ip_summed = CHECKSUM_UNNECESSARY; + + /* perform proper loopback on capable devices */ + if (dev->flags & IFF_ECHO) + skb->pkt_type = PACKET_LOOPBACK; + else + skb->pkt_type = PACKET_HOST; + + skb_reset_mac_header(skb); + skb_reset_network_header(skb); + skb_reset_transport_header(skb); + } + + return true; +} + +/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) +{ + const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + + if (skb->protocol == htons(ETH_P_CAN)) { + if (unlikely(skb->len != CAN_MTU || + cfd->len > CAN_MAX_DLEN)) + goto inval_skb; + } else if (skb->protocol == htons(ETH_P_CANFD)) { + if (unlikely(skb->len != CANFD_MTU || + cfd->len > CANFD_MAX_DLEN)) + goto inval_skb; + } else { + goto inval_skb; + } + + if (!can_skb_headroom_valid(dev, skb)) + goto inval_skb; + + return false; + +inval_skb: + kfree_skb(skb); + dev->stats.tx_dropped++; + return true; +} +EXPORT_SYMBOL_GPL(can_dropped_invalid_skb); diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index fdb22b00674a..182749e858b3 100644 --- a/include/linux/can/skb.h +++ b/include/linux/can/skb.h @@ -31,6 +31,7 @@ struct sk_buff *alloc_canfd_skb(struct net_device *dev, struct canfd_frame **cfd); struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf); +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb); /* * The struct can_skb_priv is used to transport additional information along @@ -96,64 +97,6 @@ static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb) return nskb; } -/* Check for outgoing skbs that have not been created by the CAN subsystem */ -static inline bool can_skb_headroom_valid(struct net_device *dev, - struct sk_buff *skb) -{ - /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ - if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) - return false; - - /* af_packet does not apply CAN skb specific settings */ - if (skb->ip_summed == CHECKSUM_NONE) { - /* init headroom */ - can_skb_prv(skb)->ifindex = dev->ifindex; - can_skb_prv(skb)->skbcnt = 0; - - skb->ip_summed = CHECKSUM_UNNECESSARY; - - /* perform proper loopback on capable devices */ - if (dev->flags & IFF_ECHO) - skb->pkt_type = PACKET_LOOPBACK; - else - skb->pkt_type = PACKET_HOST; - - skb_reset_mac_header(skb); - skb_reset_network_header(skb); - skb_reset_transport_header(skb); - } - - return true; -} - -/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ -static inline bool can_dropped_invalid_skb(struct net_device *dev, - struct sk_buff *skb) -{ - const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; - - if (skb->protocol == htons(ETH_P_CAN)) { - if (unlikely(skb->len != CAN_MTU || - cfd->len > CAN_MAX_DLEN)) - goto inval_skb; - } else if (skb->protocol == htons(ETH_P_CANFD)) { - if (unlikely(skb->len != CANFD_MTU || - cfd->len > CANFD_MAX_DLEN)) - goto inval_skb; - } else - goto inval_skb; - - if (!can_skb_headroom_valid(dev, skb)) - goto inval_skb; - - return false; - -inval_skb: - kfree_skb(skb); - dev->stats.tx_dropped++; - return true; -} - static inline bool can_is_canfd_skb(const struct sk_buff *skb) { /* the CAN specific type of skb is identified by its data length */ -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-14 14:16 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol @ 2022-05-15 19:17 ` Oliver Hartkopp 2022-05-17 1:50 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-15 19:17 UTC (permalink / raw) To: Vincent Mailhol, Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, netdev Hi Vincent, On 14.05.22 16:16, Vincent Mailhol wrote: > The functions can_dropped_invalid_skb() and can_skb_headroom_valid() > grew a lot over the years to a point which it does not make much sense > to have them defined as static inline in header files. Move those two > functions to the .c counterpart of skb.h. > > can_skb_headroom_valid() only caller being can_dropped_invalid_skb(), > the declaration is removed from the header. Only > can_dropped_invalid_skb() gets its symbol exported. I can see your point but the need for can-dev was always given for hardware specific stuff like bitrates, TDC, transceivers, whatever. As there would be more things in slcan (e.g. dev_alloc_skb() could be unified with alloc_can_skb()) - would it probably make sense to introduce a new can-skb module that could be used by all CAN virtual/software interfaces? Or some other split-up ... any idea? Best regards, Oliver > > While doing so, do a small cleanup: add brackets around the else block > in can_dropped_invalid_skb(). > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > --- > drivers/net/can/dev/skb.c | 58 ++++++++++++++++++++++++++++++++++++++ > include/linux/can/skb.h | 59 +-------------------------------------- > 2 files changed, 59 insertions(+), 58 deletions(-) > > diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c > index 61660248c69e..8b1991130de5 100644 > --- a/drivers/net/can/dev/skb.c > +++ b/drivers/net/can/dev/skb.c > @@ -252,3 +252,61 @@ struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf) > return skb; > } > EXPORT_SYMBOL_GPL(alloc_can_err_skb); > + > +/* Check for outgoing skbs that have not been created by the CAN subsystem */ > +static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) > +{ > + /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ > + if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) > + return false; > + > + /* af_packet does not apply CAN skb specific settings */ > + if (skb->ip_summed == CHECKSUM_NONE) { > + /* init headroom */ > + can_skb_prv(skb)->ifindex = dev->ifindex; > + can_skb_prv(skb)->skbcnt = 0; > + > + skb->ip_summed = CHECKSUM_UNNECESSARY; > + > + /* perform proper loopback on capable devices */ > + if (dev->flags & IFF_ECHO) > + skb->pkt_type = PACKET_LOOPBACK; > + else > + skb->pkt_type = PACKET_HOST; > + > + skb_reset_mac_header(skb); > + skb_reset_network_header(skb); > + skb_reset_transport_header(skb); > + } > + > + return true; > +} > + > +/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ > +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) > +{ > + const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; > + > + if (skb->protocol == htons(ETH_P_CAN)) { > + if (unlikely(skb->len != CAN_MTU || > + cfd->len > CAN_MAX_DLEN)) > + goto inval_skb; > + } else if (skb->protocol == htons(ETH_P_CANFD)) { > + if (unlikely(skb->len != CANFD_MTU || > + cfd->len > CANFD_MAX_DLEN)) > + goto inval_skb; > + } else { > + goto inval_skb; > + } > + > + if (!can_skb_headroom_valid(dev, skb)) > + goto inval_skb; > + > + return false; > + > +inval_skb: > + kfree_skb(skb); > + dev->stats.tx_dropped++; > + return true; > +} > +EXPORT_SYMBOL_GPL(can_dropped_invalid_skb); > diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h > index fdb22b00674a..182749e858b3 100644 > --- a/include/linux/can/skb.h > +++ b/include/linux/can/skb.h > @@ -31,6 +31,7 @@ struct sk_buff *alloc_canfd_skb(struct net_device *dev, > struct canfd_frame **cfd); > struct sk_buff *alloc_can_err_skb(struct net_device *dev, > struct can_frame **cf); > +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb); > > /* > * The struct can_skb_priv is used to transport additional information along > @@ -96,64 +97,6 @@ static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb) > return nskb; > } > > -/* Check for outgoing skbs that have not been created by the CAN subsystem */ > -static inline bool can_skb_headroom_valid(struct net_device *dev, > - struct sk_buff *skb) > -{ > - /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ > - if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) > - return false; > - > - /* af_packet does not apply CAN skb specific settings */ > - if (skb->ip_summed == CHECKSUM_NONE) { > - /* init headroom */ > - can_skb_prv(skb)->ifindex = dev->ifindex; > - can_skb_prv(skb)->skbcnt = 0; > - > - skb->ip_summed = CHECKSUM_UNNECESSARY; > - > - /* perform proper loopback on capable devices */ > - if (dev->flags & IFF_ECHO) > - skb->pkt_type = PACKET_LOOPBACK; > - else > - skb->pkt_type = PACKET_HOST; > - > - skb_reset_mac_header(skb); > - skb_reset_network_header(skb); > - skb_reset_transport_header(skb); > - } > - > - return true; > -} > - > -/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ > -static inline bool can_dropped_invalid_skb(struct net_device *dev, > - struct sk_buff *skb) > -{ > - const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; > - > - if (skb->protocol == htons(ETH_P_CAN)) { > - if (unlikely(skb->len != CAN_MTU || > - cfd->len > CAN_MAX_DLEN)) > - goto inval_skb; > - } else if (skb->protocol == htons(ETH_P_CANFD)) { > - if (unlikely(skb->len != CANFD_MTU || > - cfd->len > CANFD_MAX_DLEN)) > - goto inval_skb; > - } else > - goto inval_skb; > - > - if (!can_skb_headroom_valid(dev, skb)) > - goto inval_skb; > - > - return false; > - > -inval_skb: > - kfree_skb(skb); > - dev->stats.tx_dropped++; > - return true; > -} > - > static inline bool can_is_canfd_skb(const struct sk_buff *skb) > { > /* the CAN specific type of skb is identified by its data length */ ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-15 19:17 ` Oliver Hartkopp @ 2022-05-17 1:50 ` Vincent MAILHOL 2022-05-17 4:12 ` Max Staudt 2022-05-17 6:08 ` Marc Kleine-Budde 0 siblings, 2 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-17 1:50 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, linux-can, linux-kernel, Max Staudt, netdev Hi Oliver, On Mon. 16 May 2022 at 04:17, Oliver Hartkopp <socketcan@hartkopp.net> wrote: > Hi Vincent, > > On 14.05.22 16:16, Vincent Mailhol wrote: > > The functions can_dropped_invalid_skb() and can_skb_headroom_valid() > > grew a lot over the years to a point which it does not make much sense > > to have them defined as static inline in header files. Move those two > > functions to the .c counterpart of skb.h. > > > > can_skb_headroom_valid() only caller being can_dropped_invalid_skb(), > > the declaration is removed from the header. Only > > can_dropped_invalid_skb() gets its symbol exported. > > I can see your point but the need for can-dev was always given for > hardware specific stuff like bitrates, TDC, transceivers, whatever. I also see your point :) Actually, I raised the exact same idea in a previous message: https://lore.kernel.org/linux-can/CAMZ6RqLU-Wg0Cau3cM=QsU-t-7Lyzmo1nJ_VAA4Mbw3u0jnNtw@mail.gmail.com/ But you were not in CC and it seems that there is a lot of congestion recently on the mailing list so I wouldn’t be surprised if you tell me you did not receive it. > As there would be more things in slcan (e.g. dev_alloc_skb() could be > unified with alloc_can_skb()) And also the can_{put,get}_echo_skb() I guess. > would it probably make sense to > introduce a new can-skb module that could be used by all CAN > virtual/software interfaces? > > Or some other split-up ... any idea? My concern is: what would be the merrit? If we do not split, the users of slcan and v(x)can would have to load the can-dev module which will be slightly bloated for their use, but is this really an issue? I do not see how this can become a performance bottleneck, so what is the problem? I could also argue that most of the devices do not depend on rx-offload.o. So should we also split this one out of can-dev on the same basis and add another module dependency? The benefit (not having to load a bloated module for three drivers) does not outweigh the added complexity: all hardware modules will have one additional modprobe dependency on the tiny can-skb module. But as said above, I am not fully opposed to the split, I am just strongly divided. If we go for the split, creating a can-skb module is the natural and only option I see. If the above argument does not convince you, I will send a v3 with that split. Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 1:50 ` Vincent MAILHOL @ 2022-05-17 4:12 ` Max Staudt 2022-05-17 6:08 ` Marc Kleine-Budde 1 sibling, 0 replies; 119+ messages in thread From: Max Staudt @ 2022-05-17 4:12 UTC (permalink / raw) To: Vincent MAILHOL Cc: Oliver Hartkopp, Marc Kleine-Budde, linux-can, linux-kernel, netdev On Tue, 17 May 2022 10:50:16 +0900 Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > My concern is: what would be the merrit? If we do not split, the users > of slcan and v(x)can would have to load the can-dev module which will > be slightly bloated for their use, but is this really an issue? I do > not see how this can become a performance bottleneck, so what is the > problem? > I could also argue that most of the devices do not depend on > rx-offload.o. So should we also split this one out of can-dev on the > same basis and add another module dependency? > The benefit (not having to load a bloated module for three drivers) > does not outweigh the added complexity: all hardware modules will have > one additional modprobe dependency on the tiny can-skb module. > > But as said above, I am not fully opposed to the split, I am just > strongly divided. If we go for the split, creating a can-skb module is > the natural and only option I see. > If the above argument does not convince you, I will send a v3 with > that split. I originally replied to PATCHv2 in agreement with what Vincent said in the first part - I agree that simply moving this code into can-dev and making v(x)can/slcan depend on it is the straightforward thing to do. Having yet another kernel module for a tiny bit of code adds more unnecessary complexity IMHO. And from a user perspective, it seems fairly natural to have can-dev loaded any time some can0, slcan0, vcan0, etc. pops up. Finally, embedded applications that are truly short on memory are likely using a "real" CAN adapter, and hence already have can-dev loaded anyway. I think it's okay to just move it to can-dev and call it a day :) Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 1:50 ` Vincent MAILHOL 2022-05-17 4:12 ` Max Staudt @ 2022-05-17 6:08 ` Marc Kleine-Budde 2022-05-17 7:04 ` Vincent MAILHOL 1 sibling, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-17 6:08 UTC (permalink / raw) To: Vincent MAILHOL Cc: Oliver Hartkopp, linux-can, linux-kernel, Max Staudt, netdev [-- Attachment #1: Type: text/plain, Size: 1755 bytes --] On 17.05.2022 10:50:16, Vincent MAILHOL wrote: > > would it probably make sense to > > introduce a new can-skb module that could be used by all CAN > > virtual/software interfaces? > > > > Or some other split-up ... any idea? > > My concern is: what would be the merrit? If we do not split, the users > of slcan and v(x)can would have to load the can-dev module which will > be slightly bloated for their use, but is this really an issue? If you use modprobe all required modules are loaded automatically. > I do > not see how this can become a performance bottleneck, so what is the > problem? > I could also argue that most of the devices do not depend on > rx-offload.o. So should we also split this one out of can-dev on the > same basis and add another module dependency? We can add a non user visible Kconfig symbol for rx-offload and let the drivers that need it do a "select" on it. If selected the rx-offload would be compiled into to can-dev module. > The benefit (not having to load a bloated module for three drivers) > does not outweigh the added complexity: all hardware modules will have > one additional modprobe dependency on the tiny can-skb module. > > But as said above, I am not fully opposed to the split, I am just > strongly divided. If we go for the split, creating a can-skb module is > the natural and only option I see. > If the above argument does not convince you, I will send a v3 with that split. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 6:08 ` Marc Kleine-Budde @ 2022-05-17 7:04 ` Vincent MAILHOL 2022-05-17 10:45 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-17 7:04 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Oliver Hartkopp, linux-can, linux-kernel, Max Staudt, netdev On Tue. 17 May 2022 at 15:08, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 17.05.2022 10:50:16, Vincent MAILHOL wrote: > > > would it probably make sense to > > > introduce a new can-skb module that could be used by all CAN > > > virtual/software interfaces? > > > > > > Or some other split-up ... any idea? > > > > My concern is: what would be the merrit? If we do not split, the users > > of slcan and v(x)can would have to load the can-dev module which will > > be slightly bloated for their use, but is this really an issue? > > If you use modprobe all required modules are loaded automatically. Yes, this, now I know. In the past, when I started developing etas_es58x as an out of tree module (which I inserted using insmod), it took me a little time to figure out the dependencies tree and which module I actually had to modprobe separately. > > I do > > not see how this can become a performance bottleneck, so what is the > > problem? > > I could also argue that most of the devices do not depend on > > rx-offload.o. So should we also split this one out of can-dev on the > > same basis and add another module dependency? > > We can add a non user visible Kconfig symbol for rx-offload and let the > drivers that need it do a "select" on it. If selected the rx-offload > would be compiled into to can-dev module. Yes, and this remark also applies to can-skb I think. So slcan, v(x)can and can-dev will select can-skb, and some of the hardware drivers (still have to figure out the list) will select can-rx-offload (other dependencies will stay as it is today). I think that splitting the current can-dev into can-skb + can-dev + can-rx-offload is enough. Please let me know if you see a need for more. > > The benefit (not having to load a bloated module for three drivers) > > does not outweigh the added complexity: all hardware modules will have > > one additional modprobe dependency on the tiny can-skb module. > > > > But as said above, I am not fully opposed to the split, I am just > > strongly divided. If we go for the split, creating a can-skb module is > > the natural and only option I see. > > If the above argument does not convince you, I will send a v3 with that split. If both you and Oliver prefer the split, then split it would be! Because this topic is related to Kbuild, there is actually one thing which bothered me but which I never asked: why are all the CAN devices under "Networking support" and not "Device Drivers" in menuconfig like everything else? Would it make sense to move our devices under the "Device Drivers" section? I can do it while working on the v3. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 7:04 ` Vincent MAILHOL @ 2022-05-17 10:45 ` Marc Kleine-Budde 2022-05-17 11:51 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-17 10:45 UTC (permalink / raw) To: Vincent MAILHOL Cc: Oliver Hartkopp, linux-can, linux-kernel, Max Staudt, netdev [-- Attachment #1: Type: text/plain, Size: 748 bytes --] On 17.05.2022 16:04:53, Vincent MAILHOL wrote: > So slcan, v(x)can and can-dev will select can-skb, and some of the > hardware drivers (still have to figure out the list) will select > can-rx-offload (other dependencies will stay as it is today). For rx-offload that's flexcan, ti_hecc and mcp251xfd > I think that splitting the current can-dev into can-skb + can-dev + > can-rx-offload is enough. Please let me know if you see a need for > more. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 10:45 ` Marc Kleine-Budde @ 2022-05-17 11:51 ` Oliver Hartkopp 2022-05-17 12:14 ` Max Staudt 0 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-17 11:51 UTC (permalink / raw) To: Marc Kleine-Budde, Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, netdev On 17.05.22 12:45, Marc Kleine-Budde wrote: > On 17.05.2022 16:04:53, Vincent MAILHOL wrote: >> So slcan, v(x)can and can-dev will select can-skb, and some of the >> hardware drivers (still have to figure out the list) will select >> can-rx-offload (other dependencies will stay as it is today). > > For rx-offload that's flexcan, ti_hecc and mcp251xfd > >> I think that splitting the current can-dev into can-skb + can-dev + >> can-rx-offload is enough. Please let me know if you see a need for >> more. After looking through drivers/net/can/Kconfig I would probably phrase it like this: Select CAN devices (hw/sw) -> we compile a can_dev module. E.g. to handle the skb stuff for vcan's. Select hardware CAN devices -> we compile the netlink stuff into can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled into can_dev too. In the latter case: The selection of flexcan, ti_hecc and mcp251xfd automatically selects CAN_RX_OFFLOAD which is then also compiled into can_dev. Would that fit in terms of complexity? Best, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 11:51 ` Oliver Hartkopp @ 2022-05-17 12:14 ` Max Staudt 2022-05-17 12:21 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-05-17 12:14 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, Vincent MAILHOL, linux-can, linux-kernel, netdev On Tue, 17 May 2022 13:51:57 +0200 Oliver Hartkopp <socketcan@hartkopp.net> wrote: > After looking through drivers/net/can/Kconfig I would probably phrase > it like this: > > Select CAN devices (hw/sw) -> we compile a can_dev module. E.g. to > handle the skb stuff for vcan's. > > Select hardware CAN devices -> we compile the netlink stuff into > can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled into > can_dev too. > > In the latter case: The selection of flexcan, ti_hecc and mcp251xfd > automatically selects CAN_RX_OFFLOAD which is then also compiled into > can_dev. > > Would that fit in terms of complexity? IMHO these should always be compiled into can-dev. Out of tree drivers are fairly common here, and having to determine which kind of can-dev (stripped or not) the user has on their system is a nightmare waiting to happen. Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 12:14 ` Max Staudt @ 2022-05-17 12:21 ` Marc Kleine-Budde 2022-05-17 12:39 ` Max Staudt 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-17 12:21 UTC (permalink / raw) To: Max Staudt Cc: Oliver Hartkopp, Vincent MAILHOL, linux-can, linux-kernel, netdev [-- Attachment #1: Type: text/plain, Size: 1214 bytes --] On 17.05.2022 14:14:04, Max Staudt wrote: > > After looking through drivers/net/can/Kconfig I would probably phrase > > it like this: > > > > Select CAN devices (hw/sw) -> we compile a can_dev module. E.g. to > > handle the skb stuff for vcan's. > > > > Select hardware CAN devices -> we compile the netlink stuff into > > can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled into > > can_dev too. > > > > In the latter case: The selection of flexcan, ti_hecc and mcp251xfd > > automatically selects CAN_RX_OFFLOAD which is then also compiled into > > can_dev. > > > > Would that fit in terms of complexity? > > IMHO these should always be compiled into can-dev. Out of tree drivers > are fairly common here, and having to determine which kind of can-dev > (stripped or not) the user has on their system is a nightmare waiting to > happen. I personally don't care about out-of-tree drivers. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 12:21 ` Marc Kleine-Budde @ 2022-05-17 12:39 ` Max Staudt 2022-05-17 13:35 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-05-17 12:39 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Oliver Hartkopp, Vincent MAILHOL, linux-can, linux-kernel, netdev On Tue, 17 May 2022 14:21:53 +0200 Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 17.05.2022 14:14:04, Max Staudt wrote: > > > After looking through drivers/net/can/Kconfig I would probably > > > phrase it like this: > > > > > > Select CAN devices (hw/sw) -> we compile a can_dev module. E.g. > > > to handle the skb stuff for vcan's. > > > > > > Select hardware CAN devices -> we compile the netlink stuff into > > > can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled > > > into can_dev too. > > > > > > In the latter case: The selection of flexcan, ti_hecc and > > > mcp251xfd automatically selects CAN_RX_OFFLOAD which is then also > > > compiled into can_dev. > > > > > > Would that fit in terms of complexity? > > > > IMHO these should always be compiled into can-dev. Out of tree > > drivers are fairly common here, and having to determine which kind > > of can-dev (stripped or not) the user has on their system is a > > nightmare waiting to happen. > > I personally don't care about out-of-tree drivers. I know that this is the official stance in the kernel. But out-of-tree drivers do happen on a regular basis, even when developing with the aim of upstreaming. And if a developer builds a minimal kernel to host a CAN driver, without building in-tree hardware CAN drivers, then can-dev will be there but behave differently from can-dev in a full distro. Leading to heisenbugs and wasting time. The source of heisenbugs really are the suggested *hidden* Kconfigs. On another note, is the module accounting overhead in the kernel for two new modules with relatively little code in each, code that almost always is loaded when CAN is used, really worth it? Okay, I think I'm out of 2 cent pieces now :) Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 12:39 ` Max Staudt @ 2022-05-17 13:35 ` Oliver Hartkopp 2022-05-17 13:43 ` Max Staudt 2022-05-18 12:03 ` Vincent MAILHOL 0 siblings, 2 replies; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-17 13:35 UTC (permalink / raw) To: Max Staudt, Marc Kleine-Budde Cc: Vincent MAILHOL, linux-can, linux-kernel, netdev On 5/17/22 14:39, Max Staudt wrote: > On Tue, 17 May 2022 14:21:53 +0200 > Marc Kleine-Budde <mkl@pengutronix.de> wrote: > >> On 17.05.2022 14:14:04, Max Staudt wrote: >>>> After looking through drivers/net/can/Kconfig I would probably >>>> phrase it like this: >>>> >>>> Select CAN devices (hw/sw) -> we compile a can_dev module. E.g. >>>> to handle the skb stuff for vcan's. >>>> >>>> Select hardware CAN devices -> we compile the netlink stuff into >>>> can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled >>>> into can_dev too. >>>> >>>> In the latter case: The selection of flexcan, ti_hecc and >>>> mcp251xfd automatically selects CAN_RX_OFFLOAD which is then also >>>> compiled into can_dev. >>>> >>>> Would that fit in terms of complexity? >>> >>> IMHO these should always be compiled into can-dev. Out of tree >>> drivers are fairly common here, and having to determine which kind >>> of can-dev (stripped or not) the user has on their system is a >>> nightmare waiting to happen. >> >> I personally don't care about out-of-tree drivers. > > I know that this is the official stance in the kernel. > > But out-of-tree drivers do happen on a regular basis, even when > developing with the aim of upstreaming. And if a developer builds a > minimal kernel to host a CAN driver, without building in-tree hardware > CAN drivers, then can-dev will be there but behave differently from > can-dev in a full distro. Leading to heisenbugs and wasting time. The > source of heisenbugs really are the suggested *hidden* Kconfigs. > > > On another note, is the module accounting overhead in the kernel for > two new modules with relatively little code in each, code that almost > always is loaded when CAN is used, really worth it? Oh, I didn't want to introduce two new kernel modules but to have can_dev in different 'feature levels'. I would assume a distro kernel to have everything enabled with a full featured can_dev - which is likely the base for out-of-tree drivers too. But e.g. the people that are running Linux instances in a cloud only using vcan and vxcan would not need to carry the entire infrastructure of CAN hardware support and rx-offload. Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 13:35 ` Oliver Hartkopp @ 2022-05-17 13:43 ` Max Staudt 2022-05-17 14:23 ` Marc Kleine-Budde 2022-05-17 14:35 ` Oliver Hartkopp 2022-05-18 12:03 ` Vincent MAILHOL 1 sibling, 2 replies; 119+ messages in thread From: Max Staudt @ 2022-05-17 13:43 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, Vincent MAILHOL, linux-can, linux-kernel, netdev On Tue, 17 May 2022 15:35:03 +0200 Oliver Hartkopp <socketcan@hartkopp.net> wrote: > Oh, I didn't want to introduce two new kernel modules but to have > can_dev in different 'feature levels'. Which I agree is a nice idea, as long as heisenbugs can be avoided :) (as for the separate modules vs. feature levels of can-dev - sorry, my two paragraphs were each referring to a different idea. I mixed them into one single email...) Maybe the can-skb and rx-offload parts could be a *visible* sub-option of can-dev in Kconfig, which is normally optional, but immediately force-selected once a CAN HW driver is selected? > But e.g. the people that are running Linux instances in a cloud only > using vcan and vxcan would not need to carry the entire > infrastructure of CAN hardware support and rx-offload. Out of curiosity, do you have an example use case for this vcan cloud setup? I can't dream one up... Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 13:43 ` Max Staudt @ 2022-05-17 14:23 ` Marc Kleine-Budde 2022-05-17 14:35 ` Oliver Hartkopp 1 sibling, 0 replies; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-17 14:23 UTC (permalink / raw) To: Max Staudt Cc: Oliver Hartkopp, Vincent MAILHOL, linux-can, linux-kernel, netdev [-- Attachment #1: Type: text/plain, Size: 1227 bytes --] On 17.05.2022 15:43:01, Max Staudt wrote: > > Oh, I didn't want to introduce two new kernel modules but to have > > can_dev in different 'feature levels'. > > Which I agree is a nice idea, as long as heisenbugs can be avoided :) > > (as for the separate modules vs. feature levels of can-dev - sorry, my > two paragraphs were each referring to a different idea. I mixed them > into one single email...) > > Maybe the can-skb and rx-offload parts could be a *visible* sub-option > of can-dev in Kconfig, which is normally optional, but immediately > force-selected once a CAN HW driver is selected? In the ctucanfd driver we made the base driver "invisible" if COMPILE_TEST is not selected: | config CAN_CTUCANFD | tristate "CTU CAN-FD IP core" if COMPILE_TEST | | config CAN_CTUCANFD_PCI | tristate "CTU CAN-FD IP core PCI/PCIe driver" | depends on PCI | select CAN_CTUCANFD 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 13:43 ` Max Staudt 2022-05-17 14:23 ` Marc Kleine-Budde @ 2022-05-17 14:35 ` Oliver Hartkopp 2022-05-17 15:38 ` Max Staudt 1 sibling, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-17 14:35 UTC (permalink / raw) To: Max Staudt Cc: Marc Kleine-Budde, Vincent MAILHOL, linux-can, linux-kernel, netdev On 17.05.22 15:43, Max Staudt wrote: > On Tue, 17 May 2022 15:35:03 +0200 > Oliver Hartkopp <socketcan@hartkopp.net> wrote: > >> Oh, I didn't want to introduce two new kernel modules but to have >> can_dev in different 'feature levels'. > > Which I agree is a nice idea, as long as heisenbugs can be avoided :) > > (as for the separate modules vs. feature levels of can-dev - sorry, my > two paragraphs were each referring to a different idea. I mixed them > into one single email...) > > > Maybe the can-skb and rx-offload parts could be a *visible* sub-option > of can-dev in Kconfig, which is normally optional, but immediately > force-selected once a CAN HW driver is selected? I think it should be even more simple. When you enter the current Kconfig page of "CAN Device Drivers" every selection of vcan/vxcan/slcan should directly select CAN_DEV_SW. The rest could stay the same, e.g. selecting CAN_DEV "Platform CAN drivers with Netlink support" which then enables CAN_CALC_BITTIMING and CAN_LEDS to be selectable. Which also makes sure the old .config files still apply. And finally the selection of flexcan, ti_hecc and mcp251xfd automatically selects CAN_DEV_RX_OFFLOAD. Then only some more Makefile magic has to be done to build can-dev.ko accordingly. Best regards, Oliver > > >> But e.g. the people that are running Linux instances in a cloud only >> using vcan and vxcan would not need to carry the entire >> infrastructure of CAN hardware support and rx-offload. > > Out of curiosity, do you have an example use case for this vcan cloud > setup? I can't dream one up... > > > > Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 14:35 ` Oliver Hartkopp @ 2022-05-17 15:38 ` Max Staudt 2022-05-17 15:50 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-05-17 15:38 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, Vincent MAILHOL, linux-can, linux-kernel, netdev On Tue, 17 May 2022 16:35:05 +0200 Oliver Hartkopp <socketcan@hartkopp.net> wrote: > I think it should be even more simple. > > When you enter the current Kconfig page of "CAN Device Drivers" every > selection of vcan/vxcan/slcan should directly select CAN_DEV_SW. I'm a bit lost - what would CAN_DEV_SW do? If it enables can_dropped_invalid_skb(), then the HW drivers would also need to depend on CAN_DEV_SW directly or indirectly, or am I missing something? Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 15:38 ` Max Staudt @ 2022-05-17 15:50 ` Oliver Hartkopp 2022-05-17 17:52 ` Max Staudt 0 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-17 15:50 UTC (permalink / raw) To: Max Staudt Cc: Marc Kleine-Budde, Vincent MAILHOL, linux-can, linux-kernel, netdev On 17.05.22 17:38, Max Staudt wrote: > On Tue, 17 May 2022 16:35:05 +0200 > Oliver Hartkopp <socketcan@hartkopp.net> wrote: > >> I think it should be even more simple. >> >> When you enter the current Kconfig page of "CAN Device Drivers" every >> selection of vcan/vxcan/slcan should directly select CAN_DEV_SW. > > I'm a bit lost - what would CAN_DEV_SW do? It should be just *one* enabler of building can-dev-ko > If it enables can_dropped_invalid_skb(), then the HW drivers would also > need to depend on CAN_DEV_SW directly or indirectly, or am I missing > something? And CAN_DEV is another enabler that would build the skb stuff from CAN_DEV_SW too (but also the netlink stuff). That's what I meant with "some Makefile magic" which is then building the can-dev.ko with the required features depending on CAN_DEV_SW, CAN_DEV, CAN_DEV_RX_OFFLOAD, CAN_CALC_BITTIMING, etc Best, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 15:50 ` Oliver Hartkopp @ 2022-05-17 17:52 ` Max Staudt 0 siblings, 0 replies; 119+ messages in thread From: Max Staudt @ 2022-05-17 17:52 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, Vincent MAILHOL, linux-can, linux-kernel, netdev On Tue, 17 May 2022 17:50:03 +0200 Oliver Hartkopp <socketcan@hartkopp.net> wrote: > On 17.05.22 17:38, Max Staudt wrote: > > I'm a bit lost - what would CAN_DEV_SW do? > > It should be just *one* enabler of building can-dev-ko > > > If it enables can_dropped_invalid_skb(), then the HW drivers would > > also need to depend on CAN_DEV_SW directly or indirectly, or am I > > missing something? > > And CAN_DEV is another enabler that would build the skb stuff from > CAN_DEV_SW too (but also the netlink stuff). > > That's what I meant with "some Makefile magic" which is then building > the can-dev.ko with the required features depending on CAN_DEV_SW, > CAN_DEV, CAN_DEV_RX_OFFLOAD, CAN_CALC_BITTIMING, etc Ah, I see! Sounds good :) Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-17 13:35 ` Oliver Hartkopp 2022-05-17 13:43 ` Max Staudt @ 2022-05-18 12:03 ` Vincent MAILHOL 2022-05-18 12:12 ` Device Drivers: (was: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c) Marc Kleine-Budde 2022-05-18 13:10 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Oliver Hartkopp 1 sibling, 2 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-18 12:03 UTC (permalink / raw) To: Oliver Hartkopp Cc: Max Staudt, Marc Kleine-Budde, linux-can, linux-kernel, netdev I didn't think this would trigger such a passionate discussion! On Tue. 17 mai 2022 at 22:35, Oliver Hartkopp <socketcan@hartkopp.net> wrote: > On 5/17/22 14:39, Max Staudt wrote: > > On Tue, 17 May 2022 14:21:53 +0200 > > Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > > >> On 17.05.2022 14:14:04, Max Staudt wrote: > >>>> After looking through drivers/net/can/Kconfig I would probably > >>>> phrase it like this: > >>>> > >>>> Select CAN devices (hw/sw) -> we compile a can_dev module. E.g. > >>>> to handle the skb stuff for vcan's. > >>>> > >>>> Select hardware CAN devices -> we compile the netlink stuff into > >>>> can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled > >>>> into can_dev too. > >>>> > >>>> In the latter case: The selection of flexcan, ti_hecc and > >>>> mcp251xfd automatically selects CAN_RX_OFFLOAD which is then also > >>>> compiled into can_dev. > >>>> > >>>> Would that fit in terms of complexity? > >>> > >>> IMHO these should always be compiled into can-dev. Out of tree > >>> drivers are fairly common here, and having to determine which kind > >>> of can-dev (stripped or not) the user has on their system is a > >>> nightmare waiting to happen. > >> > >> I personally don't care about out-of-tree drivers. > > > > I know that this is the official stance in the kernel. > > > > But out-of-tree drivers do happen on a regular basis, even when > > developing with the aim of upstreaming. And if a developer builds a > > minimal kernel to host a CAN driver, without building in-tree hardware > > CAN drivers, then can-dev will be there but behave differently from > > can-dev in a full distro. Leading to heisenbugs and wasting time. The > > source of heisenbugs really are the suggested *hidden* Kconfigs. > > > > > > On another note, is the module accounting overhead in the kernel for > > two new modules with relatively little code in each, code that almost > > always is loaded when CAN is used, really worth it? > > Oh, I didn't want to introduce two new kernel modules but to have > can_dev in different 'feature levels'. > > I would assume a distro kernel to have everything enabled with a full > featured can_dev - which is likely the base for out-of-tree drivers too. > > But e.g. the people that are running Linux instances in a cloud only > using vcan and vxcan would not need to carry the entire infrastructure > of CAN hardware support and rx-offload. Are there really some people running custom builds of the Linux kernel in a cloud environment? The benefit of saving a few kilobytes by not having to carry the entire CAN hardware infrastructure is blown away by the cost of having to maintain a custom build. I perfectly follow the idea to split rx-offload. Integrators building some custom firmware for an embedded device might want to strip out any unneeded piece. But I am not convinced by this same argument when applied to v(x)can. A two level split (with or without rx-offload) is what makes the most sense to me. Regardless, having the three level split is not harmful. And because there seems to be a consensus on that, I am fine to continue in this direction. On a different topic, why are all the CAN devices under "Networking support" and not "Device Drivers" in menuconfig like everything else? Would it make sense to move our devices under the "Device Drivers" section? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Device Drivers: (was: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c) 2022-05-18 12:03 ` Vincent MAILHOL @ 2022-05-18 12:12 ` Marc Kleine-Budde 2022-05-18 12:45 ` Oliver Hartkopp 2022-05-18 13:10 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Oliver Hartkopp 1 sibling, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-18 12:12 UTC (permalink / raw) To: Vincent MAILHOL Cc: Oliver Hartkopp, Max Staudt, linux-can, linux-kernel, netdev [-- Attachment #1: Type: text/plain, Size: 560 bytes --] On 18.05.2022 21:03:37, Vincent MAILHOL wrote: > On a different topic, why are all the CAN devices > under "Networking support" and not "Device Drivers" in menuconfig > like everything else? Would it make sense to move our devices > under the "Device Drivers" section? ACK 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: Device Drivers: (was: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c) 2022-05-18 12:12 ` Device Drivers: (was: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c) Marc Kleine-Budde @ 2022-05-18 12:45 ` Oliver Hartkopp 0 siblings, 0 replies; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-18 12:45 UTC (permalink / raw) To: Marc Kleine-Budde, Vincent MAILHOL Cc: Max Staudt, linux-can, linux-kernel, netdev On 18.05.22 14:12, Marc Kleine-Budde wrote: > On 18.05.2022 21:03:37, Vincent MAILHOL wrote: >> On a different topic, why are all the CAN devices >> under "Networking support" and not "Device Drivers" in menuconfig >> like everything else? Would it make sense to move our devices >> under the "Device Drivers" section? > > ACK > Bluetooth did it that way too. But I feel the same. When we clean up the CAN drivers moving the CAN driver selection to drivers/net/Kconfig would make sense. ACK Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 12:03 ` Vincent MAILHOL 2022-05-18 12:12 ` Device Drivers: (was: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c) Marc Kleine-Budde @ 2022-05-18 13:10 ` Oliver Hartkopp 2022-05-18 13:28 ` Marc Kleine-Budde 1 sibling, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-18 13:10 UTC (permalink / raw) To: Vincent MAILHOL Cc: Max Staudt, Marc Kleine-Budde, linux-can, linux-kernel, netdev On 18.05.22 14:03, Vincent MAILHOL wrote: > I didn't think this would trigger such a passionate discussion! :-D Maybe your change was the drop that let the bucket run over ;-) >> But e.g. the people that are running Linux instances in a cloud only >> using vcan and vxcan would not need to carry the entire infrastructure >> of CAN hardware support and rx-offload. > > Are there really some people running custom builds of the Linux kernel > in a cloud environment? The benefit of saving a few kilobytes by not > having to carry the entire CAN hardware infrastructure is blown away > by the cost of having to maintain a custom build. When looking to the current Kconfig and Makefile content in drivers/net/can(/dev) there is also some CONFIG_CAN_LEDS which "depends on BROKEN" and builds a leds.o from a non existing leds.c ?!? Oh leds.c is in drivers/net/can/leds.c but not in drivers/net/can/dev/leds.c where it could build ... ? So what I would suggest is that we always build a can-dev.ko when a CAN driver is needed. Then we have different options that may be built-in: 1. netlink hw config interface 2. bitrate calculation 3. rx-offload 4. leds E.g. having the netlink interface without bitrate calculation does not make sense to me too. > I perfectly follow the idea to split rx-offload. Integrators building > some custom firmware for an embedded device might want to strip out > any unneeded piece. But I am not convinced by this same argument when > applied to v(x)can. It does. I've seen CAN setups (really more than one or two!) in VMs and container environments that are fed by Ethernet tunnels - sometimes also in embedded devices. > A two level split (with or without rx-offload) is what makes the most > sense to me. > > Regardless, having the three level split is not harmful. And because > there seems to be a consensus on that, I am fine to continue in this > direction. Thanks! Should we remove the extra option for the bitrate calculation then? And what about the LEDS support depending on BROKEN? That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as broken") from Uwe as it seems there were some changes in 2018. Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 13:10 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Oliver Hartkopp @ 2022-05-18 13:28 ` Marc Kleine-Budde 2022-05-18 14:07 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-18 13:28 UTC (permalink / raw) To: Oliver Hartkopp Cc: Vincent MAILHOL, Max Staudt, linux-can, linux-kernel, netdev [-- Attachment #1: Type: text/plain, Size: 2849 bytes --] On 18.05.2022 15:10:44, Oliver Hartkopp wrote: > On 18.05.22 14:03, Vincent MAILHOL wrote: > > I didn't think this would trigger such a passionate discussion! > > :-D > > Maybe your change was the drop that let the bucket run over ;-) It's so trivial that everybody feels the urge to say something. :D > > > But e.g. the people that are running Linux instances in a cloud only > > > using vcan and vxcan would not need to carry the entire infrastructure > > > of CAN hardware support and rx-offload. > > > > Are there really some people running custom builds of the Linux kernel > > in a cloud environment? The benefit of saving a few kilobytes by not > > having to carry the entire CAN hardware infrastructure is blown away > > by the cost of having to maintain a custom build. > > When looking to the current Kconfig and Makefile content in > drivers/net/can(/dev) there is also some CONFIG_CAN_LEDS which "depends on > BROKEN" and builds a leds.o from a non existing leds.c ?!? > > Oh leds.c is in drivers/net/can/leds.c but not in drivers/net/can/dev/leds.c > where it could build ... ? > > So what I would suggest is that we always build a can-dev.ko when a CAN > driver is needed. > > Then we have different options that may be built-in: > > 1. netlink hw config interface > 2. bitrate calculation > 3. rx-offload > 4. leds > > E.g. having the netlink interface without bitrate calculation does not make > sense to me too. ACK > > I perfectly follow the idea to split rx-offload. Integrators building > > some custom firmware for an embedded device might want to strip out > > any unneeded piece. But I am not convinced by this same argument when > > applied to v(x)can. > > It does. I've seen CAN setups (really more than one or two!) in VMs and > container environments that are fed by Ethernet tunnels - sometimes also in > embedded devices. > > > A two level split (with or without rx-offload) is what makes the most > > sense to me. > > > > Regardless, having the three level split is not harmful. And because > > there seems to be a consensus on that, I am fine to continue in this > > direction. > > Thanks! > > Should we remove the extra option for the bitrate calculation then? +1 > And what about the LEDS support depending on BROKEN? > That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as > broken") from Uwe as it seems there were some changes in 2018. There's a proper generic LED trigger now for network devices. So remove LED triggers, 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 13:28 ` Marc Kleine-Budde @ 2022-05-18 14:07 ` Vincent MAILHOL 2022-05-18 14:33 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-18 14:07 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Oliver Hartkopp, Max Staudt, linux-can, linux-kernel, netdev On Wed. 18 May 2022 à 22:32, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 18.05.2022 15:10:44, Oliver Hartkopp wrote: > > On 18.05.22 14:03, Vincent MAILHOL wrote: > > > I didn't think this would trigger such a passionate discussion! > > > > :-D > > > > Maybe your change was the drop that let the bucket run over ;-) > > It's so trivial that everybody feels the urge to say something. :D > > > > > But e.g. the people that are running Linux instances in a cloud only > > > > using vcan and vxcan would not need to carry the entire infrastructure > > > > of CAN hardware support and rx-offload. > > > > > > Are there really some people running custom builds of the Linux kernel > > > in a cloud environment? The benefit of saving a few kilobytes by not > > > having to carry the entire CAN hardware infrastructure is blown away > > > by the cost of having to maintain a custom build. > > > > When looking to the current Kconfig and Makefile content in > > drivers/net/can(/dev) there is also some CONFIG_CAN_LEDS which "depends on > > BROKEN" and builds a leds.o from a non existing leds.c ?!? > > > > Oh leds.c is in drivers/net/can/leds.c but not in drivers/net/can/dev/leds.c > > where it could build ... ? > > > > So what I would suggest is that we always build a can-dev.ko when a CAN > > driver is needed. > > > > Then we have different options that may be built-in: > > > > 1. netlink hw config interface > > 2. bitrate calculation > > 3. rx-offload > > 4. leds > > > > E.g. having the netlink interface without bitrate calculation does not make > > sense to me too. > > ACK > > > > I perfectly follow the idea to split rx-offload. Integrators building > > > some custom firmware for an embedded device might want to strip out > > > any unneeded piece. But I am not convinced by this same argument when > > > applied to v(x)can. > > > > It does. I've seen CAN setups (really more than one or two!) in VMs and > > container environments that are fed by Ethernet tunnels - sometimes also in > > embedded devices. Are those VM running custom builds of the kernel in which all the CAN hardware devices have been removed? Also, isn't it hard to keep those up to date with all the kernel security patches? > > > A two level split (with or without rx-offload) is what makes the most > > > sense to me. > > > > > > Regardless, having the three level split is not harmful. And because > > > there seems to be a consensus on that, I am fine to continue in this > > > direction. > > > > Thanks! > > > > Should we remove the extra option for the bitrate calculation then? > > +1 I can imagine people wanting to ship a product with the bitrate calculation removed. For example, an infotainment unit designed for one specific vehicle platform (i.e. baudrate is fixed). In that case, the integrator might decide to remove bittiming calculation and hardcode all hand calculated bittiming parameters instead. So that one, I prefer to keep it. I just didn't mention it in my previous message because it was already splitted out. > > And what about the LEDS support depending on BROKEN? > > That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as > > broken") from Uwe as it seems there were some changes in 2018. > > There's a proper generic LED trigger now for network devices. So remove > LED triggers, too. Yes, the broken LED topic also popped-up last year: https://lore.kernel.org/linux-can/20210906143057.zrpor5fkh67uqwi2@pengutronix.de/ I am OK to add one patch to the series for LED removal. Just some heads-up: I will take my time, it will definitely not be ready for the v5.19 merge window. And I also expect that there will be at least one more round of discussion. While I am at it, anything else to add to the wish list before I start to working it? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 14:07 ` Vincent MAILHOL @ 2022-05-18 14:33 ` Oliver Hartkopp 2022-05-18 14:36 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-18 14:33 UTC (permalink / raw) To: Vincent MAILHOL, Marc Kleine-Budde Cc: Max Staudt, linux-can, linux-kernel, netdev On 18.05.22 16:07, Vincent MAILHOL wrote: >>> It does. I've seen CAN setups (really more than one or two!) in VMs and >>> container environments that are fed by Ethernet tunnels - sometimes also in >>> embedded devices. > > Are those VM running custom builds of the kernel in which all the CAN > hardware devices have been removed? Also, isn't it hard to keep those > up to date with all the kernel security patches? AFAIK all kind of BSPs create custom configured kernels. And to remove attack surfaces the idea is to minimize the code size. That's not only to save some flash space. >>>> A two level split (with or without rx-offload) is what makes the most >>>> sense to me. >>>> >>>> Regardless, having the three level split is not harmful. And because >>>> there seems to be a consensus on that, I am fine to continue in this >>>> direction. >>> >>> Thanks! >>> >>> Should we remove the extra option for the bitrate calculation then? >> >> +1 > > I can imagine people wanting to ship a product with the bitrate > calculation removed. For example, an infotainment unit designed for > one specific vehicle platform (i.e. baudrate is fixed). In that case, > the integrator might decide to remove bittiming calculation and > hardcode all hand calculated bittiming parameters instead. > > So that one, I prefer to keep it. I just didn't mention it in my > previous message because it was already splitted out. Ok. Interesting that we have such different expectations. >>> And what about the LEDS support depending on BROKEN? >>> That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as >>> broken") from Uwe as it seems there were some changes in 2018. >> >> There's a proper generic LED trigger now for network devices. So remove >> LED triggers, too. > > Yes, the broken LED topic also popped-up last year: > > https://lore.kernel.org/linux-can/20210906143057.zrpor5fkh67uqwi2@pengutronix.de/ > I am OK to add one patch to the series for LED removal. Hm. We have several drivers that support LED triggers: $ git grep led.h at91_can.c:#include <linux/can/led.h> c_can/c_can_main.c:#include <linux/can/led.h> ctucanfd/ctucanfd_base.c:#include <linux/can/led.h> dev/dev.c:#include <linux/can/led.h> flexcan/flexcan-core.c:#include <linux/can/led.h> led.c:#include <linux/can/led.h> m_can/m_can.h:#include <linux/can/led.h> rcar/rcar_can.c:#include <linux/can/led.h> rcar/rcar_canfd.c:#include <linux/can/led.h> sja1000/sja1000.c:#include <linux/can/led.h> spi/hi311x.c:#include <linux/can/led.h> spi/mcp251x.c:#include <linux/can/led.h> sun4i_can.c:#include <linux/can/led.h> ti_hecc.c:#include <linux/can/led.h> usb/mcba_usb.c:#include <linux/can/led.h> usb/usb_8dev.c:#include <linux/can/led.h> xilinx_can.c:#include <linux/can/led.h> And I personally like the ability to be able to fire some LEDS (either as GPIO or probably in a window manager). I would suggest to remove the Kconfig entry but not all the code inside the drivers, so that a volunteer can convert the LED support based on the existing trigger points in the drivers code later. Our would it make sense to just leave some comment at those places like: /* LED TX trigger here */ ?? > Just some > heads-up: I will take my time, it will definitely not be ready for the > v5.19 merge window. And I also expect that there will be at least one > more round of discussion. > > While I am at it, anything else to add to the wish list before I start > to working it? Not really. IMO we already share a common picture now. Thanks for picking this up! Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 14:33 ` Oliver Hartkopp @ 2022-05-18 14:36 ` Marc Kleine-Budde 2022-05-18 14:38 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-05-18 14:36 UTC (permalink / raw) To: Oliver Hartkopp Cc: Vincent MAILHOL, Max Staudt, linux-can, linux-kernel, netdev [-- Attachment #1: Type: text/plain, Size: 2137 bytes --] On 18.05.2022 16:33:58, Oliver Hartkopp wrote: > > > > And what about the LEDS support depending on BROKEN? > > > > That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as > > > > broken") from Uwe as it seems there were some changes in 2018. > > > > > > There's a proper generic LED trigger now for network devices. So remove > > > LED triggers, too. > > > > Yes, the broken LED topic also popped-up last year: > > > > https://lore.kernel.org/linux-can/20210906143057.zrpor5fkh67uqwi2@pengutronix.de/ > I am OK to add one patch to the series for LED removal. > > Hm. We have several drivers that support LED triggers: > > $ git grep led.h > at91_can.c:#include <linux/can/led.h> > c_can/c_can_main.c:#include <linux/can/led.h> > ctucanfd/ctucanfd_base.c:#include <linux/can/led.h> > dev/dev.c:#include <linux/can/led.h> > flexcan/flexcan-core.c:#include <linux/can/led.h> > led.c:#include <linux/can/led.h> > m_can/m_can.h:#include <linux/can/led.h> > rcar/rcar_can.c:#include <linux/can/led.h> > rcar/rcar_canfd.c:#include <linux/can/led.h> > sja1000/sja1000.c:#include <linux/can/led.h> > spi/hi311x.c:#include <linux/can/led.h> > spi/mcp251x.c:#include <linux/can/led.h> > sun4i_can.c:#include <linux/can/led.h> > ti_hecc.c:#include <linux/can/led.h> > usb/mcba_usb.c:#include <linux/can/led.h> > usb/usb_8dev.c:#include <linux/can/led.h> > xilinx_can.c:#include <linux/can/led.h> > > And I personally like the ability to be able to fire some LEDS (either as > GPIO or probably in a window manager). > > I would suggest to remove the Kconfig entry but not all the code inside the > drivers, so that a volunteer can convert the LED support based on the > existing trigger points in the drivers code later. The generic netdev LED trigger code doesn't need any support in the netdev driver. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 14:36 ` Marc Kleine-Budde @ 2022-05-18 14:38 ` Oliver Hartkopp 2022-05-18 14:55 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-18 14:38 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Vincent MAILHOL, Max Staudt, linux-can, linux-kernel, netdev On 18.05.22 16:36, Marc Kleine-Budde wrote: > On 18.05.2022 16:33:58, Oliver Hartkopp wrote: >> I would suggest to remove the Kconfig entry but not all the code inside the >> drivers, so that a volunteer can convert the LED support based on the >> existing trigger points in the drivers code later. > > The generic netdev LED trigger code doesn't need any support in the > netdev driver. Oh! Yes, then it could be removed. Sorry for not looking that deep into it. Best, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 14:38 ` Oliver Hartkopp @ 2022-05-18 14:55 ` Oliver Hartkopp 2022-05-18 15:38 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-05-18 14:55 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Vincent MAILHOL, Max Staudt, linux-can, linux-kernel, netdev On 18.05.22 16:38, Oliver Hartkopp wrote: > > > On 18.05.22 16:36, Marc Kleine-Budde wrote: >> On 18.05.2022 16:33:58, Oliver Hartkopp wrote: > >>> I would suggest to remove the Kconfig entry but not all the code >>> inside the >>> drivers, so that a volunteer can convert the LED support based on the >>> existing trigger points in the drivers code later. >> >> The generic netdev LED trigger code doesn't need any support in the >> netdev driver. > > Oh! Yes, then it could be removed. Sorry for not looking that deep into it. I can send a patch for this removal too. That's an easy step which might get into 5.19 then. Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 14:55 ` Oliver Hartkopp @ 2022-05-18 15:38 ` Vincent MAILHOL 2022-05-18 15:48 ` Max Staudt 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-18 15:38 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, Max Staudt, linux-can, linux-kernel, netdev On Wed. 18 May 2022 at 23:59, Oliver Hartkopp <socketcan@hartkopp.net> wrote: > On 18.05.22 16:38, Oliver Hartkopp wrote: > > On 18.05.22 16:36, Marc Kleine-Budde wrote: > >> On 18.05.2022 16:33:58, Oliver Hartkopp wrote: > > > >>> I would suggest to remove the Kconfig entry but not all the code > >>> inside the > >>> drivers, so that a volunteer can convert the LED support based on the > >>> existing trigger points in the drivers code later. > >> > >> The generic netdev LED trigger code doesn't need any support in the > >> netdev driver. > > > > Oh! Yes, then it could be removed. Sorry for not looking that deep into it. > > I can send a patch for this removal too. That's an easy step which might > get into 5.19 then. OK, go ahead. On my side, I will start to work on the other changes either next week or next next week, depending on my mood. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 15:38 ` Vincent MAILHOL @ 2022-05-18 15:48 ` Max Staudt 2022-05-18 16:01 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-05-18 15:48 UTC (permalink / raw) To: Vincent MAILHOL Cc: Oliver Hartkopp, Marc Kleine-Budde, linux-can, linux-kernel, netdev On Thu, 19 May 2022 00:38:51 +0900 Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > On Wed. 18 May 2022 at 23:59, Oliver Hartkopp > <socketcan@hartkopp.net> wrote: > > I can send a patch for this removal too. That's an easy step which > > might get into 5.19 then. > > OK, go ahead. On my side, I will start to work on the other changes > either next week or next next week, depending on my mood. Any wishes for the next version of can327/elmcan? Should I wait until your changes are in? Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c 2022-05-18 15:48 ` Max Staudt @ 2022-05-18 16:01 ` Vincent MAILHOL 0 siblings, 0 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-05-18 16:01 UTC (permalink / raw) To: Max Staudt Cc: Oliver Hartkopp, Marc Kleine-Budde, linux-can, linux-kernel, netdev On Thu. 19 May 2022 at 00:52, Max Staudt <max@enpas.org> wrote: > On Thu, 19 May 2022 00:38:51 +0900 > Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > > > On Wed. 18 May 2022 at 23:59, Oliver Hartkopp > > <socketcan@hartkopp.net> wrote: > > > I can send a patch for this removal too. That's an easy step which > > > might get into 5.19 then. > > > > OK, go ahead. On my side, I will start to work on the other changes > > either next week or next next week, depending on my mood. > > Any wishes for the next version of can327/elmcan? The only thing I guess would be to remove the check against CAN_CTRLMODE_LISTENONLY in your xmit() function. The other things, I already commented :) > Should I wait until your changes are in? I do not think you have to wait. There are no real dependencies. You might just want to add a note after the --- scissors in the patch that there is a weak dependencies on https://lore.kernel.org/linux-can/20220514141650.1109542-5-mailhol.vincent@wanadoo.fr/ Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v3 4/4] can: dev: drop tx skb if in listen only mode 2022-05-14 14:16 ` [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes Vincent Mailhol ` (2 preceding siblings ...) 2022-05-14 14:16 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol @ 2022-05-14 14:16 ` Vincent Mailhol 3 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-05-14 14:16 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Frames can be directly injected to a can driver via the packet socket. By doing that, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configured in listen only mode. Add a check in can_dropped_invalid_skb() to discard the skb if CAN_CTRLMODE_LISTENONLY is set. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index 8b1991130de5..f7420fc43b99 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,7 @@ */ #include <linux/can/dev.h> +#include <linux/can/netlink.h> /* Local echo of CAN messages * @@ -286,6 +287,7 @@ static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) { const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + struct can_priv *priv = netdev_priv(dev); if (skb->protocol == htons(ETH_P_CAN)) { if (unlikely(skb->len != CAN_MTU || @@ -299,8 +301,13 @@ bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) goto inval_skb; } - if (!can_skb_headroom_valid(dev, skb)) + if (!can_skb_headroom_valid(dev, skb)) { + goto inval_skb; + } else if (priv->ctrlmode & CAN_CTRLMODE_LISTENONLY) { + netdev_info_once(dev, + "interface in listen only mode, dropping skb\n"); goto inval_skb; + } return false; -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol ` (4 preceding siblings ...) 2022-05-14 14:16 ` [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol ` (7 more replies) 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol 7 siblings, 8 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Aside of calc_bittiming.o which can be configured with CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked unconditionally to can-dev.o even if not needed by the user. This series first goal it to split the can-dev modules so that the user can decide which features get built in during compilation. Additionally, the CAN Device Drivers menu is moved from the "Networking support" category to the "Device Drivers" category (where all drivers are supposed to be). Below diagrams illustrate the changes made. The arrow symbol "x --> y" denotes that "y depends on x". * menu before this series * CAN bus subsystem support symbol: CONFIG_CAN | +-> CAN Device Drivers (no symbol) | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> Platform CAN drivers with Netlink support symbol: CONFIG_CAN_DEV | +-> CAN bit-timing calculation (optional for hardware drivers) | symbol: CONFIG_CAN_BITTIMING | +-> All other CAN devices * menu after this series * Network device support symbol: CONFIG_NETDEVICES | +-> CAN Device Drivers symbol: CONFIG_CAN_DEV | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> CAN device drivers with Netlink support symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) | +-> CAN bit-timing calculation (optional for all drivers) | symbol: CONFIG_CAN_BITTIMING | +-> All other CAN devices not relying on RX offload | +-> CAN rx offload symbol: CONFIG_CAN_RX_OFFLOAD | +-> CAN devices relying on rx offload (at time of writing: flexcan, ti_hecc and mcp251xfd) Patches 1 to 5 of this series do above modification. The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard tx skb (such skb can potentially reach the driver if injected via the packet socket). In more details, patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch 7 is the actual change. Those last two patches are actually connected to the first five ones: because slcan and v(x)can requires can_dropped_invalid_skb(), it was necessary to add those three devices to the scope of can-dev before moving the function to skb.o. ** N.B. ** This design results from the lengthy discussion in [1]. I did one change from Oliver's suggestions in [2]. The initial idea was that the first two config symbols should be respectively CAN_DEV_SW and CAN_DEV instead of CAN_DEV and CAN_NETLINK as proposed in this series. * First symbol is changed from CAN_DEV_SW to CAN_DEV. The rationale is that it is this entry that will trigger the build of can-dev.o and it makes more sense for me to name the symbol share the same name as the module. Furthermore, this allows to create a menuentry with an explicit name that will cover both the virtual and physical devices (naming the menuentry "CAN Device Software" would be inconsistent with the fact that physical devices would also be present in a sub menu). And not using menuentry complexifies the menu. * Second symbol is renamed from CAN_DEV to CAN_NETLINK because CAN_DEV is now taken by the previous menuconfig and netlink is the predominant feature added at this level. I am opened to other naming suggestion (CAN_DEV_NETLINK, CAN_DEV_HW...?). [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ [2] https://lore.kernel.org/linux-can/22590a57-c7c6-39c6-06d5-11c6e4e1534b@hartkopp.net/ ** Changelog ** v3 -> v4: * Five additional patches added to split can-dev module and refactor Kbuild. c.f. below (lengthy) thread: https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ v2 -> v3: * Apply can_dropped_invalid_skb() to slcan. * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by modifying Kbuild. * fix small typos. v1 -> v2: * move can_dropped_invalid_skb() to skb.c instead of dev.h * also move can_skb_headroom_valid() to skb.c Vincent Mailhol (7): can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV can: bittiming: move bittiming calculation functions to calc_bittiming.c can: Kconfig: add CONFIG_CAN_RX_OFFLOAD net: Kconfig: move the CAN device menu to the "Device Drivers" section can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c can: skb: drop tx skb if in listen only mode drivers/net/Kconfig | 2 + drivers/net/can/Kconfig | 66 +++++++-- drivers/net/can/dev/Makefile | 20 ++- drivers/net/can/dev/bittiming.c | 197 ------------------------- drivers/net/can/dev/calc_bittiming.c | 202 ++++++++++++++++++++++++++ drivers/net/can/dev/dev.c | 9 +- drivers/net/can/dev/skb.c | 72 +++++++++ drivers/net/can/spi/mcp251xfd/Kconfig | 1 + include/linux/can/skb.h | 59 +------- net/can/Kconfig | 5 +- 10 files changed, 351 insertions(+), 282 deletions(-) create mode 100644 drivers/net/can/dev/calc_bittiming.c -- 2.35.1 ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v4 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol ` (6 subsequent siblings) 7 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol In the next patches, the scope of the can_dev module will grow to engloble the software/virtual drivers (slcan, v(x)can). To this extent, release CAN_DEV by renaming it into CAN_NETLINK. The config symbol CAN_DEV will be reused to cover this extended scope. The rationale for the name CAN_NETLINK is that netlink is the predominant feature added here. The current description only mentions platform drivers despite the fact that this symbol is also required by "normal" devices (e.g. USB or PCI) which do not fall under the platform devices category. The description is updated accordingly to fix this gap. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- Please share if you have any suggestion on the name. I hesitated a lot between CAN_NETLINK or CAN_DEV_NETLINK (because netlink is the predominant feature) and CAN_DEV_HW (because this targets the non-software only drivers, i.e. the hardware ones). --- drivers/net/can/Kconfig | 18 +++++++++++------- drivers/net/can/dev/Makefile | 2 +- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index b2dcc1e5a388..99f189ad35ad 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -48,15 +48,19 @@ config CAN_SLCAN can be changed by the 'maxdev=xx' module option. This driver can also be built as a module. If so, the module will be called slcan. -config CAN_DEV - tristate "Platform CAN drivers with Netlink support" +config CAN_NETLINK + tristate "CAN device drivers with Netlink support" default y help - Enables the common framework for platform CAN drivers with Netlink - support. This is the standard library for CAN drivers. - If unsure, say Y. + Enables the common framework for CAN device drivers. This is the + standard library and provides features for the Netlink interface such + as bittiming validation, support of CAN error states, device restart + and others. + + This is required by all platform and hardware CAN drivers. If you + plan to use such devices or if unsure, say Y. -if CAN_DEV +if CAN_NETLINK config CAN_CALC_BITTIMING bool "CAN bit-timing calculation" @@ -164,7 +168,7 @@ source "drivers/net/can/softing/Kconfig" source "drivers/net/can/spi/Kconfig" source "drivers/net/can/usb/Kconfig" -endif +endif #CAN_NETLINK config CAN_DEBUG_DEVICES bool "CAN devices debugging messages" diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index af2901db473c..5b4c813c6222 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_CAN_DEV) += can-dev.o +obj-$(CONFIG_CAN_NETLINK) += can-dev.o can-dev-y += bittiming.o can-dev-y += dev.o can-dev-y += length.o -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-04 11:27 ` Marc Kleine-Budde 2022-06-04 13:46 ` Marc Kleine-Budde 2022-06-03 10:28 ` [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol ` (5 subsequent siblings) 7 siblings, 2 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol In the next patches, the software/virtual drivers (slcan, v(x)can) will depend on drivers/net/can/dev/skb.o. This patch changes the scope of the can-dev module to include the above mentioned drivers. To do so, we reuse the menu "CAN Device Drivers" and turn it into a configmenu using the config symbol CAN_DEV (which we released in previous patch). Also, add a description to this new CAN_DEV menuconfig. The symbol CAN_DEV now only triggers the build of skb.o. For this reasons, all the macros from linux/module.h are deported from drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c. Finally, drivers/net/can/dev/Makefile is adjusted accordingly. Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 29 ++++++++++++++++++++++++++--- drivers/net/can/dev/Makefile | 16 +++++++++------- drivers/net/can/dev/dev.c | 9 +-------- drivers/net/can/dev/skb.c | 7 +++++++ 4 files changed, 43 insertions(+), 18 deletions(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 99f189ad35ad..b1e47f6c5586 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -1,5 +1,25 @@ # SPDX-License-Identifier: GPL-2.0-only -menu "CAN Device Drivers" + +menuconfig CAN_DEV + tristate "CAN Device Drivers" + default y + help + Controller Area Network (CAN) is serial communications protocol up to + 1Mbit/s for its original release (now known as Classical CAN) and up + to 8Mbit/s for the more recent CAN with Flexible Data-Rate + (CAN-FD). The CAN bus was originally mainly for automotive, but is now + widely used in marine (NMEA2000), industrial, and medical + applications. More information on the CAN network protocol family + PF_CAN is contained in <Documentation/networking/can.rst>. + + This section contains all the CAN(-FD) device drivers including the + virtual ones. If you own such devices or plan to use the virtual CAN + interface to develop applications, say Y here. + + To compile as a module, choose M here: the module will be called + can-dev. + +if CAN_DEV config CAN_VCAN tristate "Virtual Local CAN Interface (vcan)" @@ -49,7 +69,7 @@ config CAN_SLCAN also be built as a module. If so, the module will be called slcan. config CAN_NETLINK - tristate "CAN device drivers with Netlink support" + bool "CAN device drivers with Netlink support" default y help Enables the common framework for CAN device drivers. This is the @@ -57,6 +77,9 @@ config CAN_NETLINK as bittiming validation, support of CAN error states, device restart and others. + The additional features selected by this option will be added to the + can-dev module. + This is required by all platform and hardware CAN drivers. If you plan to use such devices or if unsure, say Y. @@ -178,4 +201,4 @@ config CAN_DEBUG_DEVICES a problem with CAN support and want to see more of what is going on. -endmenu +endif #CAN_DEV diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 5b4c813c6222..919f87e36eed 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -1,9 +1,11 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_CAN_NETLINK) += can-dev.o -can-dev-y += bittiming.o -can-dev-y += dev.o -can-dev-y += length.o -can-dev-y += netlink.o -can-dev-y += rx-offload.o -can-dev-y += skb.o +obj-$(CONFIG_CAN_DEV) += can-dev.o + +can-dev-$(CONFIG_CAN_DEV) += skb.o + +can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o +can-dev-$(CONFIG_CAN_NETLINK) += dev.o +can-dev-$(CONFIG_CAN_NETLINK) += length.o +can-dev-$(CONFIG_CAN_NETLINK) += netlink.o +can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c index 96c9d9db00cf..523eaacfe29e 100644 --- a/drivers/net/can/dev/dev.c +++ b/drivers/net/can/dev/dev.c @@ -4,7 +4,6 @@ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> */ -#include <linux/module.h> #include <linux/kernel.h> #include <linux/slab.h> #include <linux/netdevice.h> @@ -17,12 +16,6 @@ #include <linux/gpio/consumer.h> #include <linux/of.h> -#define MOD_DESC "CAN device driver interface" - -MODULE_DESCRIPTION(MOD_DESC); -MODULE_LICENSE("GPL v2"); -MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>"); - static void can_update_state_error_stats(struct net_device *dev, enum can_state new_state) { @@ -513,7 +506,7 @@ static __init int can_dev_init(void) err = can_netlink_register(); if (!err) - pr_info(MOD_DESC "\n"); + pr_info("CAN device driver interface\n"); return err; } diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index 61660248c69e..a4208f125b76 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,13 @@ */ #include <linux/can/dev.h> +#include <linux/module.h> + +#define MOD_DESC "CAN device driver interface" + +MODULE_DESCRIPTION(MOD_DESC); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>"); /* Local echo of CAN messages * -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV 2022-06-03 10:28 ` [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol @ 2022-06-04 11:27 ` Marc Kleine-Budde 2022-06-04 12:30 ` Vincent MAILHOL 2022-06-04 13:46 ` Marc Kleine-Budde 1 sibling, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 11:27 UTC (permalink / raw) To: Vincent Mailhol Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 1825 bytes --] On 03.06.2022 19:28:43, Vincent Mailhol wrote: > In the next patches, the software/virtual drivers (slcan, v(x)can) > will depend on drivers/net/can/dev/skb.o. > > This patch changes the scope of the can-dev module to include the > above mentioned drivers. > > To do so, we reuse the menu "CAN Device Drivers" and turn it into a > configmenu using the config symbol CAN_DEV (which we released in > previous patch). Also, add a description to this new CAN_DEV > menuconfig. > > The symbol CAN_DEV now only triggers the build of skb.o. For this > reasons, all the macros from linux/module.h are deported from > drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c. > > Finally, drivers/net/can/dev/Makefile is adjusted accordingly. > > Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net> > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > --- > drivers/net/can/Kconfig | 29 ++++++++++++++++++++++++++--- > drivers/net/can/dev/Makefile | 16 +++++++++------- > drivers/net/can/dev/dev.c | 9 +-------- > drivers/net/can/dev/skb.c | 7 +++++++ > 4 files changed, 43 insertions(+), 18 deletions(-) > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > index 5b4c813c6222..919f87e36eed 100644 > --- a/drivers/net/can/dev/Makefile > +++ b/drivers/net/can/dev/Makefile > @@ -1,9 +1,11 @@ > # SPDX-License-Identifier: GPL-2.0 > > -obj-$(CONFIG_CAN_NETLINK) += can-dev.o ^^^^^^^^^^^^^^^^^^^^^ Nitpick: I think you can directly use "y" here. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV 2022-06-04 11:27 ` Marc Kleine-Budde @ 2022-06-04 12:30 ` Vincent MAILHOL 2022-06-04 12:43 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-04 12:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sat. 4 juin 2022 at 20:27, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 03.06.2022 19:28:43, Vincent Mailhol wrote: > > In the next patches, the software/virtual drivers (slcan, v(x)can) > > will depend on drivers/net/can/dev/skb.o. > > > > This patch changes the scope of the can-dev module to include the > > above mentioned drivers. > > > > To do so, we reuse the menu "CAN Device Drivers" and turn it into a > > configmenu using the config symbol CAN_DEV (which we released in > > previous patch). Also, add a description to this new CAN_DEV > > menuconfig. > > > > The symbol CAN_DEV now only triggers the build of skb.o. For this > > reasons, all the macros from linux/module.h are deported from > > drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c. > > > > Finally, drivers/net/can/dev/Makefile is adjusted accordingly. > > > > Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net> > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > --- > > drivers/net/can/Kconfig | 29 ++++++++++++++++++++++++++--- > > drivers/net/can/dev/Makefile | 16 +++++++++------- > > drivers/net/can/dev/dev.c | 9 +-------- > > drivers/net/can/dev/skb.c | 7 +++++++ > > 4 files changed, 43 insertions(+), 18 deletions(-) > > > > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > > index 5b4c813c6222..919f87e36eed 100644 > > --- a/drivers/net/can/dev/Makefile > > +++ b/drivers/net/can/dev/Makefile > > @@ -1,9 +1,11 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -obj-$(CONFIG_CAN_NETLINK) += can-dev.o > > +obj-$(CONFIG_CAN_DEV) += can-dev.o > ^^^^^^^^^^^^^^^^^^^^^ > > Nitpick: I think you can directly use "y" here. I see. So the idea would be that if we deselect CONFIG_CAN_DEV, then despite of can-dev.o being always "yes", it would be empty and thus ignored. I just didn't know this trick. I will do as suggested. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV 2022-06-04 12:30 ` Vincent MAILHOL @ 2022-06-04 12:43 ` Marc Kleine-Budde 0 siblings, 0 replies; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 12:43 UTC (permalink / raw) To: Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 960 bytes --] On 04.06.2022 21:30:57, Vincent MAILHOL wrote: > > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > > > index 5b4c813c6222..919f87e36eed 100644 > > > --- a/drivers/net/can/dev/Makefile > > > +++ b/drivers/net/can/dev/Makefile > > > @@ -1,9 +1,11 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > -obj-$(CONFIG_CAN_NETLINK) += can-dev.o > > > +obj-$(CONFIG_CAN_DEV) += can-dev.o > > ^^^^^^^^^^^^^^^^^^^^^ > > > > Nitpick: I think you can directly use "y" here. > > I see. So the idea would be that if we deselect CONFIG_CAN_DEV, then > despite of can-dev.o being always "yes", it would be empty and thus > ignored. ACK 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV 2022-06-03 10:28 ` [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol 2022-06-04 11:27 ` Marc Kleine-Budde @ 2022-06-04 13:46 ` Marc Kleine-Budde 1 sibling, 0 replies; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 13:46 UTC (permalink / raw) To: Vincent Mailhol Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 1211 bytes --] My previous mail on this was wrong (as you noticed).... so here's the corrected one (hopefully). On 03.06.2022 19:28:43, Vincent Mailhol wrote: > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > index 5b4c813c6222..919f87e36eed 100644 > --- a/drivers/net/can/dev/Makefile > +++ b/drivers/net/can/dev/Makefile > @@ -1,9 +1,11 @@ > # SPDX-License-Identifier: GPL-2.0 > > -obj-$(CONFIG_CAN_NETLINK) += can-dev.o > -can-dev-y += bittiming.o > -can-dev-y += dev.o > -can-dev-y += length.o > -can-dev-y += netlink.o > -can-dev-y += rx-offload.o > -can-dev-y += skb.o > +obj-$(CONFIG_CAN_DEV) += can-dev.o > + > +can-dev-$(CONFIG_CAN_DEV) += skb.o ^^^^^^^^^^^^^^^^ As "skb.o" is always part of "can-dev.o" (if build at all), you can use "can-dev-y" here. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-04 11:25 ` Marc Kleine-Budde 2022-06-03 10:28 ` [PATCH v4 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol ` (4 subsequent siblings) 7 siblings, 1 reply; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol The canonical way to select or deselect an object during compilation is to use this pattern in the relevant Makefile: bar-$(CONFIG_FOO) := foo.o bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. Create a new file named calc_bittiming.c with all the functions which are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the Makefile according to above pattern. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 4 + drivers/net/can/dev/Makefile | 2 + drivers/net/can/dev/bittiming.c | 197 -------------------------- drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++ 4 files changed, 208 insertions(+), 197 deletions(-) create mode 100644 drivers/net/can/dev/calc_bittiming.c diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index b1e47f6c5586..8f3b97aea638 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING source clock frequencies. Disabling saves some space, but then the bit-timing parameters must be specified directly using the Netlink arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw". + + The additional features selected by this option will be added to the + can-dev module. + If unsure, say Y. config CAN_AT91 diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 919f87e36eed..b8a55b1d90cd 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o can-dev-$(CONFIG_CAN_NETLINK) += netlink.o can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o + +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o diff --git a/drivers/net/can/dev/bittiming.c b/drivers/net/can/dev/bittiming.c index c1e76f0a5064..7ae80763c960 100644 --- a/drivers/net/can/dev/bittiming.c +++ b/drivers/net/can/dev/bittiming.c @@ -4,205 +4,8 @@ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> */ -#include <linux/units.h> #include <linux/can/dev.h> -#ifdef CONFIG_CAN_CALC_BITTIMING -#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */ - -/* Bit-timing calculation derived from: - * - * Code based on LinCAN sources and H8S2638 project - * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz - * Copyright 2005 Stanislav Marek - * email: pisa@cmp.felk.cvut.cz - * - * Calculates proper bit-timing parameters for a specified bit-rate - * and sample-point, which can then be used to set the bit-timing - * registers of the CAN controller. You can find more information - * in the header file linux/can/netlink.h. - */ -static int -can_update_sample_point(const struct can_bittiming_const *btc, - const unsigned int sample_point_nominal, const unsigned int tseg, - unsigned int *tseg1_ptr, unsigned int *tseg2_ptr, - unsigned int *sample_point_error_ptr) -{ - unsigned int sample_point_error, best_sample_point_error = UINT_MAX; - unsigned int sample_point, best_sample_point = 0; - unsigned int tseg1, tseg2; - int i; - - for (i = 0; i <= 1; i++) { - tseg2 = tseg + CAN_SYNC_SEG - - (sample_point_nominal * (tseg + CAN_SYNC_SEG)) / - 1000 - i; - tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max); - tseg1 = tseg - tseg2; - if (tseg1 > btc->tseg1_max) { - tseg1 = btc->tseg1_max; - tseg2 = tseg - tseg1; - } - - sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) / - (tseg + CAN_SYNC_SEG); - sample_point_error = abs(sample_point_nominal - sample_point); - - if (sample_point <= sample_point_nominal && - sample_point_error < best_sample_point_error) { - best_sample_point = sample_point; - best_sample_point_error = sample_point_error; - *tseg1_ptr = tseg1; - *tseg2_ptr = tseg2; - } - } - - if (sample_point_error_ptr) - *sample_point_error_ptr = best_sample_point_error; - - return best_sample_point; -} - -int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt, - const struct can_bittiming_const *btc) -{ - struct can_priv *priv = netdev_priv(dev); - unsigned int bitrate; /* current bitrate */ - unsigned int bitrate_error; /* difference between current and nominal value */ - unsigned int best_bitrate_error = UINT_MAX; - unsigned int sample_point_error; /* difference between current and nominal value */ - unsigned int best_sample_point_error = UINT_MAX; - unsigned int sample_point_nominal; /* nominal sample point */ - unsigned int best_tseg = 0; /* current best value for tseg */ - unsigned int best_brp = 0; /* current best value for brp */ - unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0; - u64 v64; - - /* Use CiA recommended sample points */ - if (bt->sample_point) { - sample_point_nominal = bt->sample_point; - } else { - if (bt->bitrate > 800 * KILO /* BPS */) - sample_point_nominal = 750; - else if (bt->bitrate > 500 * KILO /* BPS */) - sample_point_nominal = 800; - else - sample_point_nominal = 875; - } - - /* tseg even = round down, odd = round up */ - for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1; - tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) { - tsegall = CAN_SYNC_SEG + tseg / 2; - - /* Compute all possible tseg choices (tseg=tseg1+tseg2) */ - brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2; - - /* choose brp step which is possible in system */ - brp = (brp / btc->brp_inc) * btc->brp_inc; - if (brp < btc->brp_min || brp > btc->brp_max) - continue; - - bitrate = priv->clock.freq / (brp * tsegall); - bitrate_error = abs(bt->bitrate - bitrate); - - /* tseg brp biterror */ - if (bitrate_error > best_bitrate_error) - continue; - - /* reset sample point error if we have a better bitrate */ - if (bitrate_error < best_bitrate_error) - best_sample_point_error = UINT_MAX; - - can_update_sample_point(btc, sample_point_nominal, tseg / 2, - &tseg1, &tseg2, &sample_point_error); - if (sample_point_error >= best_sample_point_error) - continue; - - best_sample_point_error = sample_point_error; - best_bitrate_error = bitrate_error; - best_tseg = tseg / 2; - best_brp = brp; - - if (bitrate_error == 0 && sample_point_error == 0) - break; - } - - if (best_bitrate_error) { - /* Error in one-tenth of a percent */ - v64 = (u64)best_bitrate_error * 1000; - do_div(v64, bt->bitrate); - bitrate_error = (u32)v64; - if (bitrate_error > CAN_CALC_MAX_ERROR) { - netdev_err(dev, - "bitrate error %d.%d%% too high\n", - bitrate_error / 10, bitrate_error % 10); - return -EDOM; - } - netdev_warn(dev, "bitrate error %d.%d%%\n", - bitrate_error / 10, bitrate_error % 10); - } - - /* real sample point */ - bt->sample_point = can_update_sample_point(btc, sample_point_nominal, - best_tseg, &tseg1, &tseg2, - NULL); - - v64 = (u64)best_brp * 1000 * 1000 * 1000; - do_div(v64, priv->clock.freq); - bt->tq = (u32)v64; - bt->prop_seg = tseg1 / 2; - bt->phase_seg1 = tseg1 - bt->prop_seg; - bt->phase_seg2 = tseg2; - - /* check for sjw user settings */ - if (!bt->sjw || !btc->sjw_max) { - bt->sjw = 1; - } else { - /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */ - if (bt->sjw > btc->sjw_max) - bt->sjw = btc->sjw_max; - /* bt->sjw must not be higher than tseg2 */ - if (tseg2 < bt->sjw) - bt->sjw = tseg2; - } - - bt->brp = best_brp; - - /* real bitrate */ - bt->bitrate = priv->clock.freq / - (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2)); - - return 0; -} - -void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const, - const struct can_bittiming *dbt, - u32 *ctrlmode, u32 ctrlmode_supported) - -{ - if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO)) - return; - - *ctrlmode &= ~CAN_CTRLMODE_TDC_MASK; - - /* As specified in ISO 11898-1 section 11.3.3 "Transmitter - * delay compensation" (TDC) is only applicable if data BRP is - * one or two. - */ - if (dbt->brp == 1 || dbt->brp == 2) { - /* Sample point in clock periods */ - u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg + - dbt->phase_seg1) * dbt->brp; - - if (sample_point_in_tc < tdc_const->tdco_min) - return; - tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max); - *ctrlmode |= CAN_CTRLMODE_TDC_AUTO; - } -} -#endif /* CONFIG_CAN_CALC_BITTIMING */ - /* Checks the validity of the specified bit-timing parameters prop_seg, * phase_seg1, phase_seg2 and sjw and tries to determine the bitrate * prescaler value brp. You can find more information in the header diff --git a/drivers/net/can/dev/calc_bittiming.c b/drivers/net/can/dev/calc_bittiming.c new file mode 100644 index 000000000000..d3caa040614d --- /dev/null +++ b/drivers/net/can/dev/calc_bittiming.c @@ -0,0 +1,202 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* Copyright (C) 2005 Marc Kleine-Budde, Pengutronix + * Copyright (C) 2006 Andrey Volkov, Varma Electronics + * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> + */ + +#include <linux/units.h> +#include <linux/can/dev.h> + +#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */ + +/* Bit-timing calculation derived from: + * + * Code based on LinCAN sources and H8S2638 project + * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz + * Copyright 2005 Stanislav Marek + * email: pisa@cmp.felk.cvut.cz + * + * Calculates proper bit-timing parameters for a specified bit-rate + * and sample-point, which can then be used to set the bit-timing + * registers of the CAN controller. You can find more information + * in the header file linux/can/netlink.h. + */ +static int +can_update_sample_point(const struct can_bittiming_const *btc, + const unsigned int sample_point_nominal, const unsigned int tseg, + unsigned int *tseg1_ptr, unsigned int *tseg2_ptr, + unsigned int *sample_point_error_ptr) +{ + unsigned int sample_point_error, best_sample_point_error = UINT_MAX; + unsigned int sample_point, best_sample_point = 0; + unsigned int tseg1, tseg2; + int i; + + for (i = 0; i <= 1; i++) { + tseg2 = tseg + CAN_SYNC_SEG - + (sample_point_nominal * (tseg + CAN_SYNC_SEG)) / + 1000 - i; + tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max); + tseg1 = tseg - tseg2; + if (tseg1 > btc->tseg1_max) { + tseg1 = btc->tseg1_max; + tseg2 = tseg - tseg1; + } + + sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) / + (tseg + CAN_SYNC_SEG); + sample_point_error = abs(sample_point_nominal - sample_point); + + if (sample_point <= sample_point_nominal && + sample_point_error < best_sample_point_error) { + best_sample_point = sample_point; + best_sample_point_error = sample_point_error; + *tseg1_ptr = tseg1; + *tseg2_ptr = tseg2; + } + } + + if (sample_point_error_ptr) + *sample_point_error_ptr = best_sample_point_error; + + return best_sample_point; +} + +int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt, + const struct can_bittiming_const *btc) +{ + struct can_priv *priv = netdev_priv(dev); + unsigned int bitrate; /* current bitrate */ + unsigned int bitrate_error; /* difference between current and nominal value */ + unsigned int best_bitrate_error = UINT_MAX; + unsigned int sample_point_error; /* difference between current and nominal value */ + unsigned int best_sample_point_error = UINT_MAX; + unsigned int sample_point_nominal; /* nominal sample point */ + unsigned int best_tseg = 0; /* current best value for tseg */ + unsigned int best_brp = 0; /* current best value for brp */ + unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0; + u64 v64; + + /* Use CiA recommended sample points */ + if (bt->sample_point) { + sample_point_nominal = bt->sample_point; + } else { + if (bt->bitrate > 800 * KILO /* BPS */) + sample_point_nominal = 750; + else if (bt->bitrate > 500 * KILO /* BPS */) + sample_point_nominal = 800; + else + sample_point_nominal = 875; + } + + /* tseg even = round down, odd = round up */ + for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1; + tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) { + tsegall = CAN_SYNC_SEG + tseg / 2; + + /* Compute all possible tseg choices (tseg=tseg1+tseg2) */ + brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2; + + /* choose brp step which is possible in system */ + brp = (brp / btc->brp_inc) * btc->brp_inc; + if (brp < btc->brp_min || brp > btc->brp_max) + continue; + + bitrate = priv->clock.freq / (brp * tsegall); + bitrate_error = abs(bt->bitrate - bitrate); + + /* tseg brp biterror */ + if (bitrate_error > best_bitrate_error) + continue; + + /* reset sample point error if we have a better bitrate */ + if (bitrate_error < best_bitrate_error) + best_sample_point_error = UINT_MAX; + + can_update_sample_point(btc, sample_point_nominal, tseg / 2, + &tseg1, &tseg2, &sample_point_error); + if (sample_point_error >= best_sample_point_error) + continue; + + best_sample_point_error = sample_point_error; + best_bitrate_error = bitrate_error; + best_tseg = tseg / 2; + best_brp = brp; + + if (bitrate_error == 0 && sample_point_error == 0) + break; + } + + if (best_bitrate_error) { + /* Error in one-tenth of a percent */ + v64 = (u64)best_bitrate_error * 1000; + do_div(v64, bt->bitrate); + bitrate_error = (u32)v64; + if (bitrate_error > CAN_CALC_MAX_ERROR) { + netdev_err(dev, + "bitrate error %d.%d%% too high\n", + bitrate_error / 10, bitrate_error % 10); + return -EDOM; + } + netdev_warn(dev, "bitrate error %d.%d%%\n", + bitrate_error / 10, bitrate_error % 10); + } + + /* real sample point */ + bt->sample_point = can_update_sample_point(btc, sample_point_nominal, + best_tseg, &tseg1, &tseg2, + NULL); + + v64 = (u64)best_brp * 1000 * 1000 * 1000; + do_div(v64, priv->clock.freq); + bt->tq = (u32)v64; + bt->prop_seg = tseg1 / 2; + bt->phase_seg1 = tseg1 - bt->prop_seg; + bt->phase_seg2 = tseg2; + + /* check for sjw user settings */ + if (!bt->sjw || !btc->sjw_max) { + bt->sjw = 1; + } else { + /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */ + if (bt->sjw > btc->sjw_max) + bt->sjw = btc->sjw_max; + /* bt->sjw must not be higher than tseg2 */ + if (tseg2 < bt->sjw) + bt->sjw = tseg2; + } + + bt->brp = best_brp; + + /* real bitrate */ + bt->bitrate = priv->clock.freq / + (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2)); + + return 0; +} + +void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const, + const struct can_bittiming *dbt, + u32 *ctrlmode, u32 ctrlmode_supported) + +{ + if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO)) + return; + + *ctrlmode &= ~CAN_CTRLMODE_TDC_MASK; + + /* As specified in ISO 11898-1 section 11.3.3 "Transmitter + * delay compensation" (TDC) is only applicable if data BRP is + * one or two. + */ + if (dbt->brp == 1 || dbt->brp == 2) { + /* Sample point in clock periods */ + u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg + + dbt->phase_seg1) * dbt->brp; + + if (sample_point_in_tc < tdc_const->tdco_min) + return; + tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max); + *ctrlmode |= CAN_CTRLMODE_TDC_AUTO; + } +} -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-03 10:28 ` [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol @ 2022-06-04 11:25 ` Marc Kleine-Budde 2022-06-04 12:21 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 11:25 UTC (permalink / raw) To: Vincent Mailhol Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 2295 bytes --] On 03.06.2022 19:28:44, Vincent Mailhol wrote: > The canonical way to select or deselect an object during compilation > is to use this pattern in the relevant Makefile: > > bar-$(CONFIG_FOO) := foo.o > > bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. > > Create a new file named calc_bittiming.c with all the functions which > are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the > Makefile according to above pattern. > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > --- > drivers/net/can/Kconfig | 4 + > drivers/net/can/dev/Makefile | 2 + > drivers/net/can/dev/bittiming.c | 197 -------------------------- > drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++ > 4 files changed, 208 insertions(+), 197 deletions(-) > create mode 100644 drivers/net/can/dev/calc_bittiming.c > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > index b1e47f6c5586..8f3b97aea638 100644 > --- a/drivers/net/can/Kconfig > +++ b/drivers/net/can/Kconfig > @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING > source clock frequencies. Disabling saves some space, but then the > bit-timing parameters must be specified directly using the Netlink > arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw". > + > + The additional features selected by this option will be added to the > + can-dev module. > + > If unsure, say Y. > > config CAN_AT91 > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > index 919f87e36eed..b8a55b1d90cd 100644 > --- a/drivers/net/can/dev/Makefile > +++ b/drivers/net/can/dev/Makefile > @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o > can-dev-$(CONFIG_CAN_NETLINK) += length.o > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o > + > +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o Nitpick: Can we keep this list sorted? 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-04 11:25 ` Marc Kleine-Budde @ 2022-06-04 12:21 ` Vincent MAILHOL 2022-06-04 12:41 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-04 12:21 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sat. 4 June 2022 at 20:25, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 03.06.2022 19:28:44, Vincent Mailhol wrote: > > The canonical way to select or deselect an object during compilation > > is to use this pattern in the relevant Makefile: > > > > bar-$(CONFIG_FOO) := foo.o > > > > bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. > > > > Create a new file named calc_bittiming.c with all the functions which > > are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the > > Makefile according to above pattern. > > > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > --- > > drivers/net/can/Kconfig | 4 + > > drivers/net/can/dev/Makefile | 2 + > > drivers/net/can/dev/bittiming.c | 197 -------------------------- > > drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++ > > 4 files changed, 208 insertions(+), 197 deletions(-) > > create mode 100644 drivers/net/can/dev/calc_bittiming.c > > > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > > index b1e47f6c5586..8f3b97aea638 100644 > > --- a/drivers/net/can/Kconfig > > +++ b/drivers/net/can/Kconfig > > @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING > > source clock frequencies. Disabling saves some space, but then the > > bit-timing parameters must be specified directly using the Netlink > > arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw". > > + > > + The additional features selected by this option will be added to the > > + can-dev module. > > + > > If unsure, say Y. > > > > config CAN_AT91 > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > > index 919f87e36eed..b8a55b1d90cd 100644 > > --- a/drivers/net/can/dev/Makefile > > +++ b/drivers/net/can/dev/Makefile > > @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o > > can-dev-$(CONFIG_CAN_NETLINK) += length.o > > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > > can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o > > + > > +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > Nitpick: > Can we keep this list sorted? My idea was first to group per CONFIG symbol according to the different levels: CAN_DEV first, then CAN_NETLINK and finally CAN_CALC_BITTIMING and CAN_RX_OFFLOAD. And then only sort by alphabetical order within each group. By sorting the list, do literally mean to sort each line like this: obj-$(CONFIG_CAN_DEV) += can-dev.o can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o can-dev-$(CONFIG_CAN_DEV) += skb.o can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o can-dev-$(CONFIG_CAN_NETLINK) += netlink.o can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o or do you mean to sort by object name (ignoring the config symbol) like that: obj-$(CONFIG_CAN_DEV) += can-dev.o can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o can-dev-$(CONFIG_CAN_NETLINK) += netlink.o can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o can-dev-$(CONFIG_CAN_DEV) += skb.o ? (I honestly do not care so much how we sort the lines. My logic of grouping first by CONFIG symbols seems more natural, but I am fine to go with any other suggestion). ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-04 12:21 ` Vincent MAILHOL @ 2022-06-04 12:41 ` Marc Kleine-Budde 2022-06-04 12:56 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 12:41 UTC (permalink / raw) To: Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 4496 bytes --] On 04.06.2022 21:21:01, Vincent MAILHOL wrote: > On Sat. 4 June 2022 at 20:25, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > On 03.06.2022 19:28:44, Vincent Mailhol wrote: > > > The canonical way to select or deselect an object during compilation > > > is to use this pattern in the relevant Makefile: > > > > > > bar-$(CONFIG_FOO) := foo.o > > > > > > bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. > > > > > > Create a new file named calc_bittiming.c with all the functions which > > > are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the > > > Makefile according to above pattern. > > > > > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > > --- > > > drivers/net/can/Kconfig | 4 + > > > drivers/net/can/dev/Makefile | 2 + > > > drivers/net/can/dev/bittiming.c | 197 -------------------------- > > > drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++ > > > 4 files changed, 208 insertions(+), 197 deletions(-) > > > create mode 100644 drivers/net/can/dev/calc_bittiming.c > > > > > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > > > index b1e47f6c5586..8f3b97aea638 100644 > > > --- a/drivers/net/can/Kconfig > > > +++ b/drivers/net/can/Kconfig > > > @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING > > > source clock frequencies. Disabling saves some space, but then the > > > bit-timing parameters must be specified directly using the Netlink > > > arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw". > > > + > > > + The additional features selected by this option will be added to the > > > + can-dev module. > > > + > > > If unsure, say Y. > > > > > > config CAN_AT91 > > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > > > index 919f87e36eed..b8a55b1d90cd 100644 > > > --- a/drivers/net/can/dev/Makefile > > > +++ b/drivers/net/can/dev/Makefile > > > @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o > > > can-dev-$(CONFIG_CAN_NETLINK) += length.o > > > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > > > can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o > > > + > > > +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > > > Nitpick: > > Can we keep this list sorted? > > My idea was first to group per CONFIG symbol according to the > different levels: CAN_DEV first, then CAN_NETLINK and finally > CAN_CALC_BITTIMING and CAN_RX_OFFLOAD. And then only sort by > alphabetical order within each group. I was thinking to order by CONFIG symbol and put the objects without an additional symbol first > By sorting the list, do literally mean to sort each line like this: > > obj-$(CONFIG_CAN_DEV) += can-dev.o > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > can-dev-$(CONFIG_CAN_DEV) += skb.o > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o > can-dev-$(CONFIG_CAN_NETLINK) += dev.o > can-dev-$(CONFIG_CAN_NETLINK) += length.o > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o ...which results in: obj-$(CONFIG_CAN_DEV) += can-dev.o can-dev-y += skb.o can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o can-dev-$(CONFIG_CAN_NETLINK) += netlink.o can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > or do you mean to sort by object name (ignoring the config symbol) like that: > > obj-$(CONFIG_CAN_DEV) += can-dev.o > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > can-dev-$(CONFIG_CAN_NETLINK) += dev.o > can-dev-$(CONFIG_CAN_NETLINK) += length.o > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > can-dev-$(CONFIG_CAN_DEV) += skb.o > > ? > > (I honestly do not care so much how we sort the lines. My logic of > grouping first by CONFIG symbols seems more natural, but I am fine to > go with any other suggestion). I think this makes it clear where new files should be added. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-04 12:41 ` Marc Kleine-Budde @ 2022-06-04 12:56 ` Vincent MAILHOL 2022-06-04 13:51 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-04 12:56 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sat. 4 June 2022 at 21:41, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 04.06.2022 21:21:01, Vincent MAILHOL wrote: > > On Sat. 4 June 2022 at 20:25, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > > On 03.06.2022 19:28:44, Vincent Mailhol wrote: > > > > The canonical way to select or deselect an object during compilation > > > > is to use this pattern in the relevant Makefile: > > > > > > > > bar-$(CONFIG_FOO) := foo.o > > > > > > > > bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. > > > > > > > > Create a new file named calc_bittiming.c with all the functions which > > > > are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the > > > > Makefile according to above pattern. > > > > > > > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > > > --- > > > > drivers/net/can/Kconfig | 4 + > > > > drivers/net/can/dev/Makefile | 2 + > > > > drivers/net/can/dev/bittiming.c | 197 -------------------------- > > > > drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++ > > > > 4 files changed, 208 insertions(+), 197 deletions(-) > > > > create mode 100644 drivers/net/can/dev/calc_bittiming.c > > > > > > > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > > > > index b1e47f6c5586..8f3b97aea638 100644 > > > > --- a/drivers/net/can/Kconfig > > > > +++ b/drivers/net/can/Kconfig > > > > @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING > > > > source clock frequencies. Disabling saves some space, but then the > > > > bit-timing parameters must be specified directly using the Netlink > > > > arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw". > > > > + > > > > + The additional features selected by this option will be added to the > > > > + can-dev module. > > > > + > > > > If unsure, say Y. > > > > > > > > config CAN_AT91 > > > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > > > > index 919f87e36eed..b8a55b1d90cd 100644 > > > > --- a/drivers/net/can/dev/Makefile > > > > +++ b/drivers/net/can/dev/Makefile > > > > @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o > > > > can-dev-$(CONFIG_CAN_NETLINK) += length.o > > > > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > > > > can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o > > > > + > > > > +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > > > > > Nitpick: > > > Can we keep this list sorted? > > > > My idea was first to group per CONFIG symbol according to the > > different levels: CAN_DEV first, then CAN_NETLINK and finally > > CAN_CALC_BITTIMING and CAN_RX_OFFLOAD. And then only sort by > > alphabetical order within each group. > > I was thinking to order by CONFIG symbol and put the objects without an > additional symbol first > > > By sorting the list, do literally mean to sort each line like this: > > > > obj-$(CONFIG_CAN_DEV) += can-dev.o > > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > can-dev-$(CONFIG_CAN_DEV) += skb.o > > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o > > can-dev-$(CONFIG_CAN_NETLINK) += dev.o > > can-dev-$(CONFIG_CAN_NETLINK) += length.o > > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > > ...which results in: > > obj-$(CONFIG_CAN_DEV) += can-dev.o > > can-dev-y += skb.o I see. But this contradicts the idea to do | obj-y += can-dev as suggested in: https://lore.kernel.org/linux-can/20220604112707.z4zjdjydqy5rkyfe@pengutronix.de/ So, we have to choose between: | obj-$(CONFIG_CAN_DEV) += can-dev.o | | can-dev-y += skb.o | | can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o | (...) or: | obj-y += can-dev.o | | can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o | can-dev-$(CONFIG_CAN_DEV) += skb.o | (...) I have a slight preference for the second, but again, wouldn't mind to select the first one. > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o > can-dev-$(CONFIG_CAN_NETLINK) += dev.o > can-dev-$(CONFIG_CAN_NETLINK) += length.o > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > > > or do you mean to sort by object name (ignoring the config symbol) like that: > > > > obj-$(CONFIG_CAN_DEV) += can-dev.o > > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o > > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > can-dev-$(CONFIG_CAN_NETLINK) += dev.o > > can-dev-$(CONFIG_CAN_NETLINK) += length.o > > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > > can-dev-$(CONFIG_CAN_DEV) += skb.o > > > > ? > > > > (I honestly do not care so much how we sort the lines. My logic of > > grouping first by CONFIG symbols seems more natural, but I am fine to > > go with any other suggestion). > > I think this makes it clear where new files should be added. > > 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 | ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-04 12:56 ` Vincent MAILHOL @ 2022-06-04 13:51 ` Marc Kleine-Budde 0 siblings, 0 replies; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 13:51 UTC (permalink / raw) To: Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 1954 bytes --] On 04.06.2022 21:56:23, Vincent MAILHOL wrote: > > I was thinking to order by CONFIG symbol and put the objects without an > > additional symbol first > > > > > By sorting the list, do literally mean to sort each line like this: > > > > > > obj-$(CONFIG_CAN_DEV) += can-dev.o > > > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > > can-dev-$(CONFIG_CAN_DEV) += skb.o > > > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o > > > can-dev-$(CONFIG_CAN_NETLINK) += dev.o > > > can-dev-$(CONFIG_CAN_NETLINK) += length.o > > > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > > > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > > > > ...which results in: > > > > obj-$(CONFIG_CAN_DEV) += can-dev.o > > > > can-dev-y += skb.o > > I see. But this contradicts the idea to do > | obj-y += can-dev > as suggested in: > https://lore.kernel.org/linux-can/20220604112707.z4zjdjydqy5rkyfe@pengutronix.de/ Doh! That mail was totally wrong - I've send an updated version. > So, we have to choose between: > | obj-$(CONFIG_CAN_DEV) += can-dev.o > | > | can-dev-y += skb.o > | > | can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > | (...) +1 > or: > > | obj-y += can-dev.o > | > | can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > | can-dev-$(CONFIG_CAN_DEV) += skb.o > | (...) > > I have a slight preference for the second, but again, wouldn't mind to > select the first one. I think if can-dev is added to "obj-y" it will be always complied into the kernel. It will not be a module, if CONFIG_CAN_DEV configured as a module (which results in $(CONFIG_CAN_DEV) evaluate to "m"). Sorry for the confusion! 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v4 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol ` (2 preceding siblings ...) 2022-06-03 10:28 ` [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-04 11:22 ` Marc Kleine-Budde 2022-06-03 10:28 ` [PATCH v4 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol ` (3 subsequent siblings) 7 siblings, 1 reply; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Only a few drivers rely on the CAN rx offload framework (as of the writing of this patch, only three: flexcan, ti_hecc and mcp251xfd). Give the option to the user to deselect this features during compilation. The drivers relying on CAN rx offload are in different sub folders. All of these drivers get tagged with "select CAN_RX_OFFLOAD" so that the option is automatically enabled whenever one of those driver is chosen. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 16 ++++++++++++++++ drivers/net/can/dev/Makefile | 2 ++ drivers/net/can/spi/mcp251xfd/Kconfig | 1 + 3 files changed, 19 insertions(+) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 8f3b97aea638..1f1d81da1c8c 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -102,6 +102,20 @@ config CAN_CALC_BITTIMING If unsure, say Y. +config CAN_RX_OFFLOAD + bool "CAN RX offload" + default y + help + Framework to offload the controller's RX FIFO during one + interrupt. The CAN frames of the FIFO are read and put into a skb + queue during that interrupt and transmitted afterwards in a NAPI + context. + + The additional features selected by this option will be added to the + can-dev module. + + If unsure, say Y. + config CAN_AT91 tristate "Atmel AT91 onchip CAN controller" depends on (ARCH_AT91 || COMPILE_TEST) && HAS_IOMEM @@ -113,6 +127,7 @@ config CAN_FLEXCAN tristate "Support for Freescale FLEXCAN based chips" depends on OF || COLDFIRE || COMPILE_TEST depends on HAS_IOMEM + select CAN_RX_OFFLOAD help Say Y here if you want to support for Freescale FlexCAN. @@ -162,6 +177,7 @@ config CAN_SUN4I config CAN_TI_HECC depends on ARM tristate "TI High End CAN Controller" + select CAN_RX_OFFLOAD help Driver for TI HECC (High End CAN Controller) module found on many TI devices. The device specifications are available from www.ti.com diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index b8a55b1d90cd..5081d8a3be57 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -11,3 +11,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += netlink.o can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o + +can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o diff --git a/drivers/net/can/spi/mcp251xfd/Kconfig b/drivers/net/can/spi/mcp251xfd/Kconfig index dd0fc0a54be1..877e4356010d 100644 --- a/drivers/net/can/spi/mcp251xfd/Kconfig +++ b/drivers/net/can/spi/mcp251xfd/Kconfig @@ -2,6 +2,7 @@ config CAN_MCP251XFD tristate "Microchip MCP251xFD SPI CAN controllers" + select CAN_RX_OFFLOAD select REGMAP select WANT_DEV_COREDUMP help -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v4 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-03 10:28 ` [PATCH v4 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol @ 2022-06-04 11:22 ` Marc Kleine-Budde 2022-06-04 12:14 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 11:22 UTC (permalink / raw) To: Vincent Mailhol Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 4442 bytes --] On 03.06.2022 19:28:45, Vincent Mailhol wrote: > Only a few drivers rely on the CAN rx offload framework (as of the > writing of this patch, only three: flexcan, ti_hecc and > mcp251xfd). Give the option to the user to deselect this features > during compilation. > > The drivers relying on CAN rx offload are in different sub > folders. All of these drivers get tagged with "select CAN_RX_OFFLOAD" > so that the option is automatically enabled whenever one of those > driver is chosen. > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > --- > drivers/net/can/Kconfig | 16 ++++++++++++++++ > drivers/net/can/dev/Makefile | 2 ++ > drivers/net/can/spi/mcp251xfd/Kconfig | 1 + > 3 files changed, 19 insertions(+) > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > index 8f3b97aea638..1f1d81da1c8c 100644 > --- a/drivers/net/can/Kconfig > +++ b/drivers/net/can/Kconfig > @@ -102,6 +102,20 @@ config CAN_CALC_BITTIMING > > If unsure, say Y. > > +config CAN_RX_OFFLOAD > + bool "CAN RX offload" > + default y > + help > + Framework to offload the controller's RX FIFO during one > + interrupt. The CAN frames of the FIFO are read and put into a skb > + queue during that interrupt and transmitted afterwards in a NAPI > + context. > + > + The additional features selected by this option will be added to the > + can-dev module. > + > + If unsure, say Y. > + > config CAN_AT91 > tristate "Atmel AT91 onchip CAN controller" > depends on (ARCH_AT91 || COMPILE_TEST) && HAS_IOMEM > @@ -113,6 +127,7 @@ config CAN_FLEXCAN > tristate "Support for Freescale FLEXCAN based chips" > depends on OF || COLDFIRE || COMPILE_TEST > depends on HAS_IOMEM > + select CAN_RX_OFFLOAD > help > Say Y here if you want to support for Freescale FlexCAN. > > @@ -162,6 +177,7 @@ config CAN_SUN4I > config CAN_TI_HECC > depends on ARM > tristate "TI High End CAN Controller" > + select CAN_RX_OFFLOAD > help > Driver for TI HECC (High End CAN Controller) module found on many > TI devices. The device specifications are available from www.ti.com > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > index b8a55b1d90cd..5081d8a3be57 100644 > --- a/drivers/net/can/dev/Makefile > +++ b/drivers/net/can/dev/Makefile > @@ -11,3 +11,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do you want to remove this? > > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > + > +can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > diff --git a/drivers/net/can/spi/mcp251xfd/Kconfig b/drivers/net/can/spi/mcp251xfd/Kconfig > index dd0fc0a54be1..877e4356010d 100644 > --- a/drivers/net/can/spi/mcp251xfd/Kconfig > +++ b/drivers/net/can/spi/mcp251xfd/Kconfig > @@ -2,6 +2,7 @@ > > config CAN_MCP251XFD > tristate "Microchip MCP251xFD SPI CAN controllers" > + select CAN_RX_OFFLOAD > select REGMAP > select WANT_DEV_COREDUMP > help I remember I've given you a list of drivers needing RX offload, I probably missed the m_can driver. Feel free to squash this patch: --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -8,7 +8,6 @@ can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o can-dev-$(CONFIG_CAN_NETLINK) += netlink.o -can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig index 45ad1b3f0cd0..fc2afab36279 100644 --- a/drivers/net/can/m_can/Kconfig +++ b/drivers/net/can/m_can/Kconfig @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only menuconfig CAN_M_CAN tristate "Bosch M_CAN support" + select CAN_RX_OFFLOAD help Say Y here if you want support for Bosch M_CAN controller framework. This is common support for devices that embed the Bosch M_CAN IP. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v4 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-04 11:22 ` Marc Kleine-Budde @ 2022-06-04 12:14 ` Vincent MAILHOL 0 siblings, 0 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-04 12:14 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sat. 4 June 2022 at 20:22, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 03.06.2022 19:28:45, Vincent Mailhol wrote: > > Only a few drivers rely on the CAN rx offload framework (as of the > > writing of this patch, only three: flexcan, ti_hecc and > > mcp251xfd). Give the option to the user to deselect this features > > during compilation. > > > > The drivers relying on CAN rx offload are in different sub > > folders. All of these drivers get tagged with "select CAN_RX_OFFLOAD" > > so that the option is automatically enabled whenever one of those > > driver is chosen. > > > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > --- > > drivers/net/can/Kconfig | 16 ++++++++++++++++ > > drivers/net/can/dev/Makefile | 2 ++ > > drivers/net/can/spi/mcp251xfd/Kconfig | 1 + > > 3 files changed, 19 insertions(+) > > > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > > index 8f3b97aea638..1f1d81da1c8c 100644 > > --- a/drivers/net/can/Kconfig > > +++ b/drivers/net/can/Kconfig > > @@ -102,6 +102,20 @@ config CAN_CALC_BITTIMING > > > > If unsure, say Y. > > > > +config CAN_RX_OFFLOAD > > + bool "CAN RX offload" > > + default y > > + help > > + Framework to offload the controller's RX FIFO during one > > + interrupt. The CAN frames of the FIFO are read and put into a skb > > + queue during that interrupt and transmitted afterwards in a NAPI > > + context. > > + > > + The additional features selected by this option will be added to the > > + can-dev module. > > + > > + If unsure, say Y. > > + > > config CAN_AT91 > > tristate "Atmel AT91 onchip CAN controller" > > depends on (ARCH_AT91 || COMPILE_TEST) && HAS_IOMEM > > @@ -113,6 +127,7 @@ config CAN_FLEXCAN > > tristate "Support for Freescale FLEXCAN based chips" > > depends on OF || COLDFIRE || COMPILE_TEST > > depends on HAS_IOMEM > > + select CAN_RX_OFFLOAD > > help > > Say Y here if you want to support for Freescale FlexCAN. > > > > @@ -162,6 +177,7 @@ config CAN_SUN4I > > config CAN_TI_HECC > > depends on ARM > > tristate "TI High End CAN Controller" > > + select CAN_RX_OFFLOAD > > help > > Driver for TI HECC (High End CAN Controller) module found on many > > TI devices. The device specifications are available from www.ti.com > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile > > index b8a55b1d90cd..5081d8a3be57 100644 > > --- a/drivers/net/can/dev/Makefile > > +++ b/drivers/net/can/dev/Makefile > > @@ -11,3 +11,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > > can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Do you want to remove this? Absolutely. As you probably guessed, this is just a leftover. > > > > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > + > > +can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o > > diff --git a/drivers/net/can/spi/mcp251xfd/Kconfig b/drivers/net/can/spi/mcp251xfd/Kconfig > > index dd0fc0a54be1..877e4356010d 100644 > > --- a/drivers/net/can/spi/mcp251xfd/Kconfig > > +++ b/drivers/net/can/spi/mcp251xfd/Kconfig > > @@ -2,6 +2,7 @@ > > > > config CAN_MCP251XFD > > tristate "Microchip MCP251xFD SPI CAN controllers" > > + select CAN_RX_OFFLOAD > > select REGMAP > > select WANT_DEV_COREDUMP > > help > > I remember I've given you a list of drivers needing RX offload, I > probably missed the m_can driver. Feel free to squash this patch: Added it to v5. This went through the cracks when testing. Thanks for catching this! > --- a/drivers/net/can/dev/Makefile > +++ b/drivers/net/can/dev/Makefile > @@ -8,7 +8,6 @@ can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o > can-dev-$(CONFIG_CAN_NETLINK) += dev.o > can-dev-$(CONFIG_CAN_NETLINK) += length.o > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o > -can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o > > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o > > diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig > index 45ad1b3f0cd0..fc2afab36279 100644 > --- a/drivers/net/can/m_can/Kconfig > +++ b/drivers/net/can/m_can/Kconfig > @@ -1,6 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0-only > menuconfig CAN_M_CAN > tristate "Bosch M_CAN support" > + select CAN_RX_OFFLOAD > help > Say Y here if you want support for Bosch M_CAN controller framework. > This is common support for devices that embed the Bosch M_CAN IP. > > 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 | ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v4 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol ` (3 preceding siblings ...) 2022-06-03 10:28 ` [PATCH v4 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol ` (2 subsequent siblings) 7 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol The devices are meant to be under the "Device Drivers" category of the menuconfig. The CAN subsystem is currently one of the rare exception with all of its devices under the "Networking support" category. The CAN_DEV menuentry gets moved to fix this discrepancy. The CAN menu is added just before MCTP in order to be consistent with the current order under the "Networking support" menu. A dependency on CAN is added to CAN_DEV so that the CAN devices only show up if the CAN subsystem is enabled. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/Kconfig | 2 ++ drivers/net/can/Kconfig | 1 + net/can/Kconfig | 5 ++--- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index b2a4f998c180..5de243899de8 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -499,6 +499,8 @@ config NET_SB1000 source "drivers/net/phy/Kconfig" +source "drivers/net/can/Kconfig" + source "drivers/net/mctp/Kconfig" source "drivers/net/mdio/Kconfig" diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 1f1d81da1c8c..4ab80507c353 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -3,6 +3,7 @@ menuconfig CAN_DEV tristate "CAN Device Drivers" default y + depends on CAN help Controller Area Network (CAN) is serial communications protocol up to 1Mbit/s for its original release (now known as Classical CAN) and up diff --git a/net/can/Kconfig b/net/can/Kconfig index a9ac5ffab286..cb56be8e3862 100644 --- a/net/can/Kconfig +++ b/net/can/Kconfig @@ -15,7 +15,8 @@ menuconfig CAN PF_CAN is contained in <Documentation/networking/can.rst>. If you want CAN support you should say Y here and also to the - specific driver for your controller(s) below. + specific driver for your controller(s) under the Network device + support section. if CAN @@ -69,6 +70,4 @@ config CAN_ISOTP If you want to perform automotive vehicle diagnostic services (UDS), say 'y'. -source "drivers/net/can/Kconfig" - endif -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v4 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol ` (4 preceding siblings ...) 2022-06-03 10:28 ` [PATCH v4 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol 2022-06-04 11:46 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Marc Kleine-Budde 7 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol The functions can_dropped_invalid_skb() and can_skb_headroom_valid() grew a lot over the years to a point which it does not make much sense to have them defined as static inline in header files. Move those two functions to the .c counterpart of skb.h. can_skb_headroom_valid() only caller being can_dropped_invalid_skb(), the declaration is removed from the header. Only can_dropped_invalid_skb() gets its symbol exported. While doing so, do a small cleanup: add brackets around the else block in can_dropped_invalid_skb(). Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 58 ++++++++++++++++++++++++++++++++++++++ include/linux/can/skb.h | 59 +-------------------------------------- 2 files changed, 59 insertions(+), 58 deletions(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index a4208f125b76..dc9da76c0470 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -259,3 +259,61 @@ struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf) return skb; } EXPORT_SYMBOL_GPL(alloc_can_err_skb); + +/* Check for outgoing skbs that have not been created by the CAN subsystem */ +static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) +{ + /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ + if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) + return false; + + /* af_packet does not apply CAN skb specific settings */ + if (skb->ip_summed == CHECKSUM_NONE) { + /* init headroom */ + can_skb_prv(skb)->ifindex = dev->ifindex; + can_skb_prv(skb)->skbcnt = 0; + + skb->ip_summed = CHECKSUM_UNNECESSARY; + + /* perform proper loopback on capable devices */ + if (dev->flags & IFF_ECHO) + skb->pkt_type = PACKET_LOOPBACK; + else + skb->pkt_type = PACKET_HOST; + + skb_reset_mac_header(skb); + skb_reset_network_header(skb); + skb_reset_transport_header(skb); + } + + return true; +} + +/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) +{ + const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + + if (skb->protocol == htons(ETH_P_CAN)) { + if (unlikely(skb->len != CAN_MTU || + cfd->len > CAN_MAX_DLEN)) + goto inval_skb; + } else if (skb->protocol == htons(ETH_P_CANFD)) { + if (unlikely(skb->len != CANFD_MTU || + cfd->len > CANFD_MAX_DLEN)) + goto inval_skb; + } else { + goto inval_skb; + } + + if (!can_skb_headroom_valid(dev, skb)) + goto inval_skb; + + return false; + +inval_skb: + kfree_skb(skb); + dev->stats.tx_dropped++; + return true; +} +EXPORT_SYMBOL_GPL(can_dropped_invalid_skb); diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index fdb22b00674a..182749e858b3 100644 --- a/include/linux/can/skb.h +++ b/include/linux/can/skb.h @@ -31,6 +31,7 @@ struct sk_buff *alloc_canfd_skb(struct net_device *dev, struct canfd_frame **cfd); struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf); +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb); /* * The struct can_skb_priv is used to transport additional information along @@ -96,64 +97,6 @@ static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb) return nskb; } -/* Check for outgoing skbs that have not been created by the CAN subsystem */ -static inline bool can_skb_headroom_valid(struct net_device *dev, - struct sk_buff *skb) -{ - /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ - if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) - return false; - - /* af_packet does not apply CAN skb specific settings */ - if (skb->ip_summed == CHECKSUM_NONE) { - /* init headroom */ - can_skb_prv(skb)->ifindex = dev->ifindex; - can_skb_prv(skb)->skbcnt = 0; - - skb->ip_summed = CHECKSUM_UNNECESSARY; - - /* perform proper loopback on capable devices */ - if (dev->flags & IFF_ECHO) - skb->pkt_type = PACKET_LOOPBACK; - else - skb->pkt_type = PACKET_HOST; - - skb_reset_mac_header(skb); - skb_reset_network_header(skb); - skb_reset_transport_header(skb); - } - - return true; -} - -/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ -static inline bool can_dropped_invalid_skb(struct net_device *dev, - struct sk_buff *skb) -{ - const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; - - if (skb->protocol == htons(ETH_P_CAN)) { - if (unlikely(skb->len != CAN_MTU || - cfd->len > CAN_MAX_DLEN)) - goto inval_skb; - } else if (skb->protocol == htons(ETH_P_CANFD)) { - if (unlikely(skb->len != CANFD_MTU || - cfd->len > CANFD_MAX_DLEN)) - goto inval_skb; - } else - goto inval_skb; - - if (!can_skb_headroom_valid(dev, skb)) - goto inval_skb; - - return false; - -inval_skb: - kfree_skb(skb); - dev->stats.tx_dropped++; - return true; -} - static inline bool can_is_canfd_skb(const struct sk_buff *skb) { /* the CAN specific type of skb is identified by its data length */ -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v4 7/7] can: skb: drop tx skb if in listen only mode 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol ` (5 preceding siblings ...) 2022-06-03 10:28 ` [PATCH v4 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol @ 2022-06-03 10:28 ` Vincent Mailhol 2022-06-04 11:46 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Marc Kleine-Budde 7 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-03 10:28 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Frames can be directly injected to a can driver via the packet socket. By doing so, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configured in listen only mode. Add a check in can_dropped_invalid_skb() to discard the skb if CAN_CTRLMODE_LISTENONLY is set. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index dc9da76c0470..8bb62dd864c8 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,7 @@ */ #include <linux/can/dev.h> +#include <linux/can/netlink.h> #include <linux/module.h> #define MOD_DESC "CAN device driver interface" @@ -293,6 +294,7 @@ static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) { const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + struct can_priv *priv = netdev_priv(dev); if (skb->protocol == htons(ETH_P_CAN)) { if (unlikely(skb->len != CAN_MTU || @@ -306,8 +308,13 @@ bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) goto inval_skb; } - if (!can_skb_headroom_valid(dev, skb)) + if (!can_skb_headroom_valid(dev, skb)) { + goto inval_skb; + } else if (priv->ctrlmode & CAN_CTRLMODE_LISTENONLY) { + netdev_info_once(dev, + "interface in listen only mode, dropping skb\n"); goto inval_skb; + } return false; -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol ` (6 preceding siblings ...) 2022-06-03 10:28 ` [PATCH v4 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol @ 2022-06-04 11:46 ` Marc Kleine-Budde 2022-06-04 13:05 ` Vincent MAILHOL 7 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 11:46 UTC (permalink / raw) To: Vincent Mailhol Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 6605 bytes --] Hello Vincent, wow! This is a great series which addresses a lot of long outstanding issues. Great work! As this cover letter brings so much additional information I'll ask Jakub and David if they take pull request from me, which itself have merges. This cover letter would be part of my merge. If I get the OK, can you provide this series as a tag (ideally GPG signed) that I can pull? regards, Marc On 03.06.2022 19:28:41, Vincent Mailhol wrote: > Aside of calc_bittiming.o which can be configured with > CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked > unconditionally to can-dev.o even if not needed by the user. > > This series first goal it to split the can-dev modules so that the > user can decide which features get built in during > compilation. Additionally, the CAN Device Drivers menu is moved from > the "Networking support" category to the "Device Drivers" category > (where all drivers are supposed to be). > > Below diagrams illustrate the changes made. > The arrow symbol "x --> y" denotes that "y depends on x". > > * menu before this series * > > CAN bus subsystem support > symbol: CONFIG_CAN > | > +-> CAN Device Drivers > (no symbol) > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> Platform CAN drivers with Netlink support > symbol: CONFIG_CAN_DEV > | > +-> CAN bit-timing calculation (optional for hardware drivers) > | symbol: CONFIG_CAN_BITTIMING > | > +-> All other CAN devices > > * menu after this series * > > Network device support > symbol: CONFIG_NETDEVICES > | > +-> CAN Device Drivers > symbol: CONFIG_CAN_DEV > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> CAN device drivers with Netlink support > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > | > +-> CAN bit-timing calculation (optional for all drivers) > | symbol: CONFIG_CAN_BITTIMING > | > +-> All other CAN devices not relying on RX offload > | > +-> CAN rx offload > symbol: CONFIG_CAN_RX_OFFLOAD > | > +-> CAN devices relying on rx offload > (at time of writing: flexcan, ti_hecc and mcp251xfd) > > Patches 1 to 5 of this series do above modification. > > The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in > can_dropped_invalid_skb() to discard tx skb (such skb can potentially > reach the driver if injected via the packet socket). In more details, > patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch > 7 is the actual change. > > Those last two patches are actually connected to the first five ones: > because slcan and v(x)can requires can_dropped_invalid_skb(), it was > necessary to add those three devices to the scope of can-dev before > moving the function to skb.o. > > > ** N.B. ** > > This design results from the lengthy discussion in [1]. > > I did one change from Oliver's suggestions in [2]. The initial idea > was that the first two config symbols should be respectively > CAN_DEV_SW and CAN_DEV instead of CAN_DEV and CAN_NETLINK as proposed > in this series. > > * First symbol is changed from CAN_DEV_SW to CAN_DEV. The rationale > is that it is this entry that will trigger the build of can-dev.o > and it makes more sense for me to name the symbol share the same > name as the module. Furthermore, this allows to create a menuentry > with an explicit name that will cover both the virtual and > physical devices (naming the menuentry "CAN Device Software" would > be inconsistent with the fact that physical devices would also be > present in a sub menu). And not using menuentry complexifies the > menu. > > * Second symbol is renamed from CAN_DEV to CAN_NETLINK because > CAN_DEV is now taken by the previous menuconfig and netlink is the > predominant feature added at this level. I am opened to other > naming suggestion (CAN_DEV_NETLINK, CAN_DEV_HW...?). > > [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > [2] https://lore.kernel.org/linux-can/22590a57-c7c6-39c6-06d5-11c6e4e1534b@hartkopp.net/ > > > ** Changelog ** > > v3 -> v4: > > * Five additional patches added to split can-dev module and refactor > Kbuild. c.f. below (lengthy) thread: > https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > > > v2 -> v3: > > * Apply can_dropped_invalid_skb() to slcan. > > * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by > modifying Kbuild. > > * fix small typos. > > v1 -> v2: > > * move can_dropped_invalid_skb() to skb.c instead of dev.h > > * also move can_skb_headroom_valid() to skb.c > > Vincent Mailhol (7): > can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK > can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using > CAN_DEV > can: bittiming: move bittiming calculation functions to > calc_bittiming.c > can: Kconfig: add CONFIG_CAN_RX_OFFLOAD > net: Kconfig: move the CAN device menu to the "Device Drivers" section > can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() > to skb.c > can: skb: drop tx skb if in listen only mode > > drivers/net/Kconfig | 2 + > drivers/net/can/Kconfig | 66 +++++++-- > drivers/net/can/dev/Makefile | 20 ++- > drivers/net/can/dev/bittiming.c | 197 ------------------------- > drivers/net/can/dev/calc_bittiming.c | 202 ++++++++++++++++++++++++++ > drivers/net/can/dev/dev.c | 9 +- > drivers/net/can/dev/skb.c | 72 +++++++++ > drivers/net/can/spi/mcp251xfd/Kconfig | 1 + > include/linux/can/skb.h | 59 +------- > net/can/Kconfig | 5 +- > 10 files changed, 351 insertions(+), 282 deletions(-) > create mode 100644 drivers/net/can/dev/calc_bittiming.c > > -- > 2.35.1 > > -- 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 11:46 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Marc Kleine-Budde @ 2022-06-04 13:05 ` Vincent MAILHOL 2022-06-04 13:55 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-04 13:05 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sat. 4 juin 2022 at 20:46, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > Hello Vincent, > > wow! This is a great series which addresses a lot of long outstanding > issues. Great work! Thanks. > As this cover letter brings so much additional information I'll ask > Jakub and David if they take pull request from me, which itself have > merges. This cover letter would be part of my merge. If I get the OK, > can you provide this series as a tag (ideally GPG signed) that I can > pull? Fine, but I need a bit of guidance here. To provide a tag, I need to have my own git repository hosted online, right? Is GitHub OK or should I create one on https://git.kernel.org/? > regards, > Marc > > On 03.06.2022 19:28:41, Vincent Mailhol wrote: > > Aside of calc_bittiming.o which can be configured with > > CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked > > unconditionally to can-dev.o even if not needed by the user. > > > > This series first goal it to split the can-dev modules so that the > > user can decide which features get built in during > > compilation. Additionally, the CAN Device Drivers menu is moved from > > the "Networking support" category to the "Device Drivers" category > > (where all drivers are supposed to be). > > > > Below diagrams illustrate the changes made. > > The arrow symbol "x --> y" denotes that "y depends on x". > > > > * menu before this series * > > > > CAN bus subsystem support > > symbol: CONFIG_CAN > > | > > +-> CAN Device Drivers > > (no symbol) > > | > > +-> software/virtual CAN device drivers > > | (at time of writing: slcan, vcan, vxcan) > > | > > +-> Platform CAN drivers with Netlink support > > symbol: CONFIG_CAN_DEV > > | > > +-> CAN bit-timing calculation (optional for hardware drivers) > > | symbol: CONFIG_CAN_BITTIMING > > | > > +-> All other CAN devices > > > > * menu after this series * > > > > Network device support > > symbol: CONFIG_NETDEVICES > > | > > +-> CAN Device Drivers > > symbol: CONFIG_CAN_DEV > > | > > +-> software/virtual CAN device drivers > > | (at time of writing: slcan, vcan, vxcan) > > | > > +-> CAN device drivers with Netlink support > > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > > | > > +-> CAN bit-timing calculation (optional for all drivers) > > | symbol: CONFIG_CAN_BITTIMING > > | > > +-> All other CAN devices not relying on RX offload > > | > > +-> CAN rx offload > > symbol: CONFIG_CAN_RX_OFFLOAD > > | > > +-> CAN devices relying on rx offload > > (at time of writing: flexcan, ti_hecc and mcp251xfd) > > > > Patches 1 to 5 of this series do above modification. > > > > The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in > > can_dropped_invalid_skb() to discard tx skb (such skb can potentially > > reach the driver if injected via the packet socket). In more details, > > patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch > > 7 is the actual change. > > > > Those last two patches are actually connected to the first five ones: > > because slcan and v(x)can requires can_dropped_invalid_skb(), it was > > necessary to add those three devices to the scope of can-dev before > > moving the function to skb.o. > > > > > > ** N.B. ** > > > > This design results from the lengthy discussion in [1]. > > > > I did one change from Oliver's suggestions in [2]. The initial idea > > was that the first two config symbols should be respectively > > CAN_DEV_SW and CAN_DEV instead of CAN_DEV and CAN_NETLINK as proposed > > in this series. > > > > * First symbol is changed from CAN_DEV_SW to CAN_DEV. The rationale > > is that it is this entry that will trigger the build of can-dev.o > > and it makes more sense for me to name the symbol share the same > > name as the module. Furthermore, this allows to create a menuentry > > with an explicit name that will cover both the virtual and > > physical devices (naming the menuentry "CAN Device Software" would > > be inconsistent with the fact that physical devices would also be > > present in a sub menu). And not using menuentry complexifies the > > menu. > > > > * Second symbol is renamed from CAN_DEV to CAN_NETLINK because > > CAN_DEV is now taken by the previous menuconfig and netlink is the > > predominant feature added at this level. I am opened to other > > naming suggestion (CAN_DEV_NETLINK, CAN_DEV_HW...?). > > > > [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > > [2] https://lore.kernel.org/linux-can/22590a57-c7c6-39c6-06d5-11c6e4e1534b@hartkopp.net/ > > > > > > ** Changelog ** > > > > v3 -> v4: > > > > * Five additional patches added to split can-dev module and refactor > > Kbuild. c.f. below (lengthy) thread: > > https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > > > > > > v2 -> v3: > > > > * Apply can_dropped_invalid_skb() to slcan. > > > > * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by > > modifying Kbuild. > > > > * fix small typos. > > > > v1 -> v2: > > > > * move can_dropped_invalid_skb() to skb.c instead of dev.h > > > > * also move can_skb_headroom_valid() to skb.c > > > > Vincent Mailhol (7): > > can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK > > can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using > > CAN_DEV > > can: bittiming: move bittiming calculation functions to > > calc_bittiming.c > > can: Kconfig: add CONFIG_CAN_RX_OFFLOAD > > net: Kconfig: move the CAN device menu to the "Device Drivers" section > > can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() > > to skb.c > > can: skb: drop tx skb if in listen only mode > > > > drivers/net/Kconfig | 2 + > > drivers/net/can/Kconfig | 66 +++++++-- > > drivers/net/can/dev/Makefile | 20 ++- > > drivers/net/can/dev/bittiming.c | 197 ------------------------- > > drivers/net/can/dev/calc_bittiming.c | 202 ++++++++++++++++++++++++++ > > drivers/net/can/dev/dev.c | 9 +- > > drivers/net/can/dev/skb.c | 72 +++++++++ > > drivers/net/can/spi/mcp251xfd/Kconfig | 1 + > > include/linux/can/skb.h | 59 +------- > > net/can/Kconfig | 5 +- > > 10 files changed, 351 insertions(+), 282 deletions(-) > > create mode 100644 drivers/net/can/dev/calc_bittiming.c > > > > -- > > 2.35.1 > > > > > > -- > 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 | ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 13:05 ` Vincent MAILHOL @ 2022-06-04 13:55 ` Marc Kleine-Budde 2022-06-04 14:59 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 13:55 UTC (permalink / raw) To: Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 1247 bytes --] On 04.06.2022 22:05:09, Vincent MAILHOL wrote: > On Sat. 4 juin 2022 at 20:46, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > Hello Vincent, > > > > wow! This is a great series which addresses a lot of long outstanding > > issues. Great work! > > Thanks. > > > As this cover letter brings so much additional information I'll ask > > Jakub and David if they take pull request from me, which itself have > > merges. This cover letter would be part of my merge. If I get the OK, > > can you provide this series as a tag (ideally GPG signed) that I can > > pull? > > Fine, but I need a bit of guidance here. To provide a tag, I need to > have my own git repository hosted online, right? That is one option. > Is GitHub OK or should I create one on https://git.kernel.org/? Some maintainers don't like github, let's wait what Davem and Jakub say. I think for git.kernel.org you need a GPG key with signatures of 3 users of git.kernel.org. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 13:55 ` Marc Kleine-Budde @ 2022-06-04 14:59 ` Vincent MAILHOL 2022-06-04 15:18 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-04 14:59 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sat. 4 June 2022 at 22:55, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 04.06.2022 22:05:09, Vincent MAILHOL wrote: > > On Sat. 4 juin 2022 at 20:46, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > > Hello Vincent, > > > > > > wow! This is a great series which addresses a lot of long outstanding > > > issues. Great work! > > > > Thanks. > > > > > As this cover letter brings so much additional information I'll ask > > > Jakub and David if they take pull request from me, which itself have > > > merges. This cover letter would be part of my merge. If I get the OK, > > > can you provide this series as a tag (ideally GPG signed) that I can > > > pull? > > > > Fine, but I need a bit of guidance here. To provide a tag, I need to > > have my own git repository hosted online, right? > > That is one option. This suggests that there are other options? What would be those other options? > > Is GitHub OK or should I create one on https://git.kernel.org/? > > Some maintainers don't like github, let's wait what Davem and Jakub say. > I think for git.kernel.org you need a GPG key with signatures of 3 users > of git.kernel.org. Personally, I would also prefer getting my own git.kernel.org account. It has infinitely more swag than GitHub. But my religion does not forbid me from using GitHub :) Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 14:59 ` Vincent MAILHOL @ 2022-06-04 15:18 ` Marc Kleine-Budde 2022-06-04 16:32 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-04 15:18 UTC (permalink / raw) To: Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 1177 bytes --] On 04.06.2022 23:59:48, Vincent MAILHOL wrote: > > > Fine, but I need a bit of guidance here. To provide a tag, I need to > > > have my own git repository hosted online, right? > > > > That is one option. > > This suggests that there are other options? What would be those other > options? 2. git.kernel.org (most preferred) 3. github.com (have to ask Davem/Jakub) > > > Is GitHub OK or should I create one on https://git.kernel.org/? > > > > Some maintainers don't like github, let's wait what Davem and Jakub say. > > I think for git.kernel.org you need a GPG key with signatures of 3 users > > of git.kernel.org. > > Personally, I would also prefer getting my own git.kernel.org account. See https://korg.docs.kernel.org/accounts.html > It has infinitely more swag than GitHub. Definitively! > But my religion does not forbid me from using GitHub :) 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 15:18 ` Marc Kleine-Budde @ 2022-06-04 16:32 ` Vincent MAILHOL 2022-06-05 10:39 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-04 16:32 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sun. 5 juin 2022 at 00:18, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 04.06.2022 23:59:48, Vincent MAILHOL wrote: > > > > Fine, but I need a bit of guidance here. To provide a tag, I need to > > > > have my own git repository hosted online, right? > > > > > > That is one option. > > > > This suggests that there are other options? What would be those other > > options? > > 2. git.kernel.org (most preferred) > 3. github.com (have to ask Davem/Jakub) > > > > > Is GitHub OK or should I create one on https://git.kernel.org/? > > > > > > Some maintainers don't like github, let's wait what Davem and Jakub say. > > > I think for git.kernel.org you need a GPG key with signatures of 3 users > > > of git.kernel.org. > > > > Personally, I would also prefer getting my own git.kernel.org account. > > See https://korg.docs.kernel.org/accounts.html Thanks for the link. I will have a look at it tomorrow (or the day after tomorrow in the worst case). Meanwhile, I will send the v5 which should address all your comments. Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 16:32 ` Vincent MAILHOL @ 2022-06-05 10:39 ` Marc Kleine-Budde 2022-06-05 13:57 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-05 10:39 UTC (permalink / raw) To: Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 1735 bytes --] On 05.06.2022 01:32:15, Vincent MAILHOL wrote: > On Sun. 5 juin 2022 at 00:18, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > On 04.06.2022 23:59:48, Vincent MAILHOL wrote: > > > > > Fine, but I need a bit of guidance here. To provide a tag, I need to > > > > > have my own git repository hosted online, right? > > > > > > > > That is one option. > > > > > > This suggests that there are other options? What would be those other > > > options? > > > > 2. git.kernel.org (most preferred) > > 3. github.com (have to ask Davem/Jakub) > > > > > > > Is GitHub OK or should I create one on https://git.kernel.org/? > > > > > > > > Some maintainers don't like github, let's wait what Davem and Jakub say. > > > > I think for git.kernel.org you need a GPG key with signatures of 3 users > > > > of git.kernel.org. > > > > > > Personally, I would also prefer getting my own git.kernel.org account. > > > > See https://korg.docs.kernel.org/accounts.html > > Thanks for the link. I will have a look at it tomorrow (or the day > after tomorrow in the worst case). > > Meanwhile, I will send the v5 which should address all your comments. /me just realized that merged are independent of pull requests. I can create a local branch and merge it, as Davem and Jakub do it. I've added your v5 to can-next/master as a merge and I'll include this in my next PR to net-next if Davem and Jakub are OK with merges in my branch. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-05 10:39 ` Marc Kleine-Budde @ 2022-06-05 13:57 ` Vincent MAILHOL 2022-06-05 18:08 ` Marc Kleine-Budde 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-05 13:57 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev On Sun. 5 juin 2022 at 19:39, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 05.06.2022 01:32:15, Vincent MAILHOL wrote: > > On Sun. 5 juin 2022 at 00:18, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > > On 04.06.2022 23:59:48, Vincent MAILHOL wrote: > > > > > > Fine, but I need a bit of guidance here. To provide a tag, I need to > > > > > > have my own git repository hosted online, right? > > > > > > > > > > That is one option. > > > > > > > > This suggests that there are other options? What would be those other > > > > options? > > > > > > 2. git.kernel.org (most preferred) > > > 3. github.com (have to ask Davem/Jakub) > > > > > > > > > Is GitHub OK or should I create one on https://git.kernel.org/? > > > > > > > > > > Some maintainers don't like github, let's wait what Davem and Jakub say. > > > > > I think for git.kernel.org you need a GPG key with signatures of 3 users > > > > > of git.kernel.org. > > > > > > > > Personally, I would also prefer getting my own git.kernel.org account. > > > > > > See https://korg.docs.kernel.org/accounts.html > > > > Thanks for the link. I will have a look at it tomorrow (or the day > > after tomorrow in the worst case). > > > > Meanwhile, I will send the v5 which should address all your comments. > > /me just realized that merged are independent of pull requests. I can > create a local branch and merge it, as Davem and Jakub do it. I've added > your v5 to can-next/master as a merge and I'll include this in my next > PR to net-next if Davem and Jakub are OK with merges in my branch. So my dreams of getting my kernel.org account swag just evaporated (just kidding :)) I think I will prepare a GPG key just to be ready in the opportunity to get it signed pop-up one day. Happy to see that this is reaching an end. Honestly speaking, the menuconfig cleanup was not my most exciting contribution (euphemism) but was still a necessity. Glad that this is nearly over after more than 80 messages in the full thread (including all five versions). If I recall correctly, this is the longest thread we had in the last two years. And thanks again to Max, Oliver and you for animating the debate! Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-05 13:57 ` Vincent MAILHOL @ 2022-06-05 18:08 ` Marc Kleine-Budde 0 siblings, 0 replies; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-05 18:08 UTC (permalink / raw) To: Vincent MAILHOL Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 1387 bytes --] On 05.06.2022 22:57:03, Vincent MAILHOL wrote: > > /me just realized that merged are independent of pull requests. I can > > create a local branch and merge it, as Davem and Jakub do it. I've added > > your v5 to can-next/master as a merge and I'll include this in my next > > PR to net-next if Davem and Jakub are OK with merges in my branch. > > So my dreams of getting my kernel.org account swag just evaporated > (just kidding :)) No! > I think I will prepare a GPG key just to be ready in the opportunity > to get it signed pop-up one day. > > Happy to see that this is reaching an end. Honestly speaking, the > menuconfig cleanup was not my most exciting contribution (euphemism) > but was still a necessity. Thanks for the persistence! > Glad that this is nearly over after more > than 80 messages in the full thread (including all five versions). If > I recall correctly, this is the longest thread we had in the last two > years. And thanks again to Max, Oliver and you for animating the > debate! So the longest-thread-badge goes definitely to you! Thanks again, 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol ` (5 preceding siblings ...) 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol @ 2022-06-04 16:29 ` Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol ` (8 more replies) 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol 7 siblings, 9 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:29 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Aside of calc_bittiming.o which can be configured with CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked unconditionally to can-dev.o even if not needed by the user. This series first goal it to split the can-dev modules so that the user can decide which features get built in during compilation. Additionally, the CAN Device Drivers menu is moved from the "Networking support" category to the "Device Drivers" category (where all drivers are supposed to be). Below diagrams illustrate the changes made. The arrow symbol "x --> y" denotes that "y depends on x". * menu before this series * CAN bus subsystem support symbol: CONFIG_CAN | +-> CAN Device Drivers (no symbol) | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> Platform CAN drivers with Netlink support symbol: CONFIG_CAN_DEV | +-> CAN bit-timing calculation (optional for hardware drivers) | symbol: CONFIG_CAN_BITTIMING | +-> All other CAN devices * menu after this series * Network device support symbol: CONFIG_NETDEVICES | +-> CAN Device Drivers symbol: CONFIG_CAN_DEV | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> CAN device drivers with Netlink support symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) | +-> CAN bit-timing calculation (optional for all drivers) | symbol: CONFIG_CAN_BITTIMING | +-> All other CAN devices not relying on RX offload | +-> CAN rx offload symbol: CONFIG_CAN_RX_OFFLOAD | +-> CAN devices relying on rx offload (at time of writing: flexcan, m_can, mcp251xfd and ti_hecc) Patches 1 to 5 of this series do above modification. The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard tx skb (such skb can potentially reach the driver if injected via the packet socket). In more details, patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch 7 is the actual change. Those last two patches are actually connected to the first five ones: because slcan and v(x)can requires can_dropped_invalid_skb(), it was necessary to add those three devices to the scope of can-dev before moving the function to skb.o. This design results from the lengthy discussion in [1]. [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ ** Changelog ** v4 -> v5: * m_can is also requires RX offload. Add the "select CAN_RX_OFFLOAD" to its Makefile. * Reorder the lines of drivers/net/can/dev/Makefile. * Remove duplicated rx-offload.o target in drivers/net/can/dev/Makefile * Remove the Nota Bene in the cover letter. v3 -> v4: * Five additional patches added to split can-dev module and refactor Kbuild. c.f. below (lengthy) thread: https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ v2 -> v3: * Apply can_dropped_invalid_skb() to slcan. * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by modifying Kbuild. * fix small typos. v1 -> v2: * move can_dropped_invalid_skb() to skb.c instead of dev.h * also move can_skb_headroom_valid() to skb.c Vincent Mailhol (7): can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV can: bittiming: move bittiming calculation functions to calc_bittiming.c can: Kconfig: add CONFIG_CAN_RX_OFFLOAD net: Kconfig: move the CAN device menu to the "Device Drivers" section can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c can: skb: drop tx skb if in listen only mode drivers/net/Kconfig | 2 + drivers/net/can/Kconfig | 66 +++++++-- drivers/net/can/dev/Makefile | 17 ++- drivers/net/can/dev/bittiming.c | 197 ------------------------- drivers/net/can/dev/calc_bittiming.c | 202 ++++++++++++++++++++++++++ drivers/net/can/dev/dev.c | 9 +- drivers/net/can/dev/skb.c | 72 +++++++++ drivers/net/can/m_can/Kconfig | 1 + drivers/net/can/spi/mcp251xfd/Kconfig | 1 + include/linux/can/skb.h | 59 +------- net/can/Kconfig | 5 +- 11 files changed, 349 insertions(+), 282 deletions(-) create mode 100644 drivers/net/can/dev/calc_bittiming.c -- 2.35.1 ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v5 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol @ 2022-06-04 16:29 ` Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol ` (7 subsequent siblings) 8 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:29 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol In the next patches, the scope of the can-dev module will grow to engloble the software/virtual drivers (slcan, v(x)can). To this extent, release CAN_DEV by renaming it into CAN_NETLINK. The config symbol CAN_DEV will be reused to cover this extended scope. The rationale for the name CAN_NETLINK is that netlink is the predominant feature added here. The current description only mentions platform drivers despite the fact that this symbol is also required by "normal" devices (e.g. USB or PCI) which do not fall under the platform devices category. The description is updated accordingly to fix this gap. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- Please share if you have any suggestion on the name. I hesitated a lot between CAN_NETLINK or CAN_DEV_NETLINK (because netlink is the predominant feature) and CAN_DEV_HW (because this targets the non-software only drivers, i.e. the hardware ones). --- drivers/net/can/Kconfig | 18 +++++++++++------- drivers/net/can/dev/Makefile | 2 +- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index b2dcc1e5a388..99f189ad35ad 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -48,15 +48,19 @@ config CAN_SLCAN can be changed by the 'maxdev=xx' module option. This driver can also be built as a module. If so, the module will be called slcan. -config CAN_DEV - tristate "Platform CAN drivers with Netlink support" +config CAN_NETLINK + tristate "CAN device drivers with Netlink support" default y help - Enables the common framework for platform CAN drivers with Netlink - support. This is the standard library for CAN drivers. - If unsure, say Y. + Enables the common framework for CAN device drivers. This is the + standard library and provides features for the Netlink interface such + as bittiming validation, support of CAN error states, device restart + and others. + + This is required by all platform and hardware CAN drivers. If you + plan to use such devices or if unsure, say Y. -if CAN_DEV +if CAN_NETLINK config CAN_CALC_BITTIMING bool "CAN bit-timing calculation" @@ -164,7 +168,7 @@ source "drivers/net/can/softing/Kconfig" source "drivers/net/can/spi/Kconfig" source "drivers/net/can/usb/Kconfig" -endif +endif #CAN_NETLINK config CAN_DEBUG_DEVICES bool "CAN devices debugging messages" diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index af2901db473c..5b4c813c6222 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_CAN_DEV) += can-dev.o +obj-$(CONFIG_CAN_NETLINK) += can-dev.o can-dev-y += bittiming.o can-dev-y += dev.o can-dev-y += length.o -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v5 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol @ 2022-06-04 16:29 ` Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol ` (6 subsequent siblings) 8 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:29 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol In the next patches, the software/virtual drivers (slcan, v(x)can) will depend on drivers/net/can/dev/skb.o. This patch changes the scope of the can-dev module to include the above mentioned drivers. To do so, we reuse the menu "CAN Device Drivers" and turn it into a configmenu using the config symbol CAN_DEV (which we released in previous patch). Also, add a description to this new CAN_DEV menuconfig. The symbol CAN_DEV now only triggers the build of skb.o. For this reasons, all the macros from linux/module.h are deported from drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c. Finally, drivers/net/can/dev/Makefile is adjusted accordingly. Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 29 ++++++++++++++++++++++++++--- drivers/net/can/dev/Makefile | 16 +++++++++------- drivers/net/can/dev/dev.c | 9 +-------- drivers/net/can/dev/skb.c | 7 +++++++ 4 files changed, 43 insertions(+), 18 deletions(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 99f189ad35ad..3c692af16676 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -1,5 +1,25 @@ # SPDX-License-Identifier: GPL-2.0-only -menu "CAN Device Drivers" + +menuconfig CAN_DEV + tristate "CAN Device Drivers" + default y + help + Controller Area Network (CAN) is serial communications protocol up to + 1Mbit/s for its original release (now known as Classical CAN) and up + to 8Mbit/s for the more recent CAN with Flexible Data-Rate + (CAN-FD). The CAN bus was originally mainly for automotive, but is now + widely used in marine (NMEA2000), industrial, and medical + applications. More information on the CAN network protocol family + PF_CAN is contained in <Documentation/networking/can.rst>. + + This section contains all the CAN(-FD) device drivers including the + virtual ones. If you own such devices or plan to use the virtual CAN + interfaces to develop applications, say Y here. + + To compile as a module, choose M here: the module will be called + can-dev. + +if CAN_DEV config CAN_VCAN tristate "Virtual Local CAN Interface (vcan)" @@ -49,7 +69,7 @@ config CAN_SLCAN also be built as a module. If so, the module will be called slcan. config CAN_NETLINK - tristate "CAN device drivers with Netlink support" + bool "CAN device drivers with Netlink support" default y help Enables the common framework for CAN device drivers. This is the @@ -57,6 +77,9 @@ config CAN_NETLINK as bittiming validation, support of CAN error states, device restart and others. + The additional features selected by this option will be added to the + can-dev module. + This is required by all platform and hardware CAN drivers. If you plan to use such devices or if unsure, say Y. @@ -178,4 +201,4 @@ config CAN_DEBUG_DEVICES a problem with CAN support and want to see more of what is going on. -endmenu +endif #CAN_DEV diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 5b4c813c6222..1baaf7020f7c 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -1,9 +1,11 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_CAN_NETLINK) += can-dev.o -can-dev-y += bittiming.o -can-dev-y += dev.o -can-dev-y += length.o -can-dev-y += netlink.o -can-dev-y += rx-offload.o -can-dev-y += skb.o +obj-$(CONFIG_CAN_DEV) += can-dev.o + +can-dev-y += skb.o + +can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o +can-dev-$(CONFIG_CAN_NETLINK) += dev.o +can-dev-$(CONFIG_CAN_NETLINK) += length.o +can-dev-$(CONFIG_CAN_NETLINK) += netlink.o +can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c index 96c9d9db00cf..523eaacfe29e 100644 --- a/drivers/net/can/dev/dev.c +++ b/drivers/net/can/dev/dev.c @@ -4,7 +4,6 @@ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> */ -#include <linux/module.h> #include <linux/kernel.h> #include <linux/slab.h> #include <linux/netdevice.h> @@ -17,12 +16,6 @@ #include <linux/gpio/consumer.h> #include <linux/of.h> -#define MOD_DESC "CAN device driver interface" - -MODULE_DESCRIPTION(MOD_DESC); -MODULE_LICENSE("GPL v2"); -MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>"); - static void can_update_state_error_stats(struct net_device *dev, enum can_state new_state) { @@ -513,7 +506,7 @@ static __init int can_dev_init(void) err = can_netlink_register(); if (!err) - pr_info(MOD_DESC "\n"); + pr_info("CAN device driver interface\n"); return err; } diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index 61660248c69e..a4208f125b76 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,13 @@ */ #include <linux/can/dev.h> +#include <linux/module.h> + +#define MOD_DESC "CAN device driver interface" + +MODULE_DESCRIPTION(MOD_DESC); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>"); /* Local echo of CAN messages * -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v5 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol @ 2022-06-04 16:29 ` Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol ` (5 subsequent siblings) 8 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:29 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol The canonical way to select or deselect an object during compilation is to use this pattern in the relevant Makefile: bar-$(CONFIG_FOO) := foo.o bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. Create a new file named calc_bittiming.c with all the functions which are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the Makefile according to above pattern. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 4 + drivers/net/can/dev/Makefile | 1 + drivers/net/can/dev/bittiming.c | 197 -------------------------- drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++ 4 files changed, 207 insertions(+), 197 deletions(-) create mode 100644 drivers/net/can/dev/calc_bittiming.c diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 3c692af16676..87470feae6b1 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING source clock frequencies. Disabling saves some space, but then the bit-timing parameters must be specified directly using the Netlink arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw". + + The additional features selected by this option will be added to the + can-dev module. + If unsure, say Y. config CAN_AT91 diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 1baaf7020f7c..791e6b297ea3 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_CAN_DEV) += can-dev.o can-dev-y += skb.o +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o diff --git a/drivers/net/can/dev/bittiming.c b/drivers/net/can/dev/bittiming.c index c1e76f0a5064..7ae80763c960 100644 --- a/drivers/net/can/dev/bittiming.c +++ b/drivers/net/can/dev/bittiming.c @@ -4,205 +4,8 @@ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> */ -#include <linux/units.h> #include <linux/can/dev.h> -#ifdef CONFIG_CAN_CALC_BITTIMING -#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */ - -/* Bit-timing calculation derived from: - * - * Code based on LinCAN sources and H8S2638 project - * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz - * Copyright 2005 Stanislav Marek - * email: pisa@cmp.felk.cvut.cz - * - * Calculates proper bit-timing parameters for a specified bit-rate - * and sample-point, which can then be used to set the bit-timing - * registers of the CAN controller. You can find more information - * in the header file linux/can/netlink.h. - */ -static int -can_update_sample_point(const struct can_bittiming_const *btc, - const unsigned int sample_point_nominal, const unsigned int tseg, - unsigned int *tseg1_ptr, unsigned int *tseg2_ptr, - unsigned int *sample_point_error_ptr) -{ - unsigned int sample_point_error, best_sample_point_error = UINT_MAX; - unsigned int sample_point, best_sample_point = 0; - unsigned int tseg1, tseg2; - int i; - - for (i = 0; i <= 1; i++) { - tseg2 = tseg + CAN_SYNC_SEG - - (sample_point_nominal * (tseg + CAN_SYNC_SEG)) / - 1000 - i; - tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max); - tseg1 = tseg - tseg2; - if (tseg1 > btc->tseg1_max) { - tseg1 = btc->tseg1_max; - tseg2 = tseg - tseg1; - } - - sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) / - (tseg + CAN_SYNC_SEG); - sample_point_error = abs(sample_point_nominal - sample_point); - - if (sample_point <= sample_point_nominal && - sample_point_error < best_sample_point_error) { - best_sample_point = sample_point; - best_sample_point_error = sample_point_error; - *tseg1_ptr = tseg1; - *tseg2_ptr = tseg2; - } - } - - if (sample_point_error_ptr) - *sample_point_error_ptr = best_sample_point_error; - - return best_sample_point; -} - -int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt, - const struct can_bittiming_const *btc) -{ - struct can_priv *priv = netdev_priv(dev); - unsigned int bitrate; /* current bitrate */ - unsigned int bitrate_error; /* difference between current and nominal value */ - unsigned int best_bitrate_error = UINT_MAX; - unsigned int sample_point_error; /* difference between current and nominal value */ - unsigned int best_sample_point_error = UINT_MAX; - unsigned int sample_point_nominal; /* nominal sample point */ - unsigned int best_tseg = 0; /* current best value for tseg */ - unsigned int best_brp = 0; /* current best value for brp */ - unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0; - u64 v64; - - /* Use CiA recommended sample points */ - if (bt->sample_point) { - sample_point_nominal = bt->sample_point; - } else { - if (bt->bitrate > 800 * KILO /* BPS */) - sample_point_nominal = 750; - else if (bt->bitrate > 500 * KILO /* BPS */) - sample_point_nominal = 800; - else - sample_point_nominal = 875; - } - - /* tseg even = round down, odd = round up */ - for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1; - tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) { - tsegall = CAN_SYNC_SEG + tseg / 2; - - /* Compute all possible tseg choices (tseg=tseg1+tseg2) */ - brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2; - - /* choose brp step which is possible in system */ - brp = (brp / btc->brp_inc) * btc->brp_inc; - if (brp < btc->brp_min || brp > btc->brp_max) - continue; - - bitrate = priv->clock.freq / (brp * tsegall); - bitrate_error = abs(bt->bitrate - bitrate); - - /* tseg brp biterror */ - if (bitrate_error > best_bitrate_error) - continue; - - /* reset sample point error if we have a better bitrate */ - if (bitrate_error < best_bitrate_error) - best_sample_point_error = UINT_MAX; - - can_update_sample_point(btc, sample_point_nominal, tseg / 2, - &tseg1, &tseg2, &sample_point_error); - if (sample_point_error >= best_sample_point_error) - continue; - - best_sample_point_error = sample_point_error; - best_bitrate_error = bitrate_error; - best_tseg = tseg / 2; - best_brp = brp; - - if (bitrate_error == 0 && sample_point_error == 0) - break; - } - - if (best_bitrate_error) { - /* Error in one-tenth of a percent */ - v64 = (u64)best_bitrate_error * 1000; - do_div(v64, bt->bitrate); - bitrate_error = (u32)v64; - if (bitrate_error > CAN_CALC_MAX_ERROR) { - netdev_err(dev, - "bitrate error %d.%d%% too high\n", - bitrate_error / 10, bitrate_error % 10); - return -EDOM; - } - netdev_warn(dev, "bitrate error %d.%d%%\n", - bitrate_error / 10, bitrate_error % 10); - } - - /* real sample point */ - bt->sample_point = can_update_sample_point(btc, sample_point_nominal, - best_tseg, &tseg1, &tseg2, - NULL); - - v64 = (u64)best_brp * 1000 * 1000 * 1000; - do_div(v64, priv->clock.freq); - bt->tq = (u32)v64; - bt->prop_seg = tseg1 / 2; - bt->phase_seg1 = tseg1 - bt->prop_seg; - bt->phase_seg2 = tseg2; - - /* check for sjw user settings */ - if (!bt->sjw || !btc->sjw_max) { - bt->sjw = 1; - } else { - /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */ - if (bt->sjw > btc->sjw_max) - bt->sjw = btc->sjw_max; - /* bt->sjw must not be higher than tseg2 */ - if (tseg2 < bt->sjw) - bt->sjw = tseg2; - } - - bt->brp = best_brp; - - /* real bitrate */ - bt->bitrate = priv->clock.freq / - (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2)); - - return 0; -} - -void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const, - const struct can_bittiming *dbt, - u32 *ctrlmode, u32 ctrlmode_supported) - -{ - if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO)) - return; - - *ctrlmode &= ~CAN_CTRLMODE_TDC_MASK; - - /* As specified in ISO 11898-1 section 11.3.3 "Transmitter - * delay compensation" (TDC) is only applicable if data BRP is - * one or two. - */ - if (dbt->brp == 1 || dbt->brp == 2) { - /* Sample point in clock periods */ - u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg + - dbt->phase_seg1) * dbt->brp; - - if (sample_point_in_tc < tdc_const->tdco_min) - return; - tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max); - *ctrlmode |= CAN_CTRLMODE_TDC_AUTO; - } -} -#endif /* CONFIG_CAN_CALC_BITTIMING */ - /* Checks the validity of the specified bit-timing parameters prop_seg, * phase_seg1, phase_seg2 and sjw and tries to determine the bitrate * prescaler value brp. You can find more information in the header diff --git a/drivers/net/can/dev/calc_bittiming.c b/drivers/net/can/dev/calc_bittiming.c new file mode 100644 index 000000000000..d3caa040614d --- /dev/null +++ b/drivers/net/can/dev/calc_bittiming.c @@ -0,0 +1,202 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* Copyright (C) 2005 Marc Kleine-Budde, Pengutronix + * Copyright (C) 2006 Andrey Volkov, Varma Electronics + * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> + */ + +#include <linux/units.h> +#include <linux/can/dev.h> + +#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */ + +/* Bit-timing calculation derived from: + * + * Code based on LinCAN sources and H8S2638 project + * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz + * Copyright 2005 Stanislav Marek + * email: pisa@cmp.felk.cvut.cz + * + * Calculates proper bit-timing parameters for a specified bit-rate + * and sample-point, which can then be used to set the bit-timing + * registers of the CAN controller. You can find more information + * in the header file linux/can/netlink.h. + */ +static int +can_update_sample_point(const struct can_bittiming_const *btc, + const unsigned int sample_point_nominal, const unsigned int tseg, + unsigned int *tseg1_ptr, unsigned int *tseg2_ptr, + unsigned int *sample_point_error_ptr) +{ + unsigned int sample_point_error, best_sample_point_error = UINT_MAX; + unsigned int sample_point, best_sample_point = 0; + unsigned int tseg1, tseg2; + int i; + + for (i = 0; i <= 1; i++) { + tseg2 = tseg + CAN_SYNC_SEG - + (sample_point_nominal * (tseg + CAN_SYNC_SEG)) / + 1000 - i; + tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max); + tseg1 = tseg - tseg2; + if (tseg1 > btc->tseg1_max) { + tseg1 = btc->tseg1_max; + tseg2 = tseg - tseg1; + } + + sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) / + (tseg + CAN_SYNC_SEG); + sample_point_error = abs(sample_point_nominal - sample_point); + + if (sample_point <= sample_point_nominal && + sample_point_error < best_sample_point_error) { + best_sample_point = sample_point; + best_sample_point_error = sample_point_error; + *tseg1_ptr = tseg1; + *tseg2_ptr = tseg2; + } + } + + if (sample_point_error_ptr) + *sample_point_error_ptr = best_sample_point_error; + + return best_sample_point; +} + +int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt, + const struct can_bittiming_const *btc) +{ + struct can_priv *priv = netdev_priv(dev); + unsigned int bitrate; /* current bitrate */ + unsigned int bitrate_error; /* difference between current and nominal value */ + unsigned int best_bitrate_error = UINT_MAX; + unsigned int sample_point_error; /* difference between current and nominal value */ + unsigned int best_sample_point_error = UINT_MAX; + unsigned int sample_point_nominal; /* nominal sample point */ + unsigned int best_tseg = 0; /* current best value for tseg */ + unsigned int best_brp = 0; /* current best value for brp */ + unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0; + u64 v64; + + /* Use CiA recommended sample points */ + if (bt->sample_point) { + sample_point_nominal = bt->sample_point; + } else { + if (bt->bitrate > 800 * KILO /* BPS */) + sample_point_nominal = 750; + else if (bt->bitrate > 500 * KILO /* BPS */) + sample_point_nominal = 800; + else + sample_point_nominal = 875; + } + + /* tseg even = round down, odd = round up */ + for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1; + tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) { + tsegall = CAN_SYNC_SEG + tseg / 2; + + /* Compute all possible tseg choices (tseg=tseg1+tseg2) */ + brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2; + + /* choose brp step which is possible in system */ + brp = (brp / btc->brp_inc) * btc->brp_inc; + if (brp < btc->brp_min || brp > btc->brp_max) + continue; + + bitrate = priv->clock.freq / (brp * tsegall); + bitrate_error = abs(bt->bitrate - bitrate); + + /* tseg brp biterror */ + if (bitrate_error > best_bitrate_error) + continue; + + /* reset sample point error if we have a better bitrate */ + if (bitrate_error < best_bitrate_error) + best_sample_point_error = UINT_MAX; + + can_update_sample_point(btc, sample_point_nominal, tseg / 2, + &tseg1, &tseg2, &sample_point_error); + if (sample_point_error >= best_sample_point_error) + continue; + + best_sample_point_error = sample_point_error; + best_bitrate_error = bitrate_error; + best_tseg = tseg / 2; + best_brp = brp; + + if (bitrate_error == 0 && sample_point_error == 0) + break; + } + + if (best_bitrate_error) { + /* Error in one-tenth of a percent */ + v64 = (u64)best_bitrate_error * 1000; + do_div(v64, bt->bitrate); + bitrate_error = (u32)v64; + if (bitrate_error > CAN_CALC_MAX_ERROR) { + netdev_err(dev, + "bitrate error %d.%d%% too high\n", + bitrate_error / 10, bitrate_error % 10); + return -EDOM; + } + netdev_warn(dev, "bitrate error %d.%d%%\n", + bitrate_error / 10, bitrate_error % 10); + } + + /* real sample point */ + bt->sample_point = can_update_sample_point(btc, sample_point_nominal, + best_tseg, &tseg1, &tseg2, + NULL); + + v64 = (u64)best_brp * 1000 * 1000 * 1000; + do_div(v64, priv->clock.freq); + bt->tq = (u32)v64; + bt->prop_seg = tseg1 / 2; + bt->phase_seg1 = tseg1 - bt->prop_seg; + bt->phase_seg2 = tseg2; + + /* check for sjw user settings */ + if (!bt->sjw || !btc->sjw_max) { + bt->sjw = 1; + } else { + /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */ + if (bt->sjw > btc->sjw_max) + bt->sjw = btc->sjw_max; + /* bt->sjw must not be higher than tseg2 */ + if (tseg2 < bt->sjw) + bt->sjw = tseg2; + } + + bt->brp = best_brp; + + /* real bitrate */ + bt->bitrate = priv->clock.freq / + (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2)); + + return 0; +} + +void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const, + const struct can_bittiming *dbt, + u32 *ctrlmode, u32 ctrlmode_supported) + +{ + if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO)) + return; + + *ctrlmode &= ~CAN_CTRLMODE_TDC_MASK; + + /* As specified in ISO 11898-1 section 11.3.3 "Transmitter + * delay compensation" (TDC) is only applicable if data BRP is + * one or two. + */ + if (dbt->brp == 1 || dbt->brp == 2) { + /* Sample point in clock periods */ + u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg + + dbt->phase_seg1) * dbt->brp; + + if (sample_point_in_tc < tdc_const->tdco_min) + return; + tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max); + *ctrlmode |= CAN_CTRLMODE_TDC_AUTO; + } +} -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol ` (2 preceding siblings ...) 2022-06-04 16:29 ` [PATCH v5 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol @ 2022-06-04 16:29 ` Vincent Mailhol 2022-06-07 8:43 ` Geert Uytterhoeven 2022-06-04 16:29 ` [PATCH v5 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol ` (4 subsequent siblings) 8 siblings, 1 reply; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:29 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Only a few drivers rely on the CAN rx offload framework (as of the writing of this patch, only four: flexcan, m_can, mcp251xfd and ti_hecc). Give the option to the user to deselect this features during compilation. The drivers relying on CAN rx offload are in different sub folders. All of these drivers get tagged with "select CAN_RX_OFFLOAD" so that the option is automatically enabled whenever one of those driver is chosen. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 16 ++++++++++++++++ drivers/net/can/dev/Makefile | 2 +- drivers/net/can/m_can/Kconfig | 1 + drivers/net/can/spi/mcp251xfd/Kconfig | 1 + 4 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 87470feae6b1..91e4af727d1f 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -102,6 +102,20 @@ config CAN_CALC_BITTIMING If unsure, say Y. +config CAN_RX_OFFLOAD + bool "CAN RX offload" + default y + help + Framework to offload the controller's RX FIFO during one + interrupt. The CAN frames of the FIFO are read and put into a skb + queue during that interrupt and transmitted afterwards in a NAPI + context. + + The additional features selected by this option will be added to the + can-dev module. + + If unsure, say Y. + config CAN_AT91 tristate "Atmel AT91 onchip CAN controller" depends on (ARCH_AT91 || COMPILE_TEST) && HAS_IOMEM @@ -113,6 +127,7 @@ config CAN_FLEXCAN tristate "Support for Freescale FLEXCAN based chips" depends on OF || COLDFIRE || COMPILE_TEST depends on HAS_IOMEM + select CAN_RX_OFFLOAD help Say Y here if you want to support for Freescale FlexCAN. @@ -162,6 +177,7 @@ config CAN_SUN4I config CAN_TI_HECC depends on ARM tristate "TI High End CAN Controller" + select CAN_RX_OFFLOAD help Driver for TI HECC (High End CAN Controller) module found on many TI devices. The device specifications are available from www.ti.com diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 791e6b297ea3..633687d6b6c0 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -9,4 +9,4 @@ can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o can-dev-$(CONFIG_CAN_NETLINK) += netlink.o -can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o +can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig index 45ad1b3f0cd0..fc2afab36279 100644 --- a/drivers/net/can/m_can/Kconfig +++ b/drivers/net/can/m_can/Kconfig @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only menuconfig CAN_M_CAN tristate "Bosch M_CAN support" + select CAN_RX_OFFLOAD help Say Y here if you want support for Bosch M_CAN controller framework. This is common support for devices that embed the Bosch M_CAN IP. diff --git a/drivers/net/can/spi/mcp251xfd/Kconfig b/drivers/net/can/spi/mcp251xfd/Kconfig index dd0fc0a54be1..877e4356010d 100644 --- a/drivers/net/can/spi/mcp251xfd/Kconfig +++ b/drivers/net/can/spi/mcp251xfd/Kconfig @@ -2,6 +2,7 @@ config CAN_MCP251XFD tristate "Microchip MCP251xFD SPI CAN controllers" + select CAN_RX_OFFLOAD select REGMAP select WANT_DEV_COREDUMP help -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-04 16:29 ` [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol @ 2022-06-07 8:43 ` Geert Uytterhoeven 2022-06-07 9:27 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Geert Uytterhoeven @ 2022-06-07 8:43 UTC (permalink / raw) To: Vincent Mailhol Cc: Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Max Staudt, Oliver Hartkopp, netdev Hi Vincent, On Sun, Jun 5, 2022 at 12:25 AM Vincent Mailhol <mailhol.vincent@wanadoo.fr> wrote: > Only a few drivers rely on the CAN rx offload framework (as of the > writing of this patch, only four: flexcan, m_can, mcp251xfd and > ti_hecc). Give the option to the user to deselect this features during > compilation. Thanks for your patch! > The drivers relying on CAN rx offload are in different sub > folders. All of these drivers get tagged with "select CAN_RX_OFFLOAD" > so that the option is automatically enabled whenever one of those > driver is chosen. Great! But... > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > --- a/drivers/net/can/Kconfig > +++ b/drivers/net/can/Kconfig > @@ -102,6 +102,20 @@ config CAN_CALC_BITTIMING > > If unsure, say Y. > > +config CAN_RX_OFFLOAD > + bool "CAN RX offload" > + default y ... then why does this default to "y"? > + help > + Framework to offload the controller's RX FIFO during one > + interrupt. The CAN frames of the FIFO are read and put into a skb > + queue during that interrupt and transmitted afterwards in a NAPI > + context. > + > + The additional features selected by this option will be added to the > + can-dev module. > + > + If unsure, say Y. ... and do you suggest to enable this? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-07 8:43 ` Geert Uytterhoeven @ 2022-06-07 9:27 ` Vincent MAILHOL 2022-06-07 16:22 ` Max Staudt 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-07 9:27 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Max Staudt, Oliver Hartkopp, netdev Hi Geert, On Tue. 7 Jun 2022 at 17:43, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Vincent, > > On Sun, Jun 5, 2022 at 12:25 AM Vincent Mailhol > <mailhol.vincent@wanadoo.fr> wrote: > > Only a few drivers rely on the CAN rx offload framework (as of the > > writing of this patch, only four: flexcan, m_can, mcp251xfd and > > ti_hecc). Give the option to the user to deselect this features during > > compilation. > > Thanks for your patch! Thank you too, happy to see the warm feedback from all of you. > > The drivers relying on CAN rx offload are in different sub > > folders. All of these drivers get tagged with "select CAN_RX_OFFLOAD" > > so that the option is automatically enabled whenever one of those > > driver is chosen. The "select CAN_RX_OFFLOAD" is to make it dummy proof for the user who will deselect CAN_RX_OFFLOAD can still see the menu entries for all drivers. I think it is better than a "depends on" which would hide the rx offload devices. > Great! But... > > > > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > > --- a/drivers/net/can/Kconfig > > +++ b/drivers/net/can/Kconfig > > @@ -102,6 +102,20 @@ config CAN_CALC_BITTIMING > > > > If unsure, say Y. > > > > +config CAN_RX_OFFLOAD > > + bool "CAN RX offload" > > + default y > > ... then why does this default to "y"? > > > + help > > + Framework to offload the controller's RX FIFO during one > > + interrupt. The CAN frames of the FIFO are read and put into a skb > > + queue during that interrupt and transmitted afterwards in a NAPI > > + context. > > + > > + The additional features selected by this option will be added to the > > + can-dev module. > > + > > + If unsure, say Y. > > ... and do you suggest to enable this? Several reasons. First, *before* this series, the help menu for "Platform CAN drivers with Netlink support" (old CAN_DEV) had the "default y" and said: "if unsure, say Y." CAN_RX_OFFLOAD was part of it so, I am just maintaining the status quo. Second, and regardless of the above, I really think that it makes sense to have everything built in can-dev.ko by default. If someone does a binary release of can-dev.ko in which the rx offload is deactivated, end users would get really confused. Having a can-dev module stripped down is an expert setting. The average user which does not need CAN can deselect CONFIG_CAN and be happy. The average hobbyist who wants to do some CAN hacking will activate CONFIG_CAN and will automatically have the prerequisites in can-dev for any type of device drivers (after that just need to select the actual device drivers). The advanced user who actually read all the help menus will know that he should rather keep those to "yes" throughout the "if unsure, say Y" comment. Finally, the experts can fine tune their configuration by deselecting the pieces they did not wish for. Honestly, I am totally happy to have the "default y" tag, the "if unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all together. Unless I am violating some kind of best practices, I prefer to keep it as-is. Hope this makes sense. Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-07 9:27 ` Vincent MAILHOL @ 2022-06-07 16:22 ` Max Staudt 2022-06-07 22:06 ` Jakub Kicinski 0 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-06-07 16:22 UTC (permalink / raw) To: Vincent MAILHOL Cc: Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Tue, 7 Jun 2022 18:27:55 +0900 Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > Second, and regardless of the above, I really think that it makes > sense to have everything built in can-dev.ko by default. If someone > does a binary release of can-dev.ko in which the rx offload is > deactivated, end users would get really confused. > > Having a can-dev module stripped down is an expert setting. The > average user which does not need CAN can deselect CONFIG_CAN and be > happy. The average hobbyist who wants to do some CAN hacking will > activate CONFIG_CAN and will automatically have the prerequisites in > can-dev for any type of device drivers (after that just need to select > the actual device drivers). The advanced user who actually read all > the help menus will know that he should rather keep those to "yes" > throughout the "if unsure, say Y" comment. Finally, the experts can > fine tune their configuration by deselecting the pieces they did not > wish for. > > Honestly, I am totally happy to have the "default y" tag, the "if > unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all together. > > Unless I am violating some kind of best practices, I prefer to keep it > as-is. Hope this makes sense. I wholeheartedly agree with Vincent's decision. One example case would be users of my can327 driver, as long as it is not upstream yet. They need to have RX_OFFLOAD built into their distribution's can_dev.ko, otherwise they will have no choice but to build their own kernel. Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-07 16:22 ` Max Staudt @ 2022-06-07 22:06 ` Jakub Kicinski 2022-06-07 23:40 ` Vincent MAILHOL 2022-06-07 23:43 ` Max Staudt 0 siblings, 2 replies; 119+ messages in thread From: Jakub Kicinski @ 2022-06-07 22:06 UTC (permalink / raw) To: Max Staudt Cc: Vincent MAILHOL, Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Tue, 7 Jun 2022 18:22:16 +0200 Max Staudt wrote: > > Honestly, I am totally happy to have the "default y" tag, the "if > > unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all together. > > > > Unless I am violating some kind of best practices, I prefer to keep it > > as-is. Hope this makes sense. AFAIU Linus likes for everything that results in code being added to the kernel to default to n. If the drivers hard-select that Kconfig why bother user with the question at all? My understanding is that Linus also likes to keep Kconfig as simple as possible. > I wholeheartedly agree with Vincent's decision. > > One example case would be users of my can327 driver, as long as it is > not upstream yet. They need to have RX_OFFLOAD built into their > distribution's can_dev.ko, otherwise they will have no choice but to > build their own kernel. Upstream mentioning out-of-tree modules may have the opposite effect to what you intend :( Forgive my ignorance, what's the reason to keep the driver out of tree? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-07 22:06 ` Jakub Kicinski @ 2022-06-07 23:40 ` Vincent MAILHOL 2022-06-08 0:07 ` Jakub Kicinski 2022-06-07 23:43 ` Max Staudt 1 sibling, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-07 23:40 UTC (permalink / raw) To: Jakub Kicinski Cc: Max Staudt, Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Wed. 8 Jun 2022 à 07:06, Jakub Kicinski <kuba@kernel.org> wrote: > On Tue, 7 Jun 2022 18:22:16 +0200 Max Staudt wrote: > > > Honestly, I am totally happy to have the "default y" tag, the "if > > > unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all together. > > > > > > Unless I am violating some kind of best practices, I prefer to keep it > > > as-is. Hope this makes sense. > > AFAIU Linus likes for everything that results in code being added to > the kernel to default to n. A "make defconfig" would not select CONFIG_CAN (on which CAN_RX_OFFLOAD indirectly depends) and so by default this code is not added to the kernel. > If the drivers hard-select that Kconfig > why bother user with the question at all? My understanding is that > Linus also likes to keep Kconfig as simple as possible. I do not think that this is so convoluted. What would bother me is that RX offload is not a new feature. Before this series, RX offload is built-in the can-dev.o by default. If this new CAN_RX_OFFLOAD does not default to yes, then the default features built-in can-dev.o would change before and after this series. But you being one of the maintainers, if you insist I will go in your direction. So will removing the "default yes" and the comment "If unsure, say yes" from the CAN_RX_OFFLOAD satisfy you? > > I wholeheartedly agree with Vincent's decision. > > > > One example case would be users of my can327 driver, as long as it is > > not upstream yet. They need to have RX_OFFLOAD built into their > > distribution's can_dev.ko, otherwise they will have no choice but to > > build their own kernel. > > Upstream mentioning out-of-tree modules may have the opposite effect > to what you intend :( Forgive my ignorance, what's the reason to keep > the driver out of tree? I can answer for Max. The can327 patch is under review with the clear intent to have it upstream. c.f.: https://lore.kernel.org/linux-can/20220602213544.68273-1-max@enpas.org/ But until the patch gets accepted, it is defacto an out of tree module. Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-07 23:40 ` Vincent MAILHOL @ 2022-06-08 0:07 ` Jakub Kicinski 0 siblings, 0 replies; 119+ messages in thread From: Jakub Kicinski @ 2022-06-08 0:07 UTC (permalink / raw) To: Vincent MAILHOL Cc: Max Staudt, Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Wed, 8 Jun 2022 08:40:19 +0900 Vincent MAILHOL wrote: > On Wed. 8 Jun 2022 à 07:06, Jakub Kicinski <kuba@kernel.org> wrote: > > AFAIU Linus likes for everything that results in code being added to > > the kernel to default to n. > > A "make defconfig" would not select CONFIG_CAN (on which > CAN_RX_OFFLOAD indirectly depends) and so by default this code is not > added to the kernel. > > > If the drivers hard-select that Kconfig > > why bother user with the question at all? My understanding is that > > Linus also likes to keep Kconfig as simple as possible. > > I do not think that this is so convoluted. What would bother me is > that RX offload is not a new feature. Before this series, RX offload > is built-in the can-dev.o by default. If this new CAN_RX_OFFLOAD does > not default to yes, then the default features built-in can-dev.o would > change before and after this series. > > But you being one of the maintainers, if you insist I will go in your > direction. So will removing the "default yes" and the comment "If > unsure, say yes" from the CAN_RX_OFFLOAD satisfy you? I'm mostly trying to make sure Linus won't complain and block the entire net-next PR. Unfortunately I don't think the rules are written down anywhere. I could well be missing some CAN-specific context here but I see no practical benefit to exposing a knob for enabling driver framework and then selecting that framework in drivers as well. The only beneficiary I can think of is out-of-tree code. If the framework is optional (covers only parts of the driver's functionality) we make the knob configurable and drivers should work with or without it (e.g. PTP). If the framework is important / fundamental - hide it completely from the user / Kconfig and have the drivers 'select' it as a dependency (e.g. DEVLINK, PAGE_POOL). I'm not familiar with examples of the middle ground where we'd both expose the Kconfig, _and_ select in the drivers. Are there any? I don't want you to rage-quit over this tho, so we can merge as is and deal with the consequences. > > Upstream mentioning out-of-tree modules may have the opposite effect > > to what you intend :( Forgive my ignorance, what's the reason to keep > > the driver out of tree? > > I can answer for Max. The can327 patch is under review with the clear > intent to have it upstream. c.f.: > https://lore.kernel.org/linux-can/20220602213544.68273-1-max@enpas.org/ > > But until the patch gets accepted, it is defacto an out of tree module. Good to hear, then it will get upstream in due course, and the problem will disappear, no? ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-07 22:06 ` Jakub Kicinski 2022-06-07 23:40 ` Vincent MAILHOL @ 2022-06-07 23:43 ` Max Staudt 2022-06-08 0:14 ` Jakub Kicinski 1 sibling, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-06-07 23:43 UTC (permalink / raw) To: Jakub Kicinski Cc: Vincent MAILHOL, Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Tue, 7 Jun 2022 15:06:14 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > On Tue, 7 Jun 2022 18:22:16 +0200 Max Staudt wrote: > > > Honestly, I am totally happy to have the "default y" tag, the "if > > > unsure, say Y" comment and the "select CAN_RX_OFFLOAD" all > > > together. > > > > > > Unless I am violating some kind of best practices, I prefer to > > > keep it as-is. Hope this makes sense. > > AFAIU Linus likes for everything that results in code being added to > the kernel to default to n. If the drivers hard-select that Kconfig > why bother user with the question at all? My understanding is that > Linus also likes to keep Kconfig as simple as possible. > > > I wholeheartedly agree with Vincent's decision. > > > > One example case would be users of my can327 driver, as long as it > > is not upstream yet. They need to have RX_OFFLOAD built into their > > distribution's can_dev.ko, otherwise they will have no choice but to > > build their own kernel. > > Upstream mentioning out-of-tree modules may have the opposite effect > to what you intend :( Forgive my ignorance, what's the reason to keep > the driver out of tree? None, it's being upstreamed. But even with the best of intentions, it has been in this process for a long time, and it's still going on! For some reason, upstream tends to forget about everything that is not upstream *yet*. I've also convinced Greg K-H to include the N_DEVELOPMENT ldisc number for this very reason: To allow new drivers (ldiscs in this case) to be developed comfortably out-of-tree before they are upstreamed (and then assigned their own ldisc number). It seems strange to me to magically build some extra features into can_dev.ko, depending on whether some other .ko files are built in that very same moment, or not. By "magically", I mean an invisible Kconfig option. This is why I think Vincent's approach is best here, by making the drivers a clearly visible subset of the RX_OFFLOAD option in Kconfig, and RX_OFFLOAD user-selectable. How about making RX_OFFLOAD a separate .ko file, so we don't have various possible versions of can_dev.ko? @Vincent, I think you suggested that some time ago, IIRC? (I know, I was against a ton of little modules, but I'm changing my ways here now since it seems to help...) Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-07 23:43 ` Max Staudt @ 2022-06-08 0:14 ` Jakub Kicinski 2022-06-08 0:22 ` Max Staudt 2022-06-08 1:38 ` Vincent MAILHOL 0 siblings, 2 replies; 119+ messages in thread From: Jakub Kicinski @ 2022-06-08 0:14 UTC (permalink / raw) To: Max Staudt Cc: Vincent MAILHOL, Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Wed, 8 Jun 2022 01:43:54 +0200 Max Staudt wrote: > It seems strange to me to magically build some extra features into > can_dev.ko, depending on whether some other .ko files are built in that > very same moment, or not. By "magically", I mean an invisible Kconfig > option. This is why I think Vincent's approach is best here, by making > the drivers a clearly visible subset of the RX_OFFLOAD option in > Kconfig, and RX_OFFLOAD user-selectable. Sorry for a chunked response, vger becoming unresponsive the week after the merge window seems to become a tradition :/ We have a ton of "magical" / hidden Kconfigs in networking, take a look at net/Kconfig. Quick grep, likely not very accurate but FWIW: # not-hidden $ git grep -c -E '(bool|tristate)..' net/Kconfig net/Kconfig:23 # hidden $ git grep -c -E '(bool|tristate)$' net/Kconfig net/Kconfig:20 > How about making RX_OFFLOAD a separate .ko file, so we don't have > various possible versions of can_dev.ko? > > @Vincent, I think you suggested that some time ago, IIRC? > > (I know, I was against a ton of little modules, but I'm changing my > ways here now since it seems to help...) A separate module wouldn't help with my objections, I don't think. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-08 0:14 ` Jakub Kicinski @ 2022-06-08 0:22 ` Max Staudt 2022-06-08 1:38 ` Vincent MAILHOL 1 sibling, 0 replies; 119+ messages in thread From: Max Staudt @ 2022-06-08 0:22 UTC (permalink / raw) To: Jakub Kicinski Cc: Vincent MAILHOL, Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Tue, 7 Jun 2022 17:14:55 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > We have a ton of "magical" / hidden Kconfigs in networking, take a > look at net/Kconfig. Quick grep, likely not very accurate but FWIW: Fair enough. Thinking about it, I've grepped my distro's kernel config for features more than just a handful of times... > > How about making RX_OFFLOAD a separate .ko file, so we don't have > > various possible versions of can_dev.ko? > > > > @Vincent, I think you suggested that some time ago, IIRC? > > > > (I know, I was against a ton of little modules, but I'm changing my > > ways here now since it seems to help...) > > A separate module wouldn't help with my objections, I don't think. In a system where the CAN stack is compiled as modules (i.e. a regular desktop distribution), the feature's presence/absence would be easily visible via the .ko file's presence/absence. Then again, I have to agree, distributing a system where RX_OFFLOAD is present, but no drivers using it whatsoever, seems... strange. I guess I got lost in my thinking there, with my out of tree development and all. Sorry for the noise. Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-08 0:14 ` Jakub Kicinski 2022-06-08 0:22 ` Max Staudt @ 2022-06-08 1:38 ` Vincent MAILHOL 1 sibling, 0 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-08 1:38 UTC (permalink / raw) To: Jakub Kicinski Cc: Max Staudt, Geert Uytterhoeven, Marc Kleine-Budde, linux-can, Linux Kernel Mailing List, Oliver Hartkopp, netdev On Wed. 8 juin 2022 at 09:14, Jakub Kicinski <kuba@kernel.org> wrote: > On Wed, 8 Jun 2022 01:43:54 +0200 Max Staudt wrote: > > It seems strange to me to magically build some extra features into > > can_dev.ko, depending on whether some other .ko files are built in that > > very same moment, or not. By "magically", I mean an invisible Kconfig > > option. This is why I think Vincent's approach is best here, by making > > the drivers a clearly visible subset of the RX_OFFLOAD option in > > Kconfig, and RX_OFFLOAD user-selectable. > > Sorry for a chunked response, vger becoming unresponsive the week after > the merge window seems to become a tradition :/ > > We have a ton of "magical" / hidden Kconfigs in networking, take a look > at net/Kconfig. Quick grep, likely not very accurate but FWIW: > > # not-hidden > $ git grep -c -E '(bool|tristate)..' net/Kconfig > net/Kconfig:23 > > # hidden > $ git grep -c -E '(bool|tristate)$' net/Kconfig > net/Kconfig:20 OK. So we have a proposal to make CAN_RX_OFFLOAD an hidden configuration. I did not consider this approach before because the CAN subsystem *never* relies on this and I did not really explore other Kbuild files. | $ git grep -c -E '(bool|tristate)$' net/can/Kconfig | <no output> Before pushing my driver upstream, it was also an out of tree module for about one year and I relate a lot to what Max said. But Jakub explanations are consistent and reflect the best practices of the kernel development. Also, mainstream distribution would do an allyesconfig and ship the can-dev.ko with everything built in. So the lambda user would still have everything built-in. I will let people continue to comment for a couple of days before making the final choice and sending the next version. But so far, I am leading toward Jakub’s idea to make it a hidden feature. > > How about making RX_OFFLOAD a separate .ko file, so we don't have > > various possible versions of can_dev.ko? > > > > @Vincent, I think you suggested that some time ago, IIRC? > > > > (I know, I was against a ton of little modules, but I'm changing my > > ways here now since it seems to help...) > > A separate module wouldn't help with my objections, I don't think. ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v5 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol ` (3 preceding siblings ...) 2022-06-04 16:29 ` [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol @ 2022-06-04 16:29 ` Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol ` (3 subsequent siblings) 8 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:29 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol The devices are meant to be under the "Device Drivers" category of the menuconfig. The CAN subsystem is currently one of the rare exception with all of its devices under the "Networking support" category. The CAN_DEV menuentry gets moved to fix this discrepancy. The CAN menu is added just before MCTP in order to be consistent with the current order under the "Networking support" menu. A dependency on CAN is added to CAN_DEV so that the CAN devices only show up if the CAN subsystem is enabled. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/Kconfig | 2 ++ drivers/net/can/Kconfig | 1 + net/can/Kconfig | 5 ++--- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index b2a4f998c180..5de243899de8 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -499,6 +499,8 @@ config NET_SB1000 source "drivers/net/phy/Kconfig" +source "drivers/net/can/Kconfig" + source "drivers/net/mctp/Kconfig" source "drivers/net/mdio/Kconfig" diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 91e4af727d1f..17656beb6bda 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -3,6 +3,7 @@ menuconfig CAN_DEV tristate "CAN Device Drivers" default y + depends on CAN help Controller Area Network (CAN) is serial communications protocol up to 1Mbit/s for its original release (now known as Classical CAN) and up diff --git a/net/can/Kconfig b/net/can/Kconfig index a9ac5ffab286..cb56be8e3862 100644 --- a/net/can/Kconfig +++ b/net/can/Kconfig @@ -15,7 +15,8 @@ menuconfig CAN PF_CAN is contained in <Documentation/networking/can.rst>. If you want CAN support you should say Y here and also to the - specific driver for your controller(s) below. + specific driver for your controller(s) under the Network device + support section. if CAN @@ -69,6 +70,4 @@ config CAN_ISOTP If you want to perform automotive vehicle diagnostic services (UDS), say 'y'. -source "drivers/net/can/Kconfig" - endif -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v5 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol ` (4 preceding siblings ...) 2022-06-04 16:29 ` [PATCH v5 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol @ 2022-06-04 16:29 ` Vincent Mailhol 2022-06-04 16:30 ` [PATCH v5 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol ` (2 subsequent siblings) 8 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:29 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol The functions can_dropped_invalid_skb() and can_skb_headroom_valid() grew a lot over the years to a point which it does not make much sense to have them defined as static inline in header files. Move those two functions to the .c counterpart of skb.h. can_skb_headroom_valid()'s only caller being can_dropped_invalid_skb(), the declaration is removed from the header. Only can_dropped_invalid_skb() gets its symbol exported. While doing so, do a small cleanup: add brackets around the else block in can_dropped_invalid_skb(). Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 58 ++++++++++++++++++++++++++++++++++++++ include/linux/can/skb.h | 59 +-------------------------------------- 2 files changed, 59 insertions(+), 58 deletions(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index a4208f125b76..dc9da76c0470 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -259,3 +259,61 @@ struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf) return skb; } EXPORT_SYMBOL_GPL(alloc_can_err_skb); + +/* Check for outgoing skbs that have not been created by the CAN subsystem */ +static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) +{ + /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ + if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) + return false; + + /* af_packet does not apply CAN skb specific settings */ + if (skb->ip_summed == CHECKSUM_NONE) { + /* init headroom */ + can_skb_prv(skb)->ifindex = dev->ifindex; + can_skb_prv(skb)->skbcnt = 0; + + skb->ip_summed = CHECKSUM_UNNECESSARY; + + /* perform proper loopback on capable devices */ + if (dev->flags & IFF_ECHO) + skb->pkt_type = PACKET_LOOPBACK; + else + skb->pkt_type = PACKET_HOST; + + skb_reset_mac_header(skb); + skb_reset_network_header(skb); + skb_reset_transport_header(skb); + } + + return true; +} + +/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) +{ + const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + + if (skb->protocol == htons(ETH_P_CAN)) { + if (unlikely(skb->len != CAN_MTU || + cfd->len > CAN_MAX_DLEN)) + goto inval_skb; + } else if (skb->protocol == htons(ETH_P_CANFD)) { + if (unlikely(skb->len != CANFD_MTU || + cfd->len > CANFD_MAX_DLEN)) + goto inval_skb; + } else { + goto inval_skb; + } + + if (!can_skb_headroom_valid(dev, skb)) + goto inval_skb; + + return false; + +inval_skb: + kfree_skb(skb); + dev->stats.tx_dropped++; + return true; +} +EXPORT_SYMBOL_GPL(can_dropped_invalid_skb); diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index fdb22b00674a..182749e858b3 100644 --- a/include/linux/can/skb.h +++ b/include/linux/can/skb.h @@ -31,6 +31,7 @@ struct sk_buff *alloc_canfd_skb(struct net_device *dev, struct canfd_frame **cfd); struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf); +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb); /* * The struct can_skb_priv is used to transport additional information along @@ -96,64 +97,6 @@ static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb) return nskb; } -/* Check for outgoing skbs that have not been created by the CAN subsystem */ -static inline bool can_skb_headroom_valid(struct net_device *dev, - struct sk_buff *skb) -{ - /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ - if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) - return false; - - /* af_packet does not apply CAN skb specific settings */ - if (skb->ip_summed == CHECKSUM_NONE) { - /* init headroom */ - can_skb_prv(skb)->ifindex = dev->ifindex; - can_skb_prv(skb)->skbcnt = 0; - - skb->ip_summed = CHECKSUM_UNNECESSARY; - - /* perform proper loopback on capable devices */ - if (dev->flags & IFF_ECHO) - skb->pkt_type = PACKET_LOOPBACK; - else - skb->pkt_type = PACKET_HOST; - - skb_reset_mac_header(skb); - skb_reset_network_header(skb); - skb_reset_transport_header(skb); - } - - return true; -} - -/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ -static inline bool can_dropped_invalid_skb(struct net_device *dev, - struct sk_buff *skb) -{ - const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; - - if (skb->protocol == htons(ETH_P_CAN)) { - if (unlikely(skb->len != CAN_MTU || - cfd->len > CAN_MAX_DLEN)) - goto inval_skb; - } else if (skb->protocol == htons(ETH_P_CANFD)) { - if (unlikely(skb->len != CANFD_MTU || - cfd->len > CANFD_MAX_DLEN)) - goto inval_skb; - } else - goto inval_skb; - - if (!can_skb_headroom_valid(dev, skb)) - goto inval_skb; - - return false; - -inval_skb: - kfree_skb(skb); - dev->stats.tx_dropped++; - return true; -} - static inline bool can_is_canfd_skb(const struct sk_buff *skb) { /* the CAN specific type of skb is identified by its data length */ -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v5 7/7] can: skb: drop tx skb if in listen only mode 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol ` (5 preceding siblings ...) 2022-06-04 16:29 ` [PATCH v5 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol @ 2022-06-04 16:30 ` Vincent Mailhol 2022-06-05 17:23 ` [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild Max Staudt 2022-06-06 19:24 ` Oliver Hartkopp 8 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-04 16:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Vincent Mailhol Frames can be directly injected to a can driver via the packet socket. By doing so, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configured in listen only mode. Add a check in can_dropped_invalid_skb() to discard the skb if CAN_CTRLMODE_LISTENONLY is set. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index dc9da76c0470..8bb62dd864c8 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,7 @@ */ #include <linux/can/dev.h> +#include <linux/can/netlink.h> #include <linux/module.h> #define MOD_DESC "CAN device driver interface" @@ -293,6 +294,7 @@ static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) { const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + struct can_priv *priv = netdev_priv(dev); if (skb->protocol == htons(ETH_P_CAN)) { if (unlikely(skb->len != CAN_MTU || @@ -306,8 +308,13 @@ bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) goto inval_skb; } - if (!can_skb_headroom_valid(dev, skb)) + if (!can_skb_headroom_valid(dev, skb)) { + goto inval_skb; + } else if (priv->ctrlmode & CAN_CTRLMODE_LISTENONLY) { + netdev_info_once(dev, + "interface in listen only mode, dropping skb\n"); goto inval_skb; + } return false; -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol ` (6 preceding siblings ...) 2022-06-04 16:30 ` [PATCH v5 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol @ 2022-06-05 17:23 ` Max Staudt 2022-06-05 18:06 ` Marc Kleine-Budde 2022-06-06 19:24 ` Oliver Hartkopp 8 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-06-05 17:23 UTC (permalink / raw) To: Vincent Mailhol Cc: Marc Kleine-Budde, linux-can, linux-kernel, Oliver Hartkopp, netdev Thanks Vincent for this cleanup! Since I am upstreaming a driver that may (?) not fit the proposed structure, one question below. On Sun, 5 Jun 2022 01:29:53 +0900 Vincent Mailhol <mailhol.vincent@wanadoo.fr> wrote: > * menu after this series * > > Network device support > symbol: CONFIG_NETDEVICES > | > +-> CAN Device Drivers > symbol: CONFIG_CAN_DEV > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> CAN device drivers with Netlink support > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > | > +-> CAN bit-timing calculation (optional for all drivers) > | symbol: CONFIG_CAN_BITTIMING > | > +-> All other CAN devices not relying on RX offload > | > +-> CAN rx offload > symbol: CONFIG_CAN_RX_OFFLOAD > | > +-> CAN devices relying on rx offload > (at time of writing: flexcan, m_can, mcp251xfd and > ti_hecc) This seemingly splits drivers into "things that speak to hardware" and "things that don't". Except... slcan really does speak to hardware. It just so happens to not use any of BITTIMING or RX_OFFLOAD. However, my can327 (formerly elmcan) driver, which is an ldisc just like slcan, *does* use RX_OFFLOAD, so where to I put it? Next to flexcan, m_can, mcp251xfd and ti_hecc? Is it really just a split by features used in drivers, and no longer a split by virtual/real? Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-05 17:23 ` [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild Max Staudt @ 2022-06-05 18:06 ` Marc Kleine-Budde 2022-06-05 20:46 ` Max Staudt 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-05 18:06 UTC (permalink / raw) To: Max Staudt Cc: Vincent Mailhol, linux-can, linux-kernel, Oliver Hartkopp, netdev [-- Attachment #1: Type: text/plain, Size: 2115 bytes --] On 05.06.2022 19:23:47, Max Staudt wrote: > Thanks Vincent for this cleanup! > > Since I am upstreaming a driver that may (?) not fit the proposed > structure, one question below. > > > On Sun, 5 Jun 2022 01:29:53 +0900 > Vincent Mailhol <mailhol.vincent@wanadoo.fr> wrote: > > > * menu after this series * > > > > Network device support > > symbol: CONFIG_NETDEVICES > > | > > +-> CAN Device Drivers > > symbol: CONFIG_CAN_DEV > > | > > +-> software/virtual CAN device drivers > > | (at time of writing: slcan, vcan, vxcan) > > | > > +-> CAN device drivers with Netlink support > > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > > | > > +-> CAN bit-timing calculation (optional for all drivers) > > | symbol: CONFIG_CAN_BITTIMING > > | > > +-> All other CAN devices not relying on RX offload > > | > > +-> CAN rx offload > > symbol: CONFIG_CAN_RX_OFFLOAD > > | > > +-> CAN devices relying on rx offload > > (at time of writing: flexcan, m_can, mcp251xfd and > > ti_hecc) > > This seemingly splits drivers into "things that speak to hardware" and > "things that don't". Except... slcan really does speak to hardware. It > just so happens to not use any of BITTIMING or RX_OFFLOAD. However, my > can327 (formerly elmcan) driver, which is an ldisc just like slcan, > *does* use RX_OFFLOAD, so where to I put it? Next to flexcan, m_can, > mcp251xfd and ti_hecc? > > Is it really just a split by features used in drivers, and no longer a > split by virtual/real? We can move RX_OFFLOAD out of the "if CAN_NETLINK". Who wants to create an incremental patch against can-next/master? 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-05 18:06 ` Marc Kleine-Budde @ 2022-06-05 20:46 ` Max Staudt 2022-06-06 0:24 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Max Staudt @ 2022-06-05 20:46 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Vincent Mailhol, linux-can, linux-kernel, Oliver Hartkopp, netdev On Sun, 5 Jun 2022 20:06:41 +0200 Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 05.06.2022 19:23:47, Max Staudt wrote: > > This seemingly splits drivers into "things that speak to hardware" > > and "things that don't". Except... slcan really does speak to > > hardware. It just so happens to not use any of BITTIMING or > > RX_OFFLOAD. However, my can327 (formerly elmcan) driver, which is > > an ldisc just like slcan, *does* use RX_OFFLOAD, so where to I put > > it? Next to flexcan, m_can, mcp251xfd and ti_hecc? > > > > Is it really just a split by features used in drivers, and no > > longer a split by virtual/real? > > We can move RX_OFFLOAD out of the "if CAN_NETLINK". Who wants to > create an incremental patch against can-next/master? Yes, this may be useful in the future. But for now, I think I can answer my question myself :) My driver does support Netlink to set CAN link parameters. So I'll just drop it into the CAN_NETLINK -> RX_OFFLOAD category in Kconfig, unless anyone objects. I just got confused because in my mind, I'm still comparing it to slcan, whereas in reality, it's now functionally closer to all the other hardware drivers. Netlink and all. Apologies for the noise! Max ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-05 20:46 ` Max Staudt @ 2022-06-06 0:24 ` Vincent MAILHOL 0 siblings, 0 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-06 0:24 UTC (permalink / raw) To: Max Staudt Cc: Marc Kleine-Budde, linux-can, open list, Oliver Hartkopp, netdev On Mon. 6 Jun. 2022, at 05:46, Max Staudt <max@enpas.org> wrote: > > On Sun, 5 Jun 2022 20:06:41 +0200 > Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > > On 05.06.2022 19:23:47, Max Staudt wrote: > > > This seemingly splits drivers into "things that speak to hardware" > > > and "things that don't". Except... slcan really does speak to > > > hardware. slcan is just an oddity in this regard because all the netlink logic is done in userspace using slcand. I think that it would really benefit to be rewritten using the features under CAN_NETLINK. This way, it could for example benefit from can_priv::bitrate_const to manage the bitrates via iproute2 instead of relying on slcand c.f.: https://elinux.org/Bringing_CAN_interface_up#SLCAN_based_Interfaces Similarly, it doesn't seem that slcan loopbacks the TX frames which, in some way, violates one of the core concepts of SocketCAN: https://docs.kernel.org/networking/can.html#local-loopback-of-sent-frames You did a great job by putting all the logic in your can327 driver instead of requiring a userland tool and I think slcan merits to have your can327 improvements backported to him. > It just so happens to not use any of BITTIMING or > > > RX_OFFLOAD. However, my can327 (formerly elmcan) driver, which is > > > an ldisc just like slcan, *does* use RX_OFFLOAD, so where to I put > > > it? Next to flexcan, m_can, mcp251xfd and ti_hecc? > > > > > > Is it really just a split by features used in drivers, and no > > > longer a split by virtual/real? > > > > We can move RX_OFFLOAD out of the "if CAN_NETLINK". Who wants to > > create an incremental patch against can-next/master? > > Yes, this may be useful in the future. But for now, I think I can > answer my question myself :) I was about to answer you, but you corrected the shot before I had time to do so :) > My driver does support Netlink to set CAN link parameters. So I'll just > drop it into the CAN_NETLINK -> RX_OFFLOAD category in Kconfig, unless > anyone objects. This is the correct approach (and the only one). Try to maintain the alphabetical order of the menu when you add it. > I just got confused because in my mind, I'm still comparing it to > slcan, whereas in reality, it's now functionally closer to all the other > hardware drivers. Netlink and all. > > Apologies for the noise! No problem! Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol ` (7 preceding siblings ...) 2022-06-05 17:23 ` [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild Max Staudt @ 2022-06-06 19:24 ` Oliver Hartkopp 2022-06-07 2:49 ` Vincent MAILHOL 8 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-06-06 19:24 UTC (permalink / raw) To: Vincent Mailhol, Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, netdev Hi Vincent, great work! On 04.06.22 18:29, Vincent Mailhol wrote: > * menu after this series * > > Network device support > symbol: CONFIG_NETDEVICES > | > +-> CAN Device Drivers > symbol: CONFIG_CAN_DEV > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> CAN device drivers with Netlink support > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > | > +-> CAN bit-timing calculation (optional for all drivers) > | symbol: CONFIG_CAN_BITTIMING > | > +-> All other CAN devices not relying on RX offload > | > +-> CAN rx offload > symbol: CONFIG_CAN_RX_OFFLOAD Is this still true in patch series 5? If I understood it correctly CONFIG_CAN_BITTIMING and CONFIG_CAN_RX_OFFLOAD can be enabled by the user and (alternatively/additionally) the selection of "flexcan, m_can, mcp251xfd and ti_hecc" enables CONFIG_CAN_RX_OFFLOAD too. Right? > | > +-> CAN devices relying on rx offload > (at time of writing: flexcan, m_can, mcp251xfd and ti_hecc) Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-06 19:24 ` Oliver Hartkopp @ 2022-06-07 2:49 ` Vincent MAILHOL 2022-06-07 7:13 ` Marc Kleine-Budde 2022-06-07 20:12 ` Oliver Hartkopp 0 siblings, 2 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-07 2:49 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, linux-can, open list, Max Staudt, netdev On Tue. 7 Jun. 2022 at 04:43, Oliver Hartkopp <socketcan@hartkopp.net> wrote: > > Hi Vincent, > > great work! Thanks! > On 04.06.22 18:29, Vincent Mailhol wrote: > > > * menu after this series * > > > > Network device support > > symbol: CONFIG_NETDEVICES > > | > > +-> CAN Device Drivers > > symbol: CONFIG_CAN_DEV > > | > > +-> software/virtual CAN device drivers > > | (at time of writing: slcan, vcan, vxcan) > > | > > +-> CAN device drivers with Netlink support > > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > > | > > +-> CAN bit-timing calculation (optional for all drivers) > > | symbol: CONFIG_CAN_BITTIMING ^^^^^^^^^^^^^^^^^^^^ Typo: the symbol is CONFIG_CAN_*CALC*_BITTIMING. I made that typo twice in the cover letter (once in each diagram). The patches and their comments remain correct. > > | > > +-> All other CAN devices not relying on RX offload > > | > > +-> CAN rx offload > > symbol: CONFIG_CAN_RX_OFFLOAD > > Is this still true in patch series 5? > > If I understood it correctly CONFIG_CAN_BITTIMING and > CONFIG_CAN_RX_OFFLOAD can be enabled by the user and > (alternatively/additionally) the selection of "flexcan, m_can, mcp251xfd > and ti_hecc" enables CONFIG_CAN_RX_OFFLOAD too. > > Right? Yes, this is correct. Maybe what troubles you is the meaning of the "x --> y" arrow in the graph. I said it denotes that "y depends on x". Here "depends on" has a loose meaning. It translates to either: * Feature Y is encapsulated in Kbuild by some "if X/endif" and won't show up unless X is selected. * Feature Y has a "selects X" tag and will forcibly enable X if selected. CONFIG_CAN_*CALC*_BITTIMING is on the left side of an arrow starting from CONFIG_CAN_NETLINK so it "depends" on CONFIG_CAN_NETLINK. On the other hand, CONFIG_CAN_*CALC*_BITTIMING does not have any arrow starting from it so indeed, it can be enabled by the user independently of the other features as long as CONFIG_CAN_NETLINK is selected. CONFIG_CAN_RX_OFFLOAD is also on the left side of an arrow starting from CONFIG_CAN_NETLINK. Furthermore, there is an arrow starting from CONFIG_CAN_RX_OFFLOAD going to the "rx offload drivers". So those drivers need CONFIG_CAN_RX_OFFLOAD (which is implemented using the "selects CONFIG_CAN_RX_OFFLOAD"). However, CONFIG_CAN_RX_OFFLOAD can be selected independently of the "rx offload drivers" as long as its CONFIG_CAN_NETLINK dependency is met. So I think that the diagram is correct. Maybe rephrasing the cover letter as below would address your concerns? | Below diagrams illustrate the changes made. The arrow symbol "X --> Y" | denotes that "Y needs X". Most of the time, it is implemented using "if X" | and "endif" predicates in X’s Kbuild to encapsulate Y so that Y | does not show up unless X is selected. The exception is rx | offload which is implemented by adding a "selects | CONFIG_CAN_RX_OFFLOAD" tag in Y’s Kbuild. > > | > > +-> CAN devices relying on rx offload > > (at time of writing: flexcan, m_can, mcp251xfd and ti_hecc) Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-07 2:49 ` Vincent MAILHOL @ 2022-06-07 7:13 ` Marc Kleine-Budde 2022-06-07 8:49 ` Vincent MAILHOL 2022-06-07 20:12 ` Oliver Hartkopp 1 sibling, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-07 7:13 UTC (permalink / raw) To: Vincent MAILHOL; +Cc: Oliver Hartkopp, linux-can, open list, Max Staudt, netdev [-- Attachment #1: Type: text/plain, Size: 708 bytes --] On 07.06.2022 11:49:30, Vincent MAILHOL wrote: [...] > So I think that the diagram is correct. Maybe rephrasing the cover > letter as below would address your concerns? BTW: I got the OK from Jakub to send PR with merges. If you think the cover letter needs rephrasing, send a new series and I'm going to force push that over can-next/master. After that let's consider can-next/master as fast-forward only. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-07 7:13 ` Marc Kleine-Budde @ 2022-06-07 8:49 ` Vincent MAILHOL 0 siblings, 0 replies; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-07 8:49 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Oliver Hartkopp, linux-can, open list, Max Staudt, netdev On Tue. 7 Jun. 2022 at 16:13, Marc Kleine-Budde <mkl@pengutronix.de> wrote: > On 07.06.2022 11:49:30, Vincent MAILHOL wrote: > [...] > > So I think that the diagram is correct. Maybe rephrasing the cover > > letter as below would address your concerns? > > BTW: I got the OK from Jakub to send PR with merges. > > If you think the cover letter needs rephrasing, send a new series and > I'm going to force push that over can-next/master. After that let's > consider can-next/master as fast-forward only. I will first wait for Oliver’s feedback. Once we are aligned, I can do the v6 and I really hope that would be the last one. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-07 2:49 ` Vincent MAILHOL 2022-06-07 7:13 ` Marc Kleine-Budde @ 2022-06-07 20:12 ` Oliver Hartkopp 2022-06-07 20:27 ` Marc Kleine-Budde 1 sibling, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-06-07 20:12 UTC (permalink / raw) To: Vincent MAILHOL Cc: Marc Kleine-Budde, linux-can, open list, Max Staudt, netdev Hi Vincent, On 07.06.22 04:49, Vincent MAILHOL wrote: > On Tue. 7 Jun. 2022 at 04:43, Oliver Hartkopp <socketcan@hartkopp.net> wrote: >> >>> | >>> +-> All other CAN devices not relying on RX offload >>> | >>> +-> CAN rx offload >>> symbol: CONFIG_CAN_RX_OFFLOAD >> >> Is this still true in patch series 5? >> >> If I understood it correctly CONFIG_CAN_BITTIMING and >> CONFIG_CAN_RX_OFFLOAD can be enabled by the user and >> (alternatively/additionally) the selection of "flexcan, m_can, mcp251xfd >> and ti_hecc" enables CONFIG_CAN_RX_OFFLOAD too. >> >> Right? > > Yes, this is correct. Maybe what troubles you is the meaning of the > "x --> y" arrow in the graph. I said it denotes that "y depends on x". > Here "depends on" has a loose meaning. It translates to either: > * Feature Y is encapsulated in Kbuild by some "if X/endif" and won't > show up unless X is selected. > * Feature Y has a "selects X" tag and will forcibly enable X if selected. > > CONFIG_CAN_*CALC*_BITTIMING is on the left side of an arrow starting > from CONFIG_CAN_NETLINK so it "depends" on CONFIG_CAN_NETLINK. On the > other hand, CONFIG_CAN_*CALC*_BITTIMING does not have any arrow > starting from it so indeed, it can be enabled by the user > independently of the other features as long as CONFIG_CAN_NETLINK is > selected. Ok. > CONFIG_CAN_RX_OFFLOAD is also on the left side of an arrow starting > from CONFIG_CAN_NETLINK. Furthermore, there is an arrow starting from > CONFIG_CAN_RX_OFFLOAD going to the "rx offload drivers". So those > drivers need CONFIG_CAN_RX_OFFLOAD (which is implemented using the > "selects CONFIG_CAN_RX_OFFLOAD"). However, CONFIG_CAN_RX_OFFLOAD can > be selected independently of the "rx offload drivers" as long as its > CONFIG_CAN_NETLINK dependency is met. > > So I think that the diagram is correct. Maybe rephrasing the cover > letter as below would address your concerns? I applied your series and played with the options and it works like charm - and as expected. But the point remains that from your figure I would still assume that the M_CAN driver would only show up when CONFIG_CAN_RX_OFFLOAD was selected by the user. But the current (good) implementation shows *all* drivers and selects CONFIG_CAN_RX_OFFLOAD when e.g. M_CAN is selected. So what about: symbol: CONFIG_NETDEVICES | +-> CAN Device Drivers symbol: CONFIG_CAN_DEV | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> hardware CAN device drivers with Netlink support symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) | +-> CAN bit-timing calculation (optional for all drivers) | symbol: CONFIG_CAN_BITTIMING | +-> CAN rx offload (optional but selected by some drivers) | symbol: CONFIG_CAN_RX_OFFLOAD | +-> CAN devices drivers (some may select CONFIG_CAN_RX_OFFLOAD) (I also added 'hardware' to CAN device drivers with Netlink support) to have a distinction to 'software/virtual' CAN device drivers) At least this would help me to understand the new configuration setup. Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-07 20:12 ` Oliver Hartkopp @ 2022-06-07 20:27 ` Marc Kleine-Budde 2022-06-07 20:51 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-07 20:27 UTC (permalink / raw) To: Oliver Hartkopp; +Cc: Vincent MAILHOL, linux-can, open list, Max Staudt, netdev [-- Attachment #1: Type: text/plain, Size: 1456 bytes --] On 07.06.2022 22:12:46, Oliver Hartkopp wrote: > So what about: > > symbol: CONFIG_NETDEVICES > | > +-> CAN Device Drivers > symbol: CONFIG_CAN_DEV > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> hardware CAN device drivers with Netlink support > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > | > +-> CAN bit-timing calculation (optional for all drivers) > | symbol: CONFIG_CAN_BITTIMING > | > +-> CAN rx offload (optional but selected by some drivers) > | symbol: CONFIG_CAN_RX_OFFLOAD > | > +-> CAN devices drivers > (some may select CONFIG_CAN_RX_OFFLOAD) > > (I also added 'hardware' to CAN device drivers with Netlink support) to have > a distinction to 'software/virtual' CAN device drivers) The line between hardware and software/virtual devices ist blurry, the new can327 driver uses netlink and the slcan is currently being converted.... > At least this would help me to understand the new configuration setup. 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-07 20:27 ` Marc Kleine-Budde @ 2022-06-07 20:51 ` Oliver Hartkopp 2022-06-07 23:59 ` Vincent MAILHOL 0 siblings, 1 reply; 119+ messages in thread From: Oliver Hartkopp @ 2022-06-07 20:51 UTC (permalink / raw) To: Marc Kleine-Budde Cc: Vincent MAILHOL, linux-can, open list, Max Staudt, netdev On 07.06.22 22:27, Marc Kleine-Budde wrote: > On 07.06.2022 22:12:46, Oliver Hartkopp wrote: >> So what about: >> >> symbol: CONFIG_NETDEVICES >> | >> +-> CAN Device Drivers >> symbol: CONFIG_CAN_DEV >> | >> +-> software/virtual CAN device drivers >> | (at time of writing: slcan, vcan, vxcan) >> | >> +-> hardware CAN device drivers with Netlink support >> symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) >> | >> +-> CAN bit-timing calculation (optional for all drivers) >> | symbol: CONFIG_CAN_BITTIMING >> | >> +-> CAN rx offload (optional but selected by some drivers) >> | symbol: CONFIG_CAN_RX_OFFLOAD >> | >> +-> CAN devices drivers >> (some may select CONFIG_CAN_RX_OFFLOAD) >> >> (I also added 'hardware' to CAN device drivers with Netlink support) to have >> a distinction to 'software/virtual' CAN device drivers) > > The line between hardware and software/virtual devices ist blurry, the > new can327 driver uses netlink and the slcan is currently being > converted.... Right, which could mean that slcan and can327 should be located in the 'usual' CAN device driver section and not in the sw/virtual device section. The slcan and can327 need some kind of hardware - while vcan and vxcan don't. Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-07 20:51 ` Oliver Hartkopp @ 2022-06-07 23:59 ` Vincent MAILHOL 2022-06-08 20:10 ` Oliver Hartkopp 0 siblings, 1 reply; 119+ messages in thread From: Vincent MAILHOL @ 2022-06-07 23:59 UTC (permalink / raw) To: Oliver Hartkopp Cc: Marc Kleine-Budde, linux-can, open list, Max Staudt, netdev On Wed. 8 Jun 2022 at 05:51, Oliver Hartkopp <socketcan@hartkopp.net> wrote: > On 07.06.22 22:27, Marc Kleine-Budde wrote: > > On 07.06.2022 22:12:46, Oliver Hartkopp wrote: > >> So what about: > >> > >> symbol: CONFIG_NETDEVICES > >> | > >> +-> CAN Device Drivers > >> symbol: CONFIG_CAN_DEV > >> | > >> +-> software/virtual CAN device drivers > >> | (at time of writing: slcan, vcan, vxcan) > >> | > >> +-> hardware CAN device drivers with Netlink support > >> symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > >> | > >> +-> CAN bit-timing calculation (optional for all drivers) > >> | symbol: CONFIG_CAN_BITTIMING > >> | > >> +-> CAN rx offload (optional but selected by some drivers) > >> | symbol: CONFIG_CAN_RX_OFFLOAD > >> | > >> +-> CAN devices drivers > >> (some may select CONFIG_CAN_RX_OFFLOAD) OK, this does not follow the definition I set for the "x --> y" arrow, but it is easy to read. I am OK with your suggestion. I will also remove the definition of the "x --> y" arrow because your diagram is self explanatory. > >> (I also added 'hardware' to CAN device drivers with Netlink support) to have > >> a distinction to 'software/virtual' CAN device drivers) This line you modified is the verbatim copy of the title in menuconfig. So you are suggesting adding "hardware" to the menuconfig as well? It did not have this word in the title before this series. I was hesitating on this. If we name the symbol CAN_NETLINK, then I do not see the need to also add "hardware" in the title. If you look at the help menu, you will see: "This is required by all platform and hardware CAN drivers." Mentioning it in the help menu is enough for me. And because of the blur line between slcan (c.f. Marc's comment below), I am not convinced to add this. > > The line between hardware and software/virtual devices ist blurry, the > > new can327 driver uses netlink and the slcan is currently being > > converted.... > > Right, which could mean that slcan and can327 should be located in the > 'usual' CAN device driver section and not in the sw/virtual device section. ACK, but as discussed with Marc, I will just focus on the series itself and ignore (for the moment) that slcan will probably be moved within CAN_NETLINK scope in the future. https://lore.kernel.org/linux-can/20220607103923.5m6j4rykvitofsv4@pengutronix.de/ > The slcan and can327 need some kind of hardware - while vcan and vxcan > don't. Yours sincerely, Vincent Mailhol ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-07 23:59 ` Vincent MAILHOL @ 2022-06-08 20:10 ` Oliver Hartkopp 0 siblings, 0 replies; 119+ messages in thread From: Oliver Hartkopp @ 2022-06-08 20:10 UTC (permalink / raw) To: Vincent MAILHOL Cc: Marc Kleine-Budde, linux-can, open list, Max Staudt, netdev On 08.06.22 01:59, Vincent MAILHOL wrote: > On Wed. 8 Jun 2022 at 05:51, Oliver Hartkopp <socketcan@hartkopp.net> wrote: >>>> (I also added 'hardware' to CAN device drivers with Netlink support) to have >>>> a distinction to 'software/virtual' CAN device drivers) > > This line you modified is the verbatim copy of the title in > menuconfig. So you are suggesting adding "hardware" to the menuconfig > as well? It did not have this word in the title before this series. > I was hesitating on this. If we name the symbol CAN_NETLINK, then I do > not see the need to also add "hardware" in the title. If you look at > the help menu, you will see: "This is required by all platform and > hardware CAN drivers." Mentioning it in the help menu is enough for > me. > > And because of the blur line between slcan (c.f. Marc's comment > below), I am not convinced to add this. Yes, discussing about this change I'm not convinced either ;-) >>> The line between hardware and software/virtual devices ist blurry, the >>> new can327 driver uses netlink and the slcan is currently being >>> converted.... >> >> Right, which could mean that slcan and can327 should be located in the >> 'usual' CAN device driver section and not in the sw/virtual device section. > > ACK, but as discussed with Marc, I will just focus on the series > itself and ignore (for the moment) that slcan will probably be moved > within CAN_NETLINK scope in the future. > https://lore.kernel.org/linux-can/20220607103923.5m6j4rykvitofsv4@pengutronix.de/ Ok. Sorry for the noise! Best regards, Oliver ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v6 0/7] can: refactoring of can-dev module and of Kbuild 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol ` (6 preceding siblings ...) 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 1/7] can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol ` (9 more replies) 7 siblings, 10 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol Aside of calc_bittiming.o which can be configured with CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked unconditionally to can-dev.o even if not needed by the user. This series first goal it to split the can-dev modules so that the only the needed features get built in during compilation. Additionally, the CAN Device Drivers menu is moved from the "Networking support" category to the "Device Drivers" category (where all drivers are supposed to be). * menu before this series * CAN bus subsystem support symbol: CONFIG_CAN | +-> CAN Device Drivers (no symbol) | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> Platform CAN drivers with Netlink support symbol: CONFIG_CAN_DEV | +-> CAN bit-timing calculation (optional for hardware drivers) | symbol: CONFIG_CAN_CALC_BITTIMING | +-> All other CAN devices drivers * menu after this series * Network device support symbol: CONFIG_NETDEVICES | +-> CAN Device Drivers symbol: CONFIG_CAN_DEV | +-> software/virtual CAN device drivers | (at time of writing: slcan, vcan, vxcan) | +-> CAN device drivers with Netlink support symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) | +-> CAN bit-timing calculation (optional for all drivers) | symbol: CONFIG_CAN_CALC_BITTIMING | +-> All other CAN devices drivers (some may select CONFIG_CAN_RX_OFFLOAD) | +-> CAN rx offload (automatically selected by some drivers) (hidden symbol: CONFIG_CAN_RX_OFFLOAD) Patches 1 to 5 of this series do above modification. The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in can_dropped_invalid_skb() to discard tx skb (such skb can potentially reach the driver if injected via the packet socket). In more details, patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch 7 is the actual change. Those last two patches are actually connected to the first five ones: because slcan and v(x)can requires can_dropped_invalid_skb(), it was necessary to add those three devices to the scope of can-dev before moving the function to skb.o. This design results from the lengthy discussion in [1]. [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ ** Changelog ** v5 -> v6: * fix typo in patch #1's title: Kbuild -> Kconfig. * make CONFIG_RX_CAN an hidden config symbol and modify the diagram in the cover letter accordingly. @Oliver, with CONFIG_CAN_RX_OFFLOAD now being an hidden config, that option fully depends on the drivers. So contrary to your suggestion, I put CONFIG_CAN_RX_OFFLOAD below the device drivers in the diagram. * fix typo in cover letter: CONFIG_CAN_BITTIMING -> CONFIG_CAN_CALC_BITTIMING. v4 -> v5: * m_can is also requires RX offload. Add the "select CAN_RX_OFFLOAD" to its Makefile. * Reorder the lines of drivers/net/can/dev/Makefile. * Remove duplicated rx-offload.o target in drivers/net/can/dev/Makefile * Remove the Nota Bene in the cover letter. v3 -> v4: * Five additional patches added to split can-dev module and refactor Kbuild. c.f. below (lengthy) thread: https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ v2 -> v3: * Apply can_dropped_invalid_skb() to slcan. * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by modifying Kbuild. * fix small typos. v1 -> v2: * move can_dropped_invalid_skb() to skb.c instead of dev.h * also move can_skb_headroom_valid() to skb.c Vincent Mailhol (7): can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV can: bittiming: move bittiming calculation functions to calc_bittiming.c can: Kconfig: add CONFIG_CAN_RX_OFFLOAD net: Kconfig: move the CAN device menu to the "Device Drivers" section can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c can: skb: drop tx skb if in listen only mode drivers/net/Kconfig | 2 + drivers/net/can/Kconfig | 55 +++++-- drivers/net/can/dev/Makefile | 17 ++- drivers/net/can/dev/bittiming.c | 197 ------------------------- drivers/net/can/dev/calc_bittiming.c | 202 ++++++++++++++++++++++++++ drivers/net/can/dev/dev.c | 9 +- drivers/net/can/dev/skb.c | 72 +++++++++ drivers/net/can/m_can/Kconfig | 1 + drivers/net/can/spi/mcp251xfd/Kconfig | 1 + include/linux/can/skb.h | 59 +------- net/can/Kconfig | 5 +- 11 files changed, 338 insertions(+), 282 deletions(-) create mode 100644 drivers/net/can/dev/calc_bittiming.c -- 2.35.1 ^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH v6 1/7] can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol ` (8 subsequent siblings) 9 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol In the next patches, the scope of the can-dev module will grow to engloble the software/virtual drivers (slcan, v(x)can). To this extent, release CAN_DEV by renaming it into CAN_NETLINK. The config symbol CAN_DEV will be reused to cover this extended scope. The rationale for the name CAN_NETLINK is that netlink is the predominant feature added here. The current description only mentions platform drivers despite the fact that this symbol is also required by "normal" devices (e.g. USB or PCI) which do not fall under the platform devices category. The description is updated accordingly to fix this gap. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- Please share if you have any suggestion on the name. I hesitated a lot between CAN_NETLINK or CAN_DEV_NETLINK (because netlink is the predominant feature) and CAN_DEV_HW (because this targets the non-software only drivers, i.e. the hardware ones). --- drivers/net/can/Kconfig | 18 +++++++++++------- drivers/net/can/dev/Makefile | 2 +- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index b2dcc1e5a388..99f189ad35ad 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -48,15 +48,19 @@ config CAN_SLCAN can be changed by the 'maxdev=xx' module option. This driver can also be built as a module. If so, the module will be called slcan. -config CAN_DEV - tristate "Platform CAN drivers with Netlink support" +config CAN_NETLINK + tristate "CAN device drivers with Netlink support" default y help - Enables the common framework for platform CAN drivers with Netlink - support. This is the standard library for CAN drivers. - If unsure, say Y. + Enables the common framework for CAN device drivers. This is the + standard library and provides features for the Netlink interface such + as bittiming validation, support of CAN error states, device restart + and others. + + This is required by all platform and hardware CAN drivers. If you + plan to use such devices or if unsure, say Y. -if CAN_DEV +if CAN_NETLINK config CAN_CALC_BITTIMING bool "CAN bit-timing calculation" @@ -164,7 +168,7 @@ source "drivers/net/can/softing/Kconfig" source "drivers/net/can/spi/Kconfig" source "drivers/net/can/usb/Kconfig" -endif +endif #CAN_NETLINK config CAN_DEBUG_DEVICES bool "CAN devices debugging messages" diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index af2901db473c..5b4c813c6222 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_CAN_DEV) += can-dev.o +obj-$(CONFIG_CAN_NETLINK) += can-dev.o can-dev-y += bittiming.o can-dev-y += dev.o can-dev-y += length.o -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v6 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 1/7] can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol ` (7 subsequent siblings) 9 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol In the next patches, the software/virtual drivers (slcan, v(x)can) will depend on drivers/net/can/dev/skb.o. This patch changes the scope of the can-dev module to include the above mentioned drivers. To do so, we reuse the menu "CAN Device Drivers" and turn it into a configmenu using the config symbol CAN_DEV (which we released in previous patch). Also, add a description to this new CAN_DEV menuconfig. The symbol CAN_DEV now only triggers the build of skb.o. For this reasons, all the macros from linux/module.h are deported from drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c. Finally, drivers/net/can/dev/Makefile is adjusted accordingly. Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 29 ++++++++++++++++++++++++++--- drivers/net/can/dev/Makefile | 16 +++++++++------- drivers/net/can/dev/dev.c | 9 +-------- drivers/net/can/dev/skb.c | 7 +++++++ 4 files changed, 43 insertions(+), 18 deletions(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 99f189ad35ad..3c692af16676 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -1,5 +1,25 @@ # SPDX-License-Identifier: GPL-2.0-only -menu "CAN Device Drivers" + +menuconfig CAN_DEV + tristate "CAN Device Drivers" + default y + help + Controller Area Network (CAN) is serial communications protocol up to + 1Mbit/s for its original release (now known as Classical CAN) and up + to 8Mbit/s for the more recent CAN with Flexible Data-Rate + (CAN-FD). The CAN bus was originally mainly for automotive, but is now + widely used in marine (NMEA2000), industrial, and medical + applications. More information on the CAN network protocol family + PF_CAN is contained in <Documentation/networking/can.rst>. + + This section contains all the CAN(-FD) device drivers including the + virtual ones. If you own such devices or plan to use the virtual CAN + interfaces to develop applications, say Y here. + + To compile as a module, choose M here: the module will be called + can-dev. + +if CAN_DEV config CAN_VCAN tristate "Virtual Local CAN Interface (vcan)" @@ -49,7 +69,7 @@ config CAN_SLCAN also be built as a module. If so, the module will be called slcan. config CAN_NETLINK - tristate "CAN device drivers with Netlink support" + bool "CAN device drivers with Netlink support" default y help Enables the common framework for CAN device drivers. This is the @@ -57,6 +77,9 @@ config CAN_NETLINK as bittiming validation, support of CAN error states, device restart and others. + The additional features selected by this option will be added to the + can-dev module. + This is required by all platform and hardware CAN drivers. If you plan to use such devices or if unsure, say Y. @@ -178,4 +201,4 @@ config CAN_DEBUG_DEVICES a problem with CAN support and want to see more of what is going on. -endmenu +endif #CAN_DEV diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 5b4c813c6222..1baaf7020f7c 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -1,9 +1,11 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_CAN_NETLINK) += can-dev.o -can-dev-y += bittiming.o -can-dev-y += dev.o -can-dev-y += length.o -can-dev-y += netlink.o -can-dev-y += rx-offload.o -can-dev-y += skb.o +obj-$(CONFIG_CAN_DEV) += can-dev.o + +can-dev-y += skb.o + +can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o +can-dev-$(CONFIG_CAN_NETLINK) += dev.o +can-dev-$(CONFIG_CAN_NETLINK) += length.o +can-dev-$(CONFIG_CAN_NETLINK) += netlink.o +can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c index 96c9d9db00cf..523eaacfe29e 100644 --- a/drivers/net/can/dev/dev.c +++ b/drivers/net/can/dev/dev.c @@ -4,7 +4,6 @@ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> */ -#include <linux/module.h> #include <linux/kernel.h> #include <linux/slab.h> #include <linux/netdevice.h> @@ -17,12 +16,6 @@ #include <linux/gpio/consumer.h> #include <linux/of.h> -#define MOD_DESC "CAN device driver interface" - -MODULE_DESCRIPTION(MOD_DESC); -MODULE_LICENSE("GPL v2"); -MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>"); - static void can_update_state_error_stats(struct net_device *dev, enum can_state new_state) { @@ -513,7 +506,7 @@ static __init int can_dev_init(void) err = can_netlink_register(); if (!err) - pr_info(MOD_DESC "\n"); + pr_info("CAN device driver interface\n"); return err; } diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index 61660248c69e..a4208f125b76 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,13 @@ */ #include <linux/can/dev.h> +#include <linux/module.h> + +#define MOD_DESC "CAN device driver interface" + +MODULE_DESCRIPTION(MOD_DESC); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>"); /* Local echo of CAN messages * -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v6 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 1/7] can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol ` (6 subsequent siblings) 9 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol The canonical way to select or deselect an object during compilation is to use this pattern in the relevant Makefile: bar-$(CONFIG_FOO) := foo.o bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG. Create a new file named calc_bittiming.c with all the functions which are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the Makefile according to above pattern. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 4 + drivers/net/can/dev/Makefile | 1 + drivers/net/can/dev/bittiming.c | 197 -------------------------- drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++ 4 files changed, 207 insertions(+), 197 deletions(-) create mode 100644 drivers/net/can/dev/calc_bittiming.c diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 3c692af16676..87470feae6b1 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING source clock frequencies. Disabling saves some space, but then the bit-timing parameters must be specified directly using the Netlink arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw". + + The additional features selected by this option will be added to the + can-dev module. + If unsure, say Y. config CAN_AT91 diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 1baaf7020f7c..791e6b297ea3 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_CAN_DEV) += can-dev.o can-dev-y += skb.o +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o diff --git a/drivers/net/can/dev/bittiming.c b/drivers/net/can/dev/bittiming.c index c1e76f0a5064..7ae80763c960 100644 --- a/drivers/net/can/dev/bittiming.c +++ b/drivers/net/can/dev/bittiming.c @@ -4,205 +4,8 @@ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> */ -#include <linux/units.h> #include <linux/can/dev.h> -#ifdef CONFIG_CAN_CALC_BITTIMING -#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */ - -/* Bit-timing calculation derived from: - * - * Code based on LinCAN sources and H8S2638 project - * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz - * Copyright 2005 Stanislav Marek - * email: pisa@cmp.felk.cvut.cz - * - * Calculates proper bit-timing parameters for a specified bit-rate - * and sample-point, which can then be used to set the bit-timing - * registers of the CAN controller. You can find more information - * in the header file linux/can/netlink.h. - */ -static int -can_update_sample_point(const struct can_bittiming_const *btc, - const unsigned int sample_point_nominal, const unsigned int tseg, - unsigned int *tseg1_ptr, unsigned int *tseg2_ptr, - unsigned int *sample_point_error_ptr) -{ - unsigned int sample_point_error, best_sample_point_error = UINT_MAX; - unsigned int sample_point, best_sample_point = 0; - unsigned int tseg1, tseg2; - int i; - - for (i = 0; i <= 1; i++) { - tseg2 = tseg + CAN_SYNC_SEG - - (sample_point_nominal * (tseg + CAN_SYNC_SEG)) / - 1000 - i; - tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max); - tseg1 = tseg - tseg2; - if (tseg1 > btc->tseg1_max) { - tseg1 = btc->tseg1_max; - tseg2 = tseg - tseg1; - } - - sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) / - (tseg + CAN_SYNC_SEG); - sample_point_error = abs(sample_point_nominal - sample_point); - - if (sample_point <= sample_point_nominal && - sample_point_error < best_sample_point_error) { - best_sample_point = sample_point; - best_sample_point_error = sample_point_error; - *tseg1_ptr = tseg1; - *tseg2_ptr = tseg2; - } - } - - if (sample_point_error_ptr) - *sample_point_error_ptr = best_sample_point_error; - - return best_sample_point; -} - -int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt, - const struct can_bittiming_const *btc) -{ - struct can_priv *priv = netdev_priv(dev); - unsigned int bitrate; /* current bitrate */ - unsigned int bitrate_error; /* difference between current and nominal value */ - unsigned int best_bitrate_error = UINT_MAX; - unsigned int sample_point_error; /* difference between current and nominal value */ - unsigned int best_sample_point_error = UINT_MAX; - unsigned int sample_point_nominal; /* nominal sample point */ - unsigned int best_tseg = 0; /* current best value for tseg */ - unsigned int best_brp = 0; /* current best value for brp */ - unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0; - u64 v64; - - /* Use CiA recommended sample points */ - if (bt->sample_point) { - sample_point_nominal = bt->sample_point; - } else { - if (bt->bitrate > 800 * KILO /* BPS */) - sample_point_nominal = 750; - else if (bt->bitrate > 500 * KILO /* BPS */) - sample_point_nominal = 800; - else - sample_point_nominal = 875; - } - - /* tseg even = round down, odd = round up */ - for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1; - tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) { - tsegall = CAN_SYNC_SEG + tseg / 2; - - /* Compute all possible tseg choices (tseg=tseg1+tseg2) */ - brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2; - - /* choose brp step which is possible in system */ - brp = (brp / btc->brp_inc) * btc->brp_inc; - if (brp < btc->brp_min || brp > btc->brp_max) - continue; - - bitrate = priv->clock.freq / (brp * tsegall); - bitrate_error = abs(bt->bitrate - bitrate); - - /* tseg brp biterror */ - if (bitrate_error > best_bitrate_error) - continue; - - /* reset sample point error if we have a better bitrate */ - if (bitrate_error < best_bitrate_error) - best_sample_point_error = UINT_MAX; - - can_update_sample_point(btc, sample_point_nominal, tseg / 2, - &tseg1, &tseg2, &sample_point_error); - if (sample_point_error >= best_sample_point_error) - continue; - - best_sample_point_error = sample_point_error; - best_bitrate_error = bitrate_error; - best_tseg = tseg / 2; - best_brp = brp; - - if (bitrate_error == 0 && sample_point_error == 0) - break; - } - - if (best_bitrate_error) { - /* Error in one-tenth of a percent */ - v64 = (u64)best_bitrate_error * 1000; - do_div(v64, bt->bitrate); - bitrate_error = (u32)v64; - if (bitrate_error > CAN_CALC_MAX_ERROR) { - netdev_err(dev, - "bitrate error %d.%d%% too high\n", - bitrate_error / 10, bitrate_error % 10); - return -EDOM; - } - netdev_warn(dev, "bitrate error %d.%d%%\n", - bitrate_error / 10, bitrate_error % 10); - } - - /* real sample point */ - bt->sample_point = can_update_sample_point(btc, sample_point_nominal, - best_tseg, &tseg1, &tseg2, - NULL); - - v64 = (u64)best_brp * 1000 * 1000 * 1000; - do_div(v64, priv->clock.freq); - bt->tq = (u32)v64; - bt->prop_seg = tseg1 / 2; - bt->phase_seg1 = tseg1 - bt->prop_seg; - bt->phase_seg2 = tseg2; - - /* check for sjw user settings */ - if (!bt->sjw || !btc->sjw_max) { - bt->sjw = 1; - } else { - /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */ - if (bt->sjw > btc->sjw_max) - bt->sjw = btc->sjw_max; - /* bt->sjw must not be higher than tseg2 */ - if (tseg2 < bt->sjw) - bt->sjw = tseg2; - } - - bt->brp = best_brp; - - /* real bitrate */ - bt->bitrate = priv->clock.freq / - (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2)); - - return 0; -} - -void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const, - const struct can_bittiming *dbt, - u32 *ctrlmode, u32 ctrlmode_supported) - -{ - if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO)) - return; - - *ctrlmode &= ~CAN_CTRLMODE_TDC_MASK; - - /* As specified in ISO 11898-1 section 11.3.3 "Transmitter - * delay compensation" (TDC) is only applicable if data BRP is - * one or two. - */ - if (dbt->brp == 1 || dbt->brp == 2) { - /* Sample point in clock periods */ - u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg + - dbt->phase_seg1) * dbt->brp; - - if (sample_point_in_tc < tdc_const->tdco_min) - return; - tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max); - *ctrlmode |= CAN_CTRLMODE_TDC_AUTO; - } -} -#endif /* CONFIG_CAN_CALC_BITTIMING */ - /* Checks the validity of the specified bit-timing parameters prop_seg, * phase_seg1, phase_seg2 and sjw and tries to determine the bitrate * prescaler value brp. You can find more information in the header diff --git a/drivers/net/can/dev/calc_bittiming.c b/drivers/net/can/dev/calc_bittiming.c new file mode 100644 index 000000000000..d3caa040614d --- /dev/null +++ b/drivers/net/can/dev/calc_bittiming.c @@ -0,0 +1,202 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* Copyright (C) 2005 Marc Kleine-Budde, Pengutronix + * Copyright (C) 2006 Andrey Volkov, Varma Electronics + * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com> + */ + +#include <linux/units.h> +#include <linux/can/dev.h> + +#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */ + +/* Bit-timing calculation derived from: + * + * Code based on LinCAN sources and H8S2638 project + * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz + * Copyright 2005 Stanislav Marek + * email: pisa@cmp.felk.cvut.cz + * + * Calculates proper bit-timing parameters for a specified bit-rate + * and sample-point, which can then be used to set the bit-timing + * registers of the CAN controller. You can find more information + * in the header file linux/can/netlink.h. + */ +static int +can_update_sample_point(const struct can_bittiming_const *btc, + const unsigned int sample_point_nominal, const unsigned int tseg, + unsigned int *tseg1_ptr, unsigned int *tseg2_ptr, + unsigned int *sample_point_error_ptr) +{ + unsigned int sample_point_error, best_sample_point_error = UINT_MAX; + unsigned int sample_point, best_sample_point = 0; + unsigned int tseg1, tseg2; + int i; + + for (i = 0; i <= 1; i++) { + tseg2 = tseg + CAN_SYNC_SEG - + (sample_point_nominal * (tseg + CAN_SYNC_SEG)) / + 1000 - i; + tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max); + tseg1 = tseg - tseg2; + if (tseg1 > btc->tseg1_max) { + tseg1 = btc->tseg1_max; + tseg2 = tseg - tseg1; + } + + sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) / + (tseg + CAN_SYNC_SEG); + sample_point_error = abs(sample_point_nominal - sample_point); + + if (sample_point <= sample_point_nominal && + sample_point_error < best_sample_point_error) { + best_sample_point = sample_point; + best_sample_point_error = sample_point_error; + *tseg1_ptr = tseg1; + *tseg2_ptr = tseg2; + } + } + + if (sample_point_error_ptr) + *sample_point_error_ptr = best_sample_point_error; + + return best_sample_point; +} + +int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt, + const struct can_bittiming_const *btc) +{ + struct can_priv *priv = netdev_priv(dev); + unsigned int bitrate; /* current bitrate */ + unsigned int bitrate_error; /* difference between current and nominal value */ + unsigned int best_bitrate_error = UINT_MAX; + unsigned int sample_point_error; /* difference between current and nominal value */ + unsigned int best_sample_point_error = UINT_MAX; + unsigned int sample_point_nominal; /* nominal sample point */ + unsigned int best_tseg = 0; /* current best value for tseg */ + unsigned int best_brp = 0; /* current best value for brp */ + unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0; + u64 v64; + + /* Use CiA recommended sample points */ + if (bt->sample_point) { + sample_point_nominal = bt->sample_point; + } else { + if (bt->bitrate > 800 * KILO /* BPS */) + sample_point_nominal = 750; + else if (bt->bitrate > 500 * KILO /* BPS */) + sample_point_nominal = 800; + else + sample_point_nominal = 875; + } + + /* tseg even = round down, odd = round up */ + for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1; + tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) { + tsegall = CAN_SYNC_SEG + tseg / 2; + + /* Compute all possible tseg choices (tseg=tseg1+tseg2) */ + brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2; + + /* choose brp step which is possible in system */ + brp = (brp / btc->brp_inc) * btc->brp_inc; + if (brp < btc->brp_min || brp > btc->brp_max) + continue; + + bitrate = priv->clock.freq / (brp * tsegall); + bitrate_error = abs(bt->bitrate - bitrate); + + /* tseg brp biterror */ + if (bitrate_error > best_bitrate_error) + continue; + + /* reset sample point error if we have a better bitrate */ + if (bitrate_error < best_bitrate_error) + best_sample_point_error = UINT_MAX; + + can_update_sample_point(btc, sample_point_nominal, tseg / 2, + &tseg1, &tseg2, &sample_point_error); + if (sample_point_error >= best_sample_point_error) + continue; + + best_sample_point_error = sample_point_error; + best_bitrate_error = bitrate_error; + best_tseg = tseg / 2; + best_brp = brp; + + if (bitrate_error == 0 && sample_point_error == 0) + break; + } + + if (best_bitrate_error) { + /* Error in one-tenth of a percent */ + v64 = (u64)best_bitrate_error * 1000; + do_div(v64, bt->bitrate); + bitrate_error = (u32)v64; + if (bitrate_error > CAN_CALC_MAX_ERROR) { + netdev_err(dev, + "bitrate error %d.%d%% too high\n", + bitrate_error / 10, bitrate_error % 10); + return -EDOM; + } + netdev_warn(dev, "bitrate error %d.%d%%\n", + bitrate_error / 10, bitrate_error % 10); + } + + /* real sample point */ + bt->sample_point = can_update_sample_point(btc, sample_point_nominal, + best_tseg, &tseg1, &tseg2, + NULL); + + v64 = (u64)best_brp * 1000 * 1000 * 1000; + do_div(v64, priv->clock.freq); + bt->tq = (u32)v64; + bt->prop_seg = tseg1 / 2; + bt->phase_seg1 = tseg1 - bt->prop_seg; + bt->phase_seg2 = tseg2; + + /* check for sjw user settings */ + if (!bt->sjw || !btc->sjw_max) { + bt->sjw = 1; + } else { + /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */ + if (bt->sjw > btc->sjw_max) + bt->sjw = btc->sjw_max; + /* bt->sjw must not be higher than tseg2 */ + if (tseg2 < bt->sjw) + bt->sjw = tseg2; + } + + bt->brp = best_brp; + + /* real bitrate */ + bt->bitrate = priv->clock.freq / + (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2)); + + return 0; +} + +void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const, + const struct can_bittiming *dbt, + u32 *ctrlmode, u32 ctrlmode_supported) + +{ + if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO)) + return; + + *ctrlmode &= ~CAN_CTRLMODE_TDC_MASK; + + /* As specified in ISO 11898-1 section 11.3.3 "Transmitter + * delay compensation" (TDC) is only applicable if data BRP is + * one or two. + */ + if (dbt->brp == 1 || dbt->brp == 2) { + /* Sample point in clock periods */ + u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg + + dbt->phase_seg1) * dbt->brp; + + if (sample_point_in_tc < tdc_const->tdco_min) + return; + tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max); + *ctrlmode |= CAN_CTRLMODE_TDC_AUTO; + } +} -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v6 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol ` (2 preceding siblings ...) 2022-06-10 14:30 ` [PATCH v6 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol ` (5 subsequent siblings) 9 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol Only a few drivers rely on the CAN rx offload framework (as of the writing of this patch, only four: flexcan, m_can, mcp251xfd and ti_hecc). Split it out of can-dev and add a new config symbol: CAN_RX_OFFLOAD. The drivers relying on CAN rx offload are in different sub folders. Make CAN_RX_OFFLOAD an hidden option and tag all the drivers depending on that feature with "select CAN_RX_OFFLOAD" so that the option gets automatically enabled if and only if one of those drivers is chosen. Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/Kconfig | 5 +++++ drivers/net/can/dev/Makefile | 2 +- drivers/net/can/m_can/Kconfig | 1 + drivers/net/can/spi/mcp251xfd/Kconfig | 1 + 4 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 87470feae6b1..5335f3afc0a5 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -102,6 +102,9 @@ config CAN_CALC_BITTIMING If unsure, say Y. +config CAN_RX_OFFLOAD + bool + config CAN_AT91 tristate "Atmel AT91 onchip CAN controller" depends on (ARCH_AT91 || COMPILE_TEST) && HAS_IOMEM @@ -113,6 +116,7 @@ config CAN_FLEXCAN tristate "Support for Freescale FLEXCAN based chips" depends on OF || COLDFIRE || COMPILE_TEST depends on HAS_IOMEM + select CAN_RX_OFFLOAD help Say Y here if you want to support for Freescale FlexCAN. @@ -162,6 +166,7 @@ config CAN_SUN4I config CAN_TI_HECC depends on ARM tristate "TI High End CAN Controller" + select CAN_RX_OFFLOAD help Driver for TI HECC (High End CAN Controller) module found on many TI devices. The device specifications are available from www.ti.com diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile index 791e6b297ea3..633687d6b6c0 100644 --- a/drivers/net/can/dev/Makefile +++ b/drivers/net/can/dev/Makefile @@ -9,4 +9,4 @@ can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o can-dev-$(CONFIG_CAN_NETLINK) += dev.o can-dev-$(CONFIG_CAN_NETLINK) += length.o can-dev-$(CONFIG_CAN_NETLINK) += netlink.o -can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o +can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig index 45ad1b3f0cd0..fc2afab36279 100644 --- a/drivers/net/can/m_can/Kconfig +++ b/drivers/net/can/m_can/Kconfig @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only menuconfig CAN_M_CAN tristate "Bosch M_CAN support" + select CAN_RX_OFFLOAD help Say Y here if you want support for Bosch M_CAN controller framework. This is common support for devices that embed the Bosch M_CAN IP. diff --git a/drivers/net/can/spi/mcp251xfd/Kconfig b/drivers/net/can/spi/mcp251xfd/Kconfig index dd0fc0a54be1..877e4356010d 100644 --- a/drivers/net/can/spi/mcp251xfd/Kconfig +++ b/drivers/net/can/spi/mcp251xfd/Kconfig @@ -2,6 +2,7 @@ config CAN_MCP251XFD tristate "Microchip MCP251xFD SPI CAN controllers" + select CAN_RX_OFFLOAD select REGMAP select WANT_DEV_COREDUMP help -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v6 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol ` (3 preceding siblings ...) 2022-06-10 14:30 ` [PATCH v6 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol ` (4 subsequent siblings) 9 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol The devices are meant to be under the "Device Drivers" category of the menuconfig. The CAN subsystem is currently one of the rare exception with all of its devices under the "Networking support" category. The CAN_DEV menuentry gets moved to fix this discrepancy. The CAN menu is added just before MCTP in order to be consistent with the current order under the "Networking support" menu. A dependency on CAN is added to CAN_DEV so that the CAN devices only show up if the CAN subsystem is enabled. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/Kconfig | 2 ++ drivers/net/can/Kconfig | 1 + net/can/Kconfig | 5 ++--- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index b2a4f998c180..5de243899de8 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -499,6 +499,8 @@ config NET_SB1000 source "drivers/net/phy/Kconfig" +source "drivers/net/can/Kconfig" + source "drivers/net/mctp/Kconfig" source "drivers/net/mdio/Kconfig" diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 5335f3afc0a5..806f15146f69 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -3,6 +3,7 @@ menuconfig CAN_DEV tristate "CAN Device Drivers" default y + depends on CAN help Controller Area Network (CAN) is serial communications protocol up to 1Mbit/s for its original release (now known as Classical CAN) and up diff --git a/net/can/Kconfig b/net/can/Kconfig index a9ac5ffab286..cb56be8e3862 100644 --- a/net/can/Kconfig +++ b/net/can/Kconfig @@ -15,7 +15,8 @@ menuconfig CAN PF_CAN is contained in <Documentation/networking/can.rst>. If you want CAN support you should say Y here and also to the - specific driver for your controller(s) below. + specific driver for your controller(s) under the Network device + support section. if CAN @@ -69,6 +70,4 @@ config CAN_ISOTP If you want to perform automotive vehicle diagnostic services (UDS), say 'y'. -source "drivers/net/can/Kconfig" - endif -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v6 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol ` (4 preceding siblings ...) 2022-06-10 14:30 ` [PATCH v6 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol ` (3 subsequent siblings) 9 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol The functions can_dropped_invalid_skb() and can_skb_headroom_valid() grew a lot over the years to a point which it does not make much sense to have them defined as static inline in header files. Move those two functions to the .c counterpart of skb.h. can_skb_headroom_valid()'s only caller being can_dropped_invalid_skb(), the declaration is removed from the header. Only can_dropped_invalid_skb() gets its symbol exported. While doing so, do a small cleanup: add brackets around the else block in can_dropped_invalid_skb(). Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 58 ++++++++++++++++++++++++++++++++++++++ include/linux/can/skb.h | 59 +-------------------------------------- 2 files changed, 59 insertions(+), 58 deletions(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index a4208f125b76..dc9da76c0470 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -259,3 +259,61 @@ struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf) return skb; } EXPORT_SYMBOL_GPL(alloc_can_err_skb); + +/* Check for outgoing skbs that have not been created by the CAN subsystem */ +static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) +{ + /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ + if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) + return false; + + /* af_packet does not apply CAN skb specific settings */ + if (skb->ip_summed == CHECKSUM_NONE) { + /* init headroom */ + can_skb_prv(skb)->ifindex = dev->ifindex; + can_skb_prv(skb)->skbcnt = 0; + + skb->ip_summed = CHECKSUM_UNNECESSARY; + + /* perform proper loopback on capable devices */ + if (dev->flags & IFF_ECHO) + skb->pkt_type = PACKET_LOOPBACK; + else + skb->pkt_type = PACKET_HOST; + + skb_reset_mac_header(skb); + skb_reset_network_header(skb); + skb_reset_transport_header(skb); + } + + return true; +} + +/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) +{ + const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + + if (skb->protocol == htons(ETH_P_CAN)) { + if (unlikely(skb->len != CAN_MTU || + cfd->len > CAN_MAX_DLEN)) + goto inval_skb; + } else if (skb->protocol == htons(ETH_P_CANFD)) { + if (unlikely(skb->len != CANFD_MTU || + cfd->len > CANFD_MAX_DLEN)) + goto inval_skb; + } else { + goto inval_skb; + } + + if (!can_skb_headroom_valid(dev, skb)) + goto inval_skb; + + return false; + +inval_skb: + kfree_skb(skb); + dev->stats.tx_dropped++; + return true; +} +EXPORT_SYMBOL_GPL(can_dropped_invalid_skb); diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index fdb22b00674a..182749e858b3 100644 --- a/include/linux/can/skb.h +++ b/include/linux/can/skb.h @@ -31,6 +31,7 @@ struct sk_buff *alloc_canfd_skb(struct net_device *dev, struct canfd_frame **cfd); struct sk_buff *alloc_can_err_skb(struct net_device *dev, struct can_frame **cf); +bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb); /* * The struct can_skb_priv is used to transport additional information along @@ -96,64 +97,6 @@ static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb) return nskb; } -/* Check for outgoing skbs that have not been created by the CAN subsystem */ -static inline bool can_skb_headroom_valid(struct net_device *dev, - struct sk_buff *skb) -{ - /* af_packet creates a headroom of HH_DATA_MOD bytes which is fine */ - if (WARN_ON_ONCE(skb_headroom(skb) < sizeof(struct can_skb_priv))) - return false; - - /* af_packet does not apply CAN skb specific settings */ - if (skb->ip_summed == CHECKSUM_NONE) { - /* init headroom */ - can_skb_prv(skb)->ifindex = dev->ifindex; - can_skb_prv(skb)->skbcnt = 0; - - skb->ip_summed = CHECKSUM_UNNECESSARY; - - /* perform proper loopback on capable devices */ - if (dev->flags & IFF_ECHO) - skb->pkt_type = PACKET_LOOPBACK; - else - skb->pkt_type = PACKET_HOST; - - skb_reset_mac_header(skb); - skb_reset_network_header(skb); - skb_reset_transport_header(skb); - } - - return true; -} - -/* Drop a given socketbuffer if it does not contain a valid CAN frame. */ -static inline bool can_dropped_invalid_skb(struct net_device *dev, - struct sk_buff *skb) -{ - const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; - - if (skb->protocol == htons(ETH_P_CAN)) { - if (unlikely(skb->len != CAN_MTU || - cfd->len > CAN_MAX_DLEN)) - goto inval_skb; - } else if (skb->protocol == htons(ETH_P_CANFD)) { - if (unlikely(skb->len != CANFD_MTU || - cfd->len > CANFD_MAX_DLEN)) - goto inval_skb; - } else - goto inval_skb; - - if (!can_skb_headroom_valid(dev, skb)) - goto inval_skb; - - return false; - -inval_skb: - kfree_skb(skb); - dev->stats.tx_dropped++; - return true; -} - static inline bool can_is_canfd_skb(const struct sk_buff *skb) { /* the CAN specific type of skb is identified by its data length */ -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH v6 7/7] can: skb: drop tx skb if in listen only mode 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol ` (5 preceding siblings ...) 2022-06-10 14:30 ` [PATCH v6 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol @ 2022-06-10 14:30 ` Vincent Mailhol 2022-06-10 21:38 ` [PATCH v6 0/7] can: refactoring of can-dev module and of Kbuild Oliver Hartkopp ` (2 subsequent siblings) 9 siblings, 0 replies; 119+ messages in thread From: Vincent Mailhol @ 2022-06-10 14:30 UTC (permalink / raw) To: Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski, Vincent Mailhol Frames can be directly injected to a can driver via the packet socket. By doing so, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configured in listen only mode. Add a check in can_dropped_invalid_skb() to discard the skb if CAN_CTRLMODE_LISTENONLY is set. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> --- drivers/net/can/dev/skb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/dev/skb.c b/drivers/net/can/dev/skb.c index dc9da76c0470..8bb62dd864c8 100644 --- a/drivers/net/can/dev/skb.c +++ b/drivers/net/can/dev/skb.c @@ -5,6 +5,7 @@ */ #include <linux/can/dev.h> +#include <linux/can/netlink.h> #include <linux/module.h> #define MOD_DESC "CAN device driver interface" @@ -293,6 +294,7 @@ static bool can_skb_headroom_valid(struct net_device *dev, struct sk_buff *skb) bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) { const struct canfd_frame *cfd = (struct canfd_frame *)skb->data; + struct can_priv *priv = netdev_priv(dev); if (skb->protocol == htons(ETH_P_CAN)) { if (unlikely(skb->len != CAN_MTU || @@ -306,8 +308,13 @@ bool can_dropped_invalid_skb(struct net_device *dev, struct sk_buff *skb) goto inval_skb; } - if (!can_skb_headroom_valid(dev, skb)) + if (!can_skb_headroom_valid(dev, skb)) { + goto inval_skb; + } else if (priv->ctrlmode & CAN_CTRLMODE_LISTENONLY) { + netdev_info_once(dev, + "interface in listen only mode, dropping skb\n"); goto inval_skb; + } return false; -- 2.35.1 ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH v6 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol ` (6 preceding siblings ...) 2022-06-10 14:30 ` [PATCH v6 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol @ 2022-06-10 21:38 ` Oliver Hartkopp 2022-06-10 22:43 ` Max Staudt 2022-06-11 15:17 ` Marc Kleine-Budde 9 siblings, 0 replies; 119+ messages in thread From: Oliver Hartkopp @ 2022-06-10 21:38 UTC (permalink / raw) To: Vincent Mailhol, Marc Kleine-Budde Cc: linux-can, linux-kernel, Max Staudt, netdev, Geert Uytterhoeven, Jakub Kicinski On 10.06.22 16:30, Vincent Mailhol wrote: > Aside of calc_bittiming.o which can be configured with > CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked > unconditionally to can-dev.o even if not needed by the user. > > This series first goal it to split the can-dev modules so that the > only the needed features get built in during compilation. > Additionally, the CAN Device Drivers menu is moved from the > "Networking support" category to the "Device Drivers" category (where > all drivers are supposed to be). > > > * menu before this series * > > CAN bus subsystem support > symbol: CONFIG_CAN > | > +-> CAN Device Drivers > (no symbol) > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> Platform CAN drivers with Netlink support > symbol: CONFIG_CAN_DEV > | > +-> CAN bit-timing calculation (optional for hardware drivers) > | symbol: CONFIG_CAN_CALC_BITTIMING > | > +-> All other CAN devices drivers > > * menu after this series * > > Network device support > symbol: CONFIG_NETDEVICES > | > +-> CAN Device Drivers > symbol: CONFIG_CAN_DEV > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> CAN device drivers with Netlink support > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > | > +-> CAN bit-timing calculation (optional for all drivers) > | symbol: CONFIG_CAN_CALC_BITTIMING > | > +-> All other CAN devices drivers > (some may select CONFIG_CAN_RX_OFFLOAD) > | > +-> CAN rx offload (automatically selected by some drivers) > (hidden symbol: CONFIG_CAN_RX_OFFLOAD) > > Patches 1 to 5 of this series do above modification. > > The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in > can_dropped_invalid_skb() to discard tx skb (such skb can potentially > reach the driver if injected via the packet socket). In more details, > patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch > 7 is the actual change. > > Those last two patches are actually connected to the first five ones: > because slcan and v(x)can requires can_dropped_invalid_skb(), it was > necessary to add those three devices to the scope of can-dev before > moving the function to skb.o. > > This design results from the lengthy discussion in [1]. > > [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > > > ** Changelog ** > > v5 -> v6: > > * fix typo in patch #1's title: Kbuild -> Kconfig. > > * make CONFIG_RX_CAN an hidden config symbol and modify the diagram > in the cover letter accordingly. > > @Oliver, with CONFIG_CAN_RX_OFFLOAD now being an hidden config, > that option fully depends on the drivers. So contrary to your > suggestion, I put CONFIG_CAN_RX_OFFLOAD below the device drivers > in the diagram. Yes, fine for me. I did some Kconfig configuration tests and built the drivers to see vcan.ko depending on can-dev.ko at module loading the first time ;-) Nice work. So for these bits I can provide a Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Thanks, Oliver > > * fix typo in cover letter: CONFIG_CAN_BITTIMING -> CONFIG_CAN_CALC_BITTIMING. > > v4 -> v5: > > * m_can is also requires RX offload. Add the "select CAN_RX_OFFLOAD" > to its Makefile. > > * Reorder the lines of drivers/net/can/dev/Makefile. > > * Remove duplicated rx-offload.o target in drivers/net/can/dev/Makefile > > * Remove the Nota Bene in the cover letter. > > > v3 -> v4: > > * Five additional patches added to split can-dev module and refactor > Kbuild. c.f. below (lengthy) thread: > https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > > > v2 -> v3: > > * Apply can_dropped_invalid_skb() to slcan. > > * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by > modifying Kbuild. > > * fix small typos. > > v1 -> v2: > > * move can_dropped_invalid_skb() to skb.c instead of dev.h > > * also move can_skb_headroom_valid() to skb.c > > Vincent Mailhol (7): > can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK > can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using > CAN_DEV > can: bittiming: move bittiming calculation functions to > calc_bittiming.c > can: Kconfig: add CONFIG_CAN_RX_OFFLOAD > net: Kconfig: move the CAN device menu to the "Device Drivers" section > can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() > to skb.c > can: skb: drop tx skb if in listen only mode > > drivers/net/Kconfig | 2 + > drivers/net/can/Kconfig | 55 +++++-- > drivers/net/can/dev/Makefile | 17 ++- > drivers/net/can/dev/bittiming.c | 197 ------------------------- > drivers/net/can/dev/calc_bittiming.c | 202 ++++++++++++++++++++++++++ > drivers/net/can/dev/dev.c | 9 +- > drivers/net/can/dev/skb.c | 72 +++++++++ > drivers/net/can/m_can/Kconfig | 1 + > drivers/net/can/spi/mcp251xfd/Kconfig | 1 + > include/linux/can/skb.h | 59 +------- > net/can/Kconfig | 5 +- > 11 files changed, 338 insertions(+), 282 deletions(-) > create mode 100644 drivers/net/can/dev/calc_bittiming.c > ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v6 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol ` (7 preceding siblings ...) 2022-06-10 21:38 ` [PATCH v6 0/7] can: refactoring of can-dev module and of Kbuild Oliver Hartkopp @ 2022-06-10 22:43 ` Max Staudt 2022-06-11 15:17 ` Marc Kleine-Budde 9 siblings, 0 replies; 119+ messages in thread From: Max Staudt @ 2022-06-10 22:43 UTC (permalink / raw) To: Vincent Mailhol Cc: Marc Kleine-Budde, linux-can, linux-kernel, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski Looks good to me. Thanks Vincent for this clean-up, and thanks to everyone involved for the discussion, reviews, and testing! Acked-by: Max Staudt <max@enpas.org> ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH v6 0/7] can: refactoring of can-dev module and of Kbuild 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol ` (8 preceding siblings ...) 2022-06-10 22:43 ` Max Staudt @ 2022-06-11 15:17 ` Marc Kleine-Budde 9 siblings, 0 replies; 119+ messages in thread From: Marc Kleine-Budde @ 2022-06-11 15:17 UTC (permalink / raw) To: Vincent Mailhol Cc: linux-can, linux-kernel, Max Staudt, Oliver Hartkopp, netdev, Geert Uytterhoeven, Jakub Kicinski [-- Attachment #1: Type: text/plain, Size: 4611 bytes --] On 10.06.2022 23:30:02, Vincent Mailhol wrote: > Aside of calc_bittiming.o which can be configured with > CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked > unconditionally to can-dev.o even if not needed by the user. > > This series first goal it to split the can-dev modules so that the > only the needed features get built in during compilation. > Additionally, the CAN Device Drivers menu is moved from the > "Networking support" category to the "Device Drivers" category (where > all drivers are supposed to be). > > > * menu before this series * > > CAN bus subsystem support > symbol: CONFIG_CAN > | > +-> CAN Device Drivers > (no symbol) > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> Platform CAN drivers with Netlink support > symbol: CONFIG_CAN_DEV > | > +-> CAN bit-timing calculation (optional for hardware drivers) > | symbol: CONFIG_CAN_CALC_BITTIMING > | > +-> All other CAN devices drivers > > * menu after this series * > > Network device support > symbol: CONFIG_NETDEVICES > | > +-> CAN Device Drivers > symbol: CONFIG_CAN_DEV > | > +-> software/virtual CAN device drivers > | (at time of writing: slcan, vcan, vxcan) > | > +-> CAN device drivers with Netlink support > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > | > +-> CAN bit-timing calculation (optional for all drivers) > | symbol: CONFIG_CAN_CALC_BITTIMING > | > +-> All other CAN devices drivers > (some may select CONFIG_CAN_RX_OFFLOAD) > | > +-> CAN rx offload (automatically selected by some drivers) > (hidden symbol: CONFIG_CAN_RX_OFFLOAD) > > Patches 1 to 5 of this series do above modification. > > The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in > can_dropped_invalid_skb() to discard tx skb (such skb can potentially > reach the driver if injected via the packet socket). In more details, > patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch > 7 is the actual change. > > Those last two patches are actually connected to the first five ones: > because slcan and v(x)can requires can_dropped_invalid_skb(), it was > necessary to add those three devices to the scope of can-dev before > moving the function to skb.o. > > This design results from the lengthy discussion in [1]. > > [1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > > > ** Changelog ** > > v5 -> v6: > > * fix typo in patch #1's title: Kbuild -> Kconfig. > > * make CONFIG_RX_CAN an hidden config symbol and modify the diagram > in the cover letter accordingly. > > @Oliver, with CONFIG_CAN_RX_OFFLOAD now being an hidden config, > that option fully depends on the drivers. So contrary to your > suggestion, I put CONFIG_CAN_RX_OFFLOAD below the device drivers > in the diagram. > > * fix typo in cover letter: CONFIG_CAN_BITTIMING -> CONFIG_CAN_CALC_BITTIMING. > > v4 -> v5: > > * m_can is also requires RX offload. Add the "select CAN_RX_OFFLOAD" > to its Makefile. > > * Reorder the lines of drivers/net/can/dev/Makefile. > > * Remove duplicated rx-offload.o target in drivers/net/can/dev/Makefile > > * Remove the Nota Bene in the cover letter. > > > v3 -> v4: > > * Five additional patches added to split can-dev module and refactor > Kbuild. c.f. below (lengthy) thread: > https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/ > > > v2 -> v3: > > * Apply can_dropped_invalid_skb() to slcan. > > * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by > modifying Kbuild. > > * fix small typos. > > v1 -> v2: > > * move can_dropped_invalid_skb() to skb.c instead of dev.h > > * also move can_skb_headroom_valid() to skb.c Applied to can-next/master....as a merge with the above message! Congrats on this series and the first ever merge to the linux-can branch! 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 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
end of thread, other threads:[~2022-06-11 15:18 UTC | newest] Thread overview: 119+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-13 14:23 [PATCH 0/2] can: drop tx skb if the device is in listen only mode Vincent Mailhol 2022-05-13 14:23 ` [PATCH 1/2] can: move can_dropped_invalid_skb from skb.h to dev.h Vincent Mailhol 2022-05-13 14:23 ` [PATCH 2/2] can: dev: drop tx skb if in listen only mode Vincent Mailhol 2022-05-13 14:42 ` [PATCH 0/2] can: drop tx skb if the device is " Marc Kleine-Budde 2022-05-13 15:20 ` Vincent MAILHOL 2022-05-13 15:36 ` [PATCH v2 " Vincent Mailhol 2022-05-13 15:36 ` [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol 2022-05-14 4:20 ` kernel test robot 2022-05-14 5:16 ` Vincent MAILHOL 2022-05-14 11:17 ` Max Staudt 2022-05-13 15:36 ` [PATCH v2 2/2] can: dev: drop tx skb if in listen only mode Vincent Mailhol 2022-05-13 17:40 ` [PATCH v2 0/2] can: drop tx skb if the device is " Max Staudt 2022-05-14 3:00 ` Vincent MAILHOL 2022-05-14 14:16 ` [PATCH v3 0/4] can: can_dropped_invalid_skb() and Kbuild changes Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 1/4] can: slcan: use can_dropped_invalid_skb() instead of manual check Vincent Mailhol 2022-05-16 20:40 ` Marc Kleine-Budde 2022-05-14 14:16 ` [PATCH v3 2/4] can: Kconfig: change CAN_DEV into a menuconfig Vincent Mailhol 2022-05-14 14:16 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Vincent Mailhol 2022-05-15 19:17 ` Oliver Hartkopp 2022-05-17 1:50 ` Vincent MAILHOL 2022-05-17 4:12 ` Max Staudt 2022-05-17 6:08 ` Marc Kleine-Budde 2022-05-17 7:04 ` Vincent MAILHOL 2022-05-17 10:45 ` Marc Kleine-Budde 2022-05-17 11:51 ` Oliver Hartkopp 2022-05-17 12:14 ` Max Staudt 2022-05-17 12:21 ` Marc Kleine-Budde 2022-05-17 12:39 ` Max Staudt 2022-05-17 13:35 ` Oliver Hartkopp 2022-05-17 13:43 ` Max Staudt 2022-05-17 14:23 ` Marc Kleine-Budde 2022-05-17 14:35 ` Oliver Hartkopp 2022-05-17 15:38 ` Max Staudt 2022-05-17 15:50 ` Oliver Hartkopp 2022-05-17 17:52 ` Max Staudt 2022-05-18 12:03 ` Vincent MAILHOL 2022-05-18 12:12 ` Device Drivers: (was: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c) Marc Kleine-Budde 2022-05-18 12:45 ` Oliver Hartkopp 2022-05-18 13:10 ` [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Oliver Hartkopp 2022-05-18 13:28 ` Marc Kleine-Budde 2022-05-18 14:07 ` Vincent MAILHOL 2022-05-18 14:33 ` Oliver Hartkopp 2022-05-18 14:36 ` Marc Kleine-Budde 2022-05-18 14:38 ` Oliver Hartkopp 2022-05-18 14:55 ` Oliver Hartkopp 2022-05-18 15:38 ` Vincent MAILHOL 2022-05-18 15:48 ` Max Staudt 2022-05-18 16:01 ` Vincent MAILHOL 2022-05-14 14:16 ` [PATCH v3 4/4] can: dev: drop tx skb if in listen only mode Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol 2022-06-04 11:27 ` Marc Kleine-Budde 2022-06-04 12:30 ` Vincent MAILHOL 2022-06-04 12:43 ` Marc Kleine-Budde 2022-06-04 13:46 ` Marc Kleine-Budde 2022-06-03 10:28 ` [PATCH v4 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol 2022-06-04 11:25 ` Marc Kleine-Budde 2022-06-04 12:21 ` Vincent MAILHOL 2022-06-04 12:41 ` Marc Kleine-Budde 2022-06-04 12:56 ` Vincent MAILHOL 2022-06-04 13:51 ` Marc Kleine-Budde 2022-06-03 10:28 ` [PATCH v4 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol 2022-06-04 11:22 ` Marc Kleine-Budde 2022-06-04 12:14 ` Vincent MAILHOL 2022-06-03 10:28 ` [PATCH v4 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol 2022-06-03 10:28 ` [PATCH v4 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol 2022-06-04 11:46 ` [PATCH v4 0/7] can: refactoring of can-dev module and of Kbuild Marc Kleine-Budde 2022-06-04 13:05 ` Vincent MAILHOL 2022-06-04 13:55 ` Marc Kleine-Budde 2022-06-04 14:59 ` Vincent MAILHOL 2022-06-04 15:18 ` Marc Kleine-Budde 2022-06-04 16:32 ` Vincent MAILHOL 2022-06-05 10:39 ` Marc Kleine-Budde 2022-06-05 13:57 ` Vincent MAILHOL 2022-06-05 18:08 ` Marc Kleine-Budde 2022-06-04 16:29 ` [PATCH v5 " Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 1/7] can: Kbuild: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol 2022-06-07 8:43 ` Geert Uytterhoeven 2022-06-07 9:27 ` Vincent MAILHOL 2022-06-07 16:22 ` Max Staudt 2022-06-07 22:06 ` Jakub Kicinski 2022-06-07 23:40 ` Vincent MAILHOL 2022-06-08 0:07 ` Jakub Kicinski 2022-06-07 23:43 ` Max Staudt 2022-06-08 0:14 ` Jakub Kicinski 2022-06-08 0:22 ` Max Staudt 2022-06-08 1:38 ` Vincent MAILHOL 2022-06-04 16:29 ` [PATCH v5 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol 2022-06-04 16:29 ` [PATCH v5 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol 2022-06-04 16:30 ` [PATCH v5 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol 2022-06-05 17:23 ` [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild Max Staudt 2022-06-05 18:06 ` Marc Kleine-Budde 2022-06-05 20:46 ` Max Staudt 2022-06-06 0:24 ` Vincent MAILHOL 2022-06-06 19:24 ` Oliver Hartkopp 2022-06-07 2:49 ` Vincent MAILHOL 2022-06-07 7:13 ` Marc Kleine-Budde 2022-06-07 8:49 ` Vincent MAILHOL 2022-06-07 20:12 ` Oliver Hartkopp 2022-06-07 20:27 ` Marc Kleine-Budde 2022-06-07 20:51 ` Oliver Hartkopp 2022-06-07 23:59 ` Vincent MAILHOL 2022-06-08 20:10 ` Oliver Hartkopp 2022-06-10 14:30 ` [PATCH v6 " Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 1/7] can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 2/7] can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 4/7] can: Kconfig: add CONFIG_CAN_RX_OFFLOAD Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 5/7] net: Kconfig: move the CAN device menu to the "Device Drivers" section Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 6/7] can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.c Vincent Mailhol 2022-06-10 14:30 ` [PATCH v6 7/7] can: skb: drop tx skb if in listen only mode Vincent Mailhol 2022-06-10 21:38 ` [PATCH v6 0/7] can: refactoring of can-dev module and of Kbuild Oliver Hartkopp 2022-06-10 22:43 ` Max Staudt 2022-06-11 15:17 ` Marc Kleine-Budde
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).