[PATCH v4 10/37] tracing: Break out hist trigger assignment parsing

This will make it easier to add variables, and makes the parsing code cleaner regardless. Signed-off-by: Tom Zanussi Signed-off-by: Rajvi Jingar --- kernel/trace/trace_events_hist.c | 72 1 file

[PATCH v4 10/37] tracing: Break out hist trigger assignment parsing

This will make it easier to add variables, and makes the parsing code cleaner regardless. Signed-off-by: Tom Zanussi Signed-off-by: Rajvi Jingar --- kernel/trace/trace_events_hist.c | 72 1 file changed, 51 insertions(+), 21 deletions(-) diff --git

[PATCH v4 05/37] ring-buffer: Add interface for setting absolute time stamps

Define a new function, tracing_set_time_stamp_abs(), which can be used to enable or disable the use of absolute timestamps rather than time deltas for a trace array. Only the interface is added here; a subsequent patch will add the underlying implementation. Signed-off-by: Tom Zanussi

[PATCH v4 05/37] ring-buffer: Add interface for setting absolute time stamps

Define a new function, tracing_set_time_stamp_abs(), which can be used to enable or disable the use of absolute timestamps rather than time deltas for a trace array. Only the interface is added here; a subsequent patch will add the underlying implementation. Signed-off-by: Tom Zanussi

[PATCH v4 12/37] tracing: Add per-element variable support to tracing_map

In order to allow information to be passed between trace events, add support for per-element variables to tracing_map. This provides a means for histograms to associate a value or values with an entry when it's saved or updated, and retrieved by a subsequent event occurrences. Variables can be

[PATCH v4 12/37] tracing: Add per-element variable support to tracing_map

In order to allow information to be passed between trace events, add support for per-element variables to tracing_map. This provides a means for histograms to associate a value or values with an entry when it's saved or updated, and retrieved by a subsequent event occurrences. Variables can be

[PATCH v4 11/37] tracing: Add hist trigger timestamp support

Add support for a timestamp event field. This is actually a 'pseudo-' event field in that it behaves like it's part of the event record, but is really part of the corresponding ring buffer event. To make use of the timestamp field, users can specify "$common_timestamp" as a field name for any

[PATCH v4 11/37] tracing: Add hist trigger timestamp support

Add support for a timestamp event field. This is actually a 'pseudo-' event field in that it behaves like it's part of the event record, but is really part of the corresponding ring buffer event. To make use of the timestamp field, users can specify "$common_timestamp" as a field name for any

[PATCH v4 14/37] tracing: Add usecs modifier for hist trigger timestamps

Appending .usecs onto a $common_timestamp field will cause the timestamp value to be in microseconds instead of the default nanoseconds. A typical latency histogram using usecs would look like this: # echo 'hist:keys=pid,prio:ts0=$common_timestamp.usecs ... # echo

[PATCH v4 14/37] tracing: Add usecs modifier for hist trigger timestamps

Appending .usecs onto a $common_timestamp field will cause the timestamp value to be in microseconds instead of the default nanoseconds. A typical latency histogram using usecs would look like this: # echo 'hist:keys=pid,prio:ts0=$common_timestamp.usecs ... # echo

[PATCH v4 20/37] tracing: Pass tracing_map_elt to hist_field accessor functions

Some accessor functions, such as for variable references, require access to a corrsponding tracing_map_elt. Add a tracing_map_elt param to the function signature and update the accessor functions accordingly. Signed-off-by: Tom Zanussi ---

[PATCH v4 20/37] tracing: Pass tracing_map_elt to hist_field accessor functions

Some accessor functions, such as for variable references, require access to a corrsponding tracing_map_elt. Add a tracing_map_elt param to the function signature and update the accessor functions accordingly. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 91

[PATCH v4 13/37] tracing: Add hist_data member to hist_field

Allow hist_data access via hist_field. Some users of hist_fields require or will require more access to the associated hist_data. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-)

[PATCH v4 13/37] tracing: Add hist_data member to hist_field

Allow hist_data access via hist_field. Some users of hist_fields require or will require more access to the associated hist_data. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

[PATCH v4 21/37] tracing: Add hist_field 'type' field

Future support for synthetic events requires hist_field 'type' information, so add a field for that. Also, make other hist_field attribute usage consistent (size, is_signed, etc). Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 33

[PATCH v4 21/37] tracing: Add hist_field 'type' field

