Re: [PATCH] rtc: opal: Implement rtc_class_ops.alarm_irq_enable callback

[Alexandre Belloni]

On 31/05/2017 at 18:39:01 +0530, Vaibhav Jain wrote:
> Provide an implementation of the callback
> rtc_class_ops.alarm_irq_enable for rtc-opal driver. This callback is
> called when the wake alarm is disabled via the command:
> 
> 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
> 
> Without this the Timed-Power-On(TPO) config remains set even when its
> disabled by the above command and FSP will still force machine
> boot at previously configured alarm time.
> 
> The callback is implemented as function opal_tpo_alarm_irq_enable()
> which calls opal_set_tpo_time() with alarm.enabled == 0. A branch is
> added to opal_set_tpo_time() to handle this case by passing y_m_d ==
> h_m_s_ms == 0 to opal as arguments for opal_tpo_write() call.
> 
> Signed-off-by: Vaibhav Jain 
> ---
>  drivers/rtc/rtc-opal.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] rtc: opal: Implement rtc_class_ops.alarm_irq_enable callback

[Alexandre Belloni]

On 31/05/2017 at 18:39:01 +0530, Vaibhav Jain wrote:
> Provide an implementation of the callback
> rtc_class_ops.alarm_irq_enable for rtc-opal driver. This callback is
> called when the wake alarm is disabled via the command:
> 
> 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
> 
> Without this the Timed-Power-On(TPO) config remains set even when its
> disabled by the above command and FSP will still force machine
> boot at previously configured alarm time.
> 
> The callback is implemented as function opal_tpo_alarm_irq_enable()
> which calls opal_set_tpo_time() with alarm.enabled == 0. A branch is
> added to opal_set_tpo_time() to handle this case by passing y_m_d ==
> h_m_s_ms == 0 to opal as arguments for opal_tpo_write() call.
> 
> Signed-off-by: Vaibhav Jain 
> ---
>  drivers/rtc/rtc-opal.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Linux 4.9.34

[Greg KH]

I'm announcing the release of the 4.9.34 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/kernel-parameters.txt|7 +
 Makefile   |2 
 arch/arc/mm/mmap.c |2 
 arch/arm/mm/mmap.c |4 
 arch/frv/mm/elf-fdpic.c|2 
 arch/mips/boot/Makefile|   10 -
 arch/mips/kernel/branch.c  |4 
 arch/mips/mm/mmap.c|2 
 arch/parisc/kernel/sys_parisc.c|   15 +-
 arch/powerpc/mm/hugetlbpage-radix.c|2 
 arch/powerpc/mm/mmap.c |4 
 arch/powerpc/mm/slice.c|2 
 arch/s390/mm/mmap.c|4 
 arch/sh/mm/mmap.c  |4 
 arch/sparc/kernel/sys_sparc_64.c   |4 
 arch/sparc/mm/hugetlbpage.c|2 
 arch/tile/mm/hugetlbpage.c |2 
 arch/x86/kernel/sys_x86_64.c   |4 
 arch/x86/mm/hugetlbpage.c  |2 
 arch/x86/mm/numa_32.c  |1 
 arch/xtensa/kernel/syscall.c   |2 
 drivers/char/tpm/tpm_ibmvtpm.c |   17 +--
 drivers/cpufreq/cpufreq_conservative.c |4 
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |7 -
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |7 -
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |7 -
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |7 -
 drivers/gpu/drm/i915/i915_pvinfo.h |8 -
 drivers/gpu/drm/i915/i915_vgpu.c   |   10 -
 drivers/gpu/drm/mediatek/mtk_hdmi.c|2 
 drivers/gpu/drm/vc4/vc4_bo.c   |8 +
 drivers/iio/adc/ti_am335x_adc.c|2 
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |   39 ++-
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |3 
 drivers/iio/pressure/st_pressure_core.c|   10 -
 drivers/iio/proximity/as3935.c |6 -
 drivers/infiniband/hw/mlx5/main.c  |   14 +-
 drivers/media/usb/pvrusb2/pvrusb2-eeprom.c |   13 --
 drivers/media/v4l2-core/videobuf2-core.c   |2 
 drivers/mfd/omap-usb-tll.c |2 
 drivers/misc/c2port/c2port-duramar2150.c   |4 
 drivers/misc/mic/vop/vop_vringh.c  |1 
 drivers/net/can/usb/gs_usb.c   |2 
 drivers/net/wireless/ath/ath10k/pci.c  |3 
 drivers/staging/iio/light/tsl2x7x_core.c   |2 
 drivers/staging/rtl8188eu/core/rtw_ap.c|2 
 drivers/tty/serial/efm32-uart.c|   11 +
 drivers/tty/serial/sh-sci.c|4 
 drivers/usb/core/hcd.c |1 
 drivers/usb/core/hub.c |8 +
 drivers/usb/dwc3/dwc3-exynos.c |4 
 drivers/usb/gadget/composite.c |2 
 drivers/usb/gadget/legacy/inode.c  |9 +
 drivers/usb/gadget/udc/dummy_hcd.c |   19 +--
 drivers/usb/gadget/udc/net2280.c   |9 -
 drivers/usb/gadget/udc/renesas_usb3.c  |   43 +--
 drivers/usb/host/r8a66597-hcd.c|6 -
 drivers/usb/host/xhci-mem.c|7 -
 drivers/usb/host/xhci-pci.c|3 
 drivers/usb/musb/musb_dsps.c   |6 +
 drivers/usb/usbip/vhci_hcd.c   |   11 +
 fs/btrfs/hash.c|5 
 fs/configfs/symlink.c  |3 
 fs/f2fs/f2fs.h |5 
 fs/hugetlbfs/inode.c   |2 
 fs/proc/task_mmu.c |4 
 fs/read_write.c|2 
 include/linux/mm.h |   53 -
 include/uapi/linux/usb/ch11.h  |3 
 kernel/irq/manage.c|4 
 kernel/sched/core.c|2 
 kernel/time/alarmtimer.c   |   14 +-
 lib/libcrc32c.c|6 -
 mm/gup.c   |5 
 mm/memory-failure.c|5 
 mm/memory.c|   38 --
 mm/mmap.c  |  160 +
 mm/swap_cgroup.c   |3 
 net/ipv6/ila/ila_xlat.c|1 
 net/mac80211/cfg.c |2 
 net/mac80211/ibss.c|6 -
 net/mac80211/rx.c  |   10 +
 net/mac80211/sta_info.c|2 
 net/mac80211/wpa.c |9 -
 net/wireless/util.c|   10 +
 85 files changed, 447 insertions(+), 313 deletions(-)

Alan Stern 

Re: Linux 4.9.34

[Greg KH]

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index a6fadef92d6d..86a6746f6833 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3932,6 +3932,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
spia_pedr=
spia_peddr=
 
+   stack_guard_gap=[MM]
+   override the default stack gap protection. The value
+   is in page units and it defines how many pages prior
+   to (for stacks growing down) resp. after (for stacks
+   growing up) the main stack are reserved for no other
+   mapping. Default value is 256 pages.
+
stacktrace  [FTRACE]
Enabled the stack tracer on boot up.
 
diff --git a/Makefile b/Makefile
index 8470d81d5cc2..a40b373eba3a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 33
+SUBLEVEL = 34
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 2e06d56e987b..cf4ae6958240 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -64,7 +64,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 66353caa35b9..641334ebf46d 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -89,7 +89,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
@@ -140,7 +140,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
addr = PAGE_ALIGN(addr);
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
diff --git a/arch/frv/mm/elf-fdpic.c b/arch/frv/mm/elf-fdpic.c
index 836f14707a62..efa59f1f8022 100644
--- a/arch/frv/mm/elf-fdpic.c
+++ b/arch/frv/mm/elf-fdpic.c
@@ -74,7 +74,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, 
unsigned long addr, unsi
addr = PAGE_ALIGN(addr);
vma = find_vma(current->mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
goto success;
}
 
diff --git a/arch/mips/boot/Makefile b/arch/mips/boot/Makefile
index 2728a9a9c7c5..145b5ce8eb7e 100644
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -128,19 +128,19 @@ quiet_cmd_cpp_its_S = ITS $@
-DADDR_BITS=$(ADDR_BITS) \
-DADDR_CELLS=$(itb_addr_cells)
 
-$(obj)/vmlinux.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S $(VMLINUX) 
FORCE
$(call if_changed_dep,cpp_its_S,none,vmlinux.bin)
 
-$(obj)/vmlinux.gz.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.gz.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX) FORCE
$(call if_changed_dep,cpp_its_S,gzip,vmlinux.bin.gz)
 
-$(obj)/vmlinux.bz2.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.bz2.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX)  FORCE
$(call if_changed_dep,cpp_its_S,bzip2,vmlinux.bin.bz2)
 
-$(obj)/vmlinux.lzma.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.lzma.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX) FORCE
$(call if_changed_dep,cpp_its_S,lzma,vmlinux.bin.lzma)
 
-$(obj)/vmlinux.lzo.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.lzo.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX) FORCE
$(call if_changed_dep,cpp_its_S,lzo,vmlinux.bin.lzo)
 
 quiet_cmd_itb-image = ITB $@
diff --git a/arch/mips/kernel/branch.c b/arch/mips/kernel/branch.c
index 12c718181e5e..c86b66b57fc6 100644
--- a/arch/mips/kernel/branch.c
+++ b/arch/mips/kernel/branch.c
@@ -804,8 +804,10 @@ int __compute_return_epc_for_insn(struct pt_regs *regs,
break;
}
/* Compact branch: BNEZC || JIALC */
-   if (insn.i_format.rs)
+   if (!insn.i_format.rs) {
+  

Linux 4.9.34

[Greg KH]

I'm announcing the release of the 4.9.34 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/kernel-parameters.txt|7 +
 Makefile   |2 
 arch/arc/mm/mmap.c |2 
 arch/arm/mm/mmap.c |4 
 arch/frv/mm/elf-fdpic.c|2 
 arch/mips/boot/Makefile|   10 -
 arch/mips/kernel/branch.c  |4 
 arch/mips/mm/mmap.c|2 
 arch/parisc/kernel/sys_parisc.c|   15 +-
 arch/powerpc/mm/hugetlbpage-radix.c|2 
 arch/powerpc/mm/mmap.c |4 
 arch/powerpc/mm/slice.c|2 
 arch/s390/mm/mmap.c|4 
 arch/sh/mm/mmap.c  |4 
 arch/sparc/kernel/sys_sparc_64.c   |4 
 arch/sparc/mm/hugetlbpage.c|2 
 arch/tile/mm/hugetlbpage.c |2 
 arch/x86/kernel/sys_x86_64.c   |4 
 arch/x86/mm/hugetlbpage.c  |2 
 arch/x86/mm/numa_32.c  |1 
 arch/xtensa/kernel/syscall.c   |2 
 drivers/char/tpm/tpm_ibmvtpm.c |   17 +--
 drivers/cpufreq/cpufreq_conservative.c |4 
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |7 -
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |7 -
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |7 -
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |7 -
 drivers/gpu/drm/i915/i915_pvinfo.h |8 -
 drivers/gpu/drm/i915/i915_vgpu.c   |   10 -
 drivers/gpu/drm/mediatek/mtk_hdmi.c|2 
 drivers/gpu/drm/vc4/vc4_bo.c   |8 +
 drivers/iio/adc/ti_am335x_adc.c|2 
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |   39 ++-
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |3 
 drivers/iio/pressure/st_pressure_core.c|   10 -
 drivers/iio/proximity/as3935.c |6 -
 drivers/infiniband/hw/mlx5/main.c  |   14 +-
 drivers/media/usb/pvrusb2/pvrusb2-eeprom.c |   13 --
 drivers/media/v4l2-core/videobuf2-core.c   |2 
 drivers/mfd/omap-usb-tll.c |2 
 drivers/misc/c2port/c2port-duramar2150.c   |4 
 drivers/misc/mic/vop/vop_vringh.c  |1 
 drivers/net/can/usb/gs_usb.c   |2 
 drivers/net/wireless/ath/ath10k/pci.c  |3 
 drivers/staging/iio/light/tsl2x7x_core.c   |2 
 drivers/staging/rtl8188eu/core/rtw_ap.c|2 
 drivers/tty/serial/efm32-uart.c|   11 +
 drivers/tty/serial/sh-sci.c|4 
 drivers/usb/core/hcd.c |1 
 drivers/usb/core/hub.c |8 +
 drivers/usb/dwc3/dwc3-exynos.c |4 
 drivers/usb/gadget/composite.c |2 
 drivers/usb/gadget/legacy/inode.c  |9 +
 drivers/usb/gadget/udc/dummy_hcd.c |   19 +--
 drivers/usb/gadget/udc/net2280.c   |9 -
 drivers/usb/gadget/udc/renesas_usb3.c  |   43 +--
 drivers/usb/host/r8a66597-hcd.c|6 -
 drivers/usb/host/xhci-mem.c|7 -
 drivers/usb/host/xhci-pci.c|3 
 drivers/usb/musb/musb_dsps.c   |6 +
 drivers/usb/usbip/vhci_hcd.c   |   11 +
 fs/btrfs/hash.c|5 
 fs/configfs/symlink.c  |3 
 fs/f2fs/f2fs.h |5 
 fs/hugetlbfs/inode.c   |2 
 fs/proc/task_mmu.c |4 
 fs/read_write.c|2 
 include/linux/mm.h |   53 -
 include/uapi/linux/usb/ch11.h  |3 
 kernel/irq/manage.c|4 
 kernel/sched/core.c|2 
 kernel/time/alarmtimer.c   |   14 +-
 lib/libcrc32c.c|6 -
 mm/gup.c   |5 
 mm/memory-failure.c|5 
 mm/memory.c|   38 --
 mm/mmap.c  |  160 +
 mm/swap_cgroup.c   |3 
 net/ipv6/ila/ila_xlat.c|1 
 net/mac80211/cfg.c |2 
 net/mac80211/ibss.c|6 -
 net/mac80211/rx.c  |   10 +
 net/mac80211/sta_info.c|2 
 net/mac80211/wpa.c |9 -
 net/wireless/util.c|   10 +
 85 files changed, 447 insertions(+), 313 deletions(-)

Alan Stern 

Re: Linux 4.9.34

[Greg KH]

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index a6fadef92d6d..86a6746f6833 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3932,6 +3932,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
spia_pedr=
spia_peddr=
 
+   stack_guard_gap=[MM]
+   override the default stack gap protection. The value
+   is in page units and it defines how many pages prior
+   to (for stacks growing down) resp. after (for stacks
+   growing up) the main stack are reserved for no other
+   mapping. Default value is 256 pages.
+
stacktrace  [FTRACE]
Enabled the stack tracer on boot up.
 
diff --git a/Makefile b/Makefile
index 8470d81d5cc2..a40b373eba3a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 33
+SUBLEVEL = 34
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 2e06d56e987b..cf4ae6958240 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -64,7 +64,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 66353caa35b9..641334ebf46d 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -89,7 +89,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
@@ -140,7 +140,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
addr = PAGE_ALIGN(addr);
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
diff --git a/arch/frv/mm/elf-fdpic.c b/arch/frv/mm/elf-fdpic.c
index 836f14707a62..efa59f1f8022 100644
--- a/arch/frv/mm/elf-fdpic.c
+++ b/arch/frv/mm/elf-fdpic.c
@@ -74,7 +74,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, 
unsigned long addr, unsi
addr = PAGE_ALIGN(addr);
vma = find_vma(current->mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
goto success;
}
 
diff --git a/arch/mips/boot/Makefile b/arch/mips/boot/Makefile
index 2728a9a9c7c5..145b5ce8eb7e 100644
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -128,19 +128,19 @@ quiet_cmd_cpp_its_S = ITS $@
-DADDR_BITS=$(ADDR_BITS) \
-DADDR_CELLS=$(itb_addr_cells)
 
-$(obj)/vmlinux.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S $(VMLINUX) 
FORCE
$(call if_changed_dep,cpp_its_S,none,vmlinux.bin)
 
-$(obj)/vmlinux.gz.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.gz.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX) FORCE
$(call if_changed_dep,cpp_its_S,gzip,vmlinux.bin.gz)
 
-$(obj)/vmlinux.bz2.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.bz2.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX)  FORCE
$(call if_changed_dep,cpp_its_S,bzip2,vmlinux.bin.bz2)
 
-$(obj)/vmlinux.lzma.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.lzma.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX) FORCE
$(call if_changed_dep,cpp_its_S,lzma,vmlinux.bin.lzma)
 
-$(obj)/vmlinux.lzo.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S FORCE
+$(obj)/vmlinux.lzo.its: $(srctree)/arch/mips/$(PLATFORM)/vmlinux.its.S 
$(VMLINUX) FORCE
$(call if_changed_dep,cpp_its_S,lzo,vmlinux.bin.lzo)
 
 quiet_cmd_itb-image = ITB $@
diff --git a/arch/mips/kernel/branch.c b/arch/mips/kernel/branch.c
index 12c718181e5e..c86b66b57fc6 100644
--- a/arch/mips/kernel/branch.c
+++ b/arch/mips/kernel/branch.c
@@ -804,8 +804,10 @@ int __compute_return_epc_for_insn(struct pt_regs *regs,
break;
}
/* Compact branch: BNEZC || JIALC */
-   if (insn.i_format.rs)
+   if (!insn.i_format.rs) {
+  

[PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"

[Len Brown]

From: Len Brown 

cpufreq_quick_get() allows cpufreq drivers to over-ride cpu_khz
that is otherwise reported in x86 /proc/cpuinfo "cpu MHz".

There are four problems with this scheme,
any of them is sufficient justification to delete it.

1. Depending on which cpufreq driver is loaded, the behavior
   of this field is different.

2. Distros complain that they have to explain to users
   why and how this field changes.  Distros have requested a constant.

3. The two major providers of this information, acpi_cpufreq
   and intel_pstate, both "get it wrong" in different ways.

   acpi_cpufreq lies to the user by telling them that
   they are running at whatever frequency was last
   requested by software.

   intel_pstate lies to the user by telling them that
   they are running at the average frequency computed
   over an undefined measurement.  But an average computed
   over an undefined interval, is itself, undefined...

4. On modern processors, user space utilities, such as
   turbostat(1), are more accurate and more precise, while
   supporing concurrent measurement over arbitrary intervals.

Users who have been consulting /proc/cpuinfo to
track changing CPU frequency will be dissapointed that
it no longer wiggles -- perhaps being unaware of the
limitations of the information they have been consuming.

Yes, they can change their scripts to look in sysfs
cpufreq/scaling_cur_frequency.  Here they will find the same
data of dubious quality here removed from /proc/cpuinfo.
The value in sysfs will be addressed in a subsequent patch
to address issues 1-3, above.

Issue 4 will remain -- users that really care about
accurate frequency information should not be using either
proc or sysfs kernel interfaces.
They should be using using turbostat(8), or a similar
purpose-built analysis tool.

Signed-off-by: Len Brown 
Reviewed-by: Thomas Gleixner 
---
 arch/x86/kernel/cpu/proc.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 6df621a..218f798 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -2,7 +2,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * Get CPU information for use by the procfs.
@@ -76,14 +75,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (c->microcode)
seq_printf(m, "microcode\t: 0x%x\n", c->microcode);
 
-   if (cpu_has(c, X86_FEATURE_TSC)) {
-   unsigned int freq = cpufreq_quick_get(cpu);
-
-   if (!freq)
-   freq = cpu_khz;
+   if (cpu_has(c, X86_FEATURE_TSC))
seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
-  freq / 1000, (freq % 1000));
-   }
+  cpu_khz / 1000, (cpu_khz % 1000));
 
/* Cache size */
if (c->x86_cache_size >= 0)
-- 
2.7.4

[PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"

[Len Brown]

From: Len Brown 

cpufreq_quick_get() allows cpufreq drivers to over-ride cpu_khz
that is otherwise reported in x86 /proc/cpuinfo "cpu MHz".

There are four problems with this scheme,
any of them is sufficient justification to delete it.

1. Depending on which cpufreq driver is loaded, the behavior
   of this field is different.

2. Distros complain that they have to explain to users
   why and how this field changes.  Distros have requested a constant.

3. The two major providers of this information, acpi_cpufreq
   and intel_pstate, both "get it wrong" in different ways.

   acpi_cpufreq lies to the user by telling them that
   they are running at whatever frequency was last
   requested by software.

   intel_pstate lies to the user by telling them that
   they are running at the average frequency computed
   over an undefined measurement.  But an average computed
   over an undefined interval, is itself, undefined...

4. On modern processors, user space utilities, such as
   turbostat(1), are more accurate and more precise, while
   supporing concurrent measurement over arbitrary intervals.

Users who have been consulting /proc/cpuinfo to
track changing CPU frequency will be dissapointed that
it no longer wiggles -- perhaps being unaware of the
limitations of the information they have been consuming.

Yes, they can change their scripts to look in sysfs
cpufreq/scaling_cur_frequency.  Here they will find the same
data of dubious quality here removed from /proc/cpuinfo.
The value in sysfs will be addressed in a subsequent patch
to address issues 1-3, above.

Issue 4 will remain -- users that really care about
accurate frequency information should not be using either
proc or sysfs kernel interfaces.
They should be using using turbostat(8), or a similar
purpose-built analysis tool.

Signed-off-by: Len Brown 
Reviewed-by: Thomas Gleixner 
---
 arch/x86/kernel/cpu/proc.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 6df621a..218f798 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -2,7 +2,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * Get CPU information for use by the procfs.
@@ -76,14 +75,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (c->microcode)
seq_printf(m, "microcode\t: 0x%x\n", c->microcode);
 
-   if (cpu_has(c, X86_FEATURE_TSC)) {
-   unsigned int freq = cpufreq_quick_get(cpu);
-
-   if (!freq)
-   freq = cpu_khz;
+   if (cpu_has(c, X86_FEATURE_TSC))
seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
-  freq / 1000, (freq % 1000));
-   }
+  cpu_khz / 1000, (cpu_khz % 1000));
 
/* Cache size */
if (c->x86_cache_size >= 0)
-- 
2.7.4

[PATCH 3/4] intel_pstate: delete scheduler hook in HWP mode

[Len Brown]

From: Len Brown 

The cpufreq/scaling_cur_freq sysfs attribute is now provided by
shared x86 cpufreq code on modern x86 systems, including
all systems supported by the intel_pstate driver.

In HWP mode, maintaining that value was the sole purpose of
the scheduler hook, intel_pstate_update_util_hwp(),
so it can now be removed.

Signed-off-by: Len Brown 
---
 drivers/cpufreq/intel_pstate.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index b7de5bd..4ec5668 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1732,16 +1732,6 @@ static void intel_pstate_adjust_pstate(struct cpudata 
*cpu, int target_pstate)
fp_toint(cpu->iowait_boost * 100));
 }
 
-static void intel_pstate_update_util_hwp(struct update_util_data *data,
-u64 time, unsigned int flags)
-{
-   struct cpudata *cpu = container_of(data, struct cpudata, update_util);
-   u64 delta_ns = time - cpu->sample.time;
-
-   if ((s64)delta_ns >= INTEL_PSTATE_HWP_SAMPLING_INTERVAL)
-   intel_pstate_sample(cpu, time);
-}
-
 static void intel_pstate_update_util_pid(struct update_util_data *data,
 u64 time, unsigned int flags)
 {
@@ -1933,6 +1923,9 @@ static void intel_pstate_set_update_util_hook(unsigned 
int cpu_num)
 {
struct cpudata *cpu = all_cpu_data[cpu_num];
 
+   if (hwp_active)
+   return;
+
if (cpu->update_util_set)
return;
 
@@ -2557,7 +2550,6 @@ static int __init intel_pstate_init(void)
} else {
hwp_active++;
intel_pstate.attr = hwp_cpufreq_attrs;
-   pstate_funcs.update_util = intel_pstate_update_util_hwp;
goto hwp_cpu_matched;
}
} else {
-- 
2.7.4

Linux 4.11.7

[Greg KH]

I'm announcing the release of the 4.11.7 kernel.

All users of the 4.11 kernel series must upgrade.

The updated 4.11.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.11.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/admin-guide/kernel-parameters.txt |7 
 Documentation/devicetree/bindings/mfd/axp20x.txt|3 
 Makefile|2 
 arch/arc/mm/mmap.c  |2 
 arch/arm/boot/dts/am335x-sl50.dts   |8 
 arch/arm/mm/mmap.c  |4 
 arch/frv/mm/elf-fdpic.c |2 
 arch/mips/boot/Makefile |   10 
 arch/mips/kernel/branch.c   |4 
 arch/mips/mm/mmap.c |2 
 arch/parisc/kernel/sys_parisc.c |   15 
 arch/powerpc/mm/dump_linuxpagetables.c  |   18 
 arch/powerpc/mm/hugetlbpage-radix.c |2 
 arch/powerpc/mm/mmap.c  |4 
 arch/powerpc/mm/slice.c |2 
 arch/s390/mm/mmap.c |4 
 arch/sh/mm/mmap.c   |4 
 arch/sparc/kernel/sys_sparc_64.c|4 
 arch/sparc/mm/hugetlbpage.c |2 
 arch/tile/mm/hugetlbpage.c  |2 
 arch/x86/kernel/sys_x86_64.c|4 
 arch/x86/mm/hugetlbpage.c   |2 
 arch/x86/mm/numa_32.c   |1 
 arch/xtensa/kernel/syscall.c|2 
 drivers/cpufreq/cpufreq_conservative.c  |4 
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |7 
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |7 
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |7 
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |7 
 drivers/gpu/drm/i915/i915_gem_shrinker.c|5 
 drivers/gpu/drm/i915/i915_pvinfo.h  |8 
 drivers/gpu/drm/i915/i915_vgpu.c|   10 
 drivers/gpu/drm/i915/intel_display.c|   14 
 drivers/gpu/drm/mediatek/mtk_hdmi.c |2 
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c  |   42 +
 drivers/gpu/drm/vc4/vc4_bo.c|8 
 drivers/iio/adc/meson_saradc.c  |4 
 drivers/iio/adc/ti_am335x_adc.c |2 
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c  |   39 +
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h   |3 
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c|   41 +
 drivers/iio/proximity/as3935.c  |6 
 drivers/media/cec/cec-api.c |8 
 drivers/media/platform/coda/coda-common.c   |   21 
 drivers/media/usb/pvrusb2/pvrusb2-eeprom.c  |   13 
 drivers/media/v4l2-core/videobuf2-core.c|2 
 drivers/mfd/axp20x.c|   21 
 drivers/mfd/motorola-cpcap.c|6 
 drivers/mfd/omap-usb-tll.c  |2 
 drivers/misc/c2port/c2port-duramar2150.c|4 
 drivers/mtd/maps/Makefile   |   10 
 drivers/mtd/maps/physmap_of.c   |  389 
 drivers/mtd/maps/physmap_of_core.c  |  389 
 drivers/net/can/usb/gs_usb.c|2 
 drivers/phy/phy-rcar-gen3-usb2.c|   31 -
 drivers/staging/iio/cdc/ad7152.c|6 
 drivers/staging/iio/light/tsl2x7x_core.c|2 
 drivers/staging/media/platform/bcm2835/bcm2835-camera.c |   14 
 drivers/staging/rtl8188eu/core/rtw_ap.c |2 
 drivers/tty/serial/8250/8250_lpss.c |3 
 drivers/tty/serial/efm32-uart.c |   11 
 drivers/tty/serial/sh-sci.c |   29 -
 drivers/usb/core/hcd.c  |1 
 drivers/usb/core/hub.c  |8 
 drivers/usb/dwc3/gadget.c   |   12 
 drivers/usb/gadget/legacy/inode.c   |9 
 drivers/usb/gadget/udc/dummy_hcd.c  |   19 
 drivers/usb/gadget/udc/net2280.c|9 
 drivers/usb/gadget/udc/renesas_usb3.c   |   43 +
 drivers/usb/host/r8a66597-hcd.c 

[PATCH 3/4] intel_pstate: delete scheduler hook in HWP mode

[Len Brown]

From: Len Brown 

The cpufreq/scaling_cur_freq sysfs attribute is now provided by
shared x86 cpufreq code on modern x86 systems, including
all systems supported by the intel_pstate driver.

In HWP mode, maintaining that value was the sole purpose of
the scheduler hook, intel_pstate_update_util_hwp(),
so it can now be removed.

Signed-off-by: Len Brown 
---
 drivers/cpufreq/intel_pstate.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index b7de5bd..4ec5668 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1732,16 +1732,6 @@ static void intel_pstate_adjust_pstate(struct cpudata 
*cpu, int target_pstate)
fp_toint(cpu->iowait_boost * 100));
 }
 
-static void intel_pstate_update_util_hwp(struct update_util_data *data,
-u64 time, unsigned int flags)
-{
-   struct cpudata *cpu = container_of(data, struct cpudata, update_util);
-   u64 delta_ns = time - cpu->sample.time;
-
-   if ((s64)delta_ns >= INTEL_PSTATE_HWP_SAMPLING_INTERVAL)
-   intel_pstate_sample(cpu, time);
-}
-
 static void intel_pstate_update_util_pid(struct update_util_data *data,
 u64 time, unsigned int flags)
 {
@@ -1933,6 +1923,9 @@ static void intel_pstate_set_update_util_hook(unsigned 
int cpu_num)
 {
struct cpudata *cpu = all_cpu_data[cpu_num];
 
+   if (hwp_active)
+   return;
+
if (cpu->update_util_set)
return;
 
@@ -2557,7 +2550,6 @@ static int __init intel_pstate_init(void)
} else {
hwp_active++;
intel_pstate.attr = hwp_cpufreq_attrs;
-   pstate_funcs.update_util = intel_pstate_update_util_hwp;
goto hwp_cpu_matched;
}
} else {
-- 
2.7.4

Linux 4.11.7

[Greg KH]

I'm announcing the release of the 4.11.7 kernel.

All users of the 4.11 kernel series must upgrade.

The updated 4.11.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.11.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/admin-guide/kernel-parameters.txt |7 
 Documentation/devicetree/bindings/mfd/axp20x.txt|3 
 Makefile|2 
 arch/arc/mm/mmap.c  |2 
 arch/arm/boot/dts/am335x-sl50.dts   |8 
 arch/arm/mm/mmap.c  |4 
 arch/frv/mm/elf-fdpic.c |2 
 arch/mips/boot/Makefile |   10 
 arch/mips/kernel/branch.c   |4 
 arch/mips/mm/mmap.c |2 
 arch/parisc/kernel/sys_parisc.c |   15 
 arch/powerpc/mm/dump_linuxpagetables.c  |   18 
 arch/powerpc/mm/hugetlbpage-radix.c |2 
 arch/powerpc/mm/mmap.c  |4 
 arch/powerpc/mm/slice.c |2 
 arch/s390/mm/mmap.c |4 
 arch/sh/mm/mmap.c   |4 
 arch/sparc/kernel/sys_sparc_64.c|4 
 arch/sparc/mm/hugetlbpage.c |2 
 arch/tile/mm/hugetlbpage.c  |2 
 arch/x86/kernel/sys_x86_64.c|4 
 arch/x86/mm/hugetlbpage.c   |2 
 arch/x86/mm/numa_32.c   |1 
 arch/xtensa/kernel/syscall.c|2 
 drivers/cpufreq/cpufreq_conservative.c  |4 
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |7 
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |7 
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |7 
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |7 
 drivers/gpu/drm/i915/i915_gem_shrinker.c|5 
 drivers/gpu/drm/i915/i915_pvinfo.h  |8 
 drivers/gpu/drm/i915/i915_vgpu.c|   10 
 drivers/gpu/drm/i915/intel_display.c|   14 
 drivers/gpu/drm/mediatek/mtk_hdmi.c |2 
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c  |   42 +
 drivers/gpu/drm/vc4/vc4_bo.c|8 
 drivers/iio/adc/meson_saradc.c  |4 
 drivers/iio/adc/ti_am335x_adc.c |2 
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c  |   39 +
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h   |3 
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c|   41 +
 drivers/iio/proximity/as3935.c  |6 
 drivers/media/cec/cec-api.c |8 
 drivers/media/platform/coda/coda-common.c   |   21 
 drivers/media/usb/pvrusb2/pvrusb2-eeprom.c  |   13 
 drivers/media/v4l2-core/videobuf2-core.c|2 
 drivers/mfd/axp20x.c|   21 
 drivers/mfd/motorola-cpcap.c|6 
 drivers/mfd/omap-usb-tll.c  |2 
 drivers/misc/c2port/c2port-duramar2150.c|4 
 drivers/mtd/maps/Makefile   |   10 
 drivers/mtd/maps/physmap_of.c   |  389 
 drivers/mtd/maps/physmap_of_core.c  |  389 
 drivers/net/can/usb/gs_usb.c|2 
 drivers/phy/phy-rcar-gen3-usb2.c|   31 -
 drivers/staging/iio/cdc/ad7152.c|6 
 drivers/staging/iio/light/tsl2x7x_core.c|2 
 drivers/staging/media/platform/bcm2835/bcm2835-camera.c |   14 
 drivers/staging/rtl8188eu/core/rtw_ap.c |2 
 drivers/tty/serial/8250/8250_lpss.c |3 
 drivers/tty/serial/efm32-uart.c |   11 
 drivers/tty/serial/sh-sci.c |   29 -
 drivers/usb/core/hcd.c  |1 
 drivers/usb/core/hub.c  |8 
 drivers/usb/dwc3/gadget.c   |   12 
 drivers/usb/gadget/legacy/inode.c   |9 
 drivers/usb/gadget/udc/dummy_hcd.c  |   19 
 drivers/usb/gadget/udc/net2280.c|9 
 drivers/usb/gadget/udc/renesas_usb3.c   |   43 +
 drivers/usb/host/r8a66597-hcd.c 

[PATCH 4/4] intel_pstate: skip scheduler hook when in "performance" mode.

[Len Brown]

From: Len Brown 

When the governor is set to "performance", intel_pstate does not
need the scheduler hook for doing any calculations.  Under these
conditions, its only purpose is to continue to maintain
cpufreq/scaling_cur_freq.

The cpufreq/scaling_cur_freq sysfs attribute is now provided by
shared x86 cpufreq code on modern x86 systems, including
all systems supported by the intel_pstate driver.

So in "performance" governor mode, the scheduler hook can be skipped.
This applies to both in Software and Hardware P-state control modes.

Suggested-by: Srinivas Pandruvada 
Signed-off-by: Len Brown 
---
 drivers/cpufreq/intel_pstate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 4ec5668..4538182 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2031,10 +2031,10 @@ static int intel_pstate_set_policy(struct 
cpufreq_policy *policy)
 */
intel_pstate_clear_update_util_hook(policy->cpu);
intel_pstate_max_within_limits(cpu);
+   } else {
+   intel_pstate_set_update_util_hook(policy->cpu);
}
 
-   intel_pstate_set_update_util_hook(policy->cpu);
-
if (hwp_active)
intel_pstate_hwp_set(policy->cpu);
 
-- 
2.7.4

Re: Linux 4.11.7

[Greg KH]

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index facc20a3f962..952319b73e61 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3779,6 +3779,13 @@
spia_pedr=
spia_peddr=
 
+   stack_guard_gap=[MM]
+   override the default stack gap protection. The value
+   is in page units and it defines how many pages prior
+   to (for stacks growing down) resp. after (for stacks
+   growing up) the main stack are reserved for no other
+   mapping. Default value is 256 pages.
+
stacktrace  [FTRACE]
Enabled the stack tracer on boot up.
 
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 8f3ad9ab4637..b41d2601c6ba 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -28,6 +28,9 @@ Optional properties:
  regulator to drive the OTG VBus, rather then as an input pin
  which signals whether the board is driving OTG VBus or not.
 
+- x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is
+   wired for master mode. The default is slave mode.
+
 - -supply: a phandle to the regulator supply node. May be omitted if
  inputs are unregulated, such as using the IPSOUT output
  from the PMIC.
diff --git a/Makefile b/Makefile
index e46e99cbe5d1..1b0fe238d633 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 11
-SUBLEVEL = 6
+SUBLEVEL = 7
 EXTRAVERSION =
 NAME = Fearless Coyote
 
diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 3e25e8d6486b..2e13683dfb24 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -65,7 +65,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
diff --git a/arch/arm/boot/dts/am335x-sl50.dts 
b/arch/arm/boot/dts/am335x-sl50.dts
index c5d2589c55fc..fc864a855991 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -220,7 +220,7 @@
 
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7)  
/* spi0_cs1.gpio0_6 */
+   AM33XX_IOPAD(0x96c, PIN_INPUT | MUX_MODE7)  
/* uart0_rtsn.gpio1_9 */
>;
};
 
@@ -280,10 +280,6 @@
AM33XX_IOPAD(0x834, PIN_INPUT_PULLUP | MUX_MODE7)   
/* nKbdReset - gpmc_ad13.gpio1_13 */
AM33XX_IOPAD(0x838, PIN_INPUT_PULLUP | MUX_MODE7)   
/* nDispReset - gpmc_ad14.gpio1_14 */
AM33XX_IOPAD(0x844, PIN_INPUT_PULLUP | MUX_MODE7)   
/* USB1_enPower - gpmc_a1.gpio1_17 */
-   /* AVR Programming - SPI Bus (bit bang) - Screen and 
Keyboard */
-   AM33XX_IOPAD(0x954, PIN_INPUT_PULLUP | MUX_MODE7)   
/* Kbd/Disp/BattMOSI spi0_d0.gpio0_3 */
-   AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | MUX_MODE7)   
/* Kbd/Disp/BattMISO spi0_d1.gpio0_4 */
-   AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP | MUX_MODE7)   
/* Kbd/Disp/BattSCLK spi0_clk.gpio0_2 */
/* PDI Bus - Battery system */
AM33XX_IOPAD(0x840, PIN_INPUT_PULLUP | MUX_MODE7)   
/* nBattReset  gpmc_a0.gpio1_16 */
AM33XX_IOPAD(0x83c, PIN_INPUT_PULLUP | MUX_MODE7)   
/* BattPDIData gpmc_ad15.gpio1_15 */
@@ -384,7 +380,7 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
bus-width = <4>;
-   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
+   cd-gpios = < 9 GPIO_ACTIVE_LOW>;
vmmc-supply = <_fixed>;
 };
 
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 2239fde10b80..f0701d8d24df 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -90,7 +90,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
@@ -141,7 +141,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
addr = PAGE_ALIGN(addr);
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= 

[PATCH 0/4 v2] x86,cpufreq: unify APERF/MPERF computation

[Len Brown]

Hi Rafael, Thomas,

Please see the updated 2nd patch in this series -- in response to tglx review.
Patch 1,3,4 are unchanged.

thanks,
-Len

This patch series has 3 goals:

1. Make "cpu MHz" in /proc/cpuinfo supportable.

2. Make /sys/.../cpufreq/scaling_cur_freq meaningful
   and consistent on modern x86 systems.

3. Use 1. and 2. to remove scheduler and cpufreq overhead

There are 3 main changes since this series was proposed
about a year ago:

This update responds to distro feedback to make /proc/cpuinfo
"cpu MHz" constant.  Originally, we had proposed making it return
the same dynamic value as cpufreq sysfs.

Some community members suggested that sysfs MHz values should
be meaninful, even down to 10ms intervals.  So this has been
changed, versus the original proposal to not re-compute
at intervals shorter than 100ms.

(For those who really care about observing frequency, the
 recommendation remains to use turbostat(8) or equivalent utility,
 which can reliably measure concurrent intervals of arbitrary length)

The intel_pstate sampling mechanism has changed.
Originally this series removed an intel_pstate timer in HWP mode.
Now it removes the analogous scheduler call-back.

Most recently, in response to posting this patch on the list
about 10-days ago, the patch to remove frequency calculation
from inside intel_pstate was dropped, in order to maintain compatibility
with tracing scripts.  Also, the order of the last two patches
has been exchanged.

Please let me know if you see any issues with this series.

thanks!
Len Brown, Intel Open Source Technology Center

The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f:

  Linux 4.12-rc4 (2017-06-04 16:47:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git x86

for you to fetch changes up to 68516d288d3968fe22d6c8984a7bcbdcdbed351d:

  intel_pstate: skip scheduler hook when in "performance" mode. (2017-06-23 
22:01:46 -0700)


Len Brown (4):
  x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"
  x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF
  intel_pstate: delete scheduler hook in HWP mode
  intel_pstate: skip scheduler hook when in "performance" mode.

 arch/x86/kernel/cpu/Makefile |  1 +
 arch/x86/kernel/cpu/aperfmperf.c | 79 
 arch/x86/kernel/cpu/proc.c   | 10 +
 drivers/cpufreq/cpufreq.c| 12 +-
 drivers/cpufreq/intel_pstate.c   | 18 +++--
 include/linux/cpufreq.h  |  2 +
 6 files changed, 100 insertions(+), 22 deletions(-)
 create mode 100644 arch/x86/kernel/cpu/aperfmperf.c

[PATCH 4/4] intel_pstate: skip scheduler hook when in "performance" mode.

[Len Brown]

From: Len Brown 

When the governor is set to "performance", intel_pstate does not
need the scheduler hook for doing any calculations.  Under these
conditions, its only purpose is to continue to maintain
cpufreq/scaling_cur_freq.

The cpufreq/scaling_cur_freq sysfs attribute is now provided by
shared x86 cpufreq code on modern x86 systems, including
all systems supported by the intel_pstate driver.

So in "performance" governor mode, the scheduler hook can be skipped.
This applies to both in Software and Hardware P-state control modes.

Suggested-by: Srinivas Pandruvada 
Signed-off-by: Len Brown 
---
 drivers/cpufreq/intel_pstate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 4ec5668..4538182 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2031,10 +2031,10 @@ static int intel_pstate_set_policy(struct 
cpufreq_policy *policy)
 */
intel_pstate_clear_update_util_hook(policy->cpu);
intel_pstate_max_within_limits(cpu);
+   } else {
+   intel_pstate_set_update_util_hook(policy->cpu);
}
 
-   intel_pstate_set_update_util_hook(policy->cpu);
-
if (hwp_active)
intel_pstate_hwp_set(policy->cpu);
 
-- 
2.7.4

Re: Linux 4.11.7

[Greg KH]

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index facc20a3f962..952319b73e61 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3779,6 +3779,13 @@
spia_pedr=
spia_peddr=
 
+   stack_guard_gap=[MM]
+   override the default stack gap protection. The value
+   is in page units and it defines how many pages prior
+   to (for stacks growing down) resp. after (for stacks
+   growing up) the main stack are reserved for no other
+   mapping. Default value is 256 pages.
+
stacktrace  [FTRACE]
Enabled the stack tracer on boot up.
 
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 8f3ad9ab4637..b41d2601c6ba 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -28,6 +28,9 @@ Optional properties:
  regulator to drive the OTG VBus, rather then as an input pin
  which signals whether the board is driving OTG VBus or not.
 
+- x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is
+   wired for master mode. The default is slave mode.
+
 - -supply: a phandle to the regulator supply node. May be omitted if
  inputs are unregulated, such as using the IPSOUT output
  from the PMIC.
diff --git a/Makefile b/Makefile
index e46e99cbe5d1..1b0fe238d633 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 11
-SUBLEVEL = 6
+SUBLEVEL = 7
 EXTRAVERSION =
 NAME = Fearless Coyote
 
diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 3e25e8d6486b..2e13683dfb24 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -65,7 +65,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
diff --git a/arch/arm/boot/dts/am335x-sl50.dts 
b/arch/arm/boot/dts/am335x-sl50.dts
index c5d2589c55fc..fc864a855991 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -220,7 +220,7 @@
 
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
-   AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7)  
/* spi0_cs1.gpio0_6 */
+   AM33XX_IOPAD(0x96c, PIN_INPUT | MUX_MODE7)  
/* uart0_rtsn.gpio1_9 */
>;
};
 
@@ -280,10 +280,6 @@
AM33XX_IOPAD(0x834, PIN_INPUT_PULLUP | MUX_MODE7)   
/* nKbdReset - gpmc_ad13.gpio1_13 */
AM33XX_IOPAD(0x838, PIN_INPUT_PULLUP | MUX_MODE7)   
/* nDispReset - gpmc_ad14.gpio1_14 */
AM33XX_IOPAD(0x844, PIN_INPUT_PULLUP | MUX_MODE7)   
/* USB1_enPower - gpmc_a1.gpio1_17 */
-   /* AVR Programming - SPI Bus (bit bang) - Screen and 
Keyboard */
-   AM33XX_IOPAD(0x954, PIN_INPUT_PULLUP | MUX_MODE7)   
/* Kbd/Disp/BattMOSI spi0_d0.gpio0_3 */
-   AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP | MUX_MODE7)   
/* Kbd/Disp/BattMISO spi0_d1.gpio0_4 */
-   AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP | MUX_MODE7)   
/* Kbd/Disp/BattSCLK spi0_clk.gpio0_2 */
/* PDI Bus - Battery system */
AM33XX_IOPAD(0x840, PIN_INPUT_PULLUP | MUX_MODE7)   
/* nBattReset  gpmc_a0.gpio1_16 */
AM33XX_IOPAD(0x83c, PIN_INPUT_PULLUP | MUX_MODE7)   
/* BattPDIData gpmc_ad15.gpio1_15 */
@@ -384,7 +380,7 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
bus-width = <4>;
-   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
+   cd-gpios = < 9 GPIO_ACTIVE_LOW>;
vmmc-supply = <_fixed>;
 };
 
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 2239fde10b80..f0701d8d24df 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -90,7 +90,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
@@ -141,7 +141,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
addr = PAGE_ALIGN(addr);
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= 

[PATCH 0/4 v2] x86,cpufreq: unify APERF/MPERF computation

[Len Brown]

Hi Rafael, Thomas,

Please see the updated 2nd patch in this series -- in response to tglx review.
Patch 1,3,4 are unchanged.

thanks,
-Len

This patch series has 3 goals:

1. Make "cpu MHz" in /proc/cpuinfo supportable.

2. Make /sys/.../cpufreq/scaling_cur_freq meaningful
   and consistent on modern x86 systems.

3. Use 1. and 2. to remove scheduler and cpufreq overhead

There are 3 main changes since this series was proposed
about a year ago:

This update responds to distro feedback to make /proc/cpuinfo
"cpu MHz" constant.  Originally, we had proposed making it return
the same dynamic value as cpufreq sysfs.

Some community members suggested that sysfs MHz values should
be meaninful, even down to 10ms intervals.  So this has been
changed, versus the original proposal to not re-compute
at intervals shorter than 100ms.

(For those who really care about observing frequency, the
 recommendation remains to use turbostat(8) or equivalent utility,
 which can reliably measure concurrent intervals of arbitrary length)

The intel_pstate sampling mechanism has changed.
Originally this series removed an intel_pstate timer in HWP mode.
Now it removes the analogous scheduler call-back.

Most recently, in response to posting this patch on the list
about 10-days ago, the patch to remove frequency calculation
from inside intel_pstate was dropped, in order to maintain compatibility
with tracing scripts.  Also, the order of the last two patches
has been exchanged.

Please let me know if you see any issues with this series.

thanks!
Len Brown, Intel Open Source Technology Center

The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f:

  Linux 4.12-rc4 (2017-06-04 16:47:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git x86

for you to fetch changes up to 68516d288d3968fe22d6c8984a7bcbdcdbed351d:

  intel_pstate: skip scheduler hook when in "performance" mode. (2017-06-23 
22:01:46 -0700)


Len Brown (4):
  x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"
  x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF
  intel_pstate: delete scheduler hook in HWP mode
  intel_pstate: skip scheduler hook when in "performance" mode.

 arch/x86/kernel/cpu/Makefile |  1 +
 arch/x86/kernel/cpu/aperfmperf.c | 79 
 arch/x86/kernel/cpu/proc.c   | 10 +
 drivers/cpufreq/cpufreq.c| 12 +-
 drivers/cpufreq/intel_pstate.c   | 18 +++--
 include/linux/cpufreq.h  |  2 +
 6 files changed, 100 insertions(+), 22 deletions(-)
 create mode 100644 arch/x86/kernel/cpu/aperfmperf.c

[PATCH 2/4 v2] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

[Len Brown]

From: Len Brown 

The goal of this change is to give users a uniform and meaningful
result when they read /sys/...cpufreq/scaling_cur_freq
on modern x86 hardware, as compared to what they get today.

Modern x86 processors include the hardware needed
to accurately calculate frequency over an interval --
APERF, MPERF, and the TSC.

Here we provide an x86 routine to make this calculation
on supported hardware, and use it in preference to any
driver driver-specific cpufreq_driver.get() routine.

MHz is computed like so:

MHz = base_MHz * delta_APERF / delta_MPERF

MHz is the average frequency of the busy processor
over a measurement interval.  The interval is
defined to be the time between successive invocations
of aperfmperf_khz_on_cpu(), which are expected to to
happen on-demand when users read sysfs attribute
cpufreq/scaling_cur_freq.

As with previous methods of calculating MHz,
idle time is excluded.

base_MHz above is from TSC calibration global "cpu_khz".

This x86 native method to calculate MHz returns a meaningful result
no matter if P-states are controlled by hardware or firmware
and/or if the Linux cpufreq sub-system is or is-not installed.

When this routine is invoked more frequently, the measurement
interval becomes shorter.  However, the code limits re-computation
to 10ms intervals so that average frequency remains meaningful.

Discerning users are encouraged to take advantage of
the turbostat(8) utility, which can gracefully handle
concurrent measurement intervals of arbitrary length.

Signed-off-by: Len Brown 
---
 arch/x86/kernel/cpu/Makefile |  1 +
 arch/x86/kernel/cpu/aperfmperf.c | 79 
 drivers/cpufreq/cpufreq.c| 12 +-
 include/linux/cpufreq.h  |  2 +
 4 files changed, 93 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/cpu/aperfmperf.c

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 521..cdf8249 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -21,6 +21,7 @@ obj-y += common.o
 obj-y  += rdrand.o
 obj-y  += match.o
 obj-y  += bugs.o
+obj-$(CONFIG_CPU_FREQ) += aperfmperf.o
 
 obj-$(CONFIG_PROC_FS)  += proc.o
 obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
new file mode 100644
index 000..d869c86
--- /dev/null
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -0,0 +1,79 @@
+/*
+ * x86 APERF/MPERF KHz calculation for
+ * /sys/.../cpufreq/scaling_cur_freq
+ *
+ * Copyright (C) 2017 Intel Corp.
+ * Author: Len Brown 
+ *
+ * This file is licensed under GPLv2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct aperfmperf_sample {
+   unsigned intkhz;
+   unsigned long   jiffies;
+   u64 aperf;
+   u64 mperf;
+};
+
+static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
+
+/*
+ * aperfmperf_snapshot_khz()
+ * On the current CPU, snapshot APERF, MPERF, and jiffies
+ * unless we already did it within 10ms
+ * calculate kHz, save snapshot
+ */
+static void aperfmperf_snapshot_khz(void *dummy)
+{
+   u64 aperf, aperf_delta;
+   u64 mperf, mperf_delta;
+   struct aperfmperf_sample *s = this_cpu_ptr();
+
+   /* Don't bother re-computing within 10 ms */
+   if (time_before(jiffies, s->jiffies + HZ/100))
+   return;
+
+   rdmsrl(MSR_IA32_APERF, aperf);
+   rdmsrl(MSR_IA32_MPERF, mperf);
+
+   aperf_delta = aperf - s->aperf;
+   mperf_delta = mperf - s->mperf;
+
+   /*
+* There is no architectural guarantee that MPERF
+* increments faster than we can read it.
+*/
+   if (mperf_delta == 0)
+   return;
+
+   /*
+* if (cpu_khz * aperf_delta) fits into ULLONG_MAX, then
+*  khz = (cpu_khz * aperf_delta) / mperf_delta
+*/
+   if (div64_u64(ULLONG_MAX, cpu_khz) > aperf_delta)
+   s->khz = div64_u64((cpu_khz * aperf_delta), mperf_delta);
+   else/* khz = aperf_delta / (mperf_delta / cpu_khz) */
+   s->khz = div64_u64(aperf_delta,
+   div64_u64(mperf_delta, cpu_khz));
+   s->jiffies = jiffies;
+   s->aperf = aperf;
+   s->mperf = mperf;
+}
+
+unsigned int arch_freq_get_on_cpu(int cpu)
+{
+   if (!cpu_khz)
+   return 0;
+
+   if (!static_cpu_has(X86_FEATURE_APERFMPERF))
+   return 0;
+
+   smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, 1);
+
+   return per_cpu(samples.khz, cpu);
+}
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 26b643d..6e7424d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -632,11 +632,21 @@ show_one(cpuinfo_transition_latency, 
cpuinfo.transition_latency);
 show_one(scaling_min_freq, min);
 

[PATCH 2/4 v2] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

[Len Brown]

From: Len Brown 

The goal of this change is to give users a uniform and meaningful
result when they read /sys/...cpufreq/scaling_cur_freq
on modern x86 hardware, as compared to what they get today.

Modern x86 processors include the hardware needed
to accurately calculate frequency over an interval --
APERF, MPERF, and the TSC.

Here we provide an x86 routine to make this calculation
on supported hardware, and use it in preference to any
driver driver-specific cpufreq_driver.get() routine.

MHz is computed like so:

MHz = base_MHz * delta_APERF / delta_MPERF

MHz is the average frequency of the busy processor
over a measurement interval.  The interval is
defined to be the time between successive invocations
of aperfmperf_khz_on_cpu(), which are expected to to
happen on-demand when users read sysfs attribute
cpufreq/scaling_cur_freq.

As with previous methods of calculating MHz,
idle time is excluded.

base_MHz above is from TSC calibration global "cpu_khz".

This x86 native method to calculate MHz returns a meaningful result
no matter if P-states are controlled by hardware or firmware
and/or if the Linux cpufreq sub-system is or is-not installed.

When this routine is invoked more frequently, the measurement
interval becomes shorter.  However, the code limits re-computation
to 10ms intervals so that average frequency remains meaningful.

Discerning users are encouraged to take advantage of
the turbostat(8) utility, which can gracefully handle
concurrent measurement intervals of arbitrary length.

Signed-off-by: Len Brown 
---
 arch/x86/kernel/cpu/Makefile |  1 +
 arch/x86/kernel/cpu/aperfmperf.c | 79 
 drivers/cpufreq/cpufreq.c| 12 +-
 include/linux/cpufreq.h  |  2 +
 4 files changed, 93 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/cpu/aperfmperf.c

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 521..cdf8249 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -21,6 +21,7 @@ obj-y += common.o
 obj-y  += rdrand.o
 obj-y  += match.o
 obj-y  += bugs.o
+obj-$(CONFIG_CPU_FREQ) += aperfmperf.o
 
 obj-$(CONFIG_PROC_FS)  += proc.o
 obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
