[PATCH] spi: s3c64xx: add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Signed-off-by: Andi Shyti 
---
 drivers/spi/spi-s3c64xx.c | 18 --
 include/linux/platform_data/spi-s3c64xx.h |  4 +---
 2 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index de7df20f8712..7ef68d45edfb 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1,17 +1,7 @@
-/*
- * Copyright (C) 2009 Samsung Electronics Ltd.
- * Jaswinder Singh 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * 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.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2009 Samsung Electronics Co., Ltd.
+//  Jaswinder Singh 
 
 #include 
 #include 
diff --git a/include/linux/platform_data/spi-s3c64xx.h 
b/include/linux/platform_data/spi-s3c64xx.h
index da79774078a7..8917f38c97c5 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -2,9 +2,7 @@
  * Copyright (C) 2009 Samsung Electronics Ltd.
  * Jaswinder Singh 
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
+ * SPDX-License-Identifier: GPL-2.0
  */
 
 #ifndef __SPI_S3C64XX_H
-- 
2.15.1

[PATCH] spi: s3c64xx: add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Signed-off-by: Andi Shyti 
---
 drivers/spi/spi-s3c64xx.c | 18 --
 include/linux/platform_data/spi-s3c64xx.h |  4 +---
 2 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index de7df20f8712..7ef68d45edfb 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1,17 +1,7 @@
-/*
- * Copyright (C) 2009 Samsung Electronics Ltd.
- * Jaswinder Singh 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * 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.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2009 Samsung Electronics Co., Ltd.
+//  Jaswinder Singh 
 
 #include 
 #include 
diff --git a/include/linux/platform_data/spi-s3c64xx.h 
b/include/linux/platform_data/spi-s3c64xx.h
index da79774078a7..8917f38c97c5 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -2,9 +2,7 @@
  * Copyright (C) 2009 Samsung Electronics Ltd.
  * Jaswinder Singh 
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
+ * SPDX-License-Identifier: GPL-2.0
  */
 
 #ifndef __SPI_S3C64XX_H
-- 
2.15.1

Re: [PATCH v5] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Mon 11-12-17 16:23:31, john.hubb...@gmail.com wrote:
> From: John Hubbard 
> 
> -- Expand the documentation to discuss the hazards in
>enough detail to allow avoiding them.
> 
> -- Mention the upcoming MAP_FIXED_SAFE flag.
> 
> -- Enhance the alignment requirement slightly.
> 
> CC: Michael Ellerman 
> CC: Jann Horn 
> CC: Matthew Wilcox 
> CC: Michal Hocko 
> CC: Mike Rapoport 
> CC: Cyril Hrubis 
> CC: Michal Hocko 
> CC: Pavel Machek 
> Signed-off-by: John Hubbard 

Acked-by: Michal Hocko 

Thanks! I plan to submit my MAP_FIXED_FOO today and will send this
together with my mman update.

> ---
> 
> Changes since v4:
> 
> -- v2 ("mmap.2: MAP_FIXED is no longer discouraged") was applied already,
>so v5 is a merge, including rewording of the paragraph transitions.
> 
> -- We seem to have consensus about what to say about alignment
>now, and this includes that new wording.
> 
> Changes since v3:
> 
> -- Removed the "how to use this safely" part, and
>the SHMLBA part, both as a result of Michal Hocko's
>review.
> 
> -- A few tiny wording fixes, at the not-quite-typo level.
> 
> Changes since v2:
> 
> -- Fixed up the "how to use safely" example, in response
>to Mike Rapoport's review.
> 
> -- Changed the alignment requirement from system page
>size, to SHMLBA. This was inspired by (but not yet
>recommended by) Cyril Hrubis' review.
> 
> -- Formatting: underlined /proc//maps
> 
> Changes since v1:
> 
> -- Covered topics recommended by Matthew Wilcox
>and Jann Horn, in their recent review: the hazards
>of overwriting pre-exising mappings, and some notes
>about how to use MAP_FIXED safely.
> 
> -- Rewrote the commit description accordingly.
> 
>  man2/mmap.2 | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/mmap.2 b/man2/mmap.2
> index a5a8eb47a..400cfda2d 100644
> --- a/man2/mmap.2
> +++ b/man2/mmap.2
> @@ -212,8 +212,9 @@ Don't interpret
>  .I addr
>  as a hint: place the mapping at exactly that address.
>  .I addr
> -must be a multiple of the page size.
> -If the memory region specified by
> +must be suitably aligned: for most architectures a multiple of page
> +size is sufficient; however, some architectures may impose additional
> +restrictions. If the memory region specified by
>  .I addr
>  and
>  .I len
> @@ -226,6 +227,33 @@ Software that aspires to be portable should use this 
> option with care, keeping
>  in mind that the exact layout of a process' memory map is allowed to change
>  significantly between kernel versions, C library versions, and operating 
> system
>  releases.
> +.IP
> +Furthermore, this option is extremely hazardous (when used on its own), 
> because
> +it forcibly removes pre-existing mappings, making it easy for a 
> multi-threaded
> +process to corrupt its own address space.
> +.IP
> +For example, thread A looks through
> +.I /proc//maps
> +and locates an available
> +address range, while thread B simultaneously acquires part or all of that 
> same
> +address range. Thread A then calls mmap(MAP_FIXED), effectively overwriting
> +the mapping that thread B created.
> +.IP
> +Thread B need not create a mapping directly; simply making a library call
> +that, internally, uses
> +.I dlopen(3)
> +to load some other shared library, will
> +suffice. The dlopen(3) call will map the library into the process's address
> +space. Furthermore, almost any library call may be implemented using this
> +technique.
> +Examples include brk(2), malloc(3), pthread_create(3), and the PAM libraries
> +(http://www.linux-pam.org).
> +.IP
> +Newer kernels
> +(Linux 4.16 and later) have a
> +.B MAP_FIXED_SAFE
> +option that avoids the corruption problem; if available, MAP_FIXED_SAFE
> +should be preferred over MAP_FIXED.
>  .TP
>  .B MAP_GROWSDOWN
>  This flag is used for stacks.
> -- 
> 2.15.1
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v5] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Mon 11-12-17 16:23:31, john.hubb...@gmail.com wrote:
> From: John Hubbard 
> 
> -- Expand the documentation to discuss the hazards in
>enough detail to allow avoiding them.
> 
> -- Mention the upcoming MAP_FIXED_SAFE flag.
> 
> -- Enhance the alignment requirement slightly.
> 
> CC: Michael Ellerman 
> CC: Jann Horn 
> CC: Matthew Wilcox 
> CC: Michal Hocko 
> CC: Mike Rapoport 
> CC: Cyril Hrubis 
> CC: Michal Hocko 
> CC: Pavel Machek 
> Signed-off-by: John Hubbard 

Acked-by: Michal Hocko 

Thanks! I plan to submit my MAP_FIXED_FOO today and will send this
together with my mman update.

