RE: [EXT] Re: [PATCH v8 net-next 02/15] dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree

2021-02-06 Thread Stefan Chulski
> --
> On Sat, 6 Feb 2021 18:45:48 +0200 stef...@marvell.com wrote:
> > From: Konstantin Porotchkin 
> >
> > CM3 SRAM address space would be used for Flow Control configuration.
> >
> > Signed-off-by: Stefan Chulski 
> > Signed-off-by: Konstantin Porotchkin 
> 
> Isn't there are requirement to CC the DT mailing list and Rob on all device
> tree patches?  Maybe someone can clarify I know it's required when adding
> bindings..

I would repost with robh...@kernel.org, gregory.clem...@bootlin.com and 
devicet...@vger.kernel.org in CC

Thanks,
Stefan.


[PATCH v2] mtd: convert sysfs sprintf/snprintf family to sysfs_emit

2021-02-06 Thread Jiapeng Chong
Fix the following coccicheck warning:

convert sysfs snprintf family to sysfs_emit in 'mtdcore.c'.

Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong 
---
Changes in v2:
  - Adjust the description of the modified content.

 drivers/mtd/mtdcore.c | 35 +--
 1 file changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 2d6423d..c37056e 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -131,7 +131,7 @@ static ssize_t mtd_type_show(struct device *dev,
type = "unknown";
}
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", type);
+   return sysfs_emit(buf, "%s\n", type);
 }
 static DEVICE_ATTR(type, S_IRUGO, mtd_type_show, NULL);
 
@@ -140,7 +140,7 @@ static ssize_t mtd_flags_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "0x%lx\n", (unsigned long)mtd->flags);
+   return sysfs_emit(buf, "0x%lx\n", (unsigned long)mtd->flags);
 }
 static DEVICE_ATTR(flags, S_IRUGO, mtd_flags_show, NULL);
 
@@ -149,8 +149,7 @@ static ssize_t mtd_size_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%llu\n",
-   (unsigned long long)mtd->size);
+   return sysfs_emit(buf, "%llu\n", (unsigned long long)mtd->size);
 }
 static DEVICE_ATTR(size, S_IRUGO, mtd_size_show, NULL);
 
@@ -159,7 +158,7 @@ static ssize_t mtd_erasesize_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->erasesize);
+   return sysfs_emit(buf, "%lu\n", (unsigned long)mtd->erasesize);
 }
 static DEVICE_ATTR(erasesize, S_IRUGO, mtd_erasesize_show, NULL);
 
@@ -168,7 +167,7 @@ static ssize_t mtd_writesize_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->writesize);
+   return sysfs_emit(buf, "%lu\n", (unsigned long)mtd->writesize);
 }
 static DEVICE_ATTR(writesize, S_IRUGO, mtd_writesize_show, NULL);
 
@@ -178,7 +177,7 @@ static ssize_t mtd_subpagesize_show(struct device *dev,
struct mtd_info *mtd = dev_get_drvdata(dev);
unsigned int subpagesize = mtd->writesize >> mtd->subpage_sft;
 
-   return snprintf(buf, PAGE_SIZE, "%u\n", subpagesize);
+   return sysfs_emit(buf, "%u\n", subpagesize);
 }
 static DEVICE_ATTR(subpagesize, S_IRUGO, mtd_subpagesize_show, NULL);
 
@@ -187,7 +186,7 @@ static ssize_t mtd_oobsize_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->oobsize);
+   return sysfs_emit(buf, "%lu\n", (unsigned long)mtd->oobsize);
 }
 static DEVICE_ATTR(oobsize, S_IRUGO, mtd_oobsize_show, NULL);
 
@@ -196,7 +195,7 @@ static ssize_t mtd_oobavail_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%u\n", mtd->oobavail);
+   return sysfs_emit(buf, "%u\n", mtd->oobavail);
 }
 static DEVICE_ATTR(oobavail, S_IRUGO, mtd_oobavail_show, NULL);
 
@@ -205,7 +204,7 @@ static ssize_t mtd_numeraseregions_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%u\n", mtd->numeraseregions);
+   return sysfs_emit(buf, "%u\n", mtd->numeraseregions);
 }
 static DEVICE_ATTR(numeraseregions, S_IRUGO, mtd_numeraseregions_show,
NULL);
@@ -215,7 +214,7 @@ static ssize_t mtd_name_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%s\n", mtd->name);
+   return sysfs_emit(buf, "%s\n", mtd->name);
 }
 static DEVICE_ATTR(name, S_IRUGO, mtd_name_show, NULL);
 
@@ -224,7 +223,7 @@ static ssize_t mtd_ecc_strength_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%u\n", mtd->ecc_strength);
+   return sysfs_emit(buf, "%u\n", mtd->ecc_strength);
 }
 static DEVICE_ATTR(ecc_strength, S_IRUGO, mtd_ecc_strength_show, NULL);
 
@@ -234,7 +233,7 @@ static ssize_t mtd_bitflip_threshold_show(struct device 
*dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%u\n", mtd->bitflip_threshold);
+   return sysfs_emit(buf, "%u\n", mtd->bitflip_threshold);
 }
 
 static ssize_t mtd_bitflip_threshold_store(struct device *dev,
@@ -261,7 +260,7 @@ static ssize_t mtd_ecc_step_size_show(struct device *dev,
 {
struct mtd_info *mtd = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%u\n", mtd->ecc_step_size);
+   return sysfs_emit(buf, "%u\n", mtd->ecc_step_size);
 
 }
 static DEVICE_ATTR(ecc_step_size, S_IRUGO, mtd_ecc_step_size_show, NULL);
@@ -272,7 +271,7 @@ static ssize_t 

[PATCH] bpf/benchs/bench_ringbufs: remove unneeded semicolon

2021-02-06 Thread Yang Li
Eliminate the following coccicheck warning:
./tools/testing/selftests/bpf/benchs/bench_ringbufs.c:322:2-3: Unneeded
semicolon

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 tools/testing/selftests/bpf/benchs/bench_ringbufs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/benchs/bench_ringbufs.c 
b/tools/testing/selftests/bpf/benchs/bench_ringbufs.c
index da87c7f..bde6c9d 100644
--- a/tools/testing/selftests/bpf/benchs/bench_ringbufs.c
+++ b/tools/testing/selftests/bpf/benchs/bench_ringbufs.c
@@ -319,7 +319,7 @@ static void ringbuf_custom_process_ring(struct 
ringbuf_custom *r)
smp_store_release(r->consumer_pos, cons_pos);
else
break;
-   };
+   }
 }
 
 static void *ringbuf_custom_consumer(void *input)
-- 
1.8.3.1



Re: [PATCH] jfs: turn diLog(), dataLog() and txLog() into void functions

2021-02-06 Thread kernel test robot
Hi Yang,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on shaggy/jfs-next]
[also build test WARNING on v5.11-rc6 next-20210125]
[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/Yang-Li/jfs-turn-diLog-dataLog-and-txLog-into-void-functions/20210207-143938
base:   https://github.com/kleikamp/linux-shaggy jfs-next
config: i386-randconfig-m021-20210207 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/8b7ab4ba41269109e7cb95106023e96d640842e9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Yang-Li/jfs-turn-diLog-dataLog-and-txLog-into-void-functions/20210207-143938
git checkout 8b7ab4ba41269109e7cb95106023e96d640842e9
# 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 >>):

   fs/jfs/jfs_txnmgr.c:1368:13: error: conflicting types for 'txLog'
1368 | static void txLog(struct jfs_log *log, struct tblock *tblk, struct 
commit *cd)
 | ^
   fs/jfs/jfs_txnmgr.c:162:12: note: previous declaration of 'txLog' was here
 162 | static int txLog(struct jfs_log * log, struct tblock * tblk,
 |^
   fs/jfs/jfs_txnmgr.c:1424:13: error: conflicting types for 'diLog'
1424 | static void diLog(struct jfs_log *log, struct tblock *tblk, struct 
lrd *lrd,
 | ^
   fs/jfs/jfs_txnmgr.c:151:12: note: previous declaration of 'diLog' was here
 151 | static int diLog(struct jfs_log * log, struct tblock * tblk, struct 
lrd * lrd,
 |^
   fs/jfs/jfs_txnmgr.c:1536:13: error: conflicting types for 'dataLog'
1536 | static void dataLog(struct jfs_log *log, struct tblock *tblk, struct 
lrd *lrd,
 | ^~~
   fs/jfs/jfs_txnmgr.c:153:12: note: previous declaration of 'dataLog' was here
 153 | static int dataLog(struct jfs_log * log, struct tblock * tblk, 
struct lrd * lrd,
 |^~~
>> fs/jfs/jfs_txnmgr.c:151:12: warning: 'diLog' used but never defined
 151 | static int diLog(struct jfs_log * log, struct tblock * tblk, struct 
lrd * lrd,
 |^
>> fs/jfs/jfs_txnmgr.c:153:12: warning: 'dataLog' used but never defined
 153 | static int dataLog(struct jfs_log * log, struct tblock * tblk, 
struct lrd * lrd,
 |^~~
>> fs/jfs/jfs_txnmgr.c:162:12: warning: 'txLog' used but never defined
 162 | static int txLog(struct jfs_log * log, struct tblock * tblk,
 |^
   fs/jfs/jfs_txnmgr.c:1536:13: warning: 'dataLog' defined but not used 
[-Wunused-function]
1536 | static void dataLog(struct jfs_log *log, struct tblock *tblk, struct 
lrd *lrd,
 | ^~~
   fs/jfs/jfs_txnmgr.c:1424:13: warning: 'diLog' defined but not used 
[-Wunused-function]
1424 | static void diLog(struct jfs_log *log, struct tblock *tblk, struct 
lrd *lrd,
 | ^
   fs/jfs/jfs_txnmgr.c:1368:13: warning: 'txLog' defined but not used 
[-Wunused-function]
1368 | static void txLog(struct jfs_log *log, struct tblock *tblk, struct 
commit *cd)
 | ^


vim +/diLog +151 fs/jfs/jfs_txnmgr.c

^1da177e4c3f41 Linus Torvalds 2005-04-16  147  
^1da177e4c3f41 Linus Torvalds 2005-04-16  148  /*
^1da177e4c3f41 Linus Torvalds 2005-04-16  149   * forward references
^1da177e4c3f41 Linus Torvalds 2005-04-16  150   */
^1da177e4c3f41 Linus Torvalds 2005-04-16 @151  static int diLog(struct jfs_log 
* log, struct tblock * tblk, struct lrd * lrd,
^1da177e4c3f41 Linus Torvalds 2005-04-16  152   struct tlock * tlck, 
struct commit * cd);
^1da177e4c3f41 Linus Torvalds 2005-04-16 @153  static int dataLog(struct 
jfs_log * log, struct tblock * tblk, struct lrd * lrd,
^1da177e4c3f41 Linus Torvalds 2005-04-16  154   struct tlock * tlck);
^1da177e4c3f41 Linus Torvalds 2005-04-16  155  static void dtLog(struct jfs_log 
* log, struct tblock * tblk, struct lrd * lrd,
^1da177e4c3f41 Linus Torvalds 2005-04-16  156   struct tlock * tlck);
^1da177e4c3f41 Linus Torvalds 2005-04-16  157  static void mapLog(struct 
jfs_log * log, struct tblock * tblk, struct lrd * lrd,
^1da177e4c3f41 Linus Torvalds 2005-04-16  158   struct tlock * tlck);
^1da177e4c3f41 Linus Torvalds 2005-04-16  159  static void txAllocPMap(struct 
inode *ip, struct maplock * maplock,
^1da177e4c3f41 Linus Torvalds 2005-04-16  160   struct tblock * tblk);
^1da177e4c3f41 Linus Torvalds 2005-04-16  161  static void txForce(struct 
tblock * tblk);
^1da177e4c3f41 Linus Torvalds 

[PATCH] selftests/x86/ldt_gdt: remove unneeded semicolon

2021-02-06 Thread Yang Li
Eliminate the following coccicheck warning:
./tools/testing/selftests/x86/ldt_gdt.c:610:2-3: Unneeded semicolon

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 tools/testing/selftests/x86/ldt_gdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/ldt_gdt.c 
b/tools/testing/selftests/x86/ldt_gdt.c
index 1aef72d..3a29346 100644
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -607,7 +607,7 @@ static void do_multicpu_tests(void)
 
failures++;
asm volatile ("mov %0, %%ss" : : "rm" (orig_ss));
-   };
+   }
 
ftx = 100;  /* Kill the thread. */
syscall(SYS_futex, , FUTEX_WAKE, 0, NULL, NULL, 0);
-- 
1.8.3.1



WARNING in go7007_usb_onboard_write_interrupt/usb_submit_urb

2021-02-06 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:64eaa0fa platform/chrome: cros_ec_typec: Fix call to typec..
git tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=12d5c090d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=29ec25b819cb42f3
dashboard link: https://syzkaller.appspot.com/bug?extid=d4ebc877b1223f20d5a0
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=16b47dd8d0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=164896c4d0

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

usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: SerialNumber: syz
usb 1-1: config 0 descriptor??
[ cut here ]
usb 1-1: BOGUS urb xfer, pipe 2 != type 3
WARNING: CPU: 0 PID: 2608 at drivers/usb/core/urb.c:493 
usb_submit_urb+0xd27/0x1540 drivers/usb/core/urb.c:493
Modules linked in:
CPU: 0 PID: 2608 Comm: kworker/0:2 Not tainted 5.11.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xd27/0x1540 drivers/usb/core/urb.c:493
Code: 84 d4 02 00 00 e8 e9 e9 ba fd 4c 89 ef e8 f1 3d 1d ff 41 89 d8 44 89 e1 
4c 89 f2 48 89 c6 48 c7 c7 00 6a 61 86 e8 31 ee f9 01 <0f> 0b e9 81 f8 ff ff e8 
bd e9 ba fd 48 81 c5 30 06 00 00 e9 ad f7
RSP: 0018:c90006cf6c70 EFLAGS: 00010286
RAX:  RBX: 0003 RCX: 
RDX: 88810a895040 RSI: 81299db3 RDI: f52000d9ed80
RBP: 88810155f8a0 R08: 0001 R09: 
R10: 8149c4ab R11:  R12: 0002
R13: 8881121670a0 R14: 8881031c06e0 R15: 888102b46f00
FS:  () GS:8881f680() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 55bfb7b520d0 CR3: 00010a1f1000 CR4: 001506f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58
 usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
 usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
 go7007_usb_onboard_write_interrupt+0x26a/0x340 
drivers/media/usb/go7007/go7007-usb.c:735
 go7007_usb_interface_reset+0x139/0x540 
drivers/media/usb/go7007/go7007-usb.c:649
 go7007_load_encoder+0x11f/0x510 drivers/media/usb/go7007/go7007-driver.c:107
 go7007_boot_encoder+0x2a/0xe0 drivers/media/usb/go7007/go7007-driver.c:131
 go7007_usb_probe+0x80e/0x21f0 drivers/media/usb/go7007/go7007-usb.c:1161
 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
 really_probe+0x291/0xe60 drivers/base/dd.c:554
 driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:740
 __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:846
 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
 __device_attach+0x228/0x4a0 drivers/base/dd.c:914
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
 device_add+0xbc4/0x1d90 drivers/base/core.c:3109
 usb_set_configuration+0x113c/0x1910 drivers/usb/core/message.c:2164
 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
 really_probe+0x291/0xe60 drivers/base/dd.c:554
 driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:740
 __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:846
 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
 __device_attach+0x228/0x4a0 drivers/base/dd.c:914
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
 device_add+0xbc4/0x1d90 drivers/base/core.c:3109
 usb_new_device.cold+0x721/0x1058 drivers/usb/core/hub.c:2555
 hub_port_connect drivers/usb/core/hub.c:5223 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
 port_event drivers/usb/core/hub.c:5509 [inline]
 hub_event+0x2357/0x4320 drivers/usb/core/hub.c:5591
 process_one_work+0x98d/0x1580 kernel/workqueue.c:2275
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
 kthread+0x38c/0x460 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296


---
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:
https://goo.gl/tpsmEJ#testing-patches


Re: [PATCH] staging: emxx_udc: Fix incorrectly defined global

2021-02-06 Thread Kumar Kartikeya Dwivedi
On Sun, Feb 07, 2021 at 12:04:41PM IST, Stephen Rothwell wrote:
> 
> Given that drivers/staging/emxx_udc/emxx_udc.h is only included by
> drivers/staging/emxx_udc/emxx_udc.c, shouldn't these variables just be
> declared static in emxx_udc.c and removed from emxx_udc.h?
>

Either would be correct. I went this way because it was originally trying to
(incorrectly) define a global variable instead. I guess they can be static now
and when more users are added, the linkage can be adjusted as needed.

Here's another version of the patch:

--
>From 5835ad916ceeba620c85bc32f52ecd69f21f8dab Mon Sep 17 00:00:00 2001
From: Kumar Kartikeya Dwivedi 
Date: Sun, 7 Feb 2021 12:53:39 +0530
Subject: [PATCH] staging: emxx_udc: Make incorrectly defined global static

The global gpio_desc pointer and int vbus_irq were defined in the header,
instead put the definitions in the translation unit and make them static as
there's only a single consumer in emxx_udc.c.

This fixes the following sparse warnings for this driver:
drivers/staging/emxx_udc/emxx_udc.c: note: in included file:
drivers/staging/emxx_udc/emxx_udc.h:23:18: warning: symbol 'vbus_gpio' was not
declared. Should it be static?
drivers/staging/emxx_udc/emxx_udc.h:24:5: warning: symbol 'vbus_irq' was not 
declared. Should it be static?

Signed-off-by: Kumar Kartikeya Dwivedi 
---
 drivers/staging/emxx_udc/emxx_udc.c | 3 +++
 drivers/staging/emxx_udc/emxx_udc.h | 2 --
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index a30b4f5b1..3536c03ff 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -34,6 +34,9 @@
 #defineDRIVER_DESC "EMXX UDC driver"
 #defineDMA_ADDR_INVALID(~(dma_addr_t)0)
 
+static struct gpio_desc *vbus_gpio;
+static int vbus_irq;
+
 static const char  driver_name[] = "emxx_udc";
 static const char  driver_desc[] = DRIVER_DESC;
 
diff --git a/drivers/staging/emxx_udc/emxx_udc.h 
b/drivers/staging/emxx_udc/emxx_udc.h
index bca614d69..c9e37a1b8 100644
--- a/drivers/staging/emxx_udc/emxx_udc.h
+++ b/drivers/staging/emxx_udc/emxx_udc.h
@@ -20,8 +20,6 @@
 /* below hacked up for staging integration */
 #define GPIO_VBUS 0 /* GPIO_P153 on KZM9D */
 #define INT_VBUS 0 /* IRQ for GPIO_P153 */
-struct gpio_desc *vbus_gpio;
-int vbus_irq;
 
 /* Board dependence(Wait) */
 
-- 
2.29.2

-- 
Kartikeya


Re: [PATCH v19 3/3] scsi: ufs: Prepare HPB read for cached sub-region

2021-02-06 Thread Can Guo

On 2021-02-05 23:08, Bean Huo wrote:

On Fri, 2021-02-05 at 14:06 +, Avri Altman wrote:

> > > + put_unaligned_be64(ppn, [6]);
> >
> > You are assuming the HPB entries read out by "HPB Read Buffer"
> > cmd
> > are
> > in Little
> > Endian, which is why you are using put_unaligned_be64 here.
> > However,
> > this assumption
> > is not right for all the other flash vendors - HPB entries read
> > out
> > by
> > "HPB Read Buffer"
> > cmd may come in Big Endian, if so, their random read performance
> > are
> > screwed.
>
> For this question, it is very hard to make a correct format since
> the
> Spec doesn't give a clear definition. Should we have a default
> format,
> if there is conflict, and then add quirk or add a vendor-specific
> table?
>
> Hi Avri
> Do you have a good idea?

I don't know.  Better let Daejun answer this.
This was working for me for both Galaxy S20 (Exynos) as well as
Xiaomi Mi10 (8250).



Thanks, I tested Daejun's patchset before, it is also ok (I don't know
which version patchset). maybe we can keep current implementation as
default, then if there is conflict, and submit the quirk.



Yeah, you've tested it, are you sure that Micron's UFS devices are OK
with this specific code line?

Micron UFS FW team has confirmed that Micron's HPB entries read out by
"HPB Buffer Read" cmd are in big-endian byte ordering.

If Micron FW team is right, I am pretty sure that you would have seen
random read performance regression on Micron UFS devices caused by
invalid HPB entry format in HPB Read cmd UPIU (which leads to L2P cache
miss in device side all the time) during your test.

Can Guo.


Thanks,
Bean


Thanks,
Avri


Re: [PATCH v2 2/2] perf script: Support filtering by hex address

2021-02-06 Thread Jin, Yao

Hi Jiri,

On 2/5/2021 5:49 PM, Jiri Olsa wrote:

On Fri, Jan 29, 2021 at 03:08:54PM +0800, Jin Yao wrote:

SNIP


+   }
+   }
+
if (!ret)
al->filtered |= (1 << HIST_FILTER__SYMBOL);
}
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 64a039cbba1b..2c13f6acda7f 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2406,6 +2406,39 @@ int setup_intlist(struct intlist **list, const char 
*list_str,
return 0;
  }
  
+static int setup_addrlist(struct intlist **addr_list, struct strlist *sym_list)

+{
+   struct str_node *pos, *tmp;
+   unsigned long val;
+   char *sep;
+   int err = 0, i = 0;
+
+   *addr_list = intlist__new(NULL);
+   if (!*addr_list)
+   return -1;
+
+   strlist__for_each_entry_safe(pos, tmp, sym_list) {
+   val = strtoul(pos->s, , 16);
+   if (*sep != ',' && *sep != '\0')
+   continue;


I think you also need to check that val is valid and errno
(check other strtoul we call in perf)
because above could pass for:

$ ./perf script -S ",7fd0f1b69a13"
ls 651468 410180.795577:  90098 cycles:u:  7fd0f1b69a13 
__GI___tunables_init+0x73 (/usr/lib64/ld-2.32.so)




Now I think this may be OK because that's not the pattern matching. It just matches the 7fd0f1b69a13 
in address list.


And we also need to support the address + symbol combination, such as,

$ ./perf script -S "9a51de2a,put_cmsg"
 swapper 0 [007] 347304.359521:  44937   cycles:  9a51de2a rcu_core+0x29a 
([kernel.kallsyms])
avahi-daemon   580 [007] 347304.468122:  57176   cycles:  9af4764e put_cmsg+0xde 
([kernel.kallsyms])


So the idea is when we can get a valid address from -S list, we add the address to intlist for 
address comparison otherwise we still leave it to symbol list for symbol comparison.


Anyway, I will post v3 patch for review.

Thanks
Jin Yao


plus check for " " so we could do:

$ ./perf script -S "7fd0f1b69a13 ,7fd0f1b5e189"
ls 651468 410180.796055: 190731 cycles:u:  7fd0f1b5e189 
_dl_relocate_object+0x4b9 (/usr/lib64/ld-2.32.so)

$ ./perf script -S "7fd0f1b69a13,7fd0f1b5e189"
ls 651468 410180.795577:  90098 cycles:u:  7fd0f1b69a13 
__GI___tunables_init+0x73 (/usr/lib64/ld-2.32.so)
ls 651468 410180.796055: 190731 cycles:u:  7fd0f1b5e189 
_dl_relocate_object+0x4b9 (/usr/lib64/ld-2.32.so)


thanks,
jirka



[PATCH v2] MIPS: crash_dump.c: Simplify copy_oldmem_page()

2021-02-06 Thread Youling Tang
Replace kmap_atomic_pfn() with kmap_local_pfn() which is preemptible and
can take page faults.

Remove the indirection of the dump page and the related cruft which is not
longer required.

Remove unused or redundant header files.

Reported-by: kernel test robot 
Signed-off-by: Youling Tang 
---

v2:
 - Keep the crash_dump.h header file included to avoid the
   "no previous prototype for function" warning.

 arch/mips/kernel/crash_dump.c | 41 ++---
 1 file changed, 6 insertions(+), 35 deletions(-)

diff --git a/arch/mips/kernel/crash_dump.c b/arch/mips/kernel/crash_dump.c
index 01b2bd9..2e50f551 100644
--- a/arch/mips/kernel/crash_dump.c
+++ b/arch/mips/kernel/crash_dump.c
@@ -1,11 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
-#include 
 #include 
-#include 
-#include 
-
-static void *kdump_buf_page;
 
 /**
  * copy_oldmem_page - copy one page from "oldmem"
@@ -19,10 +14,6 @@ static void *kdump_buf_page;
  *
  * Copy a page from "oldmem". For this page, there is no pte mapped
  * in the current kernel.
- *
- * Calling copy_to_user() in atomic context is not desirable. Hence first
- * copying the data to a pre-allocated kernel page and then copying to user
- * space in non-atomic context.
  */
 ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
 size_t csize, unsigned long offset, int userbuf)
@@ -32,36 +23,16 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
if (!csize)
return 0;
 
-   vaddr = kmap_atomic_pfn(pfn);
+   vaddr = kmap_local_pfn(pfn);
 
if (!userbuf) {
-   memcpy(buf, (vaddr + offset), csize);
-   kunmap_atomic(vaddr);
+   memcpy(buf, vaddr + offset, csize);
} else {
-   if (!kdump_buf_page) {
-   pr_warn("Kdump: Kdump buffer page not allocated\n");
-
-   return -EFAULT;
-   }
-   copy_page(kdump_buf_page, vaddr);
-   kunmap_atomic(vaddr);
-   if (copy_to_user(buf, (kdump_buf_page + offset), csize))
-   return -EFAULT;
+   if (copy_to_user(buf, vaddr + offset, csize))
+   csize = -EFAULT;
}
 
-   return csize;
-}
-
-static int __init kdump_buf_page_init(void)
-{
-   int ret = 0;
+   kunmap_local(vaddr);
 
-   kdump_buf_page = kmalloc(PAGE_SIZE, GFP_KERNEL);
-   if (!kdump_buf_page) {
-   pr_warn("Kdump: Failed to allocate kdump buffer page\n");
-   ret = -ENOMEM;
-   }
-
-   return ret;
+   return csize;
 }
-arch_initcall(kdump_buf_page_init);
-- 
2.1.0



[PATCH] psi: Add PSI_CPU_FULL state

2021-02-06 Thread Chengming Zhou
The FULL state doesn't exist for the CPU resource at the system level,
but exist at the cgroup level, means all non-idle tasks in a cgroup are
delayed on the CPU resource which used by others outside of the cgroup.

Co-developed-by: Muchun Song 
Signed-off-by: Muchun Song 
Signed-off-by: Chengming Zhou 
---
 include/linux/psi_types.h |  3 ++-
 kernel/sched/psi.c| 14 +++---
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/include/linux/psi_types.h b/include/linux/psi_types.h
index b95f3211566a..0a23300d49af 100644
--- a/include/linux/psi_types.h
+++ b/include/linux/psi_types.h
@@ -50,9 +50,10 @@ enum psi_states {
PSI_MEM_SOME,
PSI_MEM_FULL,
PSI_CPU_SOME,
+   PSI_CPU_FULL,
/* Only per-CPU, to weigh the CPU in the global average: */
PSI_NONIDLE,
-   NR_PSI_STATES = 6,
+   NR_PSI_STATES = 7,
 };
 
 enum psi_aggregators {
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 39d758a15a57..c572ad529d87 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -34,7 +34,10 @@
  * delayed on that resource such that nobody is advancing and the CPU
  * goes idle. This leaves both workload and CPU unproductive.
  *
- * (Naturally, the FULL state doesn't exist for the CPU resource.)
+ * Naturally, the FULL state doesn't exist for the CPU resource at the
+ * system level, but exist at the cgroup level, means all non-idle tasks
+ * in a cgroup are delayed on the CPU resource which used by others outside
+ * of the cgroup.
  *
  * SOME = nr_delayed_tasks != 0
  * FULL = nr_delayed_tasks != 0 && nr_running_tasks == 0
@@ -225,6 +228,8 @@ static bool test_state(unsigned int *tasks, enum psi_states 
state)
return tasks[NR_MEMSTALL] && !tasks[NR_RUNNING];
case PSI_CPU_SOME:
return tasks[NR_RUNNING] > tasks[NR_ONCPU];
+   case PSI_CPU_FULL:
+   return tasks[NR_RUNNING] && !tasks[NR_ONCPU];
case PSI_NONIDLE:
return tasks[NR_IOWAIT] || tasks[NR_MEMSTALL] ||
tasks[NR_RUNNING];
@@ -678,8 +683,11 @@ static void record_times(struct psi_group_cpu *groupc, int 
cpu,
}
}
 
-   if (groupc->state_mask & (1 << PSI_CPU_SOME))
+   if (groupc->state_mask & (1 << PSI_CPU_SOME)) {
groupc->times[PSI_CPU_SOME] += delta;
+   if (groupc->state_mask & (1 << PSI_CPU_FULL))
+   groupc->times[PSI_CPU_FULL] += delta;
+   }
 
if (groupc->state_mask & (1 << PSI_NONIDLE))
groupc->times[PSI_NONIDLE] += delta;
@@ -1018,7 +1026,7 @@ int psi_show(struct seq_file *m, struct psi_group *group, 
enum psi_res res)
group->avg_next_update = update_averages(group, now);
mutex_unlock(>avgs_lock);
 
-   for (full = 0; full < 2 - (res == PSI_CPU); full++) {
+   for (full = 0; full < 2; full++) {
unsigned long avg[3];
u64 total;
int w;
-- 
2.11.0



memory leak in __ieee80211_beacon_get

2021-02-06 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10f79330d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=b7edd79f26f7c0c3
dashboard link: https://syzkaller.appspot.com/bug?extid=e832ab33619901afc64a
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=13e46a40d0

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

BUG: memory leak
unreferenced object 0x88811682b500 (size 232):
  comm "softirq", pid 0, jiffies 4295119192 (age 15.070s)
  hex dump (first 32 bytes):
10 c5 79 16 81 88 ff ff 10 c5 79 16 81 88 ff ff  ..y...y.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[<92ce1185>] __alloc_skb+0x6d/0x280 net/core/skbuff.c:198
[<27006abe>] __netdev_alloc_skb+0x6a/0x210 net/core/skbuff.c:446
[] netdev_alloc_skb include/linux/skbuff.h:2832 [inline]
[] dev_alloc_skb include/linux/skbuff.h:2845 [inline]
[] __ieee80211_beacon_get+0x662/0x7a0 
net/mac80211/tx.c:4814
[] ieee80211_beacon_get_tim+0x47/0x1c0 
net/mac80211/tx.c:4928
[<42c1663d>] ieee80211_beacon_get include/net/mac80211.h:4918 
[inline]
[<42c1663d>] mac80211_hwsim_beacon_tx+0xa1/0x2c0 
drivers/net/wireless/mac80211_hwsim.c:1729
[<681dd69b>] __iterate_interfaces+0x125/0x260 
net/mac80211/util.c:793
[<025fd347>] ieee80211_iterate_active_interfaces_atomic+0x2e/0x40 
net/mac80211/util.c:829
[] mac80211_hwsim_beacon+0x52/0xb0 
drivers/net/wireless/mac80211_hwsim.c:1782
[<18e3b983>] __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
[<18e3b983>] __hrtimer_run_queues+0x1ba/0x470 
kernel/time/hrtimer.c:1583
[] hrtimer_run_softirq+0x7e/0x100 
kernel/time/hrtimer.c:1600
[<3b2a8015>] __do_softirq+0xbf/0x2ab kernel/softirq.c:343
[] asm_call_irq_on_stack+0xf/0x20
[] __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 
[inline]
[] run_on_irqstack_cond 
arch/x86/include/asm/irq_stack.h:77 [inline]
[] do_softirq_own_stack+0x32/0x40 
arch/x86/kernel/irq_64.c:77
[<75748e36>] invoke_softirq kernel/softirq.c:226 [inline]
[<75748e36>] __irq_exit_rcu kernel/softirq.c:420 [inline]
[<75748e36>] irq_exit_rcu+0x93/0xc0 kernel/softirq.c:432
[<6645e04e>] sysvec_apic_timer_interrupt+0x36/0x80 
arch/x86/kernel/apic/apic.c:1096
[] asm_sysvec_apic_timer_interrupt+0x12/0x20 
arch/x86/include/asm/idtentry.h:629

BUG: memory leak
unreferenced object 0x88811682db00 (size 232):
  comm "softirq", pid 0, jiffies 4295119192 (age 15.070s)
  hex dump (first 32 bytes):
10 c5 6b 16 81 88 ff ff 10 c5 6b 16 81 88 ff ff  ..k...k.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[<92ce1185>] __alloc_skb+0x6d/0x280 net/core/skbuff.c:198
[<27006abe>] __netdev_alloc_skb+0x6a/0x210 net/core/skbuff.c:446
[] netdev_alloc_skb include/linux/skbuff.h:2832 [inline]
[] dev_alloc_skb include/linux/skbuff.h:2845 [inline]
[] __ieee80211_beacon_get+0x662/0x7a0 
net/mac80211/tx.c:4814
[] ieee80211_beacon_get_tim+0x47/0x1c0 
net/mac80211/tx.c:4928
[<42c1663d>] ieee80211_beacon_get include/net/mac80211.h:4918 
[inline]
[<42c1663d>] mac80211_hwsim_beacon_tx+0xa1/0x2c0 
drivers/net/wireless/mac80211_hwsim.c:1729
[<681dd69b>] __iterate_interfaces+0x125/0x260 
net/mac80211/util.c:793
[<025fd347>] ieee80211_iterate_active_interfaces_atomic+0x2e/0x40 
net/mac80211/util.c:829
[] mac80211_hwsim_beacon+0x52/0xb0 
drivers/net/wireless/mac80211_hwsim.c:1782
[<18e3b983>] __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
[<18e3b983>] __hrtimer_run_queues+0x1ba/0x470 
kernel/time/hrtimer.c:1583
[] hrtimer_run_softirq+0x7e/0x100 
kernel/time/hrtimer.c:1600
[<3b2a8015>] __do_softirq+0xbf/0x2ab kernel/softirq.c:343
[] asm_call_irq_on_stack+0xf/0x20
[] __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 
[inline]
[] run_on_irqstack_cond 
arch/x86/include/asm/irq_stack.h:77 [inline]
[] do_softirq_own_stack+0x32/0x40 
arch/x86/kernel/irq_64.c:77
[<75748e36>] invoke_softirq kernel/softirq.c:226 [inline]
[<75748e36>] __irq_exit_rcu kernel/softirq.c:420 [inline]
[<75748e36>] irq_exit_rcu+0x93/0xc0 kernel/softirq.c:432
 

[PATCH] m68k: Drop -fno-strength-reduce from KBUILD_CFLAGS

2021-02-06 Thread Finn Thain
This workaround became redundant either when the driver in question was
removed (in Linux v2.6.23) or when the compiler flag became a no-op
(in GCC v4.2). Linux has required GCC v4.6 or later since v4.19.

Link: 
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=efa1cdf01850b28c2f6f7035ebd4420259494615
References: commit 565bae6a4a8f ("[SCSI] 53c7xx: kill driver")
References: commit cafa0010cd51 ("Raise the minimum required gcc version to 
4.6")
Signed-off-by: Finn Thain 
---
 arch/m68k/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index ea14f2046fb4..5be4efec173a 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -66,8 +66,7 @@ KBUILD_CFLAGS += $(cpuflags-y)
 KBUILD_CFLAGS += -pipe -ffreestanding
 
 ifdef CONFIG_MMU
-# without -fno-strength-reduce the 53c7xx.c driver fails ;-(
-KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2
+KBUILD_CFLAGS += -ffixed-a2
 else
 # we can use a m68k-linux-gcc toolchain with these in place
 KBUILD_CPPFLAGS += -DUTS_SYSNAME=\"uClinux\"
-- 
2.26.2



[PATCH] ALSA: pci: Assign boolean values to a bool variable

2021-02-06 Thread Jiapeng Chong
Fix the following coccicheck warnings:

./sound/pci/azt3328.c:2451:2-16: WARNING: Assignment of 0/1 to bool
variable.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 sound/pci/azt3328.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/azt3328.c b/sound/pci/azt3328.c
index 77c7030..37f8fc4 100644
--- a/sound/pci/azt3328.c
+++ b/sound/pci/azt3328.c
@@ -2448,7 +2448,7 @@ static void snd_azf3328_mixer_reg_decode(struct 
azf3328_mixer_reg *r, unsigned l
 
/* shutdown codecs to reduce power / noise */
/* have ...ctrl_codec_activity() act properly */
-   codec->running = 1;
+   codec->running = true;
snd_azf3328_ctrl_codec_activity(chip, codec_type, 0);
 
spin_lock_irq(codec->lock);
-- 
1.8.3.1



[PATCH v2 1/3] iio: Add relative sensitivity support

2021-02-06 Thread Ye Xiang
Some hid sensors may use relative sensitivity such as als sensor.
This patch adds relative sensitivity checking for all hid sensors.

Signed-off-by: Ye Xiang 
---
 .../hid-sensors/hid-sensor-attributes.c   | 74 ++-
 drivers/iio/industrialio-core.c   |  1 +
 include/linux/hid-sensor-hub.h|  5 ++
 include/linux/hid-sensor-ids.h|  1 +
 include/linux/iio/types.h |  1 +
 5 files changed, 78 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c 
b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
index d349ace2e33f..cb52b4fd6bf7 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
@@ -263,6 +263,29 @@ int hid_sensor_read_raw_hyst_value(struct 
hid_sensor_common *st,
 }
 EXPORT_SYMBOL(hid_sensor_read_raw_hyst_value);
 
+int hid_sensor_read_raw_hyst_rel_value(struct hid_sensor_common *st, int *val1,
+  int *val2)
+{
+   s32 value;
+   int ret;
+
+   ret = sensor_hub_get_feature(st->hsdev,
+st->sensitivity_rel.report_id,
+st->sensitivity_rel.index, sizeof(value),
+);
+   if (ret < 0 || value < 0) {
+   *val1 = *val2 = 0;
+   return -EINVAL;
+   }
+
+   convert_from_vtf_format(value, st->sensitivity_rel.size,
+   st->sensitivity_rel.unit_expo, val1, val2);
+
+   return IIO_VAL_INT_PLUS_MICRO;
+}
+EXPORT_SYMBOL(hid_sensor_read_raw_hyst_rel_value);
+
+
 int hid_sensor_write_raw_hyst_value(struct hid_sensor_common *st,
int val1, int val2)
 {
@@ -294,6 +317,37 @@ int hid_sensor_write_raw_hyst_value(struct 
hid_sensor_common *st,
 }
 EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);
 
+int hid_sensor_write_raw_hyst_rel_value(struct hid_sensor_common *st,
+   int val1, int val2)
+{
+   s32 value;
+   int ret;
+
+   if (val1 < 0 || val2 < 0)
+   return -EINVAL;
+
+   value = convert_to_vtf_format(st->sensitivity_rel.size,
+   st->sensitivity_rel.unit_expo,
+   val1, val2);
+   ret = sensor_hub_set_feature(st->hsdev, st->sensitivity_rel.report_id,
+st->sensitivity_rel.index, sizeof(value),
+);
+   if (ret < 0 || value < 0)
+   return -EINVAL;
+
+   ret = sensor_hub_get_feature(st->hsdev,
+st->sensitivity_rel.report_id,
+st->sensitivity_rel.index, sizeof(value),
+);
+   if (ret < 0 || value < 0)
+   return -EINVAL;
+
+   st->raw_hystersis = value;
+
+   return 0;
+}
+EXPORT_SYMBOL(hid_sensor_write_raw_hyst_rel_value);
+
 /*
  * This fuction applies the unit exponent to the scale.
  * For example:
@@ -478,16 +532,28 @@ int hid_sensor_parse_common_attributes(struct 
hid_sensor_hub_device *hsdev,
HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS,
 >sensitivity);
 
+   sensor_hub_input_get_attribute_info(hsdev,
+   HID_FEATURE_REPORT, usage_id,
+   HID_USAGE_SENSOR_PROP_SENSITIVITY_REL_PCT,
+   >sensitivity_rel);
/*
 * Set Sensitivity field ids, when there is no individual modifier, will
-* check absolute sensitivity of data field
+* check absolute sensitivity and relative sensitivity of data field
 */
-   for (i = 0; i < sensitivity_addresses_len && st->sensitivity.index < 0; 
i++) {
-   sensor_hub_input_get_attribute_info(hsdev,
-   HID_FEATURE_REPORT, usage_id,
+   for (i = 0; i < sensitivity_addresses_len; i++) {
+   if (st->sensitivity.index < 0)
+   sensor_hub_input_get_attribute_info(
+   hsdev, HID_FEATURE_REPORT, usage_id,

HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
sensitivity_addresses[i],
>sensitivity);
+
+   if (st->sensitivity_rel.index < 0)
+   sensor_hub_input_get_attribute_info(
+   hsdev, HID_FEATURE_REPORT, usage_id,
+   
HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_REL_PCT |
+   sensitivity_addresses[i],
+   >sensitivity_rel);
}
 
st->raw_hystersis = -1;
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 7db761afa578..3da8fcec3c16 100644
--- 

[PATCH v2 3/3] iio: Add relative hysteresis in ABI documentation

2021-02-06 Thread Ye Xiang
Add relative hysteresis in ABI documentation for als sensor.

Signed-off-by: Ye Xiang 
---
 Documentation/ABI/testing/sysfs-bus-iio | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index d957f5da5c04..0890bd113eea 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1823,3 +1823,12 @@ Description:
hinge, keyboard, screen. It means the three channels
each correspond respectively to hinge angle, keyboard angle,
and screen angle.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/in_illuminance_hysteresis_relative
+What:  
/sys/bus/iio/devices/iio:deviceX/in_intensity_hysteresis_relative
+KernelVersion: 5.12
+Contact:   linux-...@vger.kernel.org
+Description:
+   Specify the percent for light sensor relative to the channel
+   absolute value that a data field should change before an event
+   is generated. Units are a percentage of the prior reading.
-- 
2.17.1



[PATCH v2 2/3] iio: hid-sensor-als: Add relative hysteresis support

2021-02-06 Thread Ye Xiang
Hid sensor als use relative hysteresis, this patch adds the support.

Signed-off-by: Ye Xiang 
---
 drivers/iio/light/hid-sensor-als.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/light/hid-sensor-als.c 
b/drivers/iio/light/hid-sensor-als.c
index afcdb424bfb8..85c8a05b73cb 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -54,7 +54,8 @@ static const struct iio_chan_spec als_channels[] = {
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
-   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   BIT(IIO_CHAN_INFO_HYSTERESIS) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
.scan_index = CHANNEL_SCAN_INDEX_INTENSITY,
},
{
@@ -63,7 +64,8 @@ static const struct iio_chan_spec als_channels[] = {
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
-   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   BIT(IIO_CHAN_INFO_HYSTERESIS) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
.scan_index = CHANNEL_SCAN_INDEX_ILLUM,
},
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
@@ -141,6 +143,10 @@ static int als_read_raw(struct iio_dev *indio_dev,
ret_type = hid_sensor_read_raw_hyst_value(
_state->common_attributes, val, val2);
break;
+   case IIO_CHAN_INFO_HYSTERESIS_RELATIVE:
+   ret_type = hid_sensor_read_raw_hyst_rel_value(
+   _state->common_attributes, val, val2);
+   break;
default:
ret_type = -EINVAL;
break;
@@ -168,6 +174,10 @@ static int als_write_raw(struct iio_dev *indio_dev,
ret = hid_sensor_write_raw_hyst_value(
_state->common_attributes, val, val2);
break;
+   case IIO_CHAN_INFO_HYSTERESIS_RELATIVE:
+   ret = hid_sensor_write_raw_hyst_rel_value(
+   _state->common_attributes, val, val2);
+   break;
default:
ret = -EINVAL;
}
-- 
2.17.1



[PATCH v2 0/3] Add relative hysteresis support for hid sensors

2021-02-06 Thread Ye Xiang
Currently, hid sensor als are using the relative hysteresis.
This patch series add the relative hysteresis for hid sensors.

---
v2:
  - (1/3) fix the formatting issue in hid_sensor_read_raw_hyst_rel_value.
  - (3/3) add documentation just for light sensor.

Ye Xiang (3):
  iio: Add relative sensitivity support
  iio: hid-sensor-als: Add relative hysteresis support
  iio: Add relative hysteresis in ABI documentation

 Documentation/ABI/testing/sysfs-bus-iio   |  9 +++
 .../hid-sensors/hid-sensor-attributes.c   | 74 ++-
 drivers/iio/industrialio-core.c   |  1 +
 drivers/iio/light/hid-sensor-als.c| 14 +++-
 include/linux/hid-sensor-hub.h|  5 ++
 include/linux/hid-sensor-ids.h|  1 +
 include/linux/iio/types.h |  1 +
 7 files changed, 99 insertions(+), 6 deletions(-)

-- 
2.17.1



[PATCH RFC 5/7] kvm: x86: Revise CPUID.D.1.EBX for alignment rule

2021-02-06 Thread Jing Liu
CPUID.0xD.1.EBX[1] is set if, when the compacted format of an XSAVE
area is used, this extended state component located on the next
64-byte boundary following the preceding state component (otherwise,
it is located immediately following the preceding state component).

AMX tileconfig and tiledata are the first to use 64B alignment.
Revise the runtime cpuid modification for this rule.

Signed-off-by: Jing Liu 
---
 arch/x86/kvm/cpuid.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 04a73c395c71..ee1fac0a865e 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -35,12 +35,17 @@ static u32 xstate_required_size(u64 xstate_bv, bool 
compacted)
 {
int feature_bit = 0;
u32 ret = XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET;
+   bool is_aligned = false;
 
xstate_bv &= XFEATURE_MASK_EXTEND;
while (xstate_bv) {
if (xstate_bv & 0x1) {
u32 eax, ebx, ecx, edx, offset;
cpuid_count(0xD, feature_bit, , , , );
+   /* ECX[2]: 64B alignment in compacted form */
+   is_aligned = !!(ecx & 2);
+   if (is_aligned && compacted)
+   ret = ALIGN(ret, 64);
offset = compacted ? ret : ebx;
ret = max(ret, offset + eax);
}
-- 
2.18.4



[PATCH] scsi: qla4xxx: turn qla4xxx_copy_from_fwddb_param() into void

2021-02-06 Thread Yang Li
This function always return '0' and no callers use the return value.
So make it a void function.

This eliminates the following coccicheck warning:
./drivers/scsi/qla4xxx/ql4_os.c:3642:5-7: Unneeded variable: "rc".
Return "0" on line 3741

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/scsi/qla4xxx/ql4_os.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index a4b014e..18dcb68 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -3634,12 +3634,11 @@ static int qla4xxx_copy_from_fwddb_param(struct 
iscsi_bus_flash_session *sess,
return rc;
 }
 
-static int qla4xxx_copy_to_fwddb_param(struct iscsi_bus_flash_session *sess,
+static void qla4xxx_copy_to_fwddb_param(struct iscsi_bus_flash_session *sess,
   struct iscsi_bus_flash_conn *conn,
   struct dev_db_entry *fw_ddb_entry)
 {
uint16_t options;
-   int rc = 0;
 
options = le16_to_cpu(fw_ddb_entry->options);
SET_BITVAL(conn->is_fw_assigned_ipv6,  options, BIT_11);
@@ -3738,7 +3737,7 @@ static int qla4xxx_copy_to_fwddb_param(struct 
iscsi_bus_flash_session *sess,
 
COPY_ISID(fw_ddb_entry->isid, sess->isid);
 
-   return rc;
+   return;
 }
 
 static void qla4xxx_copy_to_sess_conn_params(struct iscsi_conn *conn,
-- 
1.8.3.1



[PATCH RFC 7/7] kvm: x86: AMX XCR0 support for guest

2021-02-06 Thread Jing Liu
Two XCR0 bits are defined for AMX to support XSAVE mechanism.
Bit 17 is for tilecfg and bit 18 is for tiledata.

Signed-off-by: Jing Liu 
---
 arch/x86/kvm/x86.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bfbde877221e..f1c5893dee18 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -189,7 +189,7 @@ static struct kvm_user_return_msrs __percpu 
*user_return_msrs;
 #define KVM_SUPPORTED_XCR0 (XFEATURE_MASK_FP | XFEATURE_MASK_SSE \
| XFEATURE_MASK_YMM | XFEATURE_MASK_BNDREGS \
| XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
-   | XFEATURE_MASK_PKRU)
+   | XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE)
 
 u64 __read_mostly host_efer;
 EXPORT_SYMBOL_GPL(host_efer);
@@ -946,6 +946,12 @@ static int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, 
u64 xcr)
if ((xcr0 & XFEATURE_MASK_AVX512) != XFEATURE_MASK_AVX512)
return 1;
}
+
+   if (xcr0 & XFEATURE_MASK_XTILE) {
+   if ((xcr0 & XFEATURE_MASK_XTILE) != XFEATURE_MASK_XTILE)
+   return 1;
+   }
+
vcpu->arch.xcr0 = xcr0;
 
if ((xcr0 ^ old_xcr0) & XFEATURE_MASK_EXTEND)
-- 
2.18.4



[PATCH RFC 4/7] kvm: x86: Add new ioctls for XSAVE extension

2021-02-06 Thread Jing Liu
The static xstate buffer kvm_xsave contains the extended register
states, but it is not enough for dynamic features with large state.

Introduce a new capability called KVM_CAP_X86_XSAVE_EXTENSION to
detect if hardware has XSAVE extension (XFD). Meanwhile, add two
new ioctl interfaces to get/set the whole xstate using struct
kvm_xsave_extension buffer containing both static and dynamic
xfeatures. Reuse fill_xsave and load_xsave for both cases.

Signed-off-by: Jing Liu 
---
 arch/x86/include/uapi/asm/kvm.h |  5 +++
 arch/x86/kvm/x86.c  | 70 +
 include/uapi/linux/kvm.h|  8 
 3 files changed, 66 insertions(+), 17 deletions(-)

diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 89e5f3d1bba8..bf785e89a728 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -362,6 +362,11 @@ struct kvm_xsave {
__u32 region[1024];
 };
 
+/* for KVM_CAP_XSAVE_EXTENSION */
+struct kvm_xsave_extension {
+   __u32 region[3072];
+};
+
 #define KVM_MAX_XCRS   16
 
 struct kvm_xcr {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 15908bc65d1c..bfbde877221e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3786,6 +3786,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
ext)
case KVM_CAP_XCRS:
r = boot_cpu_has(X86_FEATURE_XSAVE);
break;
+   case KVM_CAP_X86_XSAVE_EXTENSION:
+   r = boot_cpu_has(X86_FEATURE_XSAVE) &&
+   boot_cpu_has(X86_FEATURE_XFD);
+   break;
case KVM_CAP_TSC_CONTROL:
r = kvm_has_tsc_control;
break;
@@ -4395,7 +4399,7 @@ static int kvm_vcpu_ioctl_x86_set_debugregs(struct 
kvm_vcpu *vcpu,
 
 #define XSTATE_COMPACTION_ENABLED (1ULL << 63)
 
-static void fill_xsave(u8 *dest, struct kvm_vcpu *vcpu)
+static void fill_xsave(u8 *dest, struct kvm_vcpu *vcpu, bool has_extension)
 {
struct xregs_state *xsave;
struct fpu *guest_fpu;
@@ -4403,9 +4407,14 @@ static void fill_xsave(u8 *dest, struct kvm_vcpu *vcpu)
u64 valid;
 
guest_fpu = vcpu->arch.guest_fpu;
-   xsave = _fpu->state.xsave;
+   xsave = __xsave(guest_fpu);
xstate_bv = xsave->header.xfeatures;
 
+   if (!has_extension) {
+   /* truncate with only non-dynamic features */
+   xstate_bv = xstate_bv & ~xfeatures_mask_user_dynamic;
+   }
+
/*
 * Copy legacy XSAVE area, to avoid complications with CPUID
 * leaves 0 and 1 in the loop below.
@@ -4450,7 +4459,7 @@ static void load_xsave(struct kvm_vcpu *vcpu, u8 *src)
u64 valid;
 
guest_fpu = vcpu->arch.guest_fpu;
-   xsave = _fpu->state.xsave;
+   xsave = __xsave(guest_fpu);
 
/*
 * Copy legacy XSAVE area, to avoid complications with CPUID
@@ -4488,29 +4497,31 @@ static void load_xsave(struct kvm_vcpu *vcpu, u8 *src)
}
 }
 
-static void kvm_vcpu_ioctl_x86_get_xsave(struct kvm_vcpu *vcpu,
-struct kvm_xsave *guest_xsave)
+static void kvm_vcpu_ioctl_x86_get_xsave(struct kvm_vcpu *vcpu, u32 *region, 
bool has_extension)
 {
if (boot_cpu_has(X86_FEATURE_XSAVE)) {
-   memset(guest_xsave, 0, sizeof(struct kvm_xsave));
-   fill_xsave((u8 *) guest_xsave->region, vcpu);
+   if (has_extension)
+   memset(region, 0, sizeof(struct kvm_xsave_extension));
+   else
+   memset(region, 0, sizeof(struct kvm_xsave));
+
+   fill_xsave((u8 *)region, vcpu, has_extension);
} else {
-   memcpy(guest_xsave->region,
+   memcpy(region,
>arch.guest_fpu->state.fxsave,
sizeof(struct fxregs_state));
-   *(u64 *)_xsave->region[XSAVE_HDR_OFFSET / sizeof(u32)] =
+   *(u64 *)[XSAVE_HDR_OFFSET / sizeof(u32)] =
XFEATURE_MASK_FPSSE;
}
 }
 
 #define XSAVE_MXCSR_OFFSET 24
 
-static int kvm_vcpu_ioctl_x86_set_xsave(struct kvm_vcpu *vcpu,
-   struct kvm_xsave *guest_xsave)
+static int kvm_vcpu_ioctl_x86_set_xsave(struct kvm_vcpu *vcpu, u32 *region)
 {
u64 xstate_bv =
-   *(u64 *)_xsave->region[XSAVE_HDR_OFFSET / sizeof(u32)];
-   u32 mxcsr = *(u32 *)_xsave->region[XSAVE_MXCSR_OFFSET / 
sizeof(u32)];
+   *(u64 *)[XSAVE_HDR_OFFSET / sizeof(u32)];
+   u32 mxcsr = *(u32 *)[XSAVE_MXCSR_OFFSET / sizeof(u32)];
 
if (boot_cpu_has(X86_FEATURE_XSAVE)) {
/*
@@ -4520,13 +4531,13 @@ static int kvm_vcpu_ioctl_x86_set_xsave(struct kvm_vcpu 
*vcpu,
 */
if (xstate_bv & ~supported_xcr0 || mxcsr & ~mxcsr_feature_mask)
return -EINVAL;
-   load_xsave(vcpu, (u8 *)guest_xsave->region);
+   

[PATCH RFC 6/7] kvm: x86: Add AMX_TILE, AMX_INT8 and AMX_BF16 support

2021-02-06 Thread Jing Liu
Intel introduces AMX architecture in SPR platform, which includes
AMX_TILE, AMX_INT8 and AMX_BF16 support.

Exposes these features to KVM guest.

Signed-off-by: Jing Liu 
---
 arch/x86/kvm/cpuid.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index ee1fac0a865e..1b3ea9195a75 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -423,7 +423,8 @@ void kvm_set_cpu_caps(void)
F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) |
F(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM) |
-   F(SERIALIZE) | F(TSXLDTRK)
+   F(SERIALIZE) | F(TSXLDTRK) |
+   F(AMX_TILE) | F(AMX_INT8) | F(AMX_BF16)
);
 
/* TSC_ADJUST and ARCH_CAPABILITIES are emulated in software. */
@@ -544,6 +545,8 @@ static struct kvm_cpuid_entry2 *do_host_cpuid(struct 
kvm_cpuid_array *array,
case 0x14:
case 0x17:
case 0x18:
+   case 0x1d:
+   case 0x1e:
case 0x1f:
case 0x801d:
entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
@@ -667,6 +670,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array 
*array, u32 function)
break;
case 9:
break;
+   case 0x1e:
+   break;
case 0xa: { /* Architectural Performance Monitoring */
struct x86_pmu_capability cap;
union cpuid10_eax eax;
@@ -766,9 +771,12 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array 
*array, u32 function)
entry->edx = 0;
}
break;
+   /* Intel AMX TILE */
+   case 0x1d:
/* Intel PT */
case 0x14:
-   if (!kvm_cpu_cap_has(X86_FEATURE_INTEL_PT)) {
+   if ((function == 0x14 && 
!kvm_cpu_cap_has(X86_FEATURE_INTEL_PT)) ||
+   (function == 0x1d && 
!kvm_cpu_cap_has(X86_FEATURE_AMX_TILE))) {
entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
break;
}
-- 
2.18.4



[PATCH RFC 1/7] kvm: x86: Expose XFD CPUID to guest

2021-02-06 Thread Jing Liu
Intel's Extended Feature Disable (XFD) feature is an extension
to the XSAVE feature that allows an operating system to enable
a feature while preventing specific user threads from using
the feature. A processor that supports XFD enumerates
CPUID.(EAX=0DH,ECX=1):EAX[4] as 1.

Signed-off-by: Jing Liu 
---
 arch/x86/kvm/cpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 83637a2ff605..04a73c395c71 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -437,7 +437,7 @@ void kvm_set_cpu_caps(void)
);
 
kvm_cpu_cap_mask(CPUID_D_1_EAX,
-   F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES)
+   F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES) | F(XFD)
);
 
kvm_cpu_cap_mask(CPUID_8000_0001_ECX,
-- 
2.18.4



[PATCH RFC 3/7] kvm: x86: XSAVE state and XFD MSRs context switch

2021-02-06 Thread Jing Liu
XFD allows the kernel to enable a feature state in XCR0 and to
receive a #NM trap when a task uses instructions accessing that state.
Kernel defines "struct fpu.state_mask" to indicate the saved xstate and
interact with the XFD hardware when needed via a simple conversion.
Once a dynamic feature is detected, "state_mask" is expanded and
"state_ptr" is dynamically allocated to hold the whole state. Meanwhile
once the state is not in INIT state, the corresponding XFD bit should
not be armed anymore.

In KVM, "guest_fpu" serves for any guest task working on this vcpu
during vmexit and vmenter. We provide a pre-allocated guest_fpu space
and entire "guest_fpu.state_mask" to avoid each dynamic features
detection on each vcpu task. Meanwhile, to ensure correctly
xsaves/xrstors guest state, set IA32_XFD as zero during vmexit and
vmenter.

For "current->thread.fpu", since host and guest probably have different
state and mask, it also need be switched to the right context when fpu
load and put.

Signed-off-by: Jing Liu 
---
 arch/x86/include/asm/kvm_host.h |  3 ++
 arch/x86/kernel/fpu/init.c  |  1 +
 arch/x86/kernel/fpu/xstate.c|  2 +
 arch/x86/kvm/vmx/vmx.c  | 76 +
 arch/x86/kvm/vmx/vmx.h  |  1 +
 arch/x86/kvm/x86.c  | 69 +-
 6 files changed, 141 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7e5f33a0d0e2..6dedf3d22659 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1203,6 +1203,9 @@ struct kvm_x86_ops {
   struct x86_exception *exception);
void (*handle_exit_irqoff)(struct kvm_vcpu *vcpu);
 
+   void (*xfd_load)(struct kvm_vcpu *vcpu);
+   void (*xfd_put)(struct kvm_vcpu *vcpu);
+
void (*request_immediate_exit)(struct kvm_vcpu *vcpu);
 
void (*sched_in)(struct kvm_vcpu *kvm, int cpu);
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 7e0c68043ce3..fbb761fc13ec 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -145,6 +145,7 @@ EXPORT_SYMBOL_GPL(fpu_kernel_xstate_min_size);
  * can be dynamically expanded to include some states up to this size.
  */
 unsigned int fpu_kernel_xstate_max_size;
+EXPORT_SYMBOL_GPL(fpu_kernel_xstate_max_size);
 
 /* Get alignment of the TYPE. */
 #define TYPE_ALIGN(TYPE) offsetof(struct { char x; TYPE test; }, test)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 080f3be9a5e6..9c471a0364e2 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -77,12 +77,14 @@ static struct xfeature_capflag_info xfeature_capflags[] 
__initdata = {
  * XSAVE buffer, both supervisor and user xstates.
  */
 u64 xfeatures_mask_all __read_mostly;
+EXPORT_SYMBOL_GPL(xfeatures_mask_all);
 
 /*
  * This represents user xstates, a subset of xfeatures_mask_all, saved in a
  * dynamic kernel XSAVE buffer.
  */
 u64 xfeatures_mask_user_dynamic __read_mostly;
+EXPORT_SYMBOL_GPL(xfeatures_mask_user_dynamic);
 
 static unsigned int xstate_offsets[XFEATURE_MAX] = { [ 0 ... XFEATURE_MAX - 1] 
= -1};
 static unsigned int xstate_sizes[XFEATURE_MAX]   = { [ 0 ... XFEATURE_MAX - 1] 
= -1};
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 7fa54e78c45c..be3cc0f3ec6d 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1167,6 +1167,75 @@ static void pt_guest_exit(struct vcpu_vmx *vmx)
wrmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
 }
 
+static void vmx_xfd_load(struct kvm_vcpu *vcpu)
+{
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+   if (guest_cpuid_has(vcpu, X86_FEATURE_XFD)) {
+   vmx->host_ia32_xfd = 
xfirstuse_not_detected(vcpu->arch.user_fpu);
+   /*
+* Keep IA32_XFD as zero in hypervisor.
+* Guest non-zero IA32_XFD is restored until kvm_x86_ops.run
+*/
+   if (vmx->host_ia32_xfd)
+   wrmsrl(MSR_IA32_XFD, 0);
+   }
+}
+
+static void vmx_xfd_put(struct kvm_vcpu *vcpu)
+{
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+   if (guest_cpuid_has(vcpu, X86_FEATURE_XFD)) {
+   /* IA32_XFD register is kept as zero in hypervisor. */
+   if (vmx->host_ia32_xfd)
+   wrmsrl(MSR_IA32_XFD, vmx->host_ia32_xfd);
+   /* User (qemu) IA32_XFD_ERR should be zero. */
+   if (vmx->msr_ia32_xfd_err)
+   wrmsrl(MSR_IA32_XFD_ERR, 0);
+   }
+}
+
+/* Load guest XFD MSRs before entering. */
+static void xfd_guest_enter(struct vcpu_vmx *vmx)
+{
+   if (guest_cpuid_has(>vcpu, X86_FEATURE_XFD)) {
+   if (vmx->msr_ia32_xfd)
+   wrmsrl(MSR_IA32_XFD, vmx->msr_ia32_xfd);
+   /*
+* We do not rdmsr here since in most cases
+* IA32_XFD_ERR is zero. One rare exception 

[PATCH RFC 2/7] kvm: x86: Introduce XFD MSRs as passthrough to guest

2021-02-06 Thread Jing Liu
XFD feature introduces two new MSRs: IA32_XFD and IA32_XFD_ERR.
Each of the MSRs contains a state-component bitmap. XFD is enabled
for state component i if XCR0[i] = IA32_XFD[i] = 1. When XFD is
enabled for a state component, any instruction that would access
that state component does not execute and instead generates an
device-not-available exception (#NM). IA32_XFD_ERR is for
indicating which state causes the #NM event.

The MSRs are per task and need be context switched between host
and guest, and also between tasks inside guest just as native.
Passthrough both MSRs to let guest access and write without
vmexit. Add two slots for XFD MSRs as desired passthrough MSRs.

Signed-off-by: Jing Liu 
---
 arch/x86/kvm/vmx/vmx.c | 38 ++
 arch/x86/kvm/vmx/vmx.h |  6 +-
 arch/x86/kvm/x86.c |  6 ++
 3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 47b8357b9751..7fa54e78c45c 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -162,6 +162,8 @@ static u32 
vmx_possible_passthrough_msrs[MAX_POSSIBLE_PASSTHROUGH_MSRS] = {
MSR_IA32_SYSENTER_CS,
MSR_IA32_SYSENTER_ESP,
MSR_IA32_SYSENTER_EIP,
+   MSR_IA32_XFD,
+   MSR_IA32_XFD_ERR,
MSR_CORE_C1_RES,
MSR_CORE_C3_RESIDENCY,
MSR_CORE_C6_RESIDENCY,
@@ -1824,6 +1826,18 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
 
msr_info->data = vmx->msr_ia32_umwait_control;
break;
+   case MSR_IA32_XFD:
+   if (!msr_info->host_initiated)
+   return 1;
+
+   msr_info->data = vmx->msr_ia32_xfd;
+   break;
+   case MSR_IA32_XFD_ERR:
+   if (!msr_info->host_initiated)
+   return 1;
+
+   msr_info->data = vmx->msr_ia32_xfd_err;
+   break;
case MSR_IA32_SPEC_CTRL:
if (!msr_info->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
@@ -2026,6 +2040,20 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
 
vmx->msr_ia32_umwait_control = data;
break;
+   case MSR_IA32_XFD:
+   if (!msr_info->host_initiated)
+   return 1;
+
+   vmx->msr_ia32_xfd = data;
+   break;
+   case MSR_IA32_XFD_ERR:
+   if (!msr_info->host_initiated)
+   return 1;
+   if (data)
+   break;
+
+   vmx->msr_ia32_xfd_err = data;
+   break;
case MSR_IA32_SPEC_CTRL:
if (!msr_info->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
@@ -7219,6 +7247,12 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
vmx->pt_desc.ctl_bitmask &= ~(0xfULL << (32 + i * 4));
 }
 
+static void vmx_update_intercept_xfd(struct kvm_vcpu *vcpu)
+{
+   vmx_set_intercept_for_msr(vcpu, MSR_IA32_XFD, MSR_TYPE_RW, false);
+   vmx_set_intercept_for_msr(vcpu, MSR_IA32_XFD_ERR, MSR_TYPE_RW, false);
+}
+
 static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -7249,6 +7283,10 @@ static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu 
*vcpu)
guest_cpuid_has(vcpu, X86_FEATURE_INTEL_PT))
update_intel_pt_cfg(vcpu);
 
+   if (boot_cpu_has(X86_FEATURE_XFD) &&
+   guest_cpuid_has(vcpu, X86_FEATURE_XFD))
+   vmx_update_intercept_xfd(vcpu);
+
if (boot_cpu_has(X86_FEATURE_RTM)) {
struct vmx_uret_msr *msr;
msr = vmx_find_uret_msr(vmx, MSR_IA32_TSX_CTRL);
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index f6f66e5c6510..d487f5a53a08 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -281,11 +281,15 @@ struct vcpu_vmx {
struct pt_desc pt_desc;
 
/* Save desired MSR intercept (read: pass-through) state */
-#define MAX_POSSIBLE_PASSTHROUGH_MSRS  13
+#define MAX_POSSIBLE_PASSTHROUGH_MSRS  15
struct {
DECLARE_BITMAP(read, MAX_POSSIBLE_PASSTHROUGH_MSRS);
DECLARE_BITMAP(write, MAX_POSSIBLE_PASSTHROUGH_MSRS);
} shadow_msr_intercept;
+
+   /* eXtended Feature Disabling (XFD) MSRs */
+   u64 msr_ia32_xfd;
+   u64 msr_ia32_xfd_err;
 };
 
 enum ept_pointers_status {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 93b5bacad67a..9ca8b1e58afa 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1213,6 +1213,7 @@ static const u32 msrs_to_save_all[] = {
MSR_IA32_RTIT_ADDR2_A, MSR_IA32_RTIT_ADDR2_B,
MSR_IA32_RTIT_ADDR3_A, MSR_IA32_RTIT_ADDR3_B,
MSR_IA32_UMWAIT_CONTROL,
+   MSR_IA32_XFD, MSR_IA32_XFD_ERR,
 
MSR_ARCH_PERFMON_FIXED_CTR0, 

[PATCH RFC 0/7] Introduce support for guest AMX feature

2021-02-06 Thread Jing Liu
Intel introduces Advanced Matrix Extensions (AMX) [1] feature that
will be shipping soon. AMX consists of configurable two-dimensional
"TILE" registers and new accelerator instructions that operate on them.
TMUL (Tile matrix MULtiply) is the first accelerator instruction set
to use the new registers.

Intel AMX is XSAVE supported and XSAVE enabled. It is associated with
two state components, XTILECFG and XTILEDATA. The XTILEDATA state
component is very large so an XSAVE extension called extended feature
disable (XFD) is introduced to support dynamic usage. When XFD is
enabled for a state component, any instruction that would access
that state component does not execute and instead generates an #NM.
So Linux kernel arms XFD to monitor the first usage of AMX.

This patchset adds AMX and XFD support for guest: providing related
CPUID and MSRs to guest, adding extended XSAVE state context switch and
XFD MSRs switch during vmenter/vmexit. 

This RFC series is based on kernel AMX series v3 [2] in LKML though not
latest upstream commit and we'd looking forward for your comments.

[1]: Intel Architecture Instruction Set Extension Programming Reference

https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf

[2]: AMX kernel series v3 https://lkml.org/lkml/2020/12/23/464


Jing Liu (7):
  kvm: x86: Expose XFD CPUID to guest
  kvm: x86: Introduce XFD MSRs as passthrough to guest
  kvm: x86: Dynamic XSAVE and XFD MSRs context switch
  kvm: x86: Add new ioctls for XSAVE extension
  kvm: x86: Revise CPUID.D.1.EBX for alignment rule
  kvm: x86: Add AMX_TILE, AMX_INT8 and AMX_BF16 support
  kvm: x86: AMX XCR0 support for guest

 arch/x86/include/asm/kvm_host.h |   3 +
 arch/x86/include/uapi/asm/kvm.h |   5 ++
 arch/x86/kernel/fpu/init.c  |   1 +
 arch/x86/kernel/fpu/xstate.c|   2 +
 arch/x86/kvm/cpuid.c|  19 +++-
 arch/x86/kvm/vmx/vmx.c  | 114 
 arch/x86/kvm/vmx/vmx.h  |   7 +-
 arch/x86/kvm/x86.c  | 153 ++--
 include/uapi/linux/kvm.h|   8 ++
 9 files changed, 279 insertions(+), 33 deletions(-)

-- 
2.18.4



[PATCH] powerpc/xive: Assign boolean values to a bool variable

2021-02-06 Thread Jiapeng Chong
Fix the following coccicheck warnings:

./arch/powerpc/kvm/book3s_xive.c:1856:2-17: WARNING: Assignment of 0/1
to bool variable.

./arch/powerpc/kvm/book3s_xive.c:1854:2-17: WARNING: Assignment of 0/1
to bool variable.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 arch/powerpc/kvm/book3s_xive.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index 30dfeac..e7219b6 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -1813,9 +1813,9 @@ int kvmppc_xive_set_irq(struct kvm *kvm, int 
irq_source_id, u32 irq, int level,
return -EINVAL;
 
if ((level == 1 && state->lsi) || level == KVM_INTERRUPT_SET_LEVEL)
-   state->asserted = 1;
+   state->asserted = true;
else if (level == 0 || level == KVM_INTERRUPT_UNSET) {
-   state->asserted = 0;
+   state->asserted = false;
return 0;
}
 
-- 
1.8.3.1



Re: ANNOUNCE: pahole v1.20 (gcc11 DWARF5's default, lots of ELF sections, BTF)

2021-02-06 Thread Andrii Nakryiko
On Fri, Feb 5, 2021 at 3:55 PM Arnaldo Carvalho de Melo
 wrote:
>
> Em Fri, Feb 05, 2021 at 02:11:44PM -0800, Andrii Nakryiko escreveu:
> > On Fri, Feb 5, 2021 at 8:25 AM Arnaldo Carvalho de Melo
> >  wrote:
> > >
> > > Em Fri, Feb 05, 2021 at 06:33:43AM -0300, Arnaldo Carvalho de Melo 
> > > escreveu:
> > > > On February 5, 2021 4:39:47 AM GMT-03:00, Andrii Nakryiko 
> > > >  wrote:
> > > > >On Thu, Feb 4, 2021 at 8:34 PM Arnaldo Carvalho de Melo 
> > > > >> wrote:
> > > > >> On February 4, 2021 9:01:51 PM GMT-03:00, Andrii Nakryiko
> > > > > wrote:
> > > > >> >On Thu, Feb 4, 2021 at 2:09 PM Arnaldo Carvalho de
> > > > >Melo> wrote:
> > > > >> >> The v1.20 release of pahole and its friends is out, mostly
> > > > >> >> addressing problems related to gcc 11 defaulting to DWARF5 for -g,
> > > > >> >> available at the usual places:
> > >
> > > > >> >Great, thanks, Arnaldo! Do you plan to build RPMs soon as well?
> > >
> > > > >> It's in rawhide already, I'll do it for f33, f32 later,
> > >
> > > > >Do you have a link? I tried to find it, but only see 1.19 so far.
> > >
> > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1703678
> > >
> > > And now for Fedora 33, waiting for karma bumps at:
> > >
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-804e7a572c
> > >
> > > fedpkg buidling for f32 now.
>
> > Ok, imported dwarves-1.20. Had to fix two dates in changelog (in
> > spec), day of week didn't match the date, tooling complained about
> > that. Also had to undo cmake_build and cmake_install fanciness,
> > because apparently we don't have them or the support for it is not
> > great. But otherwise everything else looks to be ok.
>
> Send patch please, I wasn't expecting this, if you could do some more
> and send me tooling bits to help me in the release process, if that is
> possible, I'd love to get it, otherwise I'll write it, don't want to go
> thru this one more time, sigh :-(
>

I just "reverted" some bits of spec file to what it used to be
pre-1.19, I think. There is also a work-around for lack of
ldconfig_scriptlets support in our platform, so I have to work around
that. Here's full diff:

diff -u sources/git/rpm/SPECS/dwarves.spec specfiles/dwarves.spec
--- sources/git/rpm/SPECS/dwarves.spec  2021-02-05 11:19:54.364938716 -0800
+++ specfiles/dwarves.spec  2021-02-05 13:26:52.502859609 -0800
@@ -3,12 +3,14 @@

 Name: dwarves
 Version: 1.20
-Release: 1%{?dist}
+Release: 1fb1%{?dist}
 License: GPLv2
 Summary: Debugging Information Manipulation Tools (pahole & friends)
 URL: http://acmel.wordpress.com
 Source: http://fedorapeople.org/~acme/dwarves/%{name}-%{version}.tar.xz
 Requires: %{libname}%{libver} = %{version}-%{release}
+Requires(post): /sbin/ldconfig
+Requires(postun): /sbin/ldconfig
 BuildRequires: gcc
 BuildRequires: cmake >= 2.8.12
 BuildRequires: zlib-devel
@@ -68,13 +70,14 @@

 %build
 %cmake -DCMAKE_BUILD_TYPE=Release .
-%cmake_build
+make VERBOSE=1 %{?_smp_mflags}

 %install
 rm -Rf %{buildroot}
-%cmake_install
+make install DESTDIR=%{buildroot}

-%ldconfig_scriptlets -n %{libname}%{libver}
+%post -p /sbin/ldconfig
+%postun -p /sbin/ldconfig

 %files
 %doc README.ctracer
@@ -295,7 +298,7 @@
 * Sat Nov 20 2010 Arnaldo Carvalho de Melo  - 1.9-1
 - New release

-* Tue Feb 08 2010 Fedora Release Engineering
 - 1.8-2
+* Mon Feb 08 2010 Fedora Release Engineering
 - 1.8-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild

 * Fri Dec  4 2009 Arnaldo Carvalho de Melo  - 1.8-1
@@ -446,7 +449,7 @@
 - Fix emission of arrays of structs, unions, etc
 - use sysconf for the default cacheline size

-* Wed Jan 18 2007 Arnaldo Carvalho de Melo 
+* Thu Jan 18 2007 Arnaldo Carvalho de Melo 
 - fab0db03ea9046893ca110bb2b7d71b764f61033
 - pdwtags added

>
> - Arnaldo


[PATCH] jfs: turn diLog(), dataLog() and txLog() into void functions

2021-02-06 Thread Yang Li
These functions always return '0' and no callers use the return value.
So make it a void function.

This eliminates the following coccicheck warning:
./fs/jfs/jfs_txnmgr.c:1365:5-7: Unneeded variable: "rc". Return "0" on
line 1414
./fs/jfs/jfs_txnmgr.c:1422:5-7: Unneeded variable: "rc". Return "0" on
line 1527

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 fs/jfs/jfs_txnmgr.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index dca8edd..c42bf86 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -1365,9 +1365,8 @@ int txCommit(tid_t tid,   /* transaction 
identifier */
  *
  * RETURN :
  */
-static int txLog(struct jfs_log * log, struct tblock * tblk, struct commit * 
cd)
+static void txLog(struct jfs_log *log, struct tblock *tblk, struct commit *cd)
 {
-   int rc = 0;
struct inode *ip;
lid_t lid;
struct tlock *tlck;
@@ -1414,7 +1413,7 @@ static int txLog(struct jfs_log * log, struct tblock * 
tblk, struct commit * cd)
}
}
 
-   return rc;
+   return;
 }
 
 /*
@@ -1422,10 +1421,9 @@ static int txLog(struct jfs_log * log, struct tblock * 
tblk, struct commit * cd)
  *
  * function:   log inode tlock and format maplock to update bmap;
  */
-static int diLog(struct jfs_log * log, struct tblock * tblk, struct lrd * lrd,
-struct tlock * tlck, struct commit * cd)
+static void diLog(struct jfs_log *log, struct tblock *tblk, struct lrd *lrd,
+struct tlock *tlck, struct commit *cd)
 {
-   int rc = 0;
struct metapage *mp;
pxd_t *pxd;
struct pxd_lock *pxdlock;
@@ -1527,7 +1525,7 @@ static int diLog(struct jfs_log * log, struct tblock * 
tblk, struct lrd * lrd,
}
 #endif /* _JFS_WIP */
 
-   return rc;
+   return;
 }
 
 /*
@@ -1535,8 +1533,8 @@ static int diLog(struct jfs_log * log, struct tblock * 
tblk, struct lrd * lrd,
  *
  * function:   log data tlock
  */
-static int dataLog(struct jfs_log * log, struct tblock * tblk, struct lrd * 
lrd,
-   struct tlock * tlck)
+static void dataLog(struct jfs_log *log, struct tblock *tblk, struct lrd *lrd,
+   struct tlock *tlck)
 {
struct metapage *mp;
pxd_t *pxd;
@@ -1562,7 +1560,7 @@ static int dataLog(struct jfs_log * log, struct tblock * 
tblk, struct lrd * lrd,
metapage_homeok(mp);
discard_metapage(mp);
tlck->mp = NULL;
-   return 0;
+   return;
}
 
PXDaddress(pxd, mp->index);
@@ -1573,7 +1571,7 @@ static int dataLog(struct jfs_log * log, struct tblock * 
tblk, struct lrd * lrd,
/* mark page as homeward bound */
tlck->flag |= tlckWRITEPAGE;
 
-   return 0;
+   return;
 }
 
 /*
-- 
1.8.3.1



Re: [PATCH] staging: emxx_udc: Fix incorrectly defined global

2021-02-06 Thread Stephen Rothwell
Hi Kumar,

On Sun,  7 Feb 2021 05:30:31 +0530 Kumar Kartikeya Dwivedi  
wrote:
>
> The global gpio_desc pointer and int were defined in the header,
> instead put the definitions in the translation unit and add an extern
> declaration for consumers of the header (currently only one, which is
> perhaps why the linker didn't complain about symbol collisions).
> 
> This fixes sparse related warnings for this driver:
> drivers/staging/emxx_udc/emxx_udc.c: note: in included file:
> drivers/staging/emxx_udc/emxx_udc.h:23:18: warning: symbol 'vbus_gpio' was 
> not declared. Should it be static?
> drivers/staging/emxx_udc/emxx_udc.h:24:5: warning: symbol 'vbus_irq' was not 
> declared. Should it be static?
> 
> Signed-off-by: Kumar Kartikeya Dwivedi 

Given that drivers/staging/emxx_udc/emxx_udc.h is only included by
drivers/staging/emxx_udc/emxx_udc.c, shouldn't these variables just be
declared static in emxx_udc.c and removed from emxx_udc.h?

> ---
>  drivers/staging/emxx_udc/emxx_udc.c | 3 +++
>  drivers/staging/emxx_udc/emxx_udc.h | 4 ++--
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
> b/drivers/staging/emxx_udc/emxx_udc.c
> index a30b4f5b1..6983c3e31 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.c
> +++ b/drivers/staging/emxx_udc/emxx_udc.c
> @@ -34,6 +34,9 @@
>  #define  DRIVER_DESC "EMXX UDC driver"
>  #define  DMA_ADDR_INVALID(~(dma_addr_t)0)
>  
> +struct gpio_desc *vbus_gpio;
> +int vbus_irq;
> +
>  static const chardriver_name[] = "emxx_udc";
>  static const chardriver_desc[] = DRIVER_DESC;
>  
> diff --git a/drivers/staging/emxx_udc/emxx_udc.h 
> b/drivers/staging/emxx_udc/emxx_udc.h
> index bca614d69..b3c4ccbe5 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.h
> +++ b/drivers/staging/emxx_udc/emxx_udc.h
> @@ -20,8 +20,8 @@
>  /* below hacked up for staging integration */
>  #define GPIO_VBUS 0 /* GPIO_P153 on KZM9D */
>  #define INT_VBUS 0 /* IRQ for GPIO_P153 */
> -struct gpio_desc *vbus_gpio;
> -int vbus_irq;
> +extern struct gpio_desc *vbus_gpio;
> +extern int vbus_irq;
>  
>  /* Board dependence(Wait) */
>  
> -- 
> 2.29.2
> 

-- 
Cheers,
Stephen Rothwell


pgpQgXtY4h3E6.pgp
Description: OpenPGP digital signature


[PATCH] usb: gadget: Assign boolean values to a bool variable

2021-02-06 Thread Jiapeng Chong
Fix the following coccicheck warnings:

./drivers/usb/gadget/udc/udc-xilinx.c:846:1-17: WARNING: Assignment of
0/1 to bool variable.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 drivers/usb/gadget/udc/udc-xilinx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
b/drivers/usb/gadget/udc/udc-xilinx.c
index d5e9d20..2a06519 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -843,8 +843,8 @@ static int __xudc_ep_enable(struct xusb_ep *ep,
break;
}
 
-   ep->buffer0ready = 0;
-   ep->buffer1ready = 0;
+   ep->buffer0ready = false;
+   ep->buffer1ready = false;
ep->curbufnum = 0;
ep->rambase = rambase[ep->epnumber];
xudc_epconfig(ep, udc);
@@ -868,11 +868,11 @@ static int __xudc_ep_enable(struct xusb_ep *ep,
if (ep->epnumber && !ep->is_in) {
udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET,
  1 << ep->epnumber);
-   ep->buffer0ready = 1;
+   ep->buffer0ready = true;
udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET,
 (1 << (ep->epnumber +
  XUSB_STATUS_EP_BUFF2_SHIFT)));
-   ep->buffer1ready = 1;
+   ep->buffer1ready = true;
}
 
return 0;
-- 
1.8.3.1



[PATCH v4 3/3] arm64: dts: mt8192: add mt6315 regulator nodes

2021-02-06 Thread Hsin-Hsiung Wang
Add MT6315 regulator nodes to MT8192 evaluation board.

Signed-off-by: Hsin-Hsiung Wang 
---
changes since v3:
- update the dts node.
---
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 46 +
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 0205837fa698..83f26cd5f693 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -24,6 +24,52 @@
};
 };
 
+ {
+   grpid = <11>;
+   mt6315_6: pmic@6 {
+   compatible = "mediatek,mt6315-regulator";
+   reg = <0x6 0>;
+
+   regulators {
+   mt6315_6_vbuck1: vbuck1 {
+   regulator-compatible = "vbuck1";
+   regulator-name = "Vbcpu";
+   regulator-min-microvolt = <30>;
+   regulator-max-microvolt = <1193750>;
+   regulator-enable-ramp-delay = <256>;
+   regulator-allowed-modes = <0 1 2 4>;
+   regulator-always-on;
+   };
+
+   mt6315_6_vbuck3: vbuck3 {
+   regulator-compatible = "vbuck3";
+   regulator-name = "Vlcpu";
+   regulator-min-microvolt = <30>;
+   regulator-max-microvolt = <1193750>;
+   regulator-enable-ramp-delay = <256>;
+   regulator-allowed-modes = <0 1 2 4>;
+   regulator-always-on;
+   };
+   };
+   };
+
+   mt6315_7: pmic@7 {
+   compatible = "mediatek,mt6315-regulator";
+   reg = <0x7 0>;
+
+   regulators {
+   mt6315_7_vbuck1: vbuck1 {
+   regulator-compatible = "vbuck1";
+   regulator-name = "Vgpu";
+   regulator-min-microvolt = <30>;
+   regulator-max-microvolt = <1193750>;
+   regulator-enable-ramp-delay = <256>;
+   regulator-allowed-modes = <0 1 2 4>;
+   };
+   };
+   };
+};
+
  {
status = "okay";
 };
-- 
2.18.0



[PATCH v4 0/3] Add support for MT6315 regulator

2021-02-06 Thread Hsin-Hsiung Wang
This patch series adds support for MediaTek PMIC MT6315 regulator driver,
which adds MT6315 related buck voltage data to the driver.
This series is based on below patch[1].

[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=429385

changes since v3:
- fix the error of binding document.
- refine the mt6315 regulator for better code quality.
- update mt6315 regulator node in the mt8192-evb.dts.

Hsin-Hsiung Wang (3):
  dt-bindings: regulator: document binding for MT6315 regulator
  regulator: mt6315: Add support for MT6315 regulator
  arm64: dts: mt8192: add mt6315 regulator nodes

 .../bindings/regulator/mt6315-regulator.yaml  |  69 
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts   |  46 +++
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/mt6315-regulator.c  | 299 ++
 include/linux/regulator/mt6315-regulator.h|  44 +++
 6 files changed, 469 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
 create mode 100644 drivers/regulator/mt6315-regulator.c
 create mode 100644 include/linux/regulator/mt6315-regulator.h

-- 
2.18.0



[PATCH v4 2/3] regulator: mt6315: Add support for MT6315 regulator

2021-02-06 Thread Hsin-Hsiung Wang
The MT6315 is a regulator found on boards based on MediaTek MT8192 and
probably other SoCs. It connects as a slave to SoC using SPMI.

Signed-off-by: Hsin-Hsiung Wang 
---
changes since v3:
- refine the mt6315 regulator for better code quality.
- remove unused registers.
---
 drivers/regulator/Kconfig  |  10 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/mt6315-regulator.c   | 299 +
 include/linux/regulator/mt6315-regulator.h |  44 +++
 4 files changed, 354 insertions(+)
 create mode 100644 drivers/regulator/mt6315-regulator.c
 create mode 100644 include/linux/regulator/mt6315-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 53fa84f4d1e1..0787a5cd64e2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -732,6 +732,16 @@ config REGULATOR_MT6311
  This driver supports the control of different power rails of device
  through regulator interface.
 
+config REGULATOR_MT6315
+   tristate "MediaTek MT6315 PMIC"
+   depends on SPMI
+   select REGMAP_SPMI
+   help
+ Say y here to select this option to enable the power regulator of
+ MediaTek MT6315 PMIC.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
 config REGULATOR_MT6323
tristate "MediaTek MT6323 PMIC"
depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 680e539f6579..c50797e5f1f8 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_MP8859) += mp8859.o
 obj-$(CONFIG_REGULATOR_MP886X) += mp886x.o
 obj-$(CONFIG_REGULATOR_MPQ7920) += mpq7920.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
+obj-$(CONFIG_REGULATOR_MT6315) += mt6315-regulator.o
 obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
 obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
diff --git a/drivers/regulator/mt6315-regulator.c 
b/drivers/regulator/mt6315-regulator.c
new file mode 100644
index ..d49a1534d8e9
--- /dev/null
+++ b/drivers/regulator/mt6315-regulator.c
@@ -0,0 +1,299 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2021 MediaTek Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MT6315_BUCK_MODE_AUTO  0
+#define MT6315_BUCK_MODE_FORCE_PWM 1
+#define MT6315_BUCK_MODE_LP2
+
+struct mt6315_regulator_info {
+   struct regulator_desc desc;
+   u32 status_reg;
+   u32 lp_mode_mask;
+   u32 lp_mode_shift;
+};
+
+struct mt_regulator_init_data {
+   u32 modeset_mask[MT6315_VBUCK_MAX];
+};
+
+struct mt6315_chip {
+   struct device *dev;
+   struct regmap *regmap;
+};
+
+#define MT_BUCK(_name, _bid, _vsel)\
+[_bid] = { \
+   .desc = {   \
+   .name = _name,  \
+   .of_match = of_match_ptr(_name),\
+   .regulators_node = "regulators",\
+   .ops = _volt_range_ops,  \
+   .type = REGULATOR_VOLTAGE,  \
+   .id = _bid, \
+   .owner = THIS_MODULE,   \
+   .n_voltages = 0xbf, \
+   .linear_ranges = mt_volt_range1,\
+   .n_linear_ranges = ARRAY_SIZE(mt_volt_range1),  \
+   .vsel_reg = _vsel,  \
+   .vsel_mask = 0xff,  \
+   .enable_reg = MT6315_BUCK_TOP_CON0, \
+   .enable_mask = BIT(_bid),   \
+   .of_map_mode = mt6315_map_mode, \
+   },  \
+   .status_reg = _bid##_DBG4,  \
+   .lp_mode_mask = BIT(_bid),  \
+   .lp_mode_shift = _bid,  \
+}
+
+static const struct linear_range mt_volt_range1[] = {
+   REGULATOR_LINEAR_RANGE(0, 0, 0xbf, 6250),
+};
+
+static unsigned int mt6315_map_mode(u32 mode)
+{
+   switch (mode) {
+   case MT6315_BUCK_MODE_AUTO:
+   return REGULATOR_MODE_NORMAL;
+   case MT6315_BUCK_MODE_FORCE_PWM:
+   return REGULATOR_MODE_FAST;
+   case MT6315_BUCK_MODE_LP:
+   return REGULATOR_MODE_IDLE;
+   default:
+   return -EINVAL;
+   }
+}
+
+static unsigned int mt6315_regulator_get_mode(struct regulator_dev *rdev)
+{
+   struct mt_regulator_init_data *init = rdev_get_drvdata(rdev);
+   const struct 

[PATCH v4 1/3] dt-bindings: regulator: document binding for MT6315 regulator

2021-02-06 Thread Hsin-Hsiung Wang
Add device tree binding information for MT6315 regulator driver.
Example bindings for MT6315 are added.

Signed-off-by: Hsin-Hsiung Wang 
---
changes since v3:
- correct the yaml file name.
- remove unused description.
- update the example.
---
 .../bindings/regulator/mt6315-regulator.yaml  | 69 +++
 1 file changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml

diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
new file mode 100644
index ..61dd5af80db6
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mt6315-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT6315 Regulator
+
+maintainers:
+  - Hsin-Hsiung Wang 
+
+description: |
+  The MT6315 is a power management IC (PMIC) configurable with SPMI.
+  that contains 4 BUCKs output which can combine with each other
+  by different efuse settings.
+
+properties:
+  compatible:
+const: mediatek,mt6315-regulator
+
+  reg:
+maxItems: 1
+
+  regulators:
+type: object
+description: List of regulators and its properties
+
+patternProperties:
+  "^vbuck[1-4]$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^vbuck[1-4]$"
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - regulators
+
+additionalProperties: false
+
+examples:
+  - |
+pmic@6 {
+  compatible = "mediatek,mt6315-regulator";
+  reg = <0x6 0>;
+
+  regulators {
+vbuck1 {
+  regulator-compatible = "vbuck1";
+  regulator-min-microvolt = <30>;
+  regulator-max-microvolt = <1193750>;
+  regulator-enable-ramp-delay = <256>;
+  regulator-allowed-modes = <0 1 2 4>;
+};
+
+vbuck3 {
+  regulator-compatible = "vbuck3";
+  regulator-min-microvolt = <30>;
+  regulator-max-microvolt = <1193750>;
+  regulator-enable-ramp-delay = <256>;
+  regulator-allowed-modes = <0 1 2 4>;
+};
+  };
+};
-- 
2.18.0



[PATCH v6 2/4] dt-bindings: spmi: document binding for the Mediatek SPMI controller

2021-02-06 Thread Hsin-Hsiung Wang
This adds documentation for the SPMI controller found on Mediatek SoCs.

Signed-off-by: Hsin-Hsiung Wang 
Reviewed-by: Rob Herring 
---
changes since v5: no changes
---
 .../bindings/spmi/mtk,spmi-mtk-pmif.yaml  | 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml

diff --git a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml 
b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
new file mode 100644
index ..a43b0302d503
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spmi/mtk,spmi-mtk-pmif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek SPMI Controller Device Tree Bindings
+
+maintainers:
+  - Hsin-Hsiung Wang 
+
+description: |+
+  On MediaTek SoCs the PMIC is connected via SPMI and the controller allows
+  for multiple SoCs to control a single SPMI master.
+
+allOf:
+  - $ref: "spmi.yaml"
+
+properties:
+  compatible:
+const: mediatek,mt6873-spmi
+
+  reg:
+maxItems: 2
+
+  reg-names:
+items:
+  - const: pmif
+  - const: spmimst
+
+  clocks:
+minItems: 3
+maxItems: 3
+
+  clock-names:
+items:
+  - const: pmif_sys_ck
+  - const: pmif_tmr_ck
+  - const: spmimst_clk_mux
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-parents:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+spmi: spmi@10027000 {
+compatible = "mediatek,mt6873-spmi";
+reg = <0 0x10027000 0 0x000e00>,
+  <0 0x10029000 0 0x000100>;
+reg-names = "pmif", "spmimst";
+clocks = < CLK_INFRA_PMIC_AP>,
+ < CLK_INFRA_PMIC_TMR>,
+ < CLK_TOP_SPMI_MST_SEL>;
+clock-names = "pmif_sys_ck",
+  "pmif_tmr_ck",
+  "spmimst_clk_mux";
+assigned-clocks = < CLK_TOP_PWRAP_ULPOSC_SEL>;
+assigned-clock-parents = < CLK_TOP_OSC_D10>;
+};
+...
-- 
2.18.0



[PATCH v6 3/4] spmi: mediatek: Add support for MT6873/8192

2021-02-06 Thread Hsin-Hsiung Wang
Add spmi support for MT6873/8192.

Signed-off-by: Hsin-Hsiung Wang 
---
changes since v5:
- add a newline at end of Makefile.
- refine the spmi-mtk-pmif driver for better code quality. 
---
 drivers/spmi/Kconfig |   9 +
 drivers/spmi/Makefile|   2 +
 drivers/spmi/spmi-mtk-pmif.c | 488 +++
 3 files changed, 499 insertions(+)
 create mode 100644 drivers/spmi/spmi-mtk-pmif.c

diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
index a53bad541f1a..418848840999 100644
--- a/drivers/spmi/Kconfig
+++ b/drivers/spmi/Kconfig
@@ -25,4 +25,13 @@ config SPMI_MSM_PMIC_ARB
  This is required for communicating with Qualcomm PMICs and
  other devices that have the SPMI interface.
 
+config SPMI_MTK_PMIF
+   tristate "Mediatek SPMI Controller (PMIC Arbiter)"
+   help
+ If you say yes to this option, support will be included for the
+ built-in SPMI PMIC Arbiter interface on Mediatek family
+ processors.
+
+ This is required for communicating with Mediatek PMICs and
+ other devices that have the SPMI interface.
 endif
diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
index 55a94cadeffe..76fb3b3ab510 100644
--- a/drivers/spmi/Makefile
+++ b/drivers/spmi/Makefile
@@ -5,3 +5,5 @@
 obj-$(CONFIG_SPMI) += spmi.o
 
 obj-$(CONFIG_SPMI_MSM_PMIC_ARB)+= spmi-pmic-arb.o
+obj-$(CONFIG_SPMI_MTK_PMIF)+= spmi-mtk-pmif.o
+
diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
new file mode 100644
index ..4ac4643f89f3
--- /dev/null
+++ b/drivers/spmi/spmi-mtk-pmif.c
@@ -0,0 +1,488 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2021 MediaTek Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SWINF_IDLE 0x00
+#define SWINF_WFVLDCLR 0x06
+
+#define GET_SWINF(x)   (((x) >> 1) & 0x7)
+
+#define PMIF_CMD_REG_0 0
+#define PMIF_CMD_REG   1
+#define PMIF_CMD_EXT_REG   2
+#define PMIF_CMD_EXT_REG_LONG  3
+
+#define PMIF_DELAY_US   10
+#define PMIF_TIMEOUT_US (10 * 1000)
+
+#define PMIF_CHAN_OFFSET 0x5
+
+#define PMIF_MAX_CLKS  3
+
+#define SPMI_OP_ST_BUSY 1
+
+struct ch_reg {
+   u32 ch_sta;
+   u32 wdata;
+   u32 rdata;
+   u32 ch_send;
+   u32 ch_rdy;
+};
+
+struct pmif_data {
+   const u32   *regs;
+   const u32   *spmimst_regs;
+   u32 soc_chan;
+};
+
+struct pmif {
+   void __iomem*base;
+   void __iomem*spmimst_base;
+   raw_spinlock_t  lock;
+   struct ch_reg   chan;
+   struct clk_bulk_data clks[PMIF_MAX_CLKS];
+   u32 nclks;
+   const struct pmif_data *data;
+};
+
+static const char * const pmif_clock_names[] = {
+   "pmif_sys_ck", "pmif_tmr_ck", "spmimst_clk_mux",
+};
+
+enum pmif_regs {
+   PMIF_INIT_DONE,
+   PMIF_INF_EN,
+   PMIF_ARB_EN,
+   PMIF_CMDISSUE_EN,
+   PMIF_TIMER_CTRL,
+   PMIF_SPI_MODE_CTRL,
+   PMIF_IRQ_EVENT_EN_0,
+   PMIF_IRQ_FLAG_0,
+   PMIF_IRQ_CLR_0,
+   PMIF_IRQ_EVENT_EN_1,
+   PMIF_IRQ_FLAG_1,
+   PMIF_IRQ_CLR_1,
+   PMIF_IRQ_EVENT_EN_2,
+   PMIF_IRQ_FLAG_2,
+   PMIF_IRQ_CLR_2,
+   PMIF_IRQ_EVENT_EN_3,
+   PMIF_IRQ_FLAG_3,
+   PMIF_IRQ_CLR_3,
+   PMIF_IRQ_EVENT_EN_4,
+   PMIF_IRQ_FLAG_4,
+   PMIF_IRQ_CLR_4,
+   PMIF_WDT_EVENT_EN_0,
+   PMIF_WDT_FLAG_0,
+   PMIF_WDT_EVENT_EN_1,
+   PMIF_WDT_FLAG_1,
+   PMIF_SWINF_0_STA,
+   PMIF_SWINF_0_WDATA_31_0,
+   PMIF_SWINF_0_RDATA_31_0,
+   PMIF_SWINF_0_ACC,
+   PMIF_SWINF_0_VLD_CLR,
+   PMIF_SWINF_1_STA,
+   PMIF_SWINF_1_WDATA_31_0,
+   PMIF_SWINF_1_RDATA_31_0,
+   PMIF_SWINF_1_ACC,
+   PMIF_SWINF_1_VLD_CLR,
+   PMIF_SWINF_2_STA,
+   PMIF_SWINF_2_WDATA_31_0,
+   PMIF_SWINF_2_RDATA_31_0,
+   PMIF_SWINF_2_ACC,
+   PMIF_SWINF_2_VLD_CLR,
+   PMIF_SWINF_3_STA,
+   PMIF_SWINF_3_WDATA_31_0,
+   PMIF_SWINF_3_RDATA_31_0,
+   PMIF_SWINF_3_ACC,
+   PMIF_SWINF_3_VLD_CLR,
+};
+
+static const u32 mt6873_regs[] = {
+   [PMIF_INIT_DONE] =  0x,
+   [PMIF_INF_EN] = 0x0024,
+   [PMIF_ARB_EN] = 0x0150,
+   [PMIF_CMDISSUE_EN] =0x03B4,
+   [PMIF_TIMER_CTRL] = 0x03E0,
+   [PMIF_SPI_MODE_CTRL] =  0x0400,
+   [PMIF_IRQ_EVENT_EN_0] = 0x0418,
+   [PMIF_IRQ_FLAG_0] = 0x0420,
+   [PMIF_IRQ_CLR_0] =  0x0424,
+   [PMIF_IRQ_EVENT_EN_1] = 0x0428,
+   [PMIF_IRQ_FLAG_1] = 0x0430,
+   [PMIF_IRQ_CLR_1] =  0x0434,
+   [PMIF_IRQ_EVENT_EN_2] = 0x0438,
+   [PMIF_IRQ_FLAG_2] = 0x0440,
+   [PMIF_IRQ_CLR_2] =  0x0444,
+   [PMIF_IRQ_EVENT_EN_3] = 0x0448,
+   [PMIF_IRQ_FLAG_3] = 0x0450,
+   [PMIF_IRQ_CLR_3] =  0x0454,
+   [PMIF_IRQ_EVENT_EN_4] = 0x0458,
+   [PMIF_IRQ_FLAG_4] = 0x0460,
+   [PMIF_IRQ_CLR_4] =  0x0464,
+   [PMIF_WDT_EVENT_EN_0] = 0x046C,
+   [PMIF_WDT_FLAG_0] = 

[PATCH v6 4/4] arm64: dts: mt8192: add spmi node

2021-02-06 Thread Hsin-Hsiung Wang
Add spmi node to SOC MT8192.

Signed-off-by: Hsin-Hsiung Wang 
---
changes since v5:
- fix the build error of MT8192.dtsi.
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index e12e024de122..5e002512441f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -247,6 +247,23 @@
clock-names = "clk13m";
};
 
+   spmi: spmi@10027000 {
+   compatible = "mediatek,mt6873-spmi";
+   reg = <0 0x10027000 0 0x000e00>,
+ <0 0x10029000 0 0x000100>;
+   reg-names = "pmif", "spmimst";
+   clocks = < CLK_INFRA_PMIC_AP>,
+< CLK_INFRA_PMIC_TMR>,
+< CLK_TOP_SPMI_MST_SEL>;
+   clock-names = "pmif_sys_ck",
+ "pmif_tmr_ck",
+ "spmimst_clk_mux";
+   assigned-clocks = < CLK_TOP_PWRAP_ULPOSC_SEL>;
+   assigned-clock-parents = < CLK_TOP_OSC_D10>;
+   #address-cells = <2>;
+   #size-cells = <0>;
+   };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8192-uart",
 "mediatek,mt6577-uart";
-- 
2.18.0



[PATCH v6 1/4] dt-bindings: spmi: modify the constraint 'maxItems' to 'minItems'

2021-02-06 Thread Hsin-Hsiung Wang
The constraint of 'maxItem: 1' might be larger than 1, so we modify it
to 'minItem: 1'.

Signed-off-by: Hsin-Hsiung Wang 
---
changes since v5:
- update the constraint of minItem to 1.
---
 Documentation/devicetree/bindings/spmi/spmi.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spmi/spmi.yaml 
b/Documentation/devicetree/bindings/spmi/spmi.yaml
index 173940930719..12dbf6567d16 100644
--- a/Documentation/devicetree/bindings/spmi/spmi.yaml
+++ b/Documentation/devicetree/bindings/spmi/spmi.yaml
@@ -25,7 +25,7 @@ properties:
 pattern: "^spmi@.*"
 
   reg:
-maxItems: 1
+minItems: 1
 
   "#address-cells":
 const: 2
-- 
2.18.0



[PATCH v6 0/4] Add SPMI support for Mediatek MT6873/8192 SoC IC

2021-02-06 Thread Hsin-Hsiung Wang
This series adds support for new SoC MT6873/8192 to the spmi driver.
This series is based on Weiyi's patches[1].

[1] 
https://patchwork.kernel.org/project/linux-mediatek/patch/1608642587-15634-7-git-send-email-weiyi...@mediatek.com/

changes since v5:
- fix the yaml error.
- refine the spmi-mtk-pmif driver for better code quality.
- fix the build error about MT8192.dtsi

Hsin-Hsiung Wang (4):
  dt-bindings: spmi: modify the constraint 'maxItems' to 'minItems'
  dt-bindings: spmi: document binding for the Mediatek SPMI controller
  spmi: mediatek: Add support for MT6873/8192
  arm64: dts: mt8192: add spmi node

 .../bindings/spmi/mtk,spmi-mtk-pmif.yaml  |  74 +++
 .../devicetree/bindings/spmi/spmi.yaml|   2 +-
 arch/arm64/boot/dts/mediatek/mt8192.dtsi  |  17 +
 drivers/spmi/Kconfig  |   9 +
 drivers/spmi/Makefile |   2 +
 drivers/spmi/spmi-mtk-pmif.c  | 488 ++
 6 files changed, 591 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
 create mode 100644 drivers/spmi/spmi-mtk-pmif.c

-- 
2.18.0



Re: [PATCH] drm/msm/dp: Add a missing semi-colon

2021-02-06 Thread Joe Perches
On Sat, 2021-02-06 at 20:18 -0800, Stephen Boyd wrote:
> A missing semicolon here causes my external display to stop working.
> Indeed, missing the semicolon on the return statement leads to
> dp_panel_update_tu_timings() not existing because the compiler thinks
> it's part of the return statement of a void function, so it must not be
> important.
> 
>   $ ./scripts/bloat-o-meter before.o after.o
>   add/remove: 1/1 grow/shrink: 0/1 up/down: 7400/-7540 (-140)
>   Function old new   delta
>   dp_panel_update_tu_timings -7400   +7400
>   _dp_ctrl_calc_tu.constprop 18024   17900-124
>   dp_panel_update_tu_timings.constprop7416   -   -7416
>   Total: Before=54440, After=54300, chg -0.26%
> 
> Add a semicolon so this function works like it used to.
[]
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c 
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
[]
> @@ -631,7 +631,7 @@ static void _dp_ctrl_calc_tu(struct dp_tu_calc_input *in,
>  
> 
>   tu = kzalloc(sizeof(*tu), GFP_KERNEL);
>   if (!tu)
> - return
> + return;
>  
> 
>   dp_panel_update_tu_timings(in, tu);

Wow, that's really unfortunate that dp_panel_update_tu_timings
is also void.

Perhaps this as YA checkpatch warning:

---
 scripts/checkpatch.pl | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9a549b009d2f..6df13e5a1557 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3674,6 +3674,12 @@ sub process {
}
}
 
+# check only a c90 keyword on the line (except else)
+   if ($sline =~ /^\+\s*($c90_Keywords)\s*$/ && $1 ne 'else') {
+   WARN("BARE_KEYWORD",
+"'$1' as the only word on a line is not good 
style\n" . $herecurr);
+   }
+
 # check multi-line statement indentation matches previous line
if ($perl_version_ok &&
$prevline =~ /^\+([ 
\t]*)((?:$c90_Keywords(?:\s+if)\s*)|(?:$Declare\s*)?(?:$Ident|\(\s*\*\s*$Ident\s*\))\s*|(?:\*\s*)*$Lval\s*=\s*$Ident\s*)\(.*(\&\&|\|\||,)\s*$/)
 {




[PATCH v2] KVM: x86/MMU: Do not check unsync status for root SP.

2021-02-06 Thread Yu Zhang
In shadow page table, only leaf SPs may be marked as unsync.
And for non-leaf SPs, we use unsync_children to keep the number
of the unsynced children. In kvm_mmu_sync_root(), sp->unsync
shall always be zero for the root SP, , hence no need to check
it. Instead, a warning inside mmu_sync_children() is added, in
case someone incorrectly used it.

Also, clarify the mmu_need_write_protect(), by moving the warning
into kvm_unsync_page().

Signed-off-by: Yu Zhang 
Signed-off-by: Sean Christopherson 
---
Changes in V2:
- warnings added based on Sean's suggestion.

 arch/x86/kvm/mmu/mmu.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 86af582..c4797a00cc 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1995,6 +1995,12 @@ static void mmu_sync_children(struct kvm_vcpu *vcpu,
LIST_HEAD(invalid_list);
bool flush = false;
 
+   /*
+* Only 4k SPTEs can directly be made unsync, the parent pages
+* should never be unsyc'd.
+*/
+   WARN_ON_ONCE(sp->unsync);
+
while (mmu_unsync_walk(parent, )) {
bool protected = false;
 
@@ -2502,6 +2508,8 @@ int kvm_mmu_unprotect_page(struct kvm *kvm, gfn_t gfn)
 
 static void kvm_unsync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp)
 {
+   WARN_ON(sp->role.level != PG_LEVEL_4K);
+
trace_kvm_mmu_unsync_page(sp);
++vcpu->kvm->stat.mmu_unsync;
sp->unsync = 1;
@@ -2524,7 +2532,6 @@ bool mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t 
gfn,
if (sp->unsync)
continue;
 
-   WARN_ON(sp->role.level != PG_LEVEL_4K);
kvm_unsync_page(vcpu, sp);
}
 
@@ -3406,8 +3413,7 @@ void kvm_mmu_sync_roots(struct kvm_vcpu *vcpu)
 * mmu_need_write_protect() describe what could go wrong if this
 * requirement isn't satisfied.
 */
-   if (!smp_load_acquire(>unsync) &&
-   !smp_load_acquire(>unsync_children))
+   if (!smp_load_acquire(>unsync_children))
return;
 
write_lock(>kvm->mmu_lock);
-- 
1.9.1



Re: [PATCH] printk: Userspace format enumeration support

2021-02-06 Thread Joe Perches
On Sat, 2021-02-06 at 21:21 +, Chris Down wrote:
> Joe Perches writes:
> > On Fri, 2021-02-05 at 22:25 +, Chris Down wrote:
> > > Petr Mladek writes:
> > > >   +  is already optinaly added by pr_fmt() to the printed 
> > > > strings
> > > > as:  pr_fmt(): ...
> > > 
> > > pr_fmts are not consistently used across the kernel, and sometimes differ 
> > > from
> > > the module itself. Many modules don't use it at all, and we also don't 
> > > have it
> > > for pr_cont. Just picking some random examples:
> > > 
> > >  % grep -av vmlinux /proc/printk_formats | shuf -n 10
> > >  mac80211,6%s: mesh STA %pM switches to channel requiring DFS (%d 
> > > MHz, width:%d, CF1/2: %d/%d MHz), aborting
> > >  thinkpad_acpi,c N/Athinkpad_acpi,c %dthinkpad_acpi,5thinkpad_acpi: 
> > > temperatures (Celsius):thinkpad_acpi,3thinkpad_acpi: Out of memory for 
> > > LED data
> > 
> > I don't understand this format.
> > 
> > "Out of memory for LED data" is a single printk ending with a '\n' newline
> > I expected this to be broken up into multiple lines, one for each printk
> > that endsd in a newline.
> 
> Hmm, that's just a manifestation of directly using `shuf` without doing the 
> transformation of trailing nulls to newlines shown in the changelog. They are 
> still distinct and separated by nulls.
> 
> > And what would happen if the function was refactored removing the pr_cont
> > uses like the below: (basically, any output that uses a mechanism that
> > aggregates a buffer then emits it, and there are a _lot_ of those)
> > 
> > printk("%s\n", buffer);
> 
> There are certainly printks which can't be trivially monitored using the 
> printk 
> format alone, but the vast majority of the ones that are monitored _do_ have 
> meaningful formats and can be monitored over time. No solution to this is 
> going 
> to catch every single case, especially when so much of the information can be 
> generated dyamically, but this patchset still goes a long way to making 
> printk 
> monitoring more tractable for use cases like the one described in the 
> changelog.

For the _vast_ majority of printk strings, this can easily be found
and compared using a trivial modification to strings.

Module specific formats are stored in the .ko files and could be
examined separately.

Here's the possible patch to strings:

---
 binutils/strings.c | 98 +-
 1 file changed, 82 insertions(+), 16 deletions(-)

diff --git a/binutils/strings.c b/binutils/strings.c
index 3444fbc7222..d4abeb0cdbb 100644
--- a/binutils/strings.c
+++ b/binutils/strings.c
@@ -26,6 +26,10 @@
--data
-d  Scan only the initialized data section(s) of object files.
 
+   --section=
+   -S  Scan only the specific section(s)
+   --kernel
+   -k  Scan only linux-kernel KERN_SOH strings
--print-file-name
-f  Print the name of the file before each string.
 
@@ -108,6 +112,14 @@ static bfd_boolean print_filenames;
 /* TRUE means for object files scan only the data section.  */
 static bfd_boolean datasection_only;
 
+/* TRUE means for object files scan only the specified sections.  */
+static bfd_boolean specified_sections_only;
+static int specified_sections_count;
+static char **specified_sections;
+
+/* TRUE means scan only linux-kernel printk strings with KERN_SOH.  */
+static bfd_boolean linux_kernel_soh;
+
 /* The BFD object file format.  */
 static char *target;
 
@@ -122,6 +134,8 @@ static struct option long_options[] =
 {
   {"all", no_argument, NULL, 'a'},
   {"data", no_argument, NULL, 'd'},
+  {"section", required_argument, NULL, 'S'},
+  {"kernel", no_argument, NULL, 'k'},
   {"print-file-name", no_argument, NULL, 'f'},
   {"bytes", required_argument, NULL, 'n'},
   {"radix", required_argument, NULL, 't'},
@@ -173,7 +187,7 @@ main (int argc, char **argv)
   encoding = 's';
   output_separator = NULL;
 
-  while ((optc = getopt_long (argc, argv, "adfhHn:wot:e:T:s:Vv0123456789",
+  while ((optc = getopt_long (argc, argv, "adS:s:kfhHn:wot:e:T:s:Vv0123456789",
  long_options, (int *) 0)) != EOF)
 {
   switch (optc)
@@ -186,6 +200,17 @@ main (int argc, char **argv)
  datasection_only = TRUE;
  break;
 
+   case 'S':
+ specified_sections_only = TRUE;
+ specified_sections = xrealloc(specified_sections,
+   (specified_sections_count + 1) * 
sizeof(const char *));
+ specified_sections[specified_sections_count++] = optarg;
+ break;
+
+   case 'k':
+ linux_kernel_soh = TRUE;
+ break;
+
case 'f':
  print_filenames = TRUE;
  break;
@@ -318,6 +343,19 @@ main (int argc, char **argv)
   return (exit_status);
 }
 
+static bfd_boolean
+section_is_specified_section (asection *sect)
+{
+  int i;
+  for (i = 0; i < specified_sections_count; i++)
+{
+  if (strcmp(specified_sections[i], sect->name) == 0) {
+   

[PATCH v2 net-next] net: socket: use BIT() for MSG_*

2021-02-06 Thread menglong8 . dong
From: Menglong Dong 

The bit mask for MSG_* seems a little confused here. Replace it
with BIT() to make it clear to understand.

Changes since v1:
- use BIT() instead of BIT_MASK()

Signed-off-by: Menglong Dong 
---
 include/linux/socket.h | 71 ++
 1 file changed, 37 insertions(+), 34 deletions(-)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 385894b4a8bb..e88859f38cd0 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -283,42 +283,45 @@ struct ucred {
Added those for 1003.1g not all are supported yet
  */
 
-#define MSG_OOB1
-#define MSG_PEEK   2
-#define MSG_DONTROUTE  4
-#define MSG_TRYHARD 4   /* Synonym for MSG_DONTROUTE for DECnet */
-#define MSG_CTRUNC 8
-#define MSG_PROBE  0x10/* Do not send. Only probe path f.e. for MTU */
-#define MSG_TRUNC  0x20
-#define MSG_DONTWAIT   0x40/* Nonblocking io*/
-#define MSG_EOR 0x80   /* End of record */
-#define MSG_WAITALL0x100   /* Wait for a full request */
-#define MSG_FIN 0x200
-#define MSG_SYN0x400
-#define MSG_CONFIRM0x800   /* Confirm path validity */
-#define MSG_RST0x1000
-#define MSG_ERRQUEUE   0x2000  /* Fetch message from error queue */
-#define MSG_NOSIGNAL   0x4000  /* Do not generate SIGPIPE */
-#define MSG_MORE   0x8000  /* Sender will send more */
-#define MSG_WAITFORONE 0x1 /* recvmmsg(): block until 1+ packets avail */
-#define MSG_SENDPAGE_NOPOLICY 0x1 /* sendpage() internal : do no apply 
policy */
-#define MSG_SENDPAGE_NOTLAST 0x2 /* sendpage() internal : not the last 
page */
-#define MSG_BATCH  0x4 /* sendmmsg(): more messages coming */
-#define MSG_EOF MSG_FIN
-#define MSG_NO_SHARED_FRAGS 0x8 /* sendpage() internal : page frags are 
not shared */
-#define MSG_SENDPAGE_DECRYPTED 0x10 /* sendpage() internal : page may carry
- * plain text and require encryption
- */
-
-#define MSG_ZEROCOPY   0x400   /* Use user data in kernel path */
-#define MSG_FASTOPEN   0x2000  /* Send data in TCP SYN */
-#define MSG_CMSG_CLOEXEC 0x4000/* Set close_on_exec for file
-  descriptor received through
-  SCM_RIGHTS */
+#define MSG_OOBBIT(0)
+#define MSG_PEEK   BIT(1)
+#define MSG_DONTROUTE  BIT(2)
+#define MSG_TRYHARDBIT(2)  /* Synonym for MSG_DONTROUTE for DECnet 
*/
+#define MSG_CTRUNC BIT(3)
+#define MSG_PROBE  BIT(4)  /* Do not send. Only probe path f.e. for MTU
*/
+#define MSG_TRUNC  BIT(5)
+#define MSG_DONTWAIT   BIT(6)  /* Nonblocking io   */
+#define MSG_EORBIT(7)  /* End of record*/
+#define MSG_WAITALLBIT(8)  /* Wait for a full request  */
+#define MSG_FINBIT(9)
+#define MSG_SYNBIT(10)
+#define MSG_CONFIRMBIT(11) /* Confirm path validity*/
+#define MSG_RSTBIT(12)
+#define MSG_ERRQUEUE   BIT(13) /* Fetch message from error queue */
+#define MSG_NOSIGNAL   BIT(14) /* Do not generate SIGPIPE  */
+#define MSG_MORE   BIT(15) /* Sender will send more*/
+#define MSG_WAITFORONE BIT(16) /* recvmmsg(): block until 1+ packets avail */
+#define MSG_SENDPAGE_NOPOLICY  BIT(16) /* sendpage() internal : do no apply 
policy */
+#define MSG_SENDPAGE_NOTLAST   BIT(17) /* sendpage() internal : not the last 
page  */
+#define MSG_BATCH  BIT(18) /* sendmmsg(): more messages coming */
+#define MSG_EOFMSG_FIN
+#define MSG_NO_SHARED_FRAGSBIT(19) /* sendpage() internal : page frags
+* are not shared
+*/
+#define MSG_SENDPAGE_DECRYPTED BIT(20) /* sendpage() internal : page may carry
+* plain text and require encryption
+*/
+
+#define MSG_ZEROCOPY   BIT(26) /* Use user data in kernel path */
+#define MSG_FASTOPEN   BIT(29) /* Send data in TCP SYN */
+#define MSG_CMSG_CLOEXEC   BIT(30) /* Set close_on_exec for file
+* descriptor received through
+* SCM_RIGHTS
+*/
 #if defined(CONFIG_COMPAT)
-#define MSG_CMSG_COMPAT0x8000  /* This message needs 32 bit 
fixups */
+#define MSG_CMSG_COMPATBIT(31) /* This message needs 32 bit fixups */
 #else
-#define MSG_CMSG_COMPAT0   /* We never have 32 bit fixups 
*/
+#define MSG_CMSG_COMPAT0   /* We never have 32 bit fixups */
 #endif
 
 
-- 
2.25.1



Re: [PATCH 2/5] lib/test_bitmap.c: Add for_each_set_clump test cases

2021-02-06 Thread Syed Nayyar Waris
On Thu, Feb 4, 2021 at 2:25 PM Syed Nayyar Waris  wrote:
>
> On Sat, Dec 26, 2020 at 8:15 PM Andy Shevchenko
>  wrote:
> >
> >
> >
> > On Saturday, December 26, 2020, Syed Nayyar Waris  
> > wrote:
> >>
> >> The introduction of the generic for_each_set_clump macro need test
> >> cases to verify the implementation. This patch adds test cases for
> >> scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits.
> >> The cases contain situations where clump is getting split at the word
> >> boundary and also when zeroes are present in the start and middle of
> >> bitmap.
> >
> >
> > You have to split it to a separate test under drivers/gpio, because now it 
> > has no sense to be like this.
>
> Hi Andy,
>
> How do I split it into separate test under drivers/gpio ? I have
> thought of making a test_clump_bits.c file in drivers/gpio.
> But how do I integrate this test file so that tests are executed at
> runtime? Similar to tests in lib/test_bitmap.c ?
>
> I believe I need to make changes in config files so that tests in
> test_clump_bits.c ( in drivers/gpio ) are executed at runtime. Could
> you please provide some steps on how to do that. Thank You !
>
> Regards
> Syed Nayyar Waris

Hi Andy, could you please help me on the above. Thanks !

Regards
Syed Nayyar Waris


[PATCH] drm/msm/dp: Add a missing semi-colon

2021-02-06 Thread Stephen Boyd
A missing semicolon here causes my external display to stop working.
Indeed, missing the semicolon on the return statement leads to
dp_panel_update_tu_timings() not existing because the compiler thinks
it's part of the return statement of a void function, so it must not be
important.

  $ ./scripts/bloat-o-meter before.o after.o
  add/remove: 1/1 grow/shrink: 0/1 up/down: 7400/-7540 (-140)
  Function old new   delta
  dp_panel_update_tu_timings -7400   +7400
  _dp_ctrl_calc_tu.constprop 18024   17900-124
  dp_panel_update_tu_timings.constprop7416   -   -7416
  Total: Before=54440, After=54300, chg -0.26%

Add a semicolon so this function works like it used to.

Cc: Sean Paul 
Cc: Kuogee Hsieh 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: Lee Jones 
Fixes: cc9014bf63a4 ("drm/msm/dp/dp_ctrl: Move 'tu' from the stack to the heap")
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 55b7d0edffbf..95913db97616 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -631,7 +631,7 @@ static void _dp_ctrl_calc_tu(struct dp_tu_calc_input *in,
 
tu = kzalloc(sizeof(*tu), GFP_KERNEL);
if (!tu)
-   return
+   return;
 
dp_panel_update_tu_timings(in, tu);
 

base-commit: ce5226625a694fa5a46db241ac4c77a1430e37fe
-- 
https://chromeos.dev



Re: [PATCH v28 06/12] fs,security: Add sb_delete hook

2021-02-06 Thread Serge E. Hallyn
On Fri, Feb 05, 2021 at 03:57:37PM +0100, Mickaël Salaün wrote:
> 
> On 05/02/2021 15:21, Serge E. Hallyn wrote:
> > On Tue, Feb 02, 2021 at 05:27:04PM +0100, Mickaël Salaün wrote:
> >> From: Mickaël Salaün 
> >>
> >> The sb_delete security hook is called when shutting down a superblock,
> >> which may be useful to release kernel objects tied to the superblock's
> >> lifetime (e.g. inodes).
> >>
> >> This new hook is needed by Landlock to release (ephemerally) tagged
> >> struct inodes.  This comes from the unprivileged nature of Landlock
> >> described in the next commit.
> >>
> >> Cc: Al Viro 
> >> Cc: James Morris 
> >> Cc: Kees Cook 
> >> Cc: Serge E. Hallyn 
> > 
> > One note below, but
> > 
> > Acked-by: Serge Hallyn 
> > 
> >> Signed-off-by: Mickaël Salaün 
> >> Reviewed-by: Jann Horn 
> >> ---
> >>
> >> Changes since v22:
> >> * Add Reviewed-by: Jann Horn 
> >>
> >> Changes since v17:
> >> * Initial patch to replace the direct call to landlock_release_inodes()
> >>   (requested by James Morris).
> >>   
> >> https://lore.kernel.org/lkml/alpine.lrh.2.21.2005150536440.7...@namei.org/
> >> ---
> >>  fs/super.c| 1 +
> >>  include/linux/lsm_hook_defs.h | 1 +
> >>  include/linux/lsm_hooks.h | 2 ++
> >>  include/linux/security.h  | 4 
> >>  security/security.c   | 5 +
> >>  5 files changed, 13 insertions(+)
> >>
> >> diff --git a/fs/super.c b/fs/super.c
> >> index 2c6cdea2ab2d..c3c5178cde65 100644
> >> --- a/fs/super.c
> >> +++ b/fs/super.c
> >> @@ -454,6 +454,7 @@ void generic_shutdown_super(struct super_block *sb)
> >>evict_inodes(sb);
> >>/* only nonzero refcount inodes can have marks */
> >>fsnotify_sb_delete(sb);
> >> +  security_sb_delete(sb);
> >>  
> >>if (sb->s_dio_done_wq) {
> >>destroy_workqueue(sb->s_dio_done_wq);
> >> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> >> index 7aaa753b8608..32472b3849bc 100644
> >> --- a/include/linux/lsm_hook_defs.h
> >> +++ b/include/linux/lsm_hook_defs.h
> >> @@ -59,6 +59,7 @@ LSM_HOOK(int, 0, fs_context_dup, struct fs_context *fc,
> >>  LSM_HOOK(int, -ENOPARAM, fs_context_parse_param, struct fs_context *fc,
> >> struct fs_parameter *param)
> >>  LSM_HOOK(int, 0, sb_alloc_security, struct super_block *sb)
> >> +LSM_HOOK(void, LSM_RET_VOID, sb_delete, struct super_block *sb)
> >>  LSM_HOOK(void, LSM_RET_VOID, sb_free_security, struct super_block *sb)
> >>  LSM_HOOK(void, LSM_RET_VOID, sb_free_mnt_opts, void *mnt_opts)
> >>  LSM_HOOK(int, 0, sb_eat_lsm_opts, char *orig, void **mnt_opts)
> >> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> >> index 970106d98306..e339b201f79b 100644
> >> --- a/include/linux/lsm_hooks.h
> >> +++ b/include/linux/lsm_hooks.h
> >> @@ -108,6 +108,8 @@
> >>   *allocated.
> >>   *@sb contains the super_block structure to be modified.
> >>   *Return 0 if operation was successful.
> >> + * @sb_delete:
> >> + *Release objects tied to a superblock (e.g. inodes).
> > 
> > It's customary here to add the line detailing the @sb argument.
> 
> What about "@sb contains the super_block structure being released."?

That's good.  Thanks.

> > 
> >>   * @sb_free_security:
> >>   *Deallocate and clear the sb->s_security field.
> >>   *@sb contains the super_block structure to be modified.
> >> diff --git a/include/linux/security.h b/include/linux/security.h
> >> index c35ea0ffccd9..c41a94e29b62 100644
> >> --- a/include/linux/security.h
> >> +++ b/include/linux/security.h
> >> @@ -288,6 +288,7 @@ void security_bprm_committed_creds(struct linux_binprm 
> >> *bprm);
> >>  int security_fs_context_dup(struct fs_context *fc, struct fs_context 
> >> *src_fc);
> >>  int security_fs_context_parse_param(struct fs_context *fc, struct 
> >> fs_parameter *param);
> >>  int security_sb_alloc(struct super_block *sb);
> >> +void security_sb_delete(struct super_block *sb);
> >>  void security_sb_free(struct super_block *sb);
> >>  void security_free_mnt_opts(void **mnt_opts);
> >>  int security_sb_eat_lsm_opts(char *options, void **mnt_opts);
> >> @@ -620,6 +621,9 @@ static inline int security_sb_alloc(struct super_block 
> >> *sb)
> >>return 0;
> >>  }
> >>  
> >> +static inline void security_sb_delete(struct super_block *sb)
> >> +{ }
> >> +
> >>  static inline void security_sb_free(struct super_block *sb)
> >>  { }
> >>  
> >> diff --git a/security/security.c b/security/security.c
> >> index 9f979d4afe6c..1b4a73b2549a 100644
> >> --- a/security/security.c
> >> +++ b/security/security.c
> >> @@ -900,6 +900,11 @@ int security_sb_alloc(struct super_block *sb)
> >>return rc;
> >>  }
> >>  
> >> +void security_sb_delete(struct super_block *sb)
> >> +{
> >> +  call_void_hook(sb_delete, sb);
> >> +}
> >> +
> >>  void security_sb_free(struct super_block *sb)
> >>  {
> >>call_void_hook(sb_free_security, sb);
> >> -- 
> >> 2.30.0


[PATCH] Input: synaptic - reverting dcb00fc799dc03fd320e123e4c81b3278c763ea5 because it breaks the touchpad for one guy on Reddit.

2021-02-06 Thread Colton Booth
I can't test myself since I don't have the correct hardware, BUT this change 
seems to work for him. I'm thinking he has an early version of the X1E which 
may use slightly different trackpad revision.

Signed-off-by: Colton Booth 
---
 drivers/input/mouse/synaptics.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index ffad142801b3..2d3f03921dbc 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -179,9 +179,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN0093", /* T480 */
"LEN0096", /* X280 */
"LEN0097", /* X280 -> ALPS trackpoint */
-   "LEN0099", /* X1 Extreme Gen 1 / P1 Gen 1 */
"LEN009b", /* T580 */
-   "LEN0402", /* X1 Extreme Gen 2 / P1 Gen 2 */
"LEN200f", /* T450s */
"LEN2044", /* L470  */
"LEN2054", /* E480 */
-- 
2.24.3 (Apple Git-128)



Re: [PATCH v2 2/2] drivers/clocksource: Fixup csky,mptimer compile error with CPU_CK610

2021-02-06 Thread Guo Ren
The same way in IRQ chip:

Link: 
https://lore.kernel.org/lkml/161245410060.1472442.13488057609914274236.b4...@kernel.org/

On Sun, Feb 7, 2021 at 11:31 AM Guo Ren  wrote:
>
> Hi Daniel,
>
> On Thu, Feb 4, 2021 at 4:48 PM Daniel Lezcano  
> wrote:
> >
> > On 04/02/2021 08:46, guo...@kernel.org wrote:
> > > From: Guo Ren 
> > >
> > > The timer-mp-csky.c only could support CPU_CK860 and it will
> > > compile error with CPU_CK610.
> > >
> > > It has been selected in arch/csky/Kconfig.
> >
> > It would be better if you fix the root cause of the compilation error.
> The timer-mp-csky.c has used specific instructions which only
> supported by CK860 and timer-mp-csky.c is only design for CK860.
>
> In arch/csky/Konfig we only select it with CK860.
> select CSKY_MPINTC if CPU_CK860
> select CSKY_MP_TIMER if CPU_CK860
>
> So here let's select timer-mp-csky.c in arch/csky/Kconfig, not in
> drivers/clocksource/Kconfig.
>
>
> --
> Best Regards
>  Guo Ren
>
> ML: https://lore.kernel.org/linux-csky/



-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/


Re: [PATCH v2 2/2] drivers/clocksource: Fixup csky,mptimer compile error with CPU_CK610

2021-02-06 Thread Guo Ren
Hi Daniel,

On Thu, Feb 4, 2021 at 4:48 PM Daniel Lezcano  wrote:
>
> On 04/02/2021 08:46, guo...@kernel.org wrote:
> > From: Guo Ren 
> >
> > The timer-mp-csky.c only could support CPU_CK860 and it will
> > compile error with CPU_CK610.
> >
> > It has been selected in arch/csky/Kconfig.
>
> It would be better if you fix the root cause of the compilation error.
The timer-mp-csky.c has used specific instructions which only
supported by CK860 and timer-mp-csky.c is only design for CK860.

In arch/csky/Konfig we only select it with CK860.
select CSKY_MPINTC if CPU_CK860
select CSKY_MP_TIMER if CPU_CK860

So here let's select timer-mp-csky.c in arch/csky/Kconfig, not in
drivers/clocksource/Kconfig.


-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/


Re: [PATCH net-next] net: socket: use BIT_MASK for MSG_*

2021-02-06 Thread Menglong Dong
Hello!

On Sat, Feb 6, 2021 at 4:20 PM Andy Shevchenko
 wrote:
>
>
>
> On Saturday, February 6, 2021,  wrote:
>>
>> From: Menglong Dong 
>>
>> The bit mask for MSG_* seems a little confused here. Replace it
>> with BIT_MASK to make it clear to understand.
>
>
> It makes it more confusing if you understand the difference between 
> BIT_MASK() and BIT(). I think you have to use the latter. And note () when 
> referring to the function or macro.
>

I replaced BIT_MASK() with BIT() in the patch of v2, and it looks much
more tidy.
I can't figure out the difference between BIT() and BIT_MASK(), seems
the latter one more safe... isn't it?

Thanks:)
Menglong Dong


Re: [PATCH v4 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver

2021-02-06 Thread Stephen Boyd
Quoting Jonathan Cameron (2021-02-06 08:17:11)
> On Tue,  2 Feb 2021 10:44:34 -0800
> Stephen Boyd  wrote:
> 
> > +static struct platform_driver cros_ec_mkbp_proximity_driver = {
> > + .driver = {
> > + .name = "cros-ec-mkbp-proximity",
> > + .of_match_table = 
> > of_match_ptr(cros_ec_mkbp_proximity_of_match),
> I'm going to assume we know no one is going to use this with
> ACPI via PRP0001 given presumably the firmware on these devices
> is tightly controlled.

Correct.

> 
> However, we should should still drop the of_match_ptr
> as it will lead to an unused warning for cros_ec_mkbp_proximity_of_match
> if anyone builds this without CONFIG_OF + it sets a general bad
> precedence that I'd rather wasn't around for people to copy.
> Note that in general we are slowly ripping these out of IIO but
> probably lots still there.
> 
> If this is all that is needed in this version I'll just do it
> whilst applying unless anyone shouts.
> 

Agreed. Thanks for fixing that last little bit.


Re: [PATCH] mips: kernel: setup: fix crash kernel resource allocation

2021-02-06 Thread Jinyang He

On 02/06/2021 08:59 PM, Ivan Khoronzhuk wrote:


In order to avoid crash kernel corruption, its memory is reserved
early in memblock and as result, in time when resources are inited
it's not present in memblock.memory, so crash kernel memory is out
of ranges listed with for_each_mem_range(). To avoid it and still
keep memory reserved lets reseve it out of loop by inserting it in
iomem_resource.


Hi, Ivan,

I'm not familiar with memblock. If the following my ideas show my
ignorance, please forgive me.

First, not only the crash kernel is reserved early in memblock, but also
code, data, and bss are also reserved in bootmem_init():

/* Reserve memory occupied by kernel. */
memblock_reserve(__pa_symbol(&_text),
__pa_symbol(&_end) - __pa_symbol(&_text));

(CONFIG_NUMA is not enabled. NUMA platform reserved them is earlier.)

If there is something unsuitable with the crash kernel, is there something
unsuitable with the kernel memory?


Then, for_each_mem_range() is normal memory. Although memblock_reserve()
has used before that, it just adds memory to memblock.reserved. That means
it will still appear in memblock.memory. Thus, here I have a question,
do we need to use replace for_each_mem_range with for_each_mem_range_rev?

Finally, thank you for the patch, it makes me think a lot.

Thanks,
Jinyang


Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
Signed-off-by: Ivan Khoronzhuk 
---
Based on linux-next/master

  arch/mips/kernel/setup.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 3785c72bc3bc..25e376ef2f2a 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -473,14 +473,15 @@ static void __init mips_parse_crashkernel(void)
crashk_res.end   = crash_base + crash_size - 1;
  }
  
-static void __init request_crashkernel(struct resource *res)

+static void __init request_crashkernel(void)
  {
int ret;
  
  	if (crashk_res.start == crashk_res.end)

return;
  
-	ret = request_resource(res, _res);

+   /* The crashk resource shoud be located in normal mem */
+   ret = insert_resource(_resource, _res);
if (!ret)
pr_info("Reserving %ldMB of memory at %ldMB for crashkernel\n",
(unsigned long)(resource_size(_res) >> 20),
@@ -734,8 +735,9 @@ static void __init resource_init(void)
request_resource(res, _resource);
request_resource(res, _resource);
request_resource(res, _resource);
-   request_crashkernel(res);
}
+
+   request_crashkernel();
  }
  
  #ifdef CONFIG_SMP




[PATCH v2 net-next] net: socket: use BIT() for MSG_*

2021-02-06 Thread menglong8 . dong
From: Menglong Dong 

The bit mask for MSG_* seems a little confused here. Replace it
with BIT() to make it clear to understand.

Changes since v1:
- use BIT() instead of BIT_MASK()

Signed-off-by: Menglong Dong 
---
 include/linux/socket.h | 71 ++
 1 file changed, 37 insertions(+), 34 deletions(-)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 385894b4a8bb..cc525d66512d 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -283,42 +283,45 @@ struct ucred {
Added those for 1003.1g not all are supported yet
  */
 
-#define MSG_OOB1
-#define MSG_PEEK   2
-#define MSG_DONTROUTE  4
-#define MSG_TRYHARD 4   /* Synonym for MSG_DONTROUTE for DECnet */
-#define MSG_CTRUNC 8
-#define MSG_PROBE  0x10/* Do not send. Only probe path f.e. for MTU */
-#define MSG_TRUNC  0x20
-#define MSG_DONTWAIT   0x40/* Nonblocking io*/
-#define MSG_EOR 0x80   /* End of record */
-#define MSG_WAITALL0x100   /* Wait for a full request */
-#define MSG_FIN 0x200
-#define MSG_SYN0x400
-#define MSG_CONFIRM0x800   /* Confirm path validity */
-#define MSG_RST0x1000
-#define MSG_ERRQUEUE   0x2000  /* Fetch message from error queue */
-#define MSG_NOSIGNAL   0x4000  /* Do not generate SIGPIPE */
-#define MSG_MORE   0x8000  /* Sender will send more */
-#define MSG_WAITFORONE 0x1 /* recvmmsg(): block until 1+ packets avail */
-#define MSG_SENDPAGE_NOPOLICY 0x1 /* sendpage() internal : do no apply 
policy */
-#define MSG_SENDPAGE_NOTLAST 0x2 /* sendpage() internal : not the last 
page */
-#define MSG_BATCH  0x4 /* sendmmsg(): more messages coming */
-#define MSG_EOF MSG_FIN
-#define MSG_NO_SHARED_FRAGS 0x8 /* sendpage() internal : page frags are 
not shared */
-#define MSG_SENDPAGE_DECRYPTED 0x10 /* sendpage() internal : page may carry
- * plain text and require encryption
- */
-
-#define MSG_ZEROCOPY   0x400   /* Use user data in kernel path */
-#define MSG_FASTOPEN   0x2000  /* Send data in TCP SYN */
-#define MSG_CMSG_CLOEXEC 0x4000/* Set close_on_exec for file
-  descriptor received through
-  SCM_RIGHTS */
+#define MSG_OOBBIT(0)
+#define MSG_PEEK   BIT(1)
+#define MSG_DONTROUTE  BIT(2)
+#define MSG_TRYHARDBIT(2)  /* Synonym for MSG_DONTROUTE for DECnet 
*/
+#define MSG_CTRUNC BIT(3)
+#define MSG_PROBE  BIT(4)  /* Do not send. Only probe path f.e. for MTU
*/
+#define MSG_TRUNC  BIT(5)
+#define MSG_DONTWAIT   BIT(6)  /* Nonblocking io   */
+#define MSG_EORBIT(7)  /* End of record*/
+#define MSG_WAITALLBIT(8)  /* Wait for a full request  */
+#define MSG_FINBIT(9)
+#define MSG_SYNBIT(10)
+#define MSG_CONFIRMBIT(11) /* Confirm path validity*/
+#define MSG_RSTBIT(12)
+#define MSG_ERRQUEUE   BIT(13) /* Fetch message from error queue */
+#define MSG_NOSIGNAL   BIT(14) /* Do not generate SIGPIPE  */
+#define MSG_MORE   BIT(15) /* Sender will send more*/
+#define MSG_WAITFORONE BIT(16) /* recvmmsg(): block until 1+ packets avail */
+#define MSG_SENDPAGE_NOPOLICY  BIT(16) /* sendpage() internal : do no apply 
policy */
+#define MSG_SENDPAGE_NOTLAST   BIT(17) /* sendpage() internal : not the last 
page  */
+#define MSG_BATCH  BIT(18) /* sendmmsg(): more messages coming */
+#define MSG_EOFMSG_FIN
+#define MSG_NO_SHARED_FRAGSBIT(19) /* sendpage() internal : page frags
+* are not shared
+*/
+#define MSG_SENDPAGE_DECRYPTED BIT(20) /* sendpage() internal : page may carry
+* plain text and require encryption
+*/
+
+#define MSG_ZEROCOPY   BIT(26) /* Use user data in kernel path */
+#define MSG_FASTOPEN   BIT(29) /* Send data in TCP SYN */
+#define MSG_CMSG_CLOEXEC   BIT(30) /* Set close_on_exec for file
+* descriptor received through
+* SCM_RIGHTS
+*/
 #if defined(CONFIG_COMPAT)
-#define MSG_CMSG_COMPAT0x8000  /* This message needs 32 bit 
fixups */
+#define MSG_CMSG_COMPATBIT_MASK(31)/* This message needs 32 bit 
fixups */
 #else
-#define MSG_CMSG_COMPAT0   /* We never have 32 bit fixups 
*/
+#define MSG_CMSG_COMPAT0   /* We never have 32 bit fixups */
 #endif
 
 
-- 
2.25.1



[PATCH v9 13/18] virt: acrn: Introduce interfaces to query C-states and P-states allowed by hypervisor

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

The C-states and P-states data are used to support CPU power management.
The hypervisor controls C-states and P-states for a User VM.

ACRN userspace need to query the data from the hypervisor to build ACPI
tables for a User VM.

HSM provides ioctls for ACRN userspace to query C-states and P-states
data obtained from the hypervisor.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/hsm.c   | 69 +++
 drivers/virt/acrn/hypercall.h | 12 ++
 include/uapi/linux/acrn.h | 55 
 3 files changed, 136 insertions(+)

diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 419271f32be8..b7f2deddc3e7 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -38,6 +38,67 @@ static int acrn_dev_open(struct inode *inode, struct file 
*filp)
return 0;
 }
 
+static int pmcmd_ioctl(u64 cmd, void __user *uptr)
+{
+   struct acrn_pstate_data *px_data;
+   struct acrn_cstate_data *cx_data;
+   u64 *pm_info;
+   int ret = 0;
+
+   switch (cmd & PMCMD_TYPE_MASK) {
+   case ACRN_PMCMD_GET_PX_CNT:
+   case ACRN_PMCMD_GET_CX_CNT:
+   pm_info = kmalloc(sizeof(u64), GFP_KERNEL);
+   if (!pm_info)
+   return -ENOMEM;
+
+   ret = hcall_get_cpu_state(cmd, virt_to_phys(pm_info));
+   if (ret < 0) {
+   kfree(pm_info);
+   break;
+   }
+
+   if (copy_to_user(uptr, pm_info, sizeof(u64)))
+   ret = -EFAULT;
+   kfree(pm_info);
+   break;
+   case ACRN_PMCMD_GET_PX_DATA:
+   px_data = kmalloc(sizeof(*px_data), GFP_KERNEL);
+   if (!px_data)
+   return -ENOMEM;
+
+   ret = hcall_get_cpu_state(cmd, virt_to_phys(px_data));
+   if (ret < 0) {
+   kfree(px_data);
+   break;
+   }
+
+   if (copy_to_user(uptr, px_data, sizeof(*px_data)))
+   ret = -EFAULT;
+   kfree(px_data);
+   break;
+   case ACRN_PMCMD_GET_CX_DATA:
+   cx_data = kmalloc(sizeof(*cx_data), GFP_KERNEL);
+   if (!cx_data)
+   return -ENOMEM;
+
+   ret = hcall_get_cpu_state(cmd, virt_to_phys(cx_data));
+   if (ret < 0) {
+   kfree(cx_data);
+   break;
+   }
+
+   if (copy_to_user(uptr, cx_data, sizeof(*cx_data)))
+   ret = -EFAULT;
+   kfree(cx_data);
+   break;
+   default:
+   break;
+   }
+
+   return ret;
+}
+
 /*
  * HSM relies on hypercall layer of the ACRN hypervisor to do the
  * sanity check against the input parameters.
@@ -54,6 +115,7 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
struct acrn_msi_entry *msi;
struct acrn_pcidev *pcidev;
struct page *page;
+   u64 cstate_cmd;
int i, ret = 0;
 
if (vm->vmid == ACRN_INVALID_VMID && cmd != ACRN_IOCTL_CREATE_VM) {
@@ -267,6 +329,13 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
case ACRN_IOCTL_CLEAR_VM_IOREQ:
acrn_ioreq_request_clear(vm);
break;
+   case ACRN_IOCTL_PM_GET_CPU_STATE:
+   if (copy_from_user(_cmd, (void *)ioctl_param,
+  sizeof(cstate_cmd)))
+   return -EFAULT;
+
+   ret = pmcmd_ioctl(cstate_cmd, (void __user *)ioctl_param);
+   break;
default:
dev_dbg(acrn_dev.this_device, "Unknown IOCTL 0x%x!\n", cmd);
ret = -ENOTTY;
diff --git a/drivers/virt/acrn/hypercall.h b/drivers/virt/acrn/hypercall.h
index a8813397a3fe..e640632366f0 100644
--- a/drivers/virt/acrn/hypercall.h
+++ b/drivers/virt/acrn/hypercall.h
@@ -39,6 +39,9 @@
 #define HC_ASSIGN_PCIDEV   _HC_ID(HC_ID, HC_ID_PCI_BASE + 0x05)
 #define HC_DEASSIGN_PCIDEV _HC_ID(HC_ID, HC_ID_PCI_BASE + 0x06)
 
+#define HC_ID_PM_BASE  0x80UL
+#define HC_PM_GET_CPU_STATE_HC_ID(HC_ID, HC_ID_PM_BASE + 0x00)
+
 /**
  * hcall_create_vm() - Create a User VM
  * @vminfo:Service VM GPA of info of User VM creation
@@ -225,4 +228,13 @@ static inline long hcall_reset_ptdev_intr(u64 vmid, u64 
irq)
return acrn_hypercall2(HC_RESET_PTDEV_INTR, vmid, irq);
 }
 
+/*
+ * hcall_get_cpu_state() - Get P-states and C-states info from the hypervisor
+ * @state: Service VM GPA of buffer of P-states and C-states
+ */
+static inline long hcall_get_cpu_state(u64 cmd, u64 state)
+{
+   return acrn_hypercall2(HC_PM_GET_CPU_STATE, cmd, state);
+}

[PATCH v9 18/18] sample/acrn: Introduce a sample of HSM ioctl interface usage

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

Launch a simple guest (with several instructions as payload) on ACRN
with demonstration ioctl usage.

Signed-off-by: Shuo Liu 
---
 samples/acrn/Makefile|  12 
 samples/acrn/guest.ld|   9 +++
 samples/acrn/payload.ld  |   9 +++
 samples/acrn/vm-sample.c | 136 +++
 4 files changed, 166 insertions(+)
 create mode 100644 samples/acrn/Makefile
 create mode 100644 samples/acrn/guest.ld
 create mode 100644 samples/acrn/payload.ld
 create mode 100644 samples/acrn/vm-sample.c

diff --git a/samples/acrn/Makefile b/samples/acrn/Makefile
new file mode 100644
index ..c8e3ed9785e9
--- /dev/null
+++ b/samples/acrn/Makefile
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+
+.PHONY: vm-sample
+
+vm-sample: vm-sample.o payload.o
+   $(CC) $^ -o $@
+
+payload.o: payload.ld guest16.o
+   $(LD) -T $< -o $@
+
+clean:
+   rm *.o vm-sample
diff --git a/samples/acrn/guest.ld b/samples/acrn/guest.ld
new file mode 100644
index ..5127c682bd22
--- /dev/null
+++ b/samples/acrn/guest.ld
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+OUTPUT_FORMAT(binary)
+SECTIONS
+{
+.start : { *(.start) }
+.text : { *(.text*) }
+.rodata : { *(.rodata) }
+.data : { *(.data) }
+}
diff --git a/samples/acrn/payload.ld b/samples/acrn/payload.ld
new file mode 100644
index ..e8d9a498ad62
--- /dev/null
+++ b/samples/acrn/payload.ld
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+SECTIONS
+{
+.payload16 0 : {
+guest16 = .;
+guest16.o(.text)
+guest16_end = .;
+}
+}
diff --git a/samples/acrn/vm-sample.c b/samples/acrn/vm-sample.c
new file mode 100644
index ..b2dad47a77a0
--- /dev/null
+++ b/samples/acrn/vm-sample.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * A sample program to run a User VM on the ACRN hypervisor
+ *
+ * This sample runs in a Service VM, which is a privileged VM of ACRN.
+ * CONFIG_ACRN_HSM need to be enabled in the Service VM.
+ *
+ * Guest VM code in guest16.s will be executed after the VM launched.
+ *
+ * Copyright (C) 2020 Intel Corporation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GUEST_MEMORY_SIZE  (1024*1024)
+void *guest_memory;
+
+extern const unsigned char guest16[], guest16_end[];
+static char io_request_page[4096] __attribute__((aligned(4096)));
+static struct acrn_io_request *io_req_buf = (struct acrn_io_request 
*)io_request_page;
+
+__u16 vcpu_num;
+__u16 vmid;
+/* POST_STANDARD_VM_UUID1, refer to 
https://github.com/projectacrn/acrn-hypervisor/blob/master/hypervisor/include/common/vm_uuids.h
 */
+guid_t vm_uuid = GUID_INIT(0x385479d2, 0xd625, 0xe811, 0x86, 0x4e, 0xcb, 0x7a, 
0x18, 0xb3, 0x46, 0x43);
+
+int hsm_fd;
+int is_running = 1;
+
+void vm_exit(int sig)
+{
+   sig = sig;
+
+   is_running = 0;
+   ioctl(hsm_fd, ACRN_IOCTL_PAUSE_VM, vmid);
+   ioctl(hsm_fd, ACRN_IOCTL_DESTROY_IOREQ_CLIENT, 0);
+}
+
+int main(int argc, char **argv)
+{
+   int vcpu_id, ret;
+   struct acrn_vm_creation create_vm = {0};
+   struct acrn_vm_memmap ram_map = {0};
+   struct acrn_vcpu_regs regs;
+   struct acrn_io_request *io_req;
+   struct acrn_ioreq_notify __attribute__((aligned(8))) notify;
+
+   argc = argc;
+   argv = argv;
+
+   guest_memory = memalign(4096, GUEST_MEMORY_SIZE);
+   if (!guest_memory) {
+   printf("No enough memory!\n");
+   return -1;
+   }
+   hsm_fd = open("/dev/acrn_hsm", O_RDWR|O_CLOEXEC);
+
+   memcpy(_vm.uuid, _uuid, 16);
+   create_vm.ioreq_buf = (__u64)io_req_buf;
+   ret = ioctl(hsm_fd, ACRN_IOCTL_CREATE_VM, _vm);
+   printf("Created VM! [%d]\n", ret);
+   vcpu_num = create_vm.vcpu_num;
+   vmid = create_vm.vmid;
+
+   /* setup guest memory */
+   ram_map.type = ACRN_MEMMAP_RAM;
+   ram_map.vma_base = (__u64)guest_memory;
+   ram_map.len = GUEST_MEMORY_SIZE;
+   ram_map.user_vm_pa = 0;
+   ram_map.attr = ACRN_MEM_ACCESS_RWX;
+   ret = ioctl(hsm_fd, ACRN_IOCTL_SET_MEMSEG, _map);
+   printf("Set up VM memory! [%d]\n", ret);
+
+   memcpy(guest_memory, guest16, guest16_end-guest16);
+
+   /* setup vcpu registers */
+   memset(, 0, sizeof(regs));
+   regs.vcpu_id = 0;
+   regs.vcpu_regs.rip = 0;
+
+   /* CR0_ET | CR0_NE */
+   regs.vcpu_regs.cr0 = 0x30U;
+   regs.vcpu_regs.cs_ar = 0x009FU;
+   regs.vcpu_regs.cs_sel = 0xF000U;
+   regs.vcpu_regs.cs_limit = 0xU;
+   regs.vcpu_regs.cs_base = 0 & 0xUL;
+   regs.vcpu_regs.rip = 0 & 0xUL;
+
+   ret = ioctl(hsm_fd, ACRN_IOCTL_SET_VCPU_REGS, );
+   printf("Set up VM BSP registers! [%d]\n", ret);
+
+   /* create an ioreq client for this VM */
+   ret = ioctl(hsm_fd, 

[PATCH v9 17/18] virt: acrn: Introduce an interface for Service VM to control vCPU

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

ACRN supports partition mode to achieve real-time requirements. In
partition mode, a CPU core can be dedicated to a vCPU of User VM. The
local APIC of the dedicated CPU core can be passthrough to the User VM.
The Service VM controls the assignment of the CPU cores.

Introduce an interface for the Service VM to remove the control of CPU
core from hypervisor perspective so that the CPU core can be a dedicated
CPU core of User VM.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/hsm.c   | 48 +++
 drivers/virt/acrn/hypercall.h | 14 ++
 2 files changed, 62 insertions(+)

diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 93f6abe10fa6..1f6b7c54a1a4 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -9,6 +9,7 @@
  * Yakui Zhao 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -371,6 +372,52 @@ static int acrn_dev_release(struct inode *inode, struct 
file *filp)
return 0;
 }
 
+static ssize_t remove_cpu_store(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   u64 cpu, lapicid;
+   int ret;
+
+   if (kstrtoull(buf, 0, ) < 0)
+   return -EINVAL;
+
+   if (cpu >= num_possible_cpus() || cpu == 0 || !cpu_is_hotpluggable(cpu))
+   return -EINVAL;
+
+   if (cpu_online(cpu))
+   remove_cpu(cpu);
+
+   lapicid = cpu_data(cpu).apicid;
+   dev_dbg(dev, "Try to remove cpu %lld with lapicid %lld\n", cpu, 
lapicid);
+   ret = hcall_sos_remove_cpu(lapicid);
+   if (ret < 0) {
+   dev_err(dev, "Failed to remove cpu %lld!\n", cpu);
+   goto fail_remove;
+   }
+
+   return count;
+
+fail_remove:
+   add_cpu(cpu);
+   return ret;
+}
+static DEVICE_ATTR_WO(remove_cpu);
+
+static struct attribute *acrn_attrs[] = {
+   _attr_remove_cpu.attr,
+   NULL
+};
+
+static struct attribute_group acrn_attr_group = {
+   .attrs = acrn_attrs,
+};
+
+static const struct attribute_group *acrn_attr_groups[] = {
+   _attr_group,
+   NULL
+};
+
 static const struct file_operations acrn_fops = {
.owner  = THIS_MODULE,
.open   = acrn_dev_open,
@@ -382,6 +429,7 @@ struct miscdevice acrn_dev = {
.minor  = MISC_DYNAMIC_MINOR,
.name   = "acrn_hsm",
.fops   = _fops,
+   .groups = acrn_attr_groups,
 };
 
 static int __init hsm_init(void)
diff --git a/drivers/virt/acrn/hypercall.h b/drivers/virt/acrn/hypercall.h
index e640632366f0..0cfad05bd1a9 100644
--- a/drivers/virt/acrn/hypercall.h
+++ b/drivers/virt/acrn/hypercall.h
@@ -13,6 +13,9 @@
 
 #define HC_ID 0x80UL
 
+#define HC_ID_GEN_BASE 0x0UL
+#define HC_SOS_REMOVE_CPU  _HC_ID(HC_ID, HC_ID_GEN_BASE + 0x01)
+
 #define HC_ID_VM_BASE  0x10UL
 #define HC_CREATE_VM   _HC_ID(HC_ID, HC_ID_VM_BASE + 0x00)
 #define HC_DESTROY_VM  _HC_ID(HC_ID, HC_ID_VM_BASE + 0x01)
@@ -42,6 +45,17 @@
 #define HC_ID_PM_BASE  0x80UL
 #define HC_PM_GET_CPU_STATE_HC_ID(HC_ID, HC_ID_PM_BASE + 0x00)
 
+/**
+ * hcall_sos_remove_cpu() - Remove a vCPU of Service VM
+ * @cpu: The vCPU to be removed
+ *
+ * Return: 0 on success, <0 on failure
+ */
+static inline long hcall_sos_remove_cpu(u64 cpu)
+{
+   return acrn_hypercall1(HC_SOS_REMOVE_CPU, cpu);
+}
+
 /**
  * hcall_create_vm() - Create a User VM
  * @vminfo:Service VM GPA of info of User VM creation
-- 
2.28.0



[PATCH v9 16/18] virt: acrn: Introduce irqfd

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

irqfd is a mechanism to inject a specific interrupt to a User VM using a
decoupled eventfd mechanism.

Vhost is a kernel-level virtio server which uses eventfd for interrupt
injection. To support vhost on ACRN, irqfd is introduced in HSM.

HSM provides ioctls to associate a virtual Message Signaled Interrupt
(MSI) with an eventfd. The corresponding virtual MSI will be injected
into a User VM once the eventfd got signal.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/Makefile   |   2 +-
 drivers/virt/acrn/acrn_drv.h |  10 ++
 drivers/virt/acrn/hsm.c  |   7 ++
 drivers/virt/acrn/irqfd.c| 235 +++
 drivers/virt/acrn/vm.c   |   3 +
 include/uapi/linux/acrn.h|  15 +++
 6 files changed, 271 insertions(+), 1 deletion(-)
 create mode 100644 drivers/virt/acrn/irqfd.c

diff --git a/drivers/virt/acrn/Makefile b/drivers/virt/acrn/Makefile
index 755b583b32ca..08ce641dcfa1 100644
--- a/drivers/virt/acrn/Makefile
+++ b/drivers/virt/acrn/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_ACRN_HSM) := acrn.o
-acrn-y := hsm.o vm.o mm.o ioreq.o ioeventfd.o
+acrn-y := hsm.o vm.o mm.o ioreq.o ioeventfd.o irqfd.o
diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index e3f8190bd972..1be54efa666c 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -159,6 +159,9 @@ extern rwlock_t acrn_vm_list_lock;
  * @ioeventfds_lock:   Lock to protect ioeventfds list
  * @ioeventfds:List to link all hsm_ioeventfd
  * @ioeventfd_client:  I/O client for ioeventfds of the VM
+ * @irqfds_lock:   Lock to protect irqfds list
+ * @irqfds:List to link all hsm_irqfd
+ * @irqfd_wq:  Workqueue for irqfd async shutdown
  */
 struct acrn_vm {
struct list_headlist;
@@ -178,6 +181,9 @@ struct acrn_vm {
struct mutexioeventfds_lock;
struct list_headioeventfds;
struct acrn_ioreq_client*ioeventfd_client;
+   struct mutexirqfds_lock;
+   struct list_headirqfds;
+   struct workqueue_struct *irqfd_wq;
 };
 
 struct acrn_vm *acrn_vm_create(struct acrn_vm *vm,
@@ -214,4 +220,8 @@ int acrn_ioeventfd_init(struct acrn_vm *vm);
 int acrn_ioeventfd_config(struct acrn_vm *vm, struct acrn_ioeventfd *args);
 void acrn_ioeventfd_deinit(struct acrn_vm *vm);
 
+int acrn_irqfd_init(struct acrn_vm *vm);
+int acrn_irqfd_config(struct acrn_vm *vm, struct acrn_irqfd *args);
+void acrn_irqfd_deinit(struct acrn_vm *vm);
+
 #endif /* __ACRN_HSM_DRV_H */
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 0b4e88b0b6bc..93f6abe10fa6 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -115,6 +115,7 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
struct acrn_vm_memmap memmap;
struct acrn_msi_entry *msi;
struct acrn_pcidev *pcidev;
+   struct acrn_irqfd irqfd;
struct page *page;
u64 cstate_cmd;
int i, ret = 0;
@@ -347,6 +348,12 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
 
ret = acrn_ioeventfd_config(vm, );
break;
+   case ACRN_IOCTL_IRQFD:
+   if (copy_from_user(, (void __user *)ioctl_param,
+  sizeof(irqfd)))
+   return -EFAULT;
+   ret = acrn_irqfd_config(vm, );
+   break;
default:
dev_dbg(acrn_dev.this_device, "Unknown IOCTL 0x%x!\n", cmd);
ret = -ENOTTY;
diff --git a/drivers/virt/acrn/irqfd.c b/drivers/virt/acrn/irqfd.c
new file mode 100644
index ..a8766d528e29
--- /dev/null
+++ b/drivers/virt/acrn/irqfd.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ACRN HSM irqfd: use eventfd objects to inject virtual interrupts
+ *
+ * Copyright (C) 2020 Intel Corporation. All rights reserved.
+ *
+ * Authors:
+ * Shuo Liu 
+ * Yakui Zhao 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "acrn_drv.h"
+
+static LIST_HEAD(acrn_irqfd_clients);
+static DEFINE_MUTEX(acrn_irqfds_mutex);
+
+/**
+ * struct hsm_irqfd - Properties of HSM irqfd
+ * @vm:Associated VM pointer
+ * @wait:  Entry of wait-queue
+ * @shutdown:  Async shutdown work
+ * @eventfd:   Associated eventfd
+ * @list:  Entry within _vm.irqfds of irqfds of a VM
+ * @pt:Structure for select/poll on the associated eventfd
+ * @msi:   MSI data
+ */
+struct hsm_irqfd {
+   struct acrn_vm  *vm;
+   wait_queue_entry_t  wait;
+   struct work_struct  shutdown;
+   struct eventfd_ctx  *eventfd;
+   struct list_head  

[PATCH v9 14/18] virt: acrn: Introduce I/O ranges operation interfaces

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

An I/O request of a User VM, which is constructed by hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.

I/O client maintains a list of address ranges. Introduce
acrn_ioreq_range_{add,del}() to manage these address ranges.

Signed-off-by: Shuo Liu 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/acrn_drv.h |  4 +++
 drivers/virt/acrn/ioreq.c| 60 
 2 files changed, 64 insertions(+)

diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index 068f0be769f6..8a7d7721f505 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -197,6 +197,10 @@ struct acrn_ioreq_client *acrn_ioreq_client_create(struct 
acrn_vm *vm,
   void *data, bool is_default,
   const char *name);
 void acrn_ioreq_client_destroy(struct acrn_ioreq_client *client);
+int acrn_ioreq_range_add(struct acrn_ioreq_client *client,
+u32 type, u64 start, u64 end);
+void acrn_ioreq_range_del(struct acrn_ioreq_client *client,
+ u32 type, u64 start, u64 end);
 
 int acrn_msi_inject(struct acrn_vm *vm, u64 msi_addr, u64 msi_data);
 
diff --git a/drivers/virt/acrn/ioreq.c b/drivers/virt/acrn/ioreq.c
index d19c05582d38..80b2e3f0e276 100644
--- a/drivers/virt/acrn/ioreq.c
+++ b/drivers/virt/acrn/ioreq.c
@@ -103,6 +103,66 @@ int acrn_ioreq_request_default_complete(struct acrn_vm 
*vm, u16 vcpu)
return ret;
 }
 
+/**
+ * acrn_ioreq_range_add() - Add an iorange monitored by an ioreq client
+ * @client:The ioreq client
+ * @type:  Type (ACRN_IOREQ_TYPE_MMIO or ACRN_IOREQ_TYPE_PORTIO)
+ * @start: Start address of iorange
+ * @end:   End address of iorange
+ *
+ * Return: 0 on success, <0 on error
+ */
+int acrn_ioreq_range_add(struct acrn_ioreq_client *client,
+u32 type, u64 start, u64 end)
+{
+   struct acrn_ioreq_range *range;
+
+   if (end < start) {
+   dev_err(acrn_dev.this_device,
+   "Invalid IO range [0x%llx,0x%llx]\n", start, end);
+   return -EINVAL;
+   }
+
+   range = kzalloc(sizeof(*range), GFP_KERNEL);
+   if (!range)
+   return -ENOMEM;
+
+   range->type = type;
+   range->start = start;
+   range->end = end;
+
+   write_lock_bh(>range_lock);
+   list_add(>list, >range_list);
+   write_unlock_bh(>range_lock);
+
+   return 0;
+}
+
+/**
+ * acrn_ioreq_range_del() - Del an iorange monitored by an ioreq client
+ * @client:The ioreq client
+ * @type:  Type (ACRN_IOREQ_TYPE_MMIO or ACRN_IOREQ_TYPE_PORTIO)
+ * @start: Start address of iorange
+ * @end:   End address of iorange
+ */
+void acrn_ioreq_range_del(struct acrn_ioreq_client *client,
+ u32 type, u64 start, u64 end)
+{
+   struct acrn_ioreq_range *range;
+
+   write_lock_bh(>range_lock);
+   list_for_each_entry(range, >range_list, list) {
+   if (type == range->type &&
+   start == range->start &&
+   end == range->end) {
+   list_del(>list);
+   kfree(range);
+   break;
+   }
+   }
+   write_unlock_bh(>range_lock);
+}
+
 /*
  * ioreq_task() is the execution entity of handler thread of an I/O client.
  * The handler callback of the I/O client is called within the handler thread.
-- 
2.28.0



[PATCH v9 11/18] virt: acrn: Introduce interfaces for PCI device passthrough

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

PCI device passthrough enables an OS in a virtual machine to directly
access a PCI device in the host. It promises almost the native
performance, which is required in performance-critical scenarios of
ACRN.

HSM provides the following ioctls:
 - Assign - ACRN_IOCTL_ASSIGN_PCIDEV
   Pass data struct acrn_pcidev from userspace to the hypervisor, and
   inform the hypervisor to assign a PCI device to a User VM.

 - De-assign - ACRN_IOCTL_DEASSIGN_PCIDEV
   Pass data struct acrn_pcidev from userspace to the hypervisor, and
   inform the hypervisor to de-assign a PCI device from a User VM.

 - Set a interrupt of a passthrough device - ACRN_IOCTL_SET_PTDEV_INTR
   Pass data struct acrn_ptdev_irq from userspace to the hypervisor,
   and inform the hypervisor to map a INTx interrupt of passthrough
   device of User VM.

 - Reset passthrough device interrupt - ACRN_IOCTL_RESET_PTDEV_INTR
   Pass data struct acrn_ptdev_irq from userspace to the hypervisor,
   and inform the hypervisor to unmap a INTx interrupt of passthrough
   device of User VM.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/hsm.c   | 50 
 drivers/virt/acrn/hypercall.h | 54 +++
 include/uapi/linux/acrn.h | 61 +++
 3 files changed, 165 insertions(+)

diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 1cc0c612dc09..94d70b1c1e5c 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -49,7 +49,9 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
struct acrn_vm_creation *vm_param;
struct acrn_vcpu_regs *cpu_regs;
struct acrn_ioreq_notify notify;
+   struct acrn_ptdev_irq *irq_info;
struct acrn_vm_memmap memmap;
+   struct acrn_pcidev *pcidev;
int i, ret = 0;
 
if (vm->vmid == ACRN_INVALID_VMID && cmd != ACRN_IOCTL_CREATE_VM) {
@@ -148,6 +150,54 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
 
ret = acrn_vm_memseg_unmap(vm, );
break;
+   case ACRN_IOCTL_ASSIGN_PCIDEV:
+   pcidev = memdup_user((void __user *)ioctl_param,
+sizeof(struct acrn_pcidev));
+   if (IS_ERR(pcidev))
+   return PTR_ERR(pcidev);
+
+   ret = hcall_assign_pcidev(vm->vmid, virt_to_phys(pcidev));
+   if (ret < 0)
+   dev_dbg(acrn_dev.this_device,
+   "Failed to assign pci device!\n");
+   kfree(pcidev);
+   break;
+   case ACRN_IOCTL_DEASSIGN_PCIDEV:
+   pcidev = memdup_user((void __user *)ioctl_param,
+sizeof(struct acrn_pcidev));
+   if (IS_ERR(pcidev))
+   return PTR_ERR(pcidev);
+
+   ret = hcall_deassign_pcidev(vm->vmid, virt_to_phys(pcidev));
+   if (ret < 0)
+   dev_dbg(acrn_dev.this_device,
+   "Failed to deassign pci device!\n");
+   kfree(pcidev);
+   break;
+   case ACRN_IOCTL_SET_PTDEV_INTR:
+   irq_info = memdup_user((void __user *)ioctl_param,
+  sizeof(struct acrn_ptdev_irq));
+   if (IS_ERR(irq_info))
+   return PTR_ERR(irq_info);
+
+   ret = hcall_set_ptdev_intr(vm->vmid, virt_to_phys(irq_info));
+   if (ret < 0)
+   dev_dbg(acrn_dev.this_device,
+   "Failed to configure intr for ptdev!\n");
+   kfree(irq_info);
+   break;
+   case ACRN_IOCTL_RESET_PTDEV_INTR:
+   irq_info = memdup_user((void __user *)ioctl_param,
+  sizeof(struct acrn_ptdev_irq));
+   if (IS_ERR(irq_info))
+   return PTR_ERR(irq_info);
+
+   ret = hcall_reset_ptdev_intr(vm->vmid, virt_to_phys(irq_info));
+   if (ret < 0)
+   dev_dbg(acrn_dev.this_device,
+   "Failed to reset intr for ptdev!\n");
+   kfree(irq_info);
+   break;
case ACRN_IOCTL_CREATE_IOREQ_CLIENT:
if (vm->default_client)
return -EEXIST;
diff --git a/drivers/virt/acrn/hypercall.h b/drivers/virt/acrn/hypercall.h
index 5eba29e3ed38..f448301832cf 100644
--- a/drivers/virt/acrn/hypercall.h
+++ b/drivers/virt/acrn/hypercall.h
@@ -28,6 +28,12 @@
 #define HC_ID_MEM_BASE 0x40UL
 #define HC_VM_SET_MEMORY_REGIONS   _HC_ID(HC_ID, HC_ID_MEM_BASE + 0x02)
 
+#define HC_ID_PCI_BASE 0x50UL
+#define HC_SET_PTDEV_INTR  _HC_ID(HC_ID, 

[PATCH v9 10/18] virt: acrn: Introduce PCI configuration space PIO accesses combiner

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

A User VM can access its virtual PCI configuration spaces via port IO
approach, which has two following steps:
 1) writes address into port 0xCF8
 2) put/get data in/from port 0xCFC

To distribute a complete PCI configuration space access one time, HSM
need to combine such two accesses together.

Combine two paired PIO I/O requests into one PCI I/O request and
continue the I/O request distribution.

Signed-off-by: Shuo Liu 
Reviewed-by: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/acrn_drv.h |  2 +
 drivers/virt/acrn/ioreq.c| 76 
 include/uapi/linux/acrn.h| 27 +
 3 files changed, 105 insertions(+)

diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index 68bd8db6c8be..6c92a505fa20 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -154,6 +154,7 @@ extern rwlock_t acrn_vm_list_lock;
  * @default_client:The default I/O request client
  * @ioreq_buf: I/O request shared buffer
  * @ioreq_page:The page of the I/O request shared 
buffer
+ * @pci_conf_addr: Address of a PCI configuration access emulation
  */
 struct acrn_vm {
struct list_headlist;
@@ -168,6 +169,7 @@ struct acrn_vm {
struct acrn_ioreq_client*default_client;
struct acrn_io_request_buffer   *ioreq_buf;
struct page *ioreq_page;
+   u32 pci_conf_addr;
 };
 
 struct acrn_vm *acrn_vm_create(struct acrn_vm *vm,
diff --git a/drivers/virt/acrn/ioreq.c b/drivers/virt/acrn/ioreq.c
index 51cb41ef7c72..d19c05582d38 100644
--- a/drivers/virt/acrn/ioreq.c
+++ b/drivers/virt/acrn/ioreq.c
@@ -222,6 +222,80 @@ int acrn_ioreq_client_wait(struct acrn_ioreq_client 
*client)
return 0;
 }
 
+static bool is_cfg_addr(struct acrn_io_request *req)
+{
+   return ((req->type == ACRN_IOREQ_TYPE_PORTIO) &&
+   (req->reqs.pio_request.address == 0xcf8));
+}
+
+static bool is_cfg_data(struct acrn_io_request *req)
+{
+   return ((req->type == ACRN_IOREQ_TYPE_PORTIO) &&
+   ((req->reqs.pio_request.address >= 0xcfc) &&
+(req->reqs.pio_request.address < (0xcfc + 4;
+}
+
+/* The low 8-bit of supported pci_reg addr.*/
+#define PCI_LOWREG_MASK  0xFC
+/* The high 4-bit of supported pci_reg addr */
+#define PCI_HIGHREG_MASK 0xF00
+/* Max number of supported functions */
+#define PCI_FUNCMAX7
+/* Max number of supported slots */
+#define PCI_SLOTMAX31
+/* Max number of supported buses */
+#define PCI_BUSMAX 255
+#define CONF1_ENABLE   0x8000UL
+/*
+ * A PCI configuration space access via PIO 0xCF8 and 0xCFC normally has two
+ * following steps:
+ *   1) writes address into 0xCF8 port
+ *   2) accesses data in/from 0xCFC
+ * This function combines such paired PCI configuration space I/O requests into
+ * one ACRN_IOREQ_TYPE_PCICFG type I/O request and continues the processing.
+ */
+static bool handle_cf8cfc(struct acrn_vm *vm,
+ struct acrn_io_request *req, u16 vcpu)
+{
+   int offset, pci_cfg_addr, pci_reg;
+   bool is_handled = false;
+
+   if (is_cfg_addr(req)) {
+   WARN_ON(req->reqs.pio_request.size != 4);
+   if (req->reqs.pio_request.direction == ACRN_IOREQ_DIR_WRITE)
+   vm->pci_conf_addr = req->reqs.pio_request.value;
+   else
+   req->reqs.pio_request.value = vm->pci_conf_addr;
+   is_handled = true;
+   } else if (is_cfg_data(req)) {
+   if (!(vm->pci_conf_addr & CONF1_ENABLE)) {
+   if (req->reqs.pio_request.direction ==
+   ACRN_IOREQ_DIR_READ)
+   req->reqs.pio_request.value = 0x;
+   is_handled = true;
+   } else {
+   offset = req->reqs.pio_request.address - 0xcfc;
+
+   req->type = ACRN_IOREQ_TYPE_PCICFG;
+   pci_cfg_addr = vm->pci_conf_addr;
+   req->reqs.pci_request.bus =
+   (pci_cfg_addr >> 16) & PCI_BUSMAX;
+   req->reqs.pci_request.dev =
+   (pci_cfg_addr >> 11) & PCI_SLOTMAX;
+   req->reqs.pci_request.func =
+   (pci_cfg_addr >> 8) & PCI_FUNCMAX;
+   pci_reg = (pci_cfg_addr & PCI_LOWREG_MASK) +
+  ((pci_cfg_addr >> 16) & PCI_HIGHREG_MASK);
+   req->reqs.pci_request.reg = pci_reg + offset;
+   }
+   }
+
+   if (is_handled)
+   ioreq_complete_request(vm, vcpu, req);
+
+   return is_handled;
+}
+
 static bool in_range(struct acrn_ioreq_range *range,
 struct acrn_io_request 

[PATCH v9 15/18] virt: acrn: Introduce ioeventfd

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

ioeventfd is a mechanism to register PIO/MMIO regions to trigger an
eventfd signal when written to by a User VM. ACRN userspace can register
any arbitrary I/O address with a corresponding eventfd and then pass the
eventfd to a specific end-point of interest for handling.

Vhost is a kernel-level virtio server which uses eventfd for signalling.
To support vhost on ACRN, ioeventfd is introduced in HSM.

A new I/O client dedicated to ioeventfd is associated with a User VM
during VM creation. HSM provides ioctls to associate an I/O region with
a eventfd. The I/O client signals a eventfd once its corresponding I/O
region is matched with an I/O request.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/Kconfig |   1 +
 drivers/virt/acrn/Makefile|   2 +-
 drivers/virt/acrn/acrn_drv.h  |  10 ++
 drivers/virt/acrn/hsm.c   |  11 ++
 drivers/virt/acrn/ioeventfd.c | 273 ++
 drivers/virt/acrn/vm.c|   2 +
 include/uapi/linux/acrn.h |  29 
 7 files changed, 327 insertions(+), 1 deletion(-)
 create mode 100644 drivers/virt/acrn/ioeventfd.c

diff --git a/drivers/virt/acrn/Kconfig b/drivers/virt/acrn/Kconfig
index 36c80378c30c..3e1a61c9d8d8 100644
--- a/drivers/virt/acrn/Kconfig
+++ b/drivers/virt/acrn/Kconfig
@@ -2,6 +2,7 @@
 config ACRN_HSM
tristate "ACRN Hypervisor Service Module"
depends on ACRN_GUEST
+   select EVENTFD
help
  ACRN Hypervisor Service Module (HSM) is a kernel module which
  communicates with ACRN userspace through ioctls and talks to
diff --git a/drivers/virt/acrn/Makefile b/drivers/virt/acrn/Makefile
index 21721cbf6a80..755b583b32ca 100644
--- a/drivers/virt/acrn/Makefile
+++ b/drivers/virt/acrn/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_ACRN_HSM) := acrn.o
-acrn-y := hsm.o vm.o mm.o ioreq.o
+acrn-y := hsm.o vm.o mm.o ioreq.o ioeventfd.o
diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index 8a7d7721f505..e3f8190bd972 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -156,6 +156,9 @@ extern rwlock_t acrn_vm_list_lock;
  * @ioreq_page:The page of the I/O request shared 
buffer
  * @pci_conf_addr: Address of a PCI configuration access emulation
  * @monitor_page:  Page of interrupt statistics of User VM
+ * @ioeventfds_lock:   Lock to protect ioeventfds list
+ * @ioeventfds:List to link all hsm_ioeventfd
+ * @ioeventfd_client:  I/O client for ioeventfds of the VM
  */
 struct acrn_vm {
struct list_headlist;
@@ -172,6 +175,9 @@ struct acrn_vm {
struct page *ioreq_page;
u32 pci_conf_addr;
struct page *monitor_page;
+   struct mutexioeventfds_lock;
+   struct list_headioeventfds;
+   struct acrn_ioreq_client*ioeventfd_client;
 };
 
 struct acrn_vm *acrn_vm_create(struct acrn_vm *vm,
@@ -204,4 +210,8 @@ void acrn_ioreq_range_del(struct acrn_ioreq_client *client,
 
 int acrn_msi_inject(struct acrn_vm *vm, u64 msi_addr, u64 msi_data);
 
+int acrn_ioeventfd_init(struct acrn_vm *vm);
+int acrn_ioeventfd_config(struct acrn_vm *vm, struct acrn_ioeventfd *args);
+void acrn_ioeventfd_deinit(struct acrn_vm *vm);
+
 #endif /* __ACRN_HSM_DRV_H */
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index b7f2deddc3e7..0b4e88b0b6bc 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -111,6 +111,7 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
struct acrn_vcpu_regs *cpu_regs;
struct acrn_ioreq_notify notify;
struct acrn_ptdev_irq *irq_info;
+   struct acrn_ioeventfd ioeventfd;
struct acrn_vm_memmap memmap;
struct acrn_msi_entry *msi;
struct acrn_pcidev *pcidev;
@@ -336,6 +337,16 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
 
ret = pmcmd_ioctl(cstate_cmd, (void __user *)ioctl_param);
break;
+   case ACRN_IOCTL_IOEVENTFD:
+   if (copy_from_user(, (void __user *)ioctl_param,
+  sizeof(ioeventfd)))
+   return -EFAULT;
+
+   if (ioeventfd.reserved != 0)
+   return -EINVAL;
+
+   ret = acrn_ioeventfd_config(vm, );
+   break;
default:
dev_dbg(acrn_dev.this_device, "Unknown IOCTL 0x%x!\n", cmd);
ret = -ENOTTY;
diff --git a/drivers/virt/acrn/ioeventfd.c b/drivers/virt/acrn/ioeventfd.c
new file mode 100644
index ..ac4037e9f947
--- /dev/null
+++ b/drivers/virt/acrn/ioeventfd.c
@@ -0,0 +1,273 @@
+// 

[PATCH v9 09/18] virt: acrn: Introduce I/O request management

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

An I/O request of a User VM, which is constructed by the hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.

For each User VM, there is a shared 4-KByte memory region used for I/O
requests communication between the hypervisor and Service VM. An I/O
request is a 256-byte structure buffer, which is 'struct
acrn_io_request', that is filled by an I/O handler of the hypervisor
when a trapped I/O access happens in a User VM. ACRN userspace in the
Service VM first allocates a 4-KByte page and passes the GPA (Guest
Physical Address) of the buffer to the hypervisor. The buffer is used as
an array of 16 I/O request slots with each I/O request slot being 256
bytes. This array is indexed by vCPU ID.

An I/O client, which is 'struct acrn_ioreq_client', is responsible for
handling User VM I/O requests whose accessed GPA falls in a certain
range. Multiple I/O clients can be associated with each User VM. There
is a special client associated with each User VM, called the default
client, that handles all I/O requests that do not fit into the range of
any other I/O clients. The ACRN userspace acts as the default client for
each User VM.

The state transitions of a ACRN I/O request are as follows.

   FREE -> PENDING -> PROCESSING -> COMPLETE -> FREE -> ...

FREE: this I/O request slot is empty
PENDING: a valid I/O request is pending in this slot
PROCESSING: the I/O request is being processed
COMPLETE: the I/O request has been processed

An I/O request in COMPLETE or FREE state is owned by the hypervisor. HSM
and ACRN userspace are in charge of processing the others.

The processing flow of I/O requests are listed as following:

a) The I/O handler of the hypervisor will fill an I/O request with
   PENDING state when a trapped I/O access happens in a User VM.
b) The hypervisor makes an upcall, which is a notification interrupt, to
   the Service VM.
c) The upcall handler schedules a worker to dispatch I/O requests.
d) The worker looks for the PENDING I/O requests, assigns them to
   different registered clients based on the address of the I/O accesses,
   updates their state to PROCESSING, and notifies the corresponding
   client to handle.
e) The notified client handles the assigned I/O requests.
f) The HSM updates I/O requests states to COMPLETE and notifies the
   hypervisor of the completion via hypercalls.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Acked-by: Davidlohr Bueso 
Cc: Davidlohr Bueso 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
Cc: Davidlohr Bueso 
---
 drivers/virt/acrn/Makefile|   2 +-
 drivers/virt/acrn/acrn_drv.h  |  82 ++
 drivers/virt/acrn/hsm.c   |  43 ++-
 drivers/virt/acrn/hypercall.h |  28 ++
 drivers/virt/acrn/ioreq.c | 521 ++
 drivers/virt/acrn/vm.c|  27 +-
 include/uapi/linux/acrn.h | 150 ++
 7 files changed, 843 insertions(+), 10 deletions(-)
 create mode 100644 drivers/virt/acrn/ioreq.c

diff --git a/drivers/virt/acrn/Makefile b/drivers/virt/acrn/Makefile
index 38bc44b6edcd..21721cbf6a80 100644
--- a/drivers/virt/acrn/Makefile
+++ b/drivers/virt/acrn/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_ACRN_HSM) := acrn.o
-acrn-y := hsm.o vm.o mm.o
+acrn-y := hsm.o vm.o mm.o ioreq.o
diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index e47a45280eea..68bd8db6c8be 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -12,10 +12,15 @@
 
 extern struct miscdevice acrn_dev;
 
+#define ACRN_NAME_LEN  16
 #define ACRN_MEM_MAPPING_MAX   256
 
 #define ACRN_MEM_REGION_ADD0
 #define ACRN_MEM_REGION_DEL2
+
+struct acrn_vm;
+struct acrn_ioreq_client;
+
 /**
  * struct vm_memory_region_op - Hypervisor memory operation
  * @type:  Operation type (ACRN_MEM_REGION_*)
@@ -75,9 +80,63 @@ struct vm_memory_mapping {
size_t  size;
 };
 
+/**
+ * struct acrn_ioreq_buffer - Data for setting the ioreq buffer of User VM
+ * @ioreq_buf: The GPA of the IO request shared buffer of a VM
+ *
+ * The parameter for the HC_SET_IOREQ_BUFFER hypercall used to set up
+ * the shared I/O request buffer between Service VM and ACRN hypervisor.
+ */
+struct acrn_ioreq_buffer {
+   u64 ioreq_buf;
+};
+
+struct acrn_ioreq_range {
+   struct list_headlist;
+   u32 type;
+   u64 start;
+   u64 end;
+};
+
+#define ACRN_IOREQ_CLIENT_DESTROYING   0U
+typedefint (*ioreq_handler_t)(struct acrn_ioreq_client *client,
+  struct acrn_io_request *req);
+/**
+ * struct acrn_ioreq_client - Structure of I/O client.
+ * @name:  Client name
+ * @vm:The VM that the client belongs to
+ * @list:  List node for this acrn_ioreq_client
+ * 

[PATCH v9 12/18] virt: acrn: Introduce interrupt injection interfaces

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

ACRN userspace need to inject virtual interrupts into a User VM in
devices emulation.

HSM needs provide interfaces to do so.

Introduce following interrupt injection interfaces:

ioctl ACRN_IOCTL_SET_IRQLINE:
  Pass data from userspace to the hypervisor, and inform the hypervisor
  to inject a virtual IOAPIC GSI interrupt to a User VM.

ioctl ACRN_IOCTL_INJECT_MSI:
  Pass data struct acrn_msi_entry from userspace to the hypervisor, and
  inform the hypervisor to inject a virtual MSI to a User VM.

ioctl ACRN_IOCTL_VM_INTR_MONITOR:
  Set a 4-Kbyte aligned shared page for statistics information of
  interrupts of a User VM.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/acrn_drv.h  |  4 
 drivers/virt/acrn/hsm.c   | 40 ++
 drivers/virt/acrn/hypercall.h | 41 +++
 drivers/virt/acrn/vm.c| 36 ++
 include/uapi/linux/acrn.h | 17 +++
 5 files changed, 138 insertions(+)

diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index 6c92a505fa20..068f0be769f6 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -155,6 +155,7 @@ extern rwlock_t acrn_vm_list_lock;
  * @ioreq_buf: I/O request shared buffer
  * @ioreq_page:The page of the I/O request shared 
buffer
  * @pci_conf_addr: Address of a PCI configuration access emulation
+ * @monitor_page:  Page of interrupt statistics of User VM
  */
 struct acrn_vm {
struct list_headlist;
@@ -170,6 +171,7 @@ struct acrn_vm {
struct acrn_io_request_buffer   *ioreq_buf;
struct page *ioreq_page;
u32 pci_conf_addr;
+   struct page *monitor_page;
 };
 
 struct acrn_vm *acrn_vm_create(struct acrn_vm *vm,
@@ -196,4 +198,6 @@ struct acrn_ioreq_client *acrn_ioreq_client_create(struct 
acrn_vm *vm,
   const char *name);
 void acrn_ioreq_client_destroy(struct acrn_ioreq_client *client);
 
+int acrn_msi_inject(struct acrn_vm *vm, u64 msi_addr, u64 msi_data);
+
 #endif /* __ACRN_HSM_DRV_H */
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 94d70b1c1e5c..419271f32be8 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -51,7 +51,9 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
struct acrn_ioreq_notify notify;
struct acrn_ptdev_irq *irq_info;
struct acrn_vm_memmap memmap;
+   struct acrn_msi_entry *msi;
struct acrn_pcidev *pcidev;
+   struct page *page;
int i, ret = 0;
 
if (vm->vmid == ACRN_INVALID_VMID && cmd != ACRN_IOCTL_CREATE_VM) {
@@ -198,6 +200,44 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
"Failed to reset intr for ptdev!\n");
kfree(irq_info);
break;
+   case ACRN_IOCTL_SET_IRQLINE:
+   ret = hcall_set_irqline(vm->vmid, ioctl_param);
+   if (ret < 0)
+   dev_dbg(acrn_dev.this_device,
+   "Failed to set interrupt line!\n");
+   break;
+   case ACRN_IOCTL_INJECT_MSI:
+   msi = memdup_user((void __user *)ioctl_param,
+ sizeof(struct acrn_msi_entry));
+   if (IS_ERR(msi))
+   return PTR_ERR(msi);
+
+   ret = hcall_inject_msi(vm->vmid, virt_to_phys(msi));
+   if (ret < 0)
+   dev_dbg(acrn_dev.this_device,
+   "Failed to inject MSI!\n");
+   kfree(msi);
+   break;
+   case ACRN_IOCTL_VM_INTR_MONITOR:
+   ret = pin_user_pages_fast(ioctl_param, 1,
+ FOLL_WRITE | FOLL_LONGTERM, );
+   if (unlikely(ret != 1)) {
+   dev_dbg(acrn_dev.this_device,
+   "Failed to pin intr hdr buffer!\n");
+   return -EFAULT;
+   }
+
+   ret = hcall_vm_intr_monitor(vm->vmid, page_to_phys(page));
+   if (ret < 0) {
+   unpin_user_page(page);
+   dev_dbg(acrn_dev.this_device,
+   "Failed to monitor intr data!\n");
+   return ret;
+   }
+   if (vm->monitor_page)
+   unpin_user_page(vm->monitor_page);
+   vm->monitor_page = page;
+   break;
case ACRN_IOCTL_CREATE_IOREQ_CLIENT:
if (vm->default_client)
return -EEXIST;
diff --git 

[PATCH v9 07/18] virt: acrn: Introduce an ioctl to set vCPU registers state

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

A virtual CPU of User VM has different context due to the different
registers state. ACRN userspace needs to set the virtual CPU
registers state (e.g. giving a initial registers state to a virtual
BSP of a User VM).

HSM provides an ioctl ACRN_IOCTL_SET_VCPU_REGS to do the virtual CPU
registers state setting. The ioctl passes the registers state from ACRN
userspace to the hypervisor directly.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/hsm.c   |  34 +-
 drivers/virt/acrn/hypercall.h |  13 
 include/uapi/linux/acrn.h | 119 ++
 3 files changed, 165 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 5fd933471683..ee5cc7413239 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -9,6 +9,7 @@
  * Yakui Zhao 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -46,7 +47,8 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
 {
struct acrn_vm *vm = filp->private_data;
struct acrn_vm_creation *vm_param;
-   int ret = 0;
+   struct acrn_vcpu_regs *cpu_regs;
+   int i, ret = 0;
 
if (vm->vmid == ACRN_INVALID_VMID && cmd != ACRN_IOCTL_CREATE_VM) {
dev_dbg(acrn_dev.this_device,
@@ -100,6 +102,36 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int 
cmd,
case ACRN_IOCTL_DESTROY_VM:
ret = acrn_vm_destroy(vm);
break;
+   case ACRN_IOCTL_SET_VCPU_REGS:
+   cpu_regs = memdup_user((void __user *)ioctl_param,
+  sizeof(struct acrn_vcpu_regs));
+   if (IS_ERR(cpu_regs))
+   return PTR_ERR(cpu_regs);
+
+   for (i = 0; i < ARRAY_SIZE(cpu_regs->reserved); i++)
+   if (cpu_regs->reserved[i])
+   return -EINVAL;
+
+   for (i = 0; i < ARRAY_SIZE(cpu_regs->vcpu_regs.reserved_32); 
i++)
+   if (cpu_regs->vcpu_regs.reserved_32[i])
+   return -EINVAL;
+
+   for (i = 0; i < ARRAY_SIZE(cpu_regs->vcpu_regs.reserved_64); 
i++)
+   if (cpu_regs->vcpu_regs.reserved_64[i])
+   return -EINVAL;
+
+   for (i = 0; i < ARRAY_SIZE(cpu_regs->vcpu_regs.gdt.reserved); 
i++)
+   if (cpu_regs->vcpu_regs.gdt.reserved[i] |
+   cpu_regs->vcpu_regs.idt.reserved[i])
+   return -EINVAL;
+
+   ret = hcall_set_vcpu_regs(vm->vmid, virt_to_phys(cpu_regs));
+   if (ret < 0)
+   dev_dbg(acrn_dev.this_device,
+   "Failed to set regs state of VM%u!\n",
+   vm->vmid);
+   kfree(cpu_regs);
+   break;
default:
dev_dbg(acrn_dev.this_device, "Unknown IOCTL 0x%x!\n", cmd);
ret = -ENOTTY;
diff --git a/drivers/virt/acrn/hypercall.h b/drivers/virt/acrn/hypercall.h
index 426b66cadb1f..f29cfae08862 100644
--- a/drivers/virt/acrn/hypercall.h
+++ b/drivers/virt/acrn/hypercall.h
@@ -19,6 +19,7 @@
 #define HC_START_VM_HC_ID(HC_ID, HC_ID_VM_BASE + 0x02)
 #define HC_PAUSE_VM_HC_ID(HC_ID, HC_ID_VM_BASE + 0x03)
 #define HC_RESET_VM_HC_ID(HC_ID, HC_ID_VM_BASE + 0x05)
+#define HC_SET_VCPU_REGS   _HC_ID(HC_ID, HC_ID_VM_BASE + 0x06)
 
 /**
  * hcall_create_vm() - Create a User VM
@@ -75,4 +76,16 @@ static inline long hcall_reset_vm(u64 vmid)
return acrn_hypercall1(HC_RESET_VM, vmid);
 }
 
+/**
+ * hcall_set_vcpu_regs() - Set up registers of virtual CPU of a User VM
+ * @vmid:  User VM ID
+ * @regs_state:Service VM GPA of registers state
+ *
+ * Return: 0 on success, <0 on failure
+ */
+static inline long hcall_set_vcpu_regs(u64 vmid, u64 regs_state)
+{
+   return acrn_hypercall2(HC_SET_VCPU_REGS, vmid, regs_state);
+}
+
 #endif /* __ACRN_HSM_HYPERCALL_H */
diff --git a/include/uapi/linux/acrn.h b/include/uapi/linux/acrn.h
index 32521168075f..775c58bad026 100644
--- a/include/uapi/linux/acrn.h
+++ b/include/uapi/linux/acrn.h
@@ -38,6 +38,123 @@ struct acrn_vm_creation {
__u64   cpu_affinity;
 };
 
+/**
+ * struct acrn_gp_regs - General registers of a User VM
+ * @rax:   Value of register RAX
+ * @rcx:   Value of register RCX
+ * @rdx:   Value of register RDX
+ * @rbx:   Value of register RBX
+ * @rsp:   Value of register RSP
+ * @rbp:   Value of register RBP
+ * @rsi:   Value of register RSI
+ * @rdi:   Value of register RDI
+ * @r8:Value of register R8
+ * @r9:Value of register R9
+ * @r10:   Value of register R10
+ * 

[PATCH v9 08/18] virt: acrn: Introduce EPT mapping management

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

The HSM provides hypervisor services to the ACRN userspace. While
launching a User VM, ACRN userspace needs to allocate memory and request
the ACRN Hypervisor to set up the EPT mapping for the VM.

A mapping cache is introduced for accelerating the translation between
the Service VM kernel virtual address and User VM physical address.

>From the perspective of the hypervisor, the types of GPA of User VM can be
listed as following:
   1) RAM region, which is used by User VM as system ram.
   2) MMIO region, which is recognized by User VM as MMIO. MMIO region is
  used to be utilized for devices emulation.

Generally, User VM RAM regions mapping is set up before VM started and
is released in the User VM destruction. MMIO regions mapping may be set
and unset dynamically during User VM running.

To achieve this, ioctls ACRN_IOCTL_SET_MEMSEG and ACRN_IOCTL_UNSET_MEMSEG
are introduced in HSM.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 drivers/virt/acrn/Makefile|   2 +-
 drivers/virt/acrn/acrn_drv.h  |  96 ++-
 drivers/virt/acrn/hsm.c   |  15 ++
 drivers/virt/acrn/hypercall.h |  14 ++
 drivers/virt/acrn/mm.c| 306 ++
 drivers/virt/acrn/vm.c|   4 +
 include/uapi/linux/acrn.h |  49 ++
 7 files changed, 476 insertions(+), 10 deletions(-)
 create mode 100644 drivers/virt/acrn/mm.c

diff --git a/drivers/virt/acrn/Makefile b/drivers/virt/acrn/Makefile
index cf8b4ed5e74e..38bc44b6edcd 100644
--- a/drivers/virt/acrn/Makefile
+++ b/drivers/virt/acrn/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_ACRN_HSM) := acrn.o
-acrn-y := hsm.o vm.o
+acrn-y := hsm.o vm.o mm.o
diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index e5aba86cad8c..e47a45280eea 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -12,26 +12,104 @@
 
 extern struct miscdevice acrn_dev;
 
+#define ACRN_MEM_MAPPING_MAX   256
+
+#define ACRN_MEM_REGION_ADD0
+#define ACRN_MEM_REGION_DEL2
+/**
+ * struct vm_memory_region_op - Hypervisor memory operation
+ * @type:  Operation type (ACRN_MEM_REGION_*)
+ * @attr:  Memory attribute (ACRN_MEM_TYPE_* | ACRN_MEM_ACCESS_*)
+ * @user_vm_pa:Physical address of User VM to be mapped.
+ * @service_vm_pa: Physical address of Service VM to be mapped.
+ * @size:  Size of this region.
+ *
+ * Structure containing needed information that is provided to ACRN Hypervisor
+ * to manage the EPT mappings of a single memory region of the User VM. Several
+ *  vm_memory_region_op can be batched to ACRN Hypervisor, see 
+ * vm_memory_region_batch.
+ */
+struct vm_memory_region_op {
+   u32 type;
+   u32 attr;
+   u64 user_vm_pa;
+   u64 service_vm_pa;
+   u64 size;
+};
+
+/**
+ * struct vm_memory_region_batch - A batch of vm_memory_region_op.
+ * @vmid:  A User VM ID.
+ * @reserved:  Reserved.
+ * @regions_num:   The number of vm_memory_region_op.
+ * @regions_gpa:   Physical address of a vm_memory_region_op array.
+ *
+ * HC_VM_SET_MEMORY_REGIONS uses this structure to manage EPT mappings of
+ * multiple memory regions of a User VM. A  vm_memory_region_batch
+ * contains multiple  vm_memory_region_op for batch processing in the
+ * ACRN Hypervisor.
+ */
+struct vm_memory_region_batch {
+   u16 vmid;
+   u16 reserved[3];
+   u32 regions_num;
+   u64 regions_gpa;
+};
+
+/**
+ * struct vm_memory_mapping - Memory map between a User VM and the Service VM
+ * @pages: Pages in Service VM kernel.
+ * @npages:Number of pages.
+ * @service_vm_va: Virtual address in Service VM kernel.
+ * @user_vm_pa:Physical address in User VM.
+ * @size:  Size of this memory region.
+ *
+ * HSM maintains memory mappings between a User VM GPA and the Service VM
+ * kernel VA for accelerating the User VM GPA translation.
+ */
+struct vm_memory_mapping {
+   struct page **pages;
+   int npages;
+   void*service_vm_va;
+   u64 user_vm_pa;
+   size_t  size;
+};
+
 #define ACRN_INVALID_VMID (0xU)
 
 #define ACRN_VM_FLAG_DESTROYED 0U
 /**
  * struct acrn_vm - Properties of ACRN User VM.
- * @list:  Entry within global list of all VMs
- * @vmid:  User VM ID
- * @vcpu_num:  Number of virtual CPUs in the VM
- * @flags: Flags (ACRN_VM_FLAG_*) of the VM. This is VM flag management
- * in HSM which is different from the _vm_creation.vm_flag.
+ * @list:  Entry within global list of all VMs.
+ * @vmid:  User VM ID.
+ * @vcpu_num:  Number of virtual CPUs in the VM.
+ * @flags: Flags 

[PATCH v9 04/18] x86/acrn: Introduce hypercall interfaces

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

The Service VM communicates with the hypervisor via conventional
hypercalls. VMCALL instruction is used to make the hypercalls.

ACRN hypercall ABI:
  * Hypercall number is in R8 register.
  * Up to 2 parameters are in RDI and RSI registers.
  * Return value is in RAX register.

Introduce the ACRN hypercall interfaces. Because GCC doesn't support R8
register as direct register constraints, use supported constraint as
input with a explicit MOV to R8 in beginning of asm.

Originally-by: Yakui Zhao 
Signed-off-by: Shuo Liu 
Reviewed-by: Reinette Chatre 
Reviewed-by: Nick Desaulniers 
Acked-by: Borislav Petkov 
Cc: Dave Hansen 
Cc: Sean Christopherson 
Cc: Dan Williams 
Cc: Fengwei Yin 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
Cc: Borislav Petkov 
Cc: Arvind Sankar 
Cc: Peter Zijlstra 
Cc: Nick Desaulniers 
Cc: Segher Boessenkool 
---
 arch/x86/include/asm/acrn.h | 54 +
 1 file changed, 54 insertions(+)

diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h
index 127f20672c5d..e003a01b7c67 100644
--- a/arch/x86/include/asm/acrn.h
+++ b/arch/x86/include/asm/acrn.h
@@ -21,4 +21,58 @@ static inline u32 acrn_cpuid_base(void)
return 0;
 }
 
+/*
+ * Hypercalls for ACRN
+ *
+ * - VMCALL instruction is used to implement ACRN hypercalls.
+ * - ACRN hypercall ABI:
+ *   - Hypercall number is passed in R8 register.
+ *   - Up to 2 arguments are passed in RDI, RSI.
+ *   - Return value will be placed in RAX.
+ *
+ * Because GCC doesn't support R8 register as direct register constraints, use
+ * supported constraint as input with a explicit MOV to R8 in beginning of asm.
+ */
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+   long result;
+
+   asm volatile("movl %1, %%r8d\n\t"
+"vmcall\n\t"
+: "=a" (result)
+: "g" (hcall_id)
+: "r8", "memory");
+
+   return result;
+}
+
+static inline long acrn_hypercall1(unsigned long hcall_id,
+  unsigned long param1)
+{
+   long result;
+
+   asm volatile("movl %1, %%r8d\n\t"
+"vmcall\n\t"
+: "=a" (result)
+: "g" (hcall_id), "D" (param1)
+: "r8", "memory");
+
+   return result;
+}
+
+static inline long acrn_hypercall2(unsigned long hcall_id,
+  unsigned long param1,
+  unsigned long param2)
+{
+   long result;
+
+   asm volatile("movl %1, %%r8d\n\t"
+"vmcall\n\t"
+: "=a" (result)
+: "g" (hcall_id), "D" (param1), "S" (param2)
+: "r8", "memory");
+
+   return result;
+}
+
 #endif /* _ASM_X86_ACRN_H */
-- 
2.28.0



[PATCH v9 05/18] virt: acrn: Introduce ACRN HSM basic driver

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

ACRN Hypervisor Service Module (HSM) is a kernel module in Service VM
which communicates with ACRN userspace through ioctls and talks to ACRN
Hypervisor through hypercalls.

Add a basic HSM driver which allows Service VM userspace to communicate
with ACRN. The following patches will add more ioctls, guest VM memory
mapping caching, I/O request processing, ioeventfd and irqfd into this
module. HSM exports a char device interface (/dev/acrn_hsm) to userspace.

Signed-off-by: Shuo Liu 
Reviewed-by: Reinette Chatre 
Cc: Dave Hansen 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 MAINTAINERS  |  1 +
 drivers/virt/Kconfig |  2 +
 drivers/virt/Makefile|  1 +
 drivers/virt/acrn/Kconfig| 14 ++
 drivers/virt/acrn/Makefile   |  3 ++
 drivers/virt/acrn/acrn_drv.h | 18 
 drivers/virt/acrn/hsm.c  | 87 
 7 files changed, 126 insertions(+)
 create mode 100644 drivers/virt/acrn/Kconfig
 create mode 100644 drivers/virt/acrn/Makefile
 create mode 100644 drivers/virt/acrn/acrn_drv.h
 create mode 100644 drivers/virt/acrn/hsm.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 3abd0fe60a58..e5d571290436 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -442,6 +442,7 @@ L:  acrn-...@lists.projectacrn.org
 S: Supported
 W: https://projectacrn.org
 F: Documentation/virt/acrn/
+F: drivers/virt/acrn/
 
 AD1889 ALSA SOUND DRIVER
 L: linux-par...@vger.kernel.org
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 80c5f9c16ec1..8061e8ef449f 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -34,4 +34,6 @@ config FSL_HV_MANAGER
 source "drivers/virt/vboxguest/Kconfig"
 
 source "drivers/virt/nitro_enclaves/Kconfig"
+
+source "drivers/virt/acrn/Kconfig"
 endif
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
index f28425ce4b39..3e272ea60cd9 100644
--- a/drivers/virt/Makefile
+++ b/drivers/virt/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_FSL_HV_MANAGER)+= fsl_hypervisor.o
 obj-y  += vboxguest/
 
 obj-$(CONFIG_NITRO_ENCLAVES)   += nitro_enclaves/
+obj-$(CONFIG_ACRN_HSM) += acrn/
diff --git a/drivers/virt/acrn/Kconfig b/drivers/virt/acrn/Kconfig
new file mode 100644
index ..36c80378c30c
--- /dev/null
+++ b/drivers/virt/acrn/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0
+config ACRN_HSM
+   tristate "ACRN Hypervisor Service Module"
+   depends on ACRN_GUEST
+   help
+ ACRN Hypervisor Service Module (HSM) is a kernel module which
+ communicates with ACRN userspace through ioctls and talks to
+ the ACRN Hypervisor through hypercalls. HSM will only run in
+ a privileged management VM, called Service VM, to manage User
+ VMs and do I/O emulation. Not required for simply running
+ under ACRN as a User VM.
+
+ To compile as a module, choose M, the module will be called
+ acrn. If unsure, say N.
diff --git a/drivers/virt/acrn/Makefile b/drivers/virt/acrn/Makefile
new file mode 100644
index ..6920ed798aaf
--- /dev/null
+++ b/drivers/virt/acrn/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_ACRN_HSM) := acrn.o
+acrn-y := hsm.o
diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
new file mode 100644
index ..29eedd696327
--- /dev/null
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ACRN_HSM_DRV_H
+#define __ACRN_HSM_DRV_H
+
+#include 
+
+#define ACRN_INVALID_VMID (0xU)
+
+/**
+ * struct acrn_vm - Properties of ACRN User VM.
+ * @vmid:  User VM ID
+ */
+struct acrn_vm {
+   u16 vmid;
+};
+
+#endif /* __ACRN_HSM_DRV_H */
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
new file mode 100644
index ..a8dcb250649d
--- /dev/null
+++ b/drivers/virt/acrn/hsm.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ACRN Hypervisor Service Module (HSM)
+ *
+ * Copyright (C) 2020 Intel Corporation. All rights reserved.
+ *
+ * Authors:
+ * Fengwei Yin 
+ * Yakui Zhao 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "acrn_drv.h"
+
+/*
+ * When /dev/acrn_hsm is opened, a 'struct acrn_vm' object is created to
+ * represent a VM instance and continues to be associated with the opened file
+ * descriptor. All ioctl operations on this file descriptor will be targeted to
+ * the VM instance. Release of this file descriptor will destroy the object.
+ */
+static int acrn_dev_open(struct inode *inode, struct file *filp)
+{
+   struct acrn_vm *vm;
+
+   vm = kzalloc(sizeof(*vm), GFP_KERNEL);
+   if (!vm)
+   return -ENOMEM;
+
+   vm->vmid = ACRN_INVALID_VMID;
+   filp->private_data = vm;
+   return 0;
+}
+
+static int acrn_dev_release(struct inode *inode, struct file *filp)
+{
+   struct 

[PATCH v9 06/18] virt: acrn: Introduce VM management interfaces

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

The VM management interfaces expose several VM operations to ACRN
userspace via ioctls. For example, creating VM, starting VM, destroying
VM and so on.

The ACRN Hypervisor needs to exchange data with the ACRN userspace
during the VM operations. HSM provides VM operation ioctls to the ACRN
userspace and communicates with the ACRN Hypervisor for VM operations
via hypercalls.

HSM maintains a list of User VM. Each User VM will be bound to an
existing file descriptor of /dev/acrn_hsm. The User VM will be
destroyed when the file descriptor is closed.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 .../userspace-api/ioctl/ioctl-number.rst  |  1 +
 MAINTAINERS   |  1 +
 drivers/virt/acrn/Makefile|  2 +-
 drivers/virt/acrn/acrn_drv.h  | 21 -
 drivers/virt/acrn/hsm.c   | 76 +-
 drivers/virt/acrn/hypercall.h | 78 +++
 drivers/virt/acrn/vm.c| 68 
 include/uapi/linux/acrn.h | 58 ++
 8 files changed, 301 insertions(+), 4 deletions(-)
 create mode 100644 drivers/virt/acrn/hypercall.h
 create mode 100644 drivers/virt/acrn/vm.c
 create mode 100644 include/uapi/linux/acrn.h

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index a4c75a28c839..0aec83c01368 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -319,6 +319,7 @@ Code  Seq#Include File  
 Comments
 0xA0  alllinux/sdp/sdp.h 
Industrial Device Project
  

 0xA1  0  linux/vtpm_proxy.h  TPM 
Emulator Proxy Driver
+0xA2  alluapi/linux/acrn.h   ACRN 
hypervisor
 0xA3  80-8F  Port ACL  
in development:
  

 0xA3  90-9F  linux/dtlk.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e5d571290436..4dcfa6e1e687 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -443,6 +443,7 @@ S:  Supported
 W: https://projectacrn.org
 F: Documentation/virt/acrn/
 F: drivers/virt/acrn/
+F: include/uapi/linux/acrn.h
 
 AD1889 ALSA SOUND DRIVER
 L: linux-par...@vger.kernel.org
diff --git a/drivers/virt/acrn/Makefile b/drivers/virt/acrn/Makefile
index 6920ed798aaf..cf8b4ed5e74e 100644
--- a/drivers/virt/acrn/Makefile
+++ b/drivers/virt/acrn/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_ACRN_HSM) := acrn.o
-acrn-y := hsm.o
+acrn-y := hsm.o vm.o
diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
index 29eedd696327..e5aba86cad8c 100644
--- a/drivers/virt/acrn/acrn_drv.h
+++ b/drivers/virt/acrn/acrn_drv.h
@@ -3,16 +3,35 @@
 #ifndef __ACRN_HSM_DRV_H
 #define __ACRN_HSM_DRV_H
 
+#include 
+#include 
+#include 
 #include 
 
+#include "hypercall.h"
+
+extern struct miscdevice acrn_dev;
+
 #define ACRN_INVALID_VMID (0xU)
 
+#define ACRN_VM_FLAG_DESTROYED 0U
 /**
  * struct acrn_vm - Properties of ACRN User VM.
+ * @list:  Entry within global list of all VMs
  * @vmid:  User VM ID
+ * @vcpu_num:  Number of virtual CPUs in the VM
+ * @flags: Flags (ACRN_VM_FLAG_*) of the VM. This is VM flag management
+ * in HSM which is different from the _vm_creation.vm_flag.
  */
 struct acrn_vm {
-   u16 vmid;
+   struct list_headlist;
+   u16 vmid;
+   int vcpu_num;
+   unsigned long   flags;
 };
 
+struct acrn_vm *acrn_vm_create(struct acrn_vm *vm,
+  struct acrn_vm_creation *vm_param);
+int acrn_vm_destroy(struct acrn_vm *vm);
+
 #endif /* __ACRN_HSM_DRV_H */
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index a8dcb250649d..5fd933471683 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -9,7 +9,6 @@
  * Yakui Zhao 
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -38,10 +37,82 @@ static int acrn_dev_open(struct inode *inode, struct file 
*filp)
return 0;
 }
 
+/*
+ * HSM relies on hypercall layer of the ACRN hypervisor to do the
+ * sanity check against the input parameters.
+ */
+static long acrn_dev_ioctl(struct file *filp, unsigned int cmd,
+  unsigned long ioctl_param)
+{
+   struct acrn_vm *vm = filp->private_data;
+   struct acrn_vm_creation *vm_param;
+   int ret = 0;
+
+   if (vm->vmid == ACRN_INVALID_VMID && cmd 

[PATCH v9 02/18] x86/acrn: Introduce acrn_{setup, remove}_intr_handler()

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

The ACRN Hypervisor builds an I/O request when a trapped I/O access
happens in User VM. Then, ACRN Hypervisor issues an upcall by sending
a notification interrupt to the Service VM. HSM in the Service VM needs
to hook the notification interrupt to handle I/O requests.

Notification interrupts from ACRN Hypervisor are already supported and
a, currently uninitialized, callback called.

Export two APIs for HSM to setup/remove its callback.

Originally-by: Yakui Zhao 
Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Acked-by: Borislav Petkov 
Cc: Dave Hansen 
Cc: Sean Christopherson 
Cc: Dan Williams 
Cc: Fengwei Yin 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 arch/x86/include/asm/acrn.h |  8 
 arch/x86/kernel/cpu/acrn.c  | 14 ++
 2 files changed, 22 insertions(+)
 create mode 100644 arch/x86/include/asm/acrn.h

diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h
new file mode 100644
index ..ff259b69cde7
--- /dev/null
+++ b/arch/x86/include/asm/acrn.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ACRN_H
+#define _ASM_X86_ACRN_H
+
+void acrn_setup_intr_handler(void (*handler)(void));
+void acrn_remove_intr_handler(void);
+
+#endif /* _ASM_X86_ACRN_H */
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index 0b2c03943ac6..e0c181781905 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -10,6 +10,8 @@
  */
 
 #include 
+
+#include 
 #include 
 #include 
 #include 
@@ -55,6 +57,18 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_acrn_hv_callback)
set_irq_regs(old_regs);
 }
 
+void acrn_setup_intr_handler(void (*handler)(void))
+{
+   acrn_intr_handler = handler;
+}
+EXPORT_SYMBOL_GPL(acrn_setup_intr_handler);
+
+void acrn_remove_intr_handler(void)
+{
+   acrn_intr_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(acrn_remove_intr_handler);
+
 const __initconst struct hypervisor_x86 x86_hyper_acrn = {
.name   = "ACRN",
.detect = acrn_detect,
-- 
2.28.0



[PATCH v9 03/18] x86/acrn: Introduce acrn_cpuid_base() and hypervisor feature bits

2021-02-06 Thread shuo . a . liu
From: Yin Fengwei 

ACRN Hypervisor reports hypervisor features via CPUID leaf 0x4001
which is similar to KVM. A VM can check if it's the privileged VM using
the feature bits. The Service VM is the only privileged VM by design.

Signed-off-by: Yin Fengwei 
Signed-off-by: Shuo Liu 
Reviewed-by: Reinette Chatre 
Acked-by: Borislav Petkov 
Cc: Dave Hansen 
Cc: Sean Christopherson 
Cc: Dan Williams 
Cc: Fengwei Yin 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
---
 arch/x86/include/asm/acrn.h | 16 
 arch/x86/kernel/cpu/acrn.c  |  2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h
index ff259b69cde7..127f20672c5d 100644
--- a/arch/x86/include/asm/acrn.h
+++ b/arch/x86/include/asm/acrn.h
@@ -2,7 +2,23 @@
 #ifndef _ASM_X86_ACRN_H
 #define _ASM_X86_ACRN_H
 
+/*
+ * This CPUID returns feature bitmaps in EAX.
+ * Guest VM uses this to detect the appropriate feature bit.
+ */
+#defineACRN_CPUID_FEATURES 0x4001
+/* Bit 0 indicates whether guest VM is privileged */
+#defineACRN_FEATURE_PRIVILEGED_VM  BIT(0)
+
 void acrn_setup_intr_handler(void (*handler)(void));
 void acrn_remove_intr_handler(void);
 
+static inline u32 acrn_cpuid_base(void)
+{
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   return hypervisor_cpuid_base("ACRNACRNACRN", 0);
+
+   return 0;
+}
+
 #endif /* _ASM_X86_ACRN_H */
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index e0c181781905..23f5f27b5a02 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -21,7 +21,7 @@
 
 static u32 __init acrn_detect(void)
 {
-   return hypervisor_cpuid_base("ACRNACRNACRN", 0);
+   return acrn_cpuid_base();
 }
 
 static void __init acrn_init_platform(void)
-- 
2.28.0



[PATCH v9 01/18] docs: acrn: Introduce ACRN

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

Add documentation on the following aspects of ACRN:

  1) A brief introduction on the architecture of ACRN.
  2) I/O request handling in ACRN.
  3) CPUID functions of ACRN.

To learn more about ACRN, please go to ACRN project website
https://projectacrn.org, or the documentation page
https://projectacrn.github.io/.

Signed-off-by: Shuo Liu 
Reviewed-by: Zhi Wang 
Reviewed-by: Reinette Chatre 
Reviewed-by: Borislav Petkov 
Cc: Dave Hansen 
Cc: Sen Christopherson 
Cc: Dan Williams 
Cc: Fengwei Yin 
Cc: Zhi Wang 
Cc: Zhenyu Wang 
Cc: Yu Wang 
Cc: Reinette Chatre 
Cc: Greg Kroah-Hartman 
Cc: Randy Dunlap 
---
 Documentation/virt/acrn/cpuid.rst| 46 +++
 Documentation/virt/acrn/index.rst| 12 +++
 Documentation/virt/acrn/introduction.rst | 43 +++
 Documentation/virt/acrn/io-request.rst   | 97 
 Documentation/virt/index.rst |  1 +
 MAINTAINERS  |  7 ++
 6 files changed, 206 insertions(+)
 create mode 100644 Documentation/virt/acrn/cpuid.rst
 create mode 100644 Documentation/virt/acrn/index.rst
 create mode 100644 Documentation/virt/acrn/introduction.rst
 create mode 100644 Documentation/virt/acrn/io-request.rst

diff --git a/Documentation/virt/acrn/cpuid.rst 
b/Documentation/virt/acrn/cpuid.rst
new file mode 100644
index ..65fa4b9c1798
--- /dev/null
+++ b/Documentation/virt/acrn/cpuid.rst
@@ -0,0 +1,46 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+ACRN CPUID bits
+===
+
+A guest VM running on an ACRN hypervisor can check some of its features using
+CPUID.
+
+ACRN cpuid functions are:
+
+function: 0x4000
+
+returns::
+
+   eax = 0x4010
+   ebx = 0x4e524341
+   ecx = 0x4e524341
+   edx = 0x4e524341
+
+Note that this value in ebx, ecx and edx corresponds to the string
+"ACRNACRNACRN". The value in eax corresponds to the maximum cpuid function
+present in this leaf, and will be updated if more functions are added in the
+future.
+
+function: define ACRN_CPUID_FEATURES (0x4001)
+
+returns::
+
+  ebx, ecx, edx
+  eax = an OR'ed group of (1 << flag)
+
+where ``flag`` is defined as below:
+
+= === 
+flag  value   meaning
+= === 
+ACRN_FEATURE_PRIVILEGED_VM0   guest VM is a privileged VM
+= === 
+
+function: 0x4010
+
+returns::
+
+  ebx, ecx, edx
+  eax = (Virtual) TSC frequency in kHz.
diff --git a/Documentation/virt/acrn/index.rst 
b/Documentation/virt/acrn/index.rst
new file mode 100644
index ..b5f793e73df5
--- /dev/null
+++ b/Documentation/virt/acrn/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+ACRN Hypervisor
+===
+
+.. toctree::
+   :maxdepth: 1
+
+   introduction
+   io-request
+   cpuid
diff --git a/Documentation/virt/acrn/introduction.rst 
b/Documentation/virt/acrn/introduction.rst
new file mode 100644
index ..f8d081bc084d
--- /dev/null
+++ b/Documentation/virt/acrn/introduction.rst
@@ -0,0 +1,43 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+ACRN Hypervisor Introduction
+
+
+The ACRN Hypervisor is a Type 1 hypervisor, running directly on bare-metal
+hardware. It has a privileged management VM, called Service VM, to manage User
+VMs and do I/O emulation.
+
+ACRN userspace is an application running in the Service VM that emulates
+devices for a User VM based on command line configurations. ACRN Hypervisor
+Service Module (HSM) is a kernel module in the Service VM which provides
+hypervisor services to the ACRN userspace.
+
+Below figure shows the architecture.
+
+::
+
+Service VMUser VM
+  ++  |  +--+
+  |+--+|  |  |  |
+  ||ACRN userspace||  |  |  |
+  |+--+|  |  |  |
+  |-ioctl--|  |  |  |   ...
+  |kernel space   +--+ |  |  |  |
+  |   |   HSM| |  |  | Drivers  |
+  |   +--+ |  |  |  |
+  +|---+  |  +--+
+  +-hypercall+
+  | ACRN Hypervisor  |
+  +--+
+  |  Hardware|
+  +--+
+
+ACRN userspace allocates memory for the User VM, configures and initializes the
+devices used by the User 

[PATCH 0/3] spi: add set_cs_timing support for HW/SW CS mode

2021-02-06 Thread Leilk Liu
Some controllers only have one HW CS, if support multiple devices, other 
devices need
to use SW CS.
This patch adds the support of both HW and SW CS via cs_gpio.

leilk.liu (3):
  spi: add power control when set_cs_timing
  spi: support CS timing for HW & SW mode
  spi: mediatek: add set_cs_timing support

 drivers/spi/spi-mt65xx.c | 72 +++-
 drivers/spi/spi.c| 32 +++---
 2 files changed, 83 insertions(+), 21 deletions(-)

-- 
2.18.0





[PATCH v9 00/18] HSM driver for ACRN hypervisor

2021-02-06 Thread shuo . a . liu
From: Shuo Liu 

ACRN is a Type 1 reference hypervisor stack, running directly on the bare-metal
hardware, and is suitable for a variety of IoT and embedded device solutions.

ACRN implements a hybrid VMM architecture, using a privileged Service VM. The
Service VM manages the system resources (CPU, memory, etc.) and I/O devices of
User VMs. Multiple User VMs are supported, with each of them running Linux,
Android OS or Windows. Both Service VM and User VMs are guest VM.

Below figure shows the architecture.

Service VMUser VM
  ++  |  +--+
  |+--+|  |  |  |
  ||ACRN userspace||  |  |  |
  |+--+|  |  |  |
  |-ioctl--|  |  |  |   ...
  |kernel space   +--+ |  |  |  |
  |   |   HSM| |  |  | Drivers  |
  |   +--+ |  |  |  |
  +|---+  |  +--+
  +-hypercall+
  |   ACRN Hypervisor|
  +--+
  |  Hardware|
  +--+

There is only one Service VM which could run Linux as OS.

In a typical case, the Service VM will be auto started when ACRN Hypervisor is
booted. Then the ACRN userspace (an application running in Service VM) could be
used to start/stop User VMs by communicating with ACRN Hypervisor Service
Module (HSM).

ACRN Hypervisor Service Module (HSM) is a middle layer that allows the ACRN
userspace and Service VM OS kernel to communicate with ACRN Hypervisor
and manage different User VMs. This middle layer provides the following
functionalities,
  - Issues hypercalls to the hypervisor to manage User VMs:
  * VM/vCPU management
  * Memory management
  * Device passthrough
  * Interrupts injection
  - I/O requests handling from User VMs.
  - Exports ioctl through HSM char device.
  - Exports function calls for other kernel modules

ACRN is focused on embedded system. So it doesn't support some features.
E.g.,
  - ACRN doesn't support VM migration.
  - ACRN doesn't support vCPU migration.

This patch set adds the HSM to the Linux kernel.
I also added a simple example to launch a small guest (with several instructions
as payload) on ACRN with demonstration ioctl usage.

The basic ARCN support was merged to upstream already.
https://lore.kernel.org/lkml/1559108037-18813-3-git-send-email-yakui.z...@intel.com/


ChangeLog:
v9:
  - Verified reserved fields of ioctls. (Greg)

v8:
  - Minor improved in documentation. (Randy)
  - Improved public header documentation. (Greg)
  - Verified more reserved fields of ioctls. (Greg)
  - Change tasklet to a high prio workqueue due to tasklets are deprecated. 
(Davidlohr)
  - Add Copyright for public header file. (Greg)

v7:
  - Typo fixed in documentation. (Boris)
  - Verified some reserved fields of ioctls. (Greg)
  - Rebased to v5.11-rc2.

v6:
  - Added the cpuid.rst documentation (Boris)
  - Deleted exported acrn_is_privileged_vm(), user detects feature bits by 
cpuid_eax() directly (Boris)
  - Used 'g' as the hcall_id constrain in hypercall definitions (Boris, Segher)
  - Removed unnecessary reserved fields from structures. Sorted some fields for 
alignment (Greg)
  - Used built-in kernel guid_t types (Greg)
  - Specified the endian of some fields in user/kernel interface structures 
(Greg)
  - Removed the alignment attribute from user/kernel interface structures (Greg)
  - Set reserved fields to zero (Greg)
  - Added a ioctl interface usage sample in the last patch (Greg)
  - Used pin_user_pages*() instead of get_user_pages*().

v5:
  - Corrected typo in documentation.
  - Removed unused pr_fmt().
  - Used supported constraint with a explicit MOV to R8 at beginning of ASM for 
hypercall interface.
  - Used dev_dbg() to replace dev_err() in places which might cause a DoS.
  - Introduced acrn_vm_list_lock as a mutex for friendly review.
  - Changed to use default attribute group list to add attribute files.

v4:
  - Used acrn_dev.this_device directly for dev_*() (Reinette)
  - Removed the odd usage of {get|put}_device() on _dev->this_device (Greg)
  - Removed unused log code. (Greg)
  - Corrected the return error values. (Greg)
  - Mentioned that HSM relies hypervisor for sanity check in acrn_dev_ioctl() 
comments (Greg)

v3:
  - Used {get|put}_device() helpers on _dev->this_device
  - Moved unused code from front patches to later ones.
  - Removed self-defined pr_fmt() and dev_fmt()
  - Provided comments for acrn_vm_list_lock.

v2:
  - Removed API version related code. (Dave)
  - 

Re: [PATCH 2/3] kbuild: clamp SUBLEVEL to 255

2021-02-06 Thread Masahiro Yamada
On Sat, Feb 6, 2021 at 12:50 PM Sasha Levin  wrote:
>
> Right now if SUBLEVEL becomes larger than 255 it will overflow into the
> territory of PATCHLEVEL, causing havoc in userspace that tests for
> specific kernel version.
>
> While userspace code tests for MAJOR and PATCHLEVEL, it doesn't test
> SUBLEVEL at any point as ABI changes don't happen in the context of
> stable tree.
>
> Thus, to avoid overflows, simply clamp SUBLEVEL to it's maximum value in
> the context of LINUX_VERSION_CODE. This does not affect "make
> kernelversion" and such.
>
> Signed-off-by: Sasha Levin 


I applied 2/3 to linux-kbuild.

Please resend only 3/3.

Thanks.



> ---
>  Makefile | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 49ac1b7fe8e99..157be50c691e5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1258,9 +1258,15 @@ define filechk_utsrelease.h
>  endef
>
>  define filechk_version.h
> -   echo \#define LINUX_VERSION_CODE $(shell \
> -   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> -   echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
> +   if [ $(SUBLEVEL) -gt 255 ]; then \
> +   echo \#define LINUX_VERSION_CODE $(shell \
> +   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255); \
> +   else \
> +   echo \#define LINUX_VERSION_CODE $(shell \
> +   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 
> $(SUBLEVEL)); \
> +   fi;  \
> +   echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \
> +   ((c) > 255 ? 255 : (c)))'
>  endef
>
>  $(version_h): FORCE
> --
> 2.27.0
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH v3 3/3] scsi: ufs: Fix wrong Task Tag used in task management request UPIUs

2021-02-06 Thread Bart Van Assche
On 2/4/21 10:09 PM, Can Guo wrote:
> That code is wrong. The Task Tag in Dword_0 should be the real tag we
> allocated for TMR. The transfer request Task Tag which we are trying to
> abort is given in Dword_5, which is the Input Parameter 3 of the TMR UPIU.
> I am not sure why the author gave hba->nutrs + req->tag as the Task Tag
> of one TMR, the commit msg abot this part is not quite informative
> 
> Table 10.22 — Task Management Request UPIU
> TASK MANAGEMENT REQUEST UPIU
> --
> |0 |1  |2   |3   |
> --
> |xx00 0100b| Flags |LUN |Task Tag|
> --
> ...
> 16 (MSB)   |17 |18  |19 (LSB)|
> --
> Input Parameter 2
> --
> 
> Table 10.24 — Task Management Input Parameters
> Field Description
> Input Parameter 2 LSB: Task Tag of the task/command operated by the task
> management function.

Thanks for the clarification. Feel free to add the following to this patch:

Reviewed-by: Bart Van Assche 


Re: [PATCH 3/3] ia64: remove generated/nr-irqs.h generation to fix build warning

2021-02-06 Thread Masahiro Yamada
On Sat, Aug 29, 2020 at 2:15 PM Masahiro Yamada  wrote:
>
> Randy reports the following warning when building ARCH=ia64 with
> CONFIG_IA64_PALINFO=m:
>
> ../scripts/Makefile.build:68: 'arch/ia64/kernel/palinfo.ko' will not be built 
> even though obj-m is specified.
> ../scripts/Makefile.build:69: You cannot use subdir-y/m to visit a module 
> Makefile. Use obj-y/m instead.
>
> This message is actually false-positive, and you can get palinfo.ko
> correctly built. It is emitted in the archprepare stage, where Kbuild
> descends into arch/ia64/kernel to generate include/generated/nr-irqs.h
> instead of any kind of kernel objects.
>
> arch/ia64/kernel/nr-irqs.c was introduced by commit 213060a4d699
> ("[IA64] pvops: paravirtualize NR_IRQS") to pre-calculate:
>
>NR_IRQS = max(IA64_NATIVE_NR_IRQS, XEN_NR_IRQS, FOO_NR_IRQS...)
>
> Since commit d52eefb47d4e ("ia64/xen: Remove Xen support for ia64"), this
> union contains just one field, making NR_IRQS and IA64_NATIVE_NR_IRQS
> always match.
>
> So, the following hard-coding now works:
>
>   #define NR_IRQSIA64_NATIVE_NR_IRQS
>
> If you need to re-introduce NR_IRQS = max(...) gimmick in the future,
> please try to implement it in asm-offsets.c instead of a separate file.
> It will be possible because the header inclusion has been consolidated
> to make asm-offsets.c independent of .
>
> Reported-by: Randy Dunlap 
> Signed-off-by: Masahiro Yamada 


This build issue is still remaining.

I will send this series in the next MW
via my kbuild tree.





> ---
>
>  arch/ia64/Makefile  |  6 --
>  arch/ia64/include/asm/irq.h |  4 +++-
>  arch/ia64/kernel/Makefile   |  5 -
>  arch/ia64/kernel/nr-irqs.c  | 22 --
>  4 files changed, 3 insertions(+), 34 deletions(-)
>  delete mode 100644 arch/ia64/kernel/nr-irqs.c
>
> diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
> index 2876a7df1b0a..3d54d411fcc4 100644
> --- a/arch/ia64/Makefile
> +++ b/arch/ia64/Makefile
> @@ -87,9 +87,3 @@ define archhelp
>echo '  install  - Install compressed kernel image'
>echo '* unwcheck - Check vmlinux for invalid unwind info'
>  endef
> -
> -archprepare: make_nr_irqs_h
> -PHONY += make_nr_irqs_h
> -
> -make_nr_irqs_h:
> -   $(Q)$(MAKE) $(build)=arch/ia64/kernel include/generated/nr-irqs.h
> diff --git a/arch/ia64/include/asm/irq.h b/arch/ia64/include/asm/irq.h
> index 5acf52e90872..0eccf33dfe8b 100644
> --- a/arch/ia64/include/asm/irq.h
> +++ b/arch/ia64/include/asm/irq.h
> @@ -14,7 +14,9 @@
>
>  #include 
>  #include 
> -#include 
> +#include 
> +
> +#define NR_IRQSIA64_NATIVE_NR_IRQS
>
>  static __inline__ int
>  irq_canonicalize (int irq)
> diff --git a/arch/ia64/kernel/Makefile b/arch/ia64/kernel/Makefile
> index 1a8df6669eee..7c9354ee4b3e 100644
> --- a/arch/ia64/kernel/Makefile
> +++ b/arch/ia64/kernel/Makefile
> @@ -48,8 +48,3 @@ CFLAGS_traps.o  += -mfixed-range=f2-f5,f16-f31
>
>  # The gate DSO image is built using a special linker script.
>  include $(src)/Makefile.gate
> -
> -include/generated/nr-irqs.h: arch/$(SRCARCH)/kernel/nr-irqs.s FORCE
> -   $(call filechk,offsets,__ASM_NR_IRQS_H__)
> -
> -targets += nr-irqs.s
> diff --git a/arch/ia64/kernel/nr-irqs.c b/arch/ia64/kernel/nr-irqs.c
> deleted file mode 100644
> index f2633b22d3be..
> --- a/arch/ia64/kernel/nr-irqs.c
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * calculate
> - * NR_IRQS = max(IA64_NATIVE_NR_IRQS, XEN_NR_IRQS, FOO_NR_IRQS...)
> - * depending on config.
> - * This must be calculated before processing asm-offset.c.
> - */
> -
> -#define ASM_OFFSETS_C 1
> -
> -#include 
> -#include 
> -#include 
> -
> -void foo(void)
> -{
> -   union paravirt_nr_irqs_max {
> -   char ia64_native_nr_irqs[IA64_NATIVE_NR_IRQS];
> -   };
> -
> -   DEFINE(NR_IRQS, sizeof (union paravirt_nr_irqs_max));
> -}
> --
> 2.25.1
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH 3/3] crypto: hisilicon/sec - fixes shash test error

2021-02-06 Thread liulongfang
On 2021/2/5 19:44, Herbert Xu write:
> On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
>> If this configuration item is not turned on,
>> the allocation of crypto_tfm will fail when
>> the shash algorithm calculates the hash
>> through the software.
>>
>> Signed-off-by: Longfang Liu 
>> ---
>>  arch/arm64/configs/defconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index 8383016..7cfc9b6 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -117,7 +117,7 @@ CONFIG_KVM=y
>>  CONFIG_ARM64_CRYPTO=y
>>  CONFIG_CRYPTO_SHA1_ARM64_CE=y
>>  CONFIG_CRYPTO_SHA2_ARM64_CE=y
>> -CONFIG_CRYPTO_SHA512_ARM64_CE=m
>> +CONFIG_CRYPTO_SHA512_ARM64_CE=y
> 
> If this is truly needed then it should be enabled through Kconfig.
> 
> Cheers,
> 
Hi Herbert,
The option select CRYPTO_SHA512 already exists in Kconfig.
Can I change it to this: select CRYPTO_SHA512 || CRYPTO_SHA512_ARM64_CE
Thanks,
Longfang Liu.


[GIT PULL] Kbuild fixes for v5.11-rc7

2021-02-06 Thread Masahiro Yamada
Hi Linus,

Please pull some Kbuild fixes.
Thanks.






The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31:

  Linux 5.11-rc4 (2021-01-17 16:37:05 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-fixes-v5.11-2

for you to fetch changes up to efe6e3068067212b85c2d0474b5ee3b2d0c7adab:

  kallsyms: fix nonconverging kallsyms table with lld (2021-02-05
17:53:28 +0900)


Kbuild fixes for v5.11 (2nd)

 - Use the 'python3' command to invoke python scripts because some
   distributions do not provide the 'python' command any more.

 - Clean-up and update documents

 - Use pkg-config to search libcrypto

 - Fix duplicated debug flags

 - Ignore some more stubs in scripts/kallsyms.c


Andy Shevchenko (1):
  scripts: switch explicitly to Python 3

Arnd Bergmann (1):
  kallsyms: fix nonconverging kallsyms table with lld

Enrico Weigelt, metux IT consult (1):
  kconfig: mconf: fix HOSTCC call

Masahiro Yamada (6):
  kbuild: simplify GCC_PLUGINS enablement in dummy-tools/gcc
  doc: gcc-plugins: update gcc-plugins.rst
  Revert "checkpatch: add check for keyword 'boolean' in Kconfig
definitions"
  kbuild: remove PYTHON variable
  scripts/clang-tools: switch explicitly to Python 3
  kbuild: fix duplicated flags in DEBUG_CFLAGS

Nathan Chancellor (1):
  Documentation/llvm: Add a section about supported architectures

Robert Karszniewicz (1):
  Documentation/Kbuild: Remove references to gcc-plugin.sh

Rolf Eike Beer (1):
  scripts: use pkg-config to locate libcrypto

 Documentation/Makefile  |  2 +-
 Documentation/kbuild/gcc-plugins.rst| 47
+-
 Documentation/kbuild/llvm.rst   | 44
+++
 Documentation/kbuild/makefiles.rst  |  2 +-
 Makefile|  7 +++---
 arch/ia64/Makefile  |  2 +-
 arch/ia64/scripts/unwcheck.py   |  2 +-
 scripts/Makefile|  8 +--
 scripts/bloat-o-meter   |  2 +-
 scripts/checkpatch.pl   |  7 --
 scripts/clang-tools/gen_compile_commands.py |  2 +-
 scripts/clang-tools/run-clang-tools.py  |  2 +-
 scripts/diffconfig  |  2 +-
 scripts/dummy-tools/gcc | 10 +++-
 scripts/jobserver-exec  |  2 +-
 scripts/kallsyms.c  |  6 +
 scripts/kconfig/mconf-cfg.sh|  2 +-
 17 files changed, 94 insertions(+), 55 deletions(-)


--
Best Regards
Masahiro Yamada


Re: [PATCH] arm64: Make CPU_BIG_ENDIAN depend on !LD_IS_LLD

2021-02-06 Thread Nathan Chancellor
On Mon, Feb 01, 2021 at 07:24:42PM -0700, Nathan Chancellor wrote:
> Similar to commit 28187dc8ebd9 ("ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN
> depends on !LD_IS_LLD"), ld.lld does not support aarch64 big endian,
> leading to the following build error when CONFIG_CPU_BIG_ENDIAN is
> selected:
> 
> ld.lld: error: unknown emulation: aarch64linuxb
> 
> There are not currently plans to implement big endian support for
> aarch64 in ld.lld but if it should be supported in the future, this
> symbol can depend on the version that first supports it. In the
> meantime, prevent this symbol from being selected to avoid these type
> of build errors.
> 
> While we are here, the indentation of this symbol used spaces since its
> introduction in commit a872013d6d03 ("arm64: kconfig: allow
> CPU_BIG_ENDIAN to be selected"). Change it to tabs to be consistent with
> kernel coding style.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/380
> Link: https://github.com/ClangBuiltLinux/linux/issues/1288
> Reported-by: Arnd Bergmann 
> Signed-off-by: Nathan Chancellor 

Fangrui has pushed proper aarch64linuxb and elf64-bigaarch64 for ld.lld:

https://reviews.llvm.org/D96211
https://reviews.llvm.org/D96188

This patch is needed for OUTPUT_FORMAT in the vDSO to work properly:

https://reviews.llvm.org/D96214

Once these are all merged into LLVM 13, I will update this to be:

depends on !LD_IS_LLD || LLD_VERSION >= 13

Cheers,
Nathan

> ---
>  arch/arm64/Kconfig | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f39568b28ec1..5ddf9fe7b4ee 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -952,8 +952,9 @@ choice
> that is selected here.
>  
>  config CPU_BIG_ENDIAN
> -   bool "Build big-endian kernel"
> -   help
> + bool "Build big-endian kernel"
> + depends on !LD_IS_LLD
> + help
> Say Y if you plan on running a kernel with a big-endian userspace.
>  
>  config CPU_LITTLE_ENDIAN
> 
> base-commit: 88bb507a74ea7d75fa49edd421eaa710a7d80598
> -- 
> 2.30.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Re: [RFC PATCH v2 2/3] usb: xhci-mtk: modify the SOF/ITP interval for mt8195

2021-02-06 Thread Chunfeng Yun
Hi Mathias,

On Wed, 2021-02-03 at 18:26 +0800, Chunfeng Yun wrote:
> There are 4 USB controllers on MT8195, the controllers (IP1~IP3,
> exclude IP0) have a wrong default SOF/ITP interval which is
> calculated from the frame counter clock 24Mhz by default, but
> in fact, the frame counter clock is 48Mhz, so we should set
> the accurate interval according to 48Mhz for those controllers.
> Note: the first controller no need set it.
> 
> Signed-off-by: Chunfeng Yun 
> ---
> v2: fix typo of comaptible
> ---
>  drivers/usb/host/xhci-mtk.c | 63 +
>  1 file changed, 63 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> index 8f321f39ab96..0a68c4ac8b48 100644
> --- a/drivers/usb/host/xhci-mtk.c
> +++ b/drivers/usb/host/xhci-mtk.c
> @@ -68,11 +68,71 @@
>  #define SSC_IP_SLEEP_EN  BIT(4)
>  #define SSC_SPM_INT_EN   BIT(1)
>  
Can I Read/Write the following xHCI controller's registers  in
xhci-mtk.c?

Ideally, xhci-mtk.c should not access them, because xhci-mtk is only a
glue driver used to initialize clocks/power and IPPC registers which
don't belong to xHCI controller.

Thanks

> +/* xHCI csr */
> +#define LS_EOF   0x930
> +#define LS_EOF_OFFSET0x89
> +
> +#define FS_EOF   0x934
> +#define FS_EOF_OFFSET0x2e
> +
> +#define SS_GEN1_EOF  0x93c
> +#define SS_GEN1_EOF_OFFSET   0x78
> +
> +#define HFCNTR_CFG   0x944
> +#define ITP_DELTA_CLK(0xa << 1)
> +#define ITP_DELTA_CLK_MASK   GENMASK(5, 1)
> +#define FRMCNT_LEV1_RANG (0x12b << 8)
> +#define FRMCNT_LEV1_RANG_MASKGENMASK(19, 8)
> +
> +#define SS_GEN2_EOF  0x990
> +#define SS_GEN2_EOF_OFFSET   0x3c
> +#define EOF_OFFSET_MASK  GENMASK(11, 0)
> +
>  enum ssusb_uwk_vers {
>   SSUSB_UWK_V1 = 1,
>   SSUSB_UWK_V2,
>  };
>  
> +/*
> + * MT8195 has 4 controllers, the controller1~3's default SOF/ITP interval
> + * is calculated from the frame counter clock 24M, but in fact, the clock
> + * is 48M, so need change the interval.
> + */
> +static void xhci_mtk_set_frame_interval(struct xhci_hcd_mtk *mtk)
> +{
> + struct device *dev = mtk->dev;
> + struct usb_hcd *hcd = mtk->hcd;
> + u32 value;
> +
> + if (!of_device_is_compatible(dev->of_node, "mediatek,mt8195-xhci"))
> + return;
> +
> + value = readl(hcd->regs + HFCNTR_CFG);
> + value &= ~(ITP_DELTA_CLK_MASK | FRMCNT_LEV1_RANG_MASK);
> + value |= (ITP_DELTA_CLK | FRMCNT_LEV1_RANG);
> + writel(value, hcd->regs + HFCNTR_CFG);
> +
> + value = readl(hcd->regs + LS_EOF);
> + value &= ~EOF_OFFSET_MASK;
> + value |= LS_EOF_OFFSET;
> + writel(value, hcd->regs + LS_EOF);
> +
> + value = readl(hcd->regs + FS_EOF);
> + value &= ~EOF_OFFSET_MASK;
> + value |= FS_EOF_OFFSET;
> + writel(value, hcd->regs + FS_EOF);
> +
> + value = readl(hcd->regs + SS_GEN1_EOF);
> + value &= ~EOF_OFFSET_MASK;
> + value |= SS_GEN1_EOF_OFFSET;
> + writel(value, hcd->regs + SS_GEN1_EOF);
> +
> + value = readl(hcd->regs + SS_GEN2_EOF);
> + value &= ~EOF_OFFSET_MASK;
> + value |= SS_GEN2_EOF_OFFSET;
> + writel(value, hcd->regs + SS_GEN2_EOF);
> +}
> +
>  static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
>  {
>   struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
> @@ -407,6 +467,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
>   ret = xhci_mtk_ssusb_config(mtk);
>   if (ret)
>   return ret;
> +
> + xhci_mtk_set_frame_interval(mtk);
>   }
>  
>   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
> @@ -655,6 +717,7 @@ static const struct dev_pm_ops xhci_mtk_pm_ops = {
>  #ifdef CONFIG_OF
>  static const struct of_device_id mtk_xhci_of_match[] = {
>   { .compatible = "mediatek,mt8173-xhci"},
> + { .compatible = "mediatek,mt8195-xhci"},
>   { .compatible = "mediatek,mtk-xhci"},
>   { },
>  };



Re: [RFC PATCH v1 1/2] block: bsg: resume scsi device before accessing

2021-02-06 Thread Bart Van Assche
On 1/26/21 8:00 PM, Asutosh Das wrote:
> Resumes the scsi device before accessing it.
> 
> Change-Id: I2929af60f2a92c89704a582fcdb285d35b429fde
> Signed-off-by: Asutosh Das 
> Signed-off-by: Can Guo 
> Signed-off-by: Bao D. Nguyen 

No Change-Id tags in upstream patches please.

Thanks,

Bart.


Re: [PATCH] mm/hugetlb: use helper huge_page_size() to simplify the hugetlb_vm_op_pagesize()

2021-02-06 Thread Miaohe Lin
On 2021/2/6 0:12, David Hildenbrand wrote:
> On 05.02.21 10:22, Miaohe Lin wrote:
>> We can use helper huge_page_size() to get the size of the pages allocated
>> when backing a VMA directly to make the code more simplified.
>>
>> Signed-off-by: Miaohe Lin 
>> ---
>>   mm/hugetlb.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 18628f8dbfb0..3eea2a34d9f5 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3647,9 +3647,7 @@ static int hugetlb_vm_op_split(struct vm_area_struct 
>> *vma, unsigned long addr)
>>     static unsigned long hugetlb_vm_op_pagesize(struct vm_area_struct *vma)
>>   {
>> -    struct hstate *hstate = hstate_vma(vma);
>> -
>> -    return 1UL << huge_page_shift(hstate);
>> +    return huge_page_size(hstate_vma(vma));
>>   }
> 
> Maybe it makes sense to squash all of these individual patches you send that 
> do the same things/perform the same cleanups. Shouldn't be to hard to 
> identify all these cases using simple "git grep".
> 

Many thanks for your advice. I'am studying the mm code and find these cleanups 
when I come across these code.
I postponed these cleanups but forgot trying to squash the patches that do the 
same things. I would try to
identify all the same cases using "git grep" rather than relying on code review.

> Makes life of reviewers and maintainers easier ...
> 

My bad. Sorry.

> 

Thanks again.


Re: [RFC PATCH 01/11] iommu/arm-smmu-v3: Add feature detection for HTTU

2021-02-06 Thread Keqian Zhu
Hi Robin,

On 2021/2/5 19:48, Robin Murphy wrote:
> On 2021-02-05 09:13, Keqian Zhu wrote:
>> Hi Robin and Jean,
>>
>> On 2021/2/5 3:50, Robin Murphy wrote:
>>> On 2021-01-28 15:17, Keqian Zhu wrote:
 From: jiangkunkun 

 The SMMU which supports HTTU (Hardware Translation Table Update) can
 update the access flag and the dirty state of TTD by hardware. It is
 essential to track dirty pages of DMA.

 This adds feature detection, none functional change.

 Co-developed-by: Keqian Zhu 
 Signed-off-by: Kunkun Jiang 
 ---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16 
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  8 
include/linux/io-pgtable.h  |  1 +
3 files changed, 25 insertions(+)

 diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
 b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
 index 8ca7415d785d..0f0fe71cc10d 100644
 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
 +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
 @@ -1987,6 +1987,7 @@ static int arm_smmu_domain_finalise(struct 
 iommu_domain *domain,
.pgsize_bitmap= smmu->pgsize_bitmap,
.ias= ias,
.oas= oas,
 +.httu_hd= smmu->features & ARM_SMMU_FEAT_HTTU_HD,
.coherent_walk= smmu->features & ARM_SMMU_FEAT_COHERENCY,
.tlb= _smmu_flush_ops,
.iommu_dev= smmu->dev,
 @@ -3224,6 +3225,21 @@ static int arm_smmu_device_hw_probe(struct 
 arm_smmu_device *smmu)
if (reg & IDR0_HYP)
smmu->features |= ARM_SMMU_FEAT_HYP;
+switch (FIELD_GET(IDR0_HTTU, reg)) {
>>>
>>> We need to accommodate the firmware override as well if we need this to be 
>>> meaningful. Jean-Philippe is already carrying a suitable patch in the SVA 
>>> stack[1].
>> Robin, Thanks for pointing it out.
>>
>> Jean, I see that the IORT HTTU flag overrides the hardware register info 
>> unconditionally. I have some concern about it:
>>
>> If the override flag has HTTU but hardware doesn't support it, then driver 
>> will use this feature but receive access fault or permission fault from SMMU 
>> unexpectedly.
>> 1) If IOPF is not supported, then kernel can not work normally.
>> 2) If IOPF is supported, kernel will perform useless actions, such as HTTU 
>> based dma dirty tracking (this series).
> 
> Yes, if the IORT describes the SMMU incorrectly, things will not work well. 
> Just like if it describes the wrong base address or the wrong interrupt 
> numbers, things will also not work well. The point is that incorrect firmware 
> can be updated in the field fairly easily; incorrect hardware can not.
Agree.

> 
> Say the SMMU designer hard-codes the ID register field to 0x2 because the 
> SMMU itself is capable of HTTU, and they assume it's always going to be wired 
> up coherently, but then a customer integrates it to a non-coherent 
> interconnect. Firmware needs to override that value to prevent an OS thinking 
> that the claimed HTTU capability is ever going to work.
> 
> Or say the SMMU *is* integrated correctly, but due to an erratum discovered 
> later in the interconnect or SMMU itself, it turns out DBM doesn't always 
> work reliably, but AF is still OK. Firmware needs to downgrade the indicated 
> level of support from that which was intended to that which works reliably.
> 
> Or say someone forgets to set an integration tieoff so their SMMU reports 0x0 
> even though it and the interconnect *can* happily support HTTU. In that case, 
> firmware may want to upgrade the value to *allow* an OS to use HTTU despite 
> the ID register being wrong.
Fair enough. Mask can realize "downgrade", but not "upgrade". You give a 
reasonable point for upgrade.

BTW, my original intention is that mask can provide some convenience for BIOS 
maker, as the override flag can keep same for SMMUs regardless they support 
HTTU or not. But it shows that mask cannot cover all scenario.

> 
>> As the IORT spec doesn't give an explicit explanation for HTTU override, can 
>> we comprehend it as a mask for HTTU related hardware register?
>> So the logic becomes: smmu->feature = HTTU override & IDR0_HTTU;
> 
> No, it literally states that the OS must use the value of the firmware field 
> *instead* of the value from the hardware field.
Yep, I just get the latest version and see it.

> 
 +case IDR0_HTTU_NONE:
 +break;
 +case IDR0_HTTU_HA:
 +smmu->features |= ARM_SMMU_FEAT_HTTU_HA;
 +break;
 +case IDR0_HTTU_HAD:
 +smmu->features |= ARM_SMMU_FEAT_HTTU_HA;
 +smmu->features |= ARM_SMMU_FEAT_HTTU_HD;
 +break;
 +default:
 +dev_err(smmu->dev, "unknown/unsupported HTTU!\n");
 +return -ENXIO;
 +}
 +
/*
 * The coherency 

drivers/media/i2c/ccs-pll.c:386:5: warning: stack frame size of 2976 bytes in function 'ccs_pll_calculate'

2021-02-06 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   61556703b610a104de324e4f061dc6cf7b218b46
commit: 9e05bbac43ebfc2fd1ff95e072730ceed807d149 media: smiapp-pll: Rename as 
ccs-pll
date:   9 weeks ago
config: powerpc64-randconfig-r025-20210205 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
c9439ca36342fb6013187d0a69aef92736951476)
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
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9e05bbac43ebfc2fd1ff95e072730ceed807d149
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 9e05bbac43ebfc2fd1ff95e072730ceed807d149
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
ARCH=powerpc64 

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

All warnings (new ones prefixed by >>):

>> drivers/media/i2c/ccs-pll.c:386:5: warning: stack frame size of 2976 bytes 
>> in function 'ccs_pll_calculate' [-Wframe-larger-than=]
   int ccs_pll_calculate(struct device *dev, const struct ccs_pll_limits 
*limits,
   ^
   1 warning generated.


vim +/ccs_pll_calculate +386 drivers/media/i2c/ccs-pll.c

   385  
 > 386  int ccs_pll_calculate(struct device *dev, const struct ccs_pll_limits 
 > *limits,
   387struct ccs_pll *pll)
   388  {
   389  const struct ccs_pll_branch_limits *op_limits = >op;
   390  struct ccs_pll_branch *op_pll = >op;
   391  uint16_t min_pre_pll_clk_div;
   392  uint16_t max_pre_pll_clk_div;
   393  uint32_t lane_op_clock_ratio;
   394  uint32_t mul, div;
   395  unsigned int i;
   396  int rval = -EINVAL;
   397  
   398  if (pll->flags & CCS_PLL_FLAG_NO_OP_CLOCKS) {
   399  /*
   400   * If there's no OP PLL at all, use the VT values
   401   * instead. The OP values are ignored for the rest of
   402   * the PLL calculation.
   403   */
   404  op_limits = >vt;
   405  op_pll = >vt;
   406  }
   407  
   408  if (pll->flags & CCS_PLL_FLAG_OP_PIX_CLOCK_PER_LANE)
   409  lane_op_clock_ratio = pll->csi2.lanes;
   410  else
   411  lane_op_clock_ratio = 1;
   412  dev_dbg(dev, "lane_op_clock_ratio: %u\n", lane_op_clock_ratio);
   413  
   414  dev_dbg(dev, "binning: %ux%u\n", pll->binning_horizontal,
   415  pll->binning_vertical);
   416  
   417  switch (pll->bus_type) {
   418  case CCS_PLL_BUS_TYPE_CSI2:
   419  /* CSI transfers 2 bits per clock per lane; thus times 
2 */
   420  pll->pll_op_clk_freq_hz = pll->link_freq * 2
   421  * (pll->csi2.lanes / lane_op_clock_ratio);
   422  break;
   423  case CCS_PLL_BUS_TYPE_PARALLEL:
   424  pll->pll_op_clk_freq_hz = pll->link_freq * 
pll->bits_per_pixel
   425  / DIV_ROUND_UP(pll->bits_per_pixel,
   426 pll->parallel.bus_width);
   427  break;
   428  default:
   429  return -EINVAL;
   430  }
   431  
   432  /* Figure out limits for pre-pll divider based on extclk */
   433  dev_dbg(dev, "min / max pre_pll_clk_div: %u / %u\n",
   434  limits->min_pre_pll_clk_div, 
limits->max_pre_pll_clk_div);
   435  max_pre_pll_clk_div =
   436  min_t(uint16_t, limits->max_pre_pll_clk_div,
   437clk_div_even(pll->ext_clk_freq_hz /
   438 limits->min_pll_ip_freq_hz));
   439  min_pre_pll_clk_div =
   440  max_t(uint16_t, limits->min_pre_pll_clk_div,
   441clk_div_even_up(
   442DIV_ROUND_UP(pll->ext_clk_freq_hz,
   443 
limits->max_pll_ip_freq_hz)));
   444  dev_dbg(dev, "pre-pll check: min / max pre_pll_clk_div: %u / 
%u\n",
   445  min_pre_pll_clk_div, max_pre_pll_clk_div);
   446  
   447  i = gcd(pll->pll_op_clk_freq_hz, pll->ext_clk_freq_hz);
   448  mul = div_u64(pll->pll_op_clk_freq_hz, i);
   449  div = pll->ext_clk_freq_hz / i;
   450  dev_dbg(dev, "mul %u / div %u\n", mul, div);
   451  
   452  min_pre_pll_clk_div =
   453  

Re: [RFC PATCH v2 1/3] dt-bindings: usb: mtk-xhci: add compatible for mt8195

2021-02-06 Thread Chunfeng Yun
On Wed, 2021-02-03 at 11:31 +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 03, 2021 at 06:26:40PM +0800, Chunfeng Yun wrote:
> > There are 4 USB controllers on MT8195, the controllers (IP1~IP3,
> > exclude IP0) have a wrong default SOF/ITP interval which is
> > calculated from the frame counter clock 24Mhz by default, but
> > in fact, the frame counter clock is 48Mhz, so we should set
> > the accurate interval according to 48Mhz. Here add a new compatible
> > for MT8195, it's also supported in driver. But the first controller
> > (IP0) has no such issue, we prefer to use generic compatible,
> > e.g. mt8192's compatible.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> > v2: no changes
> 
> Note, I do not apply patches with "RFC" as obviously you do not think
> they are worthy of being applied.  I don't see what you are asking to be
> done with this set of patches, please explain?
The DTS patch [2/3] in the series will cause merge conflict, due to the
dependent patches are not upstreamed.

Another problem is that I wander to know whether the compatible usage as
following is allowed:

arch/arm64/boot/dts/mediatek/mt8195.dtsi

   usb@1120 {  // ip0
compatible = "mediatek,mt8192-xhci",  // here use mt8192's
compatible, avoid changing SOF/ITP interval for ip0, because it's
default value is ok."mediatek,mt8192-xhci" is not supported in driver,
so finally will use generic copatible "mediatek,mtk-xhci".

 "mediatek,mtk-xhci";

};

   usb@1129 {  // ip1
compatible = "mediatek,mt8195-xhci",  // here use mt8195's
compatible, used to change SOF/ITP interval, due the the wrong default
value.
 "mediatek,mtk-xhci";
   };

   usb@112a {  // ip2
compatible = "mediatek,mt8195-xhci",  // same as ip1
 "mediatek,mtk-xhci";
};

Thank you

> 
> thanks,
> 
> greg k-h



Re: [RFC PATCH 01/11] iommu/arm-smmu-v3: Add feature detection for HTTU

2021-02-06 Thread Keqian Zhu
Hi Robin,

On 2021/2/6 0:11, Robin Murphy wrote:
> On 2021-02-05 11:48, Robin Murphy wrote:
>> On 2021-02-05 09:13, Keqian Zhu wrote:
>>> Hi Robin and Jean,
>>>
>>> On 2021/2/5 3:50, Robin Murphy wrote:
 On 2021-01-28 15:17, Keqian Zhu wrote:
> From: jiangkunkun 
>
> The SMMU which supports HTTU (Hardware Translation Table Update) can
> update the access flag and the dirty state of TTD by hardware. It is
> essential to track dirty pages of DMA.
>
> This adds feature detection, none functional change.
>
> Co-developed-by: Keqian Zhu 
> Signed-off-by: Kunkun Jiang 
> ---
>drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16 
>drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  8 
>include/linux/io-pgtable.h  |  1 +
>3 files changed, 25 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 8ca7415d785d..0f0fe71cc10d 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -1987,6 +1987,7 @@ static int arm_smmu_domain_finalise(struct 
> iommu_domain *domain,
>.pgsize_bitmap= smmu->pgsize_bitmap,
>.ias= ias,
>.oas= oas,
> +.httu_hd= smmu->features & ARM_SMMU_FEAT_HTTU_HD,
>.coherent_walk= smmu->features & ARM_SMMU_FEAT_COHERENCY,
>.tlb= _smmu_flush_ops,
>.iommu_dev= smmu->dev,
> @@ -3224,6 +3225,21 @@ static int arm_smmu_device_hw_probe(struct 
> arm_smmu_device *smmu)
>if (reg & IDR0_HYP)
>smmu->features |= ARM_SMMU_FEAT_HYP;
>+switch (FIELD_GET(IDR0_HTTU, reg)) {

 We need to accommodate the firmware override as well if we need this to be 
 meaningful. Jean-Philippe is already carrying a suitable patch in the SVA 
 stack[1].
>>> Robin, Thanks for pointing it out.
>>>
>>> Jean, I see that the IORT HTTU flag overrides the hardware register info 
>>> unconditionally. I have some concern about it:
>>>
>>> If the override flag has HTTU but hardware doesn't support it, then driver 
>>> will use this feature but receive access fault or permission fault from 
>>> SMMU unexpectedly.
>>> 1) If IOPF is not supported, then kernel can not work normally.
>>> 2) If IOPF is supported, kernel will perform useless actions, such as HTTU 
>>> based dma dirty tracking (this series).
>>
>> Yes, if the IORT describes the SMMU incorrectly, things will not work well. 
>> Just like if it describes the wrong base address or the wrong interrupt 
>> numbers, things will also not work well. The point is that incorrect 
>> firmware can be updated in the field fairly easily; incorrect hardware can 
>> not.
>>
>> Say the SMMU designer hard-codes the ID register field to 0x2 because the 
>> SMMU itself is capable of HTTU, and they assume it's always going to be 
>> wired up coherently, but then a customer integrates it to a non-coherent 
>> interconnect. Firmware needs to override that value to prevent an OS 
>> thinking that the claimed HTTU capability is ever going to work.
>>
>> Or say the SMMU *is* integrated correctly, but due to an erratum discovered 
>> later in the interconnect or SMMU itself, it turns out DBM doesn't always 
>> work reliably, but AF is still OK. Firmware needs to downgrade the indicated 
>> level of support from that which was intended to that which works reliably.
>>
>> Or say someone forgets to set an integration tieoff so their SMMU reports 
>> 0x0 even though it and the interconnect *can* happily support HTTU. In that 
>> case, firmware may want to upgrade the value to *allow* an OS to use HTTU 
>> despite the ID register being wrong.
>>
>>> As the IORT spec doesn't give an explicit explanation for HTTU override, 
>>> can we comprehend it as a mask for HTTU related hardware register?
>>> So the logic becomes: smmu->feature = HTTU override & IDR0_HTTU;
>>
>> No, it literally states that the OS must use the value of the firmware field 
>> *instead* of the value from the hardware field.
> 
> Oops, apologies for an oversight there - I've been reviewing IORT spec 
> updates lately so naturally had the newest version open already. Turns out 
> these descriptions were only clarified in the most recent release, so if you 
> were looking at an older document they *were* horribly vague.
Yep, my local version is E which was released at July 2020. I download the 
version E.a just now, thanks. ;-)

Thanks,
Keqian


Re: [fuse-devel] [PATCH] fuse: avoid deadlock when write fuse inode

2021-02-06 Thread Huang Jianan

friendly ping ... 

On 2021/2/2 12:11, Huang Jianan via fuse-devel wrote:

Hi all,


This patch works well in our product, but I am not sure this is the 
correct


way to solve this problem. I think that the inode->i_count shouldn't be

zero after iput is executed in dentry_unlink_inode, then the inode won't

be writeback. But i haven't found where iget is missing.


Thanks,

Jianan

On 2021/2/2 12:08, Huang Jianan wrote:

We found the following deadlock situations in low memory scenarios:
Thread A Thread B
- __writeback_single_inode
  - fuse_write_inode
   - fuse_simple_request
    - __fuse_request_send
 - request_wait_answer
  - fuse_dev_splice_read
   - fuse_copy_fill
    - __alloc_pages_direct_reclaim
 - do_shrink_slab
  - super_cache_scan
   - shrink_dentry_list
    - dentry_unlink_inode
 - iput_final
  - inode_wait_for_writeback

The request and inode processed by Thread A and B are the same, which
causes a deadlock. To avoid this, we remove the __GFP_FS flag when
allocating memory in fuse_copy_fill, so there will be no memory
reclaimation in super_cache_scan.

Signed-off-by: Huang Jianan 
Signed-off-by: Guo Weichao 
---
  fs/fuse/dev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 588f8d1240aa..e580b9d04c25 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -721,7 +721,7 @@ static int fuse_copy_fill(struct fuse_copy_state 
*cs)

  if (cs->nr_segs >= cs->pipe->max_usage)
  return -EIO;
  -    page = alloc_page(GFP_HIGHUSER);
+    page = alloc_page(GFP_HIGHUSER & ~__GFP_FS);
  if (!page)
  return -ENOMEM;





Re: [PATCH 1/4] mm/highmem: Lift memcpy_[to|from]_page to core

2021-02-06 Thread Chaitanya Kulkarni
On 2/5/21 18:35, ira.we...@intel.com wrote:
> +static inline void memmove_page(struct page *dst_page, size_t dst_off,
> +struct page *src_page, size_t src_off,
> +size_t len)
> +{
> + char *dst = kmap_local_page(dst_page);
> + char *src = kmap_local_page(src_page);
> +
> + BUG_ON(dst_off + len > PAGE_SIZE || src_off + len > PAGE_SIZE);
> + memmove(dst + dst_off, src + src_off, len);
> + kunmap_local(src);
> + kunmap_local(dst);
> +}
> +
> +static inline void memcpy_from_page(char *to, struct page *page, size_t 
> offset, size_t len)
How about following ?
static inline void memcpy_from_page(char *to, struct page *page, size_t
offset,
size_t len)  
> +{
> + char *from = kmap_local_page(page);
> +
> + BUG_ON(offset + len > PAGE_SIZE);
> + memcpy(to, from + offset, len);
> + kunmap_local(from);
> +}
> +
> +static inline void memcpy_to_page(struct page *page, size_t offset, const 
> char *from, size_t len)
How about following ?
static inline void memcpy_to_page(struct page *page, size_t offset,
  const char *from, size_t len)
> +{
> + char *to = kmap_local_page(page);
> +
> + BUG_ON(offset + len > PAGE_SIZE);
> + memcpy(to + offset, from, len);
> + kunmap_local(to);
> +}
> +
> +static inline void memset_page(struct page *page, size_t offset, int val, 
> size_t len)
How about following ?
static inline void memset_page(struct page *page, size_t offset, int val,
   size_t len)  
> +{
> + char *addr = kmap_local_page(page);
> +
> + BUG_ON(offset + len > PAGE_SIZE);
> + memset(addr + offset, val, len);
> + kunmap_local(addr);
> +}
> +


Re: [PATCH v2 1/1] kernel/crash_core: Add crashkernel=auto for vmcore creation

2021-02-06 Thread Dave Young
Hi Saeed,
On 02/03/21 at 04:43pm, Saeed Mirzamohammadi wrote:
> This adds crashkernel=auto feature to configure reserved memory for
> vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
> different kernel distributions and different archs based on their
> needs.
> 
> Signed-off-by: Saeed Mirzamohammadi 
> Signed-off-by: John Donnelly 
> Tested-by: John Donnelly 
> ---
>  Documentation/admin-guide/kdump/kdump.rst |  5 +
>  arch/Kconfig  | 24 +++
>  kernel/crash_core.c   |  7 +++
>  3 files changed, 36 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kdump/kdump.rst 
> b/Documentation/admin-guide/kdump/kdump.rst
> index 75a9dd98e76e..f95a2af64f59 100644
> --- a/Documentation/admin-guide/kdump/kdump.rst
> +++ b/Documentation/admin-guide/kdump/kdump.rst
> @@ -285,7 +285,12 @@ This would mean:
>  2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
>  3) if the RAM size is larger than 2G, then reserve 128M
>  
> +Or you can use crashkernel=auto if you have enough memory. The threshold
> +is 1G on x86_64 and arm64. If your system memory is less than the threshold,
> +crashkernel=auto will not reserve memory. The size changes according to
> +the system memory size like below:
>  
> +x86_64/arm64: 1G-64G:128M,64G-1T:256M,1T-:512M

This part should be updated since you do not make the default value arch
dependent.

The format of the auto str is documented well in kernel-parameters.txt
below part:
crashkernel=range1:size1[,range2:size2,...][@offset]

The crashkernel=auto should be also documented in kernel-parameters.txt
and do not need to explain the threshold etc again, just refer to the
"crashkernel=range1:size1[,range2:size2,...][@offset]" format would be
fine.

>  
>  Boot into System Kernel
>  ===
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 56b6ccc0e32d..a772eb397d73 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -14,6 +14,30 @@ menu "General architecture-dependent options"
>  config CRASH_CORE
>   bool
>  
> +if CRASH_CORE
> +
> +config CRASH_AUTO_STR
> + string "Memory reserved for crash kernel"
> + depends on CRASH_CORE
> + default "1G-64G:128M,64G-1T:256M,1T-:512M"
> + help
> +   This configures the reserved memory dependent
> +   on the value of System RAM. The syntax is:
> +   crashkernel=:[,:,...][@offset]
> +   range=start-[end]
> +
> +   For example:
> +   crashkernel=512M-2G:64M,2G-:128M
> +
> +   This would mean:
> +
> +   1) if the RAM is smaller than 512M, then don't reserve anything
> +  (this is the "rescue" case)
> +   2) if the RAM size is between 512M and 2G (exclusive), then 
> reserve 64M
> +   3) if the RAM size is larger than 2G, then reserve 128M
> +
> +endif # CRASH_CORE
> +
>  config KEXEC_CORE
>   select CRASH_CORE
>   bool
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 106e4500fd53..ab0a2b4b1ffa 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -250,6 +251,12 @@ static int __init __parse_crashkernel(char *cmdline,
>   if (suffix)
>   return parse_crashkernel_suffix(ck_cmdline, crash_size,
>   suffix);
> +#ifdef CONFIG_CRASH_AUTO_STR
> + if (strncmp(ck_cmdline, "auto", 4) == 0) {
> + ck_cmdline = CONFIG_CRASH_AUTO_STR;
> + pr_info("Using crashkernel=auto, the size chosen is a best 
> effort estimation.\n");
> + }
> +#endif
>   /*
>* if the commandline contains a ':', then that's the extended
>* syntax -- if not, it must be the classic syntax
> -- 
> 2.27.0
> 

Thanks
Dave



Re: [PATCH] iommu/mediatek: Fix error code in probe()

2021-02-06 Thread Yong Wu
On Fri, 2021-02-05 at 15:46 +0300, Dan Carpenter wrote:
> This error path is supposed to return -EINVAL.  It used to return
> directly but we added some clean up and accidentally removed the
> error code.  Also I fixed a typo in the error message.
> 
> Fixes: c0b57581b73b ("iommu/mediatek: Add power-domain operation")
> Signed-off-by: Dan Carpenter 

Reviewed-by: Yong Wu 

> ---
>  drivers/iommu/mtk_iommu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 0ad14a7604b1..5f78ac0dc30e 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -886,7 +886,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>   link = device_link_add(data->smicomm_dev, dev,
>   DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
>   if (!link) {
> - dev_err(dev, "Unable link %s.\n", dev_name(data->smicomm_dev));
> + dev_err(dev, "Unable to link %s.\n", 
> dev_name(data->smicomm_dev));
> + ret = -EINVAL;
>   goto out_runtime_disable;
>   }
>  



Re: [RFC PATCH 01/11] iommu/arm-smmu-v3: Add feature detection for HTTU

2021-02-06 Thread Keqian Zhu
Hi Jean,

On 2021/2/5 17:51, Jean-Philippe Brucker wrote:
> Hi Keqian,
> 
> On Fri, Feb 05, 2021 at 05:13:50PM +0800, Keqian Zhu wrote:
>>> We need to accommodate the firmware override as well if we need this to be 
>>> meaningful. Jean-Philippe is already carrying a suitable patch in the SVA 
>>> stack[1].
>> Robin, Thanks for pointing it out.
>>
>> Jean, I see that the IORT HTTU flag overrides the hardware register info 
>> unconditionally. I have some concern about it:
>>
>> If the override flag has HTTU but hardware doesn't support it, then driver 
>> will use this feature but receive access fault or permission fault from SMMU 
>> unexpectedly.
>> 1) If IOPF is not supported, then kernel can not work normally.
>> 2) If IOPF is supported, kernel will perform useless actions, such as HTTU 
>> based dma dirty tracking (this series).
>>
>> As the IORT spec doesn't give an explicit explanation for HTTU override, can 
>> we comprehend it as a mask for HTTU related hardware register?
> 
> To me "Overrides the value of SMMU_IDR0.HTTU" is clear enough: disregard
> the value of SMMU_IDR0.HTTU and use the one specified by IORT instead. And
> that's both ways, since there is no validity mask for the IORT value: if
> there is an IORT table, always ignore SMMU_IDR0.HTTU.
> 
> That's how the SMMU driver implements the COHACC bit, which has the same
> wording in IORT. So I think we should implement HTTU the same way.
OK, and Robin said that the latest IORT spec literally states it.

> 
> One complication is that there is no equivalent override for device tree.
> I think it can be added later if necessary, because unlike IORT it can be
> tri state (property not present, overriden positive, overridden negative).
Yeah, that would be more flexible. ;-)

> 
> Thanks,
> Jean
> 
> .
> 
Thanks,
Keqian


Re: [PATCH 04/24] perf daemon: Add server socket support

2021-02-06 Thread Namhyung Kim
On Sun, Feb 7, 2021 at 4:04 AM Jiri Olsa  wrote:
>
> On Fri, Feb 05, 2021 at 08:30:10PM +0900, Namhyung Kim wrote:
> > On Sun, Jan 31, 2021 at 8:49 AM Jiri Olsa  wrote:
> > >
> > > Add support to create server socket that listens for client
> > > commands and process them.
> > >
> > > This patch adds only the core support, all commands using
> > > this functionality are coming in following patches.
> > >
> > > Signed-off-by: Jiri Olsa 
> > > ---
> > >  tools/perf/builtin-daemon.c | 101 +++-
> > >  1 file changed, 100 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c
> > > index 8d0ac44ec808..756d60616d7d 100644
> > > --- a/tools/perf/builtin-daemon.c
> > > +++ b/tools/perf/builtin-daemon.c
> > > @@ -1,5 +1,6 @@
> > >  // SPDX-License-Identifier: GPL-2.0
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -7,6 +8,10 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > >  #include "builtin.h"
> > >  #include "perf.h"
> > >  #include "debug.h"
> > > @@ -37,6 +42,78 @@ static void sig_handler(int sig __maybe_unused)
> > > done = true;
> > >  }
> > >
> > > +static int setup_server_socket(struct daemon *daemon)
> > > +{
> > > +   struct sockaddr_un addr;
> > > +   char path[100];
> > > +   int fd;
> > > +
> > > +   fd = socket(AF_UNIX, SOCK_STREAM, 0);
> > > +   if (fd < 0) {
> > > +   fprintf(stderr, "socket: %s\n", strerror(errno));
> > > +   return -1;
> > > +   }
> > > +
> > > +   fcntl(fd, F_SETFD, FD_CLOEXEC);
> > > +
> > > +   scnprintf(path, PATH_MAX, "%s/control", daemon->base);
> >
> > I couldn't find where the default value of daemon->base is set.
> > Also 100 bytes seem not enough for the path name.
>
> 108 bytes is the limit of the unix socket path,
> I'm adding more checks on the provided base,
> so we display some reasonable error

Sgtm.

Thanks,
Namhyung


Re: [PATCH 06/24] perf daemon: Add config file support

2021-02-06 Thread Namhyung Kim
On Sun, Feb 7, 2021 at 7:35 AM Jiri Olsa  wrote:
>
> On Sat, Feb 06, 2021 at 05:05:04PM +0900, Namhyung Kim wrote:
> > On Fri, Feb 5, 2021 at 9:56 PM Jiri Olsa  wrote:
> > >
> > > On Fri, Feb 05, 2021 at 09:14:54PM +0900, Namhyung Kim wrote:
> > > > On Sun, Jan 31, 2021 at 8:49 AM Jiri Olsa  wrote:
> > > > [SNIP]
> > > > > @@ -263,9 +605,16 @@ static int __cmd_start(struct daemon *daemon, 
> > > > > struct option parent_options[],
> > > > > signal(SIGTERM, sig_handler);
> > > > >
> > > > > while (!done && !err) {
> > > > > -   if (fdarray__poll(, -1)) {
> > > > > +   err = daemon__reconfig(daemon);
> > > >
> > > > I think it's confusing since you put the reconfig function here.
> > > > What not split normal and reconfig passes?
> > >
> > > hum, not sure what's confusing in here? I've been known to
> > > produce confusing code, but this one seems clear to me
> >
> > Maybe it's because of the name.  I thought reconfig is a
> > special case when it detects some change.  But you call
> > it in the loop unconditionally.
> >
> > >
> > > >
> > > > I mean something like below
> > > >
> > > >  __cmd_start()
> > > > {
> > > > setup_server_config();
> > > > daemon__run();
> > >
> > > what's daemon__run? the daemon operates in the while loop below
> >
> > I thought about starting the sessions in the config.
> >
> > >
> > > >
> > > > while (!done && !err) {
> > > > ...
> > > > if (reconfig) {
> > > > daemon__kill();
> > >
> > > you don't kill daemon for each reconfig change,
> > > we detect changed sessions and kill/restart only them
> >
> > Yep, we can make it that way.
> >
> > >
> > > > setup_server_config();
> > > > daemon__reconfig();
> > > > }
> > > > }
> > >
> > >
> > > so basically the current workflow is:
> > >
> > > setup_server_config <--- 
> > > reads config file, prepares session objects
> > >
> > > while (!done) {
> > > daemon__reconfig<--- 
> > > check session objects states and run/stop them
> >
> > Hmm.. then how about rename it to daemon__handle_state()
> > or daemon__do_loop() or something?
>
> well it handles reconfig, so I don't think that there's
> better name than daemon__reconfig ;-)
>
> apart from handle_server_socket, all the other functions
> we call after poll can change session state, so we need
> to 'reconfig' sessions each time we do a loop

OK then.  Thanks for the explanation!

Thanks,
Namhyung


Re: [RESEND v4 1/6] misc: Add Synopsys DesignWare xData IP driver

2021-02-06 Thread Krzysztof Wilczyński
Hi Gustavo,

Thank you for all the work here!

A few suggestions.

[...]
> +static void dw_xdata_stop(struct dw_xdata *dw)
> +{
> + u32 burst = readl(&(__dw_xdara_regs(dw)->burst_cnt));
> +
> + if (burst & BIT(31)) {
> + burst &= ~(u32)BIT(31);
> + writel(burst, &(__dw_regs(dw)->burst_cnt));
> + }
> +}

Would it be possible to add a define for this "BIT(31)", similarly to
the "XPERF_CONTROL_ENABLE", for example:

  #define XPERF_CONTROL_ENABLE  BIT(5)
  #define XPERF_CONTROL_DISABLE BIT(31)

What do you think?

> +static void dw_xdata_start(struct dw_xdata *dw, bool write)
> +{
> + u32 control, status;
> +
> + /* Stop first if xfer in progress */
> + dw_xdata_stop(dw);
> +
> + /* Clear status register */
> + writel(0x0, &(__dw_regs(dw)->status));
> +
> + /* Burst count register set for continuous until stopped */
> + writel(0x80001001, &(__dw_regs(dw)->burst_cnt));

Would you mind adding a define (possibly with a comment, if it makes
sense, of course) rather than open coding it here.

> + /* Pattern register */
> + writel(0x0, &(__dw_regs(dw)->pattern));
> +
> + /* Control register */
> + control = CONTROL_DOORBELL | CONTROL_PATTERN_INC | CONTROL_NO_ADDR_INC;
> + if (write) {
> + control |= CONTROL_IS_WRITE;
> + control |= CONTROL_LENGTH(dw->max_wr_len);
> + } else {
> + control |= CONTROL_LENGTH(dw->max_rd_len);
> + }
> + writel(control, &(__dw_regs(dw)->control));
> +
> + usleep_range(100, 150);
[...]

Why sleep here?

Do you just add some delay that changes were reflected, or is it
a requirement of sorts?  What do you think about documenting why the
sleep where? Would it make sense?

[...]
> +static void dw_xdata_perf(struct dw_xdata *dw, u64 *rate, bool write)
> +{
> + u64 data[2], time[2], diff;
> +
> + /* First measurement */
> + writel(0x0, &(__dw_regs(dw)->perf_control));
> + dw_xdata_perf_meas(dw, [0], write);
> + time[0] = jiffies;
> + writel((u32)XPERF_CONTROL_ENABLE, &(__dw_regs(dw)->perf_control));
> +
> + /* Delay 100ms */
> + mdelay(100);
[...]

The mdelay() is self-explanatory, so a comment that explains why to take
two measurements that are 100 ms apart and how rate is calculated might
be more useful (unless it would be an overkill here).

If this is an arbitrary delay without any special meaning, then probably
no comment is needed here.

What do you think?

[...]
> + /* Calculations */

What sort of calculations precisely? :)

[...]
> +static int dw_xdata_pcie_probe(struct pci_dev *pdev,
> +const struct pci_device_id *pid)
> +{
> + const struct dw_xdata_pcie_data *pdata = (void *)pid->driver_data;
> + struct dw_xdata *dw;
> + u64 addr;
> + int err;
> +
> + /* Enable PCI device */
> + err = pcim_enable_device(pdev);

This comment might not be needed.

[...]
> + /* Mapping PCI BAR regions */
> + err = pcim_iomap_regions(pdev, BIT(pdata->rg_bar), pci_name(pdev));

This comment might also not be needed.

[...]
> + /* Allocate memory */

And so this comment.

[...]
> + /* Data structure initialization */
[...]
> + /* Saving data structure reference */
[...]
> + /* Sysfs */
[...]

And possibly few of these are also not needed.

Krzysztof


Re: [PATCH v2 4/4] KVM: x86: Expose Architectural LBR CPUID and its XSAVES bit

2021-02-06 Thread Xu, Like

On 2021/2/5 19:00, Paolo Bonzini wrote:

On 05/02/21 09:16, Xu, Like wrote:

Hi Paolo,

I am wondering if it is acceptable for you to
review the minor Architecture LBR patch set without XSAVES for v5.12 ?

As far as I know, the guest Arch LBR  can still work without XSAVES 
support.


I dopn't think it can work.  You could have two guests on the same 
physical CPU and the MSRs would be corrupted if the guests write to the 
MSR but they do not enable the LBRs.


Paolo


Neither Arch LBR nor the old version of LBR have this corruption issue,
and we will not use XSAVES for at least LBR MSRs in the VMX transaction.

This is because we have reused the LBR save/restore swicth support from the
host perf mechanism in the legacy LBR support, which will save/restore the LBR
MSRs of the vcpu (thread) when the vcpu is sched in/out.

Therefore, if we have two guests on the same physical CPU, the usage of LBR 
MSRs
is isolated, and it's also true when we use LBR to trace the hypervisor on 
the host.

The same thing happens on the platforms which supports Arch LBR.

I propose that we don't support using XSAVES to save/restore Arch LRB *in 
the guest*
(just like the guest Intel PT), but use the traditional RD/WRMSR, which 
still works

like the legacy LBR.

Since we already have legacy LBR support, we can add a small amount of 
effort (just
two more MSRs emulation and related CPUID exposure) to support Arch LBR w/o 
XSAVES.


I estimate that there are many issues we need to address when we supporting 
guests
to use xsaves instructions. As a rational choice, we could enable the basic 
Arch LBR.


Paolo and Sean, what do you think ?

---
thx, likexu


Re: [PATCH net-next] net/packet: Improve the comment about LL header visibility criteria

2021-02-06 Thread Jakub Kicinski
On Fri, 5 Feb 2021 21:51:36 -0500 Willem de Bruijn wrote:
> On Fri, Feb 5, 2021 at 5:42 PM Xie He  wrote:
> >
> > The "dev_has_header" function, recently added in
> > commit d549699048b4 ("net/packet: fix packet receive on L3 devices
> > without visible hard header"),
> > is more accurate as criteria for determining whether a device exposes
> > the LL header to upper layers, because in addition to dev->header_ops,
> > it also checks for dev->header_ops->create.
> >
> > When transmitting an skb on a device, dev_hard_header can be called to
> > generate an LL header. dev_hard_header will only generate a header if
> > dev->header_ops->create is present.
> >
> > Signed-off-by: Xie He   
> 
> Acked-by: Willem de Bruijn 
> 
> Indeed, existence of dev->header_ops->create is the deciding factor. Thanks 
> Xie.

Applied, thanks!


Re: [PATCH] perf record: Fix continue profiling after draining the buffer

2021-02-06 Thread Yang Jihong

Hello,

On 2021/2/5 18:46, Jiri Olsa wrote:

On Fri, Feb 05, 2021 at 07:35:22PM +0900, Namhyung Kim wrote:

Hello,

On Fri, Feb 5, 2021 at 3:50 PM Yang Jihong  wrote:


commit da231338ec9c098707c8a1e4d8a50e2400e2fe17 uses eventfd to solve rare race
where the setting and checking of 'done' which add done_fd to pollfd.
When draining buffer, revents of done_fd is 0 and evlist__filter_pollfd
function returns a non-zero value.
As a result, perf record does not stop profiling.

The following simple scenarios can trigger this condition:

sleep 10 &
perf record -p $!

After the sleep process exits, perf record should stop profiling and exit.
However, perf record keeps running.

If pollfd revents contains only POLLERR or POLLHUP,
perf record indicates that buffer is draining and need to stop profiling.
Use fdarray_flag__nonfilterable to set done eventfd to nonfilterable objects,
so that evlist__filter_pollfd does not filter and check done eventfd.

Fixes: da231338ec9c (perf record: Use an eventfd to wakeup when done)
Signed-off-by: Yang Jihong 
---
  tools/perf/builtin-record.c | 2 +-
  tools/perf/util/evlist.c| 8 
  tools/perf/util/evlist.h| 4 
  3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index fd3911650612..51e593e896ea 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1663,7 +1663,7 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
 status = -1;
 goto out_delete_session;
 }
-   err = evlist__add_pollfd(rec->evlist, done_fd);
+   err = evlist__add_wakeup_eventfd(rec->evlist, done_fd);
 if (err < 0) {
 pr_err("Failed to add wakeup eventfd to poll list\n");
 status = err;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 05363a7247c4..fea4c1e8010d 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -572,6 +572,14 @@ int evlist__filter_pollfd(struct evlist *evlist, short 
revents_and_mask)
 return perf_evlist__filter_pollfd(>core, revents_and_mask);
  }

+#ifdef HAVE_EVENTFD_SUPPORT
+int evlist__add_wakeup_eventfd(struct evlist *evlist, int fd)
+{
+   return perf_evlist__add_pollfd(>core, fd, NULL, POLLIN,
+  fdarray_flag__nonfilterable);
+}
+#endif


Does it build when HAVE_EVENTFD_SUPPORT is not defined?


yea, I was wondering the same.. but it's called only from
code within HAVE_EVENTFD_SUPPORT ifdef

jirka



Thanks,
Namhyung


I have tested that if "eventfd" feature is removed from the 
FEATURE_TESTS_BASIC list in Makefile.feature,

evlist__add_wakeup_eventfd will not be build.

Modify as follows:

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 97cbfb31b762..d1603050764a 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -32,7 +32,6 @@ FEATURE_TESTS_BASIC :=  \
 backtrace   \
 dwarf   \
 dwarf_getlocations  \
-eventfd \
 fortify-source  \
 sync-compare-and-swap   \
 get_current_dir_name\

Thanks,
Yang


+
  int evlist__poll(struct evlist *evlist, int timeout)
  {
 return perf_evlist__poll(>core, timeout);
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 1aae75895dea..6d4d62151bc8 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -142,6 +142,10 @@ struct evsel *evlist__find_tracepoint_by_name(struct 
evlist *evlist, const char
  int evlist__add_pollfd(struct evlist *evlist, int fd);
  int evlist__filter_pollfd(struct evlist *evlist, short revents_and_mask);

+#ifdef HAVE_EVENTFD_SUPPORT
+int evlist__add_wakeup_eventfd(struct evlist *evlist, int fd);
+#endif
+
  int evlist__poll(struct evlist *evlist, int timeout);

  struct evsel *evlist__id2evsel(struct evlist *evlist, u64 id);
--
2.17.1





.



net/xfrm/xfrm_output.c:506:5: warning: stack frame size of 2128 bytes in function 'xfrm_output_resume'

2021-02-06 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   61556703b610a104de324e4f061dc6cf7b218b46
commit: 010b430d5df556d5d232e3751ac691ba9e88c041 mptcp: MPTCP_IPV6 should 
depend on IPV6 instead of selecting it
date:   4 months ago
config: powerpc64-randconfig-r025-20210205 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
c9439ca36342fb6013187d0a69aef92736951476)
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
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=010b430d5df556d5d232e3751ac691ba9e88c041
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 010b430d5df556d5d232e3751ac691ba9e88c041
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
ARCH=powerpc64 

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

All warnings (new ones prefixed by >>):

>> net/xfrm/xfrm_output.c:506:5: warning: stack frame size of 2128 bytes in 
>> function 'xfrm_output_resume' [-Wframe-larger-than=]
   int xfrm_output_resume(struct sk_buff *skb, int err)
   ^
   1 warning generated.


vim +/xfrm_output_resume +506 net/xfrm/xfrm_output.c

862b82c6f960cc Herbert Xu2007-11-13  505  
c6581a457e661b Herbert Xu2007-11-13 @506  int xfrm_output_resume(struct 
sk_buff *skb, int err)
862b82c6f960cc Herbert Xu2007-11-13  507  {
29a26a56803855 Eric W. Biederman 2015-09-15  508struct net *net = 
xs_net(skb_dst(skb)->xfrm);
be10de0a322ded Eric W. Biederman 2015-09-17  509  
c6581a457e661b Herbert Xu2007-11-13  510while (likely((err = 
xfrm_output_one(skb, err)) == 0)) {
895b5c9f206eb7 Florian Westphal  2019-09-29  511
nf_reset_ct(skb);
862b82c6f960cc Herbert Xu2007-11-13  512  
cf91a99daa4651 Eric W. Biederman 2015-10-07  513err = 
skb_dst(skb)->ops->local_out(net, skb->sk, skb);
862b82c6f960cc Herbert Xu2007-11-13  514if 
(unlikely(err != 1))
c6581a457e661b Herbert Xu2007-11-13  515goto 
out;
862b82c6f960cc Herbert Xu2007-11-13  516  
adf30907d63893 Eric Dumazet  2009-06-02  517if 
(!skb_dst(skb)->xfrm)
13206b6bff3b15 Eric W. Biederman 2015-10-07  518return 
dst_output(net, skb->sk, skb);
862b82c6f960cc Herbert Xu2007-11-13  519  
adf30907d63893 Eric Dumazet  2009-06-02  520err = 
nf_hook(skb_dst(skb)->ops->family,
29a26a56803855 Eric W. Biederman 2015-09-15  521  
NF_INET_POST_ROUTING, net, skb->sk, skb,
adf30907d63893 Eric Dumazet  2009-06-02  522  
NULL, skb_dst(skb)->dev, xfrm_output2);
862b82c6f960cc Herbert Xu2007-11-13  523if 
(unlikely(err != 1))
c6581a457e661b Herbert Xu2007-11-13  524goto 
out;
862b82c6f960cc Herbert Xu2007-11-13  525}
862b82c6f960cc Herbert Xu2007-11-13  526  
c6581a457e661b Herbert Xu2007-11-13  527if (err == -EINPROGRESS)
c6581a457e661b Herbert Xu2007-11-13  528err = 0;
c6581a457e661b Herbert Xu2007-11-13  529  
c6581a457e661b Herbert Xu2007-11-13  530  out:
862b82c6f960cc Herbert Xu2007-11-13  531return err;
862b82c6f960cc Herbert Xu2007-11-13  532  }
c6581a457e661b Herbert Xu2007-11-13  533  
EXPORT_SYMBOL_GPL(xfrm_output_resume);
862b82c6f960cc Herbert Xu2007-11-13  534  

:: The code at line 506 was first introduced by commit
:: c6581a457e661b7070e484ad723bbf555b17aca2 [IPSEC]: Add async resume 
support on output

:: TO: Herbert Xu 
:: CC: David S. Miller 

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


.config.gz
Description: application/gzip


  1   2   3   4   >