From: Gao Feng
When make allyesconfig, there is one compile error on my platform
"gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4".
The following is the output.
Documentation/misc-devices/mei/mei-amt-version.c: In function ‘main’:
IAP140 is either based on or was renamed from PXA1908.
Signed-off-by: Andreas Färber
---
v2: new (Thomas)
Documentation/arm/Marvell/README | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm/Marvell/README
On Tuesday, February 21, 2017 10:30:10 AM Viresh Kumar wrote:
> On 20-02-17, 14:58, Rafael J. Wysocki wrote:
> > Yes, it is called for new and inactive policies.
> >
> > For new policies it has to populate policy->cpus (because otherwise the core
> > doesn't know what CPUs should be there), which
On Sun, Feb 19, 2017 at 09:22:35PM -0700, Logan Gunthorpe wrote:
> Really, in any situation where there's a cdev and a device in the same
> structure, the life cycles of the two become linked but their reference
> counts are not and that is the problem here.
Yes, the cdev must hold a kref on the
On Tue, Feb 21, 2017 at 12:42:45PM -0500, Rik van Riel wrote:
> Do we want that in kernel/ or in arch/x86/mm/ ?
If you'd ask me, I don't have a strong preference. It is a pile of
functionality which is part of the SME feature and as such, it is closer
to the CPU. So arch/x86/cpu/sme.c or so.
But
On Sat, 2017-02-18 at 19:12 +0100, Borislav Petkov wrote:
> On Thu, Feb 16, 2017 at 09:41:59AM -0600, Tom Lendacky wrote:
> >
> > create mode 100644 Documentation/x86/amd-memory-encryption.txt
> > create mode 100644 arch/x86/include/asm/mem_encrypt.h
> > create mode 100644
On 2/20/2017 9:21 AM, Borislav Petkov wrote:
On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote:
Adding general kernel support for memory encryption includes:
- Modify and create some page table macros to include the Secure Memory
Encryption (SME) memory encryption mask
Let's not
On Tue, Feb 21, 2017 at 10:30:47PM +1300, Chris Packham wrote:
> Signed-off-by: Chris Packham
Applied to -next.
Thanks,
Guenter
> ---
> Documentation/hwmon/tc654 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Tue, Feb 21, 2017 at 08:55:30AM -0600, Tom Lendacky wrote:
> Actually, %rbp will have the encryption bit set in it at the time of the
> check so if SME is active we won't take the jump to .Lskip_fixup.
Ha, I didn't think of that! Do you see now what I mean with being
explicit in the asm boot
On 2/18/2017 12:12 PM, Borislav Petkov wrote:
On Thu, Feb 16, 2017 at 09:41:59AM -0600, Tom Lendacky wrote:
create mode 100644 Documentation/x86/amd-memory-encryption.txt
create mode 100644 arch/x86/include/asm/mem_encrypt.h
create mode 100644 arch/x86/kernel/mem_encrypt_boot.S
create mode
On Thu, Feb 16, 2017 at 09:45:09AM -0600, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted and needs to be mapped decrypted. Add support to apply the proper
> attributes to the EFI page tables and to the early_memremap and memremap
> APIs to
On 2/20/2017 6:51 AM, Borislav Petkov wrote:
On Thu, Feb 16, 2017 at 09:43:19AM -0600, Tom Lendacky wrote:
This patch adds support to the early boot code to use Secure Memory
Encryption (SME). Support is added to update the early pagetables with
the memory encryption mask and to encrypt the
On Thu, 16 Feb, at 09:44:57AM, Tom Lendacky wrote:
> Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a
> hardcoded 0.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/platform/efi/efi.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
Signed-off-by: Chris Packham
---
Documentation/hwmon/tc654 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
index 91a2843f5f98..47636a8077b4 100644
--- a/Documentation/hwmon/tc654
+++
14 matches
Mail list logo