[PATCH 1/12 v2] switchtec: Remove immediate status check after submit a MRPC command

2018-09-26 Thread Wesley.Sheng
After submit a Firmware Download (Download sub-command) MRPC
command, Switchtec firmware refuses to response any management 
EP's BAR access until current flash programming finished.
During this time, a READ TLP to the gas area in the BAR of the
management EP will complete with significant delay like more than 
10ms.
It's a Switchtec firmware limitation that READ requests cannot get
prompt service during firmware download.
The delayed completion of READ TLP would be a problem on some system
 which is sensitive to READ timeout.
Current driver check status immediately after submit a MRPC command,
which triggers READ TLP to the gas area in the BAR of the management EP.
Also, other processes or functions, like NTB, would also trigger READ TLP by
accessing the GAS.
To avoid this, the immediate check of status is removed in this patch, and
driver delays the status check to the occurrence of MSIx or MRPC timeout.
In the meantime, user must not initiate any gas access during a firmware
download.
Also, any process that issues MRPC command will be affected by the delay
in this patch.
However, this is only a software workaround to the READ issue in firmware
download. A complete fix of this should happen in firmware.

Note: For NTB function, the memory window access is handled by Switchtec
hardware. So it's not affected by this firmware limitation. But the other GAS
access which is handled by Switchtec firmware is are affected by this firmware
limitation.

Signed-off-by: Kelvin Cao 
Signed-off-by: Wesley Sheng 

---
 drivers/pci/switch/switchtec.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c 
index 4591f15..b759228 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -142,10 +142,6 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev)
stuser->data, stuser->data_len);
iowrite32(stuser->cmd, >mmio_mrpc->cmd);
 
-   stuser->status = ioread32(>mmio_mrpc->status);
-   if (stuser->status != SWITCHTEC_MRPC_STATUS_INPROGRESS)
-   mrpc_complete_cmd(stdev);
-
schedule_delayed_work(>mrpc_timeout,
  msecs_to_jiffies(500));
 }
--
2.7.4


[PATCH 1/12 v2] switchtec: Remove immediate status check after submit a MRPC command

2018-09-26 Thread Wesley.Sheng
After submit a Firmware Download (Download sub-command) MRPC
command, Switchtec firmware refuses to response any management 
EP's BAR access until current flash programming finished.
During this time, a READ TLP to the gas area in the BAR of the
management EP will complete with significant delay like more than 
10ms.
It's a Switchtec firmware limitation that READ requests cannot get
prompt service during firmware download.
The delayed completion of READ TLP would be a problem on some system
 which is sensitive to READ timeout.
Current driver check status immediately after submit a MRPC command,
which triggers READ TLP to the gas area in the BAR of the management EP.
Also, other processes or functions, like NTB, would also trigger READ TLP by
accessing the GAS.
To avoid this, the immediate check of status is removed in this patch, and
driver delays the status check to the occurrence of MSIx or MRPC timeout.
In the meantime, user must not initiate any gas access during a firmware
download.
Also, any process that issues MRPC command will be affected by the delay
in this patch.
However, this is only a software workaround to the READ issue in firmware
download. A complete fix of this should happen in firmware.

Note: For NTB function, the memory window access is handled by Switchtec
hardware. So it's not affected by this firmware limitation. But the other GAS
access which is handled by Switchtec firmware is are affected by this firmware
limitation.

Signed-off-by: Kelvin Cao 
Signed-off-by: Wesley Sheng 

---
 drivers/pci/switch/switchtec.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c 
index 4591f15..b759228 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -142,10 +142,6 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev)
stuser->data, stuser->data_len);
iowrite32(stuser->cmd, >mmio_mrpc->cmd);
 
-   stuser->status = ioread32(>mmio_mrpc->status);
-   if (stuser->status != SWITCHTEC_MRPC_STATUS_INPROGRESS)
-   mrpc_complete_cmd(stdev);
-
schedule_delayed_work(>mrpc_timeout,
  msecs_to_jiffies(500));
 }
--
2.7.4


(sin asunto)

2018-09-26 Thread Mrs. Mavis Wanczyk




--
Good Day,

I, Mavis Wanczyk donates $ 5 Million Dollars to you, from part of my 
Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details for 
claims.


I await your earliest response and God Bless you.

Good luck,
Mavis Wanczyk.


(sin asunto)

2018-09-26 Thread Mrs. Mavis Wanczyk




--
Good Day,

I, Mavis Wanczyk donates $ 5 Million Dollars to you, from part of my 
Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details for 
claims.


I await your earliest response and God Bless you.

Good luck,
Mavis Wanczyk.


Re: [PATCH] Raise maximum number of memory controllers

2018-09-26 Thread Borislav Petkov
On Tue, Sep 25, 2018 at 09:34:49AM -0500, Justin Ernst wrote:
> We observe an oops in the skx_edac module during boot.
> Examining /var/log/messages:
> [ 3401.985757] EDAC MC0: Giving out device to module skx_edac controller 
> Skylake Socket#0 IMC#0
> [ 3401.985887] EDAC MC1: Giving out device to module skx_edac controller 
> Skylake Socket#0 IMC#1
> [ 3401.986014] EDAC MC2: Giving out device to module skx_edac controller 
> Skylake Socket#1 IMC#0
> ...
> [ 3401.987318] EDAC MC13: Giving out device to module skx_edac controller 
> Skylake Socket#0 IMC#1
> [ 3401.987435] EDAC MC14: Giving out device to module skx_edac controller 
> Skylake Socket#1 IMC#0
> [ 3401.987556] EDAC MC15: Giving out device to module skx_edac controller 
> Skylake Socket#1 IMC#1
> [ 3401.987579] Too many memory controllers: 16
> [ 3402.042614] EDAC MC: Removed device 0 for skx_edac Skylake Socket#0 IMC#0
> 
> We observe there are two memory controllers per socket, with a limit of 16.
> Raise the maximum number of memory controllers from 16 to 2 * MAX_NUMNODES 
> (1024).
> 
> Cc: Borislav Petkov 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-e...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Russ Anderson 
> Signed-off-by: Justin Ernst 
> ---
>  include/linux/edac.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH] Raise maximum number of memory controllers

2018-09-26 Thread Borislav Petkov
On Tue, Sep 25, 2018 at 09:34:49AM -0500, Justin Ernst wrote:
> We observe an oops in the skx_edac module during boot.
> Examining /var/log/messages:
> [ 3401.985757] EDAC MC0: Giving out device to module skx_edac controller 
> Skylake Socket#0 IMC#0
> [ 3401.985887] EDAC MC1: Giving out device to module skx_edac controller 
> Skylake Socket#0 IMC#1
> [ 3401.986014] EDAC MC2: Giving out device to module skx_edac controller 
> Skylake Socket#1 IMC#0
> ...
> [ 3401.987318] EDAC MC13: Giving out device to module skx_edac controller 
> Skylake Socket#0 IMC#1
> [ 3401.987435] EDAC MC14: Giving out device to module skx_edac controller 
> Skylake Socket#1 IMC#0
> [ 3401.987556] EDAC MC15: Giving out device to module skx_edac controller 
> Skylake Socket#1 IMC#1
> [ 3401.987579] Too many memory controllers: 16
> [ 3402.042614] EDAC MC: Removed device 0 for skx_edac Skylake Socket#0 IMC#0
> 
> We observe there are two memory controllers per socket, with a limit of 16.
> Raise the maximum number of memory controllers from 16 to 2 * MAX_NUMNODES 
> (1024).
> 
> Cc: Borislav Petkov 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-e...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Russ Anderson 
> Signed-off-by: Justin Ernst 
> ---
>  include/linux/edac.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


[PATCH] use STORE_LOCKED instead of STORE macro

2018-09-26 Thread Dongbo Cao
merge sysfs_writeback_running attr and sysfs_writeback_percent attr together 
with other attrs of cached_dev.

Signed-off-by: Dongbo Cao 
---
 drivers/md/bcache/sysfs.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 26f035a0..14fc9104 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -245,7 +245,7 @@ SHOW(__bch_cached_dev)
 }
 SHOW_LOCKED(bch_cached_dev)
 
-STORE(__cached_dev)
+STORE(__bch_cached_dev)
 {
struct cached_dev *dc = container_of(kobj, struct cached_dev,
 disk.kobj);
@@ -373,17 +373,6 @@ STORE(__cached_dev)
if (attr == _stop)
bcache_device_stop(>disk);
 
-   return size;
-}
-
-STORE(bch_cached_dev)
-{
-   struct cached_dev *dc = container_of(kobj, struct cached_dev,
-disk.kobj);
-
-   mutex_lock(_register_lock);
-   size = __cached_dev_store(kobj, attr, buf, size);
-
if (attr == _writeback_running)
bch_writeback_queue(dc);
 
@@ -392,9 +381,9 @@ STORE(bch_cached_dev)
schedule_delayed_work(>writeback_rate_update,
  dc->writeback_rate_update_seconds * HZ);
 
-   mutex_unlock(_register_lock);
return size;
 }
+STORE_LOCKED(bch_cached_dev)
 
 static struct attribute *bch_cached_dev_files[] = {
_attach,
-- 
2.17.1




[PATCH] use STORE_LOCKED instead of STORE macro

2018-09-26 Thread Dongbo Cao
merge sysfs_writeback_running attr and sysfs_writeback_percent attr together 
with other attrs of cached_dev.

Signed-off-by: Dongbo Cao 
---
 drivers/md/bcache/sysfs.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 26f035a0..14fc9104 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -245,7 +245,7 @@ SHOW(__bch_cached_dev)
 }
 SHOW_LOCKED(bch_cached_dev)
 
-STORE(__cached_dev)
+STORE(__bch_cached_dev)
 {
struct cached_dev *dc = container_of(kobj, struct cached_dev,
 disk.kobj);
@@ -373,17 +373,6 @@ STORE(__cached_dev)
if (attr == _stop)
bcache_device_stop(>disk);
 
-   return size;
-}
-
-STORE(bch_cached_dev)
-{
-   struct cached_dev *dc = container_of(kobj, struct cached_dev,
-disk.kobj);
-
-   mutex_lock(_register_lock);
-   size = __cached_dev_store(kobj, attr, buf, size);
-
if (attr == _writeback_running)
bch_writeback_queue(dc);
 
@@ -392,9 +381,9 @@ STORE(bch_cached_dev)
schedule_delayed_work(>writeback_rate_update,
  dc->writeback_rate_update_seconds * HZ);
 
-   mutex_unlock(_register_lock);
return size;
 }
+STORE_LOCKED(bch_cached_dev)
 
 static struct attribute *bch_cached_dev_files[] = {
_attach,
-- 
2.17.1




linux-next: Tree for Sep 27

2018-09-26 Thread Stephen Rothwell
Hi all,

Changes since 20180926:

Dropped trees: xarray, ida (temporarily)

The pci tree lost its build failure.

Non-merge commits (relative to Linus' tree): 6252
 6435 files changed, 294737 insertions(+), 131625 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c307aaf3eb47 Merge tag 'iommu-fixes-v4.19-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of 
Linus' tree)
Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain 
not in Clang search path)
Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE 
in arch's Makefile)
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (031e6e6b4e12 arm64: hugetlb: Avoid 
unnecessary clearing in huge_ptep_set_access_flags)
Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response 
format)
Merging powerpc-fixes/fixes (2483ef056f6e powerpc/numa: Use associativity if 
VPHN hcall is successful)
Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (3f32d0be6c16 tipc: lock wakeup & inputq at 
tipc_link_reset())
Merging bpf/master (3f32d0be6c16 tipc: lock wakeup & inputq at 
tipc_link_reset())
Merging ipsec/master (32bf94fb5c2e xfrm: validate template mode)
Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double 
sizeof)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related 
regression with proprietary firmware)
Merging mac80211/master (28ef8b49a338 mac80211_hwsim: do not omit multicast 
announce of first added radio)
Merging rdma-fixes/for-rc (5c5702e259dc RDMA/core: Set right entry state before 
releasing reference)
Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the 
audio-component completion timeout)
Merging sound-asoc-fixes/for-linus (6c96a58bb15b Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4)
Merging regulator-fixes/for-linus (3564951ca82b Merge branch 'regulator-4.19' 
into regulator-linus)
Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into 
spi-linus)
Merging pci-current/for-linus (f188b99f0b2d ACPI / hotplug / PCI: Don't scan 
for non-hotplug bridges if slot is not bridge)
Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4)
Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking 
irq for imx1)
Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of 
driver module reference counting)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add 
Motorola Tetra MTP6550 id)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Alw

linux-next: Tree for Sep 27

2018-09-26 Thread Stephen Rothwell
Hi all,

Changes since 20180926:

Dropped trees: xarray, ida (temporarily)

The pci tree lost its build failure.

Non-merge commits (relative to Linus' tree): 6252
 6435 files changed, 294737 insertions(+), 131625 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c307aaf3eb47 Merge tag 'iommu-fixes-v4.19-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of 
Linus' tree)
Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain 
not in Clang search path)
Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE 
in arch's Makefile)
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (031e6e6b4e12 arm64: hugetlb: Avoid 
unnecessary clearing in huge_ptep_set_access_flags)
Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response 
format)
Merging powerpc-fixes/fixes (2483ef056f6e powerpc/numa: Use associativity if 
VPHN hcall is successful)
Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (3f32d0be6c16 tipc: lock wakeup & inputq at 
tipc_link_reset())
Merging bpf/master (3f32d0be6c16 tipc: lock wakeup & inputq at 
tipc_link_reset())
Merging ipsec/master (32bf94fb5c2e xfrm: validate template mode)
Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double 
sizeof)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related 
regression with proprietary firmware)
Merging mac80211/master (28ef8b49a338 mac80211_hwsim: do not omit multicast 
announce of first added radio)
Merging rdma-fixes/for-rc (5c5702e259dc RDMA/core: Set right entry state before 
releasing reference)
Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the 
audio-component completion timeout)
Merging sound-asoc-fixes/for-linus (6c96a58bb15b Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4)
Merging regulator-fixes/for-linus (3564951ca82b Merge branch 'regulator-4.19' 
into regulator-linus)
Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into 
spi-linus)
Merging pci-current/for-linus (f188b99f0b2d ACPI / hotplug / PCI: Don't scan 
for non-hotplug bridges if slot is not bridge)
Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4)
Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking 
irq for imx1)
Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of 
driver module reference counting)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add 
Motorola Tetra MTP6550 id)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Alw

Re: [PATCH V5 06/30] csky: Cache and TLB routines

2018-09-26 Thread Guo Ren
On Tue, Sep 25, 2018 at 09:24:07AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 24, 2018 at 10:36:22PM +0800, Guo Ren wrote:
> > diff --git a/arch/csky/abiv1/inc/abi/cacheflush.h 
> > b/arch/csky/abiv1/inc/abi/cacheflush.h
> > new file mode 100644
> > index 000..f0de49c
> > --- /dev/null
> > +++ b/arch/csky/abiv1/inc/abi/cacheflush.h
> > @@ -0,0 +1,43 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ABI_CSKY_CACHEFLUSH_H
> > +#define __ABI_CSKY_CACHEFLUSH_H
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
> > +extern void flush_dcache_page(struct page *);
> > +
> > +#define flush_cache_mm(mm) cache_wbinv_all()
> > +#define flush_cache_page(vma,page,pfn) cache_wbinv_all()
> > +#define flush_cache_dup_mm(mm) cache_wbinv_all()
> > +
> > +#define flush_cache_range(mm,start,end)cache_wbinv_range(start, end)
>  ^^^ should be vma
Yes, I'll change it to:
#define flush_cache_range(mm,start,end) cache_wbinv_all()

I'll improve it later after test.

> 
> > +#endif /* __ABI_CSKY_CACHEFLUSH_H */
> 
> 
> > diff --git a/arch/csky/abiv1/inc/abi/tlb.h b/arch/csky/abiv1/inc/abi/tlb.h
> > new file mode 100644
> > index 000..6d461f3
> > --- /dev/null
> > +++ b/arch/csky/abiv1/inc/abi/tlb.h
> > @@ -0,0 +1,12 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ABI_CSKY_TLB_H
> > +#define __ABI_CSKY_TLB_H
> > +
> > +#define tlb_start_vma(tlb, vma) \
> > +   do { \
> > +   if (!tlb->fullmm) \
> > +   cache_wbinv_all(); \
> > +   }  while (0)
> > +#endif /* __ABI_CSKY_TLB_H */
> 
> That should be:
> 
>   if (!tlb->fullmm)
>   flush_cache_range(vma, vma->vm_start, vma->vm_end);
> 
> Because as per the whole abiv1 vs abiv2, you don't need write back
> invalidation for v2 at all, also, you only need to invalidate the vma
> range, no reason to shoot everything down.
> 
> Also, I'll be shortly removing this:
> 
>   https://lkml.kernel.org/r/20180913092812.071989...@infradead.org
Ok, I'll follow the rules.

> 
> > diff --git a/arch/csky/abiv2/inc/abi/cacheflush.h 
> > b/arch/csky/abiv2/inc/abi/cacheflush.h
> > new file mode 100644
> > index 000..756beb7
> > --- /dev/null
> > +++ b/arch/csky/abiv2/inc/abi/cacheflush.h
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#ifndef __ABI_CSKY_CACHEFLUSH_H
> > +#define __ABI_CSKY_CACHEFLUSH_H
> > +
> > +/* Keep includes the same across arches.  */
> > +#include 
> > +
> > +/*
> > + * The cache doesn't need to be flushed when TLB entries change when
> > + * the cache is mapped to physical memory, not virtual memory
> > + */
> > +#define flush_cache_all()  do { } while (0)
> > +#define flush_cache_mm(mm) do { } while (0)
> > +#define flush_cache_dup_mm(mm) do { } while (0)
> > +#define flush_cache_range(vma, start, end) do { } while (0)
>  ^^^ like here..
#define flush_cache_range(vma, start, end) \
do { \
if (vma->vm_flags & VM_EXEC) \
icache_inv_all(); \
}

Hmm ?

I'll improve it later after test.

Best Regards
 Guo Ren


Re: [PATCH V5 06/30] csky: Cache and TLB routines

2018-09-26 Thread Guo Ren
On Tue, Sep 25, 2018 at 09:24:07AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 24, 2018 at 10:36:22PM +0800, Guo Ren wrote:
> > diff --git a/arch/csky/abiv1/inc/abi/cacheflush.h 
> > b/arch/csky/abiv1/inc/abi/cacheflush.h
> > new file mode 100644
> > index 000..f0de49c
> > --- /dev/null
> > +++ b/arch/csky/abiv1/inc/abi/cacheflush.h
> > @@ -0,0 +1,43 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ABI_CSKY_CACHEFLUSH_H
> > +#define __ABI_CSKY_CACHEFLUSH_H
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
> > +extern void flush_dcache_page(struct page *);
> > +
> > +#define flush_cache_mm(mm) cache_wbinv_all()
> > +#define flush_cache_page(vma,page,pfn) cache_wbinv_all()
> > +#define flush_cache_dup_mm(mm) cache_wbinv_all()
> > +
> > +#define flush_cache_range(mm,start,end)cache_wbinv_range(start, end)
>  ^^^ should be vma
Yes, I'll change it to:
#define flush_cache_range(mm,start,end) cache_wbinv_all()

I'll improve it later after test.

> 
> > +#endif /* __ABI_CSKY_CACHEFLUSH_H */
> 
> 
> > diff --git a/arch/csky/abiv1/inc/abi/tlb.h b/arch/csky/abiv1/inc/abi/tlb.h
> > new file mode 100644
> > index 000..6d461f3
> > --- /dev/null
> > +++ b/arch/csky/abiv1/inc/abi/tlb.h
> > @@ -0,0 +1,12 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ABI_CSKY_TLB_H
> > +#define __ABI_CSKY_TLB_H
> > +
> > +#define tlb_start_vma(tlb, vma) \
> > +   do { \
> > +   if (!tlb->fullmm) \
> > +   cache_wbinv_all(); \
> > +   }  while (0)
> > +#endif /* __ABI_CSKY_TLB_H */
> 
> That should be:
> 
>   if (!tlb->fullmm)
>   flush_cache_range(vma, vma->vm_start, vma->vm_end);
> 
> Because as per the whole abiv1 vs abiv2, you don't need write back
> invalidation for v2 at all, also, you only need to invalidate the vma
> range, no reason to shoot everything down.
> 
> Also, I'll be shortly removing this:
> 
>   https://lkml.kernel.org/r/20180913092812.071989...@infradead.org
Ok, I'll follow the rules.

> 
> > diff --git a/arch/csky/abiv2/inc/abi/cacheflush.h 
> > b/arch/csky/abiv2/inc/abi/cacheflush.h
> > new file mode 100644
> > index 000..756beb7
> > --- /dev/null
> > +++ b/arch/csky/abiv2/inc/abi/cacheflush.h
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#ifndef __ABI_CSKY_CACHEFLUSH_H
> > +#define __ABI_CSKY_CACHEFLUSH_H
> > +
> > +/* Keep includes the same across arches.  */
> > +#include 
> > +
> > +/*
> > + * The cache doesn't need to be flushed when TLB entries change when
> > + * the cache is mapped to physical memory, not virtual memory
> > + */
> > +#define flush_cache_all()  do { } while (0)
> > +#define flush_cache_mm(mm) do { } while (0)
> > +#define flush_cache_dup_mm(mm) do { } while (0)
> > +#define flush_cache_range(vma, start, end) do { } while (0)
>  ^^^ like here..
#define flush_cache_range(vma, start, end) \
do { \
if (vma->vm_flags & VM_EXEC) \
icache_inv_all(); \
}

Hmm ?

I'll improve it later after test.

Best Regards
 Guo Ren


Re: [PATCH v3 1/2] dt-bindings: spi: Qualcomm Quad SPI(QSPI) documentation

2018-09-26 Thread Stephen Boyd
Quoting Ryan Case (2018-09-26 13:52:03)
> From: Girish Mahadevan 
> 
> Bindings for Qualcomm Quad SPI used on SoCs such as sdm845.
> 
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Ryan Case 
> ---

Reviewed-by: Stephen Boyd 



Re: [PATCH v3 1/2] dt-bindings: spi: Qualcomm Quad SPI(QSPI) documentation

2018-09-26 Thread Stephen Boyd
Quoting Ryan Case (2018-09-26 13:52:03)
> From: Girish Mahadevan 
> 
> Bindings for Qualcomm Quad SPI used on SoCs such as sdm845.
> 
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Ryan Case 
> ---

Reviewed-by: Stephen Boyd 



RE: [PATCH v2] PM / devfreq: Stop the governor before device_unregister()

2018-09-26 Thread MyungJoo Ham
> From: Vincent Donnefort 
> 
> device_release() is freeing the resources before calling the device
> specific release callback which is, in the case of devfreq, stopping
> the governor.
> 
> It is a problem as some governors are using the device resources. e.g.
> simpleondemand which is using the devfreq deferrable monitoring work. If it
> is not stopped before the resources are freed, it might lead to a use after
> free.
> 
> Signed-off-by: Vincent Donnefort 
> Reviewed-by: John Einar Reitan 
> Reviewed-by: Chanwoo Choi 

Acked-by: MyungJoo Ham 


Cheers,
MyungJoo


RE: [PATCH v2] PM / devfreq: Stop the governor before device_unregister()

2018-09-26 Thread MyungJoo Ham
> From: Vincent Donnefort 
> 
> device_release() is freeing the resources before calling the device
> specific release callback which is, in the case of devfreq, stopping
> the governor.
> 
> It is a problem as some governors are using the device resources. e.g.
> simpleondemand which is using the devfreq deferrable monitoring work. If it
> is not stopped before the resources are freed, it might lead to a use after
> free.
> 
> Signed-off-by: Vincent Donnefort 
> Reviewed-by: John Einar Reitan 
> Reviewed-by: Chanwoo Choi 

Acked-by: MyungJoo Ham 


Cheers,
MyungJoo


Re: [PATCH v2 06/21] platform: goldfish: pipe: Add DMA support to goldfish pipe

2018-09-26 Thread Greg KH
On Wed, Sep 26, 2018 at 04:02:19PM -0700, r...@google.com wrote:
> From: Roman Kiryanov 
> 
> Goldfish DMA is an extension to the pipe device and is designed
> to facilitate high-speed RAM->RAM transfers from guest to host.
> 
> See uapi/linux/goldfish/goldfish_dma.h for more details.
> 
> Signed-off-by: Roman Kiryanov 
> Signed-off-by: Lingfeng Yang 
> ---
> Changes in v2:
>  - Got sign-off from Lingfeng Yang.
>  - Removed the license boilerplate from goldfish_dma.h.
>  - Rebased.

I don't understand this series.  Please start over with 01/XX as your
other patches were all merged.

And I still think you need a better justification for this, given the
many other ways the kernel already has for this feature...

thanks,

greg k-h


Re: [PATCH v2 06/21] platform: goldfish: pipe: Add DMA support to goldfish pipe

2018-09-26 Thread Greg KH
On Wed, Sep 26, 2018 at 04:02:19PM -0700, r...@google.com wrote:
> From: Roman Kiryanov 
> 
> Goldfish DMA is an extension to the pipe device and is designed
> to facilitate high-speed RAM->RAM transfers from guest to host.
> 
> See uapi/linux/goldfish/goldfish_dma.h for more details.
> 
> Signed-off-by: Roman Kiryanov 
> Signed-off-by: Lingfeng Yang 
> ---
> Changes in v2:
>  - Got sign-off from Lingfeng Yang.
>  - Removed the license boilerplate from goldfish_dma.h.
>  - Rebased.

I don't understand this series.  Please start over with 01/XX as your
other patches were all merged.

And I still think you need a better justification for this, given the
many other ways the kernel already has for this feature...

thanks,

greg k-h


Re: [PATCH v2 4/4] power: supply: Add Spreadtrum SC27XX fuel gauge unit driver