Future support for synthetic events requires hist_field 'type' information, so add a field for that. Also, make other hist_field attribute usage consistent (size, is_signed, etc). Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 33 + 1 file

[PATCH v4 23/37] tracing: Add hist trigger action hook

Add a hook for executing extra actions whenever a histogram entry is added or updated. The default 'action' when a hist entry is added to a histogram is to update the set of values associated with it. Some applications may want to perform additional actions at that point, such as generate

[PATCH v4 23/37] tracing: Add hist trigger action hook

Add a hook for executing extra actions whenever a histogram entry is added or updated. The default 'action' when a hist entry is added to a histogram is to update the set of values associated with it. Some applications may want to perform additional actions at that point, such as generate

[PATCH v4 18/37] tracing: Add simple expression support to hist triggers

Add support for simple addition, subtraction, and unary expressions (-(expr) and expr, where expr = b-a, a+b, a+b+c) to hist triggers, in order to support a minimal set of useful inter-event calculations. These operations are needed for calculating latencies between events (timestamp1-timestamp0)

[PATCH v4 18/37] tracing: Add simple expression support to hist triggers

Add support for simple addition, subtraction, and unary expressions (-(expr) and expr, where expr = b-a, a+b, a+b+c) to hist triggers, in order to support a minimal set of useful inter-event calculations. These operations are needed for calculating latencies between events (timestamp1-timestamp0)

Kernel crash in free_pipe_info()

Hi, Linus We got more than a dozen of kernel crashes at free_pipe_info() on our 4.1 kernel, they are all very similar to this one (with slightly different faulty addresses): [433948.755473] BUG: unable to handle kernel paging request at 0001000d [433948.762570] IP: []

Kernel crash in free_pipe_info()

Hi, Linus We got more than a dozen of kernel crashes at free_pipe_info() on our 4.1 kernel, they are all very similar to this one (with slightly different faulty addresses): [433948.755473] BUG: unable to handle kernel paging request at 0001000d [433948.762570] IP: []

[PATCH] drivers/net: cris: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: "David S. Miller" Cc: Kalle Valo Cc: Arnd Bergmann

[PATCH] drivers/net: cris: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: "David S. Miller" Cc: Kalle Valo Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc:

[PATCH v4 25/37] tracing: Add support for 'field variables'

Users should be able to directly specify event fields in hist trigger 'actions' rather than being forced to explicitly create a variable for that purpose. Add support allowing fields to be used directly in actions, which essentially does just that - creates 'invisible' variables for each bare

[PATCH v4 25/37] tracing: Add support for 'field variables'

Users should be able to directly specify event fields in hist trigger 'actions' rather than being forced to explicitly create a variable for that purpose. Add support allowing fields to be used directly in actions, which essentially does just that - creates 'invisible' variables for each bare

[PATCH v4 30/37] tracing: Add hist trigger support for variable reference aliases

Add support for alias=$somevar where alias can be used as onmatch.xxx($alias). Aliases are a way of creating a new name for an existing variable, for flexibly in making naming more clear in certain cases. For example in the below the user perhaps feels that using $new_lat in the synthetic event

[PATCH v4 30/37] tracing: Add hist trigger support for variable reference aliases

Add support for alias=$somevar where alias can be used as onmatch.xxx($alias). Aliases are a way of creating a new name for an existing variable, for flexibly in making naming more clear in certain cases. For example in the below the user perhaps feels that using $new_lat in the synthetic event

[PATCH v4 28/37] tracing: Allow whitespace to surround hist trigger filter

The existing code only allows for one space before and after the 'if' specifying the filter for a hist trigger. Add code to make that more permissive as far as whitespace goes. Specifically, we want to allow spaces in the trigger itself now that we have additional syntax (onmatch/onmax) where

[PATCH v4 28/37] tracing: Allow whitespace to surround hist trigger filter

The existing code only allows for one space before and after the 'if' specifying the filter for a hist trigger. Add code to make that more permissive as far as whitespace goes. Specifically, we want to allow spaces in the trigger itself now that we have additional syntax (onmatch/onmax) where

[PATCH v4 33/37] tracing: Make tracing_set_clock() non-static

Allow tracing code outside of trace.c to access tracing_set_clock(). Some applications may require a particular clock in order to function properly, such as latency calculations. Also, add an accessor returning the current clock string. Signed-off-by: Tom Zanussi

