[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4e329d97e0d42a494f1783b27adadb208594c7d3.camel@esd.eu>
Date: Wed, 17 Nov 2021 16:22:58 +0000
From: Stefan Mätje <Stefan.Maetje@....eu>
To: "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
"wg@...ndegger.com" <wg@...ndegger.com>,
"mkl@...gutronix.de" <mkl@...gutronix.de>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 0/2] can: esd: add support for esd GmbH PCIe/402 CAN
interface
Hello Marc,
there has been no feedback for the patch version v5 since a week. I had
the hope that the patch would be included in the upcoming 5.16 kernel.
The patch v5 is basically only a version v4 rebased to the linux-can-next
tree as of 2021-10-25.
The v4 version was published on the linux-can mailing list on 2021-09-16
about 8 weeks ago. Since then I had no feedback on both of these patches.
I'm not quite sure what I can do to make the inclusion process go forward.
Any information on how to proceed is appreciated.
Best regards,
Stefan Mätje
Am Dienstag, den 09.11.2021, 16:53 +0100 schrieb Stefan Mätje:
> The purpose of this patch is to introduce a new CAN driver to support
> the esd GmbH 402 family of CAN interface boards. The hardware design
> is based on a CAN controller implemented in a FPGA attached to a
> PCIe link.
>
> More information on these boards can be found following the links
> included in the commit message.
>
> This patch supports all boards but will operate the CAN-FD capable
> boards only in Classic-CAN mode. The CAN-FD support will be added
> when the initial patch has stabilized.
>
> The patch is based on the previous work of my former colleague:
> Link: https://lore.kernel.org/linux-can/1426592308-23817-1-git-send-email-thomas.koerper@esd.eu/
>
> *Note*: scripts/checkpatch.pl still emits the following warnings:
> - esd_402_pci-core.c:270: Possible unnecessary 'out of memory' message
> This error message is there to tell the user that the DMA allocation
> failed and not an allocation for normal kernel memory.
> - esdacc.h:255: The irq_cnt pointer is still declared volatile and
> this has a reason and is explained in detail in the header
> referencing the exception noted in volatile-considered-harmful.rst.
>
> @Marc: Since v4 I've had no feedback on this patch proposal. Does this mean
> that there are no objections left and the driver now is ready for inclusion
> in the 5.16 main line kernel?
>
> Changes in v5:
> - Added the initialization for netdev::dev_port as it is implemented
> for another CAN driver. See
> https://lore.kernel.org/linux-can/20211026180553.1953189-1-mailhol.vincent@wanadoo.fr/
>
> Changes in v4:
> - Fixed the build failure on ARCH=arm64 that was found by the Intel
> kernel test robot. See
> https://lore.kernel.org/linux-can/202109120608.7ZbQXkRh-lkp@intel.com/
>
> Removed error monitoring code that used GCC's built-in compiler
> functions for atomic access (__sync_* functions). GCC versions
> after 9 (tested with "gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04)")
> don't implement the intrinsic atomic as in-line code but call
> "__aarch64_ldadd4_acq_rel" on arm64. This GCC support function
> is not exported by the kernel and therefore the module build
> post-processing fails.
>
> Removed that code because the error monitoring never showed a
> problem during the development this year.
>
>
> Changes in v3:
> - Rework the bus-off restart logic in acc_set_mode() and
> handle_core_msg_errstatechange() to call netif_wake_queue() from the
> error active event.
> - Changed pci402_init_card() to allocate a variable sized array of
> struct acc_core using devm_kcalloc() instead of using a fixed size
> array in struct pci402_card.
> - Changed handle_core_msg_txabort() to release aborted TX frames in
> TX FIFO order.
> - Fixed the acc_close() function to abort all pending TX request in
> esdACC controller.
> - Fixed counting of transmit aborts in handle_core_msg_txabort().
> It is now done like in can_flush_echo_skb().
> - Fixed handle_core_msg_buserr() to create error frames including the
> CAN RX and TX error counters that were missing.
> - Fixed acc_set_bittiming() neither to touch LOM mode setting of
> esdACC controller nor to enter or leave RESET mode.
> The esdACC controller is going active on the CAN bus in acc_open()
> and is going inactive (RESET mode) again in acc_close().
> - Rely on the automatic release of memory fetched by devm_kzalloc().
> But still use devm_irq_free() explicitely to make sure that the
> interrupt handler is disconnected at that point.
> This avoids a possible crash in non-MSI mode due to the IRQ
> triggered by another device on the same PCI IRQ line.
> - Changed to use DMA map API instead of pci_*_consistent compatibility
> wrappers.
> - Fixed stale email references and updated copyright information.
> - Removed any traces of future CAN-FD support.
>
>
> Changes in v2:
> - Avoid warning triggered by -Wshift-count-overflow on architectures
> with 32-bit dma_addr_t.
> - Fixed Makefile not to build the kernel module always. Doing this
> renamed esd402_pci.c to esd_402_pci-core.c as recommended by Marc.
>
> Stefan Mätje (2):
> MAINTAINERS: add Stefan Mätje as maintainer for the esd electronics
> GmbH CAN drivers
> can: esd: add support for esd GmbH PCIe/402 CAN interface family
>
> MAINTAINERS | 8 +
> drivers/net/can/Kconfig | 1 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/esd/Kconfig | 12 +
> drivers/net/can/esd/Makefile | 7 +
> drivers/net/can/esd/esd_402_pci-core.c | 502 ++++++++++++++++
> drivers/net/can/esd/esdacc.c | 777 +++++++++++++++++++++++++
> drivers/net/can/esd/esdacc.h | 380 ++++++++++++
> 8 files changed, 1688 insertions(+)
> create mode 100644 drivers/net/can/esd/Kconfig
> create mode 100644 drivers/net/can/esd/Makefile
> create mode 100644 drivers/net/can/esd/esd_402_pci-core.c
> create mode 100644 drivers/net/can/esd/esdacc.c
> create mode 100644 drivers/net/can/esd/esdacc.h
>
>
> base-commit: f659c5c7de7982018bb961cf1f9960e60f526bdf
Powered by blists - more mailing lists