linux-kernel - Re: [PATCH v2 2/2] irqchip/ti-sci-inta: Add support for unmapped event handling

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 for Android: free password hash cracker in your pocket

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

Message-ID: <714738536a5566c511e83dc424e94bf7@kernel.org>
Date:   Wed, 30 Sep 2020 14:13:29 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     nm@...com, t-kristo@...com, ssantosh@...nel.org,
        tglx@...utronix.de, jason@...edaemon.net, robh+dt@...nel.org,
        lokeshvutla@...com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/2] irqchip/ti-sci-inta: Add support for unmapped
 event handling

On 2020-09-30 11:01, Peter Ujfalusi wrote:
> On 30/09/2020 11.33, Marc Zyngier wrote:
>> On 2020-09-30 08:45, Peter Ujfalusi wrote:
>>> The DMA (BCDMA/PKTDMA and their rings/flows) events are under the 
>>> INTA's
>>> supervision as unmapped events in AM64.
>> 
>> What does "unmapped event" mean? An event that doesn't require a 
>> mapping?
>> Or an internally generated event? Or a proxy event?
>> 
>>> 
>>> In order to keep the current SW stack working, the INTA driver must
>>> replace
>>> the dev_id with it's own when a request comes for BCDMA or PKTDMA
>>> resources.
>> 
>> This seems to support my second option. Please clarify what you mean
>> exactly.
> 
> In previous devices with NAVSS we had event registers in UDMAP and in 
> rings.
> In AM64 with DMSS these event registers have been removed from the DMAs
> (rings are part of the DMAs).
> The event configuration registers in DMSS are part of the INTA and they
> under 'unmapped events'.

Is "unmapped events" an official TI wording, described as such in the 
TRM?

> 
> In essence the difference boils down to the fact that we do not
> configure event numbers (to be consumed by INTA) for the events coming
> from DMAs, but they already have their specific offsets within INTA's
> unmapped region.

OK, so they are not "unmapped". They are just permanently mapped, aren't 
they?

> With this change in hardware we can not use the DMA's ti_sci device
> identification number to configure these events to produce interrupts,
> they are under INTA.
> 
> The only difference in ti_sci API is that for DMA related
> interrupts/events we need to use the INTA's ti_sci device 
> identification
> number in place of the DMA component's.
> 
> I would say that I would describe the unmapped events with your first
> option. They kind of not require mapping from the source to INTA. The
> source of the event (DMA, ring) is pre-configured to send specific
> events to target the unmapped event area at specific offsets.

If they truly don't require a mapping, why is this patch actually 
mapping
them with the INTA as a source? Your explanation doesn't make much sense
to me.

> 
> But in the unmapped event register one can still define either:
> - to send a global event (to be used as trigger or for other purposes)
> - to generate interrupt (in a similar way as the IMAP registers were
> doing in NAVSS).
> 
> I'm not sure if this answers your question...

I still believe the term "unmapped event" doesn't describe what we have
here. These events seems, at least from what the patch does, internally
generated by the INTA.

Irrespective of this, my other comments still stand.

         M.
-- 
Jazz is not dead. It just smells funny...