commit ea6ff7792203ad6786bda75d1dabf33311c8bef4 upstream. RZ/G2L has separate IRQ lines for tx and error interrupt for each channel whereas R-Car has a combined IRQ line for all the channel specific t

commit a1dcfbdfd1d0f7843f381f7c58cc87a0f8c11f6c upstream. R-Car has a clock divider for CAN FD clock within the IP, whereas it is not available on RZ/G2L. Add postdiv variable to struct rcar_canfd_hw_

commit 841645cfc773cdd0a21c67357c53845f2e972f91 upstream. RZ/G2L has separate IRQ lines for receive FIFO and global error interrupt whereas R-Car has shared IRQ line. Add shared_global_irqs to struct

commit ce7c5382758b13dd4dfa2eb2f4989f9a27c58ffe upstream. The CAN FD IP found on RZ/G2L SoC has some HW features different to that of R-Car. For example, it has multiple resets and multiple IRQs for g

commit 68399ff574e4faf42b8d85da9339ca3ee2892cc7 upstream. Replace devm_reset_control_get_exclusive->devm_reset_control_ get_optional_exclusive so that we can avoid unnecessary SoC specific check in pr

From: Geert Uytterhoeven <geert+renesas@...> commit 8b043dfb3dc7c32f9c2c0c93e3c2de346ee5e358 upstream. When introducing support for R-Car V3U, which has 8 instead of 2 channels, the ECC error bi

commit 702de2c21eed04c67cefaaedc248ef16e5f6b293 upstream. We are seeing an IRQ storm on the global receive IRQ line under heavy CAN bus load conditions with both CAN channels enabled. Conditions: The

This patch series aims to fix IRQ storm issue as well as some enhancements to Renesas CANFD driver. Biju Das (6): can: rcar_canfd: rcar_canfd_handle_global_receive(): fix IRQ storm on global FIFO rece

Hi Pavel, No worries, I am doing some testing with couple of CAN patches along with IRQ storm patch. I will post soon. Cheers, Biju

Anyway, I will post this patch to CIP ML today.

Hi Pavel and Nobuhiro-San, We are missing this patch from 5.10 stable[1] in 5.10.y-cip[2]. Can you please add it? [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.1

commit 1625fbc1f73f1fa8f77c38ea554cc0b2327b156b upstream. Currently, determine_rate() is not doing any round operation and due to this it always selects a lower clock source compared to the closest hi

commit f0c00454bf78975925eccc9737faaa4d4951edbf upstream. Due to clk rounding errors on RZ/G2L platforms, it selects a clock source with a lower clock rate compared to a higher one. For eg: The roundi

From: Wolfram Sang <wsa+renesas@...> commit 2e586f8a5b0ed4a525014a692923ac96f6647816 upstream. If we reset because of an error, we need to preserve values for the clock frequency. Oth

This patch series aims to add rounding error fixes for selecting 533MHz SDHI source clk and avoid glitches when resetting. Biju Das (2): mmc: renesas_sdhi: Fix rounding errors clk: renesas: rzg2l: Sup

Yes, performance is one thing, also it will avoid unnecessary races when you start handling IRQ's in both the cores. Eg:- ch0 IRQ handler executed on core0 and ch1 IRQ handler on core 1, which unneces

IRQ processing should be fast as possible. You are improving latency of the system by avoiding unnecessary checks and by calling an unwanted function call. If it is shared IRQ, then it make sense you

Basically, tx IRQs are channel specific. Previously if any txIRQ is triggered, you are unnecessarily Checking IRQ status of the txIRQ which is not triggered. For eg: if ch0 IRQ is triggered you are ch

commit d887087c896881715c1a82f1d4f71fbfe5344ffd upstream. RZ/G2L has separate channel specific IRQs for transmit and error interrupts. But the IRQ handler processes both channels, even if there no int

Hi Nobuhiro-San, Thanks for the feedback. Renesas RAVB reviewer doesn't like macro, he wants plain number here. See [1] [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220914064730.