Quoting Nishanth Menon (2018-08-27 17:50:56)
> K3_ARCH uses TISCI for clocks as well. Enable the same
> for the driver support.
>
> Signed-off-by: Nishanth Menon
> ---
Applied to clk-next
Quoting Nishanth Menon (2018-08-27 17:50:56)
> K3_ARCH uses TISCI for clocks as well. Enable the same
> for the driver support.
>
> Signed-off-by: Nishanth Menon
> ---
Applied to clk-next
On Tue, Oct 2, 2018 at 8:37 PM Leonard Crestez wrote:
> This issue was exposed by commit efdfeb079cc3 ("regulator: fixed:
> Convert to use GPIO descriptor only") which causes the "gpios" property
> to also be parsed. Before that commit the "gpios" property had no
> effect and PHY reset was only
On Tue, Oct 2, 2018 at 8:37 PM Leonard Crestez wrote:
> This issue was exposed by commit efdfeb079cc3 ("regulator: fixed:
> Convert to use GPIO descriptor only") which causes the "gpios" property
> to also be parsed. Before that commit the "gpios" property had no
> effect and PHY reset was only
On Tue, 2 Oct 2018, Nikola Ciprich wrote:
> RHEL / centos 6:
>
> gcc-4.4.7
>
> will check newer kernels too..
We upped the gcc minimal version in newer kernels to 4.6, so 4.4 wont work
at all.
Thanks,
tglx
On Tue, 2 Oct 2018, Nikola Ciprich wrote:
> RHEL / centos 6:
>
> gcc-4.4.7
>
> will check newer kernels too..
We upped the gcc minimal version in newer kernels to 4.6, so 4.4 wont work
at all.
Thanks,
tglx
On Tue, 02 Oct 2018 12:14:53 PDT (-0700), atish.pa...@wdc.com wrote:
This patch series now has evolved to contain several related changes.
1. Updated the assorted cleanup series by palmer.
The original cleanup patch series can be found here.
On Tue, 02 Oct 2018 12:14:53 PDT (-0700), atish.pa...@wdc.com wrote:
This patch series now has evolved to contain several related changes.
1. Updated the assorted cleanup series by palmer.
The original cleanup patch series can be found here.
+Andy for opinions on things in write handlers
+Mimi Zohar as EVM maintainer
On Tue, Oct 2, 2018 at 9:55 AM joeyli wrote:
> On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi
> > wrote:
> > > This patch adds a snapshot keys handler for
+Andy for opinions on things in write handlers
+Mimi Zohar as EVM maintainer
On Tue, Oct 2, 2018 at 9:55 AM joeyli wrote:
> On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote:
> > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi
> > wrote:
> > > This patch adds a snapshot keys handler for
On Tue 25 Sep 10:29 PDT 2018, Brian Norris wrote:
> Hi Bjorn,
>
> On Tue, Sep 25, 2018 at 01:06:07AM -0700, Bjorn Andersson wrote:
> > rmtfs_mem provides access to physical storage and is crucial for the
> > operation of the Qualcomm modem subsystem.
> >
> > The rmtfs_mem implementation must be
On Tue 25 Sep 10:29 PDT 2018, Brian Norris wrote:
> Hi Bjorn,
>
> On Tue, Sep 25, 2018 at 01:06:07AM -0700, Bjorn Andersson wrote:
> > rmtfs_mem provides access to physical storage and is crucial for the
> > operation of the Qualcomm modem subsystem.
> >
> > The rmtfs_mem implementation must be
Commit-ID: 2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Gitweb: https://git.kernel.org/tip/2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Author: Mike Travis
AuthorDate: Tue, 2 Oct 2018 13:01:46 -0500
Committer: Thomas Gleixner
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200
x86/tsc: Fix UV TSC
Commit-ID: 2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Gitweb: https://git.kernel.org/tip/2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Author: Mike Travis
AuthorDate: Tue, 2 Oct 2018 13:01:46 -0500
Committer: Thomas Gleixner
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200
x86/tsc: Fix UV TSC
Commit-ID: 20a8378aa9dd108a01cb0e695599f5257a885c4b
Gitweb: https://git.kernel.org/tip/20a8378aa9dd108a01cb0e695599f5257a885c4b
Author: Mike Travis
AuthorDate: Tue, 2 Oct 2018 13:01:45 -0500
Committer: Thomas Gleixner
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200
x86/platform/uv: Provide
Commit-ID: 20a8378aa9dd108a01cb0e695599f5257a885c4b
Gitweb: https://git.kernel.org/tip/20a8378aa9dd108a01cb0e695599f5257a885c4b
Author: Mike Travis
AuthorDate: Tue, 2 Oct 2018 13:01:45 -0500
Committer: Thomas Gleixner
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200
x86/platform/uv: Provide
Hi Steve,
- Original Message -
> From: "Steve French"
> To: rfre...@redhat.com
> Cc: "LKML" , "Steve French"
> , "CIFS" , "Pavel Shilovsky"
>
> Sent: Tuesday, October 2, 2018 4:17:02 PM
> Subject: Re: [PATCH v2] CIFS: Print message when attempting a mount
>
> Are you sure that these
Hi Steve,
- Original Message -
> From: "Steve French"
> To: rfre...@redhat.com
> Cc: "LKML" , "Steve French"
> , "CIFS" , "Pavel Shilovsky"
>
> Sent: Tuesday, October 2, 2018 4:17:02 PM
> Subject: Re: [PATCH v2] CIFS: Print message when attempting a mount
>
> Are you sure that these
Hi Babu,
On 9/24/2018 12:19 PM, Moger, Babu wrote:
> Re-organize the RDT init code. Separate the call sequence for each
> feature. That way, it is easy to call quirks or features separately
> for each vendor if there are differences.
>
> Signed-off-by: Babu Moger
> ---
>
Hi Babu,
On 9/24/2018 12:19 PM, Moger, Babu wrote:
> Re-organize the RDT init code. Separate the call sequence for each
> feature. That way, it is easy to call quirks or features separately
> for each vendor if there are differences.
>
> Signed-off-by: Babu Moger
> ---
>
On Tue, 2 Oct 2018, Dave Chinner wrote:
> On Tue, Oct 02, 2018 at 06:08:16AM +1000, James Morris wrote:
> > On Mon, 1 Oct 2018, Darrick J. Wong wrote:
> >
> > > If we /did/ replace CAP_SYS_ADMIN checking with a pile of LSM hooks,
> >
> > Not sure we'd need a pile of hooks, what about just
On Tue, 2 Oct 2018, Dave Chinner wrote:
> On Tue, Oct 02, 2018 at 06:08:16AM +1000, James Morris wrote:
> > On Mon, 1 Oct 2018, Darrick J. Wong wrote:
> >
> > > If we /did/ replace CAP_SYS_ADMIN checking with a pile of LSM hooks,
> >
> > Not sure we'd need a pile of hooks, what about just
On Tue, Oct 02, 2018 at 06:23:21AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.74 release.
> There are 137 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, Oct 02, 2018 at 06:23:21AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.74 release.
> There are 137 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, Oct 02, 2018 at 06:24:14AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.131 release.
> There are 94 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, Oct 02, 2018 at 06:24:14AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.131 release.
> There are 94 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Explicit clock enabling is required on 6sll and 6ull so mention that
standard clock bindings are used.
Signed-off-by: Leonard Crestez
---
Documentation/devicetree/bindings/crypto/fsl-dcp.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
Explicit clock enabling is required on 6sll and 6ull so mention that
standard clock bindings are used.
Signed-off-by: Leonard Crestez
---
Documentation/devicetree/bindings/crypto/fsl-dcp.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
On 6ull and 6sll the DCP block has a clock which needs to be explicitly
enabled.
Add minimal handling for this at probe/remove time.
Signed-off-by: Leonard Crestez
---
drivers/crypto/mxs-dcp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/crypto/mxs-dcp.c
The only important difference relative to 6sl is that explicit clock
enabling is required.
The driver currently doesn't even probe on 6sl, a separate series was
posted to deal with the crypto functionality, those might take a while:
https://lkml.org/lkml/2018/10/2/1355
Since the functionality
On 6ull and 6sll the DCP block has a clock which needs to be explicitly
enabled.
Add minimal handling for this at probe/remove time.
Signed-off-by: Leonard Crestez
---
drivers/crypto/mxs-dcp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/crypto/mxs-dcp.c
The only important difference relative to 6sl is that explicit clock
enabling is required.
The driver currently doesn't even probe on 6sl, a separate series was
posted to deal with the crypto functionality, those might take a while:
https://lkml.org/lkml/2018/10/2/1355
Since the functionality
The DCP block on 6ull has no major differences other than requiring
explicit clock enabling.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6ull.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index
The DCP block on 6ull has no major differences other than requiring
explicit clock enabling.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6ull.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index
On 10/1/18 8:29 PM, Anup Patel wrote:
On Tue, Oct 2, 2018 at 8:45 AM Atish Patra wrote:
On 9/28/18 11:26 PM, Anup Patel wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
On 10/1/18 8:29 PM, Anup Patel wrote:
On Tue, Oct 2, 2018 at 8:45 AM Atish Patra wrote:
On 9/28/18 11:26 PM, Anup Patel wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
On 10/1/18 9:42 AM, Palmer Dabbelt wrote:
On Fri, 28 Sep 2018 23:26:05 PDT (-0700), a...@brainfault.org wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0
On 10/1/18 9:42 AM, Palmer Dabbelt wrote:
On Fri, 28 Sep 2018 23:26:05 PDT (-0700), a...@brainfault.org wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0
Are you sure that these aren't logged by the automounter (for ext4,
xfs etc.). When I looked in my dmesg logs I didn't find matching log
entries in the file systems themselves. Do you have an example?
On the idea of adding cifsFYI logging here - I slightly prefer using
ftrace (trace-cmd, ie
On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
wrote:
> Under the current scheme
>
> lsm.enabled=selinux
>
> could actually mean selinux,yama,loadpin,something_else are
> enabled. If we extend this behavior to when full stacking lands
>
> lsm.enabled=selinux,yama
>
> might mean
Are you sure that these aren't logged by the automounter (for ext4,
xfs etc.). When I looked in my dmesg logs I didn't find matching log
entries in the file systems themselves. Do you have an example?
On the idea of adding cifsFYI logging here - I slightly prefer using
ftrace (trace-cmd, ie
On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
wrote:
> Under the current scheme
>
> lsm.enabled=selinux
>
> could actually mean selinux,yama,loadpin,something_else are
> enabled. If we extend this behavior to when full stacking lands
>
> lsm.enabled=selinux,yama
>
> might mean
From: Palmer Dabbelt
We shouldn't be directly passing device tree values to userspace, both
because there could be mistakes in device trees and because the kernel
doesn't support arbitrary ISAs.
Signed-off-by: Palmer Dabbelt
[Atish: checkpatch fix and code comment formatting update]
On 10/02/2018 01:46 PM, Fenghua Yu wrote:
> On Tue, Oct 02, 2018 at 05:44:47PM +, Moger, Babu wrote:
>> Hi Fenghua,
>>
>>> -Original Message-
>>> From: Fenghua Yu
>>> Sent: Tuesday, October 2, 2018 12:07 PM
>>> On Mon, Sep 24, 2018 at 07:18:54PM +, Moger, Babu wrote:
The
This patch series now has evolved to contain several related changes.
1. Updated the assorted cleanup series by palmer.
The original cleanup patch series can be found here.
http://lists.infradead.org/pipermail/linux-riscv/2018-August/001232.html
2. Implemented decoupling linux logical CPU ids
This patch series now has evolved to contain several related changes.
1. Updated the assorted cleanup series by palmer.
The original cleanup patch series can be found here.
http://lists.infradead.org/pipermail/linux-riscv/2018-August/001232.html
2. Implemented decoupling linux logical CPU ids
From: Palmer Dabbelt
We shouldn't be directly passing device tree values to userspace, both
because there could be mistakes in device trees and because the kernel
doesn't support arbitrary ISAs.
Signed-off-by: Palmer Dabbelt
[Atish: checkpatch fix and code comment formatting update]
On 10/02/2018 01:46 PM, Fenghua Yu wrote:
> On Tue, Oct 02, 2018 at 05:44:47PM +, Moger, Babu wrote:
>> Hi Fenghua,
>>
>>> -Original Message-
>>> From: Fenghua Yu
>>> Sent: Tuesday, October 2, 2018 12:07 PM
>>> On Mon, Sep 24, 2018 at 07:18:54PM +, Moger, Babu wrote:
The
From: Palmer Dabbelt
These are just hard coded in the RISC-V port, which doesn't make any
sense. We should probably be setting these from device tree entries
when they exist, but for now I think it's saner to just leave them all
as their default values.
Signed-off-by: Palmer Dabbelt
From: Palmer Dabbelt
This isn't readily apparent from reading the code.
Signed-off-by: Palmer Dabbelt
[Atish: code comment formatting update]
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/smpboot.c | 4
1 file changed, 4 insertions(+)
diff --git
From: Palmer Dabbelt
This isn't readily apparent from reading the code.
Signed-off-by: Palmer Dabbelt
[Atish: code comment formatting update]
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/smpboot.c | 4
1 file changed, 4 insertions(+)
diff --git
From: Palmer Dabbelt
These are just hard coded in the RISC-V port, which doesn't make any
sense. We should probably be setting these from device tree entries
when they exist, but for now I think it's saner to just leave them all
as their default values.
Signed-off-by: Palmer Dabbelt
From: Anup Patel
Currently, /proc/cpuinfo show logical CPU ID as Hart ID which
is in-correct. This patch shows CPU ID and Hart ID separately
in /proc/cpuinfo using cpuid_to_hardid_map().
With this patch, contents of /proc/cpuinfo looks as follows:
processor : 0
hart: 1
isa
From: Palmer Dabbelt
It's a bit confusing exactly what this function does: it actually
returns the hartid of an OF processor node, failing with -1 on invalid
nodes. I've changed the name to _hartid() in order to make that a bit
more clear, as well as adding a comment.
Signed-off-by: Palmer
From: Anup Patel
Currently, /proc/cpuinfo show logical CPU ID as Hart ID which
is in-correct. This patch shows CPU ID and Hart ID separately
in /proc/cpuinfo using cpuid_to_hardid_map().
With this patch, contents of /proc/cpuinfo looks as follows:
processor : 0
hart: 1
isa
From: Palmer Dabbelt
It's a bit confusing exactly what this function does: it actually
returns the hartid of an OF processor node, failing with -1 on invalid
nodes. I've changed the name to _hartid() in order to make that a bit
more clear, as well as adding a comment.
Signed-off-by: Palmer
From: Palmer Dabbelt
The old name was a bit odd.
Signed-off-by: Palmer Dabbelt
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/smpboot.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/smpboot.c
From: Palmer Dabbelt
The old name was a bit odd.
Signed-off-by: Palmer Dabbelt
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/smpboot.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/smpboot.c
From: Anup Patel
The scause is already part of pt_regs so no need to pass
scause as separate arg to do_IRQ().
Reviewed-by: Christoph Hellwig
Signed-off-by: Anup Patel
---
arch/riscv/kernel/entry.S | 1 -
arch/riscv/kernel/irq.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
From: Anup Patel
The scause is already part of pt_regs so no need to pass
scause as separate arg to do_IRQ().
Reviewed-by: Christoph Hellwig
Signed-off-by: Anup Patel
---
arch/riscv/kernel/entry.S | 1 -
arch/riscv/kernel/irq.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
From: Palmer Dabbelt
commit f1f1007644ff ("mm: add new mmgrab() helper") added a
helper that we missed out on.
Signed-off-by: Palmer Dabbelt
Reviewed-by: Christoph Hellwig
Signed-off-by: Atish Patra
---
arch/riscv/kernel/smpboot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Currently, both Linux CPU id and hart id are same.
This is not recommended as it will lead to discontinuous CPU
indexing in Linux. Moreover, kdump kernel will run from CPU0
which would be absent if we follow existing scheme.
Implement a logical mapping between Linux CPU id and hart
id to decouple
From: Anup Patel
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0 CPU1 CPU2 CPU3
8: 17 7 6 14 SiFive PLIC 8
The secondary harts spin on couple of per cpu variables until both of
these are non-zero so it's not necessary to have any ordering here.
However, WRITE_ONCE should be used to avoid tearing.
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/smpboot.c | 5 +++--
1
From: Palmer Dabbelt
commit f1f1007644ff ("mm: add new mmgrab() helper") added a
helper that we missed out on.
Signed-off-by: Palmer Dabbelt
Reviewed-by: Christoph Hellwig
Signed-off-by: Atish Patra
---
arch/riscv/kernel/smpboot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Currently, both Linux CPU id and hart id are same.
This is not recommended as it will lead to discontinuous CPU
indexing in Linux. Moreover, kdump kernel will run from CPU0
which would be absent if we follow existing scheme.
Implement a logical mapping between Linux CPU id and hart
id to decouple
From: Anup Patel
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0 CPU1 CPU2 CPU3
8: 17 7 6 14 SiFive PLIC 8
The secondary harts spin on couple of per cpu variables until both of
these are non-zero so it's not necessary to have any ordering here.
However, WRITE_ONCE should be used to avoid tearing.
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/smpboot.c | 5 +++--
1
Currently, irq is enabled before preemption disabling happens.
If the scheduler fired right here and cpu is scheduled then it
may blow up.
Signed-off-by: Palmer Dabbelt
[Atish: Commit text and code comment formatting update]
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
Setup the cpu_logical_map during boot. Moreover, every SBI call
and PLIC context are based on the physical hartid. Use the logical
CPU to hartid mapping to pass correct hartid to respective functions.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Christoph Hellwig
---
From: Palmer Dabbelt
I'm not sure how I managed to miss this the first time, but this is much
better.
Signed-off-by: Palmer Dabbelt
[Atish: code comment formatting and other fixes]
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/include/asm/smp.h | 14 --
Currently, irq is enabled before preemption disabling happens.
If the scheduler fired right here and cpu is scheduled then it
may blow up.
Signed-off-by: Palmer Dabbelt
[Atish: Commit text and code comment formatting update]
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
Setup the cpu_logical_map during boot. Moreover, every SBI call
and PLIC context are based on the physical hartid. Use the logical
CPU to hartid mapping to pass correct hartid to respective functions.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Christoph Hellwig
---
From: Palmer Dabbelt
I'm not sure how I managed to miss this the first time, but this is much
better.
Signed-off-by: Palmer Dabbelt
[Atish: code comment formatting and other fixes]
Signed-off-by: Atish Patra
Reviewed-by: Christoph Hellwig
---
arch/riscv/include/asm/smp.h | 14 --
On Tue, Oct 02, 2018 at 03:40:28PM +0100, Quentin Perret wrote:
> On Tuesday 02 Oct 2018 at 16:29:24 (+0200), Peter Zijlstra wrote:
> > On Tue, Oct 02, 2018 at 03:05:23PM +0100, Quentin Perret wrote:
> > > On Tuesday 02 Oct 2018 at 15:48:57 (+0200), Peter Zijlstra wrote:
> > > > +/**
> > > > + *
On Tue, Oct 02, 2018 at 03:40:28PM +0100, Quentin Perret wrote:
> On Tuesday 02 Oct 2018 at 16:29:24 (+0200), Peter Zijlstra wrote:
> > On Tue, Oct 02, 2018 at 03:05:23PM +0100, Quentin Perret wrote:
> > > On Tuesday 02 Oct 2018 at 15:48:57 (+0200), Peter Zijlstra wrote:
> > > > +/**
> > > > + *
On Tue, 25 Sep 2018, Tim Chen wrote:
> This patch provides an application property based spectre_v2
# git grep 'This patch' Documentation/process/
> protection with STIBP against attack from another app from
s/app/application/ please. This is not android.
> a sibling hyper-thread. For
On Tue, 25 Sep 2018, Tim Chen wrote:
> This patch provides an application property based spectre_v2
# git grep 'This patch' Documentation/process/
> protection with STIBP against attack from another app from
s/app/application/ please. This is not android.
> a sibling hyper-thread. For
Commit-ID: d2266bbfa9e3e32e3b642965088ca461bd24a94f
Gitweb: https://git.kernel.org/tip/d2266bbfa9e3e32e3b642965088ca461bd24a94f
Author: Feng Tang
AuthorDate: Wed, 3 Oct 2018 00:49:21 +0800
Committer: Borislav Petkov
CommitDate: Tue, 2 Oct 2018 21:02:47 +0200
x86/earlyprintk: Add a
Commit-ID: d2266bbfa9e3e32e3b642965088ca461bd24a94f
Gitweb: https://git.kernel.org/tip/d2266bbfa9e3e32e3b642965088ca461bd24a94f
Author: Feng Tang
AuthorDate: Wed, 3 Oct 2018 00:49:21 +0800
Committer: Borislav Petkov
CommitDate: Tue, 2 Oct 2018 21:02:47 +0200
x86/earlyprintk: Add a
On Tue, 25 Sep 2018, Tim Chen wrote:
> From: Thomas Lendacky
>
> We extend the app to app spectre v2 mitigation using STIBP
> to the AMD cpus. We need to take care of special
> cases for AMD cpu's update of SPEC_CTRL MSR to avoid double
> writing of MSRs from update to SSBD and STIBP.
According
On Tue, 25 Sep 2018, Tim Chen wrote:
> From: Thomas Lendacky
>
> We extend the app to app spectre v2 mitigation using STIBP
> to the AMD cpus. We need to take care of special
> cases for AMD cpu's update of SPEC_CTRL MSR to avoid double
> writing of MSRs from update to SSBD and STIBP.
According
Commit-ID: fa7948a6413c63128335aa871fade8df55ac61e2
Gitweb: https://git.kernel.org/tip/fa7948a6413c63128335aa871fade8df55ac61e2
Author: Feng Tang
AuthorDate: Wed, 3 Oct 2018 00:49:21 +0800
Committer: Borislav Petkov
CommitDate: Tue, 2 Oct 2018 20:40:27 +0200
x86/earlyprintk: Add a
Commit-ID: fa7948a6413c63128335aa871fade8df55ac61e2
Gitweb: https://git.kernel.org/tip/fa7948a6413c63128335aa871fade8df55ac61e2
Author: Feng Tang
AuthorDate: Wed, 3 Oct 2018 00:49:21 +0800
Committer: Borislav Petkov
CommitDate: Tue, 2 Oct 2018 20:40:27 +0200
x86/earlyprintk: Add a
On 10/02/2018 04:17 AM, Sudeep Holla wrote:
On Mon, Oct 01, 2018 at 04:49:32PM -0700, Saravana Kannan wrote:
On 09/26/2018 07:48 AM, Sudeep Holla wrote:
On Wed, Sep 26, 2018 at 05:42:15PM +0300, Georgi Djakov wrote:
Hi Rob,
Thanks for the comments!
On 09/25/2018 09:02 PM, Rob Herring
On 10/02/2018 04:17 AM, Sudeep Holla wrote:
On Mon, Oct 01, 2018 at 04:49:32PM -0700, Saravana Kannan wrote:
On 09/26/2018 07:48 AM, Sudeep Holla wrote:
On Wed, Sep 26, 2018 at 05:42:15PM +0300, Georgi Djakov wrote:
Hi Rob,
Thanks for the comments!
On 09/25/2018 09:02 PM, Rob Herring
* Peter Zijlstra wrote:
> On Tue, Oct 02, 2018 at 10:10:48AM -0400, Waiman Long wrote:
> > One alternative is to group it under CONFIG_DEBUG_LOCKDEP again. This
> > metric was originally under CONFIG_DEBUG_LOCKDEP, but was moved to
> > CONFIG_LOCKDEP when trying to make other lock debugging
* Peter Zijlstra wrote:
> On Tue, Oct 02, 2018 at 10:10:48AM -0400, Waiman Long wrote:
> > One alternative is to group it under CONFIG_DEBUG_LOCKDEP again. This
> > metric was originally under CONFIG_DEBUG_LOCKDEP, but was moved to
> > CONFIG_LOCKDEP when trying to make other lock debugging
On 10/02/2018 02:32 PM, Dan Murphy wrote:
> Pavel
>
> On 10/02/2018 02:56 AM, Pavel Machek wrote:
>> On Fri 2018-09-28 13:29:46, Dan Murphy wrote:
>>> From: Pavel Machek
>>>
>>> This adds backlight support for the following TI LMU
>>> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
>>>
On 10/02/2018 02:32 PM, Dan Murphy wrote:
> Pavel
>
> On 10/02/2018 02:56 AM, Pavel Machek wrote:
>> On Fri 2018-09-28 13:29:46, Dan Murphy wrote:
>>> From: Pavel Machek
>>>
>>> This adds backlight support for the following TI LMU
>>> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
>>>
On Tue, Oct 02, 2018 at 05:44:47PM +, Moger, Babu wrote:
> Hi Fenghua,
>
> > -Original Message-
> > From: Fenghua Yu
> > Sent: Tuesday, October 2, 2018 12:07 PM
> > On Mon, Sep 24, 2018 at 07:18:54PM +, Moger, Babu wrote:
> > > The public specification is still in works. Will add
On Tue, Oct 02, 2018 at 05:44:47PM +, Moger, Babu wrote:
> Hi Fenghua,
>
> > -Original Message-
> > From: Fenghua Yu
> > Sent: Tuesday, October 2, 2018 12:07 PM
> > On Mon, Sep 24, 2018 at 07:18:54PM +, Moger, Babu wrote:
> > > The public specification is still in works. Will add
Hi,
On Mon, Oct 1, 2018 at 6:32 PM Ryan Case wrote:
> +#include
Don't need unaligned.h any more do you?
> +#define RD_FIFO_CFG0x0028
> +#define CONTINUOUS_MODEBIT(0)
> +
> +#define RD_FIFO_RESET 0x0030
> +#define RESET_FIFO BIT(0)
> +
>
Hi,
On Mon, Oct 1, 2018 at 6:32 PM Ryan Case wrote:
> +#include
Don't need unaligned.h any more do you?
> +#define RD_FIFO_CFG0x0028
> +#define CONTINUOUS_MODEBIT(0)
> +
> +#define RD_FIFO_RESET 0x0030
> +#define RESET_FIFO BIT(0)
> +
>
On Tue, Oct 02, 2018 at 08:38:41PM +0200, Miguel Ojeda wrote:
> Hi Greg,
>
> On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
> >
> > On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wrote:
> > > Hey Greg,
> > >
> > > Here are the SoundWire updates (again) for 4.20-rc1/5.0-rc1
> > > This brings in
On Tue, Oct 02, 2018 at 08:38:41PM +0200, Miguel Ojeda wrote:
> Hi Greg,
>
> On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
> >
> > On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wrote:
> > > Hey Greg,
> > >
> > > Here are the SoundWire updates (again) for 4.20-rc1/5.0-rc1
> > > This brings in
Hi Greg,
On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
>
> On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wrote:
> > Hey Greg,
> >
> > Here are the SoundWire updates (again) for 4.20-rc1/5.0-rc1
> > This brings in the multi-link streaming support and rst format
> > corrections. The changes are
Hi Greg,
On Tue, Oct 2, 2018 at 8:20 PM Greg KH wrote:
>
> On Tue, Oct 02, 2018 at 07:53:27PM +0530, Vinod wrote:
> > Hey Greg,
> >
> > Here are the SoundWire updates (again) for 4.20-rc1/5.0-rc1
> > This brings in the multi-link streaming support and rst format
> > corrections. The changes are
Bindings for "fixed-regulator" only explicitly support "gpio" property,
not "gpios". Fix by correcting the property name.
The enet PHYs on imx6sx-sdb needs to be explicitly reset after a power
cycle, handle this by adding the phy-reset-gpios property.
Both phys share a single reset, a scenario
Bindings for "fixed-regulator" only explicitly support "gpio" property,
not "gpios". Fix by correcting the property name.
The enet PHYs on imx6sx-sdb needs to be explicitly reset after a power
cycle, handle this by adding the phy-reset-gpios property.
Both phys share a single reset, a scenario
401 - 500 of 2384 matches
Mail list logo
