* Re: [GIT PULL] Qualcomm ARM64 Defconfig updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:00 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, arm-soc, Kevin Hilman,
Olof Johansson, Linux ARM
In-Reply-To: <1567317285-8555-1-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> Qualcomm ARM64 Based defconfig Updates for v5.4
>
> * Enable Qualcomm MSM8916 clock drivers
> * Add DRM_MSM to ARCH_QCOM defconfigs
> * Enable Qualcomm SM8150 clock and pinctrl drivers
Pulled into arm/defconfig.
Please remember to send pull requests to soc@kernel.org to have them
linked in the patchwork instance at
https://patchwork.kernel.org/project/linux-soc/list/
Thanks,
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 4/4] DaVinci DT updates for v5.4
From: Arnd Bergmann @ 2019-09-04 14:57 UTC (permalink / raw)
To: Sekhar Nori
Cc: Bartosz Golaszewski, ARM-SoC Maintainers, Linux ARM Mailing List
In-Reply-To: <20190828151754.21023-4-nsekhar@ti.com>
On Wed, Aug 28, 2019 at 5:18 PM Sekhar Nori <nsekhar@ti.com> wrote:
> Contains a patch to switch to more generic compatible for SPI NOR.
> This helps SPI NOR to work on newer board variants.
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 3/4] DaVinci fbdev driver updates for v5.4
From: Arnd Bergmann @ 2019-09-04 14:56 UTC (permalink / raw)
To: Sekhar Nori
Cc: Bartosz Golaszewski, ARM-SoC Maintainers, Linux ARM Mailing List,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20190828151754.21023-3-nsekhar@ti.com>
On Wed, Aug 28, 2019 at 5:18 PM Sekhar Nori <nsekhar@ti.com> wrote:
> ----------------------------------------------------------------
> This converts the da8xx fbdev driver to use GPIO backlight device
> and regulator devices. This will finally help get rid of legacy
> GPIO API calls and simplify DaVinci GPIO driver.
>
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Andrey Konovalov @ 2019-09-04 14:52 UTC (permalink / raw)
To: Cristian Marussi
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <d6bc5c4b-68b5-0a58-0f52-8bce20986dcf@arm.com>
On Fri, Aug 23, 2019 at 7:49 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
>
> Hi
>
> On 23/08/2019 18:16, Andrey Konovalov wrote:
> > On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
> > <cristian.marussi@arm.com> wrote:
> >>
> >> Hi Andrey
> >>
> >> On 24/06/2019 15:33, Andrey Konovalov wrote:
> >>> This patch is a part of a series that extends kernel ABI to allow to pass
> >>> tagged user pointers (with the top byte set to something else other than
> >>> 0x00) as syscall arguments.
> >>>
> >>> This patch adds a simple test, that calls the uname syscall with a
> >>> tagged user pointer as an argument. Without the kernel accepting tagged
> >>> user pointers the test fails with EFAULT.
> >>>
> >>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> >>> ---
> >>> tools/testing/selftests/arm64/.gitignore | 1 +
> >>> tools/testing/selftests/arm64/Makefile | 11 +++++++
> >>> .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++
> >>> tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++
> >>> 4 files changed, 53 insertions(+)
> >>> create mode 100644 tools/testing/selftests/arm64/.gitignore
> >>> create mode 100644 tools/testing/selftests/arm64/Makefile
> >>> create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
> >>> create mode 100644 tools/testing/selftests/arm64/tags_test.c
> >>
> >> After building a fresh Kernel from arm64/for-next-core from scratch at:
> >>
> >> commit 239ab658bea3b387424501e7c416640d6752dc0c
> >> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d
> >> Author: Will Deacon <will@kernel.org>
> >> Date: Thu Aug 22 18:23:53 2019 +0100
> >>
> >> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core
> >>
> >>
> >> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT=
> >>
> >> 13:30 $ make TARGETS=arm64 kselftest-clean
> >> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> >> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>
> >> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23]
> >>
> >> 13:30 $ make TARGETS=arm64 kselftest
> >> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
> >> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
> >> ARCH=arm64 -C ../../.. headers_install
> >> HOSTCC scripts/basic/fixdep
> >> HOSTCC scripts/unifdef
> >> ...
> >> ...
> >> HDRINST usr/include/asm/msgbuf.h
> >> HDRINST usr/include/asm/shmbuf.h
> >> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include
> >> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> >> tags_test.c: In function ‘main’:
> >> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
> >> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >> ^~~~~~~~~~~~~~~~~~~~~~~
> >> PR_GET_TID_ADDRESS
> >> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in
> >> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
> >> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >> ^~~~~~~~~~~~~~~~~~~~~
> >> PR_GET_DUMPABLE
> >> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed
> >> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1
> >> Makefile:136: recipe for target 'all' failed
> >> make[2]: *** [all] Error 2
> >> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed
> >> make[1]: *** [kselftest] Error 2
> >> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >> Makefile:179: recipe for target 'sub-make' failed
> >> make: *** [sub-make] Error 2
> >>
> >> Despite seeing KSFT installing Kernel Headers, they cannot be found.
> >>
> >> Fixing this patch like this make it work for me:
> >>
> >> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> >> index a61b2e743e99..f9f79fb272f0 100644
> >> --- a/tools/testing/selftests/arm64/Makefile
> >> +++ b/tools/testing/selftests/arm64/Makefile
> >> @@ -4,6 +4,7 @@
> >> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
> >>
> >> ifneq (,$(filter $(ARCH),aarch64 arm64))
> >> +CFLAGS += -I../../../../usr/include/
> >> TEST_GEN_PROGS := tags_test
> >> TEST_PROGS := run_tags_test.sh
> >> endif
> >>
> >> but is not really a proper fix since it does NOT account for case in which you have
> >> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT.
> >>
> >> Am I missing something ?
> >
> > Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h,
> > and the test has #include <sys/prctl.h> so as long as you've updated
> > your kernel headers this should work.
> >
> > (I'm OOO next week, I'll see if I can reproduce this once I'm back).
>
> Ok. Thanks for the reply.
>
> I think I've got it in my local tree having cloned arm64/for-next-core:
>
> 18:32 $ egrep -A 10 PR_SET_TAG ./include/uapi/linux/prctl.h
> #define PR_SET_TAGGED_ADDR_CTRL 55
> #define PR_GET_TAGGED_ADDR_CTRL 56
> # define PR_TAGGED_ADDR_ENABLE (1UL << 0)
>
> #endif /* _LINUX_PRCTL_H */
>
> and Kernel header are locally installed in my kernel src dir (by KSFT indeed)
>
> 18:34 $ egrep -RA 10 PR_SET_TAG usr/include/
> usr/include/linux/prctl.h:#define PR_SET_TAGGED_ADDR_CTRL 55
> usr/include/linux/prctl.h-#define PR_GET_TAGGED_ADDR_CTRL 56
> usr/include/linux/prctl.h-# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
> usr/include/linux/prctl.h-
> usr/include/linux/prctl.h-#endif /* _LINUX_PRCTL_H */
>
> but how are they supposed to be found if nor the test Makefile
> neither the KSFT Makefile who installs them pass any -I options to the
> compiler ?
> I suppose <sys/prctl.h> tries to include arch specific headers from the regular system path,
> but when you are cross-compiling ?
>
> 18:34 $ make TARGETS=arm64 kselftest
> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
> ARCH=arm64 -C ../../.. headers_install
> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/usr/include
> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -O2 -g tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test
> tags_test.c: In function ‘main’:
> tags_test.c:20:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> ^~~~~~~~~~~~~~~~~~~~~~~
> PR_GET_TID_ADDRESS
> tags_test.c:20:12: note: each undeclared identifier is reported only once for each function it appears in
> tags_test.c:20:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> ^~~~~~~~~~~~~~~~~~~~~
> PR_GET_DUMPABLE
> ../../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test' failed
> make[4]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test] Error 1
> Makefile:19: recipe for target 'all' failed
> make[3]: *** [all] Error 2
> Makefile:137: recipe for target 'all' failed
> make[2]: *** [all] Error 2
> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1236: recipe for target 'kselftest' failed
> make[1]: *** [kselftest] Error 2
> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> Makefile:179: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
>
>
> In fact many KSFT testcases seems to brutally add default headers path:
>
> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/uapi/
> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/
> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../usr/include/
> tools/testing/selftests/net/Makefile:CFLAGS += -I../../../../usr/include/
> tools/testing/selftests/membarrier/Makefile:CFLAGS += -g -I../../../../usr/include/
> ...
Hi Cristian!
Indeed, I can reproduce the issue. I don't know what's the proper way
to resolve this. Adding "CFLAGS += -I../../../../usr/include/" looks
good to me. AFAICS your series resolves this issue in a similar way,
but I think we should fix this before the current rc is released. Do
you want to submit a patch that adds this simple fix or should I do
that?
Thanks!
>
> Cheers
>
> Cristian
> >
> >
> >
> >>
> >> Thanks
> >>
> >> Cristian
> >>
> >>>
> >>> diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
> >>> new file mode 100644
> >>> index 000000000000..e8fae8d61ed6
> >>> --- /dev/null
> >>> +++ b/tools/testing/selftests/arm64/.gitignore
> >>> @@ -0,0 +1 @@
> >>> +tags_test
> >>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> >>> new file mode 100644
> >>> index 000000000000..a61b2e743e99
> >>> --- /dev/null
> >>> +++ b/tools/testing/selftests/arm64/Makefile
> >>> @@ -0,0 +1,11 @@
> >>> +# SPDX-License-Identifier: GPL-2.0
> >>> +
> >>> +# ARCH can be overridden by the user for cross compiling
> >>> +ARCH ?= $(shell uname -m 2>/dev/null || echo not)
> >>> +
> >>> +ifneq (,$(filter $(ARCH),aarch64 arm64))
> >>> +TEST_GEN_PROGS := tags_test
> >>> +TEST_PROGS := run_tags_test.sh
> >>> +endif
> >>> +
> >>> +include ../lib.mk
> >>> diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
> >>> new file mode 100755
> >>> index 000000000000..745f11379930
> >>> --- /dev/null
> >>> +++ b/tools/testing/selftests/arm64/run_tags_test.sh
> >>> @@ -0,0 +1,12 @@
> >>> +#!/bin/sh
> >>> +# SPDX-License-Identifier: GPL-2.0
> >>> +
> >>> +echo "--------------------"
> >>> +echo "running tags test"
> >>> +echo "--------------------"
> >>> +./tags_test
> >>> +if [ $? -ne 0 ]; then
> >>> + echo "[FAIL]"
> >>> +else
> >>> + echo "[PASS]"
> >>> +fi
> >>> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
> >>> new file mode 100644
> >>> index 000000000000..22a1b266e373
> >>> --- /dev/null
> >>> +++ b/tools/testing/selftests/arm64/tags_test.c
> >>> @@ -0,0 +1,29 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>> +
> >>> +#include <stdio.h>
> >>> +#include <stdlib.h>
> >>> +#include <unistd.h>
> >>> +#include <stdint.h>
> >>> +#include <sys/prctl.h>
> >>> +#include <sys/utsname.h>
> >>> +
> >>> +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
> >>> +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
> >>> + SHIFT_TAG(tag))
> >>> +
> >>> +int main(void)
> >>> +{
> >>> + static int tbi_enabled = 0;
> >>> + struct utsname *ptr, *tagged_ptr;
> >>> + int err;
> >>> +
> >>> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >>> + tbi_enabled = 1;
> >>> + ptr = (struct utsname *)malloc(sizeof(*ptr));
> >>> + if (tbi_enabled)
> >>> + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
> >>> + err = uname(tagged_ptr);
> >>> + free(ptr);
> >>> +
> >>> + return err;
> >>> +}
> >>>
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/4] DaVinci defconfig updates for v5.4
From: Arnd Bergmann @ 2019-09-04 14:51 UTC (permalink / raw)
To: Sekhar Nori
Cc: Bartosz Golaszewski, ARM-SoC Maintainers, Linux ARM Mailing List
In-Reply-To: <20190828151754.21023-2-nsekhar@ti.com>
On Wed, Aug 28, 2019 at 5:18 PM Sekhar Nori <nsekhar@ti.com> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.4/defconfig
>
> for you to fetch changes up to e869e44f2d82b9b4d35d58ceaeeadb0242bc634c:
>
> ARM: davinci_all_defconfig: enable GPIO backlight (2019-08-08 14:33:45 +0530)
>
> ----------------------------------------------------------------
> Contains davinci_all_defconfig refresh using savedefconfig and a
> patch to enable GPIO backlight.
>
> ----------------------------------------------------------------
> Bartosz Golaszewski (2):
> ARM: davinci: refresh davinci_all_defconfig
> ARM: davinci_all_defconfig: enable GPIO backlight
I'm generally not a fan of these 'refresh defconfig' patches when they
silently change options that may or may not be needed.
Some lines are just moved around but these ones
are completely removed:
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT=y
-CONFIG_SND_SOC_TLV320AIC3X=m
-CONFIG_SND_SOC_DAVINCI_MCASP=m
-CONFIG_LEDS_TRIGGERS=y
-CONFIG_TI_EDMA=y
-# CONFIG_ARM_UNWIND is not set
I think most of these are ok, but I don't see any explanation
about why you turn off CONFIG_PREEMPT.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Yuehaibing @ 2019-09-04 14:42 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, linux-samsung-soc@vger.kernel.org, f.fainelli,
benjaminfair, shc_work, khilman, openbmc, michal.simek, jonathanh,
yuenn, wens, agross, bcm-kernel-feedback-list, linux-imx,
linux-arm-msm, linux-tegra, Andi Shyti, rjui, s.hauer, mripard,
broonie, linux-mediatek, linux-rpi-kernel, paul.walmsley,
matthias.bgg, linux-amlogic, linux-arm-kernel, baohua, sbranden,
yamada.masahiro, avifishman70, venture,
linux-kernel@vger.kernel.org, linux-spi, thierry.reding, wahrenst,
kernel, kgene, shawnguo
In-Reply-To: <CAJKOXPdq4as1Oe3U+9znkvP0RA=sxUoiWVBCSbzf_wq_um2t=w@mail.gmail.com>
On 2019/9/4 22:28, Krzysztof Kozlowski wrote:
> On Wed, 4 Sep 2019 at 16:00, YueHaibing <yuehaibing@huawei.com> wrote:
>>
>> Use devm_platform_ioremap_resource() to simplify the code a bit.
>> This is detected by coccinelle.
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>
> This tag does not look real... First of all where is the report?
It is our internal CI robot, which is unavailable to external temporarily.
> Second, it was reported by coccinelle.
> Reported-by should be use to give real credits.
>
> Best regards,
> Krzysztof
>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> drivers/spi/spi-s3c24xx.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/spi-s3c24xx.c b/drivers/spi/spi-s3c24xx.c
>> index aea8fd9..2d6e37f 100644
>> --- a/drivers/spi/spi-s3c24xx.c
>> +++ b/drivers/spi/spi-s3c24xx.c
>> @@ -487,7 +487,6 @@ static int s3c24xx_spi_probe(struct platform_device *pdev)
>> struct s3c2410_spi_info *pdata;
>> struct s3c24xx_spi *hw;
>> struct spi_master *master;
>> - struct resource *res;
>> int err = 0;
>>
>> master = spi_alloc_master(&pdev->dev, sizeof(struct s3c24xx_spi));
>> @@ -536,8 +535,7 @@ static int s3c24xx_spi_probe(struct platform_device *pdev)
>> dev_dbg(hw->dev, "bitbang at %p\n", &hw->bitbang);
>>
>> /* find and map our resources */
>> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> - hw->regs = devm_ioremap_resource(&pdev->dev, res);
>> + hw->regs = devm_platform_ioremap_resource(pdev, 0);
>> if (IS_ERR(hw->regs)) {
>> err = PTR_ERR(hw->regs);
>> goto err_no_pdata;
>> --
>> 2.7.4
>>
>>
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Mark Brown @ 2019-09-04 14:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, f.fainelli, benjaminfair, shc_work, khilman, openbmc,
YueHaibing, michal.simek, jonathanh, yuenn, wens, agross,
bcm-kernel-feedback-list, linux-imx, linux-arm-msm, linux-tegra,
Andi Shyti, rjui, s.hauer, mripard,
linux-samsung-soc@vger.kernel.org, linux-mediatek,
linux-rpi-kernel, paul.walmsley, matthias.bgg, linux-amlogic,
linux-arm-kernel, baohua, sbranden, yamada.masahiro, avifishman70,
venture, linux-kernel@vger.kernel.org, linux-spi, thierry.reding,
wahrenst, kernel, kgene, shawnguo
In-Reply-To: <CAJKOXPdq4as1Oe3U+9znkvP0RA=sxUoiWVBCSbzf_wq_um2t=w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 578 bytes --]
On Wed, Sep 04, 2019 at 04:28:29PM +0200, Krzysztof Kozlowski wrote:
> On Wed, 4 Sep 2019 at 16:00, YueHaibing <yuehaibing@huawei.com> wrote:
> > Reported-by: Hulk Robot <hulkci@huawei.com>
> This tag does not look real... First of all where is the report?
> Second, it was reported by coccinelle.
> Reported-by should be use to give real credits.
I think it's reasonable, it's giving credit to the automated system
they've got running coccinelle (which they do mention in their commit
logs). It doesn't really hurt anyone and lets people see their system
is finding stuff.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From: Qian Cai @ 2019-09-04 14:37 UTC (permalink / raw)
To: Walter Wu, Andrey Konovalov
Cc: wsd_upstream, Arnd Bergmann, Linux Memory Management List,
linux-mediatek, LKML, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, Linux ARM, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <1567606591.32522.21.camel@mtksdccf07>
On Wed, 2019-09-04 at 22:16 +0800, Walter Wu wrote:
> On Wed, 2019-09-04 at 15:44 +0200, Andrey Konovalov wrote:
> > On Wed, Sep 4, 2019 at 8:51 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > +config KASAN_DUMP_PAGE
> > > + bool "Dump the page last stack information"
> > > + depends on KASAN && PAGE_OWNER
> > > + help
> > > + By default, KASAN doesn't record alloc/free stack for page
> > > allocator.
> > > + It is difficult to fix up page use-after-free issue.
> > > + This feature depends on page owner to record the last stack of
> > > page.
> > > + It is very helpful for solving the page use-after-free or out-
> > > of-bound.
> >
> > I'm not sure if we need a separate config for this. Is there any
> > reason to not have this enabled by default?
>
> PAGE_OWNER need some memory usage, it is not allowed to enable by
> default in low RAM device. so I create new feature option and the person
> who wants to use it to enable it.
Or you can try to look into reducing the memory footprint of PAGE_OWNER to fit
your needs. It does not always need to be that way.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Andy Shevchenko @ 2019-09-04 14:33 UTC (permalink / raw)
To: dongchun.zhu
Cc: Mark Rutland, devicetree, srv_heupstream, shengnan.wang,
Tomasz Figa, louis.kuo, sj.huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, bingbu.cao, Mauro Carvalho Chehab,
linux-arm Mailing List, Linux Media Mailing List
In-Reply-To: <20190708100641.2702-3-dongchun.zhu@mediatek.com>
On Mon, Jul 8, 2019 at 5:13 PM <dongchun.zhu@mediatek.com> wrote:
>
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> This patch adds a V4L2 sub-device driver for DW9768 lens voice coil,
> and provides control to set the desired focus.
>
> The DW9807 is a 10 bit DAC from Dongwoon, designed for linear
> control of voice coil motor.
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + */
2019?
> + if (!client->adapter)
> + return -ENODEV;
Is it ever possible?
> + w_buf = kzalloc(size, GFP_KERNEL);
> + if (!w_buf)
> + return -1;
Error code?
> + do {
> + ret = i2c_transfer(client->adapter, &msg, 1);
> + if (ret != 1)
> + dev_err(&client->dev, "write fail, ret:%d, retry:%d\n",
> + ret, retry_cnt);
This is noise. And better to use positive condition.
> + else
> + break;
> + retry_cnt--;
> + } while (retry_cnt != 0);
> +
} while (--retry_cnt);
> + if (retry_cnt == 0) {
> + dev_err(&client->dev, "i2c write fail(%d)\n", ret);
> + return -EIO;
> + }
> +
> + kfree(w_buf);
> +
> + return 0;
> +}
> +static int dw9768_power_off(struct dw9768_device *dw9768_dev, bool standby)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&dw9768_dev->sd);
> + int ret;
> +
> + /*
> + * Go to standby first as real power off my be denied by the hardware
> + * (single power line control for both dw9768_dev and sensor).
> + */
> + if (standby) {
> + dw9768_dev->standby = true;
> + ret = dw9768_release(dw9768_dev);
> + if (ret)
> + dev_err(&client->dev, "dw9768_release failed!\n");
Is it fatal or not?
> + }
> + ret = regulator_disable(dw9768_dev->analog_regulator);
> + if (ret)
> + return ret;
> +
> + return 0;
return regulator_disable(...);
> +}
> + dev_err(dw9768_dev->sd.dev, "%s fail error: 0x%x\n",
> + __func__, hdl->error);
Non-informative message.
> +static int dw9768_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct dw9768_device *dw9768_dev;
> + int rval;
> +
> + dw9768_dev = devm_kzalloc(&client->dev, sizeof(*dw9768_dev),
> + GFP_KERNEL);
> + if (!dw9768_dev)
> + return -ENOMEM;
> +
> + dw9768_dev->analog_regulator = devm_regulator_get(dev, "afvdd");
> + if (IS_ERR(dw9768_dev->analog_regulator)) {
> + dev_err(dev, "cannot get analog regulator\n");
Would be noise in case of deferred probe.
> + return PTR_ERR(dw9768_dev->analog_regulator);
> + }
> +err_cleanup:
> + mutex_destroy(&dw9768_dev->power_lock);
> + dw9768_subdev_cleanup(dw9768_dev);
> + dev_err(dev, "Probe failed: %d\n", rval);
Noise. Device core has this already.
> + return rval;
> +}
> +static const struct i2c_device_id dw9768_id_table[] = {
> + { DW9768_NAME, 0 },
> + { { 0 } }
{} is enough.
> +};
> +MODULE_DEVICE_TABLE(i2c, dw9768_id_table);
> +
> +static const struct of_device_id dw9768_of_table[] = {
> + { .compatible = "dongwoon,dw9768" },
> + { { 0 } }
Ditto.
> +};
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Krzysztof Kozlowski @ 2019-09-04 14:28 UTC (permalink / raw)
To: YueHaibing
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, linux-samsung-soc@vger.kernel.org, f.fainelli,
benjaminfair, shc_work, khilman, openbmc, michal.simek, jonathanh,
yuenn, wens, agross, bcm-kernel-feedback-list, linux-imx,
linux-arm-msm, linux-tegra, Andi Shyti, rjui, s.hauer, mripard,
broonie, linux-mediatek, linux-rpi-kernel, paul.walmsley,
matthias.bgg, linux-amlogic, linux-arm-kernel, baohua, sbranden,
yamada.masahiro, avifishman70, venture,
linux-kernel@vger.kernel.org, linux-spi, thierry.reding, wahrenst,
kernel, kgene, shawnguo
In-Reply-To: <20190904135918.25352-26-yuehaibing@huawei.com>
On Wed, 4 Sep 2019 at 16:00, YueHaibing <yuehaibing@huawei.com> wrote:
>
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
This tag does not look real... First of all where is the report?
Second, it was reported by coccinelle.
Reported-by should be use to give real credits.
Best regards,
Krzysztof
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/spi/spi-s3c24xx.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-s3c24xx.c b/drivers/spi/spi-s3c24xx.c
> index aea8fd9..2d6e37f 100644
> --- a/drivers/spi/spi-s3c24xx.c
> +++ b/drivers/spi/spi-s3c24xx.c
> @@ -487,7 +487,6 @@ static int s3c24xx_spi_probe(struct platform_device *pdev)
> struct s3c2410_spi_info *pdata;
> struct s3c24xx_spi *hw;
> struct spi_master *master;
> - struct resource *res;
> int err = 0;
>
> master = spi_alloc_master(&pdev->dev, sizeof(struct s3c24xx_spi));
> @@ -536,8 +535,7 @@ static int s3c24xx_spi_probe(struct platform_device *pdev)
> dev_dbg(hw->dev, "bitbang at %p\n", &hw->bitbang);
>
> /* find and map our resources */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - hw->regs = devm_ioremap_resource(&pdev->dev, res);
> + hw->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(hw->regs)) {
> err = PTR_ERR(hw->regs);
> goto err_no_pdata;
> --
> 2.7.4
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Jurgen Lambrecht @ 2019-09-04 14:26 UTC (permalink / raw)
To: Leonard Crestez, Robin Gong
Cc: Aisheng Dong, Fabio Estevam, dl-linux-imx,
linux-arm-kernel@lists.infradead.org, thesven73@gmail.com
In-Reply-To: <VI1PR04MB70235FD928F65235B2252C6CEEB90@VI1PR04MB7023.eurprd04.prod.outlook.com>
On 9/3/19 4:48 PM, Leonard Crestez wrote:
> CAUTION: This Email originated from outside Televic. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 03.09.2019 17:32, Jurgen Lambrecht wrote:
>> On 9/3/19 7:57 AM, Robin Gong wrote:
>>
>>>> And that are the last commits on drivers/dma/imx-sdma.c for my 4.19.x+fslc
>>>> branch. But I have already tried 5.1.x+fslc, and it also got stuck.
>>> Sorry, I can't reproduce your issue on Linux 5.3-rc6 with 'CONFIG_SLOB=y' and
>>> SDMA firmware built in kernel, Could you have a try on our imx6ul-14x14-evk
>>> board with Linux 5.3-rc6 directly(no any patch needed)?
>> This works on our own board (with imx6ul)!
> Something seems to be wrong with the fslc tree, using 5.1.x+fslc at
> latest commit cd1d083333e76e03d16f015c23f1f1b8c8637381 I can reproduce
> the issue on imx6ul-14x14-evk board.
>
> Running without SLOB and builtin firmware it's fine.
>
> I couldn't reproduce with latest 4.19.x+fslc (currently at commit
> 91d5756ab9096bbec256115d1d6b85f5d7139f85), maybe some additional SDMA
> patches were applied which fixed this issue?
My 4.19.x+fslc was a 4.19.56 (cda746ffc).
Now I updated to your version 4.19.66, and it does not hang anymore, but
I get a *kernel panic* (oops) (so with sdma FW and with the SLOB
allocator). Also when I remove earlycon and update the dts not to enable
sdma on the uart, it still panics. Also with our patches on top kernel
panics. To be completely sure, I compiled 4.19.66+fslc (so
91d5756ab9096bbec256115d1d6b85f5d7139f85) with imx_v6_v7_defconfig
(instead of our minimal defconfig) and then it panics half of the time
(see below).
With SLUB, it works. And with SLOB without sdma it also works!
Here the kernel panic log:
[ 0.971298] io scheduler noop registered (default)
[ 1.045927] imx-sdma 20ec000.sdma: loaded firmware 3.5
[ 1.060382] console [ttymxc0] enabled
[ 1.064199] bootconsole [ec_imx6q0] disabled
[ 1.104663] Unable to handle kernel paging request at virtual address
ffffffe8
[ 1.112035] pgd = (ptrval)
[ 1.114772] [ffffffe8] *pgd=9ffff841, *pte=00000000, *ppte=00000000
[ 1.121138] Internal error: Oops: 27 [#1] PREEMPT ARM
[ 1.126212] Modules linked in:
[ 1.129305] CPU: 0 PID: 1 Comm: swapper Not tainted
4.19.66-televic-rail-33.97.1802-00072-g39a835ebea4c #2
[ 1.138979] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 1.145197] PC is at alloc_vmap_area+0x140/0x3ec
[ 1.149836] LR is at 0x1000
[ 1.152650] pc : [<c01cc150>] lr : [<00001000>] psr: 00000053
[ 1.158937] sp : df055cb0 ip : 00009000 fp : ff800000
[ 1.164183] r10: 00000001 r9 : c0a74204 r8 : 00000001
[ 1.169430] r7 : c0a74204 r6 : ffffffff r5 : 00000001 r4 : 00009000
[ 1.175980] r3 : 00000000 r2 : 00000000 r1 : c0a11df0 r0 : e0876000
[ 1.182533] Flags: nzcv IRQs on FIQs off Mode SVC_32 ISA ARM
Segment none
[ 1.189778] Control: 10c53c7d Table: 80004059 DAC: 00000051
[ 1.195546] Process swapper (pid: 1, stack limit = 0x(ptrval))
[ 1.201399] Stack: (0xdf055cb0 to 0xdf056000)
[ 1.205785] 5ca0: e0800000
00000000 e0809000 e0800000
[ 1.213993] 5cc0: 00000000 df2ed640 df2d4d80 b65d4d11 ffffffff
00009000 df2ed5c0 00000022
[ 1.222202] 5ce0: 006080c0 00000001 e0800000 c0a03048 df2d4d80
c01cc490 ffffffff 006080c0
[ 1.230412] 5d00: df2c1980 00008000 ffffffff ffffffff 006080c0
df2d4d80 00000001 c01cd870
[ 1.238621] 5d20: ff800000 ffffffff 006080c0 c0382754 c0a12028
c0382754 ffffffff 00000000
[ 1.246829] 5d40: df2c1940 df2d4d80 00000001 c01cda50 006080c0
0000024f 00000000 ffffffff
[ 1.255038] 5d60: c0382754 00000000 df2c1940 df2ed540 00000100
c01cdb1c ffffffff c0382754
[ 1.263247] 5d80: df2d4d80 c0382754 df2d4d80 df2c1940 00000000
df2d4d90 00000000 c03808d4
[ 1.271457] 5da0: df2c1940 c037f4f0 c037f514 df2ec640 00000000
c037f520 df2c1940 df2d4d80
[ 1.279666] 5dc0: c0a12030 c037d7d4 006000c0 00100000 00000013
c05ee130 00000200 df2c1940
[ 1.287875] 5de0: 00000000 00000000 df2d4d90 00000000 00000001
c0a03048 df2d4d80 c02131cc
[ 1.296082] 5e00: 00000000 c01f5640 00000000 b65d4d11 00000000
00000000 df2d4d80 c0a03048
[ 1.304290] 5e20: 00000001 00000000 df2c194c 00000001 df2d4d80
c02134a8 df2d4e70 00000001
[ 1.312498] 5e40: 00000000 b65d4d11 c09005a4 c01f4bb8 df2d4df8
c02129a4 df2c19b0 b65d4d11
[ 1.320707] 5e60: df2c1980 df2c1940 00000000 c0a03048 00000001
df2c19b0 df2c194c 00000001
[ 1.328915] 5e80: df2d4d80 c037f138 c037d7d4 c037f514 df2c1940
c0a1cd48 00100000 c05fcbcc
[ 1.337124] 5ea0: 0000000d df29f5f0 c09005a4 b65d4d11 df29d740
df2c3cc0 c0a1cd48 c0a1cd48
[ 1.345333] 5ec0: c0a1cd4c 00000000 c0a1cd4c c0a1cd48 c09005a4
c091b158 c091ac58 00000000
[ 1.353542] 5ee0: c0a2b080 00000006 c0a03048 c091b0a8 00000000
c0929830 c0929838 c0102658
[ 1.361751] 5f00: 00000000 00000084 00000084 dfbea400 00000065
c081f5e4 00000084 c013845c
[ 1.369959] 5f20: c081eba8 00000000 c09005a4 00000000 00000006
00000006 00000000 dfbea401
[ 1.378168] 5f40: 00000000 b65d4d11 00000000 b65d4d11 c0934f90
00000006 c0a2b080 00000084
[ 1.386376] 5f60: c0a2b080 c0929838 c09005a4 c0900dbc 00000006
00000006 00000000 c09005a4
[ 1.394584] 5f80: c05fd99c 00000000 c05fd99c 00000000 00000000
00000000 00000000 00000000
[ 1.402792] 5fa0: 00000000 c05fd9a4 00000000 c01010e8 00000000
00000000 00000000 00000000
[ 1.410998] 5fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 1.419205] 5fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 1.427434] [<c01cc150>] (alloc_vmap_area) from [<c01cc490>]
(__get_vm_area_node+0x94/0x168)
[ 1.435917] [<c01cc490>] (__get_vm_area_node) from [<c01cd870>]
(__vmalloc_node_range+0x58/0x1f4)
[ 1.444825] [<c01cd870>] (__vmalloc_node_range) from [<c01cda50>]
(__vmalloc_node+0x44/0x54)
[ 1.453300] [<c01cda50>] (__vmalloc_node) from [<c01cdb1c>]
(vzalloc+0x2c/0x3c)
[ 1.460652] [<c01cdb1c>] (vzalloc) from [<c0382754>]
(check_partition+0x38/0x1d4)
[ 1.468177] [<c0382754>] (check_partition) from [<c03808d4>]
(rescan_partitions+0x78/0x440)
[ 1.476567] [<c03808d4>] (rescan_partitions) from [<c02131cc>]
(__blkdev_get+0x25c/0x414)
[ 1.484779] [<c02131cc>] (__blkdev_get) from [<c02134a8>]
(blkdev_get+0x124/0x3e8)
[ 1.492385] [<c02134a8>] (blkdev_get) from [<c037f138>]
(__device_add_disk+0x404/0x4b8)
[ 1.500432] [<c037f138>] (__device_add_disk) from [<c091b158>]
(brd_init+0xb0/0x170)
[ 1.508218] [<c091b158>] (brd_init) from [<c0102658>]
(do_one_initcall+0x48/0x1a0)
[ 1.515833] [<c0102658>] (do_one_initcall) from [<c0900dbc>]
(kernel_init_freeable+0x100/0x1c8)
[ 1.524579] [<c0900dbc>] (kernel_init_freeable) from [<c05fd9a4>]
(kernel_init+0x8/0x11c)
[ 1.532796] [<c05fd9a4>] (kernel_init) from [<c01010e8>]
(ret_from_fork+0x14/0x2c)
[ 1.540386] Exception stack(0xdf055fb0 to 0xdf055ff8)
[ 1.545463] 5fa0: 00000000
00000000 00000000 00000000
[ 1.553671] 5fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 1.561875] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.568522] Code: e5922018 e59f129c e1520001 0a00002f (e5121018)
[ 1.574733] ---[ end trace abfef683febb0cb6 ]---
[ 1.579384] Kernel panic - not syncing: Fatal exception
[ 1.584640] Rebooting in 180 seconds..
I checked the patches on drivers/dma/imx-sdma.c and "dmaengine:
imx-sdma: fix use-after-free on probe error path"
09593c25b975458025fd4cd15d5861cbaa33683d seems to describe the issue....
but not solving it for me. So that is why I put Sven in CC.
Also with 4.19.56 with our own patches on top, the kernel did not hang,
but panicked. It looks like a timing problem inside the sdma driver.
Because kernel did not crash always, sometimes it did boot. Also now,
but only with 4.19.66+fslc with imx_v6_v7_defconfig it booted the first
time correctly, after a reboot it panicked very late, I even got a login
console, but then it rebooted again, but again good. Here the log:
[ 49.763843] Unable to handle kernel paging request at virtual address
a72e118d
[ 49.772789] pgd = b60d9f54
[ 49.775817] [a72e118d] *pgd=00000000
[ 49.779501] Internal error: Oops: 5 [#1] SMP ARM
[ 49.784152] Modules linked in:
[ 49.787259] CPU: 0 PID: 455 Comm: ntpd Not tainted
4.19.66-00020-g91d5756ab909 #3
[ 49.794770] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 49.800991] PC is at find_entry+0x5c/0xc4
[ 49.805032] LR is at find_entry+0x88/0xc4
[ 49.809073] pc : [<c03090fc>] lr : [<c0309128>] psr: a0070013
[ 49.815365] sp : d96c9d40 ip : e9cb8463 fp : d96c9d74
[ 49.820616] r10: 00000001 r9 : 00000002 r8 : d8864040
[ 49.825870] r7 : d88640bc r6 : c0e70108 r5 : d96c48fc r4 : 0000000b
[ 49.832425] r3 : 0000006e r2 : 00000009 r1 : c0e70108 r0 : ffffffff
[ 49.838982] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment none
[ 49.846146] Control: 10c5387d Table: 996cc06a DAC: 00000051
[ 49.851924] Process ntpd (pid: 455, stack limit = 0x873acf61)
[ 49.857699] Stack: (0xd96c9d40 to 0xd96ca000)
[ 49.862095] 9d40: d96c9d74 d96c9d88 c0ba1030 c1132fb4 0000000b
d8090040 d96c48c0 c1108908
[ 49.870308] 9d60: d90f44d8 00000000 d96c9dbc d96c9d78 c030a94c
c03090ac c02a2d04 d96c48fc
[ 49.878519] 9d80: 00000001 00000000 c0294844 7d9fdb21 d96c9dbc
00000000 d90f0f18 00000000
[ 49.886732] 9da0: d96c9e90 d96c9f50 d96c48c0 d96c48c0 d96c9e8c
d96c9dc0 c0294ff4 c030a8e4
[ 49.894945] 9dc0: d96c9e7c d96c9dd0 c017eb8c c017e028 d96c48c0
00000000 00000000 00000000
[ 49.903157] 9de0: d90f44d8 00000041 00000000 d96c2140 00000004
00000000 00000000 c1748cc0
[ 49.911370] 9e00: 00000000 d96ae4f0 6ca44a47 00000000 dead4ead
ffffffff ffffffff c193441c
[ 49.919581] 9e20: 00000000 00000000 c0e795c8 d96c9e2c d96c9e2c
00000000 dead4ead ffffffff
[ 49.927794] 9e40: ffffffff c193441c 00000000 00000000 c0e795c8
d96c9e2c d96c9e2c 7d9fdb21
[ 49.936006] 9e60: 00000000 00000003 d96c9f50 d96c9e90 c1108908
00000001 d96c8000 00000142
[ 49.944219] 9e80: d96c9f44 d96c9e90 c02966e4 c02942a8 d8f0ad10
d90f0f18 04ff40f7 0000000b
[ 49.952433] 9ea0: d96dd021 60070013 d8e9d3d0 d8ed0960 d90f44d8
00000101 c030ac14 0000005c
[ 49.960645] 9ec0: 00000000 00000000 00000000 d96c9ed0 d96c9ef4
d96c9ee0 c0ba1258 c0184904
[ 49.968856] 9ee0: 00000000 d96acd24 d96c9f34 d96c9ef8 c02a80d4
c0ba123c d96c9f34 00000000
[ 49.977069] 9f00: d96dd000 00000000 00000000 00000002 ffffff9c
ffffff9c d96dd000 7d9fdb21
[ 49.985282] 9f20: d96c8000 00000003 c1108908 ffffff9c d96dd000
c01011e4 d96c9f94 d96c9f48
[ 49.993493] 9f40: c0281ccc c029667c d96ae000 00000001 00000000
00000000 00000004 00000100
[ 50.001704] 9f60: 00000001 7d9fdb21 00000000 00000003 01b9da68
000003e6 00000142 c01011e4
[ 50.009917] 9f80: d96c8000 00000142 d96c9fa4 d96c9f98 c0281dd0
c0281bb4 00000000 d96c9fa8
[ 50.018130] 9fa0: c0101000 c0281dc8 00000003 01b9da68 ffffff9c
b6cd6c68 00000000 00000000
[ 50.026343] 9fc0: 00000003 01b9da68 000003e6 00000142 b6f7c900
0058ead8 bee697bc 0053b50c
[ 50.034555] 9fe0: 00000142 bee696c8 b6c930d5 b6c1a6c6 20070030
ffffff9c 00000000 00000000
[ 50.042753] Backtrace:
[ 50.045258] [<c03090a0>] (find_entry) from [<c030a94c>]
(proc_sys_lookup+0x74/0x180)
[ 50.053042] r10:00000000 r9:d90f44d8 r8:c1108908 r7:d96c48c0
r6:d8090040 r5:0000000b
[ 50.060897] r4:c1132fb4
[ 50.063472] [<c030a8d8>] (proc_sys_lookup) from [<c0294ff4>]
(path_openat+0xd58/0x108c)
[ 50.071511] r10:d96c48c0 r9:d96c48c0 r8:d96c9f50 r7:d96c9e90
r6:00000000 r5:d90f0f18
[ 50.079366] r4:00000000
[ 50.081939] [<c029429c>] (path_openat) from [<c02966e4>]
(do_filp_open+0x74/0xe4)
[ 50.089459] r10:00000142 r9:d96c8000 r8:00000001 r7:c1108908
r6:d96c9e90 r5:d96c9f50
[ 50.097311] r4:00000003
[ 50.099884] [<c0296670>] (do_filp_open) from [<c0281ccc>]
(do_sys_open+0x124/0x1ec)
[ 50.107574] r8:c01011e4 r7:d96dd000 r6:ffffff9c r5:c1108908 r4:00000003
[ 50.114311] [<c0281ba8>] (do_sys_open) from [<c0281dd0>]
(sys_openat+0x14/0x18)
[ 50.121656] r10:00000142 r9:d96c8000 r8:c01011e4 r7:00000142
r6:000003e6 r5:01b9da68
[ 50.129511] r4:00000003
[ 50.132083] [<c0281dbc>] (sys_openat) from [<c0101000>]
(ret_fast_syscall+0x0/0x28)
[ 50.139766] Exception stack(0xd96c9fa8 to 0xd96c9ff0)
[ 50.144851] 9fa0: 00000003 01b9da68 ffffff9c
b6cd6c68 00000000 00000000
[ 50.153063] 9fc0: 00000003 01b9da68 000003e6 00000142 b6f7c900
0058ead8 bee697bc 0053b50c
[ 50.161269] 9fe0: 00000142 bee696c8 b6c930d5 b6c1a6c6
[ 50.166357] Code: e598a000 e06cc007 e1a0c24c e08cc18c (e79a610c)
[ 50.172754] ---[ end trace 9e22ce3f534d2b3d ]---
Then I logged into the serial console, rebooted, and again a kernel
panic, but much sooner :
[ 3.711085] imx-sdma 20ec000.sdma: loaded firmware 3.5
[ 3.739709] console [ttymxc0] enabled
[ 3.743626] bootconsole [ec_imx6q0] disabled
[ 4.078675] brd: module loaded
[ 4.327831] loop: module loaded
[ 4.343852] at24 0-0050: 256 byte 24c02 EEPROM, writable, 8 bytes/write
[ 4.434753] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
[ 4.441437] nand: Micron MT29F4G08ABADAH4
[ 4.445582] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[ 4.466637] Bad block table not found for chip 0
[ 4.474598] Bad block table not found for chip 0
[ 4.479535] Scanning device for bad blocks
[ 7.108753] Bad block table written to 0x00001ffe0000, version 0x01
[ 7.118100] Bad block table written to 0x00001ffc0000, version 0x01
[ 7.125068] 1 cmdlinepart partitions found on MTD device gpmi-nand
[ 7.131616] Creating 1 MTD partitions on "gpmi-nand":
[ 7.137028] 0x000000000000-0x000020000000 : "nandflash"
[ 7.166797] random: crng init done
[ 8.081299] gpmi-nand 1806000.gpmi-nand: driver registered.
[ 8.089377] Unable to handle kernel NULL pointer dereference at
virtual address 00000070
[ 8.098055] pgd = a7175e07
[ 8.100896] [00000070] *pgd=00000000
[ 8.104636] Internal error: Oops: 5 [#1] SMP ARM
[ 8.109316] Modules linked in:
[ 8.112459] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.19.66-00020-g91d5756ab909 #3
[ 8.120255] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 8.126506] PC is at strcmp+0x18/0x44
[ 8.130236] LR is at kset_find_obj+0x44/0x8c
[ 8.134568] pc : [<c0b9358c>] lr : [<c0b88054>] psr: 20000013
[ 8.140887] sp : d80a9e50 ip : d80a9e60 fp : d80a9e5c
[ 8.146165] r10: 00000000 r9 : c1108930 r8 : c1108908
[ 8.151444] r7 : d8139e88 r6 : c0edbd04 r5 : d8139e80 r4 : c0eba704
[ 8.158023] r3 : 00000070 r2 : 00000066 r1 : c0edbd04 r0 : 00000070
[ 8.164608] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment none
[ 8.171797] Control: 10c5387d Table: 8000406a DAC: 00000051
[ 8.177602] Process swapper/0 (pid: 1, stack limit = 0x0e667d51)
[ 8.183664] Stack: (0xd80a9e50 to 0xd80aa000)
[ 8.188084] 9e40: d80a9e7c
d80a9e60 c0b88054 c0b93580
[ 8.196328] 9e60: c117f87c c105f984 c10a7dc4 c11d7ac0 d80a9e94
d80a9e80 c0612c60 c0b8801c
[ 8.204570] 9e80: c1174e28 c117f87c d80a9eac d80a9e98 c0612cf0
c0612c50 c11d6970 c105f984
[ 8.212813] 9ea0: d80a9ebc d80a9eb0 c0613d68 c0612c88 d80a9ecc
d80a9ec0 c105f99c c0613d3c
[ 8.221056] 9ec0: d80a9f4c d80a9ed0 c01031f4 c105f990 00000000
c0f8f438 000000f7 dffffb00
[ 8.229298] 9ee0: d80a9f4c d80a9ef0 c014f5a8 c1000710 00000000
00000006 d8092000 00000000
[ 8.237542] 9f00: 60000053 c11d6970 c11dc900 c11d7ac0 d80a9f34
d80a9f20 c017bf04 7d9fdb21
[ 8.245785] 9f20: c115d3c4 00000006 c1090850 c10a7dc4 c11dc900
c11d7ac0 d80a8000 00000000
[ 8.254027] 9f40: d80a9f94 d80a9f50 c10011d4 c0103178 00000006
00000006 00000000 c1000704
[ 8.262270] 9f60: c0ba1310 000000f7 d8092000 00000000 c0b99d14
00000000 00000000 00000000
[ 8.270511] 9f80: 00000000 00000000 d80a9fac d80a9f98 c0b99d24
c1000f24 d8092000 00000000
[ 8.278753] 9fa0: 00000000 d80a9fb0 c01010b4 c0b99d20 00000000
00000000 00000000 00000000
[ 8.286993] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 8.295233] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 8.303456] Backtrace:
[ 8.305993] [<c0b93574>] (strcmp) from [<c0b88054>]
(kset_find_obj+0x44/0x8c)
[ 8.313208] [<c0b88010>] (kset_find_obj) from [<c0612c60>]
(driver_find+0x1c/0x38)
[ 8.320846] r7:c11d7ac0 r6:c10a7dc4 r5:c105f984 r4:c117f87c
[ 8.326575] [<c0612c44>] (driver_find) from [<c0612cf0>]
(driver_register+0x74/0x11c)
[ 8.334465] r4:c117f87c r3:c1174e28
[ 8.338114] [<c0612c7c>] (driver_register) from [<c0613d68>]
(__platform_driver_register+0x38/0x4c)
[ 8.347215] r5:c105f984 r4:c11d6970
[ 8.350865] [<c0613d30>] (__platform_driver_register) from
[<c105f99c>] (fsl_qspi_driver_init+0x18/0x20)
[ 8.360415] [<c105f984>] (fsl_qspi_driver_init) from [<c01031f4>]
(do_one_initcall+0x88/0x31c)
[ 8.369103] [<c010316c>] (do_one_initcall) from [<c10011d4>]
(kernel_init_freeable+0x2bc/0x3e8)
[ 8.377871] r10:00000000 r9:d80a8000 r8:c11d7ac0 r7:c11dc900
r6:c10a7dc4 r5:c1090850
[ 8.385750] r4:00000006
[ 8.388356] [<c1000f18>] (kernel_init_freeable) from [<c0b99d24>]
(kernel_init+0x10/0x120)
[ 8.396688] r10:00000000 r9:00000000 r8:00000000 r7:00000000
r6:00000000 r5:c0b99d14
[ 8.404567] r4:00000000
[ 8.407169] [<c0b99d14>] (kernel_init) from [<c01010b4>]
(ret_from_fork+0x14/0x20)
[ 8.414792] Exception stack(0xd80a9fb0 to 0xd80a9ff8)
[ 8.419902] 9fa0: 00000000
00000000 00000000 00000000
[ 8.428143] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 8.436379] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 8.443049] r4:00000000 r3:d8092000
[ 8.446690] Code: e24cb004 ea000001 e3530000 0a000008 (e4d03001)
[ 8.453044] ---[ end trace b6f2a017d259fade ]---
[ 8.457941] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 8.457941]
[ 8.467193] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b
[ 8.467193] ]---
Kind regards,
Jürgen
>
> --
> Regards,
> Leonard
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From: Walter Wu @ 2019-09-04 14:24 UTC (permalink / raw)
To: Vlastimil Babka
Cc: wsd_upstream, Arnd Bergmann, linux-mm, linux-mediatek,
linux-kernel, kasan-dev, Martin Schwidefsky, Alexander Potapenko,
linux-arm-kernel, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <7998e8f1-e5e2-da84-ea1f-33e696015dce@suse.cz>
On Wed, 2019-09-04 at 16:13 +0200, Vlastimil Babka wrote:
> On 9/4/19 4:06 PM, Walter Wu wrote:
> > On Wed, 2019-09-04 at 14:49 +0200, Vlastimil Babka wrote:
> >> On 9/4/19 8:51 AM, Walter Wu wrote:
> >> > This patch is KASAN report adds the alloc/free stacks for page allocator
> >> > in order to help programmer to see memory corruption caused by page.
> >> >
> >> > By default, KASAN doesn't record alloc/free stack for page allocator.
> >> > It is difficult to fix up page use-after-free issue.
> >> >
> >> > This feature depends on page owner to record the last stack of pages.
> >> > It is very helpful for solving the page use-after-free or out-of-bound.
> >> >
> >> > KASAN report will show the last stack of page, it may be:
> >> > a) If page is in-use state, then it prints alloc stack.
> >> > It is useful to fix up page out-of-bound issue.
> >>
> >> I expect this will conflict both in syntax and semantics with my series [1] that
> >> adds the freeing stack to page_owner when used together with debug_pagealloc,
> >> and it's now in mmotm. Glad others see the need as well :) Perhaps you could
> >> review the series, see if it fulfils your usecase (AFAICS the series should be a
> >> superset, by storing both stacks at once), and perhaps either make KASAN enable
> >> debug_pagealloc, or turn KASAN into an alternative enabler of the functionality
> >> there?
> >>
> >> Thanks, Vlastimil
> >>
> >> [1] https://lore.kernel.org/linux-mm/20190820131828.22684-1-vbabka@suse.cz/t/#u
> >>
> > Thanks your information.
> > We focus on the smartphone, so it doesn't enable
> > CONFIG_TRANSPARENT_HUGEPAGE, Is it invalid for our usecase?
>
> The THP fix is not required for the rest of the series, it was even merged to
> mainline separately.
>
> > And It looks like something is different, because we only need last
> > stack of page, so it can decrease memory overhead.
>
> That would save you depot_stack_handle_t (which is u32) per page. I guess that's
> nothing compared to KASAN overhead?
>
If we can use less memory, we can achieve what we want. Why not?
Thanks.
Walter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 01/10] KVM: arm64: Document PV-time interface
From: Andrew Jones @ 2019-09-04 14:22 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, Radim Krčmář, kvm, Suzuki K Pouloze,
Marc Zyngier, linux-doc, Russell King, linux-kernel, James Morse,
linux-arm-kernel, Catalin Marinas, Paolo Bonzini, Will Deacon,
kvmarm, Julien Thierry
In-Reply-To: <118ceeea-5501-05b6-7232-e66a175d5fae@arm.com>
On Wed, Sep 04, 2019 at 02:55:15PM +0100, Steven Price wrote:
> On 02/09/2019 13:52, Andrew Jones wrote:
> > On Fri, Aug 30, 2019 at 04:25:08PM +0100, Steven Price wrote:
> >> On 30/08/2019 15:47, Andrew Jones wrote:
> >>> On Fri, Aug 30, 2019 at 09:42:46AM +0100, Steven Price wrote:
> [...]
> >>>> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> >>>> + PV-time feature is supported by the hypervisor.
> >>>> +
> >>>> +PV_TIME_ST
> >>>> + Function ID: (uint32) : 0xC5000022
> >>>> + Return value: (int64) : IPA of the stolen time data structure for this
> >>>> + VCPU. On failure:
> >>>> + NOT_SUPPORTED (-1)
> >>>> +
> >>>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> >>>> +with inner and outer write back caching attributes, in the inner shareable
> >>>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> >>>> +meaningfully filled by the hypervisor (see structure below).
> >>>> +
> >>>> +PV_TIME_ST returns the structure for the calling VCPU.
> >>>> +
> >>>> +Stolen Time
> >>>> +-----------
> >>>> +
> >>>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> >>>> +
> >>>> + Field | Byte Length | Byte Offset | Description
> >>>> + ----------- | ----------- | ----------- | --------------------------
> >>>> + Revision | 4 | 0 | Must be 0 for version 0.1
> >>>> + Attributes | 4 | 4 | Must be 0
> >>>
> >>> The above fields don't appear to be exposed to userspace in anyway. How
> >>> will we handle migration from one KVM with one version of the structure
> >>> to another?
> >>
> >> Interesting question. User space does have access to them now it is
> >> providing the memory, but it's not exactly an easy method. In particular
> >> user space has no (simple) way of probing the kernel's supported version.
> >>
> >> I guess one solution would be to add an extra attribute on the VCPU
> >> which would provide the revision information. The current kernel would
> >> then reject any revision other than 0, but this could then be extended
> >> to support other revision numbers in the future.
> >>
> >> Although there's some logic in saying we could add the extra attribute
> >> when(/if) there is a new version. Future kernels would then be expected
> >> to use the current version unless user space explicitly set the new
> >> attribute.
> >>
> >> Do you feel this is something that needs to be addressed now, or can it
> >> be deferred until another version is proposed?
> >
> > Assuming we'll want userspace to have the option of choosing version=0,
> > and that we're fine with version=0 being the implicit choice, when nothing
> > is selected, then I guess it can be left as is for now. If, OTOH, we just
> > want migration to fail when attempting to migrate to another host with
> > an incompatible stolen-time structure (i.e. version=0 is not selectable
> > on hosts that implement later versions), then we should expose the version
> > in some way now. Perhaps a VCPU's "PV config" should be described in a
> > set of pseudo registers?
>
> I wouldn't have thought making migration fail if/when the host upgrades
> to a new version would be particularly helpful - we'd want to provide
> backwards compatibility. In particular for the suspend/resume case (I
> want to be able to save my VM to disk, upgrade the host kernel and then
> resume the VM).
>
> The only potential issue I see is the implicit "version=0 if not
> specified". That seems solvable by rejecting setting the stolen time
> base address if no version has been specified and the host kernel
> doesn't support version=0.
I think that's the same failure I was trying avoid by failing the
migration instead. Maybe it's equivalent to fail at this vcpu-ioctl
time though?
>
> >>
> >>>> + Stolen time | 8 | 8 | Stolen time in unsigned
> >>>> + | | | nanoseconds indicating how
> >>>> + | | | much time this VCPU thread
> >>>> + | | | was involuntarily not
> >>>> + | | | running on a physical CPU.
> >>>> +
> >>>> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
> >>>> +will be present within a reserved region of the normal memory given to the
> >>>> +guest. The guest should not attempt to write into this memory. There is a
> >>>> +structure per VCPU of the guest.
> >>>
> >>> Should we provide a recommendation as to how that reserved memory is
> >>> provided? One memslot divided into NR_VCPUS subregions? Should the
> >>> reserved region be described to the guest kernel with DT/ACPI? Or
> >>> should userspace ensure the region is not within any DT/ACPI described
> >>> regions?
> >>
> >> I'm open to providing a recommendation, but I'm not entirely sure I know
> >> enough here to provide one.
> >>
> >> There is an obvious efficiency argument for minimizing memslots with the
> >> current code. But if someone has a reason for using multiple memslots
> >> then that's probably a good argument for implementing a memslot-caching
> >> kvm_put_user() rather than to be dis-recommended.
> >
> > Actually even if a single memslot is used for all the PV structures for
> > all VCPUs, but it's separate from the slot(s) used for main memory, then
> > we'll likely see performance issues with memslot searches (even though
> > it's a binary search). This is because memslots already have caching. The
> > last used slot is stored in the memslots' lru_slot member (the "lru" name
> > is confusing, but it means "last used" somehow). This means we could get
> > thrashing on that slot cache if we're searching for the PV structure
> > memslot on each vcpu load after searching for the main memory slot on each
> > page fault.
>
> True - a dedicated memslot for stolen time wouldn't be great if a VM is
> needing to fault pages (which would obviously be in a different
> memslot). I don't have a good idea of the overhead of missing in the
> lru_slot cache. The main reason I stopped using a dedicated cache was
> because I discovered that my initial implementation using
> kvm_write_guest_offset_cached() (which wasn't single-copy atomic safe)
> was actually failing to use the cache because the buffer crossed a page
> boundary (see __kvm_gfn_to_hva_cache_init()). So switching away from the
> "_cached" variant was actually avoiding the extra walks of the memslots.
>
> I can look at reintroducing the caching for kvm_put_guest().
>
> >>
> >> My assumption (and testing) has been with a single memslot divided into
> >> NR_VCPUS (or more accurately the number of VCPUs in the VM) subregions.
> >>
> >> For testing DT I've tested both methods: an explicit reserved region or
> >> just ensuring it's not in any DT described region. Both seem reasonable,
> >> but it might be easier to integrate into existing migration mechanisms
> >> if it's simply a reserved region (then the memory block of the guest is
> >> just as it always was).
> >>
> >> For ACPI the situation should be similar, but my testing has been with DT.
> >
> > I also can't think of any reason why we'd have to describe it in DT/ACPI,
> > but I get this feeling that if we don't, then we'll hit some issue that
> > will make us wish we had...
>
> Without knowing why we need it it's hard to justify what should go in
> the bindings. But the idea of having the hypercalls is that the
> description is returned via hypercalls rather than explicitly in
> DT/ACPI. In theory we wouldn't need the hypercalls if it was fully
> described in DT/ACPI.
>
Fair enough
Thanks,
drew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH 0/5] Add bluetooth support for Orange Pi 3
From: Marcel Holtmann @ 2019-09-04 14:19 UTC (permalink / raw)
To: Maxime Ripard
Cc: megous, Mark Rutland, Johan Hedberg, devicetree, netdev,
linux-kernel, linux-bluetooth, Chen-Yu Tsai, Rob Herring,
David S. Miller, linux-arm-kernel
In-Reply-To: <20190830132034.u65arlv7umh64lx6@flea>
Hi Maxime,
>>>>> (Resend to add missing lists, sorry for the noise.)
>>>>>
>>>>> This series implements bluetooth support for Xunlong Orange Pi 3 board.
>>>>>
>>>>> The board uses AP6256 WiFi/BT 5.0 chip.
>>>>>
>>>>> Summary of changes:
>>>>>
>>>>> - add more delay to let initialize the chip
>>>>> - let the kernel detect firmware file path
>>>>> - add new compatible and update dt-bindings
>>>>> - update Orange Pi 3 / H6 DTS
>>>>>
>>>>> Please take a look.
>>>>>
>>>>> thank you and regards,
>>>>> Ondrej Jirman
>>>>>
>>>>> Ondrej Jirman (5):
>>>>> dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
>>>>> bluetooth: bcm: Add support for loading firmware for BCM4345C5
>>>>> bluetooth: hci_bcm: Give more time to come out of reset
>>>>> arm64: dts: allwinner: h6: Add pin configs for uart1
>>>>> arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
>>>>>
>>>>> .../bindings/net/broadcom-bluetooth.txt | 1 +
>>>>> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
>>>>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
>>>>> drivers/bluetooth/btbcm.c | 3 +++
>>>>> drivers/bluetooth/hci_bcm.c | 3 ++-
>>>>> 5 files changed, 35 insertions(+), 1 deletion(-)
>>>>
>>>> all 5 patches have been applied to bluetooth-next tree.
>>>
>>> The DTS patches (last 2) should go through the arm-soc tree, can you
>>> drop them?
>>
>> why is that? We have included DTS changes for Bluetooth devices
>> directly all the time. What is different with this hardware?
>
> I guess some maintainers are more relaxed with it than we are then,
> but for the why, well, it's the usual reasons, the most immediate one
> being that it reduces to a minimum the conflicts between trees.
>
> The other being that it's not really usual to merge patches supposed
> to be handled by another maintainer without (at least) his
> consent. I'm pretty sure you would have asked the same request if I
> would have merged the bluetooth patches through my tree without
> notice.
I took the two DTS patches out now and let the submitter deal with getting these merged.
Regards
Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Kirill A. Shutemov @ 2019-09-04 14:19 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, linux-arm-kernel, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Dan Williams,
Vlastimil Babka, Sri Krishna chowdary, Ard Biesheuvel,
Greg Kroah-Hartman, linux-mips, Ralf Baechle, linux-kernel,
Paul Burton, Mike Rapoport, Vineet Gupta, Martin Schwidefsky,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com>
On Tue, Sep 03, 2019 at 01:31:46PM +0530, Anshuman Khandual wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> page table helpers or addition of new ones.
>
> Test page table and memory pages creating it's entries at various level are
> all allocated from system memory with required alignments. If memory pages
> with required size and alignment could not be allocated, then all depending
> individual tests are skipped.
See my comments below.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steven Price <Steven.Price@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sri Krishna chowdary <schowdary@nvidia.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: James Hogan <jhogan@kernel.org>
> Cc: Paul Burton <paul.burton@mips.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-ia64@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> mm/Kconfig.debug | 14 ++
> mm/Makefile | 1 +
> mm/arch_pgtable_test.c | 425 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 440 insertions(+)
> create mode 100644 mm/arch_pgtable_test.c
>
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index 327b3ebf23bf..ce9c397f7b07 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -117,3 +117,17 @@ config DEBUG_RODATA_TEST
> depends on STRICT_KERNEL_RWX
> ---help---
> This option enables a testcase for the setting rodata read-only.
> +
> +config DEBUG_ARCH_PGTABLE_TEST
> + bool "Test arch page table helpers for semantics compliance"
> + depends on MMU
> + depends on DEBUG_KERNEL
> + help
> + This options provides a kernel module which can be used to test
> + architecture page table helper functions on various platform in
> + verifying if they comply with expected generic MM semantics. This
> + will help architectures code in making sure that any changes or
> + new additions of these helpers will still conform to generic MM
> + expected semantics.
> +
> + If unsure, say N.
> diff --git a/mm/Makefile b/mm/Makefile
> index d996846697ef..bb572c5aa8c5 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -86,6 +86,7 @@ obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
> obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
> obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
> obj-$(CONFIG_DEBUG_RODATA_TEST) += rodata_test.o
> +obj-$(CONFIG_DEBUG_ARCH_PGTABLE_TEST) += arch_pgtable_test.o
> obj-$(CONFIG_PAGE_OWNER) += page_owner.o
> obj-$(CONFIG_CLEANCACHE) += cleancache.o
> obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
> new file mode 100644
> index 000000000000..f15be8a73723
> --- /dev/null
> +++ b/mm/arch_pgtable_test.c
> @@ -0,0 +1,425 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * This kernel module validates architecture page table helpers &
> + * accessors and helps in verifying their continued compliance with
> + * generic MM semantics.
> + *
> + * Copyright (C) 2019 ARM Ltd.
> + *
> + * Author: Anshuman Khandual <anshuman.khandual@arm.com>
> + */
> +#define pr_fmt(fmt) "arch_pgtable_test: %s " fmt, __func__
> +
> +#include <linux/kernel.h>
> +#include <linux/hugetlb.h>
> +#include <linux/mm.h>
> +#include <linux/mman.h>
> +#include <linux/mm_types.h>
> +#include <linux/module.h>
> +#include <linux/printk.h>
> +#include <linux/swap.h>
> +#include <linux/swapops.h>
> +#include <linux/pfn_t.h>
> +#include <linux/gfp.h>
> +#include <linux/spinlock.h>
> +#include <linux/sched/mm.h>
> +#include <asm/pgalloc.h>
> +#include <asm/pgtable.h>
> +
> +/*
> + * Basic operations
> + *
> + * mkold(entry) = An old and not a young entry
> + * mkyoung(entry) = A young and not an old entry
> + * mkdirty(entry) = A dirty and not a clean entry
> + * mkclean(entry) = A clean and not a dirty entry
> + * mkwrite(entry) = A write and not a write protected entry
> + * wrprotect(entry) = A write protected and not a write entry
> + * pxx_bad(entry) = A mapped and non-table entry
> + * pxx_same(entry1, entry2) = Both entries hold the exact same value
> + */
> +#define VADDR_TEST (PGDIR_SIZE + PUD_SIZE + PMD_SIZE + PAGE_SIZE)
What is special about this address? How do you know if it is not occupied
yet?
> +#define VMA_TEST_FLAGS (VM_READ|VM_WRITE|VM_EXEC)
> +#define RANDOM_NZVALUE (0xbe)
> +
> +static bool pud_aligned;
> +static bool pmd_aligned;
> +
> +extern struct mm_struct *mm_alloc(void);
> +
> +static void pte_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pte_t pte = mk_pte(page, prot);
> +
> + WARN_ON(!pte_same(pte, pte));
> + WARN_ON(!pte_young(pte_mkyoung(pte)));
> + WARN_ON(!pte_dirty(pte_mkdirty(pte)));
> + WARN_ON(!pte_write(pte_mkwrite(pte)));
> + WARN_ON(pte_young(pte_mkold(pte)));
> + WARN_ON(pte_dirty(pte_mkclean(pte)));
> + WARN_ON(pte_write(pte_wrprotect(pte)));
> +}
> +
> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
> +static void pmd_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pmd_t pmd;
> +
> + /*
> + * Memory block here must be PMD_SIZE aligned. Abort this
> + * test in case we could not allocate such a memory block.
> + */
> + if (!pmd_aligned) {
> + pr_warn("Could not proceed with PMD tests\n");
> + return;
> + }
> +
> + pmd = mk_pmd(page, prot);
> + WARN_ON(!pmd_same(pmd, pmd));
> + WARN_ON(!pmd_young(pmd_mkyoung(pmd)));
> + WARN_ON(!pmd_dirty(pmd_mkdirty(pmd)));
> + WARN_ON(!pmd_write(pmd_mkwrite(pmd)));
> + WARN_ON(pmd_young(pmd_mkold(pmd)));
> + WARN_ON(pmd_dirty(pmd_mkclean(pmd)));
> + WARN_ON(pmd_write(pmd_wrprotect(pmd)));
> + /*
> + * A huge page does not point to next level page table
> + * entry. Hence this must qualify as pmd_bad().
> + */
> + WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
> +}
> +#else
> +static void pmd_basic_tests(struct page *page, pgprot_t prot) { }
> +#endif
> +
> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> +static void pud_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pud_t pud;
> +
> + /*
> + * Memory block here must be PUD_SIZE aligned. Abort this
> + * test in case we could not allocate such a memory block.
> + */
> + if (!pud_aligned) {
> + pr_warn("Could not proceed with PUD tests\n");
> + return;
> + }
> +
> + pud = pfn_pud(page_to_pfn(page), prot);
> + WARN_ON(!pud_same(pud, pud));
> + WARN_ON(!pud_young(pud_mkyoung(pud)));
> + WARN_ON(!pud_write(pud_mkwrite(pud)));
> + WARN_ON(pud_write(pud_wrprotect(pud)));
> + WARN_ON(pud_young(pud_mkold(pud)));
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> + /*
> + * A huge page does not point to next level page table
> + * entry. Hence this must qualify as pud_bad().
> + */
> + WARN_ON(!pud_bad(pud_mkhuge(pud)));
> +#endif
> +}
> +#else
> +static void pud_basic_tests(struct page *page, pgprot_t prot) { }
> +#endif
> +
> +static void p4d_basic_tests(struct page *page, pgprot_t prot)
> +{
> + p4d_t p4d;
> +
> + memset(&p4d, RANDOM_NZVALUE, sizeof(p4d_t));
> + WARN_ON(!p4d_same(p4d, p4d));
> +}
> +
> +static void pgd_basic_tests(struct page *page, pgprot_t prot)
> +{
> + pgd_t pgd;
> +
> + memset(&pgd, RANDOM_NZVALUE, sizeof(pgd_t));
> + WARN_ON(!pgd_same(pgd, pgd));
> +}
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> +static void pud_clear_tests(pud_t *pudp)
> +{
> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
> + pud_clear(pudp);
> + WARN_ON(!pud_none(READ_ONCE(*pudp)));
> +}
> +
> +static void pud_populate_tests(struct mm_struct *mm, pud_t *pudp, pmd_t *pmdp)
> +{
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pud_bad().
> + */
> + pmd_clear(pmdp);
> + pud_clear(pudp);
> + pud_populate(mm, pudp, pmdp);
> + WARN_ON(pud_bad(READ_ONCE(*pudp)));
> +}
> +#else
> +static void pud_clear_tests(pud_t *pudp) { }
> +static void pud_populate_tests(struct mm_struct *mm, pud_t *pudp, pmd_t *pmdp)
> +{
> +}
> +#endif
> +
> +#if !defined(__PAGETABLE_PUD_FOLDED) && !defined(__ARCH_HAS_5LEVEL_HACK)
> +static void p4d_clear_tests(p4d_t *p4dp)
> +{
> + memset(p4dp, RANDOM_NZVALUE, sizeof(p4d_t));
> + p4d_clear(p4dp);
> + WARN_ON(!p4d_none(READ_ONCE(*p4dp)));
> +}
> +
> +static void p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp, pud_t *pudp)
> +{
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as p4d_bad().
> + */
> + pud_clear(pudp);
> + p4d_clear(p4dp);
> + p4d_populate(mm, p4dp, pudp);
> + WARN_ON(p4d_bad(READ_ONCE(*p4dp)));
> +}
> +#else
> +static void p4d_clear_tests(p4d_t *p4dp) { }
> +static void p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp, pud_t *pudp)
> +{
> +}
> +#endif
> +
> +#ifndef __PAGETABLE_P4D_FOLDED
> +static void pgd_clear_tests(pgd_t *pgdp)
> +{
> + memset(pgdp, RANDOM_NZVALUE, sizeof(pgd_t));
> + pgd_clear(pgdp);
> + WARN_ON(!pgd_none(READ_ONCE(*pgdp)));
> +}
> +
> +static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
> +{
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pgd_bad().
> + */
> + p4d_clear(p4dp);
> + pgd_clear(pgdp);
> + pgd_populate(mm, pgdp, p4dp);
> + WARN_ON(pgd_bad(READ_ONCE(*pgdp)));
> +}
> +#else
> +static void pgd_clear_tests(pgd_t *pgdp) { }
> +static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
> +{
> +}
> +#endif
This will not work if p4d is folded at runtime. Like for x86-64 and s390.
Here's the fixup. It should work for both x86-64 and s390, but I only
tested on x86-64:
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 52e5f5f2240d..b882792a3999 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -40,6 +40,8 @@ static inline bool pgtable_l5_enabled(void)
#define pgtable_l5_enabled() 0
#endif /* CONFIG_X86_5LEVEL */
+#define mm_p4d_folded(mm) (!pgtable_l5_enabled())
+
extern unsigned int pgdir_shift;
extern unsigned int ptrs_per_p4d;
diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
index f15be8a73723..206fe3334a28 100644
--- a/mm/arch_pgtable_test.c
+++ b/mm/arch_pgtable_test.c
@@ -193,9 +193,11 @@ static void p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp, pud_t *pudp)
}
#endif
-#ifndef __PAGETABLE_P4D_FOLDED
static void pgd_clear_tests(pgd_t *pgdp)
{
+ if (mm_p4d_folded(mm))
+ return;
+
memset(pgdp, RANDOM_NZVALUE, sizeof(pgd_t));
pgd_clear(pgdp);
WARN_ON(!pgd_none(READ_ONCE(*pgdp)));
@@ -203,6 +205,9 @@ static void pgd_clear_tests(pgd_t *pgdp)
static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
{
+ if (mm_p4d_folded(mm))
+ return;
+
/*
* This entry points to next level page table page.
* Hence this must not qualify as pgd_bad().
@@ -212,12 +217,6 @@ static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
pgd_populate(mm, pgdp, p4dp);
WARN_ON(pgd_bad(READ_ONCE(*pgdp)));
}
-#else
-static void pgd_clear_tests(pgd_t *pgdp) { }
-static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
-{
-}
-#endif
static void pte_clear_tests(pte_t *ptep)
{
> +
> +static void pte_clear_tests(pte_t *ptep)
> +{
> + memset(ptep, RANDOM_NZVALUE, sizeof(pte_t));
> + pte_clear(NULL, 0, ptep);
> + WARN_ON(!pte_none(READ_ONCE(*ptep)));
> +}
> +
> +static void pmd_clear_tests(pmd_t *pmdp)
> +{
> + memset(pmdp, RANDOM_NZVALUE, sizeof(pmd_t));
> + pmd_clear(pmdp);
> + WARN_ON(!pmd_none(READ_ONCE(*pmdp)));
> +}
> +
> +static void pmd_populate_tests(struct mm_struct *mm, pmd_t *pmdp,
> + pgtable_t pgtable)
> +{
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pmd_bad().
> + */
> + pmd_clear(pmdp);
> + pmd_populate(mm, pmdp, pgtable);
> + WARN_ON(pmd_bad(READ_ONCE(*pmdp)));
> +}
> +
> +static bool pfn_range_valid(struct zone *z, unsigned long start_pfn,
> + unsigned long nr_pages)
> +{
> + unsigned long i, end_pfn = start_pfn + nr_pages;
> + struct page *page;
> +
> + for (i = start_pfn; i < end_pfn; i++) {
> + if (!pfn_valid(i))
> + return false;
> +
> + page = pfn_to_page(i);
> +
> + if (page_zone(page) != z)
> + return false;
> +
> + if (PageReserved(page))
> + return false;
> +
> + if (page_count(page) > 0)
> + return false;
> +
> + if (PageHuge(page))
> + return false;
> + }
> + return true;
> +}
> +
> +static struct page *alloc_gigantic_page(nodemask_t *nodemask,
> + int nid, gfp_t gfp_mask, int order)
> +{
> + struct zonelist *zonelist;
> + struct zone *zone;
> + struct zoneref *z;
> + enum zone_type zonesel;
> + unsigned long ret, pfn, flags, nr_pages;
> +
> + nr_pages = 1UL << order;
> + zonesel = gfp_zone(gfp_mask);
> + zonelist = node_zonelist(nid, gfp_mask);
> + for_each_zone_zonelist_nodemask(zone, z, zonelist, zonesel, nodemask) {
> + spin_lock_irqsave(&zone->lock, flags);
> + pfn = ALIGN(zone->zone_start_pfn, nr_pages);
> + while (zone_spans_pfn(zone, pfn + nr_pages - 1)) {
> + if (pfn_range_valid(zone, pfn, nr_pages)) {
> + spin_unlock_irqrestore(&zone->lock, flags);
> + ret = alloc_contig_range(pfn, pfn + nr_pages,
> + MIGRATE_MOVABLE,
> + gfp_mask);
> + if (!ret)
> + return pfn_to_page(pfn);
> + spin_lock_irqsave(&zone->lock, flags);
> + }
> + pfn += nr_pages;
> + }
> + spin_unlock_irqrestore(&zone->lock, flags);
> + }
> + return NULL;
> +}
> +
> +static struct page *alloc_mapped_page(void)
> +{
> + gfp_t gfp_mask = GFP_KERNEL | __GFP_ZERO;
> + struct page *page = NULL;
> +
> + page = alloc_gigantic_page(&node_states[N_MEMORY], first_memory_node,
> + gfp_mask, get_order(PUD_SIZE));
> + if (page) {
> + pud_aligned = true;
> + pmd_aligned = true;
> + return page;
> + }
> +
> + page = alloc_pages(gfp_mask, get_order(PMD_SIZE));
> + if (page) {
> + pmd_aligned = true;
> + return page;
> + }
> + return alloc_page(gfp_mask);
> +}
> +
> +static void free_mapped_page(struct page *page)
> +{
> + if (pud_aligned) {
> + unsigned long pfn = page_to_pfn(page);
> +
> + free_contig_range(pfn, 1ULL << get_order(PUD_SIZE));
> + return;
> + }
> +
> + if (pmd_aligned) {
> + int order = get_order(PMD_SIZE);
> +
> + free_pages((unsigned long)page_address(page), order);
> + return;
> + }
> + free_page((unsigned long)page_address(page));
> +}
> +
> +static int __init arch_pgtable_tests_init(void)
> +{
> + struct mm_struct *mm;
> + struct page *page;
> + pgd_t *pgdp;
> + p4d_t *p4dp, *saved_p4dp;
> + pud_t *pudp, *saved_pudp;
> + pmd_t *pmdp, *saved_pmdp;
> + pte_t *ptep, *saved_ptep;
> + pgprot_t prot = vm_get_page_prot(VMA_TEST_FLAGS);
> + unsigned long vaddr = VADDR_TEST;
> +
> + mm = mm_alloc();
> + if (!mm) {
> + pr_err("mm_struct allocation failed\n");
> + return 1;
> + }
> +
> + page = alloc_mapped_page();
> + if (!page) {
> + pr_err("memory allocation failed\n");
> + return 1;
> + }
> +
> + pgdp = pgd_offset(mm, vaddr);
> + p4dp = p4d_alloc(mm, pgdp, vaddr);
> + pudp = pud_alloc(mm, p4dp, vaddr);
> + pmdp = pmd_alloc(mm, pudp, vaddr);
> + ptep = pte_alloc_map(mm, pmdp, vaddr);
> +
> + /*
> + * Save all the page table page addresses as the page table
> + * entries will be used for testing with random or garbage
> + * values. These saved addresses will be used for freeing
> + * page table pages.
> + */
> + saved_p4dp = p4d_offset(pgdp, 0UL);
> + saved_pudp = pud_offset(p4dp, 0UL);
> + saved_pmdp = pmd_offset(pudp, 0UL);
> + saved_ptep = pte_offset_map(pmdp, 0UL);
> +
> + pte_basic_tests(page, prot);
> + pmd_basic_tests(page, prot);
> + pud_basic_tests(page, prot);
> + p4d_basic_tests(page, prot);
> + pgd_basic_tests(page, prot);
> +
> + pte_clear_tests(ptep);
> + pmd_clear_tests(pmdp);
> + pud_clear_tests(pudp);
> + p4d_clear_tests(p4dp);
> + pgd_clear_tests(pgdp);
> +
> + pmd_populate_tests(mm, pmdp, (pgtable_t) page);
This is not correct for architectures that defines pgtable_t as pte_t
pointer, not struct page pointer.
> + pud_populate_tests(mm, pudp, pmdp);
> + p4d_populate_tests(mm, p4dp, pudp);
> + pgd_populate_tests(mm, pgdp, p4dp);
This is wrong. All p?dp points to the second entry in page table entry.
This is not valid pointer for page table and triggers p?d_bad() on x86.
Use saved_p?dp instead.
> +
> + p4d_free(mm, saved_p4dp);
> + pud_free(mm, saved_pudp);
> + pmd_free(mm, saved_pmdp);
> + pte_free(mm, (pgtable_t) virt_to_page(saved_ptep));
> +
> + mm_dec_nr_puds(mm);
> + mm_dec_nr_pmds(mm);
> + mm_dec_nr_ptes(mm);
> + __mmdrop(mm);
> +
> + free_mapped_page(page);
> + return 0;
> +}
> +
> +static void __exit arch_pgtable_tests_exit(void) { }
> +
> +module_init(arch_pgtable_tests_init);
> +module_exit(arch_pgtable_tests_exit);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Anshuman Khandual <anshuman.khandual@arm.com>");
> +MODULE_DESCRIPTION("Test archicture page table helpers");
> --
> 2.20.1
>
>
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH net-next] MAINTAINERS: add myself as maintainer for xilinx axiethernet driver
From: Michal Simek @ 2019-09-04 14:18 UTC (permalink / raw)
To: Radhey Shyam Pandey, davem, netdev
Cc: linux-kernel, anirudha.sarangi, michal.simek, gregkh,
mchehab+samsung, linux, linux-arm-kernel
In-Reply-To: <1567604658-9335-1-git-send-email-radhey.shyam.pandey@xilinx.com>
On 04. 09. 19 15:44, Radhey Shyam Pandey wrote:
> I am maintaining xilinx axiethernet driver in xilinx tree and would like
> to maintain it in the mainline kernel as well. Hence adding myself as a
> maintainer. Also Anirudha and John has moved to new roles, so based on
> request removing them from the maintainer list.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Acked-by: John Linn <john.linn@xilinx.com>
> ---
> MAINTAINERS | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a081c47..74d5566 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17714,8 +17714,7 @@ F: include/uapi/linux/dqblk_xfs.h
> F: include/uapi/linux/fsmap.h
>
> XILINX AXI ETHERNET DRIVER
> -M: Anirudha Sarangi <anirudh@xilinx.com>
> -M: John Linn <John.Linn@xilinx.com>
> +M: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> S: Maintained
> F: drivers/net/ethernet/xilinx/xilinx_axienet*
>
>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From: Walter Wu @ 2019-09-04 14:16 UTC (permalink / raw)
To: Andrey Konovalov
Cc: wsd_upstream, Arnd Bergmann, Linux Memory Management List,
linux-mediatek, LKML, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, Linux ARM, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <CAAeHK+wyvLF8=DdEczHLzNXuP+oC0CEhoPmp_LHSKVNyAiRGLQ@mail.gmail.com>
On Wed, 2019-09-04 at 15:44 +0200, Andrey Konovalov wrote:
> On Wed, Sep 4, 2019 at 8:51 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > +config KASAN_DUMP_PAGE
> > + bool "Dump the page last stack information"
> > + depends on KASAN && PAGE_OWNER
> > + help
> > + By default, KASAN doesn't record alloc/free stack for page allocator.
> > + It is difficult to fix up page use-after-free issue.
> > + This feature depends on page owner to record the last stack of page.
> > + It is very helpful for solving the page use-after-free or out-of-bound.
>
> I'm not sure if we need a separate config for this. Is there any
> reason to not have this enabled by default?
PAGE_OWNER need some memory usage, it is not allowed to enable by
default in low RAM device. so I create new feature option and the person
who wants to use it to enable it.
Thanks.
Walter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 16/36] spi: spi-meson-spifc: use devm_platform_ioremap_resource() to simplify code
From: Neil Armstrong @ 2019-09-04 14:14 UTC (permalink / raw)
To: YueHaibing, broonie, f.fainelli, rjui, sbranden, eric, wahrenst,
shc_work, agross, khilman, matthias.bgg, shawnguo, s.hauer,
kernel, festevam, linux-imx, avifishman70, tmaimon77, tali.perry1,
venture, yuenn, benjaminfair, kgene, krzk, andi, palmer,
paul.walmsley, baohua, mripard, wens, ldewangan, thierry.reding,
jonathanh, yamada.masahiro, michal.simek
Cc: linux-samsung-soc, linux-arm-msm, openbmc, linux-kernel,
linux-spi, linux-mediatek, linux-rpi-kernel, linux-amlogic,
linux-tegra, bcm-kernel-feedback-list, linux-riscv,
linux-arm-kernel
In-Reply-To: <20190904135918.25352-17-yuehaibing@huawei.com>
On 04/09/2019 15:58, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/spi/spi-meson-spifc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-meson-spifc.c b/drivers/spi/spi-meson-spifc.c
> index f7fe9b1..c7b0399 100644
> --- a/drivers/spi/spi-meson-spifc.c
> +++ b/drivers/spi/spi-meson-spifc.c
> @@ -286,7 +286,6 @@ static int meson_spifc_probe(struct platform_device *pdev)
> {
> struct spi_master *master;
> struct meson_spifc *spifc;
> - struct resource *res;
> void __iomem *base;
> unsigned int rate;
> int ret = 0;
> @@ -300,8 +299,7 @@ static int meson_spifc_probe(struct platform_device *pdev)
> spifc = spi_master_get_devdata(master);
> spifc->dev = &pdev->dev;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - base = devm_ioremap_resource(spifc->dev, res);
> + base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(base)) {
> ret = PTR_ERR(base);
> goto out_err;
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From: Vlastimil Babka @ 2019-09-04 14:13 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, Arnd Bergmann, linux-mm, linux-mediatek,
linux-kernel, kasan-dev, Martin Schwidefsky, Alexander Potapenko,
linux-arm-kernel, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <1567605965.32522.14.camel@mtksdccf07>
On 9/4/19 4:06 PM, Walter Wu wrote:
> On Wed, 2019-09-04 at 14:49 +0200, Vlastimil Babka wrote:
>> On 9/4/19 8:51 AM, Walter Wu wrote:
>> > This patch is KASAN report adds the alloc/free stacks for page allocator
>> > in order to help programmer to see memory corruption caused by page.
>> >
>> > By default, KASAN doesn't record alloc/free stack for page allocator.
>> > It is difficult to fix up page use-after-free issue.
>> >
>> > This feature depends on page owner to record the last stack of pages.
>> > It is very helpful for solving the page use-after-free or out-of-bound.
>> >
>> > KASAN report will show the last stack of page, it may be:
>> > a) If page is in-use state, then it prints alloc stack.
>> > It is useful to fix up page out-of-bound issue.
>>
>> I expect this will conflict both in syntax and semantics with my series [1] that
>> adds the freeing stack to page_owner when used together with debug_pagealloc,
>> and it's now in mmotm. Glad others see the need as well :) Perhaps you could
>> review the series, see if it fulfils your usecase (AFAICS the series should be a
>> superset, by storing both stacks at once), and perhaps either make KASAN enable
>> debug_pagealloc, or turn KASAN into an alternative enabler of the functionality
>> there?
>>
>> Thanks, Vlastimil
>>
>> [1] https://lore.kernel.org/linux-mm/20190820131828.22684-1-vbabka@suse.cz/t/#u
>>
> Thanks your information.
> We focus on the smartphone, so it doesn't enable
> CONFIG_TRANSPARENT_HUGEPAGE, Is it invalid for our usecase?
The THP fix is not required for the rest of the series, it was even merged to
mainline separately.
> And It looks like something is different, because we only need last
> stack of page, so it can decrease memory overhead.
That would save you depot_stack_handle_t (which is u32) per page. I guess that's
nothing compared to KASAN overhead?
> I will try to enable debug_pagealloc(with your patch) and KASAN, then we
> see the result.
Thanks.
> Thanks.
> Walter
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 15/36] spi: meson-spicc: use devm_platform_ioremap_resource() to simplify code
From: Neil Armstrong @ 2019-09-04 14:13 UTC (permalink / raw)
To: YueHaibing, broonie, f.fainelli, rjui, sbranden, eric, wahrenst,
shc_work, agross, khilman, matthias.bgg, shawnguo, s.hauer,
kernel, festevam, linux-imx, avifishman70, tmaimon77, tali.perry1,
venture, yuenn, benjaminfair, kgene, krzk, andi, palmer,
paul.walmsley, baohua, mripard, wens, ldewangan, thierry.reding,
jonathanh, yamada.masahiro, michal.simek
Cc: linux-samsung-soc, linux-arm-msm, openbmc, linux-kernel,
linux-spi, linux-mediatek, linux-rpi-kernel, linux-amlogic,
linux-tegra, bcm-kernel-feedback-list, linux-riscv,
linux-arm-kernel
In-Reply-To: <20190904135918.25352-16-yuehaibing@huawei.com>
On 04/09/2019 15:58, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/spi/spi-meson-spicc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
> index 7fe4488..f3f1044 100644
> --- a/drivers/spi/spi-meson-spicc.c
> +++ b/drivers/spi/spi-meson-spicc.c
> @@ -503,7 +503,6 @@ static int meson_spicc_probe(struct platform_device *pdev)
> {
> struct spi_master *master;
> struct meson_spicc_device *spicc;
> - struct resource *res;
> int ret, irq, rate;
>
> master = spi_alloc_master(&pdev->dev, sizeof(*spicc));
> @@ -517,8 +516,7 @@ static int meson_spicc_probe(struct platform_device *pdev)
> spicc->pdev = pdev;
> platform_set_drvdata(pdev, spicc);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - spicc->base = devm_ioremap_resource(&pdev->dev, res);
> + spicc->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(spicc->base)) {
> dev_err(&pdev->dev, "io resource mapping failed\n");
> ret = PTR_ERR(spicc->base);
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Sudeep Holla @ 2019-09-04 14:12 UTC (permalink / raw)
To: Lee Jones
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
bjorn.andersson, agross, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20190904121606.17474-1-lee.jones@linaro.org>
On Wed, Sep 04, 2019 at 01:16:06PM +0100, Lee Jones wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
>
> Supported by this patch is: keyboard, battery monitoring, UFS storage,
> USB host and Bluetooth.
>
Just curious to know if the idea of booting using ACPI is completely
dropped as it's extremely difficult(because the firmware is so hacked
up and may violate spec, just my opinion) for whatever reasons.
We just made ACPI table version checking more lenient for this platform
and would be good to know if we continue to run ACPI on that or will
abandon and just use DT.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/2] mmc: block: add CMD13 polling for ioctl() cmd with R1B response
From: Avri Altman @ 2019-09-04 14:11 UTC (permalink / raw)
To: Chaotian Jing, Ulf Hansson
Cc: Jens Axboe, Chris Boot, srv_heupstream@mediatek.com,
linux-mmc@vger.kernel.org, Zachary Hays, YueHaibing,
linux-kernel@vger.kernel.org, Ming Lei, Wolfram Sang,
linux-mediatek@lists.infradead.org, Hannes Reinecke,
Matthias Brugger, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190904075444.2163-3-chaotian.jing@mediatek.com>
> static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct
> mmc_blk_data *md,
> struct mmc_blk_ioc_data *idata)
> {
> @@ -623,6 +675,9 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card
> *card, struct mmc_blk_data *md,
> __func__, status, err);
> }
>
> + if (!err && (cmd.flags & MMC_RSP_R1B))
> + err = card_busy_detect(card, MMC_BLK_TIMEOUT_MS, NULL);
> +
> return err;
> }
You have both the R1B flag check, and status poll (for rpmb) few line above.
Maybe you could re-use it.
It will both simplify this patch, and save the tad optimization of your first patch.
Thanks,
Avri
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] net: gmii2rgmii: Switch priv field in mdio device structure
From: Harini Katakam @ 2019-09-04 14:11 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, radhey.shyam.pandey, Michal Simek,
linux-kernel, Harini Katakam, David Miller, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <20190813153820.GY14290@lunn.ch>
Hi Andrew,
On Tue, Aug 13, 2019 at 9:40 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > The kernel does have a few helper, spi_get_drvdata, pci_get_drvdata,
> > > hci_get_drvdata. So maybe had add phydev_get_drvdata(struct phy_device
> > > *phydev)?
> >
> > Maybe phydev_mdio_get_drvdata? Because the driver data member available is
> > phydev->mdio.dev.driver_data.
>
> I still prefer phydev_get_drvdata(). It fits with the X_get_drvdata()
> pattern, where X is the type of parameter passed to the call, spi,
> pci, hci.
>
> We can also add mdiodev_get_drvdata(mdiodev). A few DSA drivers could
> use that.
Sorry for the late reply. I just sent a v2 adding
mdiodev_get/set_drvdata helpers
and using them in gmii2rgmii driver.
I did not add a corresponding phydev helper because there is no "struct dev" in
"struct phy_device" and I dint know if there were any users to add the member
and then a helper for driver data. Also,
strutct phy_device { struct mdio_device { struct device }}
is already available and it seemed logical to use that field to
set/get driver data
for gmii2rgmii. Please let me know if v2 is okay.
Regards,
Harini
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From: Walter Wu @ 2019-09-04 14:06 UTC (permalink / raw)
To: Vlastimil Babka
Cc: wsd_upstream, Arnd Bergmann, linux-mm, linux-mediatek,
linux-kernel, kasan-dev, Martin Schwidefsky, Alexander Potapenko,
linux-arm-kernel, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <401064ae-279d-bef3-a8d5-0fe155d0886d@suse.cz>
On Wed, 2019-09-04 at 14:49 +0200, Vlastimil Babka wrote:
> On 9/4/19 8:51 AM, Walter Wu wrote:
> > This patch is KASAN report adds the alloc/free stacks for page allocator
> > in order to help programmer to see memory corruption caused by page.
> >
> > By default, KASAN doesn't record alloc/free stack for page allocator.
> > It is difficult to fix up page use-after-free issue.
> >
> > This feature depends on page owner to record the last stack of pages.
> > It is very helpful for solving the page use-after-free or out-of-bound.
> >
> > KASAN report will show the last stack of page, it may be:
> > a) If page is in-use state, then it prints alloc stack.
> > It is useful to fix up page out-of-bound issue.
>
> I expect this will conflict both in syntax and semantics with my series [1] that
> adds the freeing stack to page_owner when used together with debug_pagealloc,
> and it's now in mmotm. Glad others see the need as well :) Perhaps you could
> review the series, see if it fulfils your usecase (AFAICS the series should be a
> superset, by storing both stacks at once), and perhaps either make KASAN enable
> debug_pagealloc, or turn KASAN into an alternative enabler of the functionality
> there?
>
> Thanks, Vlastimil
>
> [1] https://lore.kernel.org/linux-mm/20190820131828.22684-1-vbabka@suse.cz/t/#u
>
Thanks your information.
We focus on the smartphone, so it doesn't enable
CONFIG_TRANSPARENT_HUGEPAGE, Is it invalid for our usecase?
And It looks like something is different, because we only need last
stack of page, so it can decrease memory overhead.
I will try to enable debug_pagealloc(with your patch) and KASAN, then we
see the result.
Thanks.
Walter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next 36/36] spi: fsl-spi: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-09-04 13:59 UTC (permalink / raw)
To: broonie, f.fainelli, rjui, sbranden, eric, wahrenst, shc_work,
agross, khilman, matthias.bgg, shawnguo, s.hauer, kernel,
festevam, linux-imx, avifishman70, tmaimon77, tali.perry1,
venture, yuenn, benjaminfair, kgene, krzk, andi, palmer,
paul.walmsley, baohua, mripard, wens, ldewangan, thierry.reding,
jonathanh, yamada.masahiro, michal.simek
Cc: linux-samsung-soc, YueHaibing, linux-arm-msm, openbmc,
linux-mediatek, linux-kernel, linux-spi, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-tegra, linux-amlogic, linux-riscv,
linux-arm-kernel
In-Reply-To: <20190904135918.25352-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/spi/spi-fsl-cpm.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
index e967ac5..858f054 100644
--- a/drivers/spi/spi-fsl-cpm.c
+++ b/drivers/spi/spi-fsl-cpm.c
@@ -305,12 +305,10 @@ int fsl_spi_cpm_init(struct mpc8xxx_spi *mspi)
}
if (mspi->flags & SPI_CPM1) {
- struct resource *res;
void *pram;
- res = platform_get_resource(to_platform_device(dev),
- IORESOURCE_MEM, 1);
- pram = devm_ioremap_resource(dev, res);
+ pram = devm_platform_ioremap_resource(to_platform_device(dev),
+ 1);
if (IS_ERR(pram))
mspi->pram = NULL;
else
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox