Re: [PATCH 3.2 085/115] veth: don???t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Willy Tarreau 
On Sat, Apr 30, 2016 at 03:43:51PM -0700, Ben Greear wrote:
> On 04/30/2016 03:01 PM, Vijay Pandurangan wrote:
> > Consider:
> > 
> > - App A  sends out corrupt packets 50% of the time and discards inbound 
> > data.
(...)
> How can you make a generic app C know how to do this?  The path could be,
> for instance:
> 
> eth0 <-> user-space-A <-> vethA <-> vethB <-> { kernel routing logic } <-> 
> vethC <-> vethD <-> appC
> 
> There are no sockets on vethB, but it does need to have special behaviour to 
> elide
> csums.  Even if appC is hacked to know how to twiddle some thing on it's veth 
> port,
> mucking with vethD will have no effect on vethB.
> 
> With regard to your example above, why would A corrupt packets?  My guess:
> 
> 1)  It has bugs (so, fix the bugs, it could equally create incorrect data 
> with proper checksums,
> so just enabling checksumming adds no useful protection.)

I agree with Ben here, what he needs is the ability for userspace to be
trusted when *forwarding* a packet. Ideally you'd only want to receive
the csum status per packet on the packet socket and pass the same value
on the vethA interface, with this status being kept when the packet
reaches vethB.

If A purposely corrupts packet, it's A's problem. It's similar to designing
a NIC which intentionally corrupts packets and reports "checksum good".

The real issue is that in order to do things right, the userspace bridge
(here, "A") would really need to pass this status. In Ben's case as he
says, bad checksum packets are dropped before reaching A, so that
simplifies the process quite a bit and that might be what causes some
confusion, but ideally we'd rather have recvmsg() and sendmsg() with
these flags.

I faced the exact same issue 3 years ago when playing with netmap, it was
slow as hell because it would lose all checksum information when packets
were passing through userland, resulting in GRO/GSO etc being disabled,
and had to modify it to let userland preserve it. That's especially
important when you have to deal with possibly corrupted packets not yet
detected in the chain because the NIC did not validate their checksums.

Willy

Re: [PATCH 3.2 085/115] veth: don???t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Willy Tarreau 
On Sat, Apr 30, 2016 at 03:43:51PM -0700, Ben Greear wrote:
> On 04/30/2016 03:01 PM, Vijay Pandurangan wrote:
> > Consider:
> > 
> > - App A  sends out corrupt packets 50% of the time and discards inbound 
> > data.
(...)
> How can you make a generic app C know how to do this?  The path could be,
> for instance:
> 
> eth0 <-> user-space-A <-> vethA <-> vethB <-> { kernel routing logic } <-> 
> vethC <-> vethD <-> appC
> 
> There are no sockets on vethB, but it does need to have special behaviour to 
> elide
> csums.  Even if appC is hacked to know how to twiddle some thing on it's veth 
> port,
> mucking with vethD will have no effect on vethB.
> 
> With regard to your example above, why would A corrupt packets?  My guess:
> 
> 1)  It has bugs (so, fix the bugs, it could equally create incorrect data 
> with proper checksums,
> so just enabling checksumming adds no useful protection.)

I agree with Ben here, what he needs is the ability for userspace to be
trusted when *forwarding* a packet. Ideally you'd only want to receive
the csum status per packet on the packet socket and pass the same value
on the vethA interface, with this status being kept when the packet
reaches vethB.

If A purposely corrupts packet, it's A's problem. It's similar to designing
a NIC which intentionally corrupts packets and reports "checksum good".

The real issue is that in order to do things right, the userspace bridge
(here, "A") would really need to pass this status. In Ben's case as he
says, bad checksum packets are dropped before reaching A, so that
simplifies the process quite a bit and that might be what causes some
confusion, but ideally we'd rather have recvmsg() and sendmsg() with
these flags.

I faced the exact same issue 3 years ago when playing with netmap, it was
slow as hell because it would lose all checksum information when packets
were passing through userland, resulting in GRO/GSO etc being disabled,
and had to modify it to let userland preserve it. That's especially
important when you have to deal with possibly corrupted packets not yet
detected in the chain because the NIC did not validate their checksums.

Willy

[PATCH RESEND 01/12] sh: Fix typo

2016-04-30 Thread Yoshinori Sato 
BL is 1 in this time.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/kernel/head_32.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/head_32.S b/arch/sh/kernel/head_32.S
index 974bc15..14da954 100644
--- a/arch/sh/kernel/head_32.S
+++ b/arch/sh/kernel/head_32.S
@@ -59,7 +59,7 @@ ENTRY(empty_zero_page)
  */
 ENTRY(_stext)
!   Initialize Status Register
-   mov.l   1f, r0  ! MD=1, RB=0, BL=0, IMASK=0xF
+   mov.l   1f, r0  ! MD=1, RB=0, BL=1, IMASK=0xF
ldc r0, sr
!   Initialize global interrupt mask
 #ifdef CONFIG_CPU_HAS_SR_RB
-- 
2.7.0

[PATCH RESEND 01/12] sh: Fix typo

2016-04-30 Thread Yoshinori Sato 
BL is 1 in this time.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/kernel/head_32.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/head_32.S b/arch/sh/kernel/head_32.S
index 974bc15..14da954 100644
--- a/arch/sh/kernel/head_32.S
+++ b/arch/sh/kernel/head_32.S
@@ -59,7 +59,7 @@ ENTRY(empty_zero_page)
  */
 ENTRY(_stext)
!   Initialize Status Register
-   mov.l   1f, r0  ! MD=1, RB=0, BL=0, IMASK=0xF
+   mov.l   1f, r0  ! MD=1, RB=0, BL=1, IMASK=0xF
ldc r0, sr
!   Initialize global interrupt mask
 #ifdef CONFIG_CPU_HAS_SR_RB
-- 
2.7.0

[PATCH RESEND 03/12] sh: Disable board specific code in OF mode

2016-04-30 Thread Yoshinori Sato 
Board specific code conflict on of-generic.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/Makefile | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index bf5b3f5..8ff943b 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -130,6 +130,9 @@ head-y  := arch/sh/kernel/head_$(BITS).o
 core-y += arch/sh/kernel/ arch/sh/mm/ arch/sh/boards/
 core-$(CONFIG_SH_FPU_EMU)  += arch/sh/math-emu/
 
+core-$(CONFIG_USE_BUILTIN_DTB) += arch/sh/boot/dts/
+
+ifneq ($(CONFIG_SH_DEVICE_TREE),y)
 # Mach groups
 machdir-$(CONFIG_SOLUTION_ENGINE)  += mach-se
 machdir-$(CONFIG_SH_HP6XX) += mach-hp6xx
@@ -150,6 +153,7 @@ machdir-$(CONFIG_SH_LANDISK)+= 
mach-landisk
 machdir-$(CONFIG_SH_LBOX_RE2)  += mach-lboxre2
 machdir-$(CONFIG_SH_CAYMAN)+= mach-cayman
 machdir-$(CONFIG_SH_RSK)   += mach-rsk
+endif
 
 ifneq ($(machdir-y),)
 core-y += $(addprefix arch/sh/boards/, \
@@ -222,6 +226,13 @@ archclean:
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/sh/kernel/vsyscall
 
+%.dtb %.dtb.S %.dtb.o: | scripts
+   $(Q)$(MAKE) $(build)=arch/sh/boot/dts arch/sh/boot/dts/$@
+
+PHONY += dtbs
+dtbs: scripts
+   $(Q)$(MAKE) $(build)=arch/sh/boot/dts
+
 define archhelp
@echo '  zImage- Compressed kernel image'
@echo '  romImage  - Compressed ROM image, if supported'
-- 
2.7.0

[PATCH RESEND 04/12] sh: Drop CPU specific setup on OF mode

2016-04-30 Thread Yoshinori Sato 
CPU specific set conflict of-generic.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/kernel/cpu/sh4/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/kernel/cpu/sh4/Makefile b/arch/sh/kernel/cpu/sh4/Makefile
index 3a1dbc7..b822c0c 100644
--- a/arch/sh/kernel/cpu/sh4/Makefile
+++ b/arch/sh/kernel/cpu/sh4/Makefile
@@ -14,6 +14,7 @@ perf-$(CONFIG_CPU_SUBTYPE_SH7750) := perf_event.o
 perf-$(CONFIG_CPU_SUBTYPE_SH7750S) := perf_event.o
 perf-$(CONFIG_CPU_SUBTYPE_SH7091)  := perf_event.o
 
+ifndef CONFIG_OF
 # CPU subtype setup
 obj-$(CONFIG_CPU_SUBTYPE_SH7750)   += setup-sh7750.o
 obj-$(CONFIG_CPU_SUBTYPE_SH7750R)  += setup-sh7750.o
@@ -31,6 +32,7 @@ endif
 
 # Additional clocks by subtype
 clock-$(CONFIG_CPU_SUBTYPE_SH4_202)+= clock-sh4-202.o
+endif
 
 obj-y  += $(clock-y)
 obj-$(CONFIG_PERF_EVENTS)  += $(perf-y)
-- 
2.7.0

Fail to build tools/all

2016-04-30 Thread Sean Fu 
Hi guys:
I encountered a build error when running "make V=1 tools/all".
Shall we write a patch to fix it?
The following is error log.

 start ==
commit 05cf8077e54b20dddb756eaa26f3aeb5c38dd3cf
Merge: cf78031 db5dd0d
Author: Linus Torvalds 
Date:   Fri Apr 1 20:03:33 2016 -0500
= end  =

== start ===
mkdir -p
/home/sean/work/source/upstream/kernel.linus/linux/tools/power/cpupower
&& make O=/home/sean/work/source/upstream/kernel.linus/linux
subdir=tools/power/cpupower --no-print-directory -C power/cpupower 
gcc  -DVERSION=\"4.6.rc1.190.g05cf80\" -DPACKAGE=\"cpupower\"
-DPACKAGE_BUGREPORT=\"linux...@vger.kernel.org\" -D_GNU_SOURCE -pipe
-DNLS -Wall -Wchar-subscripts -Wpointer-arith -Wsign-compare
-Wno-pointer-sign -Wdeclaration-after-statement -Wshadow -O1 -g -DDEBUG
-I./lib -I ./utils -o
/home/sean/work/source/upstream/kernel.linus/linux/utils/helpers/amd.o
-c utils/helpers/amd.c
utils/helpers/amd.c:7:21: fatal error: pci/pci.h: No such file or
directory
 #include 
  ^
  compilation terminated.
  Makefile:218: recipe for target
  
'/home/sean/work/source/upstream/kernel.linus/linux/utils/helpers/amd.o'
  failed
  make[2]: ***
  
[/home/sean/work/source/upstream/kernel.linus/linux/utils/helpers/amd.o]
  Error 1
  Makefile:56: recipe for target 'cpupower' failed
  make[1]: *** [cpupower] Error 2
  Makefile:1548: recipe for target 'tools/all'
  failed
  make: *** [tools/all] Error 2
=== end ==

BestRegards
Sean

[PATCH RESEND 03/12] sh: Disable board specific code in OF mode

2016-04-30 Thread Yoshinori Sato 
Board specific code conflict on of-generic.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/Makefile | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index bf5b3f5..8ff943b 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -130,6 +130,9 @@ head-y  := arch/sh/kernel/head_$(BITS).o
 core-y += arch/sh/kernel/ arch/sh/mm/ arch/sh/boards/
 core-$(CONFIG_SH_FPU_EMU)  += arch/sh/math-emu/
 
+core-$(CONFIG_USE_BUILTIN_DTB) += arch/sh/boot/dts/
+
+ifneq ($(CONFIG_SH_DEVICE_TREE),y)
 # Mach groups
 machdir-$(CONFIG_SOLUTION_ENGINE)  += mach-se
 machdir-$(CONFIG_SH_HP6XX) += mach-hp6xx
@@ -150,6 +153,7 @@ machdir-$(CONFIG_SH_LANDISK)+= 
mach-landisk
 machdir-$(CONFIG_SH_LBOX_RE2)  += mach-lboxre2
 machdir-$(CONFIG_SH_CAYMAN)+= mach-cayman
 machdir-$(CONFIG_SH_RSK)   += mach-rsk
+endif
 
 ifneq ($(machdir-y),)
 core-y += $(addprefix arch/sh/boards/, \
@@ -222,6 +226,13 @@ archclean:
$(Q)$(MAKE) $(clean)=$(boot)
$(Q)$(MAKE) $(clean)=arch/sh/kernel/vsyscall
 
+%.dtb %.dtb.S %.dtb.o: | scripts
+   $(Q)$(MAKE) $(build)=arch/sh/boot/dts arch/sh/boot/dts/$@
+
+PHONY += dtbs
+dtbs: scripts
+   $(Q)$(MAKE) $(build)=arch/sh/boot/dts
+
 define archhelp
@echo '  zImage- Compressed kernel image'
@echo '  romImage  - Compressed ROM image, if supported'
-- 
2.7.0

[PATCH RESEND 04/12] sh: Drop CPU specific setup on OF mode

2016-04-30 Thread Yoshinori Sato 
CPU specific set conflict of-generic.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/kernel/cpu/sh4/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/kernel/cpu/sh4/Makefile b/arch/sh/kernel/cpu/sh4/Makefile
index 3a1dbc7..b822c0c 100644
--- a/arch/sh/kernel/cpu/sh4/Makefile
+++ b/arch/sh/kernel/cpu/sh4/Makefile
@@ -14,6 +14,7 @@ perf-$(CONFIG_CPU_SUBTYPE_SH7750) := perf_event.o
 perf-$(CONFIG_CPU_SUBTYPE_SH7750S) := perf_event.o
 perf-$(CONFIG_CPU_SUBTYPE_SH7091)  := perf_event.o
 
+ifndef CONFIG_OF
 # CPU subtype setup
 obj-$(CONFIG_CPU_SUBTYPE_SH7750)   += setup-sh7750.o
 obj-$(CONFIG_CPU_SUBTYPE_SH7750R)  += setup-sh7750.o
@@ -31,6 +32,7 @@ endif
 
 # Additional clocks by subtype
 clock-$(CONFIG_CPU_SUBTYPE_SH4_202)+= clock-sh4-202.o
+endif
 
 obj-y  += $(clock-y)
 obj-$(CONFIG_PERF_EVENTS)  += $(perf-y)
-- 
2.7.0

Fail to build tools/all

2016-04-30 Thread Sean Fu 
Hi guys:
I encountered a build error when running "make V=1 tools/all".
Shall we write a patch to fix it?
The following is error log.

 start ==
commit 05cf8077e54b20dddb756eaa26f3aeb5c38dd3cf
Merge: cf78031 db5dd0d
Author: Linus Torvalds 
Date:   Fri Apr 1 20:03:33 2016 -0500
= end  =

== start ===
mkdir -p
/home/sean/work/source/upstream/kernel.linus/linux/tools/power/cpupower
&& make O=/home/sean/work/source/upstream/kernel.linus/linux
subdir=tools/power/cpupower --no-print-directory -C power/cpupower 
gcc  -DVERSION=\"4.6.rc1.190.g05cf80\" -DPACKAGE=\"cpupower\"
-DPACKAGE_BUGREPORT=\"linux...@vger.kernel.org\" -D_GNU_SOURCE -pipe
-DNLS -Wall -Wchar-subscripts -Wpointer-arith -Wsign-compare
-Wno-pointer-sign -Wdeclaration-after-statement -Wshadow -O1 -g -DDEBUG
-I./lib -I ./utils -o
/home/sean/work/source/upstream/kernel.linus/linux/utils/helpers/amd.o
-c utils/helpers/amd.c
utils/helpers/amd.c:7:21: fatal error: pci/pci.h: No such file or
directory
 #include 
  ^
  compilation terminated.
  Makefile:218: recipe for target
  
'/home/sean/work/source/upstream/kernel.linus/linux/utils/helpers/amd.o'
  failed
  make[2]: ***
  
[/home/sean/work/source/upstream/kernel.linus/linux/utils/helpers/amd.o]
  Error 1
  Makefile:56: recipe for target 'cpupower' failed
  make[1]: *** [cpupower] Error 2
  Makefile:1548: recipe for target 'tools/all'
  failed
  make: *** [tools/all] Error 2
=== end ==

BestRegards
Sean

[PATCH RESEND 11/12] sh: I/O DATA HDL-U defconfig (DT mode)

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 arch/sh/configs/landisk-dt_defconfig | 100 +++
 1 file changed, 100 insertions(+)
 create mode 100644 arch/sh/configs/landisk-dt_defconfig

diff --git a/arch/sh/configs/landisk-dt_defconfig 
b/arch/sh/configs/landisk-dt_defconfig
new file mode 100644
index 000..aa52fdb
--- /dev/null
+++ b/arch/sh/configs/landisk-dt_defconfig
@@ -0,0 +1,100 @@
+CONFIG_SYSVIPC=y
+# CONFIG_FHANDLE is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_CGROUPS=y
+CONFIG_NAMESPACES=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_EXPERT=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_CPU_SUBTYPE_SH7751R=y
+CONFIG_MEMORY_START=0x0c00
+CONFIG_FLATMEM_MANUAL=y
+CONFIG_SH_DEVICE_TREE=y
+CONFIG_SH_PCLK_FREQ=
+CONFIG_HEARTBEAT=y
+CONFIG_KEXEC=y
+CONFIG_PCI=y
+CONFIG_PCI_SH7751=y
+CONFIG_PCCARD=y
+CONFIG_YENTA=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_PATA_ARTOP=y
+CONFIG_NETDEVICES=y
+CONFIG_8139CP=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_EARLYCON=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+CONFIG_HID_A4TECH=m
+CONFIG_HID_APPLE=m
+CONFIG_HID_BELKIN=m
+CONFIG_HID_CHERRY=m
+CONFIG_HID_CHICONY=m
+CONFIG_HID_CYPRESS=m
+CONFIG_HID_EZKEY=m
+CONFIG_HID_GYRATION=m
+CONFIG_HID_KENSINGTON=y
+CONFIG_HID_LOGITECH=m
+CONFIG_HID_MICROSOFT=m
+CONFIG_HID_MONTEREY=m
+CONFIG_HID_PANTHERLORD=m
+CONFIG_HID_PETALYNX=m
+CONFIG_HID_SAMSUNG=m
+CONFIG_HID_SUNPLUS=m
+# CONFIG_USB_SUPPORT is not set
+CONFIG_COMMON_CLK_SH7750=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_ISO9660_FS=m
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=m
+CONFIG_NTFS_RW=y
+CONFIG_TMPFS=y
+CONFIG_ROMFS_FS=y
+CONFIG_UFS_FS=m
+CONFIG_NFS_FS=y
+CONFIG_NFS_SWAP=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_932=y
+CONFIG_DEBUG_INFO=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
+CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
+CONFIG_WQ_WATCHDOG=y
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_PANIC_TIMEOUT=1
+CONFIG_LOCK_STAT=y
+# CONFIG_FTRACE is not set
+CONFIG_CRC_T10DIF=y
-- 
2.7.0

[PATCH RESEND 11/12] sh: I/O DATA HDL-U defconfig (DT mode)

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 arch/sh/configs/landisk-dt_defconfig | 100 +++
 1 file changed, 100 insertions(+)
 create mode 100644 arch/sh/configs/landisk-dt_defconfig

diff --git a/arch/sh/configs/landisk-dt_defconfig 
b/arch/sh/configs/landisk-dt_defconfig
new file mode 100644
index 000..aa52fdb
--- /dev/null
+++ b/arch/sh/configs/landisk-dt_defconfig
@@ -0,0 +1,100 @@
+CONFIG_SYSVIPC=y
+# CONFIG_FHANDLE is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_CGROUPS=y
+CONFIG_NAMESPACES=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_EXPERT=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_CPU_SUBTYPE_SH7751R=y
+CONFIG_MEMORY_START=0x0c00
+CONFIG_FLATMEM_MANUAL=y
+CONFIG_SH_DEVICE_TREE=y
+CONFIG_SH_PCLK_FREQ=
+CONFIG_HEARTBEAT=y
+CONFIG_KEXEC=y
+CONFIG_PCI=y
+CONFIG_PCI_SH7751=y
+CONFIG_PCCARD=y
+CONFIG_YENTA=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_PATA_ARTOP=y
+CONFIG_NETDEVICES=y
+CONFIG_8139CP=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_EARLYCON=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+CONFIG_HID_A4TECH=m
+CONFIG_HID_APPLE=m
+CONFIG_HID_BELKIN=m
+CONFIG_HID_CHERRY=m
+CONFIG_HID_CHICONY=m
+CONFIG_HID_CYPRESS=m
+CONFIG_HID_EZKEY=m
+CONFIG_HID_GYRATION=m
+CONFIG_HID_KENSINGTON=y
+CONFIG_HID_LOGITECH=m
+CONFIG_HID_MICROSOFT=m
+CONFIG_HID_MONTEREY=m
+CONFIG_HID_PANTHERLORD=m
+CONFIG_HID_PETALYNX=m
+CONFIG_HID_SAMSUNG=m
+CONFIG_HID_SUNPLUS=m
+# CONFIG_USB_SUPPORT is not set
+CONFIG_COMMON_CLK_SH7750=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_ISO9660_FS=m
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=m
+CONFIG_NTFS_RW=y
+CONFIG_TMPFS=y
+CONFIG_ROMFS_FS=y
+CONFIG_UFS_FS=m
+CONFIG_NFS_FS=y
+CONFIG_NFS_SWAP=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_932=y
+CONFIG_DEBUG_INFO=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
+CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
+CONFIG_WQ_WATCHDOG=y
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_PANIC_TIMEOUT=1
+CONFIG_LOCK_STAT=y
+# CONFIG_FTRACE is not set
+CONFIG_CRC_T10DIF=y
-- 
2.7.0

[PATCH RESEND 10/12] sh: I/O DATA HDL-U (aka landisk) support dts

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/landisk.dts | 150 +++
 1 file changed, 150 insertions(+)
 create mode 100644 arch/sh/boot/dts/landisk.dts

diff --git a/arch/sh/boot/dts/landisk.dts b/arch/sh/boot/dts/landisk.dts
new file mode 100644
index 000..a994d19
--- /dev/null
+++ b/arch/sh/boot/dts/landisk.dts
@@ -0,0 +1,150 @@
+#include 
+
+/dts-v1/;
+/ {
+   model = "I/O DATA HDL-U";
+   compatible = "iodata,hdl-u";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <>;
+   chosen {
+   stdout-path = 
+   bootargs = "console=ttySC1,115200";
+   };
+   aliases {
+   serial0 = 
+   serial1 = 
+   };
+
+   oclk: oscillator {
+#clock-cells = <0>;
+compatible = "fixed-clock";
+clock-frequency = <>;
+};
+pllclk: pllclk {
+compatible = "renesas,sh7750-pll-clock";
+clocks = <>;
+#clock-cells = <0>;
+   renesas,mult = <12>;
+reg = <0xffc0 2>, <0xffc8 4>;
+};
+iclk: iclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <6>;
+   clock-output-names = "ick";
+};
+bclk: bclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <3>;
+   clock-output-names = "bck";
+};
+fclk: fclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <0>;
+   clock-output-names = "fck";
+};
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu@0 {
+ compatible = "renesas,sh4", "renesas,sh";
+ clock-frequency = <2>;
+   };
+   };
+   memory@0c00 {
+   device_type = "memory";
+   reg = <0x0c00 0x400>;
+   };
+   shintc: interrupt-controller@ffd0 {
+   compatible = "renesas,sh7751-intc";
+   #interrupt-cells = <2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-controller;
+   reg = <0xffd0 14>, <0xfe08 128>;
+
+   };
+   cpldintc: cpld@b000 {
+   compatible = "iodata,landisk-intc";
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   reg = <0xb000 8>;
+   interrupt-map=<0  0 0>, <1  1 0>,
+ <2  2 0>, <3  3 0>,
+ <4  4 0>, <5  5 0>,
+ <6  6 0>, <7  7 0>;
+   };
+   sci0: serial@ffe0 {
+   compatible = "renesas,scif";
+   reg = <0xffe0 0x20>;
+   interrupts = ;
+   clocks = <>;
+   clock-names = "fck";
+   };
+   sci1: serial@ffe8 {
+   compatible = "renesas,scif";
+   reg = <0xffe8 0x100>;
+   interrupts = ;
+   clocks = <>;
+   clock-names = "fck";
+   };
+   tmu: timer@ffd80008 {
+   compatible = "renesas,tmu";
+   reg = <0xffd8 12>;
+   interrupts = ;
+   clocks = <>;
+   clock-names = "fck";
+   renesas,channels-mask = <0x03>;
+   };
+
+   pci: pci-controller@fe20 {
+   compatible = "renesas,sh7751-pci", "iodata,landisk";
+   device_type = "pci";
+   bus-range = <0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0x0200 0x 0xfd00 0xfd00 
0x 0x0100>,
+<0x0100 0x 0xfe24 0x 
0x 0x0004>;
+   reg = <0xfe20 0x0400>,
+ <0x0c00 0x0400>,
+ <0xff80 0x0030>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask =

[PATCH RESEND 09/12] sh: Add I/O DATA HDL-U support drivers.

2016-04-30 Thread Yoshinori Sato 
PCI host fixup and external interrupt controller.

Signed-off-by: Yoshinori Sato 
---
 .../interrupt-controller/iodata-landisk.txt| 28 +
 drivers/irqchip/irq-io-landisk.c   | 71 ++
 drivers/pci/host/pci-sh7751.c  | 25 
 3 files changed, 124 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
 create mode 100644 drivers/irqchip/irq-io-landisk.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt 
b/Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
new file mode 100644
index 000..09c2841
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
@@ -0,0 +1,28 @@
+DT bindings for the I/O DATA HDL-U interrupt controler
+
+Required properties:
+
+  - compatible: has to be "iodata,landisk-intc".
+
+  - reg: Base address and length of interrupt controller register.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+
+  - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined
+in interrupts.txt in this directory.
+
+  - interrupt-map: Interrupt mapping on parent controler.
+
+Example
+---
+
+   cpldintc: cpld@b000 {
+   compatible = "iodata,landisk-intc";
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   reg = <0xb000 8>;
+   interrupt-map=<0  0 0>, <1  1 0>,
+ <2  2 0>, <3  3 0>,
+ <4  4 0>, <5  5 0>,
+ <6  6 0>, <7  7 0>;
+   };
diff --git a/drivers/irqchip/irq-io-landisk.c b/drivers/irqchip/irq-io-landisk.c
new file mode 100644
index 000..c351925
--- /dev/null
+++ b/drivers/irqchip/irq-io-landisk.c
@@ -0,0 +1,71 @@
+/*
+ * IO-DATA LANDISK CPLD IRQ driver
+ *
+ * Copyright 2016 Yoshinori Sato 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void landisk_mask_irq(struct irq_data *data)
+{
+   u8 mask = __raw_readb(data->chip_data + 5);
+
+   mask &= !(1 << (data->irq - 5));
+   __raw_writeb(mask, data->chip_data + 5);
+}
+
+static void landisk_unmask_irq(struct irq_data *data)
+{
+   u8 mask = __raw_readb(data->chip_data + 5);
+
+   mask |= (1 << (data->irq - 5));
+   __raw_writeb(mask, data->chip_data + 5);
+}
+
+static struct irq_chip cpld_irq_chip = {
+   .name   = "LANDISK-CPLD",
+   .irq_unmask = landisk_unmask_irq,
+   .irq_mask   = landisk_mask_irq,
+};
+
+static int cpld_map(struct irq_domain *d, unsigned int virq,
+   irq_hw_number_t hw_irq_num)
+{
+   irq_set_chip_and_handler(virq, _irq_chip,
+handle_simple_irq);
+   irq_set_chip_data(virq, d->host_data);
+
+   return 0;
+}
+
+static struct irq_domain_ops irq_ops = {
+   .xlate  = irq_domain_xlate_twocell,
+   .map= cpld_map,
+};
+
+static int __init landisk_intc_of_init(struct device_node *intc,
+   struct device_node *parent)
+{
+   struct irq_domain *domain, *pdomain;
+   int num_irqpin;
+   void *baseaddr;
+
+   baseaddr = of_iomap(intc, 0);
+   pdomain = irq_find_host(parent);
+   of_get_property(intc, "interrupt-map", _irqpin);
+   num_irqpin /= sizeof(u32) * 3;
+   domain = irq_domain_create_hierarchy(pdomain, 0, num_irqpin,
+of_node_to_fwnode(intc),
+_ops, baseaddr);
+   BUG_ON(!domain);
+   irq_domain_associate_many(domain, 0, 0, 8);
+   return 0;
+}
+
+IRQCHIP_DECLARE(cpld_intc, "iodata,landisk-intc", landisk_intc_of_init);
diff --git a/drivers/pci/host/pci-sh7751.c b/drivers/pci/host/pci-sh7751.c
index fd6548b..3fa0da5 100644
--- a/drivers/pci/host/pci-sh7751.c
+++ b/drivers/pci/host/pci-sh7751.c
@@ -26,10 +26,35 @@ DEFINE_RAW_SPINLOCK(pci_config_lock);
  * PCIC fixups
  */
 
+#define PCIMCR_MRSET 0x4000
+#define PCIMCR_RFSH  0x0004
+
+static void __init landisk_fixup(void __iomem *pci_reg_base, void __iomem *bcr)
+{
+   unsigned long bcr1, mcr;
+
+   bcr1 = __raw_readl(bcr + SH7751_BCR1);
+   bcr1 |= 0x0008; /* Enable Bit 19 BREQEN, set PCIC to slave */
+   pcic_writel(bcr1, SH4_PCIBCR1);
+
+   mcr = __raw_readl(bcr + SH7751_MCR);
+   mcr &= (~PCIMCR_MRSET) & (~PCIMCR_RFSH);
+   pcic_writel(mcr, SH4_PCIMCR);
+
+   pcic_writel(0x0c00, SH7751_PCICONF5);
+   pcic_writel(0xd000, SH7751_PCICONF6);
+   pcic_writel(0x0c00, SH4_PCILAR0);
+   pcic_writel(0x, SH4_PCILAR1);
+}
+
 static __initconst const struct fixups {
char *compatible;
void (*fixup)(void __iomem *, void __iomem *);
 } fixup_list[] = {
+   {
+

[PATCH RESEND 09/12] sh: Add I/O DATA HDL-U support drivers.

2016-04-30 Thread Yoshinori Sato 
PCI host fixup and external interrupt controller.

Signed-off-by: Yoshinori Sato 
---
 .../interrupt-controller/iodata-landisk.txt| 28 +
 drivers/irqchip/irq-io-landisk.c   | 71 ++
 drivers/pci/host/pci-sh7751.c  | 25 
 3 files changed, 124 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
 create mode 100644 drivers/irqchip/irq-io-landisk.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt 
b/Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
new file mode 100644
index 000..09c2841
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
@@ -0,0 +1,28 @@
+DT bindings for the I/O DATA HDL-U interrupt controler
+
+Required properties:
+
+  - compatible: has to be "iodata,landisk-intc".
+
+  - reg: Base address and length of interrupt controller register.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+
+  - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined
+in interrupts.txt in this directory.
+
+  - interrupt-map: Interrupt mapping on parent controler.
+
+Example
+---
+
+   cpldintc: cpld@b000 {
+   compatible = "iodata,landisk-intc";
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   reg = <0xb000 8>;
+   interrupt-map=<0  0 0>, <1  1 0>,
+ <2  2 0>, <3  3 0>,
+ <4  4 0>, <5  5 0>,
+ <6  6 0>, <7  7 0>;
+   };
diff --git a/drivers/irqchip/irq-io-landisk.c b/drivers/irqchip/irq-io-landisk.c
new file mode 100644
index 000..c351925
--- /dev/null
+++ b/drivers/irqchip/irq-io-landisk.c
@@ -0,0 +1,71 @@
+/*
+ * IO-DATA LANDISK CPLD IRQ driver
+ *
+ * Copyright 2016 Yoshinori Sato 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void landisk_mask_irq(struct irq_data *data)
+{
+   u8 mask = __raw_readb(data->chip_data + 5);
+
+   mask &= !(1 << (data->irq - 5));
+   __raw_writeb(mask, data->chip_data + 5);
+}
+
+static void landisk_unmask_irq(struct irq_data *data)
+{
+   u8 mask = __raw_readb(data->chip_data + 5);
+
+   mask |= (1 << (data->irq - 5));
+   __raw_writeb(mask, data->chip_data + 5);
+}
+
+static struct irq_chip cpld_irq_chip = {
+   .name   = "LANDISK-CPLD",
+   .irq_unmask = landisk_unmask_irq,
+   .irq_mask   = landisk_mask_irq,
+};
+
+static int cpld_map(struct irq_domain *d, unsigned int virq,
+   irq_hw_number_t hw_irq_num)
+{
+   irq_set_chip_and_handler(virq, _irq_chip,
+handle_simple_irq);
+   irq_set_chip_data(virq, d->host_data);
+
+   return 0;
+}
+
+static struct irq_domain_ops irq_ops = {
+   .xlate  = irq_domain_xlate_twocell,
+   .map= cpld_map,
+};
+
+static int __init landisk_intc_of_init(struct device_node *intc,
+   struct device_node *parent)
+{
+   struct irq_domain *domain, *pdomain;
+   int num_irqpin;
+   void *baseaddr;
+
+   baseaddr = of_iomap(intc, 0);
+   pdomain = irq_find_host(parent);
+   of_get_property(intc, "interrupt-map", _irqpin);
+   num_irqpin /= sizeof(u32) * 3;
+   domain = irq_domain_create_hierarchy(pdomain, 0, num_irqpin,
+of_node_to_fwnode(intc),
+_ops, baseaddr);
+   BUG_ON(!domain);
+   irq_domain_associate_many(domain, 0, 0, 8);
+   return 0;
+}
+
+IRQCHIP_DECLARE(cpld_intc, "iodata,landisk-intc", landisk_intc_of_init);
diff --git a/drivers/pci/host/pci-sh7751.c b/drivers/pci/host/pci-sh7751.c
index fd6548b..3fa0da5 100644
--- a/drivers/pci/host/pci-sh7751.c
+++ b/drivers/pci/host/pci-sh7751.c
@@ -26,10 +26,35 @@ DEFINE_RAW_SPINLOCK(pci_config_lock);
  * PCIC fixups
  */
 
+#define PCIMCR_MRSET 0x4000
+#define PCIMCR_RFSH  0x0004
+
+static void __init landisk_fixup(void __iomem *pci_reg_base, void __iomem *bcr)
+{
+   unsigned long bcr1, mcr;
+
+   bcr1 = __raw_readl(bcr + SH7751_BCR1);
+   bcr1 |= 0x0008; /* Enable Bit 19 BREQEN, set PCIC to slave */
+   pcic_writel(bcr1, SH4_PCIBCR1);
+
+   mcr = __raw_readl(bcr + SH7751_MCR);
+   mcr &= (~PCIMCR_MRSET) & (~PCIMCR_RFSH);
+   pcic_writel(mcr, SH4_PCIMCR);
+
+   pcic_writel(0x0c00, SH7751_PCICONF5);
+   pcic_writel(0xd000, SH7751_PCICONF6);
+   pcic_writel(0x0c00, SH4_PCILAR0);
+   pcic_writel(0x, SH4_PCILAR1);
+}
+
 static __initconst const struct fixups {
char *compatible;
void (*fixup)(void __iomem *, void __iomem *);
 } fixup_list[] = {
+   {
+   .compatible = "iodata,landisk",
+

[PATCH RESEND 10/12] sh: I/O DATA HDL-U (aka landisk) support dts

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/landisk.dts | 150 +++
 1 file changed, 150 insertions(+)
 create mode 100644 arch/sh/boot/dts/landisk.dts

diff --git a/arch/sh/boot/dts/landisk.dts b/arch/sh/boot/dts/landisk.dts
new file mode 100644
index 000..a994d19
--- /dev/null
+++ b/arch/sh/boot/dts/landisk.dts
@@ -0,0 +1,150 @@
+#include 
+
+/dts-v1/;
+/ {
+   model = "I/O DATA HDL-U";
+   compatible = "iodata,hdl-u";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <>;
+   chosen {
+   stdout-path = 
+   bootargs = "console=ttySC1,115200";
+   };
+   aliases {
+   serial0 = 
+   serial1 = 
+   };
+
+   oclk: oscillator {
+#clock-cells = <0>;
+compatible = "fixed-clock";
+clock-frequency = <>;
+};
+pllclk: pllclk {
+compatible = "renesas,sh7750-pll-clock";
+clocks = <>;
+#clock-cells = <0>;
+   renesas,mult = <12>;
+reg = <0xffc0 2>, <0xffc8 4>;
+};
+iclk: iclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <6>;
+   clock-output-names = "ick";
+};
+bclk: bclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <3>;
+   clock-output-names = "bck";
+};
+fclk: fclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <0>;
+   clock-output-names = "fck";
+};
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu@0 {
+ compatible = "renesas,sh4", "renesas,sh";
+ clock-frequency = <2>;
+   };
+   };
+   memory@0c00 {
+   device_type = "memory";
+   reg = <0x0c00 0x400>;
+   };
+   shintc: interrupt-controller@ffd0 {
+   compatible = "renesas,sh7751-intc";
+   #interrupt-cells = <2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-controller;
+   reg = <0xffd0 14>, <0xfe08 128>;
+
+   };
+   cpldintc: cpld@b000 {
+   compatible = "iodata,landisk-intc";
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   reg = <0xb000 8>;
+   interrupt-map=<0  0 0>, <1  1 0>,
+ <2  2 0>, <3  3 0>,
+ <4  4 0>, <5  5 0>,
+ <6  6 0>, <7  7 0>;
+   };
+   sci0: serial@ffe0 {
+   compatible = "renesas,scif";
+   reg = <0xffe0 0x20>;
+   interrupts = ;
+   clocks = <>;
+   clock-names = "fck";
+   };
+   sci1: serial@ffe8 {
+   compatible = "renesas,scif";
+   reg = <0xffe8 0x100>;
+   interrupts = ;
+   clocks = <>;
+   clock-names = "fck";
+   };
+   tmu: timer@ffd80008 {
+   compatible = "renesas,tmu";
+   reg = <0xffd8 12>;
+   interrupts = ;
+   clocks = <>;
+   clock-names = "fck";
+   renesas,channels-mask = <0x03>;
+   };
+
+   pci: pci-controller@fe20 {
+   compatible = "renesas,sh7751-pci", "iodata,landisk";
+   device_type = "pci";
+   bus-range = <0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0x0200 0x 0xfd00 0xfd00 
0x 0x0100>,
+<0x0100 0x 0xfe24 0x 
0x 0x0004>;
+   reg = <0xfe20 0x0400>,
+ <0x0c00 0x0400>,
+ <0xff80 0x0030>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0x1800 0 7>;
+   interrupt-map = <0x 0 1  evt2irq(0x2a0) 0
+0x 0 2  evt2irq(0x2c0) 0
+0x 0 3  evt2irq(0x2e0) 0
+0x 0 4  evt2irq(0x300) 0
+
+0x0800 0 1  evt2irq(0x2c0) 0
+0x0800 0 2  evt2irq(0x2e0) 0
+0x0800 0 3  evt2irq(0x300) 0
+

[PATCH RESEND 08/12] intc: sh: Renesas Super H INTC driver

2016-04-30 Thread Yoshinori Sato 
SuperH IPR based driver.

Signed-off-by: Yoshinori Sato 
---
 .../interrupt-controller/renesas,sh7751-intc.txt   |  25 
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-renesas-shipr.c| 138 +
 4 files changed, 169 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
 create mode 100644 drivers/irqchip/irq-renesas-shipr.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
new file mode 100644
index 000..6d9bf6c
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
@@ -0,0 +1,25 @@
+DT bindings for the SH7751 interrupt controller
+
+Required properties:
+
+  - compatible: has to be "renesas,sh7751-intc".
+
+  - reg: Base address and length of interrupt controller register
+ and extend register.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+
+  - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined
+in interrupts.txt in this directory.
+
+Example
+---
+
+   shintc: interrupt-controller@ffd0 {
+   compatible = "renesas,sh7751-intc";
+   #interrupt-cells = <2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-controller;
+   reg = <0xffd0 14>, <0xfe08 128>;
+   };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3e12479..273f19d 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -244,3 +244,8 @@ config IRQ_MXS
 config MVEBU_ODMI
bool
select GENERIC_MSI_IRQ_DOMAIN
+
+config RENESAS_SH_INTC
+   def_bool y if SH_DEVICE_TREE
+   select IRQ_DOMAIN
+   select IRQ_DOMAIN_HIERARCHY
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b03cfcb..3f9fc5c 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)   += irq-pic32-evic.o
 obj-$(CONFIG_MVEBU_ODMI)   += irq-mvebu-odmi.o
+obj-$(CONFIG_RENESAS_SH_INTC)  += irq-renesas-shipr.o irq-io-landisk.o
diff --git a/drivers/irqchip/irq-renesas-shipr.c 
b/drivers/irqchip/irq-renesas-shipr.c
new file mode 100644
index 000..67cce6a
--- /dev/null
+++ b/drivers/irqchip/irq-renesas-shipr.c
@@ -0,0 +1,138 @@
+/*
+ * SH IPR-INTC interrupt contoller driver
+ *
+ * Copyright 2016 Yoshinori Sato 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct sh7751_intc_regs {
+   void *icr;
+   void *ipr;
+   void *intpri00;
+   void *intreq00;
+   void *intmsk00;
+   void *intmskclr00;
+} sh7751_regs;
+
+static const unsigned int ipr_table[] = {
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0 - 7 */
+   0x41, 0xff, 0xff, 0x40, 0xff, 0xff, 0xff, 0xff, /* 8 - 15 */
+   0x03, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00, 0x11, /* 16 - 23 */
+   0x11, 0x11, 0x11, 0x13, 0x12, 0x12, 0xff, 0xff, /* 24 - 31 */
+   0x30, 0x33, 0x32, 0x32, 0x32, 0x32, 0x32, 0x21, /* 32 - 39 */
+   0x21, 0x21, 0x21, 0x21, 0x32, 0x32, 0x32, 0x32, /* 40 - 47 */
+   0xff, 0xff, 0xff, 0x40, 0xff, 0xff, 0xff, 0xff, /* 48 - 55 */
+   0xff, 0xff, 0xff, 0x40, 0xff, 0xff, 0xff, 0xff, /* 56 - 63 */
+};
+
+static const unsigned int pri_table[] = {
+   0, 4, 4, 4, 4, 4, 4, 4,
+   8, 32, 32, 32, 12, 32, 32, 32,
+};
+
+static void sh_disable_irq(struct irq_data *data)
+{
+   int pos;
+   unsigned int addr;
+   unsigned long pri;
+   int irq = data->irq;
+   struct sh7751_intc_regs *reg = data->chip_data;
+
+   if (irq < 64) {
+   if (ipr_table[irq] != 0xff) {
+   addr = (ipr_table[irq] & 0xf0) >> 2;
+   pos = (ipr_table[irq] & 0x0f) << 4;
+   pri = ~(0x000f << pos);
+   pri &= __raw_readw(reg->ipr + addr);
+   __raw_writew(pri, reg->ipr + addr);
+   }
+   } else {
+   if (pri_table[irq - 64] < 32) {
+   pos = pri_table[irq - 64];
+   pri = ~(0x000f << pos);
+   pri &= __raw_readw(reg->intpri00);
+   __raw_writew(pri, reg->intpri00);
+   }
+   }
+}
+
+static void sh_enable_irq(struct irq_data *data)
+{
+   int pos;
+   unsigned int addr;
+   unsigned long pri;
+   int irq = data->irq;
+   struct sh7751_intc_regs *reg = data->chip_data;
+
+   if (irq < 64) {
+   if

[PATCH RESEND 06/12] clk: sh: SH7750/51 PLL and divider clock driver

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 .../bindings/clock/renesas,sh-div-clock.txt|  24 ++
 .../bindings/clock/renesas,sh7750-div-clock.txt|  27 ++
 .../bindings/clock/renesas,sh7750-pll-clock.txt|  26 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   3 +-
 drivers/clk/sh/Kconfig |   5 +
 drivers/clk/sh/Makefile|   2 +
 drivers/clk/sh/clk-sh7750.c| 223 ++
 drivers/clk/sh/clk-shdiv.c | 338 +
 9 files changed, 648 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
 create mode 100644 drivers/clk/sh/Kconfig
 create mode 100644 drivers/clk/sh/Makefile
 create mode 100644 drivers/clk/sh/clk-sh7750.c
 create mode 100644 drivers/clk/sh/clk-shdiv.c

diff --git a/Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt 
b/Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
new file mode 100644
index 000..399e0da
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
@@ -0,0 +1,24 @@
+* Renesas H8/300 divider clock
+
+Required Properties:
+
+  - compatible: Must be "renesas,h8300-div-clock"
+
+  - clocks: Reference to the parent clocks ("extal1" and "extal2")
+
+  - #clock-cells: Must be 1
+
+  - reg: Base address and length of the divide rate selector
+
+  - renesas,width: bit width of selector
+
+Example
+---
+
+   cclk: cclk {
+   compatible = "renesas,h8300-div-clock";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xfee01b 2>;
+   renesas,width = <2>;
+   };
diff --git 
a/Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt 
b/Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
new file mode 100644
index 000..8c57ab5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
@@ -0,0 +1,27 @@
+* Renesas SH7750/51 divider clock
+
+Required Properties:
+
+  - compatible: Must be "renesas,sh7750-div-clock"
+
+  - clocks: Reference to the parent clocks (mostly PLL)
+
+  - #clock-cells: Must be 0
+
+  - reg: Base address and length of the divide rate selector
+
+  - renesas,offset: bit offset of selector
+
+  - clock-output-names: The names of the clocks.
+
+Example
+---
+
+iclk: iclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <6>;
+   clock-output-names = "ick";
+};
diff --git 
a/Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt 
b/Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
new file mode 100644
index 000..06a3d31
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
@@ -0,0 +1,26 @@
+Renesas SH7750/51 PLL clock
+
+This device is Clock multiplyer
+
+Required Properties:
+
+  - compatible: Must be "renesas,sh7750-pll-clock"
+
+  - clocks: Reference to the parent clocks
+
+  - #clock-cells: Must be 0
+
+  - renesas,mult: PLL1 multiply rate
+
+  - reg: Two rate selector (FRQCR / WDT) register address
+
+Example
+---
+
+pllclk: pllclk {
+compatible = "renesas,sh7750-pll-clock";
+clocks = <>;
+#clock-cells = <0>;
+   renesas,mult = <12>;
+reg = <0xffc0 2>, <0xffc8 4>;
+};
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 16f7d33..19b0cd3 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -202,6 +202,7 @@ source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 source "drivers/clk/samsung/Kconfig"
+source "drivers/clk/sh/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/ti/Kconfig"
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..c75d9c8 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -83,4 +83,5 @@ obj-$(CONFIG_COMMON_CLK_VERSATILE)+= versatile/
 obj-$(CONFIG_X86)  += x86/
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
-obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_SUPERH)   += sh/
diff --git a/drivers/clk/sh/Kconfig b/drivers/clk/sh/Kconfig
new file mode 100644
index 000..729850c
--- /dev/null
+++ b/drivers/clk/sh/Kconfig
@@ -0,0

[PATCH RESEND 08/12] intc: sh: Renesas Super H INTC driver

2016-04-30 Thread Yoshinori Sato 
SuperH IPR based driver.

Signed-off-by: Yoshinori Sato 
---
 .../interrupt-controller/renesas,sh7751-intc.txt   |  25 
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-renesas-shipr.c| 138 +
 4 files changed, 169 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
 create mode 100644 drivers/irqchip/irq-renesas-shipr.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
new file mode 100644
index 000..6d9bf6c
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
@@ -0,0 +1,25 @@
+DT bindings for the SH7751 interrupt controller
+
+Required properties:
+
+  - compatible: has to be "renesas,sh7751-intc".
+
+  - reg: Base address and length of interrupt controller register
+ and extend register.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+
+  - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined
+in interrupts.txt in this directory.
+
+Example
+---
+
+   shintc: interrupt-controller@ffd0 {
+   compatible = "renesas,sh7751-intc";
+   #interrupt-cells = <2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-controller;
+   reg = <0xffd0 14>, <0xfe08 128>;
+   };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3e12479..273f19d 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -244,3 +244,8 @@ config IRQ_MXS
 config MVEBU_ODMI
bool
select GENERIC_MSI_IRQ_DOMAIN
+
+config RENESAS_SH_INTC
+   def_bool y if SH_DEVICE_TREE
+   select IRQ_DOMAIN
+   select IRQ_DOMAIN_HIERARCHY
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b03cfcb..3f9fc5c 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)   += irq-pic32-evic.o
 obj-$(CONFIG_MVEBU_ODMI)   += irq-mvebu-odmi.o
+obj-$(CONFIG_RENESAS_SH_INTC)  += irq-renesas-shipr.o irq-io-landisk.o
diff --git a/drivers/irqchip/irq-renesas-shipr.c 
b/drivers/irqchip/irq-renesas-shipr.c
new file mode 100644
index 000..67cce6a
--- /dev/null
+++ b/drivers/irqchip/irq-renesas-shipr.c
@@ -0,0 +1,138 @@
+/*
+ * SH IPR-INTC interrupt contoller driver
+ *
+ * Copyright 2016 Yoshinori Sato 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct sh7751_intc_regs {
+   void *icr;
+   void *ipr;
+   void *intpri00;
+   void *intreq00;
+   void *intmsk00;
+   void *intmskclr00;
+} sh7751_regs;
+
+static const unsigned int ipr_table[] = {
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0 - 7 */
+   0x41, 0xff, 0xff, 0x40, 0xff, 0xff, 0xff, 0xff, /* 8 - 15 */
+   0x03, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00, 0x11, /* 16 - 23 */
+   0x11, 0x11, 0x11, 0x13, 0x12, 0x12, 0xff, 0xff, /* 24 - 31 */
+   0x30, 0x33, 0x32, 0x32, 0x32, 0x32, 0x32, 0x21, /* 32 - 39 */
+   0x21, 0x21, 0x21, 0x21, 0x32, 0x32, 0x32, 0x32, /* 40 - 47 */
+   0xff, 0xff, 0xff, 0x40, 0xff, 0xff, 0xff, 0xff, /* 48 - 55 */
+   0xff, 0xff, 0xff, 0x40, 0xff, 0xff, 0xff, 0xff, /* 56 - 63 */
+};
+
+static const unsigned int pri_table[] = {
+   0, 4, 4, 4, 4, 4, 4, 4,
+   8, 32, 32, 32, 12, 32, 32, 32,
+};
+
+static void sh_disable_irq(struct irq_data *data)
+{
+   int pos;
+   unsigned int addr;
+   unsigned long pri;
+   int irq = data->irq;
+   struct sh7751_intc_regs *reg = data->chip_data;
+
+   if (irq < 64) {
+   if (ipr_table[irq] != 0xff) {
+   addr = (ipr_table[irq] & 0xf0) >> 2;
+   pos = (ipr_table[irq] & 0x0f) << 4;
+   pri = ~(0x000f << pos);
+   pri &= __raw_readw(reg->ipr + addr);
+   __raw_writew(pri, reg->ipr + addr);
+   }
+   } else {
+   if (pri_table[irq - 64] < 32) {
+   pos = pri_table[irq - 64];
+   pri = ~(0x000f << pos);
+   pri &= __raw_readw(reg->intpri00);
+   __raw_writew(pri, reg->intpri00);
+   }
+   }
+}
+
+static void sh_enable_irq(struct irq_data *data)
+{
+   int pos;
+   unsigned int addr;
+   unsigned long pri;
+   int irq = data->irq;
+   struct sh7751_intc_regs *reg = data->chip_data;
+
+   if (irq < 64) {
+   if (ipr_table[irq] != 0xff) {
+   addr =

[PATCH RESEND 06/12] clk: sh: SH7750/51 PLL and divider clock driver

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 .../bindings/clock/renesas,sh-div-clock.txt|  24 ++
 .../bindings/clock/renesas,sh7750-div-clock.txt|  27 ++
 .../bindings/clock/renesas,sh7750-pll-clock.txt|  26 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   3 +-
 drivers/clk/sh/Kconfig |   5 +
 drivers/clk/sh/Makefile|   2 +
 drivers/clk/sh/clk-sh7750.c| 223 ++
 drivers/clk/sh/clk-shdiv.c | 338 +
 9 files changed, 648 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
 create mode 100644 drivers/clk/sh/Kconfig
 create mode 100644 drivers/clk/sh/Makefile
 create mode 100644 drivers/clk/sh/clk-sh7750.c
 create mode 100644 drivers/clk/sh/clk-shdiv.c

diff --git a/Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt 
b/Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
new file mode 100644
index 000..399e0da
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
@@ -0,0 +1,24 @@
+* Renesas H8/300 divider clock
+
+Required Properties:
+
+  - compatible: Must be "renesas,h8300-div-clock"
+
+  - clocks: Reference to the parent clocks ("extal1" and "extal2")
+
+  - #clock-cells: Must be 1
+
+  - reg: Base address and length of the divide rate selector
+
+  - renesas,width: bit width of selector
+
+Example
+---
+
+   cclk: cclk {
+   compatible = "renesas,h8300-div-clock";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xfee01b 2>;
+   renesas,width = <2>;
+   };
diff --git 
a/Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt 
b/Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
new file mode 100644
index 000..8c57ab5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
@@ -0,0 +1,27 @@
+* Renesas SH7750/51 divider clock
+
+Required Properties:
+
+  - compatible: Must be "renesas,sh7750-div-clock"
+
+  - clocks: Reference to the parent clocks (mostly PLL)
+
+  - #clock-cells: Must be 0
+
+  - reg: Base address and length of the divide rate selector
+
+  - renesas,offset: bit offset of selector
+
+  - clock-output-names: The names of the clocks.
+
+Example
+---
+
+iclk: iclk {
+compatible = "renesas,sh7750-div-clock";
+clocks = <>;
+#clock-cells = <0>;
+reg = <0xffc0 2>;
+   renesas,offset = <6>;
+   clock-output-names = "ick";
+};
diff --git 
a/Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt 
b/Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
new file mode 100644
index 000..06a3d31
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
@@ -0,0 +1,26 @@
+Renesas SH7750/51 PLL clock
+
+This device is Clock multiplyer
+
+Required Properties:
+
+  - compatible: Must be "renesas,sh7750-pll-clock"
+
+  - clocks: Reference to the parent clocks
+
+  - #clock-cells: Must be 0
+
+  - renesas,mult: PLL1 multiply rate
+
+  - reg: Two rate selector (FRQCR / WDT) register address
+
+Example
+---
+
+pllclk: pllclk {
+compatible = "renesas,sh7750-pll-clock";
+clocks = <>;
+#clock-cells = <0>;
+   renesas,mult = <12>;
+reg = <0xffc0 2>, <0xffc8 4>;
+};
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 16f7d33..19b0cd3 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -202,6 +202,7 @@ source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 source "drivers/clk/samsung/Kconfig"
+source "drivers/clk/sh/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/ti/Kconfig"
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..c75d9c8 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -83,4 +83,5 @@ obj-$(CONFIG_COMMON_CLK_VERSATILE)+= versatile/
 obj-$(CONFIG_X86)  += x86/
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
-obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_SUPERH)   += sh/
diff --git a/drivers/clk/sh/Kconfig b/drivers/clk/sh/Kconfig
new file mode 100644
index 000..729850c
--- /dev/null
+++ b/drivers/clk/sh/Kconfig
@@ -0,0 +1,5 @@
+config

[PATCH RESEND 12/12] of: Add sh support

2016-04-30 Thread Yoshinori Sato 
sh fdt access in VA. But memory reservation use PA.
So sh need convert to PA.

Signed-off-by: Yoshinori Sato 
---
 drivers/of/fdt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 3349d2a..fb357be 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -593,6 +593,9 @@ void __init early_init_fdt_scan_reserved_mem(void)
fdt_get_mem_rsv(initial_boot_params, n, , );
if (!size)
break;
+#ifdef CONFIG_SUPERH
+   base = virt_to_phys(base);
+#endif
early_init_dt_reserve_memory_arch(base, size, 0);
}
 
-- 
2.7.0

[PATCH RESEND 05/12] sh: DeviceTree support update

2016-04-30 Thread Yoshinori Sato 
Changes bellow
- FDT setup timing fix.
- chosen/bootargs support.
- zImage support.
- DT binding helper macro.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boards/of-generic.c| 23 +++---
 arch/sh/boot/compressed/head_32.S  |  5 +++--
 arch/sh/boot/dts/include/dt-bindings   |  1 +
 arch/sh/kernel/setup.c | 19 ++
 include/dt-bindings/interrupt-controller/sh_intc.h |  2 ++
 5 files changed, 36 insertions(+), 14 deletions(-)
 create mode 12 arch/sh/boot/dts/include/dt-bindings
 create mode 100644 include/dt-bindings/interrupt-controller/sh_intc.h

diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
index bf3a166..9570873 100644
--- a/arch/sh/boards/of-generic.c
+++ b/arch/sh/boards/of-generic.c
@@ -112,29 +112,25 @@ static int noopi(void)
return 0;
 }
 
-static void __init sh_of_mem_reserve(void)
+static void __init sh_of_mem_init(void)
 {
early_init_fdt_reserve_self();
early_init_fdt_scan_reserved_mem();
 }
 
-static void __init sh_of_time_init(void)
-{
-   pr_info("SH generic board support: scanning for clocksource devices\n");
-   clocksource_probe();
-}
-
 static void __init sh_of_setup(char **cmdline_p)
 {
-   unflatten_device_tree();
-
-   board_time_init = sh_of_time_init;
+   struct device_node *cpu;
+   int freq;
 
sh_mv.mv_name = of_flat_dt_get_machine_name();
if (!sh_mv.mv_name)
sh_mv.mv_name = "Unknown SH model";
 
sh_of_smp_probe();
+   cpu = of_find_node_by_name(NULL, "cpu");
+   if (!of_property_read_u32(cpu, "clock-frequency", ))
+   preset_lpj = freq / 500;
 }
 
 static int sh_of_irq_demux(int irq)
@@ -167,8 +163,7 @@ static struct sh_machine_vector __initmv sh_of_generic_mv = 
{
.mv_init_irq= sh_of_init_irq,
.mv_clk_init= sh_of_clk_init,
.mv_mode_pins   = noopi,
-   .mv_mem_init= noop,
-   .mv_mem_reserve = sh_of_mem_reserve,
+   .mv_mem_init= sh_of_mem_init,
 };
 
 struct sh_clk_ops;
@@ -194,3 +189,7 @@ static int __init sh_of_device_init(void)
return 0;
 }
 arch_initcall_sync(sh_of_device_init);
+
+void intc_finalize(void)
+{
+}
diff --git a/arch/sh/boot/compressed/head_32.S 
b/arch/sh/boot/compressed/head_32.S
index 3e15032..cd34377 100644
--- a/arch/sh/boot/compressed/head_32.S
+++ b/arch/sh/boot/compressed/head_32.S
@@ -14,7 +14,8 @@ startup:
/* Load initial status register */
mov.l   init_sr, r1
ldc r1, sr
-
+   /* Save FDT address */
+   mov r4, r13
/* Move myself to proper location if necessary */
mova1f, r0
mov.l   1f, r2
@@ -83,7 +84,7 @@ l1:
/* Jump to the start of the decompressed kernel */
mov.l   kernel_start_addr, r0
jmp @r0
-   nop
+ mov   r13,r4

.align  2
 bss_start_addr:
