Hi Linus,
Please pull the changes for the parisc architecture for v4.11 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.11-1
Nothing really important in this patchset: Fix resource leaks in error paths,
coding style cleanups and code removal.
Thanks,
Helge
Hi Linus,
Please pull the changes for the parisc architecture for v4.11 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.11-1
Nothing really important in this patchset: Fix resource leaks in error paths,
coding style cleanups and code removal.
Thanks,
Helge
Tracefs or debugfs were causing hundreds to thousands of null PATH
records to be associated with the init_module and finit_module SYSCALL
records on a few modules when the following rule was in place for
startup:
-a always,exit -F arch=x86_64 -S init_module -F key=mod-load
In
Tracefs or debugfs were causing hundreds to thousands of null PATH
records to be associated with the init_module and finit_module SYSCALL
records on a few modules when the following rule was in place for
startup:
-a always,exit -F arch=x86_64 -S init_module -F key=mod-load
In
Am 03.03.2017 um 15:11 schrieb Boris Brezillon:
>> And add a list of successfully added notifiers, along with their
>> data pointer, to the MTD device. That's simple and would also remove
>> the need for notifier to have a private list of their instances as I
>> had to do here.
>
> And then
Am 03.03.2017 um 15:11 schrieb Boris Brezillon:
>> And add a list of successfully added notifiers, along with their
>> data pointer, to the MTD device. That's simple and would also remove
>> the need for notifier to have a private list of their instances as I
>> had to do here.
>
> And then
Hi Pavel,
On Thu, Mar 02, 2017 at 01:38:48PM +0100, Pavel Machek wrote:
> Hi!
>
> > > Ok, how about this one?
> > > omap3isp: add rest of CSI1 support
> > >
> > > CSI1 needs one more bit to be set up. Do just that.
> > >
> > > It is not as straightforward as I'd like, see the comments
Hi Pavel,
On Thu, Mar 02, 2017 at 01:38:48PM +0100, Pavel Machek wrote:
> Hi!
>
> > > Ok, how about this one?
> > > omap3isp: add rest of CSI1 support
> > >
> > > CSI1 needs one more bit to be set up. Do just that.
> > >
> > > It is not as straightforward as I'd like, see the comments
Hi!
> [auto build test ERROR on linuxtv-media/master]
> [also build test ERROR on v4.10 next-20170303]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
Yes, the patch is against Sakari's ccp2 branch. It should work ok
Hi!
> [auto build test ERROR on linuxtv-media/master]
> [also build test ERROR on v4.10 next-20170303]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
Yes, the patch is against Sakari's ccp2 branch. It should work ok
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
...to receive a fix and regression test case for nvdimm namespace
label compatibility.
Details:
An "nvdimm namespace label" is metadata on an nvdimm that provisions
dimm capacity into a
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
...to receive a fix and regression test case for nvdimm namespace
label compatibility.
Details:
An "nvdimm namespace label" is metadata on an nvdimm that provisions
dimm capacity into a
>>> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM
>>> cortex-a15) wherein pages allocated by vmalloc are in highmem region
>>> that are not addressable using 32 bit addresses and is backed by LPAE.
>>> So, a 32 bit DMA cannot access these buffers at all.
>>> When
>>> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM
>>> cortex-a15) wherein pages allocated by vmalloc are in highmem region
>>> that are not addressable using 32 bit addresses and is backed by LPAE.
>>> So, a 32 bit DMA cannot access these buffers at all.
>>> When
Hello Krzysztof,
On 02/11/2017 05:14 PM, Krzysztof Kozlowski wrote:
> In Odroid XU3 Lite board, the temperature levels reported for thermal
> zone 0 were weird. In warm room:
> /sys/class/thermal/thermal_zone0/temp:32000
> /sys/class/thermal/thermal_zone1/temp:51000
>
Hello Krzysztof,
On 02/11/2017 05:14 PM, Krzysztof Kozlowski wrote:
> In Odroid XU3 Lite board, the temperature levels reported for thermal
> zone 0 were weird. In warm room:
> /sys/class/thermal/thermal_zone0/temp:32000
> /sys/class/thermal/thermal_zone1/temp:51000
>
/xtensa-20170303
for you to fetch changes up to b46dcfa378b0cdea1ee832802c9e36750e0fffa9:
xtensa: allow merging vectors into .text section (2017-03-01 12:32:50 -0800)
Xtensa improvements for v4.11:
- clean up bootable image build
/xtensa-20170303
for you to fetch changes up to b46dcfa378b0cdea1ee832802c9e36750e0fffa9:
xtensa: allow merging vectors into .text section (2017-03-01 12:32:50 -0800)
Xtensa improvements for v4.11:
- clean up bootable image build
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T*)x)->f
|
- (T*)
e
)
Signed-off-by: simran singhal
---
drivers/staging/nvec/nvec_kbd.c | 2 +-
1 file changed, 1
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T*)x)->f
|
- (T*)
e
)
Signed-off-by: simran singhal
---
drivers/staging/nvec/nvec_kbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi Bjorn,
On 03/03/2017 02:33 PM, Bjorn Helgaas wrote:
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
This RFC series provides support for AMD's new Secure Encrypted Virtualization
(SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1].
What kernel
Hi Bjorn,
On 03/03/2017 02:33 PM, Bjorn Helgaas wrote:
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
This RFC series provides support for AMD's new Secure Encrypted Virtualization
(SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1].
What kernel
This is v5 of this series. The four previous submissions can be found
here [1], here [2], here[3], and here [4]. This version addresses the
comments received in v4 plus improvements of the handling of emulation
in 64-bit builds. Please see details in the change log.
=== What is UMIP?
User-Mode
This is v5 of this series. The four previous submissions can be found
here [1], here [2], here[3], and here [4]. This version addresses the
comments received in v4 plus improvements of the handling of emulation
in 64-bit builds. Please see details in the change log.
=== What is UMIP?
User-Mode
Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when memory addressing is used
(i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
the SIB byte points to the R/ESP (i.e., index = 4), the index should not be
used in the
Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when memory addressing is used
(i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
the SIB byte points to the R/ESP (i.e., index = 4), the index should not be
used in the
Even though memory addresses are unsigned. The operands used to compute the
effective address do have a sign. This is true for the r/m part of the
ModRM byte, the base and index parts of the SiB byte as well as the
displacement. Thus, signed variables shall be used when computing the
effective
The segment descriptor contains information that is relevant to how linear
address need to be computed. It contains the default size of addresses as
well as the base address of the segment. Thus, given a segment selector,
we ought look at segment descriptor to correctly calculate the linear
Even though memory addresses are unsigned. The operands used to compute the
effective address do have a sign. This is true for the r/m part of the
ModRM byte, the base and index parts of the SiB byte as well as the
displacement. Thus, signed variables shall be used when computing the
effective
The segment descriptor contains information that is relevant to how linear
address need to be computed. It contains the default size of addresses as
well as the base address of the segment. Thus, given a segment selector,
we ought look at segment descriptor to correctly calculate the linear
With segmentation, the base address of the segment descriptor is needed
to compute a linear address. The segment descriptor used in the address
computation depends on either any segment override prefixes in the in the
instruction or the default segment determined by the registers involved
in the
With segmentation, the base address of the segment descriptor is needed
to compute a linear address. The segment descriptor used in the address
computation depends on either any segment override prefixes in the in the
instruction or the default segment determined by the registers involved
in the
Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when a SIB byte is used and the
base of the SIB byte points to R/EBP (i.e., base = 5) and the mod part
of the ModRM byte is zero, the value of such register will not be used
as part of the
These functions read the default values of the address and operand sizes
as specified in the segment descriptor. This information is determined
from the D and L bits. Hence, it can be used for both IA-32e 64-bit and
32-bit legacy modes. For virtual-8086 mode, the default address and
operand sizes
Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when the mod part of the ModRM
byte is zero and R/EBP is specified in the R/M part of such bit, the value
of the aforementioned register should not be used in the address
computation. Instead,
Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when a SIB byte is used and the
base of the SIB byte points to R/EBP (i.e., base = 5) and the mod part
of the ModRM byte is zero, the value of such register will not be used
as part of the
These functions read the default values of the address and operand sizes
as specified in the segment descriptor. This information is determined
from the D and L bits. Hence, it can be used for both IA-32e 64-bit and
32-bit legacy modes. For virtual-8086 mode, the default address and
operand sizes
Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software
Developer's Manual volume 2A states that when the mod part of the ModRM
byte is zero and R/EBP is specified in the R/M part of such bit, the value
of the aforementioned register should not be used in the address
computation. Instead,
User-Mode Instruction Prevention is a security feature present in new
Intel processors that, when set, prevents the execution of a subset of
instructions if such instructions are executed in user mode (CPL > 0).
Attempting to execute such instructions causes a general protection
exception.
The
User-Mode Instruction Prevention is a security feature present in new
Intel processors that, when set, prevents the execution of a subset of
instructions if such instructions are executed in user mode (CPL > 0).
Attempting to execute such instructions causes a general protection
exception.
The
insn_get_addr_ref returns the effective address as defined by the
section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software
Developer's Manual. In order to compute the linear address, we must add
to the effective address the segment base address as set in the segment
descriptor.
insn_get_addr_ref returns the effective address as defined by the
section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software
Developer's Manual. In order to compute the linear address, we must add
to the effective address the segment base address as set in the segment
descriptor.
Convert the function insn_get_add_ref into a wrapper function that calls
the correct static address-decoding function depending on the size of the
address. In this way, callers do not need to worry about calling the
correct function and decreases the number of functions that need to be
exposed.
Tasks running in virtual-8086 mode or in protected mode with code
segment descriptors that specify 16-bit default address sizes via the
D bit will use 16-bit addressing form encodings as described in the Intel
64 and IA-32 Architecture Software Developer's Manual Volume 2A Section
2.1.5. 16-bit
Convert the function insn_get_add_ref into a wrapper function that calls
the correct static address-decoding function depending on the size of the
address. In this way, callers do not need to worry about calling the
correct function and decreases the number of functions that need to be
exposed.
Tasks running in virtual-8086 mode or in protected mode with code
segment descriptors that specify 16-bit default address sizes via the
D bit will use 16-bit addressing form encodings as described in the Intel
64 and IA-32 Architecture Software Developer's Manual Volume 2A Section
2.1.5. 16-bit
The 32-bit and 64-bit address encodings are identical. This means that we
can use the same function in both cases. In order to reuse the function for
32-bit address encodings, we must sign-extend our 32-bit signed operands to
64-bit signed variables (only for 64-bit builds). To decide on whether
The 32-bit and 64-bit address encodings are identical. This means that we
can use the same function in both cases. In order to reuse the function for
32-bit address encodings, we must sign-extend our 32-bit signed operands to
64-bit signed variables (only for 64-bit builds). To decide on whether
The feature User-Mode Instruction Prevention present in recent Intel
processor prevents a group of instructions from being executed with
CPL > 0. Otherwise, a general protection fault is issued.
Rather than relaying this fault to the user space (in the form of a SIGSEGV
signal), the instructions
The feature User-Mode Instruction Prevention present in recent Intel
processor prevents a group of instructions from being executed with
CPL > 0. Otherwise, a general protection fault is issued.
Rather than relaying this fault to the user space (in the form of a SIGSEGV
signal), the instructions
fixup_umip_exception will be called from do_general_protection. If the
former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV.
However, when emulation is successful but the emulated result cannot be
copied to user space memory, it is more accurate to issue a SIGSEGV with
fixup_umip_exception will be called from do_general_protection. If the
former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV.
However, when emulation is successful but the emulated result cannot be
copied to user space memory, it is more accurate to issue a SIGSEGV with
If the User-Mode Instruction Prevention CPU feature is available and
enabled, a general protection fault will be issued if the instructions
sgdt, sldt, sidt, str or smsw are executed from user-mode context
(CPL > 0). If the fault was caused by any of the instructions protected
by UMIP,
If the User-Mode Instruction Prevention CPU feature is available and
enabled, a general protection fault will be issued if the instructions
sgdt, sldt, sidt, str or smsw are executed from user-mode context
(CPL > 0). If the fault was caused by any of the instructions protected
by UMIP,
Certain user space programs that run on virtual-8086 mode may utilize
instructions protected by the User-Mode Instruction Prevention (UMIP)
security feature present in new Intel processors: SGDT, SIDT and SMSW. In
such a case, a general protection fault is issued if UMIP is enabled. When
such a
The function insn_get_reg_offset takes as argument an enumeration that
indicates the type of offset that is returned: the R/M part of the ModRM
byte, the index of the SIB byte or the base of the SIB byte. Callers of
this function would need the definition of such enumeration. This is not
needed.
Certain user space programs that run on virtual-8086 mode may utilize
instructions protected by the User-Mode Instruction Prevention (UMIP)
security feature present in new Intel processors: SGDT, SIDT and SMSW. In
such a case, a general protection fault is issued if UMIP is enabled. When
such a
The function insn_get_reg_offset takes as argument an enumeration that
indicates the type of offset that is returned: the R/M part of the ModRM
byte, the index of the SIB byte or the base of the SIB byte. Callers of
this function would need the definition of such enumeration. This is not
needed.
When computing a linear address and segmentation is used, we need to know
the base address of the segment involved in the computation. In most of
the cases, the segment base address will be zero as in USER_DS/USER32_DS.
However, it may be possible that a user space program defines its own
segments
User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a
bit in %cr4.
It makes sense to enable UMIP at some point while booting, before user
spaces come up. Like SMAP and SMEP, is not critical to have it enabled
very early during boot. This is because UMIP is relevant only when
When computing a linear address and segmentation is used, we need to know
the base address of the segment involved in the computation. In most of
the cases, the segment base address will be zero as in USER_DS/USER32_DS.
However, it may be possible that a user space program defines its own
segments
User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a
bit in %cr4.
It makes sense to enable UMIP at some point while booting, before user
spaces come up. Like SMAP and SMEP, is not critical to have it enabled
very early during boot. This is because UMIP is relevant only when
Other kernel submodules can benefit from using the utility functions
defined in mpx.c to obtain the addresses and values of operands contained
in the general purpose registers. An instance of this is the emulation code
used for instructions protected by the Intel User-Mode Instruction
Prevention
Other kernel submodules can benefit from using the utility functions
defined in mpx.c to obtain the addresses and values of operands contained
in the general purpose registers. An instance of this is the emulation code
used for instructions protected by the Intel User-Mode Instruction
Prevention
Am 03.03.2017 um 07:20 schrieb Rob Herring:
> On Tue, Feb 28, 2017 at 12:39:08PM +, Mark Rutland wrote:
>> On Tue, Feb 28, 2017 at 07:35:13AM +0100, Andreas Färber wrote:
>>> The Actions Semi S500 SoC contains a timer block with two 2 Hz and two
>>> 32-bit timers. The S900 SoC timer block has
Am 03.03.2017 um 07:20 schrieb Rob Herring:
> On Tue, Feb 28, 2017 at 12:39:08PM +, Mark Rutland wrote:
>> On Tue, Feb 28, 2017 at 07:35:13AM +0100, Andreas Färber wrote:
>>> The Actions Semi S500 SoC contains a timer block with two 2 Hz and two
>>> 32-bit timers. The S900 SoC timer block has
ebied...@xmission.com (Eric W. Biederman) writes:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> The big lesson for me, and what was not obvious from your change
>> description is that we are changing the user space visible semantics
>> of exec+ptrace and that cred_guard_mutex is not at
ebied...@xmission.com (Eric W. Biederman) writes:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> The big lesson for me, and what was not obvious from your change
>> description is that we are changing the user space visible semantics
>> of exec+ptrace and that cred_guard_mutex is not at
On 3/3/2017 2:42 PM, Bjorn Helgaas wrote:
On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
From: Tom Lendacky
The use of ioremap will force the setup data to be mapped decrypted even
though setup data is encrypted. Switch to using memremap which will be
On 3/3/2017 2:42 PM, Bjorn Helgaas wrote:
On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
From: Tom Lendacky
The use of ioremap will force the setup data to be mapped decrypted even
though setup data is encrypted. Switch to using memremap which will be
able to perform the
On Sat, Feb 25, 2017 at 12:18 PM, Sarbojit Ganguly
wrote:
> On 25 February 2017 at 20:12, Srividya Desireddy
> wrote:
>> From: Srividya Desireddy
>> Date: Thu, 23 Feb 2017 15:04:06 +0530
>> Subject: [PATCH] zswap:
On Sat, Feb 25, 2017 at 12:18 PM, Sarbojit Ganguly
wrote:
> On 25 February 2017 at 20:12, Srividya Desireddy
> wrote:
>> From: Srividya Desireddy
>> Date: Thu, 23 Feb 2017 15:04:06 +0530
>> Subject: [PATCH] zswap: Zero-filled pages handling
your email is base64-encoded; please send plain text
On Fri, 2017-03-03 at 10:25 -0800, Eric Dumazet wrote:
> On Fri, Mar 3, 2017 at 10:10 AM, Dmitry Vyukov wrote:
> > Hello,
> >
> > The following program triggers division by 0 in tcp_select_window:
> >
> >
On Fri, 2017-03-03 at 10:25 -0800, Eric Dumazet wrote:
> On Fri, Mar 3, 2017 at 10:10 AM, Dmitry Vyukov wrote:
> > Hello,
> >
> > The following program triggers division by 0 in tcp_select_window:
> >
> >
On 2017-02-28 23:15, Steve Grubb wrote:
> On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote:
> > Sorry, I forgot to include Cc: in this cover letter for context to the 4
> > alt patches.
> >
> > On 2017-02-28 22:15, Richard Guy Briggs wrote:
> > > The background to this is:
>
On 2017-02-28 23:15, Steve Grubb wrote:
> On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote:
> > Sorry, I forgot to include Cc: in this cover letter for context to the 4
> > alt patches.
> >
> > On 2017-02-28 22:15, Richard Guy Briggs wrote:
> > > The background to this is:
>
Neil Armstrong writes:
> Hi Andreas,
> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>> Hi Neil,
>>
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>>
>> First of all, any reason you're upper-casing
Neil Armstrong writes:
> Hi Andreas,
> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>> Hi Neil,
>>
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>>
>> First of all, any reason you're upper-casing Mali in the commit
Hi!
Documentation/devicetree/bindings/regulator/regulator.txt says that the
regulator-name property is optional. However fixed and gpio regulators
fail in probe with the following message, if the property is not
present:
| reg-fixed-voltage regulators:sensor_supply: Failed to allocate supply
Hi!
Documentation/devicetree/bindings/regulator/regulator.txt says that the
regulator-name property is optional. However fixed and gpio regulators
fail in probe with the following message, if the property is not
present:
| reg-fixed-voltage regulators:sensor_supply: Failed to allocate supply
Change the maxium spi clock frequency from 20MHz to 10MHz to meet the operation
voltage range requirement recommended in AT25 datasheet
Signed-off-by: Ken Lin
---
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Change the maxium spi clock frequency from 20MHz to 10MHz to meet the operation
voltage range requirement recommended in AT25 datasheet
Signed-off-by: Ken Lin
---
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This fixes type warnings generated by sparse, replaces instances of
ntohs() with be16_to_cpu() and removes unused fields in structs.
Signed-off-by: Ernestas Kulik
---
drivers/staging/ks7010/ks7010_sdio.c | 12 ++--
drivers/staging/ks7010/ks_hostif.c | 30 +
This fixes type warnings generated by sparse, replaces instances of
ntohs() with be16_to_cpu() and removes unused fields in structs.
Signed-off-by: Ernestas Kulik
---
drivers/staging/ks7010/ks7010_sdio.c | 12 ++--
drivers/staging/ks7010/ks_hostif.c | 30 +
Hi Boris,
On 03/03/2017 10:59 AM, Borislav Petkov wrote:
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
From: Tom Lendacky
Update the CPU features to include identifying and reporting on the
Secure Encrypted Virtualization (SEV) feature. SME is
Hi Boris,
On 03/03/2017 10:59 AM, Borislav Petkov wrote:
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
From: Tom Lendacky
Update the CPU features to include identifying and reporting on the
Secure Encrypted Virtualization (SEV) feature. SME is identified by
CPUID
On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> > This RFC series provides support for AMD's new Secure Encrypted
> > Virtualization
> > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4
>
On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> > This RFC series provides support for AMD's new Secure Encrypted
> > Virtualization
> > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4
>
On Thu, Mar 2, 2017 at 7:00 AM, Hoeun Ryu wrote:
> +unsigned long __rare_write_rw_alias_start = TASK_SIZE_64 / 4;
> +
> +__always_inline unsigned long __arch_rare_write_map(void)
> +{
> + struct mm_struct *mm = _write_mm;
> +
> + preempt_disable();
> +
> +
On Thu, Mar 2, 2017 at 7:00 AM, Hoeun Ryu wrote:
> +unsigned long __rare_write_rw_alias_start = TASK_SIZE_64 / 4;
> +
> +__always_inline unsigned long __arch_rare_write_map(void)
> +{
> + struct mm_struct *mm = _write_mm;
> +
> + preempt_disable();
> +
> + __switch_mm(mm);
...
On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> The use of ioremap will force the setup data to be mapped decrypted even
> though setup data is encrypted. Switch to using memremap which will be
> able to perform the proper
On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> The use of ioremap will force the setup data to be mapped decrypted even
> though setup data is encrypted. Switch to using memremap which will be
> able to perform the proper mapping.
How should callers
On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote:
> This reset is required in order to fully reset the internal state of the
> MIPI controller.
>
> Signed-off-by: John Keeping
> ---
> On Thu, 2 Mar 2017 13:56:46 -0800, Brian Norris wrote:
> > On Fri, Feb 24, 2017
On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote:
> This reset is required in order to fully reset the internal state of the
> MIPI controller.
>
> Signed-off-by: John Keeping
> ---
> On Thu, 2 Mar 2017 13:56:46 -0800, Brian Norris wrote:
> > On Fri, Feb 24, 2017 at 12:55:06PM +,
Signed-off-by: Ryan Lee
---
Replaced 'pr_err' by 'dev_err'. Modified error message.
sound/soc/codecs/max98927.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
index
Signed-off-by: Ryan Lee
---
Replaced 'pr_err' by 'dev_err'. Modified error message.
sound/soc/codecs/max98927.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
index efc761b..0abf6d3 100755
---
Signed-off-by: Ryan Lee
---
Added the mask variable to apply in one round after the switch.
sound/soc/codecs/max98927.c | 64 ++---
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/sound/soc/codecs/max98927.c
Signed-off-by: Ryan Lee
---
Added the mask variable to apply in one round after the switch.
sound/soc/codecs/max98927.c | 64 ++---
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> This RFC series provides support for AMD's new Secure Encrypted Virtualization
> (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4
> [1].
What kernel version is this series based on?
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> This RFC series provides support for AMD's new Secure Encrypted Virtualization
> (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4
> [1].
What kernel version is this series based on?
201 - 300 of 1450 matches
Mail list logo