Re: [RFC v2] perf/core: Fixes hung issue on perf stat command during cpu hotplug

[Srikar Dronamraju]

* Kajol Jain  [2020-08-26 20:24:11]:

> Commit 2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()")
> added assignment of ret value as -EAGAIN in case function
> call to 'smp_call_function_single' fails.
> For non-zero ret value, it did
> 'ret = !ret ? data.ret : -EAGAIN;', which always
> assign -EAGAIN to ret and make second if condition useless.
> 
> In scenarios like when executing a perf stat with --per-thread option, and
> if any of the monitoring cpu goes offline, the 'smp_call_function_single'
> function could return -ENXIO, and with the above check,
> task_function_call hung and increases CPU
> usage (because of repeated 'smp_call_function_single()')
> 
> Recration scenario:
>   # perf stat -a --per-thread && (offline a CPU )
> 
> Patch here removes the tertiary condition added as part of that
> commit and added a check for NULL and -EAGAIN.
> 
> Fixes: 2ed6edd33a21("perf: Add cond_resched() to task_function_call()")
> Signed-off-by: Kajol Jain 
> Reported-by: Srikar Dronamraju 

Tested-by: Srikar Dronamraju 


-- 
Thanks and Regards
Srikar Dronamraju

BUG: stack guard page was hit in __zone_watermark_ok

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:85eb5bc3 net: atheros: switch from 'pci_' to 'dma_' API
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14e3213990
kernel config:  https://syzkaller.appspot.com/x/.config?x=a0437fdd630bee11
dashboard link: https://syzkaller.appspot.com/bug?extid=144d1f35995353c5779c
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

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

BUG: stack guard page was hit at b2f481cf (stack is 
9cbf9546..99742d14)
kernel stack overflow (double-fault):  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 29993 Comm: syz-executor.4 Not tainted 5.9.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:instrument_atomic_read include/linux/instrumented.h:56 [inline]
RIP: 0010:atomic64_read include/asm-generic/atomic-instrumented.h:837 [inline]
RIP: 0010:atomic_long_read include/asm-generic/atomic-long.h:29 [inline]
RIP: 0010:zone_page_state include/linux/vmstat.h:217 [inline]
RIP: 0010:__zone_watermark_unusable_free mm/page_alloc.c:3508 [inline]
RIP: 0010:__zone_watermark_ok+0x23f/0x3f0 mm/page_alloc.c:3529
Code: c4 28 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8d bc 24 98 06 00 00 be 
08 00 00 00 4c 89 4c 24 20 4c 89 54 24 18 89 54 24 10 <4c> 89 44 24 08 48 89 3c 
24 e8 33 78 08 00 48 8b 3c 24 48 b8 00 00
RSP: 0018:c900169f7ff0 EFLAGS: 00010046
RAX: dc00 RBX: 0001 RCX: 0001
RDX:  RSI: 0008 RDI: 88812fffc498
RBP: 0001 R08:  R09: 
R10:  R11: 0001 R12: 88812fffbe00
R13: 0040 R14: 0002 R15: 
FS:  7f98bc4db700() GS:8880ae70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: c900169f7fe8 CR3: 0002063a9000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 zone_watermark_fast mm/page_alloc.c:3612 [inline]
 get_page_from_freelist+0x102f/0x37f0 mm/page_alloc.c:3785
 __alloc_pages_slowpath.constprop.0+0x322/0x2860 mm/page_alloc.c:4592
 __alloc_pages_nodemask+0x62c/0x790 mm/page_alloc.c:4901
 __alloc_pages include/linux/gfp.h:509 [inline]
 __alloc_pages_node include/linux/gfp.h:522 [inline]
 kmem_getpages mm/slab.c:1376 [inline]
 cache_grow_begin+0x71/0x430 mm/slab.c:2590
 cache_alloc_refill+0x27b/0x340 mm/slab.c:2962
 cache_alloc mm/slab.c:3045 [inline]
 cache_alloc mm/slab.c:3028 [inline]
 slab_alloc_node mm/slab.c:3241 [inline]
 kmem_cache_alloc_node_trace+0x3de/0x400 mm/slab.c:3592
 __do_kmalloc_node mm/slab.c:3614 [inline]
 __kmalloc_node_track_caller+0x38/0x60 mm/slab.c:3629
 __kmalloc_reserve net/core/skbuff.c:142 [inline]
 __alloc_skb+0xae/0x550 net/core/skbuff.c:210
 alloc_skb include/linux/skbuff.h:1085 [inline]
 nlmsg_new include/net/netlink.h:944 [inline]
 rtmsg_ifinfo_build_skb+0x72/0x1a0 net/core/rtnetlink.c:3804
 rtmsg_ifinfo_event net/core/rtnetlink.c:3840 [inline]
 rtmsg_ifinfo_event net/core/rtnetlink.c:3831 [inline]
 rtnetlink_event+0x123/0x1d0 net/core/rtnetlink.c:5614
 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2033
 call_netdevice_notifiers_extack net/core/dev.c:2045 [inline]
 call_netdevice_notifiers net/core/dev.c:2059 [inline]
 netdev_features_change net/core/dev.c:1444 [inline]
 netdev_sync_lower_features net/core/dev.c:9371 [inline]
 __netdev_update_features+0x88d/0x1360 net/core/dev.c:9502
 netdev_change_features+0x61/0xb0 net/core/dev.c:9574
 bond_compute_features+0x562/0xa80 drivers/net/bonding/bond_main.c:1308
 bond_slave_netdev_event drivers/net/bonding/bond_main.c:3375 [inline]
 bond_netdev_event+0x871/0xb80 drivers/net/bonding/bond_main.c:3415
 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2033
 call_netdevice_notifiers_extack net/core/dev.c:2045 [inline]
 call_netdevice_notifiers net/core/dev.c:2059 [inline]
 netdev_features_change net/core/dev.c:1444 [inline]
 netdev_sync_lower_features net/core/dev.c:9371 [inline]
 __netdev_update_features+0x88d/0x1360 net/core/dev.c:9502
 netdev_change_features+0x61/0xb0 net/core/dev.c:9574
 bond_compute_features+0x562/0xa80 drivers/net/bonding/bond_main.c:1308
 bond_slave_netdev_event drivers/net/bonding/bond_main.c:3375 [inline]
 bond_netdev_event+0x871/0xb80 drivers/net/bonding/bond_main.c:3415
 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2033
 call_netdevice_notifiers_extack net/core/dev.c:2045 [inline]
 call_netdevice_notifiers 

aarch64-linux-ld: sound/soc/fsl/fsl_asrc_dma.c:211: undefined reference to `dma_request_slave_channel'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   15bc20c6af4ceee97a1f90b43c0e386643c071b4
commit: 41206a073ceebc517245677a19f52ba6379b33a9 Merge v5.8-rc6 into drm-next
date:   5 weeks ago
config: arm64-randconfig-r013-20200826 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 41206a073ceebc517245677a19f52ba6379b33a9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

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

All errors (new ones prefixed by >>):

   drivers/spi/spi-dw-dma.c:45: undefined reference to `dma_get_slave_caps'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.c:53: undefined reference to 
`dma_get_slave_caps'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.o: in function 
`dw_spi_dma_init_generic':
   drivers/spi/spi-dw-dma.c:110: undefined reference to 
`dma_request_slave_channel'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.c:114: undefined reference to 
`dma_request_slave_channel'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.c:116: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.o: in function 
`dw_spi_dma_init_mfld':
   drivers/spi/spi-dw-dma.c:82: undefined reference to `__dma_request_channel'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.c:88: undefined reference to 
`__dma_request_channel'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.c:102: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.o: in function `dw_spi_dma_exit':
   drivers/spi/spi-dw-dma.c:135: undefined reference to `dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-dw-dma.c:140: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-omap2-mcspi.o: in function 
`omap2_mcspi_release_dma':
   drivers/spi/spi-omap2-mcspi.c:1017: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-omap2-mcspi.c:1021: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-omap2-mcspi.o: in function 
`omap2_mcspi_request_dma':
   drivers/spi/spi-omap2-mcspi.c:991: undefined reference to `dma_request_chan'
   aarch64-linux-ld: drivers/spi/spi-omap2-mcspi.c:983: undefined reference to 
`dma_request_chan'
   aarch64-linux-ld: drivers/spi/spi-omap2-mcspi.c:996: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.o: in function `pl022_dma_remove':
   drivers/spi/spi-pl022.c:1211: undefined reference to `dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.c:1213: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.o: in function `pl022_dma_autoprobe':
   drivers/spi/spi-pl022.c:1161: undefined reference to `dma_request_chan'
   aarch64-linux-ld: drivers/spi/spi-pl022.c:1169: undefined reference to 
`dma_request_chan'
   aarch64-linux-ld: drivers/spi/spi-pl022.c:1186: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.c:1189: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.o: in function `pl022_dma_probe':
   drivers/spi/spi-pl022.c:1117: undefined reference to `__dma_request_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.c:1125: undefined reference to 
`__dma_request_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.c:1144: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pl022.c:1146: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pxa2xx-dma.o: in function 
`dma_request_slave_channel_compat':
   include/linux/dmaengine.h:1569: undefined reference to 
`dma_request_slave_channel'
   aarch64-linux-ld: include/linux/dmaengine.h:1569: undefined reference to 
`dma_request_slave_channel'
   aarch64-linux-ld: include/linux/dmaengine.h:1576: undefined reference to 
`__dma_request_channel'
   aarch64-linux-ld: include/linux/dmaengine.h:1576: undefined reference to 
`__dma_request_channel'
   aarch64-linux-ld: drivers/spi/spi-pxa2xx-dma.o: in function 
`pxa2xx_spi_dma_setup':
   drivers/spi/spi-pxa2xx-dma.c:209: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pxa2xx-dma.o: in function 
`pxa2xx_spi_dma_release':
   drivers/spi/spi-pxa2xx-dma.c:223: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-pxa2xx-dma.c:228: undefined reference to 
`dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-uniphier.o: in function 
`uniphier_spi_remove':
   drivers/spi/spi-uniphier.c:773: undefined reference to `dma_release_channel'
   aarch64-linux-ld: drivers/spi/spi-uniphier.c:775: undefined reference to 
`dma_release_c

[PATCH 1/2] hwmon: (k10temp) Create common functions and macros for Zen CPU families

[Wei Huang]

Many SMN thermal registers in Zen CPU families are common across different
generations. For long-term code maintenance, it is better to rename these
macro and function names to Zen.

Signed-off-by: Wei Huang 
---
 drivers/hwmon/k10temp.c | 56 +
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index 8f12995ec133..f3addb97b021 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -73,22 +73,24 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
 #define F15H_M60H_HARDWARE_TEMP_CTRL_OFFSET0xd8200c64
 #define F15H_M60H_REPORTED_TEMP_CTRL_OFFSET0xd8200ca4
 
-/* F17h M01h Access througn SMN */
-#define F17H_M01H_REPORTED_TEMP_CTRL_OFFSET0x00059800
+/* Common for Zen CPU families (Family 17h and 18h) */
+#define ZEN_REPORTED_TEMP_CTRL_OFFSET  0x00059800
 
-#define F17H_M70H_CCD_TEMP(x)  (0x00059954 + ((x) * 4))
-#define F17H_M70H_CCD_TEMP_VALID   BIT(11)
-#define F17H_M70H_CCD_TEMP_MASKGENMASK(10, 0)
+#define ZEN_CCD_TEMP(x)(0x00059954 + ((x) * 4))
+#define ZEN_CCD_TEMP_VALID BIT(11)
+#define ZEN_CCD_TEMP_MASK  GENMASK(10, 0)
 
-#define F17H_M01H_SVI  0x0005A000
-#define F17H_M01H_SVI_TEL_PLANE0   (F17H_M01H_SVI + 0xc)
-#define F17H_M01H_SVI_TEL_PLANE1   (F17H_M01H_SVI + 0x10)
+#define ZEN_CUR_TEMP_SHIFT 21
+#define ZEN_CUR_TEMP_RANGE_SEL_MASKBIT(19)
 
-#define CUR_TEMP_SHIFT 21
-#define CUR_TEMP_RANGE_SEL_MASKBIT(19)
+#define ZEN_SVI_BASE   0x0005A000
 
-#define CFACTOR_ICORE  100 /* 1A / LSB */
-#define CFACTOR_ISOC   25  /* 0.25A / LSB  */
+/* F17h thermal registers through SMN */
+#define F17H_M01H_SVI_TEL_PLANE0   (ZEN_SVI_BASE + 0xc)
+#define F17H_M01H_SVI_TEL_PLANE1   (ZEN_SVI_BASE + 0x10)
+
+#define F17H_CFACTOR_ICORE 100 /* 1A / LSB */
+#define F17H_CFACTOR_ISOC  25  /* 0.25A / LSB  */
 
 struct k10temp_data {
struct pci_dev *pdev;
@@ -168,10 +170,10 @@ static void read_tempreg_nb_f15(struct pci_dev *pdev, u32 
*regval)
  F15H_M60H_REPORTED_TEMP_CTRL_OFFSET, regval);
 }
 
-static void read_tempreg_nb_f17(struct pci_dev *pdev, u32 *regval)
+static void read_tempreg_nb_zen(struct pci_dev *pdev, u32 *regval)
 {
amd_smn_read(amd_pci_dev_to_node_id(pdev),
-F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, regval);
+ZEN_REPORTED_TEMP_CTRL_OFFSET, regval);
 }
 
 static long get_raw_temp(struct k10temp_data *data)
@@ -180,7 +182,7 @@ static long get_raw_temp(struct k10temp_data *data)
long temp;
 
data->read_tempreg(data->pdev, );
-   temp = (regval >> CUR_TEMP_SHIFT) * 125;
+   temp = (regval >> ZEN_CUR_TEMP_SHIFT) * 125;
if (regval & data->temp_adjust_mask)
temp -= 49000;
return temp;
@@ -288,8 +290,8 @@ static int k10temp_read_temp(struct device *dev, u32 attr, 
int channel,
break;
case 2 ... 9:   /* Tccd{1-8} */
amd_smn_read(amd_pci_dev_to_node_id(data->pdev),
-F17H_M70H_CCD_TEMP(channel - 2), );
-   *val = (regval & F17H_M70H_CCD_TEMP_MASK) * 125 - 49000;
+ZEN_CCD_TEMP(channel - 2), );
+   *val = (regval & ZEN_CCD_TEMP_MASK) * 125 - 49000;
break;
default:
return -EOPNOTSUPP;
@@ -438,7 +440,7 @@ static int svi_show(struct seq_file *s, void *unused)
 {
struct k10temp_data *data = s->private;
 
-   k10temp_smn_regs_show(s, data->pdev, F17H_M01H_SVI, 32);
+   k10temp_smn_regs_show(s, data->pdev, ZEN_SVI_BASE, 32);
return 0;
 }
 DEFINE_SHOW_ATTRIBUTE(svi);
@@ -448,7 +450,7 @@ static int thm_show(struct seq_file *s, void *unused)
struct k10temp_data *data = s->private;
 
k10temp_smn_regs_show(s, data->pdev,
- F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, 256);
+ ZEN_REPORTED_TEMP_CTRL_OFFSET, 256);
return 0;
 }
 DEFINE_SHOW_ATTRIBUTE(thm);
@@ -528,8 +530,8 @@ static void k10temp_get_ccd_support(struct pci_dev *pdev,
 
for (i = 0; i < limit; i++) {
amd_smn_read(amd_pci_dev_to_node_id(pdev),
-F17H_M70H_CCD_TEMP(i), );
-   if (regval & F17H_M70H_CCD_TEMP_VALID)
+ZEN_CCD_TEMP(i), );
+   if (regval & ZEN_CCD_TEMP_VALID)
data->show_temp |= BIT(TCCD_BIT(i));
}
 }
@@ -565,8 +567,8 @@ static int 

[PATCH 2/2] hwmon: (k10temp) Define SVI telemetry and current factors for Zen2 CPUs

[Wei Huang]

The voltage telemetry registers for Zen2 are different from Zen1. Also
the factors of CPU current values are changed on Zen2. Add new definitions
for these register.

Signed-off-by: Wei Huang 
---
 drivers/hwmon/k10temp.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index f3addb97b021..de9f68570a4f 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -88,9 +88,13 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
 /* F17h thermal registers through SMN */
 #define F17H_M01H_SVI_TEL_PLANE0   (ZEN_SVI_BASE + 0xc)
 #define F17H_M01H_SVI_TEL_PLANE1   (ZEN_SVI_BASE + 0x10)
+#define F17H_M31H_SVI_TEL_PLANE0   (ZEN_SVI_BASE + 0x14)
+#define F17H_M31H_SVI_TEL_PLANE1   (ZEN_SVI_BASE + 0x10)
 
-#define F17H_CFACTOR_ICORE 100 /* 1A / LSB */
-#define F17H_CFACTOR_ISOC  25  /* 0.25A / LSB  */
+#define F17H_M01H_CFACTOR_ICORE100 /* 1A / LSB 
*/
+#define F17H_M01H_CFACTOR_ISOC 25  /* 0.25A / LSB  */
+#define F17H_M31H_CFACTOR_ICORE100 /* 1A / LSB 
*/
+#define F17H_M31H_CFACTOR_ISOC 31  /* 0.31A / LSB  */
 
 struct k10temp_data {
struct pci_dev *pdev;
@@ -580,17 +584,17 @@ static int k10temp_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
data->show_current = !is_threadripper() && !is_epyc();
data->svi_addr[0] = F17H_M01H_SVI_TEL_PLANE0;
data->svi_addr[1] = F17H_M01H_SVI_TEL_PLANE1;
-   data->cfactor[0] = F17H_CFACTOR_ICORE;
-   data->cfactor[1] = F17H_CFACTOR_ISOC;
+   data->cfactor[0] = F17H_M01H_CFACTOR_ICORE;
+   data->cfactor[1] = F17H_M01H_CFACTOR_ISOC;
k10temp_get_ccd_support(pdev, data, 4);
break;
case 0x31:  /* Zen2 Threadripper */
case 0x71:  /* Zen2 */
data->show_current = !is_threadripper() && !is_epyc();
-   data->cfactor[0] = F17H_CFACTOR_ICORE;
-   data->cfactor[1] = F17H_CFACTOR_ISOC;
-   data->svi_addr[0] = F17H_M01H_SVI_TEL_PLANE1;
-   data->svi_addr[1] = F17H_M01H_SVI_TEL_PLANE0;
+   data->cfactor[0] = F17H_M31H_CFACTOR_ICORE;
+   data->cfactor[1] = F17H_M31H_CFACTOR_ISOC;
+   data->svi_addr[0] = F17H_M31H_SVI_TEL_PLANE0;
+   data->svi_addr[1] = F17H_M31H_SVI_TEL_PLANE1;
k10temp_get_ccd_support(pdev, data, 8);
break;
}
-- 
2.25.2

RE: [PATCH v2 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

[Tian, Kevin]

> From: Lu Baolu 
> Sent: Thursday, August 27, 2020 12:25 PM
> 
> The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
> General
> Description) that:
> 
> If multiple control fields in this register need to be modified, software
> must serialize the modifications through multiple writes to this register.
> 
> However, in irq_remapping.c, modifications of IRE and CFI are done in one
> write. We need to do two separate writes with STS checking after each.
> 
> Fixes: af8d102f999a4 ("x86/intel/irq_remapping: Clean up x2apic opt-out
> security warning mess")
> Cc: Andy Lutomirski 
> Cc: Jacob Pan 
> Cc: Kevin Tian 
> Cc: Ashok Raj 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel/irq_remapping.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> Change log:
> v1->v2:
>   - v1 posted here
> https://lore.kernel.org/linux-iommu/20200826025825.2322-1-
> baolu...@linux.intel.com/;
>   - Add status check before disabling CFI. (Kevin)
> 
> diff --git a/drivers/iommu/intel/irq_remapping.c
> b/drivers/iommu/intel/irq_remapping.c
> index 9564d23d094f..7552bb7e92c8 100644
> --- a/drivers/iommu/intel/irq_remapping.c
> +++ b/drivers/iommu/intel/irq_remapping.c
> @@ -507,12 +507,19 @@ static void iommu_enable_irq_remapping(struct
> intel_iommu *iommu)
> 
>   /* Enable interrupt-remapping */
>   iommu->gcmd |= DMA_GCMD_IRE;
> - iommu->gcmd &= ~DMA_GCMD_CFI;  /* Block compatibility-format
> MSIs */
>   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
> -
>   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
> readl, (sts & DMA_GSTS_IRES), sts);
> 
> + /* Block compatibility-format MSIs */
> + sts = readl(iommu->reg + DMAR_GSTS_REG);

no need of this readl as the status is already three in IOMMU_WAIT_OP.

> + if (sts & DMA_GSTS_CFIS) {
> + iommu->gcmd &= ~DMA_GCMD_CFI;
> + writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
> + IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
> +   readl, !(sts & DMA_GSTS_CFIS), sts);
> + }
> +
>   /*
>* With CFI clear in the Global Command register, we should be
>* protected from dangerous (i.e. compatibility) interrupts
> --
> 2.17.1

Re: [PATCH] perf stat: update POWER9 metrics to utilize other metrics

[Ian Rogers]

On Wed, Aug 26, 2020 at 7:06 PM Paul A. Clarke  wrote:
>
> On Wed, Aug 26, 2020 at 09:26:40AM -0700, Ian Rogers wrote:
> > On Fri, Aug 14, 2020 at 5:43 AM Arnaldo Carvalho de Melo
> >  wrote:
> > > Em Fri, Aug 14, 2020 at 11:20:42AM +0530, kajoljain escreveu:
> > > > On 8/14/20 9:13 AM, Ian Rogers wrote:
> > > > > On Thu, Aug 13, 2020 at 3:21 PM Paul A. Clarke  
> > > > > wrote:
> > > > >> These changes take advantage of the new capability added in
> > > > >> merge commit 00e4db51259a5f936fec1424b884f029479d3981
> > > > >> "Allow using computed metrics in calculating other metrics".
> > > > >>
> > > > >> The net is a simplification of the expressions for a handful
> > > > >> of metrics, but no functional change.
> > > > >>
> > > > >> Signed-off-by: Paul A. Clarke 
> > > >
> > > >   The patch looks good to me.
> > > >
> > > > Reviewed-by: Kajol Jain
> > >
> > > Thanks, applied. Added Ian's Acked-by as well.
> >
> > I've synced perf and testing on a remote machine (not easy for me to
> > log into) I see failures in perf test "10.3: Parsing of PMU event
> > table metrics" like:
> > ...
> > parsing metric: dfu_stall_cpi - dflong_stall_cpi
> > Parse event failed metric 'dfu_other_stall_cpi' id 'dflong_stall_cpi'
> > expr 'dfu_stall_cpi - dflong_stall_cpi'
> > Error string 'parser error' help '(null)'
> > Parse event failed metric 'dfu_other_stall_cpi' id 'dfu_stall_cpi'
> > expr 'dfu_stall_cpi - dflong_stall_cpi'
> > Error string 'parser error' help '(null)'
> > ...
> >
> > This may be that the test doesn't handle the metric in terms of metric
> > addition and so I'll look for a fix. I thought I'd send a heads up in
> > case you had already seen/addressed this. Is perf test on PowerPC
> > clean for you at the moment?
>
> I see these errors as well (on 5.9-rc2).  Each error seems to be for the
> newer metrics that take advantage of the newer functionality, including
> the metrics I changed recently, and Kajol's 24x7 and nest metrics.
>
> Thanks for the heads up!  I confess I had not seen the errors only because
> I wasn't looking.  :-/

No worries, if we create a similar Intel metric it will likely exhibit
a similar issue in the test. Arnaldo and I have wondered about having
an all architectures mode for jevents to make it easier to test cases
like this. As my PowerPC set up is a bit special it is great that
you've confirmed this isn't at fault :-) I'll try to get time to dig a
little further.

Thanks,
Ian

> PC

Re: [RESEND PATCH v4] iommu/mediatek: check 4GB mode by reading infracfg

[Yong Wu]

On Wed, 2020-08-26 at 16:56 +0800, Miles Chen wrote:
> In previous discussion [1] and [2], we found that it is risky to
> use max_pfn or totalram_pages to tell if 4GB mode is enabled.
> 
> Check 4GB mode by reading infracfg register, remove the usage
> of the un-exported symbol max_pfn.
> 
> This is a step towards building mtk_iommu as a kernel module.
> 
> [1] 
> https://lore.kernel.org/lkml/20200603161132.2441-1-miles.c...@mediatek.com/
> [2] 
> https://lore.kernel.org/lkml/20200604080120.2628-1-miles.c...@mediatek.com/
> [3] https://lore.kernel.org/lkml/20200715205120.GA778876@bogus/
> 
> Cc: Mike Rapoport 
> Cc: David Hildenbrand 
> Cc: Yong Wu 
> Cc: Yingjoe Chen 
> Cc: Christoph Hellwig 
> Cc: Rob Herring 
> Cc: Matthias Brugger 
> Signed-off-by: Miles Chen 
> 
> ---
> 
> Change since v3
> - use lore.kernel.org links
> - move "change since..." after "---"
> 
> Change since v2:
> - determine compatible string by m4u_plat
> - rebase to next-20200720
> - add "---"
> 
> Change since v1:
> - remove the phandle usage, search for infracfg instead [3]
> - use infracfg instead of infracfg_regmap
> - move infracfg definitaions to linux/soc/mediatek/infracfg.h
> - update enable_4GB only when has_4gb_mode
> ---
>  drivers/iommu/mtk_iommu.c | 34 +++
>  include/linux/soc/mediatek/infracfg.h |  3 +++
>  2 files changed, 32 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 785b228d39a6..adc350150492 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -3,7 +3,6 @@
>   * Copyright (c) 2015-2016 MediaTek Inc.
>   * Author: Yong Wu 
>   */
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -15,13 +14,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -640,8 +642,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>   struct resource *res;
>   resource_size_t ioaddr;
>   struct component_match  *match = NULL;
> + struct regmap   *infracfg;
>   void*protect;
>   int i, larb_nr, ret;
> + u32 val;
> + char*p;
>  
>   data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>   if (!data)
> @@ -655,10 +660,29 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>   return -ENOMEM;
>   data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
>  
> - /* Whether the current dram is over 4GB */
> - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> - if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
> - data->enable_4GB = false;
> + data->enable_4GB = false;
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
> + switch (data->plat_data->m4u_plat) {
> + case M4U_MT2712:
> + p = "mediatek,mt2712-infracfg";
> + break;
> + case M4U_MT8173:
> + p = "mediatek,mt8173-infracfg";
> + break;
> + default:
> + p = NULL;
> + }
> +

This can be simplified:

if (data->plat_data->m4u_plat == M4U_MT2712)
p = "mediatek,mt2712-infracfg";
else if(data->plat_data->m4u_plat == M4U_MT8173)
p = "mediatek,mt8173-infracfg";
else
return -EINVAL;

Then,
Reviewed-by: Yong Wu 


> + infracfg = syscon_regmap_lookup_by_compatible(p);
> +
> + if (IS_ERR(infracfg))
> + return PTR_ERR(infracfg);
> +
> + ret = regmap_read(infracfg, REG_INFRA_MISC, );
> + if (ret)
> + return ret;
> + data->enable_4GB = !!(val & F_DDR_4GB_SUPPORT_EN);
> + }
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   data->base = devm_ioremap_resource(dev, res);
> diff --git a/include/linux/soc/mediatek/infracfg.h 
> b/include/linux/soc/mediatek/infracfg.h
> index fd25f0148566..233463d789c6 100644
> --- a/include/linux/soc/mediatek/infracfg.h
> +++ b/include/linux/soc/mediatek/infracfg.h
> @@ -32,6 +32,9 @@
>  #define MT7622_TOP_AXI_PROT_EN_WB(BIT(2) | BIT(6) | \
>BIT(7) | BIT(8))
>  
> +#define REG_INFRA_MISC   0xf00
> +#define F_DDR_4GB_SUPPORT_EN BIT(13)
> +
>  int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
>   bool reg_update);
>  int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,

[PATCH] drm/dp: For MST hub, Get max_link_rate_lane from extended rx capability field if EXTENDED_RECEIVER_CAPABILITY_FILED_PRESENT is set.

