* Re: [PATCH v8 1/5] mm: untag user pointers in mmap/munmap/mremap/brk
From: Andrey Konovalov @ 2019-08-19 15:45 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, open list:DOCUMENTATION, Dave Hansen, Szabolcs Nagy,
Kevin Brodsky, Will Deacon, Linux Memory Management List,
Andrew Morton, Vincenzo Frascino, Dave P Martin, Linux ARM
In-Reply-To: <20190815154403.16473-2-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 5:44 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> There isn't a good reason to differentiate between the user address
> space layout modification syscalls and the other memory
> permission/attributes ones (e.g. mprotect, madvise) w.r.t. the tagged
> address ABI. Untag the user addresses on entry to these functions.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> mm/mmap.c | 5 +++++
> mm/mremap.c | 6 +-----
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7e8c3e8ae75f..b766b633b7ae 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -201,6 +201,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
> bool downgraded = false;
> LIST_HEAD(uf);
>
> + brk = untagged_addr(brk);
> +
> if (down_write_killable(&mm->mmap_sem))
> return -EINTR;
>
> @@ -1573,6 +1575,8 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,
> struct file *file = NULL;
> unsigned long retval;
>
> + addr = untagged_addr(addr);
> +
> if (!(flags & MAP_ANONYMOUS)) {
> audit_mmap_fd(fd, flags);
> file = fget(fd);
> @@ -2874,6 +2878,7 @@ EXPORT_SYMBOL(vm_munmap);
>
> SYSCALL_DEFINE2(munmap, unsigned long, addr, size_t, len)
> {
> + addr = untagged_addr(addr);
> profile_munmap(addr);
> return __vm_munmap(addr, len, true);
> }
> diff --git a/mm/mremap.c b/mm/mremap.c
> index 64c9a3b8be0a..1fc8a29fbe3f 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -606,12 +606,8 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
> LIST_HEAD(uf_unmap_early);
> LIST_HEAD(uf_unmap);
>
> - /*
> - * Architectures may interpret the tag passed to mmap as a background
> - * colour for the corresponding vma. For mremap we don't allow tagged
> - * new_addr to preserve similar behaviour to mmap.
> - */
> addr = untagged_addr(addr);
> + new_addr = untagged_addr(new_addr);
>
> if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
> return ret;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Best representation for TDM devices
From: Mark Brown @ 2019-08-19 15:45 UTC (permalink / raw)
To: Maxime Ripard; +Cc: Ali Burak Parım, linux-arm-kernel
In-Reply-To: <20190819084141.otpbos2fgxav7rco@flea>
[-- Attachment #1.1: Type: text/plain, Size: 977 bytes --]
On Mon, Aug 19, 2019 at 10:41:41AM +0200, Maxime Ripard wrote:
> On Wed, Aug 14, 2019 at 05:02:34PM +0100, Mark Brown wrote:
> > OK, in that case I'd recommend providing them to userspace as a single
> > four channel stream - keeping everything bundled together as long as
> > possible to make it easier to keep the processing synced up.
> Ok, that's what I had in mind as well :)
> However, it looks like we can only capture as many channels as the max
> being exposed by the codec on the link?
> Any attempt at capturing something with 4 channels here using arecord
> was either reduced to two channels (the amount of channels provided by
> the adau7002 driver), or just refused by the ALSA core.
> Is there anything that we need to configure / work on to enable this?
I'd expect there's some issue in the capability/constraint matching code
that needs fixing - that should work but I can totally see it not
working unless someone goes in and does something to fix it.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH ARM] selftests, arm64: fix uninitialized symbol in tags_test.c
From: Andrey Konovalov @ 2019-08-19 15:44 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, kvm, Christian Koenig, Szabolcs Nagy,
Catalin Marinas, Will Deacon, dri-devel, Kostya Serebryany,
Khalid Aziz, Lee Smith, open list:KERNEL SELFTEST FRAMEWORK,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kees Cook,
Ruben Ayrapetyan, Kevin Brodsky, Alex Williamson,
Mauro Carvalho Chehab, Linux ARM, Linux Memory Management List,
Greg Kroah-Hartman, Felix Kuehling, LKML, Jens Wiklander,
Dan Carpenter, Ramana Radhakrishnan, Alexander Deucher,
Andrew Morton, enh, Robin Murphy, Yishai Hadas,
Luc Van Oostenryck
In-Reply-To: <20190819153856.odtneqxfxva2wjgu@willie-the-truck>
On Mon, Aug 19, 2019 at 5:39 PM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Aug 19, 2019 at 05:16:37PM +0200, Andrey Konovalov wrote:
> > On Mon, Aug 19, 2019 at 5:03 PM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Mon, Aug 19, 2019 at 03:14:42PM +0200, Andrey Konovalov wrote:
> > > > Fix tagged_ptr not being initialized when TBI is not enabled.
> > > >
> > > > Dan Carpenter <dan.carpenter@oracle.com>
> > >
> > > Guessing this was Reported-by, or has Dan introduced his own tag now? ;)
> >
> > Oops, yes, Reported-by :)
> >
> > >
> > > Got a link to the report?
> >
> > https://www.spinics.net/lists/linux-kselftest/msg09446.html
>
> Thanks, I'll fix up the commit message and push this out later on. If you
> get a chance, would you be able to look at the pending changes from
> Catalin[1], please?
>
> Will
>
> [1] https://lkml.kernel.org/r/20190815154403.16473-1-catalin.marinas@arm.com
Sure! I didn't realize some actioned is required from me on those.
I'll add my Acked-by's. 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 ARM] selftests, arm64: fix uninitialized symbol in tags_test.c
From: Will Deacon @ 2019-08-19 15:38 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mark Rutland, kvm, Christian Koenig, Szabolcs Nagy,
Catalin Marinas, Will Deacon, dri-devel, Kostya Serebryany,
Khalid Aziz, Lee Smith, open list:KERNEL SELFTEST FRAMEWORK,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kees Cook,
Ruben Ayrapetyan, Kevin Brodsky, Alex Williamson,
Mauro Carvalho Chehab, Linux ARM, Linux Memory Management List,
Greg Kroah-Hartman, Felix Kuehling, LKML, Jens Wiklander,
Dan Carpenter, Ramana Radhakrishnan, Alexander Deucher,
Andrew Morton, enh, Robin Murphy, Yishai Hadas,
Luc Van Oostenryck
In-Reply-To: <CAAeHK+xP6HnLJt_RKW67x8nbJLJp5A=av57BfwiFrA88eFn60w@mail.gmail.com>
On Mon, Aug 19, 2019 at 05:16:37PM +0200, Andrey Konovalov wrote:
> On Mon, Aug 19, 2019 at 5:03 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Aug 19, 2019 at 03:14:42PM +0200, Andrey Konovalov wrote:
> > > Fix tagged_ptr not being initialized when TBI is not enabled.
> > >
> > > Dan Carpenter <dan.carpenter@oracle.com>
> >
> > Guessing this was Reported-by, or has Dan introduced his own tag now? ;)
>
> Oops, yes, Reported-by :)
>
> >
> > Got a link to the report?
>
> https://www.spinics.net/lists/linux-kselftest/msg09446.html
Thanks, I'll fix up the commit message and push this out later on. If you
get a chance, would you be able to look at the pending changes from
Catalin[1], please?
Will
[1] https://lkml.kernel.org/r/20190815154403.16473-1-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] arm64: kasan: fix phys_to_virt() false positive on tag-based kasan
From: Andrey Konovalov @ 2019-08-19 15:37 UTC (permalink / raw)
To: Mark Rutland, Will Deacon
Cc: Walter Wu, wsd_upstream, Catalin Marinas, Will Deacon, LKML,
kasan-dev, linux-mediatek, Alexander Potapenko, Linux ARM,
Matthias Brugger, Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <20190819150341.GC9927@lakrids.cambridge.arm.com>
On Mon, Aug 19, 2019 at 5:03 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Mon, Aug 19, 2019 at 04:05:22PM +0200, Andrey Konovalov wrote:
> > On Mon, Aug 19, 2019 at 3:34 PM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote:
> > > > On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
> > > > > On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
> > > > > > __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address,
> > > > > > but it will modify pointer tag into 0xff, so there is a false positive.
> > > > > >
> > > > > > When enable tag-based kasan, phys_to_virt() function need to rewrite
> > > > > > its original pointer tag in order to avoid kasan report an incorrect
> > > > > > memory corruption.
> > > > >
> > > > > Hmm. Which tree did you see this on? We've recently queued a load of fixes
> > > > > in this area, but I /thought/ they were only needed after the support for
> > > > > 52-bit virtual addressing in the kernel.
> > > >
> > > > I'm seeing similar issues in the virtio blk code (splat below), atop of
> > > > the arm64 for-next/core branch. I think this is a latent issue, and
> > > > people are only just starting to test with KASAN_SW_TAGS.
> > > >
> > > > It looks like the virtio blk code will round-trip a SLUB-allocated pointer from
> > > > virt->page->virt, losing the per-object tag in the process.
> > > >
> > > > Our page_to_virt() seems to get a per-page tag, but this only makes
> > > > sense if you're dealing with the page allocator, rather than something
> > > > like SLUB which carves a page into smaller objects giving each object a
> > > > distinct tag.
> > > >
> > > > Any round-trip of a pointer from SLUB is going to lose the per-object
> > > > tag.
> > >
> > > Urgh, I wonder how this is supposed to work?
> > >
> > > If we end up having to check the KASAN shadow for *_to_virt(), then why
> > > do we need to store anything in the page flags at all? Andrey?
> >
> > As per 2813b9c0 ("kasan, mm, arm64: tag non slab memory allocated via
> > pagealloc") we should only save a non-0xff tag in page flags for non
> > slab pages.
> >
> > Could you share your .config so I can reproduce this?
>
> I wrote a test (below) to do so. :)
>
> It fires with arm64 defconfig, + CONFIG_TEST_KASAN=m.
>
> With Andrey Ryabinin's patch it works as expected with no KASAN splats
> for the two new test cases.
OK, Andrey's patch makes sense and fixes both Mark's test patch and
reports from CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST.
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
on both patches.
>
> Thanks,
> Mark.
>
> ---->8----
> From 7e8569b558fca21ad4e80fddae659591bc84ce1f Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland@arm.com>
> Date: Mon, 19 Aug 2019 15:39:32 +0100
> Subject: [PATCH] lib/test_kasan: add roundtrip tests
>
> In several places we needs to be able to operate on pointers which have
"needs" => "need"
> gone via a roundtrip:
>
> virt -> {phys,page} -> virt
>
> With KASAN_SW_TAGS, we can't preserve the tag for SLUB objects, and the
> {phys,page} -> virt conversion will use KASAN_TAG_KERNEL.
>
> This patch adds tests to ensure that this works as expected, without
> false positives.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> lib/test_kasan.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index b63b367a94e8..cf7b93f0d90c 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -19,6 +19,8 @@
> #include <linux/string.h>
> #include <linux/uaccess.h>
>
> +#include <asm/page.h>
> +
> /*
> * Note: test functions are marked noinline so that their names appear in
> * reports.
> @@ -337,6 +339,42 @@ static noinline void __init kmalloc_uaf2(void)
> kfree(ptr2);
> }
>
> +static noinline void __init kfree_via_page(void)
> +{
> + char *ptr;
> + size_t size = 8;
> + struct page *page;
> + unsigned long offset;
> +
> + pr_info("invalid-free false positive (via page)\n");
> + ptr = kmalloc(size, GFP_KERNEL);
> + if (!ptr) {
> + pr_err("Allocation failed\n");
> + return;
> + }
> +
> + page = virt_to_page(ptr);
> + offset = offset_in_page(ptr);
> + kfree(page_address(page) + offset);
> +}
> +
> +static noinline void __init kfree_via_phys(void)
> +{
> + char *ptr;
> + size_t size = 8;
> + phys_addr_t phys;
> +
> + pr_info("invalid-free false positive (via phys)\n");
> + ptr = kmalloc(size, GFP_KERNEL);
> + if (!ptr) {
> + pr_err("Allocation failed\n");
> + return;
> + }
> +
> + phys = virt_to_phys(ptr);
> + kfree(phys_to_virt(phys));
> +}
> +
> static noinline void __init kmem_cache_oob(void)
> {
> char *p;
> @@ -737,6 +775,8 @@ static int __init kmalloc_tests_init(void)
> kmalloc_uaf();
> kmalloc_uaf_memset();
> kmalloc_uaf2();
> + kfree_via_page();
> + kfree_via_phys();
> kmem_cache_oob();
> memcg_accounted_kmem_cache();
> kasan_stack_oob();
> --
> 2.11.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 4/3] pwm: atmel: document known weaknesses of both hardware and software
From: Uwe Kleine-König @ 2019-08-19 15:20 UTC (permalink / raw)
To: Claudiu.Beznea
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, thierry.reding,
linux-arm-kernel
In-Reply-To: <3029467b-be14-d78b-5580-8bd3842d86e2@microchip.com>
Hello Claudiu,
On Mon, Aug 19, 2019 at 12:28:59PM +0000, Claudiu.Beznea@microchip.com wrote:
> On 19.08.2019 13:46, Uwe Kleine-König wrote:
> > On Mon, Aug 19, 2019 at 09:26:04AM +0000, Claudiu.Beznea@microchip.com wrote:
> >> On 16.08.2019 12:37, Uwe Kleine-König wrote:
> >>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> >>> ---
> >>> drivers/pwm/pwm-atmel.c | 10 ++++++++++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> >>> index 42fe7bc043a8..1ddb93db9627 100644
> >>> --- a/drivers/pwm/pwm-atmel.c
> >>> +++ b/drivers/pwm/pwm-atmel.c
> >>> @@ -7,6 +7,16 @@
> >>> *
> >>> * Reference manual for "atmel,at91sam9rl-pwm":
> >>> * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
> >>> + *
> >>> + * Limitations:
> >>> + * - Periods start with the inactive level.
> >>
> >> Are you talking here about the normal polarity (from documentation: By
> >> definition, normal polarity characterizes a signal starts high for the
> >> duration of the duty cycle and goes low for the remainder of the period.)
> >
> > When .polarity = PWM_POLARITY_NORMAL is passed to atmel_pwm_apply() the
> > drivers sets PWM_CMR_CPOL=0 which according to the datasheet (linked
> > above) means: "The output waveform starts at a low level."
> >
> > So maybe just the logic has to be inverted there,
>
> Agree.
>
> > but then maybe the
> > output gets active instead of inactive when the PWM is disabled.
>
> Yes, this would happen. Playing again with CPOL when disabling may be a
> solution.
Alternatively you could argue that it would be more sensible to drop the
requirement for a certain output level on disable. You would have my
support here.
> > (Which in my book is ok, but it's Thierry's opinion that counts here.)
> >
> >> If yes, this should be solved by playing with CPOL bit of CMR.
> >>
> >>> + * - Hardware has to be stopped in general to update settings.
> >>
> >> Sama5d2 has duty cycle that could be updated on the fly.
> >
> > There is some functionality in the 9G25, too. I didn't understand it
> > completely but maybe it only helps updating one of period or duty cycle.
> >
> >>> + *
> >>> + * Software bugs/possible improvements:
> >>> + * - When atmel_pwm_apply() is called with state->enabled=false a change in
> >>> + * state->polarity isn't honored.
> >>
> >> I know that when configuring a PWM one should get the current state of the
> >> PWM, change it, then pass it to the driver via pwm_apply_state().
> >
> > That seems to be a common pattern at least. IMHO letting the consumer
> > just configure the state that should be used should be fine, too.>
> >> In case one would call the pwm_apply_state() with state->enabled =
> >> false the state would be stored in PWM specific object (of type struct
> >> pwm_device). On the next apply, with enabled = true, all the PWM
> >> parameters would be actually applied to hardware. So, until
> >> enable=true the PWM state would only be cached by PWM core specific
> >> objects (in pwm_apply_state()).
> >
> > I fail to follow what you mean here. If a PWM runs with (say) normal
> > polarity and you call pwm_apply_state(mypwm, { .polarity =
> > PWM_POLARITY_INVERSED, .enabled = false, }); the apply callback of the
> > lowlevel driver is called and supposed to configure the output to yield
> > a constant high.
>
> Ok, I see it now. I'll put it on my queue.
See above. The atmel driver is just part of my quest to get a general
picture what the common PWM implementation does. Thierry argued that it
is natural that a PWM drives the inactive level on disable.
I'd say that it would be more natural to not demand a certain level
because a) IMHO there are enough implementations that differ here and b)
consumers could just configure for duty_cycle=0 if they care.
In the case of the imx driver we could just put aside the discussions
about how we atomically switch the output to a GPIO to provide the
needed level. In case of the atmel driver you'd just invert polarity and
be done.
Best regards
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
* Re: [PATCH ARM] selftests, arm64: fix uninitialized symbol in tags_test.c
From: Andrey Konovalov @ 2019-08-19 15:16 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, kvm, Christian Koenig, Szabolcs Nagy,
Catalin Marinas, Will Deacon, dri-devel, Kostya Serebryany,
Khalid Aziz, Lee Smith, open list:KERNEL SELFTEST FRAMEWORK,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kees Cook,
Ruben Ayrapetyan, Kevin Brodsky, Alex Williamson,
Mauro Carvalho Chehab, Linux ARM, Linux Memory Management List,
Greg Kroah-Hartman, Felix Kuehling, LKML, Jens Wiklander,
Dan Carpenter, Ramana Radhakrishnan, Alexander Deucher,
Andrew Morton, enh, Robin Murphy, Yishai Hadas,
Luc Van Oostenryck
In-Reply-To: <20190819150342.sxk3zzxvrxhkpp6j@willie-the-truck>
On Mon, Aug 19, 2019 at 5:03 PM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Aug 19, 2019 at 03:14:42PM +0200, Andrey Konovalov wrote:
> > Fix tagged_ptr not being initialized when TBI is not enabled.
> >
> > Dan Carpenter <dan.carpenter@oracle.com>
>
> Guessing this was Reported-by, or has Dan introduced his own tag now? ;)
Oops, yes, Reported-by :)
>
> Got a link to the report?
https://www.spinics.net/lists/linux-kselftest/msg09446.html
>
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: at91: Documentation: update the sama5d3 and armv7m datasheets
From: Nicolas Ferre @ 2019-08-19 15:12 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches; +Cc: linux-kernel, linux-arm-kernel
Update SAMA5D3 and SAM E70/S70/V70/V71 Family SoC Datasheets. URL are
updated in Microchip documentation.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
Documentation/arm/microchip.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm/microchip.rst b/Documentation/arm/microchip.rst
index c9a44c98e868..1adf53dfc494 100644
--- a/Documentation/arm/microchip.rst
+++ b/Documentation/arm/microchip.rst
@@ -103,7 +103,7 @@ the Microchip website: http://www.microchip.com.
* Datasheet
- http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet.pdf
+ http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet_B.pdf
* ARM Cortex-A5 + NEON based SoCs
- sama5d4 family
@@ -167,7 +167,7 @@ the Microchip website: http://www.microchip.com.
* Datasheet
- http://ww1.microchip.com/downloads/en/DeviceDoc/60001527A.pdf
+ http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Data-Sheet-DS60001527D.pdf
Linux kernel information
--
2.17.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 v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Andy Shevchenko @ 2019-08-19 15:07 UTC (permalink / raw)
To: Wei Xu
Cc: Salil Mehta, jinying, Tangkunshan, Liguozhu (Kenneth),
Linus Walleij, John Garry, Rafael J. Wysocki,
Linux Kernel Mailing List, Shameerali Kolothum Thodi, Linuxarm,
open list:GPIO SUBSYSTEM, huangdaode, Jonathan Cameron,
Shiju Jose, Mika Westerberg, Zhangyi ac, linux-arm Mailing List,
Len Brown
In-Reply-To: <1566221225-5170-1-git-send-email-xuwei5@hisilicon.com>
On Mon, Aug 19, 2019 at 4:29 PM Wei Xu <xuwei5@hisilicon.com> wrote:
>
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
>
> Otherwise it will be failed to register interruption for the ACPI case.
> Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
> after gpiochip_add_irqchip but at that time the acpi data has not been
> attached yet.
>
> Tested with below steps:
>
> qemu-system-aarch64 \
> -machine virt,gic-version=3 -cpu cortex-a57 \
> -m 1G,maxmem=4G,slots=4 \
> -kernel Image -initrd rootfs.cpio.gz \
> -net none -nographic \
> -bios QEMU_EFI.fd \
> -append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
>
> The pl061 interruption is missed and the following output is not in the
> /proc/interrupts on the v5.3-rc4 compared with the v5.2.0-rc7.
>
> 43: 0 ARMH0061:00 3 Edge ACPI:Event
The proper fix is to revert the culprit since we call
acpi_gpiochip_request_interrupts() for all controllers.
Linus, please re-do the approach with IRQ handling, it seems broadly
regress with ACPI enabled platforms.
--
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 ARM] selftests, arm64: fix uninitialized symbol in tags_test.c
From: Will Deacon @ 2019-08-19 15:03 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mark Rutland, kvm, Christian Koenig, Szabolcs Nagy,
Catalin Marinas, Will Deacon, dri-devel, Kostya Serebryany,
Khalid Aziz, Lee Smith, linux-kselftest, Vincenzo Frascino,
Jacob Bramley, Leon Romanovsky, linux-rdma, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov, Dave Martin,
Evgeniy Stepanov, linux-media, Kees Cook, Ruben Ayrapetyan,
Kevin Brodsky, Alex Williamson, Mauro Carvalho Chehab,
linux-arm-kernel, linux-mm, Greg Kroah-Hartman, Felix Kuehling,
linux-kernel, Jens Wiklander, Dan Carpenter, Ramana Radhakrishnan,
Alexander Deucher, Andrew Morton, enh, Robin Murphy, Yishai Hadas,
Luc Van Oostenryck
In-Reply-To: <00eb8ba84205c59cac01b1b47615116a461c302c.1566220355.git.andreyknvl@google.com>
On Mon, Aug 19, 2019 at 03:14:42PM +0200, Andrey Konovalov wrote:
> Fix tagged_ptr not being initialized when TBI is not enabled.
>
> Dan Carpenter <dan.carpenter@oracle.com>
Guessing this was Reported-by, or has Dan introduced his own tag now? ;)
Got a link to the report?
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] arm64: kasan: fix phys_to_virt() false positive on tag-based kasan
From: Mark Rutland @ 2019-08-19 15:03 UTC (permalink / raw)
To: Andrey Konovalov, Andrey Ryabinin, Will Deacon
Cc: Walter Wu, wsd_upstream, Catalin Marinas, Will Deacon, LKML,
kasan-dev, Alexander Potapenko, Linux ARM, Matthias Brugger,
linux-mediatek, Andrew Morton, Dmitry Vyukov
In-Reply-To: <CAAeHK+w7cTGN8SgWQs0bPjPOrizqfUoMnJWTvUkCqv17Qt=3oQ@mail.gmail.com>
On Mon, Aug 19, 2019 at 04:05:22PM +0200, Andrey Konovalov wrote:
> On Mon, Aug 19, 2019 at 3:34 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote:
> > > On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
> > > > On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
> > > > > __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address,
> > > > > but it will modify pointer tag into 0xff, so there is a false positive.
> > > > >
> > > > > When enable tag-based kasan, phys_to_virt() function need to rewrite
> > > > > its original pointer tag in order to avoid kasan report an incorrect
> > > > > memory corruption.
> > > >
> > > > Hmm. Which tree did you see this on? We've recently queued a load of fixes
> > > > in this area, but I /thought/ they were only needed after the support for
> > > > 52-bit virtual addressing in the kernel.
> > >
> > > I'm seeing similar issues in the virtio blk code (splat below), atop of
> > > the arm64 for-next/core branch. I think this is a latent issue, and
> > > people are only just starting to test with KASAN_SW_TAGS.
> > >
> > > It looks like the virtio blk code will round-trip a SLUB-allocated pointer from
> > > virt->page->virt, losing the per-object tag in the process.
> > >
> > > Our page_to_virt() seems to get a per-page tag, but this only makes
> > > sense if you're dealing with the page allocator, rather than something
> > > like SLUB which carves a page into smaller objects giving each object a
> > > distinct tag.
> > >
> > > Any round-trip of a pointer from SLUB is going to lose the per-object
> > > tag.
> >
> > Urgh, I wonder how this is supposed to work?
> >
> > If we end up having to check the KASAN shadow for *_to_virt(), then why
> > do we need to store anything in the page flags at all? Andrey?
>
> As per 2813b9c0 ("kasan, mm, arm64: tag non slab memory allocated via
> pagealloc") we should only save a non-0xff tag in page flags for non
> slab pages.
>
> Could you share your .config so I can reproduce this?
I wrote a test (below) to do so. :)
It fires with arm64 defconfig, + CONFIG_TEST_KASAN=m.
With Andrey Ryabinin's patch it works as expected with no KASAN splats
for the two new test cases.
Thanks,
Mark.
---->8----
From 7e8569b558fca21ad4e80fddae659591bc84ce1f Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Mon, 19 Aug 2019 15:39:32 +0100
Subject: [PATCH] lib/test_kasan: add roundtrip tests
In several places we needs to be able to operate on pointers which have
gone via a roundtrip:
virt -> {phys,page} -> virt
With KASAN_SW_TAGS, we can't preserve the tag for SLUB objects, and the
{phys,page} -> virt conversion will use KASAN_TAG_KERNEL.
This patch adds tests to ensure that this works as expected, without
false positives.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Will Deacon <will.deacon@arm.com>
---
lib/test_kasan.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index b63b367a94e8..cf7b93f0d90c 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -19,6 +19,8 @@
#include <linux/string.h>
#include <linux/uaccess.h>
+#include <asm/page.h>
+
/*
* Note: test functions are marked noinline so that their names appear in
* reports.
@@ -337,6 +339,42 @@ static noinline void __init kmalloc_uaf2(void)
kfree(ptr2);
}
+static noinline void __init kfree_via_page(void)
+{
+ char *ptr;
+ size_t size = 8;
+ struct page *page;
+ unsigned long offset;
+
+ pr_info("invalid-free false positive (via page)\n");
+ ptr = kmalloc(size, GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ page = virt_to_page(ptr);
+ offset = offset_in_page(ptr);
+ kfree(page_address(page) + offset);
+}
+
+static noinline void __init kfree_via_phys(void)
+{
+ char *ptr;
+ size_t size = 8;
+ phys_addr_t phys;
+
+ pr_info("invalid-free false positive (via phys)\n");
+ ptr = kmalloc(size, GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ phys = virt_to_phys(ptr);
+ kfree(phys_to_virt(phys));
+}
+
static noinline void __init kmem_cache_oob(void)
{
char *p;
@@ -737,6 +775,8 @@ static int __init kmalloc_tests_init(void)
kmalloc_uaf();
kmalloc_uaf_memset();
kmalloc_uaf2();
+ kfree_via_page();
+ kfree_via_phys();
kmem_cache_oob();
memcg_accounted_kmem_cache();
kasan_stack_oob();
--
2.11.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] efi/arm: fix allocation failure when reserving the kernel base
From: Ard Biesheuvel @ 2019-08-19 14:56 UTC (permalink / raw)
To: Chester Lin
Cc: Juergen Gross, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux-kernel@vger.kernel.org,
linux@armlinux.org.uk, Mike Rapoport, Joey Lee,
geert@linux-m68k.org, ren_guo@c-sky.com, Gary Lin,
akpm@linux-foundation.org, mingo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819075621.GA20595@linux-8mug>
On Mon, 19 Aug 2019 at 11:01, Chester Lin <clin@suse.com> wrote:
>
> Hi Mike and Ard,
>
> On Thu, Aug 15, 2019 at 04:37:39PM +0300, Mike Rapoport wrote:
> > On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> > > (adding Mike)
> > >
> > > On Thu, 15 Aug 2019 at 14:28, Chester Lin <clin@suse.com> wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > > > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > > > > >
> > > > > > Hello Chester,
> > > > > >
> > > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
> > > > > > >
> > > > > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > > > > uncompressed kernel. For example, we got the following error message when
> > > > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > > > > >
> > > > > > > EFI stub: Booting Linux Kernel...
> > > > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > > > > > > EFI stub: ERROR: Failed to relocate kernel
> > > > > > >
> > > > > > > After checking the EFI memory map we found that the first page [0 - 0xfff]
> > > > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > > > > > > set the dram base at 0, which was actually in a reserved region.
> > > > > > >
> > > > > >
> > > > > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > > > > ARM when using the decompressor. The decompressor rounds down its own
> > > > > > base address to a multiple of 128 MB, and assumes the whole area is
> > > > > > available for the decompressed kernel and related data structures.
> > > > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > > > > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > > > > this is fragile). Note that the decompressor does not look at any DT
> > > > > > or EFI provided memory maps *at all*.
> > > > > >
> > > > > > So unfortunately, this is not something we can fix in the kernel, but
> > > > > > we should fix it in the bootloader or in GRUB, so it does not put any
> > > > > > reserved regions in the first 128 MB of memory,
> > > > > >
> > > > >
> > > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > > > > ARM boot protocol docs are unclear about whether this memory should be
> > > > > used or not, but it is no longer used for its original purpose (page
> > > > > tables), and the RPi loader already keeps data there.
> > > > >
> > > > > Can you check whether the following patch works for you?
> > > > >
> > > > > diff --git a/drivers/firmware/efi/libstub/Makefile
> > > > > b/drivers/firmware/efi/libstub/Makefile
> > > > > index 0460c7581220..ee0661ddb25b 100644
> > > > > --- a/drivers/firmware/efi/libstub/Makefile
> > > > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > > > > string.o random.o \
> > > > >
> > > > > lib-$(CONFIG_ARM) += arm32-stub.o
> > > > > lib-$(CONFIG_ARM64) += arm64-stub.o
> > > > > +CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > >
> > > > > #
> > > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > index e8f7aefb6813..66ff0c8ec269 100644
> > > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > @@ -204,7 +204,7 @@ efi_status_t
> > > > > handle_kernel_image(efi_system_table_t *sys_table,
> > > > > * loaded. These assumptions are made by the decompressor,
> > > > > * before any memory map is available.
> > > > > */
> > > > > - dram_base = round_up(dram_base, SZ_128M);
> > > > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;
> > > > >
> > > > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
> > > > > reserve_size);
> > > > >
> > > >
> > > > I tried your patch on rpi2 and got the following panic. Just a reminder that I
> > > > have replaced some log messages with "......" since it might be too long to
> > > > post all.
> > > >
> > >
> > > OK. Good to know that this change helps you to get past the EFI stub boot issue.
> > >
> > > > In this case the kernel failed to reserve cma, which should hit the issue of
> > > > memblock_limit=0x1000 as I had mentioned in my patch description. The first
> > > > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> > > > with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> > > > was extremely low. That's why I expand the first reservation from 1 PAGESIZE to
> > > > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> > > > if any suggestion, thank you.
> >
> >
> > > This looks like it is a separate issue. The memblock/cma code should
> > > not choke on a reserved page of memory at 0x0.
> > >
> > > Perhaps Russell or Mike (cc'ed) have an idea how to address this?
> >
> > Presuming that the last memblock dump comes from the end of
> > arm_memblock_init() with the this memory map
> >
> > memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> > memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> > memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> > memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
> >
> > adjust_lowmem_bounds() will set the memblock_limit (and respectively global
> > memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
> > happily fail.
> >
> > I believe that the assumption for memblock_limit calculations was that the
> > first bank has several megs at least.
> >
> > I wonder if this hack would help:
> >
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index d9a0038..948e5b9 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
> > * allocated when mapping the start of bank 0, which
> > * occurs before any free memory is mapped.
> > */
> > - if (!memblock_limit) {
> > + if (memblock_limit < PMD_SIZE) {
> > if (!IS_ALIGNED(block_start, PMD_SIZE))
> > memblock_limit = block_start;
> > else if (!IS_ALIGNED(block_end, PMD_SIZE))
> >
>
> I applied this patch as well and it works well on rpi-2 model B.
>
Thanks, Chester, that is good to know.
However, afaict, this only affects systems where physical memory
starts at address 0x0, so I think we need a better fix.
I know Mike has been looking into the NOMAP stuff lately, and your
original patch contains a hunk that makes this code (?) disregard
nomap memblocks. That might be a better approach.
_______________________________________________
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 v7 0/9] drm: cec: convert DRM drivers to the new notifier API
From: Hans Verkuil @ 2019-08-19 14:55 UTC (permalink / raw)
To: Neil Armstrong, Dariusz Marcinkiewicz, dri-devel, linux-media
Cc: Kate Stewart, Daniel Vetter, linux-kernel, Hans Verkuil,
Dhinakaran Pandiyan, Sam Ravnborg, linux-samsung-soc,
David Francis, amd-gfx, Jani Nikula, Jerry (Fangzhi) Zuo,
linux-arm-kernel, nouveau, Jonas Karlman, Leo Li, intel-gfx,
Russell King, Sean Paul, Rodrigo Vivi, linux-tegra,
Thomas Gleixner, Allison Randal, Thomas Lim, Jernej Skrabec,
Greg Kroah-Hartman, Douglas Anderson, Manasi Navare, Alex Deucher,
Colin Ian King, Enrico Weigelt, Laurent Pinchart
In-Reply-To: <ad2a4af0-aeff-a81e-7885-7e9fc3c5cf90@baylibre.com>
On 8/19/19 4:48 PM, Neil Armstrong wrote:
> Hi Dariusz, Hans,
>
> I can apply the dw-hdmi patches if necessary.
I'd appreciate it if you can do that.
Thanks,
Hans
>
> Neil
>
> On 19/08/2019 11:38, Hans Verkuil wrote:
>> Hi all,
>>
>> The patches in this series can be applied independently from each other.
>>
>> If you maintain one of these drivers and you want to merge it for v5.4
>> yourself, then please do so and let me know. If you prefer I commit it
>> to drm-misc, then please review and (hopefully) Ack the patch.
>>
>> I would really like to get this in for v5.4 so I can get the userspace
>> bits in for v5.4 as well through the media subsystem.
>>
>> Dariusz, can you post a v7.1 for patch 5/9 fixing the typo?
>>
>> Thanks!
>>
>> Hans
>>
>> On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
>>> This series updates DRM drivers to use new CEC notifier API.
>>>
>>> Changes since v6:
>>> Made CEC notifiers' registration and de-registration symmetric
>>> in tda998x and dw-hdmi drivers. Also, accidentally dropped one
>>> patch in v6 (change to drm_dp_cec), brought it back now.
>>> Changes since v5:
>>> Fixed a warning about a missing comment for a new member of
>>> drm_dp_aux_cec struct. Sending to a wider audience,
>>> including maintainers of respective drivers.
>>> Changes since v4:
>>> Addressing review comments.
>>> Changes since v3:
>>> Updated adapter flags in dw-hdmi-cec.
>>> Changes since v2:
>>> Include all DRM patches from "cec: improve notifier support,
>>> add connector info connector info" series.
>>> Changes since v1:
>>> Those patches delay creation of notifiers until respective
>>> connectors are constructed. It seems that those patches, for a
>>> couple of drivers, by adding the delay, introduce a race between
>>> notifiers' creation and the IRQs handling threads - at least I
>>> don't see anything obvious in there that would explicitly forbid
>>> such races to occur. v2 adds a write barrier to make sure IRQ
>>> threads see the notifier once it is created (replacing the
>>> WRITE_ONCE I put in v1). The best thing to do here, I believe,
>>> would be not to have any synchronization and make sure that an IRQ
>>> only gets enabled after the notifier is created.
>>> Dariusz Marcinkiewicz (9):
>>> drm_dp_cec: add connector info support.
>>> drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
>>> dw-hdmi-cec: use cec_notifier_cec_adap_(un)register
>>> tda9950: use cec_notifier_cec_adap_(un)register
>>> drm: tda998x: use cec_notifier_conn_(un)register
>>> drm: sti: use cec_notifier_conn_(un)register
>>> drm: tegra: use cec_notifier_conn_(un)register
>>> drm: dw-hdmi: use cec_notifier_conn_(un)register
>>> drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
>>>
>>> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++---
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++------
>>> drivers/gpu/drm/drm_dp_cec.c | 25 ++++++----
>>> drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++++++------
>>> drivers/gpu/drm/i2c/tda9950.c | 12 ++---
>>> drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++++++++++-----
>>> drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
>>> drivers/gpu/drm/i915/display/intel_hdmi.c | 13 ++++--
>>> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +-
>>> drivers/gpu/drm/sti/sti_hdmi.c | 19 +++++---
>>> drivers/gpu/drm/tegra/output.c | 28 ++++++++---
>>> include/drm/drm_dp_helper.h | 17 ++++---
>>> 13 files changed, 155 insertions(+), 94 deletions(-)
>>>
>>
>
_______________________________________________
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 01/12] irqchip/gic: Rework gic_configure_irq to take the full ICFGR base
From: Marc Zyngier @ 2019-08-19 14:53 UTC (permalink / raw)
To: Zenghui Yu
Cc: Jason Cooper, Lokesh Vutla, John Garry, linux-kernel,
Shameerali Kolothum Thodi, Rob Herring, linux-arm-kernel,
Thomas Gleixner, Julien Thierry
In-Reply-To: <a601236c-8128-ca7a-667f-12a4b7cefb89@huawei.com>
On 19/08/2019 15:26, Zenghui Yu wrote:
> Hi Marc,
>
> On 2019/8/6 18:01, Marc Zyngier wrote:
>> gic_configure_irq is currently passed the (re)distributor address,
>> to which it applies an a fixed offset to get to the configuration
>> registers. This offset is constant across all GICs, or rather it was
>> until to v3.1...
>>
>> An easy way out is for the individual drivers to pass the base
>> address of the configuration register for the considered interrupt.
>> At the same time, move part of the error handling back to the
>> individual drivers, as things are about to change on that front.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>> drivers/irqchip/irq-gic-common.c | 14 +++++---------
>> drivers/irqchip/irq-gic-v3.c | 11 ++++++++++-
>> drivers/irqchip/irq-gic.c | 10 +++++++++-
>> drivers/irqchip/irq-hip04.c | 7 ++++++-
>> 4 files changed, 30 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>> index b0a8215a13fc..6900b6f0921c 100644
>> --- a/drivers/irqchip/irq-gic-common.c
>> +++ b/drivers/irqchip/irq-gic-common.c
>> @@ -63,7 +63,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
>> * for "irq", depending on "type".
>> */
>> raw_spin_lock_irqsave(&irq_controller_lock, flags);
>> - val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
>> + val = oldval = readl_relaxed(base + confoff);
>> if (type & IRQ_TYPE_LEVEL_MASK)
>> val &= ~confmask;
>> else if (type & IRQ_TYPE_EDGE_BOTH)
>> @@ -83,14 +83,10 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
>> * does not allow us to set the configuration or we are in a
>> * non-secure mode, and hence it may not be catastrophic.
>> */
>> - writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
>> - if (readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val) {
>> - if (WARN_ON(irq >= 32))
>> - ret = -EINVAL;
>
> Since this WARN_ON is dropped, the comment above should also be updated.
> But what is the reason for deleting it? (It may give us some points
> when we fail to set type for SPIs.)
The core code already warns in the case where irq_set_type() fails, and
the duplication of warnings is pretty superfluous.
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 v7 0/9] drm: cec: convert DRM drivers to the new notifier API
From: Neil Armstrong @ 2019-08-19 14:48 UTC (permalink / raw)
To: Hans Verkuil, Dariusz Marcinkiewicz, dri-devel, linux-media
Cc: Kate Stewart, Daniel Vetter, linux-kernel, Hans Verkuil,
Dhinakaran Pandiyan, Sam Ravnborg, linux-samsung-soc,
David Francis, amd-gfx, Jani Nikula, Jerry (Fangzhi) Zuo,
linux-arm-kernel, nouveau, Jonas Karlman, Leo Li, intel-gfx,
Russell King, Sean Paul, Rodrigo Vivi, linux-tegra,
Thomas Gleixner, Allison Randal, Thomas Lim, Jernej Skrabec,
Greg Kroah-Hartman, Douglas Anderson, Manasi Navare, Alex Deucher,
Colin Ian King, Enrico Weigelt, Laurent Pinchart
In-Reply-To: <42c7ef3c-b7e5-8c63-c7c2-bfc6c56100c6@xs4all.nl>
Hi Dariusz, Hans,
I can apply the dw-hdmi patches if necessary.
Neil
On 19/08/2019 11:38, Hans Verkuil wrote:
> Hi all,
>
> The patches in this series can be applied independently from each other.
>
> If you maintain one of these drivers and you want to merge it for v5.4
> yourself, then please do so and let me know. If you prefer I commit it
> to drm-misc, then please review and (hopefully) Ack the patch.
>
> I would really like to get this in for v5.4 so I can get the userspace
> bits in for v5.4 as well through the media subsystem.
>
> Dariusz, can you post a v7.1 for patch 5/9 fixing the typo?
>
> Thanks!
>
> Hans
>
> On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
>> This series updates DRM drivers to use new CEC notifier API.
>>
>> Changes since v6:
>> Made CEC notifiers' registration and de-registration symmetric
>> in tda998x and dw-hdmi drivers. Also, accidentally dropped one
>> patch in v6 (change to drm_dp_cec), brought it back now.
>> Changes since v5:
>> Fixed a warning about a missing comment for a new member of
>> drm_dp_aux_cec struct. Sending to a wider audience,
>> including maintainers of respective drivers.
>> Changes since v4:
>> Addressing review comments.
>> Changes since v3:
>> Updated adapter flags in dw-hdmi-cec.
>> Changes since v2:
>> Include all DRM patches from "cec: improve notifier support,
>> add connector info connector info" series.
>> Changes since v1:
>> Those patches delay creation of notifiers until respective
>> connectors are constructed. It seems that those patches, for a
>> couple of drivers, by adding the delay, introduce a race between
>> notifiers' creation and the IRQs handling threads - at least I
>> don't see anything obvious in there that would explicitly forbid
>> such races to occur. v2 adds a write barrier to make sure IRQ
>> threads see the notifier once it is created (replacing the
>> WRITE_ONCE I put in v1). The best thing to do here, I believe,
>> would be not to have any synchronization and make sure that an IRQ
>> only gets enabled after the notifier is created.
>> Dariusz Marcinkiewicz (9):
>> drm_dp_cec: add connector info support.
>> drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
>> dw-hdmi-cec: use cec_notifier_cec_adap_(un)register
>> tda9950: use cec_notifier_cec_adap_(un)register
>> drm: tda998x: use cec_notifier_conn_(un)register
>> drm: sti: use cec_notifier_conn_(un)register
>> drm: tegra: use cec_notifier_conn_(un)register
>> drm: dw-hdmi: use cec_notifier_conn_(un)register
>> drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
>>
>> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++------
>> drivers/gpu/drm/drm_dp_cec.c | 25 ++++++----
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++++++------
>> drivers/gpu/drm/i2c/tda9950.c | 12 ++---
>> drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++++++++++-----
>> drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
>> drivers/gpu/drm/i915/display/intel_hdmi.c | 13 ++++--
>> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +-
>> drivers/gpu/drm/sti/sti_hdmi.c | 19 +++++---
>> drivers/gpu/drm/tegra/output.c | 28 ++++++++---
>> include/drm/drm_dp_helper.h | 17 ++++---
>> 13 files changed, 155 insertions(+), 94 deletions(-)
>>
>
_______________________________________________
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] iommu/arm-smmu: Break insecure users by disabling bypass by default
From: Will Deacon @ 2019-08-19 14:48 UTC (permalink / raw)
To: Thierry Reding
Cc: Marc Gonzalez, Joerg Roedel, Will Deacon, Douglas Anderson,
Jon Hunter, linux-tegra, Robin Murphy, Linux ARM
In-Reply-To: <20190819133327.GA23089@ulmo>
On Mon, Aug 19, 2019 at 03:33:27PM +0200, Thierry Reding wrote:
> On Mon, Aug 19, 2019 at 01:09:18PM +0100, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 01:28:56PM +0200, Thierry Reding wrote:
> > > Perhaps an alternative would be to add a property to the SMMU node that
> > > lists a set of stream IDs for which to enable bypass by default. We
> > > could let the firmware set that when the display hardware has been set
> > > up. That way when the kernel boots we can keep scanning from the
> > > reserved memory and the ARM SMMU driver would not disable bypass for the
> > > display hardware. Only when the display hardware is actually attached to
> > > the IOMMU domain, and the 1:1 mappings have been created would bypass be
> > > disabled, and at that point there should be no SMMU faults anymore, so
> > > we have cleanly transitioned to the kernel.
> > >
> > > Any thoughts?
> >
> > There is currently an extension to IORT under discussion which should
> > address this problem, so it would make a lot of sense for the DT solution
> > to follow the same approach. I think it will end up being along the lines
> > that you suggest, although we won't just enable bypass because that leaves
> > memory wide open if the device driver doesn't probe and it also creates
> > an issue because device attach typically happens before the endpoint
> > driver has probed.
> >
> > So the flow would look something like:
> >
> > - Firmware describes a physical region of memory which must be
> > reserved by the OS.
> >
> > - Additionally, firmware describes a master -> reserved memory
> > linkage as part of the IOMMU description.
> >
> > - When the IOMMU probes, these reserved memory regions will be
> > mapped 1:1 for the relevant master.
> >
> > This is similar to RMRR on x86, except that the mappings are intended to
> > be less rigid and can be torn down if the endpoint driver decides to do
> > that or for things like device passthrough.
> >
> > If we get that working, we should update our booting.txt so that DMA is
> > allowed during boot in the limited cases which this covers.
>
> that sounds very interesting. Is this extension being publicly
> discussed? If so, do you have any pointers for me to read up on this?
Sorry, I don't think it's public :(
> As for device tree, I wonder if perhaps we can achieve this without going
> through extra properties. We could, for example, just do a "reverse
> lookup" of IOMMU masters by walking the device tree and looking for nodes
> that link to an ARM SMMU in their iommus property. Granted, that's not
> going to be very efficient, but it would remove the need to duplicate
> information in DT. It's also going to be a one-time cost, so perhaps it
> would be negligible.
If we can get by with extending the iommu-map entries for the masters,
that would certainly be the neatest imo. Sounds like it's worth a quick
hack, if nothing else.
> I'm happy to help out with hashing out or implementing something on the
> DT side of things. I don't currently have access to any systems with
> ACPI, but I've got a bunch of systems that are DT based and that I would
> like to see this implemented on.
Oh, I'm certainly not saying we should hold the DT changes until the ACPI
side is sorted out, just that we should avoid divergence where we can.
Hopefully my explanation above should be sufficient for that. If you hack
something up that works for DT, I'd be happy to review it.
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 v2] arm: dts: rockchip: fix vcc_host_5v regulator for usb3 host
From: Heiko Stuebner @ 2019-08-19 14:43 UTC (permalink / raw)
To: Kever Yang
Cc: Mark Rutland, devicetree, Jonas Karlman, Katsuhiro Suzuki,
linux-kernel, linux-rockchip, Chen-Yu Tsai, Rob Herring,
Tomohiro Mayama, linux-arm-kernel
In-Reply-To: <208c56e1-bfe0-a982-927d-bdddc3116631@rock-chips.com>
Hi Kever,
Am Montag, 19. August 2019, 02:29:31 CEST schrieb Kever Yang:
> Hi Heiko,
>
> On 2019/8/16 下午8:24, Heiko Stuebner wrote:
> > Hi Kever, TL,
> >
> > [added TL Lim for clarification]
> >
> > Am Donnerstag, 15. August 2019, 10:12:52 CEST schrieb Kever Yang:
> >> According to rock64 schemetic V2 and V3, the VCC_HOST_5V output is
> >> controlled by USB_20_HOST_DRV, which is the same as VCC_HOST1_5V.
> > The v1 schematics I have do reference the GPIO0_A0 as controlling this
> > supply, so the big question would be how to handle the different versions.
> >
> > Because adding this would probably break v1 boards in this function.
> >
> > @TL: where v1 boards also sold or were they only used during development?
>
>
> I have check this with TL when I make this patch, the V1 hardware was
> never sold and only V2/V3
>
> are available on the market.
Thanks for clearing this up. I've applied this patch for 5.4 now.
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] arm64: kasan: fix phys_to_virt() false positive on tag-based kasan
From: Will Deacon @ 2019-08-19 14:43 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, Walter Wu, wsd_upstream, Andrey Konovalov, LKML,
kasan-dev, Andrey Ryabinin, linux-mediatek, Dmitry Vyukov,
Catalin Marinas, Matthias Brugger, Alexander Potapenko,
Andrew Morton, Will Deacon, Linux ARM
In-Reply-To: <1ac7eb3e-156f-218c-8c5a-39a05dd46d55@arm.com>
On Mon, Aug 19, 2019 at 03:35:16PM +0100, Robin Murphy wrote:
> On 19/08/2019 15:22, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 04:05:22PM +0200, Andrey Konovalov wrote:
> > > On Mon, Aug 19, 2019 at 3:34 PM Will Deacon <will@kernel.org> wrote:
> > > >
> > > > On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote:
> > > > > On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
> > > > > > On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
> > > > > > > __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address,
> > > > > > > but it will modify pointer tag into 0xff, so there is a false positive.
> > > > > > >
> > > > > > > When enable tag-based kasan, phys_to_virt() function need to rewrite
> > > > > > > its original pointer tag in order to avoid kasan report an incorrect
> > > > > > > memory corruption.
> > > > > >
> > > > > > Hmm. Which tree did you see this on? We've recently queued a load of fixes
> > > > > > in this area, but I /thought/ they were only needed after the support for
> > > > > > 52-bit virtual addressing in the kernel.
> > > > >
> > > > > I'm seeing similar issues in the virtio blk code (splat below), atop of
> > > > > the arm64 for-next/core branch. I think this is a latent issue, and
> > > > > people are only just starting to test with KASAN_SW_TAGS.
> > > > >
> > > > > It looks like the virtio blk code will round-trip a SLUB-allocated pointer from
> > > > > virt->page->virt, losing the per-object tag in the process.
> > > > >
> > > > > Our page_to_virt() seems to get a per-page tag, but this only makes
> > > > > sense if you're dealing with the page allocator, rather than something
> > > > > like SLUB which carves a page into smaller objects giving each object a
> > > > > distinct tag.
> > > > >
> > > > > Any round-trip of a pointer from SLUB is going to lose the per-object
> > > > > tag.
> > > >
> > > > Urgh, I wonder how this is supposed to work?
> > > >
> > > > If we end up having to check the KASAN shadow for *_to_virt(), then why
> > > > do we need to store anything in the page flags at all? Andrey?
> > >
> > > As per 2813b9c0 ("kasan, mm, arm64: tag non slab memory allocated via
> > > pagealloc") we should only save a non-0xff tag in page flags for non
> > > slab pages.
> >
> > Thanks, that makes sense. Hopefully the patch from Andrey R will solve
> > both of the reported splats, since I'd not realised they were both on the
> > kfree() path.
> >
> > > Could you share your .config so I can reproduce this?
> >
> > This is in the iopgtable code, so it's probably pretty tricky to trigger
> > at runtime unless you have the write IOMMU hardware, unfortunately.
>
> If simply freeing any entry from the l2_tables cache is sufficient, then the
> short-descriptor selftest should do the job, and that ought to run on
> anything (modulo insane RAM layouts).
Ok, so that would be defconfig + CONFIG_IOMMU_IO_PGTABLE_ARMV7S +
CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST + KASAN...
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 0/6] drm+dma: cache support for arm, etc
From: Rob Clark @ 2019-08-19 14:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Kate Stewart, Masayoshi Mizuma, Maciej W. Rozycki, Eric Biggers,
Catalin Marinas, Imre Deak, dri-devel, Chris Wilson,
Masahiro Yamada, Benjamin Gaignard, Mauro Carvalho Chehab,
Will Deacon, Emil Velikov, Deepak Sharma, Michael Ellerman,
Paul Burton, Mike Rapoport, Geert Uytterhoeven,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), Daniel Vetter,
open list:MIPS, Linus Walleij, Robin Murphy,
open list:DRM DRIVER FOR MSM ADRENO GPU, Joerg Roedel,
Arnd Bergmann, Anshuman Khandual, Hauke Mehrtens,
Jesper Dangaard Brouer, Wolfram Sang (Renesas),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Alexios Zavras,
Russell King, Doug Anderson, Thomas Gleixner, Sean Paul,
Allison Randal, Christophe Leroy, Enrico Weigelt, Ard Biesheuvel,
Greg Kroah-Hartman, open list, Rob Clark, Souptick Joarder,
Andrew Morton, open list:DRM DRIVER FOR MSM ADRENO GPU,
christian.koenig
In-Reply-To: <20190819052337.GA16622@lst.de>
On Sun, Aug 18, 2019 at 10:23 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Aug 16, 2019 at 02:04:35PM -0700, Rob Clark wrote:
> > I don't disagree about needing an API to get uncached memory (or
> > ideally just something outside of the linear map). But I think this
> > is a separate problem.
> >
> > What I was hoping for, for v5.4, is a way to stop abusing dma_map/sync
> > for cache ops to get rid of the hack I had to make for v5.3. And also
> > to fix vgem on non-x86. (Unfortunately changing vgem to used cached
> > mappings breaks x86 CI, but fixes CI on arm/arm64..) We can do that
> > without any changes in allocation. There is still the possibility for
> > problems due to cached alias, but that has been a problem this whole
> > time, it isn't something new.
>
> But that just means we start exposing random low-level APIs that
> people will quickly abuse.. In fact even your simple plan to some
> extent already is an abuse of the intent of these functions, and
> it also requires a lot of knowledge in the driver that in the normal
> cases drivers can't know (e.g. is the device dma coherent or not).
I can agree that most drivers should use the higher level APIs.. but
not that we must prevent *all* drivers from using them. Most of what
DMA API is trying to solve doesn't apply to a driver like drm/msm..
which is how we ended up with hacks to try and misuse the high level
API to accomplish what we need.
Perhaps we can protect the prototypes with #ifdef LOWLEVEL_DMA_API /
#endif type thing to make it more obvious to other drivers that it
probably isn't the API they should use?
BR,
-R
_______________________________________________
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] perf cs-etm: Support sample flags 'insn' and 'insnlen'
From: Mathieu Poirier @ 2019-08-19 14:36 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Suzuki K Poulose, Alexander Shishkin, Coresight ML,
Linux Kernel Mailing List, Leo Yan, Namhyung Kim, Robert Walker,
Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <20190819142321.GB29674@kernel.org>
On Mon, 19 Aug 2019 at 08:23, Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
> Em Thu, Aug 15, 2019 at 04:28:54PM +0800, Leo Yan escreveu:
> > The synthetic branch and instruction samples are missed to set
> > instruction related info, thus perf tool fails to display samples with
> > flags '-F,+insn,+insnlen'.
> >
> > CoreSight trace decoder has provided sufficient information to decide
> > the instruction size based on the isa type: A64/A32 instruction are
> > 32-bit size, but one exception is the T32 instruction size, which might
> > be 32-bit or 16-bit.
> >
> > This patch handles for these cases and it reads the instruction values
> > from DSO file; thus can support flags '-F,+insn,+insnlen'.
>
> Mathieu, can I have your Acked-by/Reviewed-by?
Yes, as soon as I have the opportunity to test it.
>
> - Arnaldo
>
> > Before:
> >
> > # perf script -F,insn,insnlen,ip,sym
> > 0 [unknown] ilen: 0
> > ffff97174044 _start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> > ffff97174938 _dl_start ilen: 0
> >
> > [...]
> >
> > After:
> >
> > # perf script -F,insn,insnlen,ip,sym
> > 0 [unknown] ilen: 0
> > ffff97174044 _start ilen: 4 insn: 2f 02 00 94
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> > ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> >
> > [...]
> >
> > Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
> > Cc: Mike Leach <mike.leach@linaro.org>
> > Cc: Robert Walker <robert.walker@arm.com>
> > Cc: coresight@lists.linaro.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> > tools/perf/util/cs-etm.c | 35 ++++++++++++++++++++++++++++++++++-
> > 1 file changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > index ed6f7fd5b90b..b3a5daaf1a8f 100644
> > --- a/tools/perf/util/cs-etm.c
> > +++ b/tools/perf/util/cs-etm.c
> > @@ -1076,6 +1076,35 @@ bool cs_etm__etmq_is_timeless(struct cs_etm_queue *etmq)
> > return !!etmq->etm->timeless_decoding;
> > }
> >
> > +static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
> > + u64 trace_chan_id,
> > + const struct cs_etm_packet *packet,
> > + struct perf_sample *sample)
> > +{
> > + /*
> > + * It's pointless to read instructions for the CS_ETM_DISCONTINUITY
> > + * packet, so directly bail out with 'insn_len' = 0.
> > + */
> > + if (packet->sample_type == CS_ETM_DISCONTINUITY) {
> > + sample->insn_len = 0;
> > + return;
> > + }
> > +
> > + /*
> > + * T32 instruction size might be 32-bit or 16-bit, decide by calling
> > + * cs_etm__t32_instr_size().
> > + */
> > + if (packet->isa == CS_ETM_ISA_T32)
> > + sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
> > + sample->ip);
> > + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > + else
> > + sample->insn_len = 4;
> > +
> > + cs_etm__mem_access(etmq, trace_chan_id, sample->ip,
> > + sample->insn_len, (void *)sample->insn);
> > +}
> > +
> > static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
> > struct cs_etm_traceid_queue *tidq,
> > u64 addr, u64 period)
> > @@ -1097,9 +1126,10 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
> > sample.period = period;
> > sample.cpu = tidq->packet->cpu;
> > sample.flags = tidq->prev_packet->flags;
> > - sample.insn_len = 1;
> > sample.cpumode = event->sample.header.misc;
> >
> > + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
> > +
> > if (etm->synth_opts.last_branch) {
> > cs_etm__copy_last_branch_rb(etmq, tidq);
> > sample.branch_stack = tidq->last_branch;
> > @@ -1159,6 +1189,9 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
> > sample.flags = tidq->prev_packet->flags;
> > sample.cpumode = event->sample.header.misc;
> >
> > + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->prev_packet,
> > + &sample);
> > +
> > /*
> > * perf report cannot handle events without a branch stack
> > */
> > --
> > 2.17.1
>
> --
>
> - Arnaldo
_______________________________________________
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: kasan: fix phys_to_virt() false positive on tag-based kasan
From: Robin Murphy @ 2019-08-19 14:35 UTC (permalink / raw)
To: Will Deacon, Andrey Konovalov
Cc: Mark Rutland, Walter Wu, wsd_upstream, Catalin Marinas,
Will Deacon, LKML, kasan-dev, linux-mediatek, Dmitry Vyukov,
Andrey Ryabinin, Matthias Brugger, Alexander Potapenko,
Andrew Morton, Linux ARM
In-Reply-To: <20190819142238.2jobs6vabkp2isg2@willie-the-truck>
On 19/08/2019 15:22, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 04:05:22PM +0200, Andrey Konovalov wrote:
>> On Mon, Aug 19, 2019 at 3:34 PM Will Deacon <will@kernel.org> wrote:
>>>
>>> On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote:
>>>> On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
>>>>> On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
>>>>>> __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address,
>>>>>> but it will modify pointer tag into 0xff, so there is a false positive.
>>>>>>
>>>>>> When enable tag-based kasan, phys_to_virt() function need to rewrite
>>>>>> its original pointer tag in order to avoid kasan report an incorrect
>>>>>> memory corruption.
>>>>>
>>>>> Hmm. Which tree did you see this on? We've recently queued a load of fixes
>>>>> in this area, but I /thought/ they were only needed after the support for
>>>>> 52-bit virtual addressing in the kernel.
>>>>
>>>> I'm seeing similar issues in the virtio blk code (splat below), atop of
>>>> the arm64 for-next/core branch. I think this is a latent issue, and
>>>> people are only just starting to test with KASAN_SW_TAGS.
>>>>
>>>> It looks like the virtio blk code will round-trip a SLUB-allocated pointer from
>>>> virt->page->virt, losing the per-object tag in the process.
>>>>
>>>> Our page_to_virt() seems to get a per-page tag, but this only makes
>>>> sense if you're dealing with the page allocator, rather than something
>>>> like SLUB which carves a page into smaller objects giving each object a
>>>> distinct tag.
>>>>
>>>> Any round-trip of a pointer from SLUB is going to lose the per-object
>>>> tag.
>>>
>>> Urgh, I wonder how this is supposed to work?
>>>
>>> If we end up having to check the KASAN shadow for *_to_virt(), then why
>>> do we need to store anything in the page flags at all? Andrey?
>>
>> As per 2813b9c0 ("kasan, mm, arm64: tag non slab memory allocated via
>> pagealloc") we should only save a non-0xff tag in page flags for non
>> slab pages.
>
> Thanks, that makes sense. Hopefully the patch from Andrey R will solve
> both of the reported splats, since I'd not realised they were both on the
> kfree() path.
>
>> Could you share your .config so I can reproduce this?
>
> This is in the iopgtable code, so it's probably pretty tricky to trigger
> at runtime unless you have the write IOMMU hardware, unfortunately.
If simply freeing any entry from the l2_tables cache is sufficient, then
the short-descriptor selftest should do the job, and that ought to run
on anything (modulo insane RAM layouts).
Robin.
_______________________________________________
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 01/12] irqchip/gic: Rework gic_configure_irq to take the full ICFGR base
From: Zenghui Yu @ 2019-08-19 14:26 UTC (permalink / raw)
To: Marc Zyngier
Cc: Jason Cooper, Lokesh Vutla, John Garry, linux-kernel,
Shameerali Kolothum Thodi, Rob Herring, linux-arm-kernel,
Thomas Gleixner, Julien Thierry
In-Reply-To: <20190806100121.240767-2-maz@kernel.org>
Hi Marc,
On 2019/8/6 18:01, Marc Zyngier wrote:
> gic_configure_irq is currently passed the (re)distributor address,
> to which it applies an a fixed offset to get to the configuration
> registers. This offset is constant across all GICs, or rather it was
> until to v3.1...
>
> An easy way out is for the individual drivers to pass the base
> address of the configuration register for the considered interrupt.
> At the same time, move part of the error handling back to the
> individual drivers, as things are about to change on that front.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/irqchip/irq-gic-common.c | 14 +++++---------
> drivers/irqchip/irq-gic-v3.c | 11 ++++++++++-
> drivers/irqchip/irq-gic.c | 10 +++++++++-
> drivers/irqchip/irq-hip04.c | 7 ++++++-
> 4 files changed, 30 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
> index b0a8215a13fc..6900b6f0921c 100644
> --- a/drivers/irqchip/irq-gic-common.c
> +++ b/drivers/irqchip/irq-gic-common.c
> @@ -63,7 +63,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
> * for "irq", depending on "type".
> */
> raw_spin_lock_irqsave(&irq_controller_lock, flags);
> - val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
> + val = oldval = readl_relaxed(base + confoff);
> if (type & IRQ_TYPE_LEVEL_MASK)
> val &= ~confmask;
> else if (type & IRQ_TYPE_EDGE_BOTH)
> @@ -83,14 +83,10 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
> * does not allow us to set the configuration or we are in a
> * non-secure mode, and hence it may not be catastrophic.
> */
> - writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
> - if (readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val) {
> - if (WARN_ON(irq >= 32))
> - ret = -EINVAL;
Since this WARN_ON is dropped, the comment above should also be updated.
But what is the reason for deleting it? (It may give us some points
when we fail to set type for SPIs.)
Thanks,
zenghui
> - else
> - pr_warn("GIC: PPI%d is secure or misconfigured\n",
> - irq - 16);
> - }
> + writel_relaxed(val, base + confoff);
> + if (readl_relaxed(base + confoff) != val)
> + ret = -EINVAL;
> +
> raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
>
> if (sync_access)
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 96d927f0f91a..b250e69908f8 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -407,6 +407,7 @@ static int gic_set_type(struct irq_data *d, unsigned int type)
> unsigned int irq = gic_irq(d);
> void (*rwp_wait)(void);
> void __iomem *base;
> + int ret;
>
> /* Interrupt configuration for SGIs can't be changed */
> if (irq < 16)
> @@ -425,7 +426,15 @@ static int gic_set_type(struct irq_data *d, unsigned int type)
> rwp_wait = gic_dist_wait_for_rwp;
> }
>
> - return gic_configure_irq(irq, type, base, rwp_wait);
> +
> + ret = gic_configure_irq(irq, type, base + GICD_ICFGR, rwp_wait);
> + if (ret && irq < 32) {
> + /* Misconfigured PPIs are usually not fatal */
> + pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16);
> + ret = 0;
> + }
> +
> + return ret;
> }
>
> static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index e45f45e68720..ab48760acabb 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -291,6 +291,7 @@ static int gic_set_type(struct irq_data *d, unsigned int type)
> {
> void __iomem *base = gic_dist_base(d);
> unsigned int gicirq = gic_irq(d);
> + int ret;
>
> /* Interrupt configuration for SGIs can't be changed */
> if (gicirq < 16)
> @@ -301,7 +302,14 @@ static int gic_set_type(struct irq_data *d, unsigned int type)
> type != IRQ_TYPE_EDGE_RISING)
> return -EINVAL;
>
> - return gic_configure_irq(gicirq, type, base, NULL);
> + ret = gic_configure_irq(gicirq, type, base + GIC_DIST_CONFIG, NULL);
> + if (ret && gicirq < 32) {
> + /* Misconfigured PPIs are usually not fatal */
> + pr_warn("GIC: PPI%d is secure or misconfigured\n", gicirq - 16);
> + ret = 0;
> + }
> +
> + return ret;
> }
>
> static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
> diff --git a/drivers/irqchip/irq-hip04.c b/drivers/irqchip/irq-hip04.c
> index cf705827599c..1626131834a6 100644
> --- a/drivers/irqchip/irq-hip04.c
> +++ b/drivers/irqchip/irq-hip04.c
> @@ -130,7 +130,12 @@ static int hip04_irq_set_type(struct irq_data *d, unsigned int type)
>
> raw_spin_lock(&irq_controller_lock);
>
> - ret = gic_configure_irq(irq, type, base, NULL);
> + ret = gic_configure_irq(irq, type, base + GIC_DIST_CONFIG, NULL);
> + if (ret && irq < 32) {
> + /* Misconfigured PPIs are usually not fatal */
> + pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16);
> + ret = 0;
> + }
>
> raw_spin_unlock(&irq_controller_lock);
>
>
_______________________________________________
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 04/12] irqchip/gic-v3: Add ESPI range support
From: Zenghui Yu @ 2019-08-19 14:25 UTC (permalink / raw)
To: Marc Zyngier
Cc: Jason Cooper, Lokesh Vutla, John Garry, linux-kernel,
Shameerali Kolothum Thodi, Rob Herring, linux-arm-kernel,
Thomas Gleixner, Julien Thierry
In-Reply-To: <20190806100121.240767-5-maz@kernel.org>
Hi Marc,
On 2019/8/6 18:01, Marc Zyngier wrote:
> Add the required support for the ESPI range, which behave exactly like
> the SPIs of old, only with new funky INTIDs.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/irqchip/irq-gic-v3.c | 85 ++++++++++++++++++++++++------
> include/linux/irqchip/arm-gic-v3.h | 17 +++++-
> 2 files changed, 85 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index db3bdedd7241..1ca4dde32034 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -51,13 +51,16 @@ struct gic_chip_data {
> u32 nr_redist_regions;
> u64 flags;
> bool has_rss;
> - unsigned int irq_nr;
> struct partition_desc *ppi_descs[16];
> };
>
> static struct gic_chip_data gic_data __read_mostly;
> static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
>
> +#define GIC_ID_NR (1U << GICD_TYPER_ID_BITS(gic_data.rdists.gicd_typer))
> +#define GIC_LINE_NR GICD_TYPER_SPIS(gic_data.rdists.gicd_typer)
This indicates the maximum SPI INTID that the GIC implementation
supports, should we restrict it to no more than 1020?
ITLinesNumber can be '11111', and I saw the following info on my host:
"GICv3: 992 SPIs implemented"
Thanks,
zenghui
_______________________________________________
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 7/8] parisc: don't set ARCH_NO_COHERENT_DMA_MMAP
From: Christoph Hellwig @ 2019-08-19 14:25 UTC (permalink / raw)
To: James Bottomley
Cc: linux-xtensa, Michal Simek, Vladimir Murzin, linux-parisc,
linux-sh, Takashi Iwai, linuxppc-dev, Helge Deller, x86,
linux-m68k, linux-kernel, iommu, Robin Murphy, Christoph Hellwig,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190815105002.GA30805@lst.de>
Does my explanation from Thursday make sense or is it completely
off? Does the patch description need some update to be less
confusing to those used to different terminology?
On Thu, Aug 15, 2019 at 12:50:02PM +0200, Christoph Hellwig wrote:
> Except for the different naming scheme vs the code this matches my
> assumptions.
>
> In the code we have three cases (and a fourth EISA case mention in
> comments, but not actually implemented as far as I can tell):
>
> arch/parisc/kernel/pci-dma.c says in the top of file comments:
>
> ** AFAIK, all PA7100LC and PA7300LC platforms can use this code.
>
> and the handles two different case. for cpu_type == pcxl or pcxl2
> it maps the memory as uncached for dma_alloc_coherent, and for all
> other cpu types it fails the coherent allocations.
>
> In addition to that there are the ccio and sba iommu drivers, of which
> according to your above comment one is always present for pa8xxx.
>
> Which brings us back to this patch, which ensures that no cacheable
> memory is exported to userspace by removing ->mmap from ccio and sba.
> It then enabled dma_mmap_coherent for the pcxl or pcxl2 case that
> allocates uncached memory, which dma_mmap_coherent does not work
> because dma_alloc_coherent already failed for the !pcxl && !pcxl2
> and thus there is no memory to mmap.
>
> So if the description is too confusing please suggest a better
> one, I'm a little lost between all these code names and product
> names (arch/parisc/include/asm/dma-mapping.h uses yet another set).
---end quoted text---
_______________________________________________
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] perf cs-etm: Support sample flags 'insn' and 'insnlen'
From: Arnaldo Carvalho de Melo @ 2019-08-19 14:23 UTC (permalink / raw)
To: Mathieu Poirier, Leo Yan
Cc: Suzuki K Poulose, Alexander Shishkin, coresight, linux-kernel,
Namhyung Kim, Robert Walker, Jiri Olsa, linux-arm-kernel,
Mike Leach
In-Reply-To: <20190815082854.18191-1-leo.yan@linaro.org>
Em Thu, Aug 15, 2019 at 04:28:54PM +0800, Leo Yan escreveu:
> The synthetic branch and instruction samples are missed to set
> instruction related info, thus perf tool fails to display samples with
> flags '-F,+insn,+insnlen'.
>
> CoreSight trace decoder has provided sufficient information to decide
> the instruction size based on the isa type: A64/A32 instruction are
> 32-bit size, but one exception is the T32 instruction size, which might
> be 32-bit or 16-bit.
>
> This patch handles for these cases and it reads the instruction values
> from DSO file; thus can support flags '-F,+insn,+insnlen'.
Mathieu, can I have your Acked-by/Reviewed-by?
- Arnaldo
> Before:
>
> # perf script -F,insn,insnlen,ip,sym
> 0 [unknown] ilen: 0
> ffff97174044 _start ilen: 0
> ffff97174938 _dl_start ilen: 0
> ffff97174938 _dl_start ilen: 0
> ffff97174938 _dl_start ilen: 0
> ffff97174938 _dl_start ilen: 0
> ffff97174938 _dl_start ilen: 0
> ffff97174938 _dl_start ilen: 0
> ffff97174938 _dl_start ilen: 0
> ffff97174938 _dl_start ilen: 0
>
> [...]
>
> After:
>
> # perf script -F,insn,insnlen,ip,sym
> 0 [unknown] ilen: 0
> ffff97174044 _start ilen: 4 insn: 2f 02 00 94
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
> ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54
>
> [...]
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
> Cc: Mike Leach <mike.leach@linaro.org>
> Cc: Robert Walker <robert.walker@arm.com>
> Cc: coresight@lists.linaro.org
> Cc: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/perf/util/cs-etm.c | 35 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index ed6f7fd5b90b..b3a5daaf1a8f 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -1076,6 +1076,35 @@ bool cs_etm__etmq_is_timeless(struct cs_etm_queue *etmq)
> return !!etmq->etm->timeless_decoding;
> }
>
> +static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
> + u64 trace_chan_id,
> + const struct cs_etm_packet *packet,
> + struct perf_sample *sample)
> +{
> + /*
> + * It's pointless to read instructions for the CS_ETM_DISCONTINUITY
> + * packet, so directly bail out with 'insn_len' = 0.
> + */
> + if (packet->sample_type == CS_ETM_DISCONTINUITY) {
> + sample->insn_len = 0;
> + return;
> + }
> +
> + /*
> + * T32 instruction size might be 32-bit or 16-bit, decide by calling
> + * cs_etm__t32_instr_size().
> + */
> + if (packet->isa == CS_ETM_ISA_T32)
> + sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
> + sample->ip);
> + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> + else
> + sample->insn_len = 4;
> +
> + cs_etm__mem_access(etmq, trace_chan_id, sample->ip,
> + sample->insn_len, (void *)sample->insn);
> +}
> +
> static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
> struct cs_etm_traceid_queue *tidq,
> u64 addr, u64 period)
> @@ -1097,9 +1126,10 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
> sample.period = period;
> sample.cpu = tidq->packet->cpu;
> sample.flags = tidq->prev_packet->flags;
> - sample.insn_len = 1;
> sample.cpumode = event->sample.header.misc;
>
> + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
> +
> if (etm->synth_opts.last_branch) {
> cs_etm__copy_last_branch_rb(etmq, tidq);
> sample.branch_stack = tidq->last_branch;
> @@ -1159,6 +1189,9 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
> sample.flags = tidq->prev_packet->flags;
> sample.cpumode = event->sample.header.misc;
>
> + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->prev_packet,
> + &sample);
> +
> /*
> * perf report cannot handle events without a branch stack
> */
> --
> 2.17.1
--
- Arnaldo
_______________________________________________
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