Re: [PATCH v2 2/2] drivers: firmware: efi: install new fdt in configuration table

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux