On Tue, 11 Dec 2018 at 11:13, Pankaj Bansal <pankaj.bansal@xxxxxxx> wrote: > > > > > -----Original Message----- > > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > > Sent: Tuesday, December 11, 2018 3:41 PM > > To: Pankaj Bansal <pankaj.bansal@xxxxxxx> > > Cc: Mark Rutland <mark.rutland@xxxxxxx>; Leif Lindholm > > <leif.lindholm@xxxxxxxxxx>; Grant Likely <grant.likely@xxxxxxx>; Varun Sethi > > <V.Sethi@xxxxxxx>; Udit Kumar <udit.kumar@xxxxxxx>; Bhupesh Sharma > > <bhsharma@xxxxxxxxxx>; linux-efi <linux-efi@xxxxxxxxxxxxxxx> > > 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.bansal@xxxxxxx> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > > > > Sent: Tuesday, December 11, 2018 3:32 PM > > > > To: Pankaj Bansal <pankaj.bansal@xxxxxxx> > > > > 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.bansal@xxxxxxx> > > wrote: > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > > > > > > Sent: Tuesday, December 11, 2018 3:10 PM > > > > > > To: Pankaj Bansal <pankaj.bansal@xxxxxxx> > > > > > > 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.bansal@xxxxxxx> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > > > > > > > > Sent: Tuesday, December 11, 2018 3:00 PM > > > > > > > > To: Pankaj Bansal <pankaj.bansal@xxxxxxx> > > > > > > > > Cc: Mark Rutland <mark.rutland@xxxxxxx>; Leif Lindholm > > > > > > > > <leif.lindholm@xxxxxxxxxx>; Grant Likely > > > > > > > > <grant.likely@xxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx>; Udit > > > > > > > > Kumar <udit.kumar@xxxxxxx>; Bhupesh Sharma > > > > > > > > <bhsharma@xxxxxxxxxx>; linux-efi <linux-efi@xxxxxxxxxxxxxxx> > > > > > > > > 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.bansal@xxxxxxx> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > > > > > > > > > > Sent: Tuesday, December 11, 2018 2:55 PM > > > > > > > > > > To: Pankaj Bansal <pankaj.bansal@xxxxxxx> > > > > > > > > > > Cc: Mark Rutland <mark.rutland@xxxxxxx>; Leif Lindholm > > > > > > > > > > <leif.lindholm@xxxxxxxxxx>; Grant Likely > > > > > > > > > > <grant.likely@xxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx>; > > > > > > > > > > Udit Kumar <udit.kumar@xxxxxxx>; Bhupesh Sharma > > > > > > > > > > <bhsharma@xxxxxxxxxx>; linux-efi > > > > > > > > > > <linux-efi@xxxxxxxxxxxxxxx> > > > > > > > > > > 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.bansal@xxxxxxx> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Ard Biesheuvel > > > > > > > > > > > > [mailto:ard.biesheuvel@xxxxxxxxxx] > > > > > > > > > > > > Sent: Tuesday, December 11, 2018 2:48 PM > > > > > > > > > > > > To: Pankaj Bansal <pankaj.bansal@xxxxxxx> > > > > > > > > > > > > Cc: Mark Rutland <mark.rutland@xxxxxxx>; Leif > > > > > > > > > > > > Lindholm <leif.lindholm@xxxxxxxxxx>; Grant Likely > > > > > > > > > > > > <grant.likely@xxxxxxx>; Varun Sethi > > > > > > > > > > > > <V.Sethi@xxxxxxx>; Udit Kumar <udit.kumar@xxxxxxx>; > > > > > > > > > > > > Bhupesh Sharma <bhsharma@xxxxxxxxxx>; linux-efi > > > > > > > > > > > > <linux-efi@xxxxxxxxxxxxxxx> > > > > > > > > > > > > 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.bansal@xxxxxxx> > > > > > > > > > > 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.biesheuvel@xxxxxxxxxx> > > > > > > > > > > > > > Cc: linux-efi@xxxxxxxxxxxxxxx > > > > > > > > > > > > > Signed-off-by: Pankaj Bansal > > > > > > > > > > > > > <pankaj.bansal@xxxxxxx> > > > > > > > > > > > > > > > > > > > > > > > > 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?
