linux-kernel - [PATCH 2/2] arm64: dts: renesas: white-hawk: Add CAN-FD support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 23 Jan 2023 20:06:19 +0100
From:   Geert Uytterhoeven <geert+renesas@...der.be>
To:     Magnus Damm <magnus.damm@...il.com>
Cc:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Ulrich Hecht <uli+renesas@...nd.eu>,
        linux-renesas-soc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: [PATCH 2/2] arm64: dts: renesas: white-hawk: Add CAN-FD support

Enable confirmed-working CAN-FD channels 0 and 1 on the White-Hawk
development board:
  - Channel 0 uses an NXP TJR1443AT CAN transceiver, which is be enabled
    through a GPIO,
  - Channels 1-7 use Microchip MCP2558FD-H/SN CAN transceivers (not
    mounted for channels 4-7), which do not need explicit description,
    but channels 2-3 do not seem to work.

Inspired by a patch in the BSP by Kazuya Mizuguch.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
---
This depends on "[PATCH 2/2] phy: phy-can-transceiver: Add support for
NXP TJR1443"
https://lore.kernel.org/all/0bfa1e4c43632e49c9512b4e7daa970545545dcf.1674037830.git.geert+renesas@glider.be

Changed compared to the BSP:
  - Add can_clk,
  - Add missing can_transceiver0,
  - Disable channels 2-7.

Tested using cansend, candump, and canfdtest.

  - Channel 2 does not work: "bus-off" error message.

  - Channel 3 does not work:
      - Using cansend on another interface, and candump on can3 shows
	that nothing is received.
	However, my scope does see the data on the bus, and it is not
	sent repeatedly, hence it must have been acked by the receiver.

      - Using canfdtest on can3 gives:

          can3: Message ID mismatch!
            expected: 0078: [8] 01 02 03 04 05 06 07 08
            received: 0077: [8] 00 01 02 03 04 05 06 07

Note that describing a plain gpio-hog instead of can_transceiver0 is not
sufficient, as the enable signal must not be asserted before
initialization of the CAN-FD controller,
---
 .../boot/dts/renesas/r8a779g0-white-hawk.dts  | 44 +++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
index 04a2b6b83e743f32..eff1ef6e2cc83aba 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
@@ -13,6 +13,33 @@
 / {
 	model = "Renesas White Hawk CPU and Breakout boards based on r8a779g0";
 	compatible = "renesas,white-hawk-breakout", "renesas,white-hawk-cpu", "renesas,r8a779g0";
+
+	can_transceiver0: can-phy0 {
+		compatible = "nxp,tjr1443";
+		#phy-cells = <0>;
+		enable-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+		max-bitrate = <5000000>;
+	};
+};
+
+&can_clk {
+	clock-frequency = <40000000>;
+};
+
+&canfd {
+	pinctrl-0 = <&canfd0_pins>, <&canfd1_pins>, <&can_clk_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	channel0 {
+		status = "okay";
+		phys = <&can_transceiver0>;
+	};
+
+	channel1 {
+		status = "okay";
+	};
 };
 
 &i2c0 {
@@ -23,3 +50,20 @@ eeprom@51 {
 		pagesize = <8>;
 	};
 };
+
+&pfc {
+	can_clk_pins: can-clk {
+		groups = "can_clk";
+		function = "can_clk";
+	};
+
+	canfd0_pins: canfd0 {
+		groups = "canfd0_data";
+		function = "canfd0";
+	};
+
+	canfd1_pins: canfd1 {
+		groups = "canfd1_data";
+		function = "canfd1";
+	};
+};
-- 
2.34.1