* [PATCH v3 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
From: Maxime Ripard @ 2018-05-07 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180506214901.23429-1-contact@paulk.fr>
Hi,
On Sun, May 06, 2018 at 11:48:59PM +0200, Paul Kocialkowski wrote:
> This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> as found on the Ainol AW1 tablet.
>
> The panel also supports RGB888 output. When RGB666 mode is used instead,
> the two extra lanes per component are grounded.
>
> In the future, it might become necessary to introduce a dedicated
> device-tree property to specify the bus format and maybe specify it in
> the mode description instead of panel description so that the
> appropriate mode can be selected for each bus format.
>
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
A change log would be nice. Also, you mentionned in your first version
that the screen was an AT070TN92, and now you mention that it is an
AT070TN90, which one is it?
Maxime
> ---
> drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index cbf1ab404ee7..351742df8ee1 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1086,6 +1086,29 @@ static const struct panel_desc innolux_at070tn92 = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> };
>
> +static const struct drm_display_mode innolux_at070tn90_mode = {
> + .clock = 40000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 112,
> + .hsync_end = 800 + 112 + 1,
> + .htotal = 800 + 112 + 1 + 87,
> + .vdisplay = 480,
> + .vsync_start = 480 + 141,
> + .vsync_end = 480 + 141 + 1,
> + .vtotal = 480 + 141 + 1 + 38,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc innolux_at070tn90 = {
> + .modes = &innolux_at070tn90_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> +};
> +
> static const struct display_timing innolux_g101ice_l01_timing = {
> .pixelclock = { 60400000, 71100000, 74700000 },
> .hactive = { 1280, 1280, 1280 },
> @@ -2154,6 +2177,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "innolux,at070tn92",
> .data = &innolux_at070tn92,
> + }, {
> + .compatible = "innolux,at070tn90",
> + .data = &innolux_at070tn90,
This should be ordered alphabetically.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180507/c2eb471e/attachment.sig>
^ permalink raw reply
* [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
From: Ingo Molnar @ 2018-05-07 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525655045.499830.1362901928.0EBFEACA@webmail.messagingengine.com>
* Boqun Feng <boqun.feng@gmail.com> wrote:
>
>
> On Sun, May 6, 2018, at 8:11 PM, Ingo Molnar wrote:
> >
> > * Boqun Feng <boqun.feng@gmail.com> wrote:
> >
> > > > The only change I made beyond a trivial build fix is that I also added the release
> > > > atomics variants explicitly:
> > > >
> > > > +#define atomic_cmpxchg_release(v, o, n) \
> > > > + cmpxchg_release(&((v)->counter), (o), (n))
> > > > +#define atomic64_cmpxchg_release(v, o, n) \
> > > > + cmpxchg_release(&((v)->counter), (o), (n))
> > > >
> > > > It has passed a PowerPC cross-build test here, but no runtime tests.
> > > >
> > >
> > > Do you have the commit at any branch in tip tree? I could pull it and
> > > cross-build and check the assembly code of lib/atomic64_test.c, that way
> > > I could verify whether we mess something up.
> > >
> > > > Does this patch look good to you?
> > > >
> > >
> > > Yep!
> >
> > Great - I have pushed the commits out into the locking tree, they can be
> > found in:
> >
> > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > locking/core
> >
>
> Thanks! My compile test told me that we need to remove the definitions of
> atomic_xchg and atomic64_xchg in ppc's asm/atomic.h: they are now
> duplicate, and will prevent the generation of _release and _acquire in the
> new logic.
>
> If you need a updated patch for this from me, I could send later today.
> (I don't have a handy environment for patch sending now, so...)
That would be cool, thanks! My own cross-build testing didn't trigger that build
failure.
> Other than this, the modification looks fine, the lib/atomic64_test.c
> generated the same asm before and after the patches.
Cool, thanks for checking!
Thanks,
Ingo
^ permalink raw reply
* [RFC PATCH] locking/atomics/x86/64: Clean up and fix details of <asm/atomic64_64.h>
From: Ingo Molnar @ 2018-05-07 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505093237.GD12217@hirez.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, May 05, 2018 at 11:05:51AM +0200, Dmitry Vyukov wrote:
> > On Sat, May 5, 2018 at 10:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > And I seriously hate this one:
> > >
> > > ba1c9f83f633 ("locking/atomic/x86: Un-macro-ify atomic ops implementation")
> > >
> > > and will likely undo that the moment I need to change anything there.
>
> > That was asked by Ingo:
> > https://groups.google.com/d/msg/kasan-dev/3sNHjjb4GCI/Xz1uVWaaAAAJ
> >
> > I think in the end all of current options suck in one way or another,
> > so we are just going in circles.
>
> Yeah, and I disagree with him, but didn't have the energy to fight at
> that time (and still don't really, I'm just complaining).
Ok, this negative side effect of the un-macro-ifying still bothers me, so I tried
to do something about it:
1 file changed, 81 insertions(+), 172 deletions(-)
That's actually better than what we had before ba1c9f83f633, which did:
3 files changed, 147 insertions(+), 70 deletions(-)
( Also consider that my patch adds new DocBook comments and only touches the
64-bit side, so if we do the same to the 32-bit header as well we'll gain even
more. )
But I don't think you'll like my solution: it requires twice as wide terminals to
look at those particular functions...
The trick is to merge the C functions into a single line: this makes it look a bit
weird, but it's still very readable (because the functions are simple), and, most
importantly, the _differences_ are now easily visible.
This is how that part looks like on my terminal:
... do { } while (!arch_atomic64_try_cmpxchg(v, &val, val & i)); return val; }
... do { } while (!arch_atomic64_try_cmpxchg(v, &val, val | i)); return val; }
... do { } while (!arch_atomic64_try_cmpxchg(v, &val, val ^ i)); return val; }
...
... { asm(LOCK_PREFIX "orq %1,%0" : "+m" (v->counter) : "er" (i) : "memory"); }
... { asm(LOCK_PREFIX "xorq %1,%0" : "+m" (v->counter) : "er" (i) : "memory"); }
... { asm(LOCK_PREFIX "andq %1,%0" : "+m" (v->counter) : "er" (i) : "memory"); }
Which makes the '&|^' and orq/xorq/andq differences easily visible. I kept all
those long lines at the end of the header, to make it easy not to look at it,
unless someone wants to actively change or understand the code.
The prototype/parameters are visible even with col80 terminals.
But please give it a try and at least _look_ at the result in a double-wide
terminal.
There's also a ton of other small fixes and enhancements I did to the header file
- see the changelog.
But I won't commit this without your explicit Acked-by.
Thanks,
Ingo
================>
From: Ingo Molnar <mingo@kernel.org>
Date: Mon, 7 May 2018 07:59:12 +0200
Subject: [PATCH] locking/atomics/x86/64: Clean up and fix details of <asm/atomic64_64.h>
PeterZ complained that the following macro elimination:
ba1c9f83f633: locking/atomic/x86: Un-macro-ify atomic ops implementation
bloated the header and made it less readable/maintainable.
Try to undo some of that damage, without reintroducing a macro mess:
- Merge the previously macro generated C inline functions into a single line.
While this looks weird on smaller terminals because of line wraps
(and violates the col80 style rule brutally), it's surprisingly readable
on larger terminals. An advantage with this format is that the repeated
patterns are obviously visible, while the actual differences stick out
very clearly. To me this is much more readable than the old macro solution.
While at it, also do a no-prisoners taken cleanup pass of all the code and comments
in this file:
- Fix the DocBook comment of arch_atomic64_add_unless(), which incorrectly claimed:
"Returns the old value of @v."
In reality the function returns true if the operation was performed, or false otherwise.
- Fix __always_inline use: where one member of a 'pair' of an operation has it,
add it to both. There's no reason for them to ever deviate.
- Fix/clarify the arch_atomic64_read() documentation: it not only reads but also
returns the value.
- Fix DocBook comments that referred to 'i' and 'v' instead of '@i' and '@v'.
- Remove unnecessary parentheses from arch_atomic64_read() that was probably
inherited from ancient macro versions.
- Add DocBook description for arch_atomic64_[add|sub]_return() and
arch_atomic64_fetch_[add|sub]().
- Harmonize to a single variant of referring to atomic64_t pointers in
comments, instead of these two variants:
"@v: pointer of type atomic64_t"
"@v: pointer to type atomic64_t"
Use a single, shorter variant:
"@v: pointer to atomic64_t"
(Because the _t already implies that this is a type - no need to repeat that.)
- Harmonize local variable naming, from a sometimes inconsistent selection of ad-hoc
and sometimes cryptic variable names ('c', 'val', 'dec', 'val_old', etc.), to the
following set of standardized local variable names:
'i' for integer arguments
'val_old' for old atomic values
'val_new' for old atomic values
From now on the name of the local variable is "obviously descriptive" of its
role in the code.
- Add newlines after local variable definitions and before return statements, consistently.
- Change weird "@i: required value" phrase (all arguments to function calls are
required, what does 'required' mean here?) to '@i: new value'
- Add "Doesn't imply a write memory barrier" to arch_atomic64_set(), to
mirror the read barrier comment of arch_atomic64_read().
- Change the weird "or false for all other cases" phrase to the simpler "or false otherwise"
formulation that is standard in DocBook comments.
- Harmonize the punctuation of DocBook comments: detailed descriptions always end with a period.
- Change the order of addition in the arch_atomic64_[add|sub]_return() code,
to make it match the order in the description. (No change in functionality,
addition is commutative.)
- Remove unnecessary double newlines.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/include/asm/atomic64_64.h | 253 ++++++++++++-------------------------
1 file changed, 81 insertions(+), 172 deletions(-)
diff --git a/arch/x86/include/asm/atomic64_64.h b/arch/x86/include/asm/atomic64_64.h
index 6106b59d3260..1c451871b391 100644
--- a/arch/x86/include/asm/atomic64_64.h
+++ b/arch/x86/include/asm/atomic64_64.h
@@ -12,22 +12,23 @@
/**
* arch_atomic64_read - read atomic64 variable
- * @v: pointer of type atomic64_t
+ * @v: pointer to atomic64_t
*
- * Atomically reads the value of @v.
+ * Atomically reads and returns the value of @v.
* Doesn't imply a read memory barrier.
*/
static inline long arch_atomic64_read(const atomic64_t *v)
{
- return READ_ONCE((v)->counter);
+ return READ_ONCE(v->counter);
}
/**
* arch_atomic64_set - set atomic64 variable
- * @v: pointer to type atomic64_t
- * @i: required value
+ * @v: pointer to atomic64_t
+ * @i: new value
*
* Atomically sets the value of @v to @i.
+ * Doesn't imply a write memory barrier.
*/
static inline void arch_atomic64_set(atomic64_t *v, long i)
{
@@ -35,41 +36,22 @@ static inline void arch_atomic64_set(atomic64_t *v, long i)
}
/**
- * arch_atomic64_add - add integer to atomic64 variable
- * @i: integer value to add
- * @v: pointer to type atomic64_t
+ * arch_atomic64_[add|sub] - add|subtract integer to/from atomic64 variable
+ * @i: integer value to add/subtract
+ * @v: pointer to atomic64_t
*
- * Atomically adds @i to @v.
+ * Atomically adds/subtracts @i to/from @v.
*/
-static __always_inline void arch_atomic64_add(long i, atomic64_t *v)
-{
- asm volatile(LOCK_PREFIX "addq %1,%0"
- : "=m" (v->counter)
- : "er" (i), "m" (v->counter));
-}
-
-/**
- * arch_atomic64_sub - subtract the atomic64 variable
- * @i: integer value to subtract
- * @v: pointer to type atomic64_t
- *
- * Atomically subtracts @i from @v.
- */
-static inline void arch_atomic64_sub(long i, atomic64_t *v)
-{
- asm volatile(LOCK_PREFIX "subq %1,%0"
- : "=m" (v->counter)
- : "er" (i), "m" (v->counter));
-}
+static __always_inline void arch_atomic64_sub(long i, atomic64_t *v) { asm(LOCK_PREFIX "subq %1,%0" : "=m" (v->counter) : "er" (i), "m" (v->counter)); }
+static __always_inline void arch_atomic64_add(long i, atomic64_t *v) { asm(LOCK_PREFIX "addq %1,%0" : "=m" (v->counter) : "er" (i), "m" (v->counter)); }
/**
* arch_atomic64_sub_and_test - subtract value from variable and test result
* @i: integer value to subtract
- * @v: pointer to type atomic64_t
+ * @v: pointer to atomic64_t
*
* Atomically subtracts @i from @v and returns
- * true if the result is zero, or false for all
- * other cases.
+ * true if the result is zero, or false otherwise.
*/
static inline bool arch_atomic64_sub_and_test(long i, atomic64_t *v)
{
@@ -77,133 +59,101 @@ static inline bool arch_atomic64_sub_and_test(long i, atomic64_t *v)
}
/**
- * arch_atomic64_inc - increment atomic64 variable
- * @v: pointer to type atomic64_t
+ * arch_atomic64_[inc|dec] - increment/decrement atomic64 variable
+ * @v: pointer to atomic64_t
*
- * Atomically increments @v by 1.
+ * Atomically increments/decrements @v by 1.
*/
-static __always_inline void arch_atomic64_inc(atomic64_t *v)
-{
- asm volatile(LOCK_PREFIX "incq %0"
- : "=m" (v->counter)
- : "m" (v->counter));
-}
+static __always_inline void arch_atomic64_inc(atomic64_t *v) { asm(LOCK_PREFIX "incq %0" : "=m" (v->counter) : "m" (v->counter)); }
+static __always_inline void arch_atomic64_dec(atomic64_t *v) { asm(LOCK_PREFIX "decq %0" : "=m" (v->counter) : "m" (v->counter)); }
/**
- * arch_atomic64_dec - decrement atomic64 variable
- * @v: pointer to type atomic64_t
+ * arch_atomic64_[inc|dec]_and_test - increment/decrement and test
+ * @v: pointer to atomic64_t
*
- * Atomically decrements @v by 1.
+ * Atomically increments/decrements @v by 1 and
+ * returns true if the result is 0, or false otherwise.
*/
-static __always_inline void arch_atomic64_dec(atomic64_t *v)
-{
- asm volatile(LOCK_PREFIX "decq %0"
- : "=m" (v->counter)
- : "m" (v->counter));
-}
+static inline bool arch_atomic64_dec_and_test(atomic64_t *v) { GEN_UNARY_RMWcc(LOCK_PREFIX "decq", v->counter, "%0", e); }
+static inline bool arch_atomic64_inc_and_test(atomic64_t *v) { GEN_UNARY_RMWcc(LOCK_PREFIX "incq", v->counter, "%0", e); }
/**
- * arch_atomic64_dec_and_test - decrement and test
- * @v: pointer to type atomic64_t
+ * arch_atomic64_add_negative - add and test if negative
+ * @i: integer value to add
+ * @v: pointer to atomic64_t
*
- * Atomically decrements @v by 1 and
- * returns true if the result is 0, or false for all other
- * cases.
+ * Atomically adds @i to @v and returns true
+ * if the result is negative, or false otherwise.
*/
-static inline bool arch_atomic64_dec_and_test(atomic64_t *v)
+static inline bool arch_atomic64_add_negative(long i, atomic64_t *v)
{
- GEN_UNARY_RMWcc(LOCK_PREFIX "decq", v->counter, "%0", e);
+ GEN_BINARY_RMWcc(LOCK_PREFIX "addq", v->counter, "er", i, "%0", s);
}
/**
- * arch_atomic64_inc_and_test - increment and test
- * @v: pointer to type atomic64_t
+ * arch_atomic64_[add|sub]_return - add/subtract and return
+ * @i: integer value to add/subtract
+ * @v: pointer to atomic64_t
*
- * Atomically increments @v by 1
- * and returns true if the result is zero, or false for all
- * other cases.
+ * Atomically adds/subtracts @i to/from @v and returns the new value of @v.
*/
-static inline bool arch_atomic64_inc_and_test(atomic64_t *v)
-{
- GEN_UNARY_RMWcc(LOCK_PREFIX "incq", v->counter, "%0", e);
-}
+static __always_inline long arch_atomic64_add_return(long i, atomic64_t *v) { return xadd(&v->counter, +i) + i; }
+static __always_inline long arch_atomic64_sub_return(long i, atomic64_t *v) { return xadd(&v->counter, -i) - i; }
/**
- * arch_atomic64_add_negative - add and test if negative
- * @i: integer value to add
- * @v: pointer to type atomic64_t
+ * arch_atomic64_fetch_[add|sub]_return - add/subtract and return old value
+ * @i: integer value to add/subtract
+ * @v: pointer to atomic64_t
*
- * Atomically adds @i to @v and returns true
- * if the result is negative, or false when
- * result is greater than or equal to zero.
+ * Atomically adds/subtracts @i to/from @v and returns the old value of @v.
*/
-static inline bool arch_atomic64_add_negative(long i, atomic64_t *v)
-{
- GEN_BINARY_RMWcc(LOCK_PREFIX "addq", v->counter, "er", i, "%0", s);
-}
+static __always_inline long arch_atomic64_fetch_add (long i, atomic64_t *v) { return xadd(&v->counter, +i); }
+static __always_inline long arch_atomic64_fetch_sub (long i, atomic64_t *v) { return xadd(&v->counter, -i); }
/**
- * arch_atomic64_add_return - add and return
- * @i: integer value to add
- * @v: pointer to type atomic64_t
+ * arch_atomic64_[inc|dec]_return - increment/decrement and return
+ * @v: pointer to atomic64_t
*
- * Atomically adds @i to @v and returns @i + @v
+ * Atomically increments/decrements @v and returns the new value of @v.
*/
-static __always_inline long arch_atomic64_add_return(long i, atomic64_t *v)
-{
- return i + xadd(&v->counter, i);
-}
-
-static inline long arch_atomic64_sub_return(long i, atomic64_t *v)
-{
- return arch_atomic64_add_return(-i, v);
-}
+#define arch_atomic64_inc_return(v) arch_atomic64_add_return(1, (v))
+#define arch_atomic64_dec_return(v) arch_atomic64_sub_return(1, (v))
-static inline long arch_atomic64_fetch_add(long i, atomic64_t *v)
+static inline long arch_atomic64_cmpxchg(atomic64_t *v, long val_old, long val_new)
{
- return xadd(&v->counter, i);
-}
-
-static inline long arch_atomic64_fetch_sub(long i, atomic64_t *v)
-{
- return xadd(&v->counter, -i);
-}
-
-#define arch_atomic64_inc_return(v) (arch_atomic64_add_return(1, (v)))
-#define arch_atomic64_dec_return(v) (arch_atomic64_sub_return(1, (v)))
-
-static inline long arch_atomic64_cmpxchg(atomic64_t *v, long old, long new)
-{
- return arch_cmpxchg(&v->counter, old, new);
+ return arch_cmpxchg(&v->counter, val_old, val_new);
}
#define arch_atomic64_try_cmpxchg arch_atomic64_try_cmpxchg
-static __always_inline bool arch_atomic64_try_cmpxchg(atomic64_t *v, s64 *old, long new)
+
+static __always_inline bool arch_atomic64_try_cmpxchg(atomic64_t *v, s64 *val_old, long val_new)
{
- return try_cmpxchg(&v->counter, old, new);
+ return try_cmpxchg(&v->counter, val_old, val_new);
}
-static inline long arch_atomic64_xchg(atomic64_t *v, long new)
+static inline long arch_atomic64_xchg(atomic64_t *v, long val_new)
{
- return xchg(&v->counter, new);
+ return xchg(&v->counter, val_new);
}
/**
* arch_atomic64_add_unless - add unless the number is a given value
- * @v: pointer of type atomic64_t
- * @a: the amount to add to v...
- * @u: ...unless v is equal to u.
+ * @v: pointer to atomic64_t
+ * @i: the amount to add to @v...
+ * @u: ...unless @v is equal to @u
*
- * Atomically adds @a to @v, so long as it was not @u.
- * Returns the old value of @v.
+ * Atomically adds @i to @v, so long as @v was not @u.
+ * Returns true if the operation was performed, or false otherwise.
*/
-static inline bool arch_atomic64_add_unless(atomic64_t *v, long a, long u)
+static inline bool arch_atomic64_add_unless(atomic64_t *v, long i, long u)
{
- s64 c = arch_atomic64_read(v);
+ s64 val_old = arch_atomic64_read(v);
+
do {
- if (unlikely(c == u))
+ if (unlikely(val_old == u))
return false;
- } while (!arch_atomic64_try_cmpxchg(v, &c, c + a));
+ } while (!arch_atomic64_try_cmpxchg(v, &val_old, val_old + i));
+
return true;
}
@@ -211,71 +161,30 @@ static inline bool arch_atomic64_add_unless(atomic64_t *v, long a, long u)
/*
* arch_atomic64_dec_if_positive - decrement by 1 if old value positive
- * @v: pointer of type atomic_t
+ * @v: pointer to type atomic_t
*
* The function returns the old value of *v minus 1, even if
- * the atomic variable, v, was not decremented.
+ * @v was not decremented.
*/
static inline long arch_atomic64_dec_if_positive(atomic64_t *v)
{
- s64 dec, c = arch_atomic64_read(v);
- do {
- dec = c - 1;
- if (unlikely(dec < 0))
- break;
- } while (!arch_atomic64_try_cmpxchg(v, &c, dec));
- return dec;
-}
-
-static inline void arch_atomic64_and(long i, atomic64_t *v)
-{
- asm volatile(LOCK_PREFIX "andq %1,%0"
- : "+m" (v->counter)
- : "er" (i)
- : "memory");
-}
-
-static inline long arch_atomic64_fetch_and(long i, atomic64_t *v)
-{
- s64 val = arch_atomic64_read(v);
-
- do {
- } while (!arch_atomic64_try_cmpxchg(v, &val, val & i));
- return val;
-}
-
-static inline void arch_atomic64_or(long i, atomic64_t *v)
-{
- asm volatile(LOCK_PREFIX "orq %1,%0"
- : "+m" (v->counter)
- : "er" (i)
- : "memory");
-}
-
-static inline long arch_atomic64_fetch_or(long i, atomic64_t *v)
-{
- s64 val = arch_atomic64_read(v);
+ s64 val_new, val = arch_atomic64_read(v);
do {
- } while (!arch_atomic64_try_cmpxchg(v, &val, val | i));
- return val;
-}
+ val_new = val - 1;
+ if (unlikely(val_new < 0))
+ break;
+ } while (!arch_atomic64_try_cmpxchg(v, &val, val_new));
-static inline void arch_atomic64_xor(long i, atomic64_t *v)
-{
- asm volatile(LOCK_PREFIX "xorq %1,%0"
- : "+m" (v->counter)
- : "er" (i)
- : "memory");
+ return val_new;
}
-static inline long arch_atomic64_fetch_xor(long i, atomic64_t *v)
-{
- s64 val = arch_atomic64_read(v);
+static inline long arch_atomic64_fetch_and(long i, atomic64_t *v) { s64 val = arch_atomic64_read(v); do { } while (!arch_atomic64_try_cmpxchg(v, &val, val & i)); return val; }
+static inline long arch_atomic64_fetch_or (long i, atomic64_t *v) { s64 val = arch_atomic64_read(v); do { } while (!arch_atomic64_try_cmpxchg(v, &val, val | i)); return val; }
+static inline long arch_atomic64_fetch_xor(long i, atomic64_t *v) { s64 val = arch_atomic64_read(v); do { } while (!arch_atomic64_try_cmpxchg(v, &val, val ^ i)); return val; }
- do {
- } while (!arch_atomic64_try_cmpxchg(v, &val, val ^ i));
- return val;
-}
+static inline void arch_atomic64_or (long i, atomic64_t *v) { asm(LOCK_PREFIX "orq %1,%0" : "+m" (v->counter) : "er" (i) : "memory"); }
+static inline void arch_atomic64_xor(long i, atomic64_t *v) { asm(LOCK_PREFIX "xorq %1,%0" : "+m" (v->counter) : "er" (i) : "memory"); }
+static inline void arch_atomic64_and(long i, atomic64_t *v) { asm(LOCK_PREFIX "andq %1,%0" : "+m" (v->counter) : "er" (i) : "memory"); }
#endif /* _ASM_X86_ATOMIC64_64_H */
^ permalink raw reply related
* [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver
From: Tomasz Figa @ 2018-05-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507063814.vweb4p3nfgnoc3td@tarshish>
On Mon, May 7, 2018 at 3:38 PM Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Tomasz,
> On Mon, May 07, 2018 at 06:13:27AM +0000, Tomasz Figa wrote:
> > On Thu, May 3, 2018 at 6:09 PM Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote:
> > > > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on)
> > > > +{
> > > > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > > > + int ret;
> > > > +
> > > > + v4l2_dbg(1, rkisp1_debug, &isp_dev->v4l2_dev, "s_power: %d\n",
> > on);
> > > > +
> > > > + if (on) {
> > > > + ret = pm_runtime_get_sync(isp_dev->dev);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + rkisp1_config_clk(isp_dev);
> > > > + } else {
> > > > + ret = pm_runtime_put(isp_dev->dev);
> >
> > > I commented this line out to make more than one STREAMON work.
Otherwise,
> > > the second STREAMON hangs. I guess the bug is not this driver.
Probably
> > > something in drivers/soc/rockchip/pm_domains.c. Just noting that in
case
> > > you or someone on Cc would like to investigate it further.
> > >
> > > I tested v4.16-rc4 on the Tinkerboard.
> >
> > Looks like that version doesn't include the IOMMU PM and clock handling
> > rework [1], which should fix a lot of runtime PM issues. FWIW,
linux-next
> > seems to already include it.
> >
> > [1] https://lkml.org/lkml/2018/3/23/44
> Thanks for the reference.
> It looks like the iommu driver part is in Linus' tree already. The DT
part is
> in the v4.18-armsoc/dts32 branch of Heiko's tree. Am I missing anything?
You're right, most of the series made it in time for 4.17. However, the DT
part (precisely, the clocks properties added to IOMMU nodes) is crucial for
the fixes to be effective.
> Anyway, I'll take a look.
Thanks for testing. :) (Forgot to mention in my previous email...)
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx28-cfa10049: Remove unnecessary #address/#size-cells
From: Maxime Ripard @ 2018-05-07 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525655020-31260-1-git-send-email-festevam@gmail.com>
On Sun, May 06, 2018 at 10:03:39PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Remove unnecessary #address-cells/#size-cells to fix the following
> DTC warnings:
>
> arch/arm/boot/dts/imx28-cfa10049.dtb: Warning (avoid_unnecessary_addr_size): /gpio_keys: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180507/3cafc633/attachment.sig>
^ permalink raw reply
* [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver
From: Baruch Siach @ 2018-05-07 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAFQd5CvBv4hkE=PSHBJTYa9Lj0SyggxpMBEAYD=if0=T0uzHw@mail.gmail.com>
Hi Tomasz,
On Mon, May 07, 2018 at 06:13:27AM +0000, Tomasz Figa wrote:
> On Thu, May 3, 2018 at 6:09 PM Baruch Siach <baruch@tkos.co.il> wrote:
> > On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote:
> > > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on)
> > > +{
> > > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > > + int ret;
> > > +
> > > + v4l2_dbg(1, rkisp1_debug, &isp_dev->v4l2_dev, "s_power: %d\n",
> on);
> > > +
> > > + if (on) {
> > > + ret = pm_runtime_get_sync(isp_dev->dev);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + rkisp1_config_clk(isp_dev);
> > > + } else {
> > > + ret = pm_runtime_put(isp_dev->dev);
>
> > I commented this line out to make more than one STREAMON work. Otherwise,
> > the second STREAMON hangs. I guess the bug is not this driver. Probably
> > something in drivers/soc/rockchip/pm_domains.c. Just noting that in case
> > you or someone on Cc would like to investigate it further.
> >
> > I tested v4.16-rc4 on the Tinkerboard.
>
> Looks like that version doesn't include the IOMMU PM and clock handling
> rework [1], which should fix a lot of runtime PM issues. FWIW, linux-next
> seems to already include it.
>
> [1] https://lkml.org/lkml/2018/3/23/44
Thanks for the reference.
It looks like the iommu driver part is in Linus' tree already. The DT part is
in the v4.18-armsoc/dts32 branch of Heiko's tree. Am I missing anything?
Anyway, I'll take a look.
Thanks again,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier
From: Shawn Guo @ 2018-05-07 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525189650-5826-1-git-send-email-festevam@gmail.com>
On Tue, May 01, 2018 at 12:47:29PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH -next v2] gpio: owl: Fix return value check in owl_gpio_probe()
From: Wei Yongjun @ 2018-05-07 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525657224-88189-1-git-send-email-weiyongjun1@huawei.com>
In case of error, the function of_iomap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
v1 -> v2: return -ENXIO instead of -ENOMEM
---
drivers/gpio/gpio-owl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
index 3546362..f35e80f 100644
--- a/drivers/gpio/gpio-owl.c
+++ b/drivers/gpio/gpio-owl.c
@@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
gpio->base = of_iomap(dev->of_node, 0);
- if (IS_ERR(gpio->base))
- return PTR_ERR(gpio->base);
+ if (!gpio->base)
+ return -ENXIO;
/*
* Get the number of gpio's for this bank. If none specified,
^ permalink raw reply related
* [PATCH -next v2] gpio: owl: Fix return value check in owl_gpio_probe()
From: Manivannan Sadhasivam @ 2018-05-07 6:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525674356-39189-1-git-send-email-weiyongjun1@huawei.com>
On Mon, May 07, 2018 at 06:25:56AM +0000, Wei Yongjun wrote:
> In case of error, the function of_iomap() returns NULL pointer not
> ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Thanks,
Mani
> ---
> v1 -> v2: return -ENXIO instead of -ENOMEM
> ---
> drivers/gpio/gpio-owl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
> index 3546362..f35e80f 100644
> --- a/drivers/gpio/gpio-owl.c
> +++ b/drivers/gpio/gpio-owl.c
> @@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> gpio->base = of_iomap(dev->of_node, 0);
> - if (IS_ERR(gpio->base))
> - return PTR_ERR(gpio->base);
> + if (!gpio->base)
> + return -ENXIO;
>
> /*
> * Get the number of gpio's for this bank. If none specified,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 5/9] iio: adc: at91-sama5d2_adc: add support for position and pressure channels
From: Eugen Hristev @ 2018-05-07 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180506175914.GL10960@piout.net>
On 06.05.2018 20:59, Alexandre Belloni wrote:
> Hi,
>
> On 06/05/2018 18:29:53+0100, Jonathan Cameron wrote:
>> On Mon, 30 Apr 2018 13:32:11 +0300
>> Eugen Hristev <eugen.hristev@microchip.com> wrote:
>>
>>> This implements the support for position and pressure for the included
>>> touchscreen support in the SAMA5D2 SOC ADC block.
>>> Two position channels are added and one for pressure.
>>> They can be read in raw format, or through a buffer.
>>> A normal use case is for a consumer driver to register a callback buffer
>>> for these channels.
>>> When the touchscreen channels are in the active scan mask,
>>> the driver will start the touchscreen sampling and push the data to the
>>> buffer.
>>>
>>> Some parts of this patch are based on initial original work by
>>> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
>>>
>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>> Looks good to me now.
>>
>> I'm assuming that once Dmitry and others are happy, I'll take the
>> series through the IIO tree. Will reply to the cover letter if the
>> rest of the patches look good to me to let everyone know that without
>> having to catch this comment down in here!
>>
>
> I'm planning to take both DT patches through the at91 tree once you take
> the DT bindings patches.
Please take into consideration that those DT patches do not build
stand-alone, they depend on
[PATCH v4 7/9] dt-bindings: iio: adc: at91-sama5d2_adc: add channel
specific consumer info
(the DT patches add an include statement of a file which is created in
this patch).
Thanks !
Eugen
>
>
^ permalink raw reply
* [PATCH v6 05/17] media: rkisp1: add Rockchip ISP1 subdev driver
From: Tomasz Figa @ 2018-05-07 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503090909.o3dyhukzs2y7em5z@tarshish>
Hi Baruch,
On Thu, May 3, 2018 at 6:09 PM Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Jacob,
> On Thu, Mar 08, 2018 at 05:47:55PM +0800, Jacob Chen wrote:
> > +static int rkisp1_isp_sd_s_power(struct v4l2_subdev *sd, int on)
> > +{
> > + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > + int ret;
> > +
> > + v4l2_dbg(1, rkisp1_debug, &isp_dev->v4l2_dev, "s_power: %d\n",
on);
> > +
> > + if (on) {
> > + ret = pm_runtime_get_sync(isp_dev->dev);
> > + if (ret < 0)
> > + return ret;
> > +
> > + rkisp1_config_clk(isp_dev);
> > + } else {
> > + ret = pm_runtime_put(isp_dev->dev);
> I commented this line out to make more than one STREAMON work. Otherwise,
the
> second STREAMON hangs. I guess the bug is not this driver. Probably
something
> in drivers/soc/rockchip/pm_domains.c. Just noting that in case you or
someone
> on Cc would like to investigate it further.
> I tested v4.16-rc4 on the Tinkerboard.
Looks like that version doesn't include the IOMMU PM and clock handling
rework [1], which should fix a lot of runtime PM issues. FWIW, linux-next
seems to already include it.
[1] https://lkml.org/lkml/2018/3/23/44
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: AKASHI Takahiro @ 2018-05-07 5:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <648656ef-1f1e-b0ac-581c-aba1e62f4eee@arm.com>
James,
On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > We need to prevent firmware-reserved memory regions, particularly EFI
> > memory map as well as ACPI tables, from being corrupted by loading
> > kernel/initrd (or other kexec buffers). We also want to support memory
> > allocation in top-down manner in addition to default bottom-up.
> > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > for available memory ranges in usable memblock list,
> > i.e. !NOMAP & !reserved,
>
> > instead of system resource tree.
>
> Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> be safe in the EFI-memory-map/ACPI-tables case?
>
> It would be good to avoid having two ways of doing this, and I would like to
> avoid having extra arch code...
I know what you mean.
/proc/iomem or system resource is, in my opinion, not the best place to
describe memory usage of kernel but rather to describe *physical* hardware
layout. As we are still discussing about "reserved" memory, I don't want
to depend on it.
Along with memblock list, we will have more accurate control over memory
usage.
>
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > new file mode 100644
> > index 000000000000..f9ebf54ca247
> > --- /dev/null
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -0,0 +1,57 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * kexec_file for arm64
> > + *
> > + * Copyright (C) 2018 Linaro Limited
> > + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > + *
>
> > + * Most code is derived from arm64 port of kexec-tools
>
> How does kexec-tools walk memblock?
Will remove this comment from this patch.
Obviously, this comment is for the rest of the code which will be
added to succeeding patches (patch #5 and #7).
>
> > + */
> > +
> > +#define pr_fmt(fmt) "kexec_file: " fmt
> > +
> > +#include <linux/ioport.h>
> > +#include <linux/kernel.h>
> > +#include <linux/kexec.h>
> > +#include <linux/memblock.h>
> > +
> > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > + int (*func)(struct resource *, void *))
> > +{
> > + phys_addr_t start, end;
> > + struct resource res;
> > + u64 i;
> > + int ret = 0;
> > +
> > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > + return func(&crashk_res, kbuf);
> > +
> > + if (kbuf->top_down)
> > + for_each_mem_range_rev(i, &memblock.memory, &memblock.reserved,
> > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > + &start, &end, NULL) {
>
> for_each_free_mem_range_reverse() is a more readable version of this helper.
OK. I used to use my own limited list of reserved memory instead of
memblock.reserved here to exclude verbose ranges.
> > + if (!memblock_is_map_memory(start))
> > + continue;
>
> Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
Sure, I confirmed it.
>
> > + res.start = start;
> > + res.end = end;
> > + ret = func(&res, kbuf);
> > + if (ret)
> > + break;
> > + }
> > + else
> > + for_each_mem_range(i, &memblock.memory, &memblock.reserved,
> > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > + &start, &end, NULL) {
>
> for_each_free_mem_range()?
OK.
> > + if (!memblock_is_map_memory(start))
> > + continue;
> > +
> > + res.start = start;
> > + res.end = end;
> > + ret = func(&res, kbuf);
> > + if (ret)
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> >
>
> With these changes, what we have is almost:
> arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> (the difference being powerpc doesn't yet support crash-kernels here)
>
> If the argument is walking memblock gives a better answer than the stringy
> walk_system_ram_res() thing, is there any mileage in moving this code into
> kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
>
> This would save arm64/powerpc having near-identical implementations.
> 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> kexec_file_load() support is added.
Thanks. I've forgot ppc.
-Takahiro AKASHI
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory
From: AKASHI Takahiro @ 2018-05-07 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c830fe8-56d8-b43a-6265-43d31dffe61a@arm.com>
On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > On arm64, purugatory would do almosty nothing. So just invoke secondary
> > kernel directy by jumping into its entry code.
>
> (Nits: purgatory, almost, directly)
Oops, I think I ran spell before ...
>
> > While, in this case, cpu_soft_restart() must be called with dtb address
> > in the fifth argument, the behavior still stays compatible with kexec_load
> > case as long as the argument is null.
>
>
> > diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
> > index 8021b46c9743..391df91328ac 100644
> > --- a/arch/arm64/kernel/cpu-reset.S
> > +++ b/arch/arm64/kernel/cpu-reset.S
> > @@ -24,9 +24,9 @@
> > *
> > * @el2_switch: Flag to indicate a swich to EL2 is needed.
>
> (Nit: switch)
ditto
> > * @entry: Location to jump to for soft reset.
> > - * arg0: First argument passed to @entry.
> > - * arg1: Second argument passed to @entry.
> > - * arg2: Third argument passed to @entry.
> > + * arg0: First argument passed to @entry. (relocation list)
> > + * arg1: Second argument passed to @entry.(physcal kernel entry)
>
> (Nit: physical)
ditto
>
> > + * arg2: Third argument passed to @entry. (physical dtb address)
> > *
> > * Put the CPU into the same state as it would be if it had been reset, and
> > * branch to what would be the reset vector. It must be executed with the
> > diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> > index f76ea92dff91..f7dbba00be10 100644
> > --- a/arch/arm64/kernel/machine_kexec.c
> > +++ b/arch/arm64/kernel/machine_kexec.c
> > @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage)
> > * uses physical addressing to relocate the new image to its final
> > * position and transfers control to the image entry point when the
> > * relocation is complete.
> > + * In case of kexec_file_load syscall, we directly start the kernel,
> > + * skipping purgatory.
>
> We're not really skipping purgatory, purgatory doesn't exist! For regular kexec
> the image/payload we run is up to kexec-tools. For kexec_file_load its a
> kernel-image. Purgatory is a kexec-tools-ism.
You are right, but in general, purgatory is expected to exist by
generic kexec code and does exist on all architectures, kexec_load()
or kexec_file_load(), except arm64's kexec_file_load case.
So it would be nice to have some explicit notes here.
>
> > cpu_soft_restart(kimage != kexec_crash_image,
> > - reboot_code_buffer_phys, kimage->head, kimage->start, 0);
> > + reboot_code_buffer_phys, kimage->head, kimage->start,
> > +#ifdef CONFIG_KEXEC_FILE
> > + kimage->purgatory_info.purgatory_buf ?
> > + 0 : kimage->arch.dtb_mem);
> > +#else
> > + 0);
> > +#endif
>
> Where does kimage->arch.dtb_mem come from? This patch won't build until patch 8
> adds the config option, which is going to make bisecting any kexec side-effects
> tricky.
CONFIG_KEXEC_FILE is also used in patch #4, #5 and #6.
I don't know how we can fix this as the implementation is divided
into several patches.
(So bisecting doesn't work anyway.)
> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called from
> kexec_load_purgatory(), which we don't use. How does this get a value?
>
> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 0 for
> regular kexec (as we can't know where the dtb is)? (image_arg may then be a
> better name).
The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE.
So I would like to
- merge this patch with patch#8
- change the condition
#ifdef CONFIG_KEXEC_FILE
kimage->file_mode ? kimage->arch.dtb_mem : 0);
#else
0);
#endif
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v9 02/11] kexec_file: make kexec_image_post_load_cleanup_default() global
From: AKASHI Takahiro @ 2018-05-07 4:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbf66675-1671-32f9-1410-a76986becf85@arm.com>
On Tue, May 01, 2018 at 06:46:04PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > Change this function from static to global so that arm64 can implement
> > its own arch_kimage_file_post_load_cleanup() later using
> > kexec_image_post_load_cleanup_default().
>
> Do we need to call kexec_image_post_load_cleanup_default()? All it does is call
> the image-type fops->cleanup(), which you don't implement in this series.
>
> Is this just-in-case someone adds cleanup() later and is surprised only the
> arch-level helper is called?
Yes, we want not to miss two possibilities:
- some common clean-up code is added to kexec_image_post_load_cleanup_default()
- some format(i.e. Image)-specific clean-up code is added to fops->cleanup()
-Takahiro AKASHI
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v2 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters
From: Satendra Singh Thakur @ 2018-05-07 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <920ac8d1-8d2d-1332-256d-21472f69fca5@arm.com>
To avoid duplicate logic for the same
Signed-off-by: Satendra Singh Thakur <satendra.t@samsung.com>
Acked-by: Madhur Verma <madhur.verma@samsung.com>
Cc: Hemanshu Srivastava <hemanshu.s@samsung.com>
---
v2: Removed Mr Robin from reviewed-by field
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7904ffa..7fe84fd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1490,17 +1490,8 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
- struct videomode *vm = &dsi->vm;
- struct drm_display_mode *m = adjusted_mode;
-
- vm->hactive = m->hdisplay;
- vm->vactive = m->vdisplay;
- vm->vfront_porch = m->vsync_start - m->vdisplay;
- vm->vback_porch = m->vtotal - m->vsync_end;
- vm->vsync_len = m->vsync_end - m->vsync_start;
- vm->hfront_porch = m->hsync_start - m->hdisplay;
- vm->hback_porch = m->htotal - m->hsync_end;
- vm->hsync_len = m->hsync_end - m->hsync_start;
+
+ drm_display_mode_to_videomode(adjusted_mode, &dsi->vm);
}
static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
--
2.7.4
^ permalink raw reply related
* [PATCH v2] drm/kms/mode: added a new helper for calculating videomode from crtc's display mode
From: Satendra Singh Thakur @ 2018-05-07 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sh777o63.fsf@intel.com>
1.
-Added a new helper drm_display_mode_crtc_to_videomode
-This helper calculates mode parameters like
--horizontal front_porch, back_porch, sync length
--vertical front_porch, back_porch, sync length
-using crtc fields of struct drm_display_mode
-It uses following fields of crtc mode
--horizontal sync start/end, active and total length
--vertical sync start/end, active and total length
2.
-Most of the driver use user-supplied mode for calculating videomode
-However, few drivers use HW (crtc) mode for calculating videomode
-This helper will be useful for such drivers
3.
-Currently following drivers will be using this new helper
-arm hdlcd
-atmel hlcdc
-exynos 5433 decon
-exynos7 decon
-exynos fimd
4.
-This change reduces several redundant lines of code for many drivers
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Satendra Singh Thakur <satendra.t@samsung.com>
Acked-by: Madhur Verma <madhur.verma@samsung.com>
Cc: Hemanshu Srivastava <hemanshu.s@samsung.com>
---
v2: Removed Mr Jani from Reviewed-by field
drivers/gpu/drm/arm/hdlcd_crtc.c | 10 ++--------
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 ++-------
drivers/gpu/drm/drm_modes.c | 19 +++++++++++++++++++
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 22 ++++++++++------------
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 23 ++++++++++-------------
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 +++++++++-------------
include/drm/drm_modes.h | 2 ++
7 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf5cbd6..5cec264 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -127,16 +127,10 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
struct drm_display_mode *m = &crtc->state->adjusted_mode;
- struct videomode vm;
+ struct videomode vm = {};
unsigned int polarities, err;
- vm.vfront_porch = m->crtc_vsync_start - m->crtc_vdisplay;
- vm.vback_porch = m->crtc_vtotal - m->crtc_vsync_end;
- vm.vsync_len = m->crtc_vsync_end - m->crtc_vsync_start;
- vm.hfront_porch = m->crtc_hsync_start - m->crtc_hdisplay;
- vm.hback_porch = m->crtc_htotal - m->crtc_hsync_end;
- vm.hsync_len = m->crtc_hsync_end - m->crtc_hsync_start;
-
+ drm_display_mode_crtc_to_videomode(m, &vm);
polarities = HDLCD_POLARITY_DATAEN | HDLCD_POLARITY_DATA;
if (m->flags & DRM_MODE_FLAG_PHSYNC)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d732810..fb298b8 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -76,17 +76,12 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
struct drm_display_mode *adj = &c->state->adjusted_mode;
struct atmel_hlcdc_crtc_state *state;
unsigned long mode_rate;
- struct videomode vm;
+ struct videomode vm = {};
unsigned long prate;
unsigned int cfg;
int div;
- vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
- vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end;
- vm.vsync_len = adj->crtc_vsync_end - adj->crtc_vsync_start;
- vm.hfront_porch = adj->crtc_hsync_start - adj->crtc_hdisplay;
- vm.hback_porch = adj->crtc_htotal - adj->crtc_hsync_end;
- vm.hsync_len = adj->crtc_hsync_end - adj->crtc_hsync_start;
+ drm_display_mode_crtc_to_videomode(adj, &vm);
regmap_write(regmap, ATMEL_HLCDC_CFG(1),
(vm.hsync_len - 1) | ((vm.vsync_len - 1) << 16));
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e..328f771 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -654,6 +654,25 @@ void drm_display_mode_to_videomode(const struct drm_display_mode *dmode,
vm->flags |= DISPLAY_FLAGS_DOUBLECLK;
}
EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
+/**
+ * drm_display_mode_crtc_to_videomode - fill in @vm using crtc fields of @dmode
+ * @dmode: drm_display_mode structure to use as source
+ * @vm: videomode structure to use as destination
+ *
+ * Fills out @vm using the crtc display mode specified in @dmode.
+ */
+void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode,
+ struct videomode *vm)
+{
+ vm->hfront_porch = dmode->crtc_hsync_start - dmode->crtc_hdisplay;
+ vm->hsync_len = dmode->crtc_hsync_end - dmode->crtc_hsync_start;
+ vm->hback_porch = dmode->crtc_htotal - dmode->crtc_hsync_end;
+ vm->vfront_porch = dmode->crtc_vsync_start - dmode->crtc_vdisplay;
+ vm->vsync_len = dmode->crtc_vsync_end - dmode->crtc_vsync_start;
+ vm->vback_porch = dmode->crtc_vtotal - dmode->crtc_vsync_end;
+
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_crtc_to_videomode);
/**
* drm_bus_flags_from_videomode - extract information about pixelclk and
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 1c330f2..2535ebb 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -20,6 +20,7 @@
#include <linux/of_gpio.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
+#include <video/videomode.h>
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
@@ -225,26 +226,23 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
writel(val, ctx->addr + DECON_VIDTCON2);
if (!crtc->i80_mode) {
- int vbp = m->crtc_vtotal - m->crtc_vsync_end;
- int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
+ struct videomode vm = {};
+ drm_display_mode_crtc_to_videomode(m, &vm);
if (interlaced)
- vbp = vbp / 2 - 1;
- val = VIDTCON00_VBPD_F(vbp - 1) | VIDTCON00_VFPD_F(vfp - 1);
+ vm.vback_porch = (vm.vback_porch >> 1) - 1;
+ val = VIDTCON00_VBPD_F(vm.vback_porch - 1) |
+ VIDTCON00_VFPD_F(vm.vfront_porch - 1);
writel(val, ctx->addr + DECON_VIDTCON00);
- val = VIDTCON01_VSPW_F(
- m->crtc_vsync_end - m->crtc_vsync_start - 1);
+ val = VIDTCON01_VSPW_F(vm.vsync_len - 1);
writel(val, ctx->addr + DECON_VIDTCON01);
- val = VIDTCON10_HBPD_F(
- m->crtc_htotal - m->crtc_hsync_end - 1) |
- VIDTCON10_HFPD_F(
- m->crtc_hsync_start - m->crtc_hdisplay - 1);
+ val = VIDTCON10_HBPD_F(vm.hback_porch - 1) |
+ VIDTCON10_HFPD_F(vm.hfront_porch - 1);
writel(val, ctx->addr + DECON_VIDTCON10);
- val = VIDTCON11_HSPW_F(
- m->crtc_hsync_end - m->crtc_hsync_start - 1);
+ val = VIDTCON11_HSPW_F(vm.hsync_len - 1);
writel(val, ctx->addr + DECON_VIDTCON11);
}
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3931d5e..5fdd093 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -25,6 +25,7 @@
#include <video/of_display_timing.h>
#include <video/of_videomode.h>
+#include <video/videomode.h>
#include "exynos_drm_crtc.h"
#include "exynos_drm_plane.h"
@@ -168,28 +169,24 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
return;
if (!ctx->i80_if) {
- int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+ struct videomode vm = {};
+
+ drm_display_mode_crtc_to_videomode(mode, &vm);
/* setup vertical timing values. */
- vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
- vbpd = mode->crtc_vtotal - mode->crtc_vsync_end;
- vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay;
- val = VIDTCON0_VBPD(vbpd - 1) | VIDTCON0_VFPD(vfpd - 1);
+ val = VIDTCON0_VBPD(vm.vback_porch - 1) |
+ VIDTCON0_VFPD(vm.vfront_porch - 1);
writel(val, ctx->regs + VIDTCON0);
- val = VIDTCON1_VSPW(vsync_len - 1);
+ val = VIDTCON1_VSPW(vm.vsync_len - 1);
writel(val, ctx->regs + VIDTCON1);
/* setup horizontal timing values. */
- hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
- hbpd = mode->crtc_htotal - mode->crtc_hsync_end;
- hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay;
-
- /* setup horizontal timing values. */
- val = VIDTCON2_HBPD(hbpd - 1) | VIDTCON2_HFPD(hfpd - 1);
+ val = VIDTCON2_HBPD(vm.hback_porch - 1) |
+ VIDTCON2_HFPD(vm.hfront_porch - 1);
writel(val, ctx->regs + VIDTCON2);
- val = VIDTCON3_HSPW(hsync_len - 1);
+ val = VIDTCON3_HSPW(vm.hsync_len - 1);
writel(val, ctx->regs + VIDTCON3);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index d42ae2b..c70b9ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -25,6 +25,7 @@
#include <video/of_display_timing.h>
#include <video/of_videomode.h>
+#include <video/videomode.h>
#include <video/samsung_fimd.h>
#include <drm/exynos_drm.h>
@@ -463,7 +464,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
return;
}
} else {
- int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+ struct videomode vm = {};
u32 vidcon1;
/* setup polarity values */
@@ -474,24 +475,19 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
vidcon1 |= VIDCON1_INV_HSYNC;
writel(vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);
+ drm_display_mode_crtc_to_videomode(mode, &vm);
/* setup vertical timing values. */
- vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
- vbpd = mode->crtc_vtotal - mode->crtc_vsync_end;
- vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay;
- val = VIDTCON0_VBPD(vbpd - 1) |
- VIDTCON0_VFPD(vfpd - 1) |
- VIDTCON0_VSPW(vsync_len - 1);
+ val = VIDTCON0_VBPD(vm.vback_porch - 1) |
+ VIDTCON0_VFPD(vm.vfront_porch - 1) |
+ VIDTCON0_VSPW(vm.vsync_len - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);
/* setup horizontal timing values. */
- hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
- hbpd = mode->crtc_htotal - mode->crtc_hsync_end;
- hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay;
- val = VIDTCON1_HBPD(hbpd - 1) |
- VIDTCON1_HFPD(hfpd - 1) |
- VIDTCON1_HSPW(hsync_len - 1);
+ val = VIDTCON1_HBPD(vm.hback_porch - 1) |
+ VIDTCON1_HFPD(vm.hfront_porch - 1) |
+ VIDTCON1_HSPW(vm.hsync_len - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
}
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 0d310be..9ac764b 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -473,6 +473,8 @@ void drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
void drm_display_mode_to_videomode(const struct drm_display_mode *dmode,
struct videomode *vm);
+void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode,
+ struct videomode *vm);
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags);
int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode, u32 *bus_flags,
--
2.7.4
^ permalink raw reply related
* [PATCH -next] gpio: Fix return value check in owl_gpio_probe()
From: Manivannan Sadhasivam @ 2018-05-07 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525657224-88189-1-git-send-email-weiyongjun1@huawei.com>
Hi Wei,
Thanks for the patch.
On Mon, May 07, 2018 at 01:40:24AM +0000, Wei Yongjun wrote:
> In case of error, the function of_iomap() returns NULL pointer not
> ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/gpio/gpio-owl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
> index 3546362..f35e80f 100644
> --- a/drivers/gpio/gpio-owl.c
> +++ b/drivers/gpio/gpio-owl.c
> @@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> gpio->base = of_iomap(dev->of_node, 0);
> - if (IS_ERR(gpio->base))
> - return PTR_ERR(gpio->base);
> + if (!gpio->base)
> + return -ENOMEM;
>
Agree with the check here. But the return value should be -ENXIO?
Regards,
Mani
> /*
> * Get the number of gpio's for this bank. If none specified,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] arm64: export memblock_reserve()d regions via /proc/iomem
From: Akashi Takahiro @ 2018-05-07 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2708a0b0-72c7-b518-cced-a87b8a94ab79@arm.com>
James,
# I was off the last week.
On Wed, May 02, 2018 at 11:35:04AM +0100, James Morse wrote:
> Hi guys,
>
> On 25/04/18 14:22, James Morse wrote:
> > There has been some confusion around what is necessary to prevent kexec
> > overwriting important memory regions. memblock: reserve, or nomap?
> > Only memblock nomap regions are reported via /proc/iomem, kexec's
> > user-space doesn't know about memblock_reserve()d regions.
> >
> > Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory
> > as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved
> > and thus possible for kexec to overwrite with the new kernel or initrd.
> > But this was always broken, as the UEFI memory map is also reserved
> > and not marked as nomap.
> >
> > It turns out that while kexec-tools will pick up reserved sections in
> > iomem that look like:
> > | 80000000-dfffffff : System RAM
> > | 81000000-8158ffff : reserved
> >
> > The reserved section is ignored by its 'locate_hole()' code. To fix
> > this, we need to describe memblock_reserved() and nomap regions as
> > 'reserved' at the top level:
> > | 80000000-80ffffff : System RAM
> > | 81000000-8158ffff : reserved
> > | 81590000-dfffffff : System RAM
> >
> > To complicate matters, our existing named sections are described as
> > being part of 'System RAM', but they are also memblock_reserve()d.
> > We need to keep this in-case something is depending on it. To do this
> > involves walking memblock multiple times:
> >
> > First add the 'System RAM' sections that are memory and not-reserved.
> > These may be smaller than a page if part of the page is reserved. In
> > this case we want to describe the page as reserved, so we round these
> > regions down to the smallest page-size region, which may be empty.
> > (We round-up the memblock_reserved() regions to fill in the gaps).
> >
> > The boundaries for kernel_data are changed because paging_init() punches
> > holes in the _sdata -> _edata region, and this code can't add a named
> > region that crosses memblock_reserve()d<->normal-memory regions. The
> > new helpers will catch any more overlapping regions that occur.
> >
> > Lastly, we add the memblock_reserved() regions using
> > reserve_region_with_split(), which will fill in the gaps between the
> > existing named regions. (e.g. the regions occupied by the __init code).
> > This call uses the slab allocator, so has to run from an initcall.
>
> Re-reading Akashi's description of how kdump generates the ELF headers for
> /proc/vmcore, this change might break kdump, as now the memblock_reserved()
> regions may be missing from /proc/vmcore. (I'll test that).
I also tested your patch, and there seems to be something wrong.
Actually, crash utility fails to read the core:
crash-arm64: read error: kernel virtual address: ffff0000091fa998 \
type: "shadow_timekeeper xtime_sec"
crash-arm64: read error: kernel virtual address: ffff0000091fda48 \
type: "high_memory"
Meanwhile,
$ cat /proc/iomem
40000000-4007ffff : System RAM
40080000-40f5ffff : System RAM
40080000-40f5ffff : Kernel code
40f60000-4107ffff : reserved
41080000-411c9fff : System RAM
41080000-411c99ff : Kernel data
411ca000-4122ffff : reserved <=== (A)
41230000-483fffff : System RAM
48400000-583fffff : System RAM
48400000-583fffff : Crash kernel
58400000-5858ffff : System RAM
58590000-585effff : reserved
...
Adding some debug messages shows that "shadow_timekeeper" variable
belongs to the range (A), which is originally part of "Kernel data"
and should have been unmarked from "reserved" list.
> Unless there is a 'name' for a region that kexec-tools interprets as "don't
> overwrite this, but do include it in the ELF header", then we're stuck. We can't
> fix kexec without breaking kdump, we have to change user-space.
>
> Of the two, missing data from kdump vmcore would be preferable to failed-to-boot
> kexec.
Well, kexec has had this potential bug since the day One in mainline.
(we were then using "boot wrapper" instead of normal boot loaders though.)
Even if we accept your assertion above now, future new-comers may
"rediscover" a kdump bug and make a complaint time to time.
So I think that we would be better off fixing the issue right now
completely with accompanying user-space change.
Thanks,
-Takahiro AKASHI
> If we have to change user-space, I'd like to make use of the kernels
> ability to generate the ELF header itself, (e.g. kexec_file_load()).
>
>
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 30ad2f085d1f..e82c0d5c70f8 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -202,45 +202,135 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
>
> > static void __init request_standard_resources(void)
> > {
>
> [...]
>
> > + /*
> > + * We can't allocate memory while walking free memory, count the number
> > + * of struct resource's we will need. Round start/end to the smallest
> > + * page-size region as we round the reserved regions up.
> > + */
> > + for_each_free_mem_range(i, NUMA_NO_NODE, 0, &start, &end, NULL) {
>
> Nit: That 0 should be MEMBLOCK_NONE
>
>
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH] pinctrl: mvebu: use correct MPP sel value for dev pins
From: Chris Packham @ 2018-05-07 2:25 UTC (permalink / raw)
To: linux-arm-kernel
The "dev" function is selected with the value 0x4 not 0x01.
Fixes: commit d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC")
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 28b199796fae..5e828468e43d 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -437,34 +437,34 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
MPP_VAR_FUNCTION(0x4, "dev", "we0", V_98DX3236_PLUS)),
MPP_MODE(21,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad0", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad0", V_98DX3236_PLUS)),
MPP_MODE(22,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad1", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad1", V_98DX3236_PLUS)),
MPP_MODE(23,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad2", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad2", V_98DX3236_PLUS)),
MPP_MODE(24,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad3", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad3", V_98DX3236_PLUS)),
MPP_MODE(25,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad4", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad4", V_98DX3236_PLUS)),
MPP_MODE(26,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad5", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad5", V_98DX3236_PLUS)),
MPP_MODE(27,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad6", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad6", V_98DX3236_PLUS)),
MPP_MODE(28,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "ad7", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad7", V_98DX3236_PLUS)),
MPP_MODE(29,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "a0", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "a0", V_98DX3236_PLUS)),
MPP_MODE(30,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x1, "dev", "a1", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "a1", V_98DX3236_PLUS)),
MPP_MODE(31,
MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x1, "slv_smi", "mdc", V_98DX3236_PLUS),
--
2.17.0
^ permalink raw reply related
* [PATCH] ARM: dts: imx7s: Pass the 'fsl,sec-era' property
From: Fabio Estevam @ 2018-05-07 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507011710.GH3443@dragon>
On Sun, May 6, 2018 at 10:17 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> I applied it for 4.17, but still questioning whether it's reasonable to
> have the property documented as optional in bindings, if missing the
> property results in a non-functional driver.
Thanks Shawn. Yes, after my CAAM patch gets applied it will be a
proper optional property.
^ permalink raw reply
* [PATCH -next] gpio: Fix return value check in owl_gpio_probe()
From: Wei Yongjun @ 2018-05-07 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In case of error, the function of_iomap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: d3654d38809c ("gpio: Add gpio driver for Actions OWL S900 SoC")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/gpio/gpio-owl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
index 3546362..f35e80f 100644
--- a/drivers/gpio/gpio-owl.c
+++ b/drivers/gpio/gpio-owl.c
@@ -128,8 +128,8 @@ static int owl_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
gpio->base = of_iomap(dev->of_node, 0);
- if (IS_ERR(gpio->base))
- return PTR_ERR(gpio->base);
+ if (!gpio->base)
+ return -ENOMEM;
/*
* Get the number of gpio's for this bank. If none specified,
^ permalink raw reply related
* [PATCH -next] ASoC: fix return value check in mt6351_codec_driver_probe()
From: Wei Yongjun @ 2018-05-07 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In case of error, the function dev_get_regmap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
sound/soc/codecs/mt6351.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/mt6351.c b/sound/soc/codecs/mt6351.c
index e739f07..f73dcd7 100644
--- a/sound/soc/codecs/mt6351.c
+++ b/sound/soc/codecs/mt6351.c
@@ -1472,8 +1472,8 @@ static int mt6351_codec_driver_probe(struct platform_device *pdev)
priv->dev = &pdev->dev;
priv->regmap = dev_get_regmap(pdev->dev.parent, NULL);
- if (IS_ERR(priv->regmap))
- return PTR_ERR(priv->regmap);
+ if (!priv->regmap)
+ return -ENODEV;
dev_dbg(priv->dev, "%s(), dev name %s\n",
__func__, dev_name(&pdev->dev));
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx27: use lable to override osc26m clock setting
From: Shawn Guo @ 2018-05-07 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5D1Dc9hh-o81fvy8PKNx_m8gdR9yW2w5Xumse1VFHFLTQ@mail.gmail.com>
On Fri, May 04, 2018 at 12:34:29PM -0300, Fabio Estevam wrote:
> Hi Shawn,
>
> On Thu, May 3, 2018 at 9:57 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> > Instead of copying the whole node hierarchy, let's define a label for
> > clock osc26m in soc dtsi and use it for overriding clock-frequency.
> >
> > Signed-off-by: Shawn Guo <shawnguo@kernel.org>
>
> In the Subject: s/lable/label
Fixed. Thanks, Fabio.
Shawn
^ permalink raw reply
* [PATCH V7 1/7] ARM: dts: imx6sx-sabreauto: add PMIC support
From: Shawn Guo @ 2018-05-07 1:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
On Sun, May 06, 2018 at 02:28:07PM +0800, Anson Huang wrote:
> Add pfuze100 support on i.MX6SX Sabre Auto board.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx7s: Pass the 'fsl,sec-era' property
From: Shawn Guo @ 2018-05-07 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AVjFCad4PC20X5PqMuKGJQ2cOSBnqbGw+ngYCODL2vmQ@mail.gmail.com>
On Fri, May 04, 2018 at 01:31:52PM -0300, Fabio Estevam wrote:
> Hi Shawn,
>
> On Fri, May 4, 2018 at 4:19 AM, Shawn Guo <shawnguo@kernel.org> wrote:
>
> > The property is documented as optional in the bindings. Missing the
> > property shouldn't cause any fatal error, I guess.
>
> The CAAM drivers uses the era information in many places:
>
> drivers/crypto/caam/caamalg.c: if (ctrlpriv->era >= 6) {
> drivers/crypto/caam/caamalg.c: if (ctrlpriv->era < 3)
> drivers/crypto/caam/caamalg.c: if (priv->era >= 6 && uses_dkp)
> drivers/crypto/caam/caamalg_desc.c: if (era < 6) {
> drivers/crypto/caam/caamalg_desc.c: /* Class 2 operation */
> drivers/crypto/caam/caamalg_desc.c: if (era < 6) {
> drivers/crypto/caam/caamalg_desc.c: /* Class 2 operation */
> drivers/crypto/caam/caamalg_desc.c: if (era < 6) {
>
> If the era information is not provided the value of -524 (-ENOTSUPP)
> will be used, so all the above logic will not operate correctly.
>
> I have sent a patch that allows the era information to be retrieved
> via CAAM registers:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/crypto/caam/ctrl.c?h=next-20180424&id=654f2b937b389295581bcb4aa26011a63db7bc8f
>
> but this will only land in 4.18.
>
> In order to avoid i.MX7 to report the incorrect era information in
> 4.17 I suggest that this patch should be applied for 4.17-rc.
I applied it for 4.17, but still questioning whether it's reasonable to
have the property documented as optional in bindings, if missing the
property results in a non-functional driver.
Shawn
^ 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