lkml.org 
[lkml]   [2021]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [RFT PATCH v3 06/27] dt-bindings: timer: arm,arch_timer: Add interrupt-names support
    On Mon, 08 Mar 2021 20:38:41 +0000,
    Rob Herring <robh@kernel.org> wrote:
    >
    > On Fri, Mar 05, 2021 at 06:38:41AM +0900, Hector Martin wrote:
    > > Not all platforms provide the same set of timers/interrupts, and Linux
    > > only needs one (plus kvm/guest ones); some platforms are working around
    > > this by using dummy fake interrupts. Implementing interrupt-names allows
    > > the devicetree to specify an arbitrary set of available interrupts, so
    > > the timer code can pick the right one.
    > >
    > > This also adds the hyp-virt timer/interrupt, which was previously not
    > > expressed in the fixed 4-interrupt form.
    > >
    > > Signed-off-by: Hector Martin <marcan@marcan.st>
    > > ---
    > > .../devicetree/bindings/timer/arm,arch_timer.yaml | 14 ++++++++++++++
    > > 1 file changed, 14 insertions(+)
    > >
    > > diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
    > > index 2c75105c1398..ebe9b0bebe41 100644
    > > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
    > > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
    > > @@ -34,11 +34,25 @@ properties:
    > > - arm,armv8-timer
    > >
    > > interrupts:
    > > + minItems: 1
    > > + maxItems: 5
    > > items:
    > > - description: secure timer irq
    > > - description: non-secure timer irq
    > > - description: virtual timer irq
    > > - description: hypervisor timer irq
    > > + - description: hypervisor virtual timer irq
    > > +
    > > + interrupt-names:
    > > + minItems: 1
    > > + maxItems: 5
    > > + items:
    > > + enum:
    > > + - phys-secure
    > > + - phys
    > > + - virt
    > > + - hyp-phys
    > > + - hyp-virt
    >
    > phys-secure and hyp-phys is not very consistent. secure-phys or sec-phys
    > instead?
    >
    > This allows any order which is not ideal (unfortunately json-schema
    > doesn't have a way to define order with optional entries in the middle).
    > How many possible combinations are there which make sense? If that's a
    > reasonable number, I'd rather see them listed out.

    The available of interrupts are a function of the number of security
    states, privileged exception levels and architecture revisions, as
    described in D11.1.1:

    <quote>
    - An EL1 physical timer.
    - A Non-secure EL2 physical timer.
    - An EL3 physical timer.
    - An EL1 virtual timer.
    - A Non-secure EL2 virtual timer.
    - A Secure EL2 virtual timer.
    - A Secure EL2 physical timer.
    </quote>

    * Single security state, EL1 only, ARMv7 & ARMv8.0+ (assumed NS):
    - physical, virtual
    * Single security state, EL1 + EL2, ARMv7 & ARMv8.0 (assumed NS)
    - physical, virtual, hyp physical

    * Single security state, EL1 + EL2, ARMv8.1+ (assumed NS)
    - physical, virtual, hyp physical, hyp virtual

    * Two security states, EL1 + EL3, ARMv7 & ARMv8.0+:
    - secure physical, physical, virtual

    * Two security states, EL1 + EL2 + EL3, ARMv7 & ARMv8.0
    - secure physical, physical, virtual, hyp physical

    * Two security states, EL1 + EL2 + EL3, ARMv8.1+
    - secure physical, physical, virtual, hyp physical, hyp virtual

    * Two security states, EL1 + EL2 + S-EL2 + EL3, ARMv8.4+
    - secure physical, physical, virtual, hyp physical, hyp virtual,
    secure hyp physical, secure hyp virtual

    Nobody has seen the last combination in the wild (that is, outside of
    a SW model).

    I'm really not convinced we want to express this kind of complexity in
    the binding (each of the 7 cases), specially given that we don't
    encode the underlying HW architecture level or number of exception
    levels anywhere, and have ho way to validate such information.

    Thanks,

    M.

    --
    Without deviation from the norm, progress is not possible.

    \
     
     \ /
      Last update: 2021-03-08 23:44    [W:4.378 / U:0.808 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site