* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Xie XiuQi @ 2018-06-19 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmce60y3.fsf@e105922-lin.cambridge.arm.com>
Hi Punit,
On 2018/6/14 1:39, Punit Agrawal wrote:
> Punit Agrawal <punit.agrawal@arm.com> writes:
>
>
> [...]
>
>>
>> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end
>> up returning the original node in the fallback path.
>>
>> Xie, does the below patch help? I can submit a proper patch if this
>> fixes the issue for you.
>>
>> -- >8 --
>> Subject: [PATCH] arm64/numa: Enable memoryless numa nodes
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> ---
>> arch/arm64/Kconfig | 4 ++++
>> arch/arm64/mm/numa.c | 2 ++
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index eb2cf4938f6d..5317e9aa93ab 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -756,6 +756,10 @@ config USE_PERCPU_NUMA_NODE_ID
>> def_bool y
>> depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> + def_bool y
>> + depends on NUMA
>> +
>> config HAVE_SETUP_PER_CPU_AREA
>> def_bool y
>> depends on NUMA
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index dad128ba98bf..c699dcfe93de 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -73,6 +73,8 @@ EXPORT_SYMBOL(cpumask_of_node);
>> static void map_cpu_to_node(unsigned int cpu, int nid)
>> {
>> set_cpu_numa_node(cpu, nid);
>> + set_numa_mem(local_memory_node(nid));
>
> Argh, this should be
>
> set_cpu_numa_mem(cpu, local_memory_node(nid));
>
> There is not guarantee that map_cpu_to_node() will be called on the
> local cpu.
>
> Hanjun, Xie - can you try with the update please?
I've tested this patch, but it does not help.
The boot message is attached.
I tested on a arm board with 128 cores 4 numa nodes, but I set CONFIG_NR_CPUS=72.
Then node 3 is not be created, because node 3 has no memory, and no cpu.
But some pci device may related to node 3, which be set in ACPI table.
165 /* Interface called from ACPI code to setup PCI host controller */
166 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
167 {
168 int node = acpi_get_node(root->device->handle);
169 struct acpi_pci_generic_root_info *ri;
170 struct pci_bus *bus, *child;
171 struct acpi_pci_root_ops *root_ops;
172
// this node may be not created.
177 ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
178 if (!ri)
179 return NULL;
180
181 root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node);
182 if (!root_ops) {
183 kfree(ri);
184 return NULL;
185 }
186
187 ri->cfg = pci_acpi_setup_ecam_mapping(root);
188 if (!ri->cfg) {
189 kfree(ri);
190 kfree(root_ops);
191 return NULL;
192 }
>
> Thanks,
> Punit
>
>> +
>> if (nid >= 0)
>> cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
>> }
>
> .
>
--
Thanks,
Xie XiuQi
-------------- next part --------------
[ 0.000000] Booting Linux on physical CPU 0x0000030000 [0x480fd010]
[ 0.000000] Linux version 4.16.0-rc1-00491-g204a6cc-dirty (xiexiuqi at localhost.localdomain) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05)) #17 SMP PREEMPT Tue Jun 19 16:33:32 CST 2018
[ 0.000000] earlycon: pl11 at MMIO32 0x0000000094080000 (options '')
[ 0.000000] bootconsole [pl11] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.60 by EDK II
[ 0.000000] efi: SMBIOS 3.0=0x3eb60000 ACPI 2.0=0x39710000 MEMATTR=0x3b106418
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x0000000039710000 000024 (v02 HISI )
[ 0.000000] ACPI: XSDT 0x0000000039700000 000074 (v01 HISI HIP08 00000000 01000013)
[ 0.000000] ACPI: FACP 0x0000000039630000 000114 (v06 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: DSDT 0x00000000395C0000 006A1A (v02 HISI HIP08 00000000 INTL 20170929)
[ 0.000000] ACPI: GTDT 0x0000000039620000 000060 (v02 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: DBG2 0x0000000039610000 00005A (v00 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: MCFG 0x0000000039600000 00003C (v01 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: SLIT 0x00000000395F0000 00003C (v01 HISI HIP07 00000000 INTL 20151124)
[ 0.000000] ACPI: SRAT 0x00000000395E0000 0009C0 (v03 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: APIC 0x00000000395D0000 00286C (v04 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: IORT 0x00000000395B0000 00110C (v00 HISI HIP08 00000000 INTL 20170929)
[ 0.000000] ACPI: PPTT 0x00000000311F0000 0037D0 (v01 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: SPMI 0x00000000311E0000 000041 (v05 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30000 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30001 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30002 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30003 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30100 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30101 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30102 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30103 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30200 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30201 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30202 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30203 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30300 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30301 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30302 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30303 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30400 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30401 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30402 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30403 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30500 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30501 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30502 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30503 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30600 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30601 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30602 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30603 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30700 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30701 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30702 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30703 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10000 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10001 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10002 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10003 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10100 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10101 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10102 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10103 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10200 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10201 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10202 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10203 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10300 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10301 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10302 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10303 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10400 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10401 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10402 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10403 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10500 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10501 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10502 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10503 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10600 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10601 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10602 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10603 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10700 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10701 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10702 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10703 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70000 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70001 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70002 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70003 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70100 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70101 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70102 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70103 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: cpu_to_node_map[72] is too small, may not be able to use all cpus
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x2080000000-0x23ffffffff]
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[ 0.000000] ACPI: SRAT: Node 2 PXM 2 [mem 0x402000000000-0x4023ffffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x23ffffe780-0x23ffffffff]
[ 0.000000] NUMA: Initmem setup node 1 [<memory-less node>]
[ 0.000000] NUMA: NODE_DATA [mem 0x4023fffed780-0x4023fffeefff]
[ 0.000000] NUMA: NODE_DATA(1) on node 2
[ 0.000000] NUMA: NODE_DATA [mem 0x4023fffebf00-0x4023fffed77f]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00004023ffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003942ffff]
[ 0.000000] node 0: [mem 0x0000000039430000-0x000000003956ffff]
[ 0.000000] node 0: [mem 0x0000000039570000-0x000000003963ffff]
[ 0.000000] node 0: [mem 0x0000000039640000-0x00000000396fffff]
[ 0.000000] node 0: [mem 0x0000000039700000-0x000000003971ffff]
[ 0.000000] node 0: [mem 0x0000000039720000-0x0000000039b6ffff]
[ 0.000000] node 0: [mem 0x0000000039b70000-0x000000003eb5ffff]
[ 0.000000] node 0: [mem 0x000000003eb60000-0x000000003eb8ffff]
[ 0.000000] node 0: [mem 0x000000003eb90000-0x000000003fbfffff]
[ 0.000000] node 0: [mem 0x0000002080000000-0x00000023ffffffff]
[ 0.000000] node 2: [mem 0x0000402000000000-0x00004023ffffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000023ffffffff]
[ 0.000000] Could not find start_pfn for node 1
[ 0.000000] Initmem setup node 1 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Initmem setup node 2 [mem 0x0000402000000000-0x00004023ffffffff]
[ 0.000000] psci: probing for conduit method from ACPI.
[ 0.000000] psci: PSCIv1.0 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.0
[ 0.000000] random: fast init done
[ 0.000000] percpu: Embedded 24 pages/cpu @ (ptrval) s59432 r8192 d30680 u98304
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] Built 3 zonelists, mobility grouping on. Total pages: 7998480
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: earlycon=pl011,mmio32,0x94080000 console=ttyAMA0,115200 initrd=minifs.cpio.gz acpi=force
[ 0.000000] log_buf_len individual max cpu contribution: 4096 bytes
[ 0.000000] log_buf_len total cpu_extra contributions: 290816 bytes
...
[ 0.141182] Platform MSI: ITS at 0x400202100000 domain created
[ 0.146793] PCI/MSI: ITS at 0x202100000 domain created
[ 0.151690] PCI/MSI: ITS at 0x400202100000 domain created
[ 0.156906] Remapping and enabling EFI services.
[ 0.161562] EFI remap 0x0000000039430000 => (ptrval)
[ 0.167431] EFI remap 0x0000000039480000 => (ptrval)
[ 0.173299] EFI remap 0x00000000394d0000 => (ptrval)
[ 0.179167] EFI remap 0x0000000039520000 => (ptrval)
[ 0.185037] EFI remap 0x0000000039650000 => (ptrval)
[ 0.190905] EFI remap 0x00000000396b0000 => (ptrval)
[ 0.196773] EFI remap 0x0000000039720000 => (ptrval)
[ 0.202639] EFI remap 0x0000000039770000 => (ptrval)
[ 0.208505] EFI remap 0x00000000397c0000 => (ptrval)
[ 0.214371] EFI remap 0x0000000039810000 => (ptrval)
[ 0.220236] EFI remap 0x0000000039860000 => (ptrval)
[ 0.226103] EFI remap 0x00000000398b0000 => (ptrval)
[ 0.231973] EFI remap 0x0000000039900000 => (ptrval)
[ 0.237840] EFI remap 0x0000000039970000 => (ptrval)
[ 0.243710] EFI remap 0x00000000399c0000 => (ptrval)
[ 0.249577] EFI remap 0x0000000039a10000 => (ptrval)
[ 0.255445] EFI remap 0x0000000039a60000 => (ptrval)
[ 0.261313] EFI remap 0x0000000039ab0000 => (ptrval)
[ 0.267184] EFI remap 0x0000000039b00000 => (ptrval)
[ 0.273047] EFI remap 0x000000003eb60000 => (ptrval)
[ 0.278907] EFI remap 0x0000000080000000 => (ptrval)
[ 0.284766] EFI remap 0x0000000202020000 => (ptrval)
[ 0.290626] EFI remap 0x0000000204000000 => (ptrval)
[ 0.296487] EFI remap 0x0000000206200000 => (ptrval)
[ 0.318359] smp: Bringing up secondary CPUs ...
[ 0.422473] Detected VIPT I-cache on CPU1
[ 0.422481] GICv3: CPU1: found redistributor 30001 region 1:0x00000000aa140000
[ 0.422502] CPU1: using LPI pending table @0x00000023ee480000
[ 0.422543] CPU1: Booted secondary processor 0x0000030001 [0x480fd010]
[ 0.522109] Detected VIPT I-cache on CPU2
[ 0.522115] GICv3: CPU2: found redistributor 30002 region 2:0x00000000aa180000
[ 0.522135] CPU2: using LPI pending table @0x00000023ee4b0000
[ 0.522175] CPU2: Booted secondary processor 0x0000030002 [0x480fd010]
[ 0.621751] Detected VIPT I-cache on CPU3
...
[ 7.328992] CPU70: Booted secondary processor 0x0000070102 [0x480fd010]
[ 7.435880] Detected VIPT I-cache on CPU71
[ 7.435931] GICv3: CPU71: found redistributor 70103 region 71:0x00004000aa2c0000
[ 7.435958] CPU71: using LPI pending table @0x00000023ed340000
[ 7.436037] CPU71: Booted secondary processor 0x0000070103 [0x480fd010]
[ 7.436131] smp: Brought up 3 nodes, 72 CPUs
[ 9.146250] SMP: Total of 72 processors activated.
[ 9.151067] CPU features: detected feature: GIC system register CPU interface
[ 9.158247] CPU features: detected feature: Privileged Access Never
...
[ 11.535050] pci 0000:74:02.0: BAR 5: assigned [mem 0xa2000000-0xa2007fff]
[ 11.541829] pci 0000:74:03.0: BAR 5: assigned [mem 0xa2008000-0xa2008fff]
[ 11.548610] pci 0000:75:00.0: BAR 2: assigned [mem 0x144000000-0x1443fffff 64bit pref]
[ 11.556518] pci 0000:75:00.0: BAR 9: assigned [mem 0x144400000-0x1447effff 64bit pref]
[ 11.564426] pci 0000:74:00.0: PCI bridge to [bus 75]
[ 11.569382] pci 0000:74:00.0: bridge window [mem 0x144000000-0x1447fffff 64bit pref]
[ 11.577332] ACPI: PCI Root Bridge [PCI6] (domain 0000 [bus 80-9f])
[ 11.583505] acpi PNP0A08:06: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 11.591850] acpi PNP0A08:06: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 11.599851] CPU002: pci_acpi_scan_root: 175 node 3, online 0
[ 11.605503] Unable to handle kernel paging request at virtual address 00001530
[ 11.612712] Mem abort info:
[ 11.615492] ESR = 0x96000004
[ 11.618534] Exception class = DABT (current EL), IL = 32 bits
[ 11.624440] SET = 0, FnV = 0
[ 11.627481] EA = 0, S1PTW = 0
[ 11.630608] Data abort info:
[ 11.633476] ISV = 0, ISS = 0x00000004
[ 11.637299] CM = 0, WnR = 0
[ 11.640254] [0000000000001530] user address but active_mm is swapper
[ 11.646594] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 11.652154] Modules linked in:
[ 11.655198] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc1-00491-g204a6cc-dirty #17
[ 11.663361] Hardware name: Huawei, 06/02/2018
[ 11.673174] pstate: 20c00089 (nzCv daIf +PAN +UAO)
[ 11.677955] pc : ___slab_alloc+0x60/0x590
[ 11.681952] lr : __slab_alloc.isra.24+0x58/0x70
[ 11.686469] sp : ffff00000981b870
[ 11.689771] x29: ffff00000981b870 x28: ffffc023eb8d8000
[ 11.695071] x27: ffff7e008fafd600 x26: ffff8023f0407c00
[ 11.700372] x25: ffff8023f0407c00 x24: ffff000008098da0
[ 11.705671] x23: 0000000000000003 x22: 00000000014080c0
[ 11.710971] x21: 0000000000000000 x20: 0000000000000003
[ 11.716271] x19: ffff8023f0b40870 x18: ffffffffffffffff
[ 11.721571] x17: 0000000000000000 x16: 000000000001c200
[ 11.726871] x15: ffff000009423b88 x14: ffff00008958c94f
[ 11.732171] x13: ffff00000958c95d x12: ffff00000943e858
[ 11.737471] x11: ffff00000943e000 x10: 0000000005f5e0ff
[ 11.742771] x9 : 00000000ffffffd0 x8 : 65646f6e20353731
[ 11.748071] x7 : 203a746f6f725f6e x6 : 00000000000002e8
[ 11.753371] x5 : 000000000000000a x4 : ffff8023f0b40870
[ 11.758670] x3 : ffff000008098da0 x2 : 0000000000000003
[ 11.763970] x1 : 0000000000000000 x0 : 0000000000000000
[ 11.769271] Process swapper/0 (pid: 1, stack limit = 0x00000000b21a776c)
[ 11.775958] Call trace:
[ 11.778392] ___slab_alloc+0x60/0x590
[ 11.782041] __slab_alloc.isra.24+0x58/0x70
[ 11.786212] kmem_cache_alloc_node+0xe0/0x240
[ 11.790556] pci_acpi_scan_root+0xb0/0x270
[ 11.794642] acpi_pci_root_add+0x29c/0x498
[ 11.798726] acpi_bus_attach+0x104/0x210
[ 11.802635] acpi_bus_attach+0xa4/0x210
[ 11.806458] acpi_bus_attach+0xa4/0x210
[ 11.810282] acpi_bus_scan+0x4c/0xb0
[ 11.813846] acpi_scan_init+0xec/0x24c
[ 11.817582] acpi_init+0x300/0x36c
[ 11.820972] do_one_initcall+0x50/0x158
[ 11.824797] kernel_init_freeable+0x188/0x228
[ 11.829141] kernel_init+0x10/0x100
[ 11.832617] ret_from_fork+0x10/0x18
[ 11.836181] Code: 90009081 93407e82 912ec021 f8627821 (f94a9821)
[ 11.842316] ---[ end trace 6b7476446f4b95ab ]---
[ 11.846936] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 11.846936]
[ 11.856079] SMP: stopping secondary CPUs
[ 11.860027] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 11.860027]
^ permalink raw reply
* [PATCHv3 06/19] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Catalin Marinas @ 2018-06-19 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-7-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:57PM +0100, Mark Rutland wrote:
> In subsequent patches, we'll want to make use of sve_user_enable() and
> sve_user_disable() outside of kernel/fpsimd.c. Let's move these to
> <asm/fpsimd.h> where we can make use of them.
>
> To avoid ifdeffery in sequences like:
>
> if (system_supports_sve() && some_condition
> sve_user_disable();
>
> ... empty stubs are provided when support for SVE is not enabled. Note
> that system_supports_sve() contains as IS_ENABLED(CONFIG_ARM64_SVE), so
> the sve_user_disable() call should be optimized away entirely when
> CONFIG_ARM64_SVE is not selected.
>
> To ensure that this is the case, the stub definitions contain a
> BUILD_BUG(), as we do for other stubs for which calls should always be
> optimized away when the relevant config option is not selected.
>
> At the same time, the include list of <asm/fpsimd.h> is sorted while
> adding <asm/sysreg.h>.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-19 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0d40351-8d78-fd69-cc87-d5ea5eaabd2a@arm.com>
Hi James,
On Tue, Jun 19, 2018 at 4:56 PM, James Morse <james.morse@arm.com> wrote:
> Hi Bhupesh,
>
> On 19/06/18 11:37, Bhupesh Sharma wrote:
>> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.morse@arm.com> wrote:
>>> On 19/06/18 10:57, Jin, Yanjiang wrote:
>>>>> -----Original Message-----
>>>>> From: Will Deacon [mailto:will.deacon at arm.com]
>>>>> Sent: 2018?6?19? 17:41
>>>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>>>>> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
>>>>> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
>>>>> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
>>>>> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
>>>>> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
>>>>> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
>>>>> kernel at lists.infradead.org>
>>>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
>>>>> linear region
>
>>>>>>>> It is hard to know all above in kexec-tools now. Originally I
>>>>>>>> planned to read memstart_addr's value from "/dev/mem", but someone
>>>>>>>> thought not all Kernels enable "/dev/mem", we'd better find a more
>>>>>>>> generic approach. So we want to get some suggestions from ARM kernel
>>>>> community.
>>>>>>>> Can we export this variable in Kernel side through sysconf() or
>>>>>>>> other similar methods? Or someone can provide an effect way to get
>>>>>>>> memstart_addr's value?
>>>>>>>
>>>>>>> I thought the suggestion from James was to expose this via an ELF
>>>>>>> NOTE in kcore and vmcore (or in the header directly if that's possible, but I'm
>>>>> not sure about it)?
>>>>>>
>>>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a
>>>>>> must-have, so we can't depend on it.
>>>>>
>>>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
>>>>>
>>>>>> On the other hand, phys_to_virt() is called during generating vmcore
>>>>>> in Kexec-tools, vmcore also can't help this issue.
>>>>>
>>>>> I don't understand this part. If you have the vmcore in your hand, why can't you
>>>>> grok the pv offset from the note and use that in phys_to_virt()?
>>>>
>>>> It is a chicken-and-egg issue.
>>>> phys_to virt() is for crashdump setup. To generate vmcore, we must call
>>>> phys_to_virt(). At this point, no vmcore exists.
>>>
>>> Its needed for the parts of the ELF header that kexec-tools generates at kdump
>>> load time?
>>>
>>> So adding this pv_offset to the key=value data crash_save_vmcoreinfo_init()
>>> saves isn't available early enough?
>
>> Yes, one case where it is not actually available early enough for
>> makedumpfile usage is if we are determining the PT_NOTE contents from
>> the '/proc/kcore' on a 'live' system
>
>> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len)
>>
>> {
>>
>> <snip..>
>> kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET;
>>
>> }
>
> You are trying to read the vmcoreinfo through /proc/kcore given knowledge of its
> physical address.
>
> I'm suggesting adding the contents of vmcoreinfo as a PT_NOTE section of
> /proc/kcore's ELF header. No special knowledge necessary, any elf-parser should
> be able to dump the values.
>
>
>> Now the problem at hand is to determine the offset at which the
>> pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume
>> that when you mentioned above and earlier about adding this pair to
>> the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we
>> can have 'n' number of PT_LOAD segments.
>
> It looks like there is already a NOTE section with core info in there:
> | # readelf -l /proc/kcore
> |
> | Elf file type is CORE (Core file)
> | Entry point 0x0
> | There are 16 program headers, starting at offset 64
> |
> | Program Headers:
> | Type Offset VirtAddr PhysAddr
> | FileSiz MemSiz Flags Align
> | NOTE 0x00000000000003c0 0x0000000000000000 0x0000000000000000
> | 0x0000000000001114 0x0000000000000000 0x0
>
> I assume we can add more notes without breaking the existing user...
>
> (and it looks like there are some broken __pa(kernel symbol) users in there.
Thanks for your inputs.
I am working on fixes on the above lines for kernel and user-space
tools (like makedumpfile, crash-utility and kexec-tools).
I will post some RFC patches on the same lines (or come back in case I
get stuck somewhere) shortly.
Thanks,
Bhupesh
^ permalink raw reply
* [Dev] [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Mark Brown @ 2018-06-19 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619111018.r3m35g4ei6625pqz@holly.lan>
On Tue, Jun 19, 2018 at 12:10:18PM +0100, Daniel Thompson wrote:
> On Mon, Jun 18, 2018 at 09:45:51AM +0200, Linus Walleij wrote:
> > - I am especially curious about input from Andy and Mika from
> > the Intel/ACPI camp on what they have seen for non-discoverable
> > plug-in boards. Does this problem even exist in the Intel
> > world, or not...
> I'm also interested in the "what about ACPI" question?
> Using C makes describing a board in ACPI fairly easy. AFAICT allocating
> IDs to a board rather than its included components is fairly natural for
> ACPI.
Yes, they have this problem - they have plug in modules on for example
the minnowboard and some of their other reference platforms. They have
overlays working for ACPI, these have their own problems in that they
don't appear to have the equivalent of DMI data (at least the patches
people are sending indicates that they don't) which is unfortuate as the
idiomatic thing for ACPI is as you say to key huge chunks of data of
quirk tables based on the DMI information for their boards.
They don't to my knowledge have generic connectors or anything like
that, it's just patches to the base ACPI.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/fed9da48/attachment-0001.sig>
^ permalink raw reply
* [PATCHv3 02/19] arm64: move SCTLR_EL{1,2} assertions to <asm/sysreg.h>
From: Mark Rutland @ 2018-06-19 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-3-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:53PM +0100, Mark Rutland wrote:
> Currently we assert that the SCTLR_EL{1,2}_{SET,CLEAR} bits are
> self-consistent with an assertion in config_sctlr_el1(). This is a bit
> unusual, since config_sctlr_el1() doesn't make use of these definitions,
> and is far away from the definitions themselves.
>
> We can use the CPP #error directive to have equivalent assertions in
> <asm/sysreg.h>, next to the definitions of the set/clear bits, which is
> a bit clearer and simpler.
>
> At the same time, lets fill in the upper 32 bits for both registers in
> their repsective RES0 definitions. This could be a little nicer with
Typo: s/repsective/respective/
I've fixed that up locally.
Mark.
^ permalink raw reply
* [PATCHv3 03/19] arm64: introduce sysreg_clear_set()
From: Marc Zyngier @ 2018-06-19 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-4-mark.rutland@arm.com>
On 18/06/18 13:02, Mark Rutland wrote:
> Currently we have a couple of helpers to manipulate bits in particular
> sysregs:
>
> * config_sctlr_el1(u32 clear, u32 set)
>
> * change_cpacr(u64 val, u64 mask)
>
> The parameters of these differ in naming convention, order, and size,
> which is unfortunate. They also differ slightly in behaviour, as
> change_cpacr() skips the sysreg write if the bits are unchanged, which
> is a useful optimization when sysreg writes are expensive.
>
> Before we gain more yet another sysreg manipulation function, let's
> unify these with a common helper, providing a consistent order for
> clear/set operands, and the write skipping behaviour from
> change_cpacr(). Code will be migrated to the new helper in subsequent
> patches.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 48ad361c178e..fefc17dae8ee 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -731,6 +731,17 @@ asm(
> asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
> } while (0)
>
> +/*
> + * Modify bits in a sysreg. Bits in the clear mask are zeroed, then bits in the
> + * set mask are set. Other bits are left as-is.
> + */
> +#define sysreg_clear_set(sysreg, clear, set) do { \
> + u64 __scs_val = read_sysreg(sysreg); \
> + u64 __scs_new = (__scs_val & ~(u64)(clear)) | (set); \
> + if (__scs_new != __scs_val) \
> + write_sysreg(__scs_new, sysreg); \
> +} while (0)
> +
> static inline void config_sctlr_el1(u32 clear, u32 set)
> {
> u32 val;
>
For the record, I have this patch as part of Dave's FPSIMD/SVE fixes.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv3 05/19] arm64: kill change_cpacr()
From: Catalin Marinas @ 2018-06-19 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-6-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:56PM +0100, Mark Rutland wrote:
> Now that we have sysreg_clear_set(), we can use this instead of
> change_cpacr().
>
> Note that the order of the set and clear arguments differs between
> change_cpacr() and sysreg_clear_set(), so these are flipped as part of
> the conversion. Also, sve_user_enable() redundantly clears
> CPACR_EL1_ZEN_EL0EN before setting it; this is removed for clarity.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* dynamic reservation and allocation of physically contiguous memory using CMA
From: Marek Szyprowski @ 2018-06-19 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DF0025E0-5C00-4566-82D2-F3599F206210@cisco.com>
Hi Amit,
On 2018-06-18 20:23, Amit Chandra (amichand) wrote:
>
> Hi experts,
>
> I had a question related to CMA. I have been trying to use the CMA
> infra to reserve and allocate physically contiguous memory dynamically
> at runtime.
>
> I built a custom kernel based on linux-4.14.47 to invoke the cma
> initialization apis at runtime from kernel loadable module.
>
> I invoke cma_declare_contiguous() followed by cma_init_reserved_areas().
>
> cma_declare_contiguous throws no surprises and succeeds. The issue
> happens when cma_init_reserved_areas() is invoked post that.
>
> Here is the kernel log snippet post that call:
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.593218] cma:
> cma_declare_contiguous(size 0x0000000200000000, base
> 0x0000000000000000, limit 0x0000000000000000 alignment 0x0000000000000000)
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.593228] cma: Reserved
> 8192 MiB at 0x0000001d4d000000
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.593345] BUG: Bad page
> state in process insmod? pfn:1d4d000
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.595758]
> page:ffffefc335340000 count:0 mapcount:-127 mapping:????????? (null)
> index:0x0
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.599193] flags:
> 0x57fffc000000000()
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.600751] raw:
> 057fffc000000000 0000000000000000 0000000000000000 00000000ffffff80
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.603946] raw:
> ffffefc335330020 ffffefc335350020 000000000000000a 0000000000000000
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.607152] page dumped
> because: nonzero mapcount
>
> I am having a hard time trying to understand why the mapcount is less
> than 0 here. I figured this is happening in the call to __free_pages()
> from init_cma_reserved_pageblock().
>
> Any pointers here would be really helpful. If I am missing any step
> for cma reservation, please do let me know.
>
> Thanks in advance.
>
CMA initialization is possible only on very early boot stage. CMA will
not work as dynamic module.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCHv3 04/19] arm64: kill config_sctlr_el1()
From: Catalin Marinas @ 2018-06-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-5-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:55PM +0100, Mark Rutland wrote:
> Now that we have sysreg_clear_set(), we can consistently use this
> instead of config_sctlr_el1().
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCHv3 03/19] arm64: introduce sysreg_clear_set()
From: Catalin Marinas @ 2018-06-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-4-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:54PM +0100, Mark Rutland wrote:
> Currently we have a couple of helpers to manipulate bits in particular
> sysregs:
>
> * config_sctlr_el1(u32 clear, u32 set)
>
> * change_cpacr(u64 val, u64 mask)
>
> The parameters of these differ in naming convention, order, and size,
> which is unfortunate. They also differ slightly in behaviour, as
> change_cpacr() skips the sysreg write if the bits are unchanged, which
> is a useful optimization when sysreg writes are expensive.
>
> Before we gain more yet another sysreg manipulation function, let's
> unify these with a common helper, providing a consistent order for
> clear/set operands, and the write skipping behaviour from
> change_cpacr(). Code will be migrated to the new helper in subsequent
> patches.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT
From: Adrian Hunter @ 2018-06-19 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN6PR02MB49595D9202DDF98DA16C495CC17D0@SN6PR02MB4959.namprd02.prod.outlook.com>
On 14/06/18 08:38, Manish Narani wrote:
> Ping for RFC
What is eemi? Why aren't there patches for that?
>
>> -----Original Message-----
>> From: Manish Narani [mailto:manish.narani at xilinx.com]
>> Sent: Thursday, June 7, 2018 5:42 PM
>> To: robh+dt at kernel.org; mark.rutland at arm.com; catalin.marinas at arm.com;
>> will.deacon at arm.com; mdf at kernel.org; stefan.krsmanovic at aggios.com;
>> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
>> mmc at vger.kernel.org; devicetree at vger.kernel.org;
>> adrian.hunter at intel.com; michal.simek at xilinx.com; ulf.hansson at linaro.org
>> Cc: Manish Narani <MNARANI@xilinx.com>
>> Subject: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values
>> from DT
>>
>> This patch adds support for reading Tap Delay values from Device Tree and
>> write them via eemi calls. The macros containing these tap delay values are
>> removed from the driver.
>>
>> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
>> ---
>> drivers/mmc/host/sdhci-of-arasan.c | 131
>> +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 131 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-
>> of-arasan.c
>> index e3332a5..fc0fd01 100644
>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>> @@ -36,6 +36,8 @@
>>
>> #define PHY_CLK_TOO_SLOW_HZ 400000
>>
>> +#define MMC_BANK2 0x2
>> +
>> /*
>> * On some SoCs the syscon area has a feature where the upper 16-bits of
>> * each 32-bit register act as a write mask for the lower 16-bits. This allows
>> @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
>> struct sdhci_host *host;
>> struct clk *clk_ahb;
>> struct phy *phy;
>> + u32 mio_bank;
>> + u32 device_id;
>> + u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
>> + u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
>> bool is_phy_on;
>>
>> bool has_cqe;
>> @@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct
>> sdhci_host *host,
>> return ret;
>> }
>>
>> +/**
>> + * arasan_zynqmp_set_tap_delay - Program the tap delays.
>> + * @deviceid: Unique Id of device
>> + * @itap_delay: Input Tap Delay
>> + * @oitap_delay: Output Tap Delay
>> + */
>> +static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay, u8
>> +otap_delay) {
>> + const struct zynqmp_eemi_ops *eemi_ops =
>> zynqmp_pm_get_eemi_ops();
>> + u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
>> +
>> + if (!eemi_ops || !eemi_ops->ioctl)
>> + return;
>> +
>> + if (itap_delay)
>> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
>> + PM_TAPDELAY_INPUT, itap_delay, NULL);
>> +
>> + if (otap_delay)
>> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
>> + PM_TAPDELAY_OUTPUT, otap_delay, NULL);
>> }
>> +
>> static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int
>> clock) {
>> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> struct sdhci_arasan_data *sdhci_arasan =
>> sdhci_pltfm_priv(pltfm_host);
>> bool ctrl_phy = false;
>> + u8 itap_delay;
>> + u8 otap_delay;
>>
>> if (!IS_ERR(sdhci_arasan->phy)) {
>> if (!sdhci_arasan->is_phy_on && clock <=
>> PHY_CLK_TOO_SLOW_HZ) { @@ -200,6 +231,16 @@ static void
>> sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
>> }
>> }
>>
>> + if (host->version >= SDHCI_SPEC_300) {
>> + if ((host->timing != MMC_TIMING_LEGACY) &&
>> + (host->timing != MMC_TIMING_UHS_SDR12)) {
>> + itap_delay = sdhci_arasan->itapdly[host->timing];
>> + otap_delay = sdhci_arasan->otapdly[host->timing];
>> + arasan_zynqmp_set_tap_delay(sdhci_arasan-
>>> device_id,
>> + itap_delay, otap_delay);
>> + }
>> + }
>> +
>> if (ctrl_phy && sdhci_arasan->is_phy_on) {
>> phy_power_off(sdhci_arasan->phy);
>> sdhci_arasan->is_phy_on = false;
>> @@ -456,6 +497,7 @@ static const struct of_device_id
>> sdhci_arasan_of_match[] = {
>> { .compatible = "arasan,sdhci-8.9a" },
>> { .compatible = "arasan,sdhci-5.1" },
>> { .compatible = "arasan,sdhci-4.9a" },
>> + { .compatible = "xlnx,zynqmp-8.9a" },
>>
>> { /* sentinel */ }
>> };
>> @@ -641,6 +683,74 @@ static void sdhci_arasan_unregister_sdclk(struct
>> device *dev)
>> of_clk_del_provider(dev->of_node);
>> }
>>
>> +/**
>> + * arasan_zynqmp_dt_parse_tap_delays - Read Tap Delay values from DT
>> + *
>> + * Called at initialization to parse the values of Tap Delays.
>> + *
>> + * @dev: Pointer to our struct device.
>> + */
>> +static void arasan_zynqmp_dt_parse_tap_delays(struct device *dev) {
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct sdhci_host *host = platform_get_drvdata(pdev);
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_arasan_data *sdhci_arasan =
>> sdhci_pltfm_priv(pltfm_host);
>> + struct device_node *np = dev->of_node;
>> +
>> + of_property_read_u32(np, "xlnx,itap_delay_sd_hsd",
>> + &sdhci_arasan->itapdly[MMC_TIMING_SD_HS]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sd_hsd",
>> + &sdhci_arasan->otapdly[MMC_TIMING_SD_HS]);
>> + of_property_read_u32(np, "xlnx,itap_delay_sdr25",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR25]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sdr25",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR25]);
>> + of_property_read_u32(np, "xlnx,itap_delay_sdr50",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR50]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sdr50",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR50]);
>> + of_property_read_u32(np, "xlnx,itap_delay_sd_ddr50",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_DDR50]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sd_ddr50",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_DDR50]);
>> + of_property_read_u32(np, "xlnx,itap_delay_mmc_hsd",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_HS]);
>> + of_property_read_u32(np, "xlnx,otap_delay_mmc_hsd",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_HS]);
>> + of_property_read_u32(np, "xlnx,itap_delay_mmc_ddr50",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_DDR52]);
>> + of_property_read_u32(np, "xlnx,otap_delay_mmc_ddr50",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_DDR52]);
>> + if (sdhci_arasan->mio_bank == MMC_BANK2) {
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_sdr104_b2",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_sdr104_b2",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_mmc_hs200_b2",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_HS200]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_mmc_hs200_b2",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_HS200]);
>> + } else {
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_sdr104_b0",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_sdr104_b0",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_mmc_hs200_b0",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_HS200]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_mmc_hs200_b0",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_HS200]);
>> + }
>> +}
>> +
>> static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan) {
>> struct sdhci_host *host = sdhci_arasan->host; @@ -776,6 +886,27
>> @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>> goto unreg_clk;
>> }
>>
>> + if (of_device_is_compatible(pdev->dev.of_node,
>> + "xlnx,zynqmp-8.9a")) {
>> + ret = of_property_read_u32(pdev->dev.of_node,
>> + "xlnx,mio_bank",
>> + &sdhci_arasan->mio_bank);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev,
>> + "\"xlnx,mio_bank \" property is missing.\n");
>> + goto clk_disable_all;
>> + }
>> + ret = of_property_read_u32(pdev->dev.of_node,
>> + "xlnx,device_id",
>> + &sdhci_arasan->device_id);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev,
>> + "\"xlnx,device_id \" property is missing.\n");
>> + goto clk_disable_all;
>> + }
>> + arasan_zynqmp_dt_parse_tap_delays(&pdev->dev);
>> + }
>> +
>> sdhci_arasan->phy = ERR_PTR(-ENODEV);
>> if (of_device_is_compatible(pdev->dev.of_node,
>> "arasan,sdhci-5.1")) {
>> --
>> 2.7.4
>
>
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: James Morse @ 2018-06-19 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpMoKP4eG5XhYe5hf5VC9MOY8KuHK=j0ujb8GFpyjAuAww@mail.gmail.com>
Hi Bhupesh,
On 19/06/18 11:37, Bhupesh Sharma wrote:
> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.morse@arm.com> wrote:
>> On 19/06/18 10:57, Jin, Yanjiang wrote:
>>>> -----Original Message-----
>>>> From: Will Deacon [mailto:will.deacon at arm.com]
>>>> Sent: 2018?6?19? 17:41
>>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>>>> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
>>>> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
>>>> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
>>>> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
>>>> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
>>>> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
>>>> kernel at lists.infradead.org>
>>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
>>>> linear region
>>>>>>> It is hard to know all above in kexec-tools now. Originally I
>>>>>>> planned to read memstart_addr's value from "/dev/mem", but someone
>>>>>>> thought not all Kernels enable "/dev/mem", we'd better find a more
>>>>>>> generic approach. So we want to get some suggestions from ARM kernel
>>>> community.
>>>>>>> Can we export this variable in Kernel side through sysconf() or
>>>>>>> other similar methods? Or someone can provide an effect way to get
>>>>>>> memstart_addr's value?
>>>>>>
>>>>>> I thought the suggestion from James was to expose this via an ELF
>>>>>> NOTE in kcore and vmcore (or in the header directly if that's possible, but I'm
>>>> not sure about it)?
>>>>>
>>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a
>>>>> must-have, so we can't depend on it.
>>>>
>>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
>>>>
>>>>> On the other hand, phys_to_virt() is called during generating vmcore
>>>>> in Kexec-tools, vmcore also can't help this issue.
>>>>
>>>> I don't understand this part. If you have the vmcore in your hand, why can't you
>>>> grok the pv offset from the note and use that in phys_to_virt()?
>>>
>>> It is a chicken-and-egg issue.
>>> phys_to virt() is for crashdump setup. To generate vmcore, we must call
>>> phys_to_virt(). At this point, no vmcore exists.
>>
>> Its needed for the parts of the ELF header that kexec-tools generates at kdump
>> load time?
>>
>> So adding this pv_offset to the key=value data crash_save_vmcoreinfo_init()
>> saves isn't available early enough?
> Yes, one case where it is not actually available early enough for
> makedumpfile usage is if we are determining the PT_NOTE contents from
> the '/proc/kcore' on a 'live' system
> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len)
>
> {
>
> <snip..>
> kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET;
>
> }
You are trying to read the vmcoreinfo through /proc/kcore given knowledge of its
physical address.
I'm suggesting adding the contents of vmcoreinfo as a PT_NOTE section of
/proc/kcore's ELF header. No special knowledge necessary, any elf-parser should
be able to dump the values.
> Now the problem at hand is to determine the offset at which the
> pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume
> that when you mentioned above and earlier about adding this pair to
> the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we
> can have 'n' number of PT_LOAD segments.
It looks like there is already a NOTE section with core info in there:
| # readelf -l /proc/kcore
|
| Elf file type is CORE (Core file)
| Entry point 0x0
| There are 16 program headers, starting at offset 64
|
| Program Headers:
| Type Offset VirtAddr PhysAddr
| FileSiz MemSiz Flags Align
| NOTE 0x00000000000003c0 0x0000000000000000 0x0000000000000000
| 0x0000000000001114 0x0000000000000000 0x0
I assume we can add more notes without breaking the existing user...
(and it looks like there are some broken __pa(kernel symbol) users in there.
Thanks,
James
^ permalink raw reply
* [PATCH 1/2] KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
From: Christian Borntraeger @ 2018-06-19 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e4d21bf-d30f-ac66-3017-2badf6a29ec5@arm.com>
On 06/19/2018 12:10 PM, Marc Zyngier wrote:
> On 19/06/18 11:01, Mark Rutland wrote:
>> On Tue, Jun 19, 2018 at 10:42:50AM +0100, Marc Zyngier wrote:
>>> The current behaviour of the compat ioctls is a bit odd.
>>> We provide a compat_ioctl method when KVM_COMPAT is set, and NULL
>>> otherwise. But NULL means that the normal, non-compat ioctl should
>>> be used directly for compat tasks, and there is no way to actually
>>> prevent a compat task from issueing KVM ioctls.
>>>
>>> This patch changes this behaviour, by always registering a compat_ioctl
>>> method, even if KVM_COMPAT is not selected. In that case, the callback
>>> will always return -EINVAL.
>>>
>>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>> I virt/kvm/Kconfig we have:
>>
>> config KVM_COMPAT
>> def_bool y
>> depends on KVM && COMPAT && !S390
>>
>> ... and in arch/s390 we have COMPAT support, so does this potentially break
>> anything there?
>
> It doesn't seem to (COMPAT seems to support the 31 bit stuff, which I
> don't think ever had KVM support), but my s390-foo is quite basic.
>
> Christian, could you help here?
We do not support KVM for 31 bit. So the original goal of the KVM_COMPAT stuff
was to actually disable the compat thing for the KVM device driver.
See
commit de8e5d744051568c8aad ("KVM: Disable compat ioctl for s390").
Now looking back, this patch actually only disabled the compat wrappers and
still allows an 31bit process to run the 64bit ioctls. In theory this should
cause no issues as the 64bit ioctl must fence off all invalid input anyway
but actually forbidding KVM for compat processes is even better.
So I think this patch actually is a good thing.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
if you want you could even add a
Fixes: tag.
^ permalink raw reply
* [PATCHv3 01/19] arm64: consistently use unsigned long for thread flags
From: Mark Rutland @ 2018-06-19 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619104939.likbams3ly5c5ugu@armageddon.cambridge.arm.com>
On Tue, Jun 19, 2018 at 11:49:40AM +0100, Catalin Marinas wrote:
> On Mon, Jun 18, 2018 at 01:02:52PM +0100, Mark Rutland wrote:
> > In do_notify_resume, we manipulate thread_flags as a 32-bit unsigned
> > int, whereas thread_info::flags is a 64-bit unsigned long, and elsewhere
> > (e.g. in the entry assembly) we manipulate the flags as a 64-bit
> > quantity.
> >
> > For consistency, and to avoid problems if we end up with more than 32
> > flags, let's make do_notify_resume take the flags as a 64-bit unsigned
> > long.
>
> When we get to more than 32 flags, you may want to modify the _TIF_*
> definitions as well to (UL(1) << TIF_*).
Agreed. I can spin a patch or two for a that as a subsequent cleanup.
> In the meantime:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cheers!
Mark.
^ permalink raw reply
* [Dev] [PATCH 4/5] RFC: bus: 96boards Low-Speed Connector
From: Daniel Thompson @ 2018-06-19 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-5-linus.walleij@linaro.org>
On Mon, Jun 18, 2018 at 09:45:55AM +0200, Linus Walleij wrote:
> This illustrates my idea for using a small connector driver to
> plug in "mezzanine boards" on the 96boards low-speed connector.
>
> These "mezzanine boards" are no different than "capes", "logic
> modules", etc. This thing, a non-discoverable connector where
> a user can plug in a few peripherals has been reinvented a few
> times.
>
> As a proof-of-concept we add the Secure96, a quite minimal
> mezzanine board.
>
> Users can register their boards in a simple way. Either just
> add their compatible-string in the device tree:
>
> board {
> compatible = "96boards,secure96";
> };
>
> And if they can't even change three lines in their device tree,
> or if they at runtime decide to plug in some board and test it,
> they can use sysfs, as exemplified by plugging in the secure96
> security board at runtime:
>
> > cd /sys/devices/platform/connector
> > echo 1 > secure96
> [ 61.014629] lscon connector: called mezzanine_store on secure96
> [ 61.020530] lscon connector: populate secure96
> [ 61.027081] at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write
> [ 61.053569] atmel-ecc 1-0060: configuration zone is unlocked
> [ 61.502535] tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16)
> (...)
>
> The plug-in board can be removed from sysfs and added back
> again multiple times like this with the devices being runtime
> added and removed by two writes to sysfs.
>
> > echo 0 > secure96
> > echo 1 > secure96
> > echo 0 > secure96
> (...)
Having a sysfs interface is useful (I certainly love being able to use
sysfs to manage ad-hoc I2C chains).
However it feels like the current blurring between connector device and
mezzanine device is shining through in this interface if only because
the look and feel is very different to instantiating an I2C device from
user-space.
Daniel.
^ permalink raw reply
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Srinivas Kandagatla @ 2018-06-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617143127.11421-1-j.neuschaefer@gmx.net>
On 17/06/18 15:31, Jonathan Neusch?fer wrote:
> example:
> diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
> index 6a4aadc4ce06..84b28dbe9f15 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
> @@ -30,7 +30,7 @@ Required properties:
>
> Board connectors:
> * Headset Mic
> - * Secondary Mic",
> + * Secondary Mic
> * DMIC
> * Ext Spk
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
> index aa54e49fc8a2..c7600a93ab39 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
> @@ -35,7 +35,7 @@ This binding describes the APQ8096 sound card, which uses qdsp for audio.
> "Digital Mic3"
>
> Audio pins and MicBias on WCD9335 Codec:
> - "MIC_BIAS1
> + "MIC_BIAS1"
> "MIC_BIAS2"
> "MIC_BIAS3"
> "MIC_BIAS4"
for apq8016 and apq8096 parts:
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
^ permalink raw reply
* [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
From: A.s. Dong @ 2018-06-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502100401.qmik5goglbuiqcaa@pengutronix.de>
Hi Sascha,
> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Wednesday, May 2, 2018 6:04 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; dl-linux-imx
> <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>; shawnguo at kernel.org
> Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
>
> On Sat, Apr 28, 2018 at 02:46:16AM +0800, Dong Aisheng wrote:
> > +/* Initialization of the MU code. */
> > +int __init imx8_scu_init(void)
> > +{
> > + struct device_node *np, *mu_np;
> > + struct resource mu_res;
> > + sc_err_t sci_err;
> > + int ret;
> > +
> > + if (!of_machine_is_compatible("fsl,imx8qxp"))
> > + return 0;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "nxp,imx8qxp-scu");
> > + if (!np)
> > + return -ENODEV;
> > +
> > + mu_np = of_parse_phandle(np, "fsl,mu", 0);
> > + if (WARN_ON(!mu_np))
> > + return -EINVAL;
> > +
> > + ret = of_address_to_resource(mu_np, 0, &mu_res);
> > + if (WARN_ON(ret))
> > + return -EINVAL;
> > +
> > + /* we use mu physical address as IPC communication channel ID */
> > + sci_err = sc_ipc_open(&scu_ipc_handle, (sc_ipc_id_t)(mu_res.start));
> > + if (sci_err != SC_ERR_NONE) {
> > + pr_err("Cannot open MU channel to SCU\n");
> > + return sci_err;
> > + };
>
> Introducing private error codes always has the risk of just forwarding them as
> errno codes as done here.
>
> > +
> > + of_node_put(mu_np);
> > +
> > + pr_info("NXP i.MX SCU Initialized (scu_ipc %u)\n", scu_ipc_handle);
> > +
> > + return 0;
> > +}
> > +early_initcall(imx8_scu_init);
>
> This code shows that the separate 'scu' device node shouldn't exist. It is only
> used as a stepping stone to find the 'mu' node. Instead of providing a proper
> driver for the 'mu' node the scu code registers it with its physical address.
> I don't think it makes sense to separate mu and scu code in this way.
>
> > +#define RPC_VER(MSG) ((MSG)->version)
> > +#define RPC_SIZE(MSG) ((MSG)->size)
> > +#define RPC_SVC(MSG) ((MSG)->svc)
> > +#define RPC_FUNC(MSG) ((MSG)->func)
> > +#define RPC_R8(MSG) ((MSG)->func)
> > +#define RPC_I32(MSG, IDX) ((MSG)->DATA.i32[(IDX) / 4])
> > +#define RPC_I16(MSG, IDX) ((MSG)->DATA.i16[(IDX) / 2])
> > +#define RPC_I8(MSG, IDX) ((MSG)->DATA.i8[(IDX)])
> > +#define RPC_U32(MSG, IDX) ((MSG)->DATA.u32[(IDX) / 4])
> > +#define RPC_U16(MSG, IDX) ((MSG)->DATA.u16[(IDX) / 2])
> > +#define RPC_U8(MSG, IDX) ((MSG)->DATA.u8[(IDX)])
>
> These macros only make the code less readable, please drop them. Plain
> m->version is easier to read and forces the reader through less
> indirections. IMO m->DATA.u32[0] = foo; m->DATA.u8[4] = bar is still better
> readable than doing the division by size in macros.
>
> > +typedef enum sc_rpc_async_state_e {
> > + SC_RPC_ASYNC_STATE_RD_START = 0,
> > + SC_RPC_ASYNC_STATE_RD_ACTIVE = 1,
> > + SC_RPC_ASYNC_STATE_RD_DONE = 2,
> > + SC_RPC_ASYNC_STATE_WR_START = 3,
> > + SC_RPC_ASYNC_STATE_WR_ACTIVE = 4,
> > + SC_RPC_ASYNC_STATE_WR_DONE = 5,
> > +} sc_rpc_async_state_t;
> > +
> > +typedef struct sc_rpc_async_msg_s {
> > + sc_rpc_async_state_t state;
> > + uint8_t wordIdx;
> > + sc_rpc_msg_t msg;
> > + uint32_t timeStamp;
> > +} sc_rpc_async_msg_t;
>
> We normally do not typedef struct types. Any good reasons to do so here?
>
> > +
> > +/* Functions */
> > +
> > +/*
> > + * This is an internal function to send an RPC message over an IPC
> > + * channel. It is called by client-side SCFW API function shims.
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in,out] msg handle to a message
> > + * @param[in] no_resp response flag
> > + *
> > + * If no_resp is false then this function waits for a response
> > + * and returns the result in msg.
> > + */
> > +void sc_call_rpc(sc_ipc_t ipc, sc_rpc_msg_t *msg, bool no_resp);
> > +
> > +/*
> > + * This is an internal function to dispath an RPC call that has
> > + * arrived via IPC over an MU. It is called by server-side SCFW.
> > + *
> > + * @param[in] mu MU message arrived on
> > + * @param[in,out] msg handle to a message
> > + *
> > + * The function result is returned in msg.
> > + */
> > +void sc_rpc_dispatch(sc_rsrc_t mu, sc_rpc_msg_t *msg);
>
> Declared but never defined.
>
> > +
> > +/*
> > + * This function translates an RPC message and forwards on to the
> > + * normal RPC API. It is used only by hypervisors.
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in,out] msg handle to a message
> > + *
> > + * This function decodes a message, calls macros to translate the
> > + * resources, pins, addresses, partitions, memory regions, etc. and
> > + * then forwards on to the hypervisors SCFW API.Return results are
> > + * translated back abd placed back into the message to be returned
> > + * to the original API.
> > + */
> > +void sc_rpc_xlate(sc_ipc_t ipc, sc_rpc_msg_t *msg);
>
> ditto.
>
> > +
> > +#endif /* _SC_RPC_H */
> > diff --git a/drivers/soc/imx/sc/svc/irq/rpc.h
> > b/drivers/soc/imx/sc/svc/irq/rpc.h
> > new file mode 100644
> > index 0000000..0de8718
> > --- /dev/null
> > +++ b/drivers/soc/imx/sc/svc/irq/rpc.h
> > @@ -0,0 +1,41 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017~2018 NXP
> > + *
> > + * Header file for the IRQ RPC implementation.
> > + */
> > +
> > +#ifndef _SC_IRQ_RPC_H
> > +#define _SC_IRQ_RPC_H
> > +
> > +/* Types */
> > +
> > +/*!
> > + * This type is used to indicate RPC IRQ function calls.
> > + */
> > +typedef enum irq_func_e {
> > + IRQ_FUNC_UNKNOWN = 0, /* Unknown function */
> > + IRQ_FUNC_ENABLE = 1, /* Index for irq_enable() RPC call */
> > + IRQ_FUNC_STATUS = 2, /* Index for irq_status() RPC call */
> > +} irq_func_t;
> > +
> > +/* Functions */
> > +
> > +/*!
> > + * This function dispatches an incoming IRQ RPC request.
> > + *
> > + * @param[in] caller_pt caller partition
> > + * @param[in] msg pointer to RPC message
> > + */
> > +void irq_dispatch(sc_rm_pt_t caller_pt, sc_rpc_msg_t *msg);
>
> ditto.
>
> > +
> > +/*!
> > + * This function translates and dispatches an IRQ RPC request.
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in] msg pointer to RPC message
> > + */
> > +void irq_xlate(sc_ipc_t ipc, sc_rpc_msg_t *msg);
>
> ditto.
>
> > +++ b/include/soc/imx/sc/svc/timer/api.h
> > @@ -0,0 +1,265 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017~2018 NXP
> > + *
> > + * Header file containing the public API for the System Controller
> > +(SC)
> > + * Timer function.
> > + *
> > + * TIMER_SVC (SVC) Timer Service
> > + *
> > + * Module for the Timer service. This includes support for the
> > +watchdog, RTC,
> > + * and system counter. Note every resource partition has a watchdog
> > +it can
> > + * use.
> > + */
> > +
> > +#ifndef _SC_TIMER_API_H
> > +#define _SC_TIMER_API_H
> > +
> > +/* Includes */
> > +
> > +#include <soc/imx/sc/types.h>
> > +#include <soc/imx/sc/svc/rm/api.h>
> > +
> > +/* Defines */
> > +
> > +/*
> > + * @name Defines for type widths
> > + */
> > +#define SC_TIMER_ACTION_W 3 /* Width of sc_timer_wdog_action_t
> */
> > +
> > +/*
> > + * @name Defines for sc_timer_wdog_action_t */
> > +#define SC_TIMER_WDOG_ACTION_PARTITION 0 /* Reset
> partition */
> > +#define SC_TIMER_WDOG_ACTION_WARM 1 /* Warm reset
> system */
> > +#define SC_TIMER_WDOG_ACTION_COLD 2 /* Cold reset system
> */
> > +#define SC_TIMER_WDOG_ACTION_BOARD 3 /* Reset board */
> > +#define SC_TIMER_WDOG_ACTION_IRQ 4 /* Only generate
> IRQs */
> > +
> > +/* Types */
> > +
> > +/*
> > + * This type is used to configure the watchdog action.
> > + */
> > +typedef uint8_t sc_timer_wdog_action_t;
>
> Mixing an unnecessary typedef and defines doesn't look good. This should
> be
>
> typedef enum {
> SC_TIMER_WDOG_ACTION_PARTITION,
> } sc_timer_wdog_action_t;
>
> The same pattern is used elsewhere in this patch.
>
After checking with SCU firmware owner, we know that the SCU firmware actually
did that way before, but changed to mixed typedef and defines due to below reasons:
1) emum size is undefined. Usually is int. But wdog_action_t, others are similar,
is defined as u8 in SCU communication protocol which means we can't use it without
an explicitly casting.
2) Follow MISRA C requirement
For enum, Math is not allowed on them. Cannot iterate over them. Can't hardly use at
all without cast.
That's why we decided to eliminate some using of enum in SC firmware to pass the
MISRA C scan.
And for the RPC_X macros, I still did not remove them due to it's used in all C files
which is rather than a simple head file change.
I already sent out an updated version for review.
Please check it. If you still think it's quite necessary to change, please feel free to
let me know.
Regards
Dong Aisheng
> > +
> > +/*
> > + * This type is used to declare a watchdog time value in milliseconds.
> > + */
> > +typedef uint32_t sc_timer_wdog_time_t;
>
> Why an extra type for this?
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C2d0
> 5ba17b0d24957022a08d5b0140906%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C636608522458461041&sdata=WMYanmj1AZkESu0fbXrspidjPbVc
> t3sKQYNhGt5J9ME%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [Dev] [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Daniel Thompson @ 2018-06-19 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
On Mon, Jun 18, 2018 at 09:45:51AM +0200, Linus Walleij wrote:
> This is a proposal for how to handle the non-discoverable
> 96boards plug-in expansion boards called "mezzanines" in the
> Linux kernel. It is a working RFC series meant for discussion
> at the moment.
>
> The RFC was done on the brand new Ultra96 board from Xilinx
> with a Secure96 mezzanine expansion board. The main part
> is in patch 4, the rest is enabling and examples.
>
> The code can be obtained from here:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
>
> You can for example probably augment the DTS file for any
> upstream-supported 96board and get the Secure96 going with
> it with minor efforts.
Like other commenters I'm rather like using C to solve this, and your
comments Big Upfront Design are good backup in term of convincing me.
> TODO:
>
> - Proper device tree bindings for the connector, for now
> look at the example.
>
> - Discuss whether to actually do this or just take it all and
> flush it down the drain because the community doesn't like
> it. I'm not one of those especially infatuated with my own code,
> I always stay by the old programming project management mantra
> to calculate to make one version and throw it away as stepping
> stone to a good final design.
>
> - Placement: putting this in drivers/bus is just an example.
> drivers/platform/96boards-mezzanines is fine too, maybe better?
>
> - I am especially curious about input from Andy and Mika from
> the Intel/ACPI camp on what they have seen for non-discoverable
> plug-in boards. Does this problem even exist in the Intel
> world, or not...
I'm also interested in the "what about ACPI" question?
Using C makes describing a board in ACPI fairly easy. AFAICT allocating
IDs to a board rather than its included components is fairly natural for
ACPI.
However I'm too ignorant to be able to figure out if the expansion
connector itself could/should be described in the tables (e.g. if
connector is a bus and the board is[1] a device, could the bus driver
be instantiated in a reasonable way).
Daniel.
[1] ... or becomes a device, based on feedback in this thread ;-)
^ permalink raw reply
* [PATCH] drm/bridge: tc358764: fix noderef.cocci warnings
From: kbuild test robot @ 2018-06-19 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529396370-18761-8-git-send-email-m.purski@samsung.com>
From: kbuild test robot <fengguang.wu@intel.com>
drivers/gpu/drm/bridge/tc358764.c:179:60-66: ERROR: application of sizeof to pointer
sizeof when applied to a pointer typed expression gives the size of
the pointer
Generated by: scripts/coccinelle/misc/noderef.cocci
Fixes: 147fe90c9d51 ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
CC: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
tc358764.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -176,7 +176,8 @@ static int tc358764_read(struct tc358764
ssize_t ret;
cpu_to_le16s(&addr);
- ret = mipi_dsi_generic_read(dsi, &addr, sizeof(addr), val, sizeof(val));
+ ret = mipi_dsi_generic_read(dsi, &addr, sizeof(addr), val,
+ sizeof(*val));
if (ret >= 0)
le32_to_cpus(val);
^ permalink raw reply
* [PATCH v3 7/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: kbuild test robot @ 2018-06-19 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529396370-18761-8-git-send-email-m.purski@samsung.com>
Hi Andrzej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.18-rc1]
[also build test WARNING on next-20180619]
[cannot apply to drm-exynos/exynos-drm/for-next robh/for-next drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Maciej-Purski/drm-exynos-rename-bridge_node-to-mic_bridge_node/20180619-175136
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/bridge/tc358764.c:179:60-66: ERROR: application of sizeof to pointer
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCHv3 02/19] arm64: move SCTLR_EL{1, 2} assertions to <asm/sysreg.h>
From: Catalin Marinas @ 2018-06-19 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-3-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:53PM +0100, Mark Rutland wrote:
> Currently we assert that the SCTLR_EL{1,2}_{SET,CLEAR} bits are
> self-consistent with an assertion in config_sctlr_el1(). This is a bit
> unusual, since config_sctlr_el1() doesn't make use of these definitions,
> and is far away from the definitions themselves.
>
> We can use the CPP #error directive to have equivalent assertions in
> <asm/sysreg.h>, next to the definitions of the set/clear bits, which is
> a bit clearer and simpler.
>
> At the same time, lets fill in the upper 32 bits for both registers in
> their repsective RES0 definitions. This could be a little nicer with
> GENMASK_ULL(63, 32), but this currently lives in <linux/bitops.h>, which
> cannot safely be included from assembly, as <asm/sysreg.h> can.
>
> Note the when the preprocessor evaluates an expression for an #if
> directive, all signed or unsigned values are treated as intmax_t or
> uintmax_t respectively. To avoid ambiguity, we define explicitly define
> the mask of all 64 bits.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v2 5/5] ARM: tegra: Always boot CPU in ARM-mode
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
CPU always jumps into the reset handler in ARM-mode from the Trusted
Foundations firmware, hence make CPU to always jump into kernel in
ARM-mode regardless of the firmware presence to support Thumb2 kernel + TF
case.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/mach-tegra/reset-handler.S | 1 +
arch/arm/mach-tegra/reset.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index e9f2a7775998..8eda5c786f50 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -113,6 +113,7 @@ ENTRY(__tegra_cpu_reset_handler_start)
* must be position-independent.
*/
+ .arm
.align L1_CACHE_SHIFT
ENTRY(__tegra_cpu_reset_handler)
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index b02ae7699842..3f1ef4561298 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -97,7 +97,7 @@ void __init tegra_cpu_reset_handler_init(void)
__tegra_cpu_reset_handler_data[TEGRA_RESET_MASK_PRESENT] =
*((u32 *)cpu_possible_mask);
__tegra_cpu_reset_handler_data[TEGRA_RESET_STARTUP_SECONDARY] =
- __pa_symbol((void *)secondary_startup);
+ __pa_symbol((void *)secondary_startup_arm);
#endif
#ifdef CONFIG_PM_SLEEP
--
2.17.1
^ permalink raw reply related
* [PATCH v2 4/5] ARM: tegra: Don't apply CPU erratas in insecure mode
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
CPU isn't allowed to touch secure registers while running under secure
monitor. Hence skip applying CPU erratas in the reset handler if Trusted
Foundations firmware presents.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/mach-tegra/reset-handler.S | 24 ++++++++++++------------
arch/arm/mach-tegra/reset.c | 3 +++
arch/arm/mach-tegra/reset.h | 9 +++++++--
arch/arm/mach-tegra/sleep-tegra20.S | 4 ++++
4 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 805f306fa6f7..e9f2a7775998 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -29,8 +29,6 @@
#define PMC_SCRATCH41 0x140
-#define RESET_DATA(x) ((TEGRA_RESET_##x)*4)
-
#ifdef CONFIG_PM_SLEEP
/*
* tegra_resume
@@ -121,6 +119,12 @@ ENTRY(__tegra_cpu_reset_handler)
cpsid aif, 0x13 @ SVC mode, interrupts disabled
tegra_get_soc_id TEGRA_APB_MISC_BASE, r6
+
+ adr r12, __tegra_cpu_reset_handler_data
+ ldr r0, [r12, #RESET_DATA(TF_PRESENT)]
+ cmp r0, #0
+ bne after_errata
+
#ifdef CONFIG_ARCH_TEGRA_2x_SOC
t20_check:
cmp r6, #TEGRA20
@@ -155,7 +159,6 @@ after_errata:
and r10, r10, #0x3 @ R10 = CPU number
mov r11, #1
mov r11, r11, lsl r10 @ R11 = CPU mask
- adr r12, __tegra_cpu_reset_handler_data
#ifdef CONFIG_SMP
/* Does the OS know about this CPU? */
@@ -169,10 +172,9 @@ after_errata:
cmp r6, #TEGRA20
bne 1f
/* If not CPU0, don't let CPU0 reset CPU1 now that CPU1 is coming up. */
- mov32 r5, TEGRA_IRAM_BASE + TEGRA_IRAM_RESET_HANDLER_OFFSET
mov r0, #CPU_NOT_RESETTABLE
cmp r10, #0
- strneb r0, [r5, #__tegra20_cpu1_resettable_status_offset]
+ strneb r0, [r12, #RESET_DATA(RESETTABLE_STATUS)]
1:
#endif
@@ -277,14 +279,12 @@ ENDPROC(__tegra_cpu_reset_handler)
.align L1_CACHE_SHIFT
.type __tegra_cpu_reset_handler_data, %object
.globl __tegra_cpu_reset_handler_data
+ .globl __tegra_cpu_reset_handler_data_offset
+ .equ __tegra_cpu_reset_handler_data_offset, \
+ . - __tegra_cpu_reset_handler_start
__tegra_cpu_reset_handler_data:
- .rept TEGRA_RESET_DATA_SIZE
- .long 0
+ .rept TEGRA_RESET_DATA_SIZE
+ .long 0
.endr
- .globl __tegra20_cpu1_resettable_status_offset
- .equ __tegra20_cpu1_resettable_status_offset, \
- . - __tegra_cpu_reset_handler_start
- .byte 0
.align L1_CACHE_SHIFT
-
ENTRY(__tegra_cpu_reset_handler_end)
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index dc558892753c..b02ae7699842 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/firmware.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/trusted_foundations.h>
#include "iomap.h"
#include "irammap.h"
@@ -89,6 +90,8 @@ static void __init tegra_cpu_reset_handler_enable(void)
void __init tegra_cpu_reset_handler_init(void)
{
+ __tegra_cpu_reset_handler_data[TEGRA_RESET_TF_PRESENT] =
+ trusted_foundations_registered();
#ifdef CONFIG_SMP
__tegra_cpu_reset_handler_data[TEGRA_RESET_MASK_PRESENT] =
diff --git a/arch/arm/mach-tegra/reset.h b/arch/arm/mach-tegra/reset.h
index 9c479c7925b8..db0e6b3097ab 100644
--- a/arch/arm/mach-tegra/reset.h
+++ b/arch/arm/mach-tegra/reset.h
@@ -25,7 +25,11 @@
#define TEGRA_RESET_STARTUP_SECONDARY 3
#define TEGRA_RESET_STARTUP_LP2 4
#define TEGRA_RESET_STARTUP_LP1 5
-#define TEGRA_RESET_DATA_SIZE 6
+#define TEGRA_RESET_RESETTABLE_STATUS 6
+#define TEGRA_RESET_TF_PRESENT 7
+#define TEGRA_RESET_DATA_SIZE 8
+
+#define RESET_DATA(x) ((TEGRA_RESET_##x)*4)
#ifndef __ASSEMBLY__
@@ -49,7 +53,8 @@ void __tegra_cpu_reset_handler_end(void);
(u32)__tegra_cpu_reset_handler_start)))
#define tegra20_cpu1_resettable_status \
(IO_ADDRESS(TEGRA_IRAM_BASE + TEGRA_IRAM_RESET_HANDLER_OFFSET + \
- (u32)__tegra20_cpu1_resettable_status_offset))
+ ((u32)&__tegra_cpu_reset_handler_data[TEGRA_RESET_RESETTABLE_STATUS] - \
+ (u32)__tegra_cpu_reset_handler_start)))
#endif
#define tegra_cpu_reset_handler_offset \
diff --git a/arch/arm/mach-tegra/sleep-tegra20.S b/arch/arm/mach-tegra/sleep-tegra20.S
index 5c8e638ee51a..11f423e4a263 100644
--- a/arch/arm/mach-tegra/sleep-tegra20.S
+++ b/arch/arm/mach-tegra/sleep-tegra20.S
@@ -28,6 +28,7 @@
#include <asm/cache.h>
#include "irammap.h"
+#include "reset.h"
#include "sleep.h"
#define EMC_CFG 0xc
@@ -54,6 +55,9 @@
#define APB_MISC_XM2CFGCPADCTRL2 0x8e4
#define APB_MISC_XM2CFGDPADCTRL2 0x8e8
+#define __tegra20_cpu1_resettable_status_offset \
+ (__tegra_cpu_reset_handler_data_offset + RESET_DATA(RESETTABLE_STATUS))
+
.macro pll_enable, rd, r_car_base, pll_base
ldr \rd, [\r_car_base, #\pll_base]
tst \rd, #(1 << 30)
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/5] ARM: tegra: Setup L2 cache using Trusted Foundations firmware
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
On Tegra20/30 L2 cache must be initialized using firmware call if CPU
is running in insecure mode. Initialize L2 cache and setup the outer-cache
callbacks in early boot using the firmware API.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/mach-tegra/tegra.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index f9587be48235..590b1cf1a8c4 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -38,6 +38,7 @@
#include <soc/tegra/fuse.h>
#include <soc/tegra/pmc.h>
+#include <asm/firmware.h>
#include <asm/hardware/cache-l2x0.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
@@ -70,9 +71,23 @@ u32 tegra_uart_config[3] = {
0,
};
+static void __init tegra_trusted_foundations_l2x0_cache_init(void)
+{
+ if (IS_ENABLED(CONFIG_CACHE_L2X0) &&
+ IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
+ of_machine_is_compatible("nvidia,tegra20"))
+ call_firmware_op(l2x0_init);
+
+ if (IS_ENABLED(CONFIG_CACHE_L2X0) &&
+ IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) &&
+ of_machine_is_compatible("nvidia,tegra30"))
+ call_firmware_op(l2x0_init);
+}
+
static void __init tegra_init_early(void)
{
of_register_trusted_foundations();
+ tegra_trusted_foundations_l2x0_cache_init();
tegra_cpu_reset_handler_init();
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/5] ARM: trusted_foundations: Provide information about whether firmware is registered
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
Add a helper that provides information about whether Trusted Foundations
firmware operations have been registered.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/firmware/trusted_foundations.c | 5 +++++
arch/arm/include/asm/trusted_foundations.h | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/firmware/trusted_foundations.c b/arch/arm/firmware/trusted_foundations.c
index 30df6547020f..f6eeb67de217 100644
--- a/arch/arm/firmware/trusted_foundations.c
+++ b/arch/arm/firmware/trusted_foundations.c
@@ -124,3 +124,8 @@ void of_register_trusted_foundations(void)
panic("Trusted Foundation: missing version-minor property\n");
register_trusted_foundations(&pdata);
}
+
+bool trusted_foundations_registered(void)
+{
+ return firmware_ops == &trusted_foundations_ops;
+}
diff --git a/arch/arm/include/asm/trusted_foundations.h b/arch/arm/include/asm/trusted_foundations.h
index 00748350cf72..bfd0d780824b 100644
--- a/arch/arm/include/asm/trusted_foundations.h
+++ b/arch/arm/include/asm/trusted_foundations.h
@@ -31,6 +31,7 @@
#include <linux/of.h>
#include <linux/cpu.h>
#include <linux/smp.h>
+#include <linux/types.h>
struct trusted_foundations_platform_data {
unsigned int version_major;
@@ -41,6 +42,7 @@ struct trusted_foundations_platform_data {
void register_trusted_foundations(struct trusted_foundations_platform_data *pd);
void of_register_trusted_foundations(void);
+bool trusted_foundations_registered(void);
#else /* CONFIG_TRUSTED_FOUNDATIONS */
@@ -68,6 +70,11 @@ static inline void of_register_trusted_foundations(void)
if (of_find_compatible_node(NULL, NULL, "tlm,trusted-foundations"))
register_trusted_foundations(NULL);
}
+
+static inline bool trusted_foundations_registered(void)
+{
+ return false;
+}
#endif /* CONFIG_TRUSTED_FOUNDATIONS */
#endif
--
2.17.1
^ 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