date:20201011

mtk-vcodec supports two kinds of firmware, VPU and SCP. Both were
supported from the same source files, but this is clearly unclean and
makes it more difficult to disable support for one or the other.

Move these implementations into their own file, after adding the
necessary private interfaces.

Signed-off-by: Alexandre Courbot 
---
 drivers/media/platform/mtk-vcodec/Makefile|   4 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  |   2 +-
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |   2 +-
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 174 +-
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.h |   7 +-
 .../platform/mtk-vcodec/mtk_vcodec_fw_priv.h  |  34 
 .../platform/mtk-vcodec/mtk_vcodec_fw_scp.c   |  73 
 .../platform/mtk-vcodec/mtk_vcodec_fw_vpu.c   | 109 +++
 8 files changed, 232 insertions(+), 173 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_scp.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_vpu.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index f679c6e1a3e9..6e1ea3a9f052 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -24,4 +24,6 @@ mtk-vcodec-enc-y := venc/venc_vp8_if.o \
 
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o \
-   mtk_vcodec_fw.o
+   mtk_vcodec_fw.o \
+   mtk_vcodec_fw_vpu.o \
+   mtk_vcodec_fw_scp.o
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index d14bc208ea5e..145686d2c219 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -241,7 +241,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
}
dma_set_max_seg_size(>dev, DMA_BIT_MASK(32));
 
-   dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, VPU_RST_DEC);
+   dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, DECODER);
if (IS_ERR(dev->fw_handler))
return PTR_ERR(dev->fw_handler);
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index dcfa2c2d4def..3be8a04c4c67 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -293,7 +293,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
}
dma_set_max_seg_size(>dev, DMA_BIT_MASK(32));
 
-   dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, VPU_RST_ENC);
+   dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, ENCODER);
if (IS_ERR(dev->fw_handler))
return PTR_ERR(dev->fw_handler);
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
index 6c2a2568d844..94b39ae5c2e1 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
@@ -1,193 +1,29 @@
 // SPDX-License-Identifier: GPL-2.0
 
 #include "mtk_vcodec_fw.h"
+#include "mtk_vcodec_fw_priv.h"
 #include "mtk_vcodec_util.h"
 #include "mtk_vcodec_drv.h"
 
-struct mtk_vcodec_fw_ops {
-   int (*load_firmware)(struct mtk_vcodec_fw *fw);
-   unsigned int (*get_vdec_capa)(struct mtk_vcodec_fw *fw);
-   unsigned int (*get_venc_capa)(struct mtk_vcodec_fw *fw);
-   void * (*map_dm_addr)(struct mtk_vcodec_fw *fw, u32 dtcm_dmem_addr);
-   int (*ipi_register)(struct mtk_vcodec_fw *fw, int id,
-   mtk_vcodec_ipi_handler handler, const char *name, 
void *priv);
-   int (*ipi_send)(struct mtk_vcodec_fw *fw, int id, void *buf,
-   unsigned int len, unsigned int wait);
-};
-
-struct mtk_vcodec_fw {
-   enum mtk_vcodec_fw_type type;
-   const struct mtk_vcodec_fw_ops *ops;
-   struct platform_device *pdev;
-   struct mtk_scp *scp;
-};
-
-static int mtk_vcodec_vpu_load_firmware(struct mtk_vcodec_fw *fw)
-{
-   return vpu_load_firmware(fw->pdev);
-}
-
-static unsigned int mtk_vcodec_vpu_get_vdec_capa(struct mtk_vcodec_fw *fw)
-{
-   return vpu_get_vdec_hw_capa(fw->pdev);
-}
-
-static unsigned int mtk_vcodec_vpu_get_venc_capa(struct mtk_vcodec_fw *fw)
-{
-   return vpu_get_venc_hw_capa(fw->pdev);
-}
-
-static void *mtk_vcodec_vpu_map_dm_addr(struct mtk_vcodec_fw *fw,
-   u32 dtcm_dmem_addr)
-{
-   return vpu_mapping_dm_addr(fw->pdev, dtcm_dmem_addr);
-}
-
-static int mtk_vcodec_vpu_set_ipi_register(struct mtk_vcodec_fw *fw, int id,
-  mtk_vcodec_ipi_handler handler,
-  const char *name, void *priv)
-{
-   /*
-* The handler

Re: [PATCH v2 add prerequisite-patch-id] btrfs: fix devid 0 without a replace item by failing the mount

2020-10-11 Thread Anand Jain




Accidentally this patch went to the stable. Pls, ignore. Sorry for the 
noise. Thanks.



On 12/10/20 1:26 pm, Anand Jain wrote:

If there is a BTRFS_DEV_REPLACE_DEVID without a replace item, then
it means some device is trying to attack or may be corrupted. Fail the
mount so that the user can remove the attacking or fix the corrupted
device.

As of now if BTRFS_DEV_REPLACE_DEVID is present without the replace
item, in __btrfs_free_extra_devids() we determine that there is an
extra device, and free those extra devices but continue to mount the
device.
However, we were wrong in keeping tack of the rw_devices so the syzbot
testcase failed as below [1].

[1]
WARNING: CPU: 1 PID: 3612 at fs/btrfs/volumes.c:1166 
close_fs_devices.part.0+0x607/0x800 fs/btrfs/volumes.c:1166
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 3612 Comm: syz-executor.2 Not tainted 5.9.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x198/0x1fd lib/dump_stack.c:118
  panic+0x347/0x7c0 kernel/panic.c:231
  __warn.cold+0x20/0x46 kernel/panic.c:600
  report_bug+0x1bd/0x210 lib/bug.c:198
  handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
  exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
  asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
RIP: 0010:close_fs_devices.part.0+0x607/0x800 fs/btrfs/volumes.c:1166
Code: 0f b6 04 02 84 c0 74 02 7e 33 48 8b 44 24 18 c6 80 30 01 00 00 00 48 83 c4 30 
5b 5d 41 5c 41 5d 41 5e 41 5f c3 e8 99 ce 6a fe <0f> 0b e9 71 ff ff ff e8 8d ce 
6a fe 0f 0b e9 20 ff ff ff e8 d1 d5
RSP: 0018:c900091777e0 EFLAGS: 00010246
RAX: 0004 RBX:  RCX: c9000c8b7000
RDX: 0004 RSI: 83097f47 RDI: 0007
RBP: dc00 R08: 0001 R09: 8880988a187f
R10:  R11: 0001 R12: 88809593a130
R13: 88809593a1ec R14: 8880988a1908 R15: 88809593a050
  close_fs_devices fs/btrfs/volumes.c:1193 [inline]
  btrfs_close_devices+0x95/0x1f0 fs/btrfs/volumes.c:1179
  open_ctree+0x4984/0x4a2d fs/btrfs/disk-io.c:3434
  btrfs_fill_super fs/btrfs/super.c:1316 [inline]
  btrfs_mount_root.cold+0x14/0x165 fs/btrfs/super.c:1672

The fix here is, when we determine that there isn't a replace item
then fail the mount if there is a replace target device (devid 0).

Reported-by: syzbot+4cfe71a4da060be47...@syzkaller.appspotmail.com
Signed-off-by: Anand Jain 
---
Depends on the patches
  btrfs: drop never met condition of disk_total_bytes == 0
  btrfs: fix btrfs_find_device unused arg seed
If these patches aren't integrated yet, then please add the last arg in
the function btrfs_find_device(). Any value is fine as it doesn't care.

fstest case will follow.

v2: changed title
 old: btrfs: fix rw_devices count in __btrfs_free_extra_devids

 In btrfs_init_dev_replace() try to match the presence of replace_item
 to the BTRFS_DEV_REPLACE_DEVID device. If fails then fail the
 mount. So drop the similar check in __btrfs_free_extra_devids().

  fs/btrfs/dev-replace.c | 26 --
  fs/btrfs/volumes.c | 26 +++---
  2 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 9340d03661cd..e2b7ae386224 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -91,6 +91,17 @@ int btrfs_init_dev_replace(struct btrfs_fs_info *fs_info)
ret = btrfs_search_slot(NULL, dev_root, , path, 0, 0);
if (ret) {
  no_valid_dev_replace_entry_found:
+   /*
+* We don't have a replace item or it's corrupted.
+* If there is a replace target, fail the mount.
+*/
+   if (btrfs_find_device(fs_info->fs_devices,
+ BTRFS_DEV_REPLACE_DEVID, NULL, NULL)) {
+   btrfs_err(fs_info,
+   "found replace target device without a replace item");
+   ret = -EIO;
+   goto out;
+   }
ret = 0;
dev_replace->replace_state =
BTRFS_IOCTL_DEV_REPLACE_STATE_NEVER_STARTED;
@@ -143,8 +154,19 @@ int btrfs_init_dev_replace(struct btrfs_fs_info *fs_info)
case BTRFS_IOCTL_DEV_REPLACE_STATE_NEVER_STARTED:
case BTRFS_IOCTL_DEV_REPLACE_STATE_FINISHED:
case BTRFS_IOCTL_DEV_REPLACE_STATE_CANCELED:
-   dev_replace->srcdev = NULL;
-   dev_replace->tgtdev = NULL;
+   /*
+* We don't have an active replace item but if there is a
+* replace target, fail the mount.
+*/
+   if (btrfs_find_device(fs_info->fs_devices,
+ BTRFS_DEV_REPLACE_DEVID, NULL, NULL)) {
+   btrfs_err(fs_info,
+

[PATCH v3 0/2] media: mtk-vcodec: fix builds when remoteproc is disabled

Thanks everyone for the feedback on v2. This version has grown a little bit, but
most of the added lines is just code moving around to new files. All in all this
certainly makes the driver a little bit cleaner.

Tested on both MT8173 and MT8183 and confirmed that the decoder was working on
both.

Changes since v2:
* Use the FOO || !FOO magic suggested by Hans to ensure a built-in module does
  not try to link against symbols in a module,
* Added a patch to split the VPU and SCP ops into their own source files and
  make the optional build cleaner,
* Control the build of firmware implementations using two new transparent
  Kconfig symbols.

Changes since v1:
* Added Acked-by from Randy.
* Fixed typo in Kconfig description.

Alexandre Courbot (2):
  media: mtk-vcodec: move firmware implementations into their own files
  media: mtk-vcodec: fix build breakage when one of VPU or SCP is
enabled

 drivers/media/platform/Kconfig|  22 ++-
 drivers/media/platform/mtk-vcodec/Makefile|  10 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  |   2 +-
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |   2 +-
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 174 +-
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.h |   7 +-
 .../platform/mtk-vcodec/mtk_vcodec_fw_priv.h  |  52 ++
 .../platform/mtk-vcodec/mtk_vcodec_fw_scp.c   |  73 
 .../platform/mtk-vcodec/mtk_vcodec_fw_vpu.c   | 109 +++
 9 files changed, 274 insertions(+), 177 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_scp.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_vpu.c

--
2.28.0.1011.ga647a8990f-goog

[PATCH v3 2/2] media: mtk-vcodec: fix build breakage when one of VPU or SCP is enabled

The addition of MT8183 support added a dependency on the SCP remoteproc
module. However the initial patch used the "select" Kconfig directive,
which may result in the SCP module to not be compiled if remoteproc was
disabled. In such a case, mtk-vcodec would try to link against
non-existent SCP symbols. "select" was clearly misused here as explained
in kconfig-language.txt.

Replace this by a "depends" directive on at least one of the VPU and
SCP modules, to allow the driver to be compiled as long as one of these
is enabled, and adapt the code to support this new scenario.

Also adapt the Kconfig text to explain the extra requirements for MT8173
and MT8183.

Reported-by: Sakari Ailus 
Signed-off-by: Alexandre Courbot 
Acked-by: Randy Dunlap  # build-tested
Acked-by: Sakari Ailus 
---
 drivers/media/platform/Kconfig| 22 +++
 drivers/media/platform/mtk-vcodec/Makefile| 10 +++--
 .../platform/mtk-vcodec/mtk_vcodec_fw_priv.h  | 18 +++
 3 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index a3cb104956d5..457b6c39ddc0 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -253,18 +253,32 @@ config VIDEO_MEDIATEK_VCODEC
depends on MTK_IOMMU || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on VIDEO_MEDIATEK_VPU || MTK_SCP
+   # The two following lines ensure we have the same state ("m" or "y") as
+   # our dependencies, to avoid missing symbols during link.
+   depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU
+   depends on MTK_SCP || !MTK_SCP
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
-   select VIDEO_MEDIATEK_VPU
-   select MTK_SCP
+   select VIDEO_MEDIATEK_VCODEC_VPU if VIDEO_MEDIATEK_VPU
+   select VIDEO_MEDIATEK_VCODEC_SCP if MTK_SCP
help
Mediatek video codec driver provides HW capability to
-   encode and decode in a range of video formats
-   This driver rely on VPU driver to communicate with VPU.
+   encode and decode in a range of video formats on MT8173
+   and MT8183.
+
+   Note that support for MT8173 requires VIDEO_MEDIATEK_VPU to
+   also be selected. Support for MT8183 depends on MTK_SCP.
 
To compile this driver as modules, choose M here: the
modules will be called mtk-vcodec-dec and mtk-vcodec-enc.
 
+config VIDEO_MEDIATEK_VCODEC_VPU
+   bool
+
+config VIDEO_MEDIATEK_VCODEC_SCP
+   bool
+
 config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index 6e1ea3a9f052..4618d43dbbc8 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -25,5 +25,11 @@ mtk-vcodec-enc-y := venc/venc_vp8_if.o \
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o \
mtk_vcodec_fw.o \
-   mtk_vcodec_fw_vpu.o \
-   mtk_vcodec_fw_scp.o
+
+ifneq ($(CONFIG_VIDEO_MEDIATEK_VCODEC_VPU),)
+mtk-vcodec-common-y += mtk_vcodec_fw_vpu.o
+endif
+
+ifneq ($(CONFIG_VIDEO_MEDIATEK_VCODEC_SCP),)
+mtk-vcodec-common-y += mtk_vcodec_fw_scp.o
+endif
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h
index 51f1694a7c7d..b41e66185cec 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_priv.h
@@ -27,8 +27,26 @@ struct mtk_vcodec_fw_ops {
void (*release)(struct mtk_vcodec_fw *fw);
 };
 
+#if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VCODEC_VPU)
 struct mtk_vcodec_fw *mtk_vcodec_fw_vpu_init(struct mtk_vcodec_dev *dev,
 enum mtk_vcodec_fw_use fw_use);
+#else
+static inline struct mtk_vcodec_fw *
+mtk_vcodec_fw_vpu_init(struct mtk_vcodec_dev *dev,
+  enum mtk_vcodec_fw_use fw_use)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_VIDEO_MEDIATEK_VCODEC_VPU */
+
+#if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VCODEC_SCP)
 struct mtk_vcodec_fw *mtk_vcodec_fw_scp_init(struct mtk_vcodec_dev *dev);
+#else
+static inline struct mtk_vcodec_fw *
+mtk_vcodec_fw_scp_init(struct mtk_vcodec_dev *dev)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_VIDEO_MEDIATEK_VCODEC_SCP */
 
 #endif /* _MTK_VCODEC_FW_PRIV_H_ */
-- 
2.28.0.1011.ga647a8990f-goog

Re: [kbuild-all] Re: drivers/power/supply/mp2629_charger.c:522:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'.

2020-10-11 Thread Rong Chen





On 10/9/20 10:27 PM, Andy Shevchenko wrote:

On Fri, Oct 9, 2020 at 4:23 PM kernel test robot  wrote:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   549738f15da0e5a00275977623be199fbbf7df50
commit: 3bc6d790c39dfc4539c36525e6bcb617abbae467 power: supply: Add support for 
mps mp2629 battery charger
date:   4 months ago
:: branch date: 12 hours ago
:: commit date: 4 months ago
compiler: sh4-linux-gcc (GCC) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

...


3bc6d790c39dfc Saravanan Sekar 2020-05-26  514  unsigned int rval;
3bc6d790c39dfc Saravanan Sekar 2020-05-26  515  int ret;
3bc6d790c39dfc Saravanan Sekar 2020-05-26  516
3bc6d790c39dfc Saravanan Sekar 2020-05-26  517  ret = 
regmap_read(charger->regmap, MP2629_REG_IMPEDANCE_COMP, );
3bc6d790c39dfc Saravanan Sekar 2020-05-26  518  if (ret)
3bc6d790c39dfc Saravanan Sekar 2020-05-26  519  return ret;
3bc6d790c39dfc Saravanan Sekar 2020-05-26  520
3bc6d790c39dfc Saravanan Sekar 2020-05-26  521  rval = (rval >> 4) * 10;
3bc6d790c39dfc Saravanan Sekar 2020-05-26 @522  return sprintf(buf, "%d 
mohm\n", rval);
3bc6d790c39dfc Saravanan Sekar 2020-05-26  523  }

Right, should be %u. Can LKP generate this type of patches?



Hi Andy,

Thanks for the advice, is there a auto correct tool to do such thing?
I afraid we can't cover all the circumstances.

Best Regards,
Rong Chen

Re: [LKP] Re: [hugetlbfs] c0d0381ade: vm-scalability.throughput -33.4% regression

2020-10-11 Thread Xing Zhengjun


Hi Mike,

   I re-test it in v5.9-rc8, the regression still existed. It is almost 
the same as 34ae204f1851. Do you have time to look at it? Thanks.


=
tbox_group/testcase/rootfs/kconfig/compiler/runtime/size/test/cpufreq_governor/ucode:

lkp-knm01/vm-scalability/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/8T/anon-cow-seq-hugetlb/performance/0x11

commit:
  49aef7175cc6eb703a9280a7b830e675fe8f2704
  c0d0381ade79885c04a04c303284b040616b116e
  v5.8
  34ae204f18519f0920bd50a644abd6fefc8dbfcf
  v5.9-rc1
  v5.9-rc8

49aef7175cc6eb70 c0d0381ade79885c04a04c30328v5.8 
34ae204f18519f0920bd50a644av5.9-rc1 
  v5.9-rc8
 --- --- 
--- --- 
---
 %stddev %change %stddev %change 
%stddev %change %stddev %change %stddev 
%change %stddev
 \  |\  |\ 
|\  |\  | 
 \
 38043 ±  3% -30.2%  26560 ±  4% -29.5%  26815 ± 
6%  -7.4%  35209 ±  2%  -7.4%  35244-8.8% 
  34704vm-scalability.median
  7.86 ± 19%  +9.7   17.54 ± 21% +10.4   18.23 ± 
34%  -3.14.75 ±  7%  -4.53.36 ±  7%  -4.0 
3.82 ± 15%  vm-scalability.median_stddev%
  12822071 ±  3% -34.1%8450822 ±  4% -33.6%8517252 ± 
6% -10.7%   11453675 ±  2% -10.2%   11513595 ±  2% -11.6% 
11331657vm-scalability.throughput
 2.523e+09 ±  3% -20.7%  2.001e+09 ±  5% -19.9%  2.021e+09 ± 
7%  +6.8%  2.694e+09 ±  2%  +7.3%  2.707e+09 ±  2%  +5.4% 
2.661e+09vm-scalability.workload



On 8/22/2020 7:36 AM, Mike Kravetz wrote:

On 8/21/20 2:02 PM, Mike Kravetz wrote:

Would you be willing to test this series on top of 34ae204f1851?  I will need
to rebase the series to take the changes made by 34ae204f1851 into account.


Actually, the series in this thread will apply/run cleanly on top of
34ae204f1851.  No need to rebase or port.  If we decide to move forward more
work is required.  See a few FIXME's in the patches.



--
Zhengjun Xing

Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()

2020-10-11 Thread Ira Weiny

On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.we...@intel.com wrote:
> > From: Ira Weiny 
> > 
> > These kmap() calls are localized to a single thread.  To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> > 
> 
> Hi Ira,
> 
> There were a number of options considered.
> 
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
> 
> 
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.

Thanks for the feedback.

I'm going to hold off making any changes until others weigh in.  FWIW, I kind
of like option 2 as well.  But there is already kmap_atomic() so it seemed like
kmap_() was more in line with the current API.

Thanks,
Ira

> 
> Thanks.
> 
> 
> Coly Li
>

[PATCH v2 add prerequisite-patch-id] btrfs: fix devid 0 without a replace item by failing the mount

2020-10-11 Thread Anand Jain

If there is a BTRFS_DEV_REPLACE_DEVID without a replace item, then
it means some device is trying to attack or may be corrupted. Fail the
mount so that the user can remove the attacking or fix the corrupted
device.

As of now if BTRFS_DEV_REPLACE_DEVID is present without the replace
item, in __btrfs_free_extra_devids() we determine that there is an
extra device, and free those extra devices but continue to mount the
device.
However, we were wrong in keeping tack of the rw_devices so the syzbot
testcase failed as below [1].

[1]
WARNING: CPU: 1 PID: 3612 at fs/btrfs/volumes.c:1166 
close_fs_devices.part.0+0x607/0x800 fs/btrfs/volumes.c:1166
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 3612 Comm: syz-executor.2 Not tainted 5.9.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x198/0x1fd lib/dump_stack.c:118
 panic+0x347/0x7c0 kernel/panic.c:231
 __warn.cold+0x20/0x46 kernel/panic.c:600
 report_bug+0x1bd/0x210 lib/bug.c:198
 handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
RIP: 0010:close_fs_devices.part.0+0x607/0x800 fs/btrfs/volumes.c:1166
Code: 0f b6 04 02 84 c0 74 02 7e 33 48 8b 44 24 18 c6 80 30 01 00 00 00 48 83 
c4 30 5b 5d 41 5c 41 5d 41 5e 41 5f c3 e8 99 ce 6a fe <0f> 0b e9 71 ff ff ff e8 
8d ce 6a fe 0f 0b e9 20 ff ff ff e8 d1 d5
RSP: 0018:c900091777e0 EFLAGS: 00010246
RAX: 0004 RBX:  RCX: c9000c8b7000
RDX: 0004 RSI: 83097f47 RDI: 0007
RBP: dc00 R08: 0001 R09: 8880988a187f
R10:  R11: 0001 R12: 88809593a130
R13: 88809593a1ec R14: 8880988a1908 R15: 88809593a050
 close_fs_devices fs/btrfs/volumes.c:1193 [inline]
 btrfs_close_devices+0x95/0x1f0 fs/btrfs/volumes.c:1179
 open_ctree+0x4984/0x4a2d fs/btrfs/disk-io.c:3434
 btrfs_fill_super fs/btrfs/super.c:1316 [inline]
 btrfs_mount_root.cold+0x14/0x165 fs/btrfs/super.c:1672

The fix here is, when we determine that there isn't a replace item
then fail the mount if there is a replace target device (devid 0).

Reported-by: syzbot+4cfe71a4da060be47...@syzkaller.appspotmail.com
Signed-off-by: Anand Jain 
---
Depends on the patches
 btrfs: drop never met condition of disk_total_bytes == 0
 btrfs: fix btrfs_find_device unused arg seed
If these patches aren't integrated yet, then please add the last arg in
the function btrfs_find_device(). Any value is fine as it doesn't care.

fstest case will follow.

v2: changed title
old: btrfs: fix rw_devices count in __btrfs_free_extra_devids

In btrfs_init_dev_replace() try to match the presence of replace_item
to the BTRFS_DEV_REPLACE_DEVID device. If fails then fail the
mount. So drop the similar check in __btrfs_free_extra_devids().

 fs/btrfs/dev-replace.c | 26 --
 fs/btrfs/volumes.c | 26 +++---
 2 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 9340d03661cd..e2b7ae386224 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -91,6 +91,17 @@ int btrfs_init_dev_replace(struct btrfs_fs_info *fs_info)
ret = btrfs_search_slot(NULL, dev_root, , path, 0, 0);
if (ret) {
 no_valid_dev_replace_entry_found:
+   /*
+* We don't have a replace item or it's corrupted.
+* If there is a replace target, fail the mount.
+*/
+   if (btrfs_find_device(fs_info->fs_devices,
+ BTRFS_DEV_REPLACE_DEVID, NULL, NULL)) {
+   btrfs_err(fs_info,
+   "found replace target device without a replace item");
+   ret = -EIO;
+   goto out;
+   }
ret = 0;
dev_replace->replace_state =
BTRFS_IOCTL_DEV_REPLACE_STATE_NEVER_STARTED;
@@ -143,8 +154,19 @@ int btrfs_init_dev_replace(struct btrfs_fs_info *fs_info)
case BTRFS_IOCTL_DEV_REPLACE_STATE_NEVER_STARTED:
case BTRFS_IOCTL_DEV_REPLACE_STATE_FINISHED:
case BTRFS_IOCTL_DEV_REPLACE_STATE_CANCELED:
-   dev_replace->srcdev = NULL;
-   dev_replace->tgtdev = NULL;
+   /*
+* We don't have an active replace item but if there is a
+* replace target, fail the mount.
+*/
+   if (btrfs_find_device(fs_info->fs_devices,
+ BTRFS_DEV_REPLACE_DEVID, NULL, NULL)) {
+   btrfs_err(fs_info,
+   "replace devid present without an active replace item");
+   ret = -EIO;
+   } else {
+

Re: [PATCH 2/2] Arm: dts: aspeed-g6: Add sgpio node and pinctrl setting

Hi Joel,

On 2020/10/8, 11:49 AM, Joel Stanley wrote:

On Thu, 8 Oct 2020 at 01:51, Billy Tsai  wrote:
> >
> > This patch is used to add sgpiom and sgpios nodes and add pinctrl 
setting
> > for sgpiom1
> 
> The code looks good Billy.
> 
> Please split the change in two: device tree changes (arch/arm/dts) in
> one, and pinctrl in the second, as they go through different
> maintainers.
> 

If I split the change in two, the patch of dts will have a compiler error.
Because that the sgpiom1 node needs the pinctrl symbol 
"_sgpm2_default".

> You also need to update the device tree bindings in Documentation with
> the new compatible strings:
> 
>  Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> 
> That should go in it's own patch too.
> 
> > --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> > +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> > @@ -366,6 +366,58 @@
> > #interrupt-cells = <2>;
> > };
> >
> > +   sgpiom0: sgpiom@1e780500 {
> > +   #gpio-cells = <2>;
> > +   gpio-controller;
> > +   compatible = "aspeed,ast2600-sgpiom";
> 
> This is interesting. I didn't realise the sgpio driver we have in the
> mainline kernel tree (drivers/gpio/gpio-aspeed-sgpio.c) is for the
> sgpio master device. It might be best to update the naming of the
> ast2400/ast2500 compatible in the future.
> 
> > +   reg = <0x1e780500 0x100>;
> > +   interrupts = ;
> > +   ngpios = <128>;
> > +   clocks = < ASPEED_CLK_APB2>;
> > +   interrupt-controller;
> > +   bus-frequency = <1200>;
> > +
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_sgpm1_default>;
> > +   status = "disabled";
> > +   };
> 
> > gpio1: gpio@1e780800 {
> > #gpio-cells = <2>;
> > gpio-controller;
> > @@ -377,6 +429,7 @@
> > clocks = < ASPEED_CLK_APB1>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > +   status = "disabled";
> 
> This should be in a different patch set, as it will break all of the
> systems that expect GPIO to be enabled (which is all of them).
> 
> Considering all of them expect this gpio bank to be enabled, should we
> leave it enabled here?
> 
> 
> > };
> >
> > rtc: rtc@1e781000 {
> > diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> > index 34803a6c7664..b673a44ffa3b 100644
> > --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> > +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> > @@ -46,8 +46,10 @@
> >  #define SCU620 0x620 /* Disable GPIO Internal Pull-Down #4 */
> >  #define SCU634 0x634 /* Disable GPIO Internal Pull-Down #5 */
> >  #define SCU638 0x638 /* Disable GPIO Internal Pull-Down #6 */
> > +#define SCU690 0x690 /* Multi-function Pin Control #24 */
> >  #define SCU694 0x694 /* Multi-function Pin Control #25 */
> >  #define SCU69C 0x69C /* Multi-function Pin Control #27 */
> > +#define SCU6D0 0x6D0 /* Multi-function Pin Control #28 */
> >  #define SCUC20 0xC20 /* PCIE configuration Setting Control */
> >
> >  #define ASPEED_G6_NR_PINS 256
> > @@ -81,13 +83,21 @@ FUNC_GROUP_DECL(I2C12, L26, K24);
> >  #define K26 4
> >  SIG_EXPR_LIST_DECL_SESG(K26, MACLINK1, MACLINK1, SIG_DESC_SET(SCU410, 
4));
> >  SIG_EXPR_LIST_DECL_SESG(K26, SCL13, I2C13, SIG_DESC_SET(SCU4B0, 4));
> > -PIN_DECL_2(K26, GPIOA4, MACLINK1, SCL13);
> > +/*SGPM2 is A1 Only */
> > +SIG_EXPR_LIST_DECL_SESG(K26, SGPM2CLK, SGPM2, SIG_DESC_SET(SCU6D0, 4),
> > + SIG_DESC_CLEAR(SCU410, 4), 
SIG_DESC_CLEAR(SCU4B0, 4),
> > + SIG_DESC_CLEAR(SCU690, 4));
> > +PIN_DECL_3(K26, GPIOA4, SGPM2CLK, MACLINK1, SCL13);
> >  FUNC_GROUP_DECL(MACLINK1, K26);
> >
> >  #define L24 5
> >  SIG_EXPR_LIST_DECL_SESG(L24, MACLINK2, MACLINK2, SIG_DESC_SET(SCU410, 
5));
> >  SIG_EXPR_LIST_DECL_SESG(L24, SDA13, I2C13, SIG_DESC_SET(SCU4B0, 5));
> > -PIN_DECL_2(L24, GPIOA5, MACLINK2, SDA13);
> > +/*SGPM2 is A1 Only */
> > +SIG_EXPR_LIST_DECL_SESG(L24,

Re: [PATCH v2 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq

2020-10-11 Thread Viresh Kumar

On 08-10-20, 18:31, Sumit Gupta wrote:
> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
> and keeps changing slightly. This change returns a consistent value
> from freq_table. If the reconstructed frequency has acceptable delta
> from the last written value, then return the frequency corresponding
> to the last written ndiv value from freq_table. Otherwise, print a
> warning and return the reconstructed freq.
> 
> Signed-off-by: Sumit Gupta 
> ---
>  drivers/cpufreq/tegra194-cpufreq.c | 71 
> +-
>  1 file changed, 62 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra194-cpufreq.c 
> b/drivers/cpufreq/tegra194-cpufreq.c
> index e1d931c..d250e49 100644
> --- a/drivers/cpufreq/tegra194-cpufreq.c
> +++ b/drivers/cpufreq/tegra194-cpufreq.c
> @@ -180,9 +180,70 @@ static unsigned int tegra194_get_speed_common(u32 cpu, 
> u32 delay)
>   return (rate_mhz * KHZ); /* in KHz */
>  }
>  
> +static void get_cpu_ndiv(void *ndiv)
> +{
> + u64 ndiv_val;
> +
> + asm volatile("mrs %0, s3_0_c15_c0_4" : "=r" (ndiv_val) : );
> +
> + *(u64 *)ndiv = ndiv_val;
> +}
> +
> +static void set_cpu_ndiv(void *data)

You weren't required to do this unnecessary change.

> +{
> + struct cpufreq_frequency_table *tbl = data;
> + u64 ndiv_val = (u64)tbl->driver_data;
> +
> + asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
> +}
> +
>  static unsigned int tegra194_get_speed(u32 cpu)
>  {
> - return tegra194_get_speed_common(cpu, US_DELAY);
> + struct tegra194_cpufreq_data *data = cpufreq_get_driver_data();
> + struct cpufreq_frequency_table *pos;
> + unsigned int rate;
> + u64 ndiv;
> + int ret;
> + u32 cl;
> +
> + if (!cpu_online(cpu))

This isn't required. The CPU is guaranteed to be online here.

> + return -EINVAL;
> +
> + smp_call_function_single(cpu, get_cpu_cluster, , true);
> +
> + if (cl >= data->num_clusters)

Is it really possible here ? I meant you must have already checked
this at cpufreq-init level already. Else mark it unlikely at least.

> + return -EINVAL;
> +
> + /* reconstruct actual cpu freq using counters */
> + rate = tegra194_get_speed_common(cpu, US_DELAY);
> +
> + /* get last written ndiv value */
> + ret = smp_call_function_single(cpu, get_cpu_ndiv, , true);
> + if (ret) {

What exactly can fail here ? get_cpu_ndiv() can't fail. Do we really
need this check ? What about WARN_ON_ONCE() ?

> + pr_err("cpufreq: Failed to get ndiv for CPU%d, ret:%d\n",
> +cpu, ret);
> + return rate;
> + }
> +
> + /*
> +  * If the reconstructed frequency has acceptable delta from
> +  * the last written value, then return freq corresponding
> +  * to the last written ndiv value from freq_table. This is
> +  * done to return consistent value.
> +  */
> + cpufreq_for_each_valid_entry(pos, data->tables[cl]) {
> + if (pos->driver_data != ndiv)
> + continue;
> +
> + if (abs(pos->frequency - rate) > 115200) {

where does this 115200 comes from ? Strange that it matches tty's baud
rate :)

This is 115 MHz, right ? Isn't that too big of a delta ?

> + pr_warn("cpufreq: cpu%d,cur:%u,set:%u,set ndiv:%llu\n",
> + cpu, rate, pos->frequency, ndiv);
> + } else {
> + rate = pos->frequency;
> + }
> + break;
> + }
> + return rate;
>  }

-- 
viresh

linux-next: manual merge of the irqchip tree with the mfd tree

Hi all,

Today's linux-next merge of the irqchip tree got a conflict in:

  drivers/irqchip/Makefile

between commit:

  03ac990e0ac0 ("irqchip: Add sl28cpld interrupt controller support")

from the mfd tree and commit:

  ad4c938c92af ("irqchip/irq-mst: Add MStar interrupt controller support")

from the irqchip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/irqchip/Makefile
index db5e37d2db11,f1525149b7a2..
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@@ -110,4 -113,4 +112,5 @@@ obj-$(CONFIG_LOONGSON_HTPIC)   += 
irq-lo
  obj-$(CONFIG_LOONGSON_HTVEC)  += irq-loongson-htvec.o
  obj-$(CONFIG_LOONGSON_PCH_PIC)+= irq-loongson-pch-pic.o
  obj-$(CONFIG_LOONGSON_PCH_MSI)+= irq-loongson-pch-msi.o
 +obj-$(CONFIG_SL28CPLD_INTC)   += irq-sl28cpld.o
+ obj-$(CONFIG_MST_IRQ) += irq-mst-intc.o


pgp1vPBa2ym8n.pgp
Description: OpenPGP digital signature

Re: [PATCH RESEND 1/1] perf build: Allow nested externs to enable BUILD_BUG() usage

Hi all,

On Mon, 12 Oct 2020 08:59:36 +1100 Stephen Rothwell  
wrote:
>
> On Fri, 9 Oct 2020 14:41:11 +0200 Jiri Olsa  wrote:
> >
> > On Fri, Oct 09, 2020 at 02:25:23PM +0200, Vasily Gorbik wrote:  
> > > Currently BUILD_BUG() macro is expanded to smth like the following:
> > >do {
> > >extern void __compiletime_assert_0(void)
> > >__attribute__((error("BUILD_BUG failed")));
> > >if (!(!(1)))
> > >__compiletime_assert_0();
> > >} while (0);
> > > 
> > > If used in a function body this obviously would produce build errors
> > > with -Wnested-externs and -Werror.
> > > 
> > > To enable BUILD_BUG() usage in tools/arch/x86/lib/insn.c which perf
> > > includes in intel-pt-decoder, build perf without -Wnested-externs.
> > > 
> > > Reported-by: Stephen Rothwell 
> > > Signed-off-by: Vasily Gorbik 
> > 
> > that one applied nicely ;-) thanks
> > 
> > Acked-by: Jiri Olsa   
> 
> I will apply that patch to the merge of the tip tree today (instead of
> reverting the series I reverted in Friday) (unless I get an update of
> the tip tree containing it, of course).

Tested-by: Stephen Rothwell  # build tested

-- 
Cheers,
Stephen Rothwell


pgpjfEKz89xom.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 1/1] PCI/ERR: Fix reset logic in pcie_do_recovery() call

2020-10-11 Thread Kuppuswamy, Sathyanarayanan


Hi Sinan,

On 9/28/20 11:32 AM, Kuppuswamy, Sathyanarayanan wrote:



On 9/28/20 11:25 AM, Sinan Kaya wrote:

On 9/28/2020 2:02 PM, Sinan Kaya wrote:

Since there is no state restoration for FATAL errors, I am wondering
whether
calls to ->error_detected(), ->mmio_enabled() and ->slot_reset() are
required?


I also would like to ask someone closer to the spec language double
check this.

When we recover the link at the end of the DPC handler, what is the
expected state of the endpoint?

Is it a some kind of a reset like secondary bus reset? (I assumed this
  one)

I think it will be in reset state.


Undefined?

or just plain link recovery with everything else as intact as it used
to be?





Please check the following version. It should fix most of the reset issues
properly.

https://lore.kernel.org/linux-pci/5c5bca0bdb958e456176fe6ede10ba8f838fbafc.1602263264.git.sathyanarayanan.kuppusw...@linux.intel.com/T/#t

--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

[PATCH v4 1/2] PCI/ERR: Call pci_bus_reset() before calling ->slot_reset() callback

2020-10-11 Thread sathyanarayanan . nkuppuswamy

From: Kuppuswamy Sathyanarayanan 

Currently if report_error_detected() or report_mmio_enabled()
functions requests PCI_ERS_RESULT_NEED_RESET, current
pcie_do_recovery() implementation does not do the requested
explicit device reset, but instead just calls the
report_slot_reset() on all affected devices. Notifying about the
reset via report_slot_reset() without doing the actual device
reset is incorrect. So call pci_bus_reset() before triggering
->slot_reset() callback.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/pci/pcie/err.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index c543f419d8f9..067c58728b88 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -181,11 +181,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
}
 
if (status == PCI_ERS_RESULT_NEED_RESET) {
-   /*
-* TODO: Should call platform-specific
-* functions to reset slot before calling
-* drivers' slot_reset callbacks?
-*/
+   pci_reset_bus(dev);
status = PCI_ERS_RESULT_RECOVERED;
pci_dbg(dev, "broadcast slot_reset message\n");
pci_walk_bus(bus, report_slot_reset, );
-- 
2.17.1

[PATCH v4 2/2] PCI/ERR: Split the fatal and non-fatal error recovery handling

2020-10-11 Thread sathyanarayanan . nkuppuswamy

From: Kuppuswamy Sathyanarayanan 

Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
merged fatal and non-fatal error recovery paths, and also made
recovery code depend on hotplug handler for "remove affected
device + rescan" support. But this change also complicated the
error recovery path and which in turn led to the following
issues.

1. We depend on hotplug handler for removing the affected
devices/drivers on DLLSC LINK down event (on DPC event
trigger) and DPC handler for handling the error recovery. Since
both handlers operate on same set of affected devices, it leads
to race condition, which in turn leads to  NULL pointer
exceptions or error recovery failures.You can find more details
about this issue in following link.

https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.z...@intel.com/T/#t

2. For non-hotplug capable devices fatal (DPC) error recovery
is currently broken. Current fatal error recovery implementation
relies on PCIe hotplug (pciehp) handler for detaching and
re-enumerating the affected devices/drivers. So when dealing with
non-hotplug capable devices, recovery code does not restore the state
of the affected devices correctly. You can find more details about
this issue in the following links.

https://lore.kernel.org/linux-pci/20200527083130.4137-1-zhiqiang@nxp.com/
https://lore.kernel.org/linux-pci/12115.1588207324@famine/
https://lore.kernel.org/linux-pci/0e6f89cd6b9e4a72293cc90fafe93487d7c2d295.158584.git.sathyanarayanan.kuppusw...@linux.intel.com/

In order to fix the above two issues, we should stop relying on hotplug
handler for cleaning the affected devices/drivers and let error recovery
handler own this functionality. So this patch reverts Commit bdb5ac85777d
("PCI/ERR: Handle fatal error recovery") and re-introduce the  "remove
affected device + rescan"  functionality in fatal error recovery handler.

Also holding pci_lock_rescan_remove() will prevent the race between hotplug
and DPC handler.

Fixes: bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 Documentation/PCI/pci-error-recovery.rst | 47 ++--
 drivers/pci/pcie/err.c   | 71 +++-
 2 files changed, 87 insertions(+), 31 deletions(-)

diff --git a/Documentation/PCI/pci-error-recovery.rst 
b/Documentation/PCI/pci-error-recovery.rst
index 84ceebb08cac..830c8af5838b 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -115,7 +115,7 @@ The actual steps taken by a platform to recover from a PCI 
error
 event will be platform-dependent, but will follow the general
 sequence described below.
 
-STEP 0: Error Event
+STEP 0: Error Event: ERR_NONFATAL
 ---
 A PCI bus error is detected by the PCI hardware.  On powerpc, the slot
 is isolated, in that all I/O is blocked: all reads return 0x,
@@ -160,10 +160,10 @@ particular, if the platform doesn't isolate slots), and 
recovery
 proceeds to STEP 2 (MMIO Enable).
 
 If any driver requested a slot reset (by returning PCI_ERS_RESULT_NEED_RESET),
-then recovery proceeds to STEP 4 (Slot Reset).
+then recovery proceeds to STEP 3 (Slot Reset).
 
 If the platform is unable to recover the slot, the next step
-is STEP 6 (Permanent Failure).
+is STEP 5 (Permanent Failure).
 
 .. note::
 
@@ -198,7 +198,7 @@ reset or some such, but not restart operations. This 
callback is made if
 all drivers on a segment agree that they can try to recover and if no automatic
 link reset was performed by the HW. If the platform can't just re-enable IOs
 without a slot reset or a link reset, it will not call this callback, and
-instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
+instead will have gone directly to STEP 3 (Slot Reset)
 
 .. note::
 
@@ -233,18 +233,12 @@ The driver should return one of the following result 
codes:
 
 The next step taken depends on the results returned by the drivers.
 If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
-proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
+proceeds to STEP 4 (Resume Operations).
 
 If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
-proceeds to STEP 4 (Slot Reset)
+proceeds to STEP 3 (Slot Reset)
 
-STEP 3: Link Reset
---
-The platform resets the link.  This is a PCI-Express specific step
-and is done whenever a fatal error has been detected that can be
-"solved" by resetting the link.
-
-STEP 4: Slot Reset
+STEP 3: Slot Reset
 --
 
 In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
@@ -322,7 +316,7 @@ PCI card types::
+   pdev->needs_freset = 1;
+
 
-Platform proceeds either to STEP 5 (Resume Operations) or STEP 6 (Permanent
+Platform proceeds either to STEP 4 (Resume Operations) or STEP 5 (Permanent
 Failure).
 
 .. note::
@@ -332,7 +326,7 @@ Failure).
However, it probably should.

Re: [PATCH] perf inject: Flush ordered events on FINISHED_ROUND

2020-10-11 Thread Namhyung Kim

Hi Jiri,

On Thu, Oct 8, 2020 at 6:07 PM Jiri Olsa  wrote:
>
> On Tue, Oct 06, 2020 at 02:40:32PM +0900, namhy...@kernel.org wrote:
> > This is the perf stat result:
> >
> > * Before
> >
> >  7,167,414,019  L1-dcache-loads
> >337,471,761  L1-dcache-read-misses #4.71% of all 
> > L1-dcache hits
> >
> >   11.011224671 seconds time elapsed
> >
> >
> > * After
> >
> >  7,075,556,792  L1-dcache-loads
> >771,810,388  L1-dcache-read-misses #   10.91% of all 
> > L1-dcache hits
> >
> >   17.015901863 seconds time elapsed
> >
> >
> > Hmm.. it's a memory & time trade-off then.  Maybe we need a switch to
> > select which one?
>
> I'd keep the faster one ;-) so the one before

Yeah, it's hard to argue when it slows things down much.
But I'd like to note that memory consumption also can be a
big issue in some environments.  I'll bring this back later..

Thanks
Namhyung

[PATCH] perf vendor events: Fix typos in power8 PMU events

2020-10-11 Thread Sandipan Das

This replaces the incorrectly spelled word "localtion"
with "location" in some power8 PMU event descriptions.

Fixes: 2a81fa3bb5ed ("perf vendor events: Add power8 PMU events")
Signed-off-by: Sandipan Das 
---
 .../pmu-events/arch/powerpc/power8/cache.json| 10 +-
 .../pmu-events/arch/powerpc/power8/frontend.json | 12 ++--
 .../pmu-events/arch/powerpc/power8/marked.json   | 10 +-
 .../pmu-events/arch/powerpc/power8/other.json| 16 
 .../arch/powerpc/power8/translation.json |  2 +-
 5 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/cache.json 
b/tools/perf/pmu-events/arch/powerpc/power8/cache.json
index 6b792b2c87e2..05a17084d939 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/cache.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/cache.json
@@ -32,8 +32,8 @@
   {
 "EventCode": "0x1c04e",
 "EventName": "PM_DATA_FROM_L2MISS_MOD",
-"BriefDescription": "The processor's data cache was reloaded from a 
localtion other than the local core's L2 due to a demand load",
-"PublicDescription": "The processor's data cache was reloaded from a 
localtion other than the local core's L2 due to either only demand loads or 
demand loads plus prefetches if MMCR1[16] is 1"
+"BriefDescription": "The processor's data cache was reloaded from a 
location other than the local core's L2 due to a demand load",
+"PublicDescription": "The processor's data cache was reloaded from a 
location other than the local core's L2 due to either only demand loads or 
demand loads plus prefetches if MMCR1[16] is 1"
   },
   {
 "EventCode": "0x3c040",
@@ -74,8 +74,8 @@
   {
 "EventCode": "0x4c04e",
 "EventName": "PM_DATA_FROM_L3MISS_MOD",
-"BriefDescription": "The processor's data cache was reloaded from a 
localtion other than the local core's L3 due to a demand load",
-"PublicDescription": "The processor's data cache was reloaded from a 
localtion other than the local core's L3 due to either only demand loads or 
demand loads plus prefetches if MMCR1[16] is 1"
+"BriefDescription": "The processor's data cache was reloaded from a 
location other than the local core's L3 due to a demand load",
+"PublicDescription": "The processor's data cache was reloaded from a 
location other than the local core's L3 due to either only demand loads or 
demand loads plus prefetches if MMCR1[16] is 1"
   },
   {
 "EventCode": "0x3c042",
@@ -134,7 +134,7 @@
   {
 "EventCode": "0x4e04e",
 "EventName": "PM_DPTEG_FROM_L3MISS",
-"BriefDescription": "A Page Table Entry was loaded into the TLB from a 
localtion other than the local core's L3 due to a data side request",
+"BriefDescription": "A Page Table Entry was loaded into the TLB from a 
location other than the local core's L3 due to a data side request",
 "PublicDescription": ""
   },
   {
diff --git a/tools/perf/pmu-events/arch/powerpc/power8/frontend.json 
b/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
index 1ddc30655d43..1c902a8263b6 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/frontend.json
@@ -116,8 +116,8 @@
   {
 "EventCode": "0x1404e",
 "EventName": "PM_INST_FROM_L2MISS",
-"BriefDescription": "The processor's Instruction cache was reloaded from a 
localtion other than the local core's L2 due to an instruction fetch (not 
prefetch)",
-"PublicDescription": "The processor's Instruction cache was reloaded from 
a localtion other than the local core's L2 due to either an instruction fetch 
or instruction fetch plus prefetch if MMCR1[17] is 1"
+"BriefDescription": "The processor's Instruction cache was reloaded from a 
location other than the local core's L2 due to an instruction fetch (not 
prefetch)",
+"PublicDescription": "The processor's Instruction cache was reloaded from 
a location other than the local core's L2 due to either an instruction fetch or 
instruction fetch plus prefetch if MMCR1[17] is 1"
   },
   {
 "EventCode": "0x34040",
@@ -158,8 +158,8 @@
   {
 "EventCode": "0x4404e",
 "EventName": "PM_INST_FROM_L3MISS_MOD",
-"BriefDescription": "The processor's Instruction cache was reloaded from a 
localtion other than the local core's L3 due to a instruction fetch",
-"PublicDescription": "The processor's Instruction cache was reloaded from 
a localtion other than the local core's L3 due to either an instruction fetch 
or instruction fetch plus prefetch if MMCR1[17] is 1"
+"BriefDescription": "The processor's Instruction cache was reloaded from a 
location other than the local core's L3 due to a instruction fetch",
+"PublicDescription": "The processor's Instruction cache was reloaded from 
a location other than the local core's L3 due to either an instruction fetch or 
instruction fetch plus prefetch if MMCR1[17] is 1"
   },
   {
 "EventCode": "0x34042",
@@ -320,7 +320,7 @@

Re: LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces

2020-10-11 Thread Eric W. Biederman

Andy Lutomirski  writes:

> On Sun, Oct 11, 2020 at 1:53 PM Josh Triplett  wrote:
>>
>> On Fri, Oct 09, 2020 at 11:26:06PM -0500, Serge E. Hallyn wrote:
>> > > 3. Find a way to allow setgroups() in a user namespace while keeping
>> > >in mind the case of groups used for negative access control.
>> > >This was suggested by Josh Triplett and Geoffrey Thomas. Their idea 
>> > > was to
>> > >investigate adding a prctl() to allow setgroups() to be called in a 
>> > > user
>> > >namespace at the cost of restricting paths to the most restrictive
>> > >permission. So if something is 0707 it needs to be treated as if it's 
>> > > 
>> > >even though the caller is not in its owning group which is used for 
>> > > negative
>> > >access control (how these new semantics will interact with ACLs will 
>> > > also
>> > >need to be looked into).
>> >
>> > I should probably think this through more, but for this problem, would it
>> > not suffice to add a new prevgroups grouplist to the struct cred, maybe
>> > struct group_info *locked_groups, and every time an unprivileged task 
>> > creates
>> > a new user namespace, add all its current groups to this list?
>>
>> So, effectively, you would be allowed to drop permissions, but
>> locked_groups would still be checked for restrictions?
>>
>> That seems like it'd introduce a new level of complexity (a new facet of
>> permission) to manage. Not opposed, but it does seem more complex than
>> just opting out of using groups for negative permissions.
>
> Is there any context other than regular UNIX DAC in which groups can
> act as negative permissions or is this literally just an issue for
> files with a more restrictive group mode than other mode?

Just that.

The ideas kicked around in the conversation were some variant of having
a sysctl that says "This system never uses groups for negative
permissions".

It was also suggested that if the sysctl was set the the permission
checks would be altered such that even if someone tried to set a
negative permission, the more liberal permissions of other would be used
instead.

Given that creating /etc/subgid is effectively opting out of negative
permissions already have a sysctl that says that upfront feels like a
very clean solution.

Eric

[PATCH] f2fs: fix writecount false positive in releasing compress blocks

2020-10-11 Thread Daeho Jeong

From: Daeho Jeong 

In current condition check, if it detects writecount, it return -EBUSY
regardless of f_mode of the file. Fixed it.

Signed-off-by: Daeho Jeong 
---
 fs/f2fs/file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 0a958eef3d1f..ef5a844de53f 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3509,7 +3509,8 @@ static int f2fs_release_compress_blocks(struct file 
*filp, unsigned long arg)
inode_lock(inode);
 
writecount = atomic_read(>i_writecount);
-   if ((filp->f_mode & FMODE_WRITE && writecount != 1) || writecount) {
+   if ((filp->f_mode & FMODE_WRITE && writecount != 1) ||
+   (!(filp->f_mode & FMODE_WRITE) && writecount)) {
ret = -EBUSY;
goto out;
}
-- 
2.28.0.1011.ga647a8990f-goog

Re: [PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled

Hi Mauro,

On Fri, Oct 9, 2020 at 3:34 PM Mauro Carvalho Chehab
 wrote:
>
> Em Fri, 9 Oct 2020 13:30:06 +0900
> Alexandre Courbot  escreveu:
>
> > On Fri, Oct 9, 2020 at 1:13 AM Hans Verkuil  
> > wrote:
>
> > > >>> If VIDEO_MEDIATEK_VPU=y and MTK_SCP=m, then VIDEO_MEDIATEK_VCODEC can 
> > > >>> be configured
> > > >>> to y, and then it won't be able to find the scp_ functions.
> > > >>>
> > > >>> To be honest, I'm not sure how to solve this.
> > > >>
> > > >> Found it. Add this:
> > > >>
> > > >> depends on MTK_SCP || !MTK_SCP
> > > >> depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU
> > > >>
> > > >> Ugly as hell, but it appears to be the correct incantation for this.
>
> While the above does the job, I'm wondering if the better wouldn't
> be to have this spit into 3 config dependencies. E. g. something like:
>
> config VIDEO_MEDIATEK_CODEC
> depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU
>
> config VIDEO_MEDIATEK_VPU
> depends on VIDEO_DEV && VIDEO_V4L2
> depends on ARCH_MEDIATEK || COMPILE_TEST
> tristate "support for Mediatek Video Processor Unit without SCP"
> help
> ...
>
> config VIDEO_MEDIATEK_VPU_SCP
> depends on VIDEO_DEV && VIDEO_V4L2
> depends on ARCH_MEDIATEK || COMPILE_TEST
> tristate "support for Mediatek Video Processor Unit with SCP"
> help
> ...

Doing so would introduce two extra choices to enable the driver, so
I'm a bit concerned this may be a bit confusing?

Also I have experimented with this, and it appears that
VIDEO_MEDIATEK_CODEC won't be automatically enabled if one of the new
options is selected. So this means that after setting e.g.
VIDEO_MEDIATEK_VPU_SCP, one still needs to manually enable
VIDEO_MEDIATEK_CODEC otherwise the driver won't be compiled at all.

>
> And split the board-specific data for each variant on separate files,
> doing something like this at the Makefile:
>
> obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
>mtk-vcodec-enc.o \
>mtk-vcodec-common.o
>
> ifneq ($(VIDEO_MEDIATEK_VPU_SCP),)
> obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-fw-scp.o
> endif
>
> ifneq ($(VIDEO_MEDIATEK_VPU),)
> obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-fw-vpu.o
> endif
>
> This will avoid the ugly ifdefs in the middle of mtk_vcodec_fw.c,
> and the ugly "depends on FOO || !FOO" usage.
>
> It should also be simpler to add future variants of it in the
> future, if needed.

Indeed, the split makes sense regardless of the selection mechanism
adopted. I will try to do it in the next revision.

[PATCH rdma-rc 0/3] Fixes to coming PR

2020-10-11 Thread Leon Romanovsky

From: Leon Romanovsky 

Leon Romanovsky (2):
  RDMA/core: Postpone uobject cleanup on failure till FD close
  RDMA/core: Make FD destroy callback void

Maor Gottlieb (1):
  RDMA/ucma: Fix use after free in destroy id flow

 drivers/infiniband/core/rdma_core.c   | 45 ---
 drivers/infiniband/core/ucma.c| 11 ++---
 drivers/infiniband/core/uverbs_cmd.c  |  5 +--
 drivers/infiniband/core/uverbs_std_types.c| 18 +++-
 .../core/uverbs_std_types_async_fd.c  |  5 +--
 .../core/uverbs_std_types_counters.c  |  5 +--
 drivers/infiniband/core/uverbs_std_types_cq.c |  4 +-
 drivers/infiniband/core/uverbs_std_types_dm.c |  6 +--
 .../core/uverbs_std_types_flow_action.c   |  6 +--
 drivers/infiniband/core/uverbs_std_types_qp.c |  4 +-
 .../infiniband/core/uverbs_std_types_srq.c|  4 +-
 drivers/infiniband/core/uverbs_std_types_wq.c |  4 +-
 drivers/infiniband/hw/mlx5/devx.c | 14 +++---
 drivers/infiniband/hw/mlx5/fs.c   |  6 +--
 include/rdma/ib_verbs.h   | 42 -
 include/rdma/uverbs_types.h   |  4 +-
 16 files changed, 59 insertions(+), 124 deletions(-)

--
2.26.2

Re: [PATCH 2/3] Arm: dts: aspeed-g6: Add sgpio node

Hi Joel,

Thanks for the review.

On 2020/10/12, 12:35 PM, Joel Stanley wrote:

> On Mon, 12 Oct 2020 at 03:32, Billy Tsai  
wrote:
> >
> > This patch is used to add sgpiom and sgpios nodes and add compatible
> > string for sgpiom.
> 
> You also need to add sgpios documentation to the bindings docs.
> 
> Whenever you add new device tree bindings to the kernel tree you
> should add documentation for them.
> 
> When preparing patches for submission, use scripts/checkpatch.pl to
> check for common issues. It will warn you if you are adding strings
> that are not documented.
> 
> Cheers,
> 
> Joel
> 
   Because the driver of sgpios doesn't be implemented, so I don't know how to 
describe it at sgpio-aspeed.txt. 
   Can I just add  compatible string " aspeed,ast2600-sgpios " to the document 
for bypassing the warning of checkpatch?
> >
> > Signed-off-by: Billy Tsai 
> > ---
> >  .../devicetree/bindings/gpio/sgpio-aspeed.txt |  8 +--
> >  arch/arm/boot/dts/aspeed-g6.dtsi  | 52 +++
> >  2 files changed, 57 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt 
b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > index d4d83916c09d..815d9b5167a5 100644
> > --- a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > @@ -1,8 +1,10 @@
> >  Aspeed SGPIO controller Device Tree Bindings
> >  
> >
> > -This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 
full
> > -featured Serial GPIOs. Each of the Serial GPIO pins can be programmed 
to
> > +This SGPIO controller is for ASPEED AST2500/AST2600 SoC, it supports 2 
master.
> > +One is up to 128 SGPIO input ports and 128 output ports 
concurrently(after AST2600A1)
> > +and Second one is up to 80.
> > +Each of the Serial GPIO pins can be programmed to
> >  support the following options:
> >  - Support interrupt option for each input port and various interrupt
> >sensitivity option (level-high, level-low, edge-high, edge-low)
> > @@ -14,7 +16,7 @@ support the following options:
> >  Required properties:
> >
> >  - compatible : Should be one of
> > -  "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio"
> > +  "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio", 
"aspeed,ast2600-sgpiom"
> 
> I think we should add sgpiom strings for the ast2500 (and ast2400?)
> too, as this is how they should have been named in the first place:
> 
   If I change the document whether I also need to send the patch for sgpio 
driver and g5/g4.dtsi?
> >  - compatible : Should be one of
> >"aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio"
> >   "aspeed,ast2400-sgpiom", "aspeed,ast2500-sgpiom", 
"aspeed,ast2600-sgpiom"
> 
> 
> >  - #gpio-cells : Should be 2, see gpio.txt
> >  - reg : Address and length of the register set for the device
> >  - gpio-controller : Marks the device node as a GPIO controller
> > diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi 
b/arch/arm/boot/dts/aspeed-g6.dtsi
> > index ad19dce038ea..cb053a996e87 100644
> > --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> > +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> > @@ -366,6 +366,58 @@
> > #interrupt-cells = <2>;
> > };
> >
> > +   sgpiom0: sgpiom@1e780500 {
> > +   #gpio-cells = <2>;
> > +   gpio-controller;
> > +   compatible = "aspeed,ast2600-sgpiom";
> > +   reg = <0x1e780500 0x100>;
> > +   interrupts = ;
> > +   ngpios = <128>;
> > +   clocks = < ASPEED_CLK_APB2>;
> > +   interrupt-controller;
> > +   bus-frequency = <1200>;
> > +
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_sgpm1_default>;
> > +   status = "disabled";
> > +   };
> > +
> > +   sgpiom1: sgpiom@1e780600 {
> > +   #gpio-cells = <2>;
> > +   gpio-controller;
> > +   compatible = "aspeed,ast2600-sgpiom";
> > +   reg = <0x1e780600 0x100>;
> > +   interrupts = ;
> > +   ngpios = <80>;
> > +   clocks = < ASPEED_CLK_APB2>;
> > +

[PATCH] cpufreq: stats: Fix string format specifier mismatch

2020-10-11 Thread Viresh Kumar

Fix following warning:

drivers/cpufreq/cpufreq_stats.c:63:10: warning: %d in format string (no.
1) requires 'int' but the argument type is 'unsigned int'

Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to 
cpufreq_stats_record_transition()")
Reported-by: kernel test robot 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_stats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index 1b1389face85..6cd5c8ab5d49 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -62,7 +62,7 @@ static ssize_t show_total_trans(struct cpufreq_policy 
*policy, char *buf)
if (READ_ONCE(stats->reset_pending))
return sprintf(buf, "%d\n", 0);
else
-   return sprintf(buf, "%d\n", stats->total_trans);
+   return sprintf(buf, "%u\n", stats->total_trans);
 }
 cpufreq_freq_attr_ro(total_trans);
 
-- 
2.25.0.rc1.19.g042ed3e048af

Re: [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread()

2020-10-11 Thread Ira Weiny

On Sat, Oct 10, 2020 at 11:36:49AM +, Bernard Metzler wrote:
> -ira.we...@intel.com wrote: -
> 

[snip]

> >@@ -505,7 +505,7 @@ static int siw_tx_hdt(struct siw_iwarp_tx *c_tx,
> >struct socket *s)
> > page_array[seg] = p;
> > 
> > if (!c_tx->use_sendpage) {
> >-iov[seg].iov_base = kmap(p) + fp_off;
> >+iov[seg].iov_base = kmap_thread(p) + 
> >fp_off;
> 
> This misses a corresponding kunmap_thread() in siw_unmap_pages()
> (pls change line 403 in siw_qp_tx.c as well)

Thanks I missed that.

Done.

Ira

> 
> Thanks,
> Bernard.
>

RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops

2020-10-11 Thread Z.q. Hou

Hi Kishon,

> -Original Message-
> From: Kishon Vijay Abraham I 
> Sent: 2020年10月1日 21:32
> To: Rob Herring 
> Cc: Gustavo Pimentel ; Z.q. Hou
> ; Lorenzo Pieralisi ;
> linux-kernel@vger.kernel.org; PCI ; Bjorn
> Helgaas ; Michael Walle ; Ard
> Biesheuvel 
> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of
> dw_child_pcie_ops
> 
> Hi Rob,
> 
> On 30/09/20 8:31 pm, Rob Herring wrote:
> > On Wed, Sep 30, 2020 at 8:22 AM Kishon Vijay Abraham I 
> wrote:
> >>
> >> Hi,
> >>
> >> On 29/09/20 10:41 pm, Rob Herring wrote:
> >>> On Tue, Sep 29, 2020 at 10:24 AM Gustavo Pimentel
> >>>  wrote:
> 
>  On Tue, Sep 29, 2020 at 5:5:41, Z.q. Hou 
> wrote:
> 
> > Hi Lorenzo,
> >
> > Thanks a lot for your comments!
> >
> >> -Original Message-
> >> From: Lorenzo Pieralisi 
> >> Sent: 2020年9月28日 17:39
> >> To: Z.q. Hou 
> >> Cc: Rob Herring ; linux-kernel@vger.kernel.org;
> >> PCI ; Bjorn Helgaas
> >> ; Gustavo Pimentel
> >> ; Michael Walle
> >> ; Ard Biesheuvel 
> >> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of
> >> dw_child_pcie_ops
> >>
> >> On Thu, Sep 24, 2020 at 04:24:47AM +, Z.q. Hou wrote:
> >>> Hi Rob,
> >>>
> >>> Thanks a lot for your comments!
> >>>
>  -Original Message-
>  From: Rob Herring 
>  Sent: 2020年9月18日 23:28
>  To: Z.q. Hou 
>  Cc: linux-kernel@vger.kernel.org; PCI
>  ; Lorenzo Pieralisi
>  ; Bjorn Helgaas
>  ; Gustavo Pimentel
>  ; Michael Walle
> >> ;
>  Ard Biesheuvel 
>  Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus
>  of dw_child_pcie_ops
> 
>  On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou
> 
> >> wrote:
> >
> > Hi Rob,
> >
> > Thanks a lot for your comments!
> >
> >> -Original Message-
> >> From: Rob Herring 
> >> Sent: 2020年9月17日 4:29
> >> To: Z.q. Hou 
> >> Cc: linux-kernel@vger.kernel.org; PCI
> >> ; Lorenzo Pieralisi
> >> ; Bjorn Helgaas
> >> ; Gustavo Pimentel
> >> ; Michael Walle
>  ;
> >> Ard Biesheuvel 
> >> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus
> >> of dw_child_pcie_ops
> >>
> >> On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou
>  
> >> wrote:
> >>>
> >>> From: Hou Zhiqiang 
> >>>
> >>> On NXP Layerscape platforms, it results in SError in the
> >>> enumeration of the PCIe controller, which is not connecting
> >>> with an Endpoint device. And it doesn't make sense to
> >>> enumerate the Endpoints when the PCIe link is down. So this
> >>> patch added the link up check to avoid to fire configuration
> >> transactions on link down bus.
> >>
> >> Michael reported the same issue as well.
> >>
> >> What happens if the link goes down between the check and the
> >> access?
> >
> > This patch cannot cover this case, and will get the SError.
> > But I think it makes sense to avoid firing transactions on link
> down bus.
> 
>  That's impossible to do without a race even in h/w.
> >>>
> >>> Agree.
> >>>
> 
> >> It's a racy check. I'd like to find an alternative solution.
> >> It's even worse if Layerscape is used in ECAM mode. I looked
> >> at the EDK2 setup for layerscape[1] and it looks like root
> >> ports are just skipped if link
>  is down.
> >> Maybe a link down just never happens once up, but if so, then
> >> we only need to check it once and fail probe.
> >
> > Many customers connect the FPGA Endpoint, which may
> establish
> > PCIe link after the PCIe enumeration and then rescan the PCIe
> > bus, so I think it should not exit the probe of root port even
> > if there is not link up
>  during enumeration.
> 
>  That's a good reason. I want to unify the behavior here as it
>  varies per platform currently and wasn't sure which way to go.
> 
> 
> >> I've dug into this a bit more and am curious about the
> >> PCIE_ABSERR register setting which is set to:
> >>
> >> #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of
> >> non-posted request */
> >>
> >> It seems to me this is not what we want at least for config
> >> accesses, but commit 84d897d6993 where this was added
> seems
> >> to say otherwise. Is it not possible to configure the
> >> response per access
> >> type?
> >
> > Thanks a lot for your investigation!
> > The story is like this: Some customers worry about these
> > silent error (DWC

[PATCH 09/15] dmaengine: dw-axi-dmac: Support burst residue granularity

Add support for DMA_RESIDUE_GRANULARITY_BURST so that AxiDMA can report
DMA residue.

Existing AxiDMA driver only support data transfer between
memory to memory operation, therefore reporting DMA residue
to the DMA clients is not supported.

Reporting DMA residue to the DMA clients is important as DMA clients
shall invoke dmaengine_tx_status() to understand the number of bytes
been transferred so that the buffer pointer can be updated accordingly.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 44 ---
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h |  2 +
 2 files changed, 39 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 011cf7134f25..cd99557a716c 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -265,14 +265,36 @@ dma_chan_tx_status(struct dma_chan *dchan, dma_cookie_t 
cookie,
  struct dma_tx_state *txstate)
 {
struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
-   enum dma_status ret;
+   struct virt_dma_desc *vdesc;
+   enum dma_status status;
+   u32 completed_length;
+   unsigned long flags;
+   u32 completed_blocks;
+   size_t bytes = 0;
+   u32 length;
+   u32 len;
 
-   ret = dma_cookie_status(dchan, cookie, txstate);
+   status = dma_cookie_status(dchan, cookie, txstate);
+   if (status == DMA_COMPLETE)
+   return status;
 
-   if (chan->is_paused && ret == DMA_IN_PROGRESS)
-   ret = DMA_PAUSED;
+   spin_lock_irqsave(>vc.lock, flags);
 
-   return ret;
+   vdesc = vchan_find_desc(>vc, cookie);
+   if (vdesc) {
+   length = vd_to_axi_desc(vdesc)->length;
+   completed_blocks = vd_to_axi_desc(vdesc)->completed_blocks;
+   len = vd_to_axi_desc(vdesc)->hw_desc[0].len;
+   completed_length = completed_blocks * len;
+   bytes = length - completed_length;
+   } else {
+   bytes = vd_to_axi_desc(vdesc)->length;
+   }
+
+   spin_unlock_irqrestore(>vc.lock, flags);
+   dma_set_residue(txstate, bytes);
+
+   return status;
 }
 
 static void write_desc_llp(struct axi_dma_hw_desc *desc, dma_addr_t adr)
@@ -497,6 +519,7 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, dma_addr_t 
dst_adr,
 
desc->chan = chan;
num = 0;
+   desc->length = 0;
while (len) {
xfer_len = len;
 
@@ -549,7 +572,8 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, dma_addr_t 
dst_adr,
set_desc_src_master(hw_desc);
set_desc_dest_master(hw_desc, desc);
 
-
+   hw_desc->len = xfer_len;
+   desc->length += hw_desc->len;
/* update the length and addresses for the next loop cycle */
len -= xfer_len;
dst_adr += xfer_len;
@@ -612,6 +636,7 @@ dw_axi_dma_chan_prep_cyclic(struct dma_chan *dchan, 
dma_addr_t dma_addr,
chan->direction = direction;
desc->chan = chan;
chan->cyclic = true;
+   desc->length = 0;
 
switch (direction) {
case DMA_MEM_TO_DEV:
@@ -677,6 +702,8 @@ dw_axi_dma_chan_prep_cyclic(struct dma_chan *dchan, 
dma_addr_t dma_addr,
 
set_desc_src_master(hw_desc);
 
+   hw_desc->len = period_len;
+   desc->length += hw_desc->len;
/*
 * Set end-of-link to the linked descriptor, so that cyclic
 * callback function can be triggered during interrupt.
@@ -757,6 +784,7 @@ dw_axi_dma_chan_prep_slave_sg(struct dma_chan *dchan, 
struct scatterlist *sgl,
}
 
desc->chan = chan;
+   desc->length = 0;
 
for_each_sg(sgl, sg, sg_len, i) {
mem = sg_dma_address(sg);
@@ -806,6 +834,8 @@ dw_axi_dma_chan_prep_slave_sg(struct dma_chan *dchan, 
struct scatterlist *sgl,
hw_desc->lli->ctl_lo = cpu_to_le32(ctllo);
 
set_desc_src_master(hw_desc);
+   hw_desc->len = len;
+   desc->length += hw_desc->len;
}
 
if (unlikely(!desc))
@@ -1269,7 +1299,7 @@ static int dw_probe(struct platform_device *pdev)
dw->dma.dst_addr_widths = AXI_DMA_BUSWIDTHS;
dw->dma.directions = BIT(DMA_MEM_TO_MEM);
dw->dma.directions |= BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
-   dw->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+   dw->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
 
dw->dma.dev = chip->dev;
dw->dma.device_tx_status = dma_chan_tx_status;
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
index 651874e5c88f..bdb66d775125 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
@@

[PATCH 14/15] dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA BYTE and HALFWORD registers

Add support for Intel KeemBay AxiDMA BYTE and HALFWORD registers
programming.

Intel KeemBay AxiDMA supports data transfer between device to memory
and memory to device operations.

This code is needed by I2C, I3C, I2S, SPI and UART which uses FIFO
size of 8bits and 16bits to perform memory to device data transfer
operation. 0-padding functionality is provided to avoid
pre-processing of data on CPU.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 44 ---
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 0f40b41fd5c0..d4fca3ffe67f 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -312,7 +312,7 @@ static void axi_chan_block_xfer_start(struct axi_dma_chan 
*chan,
  struct axi_dma_desc *first)
 {
u32 priority = chan->chip->dw->hdata->priority[chan->id];
-   u32 reg, irq_mask;
+   u32 reg, irq_mask, reg_width, offset, val;
u8 lms = 0; /* Select AXI0 master for LLI fetching */
 
if (unlikely(axi_chan_is_hw_enable(chan))) {
@@ -334,6 +334,25 @@ static void axi_chan_block_xfer_start(struct axi_dma_chan 
*chan,
   DWAXIDMAC_HS_SEL_HW << CH_CFG_H_HS_SEL_SRC_POS);
switch (chan->direction) {
case DMA_MEM_TO_DEV:
+   if (chan->chip->apb_regs) {
+   reg_width = __ffs(chan->config.dst_addr_width);
+   /*
+* Configure Byte and Halfword register
+* for MEM_TO_DEV only.
+*/
+   if (reg_width == DWAXIDMAC_TRANS_WIDTH_16) {
+   offset = DMAC_APB_HALFWORD_WR_CH_EN;
+   val = ioread32(chan->chip->apb_regs + offset);
+   val |= BIT(chan->id);
+   iowrite32(val, chan->chip->apb_regs + offset);
+   } else if (reg_width == DWAXIDMAC_TRANS_WIDTH_8) {
+   offset = DMAC_APB_BYTE_WR_CH_EN;
+   val = ioread32(chan->chip->apb_regs + offset);
+   val |= BIT(chan->id);
+   iowrite32(val, chan->chip->apb_regs + offset);
+   }
+   }
+
reg |= (chan->config.device_fc ?
DWAXIDMAC_TT_FC_MEM_TO_PER_DST :
DWAXIDMAC_TT_FC_MEM_TO_PER_DMAC)
@@ -1054,8 +1073,9 @@ static int dma_chan_terminate_all(struct dma_chan *dchan)
 {
struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
u32 chan_active = BIT(chan->id) << DMAC_CHAN_EN_SHIFT;
+   u32 reg_width = __ffs(chan->config.dst_addr_width);
unsigned long flags;
-   u32 val;
+   u32 offset, val;
int ret;
LIST_HEAD(head);
 
@@ -1067,9 +1087,23 @@ static int dma_chan_terminate_all(struct dma_chan *dchan)
dev_warn(dchan2dev(dchan),
 "%s failed to stop\n", axi_chan_name(chan));
 
-   if (chan->direction != DMA_MEM_TO_MEM)
-   dw_axi_dma_set_hw_channel(chan->chip,
- chan->hw_hs_num, false);
+   if (chan->direction != DMA_MEM_TO_MEM) {
+   ret = dw_axi_dma_set_hw_channel(chan->chip,
+   chan->hw_hs_num, false);
+   if (ret == 0 && chan->direction == DMA_MEM_TO_DEV) {
+   if (reg_width == DWAXIDMAC_TRANS_WIDTH_8) {
+   offset = DMAC_APB_BYTE_WR_CH_EN;
+   val = ioread32(chan->chip->apb_regs + offset);
+   val &= ~BIT(chan->id);
+   iowrite32(val, chan->chip->apb_regs + offset);
+   } else if (reg_width == DWAXIDMAC_TRANS_WIDTH_16) {
+   offset = DMAC_APB_HALFWORD_WR_CH_EN;
+   val = ioread32(chan->chip->apb_regs + offset);
+   val &= ~BIT(chan->id);
+   iowrite32(val, chan->chip->apb_regs + offset);
+   }
+   }
+   }
 
spin_lock_irqsave(>vc.lock, flags);
 
-- 
2.18.0

[PATCH 15/15] dmaengine: dw-axi-dmac: Set constraint to the Max segment size

Add support for DMA Scatter-Gather (SG) constraint so that DMA clients can
handle the AxiDMA limitation.

Without supporting DMA constraint the default Max segment size reported by
dmaengine is 64KB, which is not supported by Intel KeemBay AxiDMA.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 8 
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h  | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index d4fca3ffe67f..bd56e21663c3 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1407,6 +1408,13 @@ static int dw_probe(struct platform_device *pdev)
dw->dma.device_prep_slave_sg = dw_axi_dma_chan_prep_slave_sg;
dw->dma.device_prep_dma_cyclic = dw_axi_dma_chan_prep_cyclic;
 
+   /*
+* Synopsis DesignWare AxiDMA datasheet mentioned Maximum
+* supported blocks is 1024. Device register width is 4 bytes.
+* Therefore, set constraint to 1024 * 4.
+*/
+   dw->dma.dev->dma_parms = >dma_parms;
+   dma_set_max_seg_size(>dev, MAX_BLOCK_SIZE);
platform_set_drvdata(pdev, chip);
 
pm_runtime_enable(chip->dev);
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
index f64e8d33b127..67669049cead 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
@@ -54,6 +54,7 @@ struct axi_dma_chan {
 struct dw_axi_dma {
struct dma_device   dma;
struct dw_axi_dma_hcfg  *hdata;
+   struct device_dma_parametersdma_parms;
 
/* channels */
struct axi_dma_chan *chan;
-- 
2.18.0

[PATCH 06/15] dmaengine: dw-axi-dmac: Support device_prep_slave_sg

Add device_prep_slave_sg() callback function so that DMA_MEM_TO_DEV
and DMA_DEV_TO_MEM operations in single mode can be supported.

Existing AxiDMA driver only support data transfer between
memory to memory. Data transfer between device to memory and
memory to device in single mode would failed if this interface
is not supported by the AxiDMA driver.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 142 ++
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h |   1 +
 2 files changed, 143 insertions(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 16e6934ae9a1..1124c97025f2 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -307,6 +307,22 @@ static void axi_chan_block_xfer_start(struct axi_dma_chan 
*chan,
   priority << CH_CFG_H_PRIORITY_POS |
   DWAXIDMAC_HS_SEL_HW << CH_CFG_H_HS_SEL_DST_POS |
   DWAXIDMAC_HS_SEL_HW << CH_CFG_H_HS_SEL_SRC_POS);
+   switch (chan->direction) {
+   case DMA_MEM_TO_DEV:
+   reg |= (chan->config.device_fc ?
+   DWAXIDMAC_TT_FC_MEM_TO_PER_DST :
+   DWAXIDMAC_TT_FC_MEM_TO_PER_DMAC)
+   << CH_CFG_H_TT_FC_POS;
+   break;
+   case DMA_DEV_TO_MEM:
+   reg |= (chan->config.device_fc ?
+   DWAXIDMAC_TT_FC_PER_TO_MEM_SRC :
+   DWAXIDMAC_TT_FC_PER_TO_MEM_DMAC)
+   << CH_CFG_H_TT_FC_POS;
+   break;
+   default:
+   break;
+   }
axi_chan_iowrite32(chan, CH_CFG_H, reg);
 
write_chan_llp(chan, first->hw_desc[0].llp | lms);
@@ -559,6 +575,129 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, 
dma_addr_t dst_adr,
return NULL;
 }
 
+static struct dma_async_tx_descriptor *
+dw_axi_dma_chan_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
+ unsigned int sg_len,
+ enum dma_transfer_direction direction,
+ unsigned long flags, void *context)
+{
+   struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
+   unsigned int data_width = BIT(chan->chip->dw->hdata->m_data_width);
+   struct axi_dma_hw_desc *hw_desc = NULL;
+   struct axi_dma_desc *desc = NULL;
+   struct scatterlist *sg;
+   unsigned int reg_width;
+   unsigned int mem_width;
+   dma_addr_t reg;
+   unsigned int i;
+   u32 ctllo, ctlhi;
+   size_t block_ts;
+   u32 mem, len;
+   u64 llp = 0;
+   u8 lms = 0; /* Select AXI0 master for LLI fetching */
+
+   if (unlikely(!is_slave_direction(direction) || !sg_len))
+   return NULL;
+
+   chan->direction = direction;
+
+   desc = axi_desc_alloc(sg_len);
+   if (unlikely(!desc))
+   goto err_desc_get;
+
+   switch (direction) {
+   case DMA_MEM_TO_DEV:
+   reg_width = __ffs(chan->config.dst_addr_width);
+   reg = chan->config.dst_addr;
+   ctllo = reg_width << CH_CTL_L_DST_WIDTH_POS |
+   DWAXIDMAC_CH_CTL_L_NOINC << CH_CTL_L_DST_INC_POS |
+   DWAXIDMAC_CH_CTL_L_INC << CH_CTL_L_SRC_INC_POS;
+   break;
+   case DMA_DEV_TO_MEM:
+   reg_width = __ffs(chan->config.src_addr_width);
+   reg = chan->config.src_addr;
+   ctllo = reg_width << CH_CTL_L_SRC_WIDTH_POS |
+   DWAXIDMAC_CH_CTL_L_INC << CH_CTL_L_DST_INC_POS |
+   DWAXIDMAC_CH_CTL_L_NOINC << CH_CTL_L_SRC_INC_POS;
+   break;
+   default:
+   return NULL;
+   }
+
+   desc->chan = chan;
+
+   for_each_sg(sgl, sg, sg_len, i) {
+   mem = sg_dma_address(sg);
+   len = sg_dma_len(sg);
+   hw_desc = >hw_desc[i];
+   mem_width = __ffs(data_width | mem | len);
+   if (mem_width > DWAXIDMAC_TRANS_WIDTH_32)
+   mem_width = DWAXIDMAC_TRANS_WIDTH_32;
+
+   hw_desc->lli = axi_desc_get(chan, _desc->llp);
+   if (unlikely(!hw_desc->lli))
+   goto err_desc_get;
+
+   if (direction == DMA_MEM_TO_DEV)
+   block_ts = len >> mem_width;
+   else
+   block_ts = len >> reg_width;
+
+   ctlhi = CH_CTL_H_LLI_VALID;
+   if (chan->chip->dw->hdata->restrict_axi_burst_len) {
+   u32 burst_len = chan->chip->dw->hdata->axi_rw_burst_len;
+
+   ctlhi |= (CH_CTL_H_ARLEN_EN |
+   burst_len << CH_CTL_H_ARLEN_POS |
+   CH_CTL_H_AWLEN_EN |
+   burst_len << CH_CTL_H_AWLEN_POS);
+

Re: [PATCH RESEND] drm/aspeed: fix Kconfig warning & subsequent build errors

On Sun, 11 Oct 2020 at 23:01, Randy Dunlap  wrote:
>
> kernel test robot reported build errors (undefined references)
> that didn't make much sense. After reproducing them, there is also
> a Kconfig warning that is the root cause of the build errors, so
> fix that Kconfig problem.
>
> Fixes this Kconfig warning:
> WARNING: unmet direct dependencies detected for CMA
>   Depends on [n]: MMU [=n]
>   Selected by [m]:
>   - DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=m] && OF [=y] && 
> (COMPILE_TEST [=y] || ARCH_ASPEED) && HAVE_DMA_CONTIGUOUS [=y]
>
> and these dependent build errors:
> (.text+0x10c8c): undefined reference to `start_isolate_page_range'
> microblaze-linux-ld: (.text+0x10f14): undefined reference to 
> `test_pages_isolated'
> microblaze-linux-ld: (.text+0x10fd0): undefined reference to 
> `undo_isolate_page_range'
>
> Fixes: 76356a966e33 ("drm: aspeed: Clean up Kconfig options")
> Reported-by: kernel test robot 
> Signed-off-by: Randy Dunlap 
> Cc: Joel Stanley 
> Cc: Andrew Jeffery 
> Cc: Daniel Vetter 
> Cc: Michal Simek 
> Cc: Andrew Morton 
> Cc: Mike Rapoport 
> Cc: linux...@kvack.org
> Cc: linux-asp...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: David Airlie 
> Cc: dri-de...@lists.freedesktop.org
> ---
> First sent on 2020-09-07.
> Feel free to fix the Kconfig warning some other way...

Reviewed-by: Joel Stanley 

Thanks Randy. Sorry for missing it the first time around. I'll merge
this into drm-misc-next.

Cheers,

Joel



>
>  drivers/gpu/drm/aspeed/Kconfig |1 +
>  1 file changed, 1 insertion(+)
>
> --- linux-next-20201009.orig/drivers/gpu/drm/aspeed/Kconfig
> +++ linux-next-20201009/drivers/gpu/drm/aspeed/Kconfig
> @@ -3,6 +3,7 @@ config DRM_ASPEED_GFX
> tristate "ASPEED BMC Display Controller"
> depends on DRM && OF
> depends on (COMPILE_TEST || ARCH_ASPEED)
> +   depends on MMU
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> select DMA_CMA if HAVE_DMA_CONTIGUOUS

[PATCH 08/15] dmaengine: dw-axi-dmac: Support of_dma_controller_register()

Add support for of_dma_controller_register() so that DMA clients
can pass in device handshake number to the AxiDMA driver.

DMA clients shall code the device handshake number in the Device tree.
When DMA activities are needed, DMA clients shall invoke OF helper
function to pass in the device handshake number to the AxiDMA.

Without register to the of_dma_controller_register(), data transfer
between memory to device and device to memory operations would failed.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 26 +++
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 9e574753aaf0..011cf7134f25 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1103,6 +1104,22 @@ static int __maybe_unused axi_dma_runtime_resume(struct 
device *dev)
return axi_dma_resume(chip);
 }
 
+static struct dma_chan *dw_axi_dma_of_xlate(struct of_phandle_args *dma_spec,
+   struct of_dma *ofdma)
+{
+   struct dw_axi_dma *dw = ofdma->of_dma_data;
+   struct axi_dma_chan *chan;
+   struct dma_chan *dchan;
+
+   dchan = dma_get_any_slave_channel(>dma);
+   if (!dchan)
+   return NULL;
+
+   chan = dchan_to_axi_dma_chan(dchan);
+   chan->hw_hs_num = dma_spec->args[0];
+   return dchan;
+}
+
 static int parse_device_properties(struct axi_dma_chip *chip)
 {
struct device *dev = chip->dev;
@@ -1292,6 +1309,13 @@ static int dw_probe(struct platform_device *pdev)
if (ret)
goto err_pm_disable;
 
+   /* Register with OF helpers for DMA lookups */
+   ret = of_dma_controller_register(pdev->dev.of_node,
+dw_axi_dma_of_xlate, dw);
+   if (ret < 0)
+   dev_warn(>dev,
+"Failed to register OF DMA controller, fallback to 
MEM_TO_MEM mode\n");
+
dev_info(chip->dev, "DesignWare AXI DMA Controller, %d channels\n",
 dw->hdata->nr_channels);
 
@@ -1325,6 +1349,8 @@ static int dw_remove(struct platform_device *pdev)
 
devm_free_irq(chip->dev, chip->irq, chip);
 
+   of_dma_controller_free(chip->dev->of_node);
+
list_for_each_entry_safe(chan, _chan, >dma.channels,
vc.chan.device_node) {
list_del(>vc.chan.device_node);
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
index a26b0a242a93..651874e5c88f 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
@@ -37,6 +37,7 @@ struct axi_dma_chan {
struct axi_dma_chip *chip;
void __iomem*chan_regs;
u8  id;
+   u8  hw_hs_num;
atomic_tdescs_allocated;
 
struct dma_pool *desc_pool;
-- 
2.18.0

[PATCH 03/15] dmaengine: dw-axi-dmac: move dma_pool_create() to alloc_chan_resources()

The DMA memory block is created at driver load time and exist for
device lifetime. Move the dma_pool_create() to the ->chan_resource()
callback function allowing the DMA memory blocks to be created as needed
and destroyed when the channel is freed.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 24 ++-
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h |  2 +-
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 8cfd645479e1..46e2ba978e20 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -216,11 +216,10 @@ static struct axi_dma_desc *axi_desc_alloc(u32 num)
 static struct axi_dma_lli *axi_desc_get(struct axi_dma_chan *chan,
dma_addr_t *addr)
 {
-   struct dw_axi_dma *dw = chan->chip->dw;
struct axi_dma_lli *lli;
dma_addr_t phys;
 
-   lli = dma_pool_zalloc(dw->desc_pool, GFP_NOWAIT, );
+   lli = dma_pool_zalloc(chan->desc_pool, GFP_NOWAIT, );
if (unlikely(!lli)) {
dev_err(chan2dev(chan), "%s: not enough descriptors 
available\n",
axi_chan_name(chan));
@@ -236,14 +235,13 @@ static struct axi_dma_lli *axi_desc_get(struct 
axi_dma_chan *chan,
 static void axi_desc_put(struct axi_dma_desc *desc)
 {
struct axi_dma_chan *chan = desc->chan;
-   struct dw_axi_dma *dw = chan->chip->dw;
int count = atomic_read(>descs_allocated);
struct axi_dma_hw_desc *hw_desc;
int descs_put;
 
for (descs_put = 0; descs_put < count; descs_put++) {
hw_desc = >hw_desc[descs_put];
-   dma_pool_free(dw->desc_pool, hw_desc->lli, hw_desc->llp);
+   dma_pool_free(chan->desc_pool, hw_desc->lli, hw_desc->llp);
}
 
kfree(desc->hw_desc);
@@ -360,6 +358,15 @@ static int dma_chan_alloc_chan_resources(struct dma_chan 
*dchan)
return -EBUSY;
}
 
+   /* LLI address must be aligned to a 64-byte boundary */
+   chan->desc_pool = dma_pool_create(dev_name(chan2dev(chan)),
+ chan->chip->dev,
+ sizeof(struct axi_dma_lli),
+ 64, 0);
+   if (!chan->desc_pool) {
+   dev_err(chan2dev(chan), "No memory for descriptors\n");
+   return -ENOMEM;
+   }
dev_vdbg(dchan2dev(dchan), "%s: allocating\n", axi_chan_name(chan));
 
pm_runtime_get(chan->chip->dev);
@@ -381,6 +388,8 @@ static void dma_chan_free_chan_resources(struct dma_chan 
*dchan)
 
vchan_free_chan_resources(>vc);
 
+   dma_pool_destroy(chan->desc_pool);
+   chan->desc_pool = NULL;
dev_vdbg(dchan2dev(dchan),
 "%s: free resources, descriptor still allocated: %u\n",
 axi_chan_name(chan), atomic_read(>descs_allocated));
@@ -896,13 +905,6 @@ static int dw_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   /* Lli address must be aligned to a 64-byte boundary */
-   dw->desc_pool = dmam_pool_create(KBUILD_MODNAME, chip->dev,
-sizeof(struct axi_dma_lli), 64, 0);
-   if (!dw->desc_pool) {
-   dev_err(chip->dev, "No memory for descriptors dma pool\n");
-   return -ENOMEM;
-   }
 
INIT_LIST_HEAD(>dma.channels);
for (i = 0; i < hdata->nr_channels; i++) {
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
index 41e775e6e593..f886b2bb75de 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
@@ -39,6 +39,7 @@ struct axi_dma_chan {
u8  id;
atomic_tdescs_allocated;
 
+   struct dma_pool *desc_pool;
struct virt_dma_chanvc;
 
struct axi_dma_desc *desc;
@@ -49,7 +50,6 @@ struct axi_dma_chan {
 struct dw_axi_dma {
struct dma_device   dma;
struct dw_axi_dma_hcfg  *hdata;
-   struct dma_pool *desc_pool;
 
/* channels */
struct axi_dma_chan *chan;
-- 
2.18.0

[PATCH 02/15] dmaengine: dw-axi-dmac: simplify descriptor management

Simplify and refactor the descriptor management by removing the redundant
Linked List Item (LLI) queue control logic from the AxiDMA driver.
The descriptor is split into virtual descriptor and hardware LLI so that
only hardware LLI memories are allocated from the DMA memory pool.

Up to 64 descriptors can be allocated within a PAGE_SIZE compare to 16
descriptors in previous version. This solves the problem where an
ALSA driver expects more than 16 DMA descriptors to run.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 164 ++
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h |   9 +-
 2 files changed, 102 insertions(+), 71 deletions(-)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 14c1ac26f866..8cfd645479e1 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "dw-axi-dmac.h"
@@ -195,43 +196,58 @@ static inline const char *axi_chan_name(struct 
axi_dma_chan *chan)
return dma_chan_name(>vc.chan);
 }
 
-static struct axi_dma_desc *axi_desc_get(struct axi_dma_chan *chan)
+static struct axi_dma_desc *axi_desc_alloc(u32 num)
 {
-   struct dw_axi_dma *dw = chan->chip->dw;
struct axi_dma_desc *desc;
+
+   desc = kzalloc(sizeof(*desc), GFP_NOWAIT);
+   if (!desc)
+   return NULL;
+
+   desc->hw_desc = kcalloc(num, sizeof(*desc->hw_desc), GFP_NOWAIT);
+   if (!desc->hw_desc) {
+   kfree(desc);
+   return NULL;
+   }
+
+   return desc;
+}
+
+static struct axi_dma_lli *axi_desc_get(struct axi_dma_chan *chan,
+   dma_addr_t *addr)
+{
+   struct dw_axi_dma *dw = chan->chip->dw;
+   struct axi_dma_lli *lli;
dma_addr_t phys;
 
-   desc = dma_pool_zalloc(dw->desc_pool, GFP_NOWAIT, );
-   if (unlikely(!desc)) {
+   lli = dma_pool_zalloc(dw->desc_pool, GFP_NOWAIT, );
+   if (unlikely(!lli)) {
dev_err(chan2dev(chan), "%s: not enough descriptors 
available\n",
axi_chan_name(chan));
return NULL;
}
 
atomic_inc(>descs_allocated);
-   INIT_LIST_HEAD(>xfer_list);
-   desc->vd.tx.phys = phys;
-   desc->chan = chan;
+   *addr = phys;
 
-   return desc;
+   return lli;
 }
 
 static void axi_desc_put(struct axi_dma_desc *desc)
 {
struct axi_dma_chan *chan = desc->chan;
struct dw_axi_dma *dw = chan->chip->dw;
-   struct axi_dma_desc *child, *_next;
-   unsigned int descs_put = 0;
+   int count = atomic_read(>descs_allocated);
+   struct axi_dma_hw_desc *hw_desc;
+   int descs_put;
 
-   list_for_each_entry_safe(child, _next, >xfer_list, xfer_list) {
-   list_del(>xfer_list);
-   dma_pool_free(dw->desc_pool, child, child->vd.tx.phys);
-   descs_put++;
+   for (descs_put = 0; descs_put < count; descs_put++) {
+   hw_desc = >hw_desc[descs_put];
+   dma_pool_free(dw->desc_pool, hw_desc->lli, hw_desc->llp);
}
 
-   dma_pool_free(dw->desc_pool, desc, desc->vd.tx.phys);
-   descs_put++;
-
+   kfree(desc->hw_desc);
+   kfree(desc);
atomic_sub(descs_put, >descs_allocated);
dev_vdbg(chan2dev(chan), "%s: %d descs put, %d still allocated\n",
axi_chan_name(chan), descs_put,
@@ -258,9 +274,9 @@ dma_chan_tx_status(struct dma_chan *dchan, dma_cookie_t 
cookie,
return ret;
 }
 
-static void write_desc_llp(struct axi_dma_desc *desc, dma_addr_t adr)
+static void write_desc_llp(struct axi_dma_hw_desc *desc, dma_addr_t adr)
 {
-   desc->lli.llp = cpu_to_le64(adr);
+   desc->lli->llp = cpu_to_le64(adr);
 }
 
 static void write_chan_llp(struct axi_dma_chan *chan, dma_addr_t adr)
@@ -295,7 +311,7 @@ static void axi_chan_block_xfer_start(struct axi_dma_chan 
*chan,
   DWAXIDMAC_HS_SEL_HW << CH_CFG_H_HS_SEL_SRC_POS);
axi_chan_iowrite32(chan, CH_CFG_H, reg);
 
-   write_chan_llp(chan, first->vd.tx.phys | lms);
+   write_chan_llp(chan, first->hw_desc[0].llp | lms);
 
irq_mask = DWAXIDMAC_IRQ_DMA_TRF | DWAXIDMAC_IRQ_ALL_ERR;
axi_chan_irq_sig_set(chan, irq_mask);
@@ -378,67 +394,78 @@ static void dma_chan_free_chan_resources(struct dma_chan 
*dchan)
  * transfer and completes the DMA transfer operation at the end of current
  * block transfer.
  */
-static void set_desc_last(struct axi_dma_desc *desc)
+static void set_desc_last(struct axi_dma_hw_desc *desc)
 {
u32 val;
 
-   val = le32_to_cpu(desc->lli.ctl_hi);
+   val = le32_to_cpu(desc->lli->ctl_hi);
val |= CH_CTL_H_LLI_LAST;
-   desc->lli.ctl_hi = cpu_to_le32(val);
+   desc->lli->ctl_hi = cpu_to_le32(val);
 }
 
-static void

[PATCH 12/15] dmaengine: dw-axi-dmac: Add Intel KeemBay DMA register fields

Add support for Intel KeemBay DMA registers. These registers are required
to run data transfer between device to memory and memory to device on Intel
KeemBay SoC.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c |  4 
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h  | 14 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index ce89b4dee1dc..19806c586e81 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -1252,6 +1252,10 @@ static int dw_probe(struct platform_device *pdev)
if (IS_ERR(chip->regs))
return PTR_ERR(chip->regs);
 
+   chip->apb_regs = devm_platform_ioremap_resource(pdev, 1);
+   if (IS_ERR(chip->apb_regs))
+   dev_warn(>dev, "apb_regs not supported\n");
+
chip->core_clk = devm_clk_get(chip->dev, "core-clk");
if (IS_ERR(chip->core_clk))
return PTR_ERR(chip->core_clk);
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
index bdb66d775125..f64e8d33b127 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
@@ -63,6 +63,7 @@ struct axi_dma_chip {
struct device   *dev;
int irq;
void __iomem*regs;
+   void __iomem*apb_regs;
struct clk  *core_clk;
struct clk  *cfgr_clk;
struct dw_axi_dma   *dw;
@@ -169,6 +170,19 @@ static inline struct axi_dma_chan 
*dchan_to_axi_dma_chan(struct dma_chan *dchan)
 #define CH_INTSIGNAL_ENA   0x090 /* R/W Chan Interrupt Signal Enable */
 #define CH_INTCLEAR0x098 /* W Chan Interrupt Clear */
 
+/* Apb slave registers */
+#define DMAC_APB_CFG   0x000 /* DMAC Apb Configuration Register */
+#define DMAC_APB_STAT  0x004 /* DMAC Apb Status Register */
+#define DMAC_APB_DEBUG_STAT_0  0x008 /* DMAC Apb Debug Status Register 0 */
+#define DMAC_APB_DEBUG_STAT_1  0x00C /* DMAC Apb Debug Status Register 1 */
+#define DMAC_APB_HW_HS_SEL_0   0x010 /* DMAC Apb HW HS register 0 */
+#define DMAC_APB_HW_HS_SEL_1   0x014 /* DMAC Apb HW HS register 1 */
+#define DMAC_APB_LPI   0x018 /* DMAC Apb Low Power Interface Reg */
+#define DMAC_APB_BYTE_WR_CH_EN 0x01C /* DMAC Apb Byte Write Enable */
+#define DMAC_APB_HALFWORD_WR_CH_EN 0x020 /* DMAC Halfword write enables */
+
+#define UNUSED_CHANNEL 0x3F /* Set unused DMA channel to 0x3F */
+#define MAX_BLOCK_SIZE 0x1000 /* 1024 blocks * 4 bytes data width */
 
 /* DMAC_CFG */
 #define DMAC_EN_POS0
-- 
2.18.0

[PATCH 07/15] dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic()

Add support for device_prep_dma_cyclic() callback function to benefit
DMA cyclic client, for example ALSA.

Existing AxiDMA driver only support data transfer between memory to memory.
Data transfer between device to memory and memory to device in cyclic mode
would failed if this interface is not supported by the AxiDMA driver.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 182 +-
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h |   2 +
 2 files changed, 177 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 1124c97025f2..9e574753aaf0 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -575,6 +577,135 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, 
dma_addr_t dst_adr,
return NULL;
 }
 
+static struct dma_async_tx_descriptor *
+dw_axi_dma_chan_prep_cyclic(struct dma_chan *dchan, dma_addr_t dma_addr,
+   size_t buf_len, size_t period_len,
+   enum dma_transfer_direction direction,
+   unsigned long flags)
+{
+   struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
+   u32 data_width = BIT(chan->chip->dw->hdata->m_data_width);
+   struct axi_dma_hw_desc *hw_desc = NULL;
+   struct axi_dma_desc *desc = NULL;
+   dma_addr_t src_addr = dma_addr;
+   u32 num_periods = buf_len / period_len;
+   unsigned int reg_width;
+   unsigned int mem_width;
+   dma_addr_t reg;
+   unsigned int i;
+   u32 ctllo, ctlhi;
+   size_t block_ts;
+   u64 llp = 0;
+   u8 lms = 0; /* Select AXI0 master for LLI fetching */
+
+   block_ts = chan->chip->dw->hdata->block_size[chan->id];
+
+   mem_width = __ffs(data_width | dma_addr | period_len);
+   if (mem_width > DWAXIDMAC_TRANS_WIDTH_32)
+   mem_width = DWAXIDMAC_TRANS_WIDTH_32;
+
+   desc = axi_desc_alloc(num_periods);
+   if (unlikely(!desc))
+   goto err_desc_get;
+
+   chan->direction = direction;
+   desc->chan = chan;
+   chan->cyclic = true;
+
+   switch (direction) {
+   case DMA_MEM_TO_DEV:
+   reg_width = __ffs(chan->config.dst_addr_width);
+   reg = chan->config.dst_addr;
+   ctllo = reg_width << CH_CTL_L_DST_WIDTH_POS |
+   DWAXIDMAC_CH_CTL_L_NOINC << CH_CTL_L_DST_INC_POS |
+   DWAXIDMAC_CH_CTL_L_INC << CH_CTL_L_SRC_INC_POS;
+   break;
+   case DMA_DEV_TO_MEM:
+   reg_width = __ffs(chan->config.src_addr_width);
+   reg = chan->config.src_addr;
+   ctllo = reg_width << CH_CTL_L_SRC_WIDTH_POS |
+   DWAXIDMAC_CH_CTL_L_INC << CH_CTL_L_DST_INC_POS |
+   DWAXIDMAC_CH_CTL_L_NOINC << CH_CTL_L_SRC_INC_POS;
+   break;
+   default:
+   return NULL;
+   }
+
+   for (i = 0; i < num_periods; i++) {
+   hw_desc = >hw_desc[i];
+
+   hw_desc->lli = axi_desc_get(chan, _desc->llp);
+   if (unlikely(!hw_desc->lli))
+   goto err_desc_get;
+
+   if (direction == DMA_MEM_TO_DEV)
+   block_ts = period_len >> mem_width;
+   else
+   block_ts = period_len >> reg_width;
+
+   ctlhi = CH_CTL_H_LLI_VALID;
+   if (chan->chip->dw->hdata->restrict_axi_burst_len) {
+   u32 burst_len = chan->chip->dw->hdata->axi_rw_burst_len;
+
+   ctlhi |= (CH_CTL_H_ARLEN_EN |
+   burst_len << CH_CTL_H_ARLEN_POS |
+   CH_CTL_H_AWLEN_EN |
+   burst_len << CH_CTL_H_AWLEN_POS);
+   }
+
+   hw_desc->lli->ctl_hi = cpu_to_le32(ctlhi);
+
+   if (direction == DMA_MEM_TO_DEV)
+   ctllo |= mem_width << CH_CTL_L_SRC_WIDTH_POS;
+   else
+   ctllo |= mem_width << CH_CTL_L_DST_WIDTH_POS;
+
+   if (direction == DMA_MEM_TO_DEV) {
+   write_desc_sar(hw_desc, src_addr);
+   write_desc_dar(hw_desc, reg);
+   } else {
+   write_desc_sar(hw_desc, reg);
+   write_desc_dar(hw_desc, src_addr);
+   }
+
+   hw_desc->lli->block_ts_lo = cpu_to_le32(block_ts - 1);
+
+   ctllo |= (DWAXIDMAC_BURST_TRANS_LEN_4 << CH_CTL_L_DST_MSIZE_POS 
|
+ DWAXIDMAC_BURST_TRANS_LEN_4 << 
CH_CTL_L_SRC_MSIZE_POS);
+   hw_desc->lli->ctl_lo = cpu_to_le32(ctllo);
+
+

[PATCH 04/15] dmaengine: dw-axi-dmac: Add device_synchronize() callback

Add support for device_synchronize() callback function to sync with
dmaengine_terminate_sync().

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 46e2ba978e20..56b213211341 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -347,6 +347,13 @@ static void dma_chan_issue_pending(struct dma_chan *dchan)
spin_unlock_irqrestore(>vc.lock, flags);
 }
 
+static void dw_axi_dma_synchronize(struct dma_chan *dchan)
+{
+   struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
+
+   vchan_synchronize(>vc);
+}
+
 static int dma_chan_alloc_chan_resources(struct dma_chan *dchan)
 {
struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
@@ -940,6 +947,7 @@ static int dw_probe(struct platform_device *pdev)
dw->dma.device_free_chan_resources = dma_chan_free_chan_resources;
 
dw->dma.device_prep_dma_memcpy = dma_chan_prep_dma_memcpy;
+   dw->dma.device_synchronize = dw_axi_dma_synchronize;
 
platform_set_drvdata(pdev, chip);
 
-- 
2.18.0

[PATCH 10/15] dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA support

Add support for Intel KeemBay AxiDMA to the .compatible field.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index cd99557a716c..ce89b4dee1dc 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -1396,6 +1396,7 @@ static const struct dev_pm_ops dw_axi_dma_pm_ops = {
 
 static const struct of_device_id dw_dma_of_id_table[] = {
{ .compatible = "snps,axi-dma-1.01a" },
+   { .compatible = "intel,kmb-axi-dma" },
{}
 };
 MODULE_DEVICE_TABLE(of, dw_dma_of_id_table);
-- 
2.18.0

[PATCH 05/15] dmaengine: dw-axi-dmac: Add device_config operation

Add device_config() callback function so that the device address
can be passed to the dma driver.

DMA clients use this interface to pass in the device address to the
AxiDMA. Without this interface, data transfer between device to memory
and memory to device would failed.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 11 +++
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h  |  1 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 56b213211341..16e6934ae9a1 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -559,6 +559,16 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, 
dma_addr_t dst_adr,
return NULL;
 }
 
+static int dw_axi_dma_chan_slave_config(struct dma_chan *dchan,
+   struct dma_slave_config *config)
+{
+   struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
+
+   memcpy(>config, config, sizeof(*config));
+
+   return 0;
+}
+
 static void axi_chan_dump_lli(struct axi_dma_chan *chan,
  struct axi_dma_hw_desc *desc)
 {
@@ -948,6 +958,7 @@ static int dw_probe(struct platform_device *pdev)
 
dw->dma.device_prep_dma_memcpy = dma_chan_prep_dma_memcpy;
dw->dma.device_synchronize = dw_axi_dma_synchronize;
+   dw->dma.device_config = dw_axi_dma_chan_slave_config;
 
platform_set_drvdata(pdev, chip);
 
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
index f886b2bb75de..a75b921d6b1a 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac.h
@@ -43,6 +43,7 @@ struct axi_dma_chan {
struct virt_dma_chanvc;
 
struct axi_dma_desc *desc;
+   struct dma_slave_config config;
/* these other elements are all protected by vc.lock */
boolis_paused;
 };
-- 
2.18.0

[PATCH 13/15] dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA handshake

Add support for Intel KeemBay AxiDMA device handshake programming.
Device handshake number passed in to the AxiDMA shall be written to
the Intel KeemBay AxiDMA hardware handshake registers before DMA
operations are started.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Sia Jee Heng 
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 52 +++
 1 file changed, 52 insertions(+)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index 19806c586e81..0f40b41fd5c0 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -445,6 +445,48 @@ static void dma_chan_free_chan_resources(struct dma_chan 
*dchan)
pm_runtime_put(chan->chip->dev);
 }
 
+static int dw_axi_dma_set_hw_channel(struct axi_dma_chip *chip, u32 hs_number,
+bool set)
+{
+   unsigned long start = 0;
+   unsigned long reg_value;
+   unsigned long reg_mask;
+   unsigned long reg_set;
+   unsigned long mask;
+   unsigned long val;
+
+   if (!chip->apb_regs)
+   return -ENODEV;
+
+   /*
+* An unused DMA channel has a default value of 0x3F.
+* Lock the DMA channel by assign a handshake number to the channel.
+* Unlock the DMA channel by assign 0x3F to the channel.
+*/
+   if (set) {
+   reg_set = UNUSED_CHANNEL;
+   val = hs_number;
+   } else {
+   reg_set = hs_number;
+   val = UNUSED_CHANNEL;
+   }
+
+   reg_value = lo_hi_readq(chip->apb_regs + DMAC_APB_HW_HS_SEL_0);
+
+   for_each_set_clump8(start, reg_mask, _value, 64) {
+   if (reg_mask == reg_set) {
+   mask = GENMASK_ULL(start + 7, start);
+   reg_value &= ~mask;
+   reg_value |= rol64(val, start);
+   lo_hi_writeq(reg_value,
+chip->apb_regs + DMAC_APB_HW_HS_SEL_0);
+   break;
+   }
+   }
+
+   return 0;
+}
+
 /*
  * If DW_axi_dmac sees CHx_CTL.ShadowReg_Or_LLI_Last bit of the fetched LLI
  * as 1, it understands that the current block is the final block in the
@@ -725,6 +767,9 @@ dw_axi_dma_chan_prep_cyclic(struct dma_chan *dchan, 
dma_addr_t dma_addr,
llp = hw_desc->llp;
} while (num_periods);
 
+   if (dw_axi_dma_set_hw_channel(chan->chip, chan->hw_hs_num, true))
+   goto err_desc_get;
+
return vchan_tx_prep(>vc, >vd, flags);
 
 err_desc_get:
@@ -851,6 +896,9 @@ dw_axi_dma_chan_prep_slave_sg(struct dma_chan *dchan, 
struct scatterlist *sgl,
llp = hw_desc->llp;
} while (sg_len);
 
+   if (dw_axi_dma_set_hw_channel(chan->chip, chan->hw_hs_num, true))
+   goto err_desc_get;
+
return vchan_tx_prep(>vc, >vd, flags);
 
 err_desc_get:
@@ -1019,6 +1067,10 @@ static int dma_chan_terminate_all(struct dma_chan *dchan)
dev_warn(dchan2dev(dchan),
 "%s failed to stop\n", axi_chan_name(chan));
 
+   if (chan->direction != DMA_MEM_TO_MEM)
+   dw_axi_dma_set_hw_channel(chan->chip,
+ chan->hw_hs_num, false);
+
spin_lock_irqsave(>vc.lock, flags);
 
vchan_get_all_descriptors(>vc, );
-- 
2.18.0

[PATCH 11/15] dt-binding: dma: dw-axi-dmac: Add support for Intel KeemBay AxiDMA

Add support for Intel KeemBay AxiDMA to the dw-axi-dmac
Schemas DT binding.

Signed-off-by: Sia Jee Heng 
---
 .../bindings/dma/snps,dw-axi-dmac.yaml| 25 +++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml 
b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
index e688d25864bc..0e9bc5553a36 100644
--- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
@@ -8,6 +8,7 @@ title: Synopsys DesignWare AXI DMA Controller
 
 maintainers:
   - Eugeniy Paltsev 
 
 description: |
  Synopsys DesignWare AXI DMA Controller DT Binding
@@ -16,6 +17,7 @@ properties:
   compatible:
 enum:
   - snps,axi-dma-1.01a
+  - intel,kmb-axi-dma
 
   reg:
 items:
@@ -24,6 +26,7 @@ properties:
   reg-names:
 items:
   - const: axidma_ctrl_regs
+  - const: axidma_apb_regs
 
   interrupts:
 maxItems: 1
@@ -122,3 +125,25 @@ examples:
  snps,priority = <0 1 2 3>;
  snps,axi-max-burst-len = <16>;
  };
+
+  - |
+ #include 
+ #include 
+ /* example with intel,kmb-axi-dma */
+ #define KEEM_BAY_PSS_AXI_DMA
+ #define KEEM_BAY_PSS_APB_AXI_DMA
+ axi_dma: dma@2800 {
+ compatible = "intel,kmb-axi-dma";
+ reg = <0x2800 0x1000 0x2025 0x24>;
+ reg-names = "axidma_ctrl_regs", "axidma_apb_regs";
+ interrupts = ;
+ clock-names = "core-clk", "cfgr-clk";
+ clocks = <_clk KEEM_BAY_PSS_AXI_DMA>, <_clk 
KEEM_BAY_PSS_APB_AXI_DMA>;
+ #dma-cells = <1>;
+ dma-channels = <8>;
+ snps,dma-masters = <1>;
+ snps,data-width = <4>;
+ snps,priority = <0 0 0 0 0 0 0 0>;
+ snps,block-size = <1024 1024 1024 1024 1024 1024 1024 1024>;
+ snps,axi-max-burst-len = <16>;
+ };
-- 
2.18.0

[PATCH 01/15] dt-bindings: dma: Add YAML schemas for dw-axi-dmac

YAML schemas Device Tree (DT) binding is the new format for DT to replace
the old format. Introduce YAML schemas DT binding for dw-axi-dmac and
remove the old version.

Signed-off-by: Sia Jee Heng 
---
 .../bindings/dma/snps,dw-axi-dmac.txt |  39 --
 .../bindings/dma/snps,dw-axi-dmac.yaml| 124 ++
 2 files changed, 124 insertions(+), 39 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
 create mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml

diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt 
b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
deleted file mode 100644
index dbe160400adc..
--- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Synopsys DesignWare AXI DMA Controller
-
-Required properties:
-- compatible: "snps,axi-dma-1.01a"
-- reg: Address range of the DMAC registers. This should include
-  all of the per-channel registers.
-- interrupt: Should contain the DMAC interrupt number.
-- dma-channels: Number of channels supported by hardware.
-- snps,dma-masters: Number of AXI masters supported by the hardware.
-- snps,data-width: Maximum AXI data width supported by hardware.
-  (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
-- snps,priority: Priority of channel. Array size is equal to the number of
-  dma-channels. Priority value must be programmed within [0:dma-channels-1]
-  range. (0 - minimum priority)
-- snps,block-size: Maximum block size supported by the controller channel.
-  Array size is equal to the number of dma-channels.
-
-Optional properties:
-- snps,axi-max-burst-len: Restrict master AXI burst length by value specified
-  in this property. If this property is missing the maximum AXI burst length
-  supported by DMAC is used. [1:256]
-
-Example:
-
-dmac: dma-controller@8 {
-   compatible = "snps,axi-dma-1.01a";
-   reg = <0x8 0x400>;
-   clocks = <_clk>, <_clk>;
-   clock-names = "core-clk", "cfgr-clk";
-   interrupt-parent = <>;
-   interrupts = <27>;
-
-   dma-channels = <4>;
-   snps,dma-masters = <2>;
-   snps,data-width = <3>;
-   snps,block-size = <4096 4096 4096 4096>;
-   snps,priority = <0 1 2 3>;
-   snps,axi-max-burst-len = <16>;
-};
diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml 
b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
new file mode 100644
index ..e688d25864bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/snps,dw-axi-dmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare AXI DMA Controller
+
+maintainers:
+  - Eugeniy Paltsev 
+ #include 
+ /* example with snps,dw-axi-dmac */
+ dmac: dma-controller@8 {
+ compatible = "snps,axi-dma-1.01a";
+ reg = <0x8 0x400>;
+ clocks = <_clk>, <_clk>;
+ clock-names = "core-clk", "cfgr-clk";
+ interrupt-parent = <>;
+ interrupts = <27>;
+ #dma-cells = <1>;
+ dma-channels = <4>;
+ snps,dma-masters = <2>;
+ snps,data-width = <3>;
+ snps,block-size = <4096 4096 4096 4096>;
+ snps,priority = <0 1 2 3>;
+ snps,axi-max-burst-len = <16>;
+ };
-- 
2.18.0

[PATCH 00/15] dmaengine: dw-axi-dmac: support Intel KeemBay AxiDMA

The below patch series are to support AxiDMA running on Intel KeemBay SoC.
The base driver is dw-axi-dmac but code refactoring is needed, for example:
- Support YAML Schemas DT binding.
- Replacing Linked List with virtual descriptor management.
- Remove unrelated hw desc stuff from dma memory pool.
- Manage dma memory pool alloc/destroy based on channel activity.
- Support dmaengine device_sync() callback.
- Support dmaengine device_config().
- Support dmaegnine device_prep_slave_sg().
- Support dmaengine device_prep_dma_cyclic().
- Support of_dma_controller_register().
- Support burst residue granularity.
- Support Intel KeemBay AxiDMA registers.
- Support Intel KeemBay AxiDMA device handshake.
- Support Intel KeemBay AxiDMA BYTE and HALFWORD device operation.
- Add constraint to Max segment size.

This patch set is to replace the patch series submitted at:
https://lore.kernel.org/dmaengine/1599213094-30144-1-git-send-email-jee.heng@intel.com/

This patch series are tested on Intel KeemBay platform.


Sia Jee Heng (15):
  dt-bindings: dma: Add YAML schemas for dw-axi-dmac
  dmaengine: dw-axi-dmac: simplify descriptor management
  dmaengine: dw-axi-dmac: move dma_pool_create() to
alloc_chan_resources()
  dmaengine: dw-axi-dmac: Add device_synchronize() callback
  dmaengine: dw-axi-dmac: Add device_config operation
  dmaengine: dw-axi-dmac: Support device_prep_slave_sg
  dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic()
  dmaengine: dw-axi-dmac: Support of_dma_controller_register()
  dmaengine: dw-axi-dmac: Support burst residue granularity
  dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA support
  dt-binding: dma: dw-axi-dmac: Add support for Intel KeemBay AxiDMA
  dmaengine: dw-axi-dmac: Add Intel KeemBay DMA register fields
  dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA handshake
  dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA BYTE and HALFWORD
registers
  dmaengine: dw-axi-dmac: Set constraint to the Max segment size

 .../bindings/dma/snps,dw-axi-dmac.txt |  39 -
 .../bindings/dma/snps,dw-axi-dmac.yaml| 149 
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 696 +++---
 drivers/dma/dw-axi-dmac/dw-axi-dmac.h |  33 +-
 4 files changed, 783 insertions(+), 134 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
 create mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml

-- 
2.18.0

Re: [PATCH 3/3] pinctrl: aspeed-g6: Add sgpiom2 pinctrl setting

On Mon, 12 Oct 2020 at 03:32, Billy Tsai  wrote:
>
> At ast2600a1 we change feature of master sgpio to 2 sets.
> So this patch is used to add the pinctrl setting of the new sgpio.
>
> Signed-off-by: Billy Tsai 

Reviewed-by: Joel Stanley 

Linus, can you take this through the pinctrl tree? The patch to the
will be fine to come through your tree as we rarely update that file.

> ---
>  arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi   |  5 
>  drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 30 +++---
>  2 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi 
> b/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi
> index 7028e21bdd98..a16ecf08e307 100644
> --- a/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi
> @@ -862,6 +862,11 @@
> groups = "SGPM1";
> };
>
> +   pinctrl_sgpm2_default: sgpm2_default {
> +   function = "SGPM2";
> +   groups = "SGPM2";
> +   };
> +
> pinctrl_sgps1_default: sgps1_default {
> function = "SGPS1";
> groups = "SGPS1";
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
> b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> index 34803a6c7664..b673a44ffa3b 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> @@ -46,8 +46,10 @@
>  #define SCU620 0x620 /* Disable GPIO Internal Pull-Down #4 */
>  #define SCU634 0x634 /* Disable GPIO Internal Pull-Down #5 */
>  #define SCU638 0x638 /* Disable GPIO Internal Pull-Down #6 */
> +#define SCU690 0x690 /* Multi-function Pin Control #24 */
>  #define SCU694 0x694 /* Multi-function Pin Control #25 */
>  #define SCU69C 0x69C /* Multi-function Pin Control #27 */
> +#define SCU6D0 0x6D0 /* Multi-function Pin Control #28 */
>  #define SCUC20 0xC20 /* PCIE configuration Setting Control */
>
>  #define ASPEED_G6_NR_PINS 256
> @@ -81,13 +83,21 @@ FUNC_GROUP_DECL(I2C12, L26, K24);
>  #define K26 4
>  SIG_EXPR_LIST_DECL_SESG(K26, MACLINK1, MACLINK1, SIG_DESC_SET(SCU410, 4));
>  SIG_EXPR_LIST_DECL_SESG(K26, SCL13, I2C13, SIG_DESC_SET(SCU4B0, 4));
> -PIN_DECL_2(K26, GPIOA4, MACLINK1, SCL13);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(K26, SGPM2CLK, SGPM2, SIG_DESC_SET(SCU6D0, 4),
> + SIG_DESC_CLEAR(SCU410, 4), SIG_DESC_CLEAR(SCU4B0, 
> 4),
> + SIG_DESC_CLEAR(SCU690, 4));
> +PIN_DECL_3(K26, GPIOA4, SGPM2CLK, MACLINK1, SCL13);
>  FUNC_GROUP_DECL(MACLINK1, K26);
>
>  #define L24 5
>  SIG_EXPR_LIST_DECL_SESG(L24, MACLINK2, MACLINK2, SIG_DESC_SET(SCU410, 5));
>  SIG_EXPR_LIST_DECL_SESG(L24, SDA13, I2C13, SIG_DESC_SET(SCU4B0, 5));
> -PIN_DECL_2(L24, GPIOA5, MACLINK2, SDA13);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(L24, SGPM2LD, SGPM2, SIG_DESC_SET(SCU6D0, 5),
> + SIG_DESC_CLEAR(SCU410, 5), SIG_DESC_CLEAR(SCU4B0, 
> 5),
> + SIG_DESC_CLEAR(SCU690, 5));
> +PIN_DECL_3(L24, GPIOA5, SGPM2LD, MACLINK2, SDA13);
>  FUNC_GROUP_DECL(MACLINK2, L24);
>
>  FUNC_GROUP_DECL(I2C13, K26, L24);
> @@ -95,16 +105,26 @@ FUNC_GROUP_DECL(I2C13, K26, L24);
>  #define L23 6
>  SIG_EXPR_LIST_DECL_SESG(L23, MACLINK3, MACLINK3, SIG_DESC_SET(SCU410, 6));
>  SIG_EXPR_LIST_DECL_SESG(L23, SCL14, I2C14, SIG_DESC_SET(SCU4B0, 6));
> -PIN_DECL_2(L23, GPIOA6, MACLINK3, SCL14);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(L23, SGPM2O, SGPM2, SIG_DESC_SET(SCU6D0, 6),
> + SIG_DESC_CLEAR(SCU410, 6), SIG_DESC_CLEAR(SCU4B0, 
> 6),
> + SIG_DESC_CLEAR(SCU690, 6));
> +PIN_DECL_3(L23, GPIOA6, SGPM2O, MACLINK3, SCL14);
>  FUNC_GROUP_DECL(MACLINK3, L23);
>
>  #define K25 7
>  SIG_EXPR_LIST_DECL_SESG(K25, MACLINK4, MACLINK4, SIG_DESC_SET(SCU410, 7));
>  SIG_EXPR_LIST_DECL_SESG(K25, SDA14, I2C14, SIG_DESC_SET(SCU4B0, 7));
> -PIN_DECL_2(K25, GPIOA7, MACLINK4, SDA14);
> +/*SGPM2 is A1 Only */
> +SIG_EXPR_LIST_DECL_SESG(K25, SGPM2I, SGPM2, SIG_DESC_SET(SCU6D0, 7),
> + SIG_DESC_CLEAR(SCU410, 7), SIG_DESC_CLEAR(SCU4B0, 
> 7),
> + SIG_DESC_CLEAR(SCU690, 7));
> +PIN_DECL_3(K25, GPIOA7, SGPM2I, MACLINK4, SDA14);
>  FUNC_GROUP_DECL(MACLINK4, K25);
>
>  FUNC_GROUP_DECL(I2C14, L23, K25);
> +/*SGPM2 is A1 Only */
> +FUNC_GROUP_DECL(SGPM2, K26, L24, L23, K25);
>
>  #define J26 8
>  SIG_EXPR_LIST_DECL_SESG(J26, SALT1, SALT1, SIG_DESC_SET(SCU410, 8));
> @@ -2060,6 +2080,7 @@ static const struct aspeed_pin_group aspeed_g6_groups[] 
> = {
> ASPEED_PINCTRL_GROUP(EMMCG4),
> ASPEED_PINCTRL_GROUP(EMMCG8),
> ASPEED_PINCTRL_GROUP(SGPM1),
> +   ASPEED_PINCTRL_GROUP(SGPM2),
> ASPEED_PINCTRL_GROUP(SGPS1),
> ASPEED_PINCTRL_GROUP(SIOONCTRL),
> ASPEED_PINCTRL_GROUP(SIOPBI),
> @@ -2276,6 +2297,7 @@ static const struct aspeed_pin_function 
> aspeed_g6_functions[] = {

Re: [PATCH 2/3] Arm: dts: aspeed-g6: Add sgpio node

On Mon, 12 Oct 2020 at 03:32, Billy Tsai  wrote:
>
> This patch is used to add sgpiom and sgpios nodes and add compatiable
> string for sgpiom.

You also need to add sgpios documentation to the bindings docs.

Whenever you add new device tree bindings to the kernel tree you
should add documentation for them.

When preparing patches for submission, use scripts/checkpatch.pl to
check for common issues. It will warn you if you are adding strings
that are not documented.

Cheers,

Joel

>
> Signed-off-by: Billy Tsai 
> ---
>  .../devicetree/bindings/gpio/sgpio-aspeed.txt |  8 +--
>  arch/arm/boot/dts/aspeed-g6.dtsi  | 52 +++
>  2 files changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt 
> b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> index d4d83916c09d..815d9b5167a5 100644
> --- a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> +++ b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> @@ -1,8 +1,10 @@
>  Aspeed SGPIO controller Device Tree Bindings
>  
>
> -This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full
> -featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to
> +This SGPIO controller is for ASPEED AST2500/AST2600 SoC, it supports 2 
> master.
> +One is up to 128 SGPIO input ports and 128 output ports concurrently(after 
> AST2600A1)
> +and Second one is up to 80.
> +Each of the Serial GPIO pins can be programmed to
>  support the following options:
>  - Support interrupt option for each input port and various interrupt
>sensitivity option (level-high, level-low, edge-high, edge-low)
> @@ -14,7 +16,7 @@ support the following options:
>  Required properties:
>
>  - compatible : Should be one of
> -  "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio"
> +  "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio", "aspeed,ast2600-sgpiom"

I think we should add sgpiom strings for the ast2500 (and ast2400?)
too, as this is how they should have been named in the first place:

>  - compatible : Should be one of
>"aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio"
>   "aspeed,ast2400-sgpiom", "aspeed,ast2500-sgpiom", "aspeed,ast2600-sgpiom"


>  - #gpio-cells : Should be 2, see gpio.txt
>  - reg : Address and length of the register set for the device
>  - gpio-controller : Marks the device node as a GPIO controller
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi 
> b/arch/arm/boot/dts/aspeed-g6.dtsi
> index ad19dce038ea..cb053a996e87 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -366,6 +366,58 @@
> #interrupt-cells = <2>;
> };
>
> +   sgpiom0: sgpiom@1e780500 {
> +   #gpio-cells = <2>;
> +   gpio-controller;
> +   compatible = "aspeed,ast2600-sgpiom";
> +   reg = <0x1e780500 0x100>;
> +   interrupts = ;
> +   ngpios = <128>;
> +   clocks = < ASPEED_CLK_APB2>;
> +   interrupt-controller;
> +   bus-frequency = <1200>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_sgpm1_default>;
> +   status = "disabled";
> +   };
> +
> +   sgpiom1: sgpiom@1e780600 {
> +   #gpio-cells = <2>;
> +   gpio-controller;
> +   compatible = "aspeed,ast2600-sgpiom";
> +   reg = <0x1e780600 0x100>;
> +   interrupts = ;
> +   ngpios = <80>;
> +   clocks = < ASPEED_CLK_APB2>;
> +   interrupt-controller;
> +   bus-frequency = <1200>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_sgpm2_default>;
> +   status = "disabled";
> +   };
> +
> +   sgpios0: sgpios@1e780700 {
> +   #gpio-cells = <2>;
> +   gpio-controller;
> +   compatible = "aspeed,ast2600-sgpios";
> +   reg = <0x1e780700 0x40>;
> +   interrupts = ;
> +   clocks = < ASPEED_CLK_APB2>;
> +   status = "disabled";
> +   };
> +
> +   sgpios1: sgpios@1e780740 {
> +   #gpio-cells = <2>;
> +   gpio-controller;
> +

RE: [PATCH] PCI: layerscape: Change back to the default error response behavior

2020-10-11 Thread Z.q. Hou

Hi Rob and Kishon,

> -Original Message-
> From: Rob Herring 
> Sent: 2020年9月30日 23:08
> To: Kishon Vijay Abraham I 
> Cc: Z.q. Hou ; PCI ;
> linux-kernel@vger.kernel.org; linux-arm-kernel
> ; Lorenzo Pieralisi
> ; Bjorn Helgaas ; M.h.
> Lian ; Roy Zang ; Mingkai
> Hu ; Leo Li 
> Subject: Re: [PATCH] PCI: layerscape: Change back to the default error
> response behavior
> 
> On Wed, Sep 30, 2020 at 8:29 AM Kishon Vijay Abraham I 
> wrote:
> >
> > Hi Hou,
> >
> > On 29/09/20 6:43 pm, Zhiqiang Hou wrote:
> > > From: Hou Zhiqiang 
> > >
> > > In the current error response behavior, it will send a SLVERR
> > > response to device's internal AXI slave system interface when the
> > > PCIe controller experiences an erroneous completion (UR, CA and CT)
> > > from an external completer for its outbound non-posted request,
> > > which will result in SError and crash the kernel directly.
> > > This patch change back it to the default behavior to increase the
> > > robustness of the kernel. In the default behavior, it always sends
> > > an OKAY response to the internal AXI slave interface when the
> > > controller gets these erroneous completions. And the AER driver will
> > > report and try to recover these errors.
> >
> > I don't think not forwarding any error interrupts is a good idea.
> 
> Interrupts would be fine. Abort/SError is not. I think it is pretty clear 
> what the
> correct behavior is for config accesses.

I agree with Rob.

> 
> > Maybe
> > you could disable it while reading configuration space registers
> > (vendorID and deviceID) and then enable error forwarding back?
> 
> To add to the locking (or lack of) problems in config accesses?

If take this approach, during the hole of CFG access, the error of MEM_rd will 
also not be forwarded, so it's not a reliable mechanism for user.

Thanks,
Zhiqiang

> 
> Rob

Re: [PATCH 1/3] Arm: dts: aspeed-g6: Fix the register range of gpio

On Mon, 12 Oct 2020 at 03:32, Billy Tsai  wrote:
>
> This patch is used to fix the memory range of gpio0
>
> Signed-off-by: Billy Tsai 

Reviewed-by: Joel Stanley 

> ---
>  arch/arm/boot/dts/aspeed-g6.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi 
> b/arch/arm/boot/dts/aspeed-g6.dtsi
> index 97ca743363d7..ad19dce038ea 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -357,7 +357,7 @@
> #gpio-cells = <2>;
> gpio-controller;
> compatible = "aspeed,ast2600-gpio";
> -   reg = <0x1e78 0x800>;
> +   reg = <0x1e78 0x400>;
> interrupts = ;
> gpio-ranges = < 0 0 208>;
> ngpios = <208>;
> --
> 2.17.1
>

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

Hi all,

[Just adding Dave to cc's]

On Mon, 12 Oct 2020 15:24:52 +1100 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell  
> wrote:
> >
> > On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell  
> > wrote:  
> > >
> > > After merging the drm-misc tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > 
> > In file included from include/linux/clk.h:13,
> >  from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
> > drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function 
> > 'ingenic_drm_update_palette':
> > drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct 
> > ingenic_drm' has no member named 'dma_hwdescs'; did you mean 
> > 'dma_hwdesc_f0'?
> >   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
> >   |   ^~~
> > include/linux/kernel.h:47:33: note: in definition of macro 'ARRAY_SIZE'
> >47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> > __must_be_array(arr))
> >   | ^~~
> > drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct 
> > ingenic_drm' has no member named 'dma_hwdescs'; did you mean 
> > 'dma_hwdesc_f0'?
> >   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
> >   |   ^~~
> > include/linux/kernel.h:47:48: note: in definition of macro 'ARRAY_SIZE'
> >47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> > __must_be_array(arr))
> >   |^~~
> > In file included from include/linux/bits.h:22,
> >  from include/linux/bitops.h:5,
> >  from drivers/gpu/drm/ingenic/ingenic-drm.h:10,
> >  from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:7:
> > drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct 
> > ingenic_drm' has no member named 'dma_hwdescs'; did you mean 
> > 'dma_hwdesc_f0'?
> >   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
> >   |   ^~~
> > include/linux/build_bug.h:16:62: note: in definition of macro 
> > 'BUILD_BUG_ON_ZERO'
> >16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); 
> > })))
> >   |  ^
> > include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
> >   224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), 
> > &(a)[0]))
> >   |  ^~~
> > include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
> >47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> > __must_be_array(arr))
> >   |   
> > ^~~
> > drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of 
> > macro 'ARRAY_SIZE'
> >   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
> >   |  ^~
> > drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct 
> > ingenic_drm' has no member named 'dma_hwdescs'; did you mean 
> > 'dma_hwdesc_f0'?
> >   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
> >   |   ^~~
> > include/linux/build_bug.h:16:62: note: in definition of macro 
> > 'BUILD_BUG_ON_ZERO'
> >16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); 
> > })))
> >   |  ^
> > include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
> >   224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), 
> > &(a)[0]))
> >   |  ^~~
> > include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
> >47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> > __must_be_array(arr))
> >   |   
> > ^~~
> > drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of 
> > macro 'ARRAY_SIZE'
> >   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
> >   |  ^~
> > include/linux/build_bug.h:16:51: error: bit-field '' width not 
> > an integer constant
> >16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); 
> > })))
> >   |   ^
> > include/linux/compiler.h:224:28: note: in expansion of macro 
> > 'BUILD_BUG_ON_ZERO'
> >   224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), 
> > &(a)[0]))
> >   |^
> > include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
> >47 | #define

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

Hi all,

On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell  
wrote:
>
> On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:  
> 
> In file included from include/linux/clk.h:13,
>  from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function 
> 'ingenic_drm_update_palette':
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm' 
> has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
>   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
>   |   ^~~
> include/linux/kernel.h:47:33: note: in definition of macro 'ARRAY_SIZE'
>47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>   | ^~~
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm' 
> has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
>   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
>   |   ^~~
> include/linux/kernel.h:47:48: note: in definition of macro 'ARRAY_SIZE'
>47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>   |^~~
> In file included from include/linux/bits.h:22,
>  from include/linux/bitops.h:5,
>  from drivers/gpu/drm/ingenic/ingenic-drm.h:10,
>  from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:7:
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm' 
> has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
>   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
>   |   ^~~
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
>16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
>   |  ^
> include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
>   224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), 
> &(a)[0]))
>   |  ^~~
> include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
>47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>   |   
> ^~~
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro 
> 'ARRAY_SIZE'
>   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
>   |  ^~
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm' 
> has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
>   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
>   |   ^~~
> include/linux/build_bug.h:16:62: note: in definition of macro 
> 'BUILD_BUG_ON_ZERO'
>16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
>   |  ^
> include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
>   224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), 
> &(a)[0]))
>   |  ^~~
> include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
>47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>   |   
> ^~~
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro 
> 'ARRAY_SIZE'
>   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
>   |  ^~
> include/linux/build_bug.h:16:51: error: bit-field '' width not an 
> integer constant
>16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
>   |   ^
> include/linux/compiler.h:224:28: note: in expansion of macro 
> 'BUILD_BUG_ON_ZERO'
>   224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), 
> &(a)[0]))
>   |^
> include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
>47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>   |   
> ^~~
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro 
> 'ARRAY_SIZE'
>   448 |  for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);

[PATCH net] net: 9p: initialize sun_server.sun_path to have addr's value only when addr is valid

2020-10-11 Thread Anant Thazhemadam

In p9_fd_create_unix, checking is performed to see if the addr (passed
as an argument) is NULL or not.
However, no check is performed to see if addr is a valid address, i.e.,
it doesn't entirely consist of only 0's.
The initialization of sun_server.sun_path to be equal to this faulty
addr value leads to an uninitialized variable, as detected by KMSAN.
Checking for this (faulty addr) and returning a negative error number
appropriately, resolves this issue.

Reported-by: syzbot+75d51fe5bf4ebe988...@syzkaller.appspotmail.com
Tested-by: syzbot+75d51fe5bf4ebe988...@syzkaller.appspotmail.com
Signed-off-by: Anant Thazhemadam 
---
 net/9p/trans_fd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index c0762a302162..8f528e783a6c 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -1023,7 +1023,7 @@ p9_fd_create_unix(struct p9_client *client, const char 
*addr, char *args)
 
csocket = NULL;
 
-   if (addr == NULL)
+   if (!addr || !strlen(addr))
return -EINVAL;
 
if (strlen(addr) >= UNIX_PATH_MAX) {
-- 
2.25.1

RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops

2020-10-11 Thread Z.q. Hou



> -Original Message-
> From: Rob Herring 
> Sent: 2020年9月30日 1:11
> To: Gustavo Pimentel 
> Cc: Z.q. Hou ; Lorenzo Pieralisi
> ; linux-kernel@vger.kernel.org; PCI
> ; Bjorn Helgaas ;
> Michael Walle ; Ard Biesheuvel 
> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of
> dw_child_pcie_ops
> 
> On Tue, Sep 29, 2020 at 10:24 AM Gustavo Pimentel
>  wrote:
> >
> > On Tue, Sep 29, 2020 at 5:5:41, Z.q. Hou  wrote:
> >
> > > Hi Lorenzo,
> > >
> > > Thanks a lot for your comments!
> > >
> > > > -Original Message-
> > > > From: Lorenzo Pieralisi 
> > > > Sent: 2020年9月28日 17:39
> > > > To: Z.q. Hou 
> > > > Cc: Rob Herring ; linux-kernel@vger.kernel.org;
> > > > PCI ; Bjorn Helgaas
> > > > ; Gustavo Pimentel
> > > > ; Michael Walle
> ;
> > > > Ard Biesheuvel 
> > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of
> > > > dw_child_pcie_ops
> > > >
> > > > On Thu, Sep 24, 2020 at 04:24:47AM +, Z.q. Hou wrote:
> > > > > Hi Rob,
> > > > >
> > > > > Thanks a lot for your comments!
> > > > >
> > > > > > -Original Message-
> > > > > > From: Rob Herring 
> > > > > > Sent: 2020年9月18日 23:28
> > > > > > To: Z.q. Hou 
> > > > > > Cc: linux-kernel@vger.kernel.org; PCI
> > > > > > ; Lorenzo Pieralisi
> > > > > > ; Bjorn Helgaas
> > > > > > ; Gustavo Pimentel
> > > > > > ; Michael Walle
> > > > ;
> > > > > > Ard Biesheuvel 
> > > > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus
> > > > > > of dw_child_pcie_ops
> > > > > >
> > > > > > On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou
> > > > > > 
> > > > wrote:
> > > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > Thanks a lot for your comments!
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Rob Herring 
> > > > > > > > Sent: 2020年9月17日 4:29
> > > > > > > > To: Z.q. Hou 
> > > > > > > > Cc: linux-kernel@vger.kernel.org; PCI
> > > > > > > > ; Lorenzo Pieralisi
> > > > > > > > ; Bjorn Helgaas
> > > > > > > > ; Gustavo Pimentel
> > > > > > > > ; Michael Walle
> > > > > > ;
> > > > > > > > Ard Biesheuvel 
> > > > > > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in
> > > > > > > > map_bus of dw_child_pcie_ops
> > > > > > > >
> > > > > > > > On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou
> > > > > > 
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > From: Hou Zhiqiang 
> > > > > > > > >
> > > > > > > > > On NXP Layerscape platforms, it results in SError in the
> > > > > > > > > enumeration of the PCIe controller, which is not
> > > > > > > > > connecting with an Endpoint device. And it doesn't make
> > > > > > > > > sense to enumerate the Endpoints when the PCIe link is
> > > > > > > > > down. So this patch added the link up check to avoid to
> > > > > > > > > fire configuration
> > > > transactions on link down bus.
> > > > > > > >
> > > > > > > > Michael reported the same issue as well.
> > > > > > > >
> > > > > > > > What happens if the link goes down between the check and
> > > > > > > > the
> > > > access?
> > > > > > >
> > > > > > > This patch cannot cover this case, and will get the SError.
> > > > > > > But I think it makes sense to avoid firing transactions on link 
> > > > > > > down
> bus.
> > > > > >
> > > > > > That's impossible to do without a race even in h/w.
> > > > >
> > > > > Agree.
> > > > >
> > > > > >
> > > > > > > > It's a racy check. I'd like to find an alternative solution.
> > > > > > > > It's even worse if Layerscape is used in ECAM mode. I
> > > > > > > > looked at the EDK2 setup for layerscape[1] and it looks
> > > > > > > > like root ports are just skipped if link
> > > > > > is down.
> > > > > > > > Maybe a link down just never happens once up, but if so,
> > > > > > > > then we only need to check it once and fail probe.
> > > > > > >
> > > > > > > Many customers connect the FPGA Endpoint, which may
> > > > > > > establish PCIe link after the PCIe enumeration and then
> > > > > > > rescan the PCIe bus, so I think it should not exit the probe
> > > > > > > of root port even if there is not link up
> > > > > > during enumeration.
> > > > > >
> > > > > > That's a good reason. I want to unify the behavior here as it
> > > > > > varies per platform currently and wasn't sure which way to go.
> > > > > >
> > > > > >
> > > > > > > > I've dug into this a bit more and am curious about the
> > > > > > > > PCIE_ABSERR register setting which is set to:
> > > > > > > >
> > > > > > > > #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of
> > > > > > > > non-posted request */
> > > > > > > >
> > > > > > > > It seems to me this is not what we want at least for
> > > > > > > > config accesses, but commit 84d897d6993 where this was
> > > > > > > > added seems to say otherwise. Is it not possible to
> > > > > > > > configure the response per access
> > > > type?
> > > > > > >
> > > > > > > Thanks a lot for your investigation!
> > > > > > > The story is like this: Some customers worry about these
> > > > > > > silent error (DWC PCIe IP won't

Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo

2020-10-11 Thread Muchun Song

On Mon, Oct 12, 2020 at 2:39 AM Cong Wang  wrote:
>
> On Sat, Oct 10, 2020 at 3:39 AM Muchun Song  wrote:
> >
> > The amount of memory allocated to sockets buffer can become significant.
> > However, we do not display the amount of memory consumed by sockets
> > buffer. In this case, knowing where the memory is consumed by the kernel
>
> We do it via `ss -m`. Is it not sufficient? And if not, why not adding it 
> there
> rather than /proc/meminfo?

If the system has little free memory, we can know where the memory is via
/proc/meminfo. If a lot of memory is consumed by socket buffer, we cannot
know it when the Sock is not shown in the /proc/meminfo. If the unaware user
can't think of the socket buffer, naturally they will not `ss -m`. The
end result
is that we still don’t know where the memory is consumed. And we add the
Sock to the /proc/meminfo just like the memcg does('sock' item in the cgroup
v2 memory.stat). So I think that adding to /proc/meminfo is sufficient.

>
> >  static inline void __skb_frag_unref(skb_frag_t *frag)
> >  {
> > -   put_page(skb_frag_page(frag));
> > +   struct page *page = skb_frag_page(frag);
> > +
> > +   if (put_page_testzero(page)) {
> > +   dec_sock_node_page_state(page);
> > +   __put_page(page);
> > +   }
> >  }
>
> You mix socket page frag with skb frag at least, not sure this is exactly
> what you want, because clearly skb page frags are frequently used
> by network drivers rather than sockets.
>
> Also, which one matches this dec_sock_node_page_state()? Clearly
> not skb_fill_page_desc() or __skb_frag_ref().

Yeah, we call inc_sock_node_page_state() in the skb_page_frag_refill().
So if someone gets the page returned by skb_page_frag_refill(), it must
put the page via __skb_frag_unref()/skb_frag_unref(). We use PG_private
to indicate that we need to dec the node page state when the refcount of
page reaches zero.

Thanks.

>
> Thanks.

-- 
Yours,
Muchun

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

Hi all,

On Tue, 6 Oct 2020 13:41:20 -0300 Jason Gunthorpe  wrote:
>
> On Tue, Oct 06, 2020 at 08:35:08PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the hmm tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > 
> > Caused by commit
> > 
> >   07da1223ec93 ("lib/scatterlist: Add support in dynamic allocation of SG 
> > table from pages")
> > 
> > interacting with commit
> > 
> >   707d561f77b5 ("drm: allow limiting the scatter list size.")
> > 
> > from the drm tree.
> > 
> > I have added the following merge fix patch
> > 
> > From: Stephen Rothwell 
> > Date: Tue, 6 Oct 2020 20:22:51 +1100
> > Subject: [PATCH] lib/scatterlist: merge fix for "drm: allow limiting the
> >  scatter list size."
> > 
> > Signed-off-by: Stephen Rothwell 
> >  drivers/gpu/drm/drm_prime.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 11fe9ff76fd5..83ac901b65a2 100644
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -807,6 +807,7 @@ struct sg_table *drm_prime_pages_to_sg(struct 
> > drm_device *dev,
> >struct page **pages, unsigned int 
> > nr_pages)
> >  {
> > struct sg_table *sg = NULL;
> > +   struct scatterlist *sl;
> > size_t max_segment = 0;
> > int ret;
> >  
> > @@ -820,11 +821,13 @@ struct sg_table *drm_prime_pages_to_sg(struct 
> > drm_device *dev,
> > max_segment = dma_max_mapping_size(dev->dev);
> > if (max_segment == 0 || max_segment > SCATTERLIST_MAX_SEGMENT)
> > max_segment = SCATTERLIST_MAX_SEGMENT;
> > -   ret = __sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
> > +   sl = __sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
> >   nr_pages << PAGE_SHIFT,
> > - max_segment, GFP_KERNEL);
> > -   if (ret)
> > + max_segment, NULL, 0, GFP_KERNEL);
> > +   if (IS_ERR(sl)) {
> > +   ret = PTR_ERR(sl);
> > goto out;
> > +   }
> >  
> > return sg;
> >  out:  
> 
> This looks OK to me, thanks

This merge fix patch is now being applied to the merge of the drm tree
since the rdma tree (that is merged before the drm tree) has merged the
hmm tree.

-- 
Cheers,
Stephen Rothwell


pgplG89gH_xs1.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies

2020-10-11 Thread Viresh Kumar

On 09-10-20, 16:28, Nicola Mazzucato wrote:
> @Viresh
> I am sorry I misread your reply earlier thus I did not pay attention on that
> property.
> And yes, it is exactly as how you have described :)
> In the case 1 (different opps, different clk) and case 2 (same opps, different
> clk) we provide v/f points. In case 3, we add 'opp-shared' property in opp 
> table
> to tell that the cpus with this opp table share a clock line.
> 
> Here are my thoughts on this 3rd case:
> - the information of 'share the same clock line' comes correctly from DT as 
> it's
> purely a hw description. The same applies for cpu-perf-dependencies.
> - because the opp table can come from any firmware, we won't have any opp 
> table
> in DT, thus we won't be able to take advantage of 'opp-shared' I am afraid.

I wonder if we should use an empty OPP table just for parsing this
information.

-- 
viresh

Re: linux-next: manual merge of the tip tree with the amdgpu tree

Hi all,

On Wed, 23 Sep 2020 15:13:36 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> 
> between commit:
> 
>   59d7115dae02 ("drm/amdkfd: Move process doorbell allocation into kfd 
> device")
> 
> from the amdgpu tree and commit:
> 
>   c7b6bac9c72c ("drm, iommu: Change type of pasid to u32")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> 
> diff --cc drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index 739db04080d0,922ae138ab85..
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@@ -739,7 -723,8 +739,7 @@@ struct kfd_process 
>   /* We want to receive a notification when the mm_struct is destroyed */
>   struct mmu_notifier mmu_notifier;
>   
> - uint16_t pasid;
> + u32 pasid;
>  -unsigned int doorbell_index;
>   
>   /*
>* List of kfd_process_device structures,

This is now a conflict between the tip tree and the drm tree.

-- 
Cheers,
Stephen Rothwell


pgpjjMNVv8p0T.pgp
Description: OpenPGP digital signature

Re: [PATCH V4 3/3] arm64/mm/hotplug: Ensure early memory sections are all online

2020-10-11 Thread Gavin Shan


Hi Anshuman,

On 10/6/20 2:11 PM, Anshuman Khandual wrote:

On 10/01/2020 06:23 AM, Gavin Shan wrote:

On 9/29/20 11:54 PM, Anshuman Khandual wrote:

This adds a validation function that scans the entire boot memory and makes
sure that all early memory sections are online. This check is essential for
the memory notifier to work properly, as it cannot prevent any boot memory
from offlining, if all sections are not online to begin with. The notifier
registration is skipped, if this validation does not go through. Although
the boot section scanning is selectively enabled with DEBUG_VM.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Steve Capper 
Cc: Mark Brown 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
   arch/arm64/mm/mmu.c | 59 +
   1 file changed, 59 insertions(+)


I don't understand why this is necessary. The core already ensure the
corresponding section is online when trying to offline it. It's guranteed
that section is online when the notifier is triggered. I'm not sure if
there is anything I missed?


Current memory notifier blocks any boot memory hot removal attempt via
blocking its offlining step itself. So if some sections in boot memory
are not online (because of a bug or change in init sequence) by the
time memory block device can be removed, the notifier loses the ability
to prevent its removal. This validation here, ensures that entire boot
memory is in online state, otherwise call out sections that are not,
with an warning that those boot memory can be removed.



Well. I think it should be very rare. I guess you don't observe the
errornous case so far? However, I think it's fine to add the check
since it's only enabled with CONFIG_DEBUG_VM.

  


diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 90a30f5ebfc0..b67a657ea1ad 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1522,6 +1522,62 @@ static struct notifier_block prevent_bootmem_remove_nb = 
{
   .notifier_call = prevent_bootmem_remove_notifier,
   };
   +/*
+ * This ensures that boot memory sections on the plaltform are online


Will fix.


     ^

+ * during early boot. They could not be prevented from being offlined
+ * if for some reason they are not brought online to begin with. This
+ * help validate the basic assumption on which the above memory event
+ * notifier works to prevent boot memory offlining and it's possible
+ * removal.
+ */
+static bool validate_bootmem_online(void)
+{
+    struct memblock_region *mblk;
+    struct mem_section *ms;
+    unsigned long pfn, end_pfn, start, end;
+    bool all_online = true;
+
+    /*
+ * Scanning across all memblock might be expensive
+ * on some big memory systems. Hence enable this
+ * validation only with DEBUG_VM.
+ */
+    if (!IS_ENABLED(CONFIG_DEBUG_VM))
+    return all_online;
+
+    for_each_memblock(memory, mblk) {
+    pfn = PHYS_PFN(mblk->base);
+    end_pfn = PHYS_PFN(mblk->base + mblk->size);
+


It's not a good idea to access @mblk->{base, size}. There are two
accessors: memblock_region_memory_{base, end}_pfn().


Sure, will replace.




+    for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+    ms = __pfn_to_section(pfn);
+
+    /*
+ * All memory ranges in the system at this point
+ * should have been marked early sections.
+ */
+    WARN_ON(!early_section(ms));
+
+    /*
+ * Memory notifier mechanism here to prevent boot
+ * memory offlining depends on the fact that each
+ * early section memory on the system is intially
+ * online. Otherwise a given memory section which
+ * is already offline will be overlooked and can
+ * be removed completely. Call out such sections.
+ */


s/intially/initially


Will change.




+    if (!online_section(ms)) {
+    start = PFN_PHYS(pfn);
+    end = start + (1UL << PA_SECTION_SHIFT);
+    pr_err("Memory range [%lx %lx] is offline\n", start, end);
+    pr_err("Memory range [%lx %lx] can be removed\n", start, end);
+    all_online = false;


These two error messages can be combined:

     pr_err("Memory range [%lx %lx] not online, can't be offlined\n",
    start, end);


Will change but it is actually s/can't be offlined/can be removed/ instead.



I think you need to return @all_online immediately, without
checking if the subsequent sections are online or not? :)


Thinking about this again. It might be better if the notifier registration
does not depend on return value from validate_bootmem_online(). Instead it
should proceed either way but after calling out all boot memory sections
that are not online. In that case notifier will atleast prevent

Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

2020-10-11 Thread Willy Tarreau

Hi Enric,

On Sun, Oct 11, 2020 at 07:05:55PM +0200, Enric Balletbo i Serra wrote:
> For arm64 (i.e : arm64_defconfig):
> 1. Someone renames CONFIG_A to CONFIG_AB, sends a patch, and as he did a
> grep, the patch modifies all the defconfigs.
> 2. The patch is accepted and merged in linux-next.
> 3. KernelCI builds linux-next, boots the kernel on the hardware and all 
> the
> tests continue passing.
> 
> 
> For x86:
> 1. Someone renames CONFIG_A to CONFIG_AB, sends a patch and as he did a 
> grep
> the patches modifies all the defconfigs.
> 2. The patch is accepted and merged in linux-next.
> 3. KernelCI builds linux-next, boots the kernel on the hardware, and some
> tests start to fail or are skipped.
> 4. The maintainer is noticed about the behavior change, so he will need to
> look at the problem, and find it.
> 5. The maintainer sends a patch.
> 6. The patch is accepted, but he needs to tag the release as per kernel <
> x.y.z version it should use CONFIG_A and for kernel > x.y.z it should pick
> CONFIG_AB.
> 7. KernelCI builds linux-next, boots the kernel on the hardware and all 
> the
> tests pass again.

Previously I thought I understood your needs, but now I don't anymore. You
seem to be saying that you're not testing *anything* outside of defconfig,
and that as such you'd like defconfig to be complete enough to provide good
coverage. This sounds a bit odd to me. And what if in the arm64 case, the
CONFIG_YOUR_V4L2_DEVICE is *not* added to defconfig ? You're in the same
situation.

We all know it's not fun to have to deal with local config snippets, but
as soon as you plan to boot on a specific hardware, this is unavoidable.
Also, config symbols are rarely renamed. Most often they are moved under
new entries (e.g. CONFIG_VENDOR_FOO) which are enabled by default, so
that updating your old configuration using "make olddefconfig" is enough
to update it.

What I'm understanding from your proposed change is not to support
KernelCI, but to support Chromebooks by default. This could make more
sense if that's a relevant platform whose support is currently limited
by default, I'm not able to judge that, but at least it seems to me
this would make more sense than having specific configs for KernelCI.

Just my 2 cents,
Willy

[PATCH] sh: Remove unused HAVE_COPY_THREAD_TLS macro

2020-10-11 Thread Jinyang He

Fixes:  e1cc9d8d596e ("sh: switch to copy_thread_tls()")
Signed-off-by: Jinyang He 
---
 arch/sh/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index d209271..165f291 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -30,7 +30,6 @@ config SUPERH
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
-   select HAVE_COPY_THREAD_TLS
select HAVE_DEBUG_BUGVERBOSE
select HAVE_DEBUG_KMEMLEAK
select HAVE_DYNAMIC_FTRACE
-- 
2.1.0

Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver

2020-10-11 Thread Jason Wang




On 2020/10/12 上午10:45, Jie Deng wrote:



On 2020/10/10 11:14, Jason Wang wrote:



+
+    virtqueue_kick(vq);
+
+    time_left = wait_for_completion_timeout(>completion, 
adap->timeout);

+    if (!time_left) {
+    dev_err(>dev, "msg[%d]: addr=0x%x timeout.\n", i, 
msgs[i].addr);

+    break;
+    }



You don't set error number here. Is this intended?

And using a timeout here is not good, and if the request is finished 
just after the timeout, in the next xfer you may hit the following 
check.


It's better to use either interrupt here.

Could you check the I2C drivers in the kernel ? The 
"wait_for_completion_timeout" mechanism

is commonly used by I2C bus drivers in their i2c_algorithm.master_xfer.



There's a major difference between virtio-i2c and other drivers. In the 
case of virtio, the device could be a software device emulated by a 
remote process. This means the timeout might not be rare.


I don't see how timeout is properly handled in this patch (e.g did you 
notice that you don't set any error when timeout? or is this intended?)








+
+    vmsg = (struct virtio_i2c_msg *)virtqueue_get_buf(vq, );
+    /* vmsg should point to the same address with >vmsg */
+    if ((!vmsg) || (vmsg != >vmsg)) {
+    dev_err(>dev, "msg[%d]: addr=0x%x virtqueue 
error.\n",

+    i, msgs[i].addr);
+    break;
+    }



So I think we can remove this check. Consider only one descriptor 
will be used at most, unless there's a bug in the device (and no 
other driver to the similar check), we should not hit this.


Btw, as I replied in the previous version, the device should be 
cacpable of dealing of a batch of requests through the virtqueue, 
otherwise it's meaningless to use a queue here.


We should not assume there is no bug in the device. I don't think we 
can remove this check if we want our code to be robust.



Can you tell when at which case you may hit !vmsg or vmsg != vi->vmsg?



As I said, currently, we are using the virtqueue to send the msg one 
by one to the backend. The mechanism is described in the spec. 



Which part of the spec describes such "one by one" mechanism? If there 
is one, I'd happily give a NACK since it doesn't require a queue to work 
which is conflict with the concept of the virtqueue.




Thanks.





+

+
+#ifndef _UAPI_LINUX_VIRTIO_I2C_H
+#define _UAPI_LINUX_VIRTIO_I2C_H
+
+#include 
+#include 
+#include 
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+    __le16 addr;
+    __le16 flags;
+    __le16 len;
+};



I'm afraid this is not complete. E.g the status is missed.

I suspect what virtio-scsi use is better. Which split the in from the 
out instead of reusing the same buffer. And it can ease the uAPI 
header export.


Thanks




I think following definition in uAPI for the status is enough.
There is no need to provide a "u8" status in the structure.

/* The final status written by the device */
#define VIRTIO_I2C_MSG_OK    0
#define VIRTIO_I2C_MSG_ERR    1

You can see an example in virtio_blk.

In the spec:

struct virtio_blk_req {
le32 type;
le32 reserved;
le64 sector;
u8 data[];
u8 status;
};

In virtio_blk.h, there is only following definitions.

#define VIRTIO_BLK_S_OK        0
#define VIRTIO_BLK_S_IOERR    1
#define VIRTIO_BLK_S_UNSUPP    2



virtio-blk is a bad example, it's just too late to fix. For any new 
introduced uAPI it should be a complete one.


Thanks



Thanks.

Re: [PATCH v5 4/4] mmc: mediatek: Add subsys clock control for MT8192 msdc

2020-10-11 Thread Nicolas Boichat

Thanks for the quick turnaround.

And sorry, I should have noticed these issues in my previous pass.

On Mon, Oct 12, 2020 at 10:44 AM Wenbin Mei  wrote:
>
> MT8192 msdc is an independent sub system, we need control more bus
> clocks for it.
> Add support for the additional subsys clocks to allow it to be
> configured appropriately.
>
> Signed-off-by: Wenbin Mei 
> ---
>  drivers/mmc/host/mtk-sd.c | 74 +--
>  1 file changed, 56 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index a704745e5882..41703e6d6b17 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -35,6 +35,7 @@
>  #include "cqhci.h"
>
>  #define MAX_BD_NUM  1024
> +#define MSDC_NR_CLOCKS  3
>
>  
> /*--*/
>  /* Common Definition
> */
> @@ -425,6 +426,8 @@ struct msdc_host {
> struct clk *h_clk;  /* msdc h_clk */
> struct clk *bus_clk;/* bus clock which used to access register */
> struct clk *src_clk_cg; /* msdc source clock control gate */
> +   struct clk *sys_clk_cg; /* msdc subsys clock control gate */
> +   struct clk_bulk_data bulk_clks[MSDC_NR_CLOCKS];
> u32 mclk;   /* mmc subsystem clock frequency */
> u32 src_clk_freq;   /* source clock frequency */
> unsigned char timing;
> @@ -784,6 +787,7 @@ static void msdc_set_busy_timeout(struct msdc_host *host, 
> u64 ns, u64 clks)
>
>  static void msdc_gate_clock(struct msdc_host *host)
>  {
> +   clk_bulk_disable_unprepare(MSDC_NR_CLOCKS, host->bulk_clks);
> clk_disable_unprepare(host->src_clk_cg);
> clk_disable_unprepare(host->src_clk);
> clk_disable_unprepare(host->bus_clk);
> @@ -792,10 +796,18 @@ static void msdc_gate_clock(struct msdc_host *host)
>
>  static void msdc_ungate_clock(struct msdc_host *host)
>  {
> +   int ret;
> +
> clk_prepare_enable(host->h_clk);
> clk_prepare_enable(host->bus_clk);
> clk_prepare_enable(host->src_clk);
> clk_prepare_enable(host->src_clk_cg);
> +   ret = clk_bulk_prepare_enable(MSDC_NR_CLOCKS, host->bulk_clks);
> +   if (ret) {
> +   dev_err(host->dev, "Cannot enable pclk/axi/ahb clock 
> gates\n");
> +   return;
> +   }

It's a bit odd that we only care about the last 3 clocks... Should we
return early if any of the clocks can't be enabled? Changing the
behaviour for the other clocks should be in another patch though.

> +
> while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
> cpu_relax();
>  }
> @@ -2366,6 +2378,48 @@ static void msdc_of_property_parse(struct 
> platform_device *pdev,
> host->cqhci = false;
>  }
>
> +static int msdc_of_clock_parse(struct platform_device *pdev,
> +  struct msdc_host *host)
> +{
> +   int ret;
> +
> +   host->src_clk = devm_clk_get_optional(>dev, "source");

I think you want devm_clk_get, as the previous version of the code
does not make this clock optional.

> +   if (IS_ERR(host->src_clk))
> +   return PTR_ERR(host->src_clk);
> +
> +   host->h_clk = devm_clk_get_optional(>dev, "hclk");

ditto, devm_clk_get

> +   if (IS_ERR(host->h_clk))
> +   return PTR_ERR(host->h_clk);
> +
> +   host->bus_clk = devm_clk_get_optional(>dev, "bus_clk");
> +   if (IS_ERR(host->bus_clk))
> +   host->bus_clk = NULL;

This is consistent with previous behaviour, but this looks wrong. If
the clock exists (!= NULL return value), but you get an error, you
should return that error. This belongs in another patch though.

> +
> +   /*source clock control gate is optional clock*/
> +   host->src_clk_cg = devm_clk_get_optional(>dev, "source_cg");
> +   if (IS_ERR(host->src_clk_cg))
> +   host->src_clk_cg = NULL;
> +
> +   host->sys_clk_cg = devm_clk_get_optional(>dev, "sys_cg");
> +   if (IS_ERR(host->sys_clk_cg))
> +   host->sys_clk_cg = NULL;
> +
> +   /* If present, always enable for this clock gate */
> +   clk_prepare_enable(host->sys_clk_cg);
> +
> +   host->bulk_clks[0].id = "pclk_cg";
> +   host->bulk_clks[1].id = "axi_cg";
> +   host->bulk_clks[2].id = "ahb_cg";
> +   ret = devm_clk_bulk_get_optional(>dev, MSDC_NR_CLOCKS,
> +host->bulk_clks);
> +   if (ret) {
> +   dev_err(>dev, "Cannot get pclk/axi/ahb clock gates\n");
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
>  static int msdc_drv_probe(struct platform_device *pdev)
>  {
> struct mmc_host *mmc;
> @@ -2405,25 +2459,9 @@ static int msdc_drv_probe(struct platform_device *pdev)
> if (ret)
> goto host_free;
>
> -   host->src_clk =

Re: [PATCH FIX v0] mm: memcg/slab: Uncharge during kmem_cache_free_bulk()

2020-10-11 Thread Bharata B Rao

On Fri, Oct 09, 2020 at 11:45:51AM -0700, Roman Gushchin wrote:
> On Fri, Oct 09, 2020 at 11:34:23AM +0530, Bharata B Rao wrote:
> 
> Hi Bharata,
> 
> > Object cgroup charging is done for all the objects during
> > allocation, but during freeing, uncharging ends up happening
> > for only one object in the case of bulk allocation/freeing.
> 
> Yes, it's definitely a problem. Thank you for catching it!
> 
> I'm curious, did you find it in the wild or by looking into the code?

Found by looking at the code.

> 
> > 
> > Fix this by having a separate call to uncharge all the
> > objects from kmem_cache_free_bulk() and by modifying
> > memcg_slab_free_hook() to take care of bulk uncharging.
> >
> > Signed-off-by: Bharata B Rao 
> 
> Please, add:
> 
> Fixes: 964d4bd370d5 ("mm: memcg/slab: save obj_cgroup for non-root slab 
> objects")
> Cc: sta...@vger.kernel.org
> 
> > ---
> >  mm/slab.c |  2 +-
> >  mm/slab.h | 42 +++---
> >  mm/slub.c |  3 ++-
> >  3 files changed, 30 insertions(+), 17 deletions(-)
> > 
> > diff --git a/mm/slab.c b/mm/slab.c
> > index f658e86ec8cee..5c70600d8b1cc 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -3440,7 +3440,7 @@ void ___cache_free(struct kmem_cache *cachep, void 
> > *objp,
> > memset(objp, 0, cachep->object_size);
> > kmemleak_free_recursive(objp, cachep->flags);
> > objp = cache_free_debugcheck(cachep, objp, caller);
> > -   memcg_slab_free_hook(cachep, virt_to_head_page(objp), objp);
> > +   memcg_slab_free_hook(cachep, , 1);
> >  
> > /*
> >  * Skip calling cache_free_alien() when the platform is not numa.
> > diff --git a/mm/slab.h b/mm/slab.h
> > index 6cc323f1313af..6dd4b702888a7 100644
> > --- a/mm/slab.h
> > +++ b/mm/slab.h
> > @@ -345,30 +345,42 @@ static inline void memcg_slab_post_alloc_hook(struct 
> > kmem_cache *s,
> > obj_cgroup_put(objcg);
> >  }
> >  
> > -static inline void memcg_slab_free_hook(struct kmem_cache *s, struct page 
> > *page,
> > -   void *p)
> > +static inline void memcg_slab_free_hook(struct kmem_cache *s_orig,
> > +   void **p, int objects)
> >  {
> > +   struct kmem_cache *s;
> > struct obj_cgroup *objcg;
> > +   struct page *page;
> > unsigned int off;
> > +   int i;
> >  
> > if (!memcg_kmem_enabled())
> > return;
> >  
> > -   if (!page_has_obj_cgroups(page))
> > -   return;
> > +   for (i = 0; i < objects; i++) {
> > +   if (unlikely(!p[i]))
> > +   continue;
> >  
> > -   off = obj_to_index(s, page, p);
> > -   objcg = page_obj_cgroups(page)[off];
> > -   page_obj_cgroups(page)[off] = NULL;
> > +   page = virt_to_head_page(p[i]);
> > +   if (!page_has_obj_cgroups(page))
> > +   continue;
> >  
> > -   if (!objcg)
> > -   return;
> > +   if (!s_orig)
> > +   s = page->slab_cache;
> > +   else
> > +   s = s_orig;
> >  
> > -   obj_cgroup_uncharge(objcg, obj_full_size(s));
> > -   mod_objcg_state(objcg, page_pgdat(page), cache_vmstat_idx(s),
> > -   -obj_full_size(s));
> > +   off = obj_to_index(s, page, p[i]);
> > +   objcg = page_obj_cgroups(page)[off];
> > +   if (!objcg)
> > +   continue;
> >  
> > -   obj_cgroup_put(objcg);
> > +   page_obj_cgroups(page)[off] = NULL;
> > +   obj_cgroup_uncharge(objcg, obj_full_size(s));
> > +   mod_objcg_state(objcg, page_pgdat(page), cache_vmstat_idx(s),
> > +   -obj_full_size(s));
> > +   obj_cgroup_put(objcg);
> > +   }
> >  }
> >  
> >  #else /* CONFIG_MEMCG_KMEM */
> > @@ -406,8 +418,8 @@ static inline void memcg_slab_post_alloc_hook(struct 
> > kmem_cache *s,
> >  {
> >  }
> >  
> > -static inline void memcg_slab_free_hook(struct kmem_cache *s, struct page 
> > *page,
> > -   void *p)
> > +static inline void memcg_slab_free_hook(struct kmem_cache *s,
> > +   void **p, int objects)
> >  {
> >  }
> >  #endif /* CONFIG_MEMCG_KMEM */
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 6d3574013b2f8..0cbe67f13946e 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -3091,7 +3091,7 @@ static __always_inline void do_slab_free(struct 
> > kmem_cache *s,
> > struct kmem_cache_cpu *c;
> > unsigned long tid;
> >  
> > -   memcg_slab_free_hook(s, page, head);
> > +   memcg_slab_free_hook(s, , 1);
> 
> Hm, I wonder if it's better to teach do_slab_free() to handle the (cnt > 1) 
> case correctly?

Possible, but we will have to walk the detached freelist there while
here it is much easier to just walk the array of objects?

> 
> >  redo:
> > /*
> >  * Determine the currently cpus per cpu slab.
> > @@ -3253,6 +3253,7 @@ void kmem_cache_free_bulk(struct kmem_cache *s, 
> > size_t size, void **p)
> > if (WARN_ON(!size))
> >

[RESEND v4 2/2] KVM: VMX: Enable bus lock VM exit

2020-10-11 Thread Chenyi Qiang

Virtual Machine can exploit bus locks to degrade the performance of
system. Bus lock can be caused by split locked access to writeback(WB)
memory or by using locks on uncacheable(UC) memory. The bus lock is
typically >1000 cycles slower than an atomic operation within a cache
line. It also disrupts performance on other cores (which must wait for
the bus lock to be released before their memory operations can
complete).

To address the threat, bus lock VM exit is introduced to notify the VMM
when a bus lock was acquired, allowing it to enforce throttling or other
policy based mitigations.

A VMM can enable VM exit due to bus locks by setting a new "Bus Lock
Detection" VM-execution control(bit 30 of Secondary Processor-based VM
execution controls). If delivery of this VM exit was preempted by a
higher priority VM exit (e.g. EPT misconfiguration, EPT violation, APIC
access VM exit, APIC write VM exit, exception bitmap exiting), bit 26 of
exit reason in vmcs field is set to 1.

In current implementation, the KVM exposes this capability through
KVM_CAP_X86_BUS_LOCK_EXIT. The user can get the supported mode bitmap
(i.e. off and exit) and enable it explicitly (disabled by default). If
bus locks in guest are detected by KVM, exit to user space even when
current exit reason is handled by KVM internally. Set a new field
KVM_RUN_BUS_LOCK in vcpu->run->flags to inform the user space that there
is a bus lock in guest and it is preempted by a higher prioriy VM exit.

Document for Bus Lock VM exit is now available at the latest "Intel
Architecture Instruction Set Extensions Programming Reference".

Document Link:
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Co-developed-by: Xiaoyao Li 
Signed-off-by: Xiaoyao Li 
Signed-off-by: Chenyi Qiang 
---
 arch/x86/include/asm/kvm_host.h|  7 ++
 arch/x86/include/asm/vmx.h |  1 +
 arch/x86/include/asm/vmxfeatures.h |  1 +
 arch/x86/include/uapi/asm/kvm.h|  1 +
 arch/x86/include/uapi/asm/vmx.h|  4 +++-
 arch/x86/kvm/vmx/capabilities.h|  6 +
 arch/x86/kvm/vmx/vmx.c | 37 --
 arch/x86/kvm/vmx/vmx.h |  2 +-
 arch/x86/kvm/x86.c | 29 ++-
 include/uapi/linux/kvm.h   |  5 
 10 files changed, 88 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 5303dbc5c9bc..f5dd88553d19 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -52,6 +52,9 @@
 #define KVM_DIRTY_LOG_MANUAL_CAPS   (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
KVM_DIRTY_LOG_INITIALLY_SET)
 
+#define KVM_BUS_LOCK_DETECTION_VALID_MODE  (KVM_BUS_LOCK_DETECTION_OFF | \
+KVM_BUS_LOCK_DETECTION_EXIT)
+
 /* x86-specific vcpu->requests bit members */
 #define KVM_REQ_MIGRATE_TIMER  KVM_ARCH_REQ(0)
 #define KVM_REQ_REPORT_TPR_ACCESS  KVM_ARCH_REQ(1)
@@ -961,6 +964,8 @@ struct kvm_arch {
bool guest_can_read_msr_platform_info;
bool exception_payload_enabled;
 
+   bool bus_lock_detection_enabled;
+
struct kvm_pmu_event_filter *pmu_event_filter;
struct task_struct *nx_lpage_recovery_thread;
 };
@@ -1347,6 +1352,8 @@ extern u8   kvm_tsc_scaling_ratio_frac_bits;
 extern u64  kvm_max_tsc_scaling_ratio;
 /* 1ull << kvm_tsc_scaling_ratio_frac_bits */
 extern u64  kvm_default_tsc_scaling_ratio;
+/* bus lock detection supported? */
+extern bool kvm_has_bus_lock_exit;
 
 extern u64 kvm_mce_cap_supported;
 
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index cd7de4b401fe..93a880bc31a7 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -73,6 +73,7 @@
 #define SECONDARY_EXEC_PT_USE_GPA  VMCS_CONTROL_BIT(PT_USE_GPA)
 #define SECONDARY_EXEC_TSC_SCALING  VMCS_CONTROL_BIT(TSC_SCALING)
 #define SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE   VMCS_CONTROL_BIT(USR_WAIT_PAUSE)
+#define SECONDARY_EXEC_BUS_LOCK_DETECTION  
VMCS_CONTROL_BIT(BUS_LOCK_DETECTION)
 
 #define PIN_BASED_EXT_INTR_MASK VMCS_CONTROL_BIT(INTR_EXITING)
 #define PIN_BASED_NMI_EXITING   VMCS_CONTROL_BIT(NMI_EXITING)
diff --git a/arch/x86/include/asm/vmxfeatures.h 
b/arch/x86/include/asm/vmxfeatures.h
index 9915990fd8cf..e80523346274 100644
--- a/arch/x86/include/asm/vmxfeatures.h
+++ b/arch/x86/include/asm/vmxfeatures.h
@@ -83,5 +83,6 @@
 #define VMX_FEATURE_TSC_SCALING( 2*32+ 25) /* Scale hardware 
TSC when read in guest */
 #define VMX_FEATURE_USR_WAIT_PAUSE ( 2*32+ 26) /* Enable TPAUSE, UMONITOR, 
UMWAIT in guest */
 #define VMX_FEATURE_ENCLV_EXITING  ( 2*32+ 28) /* "" VM-Exit on ENCLV 
(leaf dependent) */
+#define VMX_FEATURE_BUS_LOCK_DETECTION ( 2*32+ 30) /* VM-Exit when bus lock 
caused */
 
 #endif /*

[V2 PATCH 0/3] Fix the memory layout and add sgpio node for aspeed g6

This patch series is used to add sgpiom and sgpios nodes and add pinctrl 
setting for sgpiom1

v2:
  - Split the change of dts and pinctrl to two commit.
  - Add the compatible string for aspeed,ast2600-sgpiom. 
aspeed,ast2600-sgpios will implement in the future.

Billy Tsai (3):
  Arm: dts: aspeed-g6: Fix the register range of gpio
  Arm: dts: aspeed-g6: Add sgpio node
  pinctrl: aspeed-g6: Add sgpiom2 pinctrl setting

 .../devicetree/bindings/gpio/sgpio-aspeed.txt |  8 +--
 arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi  |  5 ++
 arch/arm/boot/dts/aspeed-g6.dtsi  | 54 ++-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c| 30 +--
 4 files changed, 89 insertions(+), 8 deletions(-)

-- 
2.17.1

[RESEND v4 1/2] KVM: VMX: Convert vcpu_vmx.exit_reason to a union

2020-10-11 Thread Chenyi Qiang

From: Sean Christopherson 

Convert vcpu_vmx.exit_reason from a u32 to a union (of size u32).  The
full VM_EXIT_REASON field is comprised of a 16-bit basic exit reason in
bits 15:0, and single-bit modifiers in bits 31:16.

Historically, KVM has only had to worry about handling the "failed
VM-Entry" modifier, which could only be set in very specific flows and
required dedicated handling.  I.e. manually stripping the FAILED_VMENTRY
bit was a somewhat viable approach.  But even with only a single bit to
worry about, KVM has had several bugs related to comparing a basic exit
reason against the full exit reason store in vcpu_vmx.

Upcoming Intel features, e.g. SGX, will add new modifier bits that can
be set on more or less any VM-Exit, as opposed to the significantly more
restricted FAILED_VMENTRY, i.e. correctly handling everything in one-off
flows isn't scalable.  Tracking exit reason in a union forces code to
explicitly choose between consuming the full exit reason and the basic
exit, and is a convenient way to document and access the modifiers.

No functional change intended.

Cc: Xiaoyao Li 
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 42 -
 arch/x86/kvm/vmx/vmx.c| 66 ---
 arch/x86/kvm/vmx/vmx.h| 25 ++-
 3 files changed, 85 insertions(+), 48 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 1bb6b31eb646..370c414e333c 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -3304,7 +3304,11 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
enum vm_entry_failure_code entry_failure_code;
bool evaluate_pending_interrupts;
-   u32 exit_reason, failed_index;
+   union vmx_exit_reason exit_reason = {
+   .basic = EXIT_REASON_INVALID_STATE,
+   .failed_vmentry = 1,
+   };
+   u32 failed_index;
 
if (kvm_check_request(KVM_REQ_TLB_FLUSH_CURRENT, vcpu))
kvm_vcpu_flush_tlb_current(vcpu);
@@ -3354,7 +3358,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
 
if (nested_vmx_check_guest_state(vcpu, vmcs12,
 _failure_code)) {
-   exit_reason = EXIT_REASON_INVALID_STATE;
+   exit_reason.basic = EXIT_REASON_INVALID_STATE;
vmcs12->exit_qualification = entry_failure_code;
goto vmentry_fail_vmexit;
}
@@ -3365,7 +3369,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
vcpu->arch.tsc_offset += vmcs12->tsc_offset;
 
if (prepare_vmcs02(vcpu, vmcs12, _failure_code)) {
-   exit_reason = EXIT_REASON_INVALID_STATE;
+   exit_reason.basic = EXIT_REASON_INVALID_STATE;
vmcs12->exit_qualification = entry_failure_code;
goto vmentry_fail_vmexit_guest_mode;
}
@@ -3375,7 +3379,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
   
vmcs12->vm_entry_msr_load_addr,
   
vmcs12->vm_entry_msr_load_count);
if (failed_index) {
-   exit_reason = EXIT_REASON_MSR_LOAD_FAIL;
+   exit_reason.basic = EXIT_REASON_MSR_LOAD_FAIL;
vmcs12->exit_qualification = failed_index;
goto vmentry_fail_vmexit_guest_mode;
}
@@ -3443,7 +3447,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
return NVMX_VMENTRY_VMEXIT;
 
load_vmcs12_host_state(vcpu, vmcs12);
-   vmcs12->vm_exit_reason = exit_reason | VMX_EXIT_REASONS_FAILED_VMENTRY;
+   vmcs12->vm_exit_reason = exit_reason.full;
if (enable_shadow_vmcs || vmx->nested.hv_evmcs)
vmx->nested.need_vmcs12_to_shadow_sync = true;
return NVMX_VMENTRY_VMEXIT;
@@ -5496,7 +5500,12 @@ static int handle_vmfunc(struct kvm_vcpu *vcpu)
return kvm_skip_emulated_instruction(vcpu);
 
 fail:
-   nested_vmx_vmexit(vcpu, vmx->exit_reason,
+   /*
+* This is effectively a reflected VM-Exit, as opposed to a synthesized
+* nested VM-Exit.  Pass the original exit reason, i.e. don't hardcode
+* EXIT_REASON_VMFUNC as the exit reason.
+*/
+   nested_vmx_vmexit(vcpu, vmx->exit_reason.full,
  vmx_get_intr_info(vcpu),
  vmx_get_exit_qual(vcpu));
return 1;
@@ -5564,7 +5573,8 @@ static bool nested_vmx_exit_handled_io(struct kvm_vcpu 
*vcpu,
  * MSR bitmap. This may be the case even when L0 doesn't use MSR bitmaps.
  */
 static bool nested_vmx_exit_handled_msr(struct kvm_vcpu

[RESEND v4 0/2] Add bus lock VM exit support

2020-10-11 Thread Chenyi Qiang

This patch series add the support for bus lock VM exit in KVM. It is a
sub-feature of bus lock detection. When it is enabled by the VMM, the
processor generates a "Bus Lock" VM exit following execution of an
instruction if the processor detects that one or more bus locks were
caused the instruction was being executed (due to either direct access
by the instruction or stuffed accesses like through A/D updates).

This first patch applies Sean's refactor for vcpu_vmx.exit_reason
available at https://patchwork.kernel.org/patch/11500659.
It is necessary as bus lock VM exit adds a new modifier bit(bit 26) in
exit_reason field in VMCS.

The second patch is the enabling work for bus lock VM exit. Add the
support to set the capability to enable bus lock vm exit. The current
implementation just exit to user space when handling the bus lock
detected in guest.

The concrete throttling policy in user space is still to be discussed.
We can enforce ratelimit on bus lock in guest, inject some sleep time or
maybe other ideas.

Document for Bus Lock Detection is now available at the latest "Intel
Architecture Instruction Set Extensions Programming Reference".

Document Link:
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

---

Changelogs

v3->v4:
- rebase on top of v5.9
- some code cleanup.
- v3:https://lore.kernel.org/lkml/20200910083751.26686-1-chenyi.qi...@intel.com/

v2->v3:
- use a bitmap to get/set the capability of bus lock detection. we support
exit and off mode currently.
- put the handle of exiting to userspace in vmx.c, thus no need to
define a shadow to track vmx->exit_reason.bus_lock_detected.
- remove the vcpu->stats.bus_locks since every bus lock exits to userspace.
- v2:https://lore.kernel.org/lkml/20200817033604.5836-1-chenyi.qi...@intel.com/

v1->v2:
- resolve Vitaly's comment to introduce the KVM_EXIT_BUS_LOCK and a
capability to enable it.
- add the support to exit to user space when handling bus locks.
- extend the vcpu->run->flags to indicate bus lock detected for other
exit reasons when exiting to user space.
- v1:https://lore.kernel.org/lkml/20200628085341.5107-1-chenyi.qi...@intel.com/

---

Chenyi Qiang (1):
KVM: VMX: Enable bus lock VM exit

Sean Christopherson (1):
KVM: VMX: Convert vcpu_vmx.exit_reason to a union

--
2.17.1

[PATCH 2/3] Arm: dts: aspeed-g6: Add sgpio node

This patch is used to add sgpiom and sgpios nodes and add compatiable
string for sgpiom.

Signed-off-by: Billy Tsai 
---
 .../devicetree/bindings/gpio/sgpio-aspeed.txt |  8 +--
 arch/arm/boot/dts/aspeed-g6.dtsi  | 52 +++
 2 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt 
b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
index d4d83916c09d..815d9b5167a5 100644
--- a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
+++ b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
@@ -1,8 +1,10 @@
 Aspeed SGPIO controller Device Tree Bindings
 
 
-This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full
-featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to
+This SGPIO controller is for ASPEED AST2500/AST2600 SoC, it supports 2 master.
+One is up to 128 SGPIO input ports and 128 output ports concurrently(after 
AST2600A1)
+and Second one is up to 80.
+Each of the Serial GPIO pins can be programmed to
 support the following options:
 - Support interrupt option for each input port and various interrupt
   sensitivity option (level-high, level-low, edge-high, edge-low)
@@ -14,7 +16,7 @@ support the following options:
 Required properties:
 
 - compatible : Should be one of
-  "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio"
+  "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio", "aspeed,ast2600-sgpiom"
 - #gpio-cells : Should be 2, see gpio.txt
 - reg : Address and length of the register set for the device
 - gpio-controller : Marks the device node as a GPIO controller
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index ad19dce038ea..cb053a996e87 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -366,6 +366,58 @@
#interrupt-cells = <2>;
};
 
+   sgpiom0: sgpiom@1e780500 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpiom";
+   reg = <0x1e780500 0x100>;
+   interrupts = ;
+   ngpios = <128>;
+   clocks = < ASPEED_CLK_APB2>;
+   interrupt-controller;
+   bus-frequency = <1200>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_sgpm1_default>;
+   status = "disabled";
+   };
+
+   sgpiom1: sgpiom@1e780600 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpiom";
+   reg = <0x1e780600 0x100>;
+   interrupts = ;
+   ngpios = <80>;
+   clocks = < ASPEED_CLK_APB2>;
+   interrupt-controller;
+   bus-frequency = <1200>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_sgpm2_default>;
+   status = "disabled";
+   };
+
+   sgpios0: sgpios@1e780700 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpios";
+   reg = <0x1e780700 0x40>;
+   interrupts = ;
+   clocks = < ASPEED_CLK_APB2>;
+   status = "disabled";
+   };
+
+   sgpios1: sgpios@1e780740 {
+   #gpio-cells = <2>;
+   gpio-controller;
+   compatible = "aspeed,ast2600-sgpios";
+   reg = <0x1e780740 0x40>;
+   interrupts = ;
+   clocks = < ASPEED_CLK_APB2>;
+   status = "disabled";
+   };
+
gpio1: gpio@1e780800 {
#gpio-cells = <2>;
gpio-controller;
-- 
2.17.1

[PATCH 1/3] Arm: dts: aspeed-g6: Fix the register range of gpio

This patch is used to fix the memory range of gpio0

Signed-off-by: Billy Tsai 
---
 arch/arm/boot/dts/aspeed-g6.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index 97ca743363d7..ad19dce038ea 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -357,7 +357,7 @@
#gpio-cells = <2>;
gpio-controller;
compatible = "aspeed,ast2600-gpio";
-   reg = <0x1e78 0x800>;
+   reg = <0x1e78 0x400>;
interrupts = ;
gpio-ranges = < 0 0 208>;
ngpios = <208>;
-- 
2.17.1

[PATCH 3/3] pinctrl: aspeed-g6: Add sgpiom2 pinctrl setting

At ast2600a1 we change feature of master sgpio to 2 sets.
So this patch is used to add the pinctrl setting of the new sgpio.

Signed-off-by: Billy Tsai 
---
 arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi   |  5 
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 30 +++---
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi 
b/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi
index 7028e21bdd98..a16ecf08e307 100644
--- a/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6-pinctrl.dtsi
@@ -862,6 +862,11 @@
groups = "SGPM1";
};
 
+   pinctrl_sgpm2_default: sgpm2_default {
+   function = "SGPM2";
+   groups = "SGPM2";
+   };
+
pinctrl_sgps1_default: sgps1_default {
function = "SGPS1";
groups = "SGPS1";
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index 34803a6c7664..b673a44ffa3b 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -46,8 +46,10 @@
 #define SCU620 0x620 /* Disable GPIO Internal Pull-Down #4 */
 #define SCU634 0x634 /* Disable GPIO Internal Pull-Down #5 */
 #define SCU638 0x638 /* Disable GPIO Internal Pull-Down #6 */
+#define SCU690 0x690 /* Multi-function Pin Control #24 */
 #define SCU694 0x694 /* Multi-function Pin Control #25 */
 #define SCU69C 0x69C /* Multi-function Pin Control #27 */
+#define SCU6D0 0x6D0 /* Multi-function Pin Control #28 */
 #define SCUC20 0xC20 /* PCIE configuration Setting Control */
 
 #define ASPEED_G6_NR_PINS 256
@@ -81,13 +83,21 @@ FUNC_GROUP_DECL(I2C12, L26, K24);
 #define K26 4
 SIG_EXPR_LIST_DECL_SESG(K26, MACLINK1, MACLINK1, SIG_DESC_SET(SCU410, 4));
 SIG_EXPR_LIST_DECL_SESG(K26, SCL13, I2C13, SIG_DESC_SET(SCU4B0, 4));
-PIN_DECL_2(K26, GPIOA4, MACLINK1, SCL13);
+/*SGPM2 is A1 Only */
+SIG_EXPR_LIST_DECL_SESG(K26, SGPM2CLK, SGPM2, SIG_DESC_SET(SCU6D0, 4),
+ SIG_DESC_CLEAR(SCU410, 4), SIG_DESC_CLEAR(SCU4B0, 4),
+ SIG_DESC_CLEAR(SCU690, 4));
+PIN_DECL_3(K26, GPIOA4, SGPM2CLK, MACLINK1, SCL13);
 FUNC_GROUP_DECL(MACLINK1, K26);
 
 #define L24 5
 SIG_EXPR_LIST_DECL_SESG(L24, MACLINK2, MACLINK2, SIG_DESC_SET(SCU410, 5));
 SIG_EXPR_LIST_DECL_SESG(L24, SDA13, I2C13, SIG_DESC_SET(SCU4B0, 5));
-PIN_DECL_2(L24, GPIOA5, MACLINK2, SDA13);
+/*SGPM2 is A1 Only */
+SIG_EXPR_LIST_DECL_SESG(L24, SGPM2LD, SGPM2, SIG_DESC_SET(SCU6D0, 5),
+ SIG_DESC_CLEAR(SCU410, 5), SIG_DESC_CLEAR(SCU4B0, 5),
+ SIG_DESC_CLEAR(SCU690, 5));
+PIN_DECL_3(L24, GPIOA5, SGPM2LD, MACLINK2, SDA13);
 FUNC_GROUP_DECL(MACLINK2, L24);
 
 FUNC_GROUP_DECL(I2C13, K26, L24);
@@ -95,16 +105,26 @@ FUNC_GROUP_DECL(I2C13, K26, L24);
 #define L23 6
 SIG_EXPR_LIST_DECL_SESG(L23, MACLINK3, MACLINK3, SIG_DESC_SET(SCU410, 6));
 SIG_EXPR_LIST_DECL_SESG(L23, SCL14, I2C14, SIG_DESC_SET(SCU4B0, 6));
-PIN_DECL_2(L23, GPIOA6, MACLINK3, SCL14);
+/*SGPM2 is A1 Only */
+SIG_EXPR_LIST_DECL_SESG(L23, SGPM2O, SGPM2, SIG_DESC_SET(SCU6D0, 6),
+ SIG_DESC_CLEAR(SCU410, 6), SIG_DESC_CLEAR(SCU4B0, 6),
+ SIG_DESC_CLEAR(SCU690, 6));
+PIN_DECL_3(L23, GPIOA6, SGPM2O, MACLINK3, SCL14);
 FUNC_GROUP_DECL(MACLINK3, L23);
 
 #define K25 7
 SIG_EXPR_LIST_DECL_SESG(K25, MACLINK4, MACLINK4, SIG_DESC_SET(SCU410, 7));
 SIG_EXPR_LIST_DECL_SESG(K25, SDA14, I2C14, SIG_DESC_SET(SCU4B0, 7));
-PIN_DECL_2(K25, GPIOA7, MACLINK4, SDA14);
+/*SGPM2 is A1 Only */
+SIG_EXPR_LIST_DECL_SESG(K25, SGPM2I, SGPM2, SIG_DESC_SET(SCU6D0, 7),
+ SIG_DESC_CLEAR(SCU410, 7), SIG_DESC_CLEAR(SCU4B0, 7),
+ SIG_DESC_CLEAR(SCU690, 7));
+PIN_DECL_3(K25, GPIOA7, SGPM2I, MACLINK4, SDA14);
 FUNC_GROUP_DECL(MACLINK4, K25);
 
 FUNC_GROUP_DECL(I2C14, L23, K25);
+/*SGPM2 is A1 Only */
+FUNC_GROUP_DECL(SGPM2, K26, L24, L23, K25);
 
 #define J26 8
 SIG_EXPR_LIST_DECL_SESG(J26, SALT1, SALT1, SIG_DESC_SET(SCU410, 8));
@@ -2060,6 +2080,7 @@ static const struct aspeed_pin_group aspeed_g6_groups[] = 
{
ASPEED_PINCTRL_GROUP(EMMCG4),
ASPEED_PINCTRL_GROUP(EMMCG8),
ASPEED_PINCTRL_GROUP(SGPM1),
+   ASPEED_PINCTRL_GROUP(SGPM2),
ASPEED_PINCTRL_GROUP(SGPS1),
ASPEED_PINCTRL_GROUP(SIOONCTRL),
ASPEED_PINCTRL_GROUP(SIOPBI),
@@ -2276,6 +2297,7 @@ static const struct aspeed_pin_function 
aspeed_g6_functions[] = {
ASPEED_PINCTRL_FUNC(SD1),
ASPEED_PINCTRL_FUNC(SD2),
ASPEED_PINCTRL_FUNC(SGPM1),
+   ASPEED_PINCTRL_FUNC(SGPM2),
ASPEED_PINCTRL_FUNC(SGPS1),
ASPEED_PINCTRL_FUNC(SIOONCTRL),
ASPEED_PINCTRL_FUNC(SIOPBI),
-- 
2.17.1

[GIT PULL] Crypto Update for 5.10

2020-10-11 Thread Herbert Xu

Hi Linus:

API:

- Allow DRBG testing through user-space af_alg.
- Add tcrypt speed testing support for keyed hashes.
- Add type-safe init/exit hooks for ahash.

Algorithms:

- Mark arc4 as obsolete and pending for future removal.
- Mark anubis, khazad, sead and tea as obsolete.
- Improve boot-time xor benchmark.
- Add OSCCA SM2 asymmetric cipher algorithm and use it for integrity.

Drivers:

- Fixes and enhancement for XTS in caam.
- Add support for XIP8001B hwrng in xiphera-trng.
- Add RNG and hash support in sun8i-ce/sun8i-ss.
- Allow imx-rngc to be used by kernel entropy pool.
- Use crypto engine in omap-sham.
- Add support for Ingenic X1830 with ingenic.

The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:

  Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus 

for you to fetch changes up to 3093e7c16e12d729c325adb3c53dde7308cefbd8:

  X.509: Fix modular build of public_key_sm2 (2020-10-08 16:39:14 +1100)


Andrei Botila (10):
  crypto: caam/jr - add fallback for XTS with more than 8B IV
  crypto: caam/qi - add fallback for XTS with more than 8B IV
  crypto: caam/qi2 - add fallback for XTS with more than 8B IV
  crypto: caam/jr - add support for more XTS key lengths
  crypto: caam/qi - add support for more XTS key lengths
  crypto: caam/qi2 - add support for more XTS key lengths
  crypto: caam - add xts check for block length equal to zero
  crypto: caam/jr - add support for XTS with 16B IV
  crypto: caam/qi - add support for XTS with 16B IV
  crypto: caam/qi2 - add support for XTS with 16B IV

Andy Shevchenko (1):
  crypto: caam - use traditional error check pattern

Ard Biesheuvel (15):
  staging/rtl8192e: switch to RC4 library interface
  staging/rtl8192u: switch to RC4 library interface
  SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
  crypto: n2 - remove ecb(arc4) support
  crypto: bcm-iproc - remove ecb(arc4) support
  net: wireless: drop bogus CRYPTO_xxx Kconfig selects
  crypto: arc4 - mark ecb(arc4) skcipher as obsolete
  crypto: Kconfig - mark unused ciphers as obsolete
  crypto: arm/sha256-neon - avoid ADRL pseudo instruction
  crypto: arm/sha512-neon - avoid ADRL pseudo instruction
  crypto: arm/aes-neonbs - avoid hacks to prevent Thumb2 mode switches
  crypto: arm/aes-neonbs - avoid loading reorder argument on encryption
  crypto: arm/aes-neonbs - use typed init/exit routines for XTS
  crypto: xor - defer load time benchmark to a later time
  crypto: xor - use ktime for template benchmarking

Atte Tommiska (3):
  dt-bindings: vendor-prefixes: Add Xiphera vendor prefix
  dt-bindings: rng: add bindings for Xiphera XIP8001B hwrng
  hwrng: xiphera-trng: add support for XIP8001B hwrng

Christophe JAILLET (2):
  crypto: hifn_795x - switch from 'pci_' to 'dma_' API
  crypto: ixp4xx - Fix the size used in a 'dma_free_coherent()' call

Colin Ian King (1):
  crypto: chelsio - fix minor indentation issue

Corentin Labbe (18):
  crypto: proc - Removing some useless only space lines
  crypto: sun8i-ss - Add SS_START define
  crypto: sun8i-ss - Add support for the PRNG
  crypto: sun8i-ss - support hash algorithms
  crypto: sun8i-ss - fix a trivial typo
  crypto: sun8i-ss - Add more comment on some structures
  crypto: sun8i-ss - better debug printing
  crypto: sun8i-ce - handle endianness of t_common_ctl
  crypto: sun8i-ce - move iv data to request context
  crypto: sun8i-ce - split into prepare/run/unprepare
  crypto: sun8i-ce - handle different error registers
  crypto: sun8i-ce - rename has_t_dlen_in_bytes to cipher_t_dlen_in_bytes
  crypto: sun8i-ce - support hash algorithms
  crypto: sun8i-ce - Add stat_bytes debugfs
  crypto: sun8i-ce - Add support for the PRNG
  crypto: sun8i-ce - Add support for the TRNG
  crypto: sun8i-ce - fix comparison of integer expressions of different 
signedness
  crypto: sun8i-ss - fix comparison of integer expressions of different 
signedness

Dan Carpenter (1):
  crypto: sa2ul - Fix pm_runtime_get_sync() error checking

Daniel Jordan (1):
  padata: add another maintainer and another list

Denis Efremov (5):
  crypto: inside-secure - use kfree_sensitive()
  crypto: amlogic - use kfree_sensitive()
  crypto: sun8i-ce - use kfree_sensitive()
  crypto: sun8i-ss - use kfree_sensitive()
  crypto: sun8i-ss - remove redundant memzero_explicit()

Dominik Przychodni (1):
  crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA

Elena Petrova (1):
  crypto: af_alg - add extra parameters for DRBG interface

Fabio Estevam (1):
  crypto: arm/curve25519 - include 

George Acosta (1):
  crypto: cavium/nitrox - add an error message to

Re: [PATCH] x86: Fix x32 System V message queue syscalls

2020-10-11 Thread Jessica Clarke

On 12 Oct 2020, at 04:02, Andy Lutomirski  wrote:
> On Sun, Oct 11, 2020 at 6:48 PM Jessica Clarke  wrote:
>> 
>> POSIX specifies that the first field of the supplied msgp, namely mtype,
>> is a long, not a __kernel_long_t, and it's a user-defined struct due to
>> the variable-length mtext field so we can't even bend the spec and make
>> it a __kernel_long_t even if we wanted to. Thus we must use the compat
>> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
>> msgrcv respectively.
>> 
>> Due to erroneously including the first 4 bytes of mtext in the mtype
>> this would previously also cause non-zero msgtyp arguments for msgrcv to
>> search for the wrong messages, and if sharing message queues between x32
>> and non-x32 (i386 or x86_64) processes this would previously cause mtext
>> to "move" and, depending on the direction and ABI combination, lose the
>> first 4 bytes.
> 
> This has a few problems.
> 
> First, the 512-547 range is a legacy wart and we shouldn't extend it.
> I thought I had documented this, but I didn't -- oops.  Patch sent.
> The correct way to do this nowadays is to use the same number twice,
> once for x64 and once for x32.  If you try to do this and encounter
> problems with the build, please either fix them or let me know :)

Yeah, that makes more sense. Not sure what I was thinking; changing the
syscall number is clearly a breaking change that's a huge no-no (at
least without also providing old_msgsnd/msgrcv entries, but as
discussed at the end it's unlikely any userspace code actually wants
that behaviour).

> Second, since this is an ABI issue, can you please include a little
> test case that compiles for i386, x86_64 and x32, works correctly on
> all three with whatever patch you send, and fails on x32 without the
> patch?

Test is below. Only verified to break on x32 (and work on i386+amd64)
currently; once I have v2 built I will check all three give the
expected output (NB: for x32 that means only "PAY" should get printed
in the second case since the __kernel_long_t runs over into the start
of the message payload, whereas on the other two you should get the
full "PAYLOAD" since long == __kernel_long_t).

> Third, how does this interact with various libc implementations?
> msgsnd(2) and msgrcv(2) have glibc wrappers.  Have they never been
> tested on x32?

The wrappers aren't anything interesting, they just use SYSCALL_CANCEL
with either msgsnd or irc + IPCOP_msgsnd, so glibc doesn't care about
the struct layout one bit. Of course it does care about the syscall
numbers though...

As far as testing goes, well, I guess 4 byte buffer overflows just
don't get noticed that much. I noticed this not because of that, but
because someone was trying to get fakeroot to work when mixing amd64
and x32 processes, but noticed that mtext was moving around (although
they though that was how it was meant to work, not that this was a
bug). Pure x32 fakeroot though has been in use for the entire lifetime
of the Debian port, as with all other architectures, and I'm not aware
of there having been any issues discovered, despite the fact that its
default implementation is SysV IPC (as opposed to the TCP alternative).
So yeah, it's been tested, but it's not actually quite so easy to
notice.

> Fourth, if there is some deployed code that uses the buggy x32 path
> and actually works by accident, do we risk breaking it if we fix the
> bug?

I highly doubt it. Very few people know of __kernel_long_t, so you
would have to go out of your way to make it work on x32 (and go against
POSIX and the Linux manpage), and that's *after* somehow noticing that
there's a problem which nobody seems to have done, plus msgsnd/msgrcv
is rare in and of itself. A crude search through the Debian archive for
kernel_long_t.*mtype[1] doesn't turn anything up. So yeah, there is a
risk, but I think it's about as minimal as it's ever going to be,
especially given x32 being already rather niche.

Jess

[1] https://codesearch.debian.net/search?q=__kernel_long_t.*mtype=0

Test demonstrating

debian:~ jrtc27% cat sysv-msg-test.c
#include 
#include 
#include 

#include 
#include 
#include 

#include 

struct msg_long {
long mtype;
char mtext[8];
};

struct msg_long_ext {
struct msg_long msg_long;
char mext[4];
};

struct msg_kern_long {
__kernel_long_t mtype;
char mtext[8];
};

struct msg_kern_long_ext {
struct msg_kern_long msg_kern_long;
char mext[4];
};

void
do_long(void)
{
struct msg_long_ext msg_long_ext;
int msqid;

msqid = msgget(IPC_PRIVATE, 0600 | IPC_CREAT);

msg_long_ext.msg_long.mtype = 1;
strcpy(msg_long_ext.msg_long.mtext, "PAYLOAD");
strcpy(msg_long_ext.mext, "EXT");
msgsnd(msqid, _long_ext, 8, 0);

msg_long_ext.msg_long.mtype = 0;
memset(msg_long_ext.msg_long.mtext, 0, 8);
memset(msg_long_ext.mext, 0, 4);
msgrcv(msqid, _long_ext, 8, 0, 0);
printf("mtype: %ld\n", msg_long_ext.msg_long.mtype);
printf("mtext: \"%s\"\n",

Re: [PATCH V4 2/3] arm64/mm/hotplug: Enable MEM_OFFLINE event handling

2020-10-11 Thread Gavin Shan


Hi Anshuman,

On 10/6/20 1:59 PM, Anshuman Khandual wrote:

On 10/01/2020 05:27 AM, Gavin Shan wrote:

On 9/29/20 11:54 PM, Anshuman Khandual wrote:

This enables MEM_OFFLINE memory event handling. It will help intercept any
possible error condition such as if boot memory some how still got offlined
even after an explicit notifier failure, potentially by a future change in
generic hot plug framework. This would help detect such scenarios and help
debug further. While here, also call out the first section being attempted
for offline or got offlined.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Steve Capper 
Cc: Mark Brown 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
   arch/arm64/mm/mmu.c | 29 +++--
   1 file changed, 27 insertions(+), 2 deletions(-)



This looks good to me except a nit and it can be improved if
that looks reasonable and only when you get a chance for
respin.

Reviewed-by: Gavin Shan 


diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 4e70f4fea06c..90a30f5ebfc0 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1482,13 +1482,38 @@ static int prevent_bootmem_remove_notifier(struct 
notifier_block *nb,
   unsigned long end_pfn = arg->start_pfn + arg->nr_pages;
   unsigned long pfn = arg->start_pfn;
   -    if (action != MEM_GOING_OFFLINE)
+    if ((action != MEM_GOING_OFFLINE) && (action != MEM_OFFLINE))
   return NOTIFY_OK;
     for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+    unsigned long start = PFN_PHYS(pfn);
+    unsigned long end = start + (1UL << PA_SECTION_SHIFT);
+
   ms = __pfn_to_section(pfn);
-    if (early_section(ms))
+    if (!early_section(ms))
+    continue;
+


The discussion here is irrelevant to this patch itself. It seems
early_section() is coarse, which means all memory detected during
boot time won't be hotpluggable?


Right, thats the policy being enforced on arm64 platform for various
critical reasons. Please refer to earlier discussions around memory
hot remove development on arm64.



Thanks for the hints.




+    if (action == MEM_GOING_OFFLINE) {
+    pr_warn("Boot memory [%lx %lx] offlining attempted\n", start, end);
   return NOTIFY_BAD;
+    } else if (action == MEM_OFFLINE) {
+    /*
+ * This should have never happened. Boot memory
+ * offlining should have been prevented by this
+ * very notifier. Probably some memory removal
+ * procedure might have changed which would then
+ * require further debug.
+ */
+    pr_err("Boot memory [%lx %lx] offlined\n", start, end);
+
+    /*
+ * Core memory hotplug does not process a return
+ * code from the notifier for MEM_OFFLINE event.
+ * Error condition has been reported. Report as
+ * ignored.
+ */
+    return NOTIFY_DONE;
+    }
   }
   return NOTIFY_OK;
   }



I think NOTIFY_BAD is returned for MEM_OFFLINE wouldn't be a
bad idea, even the core isn't handling the errno. With this,
the code can be simplified. However, it's not a big deal and
you probably evaluate and change when you need another respin:

     pr_warn("Boot memory [%lx %lx] %s\n",
     (action == MEM_GOING_OFFLINE) ? "offlining attempted" : "offlined",
     start, end);
     return NOTIFY_BAD;


Wondering whether returning a NOTIFY_BAD for MEM_OFFLINE event could
be somewhat risky if generic hotplug mechanism to change later. But
again, probably it might just be OK.

Regardless, also wanted to differentiate error messages for both the
cases. An warning messages i.e pr_warn() for MEM_GOING_OFFLINE which
suggests an unexpected user action but an error message i.e pr_err()
for MEM_OFFLINE which clearly indicates an error condition that needs
to be debugged further.



Ok, fair enough and it looks good to me either.

Cheers,
Gavin

[git pull] vfs.git mount compat series

The last remnants of mount(2) compat buried.  Buried into NFS, that is;
generally I'm less enthusiastic about "let's use in_compat_syscall() deep in
call chain" kind of approach than Christoph seems to be, but in this case it's
warranted - that crap had been an NFS-specific wart, hopefully not to be 
repeated
in any other filesystems (read: any new filesystem introducing non-text mount
options will get NAKed even if it doesn't fuck the layout up).  Not worth trying
to grow an infrastructure that would avoid that use of in_compat_syscall()...
[Note: alpha-related tail of the series got dropped]

The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:

  Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git compat.mount

for you to fetch changes up to 028abd9222df0cf5855dab5014a5ebaf06f90565:

  fs: remove compat_sys_mount (2020-09-22 23:45:57 -0400)


Christoph Hellwig (3):
  nfs: simplify nfs4_parse_monolithic
  fs,nfs: lift compat nfs4 mount data handling into the nfs code
  fs: remove compat_sys_mount

 arch/arm64/include/asm/unistd32.h  |   2 +-
 arch/mips/kernel/syscalls/syscall_n32.tbl  |   2 +-
 arch/mips/kernel/syscalls/syscall_o32.tbl  |   2 +-
 arch/parisc/kernel/syscalls/syscall.tbl|   2 +-
 arch/powerpc/kernel/syscalls/syscall.tbl   |   2 +-
 arch/s390/kernel/syscalls/syscall.tbl  |   2 +-
 arch/sparc/kernel/syscalls/syscall.tbl |   2 +-
 arch/x86/entry/syscalls/syscall_32.tbl |   2 +-
 fs/Makefile|   1 -
 fs/compat.c| 132 --
 fs/internal.h  |   3 -
 fs/namespace.c |   4 +-
 fs/nfs/fs_context.c| 195 +
 include/linux/compat.h |   6 -
 include/uapi/asm-generic/unistd.h  |   2 +-
 tools/include/uapi/asm-generic/unistd.h|   2 +-
 tools/perf/arch/powerpc/entry/syscalls/syscall.tbl |   2 +-
 tools/perf/arch/s390/entry/syscalls/syscall.tbl|   2 +-
 18 files changed, 138 insertions(+), 227 deletions(-)
 delete mode 100644 fs/compat.c

Re: [PATCH v2] kbuild: enforce -Werror=return-type

2020-10-11 Thread Masahiro Yamada

On Mon, Oct 12, 2020 at 3:54 AM Olaf Hering  wrote:
>
> Catch errors which at least gcc tolerates by default:
>  warning: 'return' with no value, in function returning non-void 
> [-Wreturn-type]


Applied to linux-kbuild. Thanks.



> Signed-off-by: Olaf Hering 
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index f84d7e4ca0be..965e7259e6e8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -497,7 +497,7 @@ KBUILD_AFLAGS   := -D__ASSEMBLY__ -fno-PIE
>  KBUILD_CFLAGS   := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
>-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
>-Werror=implicit-function-declaration -Werror=implicit-int 
> \
> -  -Wno-format-security \
> +  -Werror=return-type -Wno-format-security \
>-std=gnu89
>  KBUILD_CPPFLAGS := -D__KERNEL__
>  KBUILD_AFLAGS_KERNEL :=



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver

2020-10-11 Thread Neal Liu

On Fri, 2020-10-09 at 14:34 +0200, Matthias Brugger wrote:
> 
> On 08/10/2020 11:39, Neal Liu wrote:
> > On Thu, 2020-10-08 at 10:45 +0200, Matthias Brugger wrote:
> >>
> >> On 08/10/2020 04:35, Neal Liu wrote:
> >>> On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote:
> 
>  On 27/08/2020 05:06, Neal Liu wrote:
> [...]
> 
> > +static int mtk_devapc_probe(struct platform_device *pdev)
> > +{
> > +   struct device_node *node = pdev->dev.of_node;
> > +   struct mtk_devapc_context *ctx;
> > +   u32 devapc_irq;
> > +   int ret;
> > +
> > +   if (IS_ERR(node))
> > +   return -ENODEV;
> > +
> > +   ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
> > +   if (!ctx)
> > +   return -ENOMEM;
> > +
> > +   ctx->data = of_device_get_match_data(>dev);
> > +   ctx->dev = >dev;
> > +
> > +   ctx->infra_base = of_iomap(node, 0);
> 
>  Does this mean the device is part of the infracfg block?
>  I wasn't able to find any information about it.
> >>>
> >>> I'm not sure why you would ask infracfg block. devapc is parts of our
> >>> SoC infra, it's different with infracfg.
> >>>
> >>
> >> I'm asking because I want to understand the HW better. I'm not able to 
> >> find any
> >> information in the datasheets. I want to avoid a situation as we had with 
> >> the
> >> MMSYS where a clock driver was submitted first and later on we realized 
> >> that
> >> MMSYS is much more then that and we had to work hard to get the driver 
> >> right.
> >>
> >> Now it's happening with SCPSYS, where a driver with the scpsys compatible 
> >> was
> >> send years ago. But SCPSYS is much more then the driver submitted. In this 
> >> case
> >> we opted to write a new driver, but moving from one driver to another one 
> >> is
> >> painfull and full of problems. For that I want to make sure we fully 
> >> understand
> >> Device APC (by the way, what does APC stands for?). Is it a totally 
> >> independent
> >> HW block or is it part of a subsystem, like for example SCP?
> >>
> >> Regards,
> >> Matthias
> > 
> > It's a totally independent HW block instead of a subsystem.
> > I think it's more simple than MMSYS or SCPSYS. But if you would like to
> > understand more about this HW, we could find another way/channel to
> > introduce it.
> > 
> 
> If it's a independent HW block, then we are good. No further information 
> needed 
> by me. I'd just advise to rename the infra_base to something like base, as it 
> made me confuse.
> 
> Thanks!
> Matthias

You can imagine that infra_base means infra devapc base address for
MT6779. In 5G platforms, MediaTek infrastructure would separate into
multiple parts, so does devapc HW. And devapc would be like:
infra_base, peri_base, peri2_base, ...

Thanks.

Re: kernel BUG at fs/reiserfs/prints.c:LINE!

2020-10-11 Thread syzbot

syzbot has found a reproducer for the following issue on:

HEAD commit:3dd0130f Merge branch 'akpm' (patches from Andrew)
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1107d07850
kernel config:  https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c
dashboard link: https://syzkaller.appspot.com/bug?extid=1541a3226994c0781b29
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=134aa19f90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=149f6fbf90

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1541a3226994c0781...@syzkaller.appspotmail.com

REISERFS panic (device loop0): journal-2332 do_journal_end: Trying to log block 
8211, which is a log block
[ cut here ]
kernel BUG at fs/reiserfs/prints.c:390!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 6887 Comm: syz-executor832 Not tainted 5.9.0-rc8-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:__reiserfs_panic.cold+0x37/0x8a fs/reiserfs/prints.c:390
Code: 9c 88 74 6d e8 cf 7c 7a ff 4c 89 e9 4c 89 f2 4c 89 e6 49 c7 c0 60 f2 4f 
8d 48 c7 c7 20 b7 9c 88 e8 b2 85 63 ff e8 ae 7c 7a ff <0f> 0b e8 a7 7c 7a ff 4d 
85 e4 49 c7 c6 60 b5 9c 88 75 0a 49 c7 c6
RSP: 0018:c9f07b00 EFLAGS: 00010293
RAX:  RBX: 88809dd2c000 RCX: 
RDX: 8880a6a7e080 RSI: 81fbc262 RDI: f520001e0f52
RBP: c9f07bd0 R08: 006a R09: 8880ae5318e7
R10:  R11:  R12: 889d1d60
R13: 889d2560 R14: 889cb560 R15: 2016
FS:  01815880() GS:8880ae50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0181e8b8 CR3: a26de000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 do_journal_end+0x3d85/0x4950 fs/reiserfs/journal.c:4135
 reiserfs_sync_fs+0xf8/0x120 fs/reiserfs/super.c:78
 __sync_filesystem fs/sync.c:39 [inline]
 sync_filesystem fs/sync.c:64 [inline]
 sync_filesystem+0x105/0x260 fs/sync.c:48
 generic_shutdown_super+0x70/0x370 fs/super.c:448
 kill_block_super+0x97/0xf0 fs/super.c:1444
 deactivate_locked_super+0x94/0x160 fs/super.c:335
 deactivate_super+0xad/0xd0 fs/super.c:366
 cleanup_mnt+0x3a3/0x530 fs/namespace.c:1118
 task_work_run+0xdd/0x190 kernel/task_work.c:141
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:165 [inline]
 exit_to_user_mode_prepare+0x1e1/0x200 kernel/entry/common.c:192
 syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:267
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x448177
Code: 00 00 00 b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 8d a2 fb ff c3 66 
2e 0f 1f 84 00 00 00 00 00 66 90 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 
6d a2 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff2be25a58 EFLAGS: 0206 ORIG_RAX: 00a6
RAX:  RBX: 7fff2be26bd0 RCX: 00448177
RDX: 00400cf7 RSI: 0002 RDI: 7fff2be25b00
RBP: 000211c2 R08:  R09: 0009
R10: 0005 R11: 0206 R12: 7fff2be26b70
R13: 01816880 R14:  R15: 
Modules linked in:
---[ end trace c00fc6b0fe3e7e74 ]---
RIP: 0010:__reiserfs_panic.cold+0x37/0x8a fs/reiserfs/prints.c:390
Code: 9c 88 74 6d e8 cf 7c 7a ff 4c 89 e9 4c 89 f2 4c 89 e6 49 c7 c0 60 f2 4f 
8d 48 c7 c7 20 b7 9c 88 e8 b2 85 63 ff e8 ae 7c 7a ff <0f> 0b e8 a7 7c 7a ff 4d 
85 e4 49 c7 c6 60 b5 9c 88 75 0a 49 c7 c6
RSP: 0018:c9f07b00 EFLAGS: 00010293
RAX:  RBX: 88809dd2c000 RCX: 
RDX: 8880a6a7e080 RSI: 81fbc262 RDI: f520001e0f52
RBP: c9f07bd0 R08: 006a R09: 8880ae5318e7
R10:  R11:  R12: 889d1d60
R13: 889d2560 R14: 889cb560 R15: 2016
FS:  01815880() GS:8880ae50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0181e8b8 CR3: a26de000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400

[git pull] vfs.git quota compat series

More Christoph's compat cleanups: quotactl(2).

The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:

  Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.quota-compat

for you to fetch changes up to 80bdad3d7e3ec03f812471d9309f5f682e10f52b:

  quota: simplify the quotactl compat handling (2020-09-17 13:00:46 -0400)


Christoph Hellwig (3):
  compat: lift compat_s64 and compat_u64 to 
  compat: add a compat_need_64bit_alignment_fixup() helper
  quota: simplify the quotactl compat handling

 arch/arm64/include/asm/compat.h|   2 -
 arch/mips/include/asm/compat.h |   2 -
 arch/parisc/include/asm/compat.h   |   2 -
 arch/powerpc/include/asm/compat.h  |   2 -
 arch/s390/include/asm/compat.h |   2 -
 arch/sparc/include/asm/compat.h|   3 +-
 arch/x86/entry/syscalls/syscall_32.tbl |   2 +-
 arch/x86/include/asm/compat.h  |   3 +-
 fs/quota/Kconfig   |   5 --
 fs/quota/Makefile  |   1 -
 fs/quota/compat.c  | 120 -
 fs/quota/compat.h  |  34 ++
 fs/quota/quota.c   |  73 
 include/asm-generic/compat.h   |   8 +++
 include/linux/compat.h |   9 +++
 include/linux/quotaops.h   |   3 -
 kernel/sys_ni.c|   1 -
 17 files changed, 113 insertions(+), 159 deletions(-)
 delete mode 100644 fs/quota/compat.c
 create mode 100644 fs/quota/compat.h

Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver

2020-10-11 Thread Jie Deng




On 2020/10/8 22:01, Wolfram Sang wrote:

Hi,

some super high level questions:


different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.

Could you provide a link directly to the backend, please?

Sure. Here is the link.
https://raw.githubusercontent.com/projectacrn/acrn-hypervisor/master/devicemodel/hw/pci/virtio/virtio_i2c.c

The device ID request:
 https://github.com/oasis-tcs/virtio-spec/issues/85

Shall we wait for this to be approved? Or will it get only approved once
the driver here is upstream?

That's what I want to know also.
So hi Michael, what's the upstream flow for this patch ?

Thanks.



+ If you say yes to this option, support will be included for the virtio
+ I2C adapter driver. The hardware can be emulated by any device model
+ software according to the virtio protocol.

That means stuff like "limiting which devices on a given bus can be
accessed" will be handled by the backends, or?

What kind of testing has been done with this on which setup?

Thanks and happy hacking,

Wolfram

Yes, you can configure what devices can be seen by the guest.
This provides a way to flexibly organize and manage I2C slave devices 
from the guest.


We tested it on Intel APL MRB. There are some docs for you reference.
https://projectacrn.github.io/latest/developer-guides/hld/virtio-i2c.html?highlight=i2c

Regards.

[git pull] vfs.git iov_iter series

Christoph's series around import_iovec() and compat variant thereof.

The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:

  Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.iov_iter

for you to fetch changes up to 5d47b394794d3086c1c338cc014011a9ee34005c:

  security/keys: remove compat_keyctl_instantiate_key_iov (2020-10-03 00:02:16 
-0400)


Christoph Hellwig (8):
  compat.h: fix a spelling error in 
  iov_iter: refactor rw_copy_check_uvector and import_iovec
  iov_iter: transparently handle compat iovecs in import_iovec
  fs: remove various compat readv/writev helpers
  fs: remove the compat readv/writev syscalls
  fs: remove compat_sys_vmsplice
  mm: remove compat_process_vm_{readv,writev}
  security/keys: remove compat_keyctl_instantiate_key_iov

David Laight (1):
  iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c

 arch/arm64/include/asm/unistd32.h  |  10 +-
 arch/mips/kernel/syscalls/syscall_n32.tbl  |  10 +-
 arch/mips/kernel/syscalls/syscall_o32.tbl  |  10 +-
 arch/parisc/kernel/syscalls/syscall.tbl|  10 +-
 arch/powerpc/kernel/syscalls/syscall.tbl   |  10 +-
 arch/s390/kernel/syscalls/syscall.tbl  |  10 +-
 arch/sparc/kernel/syscalls/syscall.tbl |  10 +-
 arch/x86/entry/syscall_x32.c   |   5 +
 arch/x86/entry/syscalls/syscall_32.tbl |  10 +-
 arch/x86/entry/syscalls/syscall_64.tbl |  10 +-
 block/scsi_ioctl.c |  12 +-
 drivers/scsi/sg.c  |   9 +-
 fs/aio.c   |   8 +-
 fs/io_uring.c  |  20 +-
 fs/read_write.c| 362 ++---
 fs/splice.c|  57 +---
 include/linux/compat.h |  50 +--
 include/linux/fs.h |  13 -
 include/linux/uio.h|  20 +-
 include/uapi/asm-generic/unistd.h  |  12 +-
 lib/iov_iter.c | 178 +++---
 mm/process_vm_access.c |  86 +
 net/compat.c   |   4 +-
 security/keys/compat.c |  37 +--
 security/keys/internal.h   |   5 -
 security/keys/keyctl.c |   2 +-
 tools/include/uapi/asm-generic/unistd.h|  12 +-
 tools/perf/arch/powerpc/entry/syscalls/syscall.tbl |  10 +-
 tools/perf/arch/s390/entry/syscalls/syscall.tbl|  10 +-
 tools/perf/arch/x86/entry/syscalls/syscall_64.tbl  |  10 +-
 30 files changed, 298 insertions(+), 714 deletions(-)

[git pull] vfs.git csum_and_copy stuff

Saner calling conventions for csum_and_copy_..._user() and friends.
Sat in -next for two cycles now...

The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:

  Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.csum_and_copy

for you to fetch changes up to 70d65cd555c5e43c613700f604a47f7ebcf7b6f1:

  ppc: propagate the calling conventions change down to 
csum_partial_copy_generic() (2020-08-20 15:45:22 -0400)


Al Viro (19):
  skb_copy_and_csum_bits(): don't bother with the last argument
  icmp_push_reply(): reorder adding the checksum up
  unify generic instances of csum_partial_copy_nocheck()
  csum_partial_copy_nocheck(): drop the last argument
  csum_and_copy_..._user(): pass 0x instead of 0 as initial sum
  saner calling conventions for csum_and_copy_..._user()
  alpha: propagate the calling convention changes down to 
csum_partial_copy.c helpers
  arm: propagate the calling convention changes down to 
csum_partial_copy_from_user()
  m68k: get rid of zeroing destination on error in csum_and_copy_from_user()
  sh: propage the calling conventions change down to 
csum_partial_copy_generic()
  i386: propagate the calling conventions change down to 
csum_partial_copy_generic()
  sparc32: propagate the calling conventions change down to 
__csum_partial_copy_sparc_generic()
  mips: csum_and_copy_{to,from}_user() are never called under KERNEL_DS
  mips: __csum_partial_copy_kernel() has no users left
  mips: propagate the calling convention change down into 
__csum_partial_copy_..._user()
  xtensa: propagate the calling conventions change down into 
csum_partial_copy_generic()
  sparc64: propagate the calling convention changes down to 
__csum_partial_copy_...()
  amd64: switch csum_partial_copy_generic() to new calling conventions
  ppc: propagate the calling conventions change down to 
csum_partial_copy_generic()

 arch/alpha/include/asm/checksum.h |   5 +-
 arch/alpha/lib/csum_partial_copy.c| 164 ---
 arch/arm/include/asm/checksum.h   |  17 +-
 arch/arm/lib/csumpartialcopy.S|   4 +-
 arch/arm/lib/csumpartialcopygeneric.S |   1 +
 arch/arm/lib/csumpartialcopyuser.S|  26 +--
 arch/c6x/include/asm/checksum.h   |   3 +
 arch/c6x/lib/csum_64plus.S|   4 +-
 arch/hexagon/include/asm/checksum.h   |  11 --
 arch/hexagon/lib/checksum.c   |  11 --
 arch/ia64/include/asm/checksum.h  |   3 -
 arch/ia64/lib/csum_partial_copy.c |  15 --
 arch/m68k/include/asm/checksum.h  |   7 +-
 arch/m68k/lib/checksum.c  |  88 +++---
 arch/mips/include/asm/checksum.h  |  68 ++--
 arch/mips/lib/csum_partial.S  | 261 ++
 arch/nios2/include/asm/checksum.h |   4 -
 arch/parisc/include/asm/checksum.h|  28 
 arch/parisc/lib/checksum.c|  17 --
 arch/powerpc/include/asm/checksum.h   |  13 +-
 arch/powerpc/lib/checksum_32.S|  74 -
 arch/powerpc/lib/checksum_64.S|  37 ++---
 arch/powerpc/lib/checksum_wrappers.c  |  74 ++---
 arch/s390/include/asm/checksum.h  |   7 -
 arch/sh/include/asm/checksum_32.h |  36 ++---
 arch/sh/lib/checksum.S| 119 --
 arch/sparc/include/asm/checksum.h |   2 +
 arch/sparc/include/asm/checksum_32.h  |  70 ++--
 arch/sparc/include/asm/checksum_64.h  |  39 +
 arch/sparc/lib/checksum_32.S  | 202 +--
 arch/sparc/lib/csum_copy.S|   3 +-
 arch/sparc/lib/csum_copy_from_user.S  |   4 +-
 arch/sparc/lib/csum_copy_to_user.S|   4 +-
 arch/sparc/mm/fault_32.c  |   6 +-
 arch/x86/include/asm/checksum.h   |   1 +
 arch/x86/include/asm/checksum_32.h|  40 ++---
 arch/x86/include/asm/checksum_64.h|  14 +-
 arch/x86/lib/checksum_32.S| 117 +-
 arch/x86/lib/csum-copy_64.S   | 140 +---
 arch/x86/lib/csum-wrappers_64.c   |  86 ++
 arch/x86/um/asm/checksum.h|  16 --
 arch/x86/um/asm/checksum_32.h |  23 ---
 arch/xtensa/include/asm/checksum.h|  34 ++--
 arch/xtensa/lib/checksum.S|  67 ++--
 drivers/net/ethernet/3com/typhoon.c   |   3 +-
 drivers/net/ethernet/sun/sunvnet_common.c |   2 +-
 include/asm-generic/checksum.h|  12 --
 include/linux/skbuff.h|   2 +-
 include/net/checksum.h|  22 ++-
 lib/checksum.c|  11 --
 lib/iov_iter.c|  21 ++-
 net/core/skbuff.c |  13 +-

Re: [tip: locking/core] lockdep: Fix lockdep recursion

2020-10-11 Thread Boqun Feng

Hi,

On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > The following commit has been merged into the locking/core branch of tip:
> > 
> > Commit-ID: 4d004099a668c41522242aa146a38cc4eb59cb1e
> > Gitweb:
> > https://git.kernel.org/tip/4d004099a668c41522242aa146a38cc4eb59cb1e
> > Author:Peter Zijlstra 
> > AuthorDate:Fri, 02 Oct 2020 11:04:21 +02:00
> > Committer: Ingo Molnar 
> > CommitterDate: Fri, 09 Oct 2020 08:53:30 +02:00
> > 
> > lockdep: Fix lockdep recursion
> > 
> > Steve reported that lockdep_assert*irq*(), when nested inside lockdep
> > itself, will trigger a false-positive.
> > 
> > One example is the stack-trace code, as called from inside lockdep,
> > triggering tracing, which in turn calls RCU, which then uses
> > lockdep_assert_irqs_disabled().
> > 
> > Fixes: a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu
> > variables")
> > Reported-by: Steven Rostedt 
> > Signed-off-by: Peter Zijlstra (Intel) 
> > Signed-off-by: Ingo Molnar 
> 
> Reverting this linux-next commit fixed booting RCU-list warnings everywhere.
> 

I think this happened because in this commit debug_lockdep_rcu_enabled()
didn't adopt to the change that made lockdep_recursion a percpu
variable?

Qian, mind to try the following?

Although, arguably the problem still exists, i.e. we still have an RCU
read-side critical section inside lock_acquire(), which may be called on
a yet-to-online CPU, which RCU doesn't watch. I think this used to be OK
because we don't "free" anything from lockdep, IOW, there is no
synchronize_rcu() or call_rcu() that _needs_ to wait for the RCU
read-side critical sections inside lockdep. But now we lock class
recycling, so it might be a problem.

That said, currently validate_chain() and lock class recycling are
mutually excluded via graph_lock, so we are safe for this one ;-)

--->8
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 39334d2d2b37..35d9bab65b75 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -275,8 +275,8 @@ EXPORT_SYMBOL_GPL(rcu_callback_map);
 
 noinstr int notrace debug_lockdep_rcu_enabled(void)
 {
-   return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && debug_locks &&
-  current->lockdep_recursion == 0;
+   return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE &&
+  __lockdep_enabled;
 }
 EXPORT_SYMBOL_GPL(debug_lockdep_rcu_enabled);
 

> == x86 ==
> [8.101841][T1] rcu: Hierarchical SRCU implementation.
> [8.110615][T5] NMI watchdog: Enabled. Permanently consumes one hw-PMU 
> counter.
> [8.153506][T1] smp: Bringing up secondary CPUs ...
> [8.163075][T1] x86: Booting SMP configuration:
> [8.167843][T1]  node  #0, CPUs:#1
> [4.002695][T0] 
> [4.002695][T0] =
> [4.002695][T0] WARNING: suspicious RCU usage
> [4.002695][T0] 5.9.0-rc8-next-20201009 #2 Not tainted
> [4.002695][T0] -
> [4.002695][T0] kernel/locking/lockdep.c:3497 RCU-list traversed in 
> non-reader section!!
> [4.002695][T0] 
> [4.002695][T0] other info that might help us debug this:
> [4.002695][T0] 
> [4.002695][T0] 
> [4.002695][T0] RCU used illegally from offline CPU!
> [4.002695][T0] rcu_scheduler_active = 1, debug_locks = 1
> [4.002695][T0] no locks held by swapper/1/0.
> [4.002695][T0] 
> [4.002695][T0] stack backtrace:
> [4.002695][T0] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 5.9.0-rc8-next-20201009 #2
> [4.002695][T0] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 
> Gen10, BIOS A40 07/10/2019
> [4.002695][T0] Call Trace:
> [4.002695][T0]  dump_stack+0x99/0xcb
> [4.002695][T0]  __lock_acquire.cold.76+0x2ad/0x3e0
> lookup_chain_cache at kernel/locking/lockdep.c:3497
> (inlined by) lookup_chain_cache_add at kernel/locking/lockdep.c:3517
> (inlined by) validate_chain at kernel/locking/lockdep.c:3572
> (inlined by) __lock_acquire at kernel/locking/lockdep.c:4837
> [4.002695][T0]  ? lockdep_hardirqs_on_prepare+0x3d0/0x3d0
> [4.002695][T0]  lock_acquire+0x1c8/0x820
> lockdep_recursion_finish at kernel/locking/lockdep.c:435
> (inlined by) lock_acquire at kernel/locking/lockdep.c:5444
> (inlined by) lock_acquire at kernel/locking/lockdep.c:5407
> [4.002695][T0]  ? __debug_object_init+0xb4/0xf50
> [4.002695][T0]  ? memset+0x1f/0x40
> [4.002695][T0]  ? rcu_read_unlock+0x40/0x40
> [4.002695][T0]  ? mce_gather_info+0x170/0x170
> [4.002695][T0]  ? arch_freq_get_on_cpu+0x270/0x270
> [4.002695][T0]  ? mce_cpu_restart+0x40/0x40
> [4.002695][T0]  _raw_spin_lock_irqsave+0x30/0x50
> [4.002695][T0]  ? __debug_object_init+0xb4/0xf50
> [4.002695][T0]

Re: [PATCH] x86: Fix x32 System V message queue syscalls

2020-10-11 Thread Andy Lutomirski

On Sun, Oct 11, 2020 at 6:48 PM Jessica Clarke  wrote:
>
> POSIX specifies that the first field of the supplied msgp, namely mtype,
> is a long, not a __kernel_long_t, and it's a user-defined struct due to
> the variable-length mtext field so we can't even bend the spec and make
> it a __kernel_long_t even if we wanted to. Thus we must use the compat
> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
> msgrcv respectively.
>
> Due to erroneously including the first 4 bytes of mtext in the mtype
> this would previously also cause non-zero msgtyp arguments for msgrcv to
> search for the wrong messages, and if sharing message queues between x32
> and non-x32 (i386 or x86_64) processes this would previously cause mtext
> to "move" and, depending on the direction and ABI combination, lose the
> first 4 bytes.

This has a few problems.

First, the 512-547 range is a legacy wart and we shouldn't extend it.
I thought I had documented this, but I didn't -- oops.  Patch sent.
The correct way to do this nowadays is to use the same number twice,
once for x64 and once for x32.  If you try to do this and encounter
problems with the build, please either fix them or let me know :)

Second, since this is an ABI issue, can you please include a little
test case that compiles for i386, x86_64 and x32, works correctly on
all three with whatever patch you send, and fails on x32 without the
patch?

Third, how does this interact with various libc implementations?
msgsnd(2) and msgrcv(2) have glibc wrappers.  Have they never been
tested on x32?

Fourth, if there is some deployed code that uses the buggy x32 path
and actually works by accident, do we risk breaking it if we fix the
bug?

--Andy

[PATCH V6] kthread: Add debugobject support

2020-10-11 Thread Qianli Zhao

From: Qianli Zhao 

kthread_work is not covered by debug objects, but the same problems as with
regular work objects apply.

Some of the issues like reinitialization of an active kthread_work are hard
to debug because the problem manifests itself later in a completely
different context.

Add debugobject support along with the necessary fixup functions to make
debugging of these problems less tedious.

Signed-off-by: Qianli Zhao 
---
V6:
- Changelog update follow tglx's suggestion
- Completion initialized as part of kthread_init_work_onstack() in 
kthread_flush_worker()/kthread_flush_work()

V5:
- Fix format error checked by checkpatch.pl 

V4:
- Changelog update
- Add comment for KWORK_ENTRY_STATIC
- Code format modification 
- Check worker availability early in kthread_flush_work

V3:
- changelog update
- add fixup_assert_init support
- move debug_kwork_activate/debug_kwork_deactivate before list operation
- name the kconfig CONFIG_DEBUG_OBJECTS_KTHREAD_WORK
- use kthread_init_work_onstack/destroy_kwork_on_stack when kthread_work used 
on stack
- __init_kwork before clear kthread_work in kthread_init_work
---
 include/linux/kthread.h |  30 +-
 include/linux/poison.h  |   4 ++
 kernel/kthread.c| 142 +---
 lib/Kconfig.debug   |  10 
 4 files changed, 176 insertions(+), 10 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 65b81e0..706302b 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -108,6 +108,17 @@ struct kthread_delayed_work {
struct timer_list timer;
 };
 
+#ifdef CONFIG_DEBUG_OBJECTS_KTHREAD_WORK
+extern void __init_kwork(struct kthread_work *kwork, int onstack);
+extern void destroy_kwork_on_stack(struct kthread_work *kwork);
+extern void destroy_delayed_kwork_on_stack(struct kthread_delayed_work 
*kdwork);
+#else
+static inline void __init_kwork(struct kthread_work *kwork, int onstack) { }
+static inline void destroy_kwork_on_stack(struct kthread_work *kwork) { }
+static inline void destroy_delayed_kwork_on_stack(struct kthread_delayed_work 
*kdwork) { }
+#endif
+
+
 #define KTHREAD_WORKER_INIT(worker){   \
.lock = __RAW_SPIN_LOCK_UNLOCKED((worker).lock),\
.work_list = LIST_HEAD_INIT((worker).work_list),\
@@ -115,7 +126,7 @@ struct kthread_delayed_work {
}
 
 #define KTHREAD_WORK_INIT(work, fn){   \
-   .node = LIST_HEAD_INIT((work).node),\
+   .node = { .next = KWORK_ENTRY_STATIC }, \
.func = (fn),   \
}
 
@@ -159,6 +170,15 @@ extern void __kthread_init_worker(struct kthread_worker 
*worker,
 
 #define kthread_init_work(work, fn)\
do {\
+   __init_kwork(work, 0);  
\
+   memset((work), 0, sizeof(struct kthread_work)); \
+   INIT_LIST_HEAD(&(work)->node);  \
+   (work)->func = (fn);\
+   } while (0)
+
+#define kthread_init_work_onstack(work, fn)
\
+   do {\
+   __init_kwork(work, 1);  
\
memset((work), 0, sizeof(struct kthread_work)); \
INIT_LIST_HEAD(&(work)->node);  \
(work)->func = (fn);\
@@ -172,6 +192,14 @@ extern void __kthread_init_worker(struct kthread_worker 
*worker,
 TIMER_IRQSAFE);\
} while (0)
 
+#define kthread_init_delayed_work_onstack(dwork, fn)   
\
+   do {\
+   kthread_init_work_onstack(&(dwork)->work, (fn));
\
+   __init_timer_on_stack(&(dwork)->timer,  
\
+kthread_delayed_work_timer_fn, \
+TIMER_IRQSAFE);\
+   } while (0)
+
 int kthread_worker_fn(void *worker_ptr);
 
 __printf(2, 3)
diff --git a/include/linux/poison.h b/include/linux/poison.h
index dc8ae5d..50811c74 100644
--- a/include/linux/poison.h
+++ b/include/linux/poison.h
@@ -82,4 +82,8 @@
 /** security/ **/
 #define KEY_DESTROY0xbd
 
+/** kernel/kthread **/
+/*indicate a static kthread_work initializer for the object debugging code.*/
+#define KWORK_ENTRY_STATIC ((void *) 0x600 + POISON_POINTER_DELTA)
+
 #endif
diff --git a/kernel/kthread.c b/kernel/kthread.c
index

Re: [PATCH v3] arm64/mm: add fallback option to allocate virtually contiguous memory

2020-10-11 Thread Gavin Shan


On 10/6/20 2:36 PM, Anshuman Khandual wrote:

On 10/02/2020 01:46 AM, Sudarshan Rajagopalan wrote:

When section mappings are enabled, we allocate vmemmap pages from physically
continuous memory of size PMD_SIZE using vmemmap_alloc_block_buf(). Section
mappings are good to reduce TLB pressure. But when system is highly fragmented
and memory blocks are being hot-added at runtime, its possible that such
physically continuous memory allocations can fail. Rather than failing the
memory hot-add procedure, add a fallback option to allocate vmemmap pages from
discontinuous pages using vmemmap_populate_basepages().

Signed-off-by: Sudarshan Rajagopalan 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Anshuman Khandual 
Cc: Mark Rutland 
Cc: Logan Gunthorpe 
Cc: David Hildenbrand 
Cc: Andrew Morton 
Cc: Steven Price 
---
  arch/arm64/mm/mmu.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)



It looks good to me with Anshuman's comments fixed:

Reviewed-by: Gavin Shan 


diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 75df62f..11f8639 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1121,8 +1121,15 @@ int __meminit vmemmap_populate(unsigned long start, 
unsigned long end, int node,
void *p = NULL;
  
  			p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);

-   if (!p)
-   return -ENOMEM;
+   if (!p) {
+   /*
+* fallback allocating with virtually
+* contiguous memory for this section
+*/


Mapping is always virtually contiguous with or without huge pages.
Please drop this comment here, as it's obvious.


+   if (vmemmap_populate_basepages(addr, next, 
node, NULL))
+   return -ENOMEM;


Please send in the 'altmap' instead of NULL for allocation from
device memory if and when requested.

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] x86/syscalls: Document the fact that syscalls 512-547 are a legacy mistake

2020-10-11 Thread Andy Lutomirski

Since commit 6365b842aae4 ("x86/syscalls: Split the x32 syscalls
into their own table"), there is no need for special x32-specific
syscall numbers.  I forgot to update the comments in syscall_64.tbl.
Add comments to make it clear to future contributors that this range
is a legacy wart.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/syscalls/syscall_64.tbl | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
b/arch/x86/entry/syscalls/syscall_64.tbl
index f30d6ae9a688..4adb5d2a3319 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -363,10 +363,10 @@
 439common  faccessat2  sys_faccessat2
 
 #
-# x32-specific system call numbers start at 512 to avoid cache impact
-# for native 64-bit operation. The __x32_compat_sys stubs are created
-# on-the-fly for compat_sys_*() compatibility system calls if X86_X32
-# is defined.
+# Due to a historical design error, certain syscalls are numbered differently
+# in x32 as compared to native x86_64.  These syscalls have numbers 512-547.
+# Do not add new syscalls to this range.  Numbers 548 and above are available
+# for non-x32 use.
 #
 512x32 rt_sigactioncompat_sys_rt_sigaction
 513x32 rt_sigreturncompat_sys_x32_rt_sigreturn
@@ -404,3 +404,5 @@
 545x32 execveatcompat_sys_execveat
 546x32 preadv2 compat_sys_preadv64v2
 547x32 pwritev2compat_sys_pwritev64v2
+# This is the end of the legacy x32 range.  Numbers 548 and above are
+# not special and are not to be used for x32-specific syscalls.
-- 
2.26.2

[PATCH] HSI: omap_ssi: Don't jump to free ID in ssi_add_controller()

2020-10-11 Thread Jing Xiangfeng

In current code, it jumps to ida_simple_remove() when ida_simple_get()
failes to allocate an ID. Just return to fix it.

Fixes: 0fae198988b8 ("HSI: omap_ssi: built omap_ssi and omap_ssi_port into one 
module")
Signed-off-by: Jing Xiangfeng 
---
 drivers/hsi/controllers/omap_ssi_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hsi/controllers/omap_ssi_core.c 
b/drivers/hsi/controllers/omap_ssi_core.c
index fa69b94debd9..7596dc164648 100644
--- a/drivers/hsi/controllers/omap_ssi_core.c
+++ b/drivers/hsi/controllers/omap_ssi_core.c
@@ -355,7 +355,7 @@ static int ssi_add_controller(struct hsi_controller *ssi,
 
err = ida_simple_get(_omap_ssi_ida, 0, 0, GFP_KERNEL);
if (err < 0)
-   goto out_err;
+   return err;
ssi->id = err;
 
ssi->owner = THIS_MODULE;
-- 
2.17.1

Re: [PATCH v9 1/6] fpga: dfl: fix the definitions of type & feature_id for dfl devices

2020-10-11 Thread Xu Yilun

On Sat, Oct 10, 2020 at 08:07:07AM -0700, Tom Rix wrote:
> 
> On 10/10/20 12:09 AM, Xu Yilun wrote:
> > The value of the field dfl_device.type comes from the 12 bits register
> > field DFH_ID according to DFL spec. So this patch changes the definition
> > of the type field to u16.
> >
> > Also it is not necessary to illustrate the valid bits of the type field
> > in comments. Instead we should explicitly define the possible values in
> > the enumeration type for it, because they are shared by hardware spec.
> > We should not let the compiler decide these values.
> >
> > Similar changes are also applied to dfl_device.feature_id.
> >
> > This patch also fixed the MODALIAS format according to the changes
> > above.
> >
> > Signed-off-by: Xu Yilun 
> > ---
> > v9: no change
> > ---
> >  drivers/fpga/dfl.c |  3 +--
> >  drivers/fpga/dfl.h | 14 +++---
> >  2 files changed, 8 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> > index b450870..5a6ba3b 100644
> > --- a/drivers/fpga/dfl.c
> > +++ b/drivers/fpga/dfl.c
> > @@ -298,8 +298,7 @@ static int dfl_bus_uevent(struct device *dev, struct 
> > kobj_uevent_env *env)
> >  {
> > struct dfl_device *ddev = to_dfl_dev(dev);
> >  
> > -   /* The type has 4 valid bits and feature_id has 12 valid bits */
> > -   return add_uevent_var(env, "MODALIAS=dfl:t%01Xf%03X",
> > +   return add_uevent_var(env, "MODALIAS=dfl:t%04Xf%04X",
> >   ddev->type, ddev->feature_id);
> >  }
> >  
> > diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
> > index 5dc758f..ac373b1 100644
> > --- a/drivers/fpga/dfl.h
> > +++ b/drivers/fpga/dfl.h
> > @@ -520,19 +520,19 @@ long dfl_feature_ioctl_set_irq(struct platform_device 
> > *pdev,
> >   * enum dfl_id_type - define the DFL FIU types
> >   */
> >  enum dfl_id_type {
> > -   FME_ID,
> > -   PORT_ID,
> > +   FME_ID = 0,
> > +   PORT_ID = 1,
> 
> This is redundant, why make this change ?

These values are shared by hardware spec, so it is suggested that the
values of the enum type should be explicitly set, otherwise the compiler
is in its right to do whatever it wants with them (within reason...)

Please see the original discussion:
https://lore.kernel.org/linux-fpga/20200923055436.ga2629...@kroah.com/

Thanks,
Yilun

> 
> Tom
> 
> > DFL_ID_MAX,
> >  };
> >  
> >  /**
> >   * struct dfl_device_id -  dfl device identifier
> > - * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
> > - * @feature_id: contains 12 bits feature identifier local to its DFL FIU 
> > type.
> > + * @type: DFL FIU type of the device. See enum dfl_id_type.
> > + * @feature_id: feature identifier local to its DFL FIU type.
> >   * @driver_data: driver specific data.
> >   */
> >  struct dfl_device_id {
> > -   u8 type;
> > +   u16 type;
> > u16 feature_id;
> > unsigned long driver_data;
> >  };
> > @@ -543,7 +543,7 @@ struct dfl_device_id {
> >   * @dev: generic device interface.
> >   * @id: id of the dfl device.
> >   * @type: type of DFL FIU of the device. See enum dfl_id_type.
> > - * @feature_id: 16 bits feature identifier local to its DFL FIU type.
> > + * @feature_id: feature identifier local to its DFL FIU type.
> >   * @mmio_res: mmio resource of this dfl device.
> >   * @irqs: list of Linux IRQ numbers of this dfl device.
> >   * @num_irqs: number of IRQs supported by this dfl device.
> > @@ -553,7 +553,7 @@ struct dfl_device_id {
> >  struct dfl_device {
> > struct device dev;
> > int id;
> > -   u8 type;
> > +   u16 type;
> > u16 feature_id;
> > struct resource mmio_res;
> > int *irqs;

linux-next: manual merge of the net-next tree with the net tree

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/mptcp/protocol.h

between commit:

  d582484726c4 ("mptcp: fix fallback for MP_JOIN subflows")

from the net tree and commit:

  d0876b2284cf ("mptcp: add the incoming RM_ADDR support")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/mptcp/protocol.h
index 972463642690,aa0ab18d2e57..
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@@ -203,9 -211,10 +212,11 @@@ struct mptcp_sock 
boolfully_established;
boolrcv_data_fin;
boolsnd_data_fin_enable;
 +  booluse_64bit_ack; /* Set when we received a 64-bit DSN */
spinlock_t  join_list_lock;
struct work_struct work;
+   struct sk_buff  *ooo_last_skb;
+   struct rb_root  out_of_order_queue;
struct list_head conn_list;
struct list_head rtx_queue;
struct list_head join_list;
@@@ -294,9 -309,10 +311,9 @@@ struct mptcp_subflow_context 
map_valid : 1,
mpc_map : 1,
backup : 1,
-   data_avail : 1,
rx_eof : 1,
 -  use_64bit_ack : 1, /* Set when we received a 64-bit DSN */
can_ack : 1;/* only after processing the remote a key */
+   enum mptcp_data_avail data_avail;
u32 remote_nonce;
u64 thmac;
u32 local_nonce;
@@@ -349,11 -365,13 +366,14 @@@ void mptcp_subflow_fully_established(st
 struct mptcp_options_received *mp_opt);
  bool mptcp_subflow_data_available(struct sock *sk);
  void __init mptcp_subflow_init(void);
 +void mptcp_subflow_reset(struct sock *ssk);
+ void mptcp_subflow_shutdown(struct sock *sk, struct sock *ssk, int how);
+ void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,
+  struct mptcp_subflow_context *subflow,
+  long timeout);
  
  /* called with sk socket lock held */
- int __mptcp_subflow_connect(struct sock *sk, int ifindex,
-   const struct mptcp_addr_info *loc,
+ int __mptcp_subflow_connect(struct sock *sk, const struct mptcp_addr_info 
*loc,
const struct mptcp_addr_info *remote);
  int mptcp_subflow_create_socket(struct sock *sk, struct socket **new_sock);
  


pgp6LfMOus4Tf.pgp
Description: OpenPGP digital signature

[PATCH v5 1/4] dt-bindings: mmc: Convert mtk-sd to json-schema

Convert the mtk-sd binding to DT schema format using json-schema.

Signed-off-by: Wenbin Mei 
---
 .../devicetree/bindings/mmc/mtk-sd.txt|  75 
 .../devicetree/bindings/mmc/mtk-sd.yaml   | 163 ++
 2 files changed, 163 insertions(+), 75 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mmc/mtk-sd.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/mtk-sd.yaml

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
deleted file mode 100644
index 26a8f320a156..
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-* MTK MMC controller
-
-The MTK  MSDC can act as a MMC controller
-to support MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the msdc driver.
-
-Required properties:
-- compatible: value should be either of the following.
-   "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
-   "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
-   "mediatek,mt8183-mmc": for mmc host ip compatible with mt8183
-   "mediatek,mt8516-mmc": for mmc host ip compatible with mt8516
-   "mediatek,mt6779-mmc": for mmc host ip compatible with mt6779
-   "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
-   "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
-   "mediatek,mt7622-mmc": for MT7622 SoC
-   "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
-   "mediatek,mt7620-mmc", for MT7621 SoC (and others)
-
-- reg: physical base address of the controller and length
-- interrupts: Should contain MSDC interrupt number
-- clocks: Should contain phandle for the clock feeding the MMC controller
-- clock-names: Should contain the following:
-   "source" - source clock (required)
-   "hclk" - HCLK which used for host (required)
-   "source_cg" - independent source clock gate (required for MT2712)
-   "bus_clk" - bus clock used for internal register access (required for 
MT2712 MSDC0/3)
-- pinctrl-names: should be "default", "state_uhs"
-- pinctrl-0: should contain default/high speed pin ctrl
-- pinctrl-1: should contain uhs mode pin ctrl
-- vmmc-supply: power to the Core
-- vqmmc-supply: power to the IO
-
-Optional properties:
-- assigned-clocks: PLL of the source clock
-- assigned-clock-parents: parent of source clock, used for HS400 mode to get 
400Mhz source clock
-- hs400-ds-delay: HS400 DS delay setting
-- mediatek,hs200-cmd-int-delay: HS200 command internal delay setting.
-   This field has total 32 stages.
-   The value is an integer from 0 to 31.
-- mediatek,hs400-cmd-int-delay: HS400 command internal delay setting
-   This field has total 32 stages.
-   The value is an integer from 0 to 31.
-- mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample selection
-  If present,HS400 command responses are 
sampled on rising edges.
-  If not present,HS400 command responses 
are sampled on falling edges.
-- mediatek,latch-ck: Some SoCs do not support enhance_rx, need set correct 
latch-ck to avoid data crc
-error caused by stop clock(fifo full)
-Valid range = [0:0x7]. if not present, default value is 0.
-applied to compatible "mediatek,mt2701-mmc".
-- resets: Phandle and reset specifier pair to softreset line of MSDC IP.
-- reset-names: Should be "hrst".
-
-Examples:
-mmc0: mmc@1123 {
-   compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
-   reg = <0 0x1123 0 0x108>;
-   interrupts = ;
-   vmmc-supply = <_vemc_3v3_reg>;
-   vqmmc-supply = <_vio18_reg>;
-   clocks = < CLK_PERI_MSDC30_0>,
-< CLK_TOP_MSDC50_0_H_SEL>;
-   clock-names = "source", "hclk";
-   pinctrl-names = "default", "state_uhs";
-   pinctrl-0 = <_pins_default>;
-   pinctrl-1 = <_pins_uhs>;
-   assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
-   assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
-   hs400-ds-delay = <0x14015>;
-   mediatek,hs200-cmd-int-delay = <26>;
-   mediatek,hs400-cmd-int-delay = <14>;
-   mediatek,hs400-cmd-resp-sel-rising;
-};
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml 
b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
new file mode 100644
index ..21a2fce5b7ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
@@ -0,0 +1,163 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mtk-sd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTK MSDC Storage Host Controller Binding
+
+maintainers:
+  - Chaotian Jing 
+  - Wenbin Mei

[PATCH v5 3/4] arm64: dts: mt8192: add mmc device node

This commit adds mmc device node for mt8192

Signed-off-by: Wenbin Mei 
---
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 89 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi| 34 
 2 files changed, 123 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 0205837fa698..a4279fa87c2b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -5,6 +5,7 @@
  */
 /dts-v1/;
 #include "mt8192.dtsi"
+#include "mt6359.dtsi"
 
 / {
model = "MediaTek MT8192 evaluation board";
@@ -27,3 +28,91 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+   pinctrl-names = "default", "state_uhs";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_uhs>;
+   bus-width = <8>;
+   max-frequency = <2>;
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   mmc-hs400-1_8v;
+   supports-cqe;
+   cap-mmc-hw-reset;
+   no-sdio;
+   no-sd;
+   hs400-ds-delay = <0x12814>;
+   vmmc-supply = <_vemc_1_ldo_reg>;
+   vqmmc-supply = <_vufs_ldo_reg>;
+   assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
+   assigned-clock-parents = < CLK_TOP_MSDCPLL>;
+   non-removable;
+};
+
+ {
+   mmc0_pins_default: mmc0default {
+   pins_cmd_dat {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   input-enable;
+   drive-strenth = <3>;
+   mediatek,pull-up-adv = <1>;
+   };
+
+   pins_clk {
+   pinmux = ;
+   drive-strenth = <3>;
+   mediatek,pull-down-adv = <2>;
+   };
+
+   pins_rst {
+   pinmux = ;
+   drive-strenth = <3>;
+   mediatek,pull-up-adv = <1>;
+   };
+   };
+
+   mmc0_pins_uhs: mmc0@0{
+   pins_cmd_dat {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   input-enable;
+   drive-strenth = <4>;
+   mediatek,pull-up-adv = <1>;
+   };
+
+   pins_clk {
+   pinmux = ;
+   drive-strenth = <4>;
+   mediatek,pull-down-adv = <2>;
+   };
+
+   pins_ds {
+   pinmux = ;
+   drive-strenth = <4>;
+   mediatek,pull-down-adv = <2>;
+   };
+
+   pins_rst {
+   pinmux = ;
+   drive-strenth = <3>;
+   mediatek,pull-up-adv = <1>;
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index faea0d97c2a9..de3d10c0eeef 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -760,6 +760,40 @@
#clock-cells = <1>;
};
 
+   mmc0: mmc@11f6 {
+   compatible = "mediatek,mt8192-mmc", 
"mediatek,mt8183-mmc";
+   reg = <0 0x11f6 0 0x1000>,
+ <0 0x11f5 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_TOP_MSDC50_0_SEL>,
+<_top CLK_MSDC_TOP_H_MST_0P>,
+<_top CLK_MSDC_TOP_SRC_0P>,
+<_top CLK_MSDC_TOP_P_CFG>,
+<_top CLK_MSDC_TOP_P_MSDC0>,
+<_top CLK_MSDC_TOP_AXI>,
+<_top CLK_MSDC_TOP_AHB2AXI_BRG_AXI>;
+   clock-names = "source", "hclk", "source_cg", "sys_cg",
+ "pclk_cg", "axi_cg", "ahb_cg";
+   status = "disabled";
+   };
+
+   mmc1: mmc@11f7 {
+   compatible = "mediatek,mt8192-mmc", 
"mediatek,mt8183-mmc";
+   reg = <0 0x11f7 0 0x1000>,
+ <0 0x11c7 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_TOP_MSDC30_1_SEL>,
+<_top CLK_MSDC_TOP_H_MST_1P>,
+<_top CLK_MSDC_TOP_SRC_1P>,
+

[PATCH v5 4/4] mmc: mediatek: Add subsys clock control for MT8192 msdc

MT8192 msdc is an independent sub system, we need control more bus
clocks for it.
Add support for the additional subsys clocks to allow it to be
configured appropriately.

Signed-off-by: Wenbin Mei 
---
 drivers/mmc/host/mtk-sd.c | 74 +--
 1 file changed, 56 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index a704745e5882..41703e6d6b17 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -35,6 +35,7 @@
 #include "cqhci.h"
 
 #define MAX_BD_NUM  1024
+#define MSDC_NR_CLOCKS  3
 
 /*--*/
 /* Common Definition*/
@@ -425,6 +426,8 @@ struct msdc_host {
struct clk *h_clk;  /* msdc h_clk */
struct clk *bus_clk;/* bus clock which used to access register */
struct clk *src_clk_cg; /* msdc source clock control gate */
+   struct clk *sys_clk_cg; /* msdc subsys clock control gate */
+   struct clk_bulk_data bulk_clks[MSDC_NR_CLOCKS];
u32 mclk;   /* mmc subsystem clock frequency */
u32 src_clk_freq;   /* source clock frequency */
unsigned char timing;
@@ -784,6 +787,7 @@ static void msdc_set_busy_timeout(struct msdc_host *host, 
u64 ns, u64 clks)
 
 static void msdc_gate_clock(struct msdc_host *host)
 {
+   clk_bulk_disable_unprepare(MSDC_NR_CLOCKS, host->bulk_clks);
clk_disable_unprepare(host->src_clk_cg);
clk_disable_unprepare(host->src_clk);
clk_disable_unprepare(host->bus_clk);
@@ -792,10 +796,18 @@ static void msdc_gate_clock(struct msdc_host *host)
 
 static void msdc_ungate_clock(struct msdc_host *host)
 {
+   int ret;
+
clk_prepare_enable(host->h_clk);
clk_prepare_enable(host->bus_clk);
clk_prepare_enable(host->src_clk);
clk_prepare_enable(host->src_clk_cg);
+   ret = clk_bulk_prepare_enable(MSDC_NR_CLOCKS, host->bulk_clks);
+   if (ret) {
+   dev_err(host->dev, "Cannot enable pclk/axi/ahb clock gates\n");
+   return;
+   }
+
while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
cpu_relax();
 }
@@ -2366,6 +2378,48 @@ static void msdc_of_property_parse(struct 
platform_device *pdev,
host->cqhci = false;
 }
 
+static int msdc_of_clock_parse(struct platform_device *pdev,
+  struct msdc_host *host)
+{
+   int ret;
+
+   host->src_clk = devm_clk_get_optional(>dev, "source");
+   if (IS_ERR(host->src_clk))
+   return PTR_ERR(host->src_clk);
+
+   host->h_clk = devm_clk_get_optional(>dev, "hclk");
+   if (IS_ERR(host->h_clk))
+   return PTR_ERR(host->h_clk);
+
+   host->bus_clk = devm_clk_get_optional(>dev, "bus_clk");
+   if (IS_ERR(host->bus_clk))
+   host->bus_clk = NULL;
+
+   /*source clock control gate is optional clock*/
+   host->src_clk_cg = devm_clk_get_optional(>dev, "source_cg");
+   if (IS_ERR(host->src_clk_cg))
+   host->src_clk_cg = NULL;
+
+   host->sys_clk_cg = devm_clk_get_optional(>dev, "sys_cg");
+   if (IS_ERR(host->sys_clk_cg))
+   host->sys_clk_cg = NULL;
+
+   /* If present, always enable for this clock gate */
+   clk_prepare_enable(host->sys_clk_cg);
+
+   host->bulk_clks[0].id = "pclk_cg";
+   host->bulk_clks[1].id = "axi_cg";
+   host->bulk_clks[2].id = "ahb_cg";
+   ret = devm_clk_bulk_get_optional(>dev, MSDC_NR_CLOCKS,
+host->bulk_clks);
+   if (ret) {
+   dev_err(>dev, "Cannot get pclk/axi/ahb clock gates\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static int msdc_drv_probe(struct platform_device *pdev)
 {
struct mmc_host *mmc;
@@ -2405,25 +2459,9 @@ static int msdc_drv_probe(struct platform_device *pdev)
if (ret)
goto host_free;
 
-   host->src_clk = devm_clk_get(>dev, "source");
-   if (IS_ERR(host->src_clk)) {
-   ret = PTR_ERR(host->src_clk);
-   goto host_free;
-   }
-
-   host->h_clk = devm_clk_get(>dev, "hclk");
-   if (IS_ERR(host->h_clk)) {
-   ret = PTR_ERR(host->h_clk);
+   ret = msdc_of_clock_parse(pdev, host);
+   if (ret)
goto host_free;
-   }
-
-   host->bus_clk = devm_clk_get(>dev, "bus_clk");
-   if (IS_ERR(host->bus_clk))
-   host->bus_clk = NULL;
-   /*source clock control gate is optional clock*/
-   host->src_clk_cg = devm_clk_get(>dev, "source_cg");
-   if (IS_ERR(host->src_clk_cg))
-   host->src_clk_cg = NULL;
 
host->reset = devm_reset_control_get_optional_exclusive(>dev,
"hrst");
-- 
2.18.0

[PATCH v5 2/4] mmc: dt-bindings: add support for MT8192 SoC

MT8192 mmc host ip is compatible with MT8183.
Add support for this.

Signed-off-by: Wenbin Mei 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml 
b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
index 21a2fce5b7ba..093db1c33653 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
@@ -29,26 +29,37 @@ properties:
   - items:
 - const: mediatek,mt7623-mmc
 - const: mediatek,mt2701-mmc
+  - items:
+- const: mediatek,mt8192-mmc
+- const: mediatek,mt8183-mmc
 
   clocks:
 description:
   Should contain phandle for the clock feeding the MMC controller.
 minItems: 2
-maxItems: 4
+maxItems: 8
 items:
   - description: source clock (required).
   - description: HCLK which used for host (required).
   - description: independent source clock gate (required for MT2712).
   - description: bus clock used for internal register access (required for 
MT2712 MSDC0/3).
+  - description: msdc subsys clock gate (required for MT8192).
+  - description: peripheral bus clock gate (required for MT8192).
+  - description: AXI bus clock gate (required for MT8192).
+  - description: AHB bus clock gate (required for MT8192).
 
   clock-names:
 minItems: 2
-maxItems: 4
+maxItems: 8
 items:
   - const: source
   - const: hclk
   - const: source_cg
   - const: bus_clk
+  - const: sys_cg
+  - const: pclk_cg
+  - const: axi_cg
+  - const: ahb_cg
 
   pinctrl-names:
 items:
-- 
2.18.0

[PATCH v5 0/4] Add mmc support for MT8192 SoC