[PATCH v4 33/37] tracing: Make tracing_set_clock() non-static

Allow tracing code outside of trace.c to access tracing_set_clock(). Some applications may require a particular clock in order to function properly, such as latency calculations. Also, add an accessor returning the current clock string. Signed-off-by: Tom Zanussi --- kernel/trace/trace.c | 2

linux-next: manual merge of the tip tree with the net-next tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: net/ipv4/tcp_output.c between commit: 6aa7de059173a ("locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()") in the tip tree and some change in the net-next tree. I

linux-next: manual merge of the tip tree with the net-next tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: net/ipv4/tcp_output.c between commit: 6aa7de059173a ("locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()") in the tip tree and some change in the net-next tree. I

Re: [PATCH] ARM: dts: exynos: fix property values of LDO15/17 for ODROID-XU3/4

On Sat, Oct 28, 2017 at 01:32:48PM -0400, tobet...@gmail.com wrote: > From: Dongjin Kim > > Looking at the schematic, LDO15 and LDO17 are tied as a power source of a > builtin network chipset. The voltage on LDO15 is corrected to 3.3V and the > name of LDO17 is corrected to

Re: [PATCH] ARM: dts: exynos: fix property values of LDO15/17 for ODROID-XU3/4

On Sat, Oct 28, 2017 at 01:32:48PM -0400, tobet...@gmail.com wrote: > From: Dongjin Kim > > Looking at the schematic, LDO15 and LDO17 are tied as a power source of a > builtin network chipset. The voltage on LDO15 is corrected to 3.3V and the > name of LDO17 is corrected to "vdd_ldo17". > >

[PATCH v4 35/37] tracing: Increase trace_recursive_lock() limit for synthetic events

Synthetic event generation needs to happen while the current event is still in progress, so add 1 to the trace_recursive_lock() recursion limit to account for that. Because we also want to allow for the possibility of a synthetic event being generated from another synthetic event, add an

[PATCH v4 35/37] tracing: Increase trace_recursive_lock() limit for synthetic events

Synthetic event generation needs to happen while the current event is still in progress, so add 1 to the trace_recursive_lock() recursion limit to account for that. Because we also want to allow for the possibility of a synthetic event being generated from another synthetic event, add an

[PATCH v4 31/37] tracing: Add 'last error' error facility for hist triggers

With the addition of variables and actions, it's become necessary to provide more detailed error information to users about syntax errors. Add a 'last error' facility accessible via the erroring event's 'hist' file. Reading the hist file after an error will display more detailed information

[PATCH v4 31/37] tracing: Add 'last error' error facility for hist triggers

With the addition of variables and actions, it's become necessary to provide more detailed error information to users about syntax errors. Add a 'last error' facility accessible via the erroring event's 'hist' file. Reading the hist file after an error will display more detailed information

[PATCH v4 37/37] selftests: ftrace: Add inter-event hist triggers testcases

From: Rajvi Jingar This adds inter-event hist triggers testcases which covers following: - create/remove synthetic event - disable histogram for synthetic event - extended error support - field variable support - histogram variables - histogram trigger onmatch

[PATCH v4 37/37] selftests: ftrace: Add inter-event hist triggers testcases

From: Rajvi Jingar This adds inter-event hist triggers testcases which covers following: - create/remove synthetic event - disable histogram for synthetic event - extended error support - field variable support - histogram variables - histogram trigger onmatch action - histogram trigger

[PATCH v4 34/37] tracing: Add a clock attribute for hist triggers

The default clock if timestamps are used in a histogram is "global". If timestamps aren't used, the clock is irrelevant. Use the "clock=" param only if you want to override the default "global" clock for a histogram with timestamps. Signed-off-by: Tom Zanussi

[PATCH v4 34/37] tracing: Add a clock attribute for hist triggers

The default clock if timestamps are used in a histogram is "global". If timestamps aren't used, the clock is irrelevant. Use the "clock=" param only if you want to override the default "global" clock for a histogram with timestamps. Signed-off-by: Tom Zanussi Signed-off-by: Rajvi Jingar ---

[PATCH v4 36/37] tracing: Add inter-event blurb to HIST_TRIGGERS config option

So that users know that inter-event tracing is supported as part of the HIST_TRIGGERS option, include text to that effect in the help text. Signed-off-by: Tom Zanussi --- kernel/trace/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v4 36/37] tracing: Add inter-event blurb to HIST_TRIGGERS config option

