Re: [PATCH v2 24/24] scsi: aic7xxx: aic79xx_osm: Remove set but unused variabes 'saved_scsiid' and 'saved_modes'

2020-07-14 Thread Hannes Reinecke

On 7/14/20 11:39 PM, Lee Jones wrote:

On Tue, 14 Jul 2020, James Bottomley wrote:


On Tue, 2020-07-14 at 09:46 +0200, Hannes Reinecke wrote:

On 7/13/20 10:00 AM, Lee Jones wrote:

Haven't been used since 2006.

Fixes the following W=1 kernel build warning(s):

  drivers/scsi/aic7xxx/aic79xx_osm.c: In function
‘ahd_linux_queue_abort_cmd’:
  drivers/scsi/aic7xxx/aic79xx_osm.c:2155:17: warning: variable
‘saved_modes’ set but not used [-Wunused-but-set-variable]
  drivers/scsi/aic7xxx/aic79xx_osm.c:2148:9: warning: variable
‘saved_scsiid’ set but not used [-Wunused-but-set-variable]

Cc: Hannes Reinecke 
Signed-off-by: Lee Jones 
---
  drivers/scsi/aic7xxx/aic79xx_osm.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c
b/drivers/scsi/aic7xxx/aic79xx_osm.c
index 3782a20d58885..140c4e74ddd7e 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
@@ -2141,14 +2141,12 @@ ahd_linux_queue_abort_cmd(struct scsi_cmnd
*cmd)
u_int  saved_scbptr;
u_int  active_scbptr;
u_int  last_phase;
-   u_int  saved_scsiid;
u_int  cdb_byte;
intretval;
intwas_paused;
intpaused;
intwait;
intdisconnected;
-   ahd_mode_state saved_modes;
unsigned long flags;
  
  	pending_scb = NULL;

@@ -2239,7 +2237,6 @@ ahd_linux_queue_abort_cmd(struct scsi_cmnd
*cmd)
goto done;
}
  
-	saved_modes = ahd_save_modes(ahd);

ahd_set_modes(ahd, AHD_MODE_SCSI, AHD_MODE_SCSI);
last_phase = ahd_inb(ahd, LASTPHASE);
saved_scbptr = ahd_get_scbptr(ahd);
@@ -2257,7 +2254,6 @@ ahd_linux_queue_abort_cmd(struct scsi_cmnd
*cmd)
 * passed in command.  That command is currently active on
the
 * bus or is in the disconnected state.
 */
-   saved_scsiid = ahd_inb(ahd, SAVED_SCSIID);
if (last_phase != P_BUSFREE
&& SCB_GET_TAG(pending_scb) == active_scbptr) {
  



Reviewed-by: Hannes Reinecke 


Hey, you don't get to do that ... I asked you to figure out why we're
missing an ahd_restore_modes().  Removing the ahd_save_modes() is
cosmetic: it gets rid of a warning but doesn't fix the problem.  I'd
rather keep the warning until the problem is fixed and the problem is
we need a mode save/restore around the ahd_set_modes() which is only
partially implemented in this function.


I had a look.  Traced it back to the dawn of time (time == Git), then
delved even further back by downloading and trawling through ~10-15
tarballs.  It looks as though drivers/scsi/aic7xxx/aic79xx_osm.c was
upstreamed in v2.5.60, nearly 20 years ago.  'saved_modes' has been
unused since at least then.  If no one has complained in 2 decades,
I'd say it probably isn't an issue worth perusing.

That's not really the point; this function is the first stage of error 
recovery. And the only real way of exercising this is to inject a 
command timeout, which is nearly impossible without dedicated hardware.
So this function will have a very limited exposure, but nevertheless a 
quite crucial function.
Hence I'm not quite agree with your reasoning, and rather would have it 
fixed.
But as we're having an alternative fix now, it might be best if you 
could drop it from your patchset and we'll fix it separately.


Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer


Re: [PATCH v10 05/12] dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script

2020-07-14 Thread Vinod Koul
On 30-06-20, 21:31, Robin Gong wrote:
> Add 'fw_loaded' and 'is_ram_script' to check if the script used by channel
> is ram script and it's loaded or not, so that could prevent meaningless
> following malloc dma descriptor and bd allocate in sdma_transfer_init(),
> otherwise memory may be consumed out potentially without free in case
> that spi fallback into pio while dma transfer failed by sdma firmware not
> ready(next ERR009165 patch depends on sdma RAM scripts/firmware).

Acked-By: Vinod Koul 

-- 
~Vinod


Re: [PATCH v2 1/6] sched_clock: Expose struct clock_read_data

2020-07-14 Thread Ahmed S. Darwish
On Wed, Jul 15, 2020 at 10:05:07AM +0800, Leo Yan wrote:
> From: Peter Zijlstra 
>
...
>
> Provide struct clock_read_data and two (seqcount) helpers so that
> architectures (arm64 in specific) can expose the numbers to userspace.
>
...
>
> +struct clock_read_data *sched_clock_read_begin(unsigned int *seq)
> +{
> + *seq = raw_read_seqcount();
> + return cd.read_data + (*seq & 1);
> +}
> +
...

Hmm, this seqcount_t is actually a latch seqcount. I know the original
code also used raw_read_seqcount(), but while at it, let's use the
proper read API for seqcount_t latchers: raw_read_seqcount_latch().

raw_read_seqcount_latch() has no read memory barrier though, and a
suspicious claim that READ_ONCE() pairs with an smp_wmb() (??). But if
its implementation is wrong, let's fix it there instead.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH


Re: [PATCH v3 04/14] dmaengine: pl330: Add quirk 'arm,pl330-periph-burst'

2020-07-14 Thread Vinod Koul
On 29-06-20, 22:05, Sugar Zhang wrote:
> This patch adds the qurik to use burst transfers only
> for pl330 controller, even for request with a length of 1.
> 
> Although, the correct way should be: if the peripheral request
> length is 1, the peripheral should use SINGLE request, and then
> notify the dmac using SINGLE mode by src/dst_maxburst with 1.
> 
> For example, on the Rockchip SoCs, all the peripherals can use
> SINGLE or BURST request by setting GRF registers. it is possible
> that if these peripheral drivers are used only for Rockchip SoCs.
> Unfortunately, it's not, such as dw uart, which is used so widely,
> and we can't set src/dst_maxburst according to the SoCs' specific
> to compatible with all the other SoCs.
> 
> So, for convenience, all the peripherals are set as BURST request
> by default on the Rockchip SoCs. even for request with a length of 1.
> the current pl330 driver will perform SINGLE transfer if the client's
> maxburst is 1, which still should be working according to chapter 2.6.6
> of datasheet which describe how DMAC performs SINGLE transfers for
> a BURST request. Unfortunately, it's broken on the Rockchip SoCs,
> which support only matching transfers, such as BURST transfer for
> BURST request, SINGLE transfer for SINGLE request.
> 
> Finally, we add the quirk to specify pl330 to use burst transfers only.

Applied, thanks

-- 
~Vinod


Re: [PATCH v3 03/14] dt-bindings: dma: pl330: Document the quirk 'arm,pl330-periph-burst'

2020-07-14 Thread Vinod Koul
On 29-06-20, 22:05, Sugar Zhang wrote:
> This patch Adds the quirk 'arm,pl330-periph-burst' for pl330.

Applied, thanks

-- 
~Vinod


Re: [PATCH v3 02/14] dmaengine: pl330: Improve transfer efficiency for the dregs

2020-07-14 Thread Vinod Koul
On 29-06-20, 22:05, Sugar Zhang wrote:
> Only the unaligned burst transfers have the dregs.
> so, still use BURST transfer with a reduced size
> for better performance.

Applied, thanks

-- 
~Vinod


Re: [PATCH v3 01/14] dmaengine: pl330: Remove the burst limit for quirk 'NO-FLUSHP'

2020-07-14 Thread Vinod Koul
On 29-06-20, 22:05, Sugar Zhang wrote:
> There is no reason to limit the performance on the 'NO-FLUSHP' SoCs,
> because 'FLUSHP' instruction is broken on these platforms, so remove
> the limit to improve the efficiency.

Applied, thanks

-- 
~Vinod


Re: kernel panic: System is deadlocked on memory

2020-07-14 Thread Yafang Shao
On Wed, Jul 15, 2020 at 12:49 PM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:d31958b3 Add linux-next specific files for 20200710
> git tree:   linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11a2fe1310
> kernel config:  https://syzkaller.appspot.com/x/.config?x=3fe4fccb94cbc1a6
> dashboard link: https://syzkaller.appspot.com/bug?extid=98be80110b9043885626
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=101ec96710
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14a7700090
>
> The issue was bisected to:
>
> commit e642d9be463d02c735cd99a9a904063324ee03d6
> Author: Yafang Shao 
> Date:   Fri Jul 10 04:58:08 2020 +
>
> mm, oom: make the calculation of oom badness more accurate
>
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1432bd7710
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1632bd7710
> console output: https://syzkaller.appspot.com/x/log.txt?x=1232bd7710
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+98be80110b9043885...@syzkaller.appspotmail.com
> Fixes: e642d9be463d ("mm, oom: make the calculation of oom badness more 
> accurate")
>
> Out of memory and no killable processes...
> Kernel panic - not syncing: System is deadlocked on memory
> CPU: 0 PID: 6810 Comm: syz-executor919 Not tainted 
> 5.8.0-rc4-next-20200710-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x18f/0x20d lib/dump_stack.c:118
>  panic+0x2e3/0x75c kernel/panic.c:231
>  out_of_memory mm/oom_kill.c:1106 [inline]
>  out_of_memory.cold+0xa6/0x182 mm/oom_kill.c:1041
>  pagefault_out_of_memory+0x109/0x11c mm/oom_kill.c:1135
>  mm_fault_error+0x123/0x380 arch/x86/mm/fault.c:930
>  do_user_addr_fault+0x5f8/0xbf0 arch/x86/mm/fault.c:1317
>  handle_page_fault arch/x86/mm/fault.c:1351 [inline]
>  exc_page_fault+0xab/0x170 arch/x86/mm/fault.c:1404
>  asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:544
> RIP: 0033:0x40154d
> Code: Bad RIP value.
> RSP: 002b:7ffddf4649b0 EFLAGS: 00010202
> RAX: 0001 RBX:  RCX: fffd
> RDX: 0001 RSI: 7ffddf4665e0 RDI: 
> RBP: 7ffddf4665e0 R08:  R09: 0001
> R10: 0064 R11: 0246 R12: 
> R13: 0003 R14:  R15: 
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> 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.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches

Thanks for the report.
This issue has been already fixed by
"mm-oom-make-the-calculation-of-oom-badness-more-accurate-v3", which
is already in the -next tree.


-- 
Thanks
Yafang


Re: Bug Report High CPU Usage events_power_efficient

2020-07-14 Thread Martin Zaharinov
Hi 

Oki i find the problem is come from nf_conntrack_core 

I isolate problem in this part :

queue_delayed_work(system_power_efficient_wq, _gc_work.dwork, HZ);


When package go to queue delayed in one moment if connection track is to big 
process to delayed go to lock and start high cpu load.

This is need to check and find solution…

For now I remove queue_delayed_work and wait to check machine and will write 
status.

Martin

> On 8 Jul 2020, at 12:28, Greg KH  wrote:
> 
> 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top
> 
> On Wed, Jul 08, 2020 at 11:34:52AM +0300, Martin Zaharinov wrote:
>> Yes i search but not find any information.
> 
> Please do the testing yourself, using 'git bisect' to find the offending
> commit.
> 
> thanks,
> 
> greg k-h



[PATCH 2/2] fpga: dfl: create a dfl bus type to support DFL devices

2020-07-14 Thread Xu Yilun
A new bus type "dfl" is introduced for private features which are not
initialized by DFL feature drivers (dfl-fme & dfl-afu drivers). So these
private features could be handled by separate driver modules.

DFL framework will create DFL devices on enumeration. DFL drivers could
be registered on this bus to match these DFL devices. They are matched by
dfl type & feature_id.

Signed-off-by: Xu Yilun 
Signed-off-by: Wu Hao 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
---
 Documentation/ABI/testing/sysfs-bus-dfl |  15 ++
 drivers/fpga/dfl.c  | 248 ++--
 drivers/fpga/dfl.h  |  85 +++
 3 files changed, 340 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl

diff --git a/Documentation/ABI/testing/sysfs-bus-dfl 
b/Documentation/ABI/testing/sysfs-bus-dfl
new file mode 100644
index 000..cd00abc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dfl
@@ -0,0 +1,15 @@
+What:  /sys/bus/dfl/devices/.../type
+Date:  March 2020
+KernelVersion: 5.7
+Contact:   Xu Yilun 
+Description:   Read-only. It returns type of DFL FIU of the device. Now DFL
+   supports 2 FIU types, 0 for FME, 1 for PORT.
+   Format: 0x%x
+
+What:  /sys/bus/dfl/devices/.../feature_id
+Date:  March 2020
+KernelVersion: 5.7
+Contact:   Xu Yilun 
+Description:   Read-only. It returns feature identifier local to its DFL FIU
+   type.
+   Format: 0x%llx
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 7dc6411..93f9d6d 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -30,12 +30,6 @@ static DEFINE_MUTEX(dfl_id_mutex);
  * index to dfl_chardevs table. If no chardev support just set devt_type
  * as one invalid index (DFL_FPGA_DEVT_MAX).
  */
-enum dfl_id_type {
-   FME_ID, /* fme id allocation and mapping */
-   PORT_ID,/* port id allocation and mapping */
-   DFL_ID_MAX,
-};
-
 enum dfl_fpga_devt_type {
DFL_FPGA_DEVT_FME,
DFL_FPGA_DEVT_PORT,
@@ -255,6 +249,228 @@ static bool is_header_feature(struct dfl_feature *feature)
return feature->id == FEATURE_ID_FIU_HEADER;
 }
 
+static const struct dfl_device_id *
+dfl_match_one_device(const struct dfl_device_id *id,
+struct dfl_device *dfl_dev)
+{
+   if (id->type == dfl_dev->type &&
+   id->feature_id == dfl_dev->feature_id)
+   return id;
+
+   return NULL;
+}
+
+static int dfl_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct dfl_device *dfl_dev = to_dfl_dev(dev);
+   struct dfl_driver *dfl_drv = to_dfl_drv(drv);
+   const struct dfl_device_id *id_entry = dfl_drv->id_table;
+
+   while (id_entry->feature_id) {
+   if (dfl_match_one_device(id_entry, dfl_dev)) {
+   dfl_dev->id_entry = id_entry;
+   return 1;
+   }
+   id_entry++;
+   }
+
+   return 0;
+}
+
+static int dfl_bus_probe(struct device *dev)
+{
+   struct dfl_device *dfl_dev = to_dfl_dev(dev);
+   struct dfl_driver *dfl_drv = to_dfl_drv(dev->driver);
+
+   return dfl_drv->probe(dfl_dev);
+}
+
+static int dfl_bus_remove(struct device *dev)
+{
+   struct dfl_device *dfl_dev = to_dfl_dev(dev);
+   struct dfl_driver *dfl_drv = to_dfl_drv(dev->driver);
+
+   if (dfl_drv->remove)
+   dfl_drv->remove(dfl_dev);
+
+   return 0;
+}
+
+static int dfl_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+   struct dfl_device *dfl_dev = to_dfl_dev(dev);
+
+   if (add_uevent_var(env, "MODALIAS=dfl:%08x:%016llx",
+  dfl_dev->type, dfl_dev->feature_id))
+   return -ENOMEM;
+
+   return 0;
+}
+
+/* show dfl info fields */
+#define dfl_info_attr(field, format_string)\
+static ssize_t \
+field##_show(struct device *dev, struct device_attribute *attr,
\
+char *buf) \
+{  \
+   struct dfl_device *dfl_dev = to_dfl_dev(dev);   \
+   \
+   return sprintf(buf, format_string, dfl_dev->field); \
+}  \
+static DEVICE_ATTR_RO(field)
+
+dfl_info_attr(type, "0x%x\n");
+dfl_info_attr(feature_id, "0x%llx\n");
+
+static struct attribute *dfl_dev_attrs[] = {
+   _attr_type.attr,
+   _attr_feature_id.attr,
+   NULL,
+};
+
+ATTRIBUTE_GROUPS(dfl_dev);
+
+static struct bus_type dfl_bus_type = {
+   .name   = "dfl",
+   .match  = dfl_bus_match,
+   .probe  = dfl_bus_probe,
+   .remove 

Re: [PATCH v4 net] rtnetlink: Fix memory(net_device) leak when ->newlink fails

2020-07-14 Thread Cong Wang
On Tue, Jul 14, 2020 at 6:27 PM Weilong Chen  wrote:
>
> When vlan_newlink call register_vlan_dev fails, it might return error
> with dev->reg_state = NETREG_UNREGISTERED. The rtnl_newlink should
> free the memory. But currently rtnl_newlink only free the memory which
> state is NETREG_UNINITIALIZED.
>
> BUG: memory leak
> unreferenced object 0x8881051de000 (size 4096):
>   comm "syz-executor139", pid 560, jiffies 4294745346 (age 32.445s)
>   hex dump (first 32 bytes):
> 76 6c 61 6e 32 00 00 00 00 00 00 00 00 00 00 00  vlan2...
> 00 45 28 03 81 88 ff ff 00 00 00 00 00 00 00 00  .E(.
>   backtrace:
> [<47527e31>] kmalloc_node include/linux/slab.h:578 [inline]
> [<47527e31>] kvmalloc_node+0x33/0xd0 mm/util.c:574
> [<2b59e3bc>] kvmalloc include/linux/mm.h:753 [inline]
> [<2b59e3bc>] kvzalloc include/linux/mm.h:761 [inline]
> [<2b59e3bc>] alloc_netdev_mqs+0x83/0xd90 net/core/dev.c:9929
> [<6076752a>] rtnl_create_link+0x2c0/0xa20 
> net/core/rtnetlink.c:3067
> [<572b3be5>] __rtnl_newlink+0xc9c/0x1330 net/core/rtnetlink.c:3329
> [] rtnl_newlink+0x66/0x90 net/core/rtnetlink.c:3397
> [<52c7c0a9>] rtnetlink_rcv_msg+0x540/0x990 
> net/core/rtnetlink.c:5460
> [<4b5cb379>] netlink_rcv_skb+0x12b/0x3a0 
> net/netlink/af_netlink.c:2469
> [] netlink_unicast_kernel net/netlink/af_netlink.c:1303 
> [inline]
> [] netlink_unicast+0x4c6/0x690 
> net/netlink/af_netlink.c:1329
> [] netlink_sendmsg+0x735/0xcc0 
> net/netlink/af_netlink.c:1918
> [<9221ebf7>] sock_sendmsg_nosec net/socket.c:652 [inline]
> [<9221ebf7>] sock_sendmsg+0x109/0x140 net/socket.c:672
> [<1c30ffe4>] sys_sendmsg+0x5f5/0x780 net/socket.c:2352
> [] ___sys_sendmsg+0x11d/0x1a0 net/socket.c:2406
> [<07297384>] __sys_sendmsg+0xeb/0x1b0 net/socket.c:2439
> [<0eb29b11>] do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
> [<6839b4d0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: e51fb152318ee6 ("rtnetlink: fix a memory leak when ->newlink fails")

This bug is apparently not introduced by my commit above.

It should be commit cb626bf566eb4433318d35681286c494f0,
right? That commit introduced NETREG_UNREGISTERED on the path.


Re: BUG: soft lockup in smp_call_function

2020-07-14 Thread syzbot
syzbot has bisected this issue to:

commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
Author: Vinicius Costa Gomes 
Date:   Sat Sep 29 00:59:43 2018 +

tc: Add support for configuring the taprio scheduler

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1196d06f10
start commit:   4437dd6e Merge tag 'io_uring-5.8-2020-07-12' of git://git...
git tree:   upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=1396d06f10
console output: https://syzkaller.appspot.com/x/log.txt?x=1596d06f10
kernel config:  https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
dashboard link: https://syzkaller.appspot.com/bug?extid=cce3691658bef1b12ac9
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11a160bf10
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16d2bd7710

Reported-by: syzbot+cce3691658bef1b12...@syzkaller.appspotmail.com
Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection


[PATCH 0/2] Modularization of DFL private feature drivers

2020-07-14 Thread Xu Yilun
This patchset makes it possible to develop independent driver modules
for DFL private features. It also helps to leverage existing kernel
drivers to enable some IP blocks in DFL.

Xu Yilun (2):
  fpga: dfl: map feature mmio resources in their own feature drivers
  fpga: dfl: create a dfl bus type to support DFL devices

 Documentation/ABI/testing/sysfs-bus-dfl |  15 ++
 drivers/fpga/dfl-pci.c  |  21 +-
 drivers/fpga/dfl.c  | 435 +++-
 drivers/fpga/dfl.h  |  91 ++-
 4 files changed, 492 insertions(+), 70 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl

-- 
2.7.4



[PATCH 1/2] fpga: dfl: map feature mmio resources in their own feature drivers

2020-07-14 Thread Xu Yilun
This patch makes preparation for modularization of DFL sub feature
drivers.

Currently, if we need to support a new DFL sub feature, an entry should
be added to fme/port_feature_drvs[] in dfl-fme/port-main.c. And we need
to re-compile the whole DFL modules. That make the DFL drivers hard to be
extended.

Another consideration is that DFL may contain some IP blocks which are
already supported by kernel, most of them are supported by platform
device drivers. We could create platform devices for these IP blocks and
get them supported by these drivers.

An important issue is that platform device drivers usually requests mmio
resources on probe. But now dfl mmio is mapped in dfl bus driver (e.g.
dfl-pci) as a whole region. Then platform device drivers for sub features
can't request their own mmio resources again. This is what the patch
trying to resolve.

This patch changes the DFL enumeration. DFL bus driver will unmap mmio
resources after first step enumeration and pass enumeration info to DFL
framework. Then DFL framework will map the mmio resources again, do 2nd
step enumeration, and also unmap the mmio resources. In this way, sub
feature drivers could then request their own mmio resources as needed.

An exception is that mmio resource of FIU headers are still mapped in dfl
bus driver. The FIU headers have some fundamental functions (sriov set,
port enable/disable) needed for dfl bus devices and other sub features.
They should not be unmapped as long as dfl bus device is alive.

Signed-off-by: Xu Yilun 
Signed-off-by: Wu Hao 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
---
 drivers/fpga/dfl-pci.c |  21 --
 drivers/fpga/dfl.c | 187 +++--
 drivers/fpga/dfl.h |   6 +-
 3 files changed, 152 insertions(+), 62 deletions(-)

diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index e220bec..22dc025 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -39,6 +39,11 @@ static void __iomem *cci_pci_ioremap_bar(struct pci_dev 
*pcidev, int bar)
return pcim_iomap_table(pcidev)[bar];
 }
 
+static void cci_pci_iounmap_bars(struct pci_dev *pcidev, int mapped_bars)
+{
+   pcim_iounmap_regions(pcidev, mapped_bars);
+}
+
 static int cci_pci_alloc_irq(struct pci_dev *pcidev)
 {
int ret, nvec = pci_msix_vec_count(pcidev);
@@ -123,7 +128,7 @@ static int *cci_pci_create_irq_table(struct pci_dev 
*pcidev, unsigned int nvec)
 static int cci_enumerate_feature_devs(struct pci_dev *pcidev)
 {
struct cci_drvdata *drvdata = pci_get_drvdata(pcidev);
-   int port_num, bar, i, nvec, ret = 0;
+   int port_num, bar, i, nvec, mapped_bars, ret = 0;
struct dfl_fpga_enum_info *info;
struct dfl_fpga_cdev *cdev;
resource_size_t start, len;
@@ -163,6 +168,8 @@ static int cci_enumerate_feature_devs(struct pci_dev 
*pcidev)
goto irq_free_exit;
}
 
+   mapped_bars = BIT(0);
+
/*
 * PF device has FME and Ports/AFUs, and VF device only has one
 * Port/AFU. Check them and add related "Device Feature List" info
@@ -172,7 +179,7 @@ static int cci_enumerate_feature_devs(struct pci_dev 
*pcidev)
start = pci_resource_start(pcidev, 0);
len = pci_resource_len(pcidev, 0);
 
-   dfl_fpga_enum_info_add_dfl(info, start, len, base);
+   dfl_fpga_enum_info_add_dfl(info, start, len);
 
/*
 * find more Device Feature Lists (e.g. Ports) per information
@@ -200,22 +207,26 @@ static int cci_enumerate_feature_devs(struct pci_dev 
*pcidev)
if (!base)
continue;
 
+   mapped_bars |= BIT(bar);
+
start = pci_resource_start(pcidev, bar) + offset;
len = pci_resource_len(pcidev, bar) - offset;
 
-   dfl_fpga_enum_info_add_dfl(info, start, len,
-  base + offset);
+   dfl_fpga_enum_info_add_dfl(info, start, len);
}
} else if (dfl_feature_is_port(base)) {
start = pci_resource_start(pcidev, 0);
len = pci_resource_len(pcidev, 0);
 
-   dfl_fpga_enum_info_add_dfl(info, start, len, base);
+   dfl_fpga_enum_info_add_dfl(info, start, len);
} else {
ret = -ENODEV;
goto irq_free_exit;
}
 
+   /* release I/O mappings for next step enumeration */
+   cci_pci_iounmap_bars(pcidev, mapped_bars);
+
/* start enumeration with prepared enumeration information */
cdev = dfl_fpga_feature_devs_enumerate(info);
if (IS_ERR(cdev)) {
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 649958a..7dc6411 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -250,6 +250,11 @@ int dfl_fpga_check_port_id(struct platform_device *pdev, 
void 

Re: [PATCH] serial: 8250_mtk: Fix high-speed baud rates clamping

2020-07-14 Thread Claire Chang
On Wed, Jul 15, 2020 at 4:45 AM Daniel Winkler  wrote:
>
> Thank you Sergey for looking into this. Adding folks working on this
> platform to perform validation of the proposed patch.
>
> Best,
> Daniel
>
> On Tue, Jul 14, 2020 at 5:41 AM Serge Semin
>  wrote:
> >
> > Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250
> > port") fixed limits of a baud rate setting for a generic 8250 port.
> > In other words since that commit the baud rate has been permitted to be
> > within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely
> > normal for a standard 8250 UART port. But there are custom 8250 ports,
> > which provide extended baud rate limits. In particular the Mediatek 8250
> > port can work with baud rates up to "uartclk" speed.
> >
> > Normally that and any other peculiarity is supposed to be handled in a
> > custom set_termios() callback implemented in the vendor-specific
> > 8250-port glue-driver. Currently that is how it's done for the most of
> > the vendor-specific 8250 ports, but for some reason for Mediatek a
> > solution has been spread out to both the glue-driver and to the generic
> > 8250-port code. Due to that a bug has been introduced, which permitted the
> > extended baud rate limit for all even for standard 8250-ports. The bug
> > has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud
> > limit in generic 8250 port") by narrowing the baud rates limit back down to
> > the normal bounds. Unfortunately by doing so we also broke the
> > Mediatek-specific extended bauds feature.
> >
> > A fix of the problem described above is twofold. First since we can't get
> > back the extended baud rate limits feature to the generic set_termios()
> > function and that method supports only a standard baud rates range, the
> > requested baud rate must be locally stored before calling it and then
> > restored back to the new termios structure after the generic set_termios()
> > finished its magic business. By doing so we still use the
> > serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers,
> > while the extended baud rate setting procedure will be performed later in
> > the custom Mediatek-specific set_termios() callback. Second since a true
> > baud rate is now fully calculated in the custom set_termios() method we
> > need to locally update the port timeout by calling the
> > uart_update_timeout() function. After the fixes described above are
> > implemented in the 8250_mtk.c driver, the Mediatek 8250-port should
> > get back to normally working with extended baud rates.
> >
> > Link: 
> > https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwink...@google.com
> >
> > Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 
> > port")
> > Reported-by: Daniel Winkler 
> > Signed-off-by: Serge Semin 
Tested-by: Claire Chang 
> >
> > ---
> >
> > Folks, sorry for a delay with the problem fix. A solution is turned out to
> > be a bit more complicated than I originally thought in my comment to the
> > Daniel revert-patch.
> >
> > Please also note, that I don't have a Mediatek hardware to test the
> > solution suggested in the patch. The code is written as on so called
> > the tip of the pen after digging into the 8250_mtk.c and 8250_port.c
> > drivers code. So please Daniel or someone with Mediatek 8250-port
> > available on a board test this patch first and report about the results in
> > reply to this emailing thread. After that, if your conclusion is positive
> > and there is no objection against the solution design the patch can be
> > merged in.
I tested it with mt8183 + QCA6174.
The UART Bluetooth works fine with this fix.
Thanks!
> >
> > Cc: Alexey Malahov 
> > Cc: Daniel Winkler 
> > Cc: Aaron Sierra 
> > Cc: Andy Shevchenko 
> > Cc: Lukas Wunner 
> > Cc: Vignesh Raghavendra 
> > Cc: linux-ser...@vger.kernel.org
> > Cc: linux-media...@lists.infradead.org
> > Cc: BlueZ 
> > Cc: chromeos-bluetooth-upstreaming 
> > 
> > Cc: abhishekpan...@chromium.org
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/tty/serial/8250/8250_mtk.c | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250_mtk.c 
> > b/drivers/tty/serial/8250/8250_mtk.c
> > index f839380c2f4c..98b8a3e30733 100644
> > --- a/drivers/tty/serial/8250/8250_mtk.c
> > +++ b/drivers/tty/serial/8250/8250_mtk.c
> > @@ -306,8 +306,21 @@ mtk8250_set_termios(struct uart_port *port, struct 
> > ktermios *termios,
> > }
> >  #endif
> >
> > +   /*
> > +* Store the requested baud rate before calling the generic 8250
> > +* set_termios method. Standard 8250 port expects bauds to be
> > +* no higher than (uartclk / 16) so the baud will be clamped if it
> > +* gets out of that bound. Mediatek 8250 port supports speed
> > +* higher than that, therefore we'll get original baud rate back
> > +* after calling the generic set_termios method and recalculate
> 

[PATCH v2 bpf-next 2/2] selftests/bpf: add callchain_stackid

2020-07-14 Thread Song Liu
This tests new helper function bpf_get_stackid_pe and bpf_get_stack_pe.
These two helpers have different implementation for perf_event with PEB
entries.

Signed-off-by: Song Liu 
---
 .../bpf/prog_tests/perf_event_stackmap.c  | 120 ++
 .../selftests/bpf/progs/perf_event_stackmap.c |  64 ++
 2 files changed, 184 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_event_stackmap.c
 create mode 100644 tools/testing/selftests/bpf/progs/perf_event_stackmap.c

diff --git a/tools/testing/selftests/bpf/prog_tests/perf_event_stackmap.c 
b/tools/testing/selftests/bpf/prog_tests/perf_event_stackmap.c
new file mode 100644
index 0..6dcc67572afc7
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/perf_event_stackmap.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 Facebook
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include "perf_event_stackmap.skel.h"
+
+#ifndef noinline
+#define noinline __attribute__((noinline))
+#endif
+
+noinline int func_1(void)
+{
+   static int val = 1;
+
+   val += 1;
+
+   usleep(100);
+   return val;
+}
+
+noinline int func_2(void)
+{
+   return func_1();
+}
+
+noinline int func_3(void)
+{
+   return func_2();
+}
+
+noinline int func_4(void)
+{
+   return func_3();
+}
+
+noinline int func_5(void)
+{
+   return func_4();
+}
+
+noinline int func_6(void)
+{
+   int i, val = 1;
+
+   for (i = 0; i < 100; i++)
+   val += func_5();
+
+   return val;
+}
+
+void test_perf_event_stackmap(void)
+{
+   struct perf_event_attr attr = {
+   /* .type = PERF_TYPE_SOFTWARE, */
+   .type = PERF_TYPE_HARDWARE,
+   .config = PERF_COUNT_HW_CPU_CYCLES,
+   .precise_ip = 2,
+   .sample_type = PERF_SAMPLE_IP | PERF_SAMPLE_BRANCH_STACK |
+   PERF_SAMPLE_CALLCHAIN,
+   .branch_sample_type = PERF_SAMPLE_BRANCH_USER |
+   PERF_SAMPLE_BRANCH_NO_FLAGS |
+   PERF_SAMPLE_BRANCH_NO_CYCLES |
+   PERF_SAMPLE_BRANCH_CALL_STACK,
+   .sample_period = 5000,
+   .size = sizeof(struct perf_event_attr),
+   };
+   struct perf_event_stackmap *skel;
+   __u32 duration = 0;
+   cpu_set_t cpu_set;
+   int pmu_fd, err;
+
+   skel = perf_event_stackmap__open();
+
+   if (CHECK(!skel, "skel_open", "skeleton open failed\n"))
+   return;
+
+   /* override program type */
+   bpf_program__set_perf_event(skel->progs.oncpu);
+
+   err = perf_event_stackmap__load(skel);
+   if (CHECK(err, "skel_load", "skeleton load failed: %d\n", err))
+   goto cleanup;
+
+   CPU_ZERO(_set);
+   CPU_SET(0, _set);
+   err = pthread_setaffinity_np(pthread_self(), sizeof(cpu_set), _set);
+   if (CHECK(err, "set_affinity", "err %d, errno %d\n", err, errno))
+   goto cleanup;
+
+   pmu_fd = syscall(__NR_perf_event_open, , -1 /* pid */,
+0 /* cpu 0 */, -1 /* group id */,
+0 /* flags */);
+   if (pmu_fd < 0) {
+   printf("%s:SKIP:cpu doesn't support the event\n", __func__);
+   test__skip();
+   goto cleanup;
+   }
+
+   skel->links.oncpu = bpf_program__attach_perf_event(skel->progs.oncpu,
+  pmu_fd);
+   if (CHECK(IS_ERR(skel->links.oncpu), "attach_perf_event",
+ "err %ld\n", PTR_ERR(skel->links.oncpu))) {
+   close(pmu_fd);
+   goto cleanup;
+   }
+
+   /* create kernel and user stack traces for testing */
+   func_6();
+
+   CHECK(skel->data->stackid_kernel != 2, "get_stackid_kernel", 
"failed\n");
+   CHECK(skel->data->stackid_user != 2, "get_stackid_user", "failed\n");
+   CHECK(skel->data->stack_kernel != 2, "get_stack_kernel", "failed\n");
+   CHECK(skel->data->stack_user != 2, "get_stack_user", "failed\n");
+   close(pmu_fd);
+
+cleanup:
+   perf_event_stackmap__destroy(skel);
+}
diff --git a/tools/testing/selftests/bpf/progs/perf_event_stackmap.c 
b/tools/testing/selftests/bpf/progs/perf_event_stackmap.c
new file mode 100644
index 0..1b0457efeedec
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/perf_event_stackmap.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 Facebook
+#include "vmlinux.h"
+#include 
+
+#ifndef PERF_MAX_STACK_DEPTH
+#define PERF_MAX_STACK_DEPTH 127
+#endif
+
+#ifndef BPF_F_USER_STACK
+#define BPF_F_USER_STACK   (1ULL << 8)
+#endif
+
+typedef __u64 stack_trace_t[PERF_MAX_STACK_DEPTH];
+struct {
+   __uint(type, BPF_MAP_TYPE_STACK_TRACE);
+   __uint(max_entries, 16384);
+   __uint(key_size, sizeof(__u32));
+   __uint(value_size, sizeof(stack_trace_t));
+} stackmap SEC(".maps");
+
+struct 

INFO: rcu detected stall in __do_sys_clock_adjtime

2020-07-14 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:a581387e Merge tag 'io_uring-5.8-2020-07-10' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1312c27710
kernel config:  https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
dashboard link: https://syzkaller.appspot.com/bug?extid=587a843fe6b38420a209
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=14778a7710
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15150e1310

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

rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu:0-...0: (1 GPs behind) idle=c22/1/0x4000 
softirq=10714/10715 fqs=5249 
(detected by 1, t=10502 jiffies, g=10189, q=4119)
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 6820 Comm: syz-executor767 Not tainted 5.8.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:should_restart_cycle net/sched/sch_taprio.c:647 [inline]
RIP: 0010:advance_sched+0x236/0x990 net/sched/sch_taprio.c:723
Code: 00 0f 85 d1 06 00 00 48 8d 7d 28 4d 8b 65 00 48 b8 00 00 00 00 00 fc ff 
df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 cf 06 00 00 <4c> 39 64 24 20 4c 8b 7d 
28 0f 84 3c 03 00 00 e8 26 aa 11 fb 4c 89
RSP: 0018:c9007d78 EFLAGS: 0046
RAX: dc00 RBX: 8880a0d9db40 RCX: 86620d01
RDX: 111013ee0ae5 RSI: 86620d0f RDI: 88809f705728
RBP: 88809f705700 R08: 0001 R09: 0003
R10: 17432cbe2e86597c R11:  R12: 88809f705710
R13: 888094684700 R14: 17432cbe2e86597c R15: dc00
FS:  01fb4880() GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2610 CR3: 9e89 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 
 __run_hrtimer kernel/time/hrtimer.c:1520 [inline]
 __hrtimer_run_queues+0x6a9/0xfc0 kernel/time/hrtimer.c:1584
 hrtimer_interrupt+0x32a/0x930 kernel/time/hrtimer.c:1646
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1080 [inline]
 __sysvec_apic_timer_interrupt+0x142/0x5e0 arch/x86/kernel/apic/apic.c:1097
 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711
 
 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
 run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
 sysvec_apic_timer_interrupt+0xe0/0x120 arch/x86/kernel/apic/apic.c:1091
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:765 [inline]
RIP: 0010:on_each_cpu+0x149/0x240 kernel/smp.c:702
Code: 00 fc ff df 48 c1 e8 03 80 3c 10 00 0f 85 e6 00 00 00 48 83 3d 97 12 4c 
08 00 0f 84 af 00 00 00 e8 9c e9 0a 00 48 89 df 57 9d <0f> 1f 44 00 00 e8 8d e9 
0a 00 bf 01 00 00 00 e8 83 a4 e6 ff 31 ff
RSP: 0018:c900017f7b68 EFLAGS: 0293
RAX:  RBX: 0293 RCX: 
RDX: 88809e192500 RSI: 8168cdf4 RDI: 0293
RBP: 0200 R08:  R09: 
R10: 0001 R11:  R12: 
R13: 001e89e9b1852336 R14: 003b9aca R15: 
 clock_was_set+0x18/0x20 kernel/time/hrtimer.c:872
 timekeeping_inject_offset+0x3e9/0x4d0 kernel/time/timekeeping.c:1305
 do_adjtimex+0x28f/0x990 kernel/time/timekeeping.c:2332
 do_clock_adjtime kernel/time/posix-timers.c:1109 [inline]
 __do_sys_clock_adjtime+0x155/0x250 kernel/time/posix-timers.c:1121
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x443949
Code: Bad RIP value.
RSP: 002b:7ffef6e7f668 EFLAGS: 0246 ORIG_RAX: 0131
RAX: ffda RBX: 0003 RCX: 00443949
RDX: 00443949 RSI: 2300 RDI: 
RBP: 7ffef6e7f670 R08: 01bb R09: 01bb
R10: 01bb R11: 0246 R12: 7ffef6e7f680
R13:  R14:  R15: 
INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 0.000 msecs


---
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


[PATCH v2 bpf-next 1/2] bpf: separate bpf_get_[stack|stackid] for perf events BPF

2020-07-14 Thread Song Liu
Calling get_perf_callchain() on perf_events from PEBS entries may cause
unwinder errors. To fix this issue, the callchain is fetched early. Such
perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY.

Similarly, calling bpf_get_[stack|stackid] on perf_events from PEBS may
also cause unwinder errors. To fix this, add separate version of these
two helpers, bpf_get_[stack|stackid]_pe. These two hepers use callchain in
bpf_perf_event_data_kern->data->callchain.

Signed-off-by: Song Liu 
---
 include/linux/bpf.h  |   2 +
 kernel/bpf/stackmap.c| 204 +++
 kernel/trace/bpf_trace.c |   4 +-
 3 files changed, 190 insertions(+), 20 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index c67c88ad35f85..bfc7a283c0f93 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1637,6 +1637,8 @@ extern const struct bpf_func_proto 
bpf_get_current_comm_proto;
 extern const struct bpf_func_proto bpf_get_stackid_proto;
 extern const struct bpf_func_proto bpf_get_stack_proto;
 extern const struct bpf_func_proto bpf_get_task_stack_proto;
+extern const struct bpf_func_proto bpf_get_stackid_proto_pe;
+extern const struct bpf_func_proto bpf_get_stack_proto_pe;
 extern const struct bpf_func_proto bpf_sock_map_update_proto;
 extern const struct bpf_func_proto bpf_sock_hash_update_proto;
 extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 48d8e739975fa..0587d4ddb06ce 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -387,11 +388,10 @@ get_callchain_entry_for_task(struct task_struct *task, 
u32 init_nr)
 #endif
 }
 
-BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
-  u64, flags)
+static long __bpf_get_stackid(struct bpf_map *map,
+ struct perf_callchain_entry *trace, u64 flags)
 {
struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, 
map);
-   struct perf_callchain_entry *trace;
struct stack_map_bucket *bucket, *new_bucket, *old_bucket;
u32 max_depth = map->value_size / stack_map_data_size(map);
/* stack_map_alloc() checks that max_depth <= 
sysctl_perf_event_max_stack */
@@ -399,21 +399,9 @@ BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct 
bpf_map *, map,
u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
u32 hash, id, trace_nr, trace_len;
bool user = flags & BPF_F_USER_STACK;
-   bool kernel = !user;
u64 *ips;
bool hash_matches;
 
-   if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
-  BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
-   return -EINVAL;
-
-   trace = get_perf_callchain(regs, init_nr, kernel, user,
-  sysctl_perf_event_max_stack, false, false);
-
-   if (unlikely(!trace))
-   /* couldn't fetch the stack trace */
-   return -EFAULT;
-
/* get_perf_callchain() guarantees that trace->nr >= init_nr
 * and trace-nr <= sysctl_perf_event_max_stack, so trace_nr <= max_depth
 */
@@ -478,6 +466,30 @@ BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct 
bpf_map *, map,
return id;
 }
 
+BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
+  u64, flags)
+{
+   u32 max_depth = map->value_size / stack_map_data_size(map);
+   /* stack_map_alloc() checks that max_depth <= 
sysctl_perf_event_max_stack */
+   u32 init_nr = sysctl_perf_event_max_stack - max_depth;
+   bool user = flags & BPF_F_USER_STACK;
+   struct perf_callchain_entry *trace;
+   bool kernel = !user;
+
+   if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
+  BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
+   return -EINVAL;
+
+   trace = get_perf_callchain(regs, init_nr, kernel, user,
+  sysctl_perf_event_max_stack, false, false);
+
+   if (unlikely(!trace))
+   /* couldn't fetch the stack trace */
+   return -EFAULT;
+
+   return __bpf_get_stackid(map, trace, flags);
+}
+
 const struct bpf_func_proto bpf_get_stackid_proto = {
.func   = bpf_get_stackid,
.gpl_only   = true,
@@ -487,7 +499,87 @@ const struct bpf_func_proto bpf_get_stackid_proto = {
.arg3_type  = ARG_ANYTHING,
 };
 
+static __u64 count_kernel_ip(struct perf_callchain_entry *trace)
+{
+   __u64 nr_kernel = 0;
+
+   while (nr_kernel < trace->nr) {
+   if (trace->ip[nr_kernel] == PERF_CONTEXT_USER)
+   break;
+   nr_kernel++;
+   }
+   return nr_kernel;
+}
+
+BPF_CALL_3(bpf_get_stackid_pe, struct bpf_perf_event_data_kern *, ctx,
+  struct bpf_map *, 

[PATCH v2 bpf-next 0/2] bpf: fix stackmap on perf_events with PEBS

2020-07-14 Thread Song Liu
Calling get_perf_callchain() on perf_events from PEBS entries may cause
unwinder errors. To fix this issue, perf subsystem fetches callchain early,
and marks perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY.
Similar issue exists when BPF program calls get_perf_callchain() via
helper functions. For more information about this issue, please refer to
discussions in [1].

This set fixes this issue with helper proto bpf_get_stackid_pe and
bpf_get_stack_pe.

[1] https://lore.kernel.org/lkml/ed7b9430-6489-4260-b3c5-9cfa2e3aa...@fb.com/

Changes v1 => v2:
1. Simplify the design and avoid introducing new helper function. (Andrii)

Song Liu (2):
  bpf: separate bpf_get_[stack|stackid] for perf events BPF
  selftests/bpf: add callchain_stackid

 include/linux/bpf.h   |   2 +
 kernel/bpf/stackmap.c | 204 --
 kernel/trace/bpf_trace.c  |   4 +-
 .../bpf/prog_tests/perf_event_stackmap.c  | 120 +++
 .../selftests/bpf/progs/perf_event_stackmap.c |  64 ++
 5 files changed, 374 insertions(+), 20 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_event_stackmap.c
 create mode 100644 tools/testing/selftests/bpf/progs/perf_event_stackmap.c

--
2.24.1


回复: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible code

2020-07-14 Thread Zhang, Qiang



发件人: Tuong Tong Lien 
发送时间: 2020年7月15日 11:53
收件人: Zhang, Qiang; Eric Dumazet; jma...@redhat.com; da...@davemloft.net; 
k...@kernel.org; Xue, Ying
抄送: net...@vger.kernel.org; tipc-discuss...@lists.sourceforge.net; 
linux-kernel@vger.kernel.org
主题: RE: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible code



> -Original Message-
> From: Zhang, Qiang 
> Sent: Wednesday, July 15, 2020 9:13 AM
> To: Eric Dumazet ; jma...@redhat.com; 
> da...@davemloft.net; k...@kernel.org; Tuong Tong Lien
> ; Xue, Ying 
> Cc: net...@vger.kernel.org; tipc-discuss...@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org
> Subject: 回复: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible 
> code
>
>
>
> 
> 发件人: Eric Dumazet 
> 发送时间: 2020年7月14日 22:15
> 收件人: Zhang, Qiang; jma...@redhat.com; da...@davemloft.net; k...@kernel.org; 
> tuong.t.l...@dektech.com.au;
> eric.duma...@gmail.com; Xue, Ying
> 抄送: net...@vger.kernel.org; tipc-discuss...@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org
> 主题: Re: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible code
>
>
>
> On 7/14/20 1:05 AM, qiang.zh...@windriver.com wrote:
> > From: Zhang Qiang 
> >
> > CPU: 0 PID: 6801 Comm: syz-executor201 Not tainted 5.8.0-rc4-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > BIOS Google 01/01/2011
> >
> > Fixes: fc1b6d6de2208 ("tipc: introduce TIPC encryption & authentication")
> > Reported-by: syzbot+263f8c0d007dc09b2...@syzkaller.appspotmail.com
> > Signed-off-by: Zhang Qiang 
> > ---
> >  v1->v2:
> >  add fixes tags.
> >
> >  net/tipc/crypto.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
> > index 8c47ded2edb6..520af0afe1b3 100644
> > --- a/net/tipc/crypto.c
> > +++ b/net/tipc/crypto.c
> > @@ -399,9 +399,10 @@ static void tipc_aead_users_set(struct tipc_aead __rcu 
> > *aead, int val)
> >   */
> >  static struct crypto_aead *tipc_aead_tfm_next(struct tipc_aead *aead)
> >  {
> > - struct tipc_tfm **tfm_entry = this_cpu_ptr(aead->tfm_entry);
> > + struct tipc_tfm **tfm_entry = get_cpu_ptr(aead->tfm_entry);
> >
> >   *tfm_entry = list_next_entry(*tfm_entry, list);
> > + put_cpu_ptr(tfm_entry);
> >   return (*tfm_entry)->tfm;
> >  }
> >
> >
>
> > You have not explained why this was safe.
> >
> >  This seems to hide a real bug.
> >
> > Presumably callers of this function should have disable preemption, and 
> > maybe > interrupts as well.
> >
> >Right after put_cpu_ptr(tfm_entry), this thread could migrate to another 
> >cpu, >and still access
> >data owned by the old cpu.
>
> Thanks for you suggest, I will check code again.
>

>Actually, last week I sent a similar patch to tipc-discussion which covers the
>case as well (there is also another place causing the same issue...). If you
>don't mind, you can take a look at below (just copied/pasted).

>BR/Tuong


Hi Tuong Tong Lien

The tipc_aead_free is RCU callback, this func is called in softirq context 
which 
preemption has been banned
so should not add preempt_disable/enable.

thanks
Zhang Qiang


>-Original Message-
>From: Tuong Tong Lien 
>Sent: Friday, July 10, 2020 5:11 PM
>To: jma...@redhat.com; ma...@donjonn.com; ying@windriver.com; 
>tipc-discuss...@lists.sourceforge.net
>Cc: tipc-dek 
Subject: [PATCH RFC 1/5] tipc: fix using smp_processor_id() in preemptible
>
>The 'this_cpu_ptr()' is used to obtain the AEAD key' TFM on the current
CPU for encryption, however the execution can be preemptible since it's
actually user-space context, so the 'using smp_processor_id() in
preemptible' has been observed.

We fix the issue by using the 'get/put_cpu_ptr()' API which consists of
a 'preempt_disable()' instead.

Signed-off-by: Tuong Lien 
---
 net/tipc/crypto.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index c8c47fc72653..1827ce4fac5d 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -326,7 +326,8 @@ static void tipc_aead_free(struct rcu_head *rp)
if (aead->cloned) {
tipc_aead_put(aead->cloned);
} else {
-   head = *this_cpu_ptr(aead->tfm_entry);
+   head = *get_cpu_ptr(aead->tfm_entry);
+   put_cpu_ptr(aead->tfm_entry);
list_for_each_entry_safe(tfm_entry, tmp, >list, list) {
crypto_free_aead(tfm_entry->tfm);
list_del(_entry->list);
@@ -399,10 +400,15 @@ static void tipc_aead_users_set(struct tipc_aead __rcu 
*aead, int val)
  */
 static struct crypto_aead *tipc_aead_tfm_next(struct tipc_aead *aead)
 {
-   struct tipc_tfm **tfm_entry = this_cpu_ptr(aead->tfm_entry);
+   struct tipc_tfm **tfm_entry;
+   struct crypto_aead *tfm;

+   tfm_entry = get_cpu_ptr(aead->tfm_entry);
*tfm_entry = 

[PATCH v2 2/2] spi: coldfire-qspi: Use clk_prepare_enable and clk_disable_unprepare

2020-07-14 Thread Qing Zhang
Convert clk_enable() to clk_prepare_enable() and clk_disable() to
clk_disable_unprepare() respectively in the spi-coldfire-qspi.c.

Signed-off-by: Qing Zhang 
---

v2:
-Modify the commit message
-Split into two patches

 drivers/spi/spi-coldfire-qspi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-coldfire-qspi.c b/drivers/spi/spi-coldfire-qspi.c
index f80e06c..8996115 100644
--- a/drivers/spi/spi-coldfire-qspi.c
+++ b/drivers/spi/spi-coldfire-qspi.c
@@ -387,7 +387,7 @@ static int mcfqspi_probe(struct platform_device *pdev)
status = PTR_ERR(mcfqspi->clk);
goto fail0;
}
-   clk_enable(mcfqspi->clk);
+   clk_prepare_enable(mcfqspi->clk);
 
master->bus_num = pdata->bus_num;
master->num_chipselect = pdata->num_chipselect;
@@ -425,7 +425,7 @@ static int mcfqspi_probe(struct platform_device *pdev)
pm_runtime_disable(>dev);
mcfqspi_cs_teardown(mcfqspi);
 fail1:
-   clk_disable(mcfqspi->clk);
+   clk_disable_unprepare(mcfqspi->clk);
 fail0:
spi_master_put(master);
 
-- 
2.1.0



[PATCH v2 1/2] spi: omap-uwire: Use clk_prepare_enable and clk_disable_unprepare

2020-07-14 Thread Qing Zhang
Convert clk_enable() to clk_prepare_enable() and clk_disable() to
clk_disable_unprepare() respectively in the spi-omap-uwire.c.

Signed-off-by: Qing Zhang 
---

v2:
  -Modify the commit message
  -Split into two patches

 drivers/spi/spi-omap-uwire.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-omap-uwire.c b/drivers/spi/spi-omap-uwire.c
index ce8dbdb..71402f7 100644
--- a/drivers/spi/spi-omap-uwire.c
+++ b/drivers/spi/spi-omap-uwire.c
@@ -443,7 +443,7 @@ static void uwire_cleanup(struct spi_device *spi)
 static void uwire_off(struct uwire_spi *uwire)
 {
uwire_write_reg(UWIRE_SR3, 0);
-   clk_disable(uwire->ck);
+   clk_disable_unprepare(uwire->ck);
spi_master_put(uwire->bitbang.master);
 }
 
@@ -475,7 +475,7 @@ static int uwire_probe(struct platform_device *pdev)
spi_master_put(master);
return status;
}
-   clk_enable(uwire->ck);
+   clk_prepare_enable(uwire->ck);
 
if (cpu_is_omap7xx())
uwire_idx_shift = 1;
-- 
2.1.0



[PATCH 3/7] drm: drm_gem.h: delete duplicated words in comments

2020-07-14 Thread Randy Dunlap
Drop the doubled words "the" and "by" in comments.

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drm_gem.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20200714.orig/include/drm/drm_gem.h
+++ linux-next-20200714/include/drm/drm_gem.h
@@ -143,7 +143,7 @@ struct drm_gem_object_funcs {
/**
 * @vunmap:
 *
-* Releases the the address previously returned by @vmap. Used by the
+* Releases the address previously returned by @vmap. Used by the
 * drm_gem_dmabuf_vunmap() helper.
 *
 * This callback is optional.
@@ -157,7 +157,7 @@ struct drm_gem_object_funcs {
 *
 * This callback is optional.
 *
-* The callback is used by by both drm_gem_mmap_obj() and
+* The callback is used by both drm_gem_mmap_obj() and
 * drm_gem_prime_mmap().  When @mmap is present @vm_ops is not
 * used, the @mmap callback must set vma->vm_ops instead.
 */


[PATCH 7/7] drm: drm_rect.h: delete duplicated word in comment

2020-07-14 Thread Randy Dunlap
Drop doubled word "the" in a comment.

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drm_rect.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/drm/drm_rect.h
+++ linux-next-20200714/include/drm/drm_rect.h
@@ -180,7 +180,7 @@ static inline int drm_rect_height(const
 }
 
 /**
- * drm_rect_visible - determine if the the rectangle is visible
+ * drm_rect_visible - determine if the rectangle is visible
  * @r: rectangle whose visibility is returned
  *
  * RETURNS:


[PATCH 2/7] drm: drm_bridge.h: delete duplicated word in comment

2020-07-14 Thread Randy Dunlap
Drop doubled word "should" in a comment.

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drm_bridge.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/drm/drm_bridge.h
+++ linux-next-20200714/include/drm/drm_bridge.h
@@ -475,7 +475,7 @@ struct drm_bridge_funcs {
 * one of them should be provided.
 *
 * If drivers need to tweak _bridge_state.input_bus_cfg.flags or
-* _bridge_state.output_bus_cfg.flags it should should happen in
+* _bridge_state.output_bus_cfg.flags it should happen in
 * this function. By default the _bridge_state.output_bus_cfg.flags
 * field is set to the next bridge
 * _bridge_state.input_bus_cfg.flags value or


[PATCH 4/7] drm: drm_mode_config.h: delete duplicated words in comments

2020-07-14 Thread Randy Dunlap
Drop doubled word "is" in several comments.

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drm_mode_config.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-next-20200714.orig/include/drm/drm_mode_config.h
+++ linux-next-20200714/include/drm/drm_mode_config.h
@@ -603,22 +603,22 @@ struct drm_mode_config {
struct drm_property *prop_src_h;
/**
 * @prop_crtc_x: Default atomic plane property for the plane destination
-* position in the _crtc is is being shown on.
+* position in the _crtc is being shown on.
 */
struct drm_property *prop_crtc_x;
/**
 * @prop_crtc_y: Default atomic plane property for the plane destination
-* position in the _crtc is is being shown on.
+* position in the _crtc is being shown on.
 */
struct drm_property *prop_crtc_y;
/**
 * @prop_crtc_w: Default atomic plane property for the plane destination
-* position in the _crtc is is being shown on.
+* position in the _crtc is being shown on.
 */
struct drm_property *prop_crtc_w;
/**
 * @prop_crtc_h: Default atomic plane property for the plane destination
-* position in the _crtc is is being shown on.
+* position in the _crtc is being shown on.
 */
struct drm_property *prop_crtc_h;
/**


[PATCH 6/7] drm: msm_drm.h: delete duplicated words in comments

2020-07-14 Thread Randy Dunlap
Drop the doubled word "to" in comments.

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/uapi/drm/msm_drm.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20200714.orig/include/uapi/drm/msm_drm.h
+++ linux-next-20200714/include/uapi/drm/msm_drm.h
@@ -252,8 +252,8 @@ struct drm_msm_gem_submit {
__u64 cmds;   /* in, ptr to array of submit_cmd's */
__s32 fence_fd;   /* in/out fence fd (see 
MSM_SUBMIT_FENCE_FD_IN/OUT) */
__u32 queueid;/* in, submitqueue id */
-   __u64 in_syncobjs;/* in, ptr to to array of 
drm_msm_gem_submit_syncobj */
-   __u64 out_syncobjs;   /* in, ptr to to array of 
drm_msm_gem_submit_syncobj */
+   __u64 in_syncobjs;/* in, ptr to array of drm_msm_gem_submit_syncobj 
*/
+   __u64 out_syncobjs;   /* in, ptr to array of drm_msm_gem_submit_syncobj 
*/
__u32 nr_in_syncobjs; /* in, number of entries in in_syncobj */
__u32 nr_out_syncobjs; /* in, number of entries in out_syncobj. */
__u32 syncobj_stride; /* in, stride of syncobj arrays. */


[PATCH 5/7] drm: i915_drm.h: delete duplicated words in comments

2020-07-14 Thread Randy Dunlap
Drop doubled words "the" and "be" in comments.

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/uapi/drm/i915_drm.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20200714.orig/include/uapi/drm/i915_drm.h
+++ linux-next-20200714/include/uapi/drm/i915_drm.h
@@ -55,7 +55,7 @@ extern "C" {
  * cause the related events to not be seen.
  *
  * I915_RESET_UEVENT - Event is generated just before an attempt to reset the
- * the GPU. The value supplied with the event is always 1. NOTE: Disable
+ * GPU. The value supplied with the event is always 1. NOTE: Disable
  * reset via module parameter will cause this event to not be seen.
  */
 #define I915_L3_PARITY_UEVENT  "L3_PARITY_ERROR"
@@ -1934,7 +1934,7 @@ enum drm_i915_perf_property_id {
 
/**
 * The value specifies which set of OA unit metrics should be
-* be configured, defining the contents of any OA unit reports.
+* configured, defining the contents of any OA unit reports.
 *
 * This property is available in perf revision 1.
 */


[PATCH 1/7] drm: drm_atomic.h: delete duplicated word in comment

2020-07-14 Thread Randy Dunlap
Drop doubled word "than" in a comment.

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drm_atomic.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/drm/drm_atomic.h
+++ linux-next-20200714/include/drm/drm_atomic.h
@@ -103,7 +103,7 @@ struct drm_crtc_commit {
 *
 * Will be signalled when all hw register changes for this commit have
 * been written out. Especially when disabling a pipe this can be much
-* later than than @flip_done, since that can signal already when the
+* later than @flip_done, since that can signal already when the
 * screen goes black, whereas to fully shut down a pipe more register
 * I/O is required.
 *


Re: [PATCH v2 0/6] arm64: perf: Proper cap_user_time* support

2020-07-14 Thread Ahmed S. Darwish
On Wed, Jul 15, 2020 at 10:05:06AM +0800, Leo Yan wrote:
...
>
> In this version, there have two changes comparing to Peter's original
> patch set [1]:
>
...
>
> [1] https://lkml.org/lkml/2020/5/12/481
>

Nitpick: please avoid using https://lkml.org:

  1) It's a non-official external service
  2) The opaque URLs it uses drop the most important info for uniquely
 identifying e-mails: the Message-Id.

Thus if the site one day goes down, and at times it did, the reference
is almost gone forever.

Use "https://lkml.kernel.org/r/". The link becomes:

  https://lkml.kernel.org/r/20200512124058.833263...@infradead.org

thanks,

--
Ahmed S. Darwish
Linutronix GmbH


[PATCH] power: supply: add "Wireless" to power_supply_type and power_supply_type_text

2020-07-14 Thread Jeehong Kim
In android platform(BatteryMonitor.cpp), SysfsStringEnumMap
supplyTypeMap[] is declred for communication with kernel(sysfs)
and there is "Wireless". But, no type for "Wireless" in kernel.
So, we suggest to add "Wireless" to power_supply_type and
power_supply_type_text.
I hope this will not only synchronize the text values with
android platform, but also help other platforms.

Reported-by: Jaeho Song 
Signed-off-by: Dohyung Kim 
Signed-off-by: Jeehong Kim 
---
 drivers/power/supply/power_supply_sysfs.c | 1 +
 include/linux/power_supply.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index bc79560229b5..35582b67eff5 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -56,6 +56,7 @@ static const char * const POWER_SUPPLY_TYPE_TEXT[] = {
[POWER_SUPPLY_TYPE_USB_PD]  = "USB_PD",
[POWER_SUPPLY_TYPE_USB_PD_DRP]  = "USB_PD_DRP",
[POWER_SUPPLY_TYPE_APPLE_BRICK_ID]  = "BrickID",
+   [POWER_SUPPLY_TYPE_WIRELESS]= "Wireless",
 };

 static const char * const POWER_SUPPLY_USB_TYPE_TEXT[] = {
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index ac1345a48ad0..c8bad17a9483 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -182,6 +182,7 @@ enum power_supply_type {
POWER_SUPPLY_TYPE_USB_PD,   /* Power Delivery Port */
POWER_SUPPLY_TYPE_USB_PD_DRP,   /* PD Dual Role Port */
POWER_SUPPLY_TYPE_APPLE_BRICK_ID,   /* Apple Charging Method */
+   POWER_SUPPLY_TYPE_WIRELESS, /* Wireless */
 };

enum power_supply_usb_type {

base-commit: e9919e11e219eaa5e8041b7b1a196839143e9125
--
2.17.1



Re: [PATCH V3 2/3] mfd: Intel Platform Monitoring Technology support

2020-07-14 Thread kernel test robot
Hi "David,

I love your patch! Perhaps something to improve:

[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on pci/next linus/master v5.8-rc5 next-20200714]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/David-E-Box/Intel-Platform-Monitoring-Technology/20200714-142630
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
02946de3802d3bc65bc9f2eb9b8d4969b5a7add8)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/mfd/intel_pmt.c:67:39: warning: unused variable 'pmt_info' 
>> [-Wunused-const-variable]
   static const struct pmt_platform_info pmt_info = {
 ^
   1 warning generated.

vim +/pmt_info +67 drivers/mfd/intel_pmt.c

66  
  > 67  static const struct pmt_platform_info pmt_info = {
68  };
69  

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


.config.gz
Description: application/gzip


[PATCH 2/4] mm/gup: restrict CMA region by using allocation scope API

2020-07-14 Thread js1304
From: Joonsoo Kim 

We have well defined scope API to exclude CMA region.
Use it rather than manipulating gfp_mask manually. With this change,
we can now use __GFP_MOVABLE for gfp_mask and the ZONE_MOVABLE is also
searched by page allocator. For hugetlb, gfp_mask is redefined since
it has a regular allocation mask filter for migration target.

Note that this can be considered as a fix for the commit 9a4e9f3b2d73
("mm: update get_user_pages_longterm to migrate pages allocated from
CMA region"). However, "Fixes" tag isn't added here since it is just
suboptimal but it doesn't cause any problem.

Suggested-by: Michal Hocko 
Signed-off-by: Joonsoo Kim 
---
 include/linux/hugetlb.h |  2 ++
 mm/gup.c| 17 -
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6b9508d..2660b04 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -708,6 +708,8 @@ static inline gfp_t htlb_modify_alloc_mask(struct hstate 
*h, gfp_t gfp_mask)
/* Some callers might want to enfoce node */
modified_mask |= (gfp_mask & __GFP_THISNODE);
 
+   modified_mask |= (gfp_mask & __GFP_NOWARN);
+
return modified_mask;
 }
 
diff --git a/mm/gup.c b/mm/gup.c
index 5daadae..bbd36a1 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1619,10 +1619,12 @@ static struct page *new_non_cma_page(struct page *page, 
unsigned long private)
 * Trying to allocate a page for migration. Ignore allocation
 * failure warnings. We don't force __GFP_THISNODE here because
 * this node here is the node where we have CMA reservation and
-* in some case these nodes will have really less non movable
+* in some case these nodes will have really less non CMA
 * allocation memory.
+*
+* Note that CMA region is prohibited by allocation scope.
 */
-   gfp_t gfp_mask = GFP_USER | __GFP_NOWARN;
+   gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_NOWARN;
 
if (PageHighMem(page))
gfp_mask |= __GFP_HIGHMEM;
@@ -1630,6 +1632,8 @@ static struct page *new_non_cma_page(struct page *page, 
unsigned long private)
 #ifdef CONFIG_HUGETLB_PAGE
if (PageHuge(page)) {
struct hstate *h = page_hstate(page);
+
+   gfp_mask = htlb_modify_alloc_mask(h, gfp_mask);
/*
 * We don't want to dequeue from the pool because pool pages 
will
 * mostly be from the CMA region.
@@ -1644,11 +1648,6 @@ static struct page *new_non_cma_page(struct page *page, 
unsigned long private)
 */
gfp_t thp_gfpmask = GFP_TRANSHUGE | __GFP_NOWARN;
 
-   /*
-* Remove the movable mask so that we don't allocate from
-* CMA area again.
-*/
-   thp_gfpmask &= ~__GFP_MOVABLE;
thp = __alloc_pages_node(nid, thp_gfpmask, HPAGE_PMD_ORDER);
if (!thp)
return NULL;
@@ -1794,7 +1793,6 @@ static long __gup_longterm_locked(struct task_struct *tsk,
 vmas_tmp, NULL, gup_flags);
 
if (gup_flags & FOLL_LONGTERM) {
-   memalloc_nocma_restore(flags);
if (rc < 0)
goto out;
 
@@ -1807,9 +1805,10 @@ static long __gup_longterm_locked(struct task_struct 
*tsk,
 
rc = check_and_migrate_cma_pages(tsk, mm, start, rc, pages,
 vmas_tmp, gup_flags);
+out:
+   memalloc_nocma_restore(flags);
}
 
-out:
if (vmas_tmp != vmas)
kfree(vmas_tmp);
return rc;
-- 
2.7.4



[PATCH 3/4] mm/hugetlb: make hugetlb migration callback CMA aware

2020-07-14 Thread js1304
From: Joonsoo Kim 

new_non_cma_page() in gup.c requires to allocate the new page that is not
on the CMA area. new_non_cma_page() implements it by using allocation
scope APIs.

However, there is a work-around for hugetlb. Normal hugetlb page
allocation API for migration is alloc_huge_page_nodemask(). It consists
of two steps. First is dequeing from the pool. Second is, if there is no
available page on the queue, allocating by using the page allocator.

new_non_cma_page() can't use this API since first step (deque) isn't
aware of scope API to exclude CMA area. So, new_non_cma_page() exports
hugetlb internal function for the second step, alloc_migrate_huge_page(),
to global scope and uses it directly. This is suboptimal since hugetlb
pages on the queue cannot be utilized.

This patch tries to fix this situation by making the deque function on
hugetlb CMA aware. In the deque function, CMA memory is skipped if
PF_MEMALLOC_NOCMA flag is found.

Acked-by: Mike Kravetz 
Signed-off-by: Joonsoo Kim 
---
 include/linux/hugetlb.h |  2 --
 mm/gup.c|  6 +-
 mm/hugetlb.c| 11 +--
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 2660b04..fb2b5aa 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -509,8 +509,6 @@ struct page *alloc_huge_page_nodemask(struct hstate *h, int 
preferred_nid,
nodemask_t *nmask, gfp_t gfp_mask);
 struct page *alloc_huge_page_vma(struct hstate *h, struct vm_area_struct *vma,
unsigned long address);
-struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask,
-int nid, nodemask_t *nmask);
 int huge_add_to_page_cache(struct page *page, struct address_space *mapping,
pgoff_t idx);
 
diff --git a/mm/gup.c b/mm/gup.c
index bbd36a1..4ba822a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1634,11 +1634,7 @@ static struct page *new_non_cma_page(struct page *page, 
unsigned long private)
struct hstate *h = page_hstate(page);
 
gfp_mask = htlb_modify_alloc_mask(h, gfp_mask);
-   /*
-* We don't want to dequeue from the pool because pool pages 
will
-* mostly be from the CMA region.
-*/
-   return alloc_migrate_huge_page(h, gfp_mask, nid, NULL);
+   return alloc_huge_page_nodemask(h, nid, NULL, gfp_mask);
}
 #endif
if (PageTransHuge(page)) {
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3245aa0..514e29c 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1036,10 +1037,16 @@ static void enqueue_huge_page(struct hstate *h, struct 
page *page)
 static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
 {
struct page *page;
+   bool nocma = !!(READ_ONCE(current->flags) & PF_MEMALLOC_NOCMA);
+
+   list_for_each_entry(page, >hugepage_freelists[nid], lru) {
+   if (nocma && is_migrate_cma_page(page))
+   continue;
 
-   list_for_each_entry(page, >hugepage_freelists[nid], lru)
if (!PageHWPoison(page))
break;
+   }
+
/*
 * if 'non-isolated free hugepage' not found on the list,
 * the allocation fails.
@@ -1928,7 +1935,7 @@ static struct page *alloc_surplus_huge_page(struct hstate 
*h, gfp_t gfp_mask,
return page;
 }
 
-struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask,
+static struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask,
 int nid, nodemask_t *nmask)
 {
struct page *page;
-- 
2.7.4



[PATCH 4/4] mm/gup: use a standard migration target allocation callback

2020-07-14 Thread js1304
From: Joonsoo Kim 

There is a well-defined migration target allocation callback. Use it.

Acked-by: Vlastimil Babka 
Signed-off-by: Joonsoo Kim 
---
 mm/gup.c | 54 ++
 1 file changed, 6 insertions(+), 48 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 4ba822a..628ca4c 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1608,52 +1608,6 @@ static bool check_dax_vmas(struct vm_area_struct **vmas, 
long nr_pages)
 }
 
 #ifdef CONFIG_CMA
-static struct page *new_non_cma_page(struct page *page, unsigned long private)
-{
-   /*
-* We want to make sure we allocate the new page from the same node
-* as the source page.
-*/
-   int nid = page_to_nid(page);
-   /*
-* Trying to allocate a page for migration. Ignore allocation
-* failure warnings. We don't force __GFP_THISNODE here because
-* this node here is the node where we have CMA reservation and
-* in some case these nodes will have really less non CMA
-* allocation memory.
-*
-* Note that CMA region is prohibited by allocation scope.
-*/
-   gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_NOWARN;
-
-   if (PageHighMem(page))
-   gfp_mask |= __GFP_HIGHMEM;
-
-#ifdef CONFIG_HUGETLB_PAGE
-   if (PageHuge(page)) {
-   struct hstate *h = page_hstate(page);
-
-   gfp_mask = htlb_modify_alloc_mask(h, gfp_mask);
-   return alloc_huge_page_nodemask(h, nid, NULL, gfp_mask);
-   }
-#endif
-   if (PageTransHuge(page)) {
-   struct page *thp;
-   /*
-* ignore allocation failure warnings
-*/
-   gfp_t thp_gfpmask = GFP_TRANSHUGE | __GFP_NOWARN;
-
-   thp = __alloc_pages_node(nid, thp_gfpmask, HPAGE_PMD_ORDER);
-   if (!thp)
-   return NULL;
-   prep_transhuge_page(thp);
-   return thp;
-   }
-
-   return __alloc_pages_node(nid, gfp_mask, 0);
-}
-
 static long check_and_migrate_cma_pages(struct task_struct *tsk,
struct mm_struct *mm,
unsigned long start,
@@ -1668,6 +1622,10 @@ static long check_and_migrate_cma_pages(struct 
task_struct *tsk,
bool migrate_allow = true;
LIST_HEAD(cma_page_list);
long ret = nr_pages;
+   struct migration_target_control mtc = {
+   .nid = NUMA_NO_NODE,
+   .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_NOWARN,
+   };
 
 check_again:
for (i = 0; i < nr_pages;) {
@@ -1713,8 +1671,8 @@ static long check_and_migrate_cma_pages(struct 
task_struct *tsk,
for (i = 0; i < nr_pages; i++)
put_page(pages[i]);
 
-   if (migrate_pages(_page_list, new_non_cma_page,
- NULL, 0, MIGRATE_SYNC, MR_CONTIG_RANGE)) {
+   if (migrate_pages(_page_list, alloc_migration_target, NULL,
+   (unsigned long), MIGRATE_SYNC, MR_CONTIG_RANGE)) {
/*
 * some of the pages failed migration. Do get_user_pages
 * without migration.
-- 
2.7.4



[PATCH 1/4] mm/page_alloc: fix non cma alloc context

2020-07-14 Thread js1304
From: Joonsoo Kim 

Currently, preventing cma area in page allocation is implemented by using
current_gfp_context(). However, there are two problems of this
implementation.

First, this doesn't work for allocation fastpath. In the fastpath,
original gfp_mask is used since current_gfp_context() is introduced in
order to control reclaim and it is on slowpath.
Second, clearing __GFP_MOVABLE has a side effect to exclude the memory
on the ZONE_MOVABLE for allocation target.

To fix these problems, this patch changes the implementation to exclude
cma area in page allocation. Main point of this change is using the
alloc_flags. alloc_flags is mainly used to control allocation so it fits
for excluding cma area in allocation.

Fixes: d7fefcc (mm/cma: add PF flag to force non cma alloc)
Cc: 
Signed-off-by: Joonsoo Kim 
---
 include/linux/sched/mm.h |  4 
 mm/page_alloc.c  | 27 +++
 2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 44ad5b7..a73847a 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -191,10 +191,6 @@ static inline gfp_t current_gfp_context(gfp_t flags)
flags &= ~(__GFP_IO | __GFP_FS);
else if (pflags & PF_MEMALLOC_NOFS)
flags &= ~__GFP_FS;
-#ifdef CONFIG_CMA
-   if (pflags & PF_MEMALLOC_NOCMA)
-   flags &= ~__GFP_MOVABLE;
-#endif
}
return flags;
 }
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6416d08..cd53894 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2791,7 +2791,7 @@ __rmqueue(struct zone *zone, unsigned int order, int 
migratetype,
 * allocating from CMA when over half of the zone's free memory
 * is in the CMA area.
 */
-   if (migratetype == MIGRATE_MOVABLE &&
+   if (alloc_flags & ALLOC_CMA &&
zone_page_state(zone, NR_FREE_CMA_PAGES) >
zone_page_state(zone, NR_FREE_PAGES) / 2) {
page = __rmqueue_cma_fallback(zone, order);
@@ -2802,7 +2802,7 @@ __rmqueue(struct zone *zone, unsigned int order, int 
migratetype,
 retry:
page = __rmqueue_smallest(zone, order, migratetype);
if (unlikely(!page)) {
-   if (migratetype == MIGRATE_MOVABLE)
+   if (alloc_flags & ALLOC_CMA)
page = __rmqueue_cma_fallback(zone, order);
 
if (!page && __rmqueue_fallback(zone, order, migratetype,
@@ -3502,11 +3502,9 @@ static inline long __zone_watermark_unusable_free(struct 
zone *z,
if (likely(!alloc_harder))
unusable_free += z->nr_reserved_highatomic;
 
-#ifdef CONFIG_CMA
/* If allocation can't use CMA areas don't use free CMA pages */
-   if (!(alloc_flags & ALLOC_CMA))
+   if (IS_ENABLED(CONFIG_CMA) && !(alloc_flags & ALLOC_CMA))
unusable_free += zone_page_state(z, NR_FREE_CMA_PAGES);
-#endif
 
return unusable_free;
 }
@@ -3693,6 +3691,16 @@ alloc_flags_nofragment(struct zone *zone, gfp_t gfp_mask)
return alloc_flags;
 }
 
+static inline void current_alloc_flags(gfp_t gfp_mask,
+   unsigned int *alloc_flags)
+{
+   unsigned int pflags = READ_ONCE(current->flags);
+
+   if (!(pflags & PF_MEMALLOC_NOCMA) &&
+   gfp_migratetype(gfp_mask) == MIGRATE_MOVABLE)
+   *alloc_flags |= ALLOC_CMA;
+}
+
 /*
  * get_page_from_freelist goes through the zonelist trying to allocate
  * a page.
@@ -3706,6 +3714,8 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int 
order, int alloc_flags,
struct pglist_data *last_pgdat_dirty_limit = NULL;
bool no_fallback;
 
+   current_alloc_flags(gfp_mask, _flags);
+
 retry:
/*
 * Scan zonelist, looking for a zone with enough free.
@@ -4339,10 +4349,6 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
} else if (unlikely(rt_task(current)) && !in_interrupt())
alloc_flags |= ALLOC_HARDER;
 
-#ifdef CONFIG_CMA
-   if (gfp_migratetype(gfp_mask) == MIGRATE_MOVABLE)
-   alloc_flags |= ALLOC_CMA;
-#endif
return alloc_flags;
 }
 
@@ -4808,9 +4814,6 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, 
unsigned int order,
if (should_fail_alloc_page(gfp_mask, order))
return false;
 
-   if (IS_ENABLED(CONFIG_CMA) && ac->migratetype == MIGRATE_MOVABLE)
-   *alloc_flags |= ALLOC_CMA;
-
return true;
 }
 
-- 
2.7.4



Re: [PATCH V1 0/5] riscv: Add k/uprobe supported

2020-07-14 Thread Guo Ren
Hi Palmer,

On Wed, Jul 15, 2020 at 2:43 AM Palmer Dabbelt  wrote:
>
> On Sat, 04 Jul 2020 07:55:28 PDT (-0700), guo...@kernel.org wrote:
> > Hi Pekka,
> >
> > On Sat, Jul 4, 2020 at 2:40 PM Pekka Enberg  wrote:
> >>
> >> On Sat, Jul 4, 2020 at 6:34 AM  wrote:
> >> > The patchset includes kprobe/uprobe support and some related fixups.
> >>
> >> Nice!
> >>
> >> On Sat, Jul 4, 2020 at 6:34 AM  wrote:
> >> > There is no single step exception in riscv ISA, so utilize ebreak to
> >> > simulate. Some pc related instructions couldn't be executed out of line
> >> > and some system/fence instructions couldn't be a trace site at all.
> >> > So we give out a reject list and simulate list in decode-insn.c.
> >>
> >> Can you elaborate on what you mean by this? Why would you need a
> >> single-step facility for kprobes? Is it for executing the instruction
> >> that was replaced with a probe breakpoint?
> >
> > It's the single-step exception, not single-step facility!
> >
> > Other arches use hardware single-step exception for k/uprobe,  eg:
> >  - powerpc: regs->msr |= MSR_SINGLESTEP
> >  - arm/arm64: PSTATE.D for enabling software step exceptions
> >  - s390: Set PER control regs, turns on single step for the given address
> >  - x86: regs->flags |= X86_EFLAGS_TF
> >  - csky: of course use hw single step :)
> >
> > Yes, All the above arches use a hardware single-step exception
> > mechanism to execute the instruction that was replaced with a probe
> > breakpoint.
>
> I guess we could handle fences by just IPIing over there and executing the
> fence?  Probably not worth the effort, though, as if you have an issue that's
> showing up close enough to a fence that you can't just probe somewhere nearby
> then you're probably going to disrupt things too much to learn anything.
All fence instructions are rejected to probe in the current patchset.
ref arch/riscv/kernel/probes/decode-insn.c:
/*
 * Reject instructions list:
 */
RISCV_INSN_REJECTED(system, insn);
RISCV_INSN_REJECTED(fence,  insn);

> I'd
> assume that AMOs are also too much of a headache to emulate, as moving them to
> a different hart would allow for different orderings that may break things.
All AMO instructions could be single-step emulated.

>
> I suppose the tricker issue is that inserting a probe in the middle of a LR/SC
> sequence will result in a loss of forward progress (or maybe even incorrect
> behavior, if you mess up a pairing), as there are fairly heavyweight
> restrictions on what you're allowed to do inside there.  I don't see any
> mechanism for handling this, maybe we need to build up tables of restricted
> regions?  All the LR/SC sequences should be hidden behind macros already, so 
> it
> shouldn't be that hard to figure it out.
Yes, the probe between LR/SC will cause dead loop risk and arm64 just
prevent exclusive instructions to probe without the middle detecting.
The macros wrapper idea seems good, but I prefer to leave it to user caring.

>
> I only gave the code a quick look, but I don't see any references to LR/SC or
> AMO so if you are handling these I guess we at least need a comment :)
Yes, I let all AMO & LR/SC could be executed out of line with a
single-step style.
I'll add a comment about LR/SC wrapper macros' idea which you mentioned.

>
> >
> >>
> >> Also, the "Debug Specification" [1] specifies a single-step facility
> >> for RISC-V -- why is that not useful for implementing kprobes?
> >>
> >> 1. https://riscv.org/specifications/debug-specification/
> > We need single-step exception not single-step by jtag, so above spec
> > is not related to the patchset.
> >
> > See riscv-Privileged spec:
> >
> > Interrupt Exception Code-Description
> > 1 0 Reserved
> > 1 1 Supervisor software interrupt
> > 1 2–4 Reserved
> > 1 5 Supervisor timer interrupt
> > 1 6–8 Reserved
> > 1 9 Supervisor external interrupt
> > 1 10–15 Reserved
> > 1 ≥16 Available for platform use
> > 0 0 Instruction address misaligned
> > 0 1 Instruction access fault
> > 0 2 Illegal instruction
> > 0 3 Breakpoint
> > 0 4 Load address misaligned
> > 0 5 Load access fault
> > 0 6 Store/AMO address misaligned
> > 0 7 Store/AMO access fault
> > 0 8 Environment call from U-mode
> > 0 9 Environment call from S-mode
> > 0 10–11 Reserved
> > 0 12 Instruction page fault
> > 0 13 Load page fault
> > 0 14 Reserved
> > 0 15 Store/AMO page fault
> > 0 16–23 Reserved
> > 0 24–31 Available for custom use
> > 0 32–47 Reserved
> > 0 48–63 Available for custom use
> > 0 ≥64 Reserved
> >
> > No single step!
> >
> > So I insert a "ebreak" instruction behind the target single-step
> > instruction to simulate the same mechanism.
>
> Single step is part of the debug spec.  That mostly discusses JTAG debugging,
> but there's also some stuff in there related to in-band debugging (at least
> watch points and single step, though there may be more).  IIRC you get a
What's the meaning of IIRC?

> breakpoint exception and then chase 

[PATCH 2/4] usb: linux/usb/gadget.h: fix duplicated word in comment

2020-07-14 Thread Randy Dunlap
Change the doubled word "in" to "be in" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
---
 include/linux/usb/gadget.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/usb/gadget.h
+++ linux-next-20200714/include/linux/usb/gadget.h
@@ -731,7 +731,7 @@ int usb_gadget_probe_driver(struct usb_g
  * it will first disconnect().  The driver is also requested
  * to unbind() and clean up any device state, before this procedure
  * finally returns.  It's expected that the unbind() functions
- * will in in exit sections, so may not be linked in some kernels.
+ * will be in exit sections, so may not be linked in some kernels.
  */
 int usb_gadget_unregister_driver(struct usb_gadget_driver *driver);
 


[PATCH 1/4] usb: linux/usb.h: drop duplicated word in comment

2020-07-14 Thread Randy Dunlap
Drop the doubled word "the" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
---
 include/linux/usb.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/usb.h
+++ linux-next-20200714/include/linux/usb.h
@@ -341,7 +341,7 @@ struct usb_interface_cache {
  * @interface: array of pointers to usb_interface structures, one for each
  * interface in the configuration.  The number of interfaces is stored
  * in desc.bNumInterfaces.  These pointers are valid only while the
- * the configuration is active.
+ * configuration is active.
  * @intf_cache: array of pointers to usb_interface_cache structures, one
  * for each interface in the configuration.  These structures exist
  * for the entire life of the device.


[PATCH 3/4] usb: linux/usb/pd_vdo.h: drop duplicated word in comment

2020-07-14 Thread Randy Dunlap
Drop the doubled word "all" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
---
 include/linux/usb/pd_vdo.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/usb/pd_vdo.h
+++ linux-next-20200714/include/linux/usb/pd_vdo.h
@@ -249,7 +249,7 @@
  * SVDM Discover SVIDs request -> response
  *
  * Request is properly formatted VDM Header with discover SVIDs command.
- * Response is a set of SVIDs of all all supported SVIDs with all zero's to
+ * Response is a set of SVIDs of all supported SVIDs with all zero's to
  * mark the end of SVIDs.  If more than 12 SVIDs are supported command SHOULD 
be
  * repeated.
  */


[PATCH 4/4] usb: linux/usb/serial.h: drop duplicated word in comment

2020-07-14 Thread Randy Dunlap
Drop the doubled word "set" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
---
 include/linux/usb/serial.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/usb/serial.h
+++ linux-next-20200714/include/linux/usb/serial.h
@@ -212,7 +212,7 @@ struct usb_serial_endpoints {
  * Return 0 to continue on with the initialization sequence.  Anything
  * else will abort it.
  * @attach: pointer to the driver's attach function.
- * This will be called when the struct usb_serial structure is fully set
+ * This will be called when the struct usb_serial structure is fully
  * set up.  Do any local initialization of the device, or any private
  * memory structure allocation at this point in time.
  * @disconnect: pointer to the driver's disconnect function.  This will be


Re: [PATCH 7/9] soundwire: intel/cadence: merge Soundwire interrupt handlers/threads

2020-07-14 Thread Vinod Koul
On 02-07-20, 10:01, Pierre-Louis Bossart wrote:
 
> > > Sounds good. Now that you are already in irq thread, does it make sense
> > > to spawn a worker thread for this and handle it there? Why not do in the
> > > irq thread itself. Using a thread kind of defeats the whole point behind
> > > concept of irq threads
> > 
> > Not sure If you are talking about cdns_update_slave_status_work().
> > The reason we need to spawn a worker thread in sdw_cdns_irq() is
> > that we will do sdw transfer which will generate an interrupt when
> > a slave interrupt is triggered. And the handler will not be invoked if the
> > previous handler is not return yet.
> > Please see the scenario below for better explanation.
> > 1. Slave interrupt arrives
> > 2.1 Try to read Slave register and waiting for the transfer response
> > 2.2 Get the transfer response interrupt and finish the sdw transfer.
> > 3. Finish the Slave interrupt handling.
> > 
> > Interrupts are triggered in step 1 and 2.2, but step 2.2's handler will not 
> > be
> > invoked if step 1's handler is not return yet.
> > What we do is to spawn a worker thread to do step 2 and return from step 1.
> > So the handler can be invoked when the transfer response interrupt arrives.
> 
> To build on Bard's correct answer, the irq thread only takes care of
> 'immediate' actions, such as command completion, parity or bus clash errors.
> The rest of the work can be split in
> a) changes to device state, usually for attachment and enumeration. This is
> rather slow and will entail regmap syncs.
> b) device interrupts - typically only for jack detection which is also
> rather slow.
> 
> Since this irq thread function is actually part of the entire HDaudio
> controller interrupt handling, we have to defer the work for cases a) and b)
> and re-enable the HDaudio interrupts at the end of the irq thread function -
> see the code I shared earlier.
> 
> In addition, both a) and b) will result  in transactions over the bus, which
> will trigger interrupts to signal the command completions. In other words,
> because of the asynchronous nature of the transactions, we need a two-level
> implementation. If you look at the previous solution it was the same, the
> commands were issued in the irq thread and the command completion was
> handled in the handler, since we had to make the handler minimal with a
> global GIE interrupt disable we kept the same hierarchy to deal with
> commands but move it up one level.
> 
> You could argue that maybe a worker thread is not optimal and could be
> replaced by something better/faster. Since the jack detection is typically
> handled with a worker thread in all ASoC codec drivers, we didn't feel the
> need to optimize further. We did not see any performance impact with this
> change.
> 
> Does this answer to your concern?

The point is that we are already in irq_thread which is designed to
handle any bottom half processing and can be given priority, spawning of
worker threads for another bottom half seems unnecessary to me and would
increase the latency for you.

I would have handled everything in irq_thread and returned, after all we
are in bottom half :)

Is there a reason for worker thread here, if so it is not clear to me
atm.

Thanks
-- 
~Vinod


Re: [PATCH 8/9] soundwire: intel: add wake interrupt support

2020-07-14 Thread Vinod Koul
On 01-07-20, 10:25, Pierre-Louis Bossart wrote:
> 
> > > > > +  * wake up master and slave so that slave can notify master
> > > > > +  * the wakeen event and let codec driver check codec status
> > > > > +  */
> > > > > + list_for_each_entry(slave, >slaves, node) {
> > > > > + /*
> > > > > +  * discard devices that are defined in ACPI tables but
> > > > > +  * not physically present and devices that cannot
> > > > > +  * generate wakes
> > > > > +  */
> > > > > + if (slave->dev_num_sticky && slave->prop.wake_capable)
> > > > > + pm_request_resume(>dev);
> > > > 
> > > > Hmmm, shouldn't slave do this? would it not make sense to notify the
> > > > slave thru callback and then slave decides to resume or not..?
> > > 
> > > In this mode, the bus is clock-stop mode, and events are detected with 
> > > level
> > > detector tied to PCI events. The master and slave devices are all in
> > > pm_runtime suspended states. The codec cannot make any decisions on its 
> > > own
> > > since the bus is stopped, it needs to first resume, which assumes that the
> > > master resumes first and the enumeration re-done before it can access any 
> > > of
> > > its registers.
> > > 
> > > By looping through the list of devices that can generate events, you 
> > > end-up
> > > first forcing the master to resume, and then each slave resumes and can
> > > check who generated the event and what happened while suspended. if the
> > > codec didn't generate the event it will go back to suspended mode after 
> > > the
> > > usual timeout.
> > > 
> > > We can add a callback but that callback would only be used for Intel
> > > solutions, but internally it would only do a pm_request_resume() since the
> > > codec cannot make any decisions before first resuming. In other words, it
> > > would be an Intel-specific callback that is implemented using generic 
> > > resume
> > > operations. It's probably better to keep this in Intel-specific code, no?
> > 
> > I do not like the idea that a device would be woken up, that kind of
> > defeats the whole idea behind the runtime pm. Waking up a device to
> > check the events is a generic sdw concept, I don't see that as Intel
> > specific one.
> 
> In this case, this in an Intel-specific mode that's beyond what MIPI
> defined. This is not the traditional in-band SoundWire wake defined in the
> SoundWire specification. The bus is completely down, the master IP is
> powered-off and all context lost. There is still the ability for a Slave
> device to throw a wake as defined by MIPI in clock-stop-mode1, but this is
> handled with a separate level detector and the wake detection is handled by
> the PCI subsystem. On a wake, the master IP needs to be powered-up, the
> entire bus needs to be restarted and the Slave devices re-enumerated.

Right and I would expect that Slave device would do runtime_get_sync()
first thing in the callback. That would ensure that the Master is
powered up, Slave is powered up, all enumeration is complete. This is
more standard way to deal with this, we expect devices to be so we
low powered or off so cannot do read/write unless we resume.

> We trigger that sequence with a loop that calls pm_request_resume() for all
> Slave devices that are present and exposed in their properties that they are
> wake-capable. As you rightly said in your comments, this will result a nice
> wake-up handled by the pm_runtime framework in the right sequence (DSP
> first, then SoundWire master then Slave devices).
> 
> You will see in follow-up patches that the master IP can be configured in
> different clock stop modes, depending on the needs (power/latency compromise
> typically). When the more traditional SoundWire wake is used, we do not use
> this sequence at all.

The point which is not clear to me if why do we need a specific
sequence. Above sequence should work for you, if not I would like to
understand why.

> > I would like to see a generic callback for the devices and let devices
> > do the resume part, that is standard operating principle when we deal
> > with suspended devices. If the device thinks they need to resume, they
> > will do the runtime resume, check the status and sleep if not
> > applicable. Since we have set the parents correctly, any resume
> > operation for slaves would wake master up as well...
> > 
> > I do not see a need for intel driver to resume slave devices here, or
> > did I miss something?
> 
> Yes, the part "If the device thinks they need to resume" is not quite right.
> The Slave device cannot access its registers before fully resuming, which in
> this case means a re-enumeration, so cannot "think" or make a decision on
> its own. That's the reason why we force them to resume, since it's the first
> step they would need to do anyways, and then if they don't have anything to
> do they go back to idle after a timeout. I invite you to see the
> 

kernel panic: System is deadlocked on memory

2020-07-14 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:d31958b3 Add linux-next specific files for 20200710
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11a2fe1310
kernel config:  https://syzkaller.appspot.com/x/.config?x=3fe4fccb94cbc1a6
dashboard link: https://syzkaller.appspot.com/bug?extid=98be80110b9043885626
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=101ec96710
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14a7700090

The issue was bisected to:

commit e642d9be463d02c735cd99a9a904063324ee03d6
Author: Yafang Shao 
Date:   Fri Jul 10 04:58:08 2020 +

mm, oom: make the calculation of oom badness more accurate

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1432bd7710
final oops: https://syzkaller.appspot.com/x/report.txt?x=1632bd7710
console output: https://syzkaller.appspot.com/x/log.txt?x=1232bd7710

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+98be80110b9043885...@syzkaller.appspotmail.com
Fixes: e642d9be463d ("mm, oom: make the calculation of oom badness more 
accurate")

Out of memory and no killable processes...
Kernel panic - not syncing: System is deadlocked on memory
CPU: 0 PID: 6810 Comm: syz-executor919 Not tainted 
5.8.0-rc4-next-20200710-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 panic+0x2e3/0x75c kernel/panic.c:231
 out_of_memory mm/oom_kill.c:1106 [inline]
 out_of_memory.cold+0xa6/0x182 mm/oom_kill.c:1041
 pagefault_out_of_memory+0x109/0x11c mm/oom_kill.c:1135
 mm_fault_error+0x123/0x380 arch/x86/mm/fault.c:930
 do_user_addr_fault+0x5f8/0xbf0 arch/x86/mm/fault.c:1317
 handle_page_fault arch/x86/mm/fault.c:1351 [inline]
 exc_page_fault+0xab/0x170 arch/x86/mm/fault.c:1404
 asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:544
RIP: 0033:0x40154d
Code: Bad RIP value.
RSP: 002b:7ffddf4649b0 EFLAGS: 00010202
RAX: 0001 RBX:  RCX: fffd
RDX: 0001 RSI: 7ffddf4665e0 RDI: 
RBP: 7ffddf4665e0 R08:  R09: 0001
R10: 0064 R11: 0246 R12: 
R13: 0003 R14:  R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches


[PATCH] staging: comedi: comedi_fops.c: changed type in assignment to unsigned int *

2020-07-14 Thread B K Karthik
fixed a sparse warning by changing the type in
assignment from void [noderef] __user * to unsigned int *
(different address space)

Signed-off-by: B K Karthik 
---
 drivers/staging/comedi/comedi_fops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 3f70e5dfac39..4cc012e231b7 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2956,7 +2956,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
cmd->scan_end_arg = v32.scan_end_arg;
cmd->stop_src = v32.stop_src;
cmd->stop_arg = v32.stop_arg;
-   cmd->chanlist = compat_ptr(v32.chanlist);
+   cmd->chanlist = (unsigned int *) compat_ptr(v32.chanlist);
cmd->chanlist_len = v32.chanlist_len;
cmd->data = compat_ptr(v32.data);
cmd->data_len = v32.data_len;
-- 
2.20.1



signature.asc
Description: PGP signature


Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning

2020-07-14 Thread Sean Christopherson
On Tue, Jul 14, 2020 at 05:39:30AM +, Andersen, John wrote:
> With regards to FSGSBASE, are we open to validating and adding that to the
> DEFAULT set as a part of a separate patchset? This patchset is focused on
> replicating the functionality we already have natively.

Kees added FSGSBASE pinning in commit a13b9d0b97211 ("x86/cpu: Use pinning
mask for CR4 bits needing to be 0"), so I believe it's a done deal already.


Re: [PATCH v2 0/5] soundwire: handle stream at the dailink level

2020-07-14 Thread Vinod Koul
On 01-07-20, 02:43, Bard Liao wrote:
> Currently, stream is handled at the dai level. But we have to handle
> stream at the dailink level in the multi-cpu dailink usage.

Applied, thanks

-- 
~Vinod


Re: [PATCH v4 5/9] KVM: nSVM: introduce nested_svm_load_cr3()/nested_npt_enabled()

2020-07-14 Thread Sean Christopherson
On Tue, Jul 14, 2020 at 01:26:24PM +0200, Vitaly Kuznetsov wrote:
> Sean Christopherson  writes:
> > IMO the addition of nested_npt_enabled() should be a separate patch, and
> > the additoin of @nested_npt should be in patch 7.
> >
> > Hypothetically speaking, if nested_npt_enabled() is inaccurate at the call
> > site in nested_prepare_vmcb_save(), then this patch is technically wrong
> > even though it doesn't introduce a bug.  Given that the call site of
> > nested_svm_load_cr3() is moved in patch 7, I don't see any value in adding
> > the placeholder parameter early.
> >
> 
> I see and I mostly agree, I put it here to avoid the unneeded churn and
> make it easier to review the whole thing: this patch is technically a
> nop so it can be reviewed in "doesn't change anything" mode and patches
> which actually change things are smaller.
> 
> Paolo already said 'queued' here and your comments can't be addressed in
> a follow-up patch but I can certainly do v5 if needed.

Eh, not necessary, I didn't see that the series was in kvm/queue until after
I hit send.  Thanks!


[PATCH 3/8] KVM: x86/mmu: Move "huge page disallowed" calculation into mapping helpers

2020-07-14 Thread Sean Christopherson
Calculate huge_page_disallowed in __direct_map() and FNAME(fetch) in
preparation for reworking the calculation so that it preserves the
requested map level and eventually to avoid flagging a shadow page as
being disallowed for being used as a large/huge page when it couldn't
have been huge in the first place, e.g. because the backing page in the
host is not large.

Pass the error code into the helpers and use it to recalcuate exec and
write_fault instead adding yet more booleans to the parameters.

Opportunistically use huge_page_disallowed instead of lpage_disallowed
to match the nomenclature used within the mapping helpers (though even
they have existing inconsistencies).

No functional change intended.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/mmu.c | 22 --
 arch/x86/kvm/mmu/paging_tmpl.h | 24 ++--
 2 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 9cd3d2a23f8a5..bbd7e8be2b936 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3306,10 +3306,14 @@ static void disallowed_hugepage_adjust(struct 
kvm_shadow_walk_iterator it,
}
 }
 
-static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, int write,
+static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
int map_writable, int max_level, kvm_pfn_t pfn,
-   bool prefault, bool account_disallowed_nx_lpage)
+   bool prefault, bool is_tdp)
 {
+   bool nx_huge_page_workaround_enabled = is_nx_huge_page_enabled();
+   bool write = error_code & PFERR_WRITE_MASK;
+   bool exec = error_code & PFERR_FETCH_MASK;
+   bool huge_page_disallowed = exec && nx_huge_page_workaround_enabled;
struct kvm_shadow_walk_iterator it;
struct kvm_mmu_page *sp;
int level, ret;
@@ -3319,6 +3323,9 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, 
int write,
if (WARN_ON(!VALID_PAGE(vcpu->arch.mmu->root_hpa)))
return RET_PF_RETRY;
 
+   if (huge_page_disallowed)
+   max_level = PG_LEVEL_4K;
+
level = kvm_mmu_hugepage_adjust(vcpu, gfn, max_level, );
 
trace_kvm_mmu_spte_requested(gpa, level, pfn);
@@ -3339,7 +3346,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, 
int write,
  it.level - 1, true, ACC_ALL);
 
link_shadow_page(vcpu, it.sptep, sp);
-   if (account_disallowed_nx_lpage)
+   if (is_tdp && huge_page_disallowed)
account_huge_nx_page(vcpu->kvm, sp);
}
}
@@ -4078,8 +4085,6 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t 
gpa, u32 error_code,
 bool prefault, int max_level, bool is_tdp)
 {
bool write = error_code & PFERR_WRITE_MASK;
-   bool exec = error_code & PFERR_FETCH_MASK;
-   bool lpage_disallowed = exec && is_nx_huge_page_enabled();
bool map_writable;
 
gfn_t gfn = gpa >> PAGE_SHIFT;
@@ -4097,9 +4102,6 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t 
gpa, u32 error_code,
if (r)
return r;
 
-   if (lpage_disallowed)
-   max_level = PG_LEVEL_4K;
-
mmu_seq = vcpu->kvm->mmu_notifier_seq;
smp_rmb();
 
@@ -4116,8 +4118,8 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t 
gpa, u32 error_code,
r = make_mmu_pages_available(vcpu);
if (r)
goto out_unlock;
-   r = __direct_map(vcpu, gpa, write, map_writable, max_level, pfn,
-prefault, is_tdp && lpage_disallowed);
+   r = __direct_map(vcpu, gpa, error_code, map_writable, max_level, pfn,
+prefault, is_tdp);
 
 out_unlock:
spin_unlock(>kvm->mmu_lock);
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 0172a949f6a75..5536b2004dac8 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -625,11 +625,14 @@ static void FNAME(pte_prefetch)(struct kvm_vcpu *vcpu, 
struct guest_walker *gw,
  * emulate this operation, return 1 to indicate this case.
  */
 static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
-struct guest_walker *gw,
-int write_fault, int max_level,
-kvm_pfn_t pfn, bool map_writable, bool prefault,
-bool lpage_disallowed)
+struct guest_walker *gw, u32 error_code,
+int max_level, kvm_pfn_t pfn, bool map_writable,
+bool prefault)
 {
+   bool nx_huge_page_workaround_enabled = is_nx_huge_page_enabled();
+   int write_fault = error_code & PFERR_WRITE_MASK;
+   bool exec = error_code & PFERR_FETCH_MASK;
+   bool huge_page_disallowed 

[PATCH 7/8] KVM: x86/mmu: Hoist ITLB multi-hit workaround check up a level

2020-07-14 Thread Sean Christopherson
Move the "ITLB multi-hit workaround enabled" check into the callers of
disallowed_hugepage_adjust() to make it more obvious that the helper is
specific to the workaround, and to be consistent with the accounting,
i.e. account_huge_nx_page() is called if and only if the workaround is
enabled.

No functional change intended.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/mmu.c | 4 ++--
 arch/x86/kvm/mmu/paging_tmpl.h | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 1b2ef2f61d997..135bdf6ef8ca9 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3300,7 +3300,6 @@ static void disallowed_hugepage_adjust(struct 
kvm_shadow_walk_iterator it,
u64 spte = *it.sptep;
 
if (it.level == level && level > PG_LEVEL_4K &&
-   is_nx_huge_page_enabled() &&
is_shadow_present_pte(spte) &&
!is_large_pte(spte)) {
/*
@@ -3342,7 +3341,8 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, 
u32 error_code,
 * We cannot overwrite existing page tables with an NX
 * large page, as the leaf could be executable.
 */
-   disallowed_hugepage_adjust(it, gfn, , );
+   if (nx_huge_page_workaround_enabled)
+   disallowed_hugepage_adjust(it, gfn, , );
 
base_gfn = gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
if (it.level == level)
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 35867a1a1ee89..db5734d7c80b6 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -694,7 +694,8 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
 * We cannot overwrite existing page tables with an NX
 * large page, as the leaf could be executable.
 */
-   disallowed_hugepage_adjust(it, gw->gfn, , );
+   if (nx_huge_page_workaround_enabled)
+   disallowed_hugepage_adjust(it, gw->gfn, , );
 
base_gfn = gw->gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
if (it.level == level)
-- 
2.26.0



[PATCH 6/8] KVM: x86/mmu: Rename 'hlevel' to 'level' in FNAME(fetch)

2020-07-14 Thread Sean Christopherson
Rename 'hlevel', which presumably stands for 'host level', to simply
'level' in FNAME(fetch).  The variable hasn't tracked the host level for
quite some time.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/paging_tmpl.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 39578a1839ca4..35867a1a1ee89 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -636,7 +636,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
struct kvm_mmu_page *sp = NULL;
struct kvm_shadow_walk_iterator it;
unsigned direct_access, access = gw->pt_access;
-   int top_level, hlevel, req_level, ret;
+   int top_level, level, req_level, ret;
gfn_t base_gfn = gw->gfn;
 
direct_access = gw->pte_access;
@@ -682,8 +682,8 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
link_shadow_page(vcpu, it.sptep, sp);
}
 
-   hlevel = kvm_mmu_hugepage_adjust(vcpu, gw->gfn, max_level, ,
-huge_page_disallowed, _level);
+   level = kvm_mmu_hugepage_adjust(vcpu, gw->gfn, max_level, ,
+   huge_page_disallowed, _level);
 
trace_kvm_mmu_spte_requested(addr, gw->level, pfn);
 
@@ -694,10 +694,10 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
 * We cannot overwrite existing page tables with an NX
 * large page, as the leaf could be executable.
 */
-   disallowed_hugepage_adjust(it, gw->gfn, , );
+   disallowed_hugepage_adjust(it, gw->gfn, , );
 
base_gfn = gw->gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
-   if (it.level == hlevel)
+   if (it.level == level)
break;
 
validate_direct_spte(vcpu, it.sptep, direct_access);
-- 
2.26.0



[PATCH 8/8] KVM: x86/mmu: Track write/user faults using bools

2020-07-14 Thread Sean Christopherson
Use bools to track write and user faults throughout the page fault paths
and down into mmu_set_spte().  The actual usage is purely boolean, but
that's not obvious without digging into all paths as the current code
uses a mix of bools (TDP and try_async_pf) and ints (shadow paging and
mmu_set_spte()).

No true functional change intended (although the pgprintk() will now
print 0/1 instead of 0/PFERR_WRITE_MASK).

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/mmu.c |  4 ++--
 arch/x86/kvm/mmu/paging_tmpl.h | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 135bdf6ef8ca9..5c47af2cc9a19 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3062,7 +3062,7 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
 }
 
 static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
-   unsigned int pte_access, int write_fault, int level,
+   unsigned int pte_access, bool write_fault, int level,
gfn_t gfn, kvm_pfn_t pfn, bool speculative,
bool host_writable)
 {
@@ -3159,7 +3159,7 @@ static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
return -1;
 
for (i = 0; i < ret; i++, gfn++, start++) {
-   mmu_set_spte(vcpu, start, access, 0, sp->role.level, gfn,
+   mmu_set_spte(vcpu, start, access, false, sp->role.level, gfn,
 page_to_pfn(pages[i]), true, true);
put_page(pages[i]);
}
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index db5734d7c80b6..e30e0d9b4613d 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -550,7 +550,7 @@ FNAME(prefetch_gpte)(struct kvm_vcpu *vcpu, struct 
kvm_mmu_page *sp,
 * we call mmu_set_spte() with host_writable = true because
 * pte_prefetch_gfn_to_pfn always gets a writable pfn.
 */
-   mmu_set_spte(vcpu, spte, pte_access, 0, PG_LEVEL_4K, gfn, pfn,
+   mmu_set_spte(vcpu, spte, pte_access, false, PG_LEVEL_4K, gfn, pfn,
 true, true);
 
kvm_release_pfn_clean(pfn);
@@ -630,7 +630,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
 bool prefault)
 {
bool nx_huge_page_workaround_enabled = is_nx_huge_page_enabled();
-   int write_fault = error_code & PFERR_WRITE_MASK;
+   bool write_fault = error_code & PFERR_WRITE_MASK;
bool exec = error_code & PFERR_FETCH_MASK;
bool huge_page_disallowed = exec && nx_huge_page_workaround_enabled;
struct kvm_mmu_page *sp = NULL;
@@ -743,7 +743,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
  */
 static bool
 FNAME(is_self_change_mapping)(struct kvm_vcpu *vcpu,
- struct guest_walker *walker, int user_fault,
+ struct guest_walker *walker, bool user_fault,
  bool *write_fault_to_shadow_pgtable)
 {
int level;
@@ -781,8 +781,8 @@ FNAME(is_self_change_mapping)(struct kvm_vcpu *vcpu,
 static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gpa_t addr, u32 error_code,
 bool prefault)
 {
-   int write_fault = error_code & PFERR_WRITE_MASK;
-   int user_fault = error_code & PFERR_USER_MASK;
+   bool write_fault = error_code & PFERR_WRITE_MASK;
+   bool user_fault = error_code & PFERR_USER_MASK;
struct guest_walker walker;
int r;
kvm_pfn_t pfn;
-- 
2.26.0



[PATCH 4/8] KVM: x86/mmu: Capture requested page level before NX huge page workaround

2020-07-14 Thread Sean Christopherson
Apply the "huge page disallowed" adjustment of the max level only after
capturing the original requested level.  The requested level will be
used in a future patch to skip adding pages to the list of disallowed
huge pages if a huge page wasn't possible anyways, e.g. if the page
isn't mapped as a huge page in the host.

No functional change intended.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/mmu.c | 22 +++---
 arch/x86/kvm/mmu/paging_tmpl.h |  8 +++-
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index bbd7e8be2b936..974c9a89c2454 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3238,7 +3238,8 @@ static int host_pfn_mapping_level(struct kvm_vcpu *vcpu, 
gfn_t gfn,
 }
 
 static int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, gfn_t gfn,
-  int max_level, kvm_pfn_t *pfnp)
+  int max_level, kvm_pfn_t *pfnp,
+  bool huge_page_disallowed, int *req_level)
 {
struct kvm_memory_slot *slot;
struct kvm_lpage_info *linfo;
@@ -3246,6 +3247,8 @@ static int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, 
gfn_t gfn,
kvm_pfn_t mask;
int level;
 
+   *req_level = PG_LEVEL_4K;
+
if (unlikely(max_level == PG_LEVEL_4K))
return PG_LEVEL_4K;
 
@@ -3270,7 +3273,14 @@ static int kvm_mmu_hugepage_adjust(struct kvm_vcpu 
*vcpu, gfn_t gfn,
if (level == PG_LEVEL_4K)
return level;
 
-   level = min(level, max_level);
+   *req_level = level = min(level, max_level);
+
+   /*
+* Enforce the iTLB multihit workaround after capturing the requested
+* level, which will be used to do precise, accurate accounting.
+*/
+   if (huge_page_disallowed)
+   return PG_LEVEL_4K;
 
/*
 * mmu_notifier_retry() was successful and mmu_lock is held, so
@@ -3316,17 +3326,15 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t 
gpa, u32 error_code,
bool huge_page_disallowed = exec && nx_huge_page_workaround_enabled;
struct kvm_shadow_walk_iterator it;
struct kvm_mmu_page *sp;
-   int level, ret;
+   int level, req_level, ret;
gfn_t gfn = gpa >> PAGE_SHIFT;
gfn_t base_gfn = gfn;
 
if (WARN_ON(!VALID_PAGE(vcpu->arch.mmu->root_hpa)))
return RET_PF_RETRY;
 
-   if (huge_page_disallowed)
-   max_level = PG_LEVEL_4K;
-
-   level = kvm_mmu_hugepage_adjust(vcpu, gfn, max_level, );
+   level = kvm_mmu_hugepage_adjust(vcpu, gfn, max_level, ,
+   huge_page_disallowed, _level);
 
trace_kvm_mmu_spte_requested(gpa, level, pfn);
for_each_shadow_entry(vcpu, gpa, it) {
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 5536b2004dac8..b92d936c0900d 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -636,7 +636,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
struct kvm_mmu_page *sp = NULL;
struct kvm_shadow_walk_iterator it;
unsigned direct_access, access = gw->pt_access;
-   int top_level, hlevel, ret;
+   int top_level, hlevel, req_level, ret;
gfn_t base_gfn = gw->gfn;
 
direct_access = gw->pte_access;
@@ -682,10 +682,8 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
link_shadow_page(vcpu, it.sptep, sp);
}
 
-   if (huge_page_disallowed)
-   max_level = PG_LEVEL_4K;
-
-   hlevel = kvm_mmu_hugepage_adjust(vcpu, gw->gfn, max_level, );
+   hlevel = kvm_mmu_hugepage_adjust(vcpu, gw->gfn, max_level, ,
+huge_page_disallowed, _level);
 
trace_kvm_mmu_spte_requested(addr, gw->level, pfn);
 
-- 
2.26.0



[PATCH 1/8] KVM: x86/mmu: Commit zap of remaining invalid pages when recovering lpages

2020-07-14 Thread Sean Christopherson
Call kvm_mmu_commit_zap_page() after exiting the "prepare zap" loop in
kvm_recover_nx_lpages() to finish zapping pages in the unlikely event
that the loop exited due to lpage_disallowed_mmu_pages being empty.
Because the recovery thread drops mmu_lock() when rescheduling, it's
possible that lpage_disallowed_mmu_pages could be emptied by a different
thread without to_zap reaching zero despite to_zap being derived from
the number of disallowed lpages.

Fixes: 1aa9b9572b105 ("kvm: x86: mmu: Recovery of shattered NX large pages")
Cc: Junaid Shahid 
Cc: sta...@vger.kernel.org
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/mmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 77810ce66bdb4..48be51027af64 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -6340,6 +6340,7 @@ static void kvm_recover_nx_lpages(struct kvm *kvm)
cond_resched_lock(>mmu_lock);
}
}
+   kvm_mmu_commit_zap_page(kvm, _list);
 
spin_unlock(>mmu_lock);
srcu_read_unlock(>srcu, rcu_idx);
-- 
2.26.0



[PATCH 2/8] KVM: x86/mmu: Refactor the zap loop for recovering NX lpages

2020-07-14 Thread Sean Christopherson
Refactor the zap loop in kvm_recover_nx_lpages() to be a for loop that
iterates on to_zap and drop the !to_zap check that leads to the in-loop
calling of kvm_mmu_commit_zap_page().  The in-loop commit when to_zap
hits zero is superfluous now that there's an unconditional commit after
the loop to handle the case where lpage_disallowed_mmu_pages is emptied.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/mmu.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 48be51027af64..9cd3d2a23f8a5 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -6321,7 +6321,10 @@ static void kvm_recover_nx_lpages(struct kvm *kvm)
 
ratio = READ_ONCE(nx_huge_pages_recovery_ratio);
to_zap = ratio ? DIV_ROUND_UP(kvm->stat.nx_lpage_splits, ratio) : 0;
-   while (to_zap && !list_empty(>arch.lpage_disallowed_mmu_pages)) {
+   for ( ; to_zap; --to_zap) {
+   if (list_empty(>arch.lpage_disallowed_mmu_pages))
+   break;
+
/*
 * We use a separate list instead of just using active_mmu_pages
 * because the number of lpage_disallowed pages is expected to
@@ -6334,10 +6337,9 @@ static void kvm_recover_nx_lpages(struct kvm *kvm)
kvm_mmu_prepare_zap_page(kvm, sp, _list);
WARN_ON_ONCE(sp->lpage_disallowed);
 
-   if (!--to_zap || need_resched() || 
spin_needbreak(>mmu_lock)) {
+   if (need_resched() || spin_needbreak(>mmu_lock)) {
kvm_mmu_commit_zap_page(kvm, _list);
-   if (to_zap)
-   cond_resched_lock(>mmu_lock);
+   cond_resched_lock(>mmu_lock);
}
}
kvm_mmu_commit_zap_page(kvm, _list);
-- 
2.26.0



Re: [PATCH -v2.1] x86/msr: Filter MSR writes

2020-07-14 Thread Borislav Petkov
On Tue, Jul 14, 2020 at 11:52:47AM -0700, Srinivas Pandruvada wrote:
> > As to the power issue, lemme CC some Intel folks I found in
> > MAINTAINERS.
> > 
> > Intel folks, pls check the link above and upthread: Why TF do people
> > need to use some luserspace daemon which pokes at MSRs which the
> > kernel
> > writes to too, in order to bypass some apparently too conservative
> > throttling, AFAIU?
> For issues related to thermal or power, we don't expect to poke MSRs
> from user space by any daemon. We have sysfs interfaces for the
> required controls. This is also true for controls via MMIO space.
> Anytime if it is safe to add, we are adding controls via sysfs.
> 
> The tool in question from the link (not from Intel), when developed may
> not have TCC or RAPL-MMIO controls via sysfs. We have sysfs interfaces
> for a while. They can send email to me to justify other controls if
> any.

CCed. (I think I got the right email from the repo).

Francesco, see the whole thread starting here:

https://lkml.kernel.org/r/20200714121955.ga2...@chrisdown.name

> > And why does this work on windoze reportedly?
> This is not related to MSR or MMIO. This is related to some ACPI
> tables. In Linux, thermald will adjust these knobs like Windows. It was
> missing some ACPI details, which Matthew Garrett submitted patches to
> kernel and getting merged with 5.8 series.

Good.

Which means that that throttled tool could do the same thing thermald is
doing so that they're all on the same page. Or simply not do anything
and tell users to install thermald instead.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


[PATCH 0/8] KVM: x86/mmu: ITLB multi-hit workaround fixes

2020-07-14 Thread Sean Christopherson
Patch 1 is a minor fix for a very theoretical bug where KVM could skip
the final "commit zap" when recovering shadow pages for the NX huge
page mitigation.

Patch 2 is cleanup that's made possible by patch 1.

Patches 3-5 are the main course and fix bugs in the NX huge page
accounting where shadow pages are incorrectly added to the list of
disallowed huge pages.  KVM doesn't actually check to see if the page
could actually have been a large page when adding to the disallowed list.
This result in what are effectively spurious zaps.  The biggest issue is
likely with shadow pages in the upper levels, i.e. levels 3 and 4, as they
are either unlikely to be huge (1gb) or flat out can't be huge (512tb).
And because of the way KVM zaps, the upper levels will be zapped first,
i.e. KVM is likely zapping and rebuilding a decent number of its shadow
pages for zero benefit.

Ideally, patches 3-5 would be a single patch to ease backporting.  In the
end, I decided the change is probably not suitable for stable as at worst
it creates an infrequent performance spike (assuming the admin isn't going
crazy with the recovery frequency), and it's far from straightforward or
risk free.  Cramming everything into a single patch was a mess.

Patches 6-8 are cleanups in related code.  The 'hlevel' name in particular
has been on my todo list for a while.

Sean Christopherson (8):
  KVM: x86/mmu: Commit zap of remaining invalid pages when recovering
lpages
  KVM: x86/mmu: Refactor the zap loop for recovering NX lpages
  KVM: x86/mmu: Move "huge page disallowed" calculation into mapping
helpers
  KVM: x86/mmu: Capture requested page level before NX huge page
workaround
  KVM: x86/mmu: Account NX huge page disallowed iff huge page was
requested
  KVM: x86/mmu: Rename 'hlevel' to 'level' in FNAME(fetch)
  KVM: x86/mmu: Hoist ITLB multi-hit workaround check up a level
  KVM: x86/mmu: Track write/user faults using bools

 arch/x86/kvm/mmu/mmu.c | 58 +-
 arch/x86/kvm/mmu/paging_tmpl.h | 39 ---
 2 files changed, 57 insertions(+), 40 deletions(-)

-- 
2.26.0



[PATCH 5/8] KVM: x86/mmu: Account NX huge page disallowed iff huge page was requested

2020-07-14 Thread Sean Christopherson
Condition the accounting of a disallowed huge NX page on the original
requested level of the page being greater than the current iterator
level.  This does two things: accounts the page if and only if a huge
page was actually disallowed, and accounts the shadow page if and only
if it was the level at which the huge page was disallowed.  For the
latter case, the previous logic would account all shadow pages used to
create the translation for the forced small page, e.g. even PML4, which
can't be a huge page on current hardware, would be accounted as having
been a disallowed huge page when using 5-level EPT.

The overzealous accounting is purely a performance issue, i.e. the
recovery thread will spuriously zap shadow pages, but otherwise the bad
behavior is harmless.

Cc: Junaid Shahid 
Fixes: b8e8c8303ff28 ("kvm: mmu: ITLB_MULTIHIT mitigation")
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/mmu/mmu.c | 3 ++-
 arch/x86/kvm/mmu/paging_tmpl.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 974c9a89c2454..1b2ef2f61d997 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3354,7 +3354,8 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, 
u32 error_code,
  it.level - 1, true, ACC_ALL);
 
link_shadow_page(vcpu, it.sptep, sp);
-   if (is_tdp && huge_page_disallowed)
+   if (is_tdp && huge_page_disallowed &&
+   req_level >= it.level)
account_huge_nx_page(vcpu->kvm, sp);
}
}
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index b92d936c0900d..39578a1839ca4 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -708,7 +708,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
sp = kvm_mmu_get_page(vcpu, base_gfn, addr,
  it.level - 1, true, 
direct_access);
link_shadow_page(vcpu, it.sptep, sp);
-   if (huge_page_disallowed)
+   if (huge_page_disallowed && req_level >= it.level)
account_huge_nx_page(vcpu->kvm, sp);
}
}
-- 
2.26.0



linux-next: manual merge of the tty tree with the qcom tree

2020-07-14 Thread Stephen Rothwell
Hi all,

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

  drivers/tty/serial/qcom_geni_serial.c

between commit:

  650c8bd36a66 ("serial: qcom_geni_serial: Always use 4 bytes per TX FIFO word")

from the qcom tree and commit:

  3550f8979a7b ("tty: serial: qcom_geni_serial: Clean up an ARRAY_SIZE() vs 
sizeof()")

from the tty tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/tty/serial/qcom_geni_serial.c
index 07b7b6b05b8b,1ed3d354e16d..
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@@ -768,8 -718,8 +768,8 @@@ static void qcom_geni_serial_handle_tx(
u8 buf[sizeof(u32)];
int c;
  
-   memset(buf, 0, ARRAY_SIZE(buf));
+   memset(buf, 0, sizeof(buf));
 -  tx_bytes = min_t(size_t, remaining, port->tx_bytes_pw);
 +  tx_bytes = min_t(size_t, remaining, BYTES_PER_FIFO_WORD);
  
for (c = 0; c < tx_bytes ; c++) {
buf[c] = xmit->buf[tail++];


pgpiraVdKalzm.pgp
Description: OpenPGP digital signature


[PATCH v1 2/3] dt-bindings: media: imx274: Add optional xclk and supplies

2020-07-14 Thread Sowjanya Komatineni
This patch adds IMX274 optional external clock input and voltage
supplies to device tree bindings.

Signed-off-by: Sowjanya Komatineni 
---
 Documentation/devicetree/bindings/media/i2c/imx274.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/imx274.txt 
b/Documentation/devicetree/bindings/media/i2c/imx274.txt
index 80f2e89..ee427f5 100644
--- a/Documentation/devicetree/bindings/media/i2c/imx274.txt
+++ b/Documentation/devicetree/bindings/media/i2c/imx274.txt
@@ -13,6 +13,11 @@ Required Properties:
 
 Optional Properties:
 - reset-gpios: Sensor reset GPIO
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- VANA-supply: Sensor 2.8v analog supply.
+- VDIG-supply: Sensor 1.8v digital core supply.
+- VDDL-supply: Sensor digital IO 1.2v supply.
 
 The imx274 device node should contain one 'port' child node with
 an 'endpoint' subnode. For further reading on port node refer to
-- 
2.7.4



[PATCH v1 3/3] media: i2c: imx274: Add IMX274 power on and off sequence

2020-07-14 Thread Sowjanya Komatineni
IMX274 has VANA analog 2.8V supply, VDIG digital core 1.8V supply,
and VDDL digital io 1.2V supply which are optional based on camera
module design.

IMX274 also need external 24Mhz clock and is optional based on
camera module design.

This patch adds support for IMX274 power on and off to enable and
disable these supplies and external clock.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/media/i2c/imx274.c | 170 -
 1 file changed, 167 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index 55869ff..8a34c07 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,8 @@
 #include 
 #include 
 
+#define IMX274_DEFAULT_CLK_FREQ2400
+
 /*
  * See "SHR, SVR Setting" in datasheet
  */
@@ -501,6 +504,10 @@ struct imx274_ctrls {
  * @frame_rate: V4L2 frame rate structure
  * @regmap: Pointer to regmap structure
  * @reset_gpio: Pointer to reset gpio
+ * @vana_supply: VANA analog supply regulator
+ * @vdig_supply: VDIG digital core supply regulator
+ * @vddl_supply: VDDL digital io supply regulator
+ * @xclk: system clock to imx274
  * @lock: Mutex structure
  * @mode: Parameters for the selected readout mode
  */
@@ -514,6 +521,10 @@ struct stimx274 {
struct v4l2_fract frame_interval;
struct regmap *regmap;
struct gpio_desc *reset_gpio;
+   struct regulator *vana_supply;
+   struct regulator *vdig_supply;
+   struct regulator *vddl_supply;
+   struct clk *xclk;
struct mutex lock; /* mutex lock for operations */
const struct imx274_mode *mode;
 };
@@ -767,6 +778,138 @@ static void imx274_reset(struct stimx274 *priv, int rst)
usleep_range(IMX274_RESET_DELAY1, IMX274_RESET_DELAY2);
 }
 
+/*
+ * imx274_power_on - Function called to power on the sensor
+ * @imx274: Pointer to device structure
+ */
+static int imx274_power_on(struct device *dev)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   struct v4l2_subdev *sd = i2c_get_clientdata(client);
+   struct stimx274 *imx274 = to_imx274(sd);
+   int ret;
+
+   ret = clk_prepare_enable(imx274->xclk);
+   if (ret) {
+   dev_err(>client->dev, "Failed to enable clock\n");
+   return ret;
+   }
+
+   if (imx274->vana_supply) {
+   ret = regulator_enable(imx274->vana_supply);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "Failed to enable VANA supply: %d\n", ret);
+   goto disable_clk;
+   }
+   }
+
+   if (imx274->vdig_supply) {
+   ret = regulator_enable(imx274->vdig_supply);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "Failed to enable VDIG supply: %d\n", ret);
+   goto disable_vana_reg;
+   }
+   }
+
+   if (imx274->vddl_supply) {
+   ret = regulator_enable(imx274->vddl_supply);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "Failed to enable VDDL supply: %d\n", ret);
+   goto disable_vdig_reg;
+   }
+   }
+
+   usleep_range(1, 2);
+   imx274_reset(imx274, 1);
+
+   return 0;
+
+disable_vdig_reg:
+   if (imx274->vdig_supply)
+   regulator_disable(imx274->vdig_supply);
+disable_vana_reg:
+   if (imx274->vana_supply)
+   regulator_disable(imx274->vana_supply);
+disable_clk:
+   clk_disable_unprepare(imx274->xclk);
+   return ret;
+}
+
+/*
+ * imx274_power_off - Function called to power off the sensor
+ * @imx274: Pointer to device structure
+ */
+static int imx274_power_off(struct device *dev)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   struct v4l2_subdev *sd = i2c_get_clientdata(client);
+   struct stimx274 *imx274 = to_imx274(sd);
+
+   imx274_reset(imx274, 0);
+
+   if (imx274->vddl_supply)
+   regulator_disable(imx274->vddl_supply);
+
+   if (imx274->vdig_supply)
+   regulator_disable(imx274->vdig_supply);
+
+   if (imx274->vana_supply)
+   regulator_disable(imx274->vana_supply);
+
+   clk_disable_unprepare(imx274->xclk);
+
+   return 0;
+}
+
+static int imx274_get_regulators(struct device *dev, struct stimx274 *imx274)
+{
+   int i;
+
+   imx274->vana_supply = devm_regulator_get_optional(dev, "VANA");
+   if (IS_ERR(imx274->vana_supply)) {
+   if (PTR_ERR(imx274->vana_supply) != -ENODEV) {
+   if (PTR_ERR(imx274->vana_supply) != -EPROBE_DEFER)
+   dev_err(>client->dev,
+   "Failed to get VANA supply: %ld\n",
+ 

[PATCH v1 1/3] media: i2c: imx274: Fix Y_OUT_SIZE register setting

2020-07-14 Thread Sowjanya Komatineni
Current driver sets Y_OUT_SIZE to crop height + 8 and seeing long frame
errors on the receiver size as expected height on reciever is crop height.

As per Sony IMX274 Y_OUT_SIZE should be the height of effective
image output from the sensor which are the actual total lines
sent over MIPI CSI to receiver.

So, Y_OUT_SIZE should be same as crop height and this patch fixes it.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/media/i2c/imx274.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index e6aa9f3..55869ff 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -1163,7 +1163,7 @@ static int imx274_apply_trimming(struct stimx274 *imx274)
(-imx274->crop.top / 2) : (imx274->crop.top / 2);
v_cut = (IMX274_MAX_HEIGHT - imx274->crop.height) / 2;
write_v_size = imx274->crop.height + 22;
-   y_out_size   = imx274->crop.height + 14;
+   y_out_size   = imx274->crop.height;
 
err = imx274_write_mbreg(imx274, IMX274_HMAX_REG_LSB, hmax, 2);
if (!err)
-- 
2.7.4



[RFC PATCH v3 04/18] i2c: tegra: Remove NULL pointer check before clk_enable/disable/prepare/unprepare

2020-07-14 Thread Sowjanya Komatineni
clk_enable, clk_disable, clk_prepare, and clk_unprepare APIs have
implementation for checking clk pointer not NULL and clock consumers
can safely call these APIs without NULL pointer check.

So, this patch cleans up Tegra i2c driver to remove explicit checks
before these APIs.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/i2c/busses/i2c-tegra.c | 64 +++---
 1 file changed, 23 insertions(+), 41 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 3be1018..c91307b9 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -655,21 +655,17 @@ static int __maybe_unused tegra_i2c_runtime_resume(struct 
device *dev)
if (ret)
return ret;
 
-   if (!i2c_dev->hw->has_single_clk_source) {
-   ret = clk_enable(i2c_dev->fast_clk);
-   if (ret < 0) {
-   dev_err(i2c_dev->dev,
-   "Enabling fast clk failed, err %d\n", ret);
-   return ret;
-   }
+   ret = clk_enable(i2c_dev->fast_clk);
+   if (ret < 0) {
+   dev_err(i2c_dev->dev,
+   "Enabling fast clk failed, err %d\n", ret);
+   return ret;
}
 
-   if (i2c_dev->slow_clk) {
-   ret = clk_enable(i2c_dev->slow_clk);
-   if (ret < 0) {
-   dev_err(dev, "failed to enable slow clock: %d\n", ret);
-   return ret;
-   }
+   ret = clk_enable(i2c_dev->slow_clk);
+   if (ret < 0) {
+   dev_err(dev, "failed to enable slow clock: %d\n", ret);
+   return ret;
}
 
ret = clk_enable(i2c_dev->div_clk);
@@ -688,12 +684,8 @@ static int __maybe_unused tegra_i2c_runtime_suspend(struct 
device *dev)
struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
 
clk_disable(i2c_dev->div_clk);
-
-   if (i2c_dev->slow_clk)
-   clk_disable(i2c_dev->slow_clk);
-
-   if (!i2c_dev->hw->has_single_clk_source)
-   clk_disable(i2c_dev->fast_clk);
+   clk_disable(i2c_dev->slow_clk);
+   clk_disable(i2c_dev->fast_clk);
 
return pinctrl_pm_select_idle_state(i2c_dev->dev);
 }
@@ -1716,20 +1708,16 @@ static int tegra_i2c_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, i2c_dev);
 
-   if (!i2c_dev->hw->has_single_clk_source) {
-   ret = clk_prepare(i2c_dev->fast_clk);
-   if (ret < 0) {
-   dev_err(i2c_dev->dev, "Clock prepare failed %d\n", ret);
-   return ret;
-   }
+   ret = clk_prepare(i2c_dev->fast_clk);
+   if (ret < 0) {
+   dev_err(i2c_dev->dev, "Clock prepare failed %d\n", ret);
+   return ret;
}
 
-   if (i2c_dev->slow_clk) {
-   ret = clk_prepare(i2c_dev->slow_clk);
-   if (ret < 0) {
-   dev_err(dev, "failed to prepare slow clock: %d\n", ret);
-   goto unprepare_fast_clk;
-   }
+   ret = clk_prepare(i2c_dev->slow_clk);
+   if (ret < 0) {
+   dev_err(dev, "failed to prepare slow clock: %d\n", ret);
+   goto unprepare_fast_clk;
}
 
if (i2c_dev->bus_clk_rate > I2C_MAX_FAST_MODE_FREQ &&
@@ -1843,12 +1831,10 @@ static int tegra_i2c_probe(struct platform_device *pdev)
clk_unprepare(i2c_dev->div_clk);
 
 unprepare_slow_clk:
-   if (i2c_dev->is_vi)
-   clk_unprepare(i2c_dev->slow_clk);
+   clk_unprepare(i2c_dev->slow_clk);
 
 unprepare_fast_clk:
-   if (!i2c_dev->hw->has_single_clk_source)
-   clk_unprepare(i2c_dev->fast_clk);
+   clk_unprepare(i2c_dev->fast_clk);
 
return ret;
 }
@@ -1867,12 +1853,8 @@ static int tegra_i2c_remove(struct platform_device *pdev)
tegra_i2c_runtime_suspend(>dev);
 
clk_unprepare(i2c_dev->div_clk);
-
-   if (i2c_dev->slow_clk)
-   clk_unprepare(i2c_dev->slow_clk);
-
-   if (!i2c_dev->hw->has_single_clk_source)
-   clk_unprepare(i2c_dev->fast_clk);
+   clk_unprepare(i2c_dev->slow_clk);
+   clk_unprepare(i2c_dev->fast_clk);
 
tegra_i2c_release_dma(i2c_dev);
return 0;
-- 
2.7.4



[RFC PATCH v3 01/18] dt-bindings: i2c: tegra: Document Tegra210 VI I2C clocks and power-domains

2020-07-14 Thread Sowjanya Komatineni
This patch documents missing clocks and power-domains of Tegra210 VI I2C.

Reviewed-by: Rob Herring 
Signed-off-by: Sowjanya Komatineni 
---
 .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt| 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt 
b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
index 18c0de3..3f2f990 100644
--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
@@ -35,12 +35,12 @@ Required properties:
Due to above changes, Tegra114 I2C driver makes incompatible with
previous hardware driver. Hence, tegra114 I2C controller is compatible
with "nvidia,tegra114-i2c".
-  nvidia,tegra210-i2c-vi: Tegra210 has one I2C controller that is part of the
-   host1x domain and typically used for camera use-cases. This VI I2C
-   controller is mostly compatible with the programming model of the
-   regular I2C controllers with a few exceptions. The I2C registers start
-   at an offset of 0xc00 (instead of 0), registers are 16 bytes apart
-   (rather than 4) and the controller does not support slave mode.
+  nvidia,tegra210-i2c-vi: Tegra210 has one I2C controller that is on host1x bus
+   and is part of VE power domain and typically used for camera use-cases.
+   This VI I2C controller is mostly compatible with the programming model
+   of the regular I2C controllers with a few exceptions. The I2C registers
+   start at an offset of 0xc00 (instead of 0), registers are 16 bytes
+   apart (rather than 4) and the controller does not support slave mode.
 - reg: Should contain I2C controller registers physical address and length.
 - interrupts: Should contain I2C controller interrupts.
 - address-cells: Address cells for I2C device address.
@@ -53,10 +53,17 @@ Required properties:
   - fast-clk
   Tegra114:
   - div-clk
+  Tegra210:
+  - div-clk
+  - slow (only for nvidia,tegra210-i2c-vi compatible node)
 - resets: Must contain an entry for each entry in reset-names.
   See ../reset/reset.txt for details.
 - reset-names: Must include the following entries:
   - i2c
+- power-domains: Only for nvidia,tegra210-i2c-vi compatible node and must
+  include venc powergate node as vi i2c is part of VE power domain.
+  tegra210-i2c-vi:
+  - pd_venc
 - dmas: Must contain an entry for each entry in clock-names.
   See ../dma/dma.txt for details.
 - dma-names: Must include the following entries:
-- 
2.7.4



[RFC PATCH v3 11/18] dt-bindings: tegra: Update VI and CSI bindings with port info

2020-07-14 Thread Sowjanya Komatineni
Update VI and CSI bindings to add port and endpoint nodes as per
media video-interfaces DT binding document.

Signed-off-by: Sowjanya Komatineni 
---
 .../display/tegra/nvidia,tegra20-host1x.txt| 92 +-
 1 file changed, 90 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 4731921..ac63ae4a 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -51,8 +51,16 @@ of the following host1x client modules:
   - vi
   - Tegra210:
 - power-domains: Must include venc powergate node as vi is in VE partition.
-  - Tegra210 has CSI part of VI sharing same host interface and register space.
-So, VI device node should have CSI child node.
+
+  ports (optional node)
+  vi can have optional ports node and max 6 ports are supported. Each port
+  should have single 'endpoint' child node. All port nodes are grouped under
+  ports node. Please refer to the bindings defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt
+
+  csi (required node)
+  Tegra210 has CSI part of VI sharing same host interface and register space.
+  So, VI device node should have CSI child node.
 
 - csi: mipi csi interface to vi
 
@@ -65,6 +73,46 @@ of the following host1x client modules:
   - power-domains: Must include sor powergate node as csicil is in
 SOR partition.
 
+  channel (optional nodes)
+  Maximum 6 channels are supported with each csi brick as either x4 or x2
+  based on hw connectivity to sensor.
+
+  Required properties:
+  - reg: csi port number. Valid port numbers are 0 through 5.
+  - nvidia,mipi-calibrate: Should contain a phandle and a specifier
+specifying which pads are used by this CSI port and need to be
+   calibrated. See also ../display/tegra/nvidia,tegra114-mipi.txt.
+
+  Each channel node must contain 2 port nodes which can be grouped
+  under 'ports' node and each port should have a single child 'endpoint'
+  node.
+
+ports node
+Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+ports node must contain below 2 port nodes.
+port@0 with single child 'endpoint' node always a sink.
+port@1 with single child 'endpoint' node always a source.
+
+port@0 (required node)
+Required properties:
+- reg: 0
+
+ endpoint (required node)
+ Required properties:
+ - data-lanes: an array of data lane from 1 to 4. Valid array
+   lengths are 1/2/4.
+ - remote-endpoint: phandle to sensor 'endpoint' node.
+
+port@1 (required node)
+Required properties:
+- reg: 1
+
+ endpoint (required node)
+ Required properties:
+ - remote-endpoint: phandle to vi port 'endpoint' node.
+
 - epp: encoder pre-processor
 
   Required properties:
@@ -340,6 +388,18 @@ Example:
 
ranges = <0x0 0x0 0x5408 0x2000>;
 
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   imx219_vi_in0: endpoint {
+   remote-endpoint = 
<_csi_out0>;
+   };
+   };
+   };
+
csi@838 {
compatible = "nvidia,tegra210-csi";
reg = <0x838 0x1300>;
@@ -362,6 +422,34 @@ Example:
 <_car TEGRA210_CLK_CSI_TPG>;
clock-names = "csi", "cilab", "cilcd", "cile", 
"csi_tpg";
power-domains = <_sor>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   channel@0 {
+   reg = <0>;
+   nvidia,mipi-calibrate = < 0x001>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   imx219_csi_in0: 
endpoint {
+   data-lanes = <1 
2>;
+   remote-endpoint 
= <_out0>;
+

[RFC PATCH v3 03/18] i2c: tegra: Don't mark VI I2C as IRQ safe runtime PM

2020-07-14 Thread Sowjanya Komatineni
Tegra VI I2C is part of VE power domain and typically used for
camera usecases.

VE power domain is not always on and is non-IRQ safe. So, IRQ safe
device cannot be attached to a non-IRQ safe domain as it prevents
powering off the PM domain and generic power domain driver will warn.

Current driver marks all I2C devices as IRQ safe and VI I2C device
does not require IRQ safe as it will not be used for atomic transfers.

This patch has fix to make VI I2C as non-IRQ safe.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/i2c/busses/i2c-tegra.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 1577296..3be1018 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1750,7 +1750,15 @@ static int tegra_i2c_probe(struct platform_device *pdev)
goto unprepare_slow_clk;
}
 
-   pm_runtime_irq_safe(>dev);
+   /*
+* VI I2C is in VE power domain which is not always on and not
+* an IRQ safe. So, IRQ safe device can't be attached to a non-IRQ
+* safe domain as it prevents powering off the PM domain.
+* Also, VI I2C device don't need to use runtime IRQ safe as it will
+* not be used for atomic transfers.
+*/
+   if (!i2c_dev->is_vi)
+   pm_runtime_irq_safe(>dev);
pm_runtime_enable(>dev);
if (!pm_runtime_enabled(>dev)) {
ret = tegra_i2c_runtime_resume(>dev);
-- 
2.7.4



[RFC PATCH v3 14/18] gpu: host1x: mipi: Update tegra_mipi_request() to be node based

2020-07-14 Thread Sowjanya Komatineni
Tegra CSI driver need a separate MIPI device for each channel as
calibration of corresponding MIPI pads for each channel should
happen independently.

So, this patch updates tegra_mipi_request() API to add a device_node
pointer argument to allow creating mipi device for specific device
node rather than a device.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/gpu/drm/tegra/dsi.c | 2 +-
 drivers/gpu/host1x/mipi.c   | 4 ++--
 include/linux/host1x.h  | 3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 38beab9..3c09e29 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -1618,7 +1618,7 @@ static int tegra_dsi_probe(struct platform_device *pdev)
if (IS_ERR(dsi->regs))
return PTR_ERR(dsi->regs);
 
-   dsi->mipi = tegra_mipi_request(>dev);
+   dsi->mipi = tegra_mipi_request(>dev, pdev->dev.of_node);
if (IS_ERR(dsi->mipi))
return PTR_ERR(dsi->mipi);
 
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
index e00809d..762d349 100644
--- a/drivers/gpu/host1x/mipi.c
+++ b/drivers/gpu/host1x/mipi.c
@@ -206,9 +206,9 @@ static int tegra_mipi_power_down(struct tegra_mipi *mipi)
return 0;
 }
 
-struct tegra_mipi_device *tegra_mipi_request(struct device *device)
+struct tegra_mipi_device *tegra_mipi_request(struct device *device,
+struct device_node *np)
 {
-   struct device_node *np = device->of_node;
struct tegra_mipi_device *dev;
struct of_phandle_args args;
int err;
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index a3a568b..9e67841 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -328,7 +328,8 @@ int host1x_client_resume(struct host1x_client *client);
 
 struct tegra_mipi_device;
 
-struct tegra_mipi_device *tegra_mipi_request(struct device *device);
+struct tegra_mipi_device *tegra_mipi_request(struct device *device,
+struct device_node *np);
 void tegra_mipi_free(struct tegra_mipi_device *device);
 int tegra_mipi_enable(struct tegra_mipi_device *device);
 int tegra_mipi_disable(struct tegra_mipi_device *device);
-- 
2.7.4



Re: [PATCH v2 3/4] x86: Expose SERIALIZE for supported cpuid

2020-07-14 Thread hpa
On July 14, 2020 5:03:31 PM PDT, "Zhang, Cathy"  wrote:
>On 7/15/2020 7:05 AM, h...@zytor.com wrote:
>> On July 14, 2020 3:42:08 PM PDT, "Zhang, Cathy"
> wrote:
>>> On 7/14/2020 11:00 AM, Sean Christopherson wrote:
 On Tue, Jul 07, 2020 at 10:16:22AM +0800, Cathy Zhang wrote:
> SERIALIZE instruction is supported by intel processors,
> like Sapphire Rapids. Expose it in KVM supported cpuid.
 Providing at least a rough overview of the instruction, e.g. its
>>> enumeration,
 usage, fault rules, controls, etc... would be nice.  In isolation,
>>> the
 changelog isn't remotely helpful in understanding the correctness
>of
>>> the
 patch.
>>> Thanks Sean! Add it in the next version.
> Signed-off-by: Cathy Zhang 
> ---
>arch/x86/kvm/cpuid.c | 3 ++-
>1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 8a294f9..e603aeb 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -341,7 +341,8 @@ void kvm_set_cpu_caps(void)
>   kvm_cpu_cap_mask(CPUID_7_EDX,
>   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(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM) |
> + F(SERIALIZE)
>   );
>
>   /* TSC_ADJUST and ARCH_CAPABILITIES are emulated in software.
>*/
> -- 
> 1.8.3.1
>
>> At least that one is easy: SERIALIZE is architecturally a NOP, but
>with hard serialization, like CPUID or IRET.
>SERIALIZE does not modify registers, arithmetic flags or memory, which 
>is different with CPUID.

That's what I meant with it being an architectural NOP.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


[RFC PATCH v3 16/18] gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait

2020-07-14 Thread Sowjanya Komatineni
SW can trigger MIPI pads calibration any time after power on
but calibration results will be latched and applied to the pads
by MIPI CAL unit only when the link is in LP-11 state and then
status register will be updated.

For CSI, trigger of pads calibration happen during CSI stream
enable where CSI receiver is kept ready prior to sensor or CSI
transmitter stream start.

So, pads may not be in LP-11 at this time and waiting for the
calibration to be done immediate after calibration start will
result in timeout.

This patch splits tegra_mipi_calibrate() and tegra_mipi_wait()
so triggering for calibration and waiting for it to complete can
happen at different stages.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/gpu/drm/tegra/dsi.c |  7 ++-
 drivers/gpu/host1x/mipi.c   | 17 +
 include/linux/host1x.h  |  1 +
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 3c09e29..1a76f1f 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -670,6 +670,7 @@ static int tegra_dsi_pad_enable(struct tegra_dsi *dsi)
 static int tegra_dsi_pad_calibrate(struct tegra_dsi *dsi)
 {
u32 value;
+   int ret;
 
/*
 * XXX Is this still needed? The module reset is deasserted right
@@ -693,7 +694,11 @@ static int tegra_dsi_pad_calibrate(struct tegra_dsi *dsi)
DSI_PAD_PREEMP_PD(0x03) | DSI_PAD_PREEMP_PU(0x3);
tegra_dsi_writel(dsi, value, DSI_PAD_CONTROL_3);
 
-   return tegra_mipi_calibrate(dsi->mipi);
+   ret = tegra_mipi_calibrate(dsi->mipi);
+   if (ret < 0)
+   return ret;
+
+   return tegra_mipi_wait(dsi->mipi);
 }
 
 static void tegra_dsi_set_timeout(struct tegra_dsi *dsi, unsigned long bclk,
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
index 259e70c..e606464 100644
--- a/drivers/gpu/host1x/mipi.c
+++ b/drivers/gpu/host1x/mipi.c
@@ -293,18 +293,29 @@ int tegra_mipi_disable(struct tegra_mipi_device *dev)
 }
 EXPORT_SYMBOL(tegra_mipi_disable);
 
-static int tegra_mipi_wait(struct tegra_mipi *mipi)
+int tegra_mipi_wait(struct tegra_mipi_device *device)
 {
+   struct tegra_mipi *mipi = device->mipi;
void __iomem *status_reg = mipi->regs + (MIPI_CAL_STATUS << 2);
u32 value;
int err;
 
+   err = clk_enable(device->mipi->clk);
+   if (err < 0)
+   return err;
+
+   mutex_lock(>mipi->lock);
+
err = readl_relaxed_poll_timeout(status_reg, value,
 !(value & MIPI_CAL_STATUS_ACTIVE) &&
 (value & MIPI_CAL_STATUS_DONE), 50,
 25);
+   mutex_unlock(>mipi->lock);
+   clk_disable(device->mipi->clk);
+
return err;
 }
+EXPORT_SYMBOL(tegra_mipi_wait);
 
 int tegra_mipi_calibrate(struct tegra_mipi_device *device)
 {
@@ -370,12 +381,10 @@ int tegra_mipi_calibrate(struct tegra_mipi_device *device)
value |= MIPI_CAL_CTRL_START;
tegra_mipi_writel(device->mipi, value, MIPI_CAL_CTRL);
 
-   err = tegra_mipi_wait(device->mipi);
-
mutex_unlock(>mipi->lock);
clk_disable(device->mipi->clk);
 
-   return err;
+   return 0;
 }
 EXPORT_SYMBOL(tegra_mipi_calibrate);
 
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 9e67841..20c885d 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -334,5 +334,6 @@ void tegra_mipi_free(struct tegra_mipi_device *device);
 int tegra_mipi_enable(struct tegra_mipi_device *device);
 int tegra_mipi_disable(struct tegra_mipi_device *device);
 int tegra_mipi_calibrate(struct tegra_mipi_device *device);
+int tegra_mipi_wait(struct tegra_mipi_device *device);
 
 #endif
-- 
2.7.4



[RFC PATCH v3 06/18] i2c: tegra: Fix runtime resume to re-init VI I2C

2020-07-14 Thread Sowjanya Komatineni
VI I2C is on host1x bus and is part of VE power domain.

During suspend/resume VE power domain goes through power off/on.

So, controller reset followed by i2c re-initialization is required
after the domain power up.

This patch fixes it.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/i2c/busses/i2c-tegra.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 7b93c45..1bf3666 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -293,6 +293,8 @@ struct tegra_i2c_dev {
bool is_curr_atomic_xfer;
 };
 
+static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev, bool clk_reinit);
+
 static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
   unsigned long reg)
 {
@@ -675,8 +677,22 @@ static int __maybe_unused tegra_i2c_runtime_resume(struct 
device *dev)
goto disable_slow_clk;
}
 
+   /*
+* VI I2C device is attached to VE power domain which goes through
+* power ON/OFF during PM runtime resume/suspend. So, controller
+* should go through reset and need to re-initialize after power
+* domain ON.
+*/
+   if (i2c_dev->is_vi) {
+   ret = tegra_i2c_init(i2c_dev, true);
+   if (ret)
+   goto disable_div_clk;
+   }
+
return 0;
 
+disable_div_clk:
+   clk_disable(i2c_dev->div_clk);
 disable_slow_clk:
clk_disable(i2c_dev->slow_clk);
 disable_fast_clk:
-- 
2.7.4



[RFC PATCH v3 12/18] media: tegra-video: Add support for external sensor capture

2020-07-14 Thread Sowjanya Komatineni
This patch adds support to capture from the external sensor
based on device graph in the device tree.

Driver walks through the device graph to create media links
between the entities and registers and unregisters video devices
when the corresponding sub-devices are bound and unbound.

Channel formats are enumerated based on available formats from
the sensor and the corresponding matched formats from the Tegra
supported video formats list.

Each Tegra CSI instance can be configured as 4-lane or 2-lane
based on supported lane configuration from the sensor through
the device tree.

Currently this driver supports V4L2 video node centric only.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/staging/media/tegra-video/Kconfig|   1 +
 drivers/staging/media/tegra-video/csi.c  | 130 +-
 drivers/staging/media/tegra-video/csi.h  |   1 +
 drivers/staging/media/tegra-video/tegra210.c |   2 +-
 drivers/staging/media/tegra-video/vi.c   | 648 +--
 drivers/staging/media/tegra-video/vi.h   |  25 +-
 6 files changed, 749 insertions(+), 58 deletions(-)

diff --git a/drivers/staging/media/tegra-video/Kconfig 
b/drivers/staging/media/tegra-video/Kconfig
index 566da62..1f35da4 100644
--- a/drivers/staging/media/tegra-video/Kconfig
+++ b/drivers/staging/media/tegra-video/Kconfig
@@ -5,6 +5,7 @@ config VIDEO_TEGRA
depends on VIDEO_V4L2
select MEDIA_CONTROLLER
select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
help
  Choose this option if you have an NVIDIA Tegra SoC.
 
diff --git a/drivers/staging/media/tegra-video/csi.c 
b/drivers/staging/media/tegra-video/csi.c
index fb667df..c21dd09 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -9,10 +9,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
+
 #include "csi.h"
 #include "video.h"
 
@@ -285,26 +288,101 @@ static const struct v4l2_subdev_ops tegra_csi_ops = {
.pad= _csi_pad_ops,
 };
 
+static int tegra_csi_channel_alloc(struct tegra_csi *csi,
+  struct device_node *node,
+  unsigned int port_num, unsigned int lanes,
+  unsigned int num_pads)
+{
+   struct tegra_csi_channel *chan;
+
+   chan = kzalloc(sizeof(*chan), GFP_KERNEL);
+   if (!chan)
+   return -ENOMEM;
+
+   list_add_tail(>list, >csi_chans);
+   chan->csi = csi;
+   chan->csi_port_num = port_num;
+   chan->numlanes = lanes;
+   chan->of_node = node;
+   chan->numpads = num_pads;
+   if (num_pads & 0x2) {
+   chan->pads[0].flags = MEDIA_PAD_FL_SINK;
+   chan->pads[1].flags = MEDIA_PAD_FL_SOURCE;
+   } else {
+   chan->pads[0].flags = MEDIA_PAD_FL_SOURCE;
+   }
+
+   return 0;
+}
+
 static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
 {
struct device_node *node = csi->dev->of_node;
unsigned int port_num;
-   struct tegra_csi_channel *chan;
unsigned int tpg_channels = csi->soc->csi_max_channels;
+   int ret;
 
/* allocate CSI channel for each CSI x2 ports */
for (port_num = 0; port_num < tpg_channels; port_num++) {
-   chan = kzalloc(sizeof(*chan), GFP_KERNEL);
-   if (!chan)
-   return -ENOMEM;
-
-   list_add_tail(>list, >csi_chans);
-   chan->csi = csi;
-   chan->csi_port_num = port_num;
-   chan->numlanes = 2;
-   chan->of_node = node;
-   chan->numpads = 1;
-   chan->pads[0].flags = MEDIA_PAD_FL_SOURCE;
+   ret = tegra_csi_channel_alloc(csi, node, port_num, 2, 1);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int tegra_csi_channels_alloc(struct tegra_csi *csi)
+{
+   struct device_node *node = csi->dev->of_node;
+   struct v4l2_fwnode_endpoint v4l2_ep = {
+   .bus_type = V4L2_MBUS_CSI2_DPHY
+   };
+   struct fwnode_handle *fwh;
+   struct device_node *channel;
+   struct device_node *ep;
+   unsigned int lanes, portno, num_pads;
+   int ret;
+
+   for_each_child_of_node(node, channel) {
+   if (!of_node_name_eq(channel, "channel"))
+   continue;
+
+   ret = of_property_read_u32(channel, "reg", );
+   if (ret < 0)
+   continue;
+
+   if (portno >= csi->soc->csi_max_channels) {
+   dev_err(csi->dev, "invalid port num %d\n", portno);
+   return -EINVAL;
+   }
+
+   ep = of_graph_get_endpoint_by_regs(channel, 0, 0);
+   if (!ep)
+   continue;
+
+   fwh = of_fwnode_handle(ep);
+   ret = v4l2_fwnode_endpoint_parse(fwh, _ep);

[RFC PATCH v3 15/18] gpu: host1x: mipi: Use readl_relaxed_poll_timeout in tegra_mipi_wait

2020-07-14 Thread Sowjanya Komatineni
Use readl_relaxed_poll_timeout() in tegra_mipi_wait() to simplify
the code.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/gpu/host1x/mipi.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
index 762d349..259e70c 100644
--- a/drivers/gpu/host1x/mipi.c
+++ b/drivers/gpu/host1x/mipi.c
@@ -21,9 +21,9 @@
  */
 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -295,19 +295,15 @@ EXPORT_SYMBOL(tegra_mipi_disable);
 
 static int tegra_mipi_wait(struct tegra_mipi *mipi)
 {
-   unsigned long timeout = jiffies + msecs_to_jiffies(250);
+   void __iomem *status_reg = mipi->regs + (MIPI_CAL_STATUS << 2);
u32 value;
+   int err;
 
-   while (time_before(jiffies, timeout)) {
-   value = tegra_mipi_readl(mipi, MIPI_CAL_STATUS);
-   if ((value & MIPI_CAL_STATUS_ACTIVE) == 0 &&
-   (value & MIPI_CAL_STATUS_DONE) != 0)
-   return 0;
-
-   usleep_range(10, 50);
-   }
-
-   return -ETIMEDOUT;
+   err = readl_relaxed_poll_timeout(status_reg, value,
+!(value & MIPI_CAL_STATUS_ACTIVE) &&
+(value & MIPI_CAL_STATUS_DONE), 50,
+25);
+   return err;
 }
 
 int tegra_mipi_calibrate(struct tegra_mipi_device *device)
-- 
2.7.4



[RFC PATCH v3 17/18] media: tegra-video: Add CSI MIPI pads calibration

2020-07-14 Thread Sowjanya Komatineni
CSI MIPI pads need to be enabled and calibrated for capturing from
the external sensor or transmitter.

MIPI CAL unit calibrates MIPI pads pull-up, pull-down and termination
impedances. Calibration is done by co-work of MIPI BIAS pad and MIPI
CAL control unit.

Triggering calibration start can happen any time after MIPI pads are
enabled but calibration results will be latched and applied to MIPI
pads by MIPI CAL unit only when the link is in LP11 state and then
calibration status register gets updated.

This patch enables CSI MIPI pads and calibrates them during streaming.

Tegra CSI receiver is able to catch the very first clock transition.
So, CSI receiver is always enabled prior to sensor streaming and
trigger of calibration start is done during CSI subdev streaming and
status of calibration is verified after sensor stream on.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/staging/media/tegra-video/csi.c | 44 +++--
 drivers/staging/media/tegra-video/csi.h |  2 ++
 drivers/staging/media/tegra-video/vi.c  | 16 
 3 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/tegra-video/csi.c 
b/drivers/staging/media/tegra-video/csi.c
index c21dd09..75c844d 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -252,15 +252,42 @@ static int tegra_csi_s_stream(struct v4l2_subdev *subdev, 
int enable)
return ret;
}
 
+   if (csi_chan->mipi) {
+   ret = tegra_mipi_enable(csi_chan->mipi);
+   if (ret < 0) {
+   dev_err(csi->dev,
+   "failed to enable MIPI pads: %d\n",
+   ret);
+   goto rpm_put;
+   }
+
+   /*
+* CSI MIPI pads PULLUP, PULLDN and TERM impedances
+* need to be calibrated after power on.
+* So, trigger the calibration start here and results
+* will be latched and applied to the pads when link is
+* in LP11 state during start of sensor streaming.
+*/
+   tegra_mipi_calibrate(csi_chan->mipi);
+   }
+
ret = csi->ops->csi_start_streaming(csi_chan);
if (ret < 0)
-   goto rpm_put;
+   goto disable_mipi;
 
return 0;
}
 
csi->ops->csi_stop_streaming(csi_chan);
 
+disable_mipi:
+   if (csi_chan->mipi) {
+   ret = tegra_mipi_disable(csi_chan->mipi);
+   if (ret < 0)
+   dev_err(csi->dev,
+   "failed to disable MIPI pads: %d\n", ret);
+   }
+
 rpm_put:
pm_runtime_put(csi->dev);
return ret;
@@ -294,6 +321,7 @@ static int tegra_csi_channel_alloc(struct tegra_csi *csi,
   unsigned int num_pads)
 {
struct tegra_csi_channel *chan;
+   int ret = 0;
 
chan = kzalloc(sizeof(*chan), GFP_KERNEL);
if (!chan)
@@ -312,7 +340,16 @@ static int tegra_csi_channel_alloc(struct tegra_csi *csi,
chan->pads[0].flags = MEDIA_PAD_FL_SOURCE;
}
 
-   return 0;
+   if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   return 0;
+
+   chan->mipi = tegra_mipi_request(csi->dev, node);
+   if (IS_ERR(chan->mipi)) {
+   ret = PTR_ERR(chan->mipi);
+   dev_err(csi->dev, "failed to get mipi device: %d\n", ret);
+   }
+
+   return ret;
 }
 
 static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
@@ -475,6 +512,9 @@ static void tegra_csi_channels_cleanup(struct tegra_csi 
*csi)
struct tegra_csi_channel *chan, *tmp;
 
list_for_each_entry_safe(chan, tmp, >csi_chans, list) {
+   if (chan->mipi)
+   tegra_mipi_free(chan->mipi);
+
subdev = >subdev;
if (subdev->dev) {
if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
diff --git a/drivers/staging/media/tegra-video/csi.h 
b/drivers/staging/media/tegra-video/csi.h
index 78a5110..0d50fc3 100644
--- a/drivers/staging/media/tegra-video/csi.h
+++ b/drivers/staging/media/tegra-video/csi.h
@@ -50,6 +50,7 @@ struct tegra_csi;
  * @framerate: active framerate for TPG
  * @h_blank: horizontal blanking for TPG active format
  * @v_blank: vertical blanking for TPG active format
+ * @mipi: mipi device for corresponding csi channel pads
  */
 struct tegra_csi_channel {
struct list_head list;
@@ -65,6 +66,7 @@ struct tegra_csi_channel {
unsigned int framerate;
unsigned int h_blank;
unsigned int v_blank;
+   struct tegra_mipi_device *mipi;
 };
 
 /**
diff --git a/drivers/staging/media/tegra-video/vi.c 

[RFC PATCH v3 07/18] i2c: tegra: Avoid tegra_i2c_init_dma() for Tegra210 vi i2c

2020-07-14 Thread Sowjanya Komatineni
VI I2C is on host1x bus so APB DMA can't be used for Tegra210 VI
I2C and there are no tx and rx dma channels for VI I2C.

So, avoid attempt of requesting DMA channels.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/i2c/busses/i2c-tegra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 1bf3666..00d3e4d 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -421,7 +421,7 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
dma_addr_t dma_phys;
int err;
 
-   if (!i2c_dev->hw->has_apb_dma)
+   if (!i2c_dev->hw->has_apb_dma || i2c_dev->is_vi)
return 0;
 
if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
-- 
2.7.4



[RFC PATCH v3 09/18] media: tegra-video: Enable TPG based on kernel config

2020-07-14 Thread Sowjanya Komatineni
Tegra internal TPG mode is only for Tegra vi and csi testing
without a real sensor and driver should default support real
sensor.

So, This patch adds CONFIG_VIDEO_TEGRA_TPG and enables Tegra
internal TPG mode only when this config is selected.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/staging/media/tegra-video/Kconfig|  6 +
 drivers/staging/media/tegra-video/csi.c  | 38 +++-
 drivers/staging/media/tegra-video/tegra210.c |  6 +
 drivers/staging/media/tegra-video/vi.c   | 13 +++---
 drivers/staging/media/tegra-video/video.c| 23 +
 5 files changed, 65 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/media/tegra-video/Kconfig 
b/drivers/staging/media/tegra-video/Kconfig
index f6c61ec..566da62 100644
--- a/drivers/staging/media/tegra-video/Kconfig
+++ b/drivers/staging/media/tegra-video/Kconfig
@@ -10,3 +10,9 @@ config VIDEO_TEGRA
 
  To compile this driver as a module, choose M here: the module
  will be called tegra-video.
+
+config VIDEO_TEGRA_TPG
+   bool "NVIDIA Tegra VI driver TPG mode"
+   depends on VIDEO_TEGRA
+   help
+ Say yes here to enable Tegra internal TPG mode
diff --git a/drivers/staging/media/tegra-video/csi.c 
b/drivers/staging/media/tegra-video/csi.c
index 40ea195..fb667df 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -62,6 +62,9 @@ static int csi_enum_bus_code(struct v4l2_subdev *subdev,
 struct v4l2_subdev_pad_config *cfg,
 struct v4l2_subdev_mbus_code_enum *code)
 {
+   if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   return -ENOIOCTLCMD;
+
if (code->index >= ARRAY_SIZE(tegra_csi_tpg_fmts))
return -EINVAL;
 
@@ -76,6 +79,9 @@ static int csi_get_format(struct v4l2_subdev *subdev,
 {
struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
 
+   if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   return -ENOIOCTLCMD;
+
fmt->format = csi_chan->format;
 
return 0;
@@ -121,6 +127,9 @@ static int csi_enum_framesizes(struct v4l2_subdev *subdev,
 {
unsigned int i;
 
+   if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   return -ENOIOCTLCMD;
+
if (fse->index >= ARRAY_SIZE(tegra_csi_tpg_sizes))
return -EINVAL;
 
@@ -148,6 +157,9 @@ static int csi_enum_frameintervals(struct v4l2_subdev 
*subdev,
const struct tpg_framerate *frmrate = csi->soc->tpg_frmrate_table;
int index;
 
+   if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   return -ENOIOCTLCMD;
+
/* one framerate per format and resolution */
if (fie->index > 0)
return -EINVAL;
@@ -172,6 +184,9 @@ static int csi_set_format(struct v4l2_subdev *subdev,
const struct v4l2_frmsize_discrete *sizes;
unsigned int i;
 
+   if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   return -ENOIOCTLCMD;
+
sizes = v4l2_find_nearest_size(tegra_csi_tpg_sizes,
   ARRAY_SIZE(tegra_csi_tpg_sizes),
   width, height,
@@ -208,6 +223,9 @@ static int tegra_csi_g_frame_interval(struct v4l2_subdev 
*subdev,
 {
struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
 
+   if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   return -ENOIOCTLCMD;
+
vfi->interval.numerator = 1;
vfi->interval.denominator = csi_chan->framerate;
 
@@ -311,8 +329,12 @@ static int tegra_csi_channel_init(struct tegra_csi_channel 
*chan)
subdev = >subdev;
v4l2_subdev_init(subdev, _csi_ops);
subdev->dev = csi->dev;
-   snprintf(subdev->name, V4L2_SUBDEV_NAME_SIZE, "%s-%d", "tpg",
-chan->csi_port_num);
+   if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+   snprintf(subdev->name, V4L2_SUBDEV_NAME_SIZE, "%s-%d", "tpg",
+chan->csi_port_num);
+   else
+   snprintf(subdev->name, V4L2_SUBDEV_NAME_SIZE, "%s",
+kbasename(chan->of_node->full_name));
 
v4l2_set_subdevdata(subdev, chan);
subdev->fwnode = of_fwnode_handle(chan->of_node);
@@ -405,11 +427,13 @@ static int tegra_csi_init(struct host1x_client *client)
 
INIT_LIST_HEAD(>csi_chans);
 
-   ret = tegra_csi_tpg_channels_alloc(csi);
-   if (ret < 0) {
-   dev_err(csi->dev,
-   "failed to allocate tpg channels: %d\n", ret);
-   goto cleanup;
+   if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG)) {
+   ret = tegra_csi_tpg_channels_alloc(csi);
+   if (ret < 0) {
+   dev_err(csi->dev,
+   "failed to allocate tpg channels: %d\n", ret);
+   goto cleanup;
+   }
}
 
ret = tegra_csi_channels_init(csi);
diff --git 

[RFC PATCH v3 02/18] arm64: tegra: Add missing clocks and power-domains to Tegra210 VI I2C

2020-07-14 Thread Sowjanya Komatineni
Tegra210 VI I2C is in VE power domain and i2c-vi node should have
power-domains property.

Current Tegra210 i2c-vi device node is missing both VI I2C clocks
and power-domains property.

This patch adds them.

Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index f4e0cc2..3827e43 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -375,6 +375,12 @@
compatible = "nvidia,tegra210-i2c-vi";
reg = <0x0 0x546c 0x0 0x0004>;
interrupts = ;
+   clocks = <_car TEGRA210_CLK_VI_I2C>,
+<_car TEGRA210_CLK_I2CSLOW>;
+   clock-names = "div-clk", "slow";
+   resets = <_car TEGRA210_CLK_VI_I2C>;
+   reset-names = "i2c";
+   power-domains = <_venc>;
status = "disabled";
};
};
-- 
2.7.4



[RFC PATCH v3 13/18] media: tegra-video: Add support for selection ioctl ops

2020-07-14 Thread Sowjanya Komatineni
This patch adds selection v4l2 ioctl operations to allow configuring
a selection rectangle in the sensor through the Tegra video device
node.

Some sensor drivers supporting crop uses try_crop rectangle from
v4l2_subdev_pad_config during try format for computing binning.

So with selection ops support, this patch also updates try format
to use try crop rectangle either from subdev frame size enumeration
or from subdev crop boundary.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/staging/media/tegra-video/vi.c | 106 +
 1 file changed, 106 insertions(+)

diff --git a/drivers/staging/media/tegra-video/vi.c 
b/drivers/staging/media/tegra-video/vi.c
index 5e19bab..676e24e2 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -437,6 +437,13 @@ static int __tegra_channel_try_format(struct 
tegra_vi_channel *chan,
struct v4l2_subdev *subdev;
struct v4l2_subdev_format fmt;
struct v4l2_subdev_pad_config *pad_cfg;
+   struct v4l2_subdev_frame_size_enum fse = {
+   .which = V4L2_SUBDEV_FORMAT_TRY,
+   };
+   struct v4l2_subdev_selection sdsel = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   .target = V4L2_SEL_TGT_CROP_BOUNDS,
+   };
int ret;
 
subdev = tegra_channel_get_remote_source_subdev(chan);
@@ -462,6 +469,24 @@ static int __tegra_channel_try_format(struct 
tegra_vi_channel *chan,
fmt.which = V4L2_SUBDEV_FORMAT_TRY;
fmt.pad = 0;
v4l2_fill_mbus_format(, pix, fmtinfo->code);
+
+   /*
+* Attempt to obtain the format size from subdev.
+* If not available, try to get crop boundary from subdev.
+*/
+   fse.code = fmtinfo->code;
+   ret = v4l2_subdev_call(subdev, pad, enum_frame_size, pad_cfg, );
+   if (ret) {
+   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, 
);
+   if (ret)
+   return -EINVAL;
+   pad_cfg->try_crop.width = sdsel.r.width;
+   pad_cfg->try_crop.height = sdsel.r.height;
+   } else {
+   pad_cfg->try_crop.width = fse.max_width;
+   pad_cfg->try_crop.height = fse.max_height;
+   }
+
ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, );
if (ret < 0)
return ret;
@@ -551,6 +576,85 @@ static int tegra_channel_set_subdev_active_fmt(struct 
tegra_vi_channel *chan)
return 0;
 }
 
+static int tegra_channel_g_selection(struct file *file, void *priv,
+struct v4l2_selection *sel)
+{
+   struct tegra_vi_channel *chan = video_drvdata(file);
+   struct v4l2_subdev *subdev;
+   struct v4l2_subdev_format fmt = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   struct v4l2_subdev_selection sdsel = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   .target = sel->target,
+   };
+   int ret;
+
+   subdev = tegra_channel_get_remote_source_subdev(chan);
+   if (!v4l2_subdev_has_op(subdev, pad, get_selection))
+   return -ENOTTY;
+
+   if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   return -EINVAL;
+   /*
+* Try the get selection operation and fallback to get format if not
+* implemented.
+*/
+   ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
+   if (!ret)
+   sel->r = sdsel.r;
+   if (ret != -ENOIOCTLCMD)
+   return ret;
+
+   ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, );
+   if (ret < 0)
+   return ret;
+
+   sel->r.left = 0;
+   sel->r.top = 0;
+   sel->r.width = fmt.format.width;
+   sel->r.height = fmt.format.height;
+
+   return 0;
+}
+
+static int tegra_channel_s_selection(struct file *file, void *fh,
+struct v4l2_selection *sel)
+{
+   struct tegra_vi_channel *chan = video_drvdata(file);
+   struct v4l2_subdev *subdev;
+   int ret;
+   struct v4l2_subdev_selection sdsel = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   .target = sel->target,
+   .flags = sel->flags,
+   .r = sel->r,
+   };
+
+   subdev = tegra_channel_get_remote_source_subdev(chan);
+   if (!v4l2_subdev_has_op(subdev, pad, set_selection))
+   return -ENOTTY;
+
+   if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   return -EINVAL;
+
+   if (vb2_is_busy(>queue))
+   return -EBUSY;
+
+   ret = v4l2_subdev_call(subdev, pad, set_selection, NULL, );
+   if (!ret) {
+   sel->r = sdsel.r;
+   /*
+* Subdev active format resolution may have changed during
+* set selection operation. So, update channel format to
+* the sub-device active format.
+*/
+   return 

[RFC PATCH v3 18/18] media: tegra-video: Compute settle times based on the clock rate

2020-07-14 Thread Sowjanya Komatineni
Settle time determines the number of cil clock cyles to wait after
LP00 when moving from LP to HS.

This patch computes T-CLK-SETTLE and T-HS-SETTLE times based on cil
clock rate and pixel rate from the sensor and programs them during
streaming.

T-CLK-SETTLE time is the interval during which receiver will ignore
any HS transitions on clock lane starting from the beginning of
T-CLK-PREPARE.

T-HS-SETTLE time is the interval during which recevier will ignore
any HS transitions on data lane starting from the beginning of
T-HS-PREPARE.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/staging/media/tegra-video/csi.c  | 55 
 drivers/staging/media/tegra-video/csi.h  |  5 +++
 drivers/staging/media/tegra-video/tegra210.c | 17 -
 3 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/tegra-video/csi.c 
b/drivers/staging/media/tegra-video/csi.c
index 75c844d..d9f9e3c 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -19,6 +19,8 @@
 #include "csi.h"
 #include "video.h"
 
+#define MHZ100
+
 static inline struct tegra_csi *
 host1x_client_to_csi(struct host1x_client *client)
 {
@@ -235,6 +237,59 @@ static int tegra_csi_g_frame_interval(struct v4l2_subdev 
*subdev,
return 0;
 }
 
+static unsigned int csi_get_pixel_rate(struct tegra_csi_channel *csi_chan)
+{
+   struct tegra_vi_channel *chan;
+   struct v4l2_subdev *src_subdev;
+   struct v4l2_ctrl *ctrl;
+
+   chan = v4l2_get_subdev_hostdata(_chan->subdev);
+   src_subdev = tegra_channel_get_remote_source_subdev(chan);
+   ctrl = v4l2_ctrl_find(src_subdev->ctrl_handler, V4L2_CID_PIXEL_RATE);
+   if (ctrl)
+   return v4l2_ctrl_g_ctrl_int64(ctrl);
+
+   return 0;
+}
+
+void tegra_csi_calc_settle_time(struct tegra_csi_channel *csi_chan,
+   u8 *clk_settle_time,
+   u8 *ths_settle_time)
+{
+   struct tegra_csi *csi = csi_chan->csi;
+   unsigned int cil_clk_mhz;
+   unsigned int pix_clk_mhz;
+   int clk_idx = (csi_chan->csi_port_num >> 1) + 1;
+
+   cil_clk_mhz = clk_get_rate(csi->clks[clk_idx].clk) / MHZ;
+   pix_clk_mhz = csi_get_pixel_rate(csi_chan) / MHZ;
+
+   /*
+* CLK Settle time is the interval during which HS receiver should
+* ignore any clock lane HS transitions, starting from the beginning
+* of T-CLK-PREPARE.
+* Per DPHY specification, T-CLK-SETTLE should be between 95ns ~ 300ns
+*
+* 95ns < (clk-settle-programmed + 7) * lp clk period < 300ns
+* midpoint = 197.5 ns
+*/
+   *clk_settle_time = ((95 + 300) * cil_clk_mhz - 14000) / 2000;
+
+   /*
+* THS Settle time is the interval during which HS receiver should
+* ignore any data lane HS transitions, starting from the beginning
+* of THS-PREPARE.
+*
+* Per DPHY specification, T-HS-SETTLE should be between 85ns + 6UI
+* and 145ns+10UI.
+* 85ns + 6UI < (Ths-settle-prog + 5) * lp_clk_period < 145ns + 10UI
+* midpoint = 115ns + 8UI
+*/
+   if (pix_clk_mhz)
+   *ths_settle_time = (115 * cil_clk_mhz + 8000 * cil_clk_mhz
+  / (2 * pix_clk_mhz) - 5000) / 1000;
+}
+
 static int tegra_csi_s_stream(struct v4l2_subdev *subdev, int enable)
 {
struct tegra_vi_channel *chan = v4l2_get_subdev_hostdata(subdev);
diff --git a/drivers/staging/media/tegra-video/csi.h 
b/drivers/staging/media/tegra-video/csi.h
index 0d50fc3..c65ff73 100644
--- a/drivers/staging/media/tegra-video/csi.h
+++ b/drivers/staging/media/tegra-video/csi.h
@@ -51,6 +51,7 @@ struct tegra_csi;
  * @h_blank: horizontal blanking for TPG active format
  * @v_blank: vertical blanking for TPG active format
  * @mipi: mipi device for corresponding csi channel pads
+ * @pixel_rate: active pixel rate from the sensor on this channel
  */
 struct tegra_csi_channel {
struct list_head list;
@@ -67,6 +68,7 @@ struct tegra_csi_channel {
unsigned int h_blank;
unsigned int v_blank;
struct tegra_mipi_device *mipi;
+   unsigned int pixel_rate;
 };
 
 /**
@@ -147,4 +149,7 @@ extern const struct tegra_csi_soc tegra210_csi_soc;
 #endif
 
 void tegra_csi_error_recover(struct v4l2_subdev *subdev);
+void tegra_csi_calc_settle_time(struct tegra_csi_channel *csi_chan,
+   u8 *clk_settle_time,
+   u8 *ths_settle_time);
 #endif
diff --git a/drivers/staging/media/tegra-video/tegra210.c 
b/drivers/staging/media/tegra-video/tegra210.c
index 253bf33..ac066c0 100644
--- a/drivers/staging/media/tegra-video/tegra210.c
+++ b/drivers/staging/media/tegra-video/tegra210.c
@@ -7,6 +7,7 @@
  * This source file contains Tegra210 supported video formats,
  * VI and CSI SoC specific data, operations and registers accessors.
  */

[RFC PATCH v3 05/18] i2c: tegra: Fix the error path in tegra_i2c_runtime_resume

2020-07-14 Thread Sowjanya Komatineni
tegra_i2c_runtime_resume does not disable prior enabled clocks
properly.

This patch fixes it.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/i2c/busses/i2c-tegra.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index c91307b9..7b93c45 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -665,18 +665,23 @@ static int __maybe_unused tegra_i2c_runtime_resume(struct 
device *dev)
ret = clk_enable(i2c_dev->slow_clk);
if (ret < 0) {
dev_err(dev, "failed to enable slow clock: %d\n", ret);
-   return ret;
+   goto disable_fast_clk;
}
 
ret = clk_enable(i2c_dev->div_clk);
if (ret < 0) {
dev_err(i2c_dev->dev,
"Enabling div clk failed, err %d\n", ret);
-   clk_disable(i2c_dev->fast_clk);
-   return ret;
+   goto disable_slow_clk;
}
 
return 0;
+
+disable_slow_clk:
+   clk_disable(i2c_dev->slow_clk);
+disable_fast_clk:
+   clk_disable(i2c_dev->fast_clk);
+   return ret;
 }
 
 static int __maybe_unused tegra_i2c_runtime_suspend(struct device *dev)
-- 
2.7.4



Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Oliver O'Halloran
On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann  wrote:
>
> - Most error checking is static: PCIBIOS_BAD_REGISTER_NUMBER
>   only happens if you pass an invalid register number, but most
>   callers pass a compile-time constant register number that is
>   known to be correct, or the driver would never work. Similarly,
>   PCIBIOS_DEVICE_NOT_FOUND wouldn't normally happen
>   since you pass a valid pci_device pointer that was already
>   probed.

Having some feedback about obvious programming errors is still useful
when doing driver development. Reporting those via printk() would
probably be more useful to those who care though.

> - config space accesses are very rare compared to memory
>   space access and on the hardware side the error handling
>   would be similar, but readl/writel don't return errors, they just
>   access wrong registers or return 0x.
>   arch/powerpc/kernel/eeh.c has a ton extra code written to
>   deal with it, but no other architectures do.

TBH the EEH MMIO hooks were probably a mistake to begin with. Errors
detected via MMIO are almost always asynchronous to the error itself
so you usually just wind up with a misleading stack trace rather than
any kind of useful synchronous error reporting. It seems like most
drivers don't bother checking for 0xFFs either and rely on the
asynchronous reporting via .error_detected() instead, so I have to
wonder what the point is. I've been thinking of removing the MMIO
hooks and using a background poller to check for errors on each PHB
periodically (assuming we don't have an EEH interrupt) instead. That
would remove the requirement for eeh_dev_check_failure() to be
interrupt safe too, so it might even let us fix all the godawful races
in EEH.

> - If we add code to detect errors in pci_read_config_*
>   and do some of the stuff from powerpc's
>   eeh_dev_check_failure(), we are more likely to catch
>   intermittent failures when drivers don't check, or bugs
>   with invalid arguments in device drivers than relying on
>   drivers to get their error handling right when those code
>   paths don't ever get covered in normal testing.

Adding some kind of error detection to the generic config accessors
wouldn't hurt, but detection is only half the problem. The main job of
eeh_dev_check_failure() is waking up the EEH recovery thread which
actually handles notifying drivers, device resets, etc and you'd want
something in the PCI core. Right now there's two implementations of
that reporting logic: one for EEH in arch/powerpc/eeh_driver.c and one
for AER/DPC in drivers/pci/pcie/err.c. I think the latter could be
moved into the PCI core easily enough since there's not much about it
that's really specific to PCIe. Ideally we could drop the EEH specific
one too, but I'm not sure how to implement that without it devolving
into callback spaghetti.

Oliver


[RFC PATCH v3 00/18] Support for Tegra video capture from external sensor

2020-07-14 Thread Sowjanya Komatineni
This series adds support for video capture from external camera sensor to
Tegra video driver.

Jetson TX1 has camera expansion connector and supports custom camera module
designed as per TX1 design specification.

This series also enables camera capture support for Jetson Nano which has
Raspberry PI camera header.

This series is tested with IMX219 camera sensor.

This series include,

VI I2C related fixes
- Camera sensor programming happens through VI I2C which is on host1x bus.
- These patches includes device tree and I2C driver fixes for VI I2C.

Tegra video driver updates
- TPG Vs Non-TPG based on Kconfig
- Support for external sensor video capture based on device graph from DT.
- Support for selection ioctl operations
- Tegra MIPI CSI pads calibration
- CSI T-CLK and T-HS settle time computation based on clock rates.

Host1x driver updates
- Adds API to allow creating mipi device for specific device node.
- Splits MIPI pads calibrate start and waiting for calibration to be done.

Device tree updates
- Adds camera connector 2V8, 1V8, 1V2 regulator supplies to Jetson TX1 DT.
- Enabled VI and CSI support in Jetson Nano DT.


Delta between patch versions:

[v3]:   Includes v2 feedback
- Uses separate helper function for retrieving remote csi subdevice
  and source subdevice.
- Added check for presence of subdevice ops set/get_selection
- dropped vb2_queue_release from driver and using
  vb2_video_unregister_device instead of video_unregister_device.
- video device register should happen in the last after all video
  device related setup is done in the driver. This is being addressed
  in below RFC patch. Once proper implementation of this is available
  will update Tegra video driver to use split APIs and do all setup
  prior to device register. Added this as TODO in the driver.
  https://www.spinics.net/lists/linux-media/msg172761.html

Note:
Patch-0012 has compilation dependency on
https://patchwork.kernel.org/patch/11659521/


[v2]:   Includes below changes based on v1 feedback
- dt-binding document and the driver update for device graph to use
  separate ports for sink endpoint and source endpoint for csi.
- Use data-lanes endpoint property for csi.
- Update tegra_mipi_request() to take device node pointer argument
  rather than adding extra API.
- Remove checking for clk pointer before clk_disable.


Sowjanya Komatineni (18):
  dt-bindings: i2c: tegra: Document Tegra210 VI I2C clocks and
power-domains
  arm64: tegra: Add missing clocks and power-domains to Tegra210 VI I2C
  i2c: tegra: Don't mark VI I2C as IRQ safe runtime PM
  i2c: tegra: Remove NULL pointer check before
clk_enable/disable/prepare/unprepare
  i2c: tegra: Fix the error path in tegra_i2c_runtime_resume
  i2c: tegra: Fix runtime resume to re-init VI I2C
  i2c: tegra: Avoid tegra_i2c_init_dma() for Tegra210 vi i2c
  media: tegra-video: Fix channel format alignment
  media: tegra-video: Enable TPG based on kernel config
  media: tegra-video: Update format lookup to offset based
  dt-bindings: tegra: Update VI and CSI bindings with port info
  media: tegra-video: Add support for external sensor capture
  media: tegra-video: Add support for selection ioctl ops
  gpu: host1x: mipi: Update tegra_mipi_request() to be node based
  gpu: host1x: mipi: Use readl_relaxed_poll_timeout in tegra_mipi_wait
  gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait
  media: tegra-video: Add CSI MIPI pads calibration
  media: tegra-video: Compute settle times based on the clock rate

 .../display/tegra/nvidia,tegra20-host1x.txt|  92 ++-
 .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt |  19 +-
 arch/arm64/boot/dts/nvidia/tegra210.dtsi   |   6 +
 drivers/gpu/drm/tegra/dsi.c|   9 +-
 drivers/gpu/host1x/mipi.c  |  37 +-
 drivers/i2c/busses/i2c-tegra.c | 101 +--
 drivers/staging/media/tegra-video/Kconfig  |   7 +
 drivers/staging/media/tegra-video/csi.c| 247 ++-
 drivers/staging/media/tegra-video/csi.h|   8 +
 drivers/staging/media/tegra-video/tegra210.c   |  25 +-
 drivers/staging/media/tegra-video/vi.c | 793 +++--
 drivers/staging/media/tegra-video/vi.h |  25 +-
 drivers/staging/media/tegra-video/video.c  |  23 +-
 include/linux/host1x.h |   4 +-
 14 files changed, 1242 insertions(+), 154 deletions(-)

-- 
2.7.4



[RFC PATCH v3 10/18] media: tegra-video: Update format lookup to offset based

2020-07-14 Thread Sowjanya Komatineni
Tegra VI supported video formats are more for non TPG and there
can be multiple pixel formats for the same media bus format.

This patch updates the helper function for format lookup based on
mbus code from pre-defined Tegra supported format list to look from
the specified list index offset.

Offset based look up is used with sensor device graph (non TPG)
where format enumeration can list all supported formats for the
specific sensor mbus codes.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/staging/media/tegra-video/vi.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/tegra-video/vi.c 
b/drivers/staging/media/tegra-video/vi.c
index 4ad3da5..93edade 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -53,11 +53,12 @@ to_tegra_channel_buffer(struct vb2_v4l2_buffer *vb)
 }
 
 static int tegra_get_format_idx_by_code(struct tegra_vi *vi,
-   unsigned int code)
+   unsigned int code,
+   unsigned int offset)
 {
unsigned int i;
 
-   for (i = 0; i < vi->soc->nformats; ++i) {
+   for (i = offset; i < vi->soc->nformats; ++i) {
if (vi->soc->video_formats[i].code == code)
return i;
}
@@ -598,11 +599,12 @@ static void vi_tpg_fmts_bitmap_init(struct 
tegra_vi_channel *chan)
bitmap_zero(chan->tpg_fmts_bitmap, MAX_FORMAT_NUM);
 
index = tegra_get_format_idx_by_code(chan->vi,
-MEDIA_BUS_FMT_SRGGB10_1X10);
+MEDIA_BUS_FMT_SRGGB10_1X10, 0);
bitmap_set(chan->tpg_fmts_bitmap, index, 1);
 
index = tegra_get_format_idx_by_code(chan->vi,
-MEDIA_BUS_FMT_RGB888_1X32_PADHI);
+MEDIA_BUS_FMT_RGB888_1X32_PADHI,
+0);
bitmap_set(chan->tpg_fmts_bitmap, index, 1);
 }
 
-- 
2.7.4



[RFC PATCH v3 08/18] media: tegra-video: Fix channel format alignment

2020-07-14 Thread Sowjanya Komatineni
Pixel format width is mistakenly aligned to surface align bytes
and altering width to aligned value may force sensor mode change
other than the requested one and also cause mismatch in width
programmed between sensor and vi which can lead to capture errors.

This patch removes width alignment and clamps width as per Tegra
minimum and maximum limits.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/staging/media/tegra-video/vi.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/media/tegra-video/vi.c 
b/drivers/staging/media/tegra-video/vi.c
index a3b9b21..0ae1771 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -359,25 +359,15 @@ static void tegra_channel_fmt_align(struct 
tegra_vi_channel *chan,
struct v4l2_pix_format *pix,
unsigned int bpp)
 {
-   unsigned int align;
-   unsigned int min_width;
-   unsigned int max_width;
-   unsigned int width;
unsigned int min_bpl;
unsigned int max_bpl;
unsigned int bpl;
 
/*
-* The transfer alignment requirements are expressed in bytes. Compute
-* minimum and maximum values, clamp the requested width and convert
-* it back to pixels. Use bytesperline to adjust the width.
+* The transfer alignment requirements are expressed in bytes.
+* Clamp the requested width and height to the limits.
 */
-   align = lcm(SURFACE_ALIGN_BYTES, bpp);
-   min_width = roundup(TEGRA_MIN_WIDTH, align);
-   max_width = rounddown(TEGRA_MAX_WIDTH, align);
-   width = roundup(pix->width * bpp, align);
-
-   pix->width = clamp(width, min_width, max_width) / bpp;
+   pix->width = clamp(pix->width, TEGRA_MIN_WIDTH, TEGRA_MAX_WIDTH);
pix->height = clamp(pix->height, TEGRA_MIN_HEIGHT, TEGRA_MAX_HEIGHT);
 
/* Clamp the requested bytes per line value. If the maximum bytes per
-- 
2.7.4



Re: [PATCH] cifs: Remove the superfluous break

2020-07-14 Thread Steve French
merged into cifs-2.6.git for-next

thx

On Tue, Jul 14, 2020 at 6:14 AM Yi Wang  wrote:
>
> From: Liao Pingfang 
>
> Remove the superfuous break, as there is a 'return' before it.
>
> Signed-off-by: Liao Pingfang 
> Signed-off-by: Yi Wang 
> ---
>  fs/cifs/sess.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
> index 5d05bd2..6708ab0 100644
> --- a/fs/cifs/sess.c
> +++ b/fs/cifs/sess.c
> @@ -1705,7 +1705,6 @@ static int select_sec(struct cifs_ses *ses, struct 
> sess_data *sess_data)
>  #else
> cifs_dbg(VFS, "Kerberos negotiated but upcall support 
> disabled!\n");
> return -ENOSYS;
> -   break;
>  #endif /* CONFIG_CIFS_UPCALL */
> case RawNTLMSSP:
> sess_data->func = sess_auth_rawntlmssp_negotiate;
> --
> 2.9.5
>


-- 
Thanks,

Steve


[PATCH] iio: buffer: fix attach/detach pollfunc order

2020-07-14 Thread Alexandru Ardelean
The original patch was error-ed by the submitter (me) and not by the author
(Lars).
After looking through the discussion logs (on email), it seems that this
order was wrong for the start, even though the order implemented in the
drivers was correct.

Discussions:
- first RFC: 
https://lore.kernel.org/linux-iio/20180622135322.3459-1-alexandru.ardel...@analog.com/
- 2nd patch: 
https://lore.kernel.org/linux-iio/20181219140912.22582-1-alexandru.ardel...@analog.com/
- final patch-sets:
  
https://lore.kernel.org/linux-iio/20200522104632.517470-1-alexandru.ardel...@analog.com/
  
https://lore.kernel.org/linux-iio/20200525113855.178821-1-alexandru.ardel...@analog.com/

The last one was applied.

The idea is that pollfunc should be attached before calling the
'indio_dev->setup_ops->postenable' hook and should be detached after
calling the 'indio_dev->setup_ops->predisable' hook.

While the drivers were updated to take this into account, the change to the
IIO core was somehow omitted and was made wrong.

This change fixes the order to the proper form.

Fixes f11d59d87b862: ("iio: Move attach/detach of the poll func to the core")
Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/industrialio-buffer.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/iio/industrialio-buffer.c 
b/drivers/iio/industrialio-buffer.c
index 2aec8b85f40d..a7d7e5143ed2 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -971,24 +971,29 @@ static int iio_enable_buffers(struct iio_dev *indio_dev,
goto err_disable_buffers;
}
 
+   if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
+   ret = iio_trigger_attach_poll_func(indio_dev->trig,
+  indio_dev->pollfunc);
+   if (ret)
+   goto err_disable_buffers;
+   }
+
if (indio_dev->setup_ops->postenable) {
ret = indio_dev->setup_ops->postenable(indio_dev);
if (ret) {
dev_dbg(_dev->dev,
   "Buffer not started: postenable failed (%d)\n", 
ret);
-   goto err_disable_buffers;
+   goto err_detach_pollfunc;
}
}
 
-   if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
-   ret = iio_trigger_attach_poll_func(indio_dev->trig,
-  indio_dev->pollfunc);
-   if (ret)
-   goto err_disable_buffers;
-   }
-
return 0;
 
+err_detach_pollfunc:
+   if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
+   iio_trigger_detach_poll_func(indio_dev->trig,
+indio_dev->pollfunc);
+   }
 err_disable_buffers:
list_for_each_entry_continue_reverse(buffer, 
_dev_opaque->buffer_list,
 buffer_list)
@@ -1014,11 +1019,6 @@ static int iio_disable_buffers(struct iio_dev *indio_dev)
if (list_empty(_dev_opaque->buffer_list))
return 0;
 
-   if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
-   iio_trigger_detach_poll_func(indio_dev->trig,
-indio_dev->pollfunc);
-   }
-
/*
 * If things go wrong at some step in disable we still need to continue
 * to perform the other steps, otherwise we leave the device in a
@@ -1032,6 +1032,11 @@ static int iio_disable_buffers(struct iio_dev *indio_dev)
ret = ret2;
}
 
+   if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
+   iio_trigger_detach_poll_func(indio_dev->trig,
+indio_dev->pollfunc);
+   }
+
list_for_each_entry(buffer, _dev_opaque->buffer_list, buffer_list) {
ret2 = iio_buffer_disable(buffer, indio_dev);
if (ret2 && !ret)
-- 
2.17.1



Re: [PATCH 3/3] ASoC: fsl-asoc-card: Support Headphone and Microphone Jack detection

2020-07-14 Thread Shengjiu Wang
On Wed, Jul 15, 2020 at 5:16 AM Nicolin Chen  wrote:
>
> Hi Shengjiu,
>
> The whole series looks good to me. Just a couple of small
> questions inline:
>
> On Tue, Jul 14, 2020 at 05:05:36PM +0800, Shengjiu Wang wrote:
> > Use asoc_simple_init_jack function from simple card to implement
> > the Headphone and Microphone detection.
> > Register notifier to disable Speaker when Headphone is plugged in
> > and enable Speaker when Headphone is unplugged.
> > Register notifier to disable Digital Microphone when Analog Microphone
> > is plugged in and enable DMIC when Analog Microphone is unplugged.
> >
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  sound/soc/fsl/Kconfig |  1 +
> >  sound/soc/fsl/fsl-asoc-card.c | 69 ++-
> >  2 files changed, 68 insertions(+), 2 deletions(-)
>
> >  static int fsl_asoc_card_late_probe(struct snd_soc_card *card)
> >  {
> >   struct fsl_asoc_card_priv *priv = snd_soc_card_get_drvdata(card);
> > @@ -745,8 +789,29 @@ static int fsl_asoc_card_probe(struct platform_device 
> > *pdev)
> >   snd_soc_card_set_drvdata(>card, priv);
> >
> >   ret = devm_snd_soc_register_card(>dev, >card);
> > - if (ret && ret != -EPROBE_DEFER)
> > - dev_err(>dev, "snd_soc_register_card failed (%d)\n", 
> > ret);
> > + if (ret) {
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(>dev, "snd_soc_register_card failed 
> > (%d)\n", ret);
>
> I think we may move this EPROBE_DEFER to the asrc_fail label.

If we move this to asrc_fail label, then it will be hard to define the
error message.
There are many places that goto asrc_fail.

>
> > + goto asrc_fail;
> > + }
> > +
> > + if (of_property_read_bool(np, "hp-det-gpio")) {
>
> Could we move this check inside asoc_simple_init_jack? There's no
> problem with doing it here though, yet I got a bit confused by it
> as I thought it's a boolean type property, which would be against
> the DT bindings until I saw asoc_simple_init_jack() uses the same
> string to get the GPIO. Just it probably would be a bit tricky as
> we need it to be optional here.
>
> Otherwise, I think we may add a line of comments to indicate that
> the API would use the same string to get the GPIO.

In asoc_simple_init_jack, gpio_is_valid() will be invalid when there is
no "hp-det-gpio" property, and asoc_simple_init_jack will return 0.

The reason why I add a check here is mostly for
snd_soc_jack_notifier_register().
when there is no jack created, there will be a kernel dump.

or I can use this code:

-   if (of_property_read_bool(np, "hp-det-gpio")) {
-   ret = asoc_simple_init_jack(>card, >hp_jack,
-   1, NULL, "Headphone Jack");
-   if (ret)
-   goto asrc_fail;
+   ret = asoc_simple_init_jack(>card, >hp_jack,
+   1, NULL, "Headphone Jack");
+   if (ret)
+   goto asrc_fail;

+   if (priv->hp_jack.jack.jack)
snd_soc_jack_notifier_register(>hp_jack.jack,
_jack_nb);
-   }

what do you think?

best regards
wang shengjiu


Re: [PATCH v3 2/9] powerpc/watchpoint: Fix DAWR exception constraint

2020-07-14 Thread Ravi Bangoria

Hi Jordan,


@@ -536,7 +538,12 @@ static bool check_dawrx_constraints(struct pt_regs *regs, 
int type,
 if (OP_IS_LOAD(type) && !(info->type & HW_BRK_TYPE_READ))
 return false;

-   if (OP_IS_STORE(type) && !(info->type & HW_BRK_TYPE_WRITE))
+   /*
+* The Cache Management instructions other than dcbz never
+* cause a match. i.e. if type is CACHEOP, the instruction
+* is dcbz, and dcbz is treated as Store.
+*/
+   if ((OP_IS_STORE(type) || type == CACHEOP) && !(info->type & 
HW_BRK_TYPE_WRITE))
 return false;

This change seems seperate to this commit?


I also thought about it but was not sure. See below ...



 if (is_kernel_addr(regs->nip) && !(info->type & HW_BRK_TYPE_KERNEL))
@@ -553,7 +560,8 @@ static bool check_dawrx_constraints(struct pt_regs *regs, 
int type,
   * including extraneous exception. Otherwise return false.
   */
  static bool check_constraints(struct pt_regs *regs, struct ppc_inst instr,
- int type, int size, struct arch_hw_breakpoint 
*info)
+ unsigned long ea, int type, int size,
+ struct arch_hw_breakpoint *info)
  {
 bool in_user_range = dar_in_user_range(regs->dar, info);
 bool dawrx_constraints;
@@ -569,11 +577,10 @@ static bool check_constraints(struct pt_regs *regs, 
struct ppc_inst instr,
 }

 if (unlikely(ppc_inst_equal(instr, ppc_inst(0 {
-   if (in_user_range)
-   return true;
-
-   if (dar_in_hw_range(regs->dar, info)) {
-   info->type |= HW_BRK_TYPE_EXTRANEOUS_IRQ;
+   if (cpu_has_feature(CPU_FTR_ARCH_31)) {
+   if (dar_in_hw_range(regs->dar, info))
+   return true;
+   } else {
 return true;

I think this would be clearer as:
 if (cpu_has_feature(CPU_FTR_ARCH_31) &&
!(dar_in_hw_range(regs->dar, info)))
 return false;
 else
 return true;


ok




 }
 return false;
@@ -581,10 +588,20 @@ static bool check_constraints(struct pt_regs *regs, 
struct ppc_inst instr,

 dawrx_constraints = check_dawrx_constraints(regs, type, info);

-   if (dar_user_range_overlaps(regs->dar, size, info))
+   if (type == UNKNOWN) {
+   if (cpu_has_feature(CPU_FTR_ARCH_31)) {
+   if (dar_in_hw_range(regs->dar, info))
+   return dawrx_constraints;
+   } else {
+   return dawrx_constraints;
+   }
+   return false;
+   }

Similar thing here, it could be:
 if ((cpu_has_feature(CPU_FTR_ARCH_31)) &&
!(dar_in_hw_range(regs->dar, info)))
 return false;
 else
 return dawrx_constraints;


ok


+
+   if (ea_user_range_overlaps(ea, size, info))
 return dawrx_constraints;

-   if (dar_hw_range_overlaps(regs->dar, size, info)) {
+   if (ea_hw_range_overlaps(ea, size, info)) {
 if (dawrx_constraints) {
 info->type |= HW_BRK_TYPE_EXTRANEOUS_IRQ;
 return true;
@@ -593,8 +610,17 @@ static bool check_constraints(struct pt_regs *regs, struct 
ppc_inst instr,
 return false;
  }

+static int cache_op_size(void)
+{
+#ifdef __powerpc64__
+   return ppc64_caches.l1d.block_size;
+#else
+   return L1_CACHE_BYTES;
+#endif
+}
+
  static void get_instr_detail(struct pt_regs *regs, struct ppc_inst *instr,
-int *type, int *size, bool *larx_stcx)
+int *type, int *size, unsigned long *ea)
  {
 struct instruction_op op;

@@ -602,16 +628,23 @@ static void get_instr_detail(struct pt_regs *regs, struct 
ppc_inst *instr,
 return;

 analyse_instr(, regs, *instr);
-
-   /*
-* Set size = 8 if analyse_instr() fails. If it's a userspace
-* watchpoint(valid or extraneous), we can notify user about it.
-* If it's a kernel watchpoint, instruction  emulation will fail
-* in stepping_handler() and watchpoint will be disabled.
-*/
 *type = GETTYPE(op.type);
-   *size = !(*type == UNKNOWN) ? GETSIZE(op.type) : 8;
-   *larx_stcx = (*type == LARX || *type == STCX);
+   *ea = op.ea;
+#ifdef __powerpc64__
+   if (!(regs->msr & MSR_64BIT))
+   *ea &= 0xUL;
+#endif
+
+   *size = GETSIZE(op.type);
+   if (*type == CACHEOP) {
+   *size = cache_op_size();
+   *ea &= ~(*size - 1);
+   }

Again related to CACHEOP, should these changes be mentioned in the
commit message?


For CACHEOP, ea returned by analyse_instr() needs to be aligned down to cache
block size manually. Also, for CACHEOP, size returned by analyse_instr() is 0
and thus 

Re: [f2fs-dev] [PATCH v2] f2fs: change the way of handling range.len in F2FS_IOC_SEC_TRIM_FILE

2020-07-14 Thread Daeho Jeong
We could use fscrypt_zeroout_range() for an encrypted file.
But, one problem is fscrypt_zeroout_range() assumes that filesystems
only use a single block device.
It means it doesn't receive bdev as a parameter.
How about changing the interface of fscrypt_zeroout_range() first and using it?

2020년 7월 14일 (화) 오후 9:36, Chao Yu 님이 작성:
>
> On 2020/7/14 2:11, Jaegeuk Kim wrote:
> > Hi Daeho,
> >
> > Please take a look at this.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev=35245180459aebf6d70fde88a538f0400a794aa6
>
> I'm curious about what will happen if we call
> sec_trim_file(F2FS_TRIM_FILE_ZEROOUT) on an encrypted file, will
> it use zero bits covering encrypted data on disk?
>
> Thanks,
>
> >
> > Thanks,
> >
> > On 07/13, Daeho Jeong wrote:
> >> From: Daeho Jeong 
> >>
> >> Changed the way of handling range.len of F2FS_IOC_SEC_TRIM_FILE.
> >>  1. Added -1 value support for range.len to secure trim the whole blocks
> >> starting from range.start regardless of i_size.
> >>  2. If the end of the range passes over the end of file, it means until
> >> the end of file (i_size).
> >>  3. ignored the case of that range.len is zero to prevent the function
> >> from making end_addr zero and triggering different behaviour of
> >> the function.
> >>
> >> Signed-off-by: Daeho Jeong 
> >> ---
> >> Changes in v2:
> >>  - Changed -1 range.len option to mean the whole blocks starting from
> >>range.start regardless of i_size
> >> ---
> >>  fs/f2fs/file.c | 23 ---
> >>  1 file changed, 12 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> index 368c80f8e2a1..2485841e3b2d 100644
> >> --- a/fs/f2fs/file.c
> >> +++ b/fs/f2fs/file.c
> >> @@ -3792,7 +3792,7 @@ static int f2fs_sec_trim_file(struct file *filp, 
> >> unsigned long arg)
> >>  pgoff_t index, pg_end;
> >>  block_t prev_block = 0, len = 0;
> >>  loff_t end_addr;
> >> -bool to_end;
> >> +bool to_end = false;
> >>  int ret = 0;
> >>
> >>  if (!(filp->f_mode & FMODE_WRITE))
> >> @@ -3813,23 +3813,23 @@ static int f2fs_sec_trim_file(struct file *filp, 
> >> unsigned long arg)
> >>  file_start_write(filp);
> >>  inode_lock(inode);
> >>
> >> -if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode)) {
> >> +if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode) ||
> >> +range.start >= inode->i_size) {
> >>  ret = -EINVAL;
> >>  goto err;
> >>  }
> >>
> >> -if (range.start >= inode->i_size) {
> >> -ret = -EINVAL;
> >> +if (range.len == 0)
> >>  goto err;
> >> -}
> >>
> >> -if (inode->i_size - range.start < range.len) {
> >> -ret = -E2BIG;
> >> -goto err;
> >> +if (inode->i_size - range.start > range.len) {
> >> +end_addr = range.start + range.len;
> >> +} else {
> >> +end_addr = range.len == (u64)-1 ?
> >> +sbi->sb->s_maxbytes : inode->i_size;
> >> +to_end = true;
> >>  }
> >> -end_addr = range.start + range.len;
> >>
> >> -to_end = (end_addr == inode->i_size);
> >>  if (!IS_ALIGNED(range.start, F2FS_BLKSIZE) ||
> >>  (!to_end && !IS_ALIGNED(end_addr, F2FS_BLKSIZE))) {
> >>  ret = -EINVAL;
> >> @@ -3846,7 +3846,8 @@ static int f2fs_sec_trim_file(struct file *filp, 
> >> unsigned long arg)
> >>  down_write(_I(inode)->i_gc_rwsem[WRITE]);
> >>  down_write(_I(inode)->i_mmap_sem);
> >>
> >> -ret = filemap_write_and_wait_range(mapping, range.start, end_addr - 
> >> 1);
> >> +ret = filemap_write_and_wait_range(mapping, range.start,
> >> +to_end ? LLONG_MAX : end_addr - 1);
> >>  if (ret)
> >>  goto out;
> >>
> >> --
> >> 2.27.0.383.g050319c2ae-goog
> >
> >
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> > .
> >


[PATCH 4/7] KVM: nVMX: Move free_nested() below vmx_switch_vmcs()

2020-07-14 Thread Sean Christopherson
Move free_nested() down below vmx_switch_vmcs() so that a future patch
can do an "emergency" invocation of vmx_switch_vmcs() if vmcs01 is not
the loaded VMCS when freeing nested resources.

No functional change intended.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 88 +++
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 7d4457aaab2ef..e9b27c6478da3 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -233,50 +233,6 @@ static inline void nested_release_evmcs(struct kvm_vcpu 
*vcpu)
vmx->nested.hv_evmcs = NULL;
 }
 
-/*
- * Free whatever needs to be freed from vmx->nested when L1 goes down, or
- * just stops using VMX.
- */
-static void free_nested(struct kvm_vcpu *vcpu)
-{
-   struct vcpu_vmx *vmx = to_vmx(vcpu);
-
-   if (!vmx->nested.vmxon && !vmx->nested.smm.vmxon)
-   return;
-
-   kvm_clear_request(KVM_REQ_GET_VMCS12_PAGES, vcpu);
-
-   vmx->nested.vmxon = false;
-   vmx->nested.smm.vmxon = false;
-   free_vpid(vmx->nested.vpid02);
-   vmx->nested.posted_intr_nv = -1;
-   vmx->nested.current_vmptr = -1ull;
-   if (enable_shadow_vmcs) {
-   vmx_disable_shadow_vmcs(vmx);
-   vmcs_clear(vmx->vmcs01.shadow_vmcs);
-   free_vmcs(vmx->vmcs01.shadow_vmcs);
-   vmx->vmcs01.shadow_vmcs = NULL;
-   }
-   kfree(vmx->nested.cached_vmcs12);
-   vmx->nested.cached_vmcs12 = NULL;
-   kfree(vmx->nested.cached_shadow_vmcs12);
-   vmx->nested.cached_shadow_vmcs12 = NULL;
-   /* Unpin physical memory we referred to in the vmcs02 */
-   if (vmx->nested.apic_access_page) {
-   kvm_release_page_clean(vmx->nested.apic_access_page);
-   vmx->nested.apic_access_page = NULL;
-   }
-   kvm_vcpu_unmap(vcpu, >nested.virtual_apic_map, true);
-   kvm_vcpu_unmap(vcpu, >nested.pi_desc_map, true);
-   vmx->nested.pi_desc = NULL;
-
-   kvm_mmu_free_roots(vcpu, >arch.guest_mmu, KVM_MMU_ROOTS_ALL);
-
-   nested_release_evmcs(vcpu);
-
-   free_loaded_vmcs(>nested.vmcs02);
-}
-
 static void vmx_sync_vmcs_host_state(struct vcpu_vmx *vmx,
 struct loaded_vmcs *prev)
 {
@@ -315,6 +271,50 @@ static void vmx_switch_vmcs(struct kvm_vcpu *vcpu, struct 
loaded_vmcs *vmcs)
vmx_register_cache_reset(vcpu);
 }
 
+/*
+ * Free whatever needs to be freed from vmx->nested when L1 goes down, or
+ * just stops using VMX.
+ */
+static void free_nested(struct kvm_vcpu *vcpu)
+{
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+   if (!vmx->nested.vmxon && !vmx->nested.smm.vmxon)
+   return;
+
+   kvm_clear_request(KVM_REQ_GET_VMCS12_PAGES, vcpu);
+
+   vmx->nested.vmxon = false;
+   vmx->nested.smm.vmxon = false;
+   free_vpid(vmx->nested.vpid02);
+   vmx->nested.posted_intr_nv = -1;
+   vmx->nested.current_vmptr = -1ull;
+   if (enable_shadow_vmcs) {
+   vmx_disable_shadow_vmcs(vmx);
+   vmcs_clear(vmx->vmcs01.shadow_vmcs);
+   free_vmcs(vmx->vmcs01.shadow_vmcs);
+   vmx->vmcs01.shadow_vmcs = NULL;
+   }
+   kfree(vmx->nested.cached_vmcs12);
+   vmx->nested.cached_vmcs12 = NULL;
+   kfree(vmx->nested.cached_shadow_vmcs12);
+   vmx->nested.cached_shadow_vmcs12 = NULL;
+   /* Unpin physical memory we referred to in the vmcs02 */
+   if (vmx->nested.apic_access_page) {
+   kvm_release_page_clean(vmx->nested.apic_access_page);
+   vmx->nested.apic_access_page = NULL;
+   }
+   kvm_vcpu_unmap(vcpu, >nested.virtual_apic_map, true);
+   kvm_vcpu_unmap(vcpu, >nested.pi_desc_map, true);
+   vmx->nested.pi_desc = NULL;
+
+   kvm_mmu_free_roots(vcpu, >arch.guest_mmu, KVM_MMU_ROOTS_ALL);
+
+   nested_release_evmcs(vcpu);
+
+   free_loaded_vmcs(>nested.vmcs02);
+}
+
 /*
  * Ensure that the current vmcs of the logical processor is the
  * vmcs01 of the vcpu before calling free_nested().
-- 
2.26.0



[PATCH 1/7] KVM: nVMX: Reset the segment cache when stuffing guest segs

2020-07-14 Thread Sean Christopherson
Explicitly reset the segment cache after stuffing guest segment regs in
prepare_vmcs02_rare().  Although the cache is reset when switching to
vmcs02, there is nothing that prevents KVM from re-populating the cache
prior to writing vmcs02 with vmcs12's values.  E.g. if the vCPU is
preempted after switching to vmcs02 but before prepare_vmcs02_rare(),
kvm_arch_vcpu_put() will dereference GUEST_SS_AR_BYTES via .get_cpl()
and cache the stale vmcs02 value.  While the current code base only
caches stale data in the preemption case, it's theoretically possible
future code could read a segment register during the nested flow itself,
i.e. this isn't technically illegal behavior in kvm_arch_vcpu_put(),
although it did introduce the bug.

This manifests as an unexpected nested VM-Enter failure when running
with unrestricted guest disabled if the above preemption case coincides
with L1 switching L2's CPL, e.g. when switching from a L2 vCPU at CPL3
to to a L2 vCPU at CPL0.  stack_segment_valid() will see the new SS_SEL
but the old SS_AR_BYTES and incorrectly mark the guest state as invalid
due to SS.dpl != SS.rpl.

Don't bother updating the cache even though prepare_vmcs02_rare() writes
every segment.  With unrestricted guest, guest segments are almost never
read, let alone L2 guest segments.  On the other hand, populating the
cache requires a large number of memory writes, i.e. it's unlikely to be
a net win.  Updating the cache would be a win when unrestricted guest is
not supported, as guest_state_valid() will immediately cache all segment
registers.  But, nested virtualization without unrestricted guest is
dirt slow, saving some VMREADs won't change that, and every CPU
manufactured in the last decade supports unrestricted guest.  In other
words, the extra (minor) complexity isn't worth the trouble.

Note, kvm_arch_vcpu_put() may see stale data when querying guest CPL
depending on when preemption occurs.  This is "ok" in that the usage is
imperfect by nature, i.e. it's used heuristically to improve performance
but doesn't affect functionality.  kvm_arch_vcpu_put() could be "fixed"
by also disabling preemption while loading segments, but that's
pointless and misleading as reading state from kvm_sched_{in,out}() is
guaranteed to see stale data in one form or another.  E.g. even if all
the usage of regs_avail is fixed to call kvm_register_mark_available()
after the associated state is set, the individual state might still be
stale with respect to the overall vCPU state.  I.e. making functional
decisions in an asynchronous hook is doomed from the get go.  Thankfully
KVM doesn't do that.

Fixes: de63ad4cf4973 ("KVM: X86: implement the logic for spinlock optimization")
Cc: sta...@vger.kernel.org
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 4d561edf6f9ca..3b23901b90809 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2407,6 +2407,8 @@ static void prepare_vmcs02_rare(struct vcpu_vmx *vmx, 
struct vmcs12 *vmcs12)
vmcs_writel(GUEST_TR_BASE, vmcs12->guest_tr_base);
vmcs_writel(GUEST_GDTR_BASE, vmcs12->guest_gdtr_base);
vmcs_writel(GUEST_IDTR_BASE, vmcs12->guest_idtr_base);
+
+   vmx->segment_cache.bitmask = 0;
}
 
if (!hv_evmcs || !(hv_evmcs->hv_clean_fields &
-- 
2.26.0



[PATCH 0/7] KVM: nVMX: Bug fixes and cleanup

2020-07-14 Thread Sean Christopherson
Fix for a brutal segment caching bug that manifested as random nested
VM-Enter failures when running with unrestricted guest disabled.  A few
more bug fixes and cleanups for stuff found by inspection when hunting
down the caching issue.

Sean Christopherson (7):
  KVM: nVMX: Reset the segment cache when stuffing guest segs
  KVM: nVMX: Reload vmcs01 if getting vmcs12's pages fails
  KVM: nVMX: Explicitly check for valid guest state for !unrestricted
guest
  KVM: nVMX: Move free_nested() below vmx_switch_vmcs()
  KVM: nVMX: Ensure vmcs01 is the loaded VMCS when freeing nested state
  KVM: nVMX: Drop redundant VMCS switch and free_nested() call
  KVM: nVMX: WARN on attempt to switch the currently loaded VMCS

 arch/x86/kvm/vmx/nested.c | 103 --
 arch/x86/kvm/vmx/vmx.c|   8 +--
 arch/x86/kvm/vmx/vmx.h|  10 
 3 files changed, 66 insertions(+), 55 deletions(-)

-- 
2.26.0



[PATCH 5/7] KVM: nVMX: Ensure vmcs01 is the loaded VMCS when freeing nested state

2020-07-14 Thread Sean Christopherson
Add a WARN in free_nested() to ensure vmcs01 is loaded prior to freeing
vmcs02 and friends, and explicitly switch to vmcs01 if it's not.  KVM is
supposed to keep is_guest_mode() and loaded_vmcs==vmcs02 synchronized,
but bugs happen and freeing vmcs02 while it's in use will escalate a KVM
error to a use-after-free and potentially crash the kernel.

Do the WARN and switch even in the !vmxon case to help detect latent
bugs.  free_nested() is not a hot path, and the check is cheap.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index e9b27c6478da3..5734bff1a5907 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -279,6 +279,9 @@ static void free_nested(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
 
+   if (WARN_ON_ONCE(vmx->loaded_vmcs != >vmcs01))
+   vmx_switch_vmcs(vcpu, >vmcs01);
+
if (!vmx->nested.vmxon && !vmx->nested.smm.vmxon)
return;
 
-- 
2.26.0



[PATCH 2/7] KVM: nVMX: Reload vmcs01 if getting vmcs12's pages fails

2020-07-14 Thread Sean Christopherson
Reload vmcs01 when bailing from nested_vmx_enter_non_root_mode() as KVM
expects vmcs01 to be loaded when is_guest_mode() is false.

Fixes: 671ddc700fd08 ("KVM: nVMX: Don't leak L1 MMIO regions to L2")
Cc: sta...@vger.kernel.org
Cc: Dan Cross 
Cc: Jim Mattson 
Cc: Peter Shier 
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 3b23901b90809..8cbf7bd3a7aa3 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -3345,8 +3345,10 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
prepare_vmcs02_early(vmx, vmcs12);
 
if (from_vmentry) {
-   if (unlikely(!nested_get_vmcs12_pages(vcpu)))
+   if (unlikely(!nested_get_vmcs12_pages(vcpu))) {
+   vmx_switch_vmcs(vcpu, >vmcs01);
return NVMX_VMENTRY_KVM_INTERNAL_ERROR;
+   }
 
if (nested_vmx_check_vmentry_hw(vcpu)) {
vmx_switch_vmcs(vcpu, >vmcs01);
-- 
2.26.0



[PATCH 3/7] KVM: nVMX: Explicitly check for valid guest state for !unrestricted guest

2020-07-14 Thread Sean Christopherson
Call guest_state_valid() directly instead of querying emulation_required
when checking if L1 is attempting VM-Enter with invalid guest state.
If emulate_invalid_guest_state is false, KVM will fixup segment regs to
avoid emulation and will never set emulation_required, i.e. KVM will
incorrectly miss the associated consistency checks because the nested
path stuffs segments directly into vmcs02.

Opportunsitically add Consistency Check tracing to make future debug
suck a little less.

Fixes: 2bb8cafea80bf ("KVM: vVMX: signal failure for nested VMEntry if 
emulation_required")
Fixes: 3184a995f782c ("KVM: nVMX: fix vmentry failure code when L2 state would 
require emulation")
Cc: sta...@vger.kernel.org
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c |  2 +-
 arch/x86/kvm/vmx/vmx.c|  8 ++--
 arch/x86/kvm/vmx/vmx.h| 10 ++
 3 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 8cbf7bd3a7aa3..7d4457aaab2ef 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2572,7 +2572,7 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct 
vmcs12 *vmcs12,
 * which means L1 attempted VMEntry to L2 with invalid state.
 * Fail the VMEntry.
 */
-   if (vmx->emulation_required) {
+   if (CC(!vmx_guest_state_valid(vcpu))) {
*entry_failure_code = ENTRY_FAIL_DEFAULT;
return -EINVAL;
}
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 1bb59ae5016dc..92c5f7cbf2389 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -340,7 +340,6 @@ static const struct kernel_param_ops vmentry_l1d_flush_ops 
= {
 };
 module_param_cb(vmentry_l1d_flush, _l1d_flush_ops, NULL, 0644);
 
-static bool guest_state_valid(struct kvm_vcpu *vcpu);
 static u32 vmx_segment_access_rights(struct kvm_segment *var);
 static __always_inline void vmx_disable_intercept_for_msr(unsigned long 
*msr_bitmap,
  u32 msr, int type);
@@ -1414,7 +1413,7 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
 
 static bool emulation_required(struct kvm_vcpu *vcpu)
 {
-   return emulate_invalid_guest_state && !guest_state_valid(vcpu);
+   return emulate_invalid_guest_state && !vmx_guest_state_valid(vcpu);
 }
 
 unsigned long vmx_get_rflags(struct kvm_vcpu *vcpu)
@@ -3501,11 +3500,8 @@ static bool cs_ss_rpl_check(struct kvm_vcpu *vcpu)
  * not.
  * We assume that registers are always usable
  */
-static bool guest_state_valid(struct kvm_vcpu *vcpu)
+bool __vmx_guest_state_valid(struct kvm_vcpu *vcpu)
 {
-   if (enable_unrestricted_guest)
-   return true;
-
/* real mode guest state checks */
if (!is_protmode(vcpu) || (vmx_get_rflags(vcpu) & X86_EFLAGS_VM)) {
if (!rmode_segment_valid(vcpu, VCPU_SREG_CS))
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 0d06951e607ce..467716e61292d 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -342,6 +342,16 @@ void vmx_load_mmu_pgd(struct kvm_vcpu *vcpu, unsigned long 
cr3);
 void ept_save_pdptrs(struct kvm_vcpu *vcpu);
 void vmx_get_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg);
 void vmx_set_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg);
+
+bool __vmx_guest_state_valid(struct kvm_vcpu *vcpu);
+static inline bool vmx_guest_state_valid(struct kvm_vcpu *vcpu)
+{
+   if (enable_unrestricted_guest)
+   return true;
+
+   return __vmx_guest_state_valid(vcpu);
+}
+
 u64 construct_eptp(struct kvm_vcpu *vcpu, unsigned long root_hpa);
 void update_exception_bitmap(struct kvm_vcpu *vcpu);
 void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
-- 
2.26.0



[PATCH 6/7] KVM: nVMX: Drop redundant VMCS switch and free_nested() call

2020-07-14 Thread Sean Christopherson
Remove the explicit switch to vmcs01 and the call to free_nested() in
nested_vmx_free_vcpu().  free_nested(), which is called unconditionally
by vmx_leave_nested(), ensures vmcs01 is loaded prior to freeing vmcs02
and friends.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 5734bff1a5907..66ed449f0d59f 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -326,8 +326,6 @@ void nested_vmx_free_vcpu(struct kvm_vcpu *vcpu)
 {
vcpu_load(vcpu);
vmx_leave_nested(vcpu);
-   vmx_switch_vmcs(vcpu, _vmx(vcpu)->vmcs01);
-   free_nested(vcpu);
vcpu_put(vcpu);
 }
 
-- 
2.26.0



[PATCH 7/7] KVM: nVMX: WARN on attempt to switch the currently loaded VMCS

2020-07-14 Thread Sean Christopherson
WARN if KVM attempts to switch to the currently loaded VMCS.  Now that
nested_vmx_free_vcpu() doesn't blindly call vmx_switch_vmcs(), all paths
that lead to vmx_switch_vmcs() are implicitly guarded by guest vs. host
mode, e.g. KVM should never emulate VMX instructions when guest mode is
active, and nested_vmx_vmexit() should never be called when host mode is
active.

Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 66ed449f0d59f..023055e636d61 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -258,7 +258,7 @@ static void vmx_switch_vmcs(struct kvm_vcpu *vcpu, struct 
loaded_vmcs *vmcs)
struct loaded_vmcs *prev;
int cpu;
 
-   if (vmx->loaded_vmcs == vmcs)
+   if (WARN_ON_ONCE(vmx->loaded_vmcs == vmcs))
return;
 
cpu = get_cpu();
-- 
2.26.0



[tip:irq/urgent] BUILD SUCCESS e3beca48a45b5e0e6e6a4e0124276b8248dcc9bb

2020-07-14 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
irq/urgent
branch HEAD: e3beca48a45b5e0e6e6a4e0124276b8248dcc9bb  irqdomain/treewide: Keep 
firmware node unconditionally allocated

elapsed time: 727m

configs tested: 129
configs skipped: 7

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
sh   se7724_defconfig
sh  sdk7786_defconfig
arm  tango4_defconfig
shmigor_defconfig
i386 allyesconfig
arm s3c6400_defconfig
m68k amcore_defconfig
c6x   allnoconfig
xtensageneric_kc705_defconfig
mips   ip27_defconfig
mips  mips_paravirt_defconfig
c6xevmc6474_defconfig
powerpc  pasemi_defconfig
shdreamcast_defconfig
openrisc alldefconfig
m68km5407c3_defconfig
arm  ep93xx_defconfig
arm  moxart_defconfig
sparc   defconfig
mipsmaltaup_defconfig
mips  rb532_defconfig
powerpcmpc7448_hpc2_defconfig
mipsnlm_xlp_defconfig
arm pxa_defconfig
m68km5307c3_defconfig
m68k  amiga_defconfig
sh kfr2r09-romimage_defconfig
openriscdefconfig
xtensa  iss_defconfig
arm  colibri_pxa270_defconfig
ia64  gensparse_defconfig
armclps711x_defconfig
sh  landisk_defconfig
arm assabet_defconfig
mips decstation_r4k_defconfig
i386  allnoconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
c6x  allyesconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a001-20200714
i386 randconfig-a005-20200714
i386 randconfig-a002-20200714
i386 randconfig-a006-20200714
i386 randconfig-a003-20200714
i386 randconfig-a004-20200714
x86_64   randconfig-a012-20200714
x86_64   randconfig-a011-20200714
x86_64   randconfig-a016-20200714
x86_64   randconfig-a014-20200714
x86_64   randconfig-a013-20200714
x86_64   randconfig-a015-20200714
i386 randconfig-a016-20200714
i386 randconfig-a011-20200714
i386

Re: [PATCH v3] scsi: ufs: Cleanup completed request without interrupt notification

2020-07-14 Thread Bart Van Assche
On 2020-07-13 01:10, Avri Altman wrote:
> Artificially injecting errors is a very common validation mechanism,
> Provided that you are not breaking anything of the upper-layers,
> Which I don't think you are doing.

Hi Avri,

My concern is that the code that is being added in the abort handler
sooner or later will evolve into a duplicate of the regular completion
path. Wouldn't it be better to poll for completions from the timeout
handler by calling ufshcd_transfer_req_compl() instead of duplicating
that function?

>>> In section 7.2.3 of the UFS specification I found the following about how
>>> to process request completions: "Software determines if new TRs have
>>> completed since step #2, by repeating one of the two methods described in
>>> step #2. If new TRs have completed, software repeats the sequence from
>>> step #3." Is such a loop perhaps missing from the Linux UFS driver?
>
> Could not find that citation.
> What version of the spec are you using?

That quote comes from the following document: "Universal Flash Storage
Host Controller Interface (UFSHCI); Version 2.1; JESD223C; (Revision of
JESD223B, September 2013); MARCH 2016".

Bart.



Re: [PATCH] powerpc: Fix inconsistent function names

2020-07-14 Thread Michael Ellerman
YueHaibing  writes:

> The stub helpers name should be consistent with prototypes.
>
> mm_context_add_vas_windows() --> mm_context_add_vas_window()
> mm_context_remove_vas_windows() --> mm_context_remove_vas_window()
>
> Fixes: c420644c0a8f ("powerpc: Use mm_context vas_windows counter to issue 
> CP_ABORT")
> Signed-off-by: YueHaibing 
> ---
>  arch/powerpc/include/asm/mmu_context.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h 
> b/arch/powerpc/include/asm/mmu_context.h
> index 1a474f6b1992..00fd1d44731a 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -218,8 +218,8 @@ static inline void inc_mm_active_cpus(struct mm_struct 
> *mm) { }
>  static inline void dec_mm_active_cpus(struct mm_struct *mm) { }
>  static inline void mm_context_add_copro(struct mm_struct *mm) { }
>  static inline void mm_context_remove_copro(struct mm_struct *mm) { }
> -static inline void mm_context_add_vas_windows(struct mm_struct *mm) { }
> -static inline void mm_context_remove_vas_windows(struct mm_struct *mm) { }
> +static inline void mm_context_add_vas_window(struct mm_struct *mm) { }
> +static inline void mm_context_remove_vas_window(struct mm_struct *mm) { }
>  #endif

Both of those functions are only called from 64-bit only code, so the
stubs should not be needed at all. Which explains why we haven't seen a
build break.

So just dropping them would be better IMO.

cheers


RE: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible code

2020-07-14 Thread Tuong Tong Lien


> -Original Message-
> From: Zhang, Qiang 
> Sent: Wednesday, July 15, 2020 9:13 AM
> To: Eric Dumazet ; jma...@redhat.com; 
> da...@davemloft.net; k...@kernel.org; Tuong Tong Lien
> ; Xue, Ying 
> Cc: net...@vger.kernel.org; tipc-discuss...@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org
> Subject: 回复: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible 
> code
> 
> 
> 
> 
> 发件人: Eric Dumazet 
> 发送时间: 2020年7月14日 22:15
> 收件人: Zhang, Qiang; jma...@redhat.com; da...@davemloft.net; k...@kernel.org; 
> tuong.t.l...@dektech.com.au;
> eric.duma...@gmail.com; Xue, Ying
> 抄送: net...@vger.kernel.org; tipc-discuss...@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org
> 主题: Re: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible code
> 
> 
> 
> On 7/14/20 1:05 AM, qiang.zh...@windriver.com wrote:
> > From: Zhang Qiang 
> >
> > CPU: 0 PID: 6801 Comm: syz-executor201 Not tainted 5.8.0-rc4-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > BIOS Google 01/01/2011
> >
> > Fixes: fc1b6d6de2208 ("tipc: introduce TIPC encryption & authentication")
> > Reported-by: syzbot+263f8c0d007dc09b2...@syzkaller.appspotmail.com
> > Signed-off-by: Zhang Qiang 
> > ---
> >  v1->v2:
> >  add fixes tags.
> >
> >  net/tipc/crypto.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
> > index 8c47ded2edb6..520af0afe1b3 100644
> > --- a/net/tipc/crypto.c
> > +++ b/net/tipc/crypto.c
> > @@ -399,9 +399,10 @@ static void tipc_aead_users_set(struct tipc_aead __rcu 
> > *aead, int val)
> >   */
> >  static struct crypto_aead *tipc_aead_tfm_next(struct tipc_aead *aead)
> >  {
> > - struct tipc_tfm **tfm_entry = this_cpu_ptr(aead->tfm_entry);
> > + struct tipc_tfm **tfm_entry = get_cpu_ptr(aead->tfm_entry);
> >
> >   *tfm_entry = list_next_entry(*tfm_entry, list);
> > + put_cpu_ptr(tfm_entry);
> >   return (*tfm_entry)->tfm;
> >  }
> >
> >
> 
> > You have not explained why this was safe.
> >
> >  This seems to hide a real bug.
> >
> > Presumably callers of this function should have disable preemption, and 
> > maybe > interrupts as well.
> >
> >Right after put_cpu_ptr(tfm_entry), this thread could migrate to another 
> >cpu, >and still access
> >data owned by the old cpu.
> 
> Thanks for you suggest, I will check code again.
> 

Actually, last week I sent a similar patch to tipc-discussion which covers the
case as well (there is also another place causing the same issue...). If you
don't mind, you can take a look at below (just copied/pasted).

BR/Tuong

-Original Message-
From: Tuong Tong Lien  
Sent: Friday, July 10, 2020 5:11 PM
To: jma...@redhat.com; ma...@donjonn.com; ying@windriver.com; 
tipc-discuss...@lists.sourceforge.net
Cc: tipc-dek 
Subject: [PATCH RFC 1/5] tipc: fix using smp_processor_id() in preemptible

The 'this_cpu_ptr()' is used to obtain the AEAD key' TFM on the current
CPU for encryption, however the execution can be preemptible since it's
actually user-space context, so the 'using smp_processor_id() in
preemptible' has been observed.

We fix the issue by using the 'get/put_cpu_ptr()' API which consists of
a 'preempt_disable()' instead.

Signed-off-by: Tuong Lien 
---
 net/tipc/crypto.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index c8c47fc72653..1827ce4fac5d 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -326,7 +326,8 @@ static void tipc_aead_free(struct rcu_head *rp)
if (aead->cloned) {
tipc_aead_put(aead->cloned);
} else {
-   head = *this_cpu_ptr(aead->tfm_entry);
+   head = *get_cpu_ptr(aead->tfm_entry);
+   put_cpu_ptr(aead->tfm_entry);
list_for_each_entry_safe(tfm_entry, tmp, >list, list) {
crypto_free_aead(tfm_entry->tfm);
list_del(_entry->list);
@@ -399,10 +400,15 @@ static void tipc_aead_users_set(struct tipc_aead __rcu 
*aead, int val)
  */
 static struct crypto_aead *tipc_aead_tfm_next(struct tipc_aead *aead)
 {
-   struct tipc_tfm **tfm_entry = this_cpu_ptr(aead->tfm_entry);
+   struct tipc_tfm **tfm_entry;
+   struct crypto_aead *tfm;
 
+   tfm_entry = get_cpu_ptr(aead->tfm_entry);
*tfm_entry = list_next_entry(*tfm_entry, list);
-   return (*tfm_entry)->tfm;
+   tfm = (*tfm_entry)->tfm;
+   put_cpu_ptr(tfm_entry);
+
+   return tfm;
 }
 
 /**
-- 
2.13.7


  1   2   3   4   5   6   7   8   9   10   >