Re: [PATCH] selftests: Makefile: create OUTPUT dir

2024-10-01 Thread Anders Roxell
On Wed, 25 Sept 2024 at 19:26, Shuah Khan  wrote:
>
> On 9/20/24 04:38, Jakub Kicinski wrote:
> > On Thu, 19 Sep 2024 09:51:47 -0600 Shuah Khan wrote:
> >>> @@ -261,6 +261,7 @@ ifdef INSTALL_PATH
> >>> @ret=1; \
> >>> for TARGET in $(TARGETS) $(INSTALL_DEP_TARGETS); do \
> >>> BUILD_TARGET=$$BUILD/$$TARGET;  \
> >>> +   mkdir -p $$BUILD_TARGET;\
> >>> $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install \
> >>> INSTALL_PATH=$(INSTALL_PATH)/$$TARGET \
> >>> SRC_PATH=$(shell readlink -e $$(pwd)) \
> >>
> >> Doesn't the "all" target mkdir work for this case? Why do we need another 
> >> mkdir here?
> >
> > I was wondering about that, too. Looks like the code from the all
> > target is copy/pasted in the install target except the mkdir line.
> > Best fix would be to make the dependency work, I don't understand
> > why it doesn't already, tho.
>
> I think this could be the issue:
>
> net main Makefile doesn't have handling for subdirs. It looks
> like the way this is handled is by adding an entry to the main
> Makefile:
>
> TARGETS += net/af_unix
> TARGETS += net/forwarding
> TARGETS += net/hsr
> TARGETS += net/mptcp
> TARGETS += net/openvswitch
> TARGETS += net/tcp_ao
> TARGETS += net/netfilter
>
> So the solution would be similar adding net/lib to the main
> Makefile.
>
> Anders, can you try the above and see if it works.

Sadly that didn't help.

>
> Another issue - lib/Makefile
> TEST_GEN_FILES += csum needs to be TEST_GEN_FILES = csum
>
> thanks,
> -- Shuah
>



[PATCH] selftests: Makefile: create OUTPUT dir

2024-09-16 Thread Anders Roxell
When cross building kselftest out-of-tree the following issue can be
seen:

[...]
make[4]: Entering directory
'/src/kernel/linux/tools/testing/selftests/net/lib'
  CC   csum
/usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld:
cannot open output file /tmp/build/kselftest/net/lib/csum: No such
file or directory
collect2: error: ld returned 1 exit status
[...]

Create the output build directory before building the targets, solves
this issue with building 'net/lib/csum'.

Suggested-by: Jakub Kicinski 
Signed-off-by: Anders Roxell 
---
 tools/testing/selftests/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index b38199965f99..05c143bcff6a 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -261,6 +261,7 @@ ifdef INSTALL_PATH
@ret=1; \
for TARGET in $(TARGETS) $(INSTALL_DEP_TARGETS); do \
BUILD_TARGET=$$BUILD/$$TARGET;  \
+   mkdir -p $$BUILD_TARGET;\
$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install \
INSTALL_PATH=$(INSTALL_PATH)/$$TARGET \
SRC_PATH=$(shell readlink -e $$(pwd)) \
-- 
2.45.2




Re: [PATCH] selftests: Makefile: add missing 'net/lib' to targets

2024-09-16 Thread Anders Roxell
On Sun, 15 Sept 2024 at 16:46, Jakub Kicinski  wrote:
>
> On Sun, 15 Sep 2024 09:36:10 +0200 Willem de Bruijn wrote:
> > > You’re right, the patch is incorrect, I could have explained better.
> > > I’m seeing an issue with an out-of-tree cross compilation build of
> > > kselftest and can’t figure out what’s wrong.
> > >
> > > make --keep-going --jobs=32 O=/tmp/build
> > > INSTALL_PATH=/tmp/build/kselftest_install \
> > >  ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
> > >  CROSS_COMPILE_COMPAT=arm-linux-gnueabihf- kselftest-install
> > >
> > > [...]
> > > make[4]: Entering directory
> > > '/home/anders/src/kernel/linux/tools/testing/selftests/net/lib'
> > >   CC   csum
> > > /usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld:
> > > cannot open output file /tmp/build/kselftest/net/lib/csum: No such
> > > file or directory
> > > collect2: error: ld returned 1 exit status
> > > [...]
> > >
> > > Any thoughts on what might be causing this?
> >
> > I wonder if this is due to the O= argument.
> >
> > Last week I noticed that some TARGETs explicitly have support for
> > this, like x86. Added in 2016 in commit a8ba798bc8ec6 ("selftests:
> > enable O and KBUILD_OUTPUT"). But by now this support is hardly
> > universal. amd-pstate does not have this infra, for instance.
> >
> > Though if the only breakage is in net/lib, then that does not explain it 
> > fully.
>
> Some funny business with this install target, I haven't investigated
> fully but the dependency on all doesn't seem to do its job, and the
> install target has a copy/paste of all with this line missing:
>
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index 3b7df5477317..3aee8e7b9993 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -261,6 +261,7 @@ ifdef INSTALL_PATH
> @ret=1; \
> for TARGET in $(TARGETS) $(INSTALL_DEP_TARGETS); do \
> BUILD_TARGET=$$BUILD/$$TARGET;  \
> +   mkdir -p $$BUILD_TARGET;\
> $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install \
> INSTALL_PATH=$(INSTALL_PATH)/$$TARGET \
> SRC_PATH=$(shell readlink -e $$(pwd)) \
>
>
> Andres, please feel free to test / write commit message and submit this
> one liner, but even with that the build for some targets fails for me.

Thank you Jakub, that solved this issue, I'll send a patch shortly.

> "make [..] install" seems wobbly.

Yes it is.

Cheers,
Anders



Re: [PATCH] selftests: Makefile: add missing 'net/lib' to targets

2024-09-14 Thread Anders Roxell
On Thu, 12 Sept 2024 at 17:23, Jakub Kicinski  wrote:
>
> On Thu, 12 Sep 2024 08:31:18 +0200 Anders Roxell wrote:
> > Fixes: 1d0dc857b5d8 ("selftests: drv-net: add checksum tests")
> > Signed-off-by: Anders Roxell 
> > ---
> >  tools/testing/selftests/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/tools/testing/selftests/Makefile 
> > b/tools/testing/selftests/Makefile
> > index 3b7df5477317..fc3681270afe 100644
> > --- a/tools/testing/selftests/Makefile
> > +++ b/tools/testing/selftests/Makefile
> > @@ -64,6 +64,7 @@ TARGETS += net
> >  TARGETS += net/af_unix
> >  TARGETS += net/forwarding
> >  TARGETS += net/hsr
> > +TARGETS += net/lib
> >  TARGETS += net/mptcp
> >  TARGETS += net/netfilter
> >  TARGETS += net/openvswitch
>
> Please make sure you always include a commit message. Among other
> things writing one would force you to understand the code, and
> in this case understand that this target is intentionally left out.
> Look around the Makefile for references to net/lib, you'll figure
> it out.
>
> The patch is incorrect.

You’re right, the patch is incorrect, I could have explained better.
I’m seeing an issue with an out-of-tree cross compilation build of
kselftest and can’t figure out what’s wrong.

make --keep-going --jobs=32 O=/tmp/build
INSTALL_PATH=/tmp/build/kselftest_install \
 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
 CROSS_COMPILE_COMPAT=arm-linux-gnueabihf- kselftest-install

[...]
make[4]: Entering directory
'/home/anders/src/kernel/linux/tools/testing/selftests/net/lib'
  CC   csum
/usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld:
cannot open output file /tmp/build/kselftest/net/lib/csum: No such
file or directory
collect2: error: ld returned 1 exit status
[...]

Any thoughts on what might be causing this?

Cheers,
Anders



[PATCH] selftests: Makefile: add missing 'net/lib' to targets

2024-09-11 Thread Anders Roxell
Fixes: 1d0dc857b5d8 ("selftests: drv-net: add checksum tests")
Signed-off-by: Anders Roxell 
---
 tools/testing/selftests/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 3b7df5477317..fc3681270afe 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -64,6 +64,7 @@ TARGETS += net
 TARGETS += net/af_unix
 TARGETS += net/forwarding
 TARGETS += net/hsr
+TARGETS += net/lib
 TARGETS += net/mptcp
 TARGETS += net/netfilter
 TARGETS += net/openvswitch
-- 
2.45.2




backport patches to linux-5.4.y

2021-04-13 Thread Anders Roxell
Hi,

Can these patches be backported to linux-5.4.y, I've tried to build
perf on arm and it failed without these patches.
fc8c0a992233 ("perf tools: Use %define api.pure full instead of %pure-parser")
20befbb10803 ("perf tools: Use %zd for size_t printf formats on 32-bit")
77d02bd00cea ("perf map: Tighten snprintf() string precision to pass
gcc check on some 32-bit arches")



Commit fc8c0a992233 ("perf tools: Use %define api.pure full instead of
%pure-parser") fixes:

util/parse-events.y:1.1-12: warning: deprecated directive:
'%pure-parser', use '%define api.pure' [-Wdeprecated]
1 | %pure-parser
  | ^~~~
  | %define api.pure

Commit 20befbb10803 ("perf tools: Use %zd for size_t printf formats on
32-bit") fixes:

In file included from util/session.c:17:
util/session.c: In function 'perf_session__process_compressed_event':
util/session.c:91:11: error: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
   91 |  pr_debug("decomp (B): %ld to %ld\n", src_size, decomp_size);
  |   ^~
util/debug.h:16:21: note: in definition of macro 'pr_fmt'
   16 | #define pr_fmt(fmt) fmt
  | ^~~
util/session.c:91:2: note: in expansion of macro 'pr_debug'
   91 |  pr_debug("decomp (B): %ld to %ld\n", src_size, decomp_size);
  |  ^~~~

Commit 77d02bd00cea ("perf map: Tighten snprintf() string precision to
pass gcc check on some 32-bit arches") fixes:

util/map.c: In function 'map__new':
util/map.c:125:5: error: '%s' directive output may be truncated
writing between 1 and 2147483645 bytes into a region of size 4096
[-Werror=format-truncation=]
  125 |"%s/platforms/%s/arch-%s/usr/lib/%s",
  | ^~
In file included from /usr/arm-linux-gnueabihf/include/stdio.h:867,
 from util/symbol.h:11,
 from util/map.c:2:
/usr/arm-linux-gnueabihf/include/bits/stdio2.h:67:10: note:
'__builtin___snprintf_chk' output 32 or more bytes (assuming
4294967321) into a destination of size 4096
   67 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
  |  ^~~~
   68 |__bos (__s), __fmt, __va_arg_pack ());
  |~


Cheers,
Anders


Re: [PATCH 5.11 225/254] arm64/mm: define arch_get_mappable_range()

2021-03-29 Thread Anders Roxell
On Mon, 29 Mar 2021 at 13:35, Greg Kroah-Hartman
 wrote:
>
> On Mon, Mar 29, 2021 at 01:06:47PM +0200, Anders Roxell wrote:
> > On Mon, 29 Mar 2021 at 12:13, Greg Kroah-Hartman
> >  wrote:
> > >
> > > On Mon, Mar 29, 2021 at 03:05:25PM +0530, Naresh Kamboju wrote:
> > > > On Mon, 29 Mar 2021 at 14:10, Greg Kroah-Hartman
> > > >  wrote:
> > > > >
> > > > > From: Anshuman Khandual 
> > > > >
> > > > > [ Upstream commit 03aaf83fba6e5af08b5dd174c72edee9b7d9ed9b ]
> > > > >
> > > > > This overrides arch_get_mappable_range() on arm64 platform which will 
> > > > > be
> > > > > used with recently added generic framework.  It drops
> > > > > inside_linear_region() and subsequent check in arch_add_memory() 
> > > > > which are
> > > > > no longer required.  It also adds a VM_BUG_ON() check that would 
> > > > > ensure
> > > > > that mhp_range_allowed() has already been called.
> > > > >
> > > > > Link: 
> > > > > https://lkml.kernel.org/r/1612149902-7867-3-git-send-email-anshuman.khand...@arm.com
> > > > > Signed-off-by: Anshuman Khandual 
> > > > > Reviewed-by: David Hildenbrand 
> > > > > Reviewed-by: Catalin Marinas 
> > > > > Cc: Will Deacon 
> > > > > Cc: Ard Biesheuvel 
> > > > > Cc: Mark Rutland 
> > > > > Cc: Heiko Carstens 
> > > > > Cc: Jason Wang 
> > > > > Cc: Jonathan Cameron 
> > > > > Cc: "Michael S. Tsirkin" 
> > > > > Cc: Michal Hocko 
> > > > > Cc: Oscar Salvador 
> > > > > Cc: Pankaj Gupta 
> > > > > Cc: Pankaj Gupta 
> > > > > Cc: teawater 
> > > > > Cc: Vasily Gorbik 
> > > > > Cc: Wei Yang 
> > > > > Signed-off-by: Andrew Morton 
> > > > > Signed-off-by: Linus Torvalds 
> > > > > Signed-off-by: Sasha Levin 
> > > > > ---
> > > > >  arch/arm64/mm/mmu.c | 15 +++
> > > > >  1 file changed, 7 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > > > index 6f0648777d34..92b3be127796 100644
> > > > > --- a/arch/arm64/mm/mmu.c
> > > > > +++ b/arch/arm64/mm/mmu.c
> > > > > @@ -1443,16 +1443,19 @@ static void __remove_pgd_mapping(pgd_t 
> > > > > *pgdir, unsigned long start, u64 size)
> > > > > free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
> > > > >  }
> > > > >
> > > > > -static bool inside_linear_region(u64 start, u64 size)
> > > > > +struct range arch_get_mappable_range(void)
> > > > >  {
> > > > > +   struct range mhp_range;
> > > > > +
> > > > > /*
> > > > >  * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END 
> > > > > - 1)]
> > > > >  * accommodating both its ends but excluding PAGE_END. Max 
> > > > > physical
> > > > >  * range which can be mapped inside this linear mapping 
> > > > > range, must
> > > > >  * also be derived from its end points.
> > > > >  */
> > > > > -   return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> > > > > -  (start + size - 1) <= __pa(PAGE_END - 1);
> > > > > +   mhp_range.start = __pa(_PAGE_OFFSET(vabits_actual));
> > > > > +   mhp_range.end =  __pa(PAGE_END - 1);
> > > > > +   return mhp_range;
> > > > >  }
> > > > >
> > > > >  int arch_add_memory(int nid, u64 start, u64 size,
> > > > > @@ -1460,11 +1463,7 @@ int arch_add_memory(int nid, u64 start, u64 
> > > > > size,
> > > > >  {
> > > > > int ret, flags = 0;
> > > > >
> > > > > -   if (!inside_linear_region(start, size)) {
> > > > > -   pr_err("[%llx %llx] is outside linear mapping 
> > > > > region\n", start, start + size);
> > > > > -   return -EINVAL;
> > > > > -   }
> > > > > -
> > > > > +   VM_BUG_ON(!mhp_range_allowed(start, size, true));
> > > > >

Re: [PATCH 5.11 225/254] arm64/mm: define arch_get_mappable_range()

2021-03-29 Thread Anders Roxell
On Mon, 29 Mar 2021 at 12:13, Greg Kroah-Hartman
 wrote:
>
> On Mon, Mar 29, 2021 at 03:05:25PM +0530, Naresh Kamboju wrote:
> > On Mon, 29 Mar 2021 at 14:10, Greg Kroah-Hartman
> >  wrote:
> > >
> > > From: Anshuman Khandual 
> > >
> > > [ Upstream commit 03aaf83fba6e5af08b5dd174c72edee9b7d9ed9b ]
> > >
> > > This overrides arch_get_mappable_range() on arm64 platform which will be
> > > used with recently added generic framework.  It drops
> > > inside_linear_region() and subsequent check in arch_add_memory() which are
> > > no longer required.  It also adds a VM_BUG_ON() check that would ensure
> > > that mhp_range_allowed() has already been called.
> > >
> > > Link: 
> > > https://lkml.kernel.org/r/1612149902-7867-3-git-send-email-anshuman.khand...@arm.com
> > > Signed-off-by: Anshuman Khandual 
> > > Reviewed-by: David Hildenbrand 
> > > Reviewed-by: Catalin Marinas 
> > > Cc: Will Deacon 
> > > Cc: Ard Biesheuvel 
> > > Cc: Mark Rutland 
> > > Cc: Heiko Carstens 
> > > Cc: Jason Wang 
> > > Cc: Jonathan Cameron 
> > > Cc: "Michael S. Tsirkin" 
> > > Cc: Michal Hocko 
> > > Cc: Oscar Salvador 
> > > Cc: Pankaj Gupta 
> > > Cc: Pankaj Gupta 
> > > Cc: teawater 
> > > Cc: Vasily Gorbik 
> > > Cc: Wei Yang 
> > > Signed-off-by: Andrew Morton 
> > > Signed-off-by: Linus Torvalds 
> > > Signed-off-by: Sasha Levin 
> > > ---
> > >  arch/arm64/mm/mmu.c | 15 +++
> > >  1 file changed, 7 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > index 6f0648777d34..92b3be127796 100644
> > > --- a/arch/arm64/mm/mmu.c
> > > +++ b/arch/arm64/mm/mmu.c
> > > @@ -1443,16 +1443,19 @@ static void __remove_pgd_mapping(pgd_t *pgdir, 
> > > unsigned long start, u64 size)
> > > free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
> > >  }
> > >
> > > -static bool inside_linear_region(u64 start, u64 size)
> > > +struct range arch_get_mappable_range(void)
> > >  {
> > > +   struct range mhp_range;
> > > +
> > > /*
> > >  * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 
> > > 1)]
> > >  * accommodating both its ends but excluding PAGE_END. Max 
> > > physical
> > >  * range which can be mapped inside this linear mapping range, 
> > > must
> > >  * also be derived from its end points.
> > >  */
> > > -   return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> > > -  (start + size - 1) <= __pa(PAGE_END - 1);
> > > +   mhp_range.start = __pa(_PAGE_OFFSET(vabits_actual));
> > > +   mhp_range.end =  __pa(PAGE_END - 1);
> > > +   return mhp_range;
> > >  }
> > >
> > >  int arch_add_memory(int nid, u64 start, u64 size,
> > > @@ -1460,11 +1463,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
> > >  {
> > > int ret, flags = 0;
> > >
> > > -   if (!inside_linear_region(start, size)) {
> > > -   pr_err("[%llx %llx] is outside linear mapping region\n", 
> > > start, start + size);
> > > -   return -EINVAL;
> > > -   }
> > > -
> > > +   VM_BUG_ON(!mhp_range_allowed(start, size, true));
> > > if (rodata_full || debug_pagealloc_enabled())
> > > flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
> >
> > The stable rc 5.10 and 5.11 builds failed for arm64 architecture
> > due to below warnings / errors,
> >
> > > Anshuman Khandual 
> > > arm64/mm: define arch_get_mappable_range()
> >
> >
> >   arch/arm64/mm/mmu.c: In function 'arch_add_memory':
> >   arch/arm64/mm/mmu.c:1483:13: error: implicit declaration of function
> > 'mhp_range_allowed'; did you mean 'cpu_map_prog_allowed'?
> > [-Werror=implicit-function-declaration]
> > VM_BUG_ON(!mhp_range_allowed(start, size, true));
> >^
> >   include/linux/build_bug.h:30:63: note: in definition of macro
> > 'BUILD_BUG_ON_INVALID'
> >#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e
> >  ^
> >   arch/arm64/mm/mmu.c:1483:2: note: in expansion of macro 'VM_BUG_ON'
> > VM_BUG_ON(!mhp_range_allowed(start, size, true));
> > ^
> >
> > Build link,
> > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.11/DISTRO=lkft,MACHINE=juno,label=docker-buster-lkft/41/consoleText
> > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/DISTRO=lkft,MACHINE=dragonboard-410c,label=docker-buster-lkft/120/consoleFull
>
> thanks, will go drop this, and the patch that was after it in the
> series, from both trees and will push out a -rc2.
>
> Note, I used tuxbuild before doing this release, and it does not show
> this error in the arm64 defconfigs. What config did you use to trigger
> this?

We have a build with CONFIG_MEMORY_HOTPLUG=y enabled too.

This is a way to reproduce it locally:
tuxmake --runtime podman --target-arch arm64 --toolchain gcc --kconfig
defconfig --kconfig-add CONFIG_MEMORY_HOTPLUG=y

Cheers,
Anders


Re: [PATCH v8] mm: cma: support sysfs

2021-03-26 Thread Anders Roxell
On Thu, 25 Mar 2021 at 00:09, Minchan Kim  wrote:
>
> Since CMA is getting used more widely, it's more important to
> keep monitoring CMA statistics for system health since it's
> directly related to user experience.
>
> This patch introduces sysfs statistics for CMA, in order to provide
> some basic monitoring of the CMA allocator.
>
>  * the number of CMA page successful allocations
>  * the number of CMA page allocation failures
>
> These two values allow the user to calcuate the allocation
> failure rate for each CMA area.
>
> e.g.)
>   /sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail]
>   /sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail]
>   /sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]
>
> The cma_stat was intentionally allocated by dynamic allocation
> to harmonize with kobject lifetime management.
> https://lore.kernel.org/linux-mm/ycoamxqt6dzkc...@kroah.com/
>
> Tested-by: Dmitry Osipenko 
> Reviewed-by: Dmitry Osipenko 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: John Hubbard 
> Link: 
> https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.k...@canonical.com/
> Addresses-Coverity: ("Dereference after null check")
> Signed-off-by: Colin Ian King 
> Signed-off-by: Minchan Kim 

Tested-by: Anders Roxell 


Re: [PATCH v8] mm: cma: support sysfs

2021-03-26 Thread Anders Roxell
On Fri, 26 Mar 2021 at 16:51, Minchan Kim  wrote:
>
> On Fri, Mar 26, 2021 at 02:59:30PM +0100, Anders Roxell wrote:
> > On Thu, 25 Mar 2021 at 00:09, Minchan Kim  wrote:
> > >
> > > Since CMA is getting used more widely, it's more important to
> > > keep monitoring CMA statistics for system health since it's
> > > directly related to user experience.
> > >
> > > This patch introduces sysfs statistics for CMA, in order to provide
> > > some basic monitoring of the CMA allocator.
> > >
> > >  * the number of CMA page successful allocations
> > >  * the number of CMA page allocation failures
> > >
> > > These two values allow the user to calcuate the allocation
> > > failure rate for each CMA area.
> > >
> > > e.g.)
> > >   /sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail]
> > >   /sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail]
> > >   /sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]
> > >
> > > The cma_stat was intentionally allocated by dynamic allocation
> > > to harmonize with kobject lifetime management.
> > > https://lore.kernel.org/linux-mm/ycoamxqt6dzkc...@kroah.com/
> > >
> > > Tested-by: Dmitry Osipenko 
> > > Reviewed-by: Dmitry Osipenko 
> > > Reviewed-by: Greg Kroah-Hartman 
> > > Reviewed-by: John Hubbard 
> > > Link: 
> > > https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.k...@canonical.com/
> > > Addresses-Coverity: ("Dereference after null check")
> > > Signed-off-by: Colin Ian King 
> > > Signed-off-by: Minchan Kim 
> >
> > When I build an arm64 kernel (allmodconfig - boot selftest) on today's
> > next tag: next-20210326, I see this issue when I'm booting in qemu.
> >
> > [0.985891][T9] Callback from call_rcu_tasks() invoked.
> > [1.008860][T1] smp: Bringing up secondary CPUs ...
> > [1.012655][T1] smp: Brought up 1 node, 1 CPU
> > [1.015194][T1] SMP: Total of 1 processors activated.
> > [1.018987][T1] CPU features: detected: 32-bit EL0 Support
> > [1.021995][T1] CPU features: detected: CRC32 instructions
> > [1.026047][T1] CPU features: detected: 32-bit EL1 Support
> > [1.033728][T1] CPU features: emulated: Privileged Access Never
> > (PAN) using TTBR0_EL1 switching
> > [2.140828][T1] CPU: All CPU(s) started at EL1
> > [2.144773][   T17] alternatives: patching kernel code
> > [  132.866390][C0] watchdog: BUG: soft lockup - CPU#0 stuck for
> > 25s! [pgdatinit0:20]
> > [  132.870865][C0] Modules linked in:
> > [  132.873037][C0] irq event stamp: 739758
> > [  132.875308][C0] hardirqs last  enabled at (739757):
> > [] _raw_spin_unlock_irqrestore+0x90/0x100
> > [  132.880740][C0] hardirqs last disabled at (739758):
> > [] enter_el1_irq_or_nmi+0xa4/0xc0
> > [  132.885801][C0] softirqs last  enabled at (739056):
> > [] __do_softirq+0x8b8/0x9ac
> > [  132.890571][C0] softirqs last disabled at (739051):
> > [] __irq_exit_rcu+0x1ac/0x240
> > [  132.895560][C0] CPU: 0 PID: 20 Comm: pgdatinit0 Not tainted
> > 5.12.0-rc4-next-20210326-8-g23921ff47279 #1
> > [  132.900759][C0] Hardware name: linux,dummy-virt (DT)
> > [  132.903637][C0] pstate: 4045 (nZcv daif +PAN -UAO -TCO BTYPE=--)
> > [  132.907212][C0] pc : _raw_spin_unlock_irqrestore+0xa4/0x100
> > [  132.910432][C0] lr : _raw_spin_unlock_irqrestore+0x90/0x100
> > [  132.913647][C0] sp : 07b9f640
> > [  132.915832][C0] x29: 07b9f640 x28: 800016954518
> > [  132.919237][C0] x27: 000e x26: dead0100
> > [  132.922689][C0] x25: dead0122 x24: 000559b0
> > [  132.926098][C0] x23: 80001550e000 x22: 800016954530
> > [  132.929479][C0] x21: 800016954518 x20: 
> > [  132.932901][C0] x19: 800010f662f4 x18: 1530
> > [  132.936312][C0] x17: 1470 x16: 5518
> > [  132.939723][C0] x15: 1578 x14: 800010189520
> > [  132.943107][C0] x13: 8000107592e0 x12: 60f73eb1
> > [  132.946520][C0] x11: 1fffe0f73eb0 x10: 60f73eb0
> > [  132.949914][C0] x9 : dfff8000 x8 : 07b9f587
> > [  132.953312][C0] x7 : 0001 x6 : 9f08c150
> > [  132.956713][C0] x5 :  x4 : 
> > [  132.960117][C0] x3 : 07b90040 x2 : 00

Re: [PATCH v8] mm: cma: support sysfs

2021-03-26 Thread Anders Roxell
On Thu, 25 Mar 2021 at 00:09, Minchan Kim  wrote:
>
> Since CMA is getting used more widely, it's more important to
> keep monitoring CMA statistics for system health since it's
> directly related to user experience.
>
> This patch introduces sysfs statistics for CMA, in order to provide
> some basic monitoring of the CMA allocator.
>
>  * the number of CMA page successful allocations
>  * the number of CMA page allocation failures
>
> These two values allow the user to calcuate the allocation
> failure rate for each CMA area.
>
> e.g.)
>   /sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail]
>   /sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail]
>   /sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]
>
> The cma_stat was intentionally allocated by dynamic allocation
> to harmonize with kobject lifetime management.
> https://lore.kernel.org/linux-mm/ycoamxqt6dzkc...@kroah.com/
>
> Tested-by: Dmitry Osipenko 
> Reviewed-by: Dmitry Osipenko 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: John Hubbard 
> Link: 
> https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.k...@canonical.com/
> Addresses-Coverity: ("Dereference after null check")
> Signed-off-by: Colin Ian King 
> Signed-off-by: Minchan Kim 

When I build an arm64 kernel (allmodconfig - boot selftest) on today's
next tag: next-20210326, I see this issue when I'm booting in qemu.

[0.985891][T9] Callback from call_rcu_tasks() invoked.
[1.008860][T1] smp: Bringing up secondary CPUs ...
[1.012655][T1] smp: Brought up 1 node, 1 CPU
[1.015194][T1] SMP: Total of 1 processors activated.
[1.018987][T1] CPU features: detected: 32-bit EL0 Support
[1.021995][T1] CPU features: detected: CRC32 instructions
[1.026047][T1] CPU features: detected: 32-bit EL1 Support
[1.033728][T1] CPU features: emulated: Privileged Access Never
(PAN) using TTBR0_EL1 switching
[2.140828][T1] CPU: All CPU(s) started at EL1
[2.144773][   T17] alternatives: patching kernel code
[  132.866390][C0] watchdog: BUG: soft lockup - CPU#0 stuck for
25s! [pgdatinit0:20]
[  132.870865][C0] Modules linked in:
[  132.873037][C0] irq event stamp: 739758
[  132.875308][C0] hardirqs last  enabled at (739757):
[] _raw_spin_unlock_irqrestore+0x90/0x100
[  132.880740][C0] hardirqs last disabled at (739758):
[] enter_el1_irq_or_nmi+0xa4/0xc0
[  132.885801][C0] softirqs last  enabled at (739056):
[] __do_softirq+0x8b8/0x9ac
[  132.890571][C0] softirqs last disabled at (739051):
[] __irq_exit_rcu+0x1ac/0x240
[  132.895560][C0] CPU: 0 PID: 20 Comm: pgdatinit0 Not tainted
5.12.0-rc4-next-20210326-8-g23921ff47279 #1
[  132.900759][C0] Hardware name: linux,dummy-virt (DT)
[  132.903637][C0] pstate: 4045 (nZcv daif +PAN -UAO -TCO BTYPE=--)
[  132.907212][C0] pc : _raw_spin_unlock_irqrestore+0xa4/0x100
[  132.910432][C0] lr : _raw_spin_unlock_irqrestore+0x90/0x100
[  132.913647][C0] sp : 07b9f640
[  132.915832][C0] x29: 07b9f640 x28: 800016954518
[  132.919237][C0] x27: 000e x26: dead0100
[  132.922689][C0] x25: dead0122 x24: 000559b0
[  132.926098][C0] x23: 80001550e000 x22: 800016954530
[  132.929479][C0] x21: 800016954518 x20: 
[  132.932901][C0] x19: 800010f662f4 x18: 1530
[  132.936312][C0] x17: 1470 x16: 5518
[  132.939723][C0] x15: 1578 x14: 800010189520
[  132.943107][C0] x13: 8000107592e0 x12: 60f73eb1
[  132.946520][C0] x11: 1fffe0f73eb0 x10: 60f73eb0
[  132.949914][C0] x9 : dfff8000 x8 : 07b9f587
[  132.953312][C0] x7 : 0001 x6 : 9f08c150
[  132.956713][C0] x5 :  x4 : 
[  132.960117][C0] x3 : 07b90040 x2 : 0005e6fd
[  132.963521][C0] x1 : 00c0 x0 : 0080
[  132.966889][C0] Call trace:
[  132.968667][C0]  _raw_spin_unlock_irqrestore+0xa4/0x100
[  132.971754][C0]  __debug_check_no_obj_freed+0x1d4/0x2a0
[  132.974890][C0]  debug_check_no_obj_freed+0x20/0x80
[  132.977813][C0]  __free_pages_ok+0x5a0/0x740
[  132.980384][C0]  __free_pages_core+0x24c/0x280
[  132.983091][C0]  deferred_free_range+0x6c/0xbc
[  132.985826][C0]  deferred_init_maxorder+0x2d0/0x350
[  132.988735][C0]  deferred_init_memmap_chunk+0xc8/0x124
[  132.991784][C0]  padata_do_multithreaded+0x15c/0x578
[  132.994723][C0]  deferred_init_memmap+0x26c/0x364
[  132.997560][C0]  kthread+0x23c/0x260
[  132.999851][C0]  ret_from_fork+0x10/0x18
[  133.002324][C0] Kernel panic - not syncing: softlockup: hung tasks
[  133.005767][C0] CPU: 0 PID: 20 Comm: pgdatinit0 Tainted: G
   L5.12.0-rc4-next-20210326-8-g23921ff47279 #1
