* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-19 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219011315.2fa0f9d1@xps13>
On Tue, Dec 19, 2017 at 01:13:15AM +0100, Miquel RAYNAL wrote:
> Boris' fix wouldn't apply anyway as it was written for pxa3xx_nand.c
> and here you are using marvell_nand.c and the code is really different.
yep I noticed already during the first problem, I couldn't even find
where the equivalent part of the code was located.
> Thanks again for your help, reviews or tested-by's are welcome for this
> driver ;)
do not hesitate to add my tested-by on your current patchset if that helps.
Willy
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-19 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpOmeEMuoCkTC7MrBDaA1J5a4vZ_7bh3HSC0G5GoAMUCjw@mail.gmail.com>
On Tue, Dec 19, 2017 at 02:58:20AM +0530, Bhupesh Sharma wrote:
> Hi Dave,
>
> On Mon, Dec 18, 2017 at 10:46 AM, Dave Young <dyoung@redhat.com> wrote:
> > kexec at fedoraproject... is for Fedora kexec scripts discussion, changed it
> > to kexec at lists.infradead.org
> >
> > Also add linux-acpi list
> > On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
> >> On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
> >> <ard.biesheuvel@linaro.org> wrote:
> >> > On 15 December 2017 at 09:59, AKASHI Takahiro
> >> > <takahiro.akashi@linaro.org> wrote:
> >> >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> >> >>> On 13 December 2017 at 12:16, AKASHI Takahiro
> >> >>> <takahiro.akashi@linaro.org> wrote:
> >> >>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >> >>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >> >>> >> <takahiro.akashi@linaro.org> wrote:
> >> >>> >> > Bhupesh, Ard,
> >> >>> >> >
> >> >>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >> >>> >> >> Hi Ard, Akashi
> >> >>> >> >>
> >> >>> >> > (snip)
> >> >>> >> >
> >> >>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >> >>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >> >>> >> >> identify its own usable memory and exclude, at its boot time, any
> >> >>> >> >> other memory areas that are part of the panicked kernel's memory.
> >> >>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >> >>> >> >> , for details)
> >> >>> >> >
> >> >>> >> > Right.
> >> >>> >> >
> >> >>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >> >>> >> >> with the crashkernel memory range:
> >> >>> >> >>
> >> >>> >> >> /* add linux,usable-memory-range */
> >> >>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >> >>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >> >>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >> >>> >> >> address_cells, size_cells);
> >> >>> >> >>
> >> >>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >> >>> >> >> , for details)
> >> >>> >> >>
> >> >>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >> >>> >> >> they are marked as System RAM or as RESERVED. As,
> >> >>> >> >> 'linux,usable-memory-range' dt node is patched up only with
> >> >>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >> >>> >> >>
> >> >>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >> >>> >> >> ACPI memory and crashes while trying to access the same:
> >> >>> >> >>
> >> >>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >> >>> >> >> -r`.img --reuse-cmdline -d
> >> >>> >> >>
> >> >>> >> >> [snip..]
> >> >>> >> >>
> >> >>> >> >> Reserved memory range
> >> >>> >> >> 000000000e800000-000000002e7fffff (0)
> >> >>> >> >>
> >> >>> >> >> Coredump memory ranges
> >> >>> >> >> 0000000000000000-000000000e7fffff (0)
> >> >>> >> >> 000000002e800000-000000003961ffff (0)
> >> >>> >> >> 0000000039d40000-000000003ed2ffff (0)
> >> >>> >> >> 000000003ed60000-000000003fbfffff (0)
> >> >>> >> >> 0000001040000000-0000001ffbffffff (0)
> >> >>> >> >> 0000002000000000-0000002ffbffffff (0)
> >> >>> >> >> 0000009000000000-0000009ffbffffff (0)
> >> >>> >> >> 000000a000000000-000000affbffffff (0)
> >> >>> >> >>
> >> >>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >> >>> >> >> memory cap'ing passed to the crash kernel inside
> >> >>> >> >> 'arch/arm64/mm/init.c' (see below):
> >> >>> >> >>
> >> >>> >> >> static void __init fdt_enforce_memory_region(void)
> >> >>> >> >> {
> >> >>> >> >> struct memblock_region reg = {
> >> >>> >> >> .size = 0,
> >> >>> >> >> };
> >> >>> >> >>
> >> >>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> >>> >> >>
> >> >>> >> >> if (reg.size)
> >> >>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >> >>> >> >> comment this out */
> >> >>> >> >> }
> >> >>> >> >
> >> >>> >> > Please just don't do that. It can cause a fatal damage on
> >> >>> >> > memory contents of the *crashed* kernel.
> >> >>> >> >
> >> >>> >> >> 5). Both the above temporary solutions fix the problem.
> >> >>> >> >>
> >> >>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >> >>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >> >>> >> >> fail.
> >> >>> >> >>
> >> >>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >> >>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >> >>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >> >>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >> >>> >> >> dt node 'linux,usable-memory-range'
> >> >>> >> >
> >> >>> >> > I still don't understand why we need to carry over the information
> >> >>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >> >>> >> > such regions are free to be reused by the kernel after some point of
> >> >>> >> > initialization. Why does crash dump kernel need to know about them?
> >> >>> >> >
> >> >>> >>
> >> >>> >> Not really. According to the UEFI spec, they can be reclaimed after
> >> >>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >> >>> >> no longer needs them. Of course, in order to be able to boot a kexec
> >> >>> >> kernel, those regions needs to be preserved, which is why they are
> >> >>> >> memblock_reserve()'d now.
> >> >>> >
> >> >>> > For my better understandings, who is actually accessing such regions
> >> >>> > during boot time, uefi itself or efistub?
> >> >>> >
> >> >>>
> >> >>> No, only the kernel. This is where the ACPI tables are stored. For
> >> >>> instance, on QEMU we have
> >> >>>
> >> >>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> >> >>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> >> >>> 01000013)
> >> >>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> >> >>> BXPC 00000001)
> >> >>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> >> >>> BXPC 00000001)
> >> >>>
> >> >>> covered by
> >> >>>
> >> >>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> >> >>> ...
> >> >>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >> >>
> >> >> OK. I mistakenly understood those regions could be freed after exiting
> >> >> UEFI boot services.
> >> >>
> >> >>>
> >> >>> >> So it seems that kexec does not honour the memblock_reserve() table
> >> >>> >> when booting the next kernel.
> >> >>> >
> >> >>> > not really.
> >> >>> >
> >> >>> >> > (In other words, can or should we skip some part of ACPI-related init code
> >> >>> >> > on crash dump kernel?)
> >> >>> >> >
> >> >>> >>
> >> >>> >> I don't think so. And the change to the handling of ACPI reclaim
> >> >>> >> regions only revealed the bug, not created it (given that other
> >> >>> >> memblock_reserve regions may be affected as well)
> >> >>> >
> >> >>> > As whether we should honor such reserved regions over kexec'ing
> >> >>> > depends on each one's specific nature, we will have to take care one-by-one.
> >> >>> > As a matter of fact, no information about "reserved" memblocks is
> >> >>> > exposed to user space (via proc/iomem).
> >> >>> >
> >> >>>
> >> >>> That is why I suggested (somewhere in this thread?) to not expose them
> >> >>> as 'System RAM'. Do you think that could solve this?
> >> >>
> >> >> Memblock-reserv'ing them is necessary to prevent their corruption and
> >> >> marking them under another name in /proc/iomem would also be good in order
> >> >> not to allocate them as part of crash kernel's memory.
> >> >>
> >> >
> >> > I agree. However, this may not be entirely trivial, since iterating
> >> > over the memblock_reserved table and creating iomem entries may result
> >> > in collisions.
> >>
> >> I found a method (using the patch I shared earlier in this thread) to mark these
> >> entries as 'ACPI reclaim memory' ranges rather than System RAM or
> >> reserved regions.
> >>
> >> >> But I'm not still convinced that we should export them in useable-
> >> >> memory-range to crash dump kernel. They will be accessed through
> >> >> acpi_os_map_memory() and so won't be required to be part of system ram
> >> >> (or memblocks), I guess.
> >> >
> >> > Agreed. They will be covered by the linear mapping in the boot kernel,
> >> > and be mapped explicitly via ioremap_cache() in the kexec kernel,
> >> > which is exactly what we want in this case.
> >>
> >> Now this is what is confusing me. I don't see the above happening.
> >>
> >> I see that the primary kernel boots up and adds the ACPI regions via:
> >> acpi_os_ioremap
> >> -> ioremap_cache
> >>
> >> But during the crashkernel boot, ''acpi_os_ioremap' calls
> >> 'ioremap' for the ACPI Reclaim Memory regions and not the _cache
> >> variant.
> >>
> >> And it fails while accessing the ACPI tables:
> >>
> >> [ 0.039205] ACPI: Core revision 20170728
> >> pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> >> [ 0.095098] Internal error: Oops: 96000021 [#1] SMP
> >> [ 0.100022] Modules linked in:
> >> [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> >> [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
> >> [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
> >> [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
> >> [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
> >> pstate: 60000045
> >> [ 0.132647] sp : ffff000008ccfb40
> >> [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
> >> [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
> >> [ 0.146718] x25: 000000000000001b x24: 0000000000000001
> >> [ 0.152083] x23: 0000000000000001 x22: ffff000009710027
> >> [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
> >> [ 0.162812] x19: 000000000000001b x18: 0000000000000005
> >> [ 0.168176] x17: 0000000000000000 x16: 0000000000000000
> >> [ 0.173541] x15: 0000000000000000 x14: 000000000000038e
> >> [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
> >> [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
> >> [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
> >> [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
> >> [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
> >> [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
> >> [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
> >> [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> >> [ 0.223224] Call trace:
> >> [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
> >> [ 0.232194] fa00: 0000000000000000 ffff000009710027
> >> ffff0000095e3980 ffff000008ccfbe0
> >> [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
> >> ffff000008ccfc50 0000000000000000
> >> [ 0.248018] fa40: ffff8000126d0140 000000000000005f
> >> 00000000ffffff76 0000000000000006
> >> [ 0.255931] fa60: ffffffffffffffff ffffffff00000000
> >> 000000000000038e 0000000000000000
> >> [ 0.263843] fa80: 0000000000000000 0000000000000000
> >> 0000000000000005 000000000000001b
> >> [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
> >> ffff000009710027 0000000000000001
> >> [ 0.279667] fac0: 0000000000000001 000000000000001b
> >> 0000000000000000 ffff0000088be820
> >> [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
> >> ffff00000849b4f8 ffff000008ccfb40
> >> [ 0.295491] fb00: ffff0000084a6764 0000000060000045
> >> ffff000008ccfb40 ffff000008260a18
> >> [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
> >> ffff000008ccfb40 ffff0000084a6764
> >> [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> >> [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> >> [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> >> [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> >> [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> >> [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> >> [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> >> [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> >> [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> >> [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> >> [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> >> [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> >> [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> >> [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> >> [ 0.394500] ---[ end trace c46ed37f9651c58e ]---
> >> [ 0.399160] Kernel panic - not syncing: Fatal exception
> >> [ 0.404437] Rebooting in 10 seconds.
> >>
> >> So, I think the linear mapping done by the primary kernel does not
> >> make these accessible in the crash kernel directly.
> >>
> >> Any pointers?
> >
> > Can you get the code line number for acpi_ns_lookup+0x25c?
>
> gdb points to the following code line number:
>
> (gdb) list *(acpi_ns_lookup+0x25c)
> 0xffff0000084aa250 is in acpi_ns_lookup (drivers/acpi/acpica/nsaccess.c:577).
> 572 }
> 573 }
> 574
> 575 /* Extract one ACPI name from the front of the pathname */
> 576
> 577 ACPI_MOVE_32_TO_32(&simple_name, path);
> 578
> 579 /* Try to find the single (4 character) ACPI name */
> 580
> 581 status =
> (gdb)
>
> i.e. ACPI_MOVE_32_TO_32(&simple_name, path);
This macro can be defined in two ways depending on
ACPI_MISALIGNMENT_NOT_SUPPORTED in drivers/acpi/acpica/acmarcos.h.
So, in principle, any use of ioremap() in acpi_os_ioremap() may be
in conflict with those definitions here.
This suggests that, under the current code base, we must expose
ACPI reclaim regions as memblocks (i.e. via usable-memory-range)
in order to avoid the reported issue.
Thanks,
-Takahiro AKASHI
> addr2line also confirms the same:
>
> # addr2line -e vmlinux ffff0000084aa250
> /root/git/kernel-alt/drivers/acpi/acpica/nsaccess.c:577
>
>
> Regards,
> Bhupesh
>
>
> >>
> >> Regards,
> >> Bhupesh
> >>
> >> >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> >> via a kernel command line parameter, "memmap=".
> >> >>
> >> _______________________________________________
> >> kexec mailing list -- kexec at lists.fedoraproject.org
> >> To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-19 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFTCetQ55zUKe25jSku0DHp8uVZA4hB32d5W6MSCNsTVpxu7Gw@mail.gmail.com>
On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>
> [snip..]
>
> [ 0.000000] linux,usable-memory-range base e800000, size 20000000
> [ 0.000000] - e800000 , 20000000
> [ 0.000000] linux,usable-memory-range base 396c0000, size a0000
> [ 0.000000] - 396c0000 , a0000
> [ 0.000000] linux,usable-memory-range base 39770000, size 40000
> [ 0.000000] - 39770000 , 40000
> [ 0.000000] linux,usable-memory-range base 398a0000, size 20000
> [ 0.000000] - 398a0000 , 20000
> [ 0.000000] initrd not fully accessible via the linear mapping --
> please check your bootloader ...
This is an odd message coming from:
|void __init arm64_memblock_init(void)
|...
|
| if (WARN(base < memblock_start_of_DRAM() ||
| base + size > memblock_start_of_DRAM() +
| linear_region_size,
| "initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) {
Can you confirm how the condition breaks here?
I suppose
base: 0xfe70000
size: 0x13c0000
memblock_start_of_DRAM(): 0xe800000
according to the information you gave me.
Thanks,
-Takahiro AKASHI
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:597
> arm64_memblock_init+0x210/0x484
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0+ #7
> [ 0.000000] task: ffff000008d05580 task.stack: ffff000008cc0000
> [ 0.000000] PC is at arm64_memblock_init+0x210/0x484
> [ 0.000000] LR is at arm64_memblock_init+0x210/0x484
> [ 0.000000] pc : [<ffff000008b76984>] lr : [<ffff000008b76984>]
> pstate: 600000c5
> [ 0.000000] sp : ffff000008ccfe80
> [ 0.000000] x29: ffff000008ccfe80 x28: 000000000f370018
> [ 0.000000] x27: 0000000011230000 x26: 00000000013b0000
> [ 0.000000] x25: 000000000fe80000 x24: ffff000008cf3000
> [ 0.000000] x23: ffff000008ec0000 x22: ffff000009680000
> [ 0.000000] x21: ffff000008afa000 x20: ffff000008080000
> [ 0.000000] x19: ffff000008afa000 x18: 000000000c283806
> [ 0.000000] x17: 0000000000000000 x16: ffff000008d05580
> [ 0.000000] x15: 000000002be00842 x14: 79206b6365686320
> [ 0.000000] x13: 657361656c70202d x12: 2d20676e69707061
> [ 0.000000] x11: 6d207261656e696c x10: 2065687420616976
> [ 0.000000] x9 : 00000000000000f4 x8 : ffff000008517414
> [ 0.000000] x7 : 746f6f622072756f x6 : 000000000000000d
> [ 0.000000] x5 : ffff000008c96360 x4 : 0000000000000001
> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
> [ 0.000000] Call trace:
> [ 0.000000] Exception stack(0xffff000008ccfd40 to 0xffff000008ccfe80)
> [ 0.000000] fd40: 0000000000000056 0000000000000000
> 0000000000000000 0000000000000000
> [ 0.000000] fd60: 0000000000000001 ffff000008c96360
> 000000000000000d 746f6f622072756f
> [ 0.000000] fd80: ffff000008517414 00000000000000f4
> 2065687420616976 6d207261656e696c
> [ 0.000000] fda0: 2d20676e69707061 657361656c70202d
> 79206b6365686320 000000002be00842
> [ 0.000000] fdc0: ffff000008d05580 0000000000000000
> 000000000c283806 ffff000008afa000
> [ 0.000000] fde0: ffff000008080000 ffff000008afa000
> ffff000009680000 ffff000008ec0000
> [ 0.000000] fe00: ffff000008cf3000 000000000fe80000
> 00000000013b0000 0000000011230000
> [ 0.000000] fe20: 000000000f370018 ffff000008ccfe80
> ffff000008b76984 ffff000008ccfe80
> [ 0.000000] fe40: ffff000008b76984 00000000600000c5
> ffff00000959b7a8 ffff000008ec0000
> [ 0.000000] fe60: ffffffffffffffff 0000000000000005
> ffff000008ccfe80 ffff000008b76984
> [ 0.000000] [<ffff000008b76984>] arm64_memblock_init+0x210/0x484
> [ 0.000000] [<ffff000008b7398c>] setup_arch+0x1b8/0x5f4
> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
> [ 0.000000] random: get_random_bytes called from
> print_oops_end_marker+0x50/0x6c with crng_init=0
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Reserving 4KB of memory at 0x2e7f0000 for elfcorehdr
> [ 0.000000] cma: Failed to reserve 512 MiB
> [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
> 0x0000000000010000 bytes below 0x0000000000000000.
> [ 0.000000]
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W
> ------------ 4.14.0+ #7
> [ 0.000000] Call trace:
> [ 0.000000] [<ffff000008088da8>] dump_backtrace+0x0/0x23c
> [ 0.000000] [<ffff000008089008>] show_stack+0x24/0x2c
> [ 0.000000] [<ffff0000087f647c>] dump_stack+0x84/0xa8
> [ 0.000000] [<ffff0000080cfd44>] panic+0x138/0x2a0
> [ 0.000000] [<ffff000008b95c88>] memblock_alloc_base+0x44/0x4c
> [ 0.000000] [<ffff000008b95cbc>] memblock_alloc+0x2c/0x38
> [ 0.000000] [<ffff000008b772dc>] early_pgtable_alloc+0x20/0x74
> [ 0.000000] [<ffff000008b7755c>] paging_init+0x28/0x544
> [ 0.000000] [<ffff000008b73990>] setup_arch+0x1bc/0x5f4
> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
> [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
> allocate 0x0000000000010000 bytes below 0x0000000000000000.
> [ 0.000000]
>
> I guess it is because of the 1G alignment requirement between the
> kernel image and the initrd and how we populate the holes between the
> kernel image, segments (including dtb) and the initrd from the
> kexec-tools.
>
> Akashi, any pointers on this will be helpful as well.
>
> Regards,
> Bhupesh
>
>
> >> >
> >> > Regards,
> >> > Bhupesh
> >> >
> >> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> > >> via a kernel command line parameter, "memmap=".
> >> > >>
> >> > _______________________________________________
> >> > kexec mailing list -- kexec at lists.fedoraproject.org
> >> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Keerthy @ 2017-12-19 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e215a5e3-f729-1de4-2837-24c4a0120114@ti.com>
On Monday 18 December 2017 06:25 PM, Keerthy wrote:
>
>
> On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:
>> Keerthy,
>>
>> On Tue, Dec 12, 2017 at 11:42:16AM +0530, Keerthy wrote:
>>> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
>>>
>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>> ---
>>>
>>> Changes in v4:
>>>
>>> * Switched to dev_get_platdata.
>>
>> Where do you expect dev.platform_data to be set? PWM driver is failing
>> with:
>> omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
>> omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>>
>> Which I fixed with patch bellow, to be able to test your patchset.
>
> Thanks! I will make the below patch part of my series.
>
>>
>> Also I'm running a bit out of time, so I'll send few clean up
>> patches and event capture code to get some feedback early.
>>
>> Regards,
>> ladis
>>
>> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
>> index 39be39e6a8dd..d3d8a49cae0d 100644
>> --- a/drivers/clocksource/timer-dm.c
>> +++ b/drivers/clocksource/timer-dm.c
>> @@ -773,6 +773,7 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
>> dev_err(dev, "%s: no platform data.\n", __func__);
>> return -ENODEV;
>> }
>> + dev->platform_data = pdata;
drivers/clocksource/timer-dm.c: In function 'omap_dm_timer_probe':
drivers/clocksource/timer-dm.c:744:21: warning: assignment discards
'const' qualifier from pointer target type
This cannot be done as we are assigning a const pointer to a non-const
pointer.
I will figure out a different way for this fix.
>>
>> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> if (unlikely(!irq)) {
>>
>>>
>>> Changes in v3:
>>>
>>> * Used of_find_platdata_by_node function to fetch platform
>>> data for timer node.
>>>
>>> drivers/pwm/pwm-omap-dmtimer.c | 39 ++++++++++++++++++++++-----------------
>>> 1 file changed, 22 insertions(+), 17 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] drivers: gpio: remove duplicate includes
From: Gregory Fong @ 2017-12-19 4:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513429012-8327-1-git-send-email-pravin.shedge4linux@gmail.com>
On Sat, Dec 16, 2017 at 4:56 AM, Pravin Shedge
<pravin.shedge4linux@gmail.com> wrote:
> These duplicate includes have been found with scripts/checkincludes.pl
> but they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219023935.GA17456@codeaurora.org>
On 12/18/17 8:39 PM, Stephen Boyd wrote:
> Ah I missed that the u16 array can't be iterated through. Any
> chance the ACPI tables can be changed to list pin ranges, like
> <33 3>, <90 2>, to indicate that pins 33, 34, 35 and pins 90, 91
> are available?
It's too late. Firmware is already shipping with the current layout.
Unfortunately, there's no good peer review process for DSDs that don't
have a DT equivalent.
> That would allow us to put that into the core
> pinctrl-msm.c file a little better and then only expose pins on
> the gpiochip when call gpiochip_add_pin_range(). If we want to
> support this in DT, I think we would have a DT property like
> available-gpios = <33 3>, <90 2>, <100 34> that we can then
> iterate through and add only these pins to the gpiochip. That's
> better than a bitmap in DT and is still compressed somewhat.
Keep in mind that all this ACPI junk is localized to pinctrl-qdf2xxx.
pinctrl-msm does not define any new data structures, it just reuses the
existing one. You can still define your DT properties any way you want
in your client drivers. pinctrl-qdf2xxx is specific to the Centriq chips.
> Without going all the way down into that path, here's my patch to
> make your patch smaller, but perhaps we can just look for the
> ACPI property or the DT property in the pinctrl-msm.c core and
> then add pin ranges directly. Then this ACPI driver doesn't
> really need to change besides for the ID update. We can expose
> all the pins and offsets, etc. from the hardware driver but cut
> out gpios in the core layer in a generic way.
Ok, let me review this. I don't think there's any gain in moving the
ACPI processing to pinctrl-msm, however.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* PROBLEM: Hard lockup on Armada-385 with mvebu-mbus driver
From: Joshua Scott @ 2017-12-19 4:07 UTC (permalink / raw)
To: linux-arm-kernel
Hard lockup on Armada-385 with mvebu-mbus driver.
Hi,
We've come across an issue where we get a hard lockup (no more console output, JTAG debugger unable to connect) after receiving CPU traffic from a Marvell switch-chip (connected via PCI). The issue usually occurs within a minute of beginning the traffic stream. The issue only occurs when both cores of the processor are enabled, switching to single-core, the issue is unreproducible.
Comparing the kernel we are using (4.4.6) to the one supplied by Marvell (where the issue does not occur), we were able to narrow the minimal change to fix the issue to the following:
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c43c3d2baf..9e6b94cdef 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -349,8 +349,6 @@ static int mvebu_mbus_setup_window(struct mvebu_mbus_state *mbus,
(attr << WIN_CTRL_ATTR_SHIFT) |
(target << WIN_CTRL_TGT_SHIFT) |
WIN_CTRL_ENABLE;
- if (mbus->hw_io_coherency)
- ctrl |= WIN_CTRL_SYNCBARRIER;
writel(base & WIN_BASE_LOW, addr + WIN_BASE_OFF);
writel(ctrl, addr + WIN_CTRL_OFF);
@@ -1082,10 +1080,6 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
mbus->soc->setup_cpu_target(mbus);
mvebu_mbus_setup_cpu_target_nooverlap(mbus);
- if (is_coherent)
- writel(UNIT_SYNC_BARRIER_ALL,
- mbus->mbuswins_base + UNIT_SYNC_BARRIER_OFF);
-
register_syscore_ops(&mvebu_mbus_syscore_ops);
return 0;
While we're not currently running the latest upstream kernel, it does appear that the offending lines above are still present in the latest upstream kernel. We're not yet sure exactly why this fixes the issue, but on our platform at least it does resolve the issue we were seeing.
The main purpose of this email is to get the ball rolling on having this fix upstreamed, and perhaps to hear back from anyone involved with this code.
Cheers,
Joshua Scott
Environment:
[root at awplus flash]# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 50.00
Features : half thumb fastmult vfp edsp vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1
processor : 1
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 50.00
Features : half thumb fastmult vfp edsp vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1
Hardware : Marvell Armada 380/385 (Device Tree)
Revision : 0000
Serial : 0000000000000000
[root at awplus flash]# cat /proc/modules
tipc 115327 248 - Live 0x7f0c3000
ip6_udp_tunnel 1679 1 tipc, Live 0x7f0bf000
udp_tunnel 2053 1 tipc, Live 0x7f0bb000
br_netfilter 12045 0 - Live 0x7f0b5000
sha256_generic 8941 0 - Live 0x7f0af000
jitterentropy_rng 5909 0 - Live 0x7f0aa000
echainiv 2007 0 - Live 0x7f0a6000
drbg 13108 0 - Live 0x7f09f000
platform_driver 98540 1 - Live 0x7f048000 (O)
ipifwd 239474 18 platform_driver,[permanent], Live 0x7f000000 (PO)
[root at awplus flash]# cat /proc/ioports
00001000-000fffff : PCI I/O
[root at awplus flash]# cat /proc/iomem
00000000-3fffffff : System RAM
00008000-00628aab : Kernel code
00666000-006b3087 : Kernel data
a0000000-dfffffff : PCI MEM
a0000000-a5ffffff : PCI Bus 0000:01
a0000000-a3ffffff : 0000:01:00.0
a0000000-a3ffffff : prestera
a4000000-a47fffff : 0000:01:00.0
a4000000-a47fffff : prestera
a4800000-a48fffff : 0000:01:00.0
a4800000-a48fffff : prestera
f1010410-f1010417 : /soc/devbus-cs1
f1010680-f10106cf : /soc/internal-regs/spi at 10680
f1011000-f101101f : /soc/internal-regs/i2c at 11000
f1012000-f101201f : serial
f1018000-f101801f : /soc/internal-regs/pinctrl at 18000
f1018100-f101813f : /soc/internal-regs/gpio at 18100
f1018140-f101817f : /soc/internal-regs/gpio at 18140
f1020704-f1020707 : /soc/internal-regs/watchdog at 20300
f1020800-f102080f : /soc/internal-regs/cpurst at 20800
f1020a00-f1020ccf : /soc/internal-regs/interrupt-controller at 20a00
f1021070-f10210c7 : /soc/internal-regs/interrupt-controller at 20a00
f1022000-f1022fff : /soc/internal-regs/pmsu at 22000
f1058000-f10584ff : /soc/internal-regs/usb at 58000
f1080000-f1081fff : /soc/pcie-controller/pcie at 1,0
f10d0000-f10d0053 : /soc/internal-regs/flash at d0000
f4800000-f487ffff : f4800000.nvs
[root at awplus flash]# lspci -vvv
00:01.0 Class 0604: Device 11ab:6820 (rev 04)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff [empty]
Memory behind bridge: a0000000-a5ffffff [size=96M]
Prefetchable memory behind bridge: 00000000-000fffff [size=1M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 0.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported ARIFwd-
AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
AtomicOpsCtl: ReqEn- EgressBlck-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
01:00.0 Class 0200: Device 11ab:c804
Subsystem: Device 11ab:11ab
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 101
Region 0: Memory at a4800000 (64-bit, prefetchable) [size=1M]
Region 2: Memory at a0000000 (64-bit, prefetchable) [size=64M]
Region 4: Memory@a4000000 (64-bit, prefetchable) [size=8M]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [60] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Kernel driver in use: ATL Marvell CPSS PCI
^ permalink raw reply related
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-19 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <615426d4-7c46-9671-87ef-790fb5733385@codeaurora.org>
On 12/18, Timur Tabi wrote:
> Stephen, any follow-up to this? I'd like to get these patches into
> 4.16 if at all possible. Thanks.
>
Ah I missed that the u16 array can't be iterated through. Any
chance the ACPI tables can be changed to list pin ranges, like
<33 3>, <90 2>, to indicate that pins 33, 34, 35 and pins 90, 91
are available? That would allow us to put that into the core
pinctrl-msm.c file a little better and then only expose pins on
the gpiochip when call gpiochip_add_pin_range(). If we want to
support this in DT, I think we would have a DT property like
available-gpios = <33 3>, <90 2>, <100 34> that we can then
iterate through and add only these pins to the gpiochip. That's
better than a bitmap in DT and is still compressed somewhat.
Without going all the way down into that path, here's my patch to
make your patch smaller, but perhaps we can just look for the
ACPI property or the DT property in the pinctrl-msm.c core and
then add pin ranges directly. Then this ACPI driver doesn't
really need to change besides for the ID update. We can expose
all the pins and offsets, etc. from the hardware driver but cut
out gpios in the core layer in a generic way.
---8<---
From: Timur Tabi <timur@codeaurora.org>
Newer versions of the firmware for the Qualcomm Datacenter Technologies
QDF2400 restricts access to a subset of the GPIOs on the TLMM. To
prevent older kernels from accidentally accessing the restricted GPIOs,
we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002,
and introduce a new property "gpios". This property is an array of
specific GPIOs that are accessible. When an older kernel boots on
newer (restricted) firmware, it will fail to probe.
To implement the sparse GPIO map, we register all of the GPIOs, but set
the pin count for the unavailable GPIOs to zero. The pinctrl-msm
driver will block those unavailable GPIOs from being accessed.
To allow newer kernels to support older firmware, the driver retains
support for QCOM8001.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 89 +++++++++++++++++++++++++++++-----
1 file changed, 77 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
index bb3ce5c3e18b..2ca2f40719b3 100644
--- a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
+++ b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
@@ -38,45 +38,107 @@ static struct msm_pinctrl_soc_data qdf2xxx_pinctrl;
/* maximum size of each gpio name (enough room for "gpioXXX" + null) */
#define NAME_SIZE 8
+enum {
+ QDF2XXX_V1,
+ QDF2XXX_V2,
+};
+
static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
{
+ const struct acpi_device_id *id;
struct pinctrl_pin_desc *pins;
struct msm_pingroup *groups;
char (*names)[NAME_SIZE];
- unsigned int i;
+ unsigned int i, j;
u32 num_gpios;
+ unsigned int avail_gpios; /* The number of GPIOs we support */
+ u16 *gpios = NULL; /* An array of supported GPIOs */
int ret;
/* Query the number of GPIOs from ACPI */
ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
if (ret < 0) {
- dev_warn(&pdev->dev, "missing num-gpios property\n");
+ dev_err(&pdev->dev, "missing 'num-gpios' property\n");
return ret;
}
-
if (!num_gpios || num_gpios > MAX_GPIOS) {
- dev_warn(&pdev->dev, "invalid num-gpios property\n");
+ dev_err(&pdev->dev, "invalid 'num-gpios' property\n");
return -ENODEV;
}
+ /*
+ * The QCOM8001 HID contains only the number of GPIOs, and assumes
+ * that all of them are available. avail_gpios is the same as num_gpios.
+ *
+ * The QCOM8002 HID introduces the 'gpios' DSD, which lists
+ * specific GPIOs that the driver is allowed to access.
+ *
+ * The make the common code simpler, in both cases we create an
+ * array of GPIOs that are accessible. So for QCOM8001, that would
+ * be all of the GPIOs.
+ */
+ id = acpi_match_device(pdev->dev.driver->acpi_match_table, &pdev->dev);
+
+ if (id->driver_data == QDF2XXX_V1) {
+ avail_gpios = num_gpios;
+ } else {
+ /* The number of GPIOs in the approved list */
+ ret = device_property_read_u16_array(&pdev->dev, "gpios",
+ NULL, 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "missing 'gpios' property\n");
+ return ret;
+ }
+ /*
+ * The number of available GPIOs should be non-zero, and no
+ * more than the total number of GPIOS.
+ */
+ if (!ret || ret > num_gpios) {
+ dev_err(&pdev->dev, "invalid 'gpios' property\n");
+ return -ENODEV;
+ }
+ avail_gpios = ret;
+
+ gpios = devm_kmalloc_array(&pdev->dev, avail_gpios,
+ sizeof(gpios[0]), GFP_KERNEL);
+ if (!gpios)
+ return -ENOMEM;
+
+ /* Assume the array of available GPIOs is sorted */
+ ret = device_property_read_u16_array(&pdev->dev, "gpios", gpios,
+ avail_gpios);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not read list of GPIOs\n");
+ return ret;
+ }
+ }
+
pins = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct pinctrl_pin_desc), GFP_KERNEL);
groups = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct msm_pingroup), GFP_KERNEL);
- names = devm_kcalloc(&pdev->dev, num_gpios, NAME_SIZE, GFP_KERNEL);
+ names = devm_kcalloc(&pdev->dev, avail_gpios, NAME_SIZE, GFP_KERNEL);
if (!pins || !groups || !names)
return -ENOMEM;
- for (i = 0; i < num_gpios; i++) {
- snprintf(names[i], NAME_SIZE, "gpio%u", i);
-
+ /*
+ * Initialize the array. GPIOs not listed in the 'gpios' bitmap
+ * still need a number, but nothing else.
+ */
+ for (i = 0, j = 0; i < num_gpios; i++) {
pins[i].number = i;
- pins[i].name = names[i];
+ groups[i].pins = &pins[i].number;
+
+ /* Only expose GPIOs that are available */
+ if (gpios && gpios[j] != i)
+ continue;
groups[i].npins = 1;
- groups[i].name = names[i];
- groups[i].pins = &pins[i].number;
+ snprintf(names[j], NAME_SIZE, "gpio%u", i);
+ pins[i].name = names[j];
+ groups[i].name = names[j];
+ j++;
groups[i].ctl_reg = 0x10000 * i;
groups[i].io_reg = 0x04 + 0x10000 * i;
@@ -100,6 +162,8 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
groups[i].intr_detection_width = 2;
}
+ devm_kfree(&pdev->dev, gpios);
+
qdf2xxx_pinctrl.pins = pins;
qdf2xxx_pinctrl.groups = groups;
qdf2xxx_pinctrl.npins = num_gpios;
@@ -110,7 +174,8 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
}
static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
- {"QCOM8001"},
+ {"QCOM8001", QDF2XXX_V1},
+ {"QCOM8002", QDF2XXX_V2},
{},
};
MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Wenyou.Yang at microchip.com @ 2017-12-19 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1641aa67-b05e-47e2-600c-70b77571b450@iki.fi>
Hi Sakari,
> -----Original Message-----
> From: Sakari Ailus [mailto:sakari.ailus at iki.fi]
> Sent: 2017?12?14? 4:06
> To: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Mauro Carvalho
> Chehab <mchehab@s-opensource.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>
> Cc: linux-kernel at vger.kernel.org; Nicolas Ferre - M43238
> <Nicolas.Ferre@microchip.com>; devicetree at vger.kernel.org; Jonathan Corbet
> <corbet@lwn.net>; Hans Verkuil <hverkuil@xs4all.nl>; linux-arm-
> kernel at lists.infradead.org; Linux Media Mailing List <linux-
> media at vger.kernel.org>; Songjun Wu <songjun.wu@microchip.com>
> Subject: Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
>
> Hi Wenyou,
>
> Wenyou Yang wrote:
> ...
> > +static int ov7740_start_streaming(struct ov7740 *ov7740) {
> > + int ret;
> > +
> > + if (ov7740->fmt) {
> > + ret = regmap_multi_reg_write(ov7740->regmap,
> > + ov7740->fmt->regs,
> > + ov7740->fmt->reg_num);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (ov7740->frmsize) {
> > + ret = regmap_multi_reg_write(ov7740->regmap,
> > + ov7740->frmsize->regs,
> > + ov7740->frmsize->reg_num);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return __v4l2_ctrl_handler_setup(ov7740->subdev.ctrl_handler);
>
> I believe you're still setting the controls after starting streaming.
Yes, it sees it does so.
The OV7740 sensor generates the stream pixel data at the constant frame rate, no such start or stop control.
>
> --
> Sakari Ailus
> sakari.ailus at iki.fi
Wenyou Yang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx7d-sdb.dtb
Type: application/octet-stream
Size: 46918 bytes
Desc: imx7d-sdb.dtb
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171219/361b8cf3/attachment-0001.obj>
^ permalink raw reply
* [PATCH V4] ACPI / GED: unregister interrupts during shutdown
From: Rafael J. Wysocki @ 2017-12-19 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513125448-6509-1-git-send-email-okaya@codeaurora.org>
On Wed, Dec 13, 2017 at 1:37 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Some GED interrupts could be pending by the time we are doing a reboot.
>
> Even though GED driver uses devm_request_irq() to register the interrupt
> handler, the handler is not being freed on time during a shutdown since
> the driver is missing a shutdown callback.
>
> If the ACPI handler is no longer available, this causes an interrupt
> storm and delays shutdown.
>
> 1. Don't use devm family of functions for IRQ registration/free
> 2. Keep track of the events since free_irq() requires the dev_id parameter
> passed into the request_irq() function.
> 3. Call free_irq() on both remove and shutdown explicitly.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Applied, thanks!
^ permalink raw reply
* [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Stephen Boyd @ 2017-12-19 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b92fd3bd-c61a-ae58-49ef-8727af065ec1@gmail.com>
On 12/14, Matthias Brugger wrote:
> Hi Stephen, Michael,
>
> On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> > The ethsys registers a reset controller, so we need to specify a
> > reset cell. This patch fixes the documentation.
> >
> > Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> > ---
> > Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > index 7aa3fa167668..6cc7840ff37a 100644
> > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > @@ -20,4 +20,5 @@ ethsys: clock-controller at 1b000000 {
> > compatible = "mediatek,mt2701-ethsys", "syscon";
> > reg = <0 0x1b000000 0 0x1000>;
> > #clock-cells = <1>;
> > + #reset-cells = <1>;
> > };
> >
>
> Will you take this patch through the clk tree, or shall I take it through my SoC
> tree?
>
It's resets, we are clk maintainers. I'm clkfused.
You can take it, along with my
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
if you like/expect conflicts.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] [v2] ARM: B15: fix unused label warnings
From: Florian Fainelli @ 2017-12-19 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218165307.1472231-1-arnd@arndb.de>
On 12/18/2017 08:52 AM, Arnd Bergmann wrote:
> The new conditionally compiled code leaves some labels and one
> variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
> are disabled:
>
> arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
> arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
> out_unmap:
> ^~~~~~~~~
> arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
> out_cpu_dead:
> ^~~~~~~~~~~~
> At top level:
> arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
>
> This replaces the existing #ifdef conditionals with IS_ENABLED()
> checks that let the compiler figure out for itself which code to
> drop.
>
> Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks Arnd!
--
Florian
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ca3b4a6-90b9-0481-beb8-29a95c86f07c@codeaurora.org>
Stephen, any follow-up to this? I'd like to get these patches into 4.16
if at all possible. Thanks.
On 12/13/17 5:09 PM, Timur Tabi wrote:
> On 12/13/2017 05:01 PM, Stephen Boyd wrote:
>> Given that we have MAX_GPIOS, it would be better to declare a
>> bitmap of available gpios of that size on the stack and then
>> iterate through the bitmap and set bits for the available ones.
>> In the QCOM8001 case, that would be setting all bits up to
>> num_gpios, and in the QCOM8002 case it would be iterating through
>> the list of gpios from the DSD property and setting the bit for
>> that gpio number.? This avoids explicitly allocating a list of
>> numbers that is freed almost immediately. Instead we just stack
>> 256 / sizeof(unsigned long) words and set bits.
>
> I'm not sure I understand.? The only think I'm allocating temporarily is
> the 'gpios' array, which is an array of shorts.? Each element stores the
> gpio number.? It's not a bit array, so "256 / sizeof(unsigned long)"
> doesn't apply.? I need that array to read the DSD.? You can't iterate
> through an DSD property without reading it completely first.
>
>> Hopefully we could lift the same logic into the core pinctrl msm
>> driver for usage on non-ACPI systems.
>
> There is no new memory allocation being done in pinctrl-msm, so I don't
> understand this either.
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq
From: Brian Norris @ 2017-12-19 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <599CDB37.3070307@rock-chips.com>
Hi Jeffy, Tony,
On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote:
> Hi Tony,
>
> On 08/23/2017 01:26 AM, Tony Lindgren wrote:
> >OK, let's fix any wakeriq ordering issues to make it more
> >usable. Sounds like in your case the wakeirq needs to be enabled
> >late and disabled early, while in my test cases I can keep it
> >enabled basically any time.
>
> yes, in my case it's a level triggered irq, which needs to be
> disabled when receive it(by irq_pm_check_wakeup(my hack) or inside
> of the custom irq handler)
>
>
> and for eage irq, maybe we should enable it right after(or before)
> the driver activate wake function(for example activate WOWLAN or
> WOLAN), otherwise would it be possible to miss some irqs(triggered
> before we actually enable the wake irq)?
Did this problem ever get resolved? To be clear, I believe the problem
at hand is:
(a) in suspend/resume (not runtime PM; we may not even have runtime PM
support for most PCI devices)
(b) using a level-triggered signal (PCI WAKE# is active low, and it's
nice to avoid certain races by treating it as level-triggered)
And with the current wakeirq code (and the latest version of Jeffy's
patch series, IIUC), I believe the above case can still trigger an
interrupt storm of sorts (it's not usually unrecoverably-stormy, since
it's a threaded IRQ, and we make "enough" progress).
I don't see how "ordering" can really resolve this problem, unless the
ordering is configured such that the interrupt handler never runs (e.g.,
we disable the IRQ before we get out of any "noirq" phase).
Options I can think of:
(1) implement runtime PM callbacks for all PCI devices, where we clear
any PME status and ensure WAKE# stops asserting [1]
(2) synchronize a device's resume() with the dedicated wake IRQ
(3) skip using the dedicated wake IRQ infrastructure and write our own
interrupt handler for this PCI/PM function
Option (1) seems pretty strange; we don't actually want to manage these
devices with runtime PM.
Option (2) could work, but it would probably require sharing more of the
core suspend/resume internals between
drivers/base/power/{wakeirq,main}.c, which may not be desirable. Among
other problems, that seems more fragile.
Option (3) is easy enough, and we already did that once for the first
pass at poorly implementing this WAKE# logic within the mwifiex driver
:)
> >If this is for suspend/resume, You could just register the
> >wakeirq on suspend and then remove it on resume. We do have at
> >least network drivers doing device_init_wakeup(dev, true) and
> >device_init_wakeup(dev, false) as needed for WOL, see for example
> >bfin_mac_ethtool_setwol().
I don't see how that would be good enough. You still have a window of
time while the driver hasn't finished resuming, in which the interrupt
handler might trigger many times.
Brian
[1] Then we also need to fixup handle_threaded_wake_irq(). Currently it
will not even try to resume the device:
/* Maybe abort suspend? */
if (irqd_is_wakeup_set(irq_get_irq_data(irq))) {
pm_wakeup_event(wirq->dev, 0);
return IRQ_HANDLED; <--- we exit here
}
/* We don't want RPM_ASYNC or RPM_NOWAIT here */
res = pm_runtime_resume(wirq->dev);
...
^ permalink raw reply
* [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-19 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218203324.ftyqrgjawkujvhmn@tarshish>
Hello Baruch,
On Mon, 18 Dec 2017 22:33:24 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > From: Baruch Siach <baruch@tkos.co.il>
> >
> > Add compatible strings for AP806 and CP110 that are part of the
> > Armada 8k/7k line of SoCs.
> >
> > Add a note on the differences in the size of the control area in
> > different bindings. This is an existing difference between the
> > Armada 375 binding and the other boards already supported. The new
> > AP806 and CP110 bindings are similar to the existing Armada 375 in
> > this regard.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > [<miquel.raynal@free-electrons.com>: reword, additional details]
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> > .../devicetree/bindings/thermal/armada-thermal.txt | 24
> > +++++++++++++++++----- 1 file changed, 19 insertions(+), 5
> > deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > index 24aacf8948c5..9b7b2c03cc6f 100644 ---
> > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt +++
> > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt @@
> > -7,17 +7,31 @@ Required properties: marvell,armada375-thermal
> > marvell,armada380-thermal marvell,armadaxp-thermal
> > + marvell,armada-ap806-thermal
> > + marvell,armada-cp110-thermal
> >
> > - reg: Device's register space.
> > Two entries are expected, see the examples below.
> > - The first one is required for the sensor register;
> > - the second one is required for the control register
> > - to be used for sensor initialization (a.k.a.
> > calibration).
> > + The first one points to the status register (4B).
> > + The second one points to the control registers
> > (8B).
> > + Note: with legacy bindings, the second entry
> > pointed
> > + only to the so called "control MSB" ("control 1"),
> > was
> > + 4B wide and did not let the possibility to reach
> > the
> > + "control LSB" ("control 0") register. This is only
> > + allowed for compatibility reasons in Armada
> > + 370/375/38x/XP DT nodes.
>
> "allowed" is not the right term, IMO. Legacy compatibles MUST point
> to the MSB control register to preserve compatibility with existing
> DTs.
>
> The original patch had a list of legacy and non-legacy compatibles. I
> think we need to keep them.
Maybe I should reword this paragraph because we both agree on the
meaning:
"
Note: Legacy bindings are only supported with Armada 370/375/38x/XP
compatibles. The second memory resource entry only points to
"control MSB/control 1", is 4 bytes wide and is preventing any access
to "control LSB/control 0".
"
Does this sounds better to you?
Thank you,
Miqu?l
>
> baruch
>
> > -Example:
> > +Examples:
> >
> > + /* Legacy bindings */
> > thermal at d0018300 {
> > compatible = "marvell,armada370-thermal";
> > - reg = <0xd0018300 0x4
> > + reg = <0xd0018300 0x4
> > 0xd0018304 0x4>;
> > };
> > +
> > + ap_thermal: thermal at 6f8084 {
> > + compatible = "marvell,armada-ap806-thermal";
> > + reg = <0x6f808C 0x4>,
> > + <0x6f8084 0x8>;
> > + };
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Miquel RAYNAL @ 2017-12-19 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218203542.msnswjqeyuudyusz@tarshish>
Hello Baruch,
On Mon, 18 Dec 2017 22:35:42 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> > Bindings were incomplete for a long time by only exposing one of
> > the two available control registers. To ease the migration to the
> > full bindings (already in use for the Armada 375 SoC), rename the
> > pointers for clarification. This way, it will only be needed to add
> > another pointer to access the other control register when the time
> > comes.
> >
> > This avoids dangerous situations where the offset 0 of the control
> > area can be either one register or the other depending on the
> > bindings used. After this change, device trees of other SoCs could
> > be migrated to the "full" bindings if they may benefit from
> > features from the unaccessible register, without any change in the
> > driver.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > ---
>
> [...]
>
> > + /*
> > + * Legacy DT bindings only described "control1" register
> > (also referred
> > + * as "control MSB" on old documentation). New bindings
> > cover
> > + * "control0/control LSB" and "control1/control MSB"
> > registers within
> > + * the same resource, which is then of size 8 instead of 4.
> > + */
> > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > + /* ->control0 unavailable in this configuration */
> > + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > + } else {
> > + priv->control0 = control + CONTROL0_OFFSET;
> > + priv->control1 = control + CONTROL1_OFFSET;
> > + }
>
> The needs_control0 field that you mentioned in the cover page is
> missing here.
Yes, at this point nobody actually *needs* control0 so the limitation
is added with the patch that introduce ap806 support as it is the first
compatible that needs both control0 and control1 to work correctly.
Does this bother you?
Thanks,
Miqu?l
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 06/12] thermal: armada: Add support for Armada AP806
From: Miquel RAYNAL @ 2017-12-19 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3m0hvik.fsf@free-electrons.com>
Hello Gregory,
Thank you for reviewing the series.
On Mon, 18 Dec 2017 17:05:07 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Miquel,
>
> On lun., d?c. 18 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
>
> > From: Baruch Siach <baruch@tkos.co.il>
> >
> > The AP806 component is integrated in the Armada 8K and 7K lines of
> > processors.
> >
> > The thermal sensor sample field on the status register is a signed
> > value. Extend armada_get_temp() and the driver structure to handle
> > signed values.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > [<miquel.raynal@free-electrons.com>: Changes when applying over the
> > previous patches, including the register names changes, also
> > switched the coefficients values to s64 instead of unsigned long to
> > deal with negative values and used do_div instead of the
> > traditionnal '/'] Signed-off-by: Miquel Raynal
> > <miquel.raynal@free-electrons.com>
>
> I am just a little concerned by the fac that the value pass though
> get_temp() is an int and now the intermediate calculation are in
> s64. But maybe I'm too picky for this,
I know, but I thought having a temporary s64 variable and casting it
when setting *temp would have been exactly the same so I decided to let
it that way, but if you have something in mind (maybe a check that a
cast into a smaller type is valid? or limiting the temperature to
some boundaries?) I can update.
Thanks,
Miqu?l
>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Gregory
>
>
> > ---
> > drivers/thermal/armada_thermal.c | 80
> > ++++++++++++++++++++++++++++++++-------- 1 file changed, 65
> > insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 198485fa77f2..ec29ea76b818
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -47,6 +47,11 @@
> > #define CONTROL0_OFFSET 0x0
> > #define CONTROL1_OFFSET 0x4
> >
> > +/* TSEN refers to the temperature sensors within the AP */
> > +#define CONTROL0_TSEN_START BIT(0)
> > +#define CONTROL0_TSEN_RESET BIT(1)
> > +#define CONTROL0_TSEN_ENABLE BIT(2)
> > +
> > struct armada_thermal_data;
> >
> > /* Marvell EBU Thermal Sensor Dev Structure */
> > @@ -66,15 +71,17 @@ struct armada_thermal_data {
> > bool (*is_valid)(struct armada_thermal_priv *);
> >
> > /* Formula coeficients: temp = (b - m * reg) / div */
> > - unsigned long coef_b;
> > - unsigned long coef_m;
> > - unsigned long coef_div;
> > + s64 coef_b;
> > + s64 coef_m;
> > + u32 coef_div;
> > bool inverted;
> > + bool signed_sample;
> >
> > /* Register shift and mask to access the sensor
> > temperature */ unsigned int temp_shift;
> > unsigned int temp_mask;
> > u32 is_valid_bit;
> > + bool needs_control0;
> > };
> >
> > static void armadaxp_init_sensor(struct platform_device *pdev,
> > @@ -154,6 +161,18 @@ static void armada380_init_sensor(struct
> > platform_device *pdev, }
> > }
> >
> > +static void armada_ap806_init_sensor(struct platform_device *pdev,
> > + struct armada_thermal_priv
> > *priv) +{
> > + u32 reg;
> > +
> > + reg = readl_relaxed(priv->control0);
> > + reg &= ~CONTROL0_TSEN_RESET;
> > + reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> > + writel(reg, priv->control0);
> > + msleep(10);
> > +}
> > +
> > static bool armada_is_valid(struct armada_thermal_priv *priv)
> > {
> > u32 reg = readl_relaxed(priv->status);
> > @@ -165,8 +184,8 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> > {
> > struct armada_thermal_priv *priv = thermal->devdata;
> > - unsigned long reg;
> > - unsigned long m, b, div;
> > + u32 reg, div;
> > + s64 sample, b, m;
> >
> > /* Valid check */
> > if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> > @@ -177,6 +196,11 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal,
> > reg = readl_relaxed(priv->status);
> > reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask;
> > + if (priv->data->signed_sample)
> > + /* The most significant bit is the sign bit */
> > + sample = sign_extend32(reg,
> > fls(priv->data->temp_mask) - 1);
> > + else
> > + sample = reg;
> >
> > /* Get formula coeficients */
> > b = priv->data->coef_b;
> > @@ -184,9 +208,12 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, div = priv->data->coef_div;
> >
> > if (priv->data->inverted)
> > - *temp = ((m * reg) - b) / div;
> > + *temp = (m * sample) - b;
> > else
> > - *temp = (b - (m * reg)) / div;
> > + *temp = b - (m * sample);
> > +
> > + do_div(*temp, div);
> > +
> > return 0;
> > }
> >
> > @@ -198,8 +225,8 @@ static const struct armada_thermal_data
> > armadaxp_data = { .init_sensor = armadaxp_init_sensor,
> > .temp_shift = 10,
> > .temp_mask = 0x1ff,
> > - .coef_b = 3153000000UL,
> > - .coef_m = 10000000UL,
> > + .coef_b = 3153000000ULL,
> > + .coef_m = 10000000ULL,
> > .coef_div = 13825,
> > };
> >
> > @@ -209,8 +236,8 @@ static const struct armada_thermal_data
> > armada370_data = { .is_valid_bit = BIT(9),
> > .temp_shift = 10,
> > .temp_mask = 0x1ff,
> > - .coef_b = 3153000000UL,
> > - .coef_m = 10000000UL,
> > + .coef_b = 3153000000ULL,
> > + .coef_m = 10000000ULL,
> > .coef_div = 13825,
> > };
> >
> > @@ -220,8 +247,8 @@ static const struct armada_thermal_data
> > armada375_data = { .is_valid_bit = BIT(10),
> > .temp_shift = 0,
> > .temp_mask = 0x1ff,
> > - .coef_b = 3171900000UL,
> > - .coef_m = 10000000UL,
> > + .coef_b = 3171900000ULL,
> > + .coef_m = 10000000ULL,
> > .coef_div = 13616,
> > };
> >
> > @@ -231,12 +258,26 @@ static const struct armada_thermal_data
> > armada380_data = { .is_valid_bit = BIT(10),
> > .temp_shift = 0,
> > .temp_mask = 0x3ff,
> > - .coef_b = 1172499100UL,
> > - .coef_m = 2000096UL,
> > + .coef_b = 1172499100ULL,
> > + .coef_m = 2000096ULL,
> > .coef_div = 4201,
> > .inverted = true,
> > };
> >
> > +static const struct armada_thermal_data armada_ap806_data = {
> > + .is_valid = armada_is_valid,
> > + .init_sensor = armada_ap806_init_sensor,
> > + .is_valid_bit = BIT(16),
> > + .temp_shift = 0,
> > + .temp_mask = 0x3ff,
> > + .coef_b = -150000LL,
> > + .coef_m = 423ULL,
> > + .coef_div = 1,
> > + .inverted = true,
> > + .signed_sample = true,
> > + .needs_control0 = true,
> > +};
> > +
> > static const struct of_device_id armada_thermal_id_table[] = {
> > {
> > .compatible = "marvell,armadaxp-thermal",
> > @@ -255,6 +296,10 @@ static const struct of_device_id
> > armada_thermal_id_table[] = { .data = &armada380_data,
> > },
> > {
> > + .compatible = "marvell,armada-ap806-thermal",
> > + .data = &armada_ap806_data,
> > + },
> > + {
> > /* sentinel */
> > },
> > };
> > @@ -296,6 +341,11 @@ static int armada_thermal_probe(struct
> > platform_device *pdev) */
> > if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > /* ->control0 unavailable in this configuration */
> > + if (priv->data->needs_control0) {
> > + dev_err(&pdev->dev, "No access to control0
> > register\n");
> > + return -EINVAL;
> > + }
> > +
> > priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > } else {
> > priv->control0 = control + CONTROL0_OFFSET;
> > --
> > 2.11.0
> >
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Rafael J. Wysocki @ 2017-12-19 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abe0efc0-6dfc-e9b0-c535-aa1a48bf1a6b@ti.com>
On Mon, Dec 18, 2017 at 8:25 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Rafael,
> On 12/16/2017 04:52 AM, Rafael J. Wysocki wrote:
>> On Fri, Dec 15, 2017 at 3:29 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>> On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>> Document the devicetree bindings that describe Texas Instruments
>>>> opp-supply which allow a platform to describe multiple regulators and
>>>> additional information, such as registers containing data needed to
>>>> program aforementioned regulators.
>>>>
>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>
>>> I need an ACK from Rob on this one.
>>
>> Actually, how this (and the next patch) is related to the [1-2/4]?
>>
>
> The main goal of this series is to add support for scaling the multiple
> regulators needed for the CPU on these TI platforms. The OPP core supports
> multiple regulators but only to the point that it can associate a list of
> regulators to a device. It still by default only scales the normal vdd regulator
> when doing a rate transition. Because of this, we must define our own method of
> doing rate transitions to take the references to our regulators held in the OPP
> core and scale them in the proper sequence depending on what the platform needs.
>
> So to describe the purpose of each patch and their relation to each other:
>
> Patch 1: We must be able to defer the ti-cpufreq driver now that we look for
> regulators during probe as they likely won't be ready when we probe.
>
> Patch 2: Tell the OPP core about regulators needed for TI CPUFreq operation
> using the OPP core. This doesn't actually do anything besides place them in a
> list at this point because the OPP core can't know how TI platforms needs them
> scaled in relation to each other. Placing the regulator definition in ti-cpufreq
> driver ensures they are registered with opp core before cpufreq-dt probes (which
> is triggered at the end of ti-cpufreq probe) and actually makes the opp core get
> the regulators.
>
> Patch 3: Binding doc for patch 4 driver.
>
> Patch 4: TI OPP supply driver which understands how to actually make use of the
> two regulators that the OPP core now has a reference to. This overrides the
> standard opp_set_rate function to let us scale frequency and voltage as needed
> for TI platforms.
Thanks for the explanation, I've applied the series.
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Miquel RAYNAL @ 2017-12-19 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218215217.GA17755@1wt.eu>
Hi Willy,
On Mon, 18 Dec 2017 22:52:17 +0100
Willy Tarreau <w@1wt.eu> wrote:
> Hi Miquel,
>
> On Mon, Dec 18, 2017 at 11:22:08AM +0100, Miquel RAYNAL wrote:
> > I fixed two problems happening during read/write of 2kiB page NAND
> > chips, I am quite confident this would solve the issues you report
> > here. Could you please give it a try?
>
> So I just tested right now, and good news, it now works pretty fine
> here, and my jffs2 properly mounted (without requiring Boris' fix
> for oob)
Great! Thanks for testing.
Boris' fix wouldn't apply anyway as it was written for pxa3xx_nand.c
and here you are using marvell_nand.c and the code is really different.
>
> # dmesg|grep -i nand
> [ 0.770395] nand: device found, Manufacturer ID: 0x01, Chip ID:
> 0xf1 [ 0.775474] nand: AMD/Spansion S34ML01G2
> [ 0.778103] nand: 128 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64 [ 0.794080] 10 ofpart partitions found on MTD
> device pxa3xx_nand-0 [ 0.798975] Creating 10 MTD partitions on
> "pxa3xx_nand-0": [ 3.245034] jffs2: version 2.2. (NAND) (SUMMARY)
> \xffffffc2\xffffffa9 2001-2006 Red Hat, Inc.
>
> I was first surprized seeing this "pxa3xx_nand-0" still appearing
> until I realized that it's how it's called in the device tree :-)
That is right, but if you create a DTS for your own board feel free to
change it, this is just a default name. Giving it some meaning (like
"main-storage" or "backup-storage") is how you could use this label.
Thanks again for your help, reviews or tested-by's are welcome for this
driver ;)
Miqu?l
^ permalink raw reply
* [PATCH v2] rcutorture: Add basic ARM64 support to run scripts
From: Paul E. McKenney @ 2017-12-18 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513070365-13436-1-git-send-email-lianglihao@huawei.com>
On Tue, Dec 12, 2017 at 05:19:25PM +0800, lianglihao at huawei.com wrote:
> From: Lihao Liang <lianglihao@huawei.com>
>
> This commit adds support of the qemu command qemu-system-aarch64
> to rcutorture.
>
> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
Queued for further review and testing, thank you!
(This one has been on my list for quite some time.)
Thanx, Paul
> ---
> This commit is against RCU's git tree rcu/dev branch
>
> commit 505b61b2ec1d ("EXP: rcu: Add debugging info to other assertion")
>
> Note that the max CPUs supported by qemu machine 'virt' is 8 so the value of
> CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
>
> tools/testing/selftests/rcutorture/bin/functions.sh | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
> index 07a1377..0541d10 100644
> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
> @@ -136,6 +136,9 @@ identify_boot_image () {
> qemu-system-x86_64|qemu-system-i386)
> echo arch/x86/boot/bzImage
> ;;
> + qemu-system-aarch64)
> + echo arch/arm64/boot/Image
> + ;;
> *)
> echo vmlinux
> ;;
> @@ -158,6 +161,9 @@ identify_qemu () {
> elif echo $u | grep -q "Intel 80386"
> then
> echo qemu-system-i386
> + elif echo $u | grep -q aarch64
> + then
> + echo qemu-system-aarch64
> elif uname -a | grep -q ppc64
> then
> echo qemu-system-ppc64
> @@ -176,16 +182,20 @@ identify_qemu () {
> # Output arguments for the qemu "-append" string based on CPU type
> # and the TORTURE_QEMU_INTERACTIVE environment variable.
> identify_qemu_append () {
> + local console=ttyS0
> case "$1" in
> qemu-system-x86_64|qemu-system-i386)
> echo noapic selinux=0 initcall_debug debug
> ;;
> + qemu-system-aarch64)
> + console=ttyAMA0
> + ;;
> esac
> if test -n "$TORTURE_QEMU_INTERACTIVE"
> then
> echo root=/dev/sda
> else
> - echo console=ttyS0
> + echo console=$console
> fi
> }
>
> @@ -197,6 +207,9 @@ identify_qemu_args () {
> case "$1" in
> qemu-system-x86_64|qemu-system-i386)
> ;;
> + qemu-system-aarch64)
> + echo -M virt -cpu host
> + ;;
> qemu-system-ppc64)
> echo -enable-kvm -M pseries -nodefaults
> echo -device spapr-vscsi
> @@ -254,7 +267,7 @@ specify_qemu_cpus () {
> echo $2
> else
> case "$1" in
> - qemu-system-x86_64|qemu-system-i386)
> + qemu-system-x86_64|qemu-system-i386|qemu-system-aarch64)
> echo $2 -smp $3
> ;;
> qemu-system-ppc64)
> --
> 2.7.4
>
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-18 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218111844.xyed3bel2wl6el3p@fireball>
On Mon, Dec 18, 2017 at 4:48 PM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> Bhupesh,
>
> On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote:
>> On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro
>> <takahiro.akashi@linaro.org> wrote:
>> > On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wrote:
>> >> kexec at fedoraproject... is for Fedora kexec scripts discussion, changed it
>> >> to kexec at lists.infradead.org
>> >>
>> >> Also add linux-acpi list
>> >
>> > Thank you.
>> >
>> >> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> >> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
>> >> > <ard.biesheuvel@linaro.org> wrote:
>> >> > > On 15 December 2017 at 09:59, AKASHI Takahiro
>> >> > > <takahiro.akashi@linaro.org> wrote:
>> >> > >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>> >> > >>> On 13 December 2017 at 12:16, AKASHI Takahiro
>> >> > >>> <takahiro.akashi@linaro.org> wrote:
>> >> > >>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>> >> > >>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
>> >> > >>> >> <takahiro.akashi@linaro.org> wrote:
>> >> > >>> >> > Bhupesh, Ard,
>> >> > >>> >> >
>> >> > >>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>> >> > >>> >> >> Hi Ard, Akashi
>> >> > >>> >> >>
>> >> > >>> >> > (snip)
>> >> > >>> >> >
>> >> > >>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>> >> > >>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>> >> > >>> >> >> identify its own usable memory and exclude, at its boot time, any
>> >> > >>> >> >> other memory areas that are part of the panicked kernel's memory.
>> >> > >>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>> >> > >>> >> >> , for details)
>> >> > >>> >> >
>> >> > >>> >> > Right.
>> >> > >>> >> >
>> >> > >>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>> >> > >>> >> >> with the crashkernel memory range:
>> >> > >>> >> >>
>> >> > >>> >> >> /* add linux,usable-memory-range */
>> >> > >>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>> >> > >>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>> >> > >>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>> >> > >>> >> >> address_cells, size_cells);
>> >> > >>> >> >>
>> >> > >>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>> >> > >>> >> >> , for details)
>> >> > >>> >> >>
>> >> > >>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>> >> > >>> >> >> they are marked as System RAM or as RESERVED. As,
>> >> > >>> >> >> 'linux,usable-memory-range' dt node is patched up only with
>> >> > >>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>> >> > >>> >> >>
>> >> > >>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
>> >> > >>> >> >> ACPI memory and crashes while trying to access the same:
>> >> > >>> >> >>
>> >> > >>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>> >> > >>> >> >> -r`.img --reuse-cmdline -d
>> >> > >>> >> >>
>> >> > >>> >> >> [snip..]
>> >> > >>> >> >>
>> >> > >>> >> >> Reserved memory range
>> >> > >>> >> >> 000000000e800000-000000002e7fffff (0)
>> >> > >>> >> >>
>> >> > >>> >> >> Coredump memory ranges
>> >> > >>> >> >> 0000000000000000-000000000e7fffff (0)
>> >> > >>> >> >> 000000002e800000-000000003961ffff (0)
>> >> > >>> >> >> 0000000039d40000-000000003ed2ffff (0)
>> >> > >>> >> >> 000000003ed60000-000000003fbfffff (0)
>> >> > >>> >> >> 0000001040000000-0000001ffbffffff (0)
>> >> > >>> >> >> 0000002000000000-0000002ffbffffff (0)
>> >> > >>> >> >> 0000009000000000-0000009ffbffffff (0)
>> >> > >>> >> >> 000000a000000000-000000affbffffff (0)
>> >> > >>> >> >>
>> >> > >>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>> >> > >>> >> >> memory cap'ing passed to the crash kernel inside
>> >> > >>> >> >> 'arch/arm64/mm/init.c' (see below):
>> >> > >>> >> >>
>> >> > >>> >> >> static void __init fdt_enforce_memory_region(void)
>> >> > >>> >> >> {
>> >> > >>> >> >> struct memblock_region reg = {
>> >> > >>> >> >> .size = 0,
>> >> > >>> >> >> };
>> >> > >>> >> >>
>> >> > >>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>> >> > >>> >> >>
>> >> > >>> >> >> if (reg.size)
>> >> > >>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>> >> > >>> >> >> comment this out */
>> >> > >>> >> >> }
>> >> > >>> >> >
>> >> > >>> >> > Please just don't do that. It can cause a fatal damage on
>> >> > >>> >> > memory contents of the *crashed* kernel.
>> >> > >>> >> >
>> >> > >>> >> >> 5). Both the above temporary solutions fix the problem.
>> >> > >>> >> >>
>> >> > >>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
>> >> > >>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>> >> > >>> >> >> fail.
>> >> > >>> >> >>
>> >> > >>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>> >> > >>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>> >> > >>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>> >> > >>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>> >> > >>> >> >> dt node 'linux,usable-memory-range'
>> >> > >>> >> >
>> >> > >>> >> > I still don't understand why we need to carry over the information
>> >> > >>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>> >> > >>> >> > such regions are free to be reused by the kernel after some point of
>> >> > >>> >> > initialization. Why does crash dump kernel need to know about them?
>> >> > >>> >> >
>> >> > >>> >>
>> >> > >>> >> Not really. According to the UEFI spec, they can be reclaimed after
>> >> > >>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>> >> > >>> >> no longer needs them. Of course, in order to be able to boot a kexec
>> >> > >>> >> kernel, those regions needs to be preserved, which is why they are
>> >> > >>> >> memblock_reserve()'d now.
>> >> > >>> >
>> >> > >>> > For my better understandings, who is actually accessing such regions
>> >> > >>> > during boot time, uefi itself or efistub?
>> >> > >>> >
>> >> > >>>
>> >> > >>> No, only the kernel. This is where the ACPI tables are stored. For
>> >> > >>> instance, on QEMU we have
>> >> > >>>
>> >> > >>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>> >> > >>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>> >> > >>> 01000013)
>> >> > >>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>> >> > >>> BXPC 00000001)
>> >> > >>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>> >> > >>> BXPC 00000001)
>> >> > >>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>> >> > >>> BXPC 00000001)
>> >> > >>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>> >> > >>> BXPC 00000001)
>> >> > >>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>> >> > >>> BXPC 00000001)
>> >> > >>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>> >> > >>> BXPC 00000001)
>> >> > >>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>> >> > >>> BXPC 00000001)
>> >> > >>>
>> >> > >>> covered by
>> >> > >>>
>> >> > >>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>> >> > >>> ...
>> >> > >>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>> >> > >>
>> >> > >> OK. I mistakenly understood those regions could be freed after exiting
>> >> > >> UEFI boot services.
>> >> > >>
>> >> > >>>
>> >> > >>> >> So it seems that kexec does not honour the memblock_reserve() table
>> >> > >>> >> when booting the next kernel.
>> >> > >>> >
>> >> > >>> > not really.
>> >> > >>> >
>> >> > >>> >> > (In other words, can or should we skip some part of ACPI-related init code
>> >> > >>> >> > on crash dump kernel?)
>> >> > >>> >> >
>> >> > >>> >>
>> >> > >>> >> I don't think so. And the change to the handling of ACPI reclaim
>> >> > >>> >> regions only revealed the bug, not created it (given that other
>> >> > >>> >> memblock_reserve regions may be affected as well)
>> >> > >>> >
>> >> > >>> > As whether we should honor such reserved regions over kexec'ing
>> >> > >>> > depends on each one's specific nature, we will have to take care one-by-one.
>> >> > >>> > As a matter of fact, no information about "reserved" memblocks is
>> >> > >>> > exposed to user space (via proc/iomem).
>> >> > >>> >
>> >> > >>>
>> >> > >>> That is why I suggested (somewhere in this thread?) to not expose them
>> >> > >>> as 'System RAM'. Do you think that could solve this?
>> >> > >>
>> >> > >> Memblock-reserv'ing them is necessary to prevent their corruption and
>> >> > >> marking them under another name in /proc/iomem would also be good in order
>> >> > >> not to allocate them as part of crash kernel's memory.
>> >> > >>
>> >> > >
>> >> > > I agree. However, this may not be entirely trivial, since iterating
>> >> > > over the memblock_reserved table and creating iomem entries may result
>> >> > > in collisions.
>> >> >
>> >> > I found a method (using the patch I shared earlier in this thread) to mark these
>> >> > entries as 'ACPI reclaim memory' ranges rather than System RAM or
>> >> > reserved regions.
>> >> >
>> >> > >> But I'm not still convinced that we should export them in useable-
>> >> > >> memory-range to crash dump kernel. They will be accessed through
>> >> > >> acpi_os_map_memory() and so won't be required to be part of system ram
>> >> > >> (or memblocks), I guess.
>> >> > >
>> >> > > Agreed. They will be covered by the linear mapping in the boot kernel,
>> >> > > and be mapped explicitly via ioremap_cache() in the kexec kernel,
>> >> > > which is exactly what we want in this case.
>> >> >
>> >> > Now this is what is confusing me. I don't see the above happening.
>> >> >
>> >> > I see that the primary kernel boots up and adds the ACPI regions via:
>> >> > acpi_os_ioremap
>> >> > -> ioremap_cache
>> >> >
>> >> > But during the crashkernel boot, ''acpi_os_ioremap' calls
>> >> > 'ioremap' for the ACPI Reclaim Memory regions and not the _cache
>> >> > variant.
>> >
>> > It is natural if that region is out of memblocks.
>>
>> Thanks for the confirmation. This was my understanding as well.
>>
>> >> > And it fails while accessing the ACPI tables:
>> >> >
>> >> > [ 0.039205] ACPI: Core revision 20170728
>> >> > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
>> >> > [ 0.095098] Internal error: Oops: 96000021 [#1] SMP
>> >
>> > this (ESR = 0x96000021) means that Data Abort and Alignment fault happened.
>> > As ioremap() makes the mapping as "Device memory", unaligned memory
>> > access won't be allowed.
>> >
>> >> > [ 0.100022] Modules linked in:
>> >> > [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
>> >> > [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
>> >> > [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
>> >> > [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
>> >> > [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
>> >> > pstate: 60000045
>> >> > [ 0.132647] sp : ffff000008ccfb40
>> >> > [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
>> >> > [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
>> >> > [ 0.146718] x25: 000000000000001b x24: 0000000000000001
>> >> > [ 0.152083] x23: 0000000000000001 x22: ffff000009710027
>> >> > [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
>> >> > [ 0.162812] x19: 000000000000001b x18: 0000000000000005
>> >> > [ 0.168176] x17: 0000000000000000 x16: 0000000000000000
>> >> > [ 0.173541] x15: 0000000000000000 x14: 000000000000038e
>> >> > [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
>> >> > [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
>> >> > [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
>> >> > [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
>> >> > [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
>> >> > [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
>> >> > [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
>> >> > [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
>> >> > [ 0.223224] Call trace:
>> >> > [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
>> >> > [ 0.232194] fa00: 0000000000000000 ffff000009710027
>> >> > ffff0000095e3980 ffff000008ccfbe0
>> >> > [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
>> >> > ffff000008ccfc50 0000000000000000
>> >> > [ 0.248018] fa40: ffff8000126d0140 000000000000005f
>> >> > 00000000ffffff76 0000000000000006
>> >> > [ 0.255931] fa60: ffffffffffffffff ffffffff00000000
>> >> > 000000000000038e 0000000000000000
>> >> > [ 0.263843] fa80: 0000000000000000 0000000000000000
>> >> > 0000000000000005 000000000000001b
>> >> > [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
>> >> > ffff000009710027 0000000000000001
>> >> > [ 0.279667] fac0: 0000000000000001 000000000000001b
>> >> > 0000000000000000 ffff0000088be820
>> >> > [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
>> >> > ffff00000849b4f8 ffff000008ccfb40
>> >> > [ 0.295491] fb00: ffff0000084a6764 0000000060000045
>> >> > ffff000008ccfb40 ffff000008260a18
>> >> > [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
>> >> > ffff000008ccfb40 ffff0000084a6764
>> >> > [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
>> >> > [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
>> >> > [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
>> >> > [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
>> >> > [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
>> >> > [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
>> >> > [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
>> >> > [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
>> >> > [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
>> >> > [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
>> >> > [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
>> >> > [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
>> >> > [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
>> >> > [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
>> >> > [ 0.394500] ---[ end trace c46ed37f9651c58e ]---
>> >> > [ 0.399160] Kernel panic - not syncing: Fatal exception
>> >> > [ 0.404437] Rebooting in 10 seconds.
>> >> >
>> >> > So, I think the linear mapping done by the primary kernel does not
>> >> > make these accessible in the crash kernel directly.
>> >> >
>> >> > Any pointers?
>> >>
>> >> Can you get the code line number for acpi_ns_lookup+0x25c?
>> >
>> > So should we always avoid ioremap() in acpi_os_ioremap() entirely, or
>> > modify acpi_ns_lookup() (or any acpi functions') to prevent unaligned
>> > accesses?
>> > (I didn't find out how unaligned accesses could happen there.)
>> >
>>
>> Right. Like I captured somewhere in this thread (perhaps the first
>> email on this subject),
>> this is indeed an unaligned address access.
>>
>> Now, modifying acpi_os_ioremap() to not ioremap() and thus avoiding
>> assigning this memory range
>> as device memory doesn't seem a neat solution as it means we are not
>> marking some thing with the right memory attribute and we can fall in
>> similar/related issues later.
>>
>> Regarding the later suggestion, what I am seeing now is that the acpi
>> table access functions are perhaps reused from the earlier x86
>> implementation, but on the arm64 (or even arm) arch we should not be
>> allowing unaligned accesses which might cause UNDEFINED behaviour and
>> resultant crash.
>>
>> So I can try going this approach and see if it works for me.
>>
>> However, I am still not very sure as to why the crashkernel ranges
>> historically do not include the System RAM regions (which may include
>> the ACPI regions as well). These regions are available for the kernel
>> usage and perhaps should be exported to the crashkernel as well.
>>
>> I am not fully aware of the previous discussions on capp'ing the
>> crashkernel memory being passed to the kdump kernel, but did we run
>> into any issues while doing so?
>>
>> Also, even if I extend the kexec-tools to modify the
>> linux,usable-memory-range and add the ACPI regions to it, the
>> crashkernel fails to boot with the below message (I have added some
>> logic to print the DTB on the crash kernel boot start):
>>
>> [ 0.000000] chosen {
>> [ 0.000000] linux,usable-memory-range
>> [ 0.000000] = <
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x0e800000
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x20000000
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x396c0000
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x000a0000
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x39770000
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x00040000
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x398a0000
>> [ 0.000000] 0x00000000
>> [ 0.000000] 0x00020000
>> [ 0.000000] >
>> [ 0.000000] ;
>>
>> [snip..]
>>
>> [ 0.000000] linux,usable-memory-range base e800000, size 20000000
>> [ 0.000000] - e800000 , 20000000
>> [ 0.000000] linux,usable-memory-range base 396c0000, size a0000
>> [ 0.000000] - 396c0000 , a0000
>> [ 0.000000] linux,usable-memory-range base 39770000, size 40000
>> [ 0.000000] - 39770000 , 40000
>> [ 0.000000] linux,usable-memory-range base 398a0000, size 20000
>> [ 0.000000] - 398a0000 , 20000
>> [ 0.000000] initrd not fully accessible via the linear mapping --
>> please check your bootloader ...
>> [ 0.000000] ------------[ cut here ]------------
>> [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:597
>> arm64_memblock_init+0x210/0x484
>> [ 0.000000] Modules linked in:
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0+ #7
>> [ 0.000000] task: ffff000008d05580 task.stack: ffff000008cc0000
>> [ 0.000000] PC is at arm64_memblock_init+0x210/0x484
>> [ 0.000000] LR is at arm64_memblock_init+0x210/0x484
>> [ 0.000000] pc : [<ffff000008b76984>] lr : [<ffff000008b76984>]
>> pstate: 600000c5
>> [ 0.000000] sp : ffff000008ccfe80
>> [ 0.000000] x29: ffff000008ccfe80 x28: 000000000f370018
>> [ 0.000000] x27: 0000000011230000 x26: 00000000013b0000
>> [ 0.000000] x25: 000000000fe80000 x24: ffff000008cf3000
>> [ 0.000000] x23: ffff000008ec0000 x22: ffff000009680000
>> [ 0.000000] x21: ffff000008afa000 x20: ffff000008080000
>> [ 0.000000] x19: ffff000008afa000 x18: 000000000c283806
>> [ 0.000000] x17: 0000000000000000 x16: ffff000008d05580
>> [ 0.000000] x15: 000000002be00842 x14: 79206b6365686320
>> [ 0.000000] x13: 657361656c70202d x12: 2d20676e69707061
>> [ 0.000000] x11: 6d207261656e696c x10: 2065687420616976
>> [ 0.000000] x9 : 00000000000000f4 x8 : ffff000008517414
>> [ 0.000000] x7 : 746f6f622072756f x6 : 000000000000000d
>> [ 0.000000] x5 : ffff000008c96360 x4 : 0000000000000001
>> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
>> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
>> [ 0.000000] Call trace:
>> [ 0.000000] Exception stack(0xffff000008ccfd40 to 0xffff000008ccfe80)
>> [ 0.000000] fd40: 0000000000000056 0000000000000000
>> 0000000000000000 0000000000000000
>> [ 0.000000] fd60: 0000000000000001 ffff000008c96360
>> 000000000000000d 746f6f622072756f
>> [ 0.000000] fd80: ffff000008517414 00000000000000f4
>> 2065687420616976 6d207261656e696c
>> [ 0.000000] fda0: 2d20676e69707061 657361656c70202d
>> 79206b6365686320 000000002be00842
>> [ 0.000000] fdc0: ffff000008d05580 0000000000000000
>> 000000000c283806 ffff000008afa000
>> [ 0.000000] fde0: ffff000008080000 ffff000008afa000
>> ffff000009680000 ffff000008ec0000
>> [ 0.000000] fe00: ffff000008cf3000 000000000fe80000
>> 00000000013b0000 0000000011230000
>> [ 0.000000] fe20: 000000000f370018 ffff000008ccfe80
>> ffff000008b76984 ffff000008ccfe80
>> [ 0.000000] fe40: ffff000008b76984 00000000600000c5
>> ffff00000959b7a8 ffff000008ec0000
>> [ 0.000000] fe60: ffffffffffffffff 0000000000000005
>> ffff000008ccfe80 ffff000008b76984
>> [ 0.000000] [<ffff000008b76984>] arm64_memblock_init+0x210/0x484
>> [ 0.000000] [<ffff000008b7398c>] setup_arch+0x1b8/0x5f4
>> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
>> [ 0.000000] random: get_random_bytes called from
>> print_oops_end_marker+0x50/0x6c with crng_init=0
>> [ 0.000000] ---[ end trace 0000000000000000 ]---
>> [ 0.000000] Reserving 4KB of memory at 0x2e7f0000 for elfcorehdr
>> [ 0.000000] cma: Failed to reserve 512 MiB
>> [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
>> 0x0000000000010000 bytes below 0x0000000000000000.
>> [ 0.000000]
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W
>> ------------ 4.14.0+ #7
>> [ 0.000000] Call trace:
>> [ 0.000000] [<ffff000008088da8>] dump_backtrace+0x0/0x23c
>> [ 0.000000] [<ffff000008089008>] show_stack+0x24/0x2c
>> [ 0.000000] [<ffff0000087f647c>] dump_stack+0x84/0xa8
>> [ 0.000000] [<ffff0000080cfd44>] panic+0x138/0x2a0
>> [ 0.000000] [<ffff000008b95c88>] memblock_alloc_base+0x44/0x4c
>> [ 0.000000] [<ffff000008b95cbc>] memblock_alloc+0x2c/0x38
>> [ 0.000000] [<ffff000008b772dc>] early_pgtable_alloc+0x20/0x74
>> [ 0.000000] [<ffff000008b7755c>] paging_init+0x28/0x544
>> [ 0.000000] [<ffff000008b73990>] setup_arch+0x1bc/0x5f4
>> [ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
>> [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
>> allocate 0x0000000000010000 bytes below 0x0000000000000000.
>> [ 0.000000]
>>
>> I guess it is because of the 1G alignment requirement between the
>> kernel image and the initrd and how we populate the holes between the
>> kernel image, segments (including dtb) and the initrd from the
>> kexec-tools.
>>
>> Akashi, any pointers on this will be helpful as well.
>
> Please show me:
> * "Virtual kernel memory layout" in dmesg
> * /proc/iomem
> * debug messages from kexec-tools (kexec -d)
So here are the changes which I have done so far in the kernel and
kexec-tools to allow mapping ACPI reclaim regions as identifiable
regions in '/proc/iomem' and to append them to the DTB property:
linux,usable-memory-range:
Linux patch: <https://github.com/bhupesh-sharma/linux/commit/88d2ff6a1c16f5aa107b567a9d9c60343e52f263>,
and
<https://github.com/bhupesh-sharma/linux/commit/23262febd29a6665d483a707a05f8869757b8848>
kexec-tools patch:
<https://github.com/bhupesh-sharma/kexec-tools/commit/3e3d7c50648b1195674d1b7667cbbfd8d899b650>
Note that I am not very clear about the hole margins that the
kexec-tools adds (so that the crashkernel's expectation that the
kernel image and initrd lie within a 1G boundary), so I have not added
my temporary changes to the github code - but any suggestions on how
to correctly put them in place would be appreciated.
And here are the rest of the inputs you asked for:
(1) # dmesg | grep -A 15 -B 4 -i "Virtual kernel memory layout"
[ 0.000000] Kernel command line:
BOOT_IMAGE=/vmlinuz-4.15.0-rc2-next-20171207+
root=/dev/mapper/rhelaa_huawei--t2280--01-root ro
earlycon=pl011,mmio,0x602B0000 efi=debug memblock_debug=1
pcie_aspm=off crashkernel=512M rd.lvm.lv=rhelaa_huawei-t2280-01/root
rd.lvm.lv=rhelaa_huawei-t2280-01/swap acpi=force
console=ttyAMA0,115200
[ 0.000000] PCIe ASPM is disabled
[ 0.000000] software IO TLB [mem 0x35620000-0x39620000] (64MB)
mapped at [ (ptrval)- (ptrval)]
[ 0.000000] Memory: 267251520K/268169216K available (7868K kernel
code, 1764K rwdata, 3328K rodata, 1280K init, 7727K bss, 917696K
reserved, 0K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
( 128 MB)
[ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
(126847 GB)
[ 0.000000] .text : 0x (ptrval) - 0x (ptrval)
( 7872 KB)
[ 0.000000] .rodata : 0x (ptrval) - 0x (ptrval)
( 3392 KB)
[ 0.000000] .init : 0x (ptrval) - 0x (ptrval)
( 1280 KB)
[ 0.000000] .data : 0x (ptrval) - 0x (ptrval)
( 1765 KB)
[ 0.000000] .bss : 0x (ptrval) - 0x (ptrval)
( 7728 KB)
[ 0.000000] fixed : 0xffff7fdffe7b0000 - 0xffff7fdffec00000
( 4416 KB)
[ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
( 16 MB)
[ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
( 128 GB maximum)
[ 0.000000] 0xffff7fe000000000 - 0xffff7fe02bff0000
( 703 MB actual)
[ 0.000000] memory : 0xffff800000000000 - 0xffff80affc000000
(720832 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=64, Nodes=4
[ 0.000000] ftrace: allocating 29903 entries in 8 pages
[ 0.000000] Hierarchical RCU implementation.
(2) # cat /proc/iomem
00000000-3961ffff : System RAM
00080000-00b7ffff : Kernel code
00cc0000-0166ffff : Kernel data
0e800000-2e7fffff : Crash kernel
39620000-396bffff : reserved
396c0000-3975ffff : ACPI reclaim region
39760000-3976ffff : reserved
39770000-397affff : ACPI reclaim region
397b0000-3989ffff : reserved
398a0000-398bffff : ACPI reclaim region
398c0000-39d3ffff : reserved
39d40000-3ed2ffff : System RAM
3ed30000-3ed5ffff : reserved
3ed60000-3fbfffff : System RAM
40500000-40500fff : sbsa-gwdt.0
40500000-40500fff : sbsa-gwdt.0
40600000-40600fff : sbsa-gwdt.0
40600000-40600fff : sbsa-gwdt.0
60080000-6008ffff : HISI0152:00
602b0000-602b0fff : ARMH0011:00
602b0000-602b0fff : ARMH0011:00
603c0000-603cffff : HISI0141:00
603c0000-603cffff : HISI0141:00
a0080000-a008ffff : HISI0152:05
a0080000-a008ffff : HISI0152:04
a0080000-a008ffff : HISI0152:03
a00a0000-a00affff : pnp 00:01
a01b0000-a01b0fff : HISI0191:00
a2000000-a200ffff : HISI0162:01
a2000000-a200ffff : HISI0162:01
a3000000-a300ffff : HISI0162:02
a3000000-a300ffff : HISI0162:02
a7020000-a702ffff : PNP0D20:00
a7020000-a702ffff : PNP0D20:00
b0000000-be7fffff : PCI Bus 0002:e8
b0000000-b06fffff : PCI Bus 0002:e9
b0000000-b00fffff : 0002:e9:00.0
b0000000-b00fffff : igb
b0100000-b01fffff : 0002:e9:00.0
b0200000-b02fffff : 0002:e9:00.1
b0200000-b02fffff : igb
b0300000-b03fffff : 0002:e9:00.1
b0400000-b04fffff : 0002:e9:00.2
b0400000-b04fffff : igb
b0500000-b05fffff : 0002:e9:00.3
b0500000-b05fffff : igb
b0600000-b0603fff : 0002:e9:00.0
b0600000-b0603fff : igb
b0604000-b0607fff : 0002:e9:00.1
b0604000-b0607fff : igb
b0608000-b060bfff : 0002:e9:00.2
b0608000-b060bfff : igb
b060c000-b060ffff : 0002:e9:00.3
b060c000-b060ffff : igb
b0700000-b0afffff : PCI Bus 0002:e9
b0700000-b077ffff : 0002:e9:00.0
b0780000-b07fffff : 0002:e9:00.0
b0800000-b087ffff : 0002:e9:00.1
b0880000-b08fffff : 0002:e9:00.1
b0900000-b097ffff : 0002:e9:00.2
b0980000-b09fffff : 0002:e9:00.2
b0a00000-b0a7ffff : 0002:e9:00.3
b0a80000-b0afffff : 0002:e9:00.3
b0b00000-b0b0ffff : 0002:e8:00.0
be800000-beffffff : PCI ECAM
c0080000-c008ffff : HISI0152:02
c0080000-c008ffff : HISI0152:01
c3000000-c300ffff : HISI0162:00
c3000000-c300ffff : HISI0162:00
c5000000-c588ffff : HISI00B2:00
c5000000-c588ffff : HISI00B2:00
c7000000-c705ffff : HISI00B2:00
c7000000-c705ffff : HISI00B2:00
d0080000-d008ffff : HISI0152:07
d0080000-d008ffff : HISI0152:06
d0100000-d010ffff : HISI02A1:00
d0100000-d010ffff : HISI02A1:00
400000000-4007fffff : PCI ECAM
440000000-4ffffffff : PCI Bus 0005:00
440000000-4407fffff : PCI Bus 0005:01
440000000-4403fffff : 0005:01:00.0
440400000-4407fffff : 0005:01:00.1
440800000-4421fffff : PCI Bus 0005:01
440800000-440bfffff : 0005:01:00.0
440800000-440bfffff : ixgbe
440c00000-440ffffff : 0005:01:00.1
440c00000-440ffffff : ixgbe
441000000-4413fffff : 0005:01:00.0
441400000-4417fffff : 0005:01:00.0
441800000-441bfffff : 0005:01:00.1
441c00000-441ffffff : 0005:01:00.1
442000000-442003fff : 0005:01:00.0
442000000-442003fff : ixgbe
442004000-442007fff : 0005:01:00.1
442004000-442007fff : ixgbe
442200000-442200fff : 0005:00:00.0
700090000-70009ffff : pnp 00:03
7000a0000-7000affff : pnp 00:05
7000b0000-7000bffff : pnp 00:06
700200000-70020ffff : pnp 00:04
740800000-740ffffff : PCI ECAM
741000000-77ffeffff : PCI Bus 0006:08
741000000-74100ffff : 0006:08:00.0
784000000-7847fffff : PCI ECAM
784800000-7bffeffff : PCI Bus 0007:40
784800000-7849fffff : PCI Bus 0007:41
784800000-7849fffff : 0007:41:00.0
786000000-787ffffff : PCI Bus 0007:41
786000000-787ffffff : 0007:41:00.0
7c4800000-7c4ffffff : PCI ECAM
7c5000000-7fffeffff : PCI Bus 0004:48
7c5000000-7c51fffff : PCI Bus 0004:49
7c5000000-7c50fffff : 0004:49:00.0
7c5100000-7c513ffff : 0004:49:00.0
7c5100000-7c513ffff : mpt3sas
7c5140000-7c514ffff : 0004:49:00.0
7c5140000-7c514ffff : mpt3sas
7c5200000-7c520ffff : 0004:48:00.0
1040000000-1ffbffffff : System RAM
2000000000-2ffbffffff : System RAM
9000000000-9ffbffffff : System RAM
a000000000-affbffffff : System RAM
400c0080000-400c008ffff : HISI0152:08
600a00a0000-600a00affff : pnp 00:08
64001000000-64001ffffff : PCI ECAM
65040000000-650ffffffff : PCI Bus 000a:10
65040000000-6504000ffff : 000a:10:00.0
700a0090000-700a009ffff : pnp 00:0a
700a0200000-700a020ffff : pnp 00:0b
74002000000-74002ffffff : PCI ECAM
75040000000-750ffffffff : PCI Bus 000c:20
75040000000-7504000ffff : 000c:20:00.0
78003000000-78003ffffff : PCI ECAM
79040000000-790ffffffff : PCI Bus 000d:30
79040000000-79040000fff : 000d:30:00.0
(3)
# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline -d
arch_process_options:149: command_line:
root=/dev/mapper/rhelaa_huawei--t2280--01-root ro
earlycon=pl011,mmio,0x602B0000 efi=debug memblock_debug=1
pcie_aspm=off rd.lvm.lv=rhelaa_huawei-t2280-01/root
rd.lvm.lv=rhelaa_huawei-t2280-01/swap acpi=force
console=ttyAMA0,115200
arch_process_options:151: initrd: /boot/initramfs-4.15.0-rc2-next-20171207+.img
arch_process_options:152: dtb: (null)
Try gzip decompression.
kernel: 0xffff968d0010 kernel_size: 0xdf9200
get_memory_ranges_iomem_cb: 0000000000000000 - 000000003961ffff : System RAM
get_memory_ranges_iomem_cb: 0000000039620000 - 00000000396bffff : reserved
get_memory_ranges_iomem_cb: 0000000039760000 - 000000003976ffff : reserved
get_memory_ranges_iomem_cb: 00000000397b0000 - 000000003989ffff : reserved
get_memory_ranges_iomem_cb: 00000000398c0000 - 0000000039d3ffff : reserved
get_memory_ranges_iomem_cb: 0000000039d40000 - 000000003ed2ffff : System RAM
get_memory_ranges_iomem_cb: 000000003ed30000 - 000000003ed5ffff : reserved
get_memory_ranges_iomem_cb: 000000003ed60000 - 000000003fbfffff : System RAM
get_memory_ranges_iomem_cb: 0000001040000000 - 0000001ffbffffff : System RAM
get_memory_ranges_iomem_cb: 0000002000000000 - 0000002ffbffffff : System RAM
get_memory_ranges_iomem_cb: 0000009000000000 - 0000009ffbffffff : System RAM
get_memory_ranges_iomem_cb: 000000a000000000 - 000000affbffffff : System RAM
elf_arm64_probe: Not an ELF executable.
image_arm64_load: kernel_segment: 000000000e800000
image_arm64_load: text_offset: 0000000000080000
image_arm64_load: image_size: 00000000015f0000
image_arm64_load: phys_offset: 0000000000000000
image_arm64_load: vp_offset: ffffffffffffffff
image_arm64_load: PE format: yes
Reserved memory range
000000000e800000-000000002e7fffff (0)
Coredump memory ranges
0000000000000000-000000000e7fffff (0)
000000002e800000-000000003961ffff (0)
0000000039d40000-000000003ed2ffff (0)
000000003ed60000-000000003fbfffff (0)
0000001040000000-0000001ffbffffff (0)
0000002000000000-0000002ffbffffff (0)
0000009000000000-0000009ffbffffff (0)
000000a000000000-000000affbffffff (0)
ACPI reclaim memory ranges
00000000396c0000-000000003975ffff (0)
0000000039770000-00000000397affff (0)
00000000398a0000-00000000398bffff (0)
crashkernel memory ranges
000000000e800000-000000002e7fffff (0)
00000000396c0000-000000003975ffff (0)
0000000039770000-00000000397affff (0)
00000000398a0000-00000000398bffff (0)
kernel symbol _text vaddr = ffff000008080000
load_crashdump_segments: page_offset: ffff800000000000
get_crash_notes_per_cpu: crash_notes addr = 1ff7cf3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7cf3200 p_paddr = 0x1ff7cf3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7d23200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7d23200 p_paddr = 0x1ff7d23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7d53200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7d53200 p_paddr = 0x1ff7d53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7d83200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7d83200 p_paddr = 0x1ff7d83200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7db3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7db3200 p_paddr = 0x1ff7db3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7de3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7de3200 p_paddr = 0x1ff7de3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7e13200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7e13200 p_paddr = 0x1ff7e13200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7e43200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7e43200 p_paddr = 0x1ff7e43200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7e73200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7e73200 p_paddr = 0x1ff7e73200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7ea3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7ea3200 p_paddr = 0x1ff7ea3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7ed3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7ed3200 p_paddr = 0x1ff7ed3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f03200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f03200 p_paddr = 0x1ff7f03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f33200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f33200 p_paddr = 0x1ff7f33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f63200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f63200 p_paddr = 0x1ff7f63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f93200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f93200 p_paddr = 0x1ff7f93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7fc3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7fc3200 p_paddr = 0x1ff7fc3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7d13200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7d13200 p_paddr = 0x2ff7d13200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7d43200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7d43200 p_paddr = 0x2ff7d43200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7d73200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7d73200 p_paddr = 0x2ff7d73200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7da3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7da3200 p_paddr = 0x2ff7da3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7dd3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7dd3200 p_paddr = 0x2ff7dd3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e03200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e03200 p_paddr = 0x2ff7e03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e33200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e33200 p_paddr = 0x2ff7e33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e63200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e63200 p_paddr = 0x2ff7e63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e93200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e93200 p_paddr = 0x2ff7e93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7ec3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7ec3200 p_paddr = 0x2ff7ec3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7ef3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7ef3200 p_paddr = 0x2ff7ef3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7f23200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7f23200 p_paddr = 0x2ff7f23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7f53200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7f53200 p_paddr = 0x2ff7f53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7f83200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7f83200 p_paddr = 0x2ff7f83200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7fb3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7fb3200 p_paddr = 0x2ff7fb3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7fe3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7fe3200 p_paddr = 0x2ff7fe3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d03200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d03200 p_paddr = 0x9ff7d03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d33200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d33200 p_paddr = 0x9ff7d33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d63200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d63200 p_paddr = 0x9ff7d63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d93200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d93200 p_paddr = 0x9ff7d93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7dc3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7dc3200 p_paddr = 0x9ff7dc3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7df3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7df3200 p_paddr = 0x9ff7df3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7e23200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7e23200 p_paddr = 0x9ff7e23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7e53200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7e53200 p_paddr = 0x9ff7e53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7e83200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7e83200 p_paddr = 0x9ff7e83200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7eb3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7eb3200 p_paddr = 0x9ff7eb3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7ee3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7ee3200 p_paddr = 0x9ff7ee3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7f13200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7f13200 p_paddr = 0x9ff7f13200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7f43200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7f43200 p_paddr = 0x9ff7f43200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7f73200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7f73200 p_paddr = 0x9ff7f73200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7fa3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7fa3200 p_paddr = 0x9ff7fa3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7fd3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7fd3200 p_paddr = 0x9ff7fd3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7883200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7883200 p_paddr = 0xaff7883200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff78b3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff78b3200 p_paddr = 0xaff78b3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff78e3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff78e3200 p_paddr = 0xaff78e3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7913200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7913200 p_paddr = 0xaff7913200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7943200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7943200 p_paddr = 0xaff7943200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7973200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7973200 p_paddr = 0xaff7973200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff79a3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff79a3200 p_paddr = 0xaff79a3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff79d3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff79d3200 p_paddr = 0xaff79d3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a03200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a03200 p_paddr = 0xaff7a03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a33200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a33200 p_paddr = 0xaff7a33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a63200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a63200 p_paddr = 0xaff7a63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a93200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a93200 p_paddr = 0xaff7a93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7ac3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7ac3200 p_paddr = 0xaff7ac3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7af3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7af3200 p_paddr = 0xaff7af3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7b23200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7b23200 p_paddr = 0xaff7b23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7b53200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7b53200 p_paddr = 0xaff7b53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
vmcoreinfo header: p_type = 4, p_offset = 0x9fc4720000 p_paddr =
0x9fc4720000 p_vaddr = 0x0 p_filesz = 0x10024 p_memsz = 0x10024
Kernel text Elf header: p_type = 1, p_offset = 0x80000 p_paddr =
0x80000 p_vaddr = 0xffff000008080000 p_filesz = 0x15f0000 p_memsz =
0x15f0000
Elf header: p_type = 1, p_offset = 0x0 p_paddr = 0x0 p_vaddr =
0xffff800000000000 p_filesz = 0xe800000 p_memsz = 0xe800000
Elf header: p_type = 1, p_offset = 0x2e800000 p_paddr = 0x2e800000
p_vaddr = 0xffff80002e800000 p_filesz = 0xae20000 p_memsz = 0xae20000
Elf header: p_type = 1, p_offset = 0x39d40000 p_paddr = 0x39d40000
p_vaddr = 0xffff800039d40000 p_filesz = 0x4ff0000 p_memsz = 0x4ff0000
Elf header: p_type = 1, p_offset = 0x3ed60000 p_paddr = 0x3ed60000
p_vaddr = 0xffff80003ed60000 p_filesz = 0xea0000 p_memsz = 0xea0000
Elf header: p_type = 1, p_offset = 0x1040000000 p_paddr = 0x1040000000
p_vaddr = 0xffff801040000000 p_filesz = 0xfbc000000 p_memsz =
0xfbc000000
Elf header: p_type = 1, p_offset = 0x2000000000 p_paddr = 0x2000000000
p_vaddr = 0xffff802000000000 p_filesz = 0xffc000000 p_memsz =
0xffc000000
Elf header: p_type = 1, p_offset = 0x9000000000 p_paddr = 0x9000000000
p_vaddr = 0xffff809000000000 p_filesz = 0xffc000000 p_memsz =
0xffc000000
Elf header: p_type = 1, p_offset = 0xa000000000 p_paddr = 0xa000000000
p_vaddr = 0xffff80a000000000 p_filesz = 0xffc000000 p_memsz =
0xffc000000
get_crash_notes_per_cpu: crash_notes addr = 1ff7cf3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7cf3200 p_paddr = 0x1ff7cf3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7d23200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7d23200 p_paddr = 0x1ff7d23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7d53200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7d53200 p_paddr = 0x1ff7d53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7d83200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7d83200 p_paddr = 0x1ff7d83200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7db3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7db3200 p_paddr = 0x1ff7db3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7de3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7de3200 p_paddr = 0x1ff7de3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7e13200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7e13200 p_paddr = 0x1ff7e13200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7e43200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7e43200 p_paddr = 0x1ff7e43200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7e73200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7e73200 p_paddr = 0x1ff7e73200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7ea3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7ea3200 p_paddr = 0x1ff7ea3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7ed3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7ed3200 p_paddr = 0x1ff7ed3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f03200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f03200 p_paddr = 0x1ff7f03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f33200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f33200 p_paddr = 0x1ff7f33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f63200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f63200 p_paddr = 0x1ff7f63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7f93200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7f93200 p_paddr = 0x1ff7f93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 1ff7fc3200, size = 424
Elf header: p_type = 4, p_offset = 0x1ff7fc3200 p_paddr = 0x1ff7fc3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7d13200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7d13200 p_paddr = 0x2ff7d13200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7d43200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7d43200 p_paddr = 0x2ff7d43200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7d73200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7d73200 p_paddr = 0x2ff7d73200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7da3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7da3200 p_paddr = 0x2ff7da3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7dd3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7dd3200 p_paddr = 0x2ff7dd3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e03200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e03200 p_paddr = 0x2ff7e03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e33200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e33200 p_paddr = 0x2ff7e33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e63200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e63200 p_paddr = 0x2ff7e63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7e93200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7e93200 p_paddr = 0x2ff7e93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7ec3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7ec3200 p_paddr = 0x2ff7ec3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7ef3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7ef3200 p_paddr = 0x2ff7ef3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7f23200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7f23200 p_paddr = 0x2ff7f23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7f53200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7f53200 p_paddr = 0x2ff7f53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7f83200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7f83200 p_paddr = 0x2ff7f83200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7fb3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7fb3200 p_paddr = 0x2ff7fb3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 2ff7fe3200, size = 424
Elf header: p_type = 4, p_offset = 0x2ff7fe3200 p_paddr = 0x2ff7fe3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d03200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d03200 p_paddr = 0x9ff7d03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d33200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d33200 p_paddr = 0x9ff7d33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d63200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d63200 p_paddr = 0x9ff7d63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7d93200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7d93200 p_paddr = 0x9ff7d93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7dc3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7dc3200 p_paddr = 0x9ff7dc3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7df3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7df3200 p_paddr = 0x9ff7df3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7e23200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7e23200 p_paddr = 0x9ff7e23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7e53200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7e53200 p_paddr = 0x9ff7e53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7e83200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7e83200 p_paddr = 0x9ff7e83200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7eb3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7eb3200 p_paddr = 0x9ff7eb3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7ee3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7ee3200 p_paddr = 0x9ff7ee3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7f13200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7f13200 p_paddr = 0x9ff7f13200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7f43200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7f43200 p_paddr = 0x9ff7f43200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7f73200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7f73200 p_paddr = 0x9ff7f73200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7fa3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7fa3200 p_paddr = 0x9ff7fa3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 9ff7fd3200, size = 424
Elf header: p_type = 4, p_offset = 0x9ff7fd3200 p_paddr = 0x9ff7fd3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7883200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7883200 p_paddr = 0xaff7883200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff78b3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff78b3200 p_paddr = 0xaff78b3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff78e3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff78e3200 p_paddr = 0xaff78e3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7913200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7913200 p_paddr = 0xaff7913200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7943200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7943200 p_paddr = 0xaff7943200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7973200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7973200 p_paddr = 0xaff7973200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff79a3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff79a3200 p_paddr = 0xaff79a3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff79d3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff79d3200 p_paddr = 0xaff79d3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a03200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a03200 p_paddr = 0xaff7a03200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a33200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a33200 p_paddr = 0xaff7a33200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a63200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a63200 p_paddr = 0xaff7a63200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7a93200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7a93200 p_paddr = 0xaff7a93200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7ac3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7ac3200 p_paddr = 0xaff7ac3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7af3200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7af3200 p_paddr = 0xaff7af3200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7b23200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7b23200 p_paddr = 0xaff7b23200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = aff7b53200, size = 424
Elf header: p_type = 4, p_offset = 0xaff7b53200 p_paddr = 0xaff7b53200
p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
vmcoreinfo header: p_type = 4, p_offset = 0x9fc4720000 p_paddr =
0x9fc4720000 p_vaddr = 0x0 p_filesz = 0x10024 p_memsz = 0x10024
Kernel text Elf header: p_type = 1, p_offset = 0x80000 p_paddr =
0x80000 p_vaddr = 0xffff000008080000 p_filesz = 0x15f0000 p_memsz =
0x15f0000
Elf header: p_type = 1, p_offset = 0x396c0000 p_paddr = 0x396c0000
p_vaddr = 0xffff8000396c0000 p_filesz = 0xa0000 p_memsz = 0xa0000
Elf header: p_type = 1, p_offset = 0x39770000 p_paddr = 0x39770000
p_vaddr = 0xffff800039770000 p_filesz = 0x40000 p_memsz = 0x40000
Elf header: p_type = 1, p_offset = 0x398a0000 p_paddr = 0x398a0000
p_vaddr = 0xffff8000398a0000 p_filesz = 0x20000 p_memsz = 0x20000
load_crashdump_segments: elfcorehdr 0x2e7f0000-0x2e7f0fff
read_1st_dtb: found /sys/firmware/fdt
get_cells_size: #address-cells:2 #size-cells:2
cells_size_fitted: 2e7f0000-2e7f0fff
cells_size_fitted: e800000-2e7fffff
cells_size_fitted: 396c0000-3975ffff
cells_size_fitted: 39770000-397affff
cells_size_fitted: 398a0000-398bffff
/ {
#size-cells = <0x00000002>;
#address-cells = <0x00000002>;
chosen {
linux,usable-memory-range = <0x00000000 0x0e800000 0x00000000
0x20000000 0x00000000 0x396c0000 0x00000000 0x000a0000 0x00000000
0x39770000 0x00000000 0x00040000 0x00000000 0x398a0000 0x00000000
0x00020000>;
linux,elfcorehdr = <0x00000000 0x2e7f0000 0x00000000 0x00001000>;
linux,uefi-mmap-desc-ver = <0x00000001>;
linux,uefi-mmap-desc-size = <0x00000030>;
linux,uefi-mmap-size = <0x00000e40>;
linux,uefi-mmap-start = <0x00000000 0x30288018>;
linux,uefi-system-table = <0x00000000 0x3ed50018>;
bootargs = "root=/dev/mapper/rhelaa_huawei--t2280--01-root ro
earlycon=pl011,mmio,0x602B0000 efi=debug memblock_debug=1
pcie_aspm=off rd.lvm.lv=rhelaa_huawei-t2280-01/root
rd.lvm.lv=rhelaa_huawei-t2280-01/swap acpi=force
console=ttyAMA0,115200";
linux,initrd-end = <0x00000000 0x2fbff9e0>;
linux,initrd-start = <0x00000000 0x2e84d000>;
};
};
initrd: base fe70000, size 13b29e0h (20654560), end 112229e0
[snip..]
sym: sha256_starts info: 12 other: 00 shndx: 1 value: eb0 size: 6c
sym: sha256_starts value: 11240eb0 addr: 11240018
machine_apply_elf_rel: CALL26 580006b394000000->580006b3940003a6
sym: sha256_update info: 12 other: 00 shndx: 1 value: 5158 size: c
sym: sha256_update value: 11245158 addr: 11240034
machine_apply_elf_rel: CALL26 9100427394000000->9100427394001449
sym: sha256_finish info: 12 other: 00 shndx: 1 value: 5164 size: 1cc
sym: sha256_finish value: 11245164 addr: 11240050
machine_apply_elf_rel: CALL26 aa1403e094000000->aa1403e094001445
sym: memcmp info: 12 other: 00 shndx: 1 value: 634 size: 34
sym: memcmp value: 11240634 addr: 11240060
machine_apply_elf_rel: CALL26 340003c094000000->340003c094000175
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 11240070
machine_apply_elf_rel: CALL26 5800046094000000->5800046094000135
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 11240078
machine_apply_elf_rel: CALL26 5800047594000000->5800047594000133
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 11240088
machine_apply_elf_rel: CALL26 9100067394000000->910006739400012f
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 112400a8
machine_apply_elf_rel: CALL26 5800036094000000->5800036094000127
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 112400b0
machine_apply_elf_rel: CALL26 910402e194000000->910402e194000125
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 112400c0
machine_apply_elf_rel: CALL26 9100067394000000->9100067394000121
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 112400d4
machine_apply_elf_rel: CALL26 5280002094000000->528000209400011c
sym: .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 112453a8 addr: 112400f0
machine_apply_elf_rel: ABS64 0000000000000000->00000000112453a8
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 11245338 addr: 112400f8
machine_apply_elf_rel: ABS64 0000000000000000->0000000011245338
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 11245358 addr: 11240100
machine_apply_elf_rel: ABS64 0000000000000000->0000000011245358
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 11245368 addr: 11240108
machine_apply_elf_rel: ABS64 0000000000000000->0000000011245368
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 1124536e addr: 11240110
machine_apply_elf_rel: ABS64 0000000000000000->000000001124536e
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 11245370 addr: 11240118
machine_apply_elf_rel: ABS64 0000000000000000->0000000011245370
sym: printf info: 12 other: 00 shndx: 1 value: 544 size: 90
sym: printf value: 11240544 addr: 1124012c
machine_apply_elf_rel: CALL26 9400000094000000->9400000094000106
sym: setup_arch info: 12 other: 00 shndx: 1 value: ea8 size: 4
sym: setup_arch value: 11240ea8 addr: 11240130
machine_apply_elf_rel: CALL26 9400000094000000->940000009400035e
sym: verify_sha256_digest info: 12 other: 00 shndx: 1 value: 0 size: f0
sym: verify_sha256_digest value: 11240000 addr: 11240134
machine_apply_elf_rel: CALL26 3400004094000000->3400004097ffffb3
sym: post_verification_setup_arch info: 12 other: 00 shndx: 1 value: ea4 size: 4
sym: post_verification_setup_arch value: 11240ea4 addr: 11240144
machine_apply_elf_rel: JUMP26 0000000014000000->0000000014000358
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 11245380 addr: 11240148
machine_apply_elf_rel: ABS64 0000000000000000->0000000011245380
sym: putchar info: 12 other: 00 shndx: 1 value: ea0 size: 4
sym: putchar value: 11240ea0 addr: 112401ac
machine_apply_elf_rel: CALL26 f94037a194000000->f94037a19400033d
sym: putchar info: 12 other: 00 shndx: 1 value: ea0 size: 4
sym: putchar value: 11240ea0 addr: 11240220
machine_apply_elf_rel: CALL26 910006f794000000->910006f794000320
sym: putchar info: 12 other: 00 shndx: 1 value: ea0 size: 4
sym: putchar value: 11240ea0 addr: 11240478
machine_apply_elf_rel: CALL26 9100073994000000->910007399400028a
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 11245392 addr: 112404b8
machine_apply_elf_rel: ABS64 0000000000000000->0000000011245392
sym: vsprintf info: 12 other: 00 shndx: 1 value: 150 size: 364
sym: vsprintf value: 11240150 addr: 11240538
machine_apply_elf_rel: CALL26 a8d07bfd94000000->a8d07bfd97ffff06
sym: vsprintf info: 12 other: 00 shndx: 1 value: 150 size: 364
sym: vsprintf value: 11240150 addr: 112405c8
machine_apply_elf_rel: CALL26 a8d17bfd94000000->a8d17bfd97fffee2
sym: purgatory info: 12 other: 00 shndx: 1 value: 120 size: 28
sym: purgatory value: 11240120 addr: 11240678
machine_apply_elf_rel: CALL26 5800001194000000->5800001197fffeaa
sym: arm64_kernel_entry info: 10 other: 00 shndx: 4 value: 120 size: 8
sym: arm64_kernel_entry value: 112454c8 addr: 1124067c
machine_apply_elf_rel: LD_PREL_LO19 5800000058000011->5800000058027271
sym: arm64_dtb_addr info: 10 other: 00 shndx: 4 value: 128 size: 8
sym: arm64_dtb_addr value: 112454d0 addr: 11240680
machine_apply_elf_rel: LD_PREL_LO19 aa1f03e158000000->aa1f03e158027280
sym: sha256_process info: 12 other: 00 shndx: 1 value: f1c size: 4134
sym: sha256_process value: 11240f1c addr: 112450bc
machine_apply_elf_rel: CALL26 d101029494000000->d101029497ffef98
sym: memcpy info: 12 other: 00 shndx: 1 value: 614 size: 20
sym: memcpy value: 11240614 addr: 11245118
machine_apply_elf_rel: JUMP26 b4fffc5814000000->b4fffc5817ffed3f
sym: memcpy info: 12 other: 00 shndx: 1 value: 614 size: 20
sym: memcpy value: 11240614 addr: 11245130
machine_apply_elf_rel: CALL26 aa1503e094000000->aa1503e097ffed39
sym: sha256_process info: 12 other: 00 shndx: 1 value: f1c size: 4134
sym: sha256_process value: 11240f1c addr: 1124513c
machine_apply_elf_rel: CALL26 cb1302d694000000->cb1302d697ffef78
sym: .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 112454d8 addr: 11245330
machine_apply_elf_rel: ABS64 0000000000000000->00000000112454d8
kexec_load: entry = 0x11240670 flags = 0xb70001
nr_segments = 5
segment[0].buf = 0xffff968d0010
segment[0].bufsz = 0xdf9200
segment[0].mem = 0xe880000
segment[0].memsz = 0x15f0000
segment[1].buf = 0xffff950e0010
segment[1].bufsz = 0x13b29e0
segment[1].mem = 0xfe70000
segment[1].memsz = 0x13c0000
segment[2].buf = 0x1115b440
segment[2].bufsz = 0x33d
segment[2].mem = 0x11230000
segment[2].memsz = 0x10000
segment[3].buf = 0x1115bb70
segment[3].bufsz = 0x5518
segment[3].mem = 0x11240000
segment[3].memsz = 0x10000
segment[4].buf = 0x11159ca0
segment[4].bufsz = 0x1000
segment[4].mem = 0x2e7f0000
segment[4].memsz = 0x10000
Regards,
Bhupesh
>
>
>> Regards,
>> Bhupesh
>>
>>
>> >> >
>> >> > Regards,
>> >> > Bhupesh
>> >> >
>> >> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> >> > >> via a kernel command line parameter, "memmap=".
>> >> > >>
>> >> > _______________________________________________
>> >> > kexec mailing list -- kexec at lists.fedoraproject.org
>> >> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* [PATCH 3/8] media: v4l2-async: simplify v4l2_async_subdev structure
From: Alexandre Belloni @ 2017-12-18 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <014b64d13c8b9d516afc3319a9de1a97b2a845de.1513625884.git.mchehab@s-opensource.com>
On 18/12/2017 at 17:53:57 -0200, Mauro Carvalho Chehab wrote:
> The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> match criteria requires just a device name.
>
> So, it doesn't make sense to enclose those into structs,
> as the criteria can go directly into the union.
>
> That makes easier to document it, as we don't need to document
> weird senseless structs.
>
> At drivers, this makes even clearer about the match criteria.
>
For atmel:
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/am437x/am437x-vpfe.c | 6 +++---
> drivers/media/platform/atmel/atmel-isc.c | 2 +-
> drivers/media/platform/atmel/atmel-isi.c | 2 +-
> drivers/media/platform/davinci/vpif_capture.c | 4 ++--
> drivers/media/platform/exynos4-is/media-dev.c | 4 ++--
> drivers/media/platform/pxa_camera.c | 2 +-
> drivers/media/platform/qcom/camss-8x16/camss.c | 2 +-
> drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
> drivers/media/platform/rcar_drif.c | 4 ++--
> drivers/media/platform/soc_camera/soc_camera.c | 2 +-
> drivers/media/platform/stm32/stm32-dcmi.c | 2 +-
> drivers/media/platform/ti-vpe/cal.c | 2 +-
> drivers/media/platform/xilinx/xilinx-vipp.c | 2 +-
> drivers/media/v4l2-core/v4l2-async.c | 16 ++++++++--------
> drivers/media/v4l2-core/v4l2-fwnode.c | 10 +++++-----
> drivers/staging/media/imx/imx-media-dev.c | 4 ++--
> include/media/v4l2-async.h | 8 ++------
> 17 files changed, 35 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c b/drivers/media/platform/am437x/am437x-vpfe.c
> index 0997c640191d..601ae6487617 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2304,8 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier *notifier,
> vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
>
> for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
> - if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
> - asd[i].match.fwnode.fwnode) {
> + if (vpfe->cfg->asd[i]->match.fwnode ==
> + asd[i].match.fwnode) {
> sdinfo = &vpfe->cfg->sub_devs[i];
> vpfe->sd[i] = subdev;
> vpfe->sd[i]->grp_id = sdinfo->grp_id;
> @@ -2510,7 +2510,7 @@ vpfe_get_pdata(struct platform_device *pdev)
> }
>
> pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
> + pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
> of_node_put(rem);
> }
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index 0c2635647f69..34676409ca08 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -2088,7 +2088,7 @@ static int isc_parse_dt(struct device *dev, struct isc_device *isc)
> subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
>
> subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - subdev_entity->asd->match.fwnode.fwnode =
> + subdev_entity->asd->match.fwnode =
> of_fwnode_handle(rem);
> list_add_tail(&subdev_entity->list, &isc->subdev_entities);
> }
> diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
> index e900995143a3..9958918e2449 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -1128,7 +1128,7 @@ static int isi_graph_parse(struct atmel_isi *isi, struct device_node *node)
> /* Remote node to connect */
> isi->entity.node = remote;
> isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - isi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> return 0;
> }
> }
> diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
> index e45916f69def..e1c273c8b9a6 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -1390,7 +1390,7 @@ static int vpif_async_bound(struct v4l2_async_notifier *notifier,
>
> for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
> struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i];
> - const struct fwnode_handle *fwnode = _asd->match.fwnode.fwnode;
> + const struct fwnode_handle *fwnode = _asd->match.fwnode;
>
> if (fwnode == subdev->fwnode) {
> vpif_obj.sd[i] = subdev;
> @@ -1595,7 +1595,7 @@ vpif_capture_get_pdata(struct platform_device *pdev)
> }
>
> pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
> + pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
> of_node_put(rem);
> }
>
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
> index 0ef583cfc424..78b48a1fa26c 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -456,7 +456,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
> }
>
> fmd->sensor[index].asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - fmd->sensor[index].asd.match.fwnode.fwnode = of_fwnode_handle(rem);
> + fmd->sensor[index].asd.match.fwnode = of_fwnode_handle(rem);
> fmd->async_subdevs[index] = &fmd->sensor[index].asd;
>
> fmd->num_sensors++;
> @@ -1364,7 +1364,7 @@ static int subdev_notifier_bound(struct v4l2_async_notifier *notifier,
>
> /* Find platform data for this sensor subdev */
> for (i = 0; i < ARRAY_SIZE(fmd->sensor); i++)
> - if (fmd->sensor[i].asd.match.fwnode.fwnode ==
> + if (fmd->sensor[i].asd.match.fwnode ==
> of_fwnode_handle(subdev->dev->of_node))
> si = &fmd->sensor[i];
>
> diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c
> index 305cf1cac210..f028084f0775 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2335,7 +2335,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
> asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> remote = of_graph_get_remote_port(np);
> if (remote) {
> - asd->match.fwnode.fwnode = of_fwnode_handle(remote);
> + asd->match.fwnode = of_fwnode_handle(remote);
> of_node_put(remote);
> } else {
> dev_notice(dev, "no remote for %pOF\n", np);
> diff --git a/drivers/media/platform/qcom/camss-8x16/camss.c b/drivers/media/platform/qcom/camss-8x16/camss.c
> index 390a42c17b66..05f06c98aa64 100644
> --- a/drivers/media/platform/qcom/camss-8x16/camss.c
> +++ b/drivers/media/platform/qcom/camss-8x16/camss.c
> @@ -341,7 +341,7 @@ static int camss_of_parse_ports(struct device *dev,
> }
>
> csd->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - csd->asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + csd->asd.match.fwnode = of_fwnode_handle(remote);
> }
>
> return notifier->num_subdevs;
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
> index 108d776f3265..f1fc7978d6d1 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -187,7 +187,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
> return -ENODEV;
>
> vin_dbg(vin, "Found digital subdevice %pOF\n",
> - to_of_node(vin->digital->asd.match.fwnode.fwnode));
> + to_of_node(vin->digital->asd.match.fwnode));
>
> vin->notifier.ops = &rvin_digital_notify_ops;
> ret = v4l2_async_notifier_register(&vin->v4l2_dev, &vin->notifier);
> diff --git a/drivers/media/platform/rcar_drif.c b/drivers/media/platform/rcar_drif.c
> index 63c94f4028a7..b2e080ef5391 100644
> --- a/drivers/media/platform/rcar_drif.c
> +++ b/drivers/media/platform/rcar_drif.c
> @@ -1107,7 +1107,7 @@ static int rcar_drif_notify_bound(struct v4l2_async_notifier *notifier,
> struct rcar_drif_sdr *sdr =
> container_of(notifier, struct rcar_drif_sdr, notifier);
>
> - if (sdr->ep.asd.match.fwnode.fwnode !=
> + if (sdr->ep.asd.match.fwnode !=
> of_fwnode_handle(subdev->dev->of_node)) {
> rdrif_err(sdr, "subdev %s cannot bind\n", subdev->name);
> return -EINVAL;
> @@ -1235,7 +1235,7 @@ static int rcar_drif_parse_subdevs(struct rcar_drif_sdr *sdr)
> return -EINVAL;
> }
>
> - sdr->ep.asd.match.fwnode.fwnode = fwnode;
> + sdr->ep.asd.match.fwnode = fwnode;
> sdr->ep.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> notifier->num_subdevs++;
>
> diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c
> index 916ff68b73d4..d13e2c5fb06f 100644
> --- a/drivers/media/platform/soc_camera/soc_camera.c
> +++ b/drivers/media/platform/soc_camera/soc_camera.c
> @@ -1517,7 +1517,7 @@ static int soc_of_bind(struct soc_camera_host *ici,
> if (!info)
> return -ENOMEM;
>
> - info->sasd.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + info->sasd.asd.match.fwnode = of_fwnode_handle(remote);
> info->sasd.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> info->subdev = &info->sasd.asd;
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index ac4c450a6c7d..9460b3080dca 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1520,7 +1520,7 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
> /* Remote node to connect */
> dcmi->entity.node = remote;
> dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - dcmi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> return 0;
> }
> }
> diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c
> index 719ed1d79957..d1febe5baa6d 100644
> --- a/drivers/media/platform/ti-vpe/cal.c
> +++ b/drivers/media/platform/ti-vpe/cal.c
> @@ -1702,7 +1702,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst)
> goto cleanup_exit;
> }
> asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - asd->match.fwnode.fwnode = of_fwnode_handle(sensor_node);
> + asd->match.fwnode = of_fwnode_handle(sensor_node);
>
> remote_ep = of_graph_get_remote_endpoint(ep_node);
> if (!remote_ep) {
> diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c b/drivers/media/platform/xilinx/xilinx-vipp.c
> index f4c3e48ed2c0..6bb28cd49dae 100644
> --- a/drivers/media/platform/xilinx/xilinx-vipp.c
> +++ b/drivers/media/platform/xilinx/xilinx-vipp.c
> @@ -387,7 +387,7 @@ static int xvip_graph_parse_one(struct xvip_composite_device *xdev,
>
> entity->node = remote;
> entity->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - entity->asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + entity->asd.match.fwnode = of_fwnode_handle(remote);
> list_add_tail(&entity->list, &xdev->entities);
> xdev->num_subdevs++;
> }
> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> index e5acfab470a5..2b08d03b251d 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -68,12 +68,12 @@ static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> static bool match_devname(struct v4l2_subdev *sd,
> struct v4l2_async_subdev *asd)
> {
> - return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
> + return !strcmp(asd->match.device_name, dev_name(sd->dev));
> }
>
> static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> {
> - return sd->fwnode == asd->match.fwnode.fwnode;
> + return sd->fwnode == asd->match.fwnode;
> }
>
> static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> @@ -319,7 +319,7 @@ static bool __v4l2_async_notifier_fwnode_has_async_subdev(
> if (asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
> continue;
>
> - if (asd->match.fwnode.fwnode == fwnode)
> + if (asd->match.fwnode == fwnode)
> return true;
> }
>
> @@ -330,7 +330,7 @@ static bool __v4l2_async_notifier_fwnode_has_async_subdev(
> if (sd->asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
> continue;
>
> - if (sd->asd->match.fwnode.fwnode == fwnode)
> + if (sd->asd->match.fwnode == fwnode)
> return true;
> }
>
> @@ -355,8 +355,8 @@ static bool v4l2_async_notifier_fwnode_has_async_subdev(
> struct v4l2_async_subdev *other_asd = notifier->subdevs[j];
>
> if (other_asd->match_type == V4L2_ASYNC_MATCH_FWNODE &&
> - asd->match.fwnode.fwnode ==
> - other_asd->match.fwnode.fwnode)
> + asd->match.fwnode ==
> + other_asd->match.fwnode)
> return true;
> }
>
> @@ -395,7 +395,7 @@ static int __v4l2_async_notifier_register(struct v4l2_async_notifier *notifier)
> break;
> case V4L2_ASYNC_MATCH_FWNODE:
> if (v4l2_async_notifier_fwnode_has_async_subdev(
> - notifier, asd->match.fwnode.fwnode, i)) {
> + notifier, asd->match.fwnode, i)) {
> dev_err(dev,
> "fwnode has already been registered or in notifier's subdev list\n");
> ret = -EEXIST;
> @@ -510,7 +510,7 @@ void v4l2_async_notifier_cleanup(struct v4l2_async_notifier *notifier)
>
> switch (asd->match_type) {
> case V4L2_ASYNC_MATCH_FWNODE:
> - fwnode_handle_put(asd->match.fwnode.fwnode);
> + fwnode_handle_put(asd->match.fwnode);
> break;
> default:
> WARN_ON_ONCE(true);
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c
> index fb72c7ac04d4..d630640642ee 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -359,9 +359,9 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
> return -ENOMEM;
>
> asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - asd->match.fwnode.fwnode =
> + asd->match.fwnode =
> fwnode_graph_get_remote_port_parent(endpoint);
> - if (!asd->match.fwnode.fwnode) {
> + if (!asd->match.fwnode) {
> dev_warn(dev, "bad remote port parent\n");
> ret = -EINVAL;
> goto out_err;
> @@ -393,7 +393,7 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
> return 0;
>
> out_err:
> - fwnode_handle_put(asd->match.fwnode.fwnode);
> + fwnode_handle_put(asd->match.fwnode);
> kfree(asd);
>
> return ret == -ENOTCONN ? 0 : ret;
> @@ -566,7 +566,7 @@ static int v4l2_fwnode_reference_parse(
> }
>
> notifier->subdevs[notifier->num_subdevs] = asd;
> - asd->match.fwnode.fwnode = args.fwnode;
> + asd->match.fwnode = args.fwnode;
> asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> notifier->num_subdevs++;
> }
> @@ -853,7 +853,7 @@ static int v4l2_fwnode_reference_parse_int_props(
> }
>
> notifier->subdevs[notifier->num_subdevs] = asd;
> - asd->match.fwnode.fwnode = fwnode;
> + asd->match.fwnode = fwnode;
> asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> notifier->num_subdevs++;
> }
> diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
> index 2800700482d6..f7ed5f506fa9 100644
> --- a/drivers/staging/media/imx/imx-media-dev.c
> +++ b/drivers/staging/media/imx/imx-media-dev.c
> @@ -48,7 +48,7 @@ find_async_subdev(struct imx_media_dev *imxmd,
> asd = &imxasd->asd;
> switch (asd->match_type) {
> case V4L2_ASYNC_MATCH_FWNODE:
> - if (fwnode && asd->match.fwnode.fwnode == fwnode)
> + if (fwnode && asd->match.fwnode == fwnode)
> return asd;
> break;
> case V4L2_ASYNC_MATCH_DEVNAME:
> @@ -104,7 +104,7 @@ int imx_media_add_async_subdev(struct imx_media_dev *imxmd,
>
> if (fwnode) {
> asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - asd->match.fwnode.fwnode = fwnode;
> + asd->match.fwnode = fwnode;
> } else {
> asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
> asd->match.device_name.name = devname;
> diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
> index 6152434cbe82..a010af5134b2 100644
> --- a/include/media/v4l2-async.h
> +++ b/include/media/v4l2-async.h
> @@ -58,12 +58,8 @@ enum v4l2_async_match_type {
> struct v4l2_async_subdev {
> enum v4l2_async_match_type match_type;
> union {
> - struct {
> - struct fwnode_handle *fwnode;
> - } fwnode;
> - struct {
> - const char *name;
> - } device_name;
> + struct fwnode_handle *fwnode;
> + const char *device_name;
> struct {
> int adapter_id;
> unsigned short address;
> --
> 2.14.3
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] of: build dbts with symbols when CONFIG_OF_OVERLAY is set
From: Frank Rowand @ 2017-12-18 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05291157-a1dc-db84-e453-c43945c1da07@gmail.com>
On 12/16/17 09:25, Andre Heider wrote:
> Hi Frank,
>
> On 15/12/17 22:06, Frank Rowand wrote:
>> On 12/14/17 07:12, Andre Heider wrote:
>>> The overlay feature requires the base dtb to be built with symbols, so
>>> lets build the dtbs with symbols when overlay support was explicitly
>>> enabled.
>>>
>>> With CONFIG_OF_ALL_DTBS on ARCH=arm the 989 dtb files grow about ~38% on
>>> average.
>>>
>>> Totals in bytes with the 3 biggest ones:
>>>
>>> Before:
>>> ????90471??? arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>> ????90521??? arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>> ????92639??? arch/arm/boot/dts/dra7-evm.dtb
>>> ????25731296??? total
>>>
>>> After:
>>> ????133203??? arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>> ????133237??? arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>> ????134545??? arch/arm/boot/dts/dra7-evm.dtb
>>> ????35464440??? total
>>>
>>> Signed-off-by: Andre Heider <a.heider@gmail.com>
>>> ---
>>>
>>> Hi,
>>>
>>> while playing around with overlays I noticed that I needed to rebuilt
>>> my distro's device trees because they didn't come with symbols.
>>>
>>> Is that for a reason, maybe the not so minor increase in size?
>>
>> Yes, size is the issue.
>>
>>
>>>
>>> Thanks,
>>> Andre
>>>
>>> ? drivers/of/unittest-data/Makefile | 7 -------
>>> ? scripts/Makefile.lib????????????? | 5 +++++
>>> ? 2 files changed, 5 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
>>> index 32389acfa616..b65061013512 100644
>>> --- a/drivers/of/unittest-data/Makefile
>>> +++ b/drivers/of/unittest-data/Makefile
>>> @@ -15,13 +15,6 @@ targets += overlay.dtb overlay.dtb.S
>>> ? targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
>>> ? targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S
>>> ? targets += overlay_base.dtb overlay_base.dtb.S
>>> -
>>> -# enable creation of __symbols__ node
>>> -DTC_FLAGS_overlay := -@
>>> -DTC_FLAGS_overlay_bad_phandle := -@
>>> -DTC_FLAGS_overlay_bad_symbol := -@
>>> -DTC_FLAGS_overlay_base := -@
>>> -
>>> ? endif
>>> ? ? .PRECIOUS: \
>>
>> No.? The unittests require these to be set unconditionally.
>>
>>
>>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>>> index 1ca4dcd2d500..c7ba4aa8a07a 100644
>>> --- a/scripts/Makefile.lib
>>> +++ b/scripts/Makefile.lib
>>> @@ -278,6 +278,11 @@ DTC_FLAGS += -Wnode_name_chars_strict \
>>> ????? -Wproperty_name_chars_strict
>>> ? endif
>>> ? +ifeq ($(CONFIG_OF_OVERLAY),y)
>>> +# enable creation of __symbols__ node
>>> +DTC_FLAGS += -@
>>> +endif
>>> +
>>> ? DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>>> ? ? # Generate an assembly file to wrap the output of the device tree compiler
>>>
>>
>> Not needed.? Instead set DTC_FLAGS in the make command.? For example:
>>
>> ??? DTC_FLAGS=-@ make qcom-apq8074-dragonboard.dtb
>>
>> There are a few architecture Makefiles that need to be fixed to not unconditionally
>> set DTC_FLAGS.
>
> Rebuilding the dts files manually with symbols isn't the problem. The
> idea was to enable it with a switch which distros simply can flip.
>
> Passing DTC_FLAGS to `make` would work too I guess, but on multi
> platform builds that's still the same issue if there're boards which
> can't handle that because of the size increase.
>
> Would a solution which enables symbols per family work? E.g.
> CONFIG_MACH_SUN7I chooses to use -@ because it can handle it.
>
> Thanks,
> Andre
Making it easy for distros to increase the size of .dtb files is
not the correct answer. We are trying to decrease the footprint
of devicetree, not increase it.
-Frank
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-18 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218112208.0057634d@xps13>
Hi Miquel,
On Mon, Dec 18, 2017 at 11:22:08AM +0100, Miquel RAYNAL wrote:
> I fixed two problems happening during read/write of 2kiB page NAND
> chips, I am quite confident this would solve the issues you report
> here. Could you please give it a try?
So I just tested right now, and good news, it now works pretty fine
here, and my jffs2 properly mounted (without requiring Boris' fix
for oob) :
# dmesg|grep -i nand
[ 0.770395] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[ 0.775474] nand: AMD/Spansion S34ML01G2
[ 0.778103] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.794080] 10 ofpart partitions found on MTD device pxa3xx_nand-0
[ 0.798975] Creating 10 MTD partitions on "pxa3xx_nand-0":
[ 3.245034] jffs2: version 2.2. (NAND) (SUMMARY) \xffffffc2\xffffffa9 2001-2006 Red Hat, Inc.
I was first surprized seeing this "pxa3xx_nand-0" still appearing until I
realized that it's how it's called in the device tree :-)
Cheers,
Willy
^ permalink raw reply
* [PATCH 2/2] ARM: dts: r8a7745: move timer node out of bus
From: Simon Horman @ 2017-12-18 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218215044.13088-1-horms+renesas@verge.net.au>
The timer node does not have any register properties and thus shouldn't be
placed on the bus.
This problem is flagged by the compiler as follows:
$ make dtbs W=1
...
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
DTC arch/arm/boot/dts/r8a7745-sk-rzg1e.dtb
arch/arm/boot/dts/r8a7745-sk-rzg1e.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7745.dtsi | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 65d92076bdde..612de9eeb7e2 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -247,18 +247,6 @@
resets = <&cpg 407>;
};
- timer {
- compatible = "arm,armv7-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
- IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
- IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
- IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
- IRQ_TYPE_LEVEL_LOW)>;
- };
-
cpg: clock-controller at e6150000 {
compatible = "renesas,r8a7745-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
@@ -1143,6 +1131,14 @@
};
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
/* External USB clock - can be overridden by the board */
usb_extal_clk: usb_extal {
compatible = "fixed-clock";
--
2.11.0
^ permalink raw reply related
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