linux-kernel - Re: [PATCH 1/2] dt-bindings: mailbox : arm,mhuv2: Allow for more RX interrupts

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: <ZDawMI0d2vv/rrRh@e120937-lin>
Date:   Wed, 12 Apr 2023 14:20:48 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     Rob Herring <robh@...nel.org>
Cc:     Sudeep Holla <sudeep.holla@....com>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, vincent.guittot@...aro.org,
        souvik.chakravarty@....com, nicola.mazzucato@....com,
        Tushar.Khandelwal@....com, viresh.kumar@...aro.org,
        jassisinghbrar@...il.com,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: mailbox : arm,mhuv2: Allow for more RX
 interrupts

On Wed, Apr 12, 2023 at 08:15:21AM -0500, Rob Herring wrote:
> On Thu, Mar 30, 2023 at 09:29:23AM +0100, Cristian Marussi wrote:
> > On Wed, Mar 29, 2023 at 06:44:31PM +0100, Sudeep Holla wrote:
> > > On Wed, Mar 29, 2023 at 04:39:35PM +0100, Cristian Marussi wrote:
> > > > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the
> > > > maximum number of available channels, but anyway no more than the maximum
> > > > number of supported interrupt for an AMBA device.
> > > > 
> > > > Signed-off-by: Cristian Marussi <cristian.marussi@....com>
> > > > ---
> > > > Cc: Rob Herring <robh+dt@...nel.org>
> > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
> > > > Cc: devicetree@...r.kernel.org
> > > > 
> > > >  .../devicetree/bindings/mailbox/arm,mhuv2.yaml      | 13 +++++++++----
> > > >  1 file changed, 9 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
> > > > index a4f1fe63659a..5a57f4e2a623 100644
> > > > --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
> > > > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
> > > > @@ -69,10 +69,15 @@ properties:
> > > >  
> > > >    interrupts:
> > > >      description: |
> > > > -      The MHUv2 controller always implements an interrupt in the "receiver"
> > > > -      mode, while the interrupt in the "sender" mode was not available in the
> > > > -      version MHUv2.0, but the later versions do have it.
> > > > -    maxItems: 1
> > > > +      The MHUv2 controller always implements at least an interrupt in the
> > > > +      "receiver" mode, while the interrupt in the "sender" mode was not
> > > > +      available in the version MHUv2.0, but the later versions do have it.
> > > > +      In "receiver" mode, beside a single combined interrupt, there could be
> > > > +      multiple interrupts, up to the number of implemented channels but anyway
> > > > +      no more than the maximum number of interrupts potentially supported by
> > > > +      AMBA.
> > > > +    minItems: 1
> > > > +    maxItems: 9
> > > 
> > 
> > Hi,
> > 
> > > I am not sure 9 is the correct value here. IIUC it is just what Linux defines
> > > as AMBA_NR_IRQS. Looking at the history it was bumped from 2 to 9 for use
> > > by PL330 DMA driver. I couldn't find anything to relate this 9 in any
> > > AMBA or other related specification.
> > > 
> > 
> > Yes, I could not find either where the 9 comes from, but it is what
> > currently each amba device is limited to, at the software level, in terms of
> > interrupts that can be detected.
> 
> IIRC, the PL330 can have an interrupt per context with up to 8 contexts 
> and then 1 global interrupt.
> 
> > 
> > > Ideally I would say we don't know what the max here. We just have a platform
> > > implementing 2 interrupts now. Do we for with 2 for now and change it if some
> > > new users require more in the future ?
> > > 
> > 
> > By the spec seems to me that the maximum number of interrupts are equal to
> > the maximum possible channels (124), or one combined interrupt.
> > 
> > But these in turn, as said, are capped by the AMBA_NR_IRQS and I have
> > only seen one system using 2. (for which I need this series to work)
> > 
> > > I will leave that to the DT maintainers but 9 is simply random based on Linux
> > > code so I would rather choose some other random number with a better reasoning
> > > than 9 as AMBA code in the kernel is limiting it to 9.
> > > 
> > 
> > Agreed. Aiming to describe any possible hw in the DT, I would say 124 at
> > this point. (even though implausible not to use the combined interrupt
> > at that point...)
> 
> Then use 124, but please describe how you get that in the description.
> 

Ok, thanks, I'll do.
Cristian