linux-kernel - Re: [PATCH] dt-bindings: memory-controllers: arm,pl353-smc: Extend to support 'arm,pl354' SMC

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:   Mon, 24 Oct 2022 09:31:41 -0500
From:   Rob Herring <robh@...nel.org>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Naga Sureshkumar Relli <nagasure@...inx.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Sureshkumar Relli <naga.sureshkumar.relli@...inx.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: memory-controllers: arm,pl353-smc: Extend to
 support 'arm,pl354' SMC

On Mon, Oct 24, 2022 at 3:14 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Hi Rob,
>
> robh@...nel.org wrote on Fri, 21 Oct 2022 15:39:28 -0500:
>
> > Add support for the Arm PL354 static memory controller to the existing
> > Arm PL353 binding. Both are different configurations of the same IP with
> > support for different types of memory interfaces.
> >
> > The 'arm,pl354' binding has already been in use upstream for a long time
> > in Arm development boards. The existing users have only the controller
> > without any child devices, so drop the required address properties
> > (ranges, #address-cells, #size-cells). The schema for 'ranges' is too
> > constrained as the order is not important and the PL354 has 8
> > chipselects (And the PL353 actually has up to 8 too).
>
> I'm not convinced the ranges constraint should be soften. For me
> the order was important (and the description in the yaml useful, but
> that's a personal opinion). What makes you think the ranges order is
> not relevant on PL353?

Address translation looks for a matching entry, so order doesn't
matter. However, we have seen cases in PCI hosts where the driver
populates registers based on the order of ranges. That's a driver
problem IMO. For PCI, it was multiple entries of the same type. For
this, we have the chip select number in the entry, so we shouldn't
have the same sort of problem. Except there is another issue that the
SRAM interface chipselects are numbered 1 and 2. The PL353 can have 4
NAND chipselects, I don't think the host addresses are necessarily in
order or contiguous either, so you could need 4 entries for NAND. The
existing description doesn't handle that, and the chipselects for the
SRAM interface should have been numbered 4-7. I don't mind saying the
entries should be in order by chipselect, but we can't define indices
of the entries as was done. It's all kind of academic because we don't
have any h/w needing anything else though the Arm boards would if the
child nodes actually got defined (not likely at this point).

Rob