* Re: [PATCH] efi/libstub: refactor Makefile to not use lib-y syntax
From: Ard Biesheuvel @ 2020-06-03 12:42 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: <CAK7LNAQ_YMfjucip8eFBod1TBMUqGgnYebBeP22dZ4J7ZsFXeg@mail.gmail.com>
On Wed, 3 Jun 2020 at 13:23, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Wed, Jun 3, 2020 at 6:16 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > 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?
>
>
> --whole-archive literally links the whole of the archive.
> If there are duplicate definitions, the linking fails
> due to multiple definition.
> So, --whole-archive is similar to linking .o files
> in this regard.
>
>
> There is a point for arm and x86 because
> the decompressor link does not use --whole-archive.
>
> As for arm64, there is no point,
> but you can pass lib.a after --no-whole-archive
> by the following patch.
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 650e1185c190..48a6afa774fc 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -145,7 +145,7 @@ 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
> +libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> # Default target when executing plain make
> boot := arch/arm64/boot
>
>
>
> Then, _efistub_efi_low_alloc_above
> and __efistub_efi_relocate_kernel will be dropped.
>
>
> If you like the static library
> do you want me to send v2?
>
Yes please
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64 build issue and mainline crash (was Re: linux-next: Tree for Jun 3)
From: Ard Biesheuvel @ 2020-06-03 12:38 UTC (permalink / raw)
To: Stephen Rothwell, Masahiro Yamada
Cc: John Garry, Linux Next Mailing List, Linux ARM,
Linux Kernel Mailing List
In-Reply-To: <20200603222026.4cf661e0@canb.auug.org.au>
On Wed, 3 Jun 2020 at 14:20, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Just resending to get past the infradead.org mail filters (hopefully).
>
> On Wed, 3 Jun 2020 22:13:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi John,
> >
> > On Wed, 3 Jun 2020 12:45:18 +0100 John Garry <john.garry@huawei.com> wrote:
> > >
> > > On 03/06/2020 12:06, Stephen Rothwell wrote:
> > >
> > > JFYI, I am finding the vanilla defconfig build broken for arm64:
> > >
> > > LD vmlinux.o
> > >
> > >
> > > /home/john/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld:
> > > cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file
> > > or directory
> > > make[1]: *** [vmlinux] Error 1
> > >
> > >
> > > make: *** [__sub-make] Error 2
> > >
> > >
> > > john@htsatcamb-server:~/linux-next$
> > >
> > > In addition, the reason I was testing this was because Linus' master
> > > (d6f9469a03d8 Merge tag 'erofs-for-5.8-rc1' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs) was crashing:
> > >
> > > [ 5.368948] loop: module loaded
> > > [ 5.372113] Unable to handle kernel paging request at virtual address
> > > fffff9ffcfec4000
> > > [ 5.380067] Mem abort info:
> > > [ 5.382865]ESR = 0x96000044
> > > [ 5.385927]EC = 0x25: DABT (current EL), IL = 32 bits
> > > [ 5.391260]SET = 0, FnV = 0
> > > [ 5.394319]EA = 0, S1PTW = 0
> > > [ 5.397467] Data abort info:
> > > [ 5.400354]ISV = 0, ISS = 0x00000044
> > > [ 5.404203]CM = 0, WnR = 1
> > > [ 5.407178] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000002f3f1000
> > > [ 5.413909] [fffff9ffcfec4000] pgd=0000000000000000
> > > [ 5.418807] Internal error: Oops: 96000044 [#1] PREEMPT SMP
> > > [ 5.424399] Modules linked in:
> > > [ 5.427462] CPU: 11 PID: 1 Comm: swapper/0 Not tainted
> > > 5.7.0-05047-gd6f9469a03d8 #388
> > > [ 5.435325] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05
> > > IT21 Nemo 2.0 RC0 04/18/2018
> > > [ 5.444499] pstate: 40000005 (nZcv daif -PAN -UAO BTYPE=--)
> > > [ 5.450098] pc : __memset+0x16c/0x1c0
> > > [ 5.453770] lr : pcpu_alloc+0x1a0/0x668
> > > [ 5.457615] sp : ffff800011d3bbd0
> > > [ 5.460936] x29: ffff800011d3bbd0 x28: ffff001fb5495180
> > > [ 5.466267] x27: 0000000000000001 x26: 0000000000000100
> > > [ 5.471597] x25: 0000000000000001 x24: 0000000000000001
> > > [ 5.476928] x23: ffff80001135e9a0 x22: ffff80001196a200
> > > [ 5.482259] x21: ffff80001196a360 x20: 0000000000000000
> > > [ 5.487590] x19: 0000000000000000 x18: fffffe107e6fdb08
> > > [ 5.492920] x17: 000000000000003f x16: 0000000000000000
> > > [ 5.498251] x15: ffff001ffbffee00 x14: 0000000000000002
> > > [ 5.503581] x13: 0000000000000000 x12: 000000000000003f
> > > [ 5.508912] x11: 0000000000000040 x10: 0000000000000040
> > > [ 5.514243] x9 : 0000000000000000 x8 : fffff9ffcfec4000
> > > [ 5.519573] x7 : 0000000000000000 x6 : 000000000000003f
> > > [ 5.524904] x5 : 0000000000000040 x4 : 0000000000000000
> > > [ 5.530234] x3 : 0000000000000004 x2 : 00000000000000c0
> > > [ 5.535565] x1 : 0000000000000000 x0 : fffff9ffcfec4000
> > > [ 5.540896] Call trace:
> > > [ 5.543344] __memset+0x16c/0x1c0
> > > [ 5.546666] __alloc_percpu+0x14/0x1c
> > > [ 5.550338] alloc_workqueue+0x164/0x42c
> > > [ 5.554273] init+0x24/0xa4
> > > [ 5.557071] do_one_initcall+0x50/0x194
> > > [ 5.560917] kernel_init_freeable+0x1e4/0x250
> > > [ 5.565288] kernel_init+0x10/0x104
> > > [ 5.568785] ret_from_fork+0x10/0x18
> > > [ 5.572372] Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
> > > [ 5.578568] ---[ end trace 63c299bbe9b8ea9e ]---
> > > [ 5.583205] Kernel panic - not syncing: Attempted to kill init!
> > > exitcode=0x0000000b
> > > [ 5.590903] SMP: stopping secondary CPUs
> > > [ 5.594846] Kernel Offset: 0xf0000 from 0xffff800010000000
> > > [ 5.600350] PHYS_OFFSET: 0x0
> > > [ 5.603235] CPU features: 0x240022,20806008
> > > [ 5.607430] Memory Limit: none
> > > [ 5.610500] ---[ end Kernel panic - not syncing: Attempted to kill init!
> > > exitcode=0x0000000b ]---
> > >
> > > I'll check that when I get a chance. Maybe all just transient.
> >
> > Yeah, I forgot to add a patch to make arm64 build again (it will be in
> > linux-next tomorrow). If you want to apply it to your tree, here is
> > what I was given:
> >
> > diff --git a/Makefile b/Makefile
> > index f80c4ff93ec9..fbb4b95ae648 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1074,7 +1074,7 @@ build-dirs := $(vmlinux-dirs)
> > clean-dirs := $(vmlinux-alldirs)
> >
> > # Externally visible symbols (used by link-vmlinux.sh)
> > -KBUILD_VMLINUX_OBJS := $(head-y) $(addsuffix built-in.a, $(core-y))
> > +KBUILD_VMLINUX_OBJS := $(head-y) $(patsubst %/,%/built-in.a, $(core-y))
> > KBUILD_VMLINUX_OBJS += $(addsuffix built-in.a, $(filter %/, $(libs-y)))
> > ifdef CONFIG_MODULES
> > KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)))
>
9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4 is the first bad commit
commit 9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4
Author: Masahiro Yamada <masahiroy@kernel.org>
Date: Mon Jun 1 14:56:59 2020 +0900
kbuild: refactor KBUILD_VMLINUX_{OBJS,LIBS} calculation
Do not overwrite core-y or drivers-y. Remove libs-y1 and libs-y2.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
_______________________________________________
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] pinctrl: freescale: imx: Use 'devm_of_iomap()' to avoid a resource leak in case of error in 'imx_pinctrl_probe()'
From: Linus Walleij @ 2020-06-03 12:36 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Dong Aisheng, Adrian Alonso, Fabio Estevam, Sascha Hauer,
Stefan Agner, open list:GPIO SUBSYSTEM, NXP Linux Team,
Sascha Hauer, Dan Carpenter, Shawn Guo, Linux ARM
In-Reply-To: <20200602200626.677981-1-christophe.jaillet@wanadoo.fr>
On Tue, Jun 2, 2020 at 10:06 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Use 'devm_of_iomap()' instead 'of_iomap()' to avoid a resource leak in
> case of error.
>
> Update the error handling code accordingly.
>
> Fixes: 26d8cde5260b ("pinctrl: freescale: imx: add shared input select reg support")
> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied!
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
* Re: [PATCH] pinctrl: freescale: imx: Fix an error handling path in 'imx_pinctrl_probe()'
From: Linus Walleij @ 2020-06-03 12:34 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Dong Aisheng, Fabio Estevam, Sascha Hauer, kernel-janitors,
linux-kernel@vger.kernel.org, Stefan Agner, Gary Bisson,
open list:GPIO SUBSYSTEM, NXP Linux Team, Sascha Hauer, Shawn Guo,
Linux ARM
In-Reply-To: <20200530204955.588962-1-christophe.jaillet@wanadoo.fr>
On Sat, May 30, 2020 at 10:49 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> 'pinctrl_unregister()' should not be called to undo
> 'devm_pinctrl_register_and_init()', it is already handled by the framework.
>
> This simplifies the error handling paths of the probe function.
> The 'imx_free_resources()' can be removed as well.
>
> Fixes: a51c158bf0f7 ("pinctrl: imx: use radix trees for groups and functions")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied!
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
* Re: [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal
From: Tomi Valkeinen @ 2020-06-03 12:33 UTC (permalink / raw)
To: Tony Lindgren, linux-omap
Cc: Nishanth Menon, Tero Kristo, Grygorii Strashko, Dave Gerlach,
Keerthy, linux-kernel, dri-devel, Andrew F . Davis,
Peter Ujfalusi, Faiz Abbas, Laurent Pinchart, Greg Kroah-Hartman,
Suman Anna, linux-arm-kernel, Roger Quadros
In-Reply-To: <20200531193941.13179-2-tony@atomide.com>
Hi Tony,
On 31/05/2020 22:39, Tony Lindgren wrote:
> When booting without legacy platform data, we no longer have omap_device
> calling PM runtime suspend for us on suspend. This causes the driver
> context not be saved as we have no suspend and resume functions defined.
>
> Let's fix the issue by switching over to use UNIVERSAL_DEV_PM_OPS as it
> will call the existing PM runtime suspend functions on suspend.
I don't think we can use UNIVERSAL_DEV_PM_OPS, as we can't disable DSS modules in any order, but
things have to be shut down in orderly manner.
omapdrm hasn't relied on omap_device calling runtime suspend for us (I didn't know it does that). We
have system suspend hooks in omap_drv.c:
SIMPLE_DEV_PM_OPS(omapdrm_pm_ops, omap_drm_suspend, omap_drm_resume)
omap_drm_suspend() is supposed to turn off the displays, which then cause dispc_runtime_put (and
other runtime_puts) to be called, which result in dispc_runtime_suspend (and other runtime PM suspends).
So... For some reason that's no longer happening? I need to try to find a board with which
suspend/resume works (without DSS)...
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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] pinctrl: sirf: add missing put_device() call in sirfsoc_gpio_probe()
From: Linus Walleij @ 2020-06-03 12:32 UTC (permalink / raw)
To: yu kuai
Cc: Barry Song, yi.zhang, linux-kernel@vger.kernel.org, Yuping Luo,
open list:GPIO SUBSYSTEM, Markus Elfring, Linux ARM
In-Reply-To: <20200603013532.755220-1-yukuai3@huawei.com>
On Wed, Jun 3, 2020 at 3:36 AM yu kuai <yukuai3@huawei.com> wrote:
> A coccicheck run provided information like the following:
>
> drivers/pinctrl/sirf/pinctrl-sirf.c:798:2-8: ERROR: missing put_device;
> call of_find_device_by_node on line 792, but without a corresponding
> object release within this function.
>
> Generated by: scripts/coccinelle/free/put_device.cocci
>
> Thus add a jump target to fix the exception handling for this
> function implementation.
>
> Fixes: 5130216265f6 ("PINCTRL: SiRF: add GPIO and GPIO irq support in CSR SiRFprimaII")
> Signed-off-by: yu kuai <yukuai3@huawei.com>
Patch applied, thanks!
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
* Re: [PATCH] pinctrl: imxl: Fix an error handling path in 'imx1_pinctrl_core_probe()'
From: Linus Walleij @ 2020-06-03 12:31 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Dong Aisheng, Fabio Estevam, Sascha Hauer, kernel-janitors,
linux-kernel@vger.kernel.org, Stefan Agner,
open list:GPIO SUBSYSTEM, Laxman Dewangan, NXP Linux Team,
Sascha Hauer, Shawn Guo, Linux ARM
In-Reply-To: <20200530201952.585798-1-christophe.jaillet@wanadoo.fr>
On Sat, May 30, 2020 at 10:20 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> When 'pinctrl_register()' has been turned into 'devm_pinctrl_register()',
> an error handling path has not been updated.
>
> Axe a now unneeded 'pinctrl_unregister()'.
>
> Fixes: e55e025d1687 ("pinctrl: imxl: Use devm_pinctrl_register() for pinctrl registration")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied.
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
* Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Sai Prakash Ranjan @ 2020-06-03 12:26 UTC (permalink / raw)
To: Robin Murphy
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, coresight,
linux-kernel, Stephen Boyd, linux-arm-kernel, Mike Leach
In-Reply-To: <6c1a4fbd-98cb-a49c-0ced-1318d5d5e7c8@arm.com>
Hi Robin,
On 2020-06-03 17:51, Robin Murphy wrote:
> On 2020-06-03 13:00, Sai Prakash Ranjan wrote:
>> Hi Robin, Mathieu
>>
>> On 2020-06-03 17:07, Robin Murphy wrote:
>>> On 2020-06-01 22:28, Mathieu Poirier wrote:
>>>> That being said I'm sure that dependencies on an IOMMU isn't a
>>>> problem confined
>>>> to coresight. I am adding Robin Murphy, who added this commit [1],
>>>> to the thread
>>>> in the hope that he can provide guidance on the right way to do
>>>> this.
>>>
>>> Right, it's not specific to CoreSight, and it's not even specific to
>>> IOMMUs really. In short, blame kexec ;)
>>>
>>
>> Yes it is not specific to coresight, we are targeting this for all
>> consumers/clients of SMMU(atleast on SC7180 SoC). We have display
>> throwing
>> NoC/interconnect errors[1] during reboot after SMMU is disabled.
>> This is also not specific to kexec either as you explained here [2]
>> about
>> a case with display which is exacly what is happening in our system
>> [1].
>
> Sure, but those instances are begging the question of why the SMMU is
> disabled at reboot in the first place ;)
>
That is what happens in SMMU shutdown callback right? It is the
reboot/shutdown
flow.
arm_smmu_device_shutdown()
platform_drv_shutdown()
device_shutdown()
kernel_restart_prepare()
kernel_restart()
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
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] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Robin Murphy @ 2020-06-03 12:21 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, coresight,
linux-kernel, Stephen Boyd, linux-arm-kernel, Mike Leach
In-Reply-To: <1549935cf69ac3a006f32eb278821027@codeaurora.org>
On 2020-06-03 13:00, Sai Prakash Ranjan wrote:
> Hi Robin, Mathieu
>
> On 2020-06-03 17:07, Robin Murphy wrote:
>> On 2020-06-01 22:28, Mathieu Poirier wrote:
>>> That being said I'm sure that dependencies on an IOMMU isn't a
>>> problem confined
>>> to coresight. I am adding Robin Murphy, who added this commit [1], to
>>> the thread
>>> in the hope that he can provide guidance on the right way to do this.
>>
>> Right, it's not specific to CoreSight, and it's not even specific to
>> IOMMUs really. In short, blame kexec ;)
>>
>
> Yes it is not specific to coresight, we are targeting this for all
> consumers/clients of SMMU(atleast on SC7180 SoC). We have display throwing
> NoC/interconnect errors[1] during reboot after SMMU is disabled.
> This is also not specific to kexec either as you explained here [2] about
> a case with display which is exacly what is happening in our system [1].
Sure, but those instances are begging the question of why the SMMU is
disabled at reboot in the first place ;)
Robin.
>
> [1]
> https://lore.kernel.org/lkml/1591009402-681-1-git-send-email-mkrishn@codeaurora.org/
>
> [2]
> https://lore.kernel.org/lkml/5858bdac-b7f9-ac26-0c0d-c9653cef841d@arm.com/
>
>> The fundamental thing is that devices should stop any DMA activity at
>> shutdown. For a normal poweroff you can typically get away without
>> doing so, but over kexec, ongoing DMA traffic may corrupt memory in
>> the new kernel (at worst, I think even DMA reads could potentially
>> cause unexpected cache behaviour that might lead to mishaps, given the
>> right combination of memory attributes).
>>
>> IOMMUs merely help to make the situation more serious. For similar
>> kexec reasons, they need to disable any existing translations at
>> shutdown (imagine if the second kernel didn't have an IOMMU driver).
>> And at that point, even the normal poweroff case becomes problematic,
>> because any device DMA that hasn't been shut down beforehand is now
>> not necessarily going benignly to memory as it would in the no-IOMMU
>> case above, but potentially to random physical addresses, with all the
>> hilarity ensuing that you would expect from that.
>>
>
> Thanks,
> Sai
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64 build issue and mainline crash (was Re: linux-next: Tree for Jun 3)
From: Stephen Rothwell @ 2020-06-03 12:20 UTC (permalink / raw)
To: John Garry
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
linux-arm-kernel, Ard Biesheuvel
In-Reply-To: <20200603221341.0705a2f9@canb.auug.org.au>
[-- Attachment #1.1: Type: text/plain, Size: 4792 bytes --]
Hi all,
Just resending to get past the infradead.org mail filters (hopefully).
On Wed, 3 Jun 2020 22:13:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi John,
>
> On Wed, 3 Jun 2020 12:45:18 +0100 John Garry <john.garry@huawei.com> wrote:
> >
> > On 03/06/2020 12:06, Stephen Rothwell wrote:
> >
> > JFYI, I am finding the vanilla defconfig build broken for arm64:
> >
> > LD vmlinux.o
> >
> >
> > /home/john/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld:
> > cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file
> > or directory
> > make[1]: *** [vmlinux] Error 1
> >
> >
> > make: *** [__sub-make] Error 2
> >
> >
> > john@htsatcamb-server:~/linux-next$
> >
> > In addition, the reason I was testing this was because Linus' master
> > (d6f9469a03d8 Merge tag 'erofs-for-5.8-rc1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs) was crashing:
> >
> > [ 5.368948] loop: module loaded
> > [ 5.372113] Unable to handle kernel paging request at virtual address
> > fffff9ffcfec4000
> > [ 5.380067] Mem abort info:
> > [ 5.382865]ESR = 0x96000044
> > [ 5.385927]EC = 0x25: DABT (current EL), IL = 32 bits
> > [ 5.391260]SET = 0, FnV = 0
> > [ 5.394319]EA = 0, S1PTW = 0
> > [ 5.397467] Data abort info:
> > [ 5.400354]ISV = 0, ISS = 0x00000044
> > [ 5.404203]CM = 0, WnR = 1
> > [ 5.407178] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000002f3f1000
> > [ 5.413909] [fffff9ffcfec4000] pgd=0000000000000000
> > [ 5.418807] Internal error: Oops: 96000044 [#1] PREEMPT SMP
> > [ 5.424399] Modules linked in:
> > [ 5.427462] CPU: 11 PID: 1 Comm: swapper/0 Not tainted
> > 5.7.0-05047-gd6f9469a03d8 #388
> > [ 5.435325] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05
> > IT21 Nemo 2.0 RC0 04/18/2018
> > [ 5.444499] pstate: 40000005 (nZcv daif -PAN -UAO BTYPE=--)
> > [ 5.450098] pc : __memset+0x16c/0x1c0
> > [ 5.453770] lr : pcpu_alloc+0x1a0/0x668
> > [ 5.457615] sp : ffff800011d3bbd0
> > [ 5.460936] x29: ffff800011d3bbd0 x28: ffff001fb5495180
> > [ 5.466267] x27: 0000000000000001 x26: 0000000000000100
> > [ 5.471597] x25: 0000000000000001 x24: 0000000000000001
> > [ 5.476928] x23: ffff80001135e9a0 x22: ffff80001196a200
> > [ 5.482259] x21: ffff80001196a360 x20: 0000000000000000
> > [ 5.487590] x19: 0000000000000000 x18: fffffe107e6fdb08
> > [ 5.492920] x17: 000000000000003f x16: 0000000000000000
> > [ 5.498251] x15: ffff001ffbffee00 x14: 0000000000000002
> > [ 5.503581] x13: 0000000000000000 x12: 000000000000003f
> > [ 5.508912] x11: 0000000000000040 x10: 0000000000000040
> > [ 5.514243] x9 : 0000000000000000 x8 : fffff9ffcfec4000
> > [ 5.519573] x7 : 0000000000000000 x6 : 000000000000003f
> > [ 5.524904] x5 : 0000000000000040 x4 : 0000000000000000
> > [ 5.530234] x3 : 0000000000000004 x2 : 00000000000000c0
> > [ 5.535565] x1 : 0000000000000000 x0 : fffff9ffcfec4000
> > [ 5.540896] Call trace:
> > [ 5.543344] __memset+0x16c/0x1c0
> > [ 5.546666] __alloc_percpu+0x14/0x1c
> > [ 5.550338] alloc_workqueue+0x164/0x42c
> > [ 5.554273] init+0x24/0xa4
> > [ 5.557071] do_one_initcall+0x50/0x194
> > [ 5.560917] kernel_init_freeable+0x1e4/0x250
> > [ 5.565288] kernel_init+0x10/0x104
> > [ 5.568785] ret_from_fork+0x10/0x18
> > [ 5.572372] Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
> > [ 5.578568] ---[ end trace 63c299bbe9b8ea9e ]---
> > [ 5.583205] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0000000b
> > [ 5.590903] SMP: stopping secondary CPUs
> > [ 5.594846] Kernel Offset: 0xf0000 from 0xffff800010000000
> > [ 5.600350] PHYS_OFFSET: 0x0
> > [ 5.603235] CPU features: 0x240022,20806008
> > [ 5.607430] Memory Limit: none
> > [ 5.610500] ---[ end Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0000000b ]---
> >
> > I'll check that when I get a chance. Maybe all just transient.
>
> Yeah, I forgot to add a patch to make arm64 build again (it will be in
> linux-next tomorrow). If you want to apply it to your tree, here is
> what I was given:
>
> diff --git a/Makefile b/Makefile
> index f80c4ff93ec9..fbb4b95ae648 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1074,7 +1074,7 @@ build-dirs := $(vmlinux-dirs)
> clean-dirs := $(vmlinux-alldirs)
>
> # Externally visible symbols (used by link-vmlinux.sh)
> -KBUILD_VMLINUX_OBJS := $(head-y) $(addsuffix built-in.a, $(core-y))
> +KBUILD_VMLINUX_OBJS := $(head-y) $(patsubst %/,%/built-in.a, $(core-y))
> KBUILD_VMLINUX_OBJS += $(addsuffix built-in.a, $(filter %/, $(libs-y)))
> ifdef CONFIG_MODULES
> KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)))
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/4] pinctrl: bcm2835: Add support for wake-up interrupts
From: Linus Walleij @ 2020-06-03 12:17 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Scott Branden, Ray Jui, Matti Vaittinen,
linux-kernel@vger.kernel.org, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200531001101.24945-1-f.fainelli@gmail.com>
On Sun, May 31, 2020 at 2:11 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> This patch series updates the bcm2835 pinctrl driver to support
> the BCM7211 SoC which is quite similar to 2711 (Raspberry Pi 4)
> except that it also supports wake-up interrupts.
>
> Thanks!
>
> Changes in v3:
>
> - added Rob's Acked-by for the binding patches (#1 and #2)
> - correct check on the number of GPIOs in irq_set_irq_wake (Stefan)
Applied this v3 version right in time for the merge window.
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
* Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Sai Prakash Ranjan @ 2020-06-03 12:14 UTC (permalink / raw)
To: Mike Leach
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, robin.murphy,
linux-arm-kernel
In-Reply-To: <CAJ9a7Vj9STJw4jBxWU_9wHftj4Q7+k8o1nTc8tr21KjYi0RkpQ@mail.gmail.com>
Hi Mike,
On 2020-06-03 16:57, Mike Leach wrote:
> Hi,
>
> On Wed, 3 Jun 2020 at 11:24, Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>>
>> Hi Mike,
>>
>> Thanks again for looking at this.
>>
>> On 2020-06-03 03:42, Mike Leach wrote:
>> [...]
>>
>> >>
>> >> SMMU/IOMMU won't be able to do much here as it is the client's
>> >> responsiblity to
>> >> properly shutdown and SMMU device link just makes sure that
>> >> SMMU(supplier) shutdown is
>> >> called only after its consumers shutdown callbacks are called.
>> >
>> > I think this use case can be handled slightly differently than the
>> > general requirements for modular CoreSight drivers.
>> >
>> > What is needed here is a way of stopping the underlying ETR hardware
>> > from issuing data to the SMMU, until the entire device has been shut
>> > down, in a way that does not remove the driver, breaking existing
>> > references and causing a system crash.
>> >
>> > We could introduce a new mode to the ETR driver - e.g.
>> > CS_MODE_SHUTDOWN.
>> >
>> > At the end of the block tmc_shutdown(struct amba_device *adev), set
>> > drvdata->mode to CS_MODE_SHUTDOWN & remove the coresight_unregister().
>> > This new mode can be used to prevent the underlying hardware from
>> > being able to restart until the device is re-powered.
>> >
>> > This mode can be detected in the code that enables / disables the ETR
>> > and handled appropriately (updates to tmc_enable_etr_sink and
>> > tmc_disable_etr_sink).
>> > This mode will persist until the device is re-started - but because we
>> > are on the device shutdown path this is not an issue.
>> >
>> > This should leave the CoreSight infrastructure stable until the
>> > drivers are shut down normally as part of the device power down
>> > process.
>> >
>>
>> Sounds good to me, but if the coresight_unregister() is the trouble
>> point
>> causing these crashes, then can't we just remove that from
>> tmc_shutdown()
>> callback? This would be like maintaining the same behaviour as now
>> where
>> on reboot/shutdown we basically don't do anything except for disabling
>> ETR.
>
> No - the new mode prevents race conditions where the thread shutting
> down the SMMU does the ETR shutdown, but then another thread happens
> to be trying to start trace and restarts the ETR.
> It also prevents the condition Mathieu discussed where a thread might
> be attempting to shutdown trace - this could try to disable the
> hardware again re-releasing resources/ re-flushing and waiting for
> stop.
>
I do not think there will a race between SMMU shutdown and ETR shutdown.
Driver core takes care of calling SMMU shutdown after its consumer
shutdown callbacks via device link, otherwise there would already be
bugs in all other client drivers.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
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 14/15] dt-bindings: pinctrl: stm32: Add missing interrupts property
From: Linus Walleij @ 2020-06-03 12:10 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre TORGUE, Greg KH, linux-usb,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
Rob Herring, Maxime Coquelin, linux-stm32, Linux ARM
In-Reply-To: <20200513145935.22493-15-benjamin.gaignard@st.com>
On Wed, May 13, 2020 at 5:00 PM Benjamin Gaignard
<benjamin.gaignard@st.com> wrote:
> Driver use interrupt-parent field so update the bindings to allow it.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Patch applied.
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
* Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Sai Prakash Ranjan @ 2020-06-03 12:00 UTC (permalink / raw)
To: Robin Murphy
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, coresight,
linux-kernel, Stephen Boyd, linux-arm-kernel, Mike Leach
In-Reply-To: <bf7e8ac2-51b2-d9cb-9c4f-c311297accac@arm.com>
Hi Robin, Mathieu
On 2020-06-03 17:07, Robin Murphy wrote:
> On 2020-06-01 22:28, Mathieu Poirier wrote:
>> That being said I'm sure that dependencies on an IOMMU isn't a problem
>> confined
>> to coresight. I am adding Robin Murphy, who added this commit [1], to
>> the thread
>> in the hope that he can provide guidance on the right way to do this.
>
> Right, it's not specific to CoreSight, and it's not even specific to
> IOMMUs really. In short, blame kexec ;)
>
Yes it is not specific to coresight, we are targeting this for all
consumers/clients of SMMU(atleast on SC7180 SoC). We have display
throwing
NoC/interconnect errors[1] during reboot after SMMU is disabled.
This is also not specific to kexec either as you explained here [2]
about
a case with display which is exacly what is happening in our system [1].
[1]
https://lore.kernel.org/lkml/1591009402-681-1-git-send-email-mkrishn@codeaurora.org/
[2]
https://lore.kernel.org/lkml/5858bdac-b7f9-ac26-0c0d-c9653cef841d@arm.com/
> The fundamental thing is that devices should stop any DMA activity at
> shutdown. For a normal poweroff you can typically get away without
> doing so, but over kexec, ongoing DMA traffic may corrupt memory in
> the new kernel (at worst, I think even DMA reads could potentially
> cause unexpected cache behaviour that might lead to mishaps, given the
> right combination of memory attributes).
>
> IOMMUs merely help to make the situation more serious. For similar
> kexec reasons, they need to disable any existing translations at
> shutdown (imagine if the second kernel didn't have an IOMMU driver).
> And at that point, even the normal poweroff case becomes problematic,
> because any device DMA that hasn't been shut down beforehand is now
> not necessarily going benignly to memory as it would in the no-IOMMU
> case above, but potentially to random physical addresses, with all the
> hilarity ensuing that you would expect from that.
>
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
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 v8 04/10] drm: bridge: dw_mipi_dsi: allow bridge daisy chaining
From: Adrian Ratiu @ 2020-06-03 12:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, Jernej Skrabec, Heiko Stuebner, Jonas Karlman,
linux-kernel, dri-devel, Andrzej Hajda, linux-imx, linux-rockchip,
kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20200602235139.GS6547@pendragon.ideasonboard.com>
On Wed, 03 Jun 2020, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Adrian,
Hi Laurent,
>
> Thank you for the patch.
>
> On Mon, Apr 27, 2020 at 11:19:46AM +0300, Adrian Ratiu wrote:
>> Up until now the assumption was that the synopsis dsi bridge
>> will directly connect to an encoder provided by the platform
>> driver, but the current practice for drivers is to leave the
>> encoder empty via the simple encoder API and add their logic to
>> their own drm_bridge. Thus we need an ablility to connect the
>> DSI bridge to another bridge provided by the platform driver,
>> so we extend the dw_mipi_dsi bind() API with a new "previous
>> bridge" arg instead of just hardcoding NULL. Cc: Laurent
>> Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
>> Adrian Ratiu <adrian.ratiu@collabora.com> --- New in v8. ---
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++++--
>> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +-
>> include/drm/bridge/dw_mipi_dsi.h | 5 ++++- 3
>> files changed, 9 insertions(+), 4 deletions(-)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
>> 16fd87055e7b7..140ff40fa1b62 100644 ---
>> a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -1456,11
>> +1456,13 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
>> /*
>> * Bind/unbind API, used from platforms based on the component
>> framework. */
>> -int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct
>> drm_encoder *encoder) +int dw_mipi_dsi_bind(struct dw_mipi_dsi
>> *dsi, + struct drm_encoder *encoder, +
>> struct drm_bridge *prev_bridge)
>> { int ret;
>> - ret = drm_bridge_attach(encoder, &dsi->bridge, NULL, 0); +
>> ret = drm_bridge_attach(encoder, &dsi->bridge, prev_bridge, 0);
>
> Please note that chaining of bridges doesn't work well if
> multiple bridges in the chain try to create a connector. This is
> why a DRM_BRIDGE_ATTACH_NO_CONNECTOR flag has been added, with a
> helper to create a connector for a chain of bridges
> (drm_bridge_connector_init()). This won't play well with the
> component framework. I would recommend using the
> of_drm_find_bridge() instead in the rockchip driver, and
> deprecating dw_mipi_dsi_bind().
>
Thank you for this insight, indeed the bridge dw_mipi_dsi_bind()
is clunky and we're making it even more so by possibly
re-inventing drm_bridge_connector_init() with it in a way which
can't work (well it does work but can lead to those nasty
multiple-encoder corner-cases you mention).
I'll address this before posting v9, to try to move to
of_drm_find_bridge() and remove dw_mipi_dsi_bind().
>> if (ret) {
>> DRM_ERROR("Failed to initialize bridge with drm\n");
>> return ret;
>> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
>> index 3feff0c45b3f7..83ef43be78135 100644
>> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
>> @@ -929,7 +929,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
>> return ret;
>> }
>>
>> - ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder);
>> + ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder, NULL);
>> if (ret) {
>> DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
>> return ret;
>> diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
>> index b0e390b3288e8..699b3531f5b36 100644
>> --- a/include/drm/bridge/dw_mipi_dsi.h
>> +++ b/include/drm/bridge/dw_mipi_dsi.h
>> @@ -14,6 +14,7 @@
>> #include <drm/drm_modes.h>
>>
>> struct drm_display_mode;
>> +struct drm_bridge;
>> struct drm_encoder;
>> struct dw_mipi_dsi;
>> struct mipi_dsi_device;
>> @@ -62,7 +63,9 @@ struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device *pdev,
>> const struct dw_mipi_dsi_plat_data
>> *plat_data);
>> void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
>> -int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder);
>> +int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi,
>> + struct drm_encoder *encoder,
>> + struct drm_bridge *prev_bridge);
>> void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
>> void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi *slave);
>>
>
> --
> Regards,
>
> Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: rtc: Convert imxdi rtc to json-schema
From: Anson Huang @ 2020-06-03 11:48 UTC (permalink / raw)
To: a.zummo, alexandre.belloni, robh+dt, shawnguo, s.hauer, kernel,
festevam, stigge, linux-rtc, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
Convert the i.MXDI RTC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/rtc/imxdi-rtc.txt | 20 -----------
.../devicetree/bindings/rtc/imxdi-rtc.yaml | 42 ++++++++++++++++++++++
2 files changed, 42 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
create mode 100644 Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml
diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
deleted file mode 100644
index c797bc9..0000000
--- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* i.MX25 Real Time Clock controller
-
-Required properties:
-- compatible: should be: "fsl,imx25-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- clocks: should contain the phandle for the rtc clock
-- interrupts: rtc alarm interrupt
-
-Optional properties:
-- interrupts: dryice security violation interrupt (second entry)
-
-Example:
-
-rtc@53ffc000 {
- compatible = "fsl,imx25-rtc";
- reg = <0x53ffc000 0x4000>;
- clocks = <&clks 81>;
- interrupts = <25 56>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml
new file mode 100644
index 0000000..6e43926
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/imxdi-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX25 Real Time Clock controller
+
+maintainers:
+ - Roland Stigge <stigge@antcom.de>
+
+properties:
+ compatible:
+ const: fsl,imx25-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: rtc alarm interrupt
+ - description: dryice security violation interrupt
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+examples:
+ - |
+ rtc@53ffc000 {
+ compatible = "fsl,imx25-rtc";
+ reg = <0x53ffc000 0x4000>;
+ clocks = <&clks 81>;
+ interrupts = <25>, <56>;
+ };
--
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 v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Prabhakar Kushwaha @ 2020-06-03 11:47 UTC (permalink / raw)
To: John Donnelly
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, Chen Zhou, Catalin Marinas,
Bhupesh Sharma, RuiRui Yang, kexec mailing list,
Linux Kernel Mailing List, Rob Herring, Simon Horman, James Morse,
guohanjun, Thomas Gleixner, Prabhakar Kushwaha, Will Deacon,
Ingo Molnar, linux-arm-kernel
In-Reply-To: <6EA47B07-5119-49DF-9980-12A2066F22CA@oracle.com>
Hi Chen,
On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>
>
>
> > On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <prabhakar.pkin@gmail.com> wrote:
> >
> > On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <john.p.donnelly@oracle.com> wrote:
> >>
> >> Hi . See below !
> >>
> >>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >>>
> >>> Hi John,
> >>>
> >>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>
> >>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> >>>>> Hi Chen,
> >>>>>
> >>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
> >>>>>> This patch series enable reserving crashkernel above 4G in arm64.
> >>>>>>
> >>>>>> There are following issues in arm64 kdump:
> >>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> >>>>>> when there is no enough low memory.
> >>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> >>>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
> >>>>>> will boot failure because there is no low memory available for allocation.
> >>>>>>
> >>>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
> >>>>>> size low memory.
> >>>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
> >>>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> >>>>>> size low memory for crash kdump kernel devices firstly and then reserve
> >>>>>> memory above 4G.
> >>>>>>
> >>>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
> >>>>>> is specified simultaneously, kernel should reserve specified size low memory
> >>>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
> >>>>>> is below 4G, the other is above 4G.
> >>>>>> In order to distinct from the high region and make no effect to the use of
> >>>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
> >>>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
> >>>>>>
> >>>>>> Besides, we need to modify kexec-tools:
> >>>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
> >>>>>>
> >>>>>> The previous changes and discussions can be retrieved from:
> >>>>>>
> >>>>>> Changes since [v7]
> >>>>>> - Move x86 CRASH_ALIGN to 2M
> >>>>>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
> >>>>>> - Update Documentation/devicetree/bindings/chosen.txt
> >>>>>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
> >>>>>> - Add Tested-by from Jhon and pk
> >>>>>>
> >>>>>> Changes since [v6]
> >>>>>> - Fix build errors reported by kbuild test robot.
> >>>>>>
> >>>>>> Changes since [v5]
> >>>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
> >>>>>> - Delete crashkernel=X,high.
> >>>>>> - Modify crashkernel=X,low.
> >>>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
> >>>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
> >>>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
> >>>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
> >>>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
> >>>>>>
> >>>>>> Changes since [v4]
> >>>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> >>>>>>
> >>>>>> Changes since [v3]
> >>>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
> >>>>>> - Fix some compiling warnings.
> >>>>>>
> >>>>>> Changes since [v2]
> >>>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> >>>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> >>>>>> patch.
> >>>>>>
> >>>>>> Changes since [v1]:
> >>>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> >>>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> >>>>>> in fdt_enforce_memory_region().
> >>>>>> There are at most two crash kernel regions, for two crash kernel regions
> >>>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> >>>>>> and then remove the memory range in the middle.
> >>>>>>
> >>>>>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
> >>>>>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
> >>>>>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
> >>>>>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
> >>>>>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
> >>>>>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
> >>>>>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
> >>>>>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
> >>>>>>
> >>>>>> Chen Zhou (5):
> >>>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
> >>>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
> >>>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
> >>>>>> kdump: update Documentation about crashkernel on arm64
> >>>>>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
> >>>>>>
> >>>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
> >>>>> with bootargs as [2] of primary kernel.
> >>>>> This error observed on ThunderX2 ARM64 platform.
> >>>>>
> >>>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
> >>>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> >>>>> Also **without** this patch-set
> >>>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
> >>>>>
> >>>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> >>>>> More details discussed earlier in
> >>>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> >>>>> solution
> >>>>>
> >>>>> This patch-set is expected to solve similar kind of issue.
> >>>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> >>>>> observation should be considered/fixed. .
> >>>>>
> >>>>> --pk
> >>>>>
> >>>>> [1]
> >>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> >>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>>>> [ 30.367696] NET: Registered protocol family 16
> >>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
> >>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> >>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> >>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> >>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>>>> [ 30.369984] Call trace:
> >>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
> >>>>> [ 30.369991] show_stack+0x20/0x30
> >>>>> [ 30.369997] dump_stack+0xc0/0x10c
> >>>>> [ 30.370001] warn_alloc+0x10c/0x178
> >>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> >>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> >>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
> >>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
> >>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> >>>>> [ 30.370020] do_one_initcall+0x54/0x228
> >>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
> >>>>> [ 30.370031] kernel_init+0x1c/0x110
> >>>>> [ 30.370034] ret_from_fork+0x10/0x18
> >>>>> [ 30.370036] Mem-Info:
> >>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> >>>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> >>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> >>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> >>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> >>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> >>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> >>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>>>> unstable:0kB all_unreclaimable? no
> >>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> >>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>>>> unstable:0kB all_unreclaimable? no
> >>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> >>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> >>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> >>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> >>>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> >>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> >>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> >>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> >>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> >>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
> >>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> >>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> >>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> >>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> >>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> >>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> >>>>> hugepages_surp=0 hugepages_size=1048576kB
> >>>>> [ 30.370130] 0 total pagecache pages
> >>>>> [ 30.370132] 0 pages in swap cache
> >>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> >>>>> [ 30.370135] Free swap = 0kB
> >>>>> [ 30.370136] Total swap = 0kB
> >>>>> [ 30.370137] 2164609 pages RAM
> >>>>> [ 30.370139] 0 pages HighMem/MovableOnly
> >>>>> [ 30.370140] 612331 pages reserved
> >>>>> [ 30.370141] 0 pages hwpoisoned
> >>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> >>>>> coherent allocation
> >>>>
> >>>>
> >>>> During my testing I saw the same error and Chen's solution corrected it .
> >>>
> >>> Which combination you are using on your side? I am using Prabhakar's
> >>> suggested environment and can reproduce the issue
> >>> with or without Chen's crashkernel support above 4G patchset.
> >>>
> >>> I am also using a ThunderX2 platform with latest makedumpfile code and
> >>> kexec-tools (with the suggested patch
> >>> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
> >>>
> >>> Thanks,
> >>> Bhupesh
> >>
> >>
> >> I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
> >>
> >>
> >>
> >> For this failure ,
> >>
> >>>>> DMA: failed to allocate 256 KiB pool for atomic
> >>>>> coherent allocation
> >>
> >>
> >> Is due to :
> >>
> >>
> >> 3618082c
> >> ("arm64 use both ZONE_DMA and ZONE_DMA32")
> >>
> >> With the introduction of ZONE_DMA to support the Raspberry DMA
> >> region below 1G, the crashkernel is placed in the upper 4G
> >> ZONE_DMA_32 region. Since the crashkernel does not have access
> >> to the ZONE_DMA region, it prints out call trace during bootup.
> >>
> >> It is due to having this CONFIG item ON :
> >>
> >>
> >> CONFIG_ZONE_DMA=y
> >>
> >> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
> >> use the device tree to specify memory below 1G.
> >>
> >>
> >
> > Disabling ZONE_DMA is temporary solution. We may need proper solution
>
>
> Perhaps the Raspberry platform configuration dependencies need separated from “server class” Arm equipment ? Or auto-configured on boot ? Consult an expert ;-)
>
>
>
> >
> >> I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
> >
> > I will also like this patch to be added in Linux as early as possible.
> >
> > Issue mentioned by me happens with or without this patch.
> >
> > This patch-set can consider fixing because it uses low memory for DMA
> > & swiotlb only.
> > We can consider restricting crashkernel within the required range like below
> >
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > index 7f9e5a6dc48c..bd67b90d35bd 100644
> > --- a/kernel/crash_core.c
> > +++ b/kernel/crash_core.c
> > @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
> > return 0;
> > }
> >
> > - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> > + low_base = memblock_find_in_range(0,0xc0000000, low_size, CRASH_ALIGN);
> > if (!low_base) {
> > pr_err("Cannot reserve %ldMB crashkernel low memory,
> > please try smaller size.\n",
> > (unsigned long)(low_size >> 20));
> >
> >
>
> I suspect 0xc0000000 would need to be a CONFIG item and not hard-coded.
>
if you consider this as valid change, can you please incorporate as
part of your patch-set.
--pk.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm64 build issue and mainline crash (was Re: linux-next: Tree for Jun 3)
From: John Garry @ 2020-06-03 11:45 UTC (permalink / raw)
To: Stephen Rothwell, Linux Next Mailing List,
linux-arm-kernel@lists.infradead.org, Ard Biesheuvel
Cc: Linux Kernel Mailing List
In-Reply-To: <20200603210603.1fcf63ed@canb.auug.org.au>
On 03/06/2020 12:06, Stephen Rothwell wrote:
JFYI, I am finding the vanilla defconfig build broken for arm64:
LD vmlinux.o
/home/john/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld:
cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file
or directory
make[1]: *** [vmlinux] Error 1
make: *** [__sub-make] Error 2
john@htsatcamb-server:~/linux-next$
In addition, the reason I was testing this was because Linus' master
(d6f9469a03d8 Merge tag 'erofs-for-5.8-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs) was crashing:
[ 5.368948] loop: module loaded
[ 5.372113] Unable to handle kernel paging request at virtual address
fffff9ffcfec4000
[ 5.380067] Mem abort info:
[ 5.382865]ESR = 0x96000044
[ 5.385927]EC = 0x25: DABT (current EL), IL = 32 bits
[ 5.391260]SET = 0, FnV = 0
[ 5.394319]EA = 0, S1PTW = 0
[ 5.397467] Data abort info:
[ 5.400354]ISV = 0, ISS = 0x00000044
[ 5.404203]CM = 0, WnR = 1
[ 5.407178] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000002f3f1000
[ 5.413909] [fffff9ffcfec4000] pgd=0000000000000000
[ 5.418807] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 5.424399] Modules linked in:
[ 5.427462] CPU: 11 PID: 1 Comm: swapper/0 Not tainted
5.7.0-05047-gd6f9469a03d8 #388
[ 5.435325] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05
IT21 Nemo 2.0 RC0 04/18/2018
[ 5.444499] pstate: 40000005 (nZcv daif -PAN -UAO BTYPE=--)
[ 5.450098] pc : __memset+0x16c/0x1c0
[ 5.453770] lr : pcpu_alloc+0x1a0/0x668
[ 5.457615] sp : ffff800011d3bbd0
[ 5.460936] x29: ffff800011d3bbd0 x28: ffff001fb5495180
[ 5.466267] x27: 0000000000000001 x26: 0000000000000100
[ 5.471597] x25: 0000000000000001 x24: 0000000000000001
[ 5.476928] x23: ffff80001135e9a0 x22: ffff80001196a200
[ 5.482259] x21: ffff80001196a360 x20: 0000000000000000
[ 5.487590] x19: 0000000000000000 x18: fffffe107e6fdb08
[ 5.492920] x17: 000000000000003f x16: 0000000000000000
[ 5.498251] x15: ffff001ffbffee00 x14: 0000000000000002
[ 5.503581] x13: 0000000000000000 x12: 000000000000003f
[ 5.508912] x11: 0000000000000040 x10: 0000000000000040
[ 5.514243] x9 : 0000000000000000 x8 : fffff9ffcfec4000
[ 5.519573] x7 : 0000000000000000 x6 : 000000000000003f
[ 5.524904] x5 : 0000000000000040 x4 : 0000000000000000
[ 5.530234] x3 : 0000000000000004 x2 : 00000000000000c0
[ 5.535565] x1 : 0000000000000000 x0 : fffff9ffcfec4000
[ 5.540896] Call trace:
[ 5.543344] __memset+0x16c/0x1c0
[ 5.546666] __alloc_percpu+0x14/0x1c
[ 5.550338] alloc_workqueue+0x164/0x42c
[ 5.554273] init+0x24/0xa4
[ 5.557071] do_one_initcall+0x50/0x194
[ 5.560917] kernel_init_freeable+0x1e4/0x250
[ 5.565288] kernel_init+0x10/0x104
[ 5.568785] ret_from_fork+0x10/0x18
[ 5.572372] Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
[ 5.578568] ---[ end trace 63c299bbe9b8ea9e ]---
[ 5.583205] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 5.590903] SMP: stopping secondary CPUs
[ 5.594846] Kernel Offset: 0xf0000 from 0xffff800010000000
[ 5.600350] PHYS_OFFSET: 0x0
[ 5.603235] CPU features: 0x240022,20806008
[ 5.607430] Memory Limit: none
[ 5.610500] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b ]---
I'll check that when I get a chance. Maybe all just transient.
Thanks
> Hi all,
>
> News: The merge window has opened, so please do *not* add v5.9 material
> to your linux-next included branches until after v5.8-rc1 has been
> released.
>
> Changes since 20200602:
>
> New tree: sh-rf
>
> My fixes tree contains:
>
> 4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")
>
> The drm-intel-fixes tree gained a conflict against Linus' tree.
>
> The overlayfs tree gained a build failure for which I applied a patch.
>
> The v4l-dvb-next tree gained a conflict against the v4l-dvb tree and a
> build failure so I used the version from next-20200602.
>
> The drm-msm tree lost its build failure.
>
> The akpm-current tree gained a conflict against Linus' tree.
>
> The akpm tree lost its build failure and gained conflicts against the
> kselftest and powerpc trees.
>
> Non-merge commits (relative to Linus' tree): 10845
> 11211 files changed, 689281 insertions(+), 199935 deletions(-)
>
> ----------------------------------------------------------------------------
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one. You should use "git fetch" and checkout or reset to the new
> master.
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source. There are also quilt-import.log and merge.log
> files in the Next directory. Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig and htmldocs. And finally, a simple boot test
> of the powerpc pseries_le_defconfig kernel in qemu (with and without
> kvm enabled).
>
> Below is a summary of the state of the merge.
>
> I am currently merging 325 trees (counting Linus' and 82 trees of bug
> fix patches pending for the current merge release).
>
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
>
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
>
> Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
> Gortmaker for triage and bug fixes.
>
_______________________________________________
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 11:45 UTC (permalink / raw)
To: Luke Hinds, Jarkko Sakkinen
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, op-tee,
Jonathan Corbet, James Bottomley, Janne Karhunen,
Linux Doc Mailing List, James Morris, Mimi Zohar,
Linux Kernel Mailing List, David Howells, linux-security-module,
open list:ASYMMETRIC KEYS, Markus Wamser, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAKrSGQSLKpb8T=H9zUoPP1B6EFrgMTMP3ZX1pEv99JtdPq7H0w@mail.gmail.com>
On Wed, 3 Jun 2020 at 14:20, Luke Hinds <lhinds@redhat.com> wrote:
>
>
>
> On Wed, Jun 3, 2020 at 9:08 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>>
>> 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
>
>
> Unless I have misunderstood, my concerns about compile time are that distributors will be cornered into releasing kernels with an opinionated selection of either TEE or TPM and any users needing the non default will need to compile their own kernel.
>
I echo with your concerns.
Jarrko,
If it's fine with you then I can switch back to dynamic approach again
in the next version.
-Sumit
>>
>>
>> > 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
* Re: [PATCH] usb: host: xhci-mtk: avoid runtime suspend when removing hcd
From: Mathias Nyman @ 2020-06-03 11:47 UTC (permalink / raw)
To: Macpaul Lin, Chunfeng Yun, Mathias Nyman, Greg Kroah-Hartman,
Matthias Brugger
Cc: Mediatek WSD Upstream, linux-usb, linux-kernel, linux-mediatek,
Macpaul Lin, linux-arm-kernel
In-Reply-To: <1590726569-28248-1-git-send-email-macpaul.lin@mediatek.com>
On 29.5.2020 7.29, 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.
>
> Change-Id: I70a5dc8006207caeecbac6955ce8e5345dcc70e6
> 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);
Might runtime suspend here.
It's a lot better than before, no panic as hcd isn't released, but a bit unnecessary.
how about this sequence instead:
pm_runtime_disable()
pm_runtime_put_noidle()
> + pm_runtime_disable(&dev->dev);
> +
-Mathias
_______________________________________________
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] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Robin Murphy @ 2020-06-03 11:37 UTC (permalink / raw)
To: Mathieu Poirier, Sai Prakash Ranjan
Cc: Suzuki K Poulose, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, linux-arm-kernel, Mike Leach
In-Reply-To: <20200601212858.GB24287@xps15>
On 2020-06-01 22:28, Mathieu Poirier wrote:
> That being said I'm sure that dependencies on an IOMMU isn't a problem confined
> to coresight. I am adding Robin Murphy, who added this commit [1], to the thread
> in the hope that he can provide guidance on the right way to do this.
Right, it's not specific to CoreSight, and it's not even specific to
IOMMUs really. In short, blame kexec ;)
The fundamental thing is that devices should stop any DMA activity at
shutdown. For a normal poweroff you can typically get away without doing
so, but over kexec, ongoing DMA traffic may corrupt memory in the new
kernel (at worst, I think even DMA reads could potentially cause
unexpected cache behaviour that might lead to mishaps, given the right
combination of memory attributes).
IOMMUs merely help to make the situation more serious. For similar kexec
reasons, they need to disable any existing translations at shutdown
(imagine if the second kernel didn't have an IOMMU driver). And at that
point, even the normal poweroff case becomes problematic, because any
device DMA that hasn't been shut down beforehand is now not necessarily
going benignly to memory as it would in the no-IOMMU case above, but
potentially to random physical addresses, with all the hilarity ensuing
that you would expect from that.
Robin.
_______________________________________________
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] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Mike Leach @ 2020-06-03 11:27 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, robin.murphy,
linux-arm-kernel
In-Reply-To: <f0357072de96970b641bbd0da98c1d61@codeaurora.org>
Hi,
On Wed, 3 Jun 2020 at 11:24, Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>
> Hi Mike,
>
> Thanks again for looking at this.
>
> On 2020-06-03 03:42, Mike Leach wrote:
> [...]
>
> >>
> >> SMMU/IOMMU won't be able to do much here as it is the client's
> >> responsiblity to
> >> properly shutdown and SMMU device link just makes sure that
> >> SMMU(supplier) shutdown is
> >> called only after its consumers shutdown callbacks are called.
> >
> > I think this use case can be handled slightly differently than the
> > general requirements for modular CoreSight drivers.
> >
> > What is needed here is a way of stopping the underlying ETR hardware
> > from issuing data to the SMMU, until the entire device has been shut
> > down, in a way that does not remove the driver, breaking existing
> > references and causing a system crash.
> >
> > We could introduce a new mode to the ETR driver - e.g.
> > CS_MODE_SHUTDOWN.
> >
> > At the end of the block tmc_shutdown(struct amba_device *adev), set
> > drvdata->mode to CS_MODE_SHUTDOWN & remove the coresight_unregister().
> > This new mode can be used to prevent the underlying hardware from
> > being able to restart until the device is re-powered.
> >
> > This mode can be detected in the code that enables / disables the ETR
> > and handled appropriately (updates to tmc_enable_etr_sink and
> > tmc_disable_etr_sink).
> > This mode will persist until the device is re-started - but because we
> > are on the device shutdown path this is not an issue.
> >
> > This should leave the CoreSight infrastructure stable until the
> > drivers are shut down normally as part of the device power down
> > process.
> >
>
> Sounds good to me, but if the coresight_unregister() is the trouble
> point
> causing these crashes, then can't we just remove that from
> tmc_shutdown()
> callback? This would be like maintaining the same behaviour as now where
> on reboot/shutdown we basically don't do anything except for disabling
> ETR.
No - the new mode prevents race conditions where the thread shutting
down the SMMU does the ETR shutdown, but then another thread happens
to be trying to start trace and restarts the ETR.
It also prevents the condition Mathieu discussed where a thread might
be attempting to shutdown trace - this could try to disable the
hardware again re-releasing resources/ re-flushing and waiting for
stop.
Regards
Mike
> This way, we do not have to introduce any new mode as well. To be exact,
> in
> tmc_shutdown() we just disable ETR and then return without unregistering
> which should not cause any issues since this is shutdown not the remove
> callback which is a requirement for making coresight modular like below:
>
> static void tmc_shutdown(struct amba_device *adev)
> {
> unsigned long flags;
> struct tmc_drvdata *drvdata = amba_get_drvdata(adev);
>
> spin_lock_irqsave(&drvdata->spinlock, flags);
>
> if (drvdata->mode == CS_MODE_DISABLED)
> goto out;
>
> if (drvdata->config_type == TMC_CONFIG_TYPE_ETR)
> tmc_etr_disable_hw(drvdata);
>
> /*
> * We do not care about coresight unregister here unlike remove
> * callback which is required for making coresight modular
> since
> * the system is going down after this.
> */
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> } from disabling the ETR again - potentially freeing up memory twice.
>
>
> Thanks,
> Sai
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
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 11:22 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: <CAMj1kXHcRuQXPej9_H_jnno516BnuFrPRqzp1+6xN-odckEMJg@mail.gmail.com>
On Wed, Jun 3, 2020 at 6:16 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> 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?
--whole-archive literally links the whole of the archive.
If there are duplicate definitions, the linking fails
due to multiple definition.
So, --whole-archive is similar to linking .o files
in this regard.
There is a point for arm and x86 because
the decompressor link does not use --whole-archive.
As for arm64, there is no point,
but you can pass lib.a after --no-whole-archive
by the following patch.
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 650e1185c190..48a6afa774fc 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -145,7 +145,7 @@ 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
+libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
# Default target when executing plain make
boot := arch/arm64/boot
Then, _efistub_efi_low_alloc_above
and __efistub_efi_relocate_kernel will be dropped.
If you like the static library
do you want me to send v2?
--
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 related
* Re: [PATCH v3 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Marc Zyngier @ 2020-06-03 11:22 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: devicetree, Lorenzo Pieralisi, Masami Hiramatsu, Jassi Brar,
Jingoo Han, linux-pci, linux-kernel, Masahiro Yamada, Rob Herring,
Gustavo Pimentel, Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <1591174481-13975-3-git-send-email-hayashi.kunihiko@socionext.com>
On 2020-06-03 09:54, Kunihiko Hayashi wrote:
> 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.
interrupts
> 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()) {
This checks whether the kernel supports MSIs. Not that they are
enabled in your controller. Is that really what you want to do?
> + 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);
> + }
These two cases do the exact same thing, calling the same interrupt.
What is the point of dealing with them independently?
> + }
>
> 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);
This is a chained handler called outside of a chained_irq_enter/exit
block. It isn't acceptable.
>
> /* 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,
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: André Przywara @ 2020-06-03 11:20 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Lorenzo Pieralisi, Liviu Dudau,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Sudeep Holla, Guenter Roeck
In-Reply-To: <CAL_JsqLgNDd-+rrYD=Y0Hm=NaV7f0NbBFb9uhhYhzM6LjxnXZg@mail.gmail.com>
On 02/06/2020 00:12, Rob Herring wrote:
Hi,
> On Mon, Jun 1, 2020 at 4:15 AM André Przywara <andre.przywara@arm.com> wrote:
>>
>> On 28/05/2020 14:30, André Przywara wrote:
>>
>> Hi,
>>
>>> On 28/05/2020 03:48, Guenter Roeck wrote:
>>>
>>> Hi Guenter,
>>>
>>>> On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
>>>>> The devicetree compiler complains when DT nodes without a reg property
>>>>> live inside a (simple) bus node:
>>>>> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
>>>>> missing or empty reg/ranges property
>>>>>
>>>>> Move the fixed clocks, the fixed regulator, the leds and the config bus
>>>>> subtree to the root node, since they do not depend on any busses.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>
>>>> This patch results in tracebacks when booting the vexpress-a15 machine
>>>> with vexpress-v2p-ca15-tc1 devicetree file in qemu. Reverting it as well
>>>> as the subsequent patches affecting the same file (to avoid revert
>>>> conflicts) fixes the problem.
>>>
>>> Many thanks for the heads up! I was able to reproduce it here. On the
>>> first glance it looks like the UART is probed before the clocks now,
>>> because the traversal of the changed DT leads to a different probe
>>> order. I will look into how to fix this.
>>
>> Turned out to be a bit more complicated:
>> The arm,vexpress,config-bus driver walks up the device tree to find a
>> arm,vexpress,site property [1]. With this patch the first parent node
>> with that property it finds is now the root node, with the wrong site ID
>> (0xf instead of 0x0). So it queries the wrong clocks (those IDs are
>> actually reserved there), and QEMU reports back "0", consequently [2].
>> Finding a clock frequency in the range of [0, 0] won't get very far.
>>
>> Possible solutions are:
>> 1) Just keep the mcc and its children at where it is in mainline right
>> now, so *partly* reverting this patch. This has the problem of still
>> producing a dtc warning, so kind of defeats the purpose of this patch.
>>
>> 2) Add a "arm,vexpress,site = <0>;" line to the "mcc" node itself.
>> Works, but looks somewhat dodgy, as the mcc node should really be a
>> child of the motherboard node, and we should not hack around this.
>>
>> 3) Dig deeper and fix the DT in a way that makes dtc happy. Might
>> involve (dummy?) ranges or reg properties. My gut feeling is that
>> arm,vexpress-sysreg,func should really have been "reg" in the first
>> place, but that's too late to change now, anyway.
>>
>> I will post 2) as a fix if 3) turns out to be not feasible.
>
> I would just do 1).
>
> To some extent, the warnings are for avoiding poor design on new
> bindings. We need a way to distinguish between existing boards and new
> ones. Maybe dts needs to learn some warning disable annotations or we
> need per target warning settings (DTC_FLAGS_foo.dtb ?). Or maybe this
> check is just too strict.
So I was always wondering about this check, actually. A simple-bus
describes a bus which is mapped into the CPU address space (in contrast
to say an I2C bus, for instance). So children of this bus node typically
have a reg property.
Now also those simple-bus nodes seem to be used to logically group
hardware in a DT (see this "motherboard" node here). *If* we go with
this, we should also allow other subnodes, for instance fixed-clocks:
after all there is probably an actual fixed crystal oscillator on the
motherboard, so it would also belong in there.
I see that (ab)using simple-bus for *just* grouping nodes is probably
not a good design, but I don't see why *every* child must be mapped into
the address space.
Maybe dtc's simple-bus check should indeed be relaxed, to just require
*at least one* child with a reg or ranges property, but also allow other
nodes?
Cheers,
Andre
_______________________________________________
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