linux-kernel - Re: [PATCH 3/3 v2] arm64: dts: renesas: add MOST device

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]

Message-ID: <fccd00c9-ec44-9586-0df2-6e46568665c1@cogentembedded.com>
Date:   Wed, 12 Jan 2022 11:56:50 +0300
From:   Nikita Yushchenko <nikita.yoush@...entembedded.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Magnus Damm <magnus.damm@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christian Gromm <christian.gromm@...rochip.com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, linux-staging@...ts.linux.dev,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3 v2] arm64: dts: renesas: add MOST device

>> +                       reg = <0 0xec520000 0 0x800>;
>> +                       interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>,
>> +                               <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>,
>> +                               <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>,
>> +                               <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>,
>> +                               <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>;
> 
> What is the purpose of the various interrupts?
> Perhaps you need interrupt-names?
> The driver seems to use only the first two, which is strange, as
> the second and third interrupt handle different channels.

Maybe Christian Gromm (the original driver author) can comment here?

As far as I understand:
- interrupts are: mlb, ahb0, ahb1, ch0rx, ch1rx
- of those, the first 3 are from dim2 itself, and the last two are from renesas-specific logic around dim2
- in the interrupt assignment tables for gen3 SoCs, renesas documents all 5 interrupts, however in the 
mlb section, renesas mentions only mlb, ahb0 and ch0rx interrupts
- moreover, renesas explicitly denies access dim2 registers responsible for channels 32..63 - which 
renders ahb1 interrupt useless; and renesas does not document any registers related to "async rx 
response" on channels 32..63 - which renders chrx1 interrupt useless
- anyway, dim2 driver registers only 32 channels (for all use cases, not only for renesas), and thus 
uses only ahb0 interrupt
- dim2 driver does not implement renesas-specific processing logic and thus does not use ch0rx interrupt

I'm not sure how to proceed here.
Is it better to define only two interrupts (mlb, ahb0) in device trees?

Regarding 'interrupt-names' - dim2 driver currently uses platform_get_irq() and thus depends on numeric 
positions (mlb interrupt at index 0 and ahb0 interrupt at index 1). I'm not sure about current use cases 
of the driver other than with rcar-gen3, and if it is ok to use of_get_irq_byname() instead. And without 
using of_get_irq_byname(), interrupt-names looks somewhat useless.

> But without any DT binding documentation
> for this hardware block, this is hard to validate, and not yet ready for
> upstream integration.

Christian, are you going to provide DT binding documentation for dim2?

Nikita