* [net 1/6] can: m_can: m_can_class_unregister(): remove erroneous m_can_clk_stop()
2021-01-07 10:34 pull-request: can 2021-01-07 Marc Kleine-Budde
@ 2021-01-07 10:34 ` Marc Kleine-Budde
2021-01-07 10:34 ` [net 2/6] can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver Marc Kleine-Budde
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Marc Kleine-Budde @ 2021-01-07 10:34 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, linux-can, kernel, Marc Kleine-Budde, Dan Murphy,
Sriram Dash, Sean Nyekjaer
In m_can_class_register() the clock is started, but stopped on exit. When
calling m_can_class_unregister(), the clock is stopped a second time.
This patch removes the erroneous m_can_clk_stop() in m_can_class_unregister().
Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework")
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Sriram Dash <sriram.dash@samsung.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20201215103238.524029-2-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 2c9f12401276..da551fd0f502 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1852,8 +1852,6 @@ EXPORT_SYMBOL_GPL(m_can_class_register);
void m_can_class_unregister(struct m_can_classdev *cdev)
{
unregister_candev(cdev->net);
-
- m_can_clk_stop(cdev);
}
EXPORT_SYMBOL_GPL(m_can_class_unregister);
base-commit: 1f685e6adbbe3c7b1bd9053be771b898d9efa655
--
2.29.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [net 2/6] can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver
2021-01-07 10:34 pull-request: can 2021-01-07 Marc Kleine-Budde
2021-01-07 10:34 ` [net 1/6] can: m_can: m_can_class_unregister(): remove erroneous m_can_clk_stop() Marc Kleine-Budde
@ 2021-01-07 10:34 ` Marc Kleine-Budde
2021-01-07 10:34 ` [net 3/6] can: mcp251xfd: mcp251xfd_handle_tefif(): fix TEF vs. TX race condition Marc Kleine-Budde
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Marc Kleine-Budde @ 2021-01-07 10:34 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, linux-can, kernel, Marc Kleine-Budde, Dan Murphy,
Sean Nyekjaer
According to the TCAN4550 datasheet "SLLSF91 - DECEMBER 2018" the tcan4x5x has
the same bittiming constants as a m_can revision 3.2.x/3.3.0.
The tcan4x5x chip I'm using identifies itself as m_can revision 3.2.1, so
remove the tcan4x5x specific bittiming values and rely on the values in the
m_can driver, which are selected according to core revision.
Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Cc: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20201215103238.524029-3-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/tcan4x5x.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/net/can/m_can/tcan4x5x.c b/drivers/net/can/m_can/tcan4x5x.c
index 24c737c4fc44..970f0e9d19bf 100644
--- a/drivers/net/can/m_can/tcan4x5x.c
+++ b/drivers/net/can/m_can/tcan4x5x.c
@@ -131,30 +131,6 @@ static inline struct tcan4x5x_priv *cdev_to_priv(struct m_can_classdev *cdev)
}
-static struct can_bittiming_const tcan4x5x_bittiming_const = {
- .name = DEVICE_NAME,
- .tseg1_min = 2,
- .tseg1_max = 31,
- .tseg2_min = 2,
- .tseg2_max = 16,
- .sjw_max = 16,
- .brp_min = 1,
- .brp_max = 32,
- .brp_inc = 1,
-};
-
-static struct can_bittiming_const tcan4x5x_data_bittiming_const = {
- .name = DEVICE_NAME,
- .tseg1_min = 1,
- .tseg1_max = 32,
- .tseg2_min = 1,
- .tseg2_max = 16,
- .sjw_max = 16,
- .brp_min = 1,
- .brp_max = 32,
- .brp_inc = 1,
-};
-
static void tcan4x5x_check_wake(struct tcan4x5x_priv *priv)
{
int wake_state = 0;
@@ -469,8 +445,6 @@ static int tcan4x5x_can_probe(struct spi_device *spi)
mcan_class->dev = &spi->dev;
mcan_class->ops = &tcan4x5x_ops;
mcan_class->is_peripheral = true;
- mcan_class->bit_timing = &tcan4x5x_bittiming_const;
- mcan_class->data_timing = &tcan4x5x_data_bittiming_const;
mcan_class->net->irq = spi->irq;
spi_set_drvdata(spi, priv);
--
2.29.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [net 3/6] can: mcp251xfd: mcp251xfd_handle_tefif(): fix TEF vs. TX race condition
2021-01-07 10:34 pull-request: can 2021-01-07 Marc Kleine-Budde
2021-01-07 10:34 ` [net 1/6] can: m_can: m_can_class_unregister(): remove erroneous m_can_clk_stop() Marc Kleine-Budde
2021-01-07 10:34 ` [net 2/6] can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver Marc Kleine-Budde
@ 2021-01-07 10:34 ` Marc Kleine-Budde
2021-01-07 10:34 ` [net 4/6] can: mcp251xfd: mcp251xfd_handle_rxif_ring(): first increment RX tail pointer in HW, then in driver Marc Kleine-Budde
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Marc Kleine-Budde @ 2021-01-07 10:34 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, linux-can, kernel, Marc Kleine-Budde
The mcp251xfd driver uses a TX FIFO for sending CAN frames and a TX Event FIFO
(TEF) for completed TX-requests.
The TEF event handling in the mcp251xfd_handle_tefif() function has a race
condition. It first increments the tx-ring's tail counter to signal that
there's room in the TX and TEF FIFO, then it increments the TEF FIFO in
hardware.
A running mcp251xfd_start_xmit() on a different CPU might not stop the txqueue
(as the tx-ring still shows free space). The next mcp251xfd_start_xmit() will
push a message into the chip and the TX complete event might overflow the TEF
FIFO.
This patch changes the order to fix the problem.
Fixes: 68c0c1c7f966 ("can: mcp251xfd: tef-path: reduce number of SPI core requests to set UINC bit")
Link: https://lore.kernel.org/r/20210105214138.3150886-2-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
index 77129d5f410b..85a1a8b7c0e7 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
@@ -1368,13 +1368,10 @@ static int mcp251xfd_handle_tefif(struct mcp251xfd_priv *priv)
struct mcp251xfd_tx_ring *tx_ring = priv->tx;
struct spi_transfer *last_xfer;
- tx_ring->tail += len;
-
/* Increment the TEF FIFO tail pointer 'len' times in
* a single SPI message.
- */
-
- /* Note:
+ *
+ * Note:
*
* "cs_change == 1" on the last transfer results in an
* active chip select after the complete SPI
@@ -1391,6 +1388,8 @@ static int mcp251xfd_handle_tefif(struct mcp251xfd_priv *priv)
if (err)
return err;
+ tx_ring->tail += len;
+
err = mcp251xfd_check_tef_tail(priv);
if (err)
return err;
--
2.29.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [net 4/6] can: mcp251xfd: mcp251xfd_handle_rxif_ring(): first increment RX tail pointer in HW, then in driver
2021-01-07 10:34 pull-request: can 2021-01-07 Marc Kleine-Budde
` (2 preceding siblings ...)
2021-01-07 10:34 ` [net 3/6] can: mcp251xfd: mcp251xfd_handle_tefif(): fix TEF vs. TX race condition Marc Kleine-Budde
@ 2021-01-07 10:34 ` Marc Kleine-Budde
2021-01-07 10:34 ` [net 5/6] can: rcar: Kconfig: update help description for CAN_RCAR config Marc Kleine-Budde
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Marc Kleine-Budde @ 2021-01-07 10:34 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, linux-can, kernel, Marc Kleine-Budde
The previous patch fixes a TEF vs. TX race condition, by first updating the TEF
tail pointer in hardware, and then updating the driver internal pointer.
The same pattern exists in the RX-path, too. This should be no problem, as the
driver accesses the RX-FIFO from the interrupt handler only, thus the access is
properly serialized. Fix the order here, too, so that the TEF- and RX-path look
similar.
Fixes: 1f652bb6bae7 ("can: mcp25xxfd: rx-path: reduce number of SPI core requests to set UINC bit")
Link: https://lore.kernel.org/r/20210105214138.3150886-3-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
index 85a1a8b7c0e7..36235afb0bc6 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
@@ -1552,10 +1552,8 @@ mcp251xfd_handle_rxif_ring(struct mcp251xfd_priv *priv,
/* Increment the RX FIFO tail pointer 'len' times in a
* single SPI message.
- */
- ring->tail += len;
-
- /* Note:
+ *
+ * Note:
*
* "cs_change == 1" on the last transfer results in an
* active chip select after the complete SPI
@@ -1571,6 +1569,8 @@ mcp251xfd_handle_rxif_ring(struct mcp251xfd_priv *priv,
last_xfer->cs_change = 1;
if (err)
return err;
+
+ ring->tail += len;
}
return 0;
--
2.29.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [net 5/6] can: rcar: Kconfig: update help description for CAN_RCAR config
2021-01-07 10:34 pull-request: can 2021-01-07 Marc Kleine-Budde
` (3 preceding siblings ...)
2021-01-07 10:34 ` [net 4/6] can: mcp251xfd: mcp251xfd_handle_rxif_ring(): first increment RX tail pointer in HW, then in driver Marc Kleine-Budde
@ 2021-01-07 10:34 ` Marc Kleine-Budde
2021-01-07 10:34 ` [net 6/6] MAINTAINERS: Update MCAN MMIO device driver maintainer Marc Kleine-Budde
2021-01-07 19:11 ` pull-request: can 2021-01-07 Jakub Kicinski
6 siblings, 0 replies; 8+ messages in thread
From: Marc Kleine-Budde @ 2021-01-07 10:34 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, linux-can, kernel, Lad Prabhakar,
Geert Uytterhoeven, Marc Kleine-Budde
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
The rcar_can driver also supports RZ/G SoC's, update the description to reflect
this.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210104090327.6547-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/rcar/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 8d36101b78e3..29cabc20109e 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
config CAN_RCAR
- tristate "Renesas R-Car CAN controller"
+ tristate "Renesas R-Car and RZ/G CAN controller"
depends on ARCH_RENESAS || ARM
help
Say Y here if you want to use CAN controller found on Renesas R-Car
- SoCs.
+ or RZ/G SoCs.
To compile this driver as a module, choose M here: the module will
be called rcar_can.
--
2.29.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [net 6/6] MAINTAINERS: Update MCAN MMIO device driver maintainer
2021-01-07 10:34 pull-request: can 2021-01-07 Marc Kleine-Budde
` (4 preceding siblings ...)
2021-01-07 10:34 ` [net 5/6] can: rcar: Kconfig: update help description for CAN_RCAR config Marc Kleine-Budde
@ 2021-01-07 10:34 ` Marc Kleine-Budde
2021-01-07 19:11 ` pull-request: can 2021-01-07 Jakub Kicinski
6 siblings, 0 replies; 8+ messages in thread
From: Marc Kleine-Budde @ 2021-01-07 10:34 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, linux-can, kernel, Sriram Dash, Pankaj Sharma,
Marc Kleine-Budde
From: Sriram Dash <sriram.dash@samsung.com>
Update Pankaj Sharma as maintainer for mcan mmio device driver as I
will be moving to a different role.
Signed-off-by: Sriram Dash <sriram.dash@samsung.com>
Acked-by: Pankaj Sharma <pankj.sharma@samsung.com>
Link: https://lore.kernel.org/r/20210104123134.16930-1-sriram.dash@samsung.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c1e45c416b1..b15514a770e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10847,7 +10847,7 @@ F: drivers/media/radio/radio-maxiradio*
MCAN MMIO DEVICE DRIVER
M: Dan Murphy <dmurphy@ti.com>
-M: Sriram Dash <sriram.dash@samsung.com>
+M: Pankaj Sharma <pankj.sharma@samsung.com>
L: linux-can@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
--
2.29.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: pull-request: can 2021-01-07
2021-01-07 10:34 pull-request: can 2021-01-07 Marc Kleine-Budde
` (5 preceding siblings ...)
2021-01-07 10:34 ` [net 6/6] MAINTAINERS: Update MCAN MMIO device driver maintainer Marc Kleine-Budde
@ 2021-01-07 19:11 ` Jakub Kicinski
6 siblings, 0 replies; 8+ messages in thread
From: Jakub Kicinski @ 2021-01-07 19:11 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, davem, linux-can, kernel
On Thu, 7 Jan 2021 11:34:45 +0100 Marc Kleine-Budde wrote:
> Hello Jakub, hello David,
>
> this is a pull request of 6 patches for net/master.
>
> The first patch is by me for the m_can driver and removes an erroneous
> m_can_clk_stop() from the driver's unregister function.
>
> The second patch targets the tcan4x5x driver, is by me, and fixes the bit
> timing constant parameters.
>
> The next two patches are by me, target the mcp251xfd driver, and fix a race
> condition in the optimized TEF path (which was added in net-next for v5.11).
> The similar code in the RX path is changed to look the same, although it
> doesn't suffer from the race condition.
>
> A patch by Lad Prabhakar updates the description and help text for the rcar CAN
> driver to reflect all supported SoCs.
>
> In the last patch Sriram Dash transfers the maintainership of the m_can driver
> to Pankaj Sharma.
Pulled, thanks!
^ permalink raw reply [flat|nested] 8+ messages in thread