From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::d44; helo=mail-io1-xd44.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2C0192119EF45 for ; Wed, 26 Dec 2018 05:46:37 -0800 (PST) Received: by mail-io1-xd44.google.com with SMTP id t24so12342221ioi.0 for ; Wed, 26 Dec 2018 05:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=K0Ac/eywbUc37fReYA5JFYJSvwK7Zcs0DCOLbFftqag=; b=jGGIethPtPHDeK7t9RDi1TZ8NzHGanOznwSSV51IKsUFmfwGuoUpUNprd5tCduBXbv 9zISfFvo+WRi2VgbUncV63fStuspWveyFlCorqwxAu61NZM+grMxBW9nlyanxBlQ55nH dKs2HvS8AEnuC7Ml8IcSvtEzYnhR5kLGZ/K1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=K0Ac/eywbUc37fReYA5JFYJSvwK7Zcs0DCOLbFftqag=; b=AsC9m1+0HQKqEiVosDH38mfJ88EGJ4X8lVDzbdMKglEL+4MwROKBg/CjPSKil04M6G FjHpdjYy2HlVeCodozxNEZ8L5ulOPTku1qS43iRIwoZEmWMXUVFf3mxpzlsU4uYo24Je TclJ/acX0QagCyEgE31T/Lkz8xQlGTARGtKR33IeOjvX93E9sIbYUpnj8vYu+TmR2YU4 oZ3xsOketDPnM2MFeefVC1QgILEZHuWH/yow+iHj7NXtf4mFycVTShH3eaTCmbTqpS2M G/1WQjZA0ZiaKqnd2VthZQWh9tDTRn9zbX1Tu/iu4Lgr3ae1nZwcrFqiBroqLfhFOPkR pcHA== X-Gm-Message-State: AJcUukcEU4Adn7ONrPXvipa2GSpAjai1SFjKr9+IuZ+H+vVSSe5ze3H7 dYSr1+4Yn3J10S2SHSmczptMIY7Pg2vxsrbJFS+gww== X-Google-Smtp-Source: ALg8bN7ReKpzkDK1BVdXaIu03wlNrrVUiWmrvQt1CQfH2lV8dXP6uTcLYbUbYeTpMAUrBJ109LkVc8VD1AyWPGh3deM= X-Received: by 2002:a6b:5d01:: with SMTP id r1mr12885113iob.170.1545831996745; Wed, 26 Dec 2018 05:46:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Wed, 26 Dec 2018 14:46:25 +0100 Message-ID: To: Pankaj Bansal Cc: Varun Sethi , Udit Kumar , linux-efi , "edk2-devel@lists.01.org" Subject: Re: Uefi runtime property in device tree X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 13:46:38 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 26 Dec 2018 at 11:15, Pankaj Bansal wrote: > > Hello Ard et al. > > I have a query regarding the device tree usage in UEFI. > In our UEFI implementation for NXP SOCs, we are using device tree to dete= ct Non discoverable platform devices. > Based on the device detected in device tree, a device instance is created= and the device=E2=80=99s driver binds to that device=E2=80=99s handle (a D= XE driver or an UEFI driver). > if the device were to be used for runtime service, then we need to alloca= te the memory for that device instance from runtime pool and set its virtua= l address using EfiConvertPointer. > To facilitate this, I wish to add an optional property to the device node= =E2=80=9Cuefi-runtime=E2=80=9D. > If this property is present in device tree the UEFI firmware will allocat= e the data from runtime pool for this device. > Also firmware will disable/delete the node in device tree before passing = onto OS, so that OS doesn=E2=80=99t use the device. > > I wish to know your thoughts on this. If this doesn=E2=80=99t seem the ri= ght way, I am happy to hear your suggestions. > Hello Pankaj, In general, you are free to do whatever you like in the internal implementation of your firmware. You can invent your own DT properties, bindings, etc, or even invent your own description language altogether as long as you ensure that the descriptions don't leak into places where they are visible to the OS. However, I do wonder how generic this has to be. Since the DT and the firmware will be tightly coupled in any case, what is preventing you from defining the RTC and NOR flash devices as DT device paths in the firmware source, and attaching to them directly rather than traversing the device tree looking for uefi_runtime nodes. Note that *any* logic that operates on device trees that are provided by the OS to the firmware will be rejected. It is the firmware's job to describe the platform to the OS, not the other way around.