> -----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. > > > If the efi application is not > > OS, then uefi needs the control of devices to function. > > If the efi application is OS, then it will signal ExitBootServices, > > only then uefi knows that the Efi application is OS and uefi firmware needs to > release the devices. > >
