* Re: [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
From: Sylwester Nawrocki @ 2020-06-03 9:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, cw00.choi, myungjoo.ham, georgi.djakov,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200602082118.GB8216@kozik-lap>
On 02.06.2020 10:21, Krzysztof Kozlowski wrote:
>> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
>> +{
>> + struct of_phandle_args args;
>> + int num, ret;
>> +
>> + num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
>> + "#interconnect-cells");
>> + if (num != 1)
>> + return NULL; /* parent nodes are optional */
>> +
>> + ret = of_parse_phandle_with_args(np, "samsung,interconnect-parent",
>> + "#interconnect-cells", 0, &args);
>> + if (ret < 0)
>> + return ERR_PTR(ret);
>> +
>> + of_node_put(args.np);
>> +
>> + return of_icc_get_from_provider(&args);
> I think of_node_put() should happen after of_icc_get_from_provider().
Indeed, thanks, I will amend that. It seems the node reference count decrementing
is often not done properly after existing calls to of_parse_phandle_with_args().
--
Thanks,
Sylwester
_______________________________________________
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] [RFC] clk: sprd: fix compile-testing
From: Chunyan Zhang @ 2020-06-03 9:17 UTC (permalink / raw)
To: Arnd Bergmann, sboyd
Cc: catalin.marinas, Michael Turquette, LKML, Chunyan Zhang,
Greg Kroah-Hartman, will, linux-clk, linux-arm-kernel
In-Reply-To: <20200408160044.2550437-1-arnd@arndb.de>
On Thu, Apr 9, 2020 at 2:57 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> I got a build failure with CONFIG_ARCH_SPRD=m when the
> main portion of the clock driver failed to get linked into
> the kernel:
>
> ERROR: modpost: "sprd_pll_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_comp_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_clk_probe" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_clk_regmap_init" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
> ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined!
> ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined!
> ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined!
>
> This is a combination of two trivial bugs:
>
> - A platform should not be 'tristate', it should be a 'bool' symbol
> like the other platforms, if only for consistency, and to avoid
> surprises like this one.
>
> - The clk Makefile does not traverse into the sprd subdirectory
> if the platform is disabled but the drivers are enabled for
> compile-testing.
>
> Fixing either of the two would be sufficient to address the link failure,
> but for correctness, both need to be changed.
>
> Fixes: 2b1b799d7630 ("arm64: change ARCH_SPRD Kconfig to tristate")
> Fixes: d41f59fd92f2 ("clk: sprd: Add common infrastructure")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hi,
This patch seems not been applied to next branch? I haven't seen it on
linux-next.
Arnd, can you please pick it to your tree.
In case you need my ack:
Acked-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Thanks,
Chunyan
> ---
> arch/arm64/Kconfig.platforms | 2 +-
> drivers/clk/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 55d70cfe0f9e..3c7e310fd8bf 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -248,7 +248,7 @@ config ARCH_TEGRA
> This enables support for the NVIDIA Tegra SoC family.
>
> config ARCH_SPRD
> - tristate "Spreadtrum SoC platform"
> + bool "Spreadtrum SoC platform"
> help
> Support for Spreadtrum ARM based SoCs
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index f4169cc2fd31..60e811d3f226 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -105,7 +105,7 @@ obj-$(CONFIG_CLK_SIFIVE) += sifive/
> obj-$(CONFIG_ARCH_SIRF) += sirf/
> obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
> obj-$(CONFIG_PLAT_SPEAR) += spear/
> -obj-$(CONFIG_ARCH_SPRD) += sprd/
> +obj-y += sprd/
> obj-$(CONFIG_ARCH_STI) += st/
> obj-$(CONFIG_ARCH_STRATIX10) += socfpga/
> obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> --
> 2.26.0
>
_______________________________________________
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] efi/libstub: refactor Makefile to not use lib-y syntax
From: Ard Biesheuvel @ 2020-06-03 9:16 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <CAK7LNAR3YqmSWh_GkXdP+2tb83sOpySeXVi-kP=1eehcD5097Q@mail.gmail.com>
On Wed, 3 Jun 2020 at 11:15, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Wed, Jun 3, 2020 at 6:02 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Wed, 3 Jun 2020 at 10:59, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Wed, Jun 3, 2020 at 5:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Wed, 3 Jun 2020 at 10:36, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > >
> > > > > On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > > >
> > > > > > On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > > > >
> > > > > > > Documentation/kbuild/makefiles.rst says:
> > > > > > >
> > > > > > > Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
> > > > > > >
> > > > > > > I want to disallow lib-y outside of them.
> > > > > > >
> > > > > >
> > > > > > Why?
> > > > >
> > > > >
> > > > > Because I plan to remove lib-y entirely at some point.
> > > > >
> > > > > lib-y is not so useful to shrink the image size because:
> > > > >
> > > > > - An object in lib.a can be omitted only when no symbol
> > > > > in that object is referenced. This rarely happens.
> > > > >
> > > > > - lib-y objects are often exported by nature
> > > > > because lib-y is a collection of utility functions.
> > > > > Even if no in-tree user, we always need to keep them
> > > > > because EXPORT_SYMBOL() is the interface to modules.
> > > > >
> > > > >
> > > > > When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49,
> > > > > I made some research.
> > > > >
> > > > > The benefit of lib-y is just 362 byte for x86_64_defconfig.
> > > > > ( Before: 26578002, After: 26578364)
> > > > >
> > > > > My hope is lib-y will be replaced by dead-code elimination or
> > > > > ultimately by LTO.
> > > > >
> > > > > drivers/firmware/efi/libstub/Makefile
> > > > > is the only Makefile that breaks the rule:
> > > > > "Use of lib-y is normally restricted to `lib/` and `arch/*/lib`"
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > > Add a custom rule to build lib.a, which is linked to the decompressor
> > > > > > > for ARCH=x86, ARCH=arm.
> > > > > > >
> > > > > > > For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> > > > > > > way.
> > > > > > >
> > > > > >
> > > > > > The code works perfectly fine as is, and I don't see what is
> > > > > > fundamentally wrong with using static libraries outside of lib/ and
> > > > > > arch/*/lib.
> > > > >
> > > > > The intended usage of lib-y is to hook lib.a
> > > > > to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS.
> > > > >
> > > > > This Makefile is just what you found to work.
> > > > >
> > > > >
> > > > > >
> > > > > > Also, I would like this code to still be incorporated as a static
> > > > > > library into arm64 as well, so that only pieces that are actually
> > > > > > needed are incorporated into the final image.
> > > > >
> > > > > No.
> > > > > It is not working like that because you set
> > > > > lib.a to core-y.
> > > > >
> > > > > All objects in core-y are always linked to vmlinux.
> > > > >
> > > >
> > > > The lib.a file is passed to the linker as a static library, so it will
> > > > only grab what it needs.
> > > >
> > > > For instance, if you build arm64 from mainline today, the
> > > > efi_relocate_kernel will not be in the final image, even though it is
> > > > built as part of libstub
> > >
> > >
> > > I built today's mainline kernel
> > > (d6f9469a03d832dcd17041ed67774ffb5f3e73b3).
> > >
> > >
> > > I see it in vmlinux.
> > >
> > >
> > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24
> > > ...
> > > $ aarch64-linux-gnu-nm -n vmlinux | grep efi_relocate_kernel
> > > ffff8000114afb90 t __efistub_efi_relocate_kernel
> > >
> >
> > That is strange. I tested this before, and it worked.
> >
> > Did anything change recently in the way the linker is invoked?
>
>
> Nothing recently.
>
> This is obvious result because
> drivers/firmware/efi/libstub/lib.a
> is passed after ----whole-archive flag.
>
>
> I guess the following commit is it,
> but it is already 3 years ago.
>
Right.
So that means there is no point at all in using static libraries, no?
Or does --whole-archive still allow duplicate definitions like static
libraries do usually?
_______________________________________________
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] efi/libstub: refactor Makefile to not use lib-y syntax
From: Masahiro Yamada @ 2020-06-03 9:14 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <CAMj1kXFKuMoYW8Sj=DHeYBSkWyeu+QgP9=fgET83K5D=-DsJ7Q@mail.gmail.com>
On Wed, Jun 3, 2020 at 6:02 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 3 Jun 2020 at 10:59, Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Wed, Jun 3, 2020 at 5:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Wed, 3 Jun 2020 at 10:36, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > >
> > > > On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > >
> > > > > On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > > >
> > > > > > Documentation/kbuild/makefiles.rst says:
> > > > > >
> > > > > > Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
> > > > > >
> > > > > > I want to disallow lib-y outside of them.
> > > > > >
> > > > >
> > > > > Why?
> > > >
> > > >
> > > > Because I plan to remove lib-y entirely at some point.
> > > >
> > > > lib-y is not so useful to shrink the image size because:
> > > >
> > > > - An object in lib.a can be omitted only when no symbol
> > > > in that object is referenced. This rarely happens.
> > > >
> > > > - lib-y objects are often exported by nature
> > > > because lib-y is a collection of utility functions.
> > > > Even if no in-tree user, we always need to keep them
> > > > because EXPORT_SYMBOL() is the interface to modules.
> > > >
> > > >
> > > > When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49,
> > > > I made some research.
> > > >
> > > > The benefit of lib-y is just 362 byte for x86_64_defconfig.
> > > > ( Before: 26578002, After: 26578364)
> > > >
> > > > My hope is lib-y will be replaced by dead-code elimination or
> > > > ultimately by LTO.
> > > >
> > > > drivers/firmware/efi/libstub/Makefile
> > > > is the only Makefile that breaks the rule:
> > > > "Use of lib-y is normally restricted to `lib/` and `arch/*/lib`"
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > > Add a custom rule to build lib.a, which is linked to the decompressor
> > > > > > for ARCH=x86, ARCH=arm.
> > > > > >
> > > > > > For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> > > > > > way.
> > > > > >
> > > > >
> > > > > The code works perfectly fine as is, and I don't see what is
> > > > > fundamentally wrong with using static libraries outside of lib/ and
> > > > > arch/*/lib.
> > > >
> > > > The intended usage of lib-y is to hook lib.a
> > > > to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS.
> > > >
> > > > This Makefile is just what you found to work.
> > > >
> > > >
> > > > >
> > > > > Also, I would like this code to still be incorporated as a static
> > > > > library into arm64 as well, so that only pieces that are actually
> > > > > needed are incorporated into the final image.
> > > >
> > > > No.
> > > > It is not working like that because you set
> > > > lib.a to core-y.
> > > >
> > > > All objects in core-y are always linked to vmlinux.
> > > >
> > >
> > > The lib.a file is passed to the linker as a static library, so it will
> > > only grab what it needs.
> > >
> > > For instance, if you build arm64 from mainline today, the
> > > efi_relocate_kernel will not be in the final image, even though it is
> > > built as part of libstub
> >
> >
> > I built today's mainline kernel
> > (d6f9469a03d832dcd17041ed67774ffb5f3e73b3).
> >
> >
> > I see it in vmlinux.
> >
> >
> > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24
> > ...
> > $ aarch64-linux-gnu-nm -n vmlinux | grep efi_relocate_kernel
> > ffff8000114afb90 t __efistub_efi_relocate_kernel
> >
>
> That is strange. I tested this before, and it worked.
>
> Did anything change recently in the way the linker is invoked?
Nothing recently.
This is obvious result because
drivers/firmware/efi/libstub/lib.a
is passed after ----whole-archive flag.
I guess the following commit is it,
but it is already 3 years ago.
commit 799c43415442414b1032580c47684cb709dfed6d (HEAD)
Author: Nicholas Piggin <npiggin@gmail.com>
Date: Fri Jun 9 15:24:17 2017 +1000
kbuild: thin archives make default for all archs
Make thin archives build the default, but keep the config option
to allow exemptions if any breakage can't be quickly solved.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
--
Best Regards
Masahiro Yamada
_______________________________________________
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] efi/libstub: refactor Makefile to not use lib-y syntax
From: Ard Biesheuvel @ 2020-06-03 9:01 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <CAK7LNARLUeuiu3Y1cFqT7550MaF8fnBmMTZxKEG0Cy3vpxVkMQ@mail.gmail.com>
On Wed, 3 Jun 2020 at 10:59, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Wed, Jun 3, 2020 at 5:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Wed, 3 Jun 2020 at 10:36, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > >
> > > > > Documentation/kbuild/makefiles.rst says:
> > > > >
> > > > > Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
> > > > >
> > > > > I want to disallow lib-y outside of them.
> > > > >
> > > >
> > > > Why?
> > >
> > >
> > > Because I plan to remove lib-y entirely at some point.
> > >
> > > lib-y is not so useful to shrink the image size because:
> > >
> > > - An object in lib.a can be omitted only when no symbol
> > > in that object is referenced. This rarely happens.
> > >
> > > - lib-y objects are often exported by nature
> > > because lib-y is a collection of utility functions.
> > > Even if no in-tree user, we always need to keep them
> > > because EXPORT_SYMBOL() is the interface to modules.
> > >
> > >
> > > When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49,
> > > I made some research.
> > >
> > > The benefit of lib-y is just 362 byte for x86_64_defconfig.
> > > ( Before: 26578002, After: 26578364)
> > >
> > > My hope is lib-y will be replaced by dead-code elimination or
> > > ultimately by LTO.
> > >
> > > drivers/firmware/efi/libstub/Makefile
> > > is the only Makefile that breaks the rule:
> > > "Use of lib-y is normally restricted to `lib/` and `arch/*/lib`"
> > >
> > >
> > >
> > >
> > > >
> > > > > Add a custom rule to build lib.a, which is linked to the decompressor
> > > > > for ARCH=x86, ARCH=arm.
> > > > >
> > > > > For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> > > > > way.
> > > > >
> > > >
> > > > The code works perfectly fine as is, and I don't see what is
> > > > fundamentally wrong with using static libraries outside of lib/ and
> > > > arch/*/lib.
> > >
> > > The intended usage of lib-y is to hook lib.a
> > > to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS.
> > >
> > > This Makefile is just what you found to work.
> > >
> > >
> > > >
> > > > Also, I would like this code to still be incorporated as a static
> > > > library into arm64 as well, so that only pieces that are actually
> > > > needed are incorporated into the final image.
> > >
> > > No.
> > > It is not working like that because you set
> > > lib.a to core-y.
> > >
> > > All objects in core-y are always linked to vmlinux.
> > >
> >
> > The lib.a file is passed to the linker as a static library, so it will
> > only grab what it needs.
> >
> > For instance, if you build arm64 from mainline today, the
> > efi_relocate_kernel will not be in the final image, even though it is
> > built as part of libstub
>
>
> I built today's mainline kernel
> (d6f9469a03d832dcd17041ed67774ffb5f3e73b3).
>
>
> I see it in vmlinux.
>
>
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24
> ...
> $ aarch64-linux-gnu-nm -n vmlinux | grep efi_relocate_kernel
> ffff8000114afb90 t __efistub_efi_relocate_kernel
>
That is strange. I tested this before, and it worked.
Did anything change recently in the way the linker is invoked?
_______________________________________________
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] efi/libstub: refactor Makefile to not use lib-y syntax
From: Masahiro Yamada @ 2020-06-03 8:59 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <CAMj1kXFxmgQ=YzmLNnMO-2gibSGQ1=tXBd07ntqCYYU122zEUw@mail.gmail.com>
On Wed, Jun 3, 2020 at 5:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 3 Jun 2020 at 10:36, Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > >
> > > > Documentation/kbuild/makefiles.rst says:
> > > >
> > > > Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
> > > >
> > > > I want to disallow lib-y outside of them.
> > > >
> > >
> > > Why?
> >
> >
> > Because I plan to remove lib-y entirely at some point.
> >
> > lib-y is not so useful to shrink the image size because:
> >
> > - An object in lib.a can be omitted only when no symbol
> > in that object is referenced. This rarely happens.
> >
> > - lib-y objects are often exported by nature
> > because lib-y is a collection of utility functions.
> > Even if no in-tree user, we always need to keep them
> > because EXPORT_SYMBOL() is the interface to modules.
> >
> >
> > When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49,
> > I made some research.
> >
> > The benefit of lib-y is just 362 byte for x86_64_defconfig.
> > ( Before: 26578002, After: 26578364)
> >
> > My hope is lib-y will be replaced by dead-code elimination or
> > ultimately by LTO.
> >
> > drivers/firmware/efi/libstub/Makefile
> > is the only Makefile that breaks the rule:
> > "Use of lib-y is normally restricted to `lib/` and `arch/*/lib`"
> >
> >
> >
> >
> > >
> > > > Add a custom rule to build lib.a, which is linked to the decompressor
> > > > for ARCH=x86, ARCH=arm.
> > > >
> > > > For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> > > > way.
> > > >
> > >
> > > The code works perfectly fine as is, and I don't see what is
> > > fundamentally wrong with using static libraries outside of lib/ and
> > > arch/*/lib.
> >
> > The intended usage of lib-y is to hook lib.a
> > to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS.
> >
> > This Makefile is just what you found to work.
> >
> >
> > >
> > > Also, I would like this code to still be incorporated as a static
> > > library into arm64 as well, so that only pieces that are actually
> > > needed are incorporated into the final image.
> >
> > No.
> > It is not working like that because you set
> > lib.a to core-y.
> >
> > All objects in core-y are always linked to vmlinux.
> >
>
> The lib.a file is passed to the linker as a static library, so it will
> only grab what it needs.
>
> For instance, if you build arm64 from mainline today, the
> efi_relocate_kernel will not be in the final image, even though it is
> built as part of libstub
I built today's mainline kernel
(d6f9469a03d832dcd17041ed67774ffb5f3e73b3).
I see it in vmlinux.
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24
...
$ aarch64-linux-gnu-nm -n vmlinux | grep efi_relocate_kernel
ffff8000114afb90 t __efistub_efi_relocate_kernel
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 6/6] PCI: uniphier: Use devm_platform_ioremap_resource_byname()
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
Use devm_platform_ioremap_resource_byname() to simplify the code a bit.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 3b51561..ce47622 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -452,8 +452,7 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.atu_base))
priv->pci.atu_base = NULL;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
- priv->base = devm_ioremap_resource(dev, res);
+ priv->base = devm_platform_ioremap_resource_byname(pdev, "link");
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 5/6] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
Even if phy driver doesn't probe, the error message can't be distinguished
from other errors. This displays error message caused by the phy driver
explicitly.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index ad14e67..3b51561 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -466,8 +466,12 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
return PTR_ERR(priv->rst);
priv->phy = devm_phy_optional_get(dev, "pcie-phy");
- if (IS_ERR(priv->phy))
- return PTR_ERR(priv->phy);
+ if (IS_ERR(priv->phy)) {
+ ret = PTR_ERR(priv->phy);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get phy (%d)\n", ret);
+ return ret;
+ }
platform_set_drvdata(pdev, priv);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, Marc Zyngier, linux-arm-kernel
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
The misc interrupts consisting of PME, AER, and Link event, is handled
by INTx handler, however, these interrupts should be also handled by
MSI handler.
This adds the function uniphier_pcie_misc_isr() that handles misc
intterupts, which is called from both INTx and MSI handlers.
This function detects PME and AER interrupts with the status register,
and invoke PME and AER drivers related to INTx or MSI.
And this sets the mask for misc interrupts from INTx if MSI is enabled
and sets the mask for misc interrupts from MSI if MSI is disabled.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 53 +++++++++++++++++++++++-------
1 file changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index a5401a0..a8dda39 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -44,7 +44,9 @@
#define PCL_SYS_AUX_PWR_DET BIT(8)
#define PCL_RCV_INT 0x8108
+#define PCL_RCV_INT_ALL_INT_MASK GENMASK(28, 25)
#define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
+#define PCL_RCV_INT_ALL_MSI_MASK GENMASK(12, 9)
#define PCL_CFG_BW_MGT_STATUS BIT(4)
#define PCL_CFG_LINK_AUTO_BW_STATUS BIT(3)
#define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
@@ -167,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
{
- writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
+ u32 val;
+
+ val = PCL_RCV_INT_ALL_ENABLE;
+ if (pci_msi_enabled())
+ val |= PCL_RCV_INT_ALL_INT_MASK;
+ else
+ val |= PCL_RCV_INT_ALL_MSI_MASK;
+
+ writel(val, priv->base + PCL_RCV_INT);
writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
}
@@ -231,28 +241,48 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
.map = uniphier_pcie_intx_map,
};
-static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+static void uniphier_pcie_misc_isr(struct pcie_port *pp)
{
- struct pcie_port *pp = irq_desc_get_handler_data(desc);
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
- struct irq_chip *chip = irq_desc_get_chip(desc);
- unsigned long reg;
- u32 val, bit, virq;
+ u32 val, virq;
- /* INT for debug */
val = readl(priv->base + PCL_RCV_INT);
if (val & PCL_CFG_BW_MGT_STATUS)
dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
+
if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
- if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
- dev_dbg(pci->dev, "Root Error\n");
- if (val & PCL_CFG_PME_MSI_STATUS)
- dev_dbg(pci->dev, "PME Interrupt\n");
+
+ if (pci_msi_enabled()) {
+ if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
+ dev_dbg(pci->dev, "Root Error Status\n");
+ virq = irq_linear_revmap(pp->irq_domain, 0);
+ generic_handle_irq(virq);
+ }
+
+ if (val & PCL_CFG_PME_MSI_STATUS) {
+ dev_dbg(pci->dev, "PME Interrupt\n");
+ virq = irq_linear_revmap(pp->irq_domain, 0);
+ generic_handle_irq(virq);
+ }
+ }
writel(val, priv->base + PCL_RCV_INT);
+}
+
+static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+{
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long reg;
+ u32 val, bit, virq;
+
+ /* misc interrupt */
+ uniphier_pcie_misc_isr(pp);
/* INTx */
chained_irq_enter(chip, desc);
@@ -330,6 +360,7 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
.host_init = uniphier_pcie_host_init,
+ .msi_host_isr = uniphier_pcie_misc_isr,
};
static int uniphier_add_pcie_port(struct uniphier_pcie_priv *priv,
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 4/6] PCI: uniphier: Add iATU register support
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
This gets iATU register area from reg property. In Synopsys DWC version
4.80 or later, since iATU register area is separated from core register
area, this area is necessary to get from DT independently.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index a8dda39..ad14e67 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -447,6 +447,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.dbi_base))
return PTR_ERR(priv->pci.dbi_base);
+ priv->pci.atu_base =
+ devm_platform_ioremap_resource_byname(pdev, "atu");
+ if (IS_ERR(priv->pci.atu_base))
+ priv->pci.atu_base = NULL;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
priv->base = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->base))
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 3/6] dt-bindings: PCI: uniphier: Add iATU register description
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsys DWC version 4.80 or later.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
index 1fa2c59..c4b7381 100644
--- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
@@ -16,6 +16,7 @@ Required properties:
"dbi" - controller configuration registers
"link" - SoC-specific glue layer registers
"config" - PCIe configuration space
+ "atu" - iATU registers for DWC version 4.80 or later
- clocks: A phandle to the clock gate for PCIe glue layer including
the host controller.
- resets: A phandle to the reset line for PCIe glue layer including
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/6] PCI: uniphier: Add features for UniPhier PCIe host controller
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
This series adds some features for UniPhier PCIe host controller.
- Add support for PME and AER invoked by MSI interrupt
- Add iATU register view support for PCIe version >= 4.80
- Add an error message when failing to get phy driver
This adds a new function called by MSI handler in DesignWare PCIe framework,
that invokes PME and AER funcions to detect the factor from SoC-dependent
registers.
Changes since v2:
- Avoid printing phy error message in case of EPROBE_DEFER
- Fix iATU register mapping method
- dt-bindings: Add Acked-by: line
- Fix typos in commit messages
- Use devm_platform_ioremap_resource_byname()
Changes since v1:
- Add check if struct resource is NULL
- Fix warning in the type of dev_err() argument
Kunihiko Hayashi (6):
PCI: dwc: Add msi_host_isr() callback
PCI: uniphier: Add misc interrupt handler to invoke PME and AER
dt-bindings: PCI: uniphier: Add iATU register description
PCI: uniphier: Add iATU register support
PCI: uniphier: Add error message when failed to get phy
PCI: uniphier: Use devm_platform_ioremap_resource_byname()
.../devicetree/bindings/pci/uniphier-pcie.txt | 1 +
drivers/pci/controller/dwc/pcie-designware-host.c | 8 +--
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-uniphier.c | 69 +++++++++++++++++-----
4 files changed, 60 insertions(+), 19 deletions(-)
--
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
* [PATCH v3 1/6] PCI: dwc: Add msi_host_isr() callback
From: Kunihiko Hayashi @ 2020-06-03 8:54 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, Marc Zyngier, linux-arm-kernel
In-Reply-To: <1591174481-13975-1-git-send-email-hayashi.kunihiko@socionext.com>
This adds msi_host_isr() callback function support to describe
SoC-dependent service triggered by MSI.
For example, when AER interrupt is triggered by MSI, the callback function
reads SoC-dependent registers and detects that the interrupt is from AER,
and invoke AER interrupts related to MSI.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++----
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 0a4a5aa..9b628a2 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -112,13 +112,13 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
static void dw_chained_msi_isr(struct irq_desc *desc)
{
struct irq_chip *chip = irq_desc_get_chip(desc);
- struct pcie_port *pp;
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
- chained_irq_enter(chip, desc);
+ if (pp->ops->msi_host_isr)
+ pp->ops->msi_host_isr(pp);
- pp = irq_desc_get_handler_data(desc);
+ chained_irq_enter(chip, desc);
dw_handle_msi_irq(pp);
-
chained_irq_exit(chip, desc);
}
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 656e00f..e741967 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -170,6 +170,7 @@ struct dw_pcie_host_ops {
void (*scan_bus)(struct pcie_port *pp);
void (*set_num_vectors)(struct pcie_port *pp);
int (*msi_host_init)(struct pcie_port *pp);
+ void (*msi_host_isr)(struct pcie_port *pp);
};
struct pcie_port {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] usb: host: xhci-mtk: avoid runtime suspend when removing hcd
From: Chunfeng Yun @ 2020-06-03 8:43 UTC (permalink / raw)
To: Macpaul Lin
Cc: Mathias Nyman, Mediatek WSD Upstream, Greg Kroah-Hartman,
linux-usb, linux-kernel, linux-mediatek, Matthias Brugger,
Macpaul Lin, linux-arm-kernel
In-Reply-To: <1590726778-29065-1-git-send-email-macpaul.lin@mediatek.com>
On Fri, 2020-05-29 at 12:32 +0800, Macpaul Lin wrote:
> When runtime suspend was enabled, runtime suspend might happened
> when xhci is removing hcd. This might cause kernel panic when hcd
> has been freed but runtime pm suspend related handle need to
> reference it.
>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
> drivers/usb/host/xhci-mtk.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> index bfbdb3c..641d24e 100644
> --- a/drivers/usb/host/xhci-mtk.c
> +++ b/drivers/usb/host/xhci-mtk.c
> @@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> struct usb_hcd *shared_hcd = xhci->shared_hcd;
>
> + pm_runtime_put_sync(&dev->dev);
> + pm_runtime_disable(&dev->dev);
> +
> usb_remove_hcd(shared_hcd);
> xhci->shared_hcd = NULL;
> device_init_wakeup(&dev->dev, false);
> @@ -597,8 +600,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
> xhci_mtk_sch_exit(mtk);
> xhci_mtk_clks_disable(mtk);
> xhci_mtk_ldos_disable(mtk);
> - pm_runtime_put_sync(&dev->dev);
> - pm_runtime_disable(&dev->dev);
>
> return 0;
> }
Reviewed-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Thanks
_______________________________________________
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 0/5 v2] KASan for ARM
From: Linus Walleij @ 2020-06-03 8:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Abbott Liu, Andrey Ryabinin, Russell King, Linux ARM,
Ard Biesheuvel
In-Reply-To: <25cdd13f-1f95-1ca5-c28b-917538643590@gmail.com>
On Mon, Jun 1, 2020 at 6:37 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> This branch got me a bit further,
Thanks, at least we get improvements. :)
> but still failed to fully initialize
> (see attached kasan.log), on another platform with a slightly different
> memory map, I ended up getting a different error (kasan2.log).
I have this error too on a Qualcomm board, it is what I report
in the cover letter, that if I load the kernel into 0x40200000
this happens but when I load it into 0x50000000 it does not
happen.
I think it is because the device tree unflatter reads from
non-kernel memory. The device tree can be placed pretty
much anywhere in physical memory, and if that physical
memory happens to end up to be inside kernel virtual
memory we are fine, and if not this happens. (This is
just my working hypothesis.)
I think the issue is a kind of bug since the kernel is
indeed accessing non-kernel memory, but on the
other hand it has to. So it has to be done under
controlled forms.
I tried to de-instrument the DT parser but that did not
help me, but possibly it is one part of the solution:
From f02ac4adf784cff9fa7b4780d5e7ff5f1c830165 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij@linaro.org>
Date: Tue, 12 May 2020 00:19:04 +0200
Subject: [PATCH] lib: fdt: De-instrumentize core FDT parser for KASan
When the architecture initialize and want to inspect the FDT
using this call sequence:
setup_arch()
unflatten_device_tree()
early_init_dt_alloc_memory_arch()
fdt_check_header()
The KASan shadow memory is set up at this point, but
fdt_check_header() will reach out into non-kernel memory
not shadowed by KASan by just casting a pointer into virtual
memory into a ((const struct fdt_header *) by way of
fdt_get_header(). KASan will attempt to shadow these memory
accesses leading to a crash like this:
Unable to handle kernel paging request at virtual address b7600619
pgd = (ptrval)
[b7600619] *pgd=00000000c
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:c
CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc1-00009-g667a8ab4ee5e-dirty #29
Hardware name: Generic DT based system
PC is at __asan_load1+0x1c/0x48
LR is at fdt_check_header+0xc/0x2f4
Fix this by de-instrumenting fdt.c from libfdt.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
lib/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/Makefile b/lib/Makefile
index 685aee60de1d..13ea92191788 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -236,6 +236,10 @@ libfdt_files = fdt.o fdt_ro.o fdt_wip.o fdt_rw.o
fdt_sw.o fdt_strerror.o \
$(foreach file, $(libfdt_files), \
$(eval CFLAGS_$(file) = -I $(srctree)/scripts/dtc/libfdt))
lib-$(CONFIG_LIBFDT) += $(libfdt_files)
+# The early kernel setup will attempt to read properties from the FDT which
+# may very well be in some memory area that is not kernel memory, leading
+# to problems when KASan tries to shadow these memory accesses.
+KASAN_SANITIZE_fdt.o := n
lib-$(CONFIG_BOOT_CONFIG) += bootconfig.o
--
2.25.4
Yours,
Linus Walleij
_______________________________________________
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] sound: usb: pcm: fix incorrect power state when playing sound after PM_AUTO suspend
From: Takashi Iwai @ 2020-06-03 8:45 UTC (permalink / raw)
To: Macpaul Lin
Cc: alsa-devel, Mediatek WSD Upstream, linux-kernel, linux-usb,
Johan Hovold, Takashi Iwai, Hui Wang, Alexander Tsoy,
linux-mediatek, Greg Kroah-Hartman, Matthias Brugger, Macpaul Lin,
Jaroslav Kysela, Szabolcs Szőke, linux-arm-kernel
In-Reply-To: <s5hblm0fxl0.wl-tiwai@suse.de>
On Wed, 03 Jun 2020 08:54:51 +0200,
Takashi Iwai wrote:
>
> On Wed, 03 Jun 2020 08:28:09 +0200,
> Takashi Iwai wrote:
> >
> > And, the most suspicious case is the last one,
> > chip->num_suspended-intf. It means that the device has multiple
> > USB interfaces and they went to suspend, while the resume isn't
> > performed for the all suspended interfaces in return.
>
> If this is the cause, a patch like below might help.
> It gets/puts the all assigned interfaced instead of only the primary
> one.
... and considering of the problem again, rather the patch below might
be the right answer. Now the driver tries to remember at which state
it entered into the system-suspend. Upon resume, in return, when the
state reaches back to that point, set the card state to D0.
The previous patch can be applied on the top, too, and it might be
worth to apply both.
Let me know if any of those actually helps.
Takashi
---
diff --git a/sound/usb/card.c b/sound/usb/card.c
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -843,9 +843,6 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
if (chip == (void *)-1L)
return 0;
- chip->autosuspended = !!PMSG_IS_AUTO(message);
- if (!chip->autosuspended)
- snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
if (!chip->num_suspended_intf++) {
list_for_each_entry(as, &chip->pcm_list, list) {
snd_usb_pcm_suspend(as);
@@ -858,6 +855,11 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
snd_usb_mixer_suspend(mixer);
}
+ if (!PMSG_IS_AUTO(message) && !chip->system_suspend) {
+ snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
+ chip->system_suspend = chip->num_suspended_intf;
+ }
+
return 0;
}
@@ -871,10 +873,10 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
if (chip == (void *)-1L)
return 0;
- if (--chip->num_suspended_intf)
- return 0;
atomic_inc(&chip->active); /* avoid autopm */
+ if (chip->num_suspended_intf > 1)
+ goto out;
list_for_each_entry(as, &chip->pcm_list, list) {
err = snd_usb_pcm_resume(as);
@@ -896,9 +898,12 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
snd_usbmidi_resume(p);
}
- if (!chip->autosuspended)
+ out:
+ if (chip->num_suspended_intf == chip->system_suspend) {
snd_power_change_state(chip->card, SNDRV_CTL_POWER_D0);
- chip->autosuspended = 0;
+ chip->system_suspend = 0;
+ }
+ chip->num_suspended_intf--;
err_out:
atomic_dec(&chip->active); /* allow autopm after this point */
diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
index 1c892c7f14d7..e0ebfb25fbd5 100644
--- a/sound/usb/usbaudio.h
+++ b/sound/usb/usbaudio.h
@@ -26,7 +26,7 @@ struct snd_usb_audio {
struct usb_interface *pm_intf;
u32 usb_id;
struct mutex mutex;
- unsigned int autosuspended:1;
+ unsigned int system_suspend;
atomic_t active;
atomic_t shutdown;
atomic_t usage_count;
_______________________________________________
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] efi/libstub: refactor Makefile to not use lib-y syntax
From: Ard Biesheuvel @ 2020-06-03 8:45 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <CAK7LNARg70FrTmnuoUiLM6KWxeJ+AeXqgB53GS6sY7z0J+qH6g@mail.gmail.com>
On Wed, 3 Jun 2020 at 10:36, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > Documentation/kbuild/makefiles.rst says:
> > >
> > > Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
> > >
> > > I want to disallow lib-y outside of them.
> > >
> >
> > Why?
>
>
> Because I plan to remove lib-y entirely at some point.
>
> lib-y is not so useful to shrink the image size because:
>
> - An object in lib.a can be omitted only when no symbol
> in that object is referenced. This rarely happens.
>
> - lib-y objects are often exported by nature
> because lib-y is a collection of utility functions.
> Even if no in-tree user, we always need to keep them
> because EXPORT_SYMBOL() is the interface to modules.
>
>
> When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49,
> I made some research.
>
> The benefit of lib-y is just 362 byte for x86_64_defconfig.
> ( Before: 26578002, After: 26578364)
>
> My hope is lib-y will be replaced by dead-code elimination or
> ultimately by LTO.
>
> drivers/firmware/efi/libstub/Makefile
> is the only Makefile that breaks the rule:
> "Use of lib-y is normally restricted to `lib/` and `arch/*/lib`"
>
>
>
>
> >
> > > Add a custom rule to build lib.a, which is linked to the decompressor
> > > for ARCH=x86, ARCH=arm.
> > >
> > > For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> > > way.
> > >
> >
> > The code works perfectly fine as is, and I don't see what is
> > fundamentally wrong with using static libraries outside of lib/ and
> > arch/*/lib.
>
> The intended usage of lib-y is to hook lib.a
> to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS.
>
> This Makefile is just what you found to work.
>
>
> >
> > Also, I would like this code to still be incorporated as a static
> > library into arm64 as well, so that only pieces that are actually
> > needed are incorporated into the final image.
>
> No.
> It is not working like that because you set
> lib.a to core-y.
>
> All objects in core-y are always linked to vmlinux.
>
The lib.a file is passed to the linker as a static library, so it will
only grab what it needs.
For instance, if you build arm64 from mainline today, the
efi_relocate_kernel will not be in the final image, even though it is
built as part of libstub
_______________________________________________
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] efi/libstub: refactor Makefile to not use lib-y syntax
From: Masahiro Yamada @ 2020-06-03 8:35 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <CAMj1kXGk-2pyTZ3yNW14Kk4fvtsNOb7maAHVM2C=vVAjaaFRug@mail.gmail.com>
On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > Documentation/kbuild/makefiles.rst says:
> >
> > Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
> >
> > I want to disallow lib-y outside of them.
> >
>
> Why?
Because I plan to remove lib-y entirely at some point.
lib-y is not so useful to shrink the image size because:
- An object in lib.a can be omitted only when no symbol
in that object is referenced. This rarely happens.
- lib-y objects are often exported by nature
because lib-y is a collection of utility functions.
Even if no in-tree user, we always need to keep them
because EXPORT_SYMBOL() is the interface to modules.
When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49,
I made some research.
The benefit of lib-y is just 362 byte for x86_64_defconfig.
( Before: 26578002, After: 26578364)
My hope is lib-y will be replaced by dead-code elimination or
ultimately by LTO.
drivers/firmware/efi/libstub/Makefile
is the only Makefile that breaks the rule:
"Use of lib-y is normally restricted to `lib/` and `arch/*/lib`"
>
> > Add a custom rule to build lib.a, which is linked to the decompressor
> > for ARCH=x86, ARCH=arm.
> >
> > For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> > way.
> >
>
> The code works perfectly fine as is, and I don't see what is
> fundamentally wrong with using static libraries outside of lib/ and
> arch/*/lib.
The intended usage of lib-y is to hook lib.a
to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS.
This Makefile is just what you found to work.
>
> Also, I would like this code to still be incorporated as a static
> library into arm64 as well, so that only pieces that are actually
> needed are incorporated into the final image.
No.
It is not working like that because you set
lib.a to core-y.
All objects in core-y are always linked to vmlinux.
Thanks.
>
>
>
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> >
> > arch/arm64/Makefile | 1 -
> > drivers/firmware/efi/Makefile | 2 +-
> > drivers/firmware/efi/libstub/Makefile | 51 +++++++++++++++------------
> > 3 files changed, 30 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 650e1185c190..ab79b20efc8d 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -145,7 +145,6 @@ export TEXT_OFFSET
> >
> > core-y += arch/arm64/
> > libs-y := arch/arm64/lib/ $(libs-y)
> > -core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> >
> > # Default target when executing plain make
> > boot := arch/arm64/boot
> > diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> > index 7a216984552b..317a05cd388b 100644
> > --- a/drivers/firmware/efi/Makefile
> > +++ b/drivers/firmware/efi/Makefile
> > @@ -20,7 +20,7 @@ obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
> > obj-$(CONFIG_UEFI_CPER) += cper.o
> > obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
> > obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
> > -subdir-$(CONFIG_EFI_STUB) += libstub
> > +obj-$(CONFIG_EFI_STUB) += libstub/
> > obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_map.o
> > obj-$(CONFIG_EFI_BOOTLOADER_CONTROL) += efibc.o
> > obj-$(CONFIG_EFI_TEST) += test/
> > diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> > index cce4a7436052..e4e9b17fa3b2 100644
> > --- a/drivers/firmware/efi/libstub/Makefile
> > +++ b/drivers/firmware/efi/libstub/Makefile
> > @@ -44,7 +44,7 @@ OBJECT_FILES_NON_STANDARD := y
> > # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
> > KCOV_INSTRUMENT := n
> >
> > -lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
> > +stub-obj-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
> > file.o mem.o random.o randomalloc.o pci.o \
> > skip_spaces.o lib-cmdline.o lib-ctype.o \
> > alignedmem.o relocate.o vsprintf.o
> > @@ -55,15 +55,19 @@ efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c
> > $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
> > $(call if_changed_rule,cc_o_c)
> >
> > -lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \
> > +stub-obj-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \
> > $(patsubst %.c,lib-%.o,$(efi-deps-y))
> >
> > -lib-$(CONFIG_ARM) += arm32-stub.o
> > -lib-$(CONFIG_ARM64) += arm64-stub.o
> > -lib-$(CONFIG_X86) += x86-stub.o
> > +stub-obj-$(CONFIG_ARM) += arm32-stub.o
> > +stub-obj-$(CONFIG_ARM64) += arm64-stub.o
> > +stub-obj-$(CONFIG_X86) += x86-stub.o
> > CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> >
> > +targets += $(stub-obj-y)
> > +stub-obj-y := $(patsubst %.o,%.stub.o, $(stub-obj-y))
> > +targets += $(stub-obj-y)
> > +
> > #
> > # For x86, bootloaders like systemd-boot or grub-efi do not zero-initialize the
> > # .bss section, so the .bss section of the EFI stub needs to be included in the
> > @@ -83,23 +87,6 @@ STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section .data=.data.efistub \
> > --rename-section .bss=.bss.efistub,load,alloc
> > STUBCOPY_RELOC-$(CONFIG_ARM) := R_ARM_ABS
> >
> > -#
> > -# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
> > -# code indefinitely unless it is annotated as __init/__initdata/__initconst etc.
> > -# So let's apply the __init annotations at the section level, by prefixing
> > -# the section names directly. This will ensure that even all the inline string
> > -# literals are covered.
> > -# The fact that the stub and the kernel proper are essentially the same binary
> > -# also means that we need to be extra careful to make sure that the stub does
> > -# not rely on any absolute symbol references, considering that the virtual
> > -# kernel mapping that the linker uses is not active yet when the stub is
> > -# executing. So build all C dependencies of the EFI stub into libstub, and do
> > -# a verification pass to see if any absolute relocations exist in any of the
> > -# object files.
> > -#
> > -extra-y := $(lib-y)
> > -lib-y := $(patsubst %.o,%.stub.o,$(lib-y))
> > -
> > STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
> > --prefix-symbols=__efistub_
> > STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
> > @@ -121,3 +108,23 @@ quiet_cmd_stubcopy = STUBCPY $@
> > /bin/false; \
> > fi; \
> > $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@
> > +
> > +# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
> > +# code indefinitely unless it is annotated as __init/__initdata/__initconst etc.
> > +# So let's apply the __init annotations at the section level, by prefixing
> > +# the section names directly. This will ensure that even all the inline string
> > +# literals are covered.
> > +# The fact that the stub and the kernel proper are essentially the same binary
> > +# also means that we need to be extra careful to make sure that the stub does
> > +# not rely on any absolute symbol references, considering that the virtual
> > +# kernel mapping that the linker uses is not active yet when the stub is
> > +# executing. So build all C dependencies of the EFI stub into libstub, and do
> > +# a verification pass to see if any absolute relocations exist in any of the
> > +# object files.
> > +#
> > +obj-$(CONFIG_ARM64) += $(stub-obj-y)
> > +extra-$(CONFIG_ARM) += lib.a
> > +extra-$(CONFIG_X86) += lib.a
> > +
> > +$(obj)/lib.a: $(addprefix $(obj)/, $(stub-obj-y)) FORCE
> > + $(call if_changed,ar)
> > --
> > 2.25.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (EXT) [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Matthias Schiffer @ 2020-06-03 8:31 UTC (permalink / raw)
To: Robin Gong
Cc: mark.rutland, devicetree, festevam, martin.fuzzey, Markus Niebel,
catalin.marinas, s.hauer, will.deacon, linux-kernel, robh+dt,
linux-spi, vkoul, broonie, linux-imx, kernel, u.kleine-koenig,
dan.j.williams, shawnguo, linux-arm-kernel
In-Reply-To: <1590006865-20900-1-git-send-email-yibin.gong@nxp.com>
On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> transfer to be send twice in DMA mode. Please get more information
> from:
> https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. The workaround is
> adding
> new sdma ram script which works in XCH mode as PIO inside sdma
> instead
> of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue should
> be
> exist on all legacy i.mx6/7 soc family before i.mx6ul.
> NXP fix this design issue from i.mx6ul, so newer chips including
> i.mx6ul/
> 6ull/6sll do not need this workaroud anymore. All other i.mx6/7/8
> chips
> still need this workaroud. This patch set add new 'fsl,imx6ul-ecspi'
> for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need
> errata
> or not.
> The first two reverted patches should be the same issue, though, it
> seems 'fixed' by changing to other shp script. Hope Sean or Sascha
> could
> have the chance to test this patch set if could fix their issues.
> Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
> on i.mx8mm because the event id is zero.
>
> PS:
> Please get sdma firmware from below linux-firmware and copy it to
> your
> local rootfs /lib/firmware/imx/sdma.
Hello Robin,
we have tried out this series, and there seems to be an issue with the
PIO fallback. We are testing on an i.MX6Q board, and our kernel is a
mostly-unmodified 5.4, on which we backported all SDMA patches from
next-20200602 (imx-sdma.c is identical to next-20200602 version), and
then applied this whole series.
We build the SDMA driver as a kernel module, which is loaded by udev,
so the root filesystem is ready and the SDMA firmware can be loaded.
The behaviour we're seeing is the following:
1. As long as the SDMA driver is not loaded, initializing spi_imx will
be deferred
2. imx_sdma is loaded. The SDMA firmware is not yet loaded at this
point
3. spi_imx is initialized and an SPI-NOR flash is probed. To load the
BFPT, the driver will attempt to use DMA; this will fail with EINVAL as
long as the SDMA firmware is not ready, so the fallback to PIO happens
(4. SDMA firmware is ready, subsequent SPI transfers use DMA)
The problem happens in step 3: Whenever the driver falls back to PIO,
the received data is corrupt. The behaviour is specific to the
fallback: When I disable DMA completely via spi_imx.use_dma, or when
the timing is lucky and the SDMA firmware gets loaded before the flash
is probed, no corruption can be observed.
Kind regards,
Matthias
>
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma
>
> v2:
> 1.Add commit log for reverted patches.
> 2.Add comment for 'ecspi_fixed' in sdma driver.
> 3.Add 'fsl,imx6sll-ecspi' compatible instead of 'fsl,imx6ul-ecspi'
> rather than remove.
> v3:
> 1.Confirm with design team make sure ERR009165 fixed on
> i.mx6ul/i.mx6ull
> /i.mx6sll, not fixed on i.mx8m/8mm and other i.mx6/7 legacy
> chips.
> Correct dts related dts patch in v2.
> 2.Clean eratta information in binding doc and new 'tx_glitch_fixed'
> flag
> in spi-imx driver to state ERR009165 fixed or not.
> 3.Enlarge burst size to fifo size for tx since tx_wml set to 0 in
> the
> errata workaroud, thus improve performance as possible.
> v4:
> 1.Add Ack tag from Mark and Vinod
> 2.Remove checking 'event_id1' zero as 'event_id0'.
> v5:
> 1.Add the last patch for compatible with the current uart driver
> which
> using rom script, so both uart ram script and rom script
> supported
> in latest firmware, by default uart rom script used. UART driver
> will be broken without this patch.
> v6:
> 1.Resend after rebase the latest next branch.
> 2.Remove below No.13~No.15 patches of v5 because they were
> mergered.
> ARM: dts: imx6ul: add dma support on ecspi
> ARM: dts: imx6sll: correct sdma compatible
> arm64: defconfig: Enable SDMA on i.mx8mq/8mm
> 3.Revert "dmaengine: imx-sdma: fix context cache" since
> 'context_loaded' removed.
> v7:
> 1.Put the last patch 13/13 'Revert "dmaengine: imx-sdma: fix
> context
> cache"' to the ahead of 03/13 'Revert "dmaengine: imx-sdma:
> refine
> to load context only once" so that no building waring during
> comes out
> during bisect.
> 2.Address Sascha's comments, including eliminating any i.mx6sx in
> this
> series, adding new 'is_imx6ul_ecspi()' instead imx in imx51 and
> taking
> care SMC bit for PIO.
> 3.Add back missing 'Reviewed-by' tag on 08/15(v5):09/13(v7)
> 'spi: imx: add new i.mx6ul compatible name in binding doc'
> v8:
> 1.remove 0003-Revert-dmaengine-imx-sdma-fix-context-cache.patch and
> merge
> it into 04/13 of v7
> 2.add 0005-spi-imx-fallback-to-PIO-if-dma-setup-failure.patch for
> no any
> ecspi function broken even if sdma firmware not updated.
> 3.merge 'tx.dst_maxburst' changes in the two continous patches into
> one
> patch to avoid confusion.
> 4.fix typo 'duplicated'.
>
> Robin Gong (13):
> Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core"
> Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores"
> Revert "dmaengine: imx-sdma: refine to load context only once"
> dmaengine: imx-sdma: remove duplicated sdma_load_context
> spi: imx: fallback to PIO if dma setup failure
> dmaengine: imx-sdma: add mcu_2_ecspi script
> spi: imx: fix ERR009165
> spi: imx: remove ERR009165 workaround on i.mx6ul
> spi: imx: add new i.mx6ul compatible name in binding doc
> dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
> dma: imx-sdma: add i.mx6ul compatible name
> dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm
> dmaengine: imx-sdma: add uart rom script
>
> .../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
> .../devicetree/bindings/spi/fsl-imx-cspi.txt | 1 +
> arch/arm/boot/dts/imx6q.dtsi | 2 +-
> arch/arm/boot/dts/imx6qdl.dtsi | 8 +-
> drivers/dma/imx-sdma.c | 67 ++++++++++
> ------
> drivers/spi/spi-imx.c | 92
> +++++++++++++++++++---
> include/linux/platform_data/dma-imx-sdma.h | 8 +-
> 7 files changed, 135 insertions(+), 44 deletions(-)
>
_______________________________________________
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 06/10] arm64: dts: actions: Add DMA Controller for S700
From: Manivannan Sadhasivam @ 2020-06-03 8:30 UTC (permalink / raw)
To: Amit Singh Tomar, andre.przywara, afaerber, vkoul, robh+dt
Cc: devicetree, linux-actions, linux-kernel, cristian.ciocaltea,
dan.j.williams, linux-arm-kernel
In-Reply-To: <1591119192-18538-7-git-send-email-amittomer25@gmail.com>
On 2 June 2020 11:03:08 PM IST, Amit Singh Tomar <amittomer25@gmail.com> wrote:
>This commit adds DAM controller present on Actions S700, it differs
DMA
>from
>S900 in terms of number of dma channels and requests.
>
>Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
>---
>Changes since v2:
> * added power-domain property as sps
> is enabled now and DMA needs it.
>Changes since v1:
> * No Change.
>Changes since RFC:
> * No Change.
>---
> arch/arm64/boot/dts/actions/s700.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
>b/arch/arm64/boot/dts/actions/s700.dtsi
>index f8eb72bb4125..605594dd7a0e 100644
>--- a/arch/arm64/boot/dts/actions/s700.dtsi
>+++ b/arch/arm64/boot/dts/actions/s700.dtsi
>@@ -6,6 +6,7 @@
> #include <dt-bindings/clock/actions,s700-cmu.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/reset/actions,s700-reset.h>
>+#include <dt-bindings/power/owl-s700-powergate.h>
Sort this alphabetically.
Thanks,
Mani
>
> / {
> compatible = "actions,s700";
>@@ -244,5 +245,19 @@
> <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> };
>+
>+ dma: dma-controller@e0230000 {
>+ compatible = "actions,s700-dma";
>+ reg = <0x0 0xe0230000 0x0 0x1000>;
>+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>+ #dma-cells = <1>;
>+ dma-channels = <10>;
>+ dma-requests = <44>;
>+ clocks = <&cmu CLK_DMAC>;
>+ power-domains = <&sps S700_PD_DMA>;
>+ };
> };
> };
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
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] drm/connector: notify userspace on hotplug after register complete
From: Daniel Vetter @ 2020-06-03 8:24 UTC (permalink / raw)
To: Jeykumar Sankaran
Cc: linux-arm-kernel, seanpaul, Steve Cohen, linux-kernel, dri-devel
In-Reply-To: <1591155451-10393-1-git-send-email-jsanka@codeaurora.org>
On Tue, Jun 02, 2020 at 08:37:31PM -0700, Jeykumar Sankaran wrote:
> drm connector notifies userspace on hotplug event prematurely before
> late_register and mode_object register completes. This leads to a race
> between userspace and kernel on updating the IDR list. So, move the
> notification to end of connector register.
>
> Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org>
> Signed-off-by: Steve Cohen <cohens@codeaurora.org>
Hm on the unregister side we don't have the race, there we remove
everything and then send out the uevent. But there the uevent is also
generated in a separate step, so I wonder whether we shouldn't do the same
for register for symmetry ...
Anyway this looks good, nice catch, I'll add cc: stable and merge.
-Daniel
> ---
> drivers/gpu/drm/drm_connector.c | 5 +++++
> drivers/gpu/drm/drm_sysfs.c | 3 ---
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b1099e1..d877ddc 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -27,6 +27,7 @@
> #include <drm/drm_print.h>
> #include <drm/drm_drv.h>
> #include <drm/drm_file.h>
> +#include <drm/drm_sysfs.h>
>
> #include <linux/uaccess.h>
>
> @@ -523,6 +524,10 @@ int drm_connector_register(struct drm_connector *connector)
> drm_mode_object_register(connector->dev, &connector->base);
>
> connector->registration_state = DRM_CONNECTOR_REGISTERED;
> +
> + /* Let userspace know we have a new connector */
> + drm_sysfs_hotplug_event(connector->dev);
> +
> goto unlock;
>
> err_debugfs:
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 939f003..f0336c8 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -291,9 +291,6 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
> return PTR_ERR(connector->kdev);
> }
>
> - /* Let userspace know we have a new connector */
> - drm_sysfs_hotplug_event(dev);
> -
> if (connector->ddc)
> return sysfs_create_link(&connector->kdev->kobj,
> &connector->ddc->dev.kobj, "ddc");
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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 0/4] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2020-06-03 8:07 UTC (permalink / raw)
To: James Bottomley
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, op-tee,
Jonathan Corbet, Janne Karhunen, Linux Doc Mailing List,
James Morris, Mimi Zohar, Linux Kernel Mailing List, dhowells,
linux-security-module, open list:ASYMMETRIC KEYS, Jarkko Sakkinen,
Markus Wamser, Casey Schaufler, linux-integrity, Jens Wiklander,
linux-arm-kernel, Serge E. Hallyn
In-Reply-To: <1591108981.4253.17.camel@linux.ibm.com>
On Tue, 2 Jun 2020 at 20:14, James Bottomley <jejb@linux.ibm.com> wrote:
>
> On Tue, 2020-06-02 at 19:48 +0530, Sumit Garg wrote:
> > Add support for TEE based trusted keys where TEE provides the
> > functionality to seal and unseal trusted keys using hardware unique
> > key. Also, this is an alternative in case platform doesn't possess a
> > TPM device.
>
> So here's a meta problem: in the case when the platform possesses both
> TEE and TPM what should it do?
IMO, trust source (either a TPM or a TEE) should be unique and
carefully chosen as per platform security policy corresponding to a
particular threat model.
And moreover TEEs have been mostly used in the embedded world where
having a hardware TPM is cumbersome given constraints regarding BoM
cost and hardware resources.
> Things like this:
>
> > --- a/security/keys/trusted-keys/trusted_core.c
> > +++ b/security/keys/trusted-keys/trusted_core.c
> > @@ -25,6 +25,8 @@
> >
> > #if defined(CONFIG_TRUSTED_TPM)
> > static struct trusted_key_ops *trusted_key_ops =
> > &tpm_trusted_key_ops;
> > +#elif defined(CONFIG_TRUSTED_TEE)
> > +static struct trusted_key_ops *trusted_key_ops =
> > &tee_trusted_key_ops;
> > #else
>
> Say it's either/or at a Kconfig level: so if you select both TEE and
> TPM based trusted keys at compile time, we intall the TPM ops and
> ignore the TEE ops, is that right? Surely this should be runtime
> selectable based on what the platform has ...
This dynamic selection was already part of v4 patch-set but after
objection from Jarrko here [1], I switched to compile time mode
instead.
[1] https://lkml.org/lkml/2020/6/2/139
> perhaps it should even be
> selectable per key?
>
> Once it is runtime selectable, what should be selected in the both
> case? Or should we allow the user to decide, if so, how?
>
> when you pipe a trusted key, I think the subtype (TEE or TPM) should be
> part of the piped information, so it loads again seamlessly. This
> would actually be fixed by something like the ASN.1 scheme I'm trying
> to upstream, at least for TPM keys, but do TEE keys have a recognized
> ASN.1 format?
>
I guess this is something which we can refine later if there are real
platforms that have a particular security requirement to support both
TPM and a TEE.
-Sumit
> James
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [REPORT: armv7m/stm32] mmap -6 error on armv7m no-mmu platform
From: dillon min @ 2020-06-03 8:07 UTC (permalink / raw)
To: hch, m.szyprowski, robin.murphy, sumit.semwal
Cc: Benjamin GAIGNARD, Alexandre Torgue, Linux Kernel Mailing List,
linaro-mm-sig, linux-stm32, Linux ARM, linux-media
[-- Attachment #1: Type: text/plain, Size: 3200 bytes --]
Hi, Christoph Hellwig, folks,
i just writing a driver for stm32f4's dma2d controller(/dev/video0
v4l2-m2m device), got following mmap -6 error
(No such device or address) at user space.
working environment is:
hardware: stm32f469-disco board, ARM Cortex-M4 up to 180MHz with FPU,
ArmV7M, no d-cache, no i-cache
kernel: 5.7.0-rc7 commitid: d16eea2fa5a1ed9bc1788db39a76017916dc7f25
app code:
int fb_fd = open("/dev/fb0", O_RDWR);
if (ioctl(fb_fd, FBIOGET_FSCREENINFO, &fix) < 0) {
perror("ioctl FBIOGET_FSCREENINFO");
close(fb_fd);
return -1;
}
char *fbuffer = mmap(NULL,
fix.smem_len,
PROT_READ | PROT_WRITE, MAP_SHARED,
fb_fd,
0);
if (fbuffer == MAP_FAILED) {
perror("mmap framebuffer");
close(fb_fd);
return -1;
}
also tried mmap /dev/fb0 to userspace , get the same error.
after some debug, it's seems some side effect created by
Fixes: 34dc0ea6bc96 ("dma-direct: provide mmap and get_sgtable method
overrides")
arch/arm/mm/dma-mapping-nommu.c
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
const struct iommu_ops *iommu, bool coherent)
{
if (IS_ENABLED(CONFIG_CPU_V7M)) {
/*
* Cache support for v7m is optional, so can be treated as
* coherent if no cache has been detected. Note that it is not
* enough to check if MPU is in use or not since in absense of
* MPU system memory map is used.
*/
dev->archdata.dma_coherent = (cacheid) ? coherent : true;
} else {
/*
* Assume coherent DMA in case MMU/MPU has not been set up.
*/
dev->archdata.dma_coherent = (get_cr() & CR_M) ?
coherent : true;
}
if (!dev->archdata.dma_coherent)
set_dma_ops(dev, &arm_nommu_dma_ops);
}
CONFIG_CPU_V7M defined since !MMU,
'cacheid' is 0, 'dev->archdata.dma_coherent' is true, don't call set_dma_ops().
cause get_dma_ops() return NULL. so , dma_is_direct() return true.
kernel/dma/mapping.c
int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
if (dma_is_direct(ops))
return dma_direct_mmap(dev, vma, cpu_addr, dma_addr, size,
attrs);
if (!ops->mmap)
return -ENXIO;
return ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
dma_direct_mmap() always return -ENXIO(-6) since CONFIG_MMU wasn't
defined for armv7m arch.
so, dma_mmap_attrs() -> dma_direct_mmap() -> -ENXIO, mmap on no-mmu platform
will get erro -6 all the time.
i'm not sure if there something wrong with my kernel config, so with
.config file attached.
Hi, Alexandre Torgue,
did st's test team verify the dcmi function with recently kernel
version? thanks.
thanks.
best regards.
Dillon,
[-- Attachment #2: config.tar.gz --]
[-- Type: application/x-gzip, Size: 19430 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Security Random Number Generator support
From: Neal Liu @ 2020-06-03 7:54 UTC (permalink / raw)
To: Marc Zyngier
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Julius Werner, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Sean Wang, lkml, wsd_upstream, Crystal Guo (郭晶),
Rob Herring, Neal Liu, Linux Crypto Mailing List, Matt Mackall,
Matthias Brugger, linux-mediatek, Ard Biesheuvel, Linux ARM
In-Reply-To: <fcbe37f6f9cbcde24f9c28bc504f1f0e@kernel.org>
On Wed, 2020-06-03 at 08:40 +0100, Marc Zyngier wrote:
> On 2020-06-03 08:29, Neal Liu wrote:
> > On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote:
> >> On 2020-06-02 13:14, Ard Biesheuvel wrote:
> >> > On Tue, 2 Jun 2020 at 10:15, Neal Liu <neal.liu@mediatek.com> wrote:
> >> >>
> >> >> These patch series introduce a security random number generator
> >> >> which provides a generic interface to get hardware rnd from Secure
> >> >> state. The Secure state can be Arm Trusted Firmware(ATF), Trusted
> >> >> Execution Environment(TEE), or even EL2 hypervisor.
> >> >>
> >> >> Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs.
> >> >> For security awareness SoCs on ARMv8 with TrustZone enabled,
> >> >> peripherals like entropy sources is not accessible from normal world
> >> >> (linux) and rather accessible from secure world (HYP/ATF/TEE) only.
> >> >> This driver aims to provide a generic interface to Arm Trusted
> >> >> Firmware or Hypervisor rng service.
> >> >>
> >> >>
> >> >> changes since v1:
> >> >> - rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can
> >> >> reuse
> >> >> this driver.
> >> >> - refine coding style and unnecessary check.
> >> >>
> >> >> changes since v2:
> >> >> - remove unused comments.
> >> >> - remove redundant variable.
> >> >>
> >> >> changes since v3:
> >> >> - add dt-bindings for MediaTek rng with TrustZone enabled.
> >> >> - revise HWRNG SMC call fid.
> >> >>
> >> >> changes since v4:
> >> >> - move bindings to the arm/firmware directory.
> >> >> - revise driver init flow to check more property.
> >> >>
> >> >> changes since v5:
> >> >> - refactor to more generic security rng driver which
> >> >> is not platform specific.
> >> >>
> >> >> *** BLURB HERE ***
> >> >>
> >> >> Neal Liu (2):
> >> >> dt-bindings: rng: add bindings for sec-rng
> >> >> hwrng: add sec-rng driver
> >> >>
> >> >
> >> > There is no reason to model a SMC call as a driver, and represent it
> >> > via a DT node like this.
> >>
> >> +1.
> >>
> >> > It would be much better if this SMC interface is made truly generic,
> >> > and wired into the arch_get_random() interface, which can be used much
> >> > earlier.
> >>
> >> Wasn't there a plan to standardize a SMC call to rule them all?
> >>
> >> M.
> >
> > Could you give us a hint how to make this SMC interface more generic in
> > addition to my approach?
> > There is no (easy) way to get platform-independent SMC function ID,
> > which is why we encode it into device tree, and provide a generic
> > driver. In this way, different devices can be mapped and then get
> > different function ID internally.
>
> The idea is simply to have *one* single ID that caters for all
> implementations, just like we did for PSCI at the time. This
> requires ARM to edict a standard, which is what I was referring
> to above.
>
> There is zero benefit in having a platform-dependent ID. It just
> pointlessly increases complexity, and means we cannot use the RNG
> before the firmware tables are available (yes, we need it that
> early).
>
> M.
Do you know which ARM expert could edict this standard?
Or is there any chance that we can make one? And be reviewed by
maintainers?
_______________________________________________
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] media: stm32-dcmi: Set minimum cpufreq requirement
From: Vincent Guittot @ 2020-06-03 7:50 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: Alexandre TORGUE, rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, Hugues FRUCHET, mchehab@kernel.org,
Valentin Schneider, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
In-Reply-To: <1b0ace18-e7f8-0b75-f6fe-968a269626b0@st.com>
On Wed, 3 Jun 2020 at 09:34, Benjamin GAIGNARD <benjamin.gaignard@st.com> wrote:
>
>
>
> On 6/2/20 3:35 PM, Valentin Schneider wrote:
> > On 02/06/20 12:37, Benjamin GAIGNARD wrote:
> >> On 6/2/20 11:31 AM, Valentin Schneider wrote:
> >>>> @@ -99,6 +100,8 @@ enum state {
> >>>>
> >>>> #define OVERRUN_ERROR_THRESHOLD 3
> >>>>
> >>>> +#define DCMI_MIN_FREQ 650000 /* in KHz */
> >>>> +
> >>> This assumes the handling part is guaranteed to always run on the same CPU
> >>> with the same performance profile (regardless of the platform). If that's
> >>> not guaranteed, it feels like you'd want this to be configurable in some
> >>> way.
> >> Yes I could add a st,stm32-dcmi-min-frequency (in KHz) parameter the
> >> device tree node.
> >>
> > Something like that - I'm not sure how well this fits with the DT
> > landscape, as you could argue it isn't really a description of the
> > hardware, more of a description of the performance expectations of the
> > software. I won't really argue here.
> >
> >>>> struct dcmi_graph_entity {
> >>>> struct v4l2_async_subdev asd;
> >>>>
> >>> [...]
> >>>> @@ -2020,6 +2042,8 @@ static int dcmi_probe(struct platform_device *pdev)
> >>>> goto err_cleanup;
> >>>> }
> >>>>
> >>>> + dcmi->policy = cpufreq_cpu_get(0);
> >>>> +
> >>> Ideally you'd want to fetch the policy of the CPU your IRQ (and handling
> >>> thread) is affined to; The only compatible DTS I found describes a single
> >>> A7, which is somewhat limited in the affinity area...
> >> If I move this code just before start streaming and use get_cpu(), would
> >> it works ?
> >>
> > AFAIA streaming_start() is not necessarily executing on the same CPU as the
> > one that will handle the interrupt. I was thinking you could use the IRQ's
> > effective affinity as a hint of which CPU(s) to boost, i.e. something like:
> >
> > ---
> > struct cpumask_var_t visited;
> > struct irq_data *d = irq_get_irq_data(irq);
> >
> > err = alloc_cpumask_var(visited, GFP_KERNEL);
> > /* ... */
> > for_each_cpu(cpu, irq_data_get_effective_affinity_mask(d)) {
> > /* check if not already spanned */
> > if (cpumask_test_cpu(cpu, visited))
> > continue;
> >
> > policy = cpufreq_cpu_get(cpu);
> > cpumask_or(visited, visited, policy->cpus);
> > /* do the boost for that policy here */
> > /* ... */
> > cpufreq_cpu_put(policy);
> > }
> > ---
> >
> > That of course falls apart when hotplug gets involved, and the effective
> > affinity changes... There's irq_set_affinity_notifier() out there, but it
> > seems it's only about the affinity, not the effective_affinity, I'm not
> > sure how valid it would be to query the effective_affinity in that
> > notifier.
> If I wait to be in the irq it will be too late so I think I will do a
> loop over all possible CPUs
> before start the streaming to change the policies.
Can't you use irq_get_affinity_mask and loop over it ?
Also You should better use freq_qos_add/remove_request during probe
and remove of the driver and use freq_qos_update_request in
dcmi_start/stop_streaming to set/unset your constraint.
>
> >
> >> Benjamin
> >>>> dev_info(&pdev->dev, "Probe done\n");
> >>>>
> >>>> platform_set_drvdata(pdev, dcmi);
> >>>> @@ -2049,6 +2073,9 @@ static int dcmi_remove(struct platform_device *pdev)
> >>>>
> >>>> pm_runtime_disable(&pdev->dev);
> >>>>
> >>>> + if (dcmi->policy)
> >>>> + cpufreq_cpu_put(dcmi->policy);
> >>>> +
> >>>> v4l2_async_notifier_unregister(&dcmi->notifier);
> >>>> v4l2_async_notifier_cleanup(&dcmi->notifier);
> >>>> media_entity_cleanup(&dcmi->vdev->entity);
_______________________________________________
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