* Re: [PATCH V4 5/6] arm64: mm: introduce 52-bit userspace support
From: Steve Capper @ 2018-12-06 12:26 UTC (permalink / raw)
To: Suzuki Poulose
Cc: ard.biesheuvel@linaro.org, jcm@redhat.com, Will Deacon,
linux-mm@kvack.org, Catalin Marinas, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <e1a9b147-d635-9f32-2f33-ccd689dba858@arm.com>
On Wed, Dec 05, 2018 at 06:22:27PM +0000, Suzuki K Poulose wrote:
> Hi Steve,
>
[...]
> I think we may need a check for the secondary CPUs to make sure that they have
> the 52bit support once the boot CPU has decided to use the feature and fail the
> CPU bring up (just like we do for the granule support).
>
> Suzuki
Hi Suzuki,
I have just written a patch to detect a mismatch between 52-bit VA that
is being tested now.
As 52-bit kernel VA support is coming in future, the patch checks for a
mismatch during the secondary boot path and, if one is found, prevents
the secondary from booting (and displays an error message to the user).
Cheers,
--
Steve
_______________________________________________
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 00/25] at24: remove
From: Sekhar Nori @ 2018-12-06 12:33 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Russell King, Arnd Bergmann,
Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger, Nicolas Ferre,
David S . Miller, Srinivas Kandagatla, Andrew Lunn,
Florian Fainelli, Rob Herring, Frank Rowand, Wolfram Sang
Cc: devicetree, netdev, linux-kernel, Bartosz Golaszewski, linux-mtd,
linux-i2c, linux-omap, linux-arm-kernel
In-Reply-To: <20181113140133.17385-1-brgl@bgdev.pl>
On 13/11/18 7:31 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Now that nvmem has gained support for defining cells from board files and
> looking them up from relevant drivers[1], it's time for a respin of the
> previous series[2] that aims at removing struct at24_platform_data from
> the tree.
>
> Since I took over maintainership of the at24 driver I've been working
> towards removing at24_platform_data in favor for device properties.
>
> DaVinci is the only platform that's still using it - all other users
> have already been converted.
>
> One of the obstacles in case of DaVinci is removing the setup() callback
> from the pdata struct, the only user of which are some davinci boards.
>
> First we add support for nvmem to MTD in a way previously discussed with
> Boris Brezillon and Srinivas Kandagatla.
>
> Then, since most boards use the EEPROM to store the MAC address, we register
> relevant cells for all users, implement a function that allows to read
> the MAC address from nvmem (and also replaces the previous DT-specific
> variant) and make davinci_emac aware of it.
>
> Next we switch all davinci users to using at24 device properties instead
> of platform data. While we're at it: we remove all other traces of the
> setup callback and platform data from davinci.
>
> Finally we remove the at24 platform data structure.
>
> I kept the review tags in patches that haven't changed from the last
> submission.
>
> As far as merging of this series goes: I'd like to avoid dragging it over
> four releases. The series is logically split into five groups:
>
> patches 1-2: nvmem and mtd changes
> patches 3-9: davinci arch-specific changes
Applied patches 3-9 to davinci tree for v4.21
> patches 10-13: networking changes
> patches 14-24: davinci specific again
> patch 25: final at24 change
>
> With that I believe we can do the following: Greg KH could pick up the
> first two patches into his char-misc tree. Sekhar would take the second
> group and the third would go through the networking tree since the first
> three sets are not linked in any way. This would be merged for 4.21. Then
> for the next release Sekhar would pick up 14-24, provide an immutable
> branch for me and I'd merge the final patch for at24 and send it upstream
> through Wolfram's i2c tree (maybe we could even delay the i2c PR in the
> merge window to avoid the immutable branch altogether).
>
> [1] https://lkml.org/lkml/2018/9/21/293
> [2] https://lkml.org/lkml/2018/8/8/528
Thanks,
Sekhar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 1/8] arm64: add type casts to untagged_addr macro
From: Andrey Konovalov @ 2018-12-06 12:34 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION, Will Deacon,
Kostya Serebryany, open list:KERNEL SELFTEST FRAMEWORK,
Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
Jacob Bramley, Dmitry Vyukov, Evgenii Stepanov, Kees Cook,
Ruben Ayrapetyan, Ramana Radhakrishnan, Linux ARM,
Linux Memory Management List, Greg Kroah-Hartman, LKML,
Luc Van Oostenryck, Lee Smith, Andrew Morton, Robin Murphy,
Kirill A. Shutemov
In-Reply-To: <20181129182218.GH22027@arrakis.emea.arm.com>
On Thu, Nov 29, 2018 at 7:22 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Thu, Nov 08, 2018 at 03:36:08PM +0100, Andrey Konovalov wrote:
> > This patch makes the untagged_addr macro accept all kinds of address types
> > (void *, unsigned long, etc.) and allows not to specify type casts in each
> > place where it is used. This is done by using __typeof__.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> > arch/arm64/include/asm/uaccess.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 07c34087bd5e..c1325271e368 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -101,7 +101,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
> > * up with a tagged userland pointer. Clear the tag to get a sane pointer to
> > * pass on to access_ok(), for instance.
> > */
> > -#define untagged_addr(addr) sign_extend64(addr, 55)
> > +#define untagged_addr(addr) \
> > + ((__typeof__(addr))sign_extend64((__u64)(addr), 55))
>
> Nitpick: same comment as here (use u64):
>
> http://lkml.kernel.org/r/20181123173739.osgvnnhmptdgtlnl@lakrids.cambridge.arm.com
Will do in v9.
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> (not acking the whole series just yet, only specific patches to remember
> what I reviewed)
OK.
Thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 2/8] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2018-12-06 12:36 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION, Will Deacon,
Kostya Serebryany, open list:KERNEL SELFTEST FRAMEWORK,
Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
Jacob Bramley, Dmitry Vyukov, Evgenii Stepanov, Kees Cook,
Ruben Ayrapetyan, Ramana Radhakrishnan, Linux ARM,
Linux Memory Management List, Greg Kroah-Hartman, LKML,
Luc Van Oostenryck, Lee Smith, Andrew Morton, Robin Murphy,
Kirill A. Shutemov
In-Reply-To: <20181129182323.GI22027@arrakis.emea.arm.com>
On Thu, Nov 29, 2018 at 7:23 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Thu, Nov 08, 2018 at 03:36:09PM +0100, Andrey Konovalov wrote:
> > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> > index efe79c1cdd47..c045b4eff95e 100644
> > --- a/include/linux/uaccess.h
> > +++ b/include/linux/uaccess.h
> > @@ -13,6 +13,10 @@
> >
> > #include <asm/uaccess.h>
> >
> > +#ifndef untagged_addr
> > +#define untagged_addr(addr) addr
> > +#endif
>
> Nitpick: add braces around (addr). Otherwise:
Will do in v9, thanks!
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
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 6/6] arm64: mm: Allow forcing all userspace addresses to 52-bit
From: Steve Capper @ 2018-12-06 12:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: ard.biesheuvel@linaro.org, jcm@redhat.com, Will Deacon,
linux-mm@kvack.org, nd, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181206115132.GD54495@arrakis.emea.arm.com>
On Thu, Dec 06, 2018 at 11:51:33AM +0000, Catalin Marinas wrote:
> On Wed, Dec 05, 2018 at 04:41:45PM +0000, Steve Capper wrote:
> > On arm64 52-bit VAs are provided to userspace when a hint is supplied to
> > mmap. This helps maintain compatibility with software that expects at
> > most 48-bit VAs to be returned.
> >
> > In order to help identify software that has 48-bit VA assumptions, this
> > patch allows one to compile a kernel where 52-bit VAs are returned by
> > default on HW that supports it.
> >
> > This feature is intended to be for development systems only.
> >
> > Signed-off-by: Steve Capper <steve.capper@arm.com>
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks Catalin.
_______________________________________________
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 v12 20/25] kasan, arm64: add brk handler for inline instrumentation
From: Andrey Konovalov @ 2018-12-06 12:25 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION,
Catalin Marinas, Paul Lawrence, Linux Memory Management List,
Alexander Potapenko, Chintan Pandya, Christoph Lameter,
Ingo Molnar, Jacob Bramley, Ruben Ayrapetyan, Mark Brand,
kasan-dev, linux-sparse, Geert Uytterhoeven, Linux ARM,
Andrey Ryabinin, Dave Martin, Evgenii Stepanov, Vishwath Mohan,
Arnd Bergmann, Linux Kbuild mailing list, Marc Zyngier,
Ramana Radhakrishnan, Mike Rapoport, Dmitry Vyukov,
Kostya Serebryany, Jann Horn, Ard Biesheuvel, Greg Kroah-Hartman,
Nick Desaulniers, LKML, Eric W . Biederman, Lee Smith,
Andrew Morton, Kirill A. Shutemov
In-Reply-To: <20181206111107.GE23697@arm.com>
On Thu, Dec 6, 2018 at 12:10 PM Will Deacon <will.deacon@arm.com> wrote:
>
> On Thu, Dec 06, 2018 at 11:31:43AM +0100, Andrey Konovalov wrote:
> > On Thu, Nov 29, 2018 at 7:01 PM Will Deacon <will.deacon@arm.com> wrote:
> > >
> > > On Tue, Nov 27, 2018 at 05:55:38PM +0100, Andrey Konovalov wrote:
> > > > Tag-based KASAN inline instrumentation mode (which embeds checks of shadow
> > > > memory into the generated code, instead of inserting a callback) generates
> > > > a brk instruction when a tag mismatch is detected.
> > > >
> > > > This commit adds a tag-based KASAN specific brk handler, that decodes the
> > > > immediate value passed to the brk instructions (to extract information
> > > > about the memory access that triggered the mismatch), reads the register
> > > > values (x0 contains the guilty address) and reports the bug.
> > > >
> > > > Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
> > > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > > > ---
> > > > arch/arm64/include/asm/brk-imm.h | 2 +
> > > > arch/arm64/kernel/traps.c | 68 +++++++++++++++++++++++++++++++-
> > > > include/linux/kasan.h | 3 ++
> > > > 3 files changed, 71 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h
> > > > index ed693c5bcec0..2945fe6cd863 100644
> > > > --- a/arch/arm64/include/asm/brk-imm.h
> > > > +++ b/arch/arm64/include/asm/brk-imm.h
> > > > @@ -16,10 +16,12 @@
> > > > * 0x400: for dynamic BRK instruction
> > > > * 0x401: for compile time BRK instruction
> > > > * 0x800: kernel-mode BUG() and WARN() traps
> > > > + * 0x9xx: tag-based KASAN trap (allowed values 0x900 - 0x9ff)
> > > > */
> > > > #define FAULT_BRK_IMM 0x100
> > > > #define KGDB_DYN_DBG_BRK_IMM 0x400
> > > > #define KGDB_COMPILED_DBG_BRK_IMM 0x401
> > > > #define BUG_BRK_IMM 0x800
> > > > +#define KASAN_BRK_IMM 0x900
> > > >
> > > > #endif
> > > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > > > index 5f4d9acb32f5..04bdc53716ef 100644
> > > > --- a/arch/arm64/kernel/traps.c
> > > > +++ b/arch/arm64/kernel/traps.c
> > > > @@ -35,6 +35,7 @@
> > > > #include <linux/sizes.h>
> > > > #include <linux/syscalls.h>
> > > > #include <linux/mm_types.h>
> > > > +#include <linux/kasan.h>
> > > >
> > > > #include <asm/atomic.h>
> > > > #include <asm/bug.h>
> > > > @@ -284,10 +285,14 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
> > > > }
> > > > }
> > > >
> > > > -void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > > > +void __arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > > > {
> > > > regs->pc += size;
> > > > +}
> > > >
> > > > +void arm64_skip_faulting_instruction(struct pt_regs *regs, unsigned long size)
> > > > +{
> > > > + __arm64_skip_faulting_instruction(regs, size);
> > > > /*
> > > > * If we were single stepping, we want to get the step exception after
> > > > * we return from the trap.
> > > > @@ -959,7 +964,7 @@ static int bug_handler(struct pt_regs *regs, unsigned int esr)
> > > > }
> > > >
> > > > /* If thread survives, skip over the BUG instruction and continue: */
> > > > - arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
> > > > + __arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
> > >
> > > Why do you want to avoid the single-step logic here? Given that we're
> > > skipping over the brk instruction, why wouldn't you want that to trigger
> > > a step exception if single-step is enabled?
> >
> > I was asked to do that, see the discussion here:
> >
> > https://www.spinics.net/lists/linux-mm/msg146575.html
> > https://www.spinics.net/lists/linux-mm/msg148215.html
> > https://www.spinics.net/lists/linux-mm/msg148367.html
>
> Aha, but we subsequently fixed the underlying problem in commit
> 9478f1927e6e ("arm64: only advance singlestep for user instruction traps").
> You were on cc, but I appreciate it's not clear that it was related to this.
Sorry, missed that patch.
> Anyway, you can just call arm64_skip_faulting_instruction() as you were
> doing and there's no need for this refactoring.
>
> Please could you spin a new version so that akpm can replace the one which
> he has queued?
Done. Thanks!
_______________________________________________
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/2] clk: Add comment about __of_clk_get_by_name() error values
From: Phil Edworthy @ 2018-12-06 12:30 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Stephen Boyd, Michael Turquette, Russell King,
linux-kernel@vger.kernel.org, Geert Uytterhoeven,
Uwe Kleine-König, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181203133040.GN10650@smile.fi.intel.com>
Hi Andy,
On 03 December 2018 13:31 Andy Shevchenko wrote:
> On Mon, Dec 03, 2018 at 11:13:08AM +0000, Phil Edworthy wrote:
> > It's not immediately obvious from the code that failure to get a clock
> > provider can return either -ENOENT or -EINVAL. Therefore, add a
> > comment to highlight this.
>
> > +/*
> > + * Beware the return values when np is valid, but no clock provider is
> found.
> > + * If name = NULL, the function returns -ENOENT.
> > + * If name != NULL, the function returns -EINVAL. This is because
> > +__of_clk_get()
>
> I would start new sentence from new line (this will emphasize the possible
> variants)
>
> * This is ...
I disagree, the explanation is specifically related to the case where the function
returns -EINVAL. Though this is a nit, so I'm not really bothered either way.
Thanks for the review!
Phil
> Otherwise looks good to me:
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> > + * is called even if of_property_match_string() returns an error.
> > + */
> > static struct clk *__of_clk_get_by_name(struct device_node *np,
> > const char *dev_id,
> > const char *name)
> > --
> > 2.17.1
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
_______________________________________________
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 4/6] arm64: mm: Offset TTBR1 to allow 52-bit PTRS_PER_PGD
From: Steve Capper @ 2018-12-06 12:27 UTC (permalink / raw)
To: Catalin Marinas
Cc: ard.biesheuvel@linaro.org, jcm@redhat.com, Will Deacon,
linux-mm@kvack.org, nd, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181206115011.GC54495@arrakis.emea.arm.com>
On Thu, Dec 06, 2018 at 11:50:12AM +0000, Catalin Marinas wrote:
> On Wed, Dec 05, 2018 at 04:41:43PM +0000, Steve Capper wrote:
> > diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h
> > index 4128bec033f6..cd361dd16b12 100644
> > --- a/arch/arm64/include/asm/asm-uaccess.h
> > +++ b/arch/arm64/include/asm/asm-uaccess.h
> > @@ -14,11 +14,13 @@
> > #ifdef CONFIG_ARM64_SW_TTBR0_PAN
> > .macro __uaccess_ttbr0_disable, tmp1
> > mrs \tmp1, ttbr1_el1 // swapper_pg_dir
> > + restore_ttbr1 \tmp1
> > bic \tmp1, \tmp1, #TTBR_ASID_MASK
> > sub \tmp1, \tmp1, #RESERVED_TTBR0_SIZE // reserved_ttbr0 just before swapper_pg_dir
> > msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1
> > isb
> > add \tmp1, \tmp1, #RESERVED_TTBR0_SIZE
> > + offset_ttbr1 \tmp1
> > msr ttbr1_el1, \tmp1 // set reserved ASID
> > isb
> > .endm
> > @@ -27,8 +29,10 @@
> > get_thread_info \tmp1
> > ldr \tmp1, [\tmp1, #TSK_TI_TTBR0] // load saved TTBR0_EL1
> > mrs \tmp2, ttbr1_el1
> > + restore_ttbr1 \tmp2
> > extr \tmp2, \tmp2, \tmp1, #48
> > ror \tmp2, \tmp2, #16
> > + offset_ttbr1 \tmp2
> > msr ttbr1_el1, \tmp2 // set the active ASID
> > isb
> > msr ttbr0_el1, \tmp1 // set the non-PAN TTBR0_EL1
>
> The patch looks alright but I think we can simplify it further if we add:
>
> depends on ARM64_PAN || !ARM64_SW_TTBR0_PAN
>
> to the 52-bit Kconfig entry.
Ahh, thank you okay, I didn't make the connection that Privileged access
never was a mandatory feature in ARMv8.1.
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Russell King - ARM Linux @ 2018-12-06 12:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPdUFfOXqMkgdv4fjhpbrmjNmw_f9cMj03a2h65snNJ4qw@mail.gmail.com>
On Thu, Dec 06, 2018 at 11:24:27AM +0100, Krzysztof Kozlowski wrote:
> On Thu, 6 Dec 2018 at 11:01, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > I've no idea based on what you've supplied given that the SoC
> > maintainers are responsible for writing the code to deal with hotplug
> > etc, and Exynos's code there is something of a maze. It's not clear
> > which bits are being used. I think you at the very least need to debug
> > to find out whether the problem is at CPU down or CPU up.
> >
> > From the ARM architecture point of view, for Cortex A9, all the
> > processor function instances should be identical. The only difference
> > as a result of the patch is that we'll be calling smp_processor_id()
> > early (which should be fine), and indirecting through the cpu_vtable[]
> > array rather than merely dereferencing the processor struct.
> >
> > What about checking dmesg - messages from offline CPUs do not appear
> > on the console(s) but are still logged in the kernel log.
> >
> > You could try making PROC_VTABLE() the same as PROC_TABLE() (iow,
> > always access cpu_vtable[0]) to see whether it's the smp_processor_id()
> > that's causing your problem or not. If it is, then try and work out
> > which of the processor functions is causing it by restoring
> > PROC_VTABLE() and then switching each from PROC_VTABLE() to
> > PROC_TABLE() until it does work.
>
> Thanks for hints!
So I can plan, how long do you think it will take to get some results
from my suggestions above?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Emiliano Ingrassia @ 2018-12-06 12:43 UTC (permalink / raw)
To: Martin Blumenstingl, Carlo Caione
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <CAFBinCDCE7RP4vgs25bqSZ8vBjrmcuB=qb3U92X6QfpmzeqrBg@mail.gmail.com>
Hi all,
thank you for involving me.
I applied Carlo's patches[0] on a kernel vanilla 4.19.6
and tested it with kernel packet generator, monitoring
bandwidth usage with "nload".
All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
with a short ethernet cable directly attached to a laptop with
1G ethernet interface, with "nload" running on the board.
The tests I performed are composed by the following steps:
1) Start packet generator with "rate 1000M" on laptop;
2) Keep packet generator active on the laptop and
start the packet generator on the board with "rate 1000M";
3) Stop both packet generators;
4) Start packet generator on the board;
5) Keep packet generator active on the board and
start the packet generator on the laptop.
Test results without Carlo's patches applied:
1) "nload" shows an incoming traffic of ~950Mbps;
2) "nload" shows an incoming traffic of ~400Mbps
and an outgoing traffic of ~250Mbps;
3) "nload" shows 0Mbps both for incoming and outgoing traffic;
4) "nload" shows an outgoing traffic of ~950Mbps from the board;
5) "nload" shows incoming traffic of 0Mbps
and an outgoing traffic of ~950Mbps.
Applying only the first patch (change mac IRQ type) I got the same results.
Applying only the second patch (drop eee-broken-1000t) I got the same results!
With both patches applied I got the same results but with an incoming traffic
of ~3Mbps on the board.
Consider that the described tests were performed for a few minutes.
The tests I performed clearly show that currently the MAC does not
perform as 1G full-duplex.
I can't say if this depends on the hardware, the driver or
the IP description in the board's device tree.
From the results shown above I think that the patches regarding 32 bit
Meson SoCs should NOT be applied together, but you can consider to apply
only the second one which remove the "eee-broken-1000t" flag
from the board MAC IP description.
In particular, I think that more tests are needed to better understand
what's happening in the case of Meson8b SoC.
To better investigate the MAC behaviour on Odroid-C1+, should I use
the Amlogic development kernel[1]? If yes, what branch should I use?
On Tue, Dec 04, 2018 at 08:59:20PM +0100, Martin Blumenstingl wrote:
> adding Emiliano because he experienced high packet loss on Odroid-C1
> without "eee-broken-1000t"
>
> On Tue, Dec 4, 2018 at 5:05 PM Carlo Caione <ccaione@baylibre.com> wrote:
> >
> > The wrong IRQ trigger type for the macirq was causing the connection
> > speed to drop after a few hours when stress testing the DUT. The fix
> > seems also to fix another long standing issue with EEE.
Carlo, can you describe precisely the tests you conducted
on your board and the tools used?
> the other two DesignWare controllers (2x dwc2) are also using
> IRQ_TYPE_LEVEL_HIGH
> so this is not unlikely - good job detective!
>
Consider that currently the USB ports do not work correctly.
In particular, USB pendrive insertion is not recognized at runtime.
> > The fixes are tested on a AXG board but we think that the same fix is
> > valid also for all the others Amlogic SoC families.
> I checked Amlogic's 3.10 kernel for the 32-bit SoCs and it seems they
> are setting all IRQs to be edge triggered: [0]
> however, Emiliano reported an issue with IRQ_TYPE_EDGE_RISING for the
> dwc2 controllers as well. 291f45dd6da5fa6 "ARM: dts: meson: fixing USB
> support on Meson6, Meson8 and Meson8b" fixed it for him whereas it
> worked for me with IRQ_TYPE_EDGE_RISING
>
> I find it strange though that Amlogic's buildroot kernel (even the
> latest buildroot_openlinux_kernel_4.9_fbdev_20180706) uses:
> interrupts = <0 8 1>
> which translates to:
> interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>
>
> does the datasheet give a hint that this IRQ should be level triggered
> or did you find out by trial and error?
>
> > Carlo Caione (2):
> > arm64: dts: meson: Fix IRQ trigger type for macirq
> > arm64: dts: meson: Remove eee-broken-1000t quirk
> >
> > arch/arm/boot/dts/meson.dtsi | 2 +-
> > arch/arm/boot/dts/meson8b-odroidc1.dts | 1 -
> these two should be in separate patches with "ARM: dts: " as prefix
>
> > arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 1 -
> > arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 2 +-
> > arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
> > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 -
> > arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi | 1 -
> > 7 files changed, 3 insertions(+), 7 deletions(-)
> >
> > --
> > 2.19.1
> >
>
> Regards
> Martin
>
> [0] https://github.com/endlessm/linux-meson/blob/cd4096c3ff4eb5b8a8a5581bb46508601c5470dc/drivers/irqchip/irq-gic.c#L400
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
Best regards,
Emiliano
[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009325.html
[1] https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/8] arm64: untag user pointers passed to the kernel
From: Andrey Konovalov @ 2018-12-06 12:44 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION, Will Deacon,
Linux Memory Management List, open list:KERNEL SELFTEST FRAMEWORK,
Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
Jacob Bramley, Dmitry Vyukov, Evgenii Stepanov, Kees Cook,
Ruben Ayrapetyan, Ramana Radhakrishnan, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, LKML, Kirill A. Shutemov,
Lee Smith, Andrew Morton, Robin Murphy, Luc Van Oostenryck
In-Reply-To: <20181129181650.GG22027@arrakis.emea.arm.com>
On Thu, Nov 29, 2018 at 7:16 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Hi Andrey,
>
> On Thu, Nov 08, 2018 at 03:48:10PM +0100, Andrey Konovalov wrote:
> > On Thu, Nov 8, 2018 at 3:36 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > > Changes in v8:
> > > - Rebased onto 65102238 (4.20-rc1).
> > > - Added a note to the cover letter on why syscall wrappers/shims that untag
> > > user pointers won't work.
> > > - Added a note to the cover letter that this patchset has been merged into
> > > the Pixel 2 kernel tree.
> > > - Documentation fixes, in particular added a list of syscalls that don't
> > > support tagged user pointers.
> >
> > I've changed the documentation to be more specific, please take a look.
> >
> > I haven't done anything about adding a way for the user to find out
> > that the kernel supports this ABI extension. I don't know what would
> > the the preferred way to do this, and we haven't received any comments
> > on that from anybody else. Probing "on some innocuous syscall
> > currently returning -EFAULT on tagged pointer arguments" works though,
> > as you mentioned.
>
> We've had some internal discussions and also talked to some people at
> Plumbers. I think the best option is to introduce an AT_FLAGS bit to
> describe the ABI relaxation on tagged pointers. Vincenzo is going to
> propose a patch on top of this series.
So should I wait for a patch from Vincenzo before posting v9 or post
it as is? Or try to develop this patch myself?
>
> > As mentioned in the cover letter, this patchset has been merged into
> > the Pixel 2 kernel tree.
>
> I just hope it's not enabled on production kernels, it would introduce
> a user ABI that may differ from what ends up upstream.
>
> --
> Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [shawnguo:imx/soc 2/2] arch/arm/Kconfig.debug:1445: syntax error
From: kbuild test robot @ 2018-12-06 12:44 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Shawn Guo, kbuild-all, linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git imx/soc
head: 911dccedb00e5b45cf2d0fafc21aba233b58e115
commit: 911dccedb00e5b45cf2d0fafc21aba233b58e115 [2/2] ARM: debug-imx: only define DEBUG_IMX_UART_PORT if needed
config: arm-hackkit_defconfig
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 911dccedb00e5b45cf2d0fafc21aba233b58e115
GCC_VERSION=7.2.0 make.cross ARCH=arm hackkit_defconfig
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> arch/arm/Kconfig.debug:1445: syntax error
>> arch/arm/Kconfig.debug:1444: invalid option
arch/arm/Kconfig.debug:1445:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1445:warning: ignoring unsupported character '|'
>> lib/Kconfig.debug:1: missing end statement for this entry
>> arch/arm/Kconfig.debug:1445: invalid statement
arch/arm/Kconfig.debug:1446:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1446:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1446: invalid statement
arch/arm/Kconfig.debug:1447:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1447:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1447: invalid statement
arch/arm/Kconfig.debug:1448:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1448:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1448: invalid statement
arch/arm/Kconfig.debug:1449:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1449:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1449: invalid statement
arch/arm/Kconfig.debug:1450:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1450:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1450: invalid statement
arch/arm/Kconfig.debug:1451:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1451:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1451: invalid statement
arch/arm/Kconfig.debug:1452:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1452:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1452: invalid statement
arch/arm/Kconfig.debug:1453:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1453:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1453: invalid statement
arch/arm/Kconfig.debug:1454:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1454:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1454: invalid statement
arch/arm/Kconfig.debug:1455:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1455:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1455: invalid statement
arch/arm/Kconfig.debug:1456: invalid statement
>> arch/arm/Kconfig.debug:1457: unexpected option "default"
arch/arm/Kconfig.debug:1458: invalid statement
arch/arm/Kconfig.debug:1459: invalid statement
arch/arm/Kconfig.debug:1460:warning: ignoring unsupported character '.'
arch/arm/Kconfig.debug:1460: invalid statement
>> lib/Kconfig.debug:2049: unexpected end statement
make[2]: *** [hackkit_defconfig] Error 1
make[1]: *** [hackkit_defconfig] Error 2
make: *** [sub-make] Error 2
--
>> arch/arm/Kconfig.debug:1445: syntax error
>> arch/arm/Kconfig.debug:1444: invalid option
arch/arm/Kconfig.debug:1445:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1445:warning: ignoring unsupported character '|'
>> lib/Kconfig.debug:1: missing end statement for this entry
>> arch/arm/Kconfig.debug:1445: invalid statement
arch/arm/Kconfig.debug:1446:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1446:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1446: invalid statement
arch/arm/Kconfig.debug:1447:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1447:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1447: invalid statement
arch/arm/Kconfig.debug:1448:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1448:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1448: invalid statement
arch/arm/Kconfig.debug:1449:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1449:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1449: invalid statement
arch/arm/Kconfig.debug:1450:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1450:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1450: invalid statement
arch/arm/Kconfig.debug:1451:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1451:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1451: invalid statement
arch/arm/Kconfig.debug:1452:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1452:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1452: invalid statement
arch/arm/Kconfig.debug:1453:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1453:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1453: invalid statement
arch/arm/Kconfig.debug:1454:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1454:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1454: invalid statement
arch/arm/Kconfig.debug:1455:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1455:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1455: invalid statement
arch/arm/Kconfig.debug:1456: invalid statement
>> arch/arm/Kconfig.debug:1457: unexpected option "default"
arch/arm/Kconfig.debug:1458: invalid statement
arch/arm/Kconfig.debug:1459: invalid statement
arch/arm/Kconfig.debug:1460:warning: ignoring unsupported character '.'
arch/arm/Kconfig.debug:1460: invalid statement
>> lib/Kconfig.debug:2049: unexpected end statement
make[2]: *** [oldconfig] Error 1
make[1]: *** [oldconfig] Error 2
make: *** [sub-make] Error 2
--
>> arch/arm/Kconfig.debug:1445: syntax error
>> arch/arm/Kconfig.debug:1444: invalid option
arch/arm/Kconfig.debug:1445:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1445:warning: ignoring unsupported character '|'
>> lib/Kconfig.debug:1: missing end statement for this entry
>> arch/arm/Kconfig.debug:1445: invalid statement
arch/arm/Kconfig.debug:1446:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1446:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1446: invalid statement
arch/arm/Kconfig.debug:1447:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1447:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1447: invalid statement
arch/arm/Kconfig.debug:1448:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1448:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1448: invalid statement
arch/arm/Kconfig.debug:1449:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1449:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1449: invalid statement
arch/arm/Kconfig.debug:1450:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1450:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1450: invalid statement
arch/arm/Kconfig.debug:1451:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1451:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1451: invalid statement
arch/arm/Kconfig.debug:1452:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1452:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1452: invalid statement
arch/arm/Kconfig.debug:1453:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1453:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1453: invalid statement
arch/arm/Kconfig.debug:1454:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1454:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1454: invalid statement
arch/arm/Kconfig.debug:1455:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1455:warning: ignoring unsupported character '|'
arch/arm/Kconfig.debug:1455: invalid statement
arch/arm/Kconfig.debug:1456: invalid statement
>> arch/arm/Kconfig.debug:1457: unexpected option "default"
arch/arm/Kconfig.debug:1458: invalid statement
arch/arm/Kconfig.debug:1459: invalid statement
arch/arm/Kconfig.debug:1460:warning: ignoring unsupported character '.'
arch/arm/Kconfig.debug:1460: invalid statement
>> lib/Kconfig.debug:2049: unexpected end statement
make[2]: *** [olddefconfig] Error 1
make[1]: *** [olddefconfig] Error 2
make: *** [sub-make] Error 2
vim +1445 arch/arm/Kconfig.debug
1417
1418 config DEBUG_AT91_UART
1419 bool
1420 depends on ARCH_AT91
1421
1422 config DEBUG_EXYNOS_UART
1423 bool
1424
1425 config DEBUG_S3C2410_UART
1426 bool
1427 select DEBUG_S3C24XX_UART
1428
1429 config DEBUG_S3C24XX_UART
1430 bool
1431
1432 config DEBUG_S3C64XX_UART
1433 bool
1434
1435 config DEBUG_S5PV210_UART
1436 bool
1437
1438 config DEBUG_OMAP2PLUS_UART
1439 bool
1440 depends on ARCH_OMAP2PLUS
1441
1442 config DEBUG_IMX_UART_PORT
1443 int "i.MX Debug UART Port Selection"
> 1444 depends on DEBUG_IMX1_UART ||
> 1445 DEBUG_IMX25_UART ||
1446 DEBUG_IMX21_IMX27_UART ||
1447 DEBUG_IMX31_UART ||
1448 DEBUG_IMX35_UART ||
1449 DEBUG_IMX50_UART ||
1450 DEBUG_IMX51_UART ||
1451 DEBUG_IMX53_UART ||
1452 DEBUG_IMX6Q_UART ||
> 1453 DEBUG_IMX6SL_UART ||
1454 DEBUG_IMX6SX_UART ||
1455 DEBUG_IMX6UL_UART ||
1456 DEBUG_IMX7D_UART
> 1457 default 1
1458 help
1459 Choose UART port on which kernel low-level debug messages
1460 should be output.
1461
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
_______________________________________________
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 1/2] arm64: dts: rockchip: rockpro64 fix regulator gpios
From: Heiko Stuebner @ 2018-12-06 12:48 UTC (permalink / raw)
To: Oskari Lemmela
Cc: Mark Rutland, devicetree, Akash Gajjar, linux-kernel,
linux-rockchip, Rob Herring, linux-arm-kernel
In-Reply-To: <20181201100817.20688-2-oskari@lemmela.net>
Am Samstag, 1. Dezember 2018, 11:08:16 CET schrieb Oskari Lemmela:
> Rockpro64 is not able boot if GPIO1_C1 pin is pulled high
> before loading linux kernel.
>
> In rockpro64 GPIO1_C1 pin is connected vdd_cpu_b regulator
> VSEL pin. Pin should be pulled down in normal operation and
> pulled high in suspend.
>
> PMIC LDO_REG2 is connected to touch panel connector.
> Rename regulator and set it to correct voltage.
>
> PCIe power is controller by GPIO1_D0.
>
> Schematics can be downloaded from:
> http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
>
> Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
applied as fix for 4.20
Thanks
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: rockchip: rockpro64 fix video output chain
From: Heiko Stuebner @ 2018-12-06 13:03 UTC (permalink / raw)
To: agajjar
Cc: Mark Rutland, devicetree, linux-kernel, linux-rockchip,
Rob Herring, Oskari Lemmela, linux-arm-kernel
In-Reply-To: <09287391-d541-cddb-4168-55ca6fee3f16@mentor.com>
Am Mittwoch, 5. Dezember 2018, 14:03:29 CET schrieb agajjar:
>
> On 12/1/2018 3:38 PM, Oskari Lemmela wrote:
> > Rockpro64 is not able boot if kernel is compiled with
> > CONFIG_DRM_ROCKCHIP=m
> >
> > Enable Rockpro64 board HDMI output to fix issue.
>
> Hi Oskari,
>
> Could you please describe this issue in detail.
>
> I am not able to reproduce this issue if CONFIG_DRM_ROCKCHIP is compile
> in or as a loadable module at the same time hdmi node is present or not.
I've now simply adjusted the commit message to:
"arm64: dts: rockchip: enable hdmi output on rk3399-rockpro64
The rockpro64 does have hdmi support, so add the necessary
devicetree node to enable it."
and applied it for 4.21.
While it still would be good to find out where the issue comes from Oskari
is seeing, the rockpro64 does have hdmi, so we can just enable it ;-)
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [shawnguo:imx/soc 2/2] arch/arm/Kconfig.debug:1445: syntax error
From: Uwe Kleine-König @ 2018-12-06 13:06 UTC (permalink / raw)
To: kbuild test robot; +Cc: kernel, Shawn Guo, kbuild-all, linux-arm-kernel
In-Reply-To: <201812062028.Xnf6p6GZ%fengguang.wu@intel.com>
Hello,
On Thu, Dec 06, 2018 at 08:44:30PM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git imx/soc
> head: 911dccedb00e5b45cf2d0fafc21aba233b58e115
> commit: 911dccedb00e5b45cf2d0fafc21aba233b58e115 [2/2] ARM: debug-imx: only define DEBUG_IMX_UART_PORT if needed
> config: arm-hackkit_defconfig
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 911dccedb00e5b45cf2d0fafc21aba233b58e115
> GCC_VERSION=7.2.0 make.cross ARCH=arm hackkit_defconfig
> GCC_VERSION=7.2.0 make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
> >> arch/arm/Kconfig.debug:1445: syntax error
> >> arch/arm/Kconfig.debug:1444: invalid option
hmm, I was sure I tested that, but I can confirm it fails for me, too.
The obvious fix is:
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 3f057593db01..c253a4e79868 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1441,18 +1441,18 @@ config DEBUG_OMAP2PLUS_UART
config DEBUG_IMX_UART_PORT
int "i.MX Debug UART Port Selection"
- depends on DEBUG_IMX1_UART ||
- DEBUG_IMX25_UART ||
- DEBUG_IMX21_IMX27_UART ||
- DEBUG_IMX31_UART ||
- DEBUG_IMX35_UART ||
- DEBUG_IMX50_UART ||
- DEBUG_IMX51_UART ||
- DEBUG_IMX53_UART ||
- DEBUG_IMX6Q_UART ||
- DEBUG_IMX6SL_UART ||
- DEBUG_IMX6SX_UART ||
- DEBUG_IMX6UL_UART ||
+ depends on DEBUG_IMX1_UART || \
+ DEBUG_IMX25_UART || \
+ DEBUG_IMX21_IMX27_UART || \
+ DEBUG_IMX31_UART || \
+ DEBUG_IMX35_UART || \
+ DEBUG_IMX50_UART || \
+ DEBUG_IMX51_UART || \
+ DEBUG_IMX53_UART || \
+ DEBUG_IMX6Q_UART || \
+ DEBUG_IMX6SL_UART || \
+ DEBUG_IMX6SX_UART || \
+ DEBUG_IMX6UL_UART || \
DEBUG_IMX7D_UART
default 1
help
@Shawn: Can you squash this into the original commit?
Best regards and sorry for the breakage,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 v3] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)
From: Lukasz Majewski @ 2018-12-06 13:08 UTC (permalink / raw)
To: Fabio Estevam
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Sascha Hauer, linux-kernel, Stefan Agner, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5CE2ei-Pu-85zpYHTg-MamMT3DahLxBHNFjX4uLEi1XWg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 576 bytes --]
Hi Fabio,
> On Thu, Dec 6, 2018 at 6:23 AM Lukasz Majewski <lukma@denx.de> wrote:
>
> > At the time of development - I've checked my NXP related patches
> > with W=1 passed to make. No warnings observed then.
>
> In linux-next the warning happens without W=1.
I will check this latter this week...
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)
From: Fabio Estevam @ 2018-12-06 13:11 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Sascha Hauer, linux-kernel, Stefan Agner, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20181206140840.53d49cd6@jawa>
Hi Lukasz,
On Thu, Dec 6, 2018 at 11:08 AM Lukasz Majewski <lukma@denx.de> wrote:
> I will check this latter this week...
Reading the spi dt-binding it states that the spi slave node is optional.
If I remove it like this, then the warning is gone:
--- a/arch/arm/boot/dts/vf610-bk4.dts
+++ b/arch/arm/boot/dts/vf610-bk4.dts
@@ -109,12 +109,6 @@
bus-num = <3>;
status = "okay";
spi-slave;
-
- slave@0 {
- compatible = "lwn,bk4";
- spi-max-frequency = <30000000>;
- reg = <0>;
- };
};
&edma0 {
Does spi slave still work without it?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: Use of_node_name_eq for node name comparisons
From: Benoit Parrot @ 2018-12-06 13:15 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-samsung-soc, Hyun Kwon, linux-kernel,
Krzysztof Kozlowski, Michal Simek, Kyungmin Park, Kukjin Kim,
Laurent Pinchart, Sylwester Nawrocki, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
In-Reply-To: <20181205195050.4759-13-robh@kernel.org>
Hi Rob,
For ti-vpe/cal.c,
Reviewed-by: Benoit Parrot <bparrot@ti.com>
Regards,
Benoit
Rob Herring <robh@kernel.org> wrote on Wed [2018-Dec-05 13:50:29 -0600]:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Benoit Parrot <bparrot@ti.com>
> Cc: Hyun Kwon <hyun.kwon@xilinx.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: linux-media@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/media/platform/exynos4-is/media-dev.c | 12 ++++++------
> drivers/media/platform/ti-vpe/cal.c | 4 ++--
> drivers/media/platform/xilinx/xilinx-tpg.c | 2 +-
> drivers/media/v4l2-core/v4l2-fwnode.c | 6 ++----
> 4 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
> index 870501b0f351..ced14af56606 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -445,7 +445,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
> */
> np = of_get_parent(rem);
>
> - if (np && !of_node_cmp(np->name, "i2c-isp"))
> + if (of_node_name_eq(np, "i2c-isp"))
> pd->fimc_bus_type = FIMC_BUS_TYPE_ISP_WRITEBACK;
> else
> pd->fimc_bus_type = pd->sensor_bus_type;
> @@ -495,7 +495,7 @@ static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
> for_each_available_child_of_node(parent, node) {
> struct device_node *port;
>
> - if (of_node_cmp(node->name, "csis"))
> + if (!of_node_name_eq(node, "csis"))
> continue;
> /* The csis node can have only port subnode. */
> port = of_get_next_child(node, NULL);
> @@ -720,13 +720,13 @@ static int fimc_md_register_platform_entities(struct fimc_md *fmd,
> continue;
>
> /* If driver of any entity isn't ready try all again later. */
> - if (!strcmp(node->name, CSIS_OF_NODE_NAME))
> + if (of_node_name_eq(node, CSIS_OF_NODE_NAME))
> plat_entity = IDX_CSIS;
> - else if (!strcmp(node->name, FIMC_IS_OF_NODE_NAME))
> + else if (of_node_name_eq(node, FIMC_IS_OF_NODE_NAME))
> plat_entity = IDX_IS_ISP;
> - else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
> + else if (of_node_name_eq(node, FIMC_LITE_OF_NODE_NAME))
> plat_entity = IDX_FLITE;
> - else if (!strcmp(node->name, FIMC_OF_NODE_NAME) &&
> + else if (of_node_name_eq(node, FIMC_OF_NODE_NAME) &&
> !of_property_read_bool(node, "samsung,lcd-wb"))
> plat_entity = IDX_FIMC;
>
> diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c
> index 95a093f41905..fc3c212b96e1 100644
> --- a/drivers/media/platform/ti-vpe/cal.c
> +++ b/drivers/media/platform/ti-vpe/cal.c
> @@ -1615,7 +1615,7 @@ of_get_next_port(const struct device_node *parent,
> return NULL;
> }
> prev = port;
> - } while (of_node_cmp(port->name, "port") != 0);
> + } while (!of_node_name_eq(port, "port"));
> }
>
> return port;
> @@ -1635,7 +1635,7 @@ of_get_next_endpoint(const struct device_node *parent,
> if (!ep)
> return NULL;
> prev = ep;
> - } while (of_node_cmp(ep->name, "endpoint") != 0);
> + } while (!of_node_name_eq(ep, "endpoint"));
>
> return ep;
> }
> diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c b/drivers/media/platform/xilinx/xilinx-tpg.c
> index 851d20dcd550..ce686b8d6cff 100644
> --- a/drivers/media/platform/xilinx/xilinx-tpg.c
> +++ b/drivers/media/platform/xilinx/xilinx-tpg.c
> @@ -725,7 +725,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
> const struct xvip_video_format *format;
> struct device_node *endpoint;
>
> - if (!port->name || of_node_cmp(port->name, "port"))
> + if (!of_node_name_eq(port, "port"))
> continue;
>
> format = xvip_of_get_format(port);
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c
> index 218f0da0ce76..849326241b17 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -564,8 +564,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
> fwnode = fwnode_get_parent(__fwnode);
> fwnode_property_read_u32(fwnode, port_prop, &link->local_port);
> fwnode = fwnode_get_next_parent(fwnode);
> - if (is_of_node(fwnode) &&
> - of_node_cmp(to_of_node(fwnode)->name, "ports") == 0)
> + if (is_of_node(fwnode) && of_node_name_eq(to_of_node(fwnode), "ports"))
> fwnode = fwnode_get_next_parent(fwnode);
> link->local_node = fwnode;
>
> @@ -578,8 +577,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
> fwnode = fwnode_get_parent(fwnode);
> fwnode_property_read_u32(fwnode, port_prop, &link->remote_port);
> fwnode = fwnode_get_next_parent(fwnode);
> - if (is_of_node(fwnode) &&
> - of_node_cmp(to_of_node(fwnode)->name, "ports") == 0)
> + if (is_of_node(fwnode) && of_node_name_eq(to_of_node(fwnode), "ports"))
> fwnode = fwnode_get_next_parent(fwnode);
> link->remote_node = fwnode;
>
> --
> 2.19.1
>
_______________________________________________
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/2] meson: Fix IRQ trigger type
From: Carlo Caione @ 2018-12-06 13:17 UTC (permalink / raw)
To: Emiliano Ingrassia, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20181206124347.GA10676@ingrassia.epigenesys.com>
On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> Hi all,
Hi Emiliano,
> thank you for involving me.
>
> I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> and tested it with kernel packet generator, monitoring
> bandwidth usage with "nload".
>
> All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> with a short ethernet cable directly attached to a laptop with
> 1G ethernet interface, with "nload" running on the board.
>
> The tests I performed are composed by the following steps:
>
> 1) Start packet generator with "rate 1000M" on laptop;
>
> 2) Keep packet generator active on the laptop and
> start the packet generator on the board with "rate 1000M";
>
> 3) Stop both packet generators;
>
> 4) Start packet generator on the board;
>
> 5) Keep packet generator active on the board and
> start the packet generator on the laptop.
out of curiosity: why do you expect to see something different from
point (2)?
> Test results without Carlo's patches applied:
>
> 1) "nload" shows an incoming traffic of ~950Mbps;
>
> 2) "nload" shows an incoming traffic of ~400Mbps
> and an outgoing traffic of ~250Mbps;
>
> 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
>
> 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
>
> 5) "nload" shows incoming traffic of 0Mbps
> and an outgoing traffic of ~950Mbps.
>
> Applying only the first patch (change mac IRQ type) I got the same
> results.
This is expected. The change in the IRQ type is solving an issue that
you can see if the run a stress test involving multiple components for
several hours.
> Applying only the second patch (drop eee-broken-1000t) I got the same
> results!
I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
problem with the ethernet? Are you suggesting that for some reason you
cannot reproduce anymore the problem for which the quirk was
introduced?
> With both patches applied I got the same results but with an incoming
> traffic
> of ~3Mbps on the board.
On all the tests and immediately from the start of the tests?
When you hit the problem con you check in /proc/interrupts if you see
the IRQ counter for the eth0 incrementing or not?
Cheers,
--
Carlo Caione
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: ftrace: Set FTRACE_SCHEDULABLE before ftrace_modify_all_code()
From: Will Deacon @ 2018-12-06 13:20 UTC (permalink / raw)
To: Steven Rostedt
Cc: Anders Roxell, keescook, arnd, catalin.marinas, linux-kernel,
Ingo Molnar, linux-arm-kernel
In-Reply-To: <20181205183304.000714627@goodmis.org>
On Wed, Dec 05, 2018 at 12:48:54PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> It has been reported that ftrace_replace_code() which is called by
> ftrace_modify_all_code() can cause a soft lockup warning for an
> allmodconfig kernel. This is because all the debug options enabled
> causes the loop in ftrace_replace_code() (which loops over all the
> functions being enabled where there can be 10s of thousands), is too
> slow, and never schedules out.
>
> To solve this, setting FTRACE_SCHEDULABLE to the command passed into
> ftrace_replace_code() will make it call cond_resched() in the loop,
> which prevents the soft lockup warning from triggering.
>
> Link: http://lkml.kernel.org/r/20181204192903.8193-1-anders.roxell@linaro.org
>
> Reported-by: Anders Roxell <anders.roxell@linaro.org>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
> arch/arm64/kernel/ftrace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> index 57e962290df3..9a8de0a79f97 100644
> --- a/arch/arm64/kernel/ftrace.c
> +++ b/arch/arm64/kernel/ftrace.c
> @@ -193,6 +193,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
>
> void arch_ftrace_update_code(int command)
> {
> + command |= FTRACE_SCHEDULABLE;
> ftrace_modify_all_code(command);
> }
Bikeshed: I'd probably go for FTRACE_MAY_SLEEP, but I'm not going to die
on that hill so...
Acked-by: Will Deacon <will.deacon@arm.com>
Thanks, Steve!
Will
_______________________________________________
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] ARM: dts: rockchip: add BQ Edison 2 QC devicetree
From: Heiko Stuebner @ 2018-12-06 13:20 UTC (permalink / raw)
To: linux-rockchip; +Cc: mark.rutland, devicetree, robh+dt, linux-arm-kernel
In-Reply-To: <20181113130559.31221-7-heiko@sntech.de>
Am Dienstag, 13. November 2018, 14:05:59 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner <heiko.stuebner@bq.com>
>
> The Edison 2 Quad-Core was a Tablet device released in 2013 by MundoReader
> using a rk3188 soc. Add a devicetree for it.
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@bq.com>
applied for 4.21
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Resend PATCH V5 0/10] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
Cc: linux-mips, kvm, rkrcmar, benh, will.deacon, christoffer.dall,
paulus, hpa, kys, kvmarm, sthemmin, mpe, x86, linux,
michael.h.kelley, mingo, catalin.marinas, jhogan, Lan Tianyu,
marc.zyngier, haiyangz, kvm-ppc, bp, pbonzini, tglx,
linux-arm-kernel, linux-kernel, ralf, paul.burton, devel,
vkuznets, linuxppc-dev
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
For nested memory virtualization, Hyper-v doesn't set write-protect
L1 hypervisor EPT page directory and page table node to track changes
while it relies on guest to tell it changes via HvFlushGuestAddressLlist
hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush
EPT page table with ranges which are specified by L1 hypervisor.
If L1 hypervisor uses INVEPT or HvFlushGuestAddressSpace hypercall to
flush EPT tlb, Hyper-V will invalidate associated EPT shadow page table
and sync L1's EPT table when next EPT page fault is triggered.
HvFlushGuestAddressLlist hypercall helps to avoid such redundant EPT
page fault and synchronization of shadow page table.
This patchset is based on the Patch "KVM/VMX: Check ept_pointer before
flushing ept tlb"(https://marc.info/?l=kvm&m=154408169705686&w=2).
Change since v4:
1) Split flush address and flush list patches. This patchset only contains
flush address patches. Will post flush list patches later.
2) Expose function hyperv_fill_flush_guest_mapping_list()
out of hyperv file
3) Adjust parameter of hyperv_flush_guest_mapping_range()
4) Reorder patchset and move Hyper-V and VMX changes ahead.
Change since v3:
1) Remove code of updating "tlbs_dirty" in kvm_flush_remote_tlbs_with_range()
2) Remove directly tlb flush in the kvm_handle_hva_range()
3) Move tlb flush in kvm_set_pte_rmapp() to kvm_mmu_notifier_change_pte()
4) Combine Vitaly's "don't pass EPT configuration info to
vmx_hv_remote_flush_tlb()" fix
Change since v2:
1) Fix comment in the kvm_flush_remote_tlbs_with_range()
2) Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
hyperv-tlfs.h.
3) Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
4) Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
struct hv_guest_mapping_flush_list.
Change since v1:
1) Convert "end_gfn" of struct kvm_tlb_range to "pages" in order
to avoid confusion as to whether "end_gfn" is inclusive or exlusive.
2) Add hyperv tlb range struct and replace kvm tlb range struct
with new struct in order to avoid using kvm struct in the hyperv
code directly.
Lan Tianyu (10):
KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
x86/hyper-v: Add HvFlushGuestAddressList hypercall support
x86/Hyper-v: Add trace in the
hyperv_nested_flush_guest_mapping_range()
KVM/VMX: Add hv tlb range flush support
KVM/MMU: Add tlb flush with range helper function
KVM: Replace old tlb flush function with new one to flush a specified
range.
KVM: Make kvm_set_spte_hva() return int
KVM/MMU: Move tlb flush in kvm_set_pte_rmapp() to
kvm_mmu_notifier_change_pte()
KVM/MMU: Flush tlb directly in the kvm_set_pte_rmapp()
KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/mips/include/asm/kvm_host.h | 2 +-
arch/mips/kvm/mmu.c | 3 +-
arch/powerpc/include/asm/kvm_host.h | 2 +-
arch/powerpc/kvm/book3s.c | 3 +-
arch/powerpc/kvm/e500_mmu_host.c | 3 +-
arch/x86/hyperv/nested.c | 80 +++++++++++++++++++++++++++++++
arch/x86/include/asm/hyperv-tlfs.h | 32 +++++++++++++
arch/x86/include/asm/kvm_host.h | 9 +++-
arch/x86/include/asm/mshyperv.h | 15 ++++++
arch/x86/include/asm/trace/hyperv.h | 14 ++++++
arch/x86/kvm/mmu.c | 96 +++++++++++++++++++++++++++++--------
arch/x86/kvm/paging_tmpl.h | 3 +-
arch/x86/kvm/vmx.c | 63 +++++++++++++++++-------
virt/kvm/arm/mmu.c | 6 ++-
virt/kvm/kvm_main.c | 5 +-
17 files changed, 292 insertions(+), 48 deletions(-)
--
2.14.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Resend PATCH V5 1/10] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, paulus, hpa, kys, kvmarm, sthemmin, mpe, x86, linux,
michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, bp, devel, tglx, linux-arm-kernel,
christoffer.dall, ralf, paul.burton, pbonzini, vkuznets,
linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
Add flush range call back in the kvm_x86_ops and platform can use it
to register its associated function. The parameter "kvm_tlb_range"
accepts a single range and flush list which contains a list of ranges.
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
Change since v1:
Change "end_gfn" to "pages" to aviod confusion as to whether
"end_gfn" is inclusive or exlusive.
---
arch/x86/include/asm/kvm_host.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index fbda5a917c5b..fc7513ecfc13 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -439,6 +439,11 @@ struct kvm_mmu {
u64 pdptrs[4]; /* pae */
};
+struct kvm_tlb_range {
+ u64 start_gfn;
+ u64 pages;
+};
+
enum pmc_type {
KVM_PMC_GP = 0,
KVM_PMC_FIXED,
@@ -1042,6 +1047,8 @@ struct kvm_x86_ops {
void (*tlb_flush)(struct kvm_vcpu *vcpu, bool invalidate_gpa);
int (*tlb_remote_flush)(struct kvm *kvm);
+ int (*tlb_remote_flush_with_range)(struct kvm *kvm,
+ struct kvm_tlb_range *range);
/*
* Flush any TLB entries associated with the given GVA.
--
2.14.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
* [Resend PATCH V5 2/10] x86/hyper-v: Add HvFlushGuestAddressList hypercall support
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, paulus, hpa, kys, kvmarm, sthemmin, mpe, x86, linux,
michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, bp, devel, tglx, linux-arm-kernel,
christoffer.dall, ralf, paul.burton, pbonzini, vkuznets,
linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
with specified ranges. This patch is to add the hypercall support.
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
Change sincd v4:
- Expose function hyperv_fill_flush_guest_mapping_list()
out of hyperv file
- Adjust parameter of hyperv_flush_guest_mapping_range()
Change since v2:
Fix some coding style issues
- Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
hyperv-tlfs.h.
- Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
- Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
struct hv_guest_mapping_flush_list.
Change since v1:
Add hyperv tlb flush struct to avoid use kvm tlb flush struct
in the hyperv file.
---
arch/x86/hyperv/nested.c | 79 ++++++++++++++++++++++++++++++++++++++
arch/x86/include/asm/hyperv-tlfs.h | 32 +++++++++++++++
arch/x86/include/asm/mshyperv.h | 15 ++++++++
3 files changed, 126 insertions(+)
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index b8e60cc50461..3d0f31e46954 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -7,6 +7,7 @@
*
* Author : Lan Tianyu <Tianyu.Lan@microsoft.com>
*/
+#define pr_fmt(fmt) "Hyper-V: " fmt
#include <linux/types.h>
@@ -54,3 +55,81 @@ int hyperv_flush_guest_mapping(u64 as)
return ret;
}
EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
+
+int hyperv_fill_flush_guest_mapping_list(
+ struct hv_guest_mapping_flush_list *flush,
+ u64 start_gfn, u64 pages)
+{
+ u64 cur = start_gfn;
+ u64 additional_pages;
+ int gpa_n = 0;
+
+ do {
+ /*
+ * If flush requests exceed max flush count, go back to
+ * flush tlbs without range.
+ */
+ if (gpa_n >= HV_MAX_FLUSH_REP_COUNT)
+ return -ENOSPC;
+
+ additional_pages = min_t(u64, pages, HV_MAX_FLUSH_PAGES) - 1;
+
+ flush->gpa_list[gpa_n].page.additional_pages = additional_pages;
+ flush->gpa_list[gpa_n].page.largepage = false;
+ flush->gpa_list[gpa_n].page.basepfn = cur;
+
+ pages -= additional_pages + 1;
+ cur += additional_pages + 1;
+ gpa_n++;
+ } while (pages > 0);
+
+ return gpa_n;
+}
+EXPORT_SYMBOL_GPL(hyperv_fill_flush_guest_mapping_list);
+
+int hyperv_flush_guest_mapping_range(u64 as,
+ hyperv_fill_flush_list_func fill_flush_list_func, void *data)
+{
+ struct hv_guest_mapping_flush_list **flush_pcpu;
+ struct hv_guest_mapping_flush_list *flush;
+ u64 status = 0;
+ unsigned long flags;
+ int ret = -ENOTSUPP;
+ int gpa_n = 0;
+
+ if (!hv_hypercall_pg || !fill_flush_list_func)
+ goto fault;
+
+ local_irq_save(flags);
+
+ flush_pcpu = (struct hv_guest_mapping_flush_list **)
+ this_cpu_ptr(hyperv_pcpu_input_arg);
+
+ flush = *flush_pcpu;
+ if (unlikely(!flush)) {
+ local_irq_restore(flags);
+ goto fault;
+ }
+
+ flush->address_space = as;
+ flush->flags = 0;
+
+ gpa_n = fill_flush_list_func(flush, data);
+ if (gpa_n < 0) {
+ local_irq_restore(flags);
+ goto fault;
+ }
+
+ status = hv_do_rep_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST,
+ gpa_n, 0, flush, NULL);
+
+ local_irq_restore(flags);
+
+ if (!(status & HV_HYPERCALL_RESULT_MASK))
+ ret = 0;
+ else
+ ret = status;
+fault:
+ return ret;
+}
+EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h
index 4139f7650fe5..405a378e1c62 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -10,6 +10,7 @@
#define _ASM_X86_HYPERV_TLFS_H
#include <linux/types.h>
+#include <asm/page.h>
/*
* The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
@@ -358,6 +359,7 @@ struct hv_tsc_emulation_status {
#define HVCALL_POST_MESSAGE 0x005c
#define HVCALL_SIGNAL_EVENT 0x005d
#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
+#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
#define HV_X64_MSR_VP_ASSIST_PAGE_ENABLE 0x00000001
#define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT 12
@@ -757,6 +759,36 @@ struct hv_guest_mapping_flush {
u64 flags;
};
+/*
+ * HV_MAX_FLUSH_PAGES = "additional_pages" + 1. It's limited
+ * by the bitwidth of "additional_pages" in union hv_gpa_page_range.
+ */
+#define HV_MAX_FLUSH_PAGES (2048)
+
+/* HvFlushGuestPhysicalAddressList hypercall */
+union hv_gpa_page_range {
+ u64 address_space;
+ struct {
+ u64 additional_pages:11;
+ u64 largepage:1;
+ u64 basepfn:52;
+ } page;
+};
+
+/*
+ * All input flush parameters should be in single page. The max flush
+ * count is equal with how many entries of union hv_gpa_page_range can
+ * be populated into the input parameter page.
+ */
+#define HV_MAX_FLUSH_REP_COUNT (PAGE_SIZE - 2 * sizeof(u64) / \
+ sizeof(union hv_gpa_page_range))
+
+struct hv_guest_mapping_flush_list {
+ u64 address_space;
+ u64 flags;
+ union hv_gpa_page_range gpa_list[HV_MAX_FLUSH_REP_COUNT];
+};
+
/* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
struct hv_tlb_flush {
u64 address_space;
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 1d0a7778e163..7da712f65398 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -22,6 +22,11 @@ struct ms_hyperv_info {
extern struct ms_hyperv_info ms_hyperv;
+
+typedef int (*hyperv_fill_flush_list_func)(
+ struct hv_guest_mapping_flush_list *flush,
+ void *data);
+
/*
* Generate the guest ID.
*/
@@ -348,6 +353,11 @@ void set_hv_tscchange_cb(void (*cb)(void));
void clear_hv_tscchange_cb(void);
void hyperv_stop_tsc_emulation(void);
int hyperv_flush_guest_mapping(u64 as);
+int hyperv_flush_guest_mapping_range(u64 as,
+ hyperv_fill_flush_list_func fill_func, void *data);
+int hyperv_fill_flush_guest_mapping_list(
+ struct hv_guest_mapping_flush_list *flush,
+ u64 start_gfn, u64 end_gfn);
#ifdef CONFIG_X86_64
void hv_apic_init(void);
@@ -370,6 +380,11 @@ static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
return NULL;
}
static inline int hyperv_flush_guest_mapping(u64 as) { return -1; }
+static inline int hyperv_flush_guest_mapping_range(u64 as,
+ hyperv_fill_flush_list_func fill_func, void *data);
+{
+ return -1;
+}
#endif /* CONFIG_HYPERV */
#ifdef CONFIG_HYPERV_TSCPAGE
--
2.14.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
* [Resend PATCH V5 3/10] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
linux-kernel, paulus, hpa, kys, kvmarm, sthemmin, mpe, x86, linux,
michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, bp, devel, tglx, linux-arm-kernel,
christoffer.dall, ralf, paul.burton, pbonzini, vkuznets,
linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>
From: Lan Tianyu <Tianyu.Lan@microsoft.com>
This patch is to trace log in the hyperv_nested_flush_
guest_mapping_range().
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
arch/x86/hyperv/nested.c | 1 +
arch/x86/include/asm/trace/hyperv.h | 14 ++++++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index 3d0f31e46954..dd0a843f766d 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -130,6 +130,7 @@ int hyperv_flush_guest_mapping_range(u64 as,
else
ret = status;
fault:
+ trace_hyperv_nested_flush_guest_mapping_range(as, ret);
return ret;
}
EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/trace/hyperv.h b/arch/x86/include/asm/trace/hyperv.h
index 2e6245a023ef..ace464f09681 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -42,6 +42,20 @@ TRACE_EVENT(hyperv_nested_flush_guest_mapping,
TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
);
+TRACE_EVENT(hyperv_nested_flush_guest_mapping_range,
+ TP_PROTO(u64 as, int ret),
+ TP_ARGS(as, ret),
+
+ TP_STRUCT__entry(
+ __field(u64, as)
+ __field(int, ret)
+ ),
+ TP_fast_assign(__entry->as = as;
+ __entry->ret = ret;
+ ),
+ TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+ );
+
TRACE_EVENT(hyperv_send_ipi_mask,
TP_PROTO(const struct cpumask *cpus,
int vector),
--
2.14.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
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