new file mode 100644
index 000..d869c86
--- /dev/null
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -0,0 +1,79 @@
+/*
+ * x86 APERF/MPERF KHz calculation for
+ * /sys/.../cpufreq/scaling_cur_freq
+ *
+ * Copyright (C) 2017 Intel Corp.
+ * Author: Len Brown 
+ *
+ * This file is licensed under GPLv2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct aperfmperf_sample {
+   unsigned intkhz;
+   unsigned long   jiffies;
+   u64 aperf;
+   u64 mperf;
+};
+
+static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
+
+/*
+ * aperfmperf_snapshot_khz()
+ * On the current CPU, snapshot APERF, MPERF, and jiffies
+ * unless we already did it within 10ms
+ * calculate kHz, save snapshot
+ */
+static void aperfmperf_snapshot_khz(void *dummy)
+{
+   u64 aperf, aperf_delta;
+   u64 mperf, mperf_delta;
+   struct aperfmperf_sample *s = this_cpu_ptr();
+
+   /* Don't bother re-computing within 10 ms */
+   if (time_before(jiffies, s->jiffies + HZ/100))
+   return;
+
+   rdmsrl(MSR_IA32_APERF, aperf);
+   rdmsrl(MSR_IA32_MPERF, mperf);
+
+   aperf_delta = aperf - s->aperf;
+   mperf_delta = mperf - s->mperf;
+
+   /*
+* There is no architectural guarantee that MPERF
+* increments faster than we can read it.
+*/
+   if (mperf_delta == 0)
+   return;
+
+   /*
+* if (cpu_khz * aperf_delta) fits into ULLONG_MAX, then
+*  khz = (cpu_khz * aperf_delta) / mperf_delta
+*/
+   if (div64_u64(ULLONG_MAX, cpu_khz) > aperf_delta)
+   s->khz = div64_u64((cpu_khz * aperf_delta), mperf_delta);
+   else/* khz = aperf_delta / (mperf_delta / cpu_khz) */
+   s->khz = div64_u64(aperf_delta,
+   div64_u64(mperf_delta, cpu_khz));
+   s->jiffies = jiffies;
+   s->aperf = aperf;
+   s->mperf = mperf;
+}
+
+unsigned int arch_freq_get_on_cpu(int cpu)
+{
+   if (!cpu_khz)
+   return 0;
+
+   if (!static_cpu_has(X86_FEATURE_APERFMPERF))
+   return 0;
+
+   smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, 1);
+
+   return per_cpu(samples.khz, cpu);
+}
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 26b643d..6e7424d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -632,11 +632,21 @@ show_one(cpuinfo_transition_latency, 
cpuinfo.transition_latency);
 show_one(scaling_min_freq, min);
 show_one(scaling_max_freq, max);
 
+__weak unsigned int 

