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, 19 Apr 2023 15:40:24 -0500
From:   "Mendez, Judith" <jm@...com>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        <linux-can@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Andrew Davis <afd@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Nishanth Menon <nm@...com>,
        Chandrasekar Ramakrishnan <rcsekar@...sung.com>,
        <devicetree@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] Enable multiple MCAN on AM62x

Hello Marc,

On 4/19/2023 1:10 AM, Marc Kleine-Budde wrote:
> On 18.04.2023 11:15:35, Mendez, Judith wrote:
>> Hello Marc,
>>
>> On 4/14/2023 12:49 PM, Marc Kleine-Budde wrote:
>>> On 13.04.2023 17:30:46, Judith Mendez wrote:
>>>> On AM62x there is one MCAN in MAIN domain and two in MCU domain.
>>>> The MCANs in MCU domain were not enabled since there is no
>>>> hardware interrupt routed to A53 GIC interrupt controller.
>>>> Therefore A53 Linux cannot be interrupted by MCU MCANs.
>>>
>>> Is this a general hardware limitation, that effects all MCU domain
>>> peripherals? Is there a mailbox mechanism between the MCU and the MAIN
>>> domain, would it be possible to pass the IRQ with a small firmware on
>>> the MCU? Anyways, that's future optimization.
>>
>> This is a hardware limitation that affects AM62x SoC and has been carried
>> over to at least 1 other SoC. Using the MCU is an idea that we have juggled
>> around for a while, we will definitely keep it in mind for future
>> optimization. Thanks for your feedback.
> 
> Once you have a proper IRQ de-multiplexer, you can integrate it into the
> system with a DT change only. No need for changes in the m_can driver.
> 

Is this a recommendation for the current patch?

The reason I am asking is because adding firmware for the M4 to forward
a mailbox with the IRQ to the A53 sounds like a good idea and we have 
been juggling the idea, but it is not an ideal solution if customers are
using the M4 for other purposes like safety.

>>>> This solution instantiates a hrtimer with 1 ms polling interval
>>>> for a MCAN when there is no hardware interrupt. This hrtimer
>>>> generates a recurring software interrupt which allows to call the
>>>> isr. The isr will check if there is pending transaction by reading
>>>> a register and proceed normally if there is.
>>>>
>>>> On AM62x this series enables two MCU MCAN which will use the hrtimer
>>>> implementation. MCANs with hardware interrupt routed to A53 Linux
>>>> will continue to use the hardware interrupt as expected.
>>>>
>>>> Timer polling method was tested on both classic CAN and CAN-FD
>>>> at 125 KBPS, 250 KBPS, 1 MBPS and 2.5 MBPS with 4 MBPS bitrate
>>>> switching.
>>>>
>>>> Letency and CPU load benchmarks were tested on 3x MCAN on AM62x.
>>>> 1 MBPS timer polling interval is the better timer polling interval
>>>> since it has comparable latency to hardware interrupt with the worse
>>>> case being 1ms + CAN frame propagation time and CPU load is not
>>>> substantial. Latency can be improved further with less than 1 ms
>>>> polling intervals, howerver it is at the cost of CPU usage since CPU
>>>> load increases at 0.5 ms and lower polling periods than 1ms.
> 
> Have you seen my suggestion of the poll-interval?
> 
> Some Linux input drivers have the property poll-interval, would it make
> sense to ass this here too?

Looking at some examples, I do think we could implement this 
poll-interval attribute, then read in the driver and initialize the 
hrtimer based on this. I like the idea to submit as a future 
optimization patch, thanks!

regards,
Judith

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