linux-kernel - Re: [PATCH 00/11] of: dma-ranges fixes and improvements

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: <20190930082055.GA21971@infradead.org>
Date:   Mon, 30 Sep 2019 01:20:55 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Rob Herring <robh@...nel.org>, DTML <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Robin Murphy <robin.murphy@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Stefan Wahren <wahrenst@....net>,
        Frank Rowand <frowand.list@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Simon Horman <horms+renesas@...ge.net.au>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Oza Pawandeep <oza.oza@...adcom.com>,
        Christoph Hellwig <hch@...radead.org>,
        Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH 00/11] of: dma-ranges fixes and improvements

On Sun, Sep 29, 2019 at 01:16:20PM +0200, Arnd Bergmann wrote:
> On a semi-related note, Thierry asked about one aspect of the dma-ranges
> property recently, which is the behavior of dma_set_mask() and related
> functions when a driver sets a mask that is larger than the memory
> area in the bus-ranges but smaller than the available physical RAM.
> As I understood Thierry's problem and the current code, the generic
> dma_set_mask() will either reject the new mask entirely or override
> the mask set by of_dma_configure, but it fails to set a correct mask
> within the limitations of the parent bus in this case.

There days dma_set_mask will only reject a mask if it is too small
to be supported by the hardware.  Larger than required masks are now
always accepted.