> -----Original Message----- > From: Ard Biesheuvel [mailto:[email protected]] > Sent: Tuesday, December 11, 2018 3:32 PM > To: Pankaj Bansal <[email protected]> > 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 <[email protected]> wrote: > > > > > > > > > -----Original Message----- > > > From: Ard Biesheuvel [mailto:[email protected]] > > > Sent: Tuesday, December 11, 2018 3:10 PM > > > To: Pankaj Bansal <[email protected]> > > > 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 <[email protected]> > wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ard Biesheuvel [mailto:[email protected]] > > > > > Sent: Tuesday, December 11, 2018 3:00 PM > > > > > To: Pankaj Bansal <[email protected]> > > > > > Cc: Mark Rutland <[email protected]>; Leif Lindholm > > > > > <[email protected]>; Grant Likely <[email protected]>; > > > > > Varun Sethi <[email protected]>; Udit Kumar <[email protected]>; > > > > > Bhupesh Sharma <[email protected]>; linux-efi > > > > > <[email protected]> > > > > > 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 > > > > > <[email protected]> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ard Biesheuvel [mailto:[email protected]] > > > > > > > Sent: Tuesday, December 11, 2018 2:55 PM > > > > > > > To: Pankaj Bansal <[email protected]> > > > > > > > Cc: Mark Rutland <[email protected]>; Leif Lindholm > > > > > > > <[email protected]>; Grant Likely > > > > > > > <[email protected]>; Varun Sethi <[email protected]>; Udit > > > > > > > Kumar <[email protected]>; Bhupesh Sharma > > > > > > > <[email protected]>; linux-efi <[email protected]> > > > > > > > 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 > > > > > > > <[email protected]> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Ard Biesheuvel [mailto:[email protected]] > > > > > > > > > Sent: Tuesday, December 11, 2018 2:48 PM > > > > > > > > > To: Pankaj Bansal <[email protected]> > > > > > > > > > Cc: Mark Rutland <[email protected]>; Leif Lindholm > > > > > > > > > <[email protected]>; Grant Likely > > > > > > > > > <[email protected]>; Varun Sethi <[email protected]>; > > > > > > > > > Udit Kumar <[email protected]>; Bhupesh Sharma > > > > > > > > > <[email protected]>; linux-efi > > > > > > > > > <[email protected]> > > > > > > > > > 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 > > > > > > > > > <[email protected]> > > > > > > > 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 <[email protected]> > > > > > > > > > > Cc: [email protected] > > > > > > > > > > Signed-off-by: Pankaj Bansal <[email protected]> > > > > > > > > > > > > > > > > > > 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. > >