diff --git a/arch/sh/boot/dts/include/dt-bindings 
b/arch/sh/boot/dts/include/dt-bindings
new file mode 12
index 000..08c00e4
--- /dev/null
+++ b/arch/sh/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 5d34605..f6bb105 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -177,7 +177,12 @@ disable:
 #ifndef CONFIG_GENERIC_CALIBRATE_DELAY
 void calibrate_delay(void)
 {
+#ifndef CONFIG_OF
struct clk *clk = clk_get(NULL, "cpu_clk");
+#else
+   struct device_node *cpu = of_find_node_by_name(NULL, "cpu");
+   struct clk *clk = of_clk_get_by_name(cpu, NULL);
+#endif
 
if (IS_ERR(clk))
panic("Need a sane CPU clock definition!");
@@ -251,7 +256,11 @@ void __ref sh_fdt_init(phys_addr_t dt_phys)
/* Avoid calling an __init function on secondary cpus. */
if (done) return;
 
+#ifdef CONFIG_USE_BUILTIN_DTB
+   dt_virt = __dtb_start;
+#else
dt_virt = phys_to_virt(dt_phys);
+#endif
 
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("Error: invalid device tree blob"
@@ -267,8 +276,13 @@ void __ref sh_fdt_init(phys_addr_t dt_phys)
 
 void __init setup_arch(char **cmdline_p)
 {
+#ifdef CONFIG_OF
+   unflatten_device_tree();
+#endif
enable_mmu();
 
+
+#ifndef CONFIG_OF
ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
 
printk(KERN_NOTICE "Boot params:\n"
@@ -290,6 +304,7 @@ void __init setup_arch(char **cmdline_p)
 
if (!MOUNT_ROOT_RDONLY)
root_mountflags &= ~MS_RDONLY;
+#endif
init_mm.start_code = (unsigned long) _text;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
@@ -312,9 +327,13 @@ void __init setup_arch(char **cmdline_p)
 #endif
 #endif
 
+#if !defined(CONFIG_OF) || defined(USE_BUILTIN_DTB)
/* Save unparsed command

[PATCH RESEND 07/12] pci: sh: SH7751 PCI host bridge driver

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 .../devicetree/bindings/pci/sh7751-pci.txt |  51 
 drivers/pci/host/Kconfig   |   7 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pci-sh7751.c  | 321 +
 drivers/pci/host/pci-sh7751.h  | 269 +
 5 files changed, 649 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/sh7751-pci.txt
 create mode 100644 drivers/pci/host/pci-sh7751.c
 create mode 100644 drivers/pci/host/pci-sh7751.h

diff --git a/Documentation/devicetree/bindings/pci/sh7751-pci.txt 
b/Documentation/devicetree/bindings/pci/sh7751-pci.txt
new file mode 100644
index 000..45b5152
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/sh7751-pci.txt
@@ -0,0 +1,51 @@
+* Renesas SH7751 PCI host interfaces
+
+Required properties:
+  - compatible: "renesas,sh7751-pci" is required.
+And board specific compatible if fixup required.
+
+  - reg: base address and length of the pcie controller registers.
+  - #address-cells: set to <2>
+  - #size-cells: set to <1>
+  - bus-range: PCI bus numbers covered
+  - device_type: set to "pci"
+  - ranges: ranges for the PCI memory and I/O regions.
+  - interrupt-map-mask and interrupt-map: standard PCI properties
+   to define the mapping of the PCIe interface to interrupt
+   numbers.
+
+Example:
+   pci: pci-controller@fe20 {
+   compatible = "renesas,sh7751-pci", "iodata,landisk";
+   device_type = "pci";
+   bus-range = <0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0x0200 0x 0xfd00 0xfd00 
0x 0x0100>,
+<0x0100 0x 0xfe24 0x 
0x 0x0004>;
+   reg = <0xfe20 0x0400>,
+ <0x0c00 0x0400>,
+ <0xff80 0x0030>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0x1800 0 7>;
+   interrupt-map = <0x 0 1  evt2irq(0x2a0) 0
+0x 0 2  evt2irq(0x2c0) 0
+0x 0 3  evt2irq(0x2e0) 0
+0x 0 4  evt2irq(0x300) 0
+
+0x0800 0 1  evt2irq(0x2c0) 0
+0x0800 0 2  evt2irq(0x2e0) 0
+0x0800 0 3  evt2irq(0x300) 0
+0x0800 0 4  evt2irq(0x2a0) 0
+
+0x1000 0 1  evt2irq(0x2e0) 0
+0x1000 0 2  evt2irq(0x300) 0
+0x1000 0 3  evt2irq(0x2a0) 0
+0x1000 0 4  evt2irq(0x2c0) 0
+
+0x1800 0 1  evt2irq(0x300) 0
+0x1800 0 2  evt2irq(0x2a0) 0
+0x1800 0 3  evt2irq(0x2c0) 0
+0x1800 0 4  evt2irq(0x2e0) 0>;
+   };
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 7a0780d..a8596db 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -231,4 +231,11 @@ config PCI_HOST_THUNDER_ECAM
help
  Say Y here if you want ECAM support for CN88XX-Pass-1.x Cavium 
Thunder SoCs.
 
+config PCI_SH7751
+   bool "Renesas SH7751 On-Chip PCI controller"
+   depends on OF && SUPERH
+   select PCI_HOST_COMMON
+   help
+ Say Y here if you want PCI support on SH7751.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index d85b5fa..91268cb 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
+obj-$(CONFIG_PCI_SH7751) += pci-sh7751.o
diff --git a/drivers/pci/host/pci-sh7751.c b/drivers/pci/host/pci-sh7751.c
new file mode 100644
index 000..fd6548b
--- /dev/null
+++ b/drivers/pci/host/pci-sh7751.c
@@ -0,0 +1,321 @@
+/*
+ * SH7751 PCI driver
+ * Copyright (C) 2016 Yoshinori Sato
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pci-host-common.h"
+#include "pci-sh7751.h"
+
+#define pcic_writel(val, reg) __raw_writel(val, pci_reg_base + (reg))
+#define pcic_readl(reg) __raw_readl(pci_reg_base + (reg))
+
+unsigned long PCIBIOS_MIN_IO;
+unsigned long PCIBIOS_MIN_MEM;
+DEFINE_RAW_SPINLOCK(pci_config_lock);
+
+/*
+ * PCIC fixups
+ */
+
+static __initconst const struct fixups {
+   char *compatible;
+   void (*fixup)(void __iomem *, void __iomem *);
+} fixup_list[] = {
+};
+
+static __init void pcic_fixups(struct device_node *np,
+  void __iomem *pcic, void

[PATCH RESEND 12/12] of: Add sh support

2016-04-30 Thread Yoshinori Sato 
sh fdt access in VA. But memory reservation use PA.
So sh need convert to PA.

Signed-off-by: Yoshinori Sato 
---
 drivers/of/fdt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 3349d2a..fb357be 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -593,6 +593,9 @@ void __init early_init_fdt_scan_reserved_mem(void)
fdt_get_mem_rsv(initial_boot_params, n, , );
if (!size)
break;
+#ifdef CONFIG_SUPERH
+   base = virt_to_phys(base);
+#endif
early_init_dt_reserve_memory_arch(base, size, 0);
}
 
-- 
2.7.0

[PATCH RESEND 05/12] sh: DeviceTree support update

2016-04-30 Thread Yoshinori Sato 
Changes bellow
- FDT setup timing fix.
- chosen/bootargs support.
- zImage support.
- DT binding helper macro.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boards/of-generic.c| 23 +++---
 arch/sh/boot/compressed/head_32.S  |  5 +++--
 arch/sh/boot/dts/include/dt-bindings   |  1 +
 arch/sh/kernel/setup.c | 19 ++
 include/dt-bindings/interrupt-controller/sh_intc.h |  2 ++
 5 files changed, 36 insertions(+), 14 deletions(-)
 create mode 12 arch/sh/boot/dts/include/dt-bindings
 create mode 100644 include/dt-bindings/interrupt-controller/sh_intc.h

diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
index bf3a166..9570873 100644
--- a/arch/sh/boards/of-generic.c
+++ b/arch/sh/boards/of-generic.c
@@ -112,29 +112,25 @@ static int noopi(void)
return 0;
 }
 
-static void __init sh_of_mem_reserve(void)
+static void __init sh_of_mem_init(void)
 {
early_init_fdt_reserve_self();
early_init_fdt_scan_reserved_mem();
 }
 
-static void __init sh_of_time_init(void)
-{
-   pr_info("SH generic board support: scanning for clocksource devices\n");
-   clocksource_probe();
-}
-
 static void __init sh_of_setup(char **cmdline_p)
 {
-   unflatten_device_tree();
-
-   board_time_init = sh_of_time_init;
+   struct device_node *cpu;
+   int freq;
 
sh_mv.mv_name = of_flat_dt_get_machine_name();
if (!sh_mv.mv_name)
sh_mv.mv_name = "Unknown SH model";
 
sh_of_smp_probe();
+   cpu = of_find_node_by_name(NULL, "cpu");
+   if (!of_property_read_u32(cpu, "clock-frequency", ))
+   preset_lpj = freq / 500;
 }
 
 static int sh_of_irq_demux(int irq)
@@ -167,8 +163,7 @@ static struct sh_machine_vector __initmv sh_of_generic_mv = 
{
.mv_init_irq= sh_of_init_irq,
.mv_clk_init= sh_of_clk_init,
.mv_mode_pins   = noopi,
-   .mv_mem_init= noop,
-   .mv_mem_reserve = sh_of_mem_reserve,
+   .mv_mem_init= sh_of_mem_init,
 };
 
 struct sh_clk_ops;
@@ -194,3 +189,7 @@ static int __init sh_of_device_init(void)
return 0;
 }
 arch_initcall_sync(sh_of_device_init);
+
+void intc_finalize(void)
+{
+}
diff --git a/arch/sh/boot/compressed/head_32.S 
b/arch/sh/boot/compressed/head_32.S
index 3e15032..cd34377 100644
--- a/arch/sh/boot/compressed/head_32.S
+++ b/arch/sh/boot/compressed/head_32.S
@@ -14,7 +14,8 @@ startup:
/* Load initial status register */
mov.l   init_sr, r1
ldc r1, sr
-
+   /* Save FDT address */
+   mov r4, r13
/* Move myself to proper location if necessary */
mova1f, r0
mov.l   1f, r2
@@ -83,7 +84,7 @@ l1:
/* Jump to the start of the decompressed kernel */
mov.l   kernel_start_addr, r0
jmp @r0
-   nop
+ mov   r13,r4

.align  2
 bss_start_addr:
diff --git a/arch/sh/boot/dts/include/dt-bindings 
b/arch/sh/boot/dts/include/dt-bindings
new file mode 12
index 000..08c00e4
--- /dev/null
+++ b/arch/sh/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 5d34605..f6bb105 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -177,7 +177,12 @@ disable:
 #ifndef CONFIG_GENERIC_CALIBRATE_DELAY
 void calibrate_delay(void)
 {
+#ifndef CONFIG_OF
struct clk *clk = clk_get(NULL, "cpu_clk");
+#else
+   struct device_node *cpu = of_find_node_by_name(NULL, "cpu");
+   struct clk *clk = of_clk_get_by_name(cpu, NULL);
+#endif
 
if (IS_ERR(clk))
panic("Need a sane CPU clock definition!");
@@ -251,7 +256,11 @@ void __ref sh_fdt_init(phys_addr_t dt_phys)
/* Avoid calling an __init function on secondary cpus. */
if (done) return;
 
+#ifdef CONFIG_USE_BUILTIN_DTB
+   dt_virt = __dtb_start;
+#else
dt_virt = phys_to_virt(dt_phys);
+#endif
 
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("Error: invalid device tree blob"
@@ -267,8 +276,13 @@ void __ref sh_fdt_init(phys_addr_t dt_phys)
 
 void __init setup_arch(char **cmdline_p)
 {
+#ifdef CONFIG_OF
+   unflatten_device_tree();
+#endif
enable_mmu();
 
+
+#ifndef CONFIG_OF
ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
 
printk(KERN_NOTICE "Boot params:\n"
@@ -290,6 +304,7 @@ void __init setup_arch(char **cmdline_p)
 
if (!MOUNT_ROOT_RDONLY)
root_mountflags &= ~MS_RDONLY;
+#endif
init_mm.start_code = (unsigned long) _text;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
@@ -312,9 +327,13 @@ void __init setup_arch(char **cmdline_p)
 #endif
 #endif
 
+#if !defined(CONFIG_OF) || defined(USE_BUILTIN_DTB)
/* Save unparsed command line copy for /proc/cmdline

[PATCH RESEND 07/12] pci: sh: SH7751 PCI host bridge driver

2016-04-30 Thread Yoshinori Sato 
Signed-off-by: Yoshinori Sato 
---
 .../devicetree/bindings/pci/sh7751-pci.txt |  51 
 drivers/pci/host/Kconfig   |   7 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pci-sh7751.c  | 321 +
 drivers/pci/host/pci-sh7751.h  | 269 +
 5 files changed, 649 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/sh7751-pci.txt
 create mode 100644 drivers/pci/host/pci-sh7751.c
 create mode 100644 drivers/pci/host/pci-sh7751.h

diff --git a/Documentation/devicetree/bindings/pci/sh7751-pci.txt 
b/Documentation/devicetree/bindings/pci/sh7751-pci.txt
new file mode 100644
index 000..45b5152
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/sh7751-pci.txt
@@ -0,0 +1,51 @@
+* Renesas SH7751 PCI host interfaces
+
+Required properties:
+  - compatible: "renesas,sh7751-pci" is required.
+And board specific compatible if fixup required.
+
+  - reg: base address and length of the pcie controller registers.
+  - #address-cells: set to <2>
+  - #size-cells: set to <1>
+  - bus-range: PCI bus numbers covered
+  - device_type: set to "pci"
+  - ranges: ranges for the PCI memory and I/O regions.
+  - interrupt-map-mask and interrupt-map: standard PCI properties
+   to define the mapping of the PCIe interface to interrupt
+   numbers.
+
+Example:
+   pci: pci-controller@fe20 {
+   compatible = "renesas,sh7751-pci", "iodata,landisk";
+   device_type = "pci";
+   bus-range = <0 0>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0x0200 0x 0xfd00 0xfd00 
0x 0x0100>,
+<0x0100 0x 0xfe24 0x 
0x 0x0004>;
+   reg = <0xfe20 0x0400>,
+ <0x0c00 0x0400>,
+ <0xff80 0x0030>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0x1800 0 7>;
+   interrupt-map = <0x 0 1  evt2irq(0x2a0) 0
+0x 0 2  evt2irq(0x2c0) 0
+0x 0 3  evt2irq(0x2e0) 0
+0x 0 4  evt2irq(0x300) 0
+
+0x0800 0 1  evt2irq(0x2c0) 0
+0x0800 0 2  evt2irq(0x2e0) 0
+0x0800 0 3  evt2irq(0x300) 0
+0x0800 0 4  evt2irq(0x2a0) 0
+
+0x1000 0 1  evt2irq(0x2e0) 0
+0x1000 0 2  evt2irq(0x300) 0
+0x1000 0 3  evt2irq(0x2a0) 0
+0x1000 0 4  evt2irq(0x2c0) 0
+
+0x1800 0 1  evt2irq(0x300) 0
+0x1800 0 2  evt2irq(0x2a0) 0
+0x1800 0 3  evt2irq(0x2c0) 0
+0x1800 0 4  evt2irq(0x2e0) 0>;
+   };
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 7a0780d..a8596db 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -231,4 +231,11 @@ config PCI_HOST_THUNDER_ECAM
help
  Say Y here if you want ECAM support for CN88XX-Pass-1.x Cavium 
Thunder SoCs.
 
+config PCI_SH7751
+   bool "Renesas SH7751 On-Chip PCI controller"
+   depends on OF && SUPERH
+   select PCI_HOST_COMMON
+   help
+ Say Y here if you want PCI support on SH7751.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index d85b5fa..91268cb 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
+obj-$(CONFIG_PCI_SH7751) += pci-sh7751.o
diff --git a/drivers/pci/host/pci-sh7751.c b/drivers/pci/host/pci-sh7751.c
new file mode 100644
index 000..fd6548b
--- /dev/null
+++ b/drivers/pci/host/pci-sh7751.c
@@ -0,0 +1,321 @@
+/*
+ * SH7751 PCI driver
+ * Copyright (C) 2016 Yoshinori Sato
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pci-host-common.h"
+#include "pci-sh7751.h"
+
+#define pcic_writel(val, reg) __raw_writel(val, pci_reg_base + (reg))
+#define pcic_readl(reg) __raw_readl(pci_reg_base + (reg))
+
+unsigned long PCIBIOS_MIN_IO;
+unsigned long PCIBIOS_MIN_MEM;
+DEFINE_RAW_SPINLOCK(pci_config_lock);
+
+/*
+ * PCIC fixups
+ */
+
+static __initconst const struct fixups {
+   char *compatible;
+   void (*fixup)(void __iomem *, void __iomem *);
+} fixup_list[] = {
+};
+
+static __init void pcic_fixups(struct device_node *np,
+  void __iomem *pcic, void __iomem *bcr)
+{
+

[PATCH RESEND 02/12] sh: Config update for OF mode

2016-04-30 Thread Yoshinori Sato 
DeviceTreee support is use liner IRQ.
And use generic function (clock / io / IRQ).

Signed-off-by: Yoshinori Sato 
---
 arch/sh/Kconfig | 26 +++---
 arch/sh/boards/Kconfig  |  4 
 arch/sh/drivers/Makefile|  2 ++
 arch/sh/include/asm/io.h|  6 ++
 arch/sh/kernel/cpu/Makefile |  8 ++--
 arch/sh/kernel/cpu/clock.c  |  9 ++---
 drivers/sh/Makefile |  2 ++
 7 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 7ed20fc..d4177ba 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -28,7 +28,7 @@ config SUPERH
select ARCH_WANT_IPC_PARSE_VERSION
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_REGS_AND_STACK_ACCESS_API
-   select MAY_HAVE_SPARSE_IRQ
+   select MAY_HAVE_SPARSE_IRQ if !SH_DEVICE_TREE
select IRQ_FORCED_THREADING
select RTC_LIB
select GENERIC_ATOMIC64
@@ -66,7 +66,7 @@ config SUPERH32
select HAVE_MIXED_BREAKPOINTS_REGS
select PERF_EVENTS
select ARCH_HIBERNATION_POSSIBLE if MMU
-   select SPARSE_IRQ
+   select SPARSE_IRQ if !SH_DEVICE_TREE
select HAVE_CC_STACKPROTECTOR
 
 config SUPERH64
@@ -745,6 +745,26 @@ endmenu
 
 menu "Boot options"
 
+config USE_BUILTIN_DTB
+   bool "Use builtin DTB"
+   default n
+   depends on SH_DEVICE_TREE
+   help
+ Link a device tree blob for particular hardware into the kernel,
+ suppressing use of the DTB pointer provided by the bootloader.
+ This option should only be used with legacy bootloaders that are
+ not capable of providing a DTB to the kernel, or for experimental
+ hardware without stable device tree bindings.
+
+config BUILTIN_DTB_SOURCE
+   string "Source file for builtin DTB"
+   default ""
+   depends on USE_BUILTIN_DTB
+   help
+ Base name (without suffix, relative to arch/sh/boot/dts) for the
+ a DTS file that will be used to produce the DTB linked into the
+ kernel.
+
 config ZERO_PAGE_OFFSET
hex
default "0x0001" if PAGE_SIZE_64KB || SH_RTS7751R2D || \
@@ -839,7 +859,7 @@ config PCI
depends on SYS_SUPPORTS_PCI
select PCI_DOMAINS
select GENERIC_PCI_IOMAP
-   select NO_GENERIC_PCI_IOPORT_MAP
+   select NO_GENERIC_PCI_IOPORT_MAP if !SH_DEVICE_TREE
help
  Find out whether you have a PCI motherboard. PCI is the name of a
  bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
index 5e52d53..98f884e 100644
--- a/arch/sh/boards/Kconfig
+++ b/arch/sh/boards/Kconfig
@@ -12,6 +12,10 @@ config SH_DEVICE_TREE
select OF_EARLY_FLATTREE
select CLKSRC_OF
select GENERIC_CALIBRATE_DELAY
+   select COMMON_CLK
+   select GENERIC_IOMAP
+   select GENERIC_IRQ_CHIP
+   select SYS_SUPPORTS_PCI
help
  Select Board Described by Device Tree to build a kernel that
  does not hard-code any board-specific knowledge but instead uses
diff --git a/arch/sh/drivers/Makefile b/arch/sh/drivers/Makefile
index e13f06b..382e86f 100644
--- a/arch/sh/drivers/Makefile
+++ b/arch/sh/drivers/Makefile
@@ -4,7 +4,9 @@
 
 obj-y  += dma/
 
+ifndef CONFIG_SH_DEVICE_TREE
 obj-$(CONFIG_PCI)  += pci/
+endif
 obj-$(CONFIG_SUPERHYWAY)   += superhyway/
 obj-$(CONFIG_PUSH_SWITCH)  += push-switch.o
 obj-$(CONFIG_HEARTBEAT)+= heartbeat.o
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 3280a6b..df62a9f 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -387,6 +387,12 @@ static inline int iounmap_fixed(void __iomem *addr) { 
return -EINVAL; }
 int valid_phys_addr_range(phys_addr_t addr, size_t size);
 int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
 
+#define PCI_IOBASE 0xfe24UL
+
+#define HAVE_ARCH_PIO_SIZE
+#define PIO_OFFSET PCI_IOBASE
+#define PIO_MASK   0x3UL
+#define PIO_RESERVED   0x4UL
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_SH_IO_H */
diff --git a/arch/sh/kernel/cpu/Makefile b/arch/sh/kernel/cpu/Makefile
index accc7ca..22ad0ee 100644
--- a/arch/sh/kernel/cpu/Makefile
+++ b/arch/sh/kernel/cpu/Makefile
@@ -16,6 +16,10 @@ obj-$(CONFIG_ARCH_SHMOBILE)  += shmobile/
 # Common interfaces.
 
 obj-$(CONFIG_SH_ADC)   += adc.o
+ifndef CONFIG_COMMON_CLK
 obj-$(CONFIG_SH_CLK_CPG_LEGACY)+= clock-cpg.o
-
-obj-y  += irq/ init.o clock.o fpu.o pfc.o proc.o
+endif
+ifndef CONFIG_GENERIC_IRQ_CHIP
+obj-y  += irq/
+endif
+obj-y  += init.o clock.o fpu.o pfc.o proc.o
diff --git a/arch/sh/kernel/cpu/clock.c b/arch/sh/kernel/cpu/clock.c
index 4187cf4..856a05c 100644
--- a/arch/sh/kernel/cpu/clock.c
+++ b/arch/sh/kernel/cpu/clock.c
@@ -17,19 +17,21 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 int __init clk_init(void)
 {
-

[PATCH RESEND 00/12] SH: landisk convert to devicetree

2016-04-30 Thread Yoshinori Sato 
SH get devicetree support. But it not working on existing H/W.

IO-DATA HDL-U (aka landisk) currentry supported.
This H/W like SH7751 evalution board. It's a best to use this as a
change base H/W.

Yoshinori Sato (12):
  sh: Fix typo
  sh: Config update for OF mode
  sh: Disable board specific code in OF mode
  sh: Drop CPU specific setup on OF mode
  sh: DeviceTree support update
  clk: sh: SH7750/51 PLL and divider clock driver
  pci: sh: SH7751 PCI host bridge driver
  intc: sh: Renesas Super H INTC driver
  sh: Add I/O DATA HDL-U support drivers.
  sh: I/O DATA HDL-U (aka landisk) support dts
  sh: I/O DATA HDL-U defconfig (DT mode)
  of: Add sh support

 .../bindings/clock/renesas,sh-div-clock.txt|  24 ++
 .../bindings/clock/renesas,sh7750-div-clock.txt|  27 ++
 .../bindings/clock/renesas,sh7750-pll-clock.txt|  26 ++
 .../interrupt-controller/iodata-landisk.txt|  28 ++
 .../interrupt-controller/renesas,sh7751-intc.txt   |  25 ++
 .../devicetree/bindings/pci/sh7751-pci.txt |  51 +++
 arch/sh/Kconfig|  26 +-
 arch/sh/Makefile   |  11 +
 arch/sh/boards/Kconfig |   4 +
 arch/sh/boards/of-generic.c|  23 +-
 arch/sh/boot/compressed/head_32.S  |   5 +-
 arch/sh/boot/dts/include/dt-bindings   |   1 +
 arch/sh/boot/dts/landisk.dts   | 150 +
 arch/sh/configs/landisk-dt_defconfig   | 100 ++
 arch/sh/drivers/Makefile   |   2 +
 arch/sh/include/asm/io.h   |   6 +
 arch/sh/kernel/cpu/Makefile|   8 +-
 arch/sh/kernel/cpu/clock.c |   9 +-
 arch/sh/kernel/cpu/sh4/Makefile|   2 +
 arch/sh/kernel/head_32.S   |   2 +-
 arch/sh/kernel/setup.c |  19 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   3 +-
 drivers/clk/sh/Kconfig |   5 +
 drivers/clk/sh/Makefile|   2 +
 drivers/clk/sh/clk-sh7750.c| 223 +
 drivers/clk/sh/clk-shdiv.c | 338 
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-io-landisk.c   |  71 +
 drivers/irqchip/irq-renesas-shipr.c| 138 
 drivers/of/fdt.c   |   3 +
 drivers/pci/host/Kconfig   |   7 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pci-sh7751.c  | 346 +
 drivers/pci/host/pci-sh7751.h  | 269 
 drivers/sh/Makefile|   2 +
 include/dt-bindings/interrupt-controller/sh_intc.h |   2 +
 38 files changed, 1942 insertions(+), 24 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
 create mode 100644 Documentation/devicetree/bindings/pci/sh7751-pci.txt
 create mode 12 arch/sh/boot/dts/include/dt-bindings
 create mode 100644 arch/sh/boot/dts/landisk.dts
 create mode 100644 arch/sh/configs/landisk-dt_defconfig
 create mode 100644 drivers/clk/sh/Kconfig
 create mode 100644 drivers/clk/sh/Makefile
 create mode 100644 drivers/clk/sh/clk-sh7750.c
 create mode 100644 drivers/clk/sh/clk-shdiv.c
 create mode 100644 drivers/irqchip/irq-io-landisk.c
 create mode 100644 drivers/irqchip/irq-renesas-shipr.c
 create mode 100644 drivers/pci/host/pci-sh7751.c
 create mode 100644 drivers/pci/host/pci-sh7751.h
 create mode 100644 include/dt-bindings/interrupt-controller/sh_intc.h

-- 
2.7.0

[PATCH RESEND 02/12] sh: Config update for OF mode

2016-04-30 Thread Yoshinori Sato 
DeviceTreee support is use liner IRQ.
And use generic function (clock / io / IRQ).

Signed-off-by: Yoshinori Sato 
---
 arch/sh/Kconfig | 26 +++---
 arch/sh/boards/Kconfig  |  4 
 arch/sh/drivers/Makefile|  2 ++
 arch/sh/include/asm/io.h|  6 ++
 arch/sh/kernel/cpu/Makefile |  8 ++--
 arch/sh/kernel/cpu/clock.c  |  9 ++---
 drivers/sh/Makefile |  2 ++
 7 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 7ed20fc..d4177ba 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -28,7 +28,7 @@ config SUPERH
select ARCH_WANT_IPC_PARSE_VERSION
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_REGS_AND_STACK_ACCESS_API
-   select MAY_HAVE_SPARSE_IRQ
+   select MAY_HAVE_SPARSE_IRQ if !SH_DEVICE_TREE
select IRQ_FORCED_THREADING
select RTC_LIB
select GENERIC_ATOMIC64
@@ -66,7 +66,7 @@ config SUPERH32
select HAVE_MIXED_BREAKPOINTS_REGS
select PERF_EVENTS
select ARCH_HIBERNATION_POSSIBLE if MMU
-   select SPARSE_IRQ
+   select SPARSE_IRQ if !SH_DEVICE_TREE
select HAVE_CC_STACKPROTECTOR
 
 config SUPERH64
@@ -745,6 +745,26 @@ endmenu
 
 menu "Boot options"
 
+config USE_BUILTIN_DTB
+   bool "Use builtin DTB"
+   default n
+   depends on SH_DEVICE_TREE
+   help
+ Link a device tree blob for particular hardware into the kernel,
+ suppressing use of the DTB pointer provided by the bootloader.
+ This option should only be used with legacy bootloaders that are
+ not capable of providing a DTB to the kernel, or for experimental
+ hardware without stable device tree bindings.
+
+config BUILTIN_DTB_SOURCE
+   string "Source file for builtin DTB"
+   default ""
+   depends on USE_BUILTIN_DTB
+   help
+ Base name (without suffix, relative to arch/sh/boot/dts) for the
+ a DTS file that will be used to produce the DTB linked into the
+ kernel.
+
 config ZERO_PAGE_OFFSET
hex
default "0x0001" if PAGE_SIZE_64KB || SH_RTS7751R2D || \
@@ -839,7 +859,7 @@ config PCI
depends on SYS_SUPPORTS_PCI
select PCI_DOMAINS
select GENERIC_PCI_IOMAP
-   select NO_GENERIC_PCI_IOPORT_MAP
+   select NO_GENERIC_PCI_IOPORT_MAP if !SH_DEVICE_TREE
help
  Find out whether you have a PCI motherboard. PCI is the name of a
  bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
index 5e52d53..98f884e 100644
--- a/arch/sh/boards/Kconfig
+++ b/arch/sh/boards/Kconfig
@@ -12,6 +12,10 @@ config SH_DEVICE_TREE
select OF_EARLY_FLATTREE
select CLKSRC_OF
select GENERIC_CALIBRATE_DELAY
+   select COMMON_CLK
+   select GENERIC_IOMAP
+   select GENERIC_IRQ_CHIP
+   select SYS_SUPPORTS_PCI
help
  Select Board Described by Device Tree to build a kernel that
  does not hard-code any board-specific knowledge but instead uses
diff --git a/arch/sh/drivers/Makefile b/arch/sh/drivers/Makefile
index e13f06b..382e86f 100644
--- a/arch/sh/drivers/Makefile
+++ b/arch/sh/drivers/Makefile
@@ -4,7 +4,9 @@
 
 obj-y  += dma/
 
+ifndef CONFIG_SH_DEVICE_TREE
 obj-$(CONFIG_PCI)  += pci/
+endif
 obj-$(CONFIG_SUPERHYWAY)   += superhyway/
 obj-$(CONFIG_PUSH_SWITCH)  += push-switch.o
 obj-$(CONFIG_HEARTBEAT)+= heartbeat.o
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 3280a6b..df62a9f 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -387,6 +387,12 @@ static inline int iounmap_fixed(void __iomem *addr) { 
return -EINVAL; }
 int valid_phys_addr_range(phys_addr_t addr, size_t size);
 int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
 
+#define PCI_IOBASE 0xfe24UL
+
+#define HAVE_ARCH_PIO_SIZE
+#define PIO_OFFSET PCI_IOBASE
+#define PIO_MASK   0x3UL
+#define PIO_RESERVED   0x4UL
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_SH_IO_H */
diff --git a/arch/sh/kernel/cpu/Makefile b/arch/sh/kernel/cpu/Makefile
index accc7ca..22ad0ee 100644
--- a/arch/sh/kernel/cpu/Makefile
+++ b/arch/sh/kernel/cpu/Makefile
@@ -16,6 +16,10 @@ obj-$(CONFIG_ARCH_SHMOBILE)  += shmobile/
 # Common interfaces.
 
 obj-$(CONFIG_SH_ADC)   += adc.o
+ifndef CONFIG_COMMON_CLK
 obj-$(CONFIG_SH_CLK_CPG_LEGACY)+= clock-cpg.o
-
-obj-y  += irq/ init.o clock.o fpu.o pfc.o proc.o
+endif
+ifndef CONFIG_GENERIC_IRQ_CHIP
+obj-y  += irq/
+endif
+obj-y  += init.o clock.o fpu.o pfc.o proc.o
diff --git a/arch/sh/kernel/cpu/clock.c b/arch/sh/kernel/cpu/clock.c
index 4187cf4..856a05c 100644
--- a/arch/sh/kernel/cpu/clock.c
+++ b/arch/sh/kernel/cpu/clock.c
@@ -17,19 +17,21 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 int __init clk_init(void)
 {
-   int ret;
+   int ret

[PATCH RESEND 00/12] SH: landisk convert to devicetree

2016-04-30 Thread Yoshinori Sato 
SH get devicetree support. But it not working on existing H/W.

IO-DATA HDL-U (aka landisk) currentry supported.
This H/W like SH7751 evalution board. It's a best to use this as a
change base H/W.

Yoshinori Sato (12):
  sh: Fix typo
  sh: Config update for OF mode
  sh: Disable board specific code in OF mode
  sh: Drop CPU specific setup on OF mode
  sh: DeviceTree support update
  clk: sh: SH7750/51 PLL and divider clock driver
  pci: sh: SH7751 PCI host bridge driver
  intc: sh: Renesas Super H INTC driver
  sh: Add I/O DATA HDL-U support drivers.
  sh: I/O DATA HDL-U (aka landisk) support dts
  sh: I/O DATA HDL-U defconfig (DT mode)
  of: Add sh support

 .../bindings/clock/renesas,sh-div-clock.txt|  24 ++
 .../bindings/clock/renesas,sh7750-div-clock.txt|  27 ++
 .../bindings/clock/renesas,sh7750-pll-clock.txt|  26 ++
 .../interrupt-controller/iodata-landisk.txt|  28 ++
 .../interrupt-controller/renesas,sh7751-intc.txt   |  25 ++
 .../devicetree/bindings/pci/sh7751-pci.txt |  51 +++
 arch/sh/Kconfig|  26 +-
 arch/sh/Makefile   |  11 +
 arch/sh/boards/Kconfig |   4 +
 arch/sh/boards/of-generic.c|  23 +-
 arch/sh/boot/compressed/head_32.S  |   5 +-
 arch/sh/boot/dts/include/dt-bindings   |   1 +
 arch/sh/boot/dts/landisk.dts   | 150 +
 arch/sh/configs/landisk-dt_defconfig   | 100 ++
 arch/sh/drivers/Makefile   |   2 +
 arch/sh/include/asm/io.h   |   6 +
 arch/sh/kernel/cpu/Makefile|   8 +-
 arch/sh/kernel/cpu/clock.c |   9 +-
 arch/sh/kernel/cpu/sh4/Makefile|   2 +
 arch/sh/kernel/head_32.S   |   2 +-
 arch/sh/kernel/setup.c |  19 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   3 +-
 drivers/clk/sh/Kconfig |   5 +
 drivers/clk/sh/Makefile|   2 +
 drivers/clk/sh/clk-sh7750.c| 223 +
 drivers/clk/sh/clk-shdiv.c | 338 
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-io-landisk.c   |  71 +
 drivers/irqchip/irq-renesas-shipr.c| 138 
 drivers/of/fdt.c   |   3 +
 drivers/pci/host/Kconfig   |   7 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pci-sh7751.c  | 346 +
 drivers/pci/host/pci-sh7751.h  | 269 
 drivers/sh/Makefile|   2 +
 include/dt-bindings/interrupt-controller/sh_intc.h |   2 +
 38 files changed, 1942 insertions(+), 24 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-div-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-pll-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/iodata-landisk.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.txt
 create mode 100644 Documentation/devicetree/bindings/pci/sh7751-pci.txt
 create mode 12 arch/sh/boot/dts/include/dt-bindings
 create mode 100644 arch/sh/boot/dts/landisk.dts
 create mode 100644 arch/sh/configs/landisk-dt_defconfig
 create mode 100644 drivers/clk/sh/Kconfig
 create mode 100644 drivers/clk/sh/Makefile
 create mode 100644 drivers/clk/sh/clk-sh7750.c
 create mode 100644 drivers/clk/sh/clk-shdiv.c
 create mode 100644 drivers/irqchip/irq-io-landisk.c
 create mode 100644 drivers/irqchip/irq-renesas-shipr.c
 create mode 100644 drivers/pci/host/pci-sh7751.c
 create mode 100644 drivers/pci/host/pci-sh7751.h
 create mode 100644 include/dt-bindings/interrupt-controller/sh_intc.h

-- 
2.7.0

2% Loan Offer! No upfront fees

2016-04-30 Thread Mr. Davies 
We give out loans from $10,000.00 to  $500,000,000.00 at 2% interest rate if 
interested contact us at: daviesanthony...@qq.com

2% Loan Offer! No upfront fees

2016-04-30 Thread Mr. Davies 
We give out loans from $10,000.00 to  $500,000,000.00 at 2% interest rate if 
interested contact us at: daviesanthony...@qq.com

Re: [PATCH V17 1/3] dmaengine: qcom_hidma: implement lower level hardware interface

2016-04-30 Thread Sinan Kaya 
On 4/28/2016 3:30 PM, Sinan Kaya wrote:
> On 4/26/2016 12:24 PM, Vinod Koul wrote:
>>> +
 +   dev_err(lldev->dev, "error 0x%x, resetting...\n",
 +   cause);
>> right justify this and others as well please
>>
> 
> Can you please point me to other lines that need to be fixed please? It looks 
> good
> to me though it doesn't to you. I want to make sure that I'm touching the 
> right ones.
> You seem to prefer a tab following an open parenthesis in your code. Do you 
> want me to
> add a tab for every single multi-line such that it comes this for instance?
> 
> 
>   ret = readl_poll_timeout(lldev->trca + HIDMA_TRCA_CTRLSTS_REG, val,
>   HIDMA_CH_STATE(val) == 
> HIDMA_CH_DISABLED, 
>   1000, 1); 
> 
> instead of
> 
>   ret = readl_poll_timeout(lldev->trca + HIDMA_TRCA_CTRLSTS_REG, val,
>HIDMA_CH_STATE(val) == HIDMA_CH_DISABLED, 1000,
>1); 
> 
> 
 +int hidma_ll_resume(struct hidma_lldev *lldev)
 +{
 +  return hidma_ll_enable(lldev);
 +}
>>
>> why do we need this empty function, use hidma_ll_enable.

 hidma_ll_enable is a common function that gets called from multiple 
 places. 
 hidma_ll_resume and hidma_ll_pause is used by the OS interface for pausing
 and resuming the DMA channel. 
>> is there a reason why we can't have the code in resume and that being called
>> internally as well as externally?
>>
> 
> I'll have the pause code in OS layer call hidma_ll_enable and get rid of pause
> function here.
> 


I posted v18 along with all the style corrections and other things you asked me.
Please let me know if there is anything outstanding.



-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

Re: [PATCH V17 1/3] dmaengine: qcom_hidma: implement lower level hardware interface

2016-04-30 Thread Sinan Kaya 
On 4/28/2016 3:30 PM, Sinan Kaya wrote:
> On 4/26/2016 12:24 PM, Vinod Koul wrote:
>>> +
 +   dev_err(lldev->dev, "error 0x%x, resetting...\n",
 +   cause);
>> right justify this and others as well please
>>
> 
> Can you please point me to other lines that need to be fixed please? It looks 
> good
> to me though it doesn't to you. I want to make sure that I'm touching the 
> right ones.
> You seem to prefer a tab following an open parenthesis in your code. Do you 
> want me to
> add a tab for every single multi-line such that it comes this for instance?
> 
> 
>   ret = readl_poll_timeout(lldev->trca + HIDMA_TRCA_CTRLSTS_REG, val,
>   HIDMA_CH_STATE(val) == 
> HIDMA_CH_DISABLED, 
>   1000, 1); 
> 
> instead of
> 
>   ret = readl_poll_timeout(lldev->trca + HIDMA_TRCA_CTRLSTS_REG, val,
>HIDMA_CH_STATE(val) == HIDMA_CH_DISABLED, 1000,
>1); 
> 
> 
 +int hidma_ll_resume(struct hidma_lldev *lldev)
 +{
 +  return hidma_ll_enable(lldev);
 +}
>>
>> why do we need this empty function, use hidma_ll_enable.

 hidma_ll_enable is a common function that gets called from multiple 
 places. 
 hidma_ll_resume and hidma_ll_pause is used by the OS interface for pausing
 and resuming the DMA channel. 
>> is there a reason why we can't have the code in resume and that being called
>> internally as well as externally?
>>
> 
> I'll have the pause code in OS layer call hidma_ll_enable and get rid of pause
> function here.
> 


I posted v18 along with all the style corrections and other things you asked me.
Please let me know if there is anything outstanding.



-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

Re: [PATCH V17 2/3] dmaengine: qcom_hidma: add debugfs hooks

2016-04-30 Thread Sinan Kaya 
On 4/27/2016 8:51 AM, ok...@codeaurora.org wrote:
> On 2016-04-27 04:15, Vinod Koul wrote:
>> On Tue, Apr 26, 2016 at 12:55:18PM -0400, Sinan Kaya wrote:
>>> On 4/26/2016 12:25 PM, Vinod Koul wrote:
>>> > On Tue, Apr 26, 2016 at 08:08:16AM -0400, ok...@codeaurora.org wrote:
>>> >> On 2016-04-25 23:30, Vinod Koul wrote:
>>> >>> On Mon, Apr 11, 2016 at 10:21:12AM -0400, Sinan Kaya wrote:
>>> >>>
>>>  +static int hidma_chan_stats(struct seq_file *s, void *unused)
>>>  +{
>>>  +struct hidma_chan *mchan = s->private;
>>>  +struct hidma_desc *mdesc;
>>>  +struct hidma_dev *dmadev = mchan->dmadev;
>>>  +
>>>  +pm_runtime_get_sync(dmadev->ddev.dev);
>>> >>>
>>> >>> debug shouldn't power up device, why do you want to do that
>>> >>
>>> >>
>>> >> Clocks are turned off while the hw is idle. I can’t reach hw
>>> >> registers without restoring power.
>>> >
>>> > Hmm, have you thought about using regmap?
>>> >
>>>
>>> To be honest, I didn't know what regmap is but I just read some code
>>> and looked at how it is used. Feel free to correct me if I got it
>>> wrong.
>>>
>>> Regmap seems to be designed for *slow* speed peripherals to improve frequent
>>> accesses by the SW. It looks like it is used by MFD, SPI and I2C drivers.
>>>
>>> It seems to cache the register contents and flush/invalidate them only when
>>> needed.
>>>
>>> The MMIO version seems to be assuming the presence of device-tree like CLK
>>> API which doesn't exist on ACPI systems and is not portable.
>>>
>>> My reaction is that it is a lot of code with no added functionality to what
>>> HIDMA driver is trying to achieve.
>>>
>>> Given that the use case here is only for debug purposes; I think it is OK
>>> to keep this runtime call here. I don't want to add any overhead into the
>>> existing code just to support the debug use case.
>>>
>>> None of my register read/writes are slow. This file will only be used to
>>> troubleshoot customer issues.
>>
>> $ is always faster than MMIO. This way you can give reg contents to users
>> without waking up hw.
>>
>> Also we at Intel use regmap on ACPI systems without CLK API
> 
> I can try and see the performance impact is. What happens to registers that 
> hw updates like status registers. Those will be most interesting during 
> debug. How does remap get updated for those? Is there a way to tell it not to 
> cache certain registers

My evaluation turned out negative. The regmap code is nice for bus like 
peripherals
like I2C and SPI where everything is bitwise accessed. This is not the case
in this code. 

Regmap is a nice tool if used properly but it doesn't mean that it will work
in every single case. It doesn't match with the goal of this driver. 

As soon as I abstract register accesses, the regmap code writes all MMIO 
registers
with the readl variant functions.

Barriers are really expensive on ARM. I paid very special attention in the 
code to decide when to use relaxed version vs. the readl version. I lose 
all of this optimization. 

Since the clocks are restored only during the debug case, I don't see any
problems here. It is not worth the effort to do redo the whole thing and 
introduce errors as I see a lot of tripping points like regmap_sync variants.


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

Re: [PATCH V17 2/3] dmaengine: qcom_hidma: add debugfs hooks

2016-04-30 Thread Sinan Kaya 
On 4/27/2016 8:51 AM, ok...@codeaurora.org wrote:
> On 2016-04-27 04:15, Vinod Koul wrote:
>> On Tue, Apr 26, 2016 at 12:55:18PM -0400, Sinan Kaya wrote:
>>> On 4/26/2016 12:25 PM, Vinod Koul wrote:
>>> > On Tue, Apr 26, 2016 at 08:08:16AM -0400, ok...@codeaurora.org wrote:
>>> >> On 2016-04-25 23:30, Vinod Koul wrote:
>>> >>> On Mon, Apr 11, 2016 at 10:21:12AM -0400, Sinan Kaya wrote:
>>> >>>
>>>  +static int hidma_chan_stats(struct seq_file *s, void *unused)
>>>  +{
>>>  +struct hidma_chan *mchan = s->private;
>>>  +struct hidma_desc *mdesc;
>>>  +struct hidma_dev *dmadev = mchan->dmadev;
>>>  +
>>>  +pm_runtime_get_sync(dmadev->ddev.dev);
>>> >>>
>>> >>> debug shouldn't power up device, why do you want to do that
>>> >>
>>> >>
>>> >> Clocks are turned off while the hw is idle. I can’t reach hw
>>> >> registers without restoring power.
>>> >
>>> > Hmm, have you thought about using regmap?
>>> >
>>>
>>> To be honest, I didn't know what regmap is but I just read some code
>>> and looked at how it is used. Feel free to correct me if I got it
>>> wrong.
>>>
>>> Regmap seems to be designed for *slow* speed peripherals to improve frequent
>>> accesses by the SW. It looks like it is used by MFD, SPI and I2C drivers.
>>>
>>> It seems to cache the register contents and flush/invalidate them only when
>>> needed.
>>>
>>> The MMIO version seems to be assuming the presence of device-tree like CLK
>>> API which doesn't exist on ACPI systems and is not portable.
>>>
>>> My reaction is that it is a lot of code with no added functionality to what
>>> HIDMA driver is trying to achieve.
>>>
>>> Given that the use case here is only for debug purposes; I think it is OK
>>> to keep this runtime call here. I don't want to add any overhead into the
>>> existing code just to support the debug use case.
>>>
>>> None of my register read/writes are slow. This file will only be used to
>>> troubleshoot customer issues.
>>
>> $ is always faster than MMIO. This way you can give reg contents to users
>> without waking up hw.
>>
>> Also we at Intel use regmap on ACPI systems without CLK API
> 
> I can try and see the performance impact is. What happens to registers that 
> hw updates like status registers. Those will be most interesting during 
> debug. How does remap get updated for those? Is there a way to tell it not to 
> cache certain registers

My evaluation turned out negative. The regmap code is nice for bus like 
peripherals
like I2C and SPI where everything is bitwise accessed. This is not the case
in this code. 

Regmap is a nice tool if used properly but it doesn't mean that it will work
in every single case. It doesn't match with the goal of this driver. 

As soon as I abstract register accesses, the regmap code writes all MMIO 
registers
with the readl variant functions.

Barriers are really expensive on ARM. I paid very special attention in the 
code to decide when to use relaxed version vs. the readl version. I lose 
all of this optimization. 

Since the clocks are restored only during the debug case, I don't see any
problems here. It is not worth the effort to do redo the whole thing and 
introduce errors as I see a lot of tripping points like regmap_sync variants.


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

[PATCH V18 3/3] dmaengine: qcom_hidma: add support for object hierarchy

2016-04-30 Thread Sinan Kaya 
In order to create a relationship model between the channels and the
management object, we are adding support for object hierarchy to the
drivers. This patch simplifies the userspace application development.
We will not have to traverse different firmware paths based on device
tree or ACPI based kernels.

No matter what flavor of kernel is used, objects will be represented as
platform devices.

The new layout is as follows:

hidmam_10: hidma-mgmt@0x5A00 {
compatible = "qcom,hidma-mgmt-1.0";
...

hidma_10: hidma@0x5a01 {
compatible = "qcom,hidma-1.0";
...
}
}

The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
in device tree and calls into the channel driver to create platform devices
for each child of the management object.

Signed-off-by: Sinan Kaya 
---
 Documentation/ABI/testing/sysfs-platform-hidma |   9 ++
 drivers/dma/qcom/hidma.c   |  39 -
 drivers/dma/qcom/hidma_mgmt.c  | 113 -
 3 files changed, 156 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma

diff --git a/Documentation/ABI/testing/sysfs-platform-hidma 
b/Documentation/ABI/testing/sysfs-platform-hidma
new file mode 100644
index 000..d364415
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -0,0 +1,9 @@
+What:  /sys/devices/platform/hidma-*/chid
+   /sys/devices/platform/QCOM8061:*/chid
+Date:  Dec 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the ID of the channel within the HIDMA instance.
+   It is used to associate a given HIDMA channel with the
+   priority and weight calls in the management interface.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 44c6491..033ac03 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -549,6 +549,43 @@ static irqreturn_t hidma_chirq_handler(int chirq, void 
*arg)
return hidma_ll_inthandler(chirq, lldev);
 }
 
+static ssize_t hidma_show_values(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct hidma_dev *mdev = platform_get_drvdata(pdev);
+
+   buf[0] = 0;
+
+   if (strcmp(attr->attr.name, "chid") == 0)
+   sprintf(buf, "%d\n", mdev->chidx);
+
+   return strlen(buf);
+}
+
+static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
+   int mode)
+{
+   struct device_attribute *attrs;
+   char *name_copy;
+
+   attrs = devm_kmalloc(dev->ddev.dev, sizeof(struct device_attribute),
+GFP_KERNEL);
+   if (!attrs)
+   return -ENOMEM;
+
+   name_copy = devm_kstrdup(dev->ddev.dev, name, GFP_KERNEL);
+   if (!name_copy)
+   return -ENOMEM;
+
+   attrs->attr.name = name_copy;
+   attrs->attr.mode = mode;
+   attrs->show = hidma_show_values;
+   sysfs_attr_init(>attr);
+
+   return device_create_file(dev->ddev.dev, attrs);
+}
+
 static int hidma_probe(struct platform_device *pdev)
 {
struct hidma_dev *dmadev;
@@ -682,6 +719,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
hidma_debug_init(dmadev);
+   hidma_create_sysfs_entry(dmadev, "chid", S_IRUGO);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -730,7 +768,6 @@ static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{},
 };
-
 MODULE_DEVICE_TABLE(of, hidma_match);
 
 static struct platform_driver hidma_driver = {
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index ef491b8..c0e3653 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -1,7 +1,7 @@
 /*
  * Qualcomm Technologies HIDMA DMA engine Management interface
  *
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -17,13 +17,14 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "hidma_mgmt.h"
 
@@ -298,5 +299,109 @@ static struct platform_driver hidma_mgmt_driver = {
},
 };
 
-module_platform_driver(hidma_mgmt_driver);
+#if defined(CONFIG_OF) && defined(CONFIG_OF_IRQ)
+static int object_counter;
+

[PATCH V18 3/3] dmaengine: qcom_hidma: add support for object hierarchy

2016-04-30 Thread Sinan Kaya 
In order to create a relationship model between the channels and the
management object, we are adding support for object hierarchy to the
drivers. This patch simplifies the userspace application development.
We will not have to traverse different firmware paths based on device
tree or ACPI based kernels.

No matter what flavor of kernel is used, objects will be represented as
platform devices.

The new layout is as follows:

hidmam_10: hidma-mgmt@0x5A00 {
compatible = "qcom,hidma-mgmt-1.0";
...

hidma_10: hidma@0x5a01 {
compatible = "qcom,hidma-1.0";
...
}
}

The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
in device tree and calls into the channel driver to create platform devices
for each child of the management object.

Signed-off-by: Sinan Kaya 
---
 Documentation/ABI/testing/sysfs-platform-hidma |   9 ++
 drivers/dma/qcom/hidma.c   |  39 -
 drivers/dma/qcom/hidma_mgmt.c  | 113 -
 3 files changed, 156 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma

diff --git a/Documentation/ABI/testing/sysfs-platform-hidma 
b/Documentation/ABI/testing/sysfs-platform-hidma
new file mode 100644
index 000..d364415
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -0,0 +1,9 @@
+What:  /sys/devices/platform/hidma-*/chid
+   /sys/devices/platform/QCOM8061:*/chid
+Date:  Dec 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the ID of the channel within the HIDMA instance.
+   It is used to associate a given HIDMA channel with the
+   priority and weight calls in the management interface.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 44c6491..033ac03 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -549,6 +549,43 @@ static irqreturn_t hidma_chirq_handler(int chirq, void 
*arg)
return hidma_ll_inthandler(chirq, lldev);
 }
 
+static ssize_t hidma_show_values(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct hidma_dev *mdev = platform_get_drvdata(pdev);
+
+   buf[0] = 0;
+
+   if (strcmp(attr->attr.name, "chid") == 0)
+   sprintf(buf, "%d\n", mdev->chidx);
+
+   return strlen(buf);
+}
+
+static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
+   int mode)
+{
+   struct device_attribute *attrs;
+   char *name_copy;
+
+   attrs = devm_kmalloc(dev->ddev.dev, sizeof(struct device_attribute),
+GFP_KERNEL);
+   if (!attrs)
+   return -ENOMEM;
+
+   name_copy = devm_kstrdup(dev->ddev.dev, name, GFP_KERNEL);
+   if (!name_copy)
+   return -ENOMEM;
+
+   attrs->attr.name = name_copy;
+   attrs->attr.mode = mode;
+   attrs->show = hidma_show_values;
+   sysfs_attr_init(>attr);
+
+   return device_create_file(dev->ddev.dev, attrs);
+}
+
 static int hidma_probe(struct platform_device *pdev)
 {
struct hidma_dev *dmadev;
@@ -682,6 +719,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
hidma_debug_init(dmadev);
+   hidma_create_sysfs_entry(dmadev, "chid", S_IRUGO);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -730,7 +768,6 @@ static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{},
 };
-
 MODULE_DEVICE_TABLE(of, hidma_match);
 
 static struct platform_driver hidma_driver = {
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index ef491b8..c0e3653 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -1,7 +1,7 @@
 /*
  * Qualcomm Technologies HIDMA DMA engine Management interface
  *
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -17,13 +17,14 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "hidma_mgmt.h"
 
@@ -298,5 +299,109 @@ static struct platform_driver hidma_mgmt_driver = {
},
 };
 
-module_platform_driver(hidma_mgmt_driver);
+#if defined(CONFIG_OF) && defined(CONFIG_OF_IRQ)
+static int object_counter;
+
+static int __init

[PATCH V18 2/3] dmaengine: qcom_hidma: add debugfs hooks

2016-04-30 Thread Sinan Kaya 
Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.

A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/Makefile|   2 +-
 drivers/dma/qcom/hidma.c |   5 +-
 drivers/dma/qcom/hidma.h |   2 +
 drivers/dma/qcom/hidma_dbg.c | 217 +++
 4 files changed, 224 insertions(+), 2 deletions(-)
 create mode 100644 drivers/dma/qcom/hidma_dbg.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 6bf9267..4bfc38b 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
 hdma_mgmt-objs  := hidma_mgmt.o hidma_mgmt_sys.o
 obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index f426d9f..44c6491 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -1,7 +1,7 @@
 /*
  * Qualcomm Technologies HIDMA DMA engine interface
  *
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -681,6 +681,7 @@ static int hidma_probe(struct platform_device *pdev)
 
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
+   hidma_debug_init(dmadev);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -689,6 +690,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
 
 uninit:
+   hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
 dmafree:
if (dmadev)
@@ -706,6 +708,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(>ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+   hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
 
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index b1362ef..db413a5 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -153,4 +153,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
 irqreturn_t hidma_ll_inthandler(int irq, void *arg);
 void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
 #endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..fa827e5
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,217 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+   struct hidma_lldev *lldev = llhndl;
+   struct hidma_tre *tre;
+   u32 length;
+   dma_addr_t src_start;
+   dma_addr_t dest_start;
+   u32 *tre_local;
+
+   if (tre_ch >= lldev->nr_tres) {
+   dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+   return;
+   }
+   tre = >trepool[tre_ch];
+   seq_printf(s, "--Channel %d -\n", tre_ch);
+   seq_printf(s, "allocated=%d\n", atomic_read(>allocated));
+   seq_printf(s, "queued = 0x%x\n", tre->queued);
+   seq_printf(s, "err_info = 0x%x\n", tre->err_info);
+   seq_printf(s, "err_code = 0x%x\n", tre->err_code);
+   seq_printf(s, "status = 0x%x\n", tre->status);
+   seq_printf(s, "idx = 0x%x\n", tre->idx);
+   seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+   seq_printf(s, "dev_name=%s\n", tre->dev_name);
+   seq_printf(s, "callback=%p\n", tre->callback);
+   seq_printf(s, "data=%p\n",

[PATCH V18 1/3] dmaengine: qcom_hidma: implement lower level hardware interface

2016-04-30 Thread Sinan Kaya 
This patch implements the hardware hooks for the HIDMA channel driver.

The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start

OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.

Completions are delivered via callbacks via tasklet.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/Makefile   |   2 +
 drivers/dma/qcom/hidma.c|   8 +-
 drivers/dma/qcom/hidma.h|  38 +-
 drivers/dma/qcom/hidma_ll.c | 872 
 4 files changed, 895 insertions(+), 25 deletions(-)
 create mode 100644 drivers/dma/qcom/hidma_ll.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index bfea699..6bf9267 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
 hdma_mgmt-objs  := hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index f8960f1..f426d9f 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -423,7 +423,7 @@ static int hidma_terminate_channel(struct dma_chan *chan)
spin_unlock_irqrestore(>lock, irqflags);
 
/* this suspends the existing transfer */
-   rc = hidma_ll_pause(dmadev->lldev);
+   rc = hidma_ll_disable(dmadev->lldev);
if (rc) {
dev_err(dmadev->ddev.dev, "channel did not pause\n");
goto out;
@@ -446,7 +446,7 @@ static int hidma_terminate_channel(struct dma_chan *chan)
list_move(>node, >free);
}
 
-   rc = hidma_ll_resume(dmadev->lldev);
+   rc = hidma_ll_enable(dmadev->lldev);
 out:
pm_runtime_mark_last_busy(dmadev->ddev.dev);
pm_runtime_put_autosuspend(dmadev->ddev.dev);
@@ -507,7 +507,7 @@ static int hidma_pause(struct dma_chan *chan)
dmadev = to_hidma_dev(mchan->chan.device);
if (!mchan->paused) {
pm_runtime_get_sync(dmadev->ddev.dev);
-   if (hidma_ll_pause(dmadev->lldev))
+   if (hidma_ll_disable(dmadev->lldev))
dev_warn(dmadev->ddev.dev, "channel did not stop\n");
mchan->paused = true;
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -526,7 +526,7 @@ static int hidma_resume(struct dma_chan *chan)
dmadev = to_hidma_dev(mchan->chan.device);
if (mchan->paused) {
pm_runtime_get_sync(dmadev->ddev.dev);
-   rc = hidma_ll_resume(dmadev->lldev);
+   rc = hidma_ll_enable(dmadev->lldev);
if (!rc)
mchan->paused = false;
else
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 231e306..b1362ef 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -1,7 +1,7 @@
 /*
  * Qualcomm Technologies HIDMA data structures
  *
- * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2016, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -20,32 +20,29 @@
 #include 
 #include 
 
-#define TRE_SIZE   32 /* each TRE is 32 bytes  */
-#define TRE_CFG_IDX0
-#define TRE_LEN_IDX1
-#define TRE_SRC_LOW_IDX2
-#define TRE_SRC_HI_IDX 3
-#define TRE_DEST_LOW_IDX   4
-#define TRE_DEST_HI_IDX5
-
-struct hidma_tx_status {
-   u8 err_info;/* error record in this transfer*/
-   u8 err_code;/* completion code  */
-};
+#define HIDMA_TRE_SIZE 32 /* each TRE is 32 bytes  */
+#define HIDMA_TRE_CFG_IDX  0
+#define HIDMA_TRE_LEN_IDX  1
+#define HIDMA_TRE_SRC_LOW_IDX  2
+#define HIDMA_TRE_SRC_HI_IDX   3
+#define HIDMA_TRE_DEST_LOW_IDX 4
+#define HIDMA_TRE_DEST_HI_IDX  5
 
 struct hidma_tre {
atomic_t allocated; /* if this channel is allocated */
bool queued;/* flag whether this is pending */
u16 status; /* status   */
-   u32 chidx;  /* index of the tre */
+   u32 idx;/* index of the tre */
u32 dma_sig;/*

[PATCH V18 2/3] dmaengine: qcom_hidma: add debugfs hooks

2016-04-30 Thread Sinan Kaya 
Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.

A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/Makefile|   2 +-
 drivers/dma/qcom/hidma.c |   5 +-
 drivers/dma/qcom/hidma.h |   2 +
 drivers/dma/qcom/hidma_dbg.c | 217 +++
 4 files changed, 224 insertions(+), 2 deletions(-)
 create mode 100644 drivers/dma/qcom/hidma_dbg.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 6bf9267..4bfc38b 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
 hdma_mgmt-objs  := hidma_mgmt.o hidma_mgmt_sys.o
 obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index f426d9f..44c6491 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -1,7 +1,7 @@
 /*
  * Qualcomm Technologies HIDMA DMA engine interface
  *
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -681,6 +681,7 @@ static int hidma_probe(struct platform_device *pdev)
 
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
+   hidma_debug_init(dmadev);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -689,6 +690,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
 
 uninit:
+   hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
 dmafree:
if (dmadev)
@@ -706,6 +708,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(>ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+   hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
 
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index b1362ef..db413a5 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -153,4 +153,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
 irqreturn_t hidma_ll_inthandler(int irq, void *arg);
 void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
 #endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..fa827e5
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,217 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+   struct hidma_lldev *lldev = llhndl;
+   struct hidma_tre *tre;
+   u32 length;
+   dma_addr_t src_start;
+   dma_addr_t dest_start;
+   u32 *tre_local;
+
+   if (tre_ch >= lldev->nr_tres) {
+   dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+   return;
+   }
+   tre = >trepool[tre_ch];
+   seq_printf(s, "--Channel %d -\n", tre_ch);
+   seq_printf(s, "allocated=%d\n", atomic_read(>allocated));
+   seq_printf(s, "queued = 0x%x\n", tre->queued);
+   seq_printf(s, "err_info = 0x%x\n", tre->err_info);
+   seq_printf(s, "err_code = 0x%x\n", tre->err_code);
+   seq_printf(s, "status = 0x%x\n", tre->status);
+   seq_printf(s, "idx = 0x%x\n", tre->idx);
+   seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+   seq_printf(s, "dev_name=%s\n", tre->dev_name);
+   seq_printf(s, "callback=%p\n", tre->callback);
+   seq_printf(s, "data=%p\n", tre->data);
+

[PATCH V18 1/3] dmaengine: qcom_hidma: implement lower level hardware interface

2016-04-30 Thread Sinan Kaya 
This patch implements the hardware hooks for the HIDMA channel driver.

The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start

OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.

Completions are delivered via callbacks via tasklet.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/Makefile   |   2 +
 drivers/dma/qcom/hidma.c|   8 +-
 drivers/dma/qcom/hidma.h|  38 +-
 drivers/dma/qcom/hidma_ll.c | 872 
 4 files changed, 895 insertions(+), 25 deletions(-)
 create mode 100644 drivers/dma/qcom/hidma_ll.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index bfea699..6bf9267 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
 hdma_mgmt-objs  := hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index f8960f1..f426d9f 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -423,7 +423,7 @@ static int hidma_terminate_channel(struct dma_chan *chan)
spin_unlock_irqrestore(>lock, irqflags);
 
/* this suspends the existing transfer */
-   rc = hidma_ll_pause(dmadev->lldev);
+   rc = hidma_ll_disable(dmadev->lldev);
if (rc) {
dev_err(dmadev->ddev.dev, "channel did not pause\n");
goto out;
@@ -446,7 +446,7 @@ static int hidma_terminate_channel(struct dma_chan *chan)
list_move(>node, >free);
}
 
-   rc = hidma_ll_resume(dmadev->lldev);
+   rc = hidma_ll_enable(dmadev->lldev);
 out:
pm_runtime_mark_last_busy(dmadev->ddev.dev);
pm_runtime_put_autosuspend(dmadev->ddev.dev);
@@ -507,7 +507,7 @@ static int hidma_pause(struct dma_chan *chan)
dmadev = to_hidma_dev(mchan->chan.device);
if (!mchan->paused) {
pm_runtime_get_sync(dmadev->ddev.dev);
-   if (hidma_ll_pause(dmadev->lldev))
+   if (hidma_ll_disable(dmadev->lldev))
dev_warn(dmadev->ddev.dev, "channel did not stop\n");
mchan->paused = true;
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -526,7 +526,7 @@ static int hidma_resume(struct dma_chan *chan)
dmadev = to_hidma_dev(mchan->chan.device);
if (mchan->paused) {
pm_runtime_get_sync(dmadev->ddev.dev);
-   rc = hidma_ll_resume(dmadev->lldev);
+   rc = hidma_ll_enable(dmadev->lldev);
if (!rc)
mchan->paused = false;
else
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 231e306..b1362ef 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -1,7 +1,7 @@
 /*
  * Qualcomm Technologies HIDMA data structures
  *
- * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2016, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -20,32 +20,29 @@
 #include 
 #include 
 
-#define TRE_SIZE   32 /* each TRE is 32 bytes  */
-#define TRE_CFG_IDX0
-#define TRE_LEN_IDX1
-#define TRE_SRC_LOW_IDX2
-#define TRE_SRC_HI_IDX 3
-#define TRE_DEST_LOW_IDX   4
-#define TRE_DEST_HI_IDX5
-
-struct hidma_tx_status {
-   u8 err_info;/* error record in this transfer*/
-   u8 err_code;/* completion code  */
-};
+#define HIDMA_TRE_SIZE 32 /* each TRE is 32 bytes  */
+#define HIDMA_TRE_CFG_IDX  0
+#define HIDMA_TRE_LEN_IDX  1
+#define HIDMA_TRE_SRC_LOW_IDX  2
+#define HIDMA_TRE_SRC_HI_IDX   3
+#define HIDMA_TRE_DEST_LOW_IDX 4
+#define HIDMA_TRE_DEST_HI_IDX  5
 
 struct hidma_tre {
atomic_t allocated; /* if this channel is allocated */
bool queued;/* flag whether this is pending */
u16 status; /* status   */
-   u32 chidx;  /* index of the tre */
+   u32 idx;/* index of the tre */
u32 dma_sig;/* signature of the tre

Re: efi_enabled(EFI_PARAVIRT) use

2016-04-30 Thread Shannon Zhao 
On 2016年05月01日 04:44, Matt Fleming wrote:
>> While I still have a question, in this patch we use
>> > efi_enabled(EFI_PARAVIRT) as a condition to make fdt_find_uefi_params()
>> > and efi_get_fdt_params() execute different ways. So it needs to find a
>> > new condition for that if we need to get rid of EFI_PARAVIRT. One I
>> > think is that xen_initial_domain() check. Is that fine?
> Hmm... why do you actually need to check whether you're running on a
> PV machine in fdt_find_uefi_params()?
Because the UEFI params for Dom0 are located under /hypervisor/uefi node
instead of /chosen. So it needs to check whether it's a Dom0 then search
and parse different node with different params arrays.

> Can't you infer that from the DT
> params you discover?
> 

> I could understand maybe only accepting the "xen,uefi-system-table"
> property if IS_ENABLED(CONFIG_XEN) but surely you don't also need to
> filter based on whether you're booting a PV kernel?
> 
> Let me put it this way: when would you see "xen,uefi-system-table" and
> *not* be booting a PV kernel?
So it still needs add another check to firstly parse the fdt to see if
there is "xen,uefi-system-table" under /hypervisor/uefi node, right? I
think it's a bit redundant compared with xen_initial_domain().

Thanks,
-- 
Shannon

Re: efi_enabled(EFI_PARAVIRT) use

2016-04-30 Thread Shannon Zhao 
On 2016年05月01日 04:44, Matt Fleming wrote:
>> While I still have a question, in this patch we use
>> > efi_enabled(EFI_PARAVIRT) as a condition to make fdt_find_uefi_params()
>> > and efi_get_fdt_params() execute different ways. So it needs to find a
>> > new condition for that if we need to get rid of EFI_PARAVIRT. One I
>> > think is that xen_initial_domain() check. Is that fine?
> Hmm... why do you actually need to check whether you're running on a
> PV machine in fdt_find_uefi_params()?
Because the UEFI params for Dom0 are located under /hypervisor/uefi node
instead of /chosen. So it needs to check whether it's a Dom0 then search
and parse different node with different params arrays.

> Can't you infer that from the DT
> params you discover?
> 

> I could understand maybe only accepting the "xen,uefi-system-table"
> property if IS_ENABLED(CONFIG_XEN) but surely you don't also need to
> filter based on whether you're booting a PV kernel?
> 
> Let me put it this way: when would you see "xen,uefi-system-table" and
> *not* be booting a PV kernel?
So it still needs add another check to firstly parse the fdt to see if
there is "xen,uefi-system-table" under /hypervisor/uefi node, right? I
think it's a bit redundant compared with xen_initial_domain().

Thanks,
-- 
Shannon

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

2016-04-30 Thread Guenter Roeck 
On Sat, Apr 30, 2016 at 05:36:51PM -0700, Guenter Roeck wrote:
> On Sat, Apr 30, 2016 at 07:38:28PM +0100, Sudip Mukherjee wrote:
> > On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote:
> > > On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee
> > > >  wrote:
> > > > > On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote:
> > > > >>
> > > > >> On 04/11/2016 10:51 PM, Sudip Mukherjee wrote:
> > > > >>>
> > > > >>> The build of avr32 allmodconfig fails with the error:
> > > > >>> ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> > > > >>>
> > > > >> This means there is a direct 64 bit divide operation in the driver,
> > > > >> which we should identify and fix.
> > > > 
> > > > This driver will quite likely never be used on AVR32. Do we need to
> > > > fix this due to some other architectures?
> > > > 
> > > > > yes, there is.
> > > > >
> > > > > in function: kempld_wdt_set_stage_timeout()
> > > > > remainder = do_div(stage_timeout64, prescaler);
> > > > 
> > > > > Any idea how to fix it?
> > > > 
> > > > Not easy, however, prescaler value is ((1 << 21) - 1) which someone
> > > > might consider as (1 << 21) with lost in precision.
> > > > 
> > > > Thus, shift on 20 bits right, add last bit to the value and shift on 1
> > > > bit right more.
> > > > 
> > > Sorry, I am missing something. do_div() should work fine with any 32 bit 
> > > value
> > > as divisor, no matter what that value is. Why does it fail here ? And why 
> > > does
> > > it work if I pass 0x1f as second parameter to do_div() directly ?
> > 
> > Please let me know what i can do here to help solve the problem.
> > linux-next continues to fail for avr32, and to make matters worse we
> > also have the similar problem in btrfs.
> > 
> > ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
> > ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> > 
> > Adding Chris to CC if he has some idea how to solve this error for btrfs.
> > Build log for next-20160429 is at:
> > https://travis-ci.org/sudipm-mukherjee/parport/jobs/126581065
> > 
> 
> Try the patch below.
> 
> Guenter
> 
Sorry, patch wasn't complete.

Guenter

---
>From c684f2cf54ecb256007288af23c24bfcdb2bbace Mon Sep 17 00:00:00 2001
From: Guenter Roeck 
Date: Sat, 30 Apr 2016 17:29:14 -0700
Subject: [PATCH] avr32: __div64_const32 is not ok

Building avr32 images may fail with errors such as

ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!

gcc for avr32 generates those symbols for certain constants used
as divisor in do_div(). The problem can be avoided by setting
__div64_const32_is_OK to false for the architecture.

Cc: Sudip Mukherjee 
Signed-off-by: Guenter Roeck 
---
 arch/avr32/include/asm/Kbuild  | 1 -
 arch/avr32/include/asm/div64.h | 3 +++
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 arch/avr32/include/asm/div64.h

diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild
index 241b9b9729d8..d2be4688ac7b 100644
--- a/arch/avr32/include/asm/Kbuild
+++ b/arch/avr32/include/asm/Kbuild
@@ -3,7 +3,6 @@ generic-y += clkdev.h
 generic-y += cputime.h
 generic-y += delay.h
 generic-y += device.h
-generic-y += div64.h
 generic-y += emergency-restart.h
 generic-y += exec.h
 generic-y += futex.h
diff --git a/arch/avr32/include/asm/div64.h b/arch/avr32/include/asm/div64.h
new file mode 100644
index ..1f3328e178df
--- /dev/null
+++ b/arch/avr32/include/asm/div64.h
@@ -0,0 +1,3 @@
+#define __div64_const32_is_OK  false
+
+#include 
-- 
2.5.0

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

2016-04-30 Thread Guenter Roeck 
On Sat, Apr 30, 2016 at 05:36:51PM -0700, Guenter Roeck wrote:
> On Sat, Apr 30, 2016 at 07:38:28PM +0100, Sudip Mukherjee wrote:
> > On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote:
> > > On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee
> > > >  wrote:
> > > > > On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote:
> > > > >>
> > > > >> On 04/11/2016 10:51 PM, Sudip Mukherjee wrote:
> > > > >>>
> > > > >>> The build of avr32 allmodconfig fails with the error:
> > > > >>> ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> > > > >>>
> > > > >> This means there is a direct 64 bit divide operation in the driver,
> > > > >> which we should identify and fix.
> > > > 
> > > > This driver will quite likely never be used on AVR32. Do we need to
> > > > fix this due to some other architectures?
> > > > 
> > > > > yes, there is.
> > > > >
> > > > > in function: kempld_wdt_set_stage_timeout()
> > > > > remainder = do_div(stage_timeout64, prescaler);
> > > > 
> > > > > Any idea how to fix it?
> > > > 
> > > > Not easy, however, prescaler value is ((1 << 21) - 1) which someone
> > > > might consider as (1 << 21) with lost in precision.
> > > > 
> > > > Thus, shift on 20 bits right, add last bit to the value and shift on 1
> > > > bit right more.
> > > > 
> > > Sorry, I am missing something. do_div() should work fine with any 32 bit 
> > > value
> > > as divisor, no matter what that value is. Why does it fail here ? And why 
> > > does
> > > it work if I pass 0x1f as second parameter to do_div() directly ?
> > 
> > Please let me know what i can do here to help solve the problem.
> > linux-next continues to fail for avr32, and to make matters worse we
> > also have the similar problem in btrfs.
> > 
> > ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
> > ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> > 
> > Adding Chris to CC if he has some idea how to solve this error for btrfs.
> > Build log for next-20160429 is at:
> > https://travis-ci.org/sudipm-mukherjee/parport/jobs/126581065
> > 
> 
> Try the patch below.
> 
> Guenter
> 
Sorry, patch wasn't complete.

Guenter

---
>From c684f2cf54ecb256007288af23c24bfcdb2bbace Mon Sep 17 00:00:00 2001
From: Guenter Roeck 
Date: Sat, 30 Apr 2016 17:29:14 -0700
Subject: [PATCH] avr32: __div64_const32 is not ok

Building avr32 images may fail with errors such as

ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!

gcc for avr32 generates those symbols for certain constants used
as divisor in do_div(). The problem can be avoided by setting
__div64_const32_is_OK to false for the architecture.

Cc: Sudip Mukherjee 
Signed-off-by: Guenter Roeck 
---
 arch/avr32/include/asm/Kbuild  | 1 -
 arch/avr32/include/asm/div64.h | 3 +++
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 arch/avr32/include/asm/div64.h

diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild
index 241b9b9729d8..d2be4688ac7b 100644
--- a/arch/avr32/include/asm/Kbuild
+++ b/arch/avr32/include/asm/Kbuild
@@ -3,7 +3,6 @@ generic-y += clkdev.h
 generic-y += cputime.h
 generic-y += delay.h
 generic-y += device.h
-generic-y += div64.h
 generic-y += emergency-restart.h
 generic-y += exec.h
 generic-y += futex.h
diff --git a/arch/avr32/include/asm/div64.h b/arch/avr32/include/asm/div64.h
new file mode 100644
index ..1f3328e178df
--- /dev/null
+++ b/arch/avr32/include/asm/div64.h
@@ -0,0 +1,3 @@
+#define __div64_const32_is_OK  false
+
+#include 
-- 
2.5.0

[PATCH RESEND 5/5] tools: hv: lsvmbus: add pci pass-through UUID

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

lsvmbus keeps its own copy of all VMBus UUIDs, add PCIe pass-through
device there to not report 'Unknown' for such devices.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/lsvmbus |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/hv/lsvmbus b/tools/hv/lsvmbus
index 162a378..e8fecd6 100644
--- a/tools/hv/lsvmbus
+++ b/tools/hv/lsvmbus
@@ -35,6 +35,7 @@ vmbus_dev_dict = {
'{ba6163d9-04a1-4d29-b605-72e2ffb1dc7f}' : 'Synthetic SCSI Controller',
'{2f9bcc4a-0069-4af3-b76b-6fd0be528cda}' : 'Synthetic fiber channel 
adapter',
'{8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}' : 'Synthetic RDMA adapter',
+   '{44c4f61d--4400-9d52-802e27ede19f}' : 'PCI Express pass-through',
'{276aacf4-ac15-426c-98dd-7521ad3f01fe}' : '[Reserved system device]',
'{f8e65716-3cb3-4a06-9a60-1889c5cccab5}' : '[Reserved system device]',
'{3375baf4-9e15-4b30-b765-67acb10d607b}' : '[Reserved system device]',
-- 
1.7.4.1

[PATCH RESEND 3/5] Drivers: hv: balloon: don't crash when memory is added in non-sorted order

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

When we iterate through all HA regions in handle_pg_range() we have an
assumption that all these regions are sorted in the list and the
'start_pfn >= has->end_pfn' check is enough to find the proper region.
Unfortunately it's not the case with WS2016 where host can hot-add regions
in a different order. We end up modifying the wrong HA region and crashing
later on pages online. Modify the check to make sure we found the region
we were searching for while iterating. Fix the same check in pfn_covered()
as well.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b853b4b..43af913 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -714,7 +714,7 @@ static bool pfn_covered(unsigned long start_pfn, unsigned 
long pfn_cnt)
 * If the pfn range we are dealing with is not in the current
 * "hot add block", move on.
 */
-   if ((start_pfn >= has->end_pfn))
+   if (start_pfn < has->start_pfn || start_pfn >= has->end_pfn)
continue;
/*
 * If the current hot add-request extends beyond
@@ -768,7 +768,7 @@ static unsigned long handle_pg_range(unsigned long pg_start,
 * If the pfn range we are dealing with is not in the current
 * "hot add block", move on.
 */
-   if ((start_pfn >= has->end_pfn))
+   if (start_pfn < has->start_pfn || start_pfn >= has->end_pfn)
continue;
 
old_covered_state = has->covered_end_pfn;
-- 
1.7.4.1

[PATCH RESEND 5/5] tools: hv: lsvmbus: add pci pass-through UUID

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

lsvmbus keeps its own copy of all VMBus UUIDs, add PCIe pass-through
device there to not report 'Unknown' for such devices.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/lsvmbus |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/hv/lsvmbus b/tools/hv/lsvmbus
index 162a378..e8fecd6 100644
--- a/tools/hv/lsvmbus
+++ b/tools/hv/lsvmbus
@@ -35,6 +35,7 @@ vmbus_dev_dict = {
'{ba6163d9-04a1-4d29-b605-72e2ffb1dc7f}' : 'Synthetic SCSI Controller',
'{2f9bcc4a-0069-4af3-b76b-6fd0be528cda}' : 'Synthetic fiber channel 
adapter',
'{8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}' : 'Synthetic RDMA adapter',
+   '{44c4f61d--4400-9d52-802e27ede19f}' : 'PCI Express pass-through',
'{276aacf4-ac15-426c-98dd-7521ad3f01fe}' : '[Reserved system device]',
'{f8e65716-3cb3-4a06-9a60-1889c5cccab5}' : '[Reserved system device]',
'{3375baf4-9e15-4b30-b765-67acb10d607b}' : '[Reserved system device]',
-- 
1.7.4.1

[PATCH RESEND 3/5] Drivers: hv: balloon: don't crash when memory is added in non-sorted order

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

When we iterate through all HA regions in handle_pg_range() we have an
assumption that all these regions are sorted in the list and the
'start_pfn >= has->end_pfn' check is enough to find the proper region.
Unfortunately it's not the case with WS2016 where host can hot-add regions
in a different order. We end up modifying the wrong HA region and crashing
later on pages online. Modify the check to make sure we found the region
we were searching for while iterating. Fix the same check in pfn_covered()
as well.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b853b4b..43af913 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -714,7 +714,7 @@ static bool pfn_covered(unsigned long start_pfn, unsigned 
long pfn_cnt)
 * If the pfn range we are dealing with is not in the current
 * "hot add block", move on.
 */
-   if ((start_pfn >= has->end_pfn))
+   if (start_pfn < has->start_pfn || start_pfn >= has->end_pfn)
continue;
/*
 * If the current hot add-request extends beyond
@@ -768,7 +768,7 @@ static unsigned long handle_pg_range(unsigned long pg_start,
 * If the pfn range we are dealing with is not in the current
 * "hot add block", move on.
 */
-   if ((start_pfn >= has->end_pfn))
+   if (start_pfn < has->start_pfn || start_pfn >= has->end_pfn)
continue;
 
old_covered_state = has->covered_end_pfn;
-- 
1.7.4.1

[PATCH RESEND 4/5] Drivers: hv: balloon: reset host_specified_ha_region

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

We set host_specified_ha_region = true on certain request but this is a
global state which stays 'true' forever. We need to reset it when we
receive a request where ha_region is not specified. I did not see any
real issues, the bug was found by code inspection.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 43af913..df35fb7 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1400,6 +1400,7 @@ static void balloon_onchannelcallback(void *context)
 * This is a normal hot-add request specifying
 * hot-add memory.
 */
+   dm->host_specified_ha_region = false;
ha_pg_range = _msg->range;
dm->ha_wrk.ha_page_range = *ha_pg_range;
dm->ha_wrk.ha_region_range.page_range = 0;
-- 
1.7.4.1

[PATCH RESEND 1/5] Drivers: hv: kvp: fix IP Failover

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

Hyper-V VMs can be replicated to another hosts and there is a feature to
set different IP for replicas, it is called 'Failover TCP/IP'. When
such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
as we finish negotiation procedure. The problem is that it can happen (and
it actually happens) before userspace daemon connects and we reply with
HV_E_FAIL to the message. As there are no repetitions we fail to set the
requested IP.

Solve the issue by postponing our reply to the negotiation message till
userspace daemon is connected. We can't wait too long as there is a
host-side timeout (cca. 75 seconds) and if we fail to reply in this time
frame the whole KVP service will become inactive. The solution is not
ideal - if it takes userspace daemon more than 60 seconds to connect
IP Failover will still fail but I don't see a solution with our current
separation between kernel and userspace parts.

Other two modules (VSS and FCOPY) don't require such delay, leave them
untouched.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_kvp.c   |   31 +++
 drivers/hv/hyperv_vmbus.h |5 +
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 9b9b370..cb1a916 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -78,9 +78,11 @@ static void kvp_send_key(struct work_struct *dummy);
 
 static void kvp_respond_to_host(struct hv_kvp_msg *msg, int error);
 static void kvp_timeout_func(struct work_struct *dummy);
+static void kvp_host_handshake_func(struct work_struct *dummy);
 static void kvp_register(int);
 
 static DECLARE_DELAYED_WORK(kvp_timeout_work, kvp_timeout_func);
+static DECLARE_DELAYED_WORK(kvp_host_handshake_work, kvp_host_handshake_func);
 static DECLARE_WORK(kvp_sendkey_work, kvp_send_key);
 
 static const char kvp_devname[] = "vmbus/hv_kvp";
@@ -130,6 +132,11 @@ static void kvp_timeout_func(struct work_struct *dummy)
hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
 }
 
+static void kvp_host_handshake_func(struct work_struct *dummy)
+{
+   hv_poll_channel(kvp_transaction.recv_channel, hv_kvp_onchannelcallback);
+}
+
 static int kvp_handle_handshake(struct hv_kvp_msg *msg)
 {
switch (msg->kvp_hdr.operation) {
@@ -154,6 +161,12 @@ static int kvp_handle_handshake(struct hv_kvp_msg *msg)
pr_debug("KVP: userspace daemon ver. %d registered\n",
 KVP_OP_REGISTER);
kvp_register(dm_reg_value);
+
+   /*
+* If we're still negotiating with the host cancel the timeout
+* work to not poll the channel twice.
+*/
+   cancel_delayed_work_sync(_host_handshake_work);
hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
 
return 0;
@@ -594,7 +607,22 @@ void hv_kvp_onchannelcallback(void *context)
struct icmsg_negotiate *negop = NULL;
int util_fw_version;
int kvp_srv_version;
+   static enum {NEGO_NOT_STARTED,
+NEGO_IN_PROGRESS,
+NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
 
+   if (host_negotiatied == NEGO_NOT_STARTED &&
+   kvp_transaction.state < HVUTIL_READY) {
+   /*
+* If userspace daemon is not connected and host is asking
+* us to negotiate we need to delay to not lose messages.
+* This is important for Failover IP setting.
+*/
+   host_negotiatied = NEGO_IN_PROGRESS;
+   schedule_delayed_work(_host_handshake_work,
+ HV_UTIL_NEGO_TIMEOUT * HZ);
+   return;
+   }
if (kvp_transaction.state > HVUTIL_READY)
return;
 
@@ -672,6 +700,8 @@ void hv_kvp_onchannelcallback(void *context)
vmbus_sendpacket(channel, recv_buffer,
   recvlen, requestid,
   VM_PKT_DATA_INBAND, 0);
+
+   host_negotiatied = NEGO_FINISHED;
}
 
 }
@@ -708,6 +738,7 @@ hv_kvp_init(struct hv_util_service *srv)
 void hv_kvp_deinit(void)
 {
kvp_transaction.state = HVUTIL_DEVICE_DYING;
+   cancel_delayed_work_sync(_host_handshake_work);
cancel_delayed_work_sync(_timeout_work);
cancel_work_sync(_sendkey_work);
hvutil_transport_destroy(hvt);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e5c586f..e5203e4 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -36,6 +36,11 @@
 #define HV_UTIL_TIMEOUT 30
 
 /*
+ * Timeout for guest-host handshake for services.
+ */
+#define HV_UTIL_NEGO_TIMEOUT 60
+
+/*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
  * is set by CPUID(HVCPUID_VERSION_FEATURES).
  */
-- 
1.7.4.1

[PATCH RESEND 2/5] Drivers: hv: vmbus: handle various crash scenarios

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
delivered to the CPU which was used for initial contact or to CPU0
depending on host version. vmbus_wait_for_unload() doesn't account for
the fact that in case we're crashing on some other CPU we won't get the
CHANNELMSG_UNLOAD_RESPONSE message and our wait on the current CPU will
never end.

Do the following:
1) Check for completion_done() in the loop. In case interrupt handler is
   still alive we'll get the confirmation we need.

2) Read message pages for all CPUs message page as we're unsure where
   CHANNELMSG_UNLOAD_RESPONSE is going to be delivered to. We can race with
   still-alive interrupt handler doing the same, add cmpxchg() to
   vmbus_signal_eom() to not lose CHANNELMSG_UNLOAD_RESPONSE message.

3) Cleanup message pages on all CPUs. This is required (at least for the
   current CPU as we're clearing CPU0 messages now but we may want to bring
   up additional CPUs on crash) as new messages won't be delivered till we
   consume what's pending. On boot we'll place message pages somewhere else
   and we won't be able to read stale messages.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel_mgmt.c |   58 +---
 drivers/hv/hyperv_vmbus.h |   16 +++-
 drivers/hv/vmbus_drv.c|7 +++--
 3 files changed, 61 insertions(+), 20 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 38b682ba..b6c1211 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -597,27 +597,55 @@ static void init_vp_index(struct vmbus_channel *channel, 
u16 dev_type)
 
 static void vmbus_wait_for_unload(void)
 {
-   int cpu = smp_processor_id();
-   void *page_addr = hv_context.synic_message_page[cpu];
-   struct hv_message *msg = (struct hv_message *)page_addr +
- VMBUS_MESSAGE_SINT;
+   int cpu;
+   void *page_addr;
+   struct hv_message *msg;
struct vmbus_channel_message_header *hdr;
-   bool unloaded = false;
+   u32 message_type;
 
+   /*
+* CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was
+* used for initial contact or to CPU0 depending on host version. When
+* we're crashing on a different CPU let's hope that IRQ handler on
+* the cpu which receives CHANNELMSG_UNLOAD_RESPONSE is still
+* functional and vmbus_unload_response() will complete
+* vmbus_connection.unload_event. If not, the last thing we can do is
+* read message pages for all CPUs directly.
+*/
while (1) {
-   if (READ_ONCE(msg->header.message_type) == HVMSG_NONE) {
-   mdelay(10);
-   continue;
-   }
+   if (completion_done(_connection.unload_event))
+   break;
 
-   hdr = (struct vmbus_channel_message_header *)msg->u.payload;
-   if (hdr->msgtype == CHANNELMSG_UNLOAD_RESPONSE)
-   unloaded = true;
+   for_each_online_cpu(cpu) {
+   page_addr = hv_context.synic_message_page[cpu];
+   msg = (struct hv_message *)page_addr +
+   VMBUS_MESSAGE_SINT;
 
-   vmbus_signal_eom(msg);
+   message_type = READ_ONCE(msg->header.message_type);
+   if (message_type == HVMSG_NONE)
+   continue;
 
-   if (unloaded)
-   break;
+   hdr = (struct vmbus_channel_message_header *)
+   msg->u.payload;
+
+   if (hdr->msgtype == CHANNELMSG_UNLOAD_RESPONSE)
+   complete(_connection.unload_event);
+
+   vmbus_signal_eom(msg, message_type);
+   }
+
+   mdelay(10);
+   }
+
+   /*
+* We're crashing and already got the UNLOAD_RESPONSE, cleanup all
+* maybe-pending messages on all CPUs to be able to receive new
+* messages after we reconnect.
+*/
+   for_each_online_cpu(cpu) {
+   page_addr = hv_context.synic_message_page[cpu];
+   msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
+   msg->header.message_type = HVMSG_NONE;
}
 }
 
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e5203e4..718b5c7 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -625,9 +625,21 @@ extern struct vmbus_channel_message_table_entry
channel_message_table[CHANNELMSG_COUNT];
 
 /* Free the message slot and signal end-of-message if required */
-static inline void vmbus_signal_eom(struct hv_message *msg)
+static inline void vmbus_signal_eom(struct

[PATCH RESEND 4/5] Drivers: hv: balloon: reset host_specified_ha_region

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

We set host_specified_ha_region = true on certain request but this is a
global state which stays 'true' forever. We need to reset it when we
receive a request where ha_region is not specified. I did not see any
real issues, the bug was found by code inspection.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 43af913..df35fb7 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1400,6 +1400,7 @@ static void balloon_onchannelcallback(void *context)
 * This is a normal hot-add request specifying
 * hot-add memory.
 */
+   dm->host_specified_ha_region = false;
ha_pg_range = _msg->range;
dm->ha_wrk.ha_page_range = *ha_pg_range;
dm->ha_wrk.ha_region_range.page_range = 0;
-- 
1.7.4.1

[PATCH RESEND 1/5] Drivers: hv: kvp: fix IP Failover

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

Hyper-V VMs can be replicated to another hosts and there is a feature to
set different IP for replicas, it is called 'Failover TCP/IP'. When
such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
as we finish negotiation procedure. The problem is that it can happen (and
it actually happens) before userspace daemon connects and we reply with
HV_E_FAIL to the message. As there are no repetitions we fail to set the
requested IP.

Solve the issue by postponing our reply to the negotiation message till
userspace daemon is connected. We can't wait too long as there is a
host-side timeout (cca. 75 seconds) and if we fail to reply in this time
frame the whole KVP service will become inactive. The solution is not
ideal - if it takes userspace daemon more than 60 seconds to connect
IP Failover will still fail but I don't see a solution with our current
separation between kernel and userspace parts.

Other two modules (VSS and FCOPY) don't require such delay, leave them
untouched.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_kvp.c   |   31 +++
 drivers/hv/hyperv_vmbus.h |5 +
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 9b9b370..cb1a916 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -78,9 +78,11 @@ static void kvp_send_key(struct work_struct *dummy);
 
 static void kvp_respond_to_host(struct hv_kvp_msg *msg, int error);
 static void kvp_timeout_func(struct work_struct *dummy);
+static void kvp_host_handshake_func(struct work_struct *dummy);
 static void kvp_register(int);
 
 static DECLARE_DELAYED_WORK(kvp_timeout_work, kvp_timeout_func);
+static DECLARE_DELAYED_WORK(kvp_host_handshake_work, kvp_host_handshake_func);
 static DECLARE_WORK(kvp_sendkey_work, kvp_send_key);
 
 static const char kvp_devname[] = "vmbus/hv_kvp";
@@ -130,6 +132,11 @@ static void kvp_timeout_func(struct work_struct *dummy)
hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
 }
 
+static void kvp_host_handshake_func(struct work_struct *dummy)
+{
+   hv_poll_channel(kvp_transaction.recv_channel, hv_kvp_onchannelcallback);
+}
+
 static int kvp_handle_handshake(struct hv_kvp_msg *msg)
 {
switch (msg->kvp_hdr.operation) {
@@ -154,6 +161,12 @@ static int kvp_handle_handshake(struct hv_kvp_msg *msg)
pr_debug("KVP: userspace daemon ver. %d registered\n",
 KVP_OP_REGISTER);
kvp_register(dm_reg_value);
+
+   /*
+* If we're still negotiating with the host cancel the timeout
+* work to not poll the channel twice.
+*/
+   cancel_delayed_work_sync(_host_handshake_work);
hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
 
return 0;
@@ -594,7 +607,22 @@ void hv_kvp_onchannelcallback(void *context)
struct icmsg_negotiate *negop = NULL;
int util_fw_version;
int kvp_srv_version;
+   static enum {NEGO_NOT_STARTED,
+NEGO_IN_PROGRESS,
+NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
 
+   if (host_negotiatied == NEGO_NOT_STARTED &&
+   kvp_transaction.state < HVUTIL_READY) {
+   /*
+* If userspace daemon is not connected and host is asking
+* us to negotiate we need to delay to not lose messages.
+* This is important for Failover IP setting.
+*/
+   host_negotiatied = NEGO_IN_PROGRESS;
+   schedule_delayed_work(_host_handshake_work,
+ HV_UTIL_NEGO_TIMEOUT * HZ);
+   return;
+   }
if (kvp_transaction.state > HVUTIL_READY)
return;
 
@@ -672,6 +700,8 @@ void hv_kvp_onchannelcallback(void *context)
vmbus_sendpacket(channel, recv_buffer,
   recvlen, requestid,
   VM_PKT_DATA_INBAND, 0);
+
+   host_negotiatied = NEGO_FINISHED;
}
 
 }
@@ -708,6 +738,7 @@ hv_kvp_init(struct hv_util_service *srv)
 void hv_kvp_deinit(void)
 {
kvp_transaction.state = HVUTIL_DEVICE_DYING;
+   cancel_delayed_work_sync(_host_handshake_work);
cancel_delayed_work_sync(_timeout_work);
cancel_work_sync(_sendkey_work);
hvutil_transport_destroy(hvt);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e5c586f..e5203e4 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -36,6 +36,11 @@
 #define HV_UTIL_TIMEOUT 30
 
 /*
+ * Timeout for guest-host handshake for services.
+ */
+#define HV_UTIL_NEGO_TIMEOUT 60
+
+/*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
  * is set by CPUID(HVCPUID_VERSION_FEATURES).
  */
-- 
1.7.4.1

[PATCH RESEND 2/5] Drivers: hv: vmbus: handle various crash scenarios

2016-04-30 Thread K. Y. Srinivasan 
From: Vitaly Kuznetsov 

Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
delivered to the CPU which was used for initial contact or to CPU0
depending on host version. vmbus_wait_for_unload() doesn't account for
the fact that in case we're crashing on some other CPU we won't get the
CHANNELMSG_UNLOAD_RESPONSE message and our wait on the current CPU will
never end.

Do the following:
1) Check for completion_done() in the loop. In case interrupt handler is
   still alive we'll get the confirmation we need.

2) Read message pages for all CPUs message page as we're unsure where
   CHANNELMSG_UNLOAD_RESPONSE is going to be delivered to. We can race with
   still-alive interrupt handler doing the same, add cmpxchg() to
   vmbus_signal_eom() to not lose CHANNELMSG_UNLOAD_RESPONSE message.

3) Cleanup message pages on all CPUs. This is required (at least for the
   current CPU as we're clearing CPU0 messages now but we may want to bring
   up additional CPUs on crash) as new messages won't be delivered till we
   consume what's pending. On boot we'll place message pages somewhere else
   and we won't be able to read stale messages.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel_mgmt.c |   58 +---
 drivers/hv/hyperv_vmbus.h |   16 +++-
 drivers/hv/vmbus_drv.c|7 +++--
 3 files changed, 61 insertions(+), 20 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 38b682ba..b6c1211 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -597,27 +597,55 @@ static void init_vp_index(struct vmbus_channel *channel, 
u16 dev_type)
 
 static void vmbus_wait_for_unload(void)
 {
-   int cpu = smp_processor_id();
-   void *page_addr = hv_context.synic_message_page[cpu];
-   struct hv_message *msg = (struct hv_message *)page_addr +
- VMBUS_MESSAGE_SINT;
+   int cpu;
+   void *page_addr;
+   struct hv_message *msg;
struct vmbus_channel_message_header *hdr;
-   bool unloaded = false;
+   u32 message_type;
 
+   /*
+* CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was
+* used for initial contact or to CPU0 depending on host version. When
+* we're crashing on a different CPU let's hope that IRQ handler on
+* the cpu which receives CHANNELMSG_UNLOAD_RESPONSE is still
+* functional and vmbus_unload_response() will complete
+* vmbus_connection.unload_event. If not, the last thing we can do is
+* read message pages for all CPUs directly.
+*/
while (1) {
-   if (READ_ONCE(msg->header.message_type) == HVMSG_NONE) {
-   mdelay(10);
-   continue;
-   }
+   if (completion_done(_connection.unload_event))
+   break;
 
-   hdr = (struct vmbus_channel_message_header *)msg->u.payload;
-   if (hdr->msgtype == CHANNELMSG_UNLOAD_RESPONSE)
-   unloaded = true;
+   for_each_online_cpu(cpu) {
+   page_addr = hv_context.synic_message_page[cpu];
+   msg = (struct hv_message *)page_addr +
+   VMBUS_MESSAGE_SINT;
 
-   vmbus_signal_eom(msg);
+   message_type = READ_ONCE(msg->header.message_type);
+   if (message_type == HVMSG_NONE)
+   continue;
 
-   if (unloaded)
-   break;
+   hdr = (struct vmbus_channel_message_header *)
+   msg->u.payload;
+
+   if (hdr->msgtype == CHANNELMSG_UNLOAD_RESPONSE)
+   complete(_connection.unload_event);
+
+   vmbus_signal_eom(msg, message_type);
+   }
+
+   mdelay(10);
+   }
+
+   /*
+* We're crashing and already got the UNLOAD_RESPONSE, cleanup all
+* maybe-pending messages on all CPUs to be able to receive new
+* messages after we reconnect.
+*/
+   for_each_online_cpu(cpu) {
+   page_addr = hv_context.synic_message_page[cpu];
+   msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
+   msg->header.message_type = HVMSG_NONE;
}
 }
 
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e5203e4..718b5c7 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -625,9 +625,21 @@ extern struct vmbus_channel_message_table_entry
channel_message_table[CHANNELMSG_COUNT];
 
 /* Free the message slot and signal end-of-message if required */
-static inline void vmbus_signal_eom(struct hv_message *msg)
+static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
 {
-

[PATCH RESEND 0/5] Drivers: hv: Some miscellaneous fixes

2016-04-30 Thread K. Y. Srinivasan 
Some miscellaneous fixes. All these patches are being resent.

Vitaly Kuznetsov (5):
  Drivers: hv: kvp: fix IP Failover
  Drivers: hv: vmbus: handle various crash scenarios
  Drivers: hv: balloon: don't crash when memory is added in non-sorted
order
  Drivers: hv: balloon: reset host_specified_ha_region
  tools: hv: lsvmbus: add pci pass-through UUID

 drivers/hv/channel_mgmt.c |   58 +---
 drivers/hv/hv_balloon.c   |5 ++-
 drivers/hv/hv_kvp.c   |   31 
 drivers/hv/hyperv_vmbus.h |   21 ++-
 drivers/hv/vmbus_drv.c|7 +++--
 tools/hv/lsvmbus  |1 +
 6 files changed, 101 insertions(+), 22 deletions(-)

-- 
1.7.4.1

[PATCH RESEND 0/5] Drivers: hv: Some miscellaneous fixes

2016-04-30 Thread K. Y. Srinivasan 
Some miscellaneous fixes. All these patches are being resent.

Vitaly Kuznetsov (5):
  Drivers: hv: kvp: fix IP Failover
  Drivers: hv: vmbus: handle various crash scenarios
  Drivers: hv: balloon: don't crash when memory is added in non-sorted
order
  Drivers: hv: balloon: reset host_specified_ha_region
  tools: hv: lsvmbus: add pci pass-through UUID

 drivers/hv/channel_mgmt.c |   58 +---
 drivers/hv/hv_balloon.c   |5 ++-
 drivers/hv/hv_kvp.c   |   31 
 drivers/hv/hyperv_vmbus.h |   21 ++-
 drivers/hv/vmbus_drv.c|7 +++--
 tools/hv/lsvmbus  |1 +
 6 files changed, 101 insertions(+), 22 deletions(-)

-- 
1.7.4.1

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

2016-04-30 Thread Guenter Roeck 
On Sat, Apr 30, 2016 at 07:38:28PM +0100, Sudip Mukherjee wrote:
> On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote:
> > On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee
> > >  wrote:
> > > > On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote:
> > > >>
> > > >> On 04/11/2016 10:51 PM, Sudip Mukherjee wrote:
> > > >>>
> > > >>> The build of avr32 allmodconfig fails with the error:
> > > >>> ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> > > >>>
> > > >> This means there is a direct 64 bit divide operation in the driver,
> > > >> which we should identify and fix.
> > > 
> > > This driver will quite likely never be used on AVR32. Do we need to
> > > fix this due to some other architectures?
> > > 
> > > > yes, there is.
> > > >
> > > > in function: kempld_wdt_set_stage_timeout()
> > > > remainder = do_div(stage_timeout64, prescaler);
> > > 
> > > > Any idea how to fix it?
> > > 
> > > Not easy, however, prescaler value is ((1 << 21) - 1) which someone
> > > might consider as (1 << 21) with lost in precision.
> > > 
> > > Thus, shift on 20 bits right, add last bit to the value and shift on 1
> > > bit right more.
> > > 
> > Sorry, I am missing something. do_div() should work fine with any 32 bit 
> > value
> > as divisor, no matter what that value is. Why does it fail here ? And why 
> > does
> > it work if I pass 0x1f as second parameter to do_div() directly ?
> 
> Please let me know what i can do here to help solve the problem.
> linux-next continues to fail for avr32, and to make matters worse we
> also have the similar problem in btrfs.
> 
> ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
> ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> 
> Adding Chris to CC if he has some idea how to solve this error for btrfs.
> Build log for next-20160429 is at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/126581065
> 

Try the patch below.

Guenter

---
>From d2f541c46ae2bf599d9aa3be0682cfac76742ebf Mon Sep 17 00:00:00 2001
From: Guenter Roeck 
Date: Sat, 30 Apr 2016 17:29:14 -0700
Subject: [PATCH] avr32: __div64_const32 is not ok

Building avr32 images may fail with errors such as

ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!

gcc for avr32 generates those symbols for certain constants used
as divisor in do_div(). The problem can be avoided by setting
__div64_const32_is_OK to false for the architecture.

Cc: Sudip Mukherjee 
Signed-off-by: Guenter Roeck 
---
 arch/avr32/include/asm/div64.h | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 arch/avr32/include/asm/div64.h

diff --git a/arch/avr32/include/asm/div64.h b/arch/avr32/include/asm/div64.h
new file mode 100644
index ..1f3328e178df
--- /dev/null
+++ b/arch/avr32/include/asm/div64.h
@@ -0,0 +1,3 @@
+#define __div64_const32_is_OK  false
+
+#include 
-- 
2.5.0

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

2016-04-30 Thread Guenter Roeck 
On Sat, Apr 30, 2016 at 07:38:28PM +0100, Sudip Mukherjee wrote:
> On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote:
> > On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee
> > >  wrote:
> > > > On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote:
> > > >>
> > > >> On 04/11/2016 10:51 PM, Sudip Mukherjee wrote:
> > > >>>
> > > >>> The build of avr32 allmodconfig fails with the error:
> > > >>> ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> > > >>>
> > > >> This means there is a direct 64 bit divide operation in the driver,
> > > >> which we should identify and fix.
> > > 
> > > This driver will quite likely never be used on AVR32. Do we need to
> > > fix this due to some other architectures?
> > > 
> > > > yes, there is.
> > > >
> > > > in function: kempld_wdt_set_stage_timeout()
> > > > remainder = do_div(stage_timeout64, prescaler);
> > > 
> > > > Any idea how to fix it?
> > > 
> > > Not easy, however, prescaler value is ((1 << 21) - 1) which someone
> > > might consider as (1 << 21) with lost in precision.
> > > 
> > > Thus, shift on 20 bits right, add last bit to the value and shift on 1
> > > bit right more.
> > > 
> > Sorry, I am missing something. do_div() should work fine with any 32 bit 
> > value
> > as divisor, no matter what that value is. Why does it fail here ? And why 
> > does
> > it work if I pass 0x1f as second parameter to do_div() directly ?
> 
> Please let me know what i can do here to help solve the problem.
> linux-next continues to fail for avr32, and to make matters worse we
> also have the similar problem in btrfs.
> 
> ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
> ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!
> 
> Adding Chris to CC if he has some idea how to solve this error for btrfs.
> Build log for next-20160429 is at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/126581065
> 

Try the patch below.

Guenter

---
>From d2f541c46ae2bf599d9aa3be0682cfac76742ebf Mon Sep 17 00:00:00 2001
From: Guenter Roeck 
Date: Sat, 30 Apr 2016 17:29:14 -0700
Subject: [PATCH] avr32: __div64_const32 is not ok

Building avr32 images may fail with errors such as

ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!

gcc for avr32 generates those symbols for certain constants used
as divisor in do_div(). The problem can be avoided by setting
__div64_const32_is_OK to false for the architecture.

Cc: Sudip Mukherjee 
Signed-off-by: Guenter Roeck 
---
 arch/avr32/include/asm/div64.h | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 arch/avr32/include/asm/div64.h

diff --git a/arch/avr32/include/asm/div64.h b/arch/avr32/include/asm/div64.h
new file mode 100644
index ..1f3328e178df
--- /dev/null
+++ b/arch/avr32/include/asm/div64.h
@@ -0,0 +1,3 @@
+#define __div64_const32_is_OK  false
+
+#include 
-- 
2.5.0

RE: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

2016-04-30 Thread KY Srinivasan 


> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, April 30, 2016 2:54 PM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com
> Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> 
> On Sat, Apr 30, 2016 at 09:43:09PM +, KY Srinivasan wrote:
> >
> >
> > > -Original Message-
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > Sent: Saturday, April 30, 2016 2:05 PM
> > > To: KY Srinivasan 
> > > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> > > jasow...@redhat.com
> > > Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> > >
> > > On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> > > > From: Vitaly Kuznetsov 
> > > >
> > > > Hyper-V VMs can be replicated to another hosts and there is a feature
> to
> > > > set different IP for replicas, it is called 'Failover TCP/IP'. When
> > > > such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message
> as
> > > soon
> > > > as we finish negotiation procedure. The problem is that it can happen
> (and
> > > > it actually happens) before userspace daemon connects and we reply
> with
> > > > HV_E_FAIL to the message. As there are no repetitions we fail to set
> the
> > > > requested IP.
> > > >
> > > > Solve the issue by postponing our reply to the negotiation message till
> > > > userspace daemon is connected. We can't wait too long as there is a
> > > > host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> > > > frame the whole KVP service will become inactive. The solution is not
> > > > ideal - if it takes userspace daemon more than 60 seconds to connect
> > > > IP Failover will still fail but I don't see a solution with our current
> > > > separation between kernel and userspace parts.
> > > >
> > > > Other two modules (VSS and FCOPY) don't require such delay, leave
> them
> > > > untouched.
> > > >
> > > > Signed-off-by: Vitaly Kuznetsov 
> > > > Signed-off-by: K. Y. Srinivasan 
> > > > ---
> > > >  drivers/hv/hv_kvp.c   |   31 +++
> > > >  drivers/hv/hyperv_vmbus.h |5 +
> > > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > >
> > > This series doesn't apply to my tree :(
> >
> > Looks like you have already applied most of the patches in this series. I 
> > will
> resend what is not applied.
> 
> If this was a "resend", why didn't it show that in the patch
> description?

My fault; sorry for the confusion. Greg, I am going to resend all the 
patches yet to be committed with the right "resend" tag.

Regards,

K. Y

RE: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

2016-04-30 Thread KY Srinivasan 


> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, April 30, 2016 2:54 PM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com
> Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> 
> On Sat, Apr 30, 2016 at 09:43:09PM +, KY Srinivasan wrote:
> >
> >
> > > -Original Message-
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > Sent: Saturday, April 30, 2016 2:05 PM
> > > To: KY Srinivasan 
> > > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> > > jasow...@redhat.com
> > > Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> > >
> > > On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> > > > From: Vitaly Kuznetsov 
> > > >
> > > > Hyper-V VMs can be replicated to another hosts and there is a feature
> to
> > > > set different IP for replicas, it is called 'Failover TCP/IP'. When
> > > > such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message
> as
> > > soon
> > > > as we finish negotiation procedure. The problem is that it can happen
> (and
> > > > it actually happens) before userspace daemon connects and we reply
> with
> > > > HV_E_FAIL to the message. As there are no repetitions we fail to set
> the
> > > > requested IP.
> > > >
> > > > Solve the issue by postponing our reply to the negotiation message till
> > > > userspace daemon is connected. We can't wait too long as there is a
> > > > host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> > > > frame the whole KVP service will become inactive. The solution is not
> > > > ideal - if it takes userspace daemon more than 60 seconds to connect
> > > > IP Failover will still fail but I don't see a solution with our current
> > > > separation between kernel and userspace parts.
> > > >
> > > > Other two modules (VSS and FCOPY) don't require such delay, leave
> them
> > > > untouched.
> > > >
> > > > Signed-off-by: Vitaly Kuznetsov 
> > > > Signed-off-by: K. Y. Srinivasan 
> > > > ---
> > > >  drivers/hv/hv_kvp.c   |   31 +++
> > > >  drivers/hv/hyperv_vmbus.h |5 +
> > > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > >
> > > This series doesn't apply to my tree :(
> >
> > Looks like you have already applied most of the patches in this series. I 
> > will
> resend what is not applied.
> 
> If this was a "resend", why didn't it show that in the patch
> description?

My fault; sorry for the confusion. Greg, I am going to resend all the 
patches yet to be committed with the right "resend" tag.

Regards,

K. Y

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

2016-04-30 Thread Guenter Roeck 

On 04/30/2016 11:38 AM, Sudip Mukherjee wrote:

On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote:

On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote:

On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee
 wrote:

On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote:


On 04/11/2016 10:51 PM, Sudip Mukherjee wrote:


The build of avr32 allmodconfig fails with the error:
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!


This means there is a direct 64 bit divide operation in the driver,
which we should identify and fix.


This driver will quite likely never be used on AVR32. Do we need to
fix this due to some other architectures?


yes, there is.

in function: kempld_wdt_set_stage_timeout()
remainder = do_div(stage_timeout64, prescaler);



Any idea how to fix it?


Not easy, however, prescaler value is ((1 << 21) - 1) which someone
might consider as (1 << 21) with lost in precision.

Thus, shift on 20 bits right, add last bit to the value and shift on 1
bit right more.


Sorry, I am missing something. do_div() should work fine with any 32 bit value
as divisor, no matter what that value is. Why does it fail here ? And why does
it work if I pass 0x1f as second parameter to do_div() directly ?


Please let me know what i can do here to help solve the problem.
linux-next continues to fail for avr32, and to make matters worse we
also have the similar problem in btrfs.

ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!



Pretty much what I suspected would happen. Oddly enough, the symbol was defined
in early avr32 patch sets [1], but dropped in the final commit after some
discussion [2]. Makes me wonder if the problem was always known.

Guenter


Adding Chris to CC if he has some idea how to solve this error for btrfs.
Build log for next-20160429 is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/126581065

regards
sudip


---
[1] https://kldp.org/files/linux-2.6.16.11-avr32-20060626.patch_.txt
[2] 
http://fa.linux.kernel.narkive.com/4UhaxiM4/avr32-architecture-patch-against-linux-2-6-18-rc1-available

Re: [PATCH] watchdog: dw_wdt: dont build for avr32

2016-04-30 Thread Guenter Roeck 

On 04/30/2016 11:38 AM, Sudip Mukherjee wrote:

On Tue, Apr 12, 2016 at 11:01:28AM -0700, Guenter Roeck wrote:

On Tue, Apr 12, 2016 at 05:58:20PM +0300, Andy Shevchenko wrote:

On Tue, Apr 12, 2016 at 4:39 PM, Sudip Mukherjee
 wrote:

On Tuesday 12 April 2016 06:36 PM, Guenter Roeck wrote:


On 04/11/2016 10:51 PM, Sudip Mukherjee wrote:


The build of avr32 allmodconfig fails with the error:
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!


This means there is a direct 64 bit divide operation in the driver,
which we should identify and fix.


This driver will quite likely never be used on AVR32. Do we need to
fix this due to some other architectures?


yes, there is.

in function: kempld_wdt_set_stage_timeout()
remainder = do_div(stage_timeout64, prescaler);



Any idea how to fix it?


Not easy, however, prescaler value is ((1 << 21) - 1) which someone
might consider as (1 << 21) with lost in precision.

Thus, shift on 20 bits right, add last bit to the value and shift on 1
bit right more.


Sorry, I am missing something. do_div() should work fine with any 32 bit value
as divisor, no matter what that value is. Why does it fail here ? And why does
it work if I pass 0x1f as second parameter to do_div() directly ?


Please let me know what i can do here to help solve the problem.
linux-next continues to fail for avr32, and to make matters worse we
also have the similar problem in btrfs.

ERROR: "__avr32_udiv64" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__avr32_udiv64" [drivers/watchdog/kempld_wdt.ko] undefined!



Pretty much what I suspected would happen. Oddly enough, the symbol was defined
in early avr32 patch sets [1], but dropped in the final commit after some
discussion [2]. Makes me wonder if the problem was always known.

Guenter


Adding Chris to CC if he has some idea how to solve this error for btrfs.
Build log for next-20160429 is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/126581065

regards
sudip


---
[1] https://kldp.org/files/linux-2.6.16.11-avr32-20060626.patch_.txt
[2] 
http://fa.linux.kernel.narkive.com/4UhaxiM4/avr32-architecture-patch-against-linux-2-6-18-rc1-available

Re: [PATCH] efibc: avoid stack overflow warning

2016-04-30 Thread Arnd Bergmann 
On Saturday 30 April 2016 23:46:41 Matt Fleming wrote:
> 
> > It's not something we'd have to worry about in practice, but it does
> > make my patch incorrect. Should we come up with a different way to
> > do it?
> 
> Jeremy proposed a patch to dynamically allocate the memory, which I
> think is the correct way to go given that our (reasonable) assumptions
> about reboot notifier concurrency are not guaranteed,
> 
>   https://lkml.kernel.org/r/87h9eked24@jcompost-mobl1.tl.intel.com

Sure, that works. I considered doing it that way but it seemed more
complicated. Please use that patch instead of mine.

Arnd

Re: [PATCH] efibc: avoid stack overflow warning

2016-04-30 Thread Arnd Bergmann 
On Saturday 30 April 2016 23:46:41 Matt Fleming wrote:
> 
> > It's not something we'd have to worry about in practice, but it does
> > make my patch incorrect. Should we come up with a different way to
> > do it?
> 
> Jeremy proposed a patch to dynamically allocate the memory, which I
> think is the correct way to go given that our (reasonable) assumptions
> about reboot notifier concurrency are not guaranteed,
> 
>   https://lkml.kernel.org/r/87h9eked24@jcompost-mobl1.tl.intel.com

Sure, that works. I considered doing it that way but it seemed more
complicated. Please use that patch instead of mine.

Arnd

Re: [PATCH 3.16 000/217] 3.16.35-rc1 review

2016-04-30 Thread Guenter Roeck 

On 04/30/2016 12:44 PM, Ben Hutchings wrote:

On Thu, 2016-04-28 at 21:16 -0700, Guenter Roeck wrote:

On 04/26/2016 04:02 PM, Ben Hutchings wrote:


This is the start of the stable review cycle for the 3.16.35 release.
There are 217 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Apr 30 22:00:00 UTC 2016.
Anything received after that time might be too late.


Updated build and test results:

Build results:
total: 137 pass: 135 fail: 2
Failed builds:
arc:allnoconfig
arm64:allmodconfig

Qemu test results:
total: 97 pass: 94 fail: 3
Failed tests:
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706


Update:

This failure was sporadic and easily fixed by adding "rootwait"
to the command line options.

Guenter


arm64:smp:defconfig
arm64:nosmp:defconfig

This is after dropping a couple of builds and qemu tests which are
known to be bad in 3.16, and after some fixes in the tree.

The arm64 build failure is due to gcc5, which needs a patch from a
later kernel. The other failures are new and did not occur in 3.16.7.

A bisect of the arm64 qemu failure points to commit f98ab7a1e78
("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't
make any progress"). Unfortunately, that is inconclusive, since there
have been several follow-up commits trying to fix it. After reverting
all those commits, the test still fails.


Thank you very much for the analysis.  I'll look at the failures later
as none of them appear to be related to the current patch series.

Ben.

Re: [PATCH 3.16 000/217] 3.16.35-rc1 review

2016-04-30 Thread Guenter Roeck 

On 04/30/2016 12:44 PM, Ben Hutchings wrote:

On Thu, 2016-04-28 at 21:16 -0700, Guenter Roeck wrote:

On 04/26/2016 04:02 PM, Ben Hutchings wrote:


This is the start of the stable review cycle for the 3.16.35 release.
There are 217 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Apr 30 22:00:00 UTC 2016.
Anything received after that time might be too late.


Updated build and test results:

Build results:
total: 137 pass: 135 fail: 2
Failed builds:
arc:allnoconfig
arm64:allmodconfig

Qemu test results:
total: 97 pass: 94 fail: 3
Failed tests:
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706


Update:

This failure was sporadic and easily fixed by adding "rootwait"
to the command line options.

Guenter


arm64:smp:defconfig
arm64:nosmp:defconfig

This is after dropping a couple of builds and qemu tests which are
known to be bad in 3.16, and after some fixes in the tree.

The arm64 build failure is due to gcc5, which needs a patch from a
later kernel. The other failures are new and did not occur in 3.16.7.

A bisect of the arm64 qemu failure points to commit f98ab7a1e78
("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't
make any progress"). Unfortunately, that is inconclusive, since there
have been several follow-up commits trying to fix it. After reverting
all those commits, the test still fails.


Thank you very much for the analysis.  I'll look at the failures later
as none of them appear to be related to the current patch series.

Ben.

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

2016-04-30 Thread Josh Triplett 
On Sat, Apr 30, 2016 at 11:35:14PM +0100, Matt Fleming wrote:
> (Adding Colin and Ricardo)
> 
> On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote:
> > 
> > How is an end user supposed to see such a message and report it to the
> > people that can fix it?  They can't.  So they report it in their
> > distributions bug tracker and it either gets closed as "yeah, firmware
> > sucks" or it sits there and rots in the hope that some day someone
> > will do something.
> > 
> > I understand where you're coming from in a pre-production, development
> > environment but to be quite clear that is not the default environment
> > Linux is run in most of the time.  If this were a kernel warning, that
> > could be fixed with a kernel patch, then maybe it would be worth it.
> > It isn't though.
> 
> If the error messages in the BGRT driver make it impossible for end
> users to achieve a pretty boot experience then I agree, that is a
> kernel bug. BGRT is an exception to the usual rule about complaining
> loudly when we encounter firmware bugs simply because we're dealing
> with UIs in this case.

Fine.  What's the highest priority message that will *not* cause splash
screens to go into text mode?  With the default boot argument of
"quiet", pr_notice or pr_info should still remain hidden, right?  So,
could we make these pr_notice, rather than pr_debug?  That way they'll
at least show up in logs, even though they don't show up on the console.

> That's not to say we should give up reporting these kinds of invalid
> table issues to firmware developers altogether. There are other means
> of doing it, and comprising the wants of many end users for the
> benefit of few firmware developers (relatively) is just not sensible.
> 
> Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
> validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
> like a very good place to include these tests since it already has a
> bunch of ACPI table checks.

BITS doesn't, but should; I've added it to the TODO list.

- Josh Triplett

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

2016-04-30 Thread Josh Triplett 
On Sat, Apr 30, 2016 at 11:35:14PM +0100, Matt Fleming wrote:
> (Adding Colin and Ricardo)
> 
> On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote:
> > 
> > How is an end user supposed to see such a message and report it to the
> > people that can fix it?  They can't.  So they report it in their
> > distributions bug tracker and it either gets closed as "yeah, firmware
> > sucks" or it sits there and rots in the hope that some day someone
> > will do something.
> > 
> > I understand where you're coming from in a pre-production, development
> > environment but to be quite clear that is not the default environment
> > Linux is run in most of the time.  If this were a kernel warning, that
> > could be fixed with a kernel patch, then maybe it would be worth it.
> > It isn't though.
> 
> If the error messages in the BGRT driver make it impossible for end
> users to achieve a pretty boot experience then I agree, that is a
> kernel bug. BGRT is an exception to the usual rule about complaining
> loudly when we encounter firmware bugs simply because we're dealing
> with UIs in this case.

Fine.  What's the highest priority message that will *not* cause splash
screens to go into text mode?  With the default boot argument of
"quiet", pr_notice or pr_info should still remain hidden, right?  So,
could we make these pr_notice, rather than pr_debug?  That way they'll
at least show up in logs, even though they don't show up on the console.

> That's not to say we should give up reporting these kinds of invalid
> table issues to firmware developers altogether. There are other means
> of doing it, and comprising the wants of many end users for the
> benefit of few firmware developers (relatively) is just not sensible.
> 
> Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
> validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
> like a very good place to include these tests since it already has a
> bunch of ACPI table checks.

BITS doesn't, but should; I've added it to the TODO list.

- Josh Triplett

[GIT PULL] Thermal management updates for v4.6-rc6

2016-04-30 Thread Eduardo Valentin 
Hello Linus,

Here are only a couple of minor fixes on thermal subsystem.

Please consider pulling from

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

to receive Thermal Management updates for v4.6-rc6 with top-most

15333e3af1de37b1b214b28c85fe9a7b257fb92c:

  thermal: use %d to print S32 parameters (2016-04-27 15:54:51 -0700)

on top of commit 913f201083c81cf021f050d041352ac854c4b526:

  Merge branch 'fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal 
(2016-04-23 17:15:39 -0700)

Specifics in this pull request:
- Fixes in hisilicon thermal driver
- More fixes of unsigned to int type change in thermal_core.c.
- These change have been CI tested using KernelCI bot [1,2]. \o/

[1] - 
https://kernelci.org/boot/all/job/evalenti/kernel/v4.6-rc4-285-gddc8fdc6e2f0/
[2] - https://kernelci.org/build/evalenti/kernel/v4.6-rc4-285-gddc8fdc6e2f0/

BR,

Eduardo Valentin


Leo Yan (2):
  thermal: hisilicon: increase temperature resolution
  thermal: use %d to print S32 parameters

 drivers/thermal/hisi_thermal.c | 4 ++--
 drivers/thermal/thermal_core.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

[GIT PULL] Thermal management updates for v4.6-rc6

2016-04-30 Thread Eduardo Valentin 
Hello Linus,

Here are only a couple of minor fixes on thermal subsystem.

Please consider pulling from

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

to receive Thermal Management updates for v4.6-rc6 with top-most

15333e3af1de37b1b214b28c85fe9a7b257fb92c:

  thermal: use %d to print S32 parameters (2016-04-27 15:54:51 -0700)

on top of commit 913f201083c81cf021f050d041352ac854c4b526:

  Merge branch 'fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal 
(2016-04-23 17:15:39 -0700)

Specifics in this pull request:
- Fixes in hisilicon thermal driver
- More fixes of unsigned to int type change in thermal_core.c.
- These change have been CI tested using KernelCI bot [1,2]. \o/

[1] - 
https://kernelci.org/boot/all/job/evalenti/kernel/v4.6-rc4-285-gddc8fdc6e2f0/
[2] - https://kernelci.org/build/evalenti/kernel/v4.6-rc4-285-gddc8fdc6e2f0/

BR,

Eduardo Valentin


Leo Yan (2):
  thermal: hisilicon: increase temperature resolution
  thermal: use %d to print S32 parameters

 drivers/thermal/hisi_thermal.c | 4 ++--
 drivers/thermal/thermal_core.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Re: OpRegion conflicts for Skylake LPSS

2016-04-30 Thread Ben Gamari 
Mika Westerberg  writes:

> On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote:
>> Ben Gamari  writes:
>> 
>> > [ Unknown signature status ]
>> > Mika Westerberg  writes:
>> >
>> >> On Tue, Apr 26, 2016 at 02:44:13AM +0200, Ben Gamari wrote:
>> >>> 
>> > snip
>> >
>> >>> It looks very much like these are describing the same device. Perhaps
>> >>> the lpss driver should be binding to this ACPI node? Or perhaps this is
>> >>> a firmware issue? Any guidance would be greatly appreciated.
>> >>
>> >> Can you send me full acpidump of that machine?
>> >
>> > It can be found at
>> > https://github.com/bgamari/dell-e7470-dsdt/blob/master/acpi.log.
>> >
>> Did this provide any insight? Let me know if more information would be
>> helpful.
>
> Sorry about the delay.
>
No worries.

> The GEXP device is most probably a GPIO expander that is connected to
> one of the I2C buses. And it indeed looks to use directly the I2C host
> controller registers so kernel rightfully complains about that.
>
> Are you able to run Windows on that machine? If yes, it would be nice to
> know if the INT3446 I2C device is shown in the device manager.
>
I had the original SSD that came with the machine with the original
Windows 7 installation intact. I popped it in and found no such device.
I then updated to Windows 10 (albeit still booting with the legacy BIOS,
not EFI) and found that once again there is no such device shown in
device manager.

>> Also, is there a way to simply allow the driver subsystem to allow
>> probing to proceed despite this resource conflict so that I can resume
>> debugging my original input device issue?
>
> Try to pass "acpi_enforce_resources=lax" in the kernel command line.

Thanks, indeed this allows the driver to load. Unfortunately it didn't
take long to encounter further issues.

The motivation for all of this is to get the touchpad into I2C mode, since
currently it is merely exposed as a simple PS/2 device. Unfortunately it
seems that even Windows 10 doesn't use the touchpad's I2C mode (although
I suppose it's possible that this is guarded on UEFI boot; moreover
Windows appears to have proper support for configurating this touchpad
in PS/2 mode, which is unfortunately an ALPS devices).

Looking at the DSDT it seems that enabling the I2C interface may require
the help of the embedded controller, the state of which is exposed in
the DSDT through a mysteriously-named SDS1 field. It looks like this
field could take on a number of values which identify a variety of
different touchpads. Given that it looks like GPIO pin states may be
determined by the value of this field I'm a bit reluctant to go fiddling
around with it. 

I do wish that firmware weren't such a nightmare.

Cheers,

- Ben


signature.asc
Description: PGP signature

Re: OpRegion conflicts for Skylake LPSS

2016-04-30 Thread Ben Gamari 
Mika Westerberg  writes:

> On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote:
>> Ben Gamari  writes:
>> 
>> > [ Unknown signature status ]
>> > Mika Westerberg  writes:
>> >
>> >> On Tue, Apr 26, 2016 at 02:44:13AM +0200, Ben Gamari wrote:
>> >>> 
>> > snip
>> >
>> >>> It looks very much like these are describing the same device. Perhaps
>> >>> the lpss driver should be binding to this ACPI node? Or perhaps this is
>> >>> a firmware issue? Any guidance would be greatly appreciated.
>> >>
>> >> Can you send me full acpidump of that machine?
>> >
>> > It can be found at
>> > https://github.com/bgamari/dell-e7470-dsdt/blob/master/acpi.log.
>> >
>> Did this provide any insight? Let me know if more information would be
>> helpful.
>
> Sorry about the delay.
>
No worries.

> The GEXP device is most probably a GPIO expander that is connected to
> one of the I2C buses. And it indeed looks to use directly the I2C host
> controller registers so kernel rightfully complains about that.
>
> Are you able to run Windows on that machine? If yes, it would be nice to
> know if the INT3446 I2C device is shown in the device manager.
>
I had the original SSD that came with the machine with the original
Windows 7 installation intact. I popped it in and found no such device.
I then updated to Windows 10 (albeit still booting with the legacy BIOS,
not EFI) and found that once again there is no such device shown in
device manager.

>> Also, is there a way to simply allow the driver subsystem to allow
>> probing to proceed despite this resource conflict so that I can resume
>> debugging my original input device issue?
>
> Try to pass "acpi_enforce_resources=lax" in the kernel command line.

Thanks, indeed this allows the driver to load. Unfortunately it didn't
take long to encounter further issues.

The motivation for all of this is to get the touchpad into I2C mode, since
currently it is merely exposed as a simple PS/2 device. Unfortunately it
seems that even Windows 10 doesn't use the touchpad's I2C mode (although
I suppose it's possible that this is guarded on UEFI boot; moreover
Windows appears to have proper support for configurating this touchpad
in PS/2 mode, which is unfortunately an ALPS devices).

Looking at the DSDT it seems that enabling the I2C interface may require
the help of the embedded controller, the state of which is exposed in
the DSDT through a mysteriously-named SDS1 field. It looks like this
field could take on a number of values which identify a variety of
different touchpads. Given that it looks like GPIO pin states may be
determined by the value of this field I'm a bit reluctant to go fiddling
around with it. 

I do wish that firmware weren't such a nightmare.

Cheers,

- Ben


signature.asc
Description: PGP signature

Re: [PATCH] efibc: avoid stack overflow warning

2016-04-30 Thread Matt Fleming 
On Sun, 01 May, at 12:34:29AM, Arnd Bergmann wrote:
> 
> The sys_restart() system call takes a mutex before calling kernel_restart()
> or kernel_poweroff().
> 
> I've had a closer look now and found that there are a few other
> callers of kernel_restart, so I guess if you restart using sysctl
> at the exact same time as calling /sbin/reboot, things may break.
 
Right. Or if the dm-verify-target driver saw an error.

> It's not something we'd have to worry about in practice, but it does
> make my patch incorrect. Should we come up with a different way to
> do it?

Jeremy proposed a patch to dynamically allocate the memory, which I
think is the correct way to go given that our (reasonable) assumptions
about reboot notifier concurrency are not guaranteed,

  https://lkml.kernel.org/r/87h9eked24@jcompost-mobl1.tl.intel.com

Re: [PATCH] efibc: avoid stack overflow warning

2016-04-30 Thread Matt Fleming 
On Sun, 01 May, at 12:34:29AM, Arnd Bergmann wrote:
> 
> The sys_restart() system call takes a mutex before calling kernel_restart()
> or kernel_poweroff().
> 
> I've had a closer look now and found that there are a few other
> callers of kernel_restart, so I guess if you restart using sysctl
> at the exact same time as calling /sbin/reboot, things may break.
 
Right. Or if the dm-verify-target driver saw an error.

> It's not something we'd have to worry about in practice, but it does
> make my patch incorrect. Should we come up with a different way to
> do it?

Jeremy proposed a patch to dynamically allocate the memory, which I
think is the correct way to go given that our (reasonable) assumptions
about reboot notifier concurrency are not guaranteed,

  https://lkml.kernel.org/r/87h9eked24@jcompost-mobl1.tl.intel.com

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Ben Greear 



On 04/30/2016 03:01 PM, Vijay Pandurangan wrote:

On Sat, Apr 30, 2016 at 5:52 PM, Ben Greear  wrote:


Good point, so if you had:

eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
userspace-stub <->eth1

and user-space hub enabled this elide flag, things would work, right?
Then, it seems like what we need is a way to tell the kernel
router/bridge logic to follow elide signals in packets coming from
veth. I'm not sure what the best way to do this is because I'm less
familiar with conventions in that part of the kernel, but assuming
there's a way to do this, would it be acceptable?



You cannot receive on one veth without transmitting on the other, so
I think the elide csum logic can go on the raw-socket, and apply to packets
in the transmit-from-user-space direction.  Just allowing the socket to make
the veth behave like it used to before this patch in question should be good
enough, since that worked for us for years.  So, just an option to modify
the
ip_summed for pkts sent on a socket is probably sufficient.


I don't think this is right. Consider:

- App A  sends out corrupt packets 50% of the time and discards inbound data.
- App B doesn't care about corrupt packets and is happy to receive
them and has some way of dealing with them (special case)
- App C is a regular app, say nc or something.

In your world, where A decides what happens to data it transmits,
then
A<--veth-->B and A<---wire-->B will have the same behaviour

but

A<-- veth --> C and A<-- wire --> C will have _different_ behaviour: C
will behave incorrectly if it's connected over veth but correctly if
connected with a wire. That is a bug.

Since A cannot know what the app it's talking to will desire, I argue
that both sides of a message must be opted in to this optimization.


How can you make a generic app C know how to do this?  The path could be,
for instance:

eth0 <-> user-space-A <-> vethA <-> vethB <-> { kernel routing logic } <-> vethC <-> 
vethD <-> appC

There are no sockets on vethB, but it does need to have special behaviour to 
elide
csums.  Even if appC is hacked to know how to twiddle some thing on it's veth 
port,
mucking with vethD will have no effect on vethB.

With regard to your example above, why would A corrupt packets?  My guess:

1)  It has bugs (so, fix the bugs, it could equally create incorrect data with 
proper checksums,
so just enabling checksumming adds no useful protection.)

2)  It means to corrupt frames.  In that case, someone must expect that C 
should receive incorrect
frames, otherwise why bother making App-A corrupt them in the first place?

3)  You are explicitly trying to test the kernel checksum logic, so you want 
the kernel to
detect the bad checksum and throw away the packet.  In this case, just 
don't set the socket
option in appA to elide checksums and the packet will be thrown away.

Any other cases you can think of?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Ben Greear 



On 04/30/2016 03:01 PM, Vijay Pandurangan wrote:

On Sat, Apr 30, 2016 at 5:52 PM, Ben Greear  wrote:


Good point, so if you had:

eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
userspace-stub <->eth1

and user-space hub enabled this elide flag, things would work, right?
Then, it seems like what we need is a way to tell the kernel
router/bridge logic to follow elide signals in packets coming from
veth. I'm not sure what the best way to do this is because I'm less
familiar with conventions in that part of the kernel, but assuming
there's a way to do this, would it be acceptable?



You cannot receive on one veth without transmitting on the other, so
I think the elide csum logic can go on the raw-socket, and apply to packets
in the transmit-from-user-space direction.  Just allowing the socket to make
the veth behave like it used to before this patch in question should be good
enough, since that worked for us for years.  So, just an option to modify
the
ip_summed for pkts sent on a socket is probably sufficient.


I don't think this is right. Consider:

- App A  sends out corrupt packets 50% of the time and discards inbound data.
- App B doesn't care about corrupt packets and is happy to receive
them and has some way of dealing with them (special case)
- App C is a regular app, say nc or something.

In your world, where A decides what happens to data it transmits,
then
A<--veth-->B and A<---wire-->B will have the same behaviour

but

A<-- veth --> C and A<-- wire --> C will have _different_ behaviour: C
will behave incorrectly if it's connected over veth but correctly if
connected with a wire. That is a bug.

Since A cannot know what the app it's talking to will desire, I argue
that both sides of a message must be opted in to this optimization.


How can you make a generic app C know how to do this?  The path could be,
for instance:

eth0 <-> user-space-A <-> vethA <-> vethB <-> { kernel routing logic } <-> vethC <-> 
vethD <-> appC

There are no sockets on vethB, but it does need to have special behaviour to 
elide
csums.  Even if appC is hacked to know how to twiddle some thing on it's veth 
port,
mucking with vethD will have no effect on vethB.

With regard to your example above, why would A corrupt packets?  My guess:

1)  It has bugs (so, fix the bugs, it could equally create incorrect data with 
proper checksums,
so just enabling checksumming adds no useful protection.)

2)  It means to corrupt frames.  In that case, someone must expect that C 
should receive incorrect
frames, otherwise why bother making App-A corrupt them in the first place?

3)  You are explicitly trying to test the kernel checksum logic, so you want 
the kernel to
detect the bad checksum and throw away the packet.  In this case, just 
don't set the socket
option in appA to elide checksums and the packet will be thrown away.

Any other cases you can think of?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Tom Herbert 
On Sat, Apr 30, 2016 at 1:59 PM, Ben Greear  wrote:
>
> On 04/30/2016 12:54 PM, Tom Herbert wrote:
>>
>> We've put considerable effort into cleaning up the checksum interface
>> to make it as unambiguous as possible, please be very careful to
>> follow it. Broken checksum processing is really hard to detect and
>> debug.
>>
>> CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
>> (indicated by csum_level) have been verified to be correct in a
>> packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
>> never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
>> checksum it would refer to has not been verified and is incorrect this
>> is a major bug.
>
>
> Suppose I know that the packet received on a packet-socket has
> already been verified by a NIC that supports hardware checksumming.
>
> Then, I want to transmit it on a veth interface using a second
> packet socket.  I do not want veth to recalculate the checksum on
> transmit, nor to validate it on the peer veth on receive, because I do
> not want to waste the CPU cycles.  I am assuming that my app is not
> accidentally corrupting frames, so the checksum can never be bad.
>
> How should the checksumming be configured for the packets going into
> the packet-socket from user-space?
>
Checksum unnecessary conversion to checksum complete should be done
and then the computed value can be sent to user space. If you want to
take advantage of the value on transmit then we would to change the
interface. But I'm not sure why recalculating the the checksum in the
host is even a problem. With all the advances in checksum offload,
LCO, RCO it seems like that shouldn't be a common case anyway.

> Also, I might want to send raw frames that do have
> broken checksums (lets assume a real NIC, not veth), and I want them
> to hit the wire with those bad checksums.
>
> How do I configure the checksumming in this case?

Just send raw packets with bad checksums (no checksum offload).

Tom

>
>
> Thanks,
> Ben
>
>
>
>>
>> Tom
>>
>> On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear 
>> wrote:
>>>
>>>
>>>
>>> On 04/30/2016 11:33 AM, Ben Hutchings wrote:


 On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
>
>
> Hello,
>>>
>>>
>>>
>>
>>
>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>
>
> Actually, no, this is not really a regression.


 [...]

 It really is.  Even though the old behaviour was a bug (raw packets
 should not be changed), if there are real applications that depend on
 that then we have to keep those applications working somehow.
>>>
>>>
>>>
>>> To be honest, I fail to see why the old behaviour is a bug when sending
>>> raw packets from user-space.  If raw packets should not be changed, then
>>> we need some way to specify what the checksum setting is to begin with,
>>> otherwise, user-space has not enough control.
>>>
>>> A socket option for new programs, and sysctl configurable defaults for
>>> raw
>>> sockets
>>> for old binary programs would be sufficient I think.
>>>
>>>
>>> Thanks,
>>> Ben
>>>
>>> --
>>> Ben Greear 
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

2016-04-30 Thread Colin Ian King 
On 30/04/16 23:35, Matt Fleming wrote:
> (Adding Colin and Ricardo)
> 
> On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote:
>>
>> How is an end user supposed to see such a message and report it to the
>> people that can fix it?  They can't.  So they report it in their
>> distributions bug tracker and it either gets closed as "yeah, firmware
>> sucks" or it sits there and rots in the hope that some day someone
>> will do something.
>>
>> I understand where you're coming from in a pre-production, development
>> environment but to be quite clear that is not the default environment
>> Linux is run in most of the time.  If this were a kernel warning, that
>> could be fixed with a kernel patch, then maybe it would be worth it.
>> It isn't though.
> 
> If the error messages in the BGRT driver make it impossible for end
> users to achieve a pretty boot experience then I agree, that is a
> kernel bug. BGRT is an exception to the usual rule about complaining
> loudly when we encounter firmware bugs simply because we're dealing
> with UIs in this case.
> 
> That's not to say we should give up reporting these kinds of invalid
> table issues to firmware developers altogether. There are other means
> of doing it, and comprising the wants of many end users for the
> benefit of few firmware developers (relatively) is just not sensible.
> 
> Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
> validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
> like a very good place to include these tests since it already has a
> bunch of ACPI table checks.
> 
fwts does have a BGRT test, although it is fairly trivial:

http://kernel.ubuntu.com/git/hwe/fwts.git/tree/src/acpi/bgrt/bgrt.c

Colin

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Tom Herbert 
On Sat, Apr 30, 2016 at 1:59 PM, Ben Greear  wrote:
>
> On 04/30/2016 12:54 PM, Tom Herbert wrote:
>>
>> We've put considerable effort into cleaning up the checksum interface
>> to make it as unambiguous as possible, please be very careful to
>> follow it. Broken checksum processing is really hard to detect and
>> debug.
>>
>> CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
>> (indicated by csum_level) have been verified to be correct in a
>> packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
>> never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
>> checksum it would refer to has not been verified and is incorrect this
>> is a major bug.
>
>
> Suppose I know that the packet received on a packet-socket has
> already been verified by a NIC that supports hardware checksumming.
>
> Then, I want to transmit it on a veth interface using a second
> packet socket.  I do not want veth to recalculate the checksum on
> transmit, nor to validate it on the peer veth on receive, because I do
> not want to waste the CPU cycles.  I am assuming that my app is not
> accidentally corrupting frames, so the checksum can never be bad.
>
> How should the checksumming be configured for the packets going into
> the packet-socket from user-space?
>
Checksum unnecessary conversion to checksum complete should be done
and then the computed value can be sent to user space. If you want to
take advantage of the value on transmit then we would to change the
interface. But I'm not sure why recalculating the the checksum in the
host is even a problem. With all the advances in checksum offload,
LCO, RCO it seems like that shouldn't be a common case anyway.

> Also, I might want to send raw frames that do have
> broken checksums (lets assume a real NIC, not veth), and I want them
> to hit the wire with those bad checksums.
>
> How do I configure the checksumming in this case?

Just send raw packets with bad checksums (no checksum offload).

Tom

>
>
> Thanks,
> Ben
>
>
>
>>
>> Tom
>>
>> On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear 
>> wrote:
>>>
>>>
>>>
>>> On 04/30/2016 11:33 AM, Ben Hutchings wrote:


 On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
>
>
> Hello,
>>>
>>>
>>>
>>
>>
>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>
>
> Actually, no, this is not really a regression.


 [...]

 It really is.  Even though the old behaviour was a bug (raw packets
 should not be changed), if there are real applications that depend on
 that then we have to keep those applications working somehow.
>>>
>>>
>>>
>>> To be honest, I fail to see why the old behaviour is a bug when sending
>>> raw packets from user-space.  If raw packets should not be changed, then
>>> we need some way to specify what the checksum setting is to begin with,
>>> otherwise, user-space has not enough control.
>>>
>>> A socket option for new programs, and sysctl configurable defaults for
>>> raw
>>> sockets
>>> for old binary programs would be sufficient I think.
>>>
>>>
>>> Thanks,
>>> Ben
>>>
>>> --
>>> Ben Greear 
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

2016-04-30 Thread Colin Ian King 
On 30/04/16 23:35, Matt Fleming wrote:
> (Adding Colin and Ricardo)
> 
> On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote:
>>
>> How is an end user supposed to see such a message and report it to the
>> people that can fix it?  They can't.  So they report it in their
>> distributions bug tracker and it either gets closed as "yeah, firmware
>> sucks" or it sits there and rots in the hope that some day someone
>> will do something.
>>
>> I understand where you're coming from in a pre-production, development
>> environment but to be quite clear that is not the default environment
>> Linux is run in most of the time.  If this were a kernel warning, that
>> could be fixed with a kernel patch, then maybe it would be worth it.
>> It isn't though.
> 
> If the error messages in the BGRT driver make it impossible for end
> users to achieve a pretty boot experience then I agree, that is a
> kernel bug. BGRT is an exception to the usual rule about complaining
> loudly when we encounter firmware bugs simply because we're dealing
> with UIs in this case.
> 
> That's not to say we should give up reporting these kinds of invalid
> table issues to firmware developers altogether. There are other means
> of doing it, and comprising the wants of many end users for the
> benefit of few firmware developers (relatively) is just not sensible.
> 
> Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
> validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
> like a very good place to include these tests since it already has a
> bunch of ACPI table checks.
> 
fwts does have a BGRT test, although it is fairly trivial:

http://kernel.ubuntu.com/git/hwe/fwts.git/tree/src/acpi/bgrt/bgrt.c

Colin

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

2016-04-30 Thread Matt Fleming 
(Adding Colin and Ricardo)

On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote:
> 
> How is an end user supposed to see such a message and report it to the
> people that can fix it?  They can't.  So they report it in their
> distributions bug tracker and it either gets closed as "yeah, firmware
> sucks" or it sits there and rots in the hope that some day someone
> will do something.
> 
> I understand where you're coming from in a pre-production, development
> environment but to be quite clear that is not the default environment
> Linux is run in most of the time.  If this were a kernel warning, that
> could be fixed with a kernel patch, then maybe it would be worth it.
> It isn't though.

If the error messages in the BGRT driver make it impossible for end
users to achieve a pretty boot experience then I agree, that is a
kernel bug. BGRT is an exception to the usual rule about complaining
loudly when we encounter firmware bugs simply because we're dealing
with UIs in this case.

That's not to say we should give up reporting these kinds of invalid
table issues to firmware developers altogether. There are other means
of doing it, and comprising the wants of many end users for the
benefit of few firmware developers (relatively) is just not sensible.

Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
like a very good place to include these tests since it already has a
bunch of ACPI table checks.

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

2016-04-30 Thread Matt Fleming 
(Adding Colin and Ricardo)

On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote:
> 
> How is an end user supposed to see such a message and report it to the
> people that can fix it?  They can't.  So they report it in their
> distributions bug tracker and it either gets closed as "yeah, firmware
> sucks" or it sits there and rots in the hope that some day someone
> will do something.
> 
> I understand where you're coming from in a pre-production, development
> environment but to be quite clear that is not the default environment
> Linux is run in most of the time.  If this were a kernel warning, that
> could be fixed with a kernel patch, then maybe it would be worth it.
> It isn't though.

If the error messages in the BGRT driver make it impossible for end
users to achieve a pretty boot experience then I agree, that is a
kernel bug. BGRT is an exception to the usual rule about complaining
loudly when we encounter firmware bugs simply because we're dealing
with UIs in this case.

That's not to say we should give up reporting these kinds of invalid
table issues to firmware developers altogether. There are other means
of doing it, and comprising the wants of many end users for the
benefit of few firmware developers (relatively) is just not sensible.

Colin, Ricardo, I haven't checked recently, are there ACPI BGRT
validations tests in FWTS and LUV? Josh (Triplett), BITS would seem
like a very good place to include these tests since it already has a
bunch of ACPI table checks.

Re: [PATCH] efibc: avoid stack overflow warning

2016-04-30 Thread Arnd Bergmann 
On Saturday 30 April 2016 21:14:49 Matt Fleming wrote:
> On Fri, 29 Apr, at 07:48:31PM, Arnd Bergmann wrote:
> > gcc complains about a newly added file for the EFI Bootloader Control:
> > 
> > drivers/firmware/efi/efibc.c: In function 'efibc_set_variable':
> > drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is 
> > larger than 1024 bytes [-Werror=frame-larger-than=]
> > 
> > The problem is the declaration of a local variable of type
> > struct efivar_entry, which is by itself larger than the warning
> > limit of 1024 bytes.
> > 
> > We know that the reboot notifiers are not called from a deep stack,
> > so this is not an actual bug, but we should still try to rework
> > the code to avoid the warning. We also know that reboot notifiers
> > are never run concurrently on multiple CPUs, so there is no problem
> > in just making the variable 'static'.
>  
> I assumed reboot notifiers were guaranteed to be non-concurrent too
> but having dug into the callers of kernel_reboot(), I couldn't find
> any kind of mutual exclusion.
> 
> How/where is this guaranteed?

The sys_restart() system call takes a mutex before calling kernel_restart()
or kernel_poweroff().

I've had a closer look now and found that there are a few other
callers of kernel_restart, so I guess if you restart using sysctl
at the exact same time as calling /sbin/reboot, things may break.

It's not something we'd have to worry about in practice, but it does
make my patch incorrect. Should we come up with a different way to
do it?

Arnd

Re: [PATCH] efibc: avoid stack overflow warning

2016-04-30 Thread Arnd Bergmann 
On Saturday 30 April 2016 21:14:49 Matt Fleming wrote:
> On Fri, 29 Apr, at 07:48:31PM, Arnd Bergmann wrote:
> > gcc complains about a newly added file for the EFI Bootloader Control:
> > 
> > drivers/firmware/efi/efibc.c: In function 'efibc_set_variable':
> > drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is 
> > larger than 1024 bytes [-Werror=frame-larger-than=]
> > 
> > The problem is the declaration of a local variable of type
> > struct efivar_entry, which is by itself larger than the warning
> > limit of 1024 bytes.
> > 
> > We know that the reboot notifiers are not called from a deep stack,
> > so this is not an actual bug, but we should still try to rework
> > the code to avoid the warning. We also know that reboot notifiers
> > are never run concurrently on multiple CPUs, so there is no problem
> > in just making the variable 'static'.
>  
> I assumed reboot notifiers were guaranteed to be non-concurrent too
> but having dug into the callers of kernel_reboot(), I couldn't find
> any kind of mutual exclusion.
> 
> How/where is this guaranteed?

The sys_restart() system call takes a mutex before calling kernel_restart()
or kernel_poweroff().

I've had a closer look now and found that there are a few other
callers of kernel_restart, so I guess if you restart using sysctl
at the exact same time as calling /sbin/reboot, things may break.

It's not something we'd have to worry about in practice, but it does
make my patch incorrect. Should we come up with a different way to
do it?

Arnd

Re: [PATCH 0/2] scop GFP_NOFS api

2016-04-30 Thread NeilBrown 
On Sat, Apr 30 2016, Dave Chinner wrote:

> On Fri, Apr 29, 2016 at 03:35:42PM +1000, NeilBrown wrote:
>> On Tue, Apr 26 2016, Michal Hocko wrote:
>> 
>> > Hi,
>> > we have discussed this topic at LSF/MM this year. There was a general
>> > interest in the scope GFP_NOFS allocation context among some FS
>> > developers. For those who are not aware of the discussion or the issue
>> > I am trying to sort out (or at least start in that direction) please
>> > have a look at patch 1 which adds memalloc_nofs_{save,restore} api
>> > which basically copies what we have for the scope GFP_NOIO allocation
>> > context. I haven't converted any of the FS myself because that is way
>> > beyond my area of expertise but I would be happy to help with further
>> > changes on the MM front as well as in some more generic code paths.
>> >
>> > Dave had an idea on how to further improve the reclaim context to be
>> > less all-or-nothing wrt. GFP_NOFS. In short he was suggesting an opaque
>> > and FS specific cookie set in the FS allocation context and consumed
>> > by the FS reclaim context to allow doing some provably save actions
>> > that would be skipped due to GFP_NOFS normally.  I like this idea and
>> > I believe we can go that direction regardless of the approach taken here.
>> > Many filesystems simply need to cleanup their NOFS usage first before
>> > diving into a more complex changes.>
>> 
>> This strikes me as over-engineering to work around an unnecessarily
>> burdensome interface but without details it is hard to be certain.
>> 
>> Exactly what things happen in "FS reclaim context" which may, or may
>> not, be safe depending on the specific FS allocation context?  Do they
>> need to happen at all?
>> 
>> My research suggests that for most filesystems the only thing that
>> happens in reclaim context that is at all troublesome is the final
>> 'evict()' on an inode.  This needs to flush out dirty pages and sync the
>> inode to storage.  Some time ago we moved most dirty-page writeout out
>> of the reclaim context and into kswapd.  I think this was an excellent
>> advance in simplicity.
>
> No, we didn't move dirty page writeout to kswapd - we moved it back
> to the background writeback threads where it can be done
> efficiently.  kswapd should almost never do single page writeback
> because of how inefficient it is from an IO perspective, even though
> it can. i.e. if we are doing any significant amount of dirty page
> writeback from memory reclaim (direct, kswapd or otherwise) then
> we've screwed something up.
>
>> If we could similarly move evict() into kswapd (and I believe we can)
>> then most file systems would do nothing in reclaim context that
>> interferes with allocation context.
>
> When lots of GFP_NOFS allocation is being done, this already
> happens. The shrinkers that can't run due to context accumulate the
> work on the shrinker structure, and when the shrinker can next run
> (e.g. run from kswapd) it runs all the deferred work from GFP_NOFS
> reclaim contexts.
>
> IOWs, we already move shrinker work from direct reclaim to kswapd
> when appropriate.
>
>> The exceptions include:
>>  - nfs and any filesystem using fscache can block for up to 1 second
>>in ->releasepage().  They used to block waiting for some IO, but that
>>caused deadlocks and wasn't really needed.  I left the timeout because
>>it seemed likely that some throttling would help.  I suspect that a
>>careful analysis will show that there is sufficient throttling
>>elsewhere.
>> 
>>  - xfs_qm_shrink_scan is nearly unique among shrinkers in that it waits
>>for IO so it can free some quotainfo things. 
>
> No it's not. evict() can block on IO - waiting for data or inode
> writeback to complete, or even for filesystems to run transactions
> on the inode. Hence the superblock shrinker can and does block in
> inode cache reclaim.

That is why I said "nearly" :-)

>
> Indeed, blocking the superblock shrinker in reclaim is a key part of
> balancing inode cache pressure in XFS. If the shrinker starts
> hitting dirty inodes, it blocks on cleaning them, thereby slowing
> the rate of allocation to that which inodes can be cleaned and
> reclaimed. There are also background threads that walk ahead freeing
> clean inodes, but we have to throttle direct reclaim in this manner
> otherwise the allocation pressure vastly outweighs the ability to
> reclaim inodes. if we don't balance this, inode allocation triggers
> the OOM killer because reclaim keeps reporting "no progress being
> made" because dirty inodes are skipped. BY blocking on such inodes,
> the shrinker makes progress (slowly) and reclaim sees that memory is
> being freed and so continues without invoking the OOM killer...

I'm very aware of the need to throttle allocation based on IO.  I
remember when NFS didn't quite get this right and filled up memory :-)

balance_dirty_pages() used to force threads to wait on the write-out of
one page for every page that they

Re: [PATCH 0/2] scop GFP_NOFS api

2016-04-30 Thread NeilBrown 
On Sat, Apr 30 2016, Dave Chinner wrote:

> On Fri, Apr 29, 2016 at 03:35:42PM +1000, NeilBrown wrote:
>> On Tue, Apr 26 2016, Michal Hocko wrote:
>> 
>> > Hi,
>> > we have discussed this topic at LSF/MM this year. There was a general
>> > interest in the scope GFP_NOFS allocation context among some FS
>> > developers. For those who are not aware of the discussion or the issue
>> > I am trying to sort out (or at least start in that direction) please
>> > have a look at patch 1 which adds memalloc_nofs_{save,restore} api
>> > which basically copies what we have for the scope GFP_NOIO allocation
>> > context. I haven't converted any of the FS myself because that is way
>> > beyond my area of expertise but I would be happy to help with further
>> > changes on the MM front as well as in some more generic code paths.
>> >
>> > Dave had an idea on how to further improve the reclaim context to be
>> > less all-or-nothing wrt. GFP_NOFS. In short he was suggesting an opaque
>> > and FS specific cookie set in the FS allocation context and consumed
>> > by the FS reclaim context to allow doing some provably save actions
>> > that would be skipped due to GFP_NOFS normally.  I like this idea and
>> > I believe we can go that direction regardless of the approach taken here.
>> > Many filesystems simply need to cleanup their NOFS usage first before
>> > diving into a more complex changes.>
>> 
>> This strikes me as over-engineering to work around an unnecessarily
>> burdensome interface but without details it is hard to be certain.
>> 
>> Exactly what things happen in "FS reclaim context" which may, or may
>> not, be safe depending on the specific FS allocation context?  Do they
>> need to happen at all?
>> 
>> My research suggests that for most filesystems the only thing that
>> happens in reclaim context that is at all troublesome is the final
>> 'evict()' on an inode.  This needs to flush out dirty pages and sync the
>> inode to storage.  Some time ago we moved most dirty-page writeout out
>> of the reclaim context and into kswapd.  I think this was an excellent
>> advance in simplicity.
>
> No, we didn't move dirty page writeout to kswapd - we moved it back
> to the background writeback threads where it can be done
> efficiently.  kswapd should almost never do single page writeback
> because of how inefficient it is from an IO perspective, even though
> it can. i.e. if we are doing any significant amount of dirty page
> writeback from memory reclaim (direct, kswapd or otherwise) then
> we've screwed something up.
>
>> If we could similarly move evict() into kswapd (and I believe we can)
>> then most file systems would do nothing in reclaim context that
>> interferes with allocation context.
>
> When lots of GFP_NOFS allocation is being done, this already
> happens. The shrinkers that can't run due to context accumulate the
> work on the shrinker structure, and when the shrinker can next run
> (e.g. run from kswapd) it runs all the deferred work from GFP_NOFS
> reclaim contexts.
>
> IOWs, we already move shrinker work from direct reclaim to kswapd
> when appropriate.
>
>> The exceptions include:
>>  - nfs and any filesystem using fscache can block for up to 1 second
>>in ->releasepage().  They used to block waiting for some IO, but that
>>caused deadlocks and wasn't really needed.  I left the timeout because
>>it seemed likely that some throttling would help.  I suspect that a
>>careful analysis will show that there is sufficient throttling
>>elsewhere.
>> 
>>  - xfs_qm_shrink_scan is nearly unique among shrinkers in that it waits
>>for IO so it can free some quotainfo things. 
>
> No it's not. evict() can block on IO - waiting for data or inode
> writeback to complete, or even for filesystems to run transactions
> on the inode. Hence the superblock shrinker can and does block in
> inode cache reclaim.

That is why I said "nearly" :-)

>
> Indeed, blocking the superblock shrinker in reclaim is a key part of
> balancing inode cache pressure in XFS. If the shrinker starts
> hitting dirty inodes, it blocks on cleaning them, thereby slowing
> the rate of allocation to that which inodes can be cleaned and
> reclaimed. There are also background threads that walk ahead freeing
> clean inodes, but we have to throttle direct reclaim in this manner
> otherwise the allocation pressure vastly outweighs the ability to
> reclaim inodes. if we don't balance this, inode allocation triggers
> the OOM killer because reclaim keeps reporting "no progress being
> made" because dirty inodes are skipped. BY blocking on such inodes,
> the shrinker makes progress (slowly) and reclaim sees that memory is
> being freed and so continues without invoking the OOM killer...

I'm very aware of the need to throttle allocation based on IO.  I
remember when NFS didn't quite get this right and filled up memory :-)

balance_dirty_pages() used to force threads to wait on the write-out of
one page for every page that they

[PATCH] efi/capsule: Make efi_capsule_pending() lockless

2016-04-30 Thread Matt Fleming 
Taking a mutex in the reboot path is bogus because we cannot sleep
with interrupts disabled, such as when rebooting due to panic(),

 [   18.069005] BUG: sleeping function called from invalid context at 
kernel/locking/mutex.c:97
 [   18.071639] in_atomic(): 0, irqs_disabled(): 1, pid: 7, name: rcu_sched
 [   18.085940] Call Trace:
 [   18.086911]  [] dump_stack+0x63/0x89
 [   18.088260]  [] ___might_sleep+0xd8/0x120
 [   18.089860]  [] __might_sleep+0x49/0x80
 [   18.091272]  [] mutex_lock+0x20/0x50
 [   18.092636]  [] efi_capsule_pending+0x1d/0x60
 [   18.094272]  [] 
native_machine_emergency_restart+0x59/0x280
 [   18.095975]  [] machine_emergency_restart+0x19/0x20
 [   18.097685]  [] emergency_restart+0x18/0x20
 [   18.099303]  [] panic+0x1ba/0x217

In this case all other CPUs will have been stopped by the time we
execute the platform reboot code, so 'capsule_pending' cannot change
under our feet. We wouldn't care even if it could since we cannot wait
for it complete.

Also, instead of relying on the external 'system_state' variable just
use a reboot notifier, so we can set 'stop_capsules' while holding
'capsule_mutex', thereby avoiding a race where system_state is updated
while we're in the middle of efi_capsule_update_locked() (since CPUs
won't have been stopped at that point).

Cc: Borislav Petkov 
Cc: Kweh Hock Leong 
Cc: Ard Biesheuvel 
Cc: Bryan O'Donoghue 
Cc: joeyli 
Signed-off-by: Matt Fleming 
---
 drivers/firmware/efi/capsule.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c
index 0de55944ac0b..4703dc9b8fbd 100644
--- a/drivers/firmware/efi/capsule.c
+++ b/drivers/firmware/efi/capsule.c
@@ -22,11 +22,12 @@ typedef struct {
 } efi_capsule_block_desc_t;
 
 static bool capsule_pending;
+static bool stop_capsules;
 static int efi_reset_type = -1;
 
 /*
  * capsule_mutex serialises access to both capsule_pending and
- * efi_reset_type.
+ * efi_reset_type and stop_capsules.
  */
 static DEFINE_MUTEX(capsule_mutex);
 
@@ -50,18 +51,13 @@ static DEFINE_MUTEX(capsule_mutex);
  */
 bool efi_capsule_pending(int *reset_type)
 {
-   bool rv = false;
-
-   mutex_lock(_mutex);
if (!capsule_pending)
-   goto out;
+   return false;
 
if (reset_type)
*reset_type = efi_reset_type;
-   rv = true;
-out:
-   mutex_unlock(_mutex);
-   return rv;
+
+   return true;
 }
 
 /*
@@ -176,7 +172,7 @@ efi_capsule_update_locked(efi_capsule_header_t *capsule,
 * whether to force an EFI reboot), and we're racing against
 * that call. Abort in that case.
 */
-   if (unlikely(system_state == SYSTEM_RESTART)) {
+   if (unlikely(stop_capsules)) {
pr_warn("Capsule update raced with reboot, aborting.\n");
return -EINVAL;
}
@@ -298,3 +294,23 @@ out:
return rv;
 }
 EXPORT_SYMBOL_GPL(efi_capsule_update);
+
+static int capsule_reboot_notify(struct notifier_block *nb,
+unsigned long event, void *cmd)
+{
+   mutex_lock(_mutex);
+   stop_capsules = true;
+   mutex_unlock(_mutex);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block capsule_reboot_nb = {
+   .notifier_call = capsule_reboot_notify,
+};
+
+static int __init capsule_reboot_register(void)
+{
+   return register_reboot_notifier(_reboot_nb);
+}
+core_initcall(capsule_reboot_register);
-- 
2.7.3

[PATCH] efi/capsule: Make efi_capsule_pending() lockless

2016-04-30 Thread Matt Fleming 
Taking a mutex in the reboot path is bogus because we cannot sleep
with interrupts disabled, such as when rebooting due to panic(),

 [   18.069005] BUG: sleeping function called from invalid context at 
kernel/locking/mutex.c:97
 [   18.071639] in_atomic(): 0, irqs_disabled(): 1, pid: 7, name: rcu_sched
 [   18.085940] Call Trace:
 [   18.086911]  [] dump_stack+0x63/0x89
 [   18.088260]  [] ___might_sleep+0xd8/0x120
 [   18.089860]  [] __might_sleep+0x49/0x80
 [   18.091272]  [] mutex_lock+0x20/0x50
 [   18.092636]  [] efi_capsule_pending+0x1d/0x60
 [   18.094272]  [] 
native_machine_emergency_restart+0x59/0x280
 [   18.095975]  [] machine_emergency_restart+0x19/0x20
 [   18.097685]  [] emergency_restart+0x18/0x20
 [   18.099303]  [] panic+0x1ba/0x217

In this case all other CPUs will have been stopped by the time we
execute the platform reboot code, so 'capsule_pending' cannot change
under our feet. We wouldn't care even if it could since we cannot wait
for it complete.

Also, instead of relying on the external 'system_state' variable just
use a reboot notifier, so we can set 'stop_capsules' while holding
'capsule_mutex', thereby avoiding a race where system_state is updated
while we're in the middle of efi_capsule_update_locked() (since CPUs
won't have been stopped at that point).

Cc: Borislav Petkov 
Cc: Kweh Hock Leong 
Cc: Ard Biesheuvel 
Cc: Bryan O'Donoghue 
Cc: joeyli 
Signed-off-by: Matt Fleming 
---
 drivers/firmware/efi/capsule.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c
index 0de55944ac0b..4703dc9b8fbd 100644
--- a/drivers/firmware/efi/capsule.c
+++ b/drivers/firmware/efi/capsule.c
@@ -22,11 +22,12 @@ typedef struct {
 } efi_capsule_block_desc_t;
 
 static bool capsule_pending;
+static bool stop_capsules;
 static int efi_reset_type = -1;
 
 /*
  * capsule_mutex serialises access to both capsule_pending and
- * efi_reset_type.
+ * efi_reset_type and stop_capsules.
  */
 static DEFINE_MUTEX(capsule_mutex);
 
@@ -50,18 +51,13 @@ static DEFINE_MUTEX(capsule_mutex);
  */
 bool efi_capsule_pending(int *reset_type)
 {
-   bool rv = false;
-
-   mutex_lock(_mutex);
if (!capsule_pending)
-   goto out;
+   return false;
 
if (reset_type)
*reset_type = efi_reset_type;
-   rv = true;
-out:
-   mutex_unlock(_mutex);
-   return rv;
+
+   return true;
 }
 
 /*
@@ -176,7 +172,7 @@ efi_capsule_update_locked(efi_capsule_header_t *capsule,
 * whether to force an EFI reboot), and we're racing against
 * that call. Abort in that case.
 */
-   if (unlikely(system_state == SYSTEM_RESTART)) {
+   if (unlikely(stop_capsules)) {
pr_warn("Capsule update raced with reboot, aborting.\n");
return -EINVAL;
}
@@ -298,3 +294,23 @@ out:
return rv;
 }
 EXPORT_SYMBOL_GPL(efi_capsule_update);
+
+static int capsule_reboot_notify(struct notifier_block *nb,
+unsigned long event, void *cmd)
+{
+   mutex_lock(_mutex);
+   stop_capsules = true;
+   mutex_unlock(_mutex);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block capsule_reboot_nb = {
+   .notifier_call = capsule_reboot_notify,
+};
+
+static int __init capsule_reboot_register(void)
+{
+   return register_reboot_notifier(_reboot_nb);
+}
+core_initcall(capsule_reboot_register);
-- 
2.7.3

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

2016-04-30 Thread Matt Fleming 
On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote:
> 
> You can see here that we've made it past the MMR read in uv_system_init,
> but we die inside of our first EFI callback.  In this example, it looks
> like we're using the kernel page table at the time of the failure, and I
> believe that the failing address is somewhere in our EFI runtime code:
> 
> [0.803396] efi: ATHORLTON EFI md dump:
> [0.803396] type: 5
> [0.803396] pad: 0
> [0.803396] phys_addr: 6a0a6000
> [0.803396] virt_addr: 0
> [0.803396] num_pages: 184
> [0.803396] attribute: 800f
> 
> So it looks like we're trying to read from EFI runtime space while using
> the kernel page table, which fails, presumably because the space is also
> not mapped into the kernel page table.  While I understand *why* it
> fails, and why the address isn't mapped, I don't fully know how we
> should handle fixing it.

How come you're not using the new EFI page tables while making EFI
runtime calls?

Who owns the MMR space and what is it used for? Do both the kernel and
the firmware need access to it? My SGI UV knowledge is zero, so I'm
happy to be educated! I can't think of any analogous memory regions on
x86 where the EFI services require the kernel to map them, other than
the EFI regions themselves.

Runtime EFI regions should be opaque, isolated and self-contained.
This is why there are two phases of execution for firmware; before and
after ExitBootServices(). Once the kernel takes control after
ExitBootServices() firmware can no longer provide timer services, for
example, and doesn't care where the kernel maps the LAPIC because it
never tries to access it.

The fact that the UV firmware does care where the MMR space is mapped
makes me suspect that there's a lack of isolation.

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

2016-04-30 Thread Matt Fleming 
On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote:
> 
> You can see here that we've made it past the MMR read in uv_system_init,
> but we die inside of our first EFI callback.  In this example, it looks
> like we're using the kernel page table at the time of the failure, and I
> believe that the failing address is somewhere in our EFI runtime code:
> 
> [0.803396] efi: ATHORLTON EFI md dump:
> [0.803396] type: 5
> [0.803396] pad: 0
> [0.803396] phys_addr: 6a0a6000
> [0.803396] virt_addr: 0
> [0.803396] num_pages: 184
> [0.803396] attribute: 800f
> 
> So it looks like we're trying to read from EFI runtime space while using
> the kernel page table, which fails, presumably because the space is also
> not mapped into the kernel page table.  While I understand *why* it
> fails, and why the address isn't mapped, I don't fully know how we
> should handle fixing it.

How come you're not using the new EFI page tables while making EFI
runtime calls?

Who owns the MMR space and what is it used for? Do both the kernel and
the firmware need access to it? My SGI UV knowledge is zero, so I'm
happy to be educated! I can't think of any analogous memory regions on
x86 where the EFI services require the kernel to map them, other than
the EFI regions themselves.

Runtime EFI regions should be opaque, isolated and self-contained.
This is why there are two phases of execution for firmware; before and
after ExitBootServices(). Once the kernel takes control after
ExitBootServices() firmware can no longer provide timer services, for
example, and doesn't care where the kernel maps the LAPIC because it
never tries to access it.

The fact that the UV firmware does care where the MMR space is mapped
makes me suspect that there's a lack of isolation.

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Vijay Pandurangan 
On Sat, Apr 30, 2016 at 5:52 PM, Ben Greear  wrote:
>>
>> Good point, so if you had:
>>
>> eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
>> userspace-stub <->eth1
>>
>> and user-space hub enabled this elide flag, things would work, right?
>> Then, it seems like what we need is a way to tell the kernel
>> router/bridge logic to follow elide signals in packets coming from
>> veth. I'm not sure what the best way to do this is because I'm less
>> familiar with conventions in that part of the kernel, but assuming
>> there's a way to do this, would it be acceptable?
>
>
> You cannot receive on one veth without transmitting on the other, so
> I think the elide csum logic can go on the raw-socket, and apply to packets
> in the transmit-from-user-space direction.  Just allowing the socket to make
> the veth behave like it used to before this patch in question should be good
> enough, since that worked for us for years.  So, just an option to modify
> the
> ip_summed for pkts sent on a socket is probably sufficient.

I don't think this is right. Consider:

- App A  sends out corrupt packets 50% of the time and discards inbound data.
- App B doesn't care about corrupt packets and is happy to receive
them and has some way of dealing with them (special case)
- App C is a regular app, say nc or something.

In your world, where A decides what happens to data it transmits,
then
A<--veth-->B and A<---wire-->B will have the same behaviour

but

A<-- veth --> C and A<-- wire --> C will have _different_ behaviour: C
will behave incorrectly if it's connected over veth but correctly if
connected with a wire. That is a bug.

Since A cannot know what the app it's talking to will desire, I argue
that both sides of a message must be opted in to this optimization.






>
>>> There may be no sockets on the vethB port.  And reader/writer is not
>>> a good way to look at it since I am implementing a bi-directional bridge
>>> in
>>> user-space and each packet-socket is for both rx and tx.
>>
>>
>> Sure, but we could model a bidrectional connection as two
>> unidirectional sockets for our discussions here, right?
>
>
> Best not to I think, you want to make sure that one socket can
> correctly handle tx and rx.  As long as that works, then using
> uni-directional sockets should work too.
>
>
> Thanks,
> Ben
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-04-30 Thread Vijay Pandurangan 
On Sat, Apr 30, 2016 at 5:52 PM, Ben Greear  wrote:
>>
>> Good point, so if you had:
>>
>> eth0 <-> raw <-> user space-bridge <-> raw <-> vethA <-> veth B <->
>> userspace-stub <->eth1
>>
>> and user-space hub enabled this elide flag, things would work, right?
>> Then, it seems like what we need is a way to tell the kernel
>> router/bridge logic to follow elide signals in packets coming from
>> veth. I'm not sure what the best way to do this is because I'm less
>> familiar with conventions in that part of the kernel, but assuming
>> there's a way to do this, would it be acceptable?
>
>
> You cannot receive on one veth without transmitting on the other, so
> I think the elide csum logic can go on the raw-socket, and apply to packets
> in the transmit-from-user-space direction.  Just allowing the socket to make
> the veth behave like it used to before this patch in question should be good
> enough, since that worked for us for years.  So, just an option to modify
> the
> ip_summed for pkts sent on a socket is probably sufficient.

I don't think this is right. Consider:

- App A  sends out corrupt packets 50% of the time and discards inbound data.
- App B doesn't care about corrupt packets and is happy to receive
them and has some way of dealing with them (special case)
- App C is a regular app, say nc or something.

In your world, where A decides what happens to data it transmits,
then
A<--veth-->B and A<---wire-->B will have the same behaviour

but

A<-- veth --> C and A<-- wire --> C will have _different_ behaviour: C
will behave incorrectly if it's connected over veth but correctly if
connected with a wire. That is a bug.

Since A cannot know what the app it's talking to will desire, I argue
that both sides of a message must be opted in to this optimization.






>
>>> There may be no sockets on the vethB port.  And reader/writer is not
>>> a good way to look at it since I am implementing a bi-directional bridge
>>> in
>>> user-space and each packet-socket is for both rx and tx.
>>
>>
>> Sure, but we could model a bidrectional connection as two
>> unidirectional sockets for our discussions here, right?
>
>
> Best not to I think, you want to make sure that one socket can
> correctly handle tx and rx.  As long as that works, then using
> uni-directional sockets should work too.
>
>
> Thanks,
> Ben
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

2016-04-30 Thread Andy Lutomirski 
On Apr 30, 2016 12:17 PM, "Borislav Petkov"  wrote:
>
> On Sat, Apr 30, 2016 at 10:47:49AM -0700, Andy Lutomirski wrote:
> > Take a look at vread_pvclock.  I decided that __pvclock_read_cycles
> > was too ugly to use and was very slow and I just gave up and rewrote
> > it.
>
> Should we kill __pvclock_read_cycles in favor of vread_pvclock? It looks
> doable at a quick scan...
>

The in-kernel version might have to be a bit different because it
needs to handle the !stable case.  If !stable, it should just use the
current CPU's copy which means that, realistically, it should just
get_cpu and use the local copy unconditionally.  Other than that, it
could look a lot like the vread_pvclock variant.

But I agree, the current thing is incomprehensible.

--Andy

> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)
> --

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

2016-04-30 Thread Andy Lutomirski 
On Apr 30, 2016 12:17 PM, "Borislav Petkov"  wrote:
>
> On Sat, Apr 30, 2016 at 10:47:49AM -0700, Andy Lutomirski wrote:
> > Take a look at vread_pvclock.  I decided that __pvclock_read_cycles
> > was too ugly to use and was very slow and I just gave up and rewrote
> > it.
>
> Should we kill __pvclock_read_cycles in favor of vread_pvclock? It looks
> doable at a quick scan...
>

The in-kernel version might have to be a bit different because it
needs to handle the !stable case.  If !stable, it should just use the
current CPU's copy which means that, realistically, it should just
get_cpu and use the local copy unconditionally.  Other than that, it
could look a lot like the vread_pvclock variant.

But I agree, the current thing is incomprehensible.

--Andy

> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)
> --

Re: [PATCH 0/2] scop GFP_NOFS api

2016-04-30 Thread NeilBrown 
On Fri, Apr 29 2016, Michal Hocko wrote:

>
> One think I have learned is that shrinkers can be really complex and
> getting rid of GFP_NOFS will be really hard so I would really like to
> start the easiest way possible and remove the direct usage and replace
> it by scope one which would at least _explain_ why it is needed. I think
> this is a reasonable _first_ step and a large step ahead because we have
> a good chance to get rid of a large number of those which were used
> "just because I wasn't sure and this should be safe, right?". I wouldn't
> be surprised if we end up with a very small number of both scope and
> direct usage in the end.

Yes, shrinkers can be complex.  About two of them are.  We could fix
lots and lots of call sites, or fix two shrinkers.
OK, that's a bit unfair as fixing one of the shrinkers involves changing
many ->evict_inode() functions.  But that would be a very focused
change.

I think your proposal is little more than re-arranging deck chairs on
the titanic.  Yes, it might give everybody a better view of the iceberg
but the iceberg is still there and in reality we can already see it.

The main iceberg is evict_inode.  It appears in both examples given so
far: xfs and gfs.  There are other little icebergs but they won't last
long after evict_inode is dealt with.

One particular problem with your process-context idea is that it isn't
inherited across threads.
Steve Whitehouse's example in gfs shows how allocation dependencies can
even cross into user space.

A more localized one that I have seen is that NFSv4 sometimes needs to
start up a state-management thread (particularly if the server
restarted).
It uses kthread_run(), which doesn't actually create the thread but asks
kthreadd to do it.  If NFS writeout is waiting for state management it
would need to make sure that kthreadd runs in allocation context to
avoid deadlock.
I feel that I've forgotten some important detail here and this might
have been fixed somehow, but the point still stands that the allocation
context can cross from thread to thread and can effectively become
anything and everything.

It is OK to wait for memory to be freed.  It is not OK to wait for any
particular piece of memory to be freed because you don't always know who
is waiting for you, or who you really are waiting on to free that
memory.

Whenever trying to free memory I think you need to do best-effort
without blocking.

>
> I would also like to revisit generic inode/dentry shrinker and see
> whether it could be more __GFP_FS friendly. As you say many FS might
> even not depend on some FS internal locks so pushing GFP_FS check down
> the layers might make a lot of sense and allow to clean some [id]cache
> even for __GFP_FS context.

I think the only part of prune_dcache_sb() that might need care is
iput() which boils down to evict().  The final unlink for NFS
silly-rename might happen in there too (in d_iput).
shrinking the dcache seems rather late to be performing that unlink
though, so I've probably missed some key detail.

If we find a way for evict(), when called from the shrinker, to be
non-blocking, and generally require all shrinkers to be non-blocking,
then many of these allocation problems evaporate.

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 0/2] scop GFP_NOFS api

2016-04-30 Thread NeilBrown 
On Fri, Apr 29 2016, Michal Hocko wrote:

>
> One think I have learned is that shrinkers can be really complex and
> getting rid of GFP_NOFS will be really hard so I would really like to
> start the easiest way possible and remove the direct usage and replace
> it by scope one which would at least _explain_ why it is needed. I think
> this is a reasonable _first_ step and a large step ahead because we have
> a good chance to get rid of a large number of those which were used
> "just because I wasn't sure and this should be safe, right?". I wouldn't
> be surprised if we end up with a very small number of both scope and
> direct usage in the end.

Yes, shrinkers can be complex.  About two of them are.  We could fix
lots and lots of call sites, or fix two shrinkers.
OK, that's a bit unfair as fixing one of the shrinkers involves changing
many ->evict_inode() functions.  But that would be a very focused
change.

I think your proposal is little more than re-arranging deck chairs on
the titanic.  Yes, it might give everybody a better view of the iceberg
but the iceberg is still there and in reality we can already see it.

The main iceberg is evict_inode.  It appears in both examples given so
far: xfs and gfs.  There are other little icebergs but they won't last
long after evict_inode is dealt with.

One particular problem with your process-context idea is that it isn't
inherited across threads.
Steve Whitehouse's example in gfs shows how allocation dependencies can
even cross into user space.

A more localized one that I have seen is that NFSv4 sometimes needs to
start up a state-management thread (particularly if the server
restarted).
It uses kthread_run(), which doesn't actually create the thread but asks
kthreadd to do it.  If NFS writeout is waiting for state management it
would need to make sure that kthreadd runs in allocation context to
avoid deadlock.
I feel that I've forgotten some important detail here and this might
have been fixed somehow, but the point still stands that the allocation
context can cross from thread to thread and can effectively become
anything and everything.

It is OK to wait for memory to be freed.  It is not OK to wait for any
particular piece of memory to be freed because you don't always know who
is waiting for you, or who you really are waiting on to free that
memory.

Whenever trying to free memory I think you need to do best-effort
without blocking.

>
> I would also like to revisit generic inode/dentry shrinker and see
> whether it could be more __GFP_FS friendly. As you say many FS might
> even not depend on some FS internal locks so pushing GFP_FS check down
> the layers might make a lot of sense and allow to clean some [id]cache
> even for __GFP_FS context.

I think the only part of prune_dcache_sb() that might need care is
iput() which boils down to evict().  The final unlink for NFS
silly-rename might happen in there too (in d_iput).
shrinking the dcache seems rather late to be performing that unlink
though, so I've probably missed some key detail.

If we find a way for evict(), when called from the shrinker, to be
non-blocking, and generally require all shrinkers to be non-blocking,
then many of these allocation problems evaporate.

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

2016-04-30 Thread Greg KH 
On Sat, Apr 30, 2016 at 09:43:09PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Saturday, April 30, 2016 2:05 PM
> > To: KY Srinivasan 
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> > jasow...@redhat.com
> > Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> > 
> > On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> > > From: Vitaly Kuznetsov 
> > >
> > > Hyper-V VMs can be replicated to another hosts and there is a feature to
> > > set different IP for replicas, it is called 'Failover TCP/IP'. When
> > > such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as
> > soon
> > > as we finish negotiation procedure. The problem is that it can happen (and
> > > it actually happens) before userspace daemon connects and we reply with
> > > HV_E_FAIL to the message. As there are no repetitions we fail to set the
> > > requested IP.
> > >
> > > Solve the issue by postponing our reply to the negotiation message till
> > > userspace daemon is connected. We can't wait too long as there is a
> > > host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> > > frame the whole KVP service will become inactive. The solution is not
> > > ideal - if it takes userspace daemon more than 60 seconds to connect
> > > IP Failover will still fail but I don't see a solution with our current
> > > separation between kernel and userspace parts.
> > >
> > > Other two modules (VSS and FCOPY) don't require such delay, leave them
> > > untouched.
> > >
> > > Signed-off-by: Vitaly Kuznetsov 
> > > Signed-off-by: K. Y. Srinivasan 
> > > ---
> > >  drivers/hv/hv_kvp.c   |   31 +++
> > >  drivers/hv/hyperv_vmbus.h |5 +
> > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > 
> > This series doesn't apply to my tree :(
> 
> Looks like you have already applied most of the patches in this series. I 
> will resend what is not applied.

If this was a "resend", why didn't it show that in the patch
description?

Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

2016-04-30 Thread Greg KH 
On Sat, Apr 30, 2016 at 09:43:09PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Saturday, April 30, 2016 2:05 PM
> > To: KY Srinivasan 
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> > jasow...@redhat.com
> > Subject: Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover
> > 
> > On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote:
> > > From: Vitaly Kuznetsov 
> > >
> > > Hyper-V VMs can be replicated to another hosts and there is a feature to
> > > set different IP for replicas, it is called 'Failover TCP/IP'. When
> > > such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as
> > soon
> > > as we finish negotiation procedure. The problem is that it can happen (and
> > > it actually happens) before userspace daemon connects and we reply with
> > > HV_E_FAIL to the message. As there are no repetitions we fail to set the
> > > requested IP.
> > >
> > > Solve the issue by postponing our reply to the negotiation message till
> > > userspace daemon is connected. We can't wait too long as there is a
> > > host-side timeout (cca. 75 seconds) and if we fail to reply in this time
> > > frame the whole KVP service will become inactive. The solution is not
> > > ideal - if it takes userspace daemon more than 60 seconds to connect
> > > IP Failover will still fail but I don't see a solution with our current
> > > separation between kernel and userspace parts.
> > >
> > > Other two modules (VSS and FCOPY) don't require such delay, leave them
> > > untouched.
> > >
> > > Signed-off-by: Vitaly Kuznetsov 
> > > Signed-off-by: K. Y. Srinivasan 
> > > ---
> > >  drivers/hv/hv_kvp.c   |   31 +++
> > >  drivers/hv/hyperv_vmbus.h |5 +
> > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > 
> > This series doesn't apply to my tree :(
> 
> Looks like you have already applied most of the patches in this series. I 
> will resend what is not applied.

If this was a "resend", why didn't it show that in the patch
description?

  1   2   3   4   >