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:   Wed, 30 May 2018 08:07:57 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Faiz Abbas <faiz_abbas@...com>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-clk@...r.kernel.org, robh+dt@...nel.org,
        bcousson@...libre.com, paul@...an.com, t-kristo@...com
Subject: Re: [PATCH v2 6/6] ARM: dts: dra76x: Add MCAN node

* Faiz Abbas <faiz_abbas@...com> [180530 14:12]:
> From: Franklin S Cooper Jr <fcooper@...com>
> 
> Add support for the MCAN peripheral which supports both classic
> CAN messages along with the new CAN-FD message.
...
> --- a/arch/arm/boot/dts/dra76x.dtsi
> +++ b/arch/arm/boot/dts/dra76x.dtsi
> @@ -27,6 +27,21 @@
>  			ti,syss-mask = <1>;
>  			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
>  			clock-names = "fck";
> +
> +			m_can0: mcan@...01a00 {
> +				compatible = "bosch,m_can";
> +				reg = <0x1a00 0x4000>, <0x0 0x18FC>;
> +				reg-names = "m_can", "message_ram";
> +				interrupt-parent = <&gic>;
> +				interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> +					     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
> +				interrupt-names = "int0", "int1";
> +				ti,hwmods = "mcan";

The "ti,hwmods" should be in the parent node now. But you may not even need
it, see the reset comment I made for the parent node patch.

> +				clocks = <&mcan_clk>, <&l3_iclk_div>;
> +				clock-names = "cclk", "hclk";
> +				bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
> +				status = "disabled";

And then you should be able to also leave out status = "disabled" as the
hardware is there for sure and we can idle it. Then a board specific
dts file can set it to "disabled" if reallly needed. Setting everything
manually to "disabled" and then again to "enabled" is the wrong way
around, the default is "enabled".

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