date:20180828

From: Wanpeng Li 

Dan Carpenter reported that the untrusted data returns from kvm_register_read()
results in the following static checker warning:
  arch/x86/kvm/lapic.c:576 kvm_pv_send_ipi()
  error: buffer underflow 'map->phys_map' 's32min-s32max'

KVM guest can easily trigger this by executing the following assembly sequence 
in Ring0:

mov $10, %rax
mov $0x, %rbx
mov $0x, %rdx
mov $0, %rsi
vmcall

As this will cause KVM to execute the following code-path:
vmx_handle_exit() -> handle_vmcall() -> kvm_emulate_hypercall() -> 
kvm_pv_send_ipi()
which will reach out-of-bounds access.

This patch fixes it by adding a check to kvm_pv_send_ipi() against 
map->max_apic_id 
and also checking whether or not map->phys_map[min + i] is NULL since the 
max_apic_id 
is set according to the max apic id, however, some phys_map maybe NULL when 
apic id 
is sparse, in addition, kvm also unconditionally set max_apic_id to 255 to 
reserve 
enough space for any xAPIC ID.

Reported-by: Dan Carpenter 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Liran Alon 
Cc: Dan Carpenter 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0cefba2..86e933c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long 
ipi_bitmap_low,
rcu_read_lock();
map = rcu_dereference(kvm->arch.apic_map);
 
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_low)) < min))
+   goto out;
/* Bits above cluster_size are masked in the caller.  */
for_each_set_bit(i, _bitmap_low, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
min += cluster_size;
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_high)) < min))
+   goto out;
for_each_set_bit(i, _bitmap_high, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
+out:
rcu_read_unlock();
return count;
 }
-- 
2.7.4

[PATCH] KVM: LAPIC: Fix pv ipis out-of-bounds access

From: Wanpeng Li 

Dan Carpenter reported that the untrusted data returns from kvm_register_read()
results in the following static checker warning:
  arch/x86/kvm/lapic.c:576 kvm_pv_send_ipi()
  error: buffer underflow 'map->phys_map' 's32min-s32max'

KVM guest can easily trigger this by executing the following assembly sequence 
in Ring0:

mov $10, %rax
mov $0x, %rbx
mov $0x, %rdx
mov $0, %rsi
vmcall

As this will cause KVM to execute the following code-path:
vmx_handle_exit() -> handle_vmcall() -> kvm_emulate_hypercall() -> 
kvm_pv_send_ipi()
which will reach out-of-bounds access.

This patch fixes it by adding a check to kvm_pv_send_ipi() against 
map->max_apic_id 
and also checking whether or not map->phys_map[min + i] is NULL since the 
max_apic_id 
is set according to the max apic id, however, some phys_map maybe NULL when 
apic id 
is sparse, in addition, kvm also unconditionally set max_apic_id to 255 to 
reserve 
enough space for any xAPIC ID.

Reported-by: Dan Carpenter 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Liran Alon 
Cc: Dan Carpenter 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0cefba2..86e933c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long 
ipi_bitmap_low,
rcu_read_lock();
map = rcu_dereference(kvm->arch.apic_map);
 
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_low)) < min))
+   goto out;
/* Bits above cluster_size are masked in the caller.  */
for_each_set_bit(i, _bitmap_low, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
min += cluster_size;
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_high)) < min))
+   goto out;
for_each_set_bit(i, _bitmap_high, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
+out:
rcu_read_unlock();
return count;
 }
-- 
2.7.4

[PATCH] KVM: LAPIC: Fix pv ipis out-of-bounds access

From: Wanpeng Li 

Dan Carpenter reported that the untrusted data returns from kvm_register_read()
results in the following static checker warning:
  arch/x86/kvm/lapic.c:576 kvm_pv_send_ipi()
  error: buffer underflow 'map->phys_map' 's32min-s32max'

KVM guest can easily trigger this by executing the following assembly sequence 
in Ring0:

mov $10, %rax
mov $0x, %rbx
mov $0x, %rdx
mov $0, %rsi
vmcall

As this will cause KVM to execute the following code-path:
vmx_handle_exit() -> handle_vmcall() -> kvm_emulate_hypercall() -> 
kvm_pv_send_ipi()
which will reach out-of-bounds access.

This patch fixes it by adding a check to kvm_pv_send_ipi() against 
map->max_apic_id 
and also checking whether or not map->phys_map[min + i] is NULL since the 
max_apic_id 
is set according to the max apic id, however, some phys_map maybe NULL when 
apic id 
is sparse, in addition, kvm also unconditionally set max_apic_id to 255 to 
reserve 
enough space for any xAPIC ID.

Reported-by: Dan Carpenter 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Liran Alon 
Cc: Dan Carpenter 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0cefba2..86e933c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long 
ipi_bitmap_low,
rcu_read_lock();
map = rcu_dereference(kvm->arch.apic_map);
 
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_low)) < min))
+   goto out;
/* Bits above cluster_size are masked in the caller.  */
for_each_set_bit(i, _bitmap_low, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
min += cluster_size;
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_high)) < min))
+   goto out;
for_each_set_bit(i, _bitmap_high, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
+out:
rcu_read_unlock();
return count;
 }
-- 
2.7.4

[PATCH] KVM: LAPIC: Fix pv ipis out-of-bounds access

From: Wanpeng Li 

Dan Carpenter reported that the untrusted data returns from kvm_register_read()
results in the following static checker warning:
  arch/x86/kvm/lapic.c:576 kvm_pv_send_ipi()
  error: buffer underflow 'map->phys_map' 's32min-s32max'

KVM guest can easily trigger this by executing the following assembly sequence 
in Ring0:

mov $10, %rax
mov $0x, %rbx
mov $0x, %rdx
mov $0, %rsi
vmcall

As this will cause KVM to execute the following code-path:
vmx_handle_exit() -> handle_vmcall() -> kvm_emulate_hypercall() -> 
kvm_pv_send_ipi()
which will reach out-of-bounds access.

This patch fixes it by adding a check to kvm_pv_send_ipi() against 
map->max_apic_id 
and also checking whether or not map->phys_map[min + i] is NULL since the 
max_apic_id 
is set according to the max apic id, however, some phys_map maybe NULL when 
apic id 
is sparse, in addition, kvm also unconditionally set max_apic_id to 255 to 
reserve 
enough space for any xAPIC ID.

Reported-by: Dan Carpenter 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Liran Alon 
Cc: Dan Carpenter 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0cefba2..86e933c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -571,18 +571,27 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long 
ipi_bitmap_low,
rcu_read_lock();
map = rcu_dereference(kvm->arch.apic_map);
 
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_low)) < min))
+   goto out;
/* Bits above cluster_size are masked in the caller.  */
for_each_set_bit(i, _bitmap_low, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
min += cluster_size;
+   if (unlikely((s32)(map->max_apic_id - __fls(ipi_bitmap_high)) < min))
+   goto out;
for_each_set_bit(i, _bitmap_high, BITS_PER_LONG) {
-   vcpu = map->phys_map[min + i]->vcpu;
-   count += kvm_apic_set_irq(vcpu, , NULL);
+   if (map->phys_map[min + i]) {
+   vcpu = map->phys_map[min + i]->vcpu;
+   count += kvm_apic_set_irq(vcpu, , NULL);
+   }
}
 
+out:
rcu_read_unlock();
return count;
 }
-- 
2.7.4

[PATCH 2/2] ARM: imx_v6_v7_defconfig: select CONFIG_ARM_CPUIDLE by default

Some i.MX platforms like i.MX7S/D uses generic ARM cpuidle
driver and psci method to support cpuidle feature, select
CONFIG_ARM_CPUIDLE by default for such platforms.

Signed-off-by: Anson Huang 
---
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index e2c1276..65df4b2 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -62,6 +62,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_ARM_IMX6Q_CPUFREQ=y
 CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_BINFMT_MISC=m
-- 
2.7.4

[PATCH 2/2] ARM: imx_v6_v7_defconfig: select CONFIG_ARM_CPUIDLE by default

Some i.MX platforms like i.MX7S/D uses generic ARM cpuidle
driver and psci method to support cpuidle feature, select
CONFIG_ARM_CPUIDLE by default for such platforms.

Signed-off-by: Anson Huang 
---
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index e2c1276..65df4b2 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -62,6 +62,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_ARM_IMX6Q_CPUFREQ=y
 CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_BINFMT_MISC=m
-- 
2.7.4

[PATCH 1/2] ARM: dts: imx7s: enable cpuidle driver

Enable cpuidle for i.MX7S/D using generic ARM cpuidle
driver, below 2 idle states enabled:

1. ARM WFI;
2. SoC WAIT mode.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx7d.dtsi |  1 +
 arch/arm/boot/dts/imx7s.dtsi | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 7cbc2ff..4d0d0f6 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -20,6 +20,7 @@
reg = <1>;
clock-frequency = <99600>;
operating-points-v2 = <_opp_table>;
+   cpu-idle-states = <_SLEEP>;
};
};
 
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 93884ce..cf5570b 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -54,6 +54,19 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   idle-states {
+   entry-method = "psci";
+
+   CPU_SLEEP: WAIT {
+   compatible = "arm,idle-state";
+   arm,psci-suspend-param = <0x001>;
+   local-timer-stop;
+   entry-latency-us = <100>;
+   exit-latency-us = <50>;
+   min-residency-us = <1000>;
+   };
+   };
+
cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
@@ -61,6 +74,7 @@
clock-frequency = <79200>;
clock-latency = <61036>; /* two CLK32 periods */
clocks = < IMX7D_CLK_ARM>;
+   cpu-idle-states = <_SLEEP>;
};
};
 
-- 
2.7.4

[PATCH 1/2] ARM: dts: imx7s: enable cpuidle driver

Enable cpuidle for i.MX7S/D using generic ARM cpuidle
driver, below 2 idle states enabled:

1. ARM WFI;
2. SoC WAIT mode.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx7d.dtsi |  1 +
 arch/arm/boot/dts/imx7s.dtsi | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 7cbc2ff..4d0d0f6 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -20,6 +20,7 @@
reg = <1>;
clock-frequency = <99600>;
operating-points-v2 = <_opp_table>;
+   cpu-idle-states = <_SLEEP>;
};
};
 
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 93884ce..cf5570b 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -54,6 +54,19 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   idle-states {
+   entry-method = "psci";
+
+   CPU_SLEEP: WAIT {
+   compatible = "arm,idle-state";
+   arm,psci-suspend-param = <0x001>;
+   local-timer-stop;
+   entry-latency-us = <100>;
+   exit-latency-us = <50>;
+   min-residency-us = <1000>;
+   };
+   };
+
cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
@@ -61,6 +74,7 @@
clock-frequency = <79200>;
clock-latency = <61036>; /* two CLK32 periods */
clocks = < IMX7D_CLK_ARM>;
+   cpu-idle-states = <_SLEEP>;
};
};
 
-- 
2.7.4

Re: [PATCH v2 1/4] genirq: Provide basic NMI management for interrupt lines

Hi Julien,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc1 next-20180828]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Julien-Thierry/genirq-Provide-basic-NMI-management-for-interrupt-lines/20180829-063713
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
>> kernel/irq/manage.c:2080: warning: Function parameter or member 'irqflags' 
>> not described in 'request_nmi'
   kernel/irq/manage.c:2080: warning: Excess function parameter 'flags' 
description in 'request_nmi'
   kernel/irq/manage.c:2081: warning: Excess function parameter 'flags' 
description in 'request_nmi'
   include/linux/srcu.h:175: warning: Function parameter or member 'p' not 
described in 'srcu_dereference_notrace'
   include/linux/srcu.h:175: warning: Function parameter or member 'sp' not 
described in 'srcu_dereference_notrace'
   include/linux/gfp.h:1: warning: no structured comments found
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.ibss' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.connect' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.keys' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ie' 
not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.ie_len' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.bssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.ssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.default_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.default_mgmt_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.prev_bssid_valid' not described in 'wireless_dev'
   include/net/mac80211.h:2328: warning: Function parameter or member 
'radiotap_timestamp.units_pos' not described in 'ieee80211_hw'
   include/net/mac80211.h:2328: warning: Function parameter or member 
'radiotap_timestamp.accuracy' not described in 'ieee80211_hw'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.rates' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.use_rts' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.use_cts_prot' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.short_preamble' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.skip_table' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.jiffies' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.vif' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.hw_key' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.flags' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.enqueue_time' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 'ack' not 
described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'ack.cookie' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.rates' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.ack_signal' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.ampdu_ack_len' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.ampdu_len' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.antenna' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or membe

Re: [PATCH v2 1/4] genirq: Provide basic NMI management for interrupt lines

Hi Julien,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc1 next-20180828]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Julien-Thierry/genirq-Provide-basic-NMI-management-for-interrupt-lines/20180829-063713
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
>> kernel/irq/manage.c:2080: warning: Function parameter or member 'irqflags' 
>> not described in 'request_nmi'
   kernel/irq/manage.c:2080: warning: Excess function parameter 'flags' 
description in 'request_nmi'
   kernel/irq/manage.c:2081: warning: Excess function parameter 'flags' 
description in 'request_nmi'
   include/linux/srcu.h:175: warning: Function parameter or member 'p' not 
described in 'srcu_dereference_notrace'
   include/linux/srcu.h:175: warning: Function parameter or member 'sp' not 
described in 'srcu_dereference_notrace'
   include/linux/gfp.h:1: warning: no structured comments found
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.ibss' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.connect' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.keys' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ie' 
not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.ie_len' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.bssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.ssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.default_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.default_mgmt_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4381: warning: Function parameter or member 
'wext.prev_bssid_valid' not described in 'wireless_dev'
   include/net/mac80211.h:2328: warning: Function parameter or member 
'radiotap_timestamp.units_pos' not described in 'ieee80211_hw'
   include/net/mac80211.h:2328: warning: Function parameter or member 
'radiotap_timestamp.accuracy' not described in 'ieee80211_hw'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.rates' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.use_rts' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.use_cts_prot' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.short_preamble' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.skip_table' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.jiffies' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.vif' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.hw_key' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.flags' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'control.enqueue_time' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 'ack' not 
described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'ack.cookie' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.rates' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.ack_signal' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.ampdu_ack_len' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.ampdu_len' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or member 
'status.antenna' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:977: warning: Function parameter or membe

Re: [PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()

2018-08-28 Thread Sergey Senozhatsky

Hi,

Cc-ing Benjamin on this.

On (08/29/18 03:23), Dmitry Safonov wrote:
> BUG: unable to handle kernel paging request at 2260
> IP: [..] n_tty_receive_buf_common+0x5f/0x86d
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
>  [..] n_tty_receive_buf2
>  [..] tty_ldisc_receive_buf
>  [..] flush_to_ldisc
>  [..] process_one_work
>  [..] worker_thread
>  [..] kthread
>  [..] ret_from_fork

Seems that you are not the first one to hit this NULL deref.

> I think, tty_ldisc_reinit() should be called with ldisc_sem hold for
> writing, which will protect any reader against line discipline changes.

Per https://lore.kernel.org/patchwork/patch/777220/

: Note that we noticed one path that called reinit without the ldisc lock
: held for writing, we added that, but it didn't fix the problem.

And I guess that Ben meant the same reinit path which you patched:

> @@ -1267,15 +1267,20 @@ static int tty_reopen(struct tty_struct *tty)
>   if (test_bit(TTY_EXCLUSIVE, >flags) && !capable(CAP_SYS_ADMIN))
>   return -EBUSY;
>  
> - tty->count++;
> + retval = tty_ldisc_lock(tty, 5 * HZ);
> + if (retval)
> + return retval;
>  
> + tty->count++;
>   if (tty->ldisc)
> - return 0;
> + goto out_unlock;
>  
>   retval = tty_ldisc_reinit(tty, tty->termios.c_line);
>   if (retval)
>   tty->count--;
>  
> +out_unlock:
> + tty_ldisc_unlock(tty);
>   return retval;
>  }

-ss

Re: [PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()

2018-08-28 Thread Sergey Senozhatsky

Hi,

Cc-ing Benjamin on this.

On (08/29/18 03:23), Dmitry Safonov wrote:
> BUG: unable to handle kernel paging request at 2260
> IP: [..] n_tty_receive_buf_common+0x5f/0x86d
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
>  [..] n_tty_receive_buf2
>  [..] tty_ldisc_receive_buf
>  [..] flush_to_ldisc
>  [..] process_one_work
>  [..] worker_thread
>  [..] kthread
>  [..] ret_from_fork

Seems that you are not the first one to hit this NULL deref.

> I think, tty_ldisc_reinit() should be called with ldisc_sem hold for
> writing, which will protect any reader against line discipline changes.

Per https://lore.kernel.org/patchwork/patch/777220/

: Note that we noticed one path that called reinit without the ldisc lock
: held for writing, we added that, but it didn't fix the problem.

And I guess that Ben meant the same reinit path which you patched:

> @@ -1267,15 +1267,20 @@ static int tty_reopen(struct tty_struct *tty)
>   if (test_bit(TTY_EXCLUSIVE, >flags) && !capable(CAP_SYS_ADMIN))
>   return -EBUSY;
>  
> - tty->count++;
> + retval = tty_ldisc_lock(tty, 5 * HZ);
> + if (retval)
> + return retval;
>  
> + tty->count++;
>   if (tty->ldisc)
> - return 0;
> + goto out_unlock;
>  
>   retval = tty_ldisc_reinit(tty, tty->termios.c_line);
>   if (retval)
>   tty->count--;
>  
> +out_unlock:
> + tty_ldisc_unlock(tty);
>   return retval;
>  }

-ss

Re: [PATCH] clk: x86: Set default parent to 48Mhz

2018-08-28 Thread Agrawal, Akshu




On 8/29/2018 3:59 AM, Stephen Boyd wrote:
> Quoting Akshu Agrawal (2018-08-20 23:51:57)
>> System clk provided in ST soc can be set to:
>> 48Mhz, non-spread
>> 25Mhz, spread
>> To get accurate rate, we need it to set it at non-spread
>> option which is 48Mhz.
>>
>> Signed-off-by: Akshu Agrawal 
> 
> Does this need to go to 4.18 stable trees? I don't see a fixes tag so
> I'm trying to understand merge priority of this patch.
> 
Yes, and its a fix, as it fixes the in accuracy in the bclk which is
derived from this clk.

Thanks,
Akshu

Re: [PATCH] clk: x86: Set default parent to 48Mhz

2018-08-28 Thread Agrawal, Akshu




On 8/29/2018 3:59 AM, Stephen Boyd wrote:
> Quoting Akshu Agrawal (2018-08-20 23:51:57)
>> System clk provided in ST soc can be set to:
>> 48Mhz, non-spread
>> 25Mhz, spread
>> To get accurate rate, we need it to set it at non-spread
>> option which is 48Mhz.
>>
>> Signed-off-by: Akshu Agrawal 
> 
> Does this need to go to 4.18 stable trees? I don't see a fixes tag so
> I'm trying to understand merge priority of this patch.
> 
Yes, and its a fix, as it fixes the in accuracy in the bclk which is
derived from this clk.

Thanks,
Akshu

Re: [PATCH] cpuidle: menu: Retain tick when shallow state is selected

2018-08-28 Thread Rafael J. Wysocki

