On 8 September 2018 at 02:39, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.4.155 release.
> There are 47 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.
>
>
On 8 September 2018 at 02:39, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.4.155 release.
> There are 47 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.
>
>
On 8 September 2018 at 02:39, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.9.126 release.
> There are 63 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.
>
>
On 8 September 2018 at 02:39, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.9.126 release.
> There are 63 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.
>
>
On 8 September 2018 at 02:38, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.14.69 release.
> There are 89 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.
>
>
On 8 September 2018 at 02:38, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.14.69 release.
> There are 89 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.
>
>
On 8 September 2018 at 02:37, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.18.7 release.
> There are 145 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.
>
>
On 8 September 2018 at 02:37, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.18.7 release.
> There are 145 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.
>
>
On Sat, Sep 08, 2018 at 04:28:09PM +0200, Arnd Bergmann wrote:
> The SNDCTL_* and SOUND_* commands are the old OSS user interface.
>
> I checked all the sound ioctl commands listed in fs/compat_ioctl.c
> to see if we still need the translation handlers. Here is what I
> found:
>
> - sound/oss/
On Sat, Sep 08, 2018 at 04:28:09PM +0200, Arnd Bergmann wrote:
> The SNDCTL_* and SOUND_* commands are the old OSS user interface.
>
> I checked all the sound ioctl commands listed in fs/compat_ioctl.c
> to see if we still need the translation handlers. Here is what I
> found:
>
> - sound/oss/
On Sat, Sep 08, 2018 at 04:28:12PM +0200, Arnd Bergmann wrote:
> These are all handled by the random driver, so instead of listing
> each ioctl, we can just use the same function to deal with both
> native and compat commands.
Umm... I don't think it's right -
> .unlocked_ioctl =
On Sat, Sep 08, 2018 at 04:28:12PM +0200, Arnd Bergmann wrote:
> These are all handled by the random driver, so instead of listing
> each ioctl, we can just use the same function to deal with both
> native and compat commands.
Umm... I don't think it's right -
> .unlocked_ioctl =
On 09/05/2018 10:01 AM, Linus Torvalds wrote:
On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote:
On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote:
---
[ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s!
[kworker/5:1:155]
[ 9990.762601] RIP:
On 09/05/2018 10:01 AM, Linus Torvalds wrote:
On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote:
On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote:
---
[ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s!
[kworker/5:1:155]
[ 9990.762601] RIP:
Greg,
On Fri, Sep 7, 2018 at 6:41 PM Greg Kroah-Hartman
wrote:
>
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Jann Horn
>
> commit 5820f140edef111a9ea2ef414ab2428b8cb805b1 upstream.
>
> The old code would hold the
Greg,
On Fri, Sep 7, 2018 at 6:41 PM Greg Kroah-Hartman
wrote:
>
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Jann Horn
>
> commit 5820f140edef111a9ea2ef414ab2428b8cb805b1 upstream.
>
> The old code would hold the
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> In order to properly support hierarchical resources control, the cgroup
> delegation model requires that attribute writes from a child group never
> fail but still are (potentially) constrained based on parent's assigned
> resources. This
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> In order to properly support hierarchical resources control, the cgroup
> delegation model requires that attribute writes from a child group never
> fail but still are (potentially) constrained based on parent's assigned
> resources. This
On Thu, Aug 30, 2018 at 01:20:05PM +0800, Anson Huang wrote:
> Update i.MX6ULL iomux header according to latest reference
> manual Rev.1, 11/2017.
>
> Signed-off-by: Anson Huang
Applied, thanks.
On Thu, Aug 30, 2018 at 01:20:05PM +0800, Anson Huang wrote:
> Update i.MX6ULL iomux header according to latest reference
> manual Rev.1, 11/2017.
>
> Signed-off-by: Anson Huang
Applied, thanks.
On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote:
> On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote:
>
> > Can you ACK on those two regulator patches, so that I can queue this
> > series up on IMX tree?
>
> I was expecting to get a pull request with the precursor patches in
On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote:
> On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote:
>
> > Can you ACK on those two regulator patches, so that I can queue this
> > series up on IMX tree?
>
> I was expecting to get a pull request with the precursor patches in
syzbot has found a reproducer for the following crash on:
HEAD commit:d7b686ebf704 Merge branch 'i2c/for-current' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148ac14940
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:d7b686ebf704 Merge branch 'i2c/for-current' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148ac14940
kernel config:
Hi,
On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add ZynqMP firmware IOCTL API to control and configure
> devices like PLLs, SD, Gem, etc.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
This patch worries me somewhat. It's a transparent pass-through
Hi,
On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add ZynqMP firmware IOCTL API to control and configure
> devices like PLLs, SD, Gem, etc.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
This patch worries me somewhat. It's a transparent pass-through
Hi,
I noticed the below when I was reviewing the code for merge into
arm-soc. Would you mind following up with an incremental patch? I
don't think we need to ask Michal to respin for this:
On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add debugfs file to query
Hi,
I noticed the below when I was reviewing the code for merge into
arm-soc. Would you mind following up with an incremental patch? I
don't think we need to ask Michal to respin for this:
On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add debugfs file to query
Hi Patrick!
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> Utilization clamping requires each CPU to know which clamp values are
> assigned to tasks that are currently RUNNABLE on that CPU.
> Multiple tasks can be assigned the same clamp value and tasks with
> different clamp values
Hi Patrick!
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> Utilization clamping requires each CPU to know which clamp values are
> assigned to tasks that are currently RUNNABLE on that CPU.
> Multiple tasks can be assigned the same clamp value and tasks with
> different clamp values
Currently, "disable_clkrun" yenta_socket module parameter is only
implemented for TI CardBus bridges.
Add also an implementation for Ricoh bridges that have the necessary
setting documented in publicly available datasheets.
Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
Currently, "disable_clkrun" yenta_socket module parameter is only
implemented for TI CardBus bridges.
Add also an implementation for Ricoh bridges that have the necessary
setting documented in publicly available datasheets.
Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone
and noinline on __naked functions") added noinline and noclone
as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0.
Since now the minimum gcc supported version is 4.6,
we can clean it up.
See
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone
and noinline on __naked functions") added noinline and noclone
as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0.
Since now the minimum gcc supported version is 4.6,
we can clean it up.
See
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Different definitions of __must_be_array:
* gcc: disabled for __CHECKER__
* clang: same definition as gcc's, but without __CHECKER__
* intel: the comment claims __builtin_types_compatible_p()
is unsupported; but icc seems to support it since 13.0.1
(released in 2012). See
Sparse knows about a few more attributes now, so we can remove
the __CHECKER__ conditions from them (which, in turn, allow us
to move some of them later on to compiler_attributes.h).
* assume_aligned: since sparse's commit ffc860b ("sparse:
ignore __assume_aligned__ attribute"), included in
Attributes const and always_inline have tests around them
which are unneeded, since they are supported by gcc >= 4.6,
clang >= 3 and icc >= 13. https://godbolt.org/z/DFPq37
In the case of gnu_inline, we do not need to test for
__GNUC_STDC_INLINE__ because, regardless of the current
inlining
Different definitions of __must_be_array:
* gcc: disabled for __CHECKER__
* clang: same definition as gcc's, but without __CHECKER__
* intel: the comment claims __builtin_types_compatible_p()
is unsupported; but icc seems to support it since 13.0.1
(released in 2012). See
Sparse knows about a few more attributes now, so we can remove
the __CHECKER__ conditions from them (which, in turn, allow us
to move some of them later on to compiler_attributes.h).
* assume_aligned: since sparse's commit ffc860b ("sparse:
ignore __assume_aligned__ attribute"), included in
Attributes const and always_inline have tests around them
which are unneeded, since they are supported by gcc >= 4.6,
clang >= 3 and icc >= 13. https://godbolt.org/z/DFPq37
In the case of gnu_inline, we do not need to test for
__GNUC_STDC_INLINE__ because, regardless of the current
inlining
Instead of using version checks per-compiler to define (or not)
each attribute, use __has_attribute to test for them, following
the cleanup started with commit 815f0ddb346c
("include/linux/compiler*.h: make compiler-*.h mutually exclusive"),
which is supported on gcc >= 5, clang >= 2.9 and icc >=
The Compiler Attributes series is an effort to disentangle
the include/linux/compiler*.h headers and bring them up to date.
The main idea behind the series is to use feature checking macros
(i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION),
which are compiler-agnostic
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc:
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Signed-off-by: Miguel Ojeda
---
MAINTAINERS | 5 +
The attribute syntax optionally allows to surround attribute names
with "__" in order to avoid collisions with macros of the same name
(see https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html).
This homogenizes all attributes to use the syntax with underscores.
While there are currently only
__optimize and __deprecate_for_modules are unused in
the whole kernel tree. Simply drop them.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Jonathan Corbet
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus
Instead of using version checks per-compiler to define (or not)
each attribute, use __has_attribute to test for them, following
the cleanup started with commit 815f0ddb346c
("include/linux/compiler*.h: make compiler-*.h mutually exclusive"),
which is supported on gcc >= 5, clang >= 2.9 and icc >=
The Compiler Attributes series is an effort to disentangle
the include/linux/compiler*.h headers and bring them up to date.
The main idea behind the series is to use feature checking macros
(i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION),
which are compiler-agnostic
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc:
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Signed-off-by: Miguel Ojeda
---
MAINTAINERS | 5 +
The attribute syntax optionally allows to surround attribute names
with "__" in order to avoid collisions with macros of the same name
(see https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html).
This homogenizes all attributes to use the syntax with underscores.
While there are currently only
__optimize and __deprecate_for_modules are unused in
the whole kernel tree. Simply drop them.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Jonathan Corbet
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
The naked attribute is supported by at least gcc >= 4.6 (for ARM,
which is the only current user), gcc >= 8 (for x86), clang >= 3.1
and icc >= 13. See https://godbolt.org/z/350Dyc
Therefore, move it out of compiler-gcc.h so that the definition
is shared by all compilers.
Cc: Rasmus Villemoes
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
The naked attribute is supported by at least gcc >= 4.6 (for ARM,
which is the only current user), gcc >= 8 (for x86), clang >= 3.1
and icc >= 13. See https://godbolt.org/z/350Dyc
Therefore, move it out of compiler-gcc.h so that the definition
is shared by all compilers.
Cc: Rasmus Villemoes
On 09/07/2018 02:07 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.7 release.
There are 145 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 09/07/2018 02:07 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.7 release.
There are 145 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 09/07/2018 02:08 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.69 release.
There are 89 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 09/07/2018 02:08 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.69 release.
There are 89 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 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.126 release.
There are 63 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 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.126 release.
There are 63 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 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.155 release.
There are 47 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 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.155 release.
There are 47 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 09/07/2018 02:10 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.122 release.
There are 29 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 09/07/2018 02:10 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.122 release.
There are 29 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 Sat, Sep 08, 2018 at 09:10:46AM -0700, Randy Dunlap wrote:
> On 09/08/2018 08:54 AM, Matthew Wilcox wrote:
> > On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote:
> >> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
> >>> I'd rather use KB and MB suffixes or at
On Sat, Sep 08, 2018 at 09:10:46AM -0700, Randy Dunlap wrote:
> On 09/08/2018 08:54 AM, Matthew Wilcox wrote:
> > On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote:
> >> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
> >>> I'd rather use KB and MB suffixes or at
Hi Jerome,
Thank you for the patch.
On 09/06/2018 03:59 PM, Jerome Brunet wrote:
> When probing, if we fail to get the pwm due to probe deferal, we shouldn't
> print an error message. Just be silent in this case.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/leds/leds-pwm.c | 5 +++--
> 1
Hi Jerome,
Thank you for the patch.
On 09/06/2018 03:59 PM, Jerome Brunet wrote:
> When probing, if we fail to get the pwm due to probe deferal, we shouldn't
> print an error message. Just be silent in this case.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/leds/leds-pwm.c | 5 +++--
> 1
On Thu, Sep 06, 2018 at 10:15:12PM +, Tyler Hicks wrote:
> On 2018-09-06 09:28:55, Tycho Andersen wrote:
> > /**
> > * struct seccomp_filter - container for seccomp BPF programs
> > *
> > @@ -66,6 +114,30 @@ struct seccomp_filter {
> > bool log;
> > struct seccomp_filter *prev;
>
On Thu, Sep 06, 2018 at 10:15:12PM +, Tyler Hicks wrote:
> On 2018-09-06 09:28:55, Tycho Andersen wrote:
> > /**
> > * struct seccomp_filter - container for seccomp BPF programs
> > *
> > @@ -66,6 +114,30 @@ struct seccomp_filter {
> > bool log;
> > struct seccomp_filter *prev;
>
Debugging a specific driver or subsystem can be a lot easier
if we can trace events specific to that driver or subsystem.
This type of filtering can be achieved using existing
dynamic debug library which provides a way to filter based
on files, functions and modules.
Using this, provide an
The new asm-generic/io-instrumented.h will keep arch code
clean and separate from instrumented version which traces
io register accesses. This instrumented header can later
be included in arm as well for tracing io register accesses.
Suggested-by: Will Deacon
Signed-off-by: Sai Prakash Ranjan
Debugging a specific driver or subsystem can be a lot easier
if we can trace events specific to that driver or subsystem.
This type of filtering can be achieved using existing
dynamic debug library which provides a way to filter based
on files, functions and modules.
Using this, provide an
The new asm-generic/io-instrumented.h will keep arch code
clean and separate from instrumented version which traces
io register accesses. This instrumented header can later
be included in arm as well for tracing io register accesses.
Suggested-by: Will Deacon
Signed-off-by: Sai Prakash Ranjan
Currently pstore has function trace support which can be
used to get the function call chain with limited data.
Event tracing has extra data which is useful to debug wide
variety of issues and is heavily used across the kernel.
Adding this support to pstore can be very helpful to debug
different
Generic IO read/write i.e., __raw_{read,write}{b,l,w,q} are
typically used to read/write from/to memory mapped registers,
which can cause hangs or some undefined behaviour if access
unclocked. Tracing these register accesses can be very helpful
to debug such issues during initial development
Currently pstore has function trace support which can be
used to get the function call chain with limited data.
Event tracing has extra data which is useful to debug wide
variety of issues and is heavily used across the kernel.
Adding this support to pstore can be very helpful to debug
different
Generic IO read/write i.e., __raw_{read,write}{b,l,w,q} are
typically used to read/write from/to memory mapped registers,
which can cause hangs or some undefined behaviour if access
unclocked. Tracing these register accesses can be very helpful
to debug such issues during initial development
Add an optional property called event-size to reserve
log buffer for trace events.
Signed-off-by: Sai Prakash Ranjan
---
.../devicetree/bindings/reserved-memory/ramoops.txt| 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further debugging. This is similar to tp_printk
cmdline option of ftrace.
Pstore support for event tracing is already added and we enable
logging to pstore only
Add an optional property called event-size to reserve
log buffer for trace events.
Signed-off-by: Sai Prakash Ranjan
---
.../devicetree/bindings/reserved-memory/ramoops.txt| 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further debugging. This is similar to tp_printk
cmdline option of ftrace.
Pstore support for event tracing is already added and we enable
logging to pstore only
Hi,
This patch series adds Event tracing support to pstore and is continuation
to the RFC patch introduced to add a new tracing facility for register
accesses called Register Trace Buffer(RTB). Since we decided to not introduce
a separate framework to trace register accesses and use existing
Hi,
This patch series adds Event tracing support to pstore and is continuation
to the RFC patch introduced to add a new tracing facility for register
accesses called Register Trace Buffer(RTB). Since we decided to not introduce
a separate framework to trace register accesses and use existing
Hi Bjorn,
On 09/08/2018 07:02 AM, Bjorn Andersson wrote:
> On Tue 04 Sep 04:01 PDT 2018, Baolin Wang wrote:
>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> [..]
>> +What:
Hi Bjorn,
On 09/08/2018 07:02 AM, Bjorn Andersson wrote:
> On Tue 04 Sep 04:01 PDT 2018, Baolin Wang wrote:
>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> [..]
>> +What:
Hi Vincent,
On 07/09/18 08:40, Vincent Guittot wrote:
> When CPUs have different capacity because of RT/DL tasks or
> micro-architecture or max frequency differences, there are situation where
> the imbalance is not correctly set to migrate waiting task on the idle CPU.
>
This is essentially
Hi Vincent,
On 07/09/18 08:40, Vincent Guittot wrote:
> When CPUs have different capacity because of RT/DL tasks or
> micro-architecture or max frequency differences, there are situation where
> the imbalance is not correctly set to migrate waiting task on the idle CPU.
>
This is essentially
Dan,
On 09/07/2018 03:52 PM, Dan Murphy wrote:
[...]
>>
>>> And I think Jacek pointed out that the bindings references in this bindings
>>> don't even exist.
>>>
>>> I am thinking we need to deprecate this MFD driver and consolidate these
>>> drivers
>>> in the LED directory as we indicated
Dan,
On 09/07/2018 03:52 PM, Dan Murphy wrote:
[...]
>>
>>> And I think Jacek pointed out that the bindings references in this bindings
>>> don't even exist.
>>>
>>> I am thinking we need to deprecate this MFD driver and consolidate these
>>> drivers
>>> in the LED directory as we indicated
On 09/06/2018 09:16 AM, Keerthy wrote:
>
>
> On Wednesday 05 September 2018 04:07 PM, Linus Walleij wrote:
>> On Mon, Sep 3, 2018 at 7:40 AM Keerthy wrote:
>>> On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
Use dev_name to get a unique label and use -1 for a base to get
On 09/06/2018 09:16 AM, Keerthy wrote:
>
>
> On Wednesday 05 September 2018 04:07 PM, Linus Walleij wrote:
>> On Mon, Sep 3, 2018 at 7:40 AM Keerthy wrote:
>>> On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
Use dev_name to get a unique label and use -1 for a base to get
On non-SMP configs, when only one of CONFIG_{PARAVIRT,IRQ_TIME}_ACCOUNTING
is defined, we are declaring a variable (irq_delta or steal) which
is not used:
kernel/sched/core.c: In function ‘update_rq_clock_task’:
kernel/sched/core.c:139:17: warning: unused variable ‘irq_delta’
On non-SMP configs, when only one of CONFIG_{PARAVIRT,IRQ_TIME}_ACCOUNTING
is defined, we are declaring a variable (irq_delta or steal) which
is not used:
kernel/sched/core.c: In function ‘update_rq_clock_task’:
kernel/sched/core.c:139:17: warning: unused variable ‘irq_delta’
1 - 100 of 352 matches
Mail list logo