Re: [PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

[Len Brown]

On Tue, Jun 20, 2017 at 6:15 AM, Thomas Gleixner  wrote:
> On Fri, 16 Jun 2017, Len Brown wrote:
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct aperfmperf_sample {
>> + unsigned int khz;
>> + unsigned long jiffies;
>> + u64 aperf;
>> + u64 mperf;
>
> Nit. Please write these in tabular fashion:
> unsignedint khz;
> unsigned long   jiffies;
> u64 aperf;
> u64 mperf;

sure, no problem -- I agreed that looks better.

But it seems there is some inconsistency about this style nit --
even in this directory.  If there is consensus going forward,
would it make sense for coding-style.rst and checkpatch.pl
to squawk about this, so you don't have to?


>> +};
>> +
>> +static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
>> +
>> +/*
>> + * aperfmperf_snapshot_khz()
>> + * On the current CPU, snapshot APERF, MPERF, and jiffies
>> + * unless we already did it within 10ms
>> + * calculate kHz, save snapshot
>> + */
>> +static void aperfmperf_snapshot_khz(void *dummy)
>> +{
>> + u64 aperf, aperf_delta;
>> + u64 mperf, mperf_delta;
>> + struct aperfmperf_sample *s = _cpu_var(samples);
>
> This is invoked via a smp function call, so you want
>
>  this_cpu_ptr(samples)
>
> here.

done. thanks!

>> + /* Don't bother re-computing within 10 ms */
>> + if (time_before(jiffies, s->jiffies + HZ/100))
>> + goto out;
>
> That way you can spare the gotos and simply return

happy to remove the gotos, thanks!

>> index a5ce0bbe..cfc6220 100644
>> --- a/include/linux/cpufreq.h
>> +++ b/include/linux/cpufreq.h
>> @@ -883,6 +883,19 @@ static inline bool policy_has_boost_freq(struct 
>> cpufreq_policy *policy)
>>  }
>>  #endif
>>
>> +#ifdef CONFIG_X86
>> +extern unsigned int aperfmperf_khz_on_cpu(unsigned int cpu);
>> +static inline unsigned int arch_freq_get_on_cpu(int cpu)

> ... having cpu as int and unsigned int is not really consistent.

True.  the SMP code uses int cpu, while cpufreq_policy.cpu is an unsigned int.
I'll use "int cpu".

> Please don't add arch specific crap in general headers.
>
> The simple way to avoid that is to have a weak function and have an arch
> override for it. If that does not work because the cpufreq stuff must be
> built as a module, then you still can avoid CONFIG_X86 and have something
> like CONFIG_ARCH_HAS_FOO.

Thanks -- this is not modular code, and so yes, __weak works -- hadn't
had occasion to use it before...
Attached is the incremental diff responding to your comments, in case
that is convenient.
I'll re-send this series with this patch updated in a sec.

thanks,
Len Brown, Intel Open Source Technology Center
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
index 5ccf63a..d869c86 100644
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -14,10 +14,10 @@
 #include 
 
 struct aperfmperf_sample {
-   unsigned int khz;
-   unsigned long jiffies;
-   u64 aperf;
-   u64 mperf;
+   unsigned intkhz;
+   unsigned long   jiffies;
+   u64 aperf;
+   u64 mperf;
 };
 
 static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
@@ -32,11 +32,11 @@ static void aperfmperf_snapshot_khz(void *dummy)
 {
u64 aperf, aperf_delta;
u64 mperf, mperf_delta;
-   struct aperfmperf_sample *s = _cpu_var(samples);
+   struct aperfmperf_sample *s = this_cpu_ptr();
 
/* Don't bother re-computing within 10 ms */
if (time_before(jiffies, s->jiffies + HZ/100))
-   goto out;
+   return;
 
rdmsrl(MSR_IA32_APERF, aperf);
rdmsrl(MSR_IA32_MPERF, mperf);
@@ -49,7 +49,7 @@ static void aperfmperf_snapshot_khz(void *dummy)
 * increments faster than we can read it.
 */
if (mperf_delta == 0)
-   goto out;
+   return;
 
/*
 * if (cpu_khz * aperf_delta) fits into ULLONG_MAX, then
@@ -63,12 +63,9 @@ static void aperfmperf_snapshot_khz(void *dummy)
s->jiffies = jiffies;
s->aperf = aperf;
s->mperf = mperf;
-
-out:
-   put_cpu_var(samples);
 }
 
-unsigned int aperfmperf_khz_on_cpu(unsigned int cpu)
+unsigned int arch_freq_get_on_cpu(int cpu)
 {
if (!cpu_khz)
return 0;
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a667fac..6e7424d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -632,6 +632,11 @@ show_one(cpuinfo_transition_latency, 
cpuinfo.transition_latency);
 show_one(scaling_min_freq, min);
 show_one(scaling_max_freq, max);
 
+__weak unsigned int arch_freq_get_on_cpu(int cpu)
+{
+   return 0;
+}
+
 static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf)
 {
ssize_t ret;
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index cfc6220..905117b 100644
--- a/include/linux/cpufreq.h
+++ 

Re: [PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF

[Len Brown]

On Tue, Jun 20, 2017 at 6:15 AM, Thomas Gleixner  wrote:
> On Fri, 16 Jun 2017, Len Brown wrote:
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct aperfmperf_sample {
>> + unsigned int khz;
>> + unsigned long jiffies;
>> + u64 aperf;
>> + u64 mperf;
>
> Nit. Please write these in tabular fashion:
> unsignedint khz;
> unsigned long   jiffies;
> u64 aperf;
> u64 mperf;

sure, no problem -- I agreed that looks better.

But it seems there is some inconsistency about this style nit --
even in this directory.  If there is consensus going forward,
would it make sense for coding-style.rst and checkpatch.pl
to squawk about this, so you don't have to?


>> +};
>> +
>> +static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
>> +
>> +/*
>> + * aperfmperf_snapshot_khz()
>> + * On the current CPU, snapshot APERF, MPERF, and jiffies
>> + * unless we already did it within 10ms
>> + * calculate kHz, save snapshot
>> + */
>> +static void aperfmperf_snapshot_khz(void *dummy)
>> +{
>> + u64 aperf, aperf_delta;
>> + u64 mperf, mperf_delta;
>> + struct aperfmperf_sample *s = _cpu_var(samples);
>
> This is invoked via a smp function call, so you want
>
>  this_cpu_ptr(samples)
>
> here.

done. thanks!

>> + /* Don't bother re-computing within 10 ms */
>> + if (time_before(jiffies, s->jiffies + HZ/100))
>> + goto out;
>
> That way you can spare the gotos and simply return

happy to remove the gotos, thanks!

>> index a5ce0bbe..cfc6220 100644
>> --- a/include/linux/cpufreq.h
>> +++ b/include/linux/cpufreq.h
>> @@ -883,6 +883,19 @@ static inline bool policy_has_boost_freq(struct 
>> cpufreq_policy *policy)
>>  }
>>  #endif
>>
>> +#ifdef CONFIG_X86
>> +extern unsigned int aperfmperf_khz_on_cpu(unsigned int cpu);
>> +static inline unsigned int arch_freq_get_on_cpu(int cpu)

> ... having cpu as int and unsigned int is not really consistent.

True.  the SMP code uses int cpu, while cpufreq_policy.cpu is an unsigned int.
I'll use "int cpu".

> Please don't add arch specific crap in general headers.
>
> The simple way to avoid that is to have a weak function and have an arch
> override for it. If that does not work because the cpufreq stuff must be
> built as a module, then you still can avoid CONFIG_X86 and have something
> like CONFIG_ARCH_HAS_FOO.

Thanks -- this is not modular code, and so yes, __weak works -- hadn't
had occasion to use it before...
Attached is the incremental diff responding to your comments, in case
that is convenient.
I'll re-send this series with this patch updated in a sec.

thanks,
Len Brown, Intel Open Source Technology Center
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
index 5ccf63a..d869c86 100644
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -14,10 +14,10 @@
 #include 
 
 struct aperfmperf_sample {
-   unsigned int khz;
-   unsigned long jiffies;
-   u64 aperf;
-   u64 mperf;
+   unsigned intkhz;
+   unsigned long   jiffies;
+   u64 aperf;
+   u64 mperf;
 };
 
 static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
@@ -32,11 +32,11 @@ static void aperfmperf_snapshot_khz(void *dummy)
 {
u64 aperf, aperf_delta;
u64 mperf, mperf_delta;
-   struct aperfmperf_sample *s = _cpu_var(samples);
+   struct aperfmperf_sample *s = this_cpu_ptr();
 
/* Don't bother re-computing within 10 ms */
if (time_before(jiffies, s->jiffies + HZ/100))
-   goto out;
+   return;
 
rdmsrl(MSR_IA32_APERF, aperf);
rdmsrl(MSR_IA32_MPERF, mperf);
@@ -49,7 +49,7 @@ static void aperfmperf_snapshot_khz(void *dummy)
 * increments faster than we can read it.
 */
if (mperf_delta == 0)
-   goto out;
+   return;
 
/*
 * if (cpu_khz * aperf_delta) fits into ULLONG_MAX, then
@@ -63,12 +63,9 @@ static void aperfmperf_snapshot_khz(void *dummy)
s->jiffies = jiffies;
s->aperf = aperf;
s->mperf = mperf;
-
-out:
-   put_cpu_var(samples);
 }
 
-unsigned int aperfmperf_khz_on_cpu(unsigned int cpu)
+unsigned int arch_freq_get_on_cpu(int cpu)
 {
if (!cpu_khz)
return 0;
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a667fac..6e7424d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -632,6 +632,11 @@ show_one(cpuinfo_transition_latency, 
cpuinfo.transition_latency);
 show_one(scaling_min_freq, min);
 show_one(scaling_max_freq, max);
 
+__weak unsigned int arch_freq_get_on_cpu(int cpu)
+{
+   return 0;
+}
+
 static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf)
 {
ssize_t ret;
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index cfc6220..905117b 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h

Re: Stable/distro kernel testing in Plumbers 2017

[gre...@linuxfoundation.org]

On Fri, Jun 23, 2017 at 03:37:28AM +, Levin, Alexander (Sasha Levin) wrote:
> Hi all,
> 
> We were hoping to discuss the state of -stable/distro kernel testing 
> in the Testing & Fuzzing MC in Plumbers 2017.
> 
> Mainly we want to understand what sort of testing is being done, how 
> bug reports are being addressed, and what improvments can we make to 
> improve the process.
> 
> The format is pretty open, we can do a BoF type of discussion and 
> talks as part of the MC if anyone is interested in doing any.
> 
> It would be great to know who is interested in this, and would be able 
> to attend Plumbers (https://www.linuxplumbersconf.org/2017/).

I'll be there and would attend this.

thanks,

greg k-h

Re: Stable/distro kernel testing in Plumbers 2017

[gre...@linuxfoundation.org]

On Fri, Jun 23, 2017 at 03:37:28AM +, Levin, Alexander (Sasha Levin) wrote:
> Hi all,
> 
> We were hoping to discuss the state of -stable/distro kernel testing 
> in the Testing & Fuzzing MC in Plumbers 2017.
> 
> Mainly we want to understand what sort of testing is being done, how 
> bug reports are being addressed, and what improvments can we make to 
> improve the process.
> 
> The format is pretty open, we can do a BoF type of discussion and 
> talks as part of the MC if anyone is interested in doing any.
> 
> It would be great to know who is interested in this, and would be able 
> to attend Plumbers (https://www.linuxplumbersconf.org/2017/).

I'll be there and would attend this.

thanks,

greg k-h

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Greg Kroah-Hartman]

On Sat, Jun 24, 2017 at 02:34:07AM +0200, Luis R. Rodriguez wrote:
> So taking the position that any kselftest script on linux-next or a future
> kernel should never break stable implicate that *any* fix going upstream for
> which there is a respective ksefltest test *must* have a stable upstream fix.

What, no!  If it's a bug, that kselftest points out, great, it's up to
stable or a vendor to backport that fix if they want it.

Again, it's just like any other test suite, look at xfstests, no one
gets mad when it adds new tests that fail on old kernels, due to bugs
there, right?

> Its not obvious to me that everyone is aware of this. What do we do about
> those cases where we *don't* want a stable fix due to the complexity?

That's up to the stable maintainers or the vendors that maintain their
own kernel trees.

thanks,

greg k-h

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Greg Kroah-Hartman]

On Sat, Jun 24, 2017 at 02:34:07AM +0200, Luis R. Rodriguez wrote:
> So taking the position that any kselftest script on linux-next or a future
> kernel should never break stable implicate that *any* fix going upstream for
> which there is a respective ksefltest test *must* have a stable upstream fix.

What, no!  If it's a bug, that kselftest points out, great, it's up to
stable or a vendor to backport that fix if they want it.

Again, it's just like any other test suite, look at xfstests, no one
gets mad when it adds new tests that fail on old kernels, due to bugs
there, right?

> Its not obvious to me that everyone is aware of this. What do we do about
> those cases where we *don't* want a stable fix due to the complexity?

That's up to the stable maintainers or the vendors that maintain their
own kernel trees.

thanks,

greg k-h

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Greg Kroah-Hartman]

On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote:
> Greg, for context, the issue here is that we made what was arguably a
> design error in seccomp's interaction with ptrace.  After determining
> that fixing it solved a bunch of problems and didn't break any user
> programs, we fixed it.  There might be new code that relies on the fix
> being present in the sense that it would be insecure without the fix.
> 
> The problem is that the fix is moderately intrusive and doesn't seem
> like a great candidate for backporting, although we could plausibly do
> it.

That's fine, not all bugfixes that tests are created to find, should be
backported.  That's up to the stable maintainers, or someone who has a
device/vendor tree based on that kernel if they want to do that or not.

That has nothing to do with the fact that the test should fail or
gracefully degrade.  Tests should fail if the action that they are
testing fails.  They should degrade and not run if the _feature_ they
are testing is not present.

Yes, sometimes this is hard, like with the seccomp stuff, and will not
always work, but that's the rule for our userspace api independant of
any testing framework or code.

Look at xfstests, no one gets mad when it adds a new test that old
kernels fail at.  It's up to someone else to either backport the kernel
change, if they want it fixed in an old kernel, not to have xfstests
just not run it at all!  There's nothing different here either.

thanks,

greg k-h

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Greg Kroah-Hartman]

On Thu, Jun 22, 2017 at 07:40:49PM -0700, Andy Lutomirski wrote:
> Greg, for context, the issue here is that we made what was arguably a
> design error in seccomp's interaction with ptrace.  After determining
> that fixing it solved a bunch of problems and didn't break any user
> programs, we fixed it.  There might be new code that relies on the fix
> being present in the sense that it would be insecure without the fix.
> 
> The problem is that the fix is moderately intrusive and doesn't seem
> like a great candidate for backporting, although we could plausibly do
> it.

That's fine, not all bugfixes that tests are created to find, should be
backported.  That's up to the stable maintainers, or someone who has a
device/vendor tree based on that kernel if they want to do that or not.

That has nothing to do with the fact that the test should fail or
gracefully degrade.  Tests should fail if the action that they are
testing fails.  They should degrade and not run if the _feature_ they
are testing is not present.

Yes, sometimes this is hard, like with the seccomp stuff, and will not
always work, but that's the rule for our userspace api independant of
any testing framework or code.

Look at xfstests, no one gets mad when it adds a new test that old
kernels fail at.  It's up to someone else to either backport the kernel
change, if they want it fixed in an old kernel, not to have xfstests
just not run it at all!  There's nothing different here either.

thanks,

greg k-h

Re: [HMM 09/15] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v5

[John Hubbard]

On 05/24/2017 10:20 AM, Jérôme Glisse wrote:
[...]

+/*
+ * hmm_devmem_fault_range() - migrate back a virtual range of memory
+ *
+ * @devmem: hmm_devmem struct use to track and manage the ZONE_DEVICE memory
+ * @vma: virtual memory area containing the range to be migrated
+ * @ops: migration callback for allocating destination memory and copying
+ * @src: array of unsigned long containing source pfns
+ * @dst: array of unsigned long containing destination pfns
+ * @start: start address of the range to migrate (inclusive)
+ * @addr: fault address (must be inside the range)
+ * @end: end address of the range to migrate (exclusive)
+ * @private: pointer passed back to each of the callback
+ * Returns: 0 on success, VM_FAULT_SIGBUS on error
+ *
+ * This is a wrapper around migrate_vma() which checks the migration status
+ * for a given fault address and returns the corresponding page fault handler
+ * status. That will be 0 on success, or VM_FAULT_SIGBUS if migration failed
+ * for the faulting address.
+ *
+ * This is a helper intendend to be used by the ZONE_DEVICE fault handler.
+ */
+int hmm_devmem_fault_range(struct hmm_devmem *devmem,
+  struct vm_area_struct *vma,
+  const struct migrate_vma_ops *ops,
+  unsigned long *src,
+  unsigned long *dst,
+  unsigned long start,
+  unsigned long addr,
+  unsigned long end,
+  void *private)
+{
+   if (migrate_vma(ops, vma, start, end, src, dst, private))
+   return VM_FAULT_SIGBUS;
+
+   if (dst[(addr - start) >> PAGE_SHIFT] & MIGRATE_PFN_ERROR)
+   return VM_FAULT_SIGBUS;
+
+   return 0;
+}
+EXPORT_SYMBOL(hmm_devmem_fault_range);
+#endif /* IS_ENABLED(CONFIG_HMM_DEVMEM) */



Hi Jerome (+Evgeny),

After some time and testing, I'd like to recommend that we delete the above 
hmm_dev_fault_range() function from the patchset. Reasons:


1. Our driver code is actually easier to follow if we call migrate_vma() directly, for CPU 
faults. That's because there are a lot of hmm_* calls in both directions (driver <--> 
core), already, and it takes some time to remember which direction each one goes.


2. The helper is a little confusing to use, what with a start, end, *and* an 
addr argument.

3. ...and it doesn't add anything that the driver can't trivially do itself.

So, let's just remove it. Less is more this time. :)

thanks,
--
John Hubbard
NVIDIA

Re: [HMM 09/15] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v5

[John Hubbard]

On 05/24/2017 10:20 AM, Jérôme Glisse wrote:
[...]

+/*
+ * hmm_devmem_fault_range() - migrate back a virtual range of memory
+ *
+ * @devmem: hmm_devmem struct use to track and manage the ZONE_DEVICE memory
+ * @vma: virtual memory area containing the range to be migrated
+ * @ops: migration callback for allocating destination memory and copying
+ * @src: array of unsigned long containing source pfns
+ * @dst: array of unsigned long containing destination pfns
+ * @start: start address of the range to migrate (inclusive)
+ * @addr: fault address (must be inside the range)
+ * @end: end address of the range to migrate (exclusive)
+ * @private: pointer passed back to each of the callback
+ * Returns: 0 on success, VM_FAULT_SIGBUS on error
+ *
+ * This is a wrapper around migrate_vma() which checks the migration status
+ * for a given fault address and returns the corresponding page fault handler
+ * status. That will be 0 on success, or VM_FAULT_SIGBUS if migration failed
+ * for the faulting address.
+ *
+ * This is a helper intendend to be used by the ZONE_DEVICE fault handler.
+ */
+int hmm_devmem_fault_range(struct hmm_devmem *devmem,
+  struct vm_area_struct *vma,
+  const struct migrate_vma_ops *ops,
+  unsigned long *src,
+  unsigned long *dst,
+  unsigned long start,
+  unsigned long addr,
+  unsigned long end,
+  void *private)
+{
+   if (migrate_vma(ops, vma, start, end, src, dst, private))
+   return VM_FAULT_SIGBUS;
+
+   if (dst[(addr - start) >> PAGE_SHIFT] & MIGRATE_PFN_ERROR)
+   return VM_FAULT_SIGBUS;
+
+   return 0;
+}
+EXPORT_SYMBOL(hmm_devmem_fault_range);
+#endif /* IS_ENABLED(CONFIG_HMM_DEVMEM) */



Hi Jerome (+Evgeny),

After some time and testing, I'd like to recommend that we delete the above 
hmm_dev_fault_range() function from the patchset. Reasons:


1. Our driver code is actually easier to follow if we call migrate_vma() directly, for CPU 
faults. That's because there are a lot of hmm_* calls in both directions (driver <--> 
core), already, and it takes some time to remember which direction each one goes.


2. The helper is a little confusing to use, what with a start, end, *and* an 
addr argument.

3. ...and it doesn't add anything that the driver can't trivially do itself.

So, let's just remove it. Less is more this time. :)

thanks,
--
John Hubbard
NVIDIA

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

[Yunsheng Lin]

Hi, Andrew

On 2017/6/24 11:12, Andrew Lunn wrote:
>> +int phy_loopback(struct phy_device *phydev, bool enable)
>> +{
>> +struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
>> +int ret = 0;
>> +
>> +if (enable && phydev->loopback_enabled)
>> +return -EBUSY;
>> +
>> +if (!enable && !phydev->loopback_enabled)
>> +return -EINVAL;
>> +
>> +if (phydev->drv && phydrv->set_loopback)
>> +ret = phydrv->set_loopback(phydev, enable);
> 
>   else
>   ret = -EOPNOTSUPP;
> 
>> +
>> +if (ret)
>> +return ret;
>> +
>> +phydev->loopback_enabled = enable;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(phy_loopback);
> 
> One of the comments we made of the PHY code in the hns driver is that
> its locking is completely broken. You have made the same error
> here. The core needs to hold the mutex while calling into the PHY
> driver.
Do you mean hns_nic_config_phy_loopback need to hold the mutex while
calling phy_loopback? and other place that calling phy_* function?

Best Regards
Yunsheng Lin

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

[Yunsheng Lin]

Hi, Andrew

On 2017/6/24 11:12, Andrew Lunn wrote:
>> +int phy_loopback(struct phy_device *phydev, bool enable)
>> +{
>> +struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
>> +int ret = 0;
>> +
>> +if (enable && phydev->loopback_enabled)
>> +return -EBUSY;
>> +
>> +if (!enable && !phydev->loopback_enabled)
>> +return -EINVAL;
>> +
>> +if (phydev->drv && phydrv->set_loopback)
>> +ret = phydrv->set_loopback(phydev, enable);
> 
>   else
>   ret = -EOPNOTSUPP;
> 
>> +
>> +if (ret)
>> +return ret;
>> +
>> +phydev->loopback_enabled = enable;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(phy_loopback);
> 
> One of the comments we made of the PHY code in the hns driver is that
> its locking is completely broken. You have made the same error
> here. The core needs to hold the mutex while calling into the PHY
> driver.
Do you mean hns_nic_config_phy_loopback need to hold the mutex while
calling phy_loopback? and other place that calling phy_* function?

Best Regards
Yunsheng Lin

[PATCH v5] trace: ras: add ARM processor error information trace event

[Xie XiuQi]

Add a new trace event for ARM processor error information, so that
the user will know what error occurred. With this information the
user may take appropriate action.

These trace events are consistent with the ARM processor error
information table which defined in UEFI 2.6 spec section N.2.4.4.1.

---
v5: add trace enabled condition which is lost on v4 back again
put flag after the type to keep multiple_error on a 2 byte boundary

v4: use __print_flags instead of __print_symbolic, because ARM_PROC_ERR_FLAGS
might have more than on bit set.
setting up default values for __entry to avoid a lot of else branches.
set flags to 0 by default instead of ~0.
fix a typo
rename arm_proc_err to arm_err_info_event
remove "ARM Processor Error: " prefix
rebase on Tyler's patchset v17 "Add UEFI 2.6 and ACPI 6.1 updates for RAS 
on ARM64"

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

v3: no change

v2: add trace enabled condition as Steven's suggestion.
fix a typo.

https://patchwork.kernel.org/patch/9653767/
---

Cc: Steven Rostedt 
Cc: Tyler Baicar 
Signed-off-by: Xie XiuQi 
---
 drivers/ras/ras.c   | 11 +++
 include/linux/cper.h|  5 
 include/ras/ras_event.h | 79 +
 3 files changed, 95 insertions(+)

diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index 39701a5..f76ab0f 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -22,7 +22,17 @@ void log_non_standard_event(const uuid_le *sec_type, const 
uuid_le *fru_id,
 
 void log_arm_hw_error(struct cper_sec_proc_arm *err)
 {
+   int i;
+   struct cper_arm_err_info *err_info;
+
trace_arm_event(err);
+
+   if (!trace_arm_err_info_event_enabled())
+   return;
+
+   err_info = (struct cper_arm_err_info *)(err + 1);
+   for (i = 0; i < err->err_info_num; i++, err_info++)
+   trace_arm_err_info_event(err_info);
 }
 
 static int __init ras_init(void)
@@ -42,6 +52,7 @@ static int __init ras_init(void)
 EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
 EXPORT_TRACEPOINT_SYMBOL_GPL(non_standard_event);
 EXPORT_TRACEPOINT_SYMBOL_GPL(arm_event);
+EXPORT_TRACEPOINT_SYMBOL_GPL(arm_err_info_event);
 
 int __init parse_ras_param(char *str)
 {
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 4c671fc..17546bf 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -275,6 +275,11 @@ enum {
 #define CPER_ARM_INFO_FLAGS_PROPAGATED BIT(2)
 #define CPER_ARM_INFO_FLAGS_OVERFLOW   BIT(3)
 
+#define CPER_ARM_INFO_TYPE_CACHE   0
+#define CPER_ARM_INFO_TYPE_TLB 1
+#define CPER_ARM_INFO_TYPE_BUS 2
+#define CPER_ARM_INFO_TYPE_UARCH   3
+
 /*
  * All tables and structs must be byte-packed to match CPER
  * specification, since the tables are provided by the system BIOS
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 429f46f..dd91ba8 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -206,6 +206,85 @@
  __entry->running_state, __entry->psci_state)
 );
 
+#define ARM_PROC_ERR_TYPE  \
+   EM ( CPER_ARM_INFO_TYPE_CACHE, "cache error" )  \
+   EM ( CPER_ARM_INFO_TYPE_TLB,  "TLB error" ) \
+   EM ( CPER_ARM_INFO_TYPE_BUS, "bus error" )  \
+   EMe ( CPER_ARM_INFO_TYPE_UARCH, "micro-architectural error" )
+
+/*
+ * First define the enums in MM_ACTION_RESULT to be exported to userspace
+ * via TRACE_DEFINE_ENUM().
+ */
+#undef EM
+#undef EMe
+#define EM(a, b) TRACE_DEFINE_ENUM(a);
+#define EMe(a, b)  TRACE_DEFINE_ENUM(a);
+
+ARM_PROC_ERR_TYPE
+
+/*
+ * Now redefine the EM() and EMe() macros to map the enums to the strings
+ * that will be printed in the output.
+ */
+#undef EM
+#undef EMe
+#define EM(a, b)   { a, b },
+#define EMe(a, b)  { a, b }
+
+#define show_proc_err_flags(flags) __print_flags(flags, "|",   
\
+   { CPER_ARM_INFO_FLAGS_FIRST,"First error captured" },   
\
+   { CPER_ARM_INFO_FLAGS_LAST, "Last error captured" },
\
+   { CPER_ARM_INFO_FLAGS_PROPAGATED,   "Propagated" }, 
\
+   { CPER_ARM_INFO_FLAGS_OVERFLOW, "Overflow" })
+
+TRACE_EVENT(arm_err_info_event,
+
+   TP_PROTO(const struct cper_arm_err_info *err),
+
+   TP_ARGS(err),
+
+   TP_STRUCT__entry(
+   __field(u8, type)
+   __field(u8, flags)
+   __field(u16, multiple_error)
+   __field(u64, error_info)
+   __field(u64, virt_fault_addr)
+   __field(u64, physical_fault_addr)
+   ),
+
+   TP_fast_assign(
+   __entry->type = err->type;
+   memset(&__entry->flags, 0,
+   sizeof(*__entry) - offsetof(typeof(*__entry), flags));
+   __entry->multiple_error = ~0;
+
+   if 

[PATCH v5] trace: ras: add ARM processor error information trace event

[Xie XiuQi]

Add a new trace event for ARM processor error information, so that
the user will know what error occurred. With this information the
user may take appropriate action.

These trace events are consistent with the ARM processor error
information table which defined in UEFI 2.6 spec section N.2.4.4.1.

---
v5: add trace enabled condition which is lost on v4 back again
put flag after the type to keep multiple_error on a 2 byte boundary

v4: use __print_flags instead of __print_symbolic, because ARM_PROC_ERR_FLAGS
might have more than on bit set.
setting up default values for __entry to avoid a lot of else branches.
set flags to 0 by default instead of ~0.
fix a typo
rename arm_proc_err to arm_err_info_event
remove "ARM Processor Error: " prefix
rebase on Tyler's patchset v17 "Add UEFI 2.6 and ACPI 6.1 updates for RAS 
on ARM64"

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

v3: no change

v2: add trace enabled condition as Steven's suggestion.
fix a typo.

https://patchwork.kernel.org/patch/9653767/
---

Cc: Steven Rostedt 
Cc: Tyler Baicar 
Signed-off-by: Xie XiuQi 
---
 drivers/ras/ras.c   | 11 +++
 include/linux/cper.h|  5 
 include/ras/ras_event.h | 79 +
 3 files changed, 95 insertions(+)

diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index 39701a5..f76ab0f 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -22,7 +22,17 @@ void log_non_standard_event(const uuid_le *sec_type, const 
uuid_le *fru_id,
 
 void log_arm_hw_error(struct cper_sec_proc_arm *err)
 {
+   int i;
+   struct cper_arm_err_info *err_info;
+
trace_arm_event(err);
+
+   if (!trace_arm_err_info_event_enabled())
+   return;
+
+   err_info = (struct cper_arm_err_info *)(err + 1);
+   for (i = 0; i < err->err_info_num; i++, err_info++)
+   trace_arm_err_info_event(err_info);
 }
 
 static int __init ras_init(void)
@@ -42,6 +52,7 @@ static int __init ras_init(void)
 EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
 EXPORT_TRACEPOINT_SYMBOL_GPL(non_standard_event);
 EXPORT_TRACEPOINT_SYMBOL_GPL(arm_event);
+EXPORT_TRACEPOINT_SYMBOL_GPL(arm_err_info_event);
 
 int __init parse_ras_param(char *str)
 {
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 4c671fc..17546bf 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -275,6 +275,11 @@ enum {
 #define CPER_ARM_INFO_FLAGS_PROPAGATED BIT(2)
 #define CPER_ARM_INFO_FLAGS_OVERFLOW   BIT(3)
 
+#define CPER_ARM_INFO_TYPE_CACHE   0
+#define CPER_ARM_INFO_TYPE_TLB 1
+#define CPER_ARM_INFO_TYPE_BUS 2
+#define CPER_ARM_INFO_TYPE_UARCH   3
+
 /*
  * All tables and structs must be byte-packed to match CPER
  * specification, since the tables are provided by the system BIOS
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 429f46f..dd91ba8 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -206,6 +206,85 @@
  __entry->running_state, __entry->psci_state)
 );
 
+#define ARM_PROC_ERR_TYPE  \
+   EM ( CPER_ARM_INFO_TYPE_CACHE, "cache error" )  \
+   EM ( CPER_ARM_INFO_TYPE_TLB,  "TLB error" ) \
+   EM ( CPER_ARM_INFO_TYPE_BUS, "bus error" )  \
+   EMe ( CPER_ARM_INFO_TYPE_UARCH, "micro-architectural error" )
+
+/*
+ * First define the enums in MM_ACTION_RESULT to be exported to userspace
+ * via TRACE_DEFINE_ENUM().
+ */
+#undef EM
+#undef EMe
+#define EM(a, b) TRACE_DEFINE_ENUM(a);
+#define EMe(a, b)  TRACE_DEFINE_ENUM(a);
+
+ARM_PROC_ERR_TYPE
+
+/*
+ * Now redefine the EM() and EMe() macros to map the enums to the strings
+ * that will be printed in the output.
+ */
+#undef EM
+#undef EMe
+#define EM(a, b)   { a, b },
+#define EMe(a, b)  { a, b }
+
+#define show_proc_err_flags(flags) __print_flags(flags, "|",   
\
+   { CPER_ARM_INFO_FLAGS_FIRST,"First error captured" },   
\
+   { CPER_ARM_INFO_FLAGS_LAST, "Last error captured" },
\
+   { CPER_ARM_INFO_FLAGS_PROPAGATED,   "Propagated" }, 
\
+   { CPER_ARM_INFO_FLAGS_OVERFLOW, "Overflow" })
+
+TRACE_EVENT(arm_err_info_event,
+
+   TP_PROTO(const struct cper_arm_err_info *err),
+
+   TP_ARGS(err),
+
+   TP_STRUCT__entry(
+   __field(u8, type)
+   __field(u8, flags)
+   __field(u16, multiple_error)
+   __field(u64, error_info)
+   __field(u64, virt_fault_addr)
+   __field(u64, physical_fault_addr)
+   ),
+
+   TP_fast_assign(
+   __entry->type = err->type;
+   memset(&__entry->flags, 0,
+   sizeof(*__entry) - offsetof(typeof(*__entry), flags));
+   __entry->multiple_error = ~0;
+
+   if (err->validation_bits & CPER_ARM_INFO_VALID_MULTI_ERR)
+ 

Re: [PATCH 3/7] staging: ccree: add support for older HW revisions

[kbuild test robot]

Hi Gilad,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20170623]
[cannot apply to v4.12-rc6]
[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/Gilad-Ben-Yossef/staging-ccree-bug-fixes-and-TODO-items-for-4-13/20170623-134445
config: x86_64-randconfig-b0-06241039 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/staging/ccree/ssi_sram_mgr.c: In function 'ssi_sram_mgr_init':
>> drivers/staging/ccree/ssi_sram_mgr.c:76: warning: format '%x' expects type 
>> 'unsigned int', but argument 3 has type 'dma_addr_t'

vim +76 drivers/staging/ccree/ssi_sram_mgr.c

60  /* Allocate "this" context */
61  drvdata->sram_mgr_handle = kzalloc(
62  sizeof(struct ssi_sram_mgr_ctx), GFP_KERNEL);
63  if (!drvdata->sram_mgr_handle) {
64  SSI_LOG_ERR("Not enough memory to allocate SRAM_MGR ctx 
(%zu)\n",
65  sizeof(struct ssi_sram_mgr_ctx));
66  rc = -ENOMEM;
67  goto out;
68  }
69  smgr_ctx = drvdata->sram_mgr_handle;
70  
71  if (drvdata->hw_rev < CC_HW_REV_712) {
72  /* Pool starts after ROM bytes */
73  start = 
(dma_addr_t)CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF,
74  HOST_SEP_SRAM_THRESHOLD));
75  if ((start & 0x3) != 0) {
  > 76  SSI_LOG_ERR("Invalid SRAM offset 0x%x\n", 
start);
77  rc = -ENODEV;
78  goto out;
79  }
80  }
81  
82  smgr_ctx->sram_free_offset = start;
83  return 0;
84  

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


.config.gz
Description: application/gzip

Re: [PATCH 3/7] staging: ccree: add support for older HW revisions

[kbuild test robot]

Hi Gilad,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20170623]
[cannot apply to v4.12-rc6]
[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/Gilad-Ben-Yossef/staging-ccree-bug-fixes-and-TODO-items-for-4-13/20170623-134445
config: x86_64-randconfig-b0-06241039 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/staging/ccree/ssi_sram_mgr.c: In function 'ssi_sram_mgr_init':
>> drivers/staging/ccree/ssi_sram_mgr.c:76: warning: format '%x' expects type 
>> 'unsigned int', but argument 3 has type 'dma_addr_t'

vim +76 drivers/staging/ccree/ssi_sram_mgr.c

60  /* Allocate "this" context */
61  drvdata->sram_mgr_handle = kzalloc(
62  sizeof(struct ssi_sram_mgr_ctx), GFP_KERNEL);
63  if (!drvdata->sram_mgr_handle) {
64  SSI_LOG_ERR("Not enough memory to allocate SRAM_MGR ctx 
(%zu)\n",
65  sizeof(struct ssi_sram_mgr_ctx));
66  rc = -ENOMEM;
67  goto out;
68  }
69  smgr_ctx = drvdata->sram_mgr_handle;
70  
71  if (drvdata->hw_rev < CC_HW_REV_712) {
72  /* Pool starts after ROM bytes */
73  start = 
(dma_addr_t)CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF,
74  HOST_SEP_SRAM_THRESHOLD));
75  if ((start & 0x3) != 0) {
  > 76  SSI_LOG_ERR("Invalid SRAM offset 0x%x\n", 
start);
77  rc = -ENODEV;
78  goto out;
79  }
80  }
81  
82  smgr_ctx->sram_free_offset = start;
83  return 0;
84  

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


.config.gz
Description: application/gzip

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

[srishti sharma]

On Sat, Jun 24, 2017 at 8:11 AM, srishti sharma  wrote:
> On Fri, Jun 23, 2017 at 9:50 PM, Greg KH  wrote:
>> On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote:
>>> Fixed alignment so that it matched open parenthesis.
>>>
>>> Signed-off-by: srishti sharma 
>>> ---
>>>  .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 
>>> +-
>>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> What differs from your previous patch?
>
> The previous patch had only one check fixed , this has all checks of
> the type = parenthesis_alignment in the file bcm2835-ctl.c fixed .
> Also there was a typo in the description of the previous patch so I
> corrected that .
>
>Always properly version your
>> patch so we know what to take.
>>
>> Please fix and resend.

I have re-sent version 2 .
>>
>> thanks,
>>
>> greg k-h
>

Regards,
Srishti

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

[srishti sharma]

On Sat, Jun 24, 2017 at 8:11 AM, srishti sharma  wrote:
> On Fri, Jun 23, 2017 at 9:50 PM, Greg KH  wrote:
>> On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote:
>>> Fixed alignment so that it matched open parenthesis.
>>>
>>> Signed-off-by: srishti sharma 
>>> ---
>>>  .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 
>>> +-
>>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> What differs from your previous patch?
>
> The previous patch had only one check fixed , this has all checks of
> the type = parenthesis_alignment in the file bcm2835-ctl.c fixed .
> Also there was a typo in the description of the previous patch so I
> corrected that .
>
>Always properly version your
>> patch so we know what to take.
>>
>> Please fix and resend.

I have re-sent version 2 .
>>
>> thanks,
>>
>> greg k-h
>

Regards,
Srishti

[PATCH v2] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.

[srishti sharma]

Fixed alignment so that it matched open parenthesis.

Signed-off-by: srishti sharma 
---
Changes in v2:
 -Fix all checks of the type "alignment should match open parenthesis" for a 
file in the same patch.

 .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index f484bb0..ce8ab36 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -105,7 +105,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_ctl_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+  struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int changed = 0;
@@ -185,7 +185,7 @@ static struct snd_kcontrol_new snd_bcm2835_ctl[] = {
 };

 static int snd_bcm2835_spdif_default_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+ struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -193,7 +193,7 @@ static int snd_bcm2835_spdif_default_info(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_default_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -210,7 +210,7 @@ static int snd_bcm2835_spdif_default_get(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_default_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
@@ -230,7 +230,7 @@ static int snd_bcm2835_spdif_default_put(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+  struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -238,7 +238,7 @@ static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
 {
/*
 * bcm2835 supports only consumer mode and sets all other format flags
@@ -249,7 +249,7 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_stream_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -257,7 +257,7 @@ static int snd_bcm2835_spdif_stream_info(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -274,7 +274,7 @@ static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_stream_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
--
2.7.4

[PATCH v2] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.

[srishti sharma]

Fixed alignment so that it matched open parenthesis.

Signed-off-by: srishti sharma 
---
Changes in v2:
 -Fix all checks of the type "alignment should match open parenthesis" for a 
file in the same patch.

 .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index f484bb0..ce8ab36 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -105,7 +105,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_ctl_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+  struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int changed = 0;
@@ -185,7 +185,7 @@ static struct snd_kcontrol_new snd_bcm2835_ctl[] = {
 };

 static int snd_bcm2835_spdif_default_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+ struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -193,7 +193,7 @@ static int snd_bcm2835_spdif_default_info(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_default_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -210,7 +210,7 @@ static int snd_bcm2835_spdif_default_get(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_default_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
@@ -230,7 +230,7 @@ static int snd_bcm2835_spdif_default_put(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+  struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -238,7 +238,7 @@ static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
 {
/*
 * bcm2835 supports only consumer mode and sets all other format flags
@@ -249,7 +249,7 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_stream_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -257,7 +257,7 @@ static int snd_bcm2835_spdif_stream_info(struct 
snd_kcontrol *kcontrol,
 }

 static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -274,7 +274,7 @@ static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol 
*kcontrol,
 }

 static int snd_bcm2835_spdif_stream_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
--
2.7.4

Re: [PATCH NET v3 2/2] net: hns: Use phy_driver to setup Phy loopback

[Andrew Lunn]

>  static int hns_nic_config_phy_loopback(struct phy_device *phy_dev, u8 en)
>  {
> -#define COPPER_CONTROL_REG 0
> -#define PHY_POWER_DOWN BIT(11)
> -#define PHY_LOOP_BACK BIT(14)
> - u16 val = 0;
> + int err;
>  
>   if (phy_dev->is_c45) /* c45 branch adding for XGE PHY */
>   return -ENOTSUPP;

You should take this out as well. You want the core to tell you if
loopback is supported or not. At some point, a c45 PHY could support
loopback.

> + case MAC_LOOP_PHY_NONE:
>   if ((phy_dev) && (!phy_dev->is_c45))
>   ret |= hns_nic_config_phy_loopback(phy_dev, 0x0);

same here.

 Andrew

Re: [PATCH NET v3 2/2] net: hns: Use phy_driver to setup Phy loopback

[Andrew Lunn]

>  static int hns_nic_config_phy_loopback(struct phy_device *phy_dev, u8 en)
>  {
> -#define COPPER_CONTROL_REG 0
> -#define PHY_POWER_DOWN BIT(11)
> -#define PHY_LOOP_BACK BIT(14)
> - u16 val = 0;
> + int err;
>  
>   if (phy_dev->is_c45) /* c45 branch adding for XGE PHY */
>   return -ENOTSUPP;

You should take this out as well. You want the core to tell you if
loopback is supported or not. At some point, a c45 PHY could support
loopback.

> + case MAC_LOOP_PHY_NONE:
>   if ((phy_dev) && (!phy_dev->is_c45))
>   ret |= hns_nic_config_phy_loopback(phy_dev, 0x0);

same here.

 Andrew

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

[Andrew Lunn]

> +int phy_loopback(struct phy_device *phydev, bool enable)
> +{
> + struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
> + int ret = 0;
> +
> + if (enable && phydev->loopback_enabled)
> + return -EBUSY;
> +
> + if (!enable && !phydev->loopback_enabled)
> + return -EINVAL;
> +
> + if (phydev->drv && phydrv->set_loopback)
> + ret = phydrv->set_loopback(phydev, enable);

else
ret = -EOPNOTSUPP;

> +
> + if (ret)
> + return ret;
> +
> + phydev->loopback_enabled = enable;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(phy_loopback);

One of the comments we made of the PHY code in the hns driver is that
its locking is completely broken. You have made the same error
here. The core needs to hold the mutex while calling into the PHY
driver.

Andrew

Re: [PATCH NET v3 1/2] net: phy: Add phy loopback support in net phy framework

[Andrew Lunn]

> +int phy_loopback(struct phy_device *phydev, bool enable)
> +{
> + struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
> + int ret = 0;
> +
> + if (enable && phydev->loopback_enabled)
> + return -EBUSY;
> +
> + if (!enable && !phydev->loopback_enabled)
> + return -EINVAL;
> +
> + if (phydev->drv && phydrv->set_loopback)
> + ret = phydrv->set_loopback(phydev, enable);

else
ret = -EOPNOTSUPP;

> +
> + if (ret)
> + return ret;
> +
> + phydev->loopback_enabled = enable;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(phy_loopback);

One of the comments we made of the PHY code in the hns driver is that
its locking is completely broken. You have made the same error
here. The core needs to hold the mutex while calling into the PHY
driver.

Andrew

[tip:irq/core 30/72] kernel/irq/debugfs.c:192:2-16: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reor

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
head:   8d9d51b62e8558bbc11c6b978acad001f9ea7a42
commit: 087cdfb662ae50e3826e7cd2e54b6519d07b60f0 [30/72] genirq/debugfs: Add 
proper debugfs interface


coccinelle warnings: (new ones prefixed by >>)

>> kernel/irq/debugfs.c:192:2-16: WARNING: NULL check before freeing functions 
>> like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not 
>> needed. Maybe consider reorganizing relevant code to avoid passing NULL 
>> values.

vim +192 kernel/irq/debugfs.c

   176  
   177  void irq_add_debugfs_entry(unsigned int irq, struct irq_desc *desc)
   178  {
   179  char name [10];
   180  
   181  if (!irq_dir || !desc || desc->debugfs_file)
   182  return;
   183  
   184  sprintf(name, "%d", irq);
   185  desc->debugfs_file = debugfs_create_file(name, 0444, irq_dir, 
desc,
   186   _irq_ops);
   187  }
   188  
   189  void irq_remove_debugfs_entry(struct irq_desc *desc)
   190  {
   191  if (desc->debugfs_file)
 > 192  debugfs_remove(desc->debugfs_file);
   193  }
   194  
   195  static int __init irq_debugfs_init(void)
   196  {
   197  struct dentry *root_dir;
   198  int irq;
   199  
   200  root_dir = debugfs_create_dir("irq", NULL);

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

[tip:irq/core 30/72] kernel/irq/debugfs.c:192:2-16: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reor

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
head:   8d9d51b62e8558bbc11c6b978acad001f9ea7a42
commit: 087cdfb662ae50e3826e7cd2e54b6519d07b60f0 [30/72] genirq/debugfs: Add 
proper debugfs interface


coccinelle warnings: (new ones prefixed by >>)

>> kernel/irq/debugfs.c:192:2-16: WARNING: NULL check before freeing functions 
>> like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not 
>> needed. Maybe consider reorganizing relevant code to avoid passing NULL 
>> values.

vim +192 kernel/irq/debugfs.c

   176  
   177  void irq_add_debugfs_entry(unsigned int irq, struct irq_desc *desc)
   178  {
   179  char name [10];
   180  
   181  if (!irq_dir || !desc || desc->debugfs_file)
   182  return;
   183  
   184  sprintf(name, "%d", irq);
   185  desc->debugfs_file = debugfs_create_file(name, 0444, irq_dir, 
desc,
   186   _irq_ops);
   187  }
   188  
   189  void irq_remove_debugfs_entry(struct irq_desc *desc)
   190  {
   191  if (desc->debugfs_file)
 > 192  debugfs_remove(desc->debugfs_file);
   193  }
   194  
   195  static int __init irq_debugfs_init(void)
   196  {
   197  struct dentry *root_dir;
   198  int irq;
   199  
   200  root_dir = debugfs_create_dir("irq", NULL);

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

Re: [PATCH 0/4] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

On Fri, 23 Jun 2017, Ondrej Zary wrote:

> On Friday 23 June 2017 13:01:53 Finn Thain wrote:
> > On Fri, 23 Jun 2017, I wrote:
> > > Does this patch help? It should be applied on top of this series of 4.
> >
> > Sorry, I sent the wrong diff. Please try this patch instead.
> 
> Thanks, much better now: both HDD and CD-ROM seem to work on DTC and non-DTC 
> chips. I get many of these messages with CD-ROM:
> [  912.397076] generic_NCR5380_pread: No end dma signal (4096/4096)
> [  913.141225] generic_NCR5380_pread: No end dma signal (4096/4096)
> 
> Maybe just remove this error message as in my original patch?
> 

The "data loop" algorithm in the datasheet syas that if End of DMA doesn't 
become asserted after a transfer, this is an error condition.

Your log (above) shows 4096/4096 bytes so I think that End of DMA is 
tested too soon: the datasheet says that End of DMA takes 100 ns to become 
asserted even after all of the relevant signals reach their final state.

I'll re-do the series to account for this.

Thanks for testing.

-- 

Re: [PATCH 0/4] g_NCR5380: PDMA fixes and cleanup

[Finn Thain]

On Fri, 23 Jun 2017, Ondrej Zary wrote:

> On Friday 23 June 2017 13:01:53 Finn Thain wrote:
> > On Fri, 23 Jun 2017, I wrote:
> > > Does this patch help? It should be applied on top of this series of 4.
> >
> > Sorry, I sent the wrong diff. Please try this patch instead.
> 
> Thanks, much better now: both HDD and CD-ROM seem to work on DTC and non-DTC 
> chips. I get many of these messages with CD-ROM:
> [  912.397076] generic_NCR5380_pread: No end dma signal (4096/4096)
> [  913.141225] generic_NCR5380_pread: No end dma signal (4096/4096)
> 
> Maybe just remove this error message as in my original patch?
> 

The "data loop" algorithm in the datasheet syas that if End of DMA doesn't 
become asserted after a transfer, this is an error condition.

Your log (above) shows 4096/4096 bytes so I think that End of DMA is 
tested too soon: the datasheet says that End of DMA takes 100 ns to become 
asserted even after all of the relevant signals reach their final state.

I'll re-do the series to account for this.

Thanks for testing.

-- 

[PATCH v3 3/3] ARM: dts: sunxi: Add R_LRADC support for A83T

[Ziping Chen]

From: Ziping Chen 

Allwinner A83T SoC has a low res adc like the one
in Allwinner A10 SoC. Now the driver has been
modified to support it.

Add support for it.

Signed-off-by: Ziping Chen 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 8923ba625b76..ccee83cc0610 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -301,5 +301,12 @@
interrupt-controller;
#interrupt-cells = <3>;
};
+
+   r_lradc: lradc@01f03c00 {
+   compatible = "allwinner,sun8i-a83t-r-lradc-keys";
+   reg = <0x01f03c00 0x100>;
+   interrupts = ;
+   status = "disabled";
+   };
};
 };
-- 
2.11.0

[PATCH v3 3/3] ARM: dts: sunxi: Add R_LRADC support for A83T

[Ziping Chen]

From: Ziping Chen 

Allwinner A83T SoC has a low res adc like the one
in Allwinner A10 SoC. Now the driver has been
modified to support it.

Add support for it.

Signed-off-by: Ziping Chen 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 8923ba625b76..ccee83cc0610 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -301,5 +301,12 @@
interrupt-controller;
#interrupt-cells = <3>;
};
+
+   r_lradc: lradc@01f03c00 {
+   compatible = "allwinner,sun8i-a83t-r-lradc-keys";
+   reg = <0x01f03c00 0x100>;
+   interrupts = ;
+   status = "disabled";
+   };
};
 };
-- 
2.11.0

[PATCH v3 1/3] input: sun4i-a10-lradc-keys: Add support for A83T

[Ziping Chen]

From: Ziping Chen 

Allwinner A83T SoC has a low res adc like the one
in Allwinner A10 SoC, however, the A10 SoC's vref
of lradc internally is divided by 2/3 and the A83T
SoC's vref of lradc internally is divided by 3/4,
thus add a hardware variant for it to be compatible
with various devices.

Signed-off-by: Ziping Chen 
---
 drivers/input/keyboard/sun4i-lradc-keys.c | 38 +++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c 
b/drivers/input/keyboard/sun4i-lradc-keys.c
index a37c172452e6..bfd2038a9047 100644
--- a/drivers/input/keyboard/sun4i-lradc-keys.c
+++ b/drivers/input/keyboard/sun4i-lradc-keys.c
@@ -46,6 +46,7 @@
 #define CONTINUE_TIME_SEL(x)   ((x) << 16) /* 4 bits */
 #define KEY_MODE_SEL(x)((x) << 12) /* 2 bits */
 #define LEVELA_B_CNT(x)((x) << 8)  /* 4 bits */
+#define HOLD_KEY_EN(x) ((x) << 7)
 #define HOLD_EN(x) ((x) << 6)
 #define LEVELB_VOL(x)  ((x) << 4)  /* 2 bits */
 #define SAMPLE_RATE(x) ((x) << 2)  /* 2 bits */
@@ -63,6 +64,25 @@
 #defineCHAN0_KEYDOWN_IRQ   BIT(1)
 #define CHAN0_DATA_IRQ BIT(0)
 
+/* struct lradc_variant - Describe sun4i-a10-lradc-keys hardware variant
+ * @divisor_numerator: The numerator of lradc Vref internally divisor
+ * @divisor_denominator:   The denominator of lradc Vref internally divisor
+ */
+struct lradc_variant {
+   u8 divisor_numerator;
+   u8 divisor_denominator;
+};
+
+static const struct lradc_variant lradc_variant_a10 = {
+   .divisor_numerator = 2,
+   .divisor_denominator = 3
+};
+
+static const struct lradc_variant r_lradc_variant_a83t = {
+   .divisor_numerator = 3,
+   .divisor_denominator = 4
+};
+
 struct sun4i_lradc_keymap {
u32 voltage;
u32 keycode;
@@ -74,6 +94,7 @@ struct sun4i_lradc_data {
void __iomem *base;
struct regulator *vref_supply;
struct sun4i_lradc_keymap *chan0_map;
+   const struct lradc_variant *variant;
u32 chan0_map_count;
u32 chan0_keycode;
u32 vref;
@@ -128,9 +149,9 @@ static int sun4i_lradc_open(struct input_dev *dev)
if (error)
return error;
 
-   /* lradc Vref internally is divided by 2/3 */
-   lradc->vref = regulator_get_voltage(lradc->vref_supply) * 2 / 3;
-
+   lradc->vref = regulator_get_voltage(lradc->vref_supply) *
+ lradc->variant->divisor_numerator /
+ lradc->variant->divisor_denominator;
/*
 * Set sample time to 4 ms / 250 Hz. Wait 2 * 4 ms for key to
 * stabilize on press, wait (1 + 1) * 4 ms for key release
@@ -222,6 +243,12 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
if (error)
return error;
 
+   lradc->variant = of_device_get_match_data(>dev);
+   if (!lradc->variant) {
+   dev_err(>dev, "Missing sun4i-a10-lradc-keys variant\n");
+   return -EINVAL;
+   }
+
lradc->vref_supply = devm_regulator_get(dev, "vref");
if (IS_ERR(lradc->vref_supply))
return PTR_ERR(lradc->vref_supply);
@@ -265,7 +292,10 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id sun4i_lradc_of_match[] = {
-   { .compatible = "allwinner,sun4i-a10-lradc-keys", },
+   { .compatible = "allwinner,sun4i-a10-lradc-keys",
+   .data = _variant_a10 },
+   { .compatible = "allwinner,sun8i-a83t-r-lradc-keys",
+   .data = _lradc_variant_a83t },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_lradc_of_match);
-- 
2.11.0

[PATCH v3 1/3] input: sun4i-a10-lradc-keys: Add support for A83T

[Ziping Chen]

From: Ziping Chen 

Allwinner A83T SoC has a low res adc like the one
in Allwinner A10 SoC, however, the A10 SoC's vref
of lradc internally is divided by 2/3 and the A83T
SoC's vref of lradc internally is divided by 3/4,
thus add a hardware variant for it to be compatible
with various devices.

Signed-off-by: Ziping Chen 
---
 drivers/input/keyboard/sun4i-lradc-keys.c | 38 +++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c 
b/drivers/input/keyboard/sun4i-lradc-keys.c
index a37c172452e6..bfd2038a9047 100644
--- a/drivers/input/keyboard/sun4i-lradc-keys.c
+++ b/drivers/input/keyboard/sun4i-lradc-keys.c
@@ -46,6 +46,7 @@
 #define CONTINUE_TIME_SEL(x)   ((x) << 16) /* 4 bits */
 #define KEY_MODE_SEL(x)((x) << 12) /* 2 bits */
 #define LEVELA_B_CNT(x)((x) << 8)  /* 4 bits */
+#define HOLD_KEY_EN(x) ((x) << 7)
 #define HOLD_EN(x) ((x) << 6)
 #define LEVELB_VOL(x)  ((x) << 4)  /* 2 bits */
 #define SAMPLE_RATE(x) ((x) << 2)  /* 2 bits */
@@ -63,6 +64,25 @@
 #defineCHAN0_KEYDOWN_IRQ   BIT(1)
 #define CHAN0_DATA_IRQ BIT(0)
 
+/* struct lradc_variant - Describe sun4i-a10-lradc-keys hardware variant
+ * @divisor_numerator: The numerator of lradc Vref internally divisor
+ * @divisor_denominator:   The denominator of lradc Vref internally divisor
+ */
+struct lradc_variant {
+   u8 divisor_numerator;
+   u8 divisor_denominator;
+};
+
+static const struct lradc_variant lradc_variant_a10 = {
+   .divisor_numerator = 2,
+   .divisor_denominator = 3
+};
+
+static const struct lradc_variant r_lradc_variant_a83t = {
+   .divisor_numerator = 3,
+   .divisor_denominator = 4
+};
+
 struct sun4i_lradc_keymap {
u32 voltage;
u32 keycode;
@@ -74,6 +94,7 @@ struct sun4i_lradc_data {
void __iomem *base;
struct regulator *vref_supply;
struct sun4i_lradc_keymap *chan0_map;
+   const struct lradc_variant *variant;
u32 chan0_map_count;
u32 chan0_keycode;
u32 vref;
@@ -128,9 +149,9 @@ static int sun4i_lradc_open(struct input_dev *dev)
if (error)
return error;
 
-   /* lradc Vref internally is divided by 2/3 */
-   lradc->vref = regulator_get_voltage(lradc->vref_supply) * 2 / 3;
-
+   lradc->vref = regulator_get_voltage(lradc->vref_supply) *
+ lradc->variant->divisor_numerator /
+ lradc->variant->divisor_denominator;
/*
 * Set sample time to 4 ms / 250 Hz. Wait 2 * 4 ms for key to
 * stabilize on press, wait (1 + 1) * 4 ms for key release
@@ -222,6 +243,12 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
if (error)
return error;
 
+   lradc->variant = of_device_get_match_data(>dev);
+   if (!lradc->variant) {
+   dev_err(>dev, "Missing sun4i-a10-lradc-keys variant\n");
+   return -EINVAL;
+   }
+
lradc->vref_supply = devm_regulator_get(dev, "vref");
if (IS_ERR(lradc->vref_supply))
return PTR_ERR(lradc->vref_supply);
@@ -265,7 +292,10 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id sun4i_lradc_of_match[] = {
-   { .compatible = "allwinner,sun4i-a10-lradc-keys", },
+   { .compatible = "allwinner,sun4i-a10-lradc-keys",
+   .data = _variant_a10 },
+   { .compatible = "allwinner,sun8i-a83t-r-lradc-keys",
+   .data = _lradc_variant_a83t },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_lradc_of_match);
-- 
2.11.0

[PATCH v3 0/3] Allwinner A83T R_LRADC support

[Ziping Chen]

From: Ziping Chen 

Hi,

This is the remaining parts of my A83T R_LRADC support series

Allwinner A83T SoC has a low res adc like the one in Allwinner
A10 SoC.

Add support for it. 

Changes for v3:
- Fix some issuses raised by Maxime.
- Added Rob's ACK.

Changes for v2:
- Add an A83T specific compatible.

Ziping Chen (3):
  input: sun4i-a10-lradc-keys: Add support for A83T
  dt-bindings: input: Add R_LRADC support for A83T
  ARM: dts: sunxi: Add R_LRADC support for A83T

 .../devicetree/bindings/input/sun4i-lradc-keys.txt |  6 ++--
 arch/arm/boot/dts/sun8i-a83t.dtsi  |  7 
 drivers/input/keyboard/sun4i-lradc-keys.c  | 38 +++---
 3 files changed, 45 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

[Ziping Chen]

From: Ziping Chen 

Allwinner A83T SoC has a low res adc like the one
in Allwinner A10 SoC.

Add binding for it.

Signed-off-by: Ziping Chen 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt 
b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
index 4357e498ef04..525d85e3043f 100644
--- a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
+++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
@@ -2,12 +2,14 @@ Allwinner sun4i low res adc attached tablet keys
 
 
 Required properties:
- - compatible: "allwinner,sun4i-a10-lradc-keys"
+ - compatible: should be one of the following string:
+   "allwinner,sun4i-a10-lradc-keys"
+   "allwinner,sun8i-a83t-r-lradc-keys"
  - reg: mmio address range of the chip
  - interrupts: interrupt to which the chip is connected
  - vref-supply: powersupply for the lradc reference voltage
 
-Each key is represented as a sub-node of "allwinner,sun4i-a10-lradc-keys":
+Each key is represented as a sub-node of the compatible mentioned above:
 
 Required subnode-properties:
- label: Descriptive name of the key.
-- 
2.11.0

[PATCH v3 0/3] Allwinner A83T R_LRADC support

[Ziping Chen]

From: Ziping Chen 

Hi,

This is the remaining parts of my A83T R_LRADC support series

Allwinner A83T SoC has a low res adc like the one in Allwinner
A10 SoC.

Add support for it. 

Changes for v3:
- Fix some issuses raised by Maxime.
- Added Rob's ACK.

Changes for v2:
- Add an A83T specific compatible.

Ziping Chen (3):
  input: sun4i-a10-lradc-keys: Add support for A83T
  dt-bindings: input: Add R_LRADC support for A83T
  ARM: dts: sunxi: Add R_LRADC support for A83T

 .../devicetree/bindings/input/sun4i-lradc-keys.txt |  6 ++--
 arch/arm/boot/dts/sun8i-a83t.dtsi  |  7 
 drivers/input/keyboard/sun4i-lradc-keys.c  | 38 +++---
 3 files changed, 45 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH v3 2/3] dt-bindings: input: Add R_LRADC support for A83T

[Ziping Chen]

From: Ziping Chen 

Allwinner A83T SoC has a low res adc like the one
in Allwinner A10 SoC.

Add binding for it.

Signed-off-by: Ziping Chen 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt 
b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
index 4357e498ef04..525d85e3043f 100644
--- a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
+++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
@@ -2,12 +2,14 @@ Allwinner sun4i low res adc attached tablet keys
 
 
 Required properties:
- - compatible: "allwinner,sun4i-a10-lradc-keys"
+ - compatible: should be one of the following string:
+   "allwinner,sun4i-a10-lradc-keys"
+   "allwinner,sun8i-a83t-r-lradc-keys"
  - reg: mmio address range of the chip
  - interrupts: interrupt to which the chip is connected
  - vref-supply: powersupply for the lradc reference voltage
 
-Each key is represented as a sub-node of "allwinner,sun4i-a10-lradc-keys":
+Each key is represented as a sub-node of the compatible mentioned above:
 
 Required subnode-properties:
- label: Descriptive name of the key.
-- 
2.11.0

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

[srishti sharma]

On Fri, Jun 23, 2017 at 9:50 PM, Greg KH  wrote:
> On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote:
>> Fixed alignment so that it matched open parenthesis.
>>
>> Signed-off-by: srishti sharma 
>> ---
>>  .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 
>> +-
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> What differs from your previous patch?

The previous patch had only one check fixed , this has all checks of
the type = parenthesis_alignment in the file bcm2835-ctl.c fixed .
Also there was a typo in the description of the previous patch so I
corrected that .

   Always properly version your
> patch so we know what to take.
>
> Please fix and resend.
>
> thanks,
>
> greg k-h

Regards,
Srishti

Re: [PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis

[srishti sharma]

On Fri, Jun 23, 2017 at 9:50 PM, Greg KH  wrote:
> On Thu, Jun 15, 2017 at 01:04:55AM +0530, srishti sharma wrote:
>> Fixed alignment so that it matched open parenthesis.
>>
>> Signed-off-by: srishti sharma 
>> ---
>>  .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 
>> +-
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> What differs from your previous patch?

The previous patch had only one check fixed , this has all checks of
the type = parenthesis_alignment in the file bcm2835-ctl.c fixed .
Also there was a typo in the description of the previous patch so I
corrected that .

   Always properly version your
> patch so we know what to take.
>
> Please fix and resend.
>
> thanks,
>
> greg k-h

Regards,
Srishti

Re: [PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support

[Andrew Lunn]

On Fri, Jun 23, 2017 at 12:59:07PM +0800, David Wu wrote:
> To make internal phy worked, need to configure the phy_clock,
> phy cru_reset and related registers.
> 
> Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13
> Signed-off-by: David Wu 
> ---
>  .../devicetree/bindings/net/rockchip-dwmac.txt |  3 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 82 
> ++
>  2 files changed, 85 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt 
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> index 8f42755..0514f69 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -22,6 +22,7 @@ Required properties:
>  < SCLK_MACREF_OUT> clock gate for RMII reference clock output
>  < ACLK_GMAC>: AXI clock gate for GMAC
>  < PCLK_GMAC>: APB clock gate for GMAC
> +< MAC_PHY>: clock for internal macphy

If this is the PHY clock, should it actually be specified in the PHY
binding? Can you read the PHY ID registers with this clock off?

 Andrew

Re: [PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support

[Andrew Lunn]

On Fri, Jun 23, 2017 at 12:59:07PM +0800, David Wu wrote:
> To make internal phy worked, need to configure the phy_clock,
> phy cru_reset and related registers.
> 
> Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13
> Signed-off-by: David Wu 
> ---
>  .../devicetree/bindings/net/rockchip-dwmac.txt |  3 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 82 
> ++
>  2 files changed, 85 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt 
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> index 8f42755..0514f69 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -22,6 +22,7 @@ Required properties:
>  < SCLK_MACREF_OUT> clock gate for RMII reference clock output
>  < ACLK_GMAC>: AXI clock gate for GMAC
>  < PCLK_GMAC>: APB clock gate for GMAC
> +< MAC_PHY>: clock for internal macphy

If this is the PHY clock, should it actually be specified in the PHY
binding? Can you read the PHY ID registers with this clock off?

 Andrew

Re: [PATCH 04/11] net: stmmac: dwmac-rk: Remove unwanted code for rk3328_set_to_rmii()

[Andrew Lunn]

On Fri, Jun 23, 2017 at 12:42:02PM +0800, David Wu wrote:
> This is wrong setting for rk3328_set_to_rmii(), so remove it.
> 
> Change-Id: I9953784ea44335d90710e5473960c95b3d68a5fd

Hi David

This is not a reconsigned tag for a patch.

 Andrew

Re: [PATCH 04/11] net: stmmac: dwmac-rk: Remove unwanted code for rk3328_set_to_rmii()

[Andrew Lunn]

On Fri, Jun 23, 2017 at 12:42:02PM +0800, David Wu wrote:
> This is wrong setting for rk3328_set_to_rmii(), so remove it.
> 
> Change-Id: I9953784ea44335d90710e5473960c95b3d68a5fd

Hi David

This is not a reconsigned tag for a patch.

 Andrew

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

[Andrew Lunn]

On Fri, Jun 23, 2017 at 12:41:59PM +0800, David Wu wrote:
> Support internal ephy currently.
> 
> Signed-off-by: David Wu 
> ---
>  drivers/net/phy/Kconfig|  4 ++
>  drivers/net/phy/Makefile   |  1 +
>  drivers/net/phy/rockchip.c | 94 
> ++
>  3 files changed, 99 insertions(+)
>  create mode 100644 drivers/net/phy/rockchip.c
> 
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index c360dd6..86010d4 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -350,6 +350,10 @@ config XILINX_GMII2RGMII
>   the Reduced Gigabit Media Independent Interface(RGMII) between
>   Ethernet physical media devices and the Gigabit Ethernet controller.
>  
> +config ROCKCHIP_MAC_PHY

This is a bit of an odd name, having both MAC and PHY in it. Are there
any other RockChip PHYs? Any external PHYS? Are they register
incompatible with the internal PHY?  Is it even RockChip IP? Or has it
been licensed from somebody else?

I would more likely just call it ROCKCHIP_PHY.

  Andrew

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

[Andrew Lunn]

On Fri, Jun 23, 2017 at 12:41:59PM +0800, David Wu wrote:
> Support internal ephy currently.
> 
> Signed-off-by: David Wu 
> ---
>  drivers/net/phy/Kconfig|  4 ++
>  drivers/net/phy/Makefile   |  1 +
>  drivers/net/phy/rockchip.c | 94 
> ++
>  3 files changed, 99 insertions(+)
>  create mode 100644 drivers/net/phy/rockchip.c
> 
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index c360dd6..86010d4 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -350,6 +350,10 @@ config XILINX_GMII2RGMII
>   the Reduced Gigabit Media Independent Interface(RGMII) between
>   Ethernet physical media devices and the Gigabit Ethernet controller.
>  
> +config ROCKCHIP_MAC_PHY

This is a bit of an odd name, having both MAC and PHY in it. Are there
any other RockChip PHYs? Any external PHYS? Are they register
incompatible with the internal PHY?  Is it even RockChip IP? Or has it
been licensed from somebody else?

I would more likely just call it ROCKCHIP_PHY.

  Andrew

[PATCH] net/icmp: restore source address if packet is NATed

[Jason A. Donenfeld]

The ICMP routines use the source address for two reasons:

1. Rate-limiting ICMP transmissions based on source address, so
   that one source address cannot provoke a flood of replies. If
   the source address is wrong, the rate limiting will be
   incorrectly applied.

2. Choosing the interface and hence new source address of the
   generated ICMP packet. If the original packet source address
   is wrong, ICMP replies will be sent from the wrong source
   address, resulting in either a misdelivery, infoleak, or just
   general network admin confusion.

Most of the time, the icmp_send and icmpv6_send routines can just reach
down into the skb's IP header to determine the saddr. However, if
icmp_send or icmpv6_send is being called from a network device driver --
there are a few in the tree -- then it's possible that by the time
icmp_send or icmpv6_send looks at the packet, the packet's source
address has already been transformed by SNAT or MASQUERADE or some other
transformation that CONNTRACK knows about. In this case, the packet's
source address is most certainly the *wrong* source address to be used
for the purpose of ICMP replies.

Rather, the source address we want to use for ICMP replies is the
original one, from before the transformation occurred.

Fortunately, it's very easy to just ask CONNTRACK if it knows about this
packet, and if so, how to fix it up. The saddr is the only field in the
header we need to fix up, for the purposes of the subsequent processing
in the icmp_send and icmpv6_send functions, so we do the lookup very
early on, so that the rest of the ICMP machinery can progress as usual.
In my tests, this setup works very well.

Signed-off-by: Jason A. Donenfeld 
---
 net/ipv4/icmp.c | 21 +
 net/ipv6/icmp.c | 21 +
 2 files changed, 42 insertions(+)

diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index c2be26b98b5f..30aa6aa79fd2 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -97,6 +97,10 @@
 #include 
 #include 
 #include 
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+#include 
+#include 
+#endif
 
 /*
  * Build xmit assembly blocks
@@ -586,6 +590,10 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
u32 mark;
struct net *net;
struct sock *sk;
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   enum ip_conntrack_info ctinfo;
+   struct nf_conn *ct;
+#endif
 
if (!rt)
goto out;
@@ -604,6 +612,19 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
goto out;
 
/*
+*  If this function is called after the skb has already been
+*  NAT transformed, the ratelimiting will apply to the wrong
+*  saddr, and the reply will will be marked as coming from the
+*  wrong host. So, we fix it up here in case connection tracking
+*  enables that.
+*/
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   ct = nf_ct_get(skb_in, );
+   if (ct)
+   iph->saddr = ct->tuplehash[0].tuple.src.u3.ip;
+#endif
+
+   /*
 *  No replies to physical multicast/broadcast
 */
if (skb_in->pkt_type != PACKET_HOST)
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 8d7b113958b1..ee8a2853121e 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -69,6 +69,10 @@
 #include 
 #include 
 #include 
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+#include 
+#include 
+#endif
 
 #include 
 
@@ -422,12 +426,29 @@ static void icmp6_send(struct sk_buff *skb, u8 type, u8 
code, __u32 info,
int len;
int err = 0;
u32 mark = IP6_REPLY_MARK(net, skb->mark);
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   enum ip_conntrack_info ctinfo;
+   struct nf_conn *ct;
+#endif
 
if ((u8 *)hdr < skb->head ||
(skb_network_header(skb) + sizeof(*hdr)) > skb_tail_pointer(skb))
return;
 
/*
+*  If this function is called after the skb has already been
+*  NAT transformed, the ratelimiting will apply to the wrong
+*  saddr, and the reply will will be marked as coming from the
+*  wrong host. So, we fix it up here in case connection tracking
+*  enables that.
+*/
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   ct = nf_ct_get(skb, );
+   if (ct)
+   hdr->saddr = ct->tuplehash[0].tuple.src.u3.in6;
+#endif
+
+   /*
 *  Make sure we respect the rules
 *  i.e. RFC 1885 2.4(e)
 *  Rule (e.1) is enforced by not using icmp6_send
-- 
2.13.1

[PATCH] net/icmp: restore source address if packet is NATed

[Jason A. Donenfeld]

The ICMP routines use the source address for two reasons:

1. Rate-limiting ICMP transmissions based on source address, so
   that one source address cannot provoke a flood of replies. If
   the source address is wrong, the rate limiting will be
   incorrectly applied.

2. Choosing the interface and hence new source address of the
   generated ICMP packet. If the original packet source address
   is wrong, ICMP replies will be sent from the wrong source
   address, resulting in either a misdelivery, infoleak, or just
   general network admin confusion.

Most of the time, the icmp_send and icmpv6_send routines can just reach
down into the skb's IP header to determine the saddr. However, if
icmp_send or icmpv6_send is being called from a network device driver --
there are a few in the tree -- then it's possible that by the time
icmp_send or icmpv6_send looks at the packet, the packet's source
address has already been transformed by SNAT or MASQUERADE or some other
transformation that CONNTRACK knows about. In this case, the packet's
source address is most certainly the *wrong* source address to be used
for the purpose of ICMP replies.

Rather, the source address we want to use for ICMP replies is the
original one, from before the transformation occurred.

Fortunately, it's very easy to just ask CONNTRACK if it knows about this
packet, and if so, how to fix it up. The saddr is the only field in the
header we need to fix up, for the purposes of the subsequent processing
in the icmp_send and icmpv6_send functions, so we do the lookup very
early on, so that the rest of the ICMP machinery can progress as usual.
In my tests, this setup works very well.

Signed-off-by: Jason A. Donenfeld 
---
 net/ipv4/icmp.c | 21 +
 net/ipv6/icmp.c | 21 +
 2 files changed, 42 insertions(+)

diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index c2be26b98b5f..30aa6aa79fd2 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -97,6 +97,10 @@
 #include 
 #include 
 #include 
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+#include 
+#include 
+#endif
 
 /*
  * Build xmit assembly blocks
@@ -586,6 +590,10 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
u32 mark;
struct net *net;
struct sock *sk;
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   enum ip_conntrack_info ctinfo;
+   struct nf_conn *ct;
+#endif
 
if (!rt)
goto out;
@@ -604,6 +612,19 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, 
__be32 info)
goto out;
 
/*
+*  If this function is called after the skb has already been
+*  NAT transformed, the ratelimiting will apply to the wrong
+*  saddr, and the reply will will be marked as coming from the
+*  wrong host. So, we fix it up here in case connection tracking
+*  enables that.
+*/
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   ct = nf_ct_get(skb_in, );
+   if (ct)
+   iph->saddr = ct->tuplehash[0].tuple.src.u3.ip;
+#endif
+
+   /*
 *  No replies to physical multicast/broadcast
 */
if (skb_in->pkt_type != PACKET_HOST)
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 8d7b113958b1..ee8a2853121e 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -69,6 +69,10 @@
 #include 
 #include 
 #include 
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+#include 
+#include 
+#endif
 
 #include 
 
@@ -422,12 +426,29 @@ static void icmp6_send(struct sk_buff *skb, u8 type, u8 
code, __u32 info,
int len;
int err = 0;
u32 mark = IP6_REPLY_MARK(net, skb->mark);
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   enum ip_conntrack_info ctinfo;
+   struct nf_conn *ct;
+#endif
 
if ((u8 *)hdr < skb->head ||
(skb_network_header(skb) + sizeof(*hdr)) > skb_tail_pointer(skb))
return;
 
/*
+*  If this function is called after the skb has already been
+*  NAT transformed, the ratelimiting will apply to the wrong
+*  saddr, and the reply will will be marked as coming from the
+*  wrong host. So, we fix it up here in case connection tracking
+*  enables that.
+*/
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+   ct = nf_ct_get(skb, );
+   if (ct)
+   hdr->saddr = ct->tuplehash[0].tuple.src.u3.in6;
+#endif
+
+   /*
 *  Make sure we respect the rules
 *  i.e. RFC 1885 2.4(e)
 *  Rule (e.1) is enforced by not using icmp6_send
-- 
2.13.1

[PATCH] alpha: support R_ALPHA_REFLONG relocations for module loading

[Michael Cree]

Since commit 71810db27c1c853b33 (modversions: treat symbol CRCs
as 32 bit quantities) R_ALPHA_REFLONG relocations can be required
to load modules. This implements it.

Tested-by: Bob Tracy 
Signed-off-by: Michael Cree 
---
 arch/alpha/kernel/module.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index 936bc8f89a67..47632fa8c24e 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -181,6 +181,9 @@ apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
switch (r_type) {
case R_ALPHA_NONE:
break;
+   case R_ALPHA_REFLONG:
+   *(u32 *)location = value;
+   break;
case R_ALPHA_REFQUAD:
/* BUG() can produce misaligned relocations. */
((u32 *)location)[0] = value;
-- 
2.11.0

[PATCH] alpha: support R_ALPHA_REFLONG relocations for module loading

[Michael Cree]

Since commit 71810db27c1c853b33 (modversions: treat symbol CRCs
as 32 bit quantities) R_ALPHA_REFLONG relocations can be required
to load modules. This implements it.

Tested-by: Bob Tracy 
Signed-off-by: Michael Cree 
---
 arch/alpha/kernel/module.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index 936bc8f89a67..47632fa8c24e 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -181,6 +181,9 @@ apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
switch (r_type) {
case R_ALPHA_NONE:
break;
+   case R_ALPHA_REFLONG:
+   *(u32 *)location = value;
+   break;
case R_ALPHA_REFQUAD:
/* BUG() can produce misaligned relocations. */
((u32 *)location)[0] = value;
-- 
2.11.0

Re: [PATCH v2 2/3] dt-bindings: input: Add DT bindings documentation for Allwinner A83T R_LRADC

[Ziping Chen]

Hi

2017-06-24 5:51 GMT+08:00 Rob Herring :
> On Tue, Jun 20, 2017 at 09:44:44PM +0800, Ziping Chen wrote:
>> From: Ziping Chen 
>
> Your subject could be more concise. "DT bindings documentation" is
> redundant.
>
>>
>> Allwinner A83T SoC has a low res adc like the one
>> in Allwinner A10 SoC.
>>
>> Add binding for it.
>>
>> Signed-off-by: Ziping Chen 
>> ---
>>  Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> Otherwise,
>
> Acked-by: Rob Herring 

OK.

Thanks,
Ziping

Re: [PATCH v2 2/3] dt-bindings: input: Add DT bindings documentation for Allwinner A83T R_LRADC

[Ziping Chen]

Hi

2017-06-24 5:51 GMT+08:00 Rob Herring :
> On Tue, Jun 20, 2017 at 09:44:44PM +0800, Ziping Chen wrote:
>> From: Ziping Chen 
>
> Your subject could be more concise. "DT bindings documentation" is
> redundant.
>
>>
>> Allwinner A83T SoC has a low res adc like the one
>> in Allwinner A10 SoC.
>>
>> Add binding for it.
>>
>> Signed-off-by: Ziping Chen 
>> ---
>>  Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> Otherwise,
>
> Acked-by: Rob Herring 

OK.

Thanks,
Ziping

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

[Andrew Lunn]

> +
> +static int internal_config_init(struct phy_device *phydev)
> +{

internal_ is a bit generic. The Marvell Ethernet switches have
internal phy, etc. rockchip_ would be a better prefix.

 Andrew

Re: [PATCH 01/11] net: phy: Add rockchip phy driver support

[Andrew Lunn]

> +
> +static int internal_config_init(struct phy_device *phydev)
> +{

internal_ is a bit generic. The Marvell Ethernet switches have
internal phy, etc. rockchip_ would be a better prefix.

 Andrew

pci: Add generic pcibios_{fixup_bus,align_resource}

[Palmer Dabbelt]

While upstreaming the RISC-V port, it was pointed out that multiple
architectures have copied the mostly empty versions of at least one of these
functions.  This defines weakly bound versions of the common functions and
removes the now obselete functions from other ports.

This has been split out from the RISC-V submission so we can decouple all these
generic changes from our port review process.  There's some discussion on an
earlier version of the patch here

  https://lkml.org/lkml/2017/6/6/998

but I'm afraid a lot of this is really out of my wheelhouse (and I'm pretty
slammed trying to get the RISC-V port in better shape), so I'm afraid I'm not
going to be able to perform the full cleanup suggested.

pci: Add generic pcibios_{fixup_bus,align_resource}

[Palmer Dabbelt]

While upstreaming the RISC-V port, it was pointed out that multiple
architectures have copied the mostly empty versions of at least one of these
functions.  This defines weakly bound versions of the common functions and
removes the now obselete functions from other ports.

This has been split out from the RISC-V submission so we can decouple all these
generic changes from our port review process.  There's some discussion on an
earlier version of the patch here

  https://lkml.org/lkml/2017/6/6/998

but I'm afraid a lot of this is really out of my wheelhouse (and I'm pretty
slammed trying to get the RISC-V port in better shape), so I'm afraid I'm not
going to be able to perform the full cleanup suggested.

[PATCH 1/3] pci: Add a generic, weakly-linked pcibios_fixup_bus

[Palmer Dabbelt]

Multiple architectures define this as an empty function, and I'm adding
another one as part of the RISC-V port.  This adds a __weak version of
pci_fixup_bios and deletes the now obselete ones in a handful of ports.

The only functional change should be that microblaze used to export
pcibios_fixup_bus.  None of the other architectures export this, so I
just dropped it.

Signed-off-by: Palmer Dabbelt 
---
 arch/arc/kernel/pcibios.c |  4 
 arch/arm64/kernel/pci.c   |  8 
 arch/cris/arch-v32/drivers/pci/bios.c |  4 
 arch/microblaze/pci/pci-common.c  |  6 --
 arch/s390/pci/pci.c   |  4 
 arch/sh/drivers/pci/pci.c |  8 
 arch/sparc/kernel/pci.c   |  4 
 arch/tile/kernel/pci.c|  8 
 arch/tile/kernel/pci_gx.c |  5 -
 drivers/pci/probe.c   | 10 ++
 10 files changed, 10 insertions(+), 51 deletions(-)

diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
index 72e1d73d0bd6..1c8df8fd5fed 100644
--- a/arch/arc/kernel/pcibios.c
+++ b/arch/arc/kernel/pcibios.c
@@ -16,7 +16,3 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
 {
return res->start;
 }
-
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index c7e3e6387a49..4c7f451aca05 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -23,14 +23,6 @@
 #include 
 
 /*
- * Called after each bus is probed, but before its children are examined
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* nothing to do, expected to be removed in the future */
-}
-
-/*
  * We don't have to worry about legacy ISA devices, so nothing to do here
  */
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
diff --git a/arch/cris/arch-v32/drivers/pci/bios.c 
b/arch/cris/arch-v32/drivers/pci/bios.c
index 394c2a73d5e2..5cc622c0225e 100644
--- a/arch/cris/arch-v32/drivers/pci/bios.c
+++ b/arch/cris/arch-v32/drivers/pci/bios.c
@@ -2,10 +2,6 @@
 #include 
 #include 
 
-void pcibios_fixup_bus(struct pci_bus *b)
-{
-}
-
 void pcibios_set_master(struct pci_dev *dev)
 {
u8 lat;
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 404fb38d06b7..940f266e5d5c 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -810,12 +810,6 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
}
 }
 
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* nothing to do */
-}
-EXPORT_SYMBOL(pcibios_fixup_bus);
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 8051df109db3..98a54dd63483 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -234,10 +234,6 @@ static int zpci_cfg_store(struct zpci_dev *zdev, int 
offset, u32 val, u8 len)
return rc;
 }
 
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
-
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
   resource_size_t size,
   resource_size_t align)
diff --git a/arch/sh/drivers/pci/pci.c b/arch/sh/drivers/pci/pci.c
index c99ee286b69f..749642e1272e 100644
--- a/arch/sh/drivers/pci/pci.c
+++ b/arch/sh/drivers/pci/pci.c
@@ -155,14 +155,6 @@ static int __init pcibios_init(void)
 subsys_initcall(pcibios_init);
 
 /*
- *  Called after each bus is probed, but before its children
- *  are examined.
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
-
-/*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
  * addresses to be allocated in the 0x000-0x0ff region
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 7eceaa10836f..78d3dc25e126 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -690,10 +690,6 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
return bus;
 }
 
-void pcibios_fixup_bus(struct pci_bus *pbus)
-{
-}
-
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
 {
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index bc6656b5708b..3113d4d5c329 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c
@@ -369,14 +369,6 @@ int __init pcibios_init(void)
 }
 subsys_initcall(pcibios_init);
 
-/*
- * No bus fixups needed.
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* Nothing needs to be done. */
-}
-
 void pcibios_set_master(struct pci_dev *dev)
 {
/* No special bus mastering setup handling. */
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index b554a68eea1b..b89172b592cc 100644
--- 

[PATCH 1/3] pci: Add a generic, weakly-linked pcibios_fixup_bus

[Palmer Dabbelt]

Multiple architectures define this as an empty function, and I'm adding
another one as part of the RISC-V port.  This adds a __weak version of
pci_fixup_bios and deletes the now obselete ones in a handful of ports.

The only functional change should be that microblaze used to export
pcibios_fixup_bus.  None of the other architectures export this, so I
just dropped it.

Signed-off-by: Palmer Dabbelt 
---
 arch/arc/kernel/pcibios.c |  4 
 arch/arm64/kernel/pci.c   |  8 
 arch/cris/arch-v32/drivers/pci/bios.c |  4 
 arch/microblaze/pci/pci-common.c  |  6 --
 arch/s390/pci/pci.c   |  4 
 arch/sh/drivers/pci/pci.c |  8 
 arch/sparc/kernel/pci.c   |  4 
 arch/tile/kernel/pci.c|  8 
 arch/tile/kernel/pci_gx.c |  5 -
 drivers/pci/probe.c   | 10 ++
 10 files changed, 10 insertions(+), 51 deletions(-)

diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
index 72e1d73d0bd6..1c8df8fd5fed 100644
--- a/arch/arc/kernel/pcibios.c
+++ b/arch/arc/kernel/pcibios.c
@@ -16,7 +16,3 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
 {
return res->start;
 }
-
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index c7e3e6387a49..4c7f451aca05 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -23,14 +23,6 @@
 #include 
 
 /*
- * Called after each bus is probed, but before its children are examined
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* nothing to do, expected to be removed in the future */
-}
-
-/*
  * We don't have to worry about legacy ISA devices, so nothing to do here
  */
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
diff --git a/arch/cris/arch-v32/drivers/pci/bios.c 
b/arch/cris/arch-v32/drivers/pci/bios.c
index 394c2a73d5e2..5cc622c0225e 100644
--- a/arch/cris/arch-v32/drivers/pci/bios.c
+++ b/arch/cris/arch-v32/drivers/pci/bios.c
@@ -2,10 +2,6 @@
 #include 
 #include 
 
-void pcibios_fixup_bus(struct pci_bus *b)
-{
-}
-
 void pcibios_set_master(struct pci_dev *dev)
 {
u8 lat;
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 404fb38d06b7..940f266e5d5c 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -810,12 +810,6 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
}
 }
 
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* nothing to do */
-}
-EXPORT_SYMBOL(pcibios_fixup_bus);
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 8051df109db3..98a54dd63483 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -234,10 +234,6 @@ static int zpci_cfg_store(struct zpci_dev *zdev, int 
offset, u32 val, u8 len)
return rc;
 }
 
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
-
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
   resource_size_t size,
   resource_size_t align)
diff --git a/arch/sh/drivers/pci/pci.c b/arch/sh/drivers/pci/pci.c
index c99ee286b69f..749642e1272e 100644
--- a/arch/sh/drivers/pci/pci.c
+++ b/arch/sh/drivers/pci/pci.c
@@ -155,14 +155,6 @@ static int __init pcibios_init(void)
 subsys_initcall(pcibios_init);
 
 /*
- *  Called after each bus is probed, but before its children
- *  are examined.
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
-
-/*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
  * addresses to be allocated in the 0x000-0x0ff region
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 7eceaa10836f..78d3dc25e126 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -690,10 +690,6 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
return bus;
 }
 
-void pcibios_fixup_bus(struct pci_bus *pbus)
-{
-}
-
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
 {
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index bc6656b5708b..3113d4d5c329 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c
@@ -369,14 +369,6 @@ int __init pcibios_init(void)
 }
 subsys_initcall(pcibios_init);
 
-/*
- * No bus fixups needed.
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* Nothing needs to be done. */
-}
-
 void pcibios_set_master(struct pci_dev *dev)
 {
/* No special bus mastering setup handling. */
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index b554a68eea1b..b89172b592cc 100644
--- a/arch/tile/kernel/pci_gx.c

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

[Palmer Dabbelt]

On Wed, 07 Jun 2017 01:01:57 PDT (-0700), Arnd Bergmann wrote:
> On Wed, Jun 7, 2017 at 9:19 AM, Geert Uytterhoeven  
> wrote:
>> CC pci folks
>>
>> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt  wrote:
>>> While upstreaming the RISC-V port, it was pointed out that multiple
>>> architectures (arc, arm64, cris, microblaze, sh, tile) have copied the
>>> mostly empty versions of at least one of these functions.  This defines
>>> weakly bound versions of the common functions so other architetures can
>>> use them.
>>>
>>> Signed-off-by: Palmer Dabbelt 
>
> Thanks a lot for taking care of this!

No problem.

>
>>> diff --git a/drivers/pci/bios.c b/drivers/pci/bios.c
>>> new file mode 100644
>>> index ..ffe34c024aa8
>>> --- /dev/null
>>> +++ b/drivers/pci/bios.c
>>> @@ -0,0 +1,42 @@
>>> +
>>> +/* This file contains weakly bound functions that implement pcibios 
>>> functions
>>> + * that some architectures have copied verbatim.
>>> + */
>
> Instead of adding a new file, I would suggest adding the two functions next
> to their callers, in probe.c and setup-res.c, respectively.

I've split this out into another patch set.

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

[Palmer Dabbelt]

On Thu, 08 Jun 2017 01:35:29 PDT (-0700), Arnd Bergmann wrote:
> On Thu, Jun 8, 2017 at 10:12 AM, Christoph Hellwig  wrote:
>> On Wed, Jun 07, 2017 at 09:19:49AM +0200, Geert Uytterhoeven wrote:
>>> CC pci folks
>>
>> Ok, replying with pci folks in Cc then :)
>>
>> Weak symbols have (rightly) gotten a bad reputation, so maybe
>> we should approach this without them.
>
> Agreed, I would almost never recommend using a __weak symbol,
> but they are already widely used in the PCI subsystem, so I suggested
> using them here for consistency.
>
> We have a struct pci_host_bridge now, and we should eventually
> move most of the 38 pci specific weak  per-architecture symbols
> into per-host driver callbacks, but that I think that would be too much
> to ask for when adding an architecture port.

I agree :)

>> It seems we have a large number of emptry pcibios_fixup_bus calls
>> alreayd, so I think we should simply have the architectures
>> that do define it define a Kconfig or header symbol and not call
>> it at all otherwise.
>
> I would argue that most of them should not be per-architecture
> in the first place, the current state is mostly an artifact of the
> times when each architecture had just one PCI implementation.
>
> The ones that have multiple implementations (arm, powerpc, ...)
> tend to actually override the weak functions with their own
> per-host multiplexers again.
>
>> For the ones that exist as lot just seem to call pci_read_bridge_bases
>> and/or pcibios_fixup_device_resources in one form or another,
>> and I wonder why we even need the arch indirection for that.
>>
>> Similarly for pcibios_align_resource: a lot of architetures seem
>> to have a noop, and the once that don't mostly seem copy and
>> paste code, so we should again have a symbol for architectures
>> to opt into it, and we probably should have a generic helper
>> for the VGA window mirroring code instead of duplicating it multiple
>> times.
>
> I now remember that we already have a host_bridge->align_resource
> callback pointer, so the generic function should definitely try
> to use that.
>
> We could just use the version from arch/mips/pci/pci-generic.c
> and remove that in the process. I'm not sure about why mips calls
> pci_read_bridge_bases() in pcibios_fixup_bus() though, or whether
> this make sense to put in the generic version.

I'm splitting this off into another patch set and sending it to a bunch of PCI
people.

[PATCH 3/3] arc: kernel/pcibios.c is empty, delete it

[Palmer Dabbelt]

Signed-off-by: Palmer Dabbelt 
---
 arch/arc/kernel/Makefile  | 1 -
 arch/arc/kernel/pcibios.c | 9 -
 2 files changed, 10 deletions(-)
 delete mode 100644 arch/arc/kernel/pcibios.c

diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
index 8942c5c3b4c5..2dc5f4296d44 100644
--- a/arch/arc/kernel/Makefile
+++ b/arch/arc/kernel/Makefile
@@ -12,7 +12,6 @@ obj-y := arcksyms.o setup.o irq.o reset.o ptrace.o process.o 
devtree.o
 obj-y  += signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o
 obj-$(CONFIG_ISA_ARCOMPACT)+= entry-compact.o intc-compact.o
 obj-$(CONFIG_ISA_ARCV2)+= entry-arcv2.o intc-arcv2.o
-obj-$(CONFIG_PCI)  += pcibios.o
 
 obj-$(CONFIG_MODULES)  += arcksyms.o module.o
 obj-$(CONFIG_SMP)  += smp.o
diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
deleted file mode 100644
index 05aba5a7b5d2..
--- a/arch/arc/kernel/pcibios.c
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Copyright (C) 2014-2015 Synopsys, Inc. (www.synopsys.com)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-- 
2.13.0

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

[Palmer Dabbelt]

On Thu, 08 Jun 2017 01:35:29 PDT (-0700), Arnd Bergmann wrote:
> On Thu, Jun 8, 2017 at 10:12 AM, Christoph Hellwig  wrote:
>> On Wed, Jun 07, 2017 at 09:19:49AM +0200, Geert Uytterhoeven wrote:
>>> CC pci folks
>>
>> Ok, replying with pci folks in Cc then :)
>>
>> Weak symbols have (rightly) gotten a bad reputation, so maybe
>> we should approach this without them.
>
> Agreed, I would almost never recommend using a __weak symbol,
> but they are already widely used in the PCI subsystem, so I suggested
> using them here for consistency.
>
> We have a struct pci_host_bridge now, and we should eventually
> move most of the 38 pci specific weak  per-architecture symbols
> into per-host driver callbacks, but that I think that would be too much
> to ask for when adding an architecture port.

I agree :)

>> It seems we have a large number of emptry pcibios_fixup_bus calls
>> alreayd, so I think we should simply have the architectures
>> that do define it define a Kconfig or header symbol and not call
>> it at all otherwise.
>
> I would argue that most of them should not be per-architecture
> in the first place, the current state is mostly an artifact of the
> times when each architecture had just one PCI implementation.
>
> The ones that have multiple implementations (arm, powerpc, ...)
> tend to actually override the weak functions with their own
> per-host multiplexers again.
>
>> For the ones that exist as lot just seem to call pci_read_bridge_bases
>> and/or pcibios_fixup_device_resources in one form or another,
>> and I wonder why we even need the arch indirection for that.
>>
>> Similarly for pcibios_align_resource: a lot of architetures seem
>> to have a noop, and the once that don't mostly seem copy and
>> paste code, so we should again have a symbol for architectures
>> to opt into it, and we probably should have a generic helper
>> for the VGA window mirroring code instead of duplicating it multiple
>> times.
>
> I now remember that we already have a host_bridge->align_resource
> callback pointer, so the generic function should definitely try
> to use that.
>
> We could just use the version from arch/mips/pci/pci-generic.c
> and remove that in the process. I'm not sure about why mips calls
> pci_read_bridge_bases() in pcibios_fixup_bus() though, or whether
> this make sense to put in the generic version.

I'm splitting this off into another patch set and sending it to a bunch of PCI
people.

Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

[Palmer Dabbelt]

On Wed, 07 Jun 2017 01:01:57 PDT (-0700), Arnd Bergmann wrote:
> On Wed, Jun 7, 2017 at 9:19 AM, Geert Uytterhoeven  
> wrote:
>> CC pci folks
>>
>> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt  wrote:
>>> While upstreaming the RISC-V port, it was pointed out that multiple
>>> architectures (arc, arm64, cris, microblaze, sh, tile) have copied the
>>> mostly empty versions of at least one of these functions.  This defines
>>> weakly bound versions of the common functions so other architetures can
>>> use them.
>>>
>>> Signed-off-by: Palmer Dabbelt 
>
> Thanks a lot for taking care of this!

No problem.

>
>>> diff --git a/drivers/pci/bios.c b/drivers/pci/bios.c
>>> new file mode 100644
>>> index ..ffe34c024aa8
>>> --- /dev/null
>>> +++ b/drivers/pci/bios.c
>>> @@ -0,0 +1,42 @@
>>> +
>>> +/* This file contains weakly bound functions that implement pcibios 
>>> functions
>>> + * that some architectures have copied verbatim.
>>> + */
>
> Instead of adding a new file, I would suggest adding the two functions next
> to their callers, in probe.c and setup-res.c, respectively.

I've split this out into another patch set.

[PATCH 3/3] arc: kernel/pcibios.c is empty, delete it

[Palmer Dabbelt]

Signed-off-by: Palmer Dabbelt 
---
 arch/arc/kernel/Makefile  | 1 -
 arch/arc/kernel/pcibios.c | 9 -
 2 files changed, 10 deletions(-)
 delete mode 100644 arch/arc/kernel/pcibios.c

diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
index 8942c5c3b4c5..2dc5f4296d44 100644
--- a/arch/arc/kernel/Makefile
+++ b/arch/arc/kernel/Makefile
@@ -12,7 +12,6 @@ obj-y := arcksyms.o setup.o irq.o reset.o ptrace.o process.o 
devtree.o
 obj-y  += signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o
 obj-$(CONFIG_ISA_ARCOMPACT)+= entry-compact.o intc-compact.o
 obj-$(CONFIG_ISA_ARCV2)+= entry-arcv2.o intc-arcv2.o
-obj-$(CONFIG_PCI)  += pcibios.o
 
 obj-$(CONFIG_MODULES)  += arcksyms.o module.o
 obj-$(CONFIG_SMP)  += smp.o
diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
deleted file mode 100644
index 05aba5a7b5d2..
--- a/arch/arc/kernel/pcibios.c
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Copyright (C) 2014-2015 Synopsys, Inc. (www.synopsys.com)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-- 
2.13.0

Re: [PATCH 13/17] RISC-V: Add include subdirectory

[Palmer Dabbelt]

On Wed, 07 Jun 2017 01:12:00 PDT (-0700), Arnd Bergmann wrote:
> On Wed, Jun 7, 2017 at 1:00 AM, Palmer Dabbelt  wrote:
>> This patch adds the include files for the RISC-V port.  These are mostly
>> based on the score port, but there are a lot of arm64-based files as
>> well.
>>
>> Signed-off-by: Palmer Dabbelt 
>
> It might be better to split this up into several parts, as the patch
> is longer than
> most people are willing to review at once.
>
> The uapi should definitely be a separate patch, as it includes the parts that
> cannot be changed any more later. memory management (pgtable, mmu,
> uaccess) would be another part to split out, and possibly all the atomics
> in one separate patch (along with spinlocks and bitops).

OK, we'll do this for the v3.

>
>> +
>> +/* IO barriers.  These only fence on the IO bits because they're only 
>> required
>> + * to order device access.  We're defining mmiowb because our AMO 
>> instructions
>> + * (which are used to implement locks) don't specify ordering.  From 
>> Chapter 7
>> + * of v2.2 of the user ISA:
>> + * "The bits order accesses to one of the two address domains, memory or 
>> I/O,
>> + * depending on which address domain the atomic instruction is accessing. No
>> + * ordering constraint is implied to accesses to the other domain, and a 
>> FENCE
>> + * instruction should be used to order across both domains."
>> + */
>> +
>> +#define __iormb()  __asm__ __volatile__ ("fence i,io" : : : "memory");
>> +#define __iowmb()  __asm__ __volatile__ ("fence io,o" : : : "memory");
>> +
>> +#define mmiowb()   __asm__ __volatile__ ("fence io,io" : : : "memory");
>> +
>> +/*
>> + * Relaxed I/O memory access primitives. These follow the Device memory
>> + * ordering rules but do not guarantee any ordering relative to Normal 
>> memory
>> + * accesses.
>> + */
>> +#define readb_relaxed(c)   ({ u8  __r = __raw_readb(c); __r; })
>> +#define readw_relaxed(c)   ({ u16 __r = le16_to_cpu((__force 
>> __le16)__raw_readw(c)); __r; })
>> +#define readl_relaxed(c)   ({ u32 __r = le32_to_cpu((__force 
>> __le32)__raw_readl(c)); __r; })
>> +#define readq_relaxed(c)   ({ u64 __r = le64_to_cpu((__force 
>> __le64)__raw_readq(c)); __r; })
>> +
>> +#define writeb_relaxed(v,c)((void)__raw_writeb((v),(c)))
>> +#define writew_relaxed(v,c)((void)__raw_writew((__force 
>> u16)cpu_to_le16(v),(c)))
>> +#define writel_relaxed(v,c)((void)__raw_writel((__force 
>> u32)cpu_to_le32(v),(c)))
>> +#define writeq_relaxed(v,c)((void)__raw_writeq((__force 
>> u64)cpu_to_le64(v),(c)))
>> +
>> +/*
>> + * I/O memory access primitives. Reads are ordered relative to any
>> + * following Normal memory access. Writes are ordered relative to any prior
>> + * Normal memory access.
>> + */
>> +#define readb(c)   ({ u8  __v = readb_relaxed(c); __iormb(); 
>> __v; })
>> +#define readw(c)   ({ u16 __v = readw_relaxed(c); __iormb(); 
>> __v; })
>> +#define readl(c)   ({ u32 __v = readl_relaxed(c); __iormb(); 
>> __v; })
>> +#define readq(c)   ({ u64 __v = readq_relaxed(c); __iormb(); 
>> __v; })
>> +
>> +#define writeb(v,c)({ __iowmb(); writeb_relaxed((v),(c)); })
>> +#define writew(v,c)({ __iowmb(); writew_relaxed((v),(c)); })
>> +#define writel(v,c)({ __iowmb(); writel_relaxed((v),(c)); })
>> +#define writeq(v,c)({ __iowmb(); writeq_relaxed((v),(c)); })
>> +
>> +#include 
>
> These do not yet contain all the changes we discussed: the relaxed operations
> don't seem to be ordered against one another and the regular accessors
> are not ordered against DMA.