[  133.011613][C0] Hardware name: linux,dummy-virt (DT)
[  133.014435][C0] 

[PATCH] arm64: defconfig: enable modern virtio pci device

2021-02-10 Thread Anders Roxell
Since patch ("virtio-pci: introduce modern device module") got added it
is not possible to boot a defconfig kernel in qemu with a virtio pci
device.  Add CONFIG_VIRTIO_PCI_MODERN=y fragment makes the kernel able
to boot.

Signed-off-by: Anders Roxell 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 arch/arm64/configs/defconfig| 1 +
 arch/mips/configs/loongson3_defconfig   | 1 +
 arch/mips/configs/malta_kvm_guest_defconfig | 1 +
 arch/powerpc/configs/guest.config   | 1 +
 arch/riscv/configs/defconfig| 1 +
 arch/riscv/configs/rv32_defconfig   | 1 +
 arch/xtensa/configs/virt_defconfig  | 1 +
 kernel/configs/kvm_guest.config | 1 +
 9 files changed, 9 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 3823da605430..02297ed49b20 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -972,6 +972,7 @@ CONFIG_DW_DMAC=y
 CONFIG_RCAR_DMAC=y
 CONFIG_RENESAS_USB_DMAC=m
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_STAGING=y
 CONFIG_MFD_NVEC=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 83c28da85834..8334e9cb4608 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -910,6 +910,7 @@ CONFIG_TI_K3_UDMA_GLUE_LAYER=y
 CONFIG_VFIO=y
 CONFIG_VFIO_PCI=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_XEN_GNTDEV=y
diff --git a/arch/mips/configs/loongson3_defconfig 
b/arch/mips/configs/loongson3_defconfig
index 0e79f81217bc..ac5f2dcbffb1 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -324,6 +324,7 @@ CONFIG_RTC_DRV_CMOS=y
 CONFIG_RTC_DRV_GOLDFISH=y
 CONFIG_DMADEVICES=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=m
 CONFIG_VIRTIO_INPUT=y
 CONFIG_VIRTIO_MMIO=y
diff --git a/arch/mips/configs/malta_kvm_guest_defconfig 
b/arch/mips/configs/malta_kvm_guest_defconfig
index 9185e0a0aa45..043633cdb406 100644
--- a/arch/mips/configs/malta_kvm_guest_defconfig
+++ b/arch/mips/configs/malta_kvm_guest_defconfig
@@ -332,6 +332,7 @@ CONFIG_RTC_DRV_CMOS=y
 CONFIG_UIO=m
 CONFIG_UIO_CIF=m
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_EXT2_FS=y
diff --git a/arch/powerpc/configs/guest.config 
b/arch/powerpc/configs/guest.config
index 209f58515d88..fbff632c8633 100644
--- a/arch/powerpc/configs/guest.config
+++ b/arch/powerpc/configs/guest.config
@@ -5,6 +5,7 @@ CONFIG_NET_FAILOVER=y
 CONFIG_VIRTIO_CONSOLE=y
 CONFIG_VIRTIO=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_KVM_GUEST=y
 CONFIG_EPAPR_PARAVIRT=y
 CONFIG_VIRTIO_BALLOON=y
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 8c3d1e451703..b7fa7a1a0c6d 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -85,6 +85,7 @@ CONFIG_MMC=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_INPUT=y
 CONFIG_VIRTIO_MMIO=y
diff --git a/arch/riscv/configs/rv32_defconfig 
b/arch/riscv/configs/rv32_defconfig
index 2c2cda6cc1c5..68296101fa06 100644
--- a/arch/riscv/configs/rv32_defconfig
+++ b/arch/riscv/configs/rv32_defconfig
@@ -84,6 +84,7 @@ CONFIG_MMC=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_INPUT=y
 CONFIG_VIRTIO_MMIO=y
diff --git a/arch/xtensa/configs/virt_defconfig 
b/arch/xtensa/configs/virt_defconfig
index 6d1387dfa96f..7fad1c2454fd 100644
--- a/arch/xtensa/configs/virt_defconfig
+++ b/arch/xtensa/configs/virt_defconfig
@@ -74,6 +74,7 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_INPUT=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
diff --git a/kernel/configs/kvm_guest.config b/kernel/configs/kvm_guest.config
index 208481d91090..8dea6df20006 100644
--- a/kernel/configs/kvm_guest.config
+++ b/kernel/configs/kvm_guest.config
@@ -22,6 +22,7 @@ CONFIG_S390_GUEST=y
 CONFIG_VIRTIO=y
 CONFIG_VIRTIO_MENU=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BLK=y
 CONFIG_VIRTIO_CONSOLE=y
 CONFIG_VIRTIO_NET=y
-- 
2.30.0



Re: [PATCH] mips: vdso: fix DWARF2 warning

2021-01-15 Thread Anders Roxell
On Fri, 15 Jan 2021 at 20:28, Nathan Chancellor
 wrote:
>
> On Fri, Jan 15, 2021 at 08:13:30PM +0100, Anders Roxell wrote:
> > When building mips tinyconifg the following warning show up
> >
> > make --silent --keep-going --jobs=8 
> > O=/home/anders/src/kernel/next/out/builddir ARCH=mips 
> > CROSS_COMPILE=mips-linux-gnu- HOSTCC=clang CC=clang
> > /srv/src/kernel/next/arch/mips/vdso/elf.S:14:1: warning: DWARF2 only 
> > supports one section per compilation unit
> > .pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long 
> > 4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3:
> > ^
> > /srv/src/kernel/next/arch/mips/vdso/elf.S:34:2: warning: DWARF2 only 
> > supports one section per compilation unit
> >  .section .mips_abiflags, "a"
> >  ^
> >
> > Rework so the mips vdso Makefile adds flag '-no-integrated-as' unless
> > LLVM_IAS is defined.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1256
> > Cc: sta...@vger.kernel.org # v4.19+
> > Suggested-by: Nick Desaulniers 
> > Signed-off-by: Anders Roxell 
>
> I believe this is the better solution:
>
> https://lore.kernel.org/r/20210115192622.3828545-1-natechancel...@gmail.com/

Yes, I agree.

Cheers,
Anders


Re: [PATCH] MIPS: VDSO: Use CLANG_FLAGS instead of filtering out '--target='

2021-01-15 Thread Anders Roxell
On Fri, 15 Jan 2021 at 20:26, Nathan Chancellor
 wrote:
>
> Commit ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO
> cflags") allowed the '--target=' flag from the main Makefile to filter
> through to the vDSO. However, it did not bring any of the other clang
> specific flags for controlling the integrated assembler and the GNU
> tools locations (--prefix=, --gcc-toolchain=, and -no-integrated-as).
> Without these, we will get a warning (visible with tinyconfig):
>
> arch/mips/vdso/elf.S:14:1: warning: DWARF2 only supports one section per
> compilation unit
> .pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long
> 4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3:
> ^
> arch/mips/vdso/elf.S:34:2: warning: DWARF2 only supports one section per
> compilation unit
>  .section .mips_abiflags, "a"
>  ^
>
> All of these flags are bundled up under CLANG_FLAGS in the main Makefile
> and exported so that they can be added to Makefiles that set their own
> CFLAGS. Use this value instead of filtering out '--target=' so there is
> no warning and all of the tools are properly used.
>
> Cc: sta...@vger.kernel.org
> Fixes: ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1256
> Reported-by: Anders Roxell 
> Signed-off-by: Nathan Chancellor 

Tested-by: Anders Roxell 

Cheers,
Anders

> ---
>  arch/mips/vdso/Makefile | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
> index 5810cc12bc1d..2131d3fd7333 100644
> --- a/arch/mips/vdso/Makefile
> +++ b/arch/mips/vdso/Makefile
> @@ -16,16 +16,13 @@ ccflags-vdso := \
> $(filter -march=%,$(KBUILD_CFLAGS)) \
> $(filter -m%-float,$(KBUILD_CFLAGS)) \
> $(filter -mno-loongson-%,$(KBUILD_CFLAGS)) \
> +   $(CLANG_FLAGS) \
> -D__VDSO__
>
>  ifndef CONFIG_64BIT
>  ccflags-vdso += -DBUILD_VDSO32
>  endif
>
> -ifdef CONFIG_CC_IS_CLANG
> -ccflags-vdso += $(filter --target=%,$(KBUILD_CFLAGS))
> -endif
> -
>  #
>  # The -fno-jump-tables flag only prevents the compiler from generating
>  # jump tables but does not prevent the compiler from emitting absolute
>
> base-commit: 7b490a8ab0f2d3ab8d838a4ff22ae86edafd34a1
> --
> 2.30.0
>


[PATCH] mips: vdso: fix DWARF2 warning

2021-01-15 Thread Anders Roxell
When building mips tinyconifg the following warning show up

make --silent --keep-going --jobs=8 O=/home/anders/src/kernel/next/out/builddir 
ARCH=mips CROSS_COMPILE=mips-linux-gnu- HOSTCC=clang CC=clang
/srv/src/kernel/next/arch/mips/vdso/elf.S:14:1: warning: DWARF2 only supports 
one section per compilation unit
.pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long 4484f - 
3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3:
^
/srv/src/kernel/next/arch/mips/vdso/elf.S:34:2: warning: DWARF2 only supports 
one section per compilation unit
 .section .mips_abiflags, "a"
 ^

Rework so the mips vdso Makefile adds flag '-no-integrated-as' unless
LLVM_IAS is defined.

Link: https://github.com/ClangBuiltLinux/linux/issues/1256
Cc: sta...@vger.kernel.org # v4.19+
Suggested-by: Nick Desaulniers 
Signed-off-by: Anders Roxell 
---
 arch/mips/vdso/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 5810cc12bc1d..83e8cf216ac8 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -26,6 +26,10 @@ ifdef CONFIG_CC_IS_CLANG
 ccflags-vdso += $(filter --target=%,$(KBUILD_CFLAGS))
 endif
 
+ifneq ($(LLVM_IAS),1)
+ccflags-vdso += -no-integrated-as
+endif
+
 #
 # The -fno-jump-tables flag only prevents the compiler from generating
 # jump tables but does not prevent the compiler from emitting absolute
-- 
2.29.2



[PATCH] mips: lib: uncached: fix non-standard usage of variable 'sp'

2021-01-15 Thread Anders Roxell
commit 5b058973d3205578aa6c9a71392e072a11ca44ef upstream.

When building mips tinyconfig with clang the following warning show up:

arch/mips/lib/uncached.c:45:6: warning: variable 'sp' is uninitialized when 
used here [-Wuninitialized]
if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
^~
arch/mips/lib/uncached.c:40:18: note: initialize the variable 'sp' to silence 
this warning
register long sp __asm__("$sp");
^
 = 0
1 warning generated.

Rework to make an explicit inline move, instead of the non-standard use
of specifying registers for local variables. This is what's written
from the gcc-10 manual [1] about specifying registers for local
variables:

"6.47.5.2 Specifying Registers for Local Variables
.
[...]

"The only supported use for this feature is to specify registers for
input and output operands when calling Extended 'asm' (*note Extended
Asm::).  [...]".

Cc:  # v5.4+
[1] https://docs.w3cub.com/gcc~10/local-register-variables
Signed-off-by: Anders Roxell 
Reported-by: Nathan Chancellor 
Reported-by: Naresh Kamboju 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/lib/uncached.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c
index 09d5deea747f..f80a67c092b6 100644
--- a/arch/mips/lib/uncached.c
+++ b/arch/mips/lib/uncached.c
@@ -37,10 +37,12 @@
  */
 unsigned long run_uncached(void *func)
 {
-   register long sp __asm__("$sp");
register long ret __asm__("$2");
long lfunc = (long)func, ufunc;
long usp;
+   long sp;
+
+   __asm__("move %0, $sp" : "=r" (sp));
 
if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
usp = CKSEG1ADDR(sp);
-- 
2.29.2



[PATCH] mips: fix Section mismatch in reference

2021-01-15 Thread Anders Roxell
commit ad4fddef5f2345aa9214e979febe2f47639c10d9 upstream.

When building mips tinyconfig with clang the following error show up:

WARNING: modpost: vmlinux.o(.text+0x1940c): Section mismatch in reference from 
the function r4k_cache_init() to the function .init.text:loongson3_sc_init()
The function r4k_cache_init() references
the function __init loongson3_sc_init().
This is often because r4k_cache_init lacks a __init
annotation or the annotation of loongson3_sc_init is wrong.

Remove marked __init from function loongson3_sc_init(),
mips_sc_probe_cm3(), and mips_sc_probe().

Cc:  # v5.4+
Signed-off-by: Anders Roxell 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/mm/c-r4k.c   | 2 +-
 arch/mips/mm/sc-mips.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 9cede7ce37e6..c9644c38ec28 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1609,7 +1609,7 @@ static void __init loongson2_sc_init(void)
c->options |= MIPS_CPU_INCLUSIVE_CACHES;
 }
 
-static void __init loongson3_sc_init(void)
+static void loongson3_sc_init(void)
 {
struct cpuinfo_mips *c = ¤t_cpu_data;
unsigned int config2, lsize;
diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
index dd0a5becaabd..06ec304ad4d1 100644
--- a/arch/mips/mm/sc-mips.c
+++ b/arch/mips/mm/sc-mips.c
@@ -146,7 +146,7 @@ static inline int mips_sc_is_activated(struct cpuinfo_mips 
*c)
return 1;
 }
 
-static int __init mips_sc_probe_cm3(void)
+static int mips_sc_probe_cm3(void)
 {
struct cpuinfo_mips *c = ¤t_cpu_data;
unsigned long cfg = read_gcr_l2_config();
@@ -180,7 +180,7 @@ static int __init mips_sc_probe_cm3(void)
return 0;
 }
 
