netdev - Re: [PATCH 04/11] of: address: Preserve the flags portion on 1:1 dma-ranges mapping

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: <CAL_JsqKN0ZNMtq+_dhurwLR+FL2MBOmWujp7uy+5HzXxUb_qDQ@mail.gmail.com>
Date: Mon, 26 Aug 2024 16:29:12 -0500
From: Rob Herring <robh@...nel.org>
To: Rob Herring <robh@...nel.org>, Andrea della Porta <andrea.porta@...e.com>, 
	Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Florian Fainelli <florian.fainelli@...adcom.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>, 
	Linus Walleij <linus.walleij@...aro.org>, Catalin Marinas <catalin.marinas@....com>, 
	Will Deacon <will@...nel.org>, Derek Kiernan <derek.kiernan@....com>, 
	Dragan Cvetic <dragan.cvetic@....com>, Arnd Bergmann <arnd@...db.de>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Nicolas Ferre <nicolas.ferre@...rochip.com>, 
	Claudiu Beznea <claudiu.beznea@...on.dev>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Saravana Kannan <saravanak@...gle.com>, Bjorn Helgaas <bhelgaas@...gle.com>, linux-clk@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-gpio@...r.kernel.org, netdev@...r.kernel.org, linux-pci@...r.kernel.org, 
	linux-arch@...r.kernel.org, Lee Jones <lee@...nel.org>, Andrew Lunn <andrew@...n.ch>, 
	Stefan Wahren <wahrenst@....net>
Subject: Re: [PATCH 04/11] of: address: Preserve the flags portion on 1:1
 dma-ranges mapping

On Wed, Aug 21, 2024 at 3:19 AM Andrea della Porta
<andrea.porta@...e.com> wrote:
>
> Hi Rob,
>
> On 19:16 Tue 20 Aug     , Rob Herring wrote:
> > On Tue, Aug 20, 2024 at 04:36:06PM +0200, Andrea della Porta wrote:
> > > A missing or empty dma-ranges in a DT node implies a 1:1 mapping for dma
> > > translations. In this specific case, rhe current behaviour is to zero out
> >
> > typo
>
> Fixed, thanks!
>
> >
> > > the entire specifier so that the translation could be carried on as an
> > > offset from zero.  This includes address specifier that has flags (e.g.
> > > PCI ranges).
> > > Once the flags portion has been zeroed, the translation chain is broken
> > > since the mapping functions will check the upcoming address specifier
> >
> > What does "upcoming address" mean?
>
> Sorry for the confusion, this means "address specifier (with valid flags) fed
> to the translating functions and for which we are looking for a translation".
> While this address has some valid flags set, it will fail the translation step
> since the ranges it is matched against have flags zeroed out by the 1:1 mapping
> condition.
>
> >
> > > against mismatching flags, always failing the 1:1 mapping and its entire
> > > purpose of always succeeding.
> > > Set to zero only the address portion while passing the flags through.
> >
> > Can you point me to what the failing DT looks like. I'm puzzled how
> > things would have worked for anyone.
> >
>
> The following is a simplified and lightly edited) version of the resulting DT
> from RPi5:
>
>  pci@0,0 {
>         #address-cells = <0x03>;
>         #size-cells = <0x02>;
>         ......
>         device_type = "pci";
>         compatible = "pci14e4,2712\0pciclass,060400\0pciclass,0604";
>         ranges = <0x82000000 0x00 0x00   0x82000000 0x00 0x00   0x00 0x600000>;
>         reg = <0x00 0x00 0x00   0x00 0x00>;
>
>         ......
>
>         rp1@0 {

What does 0 represent here? There's no 0 address in 'ranges' below.
Since you said the parent is a PCI-PCI bridge, then the unit-address
would have to be the PCI devfn and you are missing 'reg' (or omitted
it).

>                 #address-cells = <0x02>;
>                 #size-cells = <0x02>;
>                 compatible = "simple-bus";

The parent is a PCI-PCI bridge. Child nodes have to be PCI devices and
"simple-bus" is not a PCI device.

The assumption so far with all of this is that you have some specific
PCI device (and therefore a driver). The simple-buses under it are
defined per BAR. Not really certain if that makes sense in all cases,
but since the address assignment is dynamic, it may have to. I'm also
not completely convinced we should reuse 'simple-bus' here or define
something specific like 'pci-bar-bus' or something.

>                 ranges = <0xc0 0x40000000   0x01 0x00 0x00   0x00 0x400000>;
>                 dma-ranges = <0x10 0x00   0x43000000 0x10 0x00   0x10 0x00>;
>                 ......
>         };
>  };
>
> The pci@0,0 bridge node is automatically created by virtue of
> CONFIG_PCI_DYNAMIC_OF_NODES, and has no dma-ranges, hence it implies 1:1 dma
> mappings (flags for this mapping are set to zero).  The rp1@0 node has
> dma-ranges with flags set (0x43000000). Since 0x43000000 != 0x00 any translation
> will fail.

It's possible that we should fill in 'dma-ranges' when making these
nodes rather than supporting missing dma-ranges here.

Rob