On Tue, Feb 12, 2019 at 4:26 PM Ard Biesheuvel
wrote:
>
> On Tue, 12 Feb 2019 at 04:45, Masahiro Yamada
> wrote:
> >
> > It took me a while to understand what is going on in the nested
> > if-blocks.
> >
> > Simplify it by removing unneeded code.
> >
> > - if_changed automatically adds 'set
On Thu, 2019-02-14 at 12:28 -0500, Mimi Zohar wrote:
> On Wed, 2019-02-13 at 23:16 +0100, Anders Roxell wrote:
> > Commit a893ea15d764 ("tpm: move tpm_chip definition to
> > include/linux/tpm.h") introduced a build error when both ima and efi is
> > enabled. What happens is that both headers
On 2/14/2019 1:21 PM, Dimitri Sivanich wrote:
For the series:
Reviewed-by: Dimitri Sivanich
As well as I:
Reviewed-by: Mike Travis
On Wed, Feb 13, 2019 at 07:34:09PM +, Hedi Berriche wrote:
- Changes since v2
Addressed comments from Ard Biesheuvel:
* expose efi_runtime_lock
For the series:
Reviewed-by: Dimitri Sivanich
On Wed, Feb 13, 2019 at 07:34:09PM +, Hedi Berriche wrote:
> - Changes since v2
> Addressed comments from Ard Biesheuvel:
> * expose efi_runtime_lock to UV platform only instead of globally
> * remove unnecessary #ifdef CONFIG_EFI from
On Thu, Feb 14, 2019 at 09:17:37AM +0100, Ard Biesheuvel wrote:
> On Wed, 13 Feb 2019 at 20:34, Hedi Berriche wrote:
> >
> > - Changes since v2
> > Addressed comments from Ard Biesheuvel:
> > * expose efi_runtime_lock to UV platform only instead of globally
> > * remove unnecessary #ifdef
On Wed, 2019-02-13 at 23:16 +0100, Anders Roxell wrote:
> Commit a893ea15d764 ("tpm: move tpm_chip definition to
> include/linux/tpm.h") introduced a build error when both ima and efi is
> enabled. What happens is that both headers (ima.h and efi.h) defines the
> same 'NONE' constant, and it broke
On Thu, 14 Feb 2019 at 16:48, Marc Zyngier wrote:
>
> Hi Ard,
>
> On 13/02/2019 13:27, Ard Biesheuvel wrote:
> > In the irqchip and EFI code, we have what basically amounts to a quirk
> > to work around a peculiarity in the GICv3 architecture, which permits
> > the system memory address of LPI
Hi Ard,
On 13/02/2019 13:27, Ard Biesheuvel wrote:
> In the irqchip and EFI code, we have what basically amounts to a quirk
> to work around a peculiarity in the GICv3 architecture, which permits
> the system memory address of LPI tables to be programmable only once
> after a CPU reset. This
On Thu, Feb 14, 2019 at 03:57:35PM +0100, Ard Biesheuvel wrote:
> On Thu, 14 Feb 2019 at 09:34, Mike Rapoport wrote:
> >
> > On Wed, Feb 13, 2019 at 02:27:37PM +0100, Ard Biesheuvel wrote:
> > > In the irqchip and EFI code, we have what basically amounts to a quirk
> > > to work around a
On Thu, 14 Feb 2019 at 09:34, Mike Rapoport wrote:
>
> On Wed, Feb 13, 2019 at 02:27:37PM +0100, Ard Biesheuvel wrote:
> > In the irqchip and EFI code, we have what basically amounts to a quirk
> > to work around a peculiarity in the GICv3 architecture, which permits
> > the system memory address
On Wed, Feb 13, 2019 at 02:27:37PM +0100, Ard Biesheuvel wrote:
> In the irqchip and EFI code, we have what basically amounts to a quirk
> to work around a peculiarity in the GICv3 architecture, which permits
> the system memory address of LPI tables to be programmable only once
> after a CPU
On Wed, Feb 13, 2019 at 02:27:37PM +0100, Ard Biesheuvel wrote:
> In the irqchip and EFI code, we have what basically amounts to a quirk
> to work around a peculiarity in the GICv3 architecture, which permits
> the system memory address of LPI tables to be programmable only once
> after a CPU
On Wed, 13 Feb 2019 at 20:34, Hedi Berriche wrote:
>
> - Changes since v2
> Addressed comments from Ard Biesheuvel:
> * expose efi_runtime_lock to UV platform only instead of globally
> * remove unnecessary #ifdef CONFIG_EFI from bios_uv.c
>
> - Changes since v1:
> Addressed comments from
13 matches
Mail list logo
