Message ID | 20230328073328.3949796-1-dario.binacchi@amarulasolutions.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2039260vqo; Tue, 28 Mar 2023 00:51:02 -0700 (PDT) X-Google-Smtp-Source: AKy350Yh01ZXd66qJnbDw4K7DHF6YQAZoIokhlvCPX1Mveit1KLK8fOUVyed01+U8b61+HCpaJl7 X-Received: by 2002:aa7:9709:0:b0:62b:47fc:a968 with SMTP id a9-20020aa79709000000b0062b47fca968mr12290290pfg.8.1679989862403; Tue, 28 Mar 2023 00:51:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679989862; cv=none; d=google.com; s=arc-20160816; b=NM/lsUP5hCkjXQJTKFNZX4jysrH0fLefJbgClqb7bAG2EtbmdvOeBm+bxWu78RK05b lfHPpIJat8z0MWFmrLBcFg15sA/s9JKliU9DVGMeiA0LbKaEn6nkofgPWCMdh2UoKJM+ 4+n/iS7WQ5SRQ0MdcLPej4KrhN7jMVXwth4LhHq6w/IbUGLQeY3YvQhnEjdv/hoMIc1V Rtbat/A5aA7lit9BAvFz8YR0KlEjqixi1VF8kNMzlHsf7ostwDyQ5/derNoN6bAcFpzH mBurjjpljStFTjn4m962H5WS8PmpIbS3sR5SJkB6lhBOk2Gqy8uDgDEHyfl+osHpuu3I KRJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=IQemtvhch+zpychTw2wPnm8AfYz48LBPAqThlF3dIgU=; b=aBt8JIYZN7PBgjlduLcAEKByd18amq3TXJCRLxEoUHkkiSVvHQV1583BjDChHl3GHp lwWBimKvGDcVLTsesYYxO6fgf7iR79OgA7USLB6eupL/deWF5Ybs0r/9FikoWPaPcKZz elHmApsGLBM6vqerszJsreS9+MNzfINVUaT1NSGh86xk93frssXASbc7Mko9jIwzBUbc bKHdyyKt+BF6n77mF6+nRdYh79AI3qAgRRe2PEk/Bxgvt4Ef/ctAPL0tSYfNdBLYU3M8 PsNVKQB9ZRE9mOIPK5+U8is4gHNceGWkqcUdRmQ0dhLnUZy/qNtrAfya7pHr/3qKPS4+ KCkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=DDUJo2LU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u3-20020a056a00098300b00627ec453561si24912613pfg.99.2023.03.28.00.50.48; Tue, 28 Mar 2023 00:51:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=DDUJo2LU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231174AbjC1Hdu (ORCPT <rfc822;kartikey406@gmail.com> + 99 others); Tue, 28 Mar 2023 03:33:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231124AbjC1Hds (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 28 Mar 2023 03:33:48 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDD1240E4 for <linux-kernel@vger.kernel.org>; Tue, 28 Mar 2023 00:33:44 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id x3so45699841edb.10 for <linux-kernel@vger.kernel.org>; Tue, 28 Mar 2023 00:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; t=1679988823; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=IQemtvhch+zpychTw2wPnm8AfYz48LBPAqThlF3dIgU=; b=DDUJo2LUdaN/EQ7qfHi1KDLV00MZH5/PH2X5hnuvjtJigIGuxkr6lgHi454/0Ic6dV wZuw1pNJuhb0fuh8Fo1T+E25Y1FXav1kSDre2Veb0Dytbkh0LzQD0fIVtPtbJ7lX/45V l171wS7bvsLBAL2BZf2Ps9xCSKcQ1PnFqY8ho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679988823; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IQemtvhch+zpychTw2wPnm8AfYz48LBPAqThlF3dIgU=; b=gQ6urSVyTtCmmIS6+OS5LrNiSNCZN89F/WfaEgDL0+fMSW0ZS6vMUoLmYdhP8sOVks QlrXQhDJN9yBe9lzJPNxTVa0wo0YuG4kVaVqHa/d1InepGpLfBxO89u7uWwAgNPH0FiF DgILYr2TK1ExybroIbVDL/AmsQKHY6Mo7PZgIrW/egL9WD0dlKJLkAN4+/R6F6nVmoz3 3XZzwEOH89Hdpriu3+dmmkRqKBtm6XW14vgEUTx4vFFe081xgcedUWmJP0JO1xX96ZKS QIeY3NLq2kWgIIRMlz8vJhiF/9LwnNa2HM/FACGoTtuU+dKk9hjjgMWZGJnVnrleCf1D ne/w== X-Gm-Message-State: AAQBX9cSAcJ+tk7rlaZSSxWUrJUVm8keixB8CbchVM2qMu7jzcNgRed8 r3LPcZ0A0es0NnTKHJjLGbnuGXIX46PAh+TqYcBgag== X-Received: by 2002:a17:906:c453:b0:90b:53f6:fd8a with SMTP id ck19-20020a170906c45300b0090b53f6fd8amr16162637ejb.10.1679988822894; Tue, 28 Mar 2023 00:33:42 -0700 (PDT) Received: from dario-ThinkPad-T14s-Gen-2i.homenet.telecomitalia.it (host-87-0-102-254.retail.telecomitalia.it. [87.0.102.254]) by smtp.gmail.com with ESMTPSA id 15-20020a508e4f000000b004fa99a22c3bsm15478850edx.61.2023.03.28.00.33.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Mar 2023 00:33:42 -0700 (PDT) From: Dario Binacchi <dario.binacchi@amarulasolutions.com> To: linux-kernel@vger.kernel.org Cc: Vincent Mailhol <mailhol.vincent@wanadoo.fr>, Rob Herring <robh@kernel.org>, Amarula patchwork <linux-amarula@amarulasolutions.com>, michael@amarulasolutions.com, Marc Kleine-Budde <mkl@pengutronix.de>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Dario Binacchi <dario.binacchi@amarulasolutions.com>, Christophe Roullier <christophe.roullier@foss.st.com>, "David S. Miller" <davem@davemloft.net>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Mark Brown <broonie@kernel.org>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>, Wolfgang Grandegger <wg@grandegger.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-can@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org Subject: [PATCH v10 0/5] can: bxcan: add support for ST bxCAN controller Date: Tue, 28 Mar 2023 09:33:23 +0200 Message-Id: <20230328073328.3949796-1-dario.binacchi@amarulasolutions.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761553813192913949?= X-GMAIL-MSGID: =?utf-8?q?1761597049481680321?= |
Series |
can: bxcan: add support for ST bxCAN controller
|
|
Message
Dario Binacchi
March 28, 2023, 7:33 a.m. UTC
The series adds support for the basic extended CAN controller (bxCAN) found in many low- to middle-end STM32 SoCs. The driver has been tested on the stm32f469i-discovery board with a kernel version 5.19.0-rc2 in loopback + silent mode: ip link set can0 type can bitrate 125000 loopback on listen-only on ip link set up can0 candump can0 -L & cansend can0 300#AC.AB.AD.AE.75.49.AD.D1 For uboot and kernel compilation, as well as for rootfs creation I used buildroot: make stm32f469_disco_sd_defconfig make but I had to patch can-utils and busybox as can-utils and iproute are not compiled for MMU-less microcotrollers. In the case of can-utils, replacing the calls to fork() with vfork(), I was able to compile the package with working candump and cansend applications, while in the case of iproute, I ran into more than one problem and finally I decided to extend busybox's ip link command for CAN-type devices. I'm still wondering if it was really necessary, but this way I was able to test the driver. Changes in v10: - Fix errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'. Fix the "st,can-primary" description removing the "Note:" word that caused the failure. - Slightly change the note text at the top of the driver module. No functional changes. Changes in v9: - Fix commit description formatting. No semantic changes have been made. - Replace master/slave terms with primary/secondary. - Replace master/slave terms with primary/secondary. - Replace master/slave terms with primary/secondary. Changes in v8: - Do not enable the clock in probe and enable/disable it in open/close. - Return IRQ_NONE if no IRQ is active. Changes in v7: - Add Vincent Mailhol's Reviewed-by tag. - Remove all unused macros for reading/writing the controller registers. - Add CAN_ERR_CNT flag to notify availability of error counter. - Move the "break" before the newline in the switch/case statements. - Print the mnemotechnic instead of the error value in each netdev_err(). - Remove the debug print for timings parameter. - Do not copy the data if CAN_RTR_FLAG is set in bxcan_start_xmit(). - Populate ndev->ethtool_ops with the default timestamp info. Changes in v6: - move can1 node before gcan to keep ordering by address. Changes in v5: - Add Rob Herring's Acked-by tag. - Add Rob Herring's Reviewed-by tag. - Put static in front of bxcan_enable_filters() definition. Changes in v4: - Remove "st,stm32f4-bxcan-core" compatible. In this way the can nodes (compatible "st,stm32f4-bxcan") are no longer children of a parent node with compatible "st,stm32f4-bxcan-core". - Add the "st,gcan" property (global can memory) to can nodes which references a "syscon" node containing the shared clock and memory addresses. - Replace the node can@40006400 (compatible "st,stm32f4-bxcan-core") with the gcan@40006600 node ("sysnode" compatible). The gcan node contains clocks and memory addresses shared by the two can nodes of which it's no longer the parent. - Add to can nodes the "st,gcan" property (global can memory) which references the gcan@40006600 node ("sysnode compatibble). - Add "dt-bindings: arm: stm32: add compatible for syscon gcan node" patch. - Drop the core driver. Thus bxcan-drv.c has been renamed to bxcan.c and moved to the drivers/net/can folder. The drivers/net/can/bxcan directory has therefore been removed. - Use the regmap_*() functions to access the shared memory registers. - Use spinlock to protect bxcan_rmw(). - Use 1 space, instead of tabs, in the macros definition. - Drop clock ref-counting. - Drop unused code. - Drop the _SHIFT macros and use FIELD_GET()/FIELD_PREP() directly. - Add BXCAN_ prefix to lec error codes. - Add the macro BXCAN_RX_MB_NUM. - Enable time triggered mode and use can_rx_offload(). - Use readx_poll_timeout() in function with timeouts. - Loop from tail to head in bxcan_tx_isr(). - Check bits of tsr register instead of pkts variable in bxcan_tx_isr(). - Don't return from bxcan_handle_state_change() if skb/cf are NULL. - Enable/disable the generation of the bus error interrupt depending on can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING. - Don't return from bxcan_handle_bus_err() if skb is NULL. - Drop statistics updating from bxcan_handle_bus_err(). - Add an empty line in front of 'return IRQ_HANDLED;' - Rename bxcan_start() to bxcan_chip_start(). - Rename bxcan_stop() to bxcan_chip_stop(). - Disable all IRQs in bxcan_chip_stop(). - Rename bxcan_close() to bxcan_ndo_stop(). - Use writel instead of bxcan_rmw() to update the dlc register. Changes in v3: - Remove 'Dario Binacchi <dariobin@libero.it>' SOB. - Add description to the parent of the two child nodes. - Move "patterProperties:" after "properties: in top level before "required". - Add "clocks" to the "required:" list of the child nodes. - Remove 'Dario Binacchi <dariobin@libero.it>' SOB. - Add "clocks" to can@0 node. - Remove 'Dario Binacchi <dariobin@libero.it>' SOB. - Remove a blank line. - Remove 'Dario Binacchi <dariobin@libero.it>' SOB. - Fix the documentation file path in the MAINTAINERS entry. - Do not increment the "stats->rx_bytes" if the frame is remote. - Remove pr_debug() call from bxcan_rmw(). Changes in v2: - Change the file name into 'st,stm32-bxcan-core.yaml'. - Rename compatibles: - st,stm32-bxcan-core -> st,stm32f4-bxcan-core - st,stm32-bxcan -> st,stm32f4-bxcan - Rename master property to st,can-master. - Remove the status property from the example. - Put the node child properties as required. - Remove a blank line. - Fix sparse errors. - Create a MAINTAINERS entry. - Remove the print of the registers address. - Remove the volatile keyword from bxcan_rmw(). - Use tx ring algorithm to manage tx mailboxes. - Use can_{get|put}_echo_skb(). - Update DT properties. Dario Binacchi (5): dt-bindings: arm: stm32: add compatible for syscon gcan node dt-bindings: net: can: add STM32 bxcan DT bindings ARM: dts: stm32: add CAN support on stm32f429 ARM: dts: stm32: add pin map for CAN controller on stm32f4 can: bxcan: add support for ST bxCAN controller .../bindings/arm/stm32/st,stm32-syscon.yaml | 2 + .../bindings/net/can/st,stm32-bxcan.yaml | 85 ++ MAINTAINERS | 7 + arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 30 + arch/arm/boot/dts/stm32f429.dtsi | 29 + drivers/net/can/Kconfig | 12 + drivers/net/can/Makefile | 1 + drivers/net/can/bxcan.c | 1098 +++++++++++++++++ 8 files changed, 1264 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml create mode 100644 drivers/net/can/bxcan.c
Comments
On 28.03.2023 09:33:23, Dario Binacchi wrote: > The series adds support for the basic extended CAN controller (bxCAN) > found in many low- to middle-end STM32 SoCs. > > The driver has been tested on the stm32f469i-discovery board with a > kernel version 5.19.0-rc2 in loopback + silent mode: > > ip link set can0 type can bitrate 125000 loopback on listen-only on > ip link set up can0 > candump can0 -L & > cansend can0 300#AC.AB.AD.AE.75.49.AD.D1 > > For uboot and kernel compilation, as well as for rootfs creation I used > buildroot: > > make stm32f469_disco_sd_defconfig > make > > but I had to patch can-utils and busybox as can-utils and iproute are > not compiled for MMU-less microcotrollers. In the case of can-utils, > replacing the calls to fork() with vfork(), I was able to compile the > package with working candump and cansend applications, while in the > case of iproute, I ran into more than one problem and finally I decided > to extend busybox's ip link command for CAN-type devices. I'm still > wondering if it was really necessary, but this way I was able to test > the driver. Applied to linux-can-next. Thanks, Marc
Hi Marc, On Tue, Mar 28, 2023 at 10:47 AM Marc Kleine-Budde <mkl@pengutronix.de> wrote: > > On 28.03.2023 09:33:23, Dario Binacchi wrote: > > The series adds support for the basic extended CAN controller (bxCAN) > > found in many low- to middle-end STM32 SoCs. > > > > The driver has been tested on the stm32f469i-discovery board with a > > kernel version 5.19.0-rc2 in loopback + silent mode: > > > > ip link set can0 type can bitrate 125000 loopback on listen-only on > > ip link set up can0 > > candump can0 -L & > > cansend can0 300#AC.AB.AD.AE.75.49.AD.D1 > > > > For uboot and kernel compilation, as well as for rootfs creation I used > > buildroot: > > > > make stm32f469_disco_sd_defconfig > > make > > > > but I had to patch can-utils and busybox as can-utils and iproute are > > not compiled for MMU-less microcotrollers. In the case of can-utils, > > replacing the calls to fork() with vfork(), I was able to compile the > > package with working candump and cansend applications, while in the > > case of iproute, I ran into more than one problem and finally I decided > > to extend busybox's ip link command for CAN-type devices. I'm still > > wondering if it was really necessary, but this way I was able to test > > the driver. > > Applied to linux-can-next. Just one last question: To test this series, as described in the cover letter, I could not use the iproute2 package since the microcontroller is without MMU. I then extended busybox for the ip link command. I actually also added the rtnl-link-can.c application to the libmnl library. So now I find myself with two applications that have been useful to me for this type of use case. Did I do useless work because I could use other tools? If instead the tools for this use case are missing, what do you think is better to do? Submit to their respective repos or add this functionality to another project that I haven't considered ? Thanks and regards, Dario > > Thanks, > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung Nürnberg | Phone: +49-5121-206917-129 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 28.03.2023 11:28:59, Dario Binacchi wrote: > > Applied to linux-can-next. > > Just one last question: To test this series, as described in the cover > letter, I could not use the iproute2 package since the microcontroller > is without MMU. I then extended busybox for the ip link command. I > actually also added the rtnl-link-can.c application to the libmnl > library. So now I find myself with two applications that have been > useful to me for this type of use case. > > Did I do useless work because I could use other tools? systemd-networkd also supports CAN configuration, but I this will probably not work on no-MMU systemd, too. Then there is: | https://git.pengutronix.de/cgit/tools/canutils | https://git.pengutronix.de/cgit/tools/libsocketcan that contains canconfig, but it lacks CAN-FD support. > If instead the tools for this use case are missing, what do you think > is better to do? Submit to their respective repos or add this > functionality to another project that I haven't considered ? Yes, go ahead and upstream your changes! Marc