So that users know that inter-event tracing is supported as part of the HIST_TRIGGERS option, include text to that effect in the help text. Signed-off-by: Tom Zanussi --- kernel/trace/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig

[PATCH v4 27/37] tracing: Add 'onmax' hist trigger action support

Add an 'onmax(var).save(field,...)' hist trigger action which is invoked whenever an event exceeds the current maximum. The end result is that the trace event fields or variables specified as the onmax.save() params will be saved if 'var' exceeds the current maximum for that hist trigger entry.

[PATCH v4 27/37] tracing: Add 'onmax' hist trigger action support

Add an 'onmax(var).save(field,...)' hist trigger action which is invoked whenever an event exceeds the current maximum. The end result is that the trace event fields or variables specified as the onmax.save() params will be saved if 'var' exceeds the current maximum for that hist trigger entry.

[PATCH v4 24/37] tracing: Add support for 'synthetic' events

Synthetic events are user-defined events generated from hist trigger variables saved from one or more other events. To define a synthetic event, the user writes a simple specification consisting of the name of the new event along with one or more variables and their type(s), to the

[PATCH v4 24/37] tracing: Add support for 'synthetic' events

Synthetic events are user-defined events generated from hist trigger variables saved from one or more other events. To define a synthetic event, the user writes a simple specification consisting of the name of the new event along with one or more variables and their type(s), to the

[PATCH v4 32/37] tracing: Add inter-event hist trigger Documentation

Add background and details on inter-event hist triggers, including hist variables, synthetic events, and actions. Signed-off-by: Tom Zanussi Signed-off-by: Baohong Liu --- Documentation/trace/histogram.txt | 382

[PATCH v4 32/37] tracing: Add inter-event hist trigger Documentation

Add background and details on inter-event hist triggers, including hist variables, synthetic events, and actions. Signed-off-by: Tom Zanussi Signed-off-by: Baohong Liu --- Documentation/trace/histogram.txt | 382 ++ 1 file changed, 382 insertions(+) diff

[PATCH v4 29/37] tracing: Add cpu field for hist triggers

A common key to use in a histogram is the cpuid - add a new cpu 'synthetic' field for that purpose. This field is named cpu rather than $cpu or $common_cpu because 'cpu' already exists as a special filter field and it makes more sense to match that rather than add another name for the same thing.

[PATCH v4 29/37] tracing: Add cpu field for hist triggers

A common key to use in a histogram is the cpuid - add a new cpu 'synthetic' field for that purpose. This field is named cpu rather than $cpu or $common_cpu because 'cpu' already exists as a special filter field and it makes more sense to match that rather than add another name for the same thing.

[PATCH v4 26/37] tracing: Add 'onmatch' hist trigger action support

Add an 'onmatch(matching.event).(param list)' hist trigger action which is invoked with the set of variables or event fields named in the 'param list'. The result is the generation of a synthetic event that consists of the values contained in those variables and/or fields at the time the invoking

[PATCH v4 26/37] tracing: Add 'onmatch' hist trigger action support

Add an 'onmatch(matching.event).(param list)' hist trigger action which is invoked with the set of variables or event fields named in the 'param list'. The result is the generation of a synthetic event that consists of the values contained in those variables and/or fields at the time the invoking

[PATCH v4 22/37] tracing: Add variable reference handling to hist triggers

Add the necessary infrastructure to allow the variables defined on one event to be referenced in another. This allows variables set by a previous event to be referenced and used in expressions combining the variable values saved by that previous event and the event fields of the current event.

[PATCH v4 22/37] tracing: Add variable reference handling to hist triggers

Add the necessary infrastructure to allow the variables defined on one event to be referenced in another. This allows variables set by a previous event to be referenced and used in expressions combining the variable values saved by that previous event and the event fields of the current event.

[PATCH v4 15/37] tracing: Add variable support to hist triggers

Add support for saving the value of a current event's event field by assigning it to a variable that can be read by a subsequent event. The basic syntax for saving a variable is to simply prefix a unique variable name not corresponding to any keyword along with an '=' sign to any event field.

[PATCH v4 15/37] tracing: Add variable support to hist triggers

Add support for saving the value of a current event's event field by assigning it to a variable that can be read by a subsequent event. The basic syntax for saving a variable is to simply prefix a unique variable name not corresponding to any keyword along with an '=' sign to any event field.

