Re: [PATCH] ARM: efi: Simplify arch_efi_call_virt() macro by using typeof()

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

 



On Wed, 29 Jun 2022 at 10:57, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>
> On Tue, Jun 28, 2022 at 07:58:38PM +0200, Ard Biesheuvel wrote:
> > On Tue, 28 Jun 2022 at 16:09, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
> > >
> > > On Tue, Jun 28, 2022 at 03:57:38PM +0200, Ard Biesheuvel wrote:
> > > > On Tue, 28 Jun 2022 at 15:47, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
> > > > >
> > ...
> >
> > > > > I am yet to figure out how asm/efi.h and linux/efi.h are included so that
> > > > > we can have generic definition in linux/efi.h and x86 can undefine that
> > > > > and redefine its own version.
> > > > >
> > > > > Does that make sense ?
> > > > >
> > > >
> > > > I appreciate the effort, but for now, let's just fix the ones we need
> > > > to fix (and the ARM one too while we're at it). PRM can only be
> > > > enabled on x86 and arm64 anyway.
> > >
> > > True. OK then I will just update ARM version and leave loongarch as is.
> > >
> >
> > Actually, this was rather straight-forward so I folded this change
> > into your ARM patch.
>
> I see you have the generic version for all archs except arm64 and x86 as
> we discussed earlier. Since you have even included the arm64 changes, the
> PRMT enablement patches need to routed via your tree now as it depends on
> the change you have in your -next.
>
> Are you OK with that if Rafael agrees ? I can ask him on the other thread.
> No further changes are needed. Let me know.
>

Yes, that is fine. Or I can put that patch on a stable branch by itself.



[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