On Sunday, August 26, 2018 9:37:09 PM CEST Doug Smythies wrote:
> On 2018.08.25 04:22 Rafael J. Wysocki wrote:
> > On Fri, Aug 24, 2018 at 5:52 PM Doug Smythies  wrote:
> >> On 2018.08.24 02:44 Rafael J. Wysocki wrote:
> >>> On Tuesday, August 21, 2018 10:44:10 AM CEST Rafael J. Wysocki wrote:
>  From: Rafael J. Wysocki 
> 
>  The case addressed by commit 5ef499cd571c (cpuidle: menu: Handle
>  stopped tick more aggressively) in the stopped tick case is present
>  when the tick has not been stopped yet too.
> >>
> >> ... [snip] ...
> >>
>  Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with 
>  stopped tick)
> >>
> >> ... [snip] ...
> >>
> >>> Due to the lack of objections, I'm inclined to queue this up.
> >>
> >> I have been following these threads.
> >> Recall that I was involved, over a period of months, in the original
> >> "powernightmare" stuff.
> >> I have revived my tests (and wish I had left myself better notes), and
> >> am establishing a baseline before adding and trying this patch.
> >> My baseline is actually two tests with and without the previous two 
> >> patches (the ones
> >> that were just sent a couple of days ago in "More power management updates 
> >> for v4.19-rc1".
> >> I might have those results in some presentable form by later today (it 
> >> looks O.K.)
> >> Results with this patch will take another couple of days.
> >
> > Thanks Doug, much appreciated!
> 
> Test 1: A Thomas Ilsche type "powernightmare" test:
> (forever ((10 times - variable usec sleep) 0.999 seconds sleep) X 40 
> staggered threads.
> Where the "variable" was from 0.05 to 5 in steps of 0.05, for the first ~200 
> minutes of the test.
> (note: overheads mean that actual loop times are quite different.)
> And then from 5 to 500 in steps of 1, for the remaining 1000 minutes of the 
> test.
> Each step ran for 2 minutes. The system was idle for 1 minute at the start, 
> and a few
> minutes at the end of the graphs.
> While called "kernel 4.18", the baseline was actually from mainline at head = 
> df2def4,
> or just after Rafael's linux-pm "pm-4.19-rc1-2" merge.
> (actually after the next acpi merge).
> Reference kernel = df2def4 with the two patches reverted.
> 
> Test 1.1 compares baseline reference and the two patches added.
> Summary: Nothing of note.
> Results: http://fast.smythies.com/linux-pm/k418-pn-sweep.htm 
> Differences: http://fast.smythies.com/linux-pm/k418-pn-sweep-differences.htm
> Note: the title in the last graph in each link above is mislabelled.
> 
> Test 1.2 compares baseline reference and the three patches added (the two at 
> df2def4 plus the one of this thread).
> Summary: Nothing of note.
> Results: http://fast.smythies.com/linux-pm/k418-pn-sweep-rjw.htm
> Differences: 
> http://fast.smythies.com/linux-pm/k418-pn-sweep-rjw-differences.htm
> 
> Side note: There is an interesting, slight, power bump at about the 
> 260 minute point of the tests. Perhaps for further investigation some other 
> day.
> 
> Test 2: pipe test 2 CPUs, one core. CPU test.
> 
> Recall this was one of the more interesting tests with the original 
> "powernightmare"
> work, and in the end, back then, both energy was saved and performance 
> improved.
> 
> The average loop times graph is here:
> http://fast.smythies.com/linux-pm/k418-rjw-pipe-1core.png
> with the average loop times:
> Baseline: 4.83 uSec
> + 2 rjw patches:  4.69 uSec
> + 3 rjw patches:  4.80 uSec
> 
> The power and idle statistics graphs are here:
> http://fast.smythies.com/linux-pm/k418-rjw-pipe-1core.htm
> 
> Test 3: 100% load on CPU 7 test.
> 
> Recall this was another of the more interesting tests last time, but
> had more to do with idle state 0 than anything else.
> 
> The performance seems to stay within a 1% window, with the 3 patches
> being about 1% faster than the 2 patches and the baseline somewhere
> in the middle.
> 
> The power and idle statistics graphs are here:
> http://fast.smythies.com/linux-pm/k418-rjw-100.htm
> 
> From observing at the test 2 and test 3 results, it looks as
> though there are indeed "powernightmares" in the baseline kernel.
> This was not the situation at the end of the original work, 
> "V9" for anybody that recalls. I don't know when they got
> re-introduced, and didn't look.
> 
> While these don't add up to much extra energy for my processor,
> they might be more significant for other processors.
> 
> I revived my "powernightmare" trace post processor assessment
> program, and re-did some 100% Single load tests (20 minute trace):
> (recall that the "is it a 'powernigthmare' or not" threshold
> is rather arbitrary [1]. However, and for what is being done here,
> it should be greater than a tick time, which it is for my 1000Hz
> kernel.)
> 
> 1.) Reference or baseline kernel:
> 
> Idle State 0: Total Entries: 458 : PowerNightmares: 0 : Not PN time 
> (seconds): 0.016160 : PN time: 0.00 : Ratio: 0.00
> Idle State 1: Total Entries: 950 :

Re: [PATCH] cpuidle: menu: Retain tick when shallow state is selected

2018-08-28 Thread Rafael J. Wysocki

On Sunday, August 26, 2018 9:37:09 PM CEST Doug Smythies wrote:
> On 2018.08.25 04:22 Rafael J. Wysocki wrote:
> > On Fri, Aug 24, 2018 at 5:52 PM Doug Smythies  wrote:
> >> On 2018.08.24 02:44 Rafael J. Wysocki wrote:
> >>> On Tuesday, August 21, 2018 10:44:10 AM CEST Rafael J. Wysocki wrote:
>  From: Rafael J. Wysocki 
> 
>  The case addressed by commit 5ef499cd571c (cpuidle: menu: Handle
>  stopped tick more aggressively) in the stopped tick case is present
>  when the tick has not been stopped yet too.
> >>
> >> ... [snip] ...
> >>
>  Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with 
>  stopped tick)
> >>
> >> ... [snip] ...
> >>
> >>> Due to the lack of objections, I'm inclined to queue this up.
> >>
> >> I have been following these threads.
> >> Recall that I was involved, over a period of months, in the original
> >> "powernightmare" stuff.
> >> I have revived my tests (and wish I had left myself better notes), and
> >> am establishing a baseline before adding and trying this patch.
> >> My baseline is actually two tests with and without the previous two 
> >> patches (the ones
> >> that were just sent a couple of days ago in "More power management updates 
> >> for v4.19-rc1".
> >> I might have those results in some presentable form by later today (it 
> >> looks O.K.)
> >> Results with this patch will take another couple of days.
> >
> > Thanks Doug, much appreciated!
> 
> Test 1: A Thomas Ilsche type "powernightmare" test:
> (forever ((10 times - variable usec sleep) 0.999 seconds sleep) X 40 
> staggered threads.
> Where the "variable" was from 0.05 to 5 in steps of 0.05, for the first ~200 
> minutes of the test.
> (note: overheads mean that actual loop times are quite different.)
> And then from 5 to 500 in steps of 1, for the remaining 1000 minutes of the 
> test.
> Each step ran for 2 minutes. The system was idle for 1 minute at the start, 
> and a few
> minutes at the end of the graphs.
> While called "kernel 4.18", the baseline was actually from mainline at head = 
> df2def4,
> or just after Rafael's linux-pm "pm-4.19-rc1-2" merge.
> (actually after the next acpi merge).
> Reference kernel = df2def4 with the two patches reverted.
> 
> Test 1.1 compares baseline reference and the two patches added.
> Summary: Nothing of note.
> Results: http://fast.smythies.com/linux-pm/k418-pn-sweep.htm 
> Differences: http://fast.smythies.com/linux-pm/k418-pn-sweep-differences.htm
> Note: the title in the last graph in each link above is mislabelled.
> 
> Test 1.2 compares baseline reference and the three patches added (the two at 
> df2def4 plus the one of this thread).
> Summary: Nothing of note.
> Results: http://fast.smythies.com/linux-pm/k418-pn-sweep-rjw.htm
> Differences: 
> http://fast.smythies.com/linux-pm/k418-pn-sweep-rjw-differences.htm
> 
> Side note: There is an interesting, slight, power bump at about the 
> 260 minute point of the tests. Perhaps for further investigation some other 
> day.
> 
> Test 2: pipe test 2 CPUs, one core. CPU test.
> 
> Recall this was one of the more interesting tests with the original 
> "powernightmare"
> work, and in the end, back then, both energy was saved and performance 
> improved.
> 
> The average loop times graph is here:
> http://fast.smythies.com/linux-pm/k418-rjw-pipe-1core.png
> with the average loop times:
> Baseline: 4.83 uSec
> + 2 rjw patches:  4.69 uSec
> + 3 rjw patches:  4.80 uSec
> 
> The power and idle statistics graphs are here:
> http://fast.smythies.com/linux-pm/k418-rjw-pipe-1core.htm
> 
> Test 3: 100% load on CPU 7 test.
> 
> Recall this was another of the more interesting tests last time, but
> had more to do with idle state 0 than anything else.
> 
> The performance seems to stay within a 1% window, with the 3 patches
> being about 1% faster than the 2 patches and the baseline somewhere
> in the middle.
> 
> The power and idle statistics graphs are here:
> http://fast.smythies.com/linux-pm/k418-rjw-100.htm
> 
> From observing at the test 2 and test 3 results, it looks as
> though there are indeed "powernightmares" in the baseline kernel.
> This was not the situation at the end of the original work, 
> "V9" for anybody that recalls. I don't know when they got
> re-introduced, and didn't look.
> 
> While these don't add up to much extra energy for my processor,
> they might be more significant for other processors.
> 
> I revived my "powernightmare" trace post processor assessment
> program, and re-did some 100% Single load tests (20 minute trace):
> (recall that the "is it a 'powernigthmare' or not" threshold
> is rather arbitrary [1]. However, and for what is being done here,
> it should be greater than a tick time, which it is for my 1000Hz
> kernel.)
> 
> 1.) Reference or baseline kernel:
> 
> Idle State 0: Total Entries: 458 : PowerNightmares: 0 : Not PN time 
> (seconds): 0.016160 : PN time: 0.00 : Ratio: 0.00
> Idle State 1: Total Entries: 950 :

[PATCH] proc/kcore: fix invalid memory access in multi-page read optimization

2018-08-28 Thread Dominique Martinet

The 'm' kcore_list item can point to kclist_head, and it is incorrect to
look at m->addr / m->size in this case.
There is no choice but to run through the list of entries for every address
if we did not find any entry in the previous iteration

Fixes: bf991c2231117 ("proc/kcore: optimize multiple page reads")
Signed-off-by: Dominique Martinet 
---

I guess now I'm looking at bf991c2231117 again that it would be slightly
more efficient to remove the !m check and initialize m to point to
kclist_head like this:
 m = list_entry(_head, struct kcore_list, list);
but it feels a bit forced to me; deferring the choice to others.

 fs/proc/kcore.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index ad72261ee3fe..50036f6e1f52 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -451,7 +451,8 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
 * If this is the first iteration or the address is not within
 * the previous entry, search for a matching entry.
 */
-   if (!m || start < m->addr || start >= m->addr + m->size) {
+   if (!m || >list == _head || start < m->addr ||
+   start >= m->addr + m->size) {
list_for_each_entry(m, _head, list) {
if (start >= m->addr &&
start < m->addr + m->size)
-- 
2.17.1

[PATCH] proc/kcore: fix invalid memory access in multi-page read optimization

2018-08-28 Thread Dominique Martinet

The 'm' kcore_list item can point to kclist_head, and it is incorrect to
look at m->addr / m->size in this case.
There is no choice but to run through the list of entries for every address
if we did not find any entry in the previous iteration

Fixes: bf991c2231117 ("proc/kcore: optimize multiple page reads")
Signed-off-by: Dominique Martinet 
---

I guess now I'm looking at bf991c2231117 again that it would be slightly
more efficient to remove the !m check and initialize m to point to
kclist_head like this:
 m = list_entry(_head, struct kcore_list, list);
but it feels a bit forced to me; deferring the choice to others.

 fs/proc/kcore.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index ad72261ee3fe..50036f6e1f52 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -451,7 +451,8 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
 * If this is the first iteration or the address is not within
 * the previous entry, search for a matching entry.
 */
-   if (!m || start < m->addr || start >= m->addr + m->size) {
+   if (!m || >list == _head || start < m->addr ||
+   start >= m->addr + m->size) {
list_for_each_entry(m, _head, list) {
if (start >= m->addr &&
start < m->addr + m->size)
-- 
2.17.1

Re: [PATCH 3/3] dmaengine: xilinx_dma: Fix 64-bit simple CDMA transfer

2018-08-28 Thread Vinod

On 28-08-18, 14:03, Radhey Shyam Pandey wrote:
> > On 27-07-18, 16:20, Radhey Shyam Pandey wrote:
> > > In AXI CDMA simple mode also pass MSB bits of source and destination
> > > address to xilinx_write function. This fixes simple CDMA operation
> > > mode using 64-bit addressing.
> > >
> > > Signed-off-by: Radhey Shyam Pandey 
> > > Signed-off-by: Michal Simek 
> > > ---
> > >  drivers/dma/xilinx/xilinx_dma.c |6 --
> > >  1 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/dma/xilinx/xilinx_dma.c 
> > > b/drivers/dma/xilinx/xilinx_dma.c
> > > index a37871e..2e15d86 100644
> > > --- a/drivers/dma/xilinx/xilinx_dma.c
> > > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > > @@ -1245,8 +1245,10 @@ static void xilinx_cdma_start_transfer(struct
> > xilinx_dma_chan *chan)
> > >
> > >   hw = >hw;
> > >
> > > - xilinx_write(chan, XILINX_CDMA_REG_SRCADDR, hw-
> > >src_addr);
> > > - xilinx_write(chan, XILINX_CDMA_REG_DSTADDR, hw-
> > >dest_addr);
> > > + xilinx_write(chan, XILINX_CDMA_REG_SRCADDR,
> > (dma_addr_t)
> > > +  ((u64)hw->src_addr_msb << 32 | hw->src_addr));
> > 
> > so this is:
> > (dma_addr_t)((u64)hw->src_addr_msb << 32 | hw->src_addr)
> > 
> > what is src_addr data type? I think its u32. It would be better to
> > update xilinx_write() to take u64 and not dma_addr_t.
> 
> Yes, src_addr_msb and src_addr BD fields are u32. To explain: There is no
> prob in xilinx_write it takes dma_addr_t as an arg which is 32/64 bit 
> depending on _DMA_ADDR_T_64BIT. In 64bit CDMA transfer, there was a bug
> i.e in the call to xilinx_write src_addr_msb 32 bits were not passed. To fix
> that combine MSB and LSB 32 bits before passing it to xilinx_write.

Yeah that part was clear but the implementation can be better..

-- 
~Vinod

Re: [PATCH 3/3] dmaengine: xilinx_dma: Fix 64-bit simple CDMA transfer

2018-08-28 Thread Vinod

On 28-08-18, 14:03, Radhey Shyam Pandey wrote:
> > On 27-07-18, 16:20, Radhey Shyam Pandey wrote:
> > > In AXI CDMA simple mode also pass MSB bits of source and destination
> > > address to xilinx_write function. This fixes simple CDMA operation
> > > mode using 64-bit addressing.
> > >
> > > Signed-off-by: Radhey Shyam Pandey 
> > > Signed-off-by: Michal Simek 
> > > ---
> > >  drivers/dma/xilinx/xilinx_dma.c |6 --
> > >  1 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/dma/xilinx/xilinx_dma.c 
> > > b/drivers/dma/xilinx/xilinx_dma.c
> > > index a37871e..2e15d86 100644
> > > --- a/drivers/dma/xilinx/xilinx_dma.c
> > > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > > @@ -1245,8 +1245,10 @@ static void xilinx_cdma_start_transfer(struct
> > xilinx_dma_chan *chan)
> > >
> > >   hw = >hw;
> > >
> > > - xilinx_write(chan, XILINX_CDMA_REG_SRCADDR, hw-
> > >src_addr);
> > > - xilinx_write(chan, XILINX_CDMA_REG_DSTADDR, hw-
> > >dest_addr);
> > > + xilinx_write(chan, XILINX_CDMA_REG_SRCADDR,
> > (dma_addr_t)
> > > +  ((u64)hw->src_addr_msb << 32 | hw->src_addr));
> > 
> > so this is:
> > (dma_addr_t)((u64)hw->src_addr_msb << 32 | hw->src_addr)
> > 
> > what is src_addr data type? I think its u32. It would be better to
> > update xilinx_write() to take u64 and not dma_addr_t.
> 
> Yes, src_addr_msb and src_addr BD fields are u32. To explain: There is no
> prob in xilinx_write it takes dma_addr_t as an arg which is 32/64 bit 
> depending on _DMA_ADDR_T_64BIT. In 64bit CDMA transfer, there was a bug
> i.e in the call to xilinx_write src_addr_msb 32 bits were not passed. To fix
> that combine MSB and LSB 32 bits before passing it to xilinx_write.

Yeah that part was clear but the implementation can be better..

-- 
~Vinod

Re: [PATCH v2] x86/nmi: Fix some races in NMI uaccess

On Tue, Aug 28, 2018 at 10:56 AM, Rik van Riel  wrote:
> On Mon, 27 Aug 2018 16:04:16 -0700
> Andy Lutomirski  wrote:
>
>> The 0day bot is still chewing on this, but I've tested it a bit locally
>> and it seems to do the right thing.
>
> Hi Andy,
>
> the version of the patch below should fix the bug we talked about
> in email yesterday.  It should automatically cover kernel threads
> in lazy TLB mode, because current->mm will be NULL, while the
> cpu_tlbstate.loaded_mm should never be NULL.
>

That's better than mine.  I tweaked it a bit and added some debugging,
and I got this:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes=dd956eba16646fd0b15c3c0741269dfd84452dac

I made the loaded_mm handling a little more conservative to make it
more obvious that switch_mm_irqs_off() is safe regardless of exactly
when it gets called relative to switching current.

Re: [PATCH v2] x86/nmi: Fix some races in NMI uaccess

On Tue, Aug 28, 2018 at 10:56 AM, Rik van Riel  wrote:
> On Mon, 27 Aug 2018 16:04:16 -0700
> Andy Lutomirski  wrote:
>
>> The 0day bot is still chewing on this, but I've tested it a bit locally
>> and it seems to do the right thing.
>
> Hi Andy,
>
> the version of the patch below should fix the bug we talked about
> in email yesterday.  It should automatically cover kernel threads
> in lazy TLB mode, because current->mm will be NULL, while the
> cpu_tlbstate.loaded_mm should never be NULL.
>

That's better than mine.  I tweaked it a bit and added some debugging,
and I got this:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes=dd956eba16646fd0b15c3c0741269dfd84452dac

I made the loaded_mm handling a little more conservative to make it
more obvious that switch_mm_irqs_off() is safe regardless of exactly
when it gets called relative to switching current.

Re: Flushing user entries for kernel mappings in x86

On Tue, Aug 28, 2018 at 6:46 PM, Nadav Amit  wrote:
> Hello Andy,
>
> Is there a reason for __flush_tlb_one_kernel() to flush the PTE not only in
> the kernel address space, but also in the user one (as part of
> __flush_tlb_one_user)? [ I obviously regard the case when PTI is on ].

In most cases, probably not, but it's fairly cheap, I think.  And it
makes it so that we're okay if the TLB entry we're flushing is used by
the entry code.

Re: Flushing user entries for kernel mappings in x86

On Tue, Aug 28, 2018 at 6:46 PM, Nadav Amit  wrote:
> Hello Andy,
>
> Is there a reason for __flush_tlb_one_kernel() to flush the PTE not only in
> the kernel address space, but also in the user one (as part of
> __flush_tlb_one_user)? [ I obviously regard the case when PTI is on ].

In most cases, probably not, but it's fairly cheap, I think.  And it
makes it so that we're okay if the TLB entry we're flushing is used by
the entry code.

linux-next: Tree for Aug 29

2018-08-28 Thread Stephen Rothwell

Hi all,

Changes since 20180828:

Removed tree: libata (merged into the block tree)

Dropped trees: xarray, ida (temporarily)

The spi tree gained a build failure so I used the version from
next-20180828.

Non-merge commits (relative to Linus' tree): 875
 1002 files changed, 29529 insertions(+), 9144 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 284 trees (counting Linus' and 65 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (050cdc6c9501 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (ad1d69735878 Merge tag 'fuse-update-4.19' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse)
Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma())
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper 
PAGE_SHIFT bits in pfn_valid())
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (53ae914d898e net/rds: Use rdma_read_gids to get connection 
SGID/DGID in IPv6)
Merging bpf/master (501ca81760c2 bpf: sockmap, decrement copied count correctly 
in redirect error case)
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (10568f6c5761 netfilter: xt_checksum: ignore gso skbs)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to 
get connection SGID/DGID in IPv6)
Merging mac80211/master (b88d26d97c41 nl80211: Pass center frequency in kHz 
instead of MHz)
Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1)
Merging sound-current/for-linus (8a328ac1f9eb ALSA: hda/realtek - Fix HP 
Headset Mic can't record)
Merging sound-asoc-fixes/for-linus (cc276126e1bf Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging regulator-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging spi-fixes/for-linus (5223c9c1cbfc spi: spi-fsl-dspi: fix broken 
DSPI_EOQ_MODE)
Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1)
Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: 
fix array underflow in completion handler)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for 
s

linux-next: Tree for Aug 29

2018-08-28 Thread Stephen Rothwell

Hi all,

Changes since 20180828:

Removed tree: libata (merged into the block tree)

Dropped trees: xarray, ida (temporarily)

The spi tree gained a build failure so I used the version from
next-20180828.

Non-merge commits (relative to Linus' tree): 875
 1002 files changed, 29529 insertions(+), 9144 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 284 trees (counting Linus' and 65 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (050cdc6c9501 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (ad1d69735878 Merge tag 'fuse-update-4.19' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse)
Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma())
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper 
PAGE_SHIFT bits in pfn_valid())
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (53ae914d898e net/rds: Use rdma_read_gids to get connection 
SGID/DGID in IPv6)
Merging bpf/master (501ca81760c2 bpf: sockmap, decrement copied count correctly 
in redirect error case)
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (10568f6c5761 netfilter: xt_checksum: ignore gso skbs)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to 
get connection SGID/DGID in IPv6)
Merging mac80211/master (b88d26d97c41 nl80211: Pass center frequency in kHz 
instead of MHz)
Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1)
Merging sound-current/for-linus (8a328ac1f9eb ALSA: hda/realtek - Fix HP 
Headset Mic can't record)
Merging sound-asoc-fixes/for-linus (cc276126e1bf Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging regulator-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging spi-fixes/for-linus (5223c9c1cbfc spi: spi-fsl-dspi: fix broken 
DSPI_EOQ_MODE)
Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1)
Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1)
Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: 
fix array underflow in completion handler)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for 
s

[PATCH v2] arm64: dts: ls1043a: Add configure-gfladj property to USB3 node

2018-08-28 Thread Yinbo Zhu

From: Rajesh Bhagat 

Add "configure-gfladj" boolean property to USB3 node. This property
is used to determine whether frame length adjustment is required or
not

Signed-off-by: Rajesh Bhagat 
Signed-off-by: Ran Wang 
Signed-off-by: Yinbo Zhu 
---
Change in v2:
Modified some word misspellings in commit information

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 7881e3d..ed3fa79 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -609,6 +609,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   configure-gfladj;
};
 
usb1: usb3@300 {
@@ -618,6 +619,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   configure-gfladj;
};
 
usb2: usb3@310 {
@@ -627,6 +629,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   configure-gfladj;
};
 
sata: sata@320 {
-- 
1.7.1

[PATCH v2] arm64: dts: ls1043a: Add configure-gfladj property to USB3 node

2018-08-28 Thread Yinbo Zhu

From: Rajesh Bhagat 

Add "configure-gfladj" boolean property to USB3 node. This property
is used to determine whether frame length adjustment is required or
not

Signed-off-by: Rajesh Bhagat 
Signed-off-by: Ran Wang 
Signed-off-by: Yinbo Zhu 
---
Change in v2:
Modified some word misspellings in commit information

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 7881e3d..ed3fa79 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -609,6 +609,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   configure-gfladj;
};
 
usb1: usb3@300 {
@@ -618,6 +619,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   configure-gfladj;
};
 
usb2: usb3@310 {
@@ -627,6 +629,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+   configure-gfladj;
};
 
sata: sata@320 {
-- 
1.7.1

Re: [PATCH v2 4/4] irqdesc: Add domain handler for NMIs

Hi Julien,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc1 next-20180828]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Julien-Thierry/genirq-Provide-basic-NMI-management-for-interrupt-lines/20180829-063713
config: arm-nuc960_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   kernel/irq/irqdesc.c: In function 'handle_domain_nmi':
>> kernel/irq/irqdesc.c:686:8: error: implicit declaration of function 
>> 'irq_find_mapping'; did you mean 'irq_dispose_mapping'? 
>> [-Werror=implicit-function-declaration]
 irq = irq_find_mapping(domain, hwirq);
   ^~~~
   irq_dispose_mapping
   cc1: some warnings being treated as errors

vim +686 kernel/irq/irqdesc.c

   668  
   669  /**
   670   * handle_domain_nmi - Invoke the handler for a HW irq belonging to a 
domain
   671   * @domain: The domain where to perform the lookup
   672   * @hwirq:  The HW irq number to convert to a logical one
   673   * @regs:   Register file coming from the low-level handling code
   674   *
   675   * Returns: 0 on success, or -EINVAL if conversion has failed
   676   */
   677  int handle_domain_nmi(struct irq_domain *domain, unsigned int hwirq,
   678struct pt_regs *regs)
   679  {
   680  struct pt_regs *old_regs = set_irq_regs(regs);
   681  unsigned int irq;
   682  int ret = 0;
   683  
   684  nmi_enter();
   685  
 > 686  irq = irq_find_mapping(domain, hwirq);
   687  
   688  /*
   689   * ack_bad_irq is not NMI-safe, just report
   690   * an invalid interrupt.
   691   */
   692  if (likely(irq))
   693  generic_handle_irq(irq);
   694  else
   695  ret = -EINVAL;
   696  
   697  nmi_exit();
   698  set_irq_regs(old_regs);
   699  return ret;
   700  }
   701  #endif
   702  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 4/4] irqdesc: Add domain handler for NMIs