[PATCH v4 16/37] tracing: Account for variables in named trigger compatibility

Named triggers must also have the same set of variables in order to be considered compatible - update the trigger match test to account for that. The reason for this requirement is that named triggers with variables are meant to allow one or more events to set the same variable. Signed-off-by:

[PATCH v4 19/37] tracing: Generalize per-element hist trigger data

Up until now, hist triggers only needed per-element support for saving 'comm' data, which was saved directly as a private data pointer. In anticipation of the need to save other data besides 'comm', add a new hist_elt_data struct for the purpose, and switch the current 'comm'-related code over to

[PATCH v4 16/37] tracing: Account for variables in named trigger compatibility

Named triggers must also have the same set of variables in order to be considered compatible - update the trigger match test to account for that. The reason for this requirement is that named triggers with variables are meant to allow one or more events to set the same variable. Signed-off-by:

[PATCH v4 19/37] tracing: Generalize per-element hist trigger data

Up until now, hist triggers only needed per-element support for saving 'comm' data, which was saved directly as a private data pointer. In anticipation of the need to save other data besides 'comm', add a new hist_elt_data struct for the purpose, and switch the current 'comm'-related code over to

[PATCH v4 09/37] tracing: Add ring buffer event param to hist field functions

Some events such as timestamps require access to a ring_buffer_event struct; add a param so that hist field functions can access that. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 39 --- 1 file changed, 24

[PATCH v4 08/37] tracing: Give event triggers access to ring_buffer_event

The ring_buffer event can provide a timestamp that may be useful to various triggers - pass it into the handlers for that purpose. Signed-off-by: Tom Zanussi --- include/linux/trace_events.h| 14 ++- kernel/trace/trace.h| 9 +++

[PATCH v4 09/37] tracing: Add ring buffer event param to hist field functions

Some events such as timestamps require access to a ring_buffer_event struct; add a param so that hist field functions can access that. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 39 --- 1 file changed, 24 insertions(+), 15 deletions(-)

[PATCH v4 08/37] tracing: Give event triggers access to ring_buffer_event

The ring_buffer event can provide a timestamp that may be useful to various triggers - pass it into the handlers for that purpose. Signed-off-by: Tom Zanussi --- include/linux/trace_events.h| 14 ++- kernel/trace/trace.h| 9 +++

[PATCH v4 07/37] tracing: Add timestamp_mode trace file

Add a new option flag indicating whether or not the ring buffer is in 'absolute timestamp' mode. Currently this is only set/unset by hist triggers that make use of a $common_timestamp. As such, there's no reason to make this writeable for users - its purpose is only to allow users to determine

[PATCH v4 06/37] ring-buffer: Redefine the unimplemented RINGBUF_TYPE_TIME_STAMP

RINGBUF_TYPE_TIME_STAMP is defined but not used, and from what I can gather was reserved for something like an absolute timestamp feature for the ring buffer, if not a complete replacement of the current time_delta scheme. This code redefines RINGBUF_TYPE_TIME_STAMP to implement absolute time

[PATCH v4 07/37] tracing: Add timestamp_mode trace file

Add a new option flag indicating whether or not the ring buffer is in 'absolute timestamp' mode. Currently this is only set/unset by hist triggers that make use of a $common_timestamp. As such, there's no reason to make this writeable for users - its purpose is only to allow users to determine

[PATCH v4 06/37] ring-buffer: Redefine the unimplemented RINGBUF_TYPE_TIME_STAMP

RINGBUF_TYPE_TIME_STAMP is defined but not used, and from what I can gather was reserved for something like an absolute timestamp feature for the ring buffer, if not a complete replacement of the current time_delta scheme. This code redefines RINGBUF_TYPE_TIME_STAMP to implement absolute time

[PATCH v4 00/37] tracing: Inter-event (e.g. latency) support

Hi, This is V4 of the inter-event tracing patchset, addressing input from V3. These mainly directly address the input from V3, but there are a couple new things too - a new set of selftests (thanks to Rajvi Jingar for those), and a new 'timestamp_mode' ftrace file making it easy to see exactly

[PATCH v4 00/37] tracing: Inter-event (e.g. latency) support

Hi, This is V4 of the inter-event tracing patchset, addressing input from V3. These mainly directly address the input from V3, but there are a couple new things too - a new set of selftests (thanks to Rajvi Jingar for those), and a new 'timestamp_mode' ftrace file making it easy to see exactly