2018-09-26 Thread Baolin Wang
On 26 September 2018 at 23:30, Sebastian Reichel  wrote:
> Hi,
>
> On Wed, Sep 26, 2018 at 10:59:14AM +0800, Baolin Wang wrote:
>> This patch adds the Spreadtrum SC27XX serial PMICs fuel gauge support,
>> which is used to calculate the battery capacity.
>>
>> Original-by: Yuanjiang Yu 
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes from v1:
>>  - Use battery standard properties to get internal resistance and ocv table.
>>  - Change devm_gpiod_get_optional() to devm_gpiod_get().
>>  - Add power_supply_changed() when detecting battery present change.
>>  - Return micro volts for sc27xx_fgu_get_vbat_ocv().
>> ---
>>  drivers/power/supply/Kconfig |7 +
>>  drivers/power/supply/Makefile|1 +
>>  drivers/power/supply/sc27xx_fuel_gauge.c |  691 
>> ++
>>  3 files changed, 699 insertions(+)
>>  create mode 100644 drivers/power/supply/sc27xx_fuel_gauge.c
>>
>> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
>> index f27cf07..917f4b7 100644
>> --- a/drivers/power/supply/Kconfig
>> +++ b/drivers/power/supply/Kconfig
>> @@ -652,4 +652,11 @@ config CHARGER_SC2731
>>Say Y here to enable support for battery charging with SC2731
>>PMIC chips.
>>
>> +config FUEL_GAUGE_SC27XX
>> + tristate "Spreadtrum SC27XX fuel gauge driver"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> +  Say Y here to enable support for fuel gauge with SC27XX
>> +  PMIC chips.
>> +
>>  endif # POWER_SUPPLY
>> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
>> index 767105b..b731c2a 100644
>> --- a/drivers/power/supply/Makefile
>> +++ b/drivers/power/supply/Makefile
>> @@ -86,3 +86,4 @@ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>>  obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
>>  obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
>>  obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
>> +obj-$(CONFIG_FUEL_GAUGE_SC27XX)  += sc27xx_fuel_gauge.o
>> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c 
>> b/drivers/power/supply/sc27xx_fuel_gauge.c
>> new file mode 100644
>> index 000..d3422cf
>> --- /dev/null
>> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
>> @@ -0,0 +1,691 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* PMIC global control registers definition */
>> +#define SC27XX_MODULE_EN00xc08
>> +#define SC27XX_CLK_EN0   0xc18
>> +#define SC27XX_FGU_ENBIT(7)
>> +#define SC27XX_FGU_RTC_ENBIT(6)
>> +
>> +/* FGU registers definition */
>> +#define SC27XX_FGU_START 0x0
>> +#define SC27XX_FGU_CONFIG0x4
>> +#define SC27XX_FGU_ADC_CONFIG0x8
>> +#define SC27XX_FGU_STATUS0xc
>> +#define SC27XX_FGU_INT_EN0x10
>> +#define SC27XX_FGU_INT_CLR   0x14
>> +#define SC27XX_FGU_INT_STS   0x1c
>> +#define SC27XX_FGU_VOLTAGE   0x20
>> +#define SC27XX_FGU_OCV   0x24
>> +#define SC27XX_FGU_POCV  0x28
>> +#define SC27XX_FGU_CURRENT   0x2c
>> +#define SC27XX_FGU_CLBCNT_SETH   0x50
>> +#define SC27XX_FGU_CLBCNT_SETL   0x54
>> +#define SC27XX_FGU_CLBCNT_VALH   0x68
>> +#define SC27XX_FGU_CLBCNT_VALL   0x6c
>> +#define SC27XX_FGU_CLBCNT_QMAXL  0x74
>> +
>> +#define SC27XX_WRITE_SELCLB_EN   BIT(0)
>> +#define SC27XX_FGU_CLBCNT_MASK   GENMASK(15, 0)
>> +#define SC27XX_FGU_CLBCNT_SHIFT  16
>> +
>> +#define SC27XX_FGU_1000MV_ADC686
>> +#define SC27XX_FGU_1000MA_ADC1372
>> +#define SC27XX_FGU_CUR_BASIC_ADC 8192
>> +#define SC27XX_FGU_SAMPLE_HZ 2
>> +
>> +/*
>> + * struct sc27xx_fgu_data: describe the FGU device
>> + * @regmap: regmap for register access
>> + * @dev: platform device
>> + * @battery: battery power supply
>> + * @base: the base offset for the controller
>> + * @lock: protect the structure
>> + * @gpiod: GPIO for battery detection
>> + * @channel: IIO channel to get battery temperature
>> + * @internal_resist: the battery internal resistance in mOhm
>> + * @total_cap: the total capacity of the battery in mAh
>> + * @init_cap: the initial capacity of the battery in mAh
>> + * @init_clbcnt: the initial coulomb counter
>> + * @max_volt: the maximum constant input voltage in millivolt
>> + * @table_len: the capacity table length
>> + * @cap_table: capacity table with corresponding ocv
>> + */
>> +struct sc27xx_fgu_data {
>> + struct regmap *regmap;
>> + struct device *dev;
>> + struct power_supply *battery;
>> + u32 base;
>> + struct mutex lock;
>> + struct gpio_desc *gpiod;
>> + struct iio_channel *channel;
>> + bool 

Re: [PATCH v2 4/4] power: supply: Add Spreadtrum SC27XX fuel gauge unit driver

2018-09-26 Thread Baolin Wang
On 26 September 2018 at 23:30, Sebastian Reichel  wrote:
> Hi,
>
> On Wed, Sep 26, 2018 at 10:59:14AM +0800, Baolin Wang wrote:
>> This patch adds the Spreadtrum SC27XX serial PMICs fuel gauge support,
>> which is used to calculate the battery capacity.
>>
>> Original-by: Yuanjiang Yu 
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes from v1:
>>  - Use battery standard properties to get internal resistance and ocv table.
>>  - Change devm_gpiod_get_optional() to devm_gpiod_get().
>>  - Add power_supply_changed() when detecting battery present change.
>>  - Return micro volts for sc27xx_fgu_get_vbat_ocv().
>> ---
>>  drivers/power/supply/Kconfig |7 +
>>  drivers/power/supply/Makefile|1 +
>>  drivers/power/supply/sc27xx_fuel_gauge.c |  691 
>> ++
>>  3 files changed, 699 insertions(+)
>>  create mode 100644 drivers/power/supply/sc27xx_fuel_gauge.c
>>
>> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
>> index f27cf07..917f4b7 100644
>> --- a/drivers/power/supply/Kconfig
>> +++ b/drivers/power/supply/Kconfig
>> @@ -652,4 +652,11 @@ config CHARGER_SC2731
>>Say Y here to enable support for battery charging with SC2731
>>PMIC chips.
>>
>> +config FUEL_GAUGE_SC27XX
>> + tristate "Spreadtrum SC27XX fuel gauge driver"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> +  Say Y here to enable support for fuel gauge with SC27XX
>> +  PMIC chips.
>> +
>>  endif # POWER_SUPPLY
>> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
>> index 767105b..b731c2a 100644
>> --- a/drivers/power/supply/Makefile
>> +++ b/drivers/power/supply/Makefile
>> @@ -86,3 +86,4 @@ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>>  obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
>>  obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
>>  obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
>> +obj-$(CONFIG_FUEL_GAUGE_SC27XX)  += sc27xx_fuel_gauge.o
>> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c 
>> b/drivers/power/supply/sc27xx_fuel_gauge.c
>> new file mode 100644
>> index 000..d3422cf
>> --- /dev/null
>> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
>> @@ -0,0 +1,691 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* PMIC global control registers definition */
>> +#define SC27XX_MODULE_EN00xc08
>> +#define SC27XX_CLK_EN0   0xc18
>> +#define SC27XX_FGU_ENBIT(7)
>> +#define SC27XX_FGU_RTC_ENBIT(6)
>> +
>> +/* FGU registers definition */
>> +#define SC27XX_FGU_START 0x0
>> +#define SC27XX_FGU_CONFIG0x4
>> +#define SC27XX_FGU_ADC_CONFIG0x8
>> +#define SC27XX_FGU_STATUS0xc
>> +#define SC27XX_FGU_INT_EN0x10
>> +#define SC27XX_FGU_INT_CLR   0x14
>> +#define SC27XX_FGU_INT_STS   0x1c
>> +#define SC27XX_FGU_VOLTAGE   0x20
>> +#define SC27XX_FGU_OCV   0x24
>> +#define SC27XX_FGU_POCV  0x28
>> +#define SC27XX_FGU_CURRENT   0x2c
>> +#define SC27XX_FGU_CLBCNT_SETH   0x50
>> +#define SC27XX_FGU_CLBCNT_SETL   0x54
>> +#define SC27XX_FGU_CLBCNT_VALH   0x68
>> +#define SC27XX_FGU_CLBCNT_VALL   0x6c
>> +#define SC27XX_FGU_CLBCNT_QMAXL  0x74
>> +
>> +#define SC27XX_WRITE_SELCLB_EN   BIT(0)
>> +#define SC27XX_FGU_CLBCNT_MASK   GENMASK(15, 0)
>> +#define SC27XX_FGU_CLBCNT_SHIFT  16
>> +
>> +#define SC27XX_FGU_1000MV_ADC686
>> +#define SC27XX_FGU_1000MA_ADC1372
>> +#define SC27XX_FGU_CUR_BASIC_ADC 8192
>> +#define SC27XX_FGU_SAMPLE_HZ 2
>> +
>> +/*
>> + * struct sc27xx_fgu_data: describe the FGU device
>> + * @regmap: regmap for register access
>> + * @dev: platform device
>> + * @battery: battery power supply
>> + * @base: the base offset for the controller
>> + * @lock: protect the structure
>> + * @gpiod: GPIO for battery detection
>> + * @channel: IIO channel to get battery temperature
>> + * @internal_resist: the battery internal resistance in mOhm
>> + * @total_cap: the total capacity of the battery in mAh
>> + * @init_cap: the initial capacity of the battery in mAh
>> + * @init_clbcnt: the initial coulomb counter
>> + * @max_volt: the maximum constant input voltage in millivolt
>> + * @table_len: the capacity table length
>> + * @cap_table: capacity table with corresponding ocv
>> + */
>> +struct sc27xx_fgu_data {
>> + struct regmap *regmap;
>> + struct device *dev;
>> + struct power_supply *battery;
>> + u32 base;
>> + struct mutex lock;
>> + struct gpio_desc *gpiod;
>> + struct iio_channel *channel;
>> + bool 

Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as used

2018-09-26 Thread Greg Kroah-Hartman
On Wed, Sep 26, 2018 at 04:20:55PM -0700, Nathan Chancellor wrote:
> Clang emits the following warning:
> 
> drivers/staging/rtl8723bs/os_dep/sdio_intf.c:25:36: warning: variable
> 'acpi_ids' is not needed and will not be emitted
> [-Wunneeded-internal-declaration]
> static const struct acpi_device_id acpi_ids[] = {
>^
> 1 warning generated.
> 
> Mark acpi_ids with the attribute __used, which makes it clear to Clang
> that we don't want this warning while not inhibiting Clang's dead code
> elimination from removing the unreferenced internal symbol when moving
> the data to the globally available symbol with MODULE_DEVICE_TABLE.
> 
> $ nm -S drivers/staging/rtl8723bs/os_dep/sdio_intf.o | grep acpi
>  0040 R __mod_acpi__acpi_ids_device_table
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/169
> Suggested-by: Nick Desaulniers 
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c 
> b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> index 6d02904de63f..7c03b69b8ed3 100644
> --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> @@ -22,7 +22,7 @@ static const struct sdio_device_id sdio_ids[] =
>   { SDIO_DEVICE(0x024c, 0xb723), },
>   { /* end: all zeroes */ },
>  };
> -static const struct acpi_device_id acpi_ids[] = {
> +static const struct acpi_device_id acpi_ids[] __used = {

Can't we put __used somewhere in the MODULE_DEVICE_TABLE() macro so we
don't have to go adding it to all individual entries?

thanks,

greg k-h


Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as used

2018-09-26 Thread Greg Kroah-Hartman
On Wed, Sep 26, 2018 at 04:20:55PM -0700, Nathan Chancellor wrote:
> Clang emits the following warning:
> 
> drivers/staging/rtl8723bs/os_dep/sdio_intf.c:25:36: warning: variable
> 'acpi_ids' is not needed and will not be emitted
> [-Wunneeded-internal-declaration]
> static const struct acpi_device_id acpi_ids[] = {
>^
> 1 warning generated.
> 
> Mark acpi_ids with the attribute __used, which makes it clear to Clang
> that we don't want this warning while not inhibiting Clang's dead code
> elimination from removing the unreferenced internal symbol when moving
> the data to the globally available symbol with MODULE_DEVICE_TABLE.
> 
> $ nm -S drivers/staging/rtl8723bs/os_dep/sdio_intf.o | grep acpi
>  0040 R __mod_acpi__acpi_ids_device_table
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/169
> Suggested-by: Nick Desaulniers 
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c 
> b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> index 6d02904de63f..7c03b69b8ed3 100644
> --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> @@ -22,7 +22,7 @@ static const struct sdio_device_id sdio_ids[] =
>   { SDIO_DEVICE(0x024c, 0xb723), },
>   { /* end: all zeroes */ },
>  };
> -static const struct acpi_device_id acpi_ids[] = {
> +static const struct acpi_device_id acpi_ids[] __used = {

Can't we put __used somewhere in the MODULE_DEVICE_TABLE() macro so we
don't have to go adding it to all individual entries?

thanks,

greg k-h


[PATCH v3] IB/rxe: Remove unnecessary enum values

2018-09-26 Thread Nathan Chancellor
Clang warns when an emumerated type is implicitly converted to another.

drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu  = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.

Use the appropriate values from the expected enumerated type so no
conversion needs to happen then remove the unneeded definitions.

Reported-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
---

v1 -> v2:

* Don't cast, just use the expecting enumerated value directly, per
  Jason's request

v2 -> v3:

* Convert two spots from RXE_PORT_MAX_MTU to IB_MTU_4096 then remove
  value definitions.

 drivers/infiniband/sw/rxe/rxe.c   | 13 ++---
 drivers/infiniband/sw/rxe/rxe_loc.h   |  2 +-
 drivers/infiniband/sw/rxe/rxe_param.h |  4 
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..383e65c7bbc0 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom   = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom   = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom   = RXE_MAX_EE_INIT_RD_ATOM;
-   rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+   rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd   = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
 /* initialize port attributes */
 static int rxe_init_port_param(struct rxe_port *port)
 {
-   port->attr.state= RXE_PORT_STATE;
-   port->attr.max_mtu  = RXE_PORT_MAX_MTU;
-   port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
+   port->attr.state= IB_PORT_DOWN;
+   port->attr.max_mtu  = IB_MTU_4096;
+   port->attr.active_mtu   = IB_MTU_256;
port->attr.gid_tbl_len  = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags   = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz   = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state   = RXE_PORT_PHYS_STATE;
-   port->mtu_cap   =
-   ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+   port->mtu_cap   = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
 
return 0;
@@ -300,7 +299,7 @@ void rxe_set_mtu(struct rxe_dev *rxe, unsigned int ndev_mtu)
mtu = eth_mtu_int_to_enum(ndev_mtu);
 
/* Make sure that new MTU in range */
-   mtu = mtu ? min_t(enum ib_mtu, mtu, RXE_PORT_MAX_MTU) : IB_MTU_256;
+   mtu = mtu ? min_t(enum ib_mtu, mtu, IB_MTU_4096) : IB_MTU_256;
 
port->attr.active_mtu = mtu;
port->mtu_cap = ib_mtu_enum_to_int(mtu);
diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h 
b/drivers/infiniband/sw/rxe/rxe_loc.h
index 8e305422adbb..afd53f57a62b 100644
--- a/drivers/infiniband/sw/rxe/rxe_loc.h
+++ b/drivers/infiniband/sw/rxe/rxe_loc.h
@@ -195,7 +195,7 @@ static inline int qp_mtu(struct rxe_qp *qp)
   

[PATCH v3] IB/rxe: Remove unnecessary enum values

2018-09-26 Thread Nathan Chancellor
Clang warns when an emumerated type is implicitly converted to another.

drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu  = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.

Use the appropriate values from the expected enumerated type so no
conversion needs to happen then remove the unneeded definitions.

Reported-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
---

v1 -> v2:

* Don't cast, just use the expecting enumerated value directly, per
  Jason's request

v2 -> v3:

* Convert two spots from RXE_PORT_MAX_MTU to IB_MTU_4096 then remove
  value definitions.

 drivers/infiniband/sw/rxe/rxe.c   | 13 ++---
 drivers/infiniband/sw/rxe/rxe_loc.h   |  2 +-
 drivers/infiniband/sw/rxe/rxe_param.h |  4 
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..383e65c7bbc0 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom   = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom   = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom   = RXE_MAX_EE_INIT_RD_ATOM;
-   rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+   rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd   = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
 /* initialize port attributes */
 static int rxe_init_port_param(struct rxe_port *port)
 {
-   port->attr.state= RXE_PORT_STATE;
-   port->attr.max_mtu  = RXE_PORT_MAX_MTU;
-   port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
+   port->attr.state= IB_PORT_DOWN;
+   port->attr.max_mtu  = IB_MTU_4096;
+   port->attr.active_mtu   = IB_MTU_256;
port->attr.gid_tbl_len  = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags   = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz   = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state   = RXE_PORT_PHYS_STATE;
-   port->mtu_cap   =
-   ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+   port->mtu_cap   = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
 
return 0;
@@ -300,7 +299,7 @@ void rxe_set_mtu(struct rxe_dev *rxe, unsigned int ndev_mtu)
mtu = eth_mtu_int_to_enum(ndev_mtu);
 
/* Make sure that new MTU in range */
-   mtu = mtu ? min_t(enum ib_mtu, mtu, RXE_PORT_MAX_MTU) : IB_MTU_256;
+   mtu = mtu ? min_t(enum ib_mtu, mtu, IB_MTU_4096) : IB_MTU_256;
 
port->attr.active_mtu = mtu;
port->mtu_cap = ib_mtu_enum_to_int(mtu);
diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h 
b/drivers/infiniband/sw/rxe/rxe_loc.h
index 8e305422adbb..afd53f57a62b 100644
--- a/drivers/infiniband/sw/rxe/rxe_loc.h
+++ b/drivers/infiniband/sw/rxe/rxe_loc.h
@@ -195,7 +195,7 @@ static inline int qp_mtu(struct rxe_qp *qp)
   

[PATCH linux-next 10/10] ASoC: rsnd: Add kctrl to configure dai's busif

2018-09-26 Thread jiada_wang
From: Jiada Wang 

ssi0, ssi1, ssi2, ssi3, ssi4 and ssi9 have busif0 to busif7,
currently only busif0 is used by all ssi.
But tdm split and tdm ex-split mode, which require busif1 to
busif7.

This patch adds kctrl in ssi for dai-link, to make it possible
to configure the busif used by each dai-link.
Also adds rsnd_dma_addr_update() interface to make it possible
to update dma data address when there is change in condition
of dai connection.

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/dma.c  | 32 
 sound/soc/sh/rcar/rsnd.h |  2 ++
 sound/soc/sh/rcar/ssi.c  | 31 ++-
 3 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c
index 6d1947515dc8..8c284fd73fc1 100644
--- a/sound/soc/sh/rcar/dma.c
+++ b/sound/soc/sh/rcar/dma.c
@@ -792,6 +792,38 @@ int rsnd_dma_attach(struct rsnd_dai_stream *io, struct 
rsnd_mod *mod,
return rsnd_dai_connect(*dma_mod, io, (*dma_mod)->type);
 }
 
+void rsnd_dma_addr_update(struct rsnd_dai_stream *io,
+ struct rsnd_mod *mod,
+ struct rsnd_mod *dma_mod)
+{
+   struct rsnd_mod *mod_from = NULL;
+   struct rsnd_mod *mod_to = NULL;
+   struct rsnd_priv *priv = rsnd_io_to_priv(io);
+   struct rsnd_dma_ctrl *dmac = rsnd_priv_to_dmac(priv);
+   struct device *dev = rsnd_priv_to_dev(priv);
+   int is_play = rsnd_io_is_play(io);
+   struct rsnd_dma *dma = rsnd_mod_to_dma(dma_mod);
+
+   if (!dmac)
+   return;
+
+   rsnd_dma_of_path(mod, io, is_play, _from, _to);
+
+   dma->src_addr = rsnd_dma_addr(io, mod_from, is_play, 1);
+   dma->dst_addr = rsnd_dma_addr(io, mod_to,   is_play, 0);
+
+   if (mod_from && mod_to) {
+   struct rsnd_dmapp *dmapp = rsnd_dma_to_dmapp(dma);
+
+   dmapp->chcr = rsnd_dmapp_get_chcr(io, mod_from, mod_to) |
+ PDMACHCR_DE;
+   }
+
+   dev_dbg(dev, "%s[%d] %pad -> %pad\n",
+   rsnd_mod_name(mod), rsnd_mod_id(mod),
+   >src_addr, >dst_addr);
+}
+
 int rsnd_dma_probe(struct rsnd_priv *priv)
 {
struct platform_device *pdev = rsnd_priv_to_pdev(priv);
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 59b6d89d8edc..6c16d8403f7a 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -233,6 +233,8 @@ u32 rsnd_get_busif_shift(struct rsnd_dai_stream *io, struct 
rsnd_mod *mod);
  */
 int rsnd_dma_attach(struct rsnd_dai_stream *io,
struct rsnd_mod *mod, struct rsnd_mod **dma_mod);
+void rsnd_dma_addr_update(struct rsnd_dai_stream *io,
+ struct rsnd_mod *mod, struct rsnd_mod *dma_mod);
 int rsnd_dma_probe(struct rsnd_priv *priv);
 struct dma_chan *rsnd_dma_request_channel(struct device_node *of_node,
  struct rsnd_mod *mod, char *name);
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 4ac4b5b75ae2..b469db238697 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -160,6 +160,15 @@ int rsnd_ssi_get_busif(struct rsnd_dai_stream *io)
return io->busif->val;
 }
 
+static void rsnd_ssi_set_busif(struct rsnd_dai_stream *io,
+  struct rsnd_mod *mod)
+{
+   if (!rsnd_ssi_use_busif(io))
+   return;
+
+   rsnd_dma_addr_update(io, mod, io->dma);
+}
+
 static void rsnd_ssi_status_clear(struct rsnd_mod *mod)
 {
rsnd_mod_write(mod, SSISR, 0);
@@ -718,6 +727,10 @@ static int rsnd_ssi_pcm_new(struct rsnd_mod *mod,
struct rsnd_dai_stream *io,
struct snd_soc_pcm_runtime *rtd)
 {
+   int is_play = rsnd_io_is_play(io);
+   int id = rsnd_mod_id(mod);
+   int ret = 0;
+
/*
 * rsnd_rdai_is_clk_master() will be enabled after set_fmt,
 * and, pcm_new will be called after it.
@@ -725,7 +738,23 @@ static int rsnd_ssi_pcm_new(struct rsnd_mod *mod,
 */
rsnd_ssi_parent_attach(mod, io);
 
-   return 0;
+   if (!rsnd_ssi_use_busif(io))
+   return 0;
+
+   if (rsnd_ssi_is_multi_slave(mod, io))
+   return 0;
+
+   /* SSI5 to SSI8 only have one BUSIF */
+   if (id <= 4 || id == 9)
+   ret = rsnd_kctrl_new_s(mod, io, rtd,
+  is_play ?
+  "SSI Out BUSIF" :
+  "SSI In BUSIF",
+  rsnd_kctrl_accept_anytime,
+  rsnd_ssi_set_busif,
+  io->busif, 7);
+
+   return ret;
 }
 
 static int rsnd_ssi_common_probe(struct rsnd_mod *mod,
-- 
2.17.0



[PATCH linux-next 10/10] ASoC: rsnd: Add kctrl to configure dai's busif

2018-09-26 Thread jiada_wang
From: Jiada Wang 

ssi0, ssi1, ssi2, ssi3, ssi4 and ssi9 have busif0 to busif7,
currently only busif0 is used by all ssi.
But tdm split and tdm ex-split mode, which require busif1 to
busif7.

This patch adds kctrl in ssi for dai-link, to make it possible
to configure the busif used by each dai-link.
Also adds rsnd_dma_addr_update() interface to make it possible
to update dma data address when there is change in condition
of dai connection.

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/dma.c  | 32 
 sound/soc/sh/rcar/rsnd.h |  2 ++
 sound/soc/sh/rcar/ssi.c  | 31 ++-
 3 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c
index 6d1947515dc8..8c284fd73fc1 100644
--- a/sound/soc/sh/rcar/dma.c
+++ b/sound/soc/sh/rcar/dma.c
@@ -792,6 +792,38 @@ int rsnd_dma_attach(struct rsnd_dai_stream *io, struct 
rsnd_mod *mod,
return rsnd_dai_connect(*dma_mod, io, (*dma_mod)->type);
 }
 
+void rsnd_dma_addr_update(struct rsnd_dai_stream *io,
+ struct rsnd_mod *mod,
+ struct rsnd_mod *dma_mod)
+{
+   struct rsnd_mod *mod_from = NULL;
+   struct rsnd_mod *mod_to = NULL;
+   struct rsnd_priv *priv = rsnd_io_to_priv(io);
+   struct rsnd_dma_ctrl *dmac = rsnd_priv_to_dmac(priv);
+   struct device *dev = rsnd_priv_to_dev(priv);
+   int is_play = rsnd_io_is_play(io);
+   struct rsnd_dma *dma = rsnd_mod_to_dma(dma_mod);
+
+   if (!dmac)
+   return;
+
+   rsnd_dma_of_path(mod, io, is_play, _from, _to);
+
+   dma->src_addr = rsnd_dma_addr(io, mod_from, is_play, 1);
+   dma->dst_addr = rsnd_dma_addr(io, mod_to,   is_play, 0);
+
+   if (mod_from && mod_to) {
+   struct rsnd_dmapp *dmapp = rsnd_dma_to_dmapp(dma);
+
+   dmapp->chcr = rsnd_dmapp_get_chcr(io, mod_from, mod_to) |
+ PDMACHCR_DE;
+   }
+
+   dev_dbg(dev, "%s[%d] %pad -> %pad\n",
+   rsnd_mod_name(mod), rsnd_mod_id(mod),
+   >src_addr, >dst_addr);
+}
+
 int rsnd_dma_probe(struct rsnd_priv *priv)
 {
struct platform_device *pdev = rsnd_priv_to_pdev(priv);
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 59b6d89d8edc..6c16d8403f7a 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -233,6 +233,8 @@ u32 rsnd_get_busif_shift(struct rsnd_dai_stream *io, struct 
rsnd_mod *mod);
  */
 int rsnd_dma_attach(struct rsnd_dai_stream *io,
struct rsnd_mod *mod, struct rsnd_mod **dma_mod);
+void rsnd_dma_addr_update(struct rsnd_dai_stream *io,
+ struct rsnd_mod *mod, struct rsnd_mod *dma_mod);
 int rsnd_dma_probe(struct rsnd_priv *priv);
 struct dma_chan *rsnd_dma_request_channel(struct device_node *of_node,
  struct rsnd_mod *mod, char *name);
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 4ac4b5b75ae2..b469db238697 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -160,6 +160,15 @@ int rsnd_ssi_get_busif(struct rsnd_dai_stream *io)
return io->busif->val;
 }
 
+static void rsnd_ssi_set_busif(struct rsnd_dai_stream *io,
+  struct rsnd_mod *mod)
+{
+   if (!rsnd_ssi_use_busif(io))
+   return;
+
+   rsnd_dma_addr_update(io, mod, io->dma);
+}
+
 static void rsnd_ssi_status_clear(struct rsnd_mod *mod)
 {
rsnd_mod_write(mod, SSISR, 0);
@@ -718,6 +727,10 @@ static int rsnd_ssi_pcm_new(struct rsnd_mod *mod,
struct rsnd_dai_stream *io,
struct snd_soc_pcm_runtime *rtd)
 {
+   int is_play = rsnd_io_is_play(io);
+   int id = rsnd_mod_id(mod);
+   int ret = 0;
+
/*
 * rsnd_rdai_is_clk_master() will be enabled after set_fmt,
 * and, pcm_new will be called after it.
@@ -725,7 +738,23 @@ static int rsnd_ssi_pcm_new(struct rsnd_mod *mod,
 */
rsnd_ssi_parent_attach(mod, io);
 
-   return 0;
+   if (!rsnd_ssi_use_busif(io))
+   return 0;
+
+   if (rsnd_ssi_is_multi_slave(mod, io))
+   return 0;
+
+   /* SSI5 to SSI8 only have one BUSIF */
+   if (id <= 4 || id == 9)
+   ret = rsnd_kctrl_new_s(mod, io, rtd,
+  is_play ?
+  "SSI Out BUSIF" :
+  "SSI In BUSIF",
+  rsnd_kctrl_accept_anytime,
+  rsnd_ssi_set_busif,
+  io->busif, 7);
+
+   return ret;
 }
 
 static int rsnd_ssi_common_probe(struct rsnd_mod *mod,
-- 
2.17.0



[PATCH linux-next 09/10] ASoC: rsnd: add busif property to dai stream

2018-09-26 Thread jiada_wang
From: Jiada Wang 

SSI may use different busif for data transfer, this patch
adds busif property to each dai stream, to indicate the
busif used by playback/capture stream.

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/core.c | 16 +++-
 sound/soc/sh/rcar/rsnd.h |  3 +++
 sound/soc/sh/rcar/ssi.c  |  5 -
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 40d7dc4f7839..aee3132c72b9 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -560,6 +560,14 @@ struct rsnd_dai *rsnd_rdai_get(struct rsnd_priv *priv, int 
id)
return priv->rdai + id;
 }
 
+struct rsnd_kctrl_cfg_s *rsnd_busif_get(struct rsnd_priv *priv, int id)
+{
+   if ((id < 0) || (id >= 2 * rsnd_rdai_nr(priv)))
+   return NULL;
+
+   return priv->busif + id;
+}
+
 static struct snd_soc_dai_driver
 *rsnd_daidrv_get(struct rsnd_priv *priv, int id)
 {
@@ -1045,6 +1053,9 @@ static void __rsnd_dai_probe(struct rsnd_priv *priv,
io_playback = >playback;
io_capture  = >capture;
 
+   io_playback->busif = rsnd_busif_get(priv, dai_i);
+   io_capture->busif  = rsnd_busif_get(priv, rsnd_rdai_nr(priv) + dai_i);
+
snprintf(rdai->name, RSND_DAI_NAME_SIZE, "rsnd-dai.%d", dai_i);
 
rdai->priv  = priv;
@@ -1108,6 +1119,7 @@ static int rsnd_dai_probe(struct rsnd_priv *priv)
struct snd_soc_dai_driver *rdrv;
struct device *dev = rsnd_priv_to_dev(priv);
struct rsnd_dai *rdai;
+   struct rsnd_kctrl_cfg_s *busif;
int nr;
int is_graph;
int dai_i;
@@ -1123,12 +1135,14 @@ static int rsnd_dai_probe(struct rsnd_priv *priv)
 
rdrv = devm_kcalloc(dev, nr, sizeof(*rdrv), GFP_KERNEL);
rdai = devm_kcalloc(dev, nr, sizeof(*rdai), GFP_KERNEL);
-   if (!rdrv || !rdai)
+   busif = devm_kcalloc(dev, 2 * nr, sizeof(*busif), GFP_KERNEL);
+   if (!rdrv || !rdai || !busif)
return -ENOMEM;
 
priv->rdai_nr   = nr;
priv->daidrv= rdrv;
priv->rdai  = rdai;
+   priv->busif = busif;
 
/*
 * parse all dai
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 4464d1d0a042..59b6d89d8edc 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -456,6 +456,7 @@ struct rsnd_dai_stream {
struct rsnd_mod *dma;
struct rsnd_dai *rdai;
struct device *dmac_dev; /* for IPMMU */
+   struct rsnd_kctrl_cfg_s *busif;
u32 parent_ssi_status;
 };
 #define rsnd_io_to_mod(io, i)  ((i) < RSND_MOD_MAX ? (io)->mod[(i)] : NULL)
@@ -629,6 +630,8 @@ struct rsnd_priv {
 */
struct snd_soc_dai_driver *daidrv;
struct rsnd_dai *rdai;
+   struct rsnd_kctrl_cfg_s *busif;
+
int rdai_nr;
 };
 
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 75a3d15084c2..4ac4b5b75ae2 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -154,7 +154,10 @@ int rsnd_ssi_use_busif(struct rsnd_dai_stream *io)
 
 int rsnd_ssi_get_busif(struct rsnd_dai_stream *io)
 {
-   return 0; /* BUSIF0 only for now */
+   if (!rsnd_ssi_use_busif(io))
+   return 0;
+
+   return io->busif->val;
 }
 
 static void rsnd_ssi_status_clear(struct rsnd_mod *mod)
-- 
2.17.0



[PATCH linux-next 09/10] ASoC: rsnd: add busif property to dai stream

2018-09-26 Thread jiada_wang
From: Jiada Wang 

SSI may use different busif for data transfer, this patch
adds busif property to each dai stream, to indicate the
busif used by playback/capture stream.

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/core.c | 16 +++-
 sound/soc/sh/rcar/rsnd.h |  3 +++
 sound/soc/sh/rcar/ssi.c  |  5 -
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 40d7dc4f7839..aee3132c72b9 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -560,6 +560,14 @@ struct rsnd_dai *rsnd_rdai_get(struct rsnd_priv *priv, int 
id)
return priv->rdai + id;
 }
 
+struct rsnd_kctrl_cfg_s *rsnd_busif_get(struct rsnd_priv *priv, int id)
+{
+   if ((id < 0) || (id >= 2 * rsnd_rdai_nr(priv)))
+   return NULL;
+
+   return priv->busif + id;
+}
+
 static struct snd_soc_dai_driver
 *rsnd_daidrv_get(struct rsnd_priv *priv, int id)
 {
@@ -1045,6 +1053,9 @@ static void __rsnd_dai_probe(struct rsnd_priv *priv,
io_playback = >playback;
io_capture  = >capture;
 
+   io_playback->busif = rsnd_busif_get(priv, dai_i);
+   io_capture->busif  = rsnd_busif_get(priv, rsnd_rdai_nr(priv) + dai_i);
+
snprintf(rdai->name, RSND_DAI_NAME_SIZE, "rsnd-dai.%d", dai_i);
 
rdai->priv  = priv;
@@ -1108,6 +1119,7 @@ static int rsnd_dai_probe(struct rsnd_priv *priv)
struct snd_soc_dai_driver *rdrv;
struct device *dev = rsnd_priv_to_dev(priv);
struct rsnd_dai *rdai;
+   struct rsnd_kctrl_cfg_s *busif;
int nr;
int is_graph;
int dai_i;
@@ -1123,12 +1135,14 @@ static int rsnd_dai_probe(struct rsnd_priv *priv)
 
rdrv = devm_kcalloc(dev, nr, sizeof(*rdrv), GFP_KERNEL);
rdai = devm_kcalloc(dev, nr, sizeof(*rdai), GFP_KERNEL);
-   if (!rdrv || !rdai)
+   busif = devm_kcalloc(dev, 2 * nr, sizeof(*busif), GFP_KERNEL);
+   if (!rdrv || !rdai || !busif)
return -ENOMEM;
 
priv->rdai_nr   = nr;
priv->daidrv= rdrv;
priv->rdai  = rdai;
+   priv->busif = busif;
 
/*
 * parse all dai
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 4464d1d0a042..59b6d89d8edc 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -456,6 +456,7 @@ struct rsnd_dai_stream {
struct rsnd_mod *dma;
struct rsnd_dai *rdai;
struct device *dmac_dev; /* for IPMMU */
+   struct rsnd_kctrl_cfg_s *busif;
u32 parent_ssi_status;
 };
 #define rsnd_io_to_mod(io, i)  ((i) < RSND_MOD_MAX ? (io)->mod[(i)] : NULL)
@@ -629,6 +630,8 @@ struct rsnd_priv {
 */
struct snd_soc_dai_driver *daidrv;
struct rsnd_dai *rdai;
+   struct rsnd_kctrl_cfg_s *busif;
+
int rdai_nr;
 };
 
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 75a3d15084c2..4ac4b5b75ae2 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -154,7 +154,10 @@ int rsnd_ssi_use_busif(struct rsnd_dai_stream *io)
 
 int rsnd_ssi_get_busif(struct rsnd_dai_stream *io)
 {
-   return 0; /* BUSIF0 only for now */
+   if (!rsnd_ssi_use_busif(io))
+   return 0;
+
+   return io->busif->val;
 }
 
 static void rsnd_ssi_status_clear(struct rsnd_mod *mod)
-- 
2.17.0



[PATCH linux-next 08/10] arm64: r8a77965: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index fd00010a5ed7..6c0d5053a81c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1405,7 +1405,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
/* placeholder */
 
rcar_sound,dvc {
-- 
2.17.0



[PATCH linux-next 08/10] arm64: r8a77965: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index fd00010a5ed7..6c0d5053a81c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1405,7 +1405,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
/* placeholder */
 
rcar_sound,dvc {
-- 
2.17.0



[PATCH linux-next 07/10] arm64: r8a774a1: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index c9aad3e3b1b0..c3e0f2151176 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1120,7 +1120,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
clocks = < CPG_MOD 1005>,
-- 
2.17.0



[PATCH linux-next 07/10] arm64: r8a774a1: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index c9aad3e3b1b0..c3e0f2151176 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1120,7 +1120,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
clocks = < CPG_MOD 1005>,
-- 
2.17.0



[PATCH linux-next 05/10] arm64: r8a7795: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 0a66bda7124f..32d191102a81 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1796,7 +1796,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
clocks = < CPG_MOD 1005>,
-- 
2.17.0



[RESEND PATCH] ARM: prevent tracing IPI_CPU_BACKTRACE

2018-09-26 Thread Chunyan Zhang
From: Arnd Bergmann 

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds 
[-Werror=array-bounds]
trace_ipi_raise(target, ipi_types[ipinr]);

This is a correct warning as we actually overflow the array here.

This patch raise_nmi() to call __smp_cross_call() instead of
smp_cross_call(), to avoid calling into ftrace. For clarification,
I'm also adding a two new code comments describing how this one
is special.

The warning appears to have shown up after patch e7273ff49acf
("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which
changed the number assignment from '15' to '8', but as far as I can
tell has existed since the IPI tracepoints were first introduced.
If we decide to backport this patch to stable kernels, we probably
need to backport e7273ff49acf as well.

Resubmiting this patch is because that I found coverity is complaining
the issue this patch fixed, and also I got the traces like below:
"ipi_raise: target_mask=0001 (machine_suspend)" which actually was
the TPS of suspend_resume[1] rather than ipi_raise.

[1]
https://elixir.bootlin.com/linux/latest/source/kernel/power/suspend.c#L80

Signed-off-by: Arnd Bergmann 
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
Signed-off-by: Chunyan Zhang 
---
 arch/arm/include/asm/hardirq.h | 1 +
 arch/arm/kernel/smp.c  | 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index cba23ea..7a88f16 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
 #define NR_IPI 7
 
 typedef struct {
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 0978282..123be77 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -75,6 +75,10 @@ enum ipi_msg_type {
IPI_CPU_STOP,
IPI_IRQ_WORK,
IPI_COMPLETION,
+   /*
+* CPU_BACKTRACE is special and not included in NR_IPI
+* or tracable with trace_ipi_*
+*/
IPI_CPU_BACKTRACE,
/*
 * SGI8-15 can be reserved by secure firmware, and thus may
@@ -755,7 +759,7 @@ core_initcall(register_cpufreq_notifier);
 
 static void raise_nmi(cpumask_t *mask)
 {
-   smp_cross_call(mask, IPI_CPU_BACKTRACE);
+   _smp_cross_call(mask, IPI_CPU_BACKTRACE);
 }
 
 void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
-- 
2.7.4



[PATCH linux-next 06/10] arm64: r8a7796: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index e9b05d997c4e..827a704154cd 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1670,7 +1670,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
clocks = < CPG_MOD 1005>,
-- 
2.17.0



[PATCH linux-next 05/10] arm64: r8a7795: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 0a66bda7124f..32d191102a81 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1796,7 +1796,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
clocks = < CPG_MOD 1005>,
-- 
2.17.0



[RESEND PATCH] ARM: prevent tracing IPI_CPU_BACKTRACE

2018-09-26 Thread Chunyan Zhang
From: Arnd Bergmann 

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds 
[-Werror=array-bounds]
trace_ipi_raise(target, ipi_types[ipinr]);

This is a correct warning as we actually overflow the array here.

This patch raise_nmi() to call __smp_cross_call() instead of
smp_cross_call(), to avoid calling into ftrace. For clarification,
I'm also adding a two new code comments describing how this one
is special.

The warning appears to have shown up after patch e7273ff49acf
("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which
changed the number assignment from '15' to '8', but as far as I can
tell has existed since the IPI tracepoints were first introduced.
If we decide to backport this patch to stable kernels, we probably
need to backport e7273ff49acf as well.

Resubmiting this patch is because that I found coverity is complaining
the issue this patch fixed, and also I got the traces like below:
"ipi_raise: target_mask=0001 (machine_suspend)" which actually was
the TPS of suspend_resume[1] rather than ipi_raise.

[1]
https://elixir.bootlin.com/linux/latest/source/kernel/power/suspend.c#L80

Signed-off-by: Arnd Bergmann 
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
Signed-off-by: Chunyan Zhang 
---
 arch/arm/include/asm/hardirq.h | 1 +
 arch/arm/kernel/smp.c  | 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index cba23ea..7a88f16 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
 #define NR_IPI 7
 
 typedef struct {
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 0978282..123be77 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -75,6 +75,10 @@ enum ipi_msg_type {
IPI_CPU_STOP,
IPI_IRQ_WORK,
IPI_COMPLETION,
+   /*
+* CPU_BACKTRACE is special and not included in NR_IPI
+* or tracable with trace_ipi_*
+*/
IPI_CPU_BACKTRACE,
/*
 * SGI8-15 can be reserved by secure firmware, and thus may
@@ -755,7 +759,7 @@ core_initcall(register_cpufreq_notifier);
 
 static void raise_nmi(cpumask_t *mask)
 {
-   smp_cross_call(mask, IPI_CPU_BACKTRACE);
+   _smp_cross_call(mask, IPI_CPU_BACKTRACE);
 }
 
 void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
-- 
2.7.4



[PATCH linux-next 06/10] arm64: r8a7796: change to use extended audio dmac register

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index e9b05d997c4e..827a704154cd 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1670,7 +1670,7 @@
<0 0xec5a 0 0x100>,  /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>,  /* SSI */
-   <0 0xec74 0 0x200>;  /* Audio DMAC peri 
peri*/
+   <0 0xec76 0 0x200>;  /* Audio DMAC peri 
peri*/
reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
clocks = < CPG_MOD 1005>,
-- 
2.17.0



Re: [PATCH V5 17/30] csky: Misc headers

2018-09-26 Thread Guo Ren
On Tue, Sep 25, 2018 at 12:45:41PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 25, 2018 at 12:08:03PM +0200, Andrea Parri wrote:
> > Hi Guo,
> > 
> > > +/*
> > > + * set_bit - Atomically set a bit in memory
> > > + * @nr: the bit to set
> > > + * @addr: the address to start counting from
> > > + *
> > > + * This function is atomic and may not be reordered.  See __set_bit()
> > > + * if you do not require the atomic guarantees.
> > > + *
> > > + * Note: there are no guarantees that this function will not be reordered
> > > + * on non x86 architectures, so if you are writing portable code,
> > > + * make sure not to rely on its reordering guarantees.
> > > + *
> > > + * Note that @nr may be almost arbitrarily large; this function is not
> > > + * restricted to acting on a single-word quantity.
> > > + */
> > > +static inline void set_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p  |= mask; */
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w  %0, (%2)\n"
> > > + "   or32%0, %0, %1  \n"
> > > + "   stex.w  %0, (%2)\n"
> > > + "   bez %0, 1b  \n"
> > > + : "="(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > > +
> > > +/**
> > > + * clear_bit - Clears a bit in memory
> > > + * @nr: Bit to clear
> > > + * @addr: Address to start counting from
> > > + *
> > > + * clear_bit() is atomic and may not be reordered.  However, it does
> > > + * not contain a memory barrier, so if it is used for locking purposes,
> > > + * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
> > > + * in order to ensure changes are visible on other processors.
> > > + */
> > > +static inline void clear_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p &= ~mask; */
> > > + mask = ~mask;
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w  %0, (%2)\n"
> > > + "   and32   %0, %0, %1  \n"
> > > + "   stex.w  %0, (%2)\n"
> > > + "   bez %0, 1b  \n"
> > > + : "="(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > > +
> > > +/**
> > > + * change_bit - Toggle a bit in memory
> > > + * @nr: Bit to change
> > > + * @addr: Address to start counting from
> > > + *
> > > + * change_bit() is atomic and may not be reordered. It may be
> > > + * reordered on other architectures than x86.
> > > + * Note that @nr may be almost arbitrarily large; this function is not
> > > + * restricted to acting on a single-word quantity.
> > > + */
> > > +static inline void change_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p ^= mask; */
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w  %0, (%2)\n"
> > > + "   xor32   %0, %0, %1  \n"
> > > + "   stex.w  %0, (%2)\n"
> > > + "   bez %0, 1b  \n"
> > > + : "="(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > 
> > The {set,clear,change}_bit() operations don't have to be ordered: you
> > might want to remove the above smp_mb()s (and adjust the comments).
I confused it with cmpxchg, seems cmpxchg need smp_mb() before
See: https://lkml.org/lkml/2018/7/6/383

> Better yet, you can entirely delete all that and use
> asm-generic/bitops/atomic.h instead.
Yes, approve. Seems I only need care about asm/atomic.h, it's good for
me.

Best Regards
 Guo Ren


Re: [PATCH V5 17/30] csky: Misc headers

2018-09-26 Thread Guo Ren
On Tue, Sep 25, 2018 at 12:45:41PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 25, 2018 at 12:08:03PM +0200, Andrea Parri wrote:
> > Hi Guo,
> > 
> > > +/*
> > > + * set_bit - Atomically set a bit in memory
> > > + * @nr: the bit to set
> > > + * @addr: the address to start counting from
> > > + *
> > > + * This function is atomic and may not be reordered.  See __set_bit()
> > > + * if you do not require the atomic guarantees.
> > > + *
> > > + * Note: there are no guarantees that this function will not be reordered
> > > + * on non x86 architectures, so if you are writing portable code,
> > > + * make sure not to rely on its reordering guarantees.
> > > + *
> > > + * Note that @nr may be almost arbitrarily large; this function is not
> > > + * restricted to acting on a single-word quantity.
> > > + */
> > > +static inline void set_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p  |= mask; */
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w  %0, (%2)\n"
> > > + "   or32%0, %0, %1  \n"
> > > + "   stex.w  %0, (%2)\n"
> > > + "   bez %0, 1b  \n"
> > > + : "="(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > > +
> > > +/**
> > > + * clear_bit - Clears a bit in memory
> > > + * @nr: Bit to clear
> > > + * @addr: Address to start counting from
> > > + *
> > > + * clear_bit() is atomic and may not be reordered.  However, it does
> > > + * not contain a memory barrier, so if it is used for locking purposes,
> > > + * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
> > > + * in order to ensure changes are visible on other processors.
> > > + */
> > > +static inline void clear_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p &= ~mask; */
> > > + mask = ~mask;
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w  %0, (%2)\n"
> > > + "   and32   %0, %0, %1  \n"
> > > + "   stex.w  %0, (%2)\n"
> > > + "   bez %0, 1b  \n"
> > > + : "="(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > > +
> > > +/**
> > > + * change_bit - Toggle a bit in memory
> > > + * @nr: Bit to change
> > > + * @addr: Address to start counting from
> > > + *
> > > + * change_bit() is atomic and may not be reordered. It may be
> > > + * reordered on other architectures than x86.
> > > + * Note that @nr may be almost arbitrarily large; this function is not
> > > + * restricted to acting on a single-word quantity.
> > > + */
> > > +static inline void change_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p ^= mask; */
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w  %0, (%2)\n"
> > > + "   xor32   %0, %0, %1  \n"
> > > + "   stex.w  %0, (%2)\n"
> > > + "   bez %0, 1b  \n"
> > > + : "="(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > 
> > The {set,clear,change}_bit() operations don't have to be ordered: you
> > might want to remove the above smp_mb()s (and adjust the comments).
I confused it with cmpxchg, seems cmpxchg need smp_mb() before
See: https://lkml.org/lkml/2018/7/6/383

> Better yet, you can entirely delete all that and use
> asm-generic/bitops/atomic.h instead.
Yes, approve. Seems I only need care about asm/atomic.h, it's good for
me.

Best Regards
 Guo Ren


Re: [PATCH v2] IB/rxe: Avoid implicit enum conversions in rxe_init functions

2018-09-26 Thread Jason Gunthorpe
On Wed, Sep 26, 2018 at 10:01:57PM -0700, Nathan Chancellor wrote:
> Clang warns when an emumerated type is implicitly converted to another.
> 
> drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
> from enumeration type 'enum rxe_device_param' to different enumeration
> type 'enum ib_atomic_cap' [-Wenum-conversion]
> rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
> ~ ^~
> drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_port_state' [-Wenum-conversion]
> port->attr.state= RXE_PORT_STATE;
> ~ ^~
> drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> port->attr.max_mtu  = RXE_PORT_MAX_MTU;
> ~ ^~~~
> drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
> ~ ^~~
> drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
> ~~ ^~~
> 5 warnings generated.
> 
> Use the appropriate values from the expected enumerated type so no
> conversion needs to happen.
> 
> Reported-by: Nick Desaulniers 
> Signed-off-by: Nathan Chancellor 
> 
> v1 -> v2:
> 
> * Don't cast, just use the expecting enumerated value directly, per
>   Jason's request
> 
>  drivers/infiniband/sw/rxe/rxe.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
> index 10999fa69281..2f4e57886b89 100644
> +++ b/drivers/infiniband/sw/rxe/rxe.c
> @@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
>   rxe->attr.max_res_rd_atom   = RXE_MAX_RES_RD_ATOM;
>   rxe->attr.max_qp_init_rd_atom   = RXE_MAX_QP_INIT_RD_ATOM;
>   rxe->attr.max_ee_init_rd_atom   = RXE_MAX_EE_INIT_RD_ATOM;
> - rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
> + rxe->attr.atomic_cap= IB_ATOMIC_HCA;
>   rxe->attr.max_ee= RXE_MAX_EE;
>   rxe->attr.max_rdd   = RXE_MAX_RDD;
>   rxe->attr.max_mw= RXE_MAX_MW;
> @@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
>  /* initialize port attributes */
>  static int rxe_init_port_param(struct rxe_port *port)
>  {
> - port->attr.state= RXE_PORT_STATE;
> - port->attr.max_mtu  = RXE_PORT_MAX_MTU;
> - port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
> + port->attr.state= IB_PORT_DOWN;
> + port->attr.max_mtu  = IB_MTU_4096;
> + port->attr.active_mtu   = IB_MTU_256;
>   port->attr.gid_tbl_len  = RXE_PORT_GID_TBL_LEN;
>   port->attr.port_cap_flags   = RXE_PORT_PORT_CAP_FLAGS;
>   port->attr.max_msg_sz   = RXE_PORT_MAX_MSG_SZ;
> @@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
>   port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
>   port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
>   port->attr.phys_state   = RXE_PORT_PHYS_STATE;
> - port->mtu_cap   =
> - ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
> + port->mtu_cap   = ib_mtu_enum_to_int(IB_MTU_256);
>   port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
>  
>   return 0;

These are the only place some of these values are used, so declaration
should be eliminated as well.

Jason


Re: [PATCH v2] IB/rxe: Avoid implicit enum conversions in rxe_init functions

2018-09-26 Thread Jason Gunthorpe
On Wed, Sep 26, 2018 at 10:01:57PM -0700, Nathan Chancellor wrote:
> Clang warns when an emumerated type is implicitly converted to another.
> 
> drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
> from enumeration type 'enum rxe_device_param' to different enumeration
> type 'enum ib_atomic_cap' [-Wenum-conversion]
> rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
> ~ ^~
> drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_port_state' [-Wenum-conversion]
> port->attr.state= RXE_PORT_STATE;
> ~ ^~
> drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> port->attr.max_mtu  = RXE_PORT_MAX_MTU;
> ~ ^~~~
> drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
> ~ ^~~
> drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
> ~~ ^~~
> 5 warnings generated.
> 
> Use the appropriate values from the expected enumerated type so no
> conversion needs to happen.
> 
> Reported-by: Nick Desaulniers 
> Signed-off-by: Nathan Chancellor 
> 
> v1 -> v2:
> 
> * Don't cast, just use the expecting enumerated value directly, per
>   Jason's request
> 
>  drivers/infiniband/sw/rxe/rxe.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
> index 10999fa69281..2f4e57886b89 100644
> +++ b/drivers/infiniband/sw/rxe/rxe.c
> @@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
>   rxe->attr.max_res_rd_atom   = RXE_MAX_RES_RD_ATOM;
>   rxe->attr.max_qp_init_rd_atom   = RXE_MAX_QP_INIT_RD_ATOM;
>   rxe->attr.max_ee_init_rd_atom   = RXE_MAX_EE_INIT_RD_ATOM;
> - rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
> + rxe->attr.atomic_cap= IB_ATOMIC_HCA;
>   rxe->attr.max_ee= RXE_MAX_EE;
>   rxe->attr.max_rdd   = RXE_MAX_RDD;
>   rxe->attr.max_mw= RXE_MAX_MW;
> @@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
>  /* initialize port attributes */
>  static int rxe_init_port_param(struct rxe_port *port)
>  {
> - port->attr.state= RXE_PORT_STATE;
> - port->attr.max_mtu  = RXE_PORT_MAX_MTU;
> - port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
> + port->attr.state= IB_PORT_DOWN;
> + port->attr.max_mtu  = IB_MTU_4096;
> + port->attr.active_mtu   = IB_MTU_256;
>   port->attr.gid_tbl_len  = RXE_PORT_GID_TBL_LEN;
>   port->attr.port_cap_flags   = RXE_PORT_PORT_CAP_FLAGS;
>   port->attr.max_msg_sz   = RXE_PORT_MAX_MSG_SZ;
> @@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
>   port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
>   port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
>   port->attr.phys_state   = RXE_PORT_PHYS_STATE;
> - port->mtu_cap   =
> - ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
> + port->mtu_cap   = ib_mtu_enum_to_int(IB_MTU_256);
>   port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
>  
>   return 0;

These are the only place some of these values are used, so declaration
should be eliminated as well.

Jason


[PATCH linux-next 02/10] arm64: r8a7795: add dma request number for busif1 ~ busif7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

This patch adds dma request number for busif1 ~ busif7

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 130 ---
 1 file changed, 113 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5f2273caca4..0a66bda7124f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1923,53 +1923,149 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
-   dmas = < 0x01>, < 0x02>, 
< 0x15>, < 0x16>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x01>, < 0x02>,
+  < 0x15>, < 0x16>,
+  < 0x35>, < 0x36>,
+  < 0x37>, < 0x38>,
+  < 0x47>, < 0x48>,
+  < 0x3f>, < 0x40>,
+  < 0x43>, < 0x44>,
+  < 0x4f>, < 0x50>,
+  < 0x53>, < 0x54>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi1: ssi-1 {
-interrupts = ;
-   dmas = < 0x03>, < 0x04>, 
< 0x49>, < 0x4a>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   interrupts = ;
+   dmas = < 0x03>, < 0x04>,
+  < 0x49>, < 0x4a>,
+  < 0x4b>, < 0x4c>,
+  < 0x57>, < 0x58>,
+  < 0x59>, < 0x5a>,
+  < 0x5f>, < 0x60>,
+  < 0xc3>, < 0xc4>,
+  < 0xc7>, < 0xc8>,
+  < 0xcb>, < 0xcc>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
-   dmas = < 0x05>, < 0x06>, 
< 0x63>, < 0x64>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x05>, < 0x06>,
+  < 0x63>, < 0x64>,
+  < 0x67>, < 0x68>,
+  < 0x6b>, < 0x6c>,
+  < 0x6d>, < 0x6e>,
+  < 0xcf>, < 0xce>,
+  < 0xeb>, < 0xec>,
+  < 0xed>, < 0xee>,
+  < 0xef>, < 0xf0>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   

[PATCH linux-next 02/10] arm64: r8a7795: add dma request number for busif1 ~ busif7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

This patch adds dma request number for busif1 ~ busif7

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 130 ---
 1 file changed, 113 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5f2273caca4..0a66bda7124f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1923,53 +1923,149 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
-   dmas = < 0x01>, < 0x02>, 
< 0x15>, < 0x16>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x01>, < 0x02>,
+  < 0x15>, < 0x16>,
+  < 0x35>, < 0x36>,
+  < 0x37>, < 0x38>,
+  < 0x47>, < 0x48>,
+  < 0x3f>, < 0x40>,
+  < 0x43>, < 0x44>,
+  < 0x4f>, < 0x50>,
+  < 0x53>, < 0x54>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi1: ssi-1 {
-interrupts = ;
-   dmas = < 0x03>, < 0x04>, 
< 0x49>, < 0x4a>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   interrupts = ;
+   dmas = < 0x03>, < 0x04>,
+  < 0x49>, < 0x4a>,
+  < 0x4b>, < 0x4c>,
+  < 0x57>, < 0x58>,
+  < 0x59>, < 0x5a>,
+  < 0x5f>, < 0x60>,
+  < 0xc3>, < 0xc4>,
+  < 0xc7>, < 0xc8>,
+  < 0xcb>, < 0xcc>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
-   dmas = < 0x05>, < 0x06>, 
< 0x63>, < 0x64>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x05>, < 0x06>,
+  < 0x63>, < 0x64>,
+  < 0x67>, < 0x68>,
+  < 0x6b>, < 0x6c>,
+  < 0x6d>, < 0x6e>,
+  < 0xcf>, < 0xce>,
+  < 0xeb>, < 0xec>,
+  < 0xed>, < 0xee>,
+  < 0xef>, < 0xf0>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   

[PATCH linux-next 04/10] arm64: r8a774a1: add dma request number for busif1 ~ busif7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

This patch adds dma request number for busif1 ~ busif7

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 137 ++
 1 file changed, 117 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 012cbb64246e..c9aad3e3b1b0 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1247,55 +1247,152 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
-   dmas = < 0x01>, < 0x02>, 
< 0x15>, < 0x16>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x01>, < 0x02>,
+  < 0x15>, < 0x16>,
+  < 0x35>, < 0x36>,
+  < 0x37>, < 0x38>,
+  < 0x47>, < 0x48>,
+  < 0x3f>, < 0x40>,
+  < 0x43>, < 0x44>,
+  < 0x4f>, < 0x50>,
+  < 0x53>, < 0x54>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi1: ssi-1 {
interrupts = ;
-   dmas = < 0x03>, < 0x04>, 
< 0x49>, < 0x4a>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x03>, < 0x04>,
+  < 0x49>, < 0x4a>,
+  < 0x4b>, < 0x4c>,
+  < 0x57>, < 0x58>,
+  < 0x59>, < 0x5a>,
+  < 0x5f>, < 0x60>,
+  < 0xc3>, < 0xc4>,
+  < 0xc7>, < 0xc8>,
+  < 0xcb>, < 0xcc>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
-   dmas = < 0x05>, < 0x06>, 
< 0x63>, < 0x64>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x05>, < 0x06>,
+  < 0x63>, < 0x64>,
+  < 0x67>, < 0x68>,
+  < 0x6b>, < 0x6c>,
+  < 0x6d>, < 0x6e>,
+  < 0xcf>, < 0xce>,
+  < 0xeb>, < 0xec>,
+  < 0xed>, < 0xee>,
+  < 0xef>, < 0xf0>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";

[PATCH v13 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller

2018-09-26 Thread Baolin Wang
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.

Signed-off-by: Baolin Wang 
Acked-by: Pavel Machek 
---
Changes from v12:
 - None.

Changes from v11:
 - None.

Changes from v10:
 - Add duration alignment function suggested by Jacek.
 - Add acked tag from Pavel.

Changes from v9:
 - Optimize the ABI documentation file.
 - Update the brightness value in hardware pattern mode.

Changes from v8:
 - Optimize the ABI documentation file.

Changes from v7:
 - Add its own ABI documentation file.

Changes from v6:
 - None.

Changes from v5:
 - None.

Changes from v4:
 - None.

Changes from v3:
 - None.

Changes from v2:
 - None.

Changes from v1:
 - Remove pattern_get interface.
---
 .../ABI/testing/sysfs-class-led-driver-sc27xx  |   22 
 drivers/leds/leds-sc27xx-bltc.c|  121 
 2 files changed, 143 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx

diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx 
b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000..45b1e60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,22 @@
+What:  /sys/class/leds//hw_pattern
+Date:  September 2018
+KernelVersion: 4.20
+Description:
+   Specify a hardware pattern for the SC27XX LED. For the SC27XX
+   LED controller, it only supports 4 stages to make a single
+   hardware pattern, which is used to configure the rise time,
+   high time, fall time and low time for the breathing mode.
+
+   For the breathing mode, the SC27XX LED only expects one 
brightness
+   for the high stage. To be compatible with the hardware pattern
+   format, we should set brightness as 0 for rise stage, fall
+   stage and low stage.
+
+   Min stage duration: 125 ms
+   Max stage duration: 31875 ms
+
+   Since the stage duration step is 125 ms, the duration should be
+   a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ... 
31875ms.
+
+   Thus the format of the hardware pattern values should be:
+   "0 rise_duration brightness high_duration 0 fall_duration 0 
low_duration".
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..fecf27f 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,18 @@
 #define SC27XX_DUTY_MASK   GENMASK(15, 0)
 #define SC27XX_MOD_MASKGENMASK(7, 0)
 
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
 #define SC27XX_LEDS_OFFSET 0x10
 #define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
+/* Stage duration step, in milliseconds */
+#define SC27XX_LEDS_STEP   125
+/* Minimum and maximum duration, in milliseconds */
+#define SC27XX_DELTA_T_MIN SC27XX_LEDS_STEP
+#define SC27XX_DELTA_T_MAX (SC27XX_LEDS_STEP * 255)
 
 struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +132,113 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum 
led_brightness value)
return err;
 }
 
+static void sc27xx_led_clamp_align_delta_t(u32 *delta_t)
+{
+   u32 v, offset, t = *delta_t;
+
+   v = t + SC27XX_LEDS_STEP / 2;
+   v = clamp_t(u32, v, SC27XX_DELTA_T_MIN, SC27XX_DELTA_T_MAX);
+   offset = v - SC27XX_DELTA_T_MIN;
+   offset = SC27XX_LEDS_STEP * (offset / SC27XX_LEDS_STEP);
+
+   *delta_t = SC27XX_DELTA_T_MIN + offset;
+}
+
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+   struct sc27xx_led *leds = to_sc27xx_led(ldev);
+   struct regmap *regmap = leds->priv->regmap;
+   u32 base = sc27xx_led_get_offset(leds);
+   u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+   u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+   int err;
+
+   mutex_lock(>priv->lock);
+
+   /* Reset the rise, high, fall and low time to zero. */
+   regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+   regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+   err = regmap_update_bits(regmap, ctrl_base,
+   (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+   ldev->brightness = LED_OFF;
+
+   mutex_unlock(>priv->lock);
+
+   return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ u32 len, int repeat)
+{
+   struct sc27xx_led *leds = to_sc27xx_led(ldev);
+   u32 base = sc27xx_led_get_offset(leds);
+   u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+   u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+   struct regmap *regmap = leds->priv->regmap;
+  

[PATCH v13 1/2] leds: core: Introduce LED pattern trigger

2018-09-26 Thread Baolin Wang
This patch adds one new led trigger that LED device can configure
the software or hardware pattern and trigger it.

Consumers can write 'pattern' file to enable the software pattern
which alters the brightness for the specified duration with one
software timer.

Moreover consumers can write 'hw_pattern' file to enable the hardware
pattern for some LED controllers which can autonomously control
brightness over time, according to some preprogrammed hardware
patterns.

Signed-off-by: Raphael Teysseyre 
Signed-off-by: Baolin Wang 
---
Changes from v12:
 - Add gradual dimming support for software pattern.

Changes from v11:
 - Change -1 means repeat indefinitely.

Changes from v10:
 - Change 'int' to 'u32' for delta_t field.

Changes from v9:
 - None.

Changes from v8:
 - None.

Changes from v7:
 - Move the SC27XX hardware patterns description into its own ABI file.

Changes from v6:
 - Improve commit message.
 - Optimize the description of the hw_pattern file.
 - Simplify some logics.

Changes from v5:
 - Add one 'hw_pattern' file for hardware patterns.

Changes from v4:
 - Change the repeat file to return the originally written number.
 - Improve comments.
 - Fix some build warnings.

Changes from v3:
 - Reset pattern number to 0 if user provides incorrect pattern string.
 - Support one pattern.

Changes from v2:
 - Remove hardware_pattern boolen.
 - Chnage the pattern string format.

Changes from v1:
 - Use ATTRIBUTE_GROUPS() to define attributes.
 - Introduce hardware_pattern flag to determine if software pattern
 or hardware pattern.
 - Re-implement pattern_trig_store_pattern() function.
 - Remove pattern_get() interface.
 - Improve comments.
 - Other small optimization.
---
 .../ABI/testing/sysfs-class-led-trigger-pattern|   74 
 drivers/leds/trigger/Kconfig   |7 +
 drivers/leds/trigger/Makefile  |1 +
 drivers/leds/trigger/ledtrig-pattern.c |  406 
 include/linux/leds.h   |   15 +
 5 files changed, 503 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
 create mode 100644 drivers/leds/trigger/ledtrig-pattern.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
new file mode 100644
index 000..e84d42a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
@@ -0,0 +1,74 @@
+What:  /sys/class/leds//pattern
+Date:  September 2018
+KernelVersion: 4.20
+Description:
+   Specify a software pattern for the LED, that supports altering
+   the brightness for the specified duration with one software
+   timer. It can do gradual dimming and constant brightness.
+
+   The pattern is given by a series of tuples, of brightness and
+   duration (ms). The LED is expected to traverse the series and
+   each brightness value for the specified duration. Duration of
+   0 means brightness should immediately change to new value.
+
+   1. The gradual dimming format of the software pattern values
+   should be:
+   "brightness_1 duration_1 brightness_2 duration_2 brightness_3
+   duration_3 ...". For example:
+
+   echo 0 1000 255 2000 > pattern
+
+   It will make the LED go gradually from zero-intensity to max 
(255)
+   intensity in 1000 milliseconds, then back to zero intensity in 
2000
+   milliseconds:
+
+   LED brightness
+   ^
+   255-|   / \/ \/
+   |  /\ /\ /
+   | /   \  /   \  /
+   |/  \   /  \   /
+ 0-|   / \/ \/
+   +---0123456> time (s)
+
+   2. To make the LED go instantly from one brigntess value to 
another,
+   we should use use zero-time lengths. So the format should be:
+   "brightness_1 duration_1 brightness_1 0 brightness_2 duration_2
+   brightness_2 0 ...". For example:
+
+   echo 0 1000 0 0 255 2000 255 0 > pattern
+
+   It will make the LED stay off for one second, then stay at max 
brightness
+   for two seconds:
+
+   LED brightness
+   ^
+   255-|+-++-+
+   || || |
+   || || |
+   || || |
+ 0-|   -+ ++ +
+   +---0123456> time (s)
+
+What:  /sys/class/leds//hw_pattern
+Date:  September 

[PATCH linux-next 04/10] arm64: r8a774a1: add dma request number for busif1 ~ busif7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

This patch adds dma request number for busif1 ~ busif7

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 137 ++
 1 file changed, 117 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 012cbb64246e..c9aad3e3b1b0 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1247,55 +1247,152 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
-   dmas = < 0x01>, < 0x02>, 
< 0x15>, < 0x16>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x01>, < 0x02>,
+  < 0x15>, < 0x16>,
+  < 0x35>, < 0x36>,
+  < 0x37>, < 0x38>,
+  < 0x47>, < 0x48>,
+  < 0x3f>, < 0x40>,
+  < 0x43>, < 0x44>,
+  < 0x4f>, < 0x50>,
+  < 0x53>, < 0x54>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi1: ssi-1 {
interrupts = ;
-   dmas = < 0x03>, < 0x04>, 
< 0x49>, < 0x4a>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x03>, < 0x04>,
+  < 0x49>, < 0x4a>,
+  < 0x4b>, < 0x4c>,
+  < 0x57>, < 0x58>,
+  < 0x59>, < 0x5a>,
+  < 0x5f>, < 0x60>,
+  < 0xc3>, < 0xc4>,
+  < 0xc7>, < 0xc8>,
+  < 0xcb>, < 0xcc>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
-   dmas = < 0x05>, < 0x06>, 
< 0x63>, < 0x64>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x05>, < 0x06>,
+  < 0x63>, < 0x64>,
+  < 0x67>, < 0x68>,
+  < 0x6b>, < 0x6c>,
+  < 0x6d>, < 0x6e>,
+  < 0xcf>, < 0xce>,
+  < 0xeb>, < 0xec>,
+  < 0xed>, < 0xee>,
+  < 0xef>, < 0xf0>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";

[PATCH v13 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller

2018-09-26 Thread Baolin Wang
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.

Signed-off-by: Baolin Wang 
Acked-by: Pavel Machek 
---
Changes from v12:
 - None.

Changes from v11:
 - None.

Changes from v10:
 - Add duration alignment function suggested by Jacek.
 - Add acked tag from Pavel.

Changes from v9:
 - Optimize the ABI documentation file.
 - Update the brightness value in hardware pattern mode.

Changes from v8:
 - Optimize the ABI documentation file.

Changes from v7:
 - Add its own ABI documentation file.

Changes from v6:
 - None.

Changes from v5:
 - None.

Changes from v4:
 - None.

Changes from v3:
 - None.

Changes from v2:
 - None.

Changes from v1:
 - Remove pattern_get interface.
---
 .../ABI/testing/sysfs-class-led-driver-sc27xx  |   22 
 drivers/leds/leds-sc27xx-bltc.c|  121 
 2 files changed, 143 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx

diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx 
b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000..45b1e60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,22 @@
+What:  /sys/class/leds//hw_pattern
+Date:  September 2018
+KernelVersion: 4.20
+Description:
+   Specify a hardware pattern for the SC27XX LED. For the SC27XX
+   LED controller, it only supports 4 stages to make a single
+   hardware pattern, which is used to configure the rise time,
+   high time, fall time and low time for the breathing mode.
+
+   For the breathing mode, the SC27XX LED only expects one 
brightness
+   for the high stage. To be compatible with the hardware pattern
+   format, we should set brightness as 0 for rise stage, fall
+   stage and low stage.
+
+   Min stage duration: 125 ms
+   Max stage duration: 31875 ms
+
+   Since the stage duration step is 125 ms, the duration should be
+   a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ... 
31875ms.
+
+   Thus the format of the hardware pattern values should be:
+   "0 rise_duration brightness high_duration 0 fall_duration 0 
low_duration".
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..fecf27f 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,18 @@
 #define SC27XX_DUTY_MASK   GENMASK(15, 0)
 #define SC27XX_MOD_MASKGENMASK(7, 0)
 
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
 #define SC27XX_LEDS_OFFSET 0x10
 #define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
+/* Stage duration step, in milliseconds */
+#define SC27XX_LEDS_STEP   125
+/* Minimum and maximum duration, in milliseconds */
+#define SC27XX_DELTA_T_MIN SC27XX_LEDS_STEP
+#define SC27XX_DELTA_T_MAX (SC27XX_LEDS_STEP * 255)
 
 struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +132,113 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum 
led_brightness value)
return err;
 }
 
+static void sc27xx_led_clamp_align_delta_t(u32 *delta_t)
+{
+   u32 v, offset, t = *delta_t;
+
+   v = t + SC27XX_LEDS_STEP / 2;
+   v = clamp_t(u32, v, SC27XX_DELTA_T_MIN, SC27XX_DELTA_T_MAX);
+   offset = v - SC27XX_DELTA_T_MIN;
+   offset = SC27XX_LEDS_STEP * (offset / SC27XX_LEDS_STEP);
+
+   *delta_t = SC27XX_DELTA_T_MIN + offset;
+}
+
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+   struct sc27xx_led *leds = to_sc27xx_led(ldev);
+   struct regmap *regmap = leds->priv->regmap;
+   u32 base = sc27xx_led_get_offset(leds);
+   u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+   u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+   int err;
+
+   mutex_lock(>priv->lock);
+
+   /* Reset the rise, high, fall and low time to zero. */
+   regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+   regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+   err = regmap_update_bits(regmap, ctrl_base,
+   (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+   ldev->brightness = LED_OFF;
+
+   mutex_unlock(>priv->lock);
+
+   return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ u32 len, int repeat)
+{
+   struct sc27xx_led *leds = to_sc27xx_led(ldev);
+   u32 base = sc27xx_led_get_offset(leds);
+   u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+   u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+   struct regmap *regmap = leds->priv->regmap;
+  

[PATCH v13 1/2] leds: core: Introduce LED pattern trigger

2018-09-26 Thread Baolin Wang
This patch adds one new led trigger that LED device can configure
the software or hardware pattern and trigger it.

Consumers can write 'pattern' file to enable the software pattern
which alters the brightness for the specified duration with one
software timer.

Moreover consumers can write 'hw_pattern' file to enable the hardware
pattern for some LED controllers which can autonomously control
brightness over time, according to some preprogrammed hardware
patterns.

Signed-off-by: Raphael Teysseyre 
Signed-off-by: Baolin Wang 
---
Changes from v12:
 - Add gradual dimming support for software pattern.

Changes from v11:
 - Change -1 means repeat indefinitely.

Changes from v10:
 - Change 'int' to 'u32' for delta_t field.

Changes from v9:
 - None.

Changes from v8:
 - None.

Changes from v7:
 - Move the SC27XX hardware patterns description into its own ABI file.

Changes from v6:
 - Improve commit message.
 - Optimize the description of the hw_pattern file.
 - Simplify some logics.

Changes from v5:
 - Add one 'hw_pattern' file for hardware patterns.

Changes from v4:
 - Change the repeat file to return the originally written number.
 - Improve comments.
 - Fix some build warnings.

Changes from v3:
 - Reset pattern number to 0 if user provides incorrect pattern string.
 - Support one pattern.

Changes from v2:
 - Remove hardware_pattern boolen.
 - Chnage the pattern string format.

Changes from v1:
 - Use ATTRIBUTE_GROUPS() to define attributes.
 - Introduce hardware_pattern flag to determine if software pattern
 or hardware pattern.
 - Re-implement pattern_trig_store_pattern() function.
 - Remove pattern_get() interface.
 - Improve comments.
 - Other small optimization.
---
 .../ABI/testing/sysfs-class-led-trigger-pattern|   74 
 drivers/leds/trigger/Kconfig   |7 +
 drivers/leds/trigger/Makefile  |1 +
 drivers/leds/trigger/ledtrig-pattern.c |  406 
 include/linux/leds.h   |   15 +
 5 files changed, 503 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
 create mode 100644 drivers/leds/trigger/ledtrig-pattern.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
new file mode 100644
index 000..e84d42a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
@@ -0,0 +1,74 @@
+What:  /sys/class/leds//pattern
+Date:  September 2018
+KernelVersion: 4.20
+Description:
+   Specify a software pattern for the LED, that supports altering
+   the brightness for the specified duration with one software
+   timer. It can do gradual dimming and constant brightness.
+
+   The pattern is given by a series of tuples, of brightness and
+   duration (ms). The LED is expected to traverse the series and
+   each brightness value for the specified duration. Duration of
+   0 means brightness should immediately change to new value.
+
+   1. The gradual dimming format of the software pattern values
+   should be:
+   "brightness_1 duration_1 brightness_2 duration_2 brightness_3
+   duration_3 ...". For example:
+
+   echo 0 1000 255 2000 > pattern
+
+   It will make the LED go gradually from zero-intensity to max 
(255)
+   intensity in 1000 milliseconds, then back to zero intensity in 
2000
+   milliseconds:
+
+   LED brightness
+   ^
+   255-|   / \/ \/
+   |  /\ /\ /
+   | /   \  /   \  /
+   |/  \   /  \   /
+ 0-|   / \/ \/
+   +---0123456> time (s)
+
+   2. To make the LED go instantly from one brigntess value to 
another,
+   we should use use zero-time lengths. So the format should be:
+   "brightness_1 duration_1 brightness_1 0 brightness_2 duration_2
+   brightness_2 0 ...". For example:
+
+   echo 0 1000 0 0 255 2000 255 0 > pattern
+
+   It will make the LED stay off for one second, then stay at max 
brightness
+   for two seconds:
+
+   LED brightness
+   ^
+   255-|+-++-+
+   || || |
+   || || |
+   || || |
+ 0-|   -+ ++ +
+   +---0123456> time (s)
+
+What:  /sys/class/leds//hw_pattern
+Date:  September 

[PATCH linux-next 03/10] arm64: r8a7796: add dma request number for busif1 ~ busif7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

This patch adds dma request number for busif1 ~ busif7

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 136 +++
 1 file changed, 116 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 1ec6aaa520c1..e9b05d997c4e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1797,53 +1797,149 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
-   dmas = < 0x01>, < 0x02>, 
< 0x15>, < 0x16>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x01>, < 0x02>,
+  < 0x15>, < 0x16>,
+  < 0x35>, < 0x36>,
+  < 0x37>, < 0x38>,
+  < 0x47>, < 0x48>,
+  < 0x3f>, < 0x40>,
+  < 0x43>, < 0x44>,
+  < 0x4f>, < 0x50>,
+  < 0x53>, < 0x54>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi1: ssi-1 {
interrupts = ;
-   dmas = < 0x03>, < 0x04>, 
< 0x49>, < 0x4a>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x03>, < 0x04>,
+  < 0x49>, < 0x4a>,
+  < 0x4b>, < 0x4c>,
+  < 0x57>, < 0x58>,
+  < 0x59>, < 0x5a>,
+  < 0x5f>, < 0x60>,
+  < 0xc3>, < 0xc4>,
+  < 0xc7>, < 0xc8>,
+  < 0xcb>, < 0xcc>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
-   dmas = < 0x05>, < 0x06>, 
< 0x63>, < 0x64>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x05>, < 0x06>,
+  < 0x63>, < 0x64>,
+  < 0x67>, < 0x68>,
+  < 0x6b>, < 0x6c>,
+  < 0x6d>, < 0x6e>,
+  < 0xcf>, < 0xce>,
+  < 0xeb>, < 0xec>,
+  < 0xed>, < 0xee>,
+  < 0xef>, < 0xf0>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";

[PATCH linux-next 00/10] ASoC: rsnd: support to set different busif

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Rcar audio DMA/SSIU already support to use different BUSIF
to transfer data, but busif is fixed at 0.

This patch set adds kctrl interface "SSI Out/In BUSIF", which enables
to configure busif for each dai-stream used in transfer.

device tree files are updated to use extended audio dmac register,
and add dma request number for busif1 ~ busif7 

Jiada Wang (10):
  ASoC: rsnd: ssi: Request dedicated dma channels for busif1 to 7
  arm64: r8a7795: add dma request number for busif1 ~ busif7
  arm64: r8a7796: add dma request number for busif1 ~ busif7
  arm64: r8a774a1: add dma request number for busif1 ~ busif7
  arm64: r8a7795: change to use extended audio dmac register
  arm64: r8a7796: change to use extended audio dmac register
  arm64: r8a774a1: change to use extended audio dmac register
  arm64: r8a77965: change to use extended audio dmac register
  ASoC: rsnd: add busif property to dai stream
  ASoC: rsnd: Add kctrl to configure dai's busif

 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 139 ++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 132 +---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 138 +
 arch/arm64/boot/dts/renesas/r8a77965.dtsi |   2 +-
 sound/soc/sh/rcar/core.c  |  16 ++-
 sound/soc/sh/rcar/dma.c   |  32 +
 sound/soc/sh/rcar/rsnd.h  |   5 +
 sound/soc/sh/rcar/ssi.c   |  56 +++--
 8 files changed, 451 insertions(+), 69 deletions(-)

-- 
2.17.0



[PATCH linux-next 03/10] arm64: r8a7796: add dma request number for busif1 ~ busif7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

This patch adds dma request number for busif1 ~ busif7

Signed-off-by: Jiada Wang 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 136 +++
 1 file changed, 116 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 1ec6aaa520c1..e9b05d997c4e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1797,53 +1797,149 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
-   dmas = < 0x01>, < 0x02>, 
< 0x15>, < 0x16>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x01>, < 0x02>,
+  < 0x15>, < 0x16>,
+  < 0x35>, < 0x36>,
+  < 0x37>, < 0x38>,
+  < 0x47>, < 0x48>,
+  < 0x3f>, < 0x40>,
+  < 0x43>, < 0x44>,
+  < 0x4f>, < 0x50>,
+  < 0x53>, < 0x54>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi1: ssi-1 {
interrupts = ;
-   dmas = < 0x03>, < 0x04>, 
< 0x49>, < 0x4a>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x03>, < 0x04>,
+  < 0x49>, < 0x4a>,
+  < 0x4b>, < 0x4c>,
+  < 0x57>, < 0x58>,
+  < 0x59>, < 0x5a>,
+  < 0x5f>, < 0x60>,
+  < 0xc3>, < 0xc4>,
+  < 0xc7>, < 0xc8>,
+  < 0xcb>, < 0xcc>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
-   dmas = < 0x05>, < 0x06>, 
< 0x63>, < 0x64>;
-   dma-names = "rx", "tx", "rxu", "txu";
+   dmas = < 0x05>, < 0x06>,
+  < 0x63>, < 0x64>,
+  < 0x67>, < 0x68>,
+  < 0x6b>, < 0x6c>,
+  < 0x6d>, < 0x6e>,
+  < 0xcf>, < 0xce>,
+  < 0xeb>, < 0xec>,
+  < 0xed>, < 0xee>,
+  < 0xef>, < 0xf0>;
+   dma-names = "rx", "tx",
+   "rxu0", "txu0",
+   "rxu1", "txu1",
+   "rxu2", "txu2",
+   "rxu3", "txu3",
+   "rxu4", "txu4",
+   "rxu5", "txu5",
+   "rxu6", "txu6",
+   "rxu7", "txu7";

[PATCH linux-next 00/10] ASoC: rsnd: support to set different busif

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Rcar audio DMA/SSIU already support to use different BUSIF
to transfer data, but busif is fixed at 0.

This patch set adds kctrl interface "SSI Out/In BUSIF", which enables
to configure busif for each dai-stream used in transfer.

device tree files are updated to use extended audio dmac register,
and add dma request number for busif1 ~ busif7 

Jiada Wang (10):
  ASoC: rsnd: ssi: Request dedicated dma channels for busif1 to 7
  arm64: r8a7795: add dma request number for busif1 ~ busif7
  arm64: r8a7796: add dma request number for busif1 ~ busif7
  arm64: r8a774a1: add dma request number for busif1 ~ busif7
  arm64: r8a7795: change to use extended audio dmac register
  arm64: r8a7796: change to use extended audio dmac register
  arm64: r8a774a1: change to use extended audio dmac register
  arm64: r8a77965: change to use extended audio dmac register
  ASoC: rsnd: add busif property to dai stream
  ASoC: rsnd: Add kctrl to configure dai's busif

 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 139 ++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi  | 132 +---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi  | 138 +
 arch/arm64/boot/dts/renesas/r8a77965.dtsi |   2 +-
 sound/soc/sh/rcar/core.c  |  16 ++-
 sound/soc/sh/rcar/dma.c   |  32 +
 sound/soc/sh/rcar/rsnd.h  |   5 +
 sound/soc/sh/rcar/ssi.c   |  56 +++--
 8 files changed, 451 insertions(+), 69 deletions(-)

-- 
2.17.0



[PATCH linux-next 01/10] ASoC: rsnd: ssi: Request dedicated dma channels for busif1 to 7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Currently ssi driver only request dma channel for SSI_0,
which is used to transfer data to/from busif0.

But since busif1 to busif7 also maybe used, dedicated dma channels
are request for data transfer between these busif.

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/ssi.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 3adcc4f778f7..75a3d15084c2 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -76,6 +76,8 @@
 
 #define SSI_NAME "ssi"
 
+#define SSI_DMA_NAME_SIZE  10
+
 struct rsnd_ssi {
struct rsnd_mod mod;
 
@@ -938,12 +940,20 @@ static struct dma_chan *rsnd_ssi_dma_req(struct 
rsnd_dai_stream *io,
 {
struct rsnd_priv *priv = rsnd_mod_to_priv(mod);
int is_play = rsnd_io_is_play(io);
-   char *name;
+   int busif = rsnd_ssi_get_busif(io);
+   char name[SSI_DMA_NAME_SIZE];
 
-   if (rsnd_ssi_use_busif(io))
-   name = is_play ? "rxu" : "txu";
-   else
-   name = is_play ? "rx" : "tx";
+   if (rsnd_ssi_use_busif(io)) {
+   if (is_play)
+   snprintf(name, SSI_DMA_NAME_SIZE, "rxu%d", busif);
+   else
+   snprintf(name, SSI_DMA_NAME_SIZE, "txu%d", busif);
+   } else {
+   if (is_play)
+   snprintf(name, SSI_DMA_NAME_SIZE, "rx");
+   else
+   snprintf(name, SSI_DMA_NAME_SIZE, "tx");
+   }
 
return rsnd_dma_request_channel(rsnd_ssi_of_node(priv),
mod, name);
-- 
2.17.0



[PATCH linux-next 01/10] ASoC: rsnd: ssi: Request dedicated dma channels for busif1 to 7

2018-09-26 Thread jiada_wang
From: Jiada Wang 

Currently ssi driver only request dma channel for SSI_0,
which is used to transfer data to/from busif0.

But since busif1 to busif7 also maybe used, dedicated dma channels
are request for data transfer between these busif.

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/ssi.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 3adcc4f778f7..75a3d15084c2 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -76,6 +76,8 @@
 
 #define SSI_NAME "ssi"
 
+#define SSI_DMA_NAME_SIZE  10
+
 struct rsnd_ssi {
struct rsnd_mod mod;
 
@@ -938,12 +940,20 @@ static struct dma_chan *rsnd_ssi_dma_req(struct 
rsnd_dai_stream *io,
 {
struct rsnd_priv *priv = rsnd_mod_to_priv(mod);
int is_play = rsnd_io_is_play(io);
-   char *name;
+   int busif = rsnd_ssi_get_busif(io);
+   char name[SSI_DMA_NAME_SIZE];
 
-   if (rsnd_ssi_use_busif(io))
-   name = is_play ? "rxu" : "txu";
-   else
-   name = is_play ? "rx" : "tx";
+   if (rsnd_ssi_use_busif(io)) {
+   if (is_play)
+   snprintf(name, SSI_DMA_NAME_SIZE, "rxu%d", busif);
+   else
+   snprintf(name, SSI_DMA_NAME_SIZE, "txu%d", busif);
+   } else {
+   if (is_play)
+   snprintf(name, SSI_DMA_NAME_SIZE, "rx");
+   else
+   snprintf(name, SSI_DMA_NAME_SIZE, "tx");
+   }
 
return rsnd_dma_request_channel(rsnd_ssi_of_node(priv),
mod, name);
-- 
2.17.0



[PATCH v2] IB/rxe: Avoid implicit enum conversions in rxe_init functions

2018-09-26 Thread Nathan Chancellor
Clang warns when an emumerated type is implicitly converted to another.

drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu  = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.

Use the appropriate values from the expected enumerated type so no
conversion needs to happen.

Reported-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
---

v1 -> v2:

* Don't cast, just use the expecting enumerated value directly, per
  Jason's request

 drivers/infiniband/sw/rxe/rxe.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..2f4e57886b89 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom   = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom   = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom   = RXE_MAX_EE_INIT_RD_ATOM;
-   rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+   rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd   = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
 /* initialize port attributes */
 static int rxe_init_port_param(struct rxe_port *port)
 {
-   port->attr.state= RXE_PORT_STATE;
-   port->attr.max_mtu  = RXE_PORT_MAX_MTU;
-   port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
+   port->attr.state= IB_PORT_DOWN;
+   port->attr.max_mtu  = IB_MTU_4096;
+   port->attr.active_mtu   = IB_MTU_256;
port->attr.gid_tbl_len  = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags   = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz   = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state   = RXE_PORT_PHYS_STATE;
-   port->mtu_cap   =
-   ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+   port->mtu_cap   = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
 
return 0;
-- 
2.19.0



[PATCH v2] IB/rxe: Avoid implicit enum conversions in rxe_init functions

2018-09-26 Thread Nathan Chancellor
Clang warns when an emumerated type is implicitly converted to another.

drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu  = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.

Use the appropriate values from the expected enumerated type so no
conversion needs to happen.

Reported-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
---

v1 -> v2:

* Don't cast, just use the expecting enumerated value directly, per
  Jason's request

 drivers/infiniband/sw/rxe/rxe.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..2f4e57886b89 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom   = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom   = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom   = RXE_MAX_EE_INIT_RD_ATOM;
-   rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+   rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd   = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
 /* initialize port attributes */
 static int rxe_init_port_param(struct rxe_port *port)
 {
-   port->attr.state= RXE_PORT_STATE;
-   port->attr.max_mtu  = RXE_PORT_MAX_MTU;
-   port->attr.active_mtu   = RXE_PORT_ACTIVE_MTU;
+   port->attr.state= IB_PORT_DOWN;
+   port->attr.max_mtu  = IB_MTU_4096;
+   port->attr.active_mtu   = IB_MTU_256;
port->attr.gid_tbl_len  = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags   = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz   = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state   = RXE_PORT_PHYS_STATE;
-   port->mtu_cap   =
-   ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+   port->mtu_cap   = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
 
return 0;
-- 
2.19.0



[PATCH] arm64: dts: k3-am65-wakeup: Fix wakeup_uart reg address

2018-09-26 Thread Vignesh R
cbass_wakeup interconnect which is the parent of wakeup_uart node
defines address-cells=1 and size-cells=1, therefore fix up reg property
of wakeup_uart node accordingly. Otherwise, this UART instance fails to
probe if enabled.

Fixes: 4201af2544b3 ("arm64: dts: ti: am654: Add uart nodes")
Signed-off-by: Vignesh R 
---

Based on next-20180926

 arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index ee56959f4af8..c617393ea767 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -44,7 +44,7 @@
 
wkup_uart0: serial@4230 {
compatible = "ti,am654-uart";
-   reg = <0x00 0x4230 0x00 0x100>;
+   reg = <0x4230 0x100>;
reg-shift = <2>;
reg-io-width = <4>;
interrupts = ;
-- 
2.19.0



[PATCH] arm64: dts: k3-am65-wakeup: Fix wakeup_uart reg address

2018-09-26 Thread Vignesh R
cbass_wakeup interconnect which is the parent of wakeup_uart node
defines address-cells=1 and size-cells=1, therefore fix up reg property
of wakeup_uart node accordingly. Otherwise, this UART instance fails to
probe if enabled.

Fixes: 4201af2544b3 ("arm64: dts: ti: am654: Add uart nodes")
Signed-off-by: Vignesh R 
---

Based on next-20180926

 arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index ee56959f4af8..c617393ea767 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -44,7 +44,7 @@
 
wkup_uart0: serial@4230 {
compatible = "ti,am654-uart";
-   reg = <0x00 0x4230 0x00 0x100>;
+   reg = <0x4230 0x100>;
reg-shift = <2>;
reg-io-width = <4>;
interrupts = ;
-- 
2.19.0



[PATCH v7 06/39] component: alloc component_match without any comp to match

2018-09-26 Thread Ramalingam C
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().

To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct component_match with zero associated components.
Hence component master can be added with a component_match with zero
associated components.

This helps the component master bind call to get triggered,
even if no component is registered for that particular master.

This is meant for big PCI device drivers where small/optional
features are external components, and based on usecases different
combination of components are build as entire driver.

In such PCI device driver Load, if we use the component master for
waiting for few  components(features) availability, only if they are
supported by the underlying HW, then we need to allocate memory for
component_match using the API introduced in this change before
the call to component_master_add_with_match.

v2:
  No Change.

Signed-off-by: Ramalingam C 
Suggested-by: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: Kate Stewart 
Cc: Thomas Gleixner 
Cc: Philippe Ombredanne 
Cc: linux-kernel@vger.kernel.org
---
 drivers/base/component.c  | 30 ++
 include/linux/component.h |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 8946dfee4768..007fb738263a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
 }
 
 /*
+ * Allocate the match without any component_match_array elements.
+ *
+ * This function is useful when the component master might end up
+ * registering itself without any matching components.
+ */
+void component_match_alloc(struct device *master,
+   struct component_match **matchptr)
+{
+   struct component_match *match = *matchptr;
+
+   if (IS_ERR(match))
+   return;
+
+   if (match)
+   return;
+
+   match = devres_alloc(devm_component_match_release,
+sizeof(*match), GFP_KERNEL);
+   if (!match) {
+   *matchptr = ERR_PTR(-ENOMEM);
+   return;
+   }
+
+   devres_add(master, match);
+
+   *matchptr = match;
+}
+EXPORT_SYMBOL(component_match_alloc);
+
+/*
  * Add a component to be matched, with a release function.
  *
  * The match array is first created or extended if necessary.
diff --git a/include/linux/component.h b/include/linux/component.h
index e71fbbbc74e2..3f6b420a58f8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_alloc(struct device *master,
+   struct component_match **matchptr);
 
 static inline void component_match_add(struct device *master,
struct component_match **matchptr,
-- 
2.7.4



[PATCH v7 06/39] component: alloc component_match without any comp to match

2018-09-26 Thread Ramalingam C
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().

To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct component_match with zero associated components.
Hence component master can be added with a component_match with zero
associated components.

This helps the component master bind call to get triggered,
even if no component is registered for that particular master.

This is meant for big PCI device drivers where small/optional
features are external components, and based on usecases different
combination of components are build as entire driver.

In such PCI device driver Load, if we use the component master for
waiting for few  components(features) availability, only if they are
supported by the underlying HW, then we need to allocate memory for
component_match using the API introduced in this change before
the call to component_master_add_with_match.

v2:
  No Change.

Signed-off-by: Ramalingam C 
Suggested-by: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: Kate Stewart 
Cc: Thomas Gleixner 
Cc: Philippe Ombredanne 
Cc: linux-kernel@vger.kernel.org
---
 drivers/base/component.c  | 30 ++
 include/linux/component.h |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 8946dfee4768..007fb738263a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
 }
 
 /*
+ * Allocate the match without any component_match_array elements.
+ *
+ * This function is useful when the component master might end up
+ * registering itself without any matching components.
+ */
+void component_match_alloc(struct device *master,
+   struct component_match **matchptr)
+{
+   struct component_match *match = *matchptr;
+
+   if (IS_ERR(match))
+   return;
+
+   if (match)
+   return;
+
+   match = devres_alloc(devm_component_match_release,
+sizeof(*match), GFP_KERNEL);
+   if (!match) {
+   *matchptr = ERR_PTR(-ENOMEM);
+   return;
+   }
+
+   devres_add(master, match);
+
+   *matchptr = match;
+}
+EXPORT_SYMBOL(component_match_alloc);
+
+/*
  * Add a component to be matched, with a release function.
  *
  * The match array is first created or extended if necessary.
diff --git a/include/linux/component.h b/include/linux/component.h
index e71fbbbc74e2..3f6b420a58f8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_alloc(struct device *master,
+   struct component_match **matchptr);
 
 static inline void component_match_add(struct device *master,
struct component_match **matchptr,
-- 
2.7.4



Re: [PATCH] csky: fixups after bootmem removal

2018-09-26 Thread Guo Ren
On Wed, Sep 26, 2018 at 02:27:45PM +0300, Mike Rapoport wrote:
> Hi,
> 
> The below patch fixes the bootmem leftovers in csky. It is based on the
> current mmots and csky build there fails because of undefined reference to
> dma_direct_ops: 
> 
>   MODPOST vmlinux.o
> kernel/dma/mapping.o: In function `dmam_alloc_attrs':
> kernel/dma/mapping.c:143: undefined reference to `dma_direct_ops'
> kernel/dma/mapping.o: In function `dmam_declare_coherent_memory':
> kernel/dma/mapping.c:184: undefined reference to `dma_direct_ops'
> mm/dmapool.o: In function `dma_free_attrs': 
> include/linux/dma-mapping.h:558: undefined reference to `dma_direct_ops'
> 
> I've blindly added "select DMA_DIRECT_OPS" to arch/csky/Kconfig and it
> fixed the build, but I really have no idea if this the right thing to do...
You are almost right, the issue is come from the patch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=bc3ec75de5452db59b683487867ba562b950708a

we need:
-   select DMA_NONCOHERENT_OPS
+   select DMA_DIRECT_OPS

I'll fixup it in my repo.

> From 63c3b24e661e6cad88f0432dd460d35a16741871 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport 
> Date: Wed, 26 Sep 2018 13:40:13 +0300
> Subject: [PATCH] csky: fixups after bootmem removal
> 
> The bootmem removal patchest didn't take into account csky architecture and
> it still had bootmem leftovers. Remove them now.
> 
> Signed-off-by: Mike Rapoport 
> ---
>  arch/csky/Kconfig| 1 -
>  arch/csky/kernel/setup.c | 1 -
>  arch/csky/mm/highmem.c   | 4 ++--
>  arch/csky/mm/init.c  | 3 +--
>  4 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index fb2a0ae..fc25ea6 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -35,7 +35,6 @@ config CSKY
>   select HAVE_C_RECORDMCOUNT
>   select HAVE_DMA_API_DEBUG
>   select HAVE_DMA_CONTIGUOUS
> - select HAVE_MEMBLOCK
>   select MAY_HAVE_SPARSE_IRQ
>   select MODULES_USE_ELF_RELA if MODULES
>   select OF
> diff --git a/arch/csky/kernel/setup.c b/arch/csky/kernel/setup.c
> index 27f9e10..bee4d26 100644
> --- a/arch/csky/kernel/setup.c
> +++ b/arch/csky/kernel/setup.c
> @@ -3,7 +3,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
> index 149921a..5b90501 100644
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -4,7 +4,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -138,7 +138,7 @@ static void __init fixrange_init (unsigned long start, 
> unsigned long end,
>   pmd = (pmd_t *)pud;
>   for (; (k < PTRS_PER_PMD) && (vaddr != end); pmd++, 
> k++) {
>   if (pmd_none(*pmd)) {
> - pte = (pte_t *) 
> alloc_bootmem_low_pages(PAGE_SIZE);
> + pte = (pte_t *) 
> memblock_alloc_low(PAGE_SIZE, PAGE_SIZE);
>   set_pmd(pmd, __pmd(__pa(pte)));
>   BUG_ON(pte != pte_offset_kernel(pmd, 
> 0));
>   }
> diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c
> index fd2791b..46c5aaa 100644
> --- a/arch/csky/mm/init.c
> +++ b/arch/csky/mm/init.c
> @@ -14,7 +14,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -44,7 +43,7 @@ void __init mem_init(void)
>  #endif
>   high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT);
>  
> - free_all_bootmem();
> + memblock_free_all();
>  
>  #ifdef CONFIG_HIGHMEM
>   for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) {
The patch looks good for me.

Thx
 Guo Ren


Re: [PATCH] csky: fixups after bootmem removal

2018-09-26 Thread Guo Ren
On Wed, Sep 26, 2018 at 02:27:45PM +0300, Mike Rapoport wrote:
> Hi,
> 
> The below patch fixes the bootmem leftovers in csky. It is based on the
> current mmots and csky build there fails because of undefined reference to
> dma_direct_ops: 
> 
>   MODPOST vmlinux.o
> kernel/dma/mapping.o: In function `dmam_alloc_attrs':
> kernel/dma/mapping.c:143: undefined reference to `dma_direct_ops'
> kernel/dma/mapping.o: In function `dmam_declare_coherent_memory':
> kernel/dma/mapping.c:184: undefined reference to `dma_direct_ops'
> mm/dmapool.o: In function `dma_free_attrs': 
> include/linux/dma-mapping.h:558: undefined reference to `dma_direct_ops'
> 
> I've blindly added "select DMA_DIRECT_OPS" to arch/csky/Kconfig and it
> fixed the build, but I really have no idea if this the right thing to do...
You are almost right, the issue is come from the patch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=bc3ec75de5452db59b683487867ba562b950708a

we need:
-   select DMA_NONCOHERENT_OPS
+   select DMA_DIRECT_OPS

I'll fixup it in my repo.

> From 63c3b24e661e6cad88f0432dd460d35a16741871 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport 
> Date: Wed, 26 Sep 2018 13:40:13 +0300
> Subject: [PATCH] csky: fixups after bootmem removal
> 
> The bootmem removal patchest didn't take into account csky architecture and
> it still had bootmem leftovers. Remove them now.
> 
> Signed-off-by: Mike Rapoport 
> ---
>  arch/csky/Kconfig| 1 -
>  arch/csky/kernel/setup.c | 1 -
>  arch/csky/mm/highmem.c   | 4 ++--
>  arch/csky/mm/init.c  | 3 +--
>  4 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index fb2a0ae..fc25ea6 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -35,7 +35,6 @@ config CSKY
>   select HAVE_C_RECORDMCOUNT
>   select HAVE_DMA_API_DEBUG
>   select HAVE_DMA_CONTIGUOUS
> - select HAVE_MEMBLOCK
>   select MAY_HAVE_SPARSE_IRQ
>   select MODULES_USE_ELF_RELA if MODULES
>   select OF
> diff --git a/arch/csky/kernel/setup.c b/arch/csky/kernel/setup.c
> index 27f9e10..bee4d26 100644
> --- a/arch/csky/kernel/setup.c
> +++ b/arch/csky/kernel/setup.c
> @@ -3,7 +3,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
> index 149921a..5b90501 100644
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -4,7 +4,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -138,7 +138,7 @@ static void __init fixrange_init (unsigned long start, 
> unsigned long end,
>   pmd = (pmd_t *)pud;
>   for (; (k < PTRS_PER_PMD) && (vaddr != end); pmd++, 
> k++) {
>   if (pmd_none(*pmd)) {
> - pte = (pte_t *) 
> alloc_bootmem_low_pages(PAGE_SIZE);
> + pte = (pte_t *) 
> memblock_alloc_low(PAGE_SIZE, PAGE_SIZE);
>   set_pmd(pmd, __pmd(__pa(pte)));
>   BUG_ON(pte != pte_offset_kernel(pmd, 
> 0));
>   }
> diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c
> index fd2791b..46c5aaa 100644
> --- a/arch/csky/mm/init.c
> +++ b/arch/csky/mm/init.c
> @@ -14,7 +14,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -44,7 +43,7 @@ void __init mem_init(void)
>  #endif
>   high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT);
>  
> - free_all_bootmem();
> + memblock_free_all();
>  
>  #ifdef CONFIG_HIGHMEM
>   for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) {
The patch looks good for me.

Thx
 Guo Ren


Re: [PATCH] Raise maximum number of memory controllers

2018-09-26 Thread Borislav Petkov
On Wed, Sep 26, 2018 at 04:02:57PM -0700, Luck, Tony wrote:
> We don't have stats, nor control of power on a per memory controller
> or per dimm basis. So all these files are just noise.

Yeah, and also, looking at your previous mail, stuff like:

/sys/bus/mc6/devices/dimm0
/sys/bus/mc4/devices/dimm0

doesn't make any sense: why is mc* directly under bus? It should be
under ...bus/edac/mc/...

We'll have to clean it up carefully, when there's time.

> But ... we are at -rc5. Not sure that we'll figure out, write, test & debug
> the proper solution in the next 3-4 weeks. So perhaps we should apply
> 
> -#define EDAC_MAX_MCS   16
> +#define EDAC_MAX_MCS   64
> 
> as a temporary band-aid to get HPE's 32-socket machine running while
> we work on the proper fix?

Yeah, after sleeping on it I see it the same way - band-aid it now and
clean it up properly later.

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH] Raise maximum number of memory controllers

2018-09-26 Thread Borislav Petkov
On Wed, Sep 26, 2018 at 04:02:57PM -0700, Luck, Tony wrote:
> We don't have stats, nor control of power on a per memory controller
> or per dimm basis. So all these files are just noise.

Yeah, and also, looking at your previous mail, stuff like:

/sys/bus/mc6/devices/dimm0
/sys/bus/mc4/devices/dimm0

doesn't make any sense: why is mc* directly under bus? It should be
under ...bus/edac/mc/...

We'll have to clean it up carefully, when there's time.

> But ... we are at -rc5. Not sure that we'll figure out, write, test & debug
> the proper solution in the next 3-4 weeks. So perhaps we should apply
> 
> -#define EDAC_MAX_MCS   16
> +#define EDAC_MAX_MCS   64
> 
> as a temporary band-aid to get HPE's 32-socket machine running while
> we work on the proper fix?

Yeah, after sleeping on it I see it the same way - band-aid it now and
clean it up properly later.

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion

2018-09-26 Thread Jason Gunthorpe
On Wed, Sep 26, 2018 at 06:08:03PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 24, 2018 at 08:37:22PM -0600, Jason Gunthorpe wrote:
> > On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> > > On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> > >  wrote:
> > > >
> > > > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers wrote:
> > > > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > > >  wrote:
> > > > > >
> > > > > > Clang warns when one enumerated type is implicitly converted to 
> > > > > > another.
> > > > > >
> > > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit 
> > > > > > conversion
> > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different 
> > > > > > enumeration
> > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > qp_init_attr.init_attr.create_flags = 
> > > > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > > > ~ 
> > > > > > ^~~
> > > > > >
> > > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit 
> > > > > > conversion
> > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different 
> > > > > > enumeration
> > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > qp_init_attr.init_attr.create_flags = 
> > > > > > MLX4_IB_SRIOV_SQP;
> > > > > > ~ 
> > > > > > ^
> > > > > >
> > > > > > The type mlx4_ib_qp_flags explicitly provides supplemental values 
> > > > > > to the
> > > > > > type ib_qp_create_flags. Make that clear to Clang by changing the
> > > > > > create_flags type to u32.
> > > > > >
> > > > > > Reported-by: Nick Desaulniers 
> > > > > > Signed-off-by: Nathan Chancellor 
> > > > > >  include/rdma/ib_verbs.h | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > > > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > > > +++ b/include/rdma/ib_verbs.h
> > > > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > > > struct ib_qp_capcap;
> > > > > > enum ib_sig_typesq_sig_type;
> > > > > > enum ib_qp_type qp_type;
> > > > > > -   enum ib_qp_create_flags create_flags;
> > > > > > +   u32 create_flags;
> > > > >
> > > > > I think it might be better to just have explicit casts at the
> > > > > assignment.  What do the maintainers think?
> > > > >
> > > >
> > > > That's fine with me, I tend to explicitly cast if it is only one
> > > > location but it certainly makes sense in this case as well. I'll
> > > > wait for the maintainers to weigh in before sending a v2.
> > > 
> > > Yeah, I mean my opinion on this might seem arbitrary, but based on the
> > > pattern and the comment in ib_qp_create_flags, those enum values are
> > > reserved to be "subclassed" in a sense, so they should always be in
> > > sync or this code will have bigger problems.
> > 
> > One should not use an 'enum' type name for bitfield storage, as once
> > you start or'ing things together the values no longer fall on the
> > enum. Some compilers and tools even give warnings in this case, ie
> > 
> >enum x foo = X_A | X_B;
> > 
> > Is an assignment from 'int' to an 'enum x' with an implicit cast.
> > 
> > For this reason, usually bitfield enum declarations should be
> > anonymous.
> > 
> > Jason
> 
> Hi Jason,
> 
> I apologize for not understanding but how should I adjust my patch so
> that it is acceptable? Do you want the explicit casts like Nick
> suggested?

No, I think your original patch is fine, I was waiting to see if you
or Nick disagreed with my assessment on bitfields..

Jason


Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion

2018-09-26 Thread Jason Gunthorpe
On Wed, Sep 26, 2018 at 06:08:03PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 24, 2018 at 08:37:22PM -0600, Jason Gunthorpe wrote:
> > On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> > > On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> > >  wrote:
> > > >
> > > > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers wrote:
> > > > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > > >  wrote:
> > > > > >
> > > > > > Clang warns when one enumerated type is implicitly converted to 
> > > > > > another.
> > > > > >
> > > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit 
> > > > > > conversion
> > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different 
> > > > > > enumeration
> > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > qp_init_attr.init_attr.create_flags = 
> > > > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > > > ~ 
> > > > > > ^~~
> > > > > >
> > > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit 
> > > > > > conversion
> > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different 
> > > > > > enumeration
> > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > qp_init_attr.init_attr.create_flags = 
> > > > > > MLX4_IB_SRIOV_SQP;
> > > > > > ~ 
> > > > > > ^
> > > > > >
> > > > > > The type mlx4_ib_qp_flags explicitly provides supplemental values 
> > > > > > to the
> > > > > > type ib_qp_create_flags. Make that clear to Clang by changing the
> > > > > > create_flags type to u32.
> > > > > >
> > > > > > Reported-by: Nick Desaulniers 
> > > > > > Signed-off-by: Nathan Chancellor 
> > > > > >  include/rdma/ib_verbs.h | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > > > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > > > +++ b/include/rdma/ib_verbs.h
> > > > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > > > struct ib_qp_capcap;
> > > > > > enum ib_sig_typesq_sig_type;
> > > > > > enum ib_qp_type qp_type;
> > > > > > -   enum ib_qp_create_flags create_flags;
> > > > > > +   u32 create_flags;
> > > > >
> > > > > I think it might be better to just have explicit casts at the
> > > > > assignment.  What do the maintainers think?
> > > > >
> > > >
> > > > That's fine with me, I tend to explicitly cast if it is only one
> > > > location but it certainly makes sense in this case as well. I'll
> > > > wait for the maintainers to weigh in before sending a v2.
> > > 
> > > Yeah, I mean my opinion on this might seem arbitrary, but based on the
> > > pattern and the comment in ib_qp_create_flags, those enum values are
> > > reserved to be "subclassed" in a sense, so they should always be in
> > > sync or this code will have bigger problems.
> > 
> > One should not use an 'enum' type name for bitfield storage, as once
> > you start or'ing things together the values no longer fall on the
> > enum. Some compilers and tools even give warnings in this case, ie
> > 
> >enum x foo = X_A | X_B;
> > 
> > Is an assignment from 'int' to an 'enum x' with an implicit cast.
> > 
> > For this reason, usually bitfield enum declarations should be
> > anonymous.
> > 
> > Jason
> 
> Hi Jason,
> 
> I apologize for not understanding but how should I adjust my patch so
> that it is acceptable? Do you want the explicit casts like Nick
> suggested?

No, I think your original patch is fine, I was waiting to see if you
or Nick disagreed with my assessment on bitfields..

Jason


Re: [PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

2018-09-26 Thread Tianyu Lan
On 9/27/2018 12:16 PM, Michael Kelley (EOSG) wrote:
> From: Tianyu Lan  Sent: Wednesday, September 26, 2018 8:50 PM
>>
>> Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
>> with specified ranges. This patch is to add the hypercall support.
>>
>> Signed-off-by: Lan Tianyu 
>>
> 
> Looks good!
> 
> Reviewed-by:  Michael Kelley 
> 

Thanks.

Re: [PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

2018-09-26 Thread Tianyu Lan
On 9/27/2018 12:16 PM, Michael Kelley (EOSG) wrote:
> From: Tianyu Lan  Sent: Wednesday, September 26, 2018 8:50 PM
>>
>> Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
>> with specified ranges. This patch is to add the hypercall support.
>>
>> Signed-off-by: Lan Tianyu 
>>
> 
> Looks good!
> 
> Reviewed-by:  Michael Kelley 
> 

Thanks.

RE: [PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

2018-09-26 Thread Michael Kelley (EOSG)
From: Tianyu Lan  Sent: Wednesday, September 26, 2018 8:50 PM
> 
> Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
> with specified ranges. This patch is to add the hypercall support.
> 
> Signed-off-by: Lan Tianyu 
>

Looks good!

Reviewed-by:  Michael Kelley 


RE: [PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

2018-09-26 Thread Michael Kelley (EOSG)
From: Tianyu Lan  Sent: Wednesday, September 26, 2018 8:50 PM
> 
> Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
> with specified ranges. This patch is to add the hypercall support.
> 
> Signed-off-by: Lan Tianyu 
>

Looks good!

Reviewed-by:  Michael Kelley 


Re: [PATCH] torture-test modules: Remove unnecessary "ret" variables

2018-09-26 Thread Paul E. McKenney
On Tue, Sep 25, 2018 at 02:47:08PM -0500, Pierce Griffiths wrote:
> Paul,
> The #ifdef cannot be replaced, as this would break the build for
> CONFIG_HOTPLUG_CPU=n builds. There are assignments and references to two
> global variables, a struct, and a function that are declared/defined in
> a large "#ifdef CONFIG_HOTPLUG_CPU" block which ends directly above
> torture_onoff_init(). IS_ENABLED() would cause these references to be
> present at compile time, but not their declarations or definitions,
> which would certainly cause a compilation error.

Good point, and thank you!  I have queued the original patch with a
minor edit to the Subject line.  It will make it to my -rcu tree once
I find a decent internet connection.

Thanx, Paul

> On Sat, Sep 22, 2018 at 02:26:30PM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 21, 2018 at 08:21:31PM -0500, Pierce Griffiths wrote:
> > > Remove return variables (declared as "ret") in cases where,
> > > depending on whether a condition evaluates as true, the result of a
> > > function call can be immediately returned instead of storing the result in
> > > the return variable. When the condition evaluates as false, the constant
> > > initially stored in the return variable at declaration is returned 
> > > instead.
> > > 
> > > Signed-off-by: Pierce Griffiths 
> > 
> > Not bad, as it does safe a couple of lines.  Is it possible to save
> > a few more by using "if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))" instead
> > of the #ifdef?  Or does that end up breaking the build for either
> > CONFIG_HOTPLUG_CPU=y or CONFIG_HOTPLUG_CPU=n builds?
> > 
> > Thanx, Paul
> > 
> > > ---
> > >  kernel/torture.c | 22 --
> > >  1 file changed, 8 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/kernel/torture.c b/kernel/torture.c
> > > index 1ac24a826589..f4cec6db7f3c 100644
> > > --- a/kernel/torture.c
> > > +++ b/kernel/torture.c
> > > @@ -233,16 +233,15 @@ torture_onoff(void *arg)
> > >   */
> > >  int torture_onoff_init(long ooholdoff, long oointerval)
> > >  {
> > > - int ret = 0;
> > > -
> > >  #ifdef CONFIG_HOTPLUG_CPU
> > >   onoff_holdoff = ooholdoff;
> > >   onoff_interval = oointerval;
> > >   if (onoff_interval <= 0)
> > >   return 0;
> > > - ret = torture_create_kthread(torture_onoff, NULL, onoff_task);
> > > -#endif /* #ifdef CONFIG_HOTPLUG_CPU */
> > > - return ret;
> > > + return torture_create_kthread(torture_onoff, NULL, onoff_task);
> > > +#else /* #ifdef CONFIG_HOTPLUG_CPU */
> > > + return 0;
> > > +#endif /* #else #ifdef CONFIG_HOTPLUG_CPU */
> > >  }
> > >  EXPORT_SYMBOL_GPL(torture_onoff_init);
> > > 
> > > @@ -513,15 +512,13 @@ static int torture_shutdown(void *arg)
> > >   */
> > >  int torture_shutdown_init(int ssecs, void (*cleanup)(void))
> > >  {
> > > - int ret = 0;
> > > -
> > >   torture_shutdown_hook = cleanup;
> > >   if (ssecs > 0) {
> > >   shutdown_time = ktime_add(ktime_get(), ktime_set(ssecs, 0));
> > > - ret = torture_create_kthread(torture_shutdown, NULL,
> > > + return torture_create_kthread(torture_shutdown, NULL,
> > >shutdown_task);
> > >   }
> > > - return ret;
> > > + return 0;
> > >  }
> > >  EXPORT_SYMBOL_GPL(torture_shutdown_init);
> > > 
> > > @@ -619,13 +616,10 @@ static int torture_stutter(void *arg)
> > >  /*
> > >   * Initialize and kick off the torture_stutter kthread.
> > >   */
> > > -int torture_stutter_init(int s)
> > > +int torture_stutter_init(const int s)
> > >  {
> > > - int ret;
> > > -
> > >   stutter = s;
> > > - ret = torture_create_kthread(torture_stutter, NULL, stutter_task);
> > > - return ret;
> > > + return torture_create_kthread(torture_stutter, NULL, stutter_task);
> > >  }
> > >  EXPORT_SYMBOL_GPL(torture_stutter_init);
> > > 
> > > -- 
> > > 2.19.0
> > > 
> > 
> 



Re: [PATCH] torture-test modules: Remove unnecessary "ret" variables

2018-09-26 Thread Paul E. McKenney
On Tue, Sep 25, 2018 at 02:47:08PM -0500, Pierce Griffiths wrote:
> Paul,
> The #ifdef cannot be replaced, as this would break the build for
> CONFIG_HOTPLUG_CPU=n builds. There are assignments and references to two
> global variables, a struct, and a function that are declared/defined in
> a large "#ifdef CONFIG_HOTPLUG_CPU" block which ends directly above
> torture_onoff_init(). IS_ENABLED() would cause these references to be
> present at compile time, but not their declarations or definitions,
> which would certainly cause a compilation error.

Good point, and thank you!  I have queued the original patch with a
minor edit to the Subject line.  It will make it to my -rcu tree once
I find a decent internet connection.

Thanx, Paul

> On Sat, Sep 22, 2018 at 02:26:30PM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 21, 2018 at 08:21:31PM -0500, Pierce Griffiths wrote:
> > > Remove return variables (declared as "ret") in cases where,
> > > depending on whether a condition evaluates as true, the result of a
> > > function call can be immediately returned instead of storing the result in
> > > the return variable. When the condition evaluates as false, the constant
> > > initially stored in the return variable at declaration is returned 
> > > instead.
> > > 
> > > Signed-off-by: Pierce Griffiths 
> > 
> > Not bad, as it does safe a couple of lines.  Is it possible to save
> > a few more by using "if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))" instead
> > of the #ifdef?  Or does that end up breaking the build for either
> > CONFIG_HOTPLUG_CPU=y or CONFIG_HOTPLUG_CPU=n builds?
> > 
> > Thanx, Paul
> > 
> > > ---
> > >  kernel/torture.c | 22 --
> > >  1 file changed, 8 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/kernel/torture.c b/kernel/torture.c
> > > index 1ac24a826589..f4cec6db7f3c 100644
> > > --- a/kernel/torture.c
> > > +++ b/kernel/torture.c
> > > @@ -233,16 +233,15 @@ torture_onoff(void *arg)
> > >   */
> > >  int torture_onoff_init(long ooholdoff, long oointerval)
> > >  {
> > > - int ret = 0;
> > > -
> > >  #ifdef CONFIG_HOTPLUG_CPU
> > >   onoff_holdoff = ooholdoff;
> > >   onoff_interval = oointerval;
> > >   if (onoff_interval <= 0)
> > >   return 0;
> > > - ret = torture_create_kthread(torture_onoff, NULL, onoff_task);
> > > -#endif /* #ifdef CONFIG_HOTPLUG_CPU */
> > > - return ret;
> > > + return torture_create_kthread(torture_onoff, NULL, onoff_task);
> > > +#else /* #ifdef CONFIG_HOTPLUG_CPU */
> > > + return 0;
> > > +#endif /* #else #ifdef CONFIG_HOTPLUG_CPU */
> > >  }
> > >  EXPORT_SYMBOL_GPL(torture_onoff_init);
> > > 
> > > @@ -513,15 +512,13 @@ static int torture_shutdown(void *arg)
> > >   */
> > >  int torture_shutdown_init(int ssecs, void (*cleanup)(void))
> > >  {
> > > - int ret = 0;
> > > -
> > >   torture_shutdown_hook = cleanup;
> > >   if (ssecs > 0) {
> > >   shutdown_time = ktime_add(ktime_get(), ktime_set(ssecs, 0));
> > > - ret = torture_create_kthread(torture_shutdown, NULL,
> > > + return torture_create_kthread(torture_shutdown, NULL,
> > >shutdown_task);
> > >   }
> > > - return ret;
> > > + return 0;
> > >  }
> > >  EXPORT_SYMBOL_GPL(torture_shutdown_init);
> > > 
> > > @@ -619,13 +616,10 @@ static int torture_stutter(void *arg)
> > >  /*
> > >   * Initialize and kick off the torture_stutter kthread.
> > >   */
> > > -int torture_stutter_init(int s)
> > > +int torture_stutter_init(const int s)
> > >  {
> > > - int ret;
> > > -
> > >   stutter = s;
> > > - ret = torture_create_kthread(torture_stutter, NULL, stutter_task);
> > > - return ret;
> > > + return torture_create_kthread(torture_stutter, NULL, stutter_task);
> > >  }
> > >  EXPORT_SYMBOL_GPL(torture_stutter_init);
> > > 
> > > -- 
> > > 2.19.0
> > > 
> > 
> 



Re: possible deadlock in ovl_write_iter

2018-09-26 Thread Amir Goldstein
[CC: fsdevel]

On Thu, Sep 27, 2018 at 6:48 AM Amir Goldstein  wrote:
>
> On Wed, Sep 26, 2018 at 11:44 PM syzbot
>  wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:a38523185b40 erge tag 'libnvdimm-fixes-4.19-rc6' of git://..
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=178f63fa40
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
> > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
> >
> > Process accounting resumed
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.19.0-rc5+ #32 Not tainted
> > --
> > overlayfs: option "workdir=./file1\" is useless in a non-upper mount, ignore
> > syz-executor1/7265 is trying to acquire lock:
> > fec87ddb (_i_mutex_key[depth]){+.+.}, at: inode_lock
> > include/linux/fs.h:738 [inline]
> > fec87ddb (_i_mutex_key[depth]){+.+.}, at:
> > ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
> >
> > but task is already holding lock:
> > 998db2f0 (>lock#2){+.+.}, at: acct_get kernel/acct.c:161
> > [inline]
> > 998db2f0 (>lock#2){+.+.}, at: slow_acct_process
> > kernel/acct.c:577 [inline]
> > 998db2f0 (>lock#2){+.+.}, at: acct_process+0x48b/0x875
> > kernel/acct.c:605
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #2 (>lock#2){+.+.}:
> > overlayfs: at least 2 lowerdir are needed while upperdir nonexistent
> > __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> > __mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> > kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> > acct_pin_kill+0x26/0x100 kernel/acct.c:173
> > pin_kill+0x29d/0xab0 fs/fs_pin.c:50
> > kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> > = '/devices/virtual/misc/kvm'
> > acct_on+0x64a/0x8c0 kernel/acct.c:254
> > __do_sys_acct kernel/acct.c:286 [inline]
> > __se_sys_acct kernel/acct.c:273 [inline]
> > __x64_sys_acct+0xc2/0x1f0 kernel/acct.c:273
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #1 (sb_writers#3){.+.+}:
> > percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> > [inline]
> > percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> > __sb_start_write+0x214/0x370 fs/super.c:1387
> > sb_start_write include/linux/fs.h:1566 [inline]
> > mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> > ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> > ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
> > notify_change+0xbde/0x1110 fs/attr.c:334
> > do_truncate+0x1bd/0x2d0 fs/open.c:63
> > handle_truncate fs/namei.c:3008 [inline]
> > do_last fs/namei.c:3424 [inline]
> > path_openat+0x3762/0x5160 fs/namei.c:3534
> > do_filp_open+0x255/0x380 fs/namei.c:3564
> > kobject: 'loop4' (88f052bf): kobject_uevent_env
> > do_sys_open+0x568/0x700 fs/open.c:1063
> > ksys_open include/linux/syscalls.h:1276 [inline]
> > __do_sys_creat fs/open.c:1121 [inline]
> > __se_sys_creat fs/open.c:1119 [inline]
> > __x64_sys_creat+0x61/0x80 fs/open.c:1119
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > kobject: 'loop4' (88f052bf): fill_kobj_path: path
> > = '/devices/virtual/block/loop4'
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #0
> > kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> >   (_i_mutex_key[depth]){+.+.}:
> > lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
> > down_write+0x8a/0x130 kernel/locking/rwsem.c:70
> > inode_lock include/linux/fs.h:738 [inline]
> > ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
> > kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> > = '/devices/virtual/misc/kvm'
> > call_write_iter include/linux/fs.h:1808 [inline]
> > new_sync_write fs/read_write.c:474 [inline]
> > __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
> > __kernel_write+0x10c/0x370 fs/read_write.c:506
> > do_acct_process+0x1144/0x1660 kernel/acct.c:520
> > slow_acct_process kernel/acct.c:579 [inline]
> > acct_process+0x6b1/0x875 kernel/acct.c:605
> > do_exit+0x1aaf/0x2610 kernel/exit.c:857
> > 

Re: possible deadlock in ovl_write_iter

2018-09-26 Thread Amir Goldstein
[CC: fsdevel]

On Thu, Sep 27, 2018 at 6:48 AM Amir Goldstein  wrote:
>
> On Wed, Sep 26, 2018 at 11:44 PM syzbot
>  wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:a38523185b40 erge tag 'libnvdimm-fixes-4.19-rc6' of git://..
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=178f63fa40
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
> > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
> >
> > Process accounting resumed
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.19.0-rc5+ #32 Not tainted
> > --
> > overlayfs: option "workdir=./file1\" is useless in a non-upper mount, ignore
> > syz-executor1/7265 is trying to acquire lock:
> > fec87ddb (_i_mutex_key[depth]){+.+.}, at: inode_lock
> > include/linux/fs.h:738 [inline]
> > fec87ddb (_i_mutex_key[depth]){+.+.}, at:
> > ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
> >
> > but task is already holding lock:
> > 998db2f0 (>lock#2){+.+.}, at: acct_get kernel/acct.c:161
> > [inline]
> > 998db2f0 (>lock#2){+.+.}, at: slow_acct_process
> > kernel/acct.c:577 [inline]
> > 998db2f0 (>lock#2){+.+.}, at: acct_process+0x48b/0x875
> > kernel/acct.c:605
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #2 (>lock#2){+.+.}:
> > overlayfs: at least 2 lowerdir are needed while upperdir nonexistent
> > __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> > __mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> > kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> > acct_pin_kill+0x26/0x100 kernel/acct.c:173
> > pin_kill+0x29d/0xab0 fs/fs_pin.c:50
> > kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> > = '/devices/virtual/misc/kvm'
> > acct_on+0x64a/0x8c0 kernel/acct.c:254
> > __do_sys_acct kernel/acct.c:286 [inline]
> > __se_sys_acct kernel/acct.c:273 [inline]
> > __x64_sys_acct+0xc2/0x1f0 kernel/acct.c:273
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #1 (sb_writers#3){.+.+}:
> > percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> > [inline]
> > percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> > __sb_start_write+0x214/0x370 fs/super.c:1387
> > sb_start_write include/linux/fs.h:1566 [inline]
> > mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> > ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> > ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
> > notify_change+0xbde/0x1110 fs/attr.c:334
> > do_truncate+0x1bd/0x2d0 fs/open.c:63
> > handle_truncate fs/namei.c:3008 [inline]
> > do_last fs/namei.c:3424 [inline]
> > path_openat+0x3762/0x5160 fs/namei.c:3534
> > do_filp_open+0x255/0x380 fs/namei.c:3564
> > kobject: 'loop4' (88f052bf): kobject_uevent_env
> > do_sys_open+0x568/0x700 fs/open.c:1063
> > ksys_open include/linux/syscalls.h:1276 [inline]
> > __do_sys_creat fs/open.c:1121 [inline]
> > __se_sys_creat fs/open.c:1119 [inline]
> > __x64_sys_creat+0x61/0x80 fs/open.c:1119
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > kobject: 'loop4' (88f052bf): fill_kobj_path: path
> > = '/devices/virtual/block/loop4'
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #0
> > kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> >   (_i_mutex_key[depth]){+.+.}:
> > lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
> > down_write+0x8a/0x130 kernel/locking/rwsem.c:70
> > inode_lock include/linux/fs.h:738 [inline]
> > ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
> > kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> > = '/devices/virtual/misc/kvm'
> > call_write_iter include/linux/fs.h:1808 [inline]
> > new_sync_write fs/read_write.c:474 [inline]
> > __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
> > __kernel_write+0x10c/0x370 fs/read_write.c:506
> > do_acct_process+0x1144/0x1660 kernel/acct.c:520
> > slow_acct_process kernel/acct.c:579 [inline]
> > acct_process+0x6b1/0x875 kernel/acct.c:605
> > do_exit+0x1aaf/0x2610 kernel/exit.c:857
> > 

[PATCH V3 2/13] KVM/MMU: Add tlb flush with range helper function

2018-09-26 Thread Tianyu Lan
This patch is to add wrapper functions for tlb_remote_flush_with_range
callback.

Signed-off-by: Lan Tianyu 
---
Change since V2:
   Fix comment in the kvm_flush_remote_tlbs_with_range()
---
 arch/x86/kvm/mmu.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c67f09086378..18cac661a41a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -253,6 +253,54 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
 static union kvm_mmu_page_role
 kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
 
+
+static inline bool kvm_available_flush_tlb_with_range(void)
+{
+   return kvm_x86_ops->tlb_remote_flush_with_range;
+}
+
+static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm,
+   struct kvm_tlb_range *range)
+{
+   int ret = -ENOTSUPP;
+
+   if (range && kvm_x86_ops->tlb_remote_flush_with_range) {
+   /*
+* Read tlbs_dirty before flushing tlbs in order
+* to track dirty tlbs during flushing.
+*/
+   long dirty_count = smp_load_acquire(>tlbs_dirty);
+
+   ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
+   cmpxchg(>tlbs_dirty, dirty_count, 0);
+   }
+
+   if (ret)
+   kvm_flush_remote_tlbs(kvm);
+}
+
+static void kvm_flush_remote_tlbs_with_list(struct kvm *kvm,
+   struct list_head *flush_list)
+{
+   struct kvm_tlb_range range;
+
+   range.flush_list = flush_list;
+
+   kvm_flush_remote_tlbs_with_range(kvm, );
+}
+
+static void kvm_flush_remote_tlbs_with_address(struct kvm *kvm,
+   u64 start_gfn, u64 pages)
+{
+   struct kvm_tlb_range range;
+
+   range.start_gfn = start_gfn;
+   range.pages = pages;
+   range.flush_list = NULL;
+
+   kvm_flush_remote_tlbs_with_range(kvm, );
+}
+
 void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value)
 {
BUG_ON((mmio_mask & mmio_value) != mmio_value);
-- 
2.14.4


[PATCH V3 2/13] KVM/MMU: Add tlb flush with range helper function

2018-09-26 Thread Tianyu Lan
This patch is to add wrapper functions for tlb_remote_flush_with_range
callback.

Signed-off-by: Lan Tianyu 
---
Change since V2:
   Fix comment in the kvm_flush_remote_tlbs_with_range()
---
 arch/x86/kvm/mmu.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c67f09086378..18cac661a41a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -253,6 +253,54 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
 static union kvm_mmu_page_role
 kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
 
+
+static inline bool kvm_available_flush_tlb_with_range(void)
+{
+   return kvm_x86_ops->tlb_remote_flush_with_range;
+}
+
+static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm,
+   struct kvm_tlb_range *range)
+{
+   int ret = -ENOTSUPP;
+
+   if (range && kvm_x86_ops->tlb_remote_flush_with_range) {
+   /*
+* Read tlbs_dirty before flushing tlbs in order
+* to track dirty tlbs during flushing.
+*/
+   long dirty_count = smp_load_acquire(>tlbs_dirty);
+
+   ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
+   cmpxchg(>tlbs_dirty, dirty_count, 0);
+   }
+
+   if (ret)
+   kvm_flush_remote_tlbs(kvm);
+}
+
+static void kvm_flush_remote_tlbs_with_list(struct kvm *kvm,
+   struct list_head *flush_list)
+{
+   struct kvm_tlb_range range;
+
+   range.flush_list = flush_list;
+
+   kvm_flush_remote_tlbs_with_range(kvm, );
+}
+
+static void kvm_flush_remote_tlbs_with_address(struct kvm *kvm,
+   u64 start_gfn, u64 pages)
+{
+   struct kvm_tlb_range range;
+
+   range.start_gfn = start_gfn;
+   range.pages = pages;
+   range.flush_list = NULL;
+
+   kvm_flush_remote_tlbs_with_range(kvm, );
+}
+
 void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value)
 {
BUG_ON((mmio_mask & mmio_value) != mmio_value);
-- 
2.14.4


[PATCH V3 4/13] KVM/MMU: Flush tlb directly in the kvm_handle_hva_range()

2018-09-26 Thread Tianyu Lan
This patch is to flush tlb directly in the kvm_handle_hva_range()
when range flush is available.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d10d8423e8d6..877edae0401f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1888,6 +1888,13 @@ static int kvm_handle_hva_range(struct kvm *kvm,
 )
ret |= handler(kvm, iterator.rmap, memslot,
   iterator.gfn, iterator.level, 
data);
+
+   if (ret && kvm_available_flush_tlb_with_range()) {
+   kvm_flush_remote_tlbs_with_address(kvm,
+   gfn_start,
+   gfn_end - gfn_start);
+   ret = 0;
+   }
}
}
 
-- 
2.14.4


[PATCH V3 4/13] KVM/MMU: Flush tlb directly in the kvm_handle_hva_range()

2018-09-26 Thread Tianyu Lan
This patch is to flush tlb directly in the kvm_handle_hva_range()
when range flush is available.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d10d8423e8d6..877edae0401f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1888,6 +1888,13 @@ static int kvm_handle_hva_range(struct kvm *kvm,
 )
ret |= handler(kvm, iterator.rmap, memslot,
   iterator.gfn, iterator.level, 
data);
+
+   if (ret && kvm_available_flush_tlb_with_range()) {
+   kvm_flush_remote_tlbs_with_address(kvm,
+   gfn_start,
+   gfn_end - gfn_start);
+   ret = 0;
+   }
}
}
 
-- 
2.14.4


[PATCH V3 7/13] KVM: Add flush_link and parent_pte in the struct kvm_mmu_page

2018-09-26 Thread Tianyu Lan
PV EPT tlb flush function will accept a list of flush ranges and
use struct kvm_mmu_page as the list entry.

Signed-off-by: Lan Tianyu 
---
 arch/x86/include/asm/kvm_host.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a6b77978502e..c96bc4cbe4b7 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -279,6 +279,7 @@ struct kvm_rmap_head {
 
 struct kvm_mmu_page {
struct list_head link;
+   struct list_head flush_link;
struct hlist_node hash_link;
 
/*
-- 
2.14.4


[PATCH V3 7/13] KVM: Add flush_link and parent_pte in the struct kvm_mmu_page

2018-09-26 Thread Tianyu Lan
PV EPT tlb flush function will accept a list of flush ranges and
use struct kvm_mmu_page as the list entry.

Signed-off-by: Lan Tianyu 
---
 arch/x86/include/asm/kvm_host.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a6b77978502e..c96bc4cbe4b7 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -279,6 +279,7 @@ struct kvm_rmap_head {
 
 struct kvm_mmu_page {
struct list_head link;
+   struct list_head flush_link;
struct hlist_node hash_link;
 
/*
-- 
2.14.4


[PATCH V3 13/13] KVM/VMX: Add hv tlb range flush support

2018-09-26 Thread Tianyu Lan
This patch is to register tlb_remote_flush_with_range callback with
hv tlb range flush interface.

Signed-off-by: Lan Tianyu 
---
Change since v1:
   Pass flush range with new hyper-v tlb flush struct rather
than KVM tlb flush struct.
---
 arch/x86/kvm/vmx.c | 58 +++---
 1 file changed, 51 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2869c3e78168..70e1f916bfc9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1555,7 +1555,43 @@ static void check_ept_pointer_match(struct kvm *kvm)
to_kvm_vmx(kvm)->ept_pointers_match = EPT_POINTERS_MATCH;
 }
 
-static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
+int kvm_parse_flush_list_func(union hv_gpa_page_range gpa_list[],
+   int offset, struct list_head *flush_list,
+   int (*fill_flush_list)(union hv_gpa_page_range gpa_list[],
+   int offset, u64 start_gfn, u64 end_gfn))
+{
+   struct kvm_mmu_page *sp;
+
+   list_for_each_entry(sp, flush_list,
+   flush_link) {
+   offset = fill_flush_list(gpa_list, offset,
+   sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level));
+   }
+
+   return offset;
+}
+
+static inline int __hv_remote_flush_tlb_with_range(struct kvm *kvm,
+   struct kvm_vcpu *vcpu, struct kvm_tlb_range *range)
+{
+   u64 ept_pointer = to_vmx(vcpu)->ept_pointer;
+   struct hyperv_tlb_range flush_range;
+
+   if (range) {
+   flush_range.start_gfn = range->start_gfn;
+   flush_range.pages = range->pages;
+   flush_range.flush_list = range->flush_list;
+   flush_range.parse_flush_list_func = kvm_parse_flush_list_func;
+
+   return hyperv_flush_guest_mapping_range(ept_pointer,
+   _range);
+   } else {
+   return hyperv_flush_guest_mapping(ept_pointer);
+   }
+}
+
+static int hv_remote_flush_tlb_with_range(struct kvm *kvm,
+   struct kvm_tlb_range *range)
 {
struct kvm_vcpu *vcpu;
int ret = -ENOTSUPP, i;
@@ -1567,16 +1603,21 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
 
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
kvm_for_each_vcpu(i, vcpu, kvm)
-   ret |= hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer);
+   ret |= __hv_remote_flush_tlb_with_range(
+   kvm, vcpu, range);
} else {
-   ret = hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
+   ret = __hv_remote_flush_tlb_with_range(kvm,
+   kvm_get_vcpu(kvm, 0), range);
}
 
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
return ret;
 }
+
+static int hv_remote_flush_tlb(struct kvm *kvm)
+{
+   return hv_remote_flush_tlb_with_range(kvm, NULL);
+}
 #else /* !IS_ENABLED(CONFIG_HYPERV) */
 static inline void evmcs_write64(unsigned long field, u64 value) {}
 static inline void evmcs_write32(unsigned long field, u32 value) {}
@@ -7918,8 +7959,11 @@ static __init int hardware_setup(void)
 
 #if IS_ENABLED(CONFIG_HYPERV)
if (ms_hyperv.nested_features & HV_X64_NESTED_GUEST_MAPPING_FLUSH
-   && enable_ept)
-   kvm_x86_ops->tlb_remote_flush = vmx_hv_remote_flush_tlb;
+   && enable_ept) {
+   kvm_x86_ops->tlb_remote_flush = hv_remote_flush_tlb;
+   kvm_x86_ops->tlb_remote_flush_with_range =
+   hv_remote_flush_tlb_with_range;
+   }
 #endif
 
if (!cpu_has_vmx_ple()) {
-- 
2.14.4


[PATCH V3 8/13] KVM: Add spte's point in the struct kvm_mmu_page

2018-09-26 Thread Tianyu Lan
It's necessary to check whether mmu page is last or large page when add
mmu page into flush list. "spte" is needed for such check and so add
spte point in the struct kvm_mmu_page.

Signed-off-by: Lan Tianyu 
---
 arch/x86/include/asm/kvm_host.h | 1 +
 arch/x86/kvm/mmu.c  | 5 +
 arch/x86/kvm/paging_tmpl.h  | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c96bc4cbe4b7..d42d96e637b5 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -296,6 +296,7 @@ struct kvm_mmu_page {
int root_count;  /* Currently serving as active root */
unsigned int unsync_children;
struct kvm_rmap_head parent_ptes; /* rmap pointers to parent sptes */
+   u64 *sptep;
 
/* The page is obsolete if mmu_valid_gen != kvm->arch.mmu_valid_gen.  */
unsigned long mmu_valid_gen;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7c508c4bd204..a1cbbc852271 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3162,6 +3162,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write, 
int map_writable,
pseudo_gfn = base_addr >> PAGE_SHIFT;
sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
  iterator.level - 1, 1, ACC_ALL);
+   sp->sptep = iterator.sptep;
 
link_shadow_page(vcpu, iterator.sptep, sp);
}
@@ -3599,6 +3600,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
sp = kvm_mmu_get_page(vcpu, 0, 0,
vcpu->arch.mmu.shadow_root_level, 1, ACC_ALL);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = __pa(sp->spt);
} else if (vcpu->arch.mmu.shadow_root_level == PT32E_ROOT_LEVEL) {
@@ -3615,6 +3617,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
i << 30, PT32_ROOT_LEVEL, 1, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.pae_root[i] = root | PT_PRESENT_MASK;
}
@@ -3655,6 +3658,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
vcpu->arch.mmu.shadow_root_level, 0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = root;
return 0;
@@ -3692,6 +3696,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
  0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
 
vcpu->arch.mmu.pae_root[i] = root | pm_mask;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 708a5e44861a..5cbaf7c4a729 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -632,6 +632,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
table_gfn = gw->table_gfn[it.level - 2];
sp = kvm_mmu_get_page(vcpu, table_gfn, addr, it.level-1,
  false, access);
+   sp->sptep = it.sptep;
}
 
/*
@@ -662,6 +663,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
 
sp = kvm_mmu_get_page(vcpu, direct_gfn, addr, it.level-1,
  true, direct_access);
+   sp->sptep = it.sptep;
link_shadow_page(vcpu, it.sptep, sp);
}
 
-- 
2.14.4


[PATCH V3 13/13] KVM/VMX: Add hv tlb range flush support

2018-09-26 Thread Tianyu Lan
This patch is to register tlb_remote_flush_with_range callback with
hv tlb range flush interface.

Signed-off-by: Lan Tianyu 
---
Change since v1:
   Pass flush range with new hyper-v tlb flush struct rather
than KVM tlb flush struct.
---
 arch/x86/kvm/vmx.c | 58 +++---
 1 file changed, 51 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2869c3e78168..70e1f916bfc9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1555,7 +1555,43 @@ static void check_ept_pointer_match(struct kvm *kvm)
to_kvm_vmx(kvm)->ept_pointers_match = EPT_POINTERS_MATCH;
 }
 
-static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
+int kvm_parse_flush_list_func(union hv_gpa_page_range gpa_list[],
+   int offset, struct list_head *flush_list,
+   int (*fill_flush_list)(union hv_gpa_page_range gpa_list[],
+   int offset, u64 start_gfn, u64 end_gfn))
+{
+   struct kvm_mmu_page *sp;
+
+   list_for_each_entry(sp, flush_list,
+   flush_link) {
+   offset = fill_flush_list(gpa_list, offset,
+   sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level));
+   }
+
+   return offset;
+}
+
+static inline int __hv_remote_flush_tlb_with_range(struct kvm *kvm,
+   struct kvm_vcpu *vcpu, struct kvm_tlb_range *range)
+{
+   u64 ept_pointer = to_vmx(vcpu)->ept_pointer;
+   struct hyperv_tlb_range flush_range;
+
+   if (range) {
+   flush_range.start_gfn = range->start_gfn;
+   flush_range.pages = range->pages;
+   flush_range.flush_list = range->flush_list;
+   flush_range.parse_flush_list_func = kvm_parse_flush_list_func;
+
+   return hyperv_flush_guest_mapping_range(ept_pointer,
+   _range);
+   } else {
+   return hyperv_flush_guest_mapping(ept_pointer);
+   }
+}
+
+static int hv_remote_flush_tlb_with_range(struct kvm *kvm,
+   struct kvm_tlb_range *range)
 {
struct kvm_vcpu *vcpu;
int ret = -ENOTSUPP, i;
@@ -1567,16 +1603,21 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
 
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
kvm_for_each_vcpu(i, vcpu, kvm)
-   ret |= hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer);
+   ret |= __hv_remote_flush_tlb_with_range(
+   kvm, vcpu, range);
} else {
-   ret = hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
+   ret = __hv_remote_flush_tlb_with_range(kvm,
+   kvm_get_vcpu(kvm, 0), range);
}
 
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
return ret;
 }
+
+static int hv_remote_flush_tlb(struct kvm *kvm)
+{
+   return hv_remote_flush_tlb_with_range(kvm, NULL);
+}
 #else /* !IS_ENABLED(CONFIG_HYPERV) */
 static inline void evmcs_write64(unsigned long field, u64 value) {}
 static inline void evmcs_write32(unsigned long field, u32 value) {}
@@ -7918,8 +7959,11 @@ static __init int hardware_setup(void)
 
 #if IS_ENABLED(CONFIG_HYPERV)
if (ms_hyperv.nested_features & HV_X64_NESTED_GUEST_MAPPING_FLUSH
-   && enable_ept)
-   kvm_x86_ops->tlb_remote_flush = vmx_hv_remote_flush_tlb;
+   && enable_ept) {
+   kvm_x86_ops->tlb_remote_flush = hv_remote_flush_tlb;
+   kvm_x86_ops->tlb_remote_flush_with_range =
+   hv_remote_flush_tlb_with_range;
+   }
 #endif
 
if (!cpu_has_vmx_ple()) {
-- 
2.14.4


[PATCH V3 8/13] KVM: Add spte's point in the struct kvm_mmu_page

2018-09-26 Thread Tianyu Lan
It's necessary to check whether mmu page is last or large page when add
mmu page into flush list. "spte" is needed for such check and so add
spte point in the struct kvm_mmu_page.

Signed-off-by: Lan Tianyu 
---
 arch/x86/include/asm/kvm_host.h | 1 +
 arch/x86/kvm/mmu.c  | 5 +
 arch/x86/kvm/paging_tmpl.h  | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c96bc4cbe4b7..d42d96e637b5 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -296,6 +296,7 @@ struct kvm_mmu_page {
int root_count;  /* Currently serving as active root */
unsigned int unsync_children;
struct kvm_rmap_head parent_ptes; /* rmap pointers to parent sptes */
+   u64 *sptep;
 
/* The page is obsolete if mmu_valid_gen != kvm->arch.mmu_valid_gen.  */
unsigned long mmu_valid_gen;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7c508c4bd204..a1cbbc852271 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3162,6 +3162,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write, 
int map_writable,
pseudo_gfn = base_addr >> PAGE_SHIFT;
sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
  iterator.level - 1, 1, ACC_ALL);
+   sp->sptep = iterator.sptep;
 
link_shadow_page(vcpu, iterator.sptep, sp);
}
@@ -3599,6 +3600,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
sp = kvm_mmu_get_page(vcpu, 0, 0,
vcpu->arch.mmu.shadow_root_level, 1, ACC_ALL);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = __pa(sp->spt);
} else if (vcpu->arch.mmu.shadow_root_level == PT32E_ROOT_LEVEL) {
@@ -3615,6 +3617,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
i << 30, PT32_ROOT_LEVEL, 1, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.pae_root[i] = root | PT_PRESENT_MASK;
}
@@ -3655,6 +3658,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
vcpu->arch.mmu.shadow_root_level, 0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = root;
return 0;
@@ -3692,6 +3696,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
  0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+   sp->sptep = NULL;
spin_unlock(>kvm->mmu_lock);
 
vcpu->arch.mmu.pae_root[i] = root | pm_mask;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 708a5e44861a..5cbaf7c4a729 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -632,6 +632,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
table_gfn = gw->table_gfn[it.level - 2];
sp = kvm_mmu_get_page(vcpu, table_gfn, addr, it.level-1,
  false, access);
+   sp->sptep = it.sptep;
}
 
/*
@@ -662,6 +663,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
 
sp = kvm_mmu_get_page(vcpu, direct_gfn, addr, it.level-1,
  true, direct_access);
+   sp->sptep = it.sptep;
link_shadow_page(vcpu, it.sptep, sp);
}
 
-- 
2.14.4


[PATCH V3 9/13] KVM/MMU: Replace tlb flush function with range list flush function

2018-09-26 Thread Tianyu Lan
This patch is to use range list flush function in the
mmu_sync_children(), kvm_mmu_commit_zap_page() and
FNAME(sync_page)().

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 26 +++---
 arch/x86/kvm/paging_tmpl.h |  5 -
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index a1cbbc852271..5f3a69425142 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1092,6 +1092,13 @@ static void update_gfn_disallow_lpage_count(struct 
kvm_memory_slot *slot,
}
 }
 
+static void kvm_mmu_queue_flush_request(struct kvm_mmu_page *sp,
+   struct list_head *flush_list)
+{
+   if (sp->sptep && is_last_spte(*sp->sptep, sp->role.level))
+   list_add(>flush_link, flush_list);
+}
+
 void kvm_mmu_gfn_disallow_lpage(struct kvm_memory_slot *slot, gfn_t gfn)
 {
update_gfn_disallow_lpage_count(slot, gfn, 1);
@@ -2369,12 +2376,16 @@ static void mmu_sync_children(struct kvm_vcpu *vcpu,
 
while (mmu_unsync_walk(parent, )) {
bool protected = false;
+   LIST_HEAD(flush_list);
 
-   for_each_sp(pages, sp, parents, i)
+   for_each_sp(pages, sp, parents, i) {
protected |= rmap_write_protect(vcpu, sp->gfn);
+   kvm_mmu_queue_flush_request(sp, _list);
+   }
 
if (protected) {
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_list(vcpu->kvm,
+   _list);
flush = false;
}
 
@@ -2710,6 +2721,7 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
struct list_head *invalid_list)
 {
struct kvm_mmu_page *sp, *nsp;
+   LIST_HEAD(flush_list);
 
if (list_empty(invalid_list))
return;
@@ -2723,7 +2735,15 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
 * In addition, kvm_flush_remote_tlbs waits for all vcpus to exit
 * guest mode and/or lockless shadow page table walks.
 */
-   kvm_flush_remote_tlbs(kvm);
+   if (kvm_available_flush_tlb_with_range()) {
+   list_for_each_entry(sp, invalid_list, link)
+   kvm_mmu_queue_flush_request(sp, _list);
+
+   if (!list_empty(_list))
+   kvm_flush_remote_tlbs_with_list(kvm, _list);
+   } else {
+   kvm_flush_remote_tlbs(kvm);
+   }
 
list_for_each_entry_safe(sp, nsp, invalid_list, link) {
WARN_ON(!sp->role.invalid || sp->root_count);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 5cbaf7c4a729..a5f967e81429 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -972,6 +972,7 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, struct 
kvm_mmu_page *sp)
bool host_writable;
gpa_t first_pte_gpa;
int set_spte_ret = 0;
+   LIST_HEAD(flush_list);
 
/* direct kvm_mmu_page can not be unsync. */
BUG_ON(sp->role.direct);
@@ -1032,10 +1033,12 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, 
struct kvm_mmu_page *sp)
 pte_access, PT_PAGE_TABLE_LEVEL,
 gfn, spte_to_pfn(sp->spt[i]),
 true, false, host_writable);
+   if (set_spte_ret && kvm_available_flush_tlb_with_range())
+   kvm_mmu_queue_flush_request(sp, _list);
}
 
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_list(vcpu->kvm, _list);
 
return nr_present;
 }
-- 
2.14.4


[PATCH V3 11/13] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()

2018-09-26 Thread Tianyu Lan
This patch is to trace log in the hyperv_nested_flush_
guest_mapping_range().

Signed-off-by: Lan Tianyu 
---
 arch/x86/hyperv/nested.c|  1 +
 arch/x86/include/asm/trace/hyperv.h | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index a6fdfec63c7d..4850c74508f3 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -135,6 +135,7 @@ int hyperv_flush_guest_mapping_range(u64 as, struct 
hyperv_tlb_range *range)
else
ret = status;
 fault:
+   trace_hyperv_nested_flush_guest_mapping_range(as, ret);
return ret;
 }
 EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/trace/hyperv.h 
b/arch/x86/include/asm/trace/hyperv.h
index 2e6245a023ef..ace464f09681 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -42,6 +42,20 @@ TRACE_EVENT(hyperv_nested_flush_guest_mapping,
TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
);
 
+TRACE_EVENT(hyperv_nested_flush_guest_mapping_range,
+   TP_PROTO(u64 as, int ret),
+   TP_ARGS(as, ret),
+
+   TP_STRUCT__entry(
+   __field(u64, as)
+   __field(int, ret)
+   ),
+   TP_fast_assign(__entry->as = as;
+  __entry->ret = ret;
+   ),
+   TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+   );
+
 TRACE_EVENT(hyperv_send_ipi_mask,
TP_PROTO(const struct cpumask *cpus,
 int vector),
-- 
2.14.4


[PATCH V3 11/13] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()

2018-09-26 Thread Tianyu Lan
This patch is to trace log in the hyperv_nested_flush_
guest_mapping_range().

Signed-off-by: Lan Tianyu 
---
 arch/x86/hyperv/nested.c|  1 +
 arch/x86/include/asm/trace/hyperv.h | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index a6fdfec63c7d..4850c74508f3 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -135,6 +135,7 @@ int hyperv_flush_guest_mapping_range(u64 as, struct 
hyperv_tlb_range *range)
else
ret = status;
 fault:
+   trace_hyperv_nested_flush_guest_mapping_range(as, ret);
return ret;
 }
 EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/trace/hyperv.h 
b/arch/x86/include/asm/trace/hyperv.h
index 2e6245a023ef..ace464f09681 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -42,6 +42,20 @@ TRACE_EVENT(hyperv_nested_flush_guest_mapping,
TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
);
 
+TRACE_EVENT(hyperv_nested_flush_guest_mapping_range,
+   TP_PROTO(u64 as, int ret),
+   TP_ARGS(as, ret),
+
+   TP_STRUCT__entry(
+   __field(u64, as)
+   __field(int, ret)
+   ),
+   TP_fast_assign(__entry->as = as;
+  __entry->ret = ret;
+   ),
+   TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+   );
+
 TRACE_EVENT(hyperv_send_ipi_mask,
TP_PROTO(const struct cpumask *cpus,
 int vector),
-- 
2.14.4


[PATCH V3 9/13] KVM/MMU: Replace tlb flush function with range list flush function

2018-09-26 Thread Tianyu Lan
This patch is to use range list flush function in the
mmu_sync_children(), kvm_mmu_commit_zap_page() and
FNAME(sync_page)().

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 26 +++---
 arch/x86/kvm/paging_tmpl.h |  5 -
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index a1cbbc852271..5f3a69425142 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1092,6 +1092,13 @@ static void update_gfn_disallow_lpage_count(struct 
kvm_memory_slot *slot,
}
 }
 
+static void kvm_mmu_queue_flush_request(struct kvm_mmu_page *sp,
+   struct list_head *flush_list)
+{
+   if (sp->sptep && is_last_spte(*sp->sptep, sp->role.level))
+   list_add(>flush_link, flush_list);
+}
+
 void kvm_mmu_gfn_disallow_lpage(struct kvm_memory_slot *slot, gfn_t gfn)
 {
update_gfn_disallow_lpage_count(slot, gfn, 1);
@@ -2369,12 +2376,16 @@ static void mmu_sync_children(struct kvm_vcpu *vcpu,
 
while (mmu_unsync_walk(parent, )) {
bool protected = false;
+   LIST_HEAD(flush_list);
 
-   for_each_sp(pages, sp, parents, i)
+   for_each_sp(pages, sp, parents, i) {
protected |= rmap_write_protect(vcpu, sp->gfn);
+   kvm_mmu_queue_flush_request(sp, _list);
+   }
 
if (protected) {
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_list(vcpu->kvm,
+   _list);
flush = false;
}
 
@@ -2710,6 +2721,7 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
struct list_head *invalid_list)
 {
struct kvm_mmu_page *sp, *nsp;
+   LIST_HEAD(flush_list);
 
if (list_empty(invalid_list))
return;
@@ -2723,7 +2735,15 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
 * In addition, kvm_flush_remote_tlbs waits for all vcpus to exit
 * guest mode and/or lockless shadow page table walks.
 */
-   kvm_flush_remote_tlbs(kvm);
+   if (kvm_available_flush_tlb_with_range()) {
+   list_for_each_entry(sp, invalid_list, link)
+   kvm_mmu_queue_flush_request(sp, _list);
+
+   if (!list_empty(_list))
+   kvm_flush_remote_tlbs_with_list(kvm, _list);
+   } else {
+   kvm_flush_remote_tlbs(kvm);
+   }
 
list_for_each_entry_safe(sp, nsp, invalid_list, link) {
WARN_ON(!sp->role.invalid || sp->root_count);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 5cbaf7c4a729..a5f967e81429 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -972,6 +972,7 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, struct 
kvm_mmu_page *sp)
bool host_writable;
gpa_t first_pte_gpa;
int set_spte_ret = 0;
+   LIST_HEAD(flush_list);
 
/* direct kvm_mmu_page can not be unsync. */
BUG_ON(sp->role.direct);
@@ -1032,10 +1033,12 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, 
struct kvm_mmu_page *sp)
 pte_access, PT_PAGE_TABLE_LEVEL,
 gfn, spte_to_pfn(sp->spt[i]),
 true, false, host_writable);
+   if (set_spte_ret && kvm_available_flush_tlb_with_range())
+   kvm_mmu_queue_flush_request(sp, _list);
}
 
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_list(vcpu->kvm, _list);
 
return nr_present;
 }
-- 
2.14.4


[PATCH V3 12/13] KVM/VMX: Change hv flush logic when ept tables are mismatched.

2018-09-26 Thread Tianyu Lan
If ept table pointers are mismatched, flushing tlb for each vcpus via
hv flush interface still helps to reduce vmexits which are triggered
by IPI and INEPT emulation.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/vmx.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 533a327372c8..2869c3e78168 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1557,7 +1557,8 @@ static void check_ept_pointer_match(struct kvm *kvm)
 
 static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
 {
-   int ret;
+   struct kvm_vcpu *vcpu;
+   int ret = -ENOTSUPP, i;
 
spin_lock(_kvm_vmx(kvm)->ept_pointer_lock);
 
@@ -1565,14 +1566,14 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
check_ept_pointer_match(kvm);
 
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
-   ret = -ENOTSUPP;
-   goto out;
+   kvm_for_each_vcpu(i, vcpu, kvm)
+   ret |= hyperv_flush_guest_mapping(
+   to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer);
+   } else {
+   ret = hyperv_flush_guest_mapping(
+   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
}
 
-   ret = hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
-
-out:
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
return ret;
 }
-- 
2.14.4


[PATCH V3 12/13] KVM/VMX: Change hv flush logic when ept tables are mismatched.

2018-09-26 Thread Tianyu Lan
If ept table pointers are mismatched, flushing tlb for each vcpus via
hv flush interface still helps to reduce vmexits which are triggered
by IPI and INEPT emulation.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/vmx.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 533a327372c8..2869c3e78168 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1557,7 +1557,8 @@ static void check_ept_pointer_match(struct kvm *kvm)
 
 static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
 {
-   int ret;
+   struct kvm_vcpu *vcpu;
+   int ret = -ENOTSUPP, i;
 
spin_lock(_kvm_vmx(kvm)->ept_pointer_lock);
 
@@ -1565,14 +1566,14 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
check_ept_pointer_match(kvm);
 
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
-   ret = -ENOTSUPP;
-   goto out;
+   kvm_for_each_vcpu(i, vcpu, kvm)
+   ret |= hyperv_flush_guest_mapping(
+   to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer);
+   } else {
+   ret = hyperv_flush_guest_mapping(
+   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
}
 
-   ret = hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
-
-out:
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
return ret;
 }
-- 
2.14.4


[PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

2018-09-26 Thread Tianyu Lan
Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
with specified ranges. This patch is to add the hypercall support.

Signed-off-by: Lan Tianyu 
---
Change since v2:
  Fix some coding style issues
- Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
hyperv-tlfs.h.
- Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
- Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
struct hv_guest_mapping_flush_list.

Change since v1:
   Add hyperv tlb flush struct to avoid use kvm tlb flush struct
in the hyperv file.
---
 arch/x86/hyperv/nested.c   | 84 ++
 arch/x86/include/asm/hyperv-tlfs.h | 32 +++
 arch/x86/include/asm/mshyperv.h| 16 
 3 files changed, 132 insertions(+)

diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index b8e60cc50461..a6fdfec63c7d 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -7,6 +7,7 @@
  *
  * Author : Lan Tianyu 
  */
+#define pr_fmt(fmt)  "Hyper-V: " fmt
 
 
 #include 
@@ -54,3 +55,86 @@ int hyperv_flush_guest_mapping(u64 as)
return ret;
 }
 EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
+
+static int fill_flush_list(union hv_gpa_page_range gpa_list[],
+   int offset, u64 start_gfn, u64 pages)
+{
+   int gpa_n = offset;
+   u64 cur = start_gfn;
+   u64 additional_pages;
+
+   do {
+   /*
+* If flush requests exceed max flush count, go back to
+* flush tlbs without range.
+*/
+   if (gpa_n >= HV_MAX_FLUSH_REP_COUNT)
+   return -ENOSPC;
+
+   additional_pages = min_t(u64, pages, HV_MAX_FLUSH_PAGES) - 1;
+
+   gpa_list[gpa_n].page.additional_pages = additional_pages;
+   gpa_list[gpa_n].page.largepage = false;
+   gpa_list[gpa_n].page.basepfn = cur;
+
+   pages -= additional_pages + 1;
+   cur += additional_pages + 1;
+   gpa_n++;
+   } while (pages > 0);
+
+   return gpa_n;
+}
+
+int hyperv_flush_guest_mapping_range(u64 as, struct hyperv_tlb_range *range)
+{
+   struct hv_guest_mapping_flush_list **flush_pcpu;
+   struct hv_guest_mapping_flush_list *flush;
+   u64 status = 0;
+   unsigned long flags;
+   int ret = -ENOTSUPP;
+   int gpa_n = 0;
+
+   if (!hv_hypercall_pg)
+   goto fault;
+
+   local_irq_save(flags);
+
+   flush_pcpu = (struct hv_guest_mapping_flush_list **)
+   this_cpu_ptr(hyperv_pcpu_input_arg);
+
+   flush = *flush_pcpu;
+   if (unlikely(!flush)) {
+   local_irq_restore(flags);
+   goto fault;
+   }
+
+   flush->address_space = as;
+   flush->flags = 0;
+
+   if (!range->flush_list)
+   gpa_n = fill_flush_list(flush->gpa_list, gpa_n,
+   range->start_gfn, range->pages);
+   else if (range->parse_flush_list_func)
+   gpa_n = range->parse_flush_list_func(flush->gpa_list, gpa_n,
+   range->flush_list, fill_flush_list);
+   else
+   gpa_n = -1;
+
+   if (gpa_n < 0) {
+   local_irq_restore(flags);
+   goto fault;
+   }
+
+   status = hv_do_rep_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST,
+gpa_n, 0, flush, NULL);
+
+   local_irq_restore(flags);
+
+   if (!(status & HV_HYPERCALL_RESULT_MASK))
+   ret = 0;
+   else
+   ret = status;
+fault:
+   return ret;
+}
+EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/hyperv-tlfs.h 
b/arch/x86/include/asm/hyperv-tlfs.h
index e977b6b3a538..e38743328dfc 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -10,6 +10,7 @@
 #define _ASM_X86_HYPERV_TLFS_H
 
 #include 
+#include 
 
 /*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
@@ -353,6 +354,7 @@ struct hv_tsc_emulation_status {
 #define HVCALL_POST_MESSAGE0x005c
 #define HVCALL_SIGNAL_EVENT0x005d
 #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
+#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
 
 #define HV_X64_MSR_VP_ASSIST_PAGE_ENABLE   0x0001
 #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT12
@@ -750,6 +752,36 @@ struct hv_guest_mapping_flush {
u64 flags;
 };
 
+/*
+ *  HV_MAX_FLUSH_PAGES = "additional_pages" + 1. It's limited
+ *  by the bitwidth of "additional_pages" in union hv_gpa_page_range.
+ */
+#define HV_MAX_FLUSH_PAGES (2048)
+
+/* HvFlushGuestPhysicalAddressList hypercall */
+union hv_gpa_page_range {
+   u64 address_space;
+   struct {
+   u64 additional_pages:11;
+   u64 largepage:1;
+   u64 basepfn:52;
+   } page;

[PATCH V3 3/13] KVM: Replace old tlb flush function with new one to flush a specified range.

2018-09-26 Thread Tianyu Lan
This patch is to replace kvm_flush_remote_tlbs() with kvm_flush_
remote_tlbs_with_address() in some functions without logic change.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 33 ++---
 arch/x86/kvm/paging_tmpl.h |  3 ++-
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 18cac661a41a..d10d8423e8d6 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1482,8 +1482,12 @@ static bool __drop_large_spte(struct kvm *kvm, u64 
*sptep)
 
 static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
 {
-   if (__drop_large_spte(vcpu->kvm, sptep))
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   if (__drop_large_spte(vcpu->kvm, sptep)) {
+   struct kvm_mmu_page *sp = page_header(__pa(sptep));
+
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+   KVM_PAGES_PER_HPAGE(sp->role.level));
+   }
 }
 
 /*
@@ -1770,7 +1774,7 @@ static int kvm_set_pte_rmapp(struct kvm *kvm, struct 
kvm_rmap_head *rmap_head,
}
 
if (need_flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, gfn, 1);
 
return 0;
 }
@@ -1951,7 +1955,8 @@ static void rmap_recycle(struct kvm_vcpu *vcpu, u64 
*spte, gfn_t gfn)
rmap_head = gfn_to_rmap(vcpu->kvm, gfn, sp);
 
kvm_unmap_rmapp(vcpu->kvm, rmap_head, NULL, gfn, sp->role.level, 0);
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+   KVM_PAGES_PER_HPAGE(sp->role.level));
 }
 
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
@@ -2467,7 +2472,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct 
kvm_vcpu *vcpu,
account_shadowed(vcpu->kvm, sp);
if (level == PT_PAGE_TABLE_LEVEL &&
  rmap_write_protect(vcpu, gfn))
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, 1);
 
if (level > PT_PAGE_TABLE_LEVEL && need_sync)
flush |= kvm_sync_pages(vcpu, gfn, _list);
@@ -2587,7 +2592,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, 
u64 *sptep,
return;
 
drop_parent_pte(child, sptep);
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1);
}
 }
 
@@ -3011,8 +3016,10 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep, unsigned pte_access,
ret = RET_PF_EMULATE;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
}
+
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH || flush)
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn,
+   KVM_PAGES_PER_HPAGE(level));
 
if (unlikely(is_mmio_spte(*sptep)))
ret = RET_PF_EMULATE;
@@ -5621,7 +5628,8 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
 * on PT_WRITABLE_MASK anymore.
 */
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 
 static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
@@ -5685,7 +5693,8 @@ void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
 * dirty_bitmap.
 */
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_leaf_clear_dirty);
 
@@ -5703,7 +5712,8 @@ void kvm_mmu_slot_largepage_remove_write_access(struct 
kvm *kvm,
lockdep_assert_held(>slots_lock);
 
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_largepage_remove_write_access);
 
@@ -5720,7 +5730,8 @@ void kvm_mmu_slot_set_dirty(struct kvm *kvm,
 
/* see kvm_mmu_slot_leaf_clear_dirty */
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_set_dirty);
 
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 14ffd973df54..708a5e44861a 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -893,7 +893,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, 
hpa_t root_hpa)
pte_gpa += (sptep - sp->spt) * sizeof(pt_element_t);
 
if (mmu_page_zap_pte(vcpu->kvm, sp, sptep))

[PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

2018-09-26 Thread Tianyu Lan
Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
with specified ranges. This patch is to add the hypercall support.

Signed-off-by: Lan Tianyu 
---
Change since v2:
  Fix some coding style issues
- Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
hyperv-tlfs.h.
- Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
- Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
struct hv_guest_mapping_flush_list.

Change since v1:
   Add hyperv tlb flush struct to avoid use kvm tlb flush struct
in the hyperv file.
---
 arch/x86/hyperv/nested.c   | 84 ++
 arch/x86/include/asm/hyperv-tlfs.h | 32 +++
 arch/x86/include/asm/mshyperv.h| 16 
 3 files changed, 132 insertions(+)

diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index b8e60cc50461..a6fdfec63c7d 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -7,6 +7,7 @@
  *
  * Author : Lan Tianyu 
  */
+#define pr_fmt(fmt)  "Hyper-V: " fmt
 
 
 #include 
@@ -54,3 +55,86 @@ int hyperv_flush_guest_mapping(u64 as)
return ret;
 }
 EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
+
+static int fill_flush_list(union hv_gpa_page_range gpa_list[],
+   int offset, u64 start_gfn, u64 pages)
+{
+   int gpa_n = offset;
+   u64 cur = start_gfn;
+   u64 additional_pages;
+
+   do {
+   /*
+* If flush requests exceed max flush count, go back to
+* flush tlbs without range.
+*/
+   if (gpa_n >= HV_MAX_FLUSH_REP_COUNT)
+   return -ENOSPC;
+
+   additional_pages = min_t(u64, pages, HV_MAX_FLUSH_PAGES) - 1;
+
+   gpa_list[gpa_n].page.additional_pages = additional_pages;
+   gpa_list[gpa_n].page.largepage = false;
+   gpa_list[gpa_n].page.basepfn = cur;
+
+   pages -= additional_pages + 1;
+   cur += additional_pages + 1;
+   gpa_n++;
+   } while (pages > 0);
+
+   return gpa_n;
+}
+
+int hyperv_flush_guest_mapping_range(u64 as, struct hyperv_tlb_range *range)
+{
+   struct hv_guest_mapping_flush_list **flush_pcpu;
+   struct hv_guest_mapping_flush_list *flush;
+   u64 status = 0;
+   unsigned long flags;
+   int ret = -ENOTSUPP;
+   int gpa_n = 0;
+
+   if (!hv_hypercall_pg)
+   goto fault;
+
+   local_irq_save(flags);
+
+   flush_pcpu = (struct hv_guest_mapping_flush_list **)
+   this_cpu_ptr(hyperv_pcpu_input_arg);
+
+   flush = *flush_pcpu;
+   if (unlikely(!flush)) {
+   local_irq_restore(flags);
+   goto fault;
+   }
+
+   flush->address_space = as;
+   flush->flags = 0;
+
+   if (!range->flush_list)
+   gpa_n = fill_flush_list(flush->gpa_list, gpa_n,
+   range->start_gfn, range->pages);
+   else if (range->parse_flush_list_func)
+   gpa_n = range->parse_flush_list_func(flush->gpa_list, gpa_n,
+   range->flush_list, fill_flush_list);
+   else
+   gpa_n = -1;
+
+   if (gpa_n < 0) {
+   local_irq_restore(flags);
+   goto fault;
+   }
+
+   status = hv_do_rep_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST,
+gpa_n, 0, flush, NULL);
+
+   local_irq_restore(flags);
+
+   if (!(status & HV_HYPERCALL_RESULT_MASK))
+   ret = 0;
+   else
+   ret = status;
+fault:
+   return ret;
+}
+EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/hyperv-tlfs.h 
b/arch/x86/include/asm/hyperv-tlfs.h
index e977b6b3a538..e38743328dfc 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -10,6 +10,7 @@
 #define _ASM_X86_HYPERV_TLFS_H
 
 #include 
+#include 
 
 /*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
@@ -353,6 +354,7 @@ struct hv_tsc_emulation_status {
 #define HVCALL_POST_MESSAGE0x005c
 #define HVCALL_SIGNAL_EVENT0x005d
 #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
+#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
 
 #define HV_X64_MSR_VP_ASSIST_PAGE_ENABLE   0x0001
 #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT12
@@ -750,6 +752,36 @@ struct hv_guest_mapping_flush {
u64 flags;
 };
 
+/*
+ *  HV_MAX_FLUSH_PAGES = "additional_pages" + 1. It's limited
+ *  by the bitwidth of "additional_pages" in union hv_gpa_page_range.
+ */
+#define HV_MAX_FLUSH_PAGES (2048)
+
+/* HvFlushGuestPhysicalAddressList hypercall */
+union hv_gpa_page_range {
+   u64 address_space;
+   struct {
+   u64 additional_pages:11;
+   u64 largepage:1;
+   u64 basepfn:52;
+   } page;

[PATCH V3 3/13] KVM: Replace old tlb flush function with new one to flush a specified range.

2018-09-26 Thread Tianyu Lan
This patch is to replace kvm_flush_remote_tlbs() with kvm_flush_
remote_tlbs_with_address() in some functions without logic change.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 33 ++---
 arch/x86/kvm/paging_tmpl.h |  3 ++-
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 18cac661a41a..d10d8423e8d6 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1482,8 +1482,12 @@ static bool __drop_large_spte(struct kvm *kvm, u64 
*sptep)
 
 static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
 {
-   if (__drop_large_spte(vcpu->kvm, sptep))
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   if (__drop_large_spte(vcpu->kvm, sptep)) {
+   struct kvm_mmu_page *sp = page_header(__pa(sptep));
+
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+   KVM_PAGES_PER_HPAGE(sp->role.level));
+   }
 }
 
 /*
@@ -1770,7 +1774,7 @@ static int kvm_set_pte_rmapp(struct kvm *kvm, struct 
kvm_rmap_head *rmap_head,
}
 
if (need_flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, gfn, 1);
 
return 0;
 }
@@ -1951,7 +1955,8 @@ static void rmap_recycle(struct kvm_vcpu *vcpu, u64 
*spte, gfn_t gfn)
rmap_head = gfn_to_rmap(vcpu->kvm, gfn, sp);
 
kvm_unmap_rmapp(vcpu->kvm, rmap_head, NULL, gfn, sp->role.level, 0);
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+   KVM_PAGES_PER_HPAGE(sp->role.level));
 }
 
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
@@ -2467,7 +2472,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct 
kvm_vcpu *vcpu,
account_shadowed(vcpu->kvm, sp);
if (level == PT_PAGE_TABLE_LEVEL &&
  rmap_write_protect(vcpu, gfn))
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, 1);
 
if (level > PT_PAGE_TABLE_LEVEL && need_sync)
flush |= kvm_sync_pages(vcpu, gfn, _list);
@@ -2587,7 +2592,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, 
u64 *sptep,
return;
 
drop_parent_pte(child, sptep);
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1);
}
 }
 
@@ -3011,8 +3016,10 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep, unsigned pte_access,
ret = RET_PF_EMULATE;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
}
+
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH || flush)
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn,
+   KVM_PAGES_PER_HPAGE(level));
 
if (unlikely(is_mmio_spte(*sptep)))
ret = RET_PF_EMULATE;
@@ -5621,7 +5628,8 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
 * on PT_WRITABLE_MASK anymore.
 */
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 
 static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
@@ -5685,7 +5693,8 @@ void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
 * dirty_bitmap.
 */
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_leaf_clear_dirty);
 
@@ -5703,7 +5712,8 @@ void kvm_mmu_slot_largepage_remove_write_access(struct 
kvm *kvm,
lockdep_assert_held(>slots_lock);
 
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_largepage_remove_write_access);
 
@@ -5720,7 +5730,8 @@ void kvm_mmu_slot_set_dirty(struct kvm *kvm,
 
/* see kvm_mmu_slot_leaf_clear_dirty */
if (flush)
-   kvm_flush_remote_tlbs(kvm);
+   kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+   memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_set_dirty);
 
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 14ffd973df54..708a5e44861a 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -893,7 +893,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, 
hpa_t root_hpa)
pte_gpa += (sptep - sp->spt) * sizeof(pt_element_t);
 
if (mmu_page_zap_pte(vcpu->kvm, sp, sptep))

[PATCH V3 1/13] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops

2018-09-26 Thread Tianyu Lan
Add flush range call back in the kvm_x86_ops and platform can use it
to register its associated function. The parameter "kvm_tlb_range"
accepts a single range and flush list which contains a list of ranges.

Signed-off-by: Lan Tianyu 
---
Change since v1:
   Change "end_gfn" to "pages" to aviod confusion as to whether
"end_gfn" is inclusive or exlusive.
---
 arch/x86/include/asm/kvm_host.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8e90488c3d56..a6b77978502e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -402,6 +402,12 @@ struct kvm_mmu {
u64 pdptrs[4]; /* pae */
 };
 
+struct kvm_tlb_range {
+   u64 start_gfn;
+   u64 pages;
+   struct list_head *flush_list;
+};
+
 enum pmc_type {
KVM_PMC_GP = 0,
KVM_PMC_FIXED,
@@ -991,6 +997,8 @@ struct kvm_x86_ops {
 
void (*tlb_flush)(struct kvm_vcpu *vcpu, bool invalidate_gpa);
int  (*tlb_remote_flush)(struct kvm *kvm);
+   int  (*tlb_remote_flush_with_range)(struct kvm *kvm,
+   struct kvm_tlb_range *range);
 
/*
 * Flush any TLB entries associated with the given GVA.
-- 
2.14.4


[PATCH V3 1/13] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops

2018-09-26 Thread Tianyu Lan
Add flush range call back in the kvm_x86_ops and platform can use it
to register its associated function. The parameter "kvm_tlb_range"
accepts a single range and flush list which contains a list of ranges.

Signed-off-by: Lan Tianyu 
---
Change since v1:
   Change "end_gfn" to "pages" to aviod confusion as to whether
"end_gfn" is inclusive or exlusive.
---
 arch/x86/include/asm/kvm_host.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8e90488c3d56..a6b77978502e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -402,6 +402,12 @@ struct kvm_mmu {
u64 pdptrs[4]; /* pae */
 };
 
+struct kvm_tlb_range {
+   u64 start_gfn;
+   u64 pages;
+   struct list_head *flush_list;
+};
+
 enum pmc_type {
KVM_PMC_GP = 0,
KVM_PMC_FIXED,
@@ -991,6 +997,8 @@ struct kvm_x86_ops {
 
void (*tlb_flush)(struct kvm_vcpu *vcpu, bool invalidate_gpa);
int  (*tlb_remote_flush)(struct kvm *kvm);
+   int  (*tlb_remote_flush_with_range)(struct kvm *kvm,
+   struct kvm_tlb_range *range);
 
/*
 * Flush any TLB entries associated with the given GVA.
-- 
2.14.4


[PATCH V3 5/13] KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()

2018-09-26 Thread Tianyu Lan
Originally, flush tlb is done by slot_handle_level_range(). This patch
is to flush tlb directly in the kvm_zap_gfn_range() when range
flush is available.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 877edae0401f..f24101ef763e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5578,6 +5578,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, 
gfn_t gfn_end)
 {
struct kvm_memslots *slots;
struct kvm_memory_slot *memslot;
+   bool flush = false;
int i;
 
spin_lock(>mmu_lock);
@@ -5585,18 +5586,27 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t 
gfn_start, gfn_t gfn_end)
slots = __kvm_memslots(kvm, i);
kvm_for_each_memslot(memslot, slots) {
gfn_t start, end;
+   bool flush_tlb = true;
 
start = max(gfn_start, memslot->base_gfn);
end = min(gfn_end, memslot->base_gfn + memslot->npages);
if (start >= end)
continue;
 
-   slot_handle_level_range(kvm, memslot, kvm_zap_rmapp,
-   PT_PAGE_TABLE_LEVEL, 
PT_MAX_HUGEPAGE_LEVEL,
-   start, end - 1, true);
+   if (kvm_available_flush_tlb_with_range())
+   flush_tlb = false;
+
+   flush = slot_handle_level_range(kvm, memslot,
+   kvm_zap_rmapp, PT_PAGE_TABLE_LEVEL,
+   PT_MAX_HUGEPAGE_LEVEL, start,
+   end - 1, flush_tlb);
}
}
 
+   if (flush && kvm_available_flush_tlb_with_range())
+   kvm_flush_remote_tlbs_with_address(kvm, gfn_start,
+   gfn_end - gfn_start + 1);
+
spin_unlock(>mmu_lock);
 }
 
-- 
2.14.4


[PATCH V3 00/13] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM

2018-09-26 Thread Tianyu Lan
For nested memory virtualization, Hyper-v doesn't set write-protect
L1 hypervisor EPT page directory and page table node to track changes 
while it relies on guest to tell it changes via HvFlushGuestAddressLlist
hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush
EPT page table with ranges which are specified by L1 hypervisor.

If L1 hypervisor uses INVEPT or HvFlushGuestAddressSpace hypercall to
flush EPT tlb, Hyper-V will invalidate associated EPT shadow page table
and sync L1's EPT table when next EPT page fault is triggered.
HvFlushGuestAddressLlist hypercall helps to avoid such redundant EPT
page fault and synchronization of shadow page table.

Change since v2:
   1) Fix comment in the kvm_flush_remote_tlbs_with_range()
   2) Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
hyperv-tlfs.h.
   3) Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
   4) Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
struct hv_guest_mapping_flush_list.


Change since v1:
   1) Convert "end_gfn" of struct kvm_tlb_range to "pages" in order
  to avoid confusion as to whether "end_gfn" is inclusive or exlusive.
   2) Add hyperv tlb range struct and replace kvm tlb range struct
  with new struct in order to avoid using kvm struct in the hyperv
  code directly.


Lan Tianyu (13):
  KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
  KVM/MMU: Add tlb flush with range helper function
  KVM: Replace old tlb flush function with new one to flush a specified
range.
  KVM/MMU: Flush tlb directly in the kvm_handle_hva_range()
  KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()
  KVM/MMU: Flush tlb directly in kvm_mmu_zap_collapsible_spte()
  KVM: Add flush_link and parent_pte in the struct kvm_mmu_page
  KVM: Add spte's point in the struct kvm_mmu_page
  KVM/MMU: Replace tlb flush function with range list flush function
  x86/hyper-v: Add HvFlushGuestAddressList hypercall support
  x86/Hyper-v: Add trace in the
hyperv_nested_flush_guest_mapping_range()
  KVM/VMX: Change hv flush logic when ept tables are mismatched.
  KVM/VMX: Add hv tlb range flush support

 arch/x86/hyperv/nested.c|  85 +
 arch/x86/include/asm/hyperv-tlfs.h  |  32 
 arch/x86/include/asm/kvm_host.h |  10 +++
 arch/x86/include/asm/mshyperv.h |  16 
 arch/x86/include/asm/trace/hyperv.h |  14 
 arch/x86/kvm/mmu.c  | 143 +++-
 arch/x86/kvm/paging_tmpl.h  |  10 ++-
 arch/x86/kvm/vmx.c  |  65 +---
 8 files changed, 345 insertions(+), 30 deletions(-)

-- 
2.14.4


  1   2   3   4   5   6   7   8   9   10   >