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::134; helo=mail-it1-x134.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 9F3B4210F16D1 for ; Thu, 27 Dec 2018 01:58:21 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id c9so23111743itj.1 for ; Thu, 27 Dec 2018 01:58:21 -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=VEhauXD1pC/anyTtfb3UgiyhtgIwy8CUjMiPPjPkIVM=; b=A9p/eiRR0hOy6zGXPOyfhdDT7b7c9MQysa1VbrO5KIvE+kzeyQSNrrL/ki/m1JVI1H Nef9AQo4KPsnfSpCL9sPtmB1zynA7rsOmkaYhauVqYqM5dPTjbeaIRMrsnL+5Yhn6XEA 9jGpJGQrcB8WMXzx7VB6VRUlZ9n7aT8pdeKwA= 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=VEhauXD1pC/anyTtfb3UgiyhtgIwy8CUjMiPPjPkIVM=; b=lx/lZCaiV72qhdxMVDNJ0iSEnGk5NjeDVTJs+7vfa97XqJEHCbfBsU4pRQ8B2b6hgZ +omkc2M0oC+Yko7wqqjJlwSn1QgRcwUt1j67qzT5mMLN7TL2XKGNsf14Nuda0q/7Y/Kg dKIPKz0LnHPyIoK6luhG+8PIyCTJnJrN39E2cYmRlyo54kCuyLHbCsNxom7G6j5toP7k 2ptK01i0rDaI9AkKcP4DBbRTcODIvd5ZI8AK6xYrFVxUvd8B5cB3Bjh8o3BqXT/V8PpU 2MuHdw7/74v55EgvhY1vIvoOjZNg6i73GJYM7RzWyH7rE0Pbs1FQBCghyHo1k3T0Ylg4 3/Yg== X-Gm-Message-State: AA+aEWZ/wLaqt6G4wxYRpo4Mt5K9Xzxm2L/TyLAucHM/Ov6aFMLrJBXC U2D61tW1xjDer5u9ueFcnZv2D0wgzG4voOWe9hAmkg== X-Google-Smtp-Source: AFSGD/Xz0LYoCXV/3Zh9ps9EVI/9tS1o9UyNLpCWRmEe7v5QMKHKWl2lni2CEuY80PVF2Oape/OUHuQ/njVxfzaYlas= X-Received: by 2002:a02:734b:: with SMTP id a11mr14055773jae.62.1545904700532; Thu, 27 Dec 2018 01:58:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Thu, 27 Dec 2018 10:58:09 +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: Thu, 27 Dec 2018 09:58:21 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 27 Dec 2018 at 10:53, Pankaj Bansal wrote: > > Hello Ard, > > Thanks for replying > > > -----Original Message----- > > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > > Sent: Wednesday, December 26, 2018 7:16 PM > > To: Pankaj Bansal > > Cc: Varun Sethi ; Udit Kumar ; lin= ux- > > efi ; edk2-devel@lists.01.org > > Subject: Re: Uefi runtime property in device tree > > > > On Wed, 26 Dec 2018 at 11:15, Pankaj Bansal wro= te: > > > > > > 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 = detect > > Non discoverable platform devices. > > > Based on the device detected in device tree, a device instance is cre= ated and > > the device=E2=80=99s driver binds to that device=E2=80=99s handle (a DX= E driver or an UEFI driver). > > > if the device were to be used for runtime service, then we need to al= locate the > > memory for that device instance from runtime pool and set its virtual a= ddress > > 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 all= ocate the > > data from runtime pool for this device. > > > Also firmware will disable/delete the node in device tree before pass= ing 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 th= e right way, I am > > happy to hear your suggestions. > > > > > > > Hello Pankaj, > > > > In general, you are free to do whatever you like in the internal implem= entation > > 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 t= hat 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 f= irmware > > will be tightly coupled in any case, what is preventing you from defini= ng the RTC > > and NOR flash devices as DT device paths in the firmware source, and at= taching > > to them directly rather than traversing the device tree looking for uef= i_runtime > > nodes. > > The UEFI driver model that we are following, creates the device instances= for all the devices > attached to a controller by parsing DT node and sub nodes of a controller= on ConnectController call. > So we are not traversing the DT for runtime devices, rather we need to kn= ow if the device is runtime > or not when parsing the DT node. > > Take the case of SPI NOR for example. When a SPI controller is connected,= then instances for all the NOR flash devices > attached to controller are created. Only one of the NOR flash attached to= SPI bus is going to be used for runtime service. > But how does that matter? You cannot share the controller between the OS and the firmware anyway? The same applies to I2C controllers for RTC, for instance: it doesn't really fit a generic driver model. In my experience, this kind of 'flexibility' looks good in theory, but doesn't give that much benefit in practice. > > > > Note that *any* logic that operates on device trees that are provided b= y 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. > > I have a question : if we want to use DT for DXE phase in firmware and to= boot OS, should we use a common DT for firmware and OS or separate? > > If DT HAS TO BE SAME, then how do we solve this conundrum ? https://elinu= x.org/Device_Tree_Linux#forward_and_backward_dts_compatibility > Current practice is that > =E2=80=A2 new kernels work with old devicetrees > =E2=80=A2 old kernels may or may not work with new devicetrees > This means that if a binding is modified in a non-compatible manner then = the kernel implementation must still recognize the old binding until old de= vicetrees have been obsoleted and no longer exist. > > i.e. a platform's DT is updated in linux 4.19 and I start to use it in UE= FI. Then I try to boot linux 4.9 with it and it fails. > As I said before, how the firmware uses DT internally is entirely up to you. You can use the same DT or different DTs. The only contract you are bound by is the contract between the firmware and the OS, and this only applies to DT info that is exposed to the OS.