[RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
__compiletime_assert_fallback() is supposed to stop building earlier
by using the negative-array-size method in case the compiler does not
support "error" attribute, but has never worked like that.
You can try this simple code:
#include
void foo(void)
{
BUILD_BUG_ON(1);
}
GCC (precisely, GCC 4.3 or later) immediately terminates the build,
but Clang does not report anything because Clang does not support the
"error" attribute now. It will eventually fail in the link stage,
but at least __compiletime_assert_fallback() is not working.
The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation
of `condition' in BUILD_BUG_ON"). Prior to that commit, BUILD_BUG_ON()
was checked by the negative-array-size method *and* the link-time trick.
Since that commit, the negative-array-size is not effective because
'__cond' is no longer constant. As the comment in
says, GCC (and Clang as well) only emits the error for obvious cases.
When '__cond' is a variable,
((void)sizeof(char[1 - 2 * __cond]))
... is not obvious for the compiler to know the array size is negative.
One way to fix this is to stop the variable assignment, i.e. to pass
'!(condition)' directly to __compiletime_error_fallback() at the cost
of the double evaluation of 'condition'. However, all calls of
BUILD_BUG() would be turned into errors even if they are called from
dead-code.
This commit does not change the current behavior since it just rips
off the code that has not been effective for some years.
Signed-off-by: Masahiro Yamada
---
include/linux/compiler.h | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 42506e4..c062238f4 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -295,29 +295,14 @@ unsigned long read_word_at_a_time(const void *addr)
#endif
#ifndef __compiletime_error
# define __compiletime_error(message)
-/*
- * Sparse complains of variable sized arrays due to the temporary variable in
- * __compiletime_assert. Unfortunately we can't just expand it out to make
- * sparse see a constant array size without breaking compiletime_assert on old
- * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
- */
-# ifndef __CHECKER__
-# define __compiletime_error_fallback(condition) \
- do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
-# endif
-#endif
-#ifndef __compiletime_error_fallback
-# define __compiletime_error_fallback(condition) do { } while (0)
#endif
#ifdef __OPTIMIZE__
# define __compiletime_assert(condition, msg, prefix, suffix) \
do {\
- bool __cond = !(condition); \
extern void prefix ## suffix(void) __compiletime_error(msg); \
- if (__cond) \
+ if (!(condition)) \
prefix ## suffix(); \
- __compiletime_error_fallback(__cond); \
} while (0)
#else
# define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0)
--
2.7.4
[RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
__compiletime_assert_fallback() is supposed to stop building earlier
by using the negative-array-size method in case the compiler does not
support "error" attribute, but has never worked like that.
You can try this simple code:
#include
void foo(void)
{
BUILD_BUG_ON(1);
}
GCC (precisely, GCC 4.3 or later) immediately terminates the build,
but Clang does not report anything because Clang does not support the
"error" attribute now. It will eventually fail in the link stage,
but at least __compiletime_assert_fallback() is not working.
The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation
of `condition' in BUILD_BUG_ON"). Prior to that commit, BUILD_BUG_ON()
was checked by the negative-array-size method *and* the link-time trick.
Since that commit, the negative-array-size is not effective because
'__cond' is no longer constant. As the comment in
says, GCC (and Clang as well) only emits the error for obvious cases.
When '__cond' is a variable,
((void)sizeof(char[1 - 2 * __cond]))
... is not obvious for the compiler to know the array size is negative.
One way to fix this is to stop the variable assignment, i.e. to pass
'!(condition)' directly to __compiletime_error_fallback() at the cost
of the double evaluation of 'condition'. However, all calls of
BUILD_BUG() would be turned into errors even if they are called from
dead-code.
This commit does not change the current behavior since it just rips
off the code that has not been effective for some years.
Signed-off-by: Masahiro Yamada
---
include/linux/compiler.h | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 42506e4..c062238f4 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -295,29 +295,14 @@ unsigned long read_word_at_a_time(const void *addr)
#endif
#ifndef __compiletime_error
# define __compiletime_error(message)
-/*
- * Sparse complains of variable sized arrays due to the temporary variable in
- * __compiletime_assert. Unfortunately we can't just expand it out to make
- * sparse see a constant array size without breaking compiletime_assert on old
- * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
- */
-# ifndef __CHECKER__
-# define __compiletime_error_fallback(condition) \
- do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
-# endif
-#endif
-#ifndef __compiletime_error_fallback
-# define __compiletime_error_fallback(condition) do { } while (0)
#endif
#ifdef __OPTIMIZE__
# define __compiletime_assert(condition, msg, prefix, suffix) \
do {\
- bool __cond = !(condition); \
extern void prefix ## suffix(void) __compiletime_error(msg); \
- if (__cond) \
+ if (!(condition)) \
prefix ## suffix(); \
- __compiletime_error_fallback(__cond); \
} while (0)
#else
# define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0)
--
2.7.4
Re: problem in building 4.8.0: references to non-existent util CLANG
Randy Dunlap wrote: On 08/18/2018 05:48 PM, Linda Walsh wrote: Is CLANG required for building now? Looks like this patch should fix it: https://marc.info/?l=linux-kbuild=153447099313149=2 --- Thanks much!
Re: problem in building 4.8.0: references to non-existent util CLANG
Randy Dunlap wrote: On 08/18/2018 05:48 PM, Linda Walsh wrote: Is CLANG required for building now? Looks like this patch should fix it: https://marc.info/?l=linux-kbuild=153447099313149=2 --- Thanks much!
RE: [char-misc-next 00/12] mei: Add DMA ring
> > > On Tue, Jul 31, 2018 at 09:35:32AM +0300, Tomas Winkler wrote: > > > This series adds an alternative method for transferring data between > > > the mei driver and the device via a DMA ring. The DMA ring allows > > > transferring data in bigger chunks, up to 128K, than the HW ring 512B. > > > The actual sizes depend on particular MEI generations. > > > The HW ring is faster for packets that fits into the HW ring while a > > > packet that would require fragmentation is faster to send via the > > > DMA ring. > > > > I've applied the first 5 patches now. Please fix up and resend the rest. > > Greg, as I wrote, we wish to stay with the dual license in that file, please > can > you apply the patches as they are? Hi Greg, can you please respond, we have half of the series merged only, it should be completed. Thanks Tomas
RE: [char-misc-next 00/12] mei: Add DMA ring
> > > On Tue, Jul 31, 2018 at 09:35:32AM +0300, Tomas Winkler wrote: > > > This series adds an alternative method for transferring data between > > > the mei driver and the device via a DMA ring. The DMA ring allows > > > transferring data in bigger chunks, up to 128K, than the HW ring 512B. > > > The actual sizes depend on particular MEI generations. > > > The HW ring is faster for packets that fits into the HW ring while a > > > packet that would require fragmentation is faster to send via the > > > DMA ring. > > > > I've applied the first 5 patches now. Please fix up and resend the rest. > > Greg, as I wrote, we wish to stay with the dual license in that file, please > can > you apply the patches as they are? Hi Greg, can you please respond, we have half of the series merged only, it should be completed. Thanks Tomas
Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"
On Sat, Aug 18, 2018 at 01:24:51PM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote: > > On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote: > > > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. > > > > Just to be clear, if I understand correctly, this is a pure revert of > > 44bda4b7d26e and as such it reintroduces the problem solved by that > > commit. > > > > If your solution turns out to be better, that's great, but it would be > > nice to avoid the bisection hole of reintroducing the problem, then > > fixing it again later. > > There is no way to do that other than merging the revert and the fix > into one. That said, the race is sufficiently hard to hit that I > wouldn't worry too much about it. OK, then at least mention that in the changelog. > > > The new pci state mutex provides a simpler way of addressing > > > this race and avoids the relative includes added to the powerpc > > > code. >
Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"
On Sat, Aug 18, 2018 at 01:24:51PM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote: > > On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote: > > > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. > > > > Just to be clear, if I understand correctly, this is a pure revert of > > 44bda4b7d26e and as such it reintroduces the problem solved by that > > commit. > > > > If your solution turns out to be better, that's great, but it would be > > nice to avoid the bisection hole of reintroducing the problem, then > > fixing it again later. > > There is no way to do that other than merging the revert and the fix > into one. That said, the race is sufficiently hard to hit that I > wouldn't worry too much about it. OK, then at least mention that in the changelog. > > > The new pci state mutex provides a simpler way of addressing > > > this race and avoids the relative includes added to the powerpc > > > code. >
Re: problem in building 4.8.0: references to non-existent util CLANG
On 08/18/2018 05:48 PM, Linda Walsh wrote: > Is CLANG required for building now? > > when I did a "make xconfig" (or any make, for that matter), I get: > >> make xconfig > scripts/kconfig/qconf Kconfig > invocation line: ./scripts/clang-version.sh gcc ## debug line I added > ./scripts/clang-version.sh: line 15: ./COPYING: Permission denied > ./scripts/clang-version.sh: line 23: printf: __clang_major__: invalid number > ./scripts/clang-version.sh: line 23: printf: __clang_minor__: invalid number > ./scripts/clang-version.sh: line 23: printf: __clang_patchlevel__: invalid > number > init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid > .config:50:warning: symbol value '0' invalid for CLANG_VERSION > > The reference to COPYING comes from me running make in the > top dir, where there is a text file named COPYING, however it is > not executable. > > I put in an echo to see what command line the script was being passed, > "gcc"? > > I'm guessing but I don't think the clang script should be getting > called at all. I installed the sources by patching 4.17.0 (done via a > script). > > Are there instructions somewhere for what command(s) to run for patching? > It seems to have changed from using the standard patch program to using > a git version that isn't compatible w/the gnu version. I adapted the > script to the git version and that's seemed to work since I did > the change. But with 4.18.0, I am uncertain if it is working correctly. > > If the above was the only problem, I'd be less concerned, but > scripts run after the main build to build external modules failed. > It seems unlikely the two problems are related, but I wanted to fix > this first before going on to the compile-fails. > > Please Cc me, as I'm not currently on the list. > > Thanks, > Linda W. > Looks like this patch should fix it: https://marc.info/?l=linux-kbuild=153447099313149=2 -- ~Randy
Re: problem in building 4.8.0: references to non-existent util CLANG
On 08/18/2018 05:48 PM, Linda Walsh wrote: > Is CLANG required for building now? > > when I did a "make xconfig" (or any make, for that matter), I get: > >> make xconfig > scripts/kconfig/qconf Kconfig > invocation line: ./scripts/clang-version.sh gcc ## debug line I added > ./scripts/clang-version.sh: line 15: ./COPYING: Permission denied > ./scripts/clang-version.sh: line 23: printf: __clang_major__: invalid number > ./scripts/clang-version.sh: line 23: printf: __clang_minor__: invalid number > ./scripts/clang-version.sh: line 23: printf: __clang_patchlevel__: invalid > number > init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid > .config:50:warning: symbol value '0' invalid for CLANG_VERSION > > The reference to COPYING comes from me running make in the > top dir, where there is a text file named COPYING, however it is > not executable. > > I put in an echo to see what command line the script was being passed, > "gcc"? > > I'm guessing but I don't think the clang script should be getting > called at all. I installed the sources by patching 4.17.0 (done via a > script). > > Are there instructions somewhere for what command(s) to run for patching? > It seems to have changed from using the standard patch program to using > a git version that isn't compatible w/the gnu version. I adapted the > script to the git version and that's seemed to work since I did > the change. But with 4.18.0, I am uncertain if it is working correctly. > > If the above was the only problem, I'd be less concerned, but > scripts run after the main build to build external modules failed. > It seems unlikely the two problems are related, but I wanted to fix > this first before going on to the compile-fails. > > Please Cc me, as I'm not currently on the list. > > Thanks, > Linda W. > Looks like this patch should fix it: https://marc.info/?l=linux-kbuild=153447099313149=2 -- ~Randy
problem in building 4.8.0: references to non-existent util CLANG
Is CLANG required for building now? when I did a "make xconfig" (or any make, for that matter), I get: make xconfig scripts/kconfig/qconf Kconfig invocation line: ./scripts/clang-version.sh gcc ## debug line I added ./scripts/clang-version.sh: line 15: ./COPYING: Permission denied ./scripts/clang-version.sh: line 23: printf: __clang_major__: invalid number ./scripts/clang-version.sh: line 23: printf: __clang_minor__: invalid number ./scripts/clang-version.sh: line 23: printf: __clang_patchlevel__: invalid number init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid .config:50:warning: symbol value '0' invalid for CLANG_VERSION The reference to COPYING comes from me running make in the top dir, where there is a text file named COPYING, however it is not executable. I put in an echo to see what command line the script was being passed, "gcc"? I'm guessing but I don't think the clang script should be getting called at all. I installed the sources by patching 4.17.0 (done via a script). Are there instructions somewhere for what command(s) to run for patching? It seems to have changed from using the standard patch program to using a git version that isn't compatible w/the gnu version. I adapted the script to the git version and that's seemed to work since I did the change. But with 4.18.0, I am uncertain if it is working correctly. If the above was the only problem, I'd be less concerned, but scripts run after the main build to build external modules failed. It seems unlikely the two problems are related, but I wanted to fix this first before going on to the compile-fails. Please Cc me, as I'm not currently on the list. Thanks, Linda W.
problem in building 4.8.0: references to non-existent util CLANG
Is CLANG required for building now? when I did a "make xconfig" (or any make, for that matter), I get: make xconfig scripts/kconfig/qconf Kconfig invocation line: ./scripts/clang-version.sh gcc ## debug line I added ./scripts/clang-version.sh: line 15: ./COPYING: Permission denied ./scripts/clang-version.sh: line 23: printf: __clang_major__: invalid number ./scripts/clang-version.sh: line 23: printf: __clang_minor__: invalid number ./scripts/clang-version.sh: line 23: printf: __clang_patchlevel__: invalid number init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid .config:50:warning: symbol value '0' invalid for CLANG_VERSION The reference to COPYING comes from me running make in the top dir, where there is a text file named COPYING, however it is not executable. I put in an echo to see what command line the script was being passed, "gcc"? I'm guessing but I don't think the clang script should be getting called at all. I installed the sources by patching 4.17.0 (done via a script). Are there instructions somewhere for what command(s) to run for patching? It seems to have changed from using the standard patch program to using a git version that isn't compatible w/the gnu version. I adapted the script to the git version and that's seemed to work since I did the change. But with 4.18.0, I am uncertain if it is working correctly. If the above was the only problem, I'd be less concerned, but scripts run after the main build to build external modules failed. It seems unlikely the two problems are related, but I wanted to fix this first before going on to the compile-fails. Please Cc me, as I'm not currently on the list. Thanks, Linda W.
Re: linux-next: Signed-off-by missing for commit in the h8300 tree
Hi Yoshinori,
On Sun, 19 Aug 2018 01:35:47 +0900 Yoshinori Sato
wrote:
>
> > Commit
> >
> > 85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
> >
> > is missing a Signed-off-by from its committer.
>
> OK. Fixed it.
This last one is still missing your Signed-off-by ...
(it is commit 09c7c64733a2, now)
--
Cheers,
Stephen Rothwell
pgpmhRUihn_IO.pgp
Description: OpenPGP digital signature
Re: linux-next: Signed-off-by missing for commit in the h8300 tree
Hi Yoshinori,
On Sun, 19 Aug 2018 01:35:47 +0900 Yoshinori Sato
wrote:
>
> > Commit
> >
> > 85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
> >
> > is missing a Signed-off-by from its committer.
>
> OK. Fixed it.
This last one is still missing your Signed-off-by ...
(it is commit 09c7c64733a2, now)
--
Cheers,
Stephen Rothwell
pgpmhRUihn_IO.pgp
Description: OpenPGP digital signature
Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped
On Sat, Aug 18, 2018 at 11:57:00PM +0200, Rafael J. Wysocki wrote:
[...]
> > > > Otherwise we can have something like this:
> > > >
> > > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > > index da9455a..408c985 100644
> > > > --- a/kernel/time/tick-sched.c
> > > > +++ b/kernel/time/tick-sched.c
> > > > @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched
> > > > *ts, int cpu)
> > > > static void tick_nohz_retain_tick(struct tick_sched *ts)
> > > > {
> > > > ts->timer_expires_base = 0;
> > > > +
> > > > + if (ts->tick_stopped)
> > > > + tick_nohz_restart(ts, ktime_get());
> > > > }
> > > >
> > > > #ifdef CONFIG_NO_HZ_FULL
> > > >
> > >
> > > We could do that, but my concern with that approach is that we may end up
> > > stopping and starting the tick back and forth without exiting the loop
> > > in do_idle() just because somebody uses a periodic timer behind our
> > > back and the governor gets confused.
> > >
> > > Besides, that would be a change in behavior, while the $subject patch
> > > simply fixes a mistake in the original design.
> >
> > Ok, let's take the safe approach for now as this is a fix and it should
> > even be
> > routed to stable.
>
> Right. I'll queue up this patch, then.
>
> > But then in the longer term, perhaps cpuidle_select() should think that
> > through.
>
> So I have given more consideration to this and my conclusion is that
> restarting the tick between cpuidle_select() and call_cpuidle() is a
> bad idea.
>
> First off, if need_resched() is "false", the primary reason for
> running the tick on the given CPU is not there, so it only might be
> useful as a "backup" timer to wake up the CPU from an inadequate idle
> state.
>
> Now, in general, there are two reasons for the idle governor (whatever
> it is) to select an idle state with a target residency below the tick
> period length. The first reason is when the governor knows that the
> closest timer event is going to occur in this time frame, but in that
> case (as stated above), it is not necessary to worry about the tick,
> because the other timer will trigger soon enough anyway. The second
> reason is when the governor predicts a wakeup which is not by a timer
> in this time frame and it is quite arguable what the governor should
> do then. IMO it at least is not unreasonable to throw the prediction
> away and still go for the closest timer event in that case (which is
> the current approach).
>
> There's more, though. Restarting the tick between cpuidle_select()
> and call_cpuidle() might introduce quite a bit of latency into that
> point and that would mess up with the idle state selection (e.g.
> selecting a very shallow idle state might not make a lot of sense if
> that latency was high enough, because the expected wakeup might very
> well take place when the tick was being restarted), so it should
> rather be avoided IMO.
I expect the idle governor doesn't introduce many restarting tick
operations, the reason is if there have a close timer event than idle
governor can trust it to wake up CPU so in this case the idle governor
will not restart tick; if the the timer event is long delta and the
shallow state selection is caused by factors (e.g. typical pattern),
then we need restart tick to avoid powernightmares, for this case we
can restart tick only once at the beginning for the typical pattern
interrupt events; after the typical pattern interrupt doesn't continue
then we can rely on the tick to rescue the idle state to deep one.
Thanks,
Leo Yan
Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped
On Sat, Aug 18, 2018 at 11:57:00PM +0200, Rafael J. Wysocki wrote:
[...]
> > > > Otherwise we can have something like this:
> > > >
> > > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > > index da9455a..408c985 100644
> > > > --- a/kernel/time/tick-sched.c
> > > > +++ b/kernel/time/tick-sched.c
> > > > @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched
> > > > *ts, int cpu)
> > > > static void tick_nohz_retain_tick(struct tick_sched *ts)
> > > > {
> > > > ts->timer_expires_base = 0;
> > > > +
> > > > + if (ts->tick_stopped)
> > > > + tick_nohz_restart(ts, ktime_get());
> > > > }
> > > >
> > > > #ifdef CONFIG_NO_HZ_FULL
> > > >
> > >
> > > We could do that, but my concern with that approach is that we may end up
> > > stopping and starting the tick back and forth without exiting the loop
> > > in do_idle() just because somebody uses a periodic timer behind our
> > > back and the governor gets confused.
> > >
> > > Besides, that would be a change in behavior, while the $subject patch
> > > simply fixes a mistake in the original design.
> >
> > Ok, let's take the safe approach for now as this is a fix and it should
> > even be
> > routed to stable.
>
> Right. I'll queue up this patch, then.
>
> > But then in the longer term, perhaps cpuidle_select() should think that
> > through.
>
> So I have given more consideration to this and my conclusion is that
> restarting the tick between cpuidle_select() and call_cpuidle() is a
> bad idea.
>
> First off, if need_resched() is "false", the primary reason for
> running the tick on the given CPU is not there, so it only might be
> useful as a "backup" timer to wake up the CPU from an inadequate idle
> state.
>
> Now, in general, there are two reasons for the idle governor (whatever
> it is) to select an idle state with a target residency below the tick
> period length. The first reason is when the governor knows that the
> closest timer event is going to occur in this time frame, but in that
> case (as stated above), it is not necessary to worry about the tick,
> because the other timer will trigger soon enough anyway. The second
> reason is when the governor predicts a wakeup which is not by a timer
> in this time frame and it is quite arguable what the governor should
> do then. IMO it at least is not unreasonable to throw the prediction
> away and still go for the closest timer event in that case (which is
> the current approach).
>
> There's more, though. Restarting the tick between cpuidle_select()
> and call_cpuidle() might introduce quite a bit of latency into that
> point and that would mess up with the idle state selection (e.g.
> selecting a very shallow idle state might not make a lot of sense if
> that latency was high enough, because the expected wakeup might very
> well take place when the tick was being restarted), so it should
> rather be avoided IMO.
I expect the idle governor doesn't introduce many restarting tick
operations, the reason is if there have a close timer event than idle
governor can trust it to wake up CPU so in this case the idle governor
will not restart tick; if the the timer event is long delta and the
shallow state selection is caused by factors (e.g. typical pattern),
then we need restart tick to avoid powernightmares, for this case we
can restart tick only once at the beginning for the typical pattern
interrupt events; after the typical pattern interrupt doesn't continue
then we can rely on the tick to rescue the idle state to deep one.
Thanks,
Leo Yan
Re: linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
On Tue, 26 Jun 2018 12:18:53 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> arch/x86/kernel/cpu/mcheck/mce.c
>
> between commit:
>
> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>
> from the tip tree and commit:
>
> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>
> from the nvdimm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kernel/cpu/mcheck/mce.c
> index 9a16f15f79eb,a0fbf0a8b7e6..
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@@ -1076,129 -1070,6 +1072,100 @@@ static int do_memory_failure(struct mc
> return ret;
> }
>
> - #ifndef mce_unmap_kpfn
> - static void mce_unmap_kpfn(unsigned long pfn)
> - {
> - unsigned long decoy_addr;
> -
> - /*
> - * Unmap this page from the kernel 1:1 mappings to make sure
> - * we don't log more errors because of speculative access to
> - * the page.
> - * We would like to just call:
> - * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1);
> - * but doing that would radically increase the odds of a
> - * speculative access to the poison page because we'd have
> - * the virtual address of the kernel 1:1 mapping sitting
> - * around in registers.
> - * Instead we get tricky. We create a non-canonical address
> - * that looks just like the one we want, but has bit 63 flipped.
> - * This relies on set_memory_np() not checking whether we passed
> - * a legal address.
> - */
> -
> - decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
> -
> - if (set_memory_np(decoy_addr, 1))
> - pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
> - }
> - #endif
> -
> -
> +/*
> + * Cases where we avoid rendezvous handler timeout:
> + * 1) If this CPU is offline.
> + *
> + * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
> + * skip those CPUs which remain looping in the 1st kernel - see
> + * crash_nmi_callback().
> + *
> + * Note: there still is a small window between kexec-ing and the new,
> + * kdump kernel establishing a new #MC handler where a broadcasted MCE
> + * might not get handled properly.
> + */
> +static bool __mc_check_crashing_cpu(int cpu)
> +{
> +if (cpu_is_offline(cpu) ||
> +(crashing_cpu != -1 && crashing_cpu != cpu)) {
> +u64 mcgstatus;
> +
> +mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
> +if (mcgstatus & MCG_STATUS_RIPV) {
> +mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
> +return true;
> +}
> +}
> +return false;
> +}
> +
> +static void __mc_scan_banks(struct mce *m, struct mce *final,
> +unsigned long *toclear, unsigned long *valid_banks,
> +int no_way_out, int *worst)
> +{
> +struct mca_config *cfg = _cfg;
> +int severity, i;
> +
> +for (i = 0; i < cfg->banks; i++) {
> +__clear_bit(i, toclear);
> +if (!test_bit(i, valid_banks))
> +continue;
> +
> +if (!mce_banks[i].ctl)
> +continue;
> +
> +m->misc = 0;
> +m->addr = 0;
> +m->bank = i;
> +
> +m->status = mce_rdmsrl(msr_ops.status(i));
> +if (!(m->status & MCI_STATUS_VAL))
> +continue;
> +
> +/*
> + * Corrected or non-signaled errors are handled by
> + * machine_check_poll(). Leave them alone, unless this panics.
> + */
> +if (!(m->status & (cfg->ser ? MCI_STATUS_S : MCI_STATUS_UC)) &&
> +!no_way_out)
> +continue;
> +
> +/* Set taint even when machine check was not enabled. */
> +add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
> +
> +severity = mce_severity(m, cfg->tolerant, NULL, true);
> +
> +/*
> + * When machine check was for corrected/deferred handler don't
> + * touch, unless we're panicking.
> + */
> +if ((severity == MCE_KEEP_SEVERITY ||
> + severity == MCE_UCNA_SEVERITY) && !no_way_out)
> +continue;
> +
> +__set_bit(i, toclear);
> +
> +/* Machine check event was not enabled. Clear, but ignore. */
> +if (severity == MCE_NO_SEVERITY)
> +
Re: linux-next: manual merge of the nvdimm tree with the tip tree
Hi all,
On Tue, 26 Jun 2018 12:18:53 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> arch/x86/kernel/cpu/mcheck/mce.c
>
> between commit:
>
> d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
>
> from the tip tree and commit:
>
> f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
>
> from the nvdimm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kernel/cpu/mcheck/mce.c
> index 9a16f15f79eb,a0fbf0a8b7e6..
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@@ -1076,129 -1070,6 +1072,100 @@@ static int do_memory_failure(struct mc
> return ret;
> }
>
> - #ifndef mce_unmap_kpfn
> - static void mce_unmap_kpfn(unsigned long pfn)
> - {
> - unsigned long decoy_addr;
> -
> - /*
> - * Unmap this page from the kernel 1:1 mappings to make sure
> - * we don't log more errors because of speculative access to
> - * the page.
> - * We would like to just call:
> - * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1);
> - * but doing that would radically increase the odds of a
> - * speculative access to the poison page because we'd have
> - * the virtual address of the kernel 1:1 mapping sitting
> - * around in registers.
> - * Instead we get tricky. We create a non-canonical address
> - * that looks just like the one we want, but has bit 63 flipped.
> - * This relies on set_memory_np() not checking whether we passed
> - * a legal address.
> - */
> -
> - decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
> -
> - if (set_memory_np(decoy_addr, 1))
> - pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
> - }
> - #endif
> -
> -
> +/*
> + * Cases where we avoid rendezvous handler timeout:
> + * 1) If this CPU is offline.
> + *
> + * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
> + * skip those CPUs which remain looping in the 1st kernel - see
> + * crash_nmi_callback().
> + *
> + * Note: there still is a small window between kexec-ing and the new,
> + * kdump kernel establishing a new #MC handler where a broadcasted MCE
> + * might not get handled properly.
> + */
> +static bool __mc_check_crashing_cpu(int cpu)
> +{
> +if (cpu_is_offline(cpu) ||
> +(crashing_cpu != -1 && crashing_cpu != cpu)) {
> +u64 mcgstatus;
> +
> +mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
> +if (mcgstatus & MCG_STATUS_RIPV) {
> +mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
> +return true;
> +}
> +}
> +return false;
> +}
> +
> +static void __mc_scan_banks(struct mce *m, struct mce *final,
> +unsigned long *toclear, unsigned long *valid_banks,
> +int no_way_out, int *worst)
> +{
> +struct mca_config *cfg = _cfg;
> +int severity, i;
> +
> +for (i = 0; i < cfg->banks; i++) {
> +__clear_bit(i, toclear);
> +if (!test_bit(i, valid_banks))
> +continue;
> +
> +if (!mce_banks[i].ctl)
> +continue;
> +
> +m->misc = 0;
> +m->addr = 0;
> +m->bank = i;
> +
> +m->status = mce_rdmsrl(msr_ops.status(i));
> +if (!(m->status & MCI_STATUS_VAL))
> +continue;
> +
> +/*
> + * Corrected or non-signaled errors are handled by
> + * machine_check_poll(). Leave them alone, unless this panics.
> + */
> +if (!(m->status & (cfg->ser ? MCI_STATUS_S : MCI_STATUS_UC)) &&
> +!no_way_out)
> +continue;
> +
> +/* Set taint even when machine check was not enabled. */
> +add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
> +
> +severity = mce_severity(m, cfg->tolerant, NULL, true);
> +
> +/*
> + * When machine check was for corrected/deferred handler don't
> + * touch, unless we're panicking.
> + */
> +if ((severity == MCE_KEEP_SEVERITY ||
> + severity == MCE_UCNA_SEVERITY) && !no_way_out)
> +continue;
> +
> +__set_bit(i, toclear);
> +
> +/* Machine check event was not enabled. Clear, but ignore. */
> +if (severity == MCE_NO_SEVERITY)
> +
Re: linux-next: manual merge of the driver-core tree with the iommu tree
Hi all,
On Wed, 11 Jul 2018 13:14:45 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the driver-core tree got a conflict in:
>
> drivers/iommu/ipmmu-vmsa.c
>
> between commits:
>
> 0b8ac1409641 ("iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code")
> 3701c123e1c1 ("iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code")
> 98dbffd39a65 ("iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code")
>
> from the iommu tree and commit:
>
> ac6bbf0cdf42 ("iommu: Remove IOMMU_OF_DECLARE")
>
> from the driver-core tree.
>
> I fixed it up (I removed the new IOMMU_OF_DECLARE() lines) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
This is now a conflict between Linus' tree and the iommu tree.
--
Cheers,
Stephen Rothwell
pgpE5XPJfcurR.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the driver-core tree with the iommu tree
Hi all,
On Wed, 11 Jul 2018 13:14:45 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the driver-core tree got a conflict in:
>
> drivers/iommu/ipmmu-vmsa.c
>
> between commits:
>
> 0b8ac1409641 ("iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code")
> 3701c123e1c1 ("iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code")
> 98dbffd39a65 ("iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code")
>
> from the iommu tree and commit:
>
> ac6bbf0cdf42 ("iommu: Remove IOMMU_OF_DECLARE")
>
> from the driver-core tree.
>
> I fixed it up (I removed the new IOMMU_OF_DECLARE() lines) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
This is now a conflict between Linus' tree and the iommu tree.
--
Cheers,
Stephen Rothwell
pgpE5XPJfcurR.pgp
Description: OpenPGP digital signature
donation
-- donation of $3 to you, contact hams@hotmail.com to verefly
donation
-- donation of $3 to you, contact hams@hotmail.com to verefly
[PATCH] export.h: remove VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR()
With the special case handling for Blackfin and Metag was removed by
commit 94e58e0ac312 ("export.h: remove code for prefixing symbols with
underscore"), VMLINUX_SYMBOL() is no-no.
Replace the remaining usages, then remove the definition of
VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
no longer needs to include .
Signed-off-by: Masahiro Yamada
---
certs/system_certificates.S | 16
include/asm-generic/vmlinux.lds.h | 2 --
include/linux/export.h| 7 ---
usr/initramfs_data.S | 4 ++--
4 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/certs/system_certificates.S b/certs/system_certificates.S
index 3918ff7..8f29058 100644
--- a/certs/system_certificates.S
+++ b/certs/system_certificates.S
@@ -5,8 +5,8 @@
__INITRODATA
.align 8
- .globl VMLINUX_SYMBOL(system_certificate_list)
-VMLINUX_SYMBOL(system_certificate_list):
+ .globl system_certificate_list
+system_certificate_list:
__cert_list_start:
#ifdef CONFIG_MODULE_SIG
.incbin "certs/signing_key.x509"
@@ -15,21 +15,21 @@ __cert_list_start:
__cert_list_end:
#ifdef CONFIG_SYSTEM_EXTRA_CERTIFICATE
- .globl VMLINUX_SYMBOL(system_extra_cert)
+ .globl system_extra_cert
.size system_extra_cert, CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE
-VMLINUX_SYMBOL(system_extra_cert):
+system_extra_cert:
.fill CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE, 1, 0
.align 4
- .globl VMLINUX_SYMBOL(system_extra_cert_used)
-VMLINUX_SYMBOL(system_extra_cert_used):
+ .globl system_extra_cert_used
+system_extra_cert_used:
.int 0
#endif /* CONFIG_SYSTEM_EXTRA_CERTIFICATE */
.align 8
- .globl VMLINUX_SYMBOL(system_certificate_list_size)
-VMLINUX_SYMBOL(system_certificate_list_size):
+ .globl system_certificate_list_size
+system_certificate_list_size:
#ifdef CONFIG_64BIT
.quad __cert_list_end - __cert_list_start
#else
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index f173b5f..7b75ff6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -54,8 +54,6 @@
#define LOAD_OFFSET 0
#endif
-#include
-
/* Align . to a 8 byte boundary equals to maximum function alignment. */
#define ALIGN_FUNCTION() . = ALIGN(8)
diff --git a/include/linux/export.h b/include/linux/export.h
index b768d6d..c363bde 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -10,13 +10,6 @@
* hackers place grumpy comments in header files.
*/
-#define __VMLINUX_SYMBOL(x) x
-#define __VMLINUX_SYMBOL_STR(x) #x
-
-/* Indirect, so macros are expanded before pasting. */
-#define VMLINUX_SYMBOL(x) __VMLINUX_SYMBOL(x)
-#define VMLINUX_SYMBOL_STR(x) __VMLINUX_SYMBOL_STR(x)
-
#ifndef __ASSEMBLY__
struct kernel_symbol
{
diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
index b28da79..d07648f 100644
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -30,8 +30,8 @@ __irf_start:
.incbin __stringify(INITRAMFS_IMAGE)
__irf_end:
.section .init.ramfs.info,"a"
-.globl VMLINUX_SYMBOL(__initramfs_size)
-VMLINUX_SYMBOL(__initramfs_size):
+.globl __initramfs_size
+__initramfs_size:
#ifdef CONFIG_64BIT
.quad __irf_end - __irf_start
#else
--
2.7.4
[PATCH] export.h: remove VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR()
With the special case handling for Blackfin and Metag was removed by
commit 94e58e0ac312 ("export.h: remove code for prefixing symbols with
underscore"), VMLINUX_SYMBOL() is no-no.
Replace the remaining usages, then remove the definition of
VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
no longer needs to include .
Signed-off-by: Masahiro Yamada
---
certs/system_certificates.S | 16
include/asm-generic/vmlinux.lds.h | 2 --
include/linux/export.h| 7 ---
usr/initramfs_data.S | 4 ++--
4 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/certs/system_certificates.S b/certs/system_certificates.S
index 3918ff7..8f29058 100644
--- a/certs/system_certificates.S
+++ b/certs/system_certificates.S
@@ -5,8 +5,8 @@
__INITRODATA
.align 8
- .globl VMLINUX_SYMBOL(system_certificate_list)
-VMLINUX_SYMBOL(system_certificate_list):
+ .globl system_certificate_list
+system_certificate_list:
__cert_list_start:
#ifdef CONFIG_MODULE_SIG
.incbin "certs/signing_key.x509"
@@ -15,21 +15,21 @@ __cert_list_start:
__cert_list_end:
#ifdef CONFIG_SYSTEM_EXTRA_CERTIFICATE
- .globl VMLINUX_SYMBOL(system_extra_cert)
+ .globl system_extra_cert
.size system_extra_cert, CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE
-VMLINUX_SYMBOL(system_extra_cert):
+system_extra_cert:
.fill CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE, 1, 0
.align 4
- .globl VMLINUX_SYMBOL(system_extra_cert_used)
-VMLINUX_SYMBOL(system_extra_cert_used):
+ .globl system_extra_cert_used
+system_extra_cert_used:
.int 0
#endif /* CONFIG_SYSTEM_EXTRA_CERTIFICATE */
.align 8
- .globl VMLINUX_SYMBOL(system_certificate_list_size)
-VMLINUX_SYMBOL(system_certificate_list_size):
+ .globl system_certificate_list_size
+system_certificate_list_size:
#ifdef CONFIG_64BIT
.quad __cert_list_end - __cert_list_start
#else
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index f173b5f..7b75ff6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -54,8 +54,6 @@
#define LOAD_OFFSET 0
#endif
-#include
-
/* Align . to a 8 byte boundary equals to maximum function alignment. */
#define ALIGN_FUNCTION() . = ALIGN(8)
diff --git a/include/linux/export.h b/include/linux/export.h
index b768d6d..c363bde 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -10,13 +10,6 @@
* hackers place grumpy comments in header files.
*/
-#define __VMLINUX_SYMBOL(x) x
-#define __VMLINUX_SYMBOL_STR(x) #x
-
-/* Indirect, so macros are expanded before pasting. */
-#define VMLINUX_SYMBOL(x) __VMLINUX_SYMBOL(x)
-#define VMLINUX_SYMBOL_STR(x) __VMLINUX_SYMBOL_STR(x)
-
#ifndef __ASSEMBLY__
struct kernel_symbol
{
diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
index b28da79..d07648f 100644
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -30,8 +30,8 @@ __irf_start:
.incbin __stringify(INITRAMFS_IMAGE)
__irf_end:
.section .init.ramfs.info,"a"
-.globl VMLINUX_SYMBOL(__initramfs_size)
-VMLINUX_SYMBOL(__initramfs_size):
+.globl __initramfs_size
+__initramfs_size:
#ifdef CONFIG_64BIT
.quad __irf_end - __irf_start
#else
--
2.7.4
Re: Fix 80d20d35af1e ("nohz: Fix local_timer_softirq_pending()") may have revealed another problem
On 18.08.2018 13:26, Thomas Gleixner wrote:
> On Thu, 16 Aug 2018, Heiner Kallweit wrote:
>
>> Recently I started to get warning "NOHZ: local_softirq_pending 202" and
>> I think it's related to mentioned commit (didn't bisect it yet).
>> See log from suspending.
>>
>> I have no reason to think the fix is wrong, it may just have revealed
>> another issue which existed before and was hidden by the bug.
>
> Looks so. That seems to be related to CPU offlining. No idea yet...
>
I checked a little further and at the time the warning is printed the
cpu is still online but not active any longer.
I can avoid the warning with the following change, but as a
disclaimer: I have no clue of this subsystem and don't know what
I'm doing ..
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 5b33e2f5c..19a030e40 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -862,13 +862,13 @@ static void tick_nohz_full_update_tick(struct tick_sched
*ts)
static bool can_stop_idle_tick(int cpu, struct tick_sched *ts)
{
/*
-* If this CPU is offline and it is the one which updates
+* If this CPU is inactive and it is the one which updates
* jiffies, then give up the assignment and let it be taken by
* the CPU which runs the tick timer next. If we don't drop
* this here the jiffies might be stale and do_timer() never
* invoked.
*/
- if (unlikely(!cpu_online(cpu))) {
+ if (unlikely(!cpu_active(cpu))) {
if (cpu == tick_do_timer_cpu)
tick_do_timer_cpu = TICK_DO_TIMER_NONE;
/*
--
>> Rgds, Heiner
>>
>> [ 75.073353] random: crng init done
>> [ 75.073402] random: 7 urandom warning(s) missed due to ratelimiting
>> [ 78.619564] PM: suspend entry (deep)
>> [ 78.619675] PM: Syncing filesystems ... done.
>> [ 78.653684] Freezing user space processes ... (elapsed 0.002 seconds)
>> done.
>> [ 78.656094] OOM killer disabled.
>> [ 78.656113] Freezing remaining freezable tasks ... (elapsed 0.001
>> seconds) done.
>> [ 78.658177] Suspending console(s) (use no_console_suspend to debug)
>> [ 78.663066] nuvoton-cir 00:07: disabled
>> [ 78.671817] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [ 78.672210] sd 0:0:0:0: [sda] Stopping disk
>> [ 78.786651] ACPI: Preparing to enter system sleep state S3
>> [ 78.789613] PM: Saving platform NVS memory
>> [ 78.789759] Disabling non-boot CPUs ...
>> [ 78.805154] NOHZ: local_softirq_pending 202
>> [ 78.805182] NOHZ: local_softirq_pending 202
>> [ 78.807102] smpboot: CPU 1 is now offline
>>
>
Re: Fix 80d20d35af1e ("nohz: Fix local_timer_softirq_pending()") may have revealed another problem
On 18.08.2018 13:26, Thomas Gleixner wrote:
> On Thu, 16 Aug 2018, Heiner Kallweit wrote:
>
>> Recently I started to get warning "NOHZ: local_softirq_pending 202" and
>> I think it's related to mentioned commit (didn't bisect it yet).
>> See log from suspending.
>>
>> I have no reason to think the fix is wrong, it may just have revealed
>> another issue which existed before and was hidden by the bug.
>
> Looks so. That seems to be related to CPU offlining. No idea yet...
>
I checked a little further and at the time the warning is printed the
cpu is still online but not active any longer.
I can avoid the warning with the following change, but as a
disclaimer: I have no clue of this subsystem and don't know what
I'm doing ..
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 5b33e2f5c..19a030e40 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -862,13 +862,13 @@ static void tick_nohz_full_update_tick(struct tick_sched
*ts)
static bool can_stop_idle_tick(int cpu, struct tick_sched *ts)
{
/*
-* If this CPU is offline and it is the one which updates
+* If this CPU is inactive and it is the one which updates
* jiffies, then give up the assignment and let it be taken by
* the CPU which runs the tick timer next. If we don't drop
* this here the jiffies might be stale and do_timer() never
* invoked.
*/
- if (unlikely(!cpu_online(cpu))) {
+ if (unlikely(!cpu_active(cpu))) {
if (cpu == tick_do_timer_cpu)
tick_do_timer_cpu = TICK_DO_TIMER_NONE;
/*
--
>> Rgds, Heiner
>>
>> [ 75.073353] random: crng init done
>> [ 75.073402] random: 7 urandom warning(s) missed due to ratelimiting
>> [ 78.619564] PM: suspend entry (deep)
>> [ 78.619675] PM: Syncing filesystems ... done.
>> [ 78.653684] Freezing user space processes ... (elapsed 0.002 seconds)
>> done.
>> [ 78.656094] OOM killer disabled.
>> [ 78.656113] Freezing remaining freezable tasks ... (elapsed 0.001
>> seconds) done.
>> [ 78.658177] Suspending console(s) (use no_console_suspend to debug)
>> [ 78.663066] nuvoton-cir 00:07: disabled
>> [ 78.671817] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [ 78.672210] sd 0:0:0:0: [sda] Stopping disk
>> [ 78.786651] ACPI: Preparing to enter system sleep state S3
>> [ 78.789613] PM: Saving platform NVS memory
>> [ 78.789759] Disabling non-boot CPUs ...
>> [ 78.805154] NOHZ: local_softirq_pending 202
>> [ 78.805182] NOHZ: local_softirq_pending 202
>> [ 78.807102] smpboot: CPU 1 is now offline
>>
>
KINDLY REPLY stemlightresour...@gmail.com URGENTLY
KINDLY REPLY stemlightresour...@gmail.com URGENTLY
KINDLY REPLY stemlightresour...@gmail.com URGENTLY
KINDLY REPLY stemlightresour...@gmail.com URGENTLY
KASAN: use-after-free Read in do_shrink_slab
Hello, syzbot found the following crash on: HEAD commit:1f7a4c73a739 Merge tag '9p-for-4.19-2' of git://github.com.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c46d9a40 kernel config: https://syzkaller.appspot.com/x/.config?x=68e80edb3c9718c5 dashboard link: https://syzkaller.appspot.com/bug?extid=d5f648a1bfe15678786b compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d5f648a1bfe156787...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in do_shrink_slab+0xbd4/0xcb0 mm/vmscan.c:456 Read of size 8 at addr 8801ae513558 by task syz-executor6/20506 CPU: 0 PID: 20506 Comm: syz-executor6 Not tainted 4.18.0+ #195 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 do_shrink_slab+0xbd4/0xcb0 mm/vmscan.c:456 shrink_slab_memcg mm/vmscan.c:600 [inline] shrink_slab+0x7b7/0x990 mm/vmscan.c:673 shrink_node+0x429/0x16a0 mm/vmscan.c:2734 shrink_zones mm/vmscan.c:2963 [inline] do_try_to_free_pages+0x3e7/0x1290 mm/vmscan.c:3025 try_to_free_mem_cgroup_pages+0x49d/0xc90 mm/vmscan.c:3323 memory_high_write+0x283/0x310 mm/memcontrol.c:5399 cgroup_file_write+0x31f/0x840 kernel/cgroup/cgroup.c:3447 kernfs_fop_write+0x2ba/0x480 fs/kernfs/file.c:316 __vfs_write+0x117/0x9d0 fs/read_write.c:485 __kernel_write+0x10c/0x380 fs/read_write.c:506 write_pipe_buf+0x181/0x240 fs/splice.c:798 splice_from_pipe_feed fs/splice.c:503 [inline] __splice_from_pipe+0x38e/0x7c0 fs/splice.c:627 splice_from_pipe+0x1ea/0x340 fs/splice.c:662 default_file_splice_write+0x3c/0x90 fs/splice.c:810 do_splice_from fs/splice.c:852 [inline] direct_splice_actor+0x128/0x190 fs/splice.c:1019 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974 do_splice_direct+0x2d4/0x420 fs/splice.c:1062 do_sendfile+0x623/0xe20 fs/read_write.c:1440 __do_sys_sendfile64 fs/read_write.c:1501 [inline] __se_sys_sendfile64 fs/read_write.c:1487 [inline] __x64_sys_sendfile64+0x1fd/0x250 fs/read_write.c:1487 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f7151c7ac78 EFLAGS: 0246 ORIG_RAX: 0028 RAX: ffda RBX: 7f7151c7b6d4 RCX: 00457089 RDX: RSI: 0005 RDI: 0004 RBP: 009300a0 R08: R09: R10: 0001 R11: 0246 R12: R13: 004d3cb0 R14: 004c8769 R15: Allocated by task 19741: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 __do_kmalloc mm/slab.c:3718 [inline] __kmalloc+0x14e/0x760 mm/slab.c:3727 kmalloc_array include/linux/slab.h:635 [inline] kcalloc include/linux/slab.h:646 [inline] iter_file_splice_write+0x25d/0x1010 fs/splice.c:693 do_splice_from fs/splice.c:852 [inline] direct_splice_actor+0x128/0x190 fs/splice.c:1019 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974 do_splice_direct+0x2d4/0x420 fs/splice.c:1062 do_sendfile+0x623/0xe20 fs/read_write.c:1440 __do_sys_sendfile64 fs/read_write.c:1495 [inline] __se_sys_sendfile64 fs/read_write.c:1487 [inline] __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 19741: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xd9/0x260 mm/slab.c:3813 iter_file_splice_write+0x78d/0x1010 fs/splice.c:777 do_splice_from fs/splice.c:852 [inline] direct_splice_actor+0x128/0x190 fs/splice.c:1019 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974 do_splice_direct+0x2d4/0x420 fs/splice.c:1062 do_sendfile+0x623/0xe20 fs/read_write.c:1440 __do_sys_sendfile64 fs/read_write.c:1495 [inline] __se_sys_sendfile64 fs/read_write.c:1487 [inline] __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at
KASAN: use-after-free Read in do_shrink_slab
Hello, syzbot found the following crash on: HEAD commit:1f7a4c73a739 Merge tag '9p-for-4.19-2' of git://github.com.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c46d9a40 kernel config: https://syzkaller.appspot.com/x/.config?x=68e80edb3c9718c5 dashboard link: https://syzkaller.appspot.com/bug?extid=d5f648a1bfe15678786b compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d5f648a1bfe156787...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in do_shrink_slab+0xbd4/0xcb0 mm/vmscan.c:456 Read of size 8 at addr 8801ae513558 by task syz-executor6/20506 CPU: 0 PID: 20506 Comm: syz-executor6 Not tainted 4.18.0+ #195 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 do_shrink_slab+0xbd4/0xcb0 mm/vmscan.c:456 shrink_slab_memcg mm/vmscan.c:600 [inline] shrink_slab+0x7b7/0x990 mm/vmscan.c:673 shrink_node+0x429/0x16a0 mm/vmscan.c:2734 shrink_zones mm/vmscan.c:2963 [inline] do_try_to_free_pages+0x3e7/0x1290 mm/vmscan.c:3025 try_to_free_mem_cgroup_pages+0x49d/0xc90 mm/vmscan.c:3323 memory_high_write+0x283/0x310 mm/memcontrol.c:5399 cgroup_file_write+0x31f/0x840 kernel/cgroup/cgroup.c:3447 kernfs_fop_write+0x2ba/0x480 fs/kernfs/file.c:316 __vfs_write+0x117/0x9d0 fs/read_write.c:485 __kernel_write+0x10c/0x380 fs/read_write.c:506 write_pipe_buf+0x181/0x240 fs/splice.c:798 splice_from_pipe_feed fs/splice.c:503 [inline] __splice_from_pipe+0x38e/0x7c0 fs/splice.c:627 splice_from_pipe+0x1ea/0x340 fs/splice.c:662 default_file_splice_write+0x3c/0x90 fs/splice.c:810 do_splice_from fs/splice.c:852 [inline] direct_splice_actor+0x128/0x190 fs/splice.c:1019 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974 do_splice_direct+0x2d4/0x420 fs/splice.c:1062 do_sendfile+0x623/0xe20 fs/read_write.c:1440 __do_sys_sendfile64 fs/read_write.c:1501 [inline] __se_sys_sendfile64 fs/read_write.c:1487 [inline] __x64_sys_sendfile64+0x1fd/0x250 fs/read_write.c:1487 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f7151c7ac78 EFLAGS: 0246 ORIG_RAX: 0028 RAX: ffda RBX: 7f7151c7b6d4 RCX: 00457089 RDX: RSI: 0005 RDI: 0004 RBP: 009300a0 R08: R09: R10: 0001 R11: 0246 R12: R13: 004d3cb0 R14: 004c8769 R15: Allocated by task 19741: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 __do_kmalloc mm/slab.c:3718 [inline] __kmalloc+0x14e/0x760 mm/slab.c:3727 kmalloc_array include/linux/slab.h:635 [inline] kcalloc include/linux/slab.h:646 [inline] iter_file_splice_write+0x25d/0x1010 fs/splice.c:693 do_splice_from fs/splice.c:852 [inline] direct_splice_actor+0x128/0x190 fs/splice.c:1019 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974 do_splice_direct+0x2d4/0x420 fs/splice.c:1062 do_sendfile+0x623/0xe20 fs/read_write.c:1440 __do_sys_sendfile64 fs/read_write.c:1495 [inline] __se_sys_sendfile64 fs/read_write.c:1487 [inline] __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 19741: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xd9/0x260 mm/slab.c:3813 iter_file_splice_write+0x78d/0x1010 fs/splice.c:777 do_splice_from fs/splice.c:852 [inline] direct_splice_actor+0x128/0x190 fs/splice.c:1019 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974 do_splice_direct+0x2d4/0x420 fs/splice.c:1062 do_sendfile+0x623/0xe20 fs/read_write.c:1440 __do_sys_sendfile64 fs/read_write.c:1495 [inline] __se_sys_sendfile64 fs/read_write.c:1487 [inline] __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at
Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped
On Fri, Aug 17, 2018 at 4:12 PM Frederic Weisbecker wrote:
>
> On Fri, Aug 17, 2018 at 11:32:07AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, August 16, 2018 3:27:24 PM CEST Frederic Weisbecker wrote:
> > > On Thu, Aug 09, 2018 at 07:08:34PM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki
> > > >
> > > > If the tick has been stopped already, but the governor has not asked to
> > > > stop it (which it can do sometimes), the idle loop should invoke
> > > > tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> > > > of this case properly.
> > > >
> > > > Fixes: 554c8aa8ecad (sched: idle: Select idle state before stopping the
> > > > tick)
> > > > Signed-off-by: Rafael J. Wysocki
> > > > ---
> > > > kernel/sched/idle.c |2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Index: linux-pm/kernel/sched/idle.c
> > > > ===
> > > > --- linux-pm.orig/kernel/sched/idle.c
> > > > +++ linux-pm/kernel/sched/idle.c
> > > > @@ -190,7 +190,7 @@ static void cpuidle_idle_call(void)
> > > >*/
> > > > next_state = cpuidle_select(drv, dev, _tick);
> > > >
> > > > - if (stop_tick)
> > > > + if (stop_tick || tick_nohz_tick_stopped())
> > > > tick_nohz_idle_stop_tick();
> > > > else
> > > > tick_nohz_idle_retain_tick();
> > >
> > > So what if tick_nohz_idle_stop_tick() sees no timer to schedule and
> > > cancels it, we may remain idle in a shallow state for a long while?
> >
> > Yes, but the governor is expected to avoid using shallow states when the
> > tick is stopped already.
>
> So what kind of sleep do we enter to when an idle tick fires and we go
> back to idle? Is it always deep?
No, it isn't.
The state to select must always fit the time till the closest timer
event and that may be shorter than the tick period.
If there's a non-tick timer to wake the CPU up, we don't need to worry
about restarting the tick, though. :-)
> I believe that ts->tick_stopped == 1 shouldn't be too relevant for the
> governor.
> We can definetly have scenarios where the idle tick is stopped for a long
> while,
> then it fires and schedules the next timer at NOW() + TICK_NSEC (as if the
> tick
> had been restarted). This can even repeat that way for some time, because
> ts->tick_stopped == 1 only implies that the tick has been stopped once since
> we entered the idle loop. After that we may well have a periodic tick
> behaviour.
> In that case we probably don't want deep idle state. Especially if we have:
>
> idle_loop() {
> tick_stop (scheduled several seconds forward)
> deep_idle_sleep()
> //several seconds later
> tick()
> tick_stop (scheduled TICK_NSEC forward)
> deep_idle_sleep()
> tick() {
> set_need_resched()
> }
> exit idle loop
> }
>
> Here the last deep idle state isn't necessary.
No, it isn't.
However, that is not relevant for the question of whether or not to
restart the tick before entering the idle state IMO (see the
considerations below).
> >
> > > Otherwise we can have something like this:
> > >
> > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > index da9455a..408c985 100644
> > > --- a/kernel/time/tick-sched.c
> > > +++ b/kernel/time/tick-sched.c
> > > @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched
> > > *ts, int cpu)
> > > static void tick_nohz_retain_tick(struct tick_sched *ts)
> > > {
> > > ts->timer_expires_base = 0;
> > > +
> > > + if (ts->tick_stopped)
> > > + tick_nohz_restart(ts, ktime_get());
> > > }
> > >
> > > #ifdef CONFIG_NO_HZ_FULL
> > >
> >
> > We could do that, but my concern with that approach is that we may end up
> > stopping and starting the tick back and forth without exiting the loop
> > in do_idle() just because somebody uses a periodic timer behind our
> > back and the governor gets confused.
> >
> > Besides, that would be a change in behavior, while the $subject patch
> > simply fixes a mistake in the original design.
>
> Ok, let's take the safe approach for now as this is a fix and it should even
> be
> routed to stable.
Right. I'll queue up this patch, then.
> But then in the longer term, perhaps cpuidle_select() should think that
> through.
So I have given more consideration to this and my conclusion is that
restarting the tick between cpuidle_select() and call_cpuidle() is a
bad idea.
First off, if need_resched() is "false", the primary reason for
running the tick on the given CPU is not there, so it only might be
useful as a "backup" timer to wake up the CPU from an inadequate idle
state.
Now, in general, there are two reasons for the idle governor (whatever
it is) to select an idle state with a
Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped
On Fri, Aug 17, 2018 at 4:12 PM Frederic Weisbecker wrote:
>
> On Fri, Aug 17, 2018 at 11:32:07AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, August 16, 2018 3:27:24 PM CEST Frederic Weisbecker wrote:
> > > On Thu, Aug 09, 2018 at 07:08:34PM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki
> > > >
> > > > If the tick has been stopped already, but the governor has not asked to
> > > > stop it (which it can do sometimes), the idle loop should invoke
> > > > tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> > > > of this case properly.
> > > >
> > > > Fixes: 554c8aa8ecad (sched: idle: Select idle state before stopping the
> > > > tick)
> > > > Signed-off-by: Rafael J. Wysocki
> > > > ---
> > > > kernel/sched/idle.c |2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Index: linux-pm/kernel/sched/idle.c
> > > > ===
> > > > --- linux-pm.orig/kernel/sched/idle.c
> > > > +++ linux-pm/kernel/sched/idle.c
> > > > @@ -190,7 +190,7 @@ static void cpuidle_idle_call(void)
> > > >*/
> > > > next_state = cpuidle_select(drv, dev, _tick);
> > > >
> > > > - if (stop_tick)
> > > > + if (stop_tick || tick_nohz_tick_stopped())
> > > > tick_nohz_idle_stop_tick();
> > > > else
> > > > tick_nohz_idle_retain_tick();
> > >
> > > So what if tick_nohz_idle_stop_tick() sees no timer to schedule and
> > > cancels it, we may remain idle in a shallow state for a long while?
> >
> > Yes, but the governor is expected to avoid using shallow states when the
> > tick is stopped already.
>
> So what kind of sleep do we enter to when an idle tick fires and we go
> back to idle? Is it always deep?
No, it isn't.
The state to select must always fit the time till the closest timer
event and that may be shorter than the tick period.
If there's a non-tick timer to wake the CPU up, we don't need to worry
about restarting the tick, though. :-)
> I believe that ts->tick_stopped == 1 shouldn't be too relevant for the
> governor.
> We can definetly have scenarios where the idle tick is stopped for a long
> while,
> then it fires and schedules the next timer at NOW() + TICK_NSEC (as if the
> tick
> had been restarted). This can even repeat that way for some time, because
> ts->tick_stopped == 1 only implies that the tick has been stopped once since
> we entered the idle loop. After that we may well have a periodic tick
> behaviour.
> In that case we probably don't want deep idle state. Especially if we have:
>
> idle_loop() {
> tick_stop (scheduled several seconds forward)
> deep_idle_sleep()
> //several seconds later
> tick()
> tick_stop (scheduled TICK_NSEC forward)
> deep_idle_sleep()
> tick() {
> set_need_resched()
> }
> exit idle loop
> }
>
> Here the last deep idle state isn't necessary.
No, it isn't.
However, that is not relevant for the question of whether or not to
restart the tick before entering the idle state IMO (see the
considerations below).
> >
> > > Otherwise we can have something like this:
> > >
> > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > index da9455a..408c985 100644
> > > --- a/kernel/time/tick-sched.c
> > > +++ b/kernel/time/tick-sched.c
> > > @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched
> > > *ts, int cpu)
> > > static void tick_nohz_retain_tick(struct tick_sched *ts)
> > > {
> > > ts->timer_expires_base = 0;
> > > +
> > > + if (ts->tick_stopped)
> > > + tick_nohz_restart(ts, ktime_get());
> > > }
> > >
> > > #ifdef CONFIG_NO_HZ_FULL
> > >
> >
> > We could do that, but my concern with that approach is that we may end up
> > stopping and starting the tick back and forth without exiting the loop
> > in do_idle() just because somebody uses a periodic timer behind our
> > back and the governor gets confused.
> >
> > Besides, that would be a change in behavior, while the $subject patch
> > simply fixes a mistake in the original design.
>
> Ok, let's take the safe approach for now as this is a fix and it should even
> be
> routed to stable.
Right. I'll queue up this patch, then.
> But then in the longer term, perhaps cpuidle_select() should think that
> through.
So I have given more consideration to this and my conclusion is that
restarting the tick between cpuidle_select() and call_cpuidle() is a
bad idea.
First off, if need_resched() is "false", the primary reason for
running the tick on the given CPU is not there, so it only might be
useful as a "backup" timer to wake up the CPU from an inadequate idle
state.
Now, in general, there are two reasons for the idle governor (whatever
it is) to select an idle state with a
[RFC PATCH] scripts: add header bloat measuring script
With a little cooperation from fixdep, we can rather easily quantify the
header bloat phenomenon.
While computing CONFIG_ dependencies, fixdep opens all the headers used
by a given translation unit anyway, so it's rather cheap to have it
record the number and total size of those in the generated .o.cmd file.
Those lines can then be post-processed and summarized by the new
header-bloat-stat.pl script. For example, backporting this to v4.17 and
v4.18 releases shows that for a defconfig x86_64 kernel, the median
"bloat factor" (total size of translation unit)/(size of .c file)
increased from 237.7 to 239.8, and the average total translation unit
size grew by 2.5% while the average .c file only increased by
0.4%. While these numbers by themselves are not particularly alarming,
when accumulated over several releases, builds do get noticably slower -
back at v3.0, the median bloat factor was 177.8.
Having infrastrucure like this makes it easier to measure the effect
should anyone attempt something similar to the sched.h cleanup, or just
go over a subsystem trimming unused #includes from .c files (if the
script is passed one or more directories it only processes those).
On a positive note, maybe 4.19 will be a rare exception; as of
1f7a4c73a739, the median bloat factor is down to 236.0, the average .c
file has increased by 0.4% but the average total translation unit is
nevertheless 1.2% smaller, compared to v4.18.
Signed-off-by: Rasmus Villemoes
---
For some statistics, that also include build times, for releases v3.0
through v4.15, see https://wildmoose.dk/header-bloat/ . I'm not sure
that page will remain forever, so not including the url in the commit
log.
I can certainly understand if people feel this is of too little
utility to hook into fixdep like this. It's certainly possible to do
the same statistics with external tools that just parse the .o.cmd
files themselves.
scripts/basic/fixdep.c | 18 +++--
scripts/header-bloat-stat.pl | 95
2 files changed, 109 insertions(+), 4 deletions(-)
create mode 100755 scripts/header-bloat-stat.pl
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 850966f3d602..f1dec85cf9d9 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -248,7 +248,7 @@ static void parse_config_file(const char *p)
}
}
-static void *read_file(const char *filename)
+static void *read_file(const char *filename, unsigned *size)
{
struct stat st;
int fd;
@@ -276,6 +276,8 @@ static void *read_file(const char *filename)
}
buf[st.st_size] = '\0';
close(fd);
+ if (size)
+ *size += st.st_size;
return buf;
}
@@ -300,6 +302,8 @@ static void parse_dep_file(char *m, const char *target, int
insert_extra_deps)
int saw_any_target = 0;
int is_first_dep = 0;
void *buf;
+ unsigned nheaders = 0, c_size = 0, h_size = 0;
+ unsigned *sizevar;
while (1) {
/* Skip any "white space" */
@@ -321,6 +325,8 @@ static void parse_dep_file(char *m, const char *target, int
insert_extra_deps)
/* The /next/ file is the first dependency */
is_first_dep = 1;
} else if (!is_ignored_file(m, p - m)) {
+ sizevar = NULL;
+
*p = '\0';
/*
@@ -343,13 +349,16 @@ static void parse_dep_file(char *m, const char *target,
int insert_extra_deps)
printf("source_%s := %s\n\n",
target, m);
printf("deps_%s := \\\n", target);
+ sizevar = _size;
}
is_first_dep = 0;
} else {
printf(" %s \\\n", m);
+ sizevar = _size;
+ nheaders++;
}
- buf = read_file(m);
+ buf = read_file(m, sizevar);
parse_config_file(buf);
free(buf);
}
@@ -373,7 +382,8 @@ static void parse_dep_file(char *m, const char *target, int
insert_extra_deps)
do_extra_deps();
printf("\n%s: $(deps_%s)\n\n", target, target);
- printf("$(deps_%s):\n", target);
+ printf("$(deps_%s):\n\n", target);
+ printf("# header-stats: %u %u %u\n", nheaders, c_size, h_size);
}
int main(int argc, char *argv[])
@@ -394,7 +404,7 @@ int main(int argc, char *argv[])
printf("cmd_%s := %s\n\n", target, cmdline);
- buf = read_file(depfile);
+ buf = read_file(depfile, NULL);
parse_dep_file(buf, target, insert_extra_deps);
free(buf);
diff --git a/scripts/header-bloat-stat.pl
[RFC PATCH] scripts: add header bloat measuring script
With a little cooperation from fixdep, we can rather easily quantify the
header bloat phenomenon.
While computing CONFIG_ dependencies, fixdep opens all the headers used
by a given translation unit anyway, so it's rather cheap to have it
record the number and total size of those in the generated .o.cmd file.
Those lines can then be post-processed and summarized by the new
header-bloat-stat.pl script. For example, backporting this to v4.17 and
v4.18 releases shows that for a defconfig x86_64 kernel, the median
"bloat factor" (total size of translation unit)/(size of .c file)
increased from 237.7 to 239.8, and the average total translation unit
size grew by 2.5% while the average .c file only increased by
0.4%. While these numbers by themselves are not particularly alarming,
when accumulated over several releases, builds do get noticably slower -
back at v3.0, the median bloat factor was 177.8.
Having infrastrucure like this makes it easier to measure the effect
should anyone attempt something similar to the sched.h cleanup, or just
go over a subsystem trimming unused #includes from .c files (if the
script is passed one or more directories it only processes those).
On a positive note, maybe 4.19 will be a rare exception; as of
1f7a4c73a739, the median bloat factor is down to 236.0, the average .c
file has increased by 0.4% but the average total translation unit is
nevertheless 1.2% smaller, compared to v4.18.
Signed-off-by: Rasmus Villemoes
---
For some statistics, that also include build times, for releases v3.0
through v4.15, see https://wildmoose.dk/header-bloat/ . I'm not sure
that page will remain forever, so not including the url in the commit
log.
I can certainly understand if people feel this is of too little
utility to hook into fixdep like this. It's certainly possible to do
the same statistics with external tools that just parse the .o.cmd
files themselves.
scripts/basic/fixdep.c | 18 +++--
scripts/header-bloat-stat.pl | 95
2 files changed, 109 insertions(+), 4 deletions(-)
create mode 100755 scripts/header-bloat-stat.pl
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 850966f3d602..f1dec85cf9d9 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -248,7 +248,7 @@ static void parse_config_file(const char *p)
}
}
-static void *read_file(const char *filename)
+static void *read_file(const char *filename, unsigned *size)
{
struct stat st;
int fd;
@@ -276,6 +276,8 @@ static void *read_file(const char *filename)
}
buf[st.st_size] = '\0';
close(fd);
+ if (size)
+ *size += st.st_size;
return buf;
}
@@ -300,6 +302,8 @@ static void parse_dep_file(char *m, const char *target, int
insert_extra_deps)
int saw_any_target = 0;
int is_first_dep = 0;
void *buf;
+ unsigned nheaders = 0, c_size = 0, h_size = 0;
+ unsigned *sizevar;
while (1) {
/* Skip any "white space" */
@@ -321,6 +325,8 @@ static void parse_dep_file(char *m, const char *target, int
insert_extra_deps)
/* The /next/ file is the first dependency */
is_first_dep = 1;
} else if (!is_ignored_file(m, p - m)) {
+ sizevar = NULL;
+
*p = '\0';
/*
@@ -343,13 +349,16 @@ static void parse_dep_file(char *m, const char *target,
int insert_extra_deps)
printf("source_%s := %s\n\n",
target, m);
printf("deps_%s := \\\n", target);
+ sizevar = _size;
}
is_first_dep = 0;
} else {
printf(" %s \\\n", m);
+ sizevar = _size;
+ nheaders++;
}
- buf = read_file(m);
+ buf = read_file(m, sizevar);
parse_config_file(buf);
free(buf);
}
@@ -373,7 +382,8 @@ static void parse_dep_file(char *m, const char *target, int
insert_extra_deps)
do_extra_deps();
printf("\n%s: $(deps_%s)\n\n", target, target);
- printf("$(deps_%s):\n", target);
+ printf("$(deps_%s):\n\n", target);
+ printf("# header-stats: %u %u %u\n", nheaders, c_size, h_size);
}
int main(int argc, char *argv[])
@@ -394,7 +404,7 @@ int main(int argc, char *argv[])
printf("cmd_%s := %s\n\n", target, cmdline);
- buf = read_file(depfile);
+ buf = read_file(depfile, NULL);
parse_dep_file(buf, target, insert_extra_deps);
free(buf);
diff --git a/scripts/header-bloat-stat.pl
[PATCH] dt-bindings: input: pwm-vibrator: correct pwm-names in example
In the example for the pwm-vibrator bindings, pwm8 is the direction pin, and pwm9 is the enable pin. The pwm-names on the vibrator node has these two values swapped. This patch corrects the values for pwm-names. Signed-off-by: Brian Masney --- arch/arm/boot/dts/omap4-droid4-xt894.dts is actual implementation for the example and it is correct. Documentation/devicetree/bindings/input/pwm-vibrator.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt b/Documentation/devicetree/bindings/input/pwm-vibrator.txt index 09145d18491d..2731cbb7e8d7 100644 --- a/Documentation/devicetree/bindings/input/pwm-vibrator.txt +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt @@ -60,7 +60,7 @@ Example from Motorola Droid 4: compatible = "pwm-vibrator"; pwms = < 0 10 0>, < 0 10 0>; - pwm-names = "enable", "direction"; + pwm-names = "direction", "enable"; direction-duty-cycle-ns = <10>; }; }; -- 2.17.1
[PATCH] dt-bindings: input: pwm-vibrator: correct pwm-names in example
In the example for the pwm-vibrator bindings, pwm8 is the direction pin, and pwm9 is the enable pin. The pwm-names on the vibrator node has these two values swapped. This patch corrects the values for pwm-names. Signed-off-by: Brian Masney --- arch/arm/boot/dts/omap4-droid4-xt894.dts is actual implementation for the example and it is correct. Documentation/devicetree/bindings/input/pwm-vibrator.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt b/Documentation/devicetree/bindings/input/pwm-vibrator.txt index 09145d18491d..2731cbb7e8d7 100644 --- a/Documentation/devicetree/bindings/input/pwm-vibrator.txt +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt @@ -60,7 +60,7 @@ Example from Motorola Droid 4: compatible = "pwm-vibrator"; pwms = < 0 10 0>, < 0 10 0>; - pwm-names = "enable", "direction"; + pwm-names = "direction", "enable"; direction-duty-cycle-ns = <10>; }; }; -- 2.17.1
Re: [PATCH] Revert "Permit silencing of __deprecated warnings."
On Fri, Aug 17, 2018 at 7:45 PM Jason Gunthorpe wrote: > > Linus would prefer that __deprecated never produce a warning in an > allyesconfig compile. Since we have been at this state for some time, > the option no longer has a purpose. I got rid of the option, but of the code too, and - trying to set a good example - looked around for actual users and got rid of one long-deprecated function that hasn't had an in-kernel user in four years. If there are some out-of-kernel modules still using pcmcia_request_exclusive_irq(), I can only say "Oh wow, you haven't fixed your broken out-of-tree module in the 8 years it has been deprecated, see how much I care about your complaints now". Maybe somebody will be willing to look at other cases of __deprecated, but at least I won't be seeing warnings about it any more. Linus
Re: [PATCH] Revert "Permit silencing of __deprecated warnings."
On Fri, Aug 17, 2018 at 7:45 PM Jason Gunthorpe wrote: > > Linus would prefer that __deprecated never produce a warning in an > allyesconfig compile. Since we have been at this state for some time, > the option no longer has a purpose. I got rid of the option, but of the code too, and - trying to set a good example - looked around for actual users and got rid of one long-deprecated function that hasn't had an in-kernel user in four years. If there are some out-of-kernel modules still using pcmcia_request_exclusive_irq(), I can only say "Oh wow, you haven't fixed your broken out-of-tree module in the 8 years it has been deprecated, see how much I care about your complaints now". Maybe somebody will be willing to look at other cases of __deprecated, but at least I won't be seeing warnings about it any more. Linus
[PATCH] staging: rtl8188eu: Removed a function and coded inline
This patch removed function named rtw_malloc2d.
I removed this function because this function is used exactly once and
function call have some overhead also.
Maybe this will improve code runtime slightly.
Signed-off-by: Bhaskar Singh
---
drivers/staging/rtl8188eu/core/rtw_efuse.c| 10 +-
drivers/staging/rtl8188eu/include/osdep_service.h | 2 --
drivers/staging/rtl8188eu/os_dep/osdep_service.c | 14 --
3 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 0fd306a808c4..befc99c197b1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
+++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
@@ -86,12 +86,20 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16
_size_byte, u8 *pbuf)
u16 **eFuseWord = NULL;
u16 efuse_utilized = 0;
u8 u1temp = 0;
+ int z;
+ void **a = NULL;
efuseTbl = kzalloc(EFUSE_MAP_LEN_88E, GFP_KERNEL);
if (!efuseTbl)
return;
- eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E,
EFUSE_MAX_WORD_UNIT, sizeof(u16));
+ a = kzalloc(EFUSE_MAX_SECTION_88E * sizeof(void *) +
EFUSE_MAX_SECTION_88E * EFUSE_MAX_WORD_UNIT * sizeof(u16), GFP_KERNEL);
+ if (!a)
+ goto out;
+ for (z = 0; z < EFUSE_MAX_SECTION_88E; z++)
+ a[z] = ((char *)(a + EFUSE_MAX_SECTION_88E)) + z *
EFUSE_MAX_WORD_UNIT * sizeof(u16);
+out:
+ eFuseWord = (u16 **)a;
if (!eFuseWord) {
DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
goto eFuseWord_failed;
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h
b/drivers/staging/rtl8188eu/include/osdep_service.h
index fbcba79a0927..cfe5698fbbb1 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -64,8 +64,6 @@ static inline int rtw_netif_queue_stopped(struct net_device
*pnetdev)
u8 *_rtw_malloc(u32 sz);
#define rtw_malloc(sz) _rtw_malloc((sz))
-void *rtw_malloc2d(int h, int w, int size);
-
void _rtw_init_queue(struct __queue *pqueue);
struct rtw_netdev_priv_indicator {
diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index 78daef6704ac..105f3f21bdea 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -18,20 +18,6 @@ u8 *_rtw_malloc(u32 sz)
return kmalloc(sz, in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
}
-void *rtw_malloc2d(int h, int w, int size)
-{
- int j;
- void **a = kzalloc(h * sizeof(void *) + h * w * size, GFP_KERNEL);
-
- if (!a)
- goto out;
-
- for (j = 0; j < h; j++)
- a[j] = ((char *)(a + h)) + j * w * size;
-out:
- return a;
-}
-
void _rtw_init_queue(struct __queue *pqueue)
{
INIT_LIST_HEAD(>queue);
--
2.16.4
[PATCH] staging: rtl8188eu: Removed a function and coded inline
This patch removed function named rtw_malloc2d.
I removed this function because this function is used exactly once and
function call have some overhead also.
Maybe this will improve code runtime slightly.
Signed-off-by: Bhaskar Singh
---
drivers/staging/rtl8188eu/core/rtw_efuse.c| 10 +-
drivers/staging/rtl8188eu/include/osdep_service.h | 2 --
drivers/staging/rtl8188eu/os_dep/osdep_service.c | 14 --
3 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 0fd306a808c4..befc99c197b1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
+++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
@@ -86,12 +86,20 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16
_size_byte, u8 *pbuf)
u16 **eFuseWord = NULL;
u16 efuse_utilized = 0;
u8 u1temp = 0;
+ int z;
+ void **a = NULL;
efuseTbl = kzalloc(EFUSE_MAP_LEN_88E, GFP_KERNEL);
if (!efuseTbl)
return;
- eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E,
EFUSE_MAX_WORD_UNIT, sizeof(u16));
+ a = kzalloc(EFUSE_MAX_SECTION_88E * sizeof(void *) +
EFUSE_MAX_SECTION_88E * EFUSE_MAX_WORD_UNIT * sizeof(u16), GFP_KERNEL);
+ if (!a)
+ goto out;
+ for (z = 0; z < EFUSE_MAX_SECTION_88E; z++)
+ a[z] = ((char *)(a + EFUSE_MAX_SECTION_88E)) + z *
EFUSE_MAX_WORD_UNIT * sizeof(u16);
+out:
+ eFuseWord = (u16 **)a;
if (!eFuseWord) {
DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
goto eFuseWord_failed;
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h
b/drivers/staging/rtl8188eu/include/osdep_service.h
index fbcba79a0927..cfe5698fbbb1 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -64,8 +64,6 @@ static inline int rtw_netif_queue_stopped(struct net_device
*pnetdev)
u8 *_rtw_malloc(u32 sz);
#define rtw_malloc(sz) _rtw_malloc((sz))
-void *rtw_malloc2d(int h, int w, int size);
-
void _rtw_init_queue(struct __queue *pqueue);
struct rtw_netdev_priv_indicator {
diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index 78daef6704ac..105f3f21bdea 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -18,20 +18,6 @@ u8 *_rtw_malloc(u32 sz)
return kmalloc(sz, in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
}
-void *rtw_malloc2d(int h, int w, int size)
-{
- int j;
- void **a = kzalloc(h * sizeof(void *) + h * w * size, GFP_KERNEL);
-
- if (!a)
- goto out;
-
- for (j = 0; j < h; j++)
- a[j] = ((char *)(a + h)) + j * w * size;
-out:
- return a;
-}
-
void _rtw_init_queue(struct __queue *pqueue)
{
INIT_LIST_HEAD(>queue);
--
2.16.4
Re: Current LTS and their EOL
On Fri, 2018-08-17 at 23:48 +0100, Greg KH wrote: > On Fri, Aug 17, 2018 at 08:40:06AM -0700, Rodrigo Vivi wrote: > > Hi Greg, Ben, and all > > > > Is https://www.kernel.org/category/releases.html updated in terms of EOL? > > As of right now, for the kernels I maintain, yes, it is correct. > > > Some news out of Linaro conference [2] generated a lot of doubts and > > questions > > around. > > > > Specially because on the way it was stated by the news 3.16 wouldn't be > > active > > anymore. So I'm not sure about the news, but I'd like confirmation from you > > about > > expected EOL. > > Linaro has nothing to do with the 3.16 kernel, so why are you confusing > that with what was announced at that conference, which was about the 4.4 > kernel tree? The article says that other longterm branches are only supported for 2 years - which has been your usual practice, but obviously doesn't reflect what all stable maintainers have done. I try to ensure that every stable branch used in a Debian release is maintained for the lifetime of that Debian release. That means 5-6 years after the initial release of the kernel version. So far that has included 2.6.32 (maintained by Willy Tarreau), 3.2 and 3.16 (maintained by me). In the latest release we used Linux 4.9 which currently has a stated EOL of 2019. But I'm prepared to take on maintenance from that point until June 2022. Greg, is that OK with you and should the EOL be updated on that basis? Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, on joining IRC signature.asc Description: This is a digitally signed message part
Re: Current LTS and their EOL
On Fri, 2018-08-17 at 23:48 +0100, Greg KH wrote: > On Fri, Aug 17, 2018 at 08:40:06AM -0700, Rodrigo Vivi wrote: > > Hi Greg, Ben, and all > > > > Is https://www.kernel.org/category/releases.html updated in terms of EOL? > > As of right now, for the kernels I maintain, yes, it is correct. > > > Some news out of Linaro conference [2] generated a lot of doubts and > > questions > > around. > > > > Specially because on the way it was stated by the news 3.16 wouldn't be > > active > > anymore. So I'm not sure about the news, but I'd like confirmation from you > > about > > expected EOL. > > Linaro has nothing to do with the 3.16 kernel, so why are you confusing > that with what was announced at that conference, which was about the 4.4 > kernel tree? The article says that other longterm branches are only supported for 2 years - which has been your usual practice, but obviously doesn't reflect what all stable maintainers have done. I try to ensure that every stable branch used in a Debian release is maintained for the lifetime of that Debian release. That means 5-6 years after the initial release of the kernel version. So far that has included 2.6.32 (maintained by Willy Tarreau), 3.2 and 3.16 (maintained by me). In the latest release we used Linux 4.9 which currently has a stated EOL of 2019. But I'm prepared to take on maintenance from that point until June 2022. Greg, is that OK with you and should the EOL be updated on that basis? Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, on joining IRC signature.asc Description: This is a digitally signed message part
[PATCH] cdrom: gdrom: Fix spelling of 'additional'
'additional' was misspelled as 'addional'. Fixed it. It is a coding
style change which should have no impact on runtime execution of code.
Signed-off-by: Faisal Mehmood
---
drivers/cdrom/gdrom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index ae3a7537cf0f..38139e0854fb 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -463,7 +463,7 @@ static int gdrom_getsense(short *bufstring)
pr_info("%s\n", sense_texts[sense_key].text);
else
pr_err("Unknown sense key: %d\n", sense_key);
- if (bufstring) /* return addional sense data */
+ if (bufstring) /* return additional sense data */
memcpy(bufstring, [4], 2);
if (sense_key < 2)
err = 0;
--
2.18.0
[PATCH] cdrom: gdrom: Fix spelling of 'additional'
'additional' was misspelled as 'addional'. Fixed it. It is a coding
style change which should have no impact on runtime execution of code.
Signed-off-by: Faisal Mehmood
---
drivers/cdrom/gdrom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index ae3a7537cf0f..38139e0854fb 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -463,7 +463,7 @@ static int gdrom_getsense(short *bufstring)
pr_info("%s\n", sense_texts[sense_key].text);
else
pr_err("Unknown sense key: %d\n", sense_key);
- if (bufstring) /* return addional sense data */
+ if (bufstring) /* return additional sense data */
memcpy(bufstring, [4], 2);
if (sense_key < 2)
err = 0;
--
2.18.0
[PATCH] hid: hid-logitech-hidpp: Fix spelling of 'length'
'length' was misspelled as 'lenth'. Fixed it. It is a coding style change which should have no impact on runtime execution of code. Signed-off-by: Faisal Mehmood --- drivers/hid/hid-logitech-hidpp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 19cc980eebce..b89c0f5b8895 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -81,7 +81,7 @@ MODULE_PARM_DESC(disable_tap_to_click, * where as most newer devices use the FAP protocol. Both protocols are * compatible with the underlying transport, which could be usb, Unifiying, or * bluetooth. The message lengths are defined by the hid vendor specific report - * descriptor for the HIDPP_SHORT report type (total message lenth 7 bytes) and + * descriptor for the HIDPP_SHORT report type (total message length 7 bytes) and * the HIDPP_LONG report type (total message length 20 bytes) * * The RAP protocol uses both report types, whereas the FAP only uses HIDPP_LONG -- 2.18.0
[PATCH] hid: hid-logitech-hidpp: Fix spelling of 'length'
'length' was misspelled as 'lenth'. Fixed it. It is a coding style change which should have no impact on runtime execution of code. Signed-off-by: Faisal Mehmood --- drivers/hid/hid-logitech-hidpp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 19cc980eebce..b89c0f5b8895 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -81,7 +81,7 @@ MODULE_PARM_DESC(disable_tap_to_click, * where as most newer devices use the FAP protocol. Both protocols are * compatible with the underlying transport, which could be usb, Unifiying, or * bluetooth. The message lengths are defined by the hid vendor specific report - * descriptor for the HIDPP_SHORT report type (total message lenth 7 bytes) and + * descriptor for the HIDPP_SHORT report type (total message length 7 bytes) and * the HIDPP_LONG report type (total message length 20 bytes) * * The RAP protocol uses both report types, whereas the FAP only uses HIDPP_LONG -- 2.18.0
[PATCH v2 1/1] hdac-codec runtime suspended at PM:Suspend.
Keep hdac hdmi codec to be in runtime suspended while entering to system wide suspend. Currently hdac hdmi codec driver using its suspend and resume operation in prepare and complete PM callbacks, and it resumes the hd audio controller (parent of self) from runtime suspend and blocks the direct complete for hd audio controller. If hdac-codec is already in runtime suspend state skip its power down sequence in prepare, power up sequence in complete phase. It enables direct complete path for hdac-codec and hd audio controller PCI device. Signed-off-by: Anshuman Gupta --- Changes in v2 - Changed the commit message. - Using pm_runtime_suspended instead of pm_runtime_status_suspended in order to handle any race condition. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 84f7a7a..e965338 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1859,6 +1859,9 @@ static int hdmi_codec_prepare(struct device *dev) struct hdac_ext_device *edev = to_hda_ext_device(dev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return 1; + pm_runtime_get_sync(>hdev.dev); /* @@ -1880,6 +1883,9 @@ static void hdmi_codec_complete(struct device *dev) struct hdac_hdmi_priv *hdmi = hdev_to_hdmi_priv(>hdev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return; + /* Power up afg */ snd_hdac_codec_read(hdev, hdev->afg, 0, AC_VERB_SET_POWER_STATE, AC_PWRST_D0); -- 2.7.4
[PATCH v2 1/1] hdac-codec runtime suspended at PM:Suspend.
Keep hdac hdmi codec to be in runtime suspended while entering to system wide suspend. Currently hdac hdmi codec driver using its suspend and resume operation in prepare and complete PM callbacks, and it resumes the hd audio controller (parent of self) from runtime suspend and blocks the direct complete for hd audio controller. If hdac-codec is already in runtime suspend state skip its power down sequence in prepare, power up sequence in complete phase. It enables direct complete path for hdac-codec and hd audio controller PCI device. Signed-off-by: Anshuman Gupta --- Changes in v2 - Changed the commit message. - Using pm_runtime_suspended instead of pm_runtime_status_suspended in order to handle any race condition. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 84f7a7a..e965338 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1859,6 +1859,9 @@ static int hdmi_codec_prepare(struct device *dev) struct hdac_ext_device *edev = to_hda_ext_device(dev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return 1; + pm_runtime_get_sync(>hdev.dev); /* @@ -1880,6 +1883,9 @@ static void hdmi_codec_complete(struct device *dev) struct hdac_hdmi_priv *hdmi = hdev_to_hdmi_priv(>hdev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return; + /* Power up afg */ snd_hdac_codec_read(hdev, hdev->afg, 0, AC_VERB_SET_POWER_STATE, AC_PWRST_D0); -- 2.7.4
[PATCH v2 0/1] cover-letter hdac-codec runtime suspended at PM:Suspend.
Current implementation of hdac hdmi codec driver uses its suspend/resume operation callback in its prepare/complete callback which has issues with hdac direct-complete, it has been reviewed earlier that hdac hdmi codec driver requires a rework (https://patchwork.kernel.org/patch/10276021/), but as there is no rework with driver, it require to fix hdac direct complete issue to leverage hdac direct complete in order to optimize its resume latency while resuming from system wide suspend. Anshuman Gupta (1): hdac-codec runtime suspended at PM:Suspend. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) -- 2.7.4
[PATCH v2 0/1] cover-letter hdac-codec runtime suspended at PM:Suspend.
Current implementation of hdac hdmi codec driver uses its suspend/resume operation callback in its prepare/complete callback which has issues with hdac direct-complete, it has been reviewed earlier that hdac hdmi codec driver requires a rework (https://patchwork.kernel.org/patch/10276021/), but as there is no rework with driver, it require to fix hdac direct complete issue to leverage hdac direct complete in order to optimize its resume latency while resuming from system wide suspend. Anshuman Gupta (1): hdac-codec runtime suspended at PM:Suspend. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) -- 2.7.4
Re: [GIT PULL] RISC-V Updates for the 4.19 Merge Window
On Fri, Aug 17, 2018 at 1:28 PM Palmer Dabbelt wrote: > > I remember having sent this on Wednesday, but for some reason I don't see it > in > your tree or my outbox so I might be crazy. You might indeed have been having hallucinations. I don't see any other pull request from you in my mailbox than this one. Google does find a posting from you saying "Below is the pull request I plan to submit on Wednesday morning" on the RISC-V development google group list, so I think you just remembered your _plan_, not your actual email ... Anyway, I can confirm that this new pull request is now in my queue even if I don't see any earlier ones. Linus
Re: [GIT PULL] RISC-V Updates for the 4.19 Merge Window
On Fri, Aug 17, 2018 at 1:28 PM Palmer Dabbelt wrote: > > I remember having sent this on Wednesday, but for some reason I don't see it > in > your tree or my outbox so I might be crazy. You might indeed have been having hallucinations. I don't see any other pull request from you in my mailbox than this one. Google does find a posting from you saying "Below is the pull request I plan to submit on Wednesday morning" on the RISC-V development google group list, so I think you just remembered your _plan_, not your actual email ... Anyway, I can confirm that this new pull request is now in my queue even if I don't see any earlier ones. Linus
[PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
We have a need to override the definition of
barrier_before_unreachable() for MIPS, which means we either need to add
architecture-specific code into linux/compiler-gcc.h or we need to allow
the architecture to provide a header that can define the macro before
the generic definition. The latter seems like the better approach.
A straightforward approach to the per-arch header is to make use of
asm-generic to provide a default empty header & adjust architectures
which don't need anything specific to make use of that by adding the
header to generic-y. Unfortunately this doesn't work so well due to
commit a95b37e20db9 ("kbuild: get out of
") which moved the inclusion of linux/compiler.h to
cflags using the -include compiler flag.
Because the -include flag is present for all C files we compile, we need
the architecture-provided header to be present before any C files are
compiled. If any C files can be compiled prior to the asm-generic header
wrappers being generated then we hit a build failure due to missing
header. Such cases do exist - one pointed out by the kbuild test robot
is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
of the archprepare target [1].
This leaves us with a few options:
1) Use generic-y & fix any build failures we find by enforcing
ordering such that the asm-generic target occurs before any C
compilation, such that linux/compiler_types.h can always include
the generated asm-generic wrapper which in turn includes the empty
asm-generic header. This would rely on us finding all the
problematic cases - I don't know for sure that the ia64 issue is
the only one.
2) Add an actual empty header to each architecture, so that we don't
need the generated asm-generic wrapper. This seems messy.
3) Give up & add #ifdef CONFIG_MIPS or similar to
linux/compiler_types.h. This seems messy too.
4) Include the arch header only when it's actually needed, removing
the need for the asm-generic wrapper for all other architectures.
This patch allows us to use approach 4, by including an
asm/compiler_types.h header using the -include flag in the same way we
do for linux/compiler_types.h, but only if the header actually exists.
[1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
Signed-off-by: Paul Burton
Cc: Arnd Bergmann
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Ralf Baechle
Cc: linux-a...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Any thoughts anyone?
This isn't the prettiest it could possibly be but it's a small change &
clearly shouldn't break anything, which are good qualities for a patch
fixing build failures that we'd ideally backport as far as 4.16.
Changes in v8:
- New patch.
scripts/Makefile.lib | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1bb594fcfe12..4e7b41ef029b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -151,8 +151,11 @@ __a_flags = $(call flags,_a_flags)
__cpp_flags = $(call flags,_cpp_flags)
endif
+c_includes = $(wildcard
$(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
+c_includes += $(srctree)/include/linux/compiler_types.h
+
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
--include $(srctree)/include/linux/compiler_types.h \
+$(addprefix -include ,$(c_includes)) \
$(__c_flags) $(modkern_cflags) \
$(basename_flags) $(modname_flags)
--
2.18.0
[PATCH v8 2/2] MIPS: Workaround GCC __builtin_unreachable reordering bug
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.
See this potential GCC fix for details:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):
Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.
This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.
That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.
Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:
arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA
mode
Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.
Signed-off-by: Paul Burton
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Cc: James Hogan
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux-m...@linux-mips.org
---
Changes in v8:
- Move to asm/compiler_types.h to suit patch 1.
- Commit message improvements.
- Drop James' SoB since this changed a fair bit since he added it.
Changes in v7:
- Elaborate on affected GCC versions in comment.
Changes in v6: None
Changes in v5:
- Comment & commit message tweaks.
Changes in v4: None
Changes in v3:
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.
Changes in v2:
- Remove generic-y entry.
arch/mips/include/asm/compiler_types.h | 39 ++
include/linux/compiler-gcc.h | 2 ++
2 files changed, 41 insertions(+)
create mode 100644 arch/mips/include/asm/compiler_types.h
diff --git a/arch/mips/include/asm/compiler_types.h
b/arch/mips/include/asm/compiler_types.h
new file mode 100644
index ..cecd5dc48ce2
--- /dev/null
+++ b/arch/mips/include/asm/compiler_types.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_COMPILER_TYPES_H__
+#define __ASM_COMPILER_TYPES_H__
+
+/*
+ * With GCC 4.5 onwards we can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately at least GCC 4.6.3 through 7.3.0 inclusive suffer from a bug
+ * that can lead to instructions from beyond an unreachable statement being
+ * incorrectly reordered into earlier delay slots if the unreachable statement
+ * is the only content of a case in a switch statement. This can lead to
+ * seemingly random behaviour, such as invalid memory accesses from incorrectly
+ * reordered loads or
[PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
We have a need to override the definition of
barrier_before_unreachable() for MIPS, which means we either need to add
architecture-specific code into linux/compiler-gcc.h or we need to allow
the architecture to provide a header that can define the macro before
the generic definition. The latter seems like the better approach.
A straightforward approach to the per-arch header is to make use of
asm-generic to provide a default empty header & adjust architectures
which don't need anything specific to make use of that by adding the
header to generic-y. Unfortunately this doesn't work so well due to
commit a95b37e20db9 ("kbuild: get out of
") which moved the inclusion of linux/compiler.h to
cflags using the -include compiler flag.
Because the -include flag is present for all C files we compile, we need
the architecture-provided header to be present before any C files are
compiled. If any C files can be compiled prior to the asm-generic header
wrappers being generated then we hit a build failure due to missing
header. Such cases do exist - one pointed out by the kbuild test robot
is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
of the archprepare target [1].
This leaves us with a few options:
1) Use generic-y & fix any build failures we find by enforcing
ordering such that the asm-generic target occurs before any C
compilation, such that linux/compiler_types.h can always include
the generated asm-generic wrapper which in turn includes the empty
asm-generic header. This would rely on us finding all the
problematic cases - I don't know for sure that the ia64 issue is
the only one.
2) Add an actual empty header to each architecture, so that we don't
need the generated asm-generic wrapper. This seems messy.
3) Give up & add #ifdef CONFIG_MIPS or similar to
linux/compiler_types.h. This seems messy too.
4) Include the arch header only when it's actually needed, removing
the need for the asm-generic wrapper for all other architectures.
This patch allows us to use approach 4, by including an
asm/compiler_types.h header using the -include flag in the same way we
do for linux/compiler_types.h, but only if the header actually exists.
[1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
Signed-off-by: Paul Burton
Cc: Arnd Bergmann
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Ralf Baechle
Cc: linux-a...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Any thoughts anyone?
This isn't the prettiest it could possibly be but it's a small change &
clearly shouldn't break anything, which are good qualities for a patch
fixing build failures that we'd ideally backport as far as 4.16.
Changes in v8:
- New patch.
scripts/Makefile.lib | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1bb594fcfe12..4e7b41ef029b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -151,8 +151,11 @@ __a_flags = $(call flags,_a_flags)
__cpp_flags = $(call flags,_cpp_flags)
endif
+c_includes = $(wildcard
$(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
+c_includes += $(srctree)/include/linux/compiler_types.h
+
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
--include $(srctree)/include/linux/compiler_types.h \
+$(addprefix -include ,$(c_includes)) \
$(__c_flags) $(modkern_cflags) \
$(basename_flags) $(modname_flags)
--
2.18.0
[PATCH v8 2/2] MIPS: Workaround GCC __builtin_unreachable reordering bug
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.
See this potential GCC fix for details:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):
Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.
This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.
That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.
Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:
arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA
mode
Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.
Signed-off-by: Paul Burton
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Cc: James Hogan
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: linux-m...@linux-mips.org
---
Changes in v8:
- Move to asm/compiler_types.h to suit patch 1.
- Commit message improvements.
- Drop James' SoB since this changed a fair bit since he added it.
Changes in v7:
- Elaborate on affected GCC versions in comment.
Changes in v6: None
Changes in v5:
- Comment & commit message tweaks.
Changes in v4: None
Changes in v3:
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.
Changes in v2:
- Remove generic-y entry.
arch/mips/include/asm/compiler_types.h | 39 ++
include/linux/compiler-gcc.h | 2 ++
2 files changed, 41 insertions(+)
create mode 100644 arch/mips/include/asm/compiler_types.h
diff --git a/arch/mips/include/asm/compiler_types.h
b/arch/mips/include/asm/compiler_types.h
new file mode 100644
index ..cecd5dc48ce2
--- /dev/null
+++ b/arch/mips/include/asm/compiler_types.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_COMPILER_TYPES_H__
+#define __ASM_COMPILER_TYPES_H__
+
+/*
+ * With GCC 4.5 onwards we can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately at least GCC 4.6.3 through 7.3.0 inclusive suffer from a bug
+ * that can lead to instructions from beyond an unreachable statement being
+ * incorrectly reordered into earlier delay slots if the unreachable statement
+ * is the only content of a case in a switch statement. This can lead to
+ * seemingly random behaviour, such as invalid memory accesses from incorrectly
+ * reordered loads or
[PATCH v8 0/2] MIPS: Override barrier_before_unreachable() to fix microMIPS
This series overrides barrier_before_unreachable() for MIPS to add a .insn assembler directive. Due to the subsequent __builtin_unreachable(), the assembler can't tell that a label on the empty inline asm is code rather than data, so any microMIPS branches targeting it (which sadly can't be removed) raise errors due to the mismatching ISA mode, Adding the .insn in patch 2 tells the assembler that it should be treated as code. Applies cleanly atop v4.18. Changes in v8 (Paul): - Try something different... including a header that might be an asm-generic wrapper in linux/compiler_types.h creates build ordering problems for any C file which can be built before the asm-generic target. Patch 1 changes tact to avoid asm-generic & the ordering problem. - Commit message improvements in patch 2. Changes in v7 (Paul): - Elaborate on affected GCC versions in patch 4. Changes in v6 (Paul): - Fix patch 2 to find the generated headers in $(objtree). - Remove CC's for defunct MIPS email addresses (Matthew & Robert). - CC linux...@lists.infradead.org. Changes in v5 (Paul): - Rebase atop v4.18-rc8. - Comment & commit message tweaks. - Add SPDX-License-Identifier to asm-generic/compiler.h. Changes in v4 (James): - Fix asm-generic/compiler.h include from check, compiler_types.h is included on the command line so linux/compiler.h may not be included (kbuild test robot). - New patch 2 to fix um (kbuild test robot). Changes in v3 (James): - New patch 1. - Rebase after 4.17 arch removal and update commit messages. - Use asm/compiler.h instead of compiler-gcc.h (Arnd). - Drop stable tag for now. Changes in v2 (Paul): - Add generic-y entries to arch Kbuild files. Oops! Previous versions: v1: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00399.html v2: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00401.html v3: https://lkml.org/lkml/2018/4/17/228 v4: https://www.linux-mips.org/archives/linux-mips/2018-05/msg00069.html v5: https://www.spinics.net/lists/mips/msg74408.html v6: https://www.spinics.net/lists/mips/msg74425.html v7: https://www.spinics.net/lists/linux-arch/msg47934.html Older #ifdef-based attempt: https://marc.info/?l=linux-mips=14921408274=2 Paul Burton (2): kbuild: Allow asm-specific compiler_types.h MIPS: Workaround GCC __builtin_unreachable reordering bug arch/mips/include/asm/compiler_types.h | 39 ++ include/linux/compiler-gcc.h | 2 ++ scripts/Makefile.lib | 5 +++- 3 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 arch/mips/include/asm/compiler_types.h -- 2.18.0
[PATCH v8 0/2] MIPS: Override barrier_before_unreachable() to fix microMIPS
This series overrides barrier_before_unreachable() for MIPS to add a .insn assembler directive. Due to the subsequent __builtin_unreachable(), the assembler can't tell that a label on the empty inline asm is code rather than data, so any microMIPS branches targeting it (which sadly can't be removed) raise errors due to the mismatching ISA mode, Adding the .insn in patch 2 tells the assembler that it should be treated as code. Applies cleanly atop v4.18. Changes in v8 (Paul): - Try something different... including a header that might be an asm-generic wrapper in linux/compiler_types.h creates build ordering problems for any C file which can be built before the asm-generic target. Patch 1 changes tact to avoid asm-generic & the ordering problem. - Commit message improvements in patch 2. Changes in v7 (Paul): - Elaborate on affected GCC versions in patch 4. Changes in v6 (Paul): - Fix patch 2 to find the generated headers in $(objtree). - Remove CC's for defunct MIPS email addresses (Matthew & Robert). - CC linux...@lists.infradead.org. Changes in v5 (Paul): - Rebase atop v4.18-rc8. - Comment & commit message tweaks. - Add SPDX-License-Identifier to asm-generic/compiler.h. Changes in v4 (James): - Fix asm-generic/compiler.h include from check, compiler_types.h is included on the command line so linux/compiler.h may not be included (kbuild test robot). - New patch 2 to fix um (kbuild test robot). Changes in v3 (James): - New patch 1. - Rebase after 4.17 arch removal and update commit messages. - Use asm/compiler.h instead of compiler-gcc.h (Arnd). - Drop stable tag for now. Changes in v2 (Paul): - Add generic-y entries to arch Kbuild files. Oops! Previous versions: v1: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00399.html v2: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00401.html v3: https://lkml.org/lkml/2018/4/17/228 v4: https://www.linux-mips.org/archives/linux-mips/2018-05/msg00069.html v5: https://www.spinics.net/lists/mips/msg74408.html v6: https://www.spinics.net/lists/mips/msg74425.html v7: https://www.spinics.net/lists/linux-arch/msg47934.html Older #ifdef-based attempt: https://marc.info/?l=linux-mips=14921408274=2 Paul Burton (2): kbuild: Allow asm-specific compiler_types.h MIPS: Workaround GCC __builtin_unreachable reordering bug arch/mips/include/asm/compiler_types.h | 39 ++ include/linux/compiler-gcc.h | 2 ++ scripts/Makefile.lib | 5 +++- 3 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 arch/mips/include/asm/compiler_types.h -- 2.18.0
Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS
Hello Stephen,
I will test these changes and get back.
On 8/18/2018 7:42 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-08-10 18:53:54)
[v4]
* Add recalc_clk_ops to calculate the clock frequency reading the current
perf state, also add CLK_GET_RATE_NOCACHE flag.
* Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
* cleanup return from function 'com_cc_register_rcg_dfs'.
I want to squash this in. I have only compile tested it. Let me know
what you think.
8<---
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index e6300e05d5df..e5eca8a1abe4 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -163,6 +163,15 @@ extern const struct clk_ops clk_pixel_ops;
extern const struct clk_ops clk_gfx3d_ops;
extern const struct clk_ops clk_rcg2_shared_ops;
+struct clk_rcg_dfs_data {
+ struct clk_rcg2 *rcg;
+ struct clk_init_data *init;
+};
+
+#define DEFINE_RCG_DFS(r) \
+ { .rcg = ##_src, .init = ##_init }
+
extern int qcom_cc_register_rcg_dfs(struct regmap *regmap,
-struct clk_rcg2 **rcgs, int num_clks);
+ const struct clk_rcg_dfs_data *rcgs,
+ size_t len);
#endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 55a5b58cbb15..bbe2a1916296 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1051,48 +1051,24 @@ static unsigned long
clk_rcg2_dfs_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
{
struct clk_rcg2 *rcg = to_clk_rcg2(hw);
- u32 cfg, hid_div, m = 0, n = 0, mode = 0, mask, level;
- int num_parents, i;
- unsigned long prate;
-
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_CMD_DFSR_OFFSET, );
- level = (GENMASK(4, 1) & cfg) >> 1;
-
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_PERF_DFSR(level), );
- if (rcg->mnd_width) {
- mask = BIT(rcg->mnd_width) - 1;
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_PERF_M_DFSR(level), );
- m &= mask;
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_PERF_N_DFSR(level), );
- n = ~n;
- n &= mask;
- n += m;
- mode = cfg & CFG_MODE_MASK;
- mode >>= CFG_MODE_SHIFT;
- }
+ int ret;
+ u32 level;
- mask = BIT(rcg->hid_width) - 1;
- hid_div = cfg >> CFG_SRC_DIV_SHIFT;
- hid_div &= mask;
- cfg &= CFG_SRC_SEL_MASK;
- cfg >>= CFG_SRC_SEL_SHIFT;
+ regmap_read(rcg->clkr.regmap,
+ rcg->cmd_rcgr + SE_CMD_DFSR_OFFSET, );
+ level &= GENMASK(4, 1);
+ level >>= 1;
- num_parents = clk_hw_get_num_parents(hw);
- for (i = 0; i < num_parents; i++) {
- if (cfg == rcg->parent_map[i].cfg) {
- prate = clk_hw_get_rate(
- clk_hw_get_parent_by_index(>clkr.hw, i));
- if (parent_rate != prate)
- parent_rate = prate;
+ if (!rcg->freq_tbl) {
+ ret = clk_rcg2_dfs_populate_freq_table(rcg);
+ if (ret) {
+ pr_err("Failed to update DFS tables for %s\n",
+ clk_hw_get_name(hw));
+ return ret;
}
}
-
- return calc_rate(parent_rate, m, n, mode, hid_div);
+ return rcg->freq_tbl[level].freq;
}
static const struct clk_ops clk_rcg2_dfs_ops = {
@@ -1102,9 +1078,11 @@ static const struct clk_ops clk_rcg2_dfs_ops = {
.recalc_rate = clk_rcg2_dfs_recalc_rate,
};
-static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)
+static int clk_rcg2_enable_dfs(const struct clk_rcg_dfs_data *data,
+ struct regmap *regmap)
{
- struct clk_init_data *init;
+ struct clk_rcg2 *rcg = data->rcg;
+ struct clk_init_data *init = data->init;
u32 val;
int ret;
@@ -1116,18 +1094,13 @@ static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)
if (!(val & SE_CMD_DFS_EN))
return 0;
- init = kzalloc(sizeof(*init), GFP_KERNEL);
- if (!init)
- return -ENOMEM;
-
- init->name = rcg->clkr.hw.init->name;
- init->flags = rcg->clkr.hw.init->flags;
- init->parent_names = rcg->clkr.hw.init->parent_names;
- init->num_parents = rcg->clkr.hw.init->num_parents;
- init->flags = CLK_GET_RATE_NOCACHE;
+ /*
+* Rate changes with consumer writing a register in
+* their own I/O region
+*/
+ init->flags |= CLK_GET_RATE_NOCACHE;
init->ops = _rcg2_dfs_ops;
- rcg->clkr.hw.init = init;
Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS
Hello Stephen,
I will test these changes and get back.
On 8/18/2018 7:42 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-08-10 18:53:54)
[v4]
* Add recalc_clk_ops to calculate the clock frequency reading the current
perf state, also add CLK_GET_RATE_NOCACHE flag.
* Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
* cleanup return from function 'com_cc_register_rcg_dfs'.
I want to squash this in. I have only compile tested it. Let me know
what you think.
8<---
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index e6300e05d5df..e5eca8a1abe4 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -163,6 +163,15 @@ extern const struct clk_ops clk_pixel_ops;
extern const struct clk_ops clk_gfx3d_ops;
extern const struct clk_ops clk_rcg2_shared_ops;
+struct clk_rcg_dfs_data {
+ struct clk_rcg2 *rcg;
+ struct clk_init_data *init;
+};
+
+#define DEFINE_RCG_DFS(r) \
+ { .rcg = ##_src, .init = ##_init }
+
extern int qcom_cc_register_rcg_dfs(struct regmap *regmap,
-struct clk_rcg2 **rcgs, int num_clks);
+ const struct clk_rcg_dfs_data *rcgs,
+ size_t len);
#endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 55a5b58cbb15..bbe2a1916296 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1051,48 +1051,24 @@ static unsigned long
clk_rcg2_dfs_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
{
struct clk_rcg2 *rcg = to_clk_rcg2(hw);
- u32 cfg, hid_div, m = 0, n = 0, mode = 0, mask, level;
- int num_parents, i;
- unsigned long prate;
-
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_CMD_DFSR_OFFSET, );
- level = (GENMASK(4, 1) & cfg) >> 1;
-
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_PERF_DFSR(level), );
- if (rcg->mnd_width) {
- mask = BIT(rcg->mnd_width) - 1;
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_PERF_M_DFSR(level), );
- m &= mask;
- regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
- SE_PERF_N_DFSR(level), );
- n = ~n;
- n &= mask;
- n += m;
- mode = cfg & CFG_MODE_MASK;
- mode >>= CFG_MODE_SHIFT;
- }
+ int ret;
+ u32 level;
- mask = BIT(rcg->hid_width) - 1;
- hid_div = cfg >> CFG_SRC_DIV_SHIFT;
- hid_div &= mask;
- cfg &= CFG_SRC_SEL_MASK;
- cfg >>= CFG_SRC_SEL_SHIFT;
+ regmap_read(rcg->clkr.regmap,
+ rcg->cmd_rcgr + SE_CMD_DFSR_OFFSET, );
+ level &= GENMASK(4, 1);
+ level >>= 1;
- num_parents = clk_hw_get_num_parents(hw);
- for (i = 0; i < num_parents; i++) {
- if (cfg == rcg->parent_map[i].cfg) {
- prate = clk_hw_get_rate(
- clk_hw_get_parent_by_index(>clkr.hw, i));
- if (parent_rate != prate)
- parent_rate = prate;
+ if (!rcg->freq_tbl) {
+ ret = clk_rcg2_dfs_populate_freq_table(rcg);
+ if (ret) {
+ pr_err("Failed to update DFS tables for %s\n",
+ clk_hw_get_name(hw));
+ return ret;
}
}
-
- return calc_rate(parent_rate, m, n, mode, hid_div);
+ return rcg->freq_tbl[level].freq;
}
static const struct clk_ops clk_rcg2_dfs_ops = {
@@ -1102,9 +1078,11 @@ static const struct clk_ops clk_rcg2_dfs_ops = {
.recalc_rate = clk_rcg2_dfs_recalc_rate,
};
-static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)
+static int clk_rcg2_enable_dfs(const struct clk_rcg_dfs_data *data,
+ struct regmap *regmap)
{
- struct clk_init_data *init;
+ struct clk_rcg2 *rcg = data->rcg;
+ struct clk_init_data *init = data->init;
u32 val;
int ret;
@@ -1116,18 +1094,13 @@ static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)
if (!(val & SE_CMD_DFS_EN))
return 0;
- init = kzalloc(sizeof(*init), GFP_KERNEL);
- if (!init)
- return -ENOMEM;
-
- init->name = rcg->clkr.hw.init->name;
- init->flags = rcg->clkr.hw.init->flags;
- init->parent_names = rcg->clkr.hw.init->parent_names;
- init->num_parents = rcg->clkr.hw.init->num_parents;
- init->flags = CLK_GET_RATE_NOCACHE;
+ /*
+* Rate changes with consumer writing a register in
+* their own I/O region
+*/
+ init->flags |= CLK_GET_RATE_NOCACHE;
init->ops = _rcg2_dfs_ops;
- rcg->clkr.hw.init = init;
Re: [GIT PULL] Staging/IIO driver patches for 4.19-rc1
On Sat, Aug 18, 2018 at 8:57 AM Greg KH wrote: > > Note, you will have a merge problem with a device tree IIO file and the > MAINTAINERS file, both resolutions are easy, just take all changed. Heh, no. In neither case should I take all changes: the IIO was "delete both sides"), and in the MAINTAINERS file, which was delete one side, add another, somebody can't even sort stuff alphabetically. > There will be a skein file merge issue as well, but that file got > deleted so just drop that. Yes indeed. Linus
Re: [GIT PULL] Staging/IIO driver patches for 4.19-rc1
On Sat, Aug 18, 2018 at 8:57 AM Greg KH wrote: > > Note, you will have a merge problem with a device tree IIO file and the > MAINTAINERS file, both resolutions are easy, just take all changed. Heh, no. In neither case should I take all changes: the IIO was "delete both sides"), and in the MAINTAINERS file, which was delete one side, add another, somebody can't even sort stuff alphabetically. > There will be a skein file merge issue as well, but that file got > deleted so just drop that. Yes indeed. Linus
Re: [PATCH v3 7/9] iio: tsl2772: add support for avago,apds9930
On Fri, 3 Aug 2018 22:53:36 +0100
Jonathan Cameron wrote:
> On Thu, 2 Aug 2018 20:18:58 -0400
> Brian Masney wrote:
>
> > The Avago APDS9930 has the same register set as the TAOS/AMS TSL2772 so
> > this patch adds the correct bindings and the appropriate LUX table
> > values derived from the values in the datasheet. Driver was tested on a
> > LG Nexus 5 (hammerhead) phone.
> >
> > avago,apds9930 datasheet:
> > https://www.mouser.com/datasheet/2/678/avago_AV02-3190EN_DS_APDS-9930_2014-03-25[1]-1217273.pdf
> >
> > tsl2772 datasheet:
> > https://ams.com/eng/content/download/291503/1066377/file/TSL2772_DS000181_2-00.pdf
> >
> > Signed-off-by: Brian Masney
> Glad you noticed they were the same. will apply once precursors are in.
>
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/light/tsl2772.c | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index 4a11bf77a4d0..83cece921843 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -124,7 +124,8 @@ enum {
> > tsl2672,
> > tmd2672,
> > tsl2772,
> > - tmd2772
> > + tmd2772,
> > + apds9930,
> > };
> >
> > enum {
> > @@ -213,6 +214,12 @@ static const struct tsl2772_lux
> > tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 0, 0 },
> > };
> >
> > +static const struct tsl2772_lux
> > apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > + { 52000, 96824 },
> > + { 38792, 67132 },
> > + { 0, 0 },
> > +};
> > +
> > static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > [tsl2571] = tsl2x71_lux_table,
> > [tsl2671] = tsl2x71_lux_table,
> > @@ -224,6 +231,7 @@ static const struct tsl2772_lux
> > *tsl2772_default_lux_table_group[] = {
> > [tmd2672] = tmd2x72_lux_table,
> > [tsl2772] = tsl2x72_lux_table,
> > [tmd2772] = tmd2x72_lux_table,
> > + [apds9930] = apds9930_lux_table,
> > };
> >
> > static const struct tsl2772_settings tsl2772_default_settings = {
> > @@ -274,6 +282,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > + [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > };
> >
> > static int tsl2772_int_calibscale_avail[] = { 1, 8, 16, 120 };
> > @@ -299,7 +308,8 @@ static const u8 device_channel_config[] = {
> > [tsl2672] = PRX2,
> > [tmd2672] = PRX2,
> > [tsl2772] = ALSPRX2,
> > - [tmd2772] = ALSPRX2
> > + [tmd2772] = ALSPRX2,
> > + [apds9930] = ALSPRX2,
> > };
> >
> > static int tsl2772_read_status(struct tsl2772_chip *chip)
> > @@ -513,6 +523,7 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
> > case tmd2672:
> > case tsl2772:
> > case tmd2772:
> > + case apds9930:
> > if (!(ret & TSL2772_STA_PRX_VALID)) {
> > ret = -EINVAL;
> > goto prox_poll_err;
> > @@ -1393,6 +1404,7 @@ static int tsl2772_device_id_verif(int id, int target)
> > case tmd2672:
> > case tsl2772:
> > case tmd2772:
> > + case apds9930:
> > return (id & 0xf0) == SWORDFISH_ID;
> > }
> >
> > @@ -1932,6 +1944,7 @@ static const struct i2c_device_id tsl2772_idtable[] =
> > {
> > { "tmd2672", tmd2672 },
> > { "tsl2772", tsl2772 },
> > { "tmd2772", tmd2772 },
> > + { "apds9930", apds9930},
> > {}
> > };
> >
> > @@ -1948,6 +1961,7 @@ static const struct of_device_id tsl2772_of_match[] =
> > {
> > { .compatible = "amstaos,tmd2672" },
> > { .compatible = "amstaos,tsl2772" },
> > { .compatible = "amstaos,tmd2772" },
> > + { .compatible = "avago,apds9930" },
> > {}
> > };
> > MODULE_DEVICE_TABLE(of, tsl2772_of_match);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/9] iio: tsl2772: add support for avago,apds9930
On Fri, 3 Aug 2018 22:53:36 +0100
Jonathan Cameron wrote:
> On Thu, 2 Aug 2018 20:18:58 -0400
> Brian Masney wrote:
>
> > The Avago APDS9930 has the same register set as the TAOS/AMS TSL2772 so
> > this patch adds the correct bindings and the appropriate LUX table
> > values derived from the values in the datasheet. Driver was tested on a
> > LG Nexus 5 (hammerhead) phone.
> >
> > avago,apds9930 datasheet:
> > https://www.mouser.com/datasheet/2/678/avago_AV02-3190EN_DS_APDS-9930_2014-03-25[1]-1217273.pdf
> >
> > tsl2772 datasheet:
> > https://ams.com/eng/content/download/291503/1066377/file/TSL2772_DS000181_2-00.pdf
> >
> > Signed-off-by: Brian Masney
> Glad you noticed they were the same. will apply once precursors are in.
>
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/light/tsl2772.c | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index 4a11bf77a4d0..83cece921843 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -124,7 +124,8 @@ enum {
> > tsl2672,
> > tmd2672,
> > tsl2772,
> > - tmd2772
> > + tmd2772,
> > + apds9930,
> > };
> >
> > enum {
> > @@ -213,6 +214,12 @@ static const struct tsl2772_lux
> > tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 0, 0 },
> > };
> >
> > +static const struct tsl2772_lux
> > apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > + { 52000, 96824 },
> > + { 38792, 67132 },
> > + { 0, 0 },
> > +};
> > +
> > static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > [tsl2571] = tsl2x71_lux_table,
> > [tsl2671] = tsl2x71_lux_table,
> > @@ -224,6 +231,7 @@ static const struct tsl2772_lux
> > *tsl2772_default_lux_table_group[] = {
> > [tmd2672] = tmd2x72_lux_table,
> > [tsl2772] = tsl2x72_lux_table,
> > [tmd2772] = tmd2x72_lux_table,
> > + [apds9930] = apds9930_lux_table,
> > };
> >
> > static const struct tsl2772_settings tsl2772_default_settings = {
> > @@ -274,6 +282,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > + [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > };
> >
> > static int tsl2772_int_calibscale_avail[] = { 1, 8, 16, 120 };
> > @@ -299,7 +308,8 @@ static const u8 device_channel_config[] = {
> > [tsl2672] = PRX2,
> > [tmd2672] = PRX2,
> > [tsl2772] = ALSPRX2,
> > - [tmd2772] = ALSPRX2
> > + [tmd2772] = ALSPRX2,
> > + [apds9930] = ALSPRX2,
> > };
> >
> > static int tsl2772_read_status(struct tsl2772_chip *chip)
> > @@ -513,6 +523,7 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
> > case tmd2672:
> > case tsl2772:
> > case tmd2772:
> > + case apds9930:
> > if (!(ret & TSL2772_STA_PRX_VALID)) {
> > ret = -EINVAL;
> > goto prox_poll_err;
> > @@ -1393,6 +1404,7 @@ static int tsl2772_device_id_verif(int id, int target)
> > case tmd2672:
> > case tsl2772:
> > case tmd2772:
> > + case apds9930:
> > return (id & 0xf0) == SWORDFISH_ID;
> > }
> >
> > @@ -1932,6 +1944,7 @@ static const struct i2c_device_id tsl2772_idtable[] =
> > {
> > { "tmd2672", tmd2672 },
> > { "tsl2772", tsl2772 },
> > { "tmd2772", tmd2772 },
> > + { "apds9930", apds9930},
> > {}
> > };
> >
> > @@ -1948,6 +1961,7 @@ static const struct of_device_id tsl2772_of_match[] =
> > {
> > { .compatible = "amstaos,tmd2672" },
> > { .compatible = "amstaos,tsl2772" },
> > { .compatible = "amstaos,tmd2772" },
> > + { .compatible = "avago,apds9930" },
> > {}
> > };
> > MODULE_DEVICE_TABLE(of, tsl2772_of_match);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 9/9] ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for ALS / proximity
On Thu, 2 Aug 2018 20:19:00 -0400
Brian Masney wrote:
> This patch adds device tree bindings for the tsl2772 ALS / proximity
> sensor for the LG Nexus 5 (hammerhead) phone.
>
> Signed-off-by: Brian Masney
> Signed-off-by: Jonathan Marek
Acked-by: Jonathan Cameron
The precursors are working their way through the iio tree, but
it will be the next merge window before they go upstream.
Thanks,
Jonathan
> ---
> .../qcom-msm8974-lge-nexus5-hammerhead.dts| 27 +++
> arch/arm/boot/dts/qcom-msm8974.dtsi | 11
> 2 files changed, 38 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> index 928affae1885..ed8f064d0895 100644
> --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> @@ -242,6 +242,15 @@
> };
> };
>
> + i2c3_pins: i2c3 {
> + mux {
> + pins = "gpio10", "gpio11";
> + function = "blsp_i2c3";
> + drive-strength = <2>;
> + bias-disable;
> + };
> + };
> +
> i2c12_pins: i2c12 {
> mux {
> pins = "gpio87", "gpio88";
> @@ -333,6 +342,24 @@
> };
> };
> };
> +
> + i2c@f9925000 {
> + status = "ok";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + clock-frequency = <10>;
> + qcom,src-freq = <5000>;
> +
> + avago_apds993@39 {
> + compatible = "avago,apds9930";
> + reg = <0x39>;
> + interrupts-extended = < 61
> IRQ_TYPE_EDGE_FALLING>;
> + vdd-supply = <_l17>;
> + vddio-supply = <_lvs1>;
> + led-max-microamp = <10>;
> + amstaos,proximity-diodes = <0>;
> + };
> + };
> };
>
> _bus {
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index cebb6ae9143a..6dcf2bee66fb 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -713,6 +713,17 @@
> #size-cells = <0>;
> };
>
> + blsp_i2c3: i2c@f9925000 {
> + status = "disabled";
> + compatible = "qcom,i2c-qup-v2.1.1";
> + reg = <0xf9925000 0x1000>;
> + interrupts = <0 97 IRQ_TYPE_NONE>;
> + clocks = < GCC_BLSP1_QUP3_I2C_APPS_CLK>, <
> GCC_BLSP1_AHB_CLK>;
> + clock-names = "core", "iface";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> blsp_i2c8: i2c@f9964000 {
> status = "disabled";
> compatible = "qcom,i2c-qup-v2.1.1";
Re: [PATCH v3 9/9] ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for ALS / proximity
On Thu, 2 Aug 2018 20:19:00 -0400
Brian Masney wrote:
> This patch adds device tree bindings for the tsl2772 ALS / proximity
> sensor for the LG Nexus 5 (hammerhead) phone.
>
> Signed-off-by: Brian Masney
> Signed-off-by: Jonathan Marek
Acked-by: Jonathan Cameron
The precursors are working their way through the iio tree, but
it will be the next merge window before they go upstream.
Thanks,
Jonathan
> ---
> .../qcom-msm8974-lge-nexus5-hammerhead.dts| 27 +++
> arch/arm/boot/dts/qcom-msm8974.dtsi | 11
> 2 files changed, 38 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> index 928affae1885..ed8f064d0895 100644
> --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> @@ -242,6 +242,15 @@
> };
> };
>
> + i2c3_pins: i2c3 {
> + mux {
> + pins = "gpio10", "gpio11";
> + function = "blsp_i2c3";
> + drive-strength = <2>;
> + bias-disable;
> + };
> + };
> +
> i2c12_pins: i2c12 {
> mux {
> pins = "gpio87", "gpio88";
> @@ -333,6 +342,24 @@
> };
> };
> };
> +
> + i2c@f9925000 {
> + status = "ok";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + clock-frequency = <10>;
> + qcom,src-freq = <5000>;
> +
> + avago_apds993@39 {
> + compatible = "avago,apds9930";
> + reg = <0x39>;
> + interrupts-extended = < 61
> IRQ_TYPE_EDGE_FALLING>;
> + vdd-supply = <_l17>;
> + vddio-supply = <_lvs1>;
> + led-max-microamp = <10>;
> + amstaos,proximity-diodes = <0>;
> + };
> + };
> };
>
> _bus {
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index cebb6ae9143a..6dcf2bee66fb 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -713,6 +713,17 @@
> #size-cells = <0>;
> };
>
> + blsp_i2c3: i2c@f9925000 {
> + status = "disabled";
> + compatible = "qcom,i2c-qup-v2.1.1";
> + reg = <0xf9925000 0x1000>;
> + interrupts = <0 97 IRQ_TYPE_NONE>;
> + clocks = < GCC_BLSP1_QUP3_I2C_APPS_CLK>, <
> GCC_BLSP1_AHB_CLK>;
> + clock-names = "core", "iface";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> blsp_i2c8: i2c@f9964000 {
> status = "disabled";
> compatible = "qcom,i2c-qup-v2.1.1";
Re: [PATCH v3 8/9] dt-bindings: iio: tsl2772: add binding for avago,apds9930
On Tue, 7 Aug 2018 11:21:01 -0600 Rob Herring wrote: > On Thu, Aug 02, 2018 at 08:18:59PM -0400, Brian Masney wrote: > > This patch adds avago,apds9930 to the tsl2772 bindings. > > > > Signed-off-by: Brian Masney > > --- > > Documentation/devicetree/bindings/iio/light/tsl2772.txt | 1 + > > 1 file changed, 1 insertion(+) > > Reviewed-by: Rob Herring Applied. Thanks
Re: [PATCH v3 8/9] dt-bindings: iio: tsl2772: add binding for avago,apds9930
On Tue, 7 Aug 2018 11:21:01 -0600 Rob Herring wrote: > On Thu, Aug 02, 2018 at 08:18:59PM -0400, Brian Masney wrote: > > This patch adds avago,apds9930 to the tsl2772 bindings. > > > > Signed-off-by: Brian Masney > > --- > > Documentation/devicetree/bindings/iio/light/tsl2772.txt | 1 + > > 1 file changed, 1 insertion(+) > > Reviewed-by: Rob Herring Applied. Thanks
Re: [PATCH v3 3/9] iio: tsl2772: add support for reading proximity led settings from device tree
On Thu, 2 Aug 2018 20:18:54 -0400
Brian Masney wrote:
> This patch adds support for optionally reading the proximity led diode
> and current settings from device tree. This was tested using a LG
> Nexus 5 (hammerhead) which requires a different diode than the driver
> default for the IR LED.
>
> Signed-off-by: Brian Masney
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with them.
thanks,
Jonathan
> ---
> drivers/iio/light/tsl2772.c | 81 +
> 1 file changed, 81 insertions(+)
>
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index df5b2a0da96c..ae00edf0d87e 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -107,6 +107,8 @@
> #define TSL2772_ALS_GAIN_TRIM_MIN250
> #define TSL2772_ALS_GAIN_TRIM_MAX4000
>
> +#define TSL2772_MAX_PROX_LEDS2
> +
> /* Device family members */
> enum {
> tsl2571,
> @@ -141,6 +143,14 @@ struct tsl2772_chip_info {
> const struct iio_info *info;
> };
>
> +static const int tsl2772_led_currents[][2] = {
> + { 10, TSL2772_100_mA },
> + { 5, TSL2772_50_mA },
> + { 25000, TSL2772_25_mA },
> + { 13000, TSL2772_13_mA },
> + { 0, 0 }
> +};
> +
> struct tsl2772_chip {
> kernel_ulong_t id;
> struct mutex prox_mutex;
> @@ -515,6 +525,75 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
> return ret;
> }
>
> +static int tsl2772_read_prox_led_current(struct tsl2772_chip *chip)
> +{
> + struct device_node *of_node = chip->client->dev.of_node;
> + int ret, tmp, i;
> +
> + ret = of_property_read_u32(of_node, "led-max-microamp", );
> + if (ret < 0)
> + return ret;
> +
> + for (i = 0; tsl2772_led_currents[i][0] != 0; i++) {
> + if (tmp == tsl2772_led_currents[i][0]) {
> + chip->settings.prox_power = tsl2772_led_currents[i][1];
> + return 0;
> + }
> + }
> +
> + dev_err(>client->dev, "Invalid value %d for led-max-microamp\n",
> + tmp);
> +
> + return -EINVAL;
> +
> +}
> +
> +static int tsl2772_read_prox_diodes(struct tsl2772_chip *chip)
> +{
> + struct device_node *of_node = chip->client->dev.of_node;
> + int i, ret, num_leds, prox_diode_mask;
> + u32 leds[TSL2772_MAX_PROX_LEDS];
> +
> + ret = of_property_count_u32_elems(of_node, "amstaos,proximity-diodes");
> + if (ret < 0)
> + return ret;
> +
> + num_leds = ret;
> + if (num_leds > TSL2772_MAX_PROX_LEDS)
> + num_leds = TSL2772_MAX_PROX_LEDS;
> +
> + ret = of_property_read_u32_array(of_node, "amstaos,proximity-diodes",
> + leds, num_leds);
> + if (ret < 0) {
> + dev_err(>client->dev,
> + "Invalid value for amstaos,proximity-diodes: %d.\n",
> + ret);
> + return ret;
> + }
> +
> + prox_diode_mask = 0;
> + for (i = 0; i < num_leds; i++) {
> + if (leds[i] == 0)
> + prox_diode_mask |= TSL2772_DIODE0;
> + else if (leds[i] == 1)
> + prox_diode_mask |= TSL2772_DIODE1;
> + else {
> + dev_err(>client->dev,
> + "Invalid value %d in
> amstaos,proximity-diodes.\n",
> + leds[i]);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void tsl2772_parse_dt(struct tsl2772_chip *chip)
> +{
> + tsl2772_read_prox_led_current(chip);
> + tsl2772_read_prox_diodes(chip);
> +}
> +
> /**
> * tsl2772_defaults() - Populates the device nominal operating parameters
> * with those provided by a 'platform' data struct or
> @@ -541,6 +620,8 @@ static void tsl2772_defaults(struct tsl2772_chip *chip)
> memcpy(chip->tsl2772_device_lux,
> tsl2772_default_lux_table_group[chip->id],
> TSL2772_DEFAULT_TABLE_BYTES);
> +
> + tsl2772_parse_dt(chip);
> }
>
> /**
Re: [PATCH v3 3/9] iio: tsl2772: add support for reading proximity led settings from device tree
On Thu, 2 Aug 2018 20:18:54 -0400
Brian Masney wrote:
> This patch adds support for optionally reading the proximity led diode
> and current settings from device tree. This was tested using a LG
> Nexus 5 (hammerhead) which requires a different diode than the driver
> default for the IR LED.
>
> Signed-off-by: Brian Masney
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with them.
thanks,
Jonathan
> ---
> drivers/iio/light/tsl2772.c | 81 +
> 1 file changed, 81 insertions(+)
>
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index df5b2a0da96c..ae00edf0d87e 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -107,6 +107,8 @@
> #define TSL2772_ALS_GAIN_TRIM_MIN250
> #define TSL2772_ALS_GAIN_TRIM_MAX4000
>
> +#define TSL2772_MAX_PROX_LEDS2
> +
> /* Device family members */
> enum {
> tsl2571,
> @@ -141,6 +143,14 @@ struct tsl2772_chip_info {
> const struct iio_info *info;
> };
>
> +static const int tsl2772_led_currents[][2] = {
> + { 10, TSL2772_100_mA },
> + { 5, TSL2772_50_mA },
> + { 25000, TSL2772_25_mA },
> + { 13000, TSL2772_13_mA },
> + { 0, 0 }
> +};
> +
> struct tsl2772_chip {
> kernel_ulong_t id;
> struct mutex prox_mutex;
> @@ -515,6 +525,75 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
> return ret;
> }
>
> +static int tsl2772_read_prox_led_current(struct tsl2772_chip *chip)
> +{
> + struct device_node *of_node = chip->client->dev.of_node;
> + int ret, tmp, i;
> +
> + ret = of_property_read_u32(of_node, "led-max-microamp", );
> + if (ret < 0)
> + return ret;
> +
> + for (i = 0; tsl2772_led_currents[i][0] != 0; i++) {
> + if (tmp == tsl2772_led_currents[i][0]) {
> + chip->settings.prox_power = tsl2772_led_currents[i][1];
> + return 0;
> + }
> + }
> +
> + dev_err(>client->dev, "Invalid value %d for led-max-microamp\n",
> + tmp);
> +
> + return -EINVAL;
> +
> +}
> +
> +static int tsl2772_read_prox_diodes(struct tsl2772_chip *chip)
> +{
> + struct device_node *of_node = chip->client->dev.of_node;
> + int i, ret, num_leds, prox_diode_mask;
> + u32 leds[TSL2772_MAX_PROX_LEDS];
> +
> + ret = of_property_count_u32_elems(of_node, "amstaos,proximity-diodes");
> + if (ret < 0)
> + return ret;
> +
> + num_leds = ret;
> + if (num_leds > TSL2772_MAX_PROX_LEDS)
> + num_leds = TSL2772_MAX_PROX_LEDS;
> +
> + ret = of_property_read_u32_array(of_node, "amstaos,proximity-diodes",
> + leds, num_leds);
> + if (ret < 0) {
> + dev_err(>client->dev,
> + "Invalid value for amstaos,proximity-diodes: %d.\n",
> + ret);
> + return ret;
> + }
> +
> + prox_diode_mask = 0;
> + for (i = 0; i < num_leds; i++) {
> + if (leds[i] == 0)
> + prox_diode_mask |= TSL2772_DIODE0;
> + else if (leds[i] == 1)
> + prox_diode_mask |= TSL2772_DIODE1;
> + else {
> + dev_err(>client->dev,
> + "Invalid value %d in
> amstaos,proximity-diodes.\n",
> + leds[i]);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void tsl2772_parse_dt(struct tsl2772_chip *chip)
> +{
> + tsl2772_read_prox_led_current(chip);
> + tsl2772_read_prox_diodes(chip);
> +}
> +
> /**
> * tsl2772_defaults() - Populates the device nominal operating parameters
> * with those provided by a 'platform' data struct or
> @@ -541,6 +620,8 @@ static void tsl2772_defaults(struct tsl2772_chip *chip)
> memcpy(chip->tsl2772_device_lux,
> tsl2772_default_lux_table_group[chip->id],
> TSL2772_DEFAULT_TABLE_BYTES);
> +
> + tsl2772_parse_dt(chip);
> }
>
> /**
Re: [PATCH v3 6/9] dt-bindings: iio: tsl2772: add bindings for regulator framework
On Tue, 7 Aug 2018 11:20:28 -0600
Rob Herring wrote:
> On Fri, Aug 03, 2018 at 10:51:23PM +0100, Jonathan Cameron wrote:
> > On Thu, 2 Aug 2018 20:18:57 -0400
> > Brian Masney wrote:
> >
> > > This patch adds device tree bindings to the tsl2772 driver for the
> > > regulator framework.
> > >
> > > Signed-off-by: Brian Masney
> > I suspect Rob will tell you this should really have been in the same
> > patch as the earlier bindings. There is no need for us to wait
> > for the driver support as the binding describes what is there, not
> > what we do with it.
>
> Yep.
>
> >
> > Otherwise it's fine and if nothing else comes up I can merge them ;)
I merged them.
Jonathan
> >
> > Jonathan
> >
> > > ---
> > > Documentation/devicetree/bindings/iio/light/tsl2772.txt | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > b/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > index 6f33169344f2..4e7d98627cbf 100644
> > > --- a/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > +++ b/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > @@ -21,6 +21,8 @@ Optional properties:
> > > are the only valid values.
> > >- led-max-microamp - current for the proximity LED. Must be 10,
> > > 5,
> > > 25000, or 13000.
> > > + - vdd-supply: phandle to the regulator that provides power to the
> > > sensor.
> > > + - vddio-supply: phandle to the regulator that provides power to the
> > > bus.
> > >- interrupts: the sole interrupt generated by the device
> > >
> > >Refer to interrupt-controller/interrupts.txt for generic interrupt
> > > client
> > > @@ -32,6 +34,8 @@ tsl2772@39 {
> > > compatible = "amstaos,tsl2772";
> > > reg = <0x39>;
> > > interrupts-extended = < 61 IRQ_TYPE_EDGE_FALLING>;
> > > + vdd-supply = <_l17>;
> > > + vddio-supply = <_lvs1>;
> > > amstaos,proximity-diodes = <0>;
> > > led-max-microamp = <10>;
> > > };
> >
Re: [PATCH v3 6/9] dt-bindings: iio: tsl2772: add bindings for regulator framework
On Tue, 7 Aug 2018 11:20:28 -0600
Rob Herring wrote:
> On Fri, Aug 03, 2018 at 10:51:23PM +0100, Jonathan Cameron wrote:
> > On Thu, 2 Aug 2018 20:18:57 -0400
> > Brian Masney wrote:
> >
> > > This patch adds device tree bindings to the tsl2772 driver for the
> > > regulator framework.
> > >
> > > Signed-off-by: Brian Masney
> > I suspect Rob will tell you this should really have been in the same
> > patch as the earlier bindings. There is no need for us to wait
> > for the driver support as the binding describes what is there, not
> > what we do with it.
>
> Yep.
>
> >
> > Otherwise it's fine and if nothing else comes up I can merge them ;)
I merged them.
Jonathan
> >
> > Jonathan
> >
> > > ---
> > > Documentation/devicetree/bindings/iio/light/tsl2772.txt | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > b/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > index 6f33169344f2..4e7d98627cbf 100644
> > > --- a/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > +++ b/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > @@ -21,6 +21,8 @@ Optional properties:
> > > are the only valid values.
> > >- led-max-microamp - current for the proximity LED. Must be 10,
> > > 5,
> > > 25000, or 13000.
> > > + - vdd-supply: phandle to the regulator that provides power to the
> > > sensor.
> > > + - vddio-supply: phandle to the regulator that provides power to the
> > > bus.
> > >- interrupts: the sole interrupt generated by the device
> > >
> > >Refer to interrupt-controller/interrupts.txt for generic interrupt
> > > client
> > > @@ -32,6 +34,8 @@ tsl2772@39 {
> > > compatible = "amstaos,tsl2772";
> > > reg = <0x39>;
> > > interrupts-extended = < 61 IRQ_TYPE_EDGE_FALLING>;
> > > + vdd-supply = <_l17>;
> > > + vddio-supply = <_lvs1>;
> > > amstaos,proximity-diodes = <0>;
> > > led-max-microamp = <10>;
> > > };
> >
Re: [PATCH v3 4/9] dt-bindings: iio: tsl2772: add new bindings
On Tue, 7 Aug 2018 10:54:26 -0600 Rob Herring wrote: > On Fri, Aug 03, 2018 at 10:48:38PM +0100, Jonathan Cameron wrote: > > On Thu, 2 Aug 2018 20:18:55 -0400 > > Brian Masney wrote: > > > > > This patch adds the new properties amstaos,proximity-diodes and > > > led-max-microamp to the tsl2772 driver. This patch also removes the > > > driver from the trivial-devices.txt. > > > > > > Signed-off-by: Brian Masney > > > --- > > This and the implementation look fine to me, but I'll leave them for > > now to give Rob time to take a look if he wants to. > > > > Thanks, > > > > Jonathan > > > > > I got a Reviewed-by: Rob Herring on my last series but > > > didn't include it due to the new file tsl2772.txt in this patch. Device > > > tree bindings need to be complete. > > > > > > .../devicetree/bindings/iio/light/tsl2772.txt | 37 +++ > > > .../devicetree/bindings/trivial-devices.txt | 10 - > > > 2 files changed, 37 insertions(+), 10 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/iio/light/tsl2772.txt > > Reviewed-by: Rob Herring Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to ignore it. I'll apply the other dt bits to this as fixups. Jonathan > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/9] dt-bindings: iio: tsl2772: add new bindings
On Tue, 7 Aug 2018 10:54:26 -0600 Rob Herring wrote: > On Fri, Aug 03, 2018 at 10:48:38PM +0100, Jonathan Cameron wrote: > > On Thu, 2 Aug 2018 20:18:55 -0400 > > Brian Masney wrote: > > > > > This patch adds the new properties amstaos,proximity-diodes and > > > led-max-microamp to the tsl2772 driver. This patch also removes the > > > driver from the trivial-devices.txt. > > > > > > Signed-off-by: Brian Masney > > > --- > > This and the implementation look fine to me, but I'll leave them for > > now to give Rob time to take a look if he wants to. > > > > Thanks, > > > > Jonathan > > > > > I got a Reviewed-by: Rob Herring on my last series but > > > didn't include it due to the new file tsl2772.txt in this patch. Device > > > tree bindings need to be complete. > > > > > > .../devicetree/bindings/iio/light/tsl2772.txt | 37 +++ > > > .../devicetree/bindings/trivial-devices.txt | 10 - > > > 2 files changed, 37 insertions(+), 10 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/iio/light/tsl2772.txt > > Reviewed-by: Rob Herring Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to ignore it. I'll apply the other dt bits to this as fixups. Jonathan > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] iio: adc: add support for mcp3911
On Sat, 4 Aug 2018 08:55:06 +0200
Marcus Folkesson wrote:
> Hi Andy and Jonathan,
>
>
> On Fri, Aug 03, 2018 at 11:09:22PM +0100, Jonathan Cameron wrote:
> > On Thu, 2 Aug 2018 22:52:00 +0300
> > Andy Shevchenko wrote:
> >
> > > On Thu, Aug 2, 2018 at 10:15 PM, Marcus Folkesson
> > > wrote:
> > > > MCP3911 is a dual channel Analog Front End (AFE) containing two
> > > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
> > > >
> > > > Signed-off-by: Marcus Folkesson
> > >
> > > > Signed-off-by: Kent Gustavsson
> > >
> > > What is this? Why it's here (presense and location in the message)?
> > To clarify... If Kent wrote the patch and you are simply acting
> > as gatekeeper / upstreamer you should set the mail to be from Kent
> > and put your own Signed-off after his to basically act as a submaintainer
> > certifying you believe his sign off and all that entails.
> >
> > If it is a bit of a joint effort then that's fine but for copyright
> > purposes there should be some indication of the split.
>
> First, thank you Andy for noticing.
>
> I actually intended to use Co-Developed-by (a pretty new tag)
> in combination with Signed-off-by.
> But the tag must have disappeared in some preparation stage..
>
> From Documentation/process/submitting-patches.rst ::
>
> A Co-Developed-by: states that the patch was also created by another
> developer
> along with the original author. This is useful at times when multiple
> people
> work on a single patch. Note, this person also needs to have a
> Signed-off-by:
> line in the patch as well.
>
> I will switch order and add the Co-Developed-by-tag.
> Is this correct?
>
> Co-Developed-by: Kent Gustavsson
> Signed-off-by: Kent Gustavsson
> Signed-off-by: Marcus Folkesson
>
> >
> >
> > >
> > > > + * Copyright (C) 2018 Kent Gustavsson
> > >
> > > > + *
> > >
> > > Redundant.
> > >
> > > > +static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + reg = MCP3911_REG_READ(reg, adc->dev_addr);
> > > > + ret = spi_write_then_read(adc->spi, , 1, val, len);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + be32_to_cpus(val);
> > > > + *val >>= ((4 - len) * 8);
> > > > + dev_dbg(>spi->dev, "reading 0x%x from register 0x%x\n",
> > > > *val,
> > > > + reg>>1);
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32 val, u8 len)
> > > > +{
> > > > + dev_dbg(>spi->dev, "writing 0x%x to register 0x%x\n", val,
> > > > reg);
> > > > +
> > > > + val <<= (3 - len) * 8;
> > > > + cpu_to_be32s();
> > > > + val |= MCP3911_REG_WRITE(reg, adc->dev_addr);
> > > > +
> > > > + return spi_write(adc->spi, , len + 1);
> > > > +}
> > >
> > > Can't you use REGMAP_SPI ?
> > My instinct is not really. The magic device-addr doesn't help.
> > You could work around it but it's not that nice and you'd have
> > to create the regmap mapping on the fly or carry static ones
> > for each value of htat.
> >
> >
> >
> > >
> > > > + of_property_read_u32(of_node, "device-addr", >dev_addr);
> > > > + if (adc->dev_addr > 3) {
> > > > + dev_err(>spi->dev,
> > > > + "invalid device address (%i). Must be
> > > > in range 0-3.\n",
> > > > + adc->dev_addr);
> > > > + return -EINVAL;
> > > > + }
> > > > + dev_dbg(>spi->dev, "use device address %i\n",
> > > > adc->dev_addr);
> > >
> > > Isn't what we called CS (chip select)?
> > Nope. We went around this in an earlier revision. It's an address
> > transmitted
> > in the control byte to allow you to 'share' a chip select line between
> > multiple
> > chips (crazy but true).
> >
> > >
> > > > + if (IS_ERR(adc->vref)) {
> > >
> > > > +
> > >
> > > Redundant.
> > >
> > > > + if (adc->clki)
> > >
> > > Seems to be redundant if clock is optional (it should be NULL and API
> > > is NULL-aware).
> > >
> > > > + clk_disable_unprepare(adc->clki);
> > >
> > > > + if (adc->clki)
> > > > + clk_disable_unprepare(adc->clki);
> > >
> > > Ditto.
> > >
> > > > +#if defined(CONFIG_OF)
> > >
> > > This prevents playing with the device on ACPI enabled platforms.
>
> I will remove the defined(CONFIG_OF) and not use the of_match_ptr()
> macro.
>
> > Yeah, that trickery is still little known (and I forget about it from
> > time to time).
> >
> > The upshot for those who have missed this is you can use a magic
> > acpi device to instantiate based on device tree bindings :)
> >
> > So we need to strip all this 'obvious' protection stuff out of drivers.
>
> Jonathan,
> Do you want me to do the same changes for
Re: [PATCH v3 1/3] iio: adc: add support for mcp3911
On Sat, 4 Aug 2018 08:55:06 +0200
Marcus Folkesson wrote:
> Hi Andy and Jonathan,
>
>
> On Fri, Aug 03, 2018 at 11:09:22PM +0100, Jonathan Cameron wrote:
> > On Thu, 2 Aug 2018 22:52:00 +0300
> > Andy Shevchenko wrote:
> >
> > > On Thu, Aug 2, 2018 at 10:15 PM, Marcus Folkesson
> > > wrote:
> > > > MCP3911 is a dual channel Analog Front End (AFE) containing two
> > > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
> > > >
> > > > Signed-off-by: Marcus Folkesson
> > >
> > > > Signed-off-by: Kent Gustavsson
> > >
> > > What is this? Why it's here (presense and location in the message)?
> > To clarify... If Kent wrote the patch and you are simply acting
> > as gatekeeper / upstreamer you should set the mail to be from Kent
> > and put your own Signed-off after his to basically act as a submaintainer
> > certifying you believe his sign off and all that entails.
> >
> > If it is a bit of a joint effort then that's fine but for copyright
> > purposes there should be some indication of the split.
>
> First, thank you Andy for noticing.
>
> I actually intended to use Co-Developed-by (a pretty new tag)
> in combination with Signed-off-by.
> But the tag must have disappeared in some preparation stage..
>
> From Documentation/process/submitting-patches.rst ::
>
> A Co-Developed-by: states that the patch was also created by another
> developer
> along with the original author. This is useful at times when multiple
> people
> work on a single patch. Note, this person also needs to have a
> Signed-off-by:
> line in the patch as well.
>
> I will switch order and add the Co-Developed-by-tag.
> Is this correct?
>
> Co-Developed-by: Kent Gustavsson
> Signed-off-by: Kent Gustavsson
> Signed-off-by: Marcus Folkesson
>
> >
> >
> > >
> > > > + * Copyright (C) 2018 Kent Gustavsson
> > >
> > > > + *
> > >
> > > Redundant.
> > >
> > > > +static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + reg = MCP3911_REG_READ(reg, adc->dev_addr);
> > > > + ret = spi_write_then_read(adc->spi, , 1, val, len);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + be32_to_cpus(val);
> > > > + *val >>= ((4 - len) * 8);
> > > > + dev_dbg(>spi->dev, "reading 0x%x from register 0x%x\n",
> > > > *val,
> > > > + reg>>1);
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32 val, u8 len)
> > > > +{
> > > > + dev_dbg(>spi->dev, "writing 0x%x to register 0x%x\n", val,
> > > > reg);
> > > > +
> > > > + val <<= (3 - len) * 8;
> > > > + cpu_to_be32s();
> > > > + val |= MCP3911_REG_WRITE(reg, adc->dev_addr);
> > > > +
> > > > + return spi_write(adc->spi, , len + 1);
> > > > +}
> > >
> > > Can't you use REGMAP_SPI ?
> > My instinct is not really. The magic device-addr doesn't help.
> > You could work around it but it's not that nice and you'd have
> > to create the regmap mapping on the fly or carry static ones
> > for each value of htat.
> >
> >
> >
> > >
> > > > + of_property_read_u32(of_node, "device-addr", >dev_addr);
> > > > + if (adc->dev_addr > 3) {
> > > > + dev_err(>spi->dev,
> > > > + "invalid device address (%i). Must be
> > > > in range 0-3.\n",
> > > > + adc->dev_addr);
> > > > + return -EINVAL;
> > > > + }
> > > > + dev_dbg(>spi->dev, "use device address %i\n",
> > > > adc->dev_addr);
> > >
> > > Isn't what we called CS (chip select)?
> > Nope. We went around this in an earlier revision. It's an address
> > transmitted
> > in the control byte to allow you to 'share' a chip select line between
> > multiple
> > chips (crazy but true).
> >
> > >
> > > > + if (IS_ERR(adc->vref)) {
> > >
> > > > +
> > >
> > > Redundant.
> > >
> > > > + if (adc->clki)
> > >
> > > Seems to be redundant if clock is optional (it should be NULL and API
> > > is NULL-aware).
> > >
> > > > + clk_disable_unprepare(adc->clki);
> > >
> > > > + if (adc->clki)
> > > > + clk_disable_unprepare(adc->clki);
> > >
> > > Ditto.
> > >
> > > > +#if defined(CONFIG_OF)
> > >
> > > This prevents playing with the device on ACPI enabled platforms.
>
> I will remove the defined(CONFIG_OF) and not use the of_match_ptr()
> macro.
>
> > Yeah, that trickery is still little known (and I forget about it from
> > time to time).
> >
> > The upshot for those who have missed this is you can use a magic
> > acpi device to instantiate based on device tree bindings :)
> >
> > So we need to strip all this 'obvious' protection stuff out of drivers.
>
> Jonathan,
> Do you want me to do the same changes for
Re: linux-next: Signed-off-by missing for commit in the h8300 tree
On Sat, 18 Aug 2018 23:30:05 +0900,
Stephen Rothwell wrote:
>
> [1 ]
> Hi Yoshinori,
>
> Commits
>
> 785b0958b55d ("h8300: gcc-8.1 fix")
> 8eabc2d5fae0 ("h8300: Add missing output register.")
>
> are missing a Signed-off-by from their authors and committers.
>
> Commit
>
> 85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
>
> is missing a Signed-off-by from its committer.
OK. Fixed it.
> --
> Cheers,
> Stephen Rothwell
> [2 OpenPGP digital signature ]
> No public key for 015042F34957D06C created at 2018-08-18T23:30:05+0900 using
> RSA
--
Yosinori Sato
Re: linux-next: Signed-off-by missing for commit in the h8300 tree
On Sat, 18 Aug 2018 23:30:05 +0900,
Stephen Rothwell wrote:
>
> [1 ]
> Hi Yoshinori,
>
> Commits
>
> 785b0958b55d ("h8300: gcc-8.1 fix")
> 8eabc2d5fae0 ("h8300: Add missing output register.")
>
> are missing a Signed-off-by from their authors and committers.
>
> Commit
>
> 85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
>
> is missing a Signed-off-by from its committer.
OK. Fixed it.
> --
> Cheers,
> Stephen Rothwell
> [2 OpenPGP digital signature ]
> No public key for 015042F34957D06C created at 2018-08-18T23:30:05+0900 using
> RSA
--
Yosinori Sato
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On Sat, 2018-08-18 at 19:21 +0300, Sergei Shtylyov wrote: > On 08/18/2018 07:15 PM, Joe Perches wrote: > > > > We should use NULL to compare with pointer-typed value rather than > > > > 0. The issue is detected with the help of Coccinelle. > > > > > >Your description stopped to match the patch in v2. > > >Actually, this X == NULL to !x preference is largely spocific to > > > netdev... > > > Although, IDE maintainer is the same now person. :-) [] > > > > diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c [] > > > > @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, > > > > const struct ide_port_info *d) > > > > /* We won't need pci_dev if we switch to generic consistent > > > > * DMA routines ... > > > > */ > > > > - if (dev == NULL || pmif->dma_regs == 0) > > > > + if (!dev || !pmif->dma_regs) > > > > return -ENODEV; > > > > /* > > > > * Allocate space for the DBDMA commands. [] > > Perhaps discourage trivial changes to this old subsystem. > > > > checkpatch could bleat something if a patch was submitted for ide > > if the IDE MAINTAINERS entry was marked obsolete. > >Note that the IDE fixes are still OK... The checkpatch obsolete message is is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. --- > > diff --git a/MAINTAINERS b/MAINTAINERS > > index e9336962d0f2..3c4992cf5249 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -6933,7 +6933,7 @@ M:"David S. Miller" > > L: linux-...@vger.kernel.org > > Q: http://patchwork.ozlabs.org/project/linux-ide/list/ > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git > > -S: Maintained > > +S: Maintained / Obsolete (prefer LIBATA) > >What about "S: Odd Fixes"? Perhaps it better reflects the reality... That'd be up to David.
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On Sat, 2018-08-18 at 19:21 +0300, Sergei Shtylyov wrote: > On 08/18/2018 07:15 PM, Joe Perches wrote: > > > > We should use NULL to compare with pointer-typed value rather than > > > > 0. The issue is detected with the help of Coccinelle. > > > > > >Your description stopped to match the patch in v2. > > >Actually, this X == NULL to !x preference is largely spocific to > > > netdev... > > > Although, IDE maintainer is the same now person. :-) [] > > > > diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c [] > > > > @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, > > > > const struct ide_port_info *d) > > > > /* We won't need pci_dev if we switch to generic consistent > > > > * DMA routines ... > > > > */ > > > > - if (dev == NULL || pmif->dma_regs == 0) > > > > + if (!dev || !pmif->dma_regs) > > > > return -ENODEV; > > > > /* > > > > * Allocate space for the DBDMA commands. [] > > Perhaps discourage trivial changes to this old subsystem. > > > > checkpatch could bleat something if a patch was submitted for ide > > if the IDE MAINTAINERS entry was marked obsolete. > >Note that the IDE fixes are still OK... The checkpatch obsolete message is is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. --- > > diff --git a/MAINTAINERS b/MAINTAINERS > > index e9336962d0f2..3c4992cf5249 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -6933,7 +6933,7 @@ M:"David S. Miller" > > L: linux-...@vger.kernel.org > > Q: http://patchwork.ozlabs.org/project/linux-ide/list/ > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git > > -S: Maintained > > +S: Maintained / Obsolete (prefer LIBATA) > >What about "S: Odd Fixes"? Perhaps it better reflects the reality... That'd be up to David.
WARNING in __fsnotify_recalc_mask
Hello, syzbot found the following crash on: HEAD commit:1f7a4c73a739 Merge tag '9p-for-4.19-2' of git://github.com.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10cccef240 kernel config: https://syzkaller.appspot.com/x/.config?x=68e80edb3c9718c5 dashboard link: https://syzkaller.appspot.com/bug?extid=c34692a51b9a6ca93540 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11c12e8640 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c34692a51b9a6ca93...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 WARNING: CPU: 1 PID: 12015 at fs/notify/mark.c:139 __fsnotify_recalc_mask+0x2d7/0x350 fs/notify/mark.c:139 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 12015 Comm: syz-executor0 Not tainted 4.18.0+ #195 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:__fsnotify_recalc_mask+0x2d7/0x350 fs/notify/mark.c:139 Code: 90 00 00 00 48 83 c4 68 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 eb 2d a2 ff 49 83 ec 04 eb 82 e8 e0 2d a2 ff 0f 0b e8 d9 2d a2 ff <0f> 0b eb a5 e8 60 24 e1 ff e9 11 ff ff ff 48 89 df e8 f3 24 e1 ff RSP: 0018:8801b509f5c8 EFLAGS: 00010293 RAX: 8801b2c0a180 RBX: 0002 RCX: 81dabc96 RDX: RSI: 81dabd67 RDI: 0005 RBP: 8801b509f658 R08: 8801b2c0a180 R09: ed00398cb796 R10: ed00398cb796 R11: 8801cc65bcb3 R12: dc00 R13: 8801cc65bcb0 R14: R15: fsnotify_put_mark+0x523/0xab0 fs/notify/mark.c:240 fsnotify_destroy_marks+0x2d1/0x5c0 fs/notify/mark.c:741 fsnotify_clear_marks_by_inode fs/notify/fsnotify.h:39 [inline] __fsnotify_inode_delete+0x19/0x20 fs/notify/fsnotify.c:35 fsnotify_inoderemove include/linux/fsnotify.h:136 [inline] dentry_unlink_inode+0x48b/0x5e0 fs/dcache.c:370 __dentry_kill+0x44c/0x7a0 fs/dcache.c:566 dentry_kill+0xc9/0x5a0 fs/dcache.c:685 dput.part.26+0x66b/0x7a0 fs/dcache.c:846 dput+0x15/0x20 fs/dcache.c:828 __fput+0x4c2/0x860 fs/file_table.c:264 fput+0x15/0x20 fs/file_table.c:282 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:193 [inline] exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fcfa3e50c78 EFLAGS: 0246 ORIG_RAX: 0021 RAX: 000a RBX: 7fcfa3e516d4 RCX: 00457089 RDX: RSI: 000a RDI: 0008 RBP: 009300a0 R08: R09: R10: R11: 0246 R12: R13: 004cb6d0 R14: 004c31f3 R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On 08/18/2018 06:53 PM, Sergei Shtylyov wrote: >> We should use NULL to compare with pointer-typed value rather than >> 0. The issue is detected with the help of Coccinelle. > >Your description stopped to match the patch in v2. And your subject as well... >Actually, this X == NULL to !x preference is largely spocific to netdev... Specific, of course. :-) > Although, IDE maintainer is the same now person. :-) "The same person now" I wanted to type. :-) > >> Signed-off-by: zhong jiang [...] MBR, Sergei
WARNING in __fsnotify_recalc_mask
Hello, syzbot found the following crash on: HEAD commit:1f7a4c73a739 Merge tag '9p-for-4.19-2' of git://github.com.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10cccef240 kernel config: https://syzkaller.appspot.com/x/.config?x=68e80edb3c9718c5 dashboard link: https://syzkaller.appspot.com/bug?extid=c34692a51b9a6ca93540 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11c12e8640 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c34692a51b9a6ca93...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 WARNING: CPU: 1 PID: 12015 at fs/notify/mark.c:139 __fsnotify_recalc_mask+0x2d7/0x350 fs/notify/mark.c:139 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 12015 Comm: syz-executor0 Not tainted 4.18.0+ #195 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:__fsnotify_recalc_mask+0x2d7/0x350 fs/notify/mark.c:139 Code: 90 00 00 00 48 83 c4 68 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 eb 2d a2 ff 49 83 ec 04 eb 82 e8 e0 2d a2 ff 0f 0b e8 d9 2d a2 ff <0f> 0b eb a5 e8 60 24 e1 ff e9 11 ff ff ff 48 89 df e8 f3 24 e1 ff RSP: 0018:8801b509f5c8 EFLAGS: 00010293 RAX: 8801b2c0a180 RBX: 0002 RCX: 81dabc96 RDX: RSI: 81dabd67 RDI: 0005 RBP: 8801b509f658 R08: 8801b2c0a180 R09: ed00398cb796 R10: ed00398cb796 R11: 8801cc65bcb3 R12: dc00 R13: 8801cc65bcb0 R14: R15: fsnotify_put_mark+0x523/0xab0 fs/notify/mark.c:240 fsnotify_destroy_marks+0x2d1/0x5c0 fs/notify/mark.c:741 fsnotify_clear_marks_by_inode fs/notify/fsnotify.h:39 [inline] __fsnotify_inode_delete+0x19/0x20 fs/notify/fsnotify.c:35 fsnotify_inoderemove include/linux/fsnotify.h:136 [inline] dentry_unlink_inode+0x48b/0x5e0 fs/dcache.c:370 __dentry_kill+0x44c/0x7a0 fs/dcache.c:566 dentry_kill+0xc9/0x5a0 fs/dcache.c:685 dput.part.26+0x66b/0x7a0 fs/dcache.c:846 dput+0x15/0x20 fs/dcache.c:828 __fput+0x4c2/0x860 fs/file_table.c:264 fput+0x15/0x20 fs/file_table.c:282 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:193 [inline] exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fcfa3e50c78 EFLAGS: 0246 ORIG_RAX: 0021 RAX: 000a RBX: 7fcfa3e516d4 RCX: 00457089 RDX: RSI: 000a RDI: 0008 RBP: 009300a0 R08: R09: R10: R11: 0246 R12: R13: 004cb6d0 R14: 004c31f3 R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On 08/18/2018 06:53 PM, Sergei Shtylyov wrote: >> We should use NULL to compare with pointer-typed value rather than >> 0. The issue is detected with the help of Coccinelle. > >Your description stopped to match the patch in v2. And your subject as well... >Actually, this X == NULL to !x preference is largely spocific to netdev... Specific, of course. :-) > Although, IDE maintainer is the same now person. :-) "The same person now" I wanted to type. :-) > >> Signed-off-by: zhong jiang [...] MBR, Sergei
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On 08/18/2018 07:15 PM, Joe Perches wrote: >>> We should use NULL to compare with pointer-typed value rather than >>> 0. The issue is detected with the help of Coccinelle. >> >>Your description stopped to match the patch in v2. >>Actually, this X == NULL to !x preference is largely spocific to >> netdev... >> Although, IDE maintainer is the same now person. :-) >> >>> Signed-off-by: zhong jiang >>> --- >>> drivers/ide/pmac.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c >>> index c5b902b..ca36a97 100644 >>> --- a/drivers/ide/pmac.c >>> +++ b/drivers/ide/pmac.c >>> @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, const >>> struct ide_port_info *d) >>> /* We won't need pci_dev if we switch to generic consistent >>> * DMA routines ... >>> */ >>> - if (dev == NULL || pmif->dma_regs == 0) >>> + if (!dev || !pmif->dma_regs) >>> return -ENODEV; >>> /* >>> * Allocate space for the DBDMA commands. >> >> MBR, Sergei > > Perhaps discourage trivial changes to this old subsystem. > > checkpatch could bleat something if a patch was submitted for ide > if the IDE MAINTAINERS entry was marked obsolete. Note that the IDE fixes are still OK... > --- > diff --git a/MAINTAINERS b/MAINTAINERS > index e9336962d0f2..3c4992cf5249 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6933,7 +6933,7 @@ M: "David S. Miller" > L: linux-...@vger.kernel.org > Q: http://patchwork.ozlabs.org/project/linux-ide/list/ > T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git > -S: Maintained > +S: Maintained / Obsolete (prefer LIBATA) What about "S: Odd Fixes"? Perhaps it better reflects the reality... > F: Documentation/ide/ > F: drivers/ide/ > F: include/linux/ide.h MBR, Sergei
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On 08/18/2018 07:15 PM, Joe Perches wrote: >>> We should use NULL to compare with pointer-typed value rather than >>> 0. The issue is detected with the help of Coccinelle. >> >>Your description stopped to match the patch in v2. >>Actually, this X == NULL to !x preference is largely spocific to >> netdev... >> Although, IDE maintainer is the same now person. :-) >> >>> Signed-off-by: zhong jiang >>> --- >>> drivers/ide/pmac.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c >>> index c5b902b..ca36a97 100644 >>> --- a/drivers/ide/pmac.c >>> +++ b/drivers/ide/pmac.c >>> @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, const >>> struct ide_port_info *d) >>> /* We won't need pci_dev if we switch to generic consistent >>> * DMA routines ... >>> */ >>> - if (dev == NULL || pmif->dma_regs == 0) >>> + if (!dev || !pmif->dma_regs) >>> return -ENODEV; >>> /* >>> * Allocate space for the DBDMA commands. >> >> MBR, Sergei > > Perhaps discourage trivial changes to this old subsystem. > > checkpatch could bleat something if a patch was submitted for ide > if the IDE MAINTAINERS entry was marked obsolete. Note that the IDE fixes are still OK... > --- > diff --git a/MAINTAINERS b/MAINTAINERS > index e9336962d0f2..3c4992cf5249 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6933,7 +6933,7 @@ M: "David S. Miller" > L: linux-...@vger.kernel.org > Q: http://patchwork.ozlabs.org/project/linux-ide/list/ > T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git > -S: Maintained > +S: Maintained / Obsolete (prefer LIBATA) What about "S: Odd Fixes"? Perhaps it better reflects the reality... > F: Documentation/ide/ > F: drivers/ide/ > F: include/linux/ide.h MBR, Sergei
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On Sat, 2018-08-18 at 18:53 +0300, Sergei Shtylyov wrote: > On 08/18/2018 09:16 AM, zhong jiang wrote: > > > We should use NULL to compare with pointer-typed value rather than > > 0. The issue is detected with the help of Coccinelle. > >Your description stopped to match the patch in v2. >Actually, this X == NULL to !x preference is largely spocific to netdev... > Although, IDE maintainer is the same now person. :-) > > > Signed-off-by: zhong jiang > > --- > > drivers/ide/pmac.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c > > index c5b902b..ca36a97 100644 > > --- a/drivers/ide/pmac.c > > +++ b/drivers/ide/pmac.c > > @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, const > > struct ide_port_info *d) > > /* We won't need pci_dev if we switch to generic consistent > > * DMA routines ... > > */ > > - if (dev == NULL || pmif->dma_regs == 0) > > + if (!dev || !pmif->dma_regs) > > return -ENODEV; > > /* > > * Allocate space for the DBDMA commands. > > MBR, Sergei Perhaps discourage trivial changes to this old subsystem. checkpatch could bleat something if a patch was submitted for ide if the IDE MAINTAINERS entry was marked obsolete. --- diff --git a/MAINTAINERS b/MAINTAINERS index e9336962d0f2..3c4992cf5249 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6933,7 +6933,7 @@ M:"David S. Miller" L: linux-...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-ide/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git -S: Maintained +S: Maintained / Obsolete (prefer LIBATA) F: Documentation/ide/ F: drivers/ide/ F: include/linux/ide.h
Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0
On Sat, 2018-08-18 at 18:53 +0300, Sergei Shtylyov wrote: > On 08/18/2018 09:16 AM, zhong jiang wrote: > > > We should use NULL to compare with pointer-typed value rather than > > 0. The issue is detected with the help of Coccinelle. > >Your description stopped to match the patch in v2. >Actually, this X == NULL to !x preference is largely spocific to netdev... > Although, IDE maintainer is the same now person. :-) > > > Signed-off-by: zhong jiang > > --- > > drivers/ide/pmac.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c > > index c5b902b..ca36a97 100644 > > --- a/drivers/ide/pmac.c > > +++ b/drivers/ide/pmac.c > > @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, const > > struct ide_port_info *d) > > /* We won't need pci_dev if we switch to generic consistent > > * DMA routines ... > > */ > > - if (dev == NULL || pmif->dma_regs == 0) > > + if (!dev || !pmif->dma_regs) > > return -ENODEV; > > /* > > * Allocate space for the DBDMA commands. > > MBR, Sergei Perhaps discourage trivial changes to this old subsystem. checkpatch could bleat something if a patch was submitted for ide if the IDE MAINTAINERS entry was marked obsolete. --- diff --git a/MAINTAINERS b/MAINTAINERS index e9336962d0f2..3c4992cf5249 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6933,7 +6933,7 @@ M:"David S. Miller" L: linux-...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-ide/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git -S: Maintained +S: Maintained / Obsolete (prefer LIBATA) F: Documentation/ide/ F: drivers/ide/ F: include/linux/ide.h
[PATCH v1 1/2] clk: tegra: Don't enable already enabled PLLs
Initially Common Clock Framework isn't aware of the clock-enable status,
this results in enabling of clocks that were enabled by bootloader. This
is not a big deal for a regular clock-gates, but for PLL's it may have
some unpleasant consequences. Thus re-enabling PLLX (the main CPU parent
clock) may result in extra long period of PLL re-locking.
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/clk-pll.c | 50 +++--
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 830d1c87fa7c..ddb431247f08 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -444,6 +444,9 @@ static int clk_pll_enable(struct clk_hw *hw)
unsigned long flags = 0;
int ret;
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
if (pll->lock)
spin_lock_irqsave(pll->lock, flags);
@@ -939,11 +942,16 @@ static int clk_plle_training(struct tegra_clk_pll *pll)
static int clk_plle_enable(struct clk_hw *hw)
{
struct tegra_clk_pll *pll = to_clk_pll(hw);
- unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
struct tegra_clk_pll_freq_table sel;
+ unsigned long input_rate;
u32 val;
int err;
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
+ input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -1354,6 +1362,9 @@ static int clk_pllc_enable(struct clk_hw *hw)
int ret;
unsigned long flags = 0;
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
if (pll->lock)
spin_lock_irqsave(pll->lock, flags);
@@ -1566,7 +1577,12 @@ static int clk_plle_tegra114_enable(struct clk_hw *hw)
u32 val;
int ret;
unsigned long flags = 0;
- unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+ unsigned long input_rate;
+
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
+ input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -1703,6 +1719,9 @@ static int clk_pllu_tegra114_enable(struct clk_hw *hw)
return -EINVAL;
}
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
input_rate = clk_hw_get_rate(__clk_get_hw(osc));
if (pll->lock)
@@ -2378,6 +2397,16 @@ struct clk *tegra_clk_register_pllre_tegra210(const char
*name,
return clk;
}
+static int clk_plle_tegra210_is_enabled(struct clk_hw *hw)
+{
+ struct tegra_clk_pll *pll = to_clk_pll(hw);
+ u32 val;
+
+ val = pll_readl_base(pll);
+
+ return val & PLLE_BASE_ENABLE ? 1 : 0;
+}
+
static int clk_plle_tegra210_enable(struct clk_hw *hw)
{
struct tegra_clk_pll *pll = to_clk_pll(hw);
@@ -2385,7 +2414,12 @@ static int clk_plle_tegra210_enable(struct clk_hw *hw)
u32 val;
int ret = 0;
unsigned long flags = 0;
- unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+ unsigned long input_rate;
+
+ if (clk_plle_tegra210_is_enabled(hw))
+ return 0;
+
+ input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -2496,16 +2530,6 @@ static void clk_plle_tegra210_disable(struct clk_hw *hw)
spin_unlock_irqrestore(pll->lock, flags);
}
-static int clk_plle_tegra210_is_enabled(struct clk_hw *hw)
-{
- struct tegra_clk_pll *pll = to_clk_pll(hw);
- u32 val;
-
- val = pll_readl_base(pll);
-
- return val & PLLE_BASE_ENABLE ? 1 : 0;
-}
-
static const struct clk_ops tegra_clk_plle_tegra210_ops = {
.is_enabled = clk_plle_tegra210_is_enabled,
.enable = clk_plle_tegra210_enable,
--
2.18.0
[PATCH v1 2/2] clk: tegra20: Enable lock-status polling for PLLs
Currently all PLL's on Tegra20 use a hardcoded delay despite of having
a lock-status bit. The lock-status polling was disabled ~7 years ago
because apparently some PLL was failing to lock. That issue isn't
observable with the modern kernel, hence let's assume it was some
unrelated bug and enable the lock-status polling. This significantly
reduces delay of any operation that require PLL to lock.
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/clk-tegra20.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index cc857d4d4a86..75415854ce12 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -298,7 +298,8 @@ static struct tegra_clk_pll_params pll_c_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_c_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_m_params = {
@@ -314,7 +315,8 @@ static struct tegra_clk_pll_params pll_m_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_m_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_p_params = {
@@ -331,7 +333,7 @@ static struct tegra_clk_pll_params pll_p_params = {
.lock_delay = 300,
.freq_table = pll_p_freq_table,
.flags = TEGRA_PLL_FIXED | TEGRA_PLL_HAS_CPCON |
-TEGRA_PLL_HAS_LOCK_ENABLE,
+TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_USE_LOCK,
.fixed_rate = 21600,
};
@@ -348,7 +350,8 @@ static struct tegra_clk_pll_params pll_a_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_a_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_d_params = {
@@ -364,7 +367,8 @@ static struct tegra_clk_pll_params pll_d_params = {
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
.freq_table = pll_d_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static const struct pdiv_map pllu_p[] = {
@@ -387,7 +391,8 @@ static struct tegra_clk_pll_params pll_u_params = {
.lock_delay = 1000,
.pdiv_tohw = pllu_p,
.freq_table = pll_u_freq_table,
- .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_x_params = {
@@ -403,7 +408,8 @@ static struct tegra_clk_pll_params pll_x_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_x_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_e_params = {
@@ -421,7 +427,7 @@ static struct tegra_clk_pll_params pll_e_params = {
.pdiv_tohw = plle_p,
.freq_table = pll_e_freq_table,
.flags = TEGRA_PLL_FIXED | TEGRA_PLL_LOCK_MISC |
-TEGRA_PLL_HAS_LOCK_ENABLE,
+TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_USE_LOCK,
.fixed_rate = 1,
};
--
2.18.0
[PATCH v1 1/2] clk: tegra: Don't enable already enabled PLLs
Initially Common Clock Framework isn't aware of the clock-enable status,
this results in enabling of clocks that were enabled by bootloader. This
is not a big deal for a regular clock-gates, but for PLL's it may have
some unpleasant consequences. Thus re-enabling PLLX (the main CPU parent
clock) may result in extra long period of PLL re-locking.
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/clk-pll.c | 50 +++--
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 830d1c87fa7c..ddb431247f08 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -444,6 +444,9 @@ static int clk_pll_enable(struct clk_hw *hw)
unsigned long flags = 0;
int ret;
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
if (pll->lock)
spin_lock_irqsave(pll->lock, flags);
@@ -939,11 +942,16 @@ static int clk_plle_training(struct tegra_clk_pll *pll)
static int clk_plle_enable(struct clk_hw *hw)
{
struct tegra_clk_pll *pll = to_clk_pll(hw);
- unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
struct tegra_clk_pll_freq_table sel;
+ unsigned long input_rate;
u32 val;
int err;
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
+ input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -1354,6 +1362,9 @@ static int clk_pllc_enable(struct clk_hw *hw)
int ret;
unsigned long flags = 0;
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
if (pll->lock)
spin_lock_irqsave(pll->lock, flags);
@@ -1566,7 +1577,12 @@ static int clk_plle_tegra114_enable(struct clk_hw *hw)
u32 val;
int ret;
unsigned long flags = 0;
- unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+ unsigned long input_rate;
+
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
+ input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -1703,6 +1719,9 @@ static int clk_pllu_tegra114_enable(struct clk_hw *hw)
return -EINVAL;
}
+ if (clk_pll_is_enabled(hw))
+ return 0;
+
input_rate = clk_hw_get_rate(__clk_get_hw(osc));
if (pll->lock)
@@ -2378,6 +2397,16 @@ struct clk *tegra_clk_register_pllre_tegra210(const char
*name,
return clk;
}
+static int clk_plle_tegra210_is_enabled(struct clk_hw *hw)
+{
+ struct tegra_clk_pll *pll = to_clk_pll(hw);
+ u32 val;
+
+ val = pll_readl_base(pll);
+
+ return val & PLLE_BASE_ENABLE ? 1 : 0;
+}
+
static int clk_plle_tegra210_enable(struct clk_hw *hw)
{
struct tegra_clk_pll *pll = to_clk_pll(hw);
@@ -2385,7 +2414,12 @@ static int clk_plle_tegra210_enable(struct clk_hw *hw)
u32 val;
int ret = 0;
unsigned long flags = 0;
- unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+ unsigned long input_rate;
+
+ if (clk_plle_tegra210_is_enabled(hw))
+ return 0;
+
+ input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -2496,16 +2530,6 @@ static void clk_plle_tegra210_disable(struct clk_hw *hw)
spin_unlock_irqrestore(pll->lock, flags);
}
-static int clk_plle_tegra210_is_enabled(struct clk_hw *hw)
-{
- struct tegra_clk_pll *pll = to_clk_pll(hw);
- u32 val;
-
- val = pll_readl_base(pll);
-
- return val & PLLE_BASE_ENABLE ? 1 : 0;
-}
-
static const struct clk_ops tegra_clk_plle_tegra210_ops = {
.is_enabled = clk_plle_tegra210_is_enabled,
.enable = clk_plle_tegra210_enable,
--
2.18.0
[PATCH v1 2/2] clk: tegra20: Enable lock-status polling for PLLs
Currently all PLL's on Tegra20 use a hardcoded delay despite of having
a lock-status bit. The lock-status polling was disabled ~7 years ago
because apparently some PLL was failing to lock. That issue isn't
observable with the modern kernel, hence let's assume it was some
unrelated bug and enable the lock-status polling. This significantly
reduces delay of any operation that require PLL to lock.
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/clk-tegra20.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index cc857d4d4a86..75415854ce12 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -298,7 +298,8 @@ static struct tegra_clk_pll_params pll_c_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_c_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_m_params = {
@@ -314,7 +315,8 @@ static struct tegra_clk_pll_params pll_m_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_m_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_p_params = {
@@ -331,7 +333,7 @@ static struct tegra_clk_pll_params pll_p_params = {
.lock_delay = 300,
.freq_table = pll_p_freq_table,
.flags = TEGRA_PLL_FIXED | TEGRA_PLL_HAS_CPCON |
-TEGRA_PLL_HAS_LOCK_ENABLE,
+TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_USE_LOCK,
.fixed_rate = 21600,
};
@@ -348,7 +350,8 @@ static struct tegra_clk_pll_params pll_a_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_a_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_d_params = {
@@ -364,7 +367,8 @@ static struct tegra_clk_pll_params pll_d_params = {
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
.freq_table = pll_d_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static const struct pdiv_map pllu_p[] = {
@@ -387,7 +391,8 @@ static struct tegra_clk_pll_params pll_u_params = {
.lock_delay = 1000,
.pdiv_tohw = pllu_p,
.freq_table = pll_u_freq_table,
- .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_x_params = {
@@ -403,7 +408,8 @@ static struct tegra_clk_pll_params pll_x_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_x_freq_table,
- .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+ .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
};
static struct tegra_clk_pll_params pll_e_params = {
@@ -421,7 +427,7 @@ static struct tegra_clk_pll_params pll_e_params = {
.pdiv_tohw = plle_p,
.freq_table = pll_e_freq_table,
.flags = TEGRA_PLL_FIXED | TEGRA_PLL_LOCK_MISC |
-TEGRA_PLL_HAS_LOCK_ENABLE,
+TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_USE_LOCK,
.fixed_rate = 1,
};
--
2.18.0
[PATCH v1 2/5] arm64: dts: mt7622: add a bluetooth 5 device node
Add a built-in bluetooth 5 support for MT7622.
Signed-off-by: Ryder Lee
Acked-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index d297100..b4d7934 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -530,6 +530,13 @@
reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
+
+ bluetooth {
+ compatible = "mediatek,mt7622-bluetooth";
+ power-domains = < MT7622_POWER_DOMAIN_WB>;
+ clocks = <>;
+ clock-names = "ref";
+ };
};
nandc: nfi@1100d000 {
--
1.9.1
[PATCH v1 2/5] arm64: dts: mt7622: add a bluetooth 5 device node
Add a built-in bluetooth 5 support for MT7622.
Signed-off-by: Ryder Lee
Acked-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index d297100..b4d7934 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -530,6 +530,13 @@
reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
+
+ bluetooth {
+ compatible = "mediatek,mt7622-bluetooth";
+ power-domains = < MT7622_POWER_DOMAIN_WB>;
+ clocks = <>;
+ clock-names = "ref";
+ };
};
nandc: nfi@1100d000 {
--
1.9.1
[PATCH v1 4/5] arm64: dts: mt7622: add bananapi BPI-R64 board
Add support for the bananapi R64 (BPI-R64) development board from
BIPAI KEJI. Detailed hardware information for BPI-R64 which could be
found on http://wiki.banana-pi.org/Banana_Pi_BPI-R64
Signed-off-by: Ryder Lee
---
changes since v1:
- add missing sata nodes.
- fix pinctrl-0 for pcie@1,0.
- switch goio keys from polling mode to intterupt mode.
- add gpio-led nodes.
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts | 530 +
2 files changed, 531 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index 5b7fd6a..e8f952f 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -5,4 +5,5 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
new file mode 100644
index 000..5d6005c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -0,0 +1,530 @@
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR MIT)
+ */
+
+/dts-v1/;
+#include
+#include
+
+#include "mt7622.dtsi"
+#include "mt6380.dtsi"
+
+/ {
+ model = "Bananapi BPI-R64";
+ compatible = "bananapi,bpi-r64", "mediatek,mt7622";
+
+ chosen {
+ bootargs = "earlycon=uart8250,mmio32,0x11002000
console=ttyS0,115200n1 swiotlb=512";
+ };
+
+ cpus {
+ cpu@0 {
+ proc-supply = <_vcpu_reg>;
+ sram-supply = <_vm_reg>;
+ };
+
+ cpu@1 {
+ proc-supply = <_vcpu_reg>;
+ sram-supply = <_vm_reg>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ factory {
+ label = "factory";
+ linux,code = ;
+ gpios = < 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = < 102 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ green {
+ label = "bpi-r64:pio:green";
+ gpios = < 89 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ red {
+ label = "bpi-r64:pio:red";
+ gpios = < 88 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ memory {
+ reg = <0 0x4000 0 0x4000>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ gmac1: mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-handle = <>;
+ };
+
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ phy-mode = "sgmii";
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default",
[PATCH v1 4/5] arm64: dts: mt7622: add bananapi BPI-R64 board
Add support for the bananapi R64 (BPI-R64) development board from
BIPAI KEJI. Detailed hardware information for BPI-R64 which could be
found on http://wiki.banana-pi.org/Banana_Pi_BPI-R64
Signed-off-by: Ryder Lee
---
changes since v1:
- add missing sata nodes.
- fix pinctrl-0 for pcie@1,0.
- switch goio keys from polling mode to intterupt mode.
- add gpio-led nodes.
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts | 530 +
2 files changed, 531 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index 5b7fd6a..e8f952f 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -5,4 +5,5 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
new file mode 100644
index 000..5d6005c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -0,0 +1,530 @@
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR MIT)
+ */
+
+/dts-v1/;
+#include
+#include
+
+#include "mt7622.dtsi"
+#include "mt6380.dtsi"
+
+/ {
+ model = "Bananapi BPI-R64";
+ compatible = "bananapi,bpi-r64", "mediatek,mt7622";
+
+ chosen {
+ bootargs = "earlycon=uart8250,mmio32,0x11002000
console=ttyS0,115200n1 swiotlb=512";
+ };
+
+ cpus {
+ cpu@0 {
+ proc-supply = <_vcpu_reg>;
+ sram-supply = <_vm_reg>;
+ };
+
+ cpu@1 {
+ proc-supply = <_vcpu_reg>;
+ sram-supply = <_vm_reg>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ factory {
+ label = "factory";
+ linux,code = ;
+ gpios = < 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = < 102 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ green {
+ label = "bpi-r64:pio:green";
+ gpios = < 89 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ red {
+ label = "bpi-r64:pio:red";
+ gpios = < 88 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ memory {
+ reg = <0 0x4000 0 0x4000>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ gmac1: mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-handle = <>;
+ };
+
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ phy-mode = "sgmii";
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default",
[PATCH v1 5/5] dt-bindings: arm: mediatek: add support for bananapi BPI-R64 board
Update binding document for bananapi BPI-R64 board being supported. Signed-off-by: Ryder Lee Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt index 8f260e5..d30f6ce 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.txt +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -57,6 +57,9 @@ Supported boards: - Reference board variant 1 for MT7622: Required root node properties: - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622"; +- Bananapi BPI-R64 for MT7622: +Required root node properties: + - compatible = "bananapi,bpi-r64", "mediatek,mt7622"; - Reference board for MT7623a with eMMC: Required root node properties: - compatible = "mediatek,mt7623a-rfb-emmc", "mediatek,mt7623"; -- 1.9.1
[PATCH v1 5/5] dt-bindings: arm: mediatek: add support for bananapi BPI-R64 board
Update binding document for bananapi BPI-R64 board being supported. Signed-off-by: Ryder Lee Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt index 8f260e5..d30f6ce 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.txt +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -57,6 +57,9 @@ Supported boards: - Reference board variant 1 for MT7622: Required root node properties: - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622"; +- Bananapi BPI-R64 for MT7622: +Required root node properties: + - compatible = "bananapi,bpi-r64", "mediatek,mt7622"; - Reference board for MT7623a with eMMC: Required root node properties: - compatible = "mediatek,mt7623a-rfb-emmc", "mediatek,mt7623"; -- 1.9.1
[PATCH v1 3/5] arm64: dts: mt7622: fix ram size for rfb1
Fix ram size to 512 megabytes and sort nodes in alphabetical order.
Signed-off-by: Ryder Lee
Acked-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 196 +--
1 file changed, 98 insertions(+), 98 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index a747b7b..dcad086 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -51,7 +51,7 @@
};
memory {
- reg = <0 0x4000 0 0x3F00>;
+ reg = <0 0x4000 0 0x2000>;
};
reg_1p8v: regulator-1p8v {
@@ -81,6 +81,103 @@
};
};
+ {
+ status = "disabled";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ gmac1: mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-handle = <>;
+ };
+
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ phy-mode = "sgmii";
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <_pins_default>;
+ pinctrl-1 = <_pins_uhs>;
+ status = "okay";
+ bus-width = <8>;
+ max-frequency = <5000>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_1p8v>;
+ assigned-clocks = < CLK_TOP_MSDC30_0_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIV48M>;
+ non-removable;
+};
+
+ {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <_pins_default>;
+ pinctrl-1 = <_pins_uhs>;
+ status = "okay";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ cap-sd-highspeed;
+ r_smpl = <1>;
+ cd-gpios = < 81 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_3p3v>;
+ assigned-clocks = < CLK_TOP_MSDC30_1_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIV48M>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_nand_pins>;
+ status = "disabled";
+};
+
+_flash {
+ pinctrl-names = "default";
+ pinctrl-0 = <_nor_pins>;
+ status = "disabled";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -344,103 +441,6 @@
};
};
- {
- status = "disabled";
-};
-
- {
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-
- gmac1: mac@1 {
- compatible = "mediatek,eth-mac";
- reg = <1>;
- phy-handle = <>;
- };
-
- mdio-bus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- phy5: ethernet-phy@5 {
- reg = <5>;
- phy-mode = "sgmii";
- };
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-};
-
- {
- pinctrl-names = "default", "state_uhs";
- pinctrl-0 = <_pins_default>;
- pinctrl-1 = <_pins_uhs>;
- status = "okay";
- bus-width = <8>;
- max-frequency = <5000>;
- cap-mmc-highspeed;
- mmc-hs200-1_8v;
- vmmc-supply = <_3p3v>;
- vqmmc-supply = <_1p8v>;
- assigned-clocks = < CLK_TOP_MSDC30_0_SEL>;
- assigned-clock-parents = < CLK_TOP_UNIV48M>;
- non-removable;
-};
-
- {
- pinctrl-names = "default", "state_uhs";
- pinctrl-0 = <_pins_default>;
- pinctrl-1 = <_pins_uhs>;
- status = "okay";
- bus-width = <4>;
- max-frequency = <5000>;
- cap-sd-highspeed;
- r_smpl = <1>;
- cd-gpios = < 81 GPIO_ACTIVE_LOW>;
- vmmc-supply = <_3p3v>;
- vqmmc-supply = <_3p3v>;
- assigned-clocks = < CLK_TOP_MSDC30_1_SEL>;
- assigned-clock-parents = < CLK_TOP_UNIV48M>;
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_nand_pins>;
- status = "disabled";
-};
-
-_flash {
- pinctrl-names = "default";
- pinctrl-0 = <_nor_pins>;
- status = "disabled";
-
- flash@0 {
- compatible =
[PATCH v1 3/5] arm64: dts: mt7622: fix ram size for rfb1
Fix ram size to 512 megabytes and sort nodes in alphabetical order.
Signed-off-by: Ryder Lee
Acked-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 196 +--
1 file changed, 98 insertions(+), 98 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index a747b7b..dcad086 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -51,7 +51,7 @@
};
memory {
- reg = <0 0x4000 0 0x3F00>;
+ reg = <0 0x4000 0 0x2000>;
};
reg_1p8v: regulator-1p8v {
@@ -81,6 +81,103 @@
};
};
+ {
+ status = "disabled";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ gmac1: mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-handle = <>;
+ };
+
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ phy-mode = "sgmii";
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <_pins_default>;
+ pinctrl-1 = <_pins_uhs>;
+ status = "okay";
+ bus-width = <8>;
+ max-frequency = <5000>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_1p8v>;
+ assigned-clocks = < CLK_TOP_MSDC30_0_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIV48M>;
+ non-removable;
+};
+
+ {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <_pins_default>;
+ pinctrl-1 = <_pins_uhs>;
+ status = "okay";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ cap-sd-highspeed;
+ r_smpl = <1>;
+ cd-gpios = < 81 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <_3p3v>;
+ vqmmc-supply = <_3p3v>;
+ assigned-clocks = < CLK_TOP_MSDC30_1_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIV48M>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_nand_pins>;
+ status = "disabled";
+};
+
+_flash {
+ pinctrl-names = "default";
+ pinctrl-0 = <_nor_pins>;
+ status = "disabled";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -344,103 +441,6 @@
};
};
- {
- status = "disabled";
-};
-
- {
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-
- gmac1: mac@1 {
- compatible = "mediatek,eth-mac";
- reg = <1>;
- phy-handle = <>;
- };
-
- mdio-bus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- phy5: ethernet-phy@5 {
- reg = <5>;
- phy-mode = "sgmii";
- };
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-};
-
- {
- pinctrl-names = "default", "state_uhs";
- pinctrl-0 = <_pins_default>;
- pinctrl-1 = <_pins_uhs>;
- status = "okay";
- bus-width = <8>;
- max-frequency = <5000>;
- cap-mmc-highspeed;
- mmc-hs200-1_8v;
- vmmc-supply = <_3p3v>;
- vqmmc-supply = <_1p8v>;
- assigned-clocks = < CLK_TOP_MSDC30_0_SEL>;
- assigned-clock-parents = < CLK_TOP_UNIV48M>;
- non-removable;
-};
-
- {
- pinctrl-names = "default", "state_uhs";
- pinctrl-0 = <_pins_default>;
- pinctrl-1 = <_pins_uhs>;
- status = "okay";
- bus-width = <4>;
- max-frequency = <5000>;
- cap-sd-highspeed;
- r_smpl = <1>;
- cd-gpios = < 81 GPIO_ACTIVE_LOW>;
- vmmc-supply = <_3p3v>;
- vqmmc-supply = <_3p3v>;
- assigned-clocks = < CLK_TOP_MSDC30_1_SEL>;
- assigned-clock-parents = < CLK_TOP_UNIV48M>;
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_nand_pins>;
- status = "disabled";
-};
-
-_flash {
- pinctrl-names = "default";
- pinctrl-0 = <_nor_pins>;
- status = "disabled";
-
- flash@0 {
- compatible =
