* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Ard Biesheuvel @ 2018-06-12 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528785361-24477-1-git-send-email-bhsharma@redhat.com>
On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> The start of the linear region map on a KASLR enabled ARM64 machine -
> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
> support), is no longer correctly represented by the PAGE_OFFSET macro,
> since it is defined as:
>
> (UL(1) << (VA_BITS - 1)) + 1)
>
PAGE_OFFSET is the VA of the start of the linear map. The linear map
can be sparsely populated with actual memory, regardless of whether
KASLR is in effect or not. The only difference in the presence of
KASLR is that there may be such a hole at the beginning, but that does
not mean the linear map has moved, or that the value of PAGE_OFFSET is
now wrong.
> So taking an example of a platform with VA_BITS=48, this gives a static
> value of:
> PAGE_OFFSET = 0xffff800000000000
>
> However, for the KASLR case, we use the 'memstart_offset_seed'
> to randomize the linear region - since 'memstart_addr' indicates the
> start of physical RAM, we randomize the same on basis
> of 'memstart_offset_seed' value.
>
> As the PAGE_OFFSET value is used presently by several user space
> tools (for e.g. makedumpfile and crash tools) to determine the start
> of linear region and hence to read addresses (like PT_NOTE fields) from
> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
> use 'memblock_start_of_DRAM()' value (converted to virtual) as
> the start of linear region for the KASLR cases and default to
> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
> linear region.
>
Userland code that assumes that the linear map cannot have a hole at
the beginning should be fixed.
> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
> and was able to use a modified user space utility (like kexec-tools and
> makedumpfile) to determine the start of linear region correctly for
> both the KASLR and non-KASLR boot cases.
>
Can you explain the nature of the changes to the userland code?
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: James Morse <james.morse@arm.com>
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> ---
> arch/arm64/include/asm/memory.h | 3 +++
> arch/arm64/kernel/arm64ksyms.c | 1 +
> arch/arm64/mm/init.c | 3 +++
> 3 files changed, 7 insertions(+)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 49d99214f43c..bfd0915ecaf8 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
> /* PHYS_OFFSET - the physical address of the start of memory. */
> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>
> +/* the virtual base of the linear region. */
> +extern s64 linear_reg_start_addr;
> +
> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
> extern u64 kimage_vaddr;
>
> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
> index d894a20b70b2..a92238ea45ff 100644
> --- a/arch/arm64/kernel/arm64ksyms.c
> +++ b/arch/arm64/kernel/arm64ksyms.c
> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>
> /* physical memory */
> EXPORT_SYMBOL(memstart_addr);
> +EXPORT_SYMBOL(linear_reg_start_addr);
>
> /* string / mem functions */
> EXPORT_SYMBOL(strchr);
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 325cfb3b858a..29447adb0eef 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -60,6 +60,7 @@
> * that cannot be mistaken for a real physical address.
> */
> s64 memstart_addr __ro_after_init = -1;
> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>
> #ifdef CONFIG_BLK_DEV_INITRD
> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
> }
> }
>
> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
> +
> /*
> * Register the kernel text, kernel data, initrd, and initial
> * pagetables with memblock.
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] pwm: stm32: fix build warning with CONFIG_DMA_ENGINE disabled
From: Geert Uytterhoeven @ 2018-06-12 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525210843.1821071-1-arnd@arndb.de>
Hi Arnd,
On Fri, May 25, 2018 at 11:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
> Without dmaengine support, we get a harmless warning about an
> unused function:
>
> drivers/pwm/pwm-stm32.c:166:12: error: 'stm32_pwm_capture' defined but not used [-Werror=unused-function]
>
> Changing the #ifdef to an IS_ENABLED() check shuts up that warning
> and is slightly nicer to read.
>
> Fixes: 53e38fe73f94 ("pwm: stm32: Add capture support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks!
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> --- a/drivers/pwm/pwm-stm32.c
> +++ b/drivers/pwm/pwm-stm32.c
> @@ -484,9 +484,7 @@ static int stm32_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device *pwm,
> static const struct pwm_ops stm32pwm_ops = {
> .owner = THIS_MODULE,
> .apply = stm32_pwm_apply_locked,
> -#if IS_ENABLED(CONFIG_DMA_ENGINE)
> - .capture = stm32_pwm_capture,
> -#endif
> + .capture = IS_ENABLED(CONFIG_DMA_ENGINE) ? stm32_pwm_capture : NULL,
Cool, I didn't know IS_ENABLED() can be used in static initializers.
I guess it's too late/much work to use this trick in e.g. SET_*_PM_OPS(),
as there are lots of places protecting the functions by #ifdefs?
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Marek Szyprowski @ 2018-06-12 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611123104.GD1050@arm.com>
On 2018-06-11 14:31, Will Deacon wrote:
> On Mon, Jun 11, 2018 at 09:55:54AM +0200, Geert Uytterhoeven wrote:
>> Hi Marek,
>>
>> Thanks for your patch!
>>
>> On Mon, Jun 11, 2018 at 7:14 AM Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>> dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
>>> they should be cleared on allocation. In case of IOMMU-based dma-mapping
>>> implementation such buffer clearing was missing in the code path for
>>> DMA_ATTR_FORCE_CONTIGUOUS flag handling. This patch fixes this issue. For
>> Is it? The memory is allocated using dma_alloc_from_contiguous(..., gfp),
>> and __iommu_alloc_attrs() has
>>
>> /*
>> * Some drivers rely on this, and we probably don't want the
>> * possibility of stale kernel data being read by devices anyway.
>> */
>> gfp |= __GFP_ZERO;
>>
>> at the top, before the allocation.
>>
>> If cma_alloc() (called from dma_alloc_from_contiguous()) doesn't honor
>> __GFP_ZERO, I think cma_alloc() should be fixed instead.
> Agreed. We tried to fix this in 7132813c3845 ("arm64: Honor __GFP_ZERO in
> dma allocations"). Has something broken that?
The code for handling DMA_ATTR_FORCE_CONTIGUOUS flag in arm64
dma-mapping/iommu
implementation has been added later and assumed that __GFP_ZERO flag is
handled by dma_alloc_from_contiguous(). This is sadly not true, so the
buffer
allocated this way is not cleared.
In case of ARM (32bit) the newly allocated buffer is always cleared directly
after calling dma_alloc_from_contiguous() function.
I agree that adding handling of __GFP_ZERO flag to
dma_alloc_from_contiguous()
or rather cma_alloc() is a better idea, but might have some side effects, so
such change is not a good candidate for -rc cycle. I will prepare such
patch,
but for now this one is imho a bit less invasive approach.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Geert Uytterhoeven @ 2018-06-12 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612073124eucas1p18fd911ee122fea0939df7ef1c88b127c~3WTVvPusx0398003980eucas1p1H@eucas1p1.samsung.com>
Hi Marek,
On Tue, Jun 12, 2018 at 9:31 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 2018-06-11 14:31, Will Deacon wrote:
> > On Mon, Jun 11, 2018 at 09:55:54AM +0200, Geert Uytterhoeven wrote:
> >> On Mon, Jun 11, 2018 at 7:14 AM Marek Szyprowski
> >> <m.szyprowski@samsung.com> wrote:
> >>> dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
> >>> they should be cleared on allocation. In case of IOMMU-based dma-mapping
> >>> implementation such buffer clearing was missing in the code path for
> >>> DMA_ATTR_FORCE_CONTIGUOUS flag handling. This patch fixes this issue. For
> >> Is it? The memory is allocated using dma_alloc_from_contiguous(..., gfp),
> >> and __iommu_alloc_attrs() has
> >>
> >> /*
> >> * Some drivers rely on this, and we probably don't want the
> >> * possibility of stale kernel data being read by devices anyway.
> >> */
> >> gfp |= __GFP_ZERO;
> >>
> >> at the top, before the allocation.
> >>
> >> If cma_alloc() (called from dma_alloc_from_contiguous()) doesn't honor
> >> __GFP_ZERO, I think cma_alloc() should be fixed instead.
> > Agreed. We tried to fix this in 7132813c3845 ("arm64: Honor __GFP_ZERO in
> > dma allocations"). Has something broken that?
>
> The code for handling DMA_ATTR_FORCE_CONTIGUOUS flag in arm64
> dma-mapping/iommu
> implementation has been added later and assumed that __GFP_ZERO flag is
> handled by dma_alloc_from_contiguous(). This is sadly not true, so the
> buffer
> allocated this way is not cleared.
>
> In case of ARM (32bit) the newly allocated buffer is always cleared directly
> after calling dma_alloc_from_contiguous() function.
JFTR, mips and generic dma_direct_alloc() also do that, extensa does not.
> I agree that adding handling of __GFP_ZERO flag to
> dma_alloc_from_contiguous()
> or rather cma_alloc() is a better idea, but might have some side effects, so
> such change is not a good candidate for -rc cycle. I will prepare such
> patch,
> but for now this one is imho a bit less invasive approach.
OK, fine for me.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Stephen Boyd @ 2018-06-12 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67DOgnW=gesPxgmxZJWieZkzjPJm5mt7eW15HgUP3_SZg@mail.gmail.com>
Quoting Chen-Yu Tsai (2018-06-11 00:53:41)
> Hi,
>
> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> > Hi Maxime,
> >
> >
> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> >> Hi Mike, Stephen,
> >>
> >> Please merge the following changes for the next merge window, thanks!
> >>
> >> Maxime
> >>
> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >>
> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >>
> >> are available in the Git repository at:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
> >>
> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
> >>
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
> >>
> >> ----------------------------------------------------------------
> >> Allwinner clock changes for 4.18
> >>
> >> Not a lot of changes for this release, but two quite important features
> >> were added: the H6 PRCM clock support, and the needed changes to the R40
> >> clock driver to allow for the EMAC to operate.
> >>
> >> ----------------------------------------------------------------
> >> Icenowy Zheng (3):
> >> clk: sunxi-ng: add support for H6 PRCM CCU
> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
> >>
> >
> >
> >
> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
> > not included in the pull request?
> >
> >
> > You said "I've picked it up"
> > https://patchwork.kernel.org/patch/10348031/
>
> It looks like it was accidentally dropped after a rebase.
> Not quite sure what happened there. Maxime?
>
I can directly pick and send as fix for clk-fixes targeting rc2.
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Stephen Boyd @ 2018-06-12 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18f6871e-794d-3ea2-487e-32399a8b89b4@microchip.com>
Quoting Codrin Ciubotariu (2018-06-07 03:30:14)
> >
> > Seems to me that clock additions could use a new binding and we start
> > with a new driver that handles these few clocks initially. But I
> > haven't looked whether both can coexist.
>
> Mark already applied to broonie/sound.git the I2S bindings that have a
> phandle to this clock. If I am to change #clock-cells to 1, I will have
> to change the bindings to include the clock-id.
> Which approach should I take now?
>
You're talking about changing the example in the binding doc? That
doesn't really matter. Consumer side of the provider has to match the
cell count from the provider so it doesn't really need to be 'fixed' in
the example at all.
^ permalink raw reply
* [PATCH v6 3/5] dt-bindings: timer: add i.MX EPIT timer binding
From: Clément Péron @ 2018-06-12 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611181042.GA30888@rob-hp-laptop>
Hi Rob,
On Mon, 11 Jun 2018 at 20:10, Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Jun 07, 2018 at 04:05:42PM +0200, Cl?ment P?ron wrote:
> > From: Cl?ment Peron <clement.peron@devialet.com>
> >
> > Add devicetree binding document for NXP's i.MX SoC specific
> > EPIT timer driver.
> >
> > Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> > ---
> > .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks, I posted the v7 yesterday, could you add your tag to the new release ?
Regards,
Clement
^ permalink raw reply
* [clk:clk-bcm-stingray 1/2] drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
From: Stephen Boyd @ 2018-06-12 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <016e740bcf20db8fa753c6686812ce76@mail.gmail.com>
Quoting Ray Jui (2018-06-06 14:00:06)
> Hi Stephen,
>
> I'd like to confirm this kbuild error is caused by changing of the defines
> in the header.
>
> That is, kbuild test should pass with 2/2 patch.
>
> If my understanding is incorrect and this requires any further action,
> please let me know.
Don't think so. Linus merged clk-next over the weekend. Either I applied
the patches in the wrong order, or you sent them in the wrong order. In
the future, please compile test each patch in isolation. I do that
sometimes, but not always as it's still a manual process for me. I need
to update my scripts to make that better, which I'll do shortly.
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-12 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8Hs+CArdkAWoBPbr_p-nq5+0oPwOPg0NsJDRMkE_bM9A@mail.gmail.com>
Hi Ard,
On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>> The start of the linear region map on a KASLR enabled ARM64 machine -
>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>> since it is defined as:
>>
>> (UL(1) << (VA_BITS - 1)) + 1)
>>
>
> PAGE_OFFSET is the VA of the start of the linear map. The linear map
> can be sparsely populated with actual memory, regardless of whether
> KASLR is in effect or not. The only difference in the presence of
> KASLR is that there may be such a hole at the beginning, but that does
> not mean the linear map has moved, or that the value of PAGE_OFFSET is
> now wrong.
>
>> So taking an example of a platform with VA_BITS=48, this gives a static
>> value of:
>> PAGE_OFFSET = 0xffff800000000000
>>
>> However, for the KASLR case, we use the 'memstart_offset_seed'
>> to randomize the linear region - since 'memstart_addr' indicates the
>> start of physical RAM, we randomize the same on basis
>> of 'memstart_offset_seed' value.
>>
>> As the PAGE_OFFSET value is used presently by several user space
>> tools (for e.g. makedumpfile and crash tools) to determine the start
>> of linear region and hence to read addresses (like PT_NOTE fields) from
>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>> the start of linear region for the KASLR cases and default to
>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>> linear region.
>>
>
> Userland code that assumes that the linear map cannot have a hole at
> the beginning should be fixed.
That is a separate case (although that needs fixing as well via a
kernel patch probably as the user-space tools rely on '/proc/iomem'
contents to determine the first System RAM/reserved range).
1. In that particular case (see [1]) the EFI firmware sets the first
EFI block as EfiReservedMemType:
Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
Since EFI firmware won't return the "EfiReservedMemType" memory to
Linux kernel, so the kernel can't get any info about the first mem
block, and kernel can only see region2 as below:
efi: Processing EFI memory map:
efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
| | | | |WB|WT|WC|UC]
# head -1 /proc/iomem
00200000-0021ffff : reserved
2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
kernel Virtual map we can see that the memory node is set to:
# dmesg | grep memory
..........
memory : 0xffff800000200000 - 0xffff801800000000
2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
if we use 'readelf' to get the last program Header from vmcore (logs
below are for the non-kaslr case):
# readelf -l vmcore
ELF Header:
........................
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
..............................................................................................................................................................
LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
0x0000001680000000 0x0000001680000000 RWE 0
3. So if we do a simple calculation:
(VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
0xFFFF8017FFE00000 != 0xffff801800000000.
which indicates that the end virtual memory nodes are not the same
between vmlinux and vmcore.
This happens because the kexec-tools rely on 'proc/iomem' contents
while 'memstart_addr' is computed as 0 by kernel (as value of
memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
Returning back to this patch, this is a generic requirement where we
need the linear region start/base addresses in user-space applications
which is used to read addresses which lie in the linear region (for
e.g. when we read /proc/kcore contents).
>> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
>> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
>> and was able to use a modified user space utility (like kexec-tools and
>> makedumpfile) to determine the start of linear region correctly for
>> both the KASLR and non-KASLR boot cases.
>>
>
> Can you explain the nature of the changes to the userland code?
The changes are not to rely on the fixed PAGE_OFFSET macro value for
determining the base address of the linear region, but rather read the
' linear_reg_start_addr' symbol from kernel and use the same both in
case of KASLR and non-KASLR boots to determine the base of the linear
region (in [2], I have implemented a test change to kexec-tools to
read the 'linear_reg_start_addr' symbol which is available on my
public github tree, I have a similar change available in makedumpfile
which I have not yet pushed to github, as it implements other features
as well)
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582407.html
[2] https://github.com/bhupesh-sharma/kexec-tools/commit/ae511833e948ccf864fae142ccd903f9c7b3461d
Regards,
Bhupesh
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> Cc: James Morse <james.morse@arm.com>
>> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
>> ---
>> arch/arm64/include/asm/memory.h | 3 +++
>> arch/arm64/kernel/arm64ksyms.c | 1 +
>> arch/arm64/mm/init.c | 3 +++
>> 3 files changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 49d99214f43c..bfd0915ecaf8 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
>> /* PHYS_OFFSET - the physical address of the start of memory. */
>> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>>
>> +/* the virtual base of the linear region. */
>> +extern s64 linear_reg_start_addr;
>> +
>> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
>> extern u64 kimage_vaddr;
>>
>> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
>> index d894a20b70b2..a92238ea45ff 100644
>> --- a/arch/arm64/kernel/arm64ksyms.c
>> +++ b/arch/arm64/kernel/arm64ksyms.c
>> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>>
>> /* physical memory */
>> EXPORT_SYMBOL(memstart_addr);
>> +EXPORT_SYMBOL(linear_reg_start_addr);
>>
>> /* string / mem functions */
>> EXPORT_SYMBOL(strchr);
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 325cfb3b858a..29447adb0eef 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -60,6 +60,7 @@
>> * that cannot be mistaken for a real physical address.
>> */
>> s64 memstart_addr __ro_after_init = -1;
>> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>
>> #ifdef CONFIG_BLK_DEV_INITRD
>> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
>> }
>> }
>>
>> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
>> +
>> /*
>> * Register the kernel text, kernel data, initrd, and initial
>> * pagetables with memblock.
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH 3/3] pinctrl: actions: Add interrupt support for OWL S900 SoC
From: Linus Walleij @ 2018-06-12 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602165415.30956-4-manivannan.sadhasivam@linaro.org>
On Sat, Jun 2, 2018 at 6:54 PM, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
> Add interrupt support for Actions Semi OWL S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
(...)
> +++ b/drivers/pinctrl/actions/Kconfig
> @@ -5,6 +5,7 @@ config PINCTRL_OWL
> select PINCONF
> select GENERIC_PINCONF
> select GPIOLIB
> + select GPIOLIB_IRQCHIP
I don't think you're really using that (certain sign: you're implementing
.to_irq().)
GPIOLIB_IRQCHIP is nice, but can only be used when there is
a 1-1 correspondence betweem GPIO line offsets and
IRQ lines and they are numbered 0..n.
However I think you can use it! Look below for my reference
to the tegra186 and how you can probably cut out the custom
irqdomain with some manouvers.
> + struct owl_pinctrl *pctrl = irq_data_get_irq_chip_data(data);
> + const struct owl_gpio_port *port;
(...)
> + unsigned int gpio = data->hwirq;
> +
> + port = owl_gpio_get_port(pctrl, &gpio);
> +
> + gpio_base = pctrl->base + port->offset;
It is all about this calculation really.
> +static int owl_gpio_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + struct owl_pinctrl *pctrl = irq_data_get_irq_chip_data(data);
> + const struct owl_gpio_port *port;
> + void __iomem *gpio_base;
> + unsigned long flags;
> + unsigned int gpio = data->hwirq;
> + unsigned int offset, value, irq_type = 0;
> +
> + port = owl_gpio_get_port(pctrl, &gpio);
> + if (WARN_ON(port == NULL))
> + return -ENODEV;
> +
> + gpio_base = pctrl->base + port->offset;
> +
> + switch (type) {
> + case IRQ_TYPE_EDGE_RISING:
> + irq_type = OWL_GPIO_INT_EDGE_RISING;
> + break;
> +
> + case IRQ_TYPE_EDGE_FALLING:
> + irq_type = OWL_GPIO_INT_EDGE_FALLING;
> + break;
Very often things such as keys will request trigger on
both edges. This means IRQ_TYPE_EDGE_RISING
and IRQ_TYPE_EDGE_FALLING are both set, which
will cause you problems here, since it is unhandled.
I guess it is fine to set both?
> + offset = gpio < 16 ? 4 : 0;
I think even the compiler should suggest putting he (gpio < 16)
expression in paranthesis.
> + value = readl_relaxed(gpio_base + port->intc_type + offset);
> + value &= ~(OWL_GPIO_INT_MASK << ((gpio % 16) * 2));
> + value |= irq_type << ((gpio % 16) * 2);
> + writel_relaxed(value, gpio_base + port->intc_type + offset);
> +
> + raw_spin_unlock_irqrestore(&pctrl->lock, flags);
> +
> + if (type & IRQ_TYPE_EDGE_BOTH)
> + irq_set_handler_locked(data, handle_edge_irq);
> + else
> + irq_set_handler_locked(data, handle_level_irq);
Here you handle both edges, but not in the switch clause.
> +static void owl_gpio_irq_handler(struct irq_desc *desc)
This looks fine.
> +static struct irq_chip owl_gpio_irq_chip = {
> + .name = "owlgpio",
> + .irq_mask = owl_gpio_irq_mask,
> + .irq_unmask = owl_gpio_irq_unmask,
> + .irq_ack = owl_gpio_irq_ack,
> + .irq_set_type = owl_gpio_irq_set_type,
> +};
If you implement your own irqchip you need to implement
.irq_request_resources and .irq_free_resources locking the GPIO
lines for interrupt, see other drivers that do this or the
gpiolib core code in gpiolib.c.
It would be really neat if you could instead use the
GPIOLIB_IRQCHIP though, but I know it will be a bit tricky
and maybe not possible.
> + for (i = 0; i < pctrl->soc->nports; i++) {
> + irq_set_chained_handler_and_data(pctrl->irq[i],
> + owl_gpio_irq_handler,
> + pctrl);
> + }
If you use GPIOLIB_IRQCHIP with several parent IRQs.
See Thierry's work in drivers/gpio/gpio-tegra186.c for the
only example.
I think that is what you want to do here.
We do want to add helpers in gpiolib to do this in a more
organized and easy-to-use fashion. Patches welcome ;)
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Chen-Yu Tsai @ 2018-06-12 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152879040155.16708.9862482085365718831@swboyd.mtv.corp.google.com>
On Tue, Jun 12, 2018 at 4:00 PM, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Chen-Yu Tsai (2018-06-11 00:53:41)
>> Hi,
>>
>> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>> > Hi Maxime,
>> >
>> >
>> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
>> >> Hi Mike, Stephen,
>> >>
>> >> Please merge the following changes for the next merge window, thanks!
>> >>
>> >> Maxime
>> >>
>> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>> >>
>> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
>> >>
>> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
>> >>
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
>> >>
>> >> ----------------------------------------------------------------
>> >> Allwinner clock changes for 4.18
>> >>
>> >> Not a lot of changes for this release, but two quite important features
>> >> were added: the H6 PRCM clock support, and the needed changes to the R40
>> >> clock driver to allow for the EMAC to operate.
>> >>
>> >> ----------------------------------------------------------------
>> >> Icenowy Zheng (3):
>> >> clk: sunxi-ng: add support for H6 PRCM CCU
>> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
>> >>
>> >
>> >
>> >
>> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
>> > not included in the pull request?
>> >
>> >
>> > You said "I've picked it up"
>> > https://patchwork.kernel.org/patch/10348031/
>>
>> It looks like it was accidentally dropped after a rebase.
>> Not quite sure what happened there. Maxime?
>>
>
> I can directly pick and send as fix for clk-fixes targeting rc2.
The patch can still be found in the sunxi/for-next branch of the
sunxi repo on kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/for-next&id=d4a1496286b0c29fcace4e10c0047cca7cc79b25
Or the original on patchwork:
https://patchwork.kernel.org/patch/10348027/
Thanks
ChenYu
^ permalink raw reply
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: poza at codeaurora.org @ 2018-06-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-3-git-send-email-ray.jui@broadcom.com>
On 2018-05-30 03:28, Ray Jui wrote:
> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
> INTD share the same interrupt line connected to the GIC in the system,
> while the status of each INTx can be obtained through the INTX CSR
> register
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> drivers/pci/host/pcie-iproc-platform.c | 2 +
> drivers/pci/host/pcie-iproc.c | 95
> +++++++++++++++++++++++++++++++++-
> drivers/pci/host/pcie-iproc.h | 6 +++
> 3 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-iproc-platform.c
> b/drivers/pci/host/pcie-iproc-platform.c
> index e764a2a..7a51e6c 100644
> --- a/drivers/pci/host/pcie-iproc-platform.c
> +++ b/drivers/pci/host/pcie-iproc-platform.c
> @@ -70,6 +70,8 @@ static int iproc_pcie_pltfm_probe(struct
> platform_device *pdev)
> }
> pcie->base_addr = reg.start;
>
> + pcie->irq = platform_get_irq(pdev, 0);
> +
> if (of_property_read_bool(np, "brcm,pcie-ob")) {
> u32 val;
>
> diff --git a/drivers/pci/host/pcie-iproc.c
> b/drivers/pci/host/pcie-iproc.c
> index 14f374d..0bd2c14 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -14,6 +14,7 @@
> #include <linux/delay.h>
> #include <linux/interrupt.h>
> #include <linux/irqchip/arm-gic-v3.h>
> +#include <linux/irqchip/chained_irq.h>
> #include <linux/platform_device.h>
> #include <linux/of_address.h>
> #include <linux/of_pci.h>
> @@ -264,6 +265,7 @@ enum iproc_pcie_reg {
>
> /* enable INTx */
> IPROC_PCIE_INTX_EN,
> + IPROC_PCIE_INTX_CSR,
>
> /* outbound address mapping */
> IPROC_PCIE_OARR0,
> @@ -305,6 +307,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_LINK_STATUS] = 0xf0c,
> };
>
> @@ -316,6 +319,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_OARR0] = 0xd20,
> [IPROC_PCIE_OMAP0] = 0xd40,
> [IPROC_PCIE_OARR1] = 0xd28,
> @@ -332,6 +336,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_OARR0] = 0xd20,
> [IPROC_PCIE_OMAP0] = 0xd40,
> [IPROC_PCIE_OARR1] = 0xd28,
> @@ -782,9 +787,90 @@ static int iproc_pcie_check_link(struct iproc_pcie
> *pcie)
> return link_is_active ? 0 : -ENODEV;
> }
>
> -static void iproc_pcie_enable(struct iproc_pcie *pcie)
> +static int iproc_pcie_intx_map(struct irq_domain *domain, unsigned int
> irq,
> + irq_hw_number_t hwirq)
> {
> + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_simple_irq);
> + irq_set_chip_data(irq, domain->host_data);
> +
> + return 0;
> +}
> +
> +static const struct irq_domain_ops intx_domain_ops = {
> + .map = iproc_pcie_intx_map,
> +};
> +
> +static void iproc_pcie_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct iproc_pcie *pcie;
> + struct device *dev;
> + unsigned long status;
> + u32 bit, virq;
> +
> + chained_irq_enter(chip, desc);
> + pcie = irq_desc_get_handler_data(desc);
> + dev = pcie->dev;
> +
> + /* go through INTx A, B, C, D until all interrupts are handled */
> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
> + SYS_RC_INTX_MASK) != 0) {
> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(dev, "unexpected INTx%u\n", bit);
> + }
> + }
> +
Are these level or edge interrupts ? although I see DT says:
IRQ_TYPE_NONE
do you not need to clear interrupt status bits in IPROC_PCIE_INTX_CSR ?
> + chained_irq_exit(chip, desc);
> +}
> +
> +static int iproc_pcie_intx_enable(struct iproc_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + struct device_node *node = dev->of_node;
> + int ret;
> +
> iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
> +
> + /*
> + * BCMA devices do not map INTx the same way as platform devices. All
> + * BCMA needs is the above code to enable INTx
> + */
> + if (pcie->irq <= 0)
> + return 0;
> +
> + /* set IRQ handler */
> + irq_set_chained_handler_and_data(pcie->irq, iproc_pcie_isr, pcie);
> +
> + /* add IRQ domain for INTx */
> + pcie->irq_domain = irq_domain_add_linear(node, PCI_NUM_INTX + 1,
> + &intx_domain_ops, pcie);
> + if (!pcie->irq_domain) {
> + dev_err(dev, "failed to add INTx IRQ domain\n");
> + ret = -ENOMEM;
> + goto err_rm_handler_data;
> + }
> +
> + return 0;
> +
> +err_rm_handler_data:
> + irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
> +
> + return ret;
> +}
> +
> +static void iproc_pcie_intx_disable(struct iproc_pcie *pcie)
> +{
> + iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, 0x0);
> +
> + if (pcie->irq <= 0)
> + return;
> +
> + irq_domain_remove(pcie->irq_domain);
> + irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
> }
>
> static inline bool iproc_pcie_ob_is_valid(struct iproc_pcie *pcie,
> @@ -1410,7 +1496,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie,
> struct list_head *res)
> goto err_power_off_phy;
> }
>
> - iproc_pcie_enable(pcie);
> + ret = iproc_pcie_intx_enable(pcie);
> + if (ret) {
> + dev_err(dev, "failed to enable INTx\n");
> + goto err_power_off_phy;
> + }
>
> if (IS_ENABLED(CONFIG_PCI_MSI))
> if (iproc_pcie_msi_enable(pcie))
> @@ -1455,6 +1545,7 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
> pci_remove_root_bus(pcie->root_bus);
>
> iproc_pcie_msi_disable(pcie);
> + iproc_pcie_intx_disable(pcie);
>
> phy_power_off(pcie->phy);
> phy_exit(pcie->phy);
> diff --git a/drivers/pci/host/pcie-iproc.h
> b/drivers/pci/host/pcie-iproc.h
> index 67081cb..cbcaf9d 100644
> --- a/drivers/pci/host/pcie-iproc.h
> +++ b/drivers/pci/host/pcie-iproc.h
> @@ -72,6 +72,9 @@ struct iproc_msi;
> * @ib: inbound mapping related parameters
> * @ib_map: outbound mapping region related parameters
> *
> + * @irq: interrupt line wired to the generic GIC for INTx
> + * @irq_domain: IRQ domain for INTx
> + *
> * @need_msi_steer: indicates additional configuration of the iProc
> PCIe
> * controller is required to steer MSI writes to external interrupt
> controller
> * @msi: MSI data
> @@ -99,6 +102,9 @@ struct iproc_pcie {
> struct iproc_pcie_ib ib;
> const struct iproc_pcie_ib_map *ib_map;
>
> + int irq;
> + struct irq_domain *irq_domain;
> +
> bool need_msi_steer;
> struct iproc_msi *msi;
> };
^ permalink raw reply
* [PATCH v3 0/6] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-12 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528714877.2842.3.camel@pengutronix.de>
Hi Lucas,
Is the below DEAD LOCK issue same as your side? If yes, then
I'm afraid that we have to make another patch for uart to split dma
functions in uart driver out of the code area which protected by
port.lock. The warning make sense since allocate sdma bd memory
dynamically in virt-dma instead of static allocated as before. I'll
make another uart patch into my next version patchset.
[???46.155406] =====================================================
[???46.161503] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order
detected
[???46.168122] 4.17.0-rc6-00008-g7caafa3-dirty #48 Not tainted
[???46.173696] -----------------------------------------------------
[???46.179795] mxc_uart_stress/419 [HC0[0]:SC0[0]:HE0:SE1] is trying to
acquire:
[???46.186934] fa7c1440 (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.3+0x0/0x48
[???46.194270]
[???46.194270] and this task is already holding:
[???46.200106] 09a17fda (&port_lock_key){-.-.}, at:
uart_write+0x84/0x190
[???46.206658] which would create a new lock dependency:
[???46.211710]??(&port_lock_key){-.-.} -> (fs_reclaim){+.+.}
[???46.217132]
[???46.217132] but this new dependency connects a HARDIRQ-irq-safe
lock:
[???46.225051]??(&port_lock_key){-.-.}
[???46.225062]
[???46.225062] ... which became HARDIRQ-irq-safe at:
[???46.234740]???lock_acquire+0x70/0x90
[???46.238326]???_raw_spin_lock_irqsave+0x40/0x54
[???46.242777]???imx_uart_console_write+0x1bc/0x1e0
[???46.247402]???console_unlock+0x320/0x5f0
[???46.251329]???vprintk_emit+0x22c/0x3fc
[???46.255082]???vprintk_default+0x28/0x30
[???46.258923]???vprintk_func+0x78/0xcc
[???46.262503]???printk+0x34/0x54
[???46.265566]???crng_fast_load+0xf8/0x138
[???46.269407]???add_interrupt_randomness+0x21c/0x24c
[???46.274204]???handle_irq_event_percpu+0x40/0x84
[???46.278739]???handle_irq_event+0x40/0x64
[???46.282667]???handle_fasteoi_irq+0xbc/0x178
[???46.286854]???generic_handle_irq+0x28/0x3c
[???46.290954]???__handle_domain_irq+0x6c/0xe8
[???46.295148]???gic_handle_irq+0x64/0xc4
[???46.298904]???__irq_svc+0x70/0x98
[???46.302225]???_raw_spin_unlock_irq+0x30/0x34
[???46.306505]???finish_task_switch+0xc0/0x27c
[???46.310693]???__schedule+0x2c0/0x79c
[???46.314272]???schedule_idle+0x40/0x84
[???46.317941]???do_idle+0x178/0x2b4
[???46.321259]???cpu_startup_entry+0x20/0x24
[???46.325278]???rest_init+0x214/0x264
[???46.328775]???start_kernel+0x39c/0x424
[???46.332527]?????(null)
[???46.334891]
[???46.334891] to a HARDIRQ-irq-unsafe lock:
[???46.340379]??(fs_reclaim){+.+.}
[???46.340391]
[???46.340391] ... which became HARDIRQ-irq-unsafe at:
[???46.349885] ...
[???46.349895]???lock_acquire+0x70/0x90
[???46.355225]???fs_reclaim_acquire.part.3+0x38/0x48
[???46.359933]???fs_reclaim_acquire+0x1c/0x20
[???46.364036]???kmem_cache_alloc+0x2c/0x174
[???46.368051]???alloc_worker.constprop.10+0x1c/0x58
[???46.372759]???init_rescuer.part.4+0x18/0xa4
[???46.376952]???workqueue_init+0xc0/0x210
[???46.380793]???kernel_init_freeable+0x58/0x1d8
[???46.385156]???kernel_init+0x10/0x11c
[???46.388736]???ret_from_fork+0x14/0x20
[???46.392399]?????(null)
[???46.394762]
[???46.394762] other info that might help us debug this:
[???46.394762]
[???46.402769]??Possible interrupt unsafe locking scenario:
[???46.402769]
[???46.409560]????????CPU0????????????????????CPU1
[???46.414092]????????----????????????????????----
[???46.418622]???lock(fs_reclaim);
[???46.421772]????????????????????????????????local_irq_disable();
[???46.427693]????????????????????????????????lock(&port_lock_key);
[???46.433707]????????????????????????????????lock(fs_reclaim);
[???46.439372]???<Interrupt>
[???46.441993]?????lock(&port_lock_key);
[???46.445661]
[???46.445661]??*** DEADLOCK ***
[???46.445661]
On ?, 2018-06-11 at 13:01 +0200, Lucas Stach wrote:
> Hi Robin,
>
> this series breaks serial DMA for me. I wasn't able to dig in deeper
> yet. Please let me know if you can test/reproduce at your side, if
> not
> I'll try to find some time to collect some more debug info.
>
> Regards,
> Lucas
>
> Am Montag, den 11.06.2018, 22:59 +0800 schrieb Robin Gong:
> >
> > The legacy sdma driver has below limitations or drawbacks:
> > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > alloc
> > ?????one page size for one channel regardless of only few BDs
> > needed
> > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > enough.
> > ? 2. One SDMA channel can't stop immediatley once channel disabled
> > which
> > ?????means SDMA interrupt may come in after this channel
> > terminated.There
> > ?????are some patches for this corner case such as commit
> > "2746e2c389f9",
> > ?????but not cover non-cyclic.
> >
> > The common virt-dma overcomes the above limitations. It can alloc
> > bd
> > dynamically and free bd once this tx transfer done. No memory
> > wasted or
> > maximum limititation here, only depends on how many memory can be
> > requested
> > from kernel. For No.2, such issue can be workaround by checking if
> > there
> > is available descript("sdmac->desc") now once the unwanted
> > interrupt
> > coming. At last the common virt-dma is easier for sdma driver
> > maintain.
> >
> > Change from v2:
> > ? 1. include Sascha's patch to make the main patch easier to
> > review.
> > ?????Thanks Sacha.
> > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> >
> > Change from v1:
> > ? 1. split v1 patch into 5 patches.
> > ? 2. remove some unnecessary condition check.
> > ? 3. remove unnecessary 'pending' list.
> >
> > Robin Gong (5):
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? Revert "dmaengine: imx-sdma: fix pagefault when channel is
> > disabled
> > ????during interrupt"
> > ? dmaengine: imx-sdma: remove usless lock
> > ? dmaengine: imx-sdma: remove the maximum limation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> >
> > ?drivers/dma/Kconfig????|???1 +
> > ?drivers/dma/imx-sdma.c | 392 ++++++++++++++++++++++++++++---------
> > ------------
> > ?2 files changed, 227 insertions(+), 166 deletions(-)
> >
> > --?
> > 2.7.4
> >
> > Robin Gong (5):
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? Revert "dmaengine: imx-sdma: fix pagefault when channel is
> > disabled
> > ????during interrupt"
> > ? dmaengine: imx-sdma: remove usless lock
> > ? dmaengine: imx-sdma: remove the maximum limation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> >
> > Sascha Hauer (1):
> > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > ????sdma_channel
> >
> > ?drivers/dma/Kconfig????|???1 +
> > ?drivers/dma/imx-sdma.c | 391 ++++++++++++++++++++++++++++---------
> > ------------
> > ?2 files changed, 226 insertions(+), 166 deletions(-)
> >
^ permalink raw reply
* [PATCH 0/5] arm64: numa/topology/smp: fix the cpumasks for CPU hotplug
From: Sudeep Holla @ 2018-06-12 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23796631-312b-82a0-fe03-cb7985433727@huawei.com>
On 12/06/18 02:14, Hanjun Guo wrote:
> Hi Sudeep,
>
> On 2018/6/4 18:39, Sudeep Holla wrote:
>> Hi Will, Catalin, Jeremy, Morten,
>>
>> This is the fix I could come up for the issues we are seeing with arm64
>> for-next branch, in particular with commit 37c3ec2d810f ("arm64: topology:
>> divorce MC scheduling domain from core_siblings").
>>
>> The solution is to update the CPU topology during CPU hotplug operations
>> similar to other architectures like x86 and PPC. This is also inline
>> with the expection from the scheduler.
>>
>> I have cc-ed few Cavium and Huawei guys as they seem to have added or
>> modified the numa related code in the past.
>
> Sorry for the late response, I can test on ARM64 NUMA systems
> with PPTT enabled, before I'm doing that, could you give some
> suggestion of the testing? what specific test case should I
> test? doing CPU offline/online when PPTT is enabled?
>
Thanks for the response. I plan to post v2 after -rc1 which will have
some delta from this. So don't test this for now. Yes CPU hotplug tests
will be good. Also some NUMA based(numactl) assignments and try
hotplugging all CPUs in a node and similar tests with PPTT would be good.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Zhizhou Zhang @ 2018-06-12 9:07 UTC (permalink / raw)
To: linux-arm-kernel
We can't call function trace hook before setup percpu offset.
When entering secondary_start_kernel(), percpu offset has not
been initialized. So this lead hotplug malfunction.
Here is the flow to reproduce this bug:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 1 > /sys/devices/system/cpu/cpu1/online
Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
---
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3ae..11b0f30 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -179,7 +179,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
* This is the secondary CPU boot entry. We're using this CPUs
* idle thread stack, but a set of temporary page tables.
*/
-asmlinkage void secondary_start_kernel(void)
+notrace asmlinkage void secondary_start_kernel(void)
{
u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
struct mm_struct *mm = &init_mm;
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Mark Rutland @ 2018-06-12 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528794457-14129-1-git-send-email-zhizhouzhang@asrmicro.com>
On Tue, Jun 12, 2018 at 05:07:37PM +0800, Zhizhou Zhang wrote:
> We can't call function trace hook before setup percpu offset.
> When entering secondary_start_kernel(), percpu offset has not
> been initialized. So this lead hotplug malfunction.
> Here is the flow to reproduce this bug:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo function > /sys/kernel/debug/tracing/current_tracer
> echo 1 > /sys/kernel/debug/tracing/tracing_on
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> ---
> arch/arm64/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index f3e2e3ae..11b0f30 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -179,7 +179,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> * This is the secondary CPU boot entry. We're using this CPUs
> * idle thread stack, but a set of temporary page tables.
> */
> -asmlinkage void secondary_start_kernel(void)
> +notrace asmlinkage void secondary_start_kernel(void)
Minor nit: can we please keep asmlinkage first, e.g.
asmlinkage notrace void secondary_start_kernel(void)
Either way:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> {
> u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> struct mm_struct *mm = &init_mm;
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Suzuki K Poulose @ 2018-06-12 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528794457-14129-1-git-send-email-zhizhouzhang@asrmicro.com>
On 12/06/18 10:07, Zhizhou Zhang wrote:
> We can't call function trace hook before setup percpu offset.
> When entering secondary_start_kernel(), percpu offset has not
> been initialized. So this lead hotplug malfunction.
> Here is the flow to reproduce this bug:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo function > /sys/kernel/debug/tracing/current_tracer
> echo 1 > /sys/kernel/debug/tracing/tracing_on
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> ---
> arch/arm64/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index f3e2e3ae..11b0f30 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -179,7 +179,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> * This is the secondary CPU boot entry. We're using this CPUs
> * idle thread stack, but a set of temporary page tables.
> */
> -asmlinkage void secondary_start_kernel(void)
> +notrace asmlinkage void secondary_start_kernel(void)
> {
> u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> struct mm_struct *mm = &init_mm;
>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
I think this should go to stable releases as well.
Suzuki
^ permalink raw reply
* [PATCH 10/20] dts: juno: Update coresight bindings for hw port
From: Suzuki K Poulose @ 2018-06-12 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxNakRGCWT6O0JRKz+N1OTU3-XreC_FiB8Fiv+jEoPEbQ@mail.gmail.com>
On 08/06/18 22:52, Mathieu Poirier wrote:
> On 8 June 2018 at 15:49, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> On Tue, Jun 05, 2018 at 10:43:21PM +0100, Suzuki K Poulose wrote:
>>> Switch to updated coresight bindings for hw ports.
>>>
>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> ---
>>> Changes since V1:
>>> - Add support Juno for r1 & r2.
>>> ---
>>
>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Sudeep please hold on before applying this as there is more work to be
> done on this set.
Mathieu,
I will wait for Rob / Frank to have a say on the bindings before I post the
next update.
Cheers
Suzuki
^ permalink raw reply
* [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang @ 2018-06-12 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DC3FE66E-C3FD-455F-8592-E927604086CD@holtmann.org>
On Wed, 2018-05-30 at 08:26 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>>>>>
[ ... ]
> >>> * Unknown packet (code 14 len 30) 0.641509
> >>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
> >>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
> >>> * Unknown packet (code 14 len 30) 0.641592
> >>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
> >>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
> >>> * Unknown packet (code 16 len 7) [hci0] 6.536771
> >>> 01 00 00 00 05 00 01 .......
> >>> = Open Index: 00:00:46:76:22:01 [hci0] 6.717019
> >>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
> >>
> >> can you try with the latest BlueZ 5.49 or git version. Seems it actually stumbles over the extra packet here. Fun fact is that I can not get a backtrace to pin-point the issue in btmon and why it crashes.
> >>
> >
> > I had less experience updating user land BlueZ, but I can try it as possible and see whether Unknown packets still are present at newest version BlueZ. Hopefully I don't misunderstand your point here.
>
> please use the latest btmon and check if it can read your trace.
>
sure, I'll have a try with the latest btmon.
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
> >>> 02 01 01 00 00 .....
[ ... ]
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
> >>> 02 01 01 00 00 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
> >>> 02 01 01 00 00 .....
> >>
> >> Why do I see only HCI events here? Is this event conveying any useful information. It is kinda complicated that this is 0xe4 event code which is actually reserved for future use by the Bluetooth SIG. Are there any accompanying HCI commands for this and they just not make it into btmon?
> >>
> >
> > I have made all vendor HCI commands go through BlueZ core in v2 patch.
> >
> > And for these HCI events, they are all corresponding to vendor ACL data, applied only to firmware setup packets, but they're not being sent via BlueZ core, so they are not being logged in btmon.
> >
> > As for its event, where heading 0xe4 refers to a vendor event and is used on notification of that either vendor ACL data or vendor HCI command have been done.
>
> I would prefer if everything goes via the Bluetooth core since then we have it all properly scheduled. Sending things down the ACL data path however if kinda funky. Does your hardware accept sending command both via ACL data and as HCI command? If so, then I would prefer sending them as HCI commands since the speed improvement you think you are getting is neglectable on Linux (I have been down that path). This seems to be a pure optimization when Windows is driving the device.
>
firmware people said the device can support firmware download as HCI commands. According to my test, this way indeed works so I will improve the part in the next version.
> And the vendor event 0xe4 is really only received during firmware download? It is not ever received during normal operation?
>
0xe4 is only received during chip initialization.
I also thought 0xe4 is a poor definition for vendor event and already have notified firmware people should pick 0xff as its vendor event id in the future.
but for now, unfortunately, 0xe4 cannot be changed on the device, the only way is to add a workaround in RX path as below to allow btmon can recognize these bad events properly.
int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_event_hdr *hdr = (void *)skb->data;
/* Fix up the vendor event id with HCI_VENDOR_PKT instead of
* 0xe4 so that btmon can parse the kind of vendor event properly.
*/
if (hdr->evt == 0xe4)
hdr->evt = HCI_VENDOR_PKT;
/* Each HCI event would go through the core. */
return hci_recv_frame(hdev, skb);
}
> >
> >>
> >>
> >>> < HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
> >>> 01 07 01 00 04 .....
> >>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
> >>> 02 07 01 00 00 .....
[ ... ]
> >>> Encapsulated PDU
> >>> Erroneous Data Reporting
> >>> Non-flushable Packet Boundary Flag
> >>> Link Supervision Timeout Changed Event
> >>> Inquiry TX Power Level
> >>> Enhanced Power Control
> >>> Extended features
> >>> < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
> >>>> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
> >>> 29 19 09 17 20 48 07 11 00 )... H?
> >>
> >> Is this meant to happen here?
> >>
> >
> > If event received is not expected as the specification defines, I think it's probably incorrect.
> >
> > But it requires more discussion with firmware people to make it clearer.
>
> Please check and let them decode what this event means.
>
it's just debugging purpose information listing built-time something
like that and will be removed in the firmware.
> >
> >>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
> >>> Read Local Version Information (0x04|0x0001) ncmd 1
> >>> Status: Success (0x00)
> >>> HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
> >>> LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
> >>> Manufacturer: MediaTek, Inc. (70)
> >>> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
> >>>> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
[ ... ]
> >>> LE Add Device To Resolving List (Octet 34 - Bit 3)
> >>> LE Remove Device From Resolving List (Octet 34 - Bit 4)
> >>> LE Clear Resolving List (Octet 34 - Bit 5)
> >>> LE Read Resolving List Size (Octet 34 - Bit 6)
> >>> LE Read Peer Resolvable Address (Octet 34 - Bit 7)
> >>> LE Read Local Resolvable Address (Octet 35 - Bit 0)
> >>> LE Set Address Resolution Enable (Octet 35 - Bit 1)
> >>> LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
> >>> LE Read Maximum Data Length (Octet 35 - Bit 3)
> >>> Octet 35 - Bit 4
> >>> Octet 35 - Bit 5
> >>> Octet 35 - Bit 6
> >>> Octet 35 - Bit 7
> >>> Octet 36 - Bit 0
> >>
> >> So you support the PHY commands, but do not indicate support LE 2M or LE Coded? Also these are Bluetooth 5.0 commands.
> >>
> >
> > To be honest. When I ported the device into Bluez core, a unexpected event for LE read local feature would cause a fail at Bluez core, so I made a hack on Bluez core
> >
> > to allow that I can keeping bring up the device without be blocked by the issue most probably from firmware.
> >
> > Below code snippet is the only thing I added to avoid a fail at Bluez core to bring up the device.
> >
> > @@ -927,6 +927,8 @@ static void hci_cc_le_read_local_features(struct hci_dev *hdev,
> > return;
> >
> > memcpy(hdev->le_features, rp->features, 8);
> > + hdev->le_features[0] = 0;
> > + hdev->le_features[1] = 0;
> > }
>
> Send me the trace where you didn?t clear the feature bits and I check what is going on. I doubt that we have a bug, but maybe some of the commands are optional and we should add an appropriate check. Or you guys need to fix your firmware. A new btmon should decode all bits properly.
>
okay, I'll have a follow-up.
> Regards
>
> Marcel
>
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: James Morse @ 2018-06-12 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpNdg=Enp66BybNNuj5tQOp3ggyX=tm_SVzr8v2qCRteDw@mail.gmail.com>
Hi Bhupesh, Ard,
On 12/06/18 09:25, Bhupesh Sharma wrote:
> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>> The start of the linear region map on a KASLR enabled ARM64 machine -
>>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>>> since it is defined as:
>>>
>>> (UL(1) << (VA_BITS - 1)) + 1)
>> PAGE_OFFSET is the VA of the start of the linear map. The linear map
>> can be sparsely populated with actual memory, regardless of whether
>> KASLR is in effect or not. The only difference in the presence of
>> KASLR is that there may be such a hole at the beginning, but that does
>> not mean the linear map has moved, or that the value of PAGE_OFFSET is
>> now wrong.
>>> So taking an example of a platform with VA_BITS=48, this gives a static
>>> value of:
>>> PAGE_OFFSET = 0xffff800000000000
>>>
>>> However, for the KASLR case, we use the 'memstart_offset_seed'
>>> to randomize the linear region - since 'memstart_addr' indicates the
>>> start of physical RAM, we randomize the same on basis
>>> of 'memstart_offset_seed' value.
>>>
>>> As the PAGE_OFFSET value is used presently by several user space
>>> tools (for e.g. makedumpfile and crash tools) to determine the start
>>> of linear region and hence to read addresses (like PT_NOTE fields) from
>>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>>> the start of linear region for the KASLR cases and default to
>>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>>> linear region.
>> Userland code that assumes that the linear map cannot have a hole at
>> the beginning should be fixed.
> That is a separate case (although that needs fixing as well via a
> kernel patch probably as the user-space tools rely on '/proc/iomem'
> contents to determine the first System RAM/reserved range).
This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
> 1. In that particular case (see [1]) the EFI firmware sets the first
> EFI block as EfiReservedMemType:
>
> Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
> Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
>
> Since EFI firmware won't return the "EfiReservedMemType" memory to
> Linux kernel,
(Its linux that makes this choice in
drivers/firmware/efi/arm-init.c::is_usable_memory())
> so the kernel can't get any info about the first mem
> block, and kernel can only see region2 as below:
>
> efi: Processing EFI memory map:
> efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
> | | | | |WB|WT|WC|UC]
>
> # head -1 /proc/iomem
> 00200000-0021ffff : reserved
>
> 2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
> kernel Virtual map we can see that the memory node is set to:
>
> # dmesg | grep memory
> ..........
> memory : 0xffff800000200000 - 0xffff801800000000
>
> 2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
> if we use 'readelf' to get the last program Header from vmcore (logs
> below are for the non-kaslr case):
>
> # readelf -l vmcore
>
> ELF Header:
> ........................
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> ..............................................................................................................................................................
> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
> 0x0000001680000000 0x0000001680000000 RWE 0
>
> 3. So if we do a simple calculation:
>
> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
> 0xFFFF8017FFE00000 != 0xffff801800000000.
>
> which indicates that the end virtual memory nodes are not the same
> between vmlinux and vmcore.
If I've followed this properly: the problem is that to generate the ELF headers
in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
The problem you are hitting is an invisible hole at the beginning of RAM,
meaning user-space's guess_phys_to_virt() is off by the size of this hole.
Isn't KASLR a special case for this? You must have to correct for that after
kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
> This happens because the kexec-tools rely on 'proc/iomem' contents
> while 'memstart_addr' is computed as 0 by kernel (as value of
> memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
> Returning back to this patch, this is a generic requirement where we
> need the linear region start/base addresses in user-space applications
> which is used to read addresses which lie in the linear region (for
> e.g. when we read /proc/kcore contents).
>>> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
>>> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
>>> and was able to use a modified user space utility (like kexec-tools and
>>> makedumpfile) to determine the start of linear region correctly for
>>> both the KASLR and non-KASLR boot cases.
>>>
>>
>> Can you explain the nature of the changes to the userland code?
>
> The changes are not to rely on the fixed PAGE_OFFSET macro value for
> determining the base address of the linear region, but rather read the
> ' linear_reg_start_addr' symbol from kernel and use the same both in
> case of KASLR and non-KASLR boots to determine the base of the linear
> region (in [2], I have implemented a test change to kexec-tools to
> read the 'linear_reg_start_addr' symbol which is available on my
Don't use /dev/mem.
> public github tree, I have a similar change available in makedumpfile
> which I have not yet pushed to github, as it implements other features
> as well)
>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>> index 49d99214f43c..bfd0915ecaf8 100644
>>> --- a/arch/arm64/include/asm/memory.h
>>> +++ b/arch/arm64/include/asm/memory.h
>>> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
>>> /* PHYS_OFFSET - the physical address of the start of memory. */
>>> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>>>
>>> +/* the virtual base of the linear region. */
>>> +extern s64 linear_reg_start_addr;
>>> +
>>> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
>>> extern u64 kimage_vaddr;
>>>
>>> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
>>> index d894a20b70b2..a92238ea45ff 100644
>>> --- a/arch/arm64/kernel/arm64ksyms.c
>>> +++ b/arch/arm64/kernel/arm64ksyms.c
>>> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>>>
>>> /* physical memory */
>>> EXPORT_SYMBOL(memstart_addr);
>>> +EXPORT_SYMBOL(linear_reg_start_addr);
>>>
>>> /* string / mem functions */
>>> EXPORT_SYMBOL(strchr);
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 325cfb3b858a..29447adb0eef 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -60,6 +60,7 @@
>>> * that cannot be mistaken for a real physical address.
>>> */
>>> s64 memstart_addr __ro_after_init = -1;
>>> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
>>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>
>>> #ifdef CONFIG_BLK_DEV_INITRD
>>> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
>>> }
>>> }
>>>
>>> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
This patch adds a variable that nothing uses, its going to be removed. You can't
depend on reading this via /dev/mem.
Could you add the information you need as an elf-note to the vmcore instead? You
must already pick these up to handle kaslr. (from memory, this is where the
kaslr-offset is described to user-space after we kdump).
Thanks,
James
^ permalink raw reply
* [PATCH 0/4] Fix suspend resume on at91sam9261 and at91sam9263
From: Nicolas Ferre @ 2018-06-12 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607084107.4461-1-alexandre.belloni@bootlin.com>
On 07/06/2018 at 10:41, Alexandre Belloni wrote:
> USB clock detection may not work properly on at91sam9261 and at91sam9263
> because they currently use the same bit mask as at91rm9200 instead of
> the one for at91sam9260.
>
> Take the opportunity to also change the PMC compatible strings for all
> the other SoCs in preparation for the new clock bindings.
>
> Alexandre Belloni (4):
> dt-bindings: arm: remove PMC bindings
> dt-bindings: clk: at91: Document all the PMC compatibles
> ARM: at91: fix USB clock detection handling
> ARM: dts: fix PMC compatible
To the whole series:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks, best regards.
> .../devicetree/bindings/arm/atmel-pmc.txt | 14 --------------
> .../devicetree/bindings/clock/at91-clock.txt | 9 ++++-----
> arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9rl.dtsi | 2 +-
> arch/arm/boot/dts/sama5d4.dtsi | 2 +-
> arch/arm/mach-at91/pm.c | 5 +++++
> 7 files changed, 13 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/atmel-pmc.txt
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 10/20] dts: juno: Update coresight bindings for hw port
From: Sudeep Holla @ 2018-06-12 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxNakRGCWT6O0JRKz+N1OTU3-XreC_FiB8Fiv+jEoPEbQ@mail.gmail.com>
On Fri, Jun 08, 2018 at 03:52:58PM -0600, Mathieu Poirier wrote:
> On 8 June 2018 at 15:49, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> > On Tue, Jun 05, 2018 at 10:43:21PM +0100, Suzuki K Poulose wrote:
> >> Switch to updated coresight bindings for hw ports.
> >>
> >> Cc: Sudeep Holla <sudeep.holla@arm.com>
> >> Cc: Liviu Dudau <liviu.dudau@arm.com>
> >> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> >> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> ---
> >> Changes since V1:
> >> - Add support Juno for r1 & r2.
> >> ---
> >
> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Sudeep please hold on before applying this as there is more work to be
> done on this set.
>
Sure, I plan to apply the DT changes only after the driver changes are
queued by you or whichever tree it's channelled through. I was already
told the same to Suzuki.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] pwm: stm32: fix build warning with CONFIG_DMA_ENGINE disabled
From: Arnd Bergmann @ 2018-06-12 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXJg0mYbs=e0QJMDb=A+bRbPsNF=TJzSumSjjOK3yJw2Q@mail.gmail.com>
On Tue, Jun 12, 2018 at 9:25 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>> --- a/drivers/pwm/pwm-stm32.c
>> +++ b/drivers/pwm/pwm-stm32.c
>> @@ -484,9 +484,7 @@ static int stm32_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device *pwm,
>> static const struct pwm_ops stm32pwm_ops = {
>> .owner = THIS_MODULE,
>> .apply = stm32_pwm_apply_locked,
>> -#if IS_ENABLED(CONFIG_DMA_ENGINE)
>> - .capture = stm32_pwm_capture,
>> -#endif
>> + .capture = IS_ENABLED(CONFIG_DMA_ENGINE) ? stm32_pwm_capture : NULL,
>
> Cool, I didn't know IS_ENABLED() can be used in static initializers.
> I guess it's too late/much work to use this trick in e.g. SET_*_PM_OPS(),
> as there are lots of places protecting the functions by #ifdefs?
It's one of those things I've been planning to do for a long time, but as
you noticed, we can't just change the macro but have to come up with a
replacement that works without those #ifdefs. Unfortunately, nobody has
come up with a good /name/ for those macros, which is still the main blocker ;-)
Arnd
^ permalink raw reply
* [PATCH v2 0/5] thermal: tsens: Prepare for version 2 of TSENS IP
From: Amit Kucheria @ 2018-06-12 10:54 UTC (permalink / raw)
To: linux-arm-kernel
This series is a mixed bag: Some code moves to deal with version 2 of the
TSENS IP in common functions, new platform support (sdm845), a cleanup
patch and a DT change to have a common way to deal with the SROT and TM
registers despite slightly different features across the IP family and
different register offsets.
I can merge the tsens-8996.c and tsens-sdm845.c files into a tsens-v2.c if
desired.
Changes since v1:
- Move get_temp() from tsens-8996 to tsens-common and rename
- Change 8996 DT entry to allow init_common() to work across sdm845 and
8996 due to different offsets
Amit Kucheria (5):
thermal: tsens: Get rid of unused fields in structure
dt: qcom: 8996: thermal: Move to DT initialisation
thermal: tsens: Move 8996 get_temp() to common code for reuse
thermal: tsens: Add support for SDM845
thermal: tsens: Check if we have valid data before reading
.../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++-
drivers/thermal/qcom/Makefile | 2 +-
drivers/thermal/qcom/tsens-8996.c | 74 +-------------------
drivers/thermal/qcom/tsens-common.c | 78 +++++++++++++++++++---
drivers/thermal/qcom/tsens-sdm845.c | 15 +++++
drivers/thermal/qcom/tsens.c | 3 +
drivers/thermal/qcom/tsens.h | 8 ++-
8 files changed, 107 insertions(+), 86 deletions(-)
create mode 100644 drivers/thermal/qcom/tsens-sdm845.c
--
2.7.4
^ permalink raw reply
* [PATCH v2 2/5] dt: qcom: 8996: thermal: Move to DT initialisation
From: Amit Kucheria @ 2018-06-12 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528799892.git.amit.kucheria@linaro.org>
We also split up the regmap address space into two, one for the TM
registers, the other for the SROT registers. This was required to deal with
different address offsets for the TM and SROT registers across different
SoC families.
Since tsens-common.c/init_common() currently only registers one address space, the order is important (TM before SROT).This is OK since the code doesn't really use the SROT functionality yet.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++++++++++-
drivers/thermal/qcom/tsens-8996.c | 1 -
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 410ae78..b4aab18 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -451,7 +451,17 @@
tsens0: thermal-sensor at 4a8000 {
compatible = "qcom,msm8996-tsens";
- reg = <0x4a8000 0x2000>;
+ reg = <0x4a9000 0x1000>, /* TM */
+ <0x4a8000 0x1000>; /* SROT */
+ #qcom,sensors = <13>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor at 4ac000 {
+ compatible = "qcom,msm8996-tsens";
+ reg = <0x4ad000 0x1000>, /* TM */
+ <0x4ac000 0x1000>; /* SROT */
+ #qcom,sensors = <8>;
#thermal-sensor-cells = <1>;
};
diff --git a/drivers/thermal/qcom/tsens-8996.c b/drivers/thermal/qcom/tsens-8996.c
index e1f7781..6e59078 100644
--- a/drivers/thermal/qcom/tsens-8996.c
+++ b/drivers/thermal/qcom/tsens-8996.c
@@ -79,6 +79,5 @@ static const struct tsens_ops ops_8996 = {
};
const struct tsens_data data_8996 = {
- .num_sensors = 13,
.ops = &ops_8996,
};
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox