stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 101 passed with 18 offline, 1
conflict (v4.19.2-206-g857962e4c7ee)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.2-206-g857962e4c7ee/
Full Build Summary:
Hi Kees:
I want to listen to you.
--Yangtao
On Tue, Nov 20, 2018 at 8:49 AM Frank Lee wrote:
>
> Hi Dava:
>
> How about just change the ptdump_fops and ptdump_open?
>
> Yours,
> Yangtao
> On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
> >
> > On 11/19/18 7:43 AM, Yangtao Li wrote:
> >
stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 101 passed with 18 offline, 1
conflict (v4.19.2-206-g857962e4c7ee)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.2-206-g857962e4c7ee/
Full Build Summary:
Hi Kees:
I want to listen to you.
--Yangtao
On Tue, Nov 20, 2018 at 8:49 AM Frank Lee wrote:
>
> Hi Dava:
>
> How about just change the ptdump_fops and ptdump_open?
>
> Yours,
> Yangtao
> On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
> >
> > On 11/19/18 7:43 AM, Yangtao Li wrote:
> >
egulator_unlock" [drivers/regulator/da9210-regulator.ko] undefined!
ERROR: "regulator_lock" [drivers/regulator/da9210-regulator.ko] undefined!
Caused by commit
f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
I have used the regulator tree from next
Hi Dava:
How about just change the ptdump_fops and ptdump_open?
Yours,
Yangtao
On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
>
> On 11/19/18 7:43 AM, Yangtao Li wrote:
> > -static const struct file_operations ptdump_curusr_fops = {
> > - .owner = THIS_MODULE,
> > -
On Mon, Nov 19, 2018 at 4:28 PM Andy Lutomirski wrote:
>
> On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > These tools also care about ioctls. Adding a system call is a pain,
> > > but the solution is to make adding system calls less of a pain, not to
> > > permanently make the Linux
Hi Dava:
How about just change the ptdump_fops and ptdump_open?
Yours,
Yangtao
On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
>
> On 11/19/18 7:43 AM, Yangtao Li wrote:
> > -static const struct file_operations ptdump_curusr_fops = {
> > - .owner = THIS_MODULE,
> > -
On Mon, Nov 19, 2018 at 4:28 PM Andy Lutomirski wrote:
>
> On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > These tools also care about ioctls. Adding a system call is a pain,
> > > but the solution is to make adding system calls less of a pain, not to
> > > permanently make the Linux
egulator_unlock" [drivers/regulator/da9210-regulator.ko] undefined!
ERROR: "regulator_lock" [drivers/regulator/da9210-regulator.ko] undefined!
Caused by commit
f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
I have used the regulator tree from next
On 20.11.2018 3:26, Douglas Anderson wrote:
> In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
> regulators locking") disabling of the supply was moved into
> _regulator_disable(). That means regulator_disable_work() shouldn't
> be disabling since that double-disables the supply.
>
On 20.11.2018 3:26, Douglas Anderson wrote:
> In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
> regulators locking") disabling of the supply was moved into
> _regulator_disable(). That means regulator_disable_work() shouldn't
> be disabling since that double-disables the supply.
>
Hello,
Thank you for applying my patch and sorry for mistake...
On 2018年11月19日 22:43, Heiko Stuebner wrote:
Am Sonntag, 18. November 2018, 05:18:02 CET schrieb Katsuhiro Suzuki:
This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1
successfully.
Signed-off-by: Katsuhiro Suzuki
---
Hello,
Thank you for applying my patch and sorry for mistake...
On 2018年11月19日 22:43, Heiko Stuebner wrote:
Am Sonntag, 18. November 2018, 05:18:02 CET schrieb Katsuhiro Suzuki:
This patch fixes mistakes in HCLK_I2S1_8CH for running I2S1
successfully.
Signed-off-by: Katsuhiro Suzuki
---
On Mon, Nov 19, 2018 at 4:33 PM Christian Brauner wrote:
>
> On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote:
> > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > > These tools also care about ioctls. Adding a system call is a pain,
> > > > but the solution is to make
On Mon, Nov 19, 2018 at 4:33 PM Christian Brauner wrote:
>
> On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote:
> > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > > These tools also care about ioctls. Adding a system call is a pain,
> > > > but the solution is to make
On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > These tools also care about ioctls. Adding a system call is a pain,
> > > but the solution is to make adding system calls less of a pain, not to
> > > permanently make
On Mon, Nov 19, 2018 at 04:27:49PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > > These tools also care about ioctls. Adding a system call is a pain,
> > > but the solution is to make adding system calls less of a pain, not to
> > > permanently make
On 11/19/18 9:25 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.3 release.
There are 205 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 know.
Responses should be
On 11/19/18 9:25 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.3 release.
There are 205 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 know.
Responses should be
On Mon, 19 Nov 2018, Tim Chen wrote:
> On 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> > On Fri, 16 Nov 2018, Tim Chen wrote:
> >> The protection mode can be specified by the spectre_v2_app2app
> >> boot parameter with the following semantics:
> >>
> >> spectre_v2_app2app=
> >>off- Turn
On Mon, 19 Nov 2018, Tim Chen wrote:
> On 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> > On Fri, 16 Nov 2018, Tim Chen wrote:
> >> The protection mode can be specified by the spectre_v2_app2app
> >> boot parameter with the following semantics:
> >>
> >> spectre_v2_app2app=
> >>off- Turn
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooparation. I got your contact from a certain email database from your country
while i was looking for someone to handle a huge financial transaction for me
in confidence. Can you receive and invest on behalf
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooparation. I got your contact from a certain email database from your country
while i was looking for someone to handle a huge financial transaction for me
in confidence. Can you receive and invest on behalf
On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > These tools also care about ioctls. Adding a system call is a pain,
> > but the solution is to make adding system calls less of a pain, not to
> > permanently make the Linux ABI worse.
>
> For user-defined values of "worse" :)
>
I tend to
On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > These tools also care about ioctls. Adding a system call is a pain,
> > but the solution is to make adding system calls less of a pain, not to
> > permanently make the Linux ABI worse.
>
> For user-defined values of "worse" :)
>
I tend to
In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
regulators locking") disabling of the supply was moved into
_regulator_disable(). That means regulator_disable_work() shouldn't
be disabling since that double-disables the supply.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex
In the commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for
regulators locking") disabling of the supply was moved into
_regulator_disable(). That means regulator_disable_work() shouldn't
be disabling since that double-disables the supply.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex
When we called regulator_enable() on a regulator we'd end up
propagating that call all the way up the chain every time. This is a
bit of a waste of time. A child regulator already refcounts its own
enables so it should avoid passing on to its parent unless the
refcount transitioned between 0 and
Now that consumers all keep track of their own enable count, let's add
it into the regulator_summary.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index
In general when the consumer of a regulator requests that the
regulator be disabled it no longer will be drawing much load from the
regulator--it should just be the leakage current and that should be
very close to 0.
Up to this point the regulator framework has continued to count a
consumer's
In regulator_force_disable() there was a strange loop that looked like:
while (rdev->open_count--)
regulator_disable(rdev->supply);
I'm not totally sure what the goal was for this loop, but it seems
wrong to me. If anything I think maybe we should have been looping
over our use_count, but
When we called regulator_enable() on a regulator we'd end up
propagating that call all the way up the chain every time. This is a
bit of a waste of time. A child regulator already refcounts its own
enables so it should avoid passing on to its parent unless the
refcount transitioned between 0 and
Now that consumers all keep track of their own enable count, let's add
it into the regulator_summary.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index
In general when the consumer of a regulator requests that the
regulator be disabled it no longer will be drawing much load from the
regulator--it should just be the leakage current and that should be
very close to 0.
Up to this point the regulator framework has continued to count a
consumer's
In regulator_force_disable() there was a strange loop that looked like:
while (rdev->open_count--)
regulator_disable(rdev->supply);
I'm not totally sure what the goal was for this loop, but it seems
wrong to me. If anything I think maybe we should have been looping
over our use_count, but
At boot sometimes regulators (like qcom-rpmh-regulator) will return
-EINVAL if we don't know the enable state of the regulator. We
shouldn't take this to mean that the regulator is an always-on
regulator, but that was what was happening since "-EINVAL" is non-zero
and a few places in the code
The "requested_microamps" sysfs attribute was only being exposed for
"current" regulators. This didn't make sense. Allow it to be exposed
always.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/regulator/core.c
The "requested_microamps" sysfs attribute was only being exposed for
"current" regulators. This didn't make sense. Allow it to be exposed
always.
Signed-off-by: Douglas Anderson
---
drivers/regulator/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/regulator/core.c
At boot sometimes regulators (like qcom-rpmh-regulator) will return
-EINVAL if we don't know the enable state of the regulator. We
shouldn't take this to mean that the regulator is an always-on
regulator, but that was what was happening since "-EINVAL" is non-zero
and a few places in the code
On 11/19/18 9:26 AM, Greg Kroah-Hartman wrote:
--
NOTE, this is going to be the last 4.18.y release. After this one it is
end-of-life, please move to 4.19.y at this point in time.
--
This is the start of the stable review cycle for the 4.18.20 release.
There are
On 11/19/18 9:26 AM, Greg Kroah-Hartman wrote:
--
NOTE, this is going to be the last 4.18.y release. After this one it is
end-of-life, please move to 4.19.y at this point in time.
--
This is the start of the stable review cycle for the 4.18.20 release.
There are
On 11/19/2018 04:00 PM, Thomas Gleixner wrote:
> On Tue, 20 Nov 2018, Jiri Kosina wrote:
>
>> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>>
>>> What? IBPB makes tons of sense even without STIBP.
>>
>> On non-SMT, yes. But this patchset ties those two the other (sensible) way
>> around AFAICS
On 11/19/2018 04:00 PM, Thomas Gleixner wrote:
> On Tue, 20 Nov 2018, Jiri Kosina wrote:
>
>> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>>
>>> What? IBPB makes tons of sense even without STIBP.
>>
>> On non-SMT, yes. But this patchset ties those two the other (sensible) way
>> around AFAICS
On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> wrote:
> ...
> >
> > A number of us have talked about this in the plumbers Android track, and
> > a different proposal for how to solve this has been made that should be
> >
On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> wrote:
> ...
> >
> > A number of us have talked about this in the plumbers Android track, and
> > a different proposal for how to solve this has been made that should be
> >
Hi all-
We currently have some giant turds in the way that syscalls are
numbered. We have the x86_32 table, which is totally sane other than
some legacy multiplexers. Then we have the x86_64 table, which is,
um, demented:
- The numbers don't match x86_32. I have no idea why.
- We use bit
Hi all-
We currently have some giant turds in the way that syscalls are
numbered. We have the x86_32 table, which is totally sane other than
some legacy multiplexers. Then we have the x86_64 table, which is,
um, demented:
- The numbers don't match x86_32. I have no idea why.
- We use bit
On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
> On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> > Here's the current description:
> >
> > > Setting ... STIBP ... on a logical processor prevents the predicted
> > > targets of indirect branches on any logical processor of that core
>
On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
> On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> > Here's the current description:
> >
> > > Setting ... STIBP ... on a logical processor prevents the predicted
> > > targets of indirect branches on any logical processor of that core
>
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.82 release.
There are 124 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 know.
Responses should be
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.82 release.
There are 124 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 know.
Responses should be
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.138 release.
There are 83 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 know.
Responses should be
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since [PATCH 10/13 v2]
arch/nds32/include/asm/syscall.h | 8
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.138 release.
There are 83 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 know.
Responses should be
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since [PATCH 10/13 v2]
arch/nds32/include/asm/syscall.h | 8
The uapi/linux/audit.h header is going to use EM_NDS32 in order
to define AUDIT_ARCH_NDS32 which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
The value for EM_NDS32 has been taken from
The uapi/linux/audit.h header is going to use EM_NDS32 in order
to define AUDIT_ARCH_NDS32 which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
The value for EM_NDS32 has been taken from
The uapi/linux/audit.h header is going to use EM_XTENSA in order
to define AUDIT_ARCH_XTENSA which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
The value for EM_XTENSA has been taken from
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since v1
arch/m68k/include/asm/syscall.h | 12
1 file changed, 12 insertions(+)
The uapi/linux/audit.h header is going to use EM_XTENSA in order
to define AUDIT_ARCH_XTENSA which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
The value for EM_XTENSA has been taken from
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since v1
arch/m68k/include/asm/syscall.h | 12
1 file changed, 12 insertions(+)
This should never have been defined in the arch tree to begin with,
and now uapi/linux/audit.h header is going to use EM_UNICORE
in order to define AUDIT_ARCH_UNICORE which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with
These should never have been defined in the arch tree to begin with, and
now uapi/linux/audit.h header is going to use EM_ARCOMPACT and EM_ARCV2
in order to define AUDIT_ARCH_ARCOMPACT and AUDIT_ARCH_ARCV2 which are
needed to implement syscall_get_arch() which in turn is required to
extend the
This should never have been defined in the arch tree to begin with,
and now uapi/linux/audit.h header is going to use EM_HEXAGON
in order to define AUDIT_ARCH_HEXAGON which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with
This should never have been defined in the arch tree to begin with,
and now uapi/linux/audit.h header is going to use EM_UNICORE
in order to define AUDIT_ARCH_UNICORE which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with
These should never have been defined in the arch tree to begin with, and
now uapi/linux/audit.h header is going to use EM_ARCOMPACT and EM_ARCV2
in order to define AUDIT_ARCH_ARCOMPACT and AUDIT_ARCH_ARCV2 which are
needed to implement syscall_get_arch() which in turn is required to
extend the
This should never have been defined in the arch tree to begin with,
and now uapi/linux/audit.h header is going to use EM_HEXAGON
in order to define AUDIT_ARCH_HEXAGON which is needed to implement
syscall_get_arch() which in turn is required to extend
the generic ptrace API with
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.164 release.
There are 160 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 know.
Responses should be
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.164 release.
There are 160 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 know.
Responses should be
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.126 release.
There are 90 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 know.
Responses should be
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.126 release.
There are 90 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 know.
Responses should be
On 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> Tim,
>
> On Fri, 16 Nov 2018, Tim Chen wrote:
>
>> Add new protection modes for Spectre v2 mitigations against
>> Spectre v2 attacks on user processes. There are three modes:
>>
>> strict mode:
>> In this mode, IBPB and STIBP are
On 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> Tim,
>
> On Fri, 16 Nov 2018, Tim Chen wrote:
>
>> Add new protection modes for Spectre v2 mitigations against
>> Spectre v2 attacks on user processes. There are three modes:
>>
>> strict mode:
>> In this mode, IBPB and STIBP are
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Dave Hansen wrote:
>
> > > What? IBPB makes tons of sense even without STIBP.
> >
> > I'm lost. :)
> >
> > I don't think anyone is talking about using STIBP *everywhere* that IBPB
> > is in-use.
> >
> > We're just guessing that, if
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Dave Hansen wrote:
>
> > > What? IBPB makes tons of sense even without STIBP.
> >
> > I'm lost. :)
> >
> > I don't think anyone is talking about using STIBP *everywhere* that IBPB
> > is in-use.
> >
> > We're just guessing that, if
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>
> > What? IBPB makes tons of sense even without STIBP.
>
> On non-SMT, yes. But this patchset ties those two the other (sensible) way
> around AFAICS ("STIBP iff (IBPB && SMT)").
Errm. No.
The patches
On Tue, 20 Nov 2018, Jiri Kosina wrote:
> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>
> > What? IBPB makes tons of sense even without STIBP.
>
> On non-SMT, yes. But this patchset ties those two the other (sensible) way
> around AFAICS ("STIBP iff (IBPB && SMT)").
Errm. No.
The patches
Hi1
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned
> int order, int preferred_nid,
> gfp_t alloc_mask; /* The gfp_t that was actually used for
> allocation */
> struct
Hi1
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned
> int order, int preferred_nid,
> gfp_t alloc_mask; /* The gfp_t that was actually used for
> allocation */
> struct
Hi!
> Some of Huawei laptops come with a LED in the micmute key. This patch
> enables and disable this LED accordingly.
>
> Signed-off-by: Ayman Bagabas
NAK.
We already have a LED subsystem.
> +#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP)
> +#include
> +
> +static int
Hi!
> Some of Huawei laptops come with a LED in the micmute key. This patch
> enables and disable this LED accordingly.
>
> Signed-off-by: Ayman Bagabas
NAK.
We already have a LED subsystem.
> +#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP)
> +#include
> +
> +static int
On Mon, 19 Nov 2018, Dave Hansen wrote:
> > What? IBPB makes tons of sense even without STIBP.
>
> I'm lost. :)
>
> I don't think anyone is talking about using STIBP *everywhere* that IBPB
> is in-use.
>
> We're just guessing that, if anybody is paranoid enough to ask for IBPB,
> *and* they
On Mon, 19 Nov 2018, Dave Hansen wrote:
> > What? IBPB makes tons of sense even without STIBP.
>
> I'm lost. :)
>
> I don't think anyone is talking about using STIBP *everywhere* that IBPB
> is in-use.
>
> We're just guessing that, if anybody is paranoid enough to ask for IBPB,
> *and* they
On Mon, Nov 19, 2018 at 3:43 PM Dave Hansen wrote:
>
> On 11/19/18 3:19 PM, Dan Williams wrote:
> > Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
> > and Dave confirmed the expectation for TLB flush is for modifying /
> > invalidating existing pte entries, but not
On Mon, Nov 19, 2018 at 3:43 PM Dave Hansen wrote:
>
> On 11/19/18 3:19 PM, Dan Williams wrote:
> > Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
> > and Dave confirmed the expectation for TLB flush is for modifying /
> > invalidating existing pte entries, but not
On Mon, Nov 19, 2018 at 11:31:21AM -0800, Randy Dunlap wrote:
>
> Yes, all of that.
> Having some kind of pstore on x86 would be wonderful.
>
> kexec/kdump used to be an option also. I haven't tried it lately.
Sure, but kexec/kdump won't work to debug a boot failure during early
boot. You
On Mon, Nov 19, 2018 at 11:31:21AM -0800, Randy Dunlap wrote:
>
> Yes, all of that.
> Having some kind of pstore on x86 would be wonderful.
>
> kexec/kdump used to be an option also. I haven't tried it lately.
Sure, but kexec/kdump won't work to debug a boot failure during early
boot. You
On Tue, Nov 20, 2018 at 07:37:58AM +0800, kbuild test robot wrote:
> Hi Christian,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181119]
> [if your patch
On Mon, Nov 19, 2018 at 03:25:41PM -0800, Dave Hansen wrote:
> On 11/19/18 3:16 PM, Andrea Arcangeli wrote:
> > So you may want to ask why it wasn't written as your "any" vs "any" email:
>
> Presumably because the authors really and truly meant what they said. I
> was not being as careful in my
On Tue, Nov 20, 2018 at 07:37:58AM +0800, kbuild test robot wrote:
> Hi Christian,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181119]
> [if your patch
On Mon, Nov 19, 2018 at 03:25:41PM -0800, Dave Hansen wrote:
> On 11/19/18 3:16 PM, Andrea Arcangeli wrote:
> > So you may want to ask why it wasn't written as your "any" vs "any" email:
>
> Presumably because the authors really and truly meant what they said. I
> was not being as careful in my
On 11/19/18 3:19 PM, Dan Williams wrote:
> Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
> and Dave confirmed the expectation for TLB flush is for modifying /
> invalidating existing pte entries, but not initial population [2].
I _think_ this is OK.
But, could we
On 11/19/18 3:19 PM, Dan Williams wrote:
> Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
> and Dave confirmed the expectation for TLB flush is for modifying /
> invalidating existing pte entries, but not initial population [2].
I _think_ this is OK.
But, could we
Hi Christian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Hi Christian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On 11/19/18 3:01 PM, Thomas Gleixner wrote:
>> Yes, it wouldn't make sense for having just one of those if a task
>> is worried about attack from user space.
>>
>> I'll document it.
> What? IBPB makes tons of sense even without STIBP.
I'm lost. :)
I don't think anyone is talking about using
On 11/19/18 3:01 PM, Thomas Gleixner wrote:
>> Yes, it wouldn't make sense for having just one of those if a task
>> is worried about attack from user space.
>>
>> I'll document it.
> What? IBPB makes tons of sense even without STIBP.
I'm lost. :)
I don't think anyone is talking about using
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
201 - 300 of 3448 matches
Mail list logo
