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] [day] [month] [year] [list]
Message-ID: <65368cf6-afad-cb08-1b27-883e8e7eafef@ti.com>
Date:   Mon, 26 Jul 2021 13:13:08 +0530
From:   Aswath Govindraju <a-govindraju@...com>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
CC:     <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Lokesh Vutla <lokeshvutla@...com>
Subject: Re: [PATCH 3/6] arm64: dts: ti: k3-j721e: Add support for MCAN nodes

Hi Marc,

On 21/07/21 1:18 pm, Aswath Govindraju wrote:
> Hi Marc,
> 
> On 20/07/21 8:24 pm, Marc Kleine-Budde wrote:
>> On 20.07.2021 19:46:39, Aswath Govindraju wrote:
>>> From: Faiz Abbas <faiz_abbas@...com>
>>>
>>> Add support for 14 MCAN controllers in main domain and 2 MCAN controllers
>>> present in mcu domain. All the MCAN controllers support classic CAN
>>> messages as well as CAN_FD messages.
>>>
>>> Signed-off-by: Faiz Abbas <faiz_abbas@...com>
>>> Signed-off-by: Aswath Govindraju <a-govindraju@...com>
>>> ---
>>>  arch/arm64/boot/dts/ti/k3-j721e-main.dtsi     | 196 ++++++++++++++++++
>>>  .../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi      |  28 +++
>>>  2 files changed, 224 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>>> index cf3482376c1e..4215b8e6785a 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>>> @@ -1940,4 +1940,200 @@
>>>  			bus_freq = <1000000>;
>>>  		};
>>>  	};
>>> +
>>> +	main_mcan0: can@...1000 {
>>> +		compatible = "bosch,m_can";
>>> +		reg = <0x00 0x02701000 0x00 0x200>,
>>> +		      <0x00 0x02708000 0x00 0x8000>;
>>> +		reg-names = "m_can", "message_ram";
>>> +		power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
>>> +		clocks = <&k3_clks 156 1>, <&k3_clks 156 0>;
>>> +		clock-names = "cclk", "hclk";
>>> +		interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
>>> +			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
>>> +		interrupt-names = "int0", "int1";
>>> +		bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
>>
>> Are you intentionally only enabling 1 TX buffer?
>>
> 
> I have used this configuration for testing. It can be increased to 32 if
> required. Is it better to set it to the maximum number of buffers ?
> 

I have now set all the parameters that can be configured, to the their
max values.

"bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;"

Earlier while setting only one tx buffer I was unintentionally limiting
it. As far as I was able to search, the only constraint in setting them
to max values is the memory space allocated for message ram. As in this
case there is enough memory for configuring the message ram with max
values for all parameters, I see that memory space wouldn't be an issue.

After setting the above mentioned configuration I was able to perform a
few tests and they were passing.

I will fix this configuration and send a respin for this series.

Thanks,
Aswath

> Thanks,
> Aswath
> 
>> Marc
>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