Re: [PATCH] Check all .c files for bad kernel-doc comments

On Mon, Oct 30, 2017 at 05:19:18PM +0200, Jani Nikula wrote: > Related, there was also a script to do reStructuredText lint style > checks in addition to the kernel-doc checks using make CHECK and > C=1. See http://mid.mail-archive.com/87h98quc1w.fsf@intel.com I don't really care which patch goes

Re: [PATCH] Check all .c files for bad kernel-doc comments

On Mon, Oct 30, 2017 at 05:19:18PM +0200, Jani Nikula wrote: > Related, there was also a script to do reStructuredText lint style > checks in addition to the kernel-doc checks using make CHECK and > C=1. See http://mid.mail-archive.com/87h98quc1w.fsf@intel.com I don't really care which patch goes

Re: [PATCH] ravb: Use common error handling code in ravb_probe()

Hello! On 10/28/2017 08:19 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Sat, 28 Oct 2017 19:10:08 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. Have you actually tried to see if

Re: [PATCH] ravb: Use common error handling code in ravb_probe()

Hello! On 10/28/2017 08:19 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Sat, 28 Oct 2017 19:10:08 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. Have you actually tried to see if there's any change in the

Re: [PATCH v2] ARM: dts: exynos: add cpu perf counters to Exynos54xx boards

On Tue, Oct 24, 2017 at 12:59:56PM +1030, memeka wrote: > Enable support for ARM Performance Monitoring Units available in Cortex-A7 > and Cortex-A15 CPU cores for Exynos54xx SoCs (5410, 5420 and 5422/5800). > > The PMUs interrupts are defined in the common exynos54xx.dtsi device tree, > but the

Re: [PATCH v2] ARM: dts: exynos: add cpu perf counters to Exynos54xx boards

On Tue, Oct 24, 2017 at 12:59:56PM +1030, memeka wrote: > Enable support for ARM Performance Monitoring Units available in Cortex-A7 > and Cortex-A15 CPU cores for Exynos54xx SoCs (5410, 5420 and 5422/5800). > > The PMUs interrupts are defined in the common exynos54xx.dtsi device tree, > but the

[PATCH] bq2415x_charger: Use common error handling code in bq2415x_timer_work()

From: Markus Elfring Date: Mon, 30 Oct 2017 21:45:09 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] bq2415x_charger: Use common error handling code in bq2415x_timer_work()

From: Markus Elfring Date: Mon, 30 Oct 2017 21:45:09 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

linux-next: manual merge of the devicetree tree with the drm tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c between commit: 44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag setting") from the drm tree and commit: f948d6d8b792bb ("of: overlay: avoid race

linux-next: manual merge of the devicetree tree with the drm tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c between commit: 44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag setting") from the drm tree and commit: f948d6d8b792bb ("of: overlay: avoid race

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

On Mon, Oct 30, 2017 at 12:29:47PM -0700, Linus Torvalds wrote: On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu wrote: Here are 3 dmesgs related to wireless and 1 from ethernet. Fengguang, these would be lovelier still _if_ you have DEBUG_INFO enabled on the kernel,

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

On Mon, Oct 30, 2017 at 12:29:47PM -0700, Linus Torvalds wrote: On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu wrote: Here are 3 dmesgs related to wireless and 1 from ethernet. Fengguang, these would be lovelier still _if_ you have DEBUG_INFO enabled on the kernel, and your script were to

Re: [4.14-rc7] task struct corruption after fork

On Mon, Oct 30, 2017 at 11:59:30AM -0700, Linus Torvalds wrote: > and that location would *almost* make sense in that it's the end of > the same page that contained a "struct task_struct". > > Are you running with VMAP_STACK? Is there perhaps some stale code that > ends up doing the old

Re: [4.14-rc7] task struct corruption after fork

On Mon, Oct 30, 2017 at 11:59:30AM -0700, Linus Torvalds wrote: > and that location would *almost* make sense in that it's the end of > the same page that contained a "struct task_struct". > > Are you running with VMAP_STACK? Is there perhaps some stale code that > ends up doing the old

Re: [PATCH] fpga: fpga-bridge: remove unnecessary null check in of_fpga_bridge_get

