* Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
From: Chester Lin @ 2019-08-19 7:56 UTC (permalink / raw)
To: Mike Rapoport
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, Ard Biesheuvel, linux@armlinux.org.uk,
linux-kernel@vger.kernel.org, Chester Lin, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190815133738.GA2483@rapoport-lnx>
Hi Mike and Ard,
On Thu, Aug 15, 2019 at 04:37:39PM +0300, Mike Rapoport wrote:
> On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> > (adding Mike)
> >
> > On Thu, 15 Aug 2019 at 14:28, Chester Lin <clin@suse.com> wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > > > >
> > > > > Hello Chester,
> > > > >
> > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
> > > > > >
> > > > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > > > uncompressed kernel. For example, we got the following error message when
> > > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > > > >
> > > > > > EFI stub: Booting Linux Kernel...
> > > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > > > > > EFI stub: ERROR: Failed to relocate kernel
> > > > > >
> > > > > > After checking the EFI memory map we found that the first page [0 - 0xfff]
> > > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > > > > > set the dram base at 0, which was actually in a reserved region.
> > > > > >
> > > > >
> > > > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > > > ARM when using the decompressor. The decompressor rounds down its own
> > > > > base address to a multiple of 128 MB, and assumes the whole area is
> > > > > available for the decompressed kernel and related data structures.
> > > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > > > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > > > this is fragile). Note that the decompressor does not look at any DT
> > > > > or EFI provided memory maps *at all*.
> > > > >
> > > > > So unfortunately, this is not something we can fix in the kernel, but
> > > > > we should fix it in the bootloader or in GRUB, so it does not put any
> > > > > reserved regions in the first 128 MB of memory,
> > > > >
> > > >
> > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > > > ARM boot protocol docs are unclear about whether this memory should be
> > > > used or not, but it is no longer used for its original purpose (page
> > > > tables), and the RPi loader already keeps data there.
> > > >
> > > > Can you check whether the following patch works for you?
> > > >
> > > > diff --git a/drivers/firmware/efi/libstub/Makefile
> > > > b/drivers/firmware/efi/libstub/Makefile
> > > > index 0460c7581220..ee0661ddb25b 100644
> > > > --- a/drivers/firmware/efi/libstub/Makefile
> > > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > > > string.o random.o \
> > > >
> > > > lib-$(CONFIG_ARM) += arm32-stub.o
> > > > lib-$(CONFIG_ARM64) += arm64-stub.o
> > > > +CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > >
> > > > #
> > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > index e8f7aefb6813..66ff0c8ec269 100644
> > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > @@ -204,7 +204,7 @@ efi_status_t
> > > > handle_kernel_image(efi_system_table_t *sys_table,
> > > > * loaded. These assumptions are made by the decompressor,
> > > > * before any memory map is available.
> > > > */
> > > > - dram_base = round_up(dram_base, SZ_128M);
> > > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;
> > > >
> > > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
> > > > reserve_size);
> > > >
> > >
> > > I tried your patch on rpi2 and got the following panic. Just a reminder that I
> > > have replaced some log messages with "......" since it might be too long to
> > > post all.
> > >
> >
> > OK. Good to know that this change helps you to get past the EFI stub boot issue.
> >
> > > In this case the kernel failed to reserve cma, which should hit the issue of
> > > memblock_limit=0x1000 as I had mentioned in my patch description. The first
> > > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> > > with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> > > was extremely low. That's why I expand the first reservation from 1 PAGESIZE to
> > > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> > > if any suggestion, thank you.
>
>
> > This looks like it is a separate issue. The memblock/cma code should
> > not choke on a reserved page of memory at 0x0.
> >
> > Perhaps Russell or Mike (cc'ed) have an idea how to address this?
>
> Presuming that the last memblock dump comes from the end of
> arm_memblock_init() with the this memory map
>
> memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
>
> adjust_lowmem_bounds() will set the memblock_limit (and respectively global
> memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
> happily fail.
>
> I believe that the assumption for memblock_limit calculations was that the
> first bank has several megs at least.
>
> I wonder if this hack would help:
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index d9a0038..948e5b9 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
> * allocated when mapping the start of bank 0, which
> * occurs before any free memory is mapped.
> */
> - if (!memblock_limit) {
> + if (memblock_limit < PMD_SIZE) {
> if (!IS_ALIGNED(block_start, PMD_SIZE))
> memblock_limit = block_start;
> else if (!IS_ALIGNED(block_end, PMD_SIZE))
>
I applied this patch as well and it works well on rpi-2 model B.
> > > boot-log:
> > > --------
> > >
> > > Loading Linux test ...
> > > EFI stub: Booting Linux Kernel...
> > > EFI stub: Using DTB from configuration table
> > > EFI stub: Exiting boot services and installing virtual address map...
> > > Uncompressing Linux... done, booting the kernel.
> > > [ 0.000000] Booting Linux on physical CPU 0xf00
> > > [ 0.000000] Linux version 5.2.1-lpae (chester@linux-8mug) (......)
> > > [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
> > > [ 0.000000] CPU: div instructions available: patching division code
> > > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > > [ 0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B Rev 1.1
> > > [ 0.000000] printk: bootconsole [earlycon0] enabled
> > > [ 0.000000] Memory policy: Data cache writealloc
> > > [ 0.000000] efi: Getting EFI parameters from FDT:
> > > [ 0.000000] efi: System Table: 0x000000003df757c0
> > > [ 0.000000] efi: MemMap Address: 0x000000002c1c5040
> > > [ 0.000000] efi: MemMap Size: 0x000003c0
> > > [ 0.000000] efi: MemMap Desc. Size: 0x00000028
> > > [ 0.000000] efi: MemMap Desc. Version: 0x00000001
> > > [ 0.000000] efi: EFI v2.70 by Das U-Boot
> > > [ 0.000000] efi: SMBIOS=0x3cb62000 MEMRESERVE=0x3cb3d040
> > > [ 0.000000] memblock_reserve: [0x000000003cb3d040-0x000000003cb3d04f] efi_config_parse_tables+0x25c/0x2d8
> > > [ 0.000000] efi: Processing EFI memory map:
> > > [ 0.000000] MEMBLOCK configuration:
> > > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x0000000000000010
> > > [ 0.000000] memory.cnt = 0x1
> > > [ 0.000000] memory[0x0] [0x0000000000000000-0x000000003dffffff], 0x000000003e000000 bytes flags: 0x0
> > > [ 0.000000] reserved.cnt = 0x1
> > > [ 0.000000] reserved[0x0] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > > [ 0.000000] memblock_remove: [0x0000000000000000-0xfffffffffffffffe] reserve_regions+0x68/0x23c
> > > [ 0.000000] efi: 0x000000000000-0x000000000fff [Reserved | | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000000000000-0x0000000000000fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000000001000-0x000000307fff [Conventional Memory| | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000000001000-0x0000000000307fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000000308000-0x000002307fff [Boot Data | | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000000308000-0x0000000002307fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000002308000-0x000002a93fff [Loader Data | | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000002308000-0x0000000002a93fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000002a94000-0x000007cf5fff [Conventional Memory| | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000002a94000-0x0000000007cf5fff] early_init_dt_add_memory_arch+0x164/0x178
> > > ......
> > > ......
> > > [ 0.000000] memblock_add: [0x000000003df76000-0x000000003dffffff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x00003f100000-0x00003f100fff [Memory Mapped I/O |RUN| | | | | | | | | | | ]
> > > [ 0.000000] memblock_reserve: [0x000000002c1c5000-0x000000002c1c5fff] efi_init+0xd8/0x1c8
> > > [ 0.000000] memblock_reserve: [0x0000000000400000-0x0000000001df2cef] arm_memblock_init+0x44/0x19c
> > > [ 0.000000] memblock_reserve: [0x0000000000303000-0x0000000000307fff] arm_mm_memblock_reserve+0x30/0x38
> > > [ 0.000000] memblock_reserve: [0x0000000007cf6000-0x0000000007cfc5c4] early_init_dt_reserve_memory_arch+0x2c/0x30
> > > [ 0.000000] cma: Failed to reserve 64 MiB
> > > [ 0.000000] MEMBLOCK configuration:
> > > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x00000000019ff2c5
> > > [ 0.000000] memory.cnt = 0xa
> > > [ 0.000000] memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> > > [ 0.000000] memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> > > [ 0.000000] memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> > > [ 0.000000] memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
> > > [ 0.000000] memory[0x4] [0x000000003cb3f000-0x000000003cb3ffff], 0x0000000000001000 bytes flags: 0x4
> > > [ 0.000000] memory[0x5] [0x000000003cb40000-0x000000003cb5ffff], 0x0000000000020000 bytes flags: 0x0
> > > [ 0.000000] memory[0x6] [0x000000003cb60000-0x000000003cb68fff], 0x0000000000009000 bytes flags: 0x4
> > > [ 0.000000] memory[0x7] [0x000000003cb69000-0x000000003df74fff], 0x000000000140c000 bytes flags: 0x0
> > > [ 0.000000] memory[0x8] [0x000000003df75000-0x000000003df75fff], 0x0000000000001000 bytes flags: 0x4
> > > [ 0.000000] memory[0x9] [0x000000003df76000-0x000000003dffffff], 0x000000000008a000 bytes flags: 0x0
> > > [ 0.000000] reserved.cnt = 0x5
> > > [ 0.000000] reserved[0x0] [0x0000000000303000-0x0000000000307fff], 0x0000000000005000 bytes flags: 0x0
> > > [ 0.000000] reserved[0x1] [0x0000000000400000-0x0000000001df2cef], 0x00000000019f2cf0 bytes flags: 0x0
> > > [ 0.000000] reserved[0x2] [0x0000000007cf6000-0x0000000007cfc5c4], 0x00000000000065c5 bytes flags: 0x0
> > > [ 0.000000] reserved[0x3] [0x000000002c1c5000-0x000000002c1c5fff], 0x0000000000001000 bytes flags: 0x0
> > > [ 0.000000] reserved[0x4] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > > [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x0000000000000000 max_addr=0x0000000000000000 early_alloc+0x44/0x70
> > > [ 0.000000] Kernel panic - not syncing: early_alloc: Failed to allocate 4096 bytes align=0x1000
> > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.1-lpae #1 openSUSE Tumbleweed (unreleased)
> > > [ 0.000000] Hardware name: BCM2835
> > > [ 0.000000] Backtrace:
> > > [ 0.000000] [<c043fafc>] (dump_backtrace) from [<c043fd84>] (show_stack+0x20/0x24)
> > > [ 0.000000] r7:c1800000 r6:00000000 r5:600001d3 r4:c1901ba0
> > > [ 0.000000] [<c043fd64>] (show_stack) from [<c0df9400>] (dump_stack+0xd0/0x104)
> > > [ 0.000000] [<c0df9330>] (dump_stack) from [<c048061c>] (panic+0xf8/0x32c)
> > > [ 0.000000] r10:c0307000 r9:c0001000 r8:00000003 r7:00000000 r6:00000000 r5:c181df04
> > > [ 0.000000] r4:c192b8d8 r3:00000001
> > > [ 0.000000] [<c0480528>] (panic) from [<c1609728>] (early_alloc+0x60/0x70)
> > > [ 0.000000] r3:00001000 r2:00001000 r1:c10037e8 r0:c12fe64c
> > > [ 0.000000] r7:00000000
> > > [ 0.000000] [<c16096c8>] (early_alloc) from [<c1609114>] (arm_pte_alloc+0x34/0x94)
> > > [ 0.000000] r7:00000000 r6:00000000 r4:c0307000
> > > [ 0.000000] [<c16090e0>] (arm_pte_alloc) from [<c1609384>] (__create_mapping+0x210/0x2c0)
> > > [ 0.000000] r9:c0001000 r8:c0001000 r7:00000001 r6:c13f22e0 r5:c0200000 r4:c0400000
> > > [ 0.000000] [<c1609174>] (__create_mapping) from [<c160951c>] (create_mapping+0xe8/0x108)
> > > [ 0.000000] r10:c0400000 r9:c16a2110 r8:c19c7a80 r7:00000000 r6:00400000 r5:c13f2000
> > > [ 0.000000] r4:c1801ef0
> > > [ 0.000000] [<c1609434>] (create_mapping) from [<c1609f50>] (paging_init+0x350/0x75c)
> > > [ 0.000000] r4:c1842d40
> > >
> > >
> > > > >
> > > > > > grub> lsefimmap
> > > > > > Type Physical start - end #Pages Size Attributes
> > > > > > reserved 0000000000000000-0000000000000fff 00000001 4KiB WB
> > > > > > conv-mem 0000000000001000-0000000007ef5fff 00007ef5 130004KiB WB
> > > > > > RT-data 0000000007ef6000-0000000007f09fff 00000014 80KiB RT WB
> > > > > > conv-mem 0000000007f0a000-000000002d871fff 00025968 615840KiB WB
> > > > > > .....
> > > > > >
> > > > > > To avoid a reserved address, we have to ignore the memory regions which are
> > > > > > marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
> > > > > > chosen. If the region before the kernel base is unaligned, it will be
> > > > > > marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
> > > > > > will not be sticked with a very low address such as 0x1000.
> > > > > >
> > > >
> > > > This is a separate issue, so it should be handled in a separate patch.
> > > >
> > > > > > Signed-off-by: Chester Lin <clin@suse.com>
> > > > > > ---
> > > > > > arch/arm/mm/mmu.c | 3 ++
> > > > > > drivers/firmware/efi/libstub/arm32-stub.c | 43 ++++++++++++++++++-----
> > > > > > 2 files changed, 37 insertions(+), 9 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > > > index f3ce34113f89..909b11ba48d8 100644
> > > > > > --- a/arch/arm/mm/mmu.c
> > > > > > +++ b/arch/arm/mm/mmu.c
> > > > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > > > > phys_addr_t block_start = reg->base;
> > > > > > phys_addr_t block_end = reg->base + reg->size;
> > > > > >
> > > > > > + if (memblock_is_nomap(reg))
> > > > > > + continue;
> > > > > > +
> > > > > > if (reg->base < vmalloc_limit) {
> > > > > > if (block_end > lowmem_limit)
> > > > > > /*
> > > > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > index e8f7aefb6813..10d33d36df00 100644
> > > > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > @@ -128,7 +128,7 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > > >
> > > > > > for (l = 0; l < map_size; l += desc_size) {
> > > > > > efi_memory_desc_t *desc;
> > > > > > - u64 start, end;
> > > > > > + u64 start, end, spare, kernel_base;
> > > > > >
> > > > > > desc = (void *)memory_map + l;
> > > > > > start = desc->phys_addr;
> > > > > > @@ -144,27 +144,52 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > > > case EFI_BOOT_SERVICES_DATA:
> > > > > > /* Ignore types that are released to the OS anyway */
> > > > > > continue;
> > > > > > -
> > > > > > + case EFI_RESERVED_TYPE:
> > > > > > + /* Ignore reserved regions */
> > > > > > + continue;
> > > > > > case EFI_CONVENTIONAL_MEMORY:
> > > > > > /*
> > > > > > * Reserve the intersection between this entry and the
> > > > > > * region.
> > > > > > */
> > > > > > start = max(start, (u64)dram_base);
> > > > > > - end = min(end, (u64)dram_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > > + kernel_base = round_up(start, PMD_SIZE);
> > > > > > + spare = kernel_base - start;
> > > > > > + end = min(end, kernel_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > > +
> > > > > > + status = efi_call_early(allocate_pages,
> > > > > > + EFI_ALLOCATE_ADDRESS,
> > > > > > + EFI_LOADER_DATA,
> > > > > > + MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE,
> > > > > > + &kernel_base);
> > > > > > + if (status != EFI_SUCCESS) {
> > > > > > + pr_efi_err(sys_table_arg,
> > > > > > + "reserve_kernel_base: alloc failed.\n");
> > > > > > + goto out;
> > > > > > + }
> > > > > > + *reserve_addr = kernel_base;
> > > > > >
> > > > > > + if (!spare)
> > > > > > + break;
> > > > > > + /*
> > > > > > + * If there's a gap between start and kernel_base,
> > > > > > + * it needs be reserved so that the memblock_limit
> > > > > > + * will not fall on a very low address when running
> > > > > > + * adjust_lowmem_bounds(), wchich could eventually
> > > > > > + * cause CMA reservation issue.
> > > > > > + */
> > > > > > status = efi_call_early(allocate_pages,
> > > > > > EFI_ALLOCATE_ADDRESS,
> > > > > > - EFI_LOADER_DATA,
> > > > > > - (end - start) / EFI_PAGE_SIZE,
> > > > > > + EFI_RESERVED_TYPE,
> > > > > > + spare / EFI_PAGE_SIZE,
> > > > > > &start);
> > > > > > if (status != EFI_SUCCESS) {
> > > > > > pr_efi_err(sys_table_arg,
> > > > > > - "reserve_kernel_base(): alloc failed.\n");
> > > > > > + "reserve spare-region failed\n");
> > > > > > goto out;
> > > > > > }
> > > > > > - break;
> > > > > >
> > > > > > + break;
> > > > > > case EFI_LOADER_CODE:
> > > > > > case EFI_LOADER_DATA:
> > > > > > /*
> > > > > > @@ -220,7 +245,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > > *image_size = image->image_size;
> > > > > > status = efi_relocate_kernel(sys_table, image_addr, *image_size,
> > > > > > *image_size,
> > > > > > - dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > > + *reserve_addr + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > > if (status != EFI_SUCCESS) {
> > > > > > pr_efi_err(sys_table, "Failed to relocate kernel.\n");
> > > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > > @@ -233,7 +258,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > > * in memory. The kernel determines the base of DRAM from the
> > > > > > * address at which the zImage is loaded.
> > > > > > */
> > > > > > - if (*image_addr + *image_size > dram_base + ZIMAGE_OFFSET_LIMIT) {
> > > > > > + if (*image_addr + *image_size > *reserve_addr + ZIMAGE_OFFSET_LIMIT) {
> > > > > > pr_efi_err(sys_table, "Failed to relocate kernel, no low memory available.\n");
> > > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > > *reserve_size = 0;
> > > > > > --
> > > > > > 2.22.0
> > > > > >
> > > >
> >
>
> --
> Sincerely yours,
> Mike.
>
>
_______________________________________________
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 4/5] arm64: perf: Enable pmu counter direct access for perf event on armv8
From: Raphael Gault @ 2019-08-19 7:59 UTC (permalink / raw)
To: kbuild test robot
Cc: mark.rutland, raph.gault+kdev, peterz, catalin.marinas,
will.deacon, linux-kernel, acme, mingo, kbuild-all,
linux-arm-kernel
In-Reply-To: <201908182002.KAH4UW2w%lkp@intel.com>
Hi,
On 8/18/19 1:37 PM, kbuild test robot wrote:
> Hi Raphael,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc4 next-20190816]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
This patchset was based on linux-next/master and note linus
Thanks,
--
Raphael Gault
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] ARM: psci: cpuidle: defconfig updates
From: Shawn Guo @ 2019-08-19 7:57 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Mark Rutland, Ulf Hansson, Catalin Marinas, Daniel Lezcano, soc,
Sudeep Holla, Will Deacon, LAKML
In-Reply-To: <20190814125239.6270-1-lorenzo.pieralisi@arm.com>
On Wed, Aug 14, 2019 at 01:52:37PM +0100, Lorenzo Pieralisi wrote:
> Rerouting defconfig updates related to this patch series:
>
> https://lore.kernel.org/linux-arm-kernel/cover.1565348376.git.lorenzo.pieralisi@arm.com/
>
> to arm-soc, as agreed in:
>
> https://lore.kernel.org/linux-arm-kernel/58d9677db3510ed106fe23118090c84f78a44102.1565348376.git.lorenzo.pieralisi@arm.com/
>
> Patches [1-6] are already queued in the ARM64 tree.
>
> Please consider pulling these defconfig changes, thank you very much.
We, platform maintainers, also send arch/arm64/configs/defconfig changes
to arm-soc folk. So I applied both patches to IMX tree and will send
them to arm-soc for 5.4 inclusion.
Shawn
>
> Cc: Will Deacon <will@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
>
> Lorenzo Pieralisi (2):
> arm64: defconfig: Enable the PSCI CPUidle driver
> ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driver
>
> arch/arm/configs/imx_v6_v7_defconfig | 1 +
> arch/arm64/configs/defconfig | 1 +
> 2 files changed, 2 insertions(+)
>
> --
> 2.21.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: imx: stop adjusting ar8031 phy tx delay
From: Shawn Guo @ 2019-08-19 7:51 UTC (permalink / raw)
To: André Draszik
Cc: Kate Stewart, Greg Kroah-Hartman, Sascha Hauer, linux-kernel,
Russell King, NXP Linux Team, Pengutronix Kernel Team,
Thomas Gleixner, Leonard Crestez, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190809031256.3594-1-git@andred.net>
On Fri, Aug 09, 2019 at 04:12:56AM +0100, André Draszik wrote:
> Recent changes to the Atheros at803x driver cause
> the approach taken here to stop working because
> commit 6d4cd041f0af
> ("net: phy: at803x: disable delay only for RGMII mode")
> and commit cd28d1d6e52e
> ("net: phy: at803x: Disable phy delay for RGMII mode")
> fix the AR8031 driver to configure the phy's (RX/TX)
> delays as per the 'phy-mode' in the device tree.
>
> In particular, the phy tx (and rx) delays are updated
> again as per the 'phy-mode' *after* the code in here
> runs.
>
> Things worked before above commits, because the AR8031
> comes out of reset with RX delay enabled, and the
> at803x driver didn't touch the delay configuration at
> all when "rgmii" mode was selected.
>
> It appears the code in here tries to make device
> trees work that incorrectly specify "rgmii", but
> that can't work any more and it is imperative since
> above commits to have the phy-mode configured
> correctly in the device tree.
>
> I suspect there are a few imx7d based boards using
> the ar8031 phy and phy-mode = "rgmii", but given I
> don't know which ones exactly, I am not in a
> position to update the respective device trees.
>
> Hence this patch is simply removing the superfluous
> code from the imx7d initialisation. An alternative
> could be to add a warning instead, but that would
> penalize all boards that have been updated already.
>
> Signed-off-by: André Draszik <git@andred.net>
> CC: Russell King <linux@armlinux.org.uk>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> CC: Pengutronix Kernel Team <kernel@pengutronix.de>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: NXP Linux Team <linux-imx@nxp.com>
> CC: Kate Stewart <kstewart@linuxfoundation.org>
> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Leonard Crestez <leonard.crestez@nxp.com>
> CC: linux-arm-kernel@lists.infradead.org
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx7d: cl-som-imx7: make ethernet work again
From: Shawn Guo @ 2019-08-19 7:51 UTC (permalink / raw)
To: André Draszik
Cc: Mark Rutland, devicetree, linux-arm-kernel, Sascha Hauer,
linux-kernel, Rob Herring, Igor Grinberg, Pengutronix Kernel Team,
Fabio Estevam, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190809031227.3319-1-git@andred.net>
On Fri, Aug 09, 2019 at 04:12:27AM +0100, André Draszik wrote:
> Recent changes to the atheros at803x driver caused
> ethernet to stop working on this board.
> In particular commit 6d4cd041f0af
> ("net: phy: at803x: disable delay only for RGMII mode")
> and commit cd28d1d6e52e
> ("net: phy: at803x: Disable phy delay for RGMII mode")
> fix the AR8031 driver to configure the phy's (RX/TX)
> delays as per the 'phy-mode' in the device tree.
>
> This now prevents ethernet from working on this board.
>
> It used to work before those commits, because the
> AR8031 comes out of reset with RX delay enabled, and
> the at803x driver didn't touch the delay configuration
> at all when "rgmii" mode was selected, and because
> arch/arm/mach-imx/mach-imx7d.c:ar8031_phy_fixup()
> unconditionally enables TX delay.
>
> Since above commits ar8031_phy_fixup() also has no
> effect anymore, and the end-result is that all delays
> are disabled in the phy, no ethernet.
>
> Update the device tree to restore functionality.
>
> Signed-off-by: André Draszik <git@andred.net>
> CC: Ilya Ledvich <ilya@compulab.co.il>
> CC: Igor Grinberg <grinberg@compulab.co.il>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Mark Rutland <mark.rutland@arm.com>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> CC: Pengutronix Kernel Team <kernel@pengutronix.de>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: NXP Linux Team <linux-imx@nxp.com>
> CC: devicetree@vger.kernel.org
> CC: linux-arm-kernel@lists.infradead.org
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: ls1088a: Fix incorrect I2C clock divider
From: Shawn Guo @ 2019-08-19 7:43 UTC (permalink / raw)
To: Chuanhua Han
Cc: mark.rutland, devicetree, linux-kernel, leoyang.li, robh+dt,
linux-arm-kernel
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
On Tue, Aug 06, 2019 at 04:42:20PM +0800, Chuanhua Han wrote:
> Ls1088a platform, the i2c input clock is actually platform pll CLK / 8
> (this is the hardware connection), other clock divider can not get the
> correct i2c clock, resulting in the output of SCL pin clock is not
> accurate.
>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
Applied all, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm/arm64: vgic: Allow more than 256 vcpus for KVM_IRQ_LINE
From: Will Deacon @ 2019-08-19 7:41 UTC (permalink / raw)
To: Marc Zyngier
Cc: Peter Maydell, kvm, Suzuki K Poulose, qemu-arm, James Morse,
linux-arm-kernel, Zenghui Yu, kvmarm, Julien Thierry
In-Reply-To: <20190818140710.23920-1-maz@kernel.org>
On Sun, Aug 18, 2019 at 03:07:10PM +0100, Marc Zyngier wrote:
> While parts of the VGIC support a large number of vcpus (we
> bravely allow up to 512), other parts are more limited.
>
> One of these limits is visible in the KVM_IRQ_LINE ioctl, which
> only allows 256 vcpus to be signalled when using the CPU or PPI
> types. Unfortunately, we've cornered ourselves badly by allocating
> all the bits in the irq field.
>
> Since the irq_type subfield (8 bit wide) is currently only taking
> the values 0, 1 and 2 (and we have been careful not to allow anything
> else), let's reduce this field to only 4 bits, and allocate the
> remaining 4 bits to a vcpu2_index, which acts as a multiplier:
>
> vcpu_id = 256 * vcpu2_index + vcpu_index
>
> With that, and a new capability (KVM_CAP_ARM_IRQ_LINE_LAYOUT_2)
> allowing this to be discovered, it becomes possible to inject
> PPIs to up to 4096 vcpus. But please just don't.
Do you actually need a new capability for this? Older kernels reject
non-zero upper bits in the 'irq_type', so isn't that enough to probe
for this directly?
Will
_______________________________________________
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 v6 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Hugues FRUCHET @ 2019-08-19 7:40 UTC (permalink / raw)
To: Sakari Ailus
Cc: Yannick FERTRE, Alexandre TORGUE, Mickael GUENE,
linux-kernel@vger.kernel.org, Philippe CORNU, Hans Verkuil,
Benjamin Gaignard, Mauro Carvalho Chehab,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <20190819072621.GZ6133@paasikivi.fi.intel.com>
Hi Sakari,
OK, I will change.
Have you some other remarks on this serie in order that I group changes
in the next version ?
On 8/19/19 9:26 AM, Sakari Ailus wrote:
> Hi Hugues,
>
> On Mon, Aug 19, 2019 at 07:23:17AM +0000, Hugues FRUCHET wrote:
>> Hi Sakari,
>>
>> On 8/16/19 10:15 AM, Sakari Ailus wrote:
>>> Hi Hugues,
>>>
>>> On Wed, Aug 14, 2019 at 03:48:51PM +0200, Hugues Fruchet wrote:
>>>> Add a trace of the set of supported fourcc/mbus_code which
>>>> intersect between DCMI and source sub-device.
>>>>
>>>> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
>>>> ---
>>>> drivers/media/platform/stm32/stm32-dcmi.c | 12 ++++++++++--
>>>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
>>>> index b462f71..18acecf 100644
>>>> --- a/drivers/media/platform/stm32/stm32-dcmi.c
>>>> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
>>>> @@ -1447,12 +1447,20 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
>>>> /* Code supported, have we got this fourcc yet? */
>>>> for (j = 0; j < num_fmts; j++)
>>>> if (sd_fmts[j]->fourcc ==
>>>> - dcmi_formats[i].fourcc)
>>>> + dcmi_formats[i].fourcc) {
>>>> /* Already available */
>>>> + dev_dbg(dcmi->dev, "Skipping fourcc/code: %4.4s/0x%x\n",
>>>> + (char *)&sd_fmts[j]->fourcc,
>>>> + mbus_code.code);
>>>> break;
>>>> - if (j == num_fmts)
>>>> + }
>>>> + if (j == num_fmts) {
>>>> /* New */
>>>> sd_fmts[num_fmts++] = dcmi_formats + i;
>>>> + dev_dbg(dcmi->dev, "Supported fourcc/code: %4.4s/0x%x\n",
>>>
>>> Over 80 characters per line.
>>>
>>
>> This an exception of the "80 chars" in order to be able to grep in
>> kernel messages:
>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>> "However, never break user-visible strings such as printk messages,
>> because that breaks the ability to grep for them."
>>
>> This exception is managed in checkpatch.pl (--strict).
>
> This exception is for cases where wrapping the line in the usual way, e.g.
> at argument boundaries, does not prevent it exceeding 80 characters. But it is
> not the case here.
>
BR,
Hugues.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1028a: fix gpio nodes
From: Shawn Guo @ 2019-08-19 7:40 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland, devicetree, linux-gpio, Linus Walleij, linux-kernel,
Li Yang, Bartosz Golaszewski, Rob Herring, linux-arm-kernel
In-Reply-To: <20190805065700.7601-1-hui.song_1@nxp.com>
On Mon, Aug 05, 2019 at 02:57:00PM +0800, Hui Song wrote:
> From: Song Hui <hui.song_1@nxp.com>
>
> Update the nodes to include little-endian
> property to be consistent with the hardware.
>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/3] ARM: dts: imx6ul: Add csi node
From: Shawn Guo @ 2019-08-19 7:38 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: Mark Rutland, devel, Pengutronix Kernel Team, devicetree,
Greg Kroah-Hartman, Sascha Hauer, Rui Miguel Silva, Rob Herring,
NXP Linux Team, Philipp Zabel, Steve Longerbeam,
Mauro Carvalho Chehab, Fabio Estevam, linux-arm-kernel,
linux-media
In-Reply-To: <20190731163257.32448-1-sebastien.szymanski@armadeus.com>
On Wed, Jul 31, 2019 at 06:32:57PM +0200, Sébastien Szymanski wrote:
> Add csi node for i.MX6UL SoC.
>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 19/26] arm64: remove __iounmap
From: Will Deacon @ 2019-08-19 7:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-ia64, linux-sh, linux-kernel, Guo Ren, sparclinux,
linux-riscv, Vincent Chen, linux-arch, linux-s390, linux-hexagon,
x86, linux-snps-arc, linux-xtensa, Arnd Bergmann, linux-m68k,
openrisc, Greentime Hu, linux-mtd, Guan Xuetao, linux-arm-kernel,
Michal Simek, linux-parisc, linux-mips, linux-alpha, nios2-dev
In-Reply-To: <20190817073253.27819-20-hch@lst.de>
On Sat, Aug 17, 2019 at 09:32:46AM +0200, Christoph Hellwig wrote:
> No need to indirect iounmap for arm64.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/include/asm/io.h | 3 +--
> arch/arm64/mm/ioremap.c | 4 ++--
> 2 files changed, 3 insertions(+), 4 deletions(-)
Not sure why we did it like this...
Acked-by: Will Deacon <will@kernel.org>
Will
_______________________________________________
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 11/11] arm64: use asm-generic/dma-mapping.h
From: Will Deacon @ 2019-08-19 7:32 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Stefano Stabellini, Konrad Rzeszutek Wilk, x86, linux-kernel,
iommu, xen-devel, linux-arm-kernel
In-Reply-To: <20190816130013.31154-12-hch@lst.de>
On Fri, Aug 16, 2019 at 03:00:13PM +0200, Christoph Hellwig wrote:
> Now that the Xen special cases are gone nothing worth mentioning is
> left in the arm64 <asm/dma-mapping.h> file, so switch to use the
> asm-generic version instead.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/include/asm/Kbuild | 1 +
> arch/arm64/include/asm/dma-mapping.h | 22 ----------------------
> arch/arm64/mm/dma-mapping.c | 1 +
> 3 files changed, 2 insertions(+), 22 deletions(-)
> delete mode 100644 arch/arm64/include/asm/dma-mapping.h
Acked-by: Will Deacon <will@kernel.org>
Thanks for cleaning this up.
Will
_______________________________________________
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 v6 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Sakari Ailus @ 2019-08-19 7:26 UTC (permalink / raw)
To: Hugues FRUCHET
Cc: Yannick FERTRE, Alexandre TORGUE, Mickael GUENE,
linux-kernel@vger.kernel.org, Philippe CORNU, Hans Verkuil,
Benjamin Gaignard, Mauro Carvalho Chehab,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <fb02573f-991a-18c5-b780-b5fc100da6a8@st.com>
Hi Hugues,
On Mon, Aug 19, 2019 at 07:23:17AM +0000, Hugues FRUCHET wrote:
> Hi Sakari,
>
> On 8/16/19 10:15 AM, Sakari Ailus wrote:
> > Hi Hugues,
> >
> > On Wed, Aug 14, 2019 at 03:48:51PM +0200, Hugues Fruchet wrote:
> >> Add a trace of the set of supported fourcc/mbus_code which
> >> intersect between DCMI and source sub-device.
> >>
> >> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
> >> ---
> >> drivers/media/platform/stm32/stm32-dcmi.c | 12 ++++++++++--
> >> 1 file changed, 10 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> >> index b462f71..18acecf 100644
> >> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> >> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> >> @@ -1447,12 +1447,20 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
> >> /* Code supported, have we got this fourcc yet? */
> >> for (j = 0; j < num_fmts; j++)
> >> if (sd_fmts[j]->fourcc ==
> >> - dcmi_formats[i].fourcc)
> >> + dcmi_formats[i].fourcc) {
> >> /* Already available */
> >> + dev_dbg(dcmi->dev, "Skipping fourcc/code: %4.4s/0x%x\n",
> >> + (char *)&sd_fmts[j]->fourcc,
> >> + mbus_code.code);
> >> break;
> >> - if (j == num_fmts)
> >> + }
> >> + if (j == num_fmts) {
> >> /* New */
> >> sd_fmts[num_fmts++] = dcmi_formats + i;
> >> + dev_dbg(dcmi->dev, "Supported fourcc/code: %4.4s/0x%x\n",
> >
> > Over 80 characters per line.
> >
>
> This an exception of the "80 chars" in order to be able to grep in
> kernel messages:
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
> "However, never break user-visible strings such as printk messages,
> because that breaks the ability to grep for them."
>
> This exception is managed in checkpatch.pl (--strict).
This exception is for cases where wrapping the line in the usual way, e.g.
at argument boundaries, does not prevent it exceeding 80 characters. But it is
not the case here.
--
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] firmware: arm_scmi: add include guard to linux/scmi_protocol.h
From: Masahiro Yamada @ 2019-08-19 7:27 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Masahiro Yamada, linux-kernel, linux-arm-kernel
Add a header include guard just in case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
include/linux/scmi_protocol.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 9ff2e9357e9a..8a840e644907 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -4,6 +4,10 @@
*
* Copyright (C) 2018 ARM Ltd.
*/
+
+#ifndef _LINUX_SCMI_PROTOCOL_H
+#define _LINUX_SCMI_PROTOCOL_H
+
#include <linux/device.h>
#include <linux/types.h>
@@ -288,3 +292,5 @@ static inline void scmi_driver_unregister(struct scmi_driver *driver) {}
typedef int (*scmi_prot_init_fn_t)(struct scmi_handle *);
int scmi_protocol_register(int protocol_id, scmi_prot_init_fn_t fn);
void scmi_protocol_unregister(int protocol_id);
+
+#endif /* _LINUX_SCMI_PROTOCOL_H */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V5 5/5] arm64: dts: imx8mm: Enable cpu-idle driver
From: Shawn Guo @ 2019-08-19 7:27 UTC (permalink / raw)
To: Daniel Lezcano
Cc: mark.rutland, ping.bai, ccaione, catalin.marinas, agx, angus,
leonard.crestez, festevam, abel.vesa, Anson.Huang, andrew.smirnov,
will, linux-imx, devicetree, s.hauer, robh+dt, tglx,
daniel.baluta, linux-arm-kernel, aisheng.dong, linux-kernel,
kernel, l.stach
In-Reply-To: <34c03d76-ae61-63b4-153f-3f9911cc962e@linaro.org>
On Thu, Aug 15, 2019 at 06:12:50PM +0200, Daniel Lezcano wrote:
>
> Hi Anson,
>
> sorry for the late review, I've been pretty busy.
>
> If Shawn is ok, I can pick the patches 1-4 in my tree and then this one
> after you fix the comments below.
I'm okay, so:
Acked-by: Shawn Guo <shawnguo@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
* [PATCH] soc: amlogic: meson-gx-socinfo: Add of_node_put() before return
From: Nishka Dasgupta @ 2019-08-19 7:27 UTC (permalink / raw)
To: khilman, linux-arm-kernel, linux-amlogic; +Cc: Nishka Dasgupta
The variable np in function meson_gx_socinfo_init takes the return value
of of_find_compatible_node, which gets a node but does not put it. If
this node is not put it may cause a memory leak. Hence put np after its
usefulness has been exhausted.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/soc/amlogic/meson-gx-socinfo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
index bca34954518e..13695a72c695 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -138,8 +138,10 @@ static int __init meson_gx_socinfo_init(void)
}
/* check if chip-id is available */
- if (!of_property_read_bool(np, "amlogic,has-chip-id"))
+ if (!of_property_read_bool(np, "amlogic,has-chip-id")) {
+ of_node_put(np);
return -ENODEV;
+ }
/* node should be a syscon */
regmap = syscon_node_to_regmap(np);
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] usb: dwc3: qcom: Add of_node_put() before return in register function
From: Nishka Dasgupta @ 2019-08-19 7:25 UTC (permalink / raw)
To: agross, balbi, gregkh, linux-arm-kernel, linux-usb; +Cc: Nishka Dasgupta
The variable dwc3_np in the function dwc3_qcom_of_register_core takes the
value returned by of_get_child_by_name, which gets a node but does not
put it. This may cause a memory leak. Hence create a new label,
err_node_put, that puts dwc3_np and returns the required value, and
modify two return statements to instead save the required return value
in existing variable ret and then point to this label.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/usb/dwc3/dwc3-qcom.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 261af9e38ddd..227f4fee184a 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -528,16 +528,19 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to register dwc3 core - %d\n", ret);
- return ret;
+ goto err_node_put;
}
qcom->dwc3 = of_find_device_by_node(dwc3_np);
if (!qcom->dwc3) {
dev_err(dev, "failed to get dwc3 platform device\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_node_put;
}
- return 0;
+err_node_put:
+ of_node_put(dwc3_np);
+ return ret;
}
static const struct dwc3_acpi_pdata sdm845_acpi_pdata = {
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] usb: dwc3: st: Add of_dev_put() in probe function
From: Nishka Dasgupta @ 2019-08-19 7:24 UTC (permalink / raw)
To: patrice.chotard, balbi, gregkh, linux-arm-kernel, linux-usb
Cc: Nishka Dasgupta
In-Reply-To: <20190819072436.31402-1-nishkadg.linux@gmail.com>
In function st_dwc3_probe, variable child_pdev takes the value returned
by of_find_device_by_node, which gets a device pointer but does not put
it. If child_pdev is not put before the probe function returns, it may
cause a reference leak. Hence put child_pdev after its last usage.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/usb/dwc3/dwc3-st.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index 6f52c749cd58..c682420f25ca 100644
--- a/drivers/usb/dwc3/dwc3-st.c
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -274,6 +274,7 @@ static int st_dwc3_probe(struct platform_device *pdev)
dwc3_data->dr_mode = usb_get_dr_mode(&child_pdev->dev);
of_node_put(child);
+ of_dev_put(child_pdev);
/*
* Configure the USB port as device or host according to the static
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] usb: dwc3: st: Add of_node_put() before return in probe function
From: Nishka Dasgupta @ 2019-08-19 7:24 UTC (permalink / raw)
To: patrice.chotard, balbi, gregkh, linux-arm-kernel, linux-usb
Cc: Nishka Dasgupta
The local variable child in the function st_dwc3_probe takes the return
value of of_get_child_by_name, which gets a node and does not put it. If
the function returns without releasing child, this could cause a memory
error. Hence put child as soon as there is no more use for it. Also
create a new label, err_node_put, just before label undo_softreset; so
that err_node_put puts child. In between initialisation of child and its
first put, modify all statements that go to undo_softreset to now go to
err_node_put instead, from where they can fall through to
undo_softreset.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/usb/dwc3/dwc3-st.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index 16081383c401..6f52c749cd58 100644
--- a/drivers/usb/dwc3/dwc3-st.c
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -255,24 +255,25 @@ static int st_dwc3_probe(struct platform_device *pdev)
if (!child) {
dev_err(&pdev->dev, "failed to find dwc3 core node\n");
ret = -ENODEV;
- goto undo_softreset;
+ goto err_node_put;
}
/* Allocate and initialize the core */
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
- goto undo_softreset;
+ goto err_node_put;
}
child_pdev = of_find_device_by_node(child);
if (!child_pdev) {
dev_err(dev, "failed to find dwc3 core device\n");
ret = -ENODEV;
- goto undo_softreset;
+ goto err_node_put;
}
dwc3_data->dr_mode = usb_get_dr_mode(&child_pdev->dev);
+ of_node_put(child);
/*
* Configure the USB port as device or host according to the static
@@ -292,6 +293,8 @@ static int st_dwc3_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dwc3_data);
return 0;
+err_node_put:
+ of_node_put(child);
undo_softreset:
reset_control_assert(dwc3_data->rstc_rst);
undo_powerdown:
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Hugues FRUCHET @ 2019-08-19 7:23 UTC (permalink / raw)
To: Sakari Ailus
Cc: Yannick FERTRE, Alexandre TORGUE, Mickael GUENE,
linux-kernel@vger.kernel.org, Philippe CORNU, Hans Verkuil,
Benjamin Gaignard, Mauro Carvalho Chehab,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <20190816081514.GU6133@paasikivi.fi.intel.com>
Hi Sakari,
On 8/16/19 10:15 AM, Sakari Ailus wrote:
> Hi Hugues,
>
> On Wed, Aug 14, 2019 at 03:48:51PM +0200, Hugues Fruchet wrote:
>> Add a trace of the set of supported fourcc/mbus_code which
>> intersect between DCMI and source sub-device.
>>
>> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
>> ---
>> drivers/media/platform/stm32/stm32-dcmi.c | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
>> index b462f71..18acecf 100644
>> --- a/drivers/media/platform/stm32/stm32-dcmi.c
>> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
>> @@ -1447,12 +1447,20 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
>> /* Code supported, have we got this fourcc yet? */
>> for (j = 0; j < num_fmts; j++)
>> if (sd_fmts[j]->fourcc ==
>> - dcmi_formats[i].fourcc)
>> + dcmi_formats[i].fourcc) {
>> /* Already available */
>> + dev_dbg(dcmi->dev, "Skipping fourcc/code: %4.4s/0x%x\n",
>> + (char *)&sd_fmts[j]->fourcc,
>> + mbus_code.code);
>> break;
>> - if (j == num_fmts)
>> + }
>> + if (j == num_fmts) {
>> /* New */
>> sd_fmts[num_fmts++] = dcmi_formats + i;
>> + dev_dbg(dcmi->dev, "Supported fourcc/code: %4.4s/0x%x\n",
>
> Over 80 characters per line.
>
This an exception of the "80 chars" in order to be able to grep in
kernel messages:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
"However, never break user-visible strings such as printk messages,
because that breaks the ability to grep for them."
This exception is managed in checkpatch.pl (--strict).
>> + (char *)&sd_fmts[num_fmts - 1]->fourcc,
>> + sd_fmts[num_fmts - 1]->mbus_code);
>> + }
>> }
>> mbus_code.index++;
>> }
>
BR,
Hugues.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 3/3] arm64: kexec_file: add rng-seed support
From: Hsin-Yi Wang @ 2019-08-19 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Yu Zhao, Kees Cook, Ard Biesheuvel,
Catalin Marinas, Stephen Boyd, Will Deacon, linux-kernel,
Mike Rapoport, Jun Yao, Miles Chen, Rob Herring, James Morse,
Hsin-Yi Wang, Andrew Murray, Andrew Morton, Laura Abbott,
Frank Rowand, Robin Murphy
In-Reply-To: <20190819071602.139014-1-hsinyi@chromium.org>
Adding "rng-seed" to dtb. It's fine to add this property if original
fdt doesn't contain it. Since original seed will be wiped after
read, so use a default size 128 bytes here.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
No change after v7.
---
arch/arm64/kernel/machine_kexec_file.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index ba78ee7ca990..7b08bf9499b6 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -27,6 +27,8 @@
#define FDT_PROP_INITRD_END "linux,initrd-end"
#define FDT_PROP_BOOTARGS "bootargs"
#define FDT_PROP_KASLR_SEED "kaslr-seed"
+#define FDT_PROP_RNG_SEED "rng-seed"
+#define RNG_SEED_SIZE 128
const struct kexec_file_ops * const kexec_file_loaders[] = {
&kexec_image_ops,
@@ -102,6 +104,19 @@ static int setup_dtb(struct kimage *image,
FDT_PROP_KASLR_SEED);
}
+ /* add rng-seed */
+ if (rng_is_initialized()) {
+ u8 rng_seed[RNG_SEED_SIZE];
+ get_random_bytes(rng_seed, RNG_SEED_SIZE);
+ ret = fdt_setprop(dtb, off, FDT_PROP_RNG_SEED, rng_seed,
+ RNG_SEED_SIZE);
+ if (ret)
+ goto out;
+ } else {
+ pr_notice("RNG is not initialised: omitting \"%s\" property\n",
+ FDT_PROP_RNG_SEED);
+ }
+
out:
if (ret)
return (ret == -FDT_ERR_NOSPACE) ? -ENOMEM : -EINVAL;
@@ -110,7 +125,8 @@ static int setup_dtb(struct kimage *image,
}
/*
- * More space needed so that we can add initrd, bootargs and kaslr-seed.
+ * More space needed so that we can add initrd, bootargs, kaslr-seed, and
+ * rng-seed.
*/
#define DTB_EXTRA_SPACE 0x1000
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 2/3] fdt: add support for rng-seed
From: Hsin-Yi Wang @ 2019-08-19 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Yu Zhao, Kees Cook, Ard Biesheuvel,
Catalin Marinas, Stephen Boyd, Will Deacon, linux-kernel,
Mike Rapoport, Jun Yao, Miles Chen, Rob Herring, James Morse,
Hsin-Yi Wang, Andrew Murray, Andrew Morton, Laura Abbott,
Frank Rowand, Robin Murphy
In-Reply-To: <20190819071602.139014-1-hsinyi@chromium.org>
Introducing a chosen node, rng-seed, which is an entropy that can be
passed to kernel called very early to increase initial device
randomness. Bootloader should provide this entropy and the value is
read from /chosen/rng-seed in DT.
Obtain of_fdt_crc32 for CRC check after early_init_dt_scan_nodes(),
since early_init_dt_scan_chosen() would modify fdt to erase rng-seed.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Change from v7:
obtain of_fdt_crc32 after early_init_dt_scan_nodes().
---
drivers/of/fdt.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9cdf14b9aaab..97a75996993c 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -24,6 +24,7 @@
#include <linux/debugfs.h>
#include <linux/serial_core.h>
#include <linux/sysfs.h>
+#include <linux/random.h>
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#include <asm/page.h>
@@ -1044,6 +1045,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
{
int l;
const char *p;
+ const void *rng_seed;
pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
@@ -1078,6 +1080,14 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
pr_debug("Command line is: %s\n", (char*)data);
+ rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
+ if (rng_seed && l > 0) {
+ add_device_randomness(rng_seed, l);
+
+ /* try to clear seed so it won't be found. */
+ fdt_nop_property(initial_boot_params, node, "rng-seed");
+ }
+
/* break now */
return 1;
}
@@ -1166,8 +1176,6 @@ bool __init early_init_dt_verify(void *params)
/* Setup flat device-tree pointer */
initial_boot_params = params;
- of_fdt_crc32 = crc32_be(~0, initial_boot_params,
- fdt_totalsize(initial_boot_params));
return true;
}
@@ -1197,6 +1205,8 @@ bool __init early_init_dt_scan(void *params)
return false;
early_init_dt_scan_nodes();
+ of_fdt_crc32 = crc32_be(~0, initial_boot_params,
+ fdt_totalsize(initial_boot_params));
return true;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 1/3] arm64: map FDT as RW for early_init_dt_scan()
From: Hsin-Yi Wang @ 2019-08-19 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Yu Zhao, Kees Cook, Ard Biesheuvel,
Catalin Marinas, Stephen Boyd, Will Deacon, linux-kernel,
Mike Rapoport, Jun Yao, Miles Chen, Rob Herring, James Morse,
Hsin-Yi Wang, Andrew Murray, Andrew Morton, Laura Abbott,
Frank Rowand, Robin Murphy
In-Reply-To: <20190819071602.139014-1-hsinyi@chromium.org>
Currently in arm64, FDT is mapped to RO before it's passed to
early_init_dt_scan(). However, there might be some codes
(eg. commit "fdt: add support for rng-seed") that need to modify FDT
during init. Map FDT to RO after early fixups are done.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
---
No change from v7.
---
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/kaslr.c | 5 +----
arch/arm64/kernel/setup.c | 9 ++++++++-
arch/arm64/mm/mmu.c | 15 +--------------
4 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index fd6161336653..f217e3292919 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -126,7 +126,7 @@ extern void init_mem_pgprot(void);
extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
pgprot_t prot, bool page_mappings_only);
-extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
+extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
extern void mark_linear_text_alias_ro(void);
#define INIT_MM_CONTEXT(name) \
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 5a59f7567f9c..416f537bf614 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -62,9 +62,6 @@ static __init const u8 *kaslr_get_cmdline(void *fdt)
return default_cmdline;
}
-extern void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size,
- pgprot_t prot);
-
/*
* This routine will be executed with the kernel mapped at its default virtual
* address, and if it returns successfully, the kernel will be remapped, and
@@ -93,7 +90,7 @@ u64 __init kaslr_early_init(u64 dt_phys)
* attempt at mapping the FDT in setup_machine()
*/
early_fixmap_init();
- fdt = __fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
+ fdt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
if (!fdt)
return 0;
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 57ff38600828..56f664561754 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -170,9 +170,13 @@ static void __init smp_build_mpidr_hash(void)
static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
- void *dt_virt = fixmap_remap_fdt(dt_phys);
+ int size;
+ void *dt_virt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
const char *name;
+ if (dt_virt)
+ memblock_reserve(dt_phys, size);
+
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("\n"
"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
@@ -184,6 +188,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
cpu_relax();
}
+ /* Early fixups are done, map the FDT as read-only now */
+ fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL_RO);
+
name = of_flat_dt_get_machine_name();
if (!name)
return;
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e67bab4d613e..1586d7fbf26a 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -877,7 +877,7 @@ void __set_fixmap(enum fixed_addresses idx,
}
}
-void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
+void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
{
const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
int offset;
@@ -930,19 +930,6 @@ void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
return dt_virt;
}
-void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
-{
- void *dt_virt;
- int size;
-
- dt_virt = __fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL_RO);
- if (!dt_virt)
- return NULL;
-
- memblock_reserve(dt_phys, size);
- return dt_virt;
-}
-
int __init arch_ioremap_p4d_supported(void)
{
return 0;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 0/3] add support for rng-seed
From: Hsin-Yi Wang @ 2019-08-19 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Yu Zhao, Kees Cook, Ard Biesheuvel,
Catalin Marinas, Stephen Boyd, Will Deacon, linux-kernel,
Mike Rapoport, Jun Yao, Miles Chen, Rob Herring, James Morse,
Hsin-Yi Wang, Andrew Murray, Andrew Morton, Laura Abbott,
Frank Rowand, Robin Murphy
Introducing a chosen node, rng-seed, which is an entropy that can be
passed to kernel called very early to increase initial device
randomness. This can be used for adding sufficient initial entropy
for stack canary. Especially architectures that lack per-stack canary.
Hsin-Yi Wang (3):
arm64: map FDT as RW for early_init_dt_scan()
fdt: add support for rng-seed
arm64: kexec_file: add rng-seed support
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/kaslr.c | 5 +----
arch/arm64/kernel/machine_kexec_file.c | 18 +++++++++++++++++-
arch/arm64/kernel/setup.c | 9 ++++++++-
arch/arm64/mm/mmu.c | 15 +--------------
drivers/of/fdt.c | 14 ++++++++++++--
6 files changed, 40 insertions(+), 23 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: zynq-qspi: Fix missing spi_unregister_controller when unload module
From: Michal Simek @ 2019-08-19 6:54 UTC (permalink / raw)
To: Axel Lin, Mark Brown; +Cc: Michal Simek, linux-arm-kernel, linux-spi
In-Reply-To: <20190818095113.2397-1-axel.lin@ingics.com>
On 18. 08. 19 11:51, Axel Lin wrote:
> Use devm_spi_register_controller to fix missing spi_unregister_controller
> when unload module.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
> ---
> drivers/spi/spi-zynq-qspi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
> index 3155e2cabb1e..4a5326ccf65a 100644
> --- a/drivers/spi/spi-zynq-qspi.c
> +++ b/drivers/spi/spi-zynq-qspi.c
> @@ -694,7 +694,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> ctlr->setup = zynq_qspi_setup_op;
> ctlr->max_speed_hz = clk_get_rate(xqspi->refclk) / 2;
> ctlr->dev.of_node = np;
> - ret = spi_register_controller(ctlr);
> + ret = devm_spi_register_controller(&pdev->dev, ctlr);
> if (ret) {
> dev_err(&pdev->dev, "spi_register_master failed\n");
> goto clk_dis_all;
>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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