Sorry, I must have forgotten to write this -- I just wanted to push out a v3
patch set without the changes to the atomics so everything else could be looked
at.  I wanted to just go through the atomics completely and fix them, as I
found a handful of problems (everything was missing the AQ and RL bits, for
example) and figured it would be best to just get them done right.

I think that's not something for after dinner on a Friday, but hopefully I'll
get to it tomorrow morning.

Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource

[Palmer Dabbelt]

On Wed, 07 Jun 2017 02:43:09 PDT (-0700), marc.zyng...@arm.com wrote:
> On 06/06/17 23:59, Palmer Dabbelt wrote:
>> The RISC-V ISA defines a single RTC as well as an SBI oneshot timer.
>> This timer is present on all RISC-V systems.
>>
>> Signed-off-by: Palmer Dabbelt 
>> ---
>>  drivers/clocksource/Kconfig   |   8 +++
>>  drivers/clocksource/Makefile  |   1 +
>>  drivers/clocksource/timer-riscv.c | 118 
>> ++
>>  3 files changed, 127 insertions(+)
>>  create mode 100644 drivers/clocksource/timer-riscv.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 545d541ae20e..1c2c6e7c7fab 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -612,4 +612,12 @@ config CLKSRC_ST_LPC
>>Enable this option to use the Low Power controller timer
>>as clocksource.
>>
>> +config CLKSRC_RISCV
>> +#bool "Clocksource for the RISC-V platform"
>> +def_bool y if RISCV
>> +depends on RISCV
>> +help
>> +  This enables a clocksource based on the RISC-V SBI timer, which is
>> +  built in to all RISC-V systems.
>> +
>>  endmenu
>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>> index 2b5b56a6f00f..408ed9d314dc 100644
>> --- a/drivers/clocksource/Makefile
>> +++ b/drivers/clocksource/Makefile
>> @@ -73,3 +73,4 @@ obj-$(CONFIG_H8300_TMR16)  += h8300_timer16.o
>>  obj-$(CONFIG_H8300_TPU) += h8300_tpu.o
>>  obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
>>  obj-$(CONFIG_X86_NUMACHIP)  += numachip.o
>> +obj-$(CONFIG_CLKSRC_RISCV)  += timer-riscv.o
>> diff --git a/drivers/clocksource/timer-riscv.c 
>> b/drivers/clocksource/timer-riscv.c
>> new file mode 100644
>> index ..04ef7b9130b3
>> --- /dev/null
>> +++ b/drivers/clocksource/timer-riscv.c
>> @@ -0,0 +1,118 @@
>> +/*
>> + * Copyright (C) 2012 Regents of the University of California
>> + * Copyright (C) 2017 SiFive
>> + *
>> + *   This program is free software; you can redistribute it and/or
>> + *   modify it under the terms of the GNU General Public License
>> + *   as published by the Free Software Foundation, version 2.
>> + *
>> + *   This program is distributed in the hope that it will be useful,
>> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *   GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +unsigned long riscv_timebase;
>> +
>> +static DEFINE_PER_CPU(struct clock_event_device, clock_event);
>> +
>> +static int riscv_timer_set_next_event(unsigned long delta,
>> +struct clock_event_device *evdev)
>> +{
>> +sbi_set_timer(get_cycles() + delta);
>> +return 0;
>> +}
>> +
>> +static int riscv_timer_set_oneshot(struct clock_event_device *evt)
>> +{
>> +/* no-op; only one mode */
>> +return 0;
>> +}
>> +
>> +static int riscv_timer_set_shutdown(struct clock_event_device *evt)
>> +{
>> +/* can't stop the clock! */
>> +return 0;
>> +}
>> +
>> +static u64 riscv_rdtime(struct clocksource *cs)
>> +{
>> +return get_cycles();
>> +}
>> +
>> +static struct clocksource riscv_clocksource = {
>> +.name = "riscv_clocksource",
>> +.rating = 300,
>> +.read = riscv_rdtime,
>> +#ifdef CONFIG_64BITS
>> +.mask = CLOCKSOURCE_MASK(64),
>> +#else
>> +.mask = CLOCKSOURCE_MASK(32),
>> +#endif /* CONFIG_64BITS */
>> +.flags = CLOCK_SOURCE_IS_CONTINUOUS,
>> +};
>> +
>> +void riscv_timer_interrupt(void)
>> +{
>> +int cpu = smp_processor_id();
>> +struct clock_event_device *evdev = _cpu(clock_event, cpu);
>> +
>> +evdev->event_handler(evdev);
>> +}
>> +
>> +void __init init_clockevent(void)
>> +{
>> +int cpu = smp_processor_id();
>> +struct clock_event_device *ce = _cpu(clock_event, cpu);
>> +
>> +*ce = (struct clock_event_device){
>> +.name = "riscv_timer_clockevent",
>> +.features = CLOCK_EVT_FEAT_ONESHOT,
>> +.rating = 300,
>> +.cpumask = cpumask_of(cpu),
>> +.set_next_event = riscv_timer_set_next_event,
>> +.set_state_oneshot  = riscv_timer_set_oneshot,
>> +.set_state_shutdown = riscv_timer_set_shutdown,
>> +};
>> +
>> +/* Enable timer interrupts */
>> +csr_set(sie, SIE_STIE);
>> +
>> +clockevents_config_and_register(ce, riscv_timebase, 100, 0x7fff);
>> +}
>> +
>> +static unsigned long __init of_timebase(void)
>> +{
>> +struct device_node *cpu;
>> +const __be32 *prop;
>> +
>> +cpu = of_find_node_by_path("/cpus");
>> +if (cpu) {
>> +prop = of_get_property(cpu, "timebase-frequency", NULL);
>> +if (prop)
>> +return be32_to_cpu(*prop);
>
> Consider using 

Re: [PATCH 13/17] RISC-V: Add include subdirectory

[Palmer Dabbelt]

On Wed, 07 Jun 2017 01:12:00 PDT (-0700), Arnd Bergmann wrote:
> On Wed, Jun 7, 2017 at 1:00 AM, Palmer Dabbelt  wrote:
>> This patch adds the include files for the RISC-V port.  These are mostly
>> based on the score port, but there are a lot of arm64-based files as
>> well.
>>
>> Signed-off-by: Palmer Dabbelt 
>
> It might be better to split this up into several parts, as the patch
> is longer than
> most people are willing to review at once.
>
> The uapi should definitely be a separate patch, as it includes the parts that
> cannot be changed any more later. memory management (pgtable, mmu,
> uaccess) would be another part to split out, and possibly all the atomics
> in one separate patch (along with spinlocks and bitops).

OK, we'll do this for the v3.

>
>> +
>> +/* IO barriers.  These only fence on the IO bits because they're only 
>> required
>> + * to order device access.  We're defining mmiowb because our AMO 
>> instructions
>> + * (which are used to implement locks) don't specify ordering.  From 
>> Chapter 7
>> + * of v2.2 of the user ISA:
>> + * "The bits order accesses to one of the two address domains, memory or 
>> I/O,
>> + * depending on which address domain the atomic instruction is accessing. No
>> + * ordering constraint is implied to accesses to the other domain, and a 
>> FENCE
>> + * instruction should be used to order across both domains."
>> + */
>> +
>> +#define __iormb()  __asm__ __volatile__ ("fence i,io" : : : "memory");
>> +#define __iowmb()  __asm__ __volatile__ ("fence io,o" : : : "memory");
>> +
>> +#define mmiowb()   __asm__ __volatile__ ("fence io,io" : : : "memory");
>> +
>> +/*
>> + * Relaxed I/O memory access primitives. These follow the Device memory
>> + * ordering rules but do not guarantee any ordering relative to Normal 
>> memory
>> + * accesses.
>> + */
>> +#define readb_relaxed(c)   ({ u8  __r = __raw_readb(c); __r; })
>> +#define readw_relaxed(c)   ({ u16 __r = le16_to_cpu((__force 
>> __le16)__raw_readw(c)); __r; })
>> +#define readl_relaxed(c)   ({ u32 __r = le32_to_cpu((__force 
>> __le32)__raw_readl(c)); __r; })
>> +#define readq_relaxed(c)   ({ u64 __r = le64_to_cpu((__force 
>> __le64)__raw_readq(c)); __r; })
>> +
>> +#define writeb_relaxed(v,c)((void)__raw_writeb((v),(c)))
>> +#define writew_relaxed(v,c)((void)__raw_writew((__force 
>> u16)cpu_to_le16(v),(c)))
>> +#define writel_relaxed(v,c)((void)__raw_writel((__force 
>> u32)cpu_to_le32(v),(c)))
>> +#define writeq_relaxed(v,c)((void)__raw_writeq((__force 
>> u64)cpu_to_le64(v),(c)))
>> +
>> +/*
>> + * I/O memory access primitives. Reads are ordered relative to any
>> + * following Normal memory access. Writes are ordered relative to any prior
>> + * Normal memory access.
>> + */
>> +#define readb(c)   ({ u8  __v = readb_relaxed(c); __iormb(); 
>> __v; })
>> +#define readw(c)   ({ u16 __v = readw_relaxed(c); __iormb(); 
>> __v; })
>> +#define readl(c)   ({ u32 __v = readl_relaxed(c); __iormb(); 
>> __v; })
>> +#define readq(c)   ({ u64 __v = readq_relaxed(c); __iormb(); 
>> __v; })
>> +
>> +#define writeb(v,c)({ __iowmb(); writeb_relaxed((v),(c)); })
>> +#define writew(v,c)({ __iowmb(); writew_relaxed((v),(c)); })
>> +#define writel(v,c)({ __iowmb(); writel_relaxed((v),(c)); })
>> +#define writeq(v,c)({ __iowmb(); writeq_relaxed((v),(c)); })
>> +
>> +#include 
>
> These do not yet contain all the changes we discussed: the relaxed operations
> don't seem to be ordered against one another and the regular accessors
> are not ordered against DMA.