Hi Julien,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc1 next-20180828]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Julien-Thierry/genirq-Provide-basic-NMI-management-for-interrupt-lines/20180829-063713
config: arm-nuc960_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   kernel/irq/irqdesc.c: In function 'handle_domain_nmi':
>> kernel/irq/irqdesc.c:686:8: error: implicit declaration of function 
>> 'irq_find_mapping'; did you mean 'irq_dispose_mapping'? 
>> [-Werror=implicit-function-declaration]
 irq = irq_find_mapping(domain, hwirq);
   ^~~~
   irq_dispose_mapping
   cc1: some warnings being treated as errors

vim +686 kernel/irq/irqdesc.c

   668  
   669  /**
   670   * handle_domain_nmi - Invoke the handler for a HW irq belonging to a 
domain
   671   * @domain: The domain where to perform the lookup
   672   * @hwirq:  The HW irq number to convert to a logical one
   673   * @regs:   Register file coming from the low-level handling code
   674   *
   675   * Returns: 0 on success, or -EINVAL if conversion has failed
   676   */
   677  int handle_domain_nmi(struct irq_domain *domain, unsigned int hwirq,
   678struct pt_regs *regs)
   679  {
   680  struct pt_regs *old_regs = set_irq_regs(regs);
   681  unsigned int irq;
   682  int ret = 0;
   683  
   684  nmi_enter();
   685  
 > 686  irq = irq_find_mapping(domain, hwirq);
   687  
   688  /*
   689   * ack_bad_irq is not NMI-safe, just report
   690   * an invalid interrupt.
   691   */
   692  if (likely(irq))
   693  generic_handle_irq(irq);
   694  else
   695  ret = -EINVAL;
   696  
   697  nmi_exit();
   698  set_irq_regs(old_regs);
   699  return ret;
   700  }
   701  #endif
   702  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] arm64: dts: rockchip: perfection vop property define for px30

2018-08-28 Thread Sandy Huang

Add display ports for display-subsystem and add reset property
for vop node, if missing this two define, drm driver can't
probe sucess.

Signed-off-by: Sandy Huang 
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index dc3b22c..b2f1716 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -157,6 +157,7 @@
 
display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
+   ports = <_out>, <_out>;
status = "disabled";
};
 
@@ -795,10 +796,16 @@
clocks = < ACLK_VOPB>, < DCLK_VOPB>,
 < HCLK_VOPB>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_VOPB_A>, < SRST_VOPB_H>, < 
