* Re: [PATCH 6/6] arm64: dts: khadas-vim3: add commented support for PCIe
From: Marc Zyngier @ 2019-09-10 9:12 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-kernel, kishon, repk, linux-pci,
bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <2c25e8b5-191f-96c9-8989-23959a7b1c4e@baylibre.com>
On Mon, 09 Sep 2019 18:50:42 +0100,
Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Hi Marc,
>
> Le 09/09/2019 à 18:37, Marc Zyngier a écrit :
> > On Sun, 08 Sep 2019 14:42:58 +0100,
> > Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>
> >> The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> an USB3.0 Type A connector and a M.2 Key M slot.
> >> The PHY driving these differential lines is shared between
> >> the USB3.0 controller and the PCIe Controller, thus only
> >> a single controller can use it.
> >>
> >> The needed DT configuration when the MCU is configured to mux
> >> the PCIe/USB3.0 differential lines to the M.2 Key M slot is
> >> added commented and may uncommented to disable USB3.0 from the
> >> USB Complex and enable the PCIe controller.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 22 +++++++++++++++++++
> >> .../amlogic/meson-g12b-s922x-khadas-vim3.dts | 22 +++++++++++++++++++
> >> .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 ++++
> >> .../dts/amlogic/meson-sm1-khadas-vim3l.dts | 22 +++++++++++++++++++
> >> 4 files changed, 70 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> index 3a6a1e0c1e32..0577b1435cbb 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> @@ -14,3 +14,25 @@
> >> / {
> >> compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
> >> };
> >> +
> >> +/*
> >> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> + * an USB3.0 Type A connector and a M.2 Key M slot.
> >> + * The PHY driving these differential lines is shared between
> >> + * the USB3.0 controller and the PCIe Controller, thus only
> >> + * a single controller can use it.
> >> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> >> + * to the M.2 Key M slot, uncomment the following block to disable
> >> + * USB3.0 from the USB Complex and enable the PCIe controller.
> >> + */
> >> +/*
> >> +&pcie {
> >> + status = "okay";
> >> +};
> >> +
> >> +&usb {
> >> + phys = <&usb2_phy0>, <&usb2_phy1>;
> >> + phy-names = "usb2-phy0", "usb2-phy1";
> >> +};
> >> + */
> >
> > Although you can't do much more than this here, I'd expect firmware on
> > the machine to provide the DT that matches its configuration. Is it
> > the way it actually works? Or is the user actually expected to edit
> > this file?
>
> It's the plan when initial VIM3 support will be merged in u-boot mainline,
> and the MCU driver will be added aswell :
> https://patchwork.ozlabs.org/cover/1156618/
> A custom board support altering the DT will be added when this patchset
> is merged upstream.
>
> But since these are separate projects, leaving this as commented is ugly,
> but necessary.
I agree with the unfortunate necessity. However, could you please have
a comment here, indicating that the user isn't expected to change this
on their own, but instead rely on the firmware/bootloader to do it
accordingly?
Thanks,
M.
--
Jazz is not dead, it just smells funny.
_______________________________________________
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 v4 05/17] arm64: hibernate: remove gotos in create_safe_exec_page
From: Pavel Tatashin @ 2019-09-10 9:12 UTC (permalink / raw)
To: Matthias Brugger
Cc: Sasha Levin, Mark Rutland, Vladimir Murzin, Jonathan Corbet,
Marc Zyngier, Catalin Marinas, Bhupesh Sharma, kexec mailing list,
LKML, James Morris, linux-mm, James Morse, Eric W. Biederman,
will, Linux ARM
In-Reply-To: <9135be3e-cf7e-821d-928d-db98aa3ec9c8@suse.com>
> On 09/09/2019 20:12, Pavel Tatashin wrote:
> > Usually, gotos are used to handle cleanup after exception, but
> > in case of create_safe_exec_page there are no clean-ups. So,
> > simply return the errors directly.
> >
>
> While at it, how about also cleaning up swsusp_arch_resume() which has the same
> issue.
Thank you for suggestion. I will do cleanups in swsusp_arch_resume() as well.
Pasha
>
> Regards,
> Matthias
>
> > Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> > Reviewed-by: James Morse <james.morse@arm.com>
> > ---
> > arch/arm64/kernel/hibernate.c | 34 +++++++++++-----------------------
> > 1 file changed, 11 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> > index 47a861e0cb0c..7bbeb33c700d 100644
> > --- a/arch/arm64/kernel/hibernate.c
> > +++ b/arch/arm64/kernel/hibernate.c
> > @@ -198,7 +198,6 @@ static int create_safe_exec_page(void *src_start, size_t length,
> > unsigned long dst_addr,
> > phys_addr_t *phys_dst_addr)
> > {
> > - int rc = 0;
> > pgd_t *trans_pgd;
> > pgd_t *pgdp;
> > pud_t *pudp;
> > @@ -206,47 +205,37 @@ static int create_safe_exec_page(void *src_start, size_t length,
> > pte_t *ptep;
> > unsigned long dst = get_safe_page(GFP_ATOMIC);
> >
> > - if (!dst) {
> > - rc = -ENOMEM;
> > - goto out;
> > - }
> > + if (!dst)
> > + return -ENOMEM;
> >
> > memcpy((void *)dst, src_start, length);
> > __flush_icache_range(dst, dst + length);
> >
> > trans_pgd = (void *)get_safe_page(GFP_ATOMIC);
> > - if (!trans_pgd) {
> > - rc = -ENOMEM;
> > - goto out;
> > - }
> > + if (!trans_pgd)
> > + return -ENOMEM;
> >
> > pgdp = pgd_offset_raw(trans_pgd, dst_addr);
> > if (pgd_none(READ_ONCE(*pgdp))) {
> > pudp = (void *)get_safe_page(GFP_ATOMIC);
> > - if (!pudp) {
> > - rc = -ENOMEM;
> > - goto out;
> > - }
> > + if (!pudp)
> > + return -ENOMEM;
> > pgd_populate(&init_mm, pgdp, pudp);
> > }
> >
> > pudp = pud_offset(pgdp, dst_addr);
> > if (pud_none(READ_ONCE(*pudp))) {
> > pmdp = (void *)get_safe_page(GFP_ATOMIC);
> > - if (!pmdp) {
> > - rc = -ENOMEM;
> > - goto out;
> > - }
> > + if (!pmdp)
> > + return -ENOMEM;
> > pud_populate(&init_mm, pudp, pmdp);
> > }
> >
> > pmdp = pmd_offset(pudp, dst_addr);
> > if (pmd_none(READ_ONCE(*pmdp))) {
> > ptep = (void *)get_safe_page(GFP_ATOMIC);
> > - if (!ptep) {
> > - rc = -ENOMEM;
> > - goto out;
> > - }
> > + if (!ptep)
> > + return -ENOMEM;
> > pmd_populate_kernel(&init_mm, pmdp, ptep);
> > }
> >
> > @@ -272,8 +261,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> >
> > *phys_dst_addr = virt_to_phys((void *)dst);
> >
> > -out:
> > - return rc;
> > + return 0;
> > }
> >
> > #define dcache_clean_range(start, end) __flush_dcache_area(start, (end - start))
> >
_______________________________________________
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 6/6] arm64: dts: khadas-vim3: add commented support for PCIe
From: Neil Armstrong @ 2019-09-10 9:14 UTC (permalink / raw)
To: Marc Zyngier
Cc: lorenzo.pieralisi, khilman, linux-kernel, kishon, repk, linux-pci,
bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <8636h4seeq.wl-marc.zyngier@arm.com>
On 10/09/2019 11:12, Marc Zyngier wrote:
> On Mon, 09 Sep 2019 18:50:42 +0100,
> Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> Hi Marc,
>>
>> Le 09/09/2019 à 18:37, Marc Zyngier a écrit :
>>> On Sun, 08 Sep 2019 14:42:58 +0100,
>>> Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>
>>>> The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
>>>> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
>>>> an USB3.0 Type A connector and a M.2 Key M slot.
>>>> The PHY driving these differential lines is shared between
>>>> the USB3.0 controller and the PCIe Controller, thus only
>>>> a single controller can use it.
>>>>
>>>> The needed DT configuration when the MCU is configured to mux
>>>> the PCIe/USB3.0 differential lines to the M.2 Key M slot is
>>>> added commented and may uncommented to disable USB3.0 from the
>>>> USB Complex and enable the PCIe controller.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>> .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 22 +++++++++++++++++++
>>>> .../amlogic/meson-g12b-s922x-khadas-vim3.dts | 22 +++++++++++++++++++
>>>> .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 ++++
>>>> .../dts/amlogic/meson-sm1-khadas-vim3l.dts | 22 +++++++++++++++++++
>>>> 4 files changed, 70 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
>>>> index 3a6a1e0c1e32..0577b1435cbb 100644
>>>> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
>>>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
>>>> @@ -14,3 +14,25 @@
>>>> / {
>>>> compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
>>>> };
>>>> +
>>>> +/*
>>>> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
>>>> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
>>>> + * an USB3.0 Type A connector and a M.2 Key M slot.
>>>> + * The PHY driving these differential lines is shared between
>>>> + * the USB3.0 controller and the PCIe Controller, thus only
>>>> + * a single controller can use it.
>>>> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
>>>> + * to the M.2 Key M slot, uncomment the following block to disable
>>>> + * USB3.0 from the USB Complex and enable the PCIe controller.
>>>> + */
>>>> +/*
>>>> +&pcie {
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> +&usb {
>>>> + phys = <&usb2_phy0>, <&usb2_phy1>;
>>>> + phy-names = "usb2-phy0", "usb2-phy1";
>>>> +};
>>>> + */
>>>
>>> Although you can't do much more than this here, I'd expect firmware on
>>> the machine to provide the DT that matches its configuration. Is it
>>> the way it actually works? Or is the user actually expected to edit
>>> this file?
>>
>> It's the plan when initial VIM3 support will be merged in u-boot mainline,
>> and the MCU driver will be added aswell :
>> https://patchwork.ozlabs.org/cover/1156618/
>> A custom board support altering the DT will be added when this patchset
>> is merged upstream.
>>
>> But since these are separate projects, leaving this as commented is ugly,
>> but necessary.
>
> I agree with the unfortunate necessity. However, could you please have
> a comment here, indicating that the user isn't expected to change this
> on their own, but instead rely on the firmware/bootloader to do it
> accordingly?
Yes, sure.
Neil
>
> Thanks,
>
> M.
>
_______________________________________________
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 v4 10/17] arm64: trans_pgd: make trans_pgd_map_page generic
From: Pavel Tatashin @ 2019-09-10 9:20 UTC (permalink / raw)
To: Matthias Brugger
Cc: Sasha Levin, Mark Rutland, Vladimir Murzin, Jonathan Corbet,
Marc Zyngier, Catalin Marinas, Bhupesh Sharma, kexec mailing list,
LKML, James Morris, linux-mm, James Morse, Eric W. Biederman,
will, Linux ARM
In-Reply-To: <60975350-87f8-56b3-437d-d9ee26ac3bd3@suse.com>
> > +/*
> > + * Add map entry to trans_pgd for a base-size page at PTE level.
> > + * page: page to be mapped.
> > + * dst_addr: new VA address for the pages
> > + * pgprot: protection for the page.
>
> For consistency please describe all function parameters. From my experience
> function parameter description is normally done in the C-file that implements
> the logic. Don't ask me why.
Ok, I move the comment, and will describe every parameter. Thank you.
>
> > + */
> > +int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
> > + void *page, unsigned long dst_addr, pgprot_t pgprot);
> >
> > #endif /* _ASM_TRANS_TABLE_H */
> > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> > index 94ede33bd777..9b75b680ab70 100644
> > --- a/arch/arm64/kernel/hibernate.c
> > +++ b/arch/arm64/kernel/hibernate.c
> > @@ -179,6 +179,12 @@ int arch_hibernation_header_restore(void *addr)
> > }
> > EXPORT_SYMBOL(arch_hibernation_header_restore);
> >
> > +static void *
> > +hibernate_page_alloc(void *arg)
>
> AFAICS no new line needed here.
Right, will fix it.
>
> > +{
> > + return (void *)get_safe_page((gfp_t)(unsigned long)arg);
> > +}
> > +
> > /*
> > * Copies length bytes, starting at src_start into an new page,
> > * perform cache maintenance, then maps it at the specified address low
> > @@ -195,6 +201,10 @@ static int create_safe_exec_page(void *src_start, size_t length,
> > unsigned long dst_addr,
> > phys_addr_t *phys_dst_addr)
> > {
> > + struct trans_pgd_info trans_info = {
> > + .trans_alloc_page = hibernate_page_alloc,
> > + .trans_alloc_arg = (void *)GFP_ATOMIC,
> > + };
>
> New line between end of struct and other variables.
Sure.
>
> With these changes:
> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Thank you,
Pasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix unreachable code issue with cmpxchg
From: Andrew Murray @ 2019-09-10 9:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Catalin Marinas, linux-kernel, clang-built-linux,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190909202153.144970-1-arnd@arndb.de>
On Mon, Sep 09, 2019 at 10:21:35PM +0200, Arnd Bergmann wrote:
> On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
> when CONFIG_OPTIMIZE_INLINING is set.
> Clang then fails a compile-time assertion, because it cannot tell at
> compile time what the size of the argument is:
>
> mm/memcontrol.o: In function `__cmpxchg_mb':
> memcontrol.c:(.text+0x1a4c): undefined reference to `__compiletime_assert_175'
> memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__compiletime_assert_175'
>
> Mark all of the cmpxchg() style functions as __always_inline to
> ensure that the compiler can see the result.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
I was able to reproduce this with the following:
$ git describe HEAD
next-20190904
$ clang --version
Android (5821526 based on r365631) clang version 9.0.6 (https://android.googlesource.com/toolchain/llvm-project 85305eaf1e90ff529d304abac8a979e1d967f0a2) (based on LLVM 9.0.6svn)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/andrewm/android-clang/clang-r365631/bin
$ make O=~/linux-build/ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang -j56 allyesconfig Image
(I was unable to reproduce with defconfig+OPTIMIZE_INLINING).
However...
> arch/arm64/include/asm/cmpxchg.h | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> index a1398f2f9994..fd64dc8a235f 100644
> --- a/arch/arm64/include/asm/cmpxchg.h
> +++ b/arch/arm64/include/asm/cmpxchg.h
> @@ -19,7 +19,7 @@
> * acquire+release for the latter.
> */
> #define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel, cl) \
> -static inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr) \
> +static __always_inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr)\
This hunk isn't needed, there is no BUILD_BUG here.
> { \
> u##sz ret; \
> unsigned long tmp; \
> @@ -62,7 +62,7 @@ __XCHG_CASE( , , mb_, 64, dmb ish, nop, , a, l, "memory")
> #undef __XCHG_CASE
>
> #define __XCHG_GEN(sfx) \
> -static inline unsigned long __xchg##sfx(unsigned long x, \
> +static __always_inline unsigned long __xchg##sfx(unsigned long x, \
> volatile void *ptr, \
> int size) \
> { \
> @@ -103,8 +103,9 @@ __XCHG_GEN(_mb)
> #define arch_xchg_release(...) __xchg_wrapper(_rel, __VA_ARGS__)
> #define arch_xchg(...) __xchg_wrapper( _mb, __VA_ARGS__)
>
> -#define __CMPXCHG_CASE(name, sz) \
> -static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> +#define __CMPXCHG_CASE(name, sz) \
> +static __always_inline u##sz \
> +__cmpxchg_case_##name##sz(volatile void *ptr, \
This hunk isn't needed, there is no BUILD_BUG here.
> u##sz old, \
> u##sz new) \
> { \
> @@ -148,7 +149,7 @@ __CMPXCHG_DBL(_mb)
> #undef __CMPXCHG_DBL
>
> #define __CMPXCHG_GEN(sfx) \
> -static inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> +static __always_inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
> unsigned long old, \
> unsigned long new, \
> int size) \
> @@ -230,7 +231,7 @@ __CMPXCHG_GEN(_mb)
> })
>
> #define __CMPWAIT_CASE(w, sfx, sz) \
> -static inline void __cmpwait_case_##sz(volatile void *ptr, \
> +static __always_inline void __cmpwait_case_##sz(volatile void *ptr, \
> unsigned long val) \
This hunk isn't needed, there is no BUILD_BUG here.
> { \
> unsigned long tmp; \
> @@ -255,7 +256,7 @@ __CMPWAIT_CASE( , , 64);
> #undef __CMPWAIT_CASE
>
> #define __CMPWAIT_GEN(sfx) \
> -static inline void __cmpwait##sfx(volatile void *ptr, \
> +static __always_inline void __cmpwait##sfx(volatile void *ptr, \
> unsigned long val, \
> int size) \
> { \
Alternatively is it possible to replace the BUILD_BUG's with something else?
I think because we use BUILD_BUG at the end of a switch statement, we make
the assumption that size is known at compile time, for this reason we should
ensure the function containing the BUILD_BUG is __always_inline.
Looking across the kernel where BUILD_BUG is used as a default in a switch
statment ($ git grep -B 3 BUILD_BUG\( | grep default), most instances are
within macros, but many are found in an __always_inline function:
arch/x86/kvm/cpuid.h
mm/kasan/generic.c
Though some are not:
include/linux/signal.h
arch/arm64/include/asm/arm_dsu/pmu.h
I wonder if there may be a latent mole ready to whack with pmu.h?
Anyway with just the three remaining hunks:
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Tested-by: Andrew Murray <andrew.murray@arm.com>
> --
> 2.20.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
From: Matthias Brugger @ 2019-09-10 9:27 UTC (permalink / raw)
To: Stefan Wahren, catalin.marinas, marc.zyngier, robh+dt, linux-mm,
linux-arm-kernel, linux-riscv, hch, Nicolas Saenz Julienne
Cc: f.fainelli, robin.murphy, linux-kernel, linux-rpi-kernel, phill,
will, m.szyprowski
In-Reply-To: <5a8af6e9-6b90-ce26-ebd7-9ee626c9fa0e@gmx.net>
On 09/09/2019 21:33, Stefan Wahren wrote:
> Hi Nicolas,
>
> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
>> Hi all,
>> this series attempts to address some issues we found while bringing up
>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
>> up of these discussions:
>> v4: https://lkml.org/lkml/2019/9/6/352
>> v3: https://lkml.org/lkml/2019/9/2/589
>> v2: https://lkml.org/lkml/2019/8/20/767
>> v1: https://lkml.org/lkml/2019/7/31/922
>> RFC: https://lkml.org/lkml/2019/7/17/476
>>
>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
>> only address the first GB: their DMA address range is
>> 0xc0000000-0xfc000000 which is aliased to the first GB of physical
>> memory 0x00000000-0x3c000000. Note that only some peripherals have these
>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
>> view of the address space by virtue of being hooked up trough a second
>> interconnect.
>>
>> Part of this is solved on arm32 by setting up the machine specific
>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent
>> memory area at the right spot. That said no buffer bouncing (needed for
>> dma streaming) is available at the moment, but that's a story for
>> another series.
>>
>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
>> arch code as if all peripherals where be able to address the first 4GB
>> of memory.
>>
>> In the light of this, the series implements the following changes:
>>
>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G
>> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far
>> the RPi4 is the only arm64 device with such DMA addressing limitations
>> so this hardcoded solution was deemed preferable.
>>
>> - Properly set ARCH_ZONE_DMA_BITS.
>>
>> - Reserve the CMA area in a place suitable for all peripherals.
>>
>> This series has been tested on multiple devices both by checking the
>> zones setup matches the expectations and by double-checking physical
>> addresses on pages allocated on the three relevant areas GFP_DMA,
>> GFP_DMA32, GFP_KERNEL:
>>
>> - On an RPi4 with variations on the ram memory size. But also forcing
>> the situation where all three memory zones are nonempty by setting a 3G
>> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
>>
> i like to test this series on Raspberry Pi 4 and i have some questions
> to get arm64 running:
>
> Do you use U-Boot? Which tree?
If you want to use U-Boot, try v2019.10-rc4, it should have everything you need
to boot your kernel.
Regards,
Matthias
> Are there any config.txt tweaks necessary?
>
>
_______________________________________________
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 1/2] mm/page_ext: support to record the last stack of page
From: Kirill A. Shutemov @ 2019-09-10 9:31 UTC (permalink / raw)
To: Walter Wu
Cc: Qian Cai, wsd_upstream, Arnd Bergmann, David Hildenbrand,
Andrey Konovalov, linux-mediatek, linux-kernel, kasan-dev,
Michal Hocko, linux-mm, Martin Schwidefsky, Alexander Potapenko,
linux-arm-kernel, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Will Deacon, Thomas Gleixner, Dmitry Vyukov
In-Reply-To: <1568077669.24886.3.camel@mtksdccf07>
On Tue, Sep 10, 2019 at 09:07:49AM +0800, Walter Wu wrote:
> On Mon, 2019-09-09 at 12:57 +0200, David Hildenbrand wrote:
> > On 09.09.19 10:53, Walter Wu wrote:
> > > KASAN will record last stack of page in order to help programmer
> > > to see memory corruption caused by page.
> > >
> > > What is difference between page_owner and our patch?
> > > page_owner records alloc stack of page, but our patch is to record
> > > last stack(it may be alloc or free stack of page).
> > >
> > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > ---
> > > mm/page_ext.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/mm/page_ext.c b/mm/page_ext.c
> > > index 5f5769c7db3b..7ca33dcd9ffa 100644
> > > --- a/mm/page_ext.c
> > > +++ b/mm/page_ext.c
> > > @@ -65,6 +65,9 @@ static struct page_ext_operations *page_ext_ops[] = {
> > > #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)
> > > &page_idle_ops,
> > > #endif
> > > +#ifdef CONFIG_KASAN
> > > + &page_stack_ops,
> > > +#endif
> > > };
> > >
> > > static unsigned long total_usage;
> > >
> >
> > Are you sure this patch compiles?
> >
> This is patchsets, it need another patch2.
> We have verified it by running KASAN UT on Qemu.
Any patchset must be bisectable: do not break anything in the middle of
patchset.
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH ARM64 v4.4 V3 12/44] arm64: cpufeature: Test 'matches' pointer to find the end of the list
From: Viresh Kumar @ 2019-09-10 9:35 UTC (permalink / raw)
To: Mark Rutland
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190906134935.GA17375@lakrids.cambridge.arm.com>
On 06-09-19, 14:49, Mark Rutland wrote:
> I think it would be worthwhile to do that ASAP to make sure there are no
> boot-time or run-time regressions. We can look at the logs later (or
> re-run with some additional logging) to verify things are working as
> expected.
Sure, so my branch already goes through some LAVA testing from Linaro and
kernel-ci as well. It also gets build tested by 0-day testing bot.
I will make sure it runs on some big.LITTLE stuff on LAVA. Thanks.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix unreachable code issue with cmpxchg
From: Arnd Bergmann @ 2019-09-10 9:38 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, Catalin Marinas, linux-kernel@vger.kernel.org,
clang-built-linux, Will Deacon, Linux ARM
In-Reply-To: <20190910092324.GI9720@e119886-lin.cambridge.arm.com>
On Tue, Sep 10, 2019 at 11:23 AM Andrew Murray <andrew.murray@arm.com> wrote:
>
> > arch/arm64/include/asm/cmpxchg.h | 15 ++++++++-------
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> > index a1398f2f9994..fd64dc8a235f 100644
> > --- a/arch/arm64/include/asm/cmpxchg.h
> > +++ b/arch/arm64/include/asm/cmpxchg.h
> > @@ -19,7 +19,7 @@
> > * acquire+release for the latter.
> > */
> > #define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel, cl) \
> > -static inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr) \
> > +static __always_inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr)\
>
> This hunk isn't needed, there is no BUILD_BUG here.
Right, I noticed this, but it seemed like a good idea regardless given the small
size of the function compared with the overhead of a function call. We clearly
want these to be inlined all the time.
Same for the others.
> Alternatively is it possible to replace the BUILD_BUG's with something else?
>
> I think because we use BUILD_BUG at the end of a switch statement, we make
> the assumption that size is known at compile time, for this reason we should
> ensure the function containing the BUILD_BUG is __always_inline.
>
> Looking across the kernel where BUILD_BUG is used as a default in a switch
> statment ($ git grep -B 3 BUILD_BUG\( | grep default), most instances are
> within macros, but many are found in an __always_inline function:
>
> arch/x86/kvm/cpuid.h
> mm/kasan/generic.c
>
> Though some are not:
>
> include/linux/signal.h
> arch/arm64/include/asm/arm_dsu/pmu.h
>
> I wonder if there may be a latent mole ready to whack with pmu.h?
Right, it can't hurt to annotate those as well. I actually have another
fixup for linux/signal.h that I would have to revisit at some point.
See https://bugs.llvm.org/show_bug.cgi?id=38789, I think this is
fixed with clang-9 now, but maybe not with clang-8.
Arnd
_______________________________________________
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 1/2] mm/page_ext: support to record the last stack of page
From: Walter Wu @ 2019-09-10 9:43 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Qian Cai, wsd_upstream, Arnd Bergmann, David Hildenbrand,
Andrey Konovalov, linux-mediatek, linux-kernel, kasan-dev,
Michal Hocko, linux-mm, Martin Schwidefsky, Alexander Potapenko,
linux-arm-kernel, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Will Deacon, Thomas Gleixner, Dmitry Vyukov
In-Reply-To: <20190910093103.4cmqk4semlhgpmle@box.shutemov.name>
On Tue, 2019-09-10 at 12:31 +0300, Kirill A. Shutemov wrote:
> On Tue, Sep 10, 2019 at 09:07:49AM +0800, Walter Wu wrote:
> > On Mon, 2019-09-09 at 12:57 +0200, David Hildenbrand wrote:
> > > On 09.09.19 10:53, Walter Wu wrote:
> > > > KASAN will record last stack of page in order to help programmer
> > > > to see memory corruption caused by page.
> > > >
> > > > What is difference between page_owner and our patch?
> > > > page_owner records alloc stack of page, but our patch is to record
> > > > last stack(it may be alloc or free stack of page).
> > > >
> > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > > ---
> > > > mm/page_ext.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/mm/page_ext.c b/mm/page_ext.c
> > > > index 5f5769c7db3b..7ca33dcd9ffa 100644
> > > > --- a/mm/page_ext.c
> > > > +++ b/mm/page_ext.c
> > > > @@ -65,6 +65,9 @@ static struct page_ext_operations *page_ext_ops[] = {
> > > > #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)
> > > > &page_idle_ops,
> > > > #endif
> > > > +#ifdef CONFIG_KASAN
> > > > + &page_stack_ops,
> > > > +#endif
> > > > };
> > > >
> > > > static unsigned long total_usage;
> > > >
> > >
> > > Are you sure this patch compiles?
> > >
> > This is patchsets, it need another patch2.
> > We have verified it by running KASAN UT on Qemu.
>
> Any patchset must be bisectable: do not break anything in the middle of
> patchset.
>
Thanks your reminder.
I should explain complete message at commit log.
Our patchsets is below:
https://lkml.org/lkml/2019/9/9/104
https://lkml.org/lkml/2019/9/9/123
_______________________________________________
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/2] mm/kasan: dump alloc/free stack for page allocator
From: Walter Wu @ 2019-09-10 9:53 UTC (permalink / raw)
To: Andrey Ryabinin, Dmitry Vyukov, Andrey Konovalov, Arnd Bergmann,
Qian Cai
Cc: wsd_upstream, linux-mm, linux-kernel, kasan-dev, Michal Hocko,
Martin Schwidefsky, Alexander Potapenko, Matthias Brugger,
linux-mediatek, Andrew Morton, Will Deacon, Thomas Gleixner,
linux-arm-kernel
In-Reply-To: <20190909082412.24356-1-walter-zh.wu@mediatek.com>
On Mon, 2019-09-09 at 16:24 +0800, walter-zh.wu@mediatek.com wrote:
> From: Walter Wu <walter-zh.wu@mediatek.com>
>
> This patch is KASAN report adds the alloc/free stacks for page allocator
> in order to help programmer to see memory corruption caused by page.
>
> By default, KASAN doesn't record alloc and free stack for page allocator.
> It is difficult to fix up page use-after-free or dobule-free issue.
>
> Our patchsets will record the last stack of pages.
> It is very helpful for solving the page use-after-free or double-free.
>
> KASAN report will show the last stack of page, it may be:
> a) If page is in-use state, then it prints alloc stack.
> It is useful to fix up page out-of-bound issue.
>
> BUG: KASAN: slab-out-of-bounds in kmalloc_pagealloc_oob_right+0x88/0x90
> Write of size 1 at addr ffffffc0d64ea00a by task cat/115
> ...
> Allocation stack of page:
> set_page_stack.constprop.1+0x30/0xc8
> kasan_alloc_pages+0x18/0x38
> prep_new_page+0x5c/0x150
> get_page_from_freelist+0xb8c/0x17c8
> __alloc_pages_nodemask+0x1a0/0x11b0
> kmalloc_order+0x28/0x58
> kmalloc_order_trace+0x28/0xe0
> kmalloc_pagealloc_oob_right+0x2c/0x68
>
> b) If page is freed state, then it prints free stack.
> It is useful to fix up page use-after-free or double-free issue.
>
> BUG: KASAN: use-after-free in kmalloc_pagealloc_uaf+0x70/0x80
> Write of size 1 at addr ffffffc0d651c000 by task cat/115
> ...
> Free stack of page:
> kasan_free_pages+0x68/0x70
> __free_pages_ok+0x3c0/0x1328
> __free_pages+0x50/0x78
> kfree+0x1c4/0x250
> kmalloc_pagealloc_uaf+0x38/0x80
>
> This has been discussed, please refer below link.
> https://bugzilla.kernel.org/show_bug.cgi?id=203967
>
> Changes since v1:
> - slim page_owner and move it into kasan
> - enable the feature by default
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> ---
> include/linux/kasan.h | 1 +
> lib/Kconfig.kasan | 2 ++
> mm/kasan/common.c | 32 ++++++++++++++++++++++++++++++++
> mm/kasan/kasan.h | 5 +++++
> mm/kasan/report.c | 27 +++++++++++++++++++++++++++
> 5 files changed, 67 insertions(+)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index cc8a03cc9674..97e1bcb20489 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -19,6 +19,7 @@ extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
> extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
> extern pud_t kasan_early_shadow_pud[PTRS_PER_PUD];
> extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D];
> +extern struct page_ext_operations page_stack_ops;
>
> int kasan_populate_early_shadow(const void *shadow_start,
> const void *shadow_end);
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 4fafba1a923b..b5a9410ba4e8 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -41,6 +41,7 @@ config KASAN_GENERIC
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGE_EXTENSION
> help
> Enables generic KASAN mode.
> Supported in both GCC and Clang. With GCC it requires version 4.9.2
> @@ -63,6 +64,7 @@ config KASAN_SW_TAGS
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGE_EXTENSION
> help
> Enables software tag-based KASAN mode.
> This mode requires Top Byte Ignore support by the CPU and therefore
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 2277b82902d8..c349143d2587 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -211,10 +211,38 @@ void kasan_unpoison_stack_above_sp_to(const void *watermark)
> kasan_unpoison_shadow(sp, size);
> }
>
> +static bool need_page_stack(void)
> +{
> + return true;
> +}
> +
> +struct page_ext_operations page_stack_ops = {
> + .size = sizeof(depot_stack_handle_t),
> + .need = need_page_stack,
> +};
> +
> +static void set_page_stack(struct page *page, gfp_t gfp_mask)
> +{
> + struct page_ext *page_ext = lookup_page_ext(page);
> + depot_stack_handle_t handle;
> + depot_stack_handle_t *page_stack;
> +
> + if (unlikely(!page_ext))
> + return;
> +
> + handle = save_stack(gfp_mask);
> +
> + page_stack = get_page_stack(page_ext);
> + *page_stack = handle;
> +}
> +
> void kasan_alloc_pages(struct page *page, unsigned int order)
> {
> u8 tag;
> unsigned long i;
> + gfp_t gfp_flags = GFP_KERNEL;
> +
> + set_page_stack(page, gfp_flags);
>
> if (unlikely(PageHighMem(page)))
> return;
> @@ -227,6 +255,10 @@ void kasan_alloc_pages(struct page *page, unsigned int order)
>
> void kasan_free_pages(struct page *page, unsigned int order)
> {
> + gfp_t gfp_flags = GFP_KERNEL;
> +
> + set_page_stack(page, gfp_flags);
> +
> if (likely(!PageHighMem(page)))
> kasan_poison_shadow(page_address(page),
> PAGE_SIZE << order,
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index 014f19e76247..95b3b510d04f 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -126,6 +126,11 @@ static inline bool addr_has_shadow(const void *addr)
> return (addr >= kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
> }
>
> +static inline depot_stack_handle_t *get_page_stack(struct page_ext *page_ext)
> +{
> + return (void *)page_ext + page_stack_ops.offset;
> +}
> +
> void kasan_poison_shadow(const void *address, size_t size, u8 value);
>
> /**
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 0e5f965f1882..2e26bc192114 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -344,6 +344,32 @@ static void print_address_stack_frame(const void *addr)
> print_decoded_frame_descr(frame_descr);
> }
>
> +static void dump_page_stack(struct page *page)
> +{
> + struct page_ext *page_ext = lookup_page_ext(page);
> + depot_stack_handle_t handle;
> + unsigned long *entries;
> + unsigned int nr_entries;
> + depot_stack_handle_t *page_stack;
> +
> + if (unlikely(!page_ext))
> + return;
> +
> + page_stack = get_page_stack(page_ext);
> +
> + handle = READ_ONCE(*page_stack);
> + if (!handle)
> + return;
> +
> + if ((unsigned long)page->flags & PAGE_FLAGS_CHECK_AT_PREP)
> + pr_info("Allocation stack of page:\n");
> + else
> + pr_info("Free stack of page:\n");
> +
> + nr_entries = stack_depot_fetch(handle, &entries);
> + stack_trace_print(entries, nr_entries, 0);
> +}
> +
> static void print_address_description(void *addr)
> {
> struct page *page = addr_to_page(addr);
> @@ -366,6 +392,7 @@ static void print_address_description(void *addr)
> if (page) {
> pr_err("The buggy address belongs to the page:\n");
> dump_page(page, "kasan: bad access detected");
> + dump_page_stack(page);
> }
>
> print_address_stack_frame(addr);
Hi All,
We implement another version, it is different with v1. We hope that you
can give an ideas and make the KASAN report better. If it is possible,
we can use the less memory to show the corruption information that is
enough to help programmer to fix up memory corruption.
Thanks.
Walter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] docs: arm: Fix RAM offset requirement for loading a raw image
From: Alexandru Elisei @ 2019-09-10 10:03 UTC (permalink / raw)
To: linux-doc, linux-arm-kernel
Cc: ian.campbell, corbet, catalin.marinas, linux, mchehab, will
Commit 83d26d1113d8 ("ARM: 7824/1: update advice on kernel, initramfs and
FDT load address.") changed the offset requirement for loading a raw kernel
image into RAM from 32KiB (0x8000) to TEXT_OFFSET - PAGE_OFFSET, which
results in a negative value. Change the offset to be TEXT_OFFSET, which has
an arch dependent value between 0x8000 and 0x308000.
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
Documentation/arm/booting.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm/booting.rst b/Documentation/arm/booting.rst
index 4babb6c6ae1e..0507e7e3357e 100644
--- a/Documentation/arm/booting.rst
+++ b/Documentation/arm/booting.rst
@@ -178,8 +178,8 @@ prior to decompression, which will make the boot process slightly
faster.
When booting a raw (non-zImage) kernel the constraints are tighter.
-In this case the kernel must be loaded at an offset into system equal
-to TEXT_OFFSET - PAGE_OFFSET.
+In this case the kernel must be loaded at an offset into system RAM
+equal to TEXT_OFFSET.
In any case, the following conditions must be met:
--
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 related
* Applied "regulator: uniphier: Add Pro5 USB3 VBUS support" to the regulator tree
From: Mark Brown @ 2019-09-10 10:06 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Mark Rutland, devicetree, Masami Hiramatsu, Masahiro Yamada,
linux-kernel, Rob Herring, Liam Girdwood, Jassi Brar, Mark Brown,
linux-arm-kernel
In-Reply-To: <1568080304-1572-1-git-send-email-hayashi.kunihiko@socionext.com>
The patch
regulator: uniphier: Add Pro5 USB3 VBUS support
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 3ba5368dc4e5947cb70287754960776c471eb23d Mon Sep 17 00:00:00 2001
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date: Tue, 10 Sep 2019 10:51:44 +0900
Subject: [PATCH] regulator: uniphier: Add Pro5 USB3 VBUS support
Pro5 SoC has same scheme of USB3 VBUS as Pro4, so the data for Pro5 is
equivalent to Pro4.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1568080304-1572-1-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/regulator/uniphier-regulator.txt | 5 +++--
drivers/regulator/uniphier-regulator.c | 4 ++++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt
index c9919f4b92d2..94fd38b0d163 100644
--- a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt
@@ -13,6 +13,7 @@ this layer. These clocks and resets should be described in each property.
Required properties:
- compatible: Should be
"socionext,uniphier-pro4-usb3-regulator" - for Pro4 SoC
+ "socionext,uniphier-pro5-usb3-regulator" - for Pro5 SoC
"socionext,uniphier-pxs2-usb3-regulator" - for PXs2 SoC
"socionext,uniphier-ld20-usb3-regulator" - for LD20 SoC
"socionext,uniphier-pxs3-usb3-regulator" - for PXs3 SoC
@@ -20,12 +21,12 @@ Required properties:
- clocks: A list of phandles to the clock gate for USB3 glue layer.
According to the clock-names, appropriate clocks are required.
- clock-names: Should contain
- "gio", "link" - for Pro4 SoC
+ "gio", "link" - for Pro4 and Pro5 SoCs
"link" - for others
- resets: A list of phandles to the reset control for USB3 glue layer.
According to the reset-names, appropriate resets are required.
- reset-names: Should contain
- "gio", "link" - for Pro4 SoC
+ "gio", "link" - for Pro4 and Pro5 SoCs
"link" - for others
See Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/drivers/regulator/uniphier-regulator.c b/drivers/regulator/uniphier-regulator.c
index 9026d5a3e964..2311924c3103 100644
--- a/drivers/regulator/uniphier-regulator.c
+++ b/drivers/regulator/uniphier-regulator.c
@@ -185,6 +185,10 @@ static const struct of_device_id uniphier_regulator_match[] = {
.compatible = "socionext,uniphier-pro4-usb3-regulator",
.data = &uniphier_pro4_usb3_data,
},
+ {
+ .compatible = "socionext,uniphier-pro5-usb3-regulator",
+ .data = &uniphier_pro4_usb3_data,
+ },
{
.compatible = "socionext,uniphier-pxs2-usb3-regulator",
.data = &uniphier_pxs2_usb3_data,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: fix unreachable code issue with cmpxchg
From: Masahiro Yamada @ 2019-09-10 10:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Catalin Marinas, linux-kernel@vger.kernel.org,
clang-built-linux, Andrew Murray, Will Deacon, Linux ARM
In-Reply-To: <CAK8P3a2Vk+KSUGJyPTRuLPD=KPEAR43SZ1ofB6k+KeQi3fSERw@mail.gmail.com>
On Tue, Sep 10, 2019 at 6:38 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Sep 10, 2019 at 11:23 AM Andrew Murray <andrew.murray@arm.com> wrote:
>
> >
> > > arch/arm64/include/asm/cmpxchg.h | 15 ++++++++-------
> > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> > > index a1398f2f9994..fd64dc8a235f 100644
> > > --- a/arch/arm64/include/asm/cmpxchg.h
> > > +++ b/arch/arm64/include/asm/cmpxchg.h
> > > @@ -19,7 +19,7 @@
> > > * acquire+release for the latter.
> > > */
> > > #define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel, cl) \
> > > -static inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr) \
> > > +static __always_inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr)\
> >
> > This hunk isn't needed, there is no BUILD_BUG here.
>
> Right, I noticed this, but it seemed like a good idea regardless given the small
> size of the function compared with the overhead of a function call. We clearly
> want these to be inlined all the time.
Generally speaking, this should be judged by the compiler, not by humans.
If the function size is quite small compared with the cost of function call,
the compiler will determine to inline it anyway.
(If the compiler's inlining heuristic is not good, we should fix the compiler.)
So, I personally agree with Andrew Murray.
We should use __always_inline only when we must to do so.
Masahiro Yamada
>
> Same for the others.
>
> > Alternatively is it possible to replace the BUILD_BUG's with something else?
> >
> > I think because we use BUILD_BUG at the end of a switch statement, we make
> > the assumption that size is known at compile time, for this reason we should
> > ensure the function containing the BUILD_BUG is __always_inline.
> >
> > Looking across the kernel where BUILD_BUG is used as a default in a switch
> > statment ($ git grep -B 3 BUILD_BUG\( | grep default), most instances are
> > within macros, but many are found in an __always_inline function:
> >
> > arch/x86/kvm/cpuid.h
> > mm/kasan/generic.c
> >
> > Though some are not:
> >
> > include/linux/signal.h
> > arch/arm64/include/asm/arm_dsu/pmu.h
> >
> > I wonder if there may be a latent mole ready to whack with pmu.h?
>
> Right, it can't hurt to annotate those as well. I actually have another
> fixup for linux/signal.h that I would have to revisit at some point.
> See https://bugs.llvm.org/show_bug.cgi?id=38789, I think this is
> fixed with clang-9 now, but maybe not with clang-8.
>
> Arnd
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] gpio: API boundary cleanups
From: Linus Walleij @ 2019-09-10 10:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski, Rob Herring, Frank Rowand, Linux ARM
In-Reply-To: <20190906084539.21838-1-geert+renesas@glider.be>
On Fri, Sep 6, 2019 at 9:45 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> This patch series contains various API boundary cleanups for gpiolib:
> - The first two patches make two functions private,
> - The last two patches switch the remaining gpiolib exported functions
> from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL().
Good stuff, let's merge for early v5.4 (possibly rebasing if necessary).
> After this there is only a single GPIO driver function exported with
> EXPORT_SYMBOL();
>
> drivers/gpio/gpio-htc-egpio.c:EXPORT_SYMBOL(htc_egpio_get_wakeup_irq);
Kill it. People using this platform should step up if they need it.
The outoftree code was at handhelds.org and that web site is
even down. There is a copy of their git tree on github
somewhere but it is definately not maintained.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix unreachable code issue with cmpxchg
From: Andrew Murray @ 2019-09-10 10:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Catalin Marinas, linux-kernel@vger.kernel.org,
clang-built-linux, Will Deacon, Linux ARM
In-Reply-To: <CAK8P3a2Vk+KSUGJyPTRuLPD=KPEAR43SZ1ofB6k+KeQi3fSERw@mail.gmail.com>
On Tue, Sep 10, 2019 at 11:38:37AM +0200, Arnd Bergmann wrote:
> On Tue, Sep 10, 2019 at 11:23 AM Andrew Murray <andrew.murray@arm.com> wrote:
>
> >
> > > arch/arm64/include/asm/cmpxchg.h | 15 ++++++++-------
> > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> > > index a1398f2f9994..fd64dc8a235f 100644
> > > --- a/arch/arm64/include/asm/cmpxchg.h
> > > +++ b/arch/arm64/include/asm/cmpxchg.h
> > > @@ -19,7 +19,7 @@
> > > * acquire+release for the latter.
> > > */
> > > #define __XCHG_CASE(w, sfx, name, sz, mb, nop_lse, acq, acq_lse, rel, cl) \
> > > -static inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr) \
> > > +static __always_inline u##sz __xchg_case_##name##sz(u##sz x, volatile void *ptr)\
> >
> > This hunk isn't needed, there is no BUILD_BUG here.
>
> Right, I noticed this, but it seemed like a good idea regardless given the small
> size of the function compared with the overhead of a function call. We clearly
> want these to be inlined all the time.
>
> Same for the others.
I'm not so sure - isn't the point of something like OPTIMIZE_INLINING to give
more freedom to the tooling (and by virtue of the option - the user)?
Surely any decent optimising compiler will do the right thing by inlining small
trivial functions that are annotated with inline? And if not, the compiler
should be fixed not the kernel - unless of course it causes an issue - and then
we should fix those specific cases.
There must be dozens of trivial functions that are marked with __inline, I
don't think it would make sense to mark those as __always_inline. For example the
atomics in atomic_lse.h are trivial but only marked inline. We obviously want
them inline, though I don't think we should babysit the compiler to do the
right thing.
(Also the commit message implies that all the hunks are required to fix this
particular issue which they are not).
Thanks,
Andrew Murray
>
> > Alternatively is it possible to replace the BUILD_BUG's with something else?
> >
> > I think because we use BUILD_BUG at the end of a switch statement, we make
> > the assumption that size is known at compile time, for this reason we should
> > ensure the function containing the BUILD_BUG is __always_inline.
> >
> > Looking across the kernel where BUILD_BUG is used as a default in a switch
> > statment ($ git grep -B 3 BUILD_BUG\( | grep default), most instances are
> > within macros, but many are found in an __always_inline function:
> >
> > arch/x86/kvm/cpuid.h
> > mm/kasan/generic.c
> >
> > Though some are not:
> >
> > include/linux/signal.h
> > arch/arm64/include/asm/arm_dsu/pmu.h
> >
> > I wonder if there may be a latent mole ready to whack with pmu.h?
>
> Right, it can't hurt to annotate those as well. I actually have another
> fixup for linux/signal.h that I would have to revisit at some point.
> See https://bugs.llvm.org/show_bug.cgi?id=38789, I think this is
> fixed with clang-9 now, but maybe not with clang-8.
>
> Arnd
_______________________________________________
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/2] mm/kasan: dump alloc/free stack for page allocator
From: Andrey Ryabinin @ 2019-09-10 10:50 UTC (permalink / raw)
To: Vlastimil Babka, walter-zh.wu, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Andrew Morton, Martin Schwidefsky, Will Deacon,
Andrey Konovalov, Arnd Bergmann, Thomas Gleixner, Michal Hocko,
Qian Cai
Cc: wsd_upstream, linux-kernel, kasan-dev, linux-mm, linux-mediatek,
linux-arm-kernel
In-Reply-To: <d53d88df-d9a4-c126-32a8-4baeb0645a2c@suse.cz>
On 9/9/19 4:07 PM, Vlastimil Babka wrote:
> On 9/9/19 10:24 AM, walter-zh.wu@mediatek.com wrote:
>> From: Walter Wu <walter-zh.wu@mediatek.com>
>>
>> This patch is KASAN report adds the alloc/free stacks for page allocator
>> in order to help programmer to see memory corruption caused by page.
>>
>> By default, KASAN doesn't record alloc and free stack for page allocator.
>> It is difficult to fix up page use-after-free or dobule-free issue.
>>
>> Our patchsets will record the last stack of pages.
>> It is very helpful for solving the page use-after-free or double-free.
>>
>> KASAN report will show the last stack of page, it may be:
>> a) If page is in-use state, then it prints alloc stack.
>> It is useful to fix up page out-of-bound issue.
>
> I still disagree with duplicating most of page_owner functionality for the sake of using a single stack handle for both alloc and free (while page_owner + debug_pagealloc with patches in mmotm uses two handles). It reduces the amount of potentially important debugging information, and I really doubt the u32-per-page savings are significant, given the rest of KASAN overhead.
>
>> BUG: KASAN: slab-out-of-bounds in kmalloc_pagealloc_oob_right+0x88/0x90
>> Write of size 1 at addr ffffffc0d64ea00a by task cat/115
>> ...
>> Allocation stack of page:
>> set_page_stack.constprop.1+0x30/0xc8
>> kasan_alloc_pages+0x18/0x38
>> prep_new_page+0x5c/0x150
>> get_page_from_freelist+0xb8c/0x17c8
>> __alloc_pages_nodemask+0x1a0/0x11b0
>> kmalloc_order+0x28/0x58
>> kmalloc_order_trace+0x28/0xe0
>> kmalloc_pagealloc_oob_right+0x2c/0x68
>>
>> b) If page is freed state, then it prints free stack.
>> It is useful to fix up page use-after-free or double-free issue.
>>
>> BUG: KASAN: use-after-free in kmalloc_pagealloc_uaf+0x70/0x80
>> Write of size 1 at addr ffffffc0d651c000 by task cat/115
>> ...
>> Free stack of page:
>> kasan_free_pages+0x68/0x70
>> __free_pages_ok+0x3c0/0x1328
>> __free_pages+0x50/0x78
>> kfree+0x1c4/0x250
>> kmalloc_pagealloc_uaf+0x38/0x80
>>
>> This has been discussed, please refer below link.
>> https://bugzilla.kernel.org/show_bug.cgi?id=203967
>
> That's not a discussion, but a single comment from Dmitry, which btw contains "provide alloc *and* free stacks for it" ("it" refers to page, emphasis mine). It would be nice if he or other KASAN guys could clarify.
>
For slab objects we memorize both alloc and free stacks. You'll never know in advance what information will be usefull
to fix an issue, so it usually better to provide more information. I don't think we should do anything different for pages.
Given that we already have the page_owner responsible for providing alloc/free stacks for pages, all that we should in KASAN do is to
enable the feature by default. Free stack saving should be decoupled from debug_pagealloc into separate option so that it can be enabled
by KASAN and/or debug_pagealloc.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH] MAINTAINERS: Update path to physmap-versatile.c
From: Denis Efremov @ 2019-09-10 11:46 UTC (permalink / raw)
Cc: Boris Brezillon, Linus Walleij, linux-kernel@vger.kernel.org,
Joe Perches, Ricardo Ribalda Delgado, Linux ARM
In-Reply-To: <CACRpkdZRW1fpjf=vQbuDdSC1ZU9o2tq2C2bL0GonQbnPWc06-A@mail.gmail.com>
Hi,
On 8/13/19 10:20 AM, Linus Walleij wrote:
> On Tue, Aug 13, 2019 at 8:33 AM Denis Efremov <efremov@linux.com> wrote:
>
>> Update MAINTAINERS record to reflect the filename change
>> from physmap_of_versatile.c to physmap-versatile.c
>>
>> Cc: Boris Brezillon <bbrezillon@kernel.org>
>> Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Fixes: 6ca15cfa0788 ("mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini}")
>> Signed-off-by: Denis Efremov <efremov@linux.com>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
>
Could someone take this fix through his tree?
Thanks,
Denis
_______________________________________________
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] clk: imx: lpcg: write twice when writing lpcg regs
From: Daniel Baluta @ 2019-09-10 11:50 UTC (permalink / raw)
To: Anson Huang
Cc: Aisheng Dong, Peng Fan, Dong Aisheng, Stephen Boyd,
shawnguo@kernel.org, mturquette@baylibre.com,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
Abel Vesa, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <DB3PR0402MB3916906683B58843B459ABE1F5B60@DB3PR0402MB3916.eurprd04.prod.outlook.com>
On Tue, Sep 10, 2019 at 1:40 PM Anson Huang <anson.huang@nxp.com> wrote:
>
>
>
> > On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Quoting Peng Fan (2019-08-27 01:17:50)
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > There is hardware issue that:
> > > > The output clock the LPCG cell will not turn back on as expected,
> > > > even though a read of the IPG registers in the LPCG indicates that
> > > > the clock should be enabled.
> > > >
> > > > The software workaround is to write twice to enable the LPCG clock
> > > > output.
> > > >
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > >
> > > Does this need a Fixes tag?
> >
> > Not sure as it's not code logic issue but a hardware bug.
> > And 4.19 LTS still have not this driver support.
>
> Looks like there is an errata for this issue, and Ranjani just sent a patch for review internally,
>
> Back-to-back LPCG writes can be ignored by the LPCG register due to a
> HW bug. The writes need to be separated by atleast 4 cycles of the gated clock.
> The workaround is implemented as follows:
> 1. For clocks running greater than 50MHz no delay is required as the
> delay in accessing the LPCG register is sufficient.
> 2. For clocks running greater than 23MHz, a read followed by the write
> will provide the sufficient delay.
> 3. For clocks running below 23MHz, LPCG is not used.
Lets add this information in the commit message and also
enhance the comment before the double write.
Also, why can't we add a udelay after the first write and remove
the second write as having two writes for writing a value looks
very un-natural.
_______________________________________________
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/2] mm/kasan: dump alloc/free stack for page allocator
From: Vlastimil Babka @ 2019-09-10 11:53 UTC (permalink / raw)
To: Andrey Ryabinin, walter-zh.wu, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Andrew Morton, Martin Schwidefsky, Will Deacon,
Andrey Konovalov, Arnd Bergmann, Thomas Gleixner, Michal Hocko,
Qian Cai
Cc: wsd_upstream, linux-kernel, kasan-dev, linux-mm, linux-mediatek,
linux-arm-kernel
In-Reply-To: <a7863965-90ab-5dae-65e7-8f68f4b4beb5@virtuozzo.com>
On 9/10/19 12:50 PM, Andrey Ryabinin wrote:
>
>
> For slab objects we memorize both alloc and free stacks. You'll never know in advance what information will be usefull
> to fix an issue, so it usually better to provide more information. I don't think we should do anything different for pages.
Exactly, thanks.
> Given that we already have the page_owner responsible for providing alloc/free stacks for pages, all that we should in KASAN do is to
> enable the feature by default. Free stack saving should be decoupled from debug_pagealloc into separate option so that it can be enabled
> by KASAN and/or debug_pagealloc.
Right. Walter, can you do it that way, or should I?
Thanks,
Vlastimil
_______________________________________________
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] reset: uniphier-glue: Add Pro5 USB3 support
From: Kunihiko Hayashi @ 2019-09-10 11:56 UTC (permalink / raw)
To: Philipp Zabel
Cc: Mark Rutland, devicetree, Masami Hiramatsu, Jassi Brar,
linux-kernel, Masahiro Yamada, Rob Herring, linux-arm-kernel
In-Reply-To: <1568101695.3062.1.camel@pengutronix.de>
Hi Philipp,
On Tue, 10 Sep 2019 09:48:15 +0200 <p.zabel@pengutronix.de> wrote:
> Hi Kunihiko,
>
> On Tue, 2019-09-10 at 10:55 +0900, Kunihiko Hayashi wrote:
> > Pro5 SoC has same scheme of USB3 reset as Pro4, so the data for Pro5 is
> > equivalent to Pro4.
> >
> > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>
> If it is exactly the same, you could keep using the same compatible:
This driver is derived from reset-simple, so the method to control reset
in the glue block is the same for each SoC.
And both Pro4 and Pro5 need same parent clock and reset, so the data for
these SoCs refer same parent clock names and parent reset names.
However, since the glue block itself can be different, I think that
compatible string should be distinguished for each SoC.
For example, "pxs2-usb3-reset", "ld20-usb3-reset" and "pxs3-usb-reset"
in this driver are distinguished for the same reason.
Thank you,
>
> > ---
> > Documentation/devicetree/bindings/reset/uniphier-reset.txt | 5 +++--
> > drivers/reset/reset-uniphier-glue.c | 4 ++++
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> > index ea00517..e320a8c 100644
> > --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> > +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> > @@ -130,6 +130,7 @@ this layer. These clocks and resets should be described in each property.
> > Required properties:
> > - compatible: Should be
> > "socionext,uniphier-pro4-usb3-reset" - for Pro4 SoC USB3
> > + "socionext,uniphier-pro5-usb3-reset" - for Pro5 SoC USB3
>
> + "socionext,uniphier-pro5-usb3-reset", "socionext,uniphier-pro4-usb3-reset" - for Pro5 SoC USB3
>
> [...]
> > diff --git a/drivers/reset/reset-uniphier-glue.c b/drivers/reset/reset-uniphier-glue.c
> > index a45923f..2b188b3bb 100644
> > --- a/drivers/reset/reset-uniphier-glue.c
> > +++ b/drivers/reset/reset-uniphier-glue.c
> > @@ -141,6 +141,10 @@ static const struct of_device_id uniphier_glue_reset_match[] = {
> > .data = &uniphier_pro4_data,
> > },
> > {
> > + .compatible = "socionext,uniphier-pro5-usb3-reset",
> > + .data = &uniphier_pro4_data,
> > + },
> > + {
> > .compatible = "socionext,uniphier-pxs2-usb3-reset",
> > .data = &uniphier_pxs2_data,
> > },
>
> And this change would not be necessary.
>
> regards
> Philipp
---
Best Regards,
Kunihiko Hayashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] [v2] arm64: fix unreachable code issue with cmpxchg
From: Arnd Bergmann @ 2019-09-10 11:56 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, Arnd Bergmann, Peter Zijlstra (Intel),
Nick Desaulniers, linux-kernel, clang-built-linux, Andrew Murray,
Nathan Chancellor, Thomas Gleixner, linux-arm-kernel
On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined
when CONFIG_OPTIMIZE_INLINING is set.
Clang then fails a compile-time assertion, because it cannot tell at
compile time what the size of the argument is:
mm/memcontrol.o: In function `__cmpxchg_mb':
memcontrol.c:(.text+0x1a4c): undefined reference to `__compiletime_assert_175'
memcontrol.c:(.text+0x1a4c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__compiletime_assert_175'
Mark all of the cmpxchg() style functions as __always_inline to
ensure that the compiler can see the result.
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/648
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Tested-by: Andrew Murray <andrew.murray@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: skip unneeded changes, as suggested by Andrew Murray
---
arch/arm64/include/asm/cmpxchg.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
index a1398f2f9994..f9bef42c1411 100644
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -62,7 +62,7 @@ __XCHG_CASE( , , mb_, 64, dmb ish, nop, , a, l, "memory")
#undef __XCHG_CASE
#define __XCHG_GEN(sfx) \
-static inline unsigned long __xchg##sfx(unsigned long x, \
+static __always_inline unsigned long __xchg##sfx(unsigned long x, \
volatile void *ptr, \
int size) \
{ \
@@ -148,7 +148,7 @@ __CMPXCHG_DBL(_mb)
#undef __CMPXCHG_DBL
#define __CMPXCHG_GEN(sfx) \
-static inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
+static __always_inline unsigned long __cmpxchg##sfx(volatile void *ptr, \
unsigned long old, \
unsigned long new, \
int size) \
@@ -255,7 +255,7 @@ __CMPWAIT_CASE( , , 64);
#undef __CMPWAIT_CASE
#define __CMPWAIT_GEN(sfx) \
-static inline void __cmpwait##sfx(volatile void *ptr, \
+static __always_inline void __cmpwait##sfx(volatile void *ptr, \
unsigned long val, \
int size) \
{ \
--
2.20.0
_______________________________________________
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] reset: uniphier-glue: Add Pro5 USB3 support
From: Philipp Zabel @ 2019-09-10 11:59 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Mark Rutland, devicetree, Masami Hiramatsu, Jassi Brar,
linux-kernel, Masahiro Yamada, Rob Herring, linux-arm-kernel
In-Reply-To: <20190910205640.6ABD.4A936039@socionext.com>
Hi Kunihiko,
On Tue, 2019-09-10 at 20:56 +0900, Kunihiko Hayashi wrote:
[...]
> This driver is derived from reset-simple, so the method to control reset
> in the glue block is the same for each SoC.
>
> And both Pro4 and Pro5 need same parent clock and reset, so the data for
> these SoCs refer same parent clock names and parent reset names.
>
> However, since the glue block itself can be different, I think that
> compatible string should be distinguished for each SoC.
Ok, in that case I'll apply the patch as-is. Thank you for clarifying.
regards
Philipp
_______________________________________________
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 v9 1/8] mm: Add per-cpu logic to page shuffling
From: Michal Hocko @ 2019-09-10 12:11 UTC (permalink / raw)
To: Alexander Duyck
Cc: yang.zhang.wz, pagupta, kvm, mst, catalin.marinas,
Alexander Duyck, lcapitulino, linux-mm, will, aarcange,
virtio-dev, David Hildenbrand, willy, wei.w.wang, ying.huang,
riel, dan.j.williams, linux-arm-kernel, osalvador, nitesh,
konrad.wilk, dave.hansen, linux-kernel, pbonzini, akpm,
fengguang.wu, kirill.shutemov
In-Reply-To: <0ca58fea280b51b83e7b42e2087128789bc9448d.camel@linux.intel.com>
On Mon 09-09-19 08:11:36, Alexander Duyck wrote:
> On Mon, 2019-09-09 at 10:14 +0200, David Hildenbrand wrote:
> > On 07.09.19 19:25, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > >
> > > Change the logic used to generate randomness in the suffle path so that we
> > > can avoid cache line bouncing. The previous logic was sharing the offset
> > > and entropy word between all CPUs. As such this can result in cache line
> > > bouncing and will ultimately hurt performance when enabled.
> >
> > So, usually we perform such changes if there is real evidence. Do you
> > have any such performance numbers to back your claims?
>
> I'll have to go rerun the test to get the exact numbers. The reason this
> came up is that my original test was spanning NUMA nodes and that made
> this more expensive as a result since the memory was both not local to the
> CPU and was being updated by multiple sockets.
What was the pattern of page freeing in your testing? I am wondering
because order 0 pages should be prevailing and those usually go via pcp
lists so they do not get shuffled unless the batch is full IIRC.
--
Michal Hocko
SUSE Labs
_______________________________________________
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 v9 2/8] mm: Adjust shuffle code to allow for future coalescing
From: Michal Hocko @ 2019-09-10 12:20 UTC (permalink / raw)
To: Alexander Duyck
Cc: yang.zhang.wz, pagupta, kvm, david, catalin.marinas, lcapitulino,
linux-mm, alexander.h.duyck, will, aarcange, virtio-dev, mst,
willy, wei.w.wang, ying.huang, riel, konrad.wilk, dan.j.williams,
linux-arm-kernel, osalvador, nitesh, dave.hansen, linux-kernel,
pbonzini, akpm, fengguang.wu, kirill.shutemov
In-Reply-To: <20190907172520.10910.83100.stgit@localhost.localdomain>
On Sat 07-09-19 10:25:20, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> Move the head/tail adding logic out of the shuffle code and into the
> __free_one_page function since ultimately that is where it is really
> needed anyway. By doing this we should be able to reduce the overhead
> and can consolidate all of the list addition bits in one spot.
This changelog doesn't really explain why we want this. You are
reshuffling the code, allright, but why do we want to reshuffle? Is the
result readability a better code reuse or something else? Where
does the claimed reduced overhead coming from?
From a quick look buddy_merge_likely looks nicer than the code splat
we have. Good.
But then
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
[...]
> - if (is_shuffle_order(order))
> - add_to_free_area_random(page, &zone->free_area[order],
> - migratetype);
> + area = &zone->free_area[order];
> + if (is_shuffle_order(order) ? shuffle_pick_tail() :
> + buddy_merge_likely(pfn, buddy_pfn, page, order))
Ouch this is just awful don't you think?
--
Michal Hocko
SUSE Labs
_______________________________________________
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