Sorry, I must have forgotten to write this -- I just wanted to push out a v3
patch set without the changes to the atomics so everything else could be looked
at.  I wanted to just go through the atomics completely and fix them, as I
found a handful of problems (everything was missing the AQ and RL bits, for
example) and figured it would be best to just get them done right.

I think that's not something for after dinner on a Friday, but hopefully I'll
get to it tomorrow morning.

Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource

[Palmer Dabbelt]

On Wed, 07 Jun 2017 02:43:09 PDT (-0700), marc.zyng...@arm.com wrote:
> On 06/06/17 23:59, Palmer Dabbelt wrote:
>> The RISC-V ISA defines a single RTC as well as an SBI oneshot timer.
>> This timer is present on all RISC-V systems.
>>
>> Signed-off-by: Palmer Dabbelt 
>> ---
>>  drivers/clocksource/Kconfig   |   8 +++
>>  drivers/clocksource/Makefile  |   1 +
>>  drivers/clocksource/timer-riscv.c | 118 
>> ++
>>  3 files changed, 127 insertions(+)
>>  create mode 100644 drivers/clocksource/timer-riscv.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 545d541ae20e..1c2c6e7c7fab 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -612,4 +612,12 @@ config CLKSRC_ST_LPC
>>Enable this option to use the Low Power controller timer
>>as clocksource.
>>
>> +config CLKSRC_RISCV
>> +#bool "Clocksource for the RISC-V platform"
>> +def_bool y if RISCV
>> +depends on RISCV
>> +help
>> +  This enables a clocksource based on the RISC-V SBI timer, which is
>> +  built in to all RISC-V systems.
>> +
>>  endmenu
>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>> index 2b5b56a6f00f..408ed9d314dc 100644
>> --- a/drivers/clocksource/Makefile
>> +++ b/drivers/clocksource/Makefile
>> @@ -73,3 +73,4 @@ obj-$(CONFIG_H8300_TMR16)  += h8300_timer16.o
>>  obj-$(CONFIG_H8300_TPU) += h8300_tpu.o
>>  obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
>>  obj-$(CONFIG_X86_NUMACHIP)  += numachip.o
>> +obj-$(CONFIG_CLKSRC_RISCV)  += timer-riscv.o
>> diff --git a/drivers/clocksource/timer-riscv.c 
>> b/drivers/clocksource/timer-riscv.c
>> new file mode 100644
>> index ..04ef7b9130b3
>> --- /dev/null
>> +++ b/drivers/clocksource/timer-riscv.c
>> @@ -0,0 +1,118 @@
>> +/*
>> + * Copyright (C) 2012 Regents of the University of California
>> + * Copyright (C) 2017 SiFive
>> + *
>> + *   This program is free software; you can redistribute it and/or
>> + *   modify it under the terms of the GNU General Public License
>> + *   as published by the Free Software Foundation, version 2.
>> + *
>> + *   This program is distributed in the hope that it will be useful,
>> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *   GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +unsigned long riscv_timebase;
>> +
>> +static DEFINE_PER_CPU(struct clock_event_device, clock_event);
>> +
>> +static int riscv_timer_set_next_event(unsigned long delta,
>> +struct clock_event_device *evdev)
>> +{
>> +sbi_set_timer(get_cycles() + delta);
>> +return 0;
>> +}
>> +
>> +static int riscv_timer_set_oneshot(struct clock_event_device *evt)
>> +{
>> +/* no-op; only one mode */
>> +return 0;
>> +}
>> +
>> +static int riscv_timer_set_shutdown(struct clock_event_device *evt)
>> +{
>> +/* can't stop the clock! */
>> +return 0;
>> +}
>> +
>> +static u64 riscv_rdtime(struct clocksource *cs)
>> +{
>> +return get_cycles();
>> +}
>> +
>> +static struct clocksource riscv_clocksource = {
>> +.name = "riscv_clocksource",
>> +.rating = 300,
>> +.read = riscv_rdtime,
>> +#ifdef CONFIG_64BITS
>> +.mask = CLOCKSOURCE_MASK(64),
>> +#else
>> +.mask = CLOCKSOURCE_MASK(32),
>> +#endif /* CONFIG_64BITS */
>> +.flags = CLOCK_SOURCE_IS_CONTINUOUS,
>> +};
>> +
>> +void riscv_timer_interrupt(void)
>> +{
>> +int cpu = smp_processor_id();
>> +struct clock_event_device *evdev = _cpu(clock_event, cpu);
>> +
>> +evdev->event_handler(evdev);
>> +}
>> +
>> +void __init init_clockevent(void)
>> +{
>> +int cpu = smp_processor_id();
>> +struct clock_event_device *ce = _cpu(clock_event, cpu);
>> +
>> +*ce = (struct clock_event_device){
>> +.name = "riscv_timer_clockevent",
>> +.features = CLOCK_EVT_FEAT_ONESHOT,
>> +.rating = 300,
>> +.cpumask = cpumask_of(cpu),
>> +.set_next_event = riscv_timer_set_next_event,
>> +.set_state_oneshot  = riscv_timer_set_oneshot,
>> +.set_state_shutdown = riscv_timer_set_shutdown,
>> +};
>> +
>> +/* Enable timer interrupts */
>> +csr_set(sie, SIE_STIE);
>> +
>> +clockevents_config_and_register(ce, riscv_timebase, 100, 0x7fff);
>> +}
>> +
>> +static unsigned long __init of_timebase(void)
>> +{
>> +struct device_node *cpu;
>> +const __be32 *prop;
>> +
>> +cpu = of_find_node_by_path("/cpus");
>> +if (cpu) {
>> +prop = of_get_property(cpu, "timebase-frequency", NULL);
>> +if (prop)
>> +return be32_to_cpu(*prop);
>
> Consider using of_property_read_u32() 

[PATCH 2/3] pci: Add a generic, weakly-linked pcibios_align_resource

[Palmer Dabbelt]

Multiple architectures define this as trivial function, and I'm adding
another one as part of the RISC-V port.  This adds a __weak version of
pcibios_align_resource and deletes the now obselete ones in a handful of
ports.

The only functional change should be that a handful of ports used to
export pcibios_fixup_bus.  Only some architectures export this, so I
just dropped it.

Signed-off-by: Palmer Dabbelt 
---
 arch/arc/kernel/pcibios.c|  9 -
 arch/arm64/kernel/pci.c  |  9 -
 arch/ia64/pci/pci.c  |  7 ---
 arch/microblaze/pci/pci-common.c |  7 ---
 arch/sparc/kernel/leon_pci.c |  6 --
 arch/sparc/kernel/pci.c  |  6 --
 arch/sparc/kernel/pcic.c |  6 --
 arch/tile/kernel/pci.c   | 10 --
 arch/tile/kernel/pci_gx.c|  9 -
 drivers/pci/setup-res.c  | 12 
 10 files changed, 12 insertions(+), 69 deletions(-)

diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
index 1c8df8fd5fed..05aba5a7b5d2 100644
--- a/arch/arc/kernel/pcibios.c
+++ b/arch/arc/kernel/pcibios.c
@@ -7,12 +7,3 @@
  */
 
 #include 
-
-/*
- * We don't have to worry about legacy ISA devices, so nothing to do here
- */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 4c7f451aca05..9753ca23cfa1 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -23,15 +23,6 @@
 #include 
 
 /*
- * We don't have to worry about legacy ISA devices, so nothing to do here
- */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
-/*
  * Try to assign the IRQ number when probing a new device
  */
 int pcibios_alloc_irq(struct pci_dev *dev)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 4068bde623dc..f5ec736100ee 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -411,13 +411,6 @@ pcibios_disable_device (struct pci_dev *dev)
acpi_pci_irq_disable(dev);
 }
 
-resource_size_t
-pcibios_align_resource (void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 /**
  * ia64_pci_get_legacy_mem - generic legacy mem routine
  * @bus: bus to get legacy memory base address for
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 940f266e5d5c..5835c09c6e26 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -823,13 +823,6 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
  * but we want to try to avoid allocating at 0x2900-0x2bff
  * which might have be mirrored at 0x0100-0x03ff..
  */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-EXPORT_SYMBOL(pcibios_align_resource);
-
 int pcibios_add_device(struct pci_dev *dev)
 {
dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
diff --git a/arch/sparc/kernel/leon_pci.c b/arch/sparc/kernel/leon_pci.c
index 4371f72ff025..0eafdf3d036d 100644
--- a/arch/sparc/kernel/leon_pci.c
+++ b/arch/sparc/kernel/leon_pci.c
@@ -94,9 +94,3 @@ void pcibios_fixup_bus(struct pci_bus *pbus)
}
}
 }
-
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 78d3dc25e126..3f8670c92951 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -690,12 +690,6 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
return bus;
 }
 
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
u16 cmd, oldcmd;
diff --git a/arch/sparc/kernel/pcic.c b/arch/sparc/kernel/pcic.c
index a38787b84322..e038e343f2c1 100644
--- a/arch/sparc/kernel/pcic.c
+++ b/arch/sparc/kernel/pcic.c
@@ -746,12 +746,6 @@ static void watchdog_reset() {
 }
 #endif
 
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 int pcibios_enable_device(struct pci_dev *pdev, int mask)
 {
return 0;
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index 3113d4d5c329..8999a20ed9d1 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c

[PATCH 2/3] pci: Add a generic, weakly-linked pcibios_align_resource

[Palmer Dabbelt]

Multiple architectures define this as trivial function, and I'm adding
another one as part of the RISC-V port.  This adds a __weak version of
pcibios_align_resource and deletes the now obselete ones in a handful of
ports.

The only functional change should be that a handful of ports used to
export pcibios_fixup_bus.  Only some architectures export this, so I
just dropped it.

Signed-off-by: Palmer Dabbelt 
---
 arch/arc/kernel/pcibios.c|  9 -
 arch/arm64/kernel/pci.c  |  9 -
 arch/ia64/pci/pci.c  |  7 ---
 arch/microblaze/pci/pci-common.c |  7 ---
 arch/sparc/kernel/leon_pci.c |  6 --
 arch/sparc/kernel/pci.c  |  6 --
 arch/sparc/kernel/pcic.c |  6 --
 arch/tile/kernel/pci.c   | 10 --
 arch/tile/kernel/pci_gx.c|  9 -
 drivers/pci/setup-res.c  | 12 
 10 files changed, 12 insertions(+), 69 deletions(-)

diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
index 1c8df8fd5fed..05aba5a7b5d2 100644
--- a/arch/arc/kernel/pcibios.c
+++ b/arch/arc/kernel/pcibios.c
@@ -7,12 +7,3 @@
  */
 
 #include 
-
-/*
- * We don't have to worry about legacy ISA devices, so nothing to do here
- */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 4c7f451aca05..9753ca23cfa1 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -23,15 +23,6 @@
 #include 
 
 /*
- * We don't have to worry about legacy ISA devices, so nothing to do here
- */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
-/*
  * Try to assign the IRQ number when probing a new device
  */
 int pcibios_alloc_irq(struct pci_dev *dev)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 4068bde623dc..f5ec736100ee 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -411,13 +411,6 @@ pcibios_disable_device (struct pci_dev *dev)
acpi_pci_irq_disable(dev);
 }
 
-resource_size_t
-pcibios_align_resource (void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 /**
  * ia64_pci_get_legacy_mem - generic legacy mem routine
  * @bus: bus to get legacy memory base address for
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 940f266e5d5c..5835c09c6e26 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -823,13 +823,6 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
  * but we want to try to avoid allocating at 0x2900-0x2bff
  * which might have be mirrored at 0x0100-0x03ff..
  */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-EXPORT_SYMBOL(pcibios_align_resource);
-
 int pcibios_add_device(struct pci_dev *dev)
 {
dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
diff --git a/arch/sparc/kernel/leon_pci.c b/arch/sparc/kernel/leon_pci.c
index 4371f72ff025..0eafdf3d036d 100644
--- a/arch/sparc/kernel/leon_pci.c
+++ b/arch/sparc/kernel/leon_pci.c
@@ -94,9 +94,3 @@ void pcibios_fixup_bus(struct pci_bus *pbus)
}
}
 }
-
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 78d3dc25e126..3f8670c92951 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -690,12 +690,6 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
return bus;
 }
 
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
u16 cmd, oldcmd;
diff --git a/arch/sparc/kernel/pcic.c b/arch/sparc/kernel/pcic.c
index a38787b84322..e038e343f2c1 100644
--- a/arch/sparc/kernel/pcic.c
+++ b/arch/sparc/kernel/pcic.c
@@ -746,12 +746,6 @@ static void watchdog_reset() {
 }
 #endif
 
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 int pcibios_enable_device(struct pci_dev *pdev, int mask)
 {
return 0;
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index 3113d4d5c329..8999a20ed9d1 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c
@@ -67,16 +67,6 @@ 

Re: [PATCH v4] trace: ras: add ARM processor error information trace event

[Xie XiuQi]

Hi Steve,

Thanks for your comments.

On 2017/6/23 21:42, Steven Rostedt wrote:
> On Fri, 23 Jun 2017 19:13:43 +0800
> Xie XiuQi  wrote:
> 
>> Add a new trace event for ARM processor error information, so that
>> the user will know what error occurred. With this information the
>> user may take appropriate action.
>>
>> These trace events are consistent with the ARM processor error
>> information table which defined in UEFI 2.6 spec section N.2.4.4.1.
>>
>> ---
>> v4: use __print_flags instead of __print_symbolic, because ARM_PROC_ERR_FLAGS
>> might have more than on bit set.
>> setting up default values for __entry to avoid a lot of else branches.
>> set flags to 0 by default instead of ~0.
>> fix a typo
>> rename arm_proc_err to arm_proc_err_event
>> remove "ARM Processor Error: " prefix
>> rebase on Tyler's patchset v17 "Add UEFI 2.6 and ACPI 6.1 updates for 
>> RAS on ARM64"
>>
>> v3: no change
>>
>> v2: add trace enabled condition as Steven's suggestion.
> 
> Where's the trace enabled now?

Sorry, I rebased on new version and lost the trace enabled condition,
and I'll add it back again.

Thanks,
XiuQi

> 
>> fix a typo.
>>
>> https://patchwork.kernel.org/patch/9653767/
>> ---
>>
>> Cc: Steven Rostedt 
>> Cc: Tyler Baicar 
>> Signed-off-by: Xie XiuQi 
>> ---
>>  drivers/ras/ras.c   |  8 +
>>  include/linux/cper.h|  5 
>>  include/ras/ras_event.h | 79 
>> +
>>  3 files changed, 92 insertions(+)
>>
>> diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
>> index 39701a5..785e25d 100644
>> --- a/drivers/ras/ras.c
>> +++ b/drivers/ras/ras.c
>> @@ -22,7 +22,14 @@ void log_non_standard_event(const uuid_le *sec_type, 
>> const uuid_le *fru_id,
>>  
>>  void log_arm_hw_error(struct cper_sec_proc_arm *err)
>>  {
>> +int i;
>> +struct cper_arm_err_info *err_info;
>> +
>>  trace_arm_event(err);
> 
>   if (!trace_arm_err_info_event_enabled())
>   return;
> 
> ?
> 
>> +
>> +err_info = (struct cper_arm_err_info *)(err + 1);
>> +for (i = 0; i < err->err_info_num; i++, err_info++)
>> +trace_arm_err_info_event(err_info);
>>  }
>>  
>>  static int __init ras_init(void)
>> @@ -42,6 +49,7 @@ static int __init ras_init(void)
>>  EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
>>  EXPORT_TRACEPOINT_SYMBOL_GPL(non_standard_event);
>>  EXPORT_TRACEPOINT_SYMBOL_GPL(arm_event);
>> +EXPORT_TRACEPOINT_SYMBOL_GPL(arm_err_info_event);
>>  
>>  int __init parse_ras_param(char *str)
>>  {
>> diff --git a/include/linux/cper.h b/include/linux/cper.h
>> index 4c671fc..17546bf 100644
>> --- a/include/linux/cper.h
>> +++ b/include/linux/cper.h
>> @@ -275,6 +275,11 @@ enum {
>>  #define CPER_ARM_INFO_FLAGS_PROPAGATED  BIT(2)
>>  #define CPER_ARM_INFO_FLAGS_OVERFLOWBIT(3)
>>  
>> +#define CPER_ARM_INFO_TYPE_CACHE0
>> +#define CPER_ARM_INFO_TYPE_TLB  1
>> +#define CPER_ARM_INFO_TYPE_BUS  2
>> +#define CPER_ARM_INFO_TYPE_UARCH3
>> +
>>  /*
>>   * All tables and structs must be byte-packed to match CPER
>>   * specification, since the tables are provided by the system BIOS
>> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
>> index 429f46f..c38a367 100644
>> --- a/include/ras/ras_event.h
>> +++ b/include/ras/ras_event.h
>> @@ -206,6 +206,85 @@
>>__entry->running_state, __entry->psci_state)
>>  );
>>  
>> +#define ARM_PROC_ERR_TYPE   \
>> +EM ( CPER_ARM_INFO_TYPE_CACHE, "cache error" )  \
>> +EM ( CPER_ARM_INFO_TYPE_TLB,  "TLB error" ) \
>> +EM ( CPER_ARM_INFO_TYPE_BUS, "bus error" )  \
>> +EMe ( CPER_ARM_INFO_TYPE_UARCH, "micro-architectural error" )
>> +
>> +/*
>> + * First define the enums in MM_ACTION_RESULT to be exported to userspace
>> + * via TRACE_DEFINE_ENUM().
>> + */
>> +#undef EM
>> +#undef EMe
>> +#define EM(a, b) TRACE_DEFINE_ENUM(a);
>> +#define EMe(a, b)   TRACE_DEFINE_ENUM(a);
>> +
>> +ARM_PROC_ERR_TYPE
>> +
>> +/*
>> + * Now redefine the EM() and EMe() macros to map the enums to the strings
>> + * that will be printed in the output.
>> + */
>> +#undef EM
>> +#undef EMe
>> +#define EM(a, b){ a, b },
>> +#define EMe(a, b)   { a, b }
>> +
>> +#define show_proc_err_flags(flags) __print_flags(flags, "|",
>> \
>> +{ CPER_ARM_INFO_FLAGS_FIRST,"First error captured" },   
>> \
>> +{ CPER_ARM_INFO_FLAGS_LAST, "Last error captured" },
>> \
>> +{ CPER_ARM_INFO_FLAGS_PROPAGATED,   "Propagated" }, 
>> \
>> +{ CPER_ARM_INFO_FLAGS_OVERFLOW, "Overflow" })
>> +
>> +TRACE_EVENT(arm_err_info_event,
>> +
>> +TP_PROTO(const struct cper_arm_err_info *err),
>> +
>> +TP_ARGS(err),
>> +
>> +TP_STRUCT__entry(
>> +__field(u8, type)
>> +

Re: [PATCH v4] trace: ras: add ARM processor error information trace event

[Xie XiuQi]

Hi Steve,

Thanks for your comments.

On 2017/6/23 21:42, Steven Rostedt wrote:
> On Fri, 23 Jun 2017 19:13:43 +0800
> Xie XiuQi  wrote:
> 
>> Add a new trace event for ARM processor error information, so that
>> the user will know what error occurred. With this information the
>> user may take appropriate action.
>>
>> These trace events are consistent with the ARM processor error
>> information table which defined in UEFI 2.6 spec section N.2.4.4.1.
>>
>> ---
>> v4: use __print_flags instead of __print_symbolic, because ARM_PROC_ERR_FLAGS
>> might have more than on bit set.
>> setting up default values for __entry to avoid a lot of else branches.
>> set flags to 0 by default instead of ~0.
>> fix a typo
>> rename arm_proc_err to arm_proc_err_event
>> remove "ARM Processor Error: " prefix
>> rebase on Tyler's patchset v17 "Add UEFI 2.6 and ACPI 6.1 updates for 
>> RAS on ARM64"
>>
>> v3: no change
>>
>> v2: add trace enabled condition as Steven's suggestion.
> 
> Where's the trace enabled now?

Sorry, I rebased on new version and lost the trace enabled condition,
and I'll add it back again.

Thanks,
XiuQi

> 
>> fix a typo.
>>
>> https://patchwork.kernel.org/patch/9653767/
>> ---
>>
>> Cc: Steven Rostedt 
>> Cc: Tyler Baicar 
>> Signed-off-by: Xie XiuQi 
>> ---
>>  drivers/ras/ras.c   |  8 +
>>  include/linux/cper.h|  5 
>>  include/ras/ras_event.h | 79 
>> +
>>  3 files changed, 92 insertions(+)
>>
>> diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
>> index 39701a5..785e25d 100644
>> --- a/drivers/ras/ras.c
>> +++ b/drivers/ras/ras.c
>> @@ -22,7 +22,14 @@ void log_non_standard_event(const uuid_le *sec_type, 
>> const uuid_le *fru_id,
>>  
>>  void log_arm_hw_error(struct cper_sec_proc_arm *err)
>>  {
>> +int i;
>> +struct cper_arm_err_info *err_info;
>> +
>>  trace_arm_event(err);
> 
>   if (!trace_arm_err_info_event_enabled())
>   return;
> 
> ?
> 
>> +
>> +err_info = (struct cper_arm_err_info *)(err + 1);
>> +for (i = 0; i < err->err_info_num; i++, err_info++)
>> +trace_arm_err_info_event(err_info);
>>  }
>>  
>>  static int __init ras_init(void)
>> @@ -42,6 +49,7 @@ static int __init ras_init(void)
>>  EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
>>  EXPORT_TRACEPOINT_SYMBOL_GPL(non_standard_event);
>>  EXPORT_TRACEPOINT_SYMBOL_GPL(arm_event);
>> +EXPORT_TRACEPOINT_SYMBOL_GPL(arm_err_info_event);
>>  
>>  int __init parse_ras_param(char *str)
>>  {
>> diff --git a/include/linux/cper.h b/include/linux/cper.h
>> index 4c671fc..17546bf 100644
>> --- a/include/linux/cper.h
>> +++ b/include/linux/cper.h
>> @@ -275,6 +275,11 @@ enum {
>>  #define CPER_ARM_INFO_FLAGS_PROPAGATED  BIT(2)
>>  #define CPER_ARM_INFO_FLAGS_OVERFLOWBIT(3)
>>  
>> +#define CPER_ARM_INFO_TYPE_CACHE0
>> +#define CPER_ARM_INFO_TYPE_TLB  1
>> +#define CPER_ARM_INFO_TYPE_BUS  2
>> +#define CPER_ARM_INFO_TYPE_UARCH3
>> +
>>  /*
>>   * All tables and structs must be byte-packed to match CPER
>>   * specification, since the tables are provided by the system BIOS
>> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
>> index 429f46f..c38a367 100644
>> --- a/include/ras/ras_event.h
>> +++ b/include/ras/ras_event.h
>> @@ -206,6 +206,85 @@
>>__entry->running_state, __entry->psci_state)
>>  );
>>  
>> +#define ARM_PROC_ERR_TYPE   \
>> +EM ( CPER_ARM_INFO_TYPE_CACHE, "cache error" )  \
>> +EM ( CPER_ARM_INFO_TYPE_TLB,  "TLB error" ) \
>> +EM ( CPER_ARM_INFO_TYPE_BUS, "bus error" )  \
>> +EMe ( CPER_ARM_INFO_TYPE_UARCH, "micro-architectural error" )
>> +
>> +/*
>> + * First define the enums in MM_ACTION_RESULT to be exported to userspace
>> + * via TRACE_DEFINE_ENUM().
>> + */
>> +#undef EM
>> +#undef EMe
>> +#define EM(a, b) TRACE_DEFINE_ENUM(a);
>> +#define EMe(a, b)   TRACE_DEFINE_ENUM(a);
>> +
>> +ARM_PROC_ERR_TYPE
>> +
>> +/*
>> + * Now redefine the EM() and EMe() macros to map the enums to the strings
>> + * that will be printed in the output.
>> + */
>> +#undef EM
>> +#undef EMe
>> +#define EM(a, b){ a, b },
>> +#define EMe(a, b)   { a, b }
>> +
>> +#define show_proc_err_flags(flags) __print_flags(flags, "|",
>> \
>> +{ CPER_ARM_INFO_FLAGS_FIRST,"First error captured" },   
>> \
>> +{ CPER_ARM_INFO_FLAGS_LAST, "Last error captured" },
>> \
>> +{ CPER_ARM_INFO_FLAGS_PROPAGATED,   "Propagated" }, 
>> \
>> +{ CPER_ARM_INFO_FLAGS_OVERFLOW, "Overflow" })
>> +
>> +TRACE_EVENT(arm_err_info_event,
>> +
>> +TP_PROTO(const struct cper_arm_err_info *err),
>> +
>> +TP_ARGS(err),
>> +
>> +TP_STRUCT__entry(
>> +__field(u8, type)
>> +__field(u16, multiple_error)
>> +__field(u8, flags)
> 
> Wouldn't you want flags 

[PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

[Shuah Khan]

Fix to call of_node_put() right after of_drm_find_bridge() instead of
holding on to it until exynos_dsi_remove().

Suggested-by: Inki Dae 
Signed-off-by: Shuah Khan 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e337cd2..7513b88 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1689,6 +1689,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
 
if (dsi->bridge_node) {
bridge = of_drm_find_bridge(dsi->bridge_node);
+   of_node_put(dsi->bridge_node);
if (bridge)
drm_bridge_attach(encoder, bridge, NULL);
}
@@ -1807,10 +1808,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 
 static int exynos_dsi_remove(struct platform_device *pdev)
 {
-   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
-
-   of_node_put(dsi->bridge_node);
-
pm_runtime_disable(>dev);
 
component_del(>dev, _dsi_component_ops);
-- 
2.7.4

[PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

[Shuah Khan]

Fix to call of_node_put() right after of_drm_find_bridge() instead of
holding on to it until exynos_dsi_remove().

Suggested-by: Inki Dae 
Signed-off-by: Shuah Khan 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e337cd2..7513b88 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1689,6 +1689,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
 
if (dsi->bridge_node) {
bridge = of_drm_find_bridge(dsi->bridge_node);
+   of_node_put(dsi->bridge_node);
if (bridge)
drm_bridge_attach(encoder, bridge, NULL);
}
@@ -1807,10 +1808,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 
 static int exynos_dsi_remove(struct platform_device *pdev)
 {
-   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
-
-   of_node_put(dsi->bridge_node);
-
pm_runtime_disable(>dev);
 
component_del(>dev, _dsi_component_ops);
-- 
2.7.4

Re: [PATCH v2] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Rafael J. Wysocki]

On Friday, June 23, 2017 03:37:36 PM mario.limoncie...@dell.com wrote:
> > -Original Message-

[cut]

> > Index: linux-pm/drivers/acpi/sleep.c
> > ===
> > --- linux-pm.orig/drivers/acpi/sleep.c
> > +++ linux-pm/drivers/acpi/sleep.c
> > @@ -650,18 +650,108 @@ static const struct platform_suspend_ops
> > .recover = acpi_pm_finish,
> >  };
> > 
> > +static bool s2idle_in_progress;
> >  static bool s2idle_wakeup;
> > 
> > +/*
> > + * On platforms supporting the Low Power S0 Idle interface there is an ACPI
> > + * device object with the PNP0D80 compatible device ID (System Power
> > Management
> > + * Controller) and a specific _DSM method under it.  That method, if 
> > present,
> > + * can be used to indicate to the platform that the OS is transitioning 
> > into a
> > + * low-power state in which certain types of activity are not desirable or 
> > that
> > + * it is leaving such a state, which allows the platform to adjust its 
> > operation
> > + * mode accordingly.
> > + */
> > +static const struct acpi_device_id lps0_device_ids[] = {
> > +   {"PNP0D80", },
> > +   {"", },
> > +};
> > +
> > +#define ACPI_LPS0_DSM_UUID "c4eb40a0-6cd2-11e2-bcfd-0800200c9a66"
> > +
> > +#define ACPI_LPS0_SCREEN_OFF   3
> > +#define ACPI_LPS0_SCREEN_ON4
> > +#define ACPI_LPS0_ENTRY5
> > +#define ACPI_LPS0_EXIT 6
> The spec you shared also defines device constraints (function 1). It would be 
> very 
> useful if these constraints  could be parsed and compared against the actual 
> power 
> states of devices on the system at least for debugging purposes.  I'm not 
> sure if you 
> already had a plan for that in a future series.

As Srinivas said, there is a plan to use it for debug purposes going forward.

> 
> > +
> > +#define ACPI_S2IDLE_FUNC_MASK  ((1 << ACPI_LPS0_ENTRY) | (1 <<
> > ACPI_LPS0_EXIT))
> > +
> > +static acpi_handle lps0_device_handle;
> > +static guid_t lps0_dsm_guid;
> > +static char lps0_dsm_func_mask;
> > +
> > +static void acpi_sleep_run_lps0_dsm(unsigned int func)
> > +{
> > +   union acpi_object *out_obj;
> > +
> > +   if (!(lps0_dsm_func_mask & (1 << func)))
> > +   return;
> > +
> > +   out_obj = acpi_evaluate_dsm(lps0_device_handle, _dsm_guid, 1,
> > func, NULL);
> > +   ACPI_FREE(out_obj);
> > +
> > +   acpi_handle_debug(lps0_device_handle, "_DSM function %u evaluation
> > %s\n",
> > + func, out_obj ? "successful" : "failed");
> > +}
> > +
> > +static int lps0_device_attach(struct acpi_device *adev,
> > + const struct acpi_device_id *not_used)
> > +{
> > +   union acpi_object *out_obj;
> > +
> > +   if (lps0_device_handle)
> > +   return 0;
> > +
> > +   if (!(acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0))
> > +   return 0;
> Although the spec you shared refers to PNP0D80/INT33A1 in the context 
> of LPIT, the PNP0D80 device is not "only" used for low power S0.  It's 
> available on systems that don't support modern standby too.
> 
> I for example see it on a system running Windows that does not support 
> modern standby such as the Precision 5510.
> 
> All of the ASL executed in PNP0D80 is guarded with a check 
> whether or not that low power idle supported bit has been set and whether
> or not running on an OSPM that exported a group of features indicating it 
> should support it to ensure its run in the right context.
> 
> Since Linux responds as the latest group of Windows features but doesn't 
> look at ACPI_FADT_LOW_POWER_S0 yet to determine whether to default to 
> suspend to idle i'm a little worried about developing more unexercised code 
> paths specific to Linux.
> 
> For example:
> System has ACPI_FADT_LOW_POWER_S0 set, but also supports S3
> (such as XPS 9360)
> * On Windows PNP0D80 should be used, all ASL code specific to 
> modern standby will be run.
> * On Linux (with current patch) if a user invokes S3, PNP0D80 doesn't get used
> [Win7 should still be using this PNP0D80 codepath, not used by Linux]

Well, this is the situation already without this patch. :-)

> 
> * On Linux (if PNP0D80 was supported on all systems but) a user invoked
> S3, PNP0D80 functions would be run.
> [This should be an undefined behavior since the ASL would run the modern
> standby related code but then go into S3]
> 
> 
> And yes I realize have argued both for and against exporting PNP0D80 to more 
> systems above.  
> 
> I think the proper way to align to Windows behavior is recognize PNP0D80 on
> all systems and also look at ACPI_FADT_LOW_POWER_S0 at the same time to
> align using S2I instead of S3 by default.
> 
> Perhaps this is best placed in a follow up patch that can be easily reverted 
> without 
> messing up the wonderful work you've done so far in case my idea ends up 
> causing 
> other regressions that are not yet envisioned.

As you correctly pointed out above, the published documentation refers to the
PNP0D80 _DSM 

Re: [PATCH v2] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Rafael J. Wysocki]

On Friday, June 23, 2017 03:37:36 PM mario.limoncie...@dell.com wrote:
> > -Original Message-

[cut]

> > Index: linux-pm/drivers/acpi/sleep.c
> > ===
> > --- linux-pm.orig/drivers/acpi/sleep.c
> > +++ linux-pm/drivers/acpi/sleep.c
> > @@ -650,18 +650,108 @@ static const struct platform_suspend_ops
> > .recover = acpi_pm_finish,
> >  };
> > 
> > +static bool s2idle_in_progress;
> >  static bool s2idle_wakeup;
> > 
> > +/*
> > + * On platforms supporting the Low Power S0 Idle interface there is an ACPI
> > + * device object with the PNP0D80 compatible device ID (System Power
> > Management
> > + * Controller) and a specific _DSM method under it.  That method, if 
> > present,
> > + * can be used to indicate to the platform that the OS is transitioning 
> > into a
> > + * low-power state in which certain types of activity are not desirable or 
> > that
> > + * it is leaving such a state, which allows the platform to adjust its 
> > operation
> > + * mode accordingly.
> > + */
> > +static const struct acpi_device_id lps0_device_ids[] = {
> > +   {"PNP0D80", },
> > +   {"", },
> > +};
> > +
> > +#define ACPI_LPS0_DSM_UUID "c4eb40a0-6cd2-11e2-bcfd-0800200c9a66"
> > +
> > +#define ACPI_LPS0_SCREEN_OFF   3
> > +#define ACPI_LPS0_SCREEN_ON4
> > +#define ACPI_LPS0_ENTRY5
> > +#define ACPI_LPS0_EXIT 6
> The spec you shared also defines device constraints (function 1). It would be 
> very 
> useful if these constraints  could be parsed and compared against the actual 
> power 
> states of devices on the system at least for debugging purposes.  I'm not 
> sure if you 
> already had a plan for that in a future series.

As Srinivas said, there is a plan to use it for debug purposes going forward.

> 
> > +
> > +#define ACPI_S2IDLE_FUNC_MASK  ((1 << ACPI_LPS0_ENTRY) | (1 <<
> > ACPI_LPS0_EXIT))
> > +
> > +static acpi_handle lps0_device_handle;
> > +static guid_t lps0_dsm_guid;
> > +static char lps0_dsm_func_mask;
> > +
> > +static void acpi_sleep_run_lps0_dsm(unsigned int func)
> > +{
> > +   union acpi_object *out_obj;
> > +
> > +   if (!(lps0_dsm_func_mask & (1 << func)))
> > +   return;
> > +
> > +   out_obj = acpi_evaluate_dsm(lps0_device_handle, _dsm_guid, 1,
> > func, NULL);
> > +   ACPI_FREE(out_obj);
> > +
> > +   acpi_handle_debug(lps0_device_handle, "_DSM function %u evaluation
> > %s\n",
> > + func, out_obj ? "successful" : "failed");
> > +}
> > +
> > +static int lps0_device_attach(struct acpi_device *adev,
> > + const struct acpi_device_id *not_used)
> > +{
> > +   union acpi_object *out_obj;
> > +
> > +   if (lps0_device_handle)
> > +   return 0;
> > +
> > +   if (!(acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0))
> > +   return 0;
> Although the spec you shared refers to PNP0D80/INT33A1 in the context 
> of LPIT, the PNP0D80 device is not "only" used for low power S0.  It's 
> available on systems that don't support modern standby too.
> 
> I for example see it on a system running Windows that does not support 
> modern standby such as the Precision 5510.
> 
> All of the ASL executed in PNP0D80 is guarded with a check 
> whether or not that low power idle supported bit has been set and whether
> or not running on an OSPM that exported a group of features indicating it 
> should support it to ensure its run in the right context.
> 
> Since Linux responds as the latest group of Windows features but doesn't 
> look at ACPI_FADT_LOW_POWER_S0 yet to determine whether to default to 
> suspend to idle i'm a little worried about developing more unexercised code 
> paths specific to Linux.
> 
> For example:
> System has ACPI_FADT_LOW_POWER_S0 set, but also supports S3
> (such as XPS 9360)
> * On Windows PNP0D80 should be used, all ASL code specific to 
> modern standby will be run.
> * On Linux (with current patch) if a user invokes S3, PNP0D80 doesn't get used
> [Win7 should still be using this PNP0D80 codepath, not used by Linux]

Well, this is the situation already without this patch. :-)

> 
> * On Linux (if PNP0D80 was supported on all systems but) a user invoked
> S3, PNP0D80 functions would be run.
> [This should be an undefined behavior since the ASL would run the modern
> standby related code but then go into S3]
> 
> 
> And yes I realize have argued both for and against exporting PNP0D80 to more 
> systems above.  
> 
> I think the proper way to align to Windows behavior is recognize PNP0D80 on
> all systems and also look at ACPI_FADT_LOW_POWER_S0 at the same time to
> align using S2I instead of S3 by default.
> 
> Perhaps this is best placed in a follow up patch that can be easily reverted 
> without 
> messing up the wonderful work you've done so far in case my idea ends up 
> causing 
> other regressions that are not yet envisioned.

As you correctly pointed out above, the published documentation refers to the
PNP0D80 _DSM 

Re: [PATCH v9 1/5] firmware: add extensible driver data params

[Luis R. Rodriguez]

On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote:
> On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez  wrote:
> >
> > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch
> > series and I'm happy we have finally landed on it. Yes, indeed the new API
> > proposed here provides more flexibility, and it does so by embracing a
> > "data driven" API Vs the traditional procedural APIs we have seen for
> > *the firmware API*.
> 
> This has been going on forever. Everybody hates your data-driven one.

Before you, the only person who had expressed disdain here was Greg.

> It's too indirect, it adds all those nasty "descriptors" of what to
> do, and it doesn't match what the current model does at all.

This is good feedback, I do accept deciding where to draw the line is hard.
I decided to go with blocking/non-blocking as the fine line.

> Things like that may be ok as an internal implementation, but even
> there it's questionable if it then means a big disconnect between what
> people actually use (the normal functional model) and the
> implementation.

A vendor tree implemented their *own* solution and were willing to maintain
it despite this likely making it hard to port stable fixes. That I think says
a lot for a need...

> The thing is, it's much better to just have functions that load the
> firmware data. Have them named that way ("load_firmware()"), and act
> that way ("just load the damn firmware file") instead of having odd
> descriptors that describe what is goign to be done and some state for
> it, and then get passed around.
> 
> Don't add this kind of crazy abstraction complexity.
> 
> If somebody wants to veryify a signature on a firmware file, they
> should *NOT* fill in a descriptor that says "check signature when
> loading". Thats' complete BS.
> 
> They should just do "load_firmware()" and then "check_signature()" or 
> whatever.

That's a fair suggestion for firmware signing! And I'll let AKASHI comment on
whether or not that would suffice for his requirements given he's now
addressing firmware signing.

There are still other requirements and features in the pipeline for which we
can consider parameters to parse for, rather than adding new API. Case in
point, do we want *one* API just to disable the firmware cache? Specially
knowing that another feature in the pipeline later would make use of this as a
requirement?

Or let us just consider the very simple *optional* async firmware. Do we add
*one* full new API call just for that?

  Luis

Re: [PATCH v9 1/5] firmware: add extensible driver data params

[Luis R. Rodriguez]

On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote:
> On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez  wrote:
> >
> > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch
> > series and I'm happy we have finally landed on it. Yes, indeed the new API
> > proposed here provides more flexibility, and it does so by embracing a
> > "data driven" API Vs the traditional procedural APIs we have seen for
> > *the firmware API*.
> 
> This has been going on forever. Everybody hates your data-driven one.

Before you, the only person who had expressed disdain here was Greg.

> It's too indirect, it adds all those nasty "descriptors" of what to
> do, and it doesn't match what the current model does at all.

This is good feedback, I do accept deciding where to draw the line is hard.
I decided to go with blocking/non-blocking as the fine line.

> Things like that may be ok as an internal implementation, but even
> there it's questionable if it then means a big disconnect between what
> people actually use (the normal functional model) and the
> implementation.

A vendor tree implemented their *own* solution and were willing to maintain
it despite this likely making it hard to port stable fixes. That I think says
a lot for a need...

> The thing is, it's much better to just have functions that load the
> firmware data. Have them named that way ("load_firmware()"), and act
> that way ("just load the damn firmware file") instead of having odd
> descriptors that describe what is goign to be done and some state for
> it, and then get passed around.
> 
> Don't add this kind of crazy abstraction complexity.
> 
> If somebody wants to veryify a signature on a firmware file, they
> should *NOT* fill in a descriptor that says "check signature when
> loading". Thats' complete BS.
> 
> They should just do "load_firmware()" and then "check_signature()" or 
> whatever.

That's a fair suggestion for firmware signing! And I'll let AKASHI comment on
whether or not that would suffice for his requirements given he's now
addressing firmware signing.

There are still other requirements and features in the pipeline for which we
can consider parameters to parse for, rather than adding new API. Case in
point, do we want *one* API just to disable the firmware cache? Specially
knowing that another feature in the pipeline later would make use of this as a
requirement?

Or let us just consider the very simple *optional* async firmware. Do we add
*one* full new API call just for that?

  Luis

Re: [PATCH v2 12/29] kselftest.rst: do some adjustments after ReST conversion

[Shuah Khan]

On 06/23/2017 03:32 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 23 Jun 2017 08:04:02 -0600
> Shuah Khan  escreveu:
> 
>> Hi Mauro,
>>
>> On 06/17/2017 09:26 AM, Mauro Carvalho Chehab wrote:
>>> Do some minor adjustments after ReST conversion:
>>>
>>> - On most documents, we use prepend a "$ " before
>>>   command line arguments;
>>>
>>> - Prefer to use :: on the preceding line;
>>>
>>> - Split a multi-paragraph description as such.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab   
>>
>> Looks good to me. I can take this through linux-kselftest or here is
>> my Ack for it to go through the doc tree with the rest in this series.
>>
>> Acked-by: Shuah Khan 
> 
> Shuah,
> 
> Either way works for me. Whatever makes easier for you and Jon.
> 
> Regards,
> Mauro
> 
> 

Hi Jon,

Please let me know if you want me to take this through linux-kselftest
In which case, Ack the patch. If not, you already have my Ack.

thanks,
-- Shuah

Re: [PATCH v2 12/29] kselftest.rst: do some adjustments after ReST conversion

[Shuah Khan]

On 06/23/2017 03:32 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 23 Jun 2017 08:04:02 -0600
> Shuah Khan  escreveu:
> 
>> Hi Mauro,
>>
>> On 06/17/2017 09:26 AM, Mauro Carvalho Chehab wrote:
>>> Do some minor adjustments after ReST conversion:
>>>
>>> - On most documents, we use prepend a "$ " before
>>>   command line arguments;
>>>
>>> - Prefer to use :: on the preceding line;
>>>
>>> - Split a multi-paragraph description as such.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab   
>>
>> Looks good to me. I can take this through linux-kselftest or here is
>> my Ack for it to go through the doc tree with the rest in this series.
>>
>> Acked-by: Shuah Khan 
> 
> Shuah,
> 
> Either way works for me. Whatever makes easier for you and Jon.
> 
> Regards,
> Mauro
> 
> 

Hi Jon,

Please let me know if you want me to take this through linux-kselftest
In which case, Ack the patch. If not, you already have my Ack.

thanks,
-- Shuah

Re: [PATCH 10/17] irqchip: New RISC-V PLIC Driver

[Palmer Dabbelt]

On Wed, 07 Jun 2017 00:55:28 PDT (-0700), Arnd Bergmann wrote:
> On Wed, Jun 7, 2017 at 9:13 AM, Geert Uytterhoeven  
> wrote:
>>> +struct plic_enable_context {
>>> +   atomic_t mask[32]; // 32-bit * 32-entry
>>> +};
>
> You use many '//' style comments in this file, please change them all to '/* 
> */'
> for consistency with kernel coding style.

OK, I fixed them here and in all our other files that had them.

>>> +
>>> +struct plic_priority {
>>> +   u32 prio[MAX_DEVICES];
>>> +};
>>> +
>>> +struct plic_data {
>>> +   struct irq_chip chip;
>>> +   struct irq_domain   *domain;
>>> +   u32 ndev;
>>> +   void __iomem*reg;
>>> +   int handlers;
>>> +   struct plic_handler *handler;
>>> +   charname[30];
>>> +};
>>> +
>>> +struct plic_handler {
>>> +   struct plic_hart_context*context;
>>> +   struct plic_data*data;
>>> +};
>>> +
>>> +static inline
>>> +struct plic_hart_context *plic_hart_context(struct plic_data *data, size_t 
>>> i)
>>> +{
>>> +   return (struct plic_hart_context *)((char *)data->reg + HART_BASE + 
>>> HART_SIZE*i);
>>> +}
>
> 'data->reg' is an __iomem pointer, so when you build-test this with 'make 
> C=1',
> you should get a valid warning from sparse about an address space mismatch.
> Please address all the warning from sparse.

I didn't know about sparse.  I'll run it on our port and fix everything.

>>> +static void plic_disable(struct plic_data *data, int i, int hwirq)
>>> +{
>>> +   struct plic_enable_context *enable = plic_enable_context(data, i);
>>> +
>>> +   atomic_and(~(1 << (hwirq % 32)), >mask[hwirq / 32]);
>>> +}
>
> In particular, you must not do atomic operations on MMIO pointers.
> On most architectures these are explicitly disallowed and trap for
> a good reason, as the hardware implementation behind atomics tend
> to rely on the cache controller, while mmio registers are required
> to be uncached.

Sorry about that: the SiFive bus actually supports AMOs natively out to the
every device, even without caches, bit the RISC-V spec allows regions
to be marked as not supporting AMOs.  Sometimes a few SiFive-isms sneak in from
before the supervisor spec was written in this particular manner.  I've
converted this to a spinlock instead.

  
https://github.com/riscv/riscv-linux/commit/79b26ca800663399ea7d9dead73f3715deee1a99


>>> +   iowrite32(1, >prio[d->hwirq]);
>
> I would normally use 'readl' instead of 'iowrite32'. They may be the same
> on riscv, but they have slightly different meaning in portable drivers.

I assume you meant writel?  If so, that makes sense

  
https://github.com/riscv/riscv-linux/commit/45c968f1f068c35e0a5c8c90ba0776e7bdb6db78

Re: [PATCH 10/17] irqchip: New RISC-V PLIC Driver

[Palmer Dabbelt]

On Wed, 07 Jun 2017 00:55:28 PDT (-0700), Arnd Bergmann wrote:
> On Wed, Jun 7, 2017 at 9:13 AM, Geert Uytterhoeven  
> wrote:
>>> +struct plic_enable_context {
>>> +   atomic_t mask[32]; // 32-bit * 32-entry
>>> +};
>
> You use many '//' style comments in this file, please change them all to '/* 
> */'
> for consistency with kernel coding style.

OK, I fixed them here and in all our other files that had them.

>>> +
>>> +struct plic_priority {
>>> +   u32 prio[MAX_DEVICES];
>>> +};
>>> +
>>> +struct plic_data {
>>> +   struct irq_chip chip;
>>> +   struct irq_domain   *domain;
>>> +   u32 ndev;
>>> +   void __iomem*reg;
>>> +   int handlers;
>>> +   struct plic_handler *handler;
>>> +   charname[30];
>>> +};
>>> +
>>> +struct plic_handler {
>>> +   struct plic_hart_context*context;
>>> +   struct plic_data*data;
>>> +};
>>> +
>>> +static inline
>>> +struct plic_hart_context *plic_hart_context(struct plic_data *data, size_t 
>>> i)
>>> +{
>>> +   return (struct plic_hart_context *)((char *)data->reg + HART_BASE + 
>>> HART_SIZE*i);
>>> +}
>
> 'data->reg' is an __iomem pointer, so when you build-test this with 'make 
> C=1',
> you should get a valid warning from sparse about an address space mismatch.
> Please address all the warning from sparse.

I didn't know about sparse.  I'll run it on our port and fix everything.

>>> +static void plic_disable(struct plic_data *data, int i, int hwirq)
>>> +{
>>> +   struct plic_enable_context *enable = plic_enable_context(data, i);
>>> +
>>> +   atomic_and(~(1 << (hwirq % 32)), >mask[hwirq / 32]);
>>> +}
>
> In particular, you must not do atomic operations on MMIO pointers.
> On most architectures these are explicitly disallowed and trap for
> a good reason, as the hardware implementation behind atomics tend
> to rely on the cache controller, while mmio registers are required
> to be uncached.

Sorry about that: the SiFive bus actually supports AMOs natively out to the
every device, even without caches, bit the RISC-V spec allows regions
to be marked as not supporting AMOs.  Sometimes a few SiFive-isms sneak in from
before the supervisor spec was written in this particular manner.  I've
converted this to a spinlock instead.

  
https://github.com/riscv/riscv-linux/commit/79b26ca800663399ea7d9dead73f3715deee1a99


>>> +   iowrite32(1, >prio[d->hwirq]);
>
> I would normally use 'readl' instead of 'iowrite32'. They may be the same
> on riscv, but they have slightly different meaning in portable drivers.

I assume you meant writel?  If so, that makes sense

  
https://github.com/riscv/riscv-linux/commit/45c968f1f068c35e0a5c8c90ba0776e7bdb6db78