* Re: [PATCH] drivers/perf: hisi: Permit modular builds of HiSilicon uncore drivers
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: Shaokun Zhang, Zhou Wang, Mark Rutland
Cc: catalin.marinas, Will Deacon, linuxarm, linux-arm-kernel
In-Reply-To: <1588820305-174479-1-git-send-email-wangzhou1@hisilicon.com>
On Thu, 7 May 2020 10:58:25 +0800, Zhou Wang wrote:
> This patch lets HiSilicon uncore PMU driver can be built as modules.
> A common module and three specific uncore PMU driver modules will be built.
>
> Export necessary functions in hisi_uncore_pmu module, and change
> irq_set_affinity to irq_set_affinity_hint to pass compile.
Applied to will (for-next/perf), thanks!
[1/1] drivers/perf: hisi: Permit modular builds of HiSilicon uncore drivers
https://git.kernel.org/will/c/97807325a02b
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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 v2] arm64: stacktrace: Factor out some common code into on_stack()
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: catalin.marinas, 0x7f454c46, hewenliang4, lorenzo.pieralisi,
Dave.Martin, hushiyuan, tglx, mark.rutland, james.morse,
linux-kernel, Yunfeng Ye, linux-arm-kernel
Cc: Will Deacon
In-Reply-To: <07b3b0e6-3f58-4fed-07ea-7d17b7508948@huawei.com>
On Fri, 8 May 2020 11:15:45 +0800, Yunfeng Ye wrote:
> There are some common codes for stack checking, so factors it out into
> the function on_stack().
>
> No functional change.
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: stacktrace: Factor out some common code into on_stack()
https://git.kernel.org/arm64/c/bd4298c72b56
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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] arm64: defconfig: enable Qualcomm IPA and RMNet modules
From: Bjorn Andersson @ 2020-05-18 23:37 UTC (permalink / raw)
To: Alex Elder
Cc: catalin.marinas, linux-kernel, evgreen, agross, linux-arm-kernel,
subashab, will, cpratapa
In-Reply-To: <20200518215455.10095-1-elder@linaro.org>
On Mon 18 May 14:54 PDT 2020, Alex Elder wrote:
> Enable building the Qualcomm IPA driver as a kernel module. To be
> useful, the IPA driver also requires RMNet, so enable building that
> as a module as well.
>
> Signed-off-by: Alex Elder <elder@linaro.org>
Applied
Thanks,
Bjorn
> ---
> arch/arm64/configs/defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 9c6500b71bc6..56261fd7ea8d 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -306,6 +306,7 @@ CONFIG_MLX4_EN=m
> CONFIG_MLX5_CORE=m
> CONFIG_MLX5_CORE_EN=y
> CONFIG_QCOM_EMAC=m
> +CONFIG_RMNET=m
> CONFIG_RAVB=y
> CONFIG_SMC91X=y
> CONFIG_SMSC911X=y
> @@ -313,6 +314,7 @@ CONFIG_SNI_AVE=y
> CONFIG_SNI_NETSEC=y
> CONFIG_STMMAC_ETH=m
> CONFIG_TI_K3_AM65_CPSW_NUSS=y
> +CONFIG_QCOM_IPA=m
> CONFIG_MDIO_BUS_MUX_MMIOREG=y
> CONFIG_MDIO_BUS_MUX_MULTIPLEXER=y
> CONFIG_AQUANTIA_PHY=y
> --
> 2.20.1
>
_______________________________________________
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 07/15] arch/kunmap_atomic: Consolidate duplicate code
From: Ira Weiny @ 2020-05-19 0:03 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200518042932.GA59205@roeck-us.net>
On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.weiny@intel.com wrote:
> > > > From: Ira Weiny <ira.weiny@intel.com>
> > > >
> > > > Every single architecture (including !CONFIG_HIGHMEM) calls...
> > > >
> > > > pagefault_enable();
> > > > preempt_enable();
> > > >
> > > > ... before returning from __kunmap_atomic(). Lift this code into the
> > > > kunmap_atomic() macro.
> > > >
> > > > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> > > > be consistent.
> > > >
> > > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> > >
> > > This patch results in:
> > >
> > > Starting init: /bin/sh exists but couldn't execute it (error -14)
> > >
> > > when trying to boot microblazeel:petalogix-ml605 in qemu.
> >
> > Thanks for the report. I'm not readily seeing the issue.
> >
> > Do you have a kernel config? Specifically is CONFIG_HIGHMEM set?
> >
> See below. Yes, CONFIG_HIGHMEM is set.
>
> The scripts used to build and boot the image are at:
>
> https://github.com/groeck/linux-build-test/tree/master/rootfs/microblazeel
Despite finding the obvious error earlier today I've still been trying to get
this to work.
I had to make some slight modifications to use the 0-day cross compile build
and my local qemu build. But those were pretty minor modifications. I'm
running on x86_64 host.
With those slight mods to the scripts I get the following error even without my
patch set on 5.7-rc4. I have 1 cpu pegged at 100% while it is running... Is
there anything I can do to get more debug output? Perhaps I just need to let
it run longer?
Thanks,
Ira
16:46:54 > ../linux-build-test/rootfs/microblazeel/run-qemu-microblazeel.sh
Build reference: v5.7-rc4-2-g7c2411d7fb6a
Building microblaze:petalogix-s3adsp1800:qemu_microblazeel_defconfig ...
running ................ failed (silent)
------------
qemu log:
qemu-system-microblazeel: terminating on signal 15 from pid 3277686 (/bin/bash)
------------
Building microblaze:petalogix-ml605:qemu_microblazeel_ml605_defconfig ...
running ................ failed (silent)
------------
qemu log:
qemu-system-microblazeel: terminating on signal 15 from pid 3277686 (/bin/bash)
------------
<env changes>
16:47:23 > git di
diff --git a/rootfs/microblazeel/run-qemu-microblazeel.sh b/rootfs/microblazeel/run-qemu-microblazeel.sh
index 68d4de39ab50..0d6a4f85308f 100755
--- a/rootfs/microblazeel/run-qemu-microblazeel.sh
+++ b/rootfs/microblazeel/run-qemu-microblazeel.sh
@@ -3,7 +3,8 @@
dir=$(cd $(dirname $0); pwd)
. ${dir}/../scripts/common.sh
-QEMU=${QEMU:-${QEMU_BIN}/qemu-system-microblazeel}
+#QEMU=${QEMU:-${QEMU_BIN}/qemu-system-microblazeel}
+QEMU=/home/iweiny/dev/qemu/microblazeel-softmmu/qemu-system-microblazeel
PREFIX=microblazeel-linux-
ARCH=microblaze
PATH_MICROBLAZE=/opt/kernel/microblazeel/gcc-4.9.1/usr/bin
diff --git a/rootfs/scripts/common.sh b/rootfs/scripts/common.sh
index 8fa6a9be2b2f..c4550a27beaa 100644
--- a/rootfs/scripts/common.sh
+++ b/rootfs/scripts/common.sh
@@ -1,5 +1,9 @@
#!/bin/bash
+# Set up make.cross
+export COMPILER_INSTALL_PATH=$HOME/0day
+export GCC_VERSION=6.5.0
+
# Set the following variable to true to skip DC395/AM53C97 build tests
__skip_dc395=0
@@ -569,7 +573,7 @@ doclean()
then
git clean -x -d -f -q
else
- make ARCH=${ARCH} mrproper >/dev/null 2>&1
+ make.cross ARCH=${ARCH} mrproper >/dev/null 2>&1
fi
}
@@ -669,7 +673,7 @@ __setup_config()
cp ${__progdir}/${defconfig} arch/${arch}/configs
fi
- if ! make ARCH=${ARCH} CROSS_COMPILE=${PREFIX} ${defconfig} >/dev/null 2>&1 </dev/null; then
+ if ! make.cross ARCH=${ARCH} ${defconfig} >/dev/null 2>&1 </dev/null; then
return 2
fi
@@ -687,7 +691,7 @@ __setup_config()
if [[ "${rel}" = "v3.16" ]]; then
target="oldconfig"
fi
- if ! make ARCH=${ARCH} CROSS_COMPILE=${PREFIX} ${target} >/dev/null 2>&1 </dev/null; then
+ if ! make.cross ARCH=${ARCH} ${target} >/dev/null 2>&1 </dev/null; then
return 1
fi
fi
@@ -1038,7 +1042,7 @@ dosetup()
rootfs="$(setup_rootfs ${dynamic} ${rootfs})"
__common_fixups "${fixups}" "${rootfs}"
- make -j${maxload} ARCH=${ARCH} CROSS_COMPILE=${PREFIX} ${EXTRAS} </dev/null >/dev/null 2>${logfile}
+ make.cross -j${maxload} ARCH=${ARCH} ${EXTRAS} </dev/null >/dev/null 2>${logfile}
rv=$?
if [ ${rv} -ne 0 ]
then
</env changes>
_______________________________________________
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 1/4] clk/soc: mediatek: mt8183: Bind clock driver from platform device
From: Chun-Kuang Hu @ 2020-05-19 0:21 UTC (permalink / raw)
To: Matthias Brugger
Cc: Kate Stewart, Chun-Kuang Hu, devicetree, Stephen Boyd,
Greg Kroah-Hartman, Michael Turquette, linux-kernel, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal,
matthias.bgg, Enric Balletbo i Serra, mtk01761, Thomas Gleixner,
linux-clk, Linux ARM
In-Reply-To: <d95bf802-4a9d-9791-cb0b-ba804d649045@gmail.com>
Hi, Matthias:
Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月18日 週一 下午11:57寫道：
>
>
>
> On 18/05/2020 17:30, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > <matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:32寫道：
> >>
> >> From: Matthias Brugger <matthias.bgg@gmail.com>
> >>
> >> The mmsys driver is now the top level entry point for the multimedia
> >> system (mmsys), we bind the clock driver by creating a platform device.
> >> We also bind the MediaTek DRM driver which is not yet implement and
> >> therefor will errror out for now.
> >
> > You may need to let CONFIG_MTK_MMSYS depends on
> > CONFIG_COMMON_CLK_MT8173_MMSYS || CONFIG_COMMON_CLK_MT8183_MMSYS
> >
>
> That will be fixed by:
> https://patchwork.kernel.org/patch/11469521/
>
> Otherwise this won't scale as we would need to add the SoCs using the mtk-mmsys
> driver and this will be a lot if not all.
I forgot that patch, so for this patch,
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
>
> Regards,
> Matthias
>
> > Regards,
> > Chun-Kuang.
> >
> >>
> >> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> >> ---
> >>
> >> drivers/clk/mediatek/clk-mt8183-mm.c | 9 ++-------
> >> drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
> >> 2 files changed, 10 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/clk/mediatek/clk-mt8183-mm.c b/drivers/clk/mediatek/clk-mt8183-mm.c
> >> index 720c696b506d..9d60e09619c1 100644
> >> --- a/drivers/clk/mediatek/clk-mt8183-mm.c
> >> +++ b/drivers/clk/mediatek/clk-mt8183-mm.c
> >> @@ -84,8 +84,9 @@ static const struct mtk_gate mm_clks[] = {
> >>
> >> static int clk_mt8183_mm_probe(struct platform_device *pdev)
> >> {
> >> + struct device *dev = &pdev->dev;
> >> + struct device_node *node = dev->parent->of_node;
> >> struct clk_onecell_data *clk_data;
> >> - struct device_node *node = pdev->dev.of_node;
> >>
> >> clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
> >>
> >> @@ -95,16 +96,10 @@ static int clk_mt8183_mm_probe(struct platform_device *pdev)
> >> return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> >> }
> >>
> >> -static const struct of_device_id of_match_clk_mt8183_mm[] = {
> >> - { .compatible = "mediatek,mt8183-mmsys", },
> >> - {}
> >> -};
> >> -
> >> static struct platform_driver clk_mt8183_mm_drv = {
> >> .probe = clk_mt8183_mm_probe,
> >> .driver = {
> >> .name = "clk-mt8183-mm",
> >> - .of_match_table = of_match_clk_mt8183_mm,
> >> },
> >> };
> >>
> >> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> >> index cacafe23c823..783c3dd008b2 100644
> >> --- a/drivers/soc/mediatek/mtk-mmsys.c
> >> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> >> @@ -92,6 +92,10 @@ static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> >> .clk_driver = "clk-mt8173-mm",
> >> };
> >>
> >> +static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
> >> + .clk_driver = "clk-mt8183-mm",
> >> +};
> >> +
> >> static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
> >> enum mtk_ddp_comp_id next,
> >> unsigned int *addr)
> >> @@ -339,6 +343,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
> >> .compatible = "mediatek,mt8173-mmsys",
> >> .data = &mt8173_mmsys_driver_data,
> >> },
> >> + {
> >> + .compatible = "mediatek,mt8183-mmsys",
> >> + .data = &mt8183_mmsys_driver_data,
> >> + },
> >> { }
> >> };
> >>
> >> --
> >> 2.26.2
> >>
> >>
> >> _______________________________________________
> >> Linux-mediatek mailing list
> >> Linux-mediatek@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
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] ARM: kprobes: Avoid fortify_panic() when copying optprobe template
From: Andrew Jeffery @ 2020-05-19 0:22 UTC (permalink / raw)
To: Masami Hiramatsu, Kees Cook
Cc: labbott, mathieu.desnoyers, Russell King, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200518112059.c19899ffb17a4843bf4f74ab@kernel.org>
On Mon, 18 May 2020, at 11:50, Masami Hiramatsu wrote:
> On Sun, 17 May 2020 14:48:52 -0700
> Kees Cook <keescook@chromium.org> wrote:
>
> > On Mon, May 18, 2020 at 01:09:59AM +0930, Andrew Jeffery wrote:
> > > As mentioned, a couple of attempts have been made to address the issue
> > > by casting a pointer to optprobe_template_entry before providing it to
> > > memcpy(), however gccs such as Ubuntu 20.04's arm-linux-gnueabi-gcc
> > > 9.3.0 (Ubuntu 9.3.0-10ubuntu1) see through these efforts.
> >
> > Ah, dang. :P
> >
> > How about converting them all to unsized arrays, which would also allow
> > the code to drop the "&" everywhere, I think. This is untested:
> >
>
> This looks good to me since it uses same technique in sections.h.
>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>
Kees,
Were you planning to send resend this, or were you looking for me to polish it
up?
Andrew
_______________________________________________
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/4] clk/soc: mediatek: mt6797: Bind clock driver from platform device
From: Chun-Kuang Hu @ 2020-05-19 0:23 UTC (permalink / raw)
To: matthias.bgg
Cc: Kate Stewart, devicetree, Stephen Boyd, Greg Kroah-Hartman,
Michael Turquette, linux-kernel, Richard Fontana, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal,
Matthias Brugger, mtk01761, Thomas Gleixner, linux-clk, Linux ARM
In-Reply-To: <20200518113156.25009-2-matthias.bgg@kernel.org>
Hi, Matthias:
<matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:32寫道：
>
> From: Matthias Brugger <matthias.bgg@gmail.com>
>
> The mmsys driver is now the top level entry point for the multimedia
> system (mmsys), we bind the clock driver by creating a platform device.
> We also bind the MediaTek DRM driver which is not yet implement and
> therefor will errror out for now.
>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
>
> drivers/clk/mediatek/clk-mt6797-mm.c | 9 ++-------
> drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
> 2 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt6797-mm.c b/drivers/clk/mediatek/clk-mt6797-mm.c
> index 8f05653b387d..01fdce287247 100644
> --- a/drivers/clk/mediatek/clk-mt6797-mm.c
> +++ b/drivers/clk/mediatek/clk-mt6797-mm.c
> @@ -92,16 +92,12 @@ static const struct mtk_gate mm_clks[] = {
> "clk26m", 3),
> };
>
> -static const struct of_device_id of_match_clk_mt6797_mm[] = {
> - { .compatible = "mediatek,mt6797-mmsys", },
> - {}
> -};
> -
> static int clk_mt6797_mm_probe(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> + struct device_node *node = dev->parent->of_node;
> struct clk_onecell_data *clk_data;
> int r;
> - struct device_node *node = pdev->dev.of_node;
>
> clk_data = mtk_alloc_clk_data(CLK_MM_NR);
>
> @@ -121,7 +117,6 @@ static struct platform_driver clk_mt6797_mm_drv = {
> .probe = clk_mt6797_mm_probe,
> .driver = {
> .name = "clk-mt6797-mm",
> - .of_match_table = of_match_clk_mt6797_mm,
> },
> };
>
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> index 783c3dd008b2..fee64c8d3020 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -88,6 +88,10 @@ static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> .clk_driver = "clk-mt2712-mm",
> };
>
> +static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
> + .clk_driver = "clk-mt6797-mm",
> +};
> +
> static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> .clk_driver = "clk-mt8173-mm",
> };
> @@ -339,6 +343,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
> .compatible = "mediatek,mt2712-mmsys",
> .data = &mt2712_mmsys_driver_data,
> },
> + {
> + .compatible = "mediatek,mt6797-mmsys",
> + .data = &mt6797_mmsys_driver_data,
> + },
> {
> .compatible = "mediatek,mt8173-mmsys",
> .data = &mt8173_mmsys_driver_data,
> --
> 2.26.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
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 v2 2/2] arm64: dts: rockchip: rk3399: fix pd_tcpc0 and pd_tcpc1 node position
From: Caesar Wang @ 2020-05-19 0:34 UTC (permalink / raw)
To: Heiko Stübner, Johan Jonker, kever.yang
Cc: devicetree, robh+dt, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <2978296.PvbIKR7951@diego>
Hi Heiko,
在 2020/5/19 上午6:29, Heiko Stübner 写道:
> Hi Kever, Caesar,
>
> could you double check where the type-c power-domains are located
> in the power-tree, as Caesar did add them under pd_vio back in 2016.
Johan's patch is correct, the pd_tcpc0 and pd_tcpc1 are grouped by VDD_LOGIC.
I have a passed test for pd_vio without pd_tcpc*.
>
> Thanks
> Heiko
>
> Am Dienstag, 28. April 2020, 22:30:03 CEST schrieb Johan Jonker:
>> The pd_tcpc0 and pd_tcpc1 nodes are currently a sub node of pd_vio.
>> In the rk3399 TRM figure of the 'Power Domain Partition' and in the
>> table of 'Power Domain and Voltage Domain Summary' these power domains
>> are positioned directly under VD_LOGIC, so fix that in 'rk3399.dtsi'.
>>
>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Caesar Wang <wxt@rock-chips.com>
Thanks,
-Caesar
>> ---
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 20 ++++++++++----------
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index 37279db53..a4dc1bf2e 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -1056,6 +1056,16 @@
>> clocks = <&cru HCLK_SDIO>;
>> pm_qos = <&qos_sdioaudio>;
>> };
>> + pd_tcpc0@RK3399_PD_TCPD0 {
>> + reg = <RK3399_PD_TCPD0>;
>> + clocks = <&cru SCLK_UPHY0_TCPDCORE>,
>> + <&cru SCLK_UPHY0_TCPDPHY_REF>;
>> + };
>> + pd_tcpc1@RK3399_PD_TCPD1 {
>> + reg = <RK3399_PD_TCPD1>;
>> + clocks = <&cru SCLK_UPHY1_TCPDCORE>,
>> + <&cru SCLK_UPHY1_TCPDPHY_REF>;
>> + };
>> pd_usb3@RK3399_PD_USB3 {
>> reg = <RK3399_PD_USB3>;
>> clocks = <&cru ACLK_USB3>;
>> @@ -1088,16 +1098,6 @@
>> pm_qos = <&qos_isp1_m0>,
>> <&qos_isp1_m1>;
>> };
>> - pd_tcpc0@RK3399_PD_TCPD0 {
>> - reg = <RK3399_PD_TCPD0>;
>> - clocks = <&cru SCLK_UPHY0_TCPDCORE>,
>> - <&cru SCLK_UPHY0_TCPDPHY_REF>;
>> - };
>> - pd_tcpc1@RK3399_PD_TCPD1 {
>> - reg = <RK3399_PD_TCPD1>;
>> - clocks = <&cru SCLK_UPHY1_TCPDCORE>,
>> - <&cru SCLK_UPHY1_TCPDPHY_REF>;
>> - };
>> pd_vo@RK3399_PD_VO {
>> reg = <RK3399_PD_VO>;
>> #address-cells = <1>;
>>
>
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] staging: vchiq_arm: cast with __force as needed
From: Mitchell Tasman @ 2020-05-19 0:45 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Greg Kroah-Hartman, Jamal Shareef,
Marcelo Diop-Gonzalez, Nishka Dasgupta
Cc: devel, linux-kernel, bcm-kernel-feedback-list, linux-rpi-kernel,
Mitchell Tasman, linux-arm-kernel
In several cases where a pointer marked as __user is
(intentionally) assigned or passed to a non-marked target,
cast to the target pointer type with a __force directive
to quiet warnings from sparse.
Signed-off-by: Mitchell Tasman <tasman@leaflabs.com>
---
.../vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 7 ++++---
.../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index c18c6ca0b6c0..38a13e4618a8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -371,14 +371,15 @@ create_pagelist(char __user *buf, size_t count, unsigned short type)
pagelistinfo->scatterlist = scatterlist;
pagelistinfo->scatterlist_mapped = 0;
- if (is_vmalloc_addr(buf)) {
+ if (is_vmalloc_addr((void __force *)buf)) {
unsigned long length = count;
unsigned int off = offset;
for (actual_pages = 0; actual_pages < num_pages;
actual_pages++) {
- struct page *pg = vmalloc_to_page(buf + (actual_pages *
- PAGE_SIZE));
+ struct page *pg =
+ vmalloc_to_page((void __force *)(buf +
+ (actual_pages * PAGE_SIZE)));
size_t bytes = PAGE_SIZE - off;
if (!pg) {
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 2d3e114f4a66..28ea8c3a4cba 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1209,7 +1209,9 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
/* The completion must point to the
** msgbuf. */
- completion->header = msgbuf;
+ completion->header =
+ (struct vchiq_header __force *)
+ msgbuf;
}
if ((completion->reason ==
--
2.17.1
_______________________________________________
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: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-05-19 0:53 UTC (permalink / raw)
To: Viresh Kumar
Cc: Devicetree List, Arnd Bergmann, Linux Kernel Mailing List,
Bjorn Andersson, Rob Herring, Sudeep Holla, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20200518073514.tjodf6qxg3wjzyb4@vireshk-i7>
On Mon, May 18, 2020 at 2:42 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 15-05-20, 11:46, Jassi Brar wrote:
> > As I asked you yesterday over the call, it may help if you could share
> > some numbers to back up the doomsday scenario.
>
> Yes, I have already asked Sudeep to get some numbers for this. He will
> get back to us.
>
Thanks, current bottleneck numbers and the patch/changes to improve
that, would help.
> > > - With the current approach it isn't possible to assign different bits
> > > (or doorbell numbers) to clients from DT and the only way of doing
> > > that without adding new bindings is by extending #mbox-cells to accept
> > > a value of 2 as done in this patch.
> > >
> > I am afraid you are confused. You can use bit/doorbell-6 by passing
> > 0x40 to mhu as the data to send.
>
> That's how the code will do it, right I agree. What I was asking was
> the way this information is passed from DT.
>
That is a client/protocol property and has nothing to do with the
controller dt node.
cheers!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64: Register modification during syscall entry/exit stop
From: Keno Fischer @ 2020-05-19 1:05 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Kyle Huey, Will Deacon, Oleg Nesterov,
Linux Kernel Mailing List
Continuing my theme of "weird things I encounter
while trying to use ptrace on arm64", I ran into the
effect of the following code in the syscall entry/exit
reporting:
```
/*
* A scratch register (ip(r12) on AArch32, x7 on AArch64) is
* used to denote syscall entry/exit:
*/
regno = (is_compat_task() ? 12 : 7);
saved_reg = regs->regs[regno];
regs->regs[regno] = dir;
```
This seems very weird to me. I can't think of any
other architecture that does something similar
(other than unicore32 apparently, but the ptrace
support there seems like it might have just been
copied from ARM). I'm able to work around this
in my application, but it adds another stumbling block.
Some examples of things that happen:
- Writes to x7 during syscall exit stops are ignored, so
if the ptracer tries to emulate a setjmp-type thing, it
might miss this register (ptracers sometimes like to do
this to manually serialize execution between different
threads, puppeteering a single thread of execution
between different register states).
- Reads from x7 are incorrect, so if the ptracer saves
a register state and later tries to set it back to the task,
it may get x7 incorrect, but user space may be expecting
the register to be preserved (when might this happen? -
consider a ptracer that wants to modify some syscall
arguments, it modifies the arguments, restarts the syscall
but then incurs a signal, so it tries to restore the original
registers to let userspace deal with the signal without
being confused - expect signal traps don't ignore x7
modifications, so x7 may have been unexpectedly
modified).
- We now have seccomp traps, which kind of look and
act like syscall-entry traps, but don't have this behavior,
so it's not particularly reliable for ptracers to use.
Furthermore, it seems unnecessary to me on modern
kernels. We now have PTRACE_GET_SYSCALL_INFO,
which exposes this information without lying to the ptracer
about the tracee's registers.
I understand, we can't just change this, since people may
be relying on it, but I would like to propose adding a ptrace
option (PTRACE_O_ARM_REGSGOOD?) that turns this
behavior off. Now, I don't think we currently have any other
arch-specific ptrace options, so maybe there is a different
option that would be preferable (e.g. could be a different
regset), but I do think it would be good to have a way to
operate on the real x7 value. As I said, I can work around it,
but hopefully I will be able to save a future implementer
some headache.
Keno
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Bjorn Andersson @ 2020-05-19 1:29 UTC (permalink / raw)
To: Viresh Kumar
Cc: devicetree, Arnd Bergmann, Jassi Brar, linux-kernel, Rob Herring,
Sudeep Holla, Frank Rowand, linux-arm-kernel
In-Reply-To: <0a50f0cf5593baeb628dc8606c523665e5e2ae6c.1589519600.git.viresh.kumar@linaro.org>
On Thu 14 May 22:17 PDT 2020, Viresh Kumar wrote:
> From: Sudeep Holla <sudeep.holla@arm.com>
>
> Hi Rob, Arnd and Jassi,
>
> This stuff has been doing rounds on the mailing list since several years
> now with no agreed conclusion by all the parties. And here is another
> attempt to get some feedback from everyone involved to close this once
> and for ever. Your comments will very much be appreciated.
>
> The ARM MHU is defined here in the TRM [1] for your reference, which
> states following:
>
> "The MHU drives the signal using a 32-bit register, with all 32
> bits logically ORed together. The MHU provides a set of
> registers to enable software to set, clear, and check the status
> of each of the bits of this register independently. The use of
> 32 bits for each interrupt line enables software to provide more
> information about the source of the interrupt. For example, each
> bit of the register can be associated with a type of event that
> can contribute to raising the interrupt."
>
Does this mean that there are 32 different signals and they are all ORed
into the same interrupt line to trigger software action when something
happens?
Or does it mean that this register is used to pass multi-bit information
and when any such information is passed an interrupt will be triggered?
If so, what does that information mean? How is it tied into other Linux
drivers/subsystems?
> On few other platforms, like qcom, similar doorbell mechanism is present
> with separate interrupt for each of the bits (that's how I understood
> it), while in case of ARM MHU, there is a single interrupt line for all
> the 32 bits. Also in case of ARM MHU, these registers and interrupts
> have 3 copies for different priority levels, i.e. low priority
> non-secure, high priority non-secure and secure channels.
>
In the Qualcomm case we have 32 bits in a register where each bit
written will trigger an interrupt elsewhere in the SoC, as such the
mailbox is purely write only and the "read" side is handled by some
interrupt-controller.
The three copies just sounds like 3 (or 3 * 32) different mailbox
channels.
> For ARM MHU, both the dt bindings and the Linux driver support 3
> channels for the different priorities right now and support sending a 32
> bit data on every transfer in a locked fashion, i.e. only one transfer
> can be done at once and the other have to wait for it to finish first.
>
> Here are the point of view of the parties involved on this subject:
>
> Jassi's viewpoint:
>
> - Virtualization of channels should be discouraged in software based on
> specific usecases of the application. This may invite other mailbox
> driver authors to ask for doing virtualization in their drivers.
>
> - In mailbox's terminology, every channel is equivalent to a signal,
> since there is only one signal generated here by the MHU, there should
> be only one channel per priority level.
>
> - The clients should send data (of just setting 1 bit or many in the 32
> bit word) using the existing mechanism as the delays due to
> serialization shouldn't be significant anyway.
>
> - The driver supports 90% of the users with the current implementation
> and it shouldn't be extended to support doorbell and implement two
> different modes by changing value of #mbox-cells field in bindings.
I interpret Jassi's view as this is a channel that passes 32 bit
"messages".
>
> Sudeep (ARM) and myself as well to some extent:
>
> - The hardware gives us the capability to write the register in
> parallel, i.e. we can write 0x800 and 0x400 together without any
> software locks, and so these 32 bits should be considered as separate
> channel even if only one interrupt is issued by the hardware finally.
> This shouldn't be called as virtualization of the channels, as the
> hardware supports this (as clearly mentioned in the TRM) and it takes
> care of handling the signal properly.
>
But if writes to the register is ORed together than it seems like the
hardware isn't supposed to pass multi-bit messages, but instead is
supposed to carry 32 individual signals - somewhat similar to the
Qualcomm block.
I don't see a problem with having a cascaded IRQ handler for incoming
notifications.
> - With serialization, if we use only one channel as today at every
> priority, if there are 5 requests to send signal to the receiver and
> the dvfs request is the last one in queue (which may be called from
> scheduler's hot path with fast switching), it unnecessarily needs to
> wait for the first four transfers to finish due to the software
> locking imposed by the mailbox framework. This adds additional delay,
> maybe of few ms only, which isn't required by the hardware but just by
> the software and few ms can be important in scheduler's hotpath.
>
So these 5 requests, are they conveyed by the signals [1,2,3,4,5] or
[BIT(0), BIT(1), BIT(2), BIT(3), BIT(4)]?
In the first case you have to serialize things given that e.g. signal 1
immediately followed by 2 is indistinguishable from 3.
If you signals are single-bit notifications then you don't need any
serialization.
Regards,
Bjorn
> - With the current approach it isn't possible to assign different bits
> (or doorbell numbers) to clients from DT and the only way of doing
> that without adding new bindings is by extending #mbox-cells to accept
> a value of 2 as done in this patch.
>
> Jassi and Sudeep, I hope I was able to represent both the view points
> properly here. Please correct me if I have made a mistake here.
>
> This is it. It would be nice to get the views of everyone now on this
> and how should this be handled.
>
> Thanks.
>
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515f/DDI0515F_juno_arm_development_platform_soc_trm.pdf , section 3.4.4, page 3-38.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/mailbox/arm-mhu.txt | 39 ++++++++++++++++++-
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
> index 4971f03f0b33..ba659bcc7109 100644
> --- a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
> +++ b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
> @@ -10,6 +10,15 @@ STAT register and the remote clears it after having read the data.
> The last channel is specified to be a 'Secure' resource, hence can't be
> used by Linux running NS.
>
> +The MHU drives the interrupt signal using a 32-bit register, with all
> +32-bits logically ORed together. It provides a set of registers to
> +enable software to set, clear and check the status of each of the bits
> +of this register independently. The use of 32 bits per interrupt line
> +enables software to provide more information about the source of the
> +interrupt. For example, each bit of the register can be associated with
> +a type of event that can contribute to raising the interrupt. Each of
> +the 32-bits can be used as "doorbell" to alert the remote processor.
> +
> Mailbox Device Node:
> ====================
>
> @@ -18,13 +27,21 @@ used by Linux running NS.
> - compatible: Shall be "arm,mhu" & "arm,primecell"
> - reg: Contains the mailbox register address range (base
> address and length)
> -- #mbox-cells Shall be 1 - the index of the channel needed.
> +- #mbox-cells Shall be 1 - the index of the channel needed when
> + not used as set of doorbell bits.
> + Shall be 2 - the index of the channel needed, and
> + the index of the doorbell bit within the channel
> + when used in doorbell mode.
> - interrupts: Contains the interrupt information corresponding to
> - each of the 3 links of MHU.
> + each of the 3 physical channels of MHU namely low
> + priority non-secure, high priority non-secure and
> + secure channels.
>
> Example:
> --------
>
> +1. Controller which doesn't support doorbells
> +
> mhu: mailbox@2b1f0000 {
> #mbox-cells = <1>;
> compatible = "arm,mhu", "arm,primecell";
> @@ -41,3 +58,21 @@ used by Linux running NS.
> reg = <0 0x2e000000 0x4000>;
> mboxes = <&mhu 1>; /* HP-NonSecure */
> };
> +
> +2. Controller which supports doorbells
> +
> + mhu: mailbox@2b1f0000 {
> + #mbox-cells = <2>;
> + compatible = "arm,mhu", "arm,primecell";
> + reg = <0 0x2b1f0000 0x1000>;
> + interrupts = <0 36 4>, /* LP-NonSecure */
> + <0 35 4>; /* HP-NonSecure */
> + clocks = <&clock 0 2 1>;
> + clock-names = "apb_pclk";
> + };
> +
> + mhu_client: scb@2e000000 {
> + compatible = "arm,scpi";
> + reg = <0 0x2e000000 0x200>;
> + mboxes = <&mhu 1 4>; /* HP-NonSecure 5th doorbell bit */
> + };
> --
> 2.25.0.rc1.19.g042ed3e048af
>
_______________________________________________
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] firmware: arm_sdei: Put the SDEI table after using it
From: Hanjun Guo @ 2020-05-19 1:53 UTC (permalink / raw)
To: James Morse; +Cc: linux-arm-kernel
In-Reply-To: <946c9fe8-b32c-2926-911c-886169d1f842@arm.com>
On 2020/5/19 2:59, James Morse wrote:
> Hi Hanjun,
>
> On 09/05/2020 11:52, Hanjun Guo wrote:
>> The acpi_get_table() should be coupled with acpi_put_table() if
>> the mapped table is not used for runtime after the initialization
>> to release the table mapping, put the SDEI table after using it.
>
> I thought this didn't really matter once ACPI had switched to its global mapping of the
> tables...
>
>
>> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
>> index 334c8be..5c42757 100644
>> --- a/drivers/firmware/arm_sdei.c
>> +++ b/drivers/firmware/arm_sdei.c
>> @@ -1113,6 +1113,7 @@ static bool __init sdei_present_acpi(void)
>> if (ACPI_FAILURE(status))
>> return false;
>>
>> + acpi_put_table(sdei_table_header);
>> pdev = platform_device_register_simple(sdei_driver.driver.name, 0, NULL,
>> 0);
>> if (IS_ERR(pdev))
>>
>
>
> This conflicts with Sudeep's patch that moved all this code. I'll rebase and repost it.
Thank you very much!
Regards,
Hanjun
_______________________________________________
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] ARM: dts: imx50: Add src node interrupt
From: Aisheng Dong @ 2020-05-19 1:55 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589806460-19592-1-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Monday, May 18, 2020 8:54 PM
>
> Interrupt is a required property according to SRC binding, add it for SRC node.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
_______________________________________________
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] ARM: dts: imx5: make src node name generic
From: Aisheng Dong @ 2020-05-19 1:56 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589806460-19592-2-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Monday, May 18, 2020 8:54 PM
> To: robh+dt@kernel.org; shawnguo@kernel.org; s.hauer@pengutronix.de;
> kernel@pengutronix.de; festevam@gmail.com; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: [PATCH 2/2] ARM: dts: imx5: make src node name generic
>
> Node name should be generic, use "reset-controller" instead of "src" for
> i.MX5 SoCs src nodes.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
_______________________________________________
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 V2] dt-bindings: clock: Convert i.MX7D clock to json-schema
From: Aisheng Dong @ 2020-05-19 2:01 UTC (permalink / raw)
To: Anson Huang, mturquette@baylibre.com, sboyd@kernel.org,
robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Frank Li,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589813554-20929-1-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Monday, May 18, 2020 10:53 PM
>
> Convert the i.MX7D clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - Update maintainer's e-mail address.
> ---
> .../devicetree/bindings/clock/imx7d-clock.txt | 13 -----
> .../devicetree/bindings/clock/imx7d-clock.yaml | 64
> ++++++++++++++++++++++
> 2 files changed, 64 insertions(+), 13 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/clock/imx7d-clock.txt
> create mode 100644
> Documentation/devicetree/bindings/clock/imx7d-clock.yaml
>
> diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.txt
> b/Documentation/devicetree/bindings/clock/imx7d-clock.txt
> deleted file mode 100644
> index 9d3026d..0000000
> --- a/Documentation/devicetree/bindings/clock/imx7d-clock.txt
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -* Clock bindings for Freescale i.MX7 Dual
> -
> -Required properties:
> -- compatible: Should be "fsl,imx7d-ccm"
> -- reg: Address and length of the register set
> -- #clock-cells: Should be <1>
> -- clocks: list of clock specifiers, must contain an entry for each required
> - entry in clock-names
> -- clock-names: should include entries "ckil", "osc"
> -
> -The clock consumer should specify the desired clock by having the clock -ID in
> its "clocks" phandle cell. See include/dt-bindings/clock/imx7d-clock.h
> -for the full list of i.MX7 Dual clock IDs.
> diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
> b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
> new file mode 100644
> index 0000000..8cd0573
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +
> +title: Clock bindings for Freescale i.MX7 Dual
> +
> +maintainers:
> + - Frank Li <Frank.Li@nxp.com>
> + - Anson Huang <Anson.Huang@nxp.com>
> +
> +description: |
> + The clock consumer should specify the desired clock by having the
> +clock
> + ID in its "clocks" phandle cell. See
> +include/dt-bindings/clock/imx7d-clock.h
> + for the full list of i.MX7 Dual clock IDs.
> +
> +properties:
> + compatible:
> + const: fsl,imx7d-ccm
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + items:
> + - description: CCM interrupt request 1
> + - description: CCM interrupt request 2
Do we have a more specific description from RM?
Otherwise, I'm fine with this patch.
> + maxItems: 2
> +
> + '#clock-cells':
> + const: 1
> +
> + clocks:
> + items:
> + - description: 32k osc
> + - description: 24m osc
> +
> + clock-names:
> + items:
> + - const: ckil
> + - const: osc
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - '#clock-cells'
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + clock-controller@30380000 {
> + compatible = "fsl,imx7d-ccm";
> + reg = <0x30380000 0x10000>;
> + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> + #clock-cells = <1>;
> + clocks = <&ckil>, <&osc>;
> + clock-names = "ckil", "osc";
> + };
> --
> 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
* ✅ PASS: Test report for kernel 5.7.0-rc6-93d53d2.cki (arm-next)
From: CKI Project @ 2020-05-19 2:14 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Commit: 93d53d278d01 - Merge branch 'for-next/scs' into for-kernelci
The results of these automated tests are provided below.
Overall result: PASSED
Merge: OK
Compile: OK
Tests: OK
All kernel binaries, config files, and logs are available for download here:
https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=datawarehouse/2020/05/18/571360
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 1 architecture:
aarch64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ selinux-policy: serge-testsuite
✅ storage: software RAID testing
✅ stress: stress-ng
🚧 ✅ IPMI driver test
🚧 ✅ IPMItool loop stress test
🚧 ✅ Storage blktests
Host 2:
✅ Boot test
✅ Podman system integration test - as root
✅ Podman system integration test - as user
✅ LTP
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Networking bridge: sanity
✅ Ethernet drivers sanity
✅ Networking socket: fuzz
✅ Networking: igmp conformance test
✅ Networking route: pmtu
✅ Networking route_func - local
✅ Networking route_func - forward
✅ Networking TCP: keepalive test
✅ Networking UDP: socket
✅ Networking tunnel: geneve basic test
✅ Networking tunnel: gre basic
✅ L2TP basic test
✅ Networking tunnel: vxlan basic
✅ Networking ipsec: basic netns - transport
✅ Networking ipsec: basic netns - tunnel
✅ Libkcapi AF_ALG test
✅ ALSA PCM loopback test
✅ ALSA Control (mixer) Userspace Element test
✅ storage: SCSI VPD
🚧 ✅ CIFS Connectathon
🚧 ✅ POSIX pjd-fstest suites
🚧 ✅ jvm - DaCapo Benchmark Suite
🚧 ✅ jvm - jcstress tests
🚧 ✅ Memory function: kaslr
🚧 ✅ audit: audit testsuite test
🚧 ✅ trace: ftrace/tracer
Test sources: https://github.com/CKI-project/tests-beaker
💚 Pull requests are welcome for new tests or improvements to existing tests!
Aborted tests
-------------
Tests that didn't complete running successfully are marked with ⚡⚡⚡.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.
Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.
Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ⏱.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 0/4] kasan: memorize and print call_rcu stack
From: Walter Wu @ 2020-05-19 2:23 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Paul E . McKenney, Josh Triplett,
Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Andrew Morton
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
This patchset improves KASAN reports by making them to have
call_rcu() call stack information. It is useful for programmers
to solve use-after-free or double-free memory issue.
The KASAN report was as follows(cleaned up slightly):
BUG: KASAN: use-after-free in kasan_rcu_reclaim+0x58/0x60
Freed by task 0:
kasan_save_stack+0x24/0x50
kasan_set_track+0x24/0x38
kasan_set_free_info+0x18/0x20
__kasan_slab_free+0x10c/0x170
kasan_slab_free+0x10/0x18
kfree+0x98/0x270
kasan_rcu_reclaim+0x1c/0x60
Last one call_rcu() call stack:
kasan_save_stack+0x24/0x50
kasan_record_aux_stack+0xbc/0xd0
call_rcu+0x8c/0x580
kasan_rcu_uaf+0xf4/0xf8
Generic KASAN will record the last two call_rcu() call stacks and
print up to 2 call_rcu() call stacks in KASAN report. it is only
suitable for generic KASAN.
This feature considers the size of struct kasan_alloc_meta and
kasan_free_meta, we try to optimize the structure layout and size
, let it get better memory consumption.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
[2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
Changes since v2:
- remove new config option, default enable it in generic KASAN
- test this feature in SLAB/SLUB, it is pass.
- modify macro to be more clearly
- modify documentation
Changes since v3:
- change recording from first/last to the last two call stacks
- move free track into kasan free meta
- init slab_free_meta on object slot creation
- modify documentation
Changes since v4:
- change variable name to be more clearly
- remove the redundant condition
- remove init free meta-data and increasing object condition
Walter Wu (4):
rcu/kasan: record and print call_rcu() call stack
kasan: record and print the free track
kasan: add tests for call_rcu stack recording
kasan: update documentation for generic kasan
Documentation/dev-tools/kasan.rst | 3 +++
include/linux/kasan.h | 2 ++
kernel/rcu/tree.c | 2 ++
lib/Kconfig.kasan | 2 ++
lib/test_kasan.c | 30 ++++++++++++++++++++++++++++++
mm/kasan/common.c | 26 ++++----------------------
mm/kasan/generic.c | 37 +++++++++++++++++++++++++++++++++++++
mm/kasan/kasan.h | 17 +++++++++++++++++
mm/kasan/report.c | 36 ++++++++++++++++++++----------------
mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
10 files changed, 154 insertions(+), 38 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/4] kasan: record and print the free track
From: Walter Wu @ 2020-05-19 2:25 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Move free track from slub alloc meta-data to slub free meta-data in
order to make struct kasan_free_meta size is 16 bytes. It is a good
size because it is the minimal redzone size and a good number of
alignment.
For free track in generic KASAN, we do the modification in struct
kasan_alloc_meta and kasan_free_meta:
- remove free track from kasan_alloc_meta.
- add free track into kasan_free_meta.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
---
mm/kasan/common.c | 22 ++--------------------
mm/kasan/generic.c | 18 ++++++++++++++++++
mm/kasan/kasan.h | 7 +++++++
mm/kasan/report.c | 20 --------------------
mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
5 files changed, 64 insertions(+), 40 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 8bc618289bb1..47b53912f322 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
return stack_depot_save(entries, nr_entries, flags);
}
-static inline void set_track(struct kasan_track *track, gfp_t flags)
+void kasan_set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
track->stack = kasan_save_stack(flags);
@@ -299,24 +299,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
return (void *)object + cache->kasan_info.free_meta_offset;
}
-
-static void kasan_set_free_info(struct kmem_cache *cache,
- void *object, u8 tag)
-{
- struct kasan_alloc_meta *alloc_meta;
- u8 idx = 0;
-
- alloc_meta = get_alloc_info(cache, object);
-
-#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
- idx = alloc_meta->free_track_idx;
- alloc_meta->free_pointer_tag[idx] = tag;
- alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
-#endif
-
- set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
-}
-
void kasan_poison_slab(struct page *page)
{
unsigned long i;
@@ -492,7 +474,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
KASAN_KMALLOC_REDZONE);
if (cache->flags & SLAB_KASAN)
- set_track(&get_alloc_info(cache, object)->alloc_track, flags);
+ kasan_set_track(&get_alloc_info(cache, object)->alloc_track, flags);
return set_tag(object, tag);
}
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 3372bdcaf92a..763d8a13e0ac 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -344,3 +344,21 @@ void kasan_record_aux_stack(void *addr)
alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
}
+
+void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_free_meta *free_meta;
+
+ free_meta = get_free_info(cache, object);
+ kasan_set_track(&free_meta->free_track, GFP_NOWAIT);
+}
+
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_free_meta *free_meta;
+
+ free_meta = get_free_info(cache, object);
+ return &free_meta->free_track;
+}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index a7391bc83070..ad897ec36545 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -127,6 +127,9 @@ struct kasan_free_meta {
* Otherwise it might be used for the allocator freelist.
*/
struct qlist_node quarantine_link;
+#ifdef CONFIG_KASAN_GENERIC
+ struct kasan_track free_track;
+#endif
};
struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
@@ -168,6 +171,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
struct page *kasan_addr_to_page(const void *addr);
depot_stack_handle_t kasan_save_stack(gfp_t flags);
+void kasan_set_track(struct kasan_track *track, gfp_t flags);
+void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag);
#if defined(CONFIG_KASAN_GENERIC) && \
(defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 6f8f2bf8f53b..96d2657fe70f 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -159,26 +159,6 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
(void *)(object_addr + cache->object_size));
}
-static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
- void *object, u8 tag)
-{
- struct kasan_alloc_meta *alloc_meta;
- int i = 0;
-
- alloc_meta = get_alloc_info(cache, object);
-
-#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
- for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
- if (alloc_meta->free_pointer_tag[i] == tag)
- break;
- }
- if (i == KASAN_NR_FREE_STACKS)
- i = alloc_meta->free_track_idx;
-#endif
-
- return &alloc_meta->free_track[i];
-}
-
#ifdef CONFIG_KASAN_GENERIC
static void print_stack(depot_stack_handle_t stack)
{
diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
index 25b7734e7013..201dee5d6ae0 100644
--- a/mm/kasan/tags.c
+++ b/mm/kasan/tags.c
@@ -162,3 +162,40 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
kasan_poison_shadow((void *)addr, size, tag);
}
EXPORT_SYMBOL(__hwasan_tag_memory);
+
+void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ u8 idx = 0;
+
+ alloc_meta = get_alloc_info(cache, object);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+ idx = alloc_meta->free_track_idx;
+ alloc_meta->free_pointer_tag[idx] = tag;
+ alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
+#endif
+
+ kasan_set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
+}
+
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ int i = 0;
+
+ alloc_meta = get_alloc_info(cache, object);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+ for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
+ if (alloc_meta->free_pointer_tag[i] == tag)
+ break;
+ }
+ if (i == KASAN_NR_FREE_STACKS)
+ i = alloc_meta->free_track_idx;
+#endif
+
+ return &alloc_meta->free_track[i];
+}
--
2.18.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
* [PATCH v4 3/4] kasan: add tests for call_rcu stack recording
From: Walter Wu @ 2020-05-19 2:26 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Test call_rcu() call stack recording and verify whether it correctly
is printed in KASAN report.
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
---
lib/test_kasan.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index e3087d90e00d..6e5fb05d42d8 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -792,6 +792,35 @@ static noinline void __init vmalloc_oob(void)
static void __init vmalloc_oob(void) {}
#endif
+static struct kasan_rcu_info {
+ int i;
+ struct rcu_head rcu;
+} *global_ptr;
+
+static noinline void __init kasan_rcu_reclaim(struct rcu_head *rp)
+{
+ struct kasan_rcu_info *fp = container_of(rp,
+ struct kasan_rcu_info, rcu);
+
+ kfree(fp);
+ fp->i = 1;
+}
+
+static noinline void __init kasan_rcu_uaf(void)
+{
+ struct kasan_rcu_info *ptr;
+
+ pr_info("use-after-free in kasan_rcu_reclaim\n");
+ ptr = kmalloc(sizeof(struct kasan_rcu_info), GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ global_ptr = rcu_dereference_protected(ptr, NULL);
+ call_rcu(&global_ptr->rcu, kasan_rcu_reclaim);
+}
+
static int __init kmalloc_tests_init(void)
{
/*
@@ -839,6 +868,7 @@ static int __init kmalloc_tests_init(void)
kasan_bitops();
kmalloc_double_kzfree();
vmalloc_oob();
+ kasan_rcu_uaf();
kasan_restore_multi_shot(multishot);
--
2.18.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
* [PATCH v4 4/4] kasan: update documentation for generic kasan
From: Walter Wu @ 2020-05-19 2:26 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Jonathan Corbet
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Generic KASAN will support to record the last two call_rcu() call
stacks and print them in KASAN report. So need to update documentation.
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
---
Documentation/dev-tools/kasan.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index c652d740735d..fede42e6536b 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -193,6 +193,9 @@ function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
+Generic KASAN prints up to 2 call_rcu() call stacks in reports, the last one
+and the second to last.
+
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
--
2.18.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
* [PATCH v4 1/4] rcu/kasan: record and print call_rcu() call stack
From: Walter Wu @ 2020-05-19 2:23 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Paul E . McKenney, Josh Triplett,
Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Andrew Morton
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
This feature will record the last two call_rcu() call stacks and
prints up to 2 call_rcu() call stacks in KASAN report.
When call_rcu() is called, we store the call_rcu() call stack into
slub alloc meta-data, so that the KASAN report can print rcu stack.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
[2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
---
include/linux/kasan.h | 2 ++
kernel/rcu/tree.c | 2 ++
lib/Kconfig.kasan | 2 ++
mm/kasan/common.c | 4 ++--
mm/kasan/generic.c | 19 +++++++++++++++++++
mm/kasan/kasan.h | 10 ++++++++++
mm/kasan/report.c | 24 ++++++++++++++++++++++++
7 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 31314ca7c635..23b7ee00572d 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
void kasan_cache_shrink(struct kmem_cache *cache);
void kasan_cache_shutdown(struct kmem_cache *cache);
+void kasan_record_aux_stack(void *ptr);
#else /* CONFIG_KASAN_GENERIC */
static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
+static inline void kasan_record_aux_stack(void *ptr) {}
#endif /* CONFIG_KASAN_GENERIC */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 06548e2ebb72..36a4ff7f320b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -57,6 +57,7 @@
#include <linux/slab.h>
#include <linux/sched/isolation.h>
#include <linux/sched/clock.h>
+#include <linux/kasan.h>
#include "../time/tick-internal.h"
#include "tree.h"
@@ -2668,6 +2669,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
head->func = func;
head->next = NULL;
local_irq_save(flags);
+ kasan_record_aux_stack(head);
rdp = this_cpu_ptr(&rcu_data);
/* Add the callback to our list. */
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 81f5464ea9e1..4e83cf6e3caa 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -58,6 +58,8 @@ config KASAN_GENERIC
For better error detection enable CONFIG_STACKTRACE.
Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
(the resulting kernel does not boot).
+ In generic mode KASAN prints the last two call_rcu() call stacks in
+ reports.
config KASAN_SW_TAGS
bool "Software tag-based mode"
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2906358e42f0..8bc618289bb1 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -41,7 +41,7 @@
#include "kasan.h"
#include "../slab.h"
-static inline depot_stack_handle_t save_stack(gfp_t flags)
+depot_stack_handle_t kasan_save_stack(gfp_t flags)
{
unsigned long entries[KASAN_STACK_DEPTH];
unsigned int nr_entries;
@@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
static inline void set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
- track->stack = save_stack(flags);
+ track->stack = kasan_save_stack(flags);
}
void kasan_enable_current(void)
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 56ff8885fe2e..3372bdcaf92a 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -325,3 +325,22 @@ DEFINE_ASAN_SET_SHADOW(f2);
DEFINE_ASAN_SET_SHADOW(f3);
DEFINE_ASAN_SET_SHADOW(f5);
DEFINE_ASAN_SET_SHADOW(f8);
+
+void kasan_record_aux_stack(void *addr)
+{
+ struct page *page = kasan_addr_to_page(addr);
+ struct kmem_cache *cache;
+ struct kasan_alloc_meta *alloc_info;
+ void *object;
+
+ if (!(page && PageSlab(page)))
+ return;
+
+ cache = page->slab_cache;
+ object = nearest_obj(cache, page, addr);
+ alloc_info = get_alloc_info(cache, object);
+
+ /* record the last two call_rcu() call stacks */
+ alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
+ alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
+}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index e8f37199d885..a7391bc83070 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -104,7 +104,15 @@ struct kasan_track {
struct kasan_alloc_meta {
struct kasan_track alloc_track;
+#ifdef CONFIG_KASAN_GENERIC
+ /*
+ * call_rcu() call stack is stored into struct kasan_alloc_meta.
+ * The free stack is stored into struct kasan_free_meta.
+ */
+ depot_stack_handle_t aux_stack[2];
+#else
struct kasan_track free_track[KASAN_NR_FREE_STACKS];
+#endif
#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
u8 free_pointer_tag[KASAN_NR_FREE_STACKS];
u8 free_track_idx;
@@ -159,6 +167,8 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
struct page *kasan_addr_to_page(const void *addr);
+depot_stack_handle_t kasan_save_stack(gfp_t flags);
+
#if defined(CONFIG_KASAN_GENERIC) && \
(defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 80f23c9da6b0..6f8f2bf8f53b 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -179,6 +179,17 @@ static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
return &alloc_meta->free_track[i];
}
+#ifdef CONFIG_KASAN_GENERIC
+static void print_stack(depot_stack_handle_t stack)
+{
+ unsigned long *entries;
+ unsigned int nr_entries;
+
+ nr_entries = stack_depot_fetch(stack, &entries);
+ stack_trace_print(entries, nr_entries, 0);
+}
+#endif
+
static void describe_object(struct kmem_cache *cache, void *object,
const void *addr, u8 tag)
{
@@ -192,6 +203,19 @@ static void describe_object(struct kmem_cache *cache, void *object,
free_track = kasan_get_free_track(cache, object, tag);
print_track(free_track, "Freed");
pr_err("\n");
+
+#ifdef CONFIG_KASAN_GENERIC
+ if (alloc_info->aux_stack[0]) {
+ pr_err("Last one call_rcu() call stack:\n");
+ print_stack(alloc_info->aux_stack[0]);
+ pr_err("\n");
+ }
+ if (alloc_info->aux_stack[1]) {
+ pr_err("Second to last call_rcu() call stack:\n");
+ print_stack(alloc_info->aux_stack[1]);
+ pr_err("\n");
+ }
+#endif
}
describe_object_addr(cache, object, addr);
--
2.18.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 1/3] dt-bindings: timer: Convert i.MX GPT to json-schema
From: Aisheng Dong @ 2020-05-19 2:46 UTC (permalink / raw)
To: Anson Huang, daniel.lezcano@linaro.org, tglx@linutronix.de,
robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Jacky Bai,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: dl-linux-imx
In-Reply-To: <1589813260-20036-2-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Monday, May 18, 2020 10:48 PM
>
> Convert the i.MX GPT binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/timer/fsl,imxgpt.txt | 45 ---------
> .../devicetree/bindings/timer/fsl,imxgpt.yaml | 109
> +++++++++++++++++++++
> 2 files changed, 109 insertions(+), 45 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> create mode 100644
> Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> deleted file mode 100644
> index 5d8fd5b..0000000
> --- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> +++ /dev/null
> @@ -1,45 +0,0 @@
> -Freescale i.MX General Purpose Timer (GPT)
> -
> -Required properties:
> -
> -- compatible : should be one of following:
> - for i.MX1:
> - - "fsl,imx1-gpt";
> - for i.MX21:
> - - "fsl,imx21-gpt";
> - for i.MX27:
> - - "fsl,imx27-gpt", "fsl,imx21-gpt";
> - for i.MX31:
> - - "fsl,imx31-gpt";
> - for i.MX25:
> - - "fsl,imx25-gpt", "fsl,imx31-gpt";
> - for i.MX50:
> - - "fsl,imx50-gpt", "fsl,imx31-gpt";
> - for i.MX51:
> - - "fsl,imx51-gpt", "fsl,imx31-gpt";
> - for i.MX53:
> - - "fsl,imx53-gpt", "fsl,imx31-gpt";
> - for i.MX6Q:
> - - "fsl,imx6q-gpt", "fsl,imx31-gpt";
> - for i.MX6DL:
> - - "fsl,imx6dl-gpt";
> - for i.MX6SL:
> - - "fsl,imx6sl-gpt", "fsl,imx6dl-gpt";
> - for i.MX6SX:
> - - "fsl,imx6sx-gpt", "fsl,imx6dl-gpt";
> -- reg : specifies base physical address and size of the registers.
> -- interrupts : should be the gpt interrupt.
> -- clocks : the clocks provided by the SoC to drive the timer, must contain
> - an entry for each entry in clock-names.
> -- clock-names : must include "ipg" entry first, then "per" entry.
> -
> -Example:
> -
> -gpt1: timer@10003000 {
> - compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
> - reg = <0x10003000 0x1000>;
> - interrupts = <26>;
> - clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>,
> - <&clks IMX27_CLK_PER1_GATE>;
> - clock-names = "ipg", "per";
> -};
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
> b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
> new file mode 100644
> index 0000000..5c7186b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +
> +title: Freescale i.MX General Purpose Timer (GPT)
> +
> +maintainers:
> + - Sascha Hauer <s.hauer@pengutronix.de>
> +
> +properties:
> + compatible:
> + oneOf:
> + - description: on i.MX1 the following compatible must be specified
Such a description seems not necessary in order to make the doc more clean
> + items:
> + - const: "fsl,imx1-gpt"
> +
> + - description: on i.MX21 the following compatible must be specified
> + items:
> + - const: "fsl,imx21-gpt"
> +
> + - description: on i.MX27 the following compatibles must be specified
> + items:
> + - const: "fsl,imx27-gpt"
> + - const: "fsl,imx21-gpt"
> +
> + - description: on i.MX31 the following compatible must be specified
> + items:
> + - const: "fsl,imx31-gpt"
> +
> + - description: on i.MX25 the following compatibles must be specified
> + items:
> + - const: "fsl,imx25-gpt"
> + - const: "fsl,imx31-gpt"
> +
> + - description: on i.MX50 the following compatibles must be specified
> + items:
> + - const: "fsl,imx50-gpt"
> + - const: "fsl,imx31-gpt"
> +
> + - description: on i.MX51 the following compatibles must be specified
> + items:
> + - const: "fsl,imx51-gpt"
> + - const: "fsl,imx31-gpt"
> +
> + - description: on i.MX53 the following compatibles must be specified
> + items:
> + - const: "fsl,imx53-gpt"
> + - const: "fsl,imx31-gpt"
> +
> + - description: on i.MX6Q the following compatibles must be specified
> + items:
> + - const: "fsl,imx6q-gpt"
> + - const: "fsl,imx31-gpt"
> +
> + - description: on i.MX6DL the following compatible must be specified
> + items:
> + - const: "fsl,imx6dl-gpt"
> +
> + - description: on i.MX6SL the following compatibles must be specified
> + items:
> + - const: "fsl,imx6sl-gpt"
> + - const: "fsl,imx6dl-gpt"
> +
> + - description: on i.MX6SX the following compatibles must be specified
> + items:
> + - const: "fsl,imx6sx-gpt"
> + - const: "fsl,imx6dl-gpt"
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: SoC GPT ipg clock
> + - description: SoC GPT per clock
> + maxItems: 2
maxItems is not needed
> +
> + clock-names:
> + items:
> + - const: ipg
> + - const: per
> + maxItems: 2
Ditto
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx27-clock.h>
> +
> + timer@10003000 {
> + compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
> + reg = <0x10003000 0x1000>;
> + interrupts = <26>;
> + clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>,
> + <&clks IMX27_CLK_PER1_GATE>;
> + clock-names = "ipg", "per";
> + };
> --
> 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 2/3] dt-bindings: timer: Convert i.MX TPM to json-schema
From: Aisheng Dong @ 2020-05-19 2:49 UTC (permalink / raw)
To: Anson Huang, daniel.lezcano@linaro.org, tglx@linutronix.de,
robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Jacky Bai,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: dl-linux-imx
In-Reply-To: <1589813260-20036-3-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Monday, May 18, 2020 10:48 PM
>
> Convert the i.MX TPM binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/timer/nxp,tpm-timer.txt | 28 ----------
> .../devicetree/bindings/timer/nxp,tpm-timer.yaml | 63
> ++++++++++++++++++++++
> 2 files changed, 63 insertions(+), 28 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
> create mode 100644
> Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
>
> diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
> b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
> deleted file mode 100644
> index f82087b..0000000
> --- a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -NXP Low Power Timer/Pulse Width Modulation Module (TPM)
> -
> -The Timer/PWM Module (TPM) supports input capture, output compare, -and
> the generation of PWM signals to control electric motor and power
> -management applications. The counter, compare and capture registers -are
> clocked by an asynchronous clock that can remain enabled in low -power modes.
> TPM can support global counter bus where one TPM drives -the counter bus for
> the others, provided bit width is the same.
> -
> -Required properties:
> -
> -- compatible : should be "fsl,imx7ulp-tpm"
> -- reg : Specifies base physical address and size of the register sets
> - for the clock event device and clock source device.
> -- interrupts : Should be the clock event device interrupt.
> -- clocks : The clocks provided by the SoC to drive the timer, must contain
> - an entry for each entry in clock-names.
> -- clock-names : Must include the following entries: "ipg" and "per".
> -
> -Example:
> -tpm5: tpm@40260000 {
> - compatible = "fsl,imx7ulp-tpm";
> - reg = <0x40260000 0x1000>;
> - interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clks IMX7ULP_CLK_NIC1_BUS_DIV>,
> - <&clks IMX7ULP_CLK_LPTPM5>;
> - clock-names = "ipg", "per";
> -};
> diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
> b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
> new file mode 100644
> index 0000000..0d34610
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
[...]
> +
> +title: NXP Low Power Timer/Pulse Width Modulation Module (TPM)
> +
> +maintainers:
> + - Dong Aisheng <aisheng.dong@nxp.com>
> +
> +description: |
> + The Timer/PWM Module (TPM) supports input capture, output compare,
> + and the generation of PWM signals to control electric motor and power
> + management applications. The counter, compare and capture registers
> + are clocked by an asynchronous clock that can remain enabled in low
> + power modes. TPM can support global counter bus where one TPM drives
> + the counter bus for the others, provided bit width is the same.
> +
> +properties:
> + compatible:
> + const: fsl,imx7ulp-tpm
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: SoC TPM ipg clock
> + - description: SoC TPM per clock
> + maxItems: 2
Unneeded line
> +
> + clock-names:
> + items:
> + - const: ipg
> + - const: per
> + maxItems: 2
Ditto
Otherwise:
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx7ulp-clock.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + timer@40260000 {
> + compatible = "fsl,imx7ulp-tpm";
> + reg = <0x40260000 0x1000>;
> + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>,
> + <&pcc2 IMX7ULP_CLK_LPTPM5>;
> + clock-names = "ipg", "per";
> + };
> --
> 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 V3 07/15] arch/kunmap_atomic: Consolidate duplicate code
From: Guenter Roeck @ 2020-05-19 2:50 UTC (permalink / raw)
To: Ira Weiny
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200519000352.GF3025231@iweiny-DESK2.sc.intel.com>
Hi Ira,
On 5/18/20 5:03 PM, Ira Weiny wrote:
> On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
>> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
>>> On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
>>>> On Thu, May 07, 2020 at 07:59:55AM -0700, ira.weiny@intel.com wrote:
>>>>> From: Ira Weiny <ira.weiny@intel.com>
>>>>>
>>>>> Every single architecture (including !CONFIG_HIGHMEM) calls...
>>>>>
>>>>> pagefault_enable();
>>>>> preempt_enable();
>>>>>
>>>>> ... before returning from __kunmap_atomic(). Lift this code into the
>>>>> kunmap_atomic() macro.
>>>>>
>>>>> While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
>>>>> be consistent.
>>>>>
>>>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>>>> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>>>>
>>>> This patch results in:
>>>>
>>>> Starting init: /bin/sh exists but couldn't execute it (error -14)
>>>>
>>>> when trying to boot microblazeel:petalogix-ml605 in qemu.
>>>
>>> Thanks for the report. I'm not readily seeing the issue.
>>>
>>> Do you have a kernel config? Specifically is CONFIG_HIGHMEM set?
>>>
>> See below. Yes, CONFIG_HIGHMEM is set.
>>
>> The scripts used to build and boot the image are at:
>>
>> https://github.com/groeck/linux-build-test/tree/master/rootfs/microblazeel
>
> Despite finding the obvious error earlier today I've still been trying to get
> this to work.
>
> I had to make some slight modifications to use the 0-day cross compile build
> and my local qemu build. But those were pretty minor modifications. I'm
> running on x86_64 host.
>
> With those slight mods to the scripts I get the following error even without my
> patch set on 5.7-rc4. I have 1 cpu pegged at 100% while it is running... Is
> there anything I can do to get more debug output? Perhaps I just need to let
> it run longer?
>
I don't think so. Try running it with "-d" parameter (run-qemu-microblazeel.sh
-d petalogix-s3adsp1800); that gives you the qemu command line. Once it says
"running", abort the script and execute qemu directly. Oh, and please update
the repository; turns out I didn't push for a while and made a number of
changes.
My compiler was compiled with buildroot (a long time ago). I don't recall if
it needed something special in the configuration, unfortunately.
Guenter
> Thanks,
> Ira
>
> 16:46:54 > ../linux-build-test/rootfs/microblazeel/run-qemu-microblazeel.sh
> Build reference: v5.7-rc4-2-g7c2411d7fb6a
>
> Building microblaze:petalogix-s3adsp1800:qemu_microblazeel_defconfig ...
> running ................ failed (silent)
> ------------
> qemu log:
> qemu-system-microblazeel: terminating on signal 15 from pid 3277686 (/bin/bash)
> ------------
> Building microblaze:petalogix-ml605:qemu_microblazeel_ml605_defconfig ...
> running ................ failed (silent)
> ------------
> qemu log:
> qemu-system-microblazeel: terminating on signal 15 from pid 3277686 (/bin/bash)
> ------------
>
> <env changes>
> 16:47:23 > git di
> diff --git a/rootfs/microblazeel/run-qemu-microblazeel.sh b/rootfs/microblazeel/run-qemu-microblazeel.sh
> index 68d4de39ab50..0d6a4f85308f 100755
> --- a/rootfs/microblazeel/run-qemu-microblazeel.sh
> +++ b/rootfs/microblazeel/run-qemu-microblazeel.sh
> @@ -3,7 +3,8 @@
> dir=$(cd $(dirname $0); pwd)
> . ${dir}/../scripts/common.sh
>
> -QEMU=${QEMU:-${QEMU_BIN}/qemu-system-microblazeel}
> +#QEMU=${QEMU:-${QEMU_BIN}/qemu-system-microblazeel}
> +QEMU=/home/iweiny/dev/qemu/microblazeel-softmmu/qemu-system-microblazeel
> PREFIX=microblazeel-linux-
> ARCH=microblaze
> PATH_MICROBLAZE=/opt/kernel/microblazeel/gcc-4.9.1/usr/bin
> diff --git a/rootfs/scripts/common.sh b/rootfs/scripts/common.sh
> index 8fa6a9be2b2f..c4550a27beaa 100644
> --- a/rootfs/scripts/common.sh
> +++ b/rootfs/scripts/common.sh
> @@ -1,5 +1,9 @@
> #!/bin/bash
>
> +# Set up make.cross
> +export COMPILER_INSTALL_PATH=$HOME/0day
> +export GCC_VERSION=6.5.0
> +
> # Set the following variable to true to skip DC395/AM53C97 build tests
> __skip_dc395=0
>
> @@ -569,7 +573,7 @@ doclean()
> then
> git clean -x -d -f -q
> else
> - make ARCH=${ARCH} mrproper >/dev/null 2>&1
> + make.cross ARCH=${ARCH} mrproper >/dev/null 2>&1
> fi
> }
>
> @@ -669,7 +673,7 @@ __setup_config()
> cp ${__progdir}/${defconfig} arch/${arch}/configs
> fi
>
> - if ! make ARCH=${ARCH} CROSS_COMPILE=${PREFIX} ${defconfig} >/dev/null 2>&1 </dev/null; then
> + if ! make.cross ARCH=${ARCH} ${defconfig} >/dev/null 2>&1 </dev/null; then
> return 2
> fi
>
> @@ -687,7 +691,7 @@ __setup_config()
> if [[ "${rel}" = "v3.16" ]]; then
> target="oldconfig"
> fi
> - if ! make ARCH=${ARCH} CROSS_COMPILE=${PREFIX} ${target} >/dev/null 2>&1 </dev/null; then
> + if ! make.cross ARCH=${ARCH} ${target} >/dev/null 2>&1 </dev/null; then
> return 1
> fi
> fi
> @@ -1038,7 +1042,7 @@ dosetup()
> rootfs="$(setup_rootfs ${dynamic} ${rootfs})"
> __common_fixups "${fixups}" "${rootfs}"
>
> - make -j${maxload} ARCH=${ARCH} CROSS_COMPILE=${PREFIX} ${EXTRAS} </dev/null >/dev/null 2>${logfile}
> + make.cross -j${maxload} ARCH=${ARCH} ${EXTRAS} </dev/null >/dev/null 2>${logfile}
> rv=$?
> if [ ${rv} -ne 0 ]
> then
>
> </env changes>
>
_______________________________________________
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