> ---
> 
> Changes since v4:
> 
> -- v2 ("mmap.2: MAP_FIXED is no longer discouraged") was applied already,
>so v5 is a merge, including rewording of the paragraph transitions.
> 
> -- We seem to have consensus about what to say about alignment
>now, and this includes that new wording.
> 
> Changes since v3:
> 
> -- Removed the "how to use this safely" part, and
>the SHMLBA part, both as a result of Michal Hocko's
>review.
> 
> -- A few tiny wording fixes, at the not-quite-typo level.
> 
> Changes since v2:
> 
> -- Fixed up the "how to use safely" example, in response
>to Mike Rapoport's review.
> 
> -- Changed the alignment requirement from system page
>size, to SHMLBA. This was inspired by (but not yet
>recommended by) Cyril Hrubis' review.
> 
> -- Formatting: underlined /proc//maps
> 
> Changes since v1:
> 
> -- Covered topics recommended by Matthew Wilcox
>and Jann Horn, in their recent review: the hazards
>of overwriting pre-exising mappings, and some notes
>about how to use MAP_FIXED safely.
> 
> -- Rewrote the commit description accordingly.
> 
>  man2/mmap.2 | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/mmap.2 b/man2/mmap.2
> index a5a8eb47a..400cfda2d 100644
> --- a/man2/mmap.2
> +++ b/man2/mmap.2
> @@ -212,8 +212,9 @@ Don't interpret
>  .I addr
>  as a hint: place the mapping at exactly that address.
>  .I addr
> -must be a multiple of the page size.
> -If the memory region specified by
> +must be suitably aligned: for most architectures a multiple of page
> +size is sufficient; however, some architectures may impose additional
> +restrictions. If the memory region specified by
>  .I addr
>  and
>  .I len
> @@ -226,6 +227,33 @@ Software that aspires to be portable should use this 
> option with care, keeping
>  in mind that the exact layout of a process' memory map is allowed to change
>  significantly between kernel versions, C library versions, and operating 
> system
>  releases.
> +.IP
> +Furthermore, this option is extremely hazardous (when used on its own), 
> because
> +it forcibly removes pre-existing mappings, making it easy for a 
> multi-threaded
> +process to corrupt its own address space.
> +.IP
> +For example, thread A looks through
> +.I /proc//maps
> +and locates an available
> +address range, while thread B simultaneously acquires part or all of that 
> same
> +address range. Thread A then calls mmap(MAP_FIXED), effectively overwriting
> +the mapping that thread B created.
> +.IP
> +Thread B need not create a mapping directly; simply making a library call
> +that, internally, uses
> +.I dlopen(3)
> +to load some other shared library, will
> +suffice. The dlopen(3) call will map the library into the process's address
> +space. Furthermore, almost any library call may be implemented using this
> +technique.
> +Examples include brk(2), malloc(3), pthread_create(3), and the PAM libraries
> +(http://www.linux-pam.org).
> +.IP
> +Newer kernels
> +(Linux 4.16 and later) have a
> +.B MAP_FIXED_SAFE
> +option that avoids the corruption problem; if available, MAP_FIXED_SAFE
> +should be preferred over MAP_FIXED.
>  .TP
>  .B MAP_GROWSDOWN
>  This flag is used for stacks.
> -- 
> 2.15.1
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm: Release a semaphore in 'get_vaddr_frames()'

[Michal Hocko]

On Mon 11-12-17 22:10:09, Christophe JAILLET wrote:
> A semaphore is acquired before this check, so we must release it before
> leaving.
> 
> Fixes: b7f0554a56f2 ("mm: fail get_vaddr_frames() for filesystem-dax 
> mappings")
> Signed-off-by: Christophe JAILLET 

Looks good to me now.
Acked-by: Michal Hocko 

Thanks

> ---
> -- Untested --
> 
> v1 -> v2: 'goto out' instead of duplicating code
> ---
>  mm/frame_vector.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 297c7238f7d4..c64dca6e27c2 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -62,8 +62,10 @@ int get_vaddr_frames(unsigned long start, unsigned int 
> nr_frames,
>* get_user_pages_longterm() and disallow it for filesystem-dax
>* mappings.
>*/
> - if (vma_is_fsdax(vma))
> - return -EOPNOTSUPP;
> + if (vma_is_fsdax(vma)) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
>  
>   if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
>   vec->got_ref = true;
> -- 
> 2.14.1
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm: Release a semaphore in 'get_vaddr_frames()'

[Michal Hocko]

On Mon 11-12-17 22:10:09, Christophe JAILLET wrote:
> A semaphore is acquired before this check, so we must release it before
> leaving.
> 
> Fixes: b7f0554a56f2 ("mm: fail get_vaddr_frames() for filesystem-dax 
> mappings")
> Signed-off-by: Christophe JAILLET 

Looks good to me now.
Acked-by: Michal Hocko 

Thanks

> ---
> -- Untested --
> 
> v1 -> v2: 'goto out' instead of duplicating code
> ---
>  mm/frame_vector.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 297c7238f7d4..c64dca6e27c2 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -62,8 +62,10 @@ int get_vaddr_frames(unsigned long start, unsigned int 
> nr_frames,
>* get_user_pages_longterm() and disallow it for filesystem-dax
>* mappings.
>*/
> - if (vma_is_fsdax(vma))
> - return -EOPNOTSUPP;
> + if (vma_is_fsdax(vma)) {
> + ret = -EOPNOTSUPP;
> + goto out;
> + }
>  
>   if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
>   vec->got_ref = true;
> -- 
> 2.14.1
> 

-- 
Michal Hocko
SUSE Labs

[PATCH] [media] ir-spi: add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Update also the copyright owner adding myself as co-owner of the
copyright.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/ir-spi.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
index 29ed0638cb74..a32a84ae2d0b 100644
--- a/drivers/media/rc/ir-spi.c
+++ b/drivers/media/rc/ir-spi.c
@@ -1,13 +1,8 @@
-/*
- * Copyright (c) 2016 Samsung Electronics Co., Ltd.
- * Author: Andi Shyti 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * SPI driven IR LED device driver
- */
+// SPDX-License-Identifier: GPL-2.0
+// SPI driven IR LED device driver
+//
+// Copyright (c) 2016 Samsung Electronics Co., Ltd.
+// Copyright (c) Andi Shyti 
 
 #include 
 #include 
-- 
2.15.1

[PATCH] [media] ir-spi: add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Update also the copyright owner adding myself as co-owner of the
copyright.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/ir-spi.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
index 29ed0638cb74..a32a84ae2d0b 100644
--- a/drivers/media/rc/ir-spi.c
+++ b/drivers/media/rc/ir-spi.c
@@ -1,13 +1,8 @@
-/*
- * Copyright (c) 2016 Samsung Electronics Co., Ltd.
- * Author: Andi Shyti 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * SPI driven IR LED device driver
- */
+// SPDX-License-Identifier: GPL-2.0
+// SPI driven IR LED device driver
+//
+// Copyright (c) 2016 Samsung Electronics Co., Ltd.
+// Copyright (c) Andi Shyti 
 
 #include 
 #include 
-- 
2.15.1

Re: [PATCH] mm, hugetlbfs: include mm.h for vm_operations_struct

[Michal Hocko]

On Mon 11-12-17 17:21:27, Arnd Bergmann wrote:
> The infiniband umem code causes a build failure in some configurations:
> 
> In file included from drivers/infiniband/core/umem_odp.c:41:0:
> include/linux/hugetlb.h: In function 'vma_kernel_pagesize':
> include/linux/hugetlb.h:262:32: error: dereferencing pointer to incomplete 
> type 'const struct vm_operations_struct'
> 
> Including the header file that defines the structure is sufficient to
> avoid this.
> 
> Fixes: ac9284a6b670 ("mm, hugetlbfs: introduce ->pagesize() to 
> vm_operations_struct")
> Signed-off-by: Arnd Bergmann 

I've tried to do the same but the compilation failed for other
arches/configs. See 
http://lkml.kernel.org/r/20171210113715.ge20...@dhcp22.suse.cz

> ---
>  include/linux/hugetlb.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index b0f1f6768336..082ff47201be 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct ctl_table;
> -- 
> 2.9.0
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, hugetlbfs: include mm.h for vm_operations_struct

[Michal Hocko]

On Mon 11-12-17 17:21:27, Arnd Bergmann wrote:
> The infiniband umem code causes a build failure in some configurations:
> 
> In file included from drivers/infiniband/core/umem_odp.c:41:0:
> include/linux/hugetlb.h: In function 'vma_kernel_pagesize':
> include/linux/hugetlb.h:262:32: error: dereferencing pointer to incomplete 
> type 'const struct vm_operations_struct'
> 
> Including the header file that defines the structure is sufficient to
> avoid this.
> 
> Fixes: ac9284a6b670 ("mm, hugetlbfs: introduce ->pagesize() to 
> vm_operations_struct")
> Signed-off-by: Arnd Bergmann 

I've tried to do the same but the compilation failed for other
arches/configs. See 
http://lkml.kernel.org/r/20171210113715.ge20...@dhcp22.suse.cz

> ---
>  include/linux/hugetlb.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index b0f1f6768336..082ff47201be 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct ctl_table;
> -- 
> 2.9.0
> 

-- 
Michal Hocko
SUSE Labs

[PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

[Javier Martinez Canillas]

Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
for each Exynos 542x DTS. But unfortunately it missed to enable it for the
Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.

Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x 
Mixer nodes")
Signed-off-by: Javier Martinez Canillas 
Acked-by: Marek Szyprowski 

---

Changes in v2:
- Remove RFT tag.
- Add Marek's Acked-by tag.
- Add fixes tag.

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index b2b95ff205e8..0029ec27819c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -664,6 +664,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
 /* eMMC flash */
 _0 {
status = "okay";
-- 
2.14.3

RE: [intel-sgx-kernel-dev] [PATCH v7 4/8] intel_sgx: driver for Intel Software Guard Extensions

[Ayoun, Serge]

> Subject: [intel-sgx-kernel-dev] [PATCH v7 4/8] intel_sgx: driver for Intel
> Software Guard Extensions
> 
> Intel SGX is a set of CPU instructions that can be used by applications
> to set aside private regions of code and data.  The code outside the
> enclave is disallowed to access the memory inside the enclave by the CPU
> access control.
> 
> SGX driver provides a ioctl API for loading and initializing enclaves.
> Address range for enclaves is reserved with mmap() and they are
> destroyed with munmap(). Enclave construction, measurement and
> initialization is done with the provided the ioctl API.
> 
> The driver implements also a swapper thread ksgxswapd for EPC pages
> backed by a private shmem file. Currently it has a limitation of not
> swapping VA pages but there is nothing preventing to implement it later
> on. Now it was scoped out in order to keep the implementation simple.
> 
> The parameter struct for SGX_IOC_ENCLAVE_INIT does not contain a
> parameter to supply a launch token. Generating and using tokens is best
> to be kept in the control of the kernel because it has direct binding to
> the IA32_SGXPUBKEYHASHx MSRs (a core must have MSRs set to the same
> value as the signer of token).
> 
> By giving user space any role in the launch process is a risk for
> introducing bottlenecks as kernel must exhibit behavior that user space
> launch daemon depends on, properietary risks (closed launch daemons on
> closed platforms) and stability risks as there would be division of
> semantics between user space and kernel.
> 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  arch/x86/include/asm/sgx.h  | 233 ++
>  arch/x86/include/asm/sgx_arch.h | 270 +++
>  arch/x86/include/uapi/asm/sgx.h | 138 
>  drivers/platform/x86/Kconfig|   2 +
>  drivers/platform/x86/Makefile   |   1 +
>  drivers/platform/x86/intel_sgx/Kconfig  |  19 +
>  drivers/platform/x86/intel_sgx/Makefile |  13 +
>  drivers/platform/x86/intel_sgx/sgx.h| 251 ++
>  drivers/platform/x86/intel_sgx/sgx_encl.c   | 974
> 
>  drivers/platform/x86/intel_sgx/sgx_ioctl.c  | 281 +++
>  drivers/platform/x86/intel_sgx/sgx_main.c   | 413 ++
>  drivers/platform/x86/intel_sgx/sgx_page_cache.c | 647 
>  drivers/platform/x86/intel_sgx/sgx_util.c   | 346 +
>  drivers/platform/x86/intel_sgx/sgx_vma.c| 117 +++
>  14 files changed, 3705 insertions(+)
>  create mode 100644 arch/x86/include/asm/sgx.h
>  create mode 100644 arch/x86/include/asm/sgx_arch.h
>  create mode 100644 arch/x86/include/uapi/asm/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
>  create mode 100644 drivers/platform/x86/intel_sgx/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c
> 
> diff --git a/arch/x86/include/asm/sgx.h b/arch/x86/include/asm/sgx.h
> new file mode 100644
> index ..2c2575100d0d
> --- /dev/null
> +++ b/arch/x86/include/asm/sgx.h
> @@ -0,0 +1,233 @@
> +/*
> + * This file is provided under a dual BSD/GPLv2 license.  When using or
> + * redistributing this file, you may do so under either license.
> + *
> + * GPL LICENSE SUMMARY
> + *
> + * Copyright(c) 2016-2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License 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.
> + *
> + * Contact Information:
> + * Jarkko Sakkinen 
> + * Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> + *
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016-2017 Intel Corporation.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + *   * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + *   * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + *  

[PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

[Javier Martinez Canillas]

Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
for each Exynos 542x DTS. But unfortunately it missed to enable it for the
Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.

Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x 
Mixer nodes")
Signed-off-by: Javier Martinez Canillas 
Acked-by: Marek Szyprowski 

---

Changes in v2:
- Remove RFT tag.
- Add Marek's Acked-by tag.
- Add fixes tag.

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index b2b95ff205e8..0029ec27819c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -664,6 +664,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
 /* eMMC flash */
 _0 {
status = "okay";
-- 
2.14.3

RE: [intel-sgx-kernel-dev] [PATCH v7 4/8] intel_sgx: driver for Intel Software Guard Extensions

[Ayoun, Serge]

> Subject: [intel-sgx-kernel-dev] [PATCH v7 4/8] intel_sgx: driver for Intel
> Software Guard Extensions
> 
> Intel SGX is a set of CPU instructions that can be used by applications
> to set aside private regions of code and data.  The code outside the
> enclave is disallowed to access the memory inside the enclave by the CPU
> access control.
> 
> SGX driver provides a ioctl API for loading and initializing enclaves.
> Address range for enclaves is reserved with mmap() and they are
> destroyed with munmap(). Enclave construction, measurement and
> initialization is done with the provided the ioctl API.
> 
> The driver implements also a swapper thread ksgxswapd for EPC pages
> backed by a private shmem file. Currently it has a limitation of not
> swapping VA pages but there is nothing preventing to implement it later
> on. Now it was scoped out in order to keep the implementation simple.
> 
> The parameter struct for SGX_IOC_ENCLAVE_INIT does not contain a
> parameter to supply a launch token. Generating and using tokens is best
> to be kept in the control of the kernel because it has direct binding to
> the IA32_SGXPUBKEYHASHx MSRs (a core must have MSRs set to the same
> value as the signer of token).
> 
> By giving user space any role in the launch process is a risk for
> introducing bottlenecks as kernel must exhibit behavior that user space
> launch daemon depends on, properietary risks (closed launch daemons on
> closed platforms) and stability risks as there would be division of
> semantics between user space and kernel.
> 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  arch/x86/include/asm/sgx.h  | 233 ++
>  arch/x86/include/asm/sgx_arch.h | 270 +++
>  arch/x86/include/uapi/asm/sgx.h | 138 
>  drivers/platform/x86/Kconfig|   2 +
>  drivers/platform/x86/Makefile   |   1 +
>  drivers/platform/x86/intel_sgx/Kconfig  |  19 +
>  drivers/platform/x86/intel_sgx/Makefile |  13 +
>  drivers/platform/x86/intel_sgx/sgx.h| 251 ++
>  drivers/platform/x86/intel_sgx/sgx_encl.c   | 974
> 
>  drivers/platform/x86/intel_sgx/sgx_ioctl.c  | 281 +++
>  drivers/platform/x86/intel_sgx/sgx_main.c   | 413 ++
>  drivers/platform/x86/intel_sgx/sgx_page_cache.c | 647 
>  drivers/platform/x86/intel_sgx/sgx_util.c   | 346 +
>  drivers/platform/x86/intel_sgx/sgx_vma.c| 117 +++
>  14 files changed, 3705 insertions(+)
>  create mode 100644 arch/x86/include/asm/sgx.h
>  create mode 100644 arch/x86/include/asm/sgx_arch.h
>  create mode 100644 arch/x86/include/uapi/asm/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
>  create mode 100644 drivers/platform/x86/intel_sgx/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c
> 
> diff --git a/arch/x86/include/asm/sgx.h b/arch/x86/include/asm/sgx.h
> new file mode 100644
> index ..2c2575100d0d
> --- /dev/null
> +++ b/arch/x86/include/asm/sgx.h
> @@ -0,0 +1,233 @@
> +/*
> + * This file is provided under a dual BSD/GPLv2 license.  When using or
> + * redistributing this file, you may do so under either license.
> + *
> + * GPL LICENSE SUMMARY
> + *
> + * Copyright(c) 2016-2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License 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.
> + *
> + * Contact Information:
> + * Jarkko Sakkinen 
> + * Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> + *
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016-2017 Intel Corporation.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + *   * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + *   * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + *   * Neither the name of Intel Corporation 

[PATCH] Input: stmfts,s6sy671 - add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Update also the copyright owner adding myself as co-owner of the
copyright.

Signed-off-by: Andi Shyti 
---
 drivers/input/touchscreen/s6sy761.c | 15 +--
 drivers/input/touchscreen/stmfts.c  | 15 +--
 2 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/input/touchscreen/s6sy761.c 
b/drivers/input/touchscreen/s6sy761.c
index 26b1cb8a88ec..675efa93d444 100644
--- a/drivers/input/touchscreen/s6sy761.c
+++ b/drivers/input/touchscreen/s6sy761.c
@@ -1,13 +1,8 @@
-/*
- * Copyright (c) 2017 Samsung Electronics Co., Ltd.
- * Author: Andi Shyti 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Samsung S6SY761 Touchscreen device driver
- */
+// SPDX-License-Identifier: GPL-2.0
+// Samsung S6SY761 Touchscreen device driver
+//
+// Copyright (c) 2017 Samsung Electronics Co., Ltd.
+// Copyright (c) 2017 Andi Shyti 
 
 #include 
 #include 
diff --git a/drivers/input/touchscreen/stmfts.c 
b/drivers/input/touchscreen/stmfts.c
index c12d01899939..2a123e20a42e 100644
--- a/drivers/input/touchscreen/stmfts.c
+++ b/drivers/input/touchscreen/stmfts.c
@@ -1,13 +1,8 @@
-/*
- * Copyright (c) 2017 Samsung Electronics Co., Ltd.
- * Author: Andi Shyti 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * STMicroelectronics FTS Touchscreen device driver
- */
+// SPDX-License-Identifier: GPL-2.0
+// STMicroelectronics FTS Touchscreen device driver
+//
+// Copyright (c) 2017 Samsung Electronics Co., Ltd.
+// Copyright (c) 2017 Andi Shyti 
 
 #include 
 #include 
-- 
2.15.1

[PATCH] Input: stmfts,s6sy671 - add SPDX identifier

[Andi Shyti]

Replace the original license statement with the SPDX identifier.

Update also the copyright owner adding myself as co-owner of the
copyright.

Signed-off-by: Andi Shyti 
---
 drivers/input/touchscreen/s6sy761.c | 15 +--
 drivers/input/touchscreen/stmfts.c  | 15 +--
 2 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/input/touchscreen/s6sy761.c 
b/drivers/input/touchscreen/s6sy761.c
index 26b1cb8a88ec..675efa93d444 100644
--- a/drivers/input/touchscreen/s6sy761.c
+++ b/drivers/input/touchscreen/s6sy761.c
@@ -1,13 +1,8 @@
-/*
- * Copyright (c) 2017 Samsung Electronics Co., Ltd.
- * Author: Andi Shyti 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Samsung S6SY761 Touchscreen device driver
- */
+// SPDX-License-Identifier: GPL-2.0
+// Samsung S6SY761 Touchscreen device driver
+//
+// Copyright (c) 2017 Samsung Electronics Co., Ltd.
+// Copyright (c) 2017 Andi Shyti 
 
 #include 
 #include 
diff --git a/drivers/input/touchscreen/stmfts.c 
b/drivers/input/touchscreen/stmfts.c
index c12d01899939..2a123e20a42e 100644
--- a/drivers/input/touchscreen/stmfts.c
+++ b/drivers/input/touchscreen/stmfts.c
@@ -1,13 +1,8 @@
-/*
- * Copyright (c) 2017 Samsung Electronics Co., Ltd.
- * Author: Andi Shyti 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * STMicroelectronics FTS Touchscreen device driver
- */
+// SPDX-License-Identifier: GPL-2.0
+// STMicroelectronics FTS Touchscreen device driver
+//
+// Copyright (c) 2017 Samsung Electronics Co., Ltd.
+// Copyright (c) 2017 Andi Shyti 
 
 #include 
 #include 
-- 
2.15.1

Re: [RFT PATCH] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

[Javier Martinez Canillas]

Hello Marek,

On 12/12/2017 08:01 AM, Marek Szyprowski wrote:
> Hi
> 
> On 2017-12-11 23:48, Javier Martinez Canillas wrote:
>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>
>> Signed-off-by: Javier Martinez Canillas 
> 
> Acked-by: Marek Szyprowski 
>

Thanks.
 
>> ---
>>
>> I believe this may cause the boot issues reported on Exynos5800 Peach Pi
>> from v4.15-rc3, the mentioned commit made to v4.15-rc1 but it seems that
>> didn't cause any harm until commit ("510353a63796 drm/bridge: analogix
>> dp: Fix runtime PM state in get_modes() callback") fixed the runtime PM
>> management in the DP driver.
> 
> Thanks for analyzing this. Lack of this change was probably responsible for
> Exynos DRM initialization failure ("exynos-drm exynos-drm: failed to bind
> 1453.hdmi (ops hdmi_component_ops): -1" message and probably further
> error "unbalanced disables for lcd_vdd", which shows that failure path of
> analogix dp and simple panel causes unbalanced regulator disable.
>

Yes, I came to the same conclusion than you in the thread started by
Guillaume. I just couldn't test it.
 
> This patch should go to v4.15-rcX (fixes) if possible.
>

Indeed. I wondered if it also needed a Fixes tag. I didn't include it because
I thought that both the culprit and the fix would be in the same kernel release.

But I'll include it anyways.
 
>> I can't test right now, but I'm posting anyways as a RFT in case others
>> that have access to a Peach Pi can test it.
>>
>> Best regards,
>> Javier
>>
>>   arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index b2b95ff205e8..0029ec27819c 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -664,6 +664,10 @@
>>  status = "okay";
>>   };
>>   
>> + {
>> +status = "okay";
>> +};
>> +
>>   /* eMMC flash */
>>   _0 {
>>  status = "okay";
> 
> Best regards
> 

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [RFT PATCH] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

[Javier Martinez Canillas]

Hello Marek,

On 12/12/2017 08:01 AM, Marek Szyprowski wrote:
> Hi
> 
> On 2017-12-11 23:48, Javier Martinez Canillas wrote:
>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>
>> Signed-off-by: Javier Martinez Canillas 
> 
> Acked-by: Marek Szyprowski 
>

Thanks.
 
>> ---
>>
>> I believe this may cause the boot issues reported on Exynos5800 Peach Pi
>> from v4.15-rc3, the mentioned commit made to v4.15-rc1 but it seems that
>> didn't cause any harm until commit ("510353a63796 drm/bridge: analogix
>> dp: Fix runtime PM state in get_modes() callback") fixed the runtime PM
>> management in the DP driver.
> 
> Thanks for analyzing this. Lack of this change was probably responsible for
> Exynos DRM initialization failure ("exynos-drm exynos-drm: failed to bind
> 1453.hdmi (ops hdmi_component_ops): -1" message and probably further
> error "unbalanced disables for lcd_vdd", which shows that failure path of
> analogix dp and simple panel causes unbalanced regulator disable.
>

Yes, I came to the same conclusion than you in the thread started by
Guillaume. I just couldn't test it.
 
> This patch should go to v4.15-rcX (fixes) if possible.
>

Indeed. I wondered if it also needed a Fixes tag. I didn't include it because
I thought that both the culprit and the fix would be in the same kernel release.

But I'll include it anyways.
 
>> I can't test right now, but I'm posting anyways as a RFT in case others
>> that have access to a Peach Pi can test it.
>>
>> Best regards,
>> Javier
>>
>>   arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index b2b95ff205e8..0029ec27819c 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -664,6 +664,10 @@
>>  status = "okay";
>>   };
>>   
>> + {
>> +status = "okay";
>> +};
>> +
>>   /* eMMC flash */
>>   _0 {
>>  status = "okay";
> 
> Best regards
> 

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

[PATCHv2 11/13] irq debug: do not use print_symbol()

[Sergey Senozhatsky]

print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()

  char buffer[KSYM_SYMBOL_LEN];

  sprint_symbol(buffer, address);
  printk(fmt, buffer);

Replace print_symbol() with a direct printk("%pS") call.

Signed-off-by: Sergey Senozhatsky 
Cc: Thomas Gleixner 
---
 kernel/irq/debug.h | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/kernel/irq/debug.h b/kernel/irq/debug.h
index 17f05ef8f575..7e06dd275c17 100644
--- a/kernel/irq/debug.h
+++ b/kernel/irq/debug.h
@@ -3,8 +3,6 @@
  * Debugging printout:
  */
 
-#include 
-
 #define ___P(f) if (desc->status_use_accessors & f) printk("%14s set\n", #f)
 #define ___PS(f) if (desc->istate & f) printk("%14s set\n", #f)
 /* FIXME */
@@ -14,14 +12,14 @@ static inline void print_irq_desc(unsigned int irq, struct 
irq_desc *desc)
 {
printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n",
irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled);
-   printk("->handle_irq():  %p, ", desc->handle_irq);
-   print_symbol("%s\n", (unsigned long)desc->handle_irq);
-   printk("->irq_data.chip(): %p, ", desc->irq_data.chip);
-   print_symbol("%s\n", (unsigned long)desc->irq_data.chip);
+   printk("->handle_irq():  %p, %pS\n",
+   desc->handle_irq, desc->handle_irq);
+   printk("->irq_data.chip(): %p, %pS\n",
+   desc->irq_data.chip, desc->irq_data.chip);
printk("->action(): %p\n", desc->action);
if (desc->action) {
-   printk("->action->handler(): %p, ", desc->action->handler);
-   print_symbol("%s\n", (unsigned long)desc->action->handler);
+   printk("->action->handler(): %p, %pS\n",
+   desc->action->handler, desc->action->handler);
}
 
___P(IRQ_LEVEL);
-- 
2.15.1

[PATCHv2 11/13] irq debug: do not use print_symbol()

[Sergey Senozhatsky]

print_symbol() uses extra stack space to sprintf() symbol
information and then to feed that buffer to printk()

  char buffer[KSYM_SYMBOL_LEN];

  sprint_symbol(buffer, address);
  printk(fmt, buffer);

Replace print_symbol() with a direct printk("%pS") call.

Signed-off-by: Sergey Senozhatsky 
Cc: Thomas Gleixner 
---
 kernel/irq/debug.h | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/kernel/irq/debug.h b/kernel/irq/debug.h
index 17f05ef8f575..7e06dd275c17 100644
--- a/kernel/irq/debug.h
+++ b/kernel/irq/debug.h
@@ -3,8 +3,6 @@
  * Debugging printout:
  */
 
-#include 
-
 #define ___P(f) if (desc->status_use_accessors & f) printk("%14s set\n", #f)
 #define ___PS(f) if (desc->istate & f) printk("%14s set\n", #f)
 /* FIXME */
@@ -14,14 +12,14 @@ static inline void print_irq_desc(unsigned int irq, struct 
irq_desc *desc)
 {
printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n",
irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled);
-   printk("->handle_irq():  %p, ", desc->handle_irq);
-   print_symbol("%s\n", (unsigned long)desc->handle_irq);
-   printk("->irq_data.chip(): %p, ", desc->irq_data.chip);
-   print_symbol("%s\n", (unsigned long)desc->irq_data.chip);
+   printk("->handle_irq():  %p, %pS\n",
+   desc->handle_irq, desc->handle_irq);
+   printk("->irq_data.chip(): %p, %pS\n",
+   desc->irq_data.chip, desc->irq_data.chip);
printk("->action(): %p\n", desc->action);
if (desc->action) {
-   printk("->action->handler(): %p, ", desc->action->handler);
-   print_symbol("%s\n", (unsigned long)desc->action->handler);
+   printk("->action->handler(): %p, %pS\n",
+   desc->action->handler, desc->action->handler);
}
 
___P(IRQ_LEVEL);
-- 
2.15.1

Re: [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports

[Keerthy]

On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
> Keerthy,
> 
> On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
>> Remove all the unwanted exports from the driver
> 
> I'm adding event capture capability to the pwm-omap driver and so far used
> v4.15-rc3 as codebase.
> 
> Intended use is an IR receiver; for that I need to measure pulses width and
> spaces between pulses. So DM timer was setup to generate interupt after
> both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
> TCAR_IT_FLAG is cleared.
> 
> Of course, this is just proof of concept and needs to be polished and
> generalized, but to make it at least work I need functions you just
> unexported (plus some new).
> 
> Question is whenever we need this level of indirection (omap_dm_timer_ops)
> or plain exports are enough.

The general guidance is not to do plain exports and go via
omap_dm_timer_ops.

> 
> Thank you,
>   ladis
> 
>> Signed-off-by: Keerthy 
>> Reviewed-by: Sebastian Reichel 
>> ---
>> Changes in v3:
>>
>>   * Added Sebastian's Reviewed-by.
>>
>> Changes in v2:
>>
>>   * No code changes in this v2 version. Only enhanced patch
>> statistics for renames.
>>
>>  arch/arm/plat-omap/dmtimer.c | 27 ---
>>  1 file changed, 27 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
>> index d443e48..72565fc 100644
>> --- a/arch/arm/plat-omap/dmtimer.c
>> +++ b/arch/arm/plat-omap/dmtimer.c
>> @@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
>>  {
>>  return _omap_dm_timer_request(REQUEST_ANY, NULL);
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request);
>>  
>>  struct omap_dm_timer *omap_dm_timer_request_specific(int id)
>>  {
>> @@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int 
>> id)
>>  
>>  return _omap_dm_timer_request(REQUEST_BY_ID, );
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
>>  
>>  /**
>>   * omap_dm_timer_request_by_cap - Request a timer by capability
>> @@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 
>> cap)
>>  {
>>  return _omap_dm_timer_request(REQUEST_BY_CAP, );
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
>>  
>>  /**
>>   * omap_dm_timer_request_by_node - Request a timer by device-tree node
>> @@ -346,7 +343,6 @@ struct omap_dm_timer 
>> *omap_dm_timer_request_by_node(struct device_node *np)
>>  
>>  return _omap_dm_timer_request(REQUEST_BY_NODE, np);
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
>>  
>>  int omap_dm_timer_free(struct omap_dm_timer *timer)
>>  {
>> @@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
>>  timer->reserved = 0;
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_free);
>>  
>>  void omap_dm_timer_enable(struct omap_dm_timer *timer)
>>  {
>> @@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
>>  }
>>  }
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
>>  
>>  void omap_dm_timer_disable(struct omap_dm_timer *timer)
>>  {
>>  pm_runtime_put_sync(>pdev->dev);
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
>>  
>>  int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>>  {
>> @@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>>  return timer->irq;
>>  return -EINVAL;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
>>  
>>  #if defined(CONFIG_ARCH_OMAP1)
>>  #include 
>> @@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>>  
>>  return inputmask;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>>  
>>  #else
>>  
>> @@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
>> *timer)
>>  return timer->fclk;
>>  return NULL;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
>>  
>>  __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>>  {
>> @@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>>  
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>>  
>>  #endif
>>  
>> @@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
>>  omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
>>  
>>  int omap_dm_timer_start(struct omap_dm_timer *timer)
>>  {
>> @@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
>>  timer->context.tclr = l;
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_start);
>>  
>>  int omap_dm_timer_stop(struct omap_dm_timer *timer)
>>  {
>> @@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
>>  omap_dm_timer_disable(timer);
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
>>  
>>  int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)

Re: [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports

[Keerthy]

On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
> Keerthy,
> 
> On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
>> Remove all the unwanted exports from the driver
> 
> I'm adding event capture capability to the pwm-omap driver and so far used
> v4.15-rc3 as codebase.
> 
> Intended use is an IR receiver; for that I need to measure pulses width and
> spaces between pulses. So DM timer was setup to generate interupt after
> both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
> TCAR_IT_FLAG is cleared.
> 
> Of course, this is just proof of concept and needs to be polished and
> generalized, but to make it at least work I need functions you just
> unexported (plus some new).
> 
> Question is whenever we need this level of indirection (omap_dm_timer_ops)
> or plain exports are enough.

The general guidance is not to do plain exports and go via
omap_dm_timer_ops.

> 
> Thank you,
>   ladis
> 
>> Signed-off-by: Keerthy 
>> Reviewed-by: Sebastian Reichel 
>> ---
>> Changes in v3:
>>
>>   * Added Sebastian's Reviewed-by.
>>
>> Changes in v2:
>>
>>   * No code changes in this v2 version. Only enhanced patch
>> statistics for renames.
>>
>>  arch/arm/plat-omap/dmtimer.c | 27 ---
>>  1 file changed, 27 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
>> index d443e48..72565fc 100644
>> --- a/arch/arm/plat-omap/dmtimer.c
>> +++ b/arch/arm/plat-omap/dmtimer.c
>> @@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
>>  {
>>  return _omap_dm_timer_request(REQUEST_ANY, NULL);
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request);
>>  
>>  struct omap_dm_timer *omap_dm_timer_request_specific(int id)
>>  {
>> @@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int 
>> id)
>>  
>>  return _omap_dm_timer_request(REQUEST_BY_ID, );
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
>>  
>>  /**
>>   * omap_dm_timer_request_by_cap - Request a timer by capability
>> @@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 
>> cap)
>>  {
>>  return _omap_dm_timer_request(REQUEST_BY_CAP, );
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
>>  
>>  /**
>>   * omap_dm_timer_request_by_node - Request a timer by device-tree node
>> @@ -346,7 +343,6 @@ struct omap_dm_timer 
>> *omap_dm_timer_request_by_node(struct device_node *np)
>>  
>>  return _omap_dm_timer_request(REQUEST_BY_NODE, np);
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
>>  
>>  int omap_dm_timer_free(struct omap_dm_timer *timer)
>>  {
>> @@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
>>  timer->reserved = 0;
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_free);
>>  
>>  void omap_dm_timer_enable(struct omap_dm_timer *timer)
>>  {
>> @@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
>>  }
>>  }
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
>>  
>>  void omap_dm_timer_disable(struct omap_dm_timer *timer)
>>  {
>>  pm_runtime_put_sync(>pdev->dev);
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
>>  
>>  int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>>  {
>> @@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>>  return timer->irq;
>>  return -EINVAL;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
>>  
>>  #if defined(CONFIG_ARCH_OMAP1)
>>  #include 
>> @@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>>  
>>  return inputmask;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>>  
>>  #else
>>  
>> @@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
>> *timer)
>>  return timer->fclk;
>>  return NULL;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
>>  
>>  __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>>  {
>> @@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>>  
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>>  
>>  #endif
>>  
>> @@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
>>  omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
>>  
>>  int omap_dm_timer_start(struct omap_dm_timer *timer)
>>  {
>> @@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
>>  timer->context.tclr = l;
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_start);
>>  
>>  int omap_dm_timer_stop(struct omap_dm_timer *timer)
>>  {
>> @@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
>>  omap_dm_timer_disable(timer);
>>  return 0;
>>  }
>> -EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
>>  
>>  int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
>>  {
>> @@ -569,7 +555,6 @@ int 

[BUG] drivers/spi: a possible sleep-in-atomic bug in atmel_spi_remove

[Jia-Ju Bai]

According to drivers/spi/spi-atmel.c, the kernel module may sleep under 
a spinlock.

The function call path is:
atmel_spi_remove (acquire the spinlock)
  atmel_spi_release_dma
dma_release_channel
  mutex_lock --> may sleep

I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked 
by my code review.



Thanks,
Jia-Ju Bai

[BUG] drivers/spi: a possible sleep-in-atomic bug in atmel_spi_remove

[Jia-Ju Bai]

According to drivers/spi/spi-atmel.c, the kernel module may sleep under 
a spinlock.

The function call path is:
atmel_spi_remove (acquire the spinlock)
  atmel_spi_release_dma
dma_release_channel
  mutex_lock --> may sleep

I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked 
by my code review.



Thanks,
Jia-Ju Bai

[PATCH v1] DMA:omap-dma:Avoid build error by changing the function name

[venkat . prashanth2498]

From: Venkat Prashanth B U 

Change the name of the function omap_dma_filter_fn to avoid
the following build error in linux kernel version 4.4 :

drivers/dma/dma-omap.c:1273:6: error:
redefinition of 'omap_dma_filter_fn'

Signed-off-by: Venkat Prashanth B U 
Changes for v1:
- Edited subject and description of the patch to fit with the change
  done in the code base, as suggested by Vinod Koul.

- In order to avoid  issues like backporting on stable the
  checkpatch.pl issues are dropped as suggested by Vinod Koul.
---
 drivers/dma/omap-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 1dfc71c..8545dda 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1269,7 +1269,7 @@ static struct platform_driver omap_dma_driver = {
},
 };
 
-bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
+bool omap_dma_filter_func(struct dma_chan *chan, void *param)
 {
if (chan->device->dev->driver == _dma_driver.driver) {
struct omap_dmadev *od = to_omap_dma_dev(chan->device);
-- 
1.9.1

[PATCH v1] DMA:omap-dma:Avoid build error by changing the function name

[venkat . prashanth2498]

From: Venkat Prashanth B U 

Change the name of the function omap_dma_filter_fn to avoid
the following build error in linux kernel version 4.4 :

drivers/dma/dma-omap.c:1273:6: error:
redefinition of 'omap_dma_filter_fn'

Signed-off-by: Venkat Prashanth B U 
Changes for v1:
- Edited subject and description of the patch to fit with the change
  done in the code base, as suggested by Vinod Koul.

- In order to avoid  issues like backporting on stable the
  checkpatch.pl issues are dropped as suggested by Vinod Koul.
---
 drivers/dma/omap-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 1dfc71c..8545dda 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1269,7 +1269,7 @@ static struct platform_driver omap_dma_driver = {
},
 };
 
-bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
+bool omap_dma_filter_func(struct dma_chan *chan, void *param)
 {
if (chan->device->dev->driver == _dma_driver.driver) {
struct omap_dmadev *od = to_omap_dma_dev(chan->device);
-- 
1.9.1

Re: [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes

[Viresh Kumar]

On 12-12-17, 02:17, Rafael J. Wysocki wrote:
> On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
> > On 08-12-17, 14:07, Andrew-sh Cheng wrote:
> > > Add opp v2 information,
> > > and also add clocks, regulators and opp information into cpu nodes
> > > 
> > > Signed-off-by: Andrew-sh Cheng 
> > > ---
> > >  arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++
> > >  arch/arm64/boot/dts/mediatek/mt2712e.dtsi   | 57 
> > > +
> > >  2 files changed, 84 insertions(+)
> > 
> > Acked-by: Viresh Kumar 
> 
> Of course, DT bindings require ACKs from DT maintainers to be applied.

I didn't knew that we need Acks from DT maintainers for dts files as well? Yeah,
its very much required while defining new bindings for sure.

-- 
viresh

Re: [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes

[Viresh Kumar]

On 12-12-17, 02:17, Rafael J. Wysocki wrote:
> On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
> > On 08-12-17, 14:07, Andrew-sh Cheng wrote:
> > > Add opp v2 information,
> > > and also add clocks, regulators and opp information into cpu nodes
> > > 
> > > Signed-off-by: Andrew-sh Cheng 
> > > ---
> > >  arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++
> > >  arch/arm64/boot/dts/mediatek/mt2712e.dtsi   | 57 
> > > +
> > >  2 files changed, 84 insertions(+)
> > 
> > Acked-by: Viresh Kumar 
> 
> Of course, DT bindings require ACKs from DT maintainers to be applied.

I didn't knew that we need Acks from DT maintainers for dts files as well? Yeah,
its very much required while defining new bindings for sure.

-- 
viresh

Re: [PATCH 4.4 20/49] usbip: tools: Install all headers needed for libusbip development

[Greg Kroah-Hartman]

On Tue, Dec 12, 2017 at 12:13:59AM +, alexander.le...@verizon.com wrote:
> On Sat, Dec 09, 2017 at 08:41:54AM +0100, Greg Kroah-Hartman wrote:
> >On Sat, Dec 09, 2017 at 06:16:04AM +, alexander.le...@verizon.com wrote:
> >> On Fri, Dec 08, 2017 at 03:56:40AM +, Ben Hutchings wrote:
> >> >On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> >> >> 4.4-stable review patch.  If anyone has any objections, please let me 
> >> >> know.
> >> >>
> >> >> --
> >> >>
> >> >> From: Ben Hutchings 
> >> >>
> >> >>
> >> >> [ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
> >> >>
> >> >> usbip_host_driver.h now depends on several additional headers, which
> >> >> need to be installed along with it.
> >> >>
> >> >> Fixes: 021aed845303 ("staging: usbip: userspace: migrate 
> >> >> usbip_host_driver ...")
> >> >> Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared 
> >> >> with ...")
> >> >> Signed-off-by: Ben Hutchings 
> >> >> Acked-by: Shuah Khan 
> >> >> Signed-off-by: Greg Kroah-Hartman 
> >> >> Signed-off-by: Sasha Levin 
> >> >> Signed-off-by: Greg Kroah-Hartman 
> >> >> ---
> >> >>  tools/usb/usbip/Makefile.am |3 ++-
> >> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >>
> >> >> --- a/tools/usb/usbip/Makefile.am
> >> >> +++ b/tools/usb/usbip/Makefile.am
> >> >> @@ -1,6 +1,7 @@
> >> >>  SUBDIRS := libsrc src
> >> >>  includedir = @includedir@/usbip
> >> >>  include_HEADERS := $(addprefix libsrc/, \
> >> >> -    usbip_common.h vhci_driver.h usbip_host_driver.h)
> >> >> +    usbip_common.h vhci_driver.h usbip_host_driver.h \
> >> >> +    list.h sysfs_utils.h usbip_host_common.h)
> >> >
> >> >usbip_host_common.h was added in 4.7 (by the second commit listed
> >> >above), so for 4.4 and 3.18 it should not be added to this list.
> >>
> >> Thanks Ben!
> >>
> >> Greg, I'm not sure how to send you fixes for patches currently in your
> >> -rc cycle, since ideally you would just remove them instead of
> >> reverting. Any ideas?
> >
> >Yes, I can just drop them from the queue.  I'll go through all of these
> >later this evening when I get back to the keyboard...
> 
> If you regenerate trees based on the queue, can I send you patches for
> your stable-queue to remove commits after you've pulled from me but
> before you release it?

You can, but no one has ever done that before, could be an interesting
thing to attempt :)

greg k-h

Re: [PATCH 4.4 20/49] usbip: tools: Install all headers needed for libusbip development

[Greg Kroah-Hartman]

On Tue, Dec 12, 2017 at 12:13:59AM +, alexander.le...@verizon.com wrote:
> On Sat, Dec 09, 2017 at 08:41:54AM +0100, Greg Kroah-Hartman wrote:
> >On Sat, Dec 09, 2017 at 06:16:04AM +, alexander.le...@verizon.com wrote:
> >> On Fri, Dec 08, 2017 at 03:56:40AM +, Ben Hutchings wrote:
> >> >On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> >> >> 4.4-stable review patch.  If anyone has any objections, please let me 
> >> >> know.
> >> >>
> >> >> --
> >> >>
> >> >> From: Ben Hutchings 
> >> >>
> >> >>
> >> >> [ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
> >> >>
> >> >> usbip_host_driver.h now depends on several additional headers, which
> >> >> need to be installed along with it.
> >> >>
> >> >> Fixes: 021aed845303 ("staging: usbip: userspace: migrate 
> >> >> usbip_host_driver ...")
> >> >> Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared 
> >> >> with ...")
> >> >> Signed-off-by: Ben Hutchings 
> >> >> Acked-by: Shuah Khan 
> >> >> Signed-off-by: Greg Kroah-Hartman 
> >> >> Signed-off-by: Sasha Levin 
> >> >> Signed-off-by: Greg Kroah-Hartman 
> >> >> ---
> >> >>  tools/usb/usbip/Makefile.am |3 ++-
> >> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >>
> >> >> --- a/tools/usb/usbip/Makefile.am
> >> >> +++ b/tools/usb/usbip/Makefile.am
> >> >> @@ -1,6 +1,7 @@
> >> >>  SUBDIRS := libsrc src
> >> >>  includedir = @includedir@/usbip
> >> >>  include_HEADERS := $(addprefix libsrc/, \
> >> >> -    usbip_common.h vhci_driver.h usbip_host_driver.h)
> >> >> +    usbip_common.h vhci_driver.h usbip_host_driver.h \
> >> >> +    list.h sysfs_utils.h usbip_host_common.h)
> >> >
> >> >usbip_host_common.h was added in 4.7 (by the second commit listed
> >> >above), so for 4.4 and 3.18 it should not be added to this list.
> >>
> >> Thanks Ben!
> >>
> >> Greg, I'm not sure how to send you fixes for patches currently in your
> >> -rc cycle, since ideally you would just remove them instead of
> >> reverting. Any ideas?
> >
> >Yes, I can just drop them from the queue.  I'll go through all of these
> >later this evening when I get back to the keyboard...
> 
> If you regenerate trees based on the queue, can I send you patches for
> your stable-queue to remove commits after you've pulled from me but
> before you release it?

You can, but no one has ever done that before, could be an interesting
thing to attempt :)

greg k-h

Re: [PATCH 0/8] make some functions return bool

[Yaowei Bai]

On Mon, Dec 11, 2017 at 09:50:03PM -0800, David Rientjes wrote:
> On Mon, 11 Dec 2017, Yaowei Bai wrote:
> 
> > This patchset makes some *_is_* like functions return bool because
> > these functions only use true or false as their return values.
> > 
> > No functional changes.
> > 
> 
> I think the concern about this type of patchset in the past is that it is 
> unnecessary churn and makes it more time consuming to research git history 
> without any significant improvement.

While, relative to a modern computer with superb computional power, i
think the additional time to search git history is negligable and this
type of patchset is also a good practice for the kernel beginner guys.
:)

Re: [PATCH 0/8] make some functions return bool

[Yaowei Bai]

On Mon, Dec 11, 2017 at 09:50:03PM -0800, David Rientjes wrote:
> On Mon, 11 Dec 2017, Yaowei Bai wrote:
> 
> > This patchset makes some *_is_* like functions return bool because
> > these functions only use true or false as their return values.
> > 
> > No functional changes.
> > 
> 
> I think the concern about this type of patchset in the past is that it is 
> unnecessary churn and makes it more time consuming to research git history 
> without any significant improvement.

While, relative to a modern computer with superb computional power, i
think the additional time to search git history is negligable and this
type of patchset is also a good practice for the kernel beginner guys.
:)

Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag

[Sean Wang]

On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> >  {
> > struct dsa_port *dp = dsa_slave_to_port(dev);
> > u8 *mtk_tag;
> > +   bool is_vlan_skb = true;
> 
> ..
> 
> > +   /* Mark tag attribute on special tag insertion to notify hardware
> > +* whether that's a combined special tag with 802.1Q header.
> > +*/
> > +   mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > +MTK_HDR_XMIT_UNTAGGED;
> > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > -   mtk_tag[2] = 0;
> > -   mtk_tag[3] = 0;
> > +
> > +   /* Tag control information is kept for 802.1Q */
> > +   if (!is_vlan_skb) {
> > +   mtk_tag[2] = 0;
> > +   mtk_tag[3] = 0;
> > +   }
> >  
> > return skb;
> >  }
> 
> Hi Sean
> 
> So you can mark a packet for egress. What about ingress? How do you
> know the VLAN/PORT combination for packets the CPU receives? I would
> of expected a similar change to mtk_tag_rcv().
> 
>Andrew

Hi, Andrew

It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
present since it is able to put the VLAN tag after the special tag and
then follow the existing way to parse.

Sean

Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag

[Sean Wang]

On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> >  {
> > struct dsa_port *dp = dsa_slave_to_port(dev);
> > u8 *mtk_tag;
> > +   bool is_vlan_skb = true;
> 
> ..
> 
> > +   /* Mark tag attribute on special tag insertion to notify hardware
> > +* whether that's a combined special tag with 802.1Q header.
> > +*/
> > +   mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > +MTK_HDR_XMIT_UNTAGGED;
> > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > -   mtk_tag[2] = 0;
> > -   mtk_tag[3] = 0;
> > +
> > +   /* Tag control information is kept for 802.1Q */
> > +   if (!is_vlan_skb) {
> > +   mtk_tag[2] = 0;
> > +   mtk_tag[3] = 0;
> > +   }
> >  
> > return skb;
> >  }
> 
> Hi Sean
> 
> So you can mark a packet for egress. What about ingress? How do you
> know the VLAN/PORT combination for packets the CPU receives? I would
> of expected a similar change to mtk_tag_rcv().
> 
>Andrew

Hi, Andrew

It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
present since it is able to put the VLAN tag after the special tag and
then follow the existing way to parse.

Sean

Re: [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports

[Ladislav Michl]

Keerthy,

On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
> Remove all the unwanted exports from the driver

I'm adding event capture capability to the pwm-omap driver and so far used
v4.15-rc3 as codebase.

Intended use is an IR receiver; for that I need to measure pulses width and
spaces between pulses. So DM timer was setup to generate interupt after
both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
TCAR_IT_FLAG is cleared.

Of course, this is just proof of concept and needs to be polished and
generalized, but to make it at least work I need functions you just
unexported (plus some new).

Question is whenever we need this level of indirection (omap_dm_timer_ops)
or plain exports are enough.

Thank you,
ladis

> Signed-off-by: Keerthy 
> Reviewed-by: Sebastian Reichel 
> ---
> Changes in v3:
> 
>   * Added Sebastian's Reviewed-by.
> 
> Changes in v2:
> 
>   * No code changes in this v2 version. Only enhanced patch
> statistics for renames.
> 
>  arch/arm/plat-omap/dmtimer.c | 27 ---
>  1 file changed, 27 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index d443e48..72565fc 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
>  {
>   return _omap_dm_timer_request(REQUEST_ANY, NULL);
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request);
>  
>  struct omap_dm_timer *omap_dm_timer_request_specific(int id)
>  {
> @@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int 
> id)
>  
>   return _omap_dm_timer_request(REQUEST_BY_ID, );
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
>  
>  /**
>   * omap_dm_timer_request_by_cap - Request a timer by capability
> @@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 
> cap)
>  {
>   return _omap_dm_timer_request(REQUEST_BY_CAP, );
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
>  
>  /**
>   * omap_dm_timer_request_by_node - Request a timer by device-tree node
> @@ -346,7 +343,6 @@ struct omap_dm_timer 
> *omap_dm_timer_request_by_node(struct device_node *np)
>  
>   return _omap_dm_timer_request(REQUEST_BY_NODE, np);
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
>  
>  int omap_dm_timer_free(struct omap_dm_timer *timer)
>  {
> @@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
>   timer->reserved = 0;
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_free);
>  
>  void omap_dm_timer_enable(struct omap_dm_timer *timer)
>  {
> @@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
>   }
>   }
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
>  
>  void omap_dm_timer_disable(struct omap_dm_timer *timer)
>  {
>   pm_runtime_put_sync(>pdev->dev);
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
>  
>  int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>  {
> @@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>   return timer->irq;
>   return -EINVAL;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
>  
>  #if defined(CONFIG_ARCH_OMAP1)
>  #include 
> @@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>  
>   return inputmask;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>  
>  #else
>  
> @@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
> *timer)
>   return timer->fclk;
>   return NULL;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
>  
>  __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>  {
> @@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>  
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>  
>  #endif
>  
> @@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
>   omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
>  
>  int omap_dm_timer_start(struct omap_dm_timer *timer)
>  {
> @@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
>   timer->context.tclr = l;
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_start);
>  
>  int omap_dm_timer_stop(struct omap_dm_timer *timer)
>  {
> @@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
>   omap_dm_timer_disable(timer);
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
>  
>  int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
>  {
> @@ -569,7 +555,6 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
> int source)
>  
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
>  
>  int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
>   unsigned 

Re: [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports

[Ladislav Michl]

Keerthy,

On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
> Remove all the unwanted exports from the driver

I'm adding event capture capability to the pwm-omap driver and so far used
v4.15-rc3 as codebase.

Intended use is an IR receiver; for that I need to measure pulses width and
spaces between pulses. So DM timer was setup to generate interupt after
both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
TCAR_IT_FLAG is cleared.

Of course, this is just proof of concept and needs to be polished and
generalized, but to make it at least work I need functions you just
unexported (plus some new).

Question is whenever we need this level of indirection (omap_dm_timer_ops)
or plain exports are enough.

Thank you,
ladis

> Signed-off-by: Keerthy 
> Reviewed-by: Sebastian Reichel 
> ---
> Changes in v3:
> 
>   * Added Sebastian's Reviewed-by.
> 
> Changes in v2:
> 
>   * No code changes in this v2 version. Only enhanced patch
> statistics for renames.
> 
>  arch/arm/plat-omap/dmtimer.c | 27 ---
>  1 file changed, 27 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index d443e48..72565fc 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
>  {
>   return _omap_dm_timer_request(REQUEST_ANY, NULL);
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request);
>  
>  struct omap_dm_timer *omap_dm_timer_request_specific(int id)
>  {
> @@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int 
> id)
>  
>   return _omap_dm_timer_request(REQUEST_BY_ID, );
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
>  
>  /**
>   * omap_dm_timer_request_by_cap - Request a timer by capability
> @@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 
> cap)
>  {
>   return _omap_dm_timer_request(REQUEST_BY_CAP, );
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
>  
>  /**
>   * omap_dm_timer_request_by_node - Request a timer by device-tree node
> @@ -346,7 +343,6 @@ struct omap_dm_timer 
> *omap_dm_timer_request_by_node(struct device_node *np)
>  
>   return _omap_dm_timer_request(REQUEST_BY_NODE, np);
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
>  
>  int omap_dm_timer_free(struct omap_dm_timer *timer)
>  {
> @@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
>   timer->reserved = 0;
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_free);
>  
>  void omap_dm_timer_enable(struct omap_dm_timer *timer)
>  {
> @@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
>   }
>   }
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
>  
>  void omap_dm_timer_disable(struct omap_dm_timer *timer)
>  {
>   pm_runtime_put_sync(>pdev->dev);
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
>  
>  int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>  {
> @@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
>   return timer->irq;
>   return -EINVAL;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
>  
>  #if defined(CONFIG_ARCH_OMAP1)
>  #include 
> @@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>  
>   return inputmask;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>  
>  #else
>  
> @@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
> *timer)
>   return timer->fclk;
>   return NULL;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
>  
>  __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>  {
> @@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>  
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
>  
>  #endif
>  
> @@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
>   omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
>  
>  int omap_dm_timer_start(struct omap_dm_timer *timer)
>  {
> @@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
>   timer->context.tclr = l;
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_start);
>  
>  int omap_dm_timer_stop(struct omap_dm_timer *timer)
>  {
> @@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
>   omap_dm_timer_disable(timer);
>   return 0;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
>  
>  int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
>  {
> @@ -569,7 +555,6 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
> int source)
>  
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
>  
>  int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
>   unsigned int load)
> @@ -595,7 +580,6 @@ int 

Re: [PATCH] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS optional

[Byungchul Park]

+cc da...@fromorbit.com
+cc ty...@mit.edu
+cc wi...@infradead.org
+cc torva...@linux-foundation.org
+cc amir7...@gmail.com

On 12/12/2017 4:11 PM, Byungchul Park wrote:

At the moment, it's rather premature to enable
CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS by default,
because we face a lot of false positives for now since all locks and
waiters are not classified properly yet.

Until most of them get annotated properly, it'd be better to be optional.

Signed-off-by: Byungchul Park 
---
  lib/Kconfig.debug | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2689b7c..bc099f1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1092,8 +1092,6 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
-   select LOCKDEP_CROSSRELEASE
-   select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help
@@ -1164,7 +1162,9 @@ config LOCK_STAT
 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
  
  config LOCKDEP_CROSSRELEASE

-   bool
+   bool "Lock debugging: enable cross-locking checks in lockdep"
+   depends on PROVE_LOCKING
+   default n
help
 This makes lockdep work for crosslock which is a lock allowed to
 be released in a different context from the acquisition context.
@@ -1174,7 +1174,10 @@ config LOCKDEP_CROSSRELEASE
 detector, lockdep.
  
  config LOCKDEP_COMPLETIONS

-   bool
+   bool "Lock debugging: allow completions to use deadlock detector"
+   depends on PROVE_LOCKING
+   select LOCKDEP_CROSSRELEASE
+   default n
help
 A deadlock caused by wait_for_completion() and complete() can be
 detected by lockdep using crossrelease feature.



--
Thanks,
Byungchul

Re: [PATCH] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS optional

[Byungchul Park]

+cc da...@fromorbit.com
+cc ty...@mit.edu
+cc wi...@infradead.org
+cc torva...@linux-foundation.org
+cc amir7...@gmail.com

On 12/12/2017 4:11 PM, Byungchul Park wrote:

At the moment, it's rather premature to enable
CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS by default,
because we face a lot of false positives for now since all locks and
waiters are not classified properly yet.

Until most of them get annotated properly, it'd be better to be optional.

Signed-off-by: Byungchul Park 
---
  lib/Kconfig.debug | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2689b7c..bc099f1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1092,8 +1092,6 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
-   select LOCKDEP_CROSSRELEASE
-   select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help
@@ -1164,7 +1162,9 @@ config LOCK_STAT
 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
  
  config LOCKDEP_CROSSRELEASE

-   bool
+   bool "Lock debugging: enable cross-locking checks in lockdep"
+   depends on PROVE_LOCKING
+   default n
help
 This makes lockdep work for crosslock which is a lock allowed to
 be released in a different context from the acquisition context.
@@ -1174,7 +1174,10 @@ config LOCKDEP_CROSSRELEASE
 detector, lockdep.
  
  config LOCKDEP_COMPLETIONS

-   bool
+   bool "Lock debugging: allow completions to use deadlock detector"
+   depends on PROVE_LOCKING
+   select LOCKDEP_CROSSRELEASE
+   default n
help
 A deadlock caused by wait_for_completion() and complete() can be
 detected by lockdep using crossrelease feature.



--
Thanks,
Byungchul

[PATCH] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS optional

[Byungchul Park]

At the moment, it's rather premature to enable
CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS by default,
because we face a lot of false positives for now since all locks and
waiters are not classified properly yet.

Until most of them get annotated properly, it'd be better to be optional.

Signed-off-by: Byungchul Park 
---
 lib/Kconfig.debug | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2689b7c..bc099f1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1092,8 +1092,6 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
-   select LOCKDEP_CROSSRELEASE
-   select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help
@@ -1164,7 +1162,9 @@ config LOCK_STAT
 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
 
 config LOCKDEP_CROSSRELEASE
-   bool
+   bool "Lock debugging: enable cross-locking checks in lockdep"
+   depends on PROVE_LOCKING
+   default n
help
 This makes lockdep work for crosslock which is a lock allowed to
 be released in a different context from the acquisition context.
@@ -1174,7 +1174,10 @@ config LOCKDEP_CROSSRELEASE
 detector, lockdep.
 
 config LOCKDEP_COMPLETIONS
-   bool
+   bool "Lock debugging: allow completions to use deadlock detector"
+   depends on PROVE_LOCKING
+   select LOCKDEP_CROSSRELEASE
+   default n
help
 A deadlock caused by wait_for_completion() and complete() can be
 detected by lockdep using crossrelease feature.
-- 
1.9.1

[PATCH] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS optional

[Byungchul Park]

At the moment, it's rather premature to enable
CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS by default,
because we face a lot of false positives for now since all locks and
waiters are not classified properly yet.

Until most of them get annotated properly, it'd be better to be optional.

Signed-off-by: Byungchul Park 
---
 lib/Kconfig.debug | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2689b7c..bc099f1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1092,8 +1092,6 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
-   select LOCKDEP_CROSSRELEASE
-   select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help
@@ -1164,7 +1162,9 @@ config LOCK_STAT
 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
 
 config LOCKDEP_CROSSRELEASE
-   bool
+   bool "Lock debugging: enable cross-locking checks in lockdep"
+   depends on PROVE_LOCKING
+   default n
help
 This makes lockdep work for crosslock which is a lock allowed to
 be released in a different context from the acquisition context.
@@ -1174,7 +1174,10 @@ config LOCKDEP_CROSSRELEASE
 detector, lockdep.
 
 config LOCKDEP_COMPLETIONS
-   bool
+   bool "Lock debugging: allow completions to use deadlock detector"
+   depends on PROVE_LOCKING
+   select LOCKDEP_CROSSRELEASE
+   default n
help
 A deadlock caused by wait_for_completion() and complete() can be
 detected by lockdep using crossrelease feature.
-- 
1.9.1

RE: [PATCH v2] usb: host: Implement workaround for Erratum A-009611

[Yinbo Zhu]

-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com] 
Sent: Monday, December 11, 2017 4:52 PM
To: Yinbo Zhu ; Greg Kroah-Hartman 

Cc: Mathias Nyman ; open list:DESIGNWARE USB3 DRD IP 
DRIVER ; open list:DESIGNWARE USB3 DRD IP DRIVER 
; open list ; Xiaobo 
Xie ; Jerry Huang ; Ran Wang 

Subject: RE: [PATCH v2] usb: host: Implement workaround for Erratum A-009611


>>Hi,

>>(please break your lines at 80-characters)

>>Yinbo Zhu  writes:
I had check it. Every line is less than 80-characters.
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 
>>> 5cb3f6795b0b..071e7cea8cbb 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -1106,6 +1106,9 @@ static void dwc3_get_properties(struct dwc3
>>> *dwc)
>>>  
>>> dwc->quirk_reverse_in_out = device_property_read_bool(dev,
>>> "snps,quirk_reverse_in_out");
>
>>This was generated on vendor tree. This quirk doesn't exist in dwc3. 
>>Also,
>  >update your tree and review MAINTAINERS file. It has been almost 2 
> years since I left TI :-)
>
>>--
>>Balbi
>
> Hi Balbi,
>
> The quirk that I had add it in dwc3. Your meaning is that I can't use 
> quirk to enable or disable the erratum, isn't it? The tree is 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git, I had 
> updated it.

>-*- mode: grep; default-directory: "~/workspace/linux/" -*- Grep started at 
>Mon Dec 11 10:50:47

>git --no-pager grep --color -nH -e quirk_reverse_in_out

>Grep finished with no matches found at Mon Dec 11 10:50:48

>--
>balbi
Hi Balbi,

You can't find the quirk that it is normal. There's no one in the previous code.
 The quirk that I added to control the new erratum 
Please you note.

Thanks.
Yinbo.

RE: [PATCH v2] usb: host: Implement workaround for Erratum A-009611

[Yinbo Zhu]

-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com] 
Sent: Monday, December 11, 2017 4:52 PM
To: Yinbo Zhu ; Greg Kroah-Hartman 

Cc: Mathias Nyman ; open list:DESIGNWARE USB3 DRD IP 
DRIVER ; open list:DESIGNWARE USB3 DRD IP DRIVER 
; open list ; Xiaobo 
Xie ; Jerry Huang ; Ran Wang 

Subject: RE: [PATCH v2] usb: host: Implement workaround for Erratum A-009611


>>Hi,

>>(please break your lines at 80-characters)

>>Yinbo Zhu  writes:
I had check it. Every line is less than 80-characters.
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 
>>> 5cb3f6795b0b..071e7cea8cbb 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -1106,6 +1106,9 @@ static void dwc3_get_properties(struct dwc3
>>> *dwc)
>>>  
>>> dwc->quirk_reverse_in_out = device_property_read_bool(dev,
>>> "snps,quirk_reverse_in_out");
>
>>This was generated on vendor tree. This quirk doesn't exist in dwc3. 
>>Also,
>  >update your tree and review MAINTAINERS file. It has been almost 2 
> years since I left TI :-)
>
>>--
>>Balbi
>
> Hi Balbi,
>
> The quirk that I had add it in dwc3. Your meaning is that I can't use 
> quirk to enable or disable the erratum, isn't it? The tree is 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git, I had 
> updated it.

>-*- mode: grep; default-directory: "~/workspace/linux/" -*- Grep started at 
>Mon Dec 11 10:50:47

>git --no-pager grep --color -nH -e quirk_reverse_in_out

>Grep finished with no matches found at Mon Dec 11 10:50:48

>--
>balbi
Hi Balbi,

You can't find the quirk that it is normal. There's no one in the previous code.
 The quirk that I added to control the new erratum 
Please you note.

Thanks.
Yinbo.

Re: [PATCH v2] riscv/ftrace: Add basic support

[Alan Kao]

On Mon, Dec 11, 2017 at 10:15:58AM -0800, Palmer Dabbelt wrote:
> On Wed, 06 Dec 2017 18:31:10 PST (-0800), noner...@gmail.com wrote:
> > This patch contains basic ftrace support for RV64I platform.
> > Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
> > tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
> > (HAVE_FUNCTION_GRAPH_FP_TEST) are implemented following the
> > instructions in Documentation/trace/ftrace-design.txt.
> > 
> > Note that the functions in both ftrace.c and setup.c should not be
> > hooked with the compiler's -pg option: to prevent infinite self-
> > referencing for the former, and to ignore early setup stuff for the
> > latter.
> > 
> > Signed-off-by: Alan Kao 
> > ---
> > Changes in v2:
> >   - Add SPDX license identifier
> >   - Remove unnecessary LOCKDEP_SUPPORT option
> >   - Remove unnecessary #ifdef in the newly added kernel/ftrace.c
> > 
> >  arch/riscv/Kconfig  |   5 ++
> >  arch/riscv/include/asm/Kbuild   |   1 -
> >  arch/riscv/include/asm/ftrace.h |  10 
> >  arch/riscv/kernel/Makefile  |   7 +++
> >  arch/riscv/kernel/ftrace.c  |  41 +
> >  arch/riscv/kernel/mcount.S  | 126 
> > 
> >  6 files changed, 189 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/riscv/include/asm/ftrace.h
> >  create mode 100644 arch/riscv/kernel/ftrace.c
> >  create mode 100644 arch/riscv/kernel/mcount.S
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 2e15e85c8f7e..40a67fc12328 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -60,6 +60,9 @@ config PAGE_OFFSET
> >  config STACKTRACE_SUPPORT
> > def_bool y
> > 
> > +config TRACE_IRQFLAGS_SUPPORT
> > +   def_bool y
> > +
> >  config RWSEM_GENERIC_SPINLOCK
> > def_bool y
> > 
> > @@ -112,6 +115,8 @@ config ARCH_RV64I
> > bool "RV64I"
> > select CPU_SUPPORTS_64BIT_KERNEL
> > select 64BIT
> > +   select HAVE_FUNCTION_TRACER
> > +   select HAVE_FUNCTION_GRAPH_TRACER
> > 
> >  endchoice
> > 
> > diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> > index 18158be62a2b..680301bfbc4b 100644
> > --- a/arch/riscv/include/asm/Kbuild
> > +++ b/arch/riscv/include/asm/Kbuild
> > @@ -12,7 +12,6 @@ generic-y += errno.h
> >  generic-y += exec.h
> >  generic-y += fb.h
> >  generic-y += fcntl.h
> > -generic-y += ftrace.h
> >  generic-y += futex.h
> >  generic-y += hardirq.h
> >  generic-y += hash.h
> > diff --git a/arch/riscv/include/asm/ftrace.h 
> > b/arch/riscv/include/asm/ftrace.h
> > new file mode 100644
> > index ..66d4175eb13e
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/ftrace.h
> > @@ -0,0 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (C) 2017 Andes Technology Corporation */
> > +
> > +/*
> > + * The graph frame test is not possible if CONFIG_FRAME_POINTER is not 
> > enabled.
> > + * Check arch/riscv/kernel/mcount.S for detail.
> > + */
> > +#if defined(CONFIG_FUNCTION_GRAPH_TRACER) && defined(CONFIG_FRAME_POINTER)
> > +#define HAVE_FUNCTION_GRAPH_FP_TEST
> > +#endif
> > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > index ab8baf7bd142..15941f3b8363 100644
> > --- a/arch/riscv/kernel/Makefile
> > +++ b/arch/riscv/kernel/Makefile
> > @@ -2,6 +2,11 @@
> >  # Makefile for the RISC-V Linux kernel
> >  #
> > 
> > +#ifdef CONFIG_FTRACE
> > +CFLAGS_REMOVE_ftrace.o = -pg
> > +CFLAGS_REMOVE_setup.o = -pg
> > +#endif
> > +
> 
> You want ifeq, not #ifdef, in Makefiles.
>

Thanks for pointing out this. It will be fixed in v3.

> Also: I thought we were only unable to trace setup_vm()?  Either way, I
> don't think it's a big deal to avoid tracing anything in setup.c: the stuff
> in here is called once pet hart before userspace is set up, so I doubt
> anyone is going to want to trace it anyway.
>

Sure. setup_vm() is the only trouble that causes panic.

> >  extra-y += head.o
> >  extra-y += vmlinux.lds
> > 
> > @@ -29,5 +34,7 @@ CFLAGS_setup.o := -mcmodel=medany
> >  obj-$(CONFIG_SMP)  += smpboot.o
> >  obj-$(CONFIG_SMP)  += smp.o
> >  obj-$(CONFIG_MODULES)  += module.o
> > +obj-$(CONFIG_FUNCTION_TRACER)  += mcount.o
> > +obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ftrace.o
> > 
> >  clean:
> > diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
> > new file mode 100644
> > index ..d0de68d144cb
> > --- /dev/null
> > +++ b/arch/riscv/kernel/ftrace.c
> > @@ -0,0 +1,41 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2013 Linaro Limited
> > + * Author: AKASHI Takahiro 
> > + * Copyright (C) 2017 Andes Technology Corporation
> > + */
> > +
> > +#include 
> > +
> > +/*
> > + * Most of this file is copied from arm64.
> > + */
> > +void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr,
> > +  unsigned long frame_pointer)
> 

Re: [PATCH v2] riscv/ftrace: Add basic support

[Alan Kao]

On Mon, Dec 11, 2017 at 10:15:58AM -0800, Palmer Dabbelt wrote:
> On Wed, 06 Dec 2017 18:31:10 PST (-0800), noner...@gmail.com wrote:
> > This patch contains basic ftrace support for RV64I platform.
> > Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
> > tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
> > (HAVE_FUNCTION_GRAPH_FP_TEST) are implemented following the
> > instructions in Documentation/trace/ftrace-design.txt.
> > 
> > Note that the functions in both ftrace.c and setup.c should not be
> > hooked with the compiler's -pg option: to prevent infinite self-
> > referencing for the former, and to ignore early setup stuff for the
> > latter.
> > 
> > Signed-off-by: Alan Kao 
> > ---
> > Changes in v2:
> >   - Add SPDX license identifier
> >   - Remove unnecessary LOCKDEP_SUPPORT option
> >   - Remove unnecessary #ifdef in the newly added kernel/ftrace.c
> > 
> >  arch/riscv/Kconfig  |   5 ++
> >  arch/riscv/include/asm/Kbuild   |   1 -
> >  arch/riscv/include/asm/ftrace.h |  10 
> >  arch/riscv/kernel/Makefile  |   7 +++
> >  arch/riscv/kernel/ftrace.c  |  41 +
> >  arch/riscv/kernel/mcount.S  | 126 
> > 
> >  6 files changed, 189 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/riscv/include/asm/ftrace.h
> >  create mode 100644 arch/riscv/kernel/ftrace.c
> >  create mode 100644 arch/riscv/kernel/mcount.S
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 2e15e85c8f7e..40a67fc12328 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -60,6 +60,9 @@ config PAGE_OFFSET
> >  config STACKTRACE_SUPPORT
> > def_bool y
> > 
> > +config TRACE_IRQFLAGS_SUPPORT
> > +   def_bool y
> > +
> >  config RWSEM_GENERIC_SPINLOCK
> > def_bool y
> > 
> > @@ -112,6 +115,8 @@ config ARCH_RV64I
> > bool "RV64I"
> > select CPU_SUPPORTS_64BIT_KERNEL
> > select 64BIT
> > +   select HAVE_FUNCTION_TRACER
> > +   select HAVE_FUNCTION_GRAPH_TRACER
> > 
> >  endchoice
> > 
> > diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> > index 18158be62a2b..680301bfbc4b 100644
> > --- a/arch/riscv/include/asm/Kbuild
> > +++ b/arch/riscv/include/asm/Kbuild
> > @@ -12,7 +12,6 @@ generic-y += errno.h
> >  generic-y += exec.h
> >  generic-y += fb.h
> >  generic-y += fcntl.h
> > -generic-y += ftrace.h
> >  generic-y += futex.h
> >  generic-y += hardirq.h
> >  generic-y += hash.h
> > diff --git a/arch/riscv/include/asm/ftrace.h 
> > b/arch/riscv/include/asm/ftrace.h
> > new file mode 100644
> > index ..66d4175eb13e
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/ftrace.h
> > @@ -0,0 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (C) 2017 Andes Technology Corporation */
> > +
> > +/*
> > + * The graph frame test is not possible if CONFIG_FRAME_POINTER is not 
> > enabled.
> > + * Check arch/riscv/kernel/mcount.S for detail.
> > + */
> > +#if defined(CONFIG_FUNCTION_GRAPH_TRACER) && defined(CONFIG_FRAME_POINTER)
> > +#define HAVE_FUNCTION_GRAPH_FP_TEST
> > +#endif
> > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > index ab8baf7bd142..15941f3b8363 100644
> > --- a/arch/riscv/kernel/Makefile
> > +++ b/arch/riscv/kernel/Makefile
> > @@ -2,6 +2,11 @@
> >  # Makefile for the RISC-V Linux kernel
> >  #
> > 
> > +#ifdef CONFIG_FTRACE
> > +CFLAGS_REMOVE_ftrace.o = -pg
> > +CFLAGS_REMOVE_setup.o = -pg
> > +#endif
> > +
> 
> You want ifeq, not #ifdef, in Makefiles.
>

Thanks for pointing out this. It will be fixed in v3.

> Also: I thought we were only unable to trace setup_vm()?  Either way, I
> don't think it's a big deal to avoid tracing anything in setup.c: the stuff
> in here is called once pet hart before userspace is set up, so I doubt
> anyone is going to want to trace it anyway.
>

Sure. setup_vm() is the only trouble that causes panic.

> >  extra-y += head.o
> >  extra-y += vmlinux.lds
> > 
> > @@ -29,5 +34,7 @@ CFLAGS_setup.o := -mcmodel=medany
> >  obj-$(CONFIG_SMP)  += smpboot.o
> >  obj-$(CONFIG_SMP)  += smp.o
> >  obj-$(CONFIG_MODULES)  += module.o
> > +obj-$(CONFIG_FUNCTION_TRACER)  += mcount.o
> > +obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ftrace.o
> > 
> >  clean:
> > diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
> > new file mode 100644
> > index ..d0de68d144cb
> > --- /dev/null
> > +++ b/arch/riscv/kernel/ftrace.c
> > @@ -0,0 +1,41 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2013 Linaro Limited
> > + * Author: AKASHI Takahiro 
> > + * Copyright (C) 2017 Andes Technology Corporation
> > + */
> > +
> > +#include 
> > +
> > +/*
> > + * Most of this file is copied from arm64.
> > + */
> > +void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr,
> > +  unsigned long frame_pointer)
> > +{
> > +   unsigned long return_hooker = 

Re: [PATCH] KVM: X86: Fix stack-out-of-bounds read in write_mmio

[Wanpeng Li]

2017-12-12 13:52 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li 
>
> Reported by syzkaller:
>
>   BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm]
>   Read of size 8 at addr 8803259df7f8 by task syz-executor/32298
>
>   CPU: 6 PID: 32298 Comm: syz-executor Tainted: G   OE4.15.0-rc2+ 
> #18
>   Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 
> 02/16/2016
>   Call Trace:
>dump_stack+0xab/0xe1
>print_address_description+0x6b/0x290
>kasan_report+0x28a/0x370
>write_mmio+0x11e/0x270 [kvm]
>emulator_read_write_onepage+0x311/0x600 [kvm]
>emulator_read_write+0xef/0x240 [kvm]
>emulator_fix_hypercall+0x105/0x150 [kvm]
>em_hypercall+0x2b/0x80 [kvm]
>x86_emulate_insn+0x2b1/0x1640 [kvm]
>x86_emulate_instruction+0x39a/0xb90 [kvm]
>handle_exception+0x1b4/0x4d0 [kvm_intel]
>vcpu_enter_guest+0x15a0/0x2640 [kvm]
>kvm_arch_vcpu_ioctl_run+0x549/0x7d0 [kvm]
>kvm_vcpu_ioctl+0x479/0x880 [kvm]
>do_vfs_ioctl+0x142/0x9a0
>SyS_ioctl+0x74/0x80
>entry_SYSCALL_64_fastpath+0x23/0x9a
>
> The path of patched vmmcall will patch 3 bytes opcode 0F 01 C1(vmcall)
> to the guest memory, however, write_mmio tracepoint always prints 8 bytes
> through *(u64 *)val since kvm splits the mmio access into 8 bytes. This
> can result in stack-out-of-bounds read due to access the extra 5 bytes.
> This patch fixes it by just accessing the bytes which we operates on.
>
> Before patch:
>
> syz-executor-5567  [007]  51370.561696: kvm_mmio: mmio write len 3 gpa 
> 0x10 val 0x110077c1010f
>
> After patch:
>
> syz-executor-13416 [002]  51302.299573: kvm_mmio: mmio write len 3 gpa 
> 0x10 val 0xc1010f
>
> Reported-by: Dmitry Vyukov 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Signed-off-by: Wanpeng Li 
> ---

Oops, a wrong version, please ignore this one.

>  arch/x86/kvm/x86.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bc5d853..51e7932 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4690,7 +4690,10 @@ static int write_emulate(struct kvm_vcpu *vcpu, gpa_t 
> gpa,
>
>  static int write_mmio(struct kvm_vcpu *vcpu, gpa_t gpa, int bytes, void *val)
>  {
> -   trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, *(u64 *)val);
> +   u64 data = 0;
> +
> +   memcpy(, val, bytes);
> +   trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, data);
> return vcpu_mmio_write(vcpu, gpa, bytes, val);
>  }
>
> --
> 2.7.4
>

Re: [PATCH] KVM: X86: Fix stack-out-of-bounds read in write_mmio

[Wanpeng Li]

2017-12-12 13:52 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li 
>
> Reported by syzkaller:
>
>   BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm]
>   Read of size 8 at addr 8803259df7f8 by task syz-executor/32298
>
>   CPU: 6 PID: 32298 Comm: syz-executor Tainted: G   OE4.15.0-rc2+ 
> #18
>   Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 
> 02/16/2016
>   Call Trace:
>dump_stack+0xab/0xe1
>print_address_description+0x6b/0x290
>kasan_report+0x28a/0x370
>write_mmio+0x11e/0x270 [kvm]
>emulator_read_write_onepage+0x311/0x600 [kvm]
>emulator_read_write+0xef/0x240 [kvm]
>emulator_fix_hypercall+0x105/0x150 [kvm]
>em_hypercall+0x2b/0x80 [kvm]
>x86_emulate_insn+0x2b1/0x1640 [kvm]
>x86_emulate_instruction+0x39a/0xb90 [kvm]
>handle_exception+0x1b4/0x4d0 [kvm_intel]
>vcpu_enter_guest+0x15a0/0x2640 [kvm]
>kvm_arch_vcpu_ioctl_run+0x549/0x7d0 [kvm]
>kvm_vcpu_ioctl+0x479/0x880 [kvm]
>do_vfs_ioctl+0x142/0x9a0
>SyS_ioctl+0x74/0x80
>entry_SYSCALL_64_fastpath+0x23/0x9a
>
> The path of patched vmmcall will patch 3 bytes opcode 0F 01 C1(vmcall)
> to the guest memory, however, write_mmio tracepoint always prints 8 bytes
> through *(u64 *)val since kvm splits the mmio access into 8 bytes. This
> can result in stack-out-of-bounds read due to access the extra 5 bytes.
> This patch fixes it by just accessing the bytes which we operates on.
>
> Before patch:
>
> syz-executor-5567  [007]  51370.561696: kvm_mmio: mmio write len 3 gpa 
> 0x10 val 0x110077c1010f
>
> After patch:
>
> syz-executor-13416 [002]  51302.299573: kvm_mmio: mmio write len 3 gpa 
> 0x10 val 0xc1010f
>
> Reported-by: Dmitry Vyukov 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Signed-off-by: Wanpeng Li 
> ---

Oops, a wrong version, please ignore this one.

>  arch/x86/kvm/x86.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bc5d853..51e7932 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4690,7 +4690,10 @@ static int write_emulate(struct kvm_vcpu *vcpu, gpa_t 
> gpa,
>
>  static int write_mmio(struct kvm_vcpu *vcpu, gpa_t gpa, int bytes, void *val)
>  {
> -   trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, *(u64 *)val);
> +   u64 data = 0;
> +
> +   memcpy(, val, bytes);
> +   trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, data);
> return vcpu_mmio_write(vcpu, gpa, bytes, val);
>  }
>
> --
> 2.7.4
>

Re: [PATCH 41/45] arch/x86: remove duplicate includes

[Juergen Gross]

On 11/12/17 21:42, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Signed-off-by: Pravin Shedge 

Reviewed-by: Juergen Gross 


Juergen

Re: Re: [PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

[Lan Tianyu]

On 2017年12月12日 14:42, Wanpeng Li wrote:
> 2017-12-12 7:23 GMT+08:00 Lan Tianyu :
>>
>> Reported by syzkaller:
>> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 
>> x86_emulate_insn+0x557/0x15f0 [kvm]
>> Modules linked in: kvm_intel kvm [last unloaded: kvm]
>> CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB   W
>> 4.15.0-rc2-next-20171208+ #32
>> Hardware name: Intel Corporation S1200SP/S1200SP, BIOS 
>> S1200SP.86B.01.03.0006.040720161253 04/07/2016
>> RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
>> RSP: 0018:8807234476d0 EFLAGS: 00010282
>> RAX:  RBX: 88072d0237a0 RCX: a0065c4d
>> RDX: 1100e5a046f9 RSI: 0003 RDI: 88072d0237c8
>> RBP: 880723447728 R08: 88072d02 R09: a008d240
>> R10: 0002 R11: ed00e7d87db3 R12: 88072d0237c8
>> R13: 88072d023870 R14: 88072d0238c2 R15: a008d080
>> FS:  7f8a68666700() GS:88080220() 
>> knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2009506c CR3: 00071fec4005 CR4: 003626f0
>> Call Trace:
>>  x86_emulate_instruction+0x3bc/0xb70 [kvm]
>>  ? reexecute_instruction.part.162+0x130/0x130 [kvm]
>>  vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
>>  ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
>>  ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
>>  ? wait_lapic_expire+0x25/0x270 [kvm]
>>  vcpu_enter_guest+0x720/0x1ef0 [kvm]
>>  ...
>>
>> Syzkaller tests KVM emulation code path with setting RSP 0x
>> and running in 64bit non paging mode. It triggers warning that exception
>> vector is > 1f(it's initialized to be 0xff in x86_emulate_instruction())
>> during emulation of pop instruction. This is due to pop emulation callback
>> em_pop() returns X86EMUL_PROPAGATE_FAULT while not populate exception
>> vector. POP emulation code accesses RSP with linear address
>> 0x and KVM mmu returns GVA as GPA during nonpaging mode.
>> In this case, GPA 0x(~0) conflicts with error code
>> UNMAPPED_GVA which is defined to be (~(u64)0). Caller vcpu_mmio_gva_to
>> _gpa() treats the return address as error and this also causes emulator
>> _read_write_onepage() returns X86EMUL_PROPAGATE_FAULT without a validated
>> exception vector.
>>
>> This patch is to mask linear address with address width to fix such issue
>> since linear address won't occupy all 64-bit even if in 5 level paging
>> mode.
>>
>> Reported-by: Dmitry Vyukov 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Dmitry Vyukov 
>> Cc: Jim Mattson 
>> Cc: Wanpeng Li 
>> Signed-off-by: Lan Tianyu 
> 
> Tested-by: Wanpeng Li 
> 

Thanks a lot.

-- 
Best regards
Tianyu Lan

Re: [PATCH 41/45] arch/x86: remove duplicate includes

[Juergen Gross]

On 11/12/17 21:42, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Signed-off-by: Pravin Shedge 

Reviewed-by: Juergen Gross 


Juergen

Re: Re: [PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

[Lan Tianyu]

On 2017年12月12日 14:42, Wanpeng Li wrote:
> 2017-12-12 7:23 GMT+08:00 Lan Tianyu :
>>
>> Reported by syzkaller:
>> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 
>> x86_emulate_insn+0x557/0x15f0 [kvm]
>> Modules linked in: kvm_intel kvm [last unloaded: kvm]
>> CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB   W
>> 4.15.0-rc2-next-20171208+ #32
>> Hardware name: Intel Corporation S1200SP/S1200SP, BIOS 
>> S1200SP.86B.01.03.0006.040720161253 04/07/2016
>> RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
>> RSP: 0018:8807234476d0 EFLAGS: 00010282
>> RAX:  RBX: 88072d0237a0 RCX: a0065c4d
>> RDX: 1100e5a046f9 RSI: 0003 RDI: 88072d0237c8
>> RBP: 880723447728 R08: 88072d02 R09: a008d240
>> R10: 0002 R11: ed00e7d87db3 R12: 88072d0237c8
>> R13: 88072d023870 R14: 88072d0238c2 R15: a008d080
>> FS:  7f8a68666700() GS:88080220() 
>> knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2009506c CR3: 00071fec4005 CR4: 003626f0
>> Call Trace:
>>  x86_emulate_instruction+0x3bc/0xb70 [kvm]
>>  ? reexecute_instruction.part.162+0x130/0x130 [kvm]
>>  vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
>>  ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
>>  ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
>>  ? wait_lapic_expire+0x25/0x270 [kvm]
>>  vcpu_enter_guest+0x720/0x1ef0 [kvm]
>>  ...
>>
>> Syzkaller tests KVM emulation code path with setting RSP 0x
>> and running in 64bit non paging mode. It triggers warning that exception
>> vector is > 1f(it's initialized to be 0xff in x86_emulate_instruction())
>> during emulation of pop instruction. This is due to pop emulation callback
>> em_pop() returns X86EMUL_PROPAGATE_FAULT while not populate exception
>> vector. POP emulation code accesses RSP with linear address
>> 0x and KVM mmu returns GVA as GPA during nonpaging mode.
>> In this case, GPA 0x(~0) conflicts with error code
>> UNMAPPED_GVA which is defined to be (~(u64)0). Caller vcpu_mmio_gva_to
>> _gpa() treats the return address as error and this also causes emulator
>> _read_write_onepage() returns X86EMUL_PROPAGATE_FAULT without a validated
>> exception vector.
>>
>> This patch is to mask linear address with address width to fix such issue
>> since linear address won't occupy all 64-bit even if in 5 level paging
>> mode.
>>
>> Reported-by: Dmitry Vyukov 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Dmitry Vyukov 
>> Cc: Jim Mattson 
>> Cc: Wanpeng Li 
>> Signed-off-by: Lan Tianyu 
> 
> Tested-by: Wanpeng Li 
> 

Thanks a lot.

-- 
Best regards
Tianyu Lan

Re: [RFT PATCH] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

[Marek Szyprowski]

Hi

On 2017-12-11 23:48, Javier Martinez Canillas wrote:

Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
for each Exynos 542x DTS. But unfortunately it missed to enable it for the
Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.

Signed-off-by: Javier Martinez Canillas 


Acked-by: Marek Szyprowski 


---

I believe this may cause the boot issues reported on Exynos5800 Peach Pi
from v4.15-rc3, the mentioned commit made to v4.15-rc1 but it seems that
didn't cause any harm until commit ("510353a63796 drm/bridge: analogix
dp: Fix runtime PM state in get_modes() callback") fixed the runtime PM
management in the DP driver.


Thanks for analyzing this. Lack of this change was probably responsible for
Exynos DRM initialization failure ("exynos-drm exynos-drm: failed to bind
1453.hdmi (ops hdmi_component_ops): -1" message and probably further
error "unbalanced disables for lcd_vdd", which shows that failure path of
analogix dp and simple panel causes unbalanced regulator disable.

This patch should go to v4.15-rcX (fixes) if possible.


I can't test right now, but I'm posting anyways as a RFT in case others
that have access to a Peach Pi can test it.

Best regards,
Javier

  arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index b2b95ff205e8..0029ec27819c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -664,6 +664,10 @@
status = "okay";
  };
  
+ {

+   status = "okay";
+};
+
  /* eMMC flash */
  _0 {
status = "okay";


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [RFT PATCH] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

[Marek Szyprowski]

Hi

On 2017-12-11 23:48, Javier Martinez Canillas wrote:

Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
for each Exynos 542x DTS. But unfortunately it missed to enable it for the
Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.

Signed-off-by: Javier Martinez Canillas 


Acked-by: Marek Szyprowski 


---

I believe this may cause the boot issues reported on Exynos5800 Peach Pi
from v4.15-rc3, the mentioned commit made to v4.15-rc1 but it seems that
didn't cause any harm until commit ("510353a63796 drm/bridge: analogix
dp: Fix runtime PM state in get_modes() callback") fixed the runtime PM
management in the DP driver.


Thanks for analyzing this. Lack of this change was probably responsible for
Exynos DRM initialization failure ("exynos-drm exynos-drm: failed to bind
1453.hdmi (ops hdmi_component_ops): -1" message and probably further
error "unbalanced disables for lcd_vdd", which shows that failure path of
analogix dp and simple panel causes unbalanced regulator disable.

This patch should go to v4.15-rcX (fixes) if possible.


I can't test right now, but I'm posting anyways as a RFT in case others
that have access to a Peach Pi can test it.

Best regards,
Javier

  arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index b2b95ff205e8..0029ec27819c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -664,6 +664,10 @@
status = "okay";
  };
  
+ {

+   status = "okay";
+};
+
  /* eMMC flash */
  _0 {
status = "okay";


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [RESEND] x86/numa: move setting parsed numa node to num_add_memblk

[zhong jiang]

On 2017/12/11 21:45, Michal Hocko wrote:
> On Mon 11-12-17 20:59:29, zhong jiang wrote:
>> On 2017/12/11 20:03, Michal Hocko wrote:
>>> On Fri 01-12-17 18:13:52, zhong jiang wrote:
 The acpi table are very much like user input. it is likely to
 introduce some unreasonable node in some architecture. but
 they do not ingore the node and bail out in time. it will result
 in unnecessary print.
 e.g  x86:  start is equal to end is a unreasonable node.
 numa_blk_memblk will fails but return 0.

 meanwhile, Arm64 node will double set it to "numa_node_parsed"
 after NUMA adds a memblk successfully.  but X86 is not. because
 numa_add_memblk is not set in X86.
>>> I am sorry but I still fail to understand wht the actual problem is.
>>> You said that x86 will print a message. Alright at least you know that
>>> the platform provides a nonsense ACPI/SRAT? tables and you can complain.
>>> But does the kernel misbehave? In what way?
>>   From the view of  the following code , we should expect that the node is 
>> reasonable.
>>   otherwise, if we only want to complain,  it should bail out in time after 
>> printing the
>>   unreasonable message.
>>
>>   node_set(node, numa_nodes_parsed);
>>
>> pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
>> node, pxm,
>> (unsigned long long) start, (unsigned long long) end - 1,
>> hotpluggable ? " hotplug" : "",
>> ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : 
>> "");
>>
>> /* Mark hotplug range in memblock. */
>> if (hotpluggable && memblock_mark_hotplug(start, ma->length))
>> pr_warn("SRAT: Failed to mark hotplug range [mem 
>> %#010Lx-%#010Lx] in memblock\n",
>> (unsigned long long)start, (unsigned long long)end - 
>> 1);
>>
>> max_possible_pfn = max(max_possible_pfn, PFN_UP(end - 1));
>>
>> return 0;
>> out_err_bad_srat:
>> bad_srat();
>>
>>  In addition.  Arm64  will double set node to numa_nodes_parsed after add a 
>> memblk
>> successfully.  Because numa_add_memblk will perform node_set(*, *).
>>
>>  if (numa_add_memblk(node, start, end) < 0) {
>> pr_err("SRAT: Failed to add memblk to node %u [mem 
>> %#010Lx-%#010Lx]\n",
>>node, (unsigned long long) start,
>>(unsigned long long) end - 1);
>> goto out_err_bad_srat;
>> }
>>
>> node_set(node, numa_nodes_parsed);
> I am sorry but I _do not_ understand how this answers my simple
> question. You are describing the code flow which doesn't really explain
> what is the _user_ or a _runtime_ visible effect. Anybody reading this
> changelog will have to scratch his head to understand what the heck does
> this fix and whether the patch needs to be considered for backporting.
> See my point?
 There  is not any visible effect to the user.  IMO,  it is  a better 
optimization.
 Maybe I put more words  to explain  how  the patch works.  :-[

 I found the code is messy when reading it without a real issue. 

 Thanks
 zhong jiang
 

Re: [RESEND] x86/numa: move setting parsed numa node to num_add_memblk

[zhong jiang]

On 2017/12/11 21:45, Michal Hocko wrote:
> On Mon 11-12-17 20:59:29, zhong jiang wrote:
>> On 2017/12/11 20:03, Michal Hocko wrote:
>>> On Fri 01-12-17 18:13:52, zhong jiang wrote:
 The acpi table are very much like user input. it is likely to
 introduce some unreasonable node in some architecture. but
 they do not ingore the node and bail out in time. it will result
 in unnecessary print.
 e.g  x86:  start is equal to end is a unreasonable node.
 numa_blk_memblk will fails but return 0.

 meanwhile, Arm64 node will double set it to "numa_node_parsed"
 after NUMA adds a memblk successfully.  but X86 is not. because
 numa_add_memblk is not set in X86.
>>> I am sorry but I still fail to understand wht the actual problem is.
>>> You said that x86 will print a message. Alright at least you know that
>>> the platform provides a nonsense ACPI/SRAT? tables and you can complain.
>>> But does the kernel misbehave? In what way?
>>   From the view of  the following code , we should expect that the node is 
>> reasonable.
>>   otherwise, if we only want to complain,  it should bail out in time after 
>> printing the
>>   unreasonable message.
>>
>>   node_set(node, numa_nodes_parsed);
>>
>> pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
>> node, pxm,
>> (unsigned long long) start, (unsigned long long) end - 1,
>> hotpluggable ? " hotplug" : "",
>> ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : 
>> "");
>>
>> /* Mark hotplug range in memblock. */
>> if (hotpluggable && memblock_mark_hotplug(start, ma->length))
>> pr_warn("SRAT: Failed to mark hotplug range [mem 
>> %#010Lx-%#010Lx] in memblock\n",
>> (unsigned long long)start, (unsigned long long)end - 
>> 1);
>>
>> max_possible_pfn = max(max_possible_pfn, PFN_UP(end - 1));
>>
>> return 0;
>> out_err_bad_srat:
>> bad_srat();
>>
>>  In addition.  Arm64  will double set node to numa_nodes_parsed after add a 
>> memblk
>> successfully.  Because numa_add_memblk will perform node_set(*, *).
>>
>>  if (numa_add_memblk(node, start, end) < 0) {
>> pr_err("SRAT: Failed to add memblk to node %u [mem 
>> %#010Lx-%#010Lx]\n",
>>node, (unsigned long long) start,
>>(unsigned long long) end - 1);
>> goto out_err_bad_srat;
>> }
>>
>> node_set(node, numa_nodes_parsed);
> I am sorry but I _do not_ understand how this answers my simple
> question. You are describing the code flow which doesn't really explain
> what is the _user_ or a _runtime_ visible effect. Anybody reading this
> changelog will have to scratch his head to understand what the heck does
> this fix and whether the patch needs to be considered for backporting.
> See my point?
 There  is not any visible effect to the user.  IMO,  it is  a better 
optimization.
 Maybe I put more words  to explain  how  the patch works.  :-[

 I found the code is messy when reading it without a real issue. 

 Thanks
 zhong jiang
 

Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530

[Sean Wang]

Hi, Andrew

All sounds reasonable. All will be fixed in the next version.

Sean

On Thu, 2017-12-07 at 16:24 +0100, Andrew Lunn wrote:
> >  static void
> > +mt7530_port_set_vlan_unware(struct dsa_switch *ds, int port)
> > +{
> > +   struct mt7530_priv *priv = ds->priv;
> > +   int i;
> > +   bool all_user_ports_removed = true;
> 
> Hi Sean
> 
> Reverse Christmas tree please.
> 

will be fixed 

> > +static int
> > +mt7530_vlan_cmd(struct mt7530_priv *priv, enum mt7530_vlan_cmd cmd, u16 
> > vid)
> > +{
> > +   u32 val;
> > +   int ret;
> > +   struct mt7530_dummy_poll p;
> 
> Here too.
> 

will be fixed

> > +static int
> > +mt7530_port_vlan_prepare(struct dsa_switch *ds, int port,
> > +const struct switchdev_obj_port_vlan *vlan,
> > +struct switchdev_trans *trans)
> > +{
> > +   struct mt7530_priv *priv = ds->priv;
> > +
> > +   /* The port is being kept as VLAN-unware port when bridge is set up
> > +* with vlan_filtering not being set, Otherwise, the port and the
> > +* corresponding CPU port is required the setup for becoming a
> > +* VLAN-ware port.
> > +*/
> > +   if (!priv->ports[port].vlan_filtering)
> > +   return 0;
> > +
> > +   mt7530_port_set_vlan_ware(ds, port);
> > +   mt7530_port_set_vlan_ware(ds, MT7530_CPU_PORT);
> 
> A prepare function should just validate that it is possible to carry
> out the operation. It should not change any state. These two last
> lines probably don't belong here.
> 

okay, it will be moved into the proper place such as
mt7530_port_vlan_filtering

> > +
> > +   return 0;
> > +}
> > +
> > +static void
> > +mt7530_hw_vlan_add(struct mt7530_priv *priv,
> > +  struct mt7530_hw_vlan_entry *entry)
> > +{
> > +   u32 val;
> > +   u8 new_members;
> 
> Reverse Christmas tree. Please check the whole patch.
> 
 will be fixed

> > +static inline void INIT_MT7530_HW_ENTRY(struct mt7530_hw_vlan_entry *e,
> > +   int port, bool untagged)
> > +{
> > +   e->port = port;
> > +   e->untagged = untagged;
> > +}
> 
> All CAPITAL letters is for #defines. This is just a normal
> function. Please use lower case.
> 

will be fixed
> Andrew
> 

Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530

[Sean Wang]

Hi, Andrew

All sounds reasonable. All will be fixed in the next version.

Sean

On Thu, 2017-12-07 at 16:24 +0100, Andrew Lunn wrote:
> >  static void
> > +mt7530_port_set_vlan_unware(struct dsa_switch *ds, int port)
> > +{
> > +   struct mt7530_priv *priv = ds->priv;
> > +   int i;
> > +   bool all_user_ports_removed = true;
> 
> Hi Sean
> 
> Reverse Christmas tree please.
> 

will be fixed 

> > +static int
> > +mt7530_vlan_cmd(struct mt7530_priv *priv, enum mt7530_vlan_cmd cmd, u16 
> > vid)
> > +{
> > +   u32 val;
> > +   int ret;
> > +   struct mt7530_dummy_poll p;
> 
> Here too.
> 

will be fixed

> > +static int
> > +mt7530_port_vlan_prepare(struct dsa_switch *ds, int port,
> > +const struct switchdev_obj_port_vlan *vlan,
> > +struct switchdev_trans *trans)
> > +{
> > +   struct mt7530_priv *priv = ds->priv;
> > +
> > +   /* The port is being kept as VLAN-unware port when bridge is set up
> > +* with vlan_filtering not being set, Otherwise, the port and the
> > +* corresponding CPU port is required the setup for becoming a
> > +* VLAN-ware port.
> > +*/
> > +   if (!priv->ports[port].vlan_filtering)
> > +   return 0;
> > +
> > +   mt7530_port_set_vlan_ware(ds, port);
> > +   mt7530_port_set_vlan_ware(ds, MT7530_CPU_PORT);
> 
> A prepare function should just validate that it is possible to carry
> out the operation. It should not change any state. These two last
> lines probably don't belong here.
> 

okay, it will be moved into the proper place such as
mt7530_port_vlan_filtering

> > +
> > +   return 0;
> > +}
> > +
> > +static void
> > +mt7530_hw_vlan_add(struct mt7530_priv *priv,
> > +  struct mt7530_hw_vlan_entry *entry)
> > +{
> > +   u32 val;
> > +   u8 new_members;
> 
> Reverse Christmas tree. Please check the whole patch.
> 
 will be fixed

> > +static inline void INIT_MT7530_HW_ENTRY(struct mt7530_hw_vlan_entry *e,
> > +   int port, bool untagged)
> > +{
> > +   e->port = port;
> > +   e->untagged = untagged;
> > +}
> 
> All CAPITAL letters is for #defines. This is just a normal
> function. Please use lower case.
> 

will be fixed
> Andrew
> 

Re: [PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

[Wanpeng Li]

2017-12-12 7:23 GMT+08:00 Lan Tianyu :
>
> Reported by syzkaller:
> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 
> x86_emulate_insn+0x557/0x15f0 [kvm]
> Modules linked in: kvm_intel kvm [last unloaded: kvm]
> CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB   W
> 4.15.0-rc2-next-20171208+ #32
> Hardware name: Intel Corporation S1200SP/S1200SP, BIOS 
> S1200SP.86B.01.03.0006.040720161253 04/07/2016
> RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
> RSP: 0018:8807234476d0 EFLAGS: 00010282
> RAX:  RBX: 88072d0237a0 RCX: a0065c4d
> RDX: 1100e5a046f9 RSI: 0003 RDI: 88072d0237c8
> RBP: 880723447728 R08: 88072d02 R09: a008d240
> R10: 0002 R11: ed00e7d87db3 R12: 88072d0237c8
> R13: 88072d023870 R14: 88072d0238c2 R15: a008d080
> FS:  7f8a68666700() GS:88080220() 
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2009506c CR3: 00071fec4005 CR4: 003626f0
> Call Trace:
>  x86_emulate_instruction+0x3bc/0xb70 [kvm]
>  ? reexecute_instruction.part.162+0x130/0x130 [kvm]
>  vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
>  ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
>  ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
>  ? wait_lapic_expire+0x25/0x270 [kvm]
>  vcpu_enter_guest+0x720/0x1ef0 [kvm]
>  ...
>
> Syzkaller tests KVM emulation code path with setting RSP 0x
> and running in 64bit non paging mode. It triggers warning that exception
> vector is > 1f(it's initialized to be 0xff in x86_emulate_instruction())
> during emulation of pop instruction. This is due to pop emulation callback
> em_pop() returns X86EMUL_PROPAGATE_FAULT while not populate exception
> vector. POP emulation code accesses RSP with linear address
> 0x and KVM mmu returns GVA as GPA during nonpaging mode.
> In this case, GPA 0x(~0) conflicts with error code
> UNMAPPED_GVA which is defined to be (~(u64)0). Caller vcpu_mmio_gva_to
> _gpa() treats the return address as error and this also causes emulator
> _read_write_onepage() returns X86EMUL_PROPAGATE_FAULT without a validated
> exception vector.
>
> This patch is to mask linear address with address width to fix such issue
> since linear address won't occupy all 64-bit even if in 5 level paging
> mode.
>
> Reported-by: Dmitry Vyukov 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Dmitry Vyukov 
> Cc: Jim Mattson 
> Cc: Wanpeng Li 
> Signed-off-by: Lan Tianyu 

Tested-by: Wanpeng Li 

> ---
>  arch/x86/kvm/emulate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index abe74f7..9b21412 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -697,8 +697,8 @@ static __always_inline int __linearize(struct 
> x86_emulate_ctxt *ctxt,
> *max_size = 0;
> switch (mode) {
> case X86EMUL_MODE_PROT64:
> -   *linear = la;
> va_bits = ctxt_virt_addr_bits(ctxt);
> +   *linear = la & ((1ul << va_bits) - 1);
> if (get_canonical(la, va_bits) != la)
> goto bad;
>
> --
> 1.8.3.1
>

Re: [PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

[Wanpeng Li]

2017-12-12 7:23 GMT+08:00 Lan Tianyu :
>
> Reported by syzkaller:
> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 
> x86_emulate_insn+0x557/0x15f0 [kvm]
> Modules linked in: kvm_intel kvm [last unloaded: kvm]
> CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB   W
> 4.15.0-rc2-next-20171208+ #32
> Hardware name: Intel Corporation S1200SP/S1200SP, BIOS 
> S1200SP.86B.01.03.0006.040720161253 04/07/2016
> RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
> RSP: 0018:8807234476d0 EFLAGS: 00010282
> RAX:  RBX: 88072d0237a0 RCX: a0065c4d
> RDX: 1100e5a046f9 RSI: 0003 RDI: 88072d0237c8
> RBP: 880723447728 R08: 88072d02 R09: a008d240
> R10: 0002 R11: ed00e7d87db3 R12: 88072d0237c8
> R13: 88072d023870 R14: 88072d0238c2 R15: a008d080
> FS:  7f8a68666700() GS:88080220() 
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2009506c CR3: 00071fec4005 CR4: 003626f0
> Call Trace:
>  x86_emulate_instruction+0x3bc/0xb70 [kvm]
>  ? reexecute_instruction.part.162+0x130/0x130 [kvm]
>  vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
>  ? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
>  ? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
>  ? wait_lapic_expire+0x25/0x270 [kvm]
>  vcpu_enter_guest+0x720/0x1ef0 [kvm]
>  ...
>
> Syzkaller tests KVM emulation code path with setting RSP 0x
> and running in 64bit non paging mode. It triggers warning that exception
> vector is > 1f(it's initialized to be 0xff in x86_emulate_instruction())
> during emulation of pop instruction. This is due to pop emulation callback
> em_pop() returns X86EMUL_PROPAGATE_FAULT while not populate exception
> vector. POP emulation code accesses RSP with linear address
> 0x and KVM mmu returns GVA as GPA during nonpaging mode.
> In this case, GPA 0x(~0) conflicts with error code
> UNMAPPED_GVA which is defined to be (~(u64)0). Caller vcpu_mmio_gva_to
> _gpa() treats the return address as error and this also causes emulator
> _read_write_onepage() returns X86EMUL_PROPAGATE_FAULT without a validated
> exception vector.
>
> This patch is to mask linear address with address width to fix such issue
> since linear address won't occupy all 64-bit even if in 5 level paging
> mode.
>
> Reported-by: Dmitry Vyukov 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Dmitry Vyukov 
> Cc: Jim Mattson 
> Cc: Wanpeng Li 
> Signed-off-by: Lan Tianyu 

Tested-by: Wanpeng Li 

> ---
>  arch/x86/kvm/emulate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index abe74f7..9b21412 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -697,8 +697,8 @@ static __always_inline int __linearize(struct 
> x86_emulate_ctxt *ctxt,
> *max_size = 0;
> switch (mode) {
> case X86EMUL_MODE_PROT64:
> -   *linear = la;
> va_bits = ctxt_virt_addr_bits(ctxt);
> +   *linear = la & ((1ul << va_bits) - 1);
> if (get_canonical(la, va_bits) != la)
> goto bad;
>
> --
> 1.8.3.1
>

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

[Amir Goldstein]

On Mon, Dec 11, 2017 at 11:52 PM, NeilBrown  wrote:
> On Mon, Dec 11 2017, Amir Goldstein wrote:
>
>> On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown  wrote:
>>> If a filesystem does not set sb->s_export_op, then it
>>> does not support filehandles and export_fs_encode_fh()
>>> and exportfs_encode_inode_fh() should not be called.
>>> They will use export_encode_fh() is which is a default
>>> that uses inode number generation number, but in general
>>> they may not be stable.
>>>
>>> So change exportfs_encode_inode_fh() to return FILEID_INVALID
>>> if called on an unsupported Filesystem.  Currently only
>>> notify/fdinfo can do that.
>>>
>>
>> I wish you would leave this check to the caller, maybe add a helper
>> exportfs_can_decode_fh() for callers to use.
>>
>> Although there are no current uses for it in-tree, there is value in
>> being able to encode a unique file handle even when it cannot be
>> decoded back to an open file.
>>
>> I am using this property in my fanotify super block watch patches,
>> where the object identifier on the event is an encoded file handle
>> of the object, which delegates tracking filesystem objects to
>> userspace and prevents fanotify from keeping elevated refcounts
>> on inodes and dentries.
>>
>> There are quite a few userspace tools out there that are checking
>> that st_ino hasn't changed on a file between non atomic operations.
>> Those tools (or others) could benefit from a unique file handle if
>> we ever decide to provide a relaxed version of name_to_handle_at().
>
> If the filesystem doesn't define ->s_export_op, then you really cannot
> trust anything beyond the inode number (and maybe not even that), and
> the inode number is already easily available.
> What actual value do you think you get from this pretend-file-handle
> on filesystems that don't support file handles?
>

Sorry, I misread your patch. In my mind I thought you wanted to
eliminate the default export_encode_fh if there was no fh_to_dentry
operation like do_sys_name_to_handle() does. Just in my head...

FWIW, according to Pavel, if fdinfo would not export file handle
in case !fh_to_dentry op would probably be desirable, because
criu has no need for file handles that cannot be decoded.

Amir.

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

[Amir Goldstein]

On Mon, Dec 11, 2017 at 11:52 PM, NeilBrown  wrote:
> On Mon, Dec 11 2017, Amir Goldstein wrote:
>
>> On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown  wrote:
>>> If a filesystem does not set sb->s_export_op, then it
>>> does not support filehandles and export_fs_encode_fh()
>>> and exportfs_encode_inode_fh() should not be called.
>>> They will use export_encode_fh() is which is a default
>>> that uses inode number generation number, but in general
>>> they may not be stable.
>>>
>>> So change exportfs_encode_inode_fh() to return FILEID_INVALID
>>> if called on an unsupported Filesystem.  Currently only
>>> notify/fdinfo can do that.
>>>
>>
>> I wish you would leave this check to the caller, maybe add a helper
>> exportfs_can_decode_fh() for callers to use.
>>
>> Although there are no current uses for it in-tree, there is value in
>> being able to encode a unique file handle even when it cannot be
>> decoded back to an open file.
>>
>> I am using this property in my fanotify super block watch patches,
>> where the object identifier on the event is an encoded file handle
>> of the object, which delegates tracking filesystem objects to
>> userspace and prevents fanotify from keeping elevated refcounts
>> on inodes and dentries.
>>
>> There are quite a few userspace tools out there that are checking
>> that st_ino hasn't changed on a file between non atomic operations.
>> Those tools (or others) could benefit from a unique file handle if
>> we ever decide to provide a relaxed version of name_to_handle_at().
>
> If the filesystem doesn't define ->s_export_op, then you really cannot
> trust anything beyond the inode number (and maybe not even that), and
> the inode number is already easily available.
> What actual value do you think you get from this pretend-file-handle
> on filesystems that don't support file handles?
>

Sorry, I misread your patch. In my mind I thought you wanted to
eliminate the default export_encode_fh if there was no fh_to_dentry
operation like do_sys_name_to_handle() does. Just in my head...

FWIW, according to Pavel, if fdinfo would not export file handle
in case !fh_to_dentry op would probably be desirable, because
criu has no need for file handles that cannot be decoded.

Amir.

Re: [PATCH] ARM: dts: omap3-evm: Fix missing NAND partition information

[Ladislav Michl]

On Mon, Dec 11, 2017 at 10:12:13PM -0600, Derald D. Woods wrote:
> The partition information was omitted during the conversion to OMAP3430
> specific data.

That could be intentional...

> The data added by this commit is consistent with current U-Boot default
> definitions.

What about passing U-Boot partitions information to kernel instead?

> Fixes: 62fe1d337461 ("ARM: dts: omap3-evm: Add OMAP3530 specific device
> tree processor data")
> 
> Signed-off-by: Derald D. Woods 
> ---
>  arch/arm/boot/dts/omap3-evm.dts | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index 21a3b88aef0c..1220deb47aae 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -85,5 +85,30 @@
>  
>   #address-cells = <1>;
>   #size-cells = <1>;
> +
> + partition@0 {
> + label = "spl";
> + reg = <0 0x8>;
> + };
> + partition@8 {
> + label = "u-boot";
> + reg = <0x8 0x1c>;
> + };
> + partition@24 {
> + label = "dtb";
> + reg = <0x24 0x2>;
> + };
> + partition@26 {
> + label = "u-boot-env";
> + reg = <0x26 0x2>;
> + };
> + partition@28 {
> + label = "kernel";
> + reg = <0x28 0x60>;
> + };
> + partition@88 {
> + label = "rootfs";
> + reg = <0x88 0>;
> + };
>   };
>  };
> -- 
> 2.15.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-evm: Fix missing NAND partition information

[Ladislav Michl]

On Mon, Dec 11, 2017 at 10:12:13PM -0600, Derald D. Woods wrote:
> The partition information was omitted during the conversion to OMAP3430
> specific data.

That could be intentional...

> The data added by this commit is consistent with current U-Boot default
> definitions.

What about passing U-Boot partitions information to kernel instead?

> Fixes: 62fe1d337461 ("ARM: dts: omap3-evm: Add OMAP3530 specific device
> tree processor data")
> 
> Signed-off-by: Derald D. Woods 
> ---
>  arch/arm/boot/dts/omap3-evm.dts | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index 21a3b88aef0c..1220deb47aae 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -85,5 +85,30 @@
>  
>   #address-cells = <1>;
>   #size-cells = <1>;
> +
> + partition@0 {
> + label = "spl";
> + reg = <0 0x8>;
> + };
> + partition@8 {
> + label = "u-boot";
> + reg = <0x8 0x1c>;
> + };
> + partition@24 {
> + label = "dtb";
> + reg = <0x24 0x2>;
> + };
> + partition@26 {
> + label = "u-boot-env";
> + reg = <0x26 0x2>;
> + };
> + partition@28 {
> + label = "kernel";
> + reg = <0x28 0x60>;
> + };
> + partition@88 {
> + label = "rootfs";
> + reg = <0x88 0>;
> + };
>   };
>  };
> -- 
> 2.15.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] arm64: v8.4: Support for new floating point multiplication instructions

[Dongjiu Geng]

ARM v8.4 extensions add new neon instructions for performing a
multiplication of each FP16 element of one vector with the corresponding
FP16 element of a second vector, and to add or subtract this without an
intermediate rounding to the corresponding FP32 element in a third vector.

This patch detects this feature and let the userspace know about it via a
HWCAP bit and MRS emulation.

Cc: Dave Martin 
Cc: Suzuki K Poulose 
Signed-off-by: Dongjiu Geng 
---
Change since v1:
1. Address Dave and Suzuki's comments to update the commit message.
2. Address Dave's comments to update Documentation/arm64/elf_hwcaps.txt.
---
 Documentation/arm64/cpu-feature-registers.txt | 4 +++-
 Documentation/arm64/elf_hwcaps.txt| 4 
 arch/arm64/include/asm/sysreg.h   | 1 +
 arch/arm64/include/uapi/asm/hwcap.h   | 1 +
 arch/arm64/kernel/cpufeature.c| 2 ++
 arch/arm64/kernel/cpuinfo.c   | 1 +
 6 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/cpu-feature-registers.txt 
b/Documentation/arm64/cpu-feature-registers.txt
index bd9b3fa..a70090b 100644
--- a/Documentation/arm64/cpu-feature-registers.txt
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -110,7 +110,9 @@ infrastructure:
  x--x
  | Name |  bits   | visible |
  |--|
- | RES0 | [63-48] |n|
+ | RES0 | [63-52] |n|
+ |--|
+ | FHM  | [51-48] |y|
  |--|
  | DP   | [47-44] |y|
  |--|
diff --git a/Documentation/arm64/elf_hwcaps.txt 
b/Documentation/arm64/elf_hwcaps.txt
index 89edba1..987c40e 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -158,3 +158,7 @@ HWCAP_SHA512
 HWCAP_SVE
 
 Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_FHM
+
+   Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..1818077 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -419,6 +419,7 @@
 #define SCTLR_EL1_CP15BEN  (1 << 5)
 
 /* id_aa64isar0 */
+#define ID_AA64ISAR0_FHM_SHIFT 48
 #define ID_AA64ISAR0_DP_SHIFT  44
 #define ID_AA64ISAR0_SM4_SHIFT 40
 #define ID_AA64ISAR0_SM3_SHIFT 36
diff --git a/arch/arm64/include/uapi/asm/hwcap.h 
b/arch/arm64/include/uapi/asm/hwcap.h
index cda76fa..f018c3d 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -43,5 +43,6 @@
 #define HWCAP_ASIMDDP  (1 << 20)
 #define HWCAP_SHA512   (1 << 21)
 #define HWCAP_SVE  (1 << 22)
+#define HWCAP_ASIMDFHM (1 << 23)
 
 #endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..bc7e707 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
  * sync with the documentation of the CPU feature register ABI.
  */
 static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
+   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_FHM_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_DP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_SM4_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_SM3_SHIFT, 4, 0),
@@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct 
arm64_cpu_capabilities *entry, int __unus
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 
1, CAP_HWCAP, HWCAP_SM3),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 
1, CAP_HWCAP, HWCAP_SM4),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, 
CAP_HWCAP, HWCAP_ASIMDDP),
+   HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 
1, CAP_HWCAP, HWCAP_ASIMDFHM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, 
CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, 
CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, 
CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 1e25545..7f94623 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -76,6 +76,7 @@
"asimddp",

[PATCH v2] arm64: v8.4: Support for new floating point multiplication instructions

[Dongjiu Geng]

ARM v8.4 extensions add new neon instructions for performing a
multiplication of each FP16 element of one vector with the corresponding
FP16 element of a second vector, and to add or subtract this without an
intermediate rounding to the corresponding FP32 element in a third vector.

This patch detects this feature and let the userspace know about it via a
HWCAP bit and MRS emulation.

Cc: Dave Martin 
Cc: Suzuki K Poulose 
Signed-off-by: Dongjiu Geng 
---
Change since v1:
1. Address Dave and Suzuki's comments to update the commit message.
2. Address Dave's comments to update Documentation/arm64/elf_hwcaps.txt.
---
 Documentation/arm64/cpu-feature-registers.txt | 4 +++-
 Documentation/arm64/elf_hwcaps.txt| 4 
 arch/arm64/include/asm/sysreg.h   | 1 +
 arch/arm64/include/uapi/asm/hwcap.h   | 1 +
 arch/arm64/kernel/cpufeature.c| 2 ++
 arch/arm64/kernel/cpuinfo.c   | 1 +
 6 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/cpu-feature-registers.txt 
b/Documentation/arm64/cpu-feature-registers.txt
index bd9b3fa..a70090b 100644
--- a/Documentation/arm64/cpu-feature-registers.txt
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -110,7 +110,9 @@ infrastructure:
  x--x
  | Name |  bits   | visible |
  |--|
- | RES0 | [63-48] |n|
+ | RES0 | [63-52] |n|
+ |--|
+ | FHM  | [51-48] |y|
  |--|
  | DP   | [47-44] |y|
  |--|
diff --git a/Documentation/arm64/elf_hwcaps.txt 
b/Documentation/arm64/elf_hwcaps.txt
index 89edba1..987c40e 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -158,3 +158,7 @@ HWCAP_SHA512
 HWCAP_SVE
 
 Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_FHM
+
+   Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..1818077 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -419,6 +419,7 @@
 #define SCTLR_EL1_CP15BEN  (1 << 5)
 
 /* id_aa64isar0 */
+#define ID_AA64ISAR0_FHM_SHIFT 48
 #define ID_AA64ISAR0_DP_SHIFT  44
 #define ID_AA64ISAR0_SM4_SHIFT 40
 #define ID_AA64ISAR0_SM3_SHIFT 36
diff --git a/arch/arm64/include/uapi/asm/hwcap.h 
b/arch/arm64/include/uapi/asm/hwcap.h
index cda76fa..f018c3d 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -43,5 +43,6 @@
 #define HWCAP_ASIMDDP  (1 << 20)
 #define HWCAP_SHA512   (1 << 21)
 #define HWCAP_SVE  (1 << 22)
+#define HWCAP_ASIMDFHM (1 << 23)
 
 #endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..bc7e707 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
  * sync with the documentation of the CPU feature register ABI.
  */
 static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
+   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_FHM_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_DP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_SM4_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64ISAR0_SM3_SHIFT, 4, 0),
@@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct 
arm64_cpu_capabilities *entry, int __unus
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 
1, CAP_HWCAP, HWCAP_SM3),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 
1, CAP_HWCAP, HWCAP_SM4),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, 
CAP_HWCAP, HWCAP_ASIMDDP),
+   HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 
1, CAP_HWCAP, HWCAP_ASIMDFHM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, 
CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, 
CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, 
CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 1e25545..7f94623 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -76,6 +76,7 @@
"asimddp",
"sha512",
"sve",
+   "asimdfhm",
NULL
 };
 
-- 
1.9.1

[PATCH 0/2] Rockchip: Add rk1608 driver and DT-bindings

[Leo Wen]

For RK1608 driver ,you can use the v4l2-ctl command to capture frames.
Add DT bindings documentation for Rockchip RK1608.
Add the information of the maintainer.

Leo Wen (2):
  [media] Add Rockchip RK1608 driver
  dt-bindings: Document the Rockchip RK1608 bindings

 Documentation/devicetree/bindings/media/rk1608.txt |  143 +++
 MAINTAINERS|7 +
 drivers/media/spi/Makefile |1 +
 drivers/media/spi/rk1608.c | 1165 
 drivers/media/spi/rk1608.h |  366 ++
 5 files changed, 1682 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rk1608.txt
 create mode 100644 drivers/media/spi/rk1608.c
 create mode 100644 drivers/media/spi/rk1608.h

-- 
2.7.4

[PATCH 0/2] Rockchip: Add rk1608 driver and DT-bindings

[Leo Wen]

For RK1608 driver ,you can use the v4l2-ctl command to capture frames.
Add DT bindings documentation for Rockchip RK1608.
Add the information of the maintainer.

Leo Wen (2):
  [media] Add Rockchip RK1608 driver
  dt-bindings: Document the Rockchip RK1608 bindings

 Documentation/devicetree/bindings/media/rk1608.txt |  143 +++
 MAINTAINERS|7 +
 drivers/media/spi/Makefile |1 +
 drivers/media/spi/rk1608.c | 1165 
 drivers/media/spi/rk1608.h |  366 ++
 5 files changed, 1682 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rk1608.txt
 create mode 100644 drivers/media/spi/rk1608.c
 create mode 100644 drivers/media/spi/rk1608.h

-- 
2.7.4

[PATCH 2/2] dt-bindings: Document the Rockchip RK1608 bindings

[Leo Wen]

Add DT bindings documentation for Rockchip RK1608.

Signed-off-by: Leo Wen 
---
 Documentation/devicetree/bindings/media/rk1608.txt | 143 +
 MAINTAINERS|   1 +
 2 files changed, 144 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rk1608.txt

diff --git a/Documentation/devicetree/bindings/media/rk1608.txt 
b/Documentation/devicetree/bindings/media/rk1608.txt
new file mode 100644
index 000..bda5cdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rk1608.txt
@@ -0,0 +1,143 @@
+Rockchip RK1608 as a PreISP to link on Soc
+--
+
+Required properties:
+
+- compatible  : "rockchip,rk1608";
+- reg : SPI slave address of the rk1608;
+- clocks  : Must contain an entry for each entry in clock-names;
+- clock-names: Must contain "mclk" for the device's master clock;
+- reset-gpio  : GPIO connected to reset pin;
+- irq-gpio: GPIO connected to irq pin;
+- sleepst-gpio: GPIO connected to sleepst pin;
+- wakeup-gpio : GPIO connected to wakeup pin;
+- powerdown-gpio  : GPIO connected to powerdown pin;
+- pinctrl-names   : Should contain only one value - "default";
+- pinctrl-0   : Pin control group to be used for this controller;
+
+Optional properties:
+
+- spi-max-frequency: Maximum SPI clocking speed of the device;
+   (for RK1608)
+- spi-min-frequency: Minimum SPI clocking speed of the device;
+   (for RK1608)
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. The following are properties specific to those
+nodes.
+
+endpoint node
+-
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+  video-interfaces.txt. If present it should be <1> - the device
+  supports only one data lane without re-mapping.
+
+Note1: Since no data is generated in RK1608，so this is meaningful that you need
+a extra sensor (such as a camera) mounted on RK1608. You need to use endpoint@x
+to match these sensors.
+
+Note2:You must set the current value of the spi pins to be 8mA, if they are 
not.
+
+Example:
+
+ {
+   status = "okay";
+
+   spi_rk1608@00 {
+   compatible =  "rockchip,rk1608";
+   reg = <0>;
+   status = "okay";
+   spi-max-frequency = <2400>;
+   spi-min-frequency = <1200>;
+   clocks = < SCLK_SPI0>;
+   clock-names = "mclk";
+
+   reset-gpio = < 0 GPIO_ACTIVE_HIGH>;
+   irq-gpio = < 2 GPIO_ACTIVE_HIGH>;
+   sleepst-gpio = < 1 GPIO_ACTIVE_HIGH>;
+   wakeup-gpio = < 4 GPIO_ACTIVE_HIGH>;
+   powerdown-gpio = < 0 GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_irq_gpios _wake_gpios
+_sleep_gpios>;
+
+   port {
+   isp_mipi_out: endpoint {
+   remote-endpoint = <_mipi_in>;
+   data-lanes = <1>;
+   };
+   /*Example: we have two cameras*/
+   sensor_in0: endpoint@0 {
+   remote-endpoint = <>;
+   };
+
+   sensor_in1: endpoint@1 {
+   remote-endpoint = <>;
+   };
+   };
+   };
+};
+
+_phy_rx0 {
+   bus-width = <2>;
+   status = "okay";
+
+   port {
+   isp_mipi_in: endpoint {
+   remote-endpoint = <_mipi_out>;
+   data-lanes = <1>;
+   link-frequencies =
+   /bits/ 64 <10>;
+   };
+   };
+};
+
+ {
+   rk1608_irq_gpios {
+   rk1608_irq_gpios: rk1608_irq_gpios {
+   rockchip,pins = <6 2 RK_FUNC_GPIO _pull_none>;
+   rockchip,pull = <1>;
+   };
+   };
+
+   rk1608_wake_gpios {
+   rk1608_wake_gpios: rk1608_wake_gpios {
+   rockchip,pins = <6 4 RK_FUNC_GPIO _pull_none>;
+   rockchip,pull = <1>;
+   };
+   };
+
+   rk1608_sleep_gpios {
+   rk1608_sleep_gpios: rk1608_sleep_gpios {
+   rockchip,pins = <6 1 RK_FUNC_GPIO _pull_none>;
+   rockchip,pull = <1>;
+   rockchip,drive = <0>;
+   };
+   };
+
+   pcfg_pull_none_8ma: pcfg-pull-none-8ma {
+   bias-disable;
+   drive-strength = <8>;
+   };
+
+   spi0 {
+   spi0_clk: spi0-clk {
+  

[PATCH 2/2] dt-bindings: Document the Rockchip RK1608 bindings

[Leo Wen]

Add DT bindings documentation for Rockchip RK1608.

Signed-off-by: Leo Wen 
---
 Documentation/devicetree/bindings/media/rk1608.txt | 143 +
 MAINTAINERS|   1 +
 2 files changed, 144 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rk1608.txt

diff --git a/Documentation/devicetree/bindings/media/rk1608.txt 
b/Documentation/devicetree/bindings/media/rk1608.txt
new file mode 100644
index 000..bda5cdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rk1608.txt
@@ -0,0 +1,143 @@
+Rockchip RK1608 as a PreISP to link on Soc
+--
+
+Required properties:
+
+- compatible  : "rockchip,rk1608";
+- reg : SPI slave address of the rk1608;
+- clocks  : Must contain an entry for each entry in clock-names;
+- clock-names: Must contain "mclk" for the device's master clock;
+- reset-gpio  : GPIO connected to reset pin;
+- irq-gpio: GPIO connected to irq pin;
+- sleepst-gpio: GPIO connected to sleepst pin;
+- wakeup-gpio : GPIO connected to wakeup pin;
+- powerdown-gpio  : GPIO connected to powerdown pin;
+- pinctrl-names   : Should contain only one value - "default";
+- pinctrl-0   : Pin control group to be used for this controller;
+
+Optional properties:
+
+- spi-max-frequency: Maximum SPI clocking speed of the device;
+   (for RK1608)
+- spi-min-frequency: Minimum SPI clocking speed of the device;
+   (for RK1608)
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. The following are properties specific to those
+nodes.
+
+endpoint node
+-
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+  video-interfaces.txt. If present it should be <1> - the device
+  supports only one data lane without re-mapping.
+
+Note1: Since no data is generated in RK1608，so this is meaningful that you need
+a extra sensor (such as a camera) mounted on RK1608. You need to use endpoint@x
+to match these sensors.
+
+Note2:You must set the current value of the spi pins to be 8mA, if they are 
not.
+
+Example:
+
+ {
+   status = "okay";
+
+   spi_rk1608@00 {
+   compatible =  "rockchip,rk1608";
+   reg = <0>;
+   status = "okay";
+   spi-max-frequency = <2400>;
+   spi-min-frequency = <1200>;
+   clocks = < SCLK_SPI0>;
+   clock-names = "mclk";
+
+   reset-gpio = < 0 GPIO_ACTIVE_HIGH>;
+   irq-gpio = < 2 GPIO_ACTIVE_HIGH>;
+   sleepst-gpio = < 1 GPIO_ACTIVE_HIGH>;
+   wakeup-gpio = < 4 GPIO_ACTIVE_HIGH>;
+   powerdown-gpio = < 0 GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_irq_gpios _wake_gpios
+_sleep_gpios>;
+
+   port {
+   isp_mipi_out: endpoint {
+   remote-endpoint = <_mipi_in>;
+   data-lanes = <1>;
+   };
+   /*Example: we have two cameras*/
+   sensor_in0: endpoint@0 {
+   remote-endpoint = <>;
+   };
+
+   sensor_in1: endpoint@1 {
+   remote-endpoint = <>;
+   };
+   };
+   };
+};
+
+_phy_rx0 {
+   bus-width = <2>;
+   status = "okay";
+
+   port {
+   isp_mipi_in: endpoint {
+   remote-endpoint = <_mipi_out>;
+   data-lanes = <1>;
+   link-frequencies =
+   /bits/ 64 <10>;
+   };
+   };
+};
+
+ {
+   rk1608_irq_gpios {
+   rk1608_irq_gpios: rk1608_irq_gpios {
+   rockchip,pins = <6 2 RK_FUNC_GPIO _pull_none>;
+   rockchip,pull = <1>;
+   };
+   };
+
+   rk1608_wake_gpios {
+   rk1608_wake_gpios: rk1608_wake_gpios {
+   rockchip,pins = <6 4 RK_FUNC_GPIO _pull_none>;
+   rockchip,pull = <1>;
+   };
+   };
+
+   rk1608_sleep_gpios {
+   rk1608_sleep_gpios: rk1608_sleep_gpios {
+   rockchip,pins = <6 1 RK_FUNC_GPIO _pull_none>;
+   rockchip,pull = <1>;
+   rockchip,drive = <0>;
+   };
+   };
+
+   pcfg_pull_none_8ma: pcfg-pull-none-8ma {
+   bias-disable;
+   drive-strength = <8>;
+   };
+
+   spi0 {
+   spi0_clk: spi0-clk {
+   

[PATCH 1/2] [media] Add Rockchip RK1608 driver

[Leo Wen]

Rk1608 is used as a PreISP to link on Soc, which mainly has two functions.
One is to download the firmware of RK1608, and the other is to match the
extra sensor such as camera and enable sensor by calling sensor's s_power.

use below v4l2-ctl command to capture frames.

v4l2-ctl --verbose -d /dev/video1 --stream-mmap=2
--stream-to=/tmp/stream.out --stream-count=60 --stream-poll

use below command to playback the video on your PC.

mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
w=640:h=480:size=$((640*480*3/2)):format=NV12

Signed-off-by: Leo Wen 
---
 MAINTAINERS|6 +
 drivers/media/spi/Makefile |1 +
 drivers/media/spi/rk1608.c | 1165 
 drivers/media/spi/rk1608.h |  366 ++
 4 files changed, 1538 insertions(+)
 create mode 100644 drivers/media/spi/rk1608.c
 create mode 100644 drivers/media/spi/rk1608.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 82ad0ea..48235d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -128,6 +128,12 @@ Maintainers List (try to look for most precise areas first)
 
---
 
+ROCKCHIP RK1608 DRIVER
+M: Leo Wen 
+S: Maintained
+F: drivers/media/platform/spi/rk1608.c
+F: drivers/media/platform/spi/rk1608.h
+
 3C59X NETWORK DRIVER
 M: Steffen Klassert 
 L: net...@vger.kernel.org
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
index ea64013..9d9d9ec 100644
--- a/drivers/media/spi/Makefile
+++ b/drivers/media/spi/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_GS1662) += gs1662.o
+obj-$(CONFIG_ROCKCHIP_RK1608) += rk1608.o
diff --git a/drivers/media/spi/rk1608.c b/drivers/media/spi/rk1608.c
new file mode 100644
index 000..e646204
--- /dev/null
+++ b/drivers/media/spi/rk1608.c
@@ -0,0 +1,1165 @@
+/**
+ * Rockchip rk1608 driver
+ *
+ * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk1608.h"
+
+/**
+ * Rk1608 is used as the Pre-ISP to link on Soc, which mainly has two
+ * functions. One is to download the firmware of RK1608, and the other
+ * is to match the extra sensor such as camera and enable sensor by
+ * calling sensor's s_power.
+ * |---|
+ * | Sensor Camera |
+ * |---|
+ * |---||--|
+ * |---||--|
+ * |---\/--|
+ * | Pre-ISP RK1608|
+ * |---|
+ * |---||--|
+ * |---||--|
+ * |---\/--|
+ * |  Rockchip Soc |
+ * |---|
+ * Data Transfer As shown above. In RK1608, the data received from the
+ * extra sensor,and it is passed to the Soc through ISP.
+ */
+struct rk1608_state {
+   struct v4l2_subdev  sd;
+   struct v4l2_subdev  *sensor_sd;
+   struct device   *dev;
+   struct spi_device   *spi;
+   struct media_padpad;
+   struct clk  *mclk;
+   struct mutexlock;   /* protect resource */
+   struct mutexsensor_lock;/* protect sensor */
+   struct mutexsend_msg_lock;  /* protect msg */
+   int power_count;
+   int reset_gpio;
+   int reset_active;
+   int irq_gpio;
+   int irq;
+   int sleepst_gpio;
+   int 

[PATCH 1/2] [media] Add Rockchip RK1608 driver

[Leo Wen]

Rk1608 is used as a PreISP to link on Soc, which mainly has two functions.
One is to download the firmware of RK1608, and the other is to match the
extra sensor such as camera and enable sensor by calling sensor's s_power.

use below v4l2-ctl command to capture frames.

v4l2-ctl --verbose -d /dev/video1 --stream-mmap=2
--stream-to=/tmp/stream.out --stream-count=60 --stream-poll

use below command to playback the video on your PC.

mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
w=640:h=480:size=$((640*480*3/2)):format=NV12

Signed-off-by: Leo Wen 
---
 MAINTAINERS|6 +
 drivers/media/spi/Makefile |1 +
 drivers/media/spi/rk1608.c | 1165 
 drivers/media/spi/rk1608.h |  366 ++
 4 files changed, 1538 insertions(+)
 create mode 100644 drivers/media/spi/rk1608.c
 create mode 100644 drivers/media/spi/rk1608.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 82ad0ea..48235d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -128,6 +128,12 @@ Maintainers List (try to look for most precise areas first)
 
---
 
+ROCKCHIP RK1608 DRIVER
+M: Leo Wen 
+S: Maintained
+F: drivers/media/platform/spi/rk1608.c
+F: drivers/media/platform/spi/rk1608.h
+
 3C59X NETWORK DRIVER
 M: Steffen Klassert 
 L: net...@vger.kernel.org
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
index ea64013..9d9d9ec 100644
--- a/drivers/media/spi/Makefile
+++ b/drivers/media/spi/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_GS1662) += gs1662.o
+obj-$(CONFIG_ROCKCHIP_RK1608) += rk1608.o
diff --git a/drivers/media/spi/rk1608.c b/drivers/media/spi/rk1608.c
new file mode 100644
index 000..e646204
--- /dev/null
+++ b/drivers/media/spi/rk1608.c
@@ -0,0 +1,1165 @@
+/**
+ * Rockchip rk1608 driver
+ *
+ * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk1608.h"
+
+/**
+ * Rk1608 is used as the Pre-ISP to link on Soc, which mainly has two
+ * functions. One is to download the firmware of RK1608, and the other
+ * is to match the extra sensor such as camera and enable sensor by
+ * calling sensor's s_power.
+ * |---|
+ * | Sensor Camera |
+ * |---|
+ * |---||--|
+ * |---||--|
+ * |---\/--|
+ * | Pre-ISP RK1608|
+ * |---|
+ * |---||--|
+ * |---||--|
+ * |---\/--|
+ * |  Rockchip Soc |
+ * |---|
+ * Data Transfer As shown above. In RK1608, the data received from the
+ * extra sensor,and it is passed to the Soc through ISP.
+ */
+struct rk1608_state {
+   struct v4l2_subdev  sd;
+   struct v4l2_subdev  *sensor_sd;
+   struct device   *dev;
+   struct spi_device   *spi;
+   struct media_padpad;
+   struct clk  *mclk;
+   struct mutexlock;   /* protect resource */
+   struct mutexsensor_lock;/* protect sensor */
+   struct mutexsend_msg_lock;  /* protect msg */
+   int power_count;
+   int reset_gpio;
+   int reset_active;
+   int irq_gpio;
+   int irq;
+   int sleepst_gpio;
+   int sleepst_irq;
+   int wakeup_gpio;
+   int wakeup_active;
+   int 

Re: [PATCH] ptr_ring: add barriers

[George Cherian]

Hi David,

On 12/11/2017 09:23 PM, David Miller wrote:

From: "Michael S. Tsirkin" 
Date: Tue, 5 Dec 2017 21:29:37 +0200


Users of ptr_ring expect that it's safe to give the
data structure a pointer and have it be available
to consumers, but that actually requires an smb_wmb
or a stronger barrier.

In absence of such barriers and on architectures that reorder writes,
consumer might read an un=initialized value from an skb pointer stored
in the skb array.  This was observed causing crashes.

To fix, add memory barriers.  The barrier we use is a wmb, the
assumption being that producers do not need to read the value so we do
not need to order these reads.

Reported-by: George Cherian 
Suggested-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 


I'm asked for asking for testing feedback and did not get it in a
reasonable amount of time.


The tests have completed more than 48 hours without any failures.
I won't interrupt the same and run for longer time.
In case of any issue I will report the same.

So I'm applying this as-is, and queueing it up for -stable.

Thank you.


Regards,
-George

Re: [PATCH] ptr_ring: add barriers

[George Cherian]

Hi David,

On 12/11/2017 09:23 PM, David Miller wrote:

From: "Michael S. Tsirkin" 
Date: Tue, 5 Dec 2017 21:29:37 +0200


Users of ptr_ring expect that it's safe to give the
data structure a pointer and have it be available
to consumers, but that actually requires an smb_wmb
or a stronger barrier.

In absence of such barriers and on architectures that reorder writes,
consumer might read an un=initialized value from an skb pointer stored
in the skb array.  This was observed causing crashes.

To fix, add memory barriers.  The barrier we use is a wmb, the
assumption being that producers do not need to read the value so we do
not need to order these reads.

Reported-by: George Cherian 
Suggested-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 


I'm asked for asking for testing feedback and did not get it in a
reasonable amount of time.


The tests have completed more than 48 hours without any failures.
I won't interrupt the same and run for longer time.
In case of any issue I will report the same.

So I'm applying this as-is, and queueing it up for -stable.

Thank you.


Regards,
-George

[PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver

[sean.wang]

From: Sean Wang 

I work for MediaTek on maintaining the existing MediaTek SoC whose target
to home gateway such as MT7622 and MT7623 that is reusing MT2701 related
files and will keep adding support for the following such kinds of SoCs
in the future.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52f..c0edf30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10773,6 +10773,16 @@ M: Heikki Krogerus 

 S: Maintained
 F: drivers/pinctrl/intel/
 
+PIN CONTROLLER - MEDIATEK
+M: Sean Wang 
+L: linux-media...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
+F: Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
+F: drivers/pinctrl/mediatek/pinctrl-mtk-common.*
+F: drivers/pinctrl/mediatek/pinctrl-mt2701.c
+F: drivers/pinctrl/mediatek/pinctrl-mt7622.c
+
 PIN CONTROLLER - QUALCOMM
 M: Bjorn Andersson 
 S: Maintained
-- 
2.7.4

[PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver

[sean.wang]

From: Sean Wang 

I work for MediaTek on maintaining the existing MediaTek SoC whose target
to home gateway such as MT7622 and MT7623 that is reusing MT2701 related
files and will keep adding support for the following such kinds of SoCs
in the future.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52f..c0edf30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10773,6 +10773,16 @@ M: Heikki Krogerus 

 S: Maintained
 F: drivers/pinctrl/intel/
 
+PIN CONTROLLER - MEDIATEK
+M: Sean Wang 
+L: linux-media...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
+F: Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
+F: drivers/pinctrl/mediatek/pinctrl-mtk-common.*
+F: drivers/pinctrl/mediatek/pinctrl-mt2701.c
+F: drivers/pinctrl/mediatek/pinctrl-mt7622.c
+
 PIN CONTROLLER - QUALCOMM
 M: Bjorn Andersson 
 S: Maintained
-- 
2.7.4

[PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC

[sean.wang]

From: Sean Wang 

Add devicetree bindings for MediaTek MT7622 pinctrl driver.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 351 +
 1 file changed, 351 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
new file mode 100644
index 000..f18ed99
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
@@ -0,0 +1,351 @@
+== MediaTek MT7622 pinctrl controller ==
+
+Required properties for the root node:
+ - compatible: Should be one of the following
+  "mediatek,mt7622-pinctrl" for MT7622 SoC
+ - reg: offset and length of the pinctrl space
+
+ - gpio-controller: Marks the device node as a GPIO controller.
+ - #gpio-cells: Should be two. The first cell is the pin number and the
+   second is the GPIO flags.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+MT7622 pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, slew rate, etc.
+
+We support 2 types of configuration nodes. Those nodes can be either pinmux
+nodes or pinconf nodes. Each configuration node can consist of multiple nodes
+describing the pinmux and pinconf options.
+
+The name of each subnode doesn't matter as long as it is unique; all subnodes
+should be enumerated and processed purely based on their content.
+
+== pinmux nodes content ==
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinmux subnode:
+
+Required properties are:
+ - groups: An array of strings. Each string contains the name of a group.
+  Valid values for these names are listed below.
+ - function: A string containing the name of the function to mux to the
+  group. Valid values for function names are listed below.
+
+== pinconf nodes content ==
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinconf subnode:
+
+Required properties are:
+ - pins: An array of strings. Each string contains the name of a pin.
+  Valid values for these names are listed below.
+ - groups: An array of strings. Each string contains the name of a group.
+  Valid values for these names are listed below.
+
+Optional properies are:
+ bias-disable, bias-pull, bias-pull-down, input-enable,
+ input-schmitt-enable, input-schmitt-disable, output-enable
+ output-low, output-high, drive-strength, slew-rate
+
+ Valid arguments for 'slew-rate' are '0' for no slew rate controlled and '1' 
for
+ slower slew rate respectively.
+ Valid arguments for 'drive-strength', 4, 8, 12, or 16 in mA.
+
+The following specific properties as defined are valid to specify in a pinconf
+subnode:
+
+Optional properties are:
+ - mediatek,tdsel: An integer describing the steps for output level shifter 
duty
+   cycle when asserted (high pulse width adjustment). Valid arguments are from 0
+   to 15.
+ - mediatek,rdsel: An integer describing the steps for input level shifter duty
+   cycle when asserted (high pulse width adjustment). Valid arguments are from 0
+   to 63.
+
+== Valid values for pins, function and groups on MT7622 ==
+
+Valid values for pins are:
+pins can be referenced via the pin names as the below table shown and the
+related physical number is also put ahead of those names which helps cross
+references to pins between groups to know whether pins assignment conflict
+happens among devices try to acquire those available pins.
+
+   Pin #:  Valid values for pins
+   -
+   PIN 0: "GPIO_A"
+   PIN 1: "I2S1_IN"
+   PIN 2: "I2S1_OUT"
+   PIN 3: "I2S_BCLK"
+   PIN 4: "I2S_WS"
+   PIN 5: "I2S_MCLK"
+   PIN 6: "TXD0"
+   PIN 7: "RXD0"
+   PIN 8: "SPI_WP"
+   PIN 9: "SPI_HOLD"
+   PIN 10: "SPI_CLK"
+   PIN 11: "SPI_MOSI"
+   PIN 12: "SPI_MISO"
+   PIN 13: "SPI_CS"
+   PIN 14: "I2C_SDA"
+   PIN 15: "I2C_SCL"
+   PIN 16: "I2S2_IN"
+   PIN 17: "I2S3_IN"
+   PIN 18: "I2S4_IN"
+   PIN 19: "I2S2_OUT"
+   PIN 20: "I2S3_OUT"
+   PIN 21: "I2S4_OUT"
+   PIN 22: "GPIO_B"
+   PIN 23: "MDC"
+   PIN 24: "MDIO"
+   PIN 25: "G2_TXD0"
+   PIN 26: "G2_TXD1"
+   PIN 27: "G2_TXD2"
+   PIN 28: "G2_TXD3"
+   PIN 29: "G2_TXEN"
+   PIN 30: "G2_TXC"
+   PIN 31: "G2_RXD0"
+   PIN 32: "G2_RXD1"
+   PIN 

[PATCH v2 0/4] add support of pinctrl to MT7622 SoC

[sean.wang]

From: Sean Wang 

Changes since v1:
- add changes for the suggestion in v1.
- fix up the names for pin 14, 15, 71, 72, 93 and 94.
- add function "watchdog".
- change pin groups used by ethernet, i2s, led, pcie, spic, tdm
  and watchdog for refining the naming and reflecting the actual
  usage on the board.

The patchset adds support for pinctrl on MT7622 SoC.

patch 1: describe the hardware, also including the defintion for pins,
 groups and function.
patch 2: add cleanup for keep drivers inside the independent menu.
patch 3/4: add support for mt7622 SoC.

The IO core found on the SoC has the registers for pinctrl, pinconf and
gpio mixed up in the same register range.

However, the IO core for the MT7622 SoC is completely distinct from
anyone of previous MediaTek SoCs which already had support, such as the
hardware internal, register address map and register detailed definition
for each pin.

Therefore, instead, the driver is being newly implemented by reusing
generic methods provided from the core layer with GENERIC_PINCONF,
GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
simplicity and avoiding superfluous code. Where the function of pins
determined by groups is utilized in this driver which can help developers
less confused with what combinations of pins effective on the SoC and
even reducing the mistakes during the integration of those relevant
boards.

As the gpio_chip handling is also only a few lines, the driver also
implements the gpio functionality directly through GPIOLIB.

Sean Wang (4):
  dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC
  pinctrl: mediatek: cleanup for placing all drivers under the menu
  pinctrl: mediatek: add pinctrl driver for MT7622 SoC
  pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl
driver

 .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt |  351 +
 MAINTAINERS|   10 +
 drivers/pinctrl/Makefile   |2 +-
 drivers/pinctrl/mediatek/Kconfig   |   15 +-
 drivers/pinctrl/mediatek/Makefile  |3 +-
 drivers/pinctrl/mediatek/pinctrl-mt7622.c  | 1595 
 6 files changed, 1972 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7622.c

-- 
2.7.4

[PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC

[sean.wang]

From: Sean Wang 

Add devicetree bindings for MediaTek MT7622 pinctrl driver.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 351 +
 1 file changed, 351 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
new file mode 100644
index 000..f18ed99
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
@@ -0,0 +1,351 @@
+== MediaTek MT7622 pinctrl controller ==
+
+Required properties for the root node:
+ - compatible: Should be one of the following
+  "mediatek,mt7622-pinctrl" for MT7622 SoC
+ - reg: offset and length of the pinctrl space
+
+ - gpio-controller: Marks the device node as a GPIO controller.
+ - #gpio-cells: Should be two. The first cell is the pin number and the
+   second is the GPIO flags.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+MT7622 pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, slew rate, etc.
+
+We support 2 types of configuration nodes. Those nodes can be either pinmux
+nodes or pinconf nodes. Each configuration node can consist of multiple nodes
+describing the pinmux and pinconf options.
+
+The name of each subnode doesn't matter as long as it is unique; all subnodes
+should be enumerated and processed purely based on their content.
+
+== pinmux nodes content ==
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinmux subnode:
+
+Required properties are:
+ - groups: An array of strings. Each string contains the name of a group.
+  Valid values for these names are listed below.
+ - function: A string containing the name of the function to mux to the
+  group. Valid values for function names are listed below.
+
+== pinconf nodes content ==
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinconf subnode:
+
+Required properties are:
+ - pins: An array of strings. Each string contains the name of a pin.
+  Valid values for these names are listed below.
+ - groups: An array of strings. Each string contains the name of a group.
+  Valid values for these names are listed below.
+
+Optional properies are:
+ bias-disable, bias-pull, bias-pull-down, input-enable,
+ input-schmitt-enable, input-schmitt-disable, output-enable
+ output-low, output-high, drive-strength, slew-rate
+
+ Valid arguments for 'slew-rate' are '0' for no slew rate controlled and '1' 
for
+ slower slew rate respectively.
+ Valid arguments for 'drive-strength', 4, 8, 12, or 16 in mA.
+
+The following specific properties as defined are valid to specify in a pinconf
+subnode:
+
+Optional properties are:
+ - mediatek,tdsel: An integer describing the steps for output level shifter 
duty
+   cycle when asserted (high pulse width adjustment). Valid arguments are from 0
+   to 15.
+ - mediatek,rdsel: An integer describing the steps for input level shifter duty
+   cycle when asserted (high pulse width adjustment). Valid arguments are from 0
+   to 63.
+
+== Valid values for pins, function and groups on MT7622 ==
+
+Valid values for pins are:
+pins can be referenced via the pin names as the below table shown and the
+related physical number is also put ahead of those names which helps cross
+references to pins between groups to know whether pins assignment conflict
+happens among devices try to acquire those available pins.
+
+   Pin #:  Valid values for pins
+   -
+   PIN 0: "GPIO_A"
+   PIN 1: "I2S1_IN"
+   PIN 2: "I2S1_OUT"
+   PIN 3: "I2S_BCLK"
+   PIN 4: "I2S_WS"
+   PIN 5: "I2S_MCLK"
+   PIN 6: "TXD0"
+   PIN 7: "RXD0"
+   PIN 8: "SPI_WP"
+   PIN 9: "SPI_HOLD"
+   PIN 10: "SPI_CLK"
+   PIN 11: "SPI_MOSI"
+   PIN 12: "SPI_MISO"
+   PIN 13: "SPI_CS"
+   PIN 14: "I2C_SDA"
+   PIN 15: "I2C_SCL"
+   PIN 16: "I2S2_IN"
+   PIN 17: "I2S3_IN"
+   PIN 18: "I2S4_IN"
+   PIN 19: "I2S2_OUT"
+   PIN 20: "I2S3_OUT"
+   PIN 21: "I2S4_OUT"
+   PIN 22: "GPIO_B"
+   PIN 23: "MDC"
+   PIN 24: "MDIO"
+   PIN 25: "G2_TXD0"
+   PIN 26: "G2_TXD1"
+   PIN 27: "G2_TXD2"
+   PIN 28: "G2_TXD3"
+   PIN 29: "G2_TXEN"
+   PIN 30: "G2_TXC"
+   PIN 31: "G2_RXD0"
+   PIN 32: "G2_RXD1"
+   PIN 33: "G2_RXD2"
+   PIN 34: "G2_RXD3"
+   PIN 35: "G2_RXDV"
+   

[PATCH v2 0/4] add support of pinctrl to MT7622 SoC

[sean.wang]

From: Sean Wang 

Changes since v1:
- add changes for the suggestion in v1.
- fix up the names for pin 14, 15, 71, 72, 93 and 94.
- add function "watchdog".
- change pin groups used by ethernet, i2s, led, pcie, spic, tdm
  and watchdog for refining the naming and reflecting the actual
  usage on the board.

The patchset adds support for pinctrl on MT7622 SoC.

patch 1: describe the hardware, also including the defintion for pins,
 groups and function.
patch 2: add cleanup for keep drivers inside the independent menu.
patch 3/4: add support for mt7622 SoC.

The IO core found on the SoC has the registers for pinctrl, pinconf and
gpio mixed up in the same register range.

However, the IO core for the MT7622 SoC is completely distinct from
anyone of previous MediaTek SoCs which already had support, such as the
hardware internal, register address map and register detailed definition
for each pin.

Therefore, instead, the driver is being newly implemented by reusing
generic methods provided from the core layer with GENERIC_PINCONF,
GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
simplicity and avoiding superfluous code. Where the function of pins
determined by groups is utilized in this driver which can help developers
less confused with what combinations of pins effective on the SoC and
even reducing the mistakes during the integration of those relevant
boards.

As the gpio_chip handling is also only a few lines, the driver also
implements the gpio functionality directly through GPIOLIB.

Sean Wang (4):
  dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC
  pinctrl: mediatek: cleanup for placing all drivers under the menu
  pinctrl: mediatek: add pinctrl driver for MT7622 SoC
  pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl
driver

 .../devicetree/bindings/pinctrl/pinctrl-mt7622.txt |  351 +
 MAINTAINERS|   10 +
 drivers/pinctrl/Makefile   |2 +-
 drivers/pinctrl/mediatek/Kconfig   |   15 +-
 drivers/pinctrl/mediatek/Makefile  |3 +-
 drivers/pinctrl/mediatek/pinctrl-mt7622.c  | 1595 
 6 files changed, 1972 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7622.c

-- 
2.7.4

[PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu

[sean.wang]

From: Sean Wang 

Since lots of MediaTek drivers had been added, it seems slightly better
for that adding cleanup for placing MediaTek pinctrl drivers under the
independent menu as other kinds of drivers usually was done.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 drivers/pinctrl/mediatek/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index fac9866..03b3023 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -1,4 +1,5 @@
-if ARCH_MEDIATEK || COMPILE_TEST
+menu "MediaTek pinctrl drivers"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
 
 config PINCTRL_MTK
bool
@@ -46,4 +47,4 @@ config PINCTRL_MT6397
default MFD_MT6397
select PINCTRL_MTK
 
-endif
+endmenu
-- 
2.7.4

[PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC

[sean.wang]

From: Sean Wang 

Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has
the registers for pinctrl, pinconf and gpio mixed up in the same register
range. However, the IO core for the MT7622 SoC is completely distinct from
anyone of previous MediaTek SoCs which already had support, such as
the hardware internal, register address map and register detailed
definition for each pin.

Therefore, instead, the driver is being newly implemented by reusing
generic methods provided from the core layer with GENERIC_PINCONF,
GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
simplicity and rid of superfluous code. Where the function of pins
determined by groups is utilized in this driver which can help developers
less confused with what combinations of pins effective on the SoC and even
reducing the mistakes during the integration of those relevant boards.

As the gpio_chip handling is also only a few lines, the driver also
implements the gpio functionality directly through GPIOLIB.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 drivers/pinctrl/Makefile  |2 +-
 drivers/pinctrl/mediatek/Kconfig  |   10 +
 drivers/pinctrl/mediatek/Makefile |3 +-
 drivers/pinctrl/mediatek/pinctrl-mt7622.c | 1595 +
 4 files changed, 1608 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7622.c

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index d0d4844..c39aa482 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -64,5 +64,5 @@ obj-$(CONFIG_PINCTRL_SUNXI)   += sunxi/
 obj-y  += ti/
 obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
 obj-$(CONFIG_ARCH_VT8500)  += vt8500/
-obj-$(CONFIG_PINCTRL_MTK)  += mediatek/
+obj-y  += mediatek/
 obj-$(CONFIG_PINCTRL_ZX)   += zte/
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 03b3023..3e59874 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -32,6 +32,16 @@ config PINCTRL_MT8127
select PINCTRL_MTK
 
 # For ARMv8 SoCs
+config PINCTRL_MT7622
+   bool "MediaTek MT7622 pin control"
+   depends on OF
+   depends on ARM64 || COMPILE_TEST
+   select GENERIC_PINCONF
+   select GENERIC_PINCTRL_GROUPS
+   select GENERIC_PINMUX_FUNCTIONS
+   select GPIOLIB
+   select OF_GPIO
+
 config PINCTRL_MT8173
bool "Mediatek MT8173 pin control"
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index 10d9014..ed7d2b2 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -1,10 +1,11 @@
 # SPDX-License-Identifier: GPL-2.0
 # Core
-obj-y  += pinctrl-mtk-common.o
+obj-$(CONFIG_PINCTRL_MTK)  += pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
+obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
 obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
 obj-$(CONFIG_PINCTRL_MT6397)   += pinctrl-mt6397.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c 
b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
new file mode 100644
index 000..3824d82
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -0,0 +1,1595 @@
+/*
+ * MediaTek MT7622 Pinctrl Driver
+ *
+ * Copyright (C) 2017 Sean Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../core.h"
+#include "../pinconf.h"
+#include "../pinmux.h"
+
+#define PINCTRL_PINCTRL_DEVKBUILD_MODNAME
+#define MTK_RANGE(_a)  { .range = (_a), .nranges = ARRAY_SIZE(_a), }
+#define PINCTRL_PIN_GROUP(name, id)\
+   {   \
+   name,   \
+   id##_pins,  \
+   ARRAY_SIZE(id##_pins),  \
+   id##_funcs, \
+   }
+
+#define MTK_GPIO_MODE  1
+#define MTK_INPUT  0
+#define MTK_OUTPUT 1
+#define MTK_DISABLE0
+#define MTK_ENABLE 1
+
+/* Custom pinconf parameters */
+#define 

[PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu

[sean.wang]

From: Sean Wang 

Since lots of MediaTek drivers had been added, it seems slightly better
for that adding cleanup for placing MediaTek pinctrl drivers under the
independent menu as other kinds of drivers usually was done.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 drivers/pinctrl/mediatek/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index fac9866..03b3023 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -1,4 +1,5 @@
-if ARCH_MEDIATEK || COMPILE_TEST
+menu "MediaTek pinctrl drivers"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
 
 config PINCTRL_MTK
bool
@@ -46,4 +47,4 @@ config PINCTRL_MT6397
default MFD_MT6397
select PINCTRL_MTK
 
-endif
+endmenu
-- 
2.7.4

[PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC

[sean.wang]

From: Sean Wang 

Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has
the registers for pinctrl, pinconf and gpio mixed up in the same register
range. However, the IO core for the MT7622 SoC is completely distinct from
anyone of previous MediaTek SoCs which already had support, such as
the hardware internal, register address map and register detailed
definition for each pin.

Therefore, instead, the driver is being newly implemented by reusing
generic methods provided from the core layer with GENERIC_PINCONF,
GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
simplicity and rid of superfluous code. Where the function of pins
determined by groups is utilized in this driver which can help developers
less confused with what combinations of pins effective on the SoC and even
reducing the mistakes during the integration of those relevant boards.

As the gpio_chip handling is also only a few lines, the driver also
implements the gpio functionality directly through GPIOLIB.

Signed-off-by: Sean Wang 
Reviewed-by: Biao Huang 
---
 drivers/pinctrl/Makefile  |2 +-
 drivers/pinctrl/mediatek/Kconfig  |   10 +
 drivers/pinctrl/mediatek/Makefile |3 +-
 drivers/pinctrl/mediatek/pinctrl-mt7622.c | 1595 +
 4 files changed, 1608 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7622.c

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index d0d4844..c39aa482 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -64,5 +64,5 @@ obj-$(CONFIG_PINCTRL_SUNXI)   += sunxi/
 obj-y  += ti/
 obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
 obj-$(CONFIG_ARCH_VT8500)  += vt8500/
-obj-$(CONFIG_PINCTRL_MTK)  += mediatek/
+obj-y  += mediatek/
 obj-$(CONFIG_PINCTRL_ZX)   += zte/
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 03b3023..3e59874 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -32,6 +32,16 @@ config PINCTRL_MT8127
select PINCTRL_MTK
 
 # For ARMv8 SoCs
+config PINCTRL_MT7622
+   bool "MediaTek MT7622 pin control"
+   depends on OF
+   depends on ARM64 || COMPILE_TEST
+   select GENERIC_PINCONF
+   select GENERIC_PINCTRL_GROUPS
+   select GENERIC_PINMUX_FUNCTIONS
+   select GPIOLIB
+   select OF_GPIO
+
 config PINCTRL_MT8173
bool "Mediatek MT8173 pin control"
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index 10d9014..ed7d2b2 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -1,10 +1,11 @@
 # SPDX-License-Identifier: GPL-2.0
 # Core
-obj-y  += pinctrl-mtk-common.o
+obj-$(CONFIG_PINCTRL_MTK)  += pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
+obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
 obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
 obj-$(CONFIG_PINCTRL_MT6397)   += pinctrl-mt6397.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c 
b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
new file mode 100644
index 000..3824d82
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -0,0 +1,1595 @@
+/*
+ * MediaTek MT7622 Pinctrl Driver
+ *
+ * Copyright (C) 2017 Sean Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../core.h"
+#include "../pinconf.h"
+#include "../pinmux.h"
+
+#define PINCTRL_PINCTRL_DEVKBUILD_MODNAME
+#define MTK_RANGE(_a)  { .range = (_a), .nranges = ARRAY_SIZE(_a), }
+#define PINCTRL_PIN_GROUP(name, id)\
+   {   \
+   name,   \
+   id##_pins,  \
+   ARRAY_SIZE(id##_pins),  \
+   id##_funcs, \
+   }
+
+#define MTK_GPIO_MODE  1
+#define MTK_INPUT  0
+#define MTK_OUTPUT 1
+#define MTK_DISABLE0
+#define MTK_ENABLE 1
+
+/* Custom pinconf parameters */
+#define MTK_PIN_CONFIG_TDSEL   (PIN_CONFIG_END + 1)
+#define MTK_PIN_CONFIG_RDSEL   (PIN_CONFIG_END + 2)
+

Re: [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU

[Priit Laes]

On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes  wrote:
> > Convert sun4i-a10.dtsi to new CCU driver.
> >
> > Signed-off-by: Priit Laes 
> 
> I finally got around to bisecting a mainline boot failure on
> sun4i-a10-cubieboard that's been happening for quite a while.  Based
> on on kernelci.org, it showed up sometime during the v4.15 merge
> window[1].  It bisected down to this commit (in mainline as commit
> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
> 
> When it fails, there is no output on the serial console, so I don't
> know exactly how it's failing, just that it no longer boots.

Yeah, lack of output really looks like something gone wrong in clock setup,
though the commit itself has been sitting in tree for a while and the
same board has gotten actually bunch of features enabled after my clock
patches (drm modesetting + hdmi support).

I noticed that you're using GCC 5.3.1. Can you try with newer toolchain?

Priit

> 
> Kevin
> 
> [1] https://kernelci.org/boot/id/5a2e10cd59b51430a9afa173/
> 
> > ---
> >  arch/arm/boot/dts/sun4i-a10.dtsi | 636 
> >  1 file changed, 82 insertions(+), 554 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
> > b/arch/arm/boot/dts/sun4i-a10.dtsi
> > index ba20b48..0d8320a 100644
> > --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> > +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> > @@ -45,7 +45,8 @@
> >
> >  #include 
> >
> > -#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -65,9 +66,9 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_be0-lcd0-hdmi";
> > -   clocks = <_gates 36>, <_gates 43>,
> > -<_gates 44>, <_be0_clk>,
> > -<_ch1_clk>, <_gates 26>;
> > +   clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI1>,
> > +< CLK_AHB_DE_BE0>, < CLK_DE_BE0>,
> > +< CLK_TCON0_CH1>, < 
> > CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -75,10 +76,11 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0-hdmi";
> > -   clocks = <_gates 36>, <_gates 43>,
> > -<_gates 44>, <_gates 46>,
> > -<_be0_clk>, <_fe0_clk>, 
> > <_ch1_clk>,
> > -<_gates 25>, <_gates 26>;
> > +   clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI1>,
> > +< CLK_AHB_DE_BE0>, < 
> > CLK_AHB_DE_FE0>,
> > +< CLK_DE_BE0>, < CLK_DE_FE0>,
> > +< CLK_TCON0_CH1>,
> > +< CLK_DRAM_DE_FE0>, < 
> > CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -86,9 +88,10 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0";
> > -   clocks = <_gates 36>, <_gates 44>, 
> > <_gates 46>,
> > -<_be0_clk>, <_fe0_clk>, 
> > <_ch0_clk>,
> > -<_gates 25>, <_gates 26>;
> > +   clocks = < CLK_AHB_LCD0>, < CLK_AHB_DE_BE0>,
> > +< CLK_AHB_DE_FE0>, < CLK_DE_BE0>,
> > +< CLK_DE_FE0>, < CLK_TCON0_CH1>,
> > +< CLK_DRAM_DE_FE0>, < 
> > CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -96,11 +99,11 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
> > -   clocks = <_gates 34>, <_gates 36>,
> > -<_gates 44>, <_gates 46>,
> > -<_be0_clk>, <_fe0_clk>,
> > -<_ch1_clk>, <_gates 5>,
> > -<_gates 25>, <_gates 26>;
> > +   clocks = < CLK_AHB_TVE0>, < CLK_AHB_LCD0>,
> > +< CLK_AHB_DE_BE0>, < 
> > CLK_AHB_DE_FE0>,
> > +< CLK_DE_BE0>, < CLK_DE_FE0>,
> > +< CLK_TCON0_CH1>, < CLK_DRAM_TVE0>,
> > +< CLK_DRAM_DE_FE0>, < 
> > CLK_DRAM_DE_BE0>;
> >  

Re: [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU

[Priit Laes]

On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes  wrote:
> > Convert sun4i-a10.dtsi to new CCU driver.
> >
> > Signed-off-by: Priit Laes 
> 
> I finally got around to bisecting a mainline boot failure on
> sun4i-a10-cubieboard that's been happening for quite a while.  Based
> on on kernelci.org, it showed up sometime during the v4.15 merge
> window[1].  It bisected down to this commit (in mainline as commit
> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
> 
> When it fails, there is no output on the serial console, so I don't
> know exactly how it's failing, just that it no longer boots.

Yeah, lack of output really looks like something gone wrong in clock setup,
though the commit itself has been sitting in tree for a while and the
same board has gotten actually bunch of features enabled after my clock
patches (drm modesetting + hdmi support).

I noticed that you're using GCC 5.3.1. Can you try with newer toolchain?

Priit

> 
> Kevin
> 
> [1] https://kernelci.org/boot/id/5a2e10cd59b51430a9afa173/
> 
> > ---
> >  arch/arm/boot/dts/sun4i-a10.dtsi | 636 
> >  1 file changed, 82 insertions(+), 554 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
> > b/arch/arm/boot/dts/sun4i-a10.dtsi
> > index ba20b48..0d8320a 100644
> > --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> > +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> > @@ -45,7 +45,8 @@
> >
> >  #include 
> >
> > -#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -65,9 +66,9 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_be0-lcd0-hdmi";
> > -   clocks = <_gates 36>, <_gates 43>,
> > -<_gates 44>, <_be0_clk>,
> > -<_ch1_clk>, <_gates 26>;
> > +   clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI1>,
> > +< CLK_AHB_DE_BE0>, < CLK_DE_BE0>,
> > +< CLK_TCON0_CH1>, < 
> > CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -75,10 +76,11 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0-hdmi";
> > -   clocks = <_gates 36>, <_gates 43>,
> > -<_gates 44>, <_gates 46>,
> > -<_be0_clk>, <_fe0_clk>, 
> > <_ch1_clk>,
> > -<_gates 25>, <_gates 26>;
> > +   clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI1>,
> > +< CLK_AHB_DE_BE0>, < 
> > CLK_AHB_DE_FE0>,
> > +< CLK_DE_BE0>, < CLK_DE_FE0>,
> > +< CLK_TCON0_CH1>,
> > +< CLK_DRAM_DE_FE0>, < 
> > CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -86,9 +88,10 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0";
> > -   clocks = <_gates 36>, <_gates 44>, 
> > <_gates 46>,
> > -<_be0_clk>, <_fe0_clk>, 
> > <_ch0_clk>,
> > -<_gates 25>, <_gates 26>;
> > +   clocks = < CLK_AHB_LCD0>, < CLK_AHB_DE_BE0>,
> > +< CLK_AHB_DE_FE0>, < CLK_DE_BE0>,
> > +< CLK_DE_FE0>, < CLK_TCON0_CH1>,
> > +< CLK_DRAM_DE_FE0>, < 
> > CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -96,11 +99,11 @@
> > compatible = "allwinner,simple-framebuffer",
> >  "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
> > -   clocks = <_gates 34>, <_gates 36>,
> > -<_gates 44>, <_gates 46>,
> > -<_be0_clk>, <_fe0_clk>,
> > -<_ch1_clk>, <_gates 5>,
> > -<_gates 25>, <_gates 26>;
> > +   clocks = < CLK_AHB_TVE0>, < CLK_AHB_LCD0>,
> > +< CLK_AHB_DE_BE0>, < 
> > CLK_AHB_DE_FE0>,
> > +< CLK_DE_BE0>, < CLK_DE_FE0>,
> > +< CLK_TCON0_CH1>, < CLK_DRAM_TVE0>,
> > +< CLK_DRAM_DE_FE0>, < 
> > CLK_DRAM_DE_BE0>;
> > status = "disabled";
> >   

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

[Al Viro]

On Mon, Dec 11, 2017 at 08:02:24PM -0800, Jakub Kicinski wrote:
> On Mon, 11 Dec 2017 15:54:22 +, Al Viro wrote:
> > Essentially, it gives helpers for work with bitfields in fixed-endian.
> > Suppose we have e.g. a little-endian 32bit value with fixed layout;
> > expressing that as a bitfield would go like
> > struct foo {
> > unsigned foo:4; /* bits 0..3 */
> > unsigned :2;
> > unsigned bar:12;/* bits 6..17 */
> > unsigned baz:14;/* bits 18..31 */
> > }
> > Even for host-endian it doesn't work all that well - you end up with
> > ifdefs in structure definition and generated code stinks.  For fixed-endian
> > it gets really painful, and people tend to use explicit shift-and-mask
> > kind of macros for accessing the fields (and often enough get the
> > endianness conversions wrong, at that).  With these primitives
> > 
> > struct foo v<=> __le32 v
> > v.foo = i ? 1 : 2   <=> v = le32_replace_bits(v, i ? 1 : 2, 0, 4)
> > f(4 + v.baz)<=> f(4 + le32_get_bits(v, 18, 14))
> 
> Looks very useful.  The [start bit, size] pair may not land itself
> too nicely to creating defines, though.  Which is why in
> include/linux/bitfield.h we tried to use a shifted mask and work
> backwards from that single value what the start and size are.  commit
> 3e9b3112ec74 ("add basic register-field manipulation macros") has the
> description.  Could a similar trick perhaps be applicable here?

Umm...  What's wrong with

#define FIELD_FOO 0,4
#define FIELD_BAR 6,12
#define FIELD_BAZ 18,14

A macro can bloody well expand to any sequence of tokens - le32_get_bits(v, 
FIELD_BAZ)
will become le32_get_bits(v, 18, 14) just fine.  What's the problem with that?

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

[Al Viro]

On Mon, Dec 11, 2017 at 08:02:24PM -0800, Jakub Kicinski wrote:
> On Mon, 11 Dec 2017 15:54:22 +, Al Viro wrote:
> > Essentially, it gives helpers for work with bitfields in fixed-endian.
> > Suppose we have e.g. a little-endian 32bit value with fixed layout;
> > expressing that as a bitfield would go like
> > struct foo {
> > unsigned foo:4; /* bits 0..3 */
> > unsigned :2;
> > unsigned bar:12;/* bits 6..17 */
> > unsigned baz:14;/* bits 18..31 */
> > }
> > Even for host-endian it doesn't work all that well - you end up with
> > ifdefs in structure definition and generated code stinks.  For fixed-endian
> > it gets really painful, and people tend to use explicit shift-and-mask
> > kind of macros for accessing the fields (and often enough get the
> > endianness conversions wrong, at that).  With these primitives
> > 
> > struct foo v<=> __le32 v
> > v.foo = i ? 1 : 2   <=> v = le32_replace_bits(v, i ? 1 : 2, 0, 4)
> > f(4 + v.baz)<=> f(4 + le32_get_bits(v, 18, 14))
> 
> Looks very useful.  The [start bit, size] pair may not land itself
> too nicely to creating defines, though.  Which is why in
> include/linux/bitfield.h we tried to use a shifted mask and work
> backwards from that single value what the start and size are.  commit
> 3e9b3112ec74 ("add basic register-field manipulation macros") has the
> description.  Could a similar trick perhaps be applicable here?

Umm...  What's wrong with

#define FIELD_FOO 0,4
#define FIELD_BAR 6,12
#define FIELD_BAZ 18,14

A macro can bloody well expand to any sequence of tokens - le32_get_bits(v, 
FIELD_BAZ)
will become le32_get_bits(v, 18, 14) just fine.  What's the problem with that?

[PATCH v5 0/8] omap: dmtimer: Move driver out of plat-omap

[Keerthy]

The series moves dmtimer out of plat-omap to drivers/clocksource.
The series also does a bunch of changes to pwm-omap-dmtimer code
to adapt to the driver migration and clean up plat specific
pdata-quirks and use the dmtimer platform data.

Boot tested on DRA7-EVM and AM437X-GP-EVM.
Compile tested omap1_defconfig.

This is based on top of linux-next branch.

Changes from v4:

  * Made OMAP_DM_TIMER config option silent.
  * Changed the driver name to timer-dm.c

Changes from v3:

  * Reverted to v2 approach of using dev_get_platdata to fetch dmtimer ops.

Changes from V2:

  * Wrapped the inline functions in header file under OMAP2PLUS
  * Added a new of helper function to fetch plat_data from of node.

Keerthy (8):
  clocksource: dmtimer: Remove all the exports
  arm: omap: timer: Wrap the inline functions under OMAP2PLUS define
  arm: omap: Move dmtimer.h out of plat-omap
  arm: OMAP: Move dmtimer driver out of plat-omap to drivers under
clocksource
  dmtimer: Add timer ops to the platform data structure
  clocksource: dmtimer: Populate the timer ops to the pdata
  pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
  arm: omap: pdata-quirks: Remove unused timer pdata

 arch/arm/mach-omap1/pm.c   |  2 +-
 arch/arm/mach-omap1/timer.c|  2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c |  2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 32 -
 arch/arm/mach-omap2/timer.c|  2 +-
 arch/arm/plat-omap/Kconfig |  6 ---
 arch/arm/plat-omap/Makefile|  1 -
 drivers/clocksource/Kconfig|  3 ++
 drivers/clocksource/Makefile   |  1 +
 .../dmtimer.c => drivers/clocksource/timer-dm.c| 54 +++---
 drivers/pwm/pwm-omap-dmtimer.c | 39 +---
 .../include/plat => include/clocksource}/dmtimer.h |  8 +++-
 include/linux/platform_data/dmtimer-omap.h | 38 +++
 20 files changed, 108 insertions(+), 96 deletions(-)
 rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (95%)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h (97%)

-- 
1.9.1

[PATCH v5 0/8] omap: dmtimer: Move driver out of plat-omap

[Keerthy]

The series moves dmtimer out of plat-omap to drivers/clocksource.
The series also does a bunch of changes to pwm-omap-dmtimer code
to adapt to the driver migration and clean up plat specific
pdata-quirks and use the dmtimer platform data.

Boot tested on DRA7-EVM and AM437X-GP-EVM.
Compile tested omap1_defconfig.

This is based on top of linux-next branch.

Changes from v4:

  * Made OMAP_DM_TIMER config option silent.
  * Changed the driver name to timer-dm.c

Changes from v3:

  * Reverted to v2 approach of using dev_get_platdata to fetch dmtimer ops.

Changes from V2:

  * Wrapped the inline functions in header file under OMAP2PLUS
  * Added a new of helper function to fetch plat_data from of node.

Keerthy (8):
  clocksource: dmtimer: Remove all the exports
  arm: omap: timer: Wrap the inline functions under OMAP2PLUS define
  arm: omap: Move dmtimer.h out of plat-omap
  arm: OMAP: Move dmtimer driver out of plat-omap to drivers under
clocksource
  dmtimer: Add timer ops to the platform data structure
  clocksource: dmtimer: Populate the timer ops to the pdata
  pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
  arm: omap: pdata-quirks: Remove unused timer pdata

 arch/arm/mach-omap1/pm.c   |  2 +-
 arch/arm/mach-omap1/timer.c|  2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c |  2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 32 -
 arch/arm/mach-omap2/timer.c|  2 +-
 arch/arm/plat-omap/Kconfig |  6 ---
 arch/arm/plat-omap/Makefile|  1 -
 drivers/clocksource/Kconfig|  3 ++
 drivers/clocksource/Makefile   |  1 +
 .../dmtimer.c => drivers/clocksource/timer-dm.c| 54 +++---
 drivers/pwm/pwm-omap-dmtimer.c | 39 +---
 .../include/plat => include/clocksource}/dmtimer.h |  8 +++-
 include/linux/platform_data/dmtimer-omap.h | 38 +++
 20 files changed, 108 insertions(+), 96 deletions(-)
 rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (95%)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h (97%)

-- 
1.9.1

[PATCH v5 5/8] dmtimer: Add timer ops to the platform data structure

[Keerthy]

Add timer ops to the platform data structure

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---

Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 include/linux/platform_data/dmtimer-omap.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/linux/platform_data/dmtimer-omap.h 
b/include/linux/platform_data/dmtimer-omap.h
index a19b78d..a3e1794 100644
--- a/include/linux/platform_data/dmtimer-omap.h
+++ b/include/linux/platform_data/dmtimer-omap.h
@@ -20,12 +20,50 @@
 #ifndef __PLATFORM_DATA_DMTIMER_OMAP_H__
 #define __PLATFORM_DATA_DMTIMER_OMAP_H__
 
+struct omap_dm_timer_ops {
+   struct omap_dm_timer *(*request_by_node)(struct device_node *np);
+   struct omap_dm_timer *(*request_specific)(int timer_id);
+   struct omap_dm_timer *(*request)(void);
+
+   int (*free)(struct omap_dm_timer *timer);
+
+   void(*enable)(struct omap_dm_timer *timer);
+   void(*disable)(struct omap_dm_timer *timer);
+
+   int (*get_irq)(struct omap_dm_timer *timer);
+   int (*set_int_enable)(struct omap_dm_timer *timer,
+ unsigned int value);
+   int (*set_int_disable)(struct omap_dm_timer *timer, u32 mask);
+
+   struct clk *(*get_fclk)(struct omap_dm_timer *timer);
+
+   int (*start)(struct omap_dm_timer *timer);
+   int (*stop)(struct omap_dm_timer *timer);
+   int (*set_source)(struct omap_dm_timer *timer, int source);
+
+   int (*set_load)(struct omap_dm_timer *timer, int autoreload,
+   unsigned int value);
+   int (*set_match)(struct omap_dm_timer *timer, int enable,
+unsigned int match);
+   int (*set_pwm)(struct omap_dm_timer *timer, int def_on,
+  int toggle, int trigger);
+   int (*set_prescaler)(struct omap_dm_timer *timer, int prescaler);
+
+   unsigned int (*read_counter)(struct omap_dm_timer *timer);
+   int (*write_counter)(struct omap_dm_timer *timer,
+unsigned int value);
+   unsigned int (*read_status)(struct omap_dm_timer *timer);
+   int (*write_status)(struct omap_dm_timer *timer,
+   unsigned int value);
+};
+
 struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
u32 timer_errata;
int (*get_context_loss_count)(struct device *);
+   struct omap_dm_timer_ops *timer_ops;
 };
 
 #endif /* __PLATFORM_DATA_DMTIMER_OMAP_H__ */
-- 
1.9.1

[PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

[Keerthy]

Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.

Signed-off-by: Keerthy 
---

Changes in v4:

  * Switched to dev_get_platdata.

Changes in v3:

  * Used of_find_platdata_by_node function to fetch platform
data for timer node.

 drivers/pwm/pwm-omap-dmtimer.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 5ad42f3..3b27aff 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,7 +38,7 @@ struct pwm_omap_dmtimer_chip {
struct pwm_chip chip;
struct mutex mutex;
pwm_omap_dmtimer *dm_timer;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct omap_dm_timer_ops *pdata;
struct platform_device *dm_timer_pdev;
 };
 
@@ -242,19 +243,33 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
 {
struct device_node *np = pdev->dev.of_node;
struct device_node *timer;
+   struct platform_device *timer_pdev;
struct pwm_omap_dmtimer_chip *omap;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct dmtimer_platform_data *timer_pdata;
+   struct omap_dm_timer_ops *pdata;
pwm_omap_dmtimer *dm_timer;
u32 v;
int status;
 
-   pdata = dev_get_platdata(>dev);
-   if (!pdata) {
-   dev_err(>dev, "Missing dmtimer platform data\n");
+   timer = of_parse_phandle(np, "ti,timers", 0);
+   if (!timer)
+   return -ENODEV;
+
+   timer_pdev = of_find_device_by_node(timer);
+   if (!timer_pdev) {
+   dev_err(>dev, "Unable to find Timer pdev\n");
+   return -ENODEV;
+   }
+
+   timer_pdata = dev_get_platdata(_pdev->dev);
+   if (!timer_pdata) {
+   dev_err(>dev, "dmtimer pdata structure NULL\n");
return -EINVAL;
}
 
-   if (!pdata->request_by_node ||
+   pdata = timer_pdata->timer_ops;
+
+   if (!pdata || !pdata->request_by_node ||
!pdata->free ||
!pdata->enable ||
!pdata->disable ||
@@ -270,10 +285,6 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   timer = of_parse_phandle(np, "ti,timers", 0);
-   if (!timer)
-   return -ENODEV;
-
if (!of_get_property(timer, "ti,timer-pwm", NULL)) {
dev_err(>dev, "Missing ti,timer-pwm capability\n");
return -ENODEV;
@@ -291,13 +302,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
 
omap->pdata = pdata;
omap->dm_timer = dm_timer;
-
-   omap->dm_timer_pdev = of_find_device_by_node(timer);
-   if (!omap->dm_timer_pdev) {
-   dev_err(>dev, "Unable to find timer pdev\n");
-   omap->pdata->free(dm_timer);
-   return -EINVAL;
-   }
+   omap->dm_timer_pdev = timer_pdev;
 
/*
 * Ensure that the timer is stopped before we allow PWM core to call
-- 
1.9.1

[PATCH v5 5/8] dmtimer: Add timer ops to the platform data structure

[Keerthy]

Add timer ops to the platform data structure

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---

Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 include/linux/platform_data/dmtimer-omap.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/linux/platform_data/dmtimer-omap.h 
b/include/linux/platform_data/dmtimer-omap.h
index a19b78d..a3e1794 100644
--- a/include/linux/platform_data/dmtimer-omap.h
+++ b/include/linux/platform_data/dmtimer-omap.h
@@ -20,12 +20,50 @@
 #ifndef __PLATFORM_DATA_DMTIMER_OMAP_H__
 #define __PLATFORM_DATA_DMTIMER_OMAP_H__
 
+struct omap_dm_timer_ops {
+   struct omap_dm_timer *(*request_by_node)(struct device_node *np);
+   struct omap_dm_timer *(*request_specific)(int timer_id);
+   struct omap_dm_timer *(*request)(void);
+
+   int (*free)(struct omap_dm_timer *timer);
+
+   void(*enable)(struct omap_dm_timer *timer);
+   void(*disable)(struct omap_dm_timer *timer);
+
+   int (*get_irq)(struct omap_dm_timer *timer);
+   int (*set_int_enable)(struct omap_dm_timer *timer,
+ unsigned int value);
+   int (*set_int_disable)(struct omap_dm_timer *timer, u32 mask);
+
+   struct clk *(*get_fclk)(struct omap_dm_timer *timer);
+
+   int (*start)(struct omap_dm_timer *timer);
+   int (*stop)(struct omap_dm_timer *timer);
+   int (*set_source)(struct omap_dm_timer *timer, int source);
+
+   int (*set_load)(struct omap_dm_timer *timer, int autoreload,
+   unsigned int value);
+   int (*set_match)(struct omap_dm_timer *timer, int enable,
+unsigned int match);
+   int (*set_pwm)(struct omap_dm_timer *timer, int def_on,
+  int toggle, int trigger);
+   int (*set_prescaler)(struct omap_dm_timer *timer, int prescaler);
+
+   unsigned int (*read_counter)(struct omap_dm_timer *timer);
+   int (*write_counter)(struct omap_dm_timer *timer,
+unsigned int value);
+   unsigned int (*read_status)(struct omap_dm_timer *timer);
+   int (*write_status)(struct omap_dm_timer *timer,
+   unsigned int value);
+};
+
 struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
u32 timer_errata;
int (*get_context_loss_count)(struct device *);
+   struct omap_dm_timer_ops *timer_ops;
 };
 
 #endif /* __PLATFORM_DATA_DMTIMER_OMAP_H__ */
-- 
1.9.1

[PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

[Keerthy]

Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.

Signed-off-by: Keerthy 
---

Changes in v4:

  * Switched to dev_get_platdata.

Changes in v3:

  * Used of_find_platdata_by_node function to fetch platform
data for timer node.

 drivers/pwm/pwm-omap-dmtimer.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 5ad42f3..3b27aff 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,7 +38,7 @@ struct pwm_omap_dmtimer_chip {
struct pwm_chip chip;
struct mutex mutex;
pwm_omap_dmtimer *dm_timer;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct omap_dm_timer_ops *pdata;
struct platform_device *dm_timer_pdev;
 };
 
@@ -242,19 +243,33 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
 {
struct device_node *np = pdev->dev.of_node;
struct device_node *timer;
+   struct platform_device *timer_pdev;
struct pwm_omap_dmtimer_chip *omap;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct dmtimer_platform_data *timer_pdata;
+   struct omap_dm_timer_ops *pdata;
pwm_omap_dmtimer *dm_timer;
u32 v;
int status;
 
-   pdata = dev_get_platdata(>dev);
-   if (!pdata) {
-   dev_err(>dev, "Missing dmtimer platform data\n");
+   timer = of_parse_phandle(np, "ti,timers", 0);
+   if (!timer)
+   return -ENODEV;
+
+   timer_pdev = of_find_device_by_node(timer);
+   if (!timer_pdev) {
+   dev_err(>dev, "Unable to find Timer pdev\n");
+   return -ENODEV;
+   }
+
+   timer_pdata = dev_get_platdata(_pdev->dev);
+   if (!timer_pdata) {
+   dev_err(>dev, "dmtimer pdata structure NULL\n");
return -EINVAL;
}
 
-   if (!pdata->request_by_node ||
+   pdata = timer_pdata->timer_ops;
+
+   if (!pdata || !pdata->request_by_node ||
!pdata->free ||
!pdata->enable ||
!pdata->disable ||
@@ -270,10 +285,6 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   timer = of_parse_phandle(np, "ti,timers", 0);
-   if (!timer)
-   return -ENODEV;
-
if (!of_get_property(timer, "ti,timer-pwm", NULL)) {
dev_err(>dev, "Missing ti,timer-pwm capability\n");
return -ENODEV;
@@ -291,13 +302,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
 
omap->pdata = pdata;
omap->dm_timer = dm_timer;
-
-   omap->dm_timer_pdev = of_find_device_by_node(timer);
-   if (!omap->dm_timer_pdev) {
-   dev_err(>dev, "Unable to find timer pdev\n");
-   omap->pdata->free(dm_timer);
-   return -EINVAL;
-   }
+   omap->dm_timer_pdev = timer_pdev;
 
/*
 * Ensure that the timer is stopped before we allow PWM core to call
-- 
1.9.1

[PATCH v5 8/8] arm: omap: pdata-quirks: Remove unused timer pdata

[Keerthy]

Remove unused timer pdata.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---

Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 arch/arm/mach-omap2/pdata-quirks.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ad9df86..e7d7fc7 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,10 +24,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 #include "common.h"
 #include "common-board-devices.h"
@@ -477,33 +475,6 @@ void omap_auxdata_legacy_init(struct device *dev)
dev->platform_data = _gpio_auxdata;
 }
 
-/* Dual mode timer PWM callbacks platdata */
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
-   .request_by_node = omap_dm_timer_request_by_node,
-   .request_specific = omap_dm_timer_request_specific,
-   .request = omap_dm_timer_request,
-   .set_source = omap_dm_timer_set_source,
-   .get_irq = omap_dm_timer_get_irq,
-   .set_int_enable = omap_dm_timer_set_int_enable,
-   .set_int_disable = omap_dm_timer_set_int_disable,
-   .free = omap_dm_timer_free,
-   .enable = omap_dm_timer_enable,
-   .disable = omap_dm_timer_disable,
-   .get_fclk = omap_dm_timer_get_fclk,
-   .start = omap_dm_timer_start,
-   .stop = omap_dm_timer_stop,
-   .set_load = omap_dm_timer_set_load,
-   .set_match = omap_dm_timer_set_match,
-   .set_pwm = omap_dm_timer_set_pwm,
-   .set_prescaler = omap_dm_timer_set_prescaler,
-   .read_counter = omap_dm_timer_read_counter,
-   .write_counter = omap_dm_timer_write_counter,
-   .read_status = omap_dm_timer_read_status,
-   .write_status = omap_dm_timer_write_status,
-};
-#endif
-
 static struct ir_rx51_platform_data __maybe_unused rx51_ir_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
 };
@@ -572,9 +543,6 @@ static void __init omap3_mcbsp_init(void) {}
OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d0, "44d0.wkup_m3",
   _m3_data),
 #endif
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-   OF_DEV_AUXDATA("ti,omap-dmtimer-pwm", 0, NULL, _dmtimer_pdata),
-#endif
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
   _iommu_pdata),
-- 
1.9.1

[PATCH v5 8/8] arm: omap: pdata-quirks: Remove unused timer pdata

[Keerthy]

Remove unused timer pdata.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---

Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 arch/arm/mach-omap2/pdata-quirks.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ad9df86..e7d7fc7 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,10 +24,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 #include "common.h"
 #include "common-board-devices.h"
@@ -477,33 +475,6 @@ void omap_auxdata_legacy_init(struct device *dev)
dev->platform_data = _gpio_auxdata;
 }
 
-/* Dual mode timer PWM callbacks platdata */
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
-   .request_by_node = omap_dm_timer_request_by_node,
-   .request_specific = omap_dm_timer_request_specific,
-   .request = omap_dm_timer_request,
-   .set_source = omap_dm_timer_set_source,
-   .get_irq = omap_dm_timer_get_irq,
-   .set_int_enable = omap_dm_timer_set_int_enable,
-   .set_int_disable = omap_dm_timer_set_int_disable,
-   .free = omap_dm_timer_free,
-   .enable = omap_dm_timer_enable,
-   .disable = omap_dm_timer_disable,
-   .get_fclk = omap_dm_timer_get_fclk,
-   .start = omap_dm_timer_start,
-   .stop = omap_dm_timer_stop,
-   .set_load = omap_dm_timer_set_load,
-   .set_match = omap_dm_timer_set_match,
-   .set_pwm = omap_dm_timer_set_pwm,
-   .set_prescaler = omap_dm_timer_set_prescaler,
-   .read_counter = omap_dm_timer_read_counter,
-   .write_counter = omap_dm_timer_write_counter,
-   .read_status = omap_dm_timer_read_status,
-   .write_status = omap_dm_timer_write_status,
-};
-#endif
-
 static struct ir_rx51_platform_data __maybe_unused rx51_ir_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
 };
@@ -572,9 +543,6 @@ static void __init omap3_mcbsp_init(void) {}
OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d0, "44d0.wkup_m3",
   _m3_data),
 #endif
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-   OF_DEV_AUXDATA("ti,omap-dmtimer-pwm", 0, NULL, _dmtimer_pdata),
-#endif
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
   _iommu_pdata),
-- 
1.9.1

[PATCH v5 1/8] clocksource: dmtimer: Remove all the exports

[Keerthy]

Remove all the unwanted exports from the driver

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---
Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 arch/arm/plat-omap/dmtimer.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d443e48..72565fc 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
 {
return _omap_dm_timer_request(REQUEST_ANY, NULL);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request);
 
 struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 {
@@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 
return _omap_dm_timer_request(REQUEST_BY_ID, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
 
 /**
  * omap_dm_timer_request_by_cap - Request a timer by capability
@@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
 {
return _omap_dm_timer_request(REQUEST_BY_CAP, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
 
 /**
  * omap_dm_timer_request_by_node - Request a timer by device-tree node
@@ -346,7 +343,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_node(struct 
device_node *np)
 
return _omap_dm_timer_request(REQUEST_BY_NODE, np);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
 
 int omap_dm_timer_free(struct omap_dm_timer *timer)
 {
@@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
timer->reserved = 0;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_free);
 
 void omap_dm_timer_enable(struct omap_dm_timer *timer)
 {
@@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
}
}
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
 
 void omap_dm_timer_disable(struct omap_dm_timer *timer)
 {
pm_runtime_put_sync(>pdev->dev);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
 
 int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
 {
@@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
return timer->irq;
return -EINVAL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
 
 #if defined(CONFIG_ARCH_OMAP1)
 #include 
@@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return inputmask;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #else
 
@@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
*timer)
return timer->fclk;
return NULL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
 
 __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 {
@@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #endif
 
@@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
 
 int omap_dm_timer_start(struct omap_dm_timer *timer)
 {
@@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
timer->context.tclr = l;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_start);
 
 int omap_dm_timer_stop(struct omap_dm_timer *timer)
 {
@@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
 
 int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
 {
@@ -569,7 +555,6 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
int source)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
 
 int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
unsigned int load)
@@ -595,7 +580,6 @@ int omap_dm_timer_set_load(struct omap_dm_timer *timer, int 
autoreload,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load);
 
 /* Optimized set_load which removes costly spin wait in timer_start */
 int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
@@ -625,7 +609,6 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer 
*timer, int autoreload,
timer->context.tcrr = load;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load_start);
 
 int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
 unsigned int match)
@@ -650,7 +633,6 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, 
int enable,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_match);
 
 int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int 

[PATCH v5 1/8] clocksource: dmtimer: Remove all the exports

[Keerthy]

Remove all the unwanted exports from the driver

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---
Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 arch/arm/plat-omap/dmtimer.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d443e48..72565fc 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
 {
return _omap_dm_timer_request(REQUEST_ANY, NULL);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request);
 
 struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 {
@@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 
return _omap_dm_timer_request(REQUEST_BY_ID, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
 
 /**
  * omap_dm_timer_request_by_cap - Request a timer by capability
@@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
 {
return _omap_dm_timer_request(REQUEST_BY_CAP, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
 
 /**
  * omap_dm_timer_request_by_node - Request a timer by device-tree node
@@ -346,7 +343,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_node(struct 
device_node *np)
 
return _omap_dm_timer_request(REQUEST_BY_NODE, np);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
 
 int omap_dm_timer_free(struct omap_dm_timer *timer)
 {
@@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
timer->reserved = 0;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_free);
 
 void omap_dm_timer_enable(struct omap_dm_timer *timer)
 {
@@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
}
}
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
 
 void omap_dm_timer_disable(struct omap_dm_timer *timer)
 {
pm_runtime_put_sync(>pdev->dev);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
 
 int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
 {
@@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
return timer->irq;
return -EINVAL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
 
 #if defined(CONFIG_ARCH_OMAP1)
 #include 
@@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return inputmask;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #else
 
@@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
*timer)
return timer->fclk;
return NULL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
 
 __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 {
@@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #endif
 
@@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
 
 int omap_dm_timer_start(struct omap_dm_timer *timer)
 {
@@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
timer->context.tclr = l;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_start);
 
 int omap_dm_timer_stop(struct omap_dm_timer *timer)
 {
@@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
 
 int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
 {
@@ -569,7 +555,6 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
int source)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
 
 int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
unsigned int load)
@@ -595,7 +580,6 @@ int omap_dm_timer_set_load(struct omap_dm_timer *timer, int 
autoreload,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load);
 
 /* Optimized set_load which removes costly spin wait in timer_start */
 int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
@@ -625,7 +609,6 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer 
*timer, int autoreload,
timer->context.tcrr = load;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load_start);
 
 int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
 unsigned int match)
@@ -650,7 +633,6 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, 
int enable,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_match);
 
 int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
   int toggle, int trigger)

[PATCH v5 3/8] arm: omap: Move dmtimer.h out of plat-omap

[Keerthy]

The header file is currently under plat-omap directory
under arch/omap. Move this out to an accessible place.

No Code changes done to the header file.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---
Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 arch/arm/mach-omap1/pm.c   | 2 +-
 arch/arm/mach-omap1/timer.c| 2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 2 +-
 arch/arm/mach-omap2/timer.c| 2 +-
 arch/arm/plat-omap/dmtimer.c   | 2 +-
 {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h | 0
 14 files changed, 13 insertions(+), 13 deletions(-)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h 
(100%)

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index f1135bf..a07d47cf 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 8fb1ec6..7c057ab 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "soc.h"
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 1a15a34..45c1043 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 3801850..892ca58 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index beec4cd..82b51c0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -11,7 +11,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 52c9d58..310aef5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -25,7 +25,7 @@
 #include "l4_3xxx.h"
 #include 
 #include 
-#include 
+#include 
 
 #include "soc.h"
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c477096..22e0e38 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 988e7ea..530334e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index d05e553d..adabdef 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 77a515b..d05dd2d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 #include "cm81xx.h"
diff --git 

[PATCH v5 3/8] arm: omap: Move dmtimer.h out of plat-omap

[Keerthy]

The header file is currently under plat-omap directory
under arch/omap. Move this out to an accessible place.

No Code changes done to the header file.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---
Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 arch/arm/mach-omap1/pm.c   | 2 +-
 arch/arm/mach-omap1/timer.c| 2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 2 +-
 arch/arm/mach-omap2/timer.c| 2 +-
 arch/arm/plat-omap/dmtimer.c   | 2 +-
 {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h | 0
 14 files changed, 13 insertions(+), 13 deletions(-)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h 
(100%)

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index f1135bf..a07d47cf 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 8fb1ec6..7c057ab 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "soc.h"
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 1a15a34..45c1043 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 3801850..892ca58 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index beec4cd..82b51c0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -11,7 +11,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 52c9d58..310aef5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -25,7 +25,7 @@
 #include "l4_3xxx.h"
 #include 
 #include 
-#include 
+#include 
 
 #include "soc.h"
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c477096..22e0e38 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 988e7ea..530334e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index d05e553d..adabdef 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 77a515b..d05dd2d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 #include "cm81xx.h"
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 

[PATCH v5 6/8] clocksource: dmtimer: Populate the timer ops to the pdata

[Keerthy]

Add the timer ops to the platform data

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---

Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.

 drivers/clocksource/timer-dm.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index afe1dc9..1cbd954 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -922,8 +922,33 @@ static int omap_dm_timer_remove(struct platform_device 
*pdev)
return ret;
 }
 
+static struct omap_dm_timer_ops dmtimer_ops = {
+   .request_by_node = omap_dm_timer_request_by_node,
+   .request_specific = omap_dm_timer_request_specific,
+   .request = omap_dm_timer_request,
+   .set_source = omap_dm_timer_set_source,
+   .get_irq = omap_dm_timer_get_irq,
+   .set_int_enable = omap_dm_timer_set_int_enable,
+   .set_int_disable = omap_dm_timer_set_int_disable,
+   .free = omap_dm_timer_free,
+   .enable = omap_dm_timer_enable,
+   .disable = omap_dm_timer_disable,
+   .get_fclk = omap_dm_timer_get_fclk,
+   .start = omap_dm_timer_start,
+   .stop = omap_dm_timer_stop,
+   .set_load = omap_dm_timer_set_load,
+   .set_match = omap_dm_timer_set_match,
+   .set_pwm = omap_dm_timer_set_pwm,
+   .set_prescaler = omap_dm_timer_set_prescaler,
+   .read_counter = omap_dm_timer_read_counter,
+   .write_counter = omap_dm_timer_write_counter,
+   .read_status = omap_dm_timer_read_status,
+   .write_status = omap_dm_timer_write_status,
+};
+
 static const struct dmtimer_platform_data omap3plus_pdata = {
.timer_errata = OMAP_TIMER_ERRATA_I103_I767,
+   .timer_ops = _ops,
 };
 
 static const struct of_device_id omap_timer_match[] = {
-- 
1.9.1

[PATCH v5 4/8] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource

[Keerthy]

Move the dmtimer driver out of plat-omap to clocksource.
So that non-omap devices also could use this.

No Code changes done to the driver file only renamed to timer-dm.c.
Also removed the config dependencies for OMAP_DM_TIMER.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
---

Changes in v5:

  * Made OMAP_DM_TIMER config option silent.
  * Changed the driver name to timer-dm.c

Changes in v3:

  * Added Sebastian's Reviewed-by.

Changes in v2:

  * No code changes in this v2 version. Only enhanced patch
statistics for renames.
 arch/arm/plat-omap/Kconfig | 6 --
 arch/arm/plat-omap/Makefile| 1 -
 drivers/clocksource/Kconfig| 3 +++
 drivers/clocksource/Makefile   | 1 +
 arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c | 0
 5 files changed, 4 insertions(+), 7 deletions(-)
 rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (100%)

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 7276afe..afc1a1d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -106,12 +106,6 @@ config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
help
  PPA routine service ID for setting L2 auxiliary control register.
 
-config OMAP_DM_TIMER
-   bool "Use dual-mode timer"
-   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
-   help
-Select this option if you want to use OMAP Dual-Mode timers.
-
 config OMAP_SERIAL_WAKE
bool "Enable wake-up events for serial ports"
depends on ARCH_OMAP1 && OMAP_MUX
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 47e1867..7215ada 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -9,5 +9,4 @@ obj-y := sram.o dma.o counter_32k.o
 
 # omap_device support (OMAP2+ only at the moment)
 
-obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
 obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index c729a88..3f799b2 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -21,6 +21,9 @@ config CLKEVT_I8253
 config I8253_LOCK
bool
 
+config OMAP_DM_TIMER
+   bool
+
 config CLKBLD_I8253
def_bool y if CLKSRC_I8253 || CLKEVT_I8253 || I8253_LOCK
 
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 72711f1..27b5497 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_EM_TIMER_STI)+= em_sti.o
 obj-$(CONFIG_CLKBLD_I8253) += i8253.o
 obj-$(CONFIG_CLKSRC_MMIO)  += mmio.o
 obj-$(CONFIG_DIGICOLOR_TIMER)  += timer-digicolor.o
+obj-$(CONFIG_OMAP_DM_TIMER)+= timer-dm.o
 obj-$(CONFIG_DW_APB_TIMER) += dw_apb_timer.o
 obj-$(CONFIG_DW_APB_TIMER_OF)  += dw_apb_timer_of.o
 obj-$(CONFIG_FTTMR010_TIMER)   += timer-fttmr010.o
diff --git a/arch/arm/plat-omap/dmtimer.c b/drivers/clocksource/timer-dm.c
similarity index 100%
rename from arch/arm/plat-omap/dmtimer.c
rename to drivers/clocksource/timer-dm.c
-- 
1.9.1