* 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: [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 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 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: [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] 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] Qualcomm ARM64 DT updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:03 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-2-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> ----------------------------------------------------------------
> Qualcomm ARM64 Updates for v5.4
>
> * Add Lenovo Miix 630, HP Envy x2, and Asus Novago TP370QL support
> * Assorted cleanups for SDM845 nodes
> * Add video nodes, cpu coefficients, adsp, csdp, and
> fastrpc nodes for SDM845
> * Add coresight for MSM8996, SDM845, and MSM8998
> * Misc cleanups on QCS404 and PMS405
> * Update memory map for QCS404
> * Add wifi rails, update WCSS clocks, and add ADS unit names on QCS404
> * Add Longcheer and Samsung Galaxy A3U/A5U support
> * Add initial support for SM8150 and PM8150
>
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: [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature
From: Ludovic BARRE @ 2019-09-04 15:04 UTC (permalink / raw)
To: Ulf Hansson
Cc: DTML, Alexandre Torgue, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Rob Herring, Srinivas Kandagatla,
Maxime Coquelin, linux-stm32, Linux ARM
In-Reply-To: <CAPDyKFpOj8g+eY-vTxW4Sk+wVYTP1-4jDJB=nE=24eSubBvN-g@mail.gmail.com>
hi Ulf
On 8/26/19 1:39 PM, Ulf Hansson wrote:
> On Tue, 13 Aug 2019 at 12:00, Ludovic Barre <ludovic.Barre@st.com> wrote:
>>
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> In some variants, the data timer starts and decrements
>> when the DPSM enters in Wait_R or Busy state
>> (while data transfer or MMC_RSP_BUSY), and generates a
>> data timeout error if the counter reach 0.
>
> I don't quite follow here, sorry. Can you please try to elaborate on
> the use case(s) more exactly?
>
> For example, what happens when a data transfer has just finished (for
> example when MCI_DATAEND has been received) and we are going to send a
> CMD12 to stop it? In this case the CMD12 has the MMC_RSP_BUSY flag
> set.
>
example with cmd25 (write multi block)
mmci_request
- mmci_start_data
set MMCIDATATIMER, MMCIDATALENGTH, MMCIMASK0
- mmci_start_command:
set MMCIARGUMENT, MMCICOMMAND (cmd25)
mmci_irq:
- irq MCI_CMDRESPEND
- irq MCI_DATAEND
- send cmd12 => mmci_start_command(host->stop_abort or data->stop)
these cmds have flag rsp_busy and no data associate
host->cmd = cmd (host->stop_abort or data->stop) for next irq
mmci_irq:
- irq MCI_CMDRESPEND
- irq BUSYD0END
- mmci_request_end
> Another example is the CMD5, which has no data with it.
>
>>
>> -Define max_busy_timeout (in ms) according to clock.
>> -Set data timer register if the command has rsp_busy flag.
>> If busy_timeout is not defined by framework, the busy
>> length after Data Burst is defined as 1 second
>> (refer: 4.6.2.2 Write of sd specification part1 v6-0).
>
> One second is not sufficient for all operations, like ERASE for
> example. However, I understand that you want to pick some value, as a
> safety. I guess that's fine.
>
> I am thinking that if the command has the MMC_RSP_BUSY flag set, the
> core should really provide a busy timeout for it. That said, maybe the
> host driver should splat a WARN in case there is not busy timeout
> specified.
Today, I just see a busy_timeout not defined on write request.
On erase request, the timeout is defined in function mmc_do_erase.
In core, there are several paths to done a write request, and I not
be sure to fix all. For safety, I preferred fix with the max value of
write request.
>
>> -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>> ---
>> drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
>> drivers/mmc/host/mmci.h | 3 +++
>> 2 files changed, 35 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index c37e70dbe250..c50586540765 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -1075,6 +1075,7 @@ static void
>> mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
>> {
>> void __iomem *base = host->base;
>> + unsigned long long clks = 0;
>>
>> dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
>> cmd->opcode, cmd->arg, cmd->flags);
>> @@ -1097,6 +1098,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
>> else
>> c |= host->variant->cmdreg_srsp;
>> }
>> +
>> + if (host->variant->busy_timeout && !host->mrq->data) {
>
> Suppose this is a CMD12 command, having the MMC_RSP_BUSY flag set. The
> command would then be sent to stop the transmission and then
> host->mrq->data would also be set.
Sorry, it's a mistake introduce by v5.
I would keep the clear of datatimer when is not needed
(no data & no rsp busy, see below). But on cmd23 (set_block_count) with
datactrl_first variant property the datatimer should be protected.
To simplify and fix the code, I will remove the clear of datatimer
when there is no data & no rsp busy.
- if (host->variant->busy_timeout && !host->mrq->data) {
+ if (host->variant->busy_timeout && !cmd->flags & MMC_RSP_BUSY) {
+ ....
+ writel_relaxed(clks, host->base + MMCIDATATIMER);
+ }
>
> If I recall earlier what you stated about the new sdmmc variant, the
> CMD12 is needed to exit the DPSM. Hence don't you need to re-program a
> new value for the MMCIDATATIMER register for this scenario?
>
>> + if (cmd->flags & MMC_RSP_BUSY) {
>> + if (!cmd->busy_timeout)
>> + cmd->busy_timeout = 1000;
>> +
>> + clks = (unsigned long long)cmd->busy_timeout;
>> + clks *= host->cclk;
>
> Any problems with putting the above on one line?
No, it was just to not exceed 80 characters.
>
>> + do_div(clks, MSEC_PER_SEC);
>> + }
>> + writel_relaxed(clks, host->base + MMCIDATATIMER);
>
> This is writing zero to MMCIDATATIMER in case the MMC_RSP_BUSY isn't
> set, is that on purpose?
It was to clear the datatimer when the command has
no data & no rsp_busy. This allowed to look if the datatimer
was used and not correctly set with the right value (with datatimeout).
Like said above, I will remove this and set datatimer only
on rsp_busy flag.
>
>> + }
>> +
>> if (/*interrupt*/0)
>> c |= MCI_CPSM_INTERRUPT;
>>
>> @@ -1203,6 +1217,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> {
>> void __iomem *base = host->base;
>> bool sbc, busy_resp;
>> + u32 err_msk;
>>
>> if (!cmd)
>> return;
>> @@ -1215,8 +1230,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> * handling. Note that we tag on any latent IRQs postponed
>> * due to waiting for busy status.
>> */
>> - if (!((status|host->busy_status) &
>> - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
>> + err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
>
> You might as well move the initial assignment of err_msk to the its
> declaration above.
>
OK, thx
>> + if (host->variant->busy_timeout && busy_resp)
>> + err_msk |= MCI_DATATIMEOUT;
>> +
>> + if (!((status | host->busy_status) &
>> + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
>> return;
>>
>> /* Handle busy detection on DAT0 if the variant supports it. */
>> @@ -1235,8 +1254,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> * while, to allow it to be set, but tests indicates that it
>> * isn't needed.
>> */
>> - if (!host->busy_status &&
>> - !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
>> + if (!host->busy_status && !(status & err_msk) &&
>> (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
>>
>> writel(readl(base + MMCIMASK0) |
>> @@ -1290,6 +1308,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>> cmd->error = -ETIMEDOUT;
>> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
>> cmd->error = -EILSEQ;
>> + } else if (host->variant->busy_timeout && busy_resp &&
>> + status & MCI_DATATIMEOUT) {
>> + cmd->error = -ETIMEDOUT;
>> } else {
>> cmd->resp[0] = readl(base + MMCIRESPONSE0);
>> cmd->resp[1] = readl(base + MMCIRESPONSE1);
>> @@ -1948,6 +1969,8 @@ static int mmci_probe(struct amba_device *dev,
>> * Enable busy detection.
>> */
>> if (variant->busy_detect) {
>> + u32 max_busy_timeout = 0;
>> +
>> mmci_ops.card_busy = mmci_card_busy;
>> /*
>> * Not all variants have a flag to enable busy detection
>> @@ -1957,7 +1980,11 @@ static int mmci_probe(struct amba_device *dev,
>> mmci_write_datactrlreg(host,
>> host->variant->busy_dpsm_flag);
>> mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
>> - mmc->max_busy_timeout = 0;
>> +
>> + if (variant->busy_timeout)
>> + max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
>
> It looks like the max busy timeout is depending on the current picked
> clock rate, right?
>
> In such case, perhaps it's better to update mmc->max_busy_timeout as
> part of the ->set_ios() callback, as it's from there the clock rate
> gets updated. Or what do you think?
yes, it's possible
>
>> +
>> + mmc->max_busy_timeout = max_busy_timeout;
>> }
>>
>> /* Prepare a CMD12 - needed to clear the DPSM on some variants. */
>> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
>> index 833236ecb31e..d8b7f6774e8f 100644
>> --- a/drivers/mmc/host/mmci.h
>> +++ b/drivers/mmc/host/mmci.h
>> @@ -287,6 +287,8 @@ struct mmci_host;
>> * @signal_direction: input/out direction of bus signals can be indicated
>> * @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
>> * @busy_detect: true if the variant supports busy detection on DAT0.
>> + * @busy_timeout: true if the variant starts data timer when the DPSM
>> + * enter in Wait_R or Busy state.
>> * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
>> * @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
>> * indicating that the card is busy
>> @@ -333,6 +335,7 @@ struct variant_data {
>> u8 signal_direction:1;
>> u8 pwrreg_clkgate:1;
>> u8 busy_detect:1;
>> + u8 busy_timeout:1;
>> u32 busy_dpsm_flag;
>> u32 busy_detect_flag;
>> u32 busy_detect_mask;
>> --
>> 2.17.1
>>
>
> Kind regards
> Uffe
>
_______________________________________________
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 02/10] KVM: arm/arm64: Factor out hypercall handling from PSCI code
From: Steven Price @ 2019-09-04 15:05 UTC (permalink / raw)
To: kbuild test robot
Cc: Mark Rutland, Christoffer Dall, kvm,
Radim =?unknown-8bit?B?S3LEjW3DocWZ?=, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, kbuild-all, Marc Zyngier, Paolo Bonzini,
Julien Thierry, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <201909021437.rO6o0mHc%lkp@intel.com>
On 02/09/2019 08:06, kbuild test robot wrote:
> Hi Steven,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc6 next-20190830]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Steven-Price/arm64-Stolen-time-support/20190901-185152
> config: i386-randconfig-a002-201935 (attached as .config)
> compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/kvm/arm_hypercalls.h:7:0,
> from <command-line>:0:
>>> arch/x86/include/asm/kvm_emulate.h:349:22: error: 'NR_VCPU_REGS' undeclared here (not in a function)
> unsigned long _regs[NR_VCPU_REGS];
> ^~~~~~~~~~~~
This is because x86's asm/kvm_emulate.h can't be included by itself (and
doesn't even exist on other architectures). This new header file doesn't
make sense to include on x86, so I'll squash in the following to prevent
building the header file except on arm/arm64.
Steve
----8<----
diff --git a/include/Kbuild b/include/Kbuild
index c38f0d46b267..f775ea28716e 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -67,6 +67,8 @@ header-test- += keys/big_key-type.h
header-test- += keys/request_key_auth-type.h
header-test- += keys/trusted.h
header-test- += kvm/arm_arch_timer.h
+header-test-$(CONFIG_ARM) += kvm/arm_hypercalls.h
+header-test-$(CONFIG_ARM64) += kvm/arm_hypercalls.h
header-test- += kvm/arm_pmu.h
header-test-$(CONFIG_ARM) += kvm/arm_psci.h
header-test-$(CONFIG_ARM64) += kvm/arm_psci.h
_______________________________________________
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: [GIT PULL] Qualcomm Defconfig updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:05 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-3-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> ----------------------------------------------------------------
> Qualcomm ARM Based defconfig Updates for v5.4
>
> * Add DRM_MSM to ARCH_QCOM defconfigs
Pulled into arm/defconfig, 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 v4 01/10] KVM: arm64: Document PV-time interface
From: Steven Price @ 2019-09-04 15:07 UTC (permalink / raw)
To: Andrew Jones
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: <20190904142250.ohnkunb5ocwbnx6z@kamzik.brq.redhat.com>
On 04/09/2019 15:22, Andrew Jones wrote:
> 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?
Yes this is effectively the same failure. But since we require the
vcpu-ioctl to enable stolen time this gives an appropriate place to
fail. Indeed this is the failure if migrating from a host with these
patches to one running an existing kernel with no stolen time support.
Steve
_______________________________________________
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 15:09 UTC (permalink / raw)
To: Mark Brown
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: <20190904143928.GB4348@sirena.co.uk>
On Wed, 4 Sep 2019 at 16:39, Mark Brown <broonie@kernel.org> wrote:
>
> 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.
Running internally coccinelle is already credited with commit author.
The credits are coming with "From:" field.
Otherwise for commits I send I could use:
From: krzk
...
Reported-by: www.krzk.eu
Signed-off-by: krzk
To me it is ridiculous.
Different thing is that Reported-by is for fixing bugs or issues.
There is no bug here. There is no problem solved except making the
code smaller. That's not what is Reported-by for.
Best regards,
Krzysztof
_______________________________________________
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] Qualcomm Driver updates for 5.4
From: Arnd Bergmann @ 2019-09-04 15:09 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-4-git-send-email-agross@kernel.org>
On Sun, Sep 1, 2019 at 7:54 AM Andy Gross <agross@kernel.org> wrote:
> Qualcomm ARM Based Driver Updates for v5.4
>
> * Add AOSS QMP support
> * Various fixups for Qualcomm SCM
> * Add socinfo driver
> * Add SoC serial number attribute and associated APIs
> * Add SM8150 and SC7180 support in Qualcomm SCM
> * Fixup max processor count in SMEM
>
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: [GIT PULL 3/3] Broadcom devicetree changes for 5.4
From: Arnd Bergmann @ 2019-09-04 15:12 UTC (permalink / raw)
To: Florian Fainelli
Cc: Kevin Hilman, Eric Anholt, arm-soc, bcm-kernel-feedback-list,
Stefan Wahren, Olof Johansson, Linux ARM
In-Reply-To: <20190819190552.11254-3-f.fainelli@gmail.com>
On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> This pull request contains Broadcom ARM-based SoCs Device Tree updates
> for 5.4, please pull the following:
>
> - Stefan does a bunch of preparatory work for supporting the Raspberry
> Pi 4in the next merge window correct register ranges (SPI, I2C,
> UART), define memory, HDMI and MMC properties at the board level
>
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] Texas Instruments K3 SoC changes for 5.4
From: Arnd Bergmann @ 2019-09-04 15:24 UTC (permalink / raw)
To: Tero Kristo
Cc: Nishanth Menon, Lokesh Vutla, SoC Team, arm-soc,
Santosh Shilimkar, Devshatwar, Nikhil,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <b838d666-ab3b-7d41-67d4-09d606c732da@ti.com>
On Fri, Aug 30, 2019 at 3:50 PM Tero Kristo <t-kristo@ti.com> wrote:
>
> Hello arm-soc maintainers,
>
> Here are the changes for TI K3 SoC family for 5.4. This pull request is
> based on top of drivers_soc_for_5.4 [1] from Santosh, basically because
> there is hard dependency on this pull towards that. Otherwise any of the
> DTS patches applying exclusive access flags will fail to compile.
>
> I am hoping this is fine, please holler if you have anything against
> this sequencing approach.
>
> [1] https://lkml.org/lkml/2019/8/26/1124
I pulled this into an arm/late branch this time, which simplifies
dealing with the dependency.
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 1/2] ti-sysc driver changes for v5.3
From: Arnd Bergmann @ 2019-09-04 15:26 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1566599057-142651@atomide.com>
On Sat, Aug 24, 2019 at 12:24 AM Tony Lindgren <tony@atomide.com> wrote:
> Driver changes for ti-sysc for v5.4
>
> Few changes to prepare for using a reset driver for PRM rstctrl mostly
> to deal with the clocks for reset. Then few minor clean-up patches and
> SPDX license identifier changes, and add a MAINTAINERs file entry.
Pulled this one into an arm/late branch, together with the three
other pull requests that depend on this one.
Don't worry about the arm/late name, I expect to send this off
together with the other branches, it's just easier for me to
describe what's in each of the top-level branches this way.
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 2/4] more ti-sysc driver changes for v5.4
From: Arnd Bergmann @ 2019-09-04 15:26 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1567016893-318461@atomide.com-2>
On Wed, Aug 28, 2019 at 8:35 PM Tony Lindgren <tony@atomide.com> wrote:
> more ti-sysc driver changes for omap variants for v5.4
>
> Few changes mostly to deal with sgx SoC glue quirk for omap36xx that
> is needed for the related sgx SoC glue dts branch. The other changes
> are to simplify sysc_check_one_child() sysc_check_children() to be void
> functions, and detect d2d module when debugging is enabled.
Pulled into arm/late, 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] drop more legacy pdata for omaps for v5.4
From: Arnd Bergmann @ 2019-09-04 15:27 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1567016893-318461@atomide.com-3>
On Wed, Aug 28, 2019 at 8:35 PM Tony Lindgren <tony@atomide.com> wrote:
> Drop legacy platform data omap variants for v5.4
>
> We can now drop more platform data in favor of dts data for most
> devices like cpsw, gpio, i2c, mmc, uart and watchdog.
>
> In general we can do this by dropping legacy "ti,hwmods" custom dts
> property, and the platform data assuming the related dts data is correct.
> This is best done as single patch as otherwise we'd have to revert two
> patches in case of any unexpected issues, and we're just removing data.
>
> Fro cpsw, before we can do this, we need to configure the cpsw mdio clocks
> properly in dts though in the first patch. For omap4 i2c, we've already
> dropped the platform data earlier, but have been still allocting it
> dynamically based on the dts data based on the "ti,hwmods" property, but
> that is no longer needed. For d2d, we are missing the dts data, so we
> first add it and then drop the platform data.
>
> For dra7, we drop platform data and "ti,hwmods" for mcasp and mcspi.
> We've already dropped platform data earlier for gpio, i2c, mmc, and
> uart so we just need to drop "ti,hwmods" property for those.
>
> Note that this branch is based on earlier ti-sysc-fixes branch.
Pulled into arm/late, 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] sgx soc glue changes for omaps for v5.4
From: Arnd Bergmann @ 2019-09-04 15:27 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1567016893-318461@atomide.com-4>
On Wed, Aug 28, 2019 at 8:35 PM Tony Lindgren <tony@atomide.com> wrote:
> SoC glue layer changes for SGX on omap variants for v5.4
>
> For a while we've had omap4 sgx glue layer defined in dts and probed
> with ti-sysc driver. This allows idling the sgx module for PM, and
> removes the need for custom platform glue layer code for any further
> driver changes.
>
> We first drop the unused legacy platform data for omap4 sgx. Then for
> omap5, we need add the missing clkctrl clock data so we can configure
> sgx. And we configure sgx for omap34xx, omap36xx and am3517.
>
> For am335x, we still have a dependency for rstctrl reset driver changes,
> so that will be added later on.
>
> Note that this branch is based on earlier ti-sysc branch for omap36xx
> glue layer quirk handling.
Pulled into arm/late, 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] ARM: mvebu: dt64 for v5.4 (#2)
From: Arnd Bergmann @ 2019-09-04 15:38 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Andrew Lunn, Jason Cooper, Marek Behún, SoC Team, arm-soc,
Olof Johansson, Linux ARM, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a0BqjtVoTrUedDGHBUv8gwL23XWqYM2831v7G+23i8++A@mail.gmail.com>
On Tue, Sep 3, 2019 at 11:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Sep 3, 2019 at 2:41 PM Gregory CLEMENT
> <gregory.clement@bootlin.com> wrote:
> > Here is the second pull request for dt64 for mvebu for v5.4.
> >
> > For the Turris Mox board there was dependencies with moxtet header which
> > was already merged in your arm/drivers branch. That the reason why I
> > merged this branch in my mvebu/dt64 branch.
> >
> > Let me know if it is a problem and if you want that I do it in a
> > different way.
>
> I don't really like this, but it's too late to do it right now. The problem is
> that I should have not picked up the patches from the list in the first
> place if there are these dependencies.
>
> This could have been communicated better in the patch series, but
> it really my own fault.
>
> > ----------------------------------------------------------------
> > mvebu dt64 for 5.4 (part 2)
> >
> > Add support for Turris Mox board (Armada 3720 SoC based)
> >
> > ----------------------------------------------------------------
> > Marek Behún (3):
> > arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl
> > dt-bindings: marvell: document Turris Mox compatible
> > arm64: dts: marvell: add DTS for Turris Mox
>
> I think the best way forward would be for me to apply the
> remaining patches on top of the arm/drivers branch, to avoid
> also pulling in your other DT changes into arm/drivers, or pulling
> in all of arm/drivers into arm/dt.
>
> Would that work for you?
I ended up creating an arm/late branch for other reasons, put
this branch in there as well.
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] ARM: mvebu: dt64 for v5.4 (#2)
From: Gregory CLEMENT @ 2019-09-04 15:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, Jason Cooper, Marek Behún, SoC Team, arm-soc,
Olof Johansson, Linux ARM, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a0igyBe-MQ9QcVMwCF4sx76MBVwtcsF=nFJf_sgYe2G2A@mail.gmail.com>
Hi Arnd,
> On Tue, Sep 3, 2019 at 11:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, Sep 3, 2019 at 2:41 PM Gregory CLEMENT
>> <gregory.clement@bootlin.com> wrote:
>> > Here is the second pull request for dt64 for mvebu for v5.4.
>> >
>> > For the Turris Mox board there was dependencies with moxtet header which
>> > was already merged in your arm/drivers branch. That the reason why I
>> > merged this branch in my mvebu/dt64 branch.
>> >
>> > Let me know if it is a problem and if you want that I do it in a
>> > different way.
>>
>> I don't really like this, but it's too late to do it right now. The problem is
>> that I should have not picked up the patches from the list in the first
>> place if there are these dependencies.
>>
>> This could have been communicated better in the patch series, but
>> it really my own fault.
>>
>> > ----------------------------------------------------------------
>> > mvebu dt64 for 5.4 (part 2)
>> >
>> > Add support for Turris Mox board (Armada 3720 SoC based)
>> >
>> > ----------------------------------------------------------------
>> > Marek Behún (3):
>> > arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl
>> > dt-bindings: marvell: document Turris Mox compatible
>> > arm64: dts: marvell: add DTS for Turris Mox
>>
>> I think the best way forward would be for me to apply the
>> remaining patches on top of the arm/drivers branch, to avoid
>> also pulling in your other DT changes into arm/drivers, or pulling
>> in all of arm/drivers into arm/dt.
>>
>> Would that work for you?
>
> I ended up creating an arm/late branch for other reasons, put
> this branch in there as well.
OK thanks!
Gregory
>
> Arnd
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.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 v4 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Steven Price @ 2019-09-04 15:53 UTC (permalink / raw)
To: Zenghui Yu, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm
Cc: kvm, linux-doc, Catalin Marinas, Russell King, linux-kernel,
Paolo Bonzini
In-Reply-To: <d55d091f-1c0f-9c47-b7b2-95c87285335d@huawei.com>
On 03/09/2019 10:14, Zenghui Yu wrote:
> On 2019/8/30 16:42, Steven Price wrote:
>> Implement the service call for configuring a shared structure between a
>> VCPU and the hypervisor in which the hypervisor can write the time
>> stolen from the VCPU's execution time by other tasks on the host.
>>
>> The hypervisor allocates memory which is placed at an IPA chosen by user
>> space.
>
> It seems that no allocation happens in the hypervisor code. User space
> will do it instead?
Ah, yes I should update the commit message. User space does now allocate
the memory. Thanks for spotting that.
Steve
>> The hypervisor then updates the shared structure using
>> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
>> reporting the stolen time in nanoseconds.
>>
>> Whenever stolen time is enabled by the guest, the stolen time counter is
>> reset.
>>
>> The stolen time itself is retrieved from the sched_info structure
>> maintained by the Linux scheduler code. We enable SCHEDSTATS when
>> selecting KVM Kconfig to ensure this value is meaningful.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>
> Thanks,
> zenghui
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] bus: imx-weim: remove incorrect __init annotations
From: Arnd Bergmann @ 2019-09-04 16:00 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Rob Herring, Arnd Bergmann, Sven Van Asbroeck, linux-kernel,
clang-built-linux, NXP Linux Team, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-kernel
The probe function is no longer __init, so anything it calls now
must also be available at runtime, as Kbuild points out when building
with clang-9:
WARNING: vmlinux.o(.text+0x6e7040): Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
The function weim_probe() references
the function __init imx_weim_gpr_setup().
This is often because weim_probe lacks a __init
annotation or the annotation of imx_weim_gpr_setup is wrong.
WARNING: vmlinux.o(.text+0x6e70f0): Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
The function weim_probe() references
the function __init weim_timing_setup().
This is often because weim_probe lacks a __init
annotation or the annotation of weim_timing_setup is wrong.
Remove the remaining __init markings that are now wrong.
Fixes: 4a92f07816ba ("bus: imx-weim: use module_platform_driver()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I applied this on top of the patch taht introduced the build error
drivers/bus/imx-weim.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 79af0c27f5a3..28bb65a5613f 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -76,7 +76,7 @@ static const struct of_device_id weim_id_table[] = {
};
MODULE_DEVICE_TABLE(of, weim_id_table);
-static int __init imx_weim_gpr_setup(struct platform_device *pdev)
+static int imx_weim_gpr_setup(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct property *prop;
@@ -126,10 +126,10 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
}
/* Parse and set the timing for this device. */
-static int __init weim_timing_setup(struct device *dev,
- struct device_node *np, void __iomem *base,
- const struct imx_weim_devtype *devtype,
- struct cs_timing_state *ts)
+static int weim_timing_setup(struct device *dev,
+ struct device_node *np, void __iomem *base,
+ const struct imx_weim_devtype *devtype,
+ struct cs_timing_state *ts)
{
u32 cs_idx, value[MAX_CS_REGS_COUNT];
int i, ret;
--
2.20.0
_______________________________________________
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 v4 10/10] arm64: Retrieve stolen time as paravirtualized guest
From: Steven Price @ 2019-09-04 16:01 UTC (permalink / raw)
To: Andrew Jones
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190903084703.hwpelmr7fikb32nj@kamzik.brq.redhat.com>
On 03/09/2019 09:47, Andrew Jones wrote:
> On Fri, Aug 30, 2019 at 09:42:55AM +0100, Steven Price wrote:
>> Enable paravirtualization features when running under a hypervisor
>> supporting the PV_TIME_ST hypercall.
>>
>> For each (v)CPU, we ask the hypervisor for the location of a shared
>> page which the hypervisor will use to report stolen time to us. We set
>> pv_time_ops to the stolen time function which simply reads the stolen
>> value from the shared page for a VCPU. We guarantee single-copy
>> atomicity using READ_ONCE which means we can also read the stolen
>> time for another VCPU than the currently running one while it is
>> potentially being updated by the hypervisor.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> arch/arm64/include/asm/paravirt.h | 9 +-
>> arch/arm64/kernel/paravirt.c | 148 ++++++++++++++++++++++++++++++
>> arch/arm64/kernel/time.c | 3 +
>> include/linux/cpuhotplug.h | 1 +
>> 4 files changed, 160 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/paravirt.h b/arch/arm64/include/asm/paravirt.h
>> index 799d9dd6f7cc..125c26c42902 100644
>> --- a/arch/arm64/include/asm/paravirt.h
>> +++ b/arch/arm64/include/asm/paravirt.h
>> @@ -21,6 +21,13 @@ static inline u64 paravirt_steal_clock(int cpu)
>> {
>> return pv_ops.time.steal_clock(cpu);
>> }
>> -#endif
>> +
>> +int __init kvm_guest_init(void);
>> +
>> +#else
>> +
>> +#define kvm_guest_init()
>> +
>> +#endif // CONFIG_PARAVIRT
>>
>> #endif
>> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
>> index 4cfed91fe256..5bf3be7ccf7e 100644
>> --- a/arch/arm64/kernel/paravirt.c
>> +++ b/arch/arm64/kernel/paravirt.c
>> @@ -6,13 +6,161 @@
>> * Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> */
>>
>> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
>> +
>> +#include <linux/arm-smccc.h>
>> +#include <linux/cpuhotplug.h>
>> #include <linux/export.h>
>> +#include <linux/io.h>
>> #include <linux/jump_label.h>
>> +#include <linux/printk.h>
>> +#include <linux/psci.h>
>> +#include <linux/reboot.h>
>> +#include <linux/slab.h>
>> #include <linux/types.h>
>> +
>> #include <asm/paravirt.h>
>> +#include <asm/pvclock-abi.h>
>> +#include <asm/smp_plat.h>
>>
>> struct static_key paravirt_steal_enabled;
>> struct static_key paravirt_steal_rq_enabled;
>>
>> struct paravirt_patch_template pv_ops;
>> EXPORT_SYMBOL_GPL(pv_ops);
>> +
>> +struct kvmarm_stolen_time_region {
>> + struct pvclock_vcpu_stolen_time *kaddr;
>> +};
>> +
>> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region, stolen_time_region);
>> +
>> +static bool steal_acc = true;
>> +static int __init parse_no_stealacc(char *arg)
>> +{
>> + steal_acc = false;
>> + return 0;
>> +}
>> +
>> +early_param("no-steal-acc", parse_no_stealacc);
>
> Need to also add an 'ARM64' to the
> Documentation/admin-guide/kernel-parameters.txt entry for this.
Good point, thanks for the pointer.
Steve
_______________________________________________
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 00/10] arm64: Stolen time support
From: Steven Price @ 2019-09-04 16:02 UTC (permalink / raw)
To: Andrew Jones
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190903084921.zikiucdruymfgfsq@kamzik.brq.redhat.com>
On 03/09/2019 09:49, Andrew Jones wrote:
> On Tue, Sep 03, 2019 at 10:03:48AM +0200, Andrew Jones wrote:
>> Hi Steven,
>>
>> I had some fun testing this series with the KVM selftests framework. It
>> looks like it works to me, so you may add
>>
>> Tested-by: Andrew Jones <drjones@redhat.com>
>>
>
> Actually, I probably shouldn't be quite so generous with this tag yet,
> because I haven't yet tested the guest-side changes. To do that I'll
> need to start prototyping something for QEMU. I need to finish some other
> stuff first, but then I can do that.
Thanks for the testing, I'll wait for your other testing before adding
your Tested-by tag.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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