* Re: arm64/acpi: NULL dereference reports from UBSAN at boot
From: Ard Biesheuvel @ 2020-06-01 22:28 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Mark Rutland, Lorenzo Pieralisi, Peter Collingbourne,
Rafael J. Wysocki, LKML, Alexander Potapenko, Dmitry Vyukov,
Hanjun Guo, Will Deacon, Linux ARM
In-Reply-To: <CAKwvOdnz-=GD9-taLQt6LDhs2Q-xgWmywCUA6skB0NJhubB+nw@mail.gmail.com>
On Tue, 2 Jun 2020 at 00:19, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Mon, Jun 1, 2020 at 2:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 1 Jun 2020 at 23:52, Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > Anyways, it looks like the address of member from NULL subexpression
> > > looks problematic. I wonder if offsetof can be used here?
> > >
> > > #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (offsetof(d, f), (void *) 0)
> > >
> > > Seems to work in my basic test case. Untested in the kernel.
> > >
> > > IIUC, ACPI_OFFSET is trying to calculate the difference between the
> > > offset of a member of a struct and 0? Isn't that the tautology `x - 0
> > > == x`?
> >
> > No. ACPI_OFFSET() is just a poor person's version of offsetof().
> >
> > (Note that it calculates the difference between &(((d *) 0)->f) and
> > (void *)0x0, so the 0x0 term is there on both sides)
>
> Got it. So we're trying to avoid including stddef.h? Can
> __builtin_offsetof be used here?
> #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (__builtin_offsetof(d, f), (void *) 0)
Drop the 0x0:
#define ACPI_OFFSET __builtin_offsetof
should be all we need.
> The oldest version of GCC in godbolt.org (4.1) supports this builtin.
Yeah I think that should be fine.
Alternatively, using any arbitrary address other than 0x0 on both
sides should work as well to get rid of the undefined behavior
(assuming the use of NULL pointers is what is causing it), but I don't
see why we need to invent our own helper here.
BTW some other macros looks dodgy as well.
761f0b82393353507930b6721ae4311a9df2ca36 provides a nice set of
candidates to go and clean up.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64/acpi: NULL dereference reports from UBSAN at boot
From: Nick Desaulniers @ 2020-06-01 22:19 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mark Rutland, Lorenzo Pieralisi, Peter Collingbourne,
Rafael J. Wysocki, LKML, Alexander Potapenko, Dmitry Vyukov,
Hanjun Guo, Will Deacon, Linux ARM
In-Reply-To: <CAMj1kXFQzBaZO+RGKs2iJOzW6rdEiAjdVc8PJ4U+KMWgCD9a6w@mail.gmail.com>
On Mon, Jun 1, 2020 at 2:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 1 Jun 2020 at 23:52, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > Anyways, it looks like the address of member from NULL subexpression
> > looks problematic. I wonder if offsetof can be used here?
> >
> > #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (offsetof(d, f), (void *) 0)
> >
> > Seems to work in my basic test case. Untested in the kernel.
> >
> > IIUC, ACPI_OFFSET is trying to calculate the difference between the
> > offset of a member of a struct and 0? Isn't that the tautology `x - 0
> > == x`?
>
> No. ACPI_OFFSET() is just a poor person's version of offsetof().
>
> (Note that it calculates the difference between &(((d *) 0)->f) and
> (void *)0x0, so the 0x0 term is there on both sides)
Got it. So we're trying to avoid including stddef.h? Can
__builtin_offsetof be used here?
#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (__builtin_offsetof(d, f), (void *) 0)
The oldest version of GCC in godbolt.org (4.1) supports this builtin.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-01 21:59 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, Chen Zhou, Catalin Marinas, RuiRui Yang,
guohanjun, kexec mailing list, Linux Kernel Mailing List,
Rob Herring, Simon Horman, James Morse, Prabhakar Kushwaha,
Thomas Gleixner, Prabhakar Kushwaha, Will Deacon, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <CACi5LpOZzdfEKUYAfYxtgeUbk9K6YFVUKLaGS8XoS0kForjH9A@mail.gmail.com>
Hi . See below !
> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
> Hi John,
>
> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>>
>> Hi,
>>
>>
>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>> Hi Chen,
>>>
>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>
>>>> There are following issues in arm64 kdump:
>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>> when there is no enough low memory.
>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>>>> will boot failure because there is no low memory available for allocation.
>>>>
>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>> size low memory.
>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>> memory above 4G.
>>>>
>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>> is below 4G, the other is above 4G.
>>>> In order to distinct from the high region and make no effect to the use of
>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>>
>>>> Besides, we need to modify kexec-tools:
>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>>
>>>> The previous changes and discussions can be retrieved from:
>>>>
>>>> Changes since [v7]
>>>> - Move x86 CRASH_ALIGN to 2M
>>>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
>>>> - Update Documentation/devicetree/bindings/chosen.txt
>>>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
>>>> - Add Tested-by from Jhon and pk
>>>>
>>>> Changes since [v6]
>>>> - Fix build errors reported by kbuild test robot.
>>>>
>>>> Changes since [v5]
>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>> - Delete crashkernel=X,high.
>>>> - Modify crashkernel=X,low.
>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>>
>>>> Changes since [v4]
>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>>
>>>> Changes since [v3]
>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>> - Fix some compiling warnings.
>>>>
>>>> Changes since [v2]
>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>> patch.
>>>>
>>>> Changes since [v1]:
>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>> in fdt_enforce_memory_region().
>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>> and then remove the memory range in the middle.
>>>>
>>>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
>>>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
>>>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
>>>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
>>>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
>>>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
>>>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
>>>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
>>>>
>>>> Chen Zhou (5):
>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>> kdump: update Documentation about crashkernel on arm64
>>>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
>>>>
>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
>>> with bootargs as [2] of primary kernel.
>>> This error observed on ThunderX2 ARM64 platform.
>>>
>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>> Also **without** this patch-set
>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
>>>
>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
>>> More details discussed earlier in
>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
>>> solution
>>>
>>> This patch-set is expected to solve similar kind of issue.
>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
>>> observation should be considered/fixed. .
>>>
>>> --pk
>>>
>>> [1]
>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>> [ 30.367696] NET: Registered protocol family 16
>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>> [ 30.369984] Call trace:
>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>> [ 30.369991] show_stack+0x20/0x30
>>> [ 30.369997] dump_stack+0xc0/0x10c
>>> [ 30.370001] warn_alloc+0x10c/0x178
>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>> [ 30.370020] do_one_initcall+0x54/0x228
>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>> [ 30.370031] kernel_init+0x1c/0x110
>>> [ 30.370034] ret_from_fork+0x10/0x18
>>> [ 30.370036] Mem-Info:
>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>> unstable:0kB all_unreclaimable? no
>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>> unstable:0kB all_unreclaimable? no
>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>> hugepages_surp=0 hugepages_size=1048576kB
>>> [ 30.370130] 0 total pagecache pages
>>> [ 30.370132] 0 pages in swap cache
>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>> [ 30.370135] Free swap = 0kB
>>> [ 30.370136] Total swap = 0kB
>>> [ 30.370137] 2164609 pages RAM
>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>> [ 30.370140] 612331 pages reserved
>>> [ 30.370141] 0 pages hwpoisoned
>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
>>> coherent allocation
>>
>>
>> During my testing I saw the same error and Chen's solution corrected it .
>
> Which combination you are using on your side? I am using Prabhakar's
> suggested environment and can reproduce the issue
> with or without Chen's crashkernel support above 4G patchset.
>
> I am also using a ThunderX2 platform with latest makedumpfile code and
> kexec-tools (with the suggested patch
> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
>
> Thanks,
> Bhupesh
I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
For this failure ,
>>> DMA: failed to allocate 256 KiB pool for atomic
>>> coherent allocation
Is due to :
3618082c
("arm64 use both ZONE_DMA and ZONE_DMA32")
With the introduction of ZONE_DMA to support the Raspberry DMA
region below 1G, the crashkernel is placed in the upper 4G
ZONE_DMA_32 region. Since the crashkernel does not have access
to the ZONE_DMA region, it prints out call trace during bootup.
It is due to having this CONFIG item ON :
CONFIG_ZONE_DMA=y
Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
use the device tree to specify memory below 1G.
I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
Thank you,
John.
( Note .. I am not on the all the kernel-dlist emails so this won’t be seen by everyone , - someone may have to bounce it )
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64/acpi: NULL dereference reports from UBSAN at boot
From: Ard Biesheuvel @ 2020-06-01 21:57 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Mark Rutland, Lorenzo Pieralisi, Peter Collingbourne,
Rafael J. Wysocki, LKML, Alexander Potapenko, Dmitry Vyukov,
Hanjun Guo, Will Deacon, Linux ARM
In-Reply-To: <CAKwvOdmXmxOdW_TJQmYBYDY8gDOacjDTcpSWQGATb2p_85tFAQ@mail.gmail.com>
On Mon, 1 Jun 2020 at 23:52, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Mon, Jun 1, 2020 at 12:05 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Wed, May 27, 2020 at 02:41:04PM +0100, Lorenzo Pieralisi wrote:
> > > On Tue, May 26, 2020 at 09:21:57PM +0100, Will Deacon wrote:
> > > > Hi Lorenzo, Hanjun, [+Nick]
> > > >
> > > > On Thu, May 21, 2020 at 06:37:38PM +0100, Lorenzo Pieralisi wrote:
> > > > > On Thu, May 21, 2020 at 11:09:53AM +0100, Will Deacon wrote:
> > > > > > Hi folks,
> > > > > >
> > > > > > I just tried booting the arm64 for-kernelci branch under QEMU (version
> > > > > > 4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a
> > > > > > couple of NULL pointer dereferences reported at boot. I think they're
> > > > > > both GIC related (log below). I don't see a panic with UBSAN disabled,
> > > > > > so something's fishy here.
> > > > >
> > > > > May I ask you the QEMU command line please - just to make sure I can
> > > > > replicate it.
> > > >
> > > > As it turns out, I'm only able to reproduce this when building with Clang,
> > > > but I don't know whether that's because GCC is missing something of Clang
> > > > is signalling a false positive. You also don't need all of those whacky
> > > > fuzzing options enabled.
> > > >
> > > > Anyway, to reproduce:
> > > >
> > > > $ git checkout for-next/kernelci
> > > > $ make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- defconfig
> > > > <then do a menuconfig and enable UBSAN>
> > > > $ make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- Image
> > > >
> > > > I throw that at QEMU using:
> > > >
> > > > qemu-system-aarch64 -M virt -machine virtualization=true \
> > > > -machine virt,gic-version=3 \
> > > > -cpu max,sve=off -smp 2 -m 4096 \
> > > > -drive if=pflash,format=raw,file=efi.img,readonly \
> > > > -drive if=pflash,format=raw,file=varstore.img \
> > > > -drive if=virtio,format=raw,file=disk.img \
> > > > -device virtio-scsi-pci,id=scsi0 \
> > > > -device virtio-rng-pci \
> > > > -device virtio-net-pci,netdev=net0 \
> > > > -netdev user,id=net0,hostfwd=tcp::8222-:22 \
> > > > -nographic \
> > > > -kernel ~/work/linux/arch/arm64/boot/Image \
> > > > -append "earlycon root=/dev/vda2"
> > > >
> > > > I built QEMU a while ago according to:
> > > >
> > > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/will/docs/qemu/qemu-arm64-howto.html
> > > >
> > > > and its version 4.2.50 (v4.2.0-779-g4354edb6dcc7).
> > > >
> > > > My clang is version 11.0.1.
> > >
> > > Thanks a lot Will.
> > >
> > > I *think* I was right - it is the ACPI_OFFSET() macro:
> > >
> > > #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
> > >
> > > that triggers the warnings (I suspected it because at least in one of
> > > the warnings I could not see any dereference of any dynamically
> > > allocated data).
> >
> > Cheers, Lorenzo.
> >
> > > Now on what to do with it - thoughts welcome.
> >
> > Nick -- any idea what to do about the above? The '#define' pasted by
> > Lorenzo is causing a couple of spurious UBSAN splats when compiling with
> > clang 11.
>
> If there's undefined behavior from that macro soup, we should be able
> to reproduce it outside of the kernel and regardless of target
> architecture, right? The macros aren't too much to throw into a file:
>
> ```foo.c
> #define acpi_uintptr_t void *
> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
> typedef unsigned char u8;
> typedef unsigned long u64;
> typedef u64 acpi_size;
> #define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) -
> ACPI_CAST_PTR (u8, (b))))
> #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
>
> struct foo {
> unsigned char bar;
> int baz;
> };
>
> int main() {
> return ACPI_OFFSET(struct foo, baz);
> }
> ```
> I think looks right. If we run that through -E, and clean that up
> further, we get:
> ```bar.c
> typedef unsigned char u8;
> typedef unsigned long u64;
>
> struct foo {
> unsigned char bar;
> int baz;
> };
>
> int main() {
> return ((u64) (((u8 *) (void *) ((&(((struct foo *) 0)->baz)))) - ((u8
> *) (void *) (((void *) 0)))));
> }
> ```
> I may be miscounting my parentheses, but how do you take the address
> of `type`->`member`? What does that even mean?
>
> + some more sanitizer folks and Ard for ACPI.
>
> anyways, running foo.c through a compiler:
> $ clang -O2 foo.c -fsanitize=undefined
> $ ./a.out
> foo.c:15:12: runtime error: member access within null pointer of type
> 'struct foo'
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior foo.c:15:12 in
>
> (msg looks truncated, wtf)
>
> Anyways, it looks like the address of member from NULL subexpression
> looks problematic. I wonder if offsetof can be used here?
>
> #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (offsetof(d, f), (void *) 0)
>
> Seems to work in my basic test case. Untested in the kernel.
>
> IIUC, ACPI_OFFSET is trying to calculate the difference between the
> offset of a member of a struct and 0? Isn't that the tautology `x - 0
> == x`?
No. ACPI_OFFSET() is just a poor person's version of offsetof().
(Note that it calculates the difference between &(((d *) 0)->f) and
(void *)0x0, so the 0x0 term is there on both sides)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64/acpi: NULL dereference reports from UBSAN at boot
From: Nick Desaulniers @ 2020-06-01 21:51 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki, LKML,
Alexander Potapenko, Dmitry Vyukov, guohanjun,
Peter Collingbourne, Ard Biesheuvel, Linux ARM
In-Reply-To: <20200601070459.GB8601@willie-the-truck>
On Mon, Jun 1, 2020 at 12:05 AM Will Deacon <will@kernel.org> wrote:
>
> On Wed, May 27, 2020 at 02:41:04PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, May 26, 2020 at 09:21:57PM +0100, Will Deacon wrote:
> > > Hi Lorenzo, Hanjun, [+Nick]
> > >
> > > On Thu, May 21, 2020 at 06:37:38PM +0100, Lorenzo Pieralisi wrote:
> > > > On Thu, May 21, 2020 at 11:09:53AM +0100, Will Deacon wrote:
> > > > > Hi folks,
> > > > >
> > > > > I just tried booting the arm64 for-kernelci branch under QEMU (version
> > > > > 4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a
> > > > > couple of NULL pointer dereferences reported at boot. I think they're
> > > > > both GIC related (log below). I don't see a panic with UBSAN disabled,
> > > > > so something's fishy here.
> > > >
> > > > May I ask you the QEMU command line please - just to make sure I can
> > > > replicate it.
> > >
> > > As it turns out, I'm only able to reproduce this when building with Clang,
> > > but I don't know whether that's because GCC is missing something of Clang
> > > is signalling a false positive. You also don't need all of those whacky
> > > fuzzing options enabled.
> > >
> > > Anyway, to reproduce:
> > >
> > > $ git checkout for-next/kernelci
> > > $ make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- defconfig
> > > <then do a menuconfig and enable UBSAN>
> > > $ make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- Image
> > >
> > > I throw that at QEMU using:
> > >
> > > qemu-system-aarch64 -M virt -machine virtualization=true \
> > > -machine virt,gic-version=3 \
> > > -cpu max,sve=off -smp 2 -m 4096 \
> > > -drive if=pflash,format=raw,file=efi.img,readonly \
> > > -drive if=pflash,format=raw,file=varstore.img \
> > > -drive if=virtio,format=raw,file=disk.img \
> > > -device virtio-scsi-pci,id=scsi0 \
> > > -device virtio-rng-pci \
> > > -device virtio-net-pci,netdev=net0 \
> > > -netdev user,id=net0,hostfwd=tcp::8222-:22 \
> > > -nographic \
> > > -kernel ~/work/linux/arch/arm64/boot/Image \
> > > -append "earlycon root=/dev/vda2"
> > >
> > > I built QEMU a while ago according to:
> > >
> > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/will/docs/qemu/qemu-arm64-howto.html
> > >
> > > and its version 4.2.50 (v4.2.0-779-g4354edb6dcc7).
> > >
> > > My clang is version 11.0.1.
> >
> > Thanks a lot Will.
> >
> > I *think* I was right - it is the ACPI_OFFSET() macro:
> >
> > #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
> >
> > that triggers the warnings (I suspected it because at least in one of
> > the warnings I could not see any dereference of any dynamically
> > allocated data).
>
> Cheers, Lorenzo.
>
> > Now on what to do with it - thoughts welcome.
>
> Nick -- any idea what to do about the above? The '#define' pasted by
> Lorenzo is causing a couple of spurious UBSAN splats when compiling with
> clang 11.
If there's undefined behavior from that macro soup, we should be able
to reproduce it outside of the kernel and regardless of target
architecture, right? The macros aren't too much to throw into a file:
```foo.c
#define acpi_uintptr_t void *
#define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
typedef unsigned char u8;
typedef unsigned long u64;
typedef u64 acpi_size;
#define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) -
ACPI_CAST_PTR (u8, (b))))
#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
struct foo {
unsigned char bar;
int baz;
};
int main() {
return ACPI_OFFSET(struct foo, baz);
}
```
I think looks right. If we run that through -E, and clean that up
further, we get:
```bar.c
typedef unsigned char u8;
typedef unsigned long u64;
struct foo {
unsigned char bar;
int baz;
};
int main() {
return ((u64) (((u8 *) (void *) ((&(((struct foo *) 0)->baz)))) - ((u8
*) (void *) (((void *) 0)))));
}
```
I may be miscounting my parentheses, but how do you take the address
of `type`->`member`? What does that even mean?
+ some more sanitizer folks and Ard for ACPI.
anyways, running foo.c through a compiler:
$ clang -O2 foo.c -fsanitize=undefined
$ ./a.out
foo.c:15:12: runtime error: member access within null pointer of type
'struct foo'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior foo.c:15:12 in
(msg looks truncated, wtf)
Anyways, it looks like the address of member from NULL subexpression
looks problematic. I wonder if offsetof can be used here?
#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (offsetof(d, f), (void *) 0)
Seems to work in my basic test case. Untested in the kernel.
IIUC, ACPI_OFFSET is trying to calculate the difference between the
offset of a member of a struct and 0? Isn't that the tautology `x - 0
== x`?
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model
From: Daniel Lezcano @ 2020-06-01 21:44 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm, linux-arm-kernel, dri-devel,
linux-omap, linux-mediatek, linux-arm-msm, linux-imx
Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau,
bjorn.andersson, bsegall, festevam, mka, robh, amit.kucheria,
lorenzo.pieralisi, khilman, steven.price, cw00.choi, mingo,
mgorman, rui.zhang, alyssa.rosenzweig, orjan.eide, daniel,
b.zolnierkie, s.hauer, rostedt, matthias.bgg, Dietmar.Eggemann,
airlied, tomeu.vizoso, qperret, sboyd, rdunlap, rjw, agross,
kernel, sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <20200527095854.21714-5-lukasz.luba@arm.com>
On 27/05/2020 11:58, Lukasz Luba wrote:
> Add support for other devices than CPUs. The registration function
> does not require a valid cpumask pointer and is ready to handle new
> devices. Some of the internal structures has been reorganized in order to
> keep consistent view (like removing per_cpu pd pointers).
>
> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
> ---
[ ... ]
> }
> EXPORT_SYMBOL_GPL(em_register_perf_domain);
> +
> +/**
> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a device
> + * @dev : Device for which the EM is registered
> + *
> + * Try to unregister the EM for the specified device (but not a CPU).
> + */
> +void em_dev_unregister_perf_domain(struct device *dev)
> +{
> + if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
> + return;
> +
> + if (_is_cpu_device(dev))
> + return;
> +
> + mutex_lock(&em_pd_mutex);
Is the mutex really needed?
If this function is called that means there is no more user of the
em_pd, no?
> + em_debug_remove_pd(dev);
> +
> + kfree(dev->em_pd->table);
> + kfree(dev->em_pd);
> + dev->em_pd = NULL;
> + mutex_unlock(&em_pd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(em_dev_unregister_perf_domain);
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] PCI: uniphier: Add error message when failed to get phy
From: Rob Herring @ 2020-06-01 21:43 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: devicetree, Lorenzo Pieralisi, Masami Hiramatsu, Jassi Brar,
Jingoo Han, linux-kernel, Masahiro Yamada, linux-pci,
Bjorn Helgaas, Gustavo Pimentel, linux-arm-kernel
In-Reply-To: <1589536743-6684-6-git-send-email-hayashi.kunihiko@socionext.com>
On Fri, May 15, 2020 at 06:59:03PM +0900, Kunihiko Hayashi wrote:
> Even if phy driver doesn't probe, the error message can't be distinguished
> from other errors. This displays error message caused by the phy driver
> explicitly.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index 493f105..7ae9688 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -468,8 +468,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> return PTR_ERR(priv->rst);
>
> priv->phy = devm_phy_optional_get(dev, "pcie-phy");
> - if (IS_ERR(priv->phy))
> - return PTR_ERR(priv->phy);
> + if (IS_ERR(priv->phy)) {
> + ret = PTR_ERR(priv->phy);
> + dev_err(dev, "Failed to get phy (%d)\n", ret);
This will print an error on EPROBE_DEFERRED which isn't an error.
> + return ret;
> + }
>
> platform_set_drvdata(pdev, priv);
>
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/5] PCI: uniphier: Add iATU register support
From: Rob Herring @ 2020-06-01 21:32 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: devicetree, Lorenzo Pieralisi, Masami Hiramatsu, Jassi Brar,
Jingoo Han, linux-kernel, Masahiro Yamada, linux-pci,
Bjorn Helgaas, Gustavo Pimentel, linux-arm-kernel
In-Reply-To: <1589536743-6684-5-git-send-email-hayashi.kunihiko@socionext.com>
On Fri, May 15, 2020 at 06:59:02PM +0900, Kunihiko Hayashi wrote:
> This gets iATU register area from reg property. In Synopsis DWC version
> 4.80 or later, since iATU register area is separated from core register
> area, this area is necessary to get from DT independently.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index a8dda39..493f105 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(priv->pci.dbi_base))
> return PTR_ERR(priv->pci.dbi_base);
>
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> + if (res) {
> + priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
This isn't config space, so this function shouldn't be used.
Use devm_platform_ioremap_resource_byname().
> + if (IS_ERR(priv->pci.atu_base))
> + priv->pci.atu_base = NULL;
> + }
> +
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
> priv->base = devm_ioremap_resource(dev, res);
Feel free to convert this one too.
> if (IS_ERR(priv->base))
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Mathieu Poirier @ 2020-06-01 21:28 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Suzuki K Poulose, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, robin.murphy, linux-arm-kernel, Mike Leach
In-Reply-To: <28123d1e19f235f97555ee36a5ed8b52d20cbdea.1590947174.git.saiprakash.ranjan@codeaurora.org>
Hi Sai,
On top of the comments already privided by Mike, I have the following:
On Mon, Jun 01, 2020 at 01:32:26PM +0530, Sai Prakash Ranjan wrote:
> Implement a shutdown callback to ensure ETR/ETF hardware is
> properly shutdown in reboot/shutdown path. This is required
> for ETR/ETF which has SMMU address translation enabled like
> on SC7180 SoC and few others. If the hardware is still accessing
> memory after SMMU translation is disabled as part of SMMU
> shutdown callback in system reboot or shutdown path, then
> IOVAs(I/O virtual address) which it was using will go on the bus
> as the physical addresses which might result in unknown crashes
> (NoC/interconnect errors). So we make sure from this shutdown
> callback that the ETR/ETF is shutdown before SMMU translation is
> disabled and device_link in SMMU driver will take care of ordering
> of shutdown callbacks such that SMMU shutdown callback is not
> called before any of its consumer shutdown callbacks.
>
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
> .../hwtracing/coresight/coresight-tmc-etf.c | 4 +--
> .../hwtracing/coresight/coresight-tmc-etr.c | 2 +-
> drivers/hwtracing/coresight/coresight-tmc.c | 29 +++++++++++++++++++
> drivers/hwtracing/coresight/coresight-tmc.h | 3 ++
> 4 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index 36cce2bfb744..cba3e7592820 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -85,7 +85,7 @@ static void __tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
> CS_LOCK(drvdata->base);
> }
>
> -static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
> +void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
> {
> __tmc_etb_disable_hw(drvdata);
> coresight_disclaim_device(drvdata->base);
> @@ -118,7 +118,7 @@ static int tmc_etf_enable_hw(struct tmc_drvdata *drvdata)
> return 0;
> }
>
> -static void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
> +void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
> {
> CS_UNLOCK(drvdata->base);
>
Why do we care about ETB and ETF when they both use RAM internal to the device?
Moreover, the system RAM they use is not dedicated and as such falls back to the
kernel's memory pool.
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 625882bc8b08..b29c2db94d96 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1110,7 +1110,7 @@ static void __tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>
> }
>
> -static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> +void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> {
> __tmc_etr_disable_hw(drvdata);
> /* Disable CATU device if this ETR is connected to one */
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index 5a271ebc4585..7e687a356fe0 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -540,6 +540,34 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
> return ret;
> }
>
> +static void tmc_shutdown(struct amba_device *adev)
> +{
> + struct tmc_drvdata *drvdata = amba_get_drvdata(adev);
> +
> + if (!drvdata->enable)
> + goto out;
> +
> + /*
> + * We do not care about the active trace sessions here
> + * since the system is going down unlike remove callback,
> + * just make sure that the hardware is shutdown.
> + */
> + switch (drvdata->config_type) {
> + case TMC_CONFIG_TYPE_ETB:
> + tmc_etb_disable_hw(drvdata);
> + break;
> + case TMC_CONFIG_TYPE_ETF:
> + tmc_etf_disable_hw(drvdata);
> + break;
> + case TMC_CONFIG_TYPE_ETR:
> + tmc_etr_disable_hw(drvdata);
> + }
> +
> +out:
> + misc_deregister(&drvdata->miscdev);
> + coresight_unregister(drvdata->csdev);
If a session is active when tmc_shutdown() is called, unregistering the ETF/ETR
will result in a kernel crash if the session is stopped before the kernel has
had the opportunity to shutdown. It is the problem as trying to make coresight
drivers modular.
For this to really work the ongoing session would need to be stopped. That
would teardown the path and stop the sink.
That being said I'm sure that dependencies on an IOMMU isn't a problem confined
to coresight. I am adding Robin Murphy, who added this commit [1], to the thread
in the hope that he can provide guidance on the right way to do this.
Thanks,
Mathieu
[1]. 2ac15068f346 arm64: dts: juno: Add SMMUs device nodes
> +}
> +
> static const struct amba_id tmc_ids[] = {
> CS_AMBA_ID(0x000bb961),
> /* Coresight SoC 600 TMC-ETR/ETS */
> @@ -558,6 +586,7 @@ static struct amba_driver tmc_driver = {
> .suppress_bind_attrs = true,
> },
> .probe = tmc_probe,
> + .shutdown = tmc_shutdown,
> .id_table = tmc_ids,
> };
> builtin_amba_driver(tmc_driver);
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index d156860495c7..f4f56c474e58 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -262,6 +262,8 @@ u32 tmc_get_memwidth_mask(struct tmc_drvdata *drvdata);
> /* ETB/ETF functions */
> int tmc_read_prepare_etb(struct tmc_drvdata *drvdata);
> int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata);
> +void tmc_etb_disable_hw(struct tmc_drvdata *drvdata);
> +void tmc_etf_disable_hw(struct tmc_drvdata *drvdata);
> extern const struct coresight_ops tmc_etb_cs_ops;
> extern const struct coresight_ops tmc_etf_cs_ops;
>
> @@ -270,6 +272,7 @@ ssize_t tmc_etb_get_sysfs_trace(struct tmc_drvdata *drvdata,
> /* ETR functions */
> int tmc_read_prepare_etr(struct tmc_drvdata *drvdata);
> int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata);
> +void tmc_etr_disable_hw(struct tmc_drvdata *drvdata);
> extern const struct coresight_ops tmc_etr_cs_ops;
> ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
> loff_t pos, size_t len, char **bufpp);
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Bhupesh Sharma @ 2020-06-01 21:02 UTC (permalink / raw)
To: John Donnelly
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, Chen Zhou, Catalin Marinas, RuiRui Yang,
guohanjun, kexec mailing list, Linux Kernel Mailing List,
Rob Herring, Simon Horman, James Morse, Prabhakar Kushwaha,
Thomas Gleixner, Prabhakar Kushwaha, Will Deacon, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <303695cc-d3ea-9f51-1489-07d27d4253d4@oracle.com>
Hi John,
On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>
> Hi,
>
>
> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> > Hi Chen,
> >
> > On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
> >> This patch series enable reserving crashkernel above 4G in arm64.
> >>
> >> There are following issues in arm64 kdump:
> >> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> >> when there is no enough low memory.
> >> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> >> in this case, if swiotlb or DMA buffers are required, crash dump kernel
> >> will boot failure because there is no low memory available for allocation.
> >>
> >> To solve these issues, introduce crashkernel=X,low to reserve specified
> >> size low memory.
> >> Crashkernel=X tries to reserve memory for the crash dump kernel under
> >> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> >> size low memory for crash kdump kernel devices firstly and then reserve
> >> memory above 4G.
> >>
> >> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
> >> is specified simultaneously, kernel should reserve specified size low memory
> >> for crash dump kernel devices. So there may be two crash kernel regions, one
> >> is below 4G, the other is above 4G.
> >> In order to distinct from the high region and make no effect to the use of
> >> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
> >> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
> >>
> >> Besides, we need to modify kexec-tools:
> >> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
> >>
> >> The previous changes and discussions can be retrieved from:
> >>
> >> Changes since [v7]
> >> - Move x86 CRASH_ALIGN to 2M
> >> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
> >> - Update Documentation/devicetree/bindings/chosen.txt
> >> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
> >> - Add Tested-by from Jhon and pk
> >>
> >> Changes since [v6]
> >> - Fix build errors reported by kbuild test robot.
> >>
> >> Changes since [v5]
> >> - Move reserve_crashkernel_low() into kernel/crash_core.c.
> >> - Delete crashkernel=X,high.
> >> - Modify crashkernel=X,low.
> >> If crashkernel=X,low is specified simultaneously, reserve spcified size low
> >> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
> >> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
> >> pass to crash dump kernel by DT property "linux,low-memory-range".
> >> - Update Documentation/admin-guide/kdump/kdump.rst.
> >>
> >> Changes since [v4]
> >> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> >>
> >> Changes since [v3]
> >> - Add memblock_cap_memory_ranges back for multiple ranges.
> >> - Fix some compiling warnings.
> >>
> >> Changes since [v2]
> >> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> >> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> >> patch.
> >>
> >> Changes since [v1]:
> >> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> >> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> >> in fdt_enforce_memory_region().
> >> There are at most two crash kernel regions, for two crash kernel regions
> >> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> >> and then remove the memory range in the middle.
> >>
> >> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
> >> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
> >> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
> >> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
> >> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
> >> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
> >> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
> >> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
> >>
> >> Chen Zhou (5):
> >> x86: kdump: move reserve_crashkernel_low() into crash_core.c
> >> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
> >> arm64: kdump: add memory for devices by DT property, low-memory-range
> >> kdump: update Documentation about crashkernel on arm64
> >> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
> >>
> > We are getting "warn_alloc" [1] warning during boot of kdump kernel
> > with bootargs as [2] of primary kernel.
> > This error observed on ThunderX2 ARM64 platform.
> >
> > It is observed with latest upstream tag (v5.7-rc3) with this patch set
> > and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> > Also **without** this patch-set
> > "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
> >
> > This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> > More details discussed earlier in
> > https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> > solution
> >
> > This patch-set is expected to solve similar kind of issue.
> > i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> > observation should be considered/fixed. .
> >
> > --pk
> >
> > [1]
> > [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > [ 30.367696] NET: Registered protocol family 16
> > [ 30.369973] swapper/0: page allocation failure: order:6,
> > mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> > [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> > [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > [ 30.369984] Call trace:
> > [ 30.369989] dump_backtrace+0x0/0x1f8
> > [ 30.369991] show_stack+0x20/0x30
> > [ 30.369997] dump_stack+0xc0/0x10c
> > [ 30.370001] warn_alloc+0x10c/0x178
> > [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> > [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> > [ 30.370008] alloc_page_interleave+0x24/0x98
> > [ 30.370011] alloc_pages_current+0xe4/0x108
> > [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> > [ 30.370020] do_one_initcall+0x54/0x228
> > [ 30.370027] kernel_init_freeable+0x228/0x2cc
> > [ 30.370031] kernel_init+0x1c/0x110
> > [ 30.370034] ret_from_fork+0x10/0x18
> > [ 30.370036] Mem-Info:
> > [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> > [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> > [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> > [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> > [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> > [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> > [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> > unstable:0kB all_unreclaimable? no
> > [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> > unstable:0kB all_unreclaimable? no
> > [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> > reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> > bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> > [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> > high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> > pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> > [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> > high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> > pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> > [ 30.370104] lowmem_reserve[]: 0 0 0 0
> > [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> > [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> > 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> > [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> > (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> > 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> > [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> > hugepages_surp=0 hugepages_size=1048576kB
> > [ 30.370130] 0 total pagecache pages
> > [ 30.370132] 0 pages in swap cache
> > [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> > [ 30.370135] Free swap = 0kB
> > [ 30.370136] Total swap = 0kB
> > [ 30.370137] 2164609 pages RAM
> > [ 30.370139] 0 pages HighMem/MovableOnly
> > [ 30.370140] 612331 pages reserved
> > [ 30.370141] 0 pages hwpoisoned
> > [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> > coherent allocation
>
>
> During my testing I saw the same error and Chen's solution corrected it .
Which combination you are using on your side? I am using Prabhakar's
suggested environment and can reproduce the issue
with or without Chen's crashkernel support above 4G patchset.
I am also using a ThunderX2 platform with latest makedumpfile code and
kexec-tools (with the suggested patch
<https://lists.infradead.org/pipermail/kexec/2020-May/025128.html>).
Thanks,
Bhupesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH mvebu 2/2] firmware: turris-mox-rwtm: add debugfs documentation
From: Marek Behún @ 2020-06-01 21:00 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: SoC Team, arm-soc, Linux ARM, Marek Behún
In-Reply-To: <20200601210050.31821-1-marek.behun@nic.cz>
Add debugfs ABI documentation for the ECDSA signatures.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
Documentation/ABI/testing/debugfs-turris-mox-rwtm | 9 +++++++++
1 file changed, 9 insertions(+)
create mode 100644 Documentation/ABI/testing/debugfs-turris-mox-rwtm
diff --git a/Documentation/ABI/testing/debugfs-turris-mox-rwtm b/Documentation/ABI/testing/debugfs-turris-mox-rwtm
new file mode 100644
index 000000000000..2b3255ee68fd
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-turris-mox-rwtm
@@ -0,0 +1,9 @@
+What: /sys/kernel/debug/turris-mox-rwtm/do_sign
+Date: Jun 2020
+KernelVersion: 5.8
+Contact: Marek Behún <marek.behun@nic.cz>
+Description: (W) Message to sign with the ECDSA private key stored in
+ device's OTP. The message must be exactly 64 bytes (since
+ this is intended for SHA-512 hashes).
+ (R) The resulting signature, 136 bytes. This contains the R and
+ S values of the ECDSA signature, both in big-endian format.
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH mvebu 1/2] firmware: turris-mox-rwtm: support ECDSA signatures via debugfs
From: Marek Behún @ 2020-06-01 21:00 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: SoC Team, arm-soc, Linux ARM, Marek Behún
The firmware on Turris MOX secure processor offers signing messages
with ECDSA private key stored in protected OTP memory.
The optimal solution would be to register an akcipher provider via
kernel's crypto API, but crypto API does not yet support accessing
akcipher API from userspace (and probably won't for some time, see
https://www.spinics.net/lists/linux-crypto/msg38388.html).
At first I tried to put this via standard sysfs API, but the way I
designed it is not compatible with sysfs's standard "one file per
attribute".
This patch therefore adds support for accessing this signature
generation mechanism via debugfs. Since CZ.NIC's Turris MOX is the only
user of this module, the potential future change to akcipher API should
not cause problems, since we can just change our userspace software then.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
drivers/firmware/turris-mox-rwtm.c | 166 +++++++++++++++++++++++++++++
1 file changed, 166 insertions(+)
diff --git a/drivers/firmware/turris-mox-rwtm.c b/drivers/firmware/turris-mox-rwtm.c
index e27f68437b56..50bb2a6d6ccf 100644
--- a/drivers/firmware/turris-mox-rwtm.c
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -7,6 +7,7 @@
#include <linux/armada-37xx-rwtm-mailbox.h>
#include <linux/completion.h>
+#include <linux/debugfs.h>
#include <linux/dma-mapping.h>
#include <linux/hw_random.h>
#include <linux/mailbox_client.h>
@@ -69,6 +70,18 @@ struct mox_rwtm {
/* public key burned in eFuse */
int has_pubkey;
u8 pubkey[135];
+
+#ifdef CONFIG_DEBUG_FS
+ /*
+ * Signature process. This is currently done via debugfs, because it
+ * does not conform to the sysfs standard "one file per attribute".
+ * It should be rewritten via crypto API once akcipher API is available
+ * from userspace.
+ */
+ struct dentry *debugfs_root;
+ u32 last_sig[34];
+ int last_sig_done;
+#endif
};
struct mox_kobject {
@@ -279,6 +292,152 @@ static int mox_hwrng_read(struct hwrng *rng, void *data, size_t max, bool wait)
return ret;
}
+#ifdef CONFIG_DEBUG_FS
+static int rwtm_debug_open(struct inode *inode, struct file *file)
+{
+ file->private_data = inode->i_private;
+
+ return nonseekable_open(inode, file);
+}
+
+static ssize_t do_sign_read(struct file *file, char __user *buf, size_t len,
+ loff_t *ppos)
+{
+ struct mox_rwtm *rwtm = file->private_data;
+ ssize_t ret;
+
+ /* only allow one read, of 136 bytes, from position 0 */
+ if (*ppos != 0)
+ return 0;
+
+ if (len < 136)
+ return -EINVAL;
+
+ if (!rwtm->last_sig_done)
+ return -ENODATA;
+
+ /* 2 arrays of 17 32-bit words are 136 bytes */
+ ret = simple_read_from_buffer(buf, len, ppos, rwtm->last_sig, 136);
+ rwtm->last_sig_done = 0;
+
+ return ret;
+}
+
+static ssize_t do_sign_write(struct file *file, const char __user *buf,
+ size_t len, loff_t *ppos)
+{
+ struct mox_rwtm *rwtm = file->private_data;
+ struct armada_37xx_rwtm_rx_msg *reply = &rwtm->reply;
+ struct armada_37xx_rwtm_tx_msg msg;
+ loff_t dummy = 0;
+ ssize_t ret;
+
+ /* the input is a SHA-512 hash, so exactly 64 bytes have to be read */
+ if (len != 64)
+ return -EINVAL;
+
+ /* if last result is not zero user has not read that information yet */
+ if (rwtm->last_sig_done)
+ return -EBUSY;
+
+ if (!mutex_trylock(&rwtm->busy))
+ return -EBUSY;
+
+ /*
+ * Here we have to send:
+ * 1. Address of the input to sign.
+ * The input is an array of 17 32-bit words, the first (most
+ * significat) is 0, the rest 16 words are copied from the SHA-512
+ * hash given by the user and converted from BE to LE.
+ * 2. Address of the buffer where ECDSA signature value R shall be
+ * stored by the rWTM firmware.
+ * 3. Address of the buffer where ECDSA signature value S shall be
+ * stored by the rWTM firmware.
+ */
+ memset(rwtm->buf, 0, 4);
+ ret = simple_write_to_buffer(rwtm->buf + 4, 64, &dummy, buf, len);
+ if (ret < 0)
+ goto unlock_mutex;
+ be32_to_cpu_array(rwtm->buf, rwtm->buf, 17);
+
+ msg.command = MBOX_CMD_SIGN;
+ msg.args[0] = 1;
+ msg.args[1] = rwtm->buf_phys;
+ msg.args[2] = rwtm->buf_phys + 68;
+ msg.args[3] = rwtm->buf_phys + 2 * 68;
+ ret = mbox_send_message(rwtm->mbox, &msg);
+ if (ret < 0)
+ goto unlock_mutex;
+
+ ret = wait_for_completion_interruptible(&rwtm->cmd_done);
+ if (ret < 0)
+ goto unlock_mutex;
+
+ ret = MBOX_STS_VALUE(reply->retval);
+ if (MBOX_STS_ERROR(reply->retval) != MBOX_STS_SUCCESS)
+ goto unlock_mutex;
+
+ /*
+ * Here we read the R and S values of the ECDSA signature
+ * computed by the rWTM firmware and convert their words from
+ * LE to BE.
+ */
+ memcpy(rwtm->last_sig, rwtm->buf + 68, 136);
+ cpu_to_be32_array(rwtm->last_sig, rwtm->last_sig, 34);
+ rwtm->last_sig_done = 1;
+
+ mutex_unlock(&rwtm->busy);
+ return len;
+unlock_mutex:
+ mutex_unlock(&rwtm->busy);
+ return ret;
+}
+
+static const struct file_operations do_sign_fops = {
+ .owner = THIS_MODULE,
+ .open = rwtm_debug_open,
+ .read = do_sign_read,
+ .write = do_sign_write,
+ .llseek = no_llseek,
+};
+
+static int rwtm_register_debugfs(struct mox_rwtm *rwtm)
+{
+ struct dentry *root, *entry;
+
+ root = debugfs_create_dir("turris-mox-rwtm", NULL);
+
+ if (IS_ERR(root))
+ return PTR_ERR(root);
+
+ entry = debugfs_create_file_unsafe("do_sign", 0600, root, rwtm,
+ &do_sign_fops);
+ if (IS_ERR(entry))
+ goto err_remove;
+
+ rwtm->debugfs_root = root;
+
+ return 0;
+err_remove:
+ debugfs_remove_recursive(root);
+ return PTR_ERR(entry);
+}
+
+static void rwtm_unregister_debugfs(struct mox_rwtm *rwtm)
+{
+ debugfs_remove_recursive(rwtm->debugfs_root);
+}
+#else
+static inline int rwtm_register_debugfs(struct mox_rwtm *rwtm)
+{
+ return 0;
+}
+
+static inline void rwtm_unregister_debugfs(struct mox_rwtm *rwtm)
+{
+}
+#endif
+
static int turris_mox_rwtm_probe(struct platform_device *pdev)
{
struct mox_rwtm *rwtm;
@@ -340,6 +499,12 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)
goto free_channel;
}
+ ret = rwtm_register_debugfs(rwtm);
+ if (ret < 0) {
+ dev_err(dev, "Failed creating debugfs entries: %i\n", ret);
+ goto free_channel;
+ }
+
return 0;
free_channel:
@@ -355,6 +520,7 @@ static int turris_mox_rwtm_remove(struct platform_device *pdev)
{
struct mox_rwtm *rwtm = platform_get_drvdata(pdev);
+ rwtm_unregister_debugfs(rwtm);
sysfs_remove_files(rwtm_to_kobj(rwtm), mox_rwtm_attrs);
kobject_put(rwtm_to_kobj(rwtm));
mbox_free_channel(rwtm->mbox);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH] iommu/arm-smmu-v3: expose numa_node attribute to users in sysfs
From: Song Bao Hua (Barry Song) @ 2020-06-01 20:43 UTC (permalink / raw)
To: Robin Murphy, will@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, iommu@lists.linux-foundation.org
Cc: Linuxarm, linux-arm-kernel@lists.infradead.org
In-Reply-To: <4e902884-7ac3-9e79-ec01-f56f2fc5ebad@arm.com>
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, June 2, 2020 1:14 AM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; will@kernel.org;
> hch@lst.de; m.szyprowski@samsung.com; iommu@lists.linux-foundation.org
> Cc: Linuxarm <linuxarm@huawei.com>; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH] iommu/arm-smmu-v3: expose numa_node attribute to
> users in sysfs
>
> On 2020-05-30 10:15, Barry Song wrote:
> > As tests show the latency of dma_unmap can increase dramatically while
> > calling them cross NUMA nodes, especially cross CPU packages, eg.
> > 300ns vs 800ns while waiting for the completion of CMD_SYNC in an
> > empty command queue. The large latency causing by remote node will
> > in turn make contention of the command queue more serious, and enlarge
> > the latency of DMA users within local NUMA nodes.
> >
> > Users might intend to enforce NUMA locality with the consideration of
> > the position of SMMU. The patch provides minor benefit by presenting
> > this information to users directly, as they might want to know it without
> > checking hardware spec at all.
>
> Hmm, given that dev-to_node() is a standard driver model thing, is there
> not already some generic device property that can expose it - and if
> not, should there be? Presumably if userspace cares enough to want to
> know whereabouts in the system an IOMMU is, it probably also cares where
> the actual endpoint devices are too.
>
> At the very least, it doesn't seem right for it to be specific to one
> single IOMMU driver.
Right now pci devices have generally got the numa_node in sysfs by drivers/pci/pci-sysfs.c
static ssize_t numa_node_store(struct device *dev,
struct device_attribute *attr, const char *buf,
size_t count)
{
...
add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
pci_alert(pdev, FW_BUG "Overriding NUMA node to %d. Contact your vendor for updates.",
node);
dev->numa_node = node;
return count;
}
static ssize_t numa_node_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
return sprintf(buf, "%d\n", dev->numa_node);
}
static DEVICE_ATTR_RW(numa_node);
for other devices who care about numa information, the specific drivers are doing that, for example:
drivers/dax/bus.c: if (a == &dev_attr_numa_node.attr && !IS_ENABLED(CONFIG_NUMA))
drivers/dax/bus.c: &dev_attr_numa_node.attr,
drivers/dma/idxd/sysfs.c: &dev_attr_numa_node.attr,
drivers/hv/vmbus_drv.c: &dev_attr_numa_node.attr,
drivers/nvdimm/bus.c: &dev_attr_numa_node.attr,
drivers/nvme/host/core.c: &dev_attr_numa_node.attr,
smmu is usually a platform device, we can actually expose numa_node for platform_device, or globally expose numa_node
for general "device" if people don't opposite.
Barry
>
> Robin.
>
> > Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> > ---
> > drivers/iommu/arm-smmu-v3.c | 40
> ++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > index 82508730feb7..754c4d59498b 100644
> > --- a/drivers/iommu/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm-smmu-v3.c
> > @@ -4021,6 +4021,44 @@ err_reset_pci_ops: __maybe_unused;
> > return err;
> > }
> >
> > +static ssize_t numa_node_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + return sprintf(buf, "%d\n", dev_to_node(dev));
> > +}
> > +static DEVICE_ATTR_RO(numa_node);
> > +
> > +static umode_t arm_smmu_numa_attr_visible(struct kobject *kobj, struct
> attribute *a,
> > + int n)
> > +{
> > + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> > +
> > + if (!IS_ENABLED(CONFIG_NUMA))
> > + return 0;
> > +
> > + if (a == &dev_attr_numa_node.attr &&
> > + dev_to_node(dev) == NUMA_NO_NODE)
> > + return 0;
> > +
> > + return a->mode;
> > +}
> > +
> > +static struct attribute *arm_smmu_dev_attrs[] = {
> > + &dev_attr_numa_node.attr,
> > + NULL
> > +};
> > +
> > +static struct attribute_group arm_smmu_dev_attrs_group = {
> > + .attrs = arm_smmu_dev_attrs,
> > + .is_visible = arm_smmu_numa_attr_visible,
> > +};
> > +
> > +
> > +static const struct attribute_group *arm_smmu_dev_attrs_groups[] = {
> > + &arm_smmu_dev_attrs_group,
> > + NULL,
> > +};
> > +
> > static int arm_smmu_device_probe(struct platform_device *pdev)
> > {
> > int irq, ret;
> > @@ -4097,7 +4135,7 @@ static int arm_smmu_device_probe(struct
> platform_device *pdev)
> > return ret;
> >
> > /* And we're up. Go go go! */
> > - ret = iommu_device_sysfs_add(&smmu->iommu, dev, NULL,
> > + ret = iommu_device_sysfs_add(&smmu->iommu, dev,
> arm_smmu_dev_attrs_groups,
> > "smmu3.%pa", &ioaddr);
> > if (ret)
> > return ret;
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] arm: decompressor: define a new zImage tag
From: Russell King - ARM Linux admin @ 2020-06-01 20:41 UTC (permalink / raw)
To: Lukasz Stelmach
Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <dleftj8sh6sf9a.fsf%l.stelmach@samsung.com>
On Mon, Jun 01, 2020 at 10:27:45PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 19:25>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
> >> It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote:
> >> > On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
> >> >> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
> >> >> requirements of the decompressor code.
> >> >
> >> > Why do we need to know the stack and BSS size, when the userspace
> >> > kexec tool doesn't need to know this to perform the same function.
> >>
> >>
> >> kexec-tools load zImage as low in DRAM as possible and rely on two
> >> assumptions:
> >>
> >> + the zImage will copy itself to make enough room for the kernel,
> >> + sizeof(zImage+mem) < sizeof(kernel+mem), which is true because
> >> of compression.
> >>
> >> DRAM start
> >> + 0x8000
> >>
> >> zImage |-----------|-----|-------|
> >> text+data bss stack
> >>
> >> text+data bss
> >> kernel |---------------------|-------------------|
> >>
> >>
> >> initrd |-initrd-|-dtb-|
> >
> > This is actually incorrect, because the decompressor will self-
> > relocate itself to avoid the area that it is going to decompress
> > into.
>
> I described the state right after kexec(8) invocation.
Actually, you haven't, because this is _not_ how kexec(8) lays it
out, as I attempted to detail further down in my reply.
> > So, while the decompressor runs, in the above situation it
> > ends up as:
> >
> >
> > ram |------------------------------------------------------...
> > text+data bss
> > kernel |---------------------|-------------------|
> > zImage |-----------|-----|-------|
> > text+data bss stack+malloc
Note here - if the initrd was placed as _you_ describe at the end
of where the zImage ends up including its BSS, it would be
corrupted by the stack and malloc space of the decompressor while
running. Ergo, your description of how kexec(8) lays stuff out
is incorrect.
> > Where "text+data" is actually smaller than the image size that
> > was loaded - the part of the image that performs the relocation
> > is discarded (the first chunk of code up to "restart" - 200
> > bytes.) The BSS is typically smaller than 200 bytes, so we've
> > been able to get away without knowing the actual BSS size so
> > far.
> >
> >
> > ram |--|-----------------------------------------|---------...
> > |<>| TEXT_OFFSET
> > kernel |---------------------|-------------------|
> > |<----edata_size----->|<-----bss_size---->|
> > |<---------------kernel_size------------->|
> > zImage |-----------|-----|-------|
> > |<-------len------->| (initial)
> > |<----------len------------>| (final)
> >
> > The "final" len value is what the decompressor prints as the "zImage
> > requires" debugging value.
> >
> > Hence, the size that the decompressed kernel requires is kernel_size.
> >
> > The size that the decompressor requires is edata_size + len(final).
> >
> > Now, if you intend to load the kernel to ram + TEXT_OFFSET + edata_size
> > then it isn't going to lose the first 200 bytes of code, so as you
> > correctly point out, we need to know the BSS size.
>
> Formal note: can we keep using terms zImage and kernel as separate,
> where zImage is what is loaded with kexec and kernel is the decompressed
> code loaded at TEXT_OFFSET. I believe, it will help us avoid mistakes.
>
> >> >> +struct arm_zimage_tag_dc {
> >> >> + struct tag_header hdr;
> >> >> + union {
> >> >> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4
> >> >> + struct zimage_decomp_size {
> >> >> + __le32 bss_size;
> >> >> + __le32 stack_size;
> >> >> + __le32 malloc_size;
> >> >> + } decomp_size;
> >
> > You certainly don't need to know all this. All you need to know is
> > how much space the decompressor requires after the end of the image,
> > encompassing the BSS size, stack size and malloc size, which is one
> > value.
>
> I agree. However, since we are not fighting here for every single byte,
> I'd rather add them as separate values and make the tag, even if only
> slightly, more future-proof.
It doesn't make it more future-proof. What happens if we add something
else, do we need to list it separately, and then change the kernel to
accept the new value and maybe also kexec(8)? Or do we just say "the
decompressor needs X many bytes after the image" and be done with it?
The latter sounds way more future-proof to me.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] arm: decompressor: define a new zImage tag
From: Lukasz Stelmach @ 2020-06-01 20:27 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20200601182555.GP1551@shell.armlinux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 4504 bytes --]
It was <2020-06-01 pon 19:25>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
>> It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote:
>> > On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
>> >> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
>> >> requirements of the decompressor code.
>> >
>> > Why do we need to know the stack and BSS size, when the userspace
>> > kexec tool doesn't need to know this to perform the same function.
>>
>>
>> kexec-tools load zImage as low in DRAM as possible and rely on two
>> assumptions:
>>
>> + the zImage will copy itself to make enough room for the kernel,
>> + sizeof(zImage+mem) < sizeof(kernel+mem), which is true because
>> of compression.
>>
>> DRAM start
>> + 0x8000
>>
>> zImage |-----------|-----|-------|
>> text+data bss stack
>>
>> text+data bss
>> kernel |---------------------|-------------------|
>>
>>
>> initrd |-initrd-|-dtb-|
>
> This is actually incorrect, because the decompressor will self-
> relocate itself to avoid the area that it is going to decompress
> into.
I described the state right after kexec(8) invocation.
> So, while the decompressor runs, in the above situation it
> ends up as:
>
>
> ram |------------------------------------------------------...
> text+data bss
> kernel |---------------------|-------------------|
> zImage |-----------|-----|-------|
> text+data bss stack+malloc
And I am trying to achieve this state before the decompressor starts so
it won't need to copy itself during boot. The only exception is (as we
discussed under a different patch) when edata_size >= 128-eps MiB because
loading zImage above 128 MiB prevents it from properly detecting
physical memory. In such unlikely case my code behaves like kexec-tools
and loads zImage low. That is why I suggested that passing detailed
information about memory layout to the decompressor would help.
> Where "text+data" is actually smaller than the image size that
> was loaded - the part of the image that performs the relocation
> is discarded (the first chunk of code up to "restart" - 200
> bytes.) The BSS is typically smaller than 200 bytes, so we've
> been able to get away without knowing the actual BSS size so
> far.
>
>
> ram |--|-----------------------------------------|---------...
> |<>| TEXT_OFFSET
> kernel |---------------------|-------------------|
> |<----edata_size----->|<-----bss_size---->|
> |<---------------kernel_size------------->|
> zImage |-----------|-----|-------|
> |<-------len------->| (initial)
> |<----------len------------>| (final)
>
> The "final" len value is what the decompressor prints as the "zImage
> requires" debugging value.
>
> Hence, the size that the decompressed kernel requires is kernel_size.
>
> The size that the decompressor requires is edata_size + len(final).
>
> Now, if you intend to load the kernel to ram + TEXT_OFFSET + edata_size
> then it isn't going to lose the first 200 bytes of code, so as you
> correctly point out, we need to know the BSS size.
Formal note: can we keep using terms zImage and kernel as separate,
where zImage is what is loaded with kexec and kernel is the decompressed
code loaded at TEXT_OFFSET. I believe, it will help us avoid mistakes.
>> >> +struct arm_zimage_tag_dc {
>> >> + struct tag_header hdr;
>> >> + union {
>> >> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4
>> >> + struct zimage_decomp_size {
>> >> + __le32 bss_size;
>> >> + __le32 stack_size;
>> >> + __le32 malloc_size;
>> >> + } decomp_size;
>
> You certainly don't need to know all this. All you need to know is
> how much space the decompressor requires after the end of the image,
> encompassing the BSS size, stack size and malloc size, which is one
> value.
I agree. However, since we are not fighting here for every single byte,
I'd rather add them as separate values and make the tag, even if only
slightly, more future-proof.
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] clk: rockchip: rk3288: Handle clock tree for rk3288w
From: Heiko Stübner @ 2020-06-01 20:09 UTC (permalink / raw)
To: Mylène Josserand
Cc: sboyd, mturquette, linux-kernel, kever.yang, linux-rockchip,
geert, kernel, linux-clk, linux-arm-kernel
In-Reply-To: <20200601151442.156184-2-mylene.josserand@collabora.com>
Hi Mylène,
Am Montag, 1. Juni 2020, 17:14:42 CEST schrieb Mylène Josserand:
> The revision rk3288w has a different clock tree about "hclk_vio"
> clock, according to the BSP kernel code.
>
> This patch handles this difference by detecting which device-tree
> we are using. If it is a "rockchip,rk3288-cru", let's register
> the clock tree as it was before. If the compatible is
> "rockchip,rk3288w-cru", we will apply the difference according to this
> version of this SoC.
>
> Noticed that this new device-tree compatible must be handled by
> bootloader.
>
> Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
approach looks good, but you should also update the clock-controller
dt-binding for the new compatible.
Style nits below.
> ---
> drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
> index cc2a177bbdbf..5018d2f1e54c 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
> COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
> RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
> RK3288_CLKGATE_CON(3), 0, GFLAGS),
> - DIV(0, "hclk_vio", "aclk_vio0", 0,
> - RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
> COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
> RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
> RK3288_CLKGATE_CON(3), 2, GFLAGS),
> @@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
> INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, IFLAGS),
> };
>
> +static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
> + DIV(0, "hclk_vio", "aclk_vio1", 0,
> + RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
please keep indentations as they were, the sub-lines starting where they
are is actually intentional :-)
> +};
> +
> +static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
> + DIV(0, "hclk_vio", "aclk_vio0", 0,
> + RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
same here
> +};
> +
> static const char *const rk3288_critical_clocks[] __initconst = {
> "aclk_cpu",
> "aclk_peri",
> @@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
> RK3288_GRF_SOC_STATUS1);
> rockchip_clk_register_branches(ctx, rk3288_clk_branches,
> ARRAY_SIZE(rk3288_clk_branches));
> +
> + if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
> + rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
> + ARRAY_SIZE(rk3288w_hclkvio_branch));
> + else
> + rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
> + ARRAY_SIZE(rk3288_hclkvio_branch));
> +
> rockchip_clk_protect_critical(rk3288_critical_clocks,
> ARRAY_SIZE(rk3288_critical_clocks));
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: meson8: remove two invalid interrupt lines from the GPU node
From: Martin Blumenstingl @ 2020-06-01 20:04 UTC (permalink / raw)
To: linux-amlogic, khilman
Cc: Martin Blumenstingl, Thomas Graichen, linux-kernel,
linux-arm-kernel
The 3.10 vendor kernel defines the following GPU 20 interrupt lines:
#define INT_MALI_GP AM_IRQ(160)
#define INT_MALI_GP_MMU AM_IRQ(161)
#define INT_MALI_PP AM_IRQ(162)
#define INT_MALI_PMU AM_IRQ(163)
#define INT_MALI_PP0 AM_IRQ(164)
#define INT_MALI_PP0_MMU AM_IRQ(165)
#define INT_MALI_PP1 AM_IRQ(166)
#define INT_MALI_PP1_MMU AM_IRQ(167)
#define INT_MALI_PP2 AM_IRQ(168)
#define INT_MALI_PP2_MMU AM_IRQ(169)
#define INT_MALI_PP3 AM_IRQ(170)
#define INT_MALI_PP3_MMU AM_IRQ(171)
#define INT_MALI_PP4 AM_IRQ(172)
#define INT_MALI_PP4_MMU AM_IRQ(173)
#define INT_MALI_PP5 AM_IRQ(174)
#define INT_MALI_PP5_MMU AM_IRQ(175)
#define INT_MALI_PP6 AM_IRQ(176)
#define INT_MALI_PP6_MMU AM_IRQ(177)
#define INT_MALI_PP7 AM_IRQ(178)
#define INT_MALI_PP7_MMU AM_IRQ(179)
However, the driver from the 3.10 vendor kernel does not use the
following four interrupt lines:
- INT_MALI_PP3
- INT_MALI_PP3_MMU
- INT_MALI_PP7
- INT_MALI_PP7_MMU
Drop the "pp3" and "ppmmu3" interrupt lines. This is also important
because there is no matching entry in interrupt-names for it (meaning
the "pp2" interrupt is actually assigned to the "pp3" interrupt line).
Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
Reported-by: Thomas Graichen <thomas.graichen@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm/boot/dts/meson8.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index eedb92526968..a4ab8b96d0eb 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -239,8 +239,6 @@ mali: gpu@c0000 {
<GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>,
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-01 19:30 UTC (permalink / raw)
To: Prabhakar Kushwaha, Chen Zhou
Cc: horms, devicetree, bhe, Will Deacon, Linux Doc Mailing List,
Catalin Marinas, kexec mailing list, Linux Kernel Mailing List,
robh+dt, mingo, arnd, guohanjun, James Morse, Thomas Gleixner,
Prabhakar Kushwaha, dyoung, linux-arm-kernel
In-Reply-To: <CAJ2QiJ+1Hj2OQzpR5CfvLGMfTTbXAST94hsbfm0VcDmJKV3WTw@mail.gmail.com>
Hi,
On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> Hi Chen,
>
> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
>> This patch series enable reserving crashkernel above 4G in arm64.
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>> when there is no enough low memory.
>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>> will boot failure because there is no low memory available for allocation.
>>
>> To solve these issues, introduce crashkernel=X,low to reserve specified
>> size low memory.
>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>> size low memory for crash kdump kernel devices firstly and then reserve
>> memory above 4G.
>>
>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>> is specified simultaneously, kernel should reserve specified size low memory
>> for crash dump kernel devices. So there may be two crash kernel regions, one
>> is below 4G, the other is above 4G.
>> In order to distinct from the high region and make no effect to the use of
>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>
>> Besides, we need to modify kexec-tools:
>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>
>> The previous changes and discussions can be retrieved from:
>>
>> Changes since [v7]
>> - Move x86 CRASH_ALIGN to 2M
>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
>> - Update Documentation/devicetree/bindings/chosen.txt
>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
>> - Add Tested-by from Jhon and pk
>>
>> Changes since [v6]
>> - Fix build errors reported by kbuild test robot.
>>
>> Changes since [v5]
>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>> - Delete crashkernel=X,high.
>> - Modify crashkernel=X,low.
>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>> pass to crash dump kernel by DT property "linux,low-memory-range".
>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>
>> Changes since [v4]
>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>
>> Changes since [v3]
>> - Add memblock_cap_memory_ranges back for multiple ranges.
>> - Fix some compiling warnings.
>>
>> Changes since [v2]
>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>> patch.
>>
>> Changes since [v1]:
>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>> in fdt_enforce_memory_region().
>> There are at most two crash kernel regions, for two crash kernel regions
>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>> and then remove the memory range in the middle.
>>
>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
>>
>> Chen Zhou (5):
>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>> arm64: kdump: add memory for devices by DT property, low-memory-range
>> kdump: update Documentation about crashkernel on arm64
>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
>>
> We are getting "warn_alloc" [1] warning during boot of kdump kernel
> with bootargs as [2] of primary kernel.
> This error observed on ThunderX2 ARM64 platform.
>
> It is observed with latest upstream tag (v5.7-rc3) with this patch set
> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> Also **without** this patch-set
> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
>
> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> More details discussed earlier in
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> solution
>
> This patch-set is expected to solve similar kind of issue.
> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> observation should be considered/fixed. .
>
> --pk
>
> [1]
> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> [ 30.367696] NET: Registered protocol family 16
> [ 30.369973] swapper/0: page allocation failure: order:6,
> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> [ 30.369984] Call trace:
> [ 30.369989] dump_backtrace+0x0/0x1f8
> [ 30.369991] show_stack+0x20/0x30
> [ 30.369997] dump_stack+0xc0/0x10c
> [ 30.370001] warn_alloc+0x10c/0x178
> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> [ 30.370008] alloc_page_interleave+0x24/0x98
> [ 30.370011] alloc_pages_current+0xe4/0x108
> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> [ 30.370020] do_one_initcall+0x54/0x228
> [ 30.370027] kernel_init_freeable+0x228/0x2cc
> [ 30.370031] kernel_init+0x1c/0x110
> [ 30.370034] ret_from_fork+0x10/0x18
> [ 30.370036] Mem-Info:
> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> unstable:0kB all_unreclaimable? no
> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> unstable:0kB all_unreclaimable? no
> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> [ 30.370104] lowmem_reserve[]: 0 0 0 0
> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=1048576kB
> [ 30.370130] 0 total pagecache pages
> [ 30.370132] 0 pages in swap cache
> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> [ 30.370135] Free swap = 0kB
> [ 30.370136] Total swap = 0kB
> [ 30.370137] 2164609 pages RAM
> [ 30.370139] 0 pages HighMem/MovableOnly
> [ 30.370140] 612331 pages reserved
> [ 30.370141] 0 pages hwpoisoned
> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> coherent allocation
During my testing I saw the same error and Chen's solution corrected it .
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb
From: Lukasz Stelmach @ 2020-06-01 18:48 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20200601150745.GL1551@shell.armlinux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 14891 bytes --]
It was <2020-06-01 pon 16:07>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
>> This is kexec_file_load implementation for ARM. It loads zImage and
>> initrd from file descripters and resuses DTB.
>>
>> Most code is derived from arm64 kexec_file_load implementation
>> and from kexec-tools.
>
> Please make the uImage loader able to be configured out of the
> kernel; it's a legacy image format now, and some of us just don't
> use it anymore. That way, those who wish to have it can, and
> those who wish not to can have a smaller kernel.
The difference in size of arch/arm/boot/Image is 160 bytes, but
OK. Done.
>> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> ---
>> arch/arm/Kconfig | 15 ++
>> arch/arm/include/asm/image.h | 26 ++++
>> arch/arm/include/asm/kexec.h | 14 ++
>> arch/arm/kernel/Makefile | 5 +-
>> arch/arm/kernel/kexec_uimage.c | 80 ++++++++++
>> arch/arm/kernel/kexec_zimage.c | 199 +++++++++++++++++++++++++
>> arch/arm/kernel/machine_kexec.c | 11 +-
>> arch/arm/kernel/machine_kexec_file.c | 209 +++++++++++++++++++++++++++
>> 8 files changed, 554 insertions(+), 5 deletions(-)
>> create mode 100644 arch/arm/kernel/kexec_uimage.c
>> create mode 100644 arch/arm/kernel/kexec_zimage.c
>> create mode 100644 arch/arm/kernel/machine_kexec_file.c
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index c77c93c485a0..6adb849cb304 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1917,6 +1917,21 @@ config KEXEC
>> is properly shutdown, so do not be surprised if this code does not
>> initially work for you.
>>
>> +config KEXEC_FILE
>> + bool "Kexec file based system call (EXPERIMENTAL)"
>> + depends on (!SMP || PM_SLEEP_SMP)
>> + depends on USE_OF
>> + select KEXEC_CORE
>> + select CRC32
>> + help
>> + This is new version of kexec system call. This system call is
>> + file based and takes file descriptors as system call argument
>> + for kernel and initramfs as opposed to list of segments as
>> + accepted by previous system call.
>> +
>> + The kernel to be loaded MUST support Flattened Device Tree
>> + (selected with CONFIG_USE_OF).
>> +
>> config ATAGS_PROC
>> bool "Export atags in procfs"
>> depends on ATAGS && KEXEC
>> diff --git a/arch/arm/include/asm/image.h b/arch/arm/include/asm/image.h
>> index 624438740f23..95f23837b04f 100644
>> --- a/arch/arm/include/asm/image.h
>> +++ b/arch/arm/include/asm/image.h
>> @@ -8,8 +8,13 @@
>> (((x) >> 8) & 0x0000ff00) | \
>> (((x) << 8) & 0x00ff0000) | \
>> (((x) << 24) & 0xff000000))
>> +#define UIMAGE_MAGIC(x) (x)
>> #else
>> #define ZIMAGE_MAGIC(x) (x)
>> +#define UIMAGE_MAGIC(x) ((((x) >> 24) & 0x000000ff) | \
>> + (((x) >> 8) & 0x0000ff00) | \
>> + (((x) << 8) & 0x00ff0000) | \
>> + (((x) << 24) & 0xff000000))
>> #endif
>>
>> #define ARM_ZIMAGE_MAGIC1 ZIMAGE_MAGIC(0x016f2818)
>> @@ -17,6 +22,12 @@
>> #define ARM_ZIMAGE_MAGIC3 ZIMAGE_MAGIC(0x5a534c4b)
>> #define ARM_ZIMAGE_MAGIC4 ZIMAGE_MAGIC(0x5a534344)
>>
>> +#define ARM_UIMAGE_MAGIC UIMAGE_MAGIC(0x27051956)
>> +#define ARM_UIMAGE_NAME_LEN 32
>> +#define ARM_UIMAGE_TYPE_KERNEL 2
>> +#define ARM_UIMAGE_TYPE_KERNEL_NOLOAD 14
>> +#define ARM_UIMAGE_ARCH_ARM 2
>> +
>> #ifndef __ASSEMBLY__
>>
>> #include <linux/types.h>
>> @@ -33,6 +44,21 @@ struct arm_zimage_header {
>> __le32 extension_tag_offset;
>> };
>>
>> +struct arm_uimage_header {
>> + __be32 magic;
>> + __be32 hdr_crc;
>> + __be32 time;
>> + __be32 size;
>> + __be32 load;
>> + __be32 entry;
>> + __be32 crc;
>> + __u8 os;
>> + __u8 arch;
>> + __u8 type;
>> + __u8 comp;
>> + __u8 name[ARM_UIMAGE_NAME_LEN];
>> +};
>> +
>> struct arm_zimage_tag {
>> struct tag_header hdr;
>> union {
>> diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
>> index 22751b5b5735..fda35afa7195 100644
>> --- a/arch/arm/include/asm/kexec.h
>> +++ b/arch/arm/include/asm/kexec.h
>> @@ -83,6 +83,20 @@ static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
>> }
>> #define boot_pfn_to_page boot_pfn_to_page
>>
>> +#ifdef CONFIG_KEXEC_FILE
>> +
>> +extern const struct kexec_file_ops kexec_zimage_ops;
>> +extern const struct kexec_file_ops kexec_uimage_ops;
>> +
>> +struct kimage;
>> +
>> +extern int load_other_segments(struct kimage *image,
>> + unsigned long kernel_load_addr, unsigned long kernel_size,
>> + char *initrd, unsigned long initrd_len,
>> + unsigned long initrd_offset, char *cmdline);
>> +
>> +#endif /* CONFIG_KEXEC_FILE */
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif /* CONFIG_KEXEC */
>> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
>> index 89e5d864e923..466c683bb551 100644
>> --- a/arch/arm/kernel/Makefile
>> +++ b/arch/arm/kernel/Makefile
>> @@ -3,6 +3,7 @@
>> # Makefile for the linux kernel.
>> #
>>
>> +CFLAGS_kexec_zimage.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
>> CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
>> AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
>>
>> @@ -56,7 +57,9 @@ obj-$(CONFIG_FUNCTION_TRACER) += entry-ftrace.o
>> obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o insn.o patch.o
>> obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o insn.o patch.o
>> obj-$(CONFIG_JUMP_LABEL) += jump_label.o insn.o patch.o
>> -obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
>> +obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o
>> +obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_zimage.o \
>> + kexec_uimage.o
>> # Main staffs in KPROBES are in arch/arm/probes/ .
>> obj-$(CONFIG_KPROBES) += patch.o insn.o
>> obj-$(CONFIG_OABI_COMPAT) += sys_oabi-compat.o
>> diff --git a/arch/arm/kernel/kexec_uimage.c b/arch/arm/kernel/kexec_uimage.c
>> new file mode 100644
>> index 000000000000..47033574e24e
>> --- /dev/null
>> +++ b/arch/arm/kernel/kexec_uimage.c
>> @@ -0,0 +1,80 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Kexec uImage loader
>> + *
>> + * Copyright (C) 2020 Samsung Electronics
>> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
>> + */
>> +
>> +#define pr_fmt(fmt) "kexec_file(uImage): " fmt
>> +
>> +#include <asm/image.h>
>> +#include <linux/crc32.h>
>> +#include <linux/err.h>
>> +#include <linux/kexec.h>
>> +
>> +#define crc32_ones(crc, buf, len) \
>> + (crc32(crc ^ 0xffffffff, buf, len) ^ 0xffffffff)
>> +
>> +static int uimage_probe(const char *uimage_buf, unsigned long uimage_len)
>> +{
>> + const struct arm_uimage_header *h =
>> + (struct arm_uimage_header *) uimage_buf;
>> + struct arm_uimage_header uhdr;
>> + unsigned long zoff = sizeof(struct arm_uimage_header);
>> + uint32_t crc;
>> +
>> + if (h->magic != ARM_UIMAGE_MAGIC)
>> + return -EINVAL;
>> +
>> + if (h->type != ARM_UIMAGE_TYPE_KERNEL &&
>> + h->type != ARM_UIMAGE_TYPE_KERNEL_NOLOAD){
>> + pr_debug("Invalid image type: %d\n", h->type);
>> + return -EINVAL;
>> + }
>> +
>> + if (h->arch != ARM_UIMAGE_ARCH_ARM) {
>> + pr_debug("Invalidy image arch: %d\n", h->arch);
>> + return -EINVAL;
>> + }
>> +
>> + memcpy((char *)&uhdr, h, sizeof(uhdr));
>> + crc = be32_to_cpu(uhdr.hdr_crc);
>> + uhdr.hdr_crc = 0;
>> +
>> + if (crc32_ones(0, (char *)&uhdr, sizeof(uhdr)) != crc) {
>> + pr_debug("Corrupt header, CRC do not match\n");
>> + return -EINVAL;
>> + }
>> +
>> + crc = be32_to_cpu(uhdr.crc);
>> + if (crc32_ones(0, uimage_buf + zoff, uimage_len - zoff) != crc) {
>> + pr_debug("Corrupt zImage, CRC do not match\n");
>> + return -EINVAL;
>> + }
>> +
>> + return kexec_zimage_ops.probe(uimage_buf + zoff,
>> + uimage_len - zoff);
>> +}
>> +
>> +static void *uimage_load(struct kimage *image,
>> + char *uimage, unsigned long uimage_len,
>> + char *initrd, unsigned long initrd_len,
>> + char *cmdline, unsigned long cmdline_len)
>> +{
>> + const struct arm_uimage_header *h =
>> + (struct arm_uimage_header *) uimage;
>> + unsigned long zimage_offset = sizeof(struct arm_uimage_header);
>> +
>> + pr_debug("Loading uImage");
>> + return kexec_zimage_ops.load(image,
>> + uimage + zimage_offset,
>> + uimage_len - zimage_offset,
>> + initrd, initrd_len,
>> + cmdline, cmdline_len);
>> +}
>> +
>> +const struct kexec_file_ops kexec_uimage_ops = {
>> + .probe = uimage_probe,
>> + .load = uimage_load,
>> +};
>> diff --git a/arch/arm/kernel/kexec_zimage.c b/arch/arm/kernel/kexec_zimage.c
>> new file mode 100644
>> index 000000000000..d09795fc9072
>> --- /dev/null
>> +++ b/arch/arm/kernel/kexec_zimage.c
>> @@ -0,0 +1,199 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Kexec zImage loader
>> + *
>> + * Copyright (C) 2020 Samsung Electronics
>> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
>
> Please credit me as part author of this - you have taken some of my
> code from the userspace kexec tool (such as the contents of
> find_extension_tag()) and copied it in here, so this is not all your
> own work.
Done.
>> + */
>> +
>> +#define pr_fmt(fmt) "kexec_file(zImage): " fmt
>> +
>> +#include <asm/image.h>
>> +#include <asm/unaligned.h>
>> +#include <linux/err.h>
>> +#include <linux/kexec.h>
>> +#include <linux/memblock.h>
>> +
>> +#define byte_size(t) ((t)->hdr.size << 2)
>> +
>> +static const void *find_extension_tag(const char *buf,
>> + unsigned long len,
>> + uint32_t tag_id)
>> +{
>> + const struct arm_zimage_header *h = (const struct arm_zimage_header *)buf;
>> + const struct arm_zimage_tag *tag;
>> + uint32_t offset, size;
>> + uint32_t max = len - sizeof(struct tag_header);
>> +
>> + if (len < sizeof(*h) ||
>> + h->magic != ARM_ZIMAGE_MAGIC1 ||
>> + h->magic2 != ARM_ZIMAGE_MAGIC2)
>> + return NULL;
>> +
>> + for (offset = h->extension_tag_offset;
>> + (tag = (void *)(buf + offset)) != NULL &&
>> + offset < max &&
>> + (size = le32_to_cpu(byte_size(tag))) != 0 &&
>> + offset + size < len;
>> + offset += size) {
>> + pr_debug(" offset 0x%08x tag 0x%08x size %u\n",
>> + offset, le32_to_cpu(tag->hdr.tag), size);
>> + if (tag->hdr.tag == tag_id)
>> + return tag;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static int zimage_probe(const char *kernel_buf, unsigned long kernel_len)
>> +{
>> + const struct arm_zimage_header *h =
>> + (struct arm_zimage_header *)(kernel_buf);
>> +
>> + if (!h || (kernel_len < sizeof(*h)))
>> + return -EINVAL;
>> +
>> + if ((h->magic != ARM_ZIMAGE_MAGIC1) ||
>> + (h->magic2 != ARM_ZIMAGE_MAGIC2))
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +
>> +#if defined(DEBUG)
>> +#define debug_offsets() ({ \
>> + pr_debug("Image offsets:\n"); \
>> + pr_debug(" kernel 0x%08lx 0x%08lx\n", kernel_offset, kernel_len); \
>> + pr_debug(" zimage 0x%08lx 0x%08lx\n", zimage_offset, zimage_len); \
>> + pr_debug(" initrd 0x%08lx 0x%08lx\n", initrd_offset, initrd_len); \
>> +})
>> +#else
>> +#define debug_offsets()
>> +#endif
>> +
>> +static void *zimage_load(struct kimage *image,
>> + char *zimage, unsigned long zimage_len,
>> + char *initrd, unsigned long initrd_len,
>> + char *cmdline, unsigned long cmdline_len)
>> +{
>> + struct arm_zimage_header *h;
>> + struct kexec_buf kbuf;
>> + struct kexec_segment *zimage_segment;
>> + const struct arm_zimage_tag *klsz_tag;
>> + const struct arm_zimage_tag_dc *dcsz_tag;
>> + int ret = -EINVAL;
>> +
>> + unsigned long zimage_mem = 0x20000; /* malloc 64kB + stack 4 kB + some bss */
>> + unsigned long kernel_len = zimage_len * 4; /* 4:1 compression */
>
> This has been proven wrong.
5:1? The comment and the code in kexec-tools are inconsisten in this
regard. The comment says 4:1, but the code multiplies by 5. Your
recommendation? This value is used as a fallback anyway in a very
unlikely case, when tags are missing (see below).
>> + unsigned long kernel_offset = memblock_start_of_DRAM() +
>> + ALIGN(TEXT_OFFSET, PAGE_SIZE);
>
> TEXT_OFFSET is actually a property of the loaded kernel, not of the
> currently running kernel.
Indeed.
> I have a patch to add that into the zImage tag.
I am afraid, I haven't seen it before. Where can I find it?
>> + unsigned long zimage_offset = kernel_offset +
>> + ALIGN(kernel_len, PAGE_SIZE);
>> + unsigned long initrd_offset = zimage_offset +
>> + ALIGN(zimage_len + zimage_mem, PAGE_SIZE);
>
> Since kernel_len is wrong, these will be wrong... please only fall
> back to this if you don't find the extension tag - in other words,
> declare the variables here, but don't initialise them, set them
> lower down in the file if we fail to find the extension tag.
That is how it works now. This is the structure I have taken from
kexec-tools: initialize and change if additional information is
available. If the tags are not available use these values as a fallback.
>> +
>> + if (image->type == KEXEC_TYPE_CRASH) {
>> + kernel_offset += crashk_res.start;
>> + zimage_offset += crashk_res.start;
>> + initrd_offset += crashk_res.start;
>> + }
>> + debug_offsets();
>> +
>> + h = (struct arm_zimage_header *)zimage;
>> +
>> + klsz_tag = find_extension_tag(zimage, zimage_len, ZIMAGE_TAG_KRNL_SIZE);
>> + if (klsz_tag) {
>> + uint32_t *p = (void *)zimage +
>> + le32_to_cpu(klsz_tag->u.krnl_size.size_ptr);
>> + uint32_t edata_size = le32_to_cpu(get_unaligned(p));
>> + uint32_t bss_size = le32_to_cpu(klsz_tag->u.krnl_size.bss_size);
>> +
>> + kernel_len = edata_size + bss_size;
>> +
>> + pr_debug("Decompressed kernel sizes:\n");
>> + pr_debug(" text+data 0x%08lx bss 0x%08lx total 0x%08lx\n",
>> + (unsigned long)edata_size,
>> + (unsigned long)bss_size,
>> + (unsigned long)kernel_len);
>> +
>> + zimage_offset = kernel_offset + ALIGN(edata_size, PAGE_SIZE);
>> + initrd_offset = zimage_offset +
>> + max(ALIGN(zimage_len + 0x20000, PAGE_SIZE),
>> + ALIGN((unsigned long)bss_size, PAGE_SIZE));
>> + debug_offsets();
>
> This looks incorrect to me. Please see the kexec tool - what its doing
> in its corresponding section that you copied some of this code from is
> carefully thought out and can't be simplified. Ergo, I think this is
> wrong.
As I explained in <dleftjwo4qsqqf.fsf%l.stelmach@samsung.com> my
approach is slightly different. I am trying to avoid copying zImage by
putting it hight enough in the first place.
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V6, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Tomasz Figa @ 2020-06-01 18:47 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男), Louis Kuo,
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <1590570089.8804.453.camel@mhfsdcap03>
On Wed, May 27, 2020 at 11:03 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Mon, 2020-05-25 at 13:45 +0200, Tomasz Figa wrote:
> > On Fri, May 22, 2020 at 11:27 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Tomasz,
> > >
> > > Thanks for the review. My replies are as below.
> > >
> > > On Thu, 2020-05-21 at 19:51 +0000, Tomasz Figa wrote:
> > > > Hi Dongchun, Sakari,
> > > >
> > > > On Mon, May 18, 2020 at 09:27:31PM +0800, Dongchun Zhu wrote:
> > [snip]
> > > > > + pm_runtime_enable(dev);
> > > > > + if (!pm_runtime_enabled(dev)) {
> > > > > + ret = dw9768_runtime_resume(dev);
> > > > > + if (ret < 0) {
> > > > > + dev_err(dev, "failed to power on: %d\n", ret);
> > > > > + goto entity_cleanup;
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + ret = v4l2_async_register_subdev(&dw9768->sd);
> > > > > + if (ret < 0)
> > > > > + goto entity_cleanup;
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > +entity_cleanup:
> > > >
> > > > Need to power off if the code above powered on.
> > > >
> > >
> > > Thanks for the reminder.
> > > If there is something wrong with runtime PM, actuator is to be powered
> > > on via dw9768_runtime_resume() API.
> > > When actuator sub-device is powered on completely and async registered
> > > successfully, we shall power off it afterwards.
> > >
> >
> > The code above calls dw9768_runtime_resume() if
> > !pm_runtime_enabled(dev), but the clean-up code below the
> > entity_cleanup label doesn't have the corresponding
> > dw9768_runtime_suspend() call.
> >
>
> Did you mean the 'entity_cleanup' after v4l2_async_register_subdev()?
Yes.
> Actually I made some changes for OV02A V9, according to this comment.
> Could you help review that change? Thanks.
Sure, I will take a look.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl-single: fix pcs_parse_pinconf() return val
From: Gustavo A. R. Silva @ 2020-06-01 18:51 UTC (permalink / raw)
To: Drew Fustini, Tony Lindgren, Haojian Zhuang, Linus Walleij,
linux-arm-kernel, linux-omap, linux-gpio, linux-kernel
Cc: Jason Kridner, Robert Nelson
In-Reply-To: <20200531204147.GA664833@x1>
On 5/31/20 15:41, Drew Fustini wrote:
> This patch causes pcs_parse_pinconf() to return an error when no
> pinctrl_map is added. The current behavior is to return 0 when
> !PCS_HAS_PINCONF or !nconfs. Thus pcs_parse_one_pinctrl_entry()
> incorrectly assumes that a map was added and sets num_maps = 2.
>
> Analysis:
> =========
> The function pcs_parse_one_pinctrl_entry() calls pcs_parse_pinconf()
> if PCS_HAS_PINCONF is enabled. The function pcs_parse_pinconf()
> returns 0 to indicate there was no error and num_maps is then set to 2:
>
> 980 static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
> 981 struct device_node *np,
> 982 struct pinctrl_map **map,
> 983 unsigned *num_maps,
> 984 const char **pgnames)
> 985 {
> <snip>
> 1053 (*map)->type = PIN_MAP_TYPE_MUX_GROUP;
> 1054 (*map)->data.mux.group = np->name;
> 1055 (*map)->data.mux.function = np->name;
> 1056
> 1057 if (PCS_HAS_PINCONF && function) {
> 1058 res = pcs_parse_pinconf(pcs, np, function, map);
> 1059 if (res)
> 1060 goto free_pingroups;
> 1061 *num_maps = 2;
> 1062 } else {
> 1063 *num_maps = 1;
> 1064 }
>
> However, pcs_parse_pinconf() will also return 0 if !PCS_HAS_PINCONF or
> !nconfs. I believe these conditions should indicate that no map was
> added by returning non-zero. Otherwise pcs_parse_one_pinctrl_entry()
> will set num_maps = 2 even though no maps were successfully added, as
> it does not reach "m++" on line 940:
>
> 895 static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
> 896 struct pcs_function *func,
> 897 struct pinctrl_map **map)
> 898
> 899 {
> 900 struct pinctrl_map *m = *map;
> <snip>
> 917 /* If pinconf isn't supported, don't parse properties in below. */
> 918 if (!PCS_HAS_PINCONF)
> 919 return 0;
> 920
> 921 /* cacluate how much properties are supported in current node */
> 922 for (i = 0; i < ARRAY_SIZE(prop2); i++) {
> 923 if (of_find_property(np, prop2[i].name, NULL))
> 924 nconfs++;
> 925 }
> 926 for (i = 0; i < ARRAY_SIZE(prop4); i++) {
> 927 if (of_find_property(np, prop4[i].name, NULL))
> 928 nconfs++;
> 929 }
> 930 if (!nconfs)
> 919 return 0;
> 932
> 933 func->conf = devm_kcalloc(pcs->dev,
> 934 nconfs, sizeof(struct pcs_conf_vals),
> 935 GFP_KERNEL);
> 936 if (!func->conf)
> 937 return -ENOMEM;
> 938 func->nconfs = nconfs;
> 939 conf = &(func->conf[0]);
> 940 m++;
>
> This situtation will cause a boot failure [0] on the BeagleBone Black
> (AM3358) when am33xx_pinmux node in arch/arm/boot/dts/am33xx-l4.dtsi
> has compatible = "pinconf-single" instead of "pinctrl-single".
>
> The patch fixes this issue by returning -ENOSUPP when !PCS_HAS_PINCONF
> or !nconfs, so that pcs_parse_one_pinctrl_entry() will know that no
> map was added.
>
> [0] https://lore.kernel.org/linux-omap/20200529175544.GA3766151@x1/
>
Maybe add this Fixes tag here:
Fixes: 9dddb4df90d1 ("pinctrl: single: support generic pinconf")
--
Gustavo
> Signed-off-by: Drew Fustini <drew@beagleboard.org>
> ---
> drivers/pinctrl/pinctrl-single.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index 1e0614daee9b..18a02cd0c701 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -916,7 +916,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
>
> /* If pinconf isn't supported, don't parse properties in below. */
> if (!PCS_HAS_PINCONF)
> - return 0;
> + return -ENOTSUPP; /* do not return 0 as no map added */
>
> /* cacluate how much properties are supported in current node */
> for (i = 0; i < ARRAY_SIZE(prop2); i++) {
> @@ -928,7 +928,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
> nconfs++;
> }
> if (!nconfs)
> - return 0;
> + return -ENOTSUPP; /* do not return 0 as no map added */
>
> func->conf = devm_kcalloc(pcs->dev,
> nconfs, sizeof(struct pcs_conf_vals),
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: Mark Brown @ 2020-06-01 18:46 UTC (permalink / raw)
To: David Miller
Cc: stephane.leprovost, bgolaszewski, netdev, brgl, sean.wang,
linux-kernel, fparent, pedro.tsai, linux-mediatek,
andrew.perepech, john, matthias.bgg, kuba, Mark-MC.Lee,
linux-arm-kernel
In-Reply-To: <20200601.113536.134620919829517847.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 496 bytes --]
On Mon, Jun 01, 2020 at 11:35:36AM -0700, David Miller wrote:
> > v2 -> v3:
> > - drop unneeded ternary operator
> Series applied to net-next, thank you.
I already applied patch 1 and sent a pull request to Linus for it. As I
said:
| Let me know if you need a pull request for this, given the merge window
| is likely to open over the weekend I figured it's likely too late to
| apply the second patch before then.
Hopefully this merges cleanly... ideally we'd have had that pull
request.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/3] media: rockchip: Introduce driver for the camera interface on PX30
From: Tomasz Figa @ 2020-06-01 18:45 UTC (permalink / raw)
To: Maxime Chevallier, Helen Koike, Dafna Hirschfeld
Cc: Mark Rutland, linux-devicetree, Heiko Stuebner,
Linux Kernel Mailing List, Paul Kocialkowski,
open list:ARM/Rockchip SoC..., Rob Herring, Thomas Petazzoni,
Miquel Raynal, Hans Verkuil, Mauro Carvalho Chehab, Robin Murphy,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <20200529130405.929429-1-maxime.chevallier@bootlin.com>
Hi Maxime,
On Fri, May 29, 2020 at 3:04 PM Maxime Chevallier
<maxime.chevallier@bootlin.com> wrote:
>
> Hello everyone,
>
> Here's a V2 of the series adding very basic support for the camera interface on
> the Rockchip PX30 SoC.
>
> Thanks to everyone that commented on the first series, your reviews were
> very helpful :)
>
> This Camera Interface is also supported on other Rockchip SoC such as
> the RK1808, RK3128, RK3288 and RK3288, but for now I've only been able to
> test it on the PX30, using a PAL format.
How does this hardware relate to the one handled by the rkisp1 driver
that is available under staging/media/rkisp1? It was written with
RK3399 in mind, but I have a loose recollection that the hardware in
RK3288 was roughly the same.
+Helen Koike +Dafna Hirschfeld working on the rkisp1 driver.
Best regards,
Tomasz
>
> This driver is mostly based on the driver found in Rockchip's BSP, that
> has been trimmed down to support the set of features that I was able to test,
> that is pretty much a very basic one-frame capture and video streaming
> with GStreamer.
>
> This first draft only supports the Parallel interface, although the
> controller has support for BT656 and CSI2.
>
> Finally, this controller has an iommu that could be used in this driver,
> but as of today I've not been able to get it to work.
>
> Any review is welcome.
>
> Thanks,
>
> Maxime
>
> --- Changes since V1 ---
>
> - Took reviews from Rob, Hans, Robin and Heiko into account :
> - Renamed the clocks in the binding
> - Fixed the DT schema compiling
> - Fixed a few typos
> - Used the clk bulk API
> - Used the reset array API
> - Changed a few helpers for more suitable ones
> - Rebased on 5.7-rc7
>
>
>
> Maxime Chevallier (3):
> media: dt-bindings: media: Document Rockchip CIF bindings
> media: rockchip: Introduce driver for Rockhip's camera interface
> arm64: dts: rockchip: Add the camera interface description of the PX30
>
> .../bindings/media/rockchip-cif.yaml | 100 ++
> arch/arm64/boot/dts/rockchip/px30.dtsi | 12 +
> drivers/media/platform/Kconfig | 13 +
> drivers/media/platform/Makefile | 1 +
> drivers/media/platform/rockchip/cif/Makefile | 3 +
> drivers/media/platform/rockchip/cif/capture.c | 1170 +++++++++++++++++
> drivers/media/platform/rockchip/cif/dev.c | 358 +++++
> drivers/media/platform/rockchip/cif/dev.h | 213 +++
> drivers/media/platform/rockchip/cif/regs.h | 256 ++++
> 9 files changed, 2126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
> create mode 100644 drivers/media/platform/rockchip/cif/Makefile
> create mode 100644 drivers/media/platform/rockchip/cif/capture.c
> create mode 100644 drivers/media/platform/rockchip/cif/dev.c
> create mode 100644 drivers/media/platform/rockchip/cif/dev.h
> create mode 100644 drivers/media/platform/rockchip/cif/regs.h
>
> --
> 2.25.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: David Miller @ 2020-06-01 18:35 UTC (permalink / raw)
To: brgl
Cc: stephane.leprovost, bgolaszewski, netdev, sean.wang, linux-kernel,
pedro.tsai, fparent, broonie, linux-mediatek, andrew.perepech,
john, matthias.bgg, kuba, Mark-MC.Lee, linux-arm-kernel
In-Reply-To: <20200528154503.26304-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Thu, 28 May 2020 17:45:01 +0200
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> I noticed that oftentimes I use regmap_update_bits() for simple bit
> setting or clearing. In this case the fourth argument is superfluous as
> it's always 0 or equal to the mask argument.
>
> This series proposes to add simple bit operations for setting, clearing
> and testing specific bits with regmap.
>
> The second patch uses all three in a driver that got recently picked into
> the net-next tree.
>
> The patches obviously target different trees so - if you're ok with
> the change itself - I propose you pick the first one into your regmap
> tree for v5.8 and then I'll resend the second patch to add the first
> user for these macros for v5.9.
>
> v1 -> v2:
> - convert the new macros to static inline functions
>
> v2 -> v3:
> - drop unneeded ternary operator
Series applied to net-next, thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: pxa: pxa2xx: Remove 'pxa2xx_pinctrl_exit()' which is unused and broken
From: Dan Carpenter @ 2020-06-01 18:31 UTC (permalink / raw)
To: Christophe JAILLET
Cc: linus.walleij, kernel-janitors, linux-kernel, haojian.zhuang,
linux-gpio, daniel, Robert Jarzmik, linux-arm-kernel
In-Reply-To: <a2e34c9a-676f-d83f-f395-7428af038c16@wanadoo.fr>
On Mon, Jun 01, 2020 at 01:31:23PM +0200, Christophe JAILLET wrote:
> Le 01/06/2020 à 10:58, Robert Jarzmik a écrit :
> > Christophe JAILLET <christophe.jaillet@wanadoo.fr> writes:
> >
> > > Commit 6d33ee7a0534 ("pinctrl: pxa: Use devm_pinctrl_register() for pinctrl registration")
> > > has turned a 'pinctrl_register()' into 'devm_pinctrl_register()' in
> > > 'pxa2xx_pinctrl_init()'.
> > > However, the corresponding 'pinctrl_unregister()' call in
> > > 'pxa2xx_pinctrl_exit()' has not been removed.
> > >
> > > This is not an issue, because 'pxa2xx_pinctrl_exit()' is unused.
> > > Remove it now to avoid some wondering in the future and save a few LoC.
> > >
> > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >
> > Would be even a better patch with a :
> > Fixes: 6d33ee7a0534 ("pinctrl: pxa: Use devm_pinctrl_register() for pinctrl registration")
>
> I was wondering it was was needed in this case.
> The patch does not really fix anything, as the function is unused. Or it
> fixes things on a theoretical point of view.
There is no concensus... We should call a vote on this at Kernel
Summit. :P
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox