[PATCH v8 5/5] kasan debug: track pages allocated for vmalloc shadow

[Daniel Axtens]

Provide the current number of vmalloc shadow pages in
/sys/kernel/debug/kasan/vmalloc_shadow_pages.

Signed-off-by: Daniel Axtens 

---

v8: rename kasan_vmalloc/shadow_pages -> kasan/vmalloc_shadow_pages

On v4 (no dynamic freeing), I saw the following approximate figures
on my test VM:

 - fresh boot: 720
 - after test_vmalloc: ~14000

With v5 (lazy dynamic freeing):

 - boot: ~490-500
 - running modprobe test_vmalloc pushes the figures up to sometimes
as high as ~14000, but they drop down to ~560 after the test ends.
I'm not sure where the extra sixty pages are from, but running the
test repeately doesn't cause the number to keep growing, so I don't
think we're leaking.
 - with vmap_stack, spawning tasks pushes the figure up to ~4200, then
some clearing kicks in and drops it down to previous levels again.
---
 mm/kasan/common.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index e33cbab83309..5b924f860a32 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -750,6 +751,8 @@ core_initcall(kasan_memhotplug_init);
 #endif
 
 #ifdef CONFIG_KASAN_VMALLOC
+static u64 vmalloc_shadow_pages;
+
 static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
  void *unused)
 {
@@ -776,6 +779,7 @@ static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned 
long addr,
if (likely(pte_none(*ptep))) {
set_pte_at(&init_mm, addr, ptep, pte);
page = 0;
+   vmalloc_shadow_pages++;
}
spin_unlock(&init_mm.page_table_lock);
if (page)
@@ -829,6 +833,7 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, 
unsigned long addr,
if (likely(!pte_none(*ptep))) {
pte_clear(&init_mm, addr, ptep);
free_page(page);
+   vmalloc_shadow_pages--;
}
spin_unlock(&init_mm.page_table_lock);
 
@@ -947,4 +952,25 @@ void kasan_release_vmalloc(unsigned long start, unsigned 
long end,
   (unsigned long)shadow_end);
}
 }
+
+static __init int kasan_init_debugfs(void)
+{
+   struct dentry *root, *count;
+
+   root = debugfs_create_dir("kasan", NULL);
+   if (IS_ERR(root)) {
+   if (PTR_ERR(root) == -ENODEV)
+   return 0;
+   return PTR_ERR(root);
+   }
+
+   count = debugfs_create_u64("vmalloc_shadow_pages", 0444, root,
+  &vmalloc_shadow_pages);
+
+   if (IS_ERR(count))
+   return PTR_ERR(root);
+
+   return 0;
+}
+late_initcall(kasan_init_debugfs);
 #endif
-- 
2.20.1

[PATCH v8 4/5] x86/kasan: support KASAN_VMALLOC

[Daniel Axtens]

In the case where KASAN directly allocates memory to back vmalloc
space, don't map the early shadow page over it.

We prepopulate pgds/p4ds for the range that would otherwise be empty.
This is required to get it synced to hardware on boot, allowing the
lower levels of the page tables to be filled dynamically.

Acked-by: Dmitry Vyukov 
Signed-off-by: Daniel Axtens 

---
v5: fix some checkpatch CHECK warnings. There are some that remain
around lines ending with '(': I have not changed these because
it's consistent with the rest of the file and it's not easy to
see how to fix it without creating an overlong line or lots of
temporary variables.

v2: move from faulting in shadow pgds to prepopulating
---
 arch/x86/Kconfig|  1 +
 arch/x86/mm/kasan_init_64.c | 60 +
 2 files changed, 61 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 96ea2c7449ef..3590651e95f5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -135,6 +135,7 @@ config X86
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN  if X86_64
+   select HAVE_ARCH_KASAN_VMALLOC  if X86_64
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS  if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS   if MMU && COMPAT
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 296da58f3013..8f00f462709e 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -245,6 +245,51 @@ static void __init kasan_map_early_shadow(pgd_t *pgd)
} while (pgd++, addr = next, addr != end);
 }
 
+static void __init kasan_shallow_populate_p4ds(pgd_t *pgd,
+  unsigned long addr,
+  unsigned long end,
+  int nid)
+{
+   p4d_t *p4d;
+   unsigned long next;
+   void *p;
+
+   p4d = p4d_offset(pgd, addr);
+   do {
+   next = p4d_addr_end(addr, end);
+
+   if (p4d_none(*p4d)) {
+   p = early_alloc(PAGE_SIZE, nid, true);
+   p4d_populate(&init_mm, p4d, p);
+   }
+   } while (p4d++, addr = next, addr != end);
+}
+
+static void __init kasan_shallow_populate_pgds(void *start, void *end)
+{
+   unsigned long addr, next;
+   pgd_t *pgd;
+   void *p;
+   int nid = early_pfn_to_nid((unsigned long)start);
+
+   addr = (unsigned long)start;
+   pgd = pgd_offset_k(addr);
+   do {
+   next = pgd_addr_end(addr, (unsigned long)end);
+
+   if (pgd_none(*pgd)) {
+   p = early_alloc(PAGE_SIZE, nid, true);
+   pgd_populate(&init_mm, pgd, p);
+   }
+
+   /*
+* we need to populate p4ds to be synced when running in
+* four level mode - see sync_global_pgds_l4()
+*/
+   kasan_shallow_populate_p4ds(pgd, addr, next, nid);
+   } while (pgd++, addr = next, addr != (unsigned long)end);
+}
+
 #ifdef CONFIG_KASAN_INLINE
 static int kasan_die_handler(struct notifier_block *self,
 unsigned long val,
@@ -352,9 +397,24 @@ void __init kasan_init(void)
shadow_cpu_entry_end = (void *)round_up(
(unsigned long)shadow_cpu_entry_end, PAGE_SIZE);
 
+   /*
+* If we're in full vmalloc mode, don't back vmalloc space with early
+* shadow pages. Instead, prepopulate pgds/p4ds so they are synced to
+* the global table and we can populate the lower levels on demand.
+*/
+#ifdef CONFIG_KASAN_VMALLOC
+   kasan_shallow_populate_pgds(
+   kasan_mem_to_shadow((void *)PAGE_OFFSET + MAXMEM),
+   kasan_mem_to_shadow((void *)VMALLOC_END));
+
+   kasan_populate_early_shadow(
+   kasan_mem_to_shadow((void *)VMALLOC_END + 1),
+   shadow_cpu_entry_begin);
+#else
kasan_populate_early_shadow(
kasan_mem_to_shadow((void *)PAGE_OFFSET + MAXMEM),
shadow_cpu_entry_begin);
+#endif
 
kasan_populate_shadow((unsigned long)shadow_cpu_entry_begin,
  (unsigned long)shadow_cpu_entry_end, 0);
-- 
2.20.1

[PATCH v8 3/5] fork: support VMAP_STACK with KASAN_VMALLOC

[Daniel Axtens]

Supporting VMAP_STACK with KASAN_VMALLOC is straightforward:

 - clear the shadow region of vmapped stacks when swapping them in
 - tweak Kconfig to allow VMAP_STACK to be turned on with KASAN

Reviewed-by: Dmitry Vyukov 
Signed-off-by: Daniel Axtens 
---
 arch/Kconfig  | 9 +
 kernel/fork.c | 4 
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 5f8a5d84dbbe..2d914990402f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -843,16 +843,17 @@ config HAVE_ARCH_VMAP_STACK
 config VMAP_STACK
default y
bool "Use a virtually-mapped stack"
-   depends on HAVE_ARCH_VMAP_STACK && !KASAN
+   depends on HAVE_ARCH_VMAP_STACK
+   depends on !KASAN || KASAN_VMALLOC
---help---
  Enable this if you want the use virtually-mapped kernel stacks
  with guard pages.  This causes kernel stack overflows to be
  caught immediately rather than causing difficult-to-diagnose
  corruption.
 
- This is presently incompatible with KASAN because KASAN expects
- the stack to map directly to the KASAN shadow map using a formula
- that is incorrect if the stack is in vmalloc space.
+ To use this with KASAN, the architecture must support backing
+ virtual mappings with real shadow memory, and KASAN_VMALLOC must
+ be enabled.
 
 config ARCH_OPTIONAL_KERNEL_RWX
def_bool n
diff --git a/kernel/fork.c b/kernel/fork.c
index 6adbbcf448c3..0c9e6478ba85 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -94,6 +94,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -229,6 +230,9 @@ static unsigned long *alloc_thread_stack_node(struct 
task_struct *tsk, int node)
if (!s)
continue;
 
+   /* Clear the KASAN shadow of the stack. */
+   kasan_unpoison_shadow(s->addr, THREAD_SIZE);
+
/* Clear stale pointers from reused stack. */
memset(s->addr, 0, THREAD_SIZE);
 
-- 
2.20.1

[PATCH v8 2/5] kasan: add test for vmalloc

[Daniel Axtens]

Test kasan vmalloc support by adding a new test to the module.

Signed-off-by: Daniel Axtens 

--

v5: split out per Christophe Leroy
---
 lib/test_kasan.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 49cc4d570a40..328d33beae36 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -748,6 +749,30 @@ static noinline void __init kmalloc_double_kzfree(void)
kzfree(ptr);
 }
 
+#ifdef CONFIG_KASAN_VMALLOC
+static noinline void __init vmalloc_oob(void)
+{
+   void *area;
+
+   pr_info("vmalloc out-of-bounds\n");
+
+   /*
+* We have to be careful not to hit the guard page.
+* The MMU will catch that and crash us.
+*/
+   area = vmalloc(3000);
+   if (!area) {
+   pr_err("Allocation failed\n");
+   return;
+   }
+
+   ((volatile char *)area)[3100];
+   vfree(area);
+}
+#else
+static void __init vmalloc_oob(void) {}
+#endif
+
 static int __init kmalloc_tests_init(void)
 {
/*
@@ -793,6 +818,7 @@ static int __init kmalloc_tests_init(void)
kasan_strings();
kasan_bitops();
kmalloc_double_kzfree();
+   vmalloc_oob();
 
kasan_restore_multi_shot(multishot);
 
-- 
2.20.1

[PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

[Daniel Axtens]

Hook into vmalloc and vmap, and dynamically allocate real shadow
memory to back the mappings.

Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mappings
use different shadow pages, mappings would have to be aligned to
KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE.

Instead, share backing space across multiple mappings. Allocate a
backing page when a mapping in vmalloc space uses a particular page of
the shadow region. This page can be shared by other vmalloc mappings
later on.

We hook in to the vmap infrastructure to lazily clean up unused shadow
memory.

To avoid the difficulties around swapping mappings around, this code
expects that the part of the shadow region that covers the vmalloc
space will not be covered by the early shadow page, but will be left
unmapped. This will require changes in arch-specific code.

This allows KASAN with VMAP_STACK, and may be helpful for architectures
that do not have a separate module space (e.g. powerpc64, which I am
currently working on). It also allows relaxing the module alignment
back to PAGE_SIZE.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009
Acked-by: Vasily Gorbik 
Signed-off-by: Daniel Axtens 
[Mark: rework shadow allocation]
Signed-off-by: Mark Rutland 

--

v2: let kasan_unpoison_shadow deal with ranges that do not use a
full shadow byte.

v3: relax module alignment
rename to kasan_populate_vmalloc which is a much better name
deal with concurrency correctly

v4: Mark's rework
Poision pages on vfree
Handle allocation failures

v5: Per Christophe Leroy, split out test and dynamically free pages.

v6: Guard freeing page properly. Drop WARN_ON_ONCE(pte_none(*ptep)),
 on reflection it's unnecessary debugging cruft with too high a
 false positive rate.

v7: tlb flush, thanks Mark.
explain more clearly how freeing works and is concurrency-safe.
---
 Documentation/dev-tools/kasan.rst |  63 +
 include/linux/kasan.h |  31 +
 include/linux/moduleloader.h  |   2 +-
 include/linux/vmalloc.h   |  12 ++
 lib/Kconfig.kasan |  16 +++
 mm/kasan/common.c | 204 ++
 mm/kasan/generic_report.c |   3 +
 mm/kasan/kasan.h  |   1 +
 mm/vmalloc.c  |  45 ++-
 9 files changed, 375 insertions(+), 2 deletions(-)

diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index b72d07d70239..bdb92c3de7a5 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -215,3 +215,66 @@ brk handler is used to print bug reports.
 A potential expansion of this mode is a hardware tag-based mode, which would
 use hardware memory tagging support instead of compiler instrumentation and
 manual shadow memory manipulation.
+
+What memory accesses are sanitised by KASAN?
+
+
+The kernel maps memory in a number of different parts of the address
+space. This poses something of a problem for KASAN, which requires
+that all addresses accessed by instrumented code have a valid shadow
+region.
+
+The range of kernel virtual addresses is large: there is not enough
+real memory to support a real shadow region for every address that
+could be accessed by the kernel.
+
+By default
+~~
+
+By default, architectures only map real memory over the shadow region
+for the linear mapping (and potentially other small areas). For all
+other areas - such as vmalloc and vmemmap space - a single read-only
+page is mapped over the shadow area. This read-only shadow page
+declares all memory accesses as permitted.
+
+This presents a problem for modules: they do not live in the linear
+mapping, but in a dedicated module space. By hooking in to the module
+allocator, KASAN can temporarily map real shadow memory to cover
+them. This allows detection of invalid accesses to module globals, for
+example.
+
+This also creates an incompatibility with ``VMAP_STACK``: if the stack
+lives in vmalloc space, it will be shadowed by the read-only page, and
+the kernel will fault when trying to set up the shadow data for stack
+variables.
+
+CONFIG_KASAN_VMALLOC
+
+
+With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
+cost of greater memory usage. Currently this is only supported on x86.
+
+This works by hooking into vmalloc and vmap, and dynamically
+allocating real shadow memory to back the mappings.
+
+Most mappings in vmalloc space are small, requiring less than a full
+page of shadow space. Allocating a full shadow page per mapping would
+therefore be wasteful. Furthermore, to ensure that different mappings
+use different shadow pages, mappings would have to be aligned to
+``KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE``.
+
+Instead, we share backing space across multiple mappings. We a

[PATCH v8 0/5] kasan: support backing vmalloc space with real shadow memory

[Daniel Axtens]

Currently, vmalloc space is backed by the early shadow page. This
means that kasan is incompatible with VMAP_STACK.

This series provides a mechanism to back vmalloc space with real,
dynamically allocated memory. I have only wired up x86, because that's
the only currently supported arch I can work with easily, but it's
very easy to wire up other architectures, and it appears that there is
some work-in-progress code to do this on arm64 and s390.

This has been discussed before in the context of VMAP_STACK:
 - https://bugzilla.kernel.org/show_bug.cgi?id=202009
 - https://lkml.org/lkml/2018/7/22/198
 - https://lkml.org/lkml/2019/7/19/822

In terms of implementation details:

Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mappings
use different shadow pages, mappings would have to be aligned to
KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE.

Instead, share backing space across multiple mappings. Allocate a
backing page when a mapping in vmalloc space uses a particular page of
the shadow region. This page can be shared by other vmalloc mappings
later on.

We hook in to the vmap infrastructure to lazily clean up unused shadow
memory.

v1: https://lore.kernel.org/linux-mm/20190725055503.19507-1-...@axtens.net/
v2: https://lore.kernel.org/linux-mm/20190729142108.23343-1-...@axtens.net/
 Address review comments:
 - Patch 1: use kasan_unpoison_shadow's built-in handling of
ranges that do not align to a full shadow byte
 - Patch 3: prepopulate pgds rather than faulting things in
v3: https://lore.kernel.org/linux-mm/20190731071550.31814-1-...@axtens.net/
 Address comments from Mark Rutland:
 - kasan_populate_vmalloc is a better name
 - handle concurrency correctly
 - various nits and cleanups
 - relax module alignment in KASAN_VMALLOC case
v4: https://lore.kernel.org/linux-mm/20190815001636.12235-1-...@axtens.net/
 Changes to patch 1 only:
 - Integrate Mark's rework, thanks Mark!
 - handle the case where kasan_populate_shadow might fail
 - poision shadow on free, allowing the alloc path to just
 unpoision memory that it uses
v5: https://lore.kernel.org/linux-mm/20190830003821.10737-1-...@axtens.net/
 Address comments from Christophe Leroy:
 - Fix some issues with my descriptions in commit messages and docs
 - Dynamically free unused shadow pages by hooking into the vmap book-keeping
 - Split out the test into a separate patch
 - Optional patch to track the number of pages allocated
 - minor checkpatch cleanups
v6: https://lore.kernel.org/linux-mm/20190902112028.23773-1-...@axtens.net/
 Properly guard freeing pages in patch 1, drop debugging code.
v7: https://lore.kernel.org/linux-mm/20190903145536.3390-1-...@axtens.net/
Add a TLB flush on freeing, thanks Mark Rutland.
Explain more clearly how I think freeing is concurrency-safe.
v8: rename kasan_vmalloc/shadow_pages to kasan/vmalloc_shadow_pages

Daniel Axtens (5):
  kasan: support backing vmalloc space with real shadow memory
  kasan: add test for vmalloc
  fork: support VMAP_STACK with KASAN_VMALLOC
  x86/kasan: support KASAN_VMALLOC
  kasan debug: track pages allocated for vmalloc shadow

 Documentation/dev-tools/kasan.rst |  63 
 arch/Kconfig  |   9 +-
 arch/x86/Kconfig  |   1 +
 arch/x86/mm/kasan_init_64.c   |  60 
 include/linux/kasan.h |  31 
 include/linux/moduleloader.h  |   2 +-
 include/linux/vmalloc.h   |  12 ++
 kernel/fork.c |   4 +
 lib/Kconfig.kasan |  16 +++
 lib/test_kasan.c  |  26 
 mm/kasan/common.c | 230 ++
 mm/kasan/generic_report.c |   3 +
 mm/kasan/kasan.h  |   1 +
 mm/vmalloc.c  |  45 +-
 14 files changed, 497 insertions(+), 6 deletions(-)

-- 
2.20.1

Re: [PATCH v4 1/2] edac: Add an API for edac device to report for multiple errors

[Robert Richter]

On 30.09.19 16:50:46, Borislav Petkov wrote:
> --
> On Mon, Sep 23, 2019 at 08:17:40PM +0100, Hanna Hawa wrote:
> > +void edac_device_handle_ce(struct edac_device_ctl_info *edac_dev,
> > +   int inst_nr, int block_nr, const char *msg)
> > +{
> > +   __edac_device_handle_ce(edac_dev, 1, inst_nr, block_nr, msg);
> > +}
> > +EXPORT_SYMBOL_GPL(edac_device_handle_ce);
> 
> Eww, I don't like that: exporting the function *and* the __ counterpart.
> The user will get confused and that is unnecessary.

It is *not* the counterpart. The __* version already has the
additional count argument in. There are 2 patches:

1) introduce new function __edac_device_handle_ce/ue() including the
   *_count() inline functions, but keep the old symbols (note the
   count=1 parameter).

2) remove old symbol edac_device_handle_ce/ue() and replace it with an
   inline function to use the counterpart symbol too.

The first patch only adds functionality but keeps the abi. Thus it
makes a backport easier. The 2nd switches completely to the new
function.

-Robert

Re: [PATCH v5 0/3] mfd: mc13xxx: Fixes and enhancements for NXP's mc34708

[Lee Jones]

On Mon, 30 Sep 2019, Lukasz Majewski wrote:

> Dear Lee,
> 
> > This patch set provides several enhancements to mc13xxx MFD family
> > of devices by introducing mc34708 as a separate device.
> > 
> > This IC has dedicated pen detection feature, which allows better
> > touchscreen experience.
> > 
> > This is the fifth version of this code (v5).
> > Discussion regarding previous versions can be found here:
> > https://lkml.org/lkml/2018/4/12/351
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1661934.html
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1664296.html
> > https://lkml.org/lkml/2019/7/17/705
> 
> Gentle ping on this patch series. It is now 3 weeks without any reply...

Please take note and follow the kernel release cycle.

These patches were sent after the release of -rc7 i.e. very late
in the release cycle and a point where most kernel maintainers stop
reviewing/applying patches and start to prepare for the impending
merge-window.

Also, there is no such thing as a gentle ping.  If you genuinely think
your patches have unlikely("slipped though the gaps"), then post a
[RESEND] complete with a note alluding your reasons doing such.

> > Sascha Hauer (3):
> >   mfd: mc13xxx: Add mc34708 adc support
> >   input: touchscreen mc13xxx: Make platform data optional
> >   input: touchscreen mc13xxx: Add mc34708 support
> > 
> >  drivers/input/touchscreen/mc13783_ts.c | 63 ++---
> >  drivers/mfd/mc13xxx-core.c | 98
> > +- include/linux/mfd/mc34708.h|
> > 37 ++ 3 files changed, 185 insertions(+), 13 deletions(-)
> >  create mode 100644 include/linux/mfd/mc34708.h

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] dma/coherent: remove unused dma_get_device_base()

[Christoph Hellwig]

On Wed, Sep 25, 2019 at 04:54:37PM -0400, Qian Cai wrote:
> Ping. Please take a look at this trivial patch.

No need to rush.  We just had the 5.4 merge window closing.  I'll
queue this up in the dma-mapping for-next tree for 5.5 once I open it.

[PATCH net v2] net: ag71xx: fix mdio subnode support

[Oleksij Rempel]

This patch is syncing driver with actual devicetree documentation:
Documentation/devicetree/bindings/net/qca,ar71xx.txt
|Optional subnodes:
|- mdio : specifies the mdio bus, used as a container for phy nodes
|  according to phy.txt in the same directory

The driver was working with fixed phy without any noticeable issues. This bug
was uncovered by introducing dsa ar9331-switch driver.
Since no one reported this bug until now, I assume no body is using it
and this patch should not brake existing system.

Fixes: d51b6ce441d3 ("net: ethernet: add ag71xx driver")
Signed-off-by: Oleksij Rempel 
---
 drivers/net/ethernet/atheros/ag71xx.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/atheros/ag71xx.c 
b/drivers/net/ethernet/atheros/ag71xx.c
index 6703960c7cf5..d1101eea15c2 100644
--- a/drivers/net/ethernet/atheros/ag71xx.c
+++ b/drivers/net/ethernet/atheros/ag71xx.c
@@ -526,7 +526,7 @@ static int ag71xx_mdio_probe(struct ag71xx *ag)
struct device *dev = &ag->pdev->dev;
struct net_device *ndev = ag->ndev;
static struct mii_bus *mii_bus;
-   struct device_node *np;
+   struct device_node *np, *mnp;
int err;
 
np = dev->of_node;
@@ -571,7 +571,9 @@ static int ag71xx_mdio_probe(struct ag71xx *ag)
msleep(200);
}
 
-   err = of_mdiobus_register(mii_bus, np);
+   mnp = of_get_child_by_name(np, "mdio");
+   err = of_mdiobus_register(mii_bus, mnp);
+   of_node_put(mnp);
if (err)
goto mdio_err_put_clk;
 
-- 
2.23.0

Re: [PATCH] media: uvcvideo: Use streaming DMA APIs to transfer buffers

[Christoph Hellwig]

On Mon, Sep 30, 2019 at 01:23:10AM -0700, Christoph Hellwig wrote:
> And drivers really have no business looking at the dma mask.  I have
> a plan for dma_alloc_pages API that could replace that cruft, but
> until then please use GFP_KERNEL and let the dma subsystem bounce
> buffer if needed.

Can you try this series:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_pages

and see if it does whay you need for usb?

Re: [PATCH] staging: speakup: document sysfs attributes

[Greg Kroah-Hartman]

On Sat, Sep 21, 2019 at 11:22:14AM +0100, Okash Khawaja wrote:
> Speakup exposes a set of sysfs attributes under
> /sys/accessibility/speakup/ for user-space to interact with and
> configure speakup's kernel modules. This patch describes those
> attributes. Some attributes either lack a description or contain
> incomplete description. They are marked wit TODO.
> 
> Authored-by: Gregory Nowak 
> Submitted-by: Okash Khawaja 

I just realized by neither of these are valid signed-off-by lines, so I
can't take it :(

Please resend this and sign-off on it properly, as documented in the
kernel documentation files.

thanks,

greg k-h

Re: [PATCH 5.3 00/25] 5.3.2-stable review

[Greg Kroah-Hartman]

On Mon, Sep 30, 2019 at 04:31:51PM -0600, shuah wrote:
> On 9/29/19 7:56 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.2 release.
> > There are 25 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue 01 Oct 2019 01:47:47 PM UTC.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.2-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.3.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 5.3 00/25] 5.3.2-stable review

[Greg Kroah-Hartman]

On Mon, Sep 30, 2019 at 08:11:37PM -0500, Dan Rue wrote:
> On Sun, Sep 29, 2019 at 03:56:03PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.2 release.
> > There are 25 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue 01 Oct 2019 01:47:47 PM UTC.
> > Anything received after that time might be too late.
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 5.3 00/25] 5.3.2-stable review

[Greg Kroah-Hartman]

On Mon, Sep 30, 2019 at 11:30:15AM -0700, Guenter Roeck wrote:
> On Sun, Sep 29, 2019 at 03:56:03PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.2 release.
> > There are 25 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue 01 Oct 2019 01:47:47 PM UTC.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 158 pass: 158 fail: 0
> Qemu test results:
>   total: 391 pass: 391 fail: 0

Great, thanks for testing all of these and letting me know.

greg k-h

[PATCH v3 04/14] dmaengine: Add metadata_ops for dma_async_tx_descriptor

[Peter Ujfalusi]

The metadata is best described as side band data or parameters traveling
alongside the data DMAd by the DMA engine. It is data
which is understood by the peripheral and the peripheral driver only, the
DMA engine see it only as data block and it is not interpreting it in any
way.

The metadata can be different per descriptor as it is a parameter for the
data being transferred.

If the DMA supports per descriptor metadata it can implement the attach,
get_ptr/set_len callbacks.

Client drivers must only use either attach or get_ptr/set_len to avoid
misconfiguration.

Client driver can check if a given metadata mode is supported by the
channel during probe time with
dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_CLIENT);
dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_ENGINE);

and based on this information can use either mode.

Wrappers are also added for the metadata_ops.

To be used in DESC_METADATA_CLIENT mode:
dmaengine_desc_attach_metadata()

To be used in DESC_METADATA_ENGINE mode:
dmaengine_desc_get_metadata_ptr()
dmaengine_desc_set_metadata_len()

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.c   |  73 ++
 include/linux/dmaengine.h | 108 ++
 2 files changed, 181 insertions(+)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 03ac4b96117c..6baddf7dcbfd 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1302,6 +1302,79 @@ void dma_async_tx_descriptor_init(struct 
dma_async_tx_descriptor *tx,
 }
 EXPORT_SYMBOL(dma_async_tx_descriptor_init);
 
+static inline int desc_check_and_set_metadata_mode(
+   struct dma_async_tx_descriptor *desc, enum dma_desc_metadata_mode mode)
+{
+   /* Make sure that the metadata mode is not mixed */
+   if (!desc->desc_metadata_mode) {
+   if (dmaengine_is_metadata_mode_supported(desc->chan, mode))
+   desc->desc_metadata_mode = mode;
+   else
+   return -ENOTSUPP;
+   } else if (desc->desc_metadata_mode != mode) {
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+int dmaengine_desc_attach_metadata(struct dma_async_tx_descriptor *desc,
+  void *data, size_t len)
+{
+   int ret;
+
+   if (!desc)
+   return -EINVAL;
+
+   ret = desc_check_and_set_metadata_mode(desc, DESC_METADATA_CLIENT);
+   if (ret)
+   return ret;
+
+   if (!desc->metadata_ops || !desc->metadata_ops->attach)
+   return -ENOTSUPP;
+
+   return desc->metadata_ops->attach(desc, data, len);
+}
+EXPORT_SYMBOL_GPL(dmaengine_desc_attach_metadata);
+
+void *dmaengine_desc_get_metadata_ptr(struct dma_async_tx_descriptor *desc,
+ size_t *payload_len, size_t *max_len)
+{
+   int ret;
+
+   if (!desc)
+   return ERR_PTR(-EINVAL);
+
+   ret = desc_check_and_set_metadata_mode(desc, DESC_METADATA_ENGINE);
+   if (ret)
+   return ERR_PTR(ret);
+
+   if (!desc->metadata_ops || !desc->metadata_ops->get_ptr)
+   return ERR_PTR(-ENOTSUPP);
+
+   return desc->metadata_ops->get_ptr(desc, payload_len, max_len);
+}
+EXPORT_SYMBOL_GPL(dmaengine_desc_get_metadata_ptr);
+
+int dmaengine_desc_set_metadata_len(struct dma_async_tx_descriptor *desc,
+   size_t payload_len)
+{
+   int ret;
+
+   if (!desc)
+   return -EINVAL;
+
+   ret = desc_check_and_set_metadata_mode(desc, DESC_METADATA_ENGINE);
+   if (ret)
+   return ret;
+
+   if (!desc->metadata_ops || !desc->metadata_ops->set_len)
+   return -ENOTSUPP;
+
+   return desc->metadata_ops->set_len(desc, payload_len);
+}
+EXPORT_SYMBOL_GPL(dmaengine_desc_set_metadata_len);
+
 /* dma_wait_for_async_tx - spin wait for a transaction to complete
  * @tx: in-flight transaction to wait on
  */
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 8fcdee1c0cf9..40d062c3b359 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -219,6 +219,58 @@ typedef struct { DECLARE_BITMAP(bits, DMA_TX_TYPE_END); } 
dma_cap_mask_t;
  * @bytes_transferred: byte counter
  */
 
+/**
+ * enum dma_desc_metadata_mode - per descriptor metadata mode types supported
+ * @DESC_METADATA_CLIENT - the metadata buffer is allocated/provided by the
+ *  client driver and it is attached (via the dmaengine_desc_attach_metadata()
+ *  helper) to the descriptor.
+ *
+ * Client drivers interested to use this mode can follow:
+ * - DMA_MEM_TO_DEV / DEV_MEM_TO_MEM:
+ *   1. prepare the descriptor (dmaengine_prep_*)
+ * construct the metadata in the client's buffer
+ *   2. use dmaengine_desc_attach_metadata() to attach the buffer to the
+ * descriptor
+ *   3. submit the transfer
+ * - DMA_DEV_TO_MEM:
+ *   1. prepare the descriptor (dmaengine_prep_*)
+ *   2. use dmaengine_desc_attach_

[PATCH v3 02/14] soc: ti: k3: add navss ringacc driver

[Peter Ujfalusi]

From: Grygorii Strashko 

The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.

The RINGACC converts constant-address read and write accesses to equivalent
read or write accesses to a circular data structure in memory. The RINGACC
eliminates the need for each DMA controller which needs to access ring
elements from having to know the current state of the ring (base address,
current offset). The DMA controller performs a read or write access to a
specific address range (which maps to the source interface on the RINGACC)
and the RINGACC replaces the address for the transaction with a new address
which corresponds to the head or tail element of the ring (head for reads,
tail for writes). Since the RINGACC maintains the state, multiple DMA
controllers or channels are allowed to coherently share the same rings as
applicable. The RINGACC is able to place data which is destined towards
software into cached memory directly.

Supported ring modes:
- Ring Mode
- Messaging Mode
- Credentials Mode
- Queue Manager Mode

TI-SCI integration:

Texas Instrument's System Control Interface (TI-SCI) Message Protocol now
has control over Ringacc module resources management (RM) and Rings
configuration.

The corresponding support of TI-SCI Ringacc module RM protocol
introduced as option through DT parameters:
- ti,sci: phandle on TI-SCI firmware controller DT node
- ti,sci-dev-id: TI-SCI device identifier as per TI-SCI firmware spec

if both parameters present - Ringacc driver will configure/free/reset Rings
using TI-SCI Message Ringacc RM Protocol.

The Ringacc driver manages Rings allocation by itself now and requests
TI-SCI firmware to allocate and configure specific Rings only. It's done
this way because, Linux driver implements two stage Rings allocation and
configuration (allocate ring and configure ring) while I-SCI Message
Protocol supports only one combined operation (allocate+configure).

Signed-off-by: Grygorii Strashko 
Signed-off-by: Peter Ujfalusi 
---
 drivers/soc/ti/Kconfig|   12 +
 drivers/soc/ti/Makefile   |1 +
 drivers/soc/ti/k3-ringacc.c   | 1165 +
 include/linux/soc/ti/k3-ringacc.h |  245 ++
 4 files changed, 1423 insertions(+)
 create mode 100644 drivers/soc/ti/k3-ringacc.c
 create mode 100644 include/linux/soc/ti/k3-ringacc.h

diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index cf545f428d03..87722d3a 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -80,6 +80,18 @@ config TI_SCI_PM_DOMAINS
  called ti_sci_pm_domains. Note this is needed early in boot before
  rootfs may be available.
 
+config TI_K3_RINGACC
+   tristate "K3 Ring accelerator Sub System"
+   depends on ARCH_K3 || COMPILE_TEST
+   depends on TI_SCI_INTA_IRQCHIP
+   default y
+   help
+ Say y here to support the K3 Ring accelerator module.
+ The Ring Accelerator (RINGACC or RA)  provides hardware acceleration
+ to enable straightforward passing of work between a producer
+ and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs
+ If unsure, say N.
+
 endif # SOC_TI
 
 config TI_SCI_INTA_MSI_DOMAIN
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index b3868d392d4f..cc4bc8b08bf5 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_AMX3_PM)   += pm33xx.o
 obj-$(CONFIG_WKUP_M3_IPC)  += wkup_m3_ipc.o
 obj-$(CONFIG_TI_SCI_PM_DOMAINS)+= ti_sci_pm_domains.o
 obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN)   += ti_sci_inta_msi.o
+obj-$(CONFIG_TI_K3_RINGACC)+= k3-ringacc.o
diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
new file mode 100644
index ..4728a79fd2c0
--- /dev/null
+++ b/drivers/soc/ti/k3-ringacc.c
@@ -0,0 +1,1165 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI K3 NAVSS Ring Accelerator subsystem driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static LIST_HEAD(k3_ringacc_list);
+static DEFINE_MUTEX(k3_ringacc_list_lock);
+
+#define K3_RINGACC_CFG_RING_SIZE_ELCNT_MASKGENMASK(19, 0)
+
+/**
+ * struct k3_ring_rt_regs -  The RA Control/Status Registers region
+ */
+struct k3_ring_rt_regs {
+   u32 resv_16[4];
+   u32 db; /* RT Ring N Doorbell Register */
+   u32 resv_4[1];
+   u32 occ;/* RT Ring N Occupancy Register */
+   u32 indx;   /* RT Ring N Current Index Register */
+   u32 hwocc;  /* RT Ring N Hardware Occupancy Register */
+   u32 hwindx; /* RT Ring N Current Index Register */
+};
+
+#define 

[PATCH v3 05/14] dmaengine: Add support for reporting DMA cached data amount

[Peter Ujfalusi]

A DMA hardware can have big cache or FIFO and the amount of data sitting in
the DMA fabric can be an interest for the clients.

For example in audio we want to know the delay in the data flow and in case
the DMA have significantly large FIFO/cache, it can affect the latenc/delay

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.h   | 8 
 include/linux/dmaengine.h | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
index 501c0b063f85..b0b97475707a 100644
--- a/drivers/dma/dmaengine.h
+++ b/drivers/dma/dmaengine.h
@@ -77,6 +77,7 @@ static inline enum dma_status dma_cookie_status(struct 
dma_chan *chan,
state->last = complete;
state->used = used;
state->residue = 0;
+   state->in_flight_bytes = 0;
}
return dma_async_is_complete(cookie, complete, used);
 }
@@ -87,6 +88,13 @@ static inline void dma_set_residue(struct dma_tx_state 
*state, u32 residue)
state->residue = residue;
 }
 
+static inline void dma_set_in_flight_bytes(struct dma_tx_state *state,
+  u32 in_flight_bytes)
+{
+   if (state)
+   state->in_flight_bytes = in_flight_bytes;
+}
+
 struct dmaengine_desc_callback {
dma_async_tx_callback callback;
dma_async_tx_callback_result callback_result;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 40d062c3b359..02ceef95340a 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -682,11 +682,13 @@ static inline struct dma_async_tx_descriptor 
*txd_next(struct dma_async_tx_descr
  * @residue: the remaining number of bytes left to transmit
  * on the selected transfer for states DMA_IN_PROGRESS and
  * DMA_PAUSED if this is implemented in the driver, else 0
+ * @in_flight_bytes: amount of data in bytes cached by the DMA.
  */
 struct dma_tx_state {
dma_cookie_t last;
dma_cookie_t used;
u32 residue;
+   u32 in_flight_bytes;
 };
 
 /**
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH v3 09/14] dmaengine: ti: New driver for K3 UDMA - split#2: probe/remove, xlate and filter_fn

[Peter Ujfalusi]

Split patch for review containing: module probe/remove functions, of_xlate
and filter_fn for slave channel requests.

DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)

The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types. The UDMA-P is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.

The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.

The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti/k3-udma.c | 617 +++
 1 file changed, 617 insertions(+)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 628120fffa2f..d40fd268b477 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1057,3 +1057,620 @@ static irqreturn_t udma_udma_irq_handler(int irq, void 
*data)
 
return IRQ_HANDLED;
 }
+
+static struct platform_driver udma_driver;
+
+static bool udma_slave_thread_is_packet_mode(struct udma_chan *uc)
+{
+   struct udma_dev *ud = uc->ud;
+   const struct udma_match_data *match_data = ud->match_data;
+   struct udma_tr_thread_ranges *tr_threads = match_data->tr_threads;
+   int i;
+
+   if (!tr_threads)
+   return true;
+
+   for (i = 0; tr_threads[i].count; i++) {
+   int start = tr_threads[i].start;
+   int count = tr_threads[i].count;
+
+   if (uc->remote_thread_id >= start &&
+   uc->remote_thread_id < (start + count))
+   return false;
+   }
+   return true;
+}
+
+static bool udma_dma_filter_fn(struct dma_chan *chan, void *param)
+{
+   u32 *args;
+   struct udma_chan *uc;
+   struct udma_dev *ud;
+   struct device_node *chconf_node, *slave_node;
+   char prop[50];
+   u32 val;
+
+   if (chan->device->dev->driver != &udma_driver.driver)
+   return false;
+
+   uc = to_udma_chan(chan);
+   ud = uc->ud;
+   args = param;
+
+   if (args[2] == UDMA_DIR_TX) {
+   uc->dir = DMA_MEM_TO_DEV;
+   } else if (args[2] == UDMA_DIR_RX) {
+   uc->dir = DMA_DEV_TO_MEM;
+   } else {
+   dev_err(ud->dev, "Invalid direction (%u)\n", args[2]);
+   return false;
+   }
+
+   slave_node = of_find_node_by_phandle(args[0]);
+   if (!slave_node) {
+   dev_err(ud->dev, "Slave node is missing\n");
+   uc->dir = DMA_MEM_TO_MEM;
+   return false;
+   }
+
+   if (of_property_read_u32(slave_node, "ti,psil-base", &val)) {
+   dev_err(ud->dev, "ti,psil-base is missing\n");
+   uc->dir = DMA_MEM_TO_MEM;
+   return false;
+   }
+
+   uc->remote_thread_id = val + args[1];
+
+   snprintf(prop, sizeof(prop), "psil-config%u", args[1]);
+   /* Does of_node_put on slave_node */
+   chconf_node = of_find_node_by_name(slave_node, prop);
+   if (!chconf_node) {
+   dev_err(ud->dev, "Channel configuration node is missing\n");
+   uc->dir = DMA_MEM_TO_MEM;
+   uc->remote_thread_id = -1;
+   return false;
+   }
+
+   uc->pkt_mode = udma_slave_thread_is_packet_mode(uc);
+
+   if (!of_property_read_u32(chconf_node, "ti,pdma-statictr-type", &val))
+   uc->static_tr_type = val;
+
+   if (uc->static_tr_type == PDMA_STATIC_TR_XY) {
+   const struct udma_match_data *match_data = ud->match_data;
+
+   if (match_data->have_acc32)
+   uc->enable_acc32 = of_property_read_bool(chconf_node,
+   "ti,pdma-enable-acc32");
+   if (match_data->have_burst)
+

[PATCH v3 13/14] dmaengine: ti: New driver for K3 UDMA - split#6: Kconfig and Makefile

[Peter Ujfalusi]

Split patch for review containing:
Kconfig and Makefile changes

DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)

The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types. The UDMA-P is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.

The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.

The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti/Kconfig  | 13 +
 drivers/dma/ti/Makefile |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig
index d507c24fbf31..b6b7571be394 100644
--- a/drivers/dma/ti/Kconfig
+++ b/drivers/dma/ti/Kconfig
@@ -34,5 +34,18 @@ config DMA_OMAP
  Enable support for the TI sDMA (System DMA or DMA4) controller. This
  DMA engine is found on OMAP and DRA7xx parts.
 
+config TI_K3_UDMA
+   tristate "Texas Instruments UDMA support"
+   depends on ARCH_K3 || COMPILE_TEST
+   depends on TI_SCI_PROTOCOL
+   depends on TI_SCI_INTA_IRQCHIP
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   select TI_K3_RINGACC
+   default y
+help
+ Enable support for the TI UDMA (Unified DMA) controller. This
+ DMA engine is used in AM65x.
+
 config TI_DMA_CROSSBAR
bool
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 113e59ec9c32..ebd4822e064e 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -2,4 +2,5 @@
 obj-$(CONFIG_TI_CPPI41) += cppi41.o
 obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_DMA_OMAP) += omap-dma.o
+obj-$(CONFIG_TI_K3_UDMA) += k3-udma.o
 obj-$(CONFIG_TI_DMA_CROSSBAR) += dma-crossbar.o
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH v3 14/14] dmaengine: ti: k3-udma: Add glue layer for non DMAengine users

[Peter Ujfalusi]

From: Grygorii Strashko 

Certain users can not use right now the DMAengine API due to missing
features in the core. Prime example is Networking.

These users can use the glue layer interface to avoid misuse of DMAengine
API and when the core gains the needed features they can be converted to
use generic API.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti/Kconfig   |9 +
 drivers/dma/ti/Makefile  |1 +
 drivers/dma/ti/k3-udma-glue.c| 1225 ++
 drivers/dma/ti/k3-udma-private.c |  141 
 drivers/dma/ti/k3-udma.c |   63 +-
 drivers/dma/ti/k3-udma.h |   31 +
 include/linux/dma/k3-udma-glue.h |  134 
 7 files changed, 1603 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/ti/k3-udma-glue.c
 create mode 100644 drivers/dma/ti/k3-udma-private.c
 create mode 100644 include/linux/dma/k3-udma-glue.h

diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig
index b6b7571be394..88f65c2123e9 100644
--- a/drivers/dma/ti/Kconfig
+++ b/drivers/dma/ti/Kconfig
@@ -47,5 +47,14 @@ config TI_K3_UDMA
  Enable support for the TI UDMA (Unified DMA) controller. This
  DMA engine is used in AM65x.
 
+config TI_K3_UDMA_GLUE_LAYER
+   tristate "Texas Instruments UDMA Glue layer for non DMAengine users"
+   depends on ARCH_K3 || COMPILE_TEST
+   depends on TI_K3_UDMA
+   default y
+   help
+ Say y here to support the K3 NAVSS DMA glue interface
+ If unsure, say N.
+
 config TI_DMA_CROSSBAR
bool
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index ebd4822e064e..fc6e0a2c7ce9 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_TI_CPPI41) += cppi41.o
 obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_DMA_OMAP) += omap-dma.o
 obj-$(CONFIG_TI_K3_UDMA) += k3-udma.o
+obj-$(CONFIG_TI_K3_UDMA_GLUE_LAYER) += k3-udma-glue.o
 obj-$(CONFIG_TI_DMA_CROSSBAR) += dma-crossbar.o
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
new file mode 100644
index ..c6ed2ae967dd
--- /dev/null
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -0,0 +1,1225 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * K3 NAVSS DMA glue interface
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "k3-udma.h"
+
+struct k3_udma_glue_common {
+   struct device *dev;
+   struct udma_dev *udmax;
+   const struct udma_tisci_rm *tisci_rm;
+   struct k3_ringacc *ringacc;
+   u32 src_thread;
+   u32 dst_thread;
+
+   u32  hdesc_size;
+   bool epib;
+   u32  psdata_size;
+   u32  swdata_size;
+};
+
+struct k3_udma_glue_tx_channel {
+   struct k3_udma_glue_common common;
+
+   struct udma_tchan *udma_tchanx;
+   int udma_tchan_id;
+
+   struct k3_ring *ringtx;
+   struct k3_ring *ringtxcq;
+
+   bool psil_paired;
+
+   int virq;
+
+   atomic_t free_pkts;
+   bool tx_pause_on_err;
+   bool tx_filt_einfo;
+   bool tx_filt_pswords;
+   bool tx_supr_tdpkt;
+};
+
+/**
+ * k3_udma_glue_rx_flow - UDMA RX flow context data
+ *
+ */
+struct k3_udma_glue_rx_flow {
+   struct udma_rflow *udma_rflow;
+   int udma_rflow_id;
+   struct k3_ring *ringrx;
+   struct k3_ring *ringrxfdq;
+
+   int virq;
+};
+
+struct k3_udma_glue_rx_channel {
+   struct k3_udma_glue_common common;
+
+   struct udma_rchan *udma_rchanx;
+   int udma_rchan_id;
+   bool remote;
+
+   bool psil_paired;
+
+   u32  swdata_size;
+   int  flow_id_base;
+
+   struct k3_udma_glue_rx_flow *flows;
+   u32 flow_num;
+   u32 flows_ready;
+};
+
+#define K3_UDMAX_TDOWN_TIMEOUT_US 1000
+
+static int of_k3_udma_glue_parse(struct device_node *udmax_np,
+struct k3_udma_glue_common *common)
+{
+   common->ringacc = of_k3_ringacc_get_by_phandle(udmax_np,
+  "ti,ringacc");
+   if (IS_ERR(common->ringacc))
+   return PTR_ERR(common->ringacc);
+
+   common->udmax = of_xudma_dev_get(udmax_np, NULL);
+   if (IS_ERR(common->udmax))
+   return PTR_ERR(common->udmax);
+
+   common->tisci_rm = xudma_dev_get_tisci_rm(common->udmax);
+
+   return 0;
+}
+
+static int of_k3_udma_glue_parse_chn(struct device_node *chn_np,
+   const char *name, struct k3_udma_glue_common *common,
+   bool tx_chn)
+{
+   struct device_node *psil_cfg_node;
+   struct device_node *ch_cfg_node;
+   struct of_phandle_args dma_spec;
+   int index, ret = 0;
+   char prop[50];
+   u32 val;
+
+   if (unlikely(!name))
+   return -EINVAL;
+
+   index = of_property_match_string(chn_np, "dma-names", name);
+

[PATCH v3 11/14] dmaengine: ti: New driver for K3 UDMA - split#4: dma_device callbacks 1

[Peter Ujfalusi]

Split patch for review containing:
device_config, device_issue_pending, device_tx_status, device_pause,
device_resume, device_terminate_all and device_synchronize callback
implementation and the custom udma_vchan_complete.

DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)

The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types. The UDMA-P is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.

The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.

The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti/k3-udma.c | 295 +++
 1 file changed, 295 insertions(+)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index c7368e150118..69a125ec3d07 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1816,6 +1816,301 @@ static int udma_alloc_chan_resources(struct dma_chan 
*chan)
return ret;
 }
 
+static int udma_slave_config(struct dma_chan *chan,
+struct dma_slave_config *cfg)
+{
+   struct udma_chan *uc = to_udma_chan(chan);
+
+   memcpy(&uc->cfg, cfg, sizeof(uc->cfg));
+
+   return 0;
+}
+
+static void udma_issue_pending(struct dma_chan *chan)
+{
+   struct udma_chan *uc = to_udma_chan(chan);
+   unsigned long flags;
+
+   spin_lock_irqsave(&uc->vc.lock, flags);
+
+   /* If we have something pending and no active descriptor, then */
+   if (vchan_issue_pending(&uc->vc) && !uc->desc) {
+   /*
+* start a descriptor if the channel is NOT [marked as
+* terminating _and_ it is still running (teardown has not
+* completed yet)].
+*/
+   if (!(uc->state == UDMA_CHAN_IS_TERMINATING &&
+ udma_is_chan_running(uc)))
+   udma_start(uc);
+   }
+
+   spin_unlock_irqrestore(&uc->vc.lock, flags);
+}
+
+/* Not much yet */
+static enum dma_status udma_tx_status(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ struct dma_tx_state *txstate)
+{
+   struct udma_chan *uc = to_udma_chan(chan);
+   enum dma_status ret;
+   unsigned long flags;
+
+   spin_lock_irqsave(&uc->vc.lock, flags);
+
+   ret = dma_cookie_status(chan, cookie, txstate);
+
+   if (!udma_is_chan_running(uc))
+   ret = DMA_COMPLETE;
+
+   if (ret == DMA_COMPLETE || !txstate)
+   goto out;
+
+   if (uc->desc && uc->desc->vd.tx.cookie == cookie) {
+   u32 peer_bcnt = 0;
+   u32 bcnt = 0;
+   u32 residue = uc->desc->residue;
+   u32 delay = 0;
+
+   if (uc->desc->dir == DMA_MEM_TO_DEV) {
+   bcnt = udma_tchanrt_read(uc->tchan,
+UDMA_TCHAN_RT_SBCNT_REG);
+
+   if (uc->static_tr_type) {
+   peer_bcnt = udma_tchanrt_read(uc->tchan,
+   UDMA_TCHAN_RT_PEER_BCNT_REG);
+
+   if (bcnt > peer_bcnt)
+   delay = bcnt - peer_bcnt;
+   }
+   } else if (uc->desc->dir == DMA_DEV_TO_MEM) {
+   bcnt = udma_rchanrt_read(uc->rchan,
+UDMA_RCHAN_RT_BCNT_REG);
+
+   if (uc->static_tr_type) {
+   peer_bcnt = udma_rchanrt_read(uc->rchan,
+   UDMA_RCHAN_RT_PEER_BCNT_REG);
+
+   if (peer_bcnt > bcnt)
+

[PATCH v3 10/14] dmaengine: ti: New driver for K3 UDMA - split#3: alloc/free chan_resources

[Peter Ujfalusi]

Split patch for review containing: channel rsource allocation and free
functions.

DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)

The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types. The UDMA-P is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.

The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.

The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti/k3-udma.c | 797 +++
 1 file changed, 797 insertions(+)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index d40fd268b477..c7368e150118 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1058,6 +1058,803 @@ static irqreturn_t udma_udma_irq_handler(int irq, void 
*data)
return IRQ_HANDLED;
 }
 
+static struct udma_rflow *__udma_get_rflow(struct udma_dev *ud, int id)
+{
+   /*
+* Attempt to request rflow by ID can be made for any rflow
+* if not in use with assumption that caller knows what's doing.
+* TI-SCI FW will perform additional permission check ant way, it's
+* safe
+*/
+
+   if (id < 0 || id >= ud->rflow_cnt)
+   return ERR_PTR(-ENOENT);
+
+   if (test_bit(id, ud->rflow_in_use))
+   return ERR_PTR(-ENOENT);
+
+   /* GP rflow has to be allocated first */
+   if (!test_bit(id, ud->rflow_gp_map) &&
+   !test_bit(id, ud->rflow_gp_map_allocated))
+   return ERR_PTR(-EINVAL);
+
+   dev_dbg(ud->dev, "get rflow%d\n", id);
+   set_bit(id, ud->rflow_in_use);
+   return &ud->rflows[id];
+}
+
+static void __udma_put_rflow(struct udma_dev *ud, struct udma_rflow *rflow)
+{
+   if (!test_bit(rflow->id, ud->rflow_in_use)) {
+   dev_err(ud->dev, "attempt to put unused rflow%d\n", rflow->id);
+   return;
+   }
+
+   dev_dbg(ud->dev, "put rflow%d\n", rflow->id);
+   clear_bit(rflow->id, ud->rflow_in_use);
+}
+
+#define UDMA_RESERVE_RESOURCE(res) \
+static struct udma_##res *__udma_reserve_##res(struct udma_dev *ud,\
+  enum udma_tp_level tpl,  \
+  int id)  \
+{  \
+   if (id >= 0) {  \
+   if (test_bit(id, ud->res##_map)) {  \
+   dev_err(ud->dev, "res##%d is in use\n", id);\
+   return ERR_PTR(-ENOENT);\
+   }   \
+   } else {\
+   int start;  \
+   \
+   if (tpl >= ud->match_data->tpl_levels)  \
+   tpl = ud->match_data->tpl_levels - 1;   \
+   \
+   start = ud->match_data->level_start_idx[tpl];   \
+   \
+   id = find_next_zero_bit(ud->res##_map, ud->res##_cnt,   \
+   start); \
+   if (id == ud->res##_cnt) {  \
+   return ERR_PTR(-ENOENT);\
+   }   \
+   } 

[PATCH v3 12/14] dmaengine: ti: New driver for K3 UDMA - split#5: dma_device callbacks 2

[Peter Ujfalusi]

Split patch for review containing:
device_prep_slave_sg and device_prep_dma_cyclic implementation supporting
packet and TR channels.

DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)

The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types. The UDMA-P is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.

The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.

The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti/k3-udma.c | 696 +++
 1 file changed, 696 insertions(+)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 69a125ec3d07..d3e83ced48b4 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1826,6 +1826,702 @@ static int udma_slave_config(struct dma_chan *chan,
return 0;
 }
 
+static struct udma_desc *udma_alloc_tr_desc(struct udma_chan *uc,
+   size_t tr_size, int tr_count,
+   enum dma_transfer_direction dir)
+{
+   struct udma_hwdesc *hwdesc;
+   struct cppi5_desc_hdr_t *tr_desc;
+   struct udma_desc *d;
+   u32 reload_count = 0;
+   u32 ring_id;
+
+   switch (tr_size) {
+   case 16:
+   case 32:
+   case 64:
+   case 128:
+   break;
+   default:
+   dev_err(uc->ud->dev, "Unsupported TR size of %zu\n", tr_size);
+   return NULL;
+   }
+
+   /* We have only one descriptor containing multiple TRs */
+   d = kzalloc(sizeof(*d) + sizeof(d->hwdesc[0]), GFP_ATOMIC);
+   if (!d)
+   return NULL;
+
+   d->sglen = tr_count;
+
+   d->hwdesc_count = 1;
+   hwdesc = &d->hwdesc[0];
+
+   /* Allocate memory for DMA ring descriptor */
+   if (uc->use_dma_pool) {
+   hwdesc->cppi5_desc_size = uc->hdesc_size;
+   hwdesc->cppi5_desc_vaddr = dma_pool_zalloc(uc->hdesc_pool,
+   GFP_ATOMIC,
+   &hwdesc->cppi5_desc_paddr);
+   } else {
+   hwdesc->cppi5_desc_size = cppi5_trdesc_calc_size(tr_size,
+tr_count);
+   hwdesc->cppi5_desc_size = ALIGN(hwdesc->cppi5_desc_size,
+   uc->ud->desc_align);
+   hwdesc->cppi5_desc_vaddr = dma_alloc_coherent(uc->ud->dev,
+   hwdesc->cppi5_desc_size,
+   &hwdesc->cppi5_desc_paddr,
+   GFP_ATOMIC);
+   }
+
+   if (!hwdesc->cppi5_desc_vaddr) {
+   kfree(d);
+   return NULL;
+   }
+
+   /* Start of the TR req records */
+   hwdesc->tr_req_base = hwdesc->cppi5_desc_vaddr + tr_size;
+   /* Start address of the TR response array */
+   hwdesc->tr_resp_base = hwdesc->tr_req_base + tr_size * tr_count;
+
+   tr_desc = hwdesc->cppi5_desc_vaddr;
+
+   if (uc->cyclic)
+   reload_count = CPPI5_INFO0_TRDESC_RLDCNT_INFINITE;
+
+   if (dir == DMA_DEV_TO_MEM)
+   ring_id = k3_ringacc_get_ring_id(uc->rchan->r_ring);
+   else
+   ring_id = k3_ringacc_get_ring_id(uc->tchan->tc_ring);
+
+   cppi5_trdesc_init(tr_desc, tr_count, tr_size, 0, reload_count);
+   cppi5_desc_set_pktids(tr_desc, uc->id, 0x3fff);
+   cppi5_desc_set_retpolicy(tr_desc, 0, ring_id);
+
+   return d;
+}
+
+static struct udma_desc *udma_prep_slave_sg_tr(
+   struct udma_chan *uc, struct scatterlist *sgl, unsigned int sglen,
+   enum dma_transf

[PATCH v3 01/14] bindings: soc: ti: add documentation for k3 ringacc

[Peter Ujfalusi]

From: Grygorii Strashko 

The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x and j721e.

This patch introduces RINGACC device tree bindings.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/soc/ti/k3-ringacc.txt | 59 +++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt

diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt 
b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt
new file mode 100644
index ..86954cf4fa99
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt
@@ -0,0 +1,59 @@
+* Texas Instruments K3 NavigatorSS Ring Accelerator
+
+The Ring Accelerator (RA) is a machine which converts read/write accesses
+from/to a constant address into corresponding read/write accesses from/to a
+circular data structure in memory. The RA eliminates the need for each DMA
+controller which needs to access ring elements from having to know the current
+state of the ring (base address, current offset). The DMA controller
+performs a read or write access to a specific address range (which maps to the
+source interface on the RA) and the RA replaces the address for the transaction
+with a new address which corresponds to the head or tail element of the ring
+(head for reads, tail for writes).
+
+The Ring Accelerator is a hardware module that is responsible for accelerating
+management of the packet queues. The K3 SoCs can have more than one RA 
instances
+
+Required properties:
+- compatible   : Must be "ti,am654-navss-ringacc";
+- reg  : Should contain register location and length of the following
+ named register regions.
+- reg-names: should be
+ "rt" - The RA Ring Real-time Control/Status Registers
+ "fifos" - The RA Queues Registers
+ "proxy_gcfg" - The RA Proxy Global Config Registers
+ "proxy_target" - The RA Proxy Datapath Registers
+- ti,num-rings : Number of rings supported by RA
+- ti,sci-rm-range-gp-rings : TI-SCI RM subtype for GP ring range
+- ti,sci   : phandle on TI-SCI compatible System controller node
+- ti,sci-dev-id: TI-SCI device id
+- msi-parent   : phandle for "ti,sci-inta" interrupt controller
+
+Optional properties:
+ -- ti,dma-ring-reset-quirk : enable ringacc / udma ring state interoperability
+ issue software w/a
+
+Example:
+
+ringacc: ringacc@3c00 {
+   compatible = "ti,am654-navss-ringacc";
+   reg =   <0x0 0x3c00 0x0 0x40>,
+   <0x0 0x3800 0x0 0x40>,
+   <0x0 0x3112 0x0 0x100>,
+   <0x0 0x3300 0x0 0x4>;
+   reg-names = "rt", "fifos",
+   "proxy_gcfg", "proxy_target";
+   ti,num-rings = <818>;
+   ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
+   ti,dma-ring-reset-quirk;
+   ti,sci = <&dmsc>;
+   ti,sci-dev-id = <187>;
+   msi-parent = <&inta_main_udmass>;
+};
+
+client:
+
+dma_ipx: dma_ipx@ {
+   ...
+   ti,ringacc = <&ringacc>;
+   ...
+}
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH v3 08/14] dmaengine: ti: New driver for K3 UDMA - split#1: defines, structs, io func

[Peter Ujfalusi]

Split patch for review containing: defines, structs, io and low level
functions and interrupt callbacks.

DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)

The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types. The UDMA-P is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.

The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.

The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti/k3-udma.c | 1059 ++
 drivers/dma/ti/k3-udma.h |  130 +
 2 files changed, 1189 insertions(+)
 create mode 100644 drivers/dma/ti/k3-udma.c
 create mode 100644 drivers/dma/ti/k3-udma.h

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
new file mode 100644
index ..628120fffa2f
--- /dev/null
+++ b/drivers/dma/ti/k3-udma.c
@@ -0,0 +1,1059 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../virt-dma.h"
+#include "k3-udma.h"
+
+struct udma_static_tr {
+   u8 elsize; /* RPSTR0 */
+   u16 elcnt; /* RPSTR0 */
+   u16 bstcnt; /* RPSTR1 */
+};
+
+#define K3_UDMA_MAX_RFLOWS 1024
+#define K3_UDMA_DEFAULT_RING_SIZE  16
+
+struct udma_chan;
+
+enum udma_mmr {
+   MMR_GCFG = 0,
+   MMR_RCHANRT,
+   MMR_TCHANRT,
+   MMR_LAST,
+};
+
+static const char * const mmr_names[] = { "gcfg", "rchanrt", "tchanrt" };
+
+struct udma_tchan {
+   void __iomem *reg_rt;
+
+   int id;
+   struct k3_ring *t_ring; /* Transmit ring */
+   struct k3_ring *tc_ring; /* Transmit Completion ring */
+};
+
+struct udma_rchan {
+   void __iomem *reg_rt;
+
+   int id;
+   struct k3_ring *fd_ring; /* Free Descriptor ring */
+   struct k3_ring *r_ring; /* Receive ring*/
+};
+
+struct udma_rflow {
+   void __iomem *reg_rflow;
+
+   int id;
+};
+
+struct udma_tr_thread_ranges {
+   int start;
+   int count;
+};
+
+struct udma_match_data {
+   bool enable_memcpy_support;
+   bool have_acc32;
+   bool have_burst;
+   u32 statictr_z_mask;
+   u32 rchan_oes_offset;
+
+   struct udma_tr_thread_ranges *tr_threads;
+
+   u8 tpl_levels;
+   u32 level_start_idx[];
+};
+
+struct udma_dev {
+   struct dma_device ddev;
+   struct device *dev;
+   void __iomem *mmrs[MMR_LAST];
+   const struct udma_match_data *match_data;
+
+   size_t desc_align; /* alignment to use for descriptors */
+
+   struct udma_tisci_rm tisci_rm;
+
+   struct k3_ringacc *ringacc;
+
+   struct work_struct purge_work;
+   struct list_head desc_to_purge;
+   spinlock_t lock;
+
+   int tchan_cnt;
+   int echan_cnt;
+   int rchan_cnt;
+   int rflow_cnt;
+   unsigned long *tchan_map;
+   unsigned long *rchan_map;
+   unsigned long *rflow_gp_map;
+   unsigned long *rflow_gp_map_allocated;
+   unsigned long *rflow_in_use;
+
+   struct udma_tchan *tchans;
+   struct udma_rchan *rchans;
+   struct udma_rflow *rflows;
+
+   struct udma_chan *channels;
+   u32 psil_base;
+};
+
+struct udma_hwdesc {
+   size_t cppi5_desc_size;
+   void *cppi5_desc_vaddr;
+   dma_addr_t cppi5_desc_paddr;
+
+   /* TR descriptor internal pointers */
+   void *tr_req_base;
+   struct cppi5_tr_resp_t *tr_resp_base;
+};
+
+struct udma_desc {
+   struct vi

[PATCH v3 06/14] dmaengine: ti: Add cppi5 header for UDMA

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi 
---
 include/linux/dma/ti-cppi5.h | 1049 ++
 1 file changed, 1049 insertions(+)
 create mode 100644 include/linux/dma/ti-cppi5.h

diff --git a/include/linux/dma/ti-cppi5.h b/include/linux/dma/ti-cppi5.h
new file mode 100644
index ..f795f8cb7cc5
--- /dev/null
+++ b/include/linux/dma/ti-cppi5.h
@@ -0,0 +1,1049 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * CPPI5 descriptors interface
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ */
+
+#ifndef __TI_CPPI5_H__
+#define __TI_CPPI5_H__
+
+#include 
+#include 
+#include 
+
+/**
+ * struct cppi5_desc_hdr_t - Descriptor header, present in all types of
+ *  descriptors
+ * @pkt_info0: Packet info word 0 (n/a in Buffer desc)
+ * @pkt_info0: Packet info word 1 (n/a in Buffer desc)
+ * @pkt_info0: Packet info word 2 (n/a in Buffer desc)
+ * @src_dst_tag:   Packet info word 3 (n/a in Buffer desc)
+ */
+struct cppi5_desc_hdr_t {
+   u32 pkt_info0;
+   u32 pkt_info1;
+   u32 pkt_info2;
+   u32 src_dst_tag;
+} __packed;
+
+/**
+ * struct cppi5_host_desc_t - Host-mode packet and buffer descriptor definition
+ * @hdr:   Descriptor header
+ * @next_desc: word 4/5: Linking word
+ * @buf_ptr:   word 6/7: Buffer pointer
+ * @buf_info1: word 8: Buffer valid data length
+ * @org_buf_len:   word 9: Original buffer length
+ * @org_buf_ptr:   word 10/11: Original buffer pointer
+ * @epib[0]:   Extended Packet Info Data (optional, 4 words), and/or
+ * Protocol Specific Data (optional, 0-128 bytes in
+ * multiples of 4), and/or
+ * Other Software Data (0-N bytes, optional)
+ */
+struct cppi5_host_desc_t {
+   struct cppi5_desc_hdr_t hdr;
+   u64 next_desc;
+   u64 buf_ptr;
+   u32 buf_info1;
+   u32 org_buf_len;
+   u64 org_buf_ptr;
+   u32 epib[0];
+} __packed;
+
+#define CPPI5_DESC_MIN_ALIGN   (16U)
+
+#define CPPI5_INFO0_HDESC_EPIB_SIZE(16U)
+#define CPPI5_INFO0_HDESC_PSDATA_MAX_SIZE  (128U)
+
+#define CPPI5_INFO0_HDESC_TYPE_SHIFT   (30U)
+#define CPPI5_INFO0_HDESC_TYPE_MASKGENMASK(31, 30)
+#define   CPPI5_INFO0_DESC_TYPE_VAL_HOST   (1U)
+#define   CPPI5_INFO0_DESC_TYPE_VAL_MONO   (2U)
+#define   CPPI5_INFO0_DESC_TYPE_VAL_TR (3U)
+#define CPPI5_INFO0_HDESC_EPIB_PRESENT BIT(29)
+/*
+ * Protocol Specific Words location:
+ * 0 - located in the descriptor,
+ * 1 = located in the SOP Buffer immediately prior to the data.
+ */
+#define CPPI5_INFO0_HDESC_PSINFO_LOCATION  BIT(28)
+#define CPPI5_INFO0_HDESC_PSINFO_SIZE_SHIFT(22U)
+#define CPPI5_INFO0_HDESC_PSINFO_SIZE_MASK GENMASK(27, 22)
+#define CPPI5_INFO0_HDESC_PKTLEN_SHIFT (0)
+#define CPPI5_INFO0_HDESC_PKTLEN_MASK  GENMASK(21, 0)
+
+#define CPPI5_INFO1_DESC_PKTERROR_SHIFT(28U)
+#define CPPI5_INFO1_DESC_PKTERROR_MASK GENMASK(31, 28)
+#define CPPI5_INFO1_HDESC_PSFLGS_SHIFT (24U)
+#define CPPI5_INFO1_HDESC_PSFLGS_MASK  GENMASK(27, 24)
+#define CPPI5_INFO1_DESC_PKTID_SHIFT   (14U)
+#define CPPI5_INFO1_DESC_PKTID_MASKGENMASK(23, 14)
+#define CPPI5_INFO1_DESC_FLOWID_SHIFT  (0)
+#define CPPI5_INFO1_DESC_FLOWID_MASK   GENMASK(13, 0)
+
+#define CPPI5_INFO2_HDESC_PKTTYPE_SHIFT(27U)
+#define CPPI5_INFO2_HDESC_PKTTYPE_MASK GENMASK(31, 27)
+/* Return Policy: 0 - Entire packet 1 - Each buffer */
+#define CPPI5_INFO2_HDESC_RETPOLICYBIT(18)
+/*
+ * Early Return:
+ * 0 = desc pointers should be returned after all reads have been completed
+ * 1 = desc pointers should be returned immediately upon fetching
+ * the descriptor and beginning to transfer data.
+ */
+#define CPPI5_INFO2_HDESC_EARLYRET BIT(17)
+/*
+ * Return Push Policy:
+ * 0 = Descriptor must be returned to tail of queue
+ * 1 = Descriptor must be returned to head of queue
+ */
+#define CPPI5_INFO2_DESC_RETPUSHPOLICY BIT(16)
+#define CPPI5_INFO2_DESC_RETQ_SHIFT(0)
+#define CPPI5_INFO2_DESC_RETQ_MASK GENMASK(15, 0)
+
+#define CPPI5_INFO3_DESC_SRCTAG_SHIFT  (16U)
+#define CPPI5_INFO3_DESC_SRCTAG_MASK   GENMASK(31, 16)
+#define CPPI5_INFO3_DESC_DSTTAG_SHIFT  (0)
+#define CPPI5_INFO3_DESC_DSTTAG_MASK   GENMASK(15, 0)
+
+#define CPPI5_BUFINFO1_HDESC_DATA_LEN_SHIFT(0)
+#define CPPI5_BUFINFO1_HDESC_DATA_LEN_MASK GENMASK(27, 0)
+
+#define CPPI5_OBUFINFO0_HDESC_BUF_LEN_SHIFT(0)
+#define CPPI5_OBUFINFO0_HDESC_BUF_LEN_MASK GENMASK(27, 0)
+
+/**
+ * struct cppi5_desc_epib_t - Host Packet Descriptor Extended Packet Info Block
+ * @timestamp: word 0: application specific timestamp
+ * @sw_info0:  word 1: Software Info 0
+ * @sw_info1:  word 1: Software Info 1
+ * @s

[PATCH v3 07/14] dt-bindings: dma: ti: Add document for K3 UDMA

[Peter Ujfalusi]

New binding document for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P).

UDMA-P is introduced as part of the K3 architecture and can be found in
AM654 and j721e.

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/dma/ti/k3-udma.txt| 185 ++
 include/dt-bindings/dma/k3-udma.h |  10 +
 2 files changed, 195 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-udma.txt
 create mode 100644 include/dt-bindings/dma/k3-udma.h

diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.txt 
b/Documentation/devicetree/bindings/dma/ti/k3-udma.txt
new file mode 100644
index ..3a8816ec9ce0
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.txt
@@ -0,0 +1,185 @@
+* Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)
+
+The UDMA-P is intended to perform similar (but significantly upgraded) 
functions
+as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
+supports the transmission and reception of various packet types. The UDMA-P is
+architected to facilitate the segmentation and reassembly of SoC DMA data
+structure compliant packets to/from smaller data blocks that are natively
+compatible with the specific requirements of each connected peripheral. 
Multiple
+Tx and Rx channels are provided within the DMA which allow multiple 
segmentation
+or reassembly operations to be ongoing. The DMA controller maintains state
+information for each of the channels which allows packet segmentation and
+reassembly operations to be time division multiplexed between channels in order
+to share the underlying DMA hardware. An external DMA scheduler is used to
+control the ordering and rate at which this multiplexing occurs for Transmit
+operations. The ordering and rate of Receive operations is indirectly 
controlled
+by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.
+
+The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
+channels. Channels in the UDMA-P can be configured to be either Packet-Based or
+Third-Party channels on a channel by channel basis.
+
+All transfers within NAVSS is done between PSI-L source and destination 
threads.
+The peripherals serviced by UDMA can be PSI-L native (sa2ul, cpsw, etc) or
+legacy, non PSI-L native peripherals. In the later case a special, small PDMA 
is
+tasked to act as a bridge between the PSI-L fabric and the legacy peripheral.
+
+PDMAs can be configured via UDMAP peer registers to match with the 
configuration
+of the legacy peripheral.
+
+Required properties:
+
+- compatible:  Should be
+   "ti,am654-navss-main-udmap" for am654 main NAVSS UDMAP
+   "ti,am654-navss-mcu-udmap" for am654 mcu NAVSS UDMAP
+   "ti,j721e-navss-main-udmap" for j721e main NAVSS UDMAP
+   "ti,j721e-navss-mcu-udmap" for j721e mcu NAVSS UDMAP
+- #dma-cells:  Should be set to <3>.
+   - The first parameter is a phandle to the remote PSI-L
+ endpoint
+   - The second parameter is the thread offset within the
+ remote thread ID range
+   - The third parameter is the channel direction.
+- reg: Memory map of UDMAP
+- reg-names:   "gcfg", "rchanrt", "tchanrt"
+- msi-parent:  phandle for "ti,sci-inta" interrupt controller
+- ti,ringacc:  phandle for the ring accelerator node
+- ti,psil-base:PSI-L thread ID base of the UDMAP channels
+- ti,sci:  phandle on TI-SCI compatible System controller node
+- ti,sci-dev-id:   TI-SCI device id
+- ti,sci-rm-range-tchan: UDMA tchan resource list in pairs of type and subtype
+- ti,sci-rm-range-rchan: UDMA rchan resource list in pairs of type and subtype
+- ti,sci-rm-range-rflow: UDMA rflow resource list in pairs of type and subtype
+
+For PSI-L thread management the parent NAVSS node must have:
+- ti,sci:  phandle on TI-SCI compatible System controller node
+- ti,sci-dev-id:   TI-SCI device id of the NAVSS instance
+
+Remote PSI-L endpoint
+
+Required properties:
+
+- ti,psil-base:PSI-L thread ID base of the endpoint
+
+Within the PSI-L endpoint node thread configuration subnodes must present with:
+psil-configX naming convention, where X is the thread ID offset.
+
+Configuration node Optional properties:
+
+- ti,pdma-statictr-type:In case the remote endpoint (PDMAs) requires StaticTR
+   configuration:
+   - PSIL_STATIC_TR_XY (1): XY type of StaticTR
+   For endpoints without StaticTR the property is not
+   needed or to be set PSIL_STATIC_TR_NONE (0).
+- ti,pdma-enable-acc32:Force 32 bit access on peripheral port. Only 
valid

[PATCH v3 03/14] dmaengine: doc: Add sections for per descriptor metadata support

[Peter Ujfalusi]

Update the provider and client documentation with details about the
metadata support.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/driver-api/dmaengine/client.rst | 75 +++
 .../driver-api/dmaengine/provider.rst | 46 
 2 files changed, 121 insertions(+)

diff --git a/Documentation/driver-api/dmaengine/client.rst 
b/Documentation/driver-api/dmaengine/client.rst
index 45953f171500..d708e46b88a2 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -151,6 +151,81 @@ The details of these operations are:
  Note that callbacks will always be invoked from the DMA
  engines tasklet, never from interrupt context.
 
+  Optional: per descriptor metadata
+  -
+  DMAengine provides two ways for metadata support.
+
+  DESC_METADATA_CLIENT
+
+The metadata buffer is allocated/provided by the client driver and it is
+attached to the descriptor.
+
+  .. code-block:: c
+
+ int dmaengine_desc_attach_metadata(struct dma_async_tx_descriptor *desc,
+  void *data, size_t len);
+
+  DESC_METADATA_ENGINE
+
+The metadata buffer is allocated/managed by the DMA driver. The client
+driver can ask for the pointer, maximum size and the currently used size of
+the metadata and can directly update or read it.
+
+  .. code-block:: c
+
+ void *dmaengine_desc_get_metadata_ptr(struct dma_async_tx_descriptor 
*desc,
+   size_t *payload_len, size_t *max_len);
+
+ int dmaengine_desc_set_metadata_len(struct dma_async_tx_descriptor *desc,
+   size_t payload_len);
+
+  Client drivers can query if a given mode is supported with:
+
+  .. code-block:: c
+
+ bool dmaengine_is_metadata_mode_supported(struct dma_chan *chan,
+   enum dma_desc_metadata_mode mode);
+
+  Depending on the used mode client drivers must follow different flow.
+
+  DESC_METADATA_CLIENT
+
+- DMA_MEM_TO_DEV / DEV_MEM_TO_MEM:
+  1. prepare the descriptor (dmaengine_prep_*)
+ construct the metadata in the client's buffer
+  2. use dmaengine_desc_attach_metadata() to attach the buffer to the
+ descriptor
+  3. submit the transfer
+- DMA_DEV_TO_MEM:
+  1. prepare the descriptor (dmaengine_prep_*)
+  2. use dmaengine_desc_attach_metadata() to attach the buffer to the
+ descriptor
+  3. submit the transfer
+  4. when the transfer is completed, the metadata should be available in 
the
+ attached buffer
+
+  DESC_METADATA_ENGINE
+
+- DMA_MEM_TO_DEV / DEV_MEM_TO_MEM:
+  1. prepare the descriptor (dmaengine_prep_*)
+  2. use dmaengine_desc_get_metadata_ptr() to get the pointer to the
+ engine's metadata area
+  3. update the metadata at the pointer
+  4. use dmaengine_desc_set_metadata_len()  to tell the DMA engine the
+ amount of data the client has placed into the metadata buffer
+  5. submit the transfer
+- DMA_DEV_TO_MEM:
+  1. prepare the descriptor (dmaengine_prep_*)
+  2. submit the transfer
+  3. on transfer completion, use dmaengine_desc_get_metadata_ptr() to get 
the
+ pointer to the engine's metadata are
+  4. Read out the metadate from the pointer
+
+  .. note::
+
+ Mixed use of DESC_METADATA_CLIENT / DESC_METADATA_ENGINE is not allowed,
+ client drivers must use either of the modes per descriptor.
+
 4. Submit the transaction
 
Once the descriptor has been prepared and the callback information
diff --git a/Documentation/driver-api/dmaengine/provider.rst 
b/Documentation/driver-api/dmaengine/provider.rst
index dfc4486b5743..9e6d87b3c477 100644
--- a/Documentation/driver-api/dmaengine/provider.rst
+++ b/Documentation/driver-api/dmaengine/provider.rst
@@ -247,6 +247,52 @@ after each transfer. In case of a ring buffer, they may 
loop
 (DMA_CYCLIC). Addresses pointing to a device's register (e.g. a FIFO)
 are typically fixed.
 
+Per descriptor metadata support
+---
+Some data movement architecure (DMA controller and peripherals) uses metadata
+associated with a transaction. The DMA controller role is to transfer the
+payload and the metadata alongside.
+The metadata itself is not used by the DMA engine itself, but it contains
+parameters, keys, vectors, etc for peripheral or from the peripheral.
+
+The DMAengine framework provides a generic ways to facilitate the metadata for
+descriptors. Depending on the architecture the DMA driver can implement either
+or both of the methods and it is up to the client driver to choose which one
+to use.
+
+- DESC_METADATA_CLIENT
+
+  The metadata buffer is allocated/provided by the client driver and it is
+  attached (via the dmaengine_desc_attach_metadata() helper to the descriptor.
+
+  From the DMA driver the following is expected for this mode:
+  - DMA_MEM_TO_DEV / DEV_MEM_TO_MEM
+The data from the provided metadata buffer sh

[PATCH v3 00/14] dmaengine/soc: Add Texas Instruments UDMA support

[Peter Ujfalusi]

Hi,

Changes since v2
)https://patchwork.kernel.org/project/linux-dmaengine/list/?series=152609&state=*)
- Based on 5.4-rc1
- Support for Flow only data transfer for the glue layer

- cppi5 header
 - comments converted to kernel-doc style
 - Remove the excessive WARN_ONs and rely on the user for sanity
 - new macro for checking TearDown Completion Message

- ring accelerator driver
 - fixed up th commit message (SoB, TI-SCI)
 - fixed ring reset
 - CONFIG_TI_K3_RINGACC_DEBUG is removed along with the dbg_write/read functions
   and use dev_dbg()
 - k3_ringacc_ring_dump() is moved to static
 - step numbering removed from k3_ringacc_ring_reset_dma()
 - Add clarification comment for shared ring usage in k3_ringacc_ring_cfg()
 - Magic shift values in k3_ringacc_ring_cfg_proxy() got defined
 - K3_RINGACC_RING_MODE_QM is removed as it is not supported

- UDMAP DT bindings
 - Fix property prefixing: s/pdma,/ti,pdma-
 - Add ti,notdpkt property to suppress teardown completion message on tchan
 - example updated accordingly

- UDMAP DMAengine driver
 - Change __raw_readl/writel to readl/writel
 - Split up the udma_tisci_channel_config() into m2m, tx and rx tisci
   configuration functions for clarity
 - DT bindings change: s/pdma,/ti,pdma-
 - Cleanup of udma_tx_status():
  - residue calculation fix for m2m
  - no need to read packet counter as it is not used
  - peer byte counter only available in PDMAs
  - Proper locking to avoid race with interrupt handler (polled m2m fix)
 - Support for ti,notdpkt
 - RFLOW management rework to support data movement without channel:
  - the channel is not controlled by Linux but other core and we only have
rflows and rings to do the DMA transfers.
This mode is only supported by the Glue layer for now.

- UDMAP glue layer
 - Debug print improvements
 - Support for rflow/ring only data movement

Changes since v1
(https://patchwork.kernel.org/project/linux-dmaengine/list/?series=114105&state=*)
- Added support for j721e
- Based on 5.3-rc2
- dropped ti_sci API patch for RM management as it is already upstream
- dropped dmadev_get_slave_channel() patch, using __dma_request_channel()
- Added Rob's Reviewed-by to ringacc DT binding document patch
- DT bindings changes:
 - linux,udma-mode is gone, I have a simple lookup table in the driver to flag
   TR channels.
 - Support for j721e
- Fix bug in of_node_put() handling in xlate function

Changes since RFC (https://patchwork.kernel.org/cover/10612465/):
- Based on linux-next (20190506) which now have the ti_sci interrupt support
- The series can be applied and the UDMA via DMAengine API will be functional
- Included in the series: ti_sci Resource management API, cppi5 header and
  driver for the ring accelerator.
- The DMAengine core patches have been updated as per the review comments for
  earlier submittion.
- The DMAengine driver patch is artificially split up to 6 smaller patches

The k3-udma driver implements the Data Movement Architecture described in
AM65x TRM (http://www.ti.com/lit/pdf/spruid7) and
j721e TRM (http://www.ti.com/lit/pdf/spruil1)

This DMA architecture is a big departure from 'traditional' architecture where
we had either EDMA or sDMA as system DMA.

Packet DMAs were used as dedicated DMAs to service only networking (Kesytone2)
or USB (am335x) while other peripherals were serviced by EDMA.

In AM65x/j721e the UDMA (Unified DMA) is used for all data movment within the
SoC, tasked to service all peripherals (UART, McSPI, McASP, networking, etc). 

The NAVSS/UDMA is built around CPPI5 (Communications Port Programming Interface)
and it supports Packet mode (similar to CPPI4.1 in Keystone2 for networking) and
TR mode (similar to EDMA descriptor).
The data movement is done within a PSI-L fabric, peripherals (including the
UDMA-P) are not addressed by their I/O register as with traditional DMAs but
with their PSI-L thread ID.

In AM65x/j721e we have two main type of peripherals:
Legacy: McASP, McSPI, UART, etc.
 to provide connectivity they are serviced by PDMA (Peripheral DMA)
 PDMA threads are locked to service a given peripheral, for example PSI-L thread
 0x4400/0xc400 is to service McASP0 rx/tx.
 The PDMa configuration can be done via the UDMA Real Time Peer registers.
Native: Networking, security accelerator
 these peripherals have native support for PSI-L.

To be able to use the DMA the following generic steps need to be taken:
- configure a DMA channel (tchan for TX, rchan for RX)
 - channel mode: Packet or TR mode
 - for memcpy a tchan and rchan pair is used.
 - for packet mode RX we also need to configure a receive flow to configure the
   packet receiption
- the source and destination threads must be paired
- at minimum one pair of rings need to be configured:
 - tx: transfer ring and transfer completion ring
 - rx: free descriptor ring and receive ring
- two interrupts: UDMA-P channel interrupt and ring interrupt for tc_ring/r_ring
 - If the channel is in packet mode or configured to memcpy then we only ne

Re: [PATCH v2] virt: vbox: fix memory leak in hgcm_call_preprocess_linaddr

[Hans de Goede]

Hi,

On 30-09-2019 22:42, Navid Emamdoost wrote:

In hgcm_call_preprocess_linaddr memory is allocated for bounce_buf but
is not released if copy_form_user fails. In order to prevent memory leak
in case of failure, the assignment to bounce_buf_ret is moved before the
error check. This way the allocated bounce_buf will be released by the
caller.

Fixes: 579db9d45cb4 ("virt: Add vboxguest VMMDEV communication code")
Signed-off-by: Navid Emamdoost 


Thank you.

Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




---
  drivers/virt/vboxguest/vboxguest_utils.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/vboxguest/vboxguest_utils.c 
b/drivers/virt/vboxguest/vboxguest_utils.c
index 75fd140b02ff..43c391626a00 100644
--- a/drivers/virt/vboxguest/vboxguest_utils.c
+++ b/drivers/virt/vboxguest/vboxguest_utils.c
@@ -220,6 +220,8 @@ static int hgcm_call_preprocess_linaddr(
if (!bounce_buf)
return -ENOMEM;
  
+	*bounce_buf_ret = bounce_buf;

+
if (copy_in) {
ret = copy_from_user(bounce_buf, (void __user *)buf, len);
if (ret)
@@ -228,7 +230,6 @@ static int hgcm_call_preprocess_linaddr(
memset(bounce_buf, 0, len);
}
  
-	*bounce_buf_ret = bounce_buf;

hgcm_call_add_pagelist_size(bounce_buf, len, extra);
return 0;
  }

[PATCH v2 0/3] net: phy: at803x: add ar9331 support

[Oleksij Rempel]

changes v2:
- use PHY_ID_MATCH_EXACT instead of leaky masking
- remove probe and struct at803x_priv

Oleksij Rempel (3):
  net: phy: at803x: use PHY_ID_MATCH_EXACT for IDs
  net: phy: at803x: add ar9331 support
  net: phy: at803x: remove probe and struct at803x_priv

 drivers/net/phy/at803x.c | 45 ++--
 1 file changed, 15 insertions(+), 30 deletions(-)

-- 
2.23.0

[PATCH v2 1/3] net: phy: at803x: use PHY_ID_MATCH_EXACT for IDs

[Oleksij Rempel]

Use exact match for all IDs. We have no sanity checks, so we can peek
a device with no exact ID and different register layout.

Suggested-by: Heiner Kallweit 
Signed-off-by: Oleksij Rempel 
---
 drivers/net/phy/at803x.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 6ad8b1c63c34..7895dbe600ac 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -364,9 +364,8 @@ static int at803x_aneg_done(struct phy_device *phydev)
 static struct phy_driver at803x_driver[] = {
 {
/* ATHEROS 8035 */
-   .phy_id = ATH8035_PHY_ID,
+   PHY_ID_MATCH_EXACT(ATH8035_PHY_ID),
.name   = "Atheros 8035 ethernet",
-   .phy_id_mask= AT803X_PHY_ID_MASK,
.probe  = at803x_probe,
.config_init= at803x_config_init,
.set_wol= at803x_set_wol,
@@ -378,9 +377,8 @@ static struct phy_driver at803x_driver[] = {
.config_intr= at803x_config_intr,
 }, {
/* ATHEROS 8030 */
-   .phy_id = ATH8030_PHY_ID,
+   PHY_ID_MATCH_EXACT(ATH8030_PHY_ID),
.name   = "Atheros 8030 ethernet",
-   .phy_id_mask= AT803X_PHY_ID_MASK,
.probe  = at803x_probe,
.config_init= at803x_config_init,
.link_change_notify = at803x_link_change_notify,
@@ -393,9 +391,8 @@ static struct phy_driver at803x_driver[] = {
.config_intr= at803x_config_intr,
 }, {
/* ATHEROS 8031 */
-   .phy_id = ATH8031_PHY_ID,
+   PHY_ID_MATCH_EXACT(ATH8031_PHY_ID),
.name   = "Atheros 8031 ethernet",
-   .phy_id_mask= AT803X_PHY_ID_MASK,
.probe  = at803x_probe,
.config_init= at803x_config_init,
.set_wol= at803x_set_wol,
@@ -411,9 +408,7 @@ static struct phy_driver at803x_driver[] = {
 module_phy_driver(at803x_driver);
 
 static struct mdio_device_id __maybe_unused atheros_tbl[] = {
-   { ATH8030_PHY_ID, AT803X_PHY_ID_MASK },
-   { ATH8031_PHY_ID, AT803X_PHY_ID_MASK },
-   { ATH8035_PHY_ID, AT803X_PHY_ID_MASK },
+   { PHY_ID_MATCH_VENDOR(ATH8030_PHY_ID) },
{ }
 };
 
-- 
2.23.0

[PATCH v2 2/3] net: phy: at803x: add ar9331 support

[Oleksij Rempel]

Mostly this hardware can work with generic PHY driver, but this change
is needed to provided interrupt handling support.
Tested with dsa ar9331-switch driver.

Signed-off-by: Oleksij Rempel 
---
 drivers/net/phy/at803x.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 7895dbe600ac..42492f83c8d7 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -53,6 +53,7 @@
 #define AT803X_DEBUG_REG_5 0x05
 #define AT803X_DEBUG_TX_CLK_DLY_EN BIT(8)
 
+#define ATH9331_PHY_ID 0x004dd041
 #define ATH8030_PHY_ID 0x004dd076
 #define ATH8031_PHY_ID 0x004dd074
 #define ATH8035_PHY_ID 0x004dd072
@@ -403,6 +404,16 @@ static struct phy_driver at803x_driver[] = {
.aneg_done  = at803x_aneg_done,
.ack_interrupt  = &at803x_ack_interrupt,
.config_intr= &at803x_config_intr,
+}, {
+   /* ATHEROS AR9331 */
+   PHY_ID_MATCH_EXACT(ATH9331_PHY_ID),
+   .name   = "Atheros AR9331 built-in PHY",
+   .config_init= at803x_config_init,
+   .suspend= at803x_suspend,
+   .resume = at803x_resume,
+   /* PHY_BASIC_FEATURES */
+   .ack_interrupt  = &at803x_ack_interrupt,
+   .config_intr= &at803x_config_intr,
 } };
 
 module_phy_driver(at803x_driver);
-- 
2.23.0

[PATCH v2 3/3] net: phy: at803x: remove probe and struct at803x_priv

[Oleksij Rempel]

struct at803x_priv is never used in this driver. So remove it
and the probe function allocating it.

Suggested-by: Heiner Kallweit 
Signed-off-by: Oleksij Rempel 
---
 drivers/net/phy/at803x.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 42492f83c8d7..e64f77e152f4 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -63,10 +63,6 @@ MODULE_DESCRIPTION("Atheros 803x PHY driver");
 MODULE_AUTHOR("Matus Ujhelyi");
 MODULE_LICENSE("GPL");
 
-struct at803x_priv {
-   bool phy_reset:1;
-};
-
 struct at803x_context {
u16 bmcr;
u16 advertise;
@@ -232,20 +228,6 @@ static int at803x_resume(struct phy_device *phydev)
return phy_modify(phydev, MII_BMCR, BMCR_PDOWN | BMCR_ISOLATE, 0);
 }
 
-static int at803x_probe(struct phy_device *phydev)
-{
-   struct device *dev = &phydev->mdio.dev;
-   struct at803x_priv *priv;
-
-   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-   if (!priv)
-   return -ENOMEM;
-
-   phydev->priv = priv;
-
-   return 0;
-}
-
 static int at803x_config_init(struct phy_device *phydev)
 {
int ret;
@@ -367,7 +349,6 @@ static struct phy_driver at803x_driver[] = {
/* ATHEROS 8035 */
PHY_ID_MATCH_EXACT(ATH8035_PHY_ID),
.name   = "Atheros 8035 ethernet",
-   .probe  = at803x_probe,
.config_init= at803x_config_init,
.set_wol= at803x_set_wol,
.get_wol= at803x_get_wol,
@@ -380,7 +361,6 @@ static struct phy_driver at803x_driver[] = {
/* ATHEROS 8030 */
PHY_ID_MATCH_EXACT(ATH8030_PHY_ID),
.name   = "Atheros 8030 ethernet",
-   .probe  = at803x_probe,
.config_init= at803x_config_init,
.link_change_notify = at803x_link_change_notify,
.set_wol= at803x_set_wol,
@@ -394,7 +374,6 @@ static struct phy_driver at803x_driver[] = {
/* ATHEROS 8031 */
PHY_ID_MATCH_EXACT(ATH8031_PHY_ID),
.name   = "Atheros 8031 ethernet",
-   .probe  = at803x_probe,
.config_init= at803x_config_init,
.set_wol= at803x_set_wol,
.get_wol= at803x_get_wol,
-- 
2.23.0

Re: [Patch v5 4/8] media: i2c: ov2659: fix s_stream return value

[Lad, Prabhakar]

On Mon, Sep 30, 2019 at 2:07 PM Benoit Parrot  wrote:
>
> In ov2659_s_stream() return value for invoked function should be checked
> and propagated.
>
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/i2c/ov2659.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
Acked-by: Lad, Prabhakar 

Cheers,
--Prabhakar Lad

> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> index f77320e8a60d..da181a13cf44 100644
> --- a/drivers/media/i2c/ov2659.c
> +++ b/drivers/media/i2c/ov2659.c
> @@ -1187,11 +1187,15 @@ static int ov2659_s_stream(struct v4l2_subdev *sd, 
> int on)
> goto unlock;
> }
>
> -   ov2659_set_pixel_clock(ov2659);
> -   ov2659_set_frame_size(ov2659);
> -   ov2659_set_format(ov2659);
> -   ov2659_set_streaming(ov2659, 1);
> -   ov2659->streaming = on;
> +   ret = ov2659_set_pixel_clock(ov2659);
> +   if (!ret)
> +   ret = ov2659_set_frame_size(ov2659);
> +   if (!ret)
> +   ret = ov2659_set_format(ov2659);
> +   if (!ret) {
> +   ov2659_set_streaming(ov2659, 1);
> +   ov2659->streaming = on;
> +   }
>
>  unlock:
> mutex_unlock(&ov2659->lock);
> --
> 2.17.1
>

Re: [Patch v5 6/8] media: i2c: ov2659: Add powerdown/reset gpio handling

[Lad, Prabhakar]

On Mon, Sep 30, 2019 at 2:07 PM Benoit Parrot  wrote:
>
> On some board it is possible that the sensor 'powerdown' and or 'reset'
> pin might be controlled by gpio instead of being tied.
>
> To implement we add pm_runtime support which will handle the power
> up/down sequence when it is available otherwise the sensor will be
> powered on at module insertion/probe and powered off at module removal.
>
> Now originally the driver assumed that the sensor would always stay
> powered and keep its register setting. We cannot assume this anymore, so
> every time we "power up" we need to re-program the initial registers
> configuration first. This was previously done only at probe time.
>
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/i2c/Kconfig  |  2 +-
>  drivers/media/i2c/ov2659.c | 86 +-
>  2 files changed, 85 insertions(+), 3 deletions(-)
>

Acked-by: Lad, Prabhakar 

Cheers,
--Prabhakar Lad

> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 7eee1812bba3..315c1d8bdb7b 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -634,7 +634,7 @@ config VIDEO_OV2640
>  config VIDEO_OV2659
> tristate "OmniVision OV2659 sensor support"
> depends on VIDEO_V4L2 && I2C
> -   depends on MEDIA_CAMERA_SUPPORT
> +   depends on MEDIA_CAMERA_SUPPORT && GPIOLIB
> select V4L2_FWNODE
> help
>   This is a Video4Linux2 sensor driver for the OmniVision
> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> index da181a13cf44..80de2e35aeca 100644
> --- a/drivers/media/i2c/ov2659.c
> +++ b/drivers/media/i2c/ov2659.c
> @@ -22,9 +22,11 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -218,6 +220,10 @@ struct ov2659 {
> struct sensor_register *format_ctrl_regs;
> struct ov2659_pll_ctrl pll;
> int streaming;
> +   /* used to control the sensor PWDN pin */
> +   struct gpio_desc *pwdn_gpio;
> +   /* used to control the sensor RESETB pin */
> +   struct gpio_desc *resetb_gpio;
>  };
>
>  static const struct sensor_register ov2659_init_regs[] = {
> @@ -1184,10 +1190,19 @@ static int ov2659_s_stream(struct v4l2_subdev *sd, 
> int on)
> /* Stop Streaming Sequence */
> ov2659_set_streaming(ov2659, 0);
> ov2659->streaming = on;
> +   pm_runtime_put(&client->dev);
> goto unlock;
> }
>
> -   ret = ov2659_set_pixel_clock(ov2659);
> +   ret = pm_runtime_get_sync(&client->dev);
> +   if (ret < 0) {
> +   pm_runtime_put_noidle(&client->dev);
> +   goto unlock;
> +   }
> +
> +   ret = ov2659_init(sd, 0);
> +   if (!ret)
> +   ret = ov2659_set_pixel_clock(ov2659);
> if (!ret)
> ret = ov2659_set_frame_size(ov2659);
> if (!ret)
> @@ -1229,12 +1244,18 @@ static int ov2659_s_ctrl(struct v4l2_ctrl *ctrl)
>  {
> struct ov2659 *ov2659 =
> container_of(ctrl->handler, struct ov2659, ctrls);
> +   struct i2c_client *client = ov2659->client;
> +
> +   /* V4L2 controls values will be applied only when power is already up 
> */
> +   if (!pm_runtime_get_if_in_use(&client->dev))
> +   return 0;
>
> switch (ctrl->id) {
> case V4L2_CID_TEST_PATTERN:
> return ov2659_set_test_pattern(ov2659, ctrl->val);
> }
>
> +   pm_runtime_put(&client->dev);
> return 0;
>  }
>
> @@ -1247,6 +1268,39 @@ static const char * const ov2659_test_pattern_menu[] = 
> {
> "Vertical Color Bars",
>  };
>
> +static int ov2659_power_off(struct device *dev)
> +{
> +   struct i2c_client *client = to_i2c_client(dev);
> +   struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +   struct ov2659 *ov2659 = to_ov2659(sd);
> +
> +   dev_dbg(&client->dev, "%s:\n", __func__);
> +
> +   gpiod_set_value(ov2659->pwdn_gpio, 1);
> +
> +   return 0;
> +}
> +
> +static int ov2659_power_on(struct device *dev)
> +{
> +   struct i2c_client *client = to_i2c_client(dev);
> +   struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +   struct ov2659 *ov2659 = to_ov2659(sd);
> +
> +   dev_dbg(&client->dev, "%s:\n", __func__);
> +
> +   gpiod_set_value(ov2659->pwdn_gpio, 0);
> +
> +   if (ov2659->resetb_gpio) {
> +   gpiod_set_value(ov2659->resetb_gpio, 1);
> +   usleep_range(500, 1000);
> +   gpiod_set_value(ov2659->resetb_gpio, 0);
> +   usleep_range(3000, 5000);
> +   }
> +
> +   return 0;
> +}
> +
>  /* 
> -
>   * V4L2 subdev internal operations
>   */
> @@ -1327,7 +1381,6 @@ static int ov2659_detect(struct v4l2_subdev *sd)
> ret = -ENODEV;
>  

Re: [PATCH v3 1/2] x86: Don't let pgprot_modify() change the page encryption bit

[Thomas Hellstrom]

Hi,

On 9/18/19 7:57 PM, Dave Hansen wrote:
> On 9/17/19 6:01 AM, Thomas Hellström (VMware) wrote:
>> diff --git a/arch/x86/include/asm/pgtable_types.h 
>> b/arch/x86/include/asm/pgtable_types.h
>> index b5e49e6bac63..8267dd426b15 100644
>> --- a/arch/x86/include/asm/pgtable_types.h
>> +++ b/arch/x86/include/asm/pgtable_types.h
>> @@ -123,7 +123,7 @@
>>   */
>>  #define _PAGE_CHG_MASK  (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | 
>> \
>>   _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \
>> - _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
>> + _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC)
>>  #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
> My only nit with what remains is that it expands the infestation of
> things that look like a simple macro but are not.
>
> I'm debating whether we want to go fix that now, though.
>
Any chance for an ack on this? It's really a small change that, as we've
found out, fixes an existing problem.

Thanks,

Thomas

Re: [patch for-5.3 0/4] revert immediate fallback to remote hugepages

[Michal Hocko]

On Mon 30-09-19 13:28:17, Michal Hocko wrote:
[...]
> Do not get me wrong, but we have a quite a long history of fine tuning
> for THP by adding kludges here and there and they usually turnout to
> break something else. I really want to get to understand the underlying
> problem and base a solution on it rather than "__GFP_THISNODE can cause
> overreclaim so pick up a break out condition and hope for the best".

I didn't really get to any testing earlier but I was really suspecting
that hugetlb will be the first one affected because it uses
__GFP_RETRY_MAYFAIL - aka it really wants to succeed as much as possible
because this is a direct admin request to preallocate a specific number
of huge pages. The patch 3 doesn't really make any difference for those
requests.

Here is a very simple test I've done. Single NUMA node with 1G of
memory. Populate the memory with a clean page cache. That is both easy
to compact and reclaim and then try to allocate 512M worth of hugetlb
pages.
root@test1:~# cat hugetlb_test.sh
#!/bin/sh

set -x
echo 0 > /proc/sys/vm/nr_hugepages
echo 3 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/vm/compact_memory
dd if=/mnt/data/file-1G of=/dev/null bs=$((4<<10))
TS=$(date +%s)
cp /proc/vmstat vmstat.$TS.before
echo 256 > /proc/sys/vm/nr_hugepages
cat /proc/sys/vm/nr_hugepages
cp /proc/vmstat vmstat.$TS.after

The results for 2 consecutive runs on clean 5.3
root@test1:~# sh hugetlb_test.sh
+ echo 0
+ echo 3
+ echo 1
+ dd if=/mnt/data/file-1G of=/dev/null bs=4096
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 21.0694 s, 51.0 MB/s
+ date +%s
+ TS=1569905284
+ cp /proc/vmstat vmstat.1569905284.before
+ echo 256
+ cat /proc/sys/vm/nr_hugepages
256
+ cp /proc/vmstat vmstat.1569905284.after
root@test1:~# sh hugetlb_test.sh
+ echo 0
+ echo 3
+ echo 1
+ dd if=/mnt/data/file-1G of=/dev/null bs=4096
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 21.7548 s, 49.4 MB/s
+ date +%s
+ TS=1569905311
+ cp /proc/vmstat vmstat.1569905311.before
+ echo 256
+ cat /proc/sys/vm/nr_hugepages
256
+ cp /proc/vmstat vmstat.1569905311.after

so we get all the requested huge pages to the pool.

Now with first 3 patches of this series applied (the last one doesn't
make any difference for hugetlb allocations).

root@test1:~# sh hugetlb_test.sh
+ echo 0
+ echo 3
+ echo 1
+ dd if=/mnt/data/file-1G of=/dev/null bs=4096
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 20.1815 s, 53.2 MB/s
+ date +%s
+ TS=1569905516
+ cp /proc/vmstat vmstat.1569905516.before
+ echo 256
+ cat /proc/sys/vm/nr_hugepages
11
+ cp /proc/vmstat vmstat.1569905516.after
root@test1:~# sh hugetlb_test.sh
+ echo 0
+ echo 3
+ echo 1
+ dd if=/mnt/data/file-1G of=/dev/null bs=4096
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 21.9485 s, 48.9 MB/s
+ date +%s
+ TS=1569905541
+ cp /proc/vmstat vmstat.1569905541.before
+ echo 256
+ cat /proc/sys/vm/nr_hugepages
12
+ cp /proc/vmstat vmstat.1569905541.after

so we do not get more that 12 huge pages which is really poor. Although
hugetlb pages tend to be allocated early after the boot they are still
an explicit admin request and having less than 5% success rate is really
bad. If anything the __GFP_RETRY_MAYFAIL needs to be reflected in the
code.

I can provide vmstat files if anybody is interested.

Then I have tried another test for THP. It is essentially the same
thing. Populate the page cache to simulate a quite common case of memory
being used for the cache and then populate 512M anonymous area with
MADV_HUGEPAG set on it:
$ cat thp_test.sh
#!/bin/sh

set -x
echo 3 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/vm/compact_memory
dd if=/mnt/data/file-1G of=/dev/null bs=$((4<<10))
TS=$(date +%s)
cp /proc/vmstat vmstat.$TS.before
./mem_eater nowait 500M
cp /proc/vmstat vmstat.$TS.after

mem_eater is essentially (mmap, madvise, and touch page by page dummy
app).

Again clean 5.3 kernel

root@test1:~# sh thp_test.sh 
+ echo 3
+ echo 1
+ dd if=/mnt/data/file-1G of=/dev/null bs=4096
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 20.8575 s, 51.5 MB/s
+ date +%s
+ TS=1569906274
+ cp /proc/vmstat vmstat.1569906274.before
+ ./mem_eater nowait 500M
7f55e8282000-7f5607682000 rw-p  00:00 0 
Size: 512000 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss:  512000 kB
Pss:  512000 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean: 0 kB
Private_Dirty:512000 kB
Referenced:   260616 kB
Anonymous:512000 kB
LazyFree:  0 kB
AnonHugePages:509952 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:0 kB
THPeligible:1
+ cp /proc/vmstat vmstat.1569906274.after

root@test1:~# sh thp_test.sh
+ echo 3
+ echo 1
+ dd if=/mnt/data/file-1G of=/dev/null bs=4096
262144+0 

Re: [PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames

[Jernej Škrabec]

Dne torek, 01. oktober 2019 ob 00:43:34 CEST je Hans Verkuil napisal(a):
> On 10/1/19 12:27 AM, Jernej Škrabec wrote:
> > Dne ponedeljek, 30. september 2019 ob 10:10:48 CEST je Hans Verkuil
> > 
> > napisal(a):
> >> On 9/29/19 10:00 PM, Jernej Skrabec wrote:
> >>> This series adds support for decoding multi-slice H264 frames along with
> >>> support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF.
> >>> 
> >>> Code was tested by modified ffmpeg, which can be found here:
> >>> https://github.com/jernejsk/FFmpeg, branch mainline-test
> >>> It has to be configured with at least following options:
> >>> --enable-v4l2-request --enable-libudev --enable-libdrm
> >>> 
> >>> Samples used for testing:
> >>> http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4
> >>> http://jernej.libreelec.tv/videos/h264/h264.mp4
> >>> 
> >>> Command line used for testing:
> >>> ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt
> >>> bgra -f fbdev /dev/fb0
> >>> 
> >>> Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm
> >>> not sure how. ffmpeg follows exactly which slice is last in frame
> >>> and sets hold flag accordingly. Improper usage of hold flag would
> >>> corrupt ffmpeg assumptions and it would probably crash. Any ideas
> >>> how to test this are welcome!
> >> 
> >> It can be tested partially at least: if ffmpeg tells you it is the last
> >> slice, then queue the slice with the HOLD flag set, then call FLUSH
> >> afterwards. This should clear the HOLD flag again. In this case the
> >> queued
> >> buffer is probably not yet processed, so the flag is cleared before the
> >> decode job starts.
> >> 
> >> You can also try to add a sleep before calling FLUSH to see what happens
> >> if the last queued buffer is already decoded.
> > 
> > Ok, I tried following code:
> > https://github.com/jernejsk/FFmpeg/blob/flush_test/libavcodec/
> > v4l2_request.c#L220-L233
> > 
> > But results are not good. It seems that out_vb in flush command is always
> > NULL and so it always marks capture buffer as done, which leads to kernel
> > warnings.
> > 
> > dmesg output with debugging messages is here: http://ix.io/1Ks8
> > 
> > Currently I'm not sure what is going on. Shouldn't be output buffer queued
> > and waiting to MEDIA_REQUEST_IOC_QUEUE which is executed after flush
> > command as it can be seen from ffmpeg code linked above?
> 
> Argh, I forgot about the fact that this uses requests.
> 
> The FLUSH should happen *after* the MEDIA_REQUEST_IOC_QUEUE ioctl. Otherwise
> it has no effect. As long as the request hasn't been queued, the buffer is
> also not queued to the driver, so out_vb will indeed be NULL.

It's better, but still not working. Currently ffmpeg sometimes reports such 
messages: https://pastebin.com/raw/9tVVtc20 This is dmesg output: http://
ix.io/1L1L

It seems to me like a race condition. Sometimes flush works as indendent and 
sometimes it influences next frame.

Best regards,
Jernje

> 
> Sorry for the confusion.
> 
> Regards,
> 
>   Hans
> 
> > Best regards,
> > Jernej
> > 
> >> Regards,
> >> 
> >>Hans
> >>
> >>> Thanks to Jonas for adjusting ffmpeg.
> >>> 
> >>> Please let me know what you think.
> >>> 
> >>> Best regards,
> >>> Jernej
> >>> 
> >>> Changes from v1:
> >>> - added Rb tags
> >>> - updated V4L2_DEC_CMD_FLUSH documentation
> >>> - updated first slice detection in Cedrus
> >>> - hold capture buffer flag is set according to source format
> >>> - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers
> >>> 
> >>> Hans Verkuil (2):
> >>>   vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
> >>>   videodev2.h: add V4L2_DEC_CMD_FLUSH
> >>> 
> >>> Jernej Skrabec (4):
> >>>   media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers
> >>>   media: cedrus: Detect first slice of a frame
> >>>   media: cedrus: h264: Support multiple slices per frame
> >>>   media: cedrus: Add support for holding capture buffer
> >>>  
> >>>  Documentation/media/uapi/v4l/buffer.rst   | 13 ++
> >>>  .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++-
> >>>  .../media/uapi/v4l/vidioc-reqbufs.rst |  6 +++
> >>>  .../media/videodev2.h.rst.exceptions  |  1 +
> >>>  .../media/common/videobuf2/videobuf2-v4l2.c   |  8 +++-
> >>>  drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++
> >>>  drivers/staging/media/sunxi/cedrus/cedrus.h   |  1 +
> >>>  .../staging/media/sunxi/cedrus/cedrus_dec.c   | 11 +
> >>>  .../staging/media/sunxi/cedrus/cedrus_h264.c  | 11 -
> >>>  .../staging/media/sunxi/cedrus/cedrus_hw.c|  8 ++--
> >>>  .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++
> >>>  include/media/v4l2-mem2mem.h  | 46 +++
> >>>  include/media/videobuf2-core.h|  3 ++
> >>>  include/media/videobuf2-v4l2.h|  5 ++
> >>>  include/uapi/linux/videodev2.h| 14 --
> >>>  15 files changed, 175 insertions(+), 11 deletions(-)

drivers/gpu/drm/exynos/exynos_drm_dsi.c:1796:2-9: line 1796 is redundant because platform_get_irq() already prints an error (fwd)

[Julia Lawall]

-- Forwarded message --
Date: Tue, 1 Oct 2019 10:47:40 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: drivers/gpu/drm/exynos/exynos_drm_dsi.c:1796:2-9: line 1796 is
redundant because platform_get_irq() already prints an error

CC: kbuild-...@01.org
CC: linux-kernel@vger.kernel.org
TO: Sam Ravnborg 
CC: Inki Dae 

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
commit: 156bdac99061b4013c8e47799c6e574f7f84e9f4 drm/exynos: trigger build of 
all modules
date:   3 months ago
:: branch date: 9 hours ago
:: commit date: 3 months ago

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 
Reported-by: Julia Lawall 

>> drivers/gpu/drm/exynos/exynos_drm_dsi.c:1796:2-9: line 1796 is redundant 
>> because platform_get_irq() already prints an error

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=156bdac99061b4013c8e47799c6e574f7f84e9f4
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout 156bdac99061b4013c8e47799c6e574f7f84e9f4
vim +1796 drivers/gpu/drm/exynos/exynos_drm_dsi.c

f37cd5e8098441 Inki Dae 2014-05-09  1722
7eb8f069be8a03 Andrzej Hajda2014-04-04  1723  static int 
exynos_dsi_probe(struct platform_device *pdev)
7eb8f069be8a03 Andrzej Hajda2014-04-04  1724  {
2900c69c52079a Andrzej Hajda2014-10-07  1725struct device *dev = 
&pdev->dev;
7eb8f069be8a03 Andrzej Hajda2014-04-04  1726struct resource *res;
7eb8f069be8a03 Andrzej Hajda2014-04-04  1727struct exynos_dsi *dsi;
0ff03fd164a4f2 Hyungwon Hwang   2015-06-12  1728int ret, i;
7eb8f069be8a03 Andrzej Hajda2014-04-04  1729
2900c69c52079a Andrzej Hajda2014-10-07  1730dsi = devm_kzalloc(dev, 
sizeof(*dsi), GFP_KERNEL);
2900c69c52079a Andrzej Hajda2014-10-07  1731if (!dsi)
2900c69c52079a Andrzej Hajda2014-10-07  1732return -ENOMEM;
2900c69c52079a Andrzej Hajda2014-10-07  1733
e17ddecc3aa519 YoungJun Cho 2014-07-22  1734/* To be checked as 
invalid one */
e17ddecc3aa519 YoungJun Cho 2014-07-22  1735dsi->te_gpio = -ENOENT;
e17ddecc3aa519 YoungJun Cho 2014-07-22  1736
7eb8f069be8a03 Andrzej Hajda2014-04-04  1737
init_completion(&dsi->completed);
7eb8f069be8a03 Andrzej Hajda2014-04-04  1738
spin_lock_init(&dsi->transfer_lock);
7eb8f069be8a03 Andrzej Hajda2014-04-04  1739
INIT_LIST_HEAD(&dsi->transfer_list);
7eb8f069be8a03 Andrzej Hajda2014-04-04  1740
7eb8f069be8a03 Andrzej Hajda2014-04-04  1741dsi->dsi_host.ops = 
&exynos_dsi_ops;
e2d2a1e0a26472 Andrzej Hajda2014-10-07  1742dsi->dsi_host.dev = dev;
7eb8f069be8a03 Andrzej Hajda2014-04-04  1743
e2d2a1e0a26472 Andrzej Hajda2014-10-07  1744dsi->dev = dev;
2154ac9229c10f Marek Szyprowski 2016-04-19  1745dsi->driver_data = 
of_device_get_match_data(dev);
7eb8f069be8a03 Andrzej Hajda2014-04-04  1746
7eb8f069be8a03 Andrzej Hajda2014-04-04  1747ret = 
exynos_dsi_parse_dt(dsi);
7eb8f069be8a03 Andrzej Hajda2014-04-04  1748if (ret)
8665040850e3cb Andrzej Hajda2015-06-11  1749return ret;
7eb8f069be8a03 Andrzej Hajda2014-04-04  1750
7eb8f069be8a03 Andrzej Hajda2014-04-04  1751dsi->supplies[0].supply 
= "vddcore";
7eb8f069be8a03 Andrzej Hajda2014-04-04  1752dsi->supplies[1].supply 
= "vddio";
e2d2a1e0a26472 Andrzej Hajda2014-10-07  1753ret = 
devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
7eb8f069be8a03 Andrzej Hajda2014-04-04  1754
  dsi->supplies);
7eb8f069be8a03 Andrzej Hajda2014-04-04  1755if (ret) {
e2d2a1e0a26472 Andrzej Hajda2014-10-07  1756dev_info(dev, 
"failed to get regulators: %d\n", ret);
7eb8f069be8a03 Andrzej Hajda2014-04-04  1757return 
-EPROBE_DEFER;
7eb8f069be8a03 Andrzej Hajda2014-04-04  1758}
7eb8f069be8a03 Andrzej Hajda2014-04-04  1759
a86854d0c599b3 Kees Cook2018-06-12  1760dsi->clks = 
devm_kcalloc(dev,
a86854d0c599b3 Kees Cook2018-06-12  1761
dsi->driver_data->num_clks, sizeof(*dsi->clks),
0ff03fd164a4f2 Hyungwon Hwang   2015-06-12  1762
GFP_KERNEL);
e6f988a4585762 Hyungwon Hwang   2015-06-12  1763if (!dsi->clks)
e6f988a4585762 Hyungwon Hwang   2015-06-12  1764return -ENOMEM;
e6f988a4585762 Hyungwon Hwang   2015-06-12  1765
0ff03fd164a4f2 Hyungwon Hwang   2015-06-12  1766for (i = 0; i < 
dsi->driver_data->num_clks; i++) {
0ff03fd164a4f2 Hyungwon Hwang   2015-06-12  1767dsi->clks[i] = 
devm_clk_get(dev, clk_names[i]);
0ff03fd164a4f2 Hyungwon Hwang   2015-06-12  1768if 
(IS_ERR(dsi->

Re: [PATCH v3 0/2] mmc: sdhci-milbeaut: add Milbeaut SD driver

[orito.takao]

Hello

Does anyone have any comments on this ?

> The following patches add driver for SD Host controller on
> Socionext's Milbeaut M10V platforms.
> 
> SD Host controller on Milbeaut consists of two controller parts.
> One is core controller F_SDH30, this is similar to sdhci-fujitsu
> controller.
> Another is bridge controller. This bridge controller is not compatible
> with sdhci-fujitsu controller. This is special for Milbeaut series.
> 
> It has the several parts,
>  - reset control
>  - clock enable / select for SDR50/25/12
>  - hold control of DATA/CMD line
>  - select characteristics for WP/CD/LED line
>  - Re-tuning control for mode3
>  - Capability setting
>Timeout Clock / Base Clock / Timer Count for Re-Tuning /
>Debounce period
> These requires special procedures at reset or clock enable/change or
>  further tuning of clock.
> 
> Takao Orito (2):
>   dt-bindings: mmc: add DT bindings for Milbeaut SD controller
>   mmc: sdhci-milbeaut: add Milbeaut SD controller driver
> 
>  .../devicetree/bindings/mmc/sdhci-milbeaut.txt |  30 ++
>  drivers/mmc/host/Kconfig   |  11 +
>  drivers/mmc/host/Makefile  |   1 +
>  drivers/mmc/host/sdhci-milbeaut.c  | 362 
> +
>  drivers/mmc/host/sdhci_f_sdh30.c   |  26 +-
>  drivers/mmc/host/sdhci_f_sdh30.h   |  32 ++
>  6 files changed, 437 insertions(+), 25 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt
>  create mode 100644 drivers/mmc/host/sdhci-milbeaut.c
>  create mode 100644 drivers/mmc/host/sdhci_f_sdh30.h
> 
> -- 
> 1.9.1
> 

Thanks
Orito

-
Takao Orito
Socionext Inc.
E-mail:orito.ta...@socionext.com
Tel:+81-80-9815-1460
-

RE: [PATCH] x86/PAT: priority the PAT warn to error to highlight the developer

[Zhang, Jun]

Please see my comments.

Thanks,
Jun

-Original Message-
From: Borislav Petkov  
Sent: Monday, September 30, 2019 8:03 PM
To: Zhang, Jun 
Cc: dave.han...@linux.intel.com; l...@kernel.org; pet...@infradead.org; 
t...@linutronix.de; mi...@redhat.com; h...@zytor.com; He, Bo ; 
x...@kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/PAT: priority the PAT warn to error to highlight the 
developer

On Sun, Sep 29, 2019 at 03:20:31PM +0800, jun.zh...@intel.com wrote:
> From: zhang jun 
> 
> Documentation/x86/pat.txt says:
> set_memory_uc() or set_memory_wc() must use together with 
> set_memory_wb()

I had to open that file to see what it actually says - btw, the filename is 
pat.rst now - and you're very heavily paraphrasing what is there. So try again 
explaining what the requirement is.
[ZJ] next parts come from pat.txt in kernel version 4.19
Drivers wanting to export some pages to userspace do it by using mmap
interface and a combination of
1) pgprot_noncached()
2) io_remap_pfn_range() or remap_pfn_range() or vm_insert_pfn()

With PAT support, a new API pgprot_writecombine is being added. So, drivers can
continue to use the above sequence, with either pgprot_noncached() or
pgprot_writecombine() in step 1, followed by step 2.

In addition, step 2 internally tracks the region as UC or WC in memtype
list in order to ensure no conflicting mapping.

Note that this set of APIs only works with IO (non RAM) regions. If driver
wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
as step 0 above and also track the usage of those pages and use set_memory_wb()
before the page is freed to free pool.

> if break the PAT attribute, there are tons of warning like:
> [   45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req

That's some android NDK thing, it seems: "The Android NDK is a toolset that 
lets you implement parts of your app in native code,... " lemme guess, they 
have a kernel module?
[ZJ] no, "NDK MediaCodec_" is an android codec2.0 process. It want to use WC 
memory.

> write-combining for [mem 0x1e7a8-0x1e7a87fff], got write-back and 
> in the extremely case, we see kernel panic unexpected like:
> list_del corruption. prev->next should be 88806dbe69c0, but was 
> 888036f048c0

This is not really helpful. You need to explain what exactly you're doing - not 
shortening the error messages.
[ZJ] android codec2.0 want to use WC memory. Which use ion to allocate memory. 
So, we enable drivers/staging/android/ion, which work well except X86, x86 need 
to set_memory_wc().
So there are tons of warning, then list_del corruption. I use this 
patch(https://www.lkml.org/lkml/2019/9/29/25), list crash disappear.
Next is error message.
<4>[49967.389732] x86/PAT: NDK MediaCodec_:10602 map pfn RAM range req 
write-combining for [mem 0x1091f8000-0x1091f8fff], got write-back
<4>[49967.389747] x86/PAT: .vorbis.decoder:10606 map pfn RAM range req 
write-combining for [mem 0x1091f4000-0x1091f7fff], got write-back
<4>[49967.390622] x86/PAT: .vorbis.decoder:10606 map pfn RAM range req 
write-combining for [mem 0x10909-0x109090fff], got write-back
<4>[49967.390687] x86/PAT: .vorbis.decoder:10606 map pfn RAM range req 
write-combining for [mem 0x1091f8000-0x1091fbfff], got write-back
<4>[49967.390855] x86/PAT: NDK MediaCodec_:10602 map pfn RAM range req 
write-combining for [mem 0x1091f4000-0x1091f4fff], got write-back
<4>[49967.391405] x86/PAT: .vorbis.decoder:10606 map pfn RAM range req 
write-combining for [mem 0x109098000-0x109098fff], got write-back
<4>[49967.391454] x86/PAT: NDK MediaCodec_:10602 map pfn RAM range req 
write-combining for [mem 0x1091f8000-0x1091f8fff], got write-back
<4>[49967.391474] x86/PAT: .vorbis.decoder:10606 map pfn RAM range req 
write-combining for [mem 0x1091f4000-0x1091f7fff], got write-back
<4>[49967.392641] x86/PAT: .vorbis.decoder:10606 map pfn RAM range req 
write-combining for [mem 0x14eb68000-0x14eb68fff], got write-back
<4>[49967.392708] x86/PAT: .vorbis.decoder:10606 map pfn RAM range req 
write-combining for [mem 0x1091f8000-0x1091fbfff], got write-back
<4>[49967.393001] x86/PAT: NDK MediaCodec_:10602 map pfn RAM range req 
write-combining for [mem 0x1091f4000-0x1091f4fff], got write-back
<4>[49967.394066] x86/PAT: NDK MediaCodec_:10602 map pfn RAM range req 
write-combining for [mem 0x1091f8000-0x1091f8fff], got write-back
<6>[50045.677129] binder: 3390:3390 transaction failed 29189/-22, size 88-0 
line 3131
<3>[50046.153621] list_del corruption. prev->next should be 89598004c960, 
but was 895ad46e4590
<4>[50046.163464] invalid opcode:  [#1] PREEMPT SMP NOPTI
<4>[50046.169297] CPU: 1 PID: 18792 Comm: Binder:3390_1B Tainted: G U O 
 4.19.68-PKT-190905T163945Z-00031-g9de920e66b4e #1
<4>[50046.182213] RIP: 0010:__list_del_entry_valid+0x78/0x90
<4>[50046.187947] Code: e8 00 a1 c1 ff 0f 0b 48 89 fe 48 c7 c7 60 1a b6 a5 e8 
ef a0 c1 ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 98 1a b6 a5 e8 db a0 c1 ff <0f> 0b 

Re: What populates /proc/partitions ?

[David F.]

It has something to do with devtmpfs that causes it.   If I could set
this GENHD_FL_HIDDEN flag on it, it would solve the problem on those
system that say the have a floppy but doesn't really exist.Is
something built-in to allow that or it's up to the driver itself?

On Mon, Sep 30, 2019 at 8:38 PM David F.  wrote:
>
> Well, it's not straightforward.  No direct calls, it must be somehow
> when kmod is used to load the module.  The only difference I see in
> the udevadm output is the old system has attribute differences
> capability new==11, old==1, event_poll_msec new=2000, old=-1.  I
> figured if i could set the "hidden" attribute to 1 then it looks like
> /proc/partitions won't list it (already "removable"attribute), but
> udev doesn't seem to allow changing the attributes, only referencing
> them. unless I'm missing something?
>
> On Mon, Sep 30, 2019 at 5:13 PM David F.  wrote:
> >
> > Thanks for the replies.   I'll see if I can figure this out.   I know
> > with the same kernel and older udev version in use that it didn't add
> > it, but with the new udev (eudev) it does (one big difference is the
> > new one requires and uses devtmpfs and the old one didn't).
> >
> > I tried making the floppy a module but it still loads on vmware player
> > and the physical test system I'm using that doesn't have one but
> > reports it as existing (vmware doesn't hang, just adds fd0 read errors
> > to log, but physical system does hang while fdisk -l, mdadm --scan
> > runs, etc..).
> >
> > As far as the log, debugging udev output, it's close to the same, the
> > message log (busybox) not much in there to say what's up.   I even
> > tried the old .rules that were being used with the old udev version,
> > but made no difference.
> >
> > On Mon, Sep 30, 2019 at 4:49 PM Randy Dunlap  wrote:
> > >
> > > On 9/30/19 3:47 PM, David F. wrote:
> > > > Hi,
> > > >
> > > > I want to find out why fd0 is being added to /proc/partitions and stop
> > > > that for my build.  I've searched "/proc/partitions" and "partitions",
> > > > not finding anything that matters.
> > >
> > > /proc/partitions is produced on demand by causing a read of it.
> > > That is done by these functions (pointers) in block/genhd.c:
> > >
> > > static const struct seq_operations partitions_op = {
> > > .start  = show_partition_start,
> > > .next   = disk_seqf_next,
> > > .stop   = disk_seqf_stop,
> > > .show   = show_partition
> > > };
> > >
> > > in particular, show_partition().  In turn, that function uses data that 
> > > was
> > > produced upon block device discovery, also in block/genhd.c.
> > > See functions disk_get_part(), disk_part_iter_init(), 
> > > disk_part_iter_next(),
> > > disk_part_iter_exit(), __device_add_disk(), and get_gendisk().
> > >
> > > > If udev is doing it, what function is it call so I can search on that?
> > >
> > > I don't know about that.  I guess in the kernel it is about "uevents".
> > > E.g., in block/genhd.c, there are some calls to kobject_uevent() or 
> > > variants
> > > of it.
> > >
> > > > TIA!!
> > >
> > > There should be something in your boot log about "fd" or "fd0" or floppy.
> > > eh?
> > >
> > > --
> > > ~Randy

Re: [PATCH v2 0/3] Add support for SBI v0.2

[Alan Kao]

On Fri, Sep 27, 2019 at 10:57:45PM +, Atish Patra wrote:
> On Fri, 2019-09-27 at 15:19 -0700, Christoph Hellwig wrote:
> > On Thu, Sep 26, 2019 at 05:09:12PM -0700, Atish Patra wrote:
> > > The Supervisor Binary Interface(SBI) specification[1] now defines a
> > > base extension that provides extendability to add future extensions
> > > while maintaining backward compatibility with previous versions.
> > > The new version is defined as 0.2 and older version is marked as
> > > 0.1.
> > > 
> > > This series adds support v0.2 and a unified calling convention
> > > implementation between 0.1 and 0.2. It also adds minimal SBI
> > > functions
> > > from 0.2 as well to keep the series lean. 
> > 
> > So before we do this game can be please make sure we have a clean 0.2
> > environment that never uses the legacy extensions as discussed
> > before?
> > Without that all this work is rather futile.
> > 
> 
> As per our discussion offline, here are things need to be done to
> achieve that.
> 
> 1. Replace timer, sfence and ipi with better alternative APIs
>   - sbi_set_timer will be same but with new calling convention
>   - send_ipi and sfence_* apis can be modified in such a way that
>   - we don't have to use unprivileged load anymore
>   - Make it scalable
> 
> 2. Drop clear_ipi, console, and shutdown in 0.2.
> 
> We will have a new kernel config (LEGACY_SBI) that can be manually
> enabled if older firmware need to be used. By default, LEGACY_SBI will
> be disabled and kernel with new SBI will be built. We will have to set
> a flag day in a year or so when we can remove the LEGACY_SBI
> completely.
> 
> Let us know if it is not an acceptable approach to anybody.
> I will post a RFC patch with new alternate v0.2 APIs sometime next
> week.
>

Will this legacy option be compatible will bbl?  says, version 1.0.0 or
any earlier ones?

> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> -- 
> Regards,
> Atish

Re: [PATCH -next] bfa: Make restart_bfa static

[Martin K. Petersen]

YueHaibing,

> Fix sparse warning:
>
> drivers/scsi/bfa/bfad.c:1491:1: warning:
>  symbol 'restart_bfa' was not declared. Should it be static?

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/2] scsi: ufs: Add driver for TI wrapper for Cadence UFS IP

[Martin K. Petersen]

Vignesh,

> This series add DT bindings and driver for TI wrapper for Cadence UFS
> IP that is present on TI's J721e SoC

Will need some reviews from DT and ufs folks respectively before I can
queue this up.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2] scsi: qla2xxx: Remove WARN_ON_ONCE in qla2x00_status_cont_entry()

[Martin K. Petersen]

Daniel,

> Commit 88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not
> called from the completion path") introduced the WARN_ON_ONCE in
> qla2x00_status_cont_entry(). The assumption was that there is only one
> status continuations element. According to the firmware documentation
> it is possible that multiple status continuations are emitted by the
> firmware.

Applied to 5.4/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: What populates /proc/partitions ?

[David F.]

Well, it's not straightforward.  No direct calls, it must be somehow
when kmod is used to load the module.  The only difference I see in
the udevadm output is the old system has attribute differences
capability new==11, old==1, event_poll_msec new=2000, old=-1.  I
figured if i could set the "hidden" attribute to 1 then it looks like
/proc/partitions won't list it (already "removable"attribute), but
udev doesn't seem to allow changing the attributes, only referencing
them. unless I'm missing something?

On Mon, Sep 30, 2019 at 5:13 PM David F.  wrote:
>
> Thanks for the replies.   I'll see if I can figure this out.   I know
> with the same kernel and older udev version in use that it didn't add
> it, but with the new udev (eudev) it does (one big difference is the
> new one requires and uses devtmpfs and the old one didn't).
>
> I tried making the floppy a module but it still loads on vmware player
> and the physical test system I'm using that doesn't have one but
> reports it as existing (vmware doesn't hang, just adds fd0 read errors
> to log, but physical system does hang while fdisk -l, mdadm --scan
> runs, etc..).
>
> As far as the log, debugging udev output, it's close to the same, the
> message log (busybox) not much in there to say what's up.   I even
> tried the old .rules that were being used with the old udev version,
> but made no difference.
>
> On Mon, Sep 30, 2019 at 4:49 PM Randy Dunlap  wrote:
> >
> > On 9/30/19 3:47 PM, David F. wrote:
> > > Hi,
> > >
> > > I want to find out why fd0 is being added to /proc/partitions and stop
> > > that for my build.  I've searched "/proc/partitions" and "partitions",
> > > not finding anything that matters.
> >
> > /proc/partitions is produced on demand by causing a read of it.
> > That is done by these functions (pointers) in block/genhd.c:
> >
> > static const struct seq_operations partitions_op = {
> > .start  = show_partition_start,
> > .next   = disk_seqf_next,
> > .stop   = disk_seqf_stop,
> > .show   = show_partition
> > };
> >
> > in particular, show_partition().  In turn, that function uses data that was
> > produced upon block device discovery, also in block/genhd.c.
> > See functions disk_get_part(), disk_part_iter_init(), disk_part_iter_next(),
> > disk_part_iter_exit(), __device_add_disk(), and get_gendisk().
> >
> > > If udev is doing it, what function is it call so I can search on that?
> >
> > I don't know about that.  I guess in the kernel it is about "uevents".
> > E.g., in block/genhd.c, there are some calls to kobject_uevent() or variants
> > of it.
> >
> > > TIA!!
> >
> > There should be something in your boot log about "fd" or "fd0" or floppy.
> > eh?
> >
> > --
> > ~Randy

Re: [PATCH] scsi: libcxgbi: remove unused function to stop warning

[Martin K. Petersen]

Austin,

> Since 'commit fc8d0590d914 ("libcxgbi: Add ipv6 api to driver")' was 
> introduced, there is no call to csk_print_port() 
> and csk_print_ip() is made.

Applied to 5.5/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

KMSAN: uninit-value in adu_disconnect

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:014077b5 DO-NOT-SUBMIT: usb-fuzzer: main usb gadget fuzzer..
git tree:   https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=108b582660
kernel config:  https://syzkaller.appspot.com/x/.config?x=f03c659d0830ab8d
dashboard link: https://syzkaller.appspot.com/bug?extid=224d4aba0201decca39c
compiler:   clang version 9.0.0 (/home/glider/llvm/clang  
80fee25776c2fb61e74c1ecb1a523375c2500b69)

syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15abd5c160
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=168e3a3a60

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

usb 1-1: USB disconnect, device number 23
==
BUG: KMSAN: uninit-value in adu_disconnect+0x302/0x360  
drivers/usb/misc/adutux.c:774

CPU: 0 PID: 3372 Comm: kworker/0:2 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x191/0x1f0 lib/dump_stack.c:113
 kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109
 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:294
 adu_disconnect+0x302/0x360 drivers/usb/misc/adutux.c:774
 usb_unbind_interface+0x3a2/0xdd0 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:1120 [inline]
 device_release_driver_internal+0x911/0xd20 drivers/base/dd.c:1151
 device_release_driver+0x4b/0x60 drivers/base/dd.c:1174
 bus_remove_device+0x4bf/0x670 drivers/base/bus.c:556
 device_del+0xcd5/0x1d10 drivers/base/core.c:2339
 usb_disable_device+0x567/0x1150 drivers/usb/core/message.c:1241
 usb_disconnect+0x51e/0xd60 drivers/usb/core/hub.c:2199
 hub_port_connect drivers/usb/core/hub.c:4949 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
 port_event drivers/usb/core/hub.c:5359 [inline]
 hub_event+0x3fd0/0x72f0 drivers/usb/core/hub.c:5441
 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269
 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415
 kthread+0x4b5/0x4f0 kernel/kthread.c:256
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355

Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:189 [inline]
 kmsan_internal_poison_shadow+0x58/0xb0 mm/kmsan/kmsan.c:148
 kmsan_slab_free+0x8d/0x100 mm/kmsan/kmsan_hooks.c:195
 slab_free_freelist_hook mm/slub.c:1472 [inline]
 slab_free mm/slub.c:3038 [inline]
 kfree+0x4c1/0x2db0 mm/slub.c:3980
 adu_delete drivers/usb/misc/adutux.c:151 [inline]
 adu_release+0x95f/0xa50 drivers/usb/misc/adutux.c:332
 __fput+0x4c9/0xba0 fs/file_table.c:280
 fput+0x37/0x40 fs/file_table.c:313
 task_work_run+0x22e/0x2a0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop arch/x86/entry/common.c:163 [inline]
 prepare_exit_to_usermode+0x39d/0x4d0 arch/x86/entry/common.c:194
 syscall_return_slowpath+0x90/0x610 arch/x86/entry/common.c:274
 do_syscall_64+0xe2/0xf0 arch/x86/entry/common.c:300
 entry_SYSCALL_64_after_hwframe+0x63/0xe7
==


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

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

[PATCH v2] perf script python: integrate page reclaim analyze script

[Yafang Shao]

A new perf script page-reclaim is introduced in this patch. This new script
is used to report the page reclaim details. The possible usage of this
script is as bellow,
- identify latency spike caused by direct reclaim
- whehter the latency spike is relevant with pageout
- why is page reclaim requested, i.e. whether it is because of memory
  fragmentation
- page reclaim efficiency
etc
In the future we may also enhance it to analyze the memcg reclaim.

Bellow is how to use this script,
# Record, one of the following
$ perf record -e 'vmscan:mm_vmscan_*' ./workload
$ perf script record page-reclaim

# Report
$ perf script report page-reclaim

# Report per process latency
$ perf script report page-reclaim -- -p

# Report per process latency details. At what time and how long it
# stalls at each time.
$ perf script report page-reclaim -- -v

An example of doing mmtests,
$ perf script report page-reclaim
Direct reclaims: 4924
Direct latency (ms)total max avg min
  177823.2116378.977  36.114   0.051
Direct file reclaimed 22920
Direct file scanned 28306
Direct file sync write I/O 0
Direct file async write I/O 0
Direct anon reclaimed 212567
Direct anon scanned 1446854
Direct anon sync write I/O 0
Direct anon async write I/O 278325
Direct order  0 1 3
   48702331
Wake kswapd requests 716
Wake order  0 1
  715 1

Kswapd reclaims: 9
Kswapd latency (ms)total max avg min
   86353.046   42128.8169594.783 120.736
Kswapd file reclaimed 366461
Kswapd file scanned 369554
Kswapd file sync write I/O 0
Kswapd file async write I/O 0
Kswapd anon reclaimed 362594
Kswapd anon scanned 693938
Kswapd anon sync write I/O 0
Kswapd anon async write I/O 330663
Kswapd order  0 1 3
  3 1 5
Kswapd re-wakes 705

$ perf script report page-reclaim -- -p
# besides the above basic output, it will also summary per task
# latency
Per process latency (ms):
 pid[comm] total max avg min
   1[systemd]276.764 248.933   21.29   0.293
 163[kswapd0]  86353.046   42128.8169594.783 120.736
7241[bash] 12787.749 859.091  94.028   0.163
1592[master]  81.604  70.811  27.201   2.906
1595[pickup] 496.162 374.168 165.387  14.478
1098[auditd]   19.32   19.32   19.32   19.32
1120[irqbalance]5232.3311386.352 158.555   0.169
7236[usemem]79649.041763.281  24.921   0.051
1605[sshd]   1344.41 645.125  34.4720.16
7238[bash]   1158.921023.307 231.784   0.067
7239[bash] 15100.776 993.447  82.069   0.145
...

$ per script report page-reclaim -- -v
# Besides the basic output, it will asl show per task latency details
Per process latency (ms):
 pid[comm] total max avg min
   timestamp  latency(ns)
   1[systemd]276.764 248.933   21.29   0.293
   3406860552338: 16819800
   3406877381650: 5532855
   3407458799399: 929517
   3407459796042: 916682
   3407460763220: 418989
   3407461250236: 332355
   3407461637534: 401731
   3407462092234: 449219
   3407462605855: 292857
   3407462952343: 372700
   3407463364947: 414880
   3407463829547: 949162
   3407464813883: 248933444
 163[kswapd0]  86353.046   42128.8169594.783 120.736
   3357637025977: 1026962745
   3358915619888: 41268642175
   3400239664127: 42128816204
   3443784780373: 679641989
   3444847948969: 120735792
   3445001978784: 342713657
   3445835850664: 316851589
   3446865035476: 247457873
   3449355401352: 221223878
  ...

This script must be in sync with bellow vmscan tracepoints,
mm_vmscan_direct_reclaim_begin
mm_vmscan_direct_reclaim_end
mm_vmscan_kswapd_wake
mm_vmscan_kswapd_sleep
mm_vmscan_wakeup_kswapd
mm_vmscan_lru_shrink_inactive
mm_vmscan_writepage

Signed-off-by: Yafang Shao 
Cc: Tony Jones 
Cc: Mel Gorman 
---
v1->v2: verified it with python2.7 and python3.6.
add vmscan tracepoints comments in this script

---
 tools/perf/scripts/python/bin/page-reclaim-record |   2 +
 tools/perf/scripts/python/bin/page-reclaim-report |   4 +
 tools/perf/scripts/python/page-reclaim.py | 393 ++
 3 files changed, 

Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y

[Walter Wu]

On Tue, 2019-10-01 at 05:01 +0200, Dmitry Vyukov wrote:
> On Tue, Oct 1, 2019 at 4:36 AM Walter Wu  wrote:
> >
> > On Mon, 2019-09-30 at 10:57 +0200, Marc Gonzalez wrote:
> > > On 30/09/2019 06:36, Walter Wu wrote:
> > >
> > > >  bool check_memory_region(unsigned long addr, size_t size, bool write,
> > > > unsigned long ret_ip)
> > > >  {
> > > > +   if (long(size) < 0) {
> > > > +   kasan_report_invalid_size(src, dest, len, _RET_IP_);
> > > > +   return false;
> > > > +   }
> > > > +
> > > > return check_memory_region_inline(addr, size, write, ret_ip);
> > > >  }
> > >
> > > Is it expected that memcpy/memmove may sometimes (incorrectly) be passed
> > > a negative value? (It would indeed turn up as a "large" size_t)
> > >
> > > IMO, casting to long is suspicious.
> > >
> > > There seem to be some two implicit assumptions.
> > >
> > > 1) size >= ULONG_MAX/2 is invalid input
> > > 2) casting a size >= ULONG_MAX/2 to long yields a negative value
> > >
> > > 1) seems reasonable because we can't copy more than half of memory to
> > > the other half of memory. I suppose the constraint could be even tighter,
> > > but it's not clear where to draw the line, especially when considering
> > > 32b vs 64b arches.
> > >
> > > 2) is implementation-defined, and gcc works "as expected" (clang too
> > > probably) https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
> > >
> > > A comment might be warranted to explain the rationale.
> > > Regards.
> >
> > Thanks for your suggestion.
> > Yes, It is passed a negative value issue in memcpy/memmove/memset.
> > Our current idea should be assumption 1 and only consider 64b arch,
> > because KASAN only supports 64b. In fact, we really can't use so much
> > memory in 64b arch. so assumption 1 make sense.
> 
> Note there are arm KASAN patches floating around, so we should not
> make assumptions about 64-bit arch.
I think arm KASAN patch doesn't merge in mainline, because virtual
memory of shadow memory is so bigger, the kernel virtual memory only has
1GB or 2GB in 32-bit arch, it is hard to solve the issue. it may need
some trade-off.

> 
> But there seems to be a number of such casts already:
> 
It seems that everyone is the same assumption.

> $ find -name "*.c" -exec egrep "\(long\).* < 0" {} \; -print
> } else if ((long) delta < 0) {
> ./kernel/time/timer.c
> if ((long)state < 0)
> ./drivers/thermal/thermal_sysfs.c
> if ((long)delay < 0)
> ./drivers/infiniband/core/addr.c
> if ((long)tmo < 0)
> ./drivers/net/wireless/st/cw1200/pm.c
> if (pos < 0 || (long) pos != pos || (ssize_t) count < 0)
> ./sound/core/info.c
> if ((long)hwrpb->sys_type < 0) {
> ./arch/alpha/kernel/setup.c
> if ((long)m->driver_data < 0)
> ./arch/x86/kernel/apic/apic.c
> if ((long) size < 0L)
> if ((long)addr < 0L) {
> ./arch/sparc/mm/init_64.c
> if ((long)lpid < 0)
> ./arch/powerpc/kvm/book3s_hv.c
> if ((long)regs->regs[insn.mm_i_format.rs] < 0)
> if ((long)regs->regs[insn.i_format.rs] < 0) {
> if ((long)regs->regs[insn.i_format.rs] < 0) {
> ./arch/mips/kernel/branch.c
> if ((long)arch->gprs[insn.i_format.rs] < 0)
> if ((long)arch->gprs[insn.i_format.rs] < 0)
> ./arch/mips/kvm/emulate.c
> if ((long)regs->regs[insn.i_format.rs] < 0)
> ./arch/mips/math-emu/cp1emu.c
> if ((int32_t)(long)prom_vec < 0) {
> ./arch/mips/sibyte/common/cfe.c
> if (msgsz > ns->msg_ctlmax || (long) msgsz < 0 || msqid < 0)
> if (msqid < 0 || (long) bufsz < 0)
> ./ipc/msg.c
> if ((long)x < 0)
> ./mm/page-writeback.c
> if ((long)(next - val) < 0) {
> ./mm/memcontrol.c

Re: [PATCH] scsi: smartpqi: clean up an indentation issue

[Martin K. Petersen]

Colin,

> There are some statements that are indented too deeply, remove the
> extraneous tabs and rejoin split lines.

Applied (additional hunk) to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: csiostor: clean up indentation issue

[Martin K. Petersen]

Colin,

> The goto statement is indented incorrectly, remove the extraneous tab.

Applied to 5.5/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

KASAN: use-after-free Read in batadv_iv_ogm_queue_add

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:faeacb6d net: tap: clean up an indentation issue
git tree:   net
console output: https://syzkaller.appspot.com/x/log.txt?x=1241cbd360
kernel config:  https://syzkaller.appspot.com/x/.config?x=6c210ff0b9a35071
dashboard link: https://syzkaller.appspot.com/bug?extid=0cc629f19ccb8534935b
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

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

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

==
BUG: KASAN: use-after-free in memcpy include/linux/string.h:359 [inline]
BUG: KASAN: use-after-free in batadv_iv_ogm_aggregate_new  
net/batman-adv/bat_iv_ogm.c:544 [inline]
BUG: KASAN: use-after-free in batadv_iv_ogm_queue_add+0x31d/0x1120  
net/batman-adv/bat_iv_ogm.c:640

Read of size 24 at addr 888099112740 by task kworker/u4:2/2025

CPU: 1 PID: 2025 Comm: kworker/u4:2 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
 __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
 kasan_report+0x12/0x17 mm/kasan/common.c:618
 check_memory_region_inline mm/kasan/generic.c:185 [inline]
 check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192
 memcpy+0x24/0x50 mm/kasan/common.c:122
 memcpy include/linux/string.h:359 [inline]
 batadv_iv_ogm_aggregate_new net/batman-adv/bat_iv_ogm.c:544 [inline]
 batadv_iv_ogm_queue_add+0x31d/0x1120 net/batman-adv/bat_iv_ogm.c:640
 batadv_iv_ogm_schedule+0x783/0xe50 net/batman-adv/bat_iv_ogm.c:797
 batadv_iv_send_outstanding_bat_ogm_packet+0x580/0x730  
net/batman-adv/bat_iv_ogm.c:1675

 process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
 worker_thread+0x98/0xe40 kernel/workqueue.c:2415
 kthread+0x361/0x430 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

Allocated by task 9774:
 save_stack+0x23/0x90 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_kmalloc mm/kasan/common.c:493 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:466
 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:507
 kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
 kmalloc include/linux/slab.h:552 [inline]
 batadv_iv_ogm_iface_enable+0x123/0x320 net/batman-adv/bat_iv_ogm.c:201
 batadv_hardif_enable_interface+0x276/0x950  
net/batman-adv/hard-interface.c:761

 batadv_softif_slave_add+0x8f/0x100 net/batman-adv/soft-interface.c:892
 do_set_master net/core/rtnetlink.c:2369 [inline]
 do_set_master+0x1ca/0x230 net/core/rtnetlink.c:2343
 do_setlink+0xa85/0x3520 net/core/rtnetlink.c:2504
 rtnl_setlink+0x273/0x3d0 net/core/rtnetlink.c:2763
 rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223
 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241
 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
 netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
 netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
 sock_sendmsg_nosec net/socket.c:637 [inline]
 sock_sendmsg+0xd7/0x130 net/socket.c:657
 sock_write_iter+0x27c/0x3e0 net/socket.c:989
 call_write_iter include/linux/fs.h:1880 [inline]
 do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
 do_iter_write fs/read_write.c:970 [inline]
 do_iter_write+0x184/0x610 fs/read_write.c:951
 vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
 do_writev+0x15b/0x330 fs/read_write.c:1058
 __do_sys_writev fs/read_write.c:1131 [inline]
 __se_sys_writev fs/read_write.c:1128 [inline]
 __x64_sys_writev+0x75/0xb0 fs/read_write.c:1128
 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 7:
 save_stack+0x23/0x90 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_slab_free+0x102/0x150 mm/kasan/common.c:455
 kasan_slab_free+0xe/0x10 mm/kasan/common.c:463
 __cache_free mm/slab.c:3425 [inline]
 kfree+0x10a/0x2c0 mm/slab.c:3756
 batadv_iv_ogm_iface_disable+0x39/0x80 net/batman-adv/bat_iv_ogm.c:220
 batadv_hardif_disable_interface.cold+0x4b4/0x87b  
net/batman-adv/hard-interface.c:875
 batadv_softif_destroy_netlink+0xa9/0x130  
net/batman-adv/soft-interface.c:1146

 default_device_exit_batch+0x25c/0x410 net/core/dev.c:9830
 ops_exit_list.isra.0+0xfc/0x150 net/core/net_namespace.c:175
 cleanup_net+0x4e2/0xa60 net/core/net_namespace.c:594
 process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
 worker_thread+0x98/0xe40 kernel/workqueue.c:2415
 kthread+0x361/0x430 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

The buggy address belongs to the object at 888099112740
 which belongs to the cache kmalloc-3

Re: [PATCH v2] scsi: core: Log SCSI command age with errors

[Martin K. Petersen]

Milan,

> Couple of users had requested to print the SCSI command age along with
> command failure errors. This is a small change, but allows users to
> get more important information about the command that was failed, it
> would help the users in debugging the command failures:

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2] scsi: qedf: Add port_id getter

[Martin K. Petersen]

Daniel,

> Add qedf_get_host_port_id() to the transport template.
>
> The fc_transport_template initializes the port_id member to the
> default value of -1. The new getter ensures that the sysfs entry shows
> the current value and not the default one, e.g by using 'lsscsi -H -t'

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

Hi Florian,

On Mon, 2019-09-30 at 19:54 -0700, Florian Fainelli wrote:
> 
> On 9/30/2019 7:33 PM, Chris Packham wrote:
> > Hi,
> > 
> > We have a platform using the BCM53344 integrated switch/CPU. This is
> > part of the Hurricane 2 (technically Wolfhound) family of devices.
> > 
> > Currently we're using pieces of Broadcom's "iProc" SDK based on an out
> > of date kernel and we'd very much like to be running as close to
> > upstream as possible. The fact that the Ubiquiti UniFi Switch 8 is
> > upstream gives me some hope.
> 
> FYI, I could not get enough information from the iProc SDK to port (or
> not) the clock driver, so if nothing else, that is an area that may
> require immediate work (though sometimes fixed-clocks would do just fine).

Setting a fixed clock seems to work for me. At least for now.

> 
> > 
> > My current problem is the fact that the uart0 interrupt is shared with
> > the Chip Common A gpio block. When I have and interrupt node on the
> > gpio in the device tree I get an init exit at startup. If I remove the
> > interrupt node the system will boot (except I don't get cascaded
> > interrupts from the GPIOs).
> > 
> > Looking at the pinctrl-nsp-gpio.c it looks as though I might be able to
> > make this work if I can convince the gpio code to return IRQ_HANDLED or
> > IRQ_NONE but I'm struggling against the fact that the pinctrl-iproc-
> > gpio.c defers it's interrupt handing to the gpio core.
> 
> Not sure I follow you here, what part is being handed to gpiolib? The
> top interrupt handler under nsp_gpio_irq_handler() will try to do
> exactly as you described. In fact, there are other iProc designs where
> "gpio-a" and another interrupt, arch/arm/boot/dts/bcm-nsp.dtsi is one
> such example and I never had problems with that part of NSP.
> 

nsp_gpio_probe() creates the irq domain directly and
nsp_gpio_irq_handler() directly deals with sharing by returning
IRQ_HANDLED or IRQ_NONE depending on whether it has a bit set.

iproc_gpio_probe() on the sets iproc_gpio_irq_handler() as the
parent_handler and defers to gpiolib to deal with the irq domain etc.

I'm currently assuming this is why I can't have uart0 and gpio
interrupts. But of course I could be completely wrong.

> > 
> > Is there any way I can get the gpio core to deal with the shared
> > interrupt?

Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y

[Dmitry Vyukov]

On Tue, Oct 1, 2019 at 4:36 AM Walter Wu  wrote:
>
> On Mon, 2019-09-30 at 10:57 +0200, Marc Gonzalez wrote:
> > On 30/09/2019 06:36, Walter Wu wrote:
> >
> > >  bool check_memory_region(unsigned long addr, size_t size, bool write,
> > > unsigned long ret_ip)
> > >  {
> > > +   if (long(size) < 0) {
> > > +   kasan_report_invalid_size(src, dest, len, _RET_IP_);
> > > +   return false;
> > > +   }
> > > +
> > > return check_memory_region_inline(addr, size, write, ret_ip);
> > >  }
> >
> > Is it expected that memcpy/memmove may sometimes (incorrectly) be passed
> > a negative value? (It would indeed turn up as a "large" size_t)
> >
> > IMO, casting to long is suspicious.
> >
> > There seem to be some two implicit assumptions.
> >
> > 1) size >= ULONG_MAX/2 is invalid input
> > 2) casting a size >= ULONG_MAX/2 to long yields a negative value
> >
> > 1) seems reasonable because we can't copy more than half of memory to
> > the other half of memory. I suppose the constraint could be even tighter,
> > but it's not clear where to draw the line, especially when considering
> > 32b vs 64b arches.
> >
> > 2) is implementation-defined, and gcc works "as expected" (clang too
> > probably) https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
> >
> > A comment might be warranted to explain the rationale.
> > Regards.
>
> Thanks for your suggestion.
> Yes, It is passed a negative value issue in memcpy/memmove/memset.
> Our current idea should be assumption 1 and only consider 64b arch,
> because KASAN only supports 64b. In fact, we really can't use so much
> memory in 64b arch. so assumption 1 make sense.

Note there are arm KASAN patches floating around, so we should not
make assumptions about 64-bit arch.

But there seems to be a number of such casts already:

$ find -name "*.c" -exec egrep "\(long\).* < 0" {} \; -print
} else if ((long) delta < 0) {
./kernel/time/timer.c
if ((long)state < 0)
./drivers/thermal/thermal_sysfs.c
if ((long)delay < 0)
./drivers/infiniband/core/addr.c
if ((long)tmo < 0)
./drivers/net/wireless/st/cw1200/pm.c
if (pos < 0 || (long) pos != pos || (ssize_t) count < 0)
./sound/core/info.c
if ((long)hwrpb->sys_type < 0) {
./arch/alpha/kernel/setup.c
if ((long)m->driver_data < 0)
./arch/x86/kernel/apic/apic.c
if ((long) size < 0L)
if ((long)addr < 0L) {
./arch/sparc/mm/init_64.c
if ((long)lpid < 0)
./arch/powerpc/kvm/book3s_hv.c
if ((long)regs->regs[insn.mm_i_format.rs] < 0)
if ((long)regs->regs[insn.i_format.rs] < 0) {
if ((long)regs->regs[insn.i_format.rs] < 0) {
./arch/mips/kernel/branch.c
if ((long)arch->gprs[insn.i_format.rs] < 0)
if ((long)arch->gprs[insn.i_format.rs] < 0)
./arch/mips/kvm/emulate.c
if ((long)regs->regs[insn.i_format.rs] < 0)
./arch/mips/math-emu/cp1emu.c
if ((int32_t)(long)prom_vec < 0) {
./arch/mips/sibyte/common/cfe.c
if (msgsz > ns->msg_ctlmax || (long) msgsz < 0 || msqid < 0)
if (msqid < 0 || (long) bufsz < 0)
./ipc/msg.c
if ((long)x < 0)
./mm/page-writeback.c
if ((long)(next - val) < 0) {
./mm/memcontrol.c

Re: [PATCH][next] scsi: hisi_sas: fix spelling mistake "digial" -> "digital"

[Martin K. Petersen]

Colin,

> There is a spelling mistake in literal string. Fix it.

Applied to 5.5/scsi-queue. Thanks.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: bfa: release allocated memory in case of error

[Martin K. Petersen]

Navid,

> In bfad_im_get_stats if bfa_port_get_stats fails, allocated memory
> needs to be released.

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Florian Fainelli]

On 9/30/2019 7:33 PM, Chris Packham wrote:
> Hi,
> 
> We have a platform using the BCM53344 integrated switch/CPU. This is
> part of the Hurricane 2 (technically Wolfhound) family of devices.
> 
> Currently we're using pieces of Broadcom's "iProc" SDK based on an out
> of date kernel and we'd very much like to be running as close to
> upstream as possible. The fact that the Ubiquiti UniFi Switch 8 is
> upstream gives me some hope.

FYI, I could not get enough information from the iProc SDK to port (or
not) the clock driver, so if nothing else, that is an area that may
require immediate work (though sometimes fixed-clocks would do just fine).

> 
> My current problem is the fact that the uart0 interrupt is shared with
> the Chip Common A gpio block. When I have and interrupt node on the
> gpio in the device tree I get an init exit at startup. If I remove the
> interrupt node the system will boot (except I don't get cascaded
> interrupts from the GPIOs).
> 
> Looking at the pinctrl-nsp-gpio.c it looks as though I might be able to
> make this work if I can convince the gpio code to return IRQ_HANDLED or
> IRQ_NONE but I'm struggling against the fact that the pinctrl-iproc-
> gpio.c defers it's interrupt handing to the gpio core.

Not sure I follow you here, what part is being handed to gpiolib? The
top interrupt handler under nsp_gpio_irq_handler() will try to do
exactly as you described. In fact, there are other iProc designs where
"gpio-a" and another interrupt, arch/arm/boot/dts/bcm-nsp.dtsi is one
such example and I never had problems with that part of NSP.

> 
> Is there any way I can get the gpio core to deal with the shared
> interrupt?
-- 
Florian

Re: [PATCH] PCI: Add Loongson vendor ID and device IDs

[Tiezhu Yang]

On 09/30/2019 10:02 PM, Andrew Murray wrote:

On Mon, Sep 30, 2019 at 12:55:20PM +0800, Tiezhu Yang wrote:

Add the Loongson vendor ID and device IDs to pci_ids.h
to be used in the future.

The Loongson IDs can be found at the following link:
https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.ids

Co-developed-by: Lu Zeng 
Signed-off-by: Lu Zeng 
Signed-off-by: Tiezhu Yang 
---
  include/linux/pci_ids.h | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 21a5724..119639d 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -3111,4 +3111,23 @@

  #define PCI_VENDOR_ID_NCUBE0x10ff

+#define PCI_VENDOR_ID_LOONGSON 0x0014
+#define PCI_DEVICE_ID_LOONGSON_HT  0x7a00
+#define PCI_DEVICE_ID_LOONGSON_APB 0x7a02
+#define PCI_DEVICE_ID_LOONGSON_GMAC0x7a03
+#define PCI_DEVICE_ID_LOONGSON_OTG 0x7a04
+#define PCI_DEVICE_ID_LOONGSON_GPU_2K1000  0x7a05
+#define PCI_DEVICE_ID_LOONGSON_DC  0x7a06
+#define PCI_DEVICE_ID_LOONGSON_HDA 0x7a07
+#define PCI_DEVICE_ID_LOONGSON_SATA0x7a08
+#define PCI_DEVICE_ID_LOONGSON_PCIE_X1 0x7a09
+#define PCI_DEVICE_ID_LOONGSON_SPI 0x7a0b
+#define PCI_DEVICE_ID_LOONGSON_LPC 0x7a0c
+#define PCI_DEVICE_ID_LOONGSON_DMA 0x7a0f
+#define PCI_DEVICE_ID_LOONGSON_EHCI0x7a14
+#define PCI_DEVICE_ID_LOONGSON_GPU_7A1000  0x7a15
+#define PCI_DEVICE_ID_LOONGSON_PCIE_X4 0x7a19
+#define PCI_DEVICE_ID_LOONGSON_OHCI0x7a24
+#define PCI_DEVICE_ID_LOONGSON_PCIE_X8 0x7a29

Hi Tiezhu,

Thanks for the patch - however it is preferred to provide new PCI definitions
along with the drivers that use them. They don't provide any useful value
without drivers that use them.


Hi Andrew,

Thanks for your reply. This is the first step of the Loongson kernel team,
we will submit other related individual driver patches step by step in the
near future, these small patches make an easily understood change that can
be verified by reviewers.

Thanks,

Tiezhu Yang



Thanks,

Andrew Murray


+
  #endif /* _LINUX_PCI_IDS_H */
--
2.1.0

Re: [PATCH] phy-brcm-usb: Use devm_platform_ioremap_resource() in brcm_usb_phy_probe()

[Florian Fainelli]

On 9/26/2019 9:08 AM, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 26 Sep 2019 18:00:14 +0200
> 
> Simplify this function implementation a bit by using
> a known wrapper function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH] scsi: fnic: make array dev_cmd_err static const, makes object smaller

[Martin K. Petersen]

Colin,

> Don't populate the array dev_cmd_err on the stack but instead make it
> static const. Makes the object code smaller by 80 bytes.

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/3] perf/core: Provide a kernel-internal interface to recalibrate event period

[kbuild test robot]

Hi Like,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on kvm/linux-next]
[cannot apply to v5.4-rc1 next-20190930]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Like-Xu/perf-core-Provide-a-kernel-internal-interface-to-recalibrate-event-period/20191001-081543
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: sh-rsk7269_defconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh 

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

All errors (new ones prefixed by >>):

   kernel/events/core.o: In function `_perf_ioctl':
>> core.c:(.text+0x7068): undefined reference to `__get_user_unknown'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] scsi: ufs: make array setup_attrs static const, makes object smaller

[Martin K. Petersen]

Colin,

> Don't populate the array setup_attrs on the stack but instead make it
> static const. Makes the object code smaller by 180 bytes.

Applied to 5.5/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: ips: make array 'options' static const, makes object smaller

[Martin K. Petersen]

Colin,

> Don't populate the array 'options' on the stack but instead make it
> static const. Makes the object code smaller by 143 bytes.

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: mvsas: remove redundant assignment to variable rc

[Martin K. Petersen]

Colin,

> The variable rc is being initialized with a value that is never read
> and is being re-assigned a little later on. The assignment is
> redundant and hence can be removed.

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: qla2xxx: remove redundant assignment to pointer host

[Martin K. Petersen]

Colin,

> The pointer host is being initialized with a value that is never read
> and is being re-assigned a little later on. The assignment is
> redundant and hence can be removed.

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH -next] scsi: smartpqi: remove set but not used variable 'ctrl_info'

[Martin K. Petersen]

YueHaibing,

> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/scsi/smartpqi/smartpqi_init.c: In function 'pqi_driver_version_show':
> drivers/scsi/smartpqi/smartpqi_init.c:6164:24: warning:
>  variable 'ctrl_info' set but not used [-Wunused-but-set-variable]

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y

[Walter Wu]

On Mon, 2019-09-30 at 10:57 +0200, Marc Gonzalez wrote:
> On 30/09/2019 06:36, Walter Wu wrote:
> 
> >  bool check_memory_region(unsigned long addr, size_t size, bool write,
> > unsigned long ret_ip)
> >  {
> > +   if (long(size) < 0) {
> > +   kasan_report_invalid_size(src, dest, len, _RET_IP_);
> > +   return false;
> > +   }
> > +
> > return check_memory_region_inline(addr, size, write, ret_ip);
> >  }
> 
> Is it expected that memcpy/memmove may sometimes (incorrectly) be passed
> a negative value? (It would indeed turn up as a "large" size_t)
> 
> IMO, casting to long is suspicious.
> 
> There seem to be some two implicit assumptions.
> 
> 1) size >= ULONG_MAX/2 is invalid input
> 2) casting a size >= ULONG_MAX/2 to long yields a negative value
> 
> 1) seems reasonable because we can't copy more than half of memory to
> the other half of memory. I suppose the constraint could be even tighter,
> but it's not clear where to draw the line, especially when considering
> 32b vs 64b arches.
> 
> 2) is implementation-defined, and gcc works "as expected" (clang too
> probably) https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
> 
> A comment might be warranted to explain the rationale.
> Regards.

Thanks for your suggestion.
Yes, It is passed a negative value issue in memcpy/memmove/memset.
Our current idea should be assumption 1 and only consider 64b arch,
because KASAN only supports 64b. In fact, we really can't use so much
memory in 64b arch. so assumption 1 make sense.

Re: [PATCH][smartpqi-next] scsi: smartpqi: clean up indentation of a statement

[Martin K. Petersen]

Colin,

> There is a statement that is indented one level too deeply, remove the
> tab, re-join broken line and remove some empty lines.

Applied to 5.5/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v4 4/4] perf_event_open: switch to copy_struct_from_user()

[Christian Brauner]

On Tue, Oct 01, 2019 at 11:10:55AM +1000, Aleksa Sarai wrote:
> The change is very straightforward, and helps unify the syscall
> interface for struct-from-userspace syscalls.
> 
> Reviewed-by: Kees Cook 
> Signed-off-by: Aleksa Sarai 

Reviewed-by: Christian Brauner 

Problem sharing interrupts between gpioa and uart0 on Broadcom Hurricane 2 (iProc)

[Chris Packham]

Hi,

We have a platform using the BCM53344 integrated switch/CPU. This is
part of the Hurricane 2 (technically Wolfhound) family of devices.

Currently we're using pieces of Broadcom's "iProc" SDK based on an out
of date kernel and we'd very much like to be running as close to
upstream as possible. The fact that the Ubiquiti UniFi Switch 8 is
upstream gives me some hope.

My current problem is the fact that the uart0 interrupt is shared with
the Chip Common A gpio block. When I have and interrupt node on the
gpio in the device tree I get an init exit at startup. If I remove the
interrupt node the system will boot (except I don't get cascaded
interrupts from the GPIOs).

Looking at the pinctrl-nsp-gpio.c it looks as though I might be able to
make this work if I can convince the gpio code to return IRQ_HANDLED or
IRQ_NONE but I'm struggling against the fact that the pinctrl-iproc-
gpio.c defers it's interrupt handing to the gpio core.

Is there any way I can get the gpio core to deal with the shared
interrupt?

Thanks,
Chris

Re: [PATCH v4 2/4] clone3: switch to copy_struct_from_user()

[Christian Brauner]

On Tue, Oct 01, 2019 at 11:10:53AM +1000, Aleksa Sarai wrote:
> The change is very straightforward, and helps unify the syscall
> interface for struct-from-userspace syscalls. Additionally, explicitly
> define CLONE_ARGS_SIZE_VER0 to match the other users of the
> struct-extension pattern.
> 
> Reviewed-by: Kees Cook 
> Signed-off-by: Aleksa Sarai 

Reviewed-by: Christian Brauner 

Re: [PATCH v4 3/4] sched_setattr: switch to copy_struct_from_user()

[Christian Brauner]

On Tue, Oct 01, 2019 at 11:10:54AM +1000, Aleksa Sarai wrote:
> The change is very straightforward, and helps unify the syscall
> interface for struct-from-userspace syscalls. Ideally we could also
> unify sched_getattr(2)-style syscalls as well, but unfortunately the
> correct semantics for such syscalls are much less clear (see [1] for
> more detail). In future we could come up with a more sane idea for how
> the syscall interface should look.
> 
> [1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
>  robustify sched_read_attr() ABI logic and code")
> 
> Reviewed-by: Kees Cook 
> Signed-off-by: Aleksa Sarai 

Reviewed-by: Christian Brauner 

Re: [PATCH v4 1/4] lib: introduce copy_struct_from_user() helper

[Christian Brauner]

On Mon, Sep 30, 2019 at 06:58:39PM -0700, Kees Cook wrote:
> On Tue, Oct 01, 2019 at 11:10:52AM +1000, Aleksa Sarai wrote:
> > A common pattern for syscall extensions is increasing the size of a
> > struct passed from userspace, such that the zero-value of the new fields
> > result in the old kernel behaviour (allowing for a mix of userspace and
> > kernel vintages to operate on one another in most cases).
> > 
> > While this interface exists for communication in both directions, only
> > one interface is straightforward to have reasonable semantics for
> > (userspace passing a struct to the kernel). For kernel returns to
> > userspace, what the correct semantics are (whether there should be an
> > error if userspace is unaware of a new extension) is very
> > syscall-dependent and thus probably cannot be unified between syscalls
> > (a good example of this problem is [1]).
> > 
> > Previously there was no common lib/ function that implemented
> > the necessary extension-checking semantics (and different syscalls
> > implemented them slightly differently or incompletely[2]). Future
> > patches replace common uses of this pattern to make use of
> > copy_struct_from_user().
> > 
> > Some in-kernel selftests that insure that the handling of alignment and
> > various byte patterns are all handled identically to memchr_inv() usage.
> > 
> > [1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
> >  robustify sched_read_attr() ABI logic and code")
> > 
> > [2]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
> >  similar checks to copy_struct_from_user() while rt_sigprocmask(2)
> >  always rejects differently-sized struct arguments.
> > 
> > Suggested-by: Rasmus Villemoes 
> > Signed-off-by: Aleksa Sarai 
> > ---
> >  include/linux/bitops.h  |   7 +++
> >  include/linux/uaccess.h |  70 +
> >  lib/strnlen_user.c  |   8 +--
> >  lib/test_user_copy.c| 136 ++--
> >  lib/usercopy.c  |  55 
> >  5 files changed, 263 insertions(+), 13 deletions(-)
> > 
> > diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> > index cf074bce3eb3..c94a9ff9f082 100644
> > --- a/include/linux/bitops.h
> > +++ b/include/linux/bitops.h
> > @@ -4,6 +4,13 @@
> >  #include 
> >  #include 
> >  
> > +/* Set bits in the first 'n' bytes when loaded from memory */
> > +#ifdef __LITTLE_ENDIAN
> > +#  define aligned_byte_mask(n) ((1UL << 8*(n))-1)
> > +#else
> > +#  define aligned_byte_mask(n) (~0xffUL << (BITS_PER_LONG - 8 - 8*(n)))
> > +#endif
> > +
> >  #define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE)
> >  #define BITS_TO_LONGS(nr)  DIV_ROUND_UP(nr, BITS_PER_TYPE(long))
> >  
> > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> > index 70bbdc38dc37..8abbc713f7fb 100644
> > --- a/include/linux/uaccess.h
> > +++ b/include/linux/uaccess.h
> > @@ -231,6 +231,76 @@ __copy_from_user_inatomic_nocache(void *to, const void 
> > __user *from,
> >  
> >  #endif /* ARCH_HAS_NOCACHE_UACCESS */
> >  
> > +extern int check_zeroed_user(const void __user *from, size_t size);
> > +
> > +/**
> > + * copy_struct_from_user: copy a struct from userspace
> > + * @dst:   Destination address, in kernel space. This buffer must be @ksize
> > + * bytes long.
> > + * @ksize: Size of @dst struct.
> > + * @src:   Source address, in userspace.
> > + * @usize: (Alleged) size of @src struct.
> > + *
> > + * Copies a struct from userspace to kernel space, in a way that guarantees
> > + * backwards-compatibility for struct syscall arguments (as long as future
> > + * struct extensions are made such that all new fields are *appended* to 
> > the
> > + * old struct, and zeroed-out new fields have the same meaning as the old
> > + * struct).
> > + *
> > + * @ksize is just sizeof(*dst), and @usize should've been passed by 
> > userspace.
> > + * The recommended usage is something like the following:
> > + *
> > + *   SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, 
> > usize)
> > + *   {
> > + *  int err;
> > + *  struct foo karg = {};
> > + *
> > + *  if (usize > PAGE_SIZE)
> > + *return -E2BIG;
> > + *  if (usize < FOO_SIZE_VER0)
> > + *return -EINVAL;
> > + *
> > + *  err = copy_struct_from_user(&karg, sizeof(karg), uarg, usize);
> > + *  if (err)
> > + *return err;
> > + *
> > + *  // ...
> > + *   }
> > + *
> > + * There are three cases to consider:
> > + *  * If @usize == @ksize, then it's copied verbatim.
> > + *  * If @usize < @ksize, then the userspace has passed an old struct to a
> > + *newer kernel. The rest of the trailing bytes in @dst (@ksize - 
> > @usize)
> > + *are to be zero-filled.
> > + *  * If @usize > @ksize, then the userspace has passed a new struct to an
> > + *older kernel. The trailing bytes unknown to the kernel (@usize - 
> > @ksize)
> > + *are checked to ensure they are zeroed, otherwi

Re: [PATCH 1/3] perf/core: Provide a kernel-internal interface to recalibrate event period

[kbuild test robot]

Hi Like,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on kvm/linux-next]
[cannot apply to v5.4-rc1 next-20190930]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Like-Xu/perf-core-Provide-a-kernel-internal-interface-to-recalibrate-event-period/20191001-081543
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: nds32-allnoconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=nds32 

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

All errors (new ones prefixed by >>):

   nds32le-linux-ld: init/do_mounts.o: in function `perf_event_period':
>> do_mounts.c:(.text+0xc): multiple definition of `perf_event_period'; 
>> init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: init/noinitramfs.o: in function `perf_event_period':
   noinitramfs.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: arch/nds32/kernel/sys_nds32.o: in function 
`perf_event_period':
   sys_nds32.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: arch/nds32/kernel/syscall_table.o: in function 
`perf_event_period':
   syscall_table.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: arch/nds32/mm/fault.o: in function `perf_event_period':
   fault.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/fork.o: in function `perf_event_period':
   fork.c:(.text+0x374): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/exec_domain.o: in function `perf_event_period':
   exec_domain.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/cpu.o: in function `perf_event_period':
   cpu.c:(.text+0xd4): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/exit.o: in function `perf_event_period':
   exit.c:(.text+0xf30): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/sysctl.o: in function `perf_event_period':
   sysctl.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/sysctl_binary.o: in function `perf_event_period':
   sysctl_binary.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/capability.o: in function `perf_event_period':
   capability.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/ptrace.o: in function `perf_event_period':
   ptrace.c:(.text+0x3f4): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/signal.o: in function `perf_event_period':
   signal.c:(.text+0x580): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/sys.o: in function `perf_event_period':
   sys.c:(.text+0x70c): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/umh.o: in function `perf_event_period':
   umh.c:(.text+0x4c8): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/pid.o: in function `perf_event_period':
   pid.c:(.text+0x0): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/nsproxy.o: in function `perf_event_period':
   nsproxy.c:(.text+0x14c): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x0): first defined here
   nds32le-linux-ld: kernel/reboot.o: in function `perf_event_period':
   reboot.c:(.text+0x6c): multiple definition of `perf_event_period'; 
init/main.o:main.c:(.text+0x

include/linux/spinlock.h:393:9: sparse: sparse: context imbalance in 'linflex_console_write' - unexpected unlock

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
commit: 09864c1cdf5c537bd01bff45181406e422ea988c tty: serial: Add linflexuart 
driver for S32V234
date:   4 weeks ago
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-37-gd466a02-dirty
git checkout 09864c1cdf5c537bd01bff45181406e422ea988c
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

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


sparse warnings: (new ones prefixed by >>)

>> include/linux/spinlock.h:393:9: sparse: sparse: context imbalance in 
>> 'linflex_console_write' - unexpected unlock

vim +/linflex_console_write +393 include/linux/spinlock.h

c2f21ce2e31286 Thomas Gleixner 2009-12-02  390  
3490565b633c70 Denys Vlasenko  2015-07-13  391  static __always_inline void 
spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
c2f21ce2e31286 Thomas Gleixner 2009-12-02  392  {
c2f21ce2e31286 Thomas Gleixner 2009-12-02 @393  
raw_spin_unlock_irqrestore(&lock->rlock, flags);
c2f21ce2e31286 Thomas Gleixner 2009-12-02  394  }
c2f21ce2e31286 Thomas Gleixner 2009-12-02  395  

:: The code at line 393 was first introduced by commit
:: c2f21ce2e31286a0a32f8da0a7856e9ca1122ef3 locking: Implement new 
raw_spinlock

:: TO: Thomas Gleixner 
:: CC: Thomas Gleixner 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: x86/random: Speculation to the rescue

[hgntkwis]

Why not get entropy from the white noise that can be obtained from any  
attached ADC? Audio cards, some SBCs, and microcontrollers all have  
ADCs.
Not that I'm familiar with when the kernel first needs entropy or an  
expert in the field.


Thanks



-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [PATCH 3/4] perf inject --jit: Remove //anon mmap events

[Andi Kleen]

On Mon, Sep 30, 2019 at 08:49:00PM +, Steve MacLean wrote:
> SNIP
> 
> > I can't apply this one:
> 
> > patching file builtin-inject.c
> > Hunk #1 FAILED at 263.
> > 1 out of 1 hunk FAILED -- saving rejects to file builtin-inject.c.rej 
> 
> I assume this is because I based my patches on the wrong tip.
> 
> > patching file util/jitdump.c
> > patch:  malformed patch at line 236: btree, node);
> 
> This doesn't make sense to me.  The patch doesn't try to inject near line 
> 236. There aren't 236 lines in the e-mail

Most likely your mail client did line wrap.

See Documentation/process/email-clients.rst

-Andi

Re: [PATCH v1 0/2] perf stat: Support --all-kernel and --all-user

[Andi Kleen]

> > I think it's useful. Makes it easy to do kernel/user break downs.
> > perf record should support the same.
> 
> Don't we have this already with:
> 
> [root@quaco ~]# perf stat -e cycles:u,instructions:u,cycles:k,instructions:k 
> -a -- sleep 1

This only works for simple cases. Try it for --topdown or multiple -M metrics.

-Andi

Re: [PATCH v15 1/4] soc: mediatek: cmdq: define the instruction struct

[CK Hu]

Hi, Bibby:

On Fri, 2019-09-27 at 19:42 +0800, Bibby Hsieh wrote:
> Define an instruction structure for gce driver to append command.
> This structure can make the client's code more readability.
> 
> Signed-off-by: Bibby Hsieh 
> Reviewed-by: CK Hu 

You've modified this patch in this version, so you should drop this
'Reviewed-by' tag.

> Reviewed-by: Houlong Wei 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   | 106 +--
>  include/linux/mailbox/mtk-cmdq-mailbox.h |  10 +++
>  2 files changed, 90 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 7aa0517ff2f3..7af327b98d25 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -9,12 +9,24 @@
>  #include 
>  #include 
>  
> -#define CMDQ_ARG_A_WRITE_MASK0x
>  #define CMDQ_WRITE_ENABLE_MASK   BIT(0)
>  #define CMDQ_EOC_IRQ_EN  BIT(0)
>  #define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
>   << 32 | CMDQ_EOC_IRQ_EN)
>  
> +struct cmdq_instruction {
> + union {
> + u32 value;
> + u32 mask;
> + };
> + union {
> + u16 offset;
> + u16 event;
> + };
> + u8 subsys;
> + u8 op;
> +};
> +
>  static void cmdq_client_timeout(struct timer_list *t)
>  {
>   struct cmdq_client *client = from_timer(client, t, timer);
> @@ -110,10 +122,10 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_destroy);
>  
> -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> -u32 arg_a, u32 arg_b)
> +static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
> +struct cmdq_instruction *inst)
>  {
> - u64 *cmd_ptr;
> + struct cmdq_instruction *cmd_ptr;
>  
>   if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
>   /*
> @@ -129,8 +141,9 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, 
> enum cmdq_code code,
>   __func__, (u32)pkt->buf_size);
>   return -ENOMEM;
>   }
> +
>   cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> - (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> + *cmd_ptr = *inst;
>   pkt->cmd_buf_size += CMDQ_INST_SIZE;
>  
>   return 0;
> @@ -138,24 +151,42 @@ static int cmdq_pkt_append_command(struct cmdq_pkt 
> *pkt, enum cmdq_code code,
>  
>  int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
>  {
> - u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> - (subsys << CMDQ_SUBSYS_SHIFT);
> + struct cmdq_instruction *inst = kzalloc(sizeof(*inst), GFP_KERNEL);

Frequently allocate/free increase CPU loading. The simpler way is

struct cmdq_instruction inst = { 0 };

cmdq_pkt_append_command(pkt, &inst);


> + int err = 0;

No need to assign initial value.

> +
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WRITE;
> + inst->value = value;
> + inst->offset = offset;
> + inst->subsys = subsys;
>  
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> + err = cmdq_pkt_append_command(pkt, inst);
> + kfree(inst);
> +
> + return err;
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write);
>  

[snip]

>  
>  static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  {
> - int err;
> + struct cmdq_instruction *inst = kzalloc(sizeof(*inst), GFP_KERNEL);
> + int err = 0;
> +
> + if (!inst)
> + return -ENOMEM;
>  
>   /* insert EOC and generate IRQ for each command iteration */
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
> + inst->op = CMDQ_CODE_EOC;
> + inst->value = CMDQ_EOC_IRQ_EN;
> + err = cmdq_pkt_append_command(pkt, inst);
>  
>   /* JUMP to end */
> - err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
> + inst->op = CMDQ_CODE_JUMP;
> + inst->value = CMDQ_JUMP_PASS;
> + err |= cmdq_pkt_append_command(pkt, inst);

OR the err value looks strange. If you OR err 0x1 and err 0x10, you
would get the new err 0x11. How do you know that err 0x11 is the
combination of 0x1 and 0x10?

This bug seems exist in previous patch, so I would like you to fix this
bug first and then apply this patch.

Regards,
CK


> + kfree(inst);
>  
>   return err;
>  }
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index e6f54ef6698b..678760548791 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -20,6 +20,16 @@
>  #define CMDQ_WFE_WAITBIT(15)
>  #define CMDQ_WFE_WAIT_VALUE  0x1
>  
> +/*
> + * WFE arg_b
> + * bit 0-11: wait value
> + * bit 15: 1 - wait, 0 - no wait
> + * bit 16-27:

[PATCH] tty: n_hdlc: fix build on SPARC

[Randy Dunlap]

From: Randy Dunlap 

Fix tty driver build on SPARC by not using __exitdata.
It appears that SPARC does not support section .exit.data.

Fixes these build errors:

`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
`.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o

Reported-by: kbuild test robot 
Fixes: 063246641d4a ("format-security: move static strings to const")
Signed-off-by: Randy Dunlap 
Cc: Kees Cook 
Cc: Greg Kroah-Hartman 
Cc: "David S. Miller" 
Cc: Andrew Morton 
---
 drivers/tty/n_hdlc.c |5 +
 1 file changed, 5 insertions(+)

--- mmotm-2019-0925-1810.orig/drivers/tty/n_hdlc.c
+++ mmotm-2019-0925-1810/drivers/tty/n_hdlc.c
@@ -968,6 +968,11 @@ static int __init n_hdlc_init(void)

 }  /* end of init_module() */
 
+#ifdef CONFIG_SPARC
+#undef __exitdata
+#define __exitdata
+#endif
+
 static const char hdlc_unregister_ok[] __exitdata =
KERN_INFO "N_HDLC: line discipline unregistered\n";
 static const char hdlc_unregister_fail[] __exitdata =

linux-next: Tree for Oct 1

[Stephen Rothwell]

Hi all,

Changes since 20190930:

New trees: erofs-fixes, erofs, kunit

My fixes tree contains:

  04e6dac68d9b ("powerpc/64s/radix: fix for "tidy up TLB flushing code" and 
!CONFIG_PPC_RADIX_MMU")

Non-merge commits (relative to Linus' tree): 455
 594 files changed, 15071 insertions(+), 4081 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (54ecb8f7028c Linux 5.4-rc1)
Merging fixes/master (04e6dac68d9b powerpc/64s/radix: fix for "tidy up TLB 
flushing code" and !CONFIG_PPC_RADIX_MMU)
Merging kbuild-current/fixes (f97c81dc6ca5 Merge tag 'armsoc-late' of 
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc)
Merging arc-current/for-curr (41277ba7eb4e ARC: mm: tlb flush optim: elide 
redundant uTLB invalidates for MMUv3)
Merging arm-current/fixes (5b3efa4f1479 ARM: 8901/1: add a criteria for 
pfn_valid of arm)
Merging arm-soc-fixes/arm/fixes (a304c0a60252 arm64/ARM: configs: Change 
CONFIG_REMOTEPROC from m to y)
Merging arm64-fixes/for-next/fixes (799c85105233 arm64: Fix reference to docs 
for ARM64_TAGGED_ADDR_ABI)
Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache())
Merging powerpc-fixes/fixes (253c892193ab powerpc/eeh: Fix eeh 
eeh_debugfs_break_device() with SRIOV devices)
Merging s390-fixes/fixes (d45331b00ddb Linux 5.3-rc4)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (0e141f757b2c erspan: remove the incorrect mtu limit for 
erspan)
Merging bpf/master (55d554f5d140 tools: bpf: Use !building_out_of_srctree to 
determine srctree)
Merging ipsec/master (00b368502d18 xen-netfront: do not assume sk_buff_head 
list is empty in error handling)
Merging netfilter/master (02dc96ef6c25 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes')
Merging wireless-drivers/master (54ecb8f7028c Linux 5.4-rc1)
Merging mac80211/master (f794dc2304d8 sctp: fix the missing put_user when 
dumping transport thresholds)
Merging rdma-fixes/for-rc (531a64e4c35b RDMA/siw: Fix IPv6 addr_list locking)
Merging sound-current/for-linus (f41f900568d9 ALSA: usb-audio: Add DSD support 
for EVGA NU Audio)
Merging sound-asoc-fixes/for-linus (84b66885fdcf Merge branch 'asoc-5.4' into 
asoc-linus)
Merging regmap-fixes/for-linus (0161b8716465 Merge branch 'regmap-5.3' into 
regmap-linus)
Merging regulator-fixes/for-linus (f9a60abc26d9 Merge branch 'regulator-5.4' 
into regulator-linus)
Merging spi-fixes/for-linus (60b76d1c3b0a Merge branch 'spi-5.4' into spi-linus)
Merging pci-current/for-linus (5184d449600f Merge tag 'microblaze-v5.4-rc1' of 
git://git.monstr.eu/linux-2.6-microblaze)
Merging driver-core.current/driver-core-linus (54ecb8f7028c Linux 5.4-rc1)
Merging tty.current/tty-linus (54ecb8f7028c Linux 5.4-rc1)
Merging usb.current/usb-linus (54ecb8f7028c Linux 5.4-rc1)
Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix 
races between fsg_disable and fsg_set_alt)
Mergin

Re: [PATCH v4 1/4] lib: introduce copy_struct_from_user() helper

[Kees Cook]

On Tue, Oct 01, 2019 at 11:10:52AM +1000, Aleksa Sarai wrote:
> A common pattern for syscall extensions is increasing the size of a
> struct passed from userspace, such that the zero-value of the new fields
> result in the old kernel behaviour (allowing for a mix of userspace and
> kernel vintages to operate on one another in most cases).
> 
> While this interface exists for communication in both directions, only
> one interface is straightforward to have reasonable semantics for
> (userspace passing a struct to the kernel). For kernel returns to
> userspace, what the correct semantics are (whether there should be an
> error if userspace is unaware of a new extension) is very
> syscall-dependent and thus probably cannot be unified between syscalls
> (a good example of this problem is [1]).
> 
> Previously there was no common lib/ function that implemented
> the necessary extension-checking semantics (and different syscalls
> implemented them slightly differently or incompletely[2]). Future
> patches replace common uses of this pattern to make use of
> copy_struct_from_user().
> 
> Some in-kernel selftests that insure that the handling of alignment and
> various byte patterns are all handled identically to memchr_inv() usage.
> 
> [1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
>  robustify sched_read_attr() ABI logic and code")
> 
> [2]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
>  similar checks to copy_struct_from_user() while rt_sigprocmask(2)
>  always rejects differently-sized struct arguments.
> 
> Suggested-by: Rasmus Villemoes 
> Signed-off-by: Aleksa Sarai 
> ---
>  include/linux/bitops.h  |   7 +++
>  include/linux/uaccess.h |  70 +
>  lib/strnlen_user.c  |   8 +--
>  lib/test_user_copy.c| 136 ++--
>  lib/usercopy.c  |  55 
>  5 files changed, 263 insertions(+), 13 deletions(-)
> 
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index cf074bce3eb3..c94a9ff9f082 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -4,6 +4,13 @@
>  #include 
>  #include 
>  
> +/* Set bits in the first 'n' bytes when loaded from memory */
> +#ifdef __LITTLE_ENDIAN
> +#  define aligned_byte_mask(n) ((1UL << 8*(n))-1)
> +#else
> +#  define aligned_byte_mask(n) (~0xffUL << (BITS_PER_LONG - 8 - 8*(n)))
> +#endif
> +
>  #define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE)
>  #define BITS_TO_LONGS(nr)DIV_ROUND_UP(nr, BITS_PER_TYPE(long))
>  
> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> index 70bbdc38dc37..8abbc713f7fb 100644
> --- a/include/linux/uaccess.h
> +++ b/include/linux/uaccess.h
> @@ -231,6 +231,76 @@ __copy_from_user_inatomic_nocache(void *to, const void 
> __user *from,
>  
>  #endif   /* ARCH_HAS_NOCACHE_UACCESS */
>  
> +extern int check_zeroed_user(const void __user *from, size_t size);
> +
> +/**
> + * copy_struct_from_user: copy a struct from userspace
> + * @dst:   Destination address, in kernel space. This buffer must be @ksize
> + * bytes long.
> + * @ksize: Size of @dst struct.
> + * @src:   Source address, in userspace.
> + * @usize: (Alleged) size of @src struct.
> + *
> + * Copies a struct from userspace to kernel space, in a way that guarantees
> + * backwards-compatibility for struct syscall arguments (as long as future
> + * struct extensions are made such that all new fields are *appended* to the
> + * old struct, and zeroed-out new fields have the same meaning as the old
> + * struct).
> + *
> + * @ksize is just sizeof(*dst), and @usize should've been passed by 
> userspace.
> + * The recommended usage is something like the following:
> + *
> + *   SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
> + *   {
> + *  int err;
> + *  struct foo karg = {};
> + *
> + *  if (usize > PAGE_SIZE)
> + *return -E2BIG;
> + *  if (usize < FOO_SIZE_VER0)
> + *return -EINVAL;
> + *
> + *  err = copy_struct_from_user(&karg, sizeof(karg), uarg, usize);
> + *  if (err)
> + *return err;
> + *
> + *  // ...
> + *   }
> + *
> + * There are three cases to consider:
> + *  * If @usize == @ksize, then it's copied verbatim.
> + *  * If @usize < @ksize, then the userspace has passed an old struct to a
> + *newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize)
> + *are to be zero-filled.
> + *  * If @usize > @ksize, then the userspace has passed a new struct to an
> + *older kernel. The trailing bytes unknown to the kernel (@usize - 
> @ksize)
> + *are checked to ensure they are zeroed, otherwise -E2BIG is returned.
> + *
> + * Returns (in all cases, some data may have been copied):
> + *  * -E2BIG:  (@usize > @ksize) and there are non-zero trailing bytes in 
> @src.
> + *  * -EFAULT: access to userspace failed.
> + */
> +static __always_inline
> +int copy_struct_from_user(void *dst, 

Re: [PATCH v1 1/2] dt-bindings: spi: Add support for cadence-qspi IP Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Rob,

   Thank you for the review comments.

On 1/10/2019 6:36 AM, Rob Herring wrote:

On Mon, Sep 16, 2019 at 03:38:42PM +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

On Intel Lightening Mountain(LGM) SoCs QSPI controller support
to QSPI-NAND flash. This introduces to device tree binding
documentation for Cadence-QSPI controller and spi-nand flash.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
  .../devicetree/bindings/spi/cadence,qspi-nand.yaml | 84 ++
  1 file changed, 84 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml

diff --git a/Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml 
b/Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml
new file mode 100644
index ..9aae4c1459cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/cadence,qspi-nand.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Cadence QSPI Flash Controller on Intel's SoC
+
+maintainers:
+  - Ramuthevar Vadivel Murugan 
+
+allOf:
+  - $ref: "spi-controller.yaml#"
+
+description: |
+  The Cadence QSPI is a controller optimized for communication with SPI
+  FLASH memories, without DMA support on Intel's SoC.
+
+properties:
+  compatible:
+const: cadence,lgm-qspi

Vendor here should be 'intel'. Perhaps the binding should be shared too
like the driver.

Plus the vendor prefix for Cadence is cdns.

Agreed!, will update.

+
+  reg:
+maxItems: 1
+
+  fifo-depth:
+maxItems: 1
+

This is vendor specific, so needs a vendor prefix, type, and
description.

agreed!

+  fifo-width:
+maxItems: 1

Same


+
+  qspi-phyaddr:
+maxItems: 1

Same


+
+  qspi-phymask:
+maxItems: 1

Same

will update all the above.

+
+  clocks:
+maxItems: 2

Need to define what each clock is when there is more than 1.

Sure, will update.

+
+  clocks-names:
+maxItems: 2

Need to define the strings.

Noted, will update.

+
+  resets:
+maxItems: 1
+
+  reset-names:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - fifo-depth
+  - fifo-width
+  - qspi-phyaddr
+  - qspi-phymask
+  - clocks
+  - clock-names
+  - resets
+  - reset-names
+
+examples:
+  - |
+qspi@ec00 {

spi@...


Controller is qspi , so that have updated.

With Best Regards
Vadivel Murugan R

+  compatible = "cadence,qspi-nand";
+  reg = <0xec00 0x100>;
+  fifo-depth = <128>;
+  fifo-width = <4>;
+  qspi-phyaddr = <0xf400>;
+  qspi-phymask = <0x>;
+  clocks = <&cgu0 LGM_CLK_QSPI>, <&cgu0 LGM_GCLK_QSPI>;
+  clock-names = "freq", "qspi";
+  resets = <&rcu0 0x10 1>;
+  reset-names = "qspi";
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  flash: flash@1 {
+  compatible = "spi-nand";
+  reg = <1>;
+  spi-max-frequency = <1000>;
+  };
+};
+
--
2.11.0

[PATCH v4 3/4] sched_setattr: switch to copy_struct_from_user()

[Aleksa Sarai]

The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Ideally we could also
unify sched_getattr(2)-style syscalls as well, but unfortunately the
correct semantics for such syscalls are much less clear (see [1] for
more detail). In future we could come up with a more sane idea for how
the syscall interface should look.

[1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
 robustify sched_read_attr() ABI logic and code")

Reviewed-by: Kees Cook 
Signed-off-by: Aleksa Sarai 
---
 kernel/sched/core.c | 43 +++
 1 file changed, 7 insertions(+), 36 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7880f4f64d0e..dd05a378631a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5106,9 +5106,6 @@ static int sched_copy_attr(struct sched_attr __user 
*uattr, struct sched_attr *a
u32 size;
int ret;
 
-   if (!access_ok(uattr, SCHED_ATTR_SIZE_VER0))
-   return -EFAULT;
-
/* Zero the full structure, so that a short copy will be nice: */
memset(attr, 0, sizeof(*attr));
 
@@ -5116,45 +5113,19 @@ static int sched_copy_attr(struct sched_attr __user 
*uattr, struct sched_attr *a
if (ret)
return ret;
 
-   /* Bail out on silly large: */
-   if (size > PAGE_SIZE)
-   goto err_size;
-
/* ABI compatibility quirk: */
if (!size)
size = SCHED_ATTR_SIZE_VER0;
-
-   if (size < SCHED_ATTR_SIZE_VER0)
+   if (size < SCHED_ATTR_SIZE_VER0 || size > PAGE_SIZE)
goto err_size;
 
-   /*
-* If we're handed a bigger struct than we know of,
-* ensure all the unknown bits are 0 - i.e. new
-* user-space does not rely on any kernel feature
-* extensions we dont know about yet.
-*/
-   if (size > sizeof(*attr)) {
-   unsigned char __user *addr;
-   unsigned char __user *end;
-   unsigned char val;
-
-   addr = (void __user *)uattr + sizeof(*attr);
-   end  = (void __user *)uattr + size;
-
-   for (; addr < end; addr++) {
-   ret = get_user(val, addr);
-   if (ret)
-   return ret;
-   if (val)
-   goto err_size;
-   }
-   size = sizeof(*attr);
+   ret = copy_struct_from_user(attr, sizeof(*attr), uattr, size);
+   if (ret) {
+   if (ret == -E2BIG)
+   goto err_size;
+   return ret;
}
 
-   ret = copy_from_user(attr, uattr, size);
-   if (ret)
-   return -EFAULT;
-
if ((attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) &&
size < SCHED_ATTR_SIZE_VER1)
return -EINVAL;
@@ -5354,7 +5325,7 @@ sched_attr_copy_to_user(struct sched_attr __user *uattr,
  * sys_sched_getattr - similar to sched_getparam, but with sched_attr
  * @pid: the pid in question.
  * @uattr: structure containing the extended parameters.
- * @usize: sizeof(attr) that user-space knows about, for forwards and 
backwards compatibility.
+ * @usize: sizeof(attr) for fwd/bwd comp.
  * @flags: for future extension.
  */
 SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr,
-- 
2.23.0

[PATCH v4 4/4] perf_event_open: switch to copy_struct_from_user()

[Aleksa Sarai]

The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls.

Reviewed-by: Kees Cook 
Signed-off-by: Aleksa Sarai 
---
 kernel/events/core.c | 47 +---
 1 file changed, 9 insertions(+), 38 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4655adbbae10..3f0cb82e4fbc 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10586,55 +10586,26 @@ static int perf_copy_attr(struct perf_event_attr 
__user *uattr,
u32 size;
int ret;
 
-   if (!access_ok(uattr, PERF_ATTR_SIZE_VER0))
-   return -EFAULT;
-
-   /*
-* zero the full structure, so that a short copy will be nice.
-*/
+   /* Zero the full structure, so that a short copy will be nice. */
memset(attr, 0, sizeof(*attr));
 
ret = get_user(size, &uattr->size);
if (ret)
return ret;
 
-   if (size > PAGE_SIZE)   /* silly large */
-   goto err_size;
-
-   if (!size)  /* abi compat */
+   /* ABI compatibility quirk: */
+   if (!size)
size = PERF_ATTR_SIZE_VER0;
-
-   if (size < PERF_ATTR_SIZE_VER0)
+   if (size < PERF_ATTR_SIZE_VER0 || size > PAGE_SIZE)
goto err_size;
 
-   /*
-* If we're handed a bigger struct than we know of,
-* ensure all the unknown bits are 0 - i.e. new
-* user-space does not rely on any kernel feature
-* extensions we dont know about yet.
-*/
-   if (size > sizeof(*attr)) {
-   unsigned char __user *addr;
-   unsigned char __user *end;
-   unsigned char val;
-
-   addr = (void __user *)uattr + sizeof(*attr);
-   end  = (void __user *)uattr + size;
-
-   for (; addr < end; addr++) {
-   ret = get_user(val, addr);
-   if (ret)
-   return ret;
-   if (val)
-   goto err_size;
-   }
-   size = sizeof(*attr);
+   ret = copy_struct_from_user(attr, sizeof(*attr), uattr, size);
+   if (ret) {
+   if (ret == -E2BIG)
+   goto err_size;
+   return ret;
}
 
-   ret = copy_from_user(attr, uattr, size);
-   if (ret)
-   return -EFAULT;
-
attr->size = size;
 
if (attr->__reserved_1)
-- 
2.23.0

[PATCH v4 2/4] clone3: switch to copy_struct_from_user()

[Aleksa Sarai]

The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Additionally, explicitly
define CLONE_ARGS_SIZE_VER0 to match the other users of the
struct-extension pattern.

Reviewed-by: Kees Cook 
Signed-off-by: Aleksa Sarai 
---
 include/uapi/linux/sched.h |  2 ++
 kernel/fork.c  | 34 +++---
 2 files changed, 9 insertions(+), 27 deletions(-)

diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
index b3105ac1381a..0945805982b4 100644
--- a/include/uapi/linux/sched.h
+++ b/include/uapi/linux/sched.h
@@ -47,6 +47,8 @@ struct clone_args {
__aligned_u64 tls;
 };
 
+#define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
+
 /*
  * Scheduling policies
  */
diff --git a/kernel/fork.c b/kernel/fork.c
index f9572f416126..2ef529869c64 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2525,39 +2525,19 @@ SYSCALL_DEFINE5(clone, unsigned long, clone_flags, 
unsigned long, newsp,
 #ifdef __ARCH_WANT_SYS_CLONE3
 noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
  struct clone_args __user *uargs,
- size_t size)
+ size_t usize)
 {
+   int err;
struct clone_args args;
 
-   if (unlikely(size > PAGE_SIZE))
+   if (unlikely(usize > PAGE_SIZE))
return -E2BIG;
-
-   if (unlikely(size < sizeof(struct clone_args)))
+   if (unlikely(usize < CLONE_ARGS_SIZE_VER0))
return -EINVAL;
 
-   if (unlikely(!access_ok(uargs, size)))
-   return -EFAULT;
-
-   if (size > sizeof(struct clone_args)) {
-   unsigned char __user *addr;
-   unsigned char __user *end;
-   unsigned char val;
-
-   addr = (void __user *)uargs + sizeof(struct clone_args);
-   end = (void __user *)uargs + size;
-
-   for (; addr < end; addr++) {
-   if (get_user(val, addr))
-   return -EFAULT;
-   if (val)
-   return -E2BIG;
-   }
-
-   size = sizeof(struct clone_args);
-   }
-
-   if (copy_from_user(&args, uargs, size))
-   return -EFAULT;
+   err = copy_struct_from_user(&args, sizeof(args), uargs, usize);
+   if (err)
+   return err;
 
/*
 * Verify that higher 32bits of exit_signal are unset and that
-- 
2.23.0

[PATCH v4 1/4] lib: introduce copy_struct_from_user() helper

[Aleksa Sarai]

A common pattern for syscall extensions is increasing the size of a
struct passed from userspace, such that the zero-value of the new fields
result in the old kernel behaviour (allowing for a mix of userspace and
kernel vintages to operate on one another in most cases).

While this interface exists for communication in both directions, only
one interface is straightforward to have reasonable semantics for
(userspace passing a struct to the kernel). For kernel returns to
userspace, what the correct semantics are (whether there should be an
error if userspace is unaware of a new extension) is very
syscall-dependent and thus probably cannot be unified between syscalls
(a good example of this problem is [1]).

Previously there was no common lib/ function that implemented
the necessary extension-checking semantics (and different syscalls
implemented them slightly differently or incompletely[2]). Future
patches replace common uses of this pattern to make use of
copy_struct_from_user().

Some in-kernel selftests that insure that the handling of alignment and
various byte patterns are all handled identically to memchr_inv() usage.

[1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
 robustify sched_read_attr() ABI logic and code")

[2]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
 similar checks to copy_struct_from_user() while rt_sigprocmask(2)
 always rejects differently-sized struct arguments.

Suggested-by: Rasmus Villemoes 
Signed-off-by: Aleksa Sarai 
---
 include/linux/bitops.h  |   7 +++
 include/linux/uaccess.h |  70 +
 lib/strnlen_user.c  |   8 +--
 lib/test_user_copy.c| 136 ++--
 lib/usercopy.c  |  55 
 5 files changed, 263 insertions(+), 13 deletions(-)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index cf074bce3eb3..c94a9ff9f082 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -4,6 +4,13 @@
 #include 
 #include 
 
+/* Set bits in the first 'n' bytes when loaded from memory */
+#ifdef __LITTLE_ENDIAN
+#  define aligned_byte_mask(n) ((1UL << 8*(n))-1)
+#else
+#  define aligned_byte_mask(n) (~0xffUL << (BITS_PER_LONG - 8 - 8*(n)))
+#endif
+
 #define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE)
 #define BITS_TO_LONGS(nr)  DIV_ROUND_UP(nr, BITS_PER_TYPE(long))
 
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 70bbdc38dc37..8abbc713f7fb 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -231,6 +231,76 @@ __copy_from_user_inatomic_nocache(void *to, const void 
__user *from,
 
 #endif /* ARCH_HAS_NOCACHE_UACCESS */
 
+extern int check_zeroed_user(const void __user *from, size_t size);
+
+/**
+ * copy_struct_from_user: copy a struct from userspace
+ * @dst:   Destination address, in kernel space. This buffer must be @ksize
+ * bytes long.
+ * @ksize: Size of @dst struct.
+ * @src:   Source address, in userspace.
+ * @usize: (Alleged) size of @src struct.
+ *
+ * Copies a struct from userspace to kernel space, in a way that guarantees
+ * backwards-compatibility for struct syscall arguments (as long as future
+ * struct extensions are made such that all new fields are *appended* to the
+ * old struct, and zeroed-out new fields have the same meaning as the old
+ * struct).
+ *
+ * @ksize is just sizeof(*dst), and @usize should've been passed by userspace.
+ * The recommended usage is something like the following:
+ *
+ *   SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
+ *   {
+ *  int err;
+ *  struct foo karg = {};
+ *
+ *  if (usize > PAGE_SIZE)
+ *return -E2BIG;
+ *  if (usize < FOO_SIZE_VER0)
+ *return -EINVAL;
+ *
+ *  err = copy_struct_from_user(&karg, sizeof(karg), uarg, usize);
+ *  if (err)
+ *return err;
+ *
+ *  // ...
+ *   }
+ *
+ * There are three cases to consider:
+ *  * If @usize == @ksize, then it's copied verbatim.
+ *  * If @usize < @ksize, then the userspace has passed an old struct to a
+ *newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize)
+ *are to be zero-filled.
+ *  * If @usize > @ksize, then the userspace has passed a new struct to an
+ *older kernel. The trailing bytes unknown to the kernel (@usize - @ksize)
+ *are checked to ensure they are zeroed, otherwise -E2BIG is returned.
+ *
+ * Returns (in all cases, some data may have been copied):
+ *  * -E2BIG:  (@usize > @ksize) and there are non-zero trailing bytes in @src.
+ *  * -EFAULT: access to userspace failed.
+ */
+static __always_inline
+int copy_struct_from_user(void *dst, size_t ksize,
+ const void __user *src, size_t usize)
+{
+   size_t size = min(ksize, usize);
+   size_t rest = max(ksize, usize) - size;
+
+   /* Deal with trailing bytes. */
+   if (usize < ksize) {
+   memset(dst + size, 0, rest);
+   } else if (usiz

[PATCH v4 0/4] lib: introduce copy_struct_from_user() helper

[Aleksa Sarai]

Patch changelog:
 v4:
  * __always_inline copy_struct_from_user(). [Kees Cook]
  * Rework test_user_copy.ko changes. [Kees Cook]
 v3: 
 
 v2: 
 v1: 

This series was split off from the openat2(2) syscall discussion[1].
However, the copy_struct_to_user() helper has been dropped, because
after some discussion it appears that there is no really obvious
semantics for how copy_struct_to_user() should work on mixed-vintages
(for instance, whether [2] is the correct semantics for all syscalls).

A common pattern for syscall extensions is increasing the size of a
struct passed from userspace, such that the zero-value of the new fields
result in the old kernel behaviour (allowing for a mix of userspace and
kernel vintages to operate on one another in most cases).

Previously there was no common lib/ function that implemented
the necessary extension-checking semantics (and different syscalls
implemented them slightly differently or incompletely[3]). This series
implements the helper and ports several syscalls to use it.

Some in-kernel selftests are included in this patch. More complete
self-tests for copy_struct_from_user() are included in the openat2()
patchset.

[1]: https://lore.kernel.org/lkml/20190904201933.10736-1-cyp...@cyphar.com/

[2]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
 robustify sched_read_attr() ABI logic and code")

[3]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
 similar checks to copy_struct_from_user() while rt_sigprocmask(2)
 always rejects differently-sized struct arguments.

Aleksa Sarai (4):
  lib: introduce copy_struct_from_user() helper
  clone3: switch to copy_struct_from_user()
  sched_setattr: switch to copy_struct_from_user()
  perf_event_open: switch to copy_struct_from_user()

 include/linux/bitops.h |   7 ++
 include/linux/uaccess.h|  70 +++
 include/uapi/linux/sched.h |   2 +
 kernel/events/core.c   |  47 +++--
 kernel/fork.c  |  34 ++
 kernel/sched/core.c|  43 ++--
 lib/strnlen_user.c |   8 +--
 lib/test_user_copy.c   | 136 +++--
 lib/usercopy.c |  55 +++
 9 files changed, 288 insertions(+), 114 deletions(-)

-- 
2.23.0

Re: [PATCH 5.3 00/25] 5.3.2-stable review

[Dan Rue]

On Sun, Sep 29, 2019 at 03:56:03PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.2 release.
> There are 25 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Tue 01 Oct 2019 01:47:47 PM UTC.
> Anything received after that time might be too late.

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.3.2-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.3.y
git commit: 5910f7ae17298c45fce24a2f314573bcb7a86284
git describe: v5.3.1-26-g5910f7ae1729
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.3-oe/build/v5.3.1-26-g5910f7ae1729

No regressions (compared to build v5.3.1)

No fixes (compared to build v5.3.1)

Ran 23295 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-open-posix-tests
* network-basic-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 5.2 00/45] 5.2.18-stable review

[Dan Rue]

On Sun, Sep 29, 2019 at 03:55:28PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.18 release.
> There are 45 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Tue 01 Oct 2019 01:47:47 PM UTC.
> Anything received after that time might be too late.

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.2.18-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.2.y
git commit: 70cc0b99b90f823b81175b1f15f73ced86135c5b
git describe: v5.2.17-46-g70cc0b99b90f
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.17-46-g70cc0b99b90f

No regressions (compared to build v5.2.17)

No fixes (compared to build v5.2.17)

Ran 22166 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-open-posix-tests
* network-basic-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.19 00/63] 4.19.76-stable review

[Dan Rue]

On Sun, Sep 29, 2019 at 03:53:33PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.76 release.
> There are 63 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Tue 01 Oct 2019 01:47:47 PM UTC.
> Anything received after that time might be too late.

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.76-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: b52c75f7b9785d0d0e6bf145787ed2fc99f5483c
git describe: v4.19.75-64-gb52c75f7b978
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.75-64-gb52c75f7b978

No regressions (compared to build v4.19.75)

No fixes (compared to build v4.19.75)

Ran 23641 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 5.2 00/45] 5.2.18-stable review

[shuah]

On 9/29/19 7:55 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.2.18 release.
There are 45 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 01 Oct 2019 01:47:47 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.18-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.2.y
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH v7 0/1] Add bounds check for Hotplugged memory

[Alastair D'Silva]

From: Alastair D'Silva 

This series adds bounds checks for hotplugged memory, ensuring that
it is within the physically addressable range (for platforms that
define MAX_(POSSIBLE_)PHYSMEM_BITS.

This allows for early failure, rather than attempting to access
bogus section numbers.

Changelog:
 V7:
   - Cast PFN_PHYS as u64 since it's type is platform dependant
 V6:
   - Fix printf formats
 V5:
   - Factor out calculation into max_allowed var
   - Declare unchanging vars as const
   - Use PFN_PHYS macro instead of shifting by PAGE_SHIFT
 V4:
   - Relocate call to __add_pages
   - Add a warning when the addressable check fails
 V3:
   - Perform the addressable check before we take the hotplug lock
 V2:
   - Don't use MAX_POSSIBLE_PHYSMEM_BITS as it's wider that what
 may be available

Alastair D'Silva (1):
  memory_hotplug: Add a bounds check to __add_pages

 mm/memory_hotplug.c | 20 
 1 file changed, 20 insertions(+)

-- 
2.21.0

[PATCH v7 1/1] memory_hotplug: Add a bounds check to __add_pages

[Alastair D'Silva]

From: Alastair D'Silva 

On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB"). It is
possible that the addressable range may change again in the
future.

In this scenario, we end up with a bogus section returned from
__section_nr (see the discussion on the thread "mm: Trigger bug on
if a section is not found in __section_nr").

Adding a check here means that we fail early and have an
opportunity to handle the error gracefully, rather than rumbling
on and potentially accessing an incorrect section.

Further discussion is also on the thread ("powerpc: Perform a bounds
check in arch_add_memory")
http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com

Signed-off-by: Alastair D'Silva 
---
 mm/memory_hotplug.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f09913165..5af9f4466ad1 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -278,6 +278,22 @@ static int check_pfn_span(unsigned long pfn, unsigned long 
nr_pages,
return 0;
 }
 
+static int check_hotplug_memory_addressable(unsigned long pfn,
+   unsigned long nr_pages)
+{
+   const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
+
+   if (max_addr >> MAX_PHYSMEM_BITS) {
+   const u64 max_allowed = (1ull << (MAX_PHYSMEM_BITS + 1)) - 1;
+   WARN(1,
+"Hotplugged memory exceeds maximum addressable address, 
range=%#llx-%#llx, maximum=%#llx\n",
+(u64)PFN_PHYS(pfn), max_addr, max_allowed);
+   return -E2BIG;
+   }
+
+   return 0;
+}
+
 /*
  * Reasonably generic function for adding memory.  It is
  * expected that archs that support memory hotplug will
@@ -291,6 +307,10 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned 
long nr_pages,
unsigned long nr, start_sec, end_sec;
struct vmem_altmap *altmap = restrictions->altmap;
 
+   err = check_hotplug_memory_addressable(pfn, nr_pages);
+   if (err)
+   return err;
+
if (altmap) {
/*
 * Validate altmap is within bounds of the total request
-- 
2.21.0