rently in use.
Signed-off-by: Bo Yan <b...@nvidia.com>
---
Changes in v2: rename tr_buf to trace_buf
kernel/trace/trace.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5360b7aec57a..a7fb136da891 100644
--- a/kernel/
On 09/17/2017 06:50 PM, Viresh Kumar wrote:
On 15-09-17, 13:13, Bo Yan wrote:
It is possible for last_index to get a -1 if current frequency
is not found in the freq table when stats is created. If the
function "cpufreq_stats_update" is called before last_index is
updated with a v
me_in_state, triggering an exception.
Change the type of last_index of cpufreq_stats from unsigned int
to signed int.
Move last_time to location right before time_in_state. This helps
save 4 bytes in a LP64 programming model.
Signed-off-by: Bo Yan <b...@nvidia.com>
---
drivers/cpufreq/cpufreq_stats.
Steven,
Thanks for review. I have posted the following update
https://lkml.org/lkml/2017/9/18/715
Bo
On 09/18/2017 07:38 AM, Steven Rostedt wrote:
On Mon, 11 Sep 2017 11:16:35 -0700
Bo Yan <b...@nvidia.com> wrote:
One convenient way to erase trace is "echo > t
rently in use.
Signed-off-by: Bo Yan <b...@nvidia.com>
---
kernel/trace/trace.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5360b7aec57a..1f91bdd9365b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@
On 01/23/2018 06:02 PM, Rafael J. Wysocki wrote:
On Tuesday, January 23, 2018 10:57:55 PM CET Bo Yan wrote:
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 41d148af7748..95b1c4afe14e 100644
of suspend failure, system should not crash.
The fix is to check the pm_transition status in dpm_resume. if
pm_transition.event == PMSG_ON, we know for sure dpm_suspend has not
been called, so do not call cpufreq_resume.
Signed-off-by: Bo Yan <b...@nvidia.com>
---
drivers/base/power/m
On 02/02/2018 11:34 AM, Saravana Kannan wrote:
On 02/02/2018 03:54 AM, Rafael J. Wysocki wrote:
On Wednesday, January 24, 2018 9:53:14 PM CET Bo Yan wrote:
On 01/23/2018 06:02 PM, Rafael J. Wysocki wrote:
On Tuesday, January 23, 2018 10:57:55 PM CET Bo Yan wrote:
drivers/cpufreq
The of_address_to_resource returns 0 if successful. gic_check_eoimode
calls it without checking the return value. This induces Coverity
warning: "Unchecked return value".
Return false from gic_check_eoimode if of_address_to_resource returns
non-0 value.
Signed-off-by: Bo Yan
--
will always return success.
On 07/05/2018 12:13 PM, Marc Zyngier wrote:
Hi Bo,
On Thu, 5 Jul 2018 11:20:59 -0700
Bo Yan wrote:
The of_address_to_resource returns 0 if successful. gic_check_eoimode
calls it without checking the return value. This induces Coverity
warning: "Unchecked r
);
if (!is_hyp_mode_available())
return false;
We are 100% sure of_address_to_resource will succeed in this particular
case, so "(void)" will help suppress Coverity warning.
On 07/05/2018 12:18 PM, Bo Yan wrote:
Marc,
I'm also wondering if of_address_to_resource can r
n
majority of cases it generates the ldp instructions.
On 07/09/2018 04:54 AM, Robin Murphy wrote:
Hi Bo,
On 06/07/18 17:27, Bo Yan wrote:
Hi Robin, Luke,
Recently I bumped into an error when running GCC undefined behavior
sanitizer:
UBSAN: Undefined behaviour in
kernel-4.9/arch/
Hi Robin, Luke,
Recently I bumped into an error when running GCC undefined behavior
sanitizer:
UBSAN: Undefined behaviour in
kernel-4.9/arch/arm64/include/asm/checksum.h:34:6
load of misaligned address ffc198c8b254 for type 'const
__int128 unsigned'
which requires 16 byte
of suspend failure, system should not crash.
The fix is to check cpufreq_suspended first, if it's false, that means
cpufreq_suspend was not called in the first place, so do not resume
cpufreq.
Signed-off-by: Bo Yan <b...@nvidia.com>
---
drivers/cpufreq/cpufreq.c | 4
1 file cha
ctxid_pid and vmid_val in config are of type u64. When an integer
0xFF is being left shifted more than 32 bits, the behavior is
undefined. The fix is to specify 0xFF as an unsigned long.
Detected by Coverity scan: CID 37650, 37651 (Bad bit shift operation)
Signed-off-by: Bo Yan <b...@nvidia.
The function tegra_read_chipid is declared twice in fuse.h. Remove
the redundant declaration.
Signed-off-by: Bo Yan
---
include/soc/tegra/fuse.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/soc/tegra/fuse.h b/include/soc/tegra/fuse.h
index 9b6ea0c..8fb2f8a 100644
--- a/include/soc
rently in use.
Signed-off-by: Bo Yan
---
Changes in v2: rename tr_buf to trace_buf
kernel/trace/trace.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5360b7aec57a..a7fb136da891 100644
--- a/kernel/trace/trace.c
+++ b
On 09/17/2017 06:50 PM, Viresh Kumar wrote:
On 15-09-17, 13:13, Bo Yan wrote:
It is possible for last_index to get a -1 if current frequency
is not found in the freq table when stats is created. If the
function "cpufreq_stats_update" is called before last_index is
updated with a v
Steven,
Thanks for review. I have posted the following update
https://lkml.org/lkml/2017/9/18/715
Bo
On 09/18/2017 07:38 AM, Steven Rostedt wrote:
On Mon, 11 Sep 2017 11:16:35 -0700
Bo Yan wrote:
One convenient way to erase trace is "echo > trace". However, this
is cur
me_in_state, triggering an exception.
Change the type of last_index of cpufreq_stats from unsigned int
to signed int.
Move last_time to location right before time_in_state. This helps
save 4 bytes in a LP64 programming model.
Signed-off-by: Bo Yan
---
drivers/cpufreq/cpufreq_stats.c | 4 ++--
1 file chan
ctxid_pid and vmid_val in config are of type u64. When an integer
0xFF is being left shifted more than 32 bits, the behavior is
undefined. The fix is to specify 0xFF as an unsigned long.
Detected by Coverity scan: CID 37650, 37651 (Bad bit shift operation)
Signed-off-by: Bo Yan
---
drivers
On 02/02/2018 11:34 AM, Saravana Kannan wrote:
On 02/02/2018 03:54 AM, Rafael J. Wysocki wrote:
On Wednesday, January 24, 2018 9:53:14 PM CET Bo Yan wrote:
On 01/23/2018 06:02 PM, Rafael J. Wysocki wrote:
On Tuesday, January 23, 2018 10:57:55 PM CET Bo Yan wrote:
drivers/cpufreq
rently in use.
Signed-off-by: Bo Yan
---
kernel/trace/trace.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5360b7aec57a..1f91bdd9365b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4020,11 +4020,17
of suspend failure, system should not crash.
The fix is to check cpufreq_suspended first, if it's false, that means
cpufreq_suspend was not called in the first place, so do not resume
cpufreq.
Signed-off-by: Bo Yan
---
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 insertions(+)
d
On 01/23/2018 06:02 PM, Rafael J. Wysocki wrote:
On Tuesday, January 23, 2018 10:57:55 PM CET Bo Yan wrote:
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 41d148af7748..95b1c4afe14e 100644
of suspend failure, system should not crash.
The fix is to check the pm_transition status in dpm_resume. if
pm_transition.event == PMSG_ON, we know for sure dpm_suspend has not
been called, so do not call cpufreq_resume.
Signed-off-by: Bo Yan
---
drivers/base/power/main.c | 4 +++-
1 file
I agree, will update this patch with full paths replacing phandles.
On 2/13/19 12:12 AM, Thierry Reding wrote:
On Mon, Feb 11, 2019 at 03:47:07PM -0800, Bo Yan wrote:
The xavier CPU architecture includes 8 CPU cores organized in
4 clusters. Add cpu-map data for topology initialization
The xavier CPU architecture includes 8 CPU cores organized in
4 clusters. Add cpu-map data for topology initialization, this
fixes the topology information in
/sys/devices/system/cpu/cpu[n]/topology
Signed-off-by: Bo Yan
---
V3: Replaced phandles with full path to CPU node
V2: remove cache nodes
n
majority of cases it generates the ldp instructions.
On 07/09/2018 04:54 AM, Robin Murphy wrote:
Hi Bo,
On 06/07/18 17:27, Bo Yan wrote:
Hi Robin, Luke,
Recently I bumped into an error when running GCC undefined behavior
sanitizer:
UBSAN: Undefined behaviour in
kernel-4.9/arch/
The function tegra_read_chipid is declared twice in fuse.h. Remove
the redundant declaration.
Signed-off-by: Bo Yan
---
include/soc/tegra/fuse.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/soc/tegra/fuse.h b/include/soc/tegra/fuse.h
index 9b6ea0c..8fb2f8a 100644
--- a/include/soc
The patch V3 adopted changes suggested by Thierry.
On 2/13/19 8:33 AM, Bo Yan wrote:
The xavier CPU architecture includes 8 CPU cores organized in
4 clusters. Add cpu-map data for topology initialization, this
fixes the topology information in
/sys/devices/system/cpu/cpu[n]/topology
Signed
To make this simpler, I think it's best to isolate the cache information
in its own patch. So I will amend this patch to include topology
information only.
On 1/31/19 3:29 PM, Bo Yan wrote:
On 1/31/19 2:25 PM, Thierry Reding wrote:
On Thu, Jan 31, 2019 at 10:35:54AM -0800, Bo Yan wrote
The xavier CPU architecture includes 8 CPU cores organized in
4 clusters. Add cpu-map data for topology initialization, this
fixes the topology information in
/sys/devices/system/cpu/cpu[n]/topology
Signed-off-by: Bo Yan
---
V2: remove cache nodes, add topology data only
arch/arm64/boot/dts
The xavier CPU architecture includes 8 CPU cores organized in
4 clusters. Add cpu-map data for topology initialization, add
cache data for cache node creation in sysfs.
Signed-off-by: Bo Yan
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 148 +--
1 file changed, 140
On 1/31/19 2:25 PM, Thierry Reding wrote:
On Thu, Jan 31, 2019 at 10:35:54AM -0800, Bo Yan wrote:
The xavier CPU architecture includes 8 CPU cores organized in
4 clusters. Add cpu-map data for topology initialization, add
cache data for cache node creation in sysfs.
Signed-off-by: Bo Yan
The of_address_to_resource returns 0 if successful. gic_check_eoimode
calls it without checking the return value. This induces Coverity
warning: "Unchecked return value".
Return false from gic_check_eoimode if of_address_to_resource returns
non-0 value.
Signed-off-by: Bo Yan
--
will always return success.
On 07/05/2018 12:13 PM, Marc Zyngier wrote:
Hi Bo,
On Thu, 5 Jul 2018 11:20:59 -0700
Bo Yan wrote:
The of_address_to_resource returns 0 if successful. gic_check_eoimode
calls it without checking the return value. This induces Coverity
warning: "Unchecked r
);
if (!is_hyp_mode_available())
return false;
We are 100% sure of_address_to_resource will succeed in this particular
case, so "(void)" will help suppress Coverity warning.
On 07/05/2018 12:18 PM, Bo Yan wrote:
Marc,
I'm also wondering if of_address_to_resource can r
Hi Robin, Luke,
Recently I bumped into an error when running GCC undefined behavior
sanitizer:
UBSAN: Undefined behaviour in
kernel-4.9/arch/arm64/include/asm/checksum.h:34:6
load of misaligned address ffc198c8b254 for type 'const
__int128 unsigned'
which requires 16 byte
39 matches
Mail list logo
