* Re: [PATCH v3 2/4] kasan: record and print the free track
From: Walter Wu @ 2020-05-18 13:10 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: wsd_upstream, linux-mediatek, LKML, kasan-dev, Linux-MM,
Alexander Potapenko, Matthias Brugger, Andrey Ryabinin, Linux ARM
In-Reply-To: <1589801235.16436.12.camel@mtksdccf07>
On Mon, 2020-05-18 at 19:27 +0800, Walter Wu wrote:
> On Mon, 2020-05-18 at 12:18 +0200, Dmitry Vyukov wrote:
> > On Mon, May 18, 2020 at 8:27 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > >
> > > Move free track from slub alloc meta-data to slub free meta-data in
> > > order to make struct kasan_free_meta size is 16 bytes. It is a good
> > > size because it is the minimal redzone size and a good number of
> > > alignment.
> > >
> > > For free track in generic KASAN, we do the modification in struct
> > > kasan_alloc_meta and kasan_free_meta:
> > > - remove free track from kasan_alloc_meta.
> > > - add free track into kasan_free_meta.
> > >
> > > [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> > >
> > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > Cc: Alexander Potapenko <glider@google.com>
> > > ---
> > > mm/kasan/common.c | 33 ++++++++++-----------------------
> > > mm/kasan/generic.c | 18 ++++++++++++++++++
> > > mm/kasan/kasan.h | 7 +++++++
> > > mm/kasan/report.c | 20 --------------------
> > > mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
> > > 5 files changed, 72 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > > index 8bc618289bb1..6500bc2bb70c 100644
> > > --- a/mm/kasan/common.c
> > > +++ b/mm/kasan/common.c
> > > @@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
> > > return stack_depot_save(entries, nr_entries, flags);
> > > }
> > >
> > > -static inline void set_track(struct kasan_track *track, gfp_t flags)
> > > +void kasan_set_track(struct kasan_track *track, gfp_t flags)
> > > {
> > > track->pid = current->pid;
> > > track->stack = kasan_save_stack(flags);
> > > @@ -249,9 +249,7 @@ void kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
> > > *size += sizeof(struct kasan_alloc_meta);
> > >
> > > /* Add free meta. */
> > > - if (IS_ENABLED(CONFIG_KASAN_GENERIC) &&
> > > - (cache->flags & SLAB_TYPESAFE_BY_RCU || cache->ctor ||
> > > - cache->object_size < sizeof(struct kasan_free_meta))) {
> > > + if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
> >
> > Why do we need to increase object size unconditionally?
> > We only store info in free track when the object is free, so I would
> > assume we still can generally overlap free track and the object
> > itself. We store free track at the same time we use the quarantine
> > link, and the quarantine link was overlapped with the object just
> > fine.
> > With this change we indeed increase object size, which we do not want
> > in general.
> >
>
> If it doesn't add free meta, but we always store free track into the
> object, Is it safe?
>
> >
> > > cache->kasan_info.free_meta_offset = *size;
> > > *size += sizeof(struct kasan_free_meta);
> > > }
> > > @@ -299,24 +297,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
> > > return (void *)object + cache->kasan_info.free_meta_offset;
> > > }
> > >
> > > -
> > > -static void kasan_set_free_info(struct kmem_cache *cache,
> > > - void *object, u8 tag)
> > > -{
> > > - struct kasan_alloc_meta *alloc_meta;
> > > - u8 idx = 0;
> > > -
> > > - alloc_meta = get_alloc_info(cache, object);
> > > -
> > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > - idx = alloc_meta->free_track_idx;
> > > - alloc_meta->free_pointer_tag[idx] = tag;
> > > - alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > -#endif
> > > -
> > > - set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > -}
> > > -
> > > void kasan_poison_slab(struct page *page)
> > > {
> > > unsigned long i;
> > > @@ -396,6 +376,13 @@ void * __must_check kasan_init_slab_obj(struct kmem_cache *cache,
> > > alloc_info = get_alloc_info(cache, object);
> > > __memset(alloc_info, 0, sizeof(*alloc_info));
> > >
> > > + if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
> > > + struct kasan_free_meta *free_info;
> > > +
> > > + free_info = get_free_info(cache, object);
> > > + __memset(free_info, 0, sizeof(*free_info));
> >
> > If we overlap free track with object, this will not be needed as well, right?
> >
I thought about it, I think you are right, because the free track must
be stored when object is free, so even don't clean this meta data. It
doesn't matter.
Thanks for your review. If there are no other problems, I will send next
patch.
Thanks.
>
> Should we not consider those objects which have adding free meta? If
> they exist, then we should init their meta data when object re-allocate.
>
> struct kasan_free_meta {
> struct qlist_node quarantine_link;
> struct kasan_track free_track;
> };
>
>
> > > + }
> > > +
> > > if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
> > > object = set_tag(object,
> > > assign_tag(cache, object, true, false));
> > > @@ -492,7 +479,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
> > > KASAN_KMALLOC_REDZONE);
> > >
> > > if (cache->flags & SLAB_KASAN)
> > > - set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > > + kasan_set_track(&get_alloc_info(cache, object)->alloc_track, flags);
> > >
> > > return set_tag(object, tag);
> > > }
> > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > index 78d8e0a75a8a..988bc095b738 100644
> > > --- a/mm/kasan/generic.c
> > > +++ b/mm/kasan/generic.c
> > > @@ -345,3 +345,21 @@ void kasan_record_aux_stack(void *addr)
> > > alloc_info->rcu_stack[1] = alloc_info->rcu_stack[0];
> > > alloc_info->rcu_stack[0] = kasan_save_stack(GFP_NOWAIT);
> > > }
> > > +
> > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > + void *object, u8 tag)
> > > +{
> > > + struct kasan_free_meta *free_meta;
> > > +
> > > + free_meta = get_free_info(cache, object);
> > > + kasan_set_track(&free_meta->free_track, GFP_NOWAIT);
> > > +}
> > > +
> > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > + void *object, u8 tag)
> > > +{
> > > + struct kasan_free_meta *free_meta;
> > > +
> > > + free_meta = get_free_info(cache, object);
> > > + return &free_meta->free_track;
> > > +}
> > > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > > index 870c5dd07756..87ee3626b8b0 100644
> > > --- a/mm/kasan/kasan.h
> > > +++ b/mm/kasan/kasan.h
> > > @@ -127,6 +127,9 @@ struct kasan_free_meta {
> > > * Otherwise it might be used for the allocator freelist.
> > > */
> > > struct qlist_node quarantine_link;
> > > +#ifdef CONFIG_KASAN_GENERIC
> > > + struct kasan_track free_track;
> > > +#endif
> > > };
> > >
> > > struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
> > > @@ -168,6 +171,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
> > > struct page *kasan_addr_to_page(const void *addr);
> > >
> > > depot_stack_handle_t kasan_save_stack(gfp_t flags);
> > > +void kasan_set_track(struct kasan_track *track, gfp_t flags);
> > > +void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
> > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > + void *object, u8 tag);
> > >
> > > #if defined(CONFIG_KASAN_GENERIC) && \
> > > (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > > index 5ee66cf7e27c..7e9f9f6d5e85 100644
> > > --- a/mm/kasan/report.c
> > > +++ b/mm/kasan/report.c
> > > @@ -159,26 +159,6 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
> > > (void *)(object_addr + cache->object_size));
> > > }
> > >
> > > -static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > - void *object, u8 tag)
> > > -{
> > > - struct kasan_alloc_meta *alloc_meta;
> > > - int i = 0;
> > > -
> > > - alloc_meta = get_alloc_info(cache, object);
> > > -
> > > -#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > - for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > - if (alloc_meta->free_pointer_tag[i] == tag)
> > > - break;
> > > - }
> > > - if (i == KASAN_NR_FREE_STACKS)
> > > - i = alloc_meta->free_track_idx;
> > > -#endif
> > > -
> > > - return &alloc_meta->free_track[i];
> > > -}
> > > -
> > > #ifdef CONFIG_KASAN_GENERIC
> > > static void print_stack(depot_stack_handle_t stack)
> > > {
> > > diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
> > > index 25b7734e7013..201dee5d6ae0 100644
> > > --- a/mm/kasan/tags.c
> > > +++ b/mm/kasan/tags.c
> > > @@ -162,3 +162,40 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
> > > kasan_poison_shadow((void *)addr, size, tag);
> > > }
> > > EXPORT_SYMBOL(__hwasan_tag_memory);
> > > +
> > > +void kasan_set_free_info(struct kmem_cache *cache,
> > > + void *object, u8 tag)
> > > +{
> > > + struct kasan_alloc_meta *alloc_meta;
> > > + u8 idx = 0;
> > > +
> > > + alloc_meta = get_alloc_info(cache, object);
> > > +
> > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > + idx = alloc_meta->free_track_idx;
> > > + alloc_meta->free_pointer_tag[idx] = tag;
> > > + alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
> > > +#endif
> > > +
> > > + kasan_set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
> > > +}
> > > +
> > > +struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> > > + void *object, u8 tag)
> > > +{
> > > + struct kasan_alloc_meta *alloc_meta;
> > > + int i = 0;
> > > +
> > > + alloc_meta = get_alloc_info(cache, object);
> > > +
> > > +#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> > > + for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
> > > + if (alloc_meta->free_pointer_tag[i] == tag)
> > > + break;
> > > + }
> > > + if (i == KASAN_NR_FREE_STACKS)
> > > + i = alloc_meta->free_track_idx;
> > > +#endif
> > > +
> > > + return &alloc_meta->free_track[i];
> > > +}
> > > --
> > > 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PING] [PATCH v2] arm: ptrace: Fix mask for thumb breakpoint hook
From: Fredrik Strupe @ 2020-05-18 13:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, Oleg Nesterov, Russell King
In-Reply-To: <20200413173841.29651-1-fredrik@strupe.net>
call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
(0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
instructions will be masked out. This makes the function match 32-bit
thumb instructions where the second half-word is equal to instr_val,
regardless of the first half-word.
The result in this case is that all undefined 32-bit thumb instructions
with the second half-word equal to de01 (udf #1) work as breakpoints
and will raise a SIGTRAP instead of a SIGILL, instead of just the one
intended 16-bit instruction. An example of such an instruction is
eaa0b650, which is unallocated according to Arm ARM and should raise a
SIGILL, but instead raises a SIGTRAP.
This patch fixes the issue by setting all the bits in instr_mask, which
will still match the intended 16-bit thumb instruction (where the
upper half is always 0), but not any 32-bit thumb instructions.
Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
---
arch/arm/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index b606cded90cd..4cc6a7eff635 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -219,8 +219,8 @@ static struct undef_hook arm_break_hook = {
};
static struct undef_hook thumb_break_hook = {
- .instr_mask = 0xffff,
- .instr_val = 0xde01,
+ .instr_mask = 0xffffffff,
+ .instr_val = 0x0000de01,
.cpsr_mask = PSR_T_BIT,
.cpsr_val = PSR_T_BIT,
.fn = break_trap,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 3/6] arm64: scs: Use 'scs_sp' register alias for x18
From: Mark Rutland @ 2020-05-18 13:13 UTC (permalink / raw)
To: Will Deacon
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Sami Tolvanen, kernel-team, Ard Biesheuvel,
linux-arm-kernel
In-Reply-To: <20200518130335.GC32394@willie-the-truck>
On Mon, May 18, 2020 at 02:03:36PM +0100, Will Deacon wrote:
> On Mon, May 18, 2020 at 12:55:47PM +0100, Mark Rutland wrote:
> > On Fri, May 15, 2020 at 06:27:53PM +0100, Will Deacon wrote:
> > > x18 holds the SCS stack pointer value, so introduce a register alias to
> > > make this easier to read in assembly code.
> > >
> > > Signed-off-by: Will Deacon <will@kernel.org>
> >
> > I scanned through arm64 for all instances of x18, and it looks like
> > you've covered all the relevant uses here. In kvm we save/restore x18 a
> > bunch becasue it might be a platform register, but we do that
> > unconditionally and without knowledge of what it contains, so I think
> > that's fine to leave as-is. Therefore:
> >
> > Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> >
> > As an aside, the comment in entry-ftrace.S is now stale where it says
> > that x18 is safe to clobber. I can send a patch to clean that up, unless
> > you want to do that yourself.
>
> Thanks, I'll fix that up (see below). Also, apologies for typo'ing your
> email address when I sent this out on Friday.
No worries; I'd already forgotten!
>
> Will
>
> --->8
>
> From 7e86208cd6541c1229bc1fcd206596308d1727f8 Mon Sep 17 00:00:00 2001
> From: Will Deacon <will@kernel.org>
> Date: Mon, 18 May 2020 14:01:01 +0100
> Subject: [PATCH] arm64: entry-ftrace.S: Update comment to indicate that x18 is
> live
>
> The Shadow Call Stack pointer is held in x18, so update the ftrace
> entry comment to indicate that it cannot be safely clobbered.
>
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kernel/entry-ftrace.S | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
> index 833d48c9acb5..a338f40e64d3 100644
> --- a/arch/arm64/kernel/entry-ftrace.S
> +++ b/arch/arm64/kernel/entry-ftrace.S
> @@ -23,8 +23,9 @@
> *
> * ... where <entry> is either ftrace_caller or ftrace_regs_caller.
> *
> - * Each instrumented function follows the AAPCS, so here x0-x8 and x19-x30 are
> - * live, and x9-x18 are safe to clobber.
> + * Each instrumented function follows the AAPCS, so here x0-x8 and x18-x30 are
> + * live (x18 holds the Shadow Call Stack pointer), and x9-x17 are safe to
> + * clobber.
I'd have called out x18 a bit more specifically:
| Each instrumented function follows the AAPCS, so here x0-x8 and x19-x30 are
| live, x18 is potentially live with a shadow call stack pointer, and
| x9-x17 are safe to clobber.
... but either way this looks good; thanks!
Mark.
_______________________________________________
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/6] scs: Move scs_overflow_check() out of architecture code
From: Will Deacon @ 2020-05-18 13:23 UTC (permalink / raw)
To: Mark Rutland
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518121210.GD1957@C02TD0UTHF1T.local>
On Mon, May 18, 2020 at 01:12:10PM +0100, Mark Rutland wrote:
> On Fri, May 15, 2020 at 06:27:54PM +0100, Will Deacon wrote:
> > There is nothing architecture-specific about scs_overflow_check() as
> > it's just a trivial wrapper around scs_corrupted().
> >
> > For parity with task_stack_end_corrupted(), rename scs_corrupted() to
> > task_scs_end_corrupted() and call it from schedule_debug() when
> > CONFIG_SCHED_STACK_END_CHECK_is enabled. Finally, remove the unused
> > scs_overflow_check() function entirely.
> >
> > This has absolutely no impact on architectures that do not support SCS
> > (currently arm64 only).
> >
> > Signed-off-by: Will Deacon <will@kernel.org>
>
> Pulling this out of arch code seems sane to me, and the arch-specific
> chanes look sound. However, I have a concern with the changes within the
> scheduler context-switch.
>
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index a35d3318492c..56be4cbf771f 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -52,7 +52,6 @@
> > #include <asm/mmu_context.h>
> > #include <asm/processor.h>
> > #include <asm/pointer_auth.h>
> > -#include <asm/scs.h>
> > #include <asm/stacktrace.h>
> >
> > #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK)
> > @@ -516,7 +515,6 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
> > entry_task_switch(next);
> > uao_thread_switch(next);
> > ssbs_thread_switch(next);
> > - scs_overflow_check(next);
>
> Prior to this patch, we'd never switch to a task whose SCS had already
> been corrupted.
>
> With this patch, we only check that when switching away from a task, and
> only when CONFIG_SCHED_STACK_END_CHECK is selected, which at first
> glance seems to weaken that.
Yes, ignoring vmap'd stacks, this patch brings the SCS checking in-line with
the main stack checking when CONFIG_SCHED_STACK_END_CHECK=y.
> Arguably:
>
> * If the next task's SCS was corrupted by that task while it was
> running, we had already lost at that point.
With this change, we'll at least catch this one sooner, and that might be
useful if a bug has caused us to overflow the SCS but not the main stack.
> * If the next task's SCS was corrupted by another task, then that could
> also happen immediately after the check (though timing to avoid the
> check but affect the process could be harder).
We're only checking the magic end value, so the cross-task case is basically
if you overrun your own SCS as above, but then continue to overrun entire
SCSs for other tasks as well. It's probably not very useful in that case.
> ... and a VMAP'd SCS would be much nicer in this regard.
>
> Do we think this is weakening the check, or do we think it wasn't all
> that helpful to begin with?
I see it as a debug check to catch SCS overflow, rather than a hardening
feature, and I agree that using something like vmap stack for the SCS would
be better because we could have a guard page instead. This is something I
would like to revisit, but we need more information from Sami about why
Android rejected the larger allocation size, since I don't think there's an
awful lot of point merging this series if Android doesn't pick it up.
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] scs: Move DEFINE_SCS macro into core code
From: Will Deacon @ 2020-05-18 13:26 UTC (permalink / raw)
To: Mark Rutland
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518121441.GE1957@C02TD0UTHF1T.local>
On Mon, May 18, 2020 at 01:14:41PM +0100, Mark Rutland wrote:
> On Fri, May 15, 2020 at 06:27:56PM +0100, Will Deacon wrote:
> > Defining static shadow call stacks is not architecture-specific, so move
> > the DEFINE_SCS() macro into the core header file.
> >
> > Signed-off-by: Will Deacon <will@kernel.org>
>
> I think that we'll have to pull this back into arch code if/when we deal
> with VMAP'd stacks, so I'm not sure this is worthwhile given the
> diffstat is balanced.
I dunno, if another architecture wants to use this then having the stuff
in the core code makes sense to me. I also want to kill asm/scs.h entirely
and move our asm macros somewhere else where they're not mixed up with the
C headers.
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 4/6] scs: Move scs_overflow_check() out of architecture code
From: Mark Rutland @ 2020-05-18 13:32 UTC (permalink / raw)
To: Will Deacon
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518132346.GD32394@willie-the-truck>
On Mon, May 18, 2020 at 02:23:47PM +0100, Will Deacon wrote:
> On Mon, May 18, 2020 at 01:12:10PM +0100, Mark Rutland wrote:
> > On Fri, May 15, 2020 at 06:27:54PM +0100, Will Deacon wrote:
> > > There is nothing architecture-specific about scs_overflow_check() as
> > > it's just a trivial wrapper around scs_corrupted().
> > >
> > > For parity with task_stack_end_corrupted(), rename scs_corrupted() to
> > > task_scs_end_corrupted() and call it from schedule_debug() when
> > > CONFIG_SCHED_STACK_END_CHECK_is enabled. Finally, remove the unused
> > > scs_overflow_check() function entirely.
> > >
> > > This has absolutely no impact on architectures that do not support SCS
> > > (currently arm64 only).
> > >
> > > Signed-off-by: Will Deacon <will@kernel.org>
> >
> > Pulling this out of arch code seems sane to me, and the arch-specific
> > chanes look sound. However, I have a concern with the changes within the
> > scheduler context-switch.
> >
> > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > index a35d3318492c..56be4cbf771f 100644
> > > --- a/arch/arm64/kernel/process.c
> > > +++ b/arch/arm64/kernel/process.c
> > > @@ -52,7 +52,6 @@
> > > #include <asm/mmu_context.h>
> > > #include <asm/processor.h>
> > > #include <asm/pointer_auth.h>
> > > -#include <asm/scs.h>
> > > #include <asm/stacktrace.h>
> > >
> > > #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK)
> > > @@ -516,7 +515,6 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
> > > entry_task_switch(next);
> > > uao_thread_switch(next);
> > > ssbs_thread_switch(next);
> > > - scs_overflow_check(next);
> >
> > Prior to this patch, we'd never switch to a task whose SCS had already
> > been corrupted.
> >
> > With this patch, we only check that when switching away from a task, and
> > only when CONFIG_SCHED_STACK_END_CHECK is selected, which at first
> > glance seems to weaken that.
>
> Yes, ignoring vmap'd stacks, this patch brings the SCS checking in-line with
> the main stack checking when CONFIG_SCHED_STACK_END_CHECK=y.
>
> > Arguably:
> >
> > * If the next task's SCS was corrupted by that task while it was
> > running, we had already lost at that point.
>
> With this change, we'll at least catch this one sooner, and that might be
> useful if a bug has caused us to overflow the SCS but not the main stack.
Sure, but only if CONFIG_SCHED_STACK_END_CHECK is selected.
> > * If the next task's SCS was corrupted by another task, then that could
> > also happen immediately after the check (though timing to avoid the
> > check but affect the process could be harder).
>
> We're only checking the magic end value, so the cross-task case is basically
> if you overrun your own SCS as above, but then continue to overrun entire
> SCSs for other tasks as well. It's probably not very useful in that case.
>
> > ... and a VMAP'd SCS would be much nicer in this regard.
> >
> > Do we think this is weakening the check, or do we think it wasn't all
> > that helpful to begin with?
>
> I see it as a debug check to catch SCS overflow, rather than a hardening
> feature, and I agree that using something like vmap stack for the SCS would
> be better because we could have a guard page instead.
Fair enough. Could we put something into the commit message that more
explicitly calls out debug-not-hardening? I agree that under that model
this patch looks fine, and with something to that effect:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> This is something I would like to revisit, but we need more
> information from Sami about why Android rejected the larger allocation
> size, since I don't think there's an awful lot of point merging this
> series if Android doesn't pick it up.
Indeed. I'd certainly prefer the robustness of a VMAP'd SCS if we can do
that.
Mark.
_______________________________________________
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] scs: Move DEFINE_SCS macro into core code
From: Mark Rutland @ 2020-05-18 13:37 UTC (permalink / raw)
To: Will Deacon
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518132612.GE32394@willie-the-truck>
On Mon, May 18, 2020 at 02:26:12PM +0100, Will Deacon wrote:
> On Mon, May 18, 2020 at 01:14:41PM +0100, Mark Rutland wrote:
> > On Fri, May 15, 2020 at 06:27:56PM +0100, Will Deacon wrote:
> > > Defining static shadow call stacks is not architecture-specific, so move
> > > the DEFINE_SCS() macro into the core header file.
> > >
> > > Signed-off-by: Will Deacon <will@kernel.org>
> >
> > I think that we'll have to pull this back into arch code if/when we deal
> > with VMAP'd stacks, so I'm not sure this is worthwhile given the
> > diffstat is balanced.
>
> I dunno, if another architecture wants to use this then having the stuff
> in the core code makes sense to me. I also want to kill asm/scs.h entirely
> and move our asm macros somewhere else where they're not mixed up with the
> C headers.
Thinking about it a bit further, we'd have to make bigger changes anyhow
(to dynamically allocate), but given we can do that for regular stacks
we can probably do something similar here.
So no strong feelings either way on this patch.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
_______________________________________________
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/6] arm64: scs: Store absolute SCS stack pointer value in thread_info
From: Will Deacon @ 2020-05-18 13:37 UTC (permalink / raw)
To: Mark Rutland
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518113710.GA1957@C02TD0UTHF1T.local>
On Mon, May 18, 2020 at 12:37:10PM +0100, Mark Rutland wrote:
> On Fri, May 15, 2020 at 06:27:51PM +0100, Will Deacon wrote:
> > Storing the SCS information in thread_info as a {base,offset} pair
> > introduces an additional load instruction on the ret-to-user path,
> > since the SCS stack pointer in x18 has to be converted back to an offset
> > by subtracting the base.
> >
> > Replace the offset with the absolute SCS stack pointer value instead
> > and avoid the redundant load.
> >
> > Signed-off-by: Will Deacon <will@kernel.org>
>
> One trivial nit below, but regardless this looks sound to me, and I
> certainly prefer having the absolute address rather than an offset, so:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>
> > diff --git a/kernel/scs.c b/kernel/scs.c
> > index 9389c28f0853..5ff8663e4a67 100644
> > --- a/kernel/scs.c
> > +++ b/kernel/scs.c
> > @@ -60,8 +60,7 @@ int scs_prepare(struct task_struct *tsk, int node)
> > if (!s)
> > return -ENOMEM;
> >
> > - task_scs(tsk) = s;
> > - task_scs_offset(tsk) = 0;
> > + task_scs(tsk) = task_scs_sp(tsk) = s;
>
> I think this would be more legible as two statements:
>
> | task_sys(tsk) = s;
> | task_scs_sp(tsk) = s;
I think it's nice to be able to say:
task_scs(tsk) = task_scs_sp(tsk);
because it makes it very clear that they are initialised to the same thing.
Having it as two statements means somebody will update one and forget to
update the other one.
> ... as we usually save `foo = bar = baz` stuff for the start of a
> function or within loop conditions.
Hmm, I can't really find anything consistent in that regard, to be honest
with you. Did I miss something in the coding style doc?
I'll leave it as-is for now.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [V6, 0/2] media: i2c: Add support for DW9768 VCM driver
From: Dongchun Zhu @ 2020-05-18 13:27 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Hello,
This series adds DT bindings in YAML and V4L2 sub-device driver for DW9768
lens voice coil motor(VCM), which is a 10-bit DAC with 100mA output current
sink capability from Dongwoon.
The driver is designed for linear control of voice coil motor,
and controlled via IIC serial interface to set the desired focus.
It controls the position with 10-bit DAC data D[9:0] and seperates
two 8-bit regs to control the VCM position as belows.
DAC_MSB: D[9:8](ADDR: 0x03):
+---+---+---+---+---+---+---+---+
|---|---|---|---|---|---|D09|D08|
+---+---+---+---+---+---+---+---+
DAC_LSB: D[7:0](ADDR: 0x04):
+---+---+---+---+---+---+---+---+
|D07|D06|D05|D04|D03|D02|D01|D00|
+---+---+---+---+---+---+---+---+
This driver supports:
- set DW9768 to standby mode once suspend and turn it back to active if resume
- set the desired focus via V4L2_CID_FOCUS_ABSOLUTE ctrl
Previous versions of this patch-set can be found here:
v5: https://lore.kernel.org/linux-media/20200502161727.30463-1-dongchun.zhu@mediatek.com/
v4: https://lore.kernel.org/linux-media/20200330123634.363-1-dongchun.zhu@mediatek.com/
v3: https://lore.kernel.org/linux-media/20200228155958.20657-1-dongchun.zhu@mediatek.com/
v2: https://lore.kernel.org/linux-media/20190905072142.14606-1-dongchun.zhu@mediatek.com/
v1: https://lore.kernel.org/linux-media/20190708100641.2702-1-dongchun.zhu@mediatek.com/
Mainly changes of v6 are addressing comments from Rob, Sakari, Tomasz.
Compared to v5:
- Add a second compatible string for the Giantec device
- Document optional properties: "dongwoon,aac-mode", "dongwoon,aac-timing" and
"dongwoon,clock-dividing-rate" for lens specific reg settings
- Adjust Kconfig to match the current media tree master branch
- Use container_of() directly to replace of defining macro function
Please help review.
Thanks.
Dongchun Zhu (2):
media: dt-bindings: media: i2c: Document DW9768 bindings
media: i2c: dw9768: Add DW9768 VCM driver
.../bindings/media/i2c/dongwoon,dw9768.yaml | 105 +++++
MAINTAINERS | 8 +
drivers/media/i2c/Kconfig | 13 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/dw9768.c | 515 +++++++++++++++++++++
5 files changed, 642 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
create mode 100644 drivers/media/i2c/dw9768.c
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [V6, 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings
From: Dongchun Zhu @ 2020-05-18 13:27 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
In-Reply-To: <20200518132731.20855-1-dongchun.zhu@mediatek.com>
Add DeviceTree binding documentation for Dongwoon Anatech DW9768 voice
coil actuator.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/media/i2c/dongwoon,dw9768.yaml | 105 +++++++++++++++++++++
MAINTAINERS | 7 ++
2 files changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
new file mode 100644
index 0000000..b909e83
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings
+
+maintainers:
+ - Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+description: |-
+ The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter
+ with 100 mA output current sink capability. VCM current is controlled with
+ a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible)
+ serial interface that operates at clock rates up to 1MHz. This chip
+ integrates Advanced Actuator Control (AAC) technology and is intended for
+ driving voice coil lenses in camera modules.
+
+properties:
+ compatible:
+ enum:
+ # for DW9768 VCM
+ - dongwoon,dw9768
+ # for GT9769 VCM
+ - giantec,gt9769
+
+ reg:
+ maxItems: 1
+
+ vin-supply:
+ description:
+ Definition of the regulator used as I2C I/O interface power supply.
+
+ vdd-supply:
+ description:
+ Definition of the regulator used as VCM chip power supply.
+
+ dongwoon,aac-mode:
+ description:
+ Indication of AAC mode select.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum:
+ - 0 # Direct (default)
+ - 1 # AAC2 (operation time# 0.48 x Tvib)
+ - 2 # AAC3 (operation time# 0.70 x Tvib)
+ - 3 # AAC4 (operation time# 0.75 x Tvib)
+ - 4 # Reserved
+ - 5 # AAC8 (operation time# 1.13 x Tvib)
+ - 6 # Reserved
+ - 7 # Reserved
+
+ dongwoon,aac-timing:
+ description:
+ Indication of AAC Timing count, unit of 0.1 milliseconds.
+ Valid values vary from 0 to 63 (default 32).
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ dongwoon,clock-dividing-rate:
+ description:
+ Indication of VCM internal clock dividing rate select, as one multiple
+ factor to calculate VCM ring periodic time Tvib.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum:
+ - 0 # Dividing Rate - 2
+ - 1 # Dividing Rate - 1 (default)
+ - 2 # Dividing Rate - 1/2
+ - 3 # Dividing Rate - 1/4
+ - 4 # Dividing Rate - 8
+ - 5 # Dividing Rate - 4
+ - 6 # Dividing Rate - Reserved
+ - 7 # Dividing Rate - Reserved
+
+required:
+ - compatible
+ - reg
+ - vin-supply
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+
+ i2c {
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dw9768: camera-lens@c {
+ compatible = "dongwoon,dw9768";
+ reg = <0x0c>;
+
+ vin-supply = <&mt6358_vcamio_reg>;
+ vdd-supply = <&mt6358_vcama2_reg>;
+ dongwoon,aac-mode = <2>;
+ dongwoon,aac-timing = <57>;
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db..8d72c41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5151,6 +5151,13 @@ T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt
F: drivers/media/i2c/dw9714.c
+DONGWOON DW9768 LENS VOICE COIL DRIVER
+M: Dongchun Zhu <dongchun.zhu@mediatek.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
+
DONGWOON DW9807 LENS VOICE COIL DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [V6, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Dongchun Zhu @ 2020-05-18 13:27 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
In-Reply-To: <20200518132731.20855-1-dongchun.zhu@mediatek.com>
Add a V4L2 sub-device driver for DW9768 voice coil motor, providing
control to set the desired focus via IIC serial interface.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
MAINTAINERS | 1 +
drivers/media/i2c/Kconfig | 13 ++
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/dw9768.c | 515 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 530 insertions(+)
create mode 100644 drivers/media/i2c/dw9768.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d72c41..c92dc99 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5157,6 +5157,7 @@ L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
+F: drivers/media/i2c/dw9768.c
DONGWOON DW9807 LENS VOICE COIL DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 125d596..afdf994 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -1040,6 +1040,19 @@ config VIDEO_DW9714
capability. This is designed for linear control of
voice coil motors, controlled via I2C serial interface.
+config VIDEO_DW9768
+ tristate "DW9768 lens voice coil support"
+ depends on I2C && VIDEO_V4L2
+ depends on PM
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
+ help
+ This is a driver for the DW9768 camera lens voice coil.
+ DW9768 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
config VIDEO_DW9807_VCM
tristate "DW9807 lens voice coil support"
depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 77bf7d0..4057476 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
obj-$(CONFIG_VIDEO_DW9714) += dw9714.o
+obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
diff --git a/drivers/media/i2c/dw9768.c b/drivers/media/i2c/dw9768.c
new file mode 100644
index 0000000..a0cc9f3
--- /dev/null
+++ b/drivers/media/i2c/dw9768.c
@@ -0,0 +1,515 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 MediaTek Inc.
+
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-fwnode.h>
+#include <media/v4l2-subdev.h>
+
+#define DW9768_NAME "dw9768"
+#define DW9768_MAX_FOCUS_POS (1024 - 1)
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position
+ */
+#define DW9768_FOCUS_STEPS 1
+
+/*
+ * Ring control and Power control register
+ * Bit[1] RING_EN
+ * 0: Direct mode
+ * 1: AAC mode (ringing control mode)
+ * Bit[0] PD
+ * 0: Normal operation mode
+ * 1: Power down mode
+ * DW9768 requires waiting time of Topr after PD reset takes place.
+ */
+#define DW9768_RING_PD_CONTROL_REG 0x02
+#define DW9768_PD_MODE_OFF 0x00
+#define DW9768_PD_MODE_EN BIT(0)
+#define DW9768_AAC_MODE_EN BIT(1)
+
+/*
+ * DW9768 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ * DAC_MSB: D[9:8] (ADD: 0x03)
+ * DAC_LSB: D[7:0] (ADD: 0x04)
+ * D[9:0] DAC data input: positive output current = D[9:0] / 1023 * 100[mA]
+ */
+#define DW9768_MSB_ADDR 0x03
+#define DW9768_LSB_ADDR 0x04
+#define DW9768_STATUS_ADDR 0x05
+
+/*
+ * AAC mode control & prescale register
+ * Bit[7:5] Namely AC[2:0], decide the VCM mode and operation time.
+ * 000 Direct(default)
+ * 001 AAC2 0.48xTvib
+ * 010 AAC3 0.70xTvib
+ * 011 AAC4 0.75xTvib
+ * 100 Reserved
+ * 101 AAC8 1.13xTvib
+ * 110 Reserved
+ * 111 Reserved
+ * Bit[2:0] Namely PRESC[2:0], set the internal clock dividing rate as follow.
+ * 000 2
+ * 001 1(default)
+ * 010 1/2
+ * 011 1/4
+ * 100 8
+ * 101 4
+ * 110 Reserved
+ * 111 Reserved
+ */
+#define DW9768_AAC_PRESC_REG 0x06
+#define DW9768_AAC_MODE_SEL_MASK GENMASK(7, 5)
+#define DW9768_CLOCK_PRE_SCALE_SEL_MASK GENMASK(2, 0)
+
+/*
+ * VCM period of vibration register
+ * Bit[5:0] Defined as VCM rising periodic time (Tvib) together with PRESC[2:0]
+ * Tvib = (6.3ms + AACT[5:0] * 0.1ms) * Dividing Rate
+ * Dividing Rate is the internal clock dividing rate that is defined at
+ * PRESCALE register (ADD: 0x06)
+ */
+#define DW9768_AAC_TIME_REG 0x07
+
+/*
+ * DW9768 requires waiting time (delay time) of t_OPR after power-up,
+ * or in the case of PD reset taking place.
+ */
+#define DW9768_T_OPR_US 1000
+
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define DW9768_MOVE_STEPS 16
+
+/*
+ * DW9768_AAC_PRESC_REG & DW9768_AAC_TIME_REG determine VCM operation time.
+ * If DW9768_AAC_PRESC_REG is 0x41, and DW9768_AAC_TIME_REG is 0x39, VCM mode
+ * would be AAC3, Operation Time would be 0.70xTvib, that is 8.40ms.
+ */
+#define DW9768_MOVE_DELAY_US 8400
+#define DW9768_STABLE_TIME_US 20000
+
+static const char * const dw9768_supply_names[] = {
+ "vin", /* I2C I/O interface power */
+ "vdd", /* VCM power */
+};
+
+/* dw9768 device structure */
+struct dw9768 {
+ struct regulator_bulk_data supplies[ARRAY_SIZE(dw9768_supply_names)];
+ struct v4l2_ctrl_handler ctrls;
+ struct v4l2_ctrl *focus;
+ struct v4l2_subdev sd;
+
+ u32 aac_mode;
+ u32 aac_timing;
+ u32 clock_dividing_rate;
+ bool aac_mode_control_enable;
+ bool aact_cnt_select_enable;
+ bool clock_dividing_rate_select_enable;
+};
+
+static inline struct dw9768 *sd_to_dw9768(struct v4l2_subdev *subdev)
+{
+ return container_of(subdev, struct dw9768, sd);
+}
+
+struct regval_list {
+ u8 reg_num;
+ u8 value;
+};
+
+static int dw9768_read_smbus(struct dw9768 *dw9768, unsigned char reg,
+ unsigned char *val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(client, reg);
+
+ if (ret < 0)
+ return ret;
+
+ *val = (unsigned char)ret;
+
+ return 0;
+}
+
+static int dw9768_mod_reg(struct dw9768 *dw9768, u8 reg, u8 mask, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+ u8 readval;
+ int ret;
+
+ ret = dw9768_read_smbus(dw9768, reg, &readval);
+ if (ret)
+ return ret;
+
+ val = (readval & ~mask) | (val & mask);
+
+ return i2c_smbus_write_byte_data(client, reg, val);
+}
+
+static int dw9768_set_dac(struct dw9768 *dw9768, u16 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+
+ /* Write VCM position to registers */
+ return i2c_smbus_write_word_swapped(client, DW9768_MSB_ADDR, val);
+}
+
+static int dw9768_init(struct dw9768 *dw9768)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+ int ret, val;
+
+ /* Reset DW9768_RING_PD_CONTROL_REG to default status 0x00 */
+ ret = i2c_smbus_write_byte_data(client, DW9768_RING_PD_CONTROL_REG,
+ DW9768_PD_MODE_OFF);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * DW9769 requires waiting delay time of t_OPR
+ * after PD reset takes place.
+ */
+ usleep_range(DW9768_T_OPR_US, DW9768_T_OPR_US + 100);
+
+ /* Set DW9768_RING_PD_CONTROL_REG to DW9768_AAC_MODE_EN(0x01) */
+ ret = i2c_smbus_write_byte_data(client, DW9768_RING_PD_CONTROL_REG,
+ DW9768_AAC_MODE_EN);
+ if (ret < 0)
+ return ret;
+
+ /* Set AAC mode according to DT property */
+ if (dw9768->aac_mode_control_enable) {
+ ret = dw9768_mod_reg(dw9768, DW9768_AAC_PRESC_REG,
+ DW9768_AAC_MODE_SEL_MASK,
+ dw9768->aac_mode << 5);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Set Clock Dividing Rate factor according to DT property */
+ if (dw9768->clock_dividing_rate_select_enable) {
+ ret = dw9768_mod_reg(dw9768, DW9768_AAC_PRESC_REG,
+ DW9768_CLOCK_PRE_SCALE_SEL_MASK,
+ dw9768->clock_dividing_rate);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Set AAC Timing according to DT property */
+ if (dw9768->aact_cnt_select_enable) {
+ ret = i2c_smbus_write_byte_data(client, DW9768_AAC_TIME_REG,
+ dw9768->aac_timing);
+ if (ret < 0)
+ return ret;
+ }
+
+ for (val = dw9768->focus->val % DW9768_MOVE_STEPS;
+ val <= dw9768->focus->val;
+ val += DW9768_MOVE_STEPS) {
+ ret = dw9768_set_dac(dw9768, val);
+ if (ret) {
+ dev_err(&client->dev, "%s I2C failure: %d",
+ __func__, ret);
+ return ret;
+ }
+ usleep_range(DW9768_MOVE_DELAY_US,
+ DW9768_MOVE_DELAY_US + 1000);
+ }
+
+ return 0;
+}
+
+static int dw9768_release(struct dw9768 *dw9768)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+ int ret, val;
+
+ val = round_down(dw9768->focus->val, DW9768_MOVE_STEPS);
+ for ( ; val >= 0; val -= DW9768_MOVE_STEPS) {
+ ret = dw9768_set_dac(dw9768, val);
+ if (ret) {
+ dev_err(&client->dev, "I2C write fail: %d", ret);
+ return ret;
+ }
+ usleep_range(DW9768_MOVE_DELAY_US, DW9768_MOVE_DELAY_US + 1000);
+ }
+
+ /*
+ * Wait for the motor to stabilize after the last movement
+ * to prevent the motor from shaking.
+ */
+ usleep_range(DW9768_STABLE_TIME_US - DW9768_MOVE_DELAY_US,
+ DW9768_STABLE_TIME_US - DW9768_MOVE_DELAY_US + 1000);
+
+ ret = i2c_smbus_write_byte_data(client, DW9768_RING_PD_CONTROL_REG,
+ DW9768_PD_MODE_EN);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * DW9769 requires waiting delay time of t_OPR
+ * after PD reset takes place.
+ */
+ usleep_range(DW9768_T_OPR_US, DW9768_T_OPR_US + 100);
+
+ return 0;
+}
+
+static int dw9768_runtime_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct dw9768 *dw9768 = sd_to_dw9768(sd);
+
+ dw9768_release(dw9768);
+ regulator_bulk_disable(ARRAY_SIZE(dw9768_supply_names),
+ dw9768->supplies);
+
+ return 0;
+}
+
+static int dw9768_runtime_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct dw9768 *dw9768 = sd_to_dw9768(sd);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(dw9768_supply_names),
+ dw9768->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable regulators\n");
+ return ret;
+ }
+
+ /*
+ * The datasheet refers to t_OPR that needs to be waited before sending
+ * I2C commands after power-up.
+ */
+ usleep_range(DW9768_T_OPR_US, DW9768_T_OPR_US + 100);
+
+ ret = dw9768_init(dw9768);
+ if (ret < 0)
+ goto disable_regulator;
+
+ return 0;
+
+disable_regulator:
+ regulator_bulk_disable(ARRAY_SIZE(dw9768_supply_names),
+ dw9768->supplies);
+
+ return ret;
+}
+
+static int dw9768_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct dw9768 *dw9768 = container_of(ctrl->handler,
+ struct dw9768, ctrls);
+
+ if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
+ return dw9768_set_dac(dw9768, ctrl->val);
+
+ return 0;
+}
+
+static const struct v4l2_ctrl_ops dw9768_ctrl_ops = {
+ .s_ctrl = dw9768_set_ctrl,
+};
+
+static int dw9768_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+ int ret;
+
+ ret = pm_runtime_get_sync(sd->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(sd->dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int dw9768_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+ pm_runtime_put(sd->dev);
+
+ return 0;
+}
+
+static const struct v4l2_subdev_internal_ops dw9768_int_ops = {
+ .open = dw9768_open,
+ .close = dw9768_close,
+};
+
+static const struct v4l2_subdev_ops dw9768_ops = { };
+
+static int dw9768_init_controls(struct dw9768 *dw9768)
+{
+ struct v4l2_ctrl_handler *hdl = &dw9768->ctrls;
+ const struct v4l2_ctrl_ops *ops = &dw9768_ctrl_ops;
+
+ v4l2_ctrl_handler_init(hdl, 1);
+
+ dw9768->focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE, 0,
+ DW9768_MAX_FOCUS_POS,
+ DW9768_FOCUS_STEPS, 0);
+
+ if (hdl->error)
+ return hdl->error;
+
+ dw9768->sd.ctrl_handler = hdl;
+
+ return 0;
+}
+
+static int dw9768_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct dw9768 *dw9768;
+ unsigned int aac_mode_select;
+ unsigned int aac_timing_select;
+ unsigned int clock_dividing_rate_select;
+ unsigned int i;
+ int ret;
+
+ dw9768 = devm_kzalloc(dev, sizeof(*dw9768), GFP_KERNEL);
+ if (!dw9768)
+ return -ENOMEM;
+
+ v4l2_i2c_subdev_init(&dw9768->sd, client, &dw9768_ops);
+ dw9768->aac_mode_control_enable = false;
+ dw9768->aact_cnt_select_enable = false;
+ dw9768->clock_dividing_rate_select_enable = false;
+
+ /* Optional indication of AAC mode select */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "dongwoon,aac-mode",
+ &aac_mode_select);
+
+ if (!ret) {
+ dw9768->aac_mode_control_enable = true;
+ dw9768->aac_mode = aac_mode_select;
+ }
+
+ /* Optional indication of VCM internal clock dividing rate select */
+ ret = fwnode_property_read_u32(dev_fwnode(dev),
+ "dongwoon,clock-dividing-rate",
+ &clock_dividing_rate_select);
+
+ if (!ret) {
+ dw9768->clock_dividing_rate_select_enable = true;
+ dw9768->clock_dividing_rate = clock_dividing_rate_select;
+ }
+
+ /* Optional indication of AAC Timing */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "dongwoon,aac-timing",
+ &aac_timing_select);
+
+ if (!ret) {
+ dw9768->aact_cnt_select_enable = true;
+ dw9768->aac_timing = aac_timing_select;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(dw9768_supply_names); i++)
+ dw9768->supplies[i].supply = dw9768_supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dw9768_supply_names),
+ dw9768->supplies);
+ if (ret) {
+ dev_err(dev, "failed to get regulators\n");
+ return ret;
+ }
+
+ ret = dw9768_init_controls(dw9768);
+ if (ret)
+ goto entity_cleanup;
+
+ dw9768->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ dw9768->sd.internal_ops = &dw9768_int_ops;
+
+ ret = media_entity_pads_init(&dw9768->sd.entity, 0, NULL);
+ if (ret < 0)
+ goto entity_cleanup;
+
+ dw9768->sd.entity.function = MEDIA_ENT_F_LENS;
+
+ pm_runtime_enable(dev);
+ if (!pm_runtime_enabled(dev)) {
+ ret = dw9768_runtime_resume(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to power on: %d\n", ret);
+ goto entity_cleanup;
+ }
+ }
+
+ ret = v4l2_async_register_subdev(&dw9768->sd);
+ if (ret < 0)
+ goto entity_cleanup;
+
+ return 0;
+
+entity_cleanup:
+ v4l2_ctrl_handler_free(&dw9768->ctrls);
+ media_entity_cleanup(&dw9768->sd.entity);
+ return ret;
+}
+
+static int dw9768_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct dw9768 *dw9768 = sd_to_dw9768(sd);
+
+ pm_runtime_disable(&client->dev);
+ v4l2_async_unregister_subdev(&dw9768->sd);
+ v4l2_ctrl_handler_free(&dw9768->ctrls);
+ media_entity_cleanup(&dw9768->sd.entity);
+ if (!pm_runtime_status_suspended(&client->dev))
+ dw9768_runtime_suspend(&client->dev);
+ pm_runtime_set_suspended(&client->dev);
+
+ return 0;
+}
+
+static const struct of_device_id dw9768_of_table[] = {
+ { .compatible = "dongwoon,dw9768" },
+ { .compatible = "giantec,gt9769" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, dw9768_of_table);
+
+static const struct dev_pm_ops dw9768_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(dw9768_runtime_suspend, dw9768_runtime_resume, NULL)
+};
+
+static struct i2c_driver dw9768_i2c_driver = {
+ .driver = {
+ .name = DW9768_NAME,
+ .pm = &dw9768_pm_ops,
+ .of_match_table = dw9768_of_table,
+ },
+ .probe_new = dw9768_probe,
+ .remove = dw9768_remove,
+};
+module_i2c_driver(dw9768_i2c_driver);
+
+MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
+MODULE_DESCRIPTION("DW9768 VCM driver");
+MODULE_LICENSE("GPL v2");
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/6] scs: Move accounting into alloc/free functions
From: Will Deacon @ 2020-05-18 13:39 UTC (permalink / raw)
To: Mark Rutland
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518113858.GB1957@C02TD0UTHF1T.local>
On Mon, May 18, 2020 at 12:38:58PM +0100, Mark Rutland wrote:
> On Fri, May 15, 2020 at 06:27:52PM +0100, Will Deacon wrote:
> > There's no need to perform the shadow stack page accounting independently
> > of the lifetime of the underlying allocation, so call the accounting code
> > from the {alloc,free}() functions and simplify the code in the process.
> >
> > Signed-off-by: Will Deacon <will@kernel.org>
> > ---
> > kernel/scs.c | 45 +++++++++++++++++++++------------------------
> > 1 file changed, 21 insertions(+), 24 deletions(-)
>
> One (super trivial) nit below, but regardless this looks like a sound
> and sensible cleanup, so:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>
> > diff --git a/kernel/scs.c b/kernel/scs.c
> > index 5ff8663e4a67..aea841cd7586 100644
> > --- a/kernel/scs.c
> > +++ b/kernel/scs.c
> > @@ -14,25 +14,35 @@
>
> > static void *scs_alloc(int node)
> > {
>
> > + void *s = kmem_cache_alloc_node(scs_cache, GFP_SCS, node);
> > +
> > + if (!s)
> > + return NULL;
>
> Super trivial nit, but could we omit the line space between these two,
> to fit with usual style?
I really like having the empty line after the last variable declaration.
Sorry,
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] iommu/mediatek-v1: Add def_domain_type
From: Joerg Roedel @ 2020-05-18 13:42 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, anan.sun, srv_heupstream, Will Deacon, linux-kernel,
iommu, linux-mediatek, Matthias Brugger, Robin Murphy,
linux-arm-kernel
In-Reply-To: <1589530123-30240-1-git-send-email-yong.wu@mediatek.com>
On Fri, May 15, 2020 at 04:08:43PM +0800, Yong Wu wrote:
> The MediaTek V1 IOMMU is arm32 whose default domain type is
> IOMMU_DOMAIN_UNMANAGED. Add this to satisfy the bus_iommu_probe to
> enter "probe_finalize".
>
> The iommu framework will create a iommu domain for each a device.
> But all the devices share a iommu domain here, thus we skip all the
> other domains in the "attach_device" except the domain we create
> internally with arm_iommu_create_mapping.
>
> Also a minor change: in the attach_device, "data" always is not null.
> Remove "if (!data) return".
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> a. rebase on linux-next.
> b. After this patch and fixed the mutex issue(locally I only move
> mutex_unlock(&group->mutex) before __iommu_group_dma_attach(group)),
> the mtk_iommu_v1.c could work normally.
> ---
> drivers/iommu/mtk_iommu_v1.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arch/arm64: Enlarge arm64 command line length to 4096 bytes
From: 王程刚 @ 2020-05-18 13:42 UTC (permalink / raw)
To: 'Catalin Marinas', 'Will Deacon',
linux-arm-kernel, linux-kernel
Cc: kernel
Now android use many long command line, and oem need append some command
line to debug boot, so 2048 bytes cannot able to meet the requirement.
Enlarge arm64's command line length to 4096 bytes.
Signed-off-by: Chenggang Wang <wangchenggang@vivo.com>
---
arch/arm64/include/uapi/asm/setup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/uapi/asm/setup.h
b/arch/arm64/include/uapi/asm/setup.h
index 5d703888f351..85e34aa784e0 100644
--- a/arch/arm64/include/uapi/asm/setup.h
+++ b/arch/arm64/include/uapi/asm/setup.h
@@ -22,6 +22,6 @@
#include <linux/types.h>
-#define COMMAND_LINE_SIZE 2048
+#define COMMAND_LINE_SIZE 4096
#endif
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arch/arm64: Enlarge arm64 command line length to 4096 bytes
From: Will Deacon @ 2020-05-18 13:47 UTC (permalink / raw)
To: 王程刚
Cc: 'Catalin Marinas', linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <00fc01d62d1a$35445a80$9fcd0f80$@vivo.com>
On Mon, May 18, 2020 at 09:42:43PM +0800, 王程刚 wrote:
> Now android use many long command line, and oem need append some command
> line to debug boot, so 2048 bytes cannot able to meet the requirement.
> Enlarge arm64's command line length to 4096 bytes.
I thought bootconfig was supposed to fix this sort of thing?
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: [PATCHv2 0/7] Support inhibiting input devices
From: Andrzej Pietrasiewicz @ 2020-05-18 13:49 UTC (permalink / raw)
To: Hans de Goede, linux-input, linux-acpi, linux-iio,
linux-arm-kernel, linux-samsung-soc, linux-tegra, patches,
ibm-acpi-devel, platform-driver-x86
Cc: Nick Dyer, Benjamin Tissoires, Laxman Dewangan,
Peter Meerwald-Stadler, kernel, Fabio Estevam, Lars-Peter Clausen,
Krzysztof Kozlowski, Jonathan Hunter, Kukjin Kim, NXP Linux Team,
Sylvain Lemieux, Len Brown, Peter Hutterer, Michael Hennerich,
Sascha Hauer, Henrique de Moraes Holschuh, Vladimir Zapolskiy,
Barry Song, Ferruh Yigit, Dmitry Torokhov, Rafael J . Wysocki,
Thierry Reding, Sangwon Jee, Pengutronix Kernel Team,
Hartmut Knaack, Shawn Guo, Jonathan Cameron
In-Reply-To: <6d9921fc-5c2f-beda-4dcd-66d6970a22fe@redhat.com>
Hi Hans,
W dniu 18.05.2020 o 14:24, Hans de Goede pisze:
> Hi,
>
> On 5/18/20 12:48 PM, Andrzej Pietrasiewicz wrote:
>> Hi Hans,
>>
>> W dniu 15.05.2020 o 20:19, Hans de Goede pisze:
>>> Hi Andrezj,
>>>
>>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote:
>>>> Userspace might want to implement a policy to temporarily disregard input
>>>> from certain devices, including not treating them as wakeup sources.
>>>>
>>>> An example use case is a laptop, whose keyboard can be folded under the
>>>> screen to create tablet-like experience. The user then must hold the laptop
>>>> in such a way that it is difficult to avoid pressing the keyboard keys. It
>>>> is therefore desirable to temporarily disregard input from the keyboard,
>>>> until it is folded back. This obviously is a policy which should be kept
>>>> out of the kernel, but the kernel must provide suitable means to implement
>>>> such a policy.
>>>
>>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE
>>> generating evdev nodes and e.g. internal keyboards on devices with 360°
>>> hinges for this reason. libinput simply closes the /dev/input/event#
>>> node when folded and re-opens it when the keyboard should become active
>>> again. Thus not only suppresses events but allows e.g. touchpads to
>>> enter runtime suspend mode which saves power. Typically closing the
>>> /dev/input/event# node will also disable the device as wakeup source.
>>>
>>> So I wonder what this series actually adds for functionality for
>>> userspace which can not already be achieved this way?
>>>
>>> I also noticed that you keep the device open (do not call the
>>> input_device's close callback) when inhibited and just throw away
>>
>> I'm not sure if I understand you correctly, it is called:
>>
>> +static inline void input_stop(struct input_dev *dev)
>> +{
>> + if (dev->poller)
>> + input_dev_poller_stop(dev->poller);
>> + if (dev->close)
>> + dev->close(dev);
>> ^^^^^^^^^^^^^^^^
>> +static int input_inhibit(struct input_dev *dev)
>> +{
>> + int ret = 0;
>> +
>> + mutex_lock(&dev->mutex);
>> +
>> + if (dev->inhibited)
>> + goto out;
>> +
>> + if (dev->users) {
>> + if (dev->inhibit) {
>> + ret = dev->inhibit(dev);
>> + if (ret)
>> + goto out;
>> + }
>> + input_stop(dev);
>> ^^^^^^^^^^^^^^^^
>>
>> It will not be called when dev->users is zero, but if it is zero,
>> then nobody has opened the device yet so there is nothing to close.
>
> Ah, I missed that.
>
> So if the device implements the inhibit call back then on
> inhibit it will get both the inhibit and close callback called?
>
That's right. And conversely, upon uninhibit open() and uninhibit()
callbacks will be invoked. Please note that just as with open()/close(),
providing inhibit()/uninhibit() is optional.
> And what happens if the last user goes away and the device
> is not inhibited?
close() is called as usually.
>
> I'm trying to understand here what the difference between the 2
> is / what the goal of having a separate inhibit callback ?
>
Drivers have very different ideas about what it means to suspend/resume
and open/close. The optional inhibit/uninhibit callbacks are meant for
the drivers to know that it is this particular action going on.
For inhibit() there's one more argument: close() does not return a value,
so its meaning is "do some last cleanup" and as such it is not allowed
to fail - whatever its effect is, we must deem it successful. inhibit()
does return a value and so it is allowed to fail.
All in all, it is up to the drivers to decide which callback they
provide. Based on my work so far I would say that there are tens
of simple cases where open() and close() are sufficient, out of total
~400 users of input_allocate_device():
$ git grep "input_allocate_device(" | grep -v ^Documentation | \
cut -f1 -d: | sort | uniq | wc
390 390 13496
Andrzej
_______________________________________________
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] Clean up Shadow Call Stack patches for 5.8
From: Will Deacon @ 2020-05-18 13:52 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas, LKML,
Mark Rutland, kernel-team, Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <CABCJKucXmMD82mQ0rSMjfByXD42htTjkde3TsKTVP-jvuqkZwQ@mail.gmail.com>
On Fri, May 15, 2020 at 01:42:40PM -0700, Sami Tolvanen wrote:
> On Fri, May 15, 2020 at 10:28 AM Will Deacon <will@kernel.org> wrote:
> > Will Deacon (6):
> > arm64: scs: Store absolute SCS stack pointer value in thread_info
> > scs: Move accounting into alloc/free functions
> > arm64: scs: Use 'scs_sp' register alias for x18
> > scs: Move scs_overflow_check() out of architecture code
> > scs: Remove references to asm/scs.h from core code
> > scs: Move DEFINE_SCS macro into core code
> >
> > arch/Kconfig | 4 +--
> > arch/arm64/include/asm/scs.h | 29 ++++------------
> > arch/arm64/include/asm/thread_info.h | 4 +--
> > arch/arm64/kernel/asm-offsets.c | 2 +-
> > arch/arm64/kernel/entry.S | 10 +++---
> > arch/arm64/kernel/head.S | 2 +-
> > arch/arm64/kernel/process.c | 2 --
> > arch/arm64/kernel/scs.c | 6 +---
> > include/linux/scs.h | 16 +++++----
> > kernel/sched/core.c | 3 ++
> > kernel/scs.c | 52 +++++++++++++---------------
> > 11 files changed, 55 insertions(+), 75 deletions(-)
> >
> > --
> > 2.26.2.761.g0e0b3e54be-goog
>
> Thanks, Will. I tested these on my SCS tree and didn't run into any
> issues. Looks good to me.
Cheers, Sami. Can I add your 'Tested-by' to the patches, please?
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 v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Bartosz Golaszewski @ 2020-05-18 14:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Edwin Peer, DTML, Bartosz Golaszewski, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <CAK8P3a0XgJtZNKePZUUpzADO25-JZKyDiVHFS_yuHRXTjvjDwg@mail.gmail.com>
pt., 15 maj 2020 o 15:32 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > +static int mtk_mac_ring_pop_tail(struct mtk_mac_ring *ring,
> > + struct mtk_mac_ring_desc_data *desc_data)
>
> I took another look at this function because of your comment on the locking
> the descriptor updates, which seemed suspicious as the device side does not
> actually use the locks to access them
>
> > +{
> > + struct mtk_mac_ring_desc *desc = &ring->descs[ring->tail];
> > + unsigned int status;
> > +
> > + /* Let the device release the descriptor. */
> > + dma_rmb();
> > + status = desc->status;
> > + if (!(status & MTK_MAC_DESC_BIT_COWN))
> > + return -1;
>
> The dma_rmb() seems odd here, as I don't see which prior read
> is being protected by this.
>
> > + desc_data->len = status & MTK_MAC_DESC_MSK_LEN;
> > + desc_data->flags = status & ~MTK_MAC_DESC_MSK_LEN;
> > + desc_data->dma_addr = ring->dma_addrs[ring->tail];
> > + desc_data->skb = ring->skbs[ring->tail];
> > +
> > + desc->data_ptr = 0;
> > + desc->status = MTK_MAC_DESC_BIT_COWN;
> > + if (status & MTK_MAC_DESC_BIT_EOR)
> > + desc->status |= MTK_MAC_DESC_BIT_EOR;
> > +
> > + /* Flush writes to descriptor memory. */
> > + dma_wmb();
>
> The comment and the barrier here seem odd as well. I would have expected
> a barrier after the update to the data pointer, and only a single store
> but no read of the status flag instead of the read-modify-write,
> something like
>
> desc->data_ptr = 0;
> dma_wmb(); /* make pointer update visible before status update */
> desc->status = MTK_MAC_DESC_BIT_COWN | (status & MTK_MAC_DESC_BIT_EOR);
>
> > + ring->tail = (ring->tail + 1) % MTK_MAC_RING_NUM_DESCS;
> > + ring->count--;
>
> I would get rid of the 'count' here, as it duplicates the information
> that is already known from the difference between head and tail, and you
> can't update it atomically without holding a lock around the access to
> the ring. The way I'd do this is to have the head and tail pointers
> in separate cache lines, and then use READ_ONCE/WRITE_ONCE
> and smp barriers to access them, with each one updated on one
> thread but read by the other.
>
Your previous solution seems much more reliable though. For instance
in the above: when we're doing the TX cleanup (we got the TX ready
irq, we're iterating over descriptors until we know there are no more
packets scheduled (count == 0) or we encounter one that's still owned
by DMA), a parallel TX path can schedule new packets to be sent and I
don't see how we can atomically check the count (understood as a
difference between tail and head) and run a new iteration (where we'd
modify the head or tail) without risking the other path getting in the
way. We'd have to always check the descriptor.
I experimented a bit with this and couldn't come up with anything that
would pass any stress test.
On the other hand: spin_lock_bh() works fine and I like your approach
from the previous e-mail - except for the work for updating stats as
we could potentially lose some stats when we're updating in process
context with RX/TX paths running in parallel in napi context but that
would be rare enough to overlook it.
I hope v4 will be good enough even with spinlocks. :)
Bart
_______________________________________________
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/3] arm64: perf: Add support for Perf NMI interrupts
From: Sumit Garg @ 2020-05-18 14:09 UTC (permalink / raw)
To: Alexandru Elisei, Mark Rutland
Cc: Jian-Lin Chen, Will Deacon, alexander.shishkin, Catalin Marinas,
yj.chiang, Linux Kernel Mailing List, acme, Lecopzer Chen,
Peter Zijlstra, mingo, linux-mediatek, linux-arm-kernel,
matthias.bgg, namhyung, jolsa, julien.thierry.kdev
In-Reply-To: <a9002b5e-aec5-b6e0-7174-87b93351d60c@arm.com>
On Mon, 18 May 2020 at 16:47, Alexandru Elisei <alexandru.elisei@arm.com> wrote:
>
> Hi,
>
> On 5/18/20 11:45 AM, Mark Rutland wrote:
> > Hi all,
> >
> > On Mon, May 18, 2020 at 02:26:00PM +0800, Lecopzer Chen wrote:
> >> HI Sumit,
> >>
> >> Thanks for your information.
> >>
> >> I've already implemented IPI (same as you did [1], little difference
> >> in detail), hardlockup detector and perf in last year(2019) for
> >> debuggability.
> >> And now we tend to upstream to reduce kernel maintaining effort.
> >> I'm glad if someone in ARM can do this work :)
> >>
> >> Hi Julien,
> >>
> >> Does any Arm maintainers can proceed this action?
> > Alexandru (Cc'd) has been rebasing and reworking Julien's patches, which
> > is my preferred approach.
> >
> > I understand that's not quite ready for posting since he's investigating
> > some of the nastier subtleties (e.g. mutual exclusion with the NMI), but
> > maybe we can put the work-in-progress patches somewhere in the mean
> > time.
> >
> > Alexandru, do you have an idea of what needs to be done, and/or when you
> > expect you could post that?
>
> I'm currently working on rebasing the patches on top of 5.7-rc5, when I have
> something usable I'll post a link (should be a couple of days). After that I will
> address the review comments, and I plan to do a thorough testing because I'm not
> 100% confident that some of the assumptions around the locks that were removed are
> correct. My guess is this will take a few weeks.
>
Thanks Mark, Alex for the status updates on perf NMI feature.
Alex,
As the hard-lockup detection patch [1] has a dependency on perf NMI
patch-set, I will rebase and test hard-lockup detector when you have
got a working tree. But due to the dependency, I think patch [1]
should be accepted along with perf NMI patch-set. So would you be open
to include this patch as part of your series?
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html
-Sumit
> Thanks,
> Alex
> >
> > Thanks,
> > Mark.
> >
> >> This is really useful in debugging.
> >> Thank you!!
> >>
> >>
> >>
> >> [1] https://lkml.org/lkml/2020/4/24/328
> >>
> >>
> >> Lecopzer
> >>
> >> Sumit Garg <sumit.garg@linaro.org> 於 2020年5月18日 週一 下午1:46寫道:
> >>> + Julien
> >>>
> >>> Hi Lecopzer,
> >>>
> >>> On Sat, 16 May 2020 at 18:20, Lecopzer Chen <lecopzer@gmail.com> wrote:
> >>>> These series implement Perf NMI funxtionality and depends on
> >>>> Pseudo NMI [1] which has been upstreamed.
> >>>>
> >>>> In arm64 with GICv3, Pseudo NMI was implemented for NMI-like interruts.
> >>>> That can be extended to Perf NMI which is the prerequisite for hard-lockup
> >>>> detector which had already a standard interface inside Linux.
> >>>>
> >>>> Thus the first step we need to implement perf NMI interface and make sure
> >>>> it works fine.
> >>>>
> >>> This is something that is already implemented via Julien's patch-set
> >>> [1]. Its v4 has been floating since July, 2019 and I couldn't find any
> >>> major blocking comments but not sure why things haven't progressed
> >>> further.
> >>>
> >>> Maybe Julien or Arm maintainers can provide updates on existing
> >>> patch-set [1] and how we should proceed further with this interesting
> >>> feature.
> >>>
> >>> And regarding hard-lockup detection, I have been able to enable it
> >>> based on perf NMI events using Julien's perf patch-set [1]. Have a
> >>> look at the patch here [2].
> >>>
> >>> [1] https://patchwork.kernel.org/cover/11047407/
> >>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html
> >>>
> >>> -Sumit
> >>>
> >>>> Perf NMI has been test by dd if=/dev/urandom of=/dev/null like the link [2]
> >>>> did.
> >>>>
> >>>> [1] https://lkml.org/lkml/2019/1/31/535
> >>>> [2] https://www.linaro.org/blog/debugging-arm-kernels-using-nmifiq
> >>>>
> >>>>
> >>>> Lecopzer Chen (3):
> >>>> arm_pmu: Add support for perf NMI interrupts registration
> >>>> arm64: perf: Support NMI context for perf event ISR
> >>>> arm64: Kconfig: Add support for the Perf NMI
> >>>>
> >>>> arch/arm64/Kconfig | 10 +++++++
> >>>> arch/arm64/kernel/perf_event.c | 36 ++++++++++++++++++------
> >>>> drivers/perf/arm_pmu.c | 51 ++++++++++++++++++++++++++++++----
> >>>> include/linux/perf/arm_pmu.h | 6 ++++
> >>>> 4 files changed, 88 insertions(+), 15 deletions(-)
> >>>>
> >>>> --
> >>>> 2.25.1
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> linux-arm-kernel mailing list
> >>>> linux-arm-kernel@lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V6, 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings
From: Tomasz Figa @ 2020-05-18 14:12 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男), Louis Kuo,
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <20200518132731.20855-2-dongchun.zhu@mediatek.com>
Hi Dongchun,
On Mon, May 18, 2020 at 3:29 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Add DeviceTree binding documentation for Dongwoon Anatech DW9768 voice
> coil actuator.
Thanks for the patch. Please see my comments below.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
This version includes significant changes, so the reviewed-by tag
shouldn't have been carried out.
> ---
> .../bindings/media/i2c/dongwoon,dw9768.yaml | 105 +++++++++++++++++++++
> MAINTAINERS | 7 ++
> 2 files changed, 112 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> new file mode 100644
> index 0000000..b909e83
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter
> + with 100 mA output current sink capability. VCM current is controlled with
> + a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible)
> + serial interface that operates at clock rates up to 1MHz. This chip
> + integrates Advanced Actuator Control (AAC) technology and is intended for
> + driving voice coil lenses in camera modules.
> +
> +properties:
> + compatible:
> + enum:
> + # for DW9768 VCM
> + - dongwoon,dw9768
> + # for GT9769 VCM
> + - giantec,gt9769
> +
> + reg:
> + maxItems: 1
> +
> + vin-supply:
> + description:
> + Definition of the regulator used as I2C I/O interface power supply.
> +
> + vdd-supply:
> + description:
> + Definition of the regulator used as VCM chip power supply.
> +
> + dongwoon,aac-mode:
> + description:
> + Indication of AAC mode select.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Direct (default)
> + - 1 # AAC2 (operation time# 0.48 x Tvib)
> + - 2 # AAC3 (operation time# 0.70 x Tvib)
> + - 3 # AAC4 (operation time# 0.75 x Tvib)
> + - 4 # Reserved
> + - 5 # AAC8 (operation time# 1.13 x Tvib)
> + - 6 # Reserved
> + - 7 # Reserved
I'll ultimately leave it to DT maintainers, but is there any reason to
define the reserved values?
> +
> + dongwoon,aac-timing:
> + description:
> + Indication of AAC Timing count, unit of 0.1 milliseconds.
> + Valid values vary from 0 to 63 (default 32).
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> +
> + dongwoon,clock-dividing-rate:
> + description:
> + Indication of VCM internal clock dividing rate select, as one multiple
> + factor to calculate VCM ring periodic time Tvib.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Dividing Rate - 2
> + - 1 # Dividing Rate - 1 (default)
> + - 2 # Dividing Rate - 1/2
> + - 3 # Dividing Rate - 1/4
> + - 4 # Dividing Rate - 8
> + - 5 # Dividing Rate - 4
> + - 6 # Dividing Rate - Reserved
> + - 7 # Dividing Rate - Reserved
Ditto.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: clock: Convert i.MX7D clock to json-schema
From: Anson Huang @ 2020-05-18 14:06 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
Frank.Li, linux-clk, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
Convert the i.MX7D clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx7d-clock.txt | 13 -----
.../devicetree/bindings/clock/imx7d-clock.yaml | 64 ++++++++++++++++++++++
2 files changed, 64 insertions(+), 13 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.txt b/Documentation/devicetree/bindings/clock/imx7d-clock.txt
deleted file mode 100644
index 9d3026d..0000000
--- a/Documentation/devicetree/bindings/clock/imx7d-clock.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* Clock bindings for Freescale i.MX7 Dual
-
-Required properties:
-- compatible: Should be "fsl,imx7d-ccm"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-- clocks: list of clock specifiers, must contain an entry for each required
- entry in clock-names
-- clock-names: should include entries "ckil", "osc"
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx7d-clock.h
-for the full list of i.MX7 Dual clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.yaml b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
new file mode 100644
index 0000000..72eb13f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx7d-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX7 Dual
+
+maintainers:
+ - Frank Li <Frank.Li@freescale.com>
+ - Anson Huang <Anson.Huang@nxp.com>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx7d-clock.h
+ for the full list of i.MX7 Dual clock IDs.
+
+properties:
+ compatible:
+ const: fsl,imx7d-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: CCM interrupt request 1
+ - description: CCM interrupt request 2
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: 32k osc
+ - description: 24m osc
+
+ clock-names:
+ items:
+ - const: ckil
+ - const: osc
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@30380000 {
+ compatible = "fsl,imx7d-ccm";
+ reg = <0x30380000 0x10000>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ #clock-cells = <1>;
+ clocks = <&ckil>, <&osc>;
+ clock-names = "ckil", "osc";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PING] [PATCH v2] arm: ptrace: Fix mask for thumb breakpoint hook
From: Russell King - ARM Linux admin @ 2020-05-18 14:18 UTC (permalink / raw)
To: Fredrik Strupe; +Cc: linux-kernel, linux-arm-kernel, Oleg Nesterov
In-Reply-To: <d7381f90-f597-2a9c-4387-5714b41e02e6@strupe.net>
On Mon, May 18, 2020 at 03:12:06PM +0200, Fredrik Strupe wrote:
> call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
> and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
> (0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
> instructions will be masked out. This makes the function match 32-bit
> thumb instructions where the second half-word is equal to instr_val,
> regardless of the first half-word.
>
> The result in this case is that all undefined 32-bit thumb instructions
> with the second half-word equal to de01 (udf #1) work as breakpoints
> and will raise a SIGTRAP instead of a SIGILL, instead of just the one
> intended 16-bit instruction. An example of such an instruction is
> eaa0b650, which is unallocated according to Arm ARM and should raise a
> SIGILL, but instead raises a SIGTRAP.
How can 0xeaa0b650 match 0xde01 when masked with 0xffff ?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps 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/3] arm64: perf: Add support for Perf NMI interrupts
From: Mark Rutland @ 2020-05-18 14:19 UTC (permalink / raw)
To: Sumit Garg
Cc: Jian-Lin Chen, Will Deacon, alexander.shishkin, Catalin Marinas,
jolsa, Linux Kernel Mailing List, acme, Lecopzer Chen,
Peter Zijlstra, mingo, linux-mediatek, linux-arm-kernel,
matthias.bgg, namhyung, Alexandru Elisei, yj.chiang,
julien.thierry.kdev
In-Reply-To: <CAFA6WYPKD0Kkn5yQiKZQkM+tT0iW4oPnndegD-iau9EwB5DYog@mail.gmail.com>
On Mon, May 18, 2020 at 07:39:23PM +0530, Sumit Garg wrote:
> On Mon, 18 May 2020 at 16:47, Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> > On 5/18/20 11:45 AM, Mark Rutland wrote:
> > > On Mon, May 18, 2020 at 02:26:00PM +0800, Lecopzer Chen wrote:
> > >> HI Sumit,
> > >>
> > >> Thanks for your information.
> > >>
> > >> I've already implemented IPI (same as you did [1], little difference
> > >> in detail), hardlockup detector and perf in last year(2019) for
> > >> debuggability.
> > >> And now we tend to upstream to reduce kernel maintaining effort.
> > >> I'm glad if someone in ARM can do this work :)
> > >>
> > >> Hi Julien,
> > >>
> > >> Does any Arm maintainers can proceed this action?
> > > Alexandru (Cc'd) has been rebasing and reworking Julien's patches, which
> > > is my preferred approach.
> > >
> > > I understand that's not quite ready for posting since he's investigating
> > > some of the nastier subtleties (e.g. mutual exclusion with the NMI), but
> > > maybe we can put the work-in-progress patches somewhere in the mean
> > > time.
> > >
> > > Alexandru, do you have an idea of what needs to be done, and/or when you
> > > expect you could post that?
> >
> > I'm currently working on rebasing the patches on top of 5.7-rc5, when I have
> > something usable I'll post a link (should be a couple of days). After that I will
> > address the review comments, and I plan to do a thorough testing because I'm not
> > 100% confident that some of the assumptions around the locks that were removed are
> > correct. My guess is this will take a few weeks.
> >
>
> Thanks Mark, Alex for the status updates on perf NMI feature.
>
> Alex,
>
> As the hard-lockup detection patch [1] has a dependency on perf NMI
> patch-set, I will rebase and test hard-lockup detector when you have
> got a working tree. But due to the dependency, I think patch [1]
> should be accepted along with perf NMI patch-set. So would you be open
> to include this patch as part of your series?
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html
While it depends on the perf NMI bits, I don't think it makes sense to
tie that into the series given it's trying to achieve something very
different.
I think that should be reposted separately once the perf NMI bits are in
shape.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 0/7] Support inhibiting input devices
From: Hans de Goede @ 2020-05-18 14:23 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, linux-input, linux-acpi, linux-iio,
linux-arm-kernel, linux-samsung-soc, linux-tegra, patches,
ibm-acpi-devel, platform-driver-x86
Cc: Nick Dyer, Benjamin Tissoires, Laxman Dewangan,
Peter Meerwald-Stadler, kernel, Fabio Estevam, Lars-Peter Clausen,
Krzysztof Kozlowski, Jonathan Hunter, Kukjin Kim, NXP Linux Team,
Sylvain Lemieux, Len Brown, Peter Hutterer, Michael Hennerich,
Sascha Hauer, Henrique de Moraes Holschuh, Vladimir Zapolskiy,
Barry Song, Ferruh Yigit, Dmitry Torokhov, Rafael J . Wysocki,
Thierry Reding, Sangwon Jee, Pengutronix Kernel Team,
Hartmut Knaack, Shawn Guo, Jonathan Cameron
In-Reply-To: <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com>
Hi,
On 5/18/20 3:49 PM, Andrzej Pietrasiewicz wrote:
> Hi Hans,
>
> W dniu 18.05.2020 o 14:24, Hans de Goede pisze:
>> Hi,
>>
>> On 5/18/20 12:48 PM, Andrzej Pietrasiewicz wrote:
>>> Hi Hans,
>>>
>>> W dniu 15.05.2020 o 20:19, Hans de Goede pisze:
>>>> Hi Andrezj,
>>>>
>>>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote:
>>>>> Userspace might want to implement a policy to temporarily disregard input
>>>>> from certain devices, including not treating them as wakeup sources.
>>>>>
>>>>> An example use case is a laptop, whose keyboard can be folded under the
>>>>> screen to create tablet-like experience. The user then must hold the laptop
>>>>> in such a way that it is difficult to avoid pressing the keyboard keys. It
>>>>> is therefore desirable to temporarily disregard input from the keyboard,
>>>>> until it is folded back. This obviously is a policy which should be kept
>>>>> out of the kernel, but the kernel must provide suitable means to implement
>>>>> such a policy.
>>>>
>>>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE
>>>> generating evdev nodes and e.g. internal keyboards on devices with 360°
>>>> hinges for this reason. libinput simply closes the /dev/input/event#
>>>> node when folded and re-opens it when the keyboard should become active
>>>> again. Thus not only suppresses events but allows e.g. touchpads to
>>>> enter runtime suspend mode which saves power. Typically closing the
>>>> /dev/input/event# node will also disable the device as wakeup source.
>>>>
>>>> So I wonder what this series actually adds for functionality for
>>>> userspace which can not already be achieved this way?
>>>>
>>>> I also noticed that you keep the device open (do not call the
>>>> input_device's close callback) when inhibited and just throw away
>>>
>>> I'm not sure if I understand you correctly, it is called:
>>>
>>> +static inline void input_stop(struct input_dev *dev)
>>> +{
>>> + if (dev->poller)
>>> + input_dev_poller_stop(dev->poller);
>>> + if (dev->close)
>>> + dev->close(dev);
>>> ^^^^^^^^^^^^^^^^
>>> +static int input_inhibit(struct input_dev *dev)
>>> +{
>>> + int ret = 0;
>>> +
>>> + mutex_lock(&dev->mutex);
>>> +
>>> + if (dev->inhibited)
>>> + goto out;
>>> +
>>> + if (dev->users) {
>>> + if (dev->inhibit) {
>>> + ret = dev->inhibit(dev);
>>> + if (ret)
>>> + goto out;
>>> + }
>>> + input_stop(dev);
>>> ^^^^^^^^^^^^^^^^
>>>
>>> It will not be called when dev->users is zero, but if it is zero,
>>> then nobody has opened the device yet so there is nothing to close.
>>
>> Ah, I missed that.
>>
>> So if the device implements the inhibit call back then on
>> inhibit it will get both the inhibit and close callback called?
>>
>
> That's right. And conversely, upon uninhibit open() and uninhibit()
> callbacks will be invoked. Please note that just as with open()/close(),
> providing inhibit()/uninhibit() is optional.
Ack.
>> And what happens if the last user goes away and the device
>> is not inhibited?
>
> close() is called as usually.
But not inhibit, hmm, see below.
>> I'm trying to understand here what the difference between the 2
>> is / what the goal of having a separate inhibit callback ?
>>
>
> Drivers have very different ideas about what it means to suspend/resume
> and open/close. The optional inhibit/uninhibit callbacks are meant for
> the drivers to know that it is this particular action going on.
So the inhibit() callback triggers the "suspend" behavior ?
But shouldn't drivers which are capable of suspending the device
always do so on close() ?
Since your current proposal also calls close() on inhibit() I
really see little difference between an inhibit() and the last
user of the device closing it and IMHO unless there is a good
reason to actually differentiate the 2 it would be better
to only stick with the existing close() and in cases where
that does not put the device in a low-power mode yet, fix
the existing close() callback to do the low-power mode
setting instead of adding a new callback.
> For inhibit() there's one more argument: close() does not return a value,
> so its meaning is "do some last cleanup" and as such it is not allowed
> to fail - whatever its effect is, we must deem it successful. inhibit()
> does return a value and so it is allowed to fail.
Well, we could make close() return an error and at least in the inhibit()
case propagate that to userspace. I wonder if userspace is going to
do anything useful with that error though...
In my experience errors during cleanup/shutdown are best logged
(using dev_err) and otherwise ignored, so that we try to clean up
as much possible. Unless the very first step of the shutdown process
fails the device is going to be in some twilight zone state anyways
at this point we might as well try to cleanup as much as possible.
> All in all, it is up to the drivers to decide which callback they
> provide. Based on my work so far I would say that there are tens
> of simple cases where open() and close() are sufficient, out of total
> ~400 users of input_allocate_device():
>
> $ git grep "input_allocate_device(" | grep -v ^Documentation | \
> cut -f1 -d: | sort | uniq | wc
> 390 390 13496
So can you explain a bit more about the cases where only having
open/close is not sufficient? So far I have the feeling that
those are all we need and that we really do not need separate
[un]inhibit callbacks.
Regards,
Hans
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V6, 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings
From: Rob Herring @ 2020-05-18 14:31 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, linux-devicetree, Andy Shevchenko, srv_heupstream,
Linus Walleij, Shengnan Wang (王圣男),
Louis Kuo, Bartosz Golaszewski, Sj Huang, Nicolas Boichat,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu,
Sakari Ailus, Matthias Brugger, Cao Bing Bu,
Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <CAAFQd5Byvc8Fb0f3_81xSKsuyvsQJm-8g8y1Kx2aUcC=PwpS7w@mail.gmail.com>
On Mon, May 18, 2020 at 04:12:28PM +0200, Tomasz Figa wrote:
> Hi Dongchun,
>
> On Mon, May 18, 2020 at 3:29 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Add DeviceTree binding documentation for Dongwoon Anatech DW9768 voice
> > coil actuator.
>
> Thanks for the patch. Please see my comments below.
>
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> This version includes significant changes, so the reviewed-by tag
> shouldn't have been carried out.
>
> > ---
> > .../bindings/media/i2c/dongwoon,dw9768.yaml | 105 +++++++++++++++++++++
> > MAINTAINERS | 7 ++
> > 2 files changed, 112 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> > new file mode 100644
> > index 0000000..b909e83
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
> > @@ -0,0 +1,105 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter
> > + with 100 mA output current sink capability. VCM current is controlled with
> > + a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible)
> > + serial interface that operates at clock rates up to 1MHz. This chip
> > + integrates Advanced Actuator Control (AAC) technology and is intended for
> > + driving voice coil lenses in camera modules.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + # for DW9768 VCM
> > + - dongwoon,dw9768
> > + # for GT9769 VCM
> > + - giantec,gt9769
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + vin-supply:
> > + description:
> > + Definition of the regulator used as I2C I/O interface power supply.
> > +
> > + vdd-supply:
> > + description:
> > + Definition of the regulator used as VCM chip power supply.
> > +
> > + dongwoon,aac-mode:
> > + description:
> > + Indication of AAC mode select.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Direct (default)
Default can be expressed as 'default: 0'.
> > + - 1 # AAC2 (operation time# 0.48 x Tvib)
> > + - 2 # AAC3 (operation time# 0.70 x Tvib)
> > + - 3 # AAC4 (operation time# 0.75 x Tvib)
> > + - 4 # Reserved
> > + - 5 # AAC8 (operation time# 1.13 x Tvib)
> > + - 6 # Reserved
> > + - 7 # Reserved
>
> I'll ultimately leave it to DT maintainers, but is there any reason to
> define the reserved values?
No.
>
> > +
> > + dongwoon,aac-timing:
> > + description:
> > + Indication of AAC Timing count, unit of 0.1 milliseconds.
Why not just use standard units (-us)?
> > + Valid values vary from 0 to 63 (default 32).
Looks like constraints.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + dongwoon,clock-dividing-rate:
> > + description:
> > + Indication of VCM internal clock dividing rate select, as one multiple
> > + factor to calculate VCM ring periodic time Tvib.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Dividing Rate - 2
> > + - 1 # Dividing Rate - 1 (default)
> > + - 2 # Dividing Rate - 1/2
> > + - 3 # Dividing Rate - 1/4
> > + - 4 # Dividing Rate - 8
> > + - 5 # Dividing Rate - 4
> > + - 6 # Dividing Rate - Reserved
> > + - 7 # Dividing Rate - Reserved
>
> Ditto.
>
> Best regards,
> Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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