On Sat, Oct 28, 2017 at 12:15 PM, Moritz Fischer wrote: Hi Gustavo, Thanks! Alan > On Fri, Oct 27, 2017 at 08:19:51PM +, Gustavo A. R. Silva wrote: >> Notice that bridge = to_fpga_bridge(dev); expands to: >> >> bridge = container_of(dev, struct fpga_bridge, dev); >> >>

Re: [PATCH] fpga: fpga-bridge: remove unnecessary null check in of_fpga_bridge_get

On Sat, Oct 28, 2017 at 12:15 PM, Moritz Fischer wrote: Hi Gustavo, Thanks! Alan > On Fri, Oct 27, 2017 at 08:19:51PM +, Gustavo A. R. Silva wrote: >> Notice that bridge = to_fpga_bridge(dev); expands to: >> >> bridge = container_of(dev, struct fpga_bridge, dev); >> >> and container_of is

Re: [PATCH v3 0/12] arm+arm64: vdso unification to lib/vdso/

On 10/30/2017 07:18 AM, Mark Rutland wrote: Hi, On Fri, Oct 27, 2017 at 03:23:48PM -0700, Mark Salyzyn wrote: Note I noticed a bug in the old implementation of __kernel_clock_getres; it was checking only the lower 32bits of the pointer; this would work for most cases but could fail in a few.

Re: [PATCH v3 0/12] arm+arm64: vdso unification to lib/vdso/

On 10/30/2017 07:18 AM, Mark Rutland wrote: Hi, On Fri, Oct 27, 2017 at 03:23:48PM -0700, Mark Salyzyn wrote: Note I noticed a bug in the old implementation of __kernel_clock_getres; it was checking only the lower 32bits of the pointer; this would work for most cases but could fail in a few.

Re: [PATCH v3 05/12] arm: vdso: do calculations outside reader loops

Thanks for the review, am taking all the points into consideration. On 10/30/2017 07:15 AM, Mark Rutland wrote: + + typeof(((struct vdso_data *)vd)->xtime_clock_sec) sec; Why do we need to do this typeof() magic? Can't we settle on a consistent type across arches, or have a typedef in a

Re: [PATCH v3 05/12] arm: vdso: do calculations outside reader loops

Thanks for the review, am taking all the points into consideration. On 10/30/2017 07:15 AM, Mark Rutland wrote: + + typeof(((struct vdso_data *)vd)->xtime_clock_sec) sec; Why do we need to do this typeof() magic? Can't we settle on a consistent type across arches, or have a typedef in a

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

On Mon, 2017-10-30 at 15:24 +0100, Wolfram Sang wrote: > checkpatch --strict says: > > CHECK: braces {} should be used on all arms of this statement And checkpatch should die a horrible death, so what ? :-) Sorry, I can't help but trolling here when checkpatch enforce obviously disgusting and

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

On Mon, 2017-10-30 at 15:24 +0100, Wolfram Sang wrote: > checkpatch --strict says: > > CHECK: braces {} should be used on all arms of this statement And checkpatch should die a horrible death, so what ? :-) Sorry, I can't help but trolling here when checkpatch enforce obviously disgusting and

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, 25 Oct 2017 14:49:34 +1100 "Tobin C. Harding" wrote: > > First, the static_key stuff. > > DEFINE_STATIC_KEY_TRUE(no_ptr_secret) : Doesn't sleep, just a > declaration. > > if (static_branch_unlikely(_ptr_secret)) {} : Doesn't sleep, just > some assembler to jump to

Re: [PATCH v7] printk: hash addresses printed with %p

On Wed, 25 Oct 2017 14:49:34 +1100 "Tobin C. Harding" wrote: > > First, the static_key stuff. > > DEFINE_STATIC_KEY_TRUE(no_ptr_secret) : Doesn't sleep, just a > declaration. > > if (static_branch_unlikely(_ptr_secret)) {} : Doesn't sleep, just > some assembler to jump to returning true or

Re: [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 12:10:11PM -0700, Linus Torvalds wrote: On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: CC intel-gfx. Thanks, these are all interesting (even if some of them seem to be from random kernels). Fengguang, is this a new script that you

Re: [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 12:10:11PM -0700, Linus Torvalds wrote: On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: CC intel-gfx. Thanks, these are all interesting (even if some of them seem to be from random kernels). Fengguang, is this a new script that you started running? Because I'm

<    1   2   3   4   5   6   7   8   9   10   >