[Koba Ko]

Currently, DRM get the capability of the mst hub only from DP_DPCD_REV and
get the slower speed even the mst hub can run in the faster speed.

As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1, read the DP_DP13_DPCD_REV to
get the faster capability.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0, read DP_DPCD_REV.

Signed-off-by: Koba Ko 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..3b84c6801281 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3497,6 +3497,8 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8  
dp_link_count)
 int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool 
mst_state)
 {
int ret = 0;
+   u8 dpcd_ext = 0;
+   unsigned int dpcd_offset = 0;
struct drm_dp_mst_branch *mstb = NULL;
 
mutex_lock(>payload_lock);
@@ -3510,9 +3512,15 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
struct drm_dp_payload reset_pay;
 
WARN_ON(mgr->mst_primary);
+   drm_dp_dpcd_read(mgr->aux,
+DP_TRAINING_AUX_RD_INTERVAL,
+_ext, sizeof(dpcd_ext));
+
+   dpcd_offset =
+   ((dpcd_ext & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) ?  
DP_DP13_DPCD_REV : DP_DPCD_REV);
 
/* get dpcd info */
-   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd, 
DP_RECEIVER_CAP_SIZE);
+   ret = drm_dp_dpcd_read(mgr->aux, dpcd_offset, mgr->dpcd, 
DP_RECEIVER_CAP_SIZE);
if (ret != DP_RECEIVER_CAP_SIZE) {
DRM_DEBUG_KMS("failed to read DPCD\n");
goto out_unlock;
-- 
2.25.1

[PATCH 2/2] cpufreq: Do WARN() for invalid relation

[Viresh Kumar]

The relation can't be invalid here, if it is just WARN() and return 0.

Signed-off-by: Viresh Kumar 
---
 include/linux/cpufreq.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 8f141d4c859c..a911e5d06845 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -956,8 +956,8 @@ static inline int cpufreq_frequency_table_target(struct 
cpufreq_policy *policy,
case CPUFREQ_RELATION_C:
return cpufreq_table_find_index_c(policy, target_freq);
default:
-   pr_err("%s: Invalid relation: %d\n", __func__, relation);
-   return -EINVAL;
+   WARN_ON_ONCE(1);
+   return 0;
}
 }
 
-- 
2.25.0.rc1.19.g042ed3e048af

[PATCH 1/2] cpufreq: No need to verify cpufreq_driver in show_scaling_cur_freq()

[Viresh Kumar]

"cpufreq_driver" is guaranteed to be valid here, no need to check it
here.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02ab56b2a0d8..47aa90f9a7c2 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -703,8 +703,7 @@ static ssize_t show_scaling_cur_freq(struct cpufreq_policy 
*policy, char *buf)
freq = arch_freq_get_on_cpu(policy->cpu);
if (freq)
ret = sprintf(buf, "%u\n", freq);
-   else if (cpufreq_driver && cpufreq_driver->setpolicy &&
-   cpufreq_driver->get)
+   else if (cpufreq_driver->setpolicy && cpufreq_driver->get)
ret = sprintf(buf, "%u\n", cpufreq_driver->get(policy->cpu));
else
ret = sprintf(buf, "%u\n", policy->cur);
-- 
2.25.0.rc1.19.g042ed3e048af

Re: [PATCH v2 2/2] extcon: ptn5150: Set the VBUS and POLARITY property state

[Chanwoo Choi]

Hi,

On 8/27/20 2:17 PM, Ramuthevar, Vadivel MuruganX wrote:
> Hi,
> 
> On 27/8/2020 12:51 pm, Chanwoo Choi wrote:
>> Hi,
>>
>> You better to change the 'state' word to 'capability'.
>> Actually, this patch doesn't change the value of property.
>> It set the capability value of property.
>>
>> "Set the VBUS and POLARITY property capability"
> Thank you for the review comments, sure will update.
>>
>> On 8/27/20 12:56 PM, Ramuthevar,Vadivel MuruganX wrote:
>>> From: Ramuthevar Vadivel Murugan 
>>> 
>>>
>>> Set the VBUS and POLARITY property state.
>>
>> ditto. Need to change the work from 'state' and 'capability'.
> Noted.
>>
>>>
>>> Signed-off-by: Ramuthevar Vadivel Murugan 
>>> 
>>> ---
>>>   drivers/extcon/extcon-ptn5150.c | 6 ++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/extcon/extcon-ptn5150.c 
>>> b/drivers/extcon/extcon-ptn5150.c
>>> index 8b930050a3f1..b5217a61615c 100644
>>> --- a/drivers/extcon/extcon-ptn5150.c
>>> +++ b/drivers/extcon/extcon-ptn5150.c
>>> @@ -279,6 +279,12 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>>>   return ret;
>>>   }
>>>   +    extcon_set_property_capability(info->edev, EXTCON_USB,
>>> +   EXTCON_PROP_USB_VBUS);
>>> +    extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
>>> +   EXTCON_PROP_USB_VBUS);
>>> +    extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
>>> +   EXTCON_PROP_USB_TYPEC_POLARITY);
>>
>> Need to add blank line.
> Noted.
>>
>> I understood that you set the property capability
>> because of get_flipped() function of your patch[1].
>>
>> But, I think that you need to change the value of 
>> EXTCON_PROP_USB_TYPEC_POLARITY
>> when changing the state of EXTCON_USB_HOST. The polarity property value is 
>> always
>> zero regardless of EXTCON_USB_HOST state as following: The get_flipped()[1] 
>> returns
>> always the same *flipped value.
>>
>> EXTCON_USB_HOST is 1, EXTCON_PROP_USB_TYPEC_POLARITY is 0
>> EXTCON_USB_HOST is 0, EXTCON_PROP_USB_TYPEC_POLARITY is 0
> by default EXTCON_PROP_USB_TYPEC_POLARITY is 1

If you don't touch the value of EXTCON_PROP_USB_TYPEC_POLARITY property,
EXTCON_PROP_USB_TYPEC_POLARITY has default value (0).

>>
>> If EXTCON_PROP_USB_TYPEC_POLARITY value is not related to any behavior,
>> you don't need to get the property value from extcon consumer driver
>> like drivers/phy/phy-lgm-usb.c.
>>
>> Actually, I don't understand why you don't handle the value
>> of EXTCON_PROP_USB_TYPEC_POLARITY.
>>
>> Or, are there any case of what drivers/phy/phy-lgm-usb.c
>> uses the different extcon device with EXTCON_PROP_USB_TYPEC_POLARITY property
>> in the future?
> Yes, you're right, user connect the different USB cable then we check 
> polarity, accordingly driver proceeds, thanks!

OK.

>>
>> So, do you set the EXTCON_PROP_USB_TYPEC_POLARITY capability
>> for the extensibility in order to use other extcon device on later?
> yes, that might be the case as well.

OK.

>>
>>
>> [1] 
>> https://protect2.fireeye.com/v1/url?k=1fb29698-422c0d72-1fb31dd7-0cc47a6cba04-3009aa7184024984=1=566e4565-e7db-4a90-b036-fc28dbdb742f=https%3A%2F%2Fwww.spinics.net%2Flists%2Fdevicetree%2Fmsg371828.html
>> +static int get_flipped(struct tca_apb *ta, bool *flipped)
>> +{
>> +    union extcon_property_value property;
>> +    int ret;
>> +
>> +    ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
>> +  EXTCON_PROP_USB_TYPEC_POLARITY, );
>> +    if (ret) {
>> +    dev_err(ta->phy.dev, "no polarity property from extcon\n");
>> +    return ret;
>> +    }
>> +
>> +    *flipped = property.intval;
>> +
>> +    return ret;
>> +}
> Thank you for the gone through my usb-phy patch as well
> 
> Regards
> Vadivel
>>
>>
>>>   /* Initialize PTN5150 device and print vendor id and version id */
>>>   ret = ptn5150_init_dev_type(info);
>>>   if (ret)
>>>
>>
>>
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v2 1/2] extcon: ptn5150: Switch to GENMASK() and BIT() macros

[Ramuthevar, Vadivel MuruganX]

Hi,

On 27/8/2020 1:26 pm, Chanwoo Choi wrote:

-
+   vendor_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VENDOR, reg_data);
+   version_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VERSION, reg_data);
dev_dbg(info->dev, "Device type: version: 0x%x, vendor: 0x%x\n",
version_id, vendor_id);
  


Applied it. Thanks.

Thank you!

Regards
Vadivel

Re: Lockdep warning caused by "driver core: Fix sleeping in invalid context during device link deletion"

[Saravana Kannan]

On Thu, Aug 20, 2020 at 8:50 PM Dong Aisheng  wrote:
>
> Hi ALL,
>
> We met the below WARNING during system suspend on an iMX6Q SDB board
> with the latest linus/master branch (v5.9-rc1+) and next-20200820.
> v5.8 kernel is ok. So i did bisect and finally found it's caused by
> the patch below.
> Reverting it can get rid of the warning, but I wonder if there may be
> other potential issues.
> Any ideas?
>
> Defconfig used is: imx_v6_v7_defconfig
>

- 8< - Snipped text that was a bit misleading

>
> Error log:
> # echo mem > /sys/power/state
> [   39.111865] PM: suspend entry (deep)
> [   39.148650] Filesystems sync: 0.032 seconds
> [   39.154034]
> [   39.155537] ==
> [   39.161723] WARNING: possible circular locking dependency detected
> [   39.167911] 5.9.0-rc1-00103-g7eac66d0456f #37 Not tainted
> [   39.173315] --
> [   39.179500] sh/647 is trying to acquire lock:
> [   39.183862] c15a310c (dpm_list_mtx){+.+.}-{3:3}, at:
> dpm_for_each_dev+0x20/0x5c
> [   39.191200]
> [   39.191200] but task is already holding lock:
> [   39.197036] c15a37e4 (fw_lock){+.+.}-{3:3}, at: fw_pm_notify+0x90/0xd4
> [   39.203582]
> [   39.203582] which lock already depends on the new lock.
> [   39.203582]
> [   39.211763]
> [   39.211763] the existing dependency chain (in reverse order) is:
> [   39.219249]
> [   39.219249] -> #2 (fw_lock){+.+.}-{3:3}:
> [   39.224673]mutex_lock_nested+0x1c/0x24
> [   39.229126]firmware_uevent+0x18/0xa0
> [   39.233411]dev_uevent+0xc4/0x1f8
> [   39.237343]uevent_show+0x98/0x114
> [   39.241362]dev_attr_show+0x18/0x48
> [   39.245472]sysfs_kf_seq_show+0x84/0xec
> [   39.249927]seq_read+0x138/0x550
> [   39.253774]vfs_read+0x94/0x164
> [   39.257529]ksys_read+0x60/0xe8
> [   39.261288]ret_fast_syscall+0x0/0x28
> [   39.265564]0xbed7c808
> [   39.268538]
> [   39.268538] -> #1 (kn->active#3){}-{0:0}:
> [   39.274391]kernfs_remove_by_name_ns+0x40/0x94
> [   39.279450]device_del+0x144/0x3fc

Rafael/Greg,

I'm not very familiar with the #0 and #2 calls stacks. But poking
around a bit, they are NOT due to the device-link-device. But the new
stuff is the above two lines that are deleting the device-link-device
(that's used to expose device link details in sysfs) when the device
link is deleted.

Kicking off a workqueue to break this cycle is easy, but the problem
is that if I queue a work to delete the device, then the sysfs folder
won't get removed immediately. And if the same link is created again
before the work is completed, then there'll be a sysfs name collision
and warning.

So, I'm kinda stuck here. Open to suggestions. Hoping you'll have
better ideas for breaking the cycle. Or point out how I'm
misunderstanding the cycle here.

-Saravana

> [   39.283467]__device_link_del+0x4c/0x70
> [   39.287919]device_link_remove+0x5c/0x8c
> [   39.292464]_regulator_put.part.0+0x104/0x1dc
> [   39.297436]regulator_put+0x2c/0x3c
> [   39.299731] regulator regulator.5: Failed to increase supply voltage: -110
> [   39.301544]release_nodes+0x1b4/0x204
> [   39.301553]really_probe+0x104/0x3b4
> [   39.316881]driver_probe_device+0x58/0xb4
> [   39.321506]device_driver_attach+0x58/0x60
> [   39.326217]__driver_attach+0x58/0xd0
> [   39.330499]bus_for_each_dev+0x74/0xbc
> [   39.334863]bus_add_driver+0x150/0x1dc
> [   39.339227]driver_register+0x74/0x108
> [   39.343599]i2c_register_driver+0x38/0x8c
> [   39.348227]do_one_initcall+0x84/0x3b4
> [   39.352598]kernel_init_freeable+0x154/0x1e4
> [   39.357485]kernel_init+0x8/0x118
> [   39.361415]ret_from_fork+0x14/0x20
> [   39.365518]0x0
> [   39.367883]
> [   39.367883] -> #0 (dpm_list_mtx){+.+.}-{3:3}:
> [   39.373740]lock_acquire+0xe0/0x4ec
> [   39.377848]__mutex_lock+0x94/0x9d0
> [   39.381952]mutex_lock_nested+0x1c/0x24
> [   39.386405]dpm_for_each_dev+0x20/0x5c
> [   39.390769]fw_pm_notify+0xa4/0xd4
> [   39.394795]notifier_call_chain+0x48/0x80
> [   39.399420]__blocking_notifier_call_chain+0x48/0x64
> [   39.405003]__pm_notifier_call_chain+0x20/0x3c
> [   39.410063]pm_suspend+0x1ac/0x438
> [   39.414080]state_store+0x68/0xc8
> [   39.418013]kernfs_fop_write+0x10c/0x22c
> [   39.419741] cpu cpu0: failed to scale vddpu up: -110
> [   39.422551]vfs_write+0xbc/0x1d8
> [   39.422559]ksys_write+0x60/0xe8
> [   39.427529] cpufreq: __target_index: Failed to change cpu frequency: -110
> [   39.431362]ret_fast_syscall+0x0/0x28
> [   39.431368]0xbeec8958
> [   39.431372]
> [   39.431372] other info that might help us debug this:
> [   39.431372]
> [   39.431375] Chain exists of:
> [   

Re: [PATCH v2 2/2] extcon: ptn5150: Set the VBUS and POLARITY property state

[Ramuthevar, Vadivel MuruganX]

Hi,

On 27/8/2020 12:51 pm, Chanwoo Choi wrote:

Hi,

You better to change the 'state' word to 'capability'.
Actually, this patch doesn't change the value of property.
It set the capability value of property.

"Set the VBUS and POLARITY property capability"

Thank you for the review comments, sure will update.


On 8/27/20 12:56 PM, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

Set the VBUS and POLARITY property state.


ditto. Need to change the work from 'state' and 'capability'.

Noted.




Signed-off-by: Ramuthevar Vadivel Murugan 

---
  drivers/extcon/extcon-ptn5150.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 8b930050a3f1..b5217a61615c 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -279,6 +279,12 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
return ret;
}
  
+	extcon_set_property_capability(info->edev, EXTCON_USB,

+  EXTCON_PROP_USB_VBUS);
+   extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+  EXTCON_PROP_USB_VBUS);
+   extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+  EXTCON_PROP_USB_TYPEC_POLARITY);


Need to add blank line.

Noted.


I understood that you set the property capability
because of get_flipped() function of your patch[1].

But, I think that you need to change the value of EXTCON_PROP_USB_TYPEC_POLARITY
when changing the state of EXTCON_USB_HOST. The polarity property value is 
always
zero regardless of EXTCON_USB_HOST state as following: The get_flipped()[1] 
returns
always the same *flipped value.

EXTCON_USB_HOST is 1, EXTCON_PROP_USB_TYPEC_POLARITY is 0
EXTCON_USB_HOST is 0, EXTCON_PROP_USB_TYPEC_POLARITY is 0

by default EXTCON_PROP_USB_TYPEC_POLARITY is 1


If EXTCON_PROP_USB_TYPEC_POLARITY value is not related to any behavior,
you don't need to get the property value from extcon consumer driver
like drivers/phy/phy-lgm-usb.c.

Actually, I don't understand why you don't handle the value
of EXTCON_PROP_USB_TYPEC_POLARITY.

Or, are there any case of what drivers/phy/phy-lgm-usb.c
uses the different extcon device with EXTCON_PROP_USB_TYPEC_POLARITY property
in the future?
Yes, you're right, user connect the different USB cable then we check 
polarity, accordingly driver proceeds, thanks!


So, do you set the EXTCON_PROP_USB_TYPEC_POLARITY capability
for the extensibility in order to use other extcon device on later?

yes, that might be the case as well.



[1] https://www.spinics.net/lists/devicetree/msg371828.html
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+   union extcon_property_value property;
+   int ret;
+
+   ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, );
+   if (ret) {
+   dev_err(ta->phy.dev, "no polarity property from extcon\n");
+   return ret;
+   }
+
+   *flipped = property.intval;
+
+   return ret;
+}

Thank you for the gone through my usb-phy patch as well

Regards
Vadivel




/* Initialize PTN5150 device and print vendor id and version id */
ret = ptn5150_init_dev_type(info);
if (ret)

Re: [PATCH v2 1/2] extcon: ptn5150: Switch to GENMASK() and BIT() macros

[Chanwoo Choi]

On 8/27/20 12:56 PM, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Switch to GENMASK() and BIT() macros.
> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> Reviewed-by: Krzysztof Kozlowski 
> ---
>  drivers/extcon/extcon-ptn5150.c | 43 
> +++--
>  1 file changed, 11 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index 8ba706fad887..8b930050a3f1 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -7,6 +7,7 @@
>  // Author: Vijai Kumar K 
>  // Copyright (c) 2020 Krzysztof Kozlowski 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -35,29 +36,13 @@ enum ptn5150_reg {
>  #define PTN5150_UFP_ATTACHED 0x2
>  
>  /* Define PTN5150 MASK/SHIFT constant */
> -#define PTN5150_REG_DEVICE_ID_VENDOR_SHIFT   0
> -#define PTN5150_REG_DEVICE_ID_VENDOR_MASK\
> - (0x3 << PTN5150_REG_DEVICE_ID_VENDOR_SHIFT)
> +#define PTN5150_REG_DEVICE_ID_VERSIONGENMASK(7, 3)
> +#define PTN5150_REG_DEVICE_ID_VENDOR GENMASK(2, 0)
>  
> -#define PTN5150_REG_DEVICE_ID_VERSION_SHIFT  3
> -#define PTN5150_REG_DEVICE_ID_VERSION_MASK   \
> - (0x1f << PTN5150_REG_DEVICE_ID_VERSION_SHIFT)
> -
> -#define PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT 2
> -#define PTN5150_REG_CC_PORT_ATTACHMENT_MASK  \
> - (0x7 << PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT)
> -
> -#define PTN5150_REG_CC_VBUS_DETECTION_SHIFT  7
> -#define PTN5150_REG_CC_VBUS_DETECTION_MASK   \
> - (0x1 << PTN5150_REG_CC_VBUS_DETECTION_SHIFT)
> -
> -#define PTN5150_REG_INT_CABLE_ATTACH_SHIFT   0
> -#define PTN5150_REG_INT_CABLE_ATTACH_MASK\
> - (0x1 << PTN5150_REG_INT_CABLE_ATTACH_SHIFT)
> -
> -#define PTN5150_REG_INT_CABLE_DETACH_SHIFT   1
> -#define PTN5150_REG_INT_CABLE_DETACH_MASK\
> - (0x1 << PTN5150_REG_CC_CABLE_DETACH_SHIFT)
> +#define PTN5150_REG_CC_PORT_ATTACHMENT   GENMASK(4, 2)
> +#define PTN5150_REG_CC_VBUS_DETECTIONBIT(7)
> +#define PTN5150_REG_INT_CABLE_ATTACH_MASKBIT(0)
> +#define PTN5150_REG_INT_CABLE_DETACH_MASKBIT(1)
>  
>  struct ptn5150_info {
>   struct device *dev;
> @@ -95,9 +80,7 @@ static void ptn5150_check_state(struct ptn5150_info *info)
>   return;
>   }
>  
> - port_status = ((reg_data &
> - PTN5150_REG_CC_PORT_ATTACHMENT_MASK) >>
> - PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT);
> + port_status = FIELD_GET(PTN5150_REG_CC_PORT_ATTACHMENT, reg_data);
>  
>   switch (port_status) {
>   case PTN5150_DFP_ATTACHED:
> @@ -107,8 +90,7 @@ static void ptn5150_check_state(struct ptn5150_info *info)
>   break;
>   case PTN5150_UFP_ATTACHED:
>   extcon_set_state_sync(info->edev, EXTCON_USB, false);
> - vbus = ((reg_data & PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
> - PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
> + vbus = FIELD_GET(PTN5150_REG_CC_VBUS_DETECTION, reg_data);
>   if (vbus)
>   gpiod_set_value_cansleep(info->vbus_gpiod, 0);
>   else
> @@ -191,11 +173,8 @@ static int ptn5150_init_dev_type(struct ptn5150_info 
> *info)
>   return -EINVAL;
>   }
>  
> - vendor_id = ((reg_data & PTN5150_REG_DEVICE_ID_VENDOR_MASK) >>
> - PTN5150_REG_DEVICE_ID_VENDOR_SHIFT);
> - version_id = ((reg_data & PTN5150_REG_DEVICE_ID_VERSION_MASK) >>
> - PTN5150_REG_DEVICE_ID_VERSION_SHIFT);
> -
> + vendor_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VENDOR, reg_data);
> + version_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VERSION, reg_data);
>   dev_dbg(info->dev, "Device type: version: 0x%x, vendor: 0x%x\n",
>   version_id, vendor_id);
>  
> 

Applied it. Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] thermal: sysfs: fall back to vzalloc for cooling device's statistics

[Viresh Kumar]

On 27-08-20, 12:03, Yue Hu wrote:
> Hi Daniel,
> 
> Now, i'm just focus on removing the kernel warning based on current code 
> logic.
> Commit 8ea229511e06 (thermal: Add cooling device's statistics in sysfs) added
> the thermal statistics by viresh and viresh gived the patch an acknowledgement
> in anther mail thread. 
> 
> Hi viresh,
> 
> Could you review the patch again about the question above?

Yeah, I Acked it but the questions raised by Daniel are very valid and must be
answered.

I understand that you only cared about fixing the warning, but maybe we need to
fix the driver and the warning will go away by itself. If you don't want to do
it, then someone who is responsible for the driver should do it.

Was it the acpi_video.c driver that you got the warning from ? I have added
Rafael to the email in case that driver needs getting fixed.

-- 
viresh

linux-next: Tree for Aug 27

[Stephen Rothwell]

Hi all,

News:  There will be no linux-next releases next Monday or Tuesday.

Changes since 20200826:

The net-next tree gained a conflict against the net tree.

Non-merge commits (relative to Linus' tree): 2901
 3429 files changed, 100496 insertions(+), 37081 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (15bc20c6af4c Merge tag 'tty-5.9-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty)
Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1)
Merging kbuild-current/fixes (d012a7190fc1 Linux 5.9-rc2)
Merging arc-current/for-curr (37016ab49214 irqchip/eznps: Fix build error for 
!ARC700 builds)
Merging arm-current/fixes (5c6360ee4a0e ARM: 8988/1: mmu: fix crash in EFI 
calls due to p4d typo in create_mapping_late())
Merging arm64-fixes/for-next/fixes (8d75785a8142 ARM64: vdso32: Install vdso32 
from vdso_install)
Merging arm-soc-fixes/arm/fixes (9c8b0a9c37b7 Merge tag 'imx-fixes-5.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes)
Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2)
Merging drivers-memory-fixes/fixes (7ff3a2a626f7 memory: jz4780_nemc: Fix an 
error pointer vs NULL check in probe())
Merging m68k-current/for-linus (382f429bb559 m68k: defconfig: Update defconfigs 
for v5.8-rc3)
Merging powerpc-fixes/fixes (64ef8f2c4791 powerpc/perf/hv-24x7: Move cpumask 
file to top folder of hv-24x7 driver)
Merging s390-fixes/fixes (bffc2f7aa963 s390/vmem: fix vmem_add_range for 
4-level paging)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty 
inodes after removing key)
Merging net/master (5fd99b5d9950 net: cdc_ncm: Fix build error)
Merging bpf/master (7787b6fc938e bpf, sysctl: Let bpf_stats_handler take a 
kernel pointer buffer)
Merging ipsec/master (4eb2e1341575 espintcp: restore IP CB before handing the 
packet to xfrm)
Merging netfilter/master (3622adb02623 ipv6: ndisc: adjust 
ndisc_ifinfo_sysctl_change prototype)
Merging ipvs/master (7c7ab580db49 net: Convert to use the fallthrough macro)
Merging wireless-drivers/master (9a2a0862d973 brcmfmac: reserve tx credit only 
when txctl is ready to send)
Merging mac80211/master (fce2ff728f95 nl80211: fix 
NL80211_ATTR_HE_6GHZ_CAPABILITY usage)
Merging rdma-fixes/for-rc (60b1af64eb35 RDMA/rxe: Fix the parent sysfs read 
when the interface has 15 chars)
Merging sound-current/for-linus (858e0ad9301d ALSA: hda/hdmi: always check pin 
power status in i915 pin fixup)
Merging sound-asoc-fixes/for-linus (d563b6c834ae Merge series "ASoC: Fix return 
check for devm_regmap_init_sdw()" from Vinod Koul :)
Merging regmap-fixes/for-linus (d012a7190fc1 Linux 5.9-rc2)
Merging regulator-fixes/for-linus (3bec5b6aae83 Merge tag 'v5.9-rc2' into 
regulator-5.9)
Merging spi-fixes/for-linus (3812e0343b42 Merge remote-tracking branch 
'spi/for-5.9' into spi-linus)
Merging pci-current/for-linus (7c2308f79fc8 PCI/P2PDMA: Fix build without DMA 
ops)
Merging driver-core.current/driver-core-linus (d012a7190fc1 Linux 5.9-rc2)
Merging tty.current/tty-linus (ea1fc02e12b6 tty: serial: imx: add dependence 
and build for ear

Re: [PATCH 1/2] power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge

[Andreas Kemnade]

Hi,

On Wed, 26 Aug 2020 23:59:50 +0200
Sebastian Reichel  wrote:

> Hi,
> 
> On Wed, Aug 26, 2020 at 08:28:34PM +0200, Andreas Kemnade wrote:
> > On Wed, 26 Aug 2020 19:48:17 +0200
> > Sebastian Reichel  wrote:  
> > > On Sat, Aug 15, 2020 at 06:56:09PM +0200, Andreas Kemnade wrote:  
> > > > [...]
> > > > +static int rn5t618_battery_current_now(struct rn5t618_power_info *info,
> > > > +  union power_supply_propval *val)
> > > > +{
> > > > +   u16 res;
> > > > +   int ret;
> > > > +
> > > > +   ret = rn5t618_battery_read_doublereg(info, RN5T618_CC_AVEREG1, 
> > > > );
> > > > +   if (ret)
> > > > +   return ret;
> > > > +
> > > > +   val->intval = res;
> > > > +   /* 2's complement */
> > > > +   if (val->intval & (1 << 13))
> > > > +   val->intval = val->intval - (1 << 14);  
> 
> Btw. I think sign_extend32() can be used here?
> 
> > > > +   /* negate current to be positive when discharging */
> > > > +   val->intval *= -1000;
> > > 
> > > mh, the sign is not documented (which should be fixed). At least
> > > sbs-battery does it the other way around (negative current when
> > > discharging, positive otherwise). Some drivers do not support
> > > signed current and always report positive values (e.g. ACPI driver).
> > > 
> > > What did you use as reference for swapping the sign?
> > >   
> > Well, I have searched for documentation, found nothing and used the
> > bq27xxx driver as reference  which I am used to from the GTA04/GTA02,
> > so things behave equal. That are the devices where a was most
> > intensively looking at those values.
> > I thought that there would be some unwritten rule about that.  
> 
> The mess is mostly due to lacking reviewing from my side
> (and possibly my predecessors). I just went through a dozen of
> drivers and it looks like most either do not support signed current
> (and use negative values as error code :() or use negative current
> for discharge. I could not find any other driver using negative
> numbers for charging. I think it's best to negative = discharge as
> official correct value and will send an update patch for the
> documentation later.
> 
ok, I will remove that sign-change and keep/update the comment
so that you know that the driver does it the official way
and send a v2 with the other things you mentioned.

Regards,
Andreas


pgp5ljy2PRtrW.pgp
Description: OpenPGP digital signature

[PATCH v2] debugobjects: install cpu hotplug callback

[qiang.zhang]

From: Zqiang 

Due to cpu hotplug, it may never be online after it's offline,
some objects in percpu pool is never free, in order to avoid
this happening, install cpu hotplug callback, call this callback
func to free objects in percpu pool when cpu going offline.

Signed-off-by: Zqiang 
---
 v1->v2:
 Modify submission information.

 include/linux/cpuhotplug.h |  1 +
 lib/debugobjects.c | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index a2710e654b64..2e77db655cfa 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -36,6 +36,7 @@ enum cpuhp_state {
CPUHP_X86_MCE_DEAD,
CPUHP_VIRT_NET_DEAD,
CPUHP_SLUB_DEAD,
+   CPUHP_DEBUG_OBJ_DEAD,
CPUHP_MM_WRITEBACK_DEAD,
CPUHP_MM_VMSTAT_DEAD,
CPUHP_SOFTIRQ_DEAD,
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index fe4557955d97..50e21ed0519e 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define ODEBUG_HASH_BITS   14
 #define ODEBUG_HASH_SIZE   (1 << ODEBUG_HASH_BITS)
@@ -433,6 +434,23 @@ static void free_object(struct debug_obj *obj)
}
 }
 
+#if defined(CONFIG_HOTPLUG_CPU)
+static int object_cpu_offline(unsigned int cpu)
+{
+   struct debug_percpu_free *percpu_pool;
+   struct hlist_node *tmp;
+   struct debug_obj *obj;
+
+   percpu_pool = per_cpu_ptr(_obj_pool, cpu);
+   hlist_for_each_entry_safe(obj, tmp, _pool->free_objs, node) {
+   hlist_del(>node);
+   kmem_cache_free(obj_cache, obj);
+   }
+
+   return 0;
+}
+#endif
+
 /*
  * We run out of memory. That means we probably have tons of objects
  * allocated.
@@ -1367,6 +1385,11 @@ void __init debug_objects_mem_init(void)
} else
debug_objects_selftest();
 
+#if defined(CONFIG_HOTPLUG_CPU)
+   cpuhp_setup_state_nocalls(CPUHP_DEBUG_OBJ_DEAD, "object:offline", NULL,
+   object_cpu_offline);
+#endif
+
/*
 * Increase the thresholds for allocating and freeing objects
 * according to the number of possible CPUs available in the system.
-- 
2.17.1

Re: [PATCH] i2c: do not acpi/of match device in i2c_device_probe()

[Sergey Senozhatsky]

On (20/08/26 18:16), Andy Shevchenko wrote:
> On Wed, Aug 26, 2020 at 11:49:20PM +0900, Sergey Senozhatsky wrote:
> > i2c, apparently, can match the same device twice - the first
> > time in ->match bus hook (i2c_device_match()), and the second
> > one in ->probe (i2c_device_probe()) bus hook.
> > 
> > To make things more complicated, the second matching does not
> > do exactly same checks as the first one. Namely, i2c_device_match()
> > calls acpi_driver_match_device() which considers devices that
> > provide of_match_table and performs of_compatible() matching for
> > such devices. One important thing to note here is that ACPI
> > of_compatible() matching (acpi_of_match_device()) is part of ACPI
> > and does not depend on CONFIG_OF.
> > 
> > i2c_device_probe(), on the other hand, calls acpi_match_device()
> > which does not perform of_compatible() matching, but instead
> > i2c_device_probe() relies on CONFIG_OF API to perform of_match_table
> > matching, IOW ->probe matching, unlike ->match matching, depends on
> > CONFIG_OF. This can break i2c device probing on !CONFIG_OF systems
> > if the device does not provide .id_table.
> > 
> >  i2c_device_probe()
> >  ...
> >if (!driver->id_table &&
> >!i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
> >!i2c_of_match_device(dev->driver->of_match_table, client)) {
> >status = -ENODEV;
> >goto put_sync_adapter;
> >}
> > 
> > i2c_of_match_device() on !CONFIG_OF systems is always false, so we never
> > perform of_match_table matching. i2c_acpi_match_device() does ACPI match
> > only, no of_compatible() matching takes place, even though the device
> > provides .of_match_table and ACPI is capable of matching such device.
> > 
> > It is not entirely clear why the device is matched again in bus
> > ->probe after successful and proper matching in bus ->match. Let's
> > remove ->probe matching.
> 
> Reviewed-by: Andy Shevchenko 
> (assuming it's okay to go)

Thanks.

I tested the patch on x86_64 (a mix of i2c devices with and without
.id_table) and arm64 boards - didn't notice any difference, module
probing wise.

-ss

Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

[Kai Heng Feng]

Hi Ville,

> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä  
> wrote:
> 
> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
>> LSPCON only supports 8 bpc for RGB/YCbCr444.
>> 
>> Set the correct bpp otherwise it renders blank screen.
> 
> Hmm. Does 
> git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> work?
> 
> Actually better make that dp_downstream_ports_5^^^ aka.
> 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> converters") to avoid the experiments and hacks I have sitting on top.

Can you please rebase it to mainline master or drm-tip?

I am getting errors on the branch:

  DESCEND  objtool
  CALLscripts/atomic/check-atomics.sh
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  Building modules, stage 2.
  MODPOST 166 modules
  LD  arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of 
`__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first defined 
here
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only 
section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
make[2]: *** [arch/x86/boot/compressed/Makefile:119: 
arch/x86/boot/compressed/vmlinux] Error 1
make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux] 
Error 2
make: *** [arch/x86/Makefile:284: bzImage] Error 2
make: *** Waiting for unfinished jobs

Kai-Heng

> 
>> 
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
>> b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> index b781bf469644..c7a44fcaade8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
>> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector 
>> *connector,
>>  crtc_state->port_clock /= 2;
>>  crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
>>  crtc_state->lspcon_downsampling = true;
>> -}
>> +} else
>> +crtc_state->pipe_bpp = 24;
>> }
>> 
>> static bool lspcon_probe(struct intel_lspcon *lspcon)
>> -- 
>> 2.17.1
> 
> -- 
> Ville Syrjälä
> Intel

Re: [PATCH v2 3/3] usb typec: mt6360: Prevent the race condition during module remove

[啟原黃]

Guenter Roeck  於 2020年8月27日 週四 上午11:34寫道：
>
> On 8/26/20 8:25 PM, cy_huang wrote:
> > From: ChiYuan Huang 
> >
> > Prevent the race condition from interrupt and tcpci port unregister
> > during module remove.
> >
> > Signed-off-by: ChiYuan Huang 
>
> Please squash with the first patch of the series.
Done, squash into the first one and resend the patch. Thx.
>
> Thanks,
> Guenter
>
> > ---
> >  drivers/usb/typec/tcpm/tcpci_mt6360.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
> > b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > index 6a28193..a381b5d 100644
> > --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > @@ -164,6 +164,7 @@ static int mt6360_tcpc_remove(struct platform_device 
> > *pdev)
> >  {
> >   struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
> >
> > + disable_irq(mti->irq);
> >   tcpci_unregister_port(mti->tcpci);
> >   return 0;
> >  }
> >
>

[PATCH v2 1/2] usb typec: mt6360: Add support for mt6360 Type-C driver

[cy_huang]

From: ChiYuan Huang 

Mediatek MT6360 is a multi-functional IC that includes USB Type-C.
It works with Type-C Port Controller Manager to provide USB PD
and USB Type-C functionalities.

Add fix to Prevent the race condition from interrupt and tcpci port unregister
during module remove.

Signed-off-by: ChiYuan Huang 
---
 drivers/usb/typec/tcpm/Kconfig|   8 ++
 drivers/usb/typec/tcpm/Makefile   |   1 +
 drivers/usb/typec/tcpm/tcpci_mt6360.c | 213 ++
 3 files changed, 222 insertions(+)
 create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6360.c

diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index fa3f393..58a64e1 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -27,6 +27,14 @@ config TYPEC_RT1711H
  Type-C Port Controller Manager to provide USB PD and USB
  Type-C functionalities.
 
+config TYPEC_MT6360
+   tristate "Mediatek MT6360 Type-C driver"
+   depends on MFD_MT6360
+   help
+ Mediatek MT6360 is a multi-functional IC that includes
+ USB Type-C. It works with Type-C Port Controller Manager
+ to provide USB PD and USB Type-C functionalities.
+
 endif # TYPEC_TCPCI
 
 config TYPEC_FUSB302
diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
index a5ff6c8..7592ccb 100644
--- a/drivers/usb/typec/tcpm/Makefile
+++ b/drivers/usb/typec/tcpm/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_TYPEC_WCOVE)   += typec_wcove.o
 typec_wcove-y  := wcove.o
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
 obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
+obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
b/drivers/usb/typec/tcpm/tcpci_mt6360.c
new file mode 100644
index ..a381b5d
--- /dev/null
+++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright (C) 2020 MediaTek Inc.
+//
+// Author: ChiYuan Huang 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tcpci.h"
+
+#define MT6360_REG_VCONNCTRL1  0x8C
+#define MT6360_REG_MODECTRL2   0x8F
+#define MT6360_REG_SWRESET 0xA0
+#define MT6360_REG_DEBCTRL10xA1
+#define MT6360_REG_DRPCTRL10xA2
+#define MT6360_REG_DRPCTRL20xA3
+#define MT6360_REG_I2CTORST0xBF
+#define MT6360_REG_RXCTRL2 0xCF
+#define MT6360_REG_CTDCTRL20xEC
+
+/* MT6360_REG_VCONNCTRL1 */
+#define MT6360_VCONNCL_ENABLE  BIT(0)
+/* MT6360_REG_RXCTRL2 */
+#define MT6360_OPEN40M_ENABLE  BIT(7)
+/* MT6360_REG_CTDCTRL2 */
+#define MT6360_RPONESHOT_ENABLEBIT(6)
+
+struct mt6360_tcpc_info {
+   struct tcpci_data tdata;
+   struct tcpci *tcpci;
+   struct device *dev;
+   int irq;
+};
+
+static inline int mt6360_tcpc_read16(struct regmap *regmap,
+unsigned int reg, u16 *val)
+{
+   return regmap_raw_read(regmap, reg, val, sizeof(u16));
+}
+
+static inline int mt6360_tcpc_write16(struct regmap *regmap,
+ unsigned int reg, u16 val)
+{
+   return regmap_raw_write(regmap, reg, , sizeof(u16));
+}
+
+static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
+{
+   struct regmap *regmap = tdata->regmap;
+   int ret;
+
+   ret = regmap_write(regmap, MT6360_REG_SWRESET, 0x01);
+   if (ret)
+   return ret;
+
+   /* after reset command, wait 1~2ms to wait IC action */
+   usleep_range(1000, 2000);
+
+   /* write all alert to masked */
+   ret = mt6360_tcpc_write16(regmap, TCPC_ALERT_MASK, 0);
+   if (ret)
+   return ret;
+
+   /* config I2C timeout reset enable , and timeout to 200ms */
+   ret = regmap_write(regmap, MT6360_REG_I2CTORST, 0x8F);
+   if (ret)
+   return ret;
+
+   /* config CC Detect Debounce : 26.7*val us */
+   ret = regmap_write(regmap, MT6360_REG_DEBCTRL1, 0x10);
+   if (ret)
+   return ret;
+
+   /* DRP Toggle Cycle : 51.2 + 6.4*val ms */
+   ret = regmap_write(regmap, MT6360_REG_DRPCTRL1, 4);
+   if (ret)
+   return ret;
+
+   /* DRP Duyt Ctrl : dcSRC: /1024 */
+   ret = mt6360_tcpc_write16(regmap, MT6360_REG_DRPCTRL2, 330);
+   if (ret)
+   return ret;
+
+   /* Enable VCONN Current Limit function */
+   ret = regmap_update_bits(regmap, MT6360_REG_VCONNCTRL1, 
MT6360_VCONNCL_ENABLE,
+MT6360_VCONNCL_ENABLE);
+   if (ret)
+   return ret;
+
+   /* Enable cc open 40ms when pmic send vsysuv signal */
+   ret = regmap_update_bits(regmap, MT6360_REG_RXCTRL2, 
MT6360_OPEN40M_ENABLE,
+MT6360_OPEN40M_ENABLE);
+   if (ret)
+   return ret;
+
+   /* Enable Rpdet oneshot detection */
+   ret = regmap_update_bits(regmap, MT6360_REG_CTDCTRL2, 

Re: [PATCH 1/3] dt-bindings: dmaengine: Document qcom,gpi dma binding

[Vinod Koul]

On 26-08-20, 08:35, Rob Herring wrote:
> On Wed, Aug 26, 2020 at 12:32 AM Vinod Koul  wrote:
> >
> > On 25-08-20, 20:21, Vinod Koul wrote:
> > > Hey Rob,
> > >
> > > On 24-08-20, 11:40, Rob Herring wrote:
> > > > On Mon, 24 Aug 2020 14:17:10 +0530, Vinod Koul wrote:
> > > > > Add devicetree binding documentation for GPI DMA controller
> > > > > implemented on Qualcomm SoCs
> > > > >
> > > > > Signed-off-by: Vinod Koul 
> > > > > ---
> > > > >  .../devicetree/bindings/dma/qcom-gpi.yaml | 87 
> > > > > +++
> > > > >  1 file changed, 87 insertions(+)
> > > > >  create mode 100644 
> > > > > Documentation/devicetree/bindings/dma/qcom-gpi.yaml
> > > > >
> > > >
> > > >
> > > > My bot found errors running 'make dt_binding_check' on your patch:
> > > >
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma/qcom-gpi.yaml:
> > > >  properties:qcom,ev-factor: {'description': 'Event ring transfer size 
> > > > compare to channel transfer ring. Event ring length = ev-factor * 
> > > > transfer ring size', 'maxItems': 1} is not valid under any of the given 
> > > > schemas (Possible causes of the failure):
> > > > 
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma/qcom-gpi.yaml:
> > > >  properties:qcom,ev-factor: 'not' is a required property
> > >
> > > Okay updating dt-schema I do see this, now the question is what is this
> > > and what does it mean ;-) I am not sure I comprehend the error message.
> > > I see this for all the new properties I added as required for this
> > > device node
> >
> > Okay I think I have figured it out, I need to provide ref to
> > /schemas/types.yaml#definitions/uint32 for this to work, which does
> > makes sense to me.
> >
> >   qcom,max-num-gpii:
> > $ref: /schemas/types.yaml#definitions/uint32
> > maxItems: 1
> 
> uint32 is always 1 item, so drop. Is there a max value you can define?

Sorry not sure I follow, to clarify you mean drop uint32, if so which
type to use u8? I can use u8 as max wont be beyond 255.

Yes I will define min as well max values too.

> Otherwise, up to 2^32 - 1 is valid.

I see one more warning given by your bot which I am able to reproduce as
well:
Documentation/devicetree/bindings/dma/qcom,gpi.example.dt.yaml: example-0: 
dma-controller@80:reg:0: [0, 8388608, 0, 393216] is too long

So to fix this I added the #address-cells and #size-cells

#address-cells = <2>;
#size-cells = <2>;
reg = <0x0 0x0080 0x0 0x6>;

But I am getting the warning, what am I doing incorrect

-- 
~Vinod

linux-next: build failure after upgrading sphinx

[Stephen Rothwell]

Hi all,

Today I upgraded ot sphinx v3.2.1 and got the following error from
"make htmldocs":

Running Sphinx v3.2.1
enabling CJK for LaTeX builder

Extension error:
Could not import extension cdomain (exception: cannot import name 
'c_funcptr_sig_re' from 'sphinx.domains.c' 
(/usr/lib/python3/dist-packages/sphinx/domains/c.py))

I have downgraded to version 2.4.3 and await suggestions/patches :-)

-- 
Cheers,
Stephen Rothwell


pgpOxRaqIun_C.pgp
Description: OpenPGP digital signature

[PATCH v2 2/2] usb typec: mt6360: Add MT6360 Type-C DT binding documentation

[cy_huang]

From: ChiYuan Huang 

Add a devicetree binding documentation for the MT6360 Type-C driver.

Signed-off-by: ChiYuan Huang 
---
 .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml 
b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
new file mode 100644
index ..9e8ab0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT 
bindings
+
+maintainers:
+  - ChiYuan Huang 
+
+description: |
+  Mediatek MT6360 is a multi-functional device. It integrates charger, ADC, 
flash, RGB indicators,
+  regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery 
controller.
+  This document only describes MT6360 Type-C Port Switch and Power Delivery 
controller.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt6360-tcpc
+
+  interrupts-extended:
+maxItems: 1
+
+  interrupt-names:
+items:
+  - const: PD_IRQB
+
+patternProperties:
+  "connector":
+type: object
+$ref: ../connector/usb-connector.yaml#
+description:
+  Properties for usb c connector.
+
+additionalProperties: false
+
+required:
+  - compatible
+  - interrupts-extended
+  - interrupt-names
+
+examples:
+  - |
+#include 
+#include 
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mt6360@34 {
+compatible = "mediatek,mt6360";
+reg = <0x34>;
+
+tcpc {
+compatible = "mediatek,mt6360-tcpc";
+interrupts-extended = < 3 IRQ_TYPE_LEVEL_LOW>;
+interrupt-names = "PD_IRQB";
+
+connector {
+compatible = "usb-c-connector";
+label = "USB-C";
+data-role = "dual";
+power-role = "dual";
+try-power-role = "sink";
+source-pdos = ;
+sink-pdos = ;
+op-sink-microwatt = <1000>;
+};
+};
+};
+};
+...
-- 
2.7.4

RE: [EXT] Re: [PATCH v2] mwifiex: don't call del_timer_sync() on uninitialized timer

[Ganapathi Bhat]

Hi Tetsuo,

> > "grep -FrB1 'del_timer' drivers/ | grep -FA1 '.function)'" says that
> > currently there are 28 locations which call del_timer[_sync]() only if
> > that timer's function field was initialized (because timer_setup()
> > sets that timer's function field). Therefore, let's use same approach here.

Thanks for the change, it look cleaner than my re-work;

Acked-by: Ganapathi Bhat 

Regards,
Ganapathi

[tip:ras/core] BUILD SUCCESS 1e36d9c6886849c6f3d3c836370563e6bc1a6ddd

[kernel test robot]

allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a002-20200826
i386 randconfig-a004-20200826
i386 randconfig-a003-20200826
i386 randconfig-a005-20200826
i386 randconfig-a006-20200826
i386 randconfig-a001-20200826
x86_64   randconfig-a015-20200826
x86_64   randconfig-a016-20200826
x86_64   randconfig-a012-20200826
x86_64   randconfig-a014-20200826
x86_64   randconfig-a011-20200826
x86_64   randconfig-a013-20200826
i386 randconfig-a013-20200826
i386 randconfig-a012-20200826
i386 randconfig-a011-20200826
i386 randconfig-a016-20200826
i386 randconfig-a015-20200826
i386 randconfig-a014-20200826
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH v36 22/24] selftests/x86: Add a selftest for SGX

[Nathaniel McCallum]

On Thu, Jul 16, 2020 at 9:58 AM Jarkko Sakkinen
 wrote:
>
> Add a selftest for SGX. It is a trivial test where a simple enclave
> copies one 64-bit word of memory between two memory locations.
>
> Cc: linux-kselft...@vger.kernel.org
> Signed-off-by: Jarkko Sakkinen 
> ---
>  tools/testing/selftests/Makefile  |   1 +
>  tools/testing/selftests/sgx/.gitignore|   2 +
>  tools/testing/selftests/sgx/Makefile  |  53 +++
>  tools/testing/selftests/sgx/call.S|  54 +++
>  tools/testing/selftests/sgx/defines.h |  21 +
>  tools/testing/selftests/sgx/load.c| 282 +
>  tools/testing/selftests/sgx/main.c| 199 +
>  tools/testing/selftests/sgx/main.h|  38 ++
>  tools/testing/selftests/sgx/sigstruct.c   | 395 ++
>  tools/testing/selftests/sgx/test_encl.c   |  20 +
>  tools/testing/selftests/sgx/test_encl.lds |  40 ++
>  .../selftests/sgx/test_encl_bootstrap.S   |  89 
>  12 files changed, 1194 insertions(+)
>  create mode 100644 tools/testing/selftests/sgx/.gitignore
>  create mode 100644 tools/testing/selftests/sgx/Makefile
>  create mode 100644 tools/testing/selftests/sgx/call.S
>  create mode 100644 tools/testing/selftests/sgx/defines.h
>  create mode 100644 tools/testing/selftests/sgx/load.c
>  create mode 100644 tools/testing/selftests/sgx/main.c
>  create mode 100644 tools/testing/selftests/sgx/main.h
>  create mode 100644 tools/testing/selftests/sgx/sigstruct.c
>  create mode 100644 tools/testing/selftests/sgx/test_encl.c
>  create mode 100644 tools/testing/selftests/sgx/test_encl.lds
>  create mode 100644 tools/testing/selftests/sgx/test_encl_bootstrap.S
>
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index 1195bd85af38..ec7be6d5a10d 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -64,6 +64,7 @@ TARGETS += user
>  TARGETS += vm
>  TARGETS += x86
>  TARGETS += zram
> +TARGETS += sgx
>  #Please keep the TARGETS list alphabetically sorted
>  # Run "make quicktest=1 run_tests" or
>  # "make quicktest=1 kselftest" from top level Makefile
> diff --git a/tools/testing/selftests/sgx/.gitignore 
> b/tools/testing/selftests/sgx/.gitignore
> new file mode 100644
> index ..fbaf0bda9a92
> --- /dev/null
> +++ b/tools/testing/selftests/sgx/.gitignore
> @@ -0,0 +1,2 @@
> +test_sgx
> +test_encl.elf
> diff --git a/tools/testing/selftests/sgx/Makefile 
> b/tools/testing/selftests/sgx/Makefile
> new file mode 100644
> index ..95e5c4df8014
> --- /dev/null
> +++ b/tools/testing/selftests/sgx/Makefile
> @@ -0,0 +1,53 @@
> +top_srcdir = ../../../..
> +
> +include ../lib.mk
> +
> +.PHONY: all clean
> +
> +CAN_BUILD_X86_64 := $(shell ../x86/check_cc.sh $(CC) \
> +   ../x86/trivial_64bit_program.c)
> +
> +ifndef OBJCOPY
> +OBJCOPY := $(CROSS_COMPILE)objcopy
> +endif
> +
> +INCLUDES := -I$(top_srcdir)/tools/include
> +HOST_CFLAGS := -Wall -Werror -g $(INCLUDES) -fPIC -z noexecstack
> +ENCL_CFLAGS := -Wall -Werror -static -nostdlib -nostartfiles -fPIC \
> +  -fno-stack-protector -mrdrnd $(INCLUDES)
> +
> +TEST_CUSTOM_PROGS := $(OUTPUT)/test_sgx $(OUTPUT)/test_encl.elf
> +
> +ifeq ($(CAN_BUILD_X86_64), 1)
> +all: $(TEST_CUSTOM_PROGS)
> +endif
> +
> +$(OUTPUT)/test_sgx: $(OUTPUT)/main.o \
> +   $(OUTPUT)/load.o \
> +   $(OUTPUT)/sigstruct.o \
> +   $(OUTPUT)/call.o
> +   $(CC) $(HOST_CFLAGS) -o $@ $^ -lcrypto
> +
> +$(OUTPUT)/main.o: main.c
> +   $(CC) $(HOST_CFLAGS) -c $< -o $@
> +
> +$(OUTPUT)/load.o: load.c
> +   $(CC) $(HOST_CFLAGS) -c $< -o $@
> +
> +$(OUTPUT)/sigstruct.o: sigstruct.c
> +   $(CC) $(HOST_CFLAGS) -c $< -o $@
> +
> +$(OUTPUT)/call.o: call.S
> +   $(CC) $(HOST_CFLAGS) -c $< -o $@
> +
> +$(OUTPUT)/test_encl.elf: test_encl.lds test_encl.c test_encl_bootstrap.S
> +   $(CC) $(ENCL_CFLAGS) -T $^ -o $@
> +
> +EXTRA_CLEAN := \
> +   $(OUTPUT)/test_encl.elf \
> +   $(OUTPUT)/load.o \
> +   $(OUTPUT)/call.o \
> +   $(OUTPUT)/main.o \
> +   $(OUTPUT)/sigstruct.o \
> +   $(OUTPUT)/test_sgx \
> +   $(OUTPUT)/test_sgx.o \
> diff --git a/tools/testing/selftests/sgx/call.S 
> b/tools/testing/selftests/sgx/call.S
> new file mode 100644
> index ..77131e83db42
> --- /dev/null
> +++ b/tools/testing/selftests/sgx/call.S
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
> +/**
> +* Copyright(c) 2016-18 Intel Corporation.
> +*/
> +
> +   .text
> +
> +   .macro ENCLU
> +   .byte 0x0f, 0x01, 0xd7
> +   .endm
> +
> +   .text
> +
> +   .global sgx_call_vdso
> +sgx_call_vdso:
> +   .cfi_startproc
> +   push%r15
> +   .cfi_adjust_cfa_offset  8
> +   .cfi_rel_offset %r15, 0
> +   push%r14
> +   .cfi_adjust_cfa_offset  8
> +   .cfi_rel_offset %r14, 0
> +   

Re: [PATCH 1/4] dt-bindings: arm: ti: Add bindings for J7200 SoC

[Lokesh Vutla]

Hi Nishanth,

On 27/08/20 5:53 am, Nishanth Menon wrote:
> On 14:16-20200723, Lokesh Vutla wrote:
>> The J7200 SoC is a part of the K3 Multicore SoC architecture platform.
>> It is targeted for automotive gateway, vehicle compute systems,
>> Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications.
>> The SoC aims to meet the complex processing needs of modern embedded
>> products.
>>
>> Some highlights of this SoC are:
>> * Dual Cortex-A72s in a single cluster, two clusters of lockstep
>>   capable dual Cortex-R5F MCUs and a Centralized Device Management and
>>   Security Controller (DMSC).
>> * Configurable L3 Cache and IO-coherent architecture with high data
>>   throughput capable distributed DMA architecture under NAVSS.
>> * Integrated Ethernet switch supporting up to a total of 4 external ports
>>   in addition to legacy Ethernet switch of up to 2 ports.
>> * Upto 1 PCIe-GEN3 controller, 1 USB3.0 Dual-role device subsystems,
>>   20 MCANs, 3 McASP, eMMC and SD, OSPI/HyperBus memory controller, I3C and
>>   I2C, eCAP/eQEP, eHRPWM among other peripherals.
>> * One hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
>>   management.
>>
>> See J7200 Technical Reference Manual (SPRUIU1, June 2020)
>> for further details: https://www.ti.com/lit/pdf/spruiu1
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  Documentation/devicetree/bindings/arm/ti/k3.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt 
>> b/Documentation/devicetree/bindings/arm/ti/k3.txt
>> index 333e7256126a..33419cce0afa 100644
>> --- a/Documentation/devicetree/bindings/arm/ti/k3.txt
>> +++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
>> @@ -16,6 +16,9 @@ architecture it uses, using one of the following 
>> compatible values:
>>  - J721E
>>compatible = "ti,j721e";
>>  
>> +- J7200
>> +  compatible = "ti,j7200";
>> +
>>  Boards
>>  --
> 
> Lets convert the k3.txt to k3.yaml before we do anything more here.
> Looking at the full series, I see that there are pending comments from

okay, I can switch Patch 1 and 2.

> Grygorii as well which needs to be looked at. I have'nt seen a follow up
> version since this version.

Grygorii replied to the same asking to ignore his mail[0]

[0] https://patchwork.kernel.org/cover/11680441/

Thanks and regards,
Lokesh

> 
> [1] 
> https://lore.kernel.org/linux-arm-kernel/20200723084628.19241-1-lokeshvu...@ti.com/
> 

Re: [PATCH v2 2/2] extcon: ptn5150: Set the VBUS and POLARITY property state

[Chanwoo Choi]

Hi,

You better to change the 'state' word to 'capability'.
Actually, this patch doesn't change the value of property.
It set the capability value of property.

"Set the VBUS and POLARITY property capability"

On 8/27/20 12:56 PM, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Set the VBUS and POLARITY property state.

ditto. Need to change the work from 'state' and 'capability'.

> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> ---
>  drivers/extcon/extcon-ptn5150.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index 8b930050a3f1..b5217a61615c 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -279,6 +279,12 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>   return ret;
>   }
>  
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> +EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> +EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> +EXTCON_PROP_USB_TYPEC_POLARITY);

Need to add blank line.

I understood that you set the property capability
because of get_flipped() function of your patch[1].

But, I think that you need to change the value of EXTCON_PROP_USB_TYPEC_POLARITY
when changing the state of EXTCON_USB_HOST. The polarity property value is 
always
zero regardless of EXTCON_USB_HOST state as following: The get_flipped()[1] 
returns
always the same *flipped value.

EXTCON_USB_HOST is 1, EXTCON_PROP_USB_TYPEC_POLARITY is 0
EXTCON_USB_HOST is 0, EXTCON_PROP_USB_TYPEC_POLARITY is 0

If EXTCON_PROP_USB_TYPEC_POLARITY value is not related to any behavior,
you don't need to get the property value from extcon consumer driver
like drivers/phy/phy-lgm-usb.c.

Actually, I don't understand why you don't handle the value
of EXTCON_PROP_USB_TYPEC_POLARITY. 

Or, are there any case of what drivers/phy/phy-lgm-usb.c
uses the different extcon device with EXTCON_PROP_USB_TYPEC_POLARITY property
in the future?

So, do you set the EXTCON_PROP_USB_TYPEC_POLARITY capability 
for the extensibility in order to use other extcon device on later?


[1] https://www.spinics.net/lists/devicetree/msg371828.html
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+   union extcon_property_value property;
+   int ret;
+
+   ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, );
+   if (ret) {
+   dev_err(ta->phy.dev, "no polarity property from extcon\n");
+   return ret;
+   }
+
+   *flipped = property.intval;
+
+   return ret;
+}


>   /* Initialize PTN5150 device and print vendor id and version id */
>   ret = ptn5150_init_dev_type(info);
>   if (ret)
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] drm/ingenic: Fix driver not probing when IPU port is missing

[Sam Ravnborg]

Hi Paul.

On Wed, Aug 26, 2020 at 11:58:41PM +0200, Paul Cercueil wrote:
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
> 
> Fix the driver so that it will probe even if the IPU node is not present
> in devicetree (but then IPU support is disabled of course).
> 
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index ada990a7f911..216b67f1672e 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -673,6 +673,18 @@ static void ingenic_drm_unbind_all(void *d)
>   component_unbind_all(priv->dev, >drm);
>  }
>  
> +static inline struct device_node *ingenic_drm_get_ipu_node(struct device 
> *dev)
> +{
> + /* IPU is at port address 8 */
> + return of_graph_get_remote_node(dev->of_node, 8, 0);
> +}
kernel-doc for of_graph_get_remote_node() says:

* Return: Remote device node associated with remote endpoint node linked
*  to @node. Use of_node_put() on it when done.

In other words this code leaks a device node.
This was the case with the old code too.

Sam

> +
> +static inline bool ingenic_drm_has_ipu(struct device *dev)
> +{
> + return IS_ENABLED(CONFIG_DRM_INGENIC_IPU) &&
> + !!ingenic_drm_get_ipu_node(dev);
> +}
> +
>  static int ingenic_drm_bind(struct device *dev)
>  {
>   struct platform_device *pdev = to_platform_device(dev);
> @@ -808,7 +820,7 @@ static int ingenic_drm_bind(struct device *dev)
>   return ret;
>   }
>  
> - if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
> + if (ingenic_drm_has_ipu(dev)) {
>   ret = component_bind_all(dev, drm);
>   if (ret) {
>   if (ret != -EPROBE_DEFER)
> @@ -970,12 +982,9 @@ static int ingenic_drm_probe(struct platform_device 
> *pdev)
>   if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
>   return ingenic_drm_bind(dev);
>  
> - /* IPU is at port address 8 */
> - np = of_graph_get_remote_node(dev->of_node, 8, 0);
> - if (!np) {
> - dev_err(dev, "Unable to get IPU node\n");
> - return -EINVAL;
> - }
> + np = ingenic_drm_get_ipu_node(dev);
> + if (!np)
> + return ingenic_drm_bind(dev);
>  
>   drm_of_component_match_add(dev, , compare_of, np);
>  
> -- 
> 2.28.0

Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

[Hoegeun Kwon]

Hi Stefan,

Thank you for your review.


On 8/26/20 7:04 PM, Stefan Wahren wrote:
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>> There is a problem that the output does not work at a resolution
>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>> resolution exceeding FHD.
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?

As far as I know, BCM2711 raspberry pi 4 supports 4k,

don't supported on pi 3 and pi 3+.

Since 4k is not supported in versions prior to Raspberry Pi 4,

I don't think we need to modify the bvb clock.


So I think it is better to update 'brcm,bcm2711-hdmi.yaml'

instead of 'brcm,bcm2835-hdmi.yaml'.

Please comment, what do you think?

>
> I'm a little bit afraid, this change could break with older firmware
> versions on BCM283x.

Tested it several times with libdrm modetest.

I expect there will be no problem.


Best regards,

Hoegeun

>
> Best regards
> Stefan
>
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>   drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>   drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>   2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 95ec5eedea39..eb3192d1fd86 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -80,6 +80,7 @@
>>   # define VC4_HD_M_ENABLE   BIT(0)
>>   
>>   #define CEC_CLOCK_FREQ 4
>> +#define VC4_HSM_MID_CLOCK 149985000
>>   
>>   static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>   {
>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
>> drm_encoder *encoder)
>>  HDMI_WRITE(HDMI_VID_CTL,
>> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>   
>> +clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>   
>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
>> drm_encoder *encoder)
>>  return;
>>  }
>>   
>> +ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>> +(hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>> +if (ret) {
>> +DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> +ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>> +if (ret) {
>> +DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>>  if (vc4_hdmi->variant->reset)
>>  vc4_hdmi->variant->reset(vc4_hdmi);
>>   
>> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
>> *vc4_hdmi)
>>  return PTR_ERR(vc4_hdmi->audio_clock);
>>  }
>>   
>> +vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>> +if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>> +DRM_ERROR("Failed to get pixel bvb clock\n");
>> +return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>> +}
>> +
>>  vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>>  if (IS_ERR(vc4_hdmi->reset)) {
>>  DRM_ERROR("Failed to get HDMI reset line\n");
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> index 0806c6d9f24e..63c6f8bddf1d 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> @@ -147,6 +147,7 @@ struct vc4_hdmi {
>>  struct clk *pixel_clock;
>>  struct clk *hsm_clock;
>>  struct clk *audio_clock;
>> +struct clk *pixel_bvb_clock;
>>   
>>  struct reset_control *reset;
>>   
>

Re: [PATCH 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

[Lu Baolu]

Hi Kevin,

On 8/26/20 1:29 PM, Tian, Kevin wrote:

From: Lu Baolu
Sent: Wednesday, August 26, 2020 10:58 AM

The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
General
Description) that:

If multiple control fields in this register need to be modified, software
must serialize the modifications through multiple writes to this register.

However, in irq_remapping.c, modifications of IRE and CFI are done in one
write. We need to do two separate writes with STS checking after each.

Fixes: af8d102f999a4 ("x86/intel/irq_remapping: Clean up x2apic opt-out
security warning mess")
Cc: Andy Lutomirski 
Cc: Jacob Pan 
Signed-off-by: Lu Baolu 
---
  drivers/iommu/intel/irq_remapping.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index 9564d23d094f..19d7e18876fe 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -507,12 +507,16 @@ static void iommu_enable_irq_remapping(struct
intel_iommu *iommu)

/* Enable interrupt-remapping */
iommu->gcmd |= DMA_GCMD_IRE;
-   iommu->gcmd &= ~DMA_GCMD_CFI;  /* Block compatibility-format
MSIs */
writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
-
IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
  readl, (sts & DMA_GSTS_IRES), sts);

+   /* Block compatibility-format MSIs */
+   iommu->gcmd &= ~DMA_GCMD_CFI;
+   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
+   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
+ readl, !(sts & DMA_GSTS_CFIS), sts);
+


Better do it only when CFI is actually enabled (by checking sts).


Yes. Make sense. Will send a new version with this changed.

Best regards,
baolu




/*
 * With CFI clear in the Global Command register, we should be
 * protected from dangerous (i.e. compatibility) interrupts
--
2.17.1

___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v2 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

[Lu Baolu]

The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG General
Description) that:

If multiple control fields in this register need to be modified, software
must serialize the modifications through multiple writes to this register.

However, in irq_remapping.c, modifications of IRE and CFI are done in one
write. We need to do two separate writes with STS checking after each.

Fixes: af8d102f999a4 ("x86/intel/irq_remapping: Clean up x2apic opt-out 
security warning mess")
Cc: Andy Lutomirski 
Cc: Jacob Pan 
Cc: Kevin Tian 
Cc: Ashok Raj 
Signed-off-by: Lu Baolu 
---
 drivers/iommu/intel/irq_remapping.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

Change log:
v1->v2:
  - v1 posted here

https://lore.kernel.org/linux-iommu/20200826025825.2322-1-baolu...@linux.intel.com/;
  - Add status check before disabling CFI. (Kevin)

diff --git a/drivers/iommu/intel/irq_remapping.c 
b/drivers/iommu/intel/irq_remapping.c
index 9564d23d094f..7552bb7e92c8 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -507,12 +507,19 @@ static void iommu_enable_irq_remapping(struct intel_iommu 
*iommu)
 
/* Enable interrupt-remapping */
iommu->gcmd |= DMA_GCMD_IRE;
-   iommu->gcmd &= ~DMA_GCMD_CFI;  /* Block compatibility-format MSIs */
writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
-
IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
  readl, (sts & DMA_GSTS_IRES), sts);
 
+   /* Block compatibility-format MSIs */
+   sts = readl(iommu->reg + DMAR_GSTS_REG);
+   if (sts & DMA_GSTS_CFIS) {
+   iommu->gcmd &= ~DMA_GCMD_CFI;
+   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
+   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
+ readl, !(sts & DMA_GSTS_CFIS), sts);
+   }
+
/*
 * With CFI clear in the Global Command register, we should be
 * protected from dangerous (i.e. compatibility) interrupts
-- 
2.17.1

Re: [PATCH v2 1/2] drm/amdkfd: Move the ignore_crat check before the CRAT table get

[Felix Kuehling]

Am 2020-08-26 um 4:29 a.m. schrieb Hanjun Guo:
> If the ignore_crat is set to non-zero value, it's no point getting
> the CRAT table, so just move the ignore_crat check before we get the
> CRAT table.
>
> Signed-off-by: Hanjun Guo 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 6a250f8..ed77b109 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -764,6 +764,11 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
> *size)
>  
>   *crat_image = NULL;
>  
> + if (ignore_crat) {

A conflicting change in this area was just submitted on Monday to
amd-staging-drm-next. You'll need to rebase your patch. It should be
straight-forward. ignore_crat was replaced with a function call
kfd_ignore_crat().

Other than that, your patch series looks good to me. If I don't see an
update from you in a day or two, I'll fix it up myself and add my R-b.

Thanks,
  Felix


> + pr_info("CRAT table disabled by module option\n");
> + return -ENODATA;
> + }
> +
>   /* Fetch the CRAT table from ACPI */
>   status = acpi_get_table(CRAT_SIGNATURE, 0, _table);
>   if (status == AE_NOT_FOUND) {
> @@ -776,11 +781,6 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
> *size)
>   return -EINVAL;
>   }
>  
> - if (ignore_crat) {
> - pr_info("CRAT table disabled by module option\n");
> - return -ENODATA;
> - }
> -
>   pcrat_image = kmemdup(crat_table, crat_table->length, GFP_KERNEL);
>   if (!pcrat_image)
>   return -ENOMEM;

[tip:x86/urgent] BUILD SUCCESS d4f07268d035721dd055ceb0de98ace6ac5f858b

[kernel test robot]

   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a002-20200826
i386 randconfig-a004-20200826
i386 randconfig-a003-20200826
i386 randconfig-a005-20200826
i386 randconfig-a006-20200826
i386 randconfig-a001-20200826
x86_64   randconfig-a015-20200826
x86_64   randconfig-a016-20200826
x86_64   randconfig-a012-20200826
x86_64   randconfig-a014-20200826
x86_64   randconfig-a011-20200826
x86_64   randconfig-a013-20200826
i386 randconfig-a013-20200826
i386 randconfig-a012-20200826
i386 randconfig-a011-20200826
i386 randconfig-a016-20200826
i386 randconfig-a015-20200826
i386 randconfig-a014-20200826
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH v2 1/2] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver

[Viresh Kumar]

On 26-08-20, 20:57, Hector Yuan wrote:
> On Mon, 2020-08-24 at 15:36 +0530, Viresh Kumar wrote:
> > On 13-08-20, 15:07, Hector Yuan wrote:
> > >  CONFIG_ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM=m
> > >  CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
> > > +CONFIG_ARM_MEDIATEK_CPUFREQ_HW=m
> > 
> > What about a 'default m' in Kconfig itself ?
> > OK, will update in V3.

Hector, you need to remove (or not add) the right bracket (>) before the
beginning of your lines. This makes it incredibly difficult to read.

> > > + for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> > > + data = readl_relaxed(base + (i * LUT_ROW_SIZE));
> > > + freq = FIELD_GET(LUT_FREQ, data) * 1000;
> > > + volt = FIELD_GET(LUT_VOLT, data);
> > > + if (freq != prev_freq) {
> > > + table[i].frequency = freq;
> > > + dev_pm_opp_add(cpu_dev, freq * 1000, volt);
> > 
> > Why are you adding OPPs here and rather why using OPP specific stuff
> > at all in the driver ?
> > yes, the opp information is read from CPU HW engine.Then add it to the CPU 
> > dev OPP one by one.  

I asked a different question, why are you adding OPPs ? You don't need the OPPs
at all in my opinion. You can just create the frequency table and that's it.

> > > + for_each_possible_cpu(cpu) {
> > > + cpu_np = of_cpu_device_node_get(cpu);
> > > + if (!cpu_np)
> > > + continue;
> > > +
> > > + ret = of_parse_phandle_with_args(cpu_np, "mtk,freq-domain",
> > 
> > Where are bindings of this node and how does this look ?
> > Can refer to the same patch series, I split it to another patch.Each cpu 
> > will be group into one frequency domain for the CPU DVFS. 

That binding only defines "mediatek,cpufreq-hw" and not "mtk,freq-domain".

-- 
viresh

[PATCH v2] drm/vkms: avoid warning in vkms_get_vblank_timestamp

[Sidong Yang]

This patch avoid the warning in vkms_get_vblank_timestamp when vblanks aren't
enabled. When running igt test kms_cursor_crc just after vkms module, the
warning raised like below. Initial value of vblank time is zero and
hrtimer.node.expires is also zero if vblank aren't enabled before. vkms module
isn't real hardware but just virtual hardware module. so vkms can't generate a
resonable timestamp when hrtimer is off. it's best to grab the current time.

[106444.464503] [IGT] kms_cursor_crc: starting subtest pipe-A-cursor-size-change
[106444.471475] WARNING: CPU: 0 PID: 10109 at
/home/realwakka/git/linux/drivers/gpu/drm/vkms//vkms_crtc.c:91
vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471511] CPU: 0 PID: 10109 Comm: kms_cursor_crc Tainted: GW  OE
5.9.0-rc1+ #6
[106444.471514] RIP: 0010:vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471528] Call Trace:
[106444.471551]  drm_get_last_vbltimestamp+0xb9/0xd0 [drm]
[106444.471566]  drm_reset_vblank_timestamp+0x63/0xe0 [drm]
[106444.471579]  drm_crtc_vblank_on+0x85/0x150 [drm]
[106444.471582]  vkms_crtc_atomic_enable+0xe/0x10 [vkms]
[106444.471592]  drm_atomic_helper_commit_modeset_enables+0x1db/0x230
[drm_kms_helper]
[106444.471594]  vkms_atomic_commit_tail+0x38/0xc0 [vkms]
[106444.471601]  commit_tail+0x97/0x130 [drm_kms_helper]
[106444.471608]  drm_atomic_helper_commit+0x117/0x140 [drm_kms_helper]
[106444.471622]  drm_atomic_commit+0x4a/0x50 [drm]
[106444.471629]  drm_atomic_helper_set_config+0x63/0xb0 [drm_kms_helper]
[106444.471642]  drm_mode_setcrtc+0x1d9/0x7b0 [drm]
[106444.471654]  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471666]  drm_ioctl_kernel+0xb6/0x100 [drm]
[106444.471677]  drm_ioctl+0x3ad/0x470 [drm]
[106444.471688]  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471692]  ? tomoyo_file_ioctl+0x19/0x20
[106444.471694]  __x64_sys_ioctl+0x96/0xd0
[106444.471697]  do_syscall_64+0x37/0x80
[106444.471699]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Sidong Yang 

---

v2:
 - modify commit message to make it a bit easier to understand. 

---
 drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..09c012d54d58 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
struct vkms_output *output = >output;
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
+   if (!READ_ONCE(vblank->enabled)) {
+   *vblank_time = ktime_get();
+   return true;
+   }
+
*vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
 
if (WARN_ON(*vblank_time == vblank->time))
-- 
2.17.1

[tip:x86/cache] BUILD SUCCESS 29b6bd41ee24f69a85666b9f68d500b382d408fd

[kernel test robot]

allyesconfig
xtensa   allyesconfig
h8300allyesconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a002-20200826
i386 randconfig-a004-20200826
i386 randconfig-a003-20200826
i386 randconfig-a005-20200826
i386 randconfig-a006-20200826
i386 randconfig-a001-20200826
x86_64   randconfig-a015-20200826
x86_64   randconfig-a016-20200826
x86_64   randconfig-a012-20200826
x86_64   randconfig-a014-20200826
x86_64   randconfig-a011-20200826
x86_64   randconfig-a013-20200826
i386 randconfig-a013-20200826
i386 randconfig-a012-20200826
i386 randconfig-a011-20200826
i386 randconfig-a016-20200826
i386 randconfig-a015-20200826
i386 randconfig-a014-20200826
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes

[kernel test robot]

Hi Ard,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   15bc20c6af4ceee97a1f90b43c0e386643c071b4
commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move existing 
library code into lib/crypto
date:   9 months ago
config: i386-randconfig-r015-20200827 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git checkout 5fb8ef25803ef33e2eb60b626435828b937bed75
# save the attached .config to linux build tree
make W=1 ARCH=i386 

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

All warnings (new ones prefixed by >>):

   lib/crypto/chacha.c: In function 'chacha_permute':
>> lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger 
>> than 1024 bytes [-Wframe-larger-than=]
  65 | }
 | ^

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fb8ef25803ef33e2eb60b626435828b937bed75
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 5fb8ef25803ef33e2eb60b626435828b937bed75
vim +65 lib/crypto/chacha.c

e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  16  
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  17  static void 
chacha_permute(u32 *x, int nrounds)
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  18  {
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  19  int i;
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  20  
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  21  /* whitelist 
the allowed round counts */
aa7624093cb7fb lib/chacha.c   Eric Biggers  2018-11-16  22  
WARN_ON_ONCE(nrounds != 20 && nrounds != 12);
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  23  
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  24  for (i = 0; i < 
nrounds; i += 2) {
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  25  x[0]  
+= x[4];x[12] = rol32(x[12] ^ x[0],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  26  x[1]  
+= x[5];x[13] = rol32(x[13] ^ x[1],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  27  x[2]  
+= x[6];x[14] = rol32(x[14] ^ x[2],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  28  x[3]  
+= x[7];x[15] = rol32(x[15] ^ x[3],  16);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  29  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  30  x[8]  
+= x[12];   x[4]  = rol32(x[4]  ^ x[8],  12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  31  x[9]  
+= x[13];   x[5]  = rol32(x[5]  ^ x[9],  12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  32  x[10] 
+= x[14];   x[6]  = rol32(x[6]  ^ x[10], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  33  x[11] 
+= x[15];   x[7]  = rol32(x[7]  ^ x[11], 12);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  34  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  35  x[0]  
+= x[4];x[12] = rol32(x[12] ^ x[0],   8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  36  x[1]  
+= x[5];x[13] = rol32(x[13] ^ x[1],   8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  37  x[2]  
+= x[6];x[14] = rol32(x[14] ^ x[2],   8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  38  x[3]  
+= x[7];x[15] = rol32(x[15] ^ x[3],   8);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  39  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  40  x[8]  
+= x[12];   x[4]  = rol32(x[4]  ^ x[8],   7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  41  x[9]  
+= x[13];   x[5]  = rol32(x[5]  ^ x[9],   7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  42  x[10] 
+= x[14];   x[6]  = rol32(x[6]  ^ x[10],  7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  43  x[11] 
+= x[15];   x[7]  = rol32(x[7]  ^ x[11],  7);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  44  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  45  x[0]  
+= x[5];x[15] = rol32(x[15] ^ x[0],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  46  x[1]  
+= x[6];x[12] = rol32(x[12] ^ x[1],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  47  x[2]  
+= x[7];x[13] = rol32(x[13] ^ x[2],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  48  x[3]  
+= x[4];x[14] = rol32(x[14] ^ x[3],  16);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  49  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  50  x[10] 
+= x[15];   x[5]  = rol32(x[5]  ^ x[10], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  51

[PATCH v3] x86/hotplug: Silence APIC only after all irq's are migrated

[Ashok Raj]

There is a race when taking a CPU offline. Current code looks like this:

native_cpu_disable()
{
...
apic_soft_disable();
/*
 * Any existing set bits for pending interrupt to
 * this CPU are preserved and will be sent via IPI
 * to another CPU by fixup_irqs().
 */
cpu_disable_common();
{

/*
 * Race window happens here. Once local APIC has been
 * disabled any new interrupts from the device to
 * the old CPU are lost
 */
fixup_irqs(); // Too late to capture anything in IRR.
...
}
}

The fix is to disable the APIC *after* cpu_disable_common().

Testing was done with a USB NIC that provided a source of frequent
interrupts. A script migrated interrupts to a specific CPU and
then took that CPU offline.

Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead")
Link: https://lore.kernel.org/lkml/875zdarr4h@nanos.tec.linutronix.de/
Reported-by: Evan Green 
Tested-by: Mathias Nyman 
Tested-by: Evan Green 
Reviewed-by: Evan Green 
Signed-off-by: Ashok Raj 
---
v3:
Fix commit message and comments per Thomas.
https://lore.kernel.org/lkml/87mu2iw86q@nanos.tec.linutronix.de/

v2:
- Typos and fixes suggested by Randy Dunlap

To: linux-kernel@vger.kernel.org
To: Thomas Gleixner 
Cc: Sukumar Ghorai 
Cc: Srikanth Nandamuri 
Cc: Evan Green 
Cc: Mathias Nyman 
Cc: Bjorn Helgaas 
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
---
 arch/x86/kernel/smpboot.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 27aa04a95702..f5ef689dd62a 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1594,14 +1594,28 @@ int native_cpu_disable(void)
if (ret)
return ret;
 
-   /*
-* Disable the local APIC. Otherwise IPI broadcasts will reach
-* it. It still responds normally to INIT, NMI, SMI, and SIPI
-* messages.
-*/
-   apic_soft_disable();
cpu_disable_common();
 
+/*
+ * Disable the local APIC. Otherwise IPI broadcasts will reach
+ * it. It still responds normally to INIT, NMI, SMI, and SIPI
+ * messages.
+ *
+ * Disabling the APIC must happen after cpu_disable_common()
+ * which invokes fixup_irqs().
+ *
+ * Disabling the APIC preserves already set bits in IRR, but
+ * an interrupt arriving after disabling the local APIC does not
+ * set the corresponding IRR bit.
+ *
+ * fixup_irqs() scans IRR for set bits so it can raise a not
+ * yet handled interrupt on the new destination CPU via an IPI
+ * but obviously it can't do so for IRR bits which are not set.
+ * IOW, interrupts arriving after disabling the local APIC will
+ * be lost.
+ */
+   apic_soft_disable();
+
return 0;
 }
 
-- 
2.7.4

Re: [PATCH] thermal: sysfs: fall back to vzalloc for cooling device's statistics

[Yue Hu]

On Wed, 26 Aug 2020 11:19:02 +0200
Daniel Lezcano  wrote:

> Hi Yue,
> 
> On 26/08/2020 04:13, Yue Hu wrote:
> > On Mon, 24 Aug 2020 12:40:35 +0200
> > Daniel Lezcano  wrote:
> >   
> >> On 18/08/2020 08:30, Yue Hu wrote:  
> >>> From: Yue Hu 
> >>>
> >>> We observed warning about kzalloc() when register thermal cooling device
> >>> in backlight_device_register(). backlight display can be a cooling device
> >>> since reducing screen brightness will can help reduce temperature.
> >>>
> >>> However, ->get_max_state of backlight will assign max brightness of 1024
> >>> to states. The memory size can be getting 1MB+ due to states * states.
> >>
> >> What are the benefits of a 1024 states cooling device ? Is the
> >> difference noticeable with a such small step ?  
> > 
> > Okay, this issue is happened under MSM/Android platform. QCOM spmi wled 
> > driver
> > will define the max brightness. We needs to fix the issue to get thermal 
> > statistics.  
> 
> Let me rephrase my questions:
> 
> Don't you think there is something wrong in creating a 1024 x 1024
> matrix to show transitions ?
> 
> What is the benefit of such stats ?
> 
> What is the benefit of having a 1024 states cooling device ?

Hi Daniel,

Now, i'm just focus on removing the kernel warning based on current code logic.
Commit 8ea229511e06 (thermal: Add cooling device's statistics in sysfs) added
the thermal statistics by viresh and viresh gived the patch an acknowledgement
in anther mail thread. 

Hi viresh,

Could you review the patch again about the question above?

Thank you.

> 
> 
> 
> 

Re: [PATCH] m68k: Correct some typos in comments

[Finn Thain]

On Wed, 26 Aug 2020, Geert Uytterhoeven wrote:

> > @@ -2654,7 +2654,7 @@ func_startmmu_get_page_table_entry,%d0/%a1
> > jne 2f
> >
> > /* If the page table entry doesn't exist, we allocate a complete new
> > -* page and use it as one continues big page table which can cover
> > +* page and use it as one continuous big page table which can cover
> 
> Usually I use "contiguous", but the dictionary seems to permit both.
> 

Two or more things may be said to be "contiguous". I think this sentence 
refers to only one thing.

> >  * 4MB of memory, nearly almost all mappings have that alignment.
> >  */
> > get_new_page
> 
> Reviewed-by: Geert Uytterhoeven 
> i.e. will queue in the m68k for-v5.10 branch.
> 

Thanks.

> Gr{oetje,eeting}s,
> 
> Geert
> 

Re: [bio] 37abbdc72e: WARNING:at_block/bio.c:#bio_release_pages

[John Hubbard]

On 8/26/20 8:25 PM, kernel test robot wrote:
...

kern  :warn  : [   59.757746] [ cut here ]
kern  :warn  : [   59.758325] WARNING: CPU: 3 PID: 2581 at block/bio.c:955 
bio_release_pages+0xd7/0xe0
kern  :warn  : [   59.758952] Modules linked in: dm_mod netconsole btrfs 
blake2b_generic xor zstd_compress raid6_pq libcrc32c intel_rapl_msr sd_mod 
intel_rapl_common t10_pi x86_pkg_temp_thermal sg intel_powerclamp coretemp i915 
intel_gtt drm_kms_helper kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel syscopyarea rapl intel_cstate sysfillrect 
intel_uncore sysimgblt fb_sys_fops drm mei_me ipmi_devintf ahci libahci 
ipmi_msghandler libata mei joydev ie31200_edac video ip_tables
kern  :warn  : [   59.761834] CPU: 3 PID: 2581 Comm: aiodio_sparse Not tainted 
5.8.0-10182-g37abbdc72ec00 #1
kern  :warn  : [   59.762559] Hardware name: Hewlett-Packard p6-1451cx/2ADA, 
BIOS 8.15 02/05/2013
kern  :warn  : [   59.763295] RIP: 0010:bio_release_pages+0xd7/0xe0
kern  :warn  : [   59.763983] Code: e1 89 d5 81 e2 ff 0f 00 00 c1 ed 0c 29 d1 48 c1 
e5 06 48 03 28 eb 9c 48 8b 45 08 a8 01 75 c0 48 89 ef e8 8c f0 d2 ff eb b6 c3 
<0f> 0b c3 66 0f 1f 44 00 00 0f 1f 44 00 00 41 54 31 c0 55 bd 00 10
kern  :warn  : [   59.765596] RSP: :c9124e68 EFLAGS: 00010246
kern  :warn  : [   59.766339] RAX: 0a00 RBX: 888212c3f2a0 RCX: 

kern  :warn  : [   59.767124] RDX: fff41387 RSI:  RDI: 
88821fae3000
kern  :warn  : [   59.767950] RBP: 88821fae3000 R08: 88821f1d1c00 R09: 

kern  :warn  : [   59.768726] R10: 88821f1d1a10 R11: 88821faab3b0 R12: 
4001
kern  :warn  : [   59.769513] R13: 0400 R14: 2c00 R15: 

kern  :warn  : [   59.770294] FS:  7fb0401ef740() 
GS:88821fb8() knlGS:
kern  :warn  : [   59.771112] CS:  0010 DS:  ES:  CR0: 80050033
kern  :warn  : [   59.771908] CR2: 7ffc3fc11000 CR3: 00012477e006 CR4: 
001706e0
kern  :warn  : [   59.772720] Call Trace:
kern  :warn  : [   59.773466]  
kern  :warn  : [   59.774200]  iomap_dio_bio_end_io+0x5f/0x100


ah, this is self-inflicted, because my new pin_user_page() (which is called
from iomap_dio_bio_end_io) doesn't set BIO_FOLL_PIN.

Obsolete, now that BIO_FOLL_PIN is not going to happen, but it's good to see
that the system isn't doing anything unexpected here.

thanks,
--
John Hubbard
NVIDIA


kern  :warn  : [   59.774973]  blk_update_request+0x219/0x3c0
kern  :warn  : [   59.775767]  scsi_end_request+0x29/0x140
kern  :warn  : [   59.776538]  scsi_io_completion+0x7a/0x520
kern  :warn  : [   59.777324]  blk_done_softirq+0x95/0xc0
kern  :warn  : [   59.778098]  __do_softirq+0xe8/0x313
kern  :warn  : [   59.778887]  asm_call_on_stack+0x12/0x20
kern  :warn  : [   59.779662]  
kern  :warn  : [   59.780435]  do_softirq_own_stack+0x39/0x60
kern  :warn  : [   59.781217]  irq_exit_rcu+0xd2/0xe0
kern  :warn  : [   59.782020]  common_interrupt+0x74/0x140
kern  :warn  : [   59.782797]  ? asm_common_interrupt+0x8/0x40
kern  :warn  : [   59.783594]  asm_common_interrupt+0x1e/0x40
kern  :warn  : [   59.784359] RIP: 0033:0x5572c6b47f20
kern  :warn  : [   59.785119] Code: 10 00 00 49 01 c4 44 39 fd 0f 8c a2 00 00 00 ba 
00 10 00 00 4c 89 ee 44 89 f7 e8 ab f5 ff ff 85 c0 7e d7 89 c2 4c 89 eb eb 09 
<48> 83 c3 01 83 ea 01 74 c7 44 0f be 03 45 84 c0 74 ee 83 fa 03 7e
kern  :warn  : [   59.786952] RSP: 002b:7ffc3fc0fed0 EFLAGS: 0246
kern  :warn  : [   59.787836] RAX: 1000 RBX: 7ffc3fc11de1 RCX: 
7fb0403c950e
kern  :warn  : [   59.788750] RDX: 00bf RSI: 7ffc3fc10ea0 RDI: 
0007
kern  :warn  : [   59.789647] RBP: 001b5c00 R08:  R09: 
7ffc3fc0d6b7
kern  :warn  : [   59.790550] R10:  R11: 0246 R12: 
0003e000
kern  :warn  : [   59.791447] R13: 7ffc3fc10ea0 R14: 0007 R15: 
0003e000
kern  :warn  : [   59.792356] ---[ end trace 1c52c540ed6c08e4 ]---

...

[PATCH v2 2/2] extcon: ptn5150: Set the VBUS and POLARITY property state

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Set the VBUS and POLARITY property state.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
 drivers/extcon/extcon-ptn5150.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 8b930050a3f1..b5217a61615c 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -279,6 +279,12 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
return ret;
}
 
+   extcon_set_property_capability(info->edev, EXTCON_USB,
+  EXTCON_PROP_USB_VBUS);
+   extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+  EXTCON_PROP_USB_VBUS);
+   extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+  EXTCON_PROP_USB_TYPEC_POLARITY);
/* Initialize PTN5150 device and print vendor id and version id */
ret = ptn5150_init_dev_type(info);
if (ret)
-- 
2.11.0

[PATCH v2 0/2] extcon: ptn5150: Add usb-typec support for Intel LGM SoC

[Ramuthevar,Vadivel MuruganX]

Add usb-typec detection support for the Intel LGM SoC based boards.

Original driver is not supporting usb detection on Intel LGM SoC based boards
then we debugged and fixed the issue, but before sending our patches Mr.Krzyszto
has sent the same kind of patches, so I have rebased over his latest patches
which is present in maintainer tree.

Built and tested it's working fine, overthat created the new patch.

Thanks for Krzyszto and Chanwoo Choi
---
v2:
  - Krzyszto review comments update
  - squash my previous patches 1 to 5 as single patch
  - add extcon_set_property_capability for EXTCON_USB and 
EXTCON_PROP_USB_TYPEC_POLARITY 

Reference to mail discussion:
 https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2281723.html

Ramuthevar Vadivel Murugan (2):
  extcon: ptn5150: Switch to GENMASK() and BIT() macros
  extcon: ptn5150: Set the VBUS and POLARITY property state

 drivers/extcon/extcon-ptn5150.c | 49 ++---
 1 file changed, 17 insertions(+), 32 deletions(-)

-- 
2.11.0

[PATCH v2 1/2] extcon: ptn5150: Switch to GENMASK() and BIT() macros

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Switch to GENMASK() and BIT() macros.

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Krzysztof Kozlowski 
---
 drivers/extcon/extcon-ptn5150.c | 43 +++--
 1 file changed, 11 insertions(+), 32 deletions(-)

diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 8ba706fad887..8b930050a3f1 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -7,6 +7,7 @@
 // Author: Vijai Kumar K 
 // Copyright (c) 2020 Krzysztof Kozlowski 
 
+#include 
 #include 
 #include 
 #include 
@@ -35,29 +36,13 @@ enum ptn5150_reg {
 #define PTN5150_UFP_ATTACHED   0x2
 
 /* Define PTN5150 MASK/SHIFT constant */
-#define PTN5150_REG_DEVICE_ID_VENDOR_SHIFT 0
-#define PTN5150_REG_DEVICE_ID_VENDOR_MASK  \
-   (0x3 << PTN5150_REG_DEVICE_ID_VENDOR_SHIFT)
+#define PTN5150_REG_DEVICE_ID_VERSION  GENMASK(7, 3)
+#define PTN5150_REG_DEVICE_ID_VENDOR   GENMASK(2, 0)
 
-#define PTN5150_REG_DEVICE_ID_VERSION_SHIFT3
-#define PTN5150_REG_DEVICE_ID_VERSION_MASK \
-   (0x1f << PTN5150_REG_DEVICE_ID_VERSION_SHIFT)
-
-#define PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT   2
-#define PTN5150_REG_CC_PORT_ATTACHMENT_MASK\
-   (0x7 << PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT)
-
-#define PTN5150_REG_CC_VBUS_DETECTION_SHIFT7
-#define PTN5150_REG_CC_VBUS_DETECTION_MASK \
-   (0x1 << PTN5150_REG_CC_VBUS_DETECTION_SHIFT)
-
-#define PTN5150_REG_INT_CABLE_ATTACH_SHIFT 0
-#define PTN5150_REG_INT_CABLE_ATTACH_MASK  \
-   (0x1 << PTN5150_REG_INT_CABLE_ATTACH_SHIFT)
-
-#define PTN5150_REG_INT_CABLE_DETACH_SHIFT 1
-#define PTN5150_REG_INT_CABLE_DETACH_MASK  \
-   (0x1 << PTN5150_REG_CC_CABLE_DETACH_SHIFT)
+#define PTN5150_REG_CC_PORT_ATTACHMENT GENMASK(4, 2)
+#define PTN5150_REG_CC_VBUS_DETECTION  BIT(7)
+#define PTN5150_REG_INT_CABLE_ATTACH_MASK  BIT(0)
+#define PTN5150_REG_INT_CABLE_DETACH_MASK  BIT(1)
 
 struct ptn5150_info {
struct device *dev;
@@ -95,9 +80,7 @@ static void ptn5150_check_state(struct ptn5150_info *info)
return;
}
 
-   port_status = ((reg_data &
-   PTN5150_REG_CC_PORT_ATTACHMENT_MASK) >>
-   PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT);
+   port_status = FIELD_GET(PTN5150_REG_CC_PORT_ATTACHMENT, reg_data);
 
switch (port_status) {
case PTN5150_DFP_ATTACHED:
@@ -107,8 +90,7 @@ static void ptn5150_check_state(struct ptn5150_info *info)
break;
case PTN5150_UFP_ATTACHED:
extcon_set_state_sync(info->edev, EXTCON_USB, false);
-   vbus = ((reg_data & PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
-   PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
+   vbus = FIELD_GET(PTN5150_REG_CC_VBUS_DETECTION, reg_data);
if (vbus)
gpiod_set_value_cansleep(info->vbus_gpiod, 0);
else
@@ -191,11 +173,8 @@ static int ptn5150_init_dev_type(struct ptn5150_info *info)
return -EINVAL;
}
 
-   vendor_id = ((reg_data & PTN5150_REG_DEVICE_ID_VENDOR_MASK) >>
-   PTN5150_REG_DEVICE_ID_VENDOR_SHIFT);
-   version_id = ((reg_data & PTN5150_REG_DEVICE_ID_VERSION_MASK) >>
-   PTN5150_REG_DEVICE_ID_VERSION_SHIFT);
-
+   vendor_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VENDOR, reg_data);
+   version_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VERSION, reg_data);
dev_dbg(info->dev, "Device type: version: 0x%x, vendor: 0x%x\n",
version_id, vendor_id);
 
-- 
2.11.0

Re: [PATCH] libnvdimm/e820: Fix build error without MEMORY_HOTPLUG

[Yuehaibing]

Pls ignore this

It has be fixed in commit dbb8733abb1c 
("mm-memory_hotplug-introduce-default-phys_to_target_node-implementation-fix")

On 2020/8/26 20:18, YueHaibing wrote:
> If MEMORY_HOTPLUG is n, build fails:
> 
> drivers/nvdimm/e820.c: In function ‘e820_register_one’:
> drivers/nvdimm/e820.c:24:12: error: implicit declaration of function 
> ‘phys_to_target_node’; did you mean ‘set_page_node’? 
> [-Werror=implicit-function-declaration]
>   int nid = phys_to_target_node(res->start);
> ^~~
> set_page_node
> 
> Fixes: 7b27a8622f80 ("libnvdimm/e820: Retrieve and populate correct 
> 'target_node' info")
> Signed-off-by: YueHaibing 
> ---
>  drivers/nvdimm/e820.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/nvdimm/e820.c b/drivers/nvdimm/e820.c
> index 4cd18be9d0e9..c741f029f215 100644
> --- a/drivers/nvdimm/e820.c
> +++ b/drivers/nvdimm/e820.c
> @@ -17,6 +17,13 @@ static int e820_pmem_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> +#ifndef CONFIG_MEMORY_HOTPLUG
> +static inline int phys_to_target_node(u64 start)
> +{
> + return 0;
> +}
> +#endif
> +
>  static int e820_register_one(struct resource *res, void *data)
>  {
>   struct nd_region_desc ndr_desc;
> 

[PATCH v6 0/7] Fix timeout clock used by hardware data timeout

[Sowjanya Komatineni]

Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.

Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra sdmmc driver.

This series includes patches to fix this for Tegra210/Tegra186/Tegra194.

These patches need to be manually backported for 4.9, 4.14 and 4.19.

Will send patches to backport separately once these patches are ack'd.

Delta between patch versions:
[v6]:   v5 is sent out mistakenly with incorrect patches.
v6 includes proper patches addressing v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
  based on no. of clocks in sdhci device node as old device trees
  do not use sdhci clock name and this allows proper clock retrival
  irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
  timeout clock to be more clear.

[v5]:   Include below changes based on v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
  based on no. of clocks in sdhci device node as old device trees
  do not use sdhci clock name and this allows proper clock retrival
  irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
  timeout clock to be more clear.

[v4]:   Include additional dt-binding patch

[v3]:   Same as v2 with fixes tag

[v2]:   Includes minor fix
- Patch-0006: parentheses around operand of '!'

Sowjanya Komatineni (7):
  sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
  sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
  dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later
  arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
  arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
  arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
  sdhci: tegra: Add missing TMCLK for data timeout

 .../bindings/mmc/nvidia,tegra20-sdhci.txt  | 32 +++-
 arch/arm64/boot/dts/nvidia/tegra186.dtsi   | 20 +++--
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 15 ++--
 arch/arm64/boot/dts/nvidia/tegra210.dtsi   | 20 +++--
 drivers/mmc/host/sdhci-tegra.c | 92 +++---
 5 files changed, 144 insertions(+), 35 deletions(-)

-- 
2.7.4

[PATCH v6 1/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210

[Sowjanya Komatineni]

commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")

SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.

Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.

So, this patch remove this quirk for Tegra210.

Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 0a3f9d0..2be3511 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1418,7 +1418,6 @@ static const struct sdhci_ops tegra210_sdhci_ops = {
 
 static const struct sdhci_pltfm_data sdhci_tegra210_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
  SDHCI_QUIRK_SINGLE_POWER_WRITE |
  SDHCI_QUIRK_NO_HISPD_BIT |
  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
-- 
2.7.4

[PATCH v6 5/7] arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes

[Sowjanya Komatineni]

commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")

Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by default.

So, this clock should be kept enabled by the SDMMC driver.

Fixes: 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 34d249d..8eb61dd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -337,8 +337,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0340 0x0 0x1>;
interrupts = ;
-   clocks = < TEGRA186_CLK_SDMMC1>;
-   clock-names = "sdhci";
+   clocks = < TEGRA186_CLK_SDMMC1>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC1>;
reset-names = "sdhci";
interconnects = < TEGRA186_MEMORY_CLIENT_SDMMCRA >,
@@ -366,8 +367,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0342 0x0 0x1>;
interrupts = ;
-   clocks = < TEGRA186_CLK_SDMMC2>;
-   clock-names = "sdhci";
+   clocks = < TEGRA186_CLK_SDMMC2>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC2>;
reset-names = "sdhci";
interconnects = < TEGRA186_MEMORY_CLIENT_SDMMCRAA >,
@@ -390,8 +392,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0344 0x0 0x1>;
interrupts = ;
-   clocks = < TEGRA186_CLK_SDMMC3>;
-   clock-names = "sdhci";
+   clocks = < TEGRA186_CLK_SDMMC3>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC3>;
reset-names = "sdhci";
interconnects = < TEGRA186_MEMORY_CLIENT_SDMMCR >,
@@ -416,8 +419,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0346 0x0 0x1>;
interrupts = ;
-   clocks = < TEGRA186_CLK_SDMMC4>;
-   clock-names = "sdhci";
+   clocks = < TEGRA186_CLK_SDMMC4>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
assigned-clocks = < TEGRA186_CLK_SDMMC4>,
  < TEGRA186_CLK_PLLC4_VCO>;
assigned-clock-parents = < TEGRA186_CLK_PLLC4_VCO>;
-- 
2.7.4

[PATCH v6 7/7] sdhci: tegra: Add missing TMCLK for data timeout

[Sowjanya Komatineni]

commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")

Tegra210 and later has a separate sdmmc_legacy_tm (TMCLK) used by Tegra
SDMMC hawdware for data timeout to achive better timeout than using
SDCLK and using TMCLK is recommended.

USE_TMCLK_FOR_DATA_TIMEOUT bit in Tegra SDMMC register
SDHCI_TEGRA_VENDOR_SYS_SW_CTRL can be used to choose either TMCLK or
SDCLK for data timeout.

Default USE_TMCLK_FOR_DATA_TIMEOUT bit is set to 1 and TMCLK is used
for data timeout by Tegra SDMMC hardware and having TMCLK not enabled
is not recommended.

So, this patch adds quirk NVQUIRK_HAS_TMCLK for SoC having separate
timeout clock and keeps TMCLK enabled all the time.

Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 90 ++
 1 file changed, 82 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 31ed321..f69ca8d 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -110,6 +111,12 @@
 #define NVQUIRK_DIS_CARD_CLK_CONFIG_TAPBIT(8)
 #define NVQUIRK_CQHCI_DCMD_R1B_CMD_TIMING  BIT(9)
 
+/*
+ * NVQUIRK_HAS_TMCLK is for SoC's having separate timeout clock for Tegra
+ * SDMMC hardware data timeout.
+ */
+#define NVQUIRK_HAS_TMCLK  BIT(10)
+
 /* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
 #define SDHCI_TEGRA_CQE_BASE_ADDR  0xF000
 
@@ -140,6 +147,7 @@ struct sdhci_tegra_autocal_offsets {
 struct sdhci_tegra {
const struct sdhci_tegra_soc_data *soc_data;
struct gpio_desc *power_gpio;
+   struct clk *tmclk;
bool ddr_signaling;
bool pad_calib_required;
bool pad_control_available;
@@ -1433,7 +1441,8 @@ static const struct sdhci_tegra_soc_data 
soc_data_tegra210 = {
NVQUIRK_HAS_PADCALIB |
NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
NVQUIRK_ENABLE_SDR50 |
-   NVQUIRK_ENABLE_SDR104,
+   NVQUIRK_ENABLE_SDR104 |
+   NVQUIRK_HAS_TMCLK,
.min_tap_delay = 106,
.max_tap_delay = 185,
 };
@@ -1471,6 +1480,7 @@ static const struct sdhci_tegra_soc_data 
soc_data_tegra186 = {
NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
NVQUIRK_ENABLE_SDR50 |
NVQUIRK_ENABLE_SDR104 |
+   NVQUIRK_HAS_TMCLK |
NVQUIRK_CQHCI_DCMD_R1B_CMD_TIMING,
.min_tap_delay = 84,
.max_tap_delay = 136,
@@ -1483,7 +1493,8 @@ static const struct sdhci_tegra_soc_data 
soc_data_tegra194 = {
NVQUIRK_HAS_PADCALIB |
NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
NVQUIRK_ENABLE_SDR50 |
-   NVQUIRK_ENABLE_SDR104,
+   NVQUIRK_ENABLE_SDR104 |
+   NVQUIRK_HAS_TMCLK,
.min_tap_delay = 96,
.max_tap_delay = 139,
 };
@@ -1611,15 +1622,76 @@ static int sdhci_tegra_probe(struct platform_device 
*pdev)
goto err_power_req;
}
 
-   clk = devm_clk_get(mmc_dev(host->mmc), NULL);
-   if (IS_ERR(clk)) {
-   rc = PTR_ERR(clk);
+   /*
+* Tegra210 and later has separate SDMMC_LEGACY_TM clock used for
+* hardware data timeout clock and SW can choose TMCLK or SDCLK for
+* hardware data timeout through the bit USE_TMCLK_FOR_DATA_TIMEOUT
+* of the register SDHCI_TEGRA_VENDOR_SYS_SW_CTRL.
+*
+* USE_TMCLK_FOR_DATA_TIMEOUT bit default is set to 1 and SDMMC uses
+* 12Mhz TMCLK which is advertised in host capability register.
+* With TMCLK of 12Mhz provides maximum data timeout period that can
+* be achieved is 11s better than using SDCLK for data timeout.
+*
+* So, TMCLK is set to 12Mhz and kept enabled all the time on SoC's
+* supporting separate TMCLK.
+*
+* Old device tree has single sdhci clock. So with addition of TMCLK,
+* retrieving sdhci clock by "sdhci" clock name based on number of
+* clocks in sdhci device node.
+*/
+
+   if (of_clk_get_parent_count(pdev->dev.of_node) == 1) {
+   if (soc_data->nvquirks & NVQUIRK_HAS_TMCLK)
+   dev_warn(>dev,
+"missing tmclk in the device tree\n");
+
+   clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(clk)) {
+   rc = PTR_ERR(clk);
 
-   if (rc != -EPROBE_DEFER)
-   dev_err(>dev, "failed to get clock: %d\n", rc);
+   if (rc != -EPROBE_DEFER)
+   

[PATCH v6 2/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186

[Sowjanya Komatineni]

commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support")

SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the
beginning of its support in driver.

Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead
of SDCLK and this quirk should not be set.

So, this patch remove this quirk for Tegra186.

Fixes: 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 2be3511..31ed321 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1455,7 +1455,6 @@ static const struct sdhci_ops tegra186_sdhci_ops = {
 
 static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
  SDHCI_QUIRK_SINGLE_POWER_WRITE |
  SDHCI_QUIRK_NO_HISPD_BIT |
  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
-- 
2.7.4

[PATCH v6 3/7] dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later

[Sowjanya Komatineni]

Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data
timeout.

So, this patch adds "tmclk" to Tegra sdhci clock property in the
device tree binding.

Signed-off-by: Sowjanya Komatineni 
---
 .../bindings/mmc/nvidia,tegra20-sdhci.txt  | 32 --
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt 
b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
index 2cf3aff..96c0b14 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
@@ -15,8 +15,15 @@ Required properties:
   - "nvidia,tegra210-sdhci": for Tegra210
   - "nvidia,tegra186-sdhci": for Tegra186
   - "nvidia,tegra194-sdhci": for Tegra194
-- clocks : Must contain one entry, for the module clock.
-  See ../clocks/clock-bindings.txt for details.
+- clocks: For Tegra210, Tegra186 and Tegra194 must contain two entries.
+ One for the module clock and one for the timeout clock.
+ For all other Tegra devices, must contain a single entry for
+ the module clock. See ../clocks/clock-bindings.txt for details.
+- clock-names: For Tegra210, Tegra186 and Tegra194 must contain the
+  strings 'sdhci' and 'tmclk' to represent the module and
+  the timeout clocks, respectively.
+  For all other Tegra devices must contain the string 'sdhci'
+  to represent the module clock.
 - resets : Must contain an entry for each entry in reset-names.
   See ../reset/reset.txt for details.
 - reset-names : Must include the following entries:
@@ -99,7 +106,7 @@ Optional properties for Tegra210, Tegra186 and Tegra194:
 
 Example:
 sdhci@700b {
-   compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci";
+   compatible = "nvidia,tegra124-sdhci";
reg = <0x0 0x700b 0x0 0x200>;
interrupts = ;
clocks = <_car TEGRA210_CLK_SDMMC1>;
@@ -115,3 +122,22 @@ sdhci@700b {
nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>;
status = "disabled";
 };
+
+sdhci@700b {
+   compatible = "nvidia,tegra210-sdhci";
+   reg = <0x0 0x700b 0x0 0x200>;
+   interrupts = ;
+   clocks = <_car TEGRA210_CLK_SDMMC1>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
+   resets = <_car 14>;
+   reset-names = "sdhci";
+   pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
+   pinctrl-0 = <_3v3>;
+   pinctrl-1 = <_1v8>;
+   nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>;
+   nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>;
+   nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>;
+   nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>;
+   status = "disabled";
+};
-- 
2.7.4

[PATCH v6 4/7] arm64: tegra: Add missing timeout clock to Tegra210 SDMMC

[Sowjanya Komatineni]

commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")

Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 829f786..8cca216 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -1194,8 +1194,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b 0x0 0x200>;
interrupts = ;
-   clocks = <_car TEGRA210_CLK_SDMMC1>;
-   clock-names = "sdhci";
+   clocks = <_car TEGRA210_CLK_SDMMC1>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <_car 14>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8",
@@ -1222,8 +1223,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0200 0x0 0x200>;
interrupts = ;
-   clocks = <_car TEGRA210_CLK_SDMMC2>;
-   clock-names = "sdhci";
+   clocks = <_car TEGRA210_CLK_SDMMC2>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <_car 9>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-1v8-drv";
@@ -1239,8 +1241,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0400 0x0 0x200>;
interrupts = ;
-   clocks = <_car TEGRA210_CLK_SDMMC3>;
-   clock-names = "sdhci";
+   clocks = <_car TEGRA210_CLK_SDMMC3>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <_car 69>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8",
@@ -1262,8 +1265,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0600 0x0 0x200>;
interrupts = ;
-   clocks = <_car TEGRA210_CLK_SDMMC4>;
-   clock-names = "sdhci";
+   clocks = <_car TEGRA210_CLK_SDMMC4>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <_car 15>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3-drv", "sdmmc-1v8-drv";
-- 
2.7.4

[PATCH v6 6/7] arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes

[Sowjanya Komatineni]

commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")

Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 48160f4..ca5cb6a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -460,8 +460,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0340 0x1>;
interrupts = ;
-   clocks = < TEGRA194_CLK_SDMMC1>;
-   clock-names = "sdhci";
+   clocks = < TEGRA194_CLK_SDMMC1>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = < TEGRA194_RESET_SDMMC1>;
reset-names = "sdhci";
interconnects = < TEGRA194_MEMORY_CLIENT_SDMMCRA 
>,
@@ -485,8 +486,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0344 0x1>;
interrupts = ;
-   clocks = < TEGRA194_CLK_SDMMC3>;
-   clock-names = "sdhci";
+   clocks = < TEGRA194_CLK_SDMMC3>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = < TEGRA194_RESET_SDMMC3>;
reset-names = "sdhci";
interconnects = < TEGRA194_MEMORY_CLIENT_SDMMCR 
>,
@@ -511,8 +513,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0346 0x1>;
interrupts = ;
-   clocks = < TEGRA194_CLK_SDMMC4>;
-   clock-names = "sdhci";
+   clocks = < TEGRA194_CLK_SDMMC4>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
assigned-clocks = < TEGRA194_CLK_SDMMC4>,
  < TEGRA194_CLK_PLLC4>;
assigned-clock-parents =
-- 
2.7.4

Re: [kthread] 2e7d8748eb: last_state.is_incomplete_run

[qianli zhao]

I did not see any exceptions related to my changes,the corresponding
macro CONFIG_DEBUG_OBJECTS_KTHREAD is not enabled,so i think the issue
has nothing to do with my changes

Thanks

On Thu, 20 Aug 2020 at 14:26, kernel test robot  wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 2e7d8748eba7e32150cbd4f57129ea77d1255892 ("[RFC V2] kthread: add 
> object debug support")
> url: 
> https://github.com/0day-ci/linux/commits/Qianli-Zhao/kthread-add-object-debug-support/20200812-131719
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git 
> fb893de323e2d39f7a1f6df425703a2edbdf56ea
>
> in testcase: boot
>
> on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz with 16G 
> memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
>
>
>
> kernel boot failed by kexec:
>
> user  :notice:  [32m[  +0.371313]  [0m [33mLKP [0m: kexec loading...
> user  :notice:  [32m[  +0.007118]  [0mkexec --noefi -l 
> /opt/rootfs/tmp/pkg/linux/x86_64-rhel-8.3/gcc-9/2e7d8748eba7e32150cbd4f57129ea77d1255892/vmlinuz-5.8.0-12610-g2e7d8748eba7e
>  --initrd=/opt/rootfs/tmp/initrd-concatenated
>
>
>
>
> Thanks,
> Rong Chen
>

Re: [PATCH v2 3/3] usb typec: mt6360: Prevent the race condition during module remove

[Guenter Roeck]

On 8/26/20 8:25 PM, cy_huang wrote:
> From: ChiYuan Huang 
> 
> Prevent the race condition from interrupt and tcpci port unregister
> during module remove.
> 
> Signed-off-by: ChiYuan Huang 

Please squash with the first patch of the series.

Thanks,
Guenter

> ---
>  drivers/usb/typec/tcpm/tcpci_mt6360.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
> b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> index 6a28193..a381b5d 100644
> --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> @@ -164,6 +164,7 @@ static int mt6360_tcpc_remove(struct platform_device 
> *pdev)
>  {
>   struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
>  
> + disable_irq(mti->irq);
>   tcpci_unregister_port(mti->tcpci);
>   return 0;
>  }
> 

Re: [PATCH] deprecated.rst: Remove now removed uninitialized_var

[Nick Desaulniers]

On Wed, Aug 26, 2020 at 8:12 PM Joe Perches  wrote:
>
> It's now gone from the kernel so remove it from the deprecated API text.
>
> Signed-off-by: Joe Perches 

Thanks Joe.
Reviewed-by: Nick Desaulniers 

> ---
>  Documentation/process/deprecated.rst | 18 --
>  1 file changed, 18 deletions(-)
>
> diff --git a/Documentation/process/deprecated.rst 
> b/Documentation/process/deprecated.rst
> index 918e32d76fc4..70720f00b9aa 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -51,24 +51,6 @@ to make sure their systems do not continue running in the 
> face of
>  "unreachable" conditions. (For example, see commits like `this one
>  `_.)
>
> -uninitialized_var()
> 
> -For any compiler warnings about uninitialized variables, just add
> -an initializer. Using the uninitialized_var() macro (or similar
> -warning-silencing tricks) is dangerous as it papers over `real bugs
> -`_
> -(or can in the future), and suppresses unrelated compiler warnings
> -(e.g. "unused variable"). If the compiler thinks it is uninitialized,
> -either simply initialize the variable or make compiler changes. Keep in
> -mind that in most cases, if an initialization is obviously redundant,
> -the compiler's dead-store elimination pass will make sure there are no
> -needless variable writes.
> -
> -As Linus has said, this macro
> -`must 
> `_
> -`be 
> `_
> -`removed 
> `_.
> -
>  open-coded arithmetic in allocator arguments
>  
>  Dynamic size calculations (especially multiplication) should not be
>
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH v2] extcon: ptn5150: Deduplicate parts of dev_err_probe()

[Chanwoo Choi]

Hi Andy,

On 8/27/20 12:23 AM, Andy Shevchenko wrote:
> dev_err_probe() is designed to be used like
> 
>   return dev_err_probe(dev, ret, "Error message\n");
> 
> Hence no need to have a separate return statement. Besides that
> dev_err_probe() prints already returned error code, no need to repeat
> that either.
> 
> Cc: Vijai Kumar K 
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Krzysztof Kozlowski 
> ---
> v2: dropped Fixed tag (Krzysztof)
>  drivers/extcon/extcon-ptn5150.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index 8ba706fad887..051bf374b43f 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -242,8 +242,7 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>   dev_info(dev, "No VBUS GPIO, ignoring VBUS control\n");
>   info->vbus_gpiod = NULL;
>   } else {
> - dev_err_probe(dev, ret, "failed to get VBUS GPIO\n");
> - return ret;
> + return dev_err_probe(dev, ret, "failed to get VBUS 
> GPIO\n");
>   }
>   }
>  
> @@ -253,10 +252,8 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>  
>   info->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
>   if (IS_ERR(info->regmap)) {
> - ret = PTR_ERR(info->regmap);
> - dev_err_probe(info->dev, ret, "failed to allocate register map: 
> %d\n",
> -   ret);
> - return ret;
> + return dev_err_probe(info->dev, PTR_ERR(info->regmap),
> +  "failed to allocate register map\n");
>   }
>  
>   if (i2c->irq > 0) {
> @@ -264,9 +261,8 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>   } else {
>   info->int_gpiod = devm_gpiod_get(>dev, "int", GPIOD_IN);
>   if (IS_ERR(info->int_gpiod)) {
> - ret = PTR_ERR(info->int_gpiod);
> - dev_err_probe(dev, ret, "failed to get INT GPIO\n");
> - return ret;
> + return dev_err_probe(dev, PTR_ERR(info->int_gpiod),
> +  "failed to get INT GPIO\n");
>   }
>  
>   info->irq = gpiod_to_irq(info->int_gpiod);
> 

Applied it. Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH v2 3/3] usb typec: mt6360: Prevent the race condition during module remove

[cy_huang]

From: ChiYuan Huang 

Prevent the race condition from interrupt and tcpci port unregister
during module remove.

Signed-off-by: ChiYuan Huang 
---
 drivers/usb/typec/tcpm/tcpci_mt6360.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
b/drivers/usb/typec/tcpm/tcpci_mt6360.c
index 6a28193..a381b5d 100644
--- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
+++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
@@ -164,6 +164,7 @@ static int mt6360_tcpc_remove(struct platform_device *pdev)
 {
struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
 
+   disable_irq(mti->irq);
tcpci_unregister_port(mti->tcpci);
return 0;
 }
-- 
2.7.4

[PATCH v2 1/3] usb typec: mt6360: Add support for mt6360 Type-C driver

[cy_huang]

From: ChiYuan Huang 

Mediatek MT6360 is a multi-functional IC that includes USB Type-C.
It works with Type-C Port Controller Manager to provide USB PD
and USB Type-C functionalities.

Signed-off-by: ChiYuan Huang 
---
 drivers/usb/typec/tcpm/Kconfig|   8 ++
 drivers/usb/typec/tcpm/Makefile   |   1 +
 drivers/usb/typec/tcpm/tcpci_mt6360.c | 212 ++
 3 files changed, 221 insertions(+)
 create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6360.c

diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index fa3f393..58a64e1 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -27,6 +27,14 @@ config TYPEC_RT1711H
  Type-C Port Controller Manager to provide USB PD and USB
  Type-C functionalities.
 
+config TYPEC_MT6360
+   tristate "Mediatek MT6360 Type-C driver"
+   depends on MFD_MT6360
+   help
+ Mediatek MT6360 is a multi-functional IC that includes
+ USB Type-C. It works with Type-C Port Controller Manager
+ to provide USB PD and USB Type-C functionalities.
+
 endif # TYPEC_TCPCI
 
 config TYPEC_FUSB302
diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
index a5ff6c8..7592ccb 100644
--- a/drivers/usb/typec/tcpm/Makefile
+++ b/drivers/usb/typec/tcpm/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_TYPEC_WCOVE)   += typec_wcove.o
 typec_wcove-y  := wcove.o
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
 obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
+obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
b/drivers/usb/typec/tcpm/tcpci_mt6360.c
new file mode 100644
index ..6a28193
--- /dev/null
+++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright (C) 2020 MediaTek Inc.
+//
+// Author: ChiYuan Huang 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tcpci.h"
+
+#define MT6360_REG_VCONNCTRL1  0x8C
+#define MT6360_REG_MODECTRL2   0x8F
+#define MT6360_REG_SWRESET 0xA0
+#define MT6360_REG_DEBCTRL10xA1
+#define MT6360_REG_DRPCTRL10xA2
+#define MT6360_REG_DRPCTRL20xA3
+#define MT6360_REG_I2CTORST0xBF
+#define MT6360_REG_RXCTRL2 0xCF
+#define MT6360_REG_CTDCTRL20xEC
+
+/* MT6360_REG_VCONNCTRL1 */
+#define MT6360_VCONNCL_ENABLE  BIT(0)
+/* MT6360_REG_RXCTRL2 */
+#define MT6360_OPEN40M_ENABLE  BIT(7)
+/* MT6360_REG_CTDCTRL2 */
+#define MT6360_RPONESHOT_ENABLEBIT(6)
+
+struct mt6360_tcpc_info {
+   struct tcpci_data tdata;
+   struct tcpci *tcpci;
+   struct device *dev;
+   int irq;
+};
+
+static inline int mt6360_tcpc_read16(struct regmap *regmap,
+unsigned int reg, u16 *val)
+{
+   return regmap_raw_read(regmap, reg, val, sizeof(u16));
+}
+
+static inline int mt6360_tcpc_write16(struct regmap *regmap,
+ unsigned int reg, u16 val)
+{
+   return regmap_raw_write(regmap, reg, , sizeof(u16));
+}
+
+static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
+{
+   struct regmap *regmap = tdata->regmap;
+   int ret;
+
+   ret = regmap_write(regmap, MT6360_REG_SWRESET, 0x01);
+   if (ret)
+   return ret;
+
+   /* after reset command, wait 1~2ms to wait IC action */
+   usleep_range(1000, 2000);
+
+   /* write all alert to masked */
+   ret = mt6360_tcpc_write16(regmap, TCPC_ALERT_MASK, 0);
+   if (ret)
+   return ret;
+
+   /* config I2C timeout reset enable , and timeout to 200ms */
+   ret = regmap_write(regmap, MT6360_REG_I2CTORST, 0x8F);
+   if (ret)
+   return ret;
+
+   /* config CC Detect Debounce : 26.7*val us */
+   ret = regmap_write(regmap, MT6360_REG_DEBCTRL1, 0x10);
+   if (ret)
+   return ret;
+
+   /* DRP Toggle Cycle : 51.2 + 6.4*val ms */
+   ret = regmap_write(regmap, MT6360_REG_DRPCTRL1, 4);
+   if (ret)
+   return ret;
+
+   /* DRP Duyt Ctrl : dcSRC: /1024 */
+   ret = mt6360_tcpc_write16(regmap, MT6360_REG_DRPCTRL2, 330);
+   if (ret)
+   return ret;
+
+   /* Enable VCONN Current Limit function */
+   ret = regmap_update_bits(regmap, MT6360_REG_VCONNCTRL1, 
MT6360_VCONNCL_ENABLE,
+MT6360_VCONNCL_ENABLE);
+   if (ret)
+   return ret;
+
+   /* Enable cc open 40ms when pmic send vsysuv signal */
+   ret = regmap_update_bits(regmap, MT6360_REG_RXCTRL2, 
MT6360_OPEN40M_ENABLE,
+MT6360_OPEN40M_ENABLE);
+   if (ret)
+   return ret;
+
+   /* Enable Rpdet oneshot detection */
+   ret = regmap_update_bits(regmap, MT6360_REG_CTDCTRL2, 
MT6360_RPONESHOT_ENABLE,
+MT6360_RPONESHOT_ENABLE);
+   if (ret)
+   return 

[PATCH v2 2/3] usb typec: mt6360: Add MT6360 Type-C DT binding documentation

[cy_huang]

From: ChiYuan Huang 

Add a devicetree binding documentation for the MT6360 Type-C driver.

Signed-off-by: ChiYuan Huang 
---
 .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml 
b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
new file mode 100644
index ..9e8ab0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT 
bindings
+
+maintainers:
+  - ChiYuan Huang 
+
+description: |
+  Mediatek MT6360 is a multi-functional device. It integrates charger, ADC, 
flash, RGB indicators,
+  regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery 
controller.
+  This document only describes MT6360 Type-C Port Switch and Power Delivery 
controller.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt6360-tcpc
+
+  interrupts-extended:
+maxItems: 1
+
+  interrupt-names:
+items:
+  - const: PD_IRQB
+
+patternProperties:
+  "connector":
+type: object
+$ref: ../connector/usb-connector.yaml#
+description:
+  Properties for usb c connector.
+
+additionalProperties: false
+
+required:
+  - compatible
+  - interrupts-extended
+  - interrupt-names
+
+examples:
+  - |
+#include 
+#include 
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mt6360@34 {
+compatible = "mediatek,mt6360";
+reg = <0x34>;
+
+tcpc {
+compatible = "mediatek,mt6360-tcpc";
+interrupts-extended = < 3 IRQ_TYPE_LEVEL_LOW>;
+interrupt-names = "PD_IRQB";
+
+connector {
+compatible = "usb-c-connector";
+label = "USB-C";
+data-role = "dual";
+power-role = "dual";
+try-power-role = "sink";
+source-pdos = ;
+sink-pdos = ;
+op-sink-microwatt = <1000>;
+};
+};
+};
+};
+...
-- 
2.7.4

RE: [PATCH v4 1/5] exfat: integrates dir-entry getting and validation

[Namjae Jeon]

> + i = ES_INDEX_NAME;
> + while ((ep = exfat_get_validated_dentry(es, i++, TYPE_NAME))) {
Please find the way to access name entries like ep_file, ep_stream
without calling exfat_get_validated_dentry().
>   exfat_extract_uni_name(ep, uniname);
>   uniname += EXFAT_FILE_NAME_LEN;
>   }
> @@ -372,7 +369,7 @@ unsigned int exfat_get_entry_type(struct exfat_dentry *ep)
>   if (ep->type == EXFAT_STREAM)
>   return TYPE_STREAM;
>   if (ep->type == EXFAT_NAME)
> - return TYPE_EXTEND;
> + return TYPE_NAME;
>   if (ep->type == EXFAT_ACL)
>   return TYPE_ACL;
>   return TYPE_CRITICAL_SEC;
> @@ -388,7 +385,7 @@ static void exfat_set_entry_type(struct exfat_dentry *ep, 
> unsigned int type)
>   ep->type &= EXFAT_DELETE;
>   } else if (type == TYPE_STREAM) {
>   ep->type = EXFAT_STREAM;
> - } else if (type == TYPE_EXTEND) {
> + } else if (type == TYPE_NAME) {
>   ep->type = EXFAT_NAME;
>   } else if (type == TYPE_BITMAP) {
>   ep->type = EXFAT_BITMAP;
> @@ -421,7 +418,7 @@ static void exfat_init_name_entry(struct exfat_dentry 
> *ep,  {
>   int i;
> 
> - exfat_set_entry_type(ep, TYPE_EXTEND);
> + exfat_set_entry_type(ep, TYPE_NAME);
>   ep->dentry.name.flags = 0x0;
> 
>   for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { @@ -550,7 +547,7 @@ int 
> exfat_init_ext_entry(struct
> inode *inode, struct exfat_chain *p_dir,
>   exfat_update_bh(bh, sync);
>   brelse(bh);
> 
> - for (i = EXFAT_FIRST_CLUSTER; i < num_entries; i++) {
> + for (i = ES_INDEX_NAME; i < num_entries; i++) {
>   ep = exfat_get_dentry(sb, p_dir, entry + i, , );
>   if (!ep)
>   return -EIO;
> @@ -590,17 +587,16 @@ int exfat_remove_entries(struct inode *inode, struct 
> exfat_chain *p_dir,  void
> exfat_update_dir_chksum_with_entry_set(struct exfat_entry_set_cache *es)  {
>   int chksum_type = CS_DIR_ENTRY, i;
> - unsigned short chksum = 0;
> + u16 chksum = 0;
>   struct exfat_dentry *ep;
> 
>   for (i = 0; i < es->num_entries; i++) {
> - ep = exfat_get_dentry_cached(es, i);
> + ep = exfat_get_validated_dentry(es, i, TYPE_ALL);
Ditto, You do not need to repeatedly call exfat_get_validated_dentry() for the 
entries
which got from exfat_get_dentry_set().
>   chksum = exfat_calc_chksum16(ep, DENTRY_SIZE, chksum,
>chksum_type);
>   chksum_type = CS_DEFAULT;
>   }
> - ep = exfat_get_dentry_cached(es, 0);
> - ep->dentry.file.checksum = cpu_to_le16(chksum);
> + ES_FILE(es).checksum = cpu_to_le16(chksum);
>   es->modified = true;
>  }
> 
>  struct exfat_entry_set_cache *exfat_get_dentry_set(struct super_block *sb,
> - struct exfat_chain *p_dir, int entry, unsigned int type)
> + struct exfat_chain *p_dir, int entry, int max_entries)
>  {
>   int ret, i, num_bh;
> - unsigned int off, byte_offset, clu = 0;
> + unsigned int byte_offset, clu = 0;
>   sector_t sec;
>   struct exfat_sb_info *sbi = EXFAT_SB(sb);
>   struct exfat_entry_set_cache *es;
> - struct exfat_dentry *ep;
> - int num_entries;
> - enum exfat_validate_dentry_mode mode = ES_MODE_STARTED;
>   struct buffer_head *bh;
> 
>   if (p_dir->dir == DIR_DELETED) {
> @@ -844,13 +811,13 @@ struct exfat_entry_set_cache 
> *exfat_get_dentry_set(struct super_block *sb,
>   return NULL;
>   es->sb = sb;
>   es->modified = false;
> + es->num_entries = 1;
> 
>   /* byte offset in cluster */
>   byte_offset = EXFAT_CLU_OFFSET(byte_offset, sbi);
> 
>   /* byte offset in sector */
> - off = EXFAT_BLK_OFFSET(byte_offset, sb);
> - es->start_off = off;
> + es->start_off = EXFAT_BLK_OFFSET(byte_offset, sb);
> 
>   /* sector offset in cluster */
>   sec = EXFAT_B_TO_BLK(byte_offset, sb); @@ -861,15 +828,12 @@ struct 
> exfat_entry_set_cache
> *exfat_get_dentry_set(struct super_block *sb,
>   goto free_es;
>   es->bh[es->num_bh++] = bh;
> 
> - ep = exfat_get_dentry_cached(es, 0);
> - if (!exfat_validate_entry(exfat_get_entry_type(ep), ))
> + es->ep_file = exfat_get_validated_dentry(es, ES_INDEX_FILE, TYPE_FILE);
> + if (!es->ep_file)
>   goto free_es;
> + es->num_entries = min(ES_FILE(es).num_ext + 1, max_entries);
> 
> - num_entries = type == ES_ALL_ENTRIES ?
> - ep->dentry.file.num_ext + 1 : type;
> - es->num_entries = num_entries;
> -
> - num_bh = EXFAT_B_TO_BLK_ROUND_UP(off + num_entries * DENTRY_SIZE, sb);
> + num_bh = EXFAT_B_TO_BLK_ROUND_UP(es->start_off  + es->num_entries *
> +DENTRY_SIZE, sb);
>   for (i = 1; i < num_bh; i++) {
>   /* get the next sector */
>   if 

RE: [PATCH] exfat: fix pointer error checking

[Namjae Jeon]

> Fix missing result check of exfat_build_inode().
> And use PTR_ERR_OR_ZERO instead of PTR_ERR.
> 
> Signed-off-by: Tetsuhiro Kohada 
Pushed it to exfat #dev.
Thanks for your patch!

Re: [PATCH] MIPS: Loongson: Fix complie errors without CONFIG_SMP

[Matthew Wilcox]

On Thu, Aug 27, 2020 at 10:31:33AM +0800, hejinyang wrote:
> 
> 
> On 08/26/2020 09:01 PM, Matthew Wilcox wrote:
> > On Wed, Aug 26, 2020 at 08:53:27PM +0800, Jinyang He wrote:
> > > +++ b/arch/mips/include/asm/mach-loongson64/topology.h
> > > @@ -4,7 +4,11 @@
> > >   #ifdef CONFIG_NUMA
> > > +#ifdef CONFIG_SMP
> > >   #define cpu_to_node(cpu)(cpu_logical_map(cpu) >> 2)
> > > +#else
> > > +#define cpu_to_node(cpu) 0
> > > +#endif
> > Are you saying you've enabled NUMA without enabling SMP?  Does that make
> > sense?
> 
> NUMA option normally work with more than two nodes, though Loongson64 use it
> default after patch 6fbde6b492dfc761ad60a68fb2cb32b1eb05b786. Loongson64(3A)'s
> each node consists of 4 cpus while it only has 4 cpus. In other words, it has
> only one node while open NUMA. I'm confused it if NUMA deponds on SMP.
> 
> I'll try fix it with unabling NUMA and SMP later.

mips:
config NUMA
bool "NUMA Support"
depends on SYS_SUPPORTS_NUMA

x86:
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
depends on SMP

If you had a good reason for enabling NUMA without enabling SMP (CPU-less
memory nodes?), that'd be an interesting discussion to have.  Since your
hardware seems to have SMP by default, I'd suggest just adding the missing
'depends'.

[PATCH] deprecated.rst: Remove now removed uninitialized_var

[Joe Perches]

It's now gone from the kernel so remove it from the deprecated API text.

Signed-off-by: Joe Perches 
---
 Documentation/process/deprecated.rst | 18 --
 1 file changed, 18 deletions(-)

diff --git a/Documentation/process/deprecated.rst 
b/Documentation/process/deprecated.rst
index 918e32d76fc4..70720f00b9aa 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -51,24 +51,6 @@ to make sure their systems do not continue running in the 
face of
 "unreachable" conditions. (For example, see commits like `this one
 `_.)
 
-uninitialized_var()

-For any compiler warnings about uninitialized variables, just add
-an initializer. Using the uninitialized_var() macro (or similar
-warning-silencing tricks) is dangerous as it papers over `real bugs
-`_
-(or can in the future), and suppresses unrelated compiler warnings
-(e.g. "unused variable"). If the compiler thinks it is uninitialized,
-either simply initialize the variable or make compiler changes. Keep in
-mind that in most cases, if an initialization is obviously redundant,
-the compiler's dead-store elimination pass will make sure there are no
-needless variable writes.
-
-As Linus has said, this macro
-`must 
`_
-`be 
`_
-`removed 
`_.
-
 open-coded arithmetic in allocator arguments
 
 Dynamic size calculations (especially multiplication) should not be

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

[Neal Liu]

MediaTek bus fabric provides TrustZone security support and data
protection to prevent slaves from being accessed by unexpected
masters.
The security violation is logged and sent to the processor for
further analysis or countermeasures.

Any occurrence of security violation would raise an interrupt, and
it will be handled by mtk-devapc driver. The violation
information is printed in order to find the murderer.

Signed-off-by: Neal Liu 
---
 drivers/soc/mediatek/Kconfig  |9 ++
 drivers/soc/mediatek/Makefile |1 +
 drivers/soc/mediatek/mtk-devapc.c |  305 +
 3 files changed, 315 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-devapc.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 59a56cd..1177c98 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -17,6 +17,15 @@ config MTK_CMDQ
  time limitation, such as updating display configuration during the
  vblank.
 
+config MTK_DEVAPC
+   tristate "Mediatek Device APC Support"
+   help
+ Say yes here to enable support for Mediatek Device APC driver.
+ This driver is mainly used to handle the violation which catches
+ unexpected transaction.
+ The violation information is logged for further analysis or
+ countermeasures.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 01f9f87..abfd4ba 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
+obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-devapc.c 
b/drivers/soc/mediatek/mtk-devapc.c
new file mode 100644
index 000..0ba61d7
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VIO_MOD_TO_REG_IND(m)  ((m) / 32)
+#define VIO_MOD_TO_REG_OFF(m)  ((m) % 32)
+
+struct mtk_devapc_vio_dbgs {
+   union {
+   u32 vio_dbg0;
+   struct {
+   u32 mstid:16;
+   u32 dmnid:6;
+   u32 vio_w:1;
+   u32 vio_r:1;
+   u32 addr_h:4;
+   u32 resv:4;
+   } dbg0_bits;
+   };
+
+   u32 vio_dbg1;
+};
+
+struct mtk_devapc_data {
+   u32 vio_idx_num;
+   u32 vio_mask_offset;
+   u32 vio_sta_offset;
+   u32 vio_dbg0_offset;
+   u32 vio_dbg1_offset;
+   u32 apc_con_offset;
+   u32 vio_shift_sta_offset;
+   u32 vio_shift_sel_offset;
+   u32 vio_shift_con_offset;
+};
+
+struct mtk_devapc_context {
+   struct device *dev;
+   void __iomem *infra_base;
+   struct clk *infra_clk;
+   const struct mtk_devapc_data *data;
+};
+
+static void clear_vio_status(struct mtk_devapc_context *ctx)
+{
+   void __iomem *reg;
+   int i;
+
+   reg = ctx->infra_base + ctx->data->vio_sta_offset;
+
+   for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++)
+   writel(GENMASK(31, 0), reg + 4 * i);
+
+   writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), 0),
+  reg + 4 * i);
+}
+
+static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
+{
+   void __iomem *reg;
+   u32 val;
+   int i;
+
+   reg = ctx->infra_base + ctx->data->vio_mask_offset;
+
+   if (mask)
+   val = GENMASK(31, 0);
+   else
+   val = 0;
+
+   for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++)
+   writel(val, reg + 4 * i);
+
+   val = readl(reg + 4 * i);
+   if (mask)
+   val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1),
+  0);
+   else
+   val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1),
+   0);
+
+   writel(val, reg + 4 * i);
+}
+
+#define PHY_DEVAPC_TIMEOUT 0x1
+
+/*
+ * devapc_sync_vio_dbg - do "shift" mechansim" to get full violation 
information.
+ *   shift mechanism is depends on devapc hardware design.
+ *   Mediatek devapc set multiple slaves as a group.
+ *   When violation is triggered, violation info is kept
+ *   inside devapc hardware.
+ *   Driver should do shift mechansim to sync full 
violation
+ *   info to VIO_DBGs registers.
+ *
+ */
+static int 

[PATCH v7] Add MediaTek MT6779 devapc driver

[Neal Liu]

These patch series introduce a MediaTek MT6779 devapc driver.

MediaTek bus fabric provides TrustZone security support and data protection to 
prevent slaves from being accessed by unexpected masters.
The security violation is logged and sent to the processor for further analysis 
or countermeasures.

Any occurrence of security violation would raise an interrupt, and it will be 
handled by mtk-devapc driver.
The violation information is printed in order to find the murderer.

changes since v6:
- remove unnecessary mask/unmask module irq during ISR.

changes since v5:
- remove redundant write reg operation.
- use static variable of vio_dbgs instead.
- add stop_devapc() if driver is removed.

changes since v4:
- refactor data structure.
- merge two simple functions into one.
- refactor register setting to prevent too many function call overhead.

changes since v3:
- revise violation handling flow to make it more easily to understand
  hardware behavior.
- add more comments to understand how hardware works.

changes since v2:
- pass platform info through DT data.
- remove unnecessary function.
- remove slave_type because it always equals to 1 in current support SoC.
- use vio_idx_num instread of list all devices' index.
- add more comments to describe hardware behavior.

changes since v1:
- move SoC specific part to DT data.
- remove unnecessary boundary check.
- remove unnecessary data type declaration.
- use read_poll_timeout() instread of for loop polling.
- revise coding style elegantly.


*** BLURB HERE ***

Neal Liu (2):
  dt-bindings: devapc: add bindings for mtk-devapc
  soc: mediatek: add mt6779 devapc driver

 .../bindings/soc/mediatek/devapc.yaml |  58 
 drivers/soc/mediatek/Kconfig  |   9 +
 drivers/soc/mediatek/Makefile |   1 +
 drivers/soc/mediatek/mtk-devapc.c | 305 ++
 4 files changed, 373 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
 create mode 100644 drivers/soc/mediatek/mtk-devapc.c

-- 
2.18.0

[PATCH v7 1/2] dt-bindings: devapc: add bindings for mtk-devapc

[Neal Liu]

Add bindings for mtk-devapc.

Signed-off-by: Neal Liu 
---
 .../devicetree/bindings/soc/mediatek/devapc.yaml   |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml 
b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
new file mode 100644
index 000..6c763f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# # Copyright 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: MediaTek Device Access Permission Control driver
+
+description: |
+  MediaTek bus fabric provides TrustZone security support and data
+  protection to prevent slaves from being accessed by unexpected masters.
+  The security violation is logged and sent to the processor for further
+  analysis and countermeasures.
+
+maintainers:
+  - Neal Liu 
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt6779-devapc
+
+  reg:
+description: The base address of devapc register bank
+maxItems: 1
+
+  interrupts:
+description: A single interrupt specifier
+maxItems: 1
+
+  clocks:
+description: Contains module clock source and clock names
+maxItems: 1
+
+  clock-names:
+description: Names of the clocks list in clocks property
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+examples:
+  - |
+#include 
+#include 
+
+devapc: devapc@10207000 {
+  compatible = "mediatek,mt6779-devapc";
+  reg = <0x10207000 0x1000>;
+  interrupts = ;
+  clocks = <_ao CLK_INFRA_DEVICE_APC>;
+  clock-names = "devapc-infra-clock";
+};
-- 
1.7.9.5

Re: [PATCH v5 0/7] Fix timeout clock used by hardware data timeout

[Sowjanya Komatineni]

Sorry please ignore this series.

Wrong patches from my system went out.

Will send as v6.

Thanks

Sowjanya

On 8/26/20 1:05 PM, Sowjanya Komatineni wrote:

Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.

Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra sdmmc driver.

This series includes patches to fix this for Tegra210/Tegra186/Tegra194.

These patches need to be manually backported for 4.9, 4.14 and 4.19.

Will send patches to backport separately once these patches are ack'd.

Delta between patch versions:
[v5]:   Include below changes based on v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
  based on no. of clocks in sdhci device node as old device trees
  do not use sdhci clock name and this allows proper clock retrival
  irrespective of sdhci and tmclk clocks order in device tree.  
- Added separate quirk for identifying SoC's supporting separate
  timeout clock to be more clear.

[v4]:   Include additional dt-binding patch

[v3]:   Same as v2 with fixes tag

[v2]:   Includes minor fix
- Patch-0006: parentheses around operand of '!'

Sowjanya Komatineni (7):
   sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
   sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
   dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later
   arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
   arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
   arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
   sdhci: tegra: Add missing TMCLK for data timeout

  .../bindings/mmc/nvidia,tegra20-sdhci.txt  | 32 +++-
  arch/arm64/boot/dts/nvidia/tegra186.dtsi   | 20 +++--
  arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 15 ++--
  arch/arm64/boot/dts/nvidia/tegra210.dtsi   | 20 +++--
  drivers/mmc/host/sdhci-tegra.c | 91 +++---
  5 files changed, 143 insertions(+), 35 deletions(-)

kernel BUG at fs/ext4/inode.c:LINE!

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:c3d8f220 Merge tag 'kbuild-fixes-v5.9' of git://git.kernel..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f83cb690
kernel config:  https://syzkaller.appspot.com/x/.config?x=bb68b9e8a8cc842f
dashboard link: https://syzkaller.appspot.com/bug?extid=3622cea378100f45d59f
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1287ac9690
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11c7ac4690

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

[ cut here ]
kernel BUG at fs/ext4/inode.c:2598!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 27612 Comm: syz-executor879 Not tainted 5.9.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:mpage_prepare_extent_to_map+0xd34/0xd40 fs/ext4/inode.c:2598
Code: 89 e8 a0 74 9f ff 0f 0b e8 59 81 70 ff 4c 89 e7 48 c7 c6 da a3 07 89 e8 
8a 74 9f ff 0f 0b e8 43 81 70 ff 0f 0b e8 3c 81 70 ff <0f> 0b e8 c5 b3 25 06 0f 
1f 44 00 00 55 41 57 41 56 41 55 41 54 53
RSP: 0018:c9000a0974d8 EFLAGS: 00010293
RAX: 820476e4 RBX: 00fffe00a01f RCX: 88808ea5c340
RDX:  RSI: a01f RDI: 
RBP: ea00020d4f80 R08: 820471e4 R09: f9400041a9f1
R10: f9400041a9f1 R11:  R12: ea00020d4f80
R13: c9000a0977b0 R14: 1d400041a9f1 R15: dc00
FS:  7f5055f25700() GS:8880ae90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004ae4b0 CR3: a2d7f000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 ext4_writepages+0xa98/0x3750 fs/ext4/inode.c:2735
 do_writepages+0xda/0x1f0 mm/page-writeback.c:2352
 __filemap_fdatawrite_range+0x2a5/0x350 mm/filemap.c:422
 filemap_write_and_wait_range+0xca/0x160 mm/filemap.c:655
 iomap_dio_rw+0x5a7/0xeb0 fs/iomap/direct-io.c:478
 ext4_dio_read_iter fs/ext4/file.c:77 [inline]
 ext4_file_read_iter+0x544/0x6d0 fs/ext4/file.c:129
 call_read_iter include/linux/fs.h:1876 [inline]
 generic_file_splice_read+0x3c5/0x640 fs/splice.c:312
 do_splice_to fs/splice.c:870 [inline]
 splice_direct_to_actor+0x3bd/0xb60 fs/splice.c:950
 do_splice_direct+0x201/0x340 fs/splice.c:1059
 do_sendfile+0x86d/0x1210 fs/read_write.c:1540
 __do_sys_sendfile64 fs/read_write.c:1601 [inline]
 __se_sys_sendfile64 fs/read_write.c:1587 [inline]
 __x64_sys_sendfile64+0x164/0x1a0 fs/read_write.c:1587
 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x448bc9
Code: e8 1c e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
0b 06 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f5055f24ce8 EFLAGS: 0246 ORIG_RAX: 0028
RAX: ffda RBX: 006e4a28 RCX: 00448bc9
RDX:  RSI: 0006 RDI: 0004
RBP: 006e4a20 R08:  R09: 
R10: 8400fffb R11: 0246 R12: 006e4a2c
R13: 7ffdc73a76df R14: 7f5055f259c0 R15: 20c49ba5e353f7cf
Modules linked in:
---[ end trace aba5fca59eda2183 ]---
RIP: 0010:mpage_prepare_extent_to_map+0xd34/0xd40 fs/ext4/inode.c:2598
Code: 89 e8 a0 74 9f ff 0f 0b e8 59 81 70 ff 4c 89 e7 48 c7 c6 da a3 07 89 e8 
8a 74 9f ff 0f 0b e8 43 81 70 ff 0f 0b e8 3c 81 70 ff <0f> 0b e8 c5 b3 25 06 0f 
1f 44 00 00 55 41 57 41 56 41 55 41 54 53
RSP: 0018:c9000a0974d8 EFLAGS: 00010293
RAX: 820476e4 RBX: 00fffe00a01f RCX: 88808ea5c340
RDX:  RSI: a01f RDI: 
RBP: ea00020d4f80 R08: 820471e4 R09: f9400041a9f1
R10: f9400041a9f1 R11:  R12: ea00020d4f80
R13: c9000a0977b0 R14: 1d400041a9f1 R15: dc00
FS:  7f5055f25700() GS:8880ae90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004ae4b0 CR3: a2d7f000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:

Re: [PATCH v5 7/7] sdhci: tegra: Add missing TMCLK for data timeout

[kernel test robot]

Hi Sowjanya,

I love your patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on tegra/for-next v5.9-rc2 next-20200826]
[cannot apply to ulf.hansson-mmc/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sowjanya-Komatineni/Fix-timeout-clock-used-by-hardware-data-timeout/20200827-040814
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

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

All errors (new ones prefixed by >>):

>> drivers/mmc/host/sdhci-tegra.c:1496:24: error: expected '}' before ';' token
1496 |   NVQUIRK_HAS_TMCLK;
 |^
   drivers/mmc/host/sdhci-tegra.c:1488:62: note: to match this '{'
1488 | static const struct sdhci_tegra_soc_data soc_data_tegra194 = {
 |  ^
   drivers/mmc/host/sdhci-tegra.c: In function 'sdhci_tegra_probe':
>> drivers/mmc/host/sdhci-tegra.c:1643:6: error: implicit declaration of 
>> function 'of_clk_get_parent_count' [-Werror=implicit-function-declaration]
1643 |  if (of_clk_get_parent_count(>dev) == 1) {
 |  ^~~
>> drivers/mmc/host/sdhci-tegra.c:1648:22: error: 'dev' undeclared (first use 
>> in this function); did you mean 'pdev'?
1648 |   clk = devm_clk_get(dev, NULL)
 |  ^~~
 |  pdev
   drivers/mmc/host/sdhci-tegra.c:1648:22: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/mmc/host/sdhci-tegra.c:1648:32: error: expected ';' before 'if'
1648 |   clk = devm_clk_get(dev, NULL)
 |^
 |;
1649 |   if (IS_ERR(clk)) {
 |   ~~
   drivers/mmc/host/sdhci-tegra.c:1682:35: error: expected ';' before 'if'
1682 |   clk = devm_clk_get(dev, "sdhci")
 |   ^
 |   ;
1683 |   if (IS_ERR(clk)) {
 |   ~~   
   drivers/mmc/host/sdhci-tegra.c:1727:1: warning: label 'err_clk_get' defined 
but not used [-Wunused-label]
1727 | err_clk_get:
 | ^~~
   cc1: some warnings being treated as errors

# 
https://github.com/0day-ci/linux/commit/51ed0e529a10cbce9dba08a11817207acb1b5bcf
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sowjanya-Komatineni/Fix-timeout-clock-used-by-hardware-data-timeout/20200827-040814
git checkout 51ed0e529a10cbce9dba08a11817207acb1b5bcf
vim +1496 drivers/mmc/host/sdhci-tegra.c

  1487  
  1488  static const struct sdhci_tegra_soc_data soc_data_tegra194 = {
  1489  .pdata = _tegra186_pdata,
  1490  .dma_mask = DMA_BIT_MASK(39),
  1491  .nvquirks = NVQUIRK_NEEDS_PAD_CONTROL |
  1492  NVQUIRK_HAS_PADCALIB |
  1493  NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
  1494  NVQUIRK_ENABLE_SDR50 |
  1495  NVQUIRK_ENABLE_SDR104 |
> 1496  NVQUIRK_HAS_TMCLK;
  1497  .min_tap_delay = 96,
  1498  .max_tap_delay = 139,
  1499  };
  1500  
  1501  static const struct of_device_id sdhci_tegra_dt_match[] = {
  1502  { .compatible = "nvidia,tegra194-sdhci", .data = 
_data_tegra194 },
  1503  { .compatible = "nvidia,tegra186-sdhci", .data = 
_data_tegra186 },
  1504  { .compatible = "nvidia,tegra210-sdhci", .data = 
_data_tegra210 },
  1505  { .compatible = "nvidia,tegra124-sdhci", .data = 
_data_tegra124 },
  1506  { .compatible = "nvidia,tegra114-sdhci", .data = 
_data_tegra114 },
  1507  { .compatible = "nvidia,tegra30-sdhci", .data = 
_data_tegra30 },
  1508  { .compatible = "nvidia,tegra20-sdhci", .data = 
_data_tegra20 },
  1509  {}
  1510  };
  1511  MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
  1512  
  1513  static int sdhci_tegra_add_host(struct sdhci_host *host)
  1514  {
  1515  struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
  1516  struct sdhci_tegra *tegra_host = sdhci_pltfm_pr

Re: [PATCH v3] lib/string.c: implement stpcpy

[Joe Perches]

On Wed, 2020-08-26 at 19:33 -0700, Kees Cook wrote:
> On Wed, Aug 26, 2020 at 04:57:41PM -0700, Joe Perches wrote:
> > On Wed, 2020-08-26 at 16:38 -0700, Kees Cook wrote:
> > > On Thu, Aug 27, 2020 at 07:59:45AM +0900, Masahiro Yamada wrote:
> > []
> > > > OK, then stpcpy(), strcpy() and sprintf()
> > > > have the same level of unsafety.
> > > 
> > > Yes. And even snprintf() is dangerous because its return value is how
> > > much it WOULD have written, which when (commonly) used as an offset for
> > > further pointer writes, causes OOB writes too. :(
> > > https://github.com/KSPP/linux/issues/105
> > > 
> > > > strcpy() is used everywhere.
> > > 
> > > Yes. It's very frustrating, but it's not an excuse to continue
> > > using it nor introducing more bad APIs.
> > > 
> > > $ git grep '\bstrcpy\b' | wc -l
> > > 2212
> > > $ git grep '\bstrncpy\b' | wc -l
> > > 751
> > > $ git grep '\bstrlcpy\b' | wc -l
> > > 1712
> > > 
> > > $ git grep '\bstrscpy\b' | wc -l
> > > 1066
> > > 
> > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
> > > https://github.com/KSPP/linux/issues/88
> > > 
> > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> > > https://github.com/KSPP/linux/issues/89
> > > 
> > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
> > > https://github.com/KSPP/linux/issues/90
> > > 
> > > We have no way right now to block the addition of deprecated API usage,
> > > which makes ever catching up on this replacement very challenging.
> > 
> > These could be added to checkpatch's deprecated_api test.
> > ---
> >  scripts/checkpatch.pl | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 149518d2a6a7..f9ccb2a63a95 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -605,6 +605,9 @@ foreach my $entry (@mode_permission_funcs) {
> >  $mode_perms_search = "(?:${mode_perms_search})";
> >  
> >  our %deprecated_apis = (
> > +   "strcpy"=> "strscpy",
> > +   "strncpy"   => "strscpy",
> > +   "strlcpy"   => "strscpy",
> > "synchronize_rcu_bh"=> "synchronize_rcu",
> > "synchronize_rcu_bh_expedited"  => "synchronize_rcu_expedited",
> > "call_rcu_bh"   => "call_rcu",
> > 
> > 
> 
> Good idea, yeah. We, unfortunately, need to leave strncpy() off this
> list for now because it's not *strictly* deprecated (see the notes in
> bug report[1]), but the others can be.

OK, but it is in Documentation/process/deprecated.rst

strncpy() on NUL-terminated strings
---
Use of strncpy() does not guarantee that the destination buffer
will be NUL terminated. This can lead to various linear read overflows
and other misbehavior due to the missing termination. It also NUL-pads the
destination buffer if the source contents are shorter than the destination
buffer size, which may be a needless performance penalty for callers using
only NUL-terminated strings. The safe replacement is strscpy().
(Users of strscpy() still needing NUL-padding should instead
use strscpy_pad().)

If a caller is using non-NUL-terminated strings, strncpy() can
still be used, but destinations should be marked with the `__nonstring
`_
attribute to avoid future compiler warnings.

[PATCH] ice: Fix memleak in ice_set_ringparam

[Dinghao Liu]

When kcalloc() on rx_rings fails, we should free tx_rings
and xdp_rings to prevent memleak. Similarly, when
ice_alloc_rx_bufs() fails, we should free xdp_rings.

Signed-off-by: Dinghao Liu 
---
 drivers/net/ethernet/intel/ice/ice_ethtool.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c 
b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index 9e8e9531cd87..caf64eb5e96d 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -2863,7 +2863,7 @@ ice_set_ringparam(struct net_device *netdev, struct 
ethtool_ringparam *ring)
rx_rings = kcalloc(vsi->num_rxq, sizeof(*rx_rings), GFP_KERNEL);
if (!rx_rings) {
err = -ENOMEM;
-   goto done;
+   goto free_xdp;
}
 
ice_for_each_rxq(vsi, i) {
@@ -2892,7 +2892,7 @@ ice_set_ringparam(struct net_device *netdev, struct 
ethtool_ringparam *ring)
}
kfree(rx_rings);
err = -ENOMEM;
-   goto free_tx;
+   goto free_xdp;
}
}
 
@@ -2943,6 +2943,15 @@ ice_set_ringparam(struct net_device *netdev, struct 
ethtool_ringparam *ring)
}
goto done;
 
+free_xdp:
+   if (xdp_rings) {
+   for (i = 0; i < vsi->num_xdp_txq; i++) {
+   ice_free_tx_ring(vsi->xdp_rings[i]);
+   *vsi->xdp_rings[i] = xdp_rings[i];
+   }
+   kfree(xdp_rings);
+   }
+
 free_tx:
/* error cleanup if the Rx allocations failed after getting Tx */
if (tx_rings) {
-- 
2.17.1

Re: [PATCH v3] lib/string.c: implement stpcpy

[Kees Cook]

On Wed, Aug 26, 2020 at 04:57:41PM -0700, Joe Perches wrote:
> On Wed, 2020-08-26 at 16:38 -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2020 at 07:59:45AM +0900, Masahiro Yamada wrote:
> []
> > > OK, then stpcpy(), strcpy() and sprintf()
> > > have the same level of unsafety.
> > 
> > Yes. And even snprintf() is dangerous because its return value is how
> > much it WOULD have written, which when (commonly) used as an offset for
> > further pointer writes, causes OOB writes too. :(
> > https://github.com/KSPP/linux/issues/105
> > 
> > > strcpy() is used everywhere.
> > 
> > Yes. It's very frustrating, but it's not an excuse to continue
> > using it nor introducing more bad APIs.
> > 
> > $ git grep '\bstrcpy\b' | wc -l
> > 2212
> > $ git grep '\bstrncpy\b' | wc -l
> > 751
> > $ git grep '\bstrlcpy\b' | wc -l
> > 1712
> > 
> > $ git grep '\bstrscpy\b' | wc -l
> > 1066
> > 
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
> > https://github.com/KSPP/linux/issues/88
> > 
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> > https://github.com/KSPP/linux/issues/89
> > 
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
> > https://github.com/KSPP/linux/issues/90
> > 
> > We have no way right now to block the addition of deprecated API usage,
> > which makes ever catching up on this replacement very challenging.
> 
> These could be added to checkpatch's deprecated_api test.
> ---
>  scripts/checkpatch.pl | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 149518d2a6a7..f9ccb2a63a95 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -605,6 +605,9 @@ foreach my $entry (@mode_permission_funcs) {
>  $mode_perms_search = "(?:${mode_perms_search})";
>  
>  our %deprecated_apis = (
> + "strcpy"=> "strscpy",
> + "strncpy"   => "strscpy",
> + "strlcpy"   => "strscpy",
>   "synchronize_rcu_bh"=> "synchronize_rcu",
>   "synchronize_rcu_bh_expedited"  => "synchronize_rcu_expedited",
>   "call_rcu_bh"   => "call_rcu",
> 
> 

Good idea, yeah. We, unfortunately, need to leave strncpy() off this
list for now because it's not *strictly* deprecated (see the notes in
bug report[1]), but the others can be.

[1] https://github.com/KSPP/linux/issues/89

-- 
Kees Cook

[PATCH v3] mm: memcg: Fix memcg reclaim soft lockup

[Xunlei Pang]

We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
the target memcg doesn't have any reclaimable memory.

It can be easily reproduced as below:
 watchdog: BUG: soft lockup - CPU#0 stuck for 111s![memcg_test:2204]
 CPU: 0 PID: 2204 Comm: memcg_test Not tainted 5.9.0-rc2+ #12
 Call Trace:
  shrink_lruvec+0x49f/0x640
  shrink_node+0x2a6/0x6f0
  do_try_to_free_pages+0xe9/0x3e0
  try_to_free_mem_cgroup_pages+0xef/0x1f0
  try_charge+0x2c1/0x750
  mem_cgroup_charge+0xd7/0x240
  __add_to_page_cache_locked+0x2fd/0x370
  add_to_page_cache_lru+0x4a/0xc0
  pagecache_get_page+0x10b/0x2f0
  filemap_fault+0x661/0xad0
  ext4_filemap_fault+0x2c/0x40
  __do_fault+0x4d/0xf9
  handle_mm_fault+0x1080/0x1790

It only happens on our 1-vcpu instances, because there's no chance
for oom reaper to run to reclaim the to-be-killed process.

Add a cond_resched() at the upper shrink_node_memcgs() to solve this
issue, this will mean that we will get a scheduling point for each
memcg in the reclaimed hierarchy without any dependency on the
reclaimable memory in that memcg thus making it more predictable.

Acked-by: Chris Down 
Acked-by: Michal Hocko 
Suggested-by: Michal Hocko 
Signed-off-by: Xunlei Pang 
---
 mm/vmscan.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 99e1796..9727dd8 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2615,6 +2615,14 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct 
scan_control *sc)
unsigned long reclaimed;
unsigned long scanned;
 
+   /*
+* This loop can become CPU-bound when target memcgs
+* aren't eligible for reclaim - either because they
+* don't have any reclaimable pages, or because their
+* memory is explicitly protected. Avoid soft lockups.
+*/
+   cond_resched();
+
mem_cgroup_calculate_protection(target_memcg, memcg);
 
if (mem_cgroup_below_min(memcg)) {
-- 
1.8.3.1

Re: [PATCH] MIPS: Loongson: Fix complie errors without CONFIG_SMP

[hejinyang]

On 08/26/2020 09:01 PM, Matthew Wilcox wrote:

On Wed, Aug 26, 2020 at 08:53:27PM +0800, Jinyang He wrote:

+++ b/arch/mips/include/asm/mach-loongson64/topology.h
@@ -4,7 +4,11 @@
  
  #ifdef CONFIG_NUMA
  
+#ifdef CONFIG_SMP

  #define cpu_to_node(cpu)  (cpu_logical_map(cpu) >> 2)
+#else
+#define cpu_to_node(cpu)   0
+#endif

Are you saying you've enabled NUMA without enabling SMP?  Does that make
sense?


NUMA option normally work with more than two nodes, though Loongson64 use it
default after patch 6fbde6b492dfc761ad60a68fb2cb32b1eb05b786. Loongson64(3A)'s
each node consists of 4 cpus while it only has 4 cpus. In other words, it has
only one node while open NUMA. I'm confused it if NUMA deponds on SMP.

I'll try fix it with unabling NUMA and SMP later.

Thanks.:-)

Re: [PATCH] linux/kernel.h: add container_from()

[Kees Cook]

On Thu, Aug 27, 2020 at 07:06:36AM +0530, Allen Pais wrote:
> Introduce container_from() as a generic helper instead of
> sub-systems defining a private from_* API
> (Eg: from_tasklets recently introduced in
> 12cc923f1ccc: Tasklet: Introduce new initialization API)
> 
> The helper is similar to container_of() in argument order
> with the difference of naming the containing structure instead
> of having to specify its type.
> 
> Suggested-by: James E.J. Bottomley 
> Suggested-by: Greg Kroah-Hartman 
> Suggested-by: Jens Axboe 
> Signed-off-by: Allen Pais 

Acked-by: Kees Cook 

Who can carry this so it can get used by multiple trees? Should I keep a
git branch folks should merge when taking Allen's conversion patches?

(In the future we can do a treewide replacement of the
subsystem-specific from*() macros into container_from())

Thanks!

-- 
Kees Cook

Re: [PATCH v2 00/13] extcon: ptn5150: Improvements and fixes

[Chanwoo Choi]

Hi Suman,

On 8/27/20 6:56 AM, Suman Anna wrote:
> Hi Chanwoo,
> 
> On 8/24/20 6:28 AM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 8/24/20 7:36 PM, Ramuthevar, Vadivel MuruganX wrote:
>>> Hi,
>>>
>>>  Thank you for the patches and optimized the code as well.
>>>  I have applied your patches and tested, it's working fine
>>>  with few minor changes as per Intel's LGM board.
>>
>> Thanks for the test.
>>
>>>
>>>  can I send the patches along with patches or we need to wait until
>>>  your patch get merge?
>>>
>>>  Please suggest to me go further, Thanks!
>>
>> I applied these patches. You better to send your patches
>> based on extcon-next. Thanks.
> 
> I am not sure what happened, but the $id and $schema got morphed in the patch
> on linux-next, 000ce2ad3c96 ("dt-bindings: extcon: ptn5150: Convert binding to
> DT schema"), when compared to Krzysztof's original patch.

It is my fault because of the company's firewall.
I updated and pushed it. Thanks.

> 
> This is causing dtbs_check to fail in general on linux-next,
>   UPD include/config/kernel.release
>   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> Traceback (most recent call last):
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 774, in resolve_from_url
> document = self.store[url]
>   File "/home/suman/.local/lib/python3.6/site-packages/jsonschema/_utils.py",
> line 22, in __getitem__
> return self.store[self.normalize(uri)]
> KeyError:
> 'https://protect2.fireeye.com/url?k=59835ffc-05905d01-59822c67-0cc47a336902-306bd2691e458c36=1=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 777, in resolve_from_url
> document = self.resolve_remote(url)
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 860, in resolve_remote
> result = requests.get(uri).json()
>   File "/usr/lib/python3/dist-packages/requests/models.py", line 892, in json
> return complexjson.loads(self.text, **kwargs)
>   File "/usr/lib/python3/dist-packages/simplejson/__init__.py", line 518, in 
> loads
> return _default_decoder.decode(s)
>   File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 370, in 
> decode
> obj, end = self.raw_decode(s)
>   File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 400, in
> raw_decode
> return self.scan_once(s, idx=_w(s, idx).end())
> simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/home/suman/.local/bin/dt-doc-validate", line 67, in 
> ret = check_doc(f)
>   File "/home/suman/.local/bin/dt-doc-validate", line 33, in check_doc
> for error in sorted(dtschema.DTValidator.iter_schema_errors(testtree),
> key=lambda e: e.linecol):
>   File "/home/suman/.local/lib/python3.6/site-packages/dtschema/lib.py", line
> 663, in iter_schema_errors
> meta_schema = cls.resolver.resolve_from_url(schema['$schema'])
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 779, in resolve_from_url
> raise exceptions.RefResolutionError(exc)
> jsonschema.exceptions.RefResolutionError: Expecting value: line 1 column 1 
> (char 0)
> Documentation/devicetree/bindings/Makefile:52: recipe for target
> 'Documentation/devicetree/bindings/processed-schema-examples.json' failed
> make[1]: *** 
> [Documentation/devicetree/bindings/processed-schema-examples.json]
> Error 123
> Makefile:1366: recipe for target 'dt_binding_check' failed
> make: *** [dt_binding_check] Error 2
> 
> regards
> Suman
> 
>>
>>>
>>> On 17/8/2020 2:59 pm, Krzysztof Kozlowski wrote:
 Hi,

 Changes since v1:
 1. Mutex unlock fix in patch 8/13.

 Best regards,
 Krzysztof

>>>
>>>
>>
>>
> 
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 1/2] usb typec: mt6360: Add support for mt6360 Type-C driver

[Guenter Roeck]

On 8/26/20 6:11 PM, 啟原黃 wrote:
> Guenter Roeck  於 2020年8月27日 週四 上午9:02寫道：
>>
>> On 8/26/20 5:59 PM, 啟原黃 wrote:
>> [ ... ]
> +static int mt6360_tcpc_remove(struct platform_device *pdev)
> +{
> + struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
> +
> + tcpci_unregister_port(mti->tcpci);

 That leaves interrupts enabled, which might be racy
 because interrupts are still enabled here.
>>> M..., yes, it will cause the race condition during module remove.
>>> I'll add disable_irq before tcpci unregister to prevent it.
>>
>> Or just set TCPC_ALERT_MASK to 0, as in tcpci.c.
> Both are right, Thx. I'll choose one.
> 
> BTW, it seems enum typec_cc_status is used by tcpci.h.
> If I don't include tcpm.h, it will raise a warning during the compile time.

Ok, thanks for the note (that means tcpci.h should include
linux/usb/tcpm.h, really).

Guenter

Re: [PATCH] perf stat: update POWER9 metrics to utilize other metrics

[Paul A. Clarke]

On Wed, Aug 26, 2020 at 09:26:40AM -0700, Ian Rogers wrote:
> On Fri, Aug 14, 2020 at 5:43 AM Arnaldo Carvalho de Melo
>  wrote:
> > Em Fri, Aug 14, 2020 at 11:20:42AM +0530, kajoljain escreveu:
> > > On 8/14/20 9:13 AM, Ian Rogers wrote:
> > > > On Thu, Aug 13, 2020 at 3:21 PM Paul A. Clarke  wrote:
> > > >> These changes take advantage of the new capability added in
> > > >> merge commit 00e4db51259a5f936fec1424b884f029479d3981
> > > >> "Allow using computed metrics in calculating other metrics".
> > > >>
> > > >> The net is a simplification of the expressions for a handful
> > > >> of metrics, but no functional change.
> > > >>
> > > >> Signed-off-by: Paul A. Clarke 
> > >
> > >   The patch looks good to me.
> > >
> > > Reviewed-by: Kajol Jain
> >
> > Thanks, applied. Added Ian's Acked-by as well.
> 
> I've synced perf and testing on a remote machine (not easy for me to
> log into) I see failures in perf test "10.3: Parsing of PMU event
> table metrics" like:
> ...
> parsing metric: dfu_stall_cpi - dflong_stall_cpi
> Parse event failed metric 'dfu_other_stall_cpi' id 'dflong_stall_cpi'
> expr 'dfu_stall_cpi - dflong_stall_cpi'
> Error string 'parser error' help '(null)'
> Parse event failed metric 'dfu_other_stall_cpi' id 'dfu_stall_cpi'
> expr 'dfu_stall_cpi - dflong_stall_cpi'
> Error string 'parser error' help '(null)'
> ...
> 
> This may be that the test doesn't handle the metric in terms of metric
> addition and so I'll look for a fix. I thought I'd send a heads up in
> case you had already seen/addressed this. Is perf test on PowerPC
> clean for you at the moment?

I see these errors as well (on 5.9-rc2).  Each error seems to be for the
newer metrics that take advantage of the newer functionality, including
the metrics I changed recently, and Kajol's 24x7 and nest metrics.

Thanks for the heads up!  I confess I had not seen the errors only because
I wasn't looking.  :-/

PC

Re: [PATCH 5/6] pwm: sprd: Simplify with dev_err_probe()

[Chunyan Zhang]

On Wed, 26 Aug 2020 at 22:48, Krzysztof Kozlowski  wrote:
>
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe().  Less code and also it prints the error value.
>
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Chunyan Zhang 

Thanks!

> ---
>  drivers/pwm/pwm-sprd.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pwm/pwm-sprd.c b/drivers/pwm/pwm-sprd.c
> index be2394227423..5123d948efd6 100644
> --- a/drivers/pwm/pwm-sprd.c
> +++ b/drivers/pwm/pwm-sprd.c
> @@ -228,11 +228,8 @@ static int sprd_pwm_clk_init(struct sprd_pwm_chip *spc)
> if (ret == -ENOENT)
> break;
>
> -   if (ret != -EPROBE_DEFER)
> -   dev_err(spc->dev,
> -   "failed to get channel clocks\n");
> -
> -   return ret;
> +   return dev_err_probe(spc->dev, ret,
> +"failed to get channel 
> clocks\n");
> }
>
> clk_pwm = chn->clks[SPRD_PWM_CHN_OUTPUT_CLK].clk;
> --
> 2.17.1
>

Re: [PATCH v8 1/2] Add a "nosymfollow" mount option.

[Al Viro]

On Wed, Aug 26, 2020 at 02:48:19PM -0600, Ross Zwisler wrote:

> Al, now that the changes to fs/namei.c have landed and we're past the merge
> window for v5.9, what are your thoughts on this patch and the associated test?

Humm...  should that be nd->path.mnt->mnt_flags or link->mnt->mnt_flags?
Usually it's the same thing, but they might differ.  IOW, is that about the
directory we'd found it in, or is it about the link itself?

Re: [PATCH v1 5/9] phy: qcom-qmp: Get dp_com I/O resource by index

[Bjorn Andersson]

On Wed 26 Aug 16:32 CDT 2020, Stephen Boyd wrote:

> Quoting Bjorn Andersson (2020-08-25 21:36:16)
> > On Tue 25 Aug 21:47 CDT 2020, Stephen Boyd wrote:
> > 
> > > The dp_com resource is always at index 1 according to the dts files in
> > > the kernel. Get this resource by index so that we don't need to make
> > > future additions to the DT binding use 'reg-names'.
> > > 
> > 
> > Afaict the DT binding for the USB/DP phy defines that there should be a
> > reg name of "dp_com" and the current dts files all specifies this. Am I
> > missing something?
> 
> Yes the binding enforces this but this patch is removing that
> enforcement and instead mandating that dp_com is always at index 1 (i.e.
> the second one) so that we can add the DP serdes region directly after
> and avoid adding yet another reg-names property. I changed the binding
> for this usb3-dp phy compatible to make reg-names optional as well. I
> don't see any gain from using reg-names.
> 

Thanks for the explanation, I don't have any objections to this.

> > 
> > PS. Why isn't this a devm_platform_ioremap_resource{,_byname}()?
> 
> Sure. I'll roll that into this patch.

Thanks,
Bjorn

Re: [PATCH v2 2/2] soc: qcom: rpmh: Allow RPMH driver to be loaded as a module

[Bjorn Andersson]

On Tue 25 Aug 06:21 CDT 2020, Maulik Shah wrote:

> From: John Stultz 
> 
> This patch allow the rpmh driver to be loaded as a permenent
> module. Meaning it can be loaded from a module, but then cannot
> be unloaded.
> 
> Ideally, it would include a remove hook and related logic, but
> the rpmh driver is fairly core to the system, so once its loaded
> with almost anything else to get the system to go, the dependencies
> are not likely to ever also be removed.
> 
> So making it a permanent module at least improves things slightly
> over requiring it to be a built in driver.
> 
> Cc: Todd Kjos 
> Cc: Saravana Kannan 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Rajendra Nayak 
> Cc: linux-arm-...@vger.kernel.org
> Signed-off-by: John Stultz 
> Signed-off-by: Bjorn Andersson 
> [mkshah: Fix typos in commit message, send after removing _rcuidle trace]
> Signed-off-by: Maulik Shah 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/soc/qcom/Kconfig| 2 +-
>  drivers/soc/qcom/rpmh-rsc.c | 5 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 3dc3e3d..892bdc7 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -92,7 +92,7 @@ config QCOM_RMTFS_MEM
> Say y here if you intend to boot the modem remoteproc.
>  
>  config QCOM_RPMH
> - bool "Qualcomm RPM-Hardened (RPMH) Communication"
> + tristate "Qualcomm RPM-Hardened (RPMH) Communication"
>   depends on ARCH_QCOM || COMPILE_TEST
>   help
> Support for communication with the hardened-RPM blocks in
> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
> index fabe390d..5fce87c 100644
> --- a/drivers/soc/qcom/rpmh-rsc.c
> +++ b/drivers/soc/qcom/rpmh-rsc.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1025,6 +1026,7 @@ static const struct of_device_id rpmh_drv_match[] = {
>   { .compatible = "qcom,rpmh-rsc", },
>   { }
>  };
> +MODULE_DEVICE_TABLE(of, rpmh_drv_match);
>  
>  static struct platform_driver rpmh_driver = {
>   .probe = rpmh_rsc_probe,
> @@ -1040,3 +1042,6 @@ static int __init rpmh_driver_init(void)
>   return platform_driver_register(_driver);
>  }
>  arch_initcall(rpmh_driver_init);
> +
> +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. RPMh Driver");
> +MODULE_LICENSE("GPL v2");
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

[PATCH v9 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

[Ben Levinsky]

The driver was tested on Xilinx ZynqMP

For sake of ease of review, only support ZynqMP. Once accepted, then
add support for Versal platform and R5 loading onto OCM.

v2:
- remove domain struct as per review from Mathieu
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4:
- add default values for enums
- fix formatting as per checkpatch.pl --strict. Note that 1 warning and
  1 check are still raised as each is due to fixing the warning
  results in that particular line going over 80 characters.
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
- parse_fw change from use of rproc_of_resm_mem_entry_init to
  rproc_mem_entry_init and use of alloc/release
- var's of type zynqmp_r5_pdata all have same local variable name
- use dev_dbg instead of dev_info
v6:
- adding memory carveouts is handled much more similarly.
  All mem carveouts are now described in reserved memory as needed.
  That is, TCM nodes are not coupled to remoteproc anymore.
  This is reflected in the remoteproc R5 driver and the device tree
  binding.
- remove mailbox from device tree binding as it is not necessary for elf
  loading 
v7:
- remove unused headers
- zynqmp_r5_remoteproc_probe:lockstep_mode from u32* to u32
- device-tree binding "lockstep-mode"  to "xlnx,cluster-mode"
- remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
  probe()
- remove is_r5_mode_set from  zynqmp rpu remote processor private data
- do not error out if no mailbox is provided since mailboxes are optional
- remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as pdata
  is handled in zynqmp_r5_remoteproc_remove
v8:
- remove old acks, reviewed-by's in commit message
v9:
- if zynqmp_r5_remoteproc.c pdata->tx_mc_skbs not initialized, then do not
  call skb_queue_empty
- update arguments and documentation for zynqmp_pm_set_rpu_mode
- in fn zynqmp_pm_force_powerdown, change arg 'target' to 'node'
- zynqmp_pm_request_wakeup update code style
- edit 3/5 patch commit message
- document zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode
  documentation to include expected return val
- remove unused fn zynqmp_pm_get_node_status
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode uses second arg
- zynqmp_r5_remoteproc.c use of zynqmp_pm_set_tcm_config now does not
  have output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change lockstep_mode from u32* to u32
- update zynqmp_pm_set_rpu_mode and zynqmp_pm_set_rpu_mode documentation
  and remove unused args
v10:
- add include types.h to xlnx-zynqmp.h for compilation

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 

[PATCH v10 2/5] firmware: xilinx: Add shutdown/wakeup APIs

[Ben Levinsky]

Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
- fix formatting
v4:
- add default values for enumv3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
- fix formatting
v4:
- add default values for enum
v9:
- zynqmp_pm_force_powerdown update arg 'target' to 'node'
- zynqmp_pm_request_wakeup fix code style
v10:
- add types.h to includes for compilation
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,41 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  Node ID of the targeted PU or subsystem
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * Return: status, either success or error+reason
+ */
+int zynqmp_pm_force_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - PM call to wake up selected master or subsystem
+ * @node:  Node ID of the master or subsystem
+ * @set_addr:  Specifies whether the address argument is relevant
+ * @address:   Address from which to resume when woken up
+ * @ack:   Flag to specify whether acknowledge requested
+ *
+ * Return: status, either success or error+reason
+ */
+int zynqmp_pm_request_wake(const u32 node,
+  const bool set_addr,
+  const u64 address,
+  const enum zynqmp_pm_request_ack ack)
+{
+   /* set_addr flag is encoded into 1st bit of address */
+   return zynqmp_pm_invoke_fn(PM_REQUEST_WAKEUP, node, address | set_addr,
+  address >> 32, ack, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
+
 /**
  * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
  * @node:  Node ID of the slave
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index bb347dfe4ba4..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,8 @@
 
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_FORCE_POWERDOWN = 8,
+   PM_REQUEST_WAKEUP = 10,
PM_SYSTEM_SHUTDOWN = 12,
PM_REQUEST_NODE = 13,
PM_RELEASE_NODE,
@@ -376,6 +379,12 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
 int zynqmp_pm_read_pggs(u32 index, u32 *value);
 int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
 int zynqmp_pm_set_boot_health_status(u32 value);
+int zynqmp_pm_force_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(const u32 node,
+  const bool set_addr,
+  const u64 address,
+  const enum zynqmp_pm_request_ack ack);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -526,6 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1

[PATCH v10 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

[Ben Levinsky]

R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations: split or lock-step.

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Ben Levinsky 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
---
v2:
 - remove domain struct as per review from Mathieu
 v3:
 - add xilinx-related platform mgmt fn's instead of wrapping around
   function pointer in xilinx eemi ops struct
 v4:
 - add default values for enums
 - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 check
   are still raised as each is due to fixing the warning results in that
 particular line going over 80 characters.
 v5:
 - parse_fw change from use of rproc_of_resm_mem_entry_init to
 rproc_mem_entry_init and use of alloc/release
 - var's of type zynqmp_r5_pdata all have same local variable name
 - use dev_dbg instead of dev_info
 v6:
 - adding memory carveouts is handled much more similarly. All mem
 carveouts are
   now described in reserved memory as needed. That is, TCM nodes are not
   coupled to remoteproc anymore. This is reflected in the remoteproc R5
 driver
   and the device tree binding.
 - remove mailbox from device tree binding as it is not necessary for elf
   loading
 - use lockstep-mode property for configuring RPU
 v7:
 - remove unused headers
 - change  u32 *lockstep_mode ->  u32 lockstep_mode;
 - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
 - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
   remoteproc-probe time
 - remove is_r5_mode_set from  zynqmp rpu remote processor private data
 - do not error out if no mailbox is provided
 - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
 pdata is
   handled in zynqmp_r5_remoteproc_remove
v8:
 - remove old acks, reviewed-by's in commit message
v9:
- as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
  do not call skb_queue_empty
- update usage for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config and
  zynqmp_pm_get_rpu_mode
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- use of zynqmp_pm_set_tcm_config now does not have
  output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change var lockstep_mode from u32* to u32
---
 drivers/remoteproc/Kconfig|  10 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 898 ++
 3 files changed, 909 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c4d1731295eb..dd9ed45654e0 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -249,6 +249,16 @@ config STM32_RPROC
 
  This can be either built-in or a loadable module.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP_R5 remoteproc support"
+   depends on ARM64 && PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select MAILBOX
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
+
 endif # REMOTEPROC
 
 endmenu
diff --git 

[PATCH v10 3/5] firmware: xilinx: Add RPU configuration APIs

[Ben Levinsky]

This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
v9:
- update commit message
- for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
  expected output, arguments as well removing unused args
- remove unused fn zynqmp_pm_get_node_status
---
 drivers/firmware/xilinx/zynqmp.c | 51 
 include/linux/firmware/xlnx-zynqmp.h | 22 
 2 files changed, 73 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..6907abcaa981 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,57 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @out:   Returned output value
+ *
+ * Return: RPU mode. This is enum rpu_oper_mode
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, u32 *out)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_GET_RPU_OPER_MODE, 0, 0, out);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @arg1:  Argument 1 to requested IOCTL call. This is expeted to
+ *  to be value from enum rpu_oper_mode
+ * @out:   Returned output value
+ *
+ * This function is used to set RPU mode to split or lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id,
+  u32 arg1, u32 *out)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, arg1, 0, out);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @arg1:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ * @out:   Returned output value
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id,
+u32 arg1, u32 *out)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, arg1, 0, out);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..c9977d890095 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,11 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, u32 *out);
+int zynqmp_pm_set_rpu_mode(u32 node_id,
+  u32 arg1, u32 *out);
+int zynqmp_pm_set_tcm_config(u32 node_id,
+u32 arg1, u32 *out);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +554,23 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, u32 *out)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id,
+u32 arg1, u32 *out)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id,
+  u32 arg1, u32 *out)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1

[PATCH v10 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

[Ben Levinsky]

Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---

 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1

[PATCH v10 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

[Ben Levinsky]

Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Ben Levinsky 
Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
---
v3:
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4::
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
v6:
- remove coupling TCM nodes with remoteproc 
- remove mailbox as it is optional not needed
v7:
- change lockstep-mode to xlnx,cluster-mode
v9:
- show example IPC nodes and tcm bank nodes
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 113 ++
 1 file changed, 113 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..f4a28831af6c
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: "xlnx,zynqmp-r5-remoteproc-1.0"
+
+  lockstep-mode:
+description:
+  R5 core configuration (split is 0 or lock-step and 1)
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-region:
+description:
+  collection of memory carveouts used for elf-loading and inter-processor
+  communication.
+maxItems: 4
+minItems: 4
+  pnode-id:
+maxItems: 1
+  mboxes:
+maxItems: 2
+  mbox-names:
+maxItems: 2
+
+examples:
+  - |
+ reserved-memory {
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  elf_load: rproc@3ed00 {
+   no-map;
+   reg = <0x3ed0 0x4>;
+  };
+ };
+ rpu {
+  compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  lockstep-mode = <0>;
+  r5_0 {
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   memory-region = <_load>;
+   pnode-id = <0x7>;
+  };
+ };
+
+ /*
+  * Below nodes are required if using TCM to load R5 firmware
+  * if not, then either do not provide nodes are label as disabled in
+  * status property
+  */
+ tcm_0a@0 {
+ reg = <0x0 0xffe0 0x0 0x1>;
+ pnode-id = <0xf>;
+ no-map;
+ status = "okay";
+ };
+ tcm_1a@0 {
+ reg = <0x0 0xffe2 0x0 0x1>;
+ pnode-id = <0x10>;
+ no-map;
+ status = "okay";
+ };
+
+ /*
+  * Below nodes are required for IPC, as Xilinx Kernel
+  * can potentially have other applications that use CMA
+  * and conflict from hardware design. With that in mind,
+  * explicitly state the address spaces for the IPC remoteproc
+  * mechanisms.
+  *
+  * If IPC not required and only elf-loading then these are not needed.
+  */
+ rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
+ no-map;
+ reg = <0x0 0x3ed4 0x0 0x4000>;
+ };
+ rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
+ no-map;
+ reg = <0x0 0x3ed44000 0x0 0x4000>;
+ };
+ rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
+ no-map;
+ reg = <0x0 0x3ed48000 0x0 0x10>;
+ };
+
+...
-- 
2.17.1

Re: [PATCH] ext4: flag as supporting buffered async reads

[Jens Axboe]

On 8/25/20 8:18 AM, Jens Axboe wrote:
> On 8/24/20 4:56 AM, Jens Axboe wrote:
>> On 8/22/20 9:48 AM, Jens Axboe wrote:
>>> On 8/22/20 8:33 AM, Theodore Y. Ts'o wrote:
 On Fri, Aug 21, 2020 at 03:26:35PM -0600, Jens Axboe wrote:
 Resending this one, as I've been carrying it privately since May. The
 necessary bits are now upstream (and XFS/btrfs equiv changes as well),
 please consider this one for 5.9. Thanks!
>>>
>>> The necessary commit only hit upstream as of 5.9-rc1, unless I'm
>>> missing something?  It's on my queue to send to Linus once I get my
>>> (late) ext4 primary pull request for 5.9.
>>
>> Right, it went in at the start of the merge window for 5.9. Thanks Ted!
>
> Didn't see it in the queue that just sent in, is it still queued up?

 It wasn't in the queue which I queued up because that was based on
 5.8-rc4.  Linus was a bit grumpy (fairly so) because it was late, and
 that's totally on me.

 He has said that he's going to start ignoring pull requests that
 aren't fixes only if this becomes a pattern, so while I can send him
 another pull request which will just have that one change, there are
 no guarantees he's going to take it at this late date.

 Sorry, when you sent me the commit saying that the changes that were
 needed were already upstream on August 3rd, I thought that meant that
 they were aready in Linus's tree.  I should have checked and noticed
 that that in fact "ext4: flag as supporting buffered async reads"
 wasn't compiling against Linus's upstream tree, so I didn't realize
 this needed to be handled as a special case during the merge window.
>>>
>>> Well to be honest, this kind of sucks. I've been posting it since May,
>>> and the ideal approach would have been to just ack it and I could have
>>> carried it in my tree. That's what we did for btrfs and XFS, both of
>>> which have it.
>>>
>>> The required patches *were* upstreamed on August 3rd, which is why I
>>> mentioned that. But yes, not in 5.8 or earlier, of course.
>>>
>>> So I suggest that you either include it for the next pull request for
>>> Linus, or that I put it in with your ack. Either is fine with me. I'd
>>> consider this a "dropping the ball" kind of thing, it's not like the
>>> patch hasn't been in linux-next or hasn't been ready for months. This
>>> isn't some "oh I wrote this feature after the merge window" event. It'd
>>> be a real shame to ship 5.9 and ext4 not have support for the more
>>> efficient async buffered reads, imho, especially since the two other
>>> major local file systems already have it.
>>>
>>> Let me know what you think.
>>
>> Ted, can you make a call on this, please? It's now post -rc2. Let's
>> get this settled and included, one way or another.
> 
> Daily ping on this one...

And again. Ted, not sure how to make any progress with this, to be
honest, it's like pounding sand.

-- 
Jens Axboe

Re: [PATCH v2 1/2] Revert "drivers: qcom: rpmh-rsc: Use rcuidle tracepoints for rpmh"

[Bjorn Andersson]

On Tue 25 Aug 06:21 CDT 2020, Maulik Shah wrote:

> Commit efde2659b0fe ("drivers: qcom: rpmh-rsc: Use rcuidle tracepoints
> for rpmh") was written to fix a bug seen in an unmerged series that
> implemented a struct generic_pm_domain::power_off() callback calling
> rpmh_flush(). See stack trace below.
> 
>  Call trace:
>   dump_backtrace+0x0/0x174
>   show_stack+0x20/0x2c
>   dump_stack+0xc8/0x124
>   lockdep_rcu_suspicious+0xe4/0x104
>   __tcs_buffer_write+0x230/0x2d0
>   rpmh_rsc_write_ctrl_data+0x210/0x270
>   rpmh_flush+0x84/0x24c
>   rpmh_domain_power_off+0x78/0x98
>   _genpd_power_off+0x40/0xc0
>   genpd_power_off+0x168/0x208
> 
> Later the final merged solution is to use CPU PM notification to invoke
> rpmh_flush() and power_off() callback of genpd is not implemented in the
> driver.
> 
> CPU PM notifiers are run with RCU enabled/watching (see cpu_pm_notify()
> and how it calls rcu_irq_enter_irqson() before calling the notifiers).
> 
> Remove this change since RCU will not be idle during CPU PM notifications
> hence not required to use _rcuidle tracepoint. Using _rcuidle tracepoint
> prevented rpmh driver to be loadable module as these are not exported
> symbols.
> 
> This reverts commit efde2659b0fe835732047357b2902cca14f054d9.
> 
> Cc: Sai Prakash Ranjan 
> Cc: John Stultz 
> Cc: Stephen Rothwell 
> Reviewed-by: Stephen Boyd 
> Reviewed-by: Sai Prakash Ranjan 
> Reviewed-by: Ulf Hansson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Maulik Shah 
> ---
>  drivers/soc/qcom/rpmh-rsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
> index ae66757..fabe390d 100644
> --- a/drivers/soc/qcom/rpmh-rsc.c
> +++ b/drivers/soc/qcom/rpmh-rsc.c
> @@ -495,7 +495,7 @@ static void __tcs_buffer_write(struct rsc_drv *drv, int 
> tcs_id, int cmd_id,
>   write_tcs_cmd(drv, RSC_DRV_CMD_MSGID, tcs_id, j, msgid);
>   write_tcs_cmd(drv, RSC_DRV_CMD_ADDR, tcs_id, j, cmd->addr);
>   write_tcs_cmd(drv, RSC_DRV_CMD_DATA, tcs_id, j, cmd->data);
> - trace_rpmh_send_msg_rcuidle(drv, tcs_id, j, msgid, cmd);
> + trace_rpmh_send_msg(drv, tcs_id, j, msgid, cmd);
>   }
>  
>   write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, tcs_id, cmd_complete);
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH v2] HID: google: add google vivaldi HID driver

[Sean O'Brien]

> I actually believe we should follow the standard convention here, and have
> just one hid- driver for all google products. Currently we have
> hid-google-hammer, and this would add hid-google-vivaldi. Would you (or
> Wei-Ning, CCing here) object on merging these two together?

I'm a bit reluctant to merge them.  Partly because I'm not familiar with
the hid-google-hammer driver, but mostly because this driver is intended
to handle non-google products which will use a google-defined usage code.
Perhaps I should drop "google" from the driver name?

Thanks,
Sean O'Brien

[PATCH v2] arm64: dts: mt8173-elm: Set GPU power regulator to always on

[Anand K Mistry]

Keep the da9212 BUCKB always-on. This works around an issue on Elm/Hana
devices where sometimes, the regulator is disabled before scpsys is
suspended, causing the suspension of scpsys to fail.

Usually, the GPU and scpsys are suspended by the runtime PM before the
system is suspended, due to the GPU being idle. In this case, scpsys is
suspended inline with the GPU suspend, which then disables the
regulator. However, if the GPU is still active when system is suspended,
GPU suspend occurs but defers suspending scpsys to the PM's noirq phase.
Since GPU suspend disables the regulator, scpsys isn't powered and
suspending it fails with the following error:
[  523.773227] mtk-scpsys 10006000.scpsys: Failed to power off domain mfg_2d

On resume, scpsys is resumed in the noirq phase. Since scpsys requires
power from the regulator, which is still disabled at this point,
attempting to turn it on will hang the CPU. A HW watchdog eventually
reboots the system.

The obvious solution would be to add a link to the regulator from scpsys
in the devicetree. This would prevent the regulator from being disabled
until scpsys is suspended. However, in the case where suspending scpsys
is deferred to the noirq phase, disabling the regulator will fail since
it is connected over I2C which requires IRQs to be enabled. Even in the
usual case where scpsys is suspended inline with the GPU, PM will always
attempt to resume scpsys in noirq. This will attempt to enable the
regulator, which will also fail due to being unable to communicate over
I2C.

Since I2C can't be using with IRQs disabled, a workaround is to never
turn off the regulator.

Measuring power on the GPU rail on an Elm DVT device shows that the
change in power usage is negligible. The two relavent cases are S0 with
an idle GPU, and S3 (system suspended). Measurements taken using a debug
board every 100ms for 1 minute.

In S0 with an idle GPU, current behaviour with the regulator off:
@@   NAME  COUNT  AVERAGE  STDDEV  MAXMIN
@@ gpu_mw600 1.741.31 6.75   0.00
... and with the regulator on, but no load:
@@   NAME  COUNT  AVERAGE  STDDEV MAXMIN
@@ gpu_mw600 1.681.257.13   0.00
The difference being well within the margin of error.

In S3, current behaviour with the regulator off:
@@   NAME  COUNT  AVERAGE  STDDEV MAXMIN
@@ gpu_mw600 0.940.743.25   0.00
... and with the regulator on:
@@   NAME  COUNT  AVERAGE  STDDEV MAX MIN
@@ gpu_mw600 0.830.663.250.00

Signed-off-by: Anand K Mistry 

---

Changes in v2:
- Remove CHROMIUM from subject line
- Correct device in subject line (8183 -> 8173)
- Grammar/clarity changes in description

 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index a5a12b2599a4..1294f27b21c1 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -304,6 +304,7 @@ da9211_vgpu_reg: BUCKB {
regulator-min-microamp  = <200>;
regulator-max-microamp  = <300>;
regulator-ramp-delay = <1>;
+   regulator-always-on;
};
};
};
-- 
2.28.0.297.g1956fa8f8d-goog

[PATCH v2] Input: elants_i2c - Report resolution of ABS_MT_TOUCH_MAJOR by FW information.

[Johnny Chuang]

This patch adds a new behavior to report touch major resolution
based on information provided by firmware.

In initial process, driver acquires touch information from touch ic.
This information contains of one flag about reporting resolution of
ABS_MT_TOUCH_MAJOR is needed, or not.
Touch driver will report touch major resolution after geting this flag.

Signed-off-by: Johnny Chuang 
---
Changes in v2:
  - register real resolution instead of true/false.
---
 drivers/input/touchscreen/elants_i2c.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index b0bd5bb..dc7f4a5 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -151,6 +151,7 @@ struct elants_data {
 
bool wake_irq_enabled;
bool keep_power_in_suspend;
+   u8 report_major_resolution;
 
/* Must be last to be used for DMA operations */
u8 buf[MAX_PACKET_SIZE] cacheline_aligned;
@@ -459,6 +460,9 @@ static int elants_i2c_query_ts_info(struct elants_data *ts)
rows = resp[2] + resp[6] + resp[10];
cols = resp[3] + resp[7] + resp[11];
 
+   /* Decide if report resolution of ABS_MT_TOUCH_MAJOR */
+   ts->report_major_resolution = resp[16];
+
/* Process mm_to_pixel information */
error = elants_i2c_execute_command(client,
   get_osr_cmd, sizeof(get_osr_cmd),
@@ -1325,6 +1329,8 @@ static int elants_i2c_probe(struct i2c_client *client,
 0, MT_TOOL_PALM, 0, 0);
input_abs_set_res(ts->input, ABS_MT_POSITION_X, ts->x_res);
input_abs_set_res(ts->input, ABS_MT_POSITION_Y, ts->y_res);
+   if (ts->report_major_resolution > 0)
+   input_abs_set_res(ts->input, ABS_MT_TOUCH_MAJOR, 
ts->report_major_resolution);
 
touchscreen_parse_properties(ts->input, true, >prop);
 
-- 
2.7.4

Re: [PATCH] ASoC: fsl_spdif: Fix unnecessary check infsl_spdif_probe()

[Tang Bin]

Hi Mark

在 2020/8/27 0:53, Mark Brown 写道:

On Wed, Aug 26, 2020 at 11:09:18PM +0800, Tang Bin wrote:

The function fsl_spdif_probe() is only called with an openfirmware
platform device. Therefore there is no need to check that the passed
in device is NULL.

Why is this an issue - the check will make things more robust if someone
manages to load the driver on a non-DT system and otherwise costs us a
couple of instructions?

Thanks for your reply.

In this function,  function fsl_spdif_probe() can be triggered only if 
the platform_device and platform_driver matches,


so I think the judgement at the beginning is redundant.

Thanks

Tang Bin