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]
Message-Id: <a19d0a70aacaf4c3517a226bf32ea49db3542da4.1674500205.git.geert+renesas@glider.be>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