> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, December 11, 2018 3:45 PM > To: Pankaj Bansal <pankaj.ban...@nxp.com> > Cc: Mark Rutland <mark.rutl...@arm.com>; Leif Lindholm > <leif.lindh...@linaro.org>; Grant Likely <grant.lik...@arm.com>; Varun Sethi > <v.se...@nxp.com>; Udit Kumar <udit.ku...@nxp.com>; Bhupesh Sharma > <bhsha...@redhat.com>; linux-efi <linux-efi@vger.kernel.org> > Subject: Re: [PATCH v2 2/2] drivers: firmware: efi: install new fdt in > configuration table > > On Tue, 11 Dec 2018 at 11:13, Pankaj Bansal <pankaj.ban...@nxp.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > Sent: Tuesday, December 11, 2018 3:41 PM > > > To: Pankaj Bansal <pankaj.ban...@nxp.com> > > > Cc: Mark Rutland <mark.rutl...@arm.com>; Leif Lindholm > > > <leif.lindh...@linaro.org>; Grant Likely <grant.lik...@arm.com>; > > > Varun Sethi <v.se...@nxp.com>; Udit Kumar <udit.ku...@nxp.com>; > > > Bhupesh Sharma <bhsha...@redhat.com>; linux-efi > > > <linux-efi@vger.kernel.org> > > > Subject: Re: [PATCH v2 2/2] drivers: firmware: efi: install new fdt > > > in configuration table > > > > > > On Tue, 11 Dec 2018 at 11:08, Pankaj Bansal <pankaj.ban...@nxp.com> > wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > > > Sent: Tuesday, December 11, 2018 3:32 PM > > > > > To: Pankaj Bansal <pankaj.ban...@nxp.com> > > > > > Subject: Re: [PATCH v2 2/2] drivers: firmware: efi: install new > > > > > fdt in configuration table > > > > > > > > > > On Tue, 11 Dec 2018 at 10:47, Pankaj Bansal > > > > > <pankaj.ban...@nxp.com> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > > > > > Sent: Tuesday, December 11, 2018 3:10 PM > > > > > > > To: Pankaj Bansal <pankaj.ban...@nxp.com> > > > > > > > Subject: Re: [PATCH v2 2/2] drivers: firmware: efi: install > > > > > > > new fdt in configuration table > > > > > > > > > > > > > > On Tue, 11 Dec 2018 at 10:39, Pankaj Bansal > > > > > > > <pankaj.ban...@nxp.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > > > > > > > Sent: Tuesday, December 11, 2018 3:00 PM > > > > > > > > > To: Pankaj Bansal <pankaj.ban...@nxp.com> > > > > > > > > > Cc: Mark Rutland <mark.rutl...@arm.com>; Leif Lindholm > > > > > > > > > <leif.lindh...@linaro.org>; Grant Likely > > > > > > > > > <grant.lik...@arm.com>; Varun Sethi <v.se...@nxp.com>; > > > > > > > > > Udit Kumar <udit.ku...@nxp.com>; Bhupesh Sharma > > > > > > > > > <bhsha...@redhat.com>; linux-efi > > > > > > > > > <linux-efi@vger.kernel.org> > > > > > > > > > Subject: Re: [PATCH v2 2/2] drivers: firmware: efi: > > > > > > > > > install new fdt in configuration table > > > > > > > > > > > > > > > > > > On Tue, 11 Dec 2018 at 10:27, Pankaj Bansal > > > > > > > > > <pankaj.ban...@nxp.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Ard Biesheuvel > > > > > > > > > > > [mailto:ard.biesheu...@linaro.org] > > > > > > > > > > > Sent: Tuesday, December 11, 2018 2:55 PM > > > > > > > > > > > To: Pankaj Bansal <pankaj.ban...@nxp.com> > > > > > > > > > > > Cc: Mark Rutland <mark.rutl...@arm.com>; Leif > > > > > > > > > > > Lindholm <leif.lindh...@linaro.org>; Grant Likely > > > > > > > > > > > <grant.lik...@arm.com>; Varun Sethi > > > > > > > > > > > <v.se...@nxp.com>; Udit Kumar <udit.ku...@nxp.com>; > > > > > > > > > > > Bhupesh Sharma <bhsha...@redhat.com>; linux-efi > > > > > > > > > > > <linux-efi@vger.kernel.org> > > > > > > > > > > > Subject: Re: [PATCH v2 2/2] drivers: firmware: efi: > > > > > > > > > > > install new fdt in configuration table > > > > > > > > > > > > > > > > > > > > > > On Tue, 11 Dec 2018 at 10:23, Pankaj Bansal > > > > > > > > > > > <pankaj.ban...@nxp.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Ard Biesheuvel > > > > > > > > > > > > > [mailto:ard.biesheu...@linaro.org] > > > > > > > > > > > > > Sent: Tuesday, December 11, 2018 2:48 PM > > > > > > > > > > > > > To: Pankaj Bansal <pankaj.ban...@nxp.com> > > > > > > > > > > > > > Cc: Mark Rutland <mark.rutl...@arm.com>; Leif > > > > > > > > > > > > > Lindholm <leif.lindh...@linaro.org>; Grant > > > > > > > > > > > > > Likely <grant.lik...@arm.com>; Varun Sethi > > > > > > > > > > > > > <v.se...@nxp.com>; Udit Kumar > > > > > > > > > > > > > <udit.ku...@nxp.com>; Bhupesh Sharma > > > > > > > > > > > > > <bhsha...@redhat.com>; linux-efi > > > > > > > > > > > > > <linux-efi@vger.kernel.org> > > > > > > > > > > > > > Subject: Re: [PATCH v2 2/2] drivers: firmware: efi: > > > > > > > > > > > > > install new fdt in configuration table > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 11 Dec 2018 at 10:04, Pankaj Bansal > > > > > > > > > > > > > <pankaj.ban...@nxp.com> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bootloader may need to fixup the device tree > > > > > > > > > > > > > > before OS can use > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Therefore, install fdt used by OS in > > > > > > > > > > > > > > configuration tables and associate it with device > > > > > > > > > > > > > > tree > guid. > > > > > > > > > > > > > > > > > > > > > > > > > > > > UEFI/DXE drivers can fixup this device tree in > > > > > > > > > > > > > > their respective ExitBootServices events. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > > > > > > > > > > > > > > Cc: linux-efi@vger.kernel.org > > > > > > > > > > > > > > Signed-off-by: Pankaj Bansal > > > > > > > > > > > > > > <pankaj.ban...@nxp.com> > > > > > > > > > > > > > > > > > > > > > > > > > > I still think this is a bad idea. The firmware > > > > > > > > > > > > > is closely tied to the platform, so it should > > > > > > > > > > > > > provide the DT instead of > > > > > the kernel. > > > > > > > > > > > > > > > > > > > > > > > > It is. It's just that firmware is responsible to > > > > > > > > > > > > fix the status of devices before kernel can use > > > > > > > > > > > > those. In efi stub, the fdt is copied into new_fdt > > > > > > > > > > > before exit boot services. > > > > > > > > > > > > We need to fix the status of devices as part of > > > > > > > > > > > > exit boot services. We cannot do it before, > > > > > > > > > > > > because firmware is using these device and they > > > > > > > > > > > > are not > > > > > > > > > > > ready for kernel to use yet. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That doesn't matter. The kernel will not use devices > > > > > > > > > > > from the DT before > > > > > > > > > > > ExitBootServices() anyway. > > > > > > > > > > > > > > > > > > > > But what is the indication uefi driver has to "relieve > > > > > > > > > > the device and restore it > > > > > > > > > because now kernel need to use it"? > > > > > > > > > > > > > > > > > > That is ExitBootServices(). > > > > > > > > > > > > > > > > > > > The kernel is just like any other UEFI application to > > > > > > > > > > uefi firmware. How will uefi > > > > > > > > > firmware know when to relinquish control? > > > > > > > > > > > > > > > > > > At ExitBootServices() time. Any modification you make to > > > > > > > > > the device tree can be made beforehand, > > > > > > > > > > > > > > > > When you say this, you mean before the ExitBootServices() is > > > > > > > > called > ? > > > > > > > > If yes, then when? Because before ExitBootServices(), the > > > > > > > > firmware is using > > > > > > > the devices and they are not ready for kernel to use. > > > > > > > > Before ExitBootServices, there is no other event that > > > > > > > > indicates that now kernel > > > > > > > is going to boot. > > > > > > > > We fix the status of devices in device tree, only when > > > > > > > > firmware has released > > > > > > > the control and restored the devices for kernel to use. > > > > > > > > If for some reason, the firmware is not able to do so, it > > > > > > > > disables the device in > > > > > > > device tree. > > > > > > > > > > > > > > > > > since the kernel does not even read the device tree to > > > > > > > > > discover devices until after the stub terminates. > > > > > > > > > > > > > > > > Yes, but the stub has already copied the device tree into > > > > > > > > new location. So, any fixups done on device tree in > > > > > > > > configuration table would not > > > > > > > reflect in device tree that kernel would use. > > > > > > > > > > > > > > > > This is why I am registering the new device tree in > > > > > > > > configuration table. BUT only if it was generated from > > > > > > > > device tree already present in configuration table > > > > > > > > > > > > > > The firmware should make changes to the DT before it > > > > > > > supplies it to the > > > OS. > > > > > > > > > > > > The point is that for uefi "supplying DT to OS" is not > > > > > > something that firmware > > > > > can control. > > > > > > Firmware is just running an efi application. It may be OS, but > > > > > > firmware doesn't > > > > > know that. > > > > > > So, firmware cannot release control of the devices beforehand. > > > > > > > > > > The firmware does not have to release control of the devices > > > > > before enabling them in the DT. > > > > > > > > Actually I am not talking about all the devices that uefi firmware > > > > manages. I am talking about some devices that are specific to NXP > > > > platforms. We have some devices in our platform, that operate > > > > differently in uefi firmware than in kernel. So if we were to use > > > > these devices in > > > kernel, we need to release the firmware control over them and prep > > > these for kernel. > > > > If the devices are made ready for kernel to use, then we enable > > > > these in fdt > > > otherwise disable these. > > > > > > > > > > i understand that. > > > > > > But you fail to explain why those DT changes cannot be made while > > > the firmware is still using those devices. The kernel will not look > > > at the DT until after > > > ExitBootServices() so why is it a problem to enable them in the DT > > > earlier? > > > > What if we were not able to prep these devices for kernel? How will we > > disable > these devices? > > Ah. > > That is a completely different matter. > > So why would you be unable to prep a device for the kernel, and why would the > correct course of action be to remove it from the DT as if it no longer > exists?
Actually the preparation of these devices depends on certain parameter files that user supplies. These parameters are not used by firmware but are used by kernel. These parameters need to match to the boot time configuration of platform. That is why these parameters are applied by boot firmware and not by kernel. If there is a mismatch between the boot time configuration and parameters, then the parameters would not be applied. In this case kernel is not able to use the devices. Which is why we disable this particular devices, so that rest of the system can boot. Otherwise the device driver in kernel misbehaves.