SRST_VOPB>;
+   reset-names = "axi", "ahb", "dclk";
iommus = <_mmu>;
power-domains = < PX30_PD_VO>;
rockchip,grf = <>;
status = "disabled";
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 
vopb_mmu: iommu@ff460f00 {
@@ -820,10 +827,16 @@
clocks = < ACLK_VOPL>, < DCLK_VOPL>,
 < HCLK_VOPL>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_VOPL_A>, < SRST_VOPL_H>, < 
SRST_VOPL>;
+   reset-names = "axi", "ahb", "dclk";
iommus = <_mmu>;
power-domains = < PX30_PD_VO>;
rockchip,grf = <>;
status = "disabled";
+   vopl_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 
vopl_mmu: iommu@ff470f00 {
-- 
2.7.4

[PATCH] arm64: dts: rockchip: perfection vop property define for px30

2018-08-28 Thread Sandy Huang

Add display ports for display-subsystem and add reset property
for vop node, if missing this two define, drm driver can't
probe sucess.

Signed-off-by: Sandy Huang 
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index dc3b22c..b2f1716 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -157,6 +157,7 @@
 
display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
+   ports = <_out>, <_out>;
status = "disabled";
};
 
@@ -795,10 +796,16 @@
clocks = < ACLK_VOPB>, < DCLK_VOPB>,
 < HCLK_VOPB>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_VOPB_A>, < SRST_VOPB_H>, < 
SRST_VOPB>;
+   reset-names = "axi", "ahb", "dclk";
iommus = <_mmu>;
power-domains = < PX30_PD_VO>;
rockchip,grf = <>;
status = "disabled";
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 
vopb_mmu: iommu@ff460f00 {
@@ -820,10 +827,16 @@
clocks = < ACLK_VOPL>, < DCLK_VOPL>,
 < HCLK_VOPL>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_VOPL_A>, < SRST_VOPL_H>, < 
SRST_VOPL>;
+   reset-names = "axi", "ahb", "dclk";
iommus = <_mmu>;
power-domains = < PX30_PD_VO>;
rockchip,grf = <>;
status = "disabled";
+   vopl_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 
vopl_mmu: iommu@ff470f00 {
-- 
2.7.4

[PATCH v3] PCI: dwc: fix scheduling while atomic issues

2018-08-28 Thread Jisheng Zhang

When programming inbound/outbound atu, we call usleep_range() after
each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
can be called in atomic context:

inbound atu programming could be called through
pci_epc_write_header()
  =>dw_pcie_ep_write_header()
=>dw_pcie_prog_inbound_atu()

outbound atu programming could be called through
pci_bus_read_config_dword()
  =>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()

Fix this issue by calling mdelay() instead.

Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
Fixes: d8bbeb39fbf3 ("PCI: designware: Wait for iATU enable")
Signed-off-by: Jisheng Zhang 
Acked-by: Gustavo Pimentel 
---

since v2:
 - Add Fixes tag
 - Add Gustavo's Ack

since v1:
 - use mdelay() instead of udelay() to avoid __bad_udelay()

 drivers/pci/controller/dwc/pcie-designware.c | 8 
 drivers/pci/controller/dwc/pcie-designware.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 778c4f76a884..2153956a0b20 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -135,7 +135,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -178,7 +178,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
index, int type,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -236,7 +236,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
@@ -282,7 +282,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 96126fd8403c..9f1a5e399b70 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -26,8 +26,7 @@
 
 /* Parameters for the waiting for iATU enabled routine */
 #define LINK_WAIT_MAX_IATU_RETRIES 5
-#define LINK_WAIT_IATU_MIN 9000
-#define LINK_WAIT_IATU_MAX 1
+#define LINK_WAIT_IATU 9
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
-- 
2.18.0

[PATCH v3] PCI: dwc: fix scheduling while atomic issues

2018-08-28 Thread Jisheng Zhang

When programming inbound/outbound atu, we call usleep_range() after
each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
can be called in atomic context:

inbound atu programming could be called through
pci_epc_write_header()
  =>dw_pcie_ep_write_header()
=>dw_pcie_prog_inbound_atu()

outbound atu programming could be called through
pci_bus_read_config_dword()
  =>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()

Fix this issue by calling mdelay() instead.

Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
Fixes: d8bbeb39fbf3 ("PCI: designware: Wait for iATU enable")
Signed-off-by: Jisheng Zhang 
Acked-by: Gustavo Pimentel 
---

since v2:
 - Add Fixes tag
 - Add Gustavo's Ack

since v1:
 - use mdelay() instead of udelay() to avoid __bad_udelay()

 drivers/pci/controller/dwc/pcie-designware.c | 8 
 drivers/pci/controller/dwc/pcie-designware.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 778c4f76a884..2153956a0b20 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -135,7 +135,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -178,7 +178,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
index, int type,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -236,7 +236,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
@@ -282,7 +282,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 96126fd8403c..9f1a5e399b70 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -26,8 +26,7 @@
 
 /* Parameters for the waiting for iATU enabled routine */
 #define LINK_WAIT_MAX_IATU_RETRIES 5
-#define LINK_WAIT_IATU_MIN 9000
-#define LINK_WAIT_IATU_MAX 1
+#define LINK_WAIT_IATU 9
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
-- 
2.18.0

RE: [PATCH V3 0/4] clk: new APIs to handle all available clocks

2018-08-28 Thread Stephen Boyd

Quoting A.s. Dong (2018-08-16 19:33:52)
> Hi Stephen,
> 
> Do you want me to resend this series for review?
> It seems have been pending for quite a long time.
> 
> Thor just pinged me for its status as he wants to use it.
> 

I was waiting for someone to try them out or review them. Good that it
happened!

I've taken a look at the patches and I'm slightly annoyed with the API
that passes in a double pointer to clk_bulk_data and returns a count of
the number of clks found. I guess it's ok though. It's really just this
line:

devres->clks = *clks;

which makes my brain all confused and go think about what's being
assigned and if it's a struct copy or not.

Maybe this on top would make it easier to take? I'll think about it
tonight.

---8<---
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index 6d3ca5ec5de8..12c87457eca1 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -81,9 +81,9 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
if (!devres)
return -ENOMEM;
 
-   ret = clk_bulk_get_all(dev, clks);
+   ret = clk_bulk_get_all(dev, >clks);
if (ret > 0) {
-   devres->clks = *clks;
+   *clks = devres->clks;
devres->num_clks = ret;
devres_add(dev, devres);
} else {

RE: [PATCH V3 0/4] clk: new APIs to handle all available clocks

2018-08-28 Thread Stephen Boyd

Quoting A.s. Dong (2018-08-16 19:33:52)
> Hi Stephen,
> 
> Do you want me to resend this series for review?
> It seems have been pending for quite a long time.
> 
> Thor just pinged me for its status as he wants to use it.
> 

I was waiting for someone to try them out or review them. Good that it
happened!

I've taken a look at the patches and I'm slightly annoyed with the API
that passes in a double pointer to clk_bulk_data and returns a count of
the number of clks found. I guess it's ok though. It's really just this
line:

devres->clks = *clks;

which makes my brain all confused and go think about what's being
assigned and if it's a struct copy or not.

Maybe this on top would make it easier to take? I'll think about it
tonight.

---8<---
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index 6d3ca5ec5de8..12c87457eca1 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -81,9 +81,9 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
if (!devres)
return -ENOMEM;
 
-   ret = clk_bulk_get_all(dev, clks);
+   ret = clk_bulk_get_all(dev, >clks);
if (ret > 0) {
-   devres->clks = *clks;
+   *clks = devres->clks;
devres->num_clks = ret;
devres_add(dev, devres);
} else {

Re: [PATCH resend] uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name

2018-08-28 Thread Greg KH

On Tue, Aug 28, 2018 at 04:34:04PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Since this header is in "include/uapi/linux/", apparently people
> want to use it in userspace programs -- even in C++ ones.
> However, the header uses a C++ reserved keyword ("private"),
> so change that to "dh_private" instead to allow the header file
> to be used in C++ userspace.
> 
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051
> Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
> 
> Signed-off-by: Randy Dunlap 
> Cc: David Howells 
> Cc: James Morris 
> Cc: "Serge E. Hallyn" 
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: Mat Martineau 
> Cc: sta...@vger.kernel.org
> ---
>  include/uapi/linux/keyctl.h |2 +-
>  security/keys/dh.c  |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> --- lnx-416.orig/include/uapi/linux/keyctl.h
> +++ lnx-416/include/uapi/linux/keyctl.h
> @@ -65,7 +65,7 @@
>  
>  /* keyctl structures */
>  struct keyctl_dh_params {
> - __s32 private;
> + __s32 dh_private;

Ick ick ick, why not just put the C "namespace" on all uapi files if you
are including them from c++ code?  I'm sure this isn't the only problem
that has this problem, right?

This is valid C, no need to start worrying about C++ reserved names.

thanks,

greg "'struct class' is your friend" k-h

Re: [PATCH resend] uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name

2018-08-28 Thread Greg KH

On Tue, Aug 28, 2018 at 04:34:04PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Since this header is in "include/uapi/linux/", apparently people
> want to use it in userspace programs -- even in C++ ones.
> However, the header uses a C++ reserved keyword ("private"),
> so change that to "dh_private" instead to allow the header file
> to be used in C++ userspace.
> 
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051
> Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
> 
> Signed-off-by: Randy Dunlap 
> Cc: David Howells 
> Cc: James Morris 
> Cc: "Serge E. Hallyn" 
> Cc: keyri...@vger.kernel.org
> Cc: linux-security-mod...@vger.kernel.org
> Cc: Mat Martineau 
> Cc: sta...@vger.kernel.org
> ---
>  include/uapi/linux/keyctl.h |2 +-
>  security/keys/dh.c  |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> --- lnx-416.orig/include/uapi/linux/keyctl.h
> +++ lnx-416/include/uapi/linux/keyctl.h
> @@ -65,7 +65,7 @@
>  
>  /* keyctl structures */
>  struct keyctl_dh_params {
> - __s32 private;
> + __s32 dh_private;

Ick ick ick, why not just put the C "namespace" on all uapi files if you
are including them from c++ code?  I'm sure this isn't the only problem
that has this problem, right?

This is valid C, no need to start worrying about C++ reserved names.

thanks,

greg "'struct class' is your friend" k-h

[RFC] perf script: callchain handling is not useful

2018-08-28 Thread Stephane Eranian

Hi,

I am doing the following simple collection with callchain and load profiling:

$ perf record -g -d -e cpu/event=0xd0,umask=0x81/pp  my_test_program

But when I type:
$ perf script -F ip,addr
9d4821346878
9d58df25
9d58e054
9d5965bb
9d640650
9d697d06
9d63ec60
9d640322
9d64070c
9d455a60
  7030c7

9d4638ba84a0
9d5df447
9d5eaf4a
9d63e165
9d63e439
9d697d98
9d63ec60
9d640322
9d64070c
9d455a60
  7030c7
I also see the callchain and it is not clear which is the IP. Further
more parsing becomes more difficult because of multiple lines per
sample. I understand that multiline is likely because of
symbolization. But if I don't want symbolization, it should be
possible to print all in one line.

The current output is not very useful. You expect perf script to give
you one line per sample and only what you want. Callchain != IP.

I think the following should happen:
  - do not print callchain when asked for the IP. Create a callchain filter.
  - print callchain on the same line, much like what is done for brstack

It is not clear to me why callchain and ip were lumped together.
Any opinion on my proposal?
Thanks.

[RFC] perf script: callchain handling is not useful

2018-08-28 Thread Stephane Eranian

Hi,

I am doing the following simple collection with callchain and load profiling:

$ perf record -g -d -e cpu/event=0xd0,umask=0x81/pp  my_test_program

But when I type:
$ perf script -F ip,addr
9d4821346878
9d58df25
9d58e054
9d5965bb
9d640650
9d697d06
9d63ec60
9d640322
9d64070c
9d455a60
  7030c7

9d4638ba84a0
9d5df447
9d5eaf4a
9d63e165
9d63e439
9d697d98
9d63ec60
9d640322
9d64070c
9d455a60
  7030c7
I also see the callchain and it is not clear which is the IP. Further
more parsing becomes more difficult because of multiple lines per
sample. I understand that multiline is likely because of
symbolization. But if I don't want symbolization, it should be
possible to print all in one line.

The current output is not very useful. You expect perf script to give
you one line per sample and only what you want. Callchain != IP.

I think the following should happen:
  - do not print callchain when asked for the IP. Create a callchain filter.
  - print callchain on the same line, much like what is done for brstack

It is not clear to me why callchain and ip were lumped together.
Any opinion on my proposal?
Thanks.

[PATCH 3/4] tty: Lock tty pair in tty_init_dev()

It's safe to not lock both here - done to silence attempt lockdep assert in
tty_ldisc_open(), which will be added with following patch.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_io.c| 5 ++---
 drivers/tty/tty_ldisc.c | 6 ++
 include/linux/tty.h | 4 
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3ef8b977b167..a94005f915b3 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1342,7 +1342,7 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
"%s: %s driver does not set tty->port. This will crash 
the kernel later. Fix the driver!\n",
__func__, tty->driver->name);
 
-   retval = tty_ldisc_lock(tty, 5 * HZ);
+   retval = tty_ldisc_lock_pair_timeout(tty, tty->link, 5 * HZ);
if (retval)
goto err_release_lock;
tty->port->itty = tty;
@@ -1353,9 +1353,9 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
 * to decrement the use counts, as release_tty doesn't care.
 */
retval = tty_ldisc_setup(tty, tty->link);
+   tty_ldisc_unlock_pair(tty, tty->link);
if (retval)
goto err_release_tty;
-   tty_ldisc_unlock(tty);
/* Return the tty locked so that it cannot vanish under the caller */
return tty;
 
@@ -1368,7 +1368,6 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
 
/* call the tty release_tty routine to clean out this slot */
 err_release_tty:
-   tty_ldisc_unlock(tty);
tty_info_ratelimited(tty, "ldisc open failed (%d), clearing slot %d\n",
 retval, idx);
 err_release_lock:
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index fc4c97cae01e..b72266461c00 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -340,8 +340,7 @@ void tty_ldisc_unlock(struct tty_struct *tty)
__tty_ldisc_unlock(tty);
 }
 
-static int
-tty_ldisc_lock_pair_timeout(struct tty_struct *tty, struct tty_struct *tty2,
+int tty_ldisc_lock_pair_timeout(struct tty_struct *tty, struct tty_struct 
*tty2,
unsigned long timeout)
 {
int ret;
@@ -381,8 +380,7 @@ static void tty_ldisc_lock_pair(struct tty_struct *tty, 
struct tty_struct *tty2)
tty_ldisc_lock_pair_timeout(tty, tty2, MAX_SCHEDULE_TIMEOUT);
 }
 
-static void tty_ldisc_unlock_pair(struct tty_struct *tty,
- struct tty_struct *tty2)
+void tty_ldisc_unlock_pair(struct tty_struct *tty, struct tty_struct *tty2)
 {
__tty_ldisc_unlock(tty);
if (tty2)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index c56e3978b00f..5efb8f87ffdc 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -409,6 +409,10 @@ extern void tty_kclose(struct tty_struct *tty);
 extern int tty_dev_name_to_number(const char *name, dev_t *number);
 extern int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout);
 extern void tty_ldisc_unlock(struct tty_struct *tty);
+extern int tty_ldisc_lock_pair_timeout(struct tty_struct *tty,
+   struct tty_struct *tty2, unsigned long timeout);
+extern void tty_ldisc_unlock_pair(struct tty_struct *tty,
+   struct tty_struct *tty2);
 #else
 static inline void tty_kref_put(struct tty_struct *tty)
 { }
-- 
2.13.6

[PATCH 3/4] tty: Lock tty pair in tty_init_dev()

It's safe to not lock both here - done to silence attempt lockdep assert in
tty_ldisc_open(), which will be added with following patch.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_io.c| 5 ++---
 drivers/tty/tty_ldisc.c | 6 ++
 include/linux/tty.h | 4 
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3ef8b977b167..a94005f915b3 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1342,7 +1342,7 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
"%s: %s driver does not set tty->port. This will crash 
the kernel later. Fix the driver!\n",
__func__, tty->driver->name);
 
-   retval = tty_ldisc_lock(tty, 5 * HZ);
+   retval = tty_ldisc_lock_pair_timeout(tty, tty->link, 5 * HZ);
if (retval)
goto err_release_lock;
tty->port->itty = tty;
@@ -1353,9 +1353,9 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
 * to decrement the use counts, as release_tty doesn't care.
 */
retval = tty_ldisc_setup(tty, tty->link);
+   tty_ldisc_unlock_pair(tty, tty->link);
if (retval)
goto err_release_tty;
-   tty_ldisc_unlock(tty);
/* Return the tty locked so that it cannot vanish under the caller */
return tty;
 
@@ -1368,7 +1368,6 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
 
/* call the tty release_tty routine to clean out this slot */
 err_release_tty:
-   tty_ldisc_unlock(tty);
tty_info_ratelimited(tty, "ldisc open failed (%d), clearing slot %d\n",
 retval, idx);
 err_release_lock:
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index fc4c97cae01e..b72266461c00 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -340,8 +340,7 @@ void tty_ldisc_unlock(struct tty_struct *tty)
__tty_ldisc_unlock(tty);
 }
 
-static int
-tty_ldisc_lock_pair_timeout(struct tty_struct *tty, struct tty_struct *tty2,
+int tty_ldisc_lock_pair_timeout(struct tty_struct *tty, struct tty_struct 
*tty2,
unsigned long timeout)
 {
int ret;
@@ -381,8 +380,7 @@ static void tty_ldisc_lock_pair(struct tty_struct *tty, 
struct tty_struct *tty2)
tty_ldisc_lock_pair_timeout(tty, tty2, MAX_SCHEDULE_TIMEOUT);
 }
 
-static void tty_ldisc_unlock_pair(struct tty_struct *tty,
- struct tty_struct *tty2)
+void tty_ldisc_unlock_pair(struct tty_struct *tty, struct tty_struct *tty2)
 {
__tty_ldisc_unlock(tty);
if (tty2)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index c56e3978b00f..5efb8f87ffdc 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -409,6 +409,10 @@ extern void tty_kclose(struct tty_struct *tty);
 extern int tty_dev_name_to_number(const char *name, dev_t *number);
 extern int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout);
 extern void tty_ldisc_unlock(struct tty_struct *tty);
+extern int tty_ldisc_lock_pair_timeout(struct tty_struct *tty,
+   struct tty_struct *tty2, unsigned long timeout);
+extern void tty_ldisc_unlock_pair(struct tty_struct *tty,
+   struct tty_struct *tty2);
 #else
 static inline void tty_kref_put(struct tty_struct *tty)
 { }
-- 
2.13.6

[PATCH 0/4] tty: Hold write ldisc sem in tty_reopen()

Two fixes for potential and real issues.
Looks worth to have in stables as we've hit it on v4.9 stable.
And for linux-next - adding lockdep asserts for line discipline changing
code, verifying that write ldisc sem will be held forthwith.

I couldn't verify that holding write lock fixes the issue as we've hit
it only once and I've failed in reproducing it.
But searching in lkml, Cc'ing here people who probably had the same
crash (and in hope someone of them could give tested-by):

Cc: Daniel Axtens  
Cc: Dmitry Vyukov  
Cc: Michael Neuling 
Cc: Mikulas Patocka 
Cc: Pasi Kärkkäinen 
Cc: Peter Hurley 
Cc: Sergey Senozhatsky  
Cc: Tan Xiaojun 
(please, ignore if I Cc'ed you mistakenly)

Dmitry Safonov (4):
  tty: Drop tty->count on tty_reopen() failure
  tty: Hold tty_ldisc_lock() during tty_reopen()
  tty: Lock tty pair in tty_init_dev()
  tty/lockdep: Add ldisc_sem asserts

 drivers/tty/tty_io.c| 21 +++--
 drivers/tty/tty_ldisc.c | 12 
 include/linux/tty.h |  4 
 3 files changed, 27 insertions(+), 10 deletions(-)

-- 
2.13.6

[PATCH 4/4] tty/lockdep: Add ldisc_sem asserts

It should nicely document that each change to line discipline should
held write semaphor. Otherwise potential reader will have a good time.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_ldisc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index b72266461c00..9ef0b33a4132 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -444,6 +444,7 @@ static void tty_set_termios_ldisc(struct tty_struct *tty, 
int disc)
 
 static int tty_ldisc_open(struct tty_struct *tty, struct tty_ldisc *ld)
 {
+   lockdep_assert_held(>ldisc_sem);
WARN_ON(test_and_set_bit(TTY_LDISC_OPEN, >flags));
if (ld->ops->open) {
int ret;
@@ -469,6 +470,7 @@ static int tty_ldisc_open(struct tty_struct *tty, struct 
tty_ldisc *ld)
 
 static void tty_ldisc_close(struct tty_struct *tty, struct tty_ldisc *ld)
 {
+   lockdep_assert_held(>ldisc_sem);
WARN_ON(!test_bit(TTY_LDISC_OPEN, >flags));
clear_bit(TTY_LDISC_OPEN, >flags);
if (ld->ops->close)
@@ -490,6 +492,7 @@ static int tty_ldisc_failto(struct tty_struct *tty, int ld)
struct tty_ldisc *disc = tty_ldisc_get(tty, ld);
int r;
 
+   lockdep_assert_held(>ldisc_sem);
if (IS_ERR(disc))
return PTR_ERR(disc);
tty->ldisc = disc;
@@ -613,6 +616,7 @@ EXPORT_SYMBOL_GPL(tty_set_ldisc);
  */
 static void tty_ldisc_kill(struct tty_struct *tty)
 {
+   lockdep_assert_held(>ldisc_sem);
if (!tty->ldisc)
return;
/*
@@ -660,6 +664,7 @@ int tty_ldisc_reinit(struct tty_struct *tty, int disc)
struct tty_ldisc *ld;
int retval;
 
+   lockdep_assert_held(>ldisc_sem);
ld = tty_ldisc_get(tty, disc);
if (IS_ERR(ld)) {
BUG_ON(disc == N_TTY);
@@ -823,6 +828,7 @@ int tty_ldisc_init(struct tty_struct *tty)
  */
 void tty_ldisc_deinit(struct tty_struct *tty)
 {
+   /* no ldisc_sem, tty is being destroyed */
if (tty->ldisc)
tty_ldisc_put(tty->ldisc);
tty->ldisc = NULL;
-- 
2.13.6

[PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()

tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
But it races with anyone who expects line discipline to be the same
after hoding read semaphore in tty_ldisc_ref().

We've seen the following crash on v4.9.108 stable:

BUG: unable to handle kernel paging request at 2260
IP: [..] n_tty_receive_buf_common+0x5f/0x86d
Workqueue: events_unbound flush_to_ldisc
Call Trace:
 [..] n_tty_receive_buf2
 [..] tty_ldisc_receive_buf
 [..] flush_to_ldisc
 [..] process_one_work
 [..] worker_thread
 [..] kthread
 [..] ret_from_fork

I think, tty_ldisc_reinit() should be called with ldisc_sem hold for
writing, which will protect any reader against line discipline changes.

Note: I failed to reproduce the described crash, so obiviously can't
guarantee that this is the place where line discipline was switched.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_io.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 5e5da9acaf0a..3ef8b977b167 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1267,15 +1267,20 @@ static int tty_reopen(struct tty_struct *tty)
if (test_bit(TTY_EXCLUSIVE, >flags) && !capable(CAP_SYS_ADMIN))
return -EBUSY;
 
-   tty->count++;
+   retval = tty_ldisc_lock(tty, 5 * HZ);
+   if (retval)
+   return retval;
 
+   tty->count++;
if (tty->ldisc)
-   return 0;
+   goto out_unlock;
 
retval = tty_ldisc_reinit(tty, tty->termios.c_line);
if (retval)
tty->count--;
 
+out_unlock:
+   tty_ldisc_unlock(tty);
return retval;
 }
 
-- 
2.13.6

[PATCH 1/4] tty: Drop tty->count on tty_reopen() failure

In case of tty_ldisc_reinit() failure, tty->count should be decremented
back, otherwise we will never release_tty().
Never seen it in the real life, but it seems not really hard to hit.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_io.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 32bc3e3fe4d3..5e5da9acaf0a 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1255,6 +1255,7 @@ static void tty_driver_remove_tty(struct tty_driver 
*driver, struct tty_struct *
 static int tty_reopen(struct tty_struct *tty)
 {
struct tty_driver *driver = tty->driver;
+   int retval;
 
if (driver->type == TTY_DRIVER_TYPE_PTY &&
driver->subtype == PTY_TYPE_MASTER)
@@ -1268,10 +1269,14 @@ static int tty_reopen(struct tty_struct *tty)
 
tty->count++;
 
-   if (!tty->ldisc)
-   return tty_ldisc_reinit(tty, tty->termios.c_line);
+   if (tty->ldisc)
+   return 0;
 
-   return 0;
+   retval = tty_ldisc_reinit(tty, tty->termios.c_line);
+   if (retval)
+   tty->count--;
+
+   return retval;
 }
 
 /**
-- 
2.13.6

[PATCH 0/4] tty: Hold write ldisc sem in tty_reopen()

Two fixes for potential and real issues.
Looks worth to have in stables as we've hit it on v4.9 stable.
And for linux-next - adding lockdep asserts for line discipline changing
code, verifying that write ldisc sem will be held forthwith.

I couldn't verify that holding write lock fixes the issue as we've hit
it only once and I've failed in reproducing it.
But searching in lkml, Cc'ing here people who probably had the same
crash (and in hope someone of them could give tested-by):

Cc: Daniel Axtens  
Cc: Dmitry Vyukov  
Cc: Michael Neuling 
Cc: Mikulas Patocka 
Cc: Pasi Kärkkäinen 
Cc: Peter Hurley 
Cc: Sergey Senozhatsky  
Cc: Tan Xiaojun 
(please, ignore if I Cc'ed you mistakenly)

Dmitry Safonov (4):
  tty: Drop tty->count on tty_reopen() failure
  tty: Hold tty_ldisc_lock() during tty_reopen()
  tty: Lock tty pair in tty_init_dev()
  tty/lockdep: Add ldisc_sem asserts

 drivers/tty/tty_io.c| 21 +++--
 drivers/tty/tty_ldisc.c | 12 
 include/linux/tty.h |  4 
 3 files changed, 27 insertions(+), 10 deletions(-)

-- 
2.13.6

[PATCH 4/4] tty/lockdep: Add ldisc_sem asserts

It should nicely document that each change to line discipline should
held write semaphor. Otherwise potential reader will have a good time.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_ldisc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index b72266461c00..9ef0b33a4132 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -444,6 +444,7 @@ static void tty_set_termios_ldisc(struct tty_struct *tty, 
int disc)
 
 static int tty_ldisc_open(struct tty_struct *tty, struct tty_ldisc *ld)
 {
+   lockdep_assert_held(>ldisc_sem);
WARN_ON(test_and_set_bit(TTY_LDISC_OPEN, >flags));
if (ld->ops->open) {
int ret;
@@ -469,6 +470,7 @@ static int tty_ldisc_open(struct tty_struct *tty, struct 
tty_ldisc *ld)
 
 static void tty_ldisc_close(struct tty_struct *tty, struct tty_ldisc *ld)
 {
+   lockdep_assert_held(>ldisc_sem);
WARN_ON(!test_bit(TTY_LDISC_OPEN, >flags));
clear_bit(TTY_LDISC_OPEN, >flags);
if (ld->ops->close)
@@ -490,6 +492,7 @@ static int tty_ldisc_failto(struct tty_struct *tty, int ld)
struct tty_ldisc *disc = tty_ldisc_get(tty, ld);
int r;
 
+   lockdep_assert_held(>ldisc_sem);
if (IS_ERR(disc))
return PTR_ERR(disc);
tty->ldisc = disc;
@@ -613,6 +616,7 @@ EXPORT_SYMBOL_GPL(tty_set_ldisc);
  */
 static void tty_ldisc_kill(struct tty_struct *tty)
 {
+   lockdep_assert_held(>ldisc_sem);
if (!tty->ldisc)
return;
/*
@@ -660,6 +664,7 @@ int tty_ldisc_reinit(struct tty_struct *tty, int disc)
struct tty_ldisc *ld;
int retval;
 
+   lockdep_assert_held(>ldisc_sem);
ld = tty_ldisc_get(tty, disc);
if (IS_ERR(ld)) {
BUG_ON(disc == N_TTY);
@@ -823,6 +828,7 @@ int tty_ldisc_init(struct tty_struct *tty)
  */
 void tty_ldisc_deinit(struct tty_struct *tty)
 {
+   /* no ldisc_sem, tty is being destroyed */
if (tty->ldisc)
tty_ldisc_put(tty->ldisc);
tty->ldisc = NULL;
-- 
2.13.6

[PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()

tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
But it races with anyone who expects line discipline to be the same
after hoding read semaphore in tty_ldisc_ref().

We've seen the following crash on v4.9.108 stable:

BUG: unable to handle kernel paging request at 2260
IP: [..] n_tty_receive_buf_common+0x5f/0x86d
Workqueue: events_unbound flush_to_ldisc
Call Trace:
 [..] n_tty_receive_buf2
 [..] tty_ldisc_receive_buf
 [..] flush_to_ldisc
 [..] process_one_work
 [..] worker_thread
 [..] kthread
 [..] ret_from_fork

I think, tty_ldisc_reinit() should be called with ldisc_sem hold for
writing, which will protect any reader against line discipline changes.

Note: I failed to reproduce the described crash, so obiviously can't
guarantee that this is the place where line discipline was switched.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_io.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 5e5da9acaf0a..3ef8b977b167 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1267,15 +1267,20 @@ static int tty_reopen(struct tty_struct *tty)
if (test_bit(TTY_EXCLUSIVE, >flags) && !capable(CAP_SYS_ADMIN))
return -EBUSY;
 
-   tty->count++;
+   retval = tty_ldisc_lock(tty, 5 * HZ);
+   if (retval)
+   return retval;
 
+   tty->count++;
if (tty->ldisc)
-   return 0;
+   goto out_unlock;
 
retval = tty_ldisc_reinit(tty, tty->termios.c_line);
if (retval)
tty->count--;
 
+out_unlock:
+   tty_ldisc_unlock(tty);
return retval;
 }
 
-- 
2.13.6

[PATCH 1/4] tty: Drop tty->count on tty_reopen() failure

In case of tty_ldisc_reinit() failure, tty->count should be decremented
back, otherwise we will never release_tty().
Never seen it in the real life, but it seems not really hard to hit.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Safonov 
---
 drivers/tty/tty_io.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 32bc3e3fe4d3..5e5da9acaf0a 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1255,6 +1255,7 @@ static void tty_driver_remove_tty(struct tty_driver 
*driver, struct tty_struct *
 static int tty_reopen(struct tty_struct *tty)
 {
struct tty_driver *driver = tty->driver;
+   int retval;
 
if (driver->type == TTY_DRIVER_TYPE_PTY &&
driver->subtype == PTY_TYPE_MASTER)
@@ -1268,10 +1269,14 @@ static int tty_reopen(struct tty_struct *tty)
 
tty->count++;
 
-   if (!tty->ldisc)
-   return tty_ldisc_reinit(tty, tty->termios.c_line);
+   if (tty->ldisc)
+   return 0;
 
-   return 0;
+   retval = tty_ldisc_reinit(tty, tty->termios.c_line);
+   if (retval)
+   tty->count--;
+
+   return retval;
 }
 
 /**
-- 
2.13.6

[PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the
initial size of the direct mapping region. This is right in the
old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
46bit, and only 4-level mode was supported.

Later, in commit:
b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"),
__PHYSICAL_MASK_SHIFT was changed to be 52 always, no matter it's
5-level or 4-level. This is wrong for 4-level paging. Then when
adapt phyiscal memory region size based on available memory, it
will overflow if the amount of system RAM and the padding is bigger
than 64TB.

In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by
by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.

Signed-off-by: Baoquan He 
---
 arch/x86/mm/kaslr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b0eda9..0988971069c9 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -93,7 +93,7 @@ void __init kernel_randomize_memory(void)
if (!kaslr_memory_enabled())
return;
 
-   kaslr_regions[0].size_tb = 1 << (__PHYSICAL_MASK_SHIFT - TB_SHIFT);
+   kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
 
/*
-- 
2.13.6

[PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the
initial size of the direct mapping region. This is right in the
old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
46bit, and only 4-level mode was supported.

Later, in commit:
b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"),
__PHYSICAL_MASK_SHIFT was changed to be 52 always, no matter it's
5-level or 4-level. This is wrong for 4-level paging. Then when
adapt phyiscal memory region size based on available memory, it
will overflow if the amount of system RAM and the padding is bigger
than 64TB.

In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by
by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.

Signed-off-by: Baoquan He 
---
 arch/x86/mm/kaslr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b0eda9..0988971069c9 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -93,7 +93,7 @@ void __init kernel_randomize_memory(void)
if (!kaslr_memory_enabled())
return;
 
-   kaslr_regions[0].size_tb = 1 << (__PHYSICAL_MASK_SHIFT - TB_SHIFT);
+   kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
 
/*
-- 
2.13.6

[PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

Vmemmap area has different base and size depending on paging mode.
Now we just hardcode its size as 1TB in memory KASLR, it's not
right for 5-level paging mode.

Adjust it according to paging mode and use it during memory KASLR.

Signed-off-by: Baoquan He 
---
 arch/x86/include/asm/pgtable_64_types.h | 5 +
 arch/x86/mm/kaslr.c | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 04edd2d58211..fa759d2d3186 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -126,14 +126,19 @@ extern unsigned int ptrs_per_p4d;
 #define __VMEMMAP_BASE_L4  0xea00UL
 #define __VMEMMAP_BASE_L5  0xffd4UL
 
+#define VMEMMAP_SIZE_TB_L4 1UL
+#define VMEMMAP_SIZE_TB_L5 512UL
+
 #ifdef CONFIG_DYNAMIC_MEMORY_LAYOUT
 # define VMALLOC_START vmalloc_base
 # define VMALLOC_SIZE_TB   (pgtable_l5_enabled() ? VMALLOC_SIZE_TB_L5 : 
VMALLOC_SIZE_TB_L4)
 # define VMEMMAP_START vmemmap_base
+# define VMEMMAP_SIZE_TB   (pgtable_l5_enabled() ? VMEMMAP_SIZE_TB_L5 : 
VMEMMAP_SIZE_TB_L4)
 #else
 # define VMALLOC_START __VMALLOC_BASE_L4
 # define VMALLOC_SIZE_TB   VMALLOC_SIZE_TB_L4
 # define VMEMMAP_START __VMEMMAP_BASE_L4
+# define VMEMMAP_SIZE_TB   VMEMMAP_SIZE_TB_L4
 #endif /* CONFIG_DYNAMIC_MEMORY_LAYOUT */
 
 #define VMALLOC_END(VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 0988971069c9..69228af4c7d7 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -51,7 +51,7 @@ static __initdata struct kaslr_memory_region {
 } kaslr_regions[] = {
{ _offset_base, 0 },
{ _base, 0 },
-   { _base, 1 },
+   { _base, 0 },
 };
 
 /* Get size in bytes used by the memory region */
@@ -95,6 +95,7 @@ void __init kernel_randomize_memory(void)
 
kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
+   kaslr_regions[2].size_tb = VMEMMAP_SIZE_TB;
 
/*
 * Update Physical memory mapping to available and
-- 
2.13.6

[PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

Vmemmap area has different base and size depending on paging mode.
Now we just hardcode its size as 1TB in memory KASLR, it's not
right for 5-level paging mode.

Adjust it according to paging mode and use it during memory KASLR.

Signed-off-by: Baoquan He 
---
 arch/x86/include/asm/pgtable_64_types.h | 5 +
 arch/x86/mm/kaslr.c | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 04edd2d58211..fa759d2d3186 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -126,14 +126,19 @@ extern unsigned int ptrs_per_p4d;
 #define __VMEMMAP_BASE_L4  0xea00UL
 #define __VMEMMAP_BASE_L5  0xffd4UL
 
+#define VMEMMAP_SIZE_TB_L4 1UL
+#define VMEMMAP_SIZE_TB_L5 512UL
+
 #ifdef CONFIG_DYNAMIC_MEMORY_LAYOUT
 # define VMALLOC_START vmalloc_base
 # define VMALLOC_SIZE_TB   (pgtable_l5_enabled() ? VMALLOC_SIZE_TB_L5 : 
VMALLOC_SIZE_TB_L4)
 # define VMEMMAP_START vmemmap_base
+# define VMEMMAP_SIZE_TB   (pgtable_l5_enabled() ? VMEMMAP_SIZE_TB_L5 : 
VMEMMAP_SIZE_TB_L4)
 #else
 # define VMALLOC_START __VMALLOC_BASE_L4
 # define VMALLOC_SIZE_TB   VMALLOC_SIZE_TB_L4
 # define VMEMMAP_START __VMEMMAP_BASE_L4
+# define VMEMMAP_SIZE_TB   VMEMMAP_SIZE_TB_L4
 #endif /* CONFIG_DYNAMIC_MEMORY_LAYOUT */
 
 #define VMALLOC_END(VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 0988971069c9..69228af4c7d7 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -51,7 +51,7 @@ static __initdata struct kaslr_memory_region {
 } kaslr_regions[] = {
{ _offset_base, 0 },
{ _base, 0 },
-   { _base, 1 },
+   { _base, 0 },
 };
 
 /* Get size in bytes used by the memory region */
@@ -95,6 +95,7 @@ void __init kernel_randomize_memory(void)
 
kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
+   kaslr_regions[2].size_tb = VMEMMAP_SIZE_TB;
 
/*
 * Update Physical memory mapping to available and
-- 
2.13.6

Re: [PATCH] pinctrl: Convert to using %pOFn instead of device_node.name

2018-08-28 Thread Chen-Yu Tsai

On Tue, Aug 28, 2018 at 9:55 AM Rob Herring  wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Linus Walleij 
> Cc: Dong Aisheng 
> Cc: Fabio Estevam 
> Cc: Shawn Guo 
> Cc: Stefan Agner 
> Cc: Pengutronix Kernel Team 
> Cc: Sean Wang 
> Cc: Matthias Brugger 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Sebastian Hesselbarth 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Heiko Stuebner 
> Cc: Tony Lindgren 
> Cc: Haojian Zhuang 
> Cc: Patrice Chotard 
> Cc: Barry Song 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/pinctrl/berlin/berlin.c   |  6 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  7 ++--
>  drivers/pinctrl/freescale/pinctrl-imx1-core.c | 12 +++
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |  4 +--
>  drivers/pinctrl/meson/pinctrl-meson.c |  2 +-
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c |  4 +--
>  drivers/pinctrl/nomadik/pinctrl-nomadik.c |  6 ++--
>  drivers/pinctrl/pinctrl-at91.c|  8 ++---
>  drivers/pinctrl/pinctrl-lantiq.c  |  8 ++---
>  drivers/pinctrl/pinctrl-rockchip.c|  8 ++---
>  drivers/pinctrl/pinctrl-rza1.c|  8 ++---
>  drivers/pinctrl/pinctrl-single.c  | 32 +--
>  drivers/pinctrl/pinctrl-st.c  |  6 ++--
>  drivers/pinctrl/sirf/pinctrl-atlas7.c |  4 +--
>  drivers/pinctrl/stm32/pinctrl-stm32.c |  4 +--
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c |  8 ++---

For sunxi:

Acked-by: Chen-Yu Tsai

Re: [PATCH] pinctrl: Convert to using %pOFn instead of device_node.name

2018-08-28 Thread Chen-Yu Tsai

On Tue, Aug 28, 2018 at 9:55 AM Rob Herring  wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Linus Walleij 
> Cc: Dong Aisheng 
> Cc: Fabio Estevam 
> Cc: Shawn Guo 
> Cc: Stefan Agner 
> Cc: Pengutronix Kernel Team 
> Cc: Sean Wang 
> Cc: Matthias Brugger 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Sebastian Hesselbarth 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Heiko Stuebner 
> Cc: Tony Lindgren 
> Cc: Haojian Zhuang 
> Cc: Patrice Chotard 
> Cc: Barry Song 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/pinctrl/berlin/berlin.c   |  6 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  7 ++--
>  drivers/pinctrl/freescale/pinctrl-imx1-core.c | 12 +++
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |  4 +--
>  drivers/pinctrl/meson/pinctrl-meson.c |  2 +-
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c |  4 +--
>  drivers/pinctrl/nomadik/pinctrl-nomadik.c |  6 ++--
>  drivers/pinctrl/pinctrl-at91.c|  8 ++---
>  drivers/pinctrl/pinctrl-lantiq.c  |  8 ++---
>  drivers/pinctrl/pinctrl-rockchip.c|  8 ++---
>  drivers/pinctrl/pinctrl-rza1.c|  8 ++---
>  drivers/pinctrl/pinctrl-single.c  | 32 +--
>  drivers/pinctrl/pinctrl-st.c  |  6 ++--
>  drivers/pinctrl/sirf/pinctrl-atlas7.c |  4 +--
>  drivers/pinctrl/stm32/pinctrl-stm32.c |  4 +--
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c |  8 ++---

For sunxi:

Acked-by: Chen-Yu Tsai

Re: [PATCH] pinctrl: Convert to using %pOFn instead of device_node.name

2018-08-28 Thread Sean Wang

On Mon, 2018-08-27 at 20:52 -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> 
> Cc: Linus Walleij 
> Cc: Dong Aisheng 
> Cc: Fabio Estevam 
> Cc: Shawn Guo 
> Cc: Stefan Agner 
> Cc: Pengutronix Kernel Team 
> Cc: Sean Wang 
> Cc: Matthias Brugger 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Sebastian Hesselbarth 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Heiko Stuebner 
> Cc: Tony Lindgren 
> Cc: Haojian Zhuang 
> Cc: Patrice Chotard 
> Cc: Barry Song 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/pinctrl/berlin/berlin.c   |  6 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  7 ++--
>  drivers/pinctrl/freescale/pinctrl-imx1-core.c | 12 +++
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |  4 +--

For mediatek,
Acked-by: Sean Wang

Re: [PATCH] pinctrl: Convert to using %pOFn instead of device_node.name

2018-08-28 Thread Sean Wang

On Mon, 2018-08-27 at 20:52 -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> 
> Cc: Linus Walleij 
> Cc: Dong Aisheng 
> Cc: Fabio Estevam 
> Cc: Shawn Guo 
> Cc: Stefan Agner 
> Cc: Pengutronix Kernel Team 
> Cc: Sean Wang 
> Cc: Matthias Brugger 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Sebastian Hesselbarth 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Heiko Stuebner 
> Cc: Tony Lindgren 
> Cc: Haojian Zhuang 
> Cc: Patrice Chotard 
> Cc: Barry Song 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/pinctrl/berlin/berlin.c   |  6 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  7 ++--
>  drivers/pinctrl/freescale/pinctrl-imx1-core.c | 12 +++
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |  4 +--

For mediatek,
Acked-by: Sean Wang

Re: linux-next: build warnings from the build of Linus' tree

2018-08-28 Thread Greentime Hu

Arnd Bergmann  於 2018年8月24日 週五 下午8:48寫道：
>
> On Fri, Aug 24, 2018 at 10:23 AM Masami Hiramatsu  wrote:
> >
> > On Fri, 24 Aug 2018 13:32:06 +1000
> > Stephen Rothwell  wrote:
> >
> > > Hi all,
> > >
> > > After merging the origin tree, today's linux-next build (powerpc
> > > allyesconfig) produced these warnings:
> > >
> > > Maybe introduced by commit
> > >
> > >   6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
> > >
> > > I am guessing, but that is the only new thing that affects all of
> > > kernel/trace ...
> >
> > Yes, I agree. But I just followed Documentation/dev-tools/gcov.rst
> > to enable profiling in kernel/trace. Hmm, doesn't ppc64 support
> > GCOV_PROFILE?  (But as far as I can see, ARCH_HAS_GCOV_PROFILE_ALL
> > is enabled in arch/powerpc/Kconfig)
> >
> > Anyway, I'll try to reproduce it.
>
> Thje same commit causes a link failure on ARM with a randconfig
> kernel (see https://pastebin.com/KspjpyKG for the .config):
>
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_clock.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_clock.o
> `_GLOBAL__sub_D_00100_1_trace_clock_local' referenced in section
> `.fini_array.00100' of kernel/trace/trace_clock.o: defined in
> discarded section `.text.exit' of kernel/trace/trace_clock.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/ftrace.o: defined in discarded section `.text.exit' of
> kernel/trace/ftrace.o
> `_GLOBAL__sub_D_00100_1_function_trace_op' referenced in section
> `.fini_array.00100' of kernel/trace/ftrace.o: defined in discarded
> section `.text.exit' of kernel/trace/ftrace.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/ring_buffer.o: defined in discarded section `.text.exit'
> of kernel/trace/ring_buffer.o
> `_GLOBAL__sub_D_00100_1_ring_buffer_print_entry_header' referenced in
> section `.fini_array.00100' of kernel/trace/ring_buffer.o: defined in
> discarded section `.text.exit' of kernel/trace/ring_buffer.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/ring_buffer_benchmark.o: defined in discarded section
> `.text.exit' of kernel/trace/ring_buffer_benchmark.o
> `_GLOBAL__sub_D_00100_1_ring_buffer_benchmark.c' referenced in section
> `.fini_array.00100' of kernel/trace/ring_buffer_benchmark.o: defined
> in discarded section `.text.exit' of
> kernel/trace/ring_buffer_benchmark.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace.o: defined in discarded section `.text.exit' of
> kernel/trace/trace.o
> `_GLOBAL__sub_D_00100_1_ns2usecs' referenced in section
> `.fini_array.00100' of kernel/trace/trace.o: defined in discarded
> section `.text.exit' of kernel/trace/trace.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_output.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_output.o
> `_GLOBAL__sub_D_00100_1_trace_event_sem' referenced in section
> `.fini_array.00100' of kernel/trace/trace_output.o: defined in
> discarded section `.text.exit' of kernel/trace/trace_output.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_seq.o: defined in discarded section `.text.exit' of
> kernel/trace/trace_seq.o
> `_GLOBAL__sub_D_00100_1_trace_print_seq' referenced in section
> `.fini_array.00100' of kernel/trace/trace_seq.o: defined in discarded
> section `.text.exit' of kernel/trace/trace_seq.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_stat.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_stat.o
> `_GLOBAL__sub_D_00100_1_register_stat_tracer' referenced in section
> `.fini_array.00100' of kernel/trace/trace_stat.o: defined in discarded
> section `.text.exit' of kernel/trace/trace_stat.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_printk.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_printk.o
> `_GLOBAL__sub_D_00100_1_trace_printk_control' referenced in section
> `.fini_array.00100' of kernel/trace/trace_printk.o: defined in
> discarded section `.text.exit' of kernel/trace/trace_printk.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_sched_switch.o: defined in discarded section
> `.text.exit' of kernel/trace/trace_sched_switch.o
> `_GLOBAL__sub_D_00100_1_tracing_start_cmdline_record' referenced in
> section `.fini_array.00100' of kernel/trace/trace_sched_switch.o:
> defined in discarded section `.text.exit' of
> kernel/trace/trace_sched_switch.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_functions.o: defined in discarded section
> `.text.exit' of kernel/trace/trace_functions.o
> `_GLOBAL__sub_D_00100_1_ftrace_create_function_files' referenced in
> section `.fini_array.00100' of kernel/trace/trace_functions.o: defined
> in discarded section `.text.exit' of

Re: linux-next: build warnings from the build of Linus' tree

2018-08-28 Thread Greentime Hu

Arnd Bergmann  於 2018年8月24日 週五 下午8:48寫道：
>
> On Fri, Aug 24, 2018 at 10:23 AM Masami Hiramatsu  wrote:
> >
> > On Fri, 24 Aug 2018 13:32:06 +1000
> > Stephen Rothwell  wrote:
> >
> > > Hi all,
> > >
> > > After merging the origin tree, today's linux-next build (powerpc
> > > allyesconfig) produced these warnings:
> > >
> > > Maybe introduced by commit
> > >
> > >   6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
> > >
> > > I am guessing, but that is the only new thing that affects all of
> > > kernel/trace ...
> >
> > Yes, I agree. But I just followed Documentation/dev-tools/gcov.rst
> > to enable profiling in kernel/trace. Hmm, doesn't ppc64 support
> > GCOV_PROFILE?  (But as far as I can see, ARCH_HAS_GCOV_PROFILE_ALL
> > is enabled in arch/powerpc/Kconfig)
> >
> > Anyway, I'll try to reproduce it.
>
> Thje same commit causes a link failure on ARM with a randconfig
> kernel (see https://pastebin.com/KspjpyKG for the .config):
>
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_clock.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_clock.o
> `_GLOBAL__sub_D_00100_1_trace_clock_local' referenced in section
> `.fini_array.00100' of kernel/trace/trace_clock.o: defined in
> discarded section `.text.exit' of kernel/trace/trace_clock.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/ftrace.o: defined in discarded section `.text.exit' of
> kernel/trace/ftrace.o
> `_GLOBAL__sub_D_00100_1_function_trace_op' referenced in section
> `.fini_array.00100' of kernel/trace/ftrace.o: defined in discarded
> section `.text.exit' of kernel/trace/ftrace.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/ring_buffer.o: defined in discarded section `.text.exit'
> of kernel/trace/ring_buffer.o
> `_GLOBAL__sub_D_00100_1_ring_buffer_print_entry_header' referenced in
> section `.fini_array.00100' of kernel/trace/ring_buffer.o: defined in
> discarded section `.text.exit' of kernel/trace/ring_buffer.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/ring_buffer_benchmark.o: defined in discarded section
> `.text.exit' of kernel/trace/ring_buffer_benchmark.o
> `_GLOBAL__sub_D_00100_1_ring_buffer_benchmark.c' referenced in section
> `.fini_array.00100' of kernel/trace/ring_buffer_benchmark.o: defined
> in discarded section `.text.exit' of
> kernel/trace/ring_buffer_benchmark.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace.o: defined in discarded section `.text.exit' of
> kernel/trace/trace.o
> `_GLOBAL__sub_D_00100_1_ns2usecs' referenced in section
> `.fini_array.00100' of kernel/trace/trace.o: defined in discarded
> section `.text.exit' of kernel/trace/trace.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_output.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_output.o
> `_GLOBAL__sub_D_00100_1_trace_event_sem' referenced in section
> `.fini_array.00100' of kernel/trace/trace_output.o: defined in
> discarded section `.text.exit' of kernel/trace/trace_output.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_seq.o: defined in discarded section `.text.exit' of
> kernel/trace/trace_seq.o
> `_GLOBAL__sub_D_00100_1_trace_print_seq' referenced in section
> `.fini_array.00100' of kernel/trace/trace_seq.o: defined in discarded
> section `.text.exit' of kernel/trace/trace_seq.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_stat.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_stat.o
> `_GLOBAL__sub_D_00100_1_register_stat_tracer' referenced in section
> `.fini_array.00100' of kernel/trace/trace_stat.o: defined in discarded
> section `.text.exit' of kernel/trace/trace_stat.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_printk.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_printk.o
> `_GLOBAL__sub_D_00100_1_trace_printk_control' referenced in section
> `.fini_array.00100' of kernel/trace/trace_printk.o: defined in
> discarded section `.text.exit' of kernel/trace/trace_printk.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_sched_switch.o: defined in discarded section
> `.text.exit' of kernel/trace/trace_sched_switch.o
> `_GLOBAL__sub_D_00100_1_tracing_start_cmdline_record' referenced in
> section `.fini_array.00100' of kernel/trace/trace_sched_switch.o:
> defined in discarded section `.text.exit' of
> kernel/trace/trace_sched_switch.o
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_functions.o: defined in discarded section
> `.text.exit' of kernel/trace/trace_functions.o
> `_GLOBAL__sub_D_00100_1_ftrace_create_function_files' referenced in
> section `.fini_array.00100' of kernel/trace/trace_functions.o: defined
> in discarded section `.text.exit' of

RE: Re: [PATCH] devfreq: Convert to using %pOFn instead of device_node.name

2018-08-28 Thread MyungJoo Ham

> Dear Rob,
> 
> On 2018년 08월 28일 10:52, Rob Herring wrote:
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> > 
> > Cc: Chanwoo Choi 
> > Cc: MyungJoo Ham 
> > Cc: Kyungmin Park 
> > Cc: Kukjin Kim 
> > Cc: Krzysztof Kozlowski 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Signed-off-by: Rob Herring 
> > ---
> >  drivers/devfreq/event/exynos-ppmu.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
[]
> 
> Acked-by: Chanwoo Choi 

Acked-by: MyungJoo Ham

RE: Re: [PATCH] devfreq: Convert to using %pOFn instead of device_node.name

2018-08-28 Thread MyungJoo Ham

> Dear Rob,
> 
> On 2018년 08월 28일 10:52, Rob Herring wrote:
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> > 
> > Cc: Chanwoo Choi 
> > Cc: MyungJoo Ham 
> > Cc: Kyungmin Park 
> > Cc: Kukjin Kim 
> > Cc: Krzysztof Kozlowski 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Signed-off-by: Rob Herring 
> > ---
> >  drivers/devfreq/event/exynos-ppmu.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
[]
> 
> Acked-by: Chanwoo Choi 

Acked-by: MyungJoo Ham

Re: [PATCH] x86/speculation/l1tf: fix off-by-one error when warning that system has too much RAM

2018-08-28 Thread Christopher Snowhill



On 08/23/2018 07:22 PM, Andre Tomt wrote:
> On 23. aug. 2018 17:44, Andi Kleen wrote:
>> On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
>>> Two users have reported [1] that they have an "extremely unlikely"
>>> system
>>> with more than MAX_PA/2 memory and L1TF mitigation is not effective.
>>> In fact
>>> it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to
>>> holes
>>> in the e820 map, the main region is almost 500MB over the 32GB limit:
>>
>> Ah I see it's a client part with very large DIMMs and someone being
>> very brave and using that much memory without ECC.
>
> FYI; It is also happening on Xeon E3v2 (Ivy Bridge generation) w/ 32GB
> of ECC RAM here, a low-end server part that officially supports up to
> 32GB.
>

Indeed, I must be "very brave" to not have chucked this CPU and
motherboard and RAM in the bin, and bought a new board, Xeon CPU, and
ECC RAM. Maybe I'll consider that in the future, when I again have
$1000+ to buy new kit. Which will probably be never, at this rate.

>> [    0.00] microcode: microcode updated early to revision 0x20,
>> date = 2018-04-10
>> [    0.029728] L1TF: System has more than MAX_PA/2 memory. L1TF
>> mitigation not effective.
>> [    1.063155] microcode: sig=0x306a9, pf=0x2, revision=0x20
>
>
>> processor    : 7
>> vendor_id    : GenuineIntel
>> cpu family    : 6
>> model    : 58
>> model name    : Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz
>> stepping    : 9
>> microcode    : 0x20
>> cpu MHz    : 3500.044
>> cache size    : 8192 KB
>> physical id    : 0
>> siblings    : 8
>> core id    : 3
>> cpu cores    : 4
>> apicid    : 7
>> initial apicid    : 7
>> fpu    : yes
>> fpu_exception    : yes
>> cpuid level    : 13
>> wp    : yes
>> flags    : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>> syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>> xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
>> ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
>> popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm
>> cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority
>> ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d
>> bugs    : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
>> bogomips    : 6602.15
>> clflush size    : 64
>> cache_alignment    : 64
>> address sizes    : 36 bits physical, 48 bits virtual
>> power management:
>
>



pEpkey.asc
Description: application/pgp-keys

Re: [PATCH] x86/speculation/l1tf: fix off-by-one error when warning that system has too much RAM

2018-08-28 Thread Christopher Snowhill



On 08/23/2018 07:22 PM, Andre Tomt wrote:
> On 23. aug. 2018 17:44, Andi Kleen wrote:
>> On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
>>> Two users have reported [1] that they have an "extremely unlikely"
>>> system
>>> with more than MAX_PA/2 memory and L1TF mitigation is not effective.
>>> In fact
>>> it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to
>>> holes
>>> in the e820 map, the main region is almost 500MB over the 32GB limit:
>>
>> Ah I see it's a client part with very large DIMMs and someone being
>> very brave and using that much memory without ECC.
>
> FYI; It is also happening on Xeon E3v2 (Ivy Bridge generation) w/ 32GB
> of ECC RAM here, a low-end server part that officially supports up to
> 32GB.
>

Indeed, I must be "very brave" to not have chucked this CPU and
motherboard and RAM in the bin, and bought a new board, Xeon CPU, and
ECC RAM. Maybe I'll consider that in the future, when I again have
$1000+ to buy new kit. Which will probably be never, at this rate.

>> [    0.00] microcode: microcode updated early to revision 0x20,
>> date = 2018-04-10
>> [    0.029728] L1TF: System has more than MAX_PA/2 memory. L1TF
>> mitigation not effective.
>> [    1.063155] microcode: sig=0x306a9, pf=0x2, revision=0x20
>
>
>> processor    : 7
>> vendor_id    : GenuineIntel
>> cpu family    : 6
>> model    : 58
>> model name    : Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz
>> stepping    : 9
>> microcode    : 0x20
>> cpu MHz    : 3500.044
>> cache size    : 8192 KB
>> physical id    : 0
>> siblings    : 8
>> core id    : 3
>> cpu cores    : 4
>> apicid    : 7
>> initial apicid    : 7
>> fpu    : yes
>> fpu_exception    : yes
>> cpuid level    : 13
>> wp    : yes
>> flags    : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>> syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>> xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
>> ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
>> popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm
>> cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority
>> ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d
>> bugs    : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
>> bogomips    : 6602.15
>> clflush size    : 64
>> cache_alignment    : 64
>> address sizes    : 36 bits physical, 48 bits virtual
>> power management:
>
>



pEpkey.asc
Description: application/pgp-keys

[PATCH] ARM: dts: imx7d-sdb: enable gpio buttons as wakeup source

This patch enables i.MX7D SDB board's below GPIO buttons
as wakeup sources:

S1(FUNC1): KEY_VOLUMEUP
S3(FUNC2): KEY_VOLUMEDOWN

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx7d-sdb.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index c9b3c60..f1bafda 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -27,12 +27,14 @@
label = "Volume Up";
gpios = < 11 GPIO_ACTIVE_LOW>;
linux,code = ;
+   wakeup-source;
};
 
volume-down {
label = "Volume Down";
gpios = < 10 GPIO_ACTIVE_LOW>;
linux,code = ;
+   wakeup-source;
};
};
 
-- 
2.7.4

[PATCH] ARM: dts: imx7d-sdb: enable gpio buttons as wakeup source

This patch enables i.MX7D SDB board's below GPIO buttons
as wakeup sources:

S1(FUNC1): KEY_VOLUMEUP
S3(FUNC2): KEY_VOLUMEDOWN

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx7d-sdb.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index c9b3c60..f1bafda 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -27,12 +27,14 @@
label = "Volume Up";
gpios = < 11 GPIO_ACTIVE_LOW>;
linux,code = ;
+   wakeup-source;
};
 
volume-down {
label = "Volume Down";
gpios = < 10 GPIO_ACTIVE_LOW>;
linux,code = ;
+   wakeup-source;
};
};
 
-- 
2.7.4

Flushing user entries for kernel mappings in x86

2018-08-28 Thread Nadav Amit

Hello Andy,

Is there a reason for __flush_tlb_one_kernel() to flush the PTE not only in
the kernel address space, but also in the user one (as part of
__flush_tlb_one_user)? [ I obviously regard the case when PTI is on ].

Thanks,
Nadav

Flushing user entries for kernel mappings in x86

2018-08-28 Thread Nadav Amit

Hello Andy,

Is there a reason for __flush_tlb_one_kernel() to flush the PTE not only in
the kernel address space, but also in the user one (as part of
__flush_tlb_one_user)? [ I obviously regard the case when PTI is on ].

Thanks,
Nadav

Re: linux-next: build failure after merge of the spi tree

2018-08-28 Thread Baolin Wang

Hi Mark,

On 29 August 2018 at 08:33, Stephen Rothwell  wrote:
> Hi Mark,
>
> After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/linux/clk.h:16,
>  from drivers/spi/spi-sprd.c:4:
> drivers/spi/spi-sprd.c: In function 'sprd_spi_init_hw':
> drivers/spi/spi-sprd.c:462:29: error: 'struct spi_transfer' has no member 
> named 'word_delay'
>   word_delay = clamp_t(u16, t->word_delay, SPRD_SPI_MIN_DELAY_CYCLE,
>  ^~
>
> (and many more)
>
> Caused by commit
>
>   e7d973a31c24 ("spi: sprd: Add SPI driver for Spreadtrum SC9860")
>
> I have used the spi tree from next-20180828 for today.

You missed one patch (spi: Introduce one new field to set word delay),
could you apply this patch into your next branch? Thanks.

https://patchwork.kernel.org/patch/10567387/

-- 
Baolin Wang
Best Regards

Re: linux-next: build failure after merge of the spi tree

2018-08-28 Thread Baolin Wang

Hi Mark,

On 29 August 2018 at 08:33, Stephen Rothwell  wrote:
> Hi Mark,
>
> After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/linux/clk.h:16,
>  from drivers/spi/spi-sprd.c:4:
> drivers/spi/spi-sprd.c: In function 'sprd_spi_init_hw':
> drivers/spi/spi-sprd.c:462:29: error: 'struct spi_transfer' has no member 
> named 'word_delay'
>   word_delay = clamp_t(u16, t->word_delay, SPRD_SPI_MIN_DELAY_CYCLE,
>  ^~
>
> (and many more)
>
> Caused by commit
>
>   e7d973a31c24 ("spi: sprd: Add SPI driver for Spreadtrum SC9860")
>
> I have used the spi tree from next-20180828 for today.

You missed one patch (spi: Introduce one new field to set word delay),
could you apply this patch into your next branch? Thanks.

https://patchwork.kernel.org/patch/10567387/

-- 
Baolin Wang
Best Regards

RE: [PATCH 2/2] ARM: dts: imx6sll: add gpio clocks

Hi, Shawn
I saw v4.19-rc1 is created, can you please apply this patch?

Anson Huang
Best Regards!


> -Original Message-
> From: Shawn Guo 
> Sent: Thursday, July 12, 2018 10:52 AM
> To: Anson Huang 
> Cc: s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
> mturque...@baylibre.com; sb...@kernel.org; A.s. Dong
> ; Jacky Bai ; dl-linux-imx
> ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org
> Subject: Re: [PATCH 2/2] ARM: dts: imx6sll: add gpio clocks
> 
> On Fri, Jun 22, 2018 at 02:32:34PM +0800, Anson Huang wrote:
> > i.MX6SLL has GPIO clock gates in CCM CCGR, add clock property for GPIO
> > driver to make sure all GPIO banks work as expected.
> >
> > Signed-off-by: Anson Huang 
> 
> I tried to create a topic branch for this patch with dependent clk branch 
> merged
> in.  But it turns out to be difficult and not worth the effort, because too 
> many
> imx6sll patches need to be moved out from imx/dt branch, and some imx6sll
> changes are mixed with other SoCs.
> Let's apply this in next cycle.  Ping me when 4.19-rc1 is available.
> 
> Shawn

RE: [PATCH 2/2] ARM: dts: imx6sll: add gpio clocks

Hi, Shawn
I saw v4.19-rc1 is created, can you please apply this patch?

Anson Huang
Best Regards!


> -Original Message-
> From: Shawn Guo 
> Sent: Thursday, July 12, 2018 10:52 AM
> To: Anson Huang 
> Cc: s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
> mturque...@baylibre.com; sb...@kernel.org; A.s. Dong
> ; Jacky Bai ; dl-linux-imx
> ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org
> Subject: Re: [PATCH 2/2] ARM: dts: imx6sll: add gpio clocks
> 
> On Fri, Jun 22, 2018 at 02:32:34PM +0800, Anson Huang wrote:
> > i.MX6SLL has GPIO clock gates in CCM CCGR, add clock property for GPIO
> > driver to make sure all GPIO banks work as expected.
> >
> > Signed-off-by: Anson Huang 
> 
> I tried to create a topic branch for this patch with dependent clk branch 
> merged
> in.  But it turns out to be difficult and not worth the effort, because too 
> many
> imx6sll patches need to be moved out from imx/dt branch, and some imx6sll
> changes are mixed with other SoCs.
> Let's apply this in next cycle.  Ping me when 4.19-rc1 is available.
> 
> Shawn

Re: [PATCH v3] modules_install: make missing $DEPMOD a warning instead of an error

2018-08-28 Thread Masahiro Yamada

Hi Randy

2018-08-29 4:55 GMT+09:00 Randy Dunlap :
> On 08/23/2018 09:20 PM, Masahiro Yamada wrote:
>> Hi Randy,
>>
>>
>> 2018-08-24 3:13 GMT+09:00 Randy Dunlap :
>>> From: Randy Dunlap 
>>>
>>> When $DEPMOD is not found, only print a warning instead of exiting
>>> with an error message and error status.
>>
>>
>> Could you add the motivation of this change
>> (as Nikolaus reported) ?
>>
>> Without the reason recorded in git-log,
>> somebody may wonder why this commit is useful.
>>
>
> Added for v4.

Thanks.




>> BTW, if System.map is missing, depmod is silently skipped.
>>
>>
>> I think if System.map is missing, a user is doing something wrong,
>> but you could do like this:
>>
>> $ make mrproper
>>[snip]
>> $ make defconfig
>>[snip]
>> $ make modules
>>[snip]
>> $ make modules_install
>>   INSTALL drivers/thermal/x86_pkg_temp_thermal.ko
>>   INSTALL fs/efivarfs/efivarfs.ko
>>   INSTALL net/ipv4/netfilter/ipt_MASQUERADE.ko
>>   INSTALL net/ipv4/netfilter/iptable_nat.ko
>>   INSTALL net/ipv4/netfilter/nf_log_arp.ko
>>   INSTALL net/ipv4/netfilter/nf_log_ipv4.ko
>>   INSTALL net/ipv4/netfilter/nf_nat_ipv4.ko
>>   INSTALL net/ipv6/netfilter/nf_log_ipv6.ko
>>   INSTALL net/netfilter/nf_log_common.ko
>>   INSTALL net/netfilter/nf_nat.ko
>>   INSTALL net/netfilter/nf_nat_ftp.ko
>>   INSTALL net/netfilter/nf_nat_irc.ko
>>   INSTALL net/netfilter/nf_nat_sip.ko
>>   INSTALL net/netfilter/xt_LOG.ko
>>   INSTALL net/netfilter/xt_addrtype.ko
>>   INSTALL net/netfilter/xt_mark.ko
>>   INSTALL net/netfilter/xt_nat.ko
>>   DEPMOD  4.18.0+
>>
>>
>> The log looks like all the process went well,
>> but depmod is actually skipped because System.map is
>> generated by "make vmlinux"
>>
>>
>> What do you think we should do about this case?
>>
>> Skip depmod silently?
>> Make it fail?
>> Print noisy warning like missing depmod case?
>
> Since this shouldn't be happening, I prefer the noisy warning message
> like the missing depmod case.
>
> Do you want a separate patch for that?


Yes.  Could you send a patch?



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v8 4/8] media: platform: Add Cedrus VPU decoder driver

2018-08-28 Thread Ezequiel Garcia

On Tue, 2018-08-28 at 09:34 +0200, Paul Kocialkowski wrote:
> This introduces the Cedrus VPU driver that supports the VPU found in
> Allwinner SoCs, also known as Video Engine. It is implemented through
> a v4l2 m2m decoder device and a media device (used for media requests).
> So far, it only supports MPEG2 decoding.
> 
> Since this VPU is stateless, synchronization with media requests is
> required in order to ensure consistency between frame headers that
> contain metadata about the frame to process and the raw slice data that
> is used to generate the frame.
> 
> This driver was made possible thanks to the long-standing effort
> carried out by the linux-sunxi community in the interest of reverse
> engineering, documenting and implementing support for Allwinner VPU.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  MAINTAINERS   |   7 +
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/sunxi/Kconfig   |  15 +
>  drivers/staging/media/sunxi/Makefile  |   1 +
>  drivers/staging/media/sunxi/cedrus/Kconfig|  14 +
>  drivers/staging/media/sunxi/cedrus/Makefile   |   3 +
>  drivers/staging/media/sunxi/cedrus/cedrus.c   | 420 +
>  drivers/staging/media/sunxi/cedrus/cedrus.h   | 167 +
>  .../staging/media/sunxi/cedrus/cedrus_dec.c   | 116 
>  .../staging/media/sunxi/cedrus/cedrus_dec.h   |  28 +
>  .../staging/media/sunxi/cedrus/cedrus_hw.c| 322 ++
>  .../staging/media/sunxi/cedrus/cedrus_hw.h|  30 +
>  .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 235 +++
>  .../staging/media/sunxi/cedrus/cedrus_regs.h  | 233 +++
>  .../staging/media/sunxi/cedrus/cedrus_video.c | 574 ++
>  .../staging/media/sunxi/cedrus/cedrus_video.h |  32 +
>  17 files changed, 2200 insertions(+)
>  create mode 100644 drivers/staging/media/sunxi/Kconfig
>  create mode 100644 drivers/staging/media/sunxi/Makefile
>  create mode 100644 drivers/staging/media/sunxi/cedrus/Kconfig
>  create mode 100644 drivers/staging/media/sunxi/cedrus/Makefile
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_regs.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 435e6c08c694..08065d53c69d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -656,6 +656,13 @@ L:   linux-cry...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/crypto/sunxi-ss/
>  
> +ALLWINNER VPU DRIVER
> +M:   Maxime Ripard 
> +M:   Paul Kocialkowski 
> +L:   linux-me...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/staging/media/sunxi/cedrus/
> +
>  ALPHA PORT
>  M:   Richard Henderson 
>  M:   Ivan Kokshaysky 
> diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
> index db5cf67047ad..b3620a8f2d9f 100644
> --- a/drivers/staging/media/Kconfig
> +++ b/drivers/staging/media/Kconfig
> @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
>  
>  source "drivers/staging/media/omap4iss/Kconfig"
>  
> +source "drivers/staging/media/sunxi/Kconfig"
> +
>  source "drivers/staging/media/tegra-vde/Kconfig"
>  
>  source "drivers/staging/media/zoran/Kconfig"
> diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
> index 503fbe47fa58..42948f805548 100644
> --- a/drivers/staging/media/Makefile
> +++ b/drivers/staging/media/Makefile
> @@ -5,5 +5,6 @@ obj-$(CONFIG_SOC_CAMERA_IMX074)   += imx074/
>  obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031/
>  obj-$(CONFIG_VIDEO_DM365_VPFE)   += davinci_vpfe/
>  obj-$(CONFIG_VIDEO_OMAP4)+= omap4iss/
> +obj-$(CONFIG_VIDEO_SUNXI)+= sunxi/
>  obj-$(CONFIG_TEGRA_VDE)  += tegra-vde/
>  obj-$(CONFIG_VIDEO_ZORAN)+= zoran/
> diff --git a/drivers/staging/media/sunxi/Kconfig 
> b/drivers/staging/media/sunxi/Kconfig
> new file mode 100644
> index ..c78d92240ceb
> --- /dev/null
> +++ b/drivers/staging/media/sunxi/Kconfig
> @@ -0,0 +1,15 @@
> +config VIDEO_SUNXI
> + bool "Allwinner sunXi family Video Devices"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + help
> +   If you have an Allwinner SoC based on the sunXi family, say Y.
> +
> +   Note that this option doesn't include new drivers in the
> +   kernel: saying N will just cause Kconfig to skip all the
> +   questions about Allwinner media devices.
> +
> +if

Re: [PATCH v3] modules_install: make missing $DEPMOD a warning instead of an error

2018-08-28 Thread Masahiro Yamada

Hi Randy

2018-08-29 4:55 GMT+09:00 Randy Dunlap :
> On 08/23/2018 09:20 PM, Masahiro Yamada wrote:
>> Hi Randy,
>>
>>
>> 2018-08-24 3:13 GMT+09:00 Randy Dunlap :
>>> From: Randy Dunlap 
>>>
>>> When $DEPMOD is not found, only print a warning instead of exiting
>>> with an error message and error status.
>>
>>
>> Could you add the motivation of this change
>> (as Nikolaus reported) ?
>>
>> Without the reason recorded in git-log,
>> somebody may wonder why this commit is useful.
>>
>
> Added for v4.

Thanks.




>> BTW, if System.map is missing, depmod is silently skipped.
>>
>>
>> I think if System.map is missing, a user is doing something wrong,
>> but you could do like this:
>>
>> $ make mrproper
>>[snip]
>> $ make defconfig
>>[snip]
>> $ make modules
>>[snip]
>> $ make modules_install
>>   INSTALL drivers/thermal/x86_pkg_temp_thermal.ko
>>   INSTALL fs/efivarfs/efivarfs.ko
>>   INSTALL net/ipv4/netfilter/ipt_MASQUERADE.ko
>>   INSTALL net/ipv4/netfilter/iptable_nat.ko
>>   INSTALL net/ipv4/netfilter/nf_log_arp.ko
>>   INSTALL net/ipv4/netfilter/nf_log_ipv4.ko
>>   INSTALL net/ipv4/netfilter/nf_nat_ipv4.ko
>>   INSTALL net/ipv6/netfilter/nf_log_ipv6.ko
>>   INSTALL net/netfilter/nf_log_common.ko
>>   INSTALL net/netfilter/nf_nat.ko
>>   INSTALL net/netfilter/nf_nat_ftp.ko
>>   INSTALL net/netfilter/nf_nat_irc.ko
>>   INSTALL net/netfilter/nf_nat_sip.ko
>>   INSTALL net/netfilter/xt_LOG.ko
>>   INSTALL net/netfilter/xt_addrtype.ko
>>   INSTALL net/netfilter/xt_mark.ko
>>   INSTALL net/netfilter/xt_nat.ko
>>   DEPMOD  4.18.0+
>>
>>
>> The log looks like all the process went well,
>> but depmod is actually skipped because System.map is
>> generated by "make vmlinux"
>>
>>
>> What do you think we should do about this case?
>>
>> Skip depmod silently?
>> Make it fail?
>> Print noisy warning like missing depmod case?
>
> Since this shouldn't be happening, I prefer the noisy warning message
> like the missing depmod case.
>
> Do you want a separate patch for that?


Yes.  Could you send a patch?



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v8 4/8] media: platform: Add Cedrus VPU decoder driver

2018-08-28 Thread Ezequiel Garcia

On Tue, 2018-08-28 at 09:34 +0200, Paul Kocialkowski wrote:
> This introduces the Cedrus VPU driver that supports the VPU found in
> Allwinner SoCs, also known as Video Engine. It is implemented through
> a v4l2 m2m decoder device and a media device (used for media requests).
> So far, it only supports MPEG2 decoding.
> 
> Since this VPU is stateless, synchronization with media requests is
> required in order to ensure consistency between frame headers that
> contain metadata about the frame to process and the raw slice data that
> is used to generate the frame.
> 
> This driver was made possible thanks to the long-standing effort
> carried out by the linux-sunxi community in the interest of reverse
> engineering, documenting and implementing support for Allwinner VPU.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  MAINTAINERS   |   7 +
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/sunxi/Kconfig   |  15 +
>  drivers/staging/media/sunxi/Makefile  |   1 +
>  drivers/staging/media/sunxi/cedrus/Kconfig|  14 +
>  drivers/staging/media/sunxi/cedrus/Makefile   |   3 +
>  drivers/staging/media/sunxi/cedrus/cedrus.c   | 420 +
>  drivers/staging/media/sunxi/cedrus/cedrus.h   | 167 +
>  .../staging/media/sunxi/cedrus/cedrus_dec.c   | 116 
>  .../staging/media/sunxi/cedrus/cedrus_dec.h   |  28 +
>  .../staging/media/sunxi/cedrus/cedrus_hw.c| 322 ++
>  .../staging/media/sunxi/cedrus/cedrus_hw.h|  30 +
>  .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 235 +++
>  .../staging/media/sunxi/cedrus/cedrus_regs.h  | 233 +++
>  .../staging/media/sunxi/cedrus/cedrus_video.c | 574 ++
>  .../staging/media/sunxi/cedrus/cedrus_video.h |  32 +
>  17 files changed, 2200 insertions(+)
>  create mode 100644 drivers/staging/media/sunxi/Kconfig
>  create mode 100644 drivers/staging/media/sunxi/Makefile
>  create mode 100644 drivers/staging/media/sunxi/cedrus/Kconfig
>  create mode 100644 drivers/staging/media/sunxi/cedrus/Makefile
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_regs.h
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.c
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 435e6c08c694..08065d53c69d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -656,6 +656,13 @@ L:   linux-cry...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/crypto/sunxi-ss/
>  
> +ALLWINNER VPU DRIVER
> +M:   Maxime Ripard 
> +M:   Paul Kocialkowski 
> +L:   linux-me...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/staging/media/sunxi/cedrus/
> +
>  ALPHA PORT
>  M:   Richard Henderson 
>  M:   Ivan Kokshaysky 
> diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
> index db5cf67047ad..b3620a8f2d9f 100644
> --- a/drivers/staging/media/Kconfig
> +++ b/drivers/staging/media/Kconfig
> @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
>  
>  source "drivers/staging/media/omap4iss/Kconfig"
>  
> +source "drivers/staging/media/sunxi/Kconfig"
> +
>  source "drivers/staging/media/tegra-vde/Kconfig"
>  
>  source "drivers/staging/media/zoran/Kconfig"
> diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
> index 503fbe47fa58..42948f805548 100644
> --- a/drivers/staging/media/Makefile
> +++ b/drivers/staging/media/Makefile
> @@ -5,5 +5,6 @@ obj-$(CONFIG_SOC_CAMERA_IMX074)   += imx074/
>  obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031/
>  obj-$(CONFIG_VIDEO_DM365_VPFE)   += davinci_vpfe/
>  obj-$(CONFIG_VIDEO_OMAP4)+= omap4iss/
> +obj-$(CONFIG_VIDEO_SUNXI)+= sunxi/
>  obj-$(CONFIG_TEGRA_VDE)  += tegra-vde/
>  obj-$(CONFIG_VIDEO_ZORAN)+= zoran/
> diff --git a/drivers/staging/media/sunxi/Kconfig 
> b/drivers/staging/media/sunxi/Kconfig
> new file mode 100644
> index ..c78d92240ceb
> --- /dev/null
> +++ b/drivers/staging/media/sunxi/Kconfig
> @@ -0,0 +1,15 @@
> +config VIDEO_SUNXI
> + bool "Allwinner sunXi family Video Devices"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + help
> +   If you have an Allwinner SoC based on the sunXi family, say Y.
> +
> +   Note that this option doesn't include new drivers in the
> +   kernel: saying N will just cause Kconfig to skip all the
> +   questions about Allwinner media devices.
> +
> +if

Re: [PATCH v2 2/3] dt-bindings: net: dsa: Document B53 SRAB interrupts and registers

On Tue, Aug 28, 2018 at 10:54:19AM -0700, Florian Fainelli wrote:
> Document the Broadcom roboswitch Switch Register Access Block interrupt
> lines and additional register base addresses for port mux configuration
> and SGMII status/configuration registers.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  .../devicetree/bindings/net/dsa/b53.txt   | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt 
> b/Documentation/devicetree/bindings/net/dsa/b53.txt
> index 1811e1972a7a..5f1029e853b8 100644
> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
> @@ -46,6 +46,29 @@ Required properties:
>"brcm,bcm6328-switch"
>"brcm,bcm6368-switch" and the mandatory "brcm,bcm63xx-switch"
>  
> +Required properties for BCM585xx/586xx/88312 SoCs:
> +
> + - reg: a total of 3 register base addresses, the first one must be the
> +   Switch Register Access block base, the second is the port 5/4 mux
> +   configuration register and the third one is the SGMII configuration
> +   and status register base address.
> +
> + - interrupts: a total of 13 interrupts must be specified, in the following
> +   order: port 0-5, 7-8 link status change, then the integrated PHY 
> interrupt,
> +   then the timestamping interrupt and the sleep timer interrupts for ports
> +   5,7,8.

Bulleted lists would be easier to read.

> +
> +Optional properties for BCM585xx/586xx/88312 SoCs:
> +
> +  - reg-names: a total of 3 names matching the 3 base register address, must
> +be "srab", "mux_config" and "sgmii_config";

Here too, one per line please.

> +
> +  - interrupt-names: a total of 13 names matching the 13 interrupts specified
> +must be: "link_state_p0", "link_state_p1", "link_state_p2",
> +"link_state_p3", "link_state_p4", "link_state_p5", "link_state_p7",
> +"link_state_p8", "phy", "ts", "imp_sleep_timer_p5", "imp_sleep_timer_p7",
> +"imp_sleep_timer_p8"
> +
>  See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of 
> additional
>  required and optional properties.
>  
> -- 
> 2.17.1
>

Re: [PATCH v2 2/3] dt-bindings: net: dsa: Document B53 SRAB interrupts and registers

On Tue, Aug 28, 2018 at 10:54:19AM -0700, Florian Fainelli wrote:
> Document the Broadcom roboswitch Switch Register Access Block interrupt
> lines and additional register base addresses for port mux configuration
> and SGMII status/configuration registers.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  .../devicetree/bindings/net/dsa/b53.txt   | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt 
> b/Documentation/devicetree/bindings/net/dsa/b53.txt
> index 1811e1972a7a..5f1029e853b8 100644
> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
> @@ -46,6 +46,29 @@ Required properties:
>"brcm,bcm6328-switch"
>"brcm,bcm6368-switch" and the mandatory "brcm,bcm63xx-switch"
>  
> +Required properties for BCM585xx/586xx/88312 SoCs:
> +
> + - reg: a total of 3 register base addresses, the first one must be the
> +   Switch Register Access block base, the second is the port 5/4 mux
> +   configuration register and the third one is the SGMII configuration
> +   and status register base address.
> +
> + - interrupts: a total of 13 interrupts must be specified, in the following
> +   order: port 0-5, 7-8 link status change, then the integrated PHY 
> interrupt,
> +   then the timestamping interrupt and the sleep timer interrupts for ports
> +   5,7,8.

Bulleted lists would be easier to read.

> +
> +Optional properties for BCM585xx/586xx/88312 SoCs:
> +
> +  - reg-names: a total of 3 names matching the 3 base register address, must
> +be "srab", "mux_config" and "sgmii_config";

Here too, one per line please.

> +
> +  - interrupt-names: a total of 13 names matching the 13 interrupts specified
> +must be: "link_state_p0", "link_state_p1", "link_state_p2",
> +"link_state_p3", "link_state_p4", "link_state_p5", "link_state_p7",
> +"link_state_p8", "phy", "ts", "imp_sleep_timer_p5", "imp_sleep_timer_p7",
> +"imp_sleep_timer_p8"
> +
>  See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of 
> additional
>  required and optional properties.
>  
> -- 
> 2.17.1
>

Re: [PATCH] riscv: Drop setup_initrd

2018-08-28 Thread Palmer Dabbelt


On Tue, 28 Aug 2018 17:36:28 PDT (-0700), li...@roeck-us.net wrote:

On 08/28/2018 05:09 PM, Palmer Dabbelt wrote:

On Tue, 28 Aug 2018 15:12:38 PDT (-0700), li...@roeck-us.net wrote:

On Tue, Aug 28, 2018 at 03:03:00PM -0700, Palmer Dabbelt wrote:

On Tue, 28 Aug 2018 14:59:59 PDT (-0700), li...@roeck-us.net wrote:
>On Tue, Aug 28, 2018 at 11:46:09PM +0200, Andreas Schwab wrote:
>>On Aug 28 2018, Guenter Roeck  wrote:
>>
>>> On Tue, Aug 28, 2018 at 01:10:20PM -0700, Palmer Dabbelt wrote:
 On Thu, 09 Aug 2018 21:11:40 PDT (-0700), li...@roeck-us.net wrote:
 >setup_initrd() does not appear to serve a practical purpose other than
 >preventing qemu boots with "-initrd" parameter, so let's drop it.
 >
 >Signed-off-by: Guenter Roeck 
 >---
 > arch/riscv/kernel/setup.c | 39 ---
 > 1 file changed, 39 deletions(-)
 >
 >diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
 >index 2e56af3281f8..579f58a42974 100644
 >--- a/arch/riscv/kernel/setup.c
 >+++ b/arch/riscv/kernel/setup.c
 >@@ -82,41 +82,6 @@ EXPORT_SYMBOL(empty_zero_page);
 > /* The lucky hart to first increment this variable will boot the other 
cores */
 > atomic_t hart_lottery;
 >
 >-#ifdef CONFIG_BLK_DEV_INITRD
 >-static void __init setup_initrd(void)
 >-{
 >-    extern char __initramfs_start[];
 >-    extern unsigned long __initramfs_size;
 >-    unsigned long size;
 >-
 >-    if (__initramfs_size > 0) {
 >-    initrd_start = (unsigned long)(&__initramfs_start);
 >-    initrd_end = initrd_start + __initramfs_size;
 >-    }
>>>
>>> The underlying problem is probably that __initramfs_size == 512 even
>>> if there is no embedded initrd. Result is that initrd_start and initrd_end
>>> are always overwritten, even if provided and even if there is no embedded
>>> initrd. Result is that initrd_start and initrd_end are always overwritten,
>>> and -initrd from the qemu command line is always ignored.
>>>
>>> A less invasive fix than mine would be
>>>
>>> -    if (__initramfs_size > 0) {
>>> +    if (__initramfs_size > 0 && !initrd_start) {
>>>
>>> Any chance you can test that with your setup ?
>>
>>You should just delete the last four lines above.  They serve no purpose.
>>
>
>You mean the entire if() statement plus the variable declarations ?
>
>That works for me, for both embedded initrd and initrd specified with
>-initrd option, but we still need someone to test if it works for
>Palmer's use case, ie with vmlinux (and possibly initrd) embedded in
>bbl.

This still boots my Fedora images

   diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
   index db20dc630e7e..aee603123030 100644
   --- a/arch/riscv/kernel/setup.c
   +++ b/arch/riscv/kernel/setup.c
   @@ -85,15 +85,8 @@ atomic_t hart_lottery;
    #ifdef CONFIG_BLK_DEV_INITRD
    static void __init setup_initrd(void)
    {
   -    extern char __initramfs_start[];
   -    extern unsigned long __initramfs_size;
    unsigned long size;
   -    if (__initramfs_size > 0) {
   -    initrd_start = (unsigned long)(&__initramfs_start);
   -    initrd_end = initrd_start + __initramfs_size;
   -    }
   -
    if (initrd_start >= initrd_end) {
    printk(KERN_INFO "initrd not found or empty");
    goto disable;

but I have not tried an integrated initramfs.


I tested the above both with external initrd and with integrated
initramfs; both work for me.

Should I resend my patch, using the above, or do you want to create
a patch yourself ?


You should send one, then it'll go through my regular pre-PR testing flow to 
make sure it works on my end.  I just never trust these inline patches to be 
exact, even if it's unlikely there's any confusion on a patch this simple (at 
least, mechanically simple -- I'm afraid I still don't understand why the logic 
is incorrect).



Done.

There is no need to override initrd_start and initrd_end; populate_rootfs()
uses __initramfs_start and __initramfs_size directly when loading a built-in
initramfs. initrd_start and initrd_end, on the other side, are for an external
initrd, loaded separately (and initialized in __early_init_dt_declare_initrd()).


OK, that makes sense.  I dropped your patch onto for-next, assuming nothing's 
gone wrong it should go in next week.  It boots a Fedora rootfs for me.


Thanks!

Re: [PATCH] riscv: Drop setup_initrd

2018-08-28 Thread Palmer Dabbelt


On Tue, 28 Aug 2018 17:36:28 PDT (-0700), li...@roeck-us.net wrote:

On 08/28/2018 05:09 PM, Palmer Dabbelt wrote:

On Tue, 28 Aug 2018 15:12:38 PDT (-0700), li...@roeck-us.net wrote:

On Tue, Aug 28, 2018 at 03:03:00PM -0700, Palmer Dabbelt wrote:

On Tue, 28 Aug 2018 14:59:59 PDT (-0700), li...@roeck-us.net wrote:
>On Tue, Aug 28, 2018 at 11:46:09PM +0200, Andreas Schwab wrote:
>>On Aug 28 2018, Guenter Roeck  wrote:
>>
>>> On Tue, Aug 28, 2018 at 01:10:20PM -0700, Palmer Dabbelt wrote:
 On Thu, 09 Aug 2018 21:11:40 PDT (-0700), li...@roeck-us.net wrote:
 >setup_initrd() does not appear to serve a practical purpose other than
 >preventing qemu boots with "-initrd" parameter, so let's drop it.
 >
 >Signed-off-by: Guenter Roeck 
 >---
 > arch/riscv/kernel/setup.c | 39 ---
 > 1 file changed, 39 deletions(-)
 >
 >diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
 >index 2e56af3281f8..579f58a42974 100644
 >--- a/arch/riscv/kernel/setup.c
 >+++ b/arch/riscv/kernel/setup.c
 >@@ -82,41 +82,6 @@ EXPORT_SYMBOL(empty_zero_page);
 > /* The lucky hart to first increment this variable will boot the other 
cores */
 > atomic_t hart_lottery;
 >
 >-#ifdef CONFIG_BLK_DEV_INITRD
 >-static void __init setup_initrd(void)
 >-{
 >-    extern char __initramfs_start[];
 >-    extern unsigned long __initramfs_size;
 >-    unsigned long size;
 >-
 >-    if (__initramfs_size > 0) {
 >-    initrd_start = (unsigned long)(&__initramfs_start);
 >-    initrd_end = initrd_start + __initramfs_size;
 >-    }
>>>
>>> The underlying problem is probably that __initramfs_size == 512 even
>>> if there is no embedded initrd. Result is that initrd_start and initrd_end
>>> are always overwritten, even if provided and even if there is no embedded
>>> initrd. Result is that initrd_start and initrd_end are always overwritten,
>>> and -initrd from the qemu command line is always ignored.
>>>
>>> A less invasive fix than mine would be
>>>
>>> -    if (__initramfs_size > 0) {
>>> +    if (__initramfs_size > 0 && !initrd_start) {
>>>
>>> Any chance you can test that with your setup ?
>>
>>You should just delete the last four lines above.  They serve no purpose.
>>
>
>You mean the entire if() statement plus the variable declarations ?
>
>That works for me, for both embedded initrd and initrd specified with
>-initrd option, but we still need someone to test if it works for
>Palmer's use case, ie with vmlinux (and possibly initrd) embedded in
>bbl.

This still boots my Fedora images

   diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
   index db20dc630e7e..aee603123030 100644
   --- a/arch/riscv/kernel/setup.c
   +++ b/arch/riscv/kernel/setup.c
   @@ -85,15 +85,8 @@ atomic_t hart_lottery;
    #ifdef CONFIG_BLK_DEV_INITRD
    static void __init setup_initrd(void)
    {
   -    extern char __initramfs_start[];
   -    extern unsigned long __initramfs_size;
    unsigned long size;
   -    if (__initramfs_size > 0) {
   -    initrd_start = (unsigned long)(&__initramfs_start);
   -    initrd_end = initrd_start + __initramfs_size;
   -    }
   -
    if (initrd_start >= initrd_end) {
    printk(KERN_INFO "initrd not found or empty");
    goto disable;

but I have not tried an integrated initramfs.


I tested the above both with external initrd and with integrated
initramfs; both work for me.

Should I resend my patch, using the above, or do you want to create
a patch yourself ?


You should send one, then it'll go through my regular pre-PR testing flow to 
make sure it works on my end.  I just never trust these inline patches to be 
exact, even if it's unlikely there's any confusion on a patch this simple (at 
least, mechanically simple -- I'm afraid I still don't understand why the logic 
is incorrect).



Done.

There is no need to override initrd_start and initrd_end; populate_rootfs()
uses __initramfs_start and __initramfs_size directly when loading a built-in
initramfs. initrd_start and initrd_end, on the other side, are for an external
initrd, loaded separately (and initialized in __early_init_dt_declare_initrd()).


OK, that makes sense.  I dropped your patch onto for-next, assuming nothing's 
gone wrong it should go in next week.  It boots a Fedora rootfs for me.


Thanks!

Re: [PATCH v2 4/6] dt-bindings: remoteproc: Add PDC reset binding for Q6V5 PIL

On Fri, 24 Aug 2018 18:48:58 +0530, Sibi Sankar wrote:
> Add additional pdc_reset binding required for Q6V5 Modem PIL on
> SDM845 SoCs.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 4 
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring

Re: [PATCH v2 4/6] dt-bindings: remoteproc: Add PDC reset binding for Q6V5 PIL

On Fri, 24 Aug 2018 18:48:58 +0530, Sibi Sankar wrote:
> Add additional pdc_reset binding required for Q6V5 Modem PIL on
> SDM845 SoCs.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 4 
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring

[PATCH v3 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs

From: Channagoud Kadabi 

Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports error reporting for
Last Level Cache Controller (LLCC) of Tag RAM and Data RAM. Interrupts
are triggered when the errors happen in the cache, the driver handles
those interrupts and dumps the syndrome registers.

Signed-off-by: Channagoud Kadabi 
Signed-off-by: Venkata Narendra Kumar Gutta 
Co-developed-by: Venkata Narendra Kumar Gutta 
---
 MAINTAINERS|   8 +
 drivers/edac/Kconfig   |  22 ++
 drivers/edac/Makefile  |   1 +
 drivers/edac/qcom_edac.c   | 421 +
 include/linux/soc/qcom/llcc-qcom.h |  24 +++
 5 files changed, 476 insertions(+)
 create mode 100644 drivers/edac/qcom_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a23427..0bff713 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5227,6 +5227,14 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/ti_edac.c
 
+EDAC-QUALCOMM
+M: Channagoud Kadabi 
+M: Venkata Narendra Kumar Gutta 
+L: linux-arm-...@vger.kernel.org
+L: linux-e...@vger.kernel.org
+S: Maintained
+F: drivers/edac/qcom_edac.c
+
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 57304b2..df58957 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -460,4 +460,26 @@ config EDAC_TI
  Support for error detection and correction on the
   TI SoCs.
 
+config EDAC_QCOM
+   tristate "QCOM EDAC Controller"
+   depends on EDAC
+   help
+ Support for error detection and correction on the
+ QCOM SoCs.
+
+ This driver reports Single Bit Errors (SBEs) and Double Bit Errors 
(DBEs).
+ As of now, it supports error reporting for Last Level Cache 
Controller (LLCC)
+ of Tag RAM and Data RAM.
+
+config EDAC_QCOM_LLCC
+   tristate "QCOM EDAC Controller for LLCC Cache"
+   depends on EDAC_QCOM && QCOM_LLCC
+   help
+ Support for error detection and correction on the
+ QCOM LLCC cache. Report errors caught by LLCC ECC
+ mechanism.
+
+ For debugging issues having to do with stability and overall system
+ health, you should probably say 'Y' here.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 02b43a7..716096d 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_EDAC_ALTERA) += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
 obj-$(CONFIG_EDAC_TI)  += ti_edac.o
+obj-$(CONFIG_EDAC_QCOM)+= qcom_edac.o
diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
new file mode 100644
index 000..871ed07
--- /dev/null
+++ b/drivers/edac/qcom_edac.c
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "edac_mc.h"
+#include "edac_device.h"
+
+#define EDAC_LLCC   "qcom_llcc"
+
+#define LLCC_ERP_PANIC_ON_UE1
+
+#define TRP_SYN_REG_CNT 6
+#define DRP_SYN_REG_CNT 8
+
+#define LLCC_COMMON_STATUS0 0x0003000c
+#define LLCC_LB_CNT_MASKGENMASK(31, 28)
+#define LLCC_LB_CNT_SHIFT   28
+
+/* Single & double bit syndrome register offsets */
+#define TRP_ECC_SB_ERR_SYN0 0x0002304c
+#define TRP_ECC_DB_ERR_SYN0 0x00020370
+#define DRP_ECC_SB_ERR_SYN0 0x0004204c
+#define DRP_ECC_DB_ERR_SYN0 0x00042070
+
+/* Error register offsets */
+#define TRP_ECC_ERROR_STATUS1   0x00020348
+#define TRP_ECC_ERROR_STATUS0   0x00020344
+#define DRP_ECC_ERROR_STATUS1   0x00042048
+#define DRP_ECC_ERROR_STATUS0   0x00042044
+
+/* TRP, DRP interrupt register offsets */
+#define DRP_INTERRUPT_STATUS0x00041000
+#define TRP_INTERRUPT_0_STATUS  0x00020480
+#define DRP_INTERRUPT_CLEAR 0x00041008
+#define DRP_ECC_ERROR_CNTR_CLEAR0x00040004
+#define TRP_INTERRUPT_0_CLEAR   0x00020484
+#define TRP_ECC_ERROR_CNTR_CLEAR0x00020440
+
+/* Mask and shift macros */
+#define ECC_DB_ERR_COUNT_MASK   GENMASK(4, 0)
+#define ECC_DB_ERR_WAYS_MASKGENMASK(31, 16)
+#define ECC_DB_ERR_WAYS_SHIFT   BIT(4)
+
+#define ECC_SB_ERR_COUNT_MASK   GENMASK(23, 16)
+#define ECC_SB_ERR_COUNT_SHIFT  BIT(4)
+#define ECC_SB_ERR_WAYS_MASKGENMASK(15, 0)
+
+#define SB_ECC_ERRORBIT(0)
+#define DB_ECC_ERRORBIT(1)
+
+#define DRP_TRP_INT_CLEAR

[PATCH v3 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs

From: Channagoud Kadabi 

Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports error reporting for
Last Level Cache Controller (LLCC) of Tag RAM and Data RAM. Interrupts
are triggered when the errors happen in the cache, the driver handles
those interrupts and dumps the syndrome registers.

Signed-off-by: Channagoud Kadabi 
Signed-off-by: Venkata Narendra Kumar Gutta 
Co-developed-by: Venkata Narendra Kumar Gutta 
---
 MAINTAINERS|   8 +
 drivers/edac/Kconfig   |  22 ++
 drivers/edac/Makefile  |   1 +
 drivers/edac/qcom_edac.c   | 421 +
 include/linux/soc/qcom/llcc-qcom.h |  24 +++
 5 files changed, 476 insertions(+)
 create mode 100644 drivers/edac/qcom_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a23427..0bff713 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5227,6 +5227,14 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/ti_edac.c
 
+EDAC-QUALCOMM
+M: Channagoud Kadabi 
+M: Venkata Narendra Kumar Gutta 
+L: linux-arm-...@vger.kernel.org
+L: linux-e...@vger.kernel.org
+S: Maintained
+F: drivers/edac/qcom_edac.c
+
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 57304b2..df58957 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -460,4 +460,26 @@ config EDAC_TI
  Support for error detection and correction on the
   TI SoCs.
 
+config EDAC_QCOM
+   tristate "QCOM EDAC Controller"
+   depends on EDAC
+   help
+ Support for error detection and correction on the
+ QCOM SoCs.
+
+ This driver reports Single Bit Errors (SBEs) and Double Bit Errors 
(DBEs).
+ As of now, it supports error reporting for Last Level Cache 
Controller (LLCC)
+ of Tag RAM and Data RAM.
+
+config EDAC_QCOM_LLCC
+   tristate "QCOM EDAC Controller for LLCC Cache"
+   depends on EDAC_QCOM && QCOM_LLCC
+   help
+ Support for error detection and correction on the
+ QCOM LLCC cache. Report errors caught by LLCC ECC
+ mechanism.
+
+ For debugging issues having to do with stability and overall system
+ health, you should probably say 'Y' here.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 02b43a7..716096d 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_EDAC_ALTERA) += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
 obj-$(CONFIG_EDAC_TI)  += ti_edac.o
+obj-$(CONFIG_EDAC_QCOM)+= qcom_edac.o
diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
new file mode 100644
index 000..871ed07
--- /dev/null
+++ b/drivers/edac/qcom_edac.c
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "edac_mc.h"
+#include "edac_device.h"
+
+#define EDAC_LLCC   "qcom_llcc"
+
+#define LLCC_ERP_PANIC_ON_UE1
+
+#define TRP_SYN_REG_CNT 6
+#define DRP_SYN_REG_CNT 8
+
+#define LLCC_COMMON_STATUS0 0x0003000c
+#define LLCC_LB_CNT_MASKGENMASK(31, 28)
+#define LLCC_LB_CNT_SHIFT   28
+
+/* Single & double bit syndrome register offsets */
+#define TRP_ECC_SB_ERR_SYN0 0x0002304c
+#define TRP_ECC_DB_ERR_SYN0 0x00020370
+#define DRP_ECC_SB_ERR_SYN0 0x0004204c
+#define DRP_ECC_DB_ERR_SYN0 0x00042070
+
+/* Error register offsets */
+#define TRP_ECC_ERROR_STATUS1   0x00020348
+#define TRP_ECC_ERROR_STATUS0   0x00020344
+#define DRP_ECC_ERROR_STATUS1   0x00042048
+#define DRP_ECC_ERROR_STATUS0   0x00042044
+
+/* TRP, DRP interrupt register offsets */
+#define DRP_INTERRUPT_STATUS0x00041000
+#define TRP_INTERRUPT_0_STATUS  0x00020480
+#define DRP_INTERRUPT_CLEAR 0x00041008
+#define DRP_ECC_ERROR_CNTR_CLEAR0x00040004
+#define TRP_INTERRUPT_0_CLEAR   0x00020484
+#define TRP_ECC_ERROR_CNTR_CLEAR0x00020440
+
+/* Mask and shift macros */
+#define ECC_DB_ERR_COUNT_MASK   GENMASK(4, 0)
+#define ECC_DB_ERR_WAYS_MASKGENMASK(31, 16)
+#define ECC_DB_ERR_WAYS_SHIFT   BIT(4)
+
+#define ECC_SB_ERR_COUNT_MASK   GENMASK(23, 16)
+#define ECC_SB_ERR_COUNT_SHIFT  BIT(4)
+#define ECC_SB_ERR_WAYS_MASKGENMASK(15, 0)
+
+#define SB_ECC_ERRORBIT(0)
+#define DB_ECC_ERRORBIT(1)
+
+#define DRP_TRP_INT_CLEAR

Re: [PATCH v2 1/6] dt-bindings: reset: Add PDC Global binding for SDM845 SoCs

On Fri, 24 Aug 2018 18:48:55 +0530, Sibi Sankar wrote:
> Add PDC Global(Power Domain Controller) binding for SDM845 SoCs.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  .../bindings/reset/qcom,pdc-global.txt| 52 +++
>  include/dt-bindings/reset/qcom,sdm845-pdc.h   | 20 +++
>  2 files changed, 72 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/reset/qcom,pdc-global.txt
>  create mode 100644 include/dt-bindings/reset/qcom,sdm845-pdc.h
> 

Reviewed-by: Rob Herring

[PATCH v3 4/4] dt-bindings: msm: Update documentation of qcom,llcc

Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 .../devicetree/bindings/arm/msm/qcom,llcc.txt | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
index 5e85749..2e007dc 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
@@ -16,11 +16,26 @@ Properties:
 - reg:
Usage: required
Value Type: 
-   Definition: Start address and the the size of the register region.
+   Definition: The first element specifies the llcc base start address and
+   the size of the register region. The second element 
specifies
+   the llcc broadcast base address and size of the register 
region.
+
+- reg-names:
+Usage: required
+Value Type: 
+Definition: Register region names. Must be "llcc_base", 
"llcc_bcast_base".
+
+- interrupts:
+   Usage: required
+   Definition: The interrupt is associated with the llcc edac device.
+   It's used for llcc cache single and double bit error 
detection
+   and reporting.
 
 Example:
 
cache-controller@110 {
compatible = "qcom,sdm845-llcc";
-   reg = <0x110 0x25>;
+   reg = <0x110 0x20>, <0x130 0x5> ;
+   reg-names = "llcc_base", "llcc_bcast_base";
+   interrupts = ;
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 2/4] drivers: soc: Add support to register LLCC EDAC driver

Cache error reporting controller detects and reports single and
double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 18 --
 include/linux/soc/qcom/llcc-qcom.h |  2 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index a63640d..09c8bb0 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -224,7 +224,7 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
u32 attr0_val;
u32 max_cap_cacheline;
u32 sz;
-   int ret;
+   int ret = 0;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
 
@@ -282,6 +282,7 @@ int qcom_llcc_probe(struct platform_device *pdev,
struct resource *llcc_banks_res, *llcc_bcast_res;
void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
+   struct platform_device *llcc_edac;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
@@ -341,6 +342,19 @@ int qcom_llcc_probe(struct platform_device *pdev,
mutex_init(_data->lock);
platform_set_drvdata(pdev, drv_data);
 
-   return qcom_llcc_cfg_program(pdev);
+   ret = qcom_llcc_cfg_program(pdev);
+   if (ret)
+   return ret;
+
+   drv_data->ecc_irq = platform_get_irq(pdev, 0);
+   if (drv_data->ecc_irq >= 0) {
+   llcc_edac = platform_device_register_data(>dev,
+   "qcom_llcc_edac", -1, drv_data,
+   sizeof(*drv_data));
+   if (IS_ERR(llcc_edac))
+   dev_err(dev, "Failed to register llcc edac driver\n");
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(qcom_llcc_probe);
diff --git a/include/linux/soc/qcom/llcc-qcom.h 
b/include/linux/soc/qcom/llcc-qcom.h
index c681e79..2e4b34d 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -78,6 +78,7 @@ struct llcc_slice_config {
  * @num_banks: Number of llcc banks
  * @bitmap: Bit map to track the active slice ids
  * @offsets: Pointer to the bank offsets array
+ * @ecc_irq: interrupt for llcc cache error detection and reporting
  */
 struct llcc_drv_data {
struct regmap *regmap;
@@ -89,6 +90,7 @@ struct llcc_drv_data {
u32 num_banks;
unsigned long *bitmap;
u32 *offsets;
+   int ecc_irq;
 };
 
 #if IS_ENABLED(CONFIG_QCOM_LLCC)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 1/4] drivers: soc: Add broadcast base for Last Level Cache Controller (LLCC)

Currently, broadcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT). Add broadcast base in LLCC driver and use this for broadcast
writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 55 +++---
 include/linux/soc/qcom/llcc-qcom.h |  4 +--
 2 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index fcaad1a..a63640d 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -105,22 +105,24 @@ static int llcc_update_act_ctrl(u32 sid,
u32 slice_status;
int ret;
 
-   act_ctrl_reg = drv_data->bcast_off + LLCC_TRP_ACT_CTRLn(sid);
-   status_reg = drv_data->bcast_off + LLCC_TRP_STATUSn(sid);
+   act_ctrl_reg = LLCC_TRP_ACT_CTRLn(sid);
+   status_reg = LLCC_TRP_STATUSn(sid);
 
/* Set the ACTIVE trigger */
act_ctrl_reg_val |= ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
/* Clear the ACTIVE trigger */
act_ctrl_reg_val &= ~ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
-   ret = regmap_read_poll_timeout(drv_data->regmap, status_reg,
+   ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
  slice_status, !(slice_status & status),
  0, LLCC_STATUS_READ_DELAY);
return ret;
@@ -225,16 +227,13 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
int ret;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
-   u32 bcast_off = drv_data->bcast_off;
 
sz = drv_data->cfg_size;
llcc_table = drv_data->cfg;
 
for (i = 0; i < sz; i++) {
-   attr1_cfg = bcast_off +
-   LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
-   attr0_cfg = bcast_off +
-   LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
+   attr1_cfg = LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
+   attr0_cfg = LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
 
attr1_val = llcc_table[i].cache_mode;
attr1_val |= llcc_table[i].probe_target_ways <<
@@ -259,10 +258,12 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
attr0_val = llcc_table[i].res_ways & ATTR0_RES_WAYS_MASK;
attr0_val |= llcc_table[i].bonus_ways << ATTR0_BONUS_WAYS_SHIFT;
 
-   ret = regmap_write(drv_data->regmap, attr1_cfg, attr1_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr1_cfg,
+   attr1_val);
if (ret)
return ret;
-   ret = regmap_write(drv_data->regmap, attr0_cfg, attr0_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr0_cfg,
+   attr0_val);
if (ret)
return ret;
if (llcc_table[i].activate_on_init) {
@@ -278,24 +279,36 @@ int qcom_llcc_probe(struct platform_device *pdev,
 {
u32 num_banks;
struct device *dev = >dev;
-   struct resource *res;
-   void __iomem *base;
+   struct resource *llcc_banks_res, *llcc_bcast_res;
+   void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
return -ENOMEM;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   llcc_banks_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+   "llcc_base");
+   llcc_banks_base = devm_ioremap_resource(>dev, llcc_banks_res);
+   if (IS_ERR(llcc_banks_base))
+   return PTR_ERR(llcc_banks_base);
 
-   drv_data->regmap = devm_regmap_init_mmio(dev, base,
-   _regmap_config);
+   drv_data->regmap = devm_regmap_init_mmio(dev, llcc_banks_base,
+   _regmap_config);
if (IS_ERR(drv_data->regmap))
return

Re: [PATCH v2 1/6] dt-bindings: reset: Add PDC Global binding for SDM845 SoCs

On Fri, 24 Aug 2018 18:48:55 +0530, Sibi Sankar wrote:
> Add PDC Global(Power Domain Controller) binding for SDM845 SoCs.
> 
> Signed-off-by: Sibi Sankar 
> ---
>  .../bindings/reset/qcom,pdc-global.txt| 52 +++
>  include/dt-bindings/reset/qcom,sdm845-pdc.h   | 20 +++
>  2 files changed, 72 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/reset/qcom,pdc-global.txt
>  create mode 100644 include/dt-bindings/reset/qcom,sdm845-pdc.h
> 

Reviewed-by: Rob Herring

[PATCH v3 4/4] dt-bindings: msm: Update documentation of qcom,llcc

Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 .../devicetree/bindings/arm/msm/qcom,llcc.txt | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
index 5e85749..2e007dc 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
@@ -16,11 +16,26 @@ Properties:
 - reg:
Usage: required
Value Type: 
-   Definition: Start address and the the size of the register region.
+   Definition: The first element specifies the llcc base start address and
+   the size of the register region. The second element 
specifies
+   the llcc broadcast base address and size of the register 
region.
+
+- reg-names:
+Usage: required
+Value Type: 
+Definition: Register region names. Must be "llcc_base", 
"llcc_bcast_base".
+
+- interrupts:
+   Usage: required
+   Definition: The interrupt is associated with the llcc edac device.
+   It's used for llcc cache single and double bit error 
detection
+   and reporting.
 
 Example:
 
cache-controller@110 {
compatible = "qcom,sdm845-llcc";
-   reg = <0x110 0x25>;
+   reg = <0x110 0x20>, <0x130 0x5> ;
+   reg-names = "llcc_base", "llcc_bcast_base";
+   interrupts = ;
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 2/4] drivers: soc: Add support to register LLCC EDAC driver

Cache error reporting controller detects and reports single and
double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 18 --
 include/linux/soc/qcom/llcc-qcom.h |  2 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index a63640d..09c8bb0 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -224,7 +224,7 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
u32 attr0_val;
u32 max_cap_cacheline;
u32 sz;
-   int ret;
+   int ret = 0;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
 
@@ -282,6 +282,7 @@ int qcom_llcc_probe(struct platform_device *pdev,
struct resource *llcc_banks_res, *llcc_bcast_res;
void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
+   struct platform_device *llcc_edac;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
@@ -341,6 +342,19 @@ int qcom_llcc_probe(struct platform_device *pdev,
mutex_init(_data->lock);
platform_set_drvdata(pdev, drv_data);
 
-   return qcom_llcc_cfg_program(pdev);
+   ret = qcom_llcc_cfg_program(pdev);
+   if (ret)
+   return ret;
+
+   drv_data->ecc_irq = platform_get_irq(pdev, 0);
+   if (drv_data->ecc_irq >= 0) {
+   llcc_edac = platform_device_register_data(>dev,
+   "qcom_llcc_edac", -1, drv_data,
+   sizeof(*drv_data));
+   if (IS_ERR(llcc_edac))
+   dev_err(dev, "Failed to register llcc edac driver\n");
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(qcom_llcc_probe);
diff --git a/include/linux/soc/qcom/llcc-qcom.h 
b/include/linux/soc/qcom/llcc-qcom.h
index c681e79..2e4b34d 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -78,6 +78,7 @@ struct llcc_slice_config {
  * @num_banks: Number of llcc banks
  * @bitmap: Bit map to track the active slice ids
  * @offsets: Pointer to the bank offsets array
+ * @ecc_irq: interrupt for llcc cache error detection and reporting
  */
 struct llcc_drv_data {
struct regmap *regmap;
@@ -89,6 +90,7 @@ struct llcc_drv_data {
u32 num_banks;
unsigned long *bitmap;
u32 *offsets;
+   int ecc_irq;
 };
 
 #if IS_ENABLED(CONFIG_QCOM_LLCC)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 1/4] drivers: soc: Add broadcast base for Last Level Cache Controller (LLCC)

Currently, broadcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT). Add broadcast base in LLCC driver and use this for broadcast
writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 55 +++---
 include/linux/soc/qcom/llcc-qcom.h |  4 +--
 2 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index fcaad1a..a63640d 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -105,22 +105,24 @@ static int llcc_update_act_ctrl(u32 sid,
u32 slice_status;
int ret;
 
-   act_ctrl_reg = drv_data->bcast_off + LLCC_TRP_ACT_CTRLn(sid);
-   status_reg = drv_data->bcast_off + LLCC_TRP_STATUSn(sid);
+   act_ctrl_reg = LLCC_TRP_ACT_CTRLn(sid);
+   status_reg = LLCC_TRP_STATUSn(sid);
 
/* Set the ACTIVE trigger */
act_ctrl_reg_val |= ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
/* Clear the ACTIVE trigger */
act_ctrl_reg_val &= ~ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
-   ret = regmap_read_poll_timeout(drv_data->regmap, status_reg,
+   ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
  slice_status, !(slice_status & status),
  0, LLCC_STATUS_READ_DELAY);
return ret;
@@ -225,16 +227,13 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
int ret;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
-   u32 bcast_off = drv_data->bcast_off;
 
sz = drv_data->cfg_size;
llcc_table = drv_data->cfg;
 
for (i = 0; i < sz; i++) {
-   attr1_cfg = bcast_off +
-   LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
-   attr0_cfg = bcast_off +
-   LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
+   attr1_cfg = LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
+   attr0_cfg = LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
 
attr1_val = llcc_table[i].cache_mode;
attr1_val |= llcc_table[i].probe_target_ways <<
@@ -259,10 +258,12 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
attr0_val = llcc_table[i].res_ways & ATTR0_RES_WAYS_MASK;
attr0_val |= llcc_table[i].bonus_ways << ATTR0_BONUS_WAYS_SHIFT;
 
-   ret = regmap_write(drv_data->regmap, attr1_cfg, attr1_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr1_cfg,
+   attr1_val);
if (ret)
return ret;
-   ret = regmap_write(drv_data->regmap, attr0_cfg, attr0_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr0_cfg,
+   attr0_val);
if (ret)
return ret;
if (llcc_table[i].activate_on_init) {
@@ -278,24 +279,36 @@ int qcom_llcc_probe(struct platform_device *pdev,
 {
u32 num_banks;
struct device *dev = >dev;
-   struct resource *res;
-   void __iomem *base;
+   struct resource *llcc_banks_res, *llcc_bcast_res;
+   void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
return -ENOMEM;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   llcc_banks_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+   "llcc_base");
+   llcc_banks_base = devm_ioremap_resource(>dev, llcc_banks_res);
+   if (IS_ERR(llcc_banks_base))
+   return PTR_ERR(llcc_banks_base);
 
-   drv_data->regmap = devm_regmap_init_mmio(dev, base,
-   _regmap_config);
+   drv_data->regmap = devm_regmap_init_mmio(dev, llcc_banks_base,
+   _regmap_config);
if (IS_ERR(drv_data->regmap))
return

[PATCH v3 0/4] Add EDAC driver for QCOM SoCs

This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. Interrupts are triggered when the errors happen
in the cache, the driver handles those interrupts and dumps the syndrome
registers.

The driver functionality is implemented in:
qcom_edac.c : This platform driver registers to edac framework and
handles the single and double bit errors in cache by registering
interrupt handlers.

llcc-slice.c: It invokes the llcc edac driver and passes platform
data to it.

This patchset depends on the LLCC driver, which is part of 4.19 release.
Link: https://patchwork.kernel.org/patch/10422531/
Link:
http://lists-archives.com/linux-kernel/29157082-dt-bindings-documentation-for-qcom-llcc.html

Patch wise description given below:

Patch 1 adds the broadcast base regmap for broadcast writes in llcc.

Patch 2 adds the required changes to register edac driver from llcc driver.

Patch 3 adds the EDAC driver support for QCOM SoCS.

Patch 4 updates the dt bindings of llcc.

Changes since v2:
* Modified the edac driver and Kconfig
- removed unnecessary header files, typecasting and redundant comments.
- Changed the initialization of reg_data datastructure to static,
Also updated the llcc_edac_reg_data member names and datatypes.
- Removed "EDAC_QCOM_LLCC_PANIC_ON_UE" Kconfig variable

Changes since v1:
* Modified the edac driver
- Removed duplicate functions that are used to dump the syndrome registers,
replaced that with a common function and a reg_data datastructure.
- Removed structure containing function pointers.
- Addressed comments on error handling to clear the interrupt status.
* updated Kconfig

Changes since v0:
* Added EDAC_QCOM config and updated the driver
* Addressed comments related to indentation and other minor ones

Channagoud Kadabi (1):
drivers: edac: Add EDAC driver support for QCOM SoCs

Venkata Narendra Kumar Gutta (3):
drivers: soc: Add broadcast base for Last Level Cache Controller
(LLCC)
drivers: soc: Add support to register LLCC EDAC driver
dt-bindings: msm: Update documentation of qcom,llcc

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 0/4] Add EDAC driver for QCOM SoCs

The driver functionality is implemented in:
qcom_edac.c : This platform driver registers to edac framework and
handles the single and double bit errors in cache by registering
interrupt handlers.

llcc-slice.c: It invokes the llcc edac driver and passes platform
data to it.

Patch wise description given below:

Patch 1 adds the broadcast base regmap for broadcast writes in llcc.

Patch 2 adds the required changes to register edac driver from llcc driver.

Patch 3 adds the EDAC driver support for QCOM SoCS.

Patch 4 updates the dt bindings of llcc.

Changes since v0:
* Added EDAC_QCOM config and updated the driver
* Addressed comments related to indentation and other minor ones

Channagoud Kadabi (1):
drivers: edac: Add EDAC driver support for QCOM SoCs

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller

On Mon, Aug 27, 2018 at 04:55:20PM +0800, Hanjie Lin wrote:
> 
> 
> On 2018/8/24 16:22, Jerome Brunet wrote:
> > On Fri, 2018-08-24 at 15:36 +0800, Hanjie Lin wrote:
> >> From: Yue Wang 
> >>
> >> The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare
> >> PCI core. This patch adds documentation for the DT bindings in Meson PCIe
> >> controller.
> >>
> >> Signed-off-by: Yue Wang 
> >> Signed-off-by: Hanjie Lin 
> >> ---
> >>  .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 63 
> >> ++
> >>  1 file changed, 63 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt 
> >> b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> >> new file mode 100644
> >> index 000..8a831d1
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> >> @@ -0,0 +1,63 @@
> >> +Amlogic Meson AXG DWC PCIE SoC controller
> >> +
> >> +Amlogic Meson PCIe host controller is based on the Synopsys DesignWare 
> >> PCI core.
> >> +It shares common functions with the PCIe DesignWare core driver and
> >> +inherits common properties defined in
> >> +Documentation/devicetree/bindings/pci/designware-pci.txt.
> >> +
> >> +Additional properties are described here:
> >> +
> >> +Required properties:
> >> +- compatible:
> >> +  should contain "amlogic,axg-pcie" to identify the core.
> >> +- reg:
> >> +  Should contain the configuration address space.
> >> +- reg-names: Must be
> >> +  - "elbi"External local bus interface registers
> >> +  - "cfg" Meson specific registers
> >> +  - "config"  PCIe configuration space
> >> +- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert 
> >> signal.
> >> +- clocks: Must contain an entry for each entry in clock-names.
> >> +- clock-names: Must include the following entries:
> >> +  - "pclk"   PCIe GEN 100M PLL clock
> >> +  - "port"   PCIe_x(A or B) RC clock gate
> >> +  - "general"PCIe Phy clock
> >> +  - "mipi"   PCIe_x(A or B) 100M ref clock gate
> >> +- resets: phandle to the reset lines.
> >> +- reset-names: must contain "phy" and "peripheral"
> >> +   - "port" Port A or B reset
> >> +   - "apb" APB reset
> > 
> > The above description is not coherent (phy <=> port)
> > 
> 
> Yes, this should be port and apb here.
> We'll integrate phy driver into ctrl driver, and move phy reset to here also.

Why? That's the wrong thing to do if they are separate h/w blocks. You 
can do whatever you like in the drivers, but the DT should reflect the 
h/w.

Rob

Re: [PATCH v2 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller