Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers

[Greg Kroah-Hartman]

On Mon, Jun 08, 2020 at 11:29:58AM -0700, Jesse Barnes wrote:
> > Now, as to you all getting some sort of "Hardware flag" to determine
> > "inside" vs. "outside" devices, hah, good luck!  It took us a long time
> > to get that for USB, and even then, BIOSes lie and get it wrong all the
> > time.  So you will have to also deal with that in some way, for your
> > userspace policy.
> 
> I think that's inherently platform specific to some extent.  We can do
> it with our coreboot based firmware, but there's no guarantee other
> vendors will adopt the same approach.  But I think at least for the
> ChromeOS ecosystem we can come up with something that'll work, and
> allow us to dtrt in userspace wrt driver binding.

Why not work with the UEFI group to add this to their spec so that it
will work for all future firmware releases, not just your
vendor-specific one?  :)

thanks,

greg k-h

Re: [PATCH] vhost/test: fix up after API change

[Jason Wang]

On 2020/6/9 下午1:53, Jason Wang wrote:


On 2020/6/8 下午8:42, Michael S. Tsirkin wrote:

Pass a flag to request kernel thread use.

Fixes: 01fcb1cbc88e ("vhost: allow device that does not depend on 
vhost worker")

Signed-off-by: Michael S. Tsirkin 
---
  drivers/vhost/test.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index f55cb584b84a..12304eb8da15 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -122,7 +122,7 @@ static int vhost_test_open(struct inode *inode, 
struct file *f)

  vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
  n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
  vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV + 64,
-   VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT, NULL);
+   VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT, true, NULL);
    f->private_data = n;



Acked-by: Jason Wang 

Just to confirm, have you queued the doorbell mapping patches already? 
Or you expect I squash this into v2 of doorbell mapping series?



Ok, I saw the patches in your linux-next branch.

Thanks




Thanks

Re: [PATCH 5/6] vdpa: introduce virtio pci driver

[Jason Wang]

On 2020/6/8 下午9:29, Michael S. Tsirkin wrote:

On Mon, Jun 08, 2020 at 06:07:36PM +0800, Jason Wang wrote:

On 2020/6/8 下午5:54, Michael S. Tsirkin wrote:

On Mon, Jun 08, 2020 at 05:46:52PM +0800, Jason Wang wrote:

On 2020/6/8 下午5:45, Michael S. Tsirkin wrote:

On Mon, Jun 08, 2020 at 05:43:58PM +0800, Jason Wang wrote:

Looking at
pci_match_one_device() it checks both subvendor and subdevice there.

Thanks

But IIUC there is no guarantee that driver with a specific subvendor
matches in presence of a generic one.
So either IFC or virtio pci can win, whichever binds first.

I'm not sure I get there. But I try manually bind IFCVF to qemu's
virtio-net-pci, and it fails.

Thanks

Right but the reverse can happen: virtio-net can bind to IFCVF first.

That's kind of expected. The PF is expected to be bound to virtio-pci to
create VF via sysfs.

Thanks




Once VFs are created, don't we want IFCVF to bind rather than
virtio-pci?


Yes, but for PF we need virtio-pci.

Thanks


(Ab)using the driver_data field for this is an option.
What do you think?



Maybe you can elaborate more on this idea?

Thanks

Re: [PATCH] vhost/test: fix up after API change

[Jason Wang]

On 2020/6/8 下午8:42, Michael S. Tsirkin wrote:

Pass a flag to request kernel thread use.

Fixes: 01fcb1cbc88e ("vhost: allow device that does not depend on vhost worker")
Signed-off-by: Michael S. Tsirkin 
---
  drivers/vhost/test.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index f55cb584b84a..12304eb8da15 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -122,7 +122,7 @@ static int vhost_test_open(struct inode *inode, struct file 
*f)
vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV + 64,
-  VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT, NULL);
+  VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT, true, NULL);
  
  	f->private_data = n;
  



Acked-by: Jason Wang 

Just to confirm, have you queued the doorbell mapping patches already? 
Or you expect I squash this into v2 of doorbell mapping series?


Thanks

Re: [PATCH] powerpc/kprobes: Use probe_address() to read instructions

[Christoph Hellwig]

On Tue, Jun 09, 2020 at 03:28:38PM +1000, Michael Ellerman wrote:
> On Mon, 24 Feb 2020 18:02:10 + (UTC), Christophe Leroy wrote:
> > In order to avoid Oopses, use probe_address() to read the
> > instruction at the address where the trap happened.
> 
> Applied to powerpc/next.
> 
> [1/1] powerpc/kprobes: Use probe_address() to read instructions
>   
> https://git.kernel.org/powerpc/c/9ed5df69b79a22b40b20bc2132ba2495708b19c4

probe_addresss has been renamed to get_kernel_nofault in the -mm
queue that Andrew sent off to Linus last night.

Re: [PATCH] USB: gadget: serial: fix null pointer access in tty_wakeup()

[Jiri Slaby]

On 09. 06. 20, 7:00, Kyungtae Kim wrote:
> FuzzUSB (a variant of syzkaller) found an illegal memory access
> while finalizing an enumeration for a serial (acm) gadget.
> 
> Reference: https://lkml.org/lkml/2020/6/7/3
> 
> The bug arises because of accessing null instance of tty_struct 
> during USB enumeration phase i.e., set_config().
> 
> Although port->port.tty in gs_start_io() becomes null after gs_close() in 
> a separate syscall context, this tries to accesss its field (tty->flags) 
> in the following tty_wakeup(), which triggers the corruption.
> 
> The fix checks if port->port.tty is still valid before being used 
> in tty_wakeup().
...> Signed-off-by: Kyungtae Kim 
> Reported-by: Kyungtae Kim 
> 
> ---
>  drivers/usb/gadget/function/u_serial.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/function/u_serial.c 
> b/drivers/usb/gadget/function/u_serial.c
> index 8167d379e115..cf4f876783d3 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -561,7 +561,7 @@ static int gs_start_io(struct gs_port *port)
>   port->n_read = 0;
>   started = gs_start_rx(port);
>  
> - if (started) {
> + if (started && port->port.tty != NULL) {

Could you explain, what prevents port->port.tty to be non-NULL on the
lines below? As far as I can see, port->port.count is set to zero at the
same place as "port->port.tty = NULL;" in gs_close. And port->port.count
is tested in the gs_start_io's caller, i.e. in gserial_connect. All this
happens under port->port_lock.

>   gs_start_tx(port);
>   /* Unblock any pending writes into our circular buffer, in case
>* we didn't in gs_start_tx() */

If it is a race, it will still race, only the race window would be
smaller. Or am I missing something?

The whole use of port->port.tty looks suspicious in the driver. It might
work as port->port_lock at places. But converting the uses to
tty_port_tty_set & tty_port_tty_get should fix also this problem. And
tty_port_tty_wakeup in this particular situation you are fixing. (And to
tty_port_open/close in the long run.)

thanks,
-- 
js
suse labs

Re: next-0519 on thinkpad x60: sound related? window manager crash

[Christoph Hellwig]

On Mon, Jun 08, 2020 at 07:31:47PM -0700, David Rientjes wrote:
> On Mon, 8 Jun 2020, Alex Xu (Hello71) wrote:
> 
> > Excerpts from Christoph Hellwig's message of June 8, 2020 2:19 am:
> > > Can you do a listing using gdb where this happens?
> > > 
> > > gdb vmlinux
> > > 
> > > l *(snd_pcm_hw_params+0x3f3)
> > > 
> > > ?
> > > 
> > 
> > (gdb) l *(snd_pcm_hw_params+0x3f3)
> > 0x817efc85 is in snd_pcm_hw_params 
> > (.../linux/sound/core/pcm_native.c:749).
> > 744 while (runtime->boundary * 2 <= LONG_MAX - 
> > runtime->buffer_size)
> > 745 runtime->boundary *= 2;
> > 746
> > 747 /* clear the buffer for avoiding possible kernel info leaks 
> > */
> > 748 if (runtime->dma_area && !substream->ops->copy_user)
> > 749 memset(runtime->dma_area, 0, runtime->dma_bytes);
> > 750
> > 751 snd_pcm_timer_resolution_change(substream);
> > 752 snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
> > 753
> > 
> 
> Working theory is that CONFIG_DMA_NONCOHERENT_MMAP getting set is causing 
> the error_code in the page fault path.  Debugging with Alex off-thread we 
> found that dma_{alloc,free}_from_pool() are not getting called from the 
> new code in dma_direct_{alloc,free}_pages() and he has not enabled 
> mem_encrypt.

While DMA_COHERENT_POOL absolutely should not select DMA_NONCOHERENT_MMAP
(and you should send your patch either way), I don't think it is going
to make a difference here, as DMA_NONCOHERENT_MMAP just means we
allows mmaps even for non-coherent devices, and we do not support
non-coherent devices on x86.

>From the disassembly it seems like a vmalloc allocation is NULL, which
seems really weird as this patch shouldn't make a difference for them,
and I also only see a single places that allocates the field, and that
checks for an allocation failure.  But the sound code is a little
hard to unwind sometimes.

Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_*

[Christoph Hellwig]

On Mon, Jun 08, 2020 at 10:38:02PM -0700, Christoph Hellwig wrote:
> On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote:
> > Yeah, the pfn_valid check is a bit weird by definition because we are
> > using it to understand whether the address belong to us or to another
> > VM. To do the pfn_valid check we need to translate the dma address into
> > something the CPU understands, hence, the dma_to_phys call.
> > 
> > Why can't we use the already-provided paddr? Because paddr has been
> > translated twice:
> > 1) from dma to maybe-foreign phys address (could be ours, or another VM)
> > 2) from maybe-foreign address to local (using our local mapping of the 
> > foreign page)
> > 
> > In fact, it would be clearer if we had all three addresses as parameters
> > of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical
> > address (we tend to call it xenbus address, baddr), the local physical
> > address. Something like:
> 
> I think instead we should move the arch_sync_dma_for_{device,cpu}
> calls from xen_dma_sync_for_{device,cpu} into the callers, as they
> are provided by the generic dma-noncoherent.h and optimized out for
> coherent architectures like x86.  Then the swiotlb-xen.c code only
> need to call dma_cache_maint as the interface (which would have to
> grow a better name), which should then only need a single kind of
> address.

... actually I'd keep the xen_dma_sync_for_{device,cpu} names for the
low-level interface, just move the arch_sync_dma_for_{device,cpu}
calls up.

Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_*

[Christoph Hellwig]

On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote:
> Yeah, the pfn_valid check is a bit weird by definition because we are
> using it to understand whether the address belong to us or to another
> VM. To do the pfn_valid check we need to translate the dma address into
> something the CPU understands, hence, the dma_to_phys call.
> 
> Why can't we use the already-provided paddr? Because paddr has been
> translated twice:
> 1) from dma to maybe-foreign phys address (could be ours, or another VM)
> 2) from maybe-foreign address to local (using our local mapping of the 
> foreign page)
> 
> In fact, it would be clearer if we had all three addresses as parameters
> of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical
> address (we tend to call it xenbus address, baddr), the local physical
> address. Something like:

I think instead we should move the arch_sync_dma_for_{device,cpu}
calls from xen_dma_sync_for_{device,cpu} into the callers, as they
are provided by the generic dma-noncoherent.h and optimized out for
coherent architectures like x86.  Then the swiotlb-xen.c code only
need to call dma_cache_maint as the interface (which would have to
grow a better name), which should then only need a single kind of
address.

mmotm 2020-06-08-22-35 uploaded

[Andrew Morton]

The mm-of-the-moment snapshot 2020-06-08-22-35 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.7:
(patches marked "*" will be included in linux-next)

  origin.patch
* kallsyms-printk-add-loglvl-to-print_ip_sym.patch
* alpha-add-show_stack_loglvl.patch
* arc-add-show_stack_loglvl.patch
* arm-asm-add-loglvl-to-c_backtrace.patch
* arm-add-loglvl-to-unwind_backtrace.patch
* arm-add-loglvl-to-dump_backtrace.patch
* arm-wire-up-dump_backtrace_entrystm.patch
* arm-add-show_stack_loglvl.patch
* arm64-add-loglvl-to-dump_backtrace.patch
* arm64-add-show_stack_loglvl.patch
* c6x-add-show_stack_loglvl.patch
* csky-add-show_stack_loglvl.patch
* h8300-add-show_stack_loglvl.patch
* hexagon-add-show_stack_loglvl.patch
* ia64-pass-log-level-as-arg-into-ia64_do_show_stack.patch
* ia64-add-show_stack_loglvl.patch
* m68k-add-show_stack_loglvl.patch
* microblaze-add-loglvl-to-microblaze_unwind_inner.patch
* microblaze-add-loglvl-to-microblaze_unwind.patch
* microblaze-add-show_stack_loglvl.patch
* mips-add-show_stack_loglvl.patch
* nds32-add-show_stack_loglvl.patch
* nios2-add-show_stack_loglvl.patch
* openrisc-add-show_stack_loglvl.patch
* parisc-add-show_stack_loglvl.patch
* powerpc-add-show_stack_loglvl.patch
* riscv-add-show_stack_loglvl.patch
* s390-add-show_stack_loglvl.patch
* sh-add-loglvl-to-dump_mem.patch
* sh-remove-needless-printk.patch
* sh-add-loglvl-to-printk_address.patch
* sh-add-loglvl-to-show_trace.patch
* sh-add-show_stack_loglvl.patch
* sparc-add-show_stack_loglvl.patch
* um-sysrq-remove-needless-variable-sp.patch
* um-add-show_stack_loglvl.patch
* unicore32-remove-unused-pmode-argument-in-c_backtrace.patch
* unicore32-add-loglvl-to-c_backtrace.patch
* unicore32-add-show_stack_loglvl.patch
* x86-add-missing-const-qualifiers-for-log_lvl.patch
* x86-add-show_stack_loglvl.patch
* xtensa-add-loglvl-to-show_trace.patch
* xtensa-add-show_stack_loglvl.patch
* sysrq-use-show_stack_loglvl.patch
* x86-amd_gart-print-stacktrace-for-a-leak-with-kern_err.patch
* power-use-show_stack_loglvl.patch
* kdb-dont-play-with-console_loglevel.patch
* sched-print-stack-trace-with-kern_info.patch
* kernel-use-show_stack_loglvl.patch
* kernel-rename-show_stack_loglvl-=-show_stack.patch
* mm-dont-include-asm-pgtableh-if-linux-mmh-is-already-included.patch
* mm-introduce-include-linux-pgtableh.patch
* mm-reorder-includes-after-introduction-of-linux-pgtableh.patch
* csky-replace-definitions-of-__pxd_offset-with-pxd_index.patch
* m68k-mm-motorola-move-comment-about-page-table-allocation-funcitons.patch
* m68k-mm-move-cachenocahe_page-definitions-close-to-their-user.patch
* x86-mm-simplify-init_trampoline-and-surrounding-logic.patch
* mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte.patch
* mm-consolidate-pte_index-and-pte_offset_-definitions.patch
* mmap-locking-api-initial-implementation-as-rwsem-wrappers.patch
* mmu-notifier-use-the-new-mmap-locking-api.patch
* dma-reservations-use-the-new-mmap-locking-api.patch
* mmap-locking-api-use-coccinelle-to-convert-mmap_sem-rwsem-call-sites.patch
* mmap-locking-api-convert-mmap_sem-call-sites-missed-by-coccinelle.patch
* mmap-locking-api-convert-nested-write-lock-sites.patch
* mmap-locking-api-add-mmap_read_trylock_non_owner.patch
* mmap-locking-api-add-mmap_lock_initializer.patch
* mmap-locking-api-add-mmap_assert_locked-and-mmap_assert_write_locked.patch
* mmap-locking-api-rename-mmap_sem-to-mmap_lock.patch
* mmap-locking-api-convert-mmap_sem-api-comments.patch
* mmap-locking-api-convert-mmap_sem-comments.patch
* 

[PATCH 2/2] perf parse-events: fix an old style declaration

[Ian Rogers]

Fixes: a26e47162d76 (perf tools: Move ALLOC_LIST into a function)
Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.y | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index d4e076c9c2ab..acef87d9af58 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -26,7 +26,7 @@ do { \
YYABORT; \
 } while (0)
 
-static struct list_head* alloc_list()
+static struct list_head* alloc_list(void)
 {
struct list_head *list;
 
-- 
2.27.0.278.ge193c7cf3a9-goog

[PATCH 1/2] perf parse-events: fix an incompatible pointer

[Ian Rogers]

Arrays are pointer types and don't need their address taking.
Fixes: 8255718f4bed (perf pmu: Expand PMU events by prefix match)

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.y | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index c4ca932d092d..d4e076c9c2ab 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -349,7 +349,7 @@ PE_PMU_EVENT_PRE '-' PE_PMU_EVENT_SUF sep_dc
struct list_head *list;
char pmu_name[128];
 
-   snprintf(_name, 128, "%s-%s", $1, $3);
+   snprintf(pmu_name, sizeof(pmu_name), "%s-%s", $1, $3);
free($1);
free($3);
if (parse_events_multi_pmu_add(_parse_state, pmu_name, ) < 0)
-- 
2.27.0.278.ge193c7cf3a9-goog

mmotm 2020-06-08-22-33 uploaded

[Andrew Morton]

The mm-of-the-moment snapshot 2020-06-08-22-33 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.7:
(patches marked "*" will be included in linux-next)

  origin.patch
* kallsyms-printk-add-loglvl-to-print_ip_sym.patch
* alpha-add-show_stack_loglvl.patch
* arc-add-show_stack_loglvl.patch
* arm-asm-add-loglvl-to-c_backtrace.patch
* arm-add-loglvl-to-unwind_backtrace.patch
* arm-add-loglvl-to-dump_backtrace.patch
* arm-wire-up-dump_backtrace_entrystm.patch
* arm-add-show_stack_loglvl.patch
* arm64-add-loglvl-to-dump_backtrace.patch
* arm64-add-show_stack_loglvl.patch
* c6x-add-show_stack_loglvl.patch
* csky-add-show_stack_loglvl.patch
* h8300-add-show_stack_loglvl.patch
* hexagon-add-show_stack_loglvl.patch
* ia64-pass-log-level-as-arg-into-ia64_do_show_stack.patch
* ia64-add-show_stack_loglvl.patch
* m68k-add-show_stack_loglvl.patch
* microblaze-add-loglvl-to-microblaze_unwind_inner.patch
* microblaze-add-loglvl-to-microblaze_unwind.patch
* microblaze-add-show_stack_loglvl.patch
* mips-add-show_stack_loglvl.patch
* nds32-add-show_stack_loglvl.patch
* nios2-add-show_stack_loglvl.patch
* openrisc-add-show_stack_loglvl.patch
* parisc-add-show_stack_loglvl.patch
* powerpc-add-show_stack_loglvl.patch
* riscv-add-show_stack_loglvl.patch
* s390-add-show_stack_loglvl.patch
* sh-add-loglvl-to-dump_mem.patch
* sh-remove-needless-printk.patch
* sh-add-loglvl-to-printk_address.patch
* sh-add-loglvl-to-show_trace.patch
* sh-add-show_stack_loglvl.patch
* sparc-add-show_stack_loglvl.patch
* um-sysrq-remove-needless-variable-sp.patch
* um-add-show_stack_loglvl.patch
* unicore32-remove-unused-pmode-argument-in-c_backtrace.patch
* unicore32-add-loglvl-to-c_backtrace.patch
* unicore32-add-show_stack_loglvl.patch
* x86-add-missing-const-qualifiers-for-log_lvl.patch
* x86-add-show_stack_loglvl.patch
* xtensa-add-loglvl-to-show_trace.patch
* xtensa-add-show_stack_loglvl.patch
* sysrq-use-show_stack_loglvl.patch
* x86-amd_gart-print-stacktrace-for-a-leak-with-kern_err.patch
* power-use-show_stack_loglvl.patch
* kdb-dont-play-with-console_loglevel.patch
* sched-print-stack-trace-with-kern_info.patch
* kernel-use-show_stack_loglvl.patch
* kernel-rename-show_stack_loglvl-=-show_stack.patch
* mm-dont-include-asm-pgtableh-if-linux-mmh-is-already-included.patch
* mm-introduce-include-linux-pgtableh.patch
* mm-reorder-includes-after-introduction-of-linux-pgtableh.patch
* csky-replace-definitions-of-__pxd_offset-with-pxd_index.patch
* m68k-mm-motorola-move-comment-about-page-table-allocation-funcitons.patch
* m68k-mm-move-cachenocahe_page-definitions-close-to-their-user.patch
* x86-mm-simplify-init_trampoline-and-surrounding-logic.patch
* mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte.patch
* mm-consolidate-pte_index-and-pte_offset_-definitions.patch
* mmap-locking-api-initial-implementation-as-rwsem-wrappers.patch
* mmu-notifier-use-the-new-mmap-locking-api.patch
* dma-reservations-use-the-new-mmap-locking-api.patch
* mmap-locking-api-use-coccinelle-to-convert-mmap_sem-rwsem-call-sites.patch
* mmap-locking-api-convert-mmap_sem-call-sites-missed-by-coccinelle.patch
* mmap-locking-api-convert-nested-write-lock-sites.patch
* mmap-locking-api-add-mmap_read_trylock_non_owner.patch
* mmap-locking-api-add-mmap_lock_initializer.patch
* mmap-locking-api-add-mmap_assert_locked-and-mmap_assert_write_locked.patch
* mmap-locking-api-rename-mmap_sem-to-mmap_lock.patch
* mmap-locking-api-convert-mmap_sem-api-comments.patch
* mmap-locking-api-convert-mmap_sem-comments.patch
* 

Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations

[Christoph Hellwig]

On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote:
> I understand what you are suggesting about having something like:
> 
> xen_phys_to_dma(...)
> {
> phys_addr_t phys = xen_phys_to_bus(dev, paddr)
> return phys_to_dma(phys);
> }
> 
> I thought about it myself. I'll do it.

"something", yes. Except that I think the bus is a little confusing,
isn't it?  What is the Xen term for these addresses?  Also we probably
don't need the extra local variable.

> But I don't think I understood the comment about XEN_PFN_PHYS.

There is a comment above xen_phys_to_bus that it avoids using
XEN_PFN_PHYS because XEN_PFN_PHYS of the phys_addr_t vs dma_addr_t
mismatch.  But XEN_PFN_PHYS could just use a u64 instead of the
phys_addr_t and then we could use it.   Especially as XEN_PFN_PHYS
isn't actually used anywhere except in swiotlb-xen.c.  Or we could
remove XEN_PFN_PHYS enirely, as it isn't all that useful to start
with.

Re: [PATCH v2 1/1] powerpc/crash: Use NMI context for printk when starting to crash

[Michael Ellerman]

On Tue, 12 May 2020 18:45:35 -0300, Leonardo Bras wrote:
> Currently, if printk lock (logbuf_lock) is held by other thread during
> crash, there is a chance of deadlocking the crash on next printk, and
> blocking a possibly desired kdump.
> 
> At the start of default_machine_crash_shutdown, make printk enter
> NMI context, as it will use per-cpu buffers to store the message,
> and avoid locking logbuf_lock.

Applied to powerpc/next.

[1/1] powerpc/crash: Use NMI context for printk when starting to crash
  https://git.kernel.org/powerpc/c/af2876b501e42c3fb5174cac9dd02598436f0fdf

cheers

Re: [PATCH v6 0/2] Implement reentrant rtas call

[Michael Ellerman]

On Mon, 18 May 2020 20:42:43 -0300, Leonardo Bras wrote:
> Patch 2 implement rtas_call_reentrant() for reentrant rtas-calls:
> "ibm,int-on", "ibm,int-off",ibm,get-xive" and  "ibm,set-xive",
> according to LoPAPR Version 1.1 (March 24, 2016).
> 
> For that, it's necessary that every call uses a different
> rtas buffer (rtas_args). Paul Mackerras suggested using the PACA
> structure for creating a per-cpu buffer for these calls.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/rtas: Move type/struct definitions from rtas.h into rtas-types.h
  https://git.kernel.org/powerpc/c/783a015b747f606e803b798eb8b50c73c548691d
[2/2] powerpc/rtas: Implement reentrant rtas call
  https://git.kernel.org/powerpc/c/b664db8e3f976d9233cc9ea5e3f8a8c0bcabeb48

cheers

Re: [PATCH] hw_breakpoint: Fix build warnings with clang

[Michael Ellerman]

On Tue, 2 Jun 2020 09:42:08 +0530, Ravi Bangoria wrote:
> kbuild test robot reported few build warnings with hw_breakpoint code
> when compiled with clang[1]. Fix those.
> 
> [1]: 
> https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/

Applied to powerpc/next.

[1/1] hw-breakpoints: Fix build warnings with clang
  https://git.kernel.org/powerpc/c/ef3534a94fdbdeab4c89d18d0164be2ad5d6dbb7

cheers

Re: [PATCH] powerpc/wii: Fix declaration made after definition

[Michael Ellerman]

On Mon, 13 Apr 2020 12:06:45 -0700, Nathan Chancellor wrote:
> A 0day randconfig uncovered an error with clang, trimmed for brevity:
> 
> arch/powerpc/platforms/embedded6xx/wii.c:195:7: error: attribute
> declaration must precede definition [-Werror,-Wignored-attributes]
> if (!machine_is(wii))
>  ^
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/wii: Fix declaration made after definition
  https://git.kernel.org/powerpc/c/91ffeaa7e5dd62753e23a1204dc7ecd11f26eadc

cheers

Re: [PATCH] powerpc/kprobes: Use probe_address() to read instructions

[Michael Ellerman]

On Mon, 24 Feb 2020 18:02:10 + (UTC), Christophe Leroy wrote:
> In order to avoid Oopses, use probe_address() to read the
> instruction at the address where the trap happened.

Applied to powerpc/next.

[1/1] powerpc/kprobes: Use probe_address() to read instructions
  https://git.kernel.org/powerpc/c/9ed5df69b79a22b40b20bc2132ba2495708b19c4

cheers

Re: [PATCH] powerpc/32: disable KASAN with pages bigger than 16k

[Michael Ellerman]

On Thu, 28 May 2020 10:17:04 + (UTC), Christophe Leroy wrote:
> Mapping of early shadow area is implemented by using a single static
> page table having all entries pointing to the same early shadow page.
> The shadow area must therefore occupy full PGD entries.
> 
> The shadow area has a size of 128Mbytes starting at 0xf800.
> With 4k pages, a PGD entry is 4Mbytes
> With 16k pages, a PGD entry is 64Mbytes
> With 64k pages, a PGD entry is 256Mbytes which is too big.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/32: Disable KASAN with pages bigger than 16k
  https://git.kernel.org/powerpc/c/888468ce725a4cd56d72dc7e5096078f7a9251a0

cheers

Re: [PATCH] input: i8042: Remove special PowerPC handling

[Michael Ellerman]

On Mon, 18 May 2020 11:10:43 -0700, Nathan Chancellor wrote:
> This causes a build error with CONFIG_WALNUT because kb_cs and kb_data
> were removed in commit 917f0af9e5a9 ("powerpc: Remove arch/ppc and
> include/asm-ppc").
> 
> ld.lld: error: undefined symbol: kb_cs
> > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
> > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
> > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
> > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> 
> [...]

Applied to powerpc/next.

[1/1] input: i8042 - Remove special PowerPC handling
  https://git.kernel.org/powerpc/c/e4f4ffa8a98c24a4ab482669b1e2b4cfce3f52f4

cheers

Re: [PATCH v3 1/1] powerpc/kernel: Enables memory hot-remove after reboot on pseries guests

[Michael Ellerman]

On Thu, 2 Apr 2020 16:51:57 -0300, Leonardo Bras wrote:
> While providing guests, it's desirable to resize it's memory on demand.
> 
> By now, it's possible to do so by creating a guest with a small base
> memory, hot-plugging all the rest, and using 'movable_node' kernel
> command-line parameter, which puts all hot-plugged memory in
> ZONE_MOVABLE, allowing it to be removed whenever needed.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/kernel: Enables memory hot-remove after reboot on pseries guests
  https://git.kernel.org/powerpc/c/b6eca183e23e7a6625a0d2cdb806b7cd1abcd2d2

cheers

Re: [PATCH v2] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG

[Michael Ellerman]

On Sat, 30 May 2020 17:16:33 + (UTC), Christophe Leroy wrote:
> 'thread' doesn't exist in kuap_check() macro.
> 
> Use 'current' instead.

Applied to powerpc/next.

[1/1] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
  https://git.kernel.org/powerpc/c/74016701fe5f873ae23bf02835407227138d874d

cheers

Re: [PATCH] powerpc/uaccess: Don't set KUEP by default on book3s/32

[Michael Ellerman]

On Wed, 15 Apr 2020 14:57:11 + (UTC), Christophe Leroy wrote:
> On book3s/32, KUEP is an heavy process as it requires to
> set/unset the NX bit in each of the 12 user segments
> everytime the kernel is entered/exited from/to user space.
> 
> Don't select KUEP by default on book3s/32.

Applied to powerpc/next.

[1/1] powerpc/uaccess: Don't set KUEP by default on book3s/32
  https://git.kernel.org/powerpc/c/c3ba4dbbd1d05b49ec01efe098e0a78857d3ce22

cheers

Re: [PATCH] macintosh/ams-input: switch to using input device polling mode

[Michael Ellerman]

On Wed, 2 Oct 2019 14:48:54 -0700, Dmitry Torokhov wrote:
> Now that instances of input_dev support polling mode natively,
> we no longer need to create input_polled_dev instance.

Applied to powerpc/next.

[1/1] macintosh/ams-input: switch to using input device polling mode
  https://git.kernel.org/powerpc/c/0c444d98efad89e2a189d1a5a188e0385edac647

cheers

Re: [PATCH v2 01/12] powerpc/52xx: Blacklist functions running with MMU disabled for kprobe

[Michael Ellerman]

On Tue, 31 Mar 2020 16:03:36 + (UTC), Christophe Leroy wrote:
> kprobe does not handle events happening in real mode, all
> functions running with MMU disabled have to be blacklisted.

Applied to powerpc/next.

[01/12] powerpc/52xx: Blacklist functions running with MMU disabled for kprobe

https://git.kernel.org/powerpc/c/e83f01fdb9143a4f90b17fbf7d8b8b21efb2f968
[02/12] powerpc/82xx: Blacklist pq2_restart() for kprobe

https://git.kernel.org/powerpc/c/1740f15a99d30a5e2710b2b0754e65fc5ba68d1d
[03/12] powerpc/83xx: Blacklist mpc83xx_deep_resume() for kprobe

https://git.kernel.org/powerpc/c/7aa85127b1a170694b042cbc35a07afe3904173e
[04/12] powerpc/powermac: Blacklist functions running with MMU disabled for 
kprobe

https://git.kernel.org/powerpc/c/32a820670fa00419375a964ca8bc569e1499b90d
[05/12] powerpc/mem: Blacklist flush_dcache_icache_phys() for kprobe

https://git.kernel.org/powerpc/c/a64371b5d4fb37199dcd04cb7bf0132894018e33
[06/12] powerpc/32s: Make local symbols non visible in hash_low.

https://git.kernel.org/powerpc/c/f892c21d2efb3b86ecbf8f5a95ea4abeedcc91b0
[07/12] powerpc/32s: Blacklist functions running with MMU disabled for kprobe

https://git.kernel.org/powerpc/c/e6209318d63e2774c5ab214b14b948079e040064
[08/12] powerpc/rtas: Remove machine_check_in_rtas()

https://git.kernel.org/powerpc/c/32746dfe4cf37f4077929601e8877a7fd02676e8
[09/12] powerpc/32: Blacklist functions running with MMU disabled for kprobe

https://git.kernel.org/powerpc/c/5f32e8361cba8c58c4f272a389296f489ecc2823
[10/12] powerpc/entry32: Blacklist exception entry points for kprobe.

https://git.kernel.org/powerpc/c/a616c442119f2ea5641e6abc215d7255b73b982b
[11/12] powerpc/entry32: Blacklist syscall exit points for kprobe.

https://git.kernel.org/powerpc/c/7cdf4401388572f720403a7038a178a4b30ac14c
[12/12] powerpc/entry32: Blacklist exception exit points for kprobe.

https://git.kernel.org/powerpc/c/e51c3e13709fe55d4d0eb50ba435bc53a64152bf

cheers

Re: [PATCH] powerpc/uaccess: Don't set KUAP by default on book3s/32

[Michael Ellerman]

On Wed, 15 Apr 2020 14:57:09 + (UTC), Christophe Leroy wrote:
> On book3s/32, KUAP is an heavy process as it requires to
> determine which segments are impacted and unlock/lock
> each of them.
> 
> And since the implementation of user_access_begin/end, it
> is even worth for the time being because unlike __get_user(),
> user_access_begin doesn't make difference between read and write
> and unlocks access also for read allthought that's unneeded
> on book3s/32.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/uaccess: Don't set KUAP by default on book3s/32
  https://git.kernel.org/powerpc/c/547e687b2981a115814962506068873d24983af7

cheers

Re: [PATCH] powerpc/8xx: Reduce time spent in allow_user_access() and friends

[Michael Ellerman]

On Wed, 15 Apr 2020 10:06:09 + (UTC), Christophe Leroy wrote:
> To enable/disable kernel access to user space, the 8xx has to
> modify the properties of access group 1. This is done by writing
> predefined values into SPRN_Mx_AP registers.
> 
> As of today, a __put_user() gives:
> 
> 0d64 :
>  d64: 3d 20 4f ff lis r9,20479
>  d68: 61 29 ff ff ori r9,r9,65535
>  d6c: 7d 3a c3 a6 mtspr   794,r9
>  d70: 39 20 00 00 li  r9,0
>  d74: 90 83 00 00 stw r4,0(r3)
>  d78: 3d 20 6f ff lis r9,28671
>  d7c: 61 29 ff ff ori r9,r9,65535
>  d80: 7d 3a c3 a6 mtspr   794,r9
>  d84: 4e 80 00 20 blr
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/8xx: Reduce time spent in allow_user_access() and friends
  https://git.kernel.org/powerpc/c/332ce969b763553e9c4d55069e1e15aba4ea560f

cheers

Re: [PATCH v5 00/13] Modernise powerpc 40x

[Michael Ellerman]

On Thu, 21 May 2020 16:55:51 + (UTC), Christophe Leroy wrote:
> v1 and v2 of this series were aiming at removing 40x entirely,
> but it led to protests.
> 
> v3 is trying to start modernising powerpc 40x:
> - Rework TLB miss handlers to not use PTE_ATOMIC_UPDATES and _PAGE_HWWRITE
> - Remove old versions of 40x processors, namely 403 and 405GP and associated
> errata.
> - Last two patches are trivial changes in TLB miss handlers to reduce number
> of scratch registers.
> 
> [...]

Applied to powerpc/next.

[01/13] powerpc: Remove Xilinx PPC405/PPC440 support

https://git.kernel.org/powerpc/c/7ade8495dcfd788a76e6877c9ea86f5207369ea4
[02/13] powerpc/40x: Rework 40x PTE access and TLB miss

https://git.kernel.org/powerpc/c/2c74e2586bb96012ffc05f1c819b05d9cad86d6e
[03/13] powerpc/pgtable: Drop PTE_ATOMIC_UPDATES

https://git.kernel.org/powerpc/c/4e1df545e2fae53e07c93b835c3dcc9d4917c849
[04/13] powerpc/40x: Remove support for IBM 403GCX

https://git.kernel.org/powerpc/c/1b5c0967ab8aa9424cdd5108de4e055d8aeaa9d0
[05/13] powerpc/40x: Remove STB03xxx

https://git.kernel.org/powerpc/c/7583b63c343c1076c89b2012fd8758473f046f5f
[06/13] powerpc/40x: Remove WALNUT

https://git.kernel.org/powerpc/c/5786074b96e38691a0cb3d3644ca2aa5d6d8830d
[07/13] powerpc/40x: Remove EP405

https://git.kernel.org/powerpc/c/548f5244f1064c9facb19c5e97c21e1e80102ea0
[08/13] powerpc/40x: Remove support for ISS Simulator

https://git.kernel.org/powerpc/c/2874ec75708eed59a47a9a986c02add747ae6e9b
[09/13] powerpc/40x: Remove support for IBM 405GP

https://git.kernel.org/powerpc/c/7d372d4ccdd55d5ead4d4ecbc336af4dd7d04344
[10/13] powerpc/40x: Remove IBM405 Erratum #51

https://git.kernel.org/powerpc/c/59fb463b48e904dfdfff64c7dd4d67f20ae27170
[11/13] powerpc: Remove IBM405 Erratum #77

https://git.kernel.org/powerpc/c/455531e9d88048c025ff9099796413df748d92b9
[12/13] powerpc/40x: Avoid using r12 in TLB miss handlers

https://git.kernel.org/powerpc/c/797f4016f6da4a90ac83e32b213b68ff7be3812b
[13/13] powerpc/40x: Don't save CR in SPRN_SPRG_SCRATCH6

https://git.kernel.org/powerpc/c/3aacaa719b7bf135551cabde2480e8f7bfdf7c7d

cheers

Re: [PATCH v4 00/45] Use hugepages to map kernel mem on 8xx

[Michael Ellerman]

On Tue, 19 May 2020 05:48:42 + (UTC), Christophe Leroy wrote:
> The main purpose of this big series is to:
> - reorganise huge page handling to avoid using mm_slices.
> - use huge pages to map kernel memory on the 8xx.
> 
> The 8xx supports 4 page sizes: 4k, 16k, 512k and 8M.
> It uses 2 Level page tables, PGD having 1024 entries, each entry
> covering 4M address space. Then each page table has 1024 entries.
> 
> [...]

Patches 1-6 and 9-45 applied to powerpc/next.

[01/45] powerpc/kasan: Fix error detection on memory allocation

https://git.kernel.org/powerpc/c/d132443a73d7a131775df46f33000f67ed92de1e
[02/45] powerpc/kasan: Fix issues by lowering KASAN_SHADOW_END

https://git.kernel.org/powerpc/c/3a66a24f6060e6775f8c02ac52329ea0152d7e58
[03/45] powerpc/kasan: Fix shadow pages allocation failure

https://git.kernel.org/powerpc/c/d2a91cef9bbdeb87b7449fdab1a6be6000930210
[04/45] powerpc/kasan: Remove unnecessary page table locking

https://git.kernel.org/powerpc/c/7c31c05e00fc5ff2067332c5f80e525573e7269c
[05/45] powerpc/kasan: Refactor update of early shadow mappings

https://git.kernel.org/powerpc/c/7dec42ab57f2f59feba82abf0353164479bfde4c
[06/45] powerpc/kasan: Declare kasan_init_region() weak

https://git.kernel.org/powerpc/c/ec97d022f621c6c850aec46d8818b49c6aae95ad
[09/45] powerpc/ptdump: Add _PAGE_COHERENT flag

https://git.kernel.org/powerpc/c/3af4786eb429b2df76cbd7ce3bae21467ac3e4fb
[10/45] powerpc/ptdump: Display size of BATs

https://git.kernel.org/powerpc/c/6b30830e2003d9d77696084ebe2fc19dbe7d6f70
[11/45] powerpc/ptdump: Standardise display of BAT flags

https://git.kernel.org/powerpc/c/8961a2a5353cca5451f648f4838cd848a3b2354c
[12/45] powerpc/ptdump: Properly handle non standard page size

https://git.kernel.org/powerpc/c/b00ff6d8c1c3898b0f768cbb38ef722d25bd2f39
[13/45] powerpc/ptdump: Handle hugepd at PGD level

https://git.kernel.org/powerpc/c/6b789a26d7da2e0256d199da980369ef8fb49ec6
[14/45] powerpc/32s: Don't warn when mapping RO data ROX.

https://git.kernel.org/powerpc/c/4b19f96a81bceaf0bcf44d79c0855c61158065ec
[15/45] powerpc/mm: Allocate static page tables for fixmap

https://git.kernel.org/powerpc/c/925ac141d106b55acbe112a9272f970631a3c082
[16/45] powerpc/mm: Fix conditions to perform MMU specific management by blocks 
on PPC32.

https://git.kernel.org/powerpc/c/4e3319c23a66dabfd6c35f4d2633d64d99b68096
[17/45] powerpc/mm: PTE_ATOMIC_UPDATES is only for 40x

https://git.kernel.org/powerpc/c/fadaac67c9007cad9fc485e36dcc54460d6d5886
[18/45] powerpc/mm: Refactor pte_update() on nohash/32

https://git.kernel.org/powerpc/c/2db99aeb63dd6e8808dc054d181c4d0e8645bbe0
[19/45] powerpc/mm: Refactor pte_update() on book3s/32

https://git.kernel.org/powerpc/c/1c1bf294882bd12669e39ccd7680c4ce34b7c15c
[20/45] powerpc/mm: Standardise __ptep_test_and_clear_young() params between 
PPC32 and PPC64

https://git.kernel.org/powerpc/c/c7fa77016eb6093df38fdabdb7a89bb9617e7185
[21/45] powerpc/mm: Standardise pte_update() prototype between PPC32 and PPC64

https://git.kernel.org/powerpc/c/06f52524870122fb43b214d27e8f4546da36f8ba
[22/45] powerpc/mm: Create a dedicated pte_update() for 8xx

https://git.kernel.org/powerpc/c/6ad41bfbc907be0cd414f09fa5382d2133376595
[23/45] powerpc/mm: Reduce hugepd size for 8M hugepages on 8xx

https://git.kernel.org/powerpc/c/b12c07a4bb064c0a8db7554557b89d40f57c936f
[24/45] powerpc/8xx: Drop CONFIG_8xx_COPYBACK option

https://git.kernel.org/powerpc/c/d3efcd38c0b99162d889e36a30425345a18edb33
[25/45] powerpc/8xx: Prepare handlers for _PAGE_HUGE for 512k pages.

https://git.kernel.org/powerpc/c/a891c43b97d315ee5f9fe8e797d3d48fc351e053
[26/45] powerpc/8xx: Manage 512k huge pages as standard pages.

https://git.kernel.org/powerpc/c/b250c8c08c79d1eb5354c7eaa84b7505f5f2d921
[27/45] powerpc/8xx: Only 8M pages are hugepte pages now

https://git.kernel.org/powerpc/c/d4870b89acd7c362ded08f9295e8d143cf7e0024
[28/45] powerpc/8xx: MM_SLICE is not needed anymore

https://git.kernel.org/powerpc/c/555904d07eef3a2e5fc458419edf6174362c4ddd
[29/45] powerpc/8xx: Move PPC_PIN_TLB options into 8xx Kconfig

https://git.kernel.org/powerpc/c/5d4656696c30cef56b2ab506b203533c818af04d
[30/45] powerpc/8xx: Add function to set pinned TLBs

https://git.kernel.org/powerpc/c/f76c8f6d257cefda60221c83af7f97d9f74cb3ce
[31/45] powerpc/8xx: Don't set IMMR map anymore at boot

https://git.kernel.org/powerpc/c/136a9a0f74d2e0d9de5515190fe80344b86b45cf
[32/45] powerpc/8xx: Always pin TLBs at startup.

https://git.kernel.org/powerpc/c/684c1664e0de63398aceb748343541b48d398710
[33/45] powerpc/8xx: Drop special handling of Linear and IMMR mappings in I/D 
TLB handlers

https://git.kernel.org/powerpc/c/400dc0f86102d2ad11d3601f1948fbb02e926431
[34/45] powerpc/8xx: Remove now unused TLB 

Re: [PATCH v3] powerpc/64s/pgtable: fix an undefined behaviour

[Michael Ellerman]

On Thu, 5 Mar 2020 23:48:52 -0500, Qian Cai wrote:
> Booting a power9 server with hash MMU could trigger an undefined
> behaviour because pud_offset(p4d, 0) will do,
> 
> 0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10)
> 
> Fix it by converting pud_index() and friends to static inline
> functions.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/64s/pgtable: fix an undefined behaviour
  https://git.kernel.org/powerpc/c/c2e929b18cea6cbf71364f22d742d9aad7f4677a

cheers

Re: [PATCH -next] powerpc/powernv: add NULL check after kzalloc

[Michael Ellerman]

On Sat, 9 May 2020 10:08:38 +0800, Chen Zhou wrote:
> Fixes coccicheck warning:
> 
> ./arch/powerpc/platforms/powernv/opal.c:813:1-5:
>   alloc with no test, possible model on line 814
> 
> Add NULL check after kzalloc.

Applied to powerpc/next.

[1/1] powerpc/powernv: add NULL check after kzalloc
  https://git.kernel.org/powerpc/c/ceffa63acce7165c442395b7d64a11ab8b5c5dca

cheers

Re: [PATCH 3/5] soundwire: qcom: add v1.5.1 compatible

[Vinod Koul]

On 08-06-20, 16:43, Jonathan Marek wrote:
> Add a compatible string for HW version v1.5.1 on sm8250 SoCs.

Please document this new compatible

-- 
~Vinod

RE: [PATCH v9 RESEND 01/13] spi: imx: add dma_sync_sg_for_device after fallback from dma

[Robin Gong]

On 2020/06/09 0:44 Robin Murphy  wrote:
> On 2020-06-08 16:31, Mark Brown wrote:
> > On Mon, Jun 08, 2020 at 03:08:45PM +, Robin Gong wrote:
> >
>  +if (transfer->rx_sg.sgl) {
>  +struct device *rx_dev = 
>  spi->controller->dma_rx->device->dev;
>  +
>  +dma_sync_sg_for_device(rx_dev, transfer->rx_sg.sgl,
>  +   transfer->rx_sg.nents, 
>  DMA_TO_DEVICE);
>  +}
>  +
> >
> >>> This is confusing - why are we DMA mapping to the device after doing
> >>> a PIO transfer?
> >
> >> 'transfer->rx_sg.sgl' condition check that's the case fallback PIO
> >> after DMA transfer failed. But the spi core still think the buffer
> >> should be in 'device' while spi driver touch it by PIO(CPU), so sync it 
> >> back to
> device to ensure all received data flush to DDR.
> >
> > So we sync it back to the device so that we can then do another sync
> > to CPU?  TBH I'm a bit surprised that there's a requirement that we
> > explicitly undo a sync and that a redundant double sync in the same
> > direction might be an issue but I've not had a need to care so I'm
> > perfectly prepared to believe there is.
> >
> > At the very least this needs a comment.
> 
> Yeah, something's off here - at the very least, syncing with DMA_TO_DEVICE on
> the Rx buffer that was mapped with DMA_FROM_DEVICE is clearly wrong.
> CONFIG_DMA_API_DEBUG should scream about that.
> 
> If the device has written to the buffer at all since dma_map_sg() was called
> then you do need a dma_sync_sg_for_cpu() call before touching it from a CPU
> fallback path, but if nobody's going to touch it from that point until it's
> unmapped then there's no point syncing it again. The
> my_card_interrupt_handler() example in DMA-API_HOWTO.txt demonstrates
> this.
Thanks for you post, but sorry, that's not spi-imx case now, because the rx 
data in device memory is not truly updated from 'device'/DMA, but from PIO, so 
that dma_sync_sg_for_cpu with DMA_FROM_DEVICE can't be used, otherwise the 
fresh data in cache will be invalidated.
But you're right, kernel warning comes out if CONFIG_DMA_API_DEBUG enabled... 

Re: [PATCH] sample-trace-array: Fix sleeping function called from invalid context

[Divya Indi]

Hi Kefeng,

Thanks for catching this issue.

Please find my comments line -

On 6/8/20 12:54 AM, Kefeng Wang wrote:
>  BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:935
>  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/5
>  1 lock held by swapper/5/0:
>   #0: 80001002bd90 (samples/ftrace/sample-trace-array.c:38){+.-.}-{0:0}, 
> at: call_timer_fn+0x8/0x3e0
>  CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.7.0+ #8
>  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
>  Call trace:
>   dump_backtrace+0x0/0x1a0
>   show_stack+0x20/0x30
>   dump_stack+0xe4/0x150
>   ___might_sleep+0x160/0x200
>   __might_sleep+0x58/0x90
>   __mutex_lock+0x64/0x948
>   mutex_lock_nested+0x3c/0x58
>   __ftrace_set_clr_event+0x44/0x88
>   trace_array_set_clr_event+0x24/0x38
>   mytimer_handler+0x34/0x40 [sample_trace_array]
>
> mutex_lock() will be called in interrupt context, using workqueueu to fix it.

/s/workqueueu/workqueue

Fixes: 89ed42495ef4 ("tracing: Sample module to demonstrate kernel access to 
Ftrace instances.")

> Signed-off-by: Kefeng Wang 
> ---
>  samples/ftrace/sample-trace-array.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/samples/ftrace/sample-trace-array.c 
> b/samples/ftrace/sample-trace-array.c
> index d523450d73eb..41684c7dbd7b 100644
> --- a/samples/ftrace/sample-trace-array.c
> +++ b/samples/ftrace/sample-trace-array.c
> @@ -20,6 +20,16 @@ struct trace_array *tr;
>  static void mytimer_handler(struct timer_list *unused);
>  static struct task_struct *simple_tsk;
>  
> +static void trace_work_fn(struct work_struct *work)
> +{
> + /*
> +  * Disable tracing for event "sample_event".
> +  */
> + trace_array_set_clr_event(tr, "sample-subsystem", "sample_event",
> + false);
> +}
> +static DECLARE_WORK(trace_work, trace_work_fn);
> +
>  /*
>   * mytimer: Timer setup to disable tracing for event "sample_event". This
>   * timer is only for the purposes of the sample module to demonstrate access 
> of
> @@ -29,11 +39,7 @@ static DEFINE_TIMER(mytimer, mytimer_handler);
>  
>  static void mytimer_handler(struct timer_list *unused)
>  {
> - /*
> -  * Disable tracing for event "sample_event".
> -  */
> - trace_array_set_clr_event(tr, "sample-subsystem", "sample_event",
> - false);
> + schedule_work(_work);
>  }
>  
>  static void simple_thread_func(int count)

I think we also need to use cancel_work_sync() to handle the case -
1. Module unloaded
2. Timer already ran and scheduled work to disable trace event
3. When the work runs we no longer have the relevant trace array.

static int simple_thread(void *arg)
{
.

 del_timer();

  
.
 return 0;
}

Thanks,
Divya

Re: [RFC PATCH] uvcvideo: Add mapping for HEVC payloads

[Dmitry Buzdyk]

On Sun, Jun 07, 2020 at 04:07:19AM +0300, Laurent Pinchart wrote:
> Hi Dmitry,
> 
> Thank you for the patch.
> 
> On Fri, May 29, 2020 at 11:05:47AM +1000, Dmitry Buzdyk wrote:
> > Add HEVC GUID and assotiate with HEVC pixel format so that frame
> > based format descriptors recognized by the UVC video driver.
> 
> The patch itself looks OK to me, but could you share a bit more
> information about which device(s) implement this ? Are they UVC 1.1
> devices ? Could you share their full USB descriptors (retrieved with
> 'lsusb -v', running as root if possible) ?
This is a UVC1.1 camera device based on Ambarella H22 SOC.
Please note that device is still in development and yet to get actual
VID and PID.

Output of lsusb is:

Bus 001 Device 010: ID 1209:0001 Generic pid.codes Test PID
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x1209 Generic
  idProduct  0x0001 pid.codes Test PID
  bcdDevice0.10
  iManufacturer   1 Rhonda
  iProduct2 Rhonda Cam
  iSerial 3 FMABCLE1507
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x01ff
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 3
  bFunctionClass 14 Video
  bFunctionSubClass   3 Video Interface Collection
  bFunctionProtocol   0 
  iFunction   2 Rhonda Cam
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass14 Video
  bInterfaceSubClass  1 Video Control
  bInterfaceProtocol  0 
  iInterface  2 Rhonda Cam
  VideoControl Interface Descriptor:
bLength14
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdUVC   1.10
wTotalLength   0x006b
dwClockFrequency   50.00MHz
bInCollection   2
baInterfaceNr( 0)   1
baInterfaceNr( 1)   2
  VideoControl Interface Descriptor:
bLength44
bDescriptorType36
bDescriptorSubtype  6 (EXTENSION_UNIT)
bUnitID10
guidExtensionCode {e307e649-4618-a3ff-82fc-2d8b5f216773}
bNumControl   146
bNrPins 1
baSourceID( 0)  5
bControlSize   19
bmControls( 0)   0x05
bmControls( 1)   0x00
bmControls( 2)   0x00
bmControls( 3)   0x00
bmControls( 4)   0x00
bmControls( 5)   0x00
bmControls( 6)   0x00
bmControls( 7)   0x00
bmControls( 8)   0x00
bmControls( 9)   0x00
bmControls(10)   0x00
bmControls(11)   0x00
bmControls(12)   0x00
bmControls(13)   0x00
bmControls(14)   0x00
bmControls(15)   0x00
bmControls(16)   0x00
bmControls(17)   0xf0
bmControls(18)   0x02
iExtension  0 
  VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0201 Camera Sensor
bAssocTerminal  0
iTerminal   0 
wObjectiveFocalLengthMin  0
wObjectiveFocalLengthMax  0
wOcularFocalLength0
bControlSize  3
bmControls   0x0010
  VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype  5 (PROCESSING_UNIT)
bUnitID 5
bSourceID   1
wMaxMultiplier  0
bControlSize3
bmControls 0x0400
  Power Line Frequency
iProcessing 0 
bmVideoStandards 0x00
  VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID16
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bSourceID  10
iTerminal

Re: [PATCH] virtio-mem: drop unnecessary initialization

[Pankaj Gupta]

> rc is initialized to -ENIVAL but that's never used. Drop it.
>
> Fixes: 5f1f79bbc9e2 ("virtio-mem: Paravirtualized memory hotplug")
> Reported-by: kernel test robot 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/virtio/virtio_mem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index f658fe9149be..2f357142ea5e 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -1768,7 +1768,7 @@ static void virtio_mem_delete_resource(struct 
> virtio_mem *vm)
>  static int virtio_mem_probe(struct virtio_device *vdev)
>  {
> struct virtio_mem *vm;
> -   int rc = -EINVAL;
> +   int rc;
>
> BUILD_BUG_ON(sizeof(struct virtio_mem_req) != 24);
> BUILD_BUG_ON(sizeof(struct virtio_mem_resp) != 10);

Reviewed-by: Pankaj Gupta 

[rcu:rcu-tasks.2020.06.08a.v5.6] BUILD SUCCESS 5366602725fe22519c438d9f69c4af9403256a4a

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
rcu-tasks.2020.06.08a.v5.6
branch HEAD: 5366602725fe22519c438d9f69c4af9403256a4a  ftrace: Use 
synchronize_rcu_tasks_rude() instead of ftrace_sync()

elapsed time: 483m

configs tested: 98
configs skipped: 3

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

arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm shannon_defconfig
arm socfpga_defconfig
sh   sh7724_generic_defconfig
arm davinci_all_defconfig
mips  maltasmvp_eva_defconfig
armxcep_defconfig
arm mv78xx0_defconfig
sh magicpanelr2_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k 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
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
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-20200607
i386 randconfig-a006-20200607
i386 randconfig-a002-20200607
i386 randconfig-a005-20200607
i386 randconfig-a004-20200607
i386 randconfig-a003-20200607
i386 randconfig-a015-20200607
i386 randconfig-a011-20200607
i386 randconfig-a016-20200607
i386 randconfig-a012-20200607
i386 randconfig-a013-20200607
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation

Re: [PATCH 2/5] soundwire: qcom: add support for mmio soundwire devices

[Vinod Koul]

Hi Jonathan,

On 08-06-20, 16:43, Jonathan Marek wrote:
> Adds support for qcom soundwire devices with memory mapped IO registers.

Please use 'SoundWire Master devices' instead :)

> 
> Signed-off-by: Jonathan Marek 
> ---
>  drivers/soundwire/qcom.c | 25 +++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
> index f38d1fd3679f..628747df1c75 100644
> --- a/drivers/soundwire/qcom.c
> +++ b/drivers/soundwire/qcom.c
> @@ -90,6 +90,7 @@ struct qcom_swrm_ctrl {
>   struct sdw_bus bus;
>   struct device *dev;
>   struct regmap *regmap;
> + void __iomem *mmio;
>   struct completion *comp;
>   struct work_struct slave_work;
>   /* read/write lock */
> @@ -154,6 +155,20 @@ static int qcom_swrm_ahb_reg_write(struct qcom_swrm_ctrl 
> *ctrl,
>   return SDW_CMD_OK;
>  }
>  
> +static int qcom_swrm_cpu_reg_read(struct qcom_swrm_ctrl *ctrl, int reg,
> +   u32 *val)
> +{
> + *val = readl(ctrl->mmio + reg);
> + return SDW_CMD_OK;
> +}
> +
> +static int qcom_swrm_cpu_reg_write(struct qcom_swrm_ctrl *ctrl, int reg,
> +int val)
> +{
> + writel(val, ctrl->mmio + reg);
> + return SDW_CMD_OK;
> +}

this looks fine but regmap supports mmio also, so I am thinking we
should remove these and set regmap (mmio/slim)... Srini..?

-- 
~Vinod

Re: [PATCH AUTOSEL 5.7 244/274] xfs: force writes to delalloc regions to unwritten

[Darrick J. Wong]

On Mon, Jun 08, 2020 at 10:10:21PM -0400, Sasha Levin wrote:
> On Mon, Jun 08, 2020 at 06:07:27PM -0700, Darrick J. Wong wrote:
> > On Mon, Jun 08, 2020 at 07:05:37PM -0400, Sasha Levin wrote:
> > > From: "Darrick J. Wong" 
> > > 
> > > [ Upstream commit a5949d3faedf492fa7863b914da408047ab46eb0 ]
> > > 
> > > When writing to a delalloc region in the data fork, commit the new
> > > allocations (of the da reservation) as unwritten so that the mappings
> > > are only marked written once writeback completes successfully.  This
> > > fixes the problem of stale data exposure if the system goes down during
> > > targeted writeback of a specific region of a file, as tested by
> > > generic/042.
> > > 
> > > Signed-off-by: Darrick J. Wong 
> > > Reviewed-by: Christoph Hellwig 
> > > Reviewed-by: Brian Foster 
> > > Signed-off-by: Sasha Levin 
> > 
> > Err, this doesn't have a Fixes: tag attached to it.  Does it pass
> > fstests?  Because it doesn't look like you've pulled in "xfs: don't fail
> > unwritten extent conversion on writeback due to edquot", which is needed
> > to avoid regressing fstests...
> > 
> > ...waitaminute, that whole series lacks Fixes: tags because it wasn't
> > considered a good enough candidate for automatic backport.
> 
> AUTOSEL doesn't look just at the Fixes tag :)
> 
> > Ummm, does the autosel fstests driver turn on quotas? ;)
> 
> Uh, apparently not :/ Is it okay to just enable it across all tests?

It should be at this point.

> While I go fix that up, would you rather drop the series, or pick up
> 1edd2c055dff ("xfs: don't fail unwritten extent conversion on writeback
> due to edquot")?`

Let's drop it for now, please.  There might be a few more tweaks needed
to get that bit just right.

--D

> -- 
> Thanks,
> Sasha

[RFC 1/2] Eliminate over- and under-counting of io_ticks

[Josh Snyder]

Previously, io_ticks could be under-counted. Consider these I/Os along
the time axis (in jiffies):

  t  012345678
  io1||
  io2|---|

Under the old approach, io_ticks would count up to 6, like so:

  t  012345678
  io1||
  io2|---|
  stamp  0   45  8
  io_ticks   1   23  6

With this change, io_ticks instead counts to 8, eliminating the
under-counting:

  t  012345678
  io1||
  io2|---|
  stamp  05  8
  io_ticks   05  8

It was also possible for io_ticks to be over-counted. Consider a
workload that issues I/Os deterministically at intervals of 8ms (125Hz).
If each I/O takes 1ms, then the true utilization is 12.5%. The previous
implementation will increment io_ticks once for each jiffy in which an
I/O ends. Since the workload issues an I/O reliably for each jiffy, the
reported utilization will be 100%. This commit changes the approach such
that only I/Os which cross a boundary between jiffies are counted. With
this change, the given workload would count an I/O tick on every eighth
jiffy, resulting in a (correct) calculated utilization of 12.5%.

Signed-off-by: Josh Snyder 
Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise 
counting")
---
 block/blk-core.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index d1b79dfe9540..a0bbd9e099b9 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1396,14 +1396,22 @@ unsigned int blk_rq_err_bytes(const struct request *rq)
 }
 EXPORT_SYMBOL_GPL(blk_rq_err_bytes);
 
-static void update_io_ticks(struct hd_struct *part, unsigned long now, bool 
end)
+static void update_io_ticks(struct hd_struct *part, unsigned long now, 
unsigned long start)
 {
unsigned long stamp;
+   unsigned long elapsed;
 again:
stamp = READ_ONCE(part->stamp);
if (unlikely(stamp != now)) {
-   if (likely(cmpxchg(>stamp, stamp, now) == stamp))
-   __part_stat_add(part, io_ticks, end ? now - stamp : 1);
+   if (likely(cmpxchg(>stamp, stamp, now) == stamp)) {
+   // stamp denotes the last IO to finish
+   // If this IO started before stamp, then there was 
overlap between this IO
+   // and that one. We increment only by the non-overlap 
time.
+   // If not, there was no overlap and we increment by our 
own time,
+   // disregarding stamp.
+   elapsed = now - (start < stamp ? stamp : start);
+   __part_stat_add(part, io_ticks, elapsed);
+   }
}
if (part->partno) {
part = _to_disk(part)->part0;
@@ -1439,7 +1447,7 @@ void blk_account_io_done(struct request *req, u64 now)
part_stat_lock();
part = req->part;
 
-   update_io_ticks(part, jiffies, true);
+   update_io_ticks(part, jiffies, 
nsecs_to_jiffies(req->start_time_ns));
part_stat_inc(part, ios[sgrp]);
part_stat_add(part, nsecs[sgrp], now - req->start_time_ns);
part_stat_unlock();
@@ -1456,7 +1464,6 @@ void blk_account_io_start(struct request *rq)
rq->part = disk_map_sector_rcu(rq->rq_disk, blk_rq_pos(rq));
 
part_stat_lock();
-   update_io_ticks(rq->part, jiffies, false);
part_stat_unlock();
 }
 
@@ -1468,7 +1475,6 @@ unsigned long disk_start_io_acct(struct gendisk *disk, 
unsigned int sectors,
unsigned long now = READ_ONCE(jiffies);
 
part_stat_lock();
-   update_io_ticks(part, now, false);
part_stat_inc(part, ios[sgrp]);
part_stat_add(part, sectors[sgrp], sectors);
part_stat_local_inc(part, in_flight[op_is_write(op)]);
@@ -1487,7 +1493,7 @@ void disk_end_io_acct(struct gendisk *disk, unsigned int 
op,
unsigned long duration = now - start_time;
 
part_stat_lock();
-   update_io_ticks(part, now, true);
+   update_io_ticks(part, now, start_time);
part_stat_add(part, nsecs[sgrp], jiffies_to_nsecs(duration));
part_stat_local_dec(part, in_flight[op_is_write(op)]);
part_stat_unlock();
-- 
2.25.1

[RFC 0/2] Increase accuracy and precision of sampled io_ticks

[Josh Snyder]

Commit 5b18b5a73760 ("block: delete part_round_stats and switch to less
precise counting") introduces a sampling technique for calculating
io_ticks. The sampling algorithm introduces bias in the calculation of
I/O utilization. In my production system, this bias means that a
workload which previously reported 10% I/O utilization now reports 80%.
Patch 1 of this series eliminates the bias.

The sampling technique is also subject to statistical noise. Because it
infers io_ticks based on only 100 samples per second, io_ticks becomes
imprecise, and subject to swings when measuring both random and
deterministic workloads. Patch 2 of this series provides increased
precision by raising the sampling rate.

[RFC 2/2] Track io_ticks at microsecond granularity.

[Josh Snyder]

Previously, we performed truncation of I/O issue/completion times during
calculation of io_ticks, counting only I/Os which cross a jiffy
boundary. The effect is a sampling of I/Os: at every boundary between
jiffies we ask "is there an outstanding I/O" and increment a counter if
the answer is yes. This produces results that are accurate (they don't
systematically over- or under-count), but not precise (there is high
variance associated with only taking 100 samples per second).

This change modifies the sampling rate from 100Hz to 976562.5Hz (1
sample per 1024 nanoseconds). I chose this sampling rate by simulating a
workload in which I/Os are issued randomly (by a Poisson process), and
processed in constant time: an M/D/∞ system (Kendall's notation). My
goal was to produce a sampled utilization fraction which was correct to
one part-per-thousand given one second of samples.

The tradeoff of the higher sampling rate is increased synchronization
overhead caused by more frequent compare-and-swap operations. The
technique of commit 5b18b5a73760 ("block: delete part_round_stats and
switch to less precise counting") is to allow multiple I/Os to complete
while performing only one synchronized operation. As we are increasing
the sample rate by a factor of 1, we will less frequently be able to
exercise the synchronization-free code path.

Included below is the Python script I used to perform the simulation. It
estimates the correct (calculated without sampling) value of %util, and
then reports the root-mean-squared error of the as-sampled estimates.
The parameters `io_rate`, `sample_rates`, and `avgqu_sz` are meant to be
tweaked to fit characteristics of a given workload. I have chosen to
simulate against a difficult workload: 1000 I/Os per second with an
average queue size of 0.01, implying that each I/O takes 10
microseconds. This I/O latency is on par with some of the fastest
production block devices available today, and an order of magnitude
faster than a typical datacenter-grade SSD. With this change, an
estimate of disk %util will not fluctuate as displayed by iostat with
four decimal places, at a refresh rate of 1 Hz.

#!/usr/bin/env python3
from math import log
from math import sqrt
from random import random

GIGA = 1_000_000_000
SECOND = GIGA

def times(interval, avgqu_sz, sample_rates):
time = 0
correct = 0

est_counters = [0] * len(sample_rates)

while time < SECOND:
gap = -log(random()) * interval
busy = svctm if gap > svctm else gap
finish_time = time + busy

correct += busy
for i, rate in enumerate(sample_rates):
est_counters[i] += (
float(int(finish_time * rate)) - int(time * rate)
)

time += gap

return correct, [
correct - (counter / rate)
for counter, rate in zip(est_counters, sample_rates)
]

# How many I/Os per second?
io_rate = 1000
# How frequently are we sampling? (GHz)
sample_rates = [
100 / GIGA,  #  100 Hz
1000 / GIGA, # 1000 Hz
1 / 65536,   #15259 Hz
1 / 16384,   #61035 Hz
1 / 1024,#   976563 Hz
1 / 64,  # 15625000 Hz
]
avgqu_sz = 0.01

interval = SECOND / io_rate
svctm = interval * avgqu_sz
total = 0
total_errors = [0] * len(sample_rates)
count = 0
while True:
correct, errors = times(interval, svctm, sample_rates)
for i, error in enumerate(errors):
total_errors[i] += error * error
total += correct / SECOND
count += 1

# prints [{RMS error} for rate in sample_rates]
to_print = [
   "{:05.2f}".format(100 * sqrt(error / count) / SECOND)
for error in total_errors
]
print(' '.join(to_print))

Signed-off-by: Josh Snyder 
Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise 
counting")
---
 block/blk-core.c  | 16 +++-
 block/genhd.c |  4 ++--
 include/linux/genhd.h |  2 +-
 include/linux/part_stat.h |  2 +-
 4 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index a0bbd9e099b9..2749c52d649c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -62,6 +62,8 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(block_unplug);
 
 DEFINE_IDA(blk_queue_ida);
 
+#define IO_TICKS_COARSENESS 10
+
 /*
  * For queue allocation
  */
@@ -1396,10 +1398,14 @@ unsigned int blk_rq_err_bytes(const struct request *rq)
 }
 EXPORT_SYMBOL_GPL(blk_rq_err_bytes);
 
-static void update_io_ticks(struct hd_struct *part, unsigned long now, 
unsigned long start)
+static void update_io_ticks(struct hd_struct *part, u64 now, u64 start)
 {
-   unsigned long stamp;
-   unsigned long elapsed;
+   u64 stamp;
+   u64 elapsed;
+
+   start &= ~((1

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

[Zhangfei Gao]

Hi, Bjorn

On 2020/6/9 上午12:41, Bjorn Helgaas wrote:

On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:

On 2020/6/6 上午7:19, Bjorn Helgaas wrote:

On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:

On 2020/6/2 上午1:41, Bjorn Helgaas wrote:

On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:

On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:

Is this slowdown significant?  We already iterate over every device
when applying PCI_FIXUP_FINAL quirks, so if we used the existing
PCI_FIXUP_FINAL, we wouldn't be adding a new loop.  We would only be
adding two more iterations to the loop in pci_do_fixups() that tries
to match quirks against the current device.  I doubt that would be a
measurable slowdown.

I don't know how significant it is, but I remember people complaining
about adding new PCI quirks because it takes too long for them to run
them all. That was in the discussion about the quirk disabling ATS on
AMD Stoney systems.

So it probably depends on how many PCI devices are in the system whether
it causes any measureable slowdown.

I found this [1] from Paul Menzel, which was a slowdown caused by
quirk_usb_early_handoff().  I think the real problem is individual
quirks that take a long time.

The PCI_FIXUP_IOMMU things we're talking about should be fast, and of
course, they're only run for matching devices anyway.  So I'd rather
keep them as PCI_FIXUP_FINAL than add a whole new phase.


Thanks Bjorn for taking time for this.
If so, it would be much simpler.

+++ b/drivers/iommu/iommu.c
@@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct
fwnode_handle *iommu_fwnode,
      fwspec->iommu_fwnode = iommu_fwnode;
      fwspec->ops = ops;
      dev_iommu_fwspec_set(dev, fwspec);
+
+   if (dev_is_pci(dev))
+   pci_fixup_device(pci_fixup_final, to_pci_dev(dev));
+

Then pci_fixup_final will be called twice, the first in pci_bus_add_device.
Here in iommu_fwspec_init is the second time, specifically for iommu_fwspec.
Will send this when 5.8-rc1 is open.

Wait, this whole fixup approach seems wrong to me.  No matter how you
do the fixup, it's still a fixup, which means it requires ongoing
maintenance.  Surely we don't want to have to add the Vendor/Device ID
for every new AMBA device that comes along, do we?


Here the fake pci device has standard PCI cfg space, but physical
implementation is base on AMBA
They can provide pasid feature.
However,
1, does not support tlp since they are not real pci devices.
2. does not support pri, instead support stall (provided by smmu)
And stall is not a pci feature, so it is not described in struct pci_dev,
but in struct iommu_fwspec.
So we use this fixup to tell pci system that the devices can support stall,
and hereby support pasid.

This did not answer my question.  Are you proposing that we update a
quirk every time a new AMBA device is released?  I don't think that
would be a good model.

Yes, you are right, but we do not have any better idea yet.
Currently we have three fake pci devices, which support stall and pasid.
We have to let pci system know the device can support pasid, because of 
stall feature, though not support pri.

Do you have any other ideas?

Thanks

[PATCH v3 0/3] platform/x86: dell-wmi: new keys

[Y Paritcher]

Extended data and events like Fn lock are currently ignored.
This is consistent with what was done until now.
Changing this is out of scope of this patch and would require
rethinking how events are processed, as on some devices the status
is sent as it own event, and on some devices via extended data.
That is also dependent on better docs from the team at Dell.

The keycode 0x look to be a special case and was added as an
exception code (Thanks Randy for the implementation).
It was not found for any key on my device, it is only located in
the DMI table parsed at boot into the keymap.

Overall I am trying to get useless data (to me) out of my syslog
by documenting the correct scancode/keycode mappings

Y Paritcher (3):
  platform/x86: dell-wmi: add new backlight events
  platform/x86: dell-wmi: add new keymap type 0x0012
  platform/x86: dell-wmi: add new dmi mapping for keycode 0x

 drivers/platform/x86/dell-wmi.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

-- 
2.27.0

[PATCH v3 3/3] platform/x86: dell-wmi: add new dmi mapping for keycode 0xffff

[Y Paritcher]

This looks to be a special value for some sort of custom scancode.
This code could not be triggered for any keypress and is included
from the 0xB2 DMI table.

This prevents the following messages from being logged at startup on a
Dell Inspiron 5593:

dell_wmi: firmware scancode 0x48 maps to unrecognized keycode 0x
dell_wmi: firmware scancode 0x50 maps to unrecognized keycode 0x

as per this code comment:

   Log if we find an entry in the DMI table that we don't
   understand.  If this happens, we should figure out what
   the entry means and add it to bios_to_linux_keycode.

Signed-off-by: Y Paritcher 
---
 drivers/platform/x86/dell-wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index e3bc2601e631..bbdb3e860892 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -506,7 +506,7 @@ static void handle_dmi_entry(const struct dmi_header *dm, 
void *opaque)
u16 keycode = (bios_entry->keycode <
   ARRAY_SIZE(bios_to_linux_keycode)) ?
bios_to_linux_keycode[bios_entry->keycode] :
-   KEY_RESERVED;
+   (bios_entry->keycode == 0x ? KEY_UNKNOWN : 
KEY_RESERVED);
 
/*
 * Log if we find an entry in the DMI table that we don't
-- 
2.27.0

[PATCH v3 2/3] platform/x86: dell-wmi: add new keymap type 0x0012

[Y Paritcher]

These are events with extended data. The extended data is
currently ignored as userspace does not have a way to deal
it.

Ignore event with a type of 0x0012 and a code of 0xe035, as
the keyboard controller takes care of Fn lock events by itself.
This silences the following messages being logged when
pressing the Fn-lock key on a Dell Inspiron 5593:

dell_wmi: Unknown WMI event type 0x12
dell_wmi: Unknown key with type 0x0012 and code 0xe035 pressed

This is consistent with the behavior for the Fn-lock key
elsewhere in this file.

Signed-off-by: Y Paritcher 
---
 drivers/platform/x86/dell-wmi.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 0b2edfe2767d..e3bc2601e631 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -334,6 +334,15 @@ static const struct key_entry dell_wmi_keymap_type_0011[] 
= {
{ KE_IGNORE, KBD_LED_AUTO_100_TOKEN, { KEY_RESERVED } },
 };
 
+/*
+ * Keymap for WMI events of type 0x0012
+ * They are events with extended data
+ */
+static const struct key_entry dell_wmi_keymap_type_0012[] = {
+   /* Fn-lock button pressed */
+   { KE_IGNORE, 0xe035, { KEY_RESERVED } },
+};
+
 static void dell_wmi_process_key(struct wmi_device *wdev, int type, int code)
 {
struct dell_wmi_priv *priv = dev_get_drvdata(>dev);
@@ -418,10 +427,11 @@ static void dell_wmi_notify(struct wmi_device *wdev,
 
switch (buffer_entry[1]) {
case 0x: /* One key pressed or event occurred */
+   case 0x0012: /* Event with extended data occurred */
if (len > 2)
-   dell_wmi_process_key(wdev, 0x,
+   dell_wmi_process_key(wdev, buffer_entry[1],
 buffer_entry[2]);
-   /* Other entries could contain additional information */
+   /* Extended data is currently ignored */
break;
case 0x0010: /* Sequence of keys pressed */
case 0x0011: /* Sequence of events occurred */
@@ -556,6 +566,7 @@ static int dell_wmi_input_setup(struct wmi_device *wdev)
 ARRAY_SIZE(dell_wmi_keymap_type_) +
 ARRAY_SIZE(dell_wmi_keymap_type_0010) +
 ARRAY_SIZE(dell_wmi_keymap_type_0011) +
+ARRAY_SIZE(dell_wmi_keymap_type_0012) +
 1,
 sizeof(struct key_entry), GFP_KERNEL);
if (!keymap) {
@@ -600,6 +611,13 @@ static int dell_wmi_input_setup(struct wmi_device *wdev)
pos++;
}
 
+   /* Append table with events of type 0x0012 */
+   for (i = 0; i < ARRAY_SIZE(dell_wmi_keymap_type_0012); i++) {
+   keymap[pos] = dell_wmi_keymap_type_0012[i];
+   keymap[pos].code |= (0x0012 << 16);
+   pos++;
+   }
+
/*
 * Now append also table with "legacy" events of type 0x. Some of
 * them are reported also on laptops which have scancodes in DMI.
-- 
2.27.0

[PATCH v3 1/3] platform/x86: dell-wmi: add new backlight events

[Y Paritcher]

Add events with a type of 0x0010 and a code of 0x57 / 0x58,
this silences the following messages being logged on a
Dell Inspiron 5593:

dell_wmi: Unknown key with type 0x0010 and code 0x0057 pressed
dell_wmi: Unknown key with type 0x0010 and code 0x0058 pressed

These are brightness events and will be handled by acpi-video

Signed-off-by: Y Paritcher 
---
 drivers/platform/x86/dell-wmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index c25a4286d766..0b2edfe2767d 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -255,6 +255,10 @@ static const struct key_entry dell_wmi_keymap_type_0010[] 
= {
/* Keyboard backlight change notification */
{ KE_IGNORE, 0x3f, { KEY_RESERVED } },
 
+   /* Backlight brightness level */
+   { KE_KEY,0x57, { KEY_BRIGHTNESSDOWN } },
+   { KE_KEY,0x58, { KEY_BRIGHTNESSUP } },
+
/* Mic mute */
{ KE_KEY, 0x150, { KEY_MICMUTE } },
 
-- 
2.27.0

[rcu:dev.2020.06.05a 91/92] kernel/sched/fair.c:447 find_matching_se() warn: inconsistent indenting

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2020.06.05a
head:   c5432e18c8bfe9283bf5e0bc5e2460ae8f39a7ee
commit: c2e2e4194231b2da0a1cc415a63220d24377381c [91/92] EXP sched: 
Experimental patch
config: x86_64-randconfig-m001-20200608 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0

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

smatch warnings:
kernel/sched/fair.c:447 find_matching_se() warn: inconsistent indenting

vim +447 kernel/sched/fair.c

   415  
   416  static void
   417  find_matching_se(struct sched_entity **se, struct sched_entity **pse)
   418  {
   419  trace_printk("S: se: %px (%d:%px) -> %px   pse: %px (%d:%px) -> 
%px\n",
   420  *se, (*se)->depth, (*se)->cfs_rq, 
parent_entity(*se),
   421  *pse, (*pse)->depth, (*pse)->cfs_rq, 
parent_entity(*pse));
   422  
   423  /*
   424   * preemption test can be made between sibling entities who are 
in the
   425   * same cfs_rq i.e who have a common parent. Walk up the 
hierarchy of
   426   * both tasks until we find their ancestors who are siblings of 
common
   427   * parent.
   428   */
   429  
   430  while (!is_same_group(*se, *pse)) {
   431  int se_depth = (*se)->depth;
   432  int pse_depth = (*pse)->depth;
   433  
   434  if (se_depth <= pse_depth) {
   435  struct sched_entity *parent = 
parent_entity(*pse);
   436  if (WARN_ON_ONCE(!parent))
   437  return;
   438  *pse = parent;
   439  }
   440  if (se_depth >= pse_depth) {
   441  struct sched_entity *parent = 
parent_entity(*se);
   442  if (WARN_ON_ONCE(!parent))
   443  return;
   444  *se = parent_entity(*se);
   445  }
   446  
 > 447  trace_printk("i: se: %px (%d:%px) -> %px   pse: %px (%d:%px) -> 
 > %px\n",
   448  *se, (*se)->depth, (*se)->cfs_rq, 
parent_entity(*se),
   449  *pse, (*pse)->depth, (*pse)->cfs_rq, 
parent_entity(*pse));
   450  }
   451  }
   452  

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


.config.gz
Description: application/gzip

[PATCH v6 5/5] drm/msm/dpu: add display port support in DPU

[Tanmay Shah]

From: Jeykumar Sankaran 

Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.

This change is based on the Snapdragon Display port
driver changes[1].

changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
  switch cases (Jordan Crouse)

[1] https://lwn.net/Articles/768265/
[2] https://lkml.org/lkml/2018/11/17/87

changes in V3:
-- Moved this change as part of the DP driver changes.
-- Addressed compilation issues on the latest code base.

Changes in v6:
-- Fix checkpatch.pl warning

Signed-off-by: Jeykumar Sankaran 
Signed-off-by: Chandan Uddaraju 
Signed-off-by: Vara Reddy 
Signed-off-by: Tanmay Shah 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  8 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 65 -
 2 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index d796710..745d5ce 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2017,7 +2017,7 @@ static int dpu_encoder_setup_display(struct 
dpu_encoder_virt *dpu_enc,
 {
int ret = 0;
int i = 0;
-   enum dpu_intf_type intf_type;
+   enum dpu_intf_type intf_type = INTF_NONE;
struct dpu_enc_phys_init_params phys_params;
 
if (!dpu_enc) {
@@ -2039,9 +2039,9 @@ static int dpu_encoder_setup_display(struct 
dpu_encoder_virt *dpu_enc,
case DRM_MODE_ENCODER_DSI:
intf_type = INTF_DSI;
break;
-   default:
-   DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
-   return -EINVAL;
+   case DRM_MODE_ENCODER_TMDS:
+   intf_type = INTF_DP;
+   break;
}
 
WARN_ON(disp_info->num_of_h_tiles < 1);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index b8615d4..f6c219f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -492,6 +492,33 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
return rc;
 }
 
+static int _dpu_kms_initialize_displayport(struct drm_device *dev,
+   struct msm_drm_private *priv,
+   struct dpu_kms *dpu_kms)
+{
+   struct drm_encoder *encoder = NULL;
+   int rc = 0;
+
+   if (!priv->dp)
+   return rc;
+
+   encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+   if (IS_ERR(encoder)) {
+   DPU_ERROR("encoder init failed for dsi display\n");
+   return PTR_ERR(encoder);
+   }
+
+   rc = msm_dp_modeset_init(priv->dp, dev, encoder);
+   if (rc) {
+   DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+   drm_encoder_cleanup(encoder);
+   return rc;
+   }
+
+   priv->encoders[priv->num_encoders++] = encoder;
+   return rc;
+}
+
 /**
  * _dpu_kms_setup_displays - create encoders, bridges and connectors
  *   for underlying displays
@@ -504,12 +531,21 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
 {
-   /**
-* Extend this function to initialize other
-* types of displays
-*/
+   int rc = 0;
+
+   rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+   if (rc) {
+   DPU_ERROR("initialize_dsi failed, rc = %d\n", rc);
+   return rc;
+   }
 
-   return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+   rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+   if (rc) {
+   DPU_ERROR("initialize_DP failed, rc = %d\n", rc);
+   return rc;
+   }
+
+   return rc;
 }
 
 static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -694,13 +730,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms *kms,
info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
 
-   /* TODO: No support for DSI swap */
-   for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
-   if (priv->dsi[i]) {
-   info.h_tile_instance[info.num_of_h_tiles] = i;
-   info.num_of_h_tiles++;
+   switch (info.intf_type) {
+   case DRM_MODE_ENCODER_DSI:
+   /* TODO: No support for DSI swap */
+   for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+   if (priv->dsi[i]) {
+   info.h_tile_instance[info.num_of_h_tiles] = i;
+   info.num_of_h_tiles++;
+   }
}
-   }
+   break;
+   case 

[PATCH v6 4/5] drm/msm/dp: add support for DP PLL driver

[Tanmay Shah]

From: Chandan Uddaraju 

Add the needed DP PLL specific files to support
display port interface on msm targets.

The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.

Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.

Changes in v4:
-- Update the DP link clock provider names

Changes in V5:
-- Addressed comments from Stephen Boyd, Rob clark.

Changes in V6:
-- Remove PLL as separate driver and include PLL as DP module
-- Remove redundant clock parsing from PLL module and make DP as
   clock provider
-- Map USB3 DPCOM and PHY IO using hardcoded register address and
   move mapping form parser to PLL module
-- Access DP PHY modules from same base address using offsets instead of
   deriving base address of individual module from device tree.
-- Remove dp_pll_10nm_util.c and include its functionality in
   dp_pll_10nm.c
-- Introduce new data structures private to PLL module

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Vara Reddy 
Signed-off-by: Tanmay Shah 
---
 drivers/gpu/drm/msm/Kconfig |  13 +
 drivers/gpu/drm/msm/Makefile|   3 +
 drivers/gpu/drm/msm/dp/dp_catalog.c |  64 ++-
 drivers/gpu/drm/msm/dp/dp_display.c |  17 +-
 drivers/gpu/drm/msm/dp/dp_display.h |   3 +
 drivers/gpu/drm/msm/dp/dp_parser.c  |  51 +-
 drivers/gpu/drm/msm/dp/dp_parser.h  |   9 +-
 drivers/gpu/drm/msm/dp/dp_pll.c |  93 
 drivers/gpu/drm/msm/dp/dp_pll.h |  59 +++
 drivers/gpu/drm/msm/dp/dp_pll_10nm.c| 903 
 drivers/gpu/drm/msm/dp/dp_pll_private.h | 103 
 drivers/gpu/drm/msm/dp/dp_power.c   |  10 +
 drivers/gpu/drm/msm/dp/dp_power.h   |  71 ++-
 drivers/gpu/drm/msm/dp/dp_reg.h |  16 +
 14 files changed, 1349 insertions(+), 66 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.c
 create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.h
 create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_10nm.c
 create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_private.h

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index ea3c4d0..43544c1 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -65,6 +65,19 @@ config DRM_MSM_DP
  display support is enabled through this config option. It can
  be primary or secondary display on device.
 
+config DRM_MSM_DP_PLL
+   bool "Enable DP PLL driver in MSM DRM"
+   depends on DRM_MSM_DP && COMMON_CLK
+   help
+ Choose this option to enable DP PLL driver which provides DP
+ source clocks under common clock framework.
+
+config DRM_MSM_DP_10NM_PLL
+   bool "Enable DP 10nm PLL driver in MSM DRM (used by SDM845)"
+   depends on DRM_MSM_DP_PLL
+   help
+ Choose this option if DP PLL on SDM845 is used on the platform.
+
 config DRM_MSM_DSI
bool "Enable DSI support in MSM DRM driver"
depends on DRM_MSM
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index af868e7..af259c6 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -140,4 +140,7 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/pll/dsi_pll_14nm.o
 msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
 endif
 
+msm-$(CONFIG_DRM_MSM_DP_PLL)+= dp/dp_pll.o
+msm-$(CONFIG_DRM_MSM_DP_10NM_PLL)+= dp/dp_pll_10nm.o
+
 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c 
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index d02f4eb..2b982f0 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -5,6 +5,7 @@
 
 #define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
 
+#include 
 #include 
 #include 
 #include 
@@ -134,59 +135,61 @@ static inline void dp_write_ahb(struct dp_catalog_private 
*catalog,
writel(data, catalog->io->dp_controller.base + offset);
 }
 
-static inline u32 dp_read_cc(struct dp_catalog_private *catalog, u32 offset)
-{
-   return readl_relaxed(catalog->io->dp_cc_io.base + offset);
-}
-
 static inline void dp_write_phy(struct dp_catalog_private *catalog,
   u32 offset, u32 data)
 {
+   offset += DP_PHY_REG_OFFSET;
/*
 * To make sure phy reg writes happens before any other operation,
 * this function uses writel() instread of writel_relaxed()
 */
-   writel(data, catalog->io->phy_io.base + offset);
+   writel(data, catalog->io->phy_reg.base + offset);
 }
 
 static inline u32 dp_read_phy(struct dp_catalog_private *catalog,
   u32 offset)
 {
+   offset += DP_PHY_REG_OFFSET;
/*
 * To make sure phy reg writes happens before any other operation,
 * this function uses writel() instread of writel_relaxed()
 */
-   return readl_relaxed(catalog->io->phy_io.base + offset);
+   return readl_relaxed(catalog->io->phy_reg.base + offset);
 }
 
 static 

Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations

[Stefano Stabellini]

On Mon, 8 Jun 2020, Stefano Stabellini wrote:
> On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> > On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote:
> > > From: Stefano Stabellini 
> > > 
> > > With some devices physical addresses are different than dma addresses.
> > > To be able to deal with these cases, we need to call phys_to_dma on
> > > physical addresses (including machine addresses in Xen terminology)
> > > before returning them from xen_swiotlb_alloc_coherent and
> > > xen_swiotlb_map_page.
> > > 
> > > We also need to convert dma addresses back to physical addresses using
> > > dma_to_phys in xen_swiotlb_free_coherent and xen_swiotlb_unmap_page if
> > > we want to do any operations on them.
> > > 
> > > Call dma_to_phys in is_xen_swiotlb_buffer.
> > > Call phys_to_dma in xen_phys_to_bus.
> > > Call dma_to_phys in xen_bus_to_phys.
> > > 
> > > Everything is taken care of by these changes except for
> > > xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a
> > > few explicit phys_to_dma/dma_to_phys calls.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > Tested-by: Corey Minyard 
> > > Tested-by: Roman Shaposhnik 
> > > ---
> > > Changes in v2:
> > > - improve commit message
> > > ---
> > >  drivers/xen/swiotlb-xen.c | 22 --
> > >  1 file changed, 12 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > > index 0a6cb67f0fc4..60ef07440905 100644
> > > --- a/drivers/xen/swiotlb-xen.c
> > > +++ b/drivers/xen/swiotlb-xen.c
> > > @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct 
> > > device *dev, phys_addr_t paddr)
> > >  
> > >   dma |= paddr & ~XEN_PAGE_MASK;
> > >  
> > > - return dma;
> > > + return phys_to_dma(dev, dma);
> > 
> > So looking at this function:
> > 
> > The dma name for something passed to phys_to_dma is really
> > weird.
> 
> Yeah, that is true, I am not sure why I chose that confusing name. I'll
> rename it.
> 
> 
> > The fact that the comments says don't use XEN_PFN_PHYS
> > beause of the type mismatch while nothing but swiotlb-xen is the only
> > user of XEN_PFN_PHYS is also weird.  I think XEN_PFN_PHYS needs to move
> > to swiotlb-xen first, then use a hardcoded u64 for the size, and the
> > split the function into a phys_to_xen_phys (or so) function where
> > the result gets passed to phys_to_dma.
> 
> I understand what you are suggesting about having something like:
> 
> xen_phys_to_dma(...)
> {
> phys_addr_t phys = xen_phys_to_bus(dev, paddr)
> return phys_to_dma(phys);
> }
> 
> I thought about it myself. I'll do it.
> 
> But I don't think I understood the comment about XEN_PFN_PHYS.

You meant to move the #define from the header to swiotlb-xen.c, didn't
you, and to use a cast to u64 instead of phys_addr_t?

Re: [PATCH v2 1/3] capabilities: Introduce CAP_CHECKPOINT_RESTORE

[Andrei Vagin]

On Wed, Jun 03, 2020 at 06:23:26PM +0200, Adrian Reber wrote:
> This patch introduces CAP_CHECKPOINT_RESTORE, a new capability facilitating
> checkpoint/restore for non-root users.
> 
> Over the last years, The CRIU (Checkpoint/Restore In Userspace) team has been
> asked numerous times if it is possible to checkpoint/restore a process as
> non-root. The answer usually was: 'almost'.
> 
> The main blocker to restore a process as non-root was to control the PID of 
> the
> restored process. This feature available via the clone3 system call, or via
> /proc/sys/kernel/ns_last_pid is unfortunately guarded by CAP_SYS_ADMIN.
> 
> In the past two years, requests for non-root checkpoint/restore have increased
> due to the following use cases:
> * Checkpoint/Restore in an HPC environment in combination with a resource
>   manager distributing jobs where users are always running as non-root.
>   There is a desire to provide a way to checkpoint and restore long running
>   jobs.
> * Container migration as non-root
> * We have been in contact with JVM developers who are integrating
>   CRIU into a Java VM to decrease the startup time. These checkpoint/restore
>   applications are not meant to be running with CAP_SYS_ADMIN.
> 
...
> 
> The introduced capability allows to:
> * Control PIDs when the current user is CAP_CHECKPOINT_RESTORE capable
>   for the corresponding PID namespace via ns_last_pid/clone3.
> * Open files in /proc/pid/map_files when the current user is
>   CAP_CHECKPOINT_RESTORE capable in the root namespace, useful for recovering
>   files that are unreachable via the file system such as deleted files, or 
> memfd
>   files.

PTRACE_O_SUSPEND_SECCOMP is needed for C/R and it is protected by
CAP_SYS_ADMIN too.

Thanks,
Andrei

Re: [PATCH V3 3/3] mmc: sdhci-msm: Use internal voltage control

[Veerabhadrarao Badiganti]

Hi Bjorn,

Do you have any comments on V3 patchset?

Thanks
Veera

On 6/2/2020 4:17 PM, Veerabhadrarao Badiganti wrote:


On qcom SD host controllers voltage switching be done after the HW
is ready for it. The HW informs its readiness through power irq.
The voltage switching should happen only then.

Use the internal voltage switching and then control the voltage
switching using power irq.

Set the regulator load as well so that regulator can be configured
in LPM mode when in is not being used.

Co-developed-by: Asutosh Das 
Signed-off-by: Asutosh Das 
Co-developed-by: Vijay Viswanath 
Signed-off-by: Vijay Viswanath 
Co-developed-by: Veerabhadrarao Badiganti 
Signed-off-by: Veerabhadrarao Badiganti 
---
  drivers/mmc/host/sdhci-msm.c | 235 +--
  1 file changed, 226 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 95cd9735e9a3..20ef90fc7dd7 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -36,7 +36,9 @@
  #define CORE_PWRCTL_IO_LOWBIT(2)
  #define CORE_PWRCTL_IO_HIGH   BIT(3)
  #define CORE_PWRCTL_BUS_SUCCESS BIT(0)
+#define CORE_PWRCTL_BUS_FAILBIT(1)
  #define CORE_PWRCTL_IO_SUCCESSBIT(2)
+#define CORE_PWRCTL_IO_FAIL BIT(3)
  #define REQ_BUS_OFF   BIT(0)
  #define REQ_BUS_ONBIT(1)
  #define REQ_IO_LOWBIT(2)
@@ -277,6 +279,8 @@ struct sdhci_msm_host {
bool uses_tassadar_dll;
u32 dll_config;
u32 ddr_config;
+   u32 vqmmc_load;
+   bool vqmmc_enabled;
  };
  
  static const struct sdhci_msm_offset *sdhci_priv_msm_offset(struct sdhci_host *host)

@@ -1339,6 +1343,91 @@ static void sdhci_msm_set_uhs_signaling(struct 
sdhci_host *host,
sdhci_msm_hs400(host, >ios);
  }
  
+static int sdhci_msm_set_vmmc(struct mmc_host *mmc)

+{
+   if (IS_ERR(mmc->supply.vmmc))
+   return 0;
+
+   return mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, mmc->ios.vdd);
+}
+
+static int msm_toggle_vqmmc(struct sdhci_msm_host *msm_host,
+ struct mmc_host *mmc, bool level)
+{
+   int ret;
+   struct mmc_ios ios;
+
+   if (msm_host->vqmmc_enabled == level)
+   return 0;
+
+   if (level) {
+   /* Set the IO voltage regulator to default voltage level */
+   if (msm_host->caps_0 & CORE_3_0V_SUPPORT)
+   ios.signal_voltage = MMC_SIGNAL_VOLTAGE_330;
+   else if (msm_host->caps_0 & CORE_1_8V_SUPPORT)
+   ios.signal_voltage = MMC_SIGNAL_VOLTAGE_180;
+
+   if (msm_host->caps_0 & CORE_VOLT_SUPPORT) {
+   ret = mmc_regulator_set_vqmmc(mmc, );
+   if (ret < 0) {
+   dev_err(mmc_dev(mmc), "%s: vqmmc set volgate failed: 
%d\n",
+   mmc_hostname(mmc), ret);
+   goto out;
+   }
+   }
+   ret = regulator_enable(mmc->supply.vqmmc);
+   } else {
+   ret = regulator_disable(mmc->supply.vqmmc);
+   }
+
+   if (ret)
+   dev_err(mmc_dev(mmc), "%s: vqmm %sable failed: %d\n",
+   mmc_hostname(mmc), level ? "en":"dis", ret);
+   else
+   msm_host->vqmmc_enabled = level;
+out:
+   return ret;
+}
+
+static int msm_config_vqmmc_mode(struct sdhci_msm_host *msm_host,
+ struct mmc_host *mmc, bool hpm)
+{
+   int load, ret;
+
+   if (!msm_host->vqmmc_load)
+   return 0;
+
+   load = hpm ? msm_host->vqmmc_load : 0;
+   ret = regulator_set_load(mmc->supply.vqmmc, load);
+   if (ret)
+   dev_err(mmc_dev(mmc), "%s: vqmmc set load failed: %d\n",
+   mmc_hostname(mmc), ret);
+   return ret;
+}
+
+static int sdhci_msm_set_vqmmc(struct sdhci_msm_host *msm_host,
+ struct mmc_host *mmc, bool level)
+{
+   int ret;
+   bool always_on;
+
+   if (IS_ERR(mmc->supply.vqmmc)||
+   (mmc->ios.power_mode == MMC_POWER_UNDEFINED))
+   return 0;
+   /*
+* For eMMC don't turn off Vqmmc, Instead just configure it in LPM
+* and HPM modes by setting the right amonut of load.
+*/
+   always_on = mmc->card && mmc_card_mmc(mmc->card);
+
+   if (always_on)
+   ret = msm_config_vqmmc_mode(msm_host, mmc, level);
+   else
+   ret = msm_toggle_vqmmc(msm_host, mmc, level);
+
+   return ret;
+}
+
  static inline void sdhci_msm_init_pwr_irq_wait(struct sdhci_msm_host 
*msm_host)
  {
init_waitqueue_head(_host->pwr_irq_wait);
@@ -1442,8 +1531,9 @@ static void sdhci_msm_handle_pwr_irq(struct sdhci_host 
*host, int irq)
  {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_msm_host *msm_host = 

Lieber Freund (Assalamu Alaikum),?

[AISHA GADDAFI]

-- 
Lieber Freund (Assalamu Alaikum),

Ich bin vor einer privaten Suche auf Ihren E-Mail-Kontakt gestoßen
Ihre Hilfe. Mein Name ist Aisha Al-Qaddafi, eine alleinerziehende
Mutter und eine Witwe
mit drei Kindern. Ich bin die einzige leibliche Tochter des Spätlibyschen
Präsident (verstorbener Oberst Muammar Gaddafi).

Ich habe Investmentfonds im Wert von siebenundzwanzig Millionen
fünfhunderttausend
United State Dollar ($ 27.500.000.00) und ich brauche eine
vertrauenswürdige Investition
Manager / Partner aufgrund meines aktuellen Flüchtlingsstatus bin ich jedoch
Möglicherweise interessieren Sie sich für die Unterstützung von
Investitionsprojekten in Ihrem Land
Von dort aus können wir in naher Zukunft Geschäftsbeziehungen aufbauen.

Ich bin bereit, mit Ihnen über das Verhältnis zwischen Investition und
Unternehmensgewinn zu verhandeln
Basis für die zukünftige Investition Gewinne zu erzielen.

Wenn Sie bereit sind, dieses Projekt in meinem Namen zu bearbeiten,
antworten Sie bitte dringend
Damit ich Ihnen mehr Informationen über die Investmentfonds geben kann.

Ihre dringende Antwort wird geschätzt. schreibe mir an diese email adresse (
ayishagdda...@mail.ru ) zur weiteren Diskussion.

Freundliche Grüße
Frau Aisha Al-Qaddafi

linux-next: build warning after merge of the vhost tree

[Stephen Rothwell]

Hi all,

After merging the vhost tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/device.h:15,
 from include/linux/virtio.h:9,
 from drivers/virtio/virtio_mem.c:10:
drivers/virtio/virtio_mem.c: In function 'virtio_mem_init':
drivers/virtio/virtio_mem.c:1720:27: warning: format '%x' expects argument of 
type 'unsigned int', but argument 3 has type 'uint64_t' {aka 'long long 
unsigned int'} [-Wformat=]
 1720 |  dev_info(>vdev->dev, "subblock size: 0x%x",
  |   ^
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
   19 | #define dev_fmt(fmt) fmt
  |  ^~~
drivers/virtio/virtio_mem.c:1720:2: note: in expansion of macro 'dev_info'
 1720 |  dev_info(>vdev->dev, "subblock size: 0x%x",
  |  ^~~~
drivers/virtio/virtio_mem.c:1720:46: note: format string is defined here
 1720 |  dev_info(>vdev->dev, "subblock size: 0x%x",
  | ~^
  |  |
  |  unsigned int
  | %llx

Introduced by commit

  676fa9ba893e ("virtio_mem: convert device block size into 64bit")

-- 
Cheers,
Stephen Rothwell


pgpNf66N8brdr.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 2/2] regulator: Add support for sync_state() callbacks

[Saravana Kannan]

On Mon, Jun 1, 2020 at 10:23 AM Mark Brown  wrote:
>
> On Fri, May 29, 2020 at 07:39:33PM -0700, Saravana Kannan wrote:
> > On Fri, May 29, 2020 at 6:00 AM Mark Brown  wrote:
> > > On Thu, May 28, 2020 at 12:06:10PM -0700, Saravana Kannan wrote:
>
> > > > especially important for regulators that might be powering more than one
> > > > consumer. Otherwise, when the first consumer probes, enables and then
> > > > disables the "boot on" regulator, it'd turn off the power to rest of the
> > > > consumers of the "boot on" regulator.
>
> > > Which is a problem because...?
>
> > Those consumers that haven't probed can be powered on and active and
> > can crash the system if the power is pulled under their feet.
>
> This is I think the first time anyone has suggested that this is likely
> to be an issue - the previous concerns have all been about screens
> glitching.

Looks like we got at least one concrete example now in [1].

>
> > > > The sync_state() callback that's been added to drivers is meant for
> > > > situations like this. It gets called when all the consumers of a device
> > > > have probed successfully. To ease the transition to sync_state()
> > > > callbacks, it is never called before late_initcall_sync().
>
> > > This is not terribly useful for regulators where adding any of these
> > > delays is going to create surprises.  Frankly I can't really see why
> > > deferring things until late_initcall() would help anything.
>
> > Is this different from what's done already?
>
> At the minute we implement any requested changes immediately.
>
> >  Not having this delay is
> > easy -- but will have to be at a global level across
> > devices/resources.
>
> That seems fine given that there appears to be no reason to introduce a
> delay.
>
> > > > +static void regulator_set_minimum_state(struct regulator_dev *rdev)
> > > > +{
>
> > > I find this name very confusing.  If anything it's doing the opposite of
> > > setting a minimum state, it's trying to prevent that happening.
>
> > I agree. I renamed it to try and make it better, but I can see how
> > it's more confusing once you called it out. Suggestions?
>
> > regulator_set_boot_limits? regulator_set_boot_constraints?
>
> ignore_consumer_requests()?

But it doesn't really ignore consumer requests though. In response to
all your comments above, I haven't done a good job of explaining the
issues and the solution. I'll try to redo that part again when I send
v3 and hopefully I can do better.

> > > > + /*
> > > > +  * Wait for parent supply to be ready before trying to keep this
> > > > +  * regulator on.
> > > > +  */
> > > > + if (rdev->supply_name && !rdev->supply)
> > > > + return;
>
> > > I can't make sense of this.  This stuff only limits disabling, not
> > > enabling, regulators, we're keeping things on here anyway and why would
> > > we care about the supply for disabling?
>
> > We want to wait till supply is set up before we try to put the
> > "enable" vote on a regulator. Otherwise, it won't be propagated
> > properly? I do know that regulator_resolve_supply() takes care of
> > propagating the use count, but we could delete that code if we just
> > till the supply is resolved before "enabling" the regulator. The usual
> > clients can't "get" the regulator anyway without the supply being
> > resolved. Long story short, doing it this way can allow us to delete
> > some functionally duplicative code.
>
> So this is to support some future change that you either haven't
> written or haven't sent out yet.  Please don't do stuff like this, it
> makes everything more confusing.  Send out isolated, coherent changes
> that do a single thing per patch, if there's things you're thinking of
> for future work then save them for when you actually do that future
> work.  That makes everything clearer and easier to follow.

Ok. Thinking more about it, when I try to add voltage handling, I'll
need to call regulator_get_voltage_rdev(). So I might still need to
wait till supply is set up. However, if I don't really need it, I'll
make sure to drop any "future improvements" related changes.

> > > I've just realised that this is even more restrictive than the
> > > descriptions have suggested - it's not just preventing any changes until
> > > all potential consumers of a given regulator have instantiated, it's
> > > preventing changes until all potential consumers of all resources
> > > provided by a given device have instantiated.  Given that many systems
> > > have a single PMIC which may also be providing other things like GPIOs
> > > that would mean that any consumer that doesn't instantiate would prevent
> > > any device getting turned off which seems even more concerning.
>
> > Your understanding is correct. I'll try to clarify the commit text as
> > best as I can. Your concerns are why this is not the default behavior.
>
> My concern is that introducing extra delays is likely to make things
> 

[PATCH] x86/cpu: Use pinning mask for CR4 bits needing to be 0

[Kees Cook]

The X86_CR4_FSGSBASE bit of CR4 should not change after boot[1]. Older
kernels should enforce this bit to zero, and newer kernels need to
enforce it depending on boot-time configuration (e.g. "nofsgsbase").
To support a pinned bit being either 1 or 0, use an explicit mask in
combination with the expected pinned bit values.

[1] 
https://lore.kernel.org/lkml/20200527103147.gi325...@hirez.programming.kicks-ass.net

Signed-off-by: Kees Cook 
---
 arch/x86/kernel/cpu/common.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index bed0cb83fe24..677a7d593a04 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -347,6 +347,9 @@ static __always_inline void setup_umip(struct cpuinfo_x86 
*c)
cr4_clear_bits(X86_CR4_UMIP);
 }
 
+/* These bits should not change their value after CPU init is finished. */
+static const unsigned long cr4_pinned_mask =
+   X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP | X86_CR4_FSGSBASE;
 static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning);
 static unsigned long cr4_pinned_bits __ro_after_init;
 
@@ -371,20 +374,20 @@ EXPORT_SYMBOL(native_write_cr0);
 
 void native_write_cr4(unsigned long val)
 {
-   unsigned long bits_missing = 0;
+   unsigned long bits_changed = 0;
 
 set_register:
asm volatile("mov %0,%%cr4": "+r" (val), "+m" (cr4_pinned_bits));
 
if (static_branch_likely(_pinning)) {
-   if (unlikely((val & cr4_pinned_bits) != cr4_pinned_bits)) {
-   bits_missing = ~val & cr4_pinned_bits;
-   val |= bits_missing;
+   if (unlikely((val & cr4_pinned_mask) != cr4_pinned_bits)) {
+   bits_changed = (val & cr4_pinned_mask) ^ 
cr4_pinned_bits;
+   val = (val & ~cr4_pinned_mask) | cr4_pinned_bits;
goto set_register;
}
-   /* Warn after we've set the missing bits. */
-   WARN_ONCE(bits_missing, "CR4 bits went missing: %lx!?\n",
- bits_missing);
+   /* Warn after we've corrected the changed bits. */
+   WARN_ONCE(bits_changed, "pinned CR4 bits changed: 0x%lx!?\n",
+ bits_changed);
}
 }
 EXPORT_SYMBOL(native_write_cr4);
@@ -396,7 +399,7 @@ void cr4_init(void)
if (boot_cpu_has(X86_FEATURE_PCID))
cr4 |= X86_CR4_PCIDE;
if (static_branch_likely(_pinning))
-   cr4 |= cr4_pinned_bits;
+   cr4 = (cr4 & ~cr4_pinned_mask) | cr4_pinned_bits;
 
__write_cr4(cr4);
 
@@ -411,10 +414,7 @@ void cr4_init(void)
  */
 static void __init setup_cr_pinning(void)
 {
-   unsigned long mask;
-
-   mask = (X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP);
-   cr4_pinned_bits = this_cpu_read(cpu_tlbstate.cr4) & mask;
+   cr4_pinned_bits = this_cpu_read(cpu_tlbstate.cr4) & cr4_pinned_mask;
static_key_enable(_pinning.key);
 }
 
-- 
2.25.1


-- 
Kees Cook

Re: FATAL: drivers/phy/intel/phy-intel-emmc: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_of___device_table=512.

[Ramuthevar, Vadivel MuruganX]

Hi,

On 8/6/2020 10:23 am, kernel test robot wrote:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   af7b4801030c07637840191c69eb666917e4135d
commit: 9227942383307f97fa6992416f73af4a23ef972c phy: intel-lgm-emmc: Add 
support for eMMC PHY
date:   5 months ago
config: x86_64-randconfig-a011-20200607 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
e429cffd4f228f70c1d9df0e5d77c08590dd9766)
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
 git checkout 9227942383307f97fa6992416f73af4a23ef972c
 # 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 errors (new ones prefixed by >>, old ones prefixed by <<):

WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/intel/phy-intel-emmc.o
see include/linux/module.h for more information

FATAL: drivers/phy/intel/phy-intel-emmc: sizeof(struct of_device_id)=200 is not a 
modulo of the size of section __mod_of___device_table=512.

Fix definition of struct of_device_id in mod_devicetable.h

Thanks for the report!

Noted, will fix it.

Regards
Vadivel



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

Re: [PATCH] dtc: also check for libyaml

[Jiping Ma]

On 06/09/2020 10:52 AM, Masahiro Yamada wrote:

On Tue, Jun 9, 2020 at 10:01 AM Jiping Ma  wrote:



On 06/09/2020 03:09 AM, Rob Herring wrote:

On Mon, Jun 8, 2020 at 2:42 AM Jiping Ma  wrote:

yamltree.c includes , If /usr/include/yaml.h does not exist,
it fails to build.

Does this patch fix your issue?:

https://lore.kernel.org/linux-devicetree/20200505100319.741454-1-masahi...@kernel.org/

No, it did not fix the issue.

$ pkg-config --cflags yaml-0.1

$ pkg-config yaml-0.1 --libs
-L/buildarea/jma1/wr-19-0518/19.45/sysroots/aarch64-wrs-linux/usr/lib64
-lyaml
This issue happened in Yocto,  After completing the SDK build and 
installing it, use a new shell to source the environment and try to 
build the helper scripts.
export 
SDKTARGETSYSROOT=/buildarea/jma1/wr-19-0518/19.45/sysroots/aarch64-wrs-linux
export 
PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib64/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig




If I install libyaml to a non-standard location
(/home/masahiro/foo), my pkg-config shows as follows:



masahiro@oscar:~$ pkg-config --cflags   yaml-0.1
-I/home/masahiro/foo/include
masahiro@oscar:~$ pkg-config --libs   yaml-0.1
-L/home/masahiro/foo/lib -lyaml










Signed-off-by: Jiping Ma 
---
   scripts/dtc/Makefile | 4 
   1 file changed, 4 insertions(+)

diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
index b5a5b1c..b49dfea 100644
--- a/scripts/dtc/Makefile
+++ b/scripts/dtc/Makefile
@@ -18,9 +18,13 @@ $(error dtc needs libyaml for DT schema validation support. \
   endif
   HOST_EXTRACFLAGS += -DNO_YAML
   else
+ifeq ($(wildcard /usr/include/yaml.h),)
+HOST_EXTRACFLAGS += -DNO_YAML
+else
   dtc-objs   += yamltree.o
   HOSTLDLIBS_dtc := $(shell pkg-config yaml-0.1 --libs)
   endif
+endif

   # Generated files need one more search path to include headers in source tree
   HOSTCFLAGS_dtc-lexer.lex.o := -I $(srctree)/$(src)
--
1.9.1

Re: [PATCH RFC v4 00/13] virtio-mem: paravirtualized memory

[Alex Shi]

在 2020/6/5 下午8:18, David Hildenbrand 写道:
> On 05.06.20 12:46, Alex Shi wrote:
>>
>>
>> 在 2020/6/5 下午6:05, David Hildenbrand 写道:
 I guess I know what's happening here. In case we only have DMA memory
 when booting, we don't reserve swiotlb buffers. Once we hotplug memory
 and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to
 map such PFNs (total 0 (slots), used 0 (slots)).

 Can you try with "swiotlb=force" on the kernel cmdline?
>>> Alternative, looks like you can specify "-m 2G,maxmem=16G,slots=1", to
>>> create proper ACPI tables that indicate hotpluggable memory. (I'll have
>>> to look into QEMU to figure out to always indicate hotpluggable memory
>>> that way).
>>>
>>
>>
>> That works too. Yes, better resolved in qemu, maybe. :)
>>
> 
> You can checkout
> 
> g...@github.com:davidhildenbrand/qemu.git virtio-mem-v4

yes, it works for me. Thanks!

> 
> (prone to change before officially sent), which will create srat tables
> also if no "slots" parameter was defined (and no -numa config was
> specified).
> 
> Your original example should work with that.
> 

Re: [PATCH 1/1] psi: eliminate kthread_worker from psi trigger scheduling mechanism

[Suren Baghdasaryan]

On Thu, Jun 4, 2020 at 12:20 PM Suren Baghdasaryan  wrote:
>
> On Thu, Jun 4, 2020 at 6:12 AM Peter Zijlstra  wrote:
> >
> > On Thu, May 28, 2020 at 12:54:42PM -0700, Suren Baghdasaryan wrote:
> > > Each psi group requires a dedicated kthread_delayed_work and
> > > kthread_worker. Since no other work can be performed using psi_group's
> > > kthread_worker, the same result can be obtained using a task_struct and
> > > a timer directly. This makes psi triggering simpler by removing lists
> > > and locks involved with kthread_worker usage and eliminates the need for
> > > poll_scheduled atomic use in the hot path.
> > >
> > > Signed-off-by: Suren Baghdasaryan 
> > > ---
> > > This patch is meant to address Peter's request in [1] to pull
> > > kthread_queue_delayed_work() out from under rq->lock. This should also 
> > > address
> > > the lockdep warning about possibility of a circular dependency described 
> > > in [2]
> >
> > I think you could've just fixed kthread_queue_delayed_work(), that code
> > is sub-optimal.

After some more staring into kthread code I think I understand what
Peter's comment meant about delayed_work_list.
worker->delayed_work_list seems to be unnecessary because each
kthread_delayed_work has its own timer which will add the work into
worker->work_list when the time comes. So there is no need to store
the delayed work in an intermediate worker->delayed_work_list.
However I think kthread_destroy_worker() has an issue if it's called
while worker->delayed_work_list is non-empty. The issue is that
kthread_destroy_worker() does not stop all the
kthread_delayed_work->timers scheduled on the
worker->delayed_work_list. So if such a timer fires after a call to
kthread_destroy_worker(), timer's handler will dereference the already
destroyed worker.

If I'm right and this is indeed an issue then I think we do need
worker->delayed_work_list to cancel all the scheduled timers. The
issue can be avoided if we assume that the caller will alway call
kthread_cancel_delayed_work_sync() for each delayed_work scheduled on
worker->delayed_work_list before calling kthread_destroy_worker(). If
that's what we expect I think this expectation should be reflected in
the comments and a WARN_ON(!list_empty(>delayed_work_list)) be
added in kthread_destroy_worker(). WDYT?

>
> Ok, let me look into it some more. My understanding was that the
> worker->lock in kthread_queue_delayed_work() was needed to synchronize
> worker->delayed_work_list access. But maybe I'm missing something... I
> assume you are talking about optimizing this beyond what
> https://lkml.org/lkml/2020/5/4/1148 was doing?
>
> BTW, any objections against taking https://lkml.org/lkml/2020/5/4/1148
> ? It's not the ultimate fix but it is an improvement since it gets
> some of the operations that were unnecessarily under worker->lock out
> of it.
>
> >
> > But I suppose this works too.
>
> In PSI's case there is always one work for each worker, so the
> delayed_work_list and work_list are not needed and therefore I can
> replace kthread_worker machinery with a task and a timer.
> I think I can simplify this a bit further. For example
> group->poll_wakeup doesn't have to be an atomic. Originally I wanted
> to avoid a possibility of a race when poll_timer_fn sets it and
> psi_poll_worker resets it and as a result misses a wakeup, however if
> psi_poll_worker resets it before calling psi_poll_work then there is
> no harm in missing a wakeup because we called psi_poll_work and did
> the required work anyway.
>
> One question about this patch I'm not sure about and wanted to ask you
> Peter is whether it's ok to call mod_timer from within a hotpath
> (while holding rq->lock). As I described in the additional comment,
> there is a possibility of a race between when I check timer_pending
> and the call to mod_timer, so it's possible that mod_timer might be
> called both from psi_poll_work (psi poll work handler) and from
> psi_task_change (hotpath under rq->lock). I see that mod_timer takes
> base->lock spinlock, and IIUC such a race might block the hotpath and
> therefore is unacceptable. If this is true I'll need to revive the
> poll_scheduled atomic to close this race and then I can change
> mod_timer into add_timer.
> WDYT? And sorry for my ignorance if this is a trivial question. I'm
> not sure about the rules when it comes to rq->locks.
>
> Thanks,
> Suren.
>
> >
> > --
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to kernel-team+unsubscr...@android.com.
> >

Re: [PATCH v6 1/7] fpga: dfl: parse interrupt info for feature devices on enumeration

[Xu Yilun]

On Mon, Jun 08, 2020 at 05:48:22PM -0700, Tom Rix wrote:
> I am not sure about the use of parse_feature_irqs.

This function will parse interrupt info for private features which
support interrupts. For now, 3 private features, FME error, Port error
& User interrupt (for AFU), are using interrupt for async notification.

> 
> If the irq parse fails, the feature fails to be created.  So an old afu 
> feature which loaded ok in an older kernel can fail.  This could surprise the 
> user.

The irq info is embedded in FPGA static region, which could not be
partially reprogrammed by user. So if the irq parse fails, it means
something is wrong in the fundamental part of the FPGA. The fail out
may help users find out the issue in early phase.

> 
> Below is a change that fails more gracefully.  Even if there is a problem in 
> the parse, the feature will be created. because the nr_irq's is 0, the irq 
> code should not execute.

Yes this is another way to handle the irq error. Actually it raised another
concern, which errors could be supressed and which should be failed out?
Now we conform to the critera that we try the best to ensure the FPGA
static region is reliable.

Thanks,
Yilun.

> 
> Tom
> 
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 125369c6c5b3..edba1e8410bd 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -708,11 +708,8 @@ static int parse_feature_irqs(struct 
> build_feature_devs_info *binfo,
>     break;
>     }
>  
> -   if (!inr) {
> -   *irq_base = 0;
> -   *nr_irqs = 0;
> +   if (!inr)
>     return 0;
> -   }
>  
>     dev_dbg(binfo->dev, "feature: 0x%llx, irq_base: %u, nr_irqs: %u\n",
>     fid, ibase, inr);
> @@ -751,9 +748,9 @@ create_feature_instance(struct build_feature_devs_info 
> *binfo,
>     struct dfl_fpga_enum_dfl *dfl, resource_size_t ofst,
>     resource_size_t size, u64 fid)
>  {
> -   unsigned int irq_base, nr_irqs;
> +   unsigned int irq_base = 0;
> +   unsigned int nr_irqs = 0;
>     struct dfl_feature_info *finfo;
> -   int ret;
>  
>     /* read feature size and id if inputs are invalid */
>     size = size ? size : feature_size(dfl->ioaddr + ofst);
> @@ -762,9 +759,7 @@ create_feature_instance(struct build_feature_devs_info 
> *binfo,
>     if (dfl->len - ofst < size)
>     return -EINVAL;
>  
> -   ret = parse_feature_irqs(binfo, ofst, fid, _base, _irqs);
> -   if (ret)
> -   return ret;
> +   parse_feature_irqs(binfo, ofst, fid, _base, _irqs);
>  
>     finfo = kzalloc(sizeof(*finfo), GFP_KERNEL);
>     if (!finfo)
> 
> On 6/4/20 1:52 AM, Xu Yilun wrote:
> > DFL based FPGA devices could support interrupts for different purposes,
> > but current DFL framework only supports feature device enumeration with
> > given MMIO resources information via common DFL headers. This patch
> > introduces one new API dfl_fpga_enum_info_add_irq for low level bus
> > drivers (e.g. PCIe device driver) to pass its interrupt resources
> > information to DFL framework for enumeration, and also adds interrupt
> > enumeration code in framework to parse and assign interrupt resources
> > for enumerated feature devices and their own sub features.
> >
> > With this patch, DFL framework enumerates interrupt resources for core
> > features, including PORT Error Reporting, FME (FPGA Management Engine)
> > Error Reporting and also AFU User Interrupts.
> >
> > Signed-off-by: Luwei Kang 
> > Signed-off-by: Wu Hao 
> > Signed-off-by: Xu Yilun 
> > Reviewed-by: Marcelo Tosatti 
> > Acked-by: Wu Hao 
> > 
> > v2: early validating irq table for each feature in parse_feature_irq().
> > Some code improvement and minor fix for Hao's comments.
> > v3: put parse_feature_irqs() inside create_feature_instance()
> > some minor fixes and more comments
> > v4: no need to include asm/irq.h.
> > fail the dfl enumeration when irq parsing error happens.
> > v5: Some minor fix for Hao's comments
> > v6: Remove unnecessary type casting.
> > Some comment fix for Moritz's comments.
> > ---
> >  drivers/fpga/dfl.c | 153 
> > +
> >  drivers/fpga/dfl.h |  40 ++
> >  2 files changed, 193 insertions(+)
> >
> > diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> > index 9909948..02c1ec4 100644
> > --- a/drivers/fpga/dfl.c
> > +++ b/drivers/fpga/dfl.c
> > @@ -421,6 +421,9 @@ EXPORT_SYMBOL_GPL(dfl_fpga_dev_ops_unregister);
> >   *
> >   * @dev: device to enumerate.
> >   * @cdev: the container device for all feature devices.
> > + * @nr_irqs: number of irqs for all feature devices.
> > + * @irq_table: Linux IRQ numbers for all irqs, indexed by local irq index 
> > of
> > + *this device.
> >   * @feature_dev: current feature device.
> >   * @ioaddr: header register region address of feature device in 
> > enumeration.

[PATCH] MIPS: Use arch specific syscall name match function

[Bibo Mao]

On MIPS system, most of the syscall function name begin with prefix
sys_. Some syscalls are special such as clone/fork, function name of
these begin with __sys_. Since scratch registers need be saved in
stack when these system calls happens.

With ftrace system call method, system call functions are declared with
SYSCALL_DEFINEx, metadata of the system call symbol name begins with
sys_. Here mips specific function arch_syscall_match_sym_name is used to
compare function name between sys_call_table[] and metadata of syscall
symbol.

Signed-off-by: Bibo Mao 
---
 arch/mips/include/asm/ftrace.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
index b463f2a..9b42115 100644
--- a/arch/mips/include/asm/ftrace.h
+++ b/arch/mips/include/asm/ftrace.h
@@ -87,4 +87,20 @@ struct dyn_arch_ftrace {
 #endif /*  CONFIG_DYNAMIC_FTRACE */
 #endif /* __ASSEMBLY__ */
 #endif /* CONFIG_FUNCTION_TRACER */
+
+#ifndef __ASSEMBLY__
+#ifdef CONFIG_FTRACE_SYSCALLS
+/*
+ * Some syscall entry functions on mips start with "__sys_" (fork and clone,
+ * for instance). We should also match the sys_ variant with those.
+ */
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+static inline bool arch_syscall_match_sym_name(const char *sym,
+  const char *name)
+{
+   return !strcmp(sym, name) ||
+   (!strncmp(sym, "__sys_", 6) && !strcmp(sym + 6, name + 4));
+}
+#endif /* CONFIG_FTRACE_SYSCALLS */
+#endif /* __ASSEMBLY__ */
 #endif /* _ASM_MIPS_FTRACE_H */
-- 
1.8.3.1

Re: [PATCH] dtc: also check for libyaml

[Masahiro Yamada]

On Tue, Jun 9, 2020 at 10:01 AM Jiping Ma  wrote:
>
>
>
> On 06/09/2020 03:09 AM, Rob Herring wrote:
> > On Mon, Jun 8, 2020 at 2:42 AM Jiping Ma  wrote:
> >> yamltree.c includes , If /usr/include/yaml.h does not exist,
> >> it fails to build.
> > Does this patch fix your issue?:
> >
> > https://lore.kernel.org/linux-devicetree/20200505100319.741454-1-masahi...@kernel.org/
> No, it did not fix the issue.
>
> $ pkg-config --cflags yaml-0.1
>
> $ pkg-config yaml-0.1 --libs
> -L/buildarea/jma1/wr-19-0518/19.45/sysroots/aarch64-wrs-linux/usr/lib64
> -lyaml




If I install libyaml to a non-standard location
(/home/masahiro/foo), my pkg-config shows as follows:



masahiro@oscar:~$ pkg-config --cflags   yaml-0.1
-I/home/masahiro/foo/include
masahiro@oscar:~$ pkg-config --libs   yaml-0.1
-L/home/masahiro/foo/lib -lyaml







> >
> >
> >> Signed-off-by: Jiping Ma 
> >> ---
> >>   scripts/dtc/Makefile | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> >> index b5a5b1c..b49dfea 100644
> >> --- a/scripts/dtc/Makefile
> >> +++ b/scripts/dtc/Makefile
> >> @@ -18,9 +18,13 @@ $(error dtc needs libyaml for DT schema validation 
> >> support. \
> >>   endif
> >>   HOST_EXTRACFLAGS += -DNO_YAML
> >>   else
> >> +ifeq ($(wildcard /usr/include/yaml.h),)
> >> +HOST_EXTRACFLAGS += -DNO_YAML
> >> +else
> >>   dtc-objs   += yamltree.o
> >>   HOSTLDLIBS_dtc := $(shell pkg-config yaml-0.1 --libs)
> >>   endif
> >> +endif
> >>
> >>   # Generated files need one more search path to include headers in source 
> >> tree
> >>   HOSTCFLAGS_dtc-lexer.lex.o := -I $(srctree)/$(src)
> >> --
> >> 1.9.1
> >>
>


-- 
Best Regards
Masahiro Yamada

RE: [RFC PATCH 2/2] drm: xlnx: driver for Xilinx DSI TX Subsystem

[Venkateshwar Rao Gannavarapu]

Hi Laurent,

Thanks for the review. 
Please see my comments about D-PHY and bridge driver implementation.

>-Original Message-
>From: Laurent Pinchart 
>Sent: Sunday, June 7, 2020 7:55 AM
>To: Venkateshwar Rao Gannavarapu 
>Cc: Hyun Kwon ; dri-de...@lists.freedesktop.org;
>airl...@linux.ie; dan...@ffwll.ch; linux-kernel@vger.kernel.org; Sandip Kothari
>
>Subject: Re: [RFC PATCH 2/2] drm: xlnx: driver for Xilinx DSI TX Subsystem
>
>Hi GVRao,
>
>On Sun, May 31, 2020 at 05:41:50PM +, Venkateshwar Rao Gannavarapu
>wrote:
>> On Sunday, May 24, 2020 8:38 AM, Laurent Pinchart wrote:
>> > On Mon, May 04, 2020 at 11:43:48AM -0700, Hyun Kwon wrote:
>> >> On Mon, 2020-04-20 at 14:20:56 -0700, Venkateshwar Rao Gannavarapu
>wrote:
>> >>> The Xilinx MIPI DSI Tx Subsystem soft IP is used to display video
>> >>> data from AXI-4 stream interface.
>> >>>
>> >>> It supports upto 4 lanes, optional register interface for the
>> >>> DPHY,
>> >>
>> >> I don't see the register interface for dphy support.
>> >
>> > I think the D-PHY should be supported through a PHY driver, as it
>> > seems to be shared between different subsystems.
>>
>> IP has the provision to read DPHY register for debug purpose only.
>> No programming of DPHY is required in subsystem.
>
>Do you know if this is the same D-PHY as used in the CSI2-RX subsystem ?
 
Same D-PHY core has been used in MIPI CSI2 RXSS, but with different 
configuration.
>
>> >>> multiple RGB color formats, command mode and video mode.
>> >>> This is a MIPI-DSI host driver and provides DSI bus for panels.
>> >>> This driver also helps to communicate with its panel using panel
>> >>> framework.
>> >>>
>> >>> Signed-off-by: Venkateshwar Rao Gannavarapu
>> >>> 
>> >>> ---
>> >>>  drivers/gpu/drm/xlnx/Kconfig|  11 +
>> >>>  drivers/gpu/drm/xlnx/Makefile   |   2 +
>> >>>  drivers/gpu/drm/xlnx/xlnx_dsi.c | 755
>> >>> 
>> >
>> > Daniel Vetter has recently expressed his opiion that bridge drivers
>> > should go to drivers/gpu/drm/bridge/. It would then be
>> > drivers/gpu/drm/bridge/xlnx/. I don't have a strong opinion myself.

The DSI-TX subsystem IP block is not a bridge driver.
The DSI-TX subsystem IP block itself contains all the drm encoder/connector
functionality and it’s the last node in display pipe line. I didn't see any hard
requirement to implement it into bridge driver and I see many DSI drivers are
implemented as encoder drivers.
Xilinx PL DRM encoder drivers are implemented in modular approach so that
they can work with any CRTC driver which handles the DMA calls.
So, at this stage we want to upstream as encoder driver only.
>> >
>> >>>  3 files changed, 768 insertions(+)  create mode 100644
>> >>> drivers/gpu/drm/xlnx/xlnx_dsi.c
>
>[snip]
>
>--
>Regards,
>
>Laurent Pinchart

Regards,
GVRao
 

RE: [PATCH v9 RESEND 01/13] spi: imx: add dma_sync_sg_for_device after fallback from dma

[Robin Gong]

On 2020/06/08 23:32 Mark Brown  wrote: 
> On Mon, Jun 08, 2020 at 03:08:45PM +, Robin Gong wrote:
> 
> > > > +   if (transfer->rx_sg.sgl) {
> > > > +   struct device *rx_dev = 
> > > > spi->controller->dma_rx->device->dev;
> > > > +
> > > > +   dma_sync_sg_for_device(rx_dev, transfer->rx_sg.sgl,
> > > > +  transfer->rx_sg.nents, 
> > > > DMA_TO_DEVICE);
> > > > +   }
> > > > +
> 
> > > This is confusing - why are we DMA mapping to the device after doing
> > > a PIO transfer?
> 
> > 'transfer->rx_sg.sgl' condition check that's the case fallback PIO
> > after DMA transfer failed. But the spi core still think the buffer
> > should be in 'device' while spi driver touch it by PIO(CPU), so sync it 
> > back to
> device to ensure all received data flush to DDR.
> 
> So we sync it back to the device so that we can then do another sync to CPU?
Yes, spi.c will sync to CPU again in spi_unmap_buf() after transfer done 
finally.
Otherwise, the fresh received data by CPU in this fallback case may be 
invalidated
by spi.c, which led to the data corrupt on Matthias's side.

> TBH I'm a bit surprised that there's a requirement that we explicitly undo a
> sync and that a redundant double sync in the same direction might be an issue
Considering DMA transfer may be failed(for example, sdma firmware may not be
updated as ERR009165 depends on), we'd better fallback to PIO to ensure no any
function break here. Thus should clean fresh rx data from cache into external 
memory
as real 'device' received by DMA. Understood a bit confusing here, but that way 
could
be avoided by any code changing in spi.c. Or make some code changes in spi.c to 
cancel
spi_unmap_buf() in such fallback case?

> but I've not had a need to care so I'm perfectly prepared to believe there is.
> 
> At the very least this needs a comment.
Okay, I'll add comment here in next.

Re: [PATCH] dtc: also check for libyaml

[Masahiro Yamada]

On Tue, Jun 9, 2020 at 10:01 AM Jiping Ma  wrote:
>
>
>
> On 06/09/2020 03:09 AM, Rob Herring wrote:
> > On Mon, Jun 8, 2020 at 2:42 AM Jiping Ma  wrote:
> >> yamltree.c includes , If /usr/include/yaml.h does not exist,
> >> it fails to build.
> > Does this patch fix your issue?:
> >
> > https://lore.kernel.org/linux-devicetree/20200505100319.741454-1-masahi...@kernel.org/
> No, it did not fix the issue.
>
> $ pkg-config --cflags yaml-0.1
>


Then, this is a problem on your system.






> $ pkg-config yaml-0.1 --libs
> -L/buildarea/jma1/wr-19-0518/19.45/sysroots/aarch64-wrs-linux/usr/lib64
> -lyaml
>
> >
> >
> >> Signed-off-by: Jiping Ma 
> >> ---
> >>   scripts/dtc/Makefile | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> >> index b5a5b1c..b49dfea 100644
> >> --- a/scripts/dtc/Makefile
> >> +++ b/scripts/dtc/Makefile
> >> @@ -18,9 +18,13 @@ $(error dtc needs libyaml for DT schema validation 
> >> support. \
> >>   endif
> >>   HOST_EXTRACFLAGS += -DNO_YAML
> >>   else
> >> +ifeq ($(wildcard /usr/include/yaml.h),)
> >> +HOST_EXTRACFLAGS += -DNO_YAML
> >> +else
> >>   dtc-objs   += yamltree.o
> >>   HOSTLDLIBS_dtc := $(shell pkg-config yaml-0.1 --libs)
> >>   endif
> >> +endif
> >>
> >>   # Generated files need one more search path to include headers in source 
> >> tree
> >>   HOSTCFLAGS_dtc-lexer.lex.o := -I $(srctree)/$(src)
> >> --
> >> 1.9.1
> >>
>


--
Best Regards
Masahiro Yamada

Re: [PATCH] regulator: do not balance 'boot-on' coupled regulators without constraints

[Saravana Kannan]

On Fri, Jun 5, 2020 at 8:59 AM Mark Brown  wrote:
>
> On Fri, Jun 05, 2020 at 03:37:32PM +0200, Marek Szyprowski wrote:
> > On 05.06.2020 12:20, Mark Brown wrote:
>
> > > No, this is not what boot-on means at all.  It is there for cases where
> > > we can't read the enable status from the hardware.  Trying to infer
> > > *anything* about the runtime behaviour from it being present or absent
> > > is very badly broken.
>
> > Okay, what about the 'always-on' property? I don't think that we need
> > another property for annotating this behavior, as in my opinion this is
>
> No, that's just as disconnected from the need - we may as well do it
> based on the regulator name being an odd number of characters.
>
> > just an implementation issue on the Linux kernel and regulator
> > framework. Alternatively I can drop the property check, but then it
> > won't be possible to have a regulator without a consumer, which follows
> > the other one (although we still don't have a real use case for it).
>
> > If you don't like this idea at all, I will try to move this logic to the
> > custom coupler again, although it would mean some code copying.
>
> I think that's better TBH.
>
> > > Saravana (CCed) was working on some patches which tried to deal with
> > > some stuff around this for enables using the sync_state() callback.
> > > Unfortunately there's quite a few problems with the current approach
> > > (the biggest one from my point of view being that it's implemented so
> > > that it requires every single consumer of every device on the PMIC to
> > > come up but there's others at more of an implementation level).
>
> > I'm not sure if we really need such complex solution for this...
>
> So I think that the specific approach there is overly heavyweight and
> restrictive but I do see the general use case here for something per
> regulator providing we can avoid breaking anything that does actually
> need to change the regulator state (eg, raising the voltage for
> cpufreq).

The changes I propose won't prevent anything from asking for more
power/energy (will always allow turning on stuff, increasing voltage,
increasing current, etc). It'll only prevent reducing power lower than
what was provided when the bootloader left stuff on. This shouldn't
break most boards -- because any other consumer could be setting
similar limits and things don't break then. But even if that's a
concern, we can still default to a timeout behavior and then give
folks the choice of disabling the timeout if they know all their
devices will probe.

Btw, the patch series I sent fixes a lot of subtle use cases even with
the timeout enabled. For example, in one hardware platform, a LDO is
shared between camera, display, UFS and USB. The camera driver would
probe first, enable the regulator, poll its HW and then disable the
regulator. This causes the regulator to be disabled before display,
UFS, and USB could probe and this caused hardware faults for those.

> Previously to the past week I'd only really heard about it
> causing problems in the context of displays left on by the bootloader
> glitching during boot but this is a concrete

Ah, finally! I have examples of pretty much the same issue in some
downstream kernels -- the CPU and memory shares rails with other
hardware blocks and things fail if this isn't taken care of. Glad that
someone else found an example for me in the upstream kernel.

> use case and we already
> have the infrastructure to track dependencies at the device model level
> if we use it well.

I'll send out a v3 series in a couple of days to address Mark's
earlier comments and also add the voltage support to address Marek's
case. We can take it from there.

-Saravana

Re: [patch V9 10/39] x86/entry: Provide helpers for execute on irqstack

[Qian Cai]

On Tue, Jun 09, 2020 at 12:20:06AM +0200, Thomas Gleixner wrote:
> Qian,
> 
> can you please ensure that people who got cc'ed because the problem
> affects their subsystem are included on your replies even if you are
> replying to a different subthread?
> 
> I explicitely did:
> 
>  Cc:+ Alexander
> 
> at the very beginning of my reply:
> 
>https://lore.kernel.org/r/87v9k3jdc6@nanos.tec.linutronix.de
> 
> to make you aware of that.
> 
> Yes, email sucks, but it sucks even more when people are careless.

Sorry, I will remeber that next time.

[]
> To get facts instead of useless loop theories, can you please apply the
> patch below, enable DEBUGFS and provide the output of
> 
>/sys/kernel/debug/stackdepot/info
> 
> for a kernel before that change and after? Please read out that file at
> periodically roughly the same amounts of time after starting your test
> scenario.
> 
> Note, that I doubled the size of the stack depot so that we get real
> numbers and not the cutoff by the size limit. IOW, the warning should
> not trigger anymore. If it triggers nevertheless then the numbers will
> still tell us an interesting story.

Instead of running the whole testsuite, I just picked this single LTP
oom02 test which seems usually trigger it within the testsuite. Let me
know if this is insufficient (which indeed tell the big difference in
"Unique stacks"), and I am happy to run the whole things.

BAD: next-20200608
GOOD: next-20200528 (which does not include this series)

BAD (after boot)
# cat /sys/kernel/debug/stackdepot/info
Unique stacks: 33547
Depot index:   359
Depot offset:  6752

BAD (after oom02)
# cat /sys/kernel/debug/stackdepot/info
Unique stacks: 140476
Depot index:   2555
Depot offset:  9168

GOOD (after boot)
# cat /sys/kernel/debug/stackdepot/info
Unique stacks: 31112
Depot index:   317
Depot offset:  14384

GOOD (after oom02)
# cat /sys/kernel/debug/stackdepot/info
Unique stacks: 34176
Depot index:   354
Depot offset:  4032

BTW, I am happy to run another one using next-20200608 with just this
series reverted if you suspect there is something else going on between
those two trees.

Re: next-0519 on thinkpad x60: sound related? window manager crash

[David Rientjes]

On Mon, 8 Jun 2020, Alex Xu (Hello71) wrote:

> Excerpts from Christoph Hellwig's message of June 8, 2020 2:19 am:
> > Can you do a listing using gdb where this happens?
> > 
> > gdb vmlinux
> > 
> > l *(snd_pcm_hw_params+0x3f3)
> > 
> > ?
> > 
> 
> (gdb) l *(snd_pcm_hw_params+0x3f3)
> 0x817efc85 is in snd_pcm_hw_params 
> (.../linux/sound/core/pcm_native.c:749).
> 744 while (runtime->boundary * 2 <= LONG_MAX - 
> runtime->buffer_size)
> 745 runtime->boundary *= 2;
> 746
> 747 /* clear the buffer for avoiding possible kernel info leaks */
> 748 if (runtime->dma_area && !substream->ops->copy_user)
> 749 memset(runtime->dma_area, 0, runtime->dma_bytes);
> 750
> 751 snd_pcm_timer_resolution_change(substream);
> 752 snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
> 753
> 

Working theory is that CONFIG_DMA_NONCOHERENT_MMAP getting set is causing 
the error_code in the page fault path.  Debugging with Alex off-thread we 
found that dma_{alloc,free}_from_pool() are not getting called from the 
new code in dma_direct_{alloc,free}_pages() and he has not enabled 
mem_encrypt.

So the issue is related to setting CONFIG_DMA_COHERENT_POOL, and not 
anything else related to AMD SME.  He has a patch to try out, but I wanted 
to update the thread in case there are other ideas to try other than 
selecting CONFIG_DMA_NONCOHERENT_MMAP only when CONFIG_DMA_REMAP is set 
(and not CONFIG_DMA_COHERENT_POOL).

Re: [RFC] decrease tsk->signal->live before profile_task_exit

[liuchao (CR)]

Eric W. Biederman  writes:

> liuchao  writes:
> 
> > I want to dermine which thread is the last one to enter do_exit in
> > profile_task_exit. But when a lot of threads exit, tsk->signal->live
> > is not correct since it decrease after profile_task_exit.
> 
> I don't think that would be wise.
> 
> Any additional code before the sanity checks at the start of do_exit seems
> like a bad idea.
> 
> We could probably move the decrement of tsk->signal->live a little earlier,
> but not that much earlier in the function.
> 
> Does profile_task_exit even make sense that early in the code?  If the code
> is doing much of anything that is a completely inappopriate placement of
> profile_task_exit.

I think so too.

Move the decrement of tsk->signal->live after the sanity checks, then
profile_task_exit and kcov_task_exit make more sense.

> 
> Eric
> 
> 
> > Signed-off-by: liuchao 
> > ---
> >  kernel/exit.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/exit.c b/kernel/exit.c index
> > ce2a75bc0ade..1693764bc356 100644
> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> > @@ -708,6 +708,7 @@ void __noreturn do_exit(long code)
> > struct task_struct *tsk = current;
> > int group_dead;
> >
> > +   group_dead = atomic_dec_and_test(>signal->live);
> > profile_task_exit(tsk);
> > kcov_task_exit(tsk);
> >
> > @@ -755,7 +756,6 @@ void __noreturn do_exit(long code)
> > if (tsk->mm)
> > sync_mm_rss(tsk->mm);
> > acct_update_integrals(tsk);
> > -   group_dead = atomic_dec_and_test(>signal->live);
> > if (group_dead) {
> > /*
> >  * If the last thread of global init has exited, panic

[PATCH] ARM: Kconfig: set default ZBOOT_ROM_TEXT/BSS value to 0x0

[Chris Packham]

ZBOOT_ROM_TEXT and ZBOOT_ROM_BSS are defined as 'hex' but had a default
of "0". Kconfig will helpfully expand a text entry of 0 to 0x0 but
because this is not the same as the default value it was treated as
being explicitly set when running 'make savedefconfig' so most arm
defconfigs have CONFIG_ZBOOT_ROM_TEXT=0x0 and CONFIG_ZBOOT_ROM_BSS=0x0.

Change the default to 0x0 which will mean next time the defconfigs are
re-generated the spurious config entries will be removed.

Signed-off-by: Chris Packham 
---
I'm assuming there's some semi-automated regular process that syncs up the
defconfigs so I've not created a patch with the result of regenerating the
defconfigs.

 arch/arm/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fb6c85c5d344..38c0cab598bf 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1750,7 +1750,7 @@ config DEPRECATED_PARAM_STRUCT
 # TEXT and BSS so we preserve their values in the config files.
 config ZBOOT_ROM_TEXT
hex "Compressed ROM boot loader base address"
-   default "0"
+   default 0x0
help
  The physical address at which the ROM-able zImage is to be
  placed in the target.  Platforms which normally make use of
@@ -1761,7 +1761,7 @@ config ZBOOT_ROM_TEXT
 
 config ZBOOT_ROM_BSS
hex "Compressed ROM boot loader BSS address"
-   default "0"
+   default 0x0
help
  The base address of an area of read/write memory in the target
  for the ROM-able zImage which must be available while the
-- 
2.25.1

[PATCH linux-next] kernel/fork.c: annotate data races for copy_process

[Weilong Chen]

The check is only there to stop root fork bombs.

BUG: KCSAN: data-race in copy_process / copy_process

write to 0x86f87d20 of 4 bytes by task 7121 on cpu 5:
 copy_process+0x2e1a/0x3af0 kernel/fork.c:2285
 _do_fork+0xf7/0x790 kernel/fork.c:2430
 __do_sys_clone+0xf9/0x130 kernel/fork.c:2585
 __se_sys_clone kernel/fork.c:2566 [inline]
 __x64_sys_clone+0x6c/0x80 kernel/fork.c:2566
 do_syscall_64+0xc7/0x3b0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

read to 0x86f87d20 of 4 bytes by task 7125 on cpu 3:
 copy_process+0x9eb/0x3af0 kernel/fork.c:1967
 _do_fork+0xf7/0x790 kernel/fork.c:2430
 __do_sys_clone+0xf9/0x130 kernel/fork.c:2585
 __se_sys_clone kernel/fork.c:2566 [inline]
 __x64_sys_clone+0x6c/0x80 kernel/fork.c:2566
 do_syscall_64+0xc7/0x3b0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Weilong Chen 
---
 kernel/fork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 142b23645d82..efc5493203ae 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1977,7 +1977,7 @@ static __latent_entropy struct task_struct *copy_process(
 * to stop root fork bombs.
 */
retval = -EAGAIN;
-   if (nr_threads >= max_threads)
+   if (data_race(nr_threads >= max_threads))
goto bad_fork_cleanup_count;
 
delayacct_tsk_init(p);  /* Must remain after dup_task_struct() */
-- 
2.17.1

Re: [PATCH net 0/2] rxrpc: Fix hang due to missing notification

[David Miller]

From: David Howells 
Date: Mon, 08 Jun 2020 19:49:47 +0100

> Here's a fix for AF_RXRPC.  Occasionally calls hang because there are
> circumstances in which rxrpc generate a notification when a call is
> completed - primarily because initial packet transmission failed and the
> call was killed off and an error returned.  But the AFS filesystem driver
> doesn't check this under all circumstances, expecting failure to be
> delivered by asynchronous notification.
> 
> There are two patches: the first moves the problematic bits out-of-line and
> the second contains the fix.
> 
> The patches are tagged here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-fixes-20200605

Pulled, thanks David.

Re: [PATCH net v2] mptcp: bugfix for RM_ADDR option parsing

[David Miller]

From: Geliang Tang 
Date: Mon,  8 Jun 2020 18:47:54 +0800

> In MPTCPOPT_RM_ADDR option parsing, the pointer "ptr" pointed to the
> "Subtype" octet, the pointer "ptr+1" pointed to the "Address ID" octet:
> 
>   +---+---+---+
>   |Subtype|(resvd)|   Address ID  |
>   +---+---+---+
>   |   |
>  ptrptr+1
> 
> We should set mp_opt->rm_id to the value of "ptr+1", not "ptr". This patch
> will fix this bug.
> 
> Fixes: 3df523ab582c ("mptcp: Add ADD_ADDR handling")
> Signed-off-by: Geliang Tang 
> ---
>  Changes in v2:
>   - Add "-net" subject and "Fixes" tag as Matt suggested.

Applied and queued up for v5.7 -stable, thanks!

Re: [PATCH AUTOSEL 5.7 244/274] xfs: force writes to delalloc regions to unwritten

[Sasha Levin]

On Mon, Jun 08, 2020 at 06:07:27PM -0700, Darrick J. Wong wrote:

On Mon, Jun 08, 2020 at 07:05:37PM -0400, Sasha Levin wrote:

From: "Darrick J. Wong" 

[ Upstream commit a5949d3faedf492fa7863b914da408047ab46eb0 ]

When writing to a delalloc region in the data fork, commit the new
allocations (of the da reservation) as unwritten so that the mappings
are only marked written once writeback completes successfully.  This
fixes the problem of stale data exposure if the system goes down during
targeted writeback of a specific region of a file, as tested by
generic/042.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Brian Foster 
Signed-off-by: Sasha Levin 


Err, this doesn't have a Fixes: tag attached to it.  Does it pass
fstests?  Because it doesn't look like you've pulled in "xfs: don't fail
unwritten extent conversion on writeback due to edquot", which is needed
to avoid regressing fstests...

...waitaminute, that whole series lacks Fixes: tags because it wasn't
considered a good enough candidate for automatic backport.


AUTOSEL doesn't look just at the Fixes tag :)


Ummm, does the autosel fstests driver turn on quotas? ;)


Uh, apparently not :/ Is it okay to just enable it across all tests?

While I go fix that up, would you rather drop the series, or pick up
1edd2c055dff ("xfs: don't fail unwritten extent conversion on writeback
due to edquot")?`

--
Thanks,
Sasha

[PATCH v3] jffs2: fix jffs2 mounting failure

[Zhe Li]

Thanks for the advice mentioned in the email.
This is my v3 patch for this problem.

Mounting jffs2 on nand flash will get message "failed: I/O error"
with the steps listed below.
1.umount jffs2
2.erase nand flash
3.mount jffs2 on it (this mounting operation will be successful)
4.do chown or chmod to the mount point directory
5.umount jffs2
6.mount jffs2 on nand flash
After step 6, we will get message "mount ... failed: I/O error".

Typical image of this problem is like:
Empty space found from 0x to 0x008a
Inode node at xx, totlen 0x0044, #ino 1, version 1, isize 0...

The reason for this mounting failure is that at the end of function
jffs2_scan_medium(), jffs2 will check the used_size and some info
of nr_blocks.If conditions are met, it will return -EIO.

The detail is that, in the steps listed above, step 4 will write
jffs2_raw_inode into flash without jffs2_raw_dirent, which will
cause that there are some jffs2_raw_inode but no jffs2_raw_dirent
on flash. This will meet the condition at the end of function
jffs2_scan_medium() and return -EIO if we umount jffs2 and mount it
again.

We notice that jffs2 add the value of c->unchecked_size if we find
an inode node while mounting. And jffs2 will never add the value of
c->unchecked_size in other situations. So this patch add one more
condition about c->unchecked_size of the judgement to fix this problem.

Signed-off-by: Zhe Li 
---
 fs/jffs2/scan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index 5f7e284..db72a9d 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -261,7 +261,8 @@ int jffs2_scan_medium(struct jffs2_sb_info *c)
}
 #endif
if (c->nr_erasing_blocks) {
-   if ( !c->used_size && 
((c->nr_free_blocks+empty_blocks+bad_blocks)!= c->nr_blocks || bad_blocks == 
c->nr_blocks) ) {
+   if (!c->used_size && !c->unchecked_size &&
+   ((c->nr_free_blocks+empty_blocks+bad_blocks) != 
c->nr_blocks || bad_blocks == c->nr_blocks)) {
pr_notice("Cowardly refusing to erase blocks on 
filesystem with no valid JFFS2 nodes\n");
pr_notice("empty_blocks %d, bad_blocks %d, c->nr_blocks 
%d\n",
  empty_blocks, bad_blocks, c->nr_blocks);
-- 
2.7.4

Re: [PATCH 1/1] cxgb4: fix cxgb4_uld_in_use() not used error

[David Miller]

From: Heinrich Schuchardt 
Date: Mon,  8 Jun 2020 02:58:23 +0200

> When building without CONFIG_CHELSIO_TLS_DEVICE a build error occurs:
> 
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:666:13: error:
> ‘cxgb4_uld_in_use’ defined but not used [-Werror=unused-function]
>   666 | static bool cxgb4_uld_in_use(struct adapter *adap)
>   | ^~~~
> 
> Guard cxgb4_uld_in_use() with #ifdef CONFIG_CHELSIO_TLS_DEVICE.
> 
> Signed-off-by: Heinrich Schuchardt 


Please see commit ef1c75593e770aff8749e902aa0deb6855a3f485, which already
does this.

Thank you.

Re: [PATCH AUTOSEL 5.6 001/606] hwmon: (da9052) Synchronize access with mfd

[Sasha Levin]

Uh, I messed something up for the 5.6 series, sorry :(

--
Thanks,
Sasha

Re: [PATCH net-next 1/4] xfrm: bail early on slave pass over skb

[David Miller]

net-next is closed, thank you

RE: [PATCH 3/3] exfat: set EXFAT_SB_DIRTY and VOL_DIRTY at the same timing

[Namjae Jeon]

> Thank you for your comment.
> 
> > >> Can you split this patch into two? (Don't set VOL_DIRTY on
> > >> -ENOTEMPTY and Setting EXFAT_SB_DIRTY is merged into
> > >> exfat_set_vol_flag). I need to check the second one more.
> > >
> > > Can't do that.
> > >
> > > exfat_set_vol_flag() is called when rmdir processing begins. When
> > > Not-empty is detected, VOL_DIRTY has already been written and synced
> > > to the media.
> > You can move it before calling exfat_remove_entries().
> 
> Can be moved, but that doesn't solve the problem.
> It causes the similar problem as before.
> 
> exfat_remove_entries() calls exfat_get_dentry().
> If exfat_get_dentry() fails, update bh and set SB_DIRTY will not be executed.
> As a result, SB_DIRTY is not set and sync does not work.
> Similar problems occur with other writing functions.
> Similar problems occur when pre-write checks are added in the future.
> 
> If you don't set VOL_DIRTY at the beginning, you should delay to set 
> VOL_DIRTY until update-bh & set
> SB_DIRTY.
> This avoids unnecessary changes to VOL_DIRTY/VOL_CLEAN.
Right, That's what I am going to point out.
> I think this method is smart, but it is difficult to decide when to set 
> VOL_CLEAN.
> (I tried to implement it, but gave up)
Okay, I'm a little busy now, but I'll give you feedback soon.
Thanks for your work!
> 
> > > By doing this, sync is guaranteed if VOL_DIRTY is set by calling
> > > exfat_set_vol_flag.
> > >
> > > This change may still have problems, but it's little better than
> > > before, I think.
> > I need to check more if it is the best or there is more better way.
> 
> I think the sync-problems still exist.
> Let's improve little by little. :-)
> 
> BR
> ---
> Kohada Tetsuhiro 

[PATCH v5] block: Fix use-after-free in blkdev_get()

[Jason Yan]

In blkdev_get() we call __blkdev_get() to do some internal jobs and if
there is some errors in __blkdev_get(), the bdput() is called which
means we have released the refcount of the bdev (actually the refcount of
the bdev inode). This means we cannot access bdev after that point. But
acctually bdev is still accessed in blkdev_get() after calling
__blkdev_get(). This results in use-after-free if the refcount is the
last one we released in __blkdev_get(). Let's take a look at the
following scenerio:

  CPU0CPU1CPU2
blkdev_open blkdev_open   Remove disk
  bd_acquire
  blkdev_get
__blkdev_get  del_gendisk
bdev_unhash_inode
  bd_acquire  bdev_get_gendisk
bd_forget   failed because of unhashed
  bdput
  bdput (the last one)
bdev_evict_inode

access bdev => use after free

[  459.350216] BUG: KASAN: use-after-free in __lock_acquire+0x24c1/0x31b0
[  459.351190] Read of size 8 at addr 88806c815a80 by task 
syz-executor.0/20132
[  459.352347]
[  459.352594] CPU: 0 PID: 20132 Comm: syz-executor.0 Not tainted 4.19.90 #2
[  459.353628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1ubuntu1 04/01/2014
[  459.354947] Call Trace:
[  459.355337]  dump_stack+0x111/0x19e
[  459.355879]  ? __lock_acquire+0x24c1/0x31b0
[  459.356523]  print_address_description+0x60/0x223
[  459.357248]  ? __lock_acquire+0x24c1/0x31b0
[  459.357887]  kasan_report.cold+0xae/0x2d8
[  459.358503]  __lock_acquire+0x24c1/0x31b0
[  459.359120]  ? _raw_spin_unlock_irq+0x24/0x40
[  459.359784]  ? lockdep_hardirqs_on+0x37b/0x580
[  459.360465]  ? _raw_spin_unlock_irq+0x24/0x40
[  459.361123]  ? finish_task_switch+0x125/0x600
[  459.361812]  ? finish_task_switch+0xee/0x600
[  459.362471]  ? mark_held_locks+0xf0/0xf0
[  459.363108]  ? __schedule+0x96f/0x21d0
[  459.363716]  lock_acquire+0x111/0x320
[  459.364285]  ? blkdev_get+0xce/0xbe0
[  459.364846]  ? blkdev_get+0xce/0xbe0
[  459.365390]  __mutex_lock+0xf9/0x12a0
[  459.365948]  ? blkdev_get+0xce/0xbe0
[  459.366493]  ? bdev_evict_inode+0x1f0/0x1f0
[  459.367130]  ? blkdev_get+0xce/0xbe0
[  459.367678]  ? destroy_inode+0xbc/0x110
[  459.368261]  ? mutex_trylock+0x1a0/0x1a0
[  459.368867]  ? __blkdev_get+0x3e6/0x1280
[  459.369463]  ? bdev_disk_changed+0x1d0/0x1d0
[  459.370114]  ? blkdev_get+0xce/0xbe0
[  459.370656]  blkdev_get+0xce/0xbe0
[  459.371178]  ? find_held_lock+0x2c/0x110
[  459.371774]  ? __blkdev_get+0x1280/0x1280
[  459.372383]  ? lock_downgrade+0x680/0x680
[  459.373002]  ? lock_acquire+0x111/0x320
[  459.373587]  ? bd_acquire+0x21/0x2c0
[  459.374134]  ? do_raw_spin_unlock+0x4f/0x250
[  459.374780]  blkdev_open+0x202/0x290
[  459.375325]  do_dentry_open+0x49e/0x1050
[  459.375924]  ? blkdev_get_by_dev+0x70/0x70
[  459.376543]  ? __x64_sys_fchdir+0x1f0/0x1f0
[  459.377192]  ? inode_permission+0xbe/0x3a0
[  459.377818]  path_openat+0x148c/0x3f50
[  459.378392]  ? kmem_cache_alloc+0xd5/0x280
[  459.379016]  ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  459.379802]  ? path_lookupat.isra.0+0x900/0x900
[  459.380489]  ? __lock_is_held+0xad/0x140
[  459.381093]  do_filp_open+0x1a1/0x280
[  459.381654]  ? may_open_dev+0xf0/0xf0
[  459.382214]  ? find_held_lock+0x2c/0x110
[  459.382816]  ? lock_downgrade+0x680/0x680
[  459.383425]  ? __lock_is_held+0xad/0x140
[  459.384024]  ? do_raw_spin_unlock+0x4f/0x250
[  459.384668]  ? _raw_spin_unlock+0x1f/0x30
[  459.385280]  ? __alloc_fd+0x448/0x560
[  459.385841]  do_sys_open+0x3c3/0x500
[  459.386386]  ? filp_open+0x70/0x70
[  459.386911]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  459.387610]  ? trace_hardirqs_off_caller+0x55/0x1c0
[  459.388342]  ? do_syscall_64+0x1a/0x520
[  459.388930]  do_syscall_64+0xc3/0x520
[  459.389490]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  459.390248] RIP: 0033:0x416211
[  459.390720] Code: 75 14 b8 02 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83
04 19 00 00 c3 48 83 ec 08 e8 0a fa ff ff 48 89 04 24 b8 02 00 00 00 0f
   05 <48> 8b 3c 24 48 89 c2 e8 53 fa ff ff 48 89 d0 48 83 c4 08 48 3d
  01
[  459.393483] RSP: 002b:7fe45dfe9a60 EFLAGS: 0293 ORIG_RAX: 
0002
[  459.394610] RAX: ffda RBX: 7fe45dfea6d4 RCX: 00416211
[  459.395678] RDX: 7fe45dfe9b0a RSI: 0002 RDI: 7fe45dfe9b00
[  459.396758] RBP: 0076bf20 R08:  R09: 000a
[  459.397930] R10: 0075 R11: 0293 R12: 
[  459.399022] R13: 0bd9 R14: 004cdb80 R15: 0076bf2c
[  459.400168]
[  459.400430] Allocated by task 20132:
[  459.401038]  kasan_kmalloc+0xbf/0xe0
[  459.401652]  kmem_cache_alloc+0xd5/0x280
[  459.402330]  bdev_alloc_inode+0x18/0x40
[  459.402970]  alloc_inode+0x5f/0x180
[  459.403510]  iget5_locked+0x57/0xd0
[  459.404095]  bdget+0x94/0x4e0
[  

[PATCH] KVM: nVMX: Wrap VM-Fail valid path in generic VM-Fail helper

[Sean Christopherson]

Add nested_vmx_fail() to wrap VM-Fail paths that _may_ result in VM-Fail
Valid to make it clear at the call sites that the Valid flavor isn't
guaranteed.

Suggested-by: Vitaly Kuznetsov 
Signed-off-by: Sean Christopherson 
---
 arch/x86/kvm/vmx/nested.c | 77 ++-
 1 file changed, 36 insertions(+), 41 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index bcb50724be38..f45a36e5c863 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -171,15 +171,6 @@ static int nested_vmx_failInvalid(struct kvm_vcpu *vcpu)
 static int nested_vmx_failValid(struct kvm_vcpu *vcpu,
u32 vm_instruction_error)
 {
-   struct vcpu_vmx *vmx = to_vmx(vcpu);
-
-   /*
-* failValid writes the error number to the current VMCS, which
-* can't be done if there isn't a current VMCS.
-*/
-   if (vmx->nested.current_vmptr == -1ull && !vmx->nested.hv_evmcs)
-   return nested_vmx_failInvalid(vcpu);
-
vmx_set_rflags(vcpu, (vmx_get_rflags(vcpu)
& ~(X86_EFLAGS_CF | X86_EFLAGS_PF | X86_EFLAGS_AF |
X86_EFLAGS_SF | X86_EFLAGS_OF))
@@ -192,6 +183,20 @@ static int nested_vmx_failValid(struct kvm_vcpu *vcpu,
return kvm_skip_emulated_instruction(vcpu);
 }
 
+static int nested_vmx_fail(struct kvm_vcpu *vcpu, u32 vm_instruction_error)
+{
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+   /*
+* failValid writes the error number to the current VMCS, which
+* can't be done if there isn't a current VMCS.
+*/
+   if (vmx->nested.current_vmptr == -1ull && !vmx->nested.hv_evmcs)
+   return nested_vmx_failInvalid(vcpu);
+
+   return nested_vmx_failValid(vcpu, vm_instruction_error);
+}
+
 static void nested_vmx_abort(struct kvm_vcpu *vcpu, u32 indicator)
 {
/* TODO: not to reset guest simply here. */
@@ -3456,19 +3461,18 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool 
launch)
 * when using the merged vmcs02.
 */
if (interrupt_shadow & KVM_X86_SHADOW_INT_MOV_SS)
-   return nested_vmx_failValid(vcpu,
-   VMXERR_ENTRY_EVENTS_BLOCKED_BY_MOV_SS);
+   return nested_vmx_fail(vcpu, 
VMXERR_ENTRY_EVENTS_BLOCKED_BY_MOV_SS);
 
if (vmcs12->launch_state == launch)
-   return nested_vmx_failValid(vcpu,
+   return nested_vmx_fail(vcpu,
launch ? VMXERR_VMLAUNCH_NONCLEAR_VMCS
   : VMXERR_VMRESUME_NONLAUNCHED_VMCS);
 
if (nested_vmx_check_controls(vcpu, vmcs12))
-   return nested_vmx_failValid(vcpu, 
VMXERR_ENTRY_INVALID_CONTROL_FIELD);
+   return nested_vmx_fail(vcpu, 
VMXERR_ENTRY_INVALID_CONTROL_FIELD);
 
if (nested_vmx_check_host_state(vcpu, vmcs12))
-   return nested_vmx_failValid(vcpu, 
VMXERR_ENTRY_INVALID_HOST_STATE_FIELD);
+   return nested_vmx_fail(vcpu, 
VMXERR_ENTRY_INVALID_HOST_STATE_FIELD);
 
/*
 * We're finally done with prerequisite checking, and can start with
@@ -3517,7 +3521,7 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool 
launch)
if (status == NVMX_VMENTRY_VMEXIT)
return 1;
WARN_ON_ONCE(status != NVMX_VMENTRY_VMFAIL);
-   return nested_vmx_failValid(vcpu, VMXERR_ENTRY_INVALID_CONTROL_FIELD);
+   return nested_vmx_fail(vcpu, VMXERR_ENTRY_INVALID_CONTROL_FIELD);
 }
 
 /*
@@ -4460,7 +4464,7 @@ void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
vm_exit_reason,
 * flag and the VM-instruction error field of the VMCS
 * accordingly, and skip the emulated instruction.
 */
-   (void)nested_vmx_failValid(vcpu, VMXERR_ENTRY_INVALID_CONTROL_FIELD);
+   (void)nested_vmx_fail(vcpu, VMXERR_ENTRY_INVALID_CONTROL_FIELD);
 
/*
 * Restore L1's host state to KVM's software model.  We're here
@@ -4760,8 +4764,7 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
}
 
if (vmx->nested.vmxon)
-   return nested_vmx_failValid(vcpu,
-   VMXERR_VMXON_IN_VMX_ROOT_OPERATION);
+   return nested_vmx_fail(vcpu, 
VMXERR_VMXON_IN_VMX_ROOT_OPERATION);
 
if ((vmx->msr_ia32_feature_control & VMXON_NEEDED_FEATURES)
!= VMXON_NEEDED_FEATURES) {
@@ -4852,12 +4855,10 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
return r;
 
if (!page_address_valid(vcpu, vmptr))
-   return nested_vmx_failValid(vcpu,
-   VMXERR_VMCLEAR_INVALID_ADDRESS);
+   return nested_vmx_fail(vcpu, VMXERR_VMCLEAR_INVALID_ADDRESS);
 
if (vmptr == vmx->nested.vmxon_ptr)
-   return nested_vmx_failValid(vcpu,
-   VMXERR_VMCLEAR_VMXON_POINTER);
+   return nested_vmx_fail(vcpu, VMXERR_VMCLEAR_VMXON_POINTER);
 
 

[PATCH] KVM: VMX: Add helpers to identify interrupt type from intr_info

[Sean Christopherson]

Add is_intr_type() and is_intr_type_n() to consolidate the boilerplate
code for querying a specific type of interrupt given an encoded value
from VMCS.VM_{ENTER,EXIT}_INTR_INFO, with and without an associated
vector respectively.

Signed-off-by: Sean Christopherson 
---

I wrote and proposed a version of this patch a while back[*], but AFAICT
never posted it as a formal patch.

[*] https://lkml.kernel.org/r/20190819233537.gg1...@linux.intel.com

 arch/x86/kvm/vmx/vmcs.h | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/vmx/vmcs.h b/arch/x86/kvm/vmx/vmcs.h
index 5c0ff80b85c0..7a3675fddec2 100644
--- a/arch/x86/kvm/vmx/vmcs.h
+++ b/arch/x86/kvm/vmx/vmcs.h
@@ -72,11 +72,24 @@ struct loaded_vmcs {
struct vmcs_controls_shadow controls_shadow;
 };
 
+static inline bool is_intr_type(u32 intr_info, u32 type)
+{
+   const u32 mask = INTR_INFO_VALID_MASK | INTR_INFO_INTR_TYPE_MASK;
+
+   return (intr_info & mask) == (INTR_INFO_VALID_MASK | type);
+}
+
+static inline bool is_intr_type_n(u32 intr_info, u32 type, u8 vector)
+{
+   const u32 mask = INTR_INFO_VALID_MASK | INTR_INFO_INTR_TYPE_MASK |
+INTR_INFO_VECTOR_MASK;
+
+   return (intr_info & mask) == (INTR_INFO_VALID_MASK | type | vector);
+}
+
 static inline bool is_exception_n(u32 intr_info, u8 vector)
 {
-   return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VECTOR_MASK |
-INTR_INFO_VALID_MASK)) ==
-   (INTR_TYPE_HARD_EXCEPTION | vector | INTR_INFO_VALID_MASK);
+   return is_intr_type_n(intr_info, INTR_TYPE_HARD_EXCEPTION, vector);
 }
 
 static inline bool is_debug(u32 intr_info)
@@ -106,28 +119,23 @@ static inline bool is_gp_fault(u32 intr_info)
 
 static inline bool is_machine_check(u32 intr_info)
 {
-   return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VECTOR_MASK |
-INTR_INFO_VALID_MASK)) ==
-   (INTR_TYPE_HARD_EXCEPTION | MC_VECTOR | INTR_INFO_VALID_MASK);
+   return is_exception_n(intr_info, MC_VECTOR);
 }
 
 /* Undocumented: icebp/int1 */
 static inline bool is_icebp(u32 intr_info)
 {
-   return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
-   == (INTR_TYPE_PRIV_SW_EXCEPTION | INTR_INFO_VALID_MASK);
+   return is_intr_type(intr_info, INTR_TYPE_PRIV_SW_EXCEPTION);
 }
 
 static inline bool is_nmi(u32 intr_info)
 {
-   return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
-   == (INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK);
+   return is_intr_type(intr_info, INTR_TYPE_NMI_INTR);
 }
 
 static inline bool is_external_intr(u32 intr_info)
 {
-   return (intr_info & (INTR_INFO_VALID_MASK | INTR_INFO_INTR_TYPE_MASK))
-   == (INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR);
+   return is_intr_type(intr_info, INTR_TYPE_EXT_INTR);
 }
 
 enum vmcs_field_width {
-- 
2.26.0

Re: [RFC PATCH] KVM: x86: Fix APIC page invalidation race

[Eiichi Tsukata]

> On Jun 8, 2020, at 22:13, Paolo Bonzini  wrote:
> 
> On 06/06/20 06:26, Eiichi Tsukata wrote:
>> Commit b1394e745b94 ("KVM: x86: fix APIC page invalidation") tried to
>> fix inappropriate APIC page invalidation by re-introducing arch specific
>> kvm_arch_mmu_notifier_invalidate_range() and calling it from
>> kvm_mmu_notifier_invalidate_range_start. But threre could be the
>> following race because VMCS APIC address cache can be updated
>> *before* it is unmapped.
>> 
>> Race:
>>  (Invalidator) kvm_mmu_notifier_invalidate_range_start()
>>  (Invalidator) kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD)
>>  (KVM VCPU) vcpu_enter_guest()
>>  (KVM VCPU) kvm_vcpu_reload_apic_access_page()
>>  (Invalidator) actually unmap page
>> 
>> Symptom:
>>  The above race can make Guest OS see already freed page and Guest OS
>> will see broken APIC register values.
> 
> This is not exactly the issue.  The values in the APIC-access page do
> not really matter, the problem is that the host physical address values
> won't match between the page tables and the APIC-access page address.
> Then the processor will not trap APIC accesses, and will instead show
> the raw contents of the APIC-access page (zeroes), and cause the crash
> as you mention below.
> 
> Still, the race explains the symptoms and the patch matches this text in
> include/linux/mmu_notifier.h:
> 
>* If the subsystem
> * can't guarantee that no additional references are taken to
> * the pages in the range, it has to implement the
> * invalidate_range() notifier to remove any references taken
> * after invalidate_range_start().
> 
> where the "additional reference" is in the VMCS: because we have to
> account for kvm_vcpu_reload_apic_access_page running between
> invalidate_range_start() and invalidate_range_end(), we need to
> implement invalidate_range().
> 
> The patch seems good, but I'd like Andrea Arcangeli to take a look as
> well so I've CCed him.
> 
> Thank you very much!
> 
> Paolo
> 

Hello Paolo

Thanks for detailed explanation!
I’ll fix the commit message like this:

```
Symptom:
  The above race can cause mismatch between the page tables and the
APIC-access page address in VMCS.Then the processor will not trap APIC
accesses, and will instead show the raw contents of the APIC-access page
(zeroes). Especially, Windows OS checks LAPIC modification so it can cause
BSOD crash with BugCheck CRITICAL_STRUCTURE_CORRUPTION (109). These symptoms
are the same as we previously saw in
https://bugzilla.kernel.org/show_bug.cgi?id=197951
and we are currently seeing in
https://bugzilla.redhat.com/show_bug.cgi?id=1751017.

To prevent mismatch between page tables and APIC-access page address,
this patch calls kvm_arch_mmu_notifier_invalidate_range() from
kvm_mmu_notifier_invalidate_range() instead of ..._range_start().
We need to implement invalidate_range() because we have to
account for kvm_vcpu_reload_apic_access_page() running between
invalidate_range_start() and invalidate_range_end().
```


Best

Eiichi

Re: Re: [PATCH] media: platform: sti: hva: Fix runtime PM imbalance on error

[dinghao . liu]

Hi Hans,
> err_pm:
> pm_runtime_put(dev);
> 
> Shouldn't that be pm_runtime_put_sync()?
> 
> I'm not pm expert, but it does look odd.
> 

I checked the implementation of these two APIs before
and found they were exactly the same. So I think it's
fine to keep using pm_runtime_put().

Regards,
Dinghao

Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_TRIM_FILE ioctl

[Daeho Jeong]

Like the discussion, I'll add a flag to select discard and/or zero out.
We need to send the discard first between those, because we'll send
the discard to a zero-ed new block, if we zero out first.

2020년 6월 9일 (화) 오전 10:16, Chao Yu 님이 작성:
>
> On 2020/6/8 21:07, Jaegeuk Kim wrote:
> > On 06/08, Chao Yu wrote:
> >> On 2020/6/8 15:19, Daeho Jeong wrote:
> >>> Yes, I agree with you about each vendor has different implementation on 
> >>> discard.
> >>> So, we might be gonna use the combination of zeroing and send discards
> >>> for a more
> >>> secure solution. :)
> >>
> >> IIRC, current solution is:
> >>
> >> - pin file
> >> - get all block addresses of file
> >> - write zero to block addresses
> >> - issue discard
> >>
> >> Is that correct?
> >>
> >> Could we handle those logic (zero out & discard) in new interface
> >> (may be named as {F2FS,EXT4}_IOC_SEC_TRIM_FILE)? then userspace logic
> >> could be quite simple later, and also memcpy could be avoid to make
> >> destruction process more efficient.
> >
> > What about adding a flag to determine calling unmap and/or zero out?
>
> Better. :)
>
> Thanks,
>
> >
> >>
> >> Just raw proposal. :)
> >>
> >> Thanks,
> >>
> >>> I think we still need a discard interface to unmap from the mapping
> >>> table of the storage device side.
> >>>
> >>> Thanks,
> >>>
> >>> 2020년 6월 8일 (월) 오후 3:57, Chao Yu 님이 작성:
> 
>  On 2020/6/8 11:36, Daeho Jeong wrote:
> > Yes, this is for security key destruction.
> >
> > AFAIK, discard will unmap the data block and, after done it,
> > we can read either zero data or garbage data from that block depending
> > on eMMC/UFS.
> 
>  Since spec didn't restrict how vendor implement the erase interface, so
>  in order to enhance performance of discard interface, vendor could 
>  implement
>  it as an async one, which may not zero mapping entry(L1 table), instead, 
>  it
>  could set related bitmap to invalid that mapping entry, than later if 
>  device
>  allow user to access that invalid mapping entry, key info may be 
>  explosed,
> 
>  It's completely up to how vendor implement the interface, so I think 
>  there is
>  still risk to use discard.
> 
>  Thanks,
> 
> > In a view point of read data, it might be the same with zeroing the 
> > data block.
> > However, since we can even unmap that block, I believe discard is
> > safer than zeroing out.
> >
> > 2020년 6월 8일 (월) 오전 11:46, Chao Yu 님이 작성:
> >>
> >> On 2020/6/5 12:27, Daeho Jeong wrote:
> >>> From: Daeho Jeong 
> >>>
> >>> Added a new ioctl to send discard commands to whole data area of
> >>> a regular file for security reason.
> >>
> >> I guess this interface is introduced for security key destruction, if 
> >> I'm
> >> right, however, IIRC, discard(erase) semantics in eMMC/UFS spec won't
> >> guarantee that data which was discard could be zeroed out, so after 
> >> discard,
> >> the key still have risk of exposure. So instead, should we use 
> >> sb_issue_zeroout()?
> >>
> >> Thanks,
> >>
> >>>
> >>> Signed-off-by: Daeho Jeong 
> >>> ---
> >>>  fs/f2fs/f2fs.h |   1 +
> >>>  fs/f2fs/file.c | 129 
> >>> +
> >>>  2 files changed, 130 insertions(+)
> >>>
> >>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >>> index c812fb8e2d9c..9ae81d0fefa0 100644
> >>> --- a/fs/f2fs/f2fs.h
> >>> +++ b/fs/f2fs/f2fs.h
> >>> @@ -434,6 +434,7 @@ static inline bool __has_cursum_space(struct 
> >>> f2fs_journal *journal,
> >>>   _IOR(F2FS_IOCTL_MAGIC, 18, 
> >>> __u64)
> >>>  #define F2FS_IOC_RESERVE_COMPRESS_BLOCKS 
> >>> \
> >>>   _IOR(F2FS_IOCTL_MAGIC, 19, 
> >>> __u64)
> >>> +#define F2FS_IOC_TRIM_FILE   _IO(F2FS_IOCTL_MAGIC, 20)
> >>>
> >>>  #define F2FS_IOC_GET_VOLUME_NAME FS_IOC_GETFSLABEL
> >>>  #define F2FS_IOC_SET_VOLUME_NAME FS_IOC_SETFSLABEL
> >>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >>> index dfa1ac2d751a..58507bb5649c 100644
> >>> --- a/fs/f2fs/file.c
> >>> +++ b/fs/f2fs/file.c
> >>> @@ -3749,6 +3749,132 @@ static int 
> >>> f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg)
> >>>   return ret;
> >>>  }
> >>>
> >>> +static int f2fs_trim_file(struct file *filp)
> >>> +{
> >>> + struct inode *inode = file_inode(filp);
> >>> + struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> >>> + struct address_space *mapping = inode->i_mapping;
> >>> + struct bio *bio = NULL;
> >>> + struct block_device *prev_bdev = NULL;
> >>> + loff_t file_size;
> >>> + pgoff_t index, pg_start = 0, pg_end;
> >>> + block_t prev_block = 0, len = 0;
> 

[PATCH v5 1/3] virtio: add dma-buf support for exported objects

[David Stevens]

This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.

Signed-off-by: David Stevens 
---
 drivers/virtio/Makefile |  2 +-
 drivers/virtio/virtio.c |  6 +++
 drivers/virtio/virtio_dma_buf.c | 82 +
 include/linux/virtio.h  |  1 +
 include/linux/virtio_dma_buf.h  | 37 +++
 5 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 drivers/virtio/virtio_dma_buf.c
 create mode 100644 include/linux/virtio_dma_buf.h

diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 29a1386ecc03..ecdae5b596de 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
+obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o virtio_dma_buf.o
 obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
 obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
 virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index a977e32a88f2..5d46f0ded92d 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -357,6 +357,12 @@ int register_virtio_device(struct virtio_device *dev)
 }
 EXPORT_SYMBOL_GPL(register_virtio_device);
 
+bool is_virtio_device(struct device *dev)
+{
+   return dev->bus == _bus;
+}
+EXPORT_SYMBOL_GPL(is_virtio_device);
+
 void unregister_virtio_device(struct virtio_device *dev)
 {
int index = dev->index; /* save for after device release */
diff --git a/drivers/virtio/virtio_dma_buf.c b/drivers/virtio/virtio_dma_buf.c
new file mode 100644
index ..fa0d3a668f53
--- /dev/null
+++ b/drivers/virtio/virtio_dma_buf.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * dma-bufs for virtio exported objects
+ *
+ * Copyright (C) 2020 Google, Inc.
+ */
+
+#include 
+
+/**
+ * virtio_dma_buf_export - Creates a new dma-buf for a virtio exported object
+ * @exp_info: [in] see dma_buf_export(). ops MUST refer to a dma_buf_ops
+ * struct embedded in a virtio_dma_buf_ops.
+ *
+ * This wraps dma_buf_export() to allow virtio drivers to create a dma-buf
+ * for an virtio exported object that can be queried by other virtio drivers
+ * for the object's UUID.
+ */
+struct dma_buf *virtio_dma_buf_export(
+   const struct dma_buf_export_info *exp_info)
+{
+   const struct virtio_dma_buf_ops *virtio_ops = container_of(
+   exp_info->ops, const struct virtio_dma_buf_ops, ops);
+
+   if (!exp_info->ops
+   || exp_info->ops->attach != _dma_buf_attach
+   || !virtio_ops->get_uuid) {
+   return ERR_PTR(-EINVAL);
+   }
+
+   return dma_buf_export(exp_info);
+}
+EXPORT_SYMBOL(virtio_dma_buf_export);
+
+/**
+ * virtio_dma_buf_attach - mandatory attach callback for virtio dma-bufs
+ */
+int virtio_dma_buf_attach(struct dma_buf *dma_buf,
+ struct dma_buf_attachment *attach)
+{
+   int ret;
+   const struct virtio_dma_buf_ops *ops = container_of(
+   dma_buf->ops, const struct virtio_dma_buf_ops, ops);
+
+   if (ops->device_attach) {
+   ret = ops->device_attach(dma_buf, attach);
+   if (ret)
+   return ret;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(virtio_dma_buf_attach);
+
+/**
+ * is_virtio_dma_buf - returns true if the given dma-buf is a virtio dma-buf
+ * @dma_buf: buffer to query
+ */
+bool is_virtio_dma_buf(struct dma_buf *dma_buf)
+{
+   return dma_buf->ops->attach == _dma_buf_attach;
+}
+EXPORT_SYMBOL(is_virtio_dma_buf);
+
+/**
+ * virtio_dma_buf_get_uuid - gets the uuid of the virtio dma-buf's exported 
object
+ * @dma_buf: [in] buffer to query
+ * @uuid: [out] the uuid
+ *
+ * Returns: 0 on success, negative on failure.
+ */
+int virtio_dma_buf_get_uuid(struct dma_buf *dma_buf,
+   uuid_t *uuid)
+{
+   const struct virtio_dma_buf_ops *ops = container_of(
+   dma_buf->ops, const struct virtio_dma_buf_ops, ops);
+
+   if (!is_virtio_dma_buf(dma_buf))
+   return -EINVAL;
+
+   return ops->get_uuid(dma_buf, uuid);
+}
+EXPORT_SYMBOL(virtio_dma_buf_get_uuid);
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 15f906e4a748..9397e25616c4 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -128,6 +128,7 @@ static inline struct virtio_device *dev_to_virtio(struct 
device *_dev)
 void virtio_add_status(struct virtio_device *dev, unsigned int status);
 int register_virtio_device(struct virtio_device *dev);
 void unregister_virtio_device(struct virtio_device *dev);
+bool is_virtio_device(struct device *dev);
 
 void virtio_break_device(struct virtio_device *dev);
 
diff --git a/include/linux/virtio_dma_buf.h 

[PATCH v5 3/3] drm/virtio: Support virtgpu exported resources

[David Stevens]

Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.

Signed-off-by: David Stevens 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  3 +
 drivers/gpu/drm/virtio/virtgpu_drv.h   | 20 ++
 drivers/gpu/drm/virtio/virtgpu_kms.c   |  4 ++
 drivers/gpu/drm/virtio/virtgpu_prime.c | 96 +-
 drivers/gpu/drm/virtio/virtgpu_vq.c| 55 +++
 5 files changed, 175 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index ab4bed78e656..b039f493bda9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -165,6 +165,7 @@ static unsigned int features[] = {
VIRTIO_GPU_F_VIRGL,
 #endif
VIRTIO_GPU_F_EDID,
+   VIRTIO_GPU_F_RESOURCE_UUID,
 };
 static struct virtio_driver virtio_gpu_driver = {
.feature_table = features,
@@ -202,6 +203,8 @@ static struct drm_driver driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_mmap = drm_gem_prime_mmap,
+   .gem_prime_export = virtgpu_gem_prime_export,
+   .gem_prime_import = virtgpu_gem_prime_import,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
 
.gem_create_object = virtio_gpu_create_object,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 49bebdee6d91..39dc907aa805 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -49,6 +49,10 @@
 #define DRIVER_MINOR 1
 #define DRIVER_PATCHLEVEL 0
 
+#define UUID_INITIALIZING 0
+#define UUID_INITIALIZED 1
+#define UUID_INITIALIZATION_FAILED 2
+
 struct virtio_gpu_object_params {
uint32_t format;
uint32_t width;
@@ -71,6 +75,9 @@ struct virtio_gpu_object {
uint32_t hw_res_handle;
bool dumb;
bool created;
+
+   int uuid_state;
+   uuid_t uuid;
 };
 #define gem_to_virtio_gpu_obj(gobj) \
container_of((gobj), struct virtio_gpu_object, base.base)
@@ -200,6 +207,7 @@ struct virtio_gpu_device {
bool has_virgl_3d;
bool has_edid;
bool has_indirect;
+   bool has_resource_assign_uuid;
 
struct work_struct config_changed_work;
 
@@ -210,6 +218,8 @@ struct virtio_gpu_device {
struct virtio_gpu_drv_capset *capsets;
uint32_t num_capsets;
struct list_head cap_cache;
+
+   spinlock_t resource_export_lock;
 };
 
 struct virtio_gpu_fpriv {
@@ -335,6 +345,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct 
*work);
 
 void virtio_gpu_notify(struct virtio_gpu_device *vgdev);
 
+int
+virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev,
+   struct virtio_gpu_object_array *objs);
+
 /* virtgpu_display.c */
 void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
 void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
@@ -366,6 +380,12 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
 bool virtio_gpu_is_shmem(struct virtio_gpu_object *bo);
 
 /* virtgpu_prime.c */
+struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
+int flags);
+struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *buf);
+int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj,
+  uuid_t *uuid);
 struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
struct sg_table *sgt);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 023a030ca7b9..7bcd0c75effa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -125,6 +125,7 @@ int virtio_gpu_init(struct drm_device *dev)
vgdev->dev = dev->dev;
 
spin_lock_init(>display_info_lock);
+   spin_lock_init(>resource_export_lock);
ida_init(>ctx_id_ida);
ida_init(>resource_ida);
init_waitqueue_head(>resp_wq);
@@ -153,6 +154,9 @@ int virtio_gpu_init(struct drm_device *dev)
if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) {
vgdev->has_indirect = true;
}
+   if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
+   vgdev->has_resource_assign_uuid = true;
+   }
 
DRM_INFO("features: %cvirgl %cedid\n",
 vgdev->has_virgl_3d ? '+' : '-',
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 050d24c39a8f..acd14ef73d56 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -23,12 +23,102 @@
  */
 
 #include 
+#include 
 

[PATCH v5 2/3] virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature

[David Stevens]

This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.

Signed-off-by: David Stevens 
---
 include/uapi/linux/virtio_gpu.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index 0c85914d9369..9721d58b4d58 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -50,6 +50,10 @@
  * VIRTIO_GPU_CMD_GET_EDID
  */
 #define VIRTIO_GPU_F_EDID1
+/*
+ * VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID
+ */
+#define VIRTIO_GPU_F_RESOURCE_UUID   2
 
 enum virtio_gpu_ctrl_type {
VIRTIO_GPU_UNDEFINED = 0,
@@ -66,6 +70,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_GET_CAPSET_INFO,
VIRTIO_GPU_CMD_GET_CAPSET,
VIRTIO_GPU_CMD_GET_EDID,
+   VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
 
/* 3d commands */
VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -87,6 +92,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_RESP_OK_CAPSET_INFO,
VIRTIO_GPU_RESP_OK_CAPSET,
VIRTIO_GPU_RESP_OK_EDID,
+   VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
 
/* error responses */
VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -340,4 +346,17 @@ enum virtio_gpu_formats {
VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM  = 134,
 };
 
+/* VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID */
+struct virtio_gpu_resource_assign_uuid {
+   struct virtio_gpu_ctrl_hdr hdr;
+   __le32 resource_id;
+   __le32 padding;
+};
+
+/* VIRTIO_GPU_RESP_OK_RESOURCE_UUID */
+struct virtio_gpu_resp_resource_uuid {
+   struct virtio_gpu_ctrl_hdr hdr;
+   __u8 uuid[16];
+};
+
 #endif
-- 
2.27.0.278.ge193c7cf3a9-goog

[PATCH v5 0/3] Support virtio cross-device resources

[David Stevens]

This patchset implements the current proposal for virtio cross-device
resource sharing [1]. It will be used to import virtio resources into
the virtio-video driver currently under discussion [2]. The patch
under consideration to add support in the virtio-video driver is [3].
It uses the APIs from v3 of this series, but the changes to update it
are relatively minor.

This patchset adds a new flavor of dma-bufs that supports querying the
underlying virtio object UUID, as well as adding support for exporting
resources from virtgpu.

[1] https://markmail.org/thread/2ypjt5cfeu3m6lxu
[2] https://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks

v4 -> v5 changes:
 - Remove virtio_dma_buf_export_info.

David Stevens (3):
  virtio: add dma-buf support for exported objects
  virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
  drm/virtio: Support virtgpu exported resources

 drivers/gpu/drm/virtio/virtgpu_drv.c   |  3 +
 drivers/gpu/drm/virtio/virtgpu_drv.h   | 20 ++
 drivers/gpu/drm/virtio/virtgpu_kms.c   |  4 ++
 drivers/gpu/drm/virtio/virtgpu_prime.c | 96 +-
 drivers/gpu/drm/virtio/virtgpu_vq.c| 55 +++
 drivers/virtio/Makefile|  2 +-
 drivers/virtio/virtio.c|  6 ++
 drivers/virtio/virtio_dma_buf.c| 82 ++
 include/linux/virtio.h |  1 +
 include/linux/virtio_dma_buf.h | 37 ++
 include/uapi/linux/virtio_gpu.h| 19 +
 11 files changed, 321 insertions(+), 4 deletions(-)
 create mode 100644 drivers/virtio/virtio_dma_buf.c
 create mode 100644 include/linux/virtio_dma_buf.h

-- 
2.27.0.278.ge193c7cf3a9-goog

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

[Bart Van Assche]

On 2020-06-06 11:38, Avri Altman wrote:
>> +   for (i = 0; i < bit_len; i++) {
>> +   if (test_bit(srgn_offset + i, srgn->mctx->ppn_dirty))
>
> Maybe use a mask or hweight instead of testing bit by bit?

How about using find_next_bit() from include/linux/bitmap.h?

/*
 *  find_next_bit(addr, nbits, bit) Position next set bit in *addr
 *  >= bit
 */

Thanks,

Bart.

Re: [PATCH v2] f2fs: use kfree() instead of kvfree() to free superblock data

[Chao Yu]

Hello Denis,

On 2020/6/8 23:41, Denis Efremov wrote:
> Use kfree() instead of kvfree() to free super in read_raw_super_block()
> because the memory is allocated with kzalloc() in the function.
> Use kfree() instead of kvfree() to free sbi in f2fs_fill_super() and
> f2fs_put_super() because the memory is allocated with kzalloc().
> 
> Fixes: 5222595d093e ("f2fs: use kvmalloc, if kmalloc is failed")
> Signed-off-by: Denis Efremov 

I found two missing cases, so how about this?

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f3c151169542..f913a63e93f0 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1206,7 +1206,7 @@ static void f2fs_put_super(struct super_block *sb)
sb->s_fs_info = NULL;
if (sbi->s_chksum_driver)
crypto_free_shash(sbi->s_chksum_driver);
-   kvfree(sbi->raw_super);
+   kfree(sbi->raw_super);

destroy_device_list(sbi);
f2fs_destroy_xattr_caches(sbi);
@@ -1221,7 +1221,7 @@ static void f2fs_put_super(struct super_block *sb)
 #ifdef CONFIG_UNICODE
utf8_unload(sbi->s_encoding);
 #endif
-   kvfree(sbi);
+   kfree(sbi);
 }

 int f2fs_sync_fs(struct super_block *sb, int sync)
@@ -3101,7 +3101,7 @@ static int read_raw_super_block(struct f2fs_sb_info *sbi,

/* No valid superblock */
if (!*raw_super)
-   kvfree(super);
+   kfree(super);
else
err = 0;

@@ -3779,11 +3779,11 @@ static int f2fs_fill_super(struct super_block *sb, void 
*data, int silent)
 #endif
kvfree(options);
 free_sb_buf:
-   kvfree(raw_super);
+   kfree(raw_super);
 free_sbi:
if (sbi->s_chksum_driver)
crypto_free_shash(sbi->s_chksum_driver);
-   kvfree(sbi);
+   kfree(sbi);

/* give only one another chance */
if (retry_cnt > 0 && skip_recovery) {

Mes Salutations

[Mr TOLAR OKANSE]

Mes Salutations

Je suis Mr Tolar Okanse,  conseiller financier, des biens et de 
patrimoines privés. J'ai trouvé votre contact suite à une 
recherche via l'Internet et je vous prie de m'excuser pour cette 
intrusion inattendue de ma part et l'effet surpris que cela peut 
causer vu tout ce qui se passe actuellement sur l'Internet.

Par ce message, je viens vous solliciter pour une collaboration 
sérieuse et fructueuse. Dans le cas où vous serez intéressés par 
mon offre, une rencontre physique est nécessaire, voir 
indispensable  afin de discuter tête à tête des axes et 
paramètres  pour la bonne réalisation de cette collaboration.

En effet, je suis en contact avec un client (ressortissent 
libyen) qui souhaiterait faire des placements et investissement 
dans tous les domaines rentable. Ce dernier est à la recherche 
d'un manager sérieux à qui il va tout confier pour la réalisation 
de ce projet.


Contact direct: tolarokens...@gmail.com


Cordialement...
Mr T. Okanse

[PATCH v6 1/4] mmc: mediatek: add MT6779 MMC driver support

[Chun-Hung Wu]

MT6779 add cqhci support, so need to add new code
to support it.

Signed-off-by: Chun-Hung Wu 
---
 drivers/mmc/host/mtk-sd.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b221c02..8ada675 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -538,6 +538,18 @@ struct msdc_host {
.use_internal_cd = true,
 };
 
+static const struct mtk_mmc_compatible mt6779_compat = {
+   .clk_div_bits = 12,
+   .hs400_tune = false,
+   .pad_tune_reg = MSDC_PAD_TUNE0,
+   .async_fifo = true,
+   .data_tune = true,
+   .busy_check = true,
+   .stop_clk_fix = true,
+   .enhance_rx = true,
+   .support_64g = true,
+};
+
 static const struct of_device_id msdc_of_ids[] = {
{ .compatible = "mediatek,mt8135-mmc", .data = _compat},
{ .compatible = "mediatek,mt8173-mmc", .data = _compat},
@@ -547,6 +559,7 @@ struct msdc_host {
{ .compatible = "mediatek,mt7622-mmc", .data = _compat},
{ .compatible = "mediatek,mt8516-mmc", .data = _compat},
{ .compatible = "mediatek,mt7620-mmc", .data = _compat},
+   { .compatible = "mediatek,mt6779-mmc", .data = _compat},
{}
 };
 MODULE_DEVICE_TABLE(of, msdc_of_ids);
-- 
1.9.1

[PATCH v6 3/4] mmc: mediatek: command queue support

[Chun-Hung Wu]

Support command queue for mt6779 platform.
a. Add msdc_set_busy_timeout() to calculate emmc write timeout.
b. Connect mtk msdc driver to cqhci driver through
   host->cq_host->ops = _cmdq_ops;
c. msdc_cmdq_irq() will link up with cqchi_irq(). Besides, it provides
   more irq error messages like RSPCRCERR/CMDTO/DATACRCERR/DATTMO.
d. Use the options below to separate support for CQHCI or not, because
   some of our platform does not support CQHCI hence no kernel option:
   CONFIG_MMC_CQHCI.
   #if IS_ENABLED(CONFIG_MMC_CQHCI)
   XXX //Support CQHCI
   #else
   XXX //Not support CQHCI
   #endif

Signed-off-by: Chun-Hung Wu 
---
 drivers/mmc/host/mtk-sd.c | 119 ++
 1 file changed, 119 insertions(+)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 84a7bd44..9d69269 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#include "cqhci.h"
+
 #define MAX_BD_NUM  1024
 
 /*--*/
@@ -152,6 +154,7 @@
 #define MSDC_INT_DMA_BDCSERR(0x1 << 17)/* W1C */
 #define MSDC_INT_DMA_GPDCSERR   (0x1 << 18)/* W1C */
 #define MSDC_INT_DMA_PROTECT(0x1 << 19)/* W1C */
+#define MSDC_INT_CMDQ   (0x1 << 28)/* W1C */
 
 /* MSDC_INTEN mask */
 #define MSDC_INTEN_MMCIRQ   (0x1 << 0) /* RW */
@@ -182,6 +185,7 @@
 /* SDC_CFG mask */
 #define SDC_CFG_SDIOINTWKUP (0x1 << 0) /* RW */
 #define SDC_CFG_INSWKUP (0x1 << 1) /* RW */
+#define SDC_CFG_WRDTOC  (0x1fff  << 2)  /* RW */
 #define SDC_CFG_BUSWIDTH(0x3 << 16)/* RW */
 #define SDC_CFG_SDIO(0x1 << 19)/* RW */
 #define SDC_CFG_SDIOIDE (0x1 << 20)/* RW */
@@ -230,6 +234,7 @@
 #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)  /* RW */
 
 #define MSDC_PATCH_BIT1_CMDTA (0x7 << 3)/* RW */
+#define MSDC_PB1_BUSY_CHECK_SEL   (0x1 << 7)/* RW */
 #define MSDC_PATCH_BIT1_STOP_DLY  (0xf << 8)/* RW */
 
 #define MSDC_PATCH_BIT2_CFGRESP   (0x1 << 15)   /* RW */
@@ -431,9 +436,11 @@ struct msdc_host {
 /* cmd response sample selection for HS400 */
bool hs400_mode;/* current eMMC will run at hs400 mode */
bool internal_cd;   /* Use internal card-detect logic */
+   bool cqhci; /* support eMMC hw cmdq */
struct msdc_save_para save_para; /* used when gate HCLK */
struct msdc_tune_para def_tune_para; /* default tune setting */
struct msdc_tune_para saved_tune_para; /* tune result of CMD21/CMD19 */
+   struct cqhci_host *cq_host;
 };
 
 static const struct mtk_mmc_compatible mt8135_compat = {
@@ -764,6 +771,15 @@ static void msdc_set_timeout(struct msdc_host *host, u64 
ns, u64 clks)
  (u32)(timeout > 255 ? 255 : timeout));
 }
 
+static void msdc_set_busy_timeout(struct msdc_host *host, u64 ns, u64 clks)
+{
+   u64 timeout;
+
+   timeout = msdc_timeout_cal(host, ns, clks);
+   sdr_set_field(host->base + SDC_CFG, SDC_CFG_WRDTOC,
+ (u32)(timeout > 8191 ? 8191 : timeout));
+}
+
 static void msdc_gate_clock(struct msdc_host *host)
 {
clk_disable_unprepare(host->src_clk_cg);
@@ -1480,6 +1496,36 @@ static void msdc_enable_sdio_irq(struct mmc_host *mmc, 
int enb)
pm_runtime_put_noidle(host->dev);
 }
 
+#if IS_ENABLED(CONFIG_MMC_CQHCI)
+static irqreturn_t msdc_cmdq_irq(struct msdc_host *host, u32 intsts)
+{
+   int cmd_err = 0, dat_err = 0;
+
+   if (intsts & MSDC_INT_RSPCRCERR) {
+   cmd_err = -EILSEQ;
+   dev_err(host->dev, "%s: CMD CRC ERR", __func__);
+   } else if (intsts & MSDC_INT_CMDTMO) {
+   cmd_err = -ETIMEDOUT;
+   dev_err(host->dev, "%s: CMD TIMEOUT ERR", __func__);
+   }
+
+   if (intsts & MSDC_INT_DATCRCERR) {
+   dat_err = -EILSEQ;
+   dev_err(host->dev, "%s: DATA CRC ERR", __func__);
+   } else if (intsts & MSDC_INT_DATTMO) {
+   dat_err = -ETIMEDOUT;
+   dev_err(host->dev, "%s: DATA TIMEOUT ERR", __func__);
+   }
+
+   if (cmd_err || dat_err) {
+   dev_err(host->dev, "cmd_err = %d, dat_err =%d, intsts = 0x%x",
+   cmd_err, dat_err, intsts);
+   }
+
+   return cqhci_irq(host->mmc, 0, cmd_err, dat_err);
+}
+#endif
+
 static irqreturn_t msdc_irq(int irq, void *dev_id)
 {
struct msdc_host *host = (struct msdc_host *) dev_id;
@@ -1516,6 +1562,16 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
if (!(events & (event_mask & ~MSDC_INT_SDIOIRQ)))
break;
 
+#if IS_ENABLED(CONFIG_MMC_CQHCI)
+   if ((host->mmc->caps2 & MMC_CAP2_CQE) &&
+   (events & MSDC_INT_CMDQ)) {
+   msdc_cmdq_irq(host, events);
+   /* clear interrupts */
+

[PATCH v6 4/4] dt-bindings: mmc: mediatek: Add document for mt6779

[Chun-Hung Wu]

Add compatible node for mt6779 mmc and HW cmdq selection
node "mediatek,cqhci".

Signed-off-by: Chun-Hung Wu 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 8a532f4..d4d20b9 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -12,6 +12,7 @@ Required properties:
"mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
"mediatek,mt8183-mmc": for mmc host ip compatible with mt8183
"mediatek,mt8516-mmc": for mmc host ip compatible with mt8516
+   "mediatek,mt6779-mmc": for mmc host ip compatible with mt6779
"mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
"mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
"mediatek,mt7622-mmc": for MT7622 SoC
@@ -49,6 +50,9 @@ Optional properties:
 error caused by stop clock(fifo full)
 Valid range = [0:0x7]. if not present, default value is 0.
 applied to compatible "mediatek,mt2701-mmc".
+- mediatek,cqhci: HW cmdq selection
+ If present, hw command queue is enabled.
+ If not present, hw command queue is disabled.
 
 Examples:
 mmc0: mmc@1123 {
-- 
1.9.1

[PATCH v6 0/4] mmc: mediatek: add mmc cqhci support

[Chun-Hung Wu]

This series provides MediaTek cqhci implementations as below:
  - Extend mmc_of_parse() to parse CQE bindings
  - Remove redundant host CQE bindings
  - Refine msdc timeout api to reduce redundant code
  - MediaTek command queue support
  - dt-bindings for mt6779

v1 -> v2:
  - Add more patch details in commit message
  - Separate msdc timeout api refine to individual patch

v2 -> v3:
  - Remove CR-Id, Change-Id and Feature in patches
  - Add Signed-off-by in patches

v3 -> v4:
  - Refine CQE bindings in mmc_of_parse (Ulf Hansson)
  - Remove redundant host CQE bindings (Linux Walleij)

v4 -> v5:
  - Add Acked-by and more maintainers

v5 -> v6:
  - Move CQE bindings back to vendor driver
  - Add mt6779 mmc support as an individual patch
  - Error handling for cq_host devm_kzallo()

Chun-Hung Wu (4):
  [1/4] mmc: mediatek: add MT6779 MMC driver support
  [2/4] mmc: mediatek: refine msdc timeout api
  [3/4] mmc: mediatek: command queue support
  [4/4] dt-bindings: mmc: mediatek: Add document for mt6779

 Documentation/devicetree/bindings/mmc/mtk-sd.txt |   4 +
 drivers/mmc/host/mtk-sd.c| 164 +--
 2 files changed, 158 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH v6 2/4] mmc: mediatek: refine msdc timeout api

[Chun-Hung Wu]

Extract msdc timeout api common part to have
better code architecture and avoid redundant code.

Signed-off-by: Chun-Hung Wu 
---
 drivers/mmc/host/mtk-sd.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 8ada675..84a7bd44 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -723,21 +723,21 @@ static void msdc_unprepare_data(struct msdc_host *host, 
struct mmc_request *mrq)
}
 }
 
-/* clock control primitives */
-static void msdc_set_timeout(struct msdc_host *host, u32 ns, u32 clks)
+static u64 msdc_timeout_cal(struct msdc_host *host, u64 ns, u64 clks)
 {
-   u32 timeout, clk_ns;
+   u64 timeout, clk_ns;
u32 mode = 0;
 
-   host->timeout_ns = ns;
-   host->timeout_clks = clks;
if (host->mmc->actual_clock == 0) {
timeout = 0;
} else {
-   clk_ns  = 10UL / host->mmc->actual_clock;
-   timeout = (ns + clk_ns - 1) / clk_ns + clks;
+   clk_ns  = 10ULL;
+   do_div(clk_ns, host->mmc->actual_clock);
+   timeout = ns + clk_ns - 1;
+   do_div(timeout, clk_ns);
+   timeout += clks;
/* in 1048576 sclk cycle unit */
-   timeout = (timeout + (0x1 << 20) - 1) >> 20;
+   timeout = DIV_ROUND_UP(timeout, (0x1 << 20));
if (host->dev_comp->clk_div_bits == 8)
sdr_get_field(host->base + MSDC_CFG,
  MSDC_CFG_CKMOD, );
@@ -747,9 +747,21 @@ static void msdc_set_timeout(struct msdc_host *host, u32 
ns, u32 clks)
/*DDR mode will double the clk cycles for data timeout */
timeout = mode >= 2 ? timeout * 2 : timeout;
timeout = timeout > 1 ? timeout - 1 : 0;
-   timeout = timeout > 255 ? 255 : timeout;
}
-   sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC, timeout);
+   return timeout;
+}
+
+/* clock control primitives */
+static void msdc_set_timeout(struct msdc_host *host, u64 ns, u64 clks)
+{
+   u64 timeout;
+
+   host->timeout_ns = ns;
+   host->timeout_clks = clks;
+
+   timeout = msdc_timeout_cal(host, ns, clks);
+   sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC,
+ (u32)(timeout > 255 ? 255 : timeout));
 }
 
 static void msdc_gate_clock(struct msdc_host *host)
-- 
1.9.1