-static inline int __init mips_sc_probe(void)
+static inline int mips_sc_probe(void)
 {
struct cpuinfo_mips *c = ¤t_cpu_data;
unsigned int config1, config2;
-- 
2.29.2



[PATCH v2] mips: lib: uncached: fix non-standard usage of variable 'sp'

2020-12-11 Thread Anders Roxell
When building mips tinyconfig with clang the following warning show up:

arch/mips/lib/uncached.c:45:6: warning: variable 'sp' is uninitialized when 
used here [-Wuninitialized]
if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
^~
arch/mips/lib/uncached.c:40:18: note: initialize the variable 'sp' to silence 
this warning
register long sp __asm__("$sp");
^
 = 0
1 warning generated.

Rework to make an explicit inline move, instead of the non-standard use
of specifying registers for local variables. This is what's written
from the gcc-10 manual [1] about specifying registers for local
variables:

"6.47.5.2 Specifying Registers for Local Variables
.
[...]

"The only supported use for this feature is to specify registers for
input and output operands when calling Extended 'asm' (*note Extended
Asm::).  [...]".

[1] https://docs.w3cub.com/gcc~10/local-register-variables
Signed-off-by: Anders Roxell 
---
 arch/mips/lib/uncached.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c
index 09d5deea747f..f80a67c092b6 100644
--- a/arch/mips/lib/uncached.c
+++ b/arch/mips/lib/uncached.c
@@ -37,10 +37,12 @@
  */
 unsigned long run_uncached(void *func)
 {
-   register long sp __asm__("$sp");
register long ret __asm__("$2");
long lfunc = (long)func, ufunc;
long usp;
+   long sp;
+
+   __asm__("move %0, $sp" : "=r" (sp));
 
if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
usp = CKSEG1ADDR(sp);
-- 
2.29.2



[PATCH] sh: kernel: traps: remove unused variable

2020-12-10 Thread Anders Roxell
When building defconfig the following warning shows up:

arch/sh/kernel/traps.c: In function 'nmi_trap_handler':
arch/sh/kernel/traps.c:183:15: warning: unused variable 'cpu' 
[-Wunused-variable]
  unsigned int cpu = smp_processor_id();
   ^~~

Remove an unused variable 'cpu'.

Fixes: fe3f1d5d7cd3 ("sh: Get rid of nmi_count()")
Signed-off-by: Anders Roxell 
---
 arch/sh/kernel/traps.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/sh/kernel/traps.c b/arch/sh/kernel/traps.c
index f5beecdac693..e76b22157099 100644
--- a/arch/sh/kernel/traps.c
+++ b/arch/sh/kernel/traps.c
@@ -180,7 +180,6 @@ static inline void arch_ftrace_nmi_exit(void) { }
 
 BUILD_TRAP_HANDLER(nmi)
 {
-   unsigned int cpu = smp_processor_id();
TRAP_HANDLER_DECL;
 
arch_ftrace_nmi_enter();
-- 
2.29.2



Re: [PATCH] mm/memblock:use a more appropriate order calculation when free memblock pages

2020-12-05 Thread Anders Roxell
On Fri, 4 Dec 2020 at 18:44, Jon Hunter  wrote:
>
>
> On 04/12/2020 16:07, Marek Szyprowski wrote:
> > Hi All,
> >
> > On 04.12.2020 14:42, Qian Cai wrote:
> >> On Thu, 2020-12-03 at 23:23 +0800, carver4...@163.com wrote:
> >>> From: Hailong Liu 
> >>>
> >>> When system in the booting stage, pages span from [start, end] of a 
> >>> memblock
> >>> are freed to buddy in a order as large as possible (less than MAX_ORDER) 
> >>> at
> >>> first, then decrease gradually to a proper order(less than end) in a loop.
> >>>
> >>> However, *min(MAX_ORDER - 1UL, __ffs(start))* can not get the largest 
> >>> order
> >>> in some cases.
> >>> Instead, *__ffs(end - start)* may be more appropriate and meaningful.
> >>>
> >>> Signed-off-by: Hailong Liu 
> >> Reverting this commit on the top of today's linux-next fixed boot crashes 
> >> on
> >> multiple NUMA systems.
> >
> > I confirm. Reverting commit 4df001639c84 ("mm/memblock: use a more
> > appropriate order calculation when free memblock pages") on top of linux
> > next-20201204 fixed booting of my ARM32bit test systems.
>
>
> FWIW, I also confirm that this is causing several 32-bit Tegra platforms
> to crash on boot and reverting this fixes the problem.

I had the same experience on an arm64 system.

Cheers,
Anders


Re: [PATCH] mm/memblock:use a more appropriate order calculation when free memblock pages

2020-12-05 Thread Anders Roxell
On Sat, 5 Dec 2020 at 18:09, Anders Roxell  wrote:
>
> On Fri, 4 Dec 2020 at 18:44, Jon Hunter  wrote:
> >
> >
> > On 04/12/2020 16:07, Marek Szyprowski wrote:
> > > Hi All,
> > >
> > > On 04.12.2020 14:42, Qian Cai wrote:
> > >> On Thu, 2020-12-03 at 23:23 +0800, carver4...@163.com wrote:
> > >>> From: Hailong Liu 
> > >>>
> > >>> When system in the booting stage, pages span from [start, end] of a 
> > >>> memblock
> > >>> are freed to buddy in a order as large as possible (less than 
> > >>> MAX_ORDER) at
> > >>> first, then decrease gradually to a proper order(less than end) in a 
> > >>> loop.
> > >>>
> > >>> However, *min(MAX_ORDER - 1UL, __ffs(start))* can not get the largest 
> > >>> order
> > >>> in some cases.
> > >>> Instead, *__ffs(end - start)* may be more appropriate and meaningful.
> > >>>
> > >>> Signed-off-by: Hailong Liu 
> > >> Reverting this commit on the top of today's linux-next fixed boot 
> > >> crashes on
> > >> multiple NUMA systems.
> > >
> > > I confirm. Reverting commit 4df001639c84 ("mm/memblock: use a more
> > > appropriate order calculation when free memblock pages") on top of linux
> > > next-20201204 fixed booting of my ARM32bit test systems.
> >
> >
> > FWIW, I also confirm that this is causing several 32-bit Tegra platforms
> > to crash on boot and reverting this fixes the problem.
>
> I had the same experience on an arm64 system.

This is the log that I see:

[0.00][T0] percpu: Embedded 507 pages/cpu s2036568 r8192
d31912 u2076672
[0.00][T0] Detected VIPT I-cache on CPU0
[0.00][T0] CPU features: detected: ARM erratum 845719
[0.00][T0] CPU features: GIC system register CPU interface
present but disabled by higher exception level
[0.00][T0] CPU features: kernel page table isolation
forced OFF by kpti command line option
[0.00][T0] Built 1 zonelists, mobility grouping on.  Total
pages: 516096
[0.00][T0] Policy zone: DMA
[0.00][T0] Kernel command line: root=/dev/root
rootfstype=9p rootflags=trans=virtio console=ttyAMA0,38400n8
earlycon=pl011,0x900 initcall_debug softlockup_panic=0
security=none kpti=no
[0.00][T0] Dentry cache hash table entries: 262144 (order:
9, 2097152 bytes, linear)
[0.00][T0] Inode-cache hash table entries: 131072 (order:
8, 1048576 bytes, linear)
[0.00][T0] mem auto-init: stack:off, heap alloc:on, heap free:on
[0.00][T0] mem auto-init: clearing system memory may take
some time...
[0.00][T0] page:(ptrval) refcount:0 mapcount:0
mapping: index:0x0 pfn:0x40010
[0.00][T0] flags: 0x1fffe00()
[0.00][T0] raw: 01fffe00 fc000408
fc000408 
[0.00][T0] raw:  
 
[0.00][T0] page dumped because: VM_BUG_ON_PAGE(pfn & ((1
<< order) - 1))
[0.00][T0] [ cut here ]
[0.00][T0] kernel BUG at mm/page_alloc.c:1015!
[0.00][T0] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[0.00][T0] Modules linked in:
[0.00][T0] CPU: 0 PID: 0 Comm: swapper Not tainted
5.10.0-rc6-next-20201204-00010-g7f8e9106f747-dirty #1
[0.00][T0] Hardware name: linux,dummy-virt (DT)
[0.00][T0] pstate: 40400085 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
[0.00][T0] pc : __free_one_page+0x14c/0x700
[0.00][T0] lr : __free_one_page+0x14c/0x700
[0.00][T0] sp : 800013fd7c10
[0.00][T0] x29: 800013fd7c10 x28: 
[0.00][T0] x27: 0200 x26: 0001
[0.00][T0] x25:  x24: 0009
[0.00][T0] x23: 7dbfbd40 x22: fc000400
[0.00][T0] x21: 00040010 x20: 0009
[0.00][T0] x19: 01ff x18: 
[0.00][T0] x17:  x16: 
[0.00][T0] x15:  x14: 
[0.00][T0] x13:  x12: 7281852d
[0.00][T0] x11: 1281852c x10: 7281852c
[0.00][T0] x9 : dfff8000 x8 : 8000140c2960
[0.00][T0] x7 : 0001 x6 : 8d7e7ad4
[0.00][T0] x5 :  x4 : 
[0.00][T0] x3 : 80001400ab00 x2 : 
[0.00][T0] x1 : 

[PATCH] kfence: fix implicit function declaration

2020-12-04 Thread Anders Roxell
When building kfence the following error shows up:

In file included from mm/kfence/report.c:13:
arch/arm64/include/asm/kfence.h: In function ‘kfence_protect_page’:
arch/arm64/include/asm/kfence.h:12:2: error: implicit declaration of function 
‘set_memory_valid’ [-Werror=implicit-function-declaration]
   12 |  set_memory_valid(addr, 1, !protect);
  |  ^~~~

Use the correct include both
f2b7c491916d ("set_memory: allow querying whether set_direct_map_*() is 
actually enabled")
and 4c4c75881536 ("arm64, kfence: enable KFENCE for ARM64") went in the
same day via different trees.

Signed-off-by: Anders Roxell 
---

I got this build error in todays next-20201204.
Andrew, since both patches are in your -mm tree, I think this can be
folded into 4c4c75881536 ("arm64, kfence: enable KFENCE for ARM64")

 arch/arm64/include/asm/kfence.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/kfence.h
index 6c0afeeab635..c44bb368a810 100644
--- a/arch/arm64/include/asm/kfence.h
+++ b/arch/arm64/include/asm/kfence.h
@@ -3,7 +3,7 @@
 #ifndef __ASM_KFENCE_H
 #define __ASM_KFENCE_H
 
-#include 
+#include 
 
 static inline bool arch_kfence_init_pool(void) { return true; }
 
-- 
2.29.2



[PATCH] dpaa_eth: fix build errorr in dpaa_fq_init

2020-12-03 Thread Anders Roxell
When building FSL_DPAA_ETH the following build error shows up:

/tmp/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c: In function ‘dpaa_fq_init’:
/tmp/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:1135:9: error: too few 
arguments to function ‘xdp_rxq_info_reg’
 1135 |   err = xdp_rxq_info_reg(&dpaa_fq->xdp_rxq, dpaa_fq->net_dev,
  | ^~~~

Commit b02e5a0ebb17 ("xsk: Propagate napi_id to XDP socket Rx path")
added an extra argument to function xdp_rxq_info_reg and commit
d57e57d0cd04 ("dpaa_eth: add XDP_TX support") didn't know about that
extra argument.

Signed-off-by: Anders Roxell 
---

I think this issue is seen since both patches went in at the same time
to bpf-next and net-next.

 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 947b3d2f9c7e..6cc8c4e078de 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1133,7 +1133,7 @@ static int dpaa_fq_init(struct dpaa_fq *dpaa_fq, bool 
td_enable)
if (dpaa_fq->fq_type == FQ_TYPE_RX_DEFAULT ||
dpaa_fq->fq_type == FQ_TYPE_RX_PCD) {
err = xdp_rxq_info_reg(&dpaa_fq->xdp_rxq, dpaa_fq->net_dev,
-  dpaa_fq->fqid);
+  dpaa_fq->fqid, 0);
if (err) {
dev_err(dev, "xdp_rxq_info_reg() = %d\n", err);
return err;
-- 
2.29.2



Re: [PATCH] drivers: hwmon: pwm-fan: fix warning unused variable 'ctx'

2020-11-30 Thread Anders Roxell
On Tue, 1 Dec 2020 at 01:49, Guenter Roeck  wrote:
>
> On Tue, Dec 01, 2020 at 01:31:18AM +0100, Anders Roxell wrote:
> > When building hwmon/pwm-fan the following unused-variable warning shows
> > up:
> >
> > /tmp/drivers/hwmon/pwm-fan.c: In function ‘pwm_fan_is_visible’:
> > /tmp/drivers/hwmon/pwm-fan.c:167:22: warning: unused variable ‘ctx’ 
> > [-Wunused-variable]
> >
> > Remove the unneeded variable declaration 'ctx'.
> >
> > Fixes: 439ed83acc19 ("hwmon: (pwm-fan) Convert to 
> > hwmon_device_register_with_info API")
> > Signed-off-by: Anders Roxell 
>
> I already folded this change into the original patch.

That's great Guenter, I missed that. I'm sorry for the noise.

Cheers,
Anders


Re: [PATCH] mips: lib: uncached: fix uninitialized variable 'sp'

2020-11-30 Thread Anders Roxell
On Mon, 30 Nov 2020 at 21:22, Nick Desaulniers  wrote:
>
> On Fri, Nov 27, 2020 at 12:39 AM Anders Roxell  
> wrote:
> >
> > When building mips tinyconfig with clang the following warning show up:
> >
> > /tmp/arch/mips/lib/uncached.c:40:18: note: initialize the variable 'sp' to 
> > silence this warning
> > register long sp __asm__("$sp");
> > ^
> >  = 0
>
> Hi Anders

Hi Nick,

>, thank you for sending the patch. Do you have the full text
> of the warning; it looks like only the note was included?

oops, looks like I missed this:

/srv/src/kernel/next/arch/mips/lib/uncached.c:45:6: warning: variable
'sp' is uninitialized when used here [-Wuninitialized]
if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
^~
/srv/src/kernel/next/arch/mips/lib/uncached.c:40:18: note: initialize
the variable 'sp' to silence this warning
register long sp __asm__("$sp");
^
         = 0
1 warning generated.

Cheers,
Anders

>
> >
> > Rework to make an explicit inline move.
> >
> > Signed-off-by: Anders Roxell 
> > ---
> >  arch/mips/lib/uncached.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c
> > index 09d5deea747f..21a4b94a0558 100644
> > --- a/arch/mips/lib/uncached.c
> > +++ b/arch/mips/lib/uncached.c
> > @@ -37,10 +37,11 @@
> >   */
> >  unsigned long run_uncached(void *func)
> >  {
> > -   register long sp __asm__("$sp");
> > register long ret __asm__("$2");
> > long lfunc = (long)func, ufunc;
> > long usp;
> > +   long sp;
> > +   asm ("move %0, $sp" : "=r" (sp));
> >
> > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
> > usp = CKSEG1ADDR(sp);
> > --
> > 2.29.2
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers


[PATCH] drivers: hwmon: pwm-fan: fix warning unused variable 'ctx'

2020-11-30 Thread Anders Roxell
When building hwmon/pwm-fan the following unused-variable warning shows
up:

/tmp/drivers/hwmon/pwm-fan.c: In function ‘pwm_fan_is_visible’:
/tmp/drivers/hwmon/pwm-fan.c:167:22: warning: unused variable ‘ctx’ 
[-Wunused-variable]

Remove the unneeded variable declaration 'ctx'.

Fixes: 439ed83acc19 ("hwmon: (pwm-fan) Convert to 
hwmon_device_register_with_info API")
Signed-off-by: Anders Roxell 
---
 drivers/hwmon/pwm-fan.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 57b574837b58..777439f48c14 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -164,8 +164,6 @@ static umode_t pwm_fan_is_visible(const void *data,
  enum hwmon_sensor_types type,
  u32 attr, int channel)
 {
-   struct pwm_fan_ctx *ctx = (struct pwm_fan_ctx *)data;
-
switch (type) {
case hwmon_pwm:
return 0644;
-- 
2.29.2



[PATCH] mips: fix Section mismatch in reference

2020-11-27 Thread Anders Roxell
When building mips tinyconfig with clang the following error show up:

WARNING: modpost: vmlinux.o(.text+0x1940c): Section mismatch in reference from 
the function r4k_cache_init() to the function .init.text:loongson3_sc_init()
The function r4k_cache_init() references
the function __init loongson3_sc_init().
This is often because r4k_cache_init lacks a __init
annotation or the annotation of loongson3_sc_init is wrong.

Remove marked __init from function loongson3_sc_init(),
mips_sc_probe_cm3(), and mips_sc_probe().

Signed-off-by: Anders Roxell 
---
 arch/mips/mm/c-r4k.c   | 2 +-
 arch/mips/mm/sc-mips.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 99521764c75b..4f976d687ab0 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1609,7 +1609,7 @@ static void __init loongson2_sc_init(void)
c->options |= MIPS_CPU_INCLUSIVE_CACHES;
 }
 
-static void __init loongson3_sc_init(void)
+static void loongson3_sc_init(void)
 {
struct cpuinfo_mips *c = ¤t_cpu_data;
unsigned int config2, lsize;
diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
index dd0a5becaabd..06ec304ad4d1 100644
--- a/arch/mips/mm/sc-mips.c
+++ b/arch/mips/mm/sc-mips.c
@@ -146,7 +146,7 @@ static inline int mips_sc_is_activated(struct cpuinfo_mips 
*c)
return 1;
 }
 
-static int __init mips_sc_probe_cm3(void)
+static int mips_sc_probe_cm3(void)
 {
struct cpuinfo_mips *c = ¤t_cpu_data;
unsigned long cfg = read_gcr_l2_config();
@@ -180,7 +180,7 @@ static int __init mips_sc_probe_cm3(void)
return 0;
 }
 
-static inline int __init mips_sc_probe(void)
+static inline int mips_sc_probe(void)
 {
struct cpuinfo_mips *c = ¤t_cpu_data;
unsigned int config1, config2;
-- 
2.29.2



[PATCH] mips: lib: uncached: fix uninitialized variable 'sp'

2020-11-27 Thread Anders Roxell
When building mips tinyconfig with clang the following warning show up:

/tmp/arch/mips/lib/uncached.c:40:18: note: initialize the variable 'sp' to 
silence this warning
register long sp __asm__("$sp");
^
 = 0

Rework to make an explicit inline move.

Signed-off-by: Anders Roxell 
---
 arch/mips/lib/uncached.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c
index 09d5deea747f..21a4b94a0558 100644
--- a/arch/mips/lib/uncached.c
+++ b/arch/mips/lib/uncached.c
@@ -37,10 +37,11 @@
  */
 unsigned long run_uncached(void *func)
 {
-   register long sp __asm__("$sp");
register long ret __asm__("$2");
long lfunc = (long)func, ufunc;
long usp;
+   long sp;
+   asm ("move %0, $sp" : "=r" (sp));
 
if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
usp = CKSEG1ADDR(sp);
-- 
2.29.2



Re: [PATCH] parisc: signal: remove _SA_SIGGFAULT

2020-11-26 Thread Anders Roxell
On Thu, 26 Nov 2020 at 15:46, Helge Deller  wrote:
>
> On 11/26/20 2:06 PM, Anders Roxell wrote:
> > When building tinyconfig on parisc the following error shows up:
> >
> > /tmp/kernel/signal.c: In function 'do_sigaction':
> > /tmp/arch/parisc/include/asm/signal.h:24:30: error: '_SA_SIGGFAULT' 
> > undeclared (first use in this function); did you mean 'SIL_FAULT'?
> >  #define __ARCH_UAPI_SA_FLAGS _SA_SIGGFAULT
> >   ^
> >
> > The changes in the two individual patches listed in 'Fixes' below are
> > OK.  Remove the _SA_SIGGFAULT define since PH-UX isn't going to be
> > supported according to commit 41f5a81c07cd ("parisc: Drop HP-UX specific
> > fcntl and signal flags").
> >
> > Fixes: 23acdc76f179 ("signal: clear non-uapi flag bits when 
> > passing/returning sa_flags")
> > Fixes: 41f5a81c07cd ("parisc: Drop HP-UX specific fcntl and signal flags")
> > Signed-off-by: Anders Roxell 
> > ---
> >  arch/parisc/include/asm/signal.h | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/parisc/include/asm/signal.h 
> > b/arch/parisc/include/asm/signal.h
> > index 30dd1e43ef88..715c96ba2ec8 100644
> > --- a/arch/parisc/include/asm/signal.h
> > +++ b/arch/parisc/include/asm/signal.h
> > @@ -21,8 +21,6 @@ typedef struct {
> >   unsigned long sig[_NSIG_WORDS];
> >  } sigset_t;
> >
> > -#define __ARCH_UAPI_SA_FLAGS _SA_SIGGFAULT
> > -
>
> Which kernel are you testing?

I used used linux-next tag: next-20201126

Cheers,
Anders

> I don't see this line in current git head...?!?
>
> Helge
>
> >  #include 
> >
> >  #endif /* !__ASSEMBLY */
> >
>


[PATCH] parisc: signal: remove _SA_SIGGFAULT

2020-11-26 Thread Anders Roxell
When building tinyconfig on parisc the following error shows up:

/tmp/kernel/signal.c: In function 'do_sigaction':
/tmp/arch/parisc/include/asm/signal.h:24:30: error: '_SA_SIGGFAULT' undeclared 
(first use in this function); did you mean 'SIL_FAULT'?
 #define __ARCH_UAPI_SA_FLAGS _SA_SIGGFAULT
  ^

The changes in the two individual patches listed in 'Fixes' below are
OK.  Remove the _SA_SIGGFAULT define since PH-UX isn't going to be
supported according to commit 41f5a81c07cd ("parisc: Drop HP-UX specific
fcntl and signal flags").

Fixes: 23acdc76f179 ("signal: clear non-uapi flag bits when passing/returning 
sa_flags")
Fixes: 41f5a81c07cd ("parisc: Drop HP-UX specific fcntl and signal flags")
Signed-off-by: Anders Roxell 
---
 arch/parisc/include/asm/signal.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/parisc/include/asm/signal.h b/arch/parisc/include/asm/signal.h
index 30dd1e43ef88..715c96ba2ec8 100644
--- a/arch/parisc/include/asm/signal.h
+++ b/arch/parisc/include/asm/signal.h
@@ -21,8 +21,6 @@ typedef struct {
unsigned long sig[_NSIG_WORDS];
 } sigset_t;
 
-#define __ARCH_UAPI_SA_FLAGS   _SA_SIGGFAULT
-
 #include 
 
 #endif /* !__ASSEMBLY */
-- 
2.29.2



[PATCH] parisc: pci-dma: fix warning unused-function

2020-11-26 Thread Anders Roxell
When building tinyconfig on parisc the following warnign shows up:

/tmp/arch/parisc/kernel/pci-dma.c:338:12: warning: 'proc_pcxl_dma_show' defined 
but not used [-Wunused-function]
 static int proc_pcxl_dma_show(struct seq_file *m, void *v)
^~

Mark the function as __maybe_unused to fix the warning.

Signed-off-by: Anders Roxell 
---
 arch/parisc/kernel/pci-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index 36610a5c029f..36a57aa38e87 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -335,7 +335,7 @@ pcxl_free_range(unsigned long vaddr, size_t size)
dump_resmap();
 }
 
-static int proc_pcxl_dma_show(struct seq_file *m, void *v)
+static int __maybe_unused proc_pcxl_dma_show(struct seq_file *m, void *v)
 {
 #if 0
u_long i = 0;
-- 
2.29.2



Re: [PATCH] kfence: Avoid stalling work queue task without allocations

2020-11-11 Thread Anders Roxell
On Wed, 11 Nov 2020 at 09:29, Marco Elver  wrote:
>
> On Wed, 11 Nov 2020 at 00:23, Anders Roxell  wrote:
> [...]
> >
> > I gave them a spin on next-20201105 [1] and on next-20201110 [2].
> >
> > I eventually got to a prompt on next-20201105.
> > However, I got to this kernel panic on the next-20201110:
> >
> > [...]
> > [ 1514.089966][T1] Testing event system initcall: OK
> > [ 1514.806232][T1] Running tests on all trace events:
> > [ 1514.857835][T1] Testing all events:
> > [ 1525.503262][C0] hrtimer: interrupt took 10902600 ns
> > [ 1623.861452][C0] BUG: workqueue lockup - pool cpus=0 node=0
> > flags=0x0 nice=0 stuck for 65s!
> > [...]
> > [ 7823.104349][   T28]   Tainted: GW
> > 5.10.0-rc3-next-20201110-8-g8dc06700529d #3
> > [ 7833.206491][   T28] "echo 0 >
> > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 7840.750700][   T28] task:kworker/0:1 state:D stack:26640 pid:
> > 1872 ppid: 2 flags:0x0428
> > [ 7875.642531][   T28] Workqueue: events toggle_allocation_gate
> > [ 7889.178334][   T28] Call trace:
> > [ 7897.066649][   T28]  __switch_to+0x1cc/0x1e0
> > [ 7905.326856][   T28]  0x0f7077b0
> > [ 7928.354644][   T28] INFO: lockdep is turned off.
> > [ 7934.022572][   T28] Kernel panic - not syncing: hung_task: blocked tasks
> > [ 7934.032039][   T28] CPU: 0 PID: 28 Comm: khungtaskd Tainted: G
> >   W 5.10.0-rc3-next-20201110-8-g8dc06700529d #3
> > [ 7934.045586][   T28] Hardware name: linux,dummy-virt (DT)
> > [ 7934.053677][   T28] Call trace:
> > [ 7934.060276][   T28]  dump_backtrace+0x0/0x420
> > [ 7934.067635][   T28]  show_stack+0x38/0xa0
> > [ 7934.091277][   T28]  dump_stack+0x1d4/0x278
> > [ 7934.098878][   T28]  panic+0x304/0x5d8
> > [ 7934.114923][   T28]  check_hung_uninterruptible_tasks+0x5e4/0x640
> > [ 7934.123823][   T28]  watchdog+0x138/0x160
> > [ 7934.131561][   T28]  kthread+0x23c/0x260
> > [ 7934.138590][   T28]  ret_from_fork+0x10/0x18
> > [ 7934.146631][   T28] Kernel Offset: disabled
> > [ 7934.153749][   T28] CPU features: 0x0240002,20002004
> > [ 7934.161476][   T28] Memory Limit: none
> > [ 7934.171272][   T28] ---[ end Kernel panic - not syncing: hung_task:
> > blocked tasks ]---
> >
> > Cheers,
> > Anders
> > [1] https://people.linaro.org/~anders.roxell/output-next-20201105-test.log
> > [2] https://people.linaro.org/~anders.roxell/output-next-20201110-test.log
>
> Thanks for testing. The fact that it passes on next-20201105 but not
> on 20201110 is strange. If you boot with KFENCE disabled (boot param
> kfence.sample_interval=0), does it boot?

This is my qemu cmdline with kfence.sample_interval=0
$ qemu-system-aarch64 --enable-kvm -cpu cortex-a53 -kernel
Image-20201110-test -serial stdio -monitor none -nographic -m 2G -M
virt -fsdev 
local,id=root,path=/srv/kvm/tmp/stretch/arm64-test,security_model=none,writeout=immediate
-device virtio-rng-pci -device
virtio-9p-pci,fsdev=root,mount_tag=/dev/root -append "root=/dev/root
rootfstype=9p rootflags=trans=virtio console=ttyAMA0,38400n8
earlycon=pl011,0x900 initcall_debug softlockup_panic=0
security=none kpti=no kfence.sample_interval=0"

This is the result, I managed to get to the prompt. see
https://people.linaro.org/~anders.roxell/output-next-20201110-test-2.log

Cheers,
Anders

>
> In your log [2] I see a number of "BUG: workqueue lockup ..." but that
> doesn't make sense, at least I don't think the KFENCE work item is
> causing this. It'd be interesting to bisect what changed between
> 20201105 and 20201110, but I have a suspicion that might take too
> long. Short of that, let me see if there are any changes between the 2
> that look like it might be causing this.
>
> Thanks,
> -- Marco


Re: [PATCH] kfence: Avoid stalling work queue task without allocations

2020-11-10 Thread Anders Roxell
On Tue, 10 Nov 2020 at 14:53, Marco Elver  wrote:
>
> To toggle the allocation gates, we set up a delayed work that calls
> toggle_allocation_gate(). Here we use wait_event() to await an
> allocation and subsequently disable the static branch again. However, if
> the kernel has stopped doing allocations entirely, we'd wait
> indefinitely, and stall the worker task. This may also result in the
> appropriate warnings if CONFIG_DETECT_HUNG_TASK=y.
>
> Therefore, introduce a 1 second timeout and use wait_event_timeout(). If
> the timeout is reached, the static branch is disabled and a new delayed
> work is scheduled to try setting up an allocation at a later time.
>
> Note that, this scenario is very unlikely during normal workloads once
> the kernel has booted and user space tasks are running. It can, however,
> happen during early boot after KFENCE has been enabled, when e.g.
> running tests that do not result in any allocations.
>
> Link: 
> https://lkml.kernel.org/r/CADYN=9j0dqhizagb0-jz4hobbh+05kmbxb4c0cxms7qi5na...@mail.gmail.com
> Reported-by: Anders Roxell 
> Signed-off-by: Marco Elver 
> ---
>  mm/kfence/core.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index 9358f42a9a9e..933b197b8634 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -592,7 +592,11 @@ static void toggle_allocation_gate(struct work_struct 
> *work)
> /* Enable static key, and await allocation to happen. */
> atomic_set(&allocation_gate, 0);
> static_branch_enable(&kfence_allocation_key);
> -   wait_event(allocation_wait, atomic_read(&allocation_gate) != 0);
> +   /*
> +* Await an allocation. Timeout after 1 second, in case the kernel 
> stops
> +* doing allocations, to avoid stalling this worker task for too long.
> +*/
> +   wait_event_timeout(allocation_wait, atomic_read(&allocation_gate) != 
> 0, HZ);
>
> /* Disable static key and reset timer. */
> static_branch_disable(&kfence_allocation_key);
> --
> 2.29.2.222.g5d2a92d10f8-goog
>

I gave them a spin on next-20201105 [1] and on next-20201110 [2].

I eventually got to a prompt on next-20201105.
However, I got to this kernel panic on the next-20201110:

[...]
[ 1514.089966][T1] Testing event system initcall: OK
[ 1514.806232][T1] Running tests on all trace events:
[ 1514.857835][T1] Testing all events:
[ 1525.503262][C0] hrtimer: interrupt took 10902600 ns
[ 1623.861452][C0] BUG: workqueue lockup - pool cpus=0 node=0
flags=0x0 nice=0 stuck for 65s!
[...]
[ 7823.104349][   T28]   Tainted: GW
5.10.0-rc3-next-20201110-8-g8dc06700529d #3
[ 7833.206491][   T28] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7840.750700][   T28] task:kworker/0:1 state:D stack:26640 pid:
1872 ppid: 2 flags:0x0428
[ 7875.642531][   T28] Workqueue: events toggle_allocation_gate
[ 7889.178334][   T28] Call trace:
[ 7897.066649][   T28]  __switch_to+0x1cc/0x1e0
[ 7905.326856][   T28]  0x0f7077b0
[ 7928.354644][   T28] INFO: lockdep is turned off.
[ 7934.022572][   T28] Kernel panic - not syncing: hung_task: blocked tasks
[ 7934.032039][   T28] CPU: 0 PID: 28 Comm: khungtaskd Tainted: G
  W 5.10.0-rc3-next-20201110-8-g8dc06700529d #3
[ 7934.045586][   T28] Hardware name: linux,dummy-virt (DT)
[ 7934.053677][   T28] Call trace:
[ 7934.060276][   T28]  dump_backtrace+0x0/0x420
[ 7934.067635][   T28]  show_stack+0x38/0xa0
[ 7934.091277][   T28]  dump_stack+0x1d4/0x278
[ 7934.098878][   T28]  panic+0x304/0x5d8
[ 7934.114923][   T28]  check_hung_uninterruptible_tasks+0x5e4/0x640
[ 7934.123823][   T28]  watchdog+0x138/0x160
[ 7934.131561][   T28]  kthread+0x23c/0x260
[ 7934.138590][   T28]  ret_from_fork+0x10/0x18
[ 7934.146631][   T28] Kernel Offset: disabled
[ 7934.153749][   T28] CPU features: 0x0240002,20002004
[ 7934.161476][   T28] Memory Limit: none
[ 7934.171272][   T28] ---[ end Kernel panic - not syncing: hung_task:
blocked tasks ]---


Cheers,
Anders
[1] https://people.linaro.org/~anders.roxell/output-next-20201105-test.log
[2] https://people.linaro.org/~anders.roxell/output-next-20201110-test.log


Re: linux-next: Tree for Nov 5

2020-11-10 Thread Anders Roxell
On Tue, 10 Nov 2020 at 14:54, Marco Elver  wrote:
>
> On Tue, 10 Nov 2020 at 10:36, Dmitry Vyukov  wrote:
> [...]
> > > > On Tue, Nov 10, 2020 at 8:50 AM Anders Roxell 
> > > >  wrote:
> [...]
> > > > > When building an arm64 allmodconfig and booting up that in qemu I see
> > > > >
> > > > > [10011.092394][   T28] task:kworker/0:2 state:D stack:26896 pid:
> > > > > 1840 ppid: 2 flags:0x0428
> > > > > [10022.368093][   T28] Workqueue: events toggle_allocation_gate
> > > > > [10024.827549][   T28] Call trace:
> > > > > [10027.152494][   T28]  __switch_to+0x1cc/0x1e0
> > > > > [10031.378073][   T28]  __schedule+0x730/0x800
> > > > > [10032.164468][   T28]  schedule+0xd8/0x160
> > > > > [10033.886807][   T28]  toggle_allocation_gate+0x16c/0x220
> > > > > [10038.477987][   T28]  process_one_work+0x5c0/0x980
> > > > > [10039.900075][   T28]  worker_thread+0x428/0x720
> > > > > [10042.782911][   T28]  kthread+0x23c/0x260
> > > > > [10043.171725][   T28]  ret_from_fork+0x10/0x18
> > > > > [10046.227741][   T28] INFO: lockdep is turned off.
> > > > > [10047.732220][   T28] Kernel panic - not syncing: hung_task: blocked 
> > > > > tasks
> > > > > [10047.741785][   T28] CPU: 0 PID: 28 Comm: khungtaskd Tainted: G
> > > > >   W 5.10.0-rc2-next-20201105-6-g7af110e4d8ed #1
> > > > > [10047.755348][   T28] Hardware name: linux,dummy-virt (DT)
> > > > > [10047.763476][   T28] Call trace:
> > > > > [10047.769802][   T28]  dump_backtrace+0x0/0x420
> > > > > [10047.777104][   T28]  show_stack+0x38/0xa0
> > > > > [10047.784177][   T28]  dump_stack+0x1d4/0x278
> > > > > [10047.791362][   T28]  panic+0x304/0x5d8
> > > > > [10047.798202][   T28]  check_hung_uninterruptible_tasks+0x5e4/0x640
> > > > > [10047.807056][   T28]  watchdog+0x138/0x160
> > > > > [10047.814140][   T28]  kthread+0x23c/0x260
> > > > > [10047.821130][   T28]  ret_from_fork+0x10/0x18
> > > > > [10047.829181][   T28] Kernel Offset: disabled
> > > > > [10047.836274][   T28] CPU features: 0x0240002,20002004
> > > > > [10047.844070][   T28] Memory Limit: none
> > > > > [10047.853599][   T28] ---[ end Kernel panic - not syncing: hung_task:
> > > > > blocked tasks ]---
> > > > >
> > > > > if I build with KFENCE=n it boots up eventually, here's my .config 
> > > > > file [2].
> > > > >
> > > > > Any idea what may happen?
> > > > >
> > > > > it happens on next-20201109 also, but it takes longer until we get the
> > > > > "Call trace:".
> > > > >
> > > > > Cheers,
> > > > > Anders
> > > > > [1] http://ix.io/2Ddv
> > > > > [2] 
> > > > > https://people.linaro.org/~anders.roxell/allmodconfig-next-20201105.config
> [...]
> > > oh I missed to say that this is the full boot log with the kernel
> > > panic http://ix.io/2Ddv
> >
> > Thanks!
> > The last messages before the hang are:
> >
> > [ 1367.791522][T1] Running tests on all trace events:
> > [ 1367.815307][T1] Testing all events:
> >
> > I can imagine tracing somehow interferes with kfence.
>
> The reason is simply that that config on qemu is so slow (enabling
> lockdep helped), and the test that is running doesn't result in
> allocations for an extended time. Because of that our wait_event()
> just stalls, as there are no allocations coming in. My guess is that
> this scenario is unique to early boot, where we are not yet running
> user space, paired with running a selftest that results in no
> allocations for some time.
>
> Try and give that a spin:
> https://lkml.kernel.org/r/20201110135320.3309507-1-el...@google.com

Thank you Marco.
I'll give it a spin and reply to that thread if it works or not.

Cheers,
Anders


[PATCHv2] arm64: dts: freescale: fix typo Makefile

2020-11-10 Thread Anders Roxell
While trying to do 'make dtbs_install' the following error shows up

make[3]: *** No rule to make target
  '/tmp/out/obj-dir/dtbinstallfreescale/imx8mm-kontron-n801x-s.dts', needed by 
'__dtbs_install'.

Fix typo in imx8mm-kontron-n801x-s.dts change file ending to *.dtb

Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and 
baseboards")
Signed-off-by: Anders Roxell 
---
 arch/arm64/boot/dts/freescale/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 876bf484bbe6..6f0777ee6cd6 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,7 +32,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2162a-qds.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
-dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-n801x-s.dts
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-n801x-s.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
-- 
2.28.0



Re: [PATCH] arm64: dts: freescale: fix typo Makefile

2020-11-10 Thread Anders Roxell
On Fri, 6 Nov 2020 at 16:12, Krzysztof Kozlowski  wrote:
>
> On Thu, Nov 05, 2020 at 12:18:23PM +0100, Anders Roxell wrote:
> > While trying to do 'make dtbs_install' the following error shows up
> >
> > make[3]: *** No rule to make target
> >   
> > '/srv/src/kernel/next/out/obj-arm64-next-20201105/dtbsinstall/freescale/imx8mm-kontron-n801x-s.dts',
> >   needed by '__dtbs_install'.
> > make[3]: Target '__dtbs_install' not remade because of errors.
> > make[2]: *** [/srv/src/kernel/bisecting/scripts/Makefile.dtbinst:34:
> >   arch/arm64/boot/dts/freescale] Error 2
> > make[2]: Target '__dtbs_install' not remade because of errors.
> > make[1]: *** [/srv/src/kernel/bisecting/Makefile:1344: dtbs_install]
> >   Error 2
> > make: *** [Makefile:185: __sub-make] Error 2
> > make: Target 'dtbs_install' not remade because of errors.
>
> Don't paste unrelated messages and don't wrap too early ("Error 2"
> should not be after new line). This blob is not useful at all.
>
> Keep only first two lines, all rest is meaningless.

Thank you for your review Krzysztof, I'll do that.

>
> >
> > Fix typo in imx8mm-kontron-n801x-s.dts change file ending to *.dtb
> >
> > Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and 
> > baseboards")
> > Signed-off-by: Anders Roxell 
>
> You need to CC the maintainers of platform. Unfortunately Makefile is
> not included, so point to the DTS file to get the proper folks and
> mailing lists.

Ok, I'll send out a v2 shortly.

Cheers,
Anders


Re: linux-next: Tree for Nov 5

2020-11-10 Thread Anders Roxell
On Tue, 10 Nov 2020 at 10:17, Dmitry Vyukov  wrote:
>
> On Tue, Nov 10, 2020 at 8:50 AM Anders Roxell  
> wrote:
> >
> > On Thu, 5 Nov 2020 at 07:06, Stephen Rothwell  wrote:
> > >
> > > Hi all,
> > >
> > > Changes since 20201104:
> >
> > When building an arm64 allmodconfig and booting up that in qemu I see
> >
> > [10011.092394][   T28] task:kworker/0:2 state:D stack:26896 pid:
> > 1840 ppid: 2 flags:0x0428
> > [10022.368093][   T28] Workqueue: events toggle_allocation_gate
> > [10024.827549][   T28] Call trace:
> > [10027.152494][   T28]  __switch_to+0x1cc/0x1e0
> > [10031.378073][   T28]  __schedule+0x730/0x800
> > [10032.164468][   T28]  schedule+0xd8/0x160
> > [10033.886807][   T28]  toggle_allocation_gate+0x16c/0x220
> > [10038.477987][   T28]  process_one_work+0x5c0/0x980
> > [10039.900075][   T28]  worker_thread+0x428/0x720
> > [10042.782911][   T28]  kthread+0x23c/0x260
> > [10043.171725][   T28]  ret_from_fork+0x10/0x18
> > [10046.227741][   T28] INFO: lockdep is turned off.
> > [10047.732220][   T28] Kernel panic - not syncing: hung_task: blocked tasks
> > [10047.741785][   T28] CPU: 0 PID: 28 Comm: khungtaskd Tainted: G
> >   W 5.10.0-rc2-next-20201105-6-g7af110e4d8ed #1
> > [10047.755348][   T28] Hardware name: linux,dummy-virt (DT)
> > [10047.763476][   T28] Call trace:
> > [10047.769802][   T28]  dump_backtrace+0x0/0x420
> > [10047.777104][   T28]  show_stack+0x38/0xa0
> > [10047.784177][   T28]  dump_stack+0x1d4/0x278
> > [10047.791362][   T28]  panic+0x304/0x5d8
> > [10047.798202][   T28]  check_hung_uninterruptible_tasks+0x5e4/0x640
> > [10047.807056][   T28]  watchdog+0x138/0x160
> > [10047.814140][   T28]  kthread+0x23c/0x260
> > [10047.821130][   T28]  ret_from_fork+0x10/0x18
> > [10047.829181][   T28] Kernel Offset: disabled
> > [10047.836274][   T28] CPU features: 0x0240002,20002004
> > [10047.844070][   T28] Memory Limit: none
> > [10047.853599][   T28] ---[ end Kernel panic - not syncing: hung_task:
> > blocked tasks ]---
> >
> > if I build with KFENCE=n it boots up eventually, here's my .config file [2].
> >
> > Any idea what may happen?
> >
> > it happens on next-20201109 also, but it takes longer until we get the
> > "Call trace:".
> >
> > Cheers,
> > Anders
> > [1] http://ix.io/2Ddv
> > [2] 
> > https://people.linaro.org/~anders.roxell/allmodconfig-next-20201105.config
>
> Hi Anders,

Hi Dmitry,

>
> Does it happen during boot or afterwards?

During boot, since it runs a lot of boot selftests.

> 10047 are seconds after boot, right?

No

> So this is like 3 hours after boot, no?

This is a boot log where I actually get to the boot prompt.
https://people.linaro.org/~anders.roxell/output-next-20201109-nokfence.log

> Also, is there anything useful before that part of the log?

oh I missed to say that this is the full boot log with the kernel
panic http://ix.io/2Ddv

Cheers,
Anders


Re: linux-next: Tree for Nov 5

2020-11-09 Thread Anders Roxell
On Thu, 5 Nov 2020 at 07:06, Stephen Rothwell  wrote:
>
> Hi all,
>
> Changes since 20201104:

When building an arm64 allmodconfig and booting up that in qemu I see

[10011.092394][   T28] task:kworker/0:2 state:D stack:26896 pid:
1840 ppid: 2 flags:0x0428
[10022.368093][   T28] Workqueue: events toggle_allocation_gate
[10024.827549][   T28] Call trace:
[10027.152494][   T28]  __switch_to+0x1cc/0x1e0
[10031.378073][   T28]  __schedule+0x730/0x800
[10032.164468][   T28]  schedule+0xd8/0x160
[10033.886807][   T28]  toggle_allocation_gate+0x16c/0x220
[10038.477987][   T28]  process_one_work+0x5c0/0x980
[10039.900075][   T28]  worker_thread+0x428/0x720
[10042.782911][   T28]  kthread+0x23c/0x260
[10043.171725][   T28]  ret_from_fork+0x10/0x18
[10046.227741][   T28] INFO: lockdep is turned off.
[10047.732220][   T28] Kernel panic - not syncing: hung_task: blocked tasks
[10047.741785][   T28] CPU: 0 PID: 28 Comm: khungtaskd Tainted: G
  W 5.10.0-rc2-next-20201105-6-g7af110e4d8ed #1
[10047.755348][   T28] Hardware name: linux,dummy-virt (DT)
[10047.763476][   T28] Call trace:
[10047.769802][   T28]  dump_backtrace+0x0/0x420
[10047.777104][   T28]  show_stack+0x38/0xa0
[10047.784177][   T28]  dump_stack+0x1d4/0x278
[10047.791362][   T28]  panic+0x304/0x5d8
[10047.798202][   T28]  check_hung_uninterruptible_tasks+0x5e4/0x640
[10047.807056][   T28]  watchdog+0x138/0x160
[10047.814140][   T28]  kthread+0x23c/0x260
[10047.821130][   T28]  ret_from_fork+0x10/0x18
[10047.829181][   T28] Kernel Offset: disabled
[10047.836274][   T28] CPU features: 0x0240002,20002004
[10047.844070][   T28] Memory Limit: none
[10047.853599][   T28] ---[ end Kernel panic - not syncing: hung_task:
blocked tasks ]---

if I build with KFENCE=n it boots up eventually, here's my .config file [2].

Any idea what may happen?

it happens on next-20201109 also, but it takes longer until we get the
"Call trace:".

Cheers,
Anders
[1] http://ix.io/2Ddv
[2] https://people.linaro.org/~anders.roxell/allmodconfig-next-20201105.config


[PATCH] sound: soc: mediatek: mt8192: fix modpost ERROR

2020-11-05 Thread Anders Roxell
When enabling CONFIG_SND_SOC_MT8192_MT6359_RT1015_RT5682=m the following
error shows up:

ERROR: modpost: "mt8192_afe_gpio_request"
[sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.ko] undefined!
ERROR: modpost: "mt8192_afe_gpio_init"
[sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.ko] undefined!

Fix the link error by export the symbols mt8192_afe_gpio_init and
mt8192_afe_gpio_request.

Fixes: 18b13ff23fab ("ASoC: mediatek: mt8192: add machine driver with mt6359, 
rt1015 and rt5682")
Signed-off-by: Anders Roxell 
---
 sound/soc/mediatek/mt8192/mt8192-afe-gpio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c 
b/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c
index ea000888c9e8..0286c95ed2b8 100644
--- a/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c
+++ b/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c
@@ -160,6 +160,7 @@ int mt8192_afe_gpio_init(struct device *dev)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(mt8192_afe_gpio_init);
 
 static int mt8192_afe_gpio_adda_dl(struct device *dev, bool enable)
 {
@@ -304,3 +305,4 @@ int mt8192_afe_gpio_request(struct device *dev, bool enable,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(mt8192_afe_gpio_request);
-- 
2.28.0



[PATCH] arm64: dts: freescale: fix typo Makefile

2020-11-05 Thread Anders Roxell
While trying to do 'make dtbs_install' the following error shows up

make[3]: *** No rule to make target
  
'/srv/src/kernel/next/out/obj-arm64-next-20201105/dtbsinstall/freescale/imx8mm-kontron-n801x-s.dts',
  needed by '__dtbs_install'.
make[3]: Target '__dtbs_install' not remade because of errors.
make[2]: *** [/srv/src/kernel/bisecting/scripts/Makefile.dtbinst:34:
  arch/arm64/boot/dts/freescale] Error 2
make[2]: Target '__dtbs_install' not remade because of errors.
make[1]: *** [/srv/src/kernel/bisecting/Makefile:1344: dtbs_install]
  Error 2
make: *** [Makefile:185: __sub-make] Error 2
make: Target 'dtbs_install' not remade because of errors.

Fix typo in imx8mm-kontron-n801x-s.dts change file ending to *.dtb

Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and 
baseboards")
Signed-off-by: Anders Roxell 
---
 arch/arm64/boot/dts/freescale/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 876bf484bbe6..6f0777ee6cd6 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,7 +32,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2162a-qds.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
-dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-n801x-s.dts
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-n801x-s.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
-- 
2.28.0



Re: [PATCH] soc: qcom: QCOM_RPMH fix build with modular QCOM_RPMH

2020-10-28 Thread Anders Roxell
On Tue, 27 Oct 2020 at 22:15, Lina Iyer  wrote:
>
> Hi Anders,
>
> On Tue, Oct 27 2020 at 05:14 -0600, Anders Roxell wrote:
> >When building allmodconfig leading to the following link error with
> >CONFIG_QCOM_RPMH=y and CONFIG_QCOM_COMMAND_DB=m:
> >
> >aarch64-linux-gnu-ld: drivers/clk/qcom/clk-rpmh.o: in function 
> >`clk_rpmh_probe':
> >  drivers/clk/qcom/clk-rpmh.c:474: undefined reference to `cmd_db_read_addr'
> >  drivers/clk/qcom/clk-rpmh.c:474:(.text+0x254): relocation truncated to 
> > fit: R_AARCH64_CALL26 against undefined symbol `cmd_db_read_addr'
> >
> >Fix this by adding a Kconfig depenency and forcing QCOM_RPMH to be a
> >module when QCOM_COMMAND_DB is a module. Also removing the dependency on
> >'ARCH_QCOM || COMPILE_TEST' since that is already a dependency for
> >QCOM_COMMAND_DB.
> >
> >Fixes: 778279f4f5e4 ("soc: qcom: cmd-db: allow loading as a module")
> >Signed-off-by: Anders Roxell 
> >---
> > drivers/soc/qcom/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> >index 9b4ae9c16ba7..3bdd1604f78f 100644
> >--- a/drivers/soc/qcom/Kconfig
> >+++ b/drivers/soc/qcom/Kconfig
> >@@ -109,7 +109,7 @@ config QCOM_RMTFS_MEM
> >
> > config QCOM_RPMH
> >   tristate "Qualcomm RPM-Hardened (RPMH) Communication"
> >-  depends on ARCH_QCOM || COMPILE_TEST
> >+  depends on QCOM_COMMAND_DB
> A solution was posted in the mailing list alredy -
> https://lore.kernel.org/linux-arm-msm/20201008040907.7036-1-il...@codeaurora.org/

I missed that one, thanks.

>
> If you get a chance, please give that a shot to see if that works for
> you.

That will work too, but the "depends on ARCH_QCOM || COMPILE_TEST"
isn't needed since that is already the dependency for QCOM_COMMAND_DB.
So that should be met here too or am I missing something?

Cheers,
Anders

>
> Thanks,
> Lina
>
> >   help
> > Support for communication with the hardened-RPM blocks in
> > Qualcomm Technologies Inc (QTI) SoCs. RPMH communication uses an
> >--
> >2.28.0
> >


[PATCH] soc: qcom: QCOM_RPMH fix build with modular QCOM_RPMH

2020-10-27 Thread Anders Roxell
When building allmodconfig leading to the following link error with
CONFIG_QCOM_RPMH=y and CONFIG_QCOM_COMMAND_DB=m:

aarch64-linux-gnu-ld: drivers/clk/qcom/clk-rpmh.o: in function `clk_rpmh_probe':
  drivers/clk/qcom/clk-rpmh.c:474: undefined reference to `cmd_db_read_addr'
  drivers/clk/qcom/clk-rpmh.c:474:(.text+0x254): relocation truncated to fit: 
R_AARCH64_CALL26 against undefined symbol `cmd_db_read_addr'

Fix this by adding a Kconfig depenency and forcing QCOM_RPMH to be a
module when QCOM_COMMAND_DB is a module. Also removing the dependency on
'ARCH_QCOM || COMPILE_TEST' since that is already a dependency for
QCOM_COMMAND_DB.

Fixes: 778279f4f5e4 ("soc: qcom: cmd-db: allow loading as a module")
Signed-off-by: Anders Roxell 
---
 drivers/soc/qcom/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9b4ae9c16ba7..3bdd1604f78f 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -109,7 +109,7 @@ config QCOM_RMTFS_MEM
 
 config QCOM_RPMH
tristate "Qualcomm RPM-Hardened (RPMH) Communication"
-   depends on ARCH_QCOM || COMPILE_TEST
+   depends on QCOM_COMMAND_DB
help
  Support for communication with the hardened-RPM blocks in
  Qualcomm Technologies Inc (QTI) SoCs. RPMH communication uses an
-- 
2.28.0



Re: [PATCH next] gpiolib: check for parent device in devprop_gpiochip_set_names()

2020-09-16 Thread Anders Roxell
On Wed, 16 Sep 2020 at 16:47, Bartosz Golaszewski  wrote:
>
> On Wed, Sep 16, 2020 at 4:29 PM Andy Shevchenko
>  wrote:
> >
> > On Wed, Sep 16, 2020 at 03:43:27PM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski 
> > >
> > > It's possible for a GPIO chip to not have a parent device (whose
> > > properties we inspect for 'gpio-line-names'). In this case we should
> > > simply return from devprop_gpiochip_set_names(). Add an appropriate
> > > check for this use-case.
> >
> > Ah, nice!
> > Can we also add a small comment in the code, b/c w/o it I would stumble over
> > and eager to remove looks-as-unneeded check?
> > Reviewed-by: Andy Shevchenko 

Tested-by: Anders Roxell 


Re: [PATCH 0/3] gpiolib: generalize GPIO line names property

2020-09-15 Thread Anders Roxell
On Tue, 8 Sep 2020 at 18:40, Bartosz Golaszewski  wrote:
>
> From: Bartosz Golaszewski 
>
> I initially sent this as part of the gpio-mockup overhaul but since
> these patches are indepentent and the work on gpio-mockup may become
> more complicated - I'm sending these separately.
>
> The only change is adding additional property helpers to count strings
> in array.
>
> Bartosz Golaszewski (3):
>   device: property: add helpers to count items in string arrays
>   gpiolib: generalize devprop_gpiochip_set_names() for device properties
>   gpiolib: unexport devprop_gpiochip_set_names()

I do an arm64 allmodconfig build fron linux-next (tag: next-20200915) and
run that in qemu. When I run I see the following output (see full log [1]):
"BUG: KASAN: null-ptr-deref in device_property_read_string_array".


[ 6186.339462][T1] unittest-gpio
testcase-data:overlay-node:test-bus:gpio@0: no pinctrl handle
[ 6186.346148][T1] gpiochip_find_base: found new base at 507
[ 6186.348684][T1]
==
[ 6186.351563][T1] BUG: KASAN: null-ptr-deref in
device_property_read_string_array+0x40/0xa0
[ 6186.355157][T1] Read of size 8 at addr 0570 by task
swapper/0/1
[ 6186.358212][T1]
[ 6186.359361][T1] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G
W 5.9.0-rc5-next-20200915-6-g104c8fe4916b #1
[ 6186.363877][T1] Hardware name: linux,dummy-virt (DT)
[ 6186.366156][T1] Call trace:
[ 6186.367540][T1]  dump_backtrace+0x0/0x320
[ 6186.369446][T1]  show_stack+0x38/0x60
[ 6186.371282][T1]  dump_stack+0x1d4/0x278
[ 6186.373193][T1]  __kasan_report+0x148/0x180
[ 6186.375265][T1]  kasan_report+0x44/0xe0
[ 6186.377168][T1]  __asan_load8+0xbc/0xe0
[ 6186.379069][T1]  device_property_read_string_array+0x40/0xa0
[ 6186.381741][T1]  devprop_gpiochip_set_names.isra.0+0x4c/0x200
[ 6186.384394][T1]  gpiochip_add_data_with_key+0x75c/0xf80
[ 6186.386876][T1]  unittest_gpio_probe+0xf4/0x1e0
[ 6186.389049][T1]  platform_drv_probe+0xac/0x160
[ 6186.391184][T1]  really_probe+0x430/0xaa0
[ 6186.393136][T1]  really_probe_debug+0x3c/0xe0
[ 6186.395238][T1]  driver_probe_device+0x134/0x1c0
[ 6186.397443][T1]  device_driver_attach+0xec/0x180
[ 6186.399639][T1]  __driver_attach+0x1f0/0x220
[ 6186.401718][T1]  bus_for_each_dev+0x104/0x1c0
[ 6186.403796][T1]  driver_attach+0x44/0x60
[ 6186.405731][T1]  bus_add_driver+0x214/0x3c0
[ 6186.407745][T1]  driver_register+0x1a8/0x240
[ 6186.409835][T1]  __platform_driver_register+0x90/0xa0
[ 6186.412207][T1]  of_unittest_overlay_gpio+0x20c/0x7cc
[ 6186.414595][T1]  of_unittest_overlay+0x748/0x7c0
[ 6186.416810][T1]  of_unittest+0x148/0x184
[ 6186.418732][T1]  do_one_initcall+0xc4/0x280
[ 6186.420782][T1]  do_initcalls+0x148/0x1ac
[ 6186.422758][T1]  kernel_init_freeable+0x158/0x1a0
[ 6186.425023][T1]  kernel_init+0x24/0x1f0
[ 6186.426938][T1]  ret_from_fork+0x10/0x18
[ 6186.428894][T1]
==
[ 6186.433241][T1] Unable to handle kernel read from unreadable
memory at virtual address 0570
[ 6186.437207][T1] Mem abort info:
[ 6186.438639][T1]   ESR = 0x9604
[ 6186.440536][T1]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 6186.442791][T1]   SET = 0, FnV = 0
[ 6186.444660][T1]   EA = 0, S1PTW = 0
[ 6186.446233][T1] Data abort info:
[ 6186.447938][T1]   ISV = 0, ISS = 0x0004
[ 6186.449749][T1]   CM = 0, WnR = 0
[ 6186.451222][T1] [0570] user address but active_mm is swapper
[ 6186.454000][T1] Internal error: Oops: 9604 [#1] PREEMPT SMP
[ 6186.456422][T1] Modules linked in:
[ 6186.458232][T1] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB
W 5.9.0-rc5-next-20200915-6-g104c8fe4916b #1
[ 6186.462833][T1] Hardware name: linux,dummy-virt (DT)
[ 6186.465170][T1] pstate: 6045 (nZCv daif +PAN -UAO BTYPE=--)
[ 6186.467910][T1] pc : device_property_read_string_array+0x40/0xa0
[ 6186.470653][T1] lr : device_property_read_string_array+0x40/0xa0
[ 6186.473380][T1] sp : 69827770
[ 6186.475138][T1] x29: 69827770 x28: a00014a2cc20
[ 6186.477806][T1] x27: 68794760 x26: 68794800
[ 6186.480444][T1] x25: 68794000 x24: 674e1094
[ 6186.483107][T1] x23:  x22: 
[ 6186.485794][T1] x21: a00012d61ca0 x20: a00012d61200
[ 6186.488457][T1] x19:  x18: 14b8
[ 6186.491100][T1] x17: 14f8 x16: 1438
[ 6186.493779][T1] x15: f1f1f1f1 x14: 0003
[ 6186.496405][T1] x13: 000ca688 x12: 8d304e7b
[ 6186.499084][T1] x11: 1fffed304e7a x10: 8d304e7a
[ 6186.501775][T1] x9 : a00012702b2c x8 : 698273d7
[ 6186.504409][T1] x7 : 00

Re: linux-next: Tree for Aug 26

2020-09-07 Thread Anders Roxell
On Thu, 3 Sep 2020 at 18:14, Paul E. McKenney  wrote:
>
> On Thu, Sep 03, 2020 at 10:39:10AM +0200, Anders Roxell wrote:
> > Hi Paul,
> >
> > On Sat, 29 Aug 2020 at 00:59, Paul E. McKenney  wrote:
> > >
> > > On Fri, Aug 28, 2020 at 09:24:19PM +0200, Anders Roxell wrote:
> > > > On Fri, 28 Aug 2020 at 15:29, Paul E. McKenney  
> > > > wrote:
> > > > >
> > > > > On Fri, Aug 28, 2020 at 09:37:17AM +0200, Anders Roxell wrote:
> > > > > > On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Aug 26, 2020 at 08:19:01PM +0200, Anders Roxell wrote:
> > > > > > > > On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell 
> > > > > > > >  wrote:
> > > > > > >
> > > > > > > [ . . . ]
> > > > > > >
> > > > > > > > I've built and run an arm64 allmodconfig kernel where I use the
> > > > > > > > defconfig as the base, I do this for testing purposes.
> > > > > > > > I can see the following call trace [1]:
> > > > > > > >
> > > > > > > > [ 2595.811453][T1] Running tests on all trace events:
> > > > > > > > [ 2595.860933][T1] Testing all events:
> > > > > > > > [ 4316.066072][T8] kworker/dying (8) used greatest stack 
> > > > > > > > depth:
> > > > > > > > 27056 bytes left
> > > > > > > > [ 8561.924871][C0] watchdog: BUG: soft lockup - CPU#0 stuck 
> > > > > > > > for
> > > > > > > > 22s! [migration/0:14]
> > > > > > > > [ 8561.934498][C0] Modules linked in:
> > > > > > > > [ 8561.942303][C0] irq event stamp: 4044
> > > > > > > > [ 8561.949044][C0] hardirqs last  enabled at (4043):
> > > > > > > > [] _raw_spin_unlock_irqrestore+0xac/0x138
> > > > > > > > [ 8561.960848][C0] hardirqs last disabled at (4044):
> > > > > > > > [] __schedule+0xf8/0x7e0
> > > > > > > > [ 8561.971418][C0] softirqs last  enabled at (3698):
> > > > > > > > [] __do_softirq+0x524/0x5f8
> > > > > > > > [ 8561.982191][C0] softirqs last disabled at (3689):
> > > > > > > > [] __irq_exit_rcu+0x128/0x1a0
> > > > > > > > [ 8561.993068][C0] CPU: 0 PID: 14 Comm: migration/0 
> > > > > > > > Tainted: G
> > > > > > > >W 5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1
> > > > > > > > [ 8562.005684][C0] Hardware name: linux,dummy-virt (DT)
> > > > > > > > [ 8562.013247][C0] pstate: 8045 (Nzcv daif +PAN -UAO 
> > > > > > > > BTYPE=--)
> > > > > > > > [ 8562.021657][C0] pc : arch_local_irq_enable+0x58/0x80
> > > > > > > > [ 8562.029323][C0] lr : _raw_spin_unlock_irq+0x84/0xc0
> > > > > > > > [ 8562.036739][C0] sp : 698efaa0
> > > > > > > > [ 8562.042984][C0] x29: 698efaa0 x28: 
> > > > > > > > 6ad0f270
> > > > > > > > [ 8562.053814][C0] x27: 6ad0f248 x26: 
> > > > > > > > 698d4718
> > > > > > > > [ 8562.064687][C0] x25: 6ad0e798 x24: 
> > > > > > > > a000139e3a40
> > > > > > > > [ 8562.075506][C0] x23: 0001 x22: 
> > > > > > > > a000154f5000
> > > > > > > > [ 8562.086425][C0] x21: 6ad0e798 x20: 
> > > > > > > > 6ad0e780
> > > > > > > > [ 8562.097255][C0] x19: a000126a905c x18: 
> > > > > > > > 14c0
> > > > > > > > [ 8562.108071][C0] x17: 1500 x16: 
> > > > > > > > 1440
> > > > > > > > [ 8562.118918][C0] x15: f1f1f1f1 x14: 
> > > > > > > > 003d0900
> > > > > > > > [ 8562.129739][C0] x13: 3d09 x12: 
> > > > > > > > 8d31df41
> > > > > > > > [ 8562.140544][C0] x11: 1fffed31df40 x10: 
&

Re: linux-next: Tree for Aug 26

2020-09-03 Thread Anders Roxell
Hi Paul,

On Sat, 29 Aug 2020 at 00:59, Paul E. McKenney  wrote:
>
> On Fri, Aug 28, 2020 at 09:24:19PM +0200, Anders Roxell wrote:
> > On Fri, 28 Aug 2020 at 15:29, Paul E. McKenney  wrote:
> > >
> > > On Fri, Aug 28, 2020 at 09:37:17AM +0200, Anders Roxell wrote:
> > > > On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney  
> > > > wrote:
> > > > >
> > > > > On Wed, Aug 26, 2020 at 08:19:01PM +0200, Anders Roxell wrote:
> > > > > > On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell 
> > > > > >  wrote:
> > > > >
> > > > > [ . . . ]
> > > > >
> > > > > > I've built and run an arm64 allmodconfig kernel where I use the
> > > > > > defconfig as the base, I do this for testing purposes.
> > > > > > I can see the following call trace [1]:
> > > > > >
> > > > > > [ 2595.811453][T1] Running tests on all trace events:
> > > > > > [ 2595.860933][T1] Testing all events:
> > > > > > [ 4316.066072][T8] kworker/dying (8) used greatest stack depth:
> > > > > > 27056 bytes left
> > > > > > [ 8561.924871][C0] watchdog: BUG: soft lockup - CPU#0 stuck for
> > > > > > 22s! [migration/0:14]
> > > > > > [ 8561.934498][C0] Modules linked in:
> > > > > > [ 8561.942303][C0] irq event stamp: 4044
> > > > > > [ 8561.949044][C0] hardirqs last  enabled at (4043):
> > > > > > [] _raw_spin_unlock_irqrestore+0xac/0x138
> > > > > > [ 8561.960848][C0] hardirqs last disabled at (4044):
> > > > > > [] __schedule+0xf8/0x7e0
> > > > > > [ 8561.971418][C0] softirqs last  enabled at (3698):
> > > > > > [] __do_softirq+0x524/0x5f8
> > > > > > [ 8561.982191][C0] softirqs last disabled at (3689):
> > > > > > [] __irq_exit_rcu+0x128/0x1a0
> > > > > > [ 8561.993068][C0] CPU: 0 PID: 14 Comm: migration/0 Tainted: G
> > > > > >W 5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1
> > > > > > [ 8562.005684][C0] Hardware name: linux,dummy-virt (DT)
> > > > > > [ 8562.013247][C0] pstate: 8045 (Nzcv daif +PAN -UAO 
> > > > > > BTYPE=--)
> > > > > > [ 8562.021657][C0] pc : arch_local_irq_enable+0x58/0x80
> > > > > > [ 8562.029323][C0] lr : _raw_spin_unlock_irq+0x84/0xc0
> > > > > > [ 8562.036739][C0] sp : 698efaa0
> > > > > > [ 8562.042984][C0] x29: 698efaa0 x28: 6ad0f270
> > > > > > [ 8562.053814][C0] x27: 6ad0f248 x26: 698d4718
> > > > > > [ 8562.064687][C0] x25: 6ad0e798 x24: a000139e3a40
> > > > > > [ 8562.075506][C0] x23: 0001 x22: a000154f5000
> > > > > > [ 8562.086425][C0] x21: 6ad0e798 x20: 6ad0e780
> > > > > > [ 8562.097255][C0] x19: a000126a905c x18: 14c0
> > > > > > [ 8562.108071][C0] x17: 1500 x16: 1440
> > > > > > [ 8562.118918][C0] x15: f1f1f1f1 x14: 003d0900
> > > > > > [ 8562.129739][C0] x13: 3d09 x12: 8d31df41
> > > > > > [ 8562.140544][C0] x11: 1fffed31df40 x10: 8d31df40
> > > > > > [ 8562.151366][C0] x9 : dfffa000 x8 : 698efa07
> > > > > > [ 8562.162247][C0] x7 : 0001 x6 : 72ce20c0
> > > > > > [ 8562.173072][C0] x5 : 698d4040 x4 : dfffa000
> > > > > > [ 8562.183954][C0] x3 : a0001040f904 x2 : 0007
> > > > > > [ 8562.194811][C0] x1 : a0001408 x0 : 00e0
> > > > > > [ 8562.205858][C0] Call trace:
> > > > > > [ 8562.211739][C0]  arch_local_irq_enable+0x58/0x80
> > > > > > [ 8562.219076][C0]  _raw_spin_unlock_irq+0x84/0xc0
> > > > > > [ 8562.226394][C0]  __schedule+0x75c/0x7e0
> > > > > > [ 8562.233074][C0]  preempt_schedule_notrace+0x64/0xc0
> > > > > > [ 8562.268210][C0]  ftrace_ops_list_func+0x494/0x4e0
> > > > > > [ 8562.275735][C0]  ftrace_graph_call+0x0/0x4
> > > > > > [ 8562.282647][C0]  preempt_count_add+0xc/0x240
> > > > > > [ 8562.2

Re: linux-next: Tree for Aug 26

2020-08-28 Thread Anders Roxell
On Fri, 28 Aug 2020 at 15:29, Paul E. McKenney  wrote:
>
> On Fri, Aug 28, 2020 at 09:37:17AM +0200, Anders Roxell wrote:
> > On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney  wrote:
> > >
> > > On Wed, Aug 26, 2020 at 08:19:01PM +0200, Anders Roxell wrote:
> > > > On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell  
> > > > wrote:
> > >
> > > [ . . . ]
> > >
> > > > I've built and run an arm64 allmodconfig kernel where I use the
> > > > defconfig as the base, I do this for testing purposes.
> > > > I can see the following call trace [1]:
> > > >
> > > > [ 2595.811453][T1] Running tests on all trace events:
> > > > [ 2595.860933][T1] Testing all events:
> > > > [ 4316.066072][T8] kworker/dying (8) used greatest stack depth:
> > > > 27056 bytes left
> > > > [ 8561.924871][C0] watchdog: BUG: soft lockup - CPU#0 stuck for
> > > > 22s! [migration/0:14]
> > > > [ 8561.934498][C0] Modules linked in:
> > > > [ 8561.942303][C0] irq event stamp: 4044
> > > > [ 8561.949044][C0] hardirqs last  enabled at (4043):
> > > > [] _raw_spin_unlock_irqrestore+0xac/0x138
> > > > [ 8561.960848][C0] hardirqs last disabled at (4044):
> > > > [] __schedule+0xf8/0x7e0
> > > > [ 8561.971418][C0] softirqs last  enabled at (3698):
> > > > [] __do_softirq+0x524/0x5f8
> > > > [ 8561.982191][C0] softirqs last disabled at (3689):
> > > > [] __irq_exit_rcu+0x128/0x1a0
> > > > [ 8561.993068][C0] CPU: 0 PID: 14 Comm: migration/0 Tainted: G
> > > >W 5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1
> > > > [ 8562.005684][C0] Hardware name: linux,dummy-virt (DT)
> > > > [ 8562.013247][C0] pstate: 8045 (Nzcv daif +PAN -UAO BTYPE=--)
> > > > [ 8562.021657][C0] pc : arch_local_irq_enable+0x58/0x80
> > > > [ 8562.029323][C0] lr : _raw_spin_unlock_irq+0x84/0xc0
> > > > [ 8562.036739][C0] sp : 698efaa0
> > > > [ 8562.042984][C0] x29: 698efaa0 x28: 6ad0f270
> > > > [ 8562.053814][C0] x27: 6ad0f248 x26: 698d4718
> > > > [ 8562.064687][C0] x25: 6ad0e798 x24: a000139e3a40
> > > > [ 8562.075506][C0] x23: 0001 x22: a000154f5000
> > > > [ 8562.086425][C0] x21: 6ad0e798 x20: 6ad0e780
> > > > [ 8562.097255][C0] x19: a000126a905c x18: 14c0
> > > > [ 8562.108071][C0] x17: 1500 x16: 1440
> > > > [ 8562.118918][C0] x15: f1f1f1f1 x14: 003d0900
> > > > [ 8562.129739][C0] x13: 3d09 x12: 8d31df41
> > > > [ 8562.140544][C0] x11: 1fffed31df40 x10: 8d31df40
> > > > [ 8562.151366][C0] x9 : dfffa000 x8 : 698efa07
> > > > [ 8562.162247][C0] x7 : 0001 x6 : 72ce20c0
> > > > [ 8562.173072][C0] x5 : 698d4040 x4 : dfffa000
> > > > [ 8562.183954][C0] x3 : a0001040f904 x2 : 0007
> > > > [ 8562.194811][C0] x1 : a0001408 x0 : 00e0
> > > > [ 8562.205858][C0] Call trace:
> > > > [ 8562.211739][C0]  arch_local_irq_enable+0x58/0x80
> > > > [ 8562.219076][C0]  _raw_spin_unlock_irq+0x84/0xc0
> > > > [ 8562.226394][C0]  __schedule+0x75c/0x7e0
> > > > [ 8562.233074][C0]  preempt_schedule_notrace+0x64/0xc0
> > > > [ 8562.268210][C0]  ftrace_ops_list_func+0x494/0x4e0
> > > > [ 8562.275735][C0]  ftrace_graph_call+0x0/0x4
> > > > [ 8562.282647][C0]  preempt_count_add+0xc/0x240
> > > > [ 8562.289686][C0]  schedule+0xe4/0x160
> > > > [ 8562.296187][C0]  smpboot_thread_fn+0x47c/0x540
> > > > [ 8562.303377][C0]  kthread+0x23c/0x260
> > > > [ 8562.309906][C0]  ret_from_fork+0x10/0x18
> > > > [ 8562.316604][C0] Kernel panic - not syncing: softlockup: hung 
> > > > tasks
> > > > [ 8562.325230][C0] CPU: 0 PID: 14 Comm: migration/0 Tainted: G
> > > >WL5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1
> > > > [ 8562.337861][C0] Hardware name: linux,dummy-virt (DT)
> > > > [ 8562.345374][C0] Call trace:
> > > > [ 8562.351228][C0]  dump_backtrace+0x0/0x320
> > > > [ 8562.358070][C0]  show_stack+0x38/0x60
> > > > [

Re: Kernel panic : Unable to handle kernel paging request at virtual address - dead address between user and kernel address ranges

2020-08-28 Thread Anders Roxell
On Fri, 28 Aug 2020 at 11:35, Ulf Hansson  wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju  
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju  
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar  
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > > [3.680477]  dev_pm_opp_put_clkname+0x30/0x58
> > > > > > > [3.683431]  sdhci_msm_probe+0x284/0x9a0
> > > > >
> > > > > dev_pm_opp_put_clkname() is part of the error handling in the
> > > > > probe function, so I would deduct there are two problems:
> > > > >
> > > > > - something failed during the probe and the driver is trying
> > > > >   to unwind
> > > > > - the error handling it self is buggy and tries to undo something
> > > > >   again that has already been undone.
> > > >
> > > > Right.
> > > >
> > > > > This points to Viresh's
> > > > > d05a7238fe1c mmc: sdhci-msm: Unconditionally call 
> > > > > dev_pm_opp_of_remove_table()
> > > >
> > > > I completely forgot that Ulf already pushed this patch and I was
> > > > wondering on which of the OPP core changes I wrote have done this :(
> > > >
> > > > > Most likely this is not the entire problem but it uncovered a 
> > > > > preexisting
> > > > > bug.
> > > >
> > > > I think this is.
> > > >
> > > > Naresh: Can you please test with this diff ?
> > >
> > > I have applied your patch and tested but still see the reported problem.
> >
> > The git bisect shows that the first bad commit is,
> > d05a7238fe1c mmc: sdhci-msm: Unconditionally call 
> > dev_pm_opp_of_remove_table()
> >
> > Reported-by: Naresh Kamboju 
> > Reported-by: Anders Roxell 
>
> I am not sure what version of the patch you tested. However, I have
> dropped Viresh's v1 and replaced it with v2 [1]. It's available for
> testing at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
>
> Can you please check if it still causes problems, then I will drop it, again.

I tried to run with a kernel from your tree and I could see the same
kernel panic on db410c [1].

Cheers,
Anders
[1] https://lkft.validation.linaro.org/scheduler/job/1717770#L1912


Re: linux-next: Tree for Aug 26

2020-08-28 Thread Anders Roxell
On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney  wrote:
>
> On Wed, Aug 26, 2020 at 08:19:01PM +0200, Anders Roxell wrote:
> > On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell  
> > wrote:
>
> [ . . . ]
>
> > I've built and run an arm64 allmodconfig kernel where I use the
> > defconfig as the base, I do this for testing purposes.
> > I can see the following call trace [1]:
> >
> > [ 2595.811453][T1] Running tests on all trace events:
> > [ 2595.860933][T1] Testing all events:
> > [ 4316.066072][T8] kworker/dying (8) used greatest stack depth:
> > 27056 bytes left
> > [ 8561.924871][C0] watchdog: BUG: soft lockup - CPU#0 stuck for
> > 22s! [migration/0:14]
> > [ 8561.934498][C0] Modules linked in:
> > [ 8561.942303][C0] irq event stamp: 4044
> > [ 8561.949044][C0] hardirqs last  enabled at (4043):
> > [] _raw_spin_unlock_irqrestore+0xac/0x138
> > [ 8561.960848][C0] hardirqs last disabled at (4044):
> > [] __schedule+0xf8/0x7e0
> > [ 8561.971418][C0] softirqs last  enabled at (3698):
> > [] __do_softirq+0x524/0x5f8
> > [ 8561.982191][C0] softirqs last disabled at (3689):
> > [] __irq_exit_rcu+0x128/0x1a0
> > [ 8561.993068][C0] CPU: 0 PID: 14 Comm: migration/0 Tainted: G
> >W 5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1
> > [ 8562.005684][C0] Hardware name: linux,dummy-virt (DT)
> > [ 8562.013247][C0] pstate: 8045 (Nzcv daif +PAN -UAO BTYPE=--)
> > [ 8562.021657][C0] pc : arch_local_irq_enable+0x58/0x80
> > [ 8562.029323][C0] lr : _raw_spin_unlock_irq+0x84/0xc0
> > [ 8562.036739][C0] sp : 698efaa0
> > [ 8562.042984][C0] x29: 698efaa0 x28: 6ad0f270
> > [ 8562.053814][C0] x27: 6ad0f248 x26: 698d4718
> > [ 8562.064687][C0] x25: 6ad0e798 x24: a000139e3a40
> > [ 8562.075506][C0] x23: 0001 x22: a000154f5000
> > [ 8562.086425][C0] x21: 6ad0e798 x20: 6ad0e780
> > [ 8562.097255][C0] x19: a000126a905c x18: 14c0
> > [ 8562.108071][C0] x17: 1500 x16: 1440
> > [ 8562.118918][C0] x15: f1f1f1f1 x14: 003d0900
> > [ 8562.129739][C0] x13: 3d09 x12: 8d31df41
> > [ 8562.140544][C0] x11: 1fffed31df40 x10: 8d31df40
> > [ 8562.151366][C0] x9 : dfffa000 x8 : 698efa07
> > [ 8562.162247][C0] x7 : 0001 x6 : 72ce20c0
> > [ 8562.173072][C0] x5 : 698d4040 x4 : dfffa000
> > [ 8562.183954][C0] x3 : a0001040f904 x2 : 0007
> > [ 8562.194811][C0] x1 : a0001408 x0 : 00e0
> > [ 8562.205858][C0] Call trace:
> > [ 8562.211739][C0]  arch_local_irq_enable+0x58/0x80
> > [ 8562.219076][C0]  _raw_spin_unlock_irq+0x84/0xc0
> > [ 8562.226394][C0]  __schedule+0x75c/0x7e0
> > [ 8562.233074][C0]  preempt_schedule_notrace+0x64/0xc0
> > [ 8562.268210][C0]  ftrace_ops_list_func+0x494/0x4e0
> > [ 8562.275735][C0]  ftrace_graph_call+0x0/0x4
> > [ 8562.282647][C0]  preempt_count_add+0xc/0x240
> > [ 8562.289686][C0]  schedule+0xe4/0x160
> > [ 8562.296187][C0]  smpboot_thread_fn+0x47c/0x540
> > [ 8562.303377][C0]  kthread+0x23c/0x260
> > [ 8562.309906][C0]  ret_from_fork+0x10/0x18
> > [ 8562.316604][C0] Kernel panic - not syncing: softlockup: hung tasks
> > [ 8562.325230][C0] CPU: 0 PID: 14 Comm: migration/0 Tainted: G
> >WL5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1
> > [ 8562.337861][C0] Hardware name: linux,dummy-virt (DT)
> > [ 8562.345374][C0] Call trace:
> > [ 8562.351228][C0]  dump_backtrace+0x0/0x320
> > [ 8562.358070][C0]  show_stack+0x38/0x60
> > [ 8562.364728][C0]  dump_stack+0x1c0/0x280
> > [ 8562.371447][C0]  panic+0x32c/0x614
> > [ 8562.377868][C0]  watchdog_timer_fn+0x49c/0x560
> > [ 8562.385076][C0]  __run_hrtimer+0x1cc/0x360
> > [ 8562.392021][C0]  __hrtimer_run_queues+0x1a0/0x220
> > [ 8562.399500][C0]  hrtimer_interrupt+0x1f8/0x440
> > [ 8562.406807][C0]  arch_timer_handler_virt+0x68/0xa0
> > [ 8562.414338][C0]  handle_percpu_devid_irq+0x118/0x2a0
> > [ 8562.421992][C0]  __handle_domain_irq+0x150/0x1c0
> > [ 8562.429315][C0]  gic_handle_irq+0x98/0x120
> > [ 8562.436297][C0]  el1_irq+0xd4/0x1c0
>
> We appear to have taken an interrupt here, just after releasing
> an irq-disabled lock and enabling interrupts.
>
> > [ 8562.442748][C0]  arch_local_ir

Re: linux-next: Tree for Aug 27

2020-08-27 Thread Anders Roxell
On Thu, 27 Aug 2020 at 07:11, Stephen Rothwell  wrote:
>
> Hi all,
>
> News:  There will be no linux-next releases next Monday or Tuesday.
>
> Changes since 20200826:
>
> The net-next tree gained a conflict against the net tree.
>
> Non-merge commits (relative to Linus' tree): 2901
>  3429 files changed, 100496 insertions(+), 37081 deletions(-)
>

I built riscv on todays tag and I see this error:
../arch/riscv/kernel/setup.c: In function ‘setup_arch’:
../arch/riscv/kernel/setup.c:74:2: error: implicit declaration of
function ‘early_ioremap_setup’; did you mean ‘early_memtest’?
[-Werror=implicit-function-declaration]
  early_ioremap_setup();
  ^~~
  early_memtest
cc1: some warnings being treated as errors

I think its due to commit 3d109b0e0949 ("RISC-V: Add early ioremap support")

It builds with this fix:

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 5ab185130cae..41ef96d0d97a 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -19,6 +19,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 
 #include 


Cheers,
Anders


Re: linux-next: Tree for Aug 26

2020-08-26 Thread Anders Roxell
On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell  wrote:
>
> Hi all,
>
> News:  There will be no linux-next releases next Monday or Tuesday.
>
> Changes since 20200825:
>
> The bpf-next tree lost its build failure.
>
> The drm-misc tree gained conflicts against Linus' tree and the amdgpu
> tree.  It also gained a semantic conflict against the drm-misc-fixes tree.
>
> Non-merge commits (relative to Linus' tree): 2773
>  3346 files changed, 94589 insertions(+), 35418 deletions(-)
>
> 
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log
> files in the Next directory.  Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig and htmldocs. And finally, a simple boot test
> of the powerpc pseries_le_defconfig kernel in qemu (with and without
> kvm enabled).
>
> Below is a summary of the state of the merge.
>
> I am currently merging 328 trees (counting Linus' and 86 trees of bug
> fix patches pending for the current merge release).
>
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
>
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
>
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
>
> --
> Cheers,
> Stephen Rothwell
>
> $ git checkout master
> $ git reset --hard stable
> Merging origin/master (abb3438d69fb Merge tag 'm68knommu-for-v5.9-rc3' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu)
> Merging fixes/master (9123e3a74ec7 Linux 5.9-rc1)
> Merging kbuild-current/fixes (510bc3cb1ddc kconfig: qconf: replace deprecated 
> QString::sprintf() with QTextStream)
> Merging arc-current/for-curr (37016ab49214 irqchip/eznps: Fix build error for 
> !ARC700 builds)
> Merging arm-current/fixes (5c6360ee4a0e ARM: 8988/1: mmu: fix crash in EFI 
> calls due to p4d typo in create_mapping_late())
> Merging arm64-fixes/for-next/fixes (8d75785a8142 ARM64: vdso32: Install 
> vdso32 from vdso_install)
> Merging arm-soc-fixes/arm/fixes (9c8b0a9c37b7 Merge tag 'imx-fixes-5.9' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes)
> Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2)
> Merging drivers-memory-fixes/fixes (7ff3a2a626f7 memory: jz4780_nemc: Fix an 
> error pointer vs NULL check in probe())
> Merging m68k-current/for-linus (382f429bb559 m68k: defconfig: Update 
> defconfigs for v5.8-rc3)
> Merging powerpc-fixes/fixes (64ef8f2c4791 powerpc/perf/hv-24x7: Move cpumask 
> file to top folder of hv-24x7 driver)
> Merging s390-fixes/fixes (b97bf44f9915 s390/pci: fix PF/VF linking on hot 
> plug)
> Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
> Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty 
> inodes after removing key)
> Merging net/master (2c6500e82e51 net: ethernet: ti: cpsw_new: fix clean up of 
> vlan mc entries for host port)
> Merging bpf/master (7787b6fc938e bpf, sysctl: Let bpf_stats_handler take a 
> kernel pointer buffer)
> Merging ipsec/master (4eb2e1341575 espintcp: restore IP CB before handing the 
> packet to xfrm)
> Merging netfilter/master (3622adb02623 ipv6: ndisc: adjust 
> ndisc_ifinfo_sysctl_change prototype)
> Merging ipvs/master (7c7ab580db49 net: Convert to use the fallthrough macro)
> Merging wireless-drivers/master (9a2a0862d973 brcmfmac: reserve tx credit 
> only when txctl is ready to send)
> Merging mac80211/master (fce2ff728f95 nl80211: fix 
> NL80211_ATTR_HE_6GHZ_CAPABILITY usage)
> Merging rdma-fixes/for-rc (60b1af64eb35 RDMA/rxe: Fix the parent sysfs read 
> when the interface has 15 chars)
> Merging sound-current/for-linus (eed8f88b109a Revert "ALSA: hda: Add support 
> for Loongson 7A1000 controller")
> Merging sound-asoc-fixes/for-linus (d062085d61b1 ASoC: ti: fixup 
> ams_delta_mute() function name)
> Merging regmap-fixes/for-linus (d012a7190fc1 Linux 5.9-rc2)
> Merging regulator-fixes/fo

Re: BUG: Bad page state in process true pfn:a8fed on arm

2020-08-25 Thread Anders Roxell
On Tue, 25 Aug 2020 at 10:32, Mike Rapoport  wrote:
>
> On Tue, Aug 25, 2020 at 01:03:53PM +0530, Naresh Kamboju wrote:
> > On Mon, 24 Aug 2020 at 16:36, Matthew Wilcox  wrote:
> > >
> > > On Mon, Aug 24, 2020 at 03:14:55PM +0530, Naresh Kamboju wrote:
> > > > [   67.545247] BUG: Bad page state in process true  pfn:a8fed
> > > > [   67.550767] page:9640c0ab refcount:0 mapcount:-1024
> > >
> > > Somebody freed a page table without calling __ClearPageTable() on it.
> >
> > After running git bisect on this problem,
> > The first suspecting of this problem on arm architecture this patch.
> > 424efe723f7717430bec7c93b4d28bba73e31cf6
> > ("mm: account PMD tables like PTE tables ")
> >
> > Reported-by: Naresh Kamboju 
> > Reported-by: Anders Roxell 
>
> Can you please check if this fix helps?

That fixed the problem.

Cheers,
Anders

>
> diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
> index 9415222b49ad..b8cbe03ad260 100644
> --- a/arch/arm/include/asm/tlb.h
> +++ b/arch/arm/include/asm/tlb.h
> @@ -59,6 +59,7 @@ __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmdp, 
> unsigned long addr)
>  #ifdef CONFIG_ARM_LPAE
> struct page *page = virt_to_page(pmdp);
>
> +   pgtable_pmd_page_dtor(page);
> tlb_remove_table(tlb, page);
>  #endif
>  }
>
> > Additional information:
> > We have tested linux next by reverting this patch and confirmed
> > that the reported BUG is not reproduced.
> >
> > These configs enabled on the running device,
> >
> > CONFIG_TRANSPARENT_HUGEPAGE=y
> > CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
> >
> >
> > -- Suspecting patch --
> > commit 424efe723f7717430bec7c93b4d28bba73e31cf6
> > Author: Matthew Wilcox 
> > Date:   Thu Aug 20 10:01:30 2020 +1000
> >
> > mm: account PMD tables like PTE tables
> >
> > We account the PTE level of the page tables to the process in order to
> > make smarter OOM decisions and help diagnose why memory is fragmented.
> > For these same reasons, we should account pages allocated for PMDs.  
> > With
> > larger process address spaces and ASLR, the number of PMDs in use is
> > higher than it used to be so the inaccuracy is starting to matter.
> >
> > Link: 
> > http://lkml.kernel.org/r/20200627184642.gf25...@casper.infradead.org
> > Signed-off-by: Matthew Wilcox (Oracle) 
> > Reviewed-by: Mike Rapoport 
> > Cc: Abdul Haleem 
> > Cc: Andy Lutomirski 
> > Cc: Arnd Bergmann 
> > Cc: Christophe Leroy 
> > Cc: Joerg Roedel 
> > Cc: Max Filippov 
> > Cc: Peter Zijlstra 
> > Cc: Satheesh Rajendran 
> > Cc: Stafford Horne 
> > Signed-off-by: Andrew Morton 
> > Signed-off-by: Stephen Rothwell 
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index b0a15ee77b8a..a4e5b806347c 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -2239,7 +2239,7 @@ static inline spinlock_t *pmd_lockptr(struct
> > mm_struct *mm, pmd_t *pmd)
> >   return ptlock_ptr(pmd_to_page(pmd));
> >  }
> >
> > -static inline bool pgtable_pmd_page_ctor(struct page *page)
> > +static inline bool pmd_ptlock_init(struct page *page)
> >  {
> >  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >   page->pmd_huge_pte = NULL;
> > @@ -2247,7 +2247,7 @@ static inline bool pgtable_pmd_page_ctor(struct
> > page *page)
> >   return ptlock_init(page);
> >  }
> >
> > -static inline void pgtable_pmd_page_dtor(struct page *page)
> > +static inline void pmd_ptlock_free(struct page *page)
> >  {
> >  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >   VM_BUG_ON_PAGE(page->pmd_huge_pte, page);
> > @@ -2264,8 +2264,8 @@ static inline spinlock_t *pmd_lockptr(struct
> > mm_struct *mm, pmd_t *pmd)
> >   return &mm->page_table_lock;
> >  }
> >
> > -static inline bool pgtable_pmd_page_ctor(struct page *page) { return true; 
> > }
> > -static inline void pgtable_pmd_page_dtor(struct page *page) {}
> > +static inline bool pmd_ptlock_init(struct page *page) { return true; }
> > +static inline void pmd_ptlock_free(struct page *page) {}
> >
> >  #define pmd_huge_pte(mm, pmd) ((mm)->pmd_huge_pte)
> >
> > @@ -2278,6 +2278,22 @@ static inline spinlock_t *pmd_lock(struct
> > mm_struct *mm, pmd_t *pmd)
> >   return ptl;
> >  }
> >
> > +static inline bool pgtable_pmd_page_ctor(struct page *page)
> > +{
> > + if (!pmd_ptlock_init(page))
> > + return false;
> > + __SetPageTable(page);
> > + inc_zone_page_state(page, NR_PAGETABLE);
> > + return true;
> > +}
> > +
> > +static inline void pgtable_pmd_page_dtor(struct page *page)
> > +{
> > + pmd_ptlock_free(page);
> > + __ClearPageTable(page);
> > + dec_zone_page_state(page, NR_PAGETABLE);
> > +}
> > +
> >  /*
> >   * No scalability reason to split PUD locks yet, but follow the same 
> > pattern
> >   * as the PMD locks to make it easier if we decide to.  The VM should not 
> > be
> >
> >
> >
> >
> > - Naresh
>
> --
> Sincerely yours,
> Mike.


Re: linux-next: Tree for Jul 9

2020-07-09 Thread Anders Roxell
On Thu, 9 Jul 2020 at 11:18, Stephen Rothwell  wrote:
>
> Hi all,
>
> Changes since 20200708:
>
> My fixes tree contains:
>
>   dbf24e30ce2e ("device_cgroup: Fix RCU list debugging warning")
>   b236d81d9e4f ("powerpc/boot/dts: Fix dtc "pciex" warnings")
>
> The kbuild tree still had its build failure for which I reverted a commit.
>
> The scmi tree gained a build failure so I used the version from
> next-20200708;
>
> The net-next tree gained a conflict against the pci tree.
>
> The block tree gained conflicts against the btrfs and fscrypt trees.
>
> The device-mapper tree gained a conflict against the block tree.
>
> The security tree still had its build failure for which I applied a patch.
>
> The tip tree still had one build failure for which I reverted a commit.
>
> The akpm-current tree gained a conflict against the userns tree and a
> build failure for which I reverted 2 commits.
>
> The akpm tree lost a patch that turned up elsewhere.
>
> Non-merge commits (relative to Linus' tree): 5915
>  6780 files changed, 362395 insertions(+), 141614 deletions(-)
>

Today's tag doesn't build on arm64.
I think this patch e76b573f11d1 ("arm64: mte: Add
PTRACE_{PEEK,POKE}MTETAGS support")
broke the build due to this patch was included also
dc766e66c2b3 ("mm/gup: remove task_struct pointer for all gup code")...

/srv/src/kernel/next/arch/arm64/kernel/mte.c: In function
‘__access_remote_tags’:
/srv/src/kernel/next/arch/arm64/kernel/mte.c:224:31: error: passing
argument 1 of ‘get_user_pages_remote’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
  224 |   ret = get_user_pages_remote(tsk, mm, addr, 1, gup_flags,
  |   ^~~
  |   |
  |   struct task_struct *
In file included from /srv/src/kernel/next/arch/arm64/kernel/mte.c:8:
/srv/src/kernel/next/include/linux/mm.h:1707:46: note: expected
‘struct mm_struct *’ but argument is of type ‘struct task_struct *’
 1707 | long get_user_pages_remote(struct mm_struct *mm,
  |~~^~
/srv/src/kernel/next/arch/arm64/kernel/mte.c:224:36: warning: passing
argument 2 of ‘get_user_pages_remote’ makes integer from pointer
without a cast [-Wint-conversion]
  224 |   ret = get_user_pages_remote(tsk, mm, addr, 1, gup_flags,
  |^~
  ||
  |struct mm_struct *
In file included from /srv/src/kernel/next/arch/arm64/kernel/mte.c:8:
/srv/src/kernel/next/include/linux/mm.h:1708:22: note: expected ‘long
unsigned int’ but argument is of type ‘struct mm_struct *’
 1708 |unsigned long start, unsigned long nr_pages,
  |~~^
/srv/src/kernel/next/arch/arm64/kernel/mte.c:224:49: warning: passing
argument 5 of ‘get_user_pages_remote’ makes pointer from integer
without a cast [-Wint-conversion]
  224 |   ret = get_user_pages_remote(tsk, mm, addr, 1, gup_flags,
  | ^
  | |
  | unsigned int
In file included from /srv/src/kernel/next/arch/arm64/kernel/mte.c:8:
/srv/src/kernel/next/include/linux/mm.h:1709:46: note: expected
‘struct page **’ but argument is of type ‘unsigned int’
 1709 |unsigned int gup_flags, struct page **pages,
  |~~^
/srv/src/kernel/next/arch/arm64/kernel/mte.c:225:10: error: passing
argument 6 of ‘get_user_pages_remote’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
  225 |  &page, &vma, NULL);
  |  ^
  |  |
  |  struct page **
In file included from /srv/src/kernel/next/arch/arm64/kernel/mte.c:8:
/srv/src/kernel/next/include/linux/mm.h:1710:32: note: expected
‘struct vm_area_struct **’ but argument is of type ‘struct page **’
 1710 |struct vm_area_struct **vmas, int *locked);
  |^~~~
/srv/src/kernel/next/arch/arm64/kernel/mte.c:225:17: error: passing
argument 7 of ‘get_user_pages_remote’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
  225 |  &page, &vma, NULL);
  | ^~~~
  | |
  | struct vm_area_struct **
In file included from /srv/src/kernel/next/arch/arm64/kernel/mte.c:8:
/srv/src/kernel/next/include/linux/mm.h:1710:43: note: expected ‘int
*’ but argument is of type ‘struct vm_area_struct **’
 1710 |struct vm_area_struct **vmas, int *locked);
  |  ~^~
/srv/src/kernel/next/arch/arm64/kernel/mte.c:224:9: error: too many
arguments to function ‘get_user_pages_remote’
  224 |   ret = get_user_pages_remote(tsk, mm, addr, 1, gup_flags,
  | ^
In file included from /srv/src/kernel/ne

Re: [PATCH v2 1/2] kbuild: introduce ccflags-remove-y and asflags-remove-y

2020-07-07 Thread Anders Roxell
On Tue, 7 Jul 2020 at 11:21, Masahiro Yamada  wrote:
>
> CFLAGS_REMOVE_.o filters out flags when compiling a particular
> object, but there is no convenient way to do that for every object in
> a directory.
>
> Add ccflags-remove-y and asflags-remove-y to make it easily.
>
> Use ccflags-remove-y to clean up some Makefiles.
>
> The add/remove order works as follows:
>
>  [1] KBUILD_CFLAGS specifies compiler flags used globally
>
>  [2] ccflags-y adds compiler flags for all objects in the
>  current Makefile
>
>  [3] ccflags-remove-y removes compiler flags for all objects in the
>  current Makefile (New feature)
>
>  [4] CFLAGS_ adds compiler flags per file.
>
>  [5] CFLAGS_REMOVE_ removes compiler flags per file.
>
> Having [3] before [4] allows us to remove flags from most (but not all)
> objects in the current Makefile.
>
> For example, kernel/trace/Makefile removes $(CC_FLAGS_FTRACE)
> from all objects in the directory, then adds it back to
> trace_selftest_dynamic.o and CFLAGS_trace_kprobe_selftest.o
>
> Please note ccflags-remove-y has no effect to the sub-directories.
> In contrast, the previous notation got rid of compiler flags also from
> all the sub-directories.
>
>   arch/arm/boot/compressed/
>   arch/powerpc/xmon/
>   arch/sh/
>   kernel/trace/
>
> ... have no sub-directories.
>
>   lib/
>
> ... has several sub-directories.
>
> To keep the behavior, I added ccflags-remove-y to all Makefiles
> in subdirectories of lib/, except:
>
>   lib/vdso/Makefile- Kbuild does not descend into this Makefile
>   lib/raid/test/Makefile   - This is not used for the kernel build
>
> I think commit 2464a609ded0 ("ftrace: do not trace library functions")
> excluded too much. In later commit, I will try to remove ccflags-remove-y
> from sub-directory Makefiles.
>
> Suggested-by: Sami Tolvanen 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Steven Rostedt (VMware) 
> Acked-by: Michael Ellerman  (powerpc)

Tested-by: Anders Roxell 

> ---
>
> Changes in v2:
>   - Swap the order of [3] and [4] to keep the current behavior of
> kernel/trace/Makefile.
>   - Add ccflags-remove-y to subdir Makefiles of lib/
>
>  Documentation/kbuild/makefiles.rst | 14 ++
>  arch/arm/boot/compressed/Makefile  |  6 +-
>  arch/powerpc/xmon/Makefile |  3 +--
>  arch/sh/boot/compressed/Makefile   |  5 +
>  kernel/trace/Makefile  |  4 ++--
>  lib/842/Makefile   |  3 +++
>  lib/Makefile   |  5 +
>  lib/crypto/Makefile|  2 ++
>  lib/dim/Makefile   |  2 ++
>  lib/fonts/Makefile |  2 ++
>  lib/kunit/Makefile |  3 +++
>  lib/livepatch/Makefile |  2 ++
>  lib/lz4/Makefile   |  1 +
>  lib/lzo/Makefile   |  2 ++
>  lib/math/Makefile  |  2 ++
>  lib/mpi/Makefile   |  2 ++
>  lib/raid6/Makefile |  3 +++
>  lib/reed_solomon/Makefile  |  2 ++
>  lib/xz/Makefile|  3 +++
>  lib/zlib_deflate/Makefile  |  2 ++
>  lib/zlib_dfltcc/Makefile   |  2 ++
>  lib/zlib_inflate/Makefile  |  2 ++
>  lib/zstd/Makefile  |  1 +
>  scripts/Makefile.lib   | 14 --
>  24 files changed, 64 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.rst 
> b/Documentation/kbuild/makefiles.rst
> index 6515ebc12b6f..14d8e7d23c04 100644
> --- a/Documentation/kbuild/makefiles.rst
> +++ b/Documentation/kbuild/makefiles.rst
> @@ -368,6 +368,14 @@ more details, with real examples.
>
> subdir-ccflags-y := -Werror
>
> +ccflags-remove-y, asflags-remove-y
> +   These flags are used to remove particular flags for the compiler,
> +   assembler invocations.
> +
> +   Example::
> +
> +   ccflags-remove-$(CONFIG_MCOUNT) += -pg
> +
>  CFLAGS_$@, AFLAGS_$@
> CFLAGS_$@ and AFLAGS_$@ only apply to commands in current
> kbuild makefile.
> @@ -375,6 +383,9 @@ more details, with real examples.
> $(CFLAGS_$@) specifies per-file options for $(CC).  The $@
> part has a literal value which specifies the file that it is for.
>
> +   CFLAGS_$@ has the higher priority than ccflags-remove-y; CFLAGS_$@
> +   can re-add compiler flags that were removed by ccflags-remove-y.
> +
> Example::
>
> # drivers/scsi/Makefile
> @@ -387,6 +398,9 @@ more details, with real examples.
> $(AFLAGS_$@) is a similar feature for source files in assembly
> languages.
>

Re: [PATCH] kbuild: introduce ccflags-remove-y and asflags-remove-y

2020-07-06 Thread Anders Roxell
On Mon, 6 Jul 2020 at 13:24, Anders Roxell  wrote:
>
> Hi,
>
> When I built an allmodconfig kernel for arm64, and boot that in qemu
> guest I see the following issues:
>
> [...]
> [   10.451561][T1] Testing tracer function: PASSED
> [   33.087895][T1] Testing dynamic ftrace: .. filter did not
> filter .. FAILED!
> [   51.127094][T1] [ cut here ]
> [   51.132387][T1] WARNING: CPU: 0 PID: 1 at
> kernel/trace/trace.c:1814 run_tracer_selftest+0x314/0x40c
> [   51.140805][T1] Modules linked in:
> [   51.145398][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.8.0-rc3-next-20200703-4-g8cd4bc531754 #1
> [   51.154146][T1] Hardware name: linux,dummy-virt (DT)
> [   51.159536][T1] pstate: 8045 (Nzcv daif +PAN -UAO BTYPE=--)
> [   51.165711][T1] pc : run_tracer_selftest+0x314/0x40c
> [   51.171167][T1] lr : run_tracer_selftest+0x308/0x40c
> [   51.176475][T1] sp : 69c07c40
> [   51.180855][T1] x29: 69c07c40 x28: a00015e80320
> [   51.187187][T1] x27: a00013e074a0 x26: a000150f22ee
> [   51.193520][T1] x25: a000125b35a0 x24: a00013f6a000
> [   51.199868][T1] x23: a00013f6adc0 x22: 
> [   51.206225][T1] x21: a000150f2250 x20: a00015e801c0
> [   51.212582][T1] x19: a00015e7fa80 x18: 2750
> [   51.218887][T1] x17: 14c0 x16: 16f0
> [   51.225229][T1] x15: 14f8 x14: a0001000a3c8
> [   51.231584][T1] x13: a000124a5fb8 x12: 8d494822
> [   51.237935][T1] x11: 1fffed494821 x10: 8d494821
> [   51.244293][T1] x9 : a000101763b0 x8 : 69c077d7
> [   51.250704][T1] x7 : 0001 x6 : 69c077d0
> [   51.257060][T1] x5 : 6a7fc040 x4 : 
> [   51.263423][T1] x3 : a0001028 x2 : 8af050918b00
> [   51.269757][T1] x1 :  x0 : 0001
> [   51.276084][T1] Call trace:
> [   51.279934][T1]  run_tracer_selftest+0x314/0x40c
> [   51.285174][T1]  init_trace_selftests+0x110/0x31c
> [   51.290391][T1]  do_one_initcall+0x410/0x960
> [   51.295315][T1]  kernel_init_freeable+0x430/0x4f0
> [   51.300595][T1]  kernel_init+0x20/0x1d8
> [   51.305180][T1]  ret_from_fork+0x10/0x18
> [   51.309741][T1] irq event stamp: 1401832
> [   51.314399][T1] hardirqs last  enabled at (1401831):
> [] console_unlock+0xc04/0xd10
> [   51.322973][T1] hardirqs last disabled at (1401832):
> [] debug_exception_enter+0xbc/0x200
> [   51.331993][T1] softirqs last  enabled at (1401828):
> [] __do_softirq+0x95c/0x9f8
> [   51.340490][T1] softirqs last disabled at (1401821):
> [] irq_exit+0x118/0x198
> [   51.348717][T1] _warn_unseeded_randomness: 5 callbacks suppressed
> [   51.349263][T1] random: get_random_bytes called from
> print_oops_end_marker+0x48/0x80 with crng_init=0
> [   51.350502][T1] ---[ end trace c566e8a71c933d3c ]---
> [...]
> [40709.672335][C0] pool 2: cpus=0 flags=0x5 nice=0 hung=3s
> workers=3 manager: 1455
> [40739.960593][   T26] INFO: lockdep is turned off.
> [40775.312499][   T26] Kernel panic - not syncing: hung_task: blocked tasks
> [40775.341521][   T26] CPU: 0 PID: 26 Comm: khungtaskd Tainted: G
>   W 5.8.0-rc3-next-20200703-4-g8cd4bc531754 #1
> [40775.352848][   T26] Hardware name: linux,dummy-virt (DT)
> [40775.359304][   T26] Call trace:
> [40775.364148][   T26]  dump_backtrace+0x0/0x418
> [40775.369918][   T26]  show_stack+0x34/0x48
> [40775.375468][   T26]  dump_stack+0x1f4/0x2b0
> [40775.381136][   T26]  panic+0x2dc/0x6ec
> [40775.386430][   T26]  watchdog+0x1400/0x1460
> [40775.392103][   T26]  kthread+0x23c/0x250
> [40775.397548][   T26]  ret_from_fork+0x10/0x18
> [40775.407039][   T26] Kernel Offset: disabled
> [40775.412634][   T26] CPU features: 0x240002,20002004
> [40775.418751][   T26] Memory Limit: none
> [40775.425823][   T26] ---[ end Kernel panic - not syncing: hung_task:
> blocked tasks ]---
>
> The full log can be found here [1].
>
> Without this patch for  'trace_selftest_dynamic' for instance, CC_FLAGS_FTRACE
> was removed from kernel/trace/*, and then added back to
> kernel/trace/trace_selftest_dynamic.
> While with this patch it looks like we add the flag (even though it is
> already there), and then
> removes the flag for all files in kernel/trace/* .

Hi again,

I think the patch below solved the issue for trace_selftest_dynamic. However,
I think there is still differences in lib/* .

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index cc5e3c6aaa20..5632a711921f 100644
--- a/scripts/Makefile.lib
+++ b/scri

Re: [PATCH] kbuild: introduce ccflags-remove-y and asflags-remove-y

2020-07-06 Thread Anders Roxell
Hi,

When I built an allmodconfig kernel for arm64, and boot that in qemu
guest I see the following issues:

[...]
[   10.451561][T1] Testing tracer function: PASSED
[   33.087895][T1] Testing dynamic ftrace: .. filter did not
filter .. FAILED!
[   51.127094][T1] [ cut here ]
[   51.132387][T1] WARNING: CPU: 0 PID: 1 at
kernel/trace/trace.c:1814 run_tracer_selftest+0x314/0x40c
[   51.140805][T1] Modules linked in:
[   51.145398][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.8.0-rc3-next-20200703-4-g8cd4bc531754 #1
[   51.154146][T1] Hardware name: linux,dummy-virt (DT)
[   51.159536][T1] pstate: 8045 (Nzcv daif +PAN -UAO BTYPE=--)
[   51.165711][T1] pc : run_tracer_selftest+0x314/0x40c
[   51.171167][T1] lr : run_tracer_selftest+0x308/0x40c
[   51.176475][T1] sp : 69c07c40
[   51.180855][T1] x29: 69c07c40 x28: a00015e80320
[   51.187187][T1] x27: a00013e074a0 x26: a000150f22ee
[   51.193520][T1] x25: a000125b35a0 x24: a00013f6a000
[   51.199868][T1] x23: a00013f6adc0 x22: 
[   51.206225][T1] x21: a000150f2250 x20: a00015e801c0
[   51.212582][T1] x19: a00015e7fa80 x18: 2750
[   51.218887][T1] x17: 14c0 x16: 16f0
[   51.225229][T1] x15: 14f8 x14: a0001000a3c8
[   51.231584][T1] x13: a000124a5fb8 x12: 8d494822
[   51.237935][T1] x11: 1fffed494821 x10: 8d494821
[   51.244293][T1] x9 : a000101763b0 x8 : 69c077d7
[   51.250704][T1] x7 : 0001 x6 : 69c077d0
[   51.257060][T1] x5 : 6a7fc040 x4 : 
[   51.263423][T1] x3 : a0001028 x2 : 8af050918b00
[   51.269757][T1] x1 :  x0 : 0001
[   51.276084][T1] Call trace:
[   51.279934][T1]  run_tracer_selftest+0x314/0x40c
[   51.285174][T1]  init_trace_selftests+0x110/0x31c
[   51.290391][T1]  do_one_initcall+0x410/0x960
[   51.295315][T1]  kernel_init_freeable+0x430/0x4f0
[   51.300595][T1]  kernel_init+0x20/0x1d8
[   51.305180][T1]  ret_from_fork+0x10/0x18
[   51.309741][T1] irq event stamp: 1401832
[   51.314399][T1] hardirqs last  enabled at (1401831):
[] console_unlock+0xc04/0xd10
[   51.322973][T1] hardirqs last disabled at (1401832):
[] debug_exception_enter+0xbc/0x200
[   51.331993][T1] softirqs last  enabled at (1401828):
[] __do_softirq+0x95c/0x9f8
[   51.340490][T1] softirqs last disabled at (1401821):
[] irq_exit+0x118/0x198
[   51.348717][T1] _warn_unseeded_randomness: 5 callbacks suppressed
[   51.349263][T1] random: get_random_bytes called from
print_oops_end_marker+0x48/0x80 with crng_init=0
[   51.350502][T1] ---[ end trace c566e8a71c933d3c ]---
[...]
[40709.672335][C0] pool 2: cpus=0 flags=0x5 nice=0 hung=3s
workers=3 manager: 1455
[40739.960593][   T26] INFO: lockdep is turned off.
[40775.312499][   T26] Kernel panic - not syncing: hung_task: blocked tasks
[40775.341521][   T26] CPU: 0 PID: 26 Comm: khungtaskd Tainted: G
  W 5.8.0-rc3-next-20200703-4-g8cd4bc531754 #1
[40775.352848][   T26] Hardware name: linux,dummy-virt (DT)
[40775.359304][   T26] Call trace:
[40775.364148][   T26]  dump_backtrace+0x0/0x418
[40775.369918][   T26]  show_stack+0x34/0x48
[40775.375468][   T26]  dump_stack+0x1f4/0x2b0
[40775.381136][   T26]  panic+0x2dc/0x6ec
[40775.386430][   T26]  watchdog+0x1400/0x1460
[40775.392103][   T26]  kthread+0x23c/0x250
[40775.397548][   T26]  ret_from_fork+0x10/0x18
[40775.407039][   T26] Kernel Offset: disabled
[40775.412634][   T26] CPU features: 0x240002,20002004
[40775.418751][   T26] Memory Limit: none
[40775.425823][   T26] ---[ end Kernel panic - not syncing: hung_task:
blocked tasks ]---

The full log can be found here [1].

Without this patch for  'trace_selftest_dynamic' for instance, CC_FLAGS_FTRACE
was removed from kernel/trace/*, and then added back to
kernel/trace/trace_selftest_dynamic.
While with this patch it looks like we add the flag (even though it is
already there), and then
removes the flag for all files in kernel/trace/* .

Cheers,
Anders
[1] https://people.linaro.org/~anders.roxell/output-next-20200703.log

On Tue, 30 Jun 2020 at 04:09, Masahiro Yamada  wrote:
>
> On Mon, Jun 29, 2020 at 2:55 PM Michael Ellerman  wrote:
> >
> > Masahiro Yamada  writes:
> > > CFLAGS_REMOVE_.o works per object, that is, there is no
> > > convenient way to filter out flags for every object in a directory.
> > >
> > > Add ccflags-remove-y and asflags-remove-y to make it easily.
> > >
> > > Use ccflags-remove-y to clean up some Makefiles.
> > >
> > > Suggested-by: Sami Tolvanen 
> > > Signed-off-by: Masahiro Yamada 
> > > ---
> > >
> > >  arch/arm/boot/compressed/Makefile | 6 +-
> > >  arch/powerpc/xmon/Makefile| 3 +--
> > >  arch/sh/boot/compressed/Makefile  | 5 +
> > >  kernel/trac

Re: [PATCH v3 0/6] Enable as many KUnit tests as possible

2020-05-27 Thread Anders Roxell
Hi all,

Friendly ping: who can take this?

Cheers,
Anders

On Mon, 11 May 2020 at 15:14, Anders Roxell  wrote:
>
> Hi,
>
> This patchset will try to enable as many KUnit test fragments as
> possible for the current .config file.
> This will make it easier for both developers that tests their specific
> feature and also for test-systems that would like to get as much as
> possible for their current .config file.
>
> I will send a separate KCSAN KUnit patch after this patchset since that
> isn't in mainline yet.
>
> Since v2:
> Fixed David's comments. KUNIT_RUN_ALL -> KUNIT_ALL_TESTS, and he
> suggested a great help text.
>
> Since v1:
> Marco commented to split up the patches, and change a "." to a ",".
>
>
> Cheers,
> Anders
>
> Anders Roxell (6):
>   kunit: Kconfig: enable a KUNIT_ALL_TESTS fragment
>   kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS
>   lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_ALL_TESTS
>   drivers: base: default KUNIT_* fragments to KUNIT_ALL_TESTS
>   fs: ext4: default KUNIT_* fragments to KUNIT_ALL_TESTS
>   security: apparmor: default KUNIT_* fragments to KUNIT_ALL_TESTS
>
>  drivers/base/Kconfig  |  3 ++-
>  drivers/base/test/Kconfig |  3 ++-
>  fs/ext4/Kconfig   |  3 ++-
>  lib/Kconfig.debug |  6 --
>  lib/kunit/Kconfig | 23 ---
>  security/apparmor/Kconfig |  3 ++-
>  6 files changed, 32 insertions(+), 9 deletions(-)
>
> --
> 2.20.1
>


[PATCH 1/5] power: vexpress: add suppress_bind_attrs to true

2020-05-27 Thread Anders Roxell
Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind
attributes available via the sysfs, so lets be explicit here and use
".suppress_bind_attrs = true" to prevent userspace from doing something
silly.

Signed-off-by: Anders Roxell 
---
 drivers/power/reset/vexpress-poweroff.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/power/reset/vexpress-poweroff.c 
b/drivers/power/reset/vexpress-poweroff.c
index 90cbaa8341e3..0bf9ab8653ae 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -143,6 +143,7 @@ static struct platform_driver vexpress_reset_driver = {
.driver = {
.name = "vexpress-reset",
.of_match_table = vexpress_reset_of_match,
+   .suppress_bind_attrs = true,
},
 };
 
-- 
2.26.2



[PATCH 2/5] power: vexpress: cleanup: use builtin_platform_driver

2020-05-27 Thread Anders Roxell
Use the helper macro for builtin drivers taht don't do anything special
in driver init. This removes some boilerplate code.

Signed-off-by: Anders Roxell 
---
 drivers/power/reset/vexpress-poweroff.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/power/reset/vexpress-poweroff.c 
b/drivers/power/reset/vexpress-poweroff.c
index 0bf9ab8653ae..1fdbcbd95fc2 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -146,9 +146,4 @@ static struct platform_driver vexpress_reset_driver = {
.suppress_bind_attrs = true,
},
 };
-
-static int __init vexpress_reset_init(void)
-{
-   return platform_driver_register(&vexpress_reset_driver);
-}
-device_initcall(vexpress_reset_init);
+builtin_platform_driver(vexpress_reset_driver);
-- 
2.26.2



[PATCH 5/5] power: vexpress: make the reset driver a module

2020-05-27 Thread Anders Roxell
Today the vexpress power driver can only be builtin.  Rework so it's
possible for the vexpress power driver to be a module.

Signed-off-by: Anders Roxell 
---
 arch/arm/mach-vexpress/Kconfig  |  1 -
 drivers/power/reset/Kconfig |  5 +++--
 drivers/power/reset/vexpress-poweroff.c | 12 +++-
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 065e12991663..4b54d8cf897d 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -15,7 +15,6 @@ menuconfig ARCH_VEXPRESS
select NO_IOPORT_MAP
select PLAT_VERSATILE
select POWER_RESET
-   select POWER_RESET_VEXPRESS
select POWER_SUPPLY
select REGULATOR if MMC_ARMMMCI
select REGULATOR_FIXED_VOLTAGE if REGULATOR
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index f07b982c8dff..8468d42b0198 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -189,9 +189,10 @@ config POWER_RESET_VERSATILE
  reference boards.
 
 config POWER_RESET_VEXPRESS
-   bool "ARM Versatile Express power-off and reset driver"
+   tristate "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
-   depends on VEXPRESS_CONFIG=y
+   depends on VEXPRESS_CONFIG
+   default VEXPRESS_CONFIG
help
  Power off and reset support for the ARM Ltd. Versatile
  Express boards.
diff --git a/drivers/power/reset/vexpress-poweroff.c 
b/drivers/power/reset/vexpress-poweroff.c
index 1fdbcbd95fc2..b1eef95132d9 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -146,4 +147,13 @@ static struct platform_driver vexpress_reset_driver = {
.suppress_bind_attrs = true,
},
 };
-builtin_platform_driver(vexpress_reset_driver);
+
+static int __init vexpress_reset_init(void)
+{
+   return platform_driver_register(&vexpress_reset_driver);
+}
+module_init(vexpress_reset_init);
+
+MODULE_AUTHOR("Pawel Moll ");
+MODULE_DESCRIPTION("Vexpress reset driver");
+MODULE_LICENSE("GPL v2");
-- 
2.26.2



[PATCH 4/5] power: reset: vexpress: fix build issue

2020-05-27 Thread Anders Roxell
An allmodconfig kernel makes CONFIG_VEXPRESS_CONFIG a module and
CONFIG_POWER_RESET_VEXPRESS builtin. That makes us see this build
error:

aarch64-linux-gnu-ld: drivers/power/reset/vexpress-poweroff.o: in function 
`vexpress_reset_probe':
../drivers/power/reset/vexpress-poweroff.c:119: undefined reference to 
`devm_regmap_init_vexpress_config'
../drivers/power/reset/vexpress-poweroff.c:119:(.text+0x48c): relocation 
truncated to fit: R_AARCH64_CALL26 against undefined symbol
`devm_regmap_init_vexpress_config'
make[1]: *** [/srv/src/kernel/next/Makefile:1126: vmlinux] Error 1

Rework so that POWER_RESET_VEXPRESS depends on 'VEXPRESS_CONFIG=y'.

Fixes: d06cfe3f123c ("bus: vexpress-config: Merge vexpress-syscfg into 
vexpress-config")
Signed-off-by: Anders Roxell 
Acked-by: Rob Herring 
---
 drivers/power/reset/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4dfac618b942..f07b982c8dff 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -191,7 +191,7 @@ config POWER_RESET_VERSATILE
 config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
-   depends on VEXPRESS_CONFIG
+   depends on VEXPRESS_CONFIG=y
help
  Power off and reset support for the ARM Ltd. Versatile
  Express boards.
-- 
2.26.2



[PATCH 3/5] Revert "ARM: vexpress: Don't select VEXPRESS_CONFIG"

2020-05-27 Thread Anders Roxell
This reverts commit 848685c25da99d871bbd87369f3c3d6eead661ac.
Due to when I set 'depends on VEXPRESS_CONFOG=Y' in 'config
POWER_RESET_VEXPRESS' to get an allmodconfig build on arm64 to build,
and allmodconfig build on arm fails if this patch isn't reverted.

Signed-off-by: Anders Roxell 
---
 arch/arm/mach-vexpress/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 8391a5b3cd78..065e12991663 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -19,6 +19,7 @@ menuconfig ARCH_VEXPRESS
select POWER_SUPPLY
select REGULATOR if MMC_ARMMMCI
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+   select VEXPRESS_CONFIG
help
  This option enables support for systems using Cortex processor based
  ARM core and logic (FPGA) tiles on the Versatile Express motherboard,
-- 
2.26.2



[PATCH 0/5] vexpress: modularize power reset driver

2020-05-27 Thread Anders Roxell
Hi,

This patchset contains a bugfixe, a cleanup and fixes allmodconfig build 
breakages
on arm and arm64. Also making the vexpress power reset driver a module.

Cheers,
Anders

Anders Roxell (5):
  power: vexpress: add suppress_bind_attrs to true
  power: vexpress: cleanup: use builtin_platform_driver
  Revert "ARM: vexpress: Don't select VEXPRESS_CONFIG"
  power: reset: vexpress: fix build issue
  power: vexpress: make the reset driver a module

 arch/arm/mach-vexpress/Kconfig  | 2 +-
 drivers/power/reset/Kconfig | 3 ++-
 drivers/power/reset/vexpress-poweroff.c | 8 +++-
 3 files changed, 10 insertions(+), 3 deletions(-)

-- 
2.26.2



Re: [PATCH] power: reset: vexpress: fix build issue

2020-05-26 Thread Anders Roxell
On Tue, 26 May 2020 at 17:41, Rob Herring  wrote:
>
> " On Mon, May 25, 2020 at 11:38 PM Nathan Chancellor
>  wrote:
> >
> > On Mon, May 25, 2020 at 07:37:45PM -0400, Valdis Klētnieks wrote:
> > > On Sun, 24 May 2020 15:20:25 -0700, Nathan Chancellor said:
> > >
> > > > arm-linux-gnueabi-ld: drivers/power/reset/vexpress-poweroff.o: in 
> > > > function `vexpress_reset_probe':
> > > > vexpress-poweroff.c:(.text+0x36c): undefined reference to 
> > > > `devm_regmap_init_vexpress_config'
> > >
> > > The part I can't figure out is that git blame tells me there's already an
> > > export:
> > >
> > > 3b9334ac835bb (Pawel Moll  2014-04-30 16:46:29 +0100 154)   return 
> > > regmap;
> > > 3b9334ac835bb (Pawel Moll  2014-04-30 16:46:29 +0100 155) }
> > > b33cdd283bd91 (Arnd Bergmann   2014-05-26 17:25:22 +0200 156) 
> > > EXPORT_SYMBOL_GPL(devm_regmap_init_vexpress_config);
> > > 3b9334ac835bb (Pawel Moll  2014-04-30 16:46:29 +0100 157)
> > >
> > > but I can't figure out where or if 
> > > drivers/power/reset/vexpress-poweroff.c gets
> > > a MODULE_LICENSE from...
> >
> > Correct, it is exported but that file is being built as a module whereas
> > the file requiring it is beign builtin. As far as I understand, that
> > will not work, hence the error.
> >
> > The issue with this patch is that ARCH_VEXPRESS still just selects
> > POWER_RESET_VEXPRESS, which ignores "depends on", hence the Kconfig
> > warning and not fixing the error.
> >
> > I am not that much of a Kconfig guru to come up with a solution. I am
> > just reporting it because arm allmodconfig is broken on -next due to
> > this.
>
> Commit "ARM: vexpress: Don't select VEXPRESS_CONFIG" needs to be
> reverted. I've asked Arnd to revert it.

Reverting that patch with my patch will make allmodconfig work for arm too.

>
> Anders patch is still needed for arm64.

Yes, it is still needed for arm64.

Cheers,
Anders


[PATCH] power: reset: vexpress: fix build issue

2020-05-22 Thread Anders Roxell
An allmodconfig kernel makes CONFIG_VEXPRESS_CONFIG a module and
CONFIG_POWER_RESET_VEXPRESS builtin. That makes us see this build
error:

aarch64-linux-gnu-ld: drivers/power/reset/vexpress-poweroff.o: in function 
`vexpress_reset_probe':
../drivers/power/reset/vexpress-poweroff.c:119: undefined reference to 
`devm_regmap_init_vexpress_config'
../drivers/power/reset/vexpress-poweroff.c:119:(.text+0x48c): relocation 
truncated to fit: R_AARCH64_CALL26 against undefined symbol
`devm_regmap_init_vexpress_config'
make[1]: *** [/srv/src/kernel/next/Makefile:1126: vmlinux] Error 1

Rework so that POWER_RESET_VEXPRESS depends on 'VEXPRESS_CONFIG=y'.

Fixes: d06cfe3f123c ("bus: vexpress-config: Merge vexpress-syscfg into 
vexpress-config")
Acked-by: Rob Herring 
Signed-off-by: Anders Roxell 
---
 drivers/power/reset/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4dfac618b942..f07b982c8dff 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -191,7 +191,7 @@ config POWER_RESET_VERSATILE
 config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
-   depends on VEXPRESS_CONFIG
+   depends on VEXPRESS_CONFIG=y
help
  Power off and reset support for the ARM Ltd. Versatile
  Express boards.
-- 
2.26.2



[PATCH] power: reset: vexpress: fix build issue

2020-05-20 Thread Anders Roxell
An allmodconfig kernel makes CONFIG_VEXPRESS_CONFIG a module and
CONFIG_POWER_RESET_VEXPRESS builtin. That makes us see this build
error:

aarch64-linux-gnu-ld: drivers/power/reset/vexpress-poweroff.o: in function 
`vexpress_reset_probe':
../drivers/power/reset/vexpress-poweroff.c:119: undefined reference to 
`devm_regmap_init_vexpress_config'
../drivers/power/reset/vexpress-poweroff.c:119:(.text+0x48c): relocation 
truncated to fit: R_AARCH64_CALL26 against undefined symbol
`devm_regmap_init_vexpress_config'
make[1]: *** [/srv/src/kernel/next/Makefile:1126: vmlinux] Error 1

Rework so that POWER_RESET_VEXPRESS depends on 'VEXPRESS_CONFIG=y'.

Fixes: d06cfe3f123c ("bus: vexpress-config: Merge vexpress-syscfg into 
vexpress-config")
Signed-off-by: Anders Roxell 
---
 drivers/power/reset/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4dfac618b942..f07b982c8dff 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -191,7 +191,7 @@ config POWER_RESET_VERSATILE
 config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
-   depends on VEXPRESS_CONFIG
+   depends on VEXPRESS_CONFIG=y
help
  Power off and reset support for the ARM Ltd. Versatile
  Express boards.
-- 
2.26.2



Re: [PATCH v13 3/5] usb: xhci: Add support for Renesas controller with memory

2020-05-18 Thread Anders Roxell
On Mon, 18 May 2020 at 21:57, Vinod Koul  wrote:
>
> Hi Anders,

Hi Vinod,

>
> On 18-05-20, 19:53, Anders Roxell wrote:
> > On Wed, 6 May 2020 at 08:01, Vinod Koul  wrote:
> > >
> > > Some rensas controller like uPD720201 and uPD720202 need firmware to be
> > > loaded. Add these devices in pci table and invoke renesas firmware loader
> > > functions to check and load the firmware into device memory when
> > > required.
> > >
> > > Signed-off-by: Vinod Koul 
> >
> > Hi, I got a build error when I built an arm64 allmodconfig kernel.
>
> Thanks for this. This is happening as we have default y for USB_XHCI_PCI
> and then we make USB_XHCI_PCI_RENESAS=m. That should be not allowed as
> we export as symbol so both can be inbuilt or modules but USB_XHCI_PCI=y
> and USB_XHCI_PCI_RENESAS=m cant. While it is valid that USB_XHCI_PCI=y|m
> and USB_XHCI_PCI_RENESAS=n
>
> So this seems to get fixed by below for me. I have tested with
>  - both y and m (easy)
>  - make USB_XHCI_PCI_RENESAS=n, USB_XHCI_PCI=y|m works
>  - try making USB_XHCI_PCI=y and USB_XHCI_PCI_RENESAS=m, then
>USB_XHCI_PCI=m by kbuild :)
>  - try making USB_XHCI_PCI=m and USB_XHCI_PCI_RENESAS=y, kbuild gives
>error prompt that it will be m due to depends
>
> Thanks to all the fixes done by Arnd which pointed me to this. Pls
> verify

I was able to build an arm64 allmodconfig kernel with this change.

Cheers,
Anders

> and I will send the fix with you as reported :)
>
>  >8 
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index b5c542d6a1c5..92783d175b3f 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -40,11 +40,11 @@ config USB_XHCI_DBGCAP
>  config USB_XHCI_PCI
> tristate
> depends on USB_PCI
> +   depends on USB_XHCI_PCI_RENESAS || !USB_XHCI_PCI_RENESAS
> default y
>
>  config USB_XHCI_PCI_RENESAS
> tristate "Support for additional Renesas xHCI controller with 
> firwmare"
> -   depends on USB_XHCI_PCI
> ---help---
>   Say 'Y' to enable the support for the Renesas xHCI controller with
>   firwmare. Make sure you have the firwmare for the device and
>
> --
> ~Vinod


Re: [PATCH v13 3/5] usb: xhci: Add support for Renesas controller with memory

2020-05-18 Thread Anders Roxell
On Wed, 6 May 2020 at 08:01, Vinod Koul  wrote:
>
> Some rensas controller like uPD720201 and uPD720202 need firmware to be
> loaded. Add these devices in pci table and invoke renesas firmware loader
> functions to check and load the firmware into device memory when
> required.
>
> Signed-off-by: Vinod Koul 

Hi, I got a build error when I built an arm64 allmodconfig kernel.

building obj-arm64-next-20200518

aarch64-linux-gnu-ld: drivers/usb/host/xhci-pci.o: in function
`xhci_pci_remove':
/srv/src/kernel/next/obj-arm64-next-20200518/../drivers/usb/host/xhci-pci.c:411:
undefined reference to `renesas_xhci_pci_exit'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200518/../drivers/usb/host/xhci-pci.c:411:(.text+0xd8):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`renesas_xhci_pci_exit'
aarch64-linux-gnu-ld: drivers/usb/host/xhci-pci.o: in function `xhci_pci_probe':
/srv/src/kernel/next/obj-arm64-next-20200518/../drivers/usb/host/xhci-pci.c:345:
undefined reference to `renesas_xhci_check_request_fw'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200518/../drivers/usb/host/xhci-pci.c:345:(.text+0x2298):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`renesas_xhci_check_request_fw'
make[1]: *** [/srv/src/kernel/next/Makefile:1126: vmlinux] Error 1
make[1]: Target 'Image' not remade because of errors.
make: *** [Makefile:185: __sub-make] Error 2
make: Target 'Image' not remade because of errors.

When I reverted this patch from todays next tag next-20200518 I
managed to build.


Cheers,
Anders

> ---
>  drivers/usb/host/xhci-pci.c | 35 ++-
>  drivers/usb/host/xhci.h |  1 +
>  2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index b6c2f5c530e3..ef513c2fb843 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -15,6 +15,7 @@
>
>  #include "xhci.h"
>  #include "xhci-trace.h"
> +#include "xhci-pci.h"
>
>  #define SSIC_PORT_NUM  2
>  #define SSIC_PORT_CFG2 0x880c
> @@ -87,7 +88,16 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct 
> pci_dev *pdev)
>
>  static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
>  {
> -   struct pci_dev  *pdev = to_pci_dev(dev);
> +   struct pci_dev  *pdev = to_pci_dev(dev);
> +   struct xhci_driver_data *driver_data;
> +   const struct pci_device_id  *id;
> +
> +   id = pci_match_id(pdev->driver->id_table, pdev);
> +
> +   if (id && id->driver_data) {
> +   driver_data = (struct xhci_driver_data *)id->driver_data;
> +   xhci->quirks |= driver_data->quirks;
> +   }
>
> /* Look for vendor-specific quirks */
> if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC &&
> @@ -328,6 +338,14 @@ static int xhci_pci_probe(struct pci_dev *dev, const 
> struct pci_device_id *id)
> int retval;
> struct xhci_hcd *xhci;
> struct usb_hcd *hcd;
> +   struct xhci_driver_data *driver_data;
> +
> +   driver_data = (struct xhci_driver_data *)id->driver_data;
> +   if (driver_data && driver_data->quirks & XHCI_RENESAS_FW_QUIRK) {
> +   retval = renesas_xhci_check_request_fw(dev, id);
> +   if (retval)
> +   return retval;
> +   }
>
> /* Prevent runtime suspending between USB-2 and USB-3 initialization 
> */
> pm_runtime_get_noresume(&dev->dev);
> @@ -389,6 +407,9 @@ static void xhci_pci_remove(struct pci_dev *dev)
> struct xhci_hcd *xhci;
>
> xhci = hcd_to_xhci(pci_get_drvdata(dev));
> +   if (xhci->quirks & XHCI_RENESAS_FW_QUIRK)
> +   renesas_xhci_pci_exit(dev);
> +
> xhci->xhc_state |= XHCI_STATE_REMOVING;
>
> if (xhci->quirks & XHCI_DEFAULT_PM_RUNTIME_ALLOW)
> @@ -540,14 +561,26 @@ static void xhci_pci_shutdown(struct usb_hcd *hcd)
>
>  /*-*/
>
> +static const struct xhci_driver_data reneses_data = {
> +   .quirks  = XHCI_RENESAS_FW_QUIRK,
> +   .firmware = "renesas_usb_fw.mem",
> +};
> +
>  /* PCI driver selection metadata; PCI hotplugging uses this */
>  static const struct pci_device_id pci_ids[] = {
> +   { PCI_DEVICE(0x1912, 0x0014),
> +   .driver_data =  (unsigned long)&reneses_data,
> +   },
> +   { PCI_DEVICE(0x1912, 0x0015),
> +   .driver_data =  (unsigned long)&reneses_data,
> +   },
> /* handle any USB 3.0 xHCI controller */
> { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0),
> },
> { /* end: all zeroes */ }
>  };
>  MODULE_DEVICE_TABLE(pci, pci_ids);
> +MODULE_FIRMWARE("renesas_usb_fw.mem");
>
>  /* pci driver glue; this is a "new style" PCI driver module */
>  static struct pci_driver xhci_pci_driver = {
> diff --git a/drivers/usb/host/xhci.h b/d

[PATCH v2] scripts: fix deprecated always and hostprogs-y

2020-05-12 Thread Anders Roxell
When I did an allmodconfig build the following warning showed up:

scripts/Makefile.lib:8: 'always' is deprecated. Please use 'always-y' instead
scripts/Makefile.lib:12: 'hostprogs-y' and 'hostprogs-m' are deprecated. Please 
use 'hostprogs' instead

Rework to use the new 'always-y' and 'hostprogs'.

Fixes: 631ec151fd96 ("Add sample notification program")
Reported-by: Stephen Rothwell 
Signed-off-by: Anders Roxell 
---

Fixed Masahiro's comments.

 samples/watch_queue/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/samples/watch_queue/Makefile b/samples/watch_queue/Makefile
index eec00dd0a8df..8511fb6c53d2 100644
--- a/samples/watch_queue/Makefile
+++ b/samples/watch_queue/Makefile
@@ -1,7 +1,7 @@
 # List of programs to build
-hostprogs-y := watch_test
+hostprogs := watch_test
 
 # Tell kbuild to always build the programs
-always := $(hostprogs-y)
+always-y := $(hostprogs)
 
 HOSTCFLAGS_watch_test.o += -I$(objtree)/usr/include
-- 
2.20.1



[PATCH] security: fix the default value of secid_to_secctx hook

2020-05-12 Thread Anders Roxell
security_secid_to_secctx is called by the bpf_lsm hook and a successful
return value (i.e 0) implies that the parameter will be consumed by the
LSM framework. The current behaviour return success when the pointer
isn't initialized when CONFIG_BPF_LSM is enabled, with the default
return from kernel/bpf/bpf_lsm.c.

This is the internal error:

[ 1229.341488][ T2659] usercopy: Kernel memory exposure attempt detected from 
null address (offset 0, size 280)!
[ 1229.374977][ T2659] [ cut here ]
[ 1229.376813][ T2659] kernel BUG at mm/usercopy.c:99!
[ 1229.378398][ T2659] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 1229.380348][ T2659] Modules linked in:
[ 1229.381654][ T2659] CPU: 0 PID: 2659 Comm: systemd-journal Tainted: GB   
W 5.7.0-rc5-next-20200511-00019-g864e0c6319b8-dirty #13
[ 1229.385429][ T2659] Hardware name: linux,dummy-virt (DT)
[ 1229.387143][ T2659] pstate: 8045 (Nzcv daif +PAN -UAO BTYPE=--)
[ 1229.389165][ T2659] pc : usercopy_abort+0xc8/0xcc
[ 1229.390705][ T2659] lr : usercopy_abort+0xc8/0xcc
[ 1229.392225][ T2659] sp : 64247450
[ 1229.393533][ T2659] x29: 64247460 x28: 
[ 1229.395449][ T2659] x27: 0118 x26: 
[ 1229.397384][ T2659] x25: a000127049e0 x24: a000127049e0
[ 1229.399306][ T2659] x23: a000127048e0 x22: a000127048a0
[ 1229.401241][ T2659] x21: a00012704b80 x20: a000127049e0
[ 1229.403163][ T2659] x19: a00012704820 x18: 
[ 1229.405094][ T2659] x17:  x16: 
[ 1229.407008][ T2659] x15:  x14: 003d0900
[ 1229.408942][ T2659] x13: 8d5b25b2 x12: 1fffed5b25b1
[ 1229.410859][ T2659] x11: 1fffed5b25b1 x10: 8d5b25b1
[ 1229.412791][ T2659] x9 : a0001034bee0 x8 : 6ad92d8f
[ 1229.414707][ T2659] x7 :  x6 : a00015eacb20
[ 1229.416642][ T2659] x5 : 693c8040 x4 : 
[ 1229.418558][ T2659] x3 : a0001034befc x2 : d57a7483a01c6300
[ 1229.420610][ T2659] x1 :  x0 : 0059
[ 1229.422526][ T2659] Call trace:
[ 1229.423631][ T2659]  usercopy_abort+0xc8/0xcc
[ 1229.425091][ T2659]  __check_object_size+0xdc/0x7d4
[ 1229.426729][ T2659]  put_cmsg+0xa30/0xa90
[ 1229.428132][ T2659]  unix_dgram_recvmsg+0x80c/0x930
[ 1229.429731][ T2659]  sock_recvmsg+0x9c/0xc0
[ 1229.431123][ T2659]  sys_recvmsg+0x1cc/0x5f8
[ 1229.432663][ T2659]  ___sys_recvmsg+0x100/0x160
[ 1229.434151][ T2659]  __sys_recvmsg+0x110/0x1a8
[ 1229.435623][ T2659]  __arm64_sys_recvmsg+0x58/0x70
[ 1229.437218][ T2659]  el0_svc_common.constprop.1+0x29c/0x340
[ 1229.438994][ T2659]  do_el0_svc+0xe8/0x108
[ 1229.440587][ T2659]  el0_svc+0x74/0x88
[ 1229.441917][ T2659]  el0_sync_handler+0xe4/0x8b4
[ 1229.443464][ T2659]  el0_sync+0x17c/0x180
[ 1229.444920][ T2659] Code: aa1703e2 aa1603e1 910a8260 97ecc860 (d421)
[ 1229.447070][ T2659] ---[ end trace 400497d91baeaf51 ]---
[ 1229.448791][ T2659] Kernel panic - not syncing: Fatal exception
[ 1229.450692][ T2659] Kernel Offset: disabled
[ 1229.452061][ T2659] CPU features: 0x240002,20002004
[ 1229.453647][ T2659] Memory Limit: none
[ 1229.455015][ T2659] ---[ end Kernel panic - not syncing: Fatal exception ]---

Rework the so the default return value is -EOPNOTSUPP.

There are likely other callbacks such as security_inode_getsecctx() that
may have the same problem, and that someone that understand the code
better needs to audit them.

Thank you Arnd for helping me figure out what went wrong.

CC: Arnd Bergmann 
Fixes: 98e828a0650f ("security: Refactor declaration of LSM hooks")
Signed-off-by: Anders Roxell 
---
 include/linux/lsm_hook_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index b9e73d736e13..31eb3381e54b 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -243,7 +243,7 @@ LSM_HOOK(int, -EINVAL, getprocattr, struct task_struct *p, 
char *name,
 char **value)
 LSM_HOOK(int, -EINVAL, setprocattr, const char *name, void *value, size_t size)
 LSM_HOOK(int, 0, ismaclabel, const char *name)
-LSM_HOOK(int, 0, secid_to_secctx, u32 secid, char **secdata,
+LSM_HOOK(int, -EOPNOTSUPP, secid_to_secctx, u32 secid, char **secdata,
 u32 *seclen)
 LSM_HOOK(int, 0, secctx_to_secid, const char *secdata, u32 seclen, u32 *secid)
 LSM_HOOK(void, LSM_RET_VOID, release_secctx, char *secdata, u32 seclen)
-- 
2.20.1



Re: [PATCH] scripts: fix deprecated always and hostprogs-y

2020-05-11 Thread Anders Roxell
On Wed, 6 May 2020 at 20:36, Masahiro Yamada  wrote:
>
> On Tue, May 5, 2020 at 8:54 PM Anders Roxell  wrote:
> >
> > When I did an allmodconfig build the following warning showed up:
> >
> > scripts/Makefile.lib:8: 'always' is deprecated. Please use 'always-y' 
> > instead
> > scripts/Makefile.lib:12: 'hostprogs-y' and 'hostprogs-m' are deprecated. 
> > Please use 'hostprogs' instead
> >
> > Rework to use the new 'always-y' and 'hostprogs'.
> >
> > Fixes: ee066c3ddf7b ("kbuild: warn if always, hostprogs-y, or hostprogs-m 
> > is used")
> > Signed-off-by: Anders Roxell 
>
>
> As Stephen Rothwell reported
> (https://lkml.org/lkml/2020/5/3/392),
> this warning appears by merging the
> two different trees.

Right, I see.

>
>
> You sent this patch to the kbuild maintainers,
> but samples/watch_queue/Makefile does not exist
> in the kbuild tree.

oops, I'm sorry.

>
>
> Also, please drop the fixes tag.

I will.

> The commit hash might change.
>
>
> > ---
> >  samples/watch_queue/Makefile | 4 ++--
> >  scripts/Makefile.build   | 1 -
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/samples/watch_queue/Makefile b/samples/watch_queue/Makefile
> > index eec00dd0a8df..8511fb6c53d2 100644
> > --- a/samples/watch_queue/Makefile
> > +++ b/samples/watch_queue/Makefile
> > @@ -1,7 +1,7 @@
> >  # List of programs to build
> > -hostprogs-y := watch_test
> > +hostprogs := watch_test
> >
> >  # Tell kbuild to always build the programs
> > -always := $(hostprogs-y)
> > +always-y := $(hostprogs)
> >
> >  HOSTCFLAGS_watch_test.o += -I$(objtree)/usr/include
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index 3665b1a0bc8e..abdba70f33a1 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -15,7 +15,6 @@ obj-y :=
> >  obj-m :=
> >  lib-y :=
> >  lib-m :=
> > -always :=
> >  always-y :=
> >  always-m :=
> >  targets :=
>
>
> Why are you deleting 'always'?
> It would immediately break
> the downstream Makefiles immediately.

Thank you, you are correct.

I will send out a new patch shortly to the correct list.

Cheers,
Anders


[PATCH v3 3/6] lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_ALL_TESTS

2020-05-11 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_ALL_TESTS' so individual tests can not be turned off.
Therefore if KUNIT_ALL_TESTS is enabled that will hide the prompt in
menuconfig.

Reviewed-by: David Gow 
Signed-off-by: Anders Roxell 
---
 lib/Kconfig.debug | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 21d9c5f6e7ec..1f4ab7a2bdee 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2064,8 +2064,9 @@ config TEST_SYSCTL
  If unsure, say N.
 
 config SYSCTL_KUNIT_TEST
-   tristate "KUnit test for sysctl"
+   tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
depends on KUNIT
+   default KUNIT_ALL_TESTS
help
  This builds the proc sysctl unit test, which runs on boot.
  Tests the API contract and implementation correctness of sysctl.
@@ -2075,8 +2076,9 @@ config SYSCTL_KUNIT_TEST
  If unsure, say N.
 
 config LIST_KUNIT_TEST
-   tristate "KUnit Test for Kernel Linked-list structures"
+   tristate "KUnit Test for Kernel Linked-list structures" if 
!KUNIT_ALL_TESTS
depends on KUNIT
+   default KUNIT_ALL_TESTS
help
  This builds the linked list KUnit test suite.
  It tests that the API and basic functionality of the list_head type
-- 
2.20.1



[PATCH v3 6/6] security: apparmor: default KUNIT_* fragments to KUNIT_ALL_TESTS

2020-05-11 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_ALL_TESTS' so individual tests can not be turned off.
Therefore if KUNIT_ALL_TESTS is enabled that will hide the prompt in
menuconfig.

Reviewed-by: David Gow 
Signed-off-by: Anders Roxell 
---
 security/apparmor/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig
index 0fe336860773..03fae1bd48a6 100644
--- a/security/apparmor/Kconfig
+++ b/security/apparmor/Kconfig
@@ -70,8 +70,9 @@ config SECURITY_APPARMOR_DEBUG_MESSAGES
  the kernel message buffer.
 
 config SECURITY_APPARMOR_KUNIT_TEST
-   bool "Build KUnit tests for policy_unpack.c"
+   bool "Build KUnit tests for policy_unpack.c" if !KUNIT_ALL_TESTS
depends on KUNIT=y && SECURITY_APPARMOR
+   default KUNIT_ALL_TESTS
help
  This builds the AppArmor KUnit tests.
 
-- 
2.20.1



[PATCH v3 1/6] kunit: Kconfig: enable a KUNIT_ALL_TESTS fragment

2020-05-11 Thread Anders Roxell
Make it easier to enable all KUnit fragments.  This is useful for kernel
devs or testers, so its easy to get all KUnit tests enabled and if new
gets added they will be enabled as well.  Fragments that has to be
builtin will be missed if CONFIG_KUNIT_ALL_TESTS is set as a module.

Signed-off-by: Anders Roxell 
---
 lib/kunit/Kconfig | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 95d12e3d6d95..bdeee7639005 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -41,4 +41,18 @@ config KUNIT_EXAMPLE_TEST
  is intended for curious hackers who would like to understand how to
  use KUnit for kernel development.
 
+config KUNIT_ALL_TESTS
+   tristate "All KUnit tests with satisfied dependencies"
+   help
+ Enables all KUnit tests, if they can be enabled.
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
 endif # KUNIT
-- 
2.20.1



[PATCH v3 4/6] drivers: base: default KUNIT_* fragments to KUNIT_ALL_TESTS

2020-05-11 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_ALL_TESTS' so individual tests can not be turned off.
Therefore if KUNIT_ALL_TESTS is enabled that will hide the prompt in
menuconfig.

Reviewed-by: David Gow 
Signed-off-by: Anders Roxell 
---
 drivers/base/Kconfig  | 3 ++-
 drivers/base/test/Kconfig | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 5f0bc74d2409..8d7001712062 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -149,8 +149,9 @@ config DEBUG_TEST_DRIVER_REMOVE
  test this functionality.
 
 config PM_QOS_KUNIT_TEST
-   bool "KUnit Test for PM QoS features"
+   bool "KUnit Test for PM QoS features" if !KUNIT_ALL_TESTS
depends on KUNIT=y
+   default KUNIT_ALL_TESTS
 
 config HMEM_REPORTING
bool
diff --git a/drivers/base/test/Kconfig b/drivers/base/test/Kconfig
index 305c7751184a..ba225eb1b761 100644
--- a/drivers/base/test/Kconfig
+++ b/drivers/base/test/Kconfig
@@ -9,5 +9,6 @@ config TEST_ASYNC_DRIVER_PROBE
 
  If unsure say N.
 config KUNIT_DRIVER_PE_TEST
-   bool "KUnit Tests for property entry API"
+   bool "KUnit Tests for property entry API" if !KUNIT_ALL_TESTS
depends on KUNIT=y
+   default KUNIT_ALL_TESTS
-- 
2.20.1



[PATCH v3 0/6] Enable as many KUnit tests as possible

2020-05-11 Thread Anders Roxell
Hi,

This patchset will try to enable as many KUnit test fragments as
possible for the current .config file.
This will make it easier for both developers that tests their specific
feature and also for test-systems that would like to get as much as
possible for their current .config file.

I will send a separate KCSAN KUnit patch after this patchset since that
isn't in mainline yet.

Since v2:
Fixed David's comments. KUNIT_RUN_ALL -> KUNIT_ALL_TESTS, and he
suggested a great help text.

Since v1:
Marco commented to split up the patches, and change a "." to a ",".


Cheers,
Anders

Anders Roxell (6):
  kunit: Kconfig: enable a KUNIT_ALL_TESTS fragment
  kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS
  lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_ALL_TESTS
  drivers: base: default KUNIT_* fragments to KUNIT_ALL_TESTS
  fs: ext4: default KUNIT_* fragments to KUNIT_ALL_TESTS
  security: apparmor: default KUNIT_* fragments to KUNIT_ALL_TESTS

 drivers/base/Kconfig  |  3 ++-
 drivers/base/test/Kconfig |  3 ++-
 fs/ext4/Kconfig   |  3 ++-
 lib/Kconfig.debug |  6 --
 lib/kunit/Kconfig | 23 ---
 security/apparmor/Kconfig |  3 ++-
 6 files changed, 32 insertions(+), 9 deletions(-)

-- 
2.20.1



[PATCH v3 2/6] kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS

2020-05-11 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_ALL_TESTS' so individual tests can not be turned off.
Therefore if KUNIT_ALL_TESTS is enabled that will hide the prompt in
menuconfig.

Reviewed-by: David Gow 
Signed-off-by: Anders Roxell 
---
 lib/kunit/Kconfig | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index bdeee7639005..00909e6a2443 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -15,7 +15,8 @@ menuconfig KUNIT
 if KUNIT
 
 config KUNIT_DEBUGFS
-   bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation"
+   bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation" if 
!KUNIT_ALL_TESTS
+   default KUNIT_ALL_TESTS
help
  Enable debugfs representation for kunit.  Currently this consists
  of /sys/kernel/debug/kunit//results files for each
@@ -23,7 +24,8 @@ config KUNIT_DEBUGFS
  run that occurred.
 
 config KUNIT_TEST
-   tristate "KUnit test for KUnit"
+   tristate "KUnit test for KUnit" if !KUNIT_ALL_TESTS
+   default KUNIT_ALL_TESTS
help
  Enables the unit tests for the KUnit test framework. These tests test
  the KUnit test framework itself; the tests are both written using
@@ -32,7 +34,8 @@ config KUNIT_TEST
  expected.
 
 config KUNIT_EXAMPLE_TEST
-   tristate "Example test for KUnit"
+   tristate "Example test for KUnit" if !KUNIT_ALL_TESTS
+   default KUNIT_ALL_TESTS
help
  Enables an example unit test that illustrates some of the basic
  features of KUnit. This test only exists to help new users understand
-- 
2.20.1



[PATCH v3 5/6] fs: ext4: default KUNIT_* fragments to KUNIT_ALL_TESTS

2020-05-11 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_ALL_TESTS' so individual tests can not be turned off.
Therefore if KUNIT_ALL_TESTS is enabled that will hide the prompt in
menuconfig.

Reviewed-by: David Gow 
Signed-off-by: Anders Roxell 
---
 fs/ext4/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
index 2a592e38cdfe..bc7815158503 100644
--- a/fs/ext4/Kconfig
+++ b/fs/ext4/Kconfig
@@ -103,9 +103,10 @@ config EXT4_DEBUG
echo 1 > /sys/module/ext4/parameters/mballoc_debug
 
 config EXT4_KUNIT_TESTS
-   tristate "KUnit tests for ext4"
+   tristate "KUnit tests for ext4" if !KUNIT_ALL_TESTS
select EXT4_FS
depends on KUNIT
+   default KUNIT_ALL_TESTS
help
  This builds the ext4 KUnit tests.
 
-- 
2.20.1



Re: [PATCH v2 1/6] kunit: Kconfig: enable a KUNIT_RUN_ALL fragment

2020-05-06 Thread Anders Roxell
Hi David,

Thank you for the review.

On Wed, 6 May 2020 at 07:08, David Gow  wrote:
>
> On Tue, May 5, 2020 at 6:27 PM Anders Roxell  wrote:
> >
> > Make it easier to enable all KUnit fragments.  This is needed for kernel
> > test-systems, so its easy to get all KUnit tests enabled and if new gets
> > added they will be enabled as well.  Fragments that has to be builtin
> > will be missed if CONFIG_KUNIT_RUN_ALL is set as a module.
> >
> > Signed-off-by: Anders Roxell 
> > ---
> >  lib/kunit/Kconfig | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
> > index 95d12e3d6d95..537f37bc8400 100644
> > --- a/lib/kunit/Kconfig
> > +++ b/lib/kunit/Kconfig
> > @@ -41,4 +41,10 @@ config KUNIT_EXAMPLE_TEST
> >   is intended for curious hackers who would like to understand how 
> > to
> >   use KUnit for kernel development.
> >
> > +config KUNIT_RUN_ALL
> > +   tristate "KUnit run all test"
>
> I'm not 100% sure about this name and description. It only actually
> "runs" the tests if they're builtin (as modules, they'll only run when
> loaded).
>
> Would KUNIT_BUILD_ALL or KUNIT_ALL_TESTS

I would like to go with KUNIT_ALL_TESTS if no one objects.

> or similar be better?
>
> It also, as mentioned, only really runs all available (i.e., with
> dependencies met in the current .config) tests (as distinct from the
> --alltests flag to kunit.py, which builds UML with allyesconfig), it
> might be good to add this to the description or help.
>
> Something like "Enable all KUnit tests" or "Enable all available KUnit
> tests" (or even something about "all KUnit tests with satisfied
> dependencies") might be clearer.

I like "All KUnit tests with satisfied dependencies".

>
> > +   help
> > + Enables all KUnit tests, if they can be enabled.
> > + That depends on if KUnit is enabled as a module or builtin.
> > +
> I like the first line here, but the second one could use a bit more
> explanation. Maybe copy some of the boilerplate text from other tests,
> e.g.:
>
>   KUnit tests run during boot and output the results to the debug log
>  in TAP format (http://testanything.org/). Only useful for kernel devs
>  running the KUnit test harness, and not intended for inclusion into a
>  production build.
>
>  For more information on KUnit and unit tests in general please refer
>  to the KUnit documentation in Documentation/dev-tools/kunit/.
>
>  If unsure, say N.

Makes much more sense, thanks.

>
> >  endif # KUNIT
> > --
> > 2.20.1
> >
>
> Otherwise, this is looking good. I've done some quick testing, and it
> all seems to work for me. As long as it's clear what the difference
> between this and other ways of running "all tests" (like the
> --alltests kunit.py option),

Do you think it should be made clearer in some way?

> I'm all for including this in.
>

Cheers,
Anders


Re: [PATCH net-next] net: ethernet: ti: am65-cpts: fix build

2020-05-05 Thread Anders Roxell
On Tue, 5 May 2020 at 18:21, Grygorii Strashko  wrote:
>
> It's possible to have build configuration which will force PTP_1588_CLOCK=m
> and so TI_K3_AM65_CPTS=m while still have TI_K3_AM65_CPSW_NUSS=y. This will
> cause build failures:
>
> aarch64-linux-gnu-ld: ../drivers/net/ethernet/ti/am65-cpsw-nuss.o: in 
> function `am65_cpsw_init_cpts':
> ../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685: undefined reference to 
> `am65_cpts_create'
> aarch64-linux-gnu-ld: 
> ../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:(.text+0x2e20):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 
> `am65_cpts_create'
>
> Fix it by adding dependencies from CPTS in TI_K3_AM65_CPSW_NUSS as below:
>config TI_K3_AM65_CPSW_NUSS
>...
>  depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS
>
> Note. This will create below dependencies and for NFS boot + CPTS all of them
> have to be built-in.
>   PTP_1588_CLOCK -> TI_K3_AM65_CPTS -> TI_K3_AM65_CPSW_NUSS
>
> While here, clean up TI_K3_AM65_CPTS definition.
>
> Fixes: b1f66a5bee07 ("net: ethernet: ti: am65-cpsw-nuss: enable packet 
> timestamping support")
> Signed-off-by: Grygorii Strashko 
> Reported-by: Anders Roxell 

Tested-by: Anders Roxell 

> ---
>  drivers/net/ethernet/ti/Kconfig | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index 4ab35ce7b451..988e907e3322 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -99,7 +99,7 @@ config TI_K3_AM65_CPSW_NUSS
> depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
> select TI_DAVINCI_MDIO
> imply PHY_TI_GMII_SEL
> -   imply TI_AM65_CPTS
> +   depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS

Don't we want to move this so it is below the other 'depends on' ?

Cheers,
Anders

> help
>   This driver supports TI K3 AM654/J721E CPSW2G Ethernet SubSystem.
>   The two-port Gigabit Ethernet MAC (MCU_CPSW0) subsystem provides
> @@ -112,9 +112,8 @@ config TI_K3_AM65_CPSW_NUSS
>
>  config TI_K3_AM65_CPTS
> tristate "TI K3 AM65x CPTS"
> -   depends on ARCH_K3 && OF && PTP_1588_CLOCK
> +   depends on ARCH_K3 && OF
> depends on PTP_1588_CLOCK
> -   select NET_PTP_CLASSIFY
> help
>   Say y here to support the TI K3 AM65x CPTS with 1588 features such 
> as
>   PTP hardware clock for each CPTS device and network packets
> --
> 2.17.1
>


Re: [PATCH net-next 3/7] net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support

2020-05-05 Thread Anders Roxell
On Tue, 5 May 2020 at 14:20, Grygorii Strashko  wrote:
>
> Hi Anders,

Hi Grygorii,

>
> On 05/05/2020 14:59, Anders Roxell wrote:
> > On Tue, 5 May 2020 at 13:16, Anders Roxell  wrote:
> >> On Tue, 5 May 2020 at 13:05, Grygorii Strashko  
> >> wrote:
> >>> On 05/05/2020 13:17, Anders Roxell wrote:
> >>>> On Fri, 1 May 2020 at 22:50, Grygorii Strashko 
> >>>>  wrote:
> >>>>>
> >>>>> The MCU CPSW Common Platform Time Sync (CPTS) provides possibility to
> >>>>> timestamp TX PTP packets and all RX packets.
> >>>>>
> >>>>> This enables corresponding support in TI AM65x/J721E MCU CPSW driver.
> >>>>>
> >>>>> Signed-off-by: Grygorii Strashko 
> >>>>> ---
> >>>>>drivers/net/ethernet/ti/Kconfig |   1 +
> >>>>>drivers/net/ethernet/ti/am65-cpsw-ethtool.c |  24 ++-
> >>>>>drivers/net/ethernet/ti/am65-cpsw-nuss.c| 172 
> >>>>> 
> >>>>>drivers/net/ethernet/ti/am65-cpsw-nuss.h|   6 +-
> >>>>>4 files changed, 201 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/net/ethernet/ti/Kconfig 
> >>>>> b/drivers/net/ethernet/ti/Kconfig
> >>>>> index 1f4e5b6dc686..2c7bd1ccaaec 100644
> >>>>> --- a/drivers/net/ethernet/ti/Kconfig
> >>>>> +++ b/drivers/net/ethernet/ti/Kconfig
> >>>>> @@ -100,6 +100,7 @@ config TI_K3_AM65_CPSW_NUSS
> >>>>>   depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
> >>>>>   select TI_DAVINCI_MDIO
> >>>>>   imply PHY_TI_GMII_SEL
> >>>>> +   imply TI_AM65_CPTS
> >>>>
> >>>> Should this be TI_K3_AM65_CPTS ?
> >
> > instead of 'imply TI_K3_AM65_CPTS' don't you want to do this:
> > 'depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS'
> >
> >
>
> Right, I'll try. It seems your defconfig is produced by randconfig as
> I can't get broken cfg TI_AM65_CPTS=m and TI_K3_AM65_CPSW_NUSS=y
> with neither one below:
>
>   make ARCH=arm64 O=k3-arm64 defconfig
>   make ARCH=arm64 O=k3-arm64 allnoconfig
>   make ARCH=arm64 O=k3-arm64 allyesconfig
>   make ARCH=arm64 O=k3-arm64 allmodconfig
>   make ARCH=arm64 O=k3-arm64 alldefconfig
>   make ARCH=arm64 O=k3-arm64 yes2modconfig
>   make ARCH=arm64 O=k3-arm64 mod2yesconfig

I'm so sorry, I forgot to tell you that I do my allmodconfig like this:

make ARCH=arm64 KCONFIG_ALLCONFIG=arch/arm64/configs/defconfig
O=k3-arm64 allmodconfig

Then I'm sure I should get a bootable kernel since that uses the
defconfig as a base...

Cheers,
Anders

>
> Related legacy TI CPTS threads:
>   https://lkml.org/lkml/2020/5/2/344
>   https://lkml.org/lkml/2020/5/1/1348
>
> I'd try summarize goal
>   TI_K3_AM65_CPSW_NUSS  TI_AM65_CPTS
>   Y Y/N
>   M Y/M/N
>   N Y/M/N
>
>
> --
> Best regards,
> grygorii


Re: [PATCH net-next 3/7] net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support

2020-05-05 Thread Anders Roxell
On Tue, 5 May 2020 at 13:16, Anders Roxell  wrote:
>
> On Tue, 5 May 2020 at 13:05, Grygorii Strashko  
> wrote:
> >
> > hi Anders,
>
> Hi Grygorii,

Hi again,

>
> >
> > On 05/05/2020 13:17, Anders Roxell wrote:
> > > On Fri, 1 May 2020 at 22:50, Grygorii Strashko  
> > > wrote:
> > >>
> > >> The MCU CPSW Common Platform Time Sync (CPTS) provides possibility to
> > >> timestamp TX PTP packets and all RX packets.
> > >>
> > >> This enables corresponding support in TI AM65x/J721E MCU CPSW driver.
> > >>
> > >> Signed-off-by: Grygorii Strashko 
> > >> ---
> > >>   drivers/net/ethernet/ti/Kconfig |   1 +
> > >>   drivers/net/ethernet/ti/am65-cpsw-ethtool.c |  24 ++-
> > >>   drivers/net/ethernet/ti/am65-cpsw-nuss.c| 172 
> > >>   drivers/net/ethernet/ti/am65-cpsw-nuss.h|   6 +-
> > >>   4 files changed, 201 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/net/ethernet/ti/Kconfig 
> > >> b/drivers/net/ethernet/ti/Kconfig
> > >> index 1f4e5b6dc686..2c7bd1ccaaec 100644
> > >> --- a/drivers/net/ethernet/ti/Kconfig
> > >> +++ b/drivers/net/ethernet/ti/Kconfig
> > >> @@ -100,6 +100,7 @@ config TI_K3_AM65_CPSW_NUSS
> > >>  depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
> > >>  select TI_DAVINCI_MDIO
> > >>  imply PHY_TI_GMII_SEL
> > >> +   imply TI_AM65_CPTS
> > >
> > > Should this be TI_K3_AM65_CPTS ?

instead of 'imply TI_K3_AM65_CPTS' don't you want to do this:
'depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS'


Cheers,
Anders

> > >
> > > I did an arm64 allmodconfig build on todays next tag: next-20200505
> > > and got this undefined symbol:
> > >
> > > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > > function `am65_cpsw_init_cpts':
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:
> > > undefined reference to `am65_cpts_create'
> > > aarch64-linux-gnu-ld:
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:(.text+0x2e20):
> > > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > > `am65_cpts_create'
> > > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > > function `am65_cpsw_nuss_tx_compl_packets':
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:
> > > undefined reference to `am65_cpts_tx_timestamp'
> > > aarch64-linux-gnu-ld:
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:(.text+0x4cf0):
> > > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > > `am65_cpts_tx_timestamp'
> > > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > > function `am65_cpsw_nuss_ndo_slave_xmit':
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:
> > > undefined reference to `am65_cpts_prep_tx_timestamp'
> > > aarch64-linux-gnu-ld:
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:(.text+0x58fc):
> > > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > > `am65_cpts_prep_tx_timestamp'
> > > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > > function `am65_cpsw_nuss_hwtstamp_set':
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:
> > > undefined reference to `am65_cpts_rx_enable'
> > > aarch64-linux-gnu-ld:
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:(.text+0x7564):
> > > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > > `am65_cpts_rx_enable'
> > > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-ethtool.o: in
> > > function `am65_cpsw_get_ethtool_ts_info':
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:
> > > undefined reference to `am65_cpts_phc_index'
> > > aarch64-linux-gnu-ld:
> > > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:(.text+0xbe8):
> > > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > > `am65_cpts_phc_index'
> > > make[1]: *** [/srv/src/kernel/next/Makefile:1114: vmlinux] Error 1
> > > make[1]: Target 'Image' not remade because of errors.
> > > make: *** [Makefile:180: sub-make] Error 2
> > > make: Target 'Image' not remade because of errors.
> >
> > Sry, I can't reproduce it net-next.
>
> Oh I forgot to try net-next, sorry.
>
> > trying next...
>
> Thank you.
>
> > What's your config?
>
> This is the config [1] I used.
>
> Cheers,
> Anders
> [1] https://people.linaro.org/~anders.roxell/kernel-next-20200505.config
>
> >
> > --
> > Best regards,
> > grygorii


[PATCH] scripts: fix deprecated always and hostprogs-y

2020-05-05 Thread Anders Roxell
When I did an allmodconfig build the following warning showed up:

scripts/Makefile.lib:8: 'always' is deprecated. Please use 'always-y' instead
scripts/Makefile.lib:12: 'hostprogs-y' and 'hostprogs-m' are deprecated. Please 
use 'hostprogs' instead

Rework to use the new 'always-y' and 'hostprogs'.

Fixes: ee066c3ddf7b ("kbuild: warn if always, hostprogs-y, or hostprogs-m is 
used")
Signed-off-by: Anders Roxell 
---
 samples/watch_queue/Makefile | 4 ++--
 scripts/Makefile.build   | 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/samples/watch_queue/Makefile b/samples/watch_queue/Makefile
index eec00dd0a8df..8511fb6c53d2 100644
--- a/samples/watch_queue/Makefile
+++ b/samples/watch_queue/Makefile
@@ -1,7 +1,7 @@
 # List of programs to build
-hostprogs-y := watch_test
+hostprogs := watch_test
 
 # Tell kbuild to always build the programs
-always := $(hostprogs-y)
+always-y := $(hostprogs)
 
 HOSTCFLAGS_watch_test.o += -I$(objtree)/usr/include
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 3665b1a0bc8e..abdba70f33a1 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -15,7 +15,6 @@ obj-y :=
 obj-m :=
 lib-y :=
 lib-m :=
-always :=
 always-y :=
 always-m :=
 targets :=
-- 
2.20.1



Re: [PATCH net-next 3/7] net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support

2020-05-05 Thread Anders Roxell
On Tue, 5 May 2020 at 13:05, Grygorii Strashko  wrote:
>
> hi Anders,

Hi Grygorii,

>
> On 05/05/2020 13:17, Anders Roxell wrote:
> > On Fri, 1 May 2020 at 22:50, Grygorii Strashko  
> > wrote:
> >>
> >> The MCU CPSW Common Platform Time Sync (CPTS) provides possibility to
> >> timestamp TX PTP packets and all RX packets.
> >>
> >> This enables corresponding support in TI AM65x/J721E MCU CPSW driver.
> >>
> >> Signed-off-by: Grygorii Strashko 
> >> ---
> >>   drivers/net/ethernet/ti/Kconfig |   1 +
> >>   drivers/net/ethernet/ti/am65-cpsw-ethtool.c |  24 ++-
> >>   drivers/net/ethernet/ti/am65-cpsw-nuss.c| 172 
> >>   drivers/net/ethernet/ti/am65-cpsw-nuss.h|   6 +-
> >>   4 files changed, 201 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/Kconfig 
> >> b/drivers/net/ethernet/ti/Kconfig
> >> index 1f4e5b6dc686..2c7bd1ccaaec 100644
> >> --- a/drivers/net/ethernet/ti/Kconfig
> >> +++ b/drivers/net/ethernet/ti/Kconfig
> >> @@ -100,6 +100,7 @@ config TI_K3_AM65_CPSW_NUSS
> >>  depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
> >>  select TI_DAVINCI_MDIO
> >>  imply PHY_TI_GMII_SEL
> >> +   imply TI_AM65_CPTS
> >
> > Should this be TI_K3_AM65_CPTS ?
> >
> > I did an arm64 allmodconfig build on todays next tag: next-20200505
> > and got this undefined symbol:
> >
> > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > function `am65_cpsw_init_cpts':
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:
> > undefined reference to `am65_cpts_create'
> > aarch64-linux-gnu-ld:
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:(.text+0x2e20):
> > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > `am65_cpts_create'
> > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > function `am65_cpsw_nuss_tx_compl_packets':
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:
> > undefined reference to `am65_cpts_tx_timestamp'
> > aarch64-linux-gnu-ld:
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:(.text+0x4cf0):
> > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > `am65_cpts_tx_timestamp'
> > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > function `am65_cpsw_nuss_ndo_slave_xmit':
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:
> > undefined reference to `am65_cpts_prep_tx_timestamp'
> > aarch64-linux-gnu-ld:
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:(.text+0x58fc):
> > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > `am65_cpts_prep_tx_timestamp'
> > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
> > function `am65_cpsw_nuss_hwtstamp_set':
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:
> > undefined reference to `am65_cpts_rx_enable'
> > aarch64-linux-gnu-ld:
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:(.text+0x7564):
> > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > `am65_cpts_rx_enable'
> > aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-ethtool.o: in
> > function `am65_cpsw_get_ethtool_ts_info':
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:
> > undefined reference to `am65_cpts_phc_index'
> > aarch64-linux-gnu-ld:
> > /srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:(.text+0xbe8):
> > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > `am65_cpts_phc_index'
> > make[1]: *** [/srv/src/kernel/next/Makefile:1114: vmlinux] Error 1
> > make[1]: Target 'Image' not remade because of errors.
> > make: *** [Makefile:180: sub-make] Error 2
> > make: Target 'Image' not remade because of errors.
>
> Sry, I can't reproduce it net-next.

Oh I forgot to try net-next, sorry.

> trying next...

Thank you.

> What's your config?

This is the config [1] I used.

Cheers,
Anders
[1] https://people.linaro.org/~anders.roxell/kernel-next-20200505.config

>
> --
> Best regards,
> grygorii


[PATCH v2 4/6] drivers: base: default KUNIT_* fragments to KUNIT_RUN_ALL

2020-05-05 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
someone wants that even though KUNIT_RUN_ALL is enabled.

Signed-off-by: Anders Roxell 
---
 drivers/base/Kconfig  | 3 ++-
 drivers/base/test/Kconfig | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 5f0bc74d2409..c48e6e4ef367 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -149,8 +149,9 @@ config DEBUG_TEST_DRIVER_REMOVE
  test this functionality.
 
 config PM_QOS_KUNIT_TEST
-   bool "KUnit Test for PM QoS features"
+   bool "KUnit Test for PM QoS features" if !KUNIT_RUN_ALL
depends on KUNIT=y
+   default KUNIT_RUN_ALL
 
 config HMEM_REPORTING
bool
diff --git a/drivers/base/test/Kconfig b/drivers/base/test/Kconfig
index 305c7751184a..0d662d689f6b 100644
--- a/drivers/base/test/Kconfig
+++ b/drivers/base/test/Kconfig
@@ -9,5 +9,6 @@ config TEST_ASYNC_DRIVER_PROBE
 
  If unsure say N.
 config KUNIT_DRIVER_PE_TEST
-   bool "KUnit Tests for property entry API"
+   bool "KUnit Tests for property entry API" if !KUNIT_RUN_ALL
depends on KUNIT=y
+   default KUNIT_RUN_ALL
-- 
2.20.1



[PATCH v2 5/6] fs: ext4: default KUNIT_* fragments to KUNIT_RUN_ALL

2020-05-05 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
someone wants that even though KUNIT_RUN_ALL is enabled.

Signed-off-by: Anders Roxell 
---
 fs/ext4/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
index 2a592e38cdfe..76785143259d 100644
--- a/fs/ext4/Kconfig
+++ b/fs/ext4/Kconfig
@@ -103,9 +103,10 @@ config EXT4_DEBUG
echo 1 > /sys/module/ext4/parameters/mballoc_debug
 
 config EXT4_KUNIT_TESTS
-   tristate "KUnit tests for ext4"
+   tristate "KUnit tests for ext4" if !KUNIT_RUN_ALL
select EXT4_FS
depends on KUNIT
+   default KUNIT_RUN_ALL
help
  This builds the ext4 KUnit tests.
 
-- 
2.20.1



[PATCH v2 6/6] security: apparmor: default KUNIT_* fragments to KUNIT_RUN_ALL

2020-05-05 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
someone wants that even though KUNIT_RUN_ALL is enabled.

Signed-off-by: Anders Roxell 
---
 security/apparmor/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig
index 0fe336860773..c4648426ea5d 100644
--- a/security/apparmor/Kconfig
+++ b/security/apparmor/Kconfig
@@ -70,8 +70,9 @@ config SECURITY_APPARMOR_DEBUG_MESSAGES
  the kernel message buffer.
 
 config SECURITY_APPARMOR_KUNIT_TEST
-   bool "Build KUnit tests for policy_unpack.c"
+   bool "Build KUnit tests for policy_unpack.c" if !KUNIT_RUN_ALL
depends on KUNIT=y && SECURITY_APPARMOR
+   default KUNIT_RUN_ALL
help
  This builds the AppArmor KUnit tests.
 
-- 
2.20.1



[PATCH v2 3/6] lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_RUN_ALL

2020-05-05 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
someone wants that even though KUNIT_RUN_ALL is enabled.

Signed-off-by: Anders Roxell 
---
 lib/Kconfig.debug | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 21d9c5f6e7ec..d1a94ff56a87 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2064,8 +2064,9 @@ config TEST_SYSCTL
  If unsure, say N.
 
 config SYSCTL_KUNIT_TEST
-   tristate "KUnit test for sysctl"
+   tristate "KUnit test for sysctl" if !KUNIT_RUN_ALL
depends on KUNIT
+   default KUNIT_RUN_ALL
help
  This builds the proc sysctl unit test, which runs on boot.
  Tests the API contract and implementation correctness of sysctl.
@@ -2075,8 +2076,9 @@ config SYSCTL_KUNIT_TEST
  If unsure, say N.
 
 config LIST_KUNIT_TEST
-   tristate "KUnit Test for Kernel Linked-list structures"
+   tristate "KUnit Test for Kernel Linked-list structures" if 
!KUNIT_RUN_ALL
depends on KUNIT
+   default KUNIT_RUN_ALL
help
  This builds the linked list KUnit test suite.
  It tests that the API and basic functionality of the list_head type
-- 
2.20.1



[PATCH v2 0/6] Enable as many KUnit tests as possible

2020-05-05 Thread Anders Roxell
Hi,

This patchset will try to enable as many KUnit test fragments as
possible for the current .config file.
This will make it easier for both developers that tests their specific
feature and also for test-systems that would like to get as much as
possible for their current .config file.

I will send a separate KCSAN KUnit patch after this patchset since that
isn't in mainline yet.

Since v1:
Marco commented to split up the patches, and change a "." to a ",".


Cheers,
Anders

Anders Roxell (6):
  kunit: Kconfig: enable a KUNIT_RUN_ALL fragment
  kunit: default KUNIT_* fragments to KUNIT_RUN_ALL
  lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_RUN_ALL
  drivers: base: default KUNIT_* fragments to KUNIT_RUN_ALL
  fs: ext4: default KUNIT_* fragments to KUNIT_RUN_ALL
  security: apparmor: default KUNIT_* fragments to KUNIT_RUN_ALL

 drivers/base/Kconfig  |  3 ++-
 drivers/base/test/Kconfig |  3 ++-
 fs/ext4/Kconfig   |  3 ++-
 lib/Kconfig.debug |  6 --
 lib/kunit/Kconfig | 15 ---
 security/apparmor/Kconfig |  3 ++-
 6 files changed, 24 insertions(+), 9 deletions(-)

-- 
2.20.1



[PATCH v2 1/6] kunit: Kconfig: enable a KUNIT_RUN_ALL fragment

2020-05-05 Thread Anders Roxell
Make it easier to enable all KUnit fragments.  This is needed for kernel
test-systems, so its easy to get all KUnit tests enabled and if new gets
added they will be enabled as well.  Fragments that has to be builtin
will be missed if CONFIG_KUNIT_RUN_ALL is set as a module.

Signed-off-by: Anders Roxell 
---
 lib/kunit/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 95d12e3d6d95..537f37bc8400 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -41,4 +41,10 @@ config KUNIT_EXAMPLE_TEST
  is intended for curious hackers who would like to understand how to
  use KUnit for kernel development.
 
+config KUNIT_RUN_ALL
+   tristate "KUnit run all test"
+   help
+ Enables all KUnit tests, if they can be enabled.
+ That depends on if KUnit is enabled as a module or builtin.
+
 endif # KUNIT
-- 
2.20.1



[PATCH v2 2/6] kunit: default KUNIT_* fragments to KUNIT_RUN_ALL

2020-05-05 Thread Anders Roxell
This makes it easier to enable all KUnit fragments.

Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
someone wants that even though KUNIT_RUN_ALL is enabled.

Signed-off-by: Anders Roxell 
---
 lib/kunit/Kconfig | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 537f37bc8400..e6a60391fa6b 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -15,7 +15,8 @@ menuconfig KUNIT
 if KUNIT
 
 config KUNIT_DEBUGFS
-   bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation"
+   bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation" if 
!KUNIT_RUN_ALL
+   default KUNIT_RUN_ALL
help
  Enable debugfs representation for kunit.  Currently this consists
  of /sys/kernel/debug/kunit//results files for each
@@ -23,7 +24,8 @@ config KUNIT_DEBUGFS
  run that occurred.
 
 config KUNIT_TEST
-   tristate "KUnit test for KUnit"
+   tristate "KUnit test for KUnit" if !KUNIT_RUN_ALL
+   default KUNIT_RUN_ALL
help
  Enables the unit tests for the KUnit test framework. These tests test
  the KUnit test framework itself; the tests are both written using
@@ -32,7 +34,8 @@ config KUNIT_TEST
  expected.
 
 config KUNIT_EXAMPLE_TEST
-   tristate "Example test for KUnit"
+   tristate "Example test for KUnit" if !KUNIT_RUN_ALL
+   default KUNIT_RUN_ALL
help
  Enables an example unit test that illustrates some of the basic
  features of KUnit. This test only exists to help new users understand
-- 
2.20.1



Re: [PATCH net-next 3/7] net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support

2020-05-05 Thread Anders Roxell
On Fri, 1 May 2020 at 22:50, Grygorii Strashko  wrote:
>
> The MCU CPSW Common Platform Time Sync (CPTS) provides possibility to
> timestamp TX PTP packets and all RX packets.
>
> This enables corresponding support in TI AM65x/J721E MCU CPSW driver.
>
> Signed-off-by: Grygorii Strashko 
> ---
>  drivers/net/ethernet/ti/Kconfig |   1 +
>  drivers/net/ethernet/ti/am65-cpsw-ethtool.c |  24 ++-
>  drivers/net/ethernet/ti/am65-cpsw-nuss.c| 172 
>  drivers/net/ethernet/ti/am65-cpsw-nuss.h|   6 +-
>  4 files changed, 201 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index 1f4e5b6dc686..2c7bd1ccaaec 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -100,6 +100,7 @@ config TI_K3_AM65_CPSW_NUSS
> depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
> select TI_DAVINCI_MDIO
> imply PHY_TI_GMII_SEL
> +   imply TI_AM65_CPTS

Should this be TI_K3_AM65_CPTS ?

I did an arm64 allmodconfig build on todays next tag: next-20200505
and got this undefined symbol:

aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_init_cpts':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:
undefined reference to `am65_cpts_create'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:(.text+0x2e20):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_create'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_nuss_tx_compl_packets':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:
undefined reference to `am65_cpts_tx_timestamp'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:(.text+0x4cf0):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_tx_timestamp'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_nuss_ndo_slave_xmit':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:
undefined reference to `am65_cpts_prep_tx_timestamp'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:(.text+0x58fc):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_prep_tx_timestamp'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_nuss_hwtstamp_set':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:
undefined reference to `am65_cpts_rx_enable'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:(.text+0x7564):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_rx_enable'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-ethtool.o: in
function `am65_cpsw_get_ethtool_ts_info':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:
undefined reference to `am65_cpts_phc_index'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:(.text+0xbe8):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_phc_index'
make[1]: *** [/srv/src/kernel/next/Makefile:1114: vmlinux] Error 1
make[1]: Target 'Image' not remade because of errors.
make: *** [Makefile:180: sub-make] Error 2
make: Target 'Image' not remade because of errors.


Cheers,
Anders

> help
>   This driver supports TI K3 AM654/J721E CPSW2G Ethernet SubSystem.
>   The two-port Gigabit Ethernet MAC (MCU_CPSW0) subsystem provides
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-ethtool.c 
> b/drivers/net/ethernet/ti/am65-cpsw-ethtool.c
> index c3502aa15ea0..23661a6ed426 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-ethtool.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-ethtool.c
> @@ -12,6 +12,7 @@
>
>  #include "am65-cpsw-nuss.h"
>  #include "cpsw_ale.h"
> +#include "am65-cpts.h"
>
>  #define AM65_CPSW_REGDUMP_VER 0x1
>
> @@ -694,6 +695,27 @@ static void am65_cpsw_get_ethtool_stats(struct 
> net_device *ndev,
> hw_stats[i].offset);
>  }
>
> +static int am65_cpsw_get_ethtool_ts_info(struct net_device *ndev,
> +struct ethtool_ts_info *info)
> +{
> +   struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
> +
> +   if (!IS_ENABLED(CONFIG_TI_K3_AM65_CPTS))
> +   return ethtool_op_get_ts_info(ndev, info);
> +
> +   info->so_timestamping =
> +   SOF_TIMESTAMPING_TX_HARDWARE |
> +   SOF_TIMESTAMPING_TX_SOFTWARE |
> +   SOF_TIMESTAMPING_RX_HARDWARE |
> +

Re: linux-next: Tree for May 5

2020-05-05 Thread Anders Roxell
On Tue, 5 May 2020 at 09:16, Stephen Rothwell  wrote:
>
> Hi all,
>
> Changes since 20200504:
>
> New tree: ti-k3
>
> My fixes tree contains:
>
>   bbefc924d0ff ("ubsan: disable UBSAN_ALIGNMENT under COMPILE_TEST")
>   7cb1d38f52b1 ("drm/msm: Fix undefined "rd_full" link error")
>
> The qcom tree still had its build failure for which I reverted a commit.
>
> Non-merge commits (relative to Linus' tree): 5888
>  6922 files changed, 233385 insertions(+), 91859 deletions(-)
>

I did an arm64 allmodconfig build and got this undefined symbol:

aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_init_cpts':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:
undefined reference to `am65_cpts_create'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1685:(.text+0x2e20):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_create'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_nuss_tx_compl_packets':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:
undefined reference to `am65_cpts_tx_timestamp'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:923:(.text+0x4cf0):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_tx_timestamp'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_nuss_ndo_slave_xmit':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:
undefined reference to `am65_cpts_prep_tx_timestamp'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1018:(.text+0x58fc):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_prep_tx_timestamp'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-nuss.o: in
function `am65_cpsw_nuss_hwtstamp_set':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:
undefined reference to `am65_cpts_rx_enable'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-nuss.c:1265:(.text+0x7564):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_rx_enable'
aarch64-linux-gnu-ld: drivers/net/ethernet/ti/am65-cpsw-ethtool.o: in
function `am65_cpsw_get_ethtool_ts_info':
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:
undefined reference to `am65_cpts_phc_index'
aarch64-linux-gnu-ld:
/srv/src/kernel/next/obj-arm64-next-20200505/../drivers/net/ethernet/ti/am65-cpsw-ethtool.c:713:(.text+0xbe8):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`am65_cpts_phc_index'
make[1]: *** [/srv/src/kernel/next/Makefile:1114: vmlinux] Error 1
make[1]: Target 'Image' not remade because of errors.
make: *** [Makefile:180: sub-make] Error 2
make: Target 'Image' not remade because of errors.


I was able to build if I reverted this patch:
b1f66a5bee07 ("net: ethernet: ti: am65-cpsw-nuss: enable packet
timestamping support")


Cheers,
Anders


Re: [PATCH] kunit: Kconfig: enable a KUNIT_RUN_ALL fragment

2020-05-05 Thread Anders Roxell
On Sat, 2 May 2020 at 04:11, David Gow  wrote:
>
> On Sat, May 2, 2020 at 4:31 AM Brendan Higgins
>  wrote:
> >
> > On Fri, May 1, 2020 at 1:35 AM Anders Roxell  
> > wrote:
> > >
> > > Make it easier to enable all KUnit fragments.  This is needed for kernel
> > > test-systems, so its easy to get all KUnit tests enabled and if new gets
> > > added they will be enabled as well.  Fragments that has to be builtin
> > > will be missed if CONFIG_KUNIT_RUN_ALL is set as a module.
> > >
> > > Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
> > > someone wants that even though KUNIT_RUN_ALL is enabled.
> >
> > I would LOVE IT, if you could make this work! I have been trying to
> > figure out the best way to run all KUnit tests for a long time now.
> >
> > That being said, I am a bit skeptical that this approach will be much
> > more successful than just using allyesconfig. Either way, there are
> > tests coming down the pipeline that are incompatible with each other
> > (the KASAN test and the KCSAN test will be incompatible). Even so,
> > tests like the apparmor test require a lot of non-default
> > configuration to compile. In the end, I am not sure how many tests we
> > will really be able to turn on this way.
> >
> > Thoughts?
>
> I think there's still some value in this which the allyesconfig option
> doesn't provide. As you point out, it's not possible to have a generic
> "run all tests" option due to potential conflicting dependencies, but
> this does provide a way to run all tests for things enabled in the
> current config. This could be really useful for downstream developers
> who want a way of running all tests relevant to their config without
> the overhead of running irrelevant tests (e.g., for drivers they don't
> build).

It will solve that as well as for a tester doesn't have to go through all KUnit
tests fragments to turn them on.

> Using allyesconfig doesn't make that distinction.

We could also create a config fragment file in kernel/configs/kunit.config
where we set
--start
CONFIG_KUNIT=y
CONFIG_KUNIT_RUN_ALL=y
CONFIG_SECURITY_APPARMOR=y
--end


So, these two can only be enabled if KUNIT=y
CONFIG_KUNIT_DRIVER_PE_TEST=y
CONFIG_PM_QOS_KUNIT_TEST=y

and for this one we have a pre-request of SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_KUNIT_TEST=y

Other tests solves the dependencies with 'select' like
CONFIG_EXT4_KUNIT_TESTS, that adds this row in
fs/ext4/Kconfig, 'select EXT4_FS'

But I think we should try to minimize the number of 'select' statements,
in order to avoid circular dependencies and unexpected behaviours.
Maybe we should add the CONFIG_EXT4_FS=y into the kunit.config
file instead ?


>
> Ultimately, we'll probably still want something which enables a
> broader set of tests for upstream development: whether that's based on
> this, allyesconfig, or something else entirely remains to be seen, I
> think. I suspect we're going to end up with something
> subsystem-specific (having a kunitconfig per subsystem, or a testing
> line in MAINTAINERS or similar are ideas which have been brought up in
> the past).
>
> This is a great looking tool to have in the toolbox, though.

I agree!

I'll prepare a patchset with individual patches as was suggested by Marco
shortly.

Cheers,
Anders


Re: [PATCH] kunit: Kconfig: enable a KUNIT_RUN_ALL fragment

2020-05-01 Thread Anders Roxell
On Fri, 1 May 2020 at 11:57, Marco Elver  wrote:
>
> On Fri, 1 May 2020 at 10:35, Anders Roxell  wrote:
> >
> > Make it easier to enable all KUnit fragments.  This is needed for kernel
> > test-systems, so its easy to get all KUnit tests enabled and if new gets
> > added they will be enabled as well.  Fragments that has to be builtin
> > will be missed if CONFIG_KUNIT_RUN_ALL is set as a module.
> >
> > Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
> > someone wants that even though KUNIT_RUN_ALL is enabled.
> >
> > Signed-off-by: Anders Roxell 
> > ---
> >  drivers/base/Kconfig  |  3 ++-
> >  drivers/base/test/Kconfig |  3 ++-
> >  fs/ext4/Kconfig   |  3 ++-
> >  lib/Kconfig.debug |  6 --
> >  lib/Kconfig.kcsan |  3 ++-
> >  lib/kunit/Kconfig | 15 ---
> >  security/apparmor/Kconfig |  3 ++-
> >  7 files changed, 26 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 5f0bc74d2409..c48e6e4ef367 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -149,8 +149,9 @@ config DEBUG_TEST_DRIVER_REMOVE
> >   test this functionality.
> >
> >  config PM_QOS_KUNIT_TEST
> > -   bool "KUnit Test for PM QoS features"
> > +   bool "KUnit Test for PM QoS features" if !KUNIT_RUN_ALL
> > depends on KUNIT=y
> > +   default KUNIT_RUN_ALL
> >
> >  config HMEM_REPORTING
> > bool
> > diff --git a/drivers/base/test/Kconfig b/drivers/base/test/Kconfig
> > index 305c7751184a..0d662d689f6b 100644
> > --- a/drivers/base/test/Kconfig
> > +++ b/drivers/base/test/Kconfig
> > @@ -9,5 +9,6 @@ config TEST_ASYNC_DRIVER_PROBE
> >
> >   If unsure say N.
> >  config KUNIT_DRIVER_PE_TEST
> > -   bool "KUnit Tests for property entry API"
> > +   bool "KUnit Tests for property entry API" if !KUNIT_RUN_ALL
> > depends on KUNIT=y
> > +   default KUNIT_RUN_ALL
> > diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
> > index 2a592e38cdfe..76785143259d 100644
> > --- a/fs/ext4/Kconfig
> > +++ b/fs/ext4/Kconfig
> > @@ -103,9 +103,10 @@ config EXT4_DEBUG
> > echo 1 > /sys/module/ext4/parameters/mballoc_debug
> >
> >  config EXT4_KUNIT_TESTS
> > -   tristate "KUnit tests for ext4"
> > +   tristate "KUnit tests for ext4" if !KUNIT_RUN_ALL
> > select EXT4_FS
> > depends on KUNIT
> > +   default KUNIT_RUN_ALL
> > help
> >   This builds the ext4 KUnit tests.
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 8e4aded46281..993e0c5549bc 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -2123,8 +2123,9 @@ config TEST_SYSCTL
> >   If unsure, say N.
> >
> >  config SYSCTL_KUNIT_TEST
> > -   tristate "KUnit test for sysctl"
> > +   tristate "KUnit test for sysctl" if !KUNIT_RUN_ALL
> > depends on KUNIT
> > +   default KUNIT_RUN_ALL
> > help
> >   This builds the proc sysctl unit test, which runs on boot.
> >   Tests the API contract and implementation correctness of sysctl.
> > @@ -2134,8 +2135,9 @@ config SYSCTL_KUNIT_TEST
> >   If unsure, say N.
> >
> >  config LIST_KUNIT_TEST
> > -   tristate "KUnit Test for Kernel Linked-list structures"
> > +   tristate "KUnit Test for Kernel Linked-list structures" if 
> > !KUNIT_RUN_ALL
> > depends on KUNIT
> > +   default KUNIT_RUN_ALL
> > help
> >   This builds the linked list KUnit test suite.
> >   It tests that the API and basic functionality of the list_head 
> > type
> > diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
> > index ea28245c6c1d..91398300a1bc 100644
> > --- a/lib/Kconfig.kcsan
> > +++ b/lib/Kconfig.kcsan
> > @@ -46,8 +46,9 @@ config KCSAN_SELFTEST
> >   works as intended.
> >
> >  config KCSAN_TEST
> > -   tristate "KCSAN test for integrated runtime behaviour"
> > +   tristate "KCSAN test for integrated runtime behaviour" if 
> > !KUNIT_RUN_ALL
> > depends on TRACEPOINTS && KUNIT
> > +   default KUNIT_RUN_ALL
> > select TORTURE_TEST
> > help
> >   KCSAN test focusing on b

[PATCH] kunit: Kconfig: enable a KUNIT_RUN_ALL fragment

2020-05-01 Thread Anders Roxell
Make it easier to enable all KUnit fragments.  This is needed for kernel
test-systems, so its easy to get all KUnit tests enabled and if new gets
added they will be enabled as well.  Fragments that has to be builtin
will be missed if CONFIG_KUNIT_RUN_ALL is set as a module.

Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if
someone wants that even though KUNIT_RUN_ALL is enabled.

Signed-off-by: Anders Roxell 
---
 drivers/base/Kconfig  |  3 ++-
 drivers/base/test/Kconfig |  3 ++-
 fs/ext4/Kconfig   |  3 ++-
 lib/Kconfig.debug |  6 --
 lib/Kconfig.kcsan |  3 ++-
 lib/kunit/Kconfig | 15 ---
 security/apparmor/Kconfig |  3 ++-
 7 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 5f0bc74d2409..c48e6e4ef367 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -149,8 +149,9 @@ config DEBUG_TEST_DRIVER_REMOVE
  test this functionality.
 
 config PM_QOS_KUNIT_TEST
-   bool "KUnit Test for PM QoS features"
+   bool "KUnit Test for PM QoS features" if !KUNIT_RUN_ALL
depends on KUNIT=y
+   default KUNIT_RUN_ALL
 
 config HMEM_REPORTING
bool
diff --git a/drivers/base/test/Kconfig b/drivers/base/test/Kconfig
index 305c7751184a..0d662d689f6b 100644
--- a/drivers/base/test/Kconfig
+++ b/drivers/base/test/Kconfig
@@ -9,5 +9,6 @@ config TEST_ASYNC_DRIVER_PROBE
 
  If unsure say N.
 config KUNIT_DRIVER_PE_TEST
-   bool "KUnit Tests for property entry API"
+   bool "KUnit Tests for property entry API" if !KUNIT_RUN_ALL
depends on KUNIT=y
+   default KUNIT_RUN_ALL
diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
index 2a592e38cdfe..76785143259d 100644
--- a/fs/ext4/Kconfig
+++ b/fs/ext4/Kconfig
@@ -103,9 +103,10 @@ config EXT4_DEBUG
echo 1 > /sys/module/ext4/parameters/mballoc_debug
 
 config EXT4_KUNIT_TESTS
-   tristate "KUnit tests for ext4"
+   tristate "KUnit tests for ext4" if !KUNIT_RUN_ALL
select EXT4_FS
depends on KUNIT
+   default KUNIT_RUN_ALL
help
  This builds the ext4 KUnit tests.
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8e4aded46281..993e0c5549bc 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2123,8 +2123,9 @@ config TEST_SYSCTL
  If unsure, say N.
 
 config SYSCTL_KUNIT_TEST
-   tristate "KUnit test for sysctl"
+   tristate "KUnit test for sysctl" if !KUNIT_RUN_ALL
depends on KUNIT
+   default KUNIT_RUN_ALL
help
  This builds the proc sysctl unit test, which runs on boot.
  Tests the API contract and implementation correctness of sysctl.
@@ -2134,8 +2135,9 @@ config SYSCTL_KUNIT_TEST
  If unsure, say N.
 
 config LIST_KUNIT_TEST
-   tristate "KUnit Test for Kernel Linked-list structures"
+   tristate "KUnit Test for Kernel Linked-list structures" if 
!KUNIT_RUN_ALL
depends on KUNIT
+   default KUNIT_RUN_ALL
help
  This builds the linked list KUnit test suite.
  It tests that the API and basic functionality of the list_head type
diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
index ea28245c6c1d..91398300a1bc 100644
--- a/lib/Kconfig.kcsan
+++ b/lib/Kconfig.kcsan
@@ -46,8 +46,9 @@ config KCSAN_SELFTEST
  works as intended.
 
 config KCSAN_TEST
-   tristate "KCSAN test for integrated runtime behaviour"
+   tristate "KCSAN test for integrated runtime behaviour" if !KUNIT_RUN_ALL
depends on TRACEPOINTS && KUNIT
+   default KUNIT_RUN_ALL
select TORTURE_TEST
help
  KCSAN test focusing on behaviour of the integrated runtime. Tests
diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 95d12e3d6d95..d6a912779816 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -15,7 +15,8 @@ menuconfig KUNIT
 if KUNIT
 
 config KUNIT_DEBUGFS
-   bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation"
+   bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation" if 
!KUNIT_RUN_ALL
+   default KUNIT_RUN_ALL
help
  Enable debugfs representation for kunit.  Currently this consists
  of /sys/kernel/debug/kunit//results files for each
@@ -23,7 +24,8 @@ config KUNIT_DEBUGFS
  run that occurred.
 
 config KUNIT_TEST
-   tristate "KUnit test for KUnit"
+   tristate "KUnit test for KUnit" if !KUNIT_RUN_ALL
+   default KUNIT_RUN_ALL
help
  Enables the unit tests for the KUnit test framework. These tests test
  the KUnit test framework itself; the tests are both written using
@@ -32,7 +34,8 @@ config KUNIT_TEST
  expected.
 
 config KUNIT_EXAMPLE_TEST
-   tristate "Example test f

Re: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support

2019-10-22 Thread Anders Roxell
On 2019-10-22 10:19, Peng Ma wrote:
> Hi Anders && Viod,
> 
> I sent v6 patch to fix the build error, please check.

oh I will check, didn't see them when I sent out my email. =/

Cheers,
Anders

> Patchwork link:
> https://patchwork.kernel.org/project/linux-dmaengine/list/?series=191397
> 
> Best Regards,
> Peng
> >-Original Message-
> >From: Anders Roxell 
> >Sent: 2019年10月22日 17:27
> >To: Peng Ma 
> >Cc: Vinod Koul ; dan.j.willi...@intel.com; Leo Li
> >; linux-kernel@vger.kernel.org;
> >dmaeng...@vger.kernel.org
> >Subject: Re: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
> >DPDMAI(Data Path DMA Interface) support
> >
> >Caution: EXT Email
> >
> >On Thu, 17 Oct 2019 at 08:16, Peng Ma  wrote:
> >>
> >> Hi Vinod,
> >>
> >> Thanks very much for your reply.
> >>
> >> Best Regards,
> >> Peng
> >> >-Original Message-
> >> >From: Vinod Koul 
> >> >Sent: 2019年10月17日 12:11
> >> >To: Peng Ma 
> >> >Cc: dan.j.willi...@intel.com; Leo Li ;
> >> >linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org
> >> >Subject: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
> >> >DPDMAI(Data Path DMA Interface) support
> >> >
> >> >Caution: EXT Email
> >> >
> >> >On 30-09-19, 02:04, Peng Ma wrote:
> >> >> The MC(Management Complex) exports the DPDMAI(Data Path DMA
> >> >Interface)
> >> >> object as an interface to operate the DPAA2(Data Path Acceleration
> >> >> Architecture 2) qDMA Engine. The DPDMAI enables sending frame-based
> >> >> requests to qDMA and receiving back confirmation response on
> >> >> transaction completion, utilizing the DPAA2 QBMan(Queue Manager and
> >> >> Buffer Manager
> >> >> hardware) infrastructure. DPDMAI object provides up to two
> >> >> priorities for processing qDMA requests.
> >> >> The following list summarizes the DPDMAI main features and capabilities:
> >> >>   1. Supports up to two scheduling priorities for processing
> >> >>   service requests.
> >> >>   - Each DPDMAI transmit queue is mapped to one of two service
> >> >>   priorities, allowing further prioritization in hardware between
> >> >>   requests from different DPDMAI objects.
> >> >>   2. Supports up to two receive queues for incoming transaction
> >> >>   completion confirmations.
> >> >>   - Each DPDMAI receive queue is mapped to one of two receive
> >> >>   priorities, allowing further prioritization between other
> >> >>   interfaces when associating the DPDMAI receive queues to DPIO
> >> >>   or DPCON(Data Path Concentrator) objects.
> >> >>   3. Supports different scheduling options for processing received
> >> >>   packets:
> >> >>   - Queues can be configured either in 'parked' mode (default),
> >> >>   or attached to a DPIO object, or attached to DPCON object.
> >> >>   4. Allows interaction with one or more DPIO objects for
> >> >>   dequeueing/enqueueing frame descriptors(FD) and for
> >> >>   acquiring/releasing buffers.
> >> >>   5. Supports enable, disable, and reset operations.
> >> >>
> >> >> Add dpdmai to support some platforms with dpaa2 qdma engine.
> >> >
> >> >Applied both, thanks
> >
> >I see this error when I'm building.
> >
> >WARNING: modpost: missing MODULE_LICENSE() in
> >drivers/dma/fsl-dpaa2-qdma/dpdmai.o
> >see include/linux/module.h for more information
> >ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
> >undefined!
> >ERROR: "dpdmai_set_rx_queue"
> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> >ERROR: "dpdmai_get_tx_queue"
> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> >ERROR: "dpdmai_get_rx_queue"
> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> >ERROR: "dpdmai_get_attributes"
> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> >ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
> >undefined!
> >ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
> >undefined!
> >ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
> >undefined!
> >ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
> >undefined!
> >make[2]: *** [../scripts/Makefile.modpost:95: __modpost] Error 1
> >make[1]: *** [/srv/src/kernel/next/Makefile:1282: modules] Error 2
> >make: *** [Makefile:179: sub-make] Error 2
> >make: Target 'Image' not remade because of errors.
> >make: Target 'modules' not remade because of errors.
> >
> >any other that see the same ?
> >
> >Cheers,
> >Anders


Re: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support

2019-10-22 Thread Anders Roxell
On Thu, 17 Oct 2019 at 08:16, Peng Ma  wrote:
>
> Hi Vinod,
>
> Thanks very much for your reply.
>
> Best Regards,
> Peng
> >-Original Message-
> >From: Vinod Koul 
> >Sent: 2019年10月17日 12:11
> >To: Peng Ma 
> >Cc: dan.j.willi...@intel.com; Leo Li ;
> >linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org
> >Subject: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data
> >Path DMA Interface) support
> >
> >Caution: EXT Email
> >
> >On 30-09-19, 02:04, Peng Ma wrote:
> >> The MC(Management Complex) exports the DPDMAI(Data Path DMA
> >Interface)
> >> object as an interface to operate the DPAA2(Data Path Acceleration
> >> Architecture 2) qDMA Engine. The DPDMAI enables sending frame-based
> >> requests to qDMA and receiving back confirmation response on
> >> transaction completion, utilizing the DPAA2 QBMan(Queue Manager and
> >> Buffer Manager
> >> hardware) infrastructure. DPDMAI object provides up to two priorities
> >> for processing qDMA requests.
> >> The following list summarizes the DPDMAI main features and capabilities:
> >>   1. Supports up to two scheduling priorities for processing
> >>   service requests.
> >>   - Each DPDMAI transmit queue is mapped to one of two service
> >>   priorities, allowing further prioritization in hardware between
> >>   requests from different DPDMAI objects.
> >>   2. Supports up to two receive queues for incoming transaction
> >>   completion confirmations.
> >>   - Each DPDMAI receive queue is mapped to one of two receive
> >>   priorities, allowing further prioritization between other
> >>   interfaces when associating the DPDMAI receive queues to DPIO
> >>   or DPCON(Data Path Concentrator) objects.
> >>   3. Supports different scheduling options for processing received
> >>   packets:
> >>   - Queues can be configured either in 'parked' mode (default),
> >>   or attached to a DPIO object, or attached to DPCON object.
> >>   4. Allows interaction with one or more DPIO objects for
> >>   dequeueing/enqueueing frame descriptors(FD) and for
> >>   acquiring/releasing buffers.
> >>   5. Supports enable, disable, and reset operations.
> >>
> >> Add dpdmai to support some platforms with dpaa2 qdma engine.
> >
> >Applied both, thanks

I see this error when I'm building.

WARNING: modpost: missing MODULE_LICENSE() in
drivers/dma/fsl-dpaa2-qdma/dpdmai.o
see include/linux/module.h for more information
ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_set_rx_queue"
[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_get_tx_queue"
[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_get_rx_queue"
[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_get_attributes"
[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
make[2]: *** [../scripts/Makefile.modpost:95: __modpost] Error 1
make[1]: *** [/srv/src/kernel/next/Makefile:1282: modules] Error 2
make: *** [Makefile:179: sub-make] Error 2
make: Target 'Image' not remade because of errors.
make: Target 'modules' not remade because of errors.

any other that see the same ?

Cheers,
Anders


Re: [PATCH 3/3] arm64: configs: unset CPU_BIG_ENDIAN

2019-10-03 Thread Anders Roxell
On Tue, 1 Oct 2019 at 16:04, John Garry  wrote:
>
> On 26/09/2019 20:30, Anders Roxell wrote:
> > When building allmodconfig 
> > KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
> > CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
> > people wants.
>
> Today allmodconfig does not enable CONFIG_ACPI due to BE config, which
> is quite unfortunate, I'd say.

right.

>
> >
> > Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so
>
> defconfig

thanks.

>
> > it doesn't get enabled when building allmodconfig kernels. When doing a
> > 'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
>
> So without having to pass KCONFIG_ALLCONFIG or do anything else, what
> about a config for CONFIG_CPU_LITTLE_ENDIAN instead? I'm not sure if
> that was omitted for a specific reason.

Oh, I tried to elaborate on the idea in the cover letter, that using
the defconfig
as base and then configure the rest as modules is to get a bootable kernel
that have as many features turned on as possible. That will make it possible
to run as wide a range of testsuites as possible on a single kernel.

Does that make it clearer ?

Cheers,
Anders


>
> Thanks,
> John
>
> >
> > Signed-off-by: Anders Roxell 
> > ---
> >  arch/arm64/configs/defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index 878f379d8d84..c9aa6b9ee996 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y
> >  # CONFIG_SCHED_DEBUG is not set
> >  CONFIG_MEMTEST=y
> >  # CONFIG_CMDLINE_FORCE is not set
> > +# CONFIG_CPU_BIG_ENDIAN is not set
> >
>
>


[PATCH 3/3] arm64: configs: unset CPU_BIG_ENDIAN

2019-09-26 Thread Anders Roxell
When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
people wants.

Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so
it doesn't get enabled when building allmodconfig kernels. When doing a
'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.

Signed-off-by: Anders Roxell 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 878f379d8d84..c9aa6b9ee996 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y
 # CONFIG_SCHED_DEBUG is not set
 CONFIG_MEMTEST=y
 # CONFIG_CMDLINE_FORCE is not set
+# CONFIG_CPU_BIG_ENDIAN is not set
-- 
2.20.1



  1   2   3   4   >