Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Received-SPF: Fail (protection.outlook.com: domain of arm.com does not
 designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
From:   Ayan Halder <Ayan.Halder@arm.com>
To:     Rob Herring <robh+dt@kernel.org>
CC:     Mark Rutland <Mark.Rutland@arm.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Liviu Dudau <Liviu.Dudau@arm.com>,
        Mihail Atanassov <Mihail.Atanassov@arm.com>,
        "james qian wang (Arm Technology China)" <james.qian.wang@arm.com>,
        Brian Starkey <Brian.Starkey@arm.com>, nd <nd@arm.com>
Subject: Re: Question regarding "reserved-memory"
Thread-Topic: Question regarding "reserved-memory"
Thread-Index: AQHVinZwwZsw70agmEe040OUqUpTNqdp3/4AgAAICoA=
Date:   Thu, 24 Oct 2019 15:19:52 +0000
Message-ID: <20191024151951.GA29067@arm.com>
References: <20191024142211.GA29467@arm.com>
 <CAL_JsqJSSYdRyy=Hw4H613fWVyXM3ivFj8mgO6iwvXZQOr=9pA@mail.gmail.com>
In-Reply-To: <CAL_JsqJSSYdRyy=Hw4H613fWVyXM3ivFj8mgO6iwvXZQOr=9pA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Ayan.Halder@arm.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [217.140.106.53]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 115ac93a-19e1-4949-3e95-08d75895a35a
X-MS-TrafficTypeDiagnostic: AM0PR08MB5137:|AM0PR08MB5137:|AM0PR08MB4596:
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <AM0PR08MB45964382D4A132CA4220E205E46A0@AM0PR08MB4596.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882;
x-forefront-prvs: 0200DDA8BE
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(4636009)(376002)(346002)(366004)(396003)(136003)(39860400002)(189003)(199004)(186003)(76176011)(102836004)(25786009)(86362001)(66946007)(66476007)(66066001)(53546011)(386003)(6506007)(26005)(4326008)(3846002)(6116002)(81166006)(11346002)(81156014)(446003)(2616005)(476003)(486006)(14454004)(66556008)(8676002)(64756008)(66446008)(44832011)(8936002)(478600001)(6486002)(305945005)(7736002)(33656002)(6246003)(14444005)(54906003)(99286004)(316002)(6436002)(229853002)(256004)(5660300002)(2906002)(36756003)(71190400001)(71200400001)(6512007)(52116002)(1076003);DIR:OUT;SFP:1101;SCL:1;SRVR:AM0PR08MB5137;H:AM0PR08MB5345.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: a3Al9ZnNHStOjXXtHSw/cApok7f8XWIGCOsza5kVAHhb0xCwtXipE9m1OokkoR+MAOrf3I/Zz0bNocycfWy8G9CotfSHqqi1seHwTKSbjC0+TK3/UP92JG5bVRMwQ8oarMaP3MjkUWHe+Vagr8mnekTSzKUV+F87YU77BU2gGx/+Py8dT5E0HNYfVr/5ltqwyX21ONOGKZPxsXiURWnxlJ1E/wPoVEKnQTengugBfzf80XergA4vQ1qbKfpsdq0BwMEdSKE63Y8sS1DlBQNqS05/9Fj6qH6T+z0NbLj8CAyFyBA7cEyEio/WQWMvsjXetditfgvYKhu0gOAJY87hwsUhpVE4bDl9w4dCWb2UKLW5GcsyiJEV92LcwZBmZqeYls9n/ZHXWZKv6JBA/jjWzGZBzAf4+8CCmh2chPjavpssvzLs9Q0bciz6lcRnJL4a
Content-Type: text/plain; charset="us-ascii"
Content-ID: <47D9427BD490E34687050EE8A7647BE1@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5137
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Ayan.Halder@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT052.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123;IPV:CAL;SCL:-1;CTRY:IE;EFV:NLI;SFV:NSPM;SFS:(10009020)(4636009)(376002)(39860400002)(346002)(396003)(136003)(1110001)(339900001)(199004)(189003)(3846002)(2906002)(6116002)(4326008)(36906005)(316002)(229853002)(446003)(14444005)(11346002)(305945005)(66066001)(7736002)(8746002)(2616005)(33656002)(5660300002)(336012)(486006)(23726003)(126002)(22756006)(46406003)(476003)(25786009)(356004)(1076003)(478600001)(14454004)(86362001)(50466002)(53546011)(6486002)(76176011)(36756003)(99286004)(26826003)(81166006)(81156014)(8676002)(105606002)(450100002)(8936002)(6862004)(186003)(70206006)(70586007)(386003)(47776003)(76130400001)(54906003)(6246003)(26005)(6512007)(102836004)(97756001)(6506007);DIR:OUT;SFP:1101;SCL:1;SRVR:AM0PR08MB4596;H:64aa7808-outbound-1.mta.getcheckrecipient.com;FPR:;SPF:Fail;LANG:en;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;A:1;MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 7052bbf4-1f77-4373-91ba-08d758959e19
NoDisclaimer: True
X-Forefront-PRVS: 0200DDA8BE
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 5vKLxqUhbaysqC1kj3VsZz4BT/e3KkCqE0avITqwMZwKXAKDE2d+rZcwvEqjKAzSiJJCp0pIX3dDIIv7l/acoq1hHrRAGZckkxFXnSZud13MaqoM5QYr2xxcMFl3Sgq3TD3xNBiDUFaR+Iiqr/7h3TnkskV1E0qb2TW5pyi6igzvN3hzBTYkdjdoBGYfF72OHEA01NZ3IwAd4URCK7WRruNtgvg4vYY0paKv9AFltMnUVDTM+L/vVRS6CaDIQIcUindaoU8SQ6SI66NYjC7BYaZpq0/N9hVxQK6wPUorshomQt/5+KY7M4pzwHdlvi7gABGAutJyQk77uFzyukpC4yq+xzDV0kImSmn6ggZlqLVon/SRmKpk3veQJHaV5/jMhhrJ6Kl8QDmeq5u5UHlVfB2ftV9uffg0vam9Pftoy9E1O2HgXMgECV8byser51sv
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2019 15:20:00.8785
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 115ac93a-19e1-4949-3e95-08d75895a35a
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4596
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Oct 24, 2019 at 09:51:04AM -0500, Rob Herring wrote:
> On Thu, Oct 24, 2019 at 9:22 AM Ayan Halder <Ayan.Halder@arm.com> wrote:
Hi Bob,

Thanks for your quick response.
> >
> >
> > Hi Folks,
> >
> > I have a question regarding "reserved-memory". I am using an Arm Juno
> > platform which has a chunk of ram in its fpga. I intend to make this
> > memory as reserved so that it can be shared between various devices
> > for passing framebuffer.
> >
> > My dts looks like the following:-
> >
> > / {
> >         .... // some nodes
> >
> >         tlx@60000000 {
> >                 compatible =3D "simple-bus";
> >                 ...
> >
> >                 juno_wrapper {
> >
> >                         ... /* here we have all the nodes */
> >                             /* corresponding to the devices in the fpga=
 */
> >
> >                         memory@d000000 {
> >                                device_type =3D "memory";
> >                                reg =3D <0x00 0x60000000 0x00 0x8000000>=
;
> >                         };
> >
> >                         reserved-memory {
> >                                #address-cells =3D <0x01>;
> >                                #size-cells =3D <0x01>;
> >                                ranges;
> >
> >                                framebuffer@d000000 {
> >                                         compatible =3D "shared-dma-pool=
";
> >                                         linux,cma-default;
> >                                         reusable;
> >                                         reg =3D <0x00 0x60000000 0x00 0=
x8000000>;
> >                                         phandle =3D <0x44>;
> >                                 };
> >                         };
> >                         ...
> >                 }
> >         }
> > ...
> > }
> >
> > Note that the depth of the "reserved-memory" node is 3.
> >
> > Refer __fdt_scan_reserved_mem() :-
> >
> >         if (!found && depth =3D=3D 1 && strcmp(uname, "reserved-memory"=
) =3D=3D 0) {
> >
> >                 if (__reserved_mem_check_root(node) !=3D 0) {
> >                         pr_err("Reserved memory: unsupported node
> > format, ignoring\n");
> >                         /* break scan */
> >                         return 1;
> >                 }
> >                 found =3D 1;
> >
> >                 /* scan next node */
> >                 return 0;
> >         }
> >
> > It expects the "reserved-memory" node to be at depth =3D=3D 1 and so it
> > does not probe it in our case.
> >
> > Niether from the
> > Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> >  nor from commit - e8d9d1f5485b52ec3c4d7af839e6914438f6c285,
> > I could understand the reason for such restriction.
> >
> > So, I seek the community's advice as to whether I should fix up
> > __fdt_scan_reserved_mem() so as to do away with the restriction or
> > put the "reserved-memory" node outside of 'tlx@60000000' (which looks
> >  logically incorrect as the memory is on the fpga platform).
>=20
> For now, I'm going to say it must be at the root level.=20
Can you mention it in the Documentation/.../reserved-memory.txt,
please?

> I'd guess the
> memory@d000000 node is also just ignored (wrong unit-address BTW).
I would request you to ignore the address for the time being. In
juno_wrapper{}, we have a complex remapping of addresses of all the
sub-devices. I deliberately did not put that in the snippet, so as to
prevent any distraction from the core issue.

>=20
> I think you're also forgetting the later unflattened parsing of
> /reserved-memory.
Are you talking about the remaining part of the
__fdt_scan_reserved_mem() ie

       ....
        } else if (found && depth < 2) {
                /* scanning of /reserved-memory has been finished */
                return 1;
        }

        if (!of_fdt_device_is_available(initial_boot_params, node))
                return 0;

        err =3D __reserved_mem_reserve_reg(node, uname);
        if (err =3D=3D -ENOENT && of_get_flat_dt_prop(node, "size", NULL))
                fdt_reserved_mem_save_node(node, uname, 0, 0);

        /* scan next node */
        return 0;

If so, I agree with you that it needs to be changed as well (if we
were to do away with the restriction).

> The other complication IIRC is booting with UEFI
> does it's own reserved memory table which often uses the DT table as
> its source.
I have no knowledge of UEFI booting. So if UEFI expects
"reserved-memory" nodes to be at root level, then we must adhere to
the restriction. :)

Ayan
>=20
> Rob