Re: [PATCH v3 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

[Tony Lindgren]

* Peter Ujfalusi  [160603 06:10]:
> On 06/03/16 14:03, Peter Ujfalusi wrote:
> > 
> > I have prepared two branches on top of v4.7-rc1:
> > [1] https://github.com/omap-audio/linux-audio.git 
> > peter/for-4.8_omapdss_part1
> > 
> > containing:
> >   ARM: OMAP: rx51-video: Do not set TV connector_type
> >   ARM/video: omap2: Move omap_display_init declaration to
> > mach-omap2/display.h
> >   video/platform_data: omapdss: Create new header file for platform data
> >   ARM: OMAP2: Use the platform_data header for omapdss
> 
> I have added your Acked-by to the ARM: OMAP patches to speed things up, please
> let me know if that is OK.

Well in general not, but seems OK to me in this case.

If peter/for-4.8_omapdss_part1 is now considered immutable, can
you please send me a pull request that I can merge it into
omap-for-v4.8/soc too?

Regards,

Tony

Re: [PATCH] dmaengine: do not allow access outside of unmap_pool

[Vinod Koul]

On Tue, May 17, 2016 at 01:00:46PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> When CONFIG_DMA_ENGINE_RAID is defined, unmap_pool[] is just 1
> element in size, however, allows orders of 2..8 to access
> outside unmap_pool and returns an invalid address. Ensure
> we fall into the default path and report a BUG() when
> CONFIG_DMA_ENGINE_RAID is defined and order is out of range.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/dma/dmaengine.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 8c9f45f..6027e66 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -1100,12 +1100,14 @@ static struct dmaengine_unmap_pool 
> *__get_unmap_pool(int nr)
>   switch (order) {
>   case 0 ... 1:
>   return _pool[0];
> + #if IS_ENABLED(CONFIG_DMA_ENGINE_RAID)

Okay if CONFIG_DMA_ENGINE_RAID is enabled (m or y) then IS_ENABLED
return 1, so we will go inside and not fall into default. And I though
by changelog that you want it to go to default in CONFIG_DMA_ENGINE_RAID
is defined!

What did I miss...

>   case 2 ... 4:
>   return _pool[1];
>   case 5 ... 7:
>   return _pool[2];
>   case 8:
>   return _pool[3];
> + #endif
>   default:
>   BUG();
>   return NULL;
> -- 
> 2.8.1
> 

-- 
~Vinod

Re: [PATCH v3 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

[Tony Lindgren]

* Peter Ujfalusi  [160603 06:10]:
> On 06/03/16 14:03, Peter Ujfalusi wrote:
> > 
> > I have prepared two branches on top of v4.7-rc1:
> > [1] https://github.com/omap-audio/linux-audio.git 
> > peter/for-4.8_omapdss_part1
> > 
> > containing:
> >   ARM: OMAP: rx51-video: Do not set TV connector_type
> >   ARM/video: omap2: Move omap_display_init declaration to
> > mach-omap2/display.h
> >   video/platform_data: omapdss: Create new header file for platform data
> >   ARM: OMAP2: Use the platform_data header for omapdss
> 
> I have added your Acked-by to the ARM: OMAP patches to speed things up, please
> let me know if that is OK.

Well in general not, but seems OK to me in this case.

If peter/for-4.8_omapdss_part1 is now considered immutable, can
you please send me a pull request that I can merge it into
omap-for-v4.8/soc too?

Regards,

Tony

Re: [PATCH] dmaengine: do not allow access outside of unmap_pool

[Vinod Koul]

On Tue, May 17, 2016 at 01:00:46PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> When CONFIG_DMA_ENGINE_RAID is defined, unmap_pool[] is just 1
> element in size, however, allows orders of 2..8 to access
> outside unmap_pool and returns an invalid address. Ensure
> we fall into the default path and report a BUG() when
> CONFIG_DMA_ENGINE_RAID is defined and order is out of range.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/dma/dmaengine.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 8c9f45f..6027e66 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -1100,12 +1100,14 @@ static struct dmaengine_unmap_pool 
> *__get_unmap_pool(int nr)
>   switch (order) {
>   case 0 ... 1:
>   return _pool[0];
> + #if IS_ENABLED(CONFIG_DMA_ENGINE_RAID)

Okay if CONFIG_DMA_ENGINE_RAID is enabled (m or y) then IS_ENABLED
return 1, so we will go inside and not fall into default. And I though
by changelog that you want it to go to default in CONFIG_DMA_ENGINE_RAID
is defined!

What did I miss...

>   case 2 ... 4:
>   return _pool[1];
>   case 5 ... 7:
>   return _pool[2];
>   case 8:
>   return _pool[3];
> + #endif
>   default:
>   BUG();
>   return NULL;
> -- 
> 2.8.1
> 

-- 
~Vinod

[ANNOUNCE] Git v2.9.0-rc2

[Junio C Hamano]

A release candidate Git v2.9.0-rc2 is now available for testing
at the usual places.  It is comprised of 477 non-merge commits
since v2.8.0, contributed by 67 people, 27 of which are new faces.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories all have a copy of the
'v2.9.0-rc2' tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors whose contributions weren't in v2.8.0 are as follows.
Welcome to the Git development community!

  Alexander Rinass, Armin Kunaschik, Benjamin Dopplinger,
  Ben Woosley, Erwan Mathoniere, Gabriel Souza Franco, Jacob
  Nisnevich, Jan Durovec, Jean-Noël Avila, Kazuki Yamaguchi,
  Keller Fuchs, Laurent Arnoud, Li Peng, Marios Titas, Mehul Jain,
  Michael Procter, Nikola Forró, Pablo Santiago Blum de Aguiar,
  Pranit Bauva, Ray Zhang, René Nyffenegger, Santiago Torres,
  Saurav Sachidanand, Shin Kojima, Sidhant Sharma [:tk], Stanislav
  Kolotinskiy, and Xiaolong Ye.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  Adam Dinwoodie, Ævar Arnfjörð Bjarmason, Alexander Kuleshov,
  brian m. carlson, Brian Norris, Christian Couder, David Aguilar,
  David Turner, Dennis Kaarsemaker, Elia Pinto, Elijah Newren,
  Eric Sunshine, Eric Wong, Felipe Contreras, Jacob Keller,
  Jeff King, Jiang Xin, Johannes Schindelin, Johannes Sixt,
  John Keeping, Junio C Hamano, Karsten Blees, Lars Schneider,
  Linus Torvalds, Luke Diamand, Matthieu Moy, Michael Haggerty,
  Michael J Gruber, Michael Rappazzo, Nguyễn Thái Ngọc
  Duy, Ori Avtalion, Ralf Thielow, Ramsay Jones, René Scharfe,
  Stefan Beller, Stephen P. Smith, Sven Strickroth, SZEDER Gábor,
  Torsten Bögershausen, and Vasco Almeida.



Git 2.9 Release Notes (draft)
=

Backward compatibility notes


The end-user facing Porcelain level commands in the "git diff" and
"git log" family by default enable the rename detection; you can still
use "diff.renames" configuration variable to disable this.

Merging two branches that have no common ancestor with "git merge" is
by default forbidden now to prevent creating such an unusual merge by
mistake.

The output formats of "git log" that indents the commit log message by
4 spaces now expands HT in the log message by default.  You can use
the "--no-expand-tabs" option to disable this.

"git commit-tree" plumbing command required the user to always sign
its result when the user sets the commit.gpgsign configuration
variable, which was an ancient mistake, which this release corrects.
A script that drives commit-tree, if it relies on this mistake, now
needs to read commit.gpgsign and pass the -S option as necessary.


Updates since v2.8
--

UI, Workflows & Features

 * Comes with git-multimail 1.3.1 (in contrib/).

 * The end-user facing commands like "git diff" and "git log"
   now enable the rename detection by default.

 * The credential.helper configuration variable is cumulative and
   there is no good way to override it from the command line.  As
   a special case, giving an empty string as its value now serves
   as the signal to clear the values specified in various files.

 * A new "interactive.diffFilter" configuration can be used to
   customize the diff shown in "git add -i" sessions.

 * "git p4" now allows P4 author names to be mapped to Git author
   names.

 * "git rebase -x" can be used without passing "-i" option.

 * "git -c credential.= submodule" can now be used to
   propagate configuration variables related to credential helper
   down to the submodules.

 * "git tag" can create an annotated tag without explicitly given an
   "-a" (or "-s") option (i.e. when a tag message is given).  A new
   configuration variable, tag.forceSignAnnotated, can be used to tell
   the command to create signed tag in such a situation.

 * "git merge" used to allow merging two branches that have no common
   base by default, which led to a brand new history of an existing
   project created and then get pulled by an unsuspecting maintainer,
   which allowed an unnecessary parallel history merged into the
   existing project.  The command has been taught not to allow this by
   default, with an escape hatch "--allow-unrelated-histories" option
   to be used in a rare event that merges histories of two projects
   that started their lives independently.

 * "git pull" has been taught to pass the "--allow-unrelated-histories"
   option to underlying "git merge".

 * "git apply -v" learned to report paths in the patch that were
   skipped via --include/--exclude mechanism or being outside 

[ANNOUNCE] Git v2.8.4

[Junio C Hamano]

The latest maintenance release Git v2.8.4 is now available at
the usual places.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.8.4'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git



Git v2.8.4 Release Notes


Fixes since v2.8.3
--

 * Documentation for "git merge --verify-signatures" has been updated
   to clarify that the signature of only the commit at the tip is
   verified.  Also the phrasing used for signature and key validity is
   adjusted to align with that used by OpenPGP.

 * On Windows, .git and optionally any files whose name starts with a
   dot are now marked as hidden, with a core.hideDotFiles knob to
   customize this behaviour.

 * Portability enhancement for "rebase -i" to help platforms whose
   shell does not like "for i in " (which is not POSIX-kosher).

 * "git fsck" learned to catch NUL byte in a commit object as
   potential error and warn.

 * CI test was taught to build documentation pages.

 * Many 'linkgit:' references were broken,
   which are all fixed with this.

 * "git describe --contains" often made a hard-to-justify choice of
   tag to give name to a given commit, because it tried to come up
   with a name with smallest number of hops from a tag, causing an old
   commit whose close descendant that is recently tagged were not
   described with respect to an old tag but with a newer tag.  It did
   not help that its computation of "hop" count was further tweaked to
   penalize being on a side branch of a merge.  The logic has been
   updated to favor using the tag with the oldest tagger date, which
   is a lot easier to explain to the end users: "We describe a commit
   in terms of the (chronologically) oldest tag that contains the
   commit."

 * Running tests with '-x' option to trace the individual command
   executions is a useful way to debug test scripts, but some tests
   that capture the standard error stream and check what the command
   said can be broken with the trace output mixed in.  When running
   our tests under "bash", however, we can redirect the trace output
   to another file descriptor to keep the standard error of programs
   being tested intact.

 * "http.cookieFile" configuration variable clearly wants a pathname,
   but we forgot to treat it as such by e.g. applying tilde expansion.

 * When de-initialising all submodules, "git submodule deinit" gave a
   faulty recommendation to use "git submodule deinit .", which would
   result in a strange error message in a pathological corner case.
   This has been corrected to suggest "submodule deinit --all" instead.

 * Many commands normalize command line arguments from NFD to NFC
   variant of UTF-8 on OSX, but commands in the "diff" family did
   not, causing "git diff $path" to complain that no such path is
   known to Git.  They have been taught to do the normalization.

 * A couple of bugs around core.autocrlf have been fixed.

 * "git difftool" learned to handle unmerged paths correctly in
   dir-diff mode.

 * The "are we talking with TTY, doing an interactive session?"
   detection has been updated to work better for "Git for Windows".


Also contains other minor documentation updates and code clean-ups.



Changes since v2.8.3 are as follows:

Alexander Rinass (1):
  diff: run arguments through precompose_argv

Armin Kunaschik (1):
  t4151: make sure argument to 'test -z' is given

Brian Norris (3):
  Documentation: config: improve word ordering for http.cookieFile
  http: expand http.cookieFile as a path
  config: consistently format $variables in monospaced font

David Aguilar (2):
  difftool: initialize variables for readability
  difftool: handle unmerged files in dir-diff mode

Jeff King (3):
  rebase--interactive: avoid empty list in shell for-loop
  test-lib: set BASH_XTRACEFD automatically
  archive-tar: convert snprintf to xsnprintf

Johannes Schindelin (3):
  name-rev: include taggerdate in considering the best name
  mingw: introduce the 'core.hideDotFiles' setting
  mingw: remove unnecessary definition

Junio C Hamano (9):
  fsck_commit_buffer(): do not special case the last validation
  config: describe 'pathname' value type
  test-lib-functions.sh: remove misleading comment on test_seq
  test-lib-functions.sh: rewrite test_seq without Perl
  Documentation: fix linkgit references
  fsck: detect and warn a commit with embedded NUL
  Start preparing for 2.8.4
  More topics for 2.8.4

[ANNOUNCE] Git v2.9.0-rc2

[Junio C Hamano]

A release candidate Git v2.9.0-rc2 is now available for testing
at the usual places.  It is comprised of 477 non-merge commits
since v2.8.0, contributed by 67 people, 27 of which are new faces.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories all have a copy of the
'v2.9.0-rc2' tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors whose contributions weren't in v2.8.0 are as follows.
Welcome to the Git development community!

  Alexander Rinass, Armin Kunaschik, Benjamin Dopplinger,
  Ben Woosley, Erwan Mathoniere, Gabriel Souza Franco, Jacob
  Nisnevich, Jan Durovec, Jean-Noël Avila, Kazuki Yamaguchi,
  Keller Fuchs, Laurent Arnoud, Li Peng, Marios Titas, Mehul Jain,
  Michael Procter, Nikola Forró, Pablo Santiago Blum de Aguiar,
  Pranit Bauva, Ray Zhang, René Nyffenegger, Santiago Torres,
  Saurav Sachidanand, Shin Kojima, Sidhant Sharma [:tk], Stanislav
  Kolotinskiy, and Xiaolong Ye.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  Adam Dinwoodie, Ævar Arnfjörð Bjarmason, Alexander Kuleshov,
  brian m. carlson, Brian Norris, Christian Couder, David Aguilar,
  David Turner, Dennis Kaarsemaker, Elia Pinto, Elijah Newren,
  Eric Sunshine, Eric Wong, Felipe Contreras, Jacob Keller,
  Jeff King, Jiang Xin, Johannes Schindelin, Johannes Sixt,
  John Keeping, Junio C Hamano, Karsten Blees, Lars Schneider,
  Linus Torvalds, Luke Diamand, Matthieu Moy, Michael Haggerty,
  Michael J Gruber, Michael Rappazzo, Nguyễn Thái Ngọc
  Duy, Ori Avtalion, Ralf Thielow, Ramsay Jones, René Scharfe,
  Stefan Beller, Stephen P. Smith, Sven Strickroth, SZEDER Gábor,
  Torsten Bögershausen, and Vasco Almeida.



Git 2.9 Release Notes (draft)
=

Backward compatibility notes


The end-user facing Porcelain level commands in the "git diff" and
"git log" family by default enable the rename detection; you can still
use "diff.renames" configuration variable to disable this.

Merging two branches that have no common ancestor with "git merge" is
by default forbidden now to prevent creating such an unusual merge by
mistake.

The output formats of "git log" that indents the commit log message by
4 spaces now expands HT in the log message by default.  You can use
the "--no-expand-tabs" option to disable this.

"git commit-tree" plumbing command required the user to always sign
its result when the user sets the commit.gpgsign configuration
variable, which was an ancient mistake, which this release corrects.
A script that drives commit-tree, if it relies on this mistake, now
needs to read commit.gpgsign and pass the -S option as necessary.


Updates since v2.8
--

UI, Workflows & Features

 * Comes with git-multimail 1.3.1 (in contrib/).

 * The end-user facing commands like "git diff" and "git log"
   now enable the rename detection by default.

 * The credential.helper configuration variable is cumulative and
   there is no good way to override it from the command line.  As
   a special case, giving an empty string as its value now serves
   as the signal to clear the values specified in various files.

 * A new "interactive.diffFilter" configuration can be used to
   customize the diff shown in "git add -i" sessions.

 * "git p4" now allows P4 author names to be mapped to Git author
   names.

 * "git rebase -x" can be used without passing "-i" option.

 * "git -c credential.= submodule" can now be used to
   propagate configuration variables related to credential helper
   down to the submodules.

 * "git tag" can create an annotated tag without explicitly given an
   "-a" (or "-s") option (i.e. when a tag message is given).  A new
   configuration variable, tag.forceSignAnnotated, can be used to tell
   the command to create signed tag in such a situation.

 * "git merge" used to allow merging two branches that have no common
   base by default, which led to a brand new history of an existing
   project created and then get pulled by an unsuspecting maintainer,
   which allowed an unnecessary parallel history merged into the
   existing project.  The command has been taught not to allow this by
   default, with an escape hatch "--allow-unrelated-histories" option
   to be used in a rare event that merges histories of two projects
   that started their lives independently.

 * "git pull" has been taught to pass the "--allow-unrelated-histories"
   option to underlying "git merge".

 * "git apply -v" learned to report paths in the patch that were
   skipped via --include/--exclude mechanism or being outside 

[ANNOUNCE] Git v2.8.4

[Junio C Hamano]

The latest maintenance release Git v2.8.4 is now available at
the usual places.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.8.4'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git



Git v2.8.4 Release Notes


Fixes since v2.8.3
--

 * Documentation for "git merge --verify-signatures" has been updated
   to clarify that the signature of only the commit at the tip is
   verified.  Also the phrasing used for signature and key validity is
   adjusted to align with that used by OpenPGP.

 * On Windows, .git and optionally any files whose name starts with a
   dot are now marked as hidden, with a core.hideDotFiles knob to
   customize this behaviour.

 * Portability enhancement for "rebase -i" to help platforms whose
   shell does not like "for i in " (which is not POSIX-kosher).

 * "git fsck" learned to catch NUL byte in a commit object as
   potential error and warn.

 * CI test was taught to build documentation pages.

 * Many 'linkgit:' references were broken,
   which are all fixed with this.

 * "git describe --contains" often made a hard-to-justify choice of
   tag to give name to a given commit, because it tried to come up
   with a name with smallest number of hops from a tag, causing an old
   commit whose close descendant that is recently tagged were not
   described with respect to an old tag but with a newer tag.  It did
   not help that its computation of "hop" count was further tweaked to
   penalize being on a side branch of a merge.  The logic has been
   updated to favor using the tag with the oldest tagger date, which
   is a lot easier to explain to the end users: "We describe a commit
   in terms of the (chronologically) oldest tag that contains the
   commit."

 * Running tests with '-x' option to trace the individual command
   executions is a useful way to debug test scripts, but some tests
   that capture the standard error stream and check what the command
   said can be broken with the trace output mixed in.  When running
   our tests under "bash", however, we can redirect the trace output
   to another file descriptor to keep the standard error of programs
   being tested intact.

 * "http.cookieFile" configuration variable clearly wants a pathname,
   but we forgot to treat it as such by e.g. applying tilde expansion.

 * When de-initialising all submodules, "git submodule deinit" gave a
   faulty recommendation to use "git submodule deinit .", which would
   result in a strange error message in a pathological corner case.
   This has been corrected to suggest "submodule deinit --all" instead.

 * Many commands normalize command line arguments from NFD to NFC
   variant of UTF-8 on OSX, but commands in the "diff" family did
   not, causing "git diff $path" to complain that no such path is
   known to Git.  They have been taught to do the normalization.

 * A couple of bugs around core.autocrlf have been fixed.

 * "git difftool" learned to handle unmerged paths correctly in
   dir-diff mode.

 * The "are we talking with TTY, doing an interactive session?"
   detection has been updated to work better for "Git for Windows".


Also contains other minor documentation updates and code clean-ups.



Changes since v2.8.3 are as follows:

Alexander Rinass (1):
  diff: run arguments through precompose_argv

Armin Kunaschik (1):
  t4151: make sure argument to 'test -z' is given

Brian Norris (3):
  Documentation: config: improve word ordering for http.cookieFile
  http: expand http.cookieFile as a path
  config: consistently format $variables in monospaced font

David Aguilar (2):
  difftool: initialize variables for readability
  difftool: handle unmerged files in dir-diff mode

Jeff King (3):
  rebase--interactive: avoid empty list in shell for-loop
  test-lib: set BASH_XTRACEFD automatically
  archive-tar: convert snprintf to xsnprintf

Johannes Schindelin (3):
  name-rev: include taggerdate in considering the best name
  mingw: introduce the 'core.hideDotFiles' setting
  mingw: remove unnecessary definition

Junio C Hamano (9):
  fsck_commit_buffer(): do not special case the last validation
  config: describe 'pathname' value type
  test-lib-functions.sh: remove misleading comment on test_seq
  test-lib-functions.sh: rewrite test_seq without Perl
  Documentation: fix linkgit references
  fsck: detect and warn a commit with embedded NUL
  Start preparing for 2.8.4
  More topics for 2.8.4

[PATCH v2] cpu/hotplug: handle unbalanced hotplug enable/disable

[Lianwei Wang]

Currently it just print a warning message but did not
reset cpu_hotplug_disabled when the enable/disable is
unbalanced. The unbalanced enable/disable will lead
the cpu hotplug work abnormally.

Do nothing if an unablanced hotplug enable detected.

Signed-off-by: Lianwei Wang 
---
 kernel/cpu.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 3e3f6e49eabb..8011b1e40523 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -245,6 +245,19 @@ void cpu_hotplug_done(void)
cpuhp_lock_release();
 }
 
+static void _cpu_hotplug_disable(void)
+{
+   cpu_hotplug_disabled++;
+}
+
+static void _cpu_hotplug_enable(void)
+{
+   if (WARN(!cpu_hotplug_disabled, "Unbalanced cpu hotplug enable\n"))
+   return;
+
+   cpu_hotplug_disabled--;
+}
+
 /*
  * Wait for currently running CPU hotplug operations to complete (if any) and
  * disable future CPU hotplug (from sysfs). The 'cpu_add_remove_lock' protects
@@ -255,7 +268,7 @@ void cpu_hotplug_done(void)
 void cpu_hotplug_disable(void)
 {
cpu_maps_update_begin();
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
@@ -263,7 +276,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
 void cpu_hotplug_enable(void)
 {
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
@@ -1071,7 +1084,7 @@ int disable_nonboot_cpus(void)
 * this even in case of failure as all disable_nonboot_cpus() users are
 * supposed to do enable_nonboot_cpus() on the failure path.
 */
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
 
cpu_maps_update_done();
return error;
@@ -1091,7 +1104,7 @@ void enable_nonboot_cpus(void)
 
/* Allow everyone to use the CPU hotplug again */
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
if (cpumask_empty(frozen_cpus))
goto out;
 
-- 
1.9.1

[PATCH v2] cpu/hotplug: handle unbalanced hotplug enable/disable

[Lianwei Wang]

Currently it just print a warning message but did not
reset cpu_hotplug_disabled when the enable/disable is
unbalanced. The unbalanced enable/disable will lead
the cpu hotplug work abnormally.

Do nothing if an unablanced hotplug enable detected.

Signed-off-by: Lianwei Wang 
---
 kernel/cpu.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 3e3f6e49eabb..8011b1e40523 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -245,6 +245,19 @@ void cpu_hotplug_done(void)
cpuhp_lock_release();
 }
 
+static void _cpu_hotplug_disable(void)
+{
+   cpu_hotplug_disabled++;
+}
+
+static void _cpu_hotplug_enable(void)
+{
+   if (WARN(!cpu_hotplug_disabled, "Unbalanced cpu hotplug enable\n"))
+   return;
+
+   cpu_hotplug_disabled--;
+}
+
 /*
  * Wait for currently running CPU hotplug operations to complete (if any) and
  * disable future CPU hotplug (from sysfs). The 'cpu_add_remove_lock' protects
@@ -255,7 +268,7 @@ void cpu_hotplug_done(void)
 void cpu_hotplug_disable(void)
 {
cpu_maps_update_begin();
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
@@ -263,7 +276,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
 void cpu_hotplug_enable(void)
 {
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
cpu_maps_update_done();
 }
 EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
@@ -1071,7 +1084,7 @@ int disable_nonboot_cpus(void)
 * this even in case of failure as all disable_nonboot_cpus() users are
 * supposed to do enable_nonboot_cpus() on the failure path.
 */
-   cpu_hotplug_disabled++;
+   _cpu_hotplug_disable();
 
cpu_maps_update_done();
return error;
@@ -1091,7 +1104,7 @@ void enable_nonboot_cpus(void)
 
/* Allow everyone to use the CPU hotplug again */
cpu_maps_update_begin();
-   WARN_ON(--cpu_hotplug_disabled < 0);
+   _cpu_hotplug_enable();
if (cpumask_empty(frozen_cpus))
goto out;
 
-- 
1.9.1

Re: [PATCH v2 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

[Tony Lindgren]

* Tomi Valkeinen  [160603 03:53]:
> 
> 
> On 02/06/16 18:23, Tony Lindgren wrote:
> > * Tomi Valkeinen  [160602 05:28]:
> >>
> >> Tony, can you have a look at the arch/arm parts here and give your ack
> >> if they're fine? They should be quite small and display specific, so I
> >> don't see much chance for conflict there.
> > 
> > Looks good to me, but these are going to conflict with the board-*.c
> > removal patches. And those we want to have easily revertable in case
> > of issues.
> > 
> > Peter, can you do an immutable minimal branch of just the pdata
> > changes affecting the board-*.c files? That way both Tomi and I
> > can merge that in.
> 
> I wonder how minimal it can be, as I think most of the patches are
> needed for pdata changes. Well, Peter can tell better.

Looks like Peter's new series deals with it just fine.

> What board changes do you expect for the next merge window? If it's just
> "git rm boardfile.c", that should be an easy conflict to resolve, right?

Trivial but no need to create these merge conflicts here.

Regards,

Tony

Re: [PATCH v2 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

[Tony Lindgren]

* Tomi Valkeinen  [160603 03:53]:
> 
> 
> On 02/06/16 18:23, Tony Lindgren wrote:
> > * Tomi Valkeinen  [160602 05:28]:
> >>
> >> Tony, can you have a look at the arch/arm parts here and give your ack
> >> if they're fine? They should be quite small and display specific, so I
> >> don't see much chance for conflict there.
> > 
> > Looks good to me, but these are going to conflict with the board-*.c
> > removal patches. And those we want to have easily revertable in case
> > of issues.
> > 
> > Peter, can you do an immutable minimal branch of just the pdata
> > changes affecting the board-*.c files? That way both Tomi and I
> > can merge that in.
> 
> I wonder how minimal it can be, as I think most of the patches are
> needed for pdata changes. Well, Peter can tell better.

Looks like Peter's new series deals with it just fine.

> What board changes do you expect for the next merge window? If it's just
> "git rm boardfile.c", that should be an easy conflict to resolve, right?

Trivial but no need to create these merge conflicts here.

Regards,

Tony

Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

[Boris Brezillon]

On Mon, 6 Jun 2016 22:31:38 +0200
Boris Brezillon  wrote:

> On Mon, 6 Jun 2016 22:59:03 +0300
> Aleksei Mamlin  wrote:
> 
> > On Mon, 6 Jun 2016 20:55:49 +0200
> > Boris Brezillon  wrote:
> >   
> > > On Mon,  6 Jun 2016 13:24:22 +0300
> > > Aleksei Mamlin  wrote:
> > > 
> > > > Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> > > > nand_ids table so that we can later use the NAND ECC infos and ONFI 
> > > > timings
> > > > mode in controller drivers.
> > > 
> > > Still hoping to get this series [1] merged in 4.8, but if that's
> > > not the case, I'll apply your patch.
> > > 
> > > BTW, that would be great if you could test it on your platforms.
> > > 
> > 
> > It seems that Hynix-specific initialization code can't handle 
> > H27UBG8T2BTR-BC
> > chip:
> > 
> > [0.886153] nand: Could not find valid ONFI parameter page; aborting
> > [0.892665] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> > [0.899025] nand: Hynix 1c03000.nand
> > [0.902596] nand: bus width 8 instead 16 bit
> > [0.906858] nand: No NAND device found
> > [0.910620] sunxi_nand 1c03000.nand: failed to init nand chips
> > [0.916528] sunxi_nand: probe of 1c03000.nand failed with error -22  
> 
> Can you try this patch? It should fix the problem [1].

Brian, I have a question regarding the extended NAND ids (not full-ids)
defined in the nand_ids table. Are they really valid for all vendors?

If that's the case, why are we extracting the bus width from the id[3]
since we already have this information in the options field?

> 
> [1]http://code.bulix.org/6hjww1-100494
> 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

[Boris Brezillon]

On Mon, 6 Jun 2016 22:31:38 +0200
Boris Brezillon  wrote:

> On Mon, 6 Jun 2016 22:59:03 +0300
> Aleksei Mamlin  wrote:
> 
> > On Mon, 6 Jun 2016 20:55:49 +0200
> > Boris Brezillon  wrote:
> >   
> > > On Mon,  6 Jun 2016 13:24:22 +0300
> > > Aleksei Mamlin  wrote:
> > > 
> > > > Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> > > > nand_ids table so that we can later use the NAND ECC infos and ONFI 
> > > > timings
> > > > mode in controller drivers.
> > > 
> > > Still hoping to get this series [1] merged in 4.8, but if that's
> > > not the case, I'll apply your patch.
> > > 
> > > BTW, that would be great if you could test it on your platforms.
> > > 
> > 
> > It seems that Hynix-specific initialization code can't handle 
> > H27UBG8T2BTR-BC
> > chip:
> > 
> > [0.886153] nand: Could not find valid ONFI parameter page; aborting
> > [0.892665] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> > [0.899025] nand: Hynix 1c03000.nand
> > [0.902596] nand: bus width 8 instead 16 bit
> > [0.906858] nand: No NAND device found
> > [0.910620] sunxi_nand 1c03000.nand: failed to init nand chips
> > [0.916528] sunxi_nand: probe of 1c03000.nand failed with error -22  
> 
> Can you try this patch? It should fix the problem [1].

Brian, I have a question regarding the extended NAND ids (not full-ids)
defined in the nand_ids table. Are they really valid for all vendors?

If that's the case, why are we extracting the bus width from the id[3]
since we already have this information in the options field?

> 
> [1]http://code.bulix.org/6hjww1-100494
> 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

[Boris Brezillon]

On Tue, 7 Jun 2016 00:06:45 +0300
Aleksei Mamlin  wrote:

> On Mon, 6 Jun 2016 22:31:38 +0200
> Boris Brezillon  wrote:
> 
> > On Mon, 6 Jun 2016 22:59:03 +0300
> > Aleksei Mamlin  wrote:
> >   
> > > On Mon, 6 Jun 2016 20:55:49 +0200
> > > Boris Brezillon  wrote:
> > >   
> > > > On Mon,  6 Jun 2016 13:24:22 +0300
> > > > Aleksei Mamlin  wrote:
> > > > 
> > > > > Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> > > > > nand_ids table so that we can later use the NAND ECC infos and ONFI 
> > > > > timings
> > > > > mode in controller drivers.
> > > > 
> > > > Still hoping to get this series [1] merged in 4.8, but if that's
> > > > not the case, I'll apply your patch.
> > > > 
> > > > BTW, that would be great if you could test it on your platforms.
> > > > 
> > > 
> > > It seems that Hynix-specific initialization code can't handle 
> > > H27UBG8T2BTR-BC
> > > chip:
> > > 
> > > [0.886153] nand: Could not find valid ONFI parameter page; aborting
> > > [0.892665] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> > > [0.899025] nand: Hynix 1c03000.nand
> > > [0.902596] nand: bus width 8 instead 16 bit
> > > [0.906858] nand: No NAND device found
> > > [0.910620] sunxi_nand 1c03000.nand: failed to init nand chips
> > > [0.916528] sunxi_nand: probe of 1c03000.nand failed with error -22  
> > 
> > Can you try this patch? It should fix the problem [1].
> > 
> > [1]http://code.bulix.org/6hjww1-100494
> >   
> 
> Yes, it fixes problem. What about ONFI parameter page? Should it be ignored?

It should be ignored: your NAND is not 'ONFI compatible', the datasheet
just says that it supports the' ONFI command set', which is not the
same :).
The trace you're seeing here is just notifying that the core failed to
detect an ONFI NAND, which is expected in your case.

> [0.886068] nand: Could not find valid ONFI parameter page; aborting
> [0.892571] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> [0.898917] nand: Hynix NAND 4GiB 3,3V 8-bit
> [0.903198] nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, 
> OOB size: 640
> [0.911908] Bad block table found at page 524032, version 0x01
> [0.918534] Bad block table found at page 523776, version 0x01
> [0.972112] 5 ofpart partitions found on MTD device 1c03000.nand
> [0.978116] Creating 5 MTD partitions on "1c03000.nand":
> [0.983477] 0x-0x0020 : "boot0"
> [0.988803] 0x0020-0x0040 : "boot0-rescue"
> [0.994692] 0x0040-0x0060 : "uboot"
> [0.44] 0x0060-0x0080 : "uboot-rescue"
> [1.005763] 0x0080-0x0001 : "main"
> 
> > 
> > -- 
> > Boris Brezillon, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com  
> 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 5/7] mtd: nand: Add Hynix H27UBG8T2BTR-BC to nand_ids table

[Boris Brezillon]

On Tue, 7 Jun 2016 00:06:45 +0300
Aleksei Mamlin  wrote:

> On Mon, 6 Jun 2016 22:31:38 +0200
> Boris Brezillon  wrote:
> 
> > On Mon, 6 Jun 2016 22:59:03 +0300
> > Aleksei Mamlin  wrote:
> >   
> > > On Mon, 6 Jun 2016 20:55:49 +0200
> > > Boris Brezillon  wrote:
> > >   
> > > > On Mon,  6 Jun 2016 13:24:22 +0300
> > > > Aleksei Mamlin  wrote:
> > > > 
> > > > > Add the full description of the Hynix H27UBG8T2BTR-BC NAND chip in the
> > > > > nand_ids table so that we can later use the NAND ECC infos and ONFI 
> > > > > timings
> > > > > mode in controller drivers.
> > > > 
> > > > Still hoping to get this series [1] merged in 4.8, but if that's
> > > > not the case, I'll apply your patch.
> > > > 
> > > > BTW, that would be great if you could test it on your platforms.
> > > > 
> > > 
> > > It seems that Hynix-specific initialization code can't handle 
> > > H27UBG8T2BTR-BC
> > > chip:
> > > 
> > > [0.886153] nand: Could not find valid ONFI parameter page; aborting
> > > [0.892665] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> > > [0.899025] nand: Hynix 1c03000.nand
> > > [0.902596] nand: bus width 8 instead 16 bit
> > > [0.906858] nand: No NAND device found
> > > [0.910620] sunxi_nand 1c03000.nand: failed to init nand chips
> > > [0.916528] sunxi_nand: probe of 1c03000.nand failed with error -22  
> > 
> > Can you try this patch? It should fix the problem [1].
> > 
> > [1]http://code.bulix.org/6hjww1-100494
> >   
> 
> Yes, it fixes problem. What about ONFI parameter page? Should it be ignored?

It should be ignored: your NAND is not 'ONFI compatible', the datasheet
just says that it supports the' ONFI command set', which is not the
same :).
The trace you're seeing here is just notifying that the core failed to
detect an ONFI NAND, which is expected in your case.

> [0.886068] nand: Could not find valid ONFI parameter page; aborting
> [0.892571] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
> [0.898917] nand: Hynix NAND 4GiB 3,3V 8-bit
> [0.903198] nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, 
> OOB size: 640
> [0.911908] Bad block table found at page 524032, version 0x01
> [0.918534] Bad block table found at page 523776, version 0x01
> [0.972112] 5 ofpart partitions found on MTD device 1c03000.nand
> [0.978116] Creating 5 MTD partitions on "1c03000.nand":
> [0.983477] 0x-0x0020 : "boot0"
> [0.988803] 0x0020-0x0040 : "boot0-rescue"
> [0.994692] 0x0040-0x0060 : "uboot"
> [0.44] 0x0060-0x0080 : "uboot-rescue"
> [1.005763] 0x0080-0x0001 : "main"
> 
> > 
> > -- 
> > Boris Brezillon, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com  
> 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v1] PM / sleep: make pm notifier called symmetrically

[Lianwei Wang]

On Wed, May 18, 2016 at 11:06 PM, Lianwei Wang  wrote:
> On Wed, May 18, 2016 at 1:34 PM, Rafael J. Wysocki  wrote:
>> On Wed, May 18, 2016 at 8:07 AM, Lianwei Wang  wrote:
>>> This makes pm notifier PREPARE/POST symmetrical: if PREPARE
>>> fails, we will only undo what ever happened on PREPARE.
>>>
>>> It fixes the unbalanced cpu hotplug enable in cpu pm notifier.
>>
>> Can you please describe the problem you're trying to address in a bit
>> more detail?
>
> It is described in another patch, and it is a common issue. I fixed
> the similar issue several times, all because that the CPU_POST_SUSPEND
> notifier callback is called without call CPU_SUSPEND_PREPARE notifier
> callback before. Something is DO in PM_XXX_PREPARE and UNDO in
> POST_XXX. If we don't DO it in XXX_PREPARE then we don't need to UNDO
> it in  PM_POST_XXX.
>
> Here is the link for the unbalanced cpu hotplug enable case:
> https://lkml.org/lkml/2016/5/6/61 .
>
> Thanks,
> Lianwei

Did anyone from the maintainer review the patch yet?

Re: [PATCH v1] PM / sleep: make pm notifier called symmetrically

[Lianwei Wang]

On Wed, May 18, 2016 at 11:06 PM, Lianwei Wang  wrote:
> On Wed, May 18, 2016 at 1:34 PM, Rafael J. Wysocki  wrote:
>> On Wed, May 18, 2016 at 8:07 AM, Lianwei Wang  wrote:
>>> This makes pm notifier PREPARE/POST symmetrical: if PREPARE
>>> fails, we will only undo what ever happened on PREPARE.
>>>
>>> It fixes the unbalanced cpu hotplug enable in cpu pm notifier.
>>
>> Can you please describe the problem you're trying to address in a bit
>> more detail?
>
> It is described in another patch, and it is a common issue. I fixed
> the similar issue several times, all because that the CPU_POST_SUSPEND
> notifier callback is called without call CPU_SUSPEND_PREPARE notifier
> callback before. Something is DO in PM_XXX_PREPARE and UNDO in
> POST_XXX. If we don't DO it in XXX_PREPARE then we don't need to UNDO
> it in  PM_POST_XXX.
>
> Here is the link for the unbalanced cpu hotplug enable case:
> https://lkml.org/lkml/2016/5/6/61 .
>
> Thanks,
> Lianwei

Did anyone from the maintainer review the patch yet?

Re: [PATCH] cpu/hotplug: handle unbalanced hotplug enable/disable

[Lianwei Wang]

On Thu, May 12, 2016 at 1:06 AM, Lianwei Wang  wrote:
> I have come up a patch to make the pm notifier called symmetrically
> and currently being tested. I will send it out after pass the test.
>
> On Fri, May 6, 2016 at 12:18 AM, Thomas Gleixner  wrote:
>> On Fri, 6 May 2016, Lianwei Wang wrote:
>>> On Thu, May 5, 2016 at 5:13 AM, Thomas Gleixner  wrote:
>>> > Can you eventually come up with a coherent explanation of the problem 
>>> > down to
>>> > the root cause or are we going to play this "move the workaround one step
>>> > down" game for another 10 rounds?
>>> >
>>> Do you agree that any driver can abort the suspend process by
>>> returning an error or NOTIFY_BAD if it is not ready to suspend?
>>> I have explain it and I also copied the example code that abort
>>> suspend by returning an error or NOTIFY_BAD in the pm notifier
>>> callback function.
>>
>> I don't need copied example code which does not tell me what the real problem
>> is.
>>
>>> The cpu_hotplug_disable and cpu_hotplug_enable are called in one of
>>> the PM notifier callback. And they are called from two difference
>>> place.
>>> Below is how it happened:
>>>   pm_suspend
>>> |--enter_state
>>> |--suspend_prepare
>>> |--pm_notifier_call_chain(PM_SUSPEND_PREPARE)
>>> ||--call_back_1
>>> ||--call_back_..
>>> ||--call_back_n ===> return NOTIFY_BAD to abort call chain 
>>> and
>>> ||suspend process here
>>> ||--cpu_hotplug_pm_callback()
>>> ||   |--cpu_hotplug_disable  => remember it is not
>>> called yet
>>> ||--call_back_..
>>> |
>>> |--pm_notifier_call_chain(PM_POST_SUSPEND)
>>> ||--call_back_1
>>> ||--call_back_..
>>> ||--call_back_n
>>> ||--cpu_hotplug_pm_callback()
>>> ||   |--cpu_hotplug_enable  => Here it is unbalanced 
>>> called
>>> ||--call_back_..
>>> |
>>> So, keep in mind that for pm notifier call chain, the
>>> PM_SUSPEND_PREPARE notifier and PM_POST_SUSPEND notifier is not always
>>> paired called. Sometimes for a driver's pm notifier callback, the
>>> PM_POST_SUSPEND is called without PM_SUSPEND_PREPARE.
>>
>> So that is the real problem: cpu_hotplug_pm_callback(PM_POST_SUSPEND) can be
>> called w/o a previous call to cpu_hotplug_pm_callback(PM_SUSPEND_PREPARE).
>>
>>> > It cannot prevent any unbalanced calls. It mitigates the issue, but 
>>> > that's a
>>> > different problem.
>>> It did not migrate the issue. It give a warning message to log the
>>> unbalanced issue and it also make sure the cpu hotplug continue to
>>> work well even someone do an unbalanced call. It is a good checking as
>>> the enable_irq/disable_irq do. There are some other unbalanced
>>> checking in kernel too. All make sure the kernel has a better
>>> stability.
>>
>> I'm not opposed to do that and I said so several times. But I said as well,
>> that we do not add this without fixing the problem which made you write that
>> patch in the first place.
>>
>> So we have a proper explanation for the real problem now, but we have no
>> fix.
>>
>> And again: Your patch is NOT a fix. Simply because it will emit a warning
>> everytime the above happens. And that's wrong because the abort is a
>> legitimate scenario.
>>
>> So please come up with a sensible fix for the suspend abort issue and then we
>> can add the balance check/fixup to the hotplug_disable/enable() code.
>>
>> Thanks,
>>
>> tglx
>>
>>

I think this is the best solution to fix this unbalanced issue for now.

Re: [PATCH] cpu/hotplug: handle unbalanced hotplug enable/disable

[Lianwei Wang]

On Thu, May 12, 2016 at 1:06 AM, Lianwei Wang  wrote:
> I have come up a patch to make the pm notifier called symmetrically
> and currently being tested. I will send it out after pass the test.
>
> On Fri, May 6, 2016 at 12:18 AM, Thomas Gleixner  wrote:
>> On Fri, 6 May 2016, Lianwei Wang wrote:
>>> On Thu, May 5, 2016 at 5:13 AM, Thomas Gleixner  wrote:
>>> > Can you eventually come up with a coherent explanation of the problem 
>>> > down to
>>> > the root cause or are we going to play this "move the workaround one step
>>> > down" game for another 10 rounds?
>>> >
>>> Do you agree that any driver can abort the suspend process by
>>> returning an error or NOTIFY_BAD if it is not ready to suspend?
>>> I have explain it and I also copied the example code that abort
>>> suspend by returning an error or NOTIFY_BAD in the pm notifier
>>> callback function.
>>
>> I don't need copied example code which does not tell me what the real problem
>> is.
>>
>>> The cpu_hotplug_disable and cpu_hotplug_enable are called in one of
>>> the PM notifier callback. And they are called from two difference
>>> place.
>>> Below is how it happened:
>>>   pm_suspend
>>> |--enter_state
>>> |--suspend_prepare
>>> |--pm_notifier_call_chain(PM_SUSPEND_PREPARE)
>>> ||--call_back_1
>>> ||--call_back_..
>>> ||--call_back_n ===> return NOTIFY_BAD to abort call chain 
>>> and
>>> ||suspend process here
>>> ||--cpu_hotplug_pm_callback()
>>> ||   |--cpu_hotplug_disable  => remember it is not
>>> called yet
>>> ||--call_back_..
>>> |
>>> |--pm_notifier_call_chain(PM_POST_SUSPEND)
>>> ||--call_back_1
>>> ||--call_back_..
>>> ||--call_back_n
>>> ||--cpu_hotplug_pm_callback()
>>> ||   |--cpu_hotplug_enable  => Here it is unbalanced 
>>> called
>>> ||--call_back_..
>>> |
>>> So, keep in mind that for pm notifier call chain, the
>>> PM_SUSPEND_PREPARE notifier and PM_POST_SUSPEND notifier is not always
>>> paired called. Sometimes for a driver's pm notifier callback, the
>>> PM_POST_SUSPEND is called without PM_SUSPEND_PREPARE.
>>
>> So that is the real problem: cpu_hotplug_pm_callback(PM_POST_SUSPEND) can be
>> called w/o a previous call to cpu_hotplug_pm_callback(PM_SUSPEND_PREPARE).
>>
>>> > It cannot prevent any unbalanced calls. It mitigates the issue, but 
>>> > that's a
>>> > different problem.
>>> It did not migrate the issue. It give a warning message to log the
>>> unbalanced issue and it also make sure the cpu hotplug continue to
>>> work well even someone do an unbalanced call. It is a good checking as
>>> the enable_irq/disable_irq do. There are some other unbalanced
>>> checking in kernel too. All make sure the kernel has a better
>>> stability.
>>
>> I'm not opposed to do that and I said so several times. But I said as well,
>> that we do not add this without fixing the problem which made you write that
>> patch in the first place.
>>
>> So we have a proper explanation for the real problem now, but we have no
>> fix.
>>
>> And again: Your patch is NOT a fix. Simply because it will emit a warning
>> everytime the above happens. And that's wrong because the abort is a
>> legitimate scenario.
>>
>> So please come up with a sensible fix for the suspend abort issue and then we
>> can add the balance check/fixup to the hotplug_disable/enable() code.
>>
>> Thanks,
>>
>> tglx
>>
>>

I think this is the best solution to fix this unbalanced issue for now.

Re: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode

[Vinod Koul]

On Mon, Apr 25, 2016 at 02:18:05PM +0530, Kedareswara rao Appana wrote:
> This patch updates the dmatest client to support
> scatter-gather dma mode.
> 
> Signed-off-by: Kedareswara rao Appana 
> ---
>  drivers/dma/dmatest.c | 38 --
>  1 file changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> index b8576fd..6f259d8 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -51,6 +51,14 @@ module_param(iterations, uint, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(iterations,
>   "Iterations before stopping test (default: infinite)");
>  
> +static unsigned int sg_sources = 1;
> +module_param(sg_sources, uint, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(sg_sources,

sg_buffers rather?

> + "Number of scatter gather buffers (default: 1)");

blank line please

> +static unsigned int dmatest = 1;
> +module_param(dmatest, uint, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(dmatest,
> + "dmatest 0-memcpy 1-slave_sg (default: 1)");

dmatest? What does this mean!

>  static unsigned int xor_sources = 3;
>  module_param(xor_sources, uint, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(xor_sources,
> @@ -431,6 +439,8 @@ static int dmatest_func(void *data)
>   dev = chan->device;
>   if (thread->type == DMA_MEMCPY)
>   src_cnt = dst_cnt = 1;
> + else if (thread->type == DMA_SG)
> + src_cnt = dst_cnt = sg_sources;
>   else if (thread->type == DMA_XOR) {
>   /* force odd to ensure dst = src */
>   src_cnt = min_odd(params->xor_sources | 1, dev->max_xor);
> @@ -485,6 +495,8 @@ static int dmatest_func(void *data)
>   dma_addr_t *dsts;
>   unsigned int src_off, dst_off, len;
>   u8 align = 0;
> + struct scatterlist tx_sg[src_cnt];
> + struct scatterlist rx_sg[src_cnt];
>  
>   total_tests++;
>  
> @@ -577,10 +589,21 @@ static int dmatest_func(void *data)
>   um->bidi_cnt++;
>   }
>  
> + sg_init_table(tx_sg, src_cnt);
> + sg_init_table(rx_sg, dst_cnt);

why dst_cnt  here wheras you used src_cnt to create the list!

> + for (i = 0; i < src_cnt; i++) {
> + sg_dma_address(_sg[i]) = srcs[i];
> + sg_dma_address(_sg[i]) = dsts[i] + dst_off;
> + sg_dma_len(_sg[i]) = len;
> + sg_dma_len(_sg[i]) = len;
> + }
>   if (thread->type == DMA_MEMCPY)
>   tx = dev->device_prep_dma_memcpy(chan,
>dsts[0] + dst_off,
>srcs[0], len, flags);
> + else if (thread->type == DMA_SG)
> + tx = dev->device_prep_dma_sg(chan, tx_sg,
> + dst_cnt, rx_sg, src_cnt, flags);

again dst_cnt

>   else if (thread->type == DMA_XOR)
>   tx = dev->device_prep_dma_xor(chan,
> dsts[0] + dst_off,
> @@ -748,6 +771,8 @@ static int dmatest_add_threads(struct dmatest_info *info,
>  
>   if (type == DMA_MEMCPY)
>   op = "copy";
> + else if (type == DMA_SG)
> + op = "sg";
>   else if (type == DMA_XOR)
>   op = "xor";
>   else if (type == DMA_PQ)
> @@ -802,8 +827,16 @@ static int dmatest_add_channel(struct dmatest_info *info,
>   INIT_LIST_HEAD(>threads);
>  
>   if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask)) {
> - cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
> - thread_count += cnt > 0 ? cnt : 0;
> + if (dmatest == 0) {
> + cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
> + thread_count += cnt > 0 ? cnt : 0;
> + }
> + }

blank line

-- 
~Vinod

Re: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode

[Vinod Koul]

On Mon, Apr 25, 2016 at 02:18:05PM +0530, Kedareswara rao Appana wrote:
> This patch updates the dmatest client to support
> scatter-gather dma mode.
> 
> Signed-off-by: Kedareswara rao Appana 
> ---
>  drivers/dma/dmatest.c | 38 --
>  1 file changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> index b8576fd..6f259d8 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -51,6 +51,14 @@ module_param(iterations, uint, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(iterations,
>   "Iterations before stopping test (default: infinite)");
>  
> +static unsigned int sg_sources = 1;
> +module_param(sg_sources, uint, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(sg_sources,

sg_buffers rather?

> + "Number of scatter gather buffers (default: 1)");

blank line please

> +static unsigned int dmatest = 1;
> +module_param(dmatest, uint, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(dmatest,
> + "dmatest 0-memcpy 1-slave_sg (default: 1)");

dmatest? What does this mean!

>  static unsigned int xor_sources = 3;
>  module_param(xor_sources, uint, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(xor_sources,
> @@ -431,6 +439,8 @@ static int dmatest_func(void *data)
>   dev = chan->device;
>   if (thread->type == DMA_MEMCPY)
>   src_cnt = dst_cnt = 1;
> + else if (thread->type == DMA_SG)
> + src_cnt = dst_cnt = sg_sources;
>   else if (thread->type == DMA_XOR) {
>   /* force odd to ensure dst = src */
>   src_cnt = min_odd(params->xor_sources | 1, dev->max_xor);
> @@ -485,6 +495,8 @@ static int dmatest_func(void *data)
>   dma_addr_t *dsts;
>   unsigned int src_off, dst_off, len;
>   u8 align = 0;
> + struct scatterlist tx_sg[src_cnt];
> + struct scatterlist rx_sg[src_cnt];
>  
>   total_tests++;
>  
> @@ -577,10 +589,21 @@ static int dmatest_func(void *data)
>   um->bidi_cnt++;
>   }
>  
> + sg_init_table(tx_sg, src_cnt);
> + sg_init_table(rx_sg, dst_cnt);

why dst_cnt  here wheras you used src_cnt to create the list!

> + for (i = 0; i < src_cnt; i++) {
> + sg_dma_address(_sg[i]) = srcs[i];
> + sg_dma_address(_sg[i]) = dsts[i] + dst_off;
> + sg_dma_len(_sg[i]) = len;
> + sg_dma_len(_sg[i]) = len;
> + }
>   if (thread->type == DMA_MEMCPY)
>   tx = dev->device_prep_dma_memcpy(chan,
>dsts[0] + dst_off,
>srcs[0], len, flags);
> + else if (thread->type == DMA_SG)
> + tx = dev->device_prep_dma_sg(chan, tx_sg,
> + dst_cnt, rx_sg, src_cnt, flags);

again dst_cnt

>   else if (thread->type == DMA_XOR)
>   tx = dev->device_prep_dma_xor(chan,
> dsts[0] + dst_off,
> @@ -748,6 +771,8 @@ static int dmatest_add_threads(struct dmatest_info *info,
>  
>   if (type == DMA_MEMCPY)
>   op = "copy";
> + else if (type == DMA_SG)
> + op = "sg";
>   else if (type == DMA_XOR)
>   op = "xor";
>   else if (type == DMA_PQ)
> @@ -802,8 +827,16 @@ static int dmatest_add_channel(struct dmatest_info *info,
>   INIT_LIST_HEAD(>threads);
>  
>   if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask)) {
> - cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
> - thread_count += cnt > 0 ? cnt : 0;
> + if (dmatest == 0) {
> + cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
> + thread_count += cnt > 0 ? cnt : 0;
> + }
> + }

blank line

-- 
~Vinod

Re: powerpc/nvram: Fix an incorrect partition merge

[Stewart Smith]

xinhui  writes:
>> Has it always been broken?
>>
>
> no. after nvram partition corruption hit, all nvram partitions will be
> erased and re-alloc after the second machine reboot.
> I don't know who does it but i guess it is the firmware. :)

It is. PAPR says we format NVRAM when it's corrupted. This is also true
for NVRAM for PowerNV (not just pseries guest).

-- 
Stewart Smith
OPAL Architect, IBM.

Re: powerpc/nvram: Fix an incorrect partition merge

[Stewart Smith]

xinhui  writes:
>> Has it always been broken?
>>
>
> no. after nvram partition corruption hit, all nvram partitions will be
> erased and re-alloc after the second machine reboot.
> I don't know who does it but i guess it is the firmware. :)

It is. PAPR says we format NVRAM when it's corrupted. This is also true
for NVRAM for PowerNV (not just pseries guest).

-- 
Stewart Smith
OPAL Architect, IBM.

Re: [PATCH] iio: light: tcs3472: use iio helper function to guarantee direct mode

[Peter Meerwald-Stadler]

On Mon, 6 Jun 2016, Alison Schofield wrote:

> Replace the code that guarantees the device stays in direct mode
> with iio_device_claim_direct_mode() which does same.  This allows
> removal of an unused lock in the device private global data.

Acked-by: Peter Meerwald-Stadler 
 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/light/tcs3472.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c
> index 1b530bf..b29312f 100644
> --- a/drivers/iio/light/tcs3472.c
> +++ b/drivers/iio/light/tcs3472.c
> @@ -52,7 +52,6 @@
>  
>  struct tcs3472_data {
>   struct i2c_client *client;
> - struct mutex lock;
>   u8 enable;
>   u8 control;
>   u8 atime;
> @@ -117,17 +116,16 @@ static int tcs3472_read_raw(struct iio_dev *indio_dev,
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> - if (iio_buffer_enabled(indio_dev))
> - return -EBUSY;
> -
> - mutex_lock(>lock);
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
>   ret = tcs3472_req_data(data);
>   if (ret < 0) {
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   return ret;
>   }
>   ret = i2c_smbus_read_word_data(data->client, chan->address);
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   if (ret < 0)
>   return ret;
>   *val = ret;
> @@ -263,7 +261,6 @@ static int tcs3472_probe(struct i2c_client *client,
>   data = iio_priv(indio_dev);
>   i2c_set_clientdata(client, indio_dev);
>   data->client = client;
> - mutex_init(>lock);
>  
>   indio_dev->dev.parent = >dev;
>   indio_dev->info = _info;
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [PATCH] iio: light: tcs3472: use iio helper function to guarantee direct mode

[Peter Meerwald-Stadler]

On Mon, 6 Jun 2016, Alison Schofield wrote:

> Replace the code that guarantees the device stays in direct mode
> with iio_device_claim_direct_mode() which does same.  This allows
> removal of an unused lock in the device private global data.

Acked-by: Peter Meerwald-Stadler 
 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/light/tcs3472.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c
> index 1b530bf..b29312f 100644
> --- a/drivers/iio/light/tcs3472.c
> +++ b/drivers/iio/light/tcs3472.c
> @@ -52,7 +52,6 @@
>  
>  struct tcs3472_data {
>   struct i2c_client *client;
> - struct mutex lock;
>   u8 enable;
>   u8 control;
>   u8 atime;
> @@ -117,17 +116,16 @@ static int tcs3472_read_raw(struct iio_dev *indio_dev,
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> - if (iio_buffer_enabled(indio_dev))
> - return -EBUSY;
> -
> - mutex_lock(>lock);
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
>   ret = tcs3472_req_data(data);
>   if (ret < 0) {
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   return ret;
>   }
>   ret = i2c_smbus_read_word_data(data->client, chan->address);
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   if (ret < 0)
>   return ret;
>   *val = ret;
> @@ -263,7 +261,6 @@ static int tcs3472_probe(struct i2c_client *client,
>   data = iio_priv(indio_dev);
>   i2c_set_clientdata(client, indio_dev);
>   data->client = client;
> - mutex_init(>lock);
>  
>   indio_dev->dev.parent = >dev;
>   indio_dev->info = _info;
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

[PATCH net-next v2 4/4] arm64: bpf: optimize LD_ABS, LD_IND

[Zi Shen Lim]

Remove superfluous stack frame, saving us 3 instructions for every
LD_ABS or LD_IND.

Signed-off-by: Zi Shen Lim 
---
 arch/arm64/net/bpf_jit_comp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 7ae304e..b2fc97a 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -731,11 +731,8 @@ emit_cond_jmp:
emit_a64_mov_i64(r3, size, ctx);
emit(A64_SUB_I(1, r4, fp, STACK_SIZE), ctx);
emit_a64_mov_i64(r5, (unsigned long)bpf_load_pointer, ctx);
-   emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
-   emit(A64_MOV(1, A64_FP, A64_SP), ctx);
emit(A64_BLR(r5), ctx);
emit(A64_MOV(1, r0, A64_R(0)), ctx);
-   emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
 
jmp_offset = epilogue_offset(ctx);
check_imm19(jmp_offset);
-- 
1.9.1

[PATCH net-next v2 1/4] bpf: fix missing header inclusion

[Zi Shen Lim]

Commit 0fc174dea545 ("ebpf: make internal bpf API independent of
CONFIG_BPF_SYSCALL ifdefs") introduced usage of ERR_PTR() in
bpf_prog_get(), however did not include linux/err.h.

Without this patch, when compiling arm64 BPF without CONFIG_BPF_SYSCALL:
...
In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h: In function 'bpf_prog_get':
include/linux/bpf.h:235:9: error: implicit declaration of function 'ERR_PTR' 
[-Werror=implicit-function-declaration]
  return ERR_PTR(-EOPNOTSUPP);
 ^
include/linux/bpf.h:235:9: warning: return makes pointer from integer without a 
cast [-Wint-conversion]
In file included from include/linux/rwsem.h:17:0,
 from include/linux/mm_types.h:10,
 from include/linux/sched.h:27,
 from arch/arm64/include/asm/compat.h:25,
 from arch/arm64/include/asm/stat.h:23,
 from include/linux/stat.h:5,
 from include/linux/compat.h:12,
 from include/linux/filter.h:10,
 from arch/arm64/net/bpf_jit_comp.c:22:
include/linux/err.h: At top level:
include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR'
 static inline void * __must_check ERR_PTR(long error)
   ^
In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h:235:9: note: previous implicit declaration of 'ERR_PTR' was 
here
  return ERR_PTR(-EOPNOTSUPP);
 ^
...

Fixes: 0fc174dea545 ("ebpf: make internal bpf API independent of 
CONFIG_BPF_SYSCALL ifdefs")
Suggested-by: Daniel Borkmann 
Signed-off-by: Zi Shen Lim 
Acked-by: Daniel Borkmann 
---
 include/linux/bpf.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 8ee27b8..1bcae82 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bpf_map;
 
-- 
1.9.1

[PATCH net-next v2 4/4] arm64: bpf: optimize LD_ABS, LD_IND

[Zi Shen Lim]

Remove superfluous stack frame, saving us 3 instructions for every
LD_ABS or LD_IND.

Signed-off-by: Zi Shen Lim 
---
 arch/arm64/net/bpf_jit_comp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 7ae304e..b2fc97a 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -731,11 +731,8 @@ emit_cond_jmp:
emit_a64_mov_i64(r3, size, ctx);
emit(A64_SUB_I(1, r4, fp, STACK_SIZE), ctx);
emit_a64_mov_i64(r5, (unsigned long)bpf_load_pointer, ctx);
-   emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
-   emit(A64_MOV(1, A64_FP, A64_SP), ctx);
emit(A64_BLR(r5), ctx);
emit(A64_MOV(1, r0, A64_R(0)), ctx);
-   emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
 
jmp_offset = epilogue_offset(ctx);
check_imm19(jmp_offset);
-- 
1.9.1

[PATCH net-next v2 1/4] bpf: fix missing header inclusion

[Zi Shen Lim]

Commit 0fc174dea545 ("ebpf: make internal bpf API independent of
CONFIG_BPF_SYSCALL ifdefs") introduced usage of ERR_PTR() in
bpf_prog_get(), however did not include linux/err.h.

Without this patch, when compiling arm64 BPF without CONFIG_BPF_SYSCALL:
...
In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h: In function 'bpf_prog_get':
include/linux/bpf.h:235:9: error: implicit declaration of function 'ERR_PTR' 
[-Werror=implicit-function-declaration]
  return ERR_PTR(-EOPNOTSUPP);
 ^
include/linux/bpf.h:235:9: warning: return makes pointer from integer without a 
cast [-Wint-conversion]
In file included from include/linux/rwsem.h:17:0,
 from include/linux/mm_types.h:10,
 from include/linux/sched.h:27,
 from arch/arm64/include/asm/compat.h:25,
 from arch/arm64/include/asm/stat.h:23,
 from include/linux/stat.h:5,
 from include/linux/compat.h:12,
 from include/linux/filter.h:10,
 from arch/arm64/net/bpf_jit_comp.c:22:
include/linux/err.h: At top level:
include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR'
 static inline void * __must_check ERR_PTR(long error)
   ^
In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h:235:9: note: previous implicit declaration of 'ERR_PTR' was 
here
  return ERR_PTR(-EOPNOTSUPP);
 ^
...

Fixes: 0fc174dea545 ("ebpf: make internal bpf API independent of 
CONFIG_BPF_SYSCALL ifdefs")
Suggested-by: Daniel Borkmann 
Signed-off-by: Zi Shen Lim 
Acked-by: Daniel Borkmann 
---
 include/linux/bpf.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 8ee27b8..1bcae82 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bpf_map;
 
-- 
1.9.1

Re: [PATCH] iio: light: isl29125: use iio helper function to guarantee direct mode

[Peter Meerwald-Stadler]

> Replace the code that guarantees the device stays in direct mode
> with iio_device_claim_direct_mode() which does same.  This allows
> removal of an unused lock in the device private global data.

nice!
Acked-by: Peter Meerwald-Stadler 

> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/light/isl29125.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iio/light/isl29125.c b/drivers/iio/light/isl29125.c
> index e2945a2..a6b9d66 100644
> --- a/drivers/iio/light/isl29125.c
> +++ b/drivers/iio/light/isl29125.c
> @@ -50,7 +50,6 @@
>  
>  struct isl29125_data {
>   struct i2c_client *client;
> - struct mutex lock;
>   u8 conf1;
>   u16 buffer[8]; /* 3x 16-bit, padding, 8 bytes timestamp */
>  };
> @@ -128,11 +127,11 @@ static int isl29125_read_raw(struct iio_dev *indio_dev,
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> - if (iio_buffer_enabled(indio_dev))
> - return -EBUSY;
> - mutex_lock(>lock);
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
>   ret = isl29125_read_data(data, chan->scan_index);
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   if (ret < 0)
>   return ret;
>   *val = ret;
> @@ -259,7 +258,6 @@ static int isl29125_probe(struct i2c_client *client,
>   data = iio_priv(indio_dev);
>   i2c_set_clientdata(client, indio_dev);
>   data->client = client;
> - mutex_init(>lock);
>  
>   indio_dev->dev.parent = >dev;
>   indio_dev->info = _info;
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [PATCH] iio: light: isl29125: use iio helper function to guarantee direct mode

[Peter Meerwald-Stadler]

> Replace the code that guarantees the device stays in direct mode
> with iio_device_claim_direct_mode() which does same.  This allows
> removal of an unused lock in the device private global data.

nice!
Acked-by: Peter Meerwald-Stadler 

> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/light/isl29125.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iio/light/isl29125.c b/drivers/iio/light/isl29125.c
> index e2945a2..a6b9d66 100644
> --- a/drivers/iio/light/isl29125.c
> +++ b/drivers/iio/light/isl29125.c
> @@ -50,7 +50,6 @@
>  
>  struct isl29125_data {
>   struct i2c_client *client;
> - struct mutex lock;
>   u8 conf1;
>   u16 buffer[8]; /* 3x 16-bit, padding, 8 bytes timestamp */
>  };
> @@ -128,11 +127,11 @@ static int isl29125_read_raw(struct iio_dev *indio_dev,
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> - if (iio_buffer_enabled(indio_dev))
> - return -EBUSY;
> - mutex_lock(>lock);
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
>   ret = isl29125_read_data(data, chan->scan_index);
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   if (ret < 0)
>   return ret;
>   *val = ret;
> @@ -259,7 +258,6 @@ static int isl29125_probe(struct i2c_client *client,
>   data = iio_priv(indio_dev);
>   i2c_set_clientdata(client, indio_dev);
>   data->client = client;
> - mutex_init(>lock);
>  
>   indio_dev->dev.parent = >dev;
>   indio_dev->info = _info;
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

[PATCH net-next v2 0/4] arm64 BPF JIT updates

[Zi Shen Lim]

Updates for arm64 eBPF JIT.
The main addition here is implementation of bpf_tail_call.

#1: Fix missing header inclusion in linux/bpf.h.
#2: Add bpf_tail_call for arm64.
#3,4: Optimizations to reduce instruction count for jitted code.

Changes since v1:
 - Added patch #1 to address build error due to missing header inclusion
   in linux/bpf.h. (Thanks to suggestion and ack by Daniel Borkmann)
   Ordered it ahead of bpf_tail_call patch #2 so build error is not
   triggered.

Zi Shen Lim (4):
  bpf: fix missing header inclusion
  arm64: bpf: implement bpf_tail_call() helper
  arm64: bpf: optimize JMP_CALL
  arm64: bpf: optimize LD_ABS, LD_IND

 arch/arm64/net/bpf_jit.h  |   3 +-
 arch/arm64/net/bpf_jit_comp.c | 111 --
 include/linux/bpf.h   |   1 +
 3 files changed, 99 insertions(+), 16 deletions(-)

-- 
1.9.1

[PATCH net-next v2 3/4] arm64: bpf: optimize JMP_CALL

[Zi Shen Lim]

Remove superfluous stack frame, saving us 3 instructions for
every JMP_CALL.

Signed-off-by: Zi Shen Lim 
---
 arch/arm64/net/bpf_jit_comp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 51abc97..7ae304e 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -578,11 +578,8 @@ emit_cond_jmp:
const u64 func = (u64)__bpf_call_base + imm;
 
emit_a64_mov_i64(tmp, func, ctx);
-   emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
-   emit(A64_MOV(1, A64_FP, A64_SP), ctx);
emit(A64_BLR(tmp), ctx);
emit(A64_MOV(1, r0, A64_R(0)), ctx);
-   emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
break;
}
/* tail call */
-- 
1.9.1

Re: [PATCH] iio: light: tcs3414: use iio helper function to guarantee direct mode

[Peter Meerwald-Stadler]

> Replace the code that guarantees the device stays in direct mode
> with iio_device_claim_direct_mode() which does same.  This allows
> removal of an unused lock in the device private global data.

Acked-by: Peter Meerwald-Stadler 
 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/light/tcs3414.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/light/tcs3414.c b/drivers/iio/light/tcs3414.c
> index f90f8c5..8a15fb5 100644
> --- a/drivers/iio/light/tcs3414.c
> +++ b/drivers/iio/light/tcs3414.c
> @@ -53,7 +53,6 @@
>  
>  struct tcs3414_data {
>   struct i2c_client *client;
> - struct mutex lock;
>   u8 control;
>   u8 gain;
>   u8 timing;
> @@ -134,16 +133,16 @@ static int tcs3414_read_raw(struct iio_dev *indio_dev,
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> - if (iio_buffer_enabled(indio_dev))
> - return -EBUSY;
> - mutex_lock(>lock);
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
>   ret = tcs3414_req_data(data);
>   if (ret < 0) {
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   return ret;
>   }
>   ret = i2c_smbus_read_word_data(data->client, chan->address);
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   if (ret < 0)
>   return ret;
>   *val = ret;
> @@ -288,7 +287,6 @@ static int tcs3414_probe(struct i2c_client *client,
>   data = iio_priv(indio_dev);
>   i2c_set_clientdata(client, indio_dev);
>   data->client = client;
> - mutex_init(>lock);
>  
>   indio_dev->dev.parent = >dev;
>   indio_dev->info = _info;
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

[PATCH net-next v2 0/4] arm64 BPF JIT updates

[Zi Shen Lim]

Updates for arm64 eBPF JIT.
The main addition here is implementation of bpf_tail_call.

#1: Fix missing header inclusion in linux/bpf.h.
#2: Add bpf_tail_call for arm64.
#3,4: Optimizations to reduce instruction count for jitted code.

Changes since v1:
 - Added patch #1 to address build error due to missing header inclusion
   in linux/bpf.h. (Thanks to suggestion and ack by Daniel Borkmann)
   Ordered it ahead of bpf_tail_call patch #2 so build error is not
   triggered.

Zi Shen Lim (4):
  bpf: fix missing header inclusion
  arm64: bpf: implement bpf_tail_call() helper
  arm64: bpf: optimize JMP_CALL
  arm64: bpf: optimize LD_ABS, LD_IND

 arch/arm64/net/bpf_jit.h  |   3 +-
 arch/arm64/net/bpf_jit_comp.c | 111 --
 include/linux/bpf.h   |   1 +
 3 files changed, 99 insertions(+), 16 deletions(-)

-- 
1.9.1

[PATCH net-next v2 3/4] arm64: bpf: optimize JMP_CALL

[Zi Shen Lim]

Remove superfluous stack frame, saving us 3 instructions for
every JMP_CALL.

Signed-off-by: Zi Shen Lim 
---
 arch/arm64/net/bpf_jit_comp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 51abc97..7ae304e 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -578,11 +578,8 @@ emit_cond_jmp:
const u64 func = (u64)__bpf_call_base + imm;
 
emit_a64_mov_i64(tmp, func, ctx);
-   emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
-   emit(A64_MOV(1, A64_FP, A64_SP), ctx);
emit(A64_BLR(tmp), ctx);
emit(A64_MOV(1, r0, A64_R(0)), ctx);
-   emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
break;
}
/* tail call */
-- 
1.9.1

Re: [PATCH] iio: light: tcs3414: use iio helper function to guarantee direct mode

[Peter Meerwald-Stadler]

> Replace the code that guarantees the device stays in direct mode
> with iio_device_claim_direct_mode() which does same.  This allows
> removal of an unused lock in the device private global data.

Acked-by: Peter Meerwald-Stadler 
 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/light/tcs3414.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/light/tcs3414.c b/drivers/iio/light/tcs3414.c
> index f90f8c5..8a15fb5 100644
> --- a/drivers/iio/light/tcs3414.c
> +++ b/drivers/iio/light/tcs3414.c
> @@ -53,7 +53,6 @@
>  
>  struct tcs3414_data {
>   struct i2c_client *client;
> - struct mutex lock;
>   u8 control;
>   u8 gain;
>   u8 timing;
> @@ -134,16 +133,16 @@ static int tcs3414_read_raw(struct iio_dev *indio_dev,
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> - if (iio_buffer_enabled(indio_dev))
> - return -EBUSY;
> - mutex_lock(>lock);
> + ret = iio_device_claim_direct_mode(indio_dev);
> + if (ret)
> + return ret;
>   ret = tcs3414_req_data(data);
>   if (ret < 0) {
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   return ret;
>   }
>   ret = i2c_smbus_read_word_data(data->client, chan->address);
> - mutex_unlock(>lock);
> + iio_device_release_direct_mode(indio_dev);
>   if (ret < 0)
>   return ret;
>   *val = ret;
> @@ -288,7 +287,6 @@ static int tcs3414_probe(struct i2c_client *client,
>   data = iio_priv(indio_dev);
>   i2c_set_clientdata(client, indio_dev);
>   data->client = client;
> - mutex_init(>lock);
>  
>   indio_dev->dev.parent = >dev;
>   indio_dev->info = _info;
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode

[Vinod Koul]

On Mon, Apr 25, 2016 at 02:01:59PM +, Ramon Fried wrote:
> Wow. Thanks a lot !

care to give tested-by ?

-- 
~Vinod

Re: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode

[Vinod Koul]

On Mon, Apr 25, 2016 at 02:01:59PM +, Ramon Fried wrote:
> Wow. Thanks a lot !

care to give tested-by ?

-- 
~Vinod

Re: [PATCH 3.10 000/143] 3.10.102-stable review

[Willy Tarreau]

On Mon, Jun 06, 2016 at 09:30:11PM -0700, Guenter Roeck wrote:
> > > Do you have a repository, either with the patch
> > > series or with the to-be-tested branch, where the builder could
> > > pick it up ?
> > 
> > I don't but I can set something up for you. Would you be OK with a
> > branch in my account (eg: "3.10-for-guenter") which I "git push -f"
> > from my local branch ? That way you always pull from the same branch
> > and we don't care if patches are removed during the process. Just let
> > me know. Otherwise let me know if a different form is desired.
> > 
> 
> Yes, that would be excellent. I would suggest to name it something like
> stable-3.10-queue, though, to be a bit more generic. After all, other
> testers will want to pick it up as well.

Well, for me it would not be a "queue" in the sense of how Greg maintains
it but more a release candidate derived from the last 3.10 tag. Basically
if nothing changes between the review and the release, it will just get
an extra commit which is the release tag. If I produce it just for your
use case and you're fine with a force-pushed branch, I'd rather avoid to
confuse other people who probably have no business using it.

Thanks,
Willy

Re: [PATCH 3.10 000/143] 3.10.102-stable review

[Willy Tarreau]

On Mon, Jun 06, 2016 at 09:30:11PM -0700, Guenter Roeck wrote:
> > > Do you have a repository, either with the patch
> > > series or with the to-be-tested branch, where the builder could
> > > pick it up ?
> > 
> > I don't but I can set something up for you. Would you be OK with a
> > branch in my account (eg: "3.10-for-guenter") which I "git push -f"
> > from my local branch ? That way you always pull from the same branch
> > and we don't care if patches are removed during the process. Just let
> > me know. Otherwise let me know if a different form is desired.
> > 
> 
> Yes, that would be excellent. I would suggest to name it something like
> stable-3.10-queue, though, to be a bit more generic. After all, other
> testers will want to pick it up as well.

Well, for me it would not be a "queue" in the sense of how Greg maintains
it but more a release candidate derived from the last 3.10 tag. Basically
if nothing changes between the review and the release, it will just get
an extra commit which is the release tag. If I produce it just for your
use case and you're fine with a force-pushed branch, I'd rather avoid to
confuse other people who probably have no business using it.

Thanks,
Willy

[PATCH] kbuild: do not append NOSTDINC_FLAGS to avoid rebuild in package targets

[Masahiro Yamada]

For package building, the scripts/package/Makefile invokes
"$(MAKE) KBUILD_SRC=", so the top Makefile is invoked recursively.

Notice NOSTDINC_FLAGS is exported and assigned with "+=", not ":=".
It means, NOSTDINC_FLAGS is accumulated in the call loop of package
build: top Makefile -> scripts/package/Makefile -> top Makefile.

Before, it was not a big deal because GCC just ignores the repeated
compile options, and $(call if_changed,...) compared the old/new
commands as a set of arguments.

However, the situation was changed by commit 9c8fa9bc08f6 ("kbuild:
fix if_change and friends to consider argument order").  Now Kbuild
compares old/new commands more precisely.

Since then, "make" followed by "make targz-pkg" always rebuilds the
whole kernel.  The NOSTDINC_FLAGS is added just once for "make",
whilst twice for "make targz-pkg" as mentioned above.  So, Kbuild
considers that the build command has changed despite that we want a
tarball straight away if everything is already built.

The easiest way to fix this problem is to change "+=" to ":="
for NOSTDINC_FLAGS assignment.

This effectively reverts commit e8f5bdb02ce0 ("[PATCH] Makefile
include path ordering").  Its log says that the arch Makefile may
override the include path order, but I see no arch Makefile touching
NOSTDINC_FLAGS.  So, this change should have no impact unless
something outside of the kernel needs to override it.

Reported-by: Paulo Zanoni 
Signed-off-by: Masahiro Yamada 
---

This patch is fixing the problem reported by:
http://www.gossamer-threads.com/lists/linux/kernel/2454440

Paulo,
Thanks for your report!

Rik,
This patch is reverting your commit applied more than a decide ago.
As far as I see the kernel tree, I am not sure if it is still needed.
I am not familiar with Xen at all, so your review is very appreciated.


 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 8d1301a..58c06be 100644
--- a/Makefile
+++ b/Makefile
@@ -767,7 +767,7 @@ KBUILD_CFLAGS += $(call cc-option, 
-fno-inline-functions-called-once)
 endif
 
 # arch Makefile may override CC so keep this after arch Makefile is included
-NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
+NOSTDINC_FLAGS := -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS += $(NOSTDINC_FLAGS)
 
 # warn about C99 declaration after statement
-- 
1.9.1

[PATCH] kbuild: do not append NOSTDINC_FLAGS to avoid rebuild in package targets

[Masahiro Yamada]

For package building, the scripts/package/Makefile invokes
"$(MAKE) KBUILD_SRC=", so the top Makefile is invoked recursively.

Notice NOSTDINC_FLAGS is exported and assigned with "+=", not ":=".
It means, NOSTDINC_FLAGS is accumulated in the call loop of package
build: top Makefile -> scripts/package/Makefile -> top Makefile.

Before, it was not a big deal because GCC just ignores the repeated
compile options, and $(call if_changed,...) compared the old/new
commands as a set of arguments.

However, the situation was changed by commit 9c8fa9bc08f6 ("kbuild:
fix if_change and friends to consider argument order").  Now Kbuild
compares old/new commands more precisely.

Since then, "make" followed by "make targz-pkg" always rebuilds the
whole kernel.  The NOSTDINC_FLAGS is added just once for "make",
whilst twice for "make targz-pkg" as mentioned above.  So, Kbuild
considers that the build command has changed despite that we want a
tarball straight away if everything is already built.

The easiest way to fix this problem is to change "+=" to ":="
for NOSTDINC_FLAGS assignment.

This effectively reverts commit e8f5bdb02ce0 ("[PATCH] Makefile
include path ordering").  Its log says that the arch Makefile may
override the include path order, but I see no arch Makefile touching
NOSTDINC_FLAGS.  So, this change should have no impact unless
something outside of the kernel needs to override it.

Reported-by: Paulo Zanoni 
Signed-off-by: Masahiro Yamada 
---

This patch is fixing the problem reported by:
http://www.gossamer-threads.com/lists/linux/kernel/2454440

Paulo,
Thanks for your report!

Rik,
This patch is reverting your commit applied more than a decide ago.
As far as I see the kernel tree, I am not sure if it is still needed.
I am not familiar with Xen at all, so your review is very appreciated.


 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 8d1301a..58c06be 100644
--- a/Makefile
+++ b/Makefile
@@ -767,7 +767,7 @@ KBUILD_CFLAGS += $(call cc-option, 
-fno-inline-functions-called-once)
 endif
 
 # arch Makefile may override CC so keep this after arch Makefile is included
-NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
+NOSTDINC_FLAGS := -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS += $(NOSTDINC_FLAGS)
 
 # warn about C99 declaration after statement
-- 
1.9.1

Re: [PATCH] dmaengine: bcm2835: Fix polling for completion of DMA with interrupts masked.

[Vinod Koul]

On Mon, Jun 06, 2016 at 10:33:18AM -0700, Eric Anholt wrote:
> Vinod Koul  writes:
> 
> > On Fri, Jun 03, 2016 at 07:29:11PM -0700, Eric Anholt wrote:
> >> The tx_status hook is supposed to be safe to call from interrupt
> >> context, but it wouldn't ever return completion for the last transfer,
> >> meaning you couldn't poll for DMA completion with interrupts masked.
> >
> > and why is that?
> 
> Maybe this was poorly worded.  How about:
> 
> The tx_status hook is supposed to be safe to call from interrupt
> context.  However, the current transfer currently only gets marked
> complete by the IRQ handler, so if interrupts were masked then polling
> for completion would never finish.

Sound better :)

> 
> >> This fixes IRQ handling for bcm2835's DSI1, which requires using the
> >> DMA engine to write its registers due to a bug in the AXI bridge.
> >> 
> >> Signed-off-by: Eric Anholt 
> >> ---
> >>  drivers/dma/bcm2835-dma.c | 24 +++-
> >>  1 file changed, 19 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> >> index 6149b27c33ad..320461c578e3 100644
> >> --- a/drivers/dma/bcm2835-dma.c
> >> +++ b/drivers/dma/bcm2835-dma.c
> >> @@ -570,16 +570,16 @@ static enum dma_status bcm2835_dma_tx_status(struct 
> >> dma_chan *chan,
> >>struct virt_dma_desc *vd;
> >>enum dma_status ret;
> >>unsigned long flags;
> >> +  u32 residue;
> >>  
> >>ret = dma_cookie_status(chan, cookie, txstate);
> >> -  if (ret == DMA_COMPLETE || !txstate)
> >> +  if (ret == DMA_COMPLETE)
> >
> > Why do you change this? txstate can be NULL, so no point calculating reside
> > for those cases
> 
> The point was to go into the "Calculate where we're at in our current
> DMA (if the current DMA is the one we're asking about status for)" path,
> so that we could note when the DMA is complete even when there's no
> txstate passed in.

Can you explain what you mean by current DMA!

The claulation is always done for 'descriptor' represnted by the cookie. So
it doesnt not matter...!

Thanks
-- 
~Vinod


signature.asc
Description: Digital signature

Re: [PATCH] dmaengine: bcm2835: Fix polling for completion of DMA with interrupts masked.

[Vinod Koul]

On Mon, Jun 06, 2016 at 10:33:18AM -0700, Eric Anholt wrote:
> Vinod Koul  writes:
> 
> > On Fri, Jun 03, 2016 at 07:29:11PM -0700, Eric Anholt wrote:
> >> The tx_status hook is supposed to be safe to call from interrupt
> >> context, but it wouldn't ever return completion for the last transfer,
> >> meaning you couldn't poll for DMA completion with interrupts masked.
> >
> > and why is that?
> 
> Maybe this was poorly worded.  How about:
> 
> The tx_status hook is supposed to be safe to call from interrupt
> context.  However, the current transfer currently only gets marked
> complete by the IRQ handler, so if interrupts were masked then polling
> for completion would never finish.

Sound better :)

> 
> >> This fixes IRQ handling for bcm2835's DSI1, which requires using the
> >> DMA engine to write its registers due to a bug in the AXI bridge.
> >> 
> >> Signed-off-by: Eric Anholt 
> >> ---
> >>  drivers/dma/bcm2835-dma.c | 24 +++-
> >>  1 file changed, 19 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> >> index 6149b27c33ad..320461c578e3 100644
> >> --- a/drivers/dma/bcm2835-dma.c
> >> +++ b/drivers/dma/bcm2835-dma.c
> >> @@ -570,16 +570,16 @@ static enum dma_status bcm2835_dma_tx_status(struct 
> >> dma_chan *chan,
> >>struct virt_dma_desc *vd;
> >>enum dma_status ret;
> >>unsigned long flags;
> >> +  u32 residue;
> >>  
> >>ret = dma_cookie_status(chan, cookie, txstate);
> >> -  if (ret == DMA_COMPLETE || !txstate)
> >> +  if (ret == DMA_COMPLETE)
> >
> > Why do you change this? txstate can be NULL, so no point calculating reside
> > for those cases
> 
> The point was to go into the "Calculate where we're at in our current
> DMA (if the current DMA is the one we're asking about status for)" path,
> so that we could note when the DMA is complete even when there's no
> txstate passed in.

Can you explain what you mean by current DMA!

The claulation is always done for 'descriptor' represnted by the cookie. So
it doesnt not matter...!

Thanks
-- 
~Vinod


signature.asc
Description: Digital signature

Re: linux-next: Tree for Jun 6 (mm/slub.c)

[Randy Dunlap]

On 06/05/16 21:20, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160603:
> 

on i386:

mm/built-in.o: In function `init_cache_random_seq':
slub.c:(.text+0x76921): undefined reference to `cache_random_seq_create'
mm/built-in.o: In function `__kmem_cache_release':
(.text+0x80525): undefined reference to `cache_random_seq_destroy'


Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.7.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
# CONFIG_MULTIUSER is not set
CONFIG_SGETMASK_SYSCALL=y
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is 

Re: linux-next: Tree for Jun 6 (mm/slub.c)

[Randy Dunlap]

On 06/05/16 21:20, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160603:
> 

on i386:

mm/built-in.o: In function `init_cache_random_seq':
slub.c:(.text+0x76921): undefined reference to `cache_random_seq_create'
mm/built-in.o: In function `__kmem_cache_release':
(.text+0x80525): undefined reference to `cache_random_seq_destroy'


Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.7.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
# CONFIG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
# CONFIG_MULTIUSER is not set
CONFIG_SGETMASK_SYSCALL=y
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is 

[PATCH] iio: light: tcs3472: use iio helper function to guarantee direct mode

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode
with iio_device_claim_direct_mode() which does same.  This allows
removal of an unused lock in the device private global data.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/light/tcs3472.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c
index 1b530bf..b29312f 100644
--- a/drivers/iio/light/tcs3472.c
+++ b/drivers/iio/light/tcs3472.c
@@ -52,7 +52,6 @@
 
 struct tcs3472_data {
struct i2c_client *client;
-   struct mutex lock;
u8 enable;
u8 control;
u8 atime;
@@ -117,17 +116,16 @@ static int tcs3472_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-
-   mutex_lock(>lock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
ret = tcs3472_req_data(data);
if (ret < 0) {
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
return ret;
}
ret = i2c_smbus_read_word_data(data->client, chan->address);
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ret;
@@ -263,7 +261,6 @@ static int tcs3472_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   mutex_init(>lock);
 
indio_dev->dev.parent = >dev;
indio_dev->info = _info;
-- 
2.1.4

[PATCH] iio: light: tcs3472: use iio helper function to guarantee direct mode

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode
with iio_device_claim_direct_mode() which does same.  This allows
removal of an unused lock in the device private global data.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/light/tcs3472.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c
index 1b530bf..b29312f 100644
--- a/drivers/iio/light/tcs3472.c
+++ b/drivers/iio/light/tcs3472.c
@@ -52,7 +52,6 @@
 
 struct tcs3472_data {
struct i2c_client *client;
-   struct mutex lock;
u8 enable;
u8 control;
u8 atime;
@@ -117,17 +116,16 @@ static int tcs3472_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-
-   mutex_lock(>lock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
ret = tcs3472_req_data(data);
if (ret < 0) {
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
return ret;
}
ret = i2c_smbus_read_word_data(data->client, chan->address);
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ret;
@@ -263,7 +261,6 @@ static int tcs3472_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   mutex_init(>lock);
 
indio_dev->dev.parent = >dev;
indio_dev->info = _info;
-- 
2.1.4

[PATCH] iio: light: tcs3414: use iio helper function to guarantee direct mode

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode
with iio_device_claim_direct_mode() which does same.  This allows
removal of an unused lock in the device private global data.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/light/tcs3414.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/light/tcs3414.c b/drivers/iio/light/tcs3414.c
index f90f8c5..8a15fb5 100644
--- a/drivers/iio/light/tcs3414.c
+++ b/drivers/iio/light/tcs3414.c
@@ -53,7 +53,6 @@
 
 struct tcs3414_data {
struct i2c_client *client;
-   struct mutex lock;
u8 control;
u8 gain;
u8 timing;
@@ -134,16 +133,16 @@ static int tcs3414_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-   mutex_lock(>lock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
ret = tcs3414_req_data(data);
if (ret < 0) {
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
return ret;
}
ret = i2c_smbus_read_word_data(data->client, chan->address);
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ret;
@@ -288,7 +287,6 @@ static int tcs3414_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   mutex_init(>lock);
 
indio_dev->dev.parent = >dev;
indio_dev->info = _info;
-- 
2.1.4

[PATCH] iio: light: tcs3414: use iio helper function to guarantee direct mode

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode
with iio_device_claim_direct_mode() which does same.  This allows
removal of an unused lock in the device private global data.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/light/tcs3414.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/light/tcs3414.c b/drivers/iio/light/tcs3414.c
index f90f8c5..8a15fb5 100644
--- a/drivers/iio/light/tcs3414.c
+++ b/drivers/iio/light/tcs3414.c
@@ -53,7 +53,6 @@
 
 struct tcs3414_data {
struct i2c_client *client;
-   struct mutex lock;
u8 control;
u8 gain;
u8 timing;
@@ -134,16 +133,16 @@ static int tcs3414_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-   mutex_lock(>lock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
ret = tcs3414_req_data(data);
if (ret < 0) {
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
return ret;
}
ret = i2c_smbus_read_word_data(data->client, chan->address);
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ret;
@@ -288,7 +287,6 @@ static int tcs3414_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   mutex_init(>lock);
 
indio_dev->dev.parent = >dev;
indio_dev->info = _info;
-- 
2.1.4

[PATCH] iio: light: isl29125: use iio helper function to guarantee direct mode

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode
with iio_device_claim_direct_mode() which does same.  This allows
removal of an unused lock in the device private global data.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/light/isl29125.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/light/isl29125.c b/drivers/iio/light/isl29125.c
index e2945a2..a6b9d66 100644
--- a/drivers/iio/light/isl29125.c
+++ b/drivers/iio/light/isl29125.c
@@ -50,7 +50,6 @@
 
 struct isl29125_data {
struct i2c_client *client;
-   struct mutex lock;
u8 conf1;
u16 buffer[8]; /* 3x 16-bit, padding, 8 bytes timestamp */
 };
@@ -128,11 +127,11 @@ static int isl29125_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-   mutex_lock(>lock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
ret = isl29125_read_data(data, chan->scan_index);
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ret;
@@ -259,7 +258,6 @@ static int isl29125_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   mutex_init(>lock);
 
indio_dev->dev.parent = >dev;
indio_dev->info = _info;
-- 
2.1.4

[PATCH] iio: light: isl29125: use iio helper function to guarantee direct mode

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode
with iio_device_claim_direct_mode() which does same.  This allows
removal of an unused lock in the device private global data.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/light/isl29125.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/light/isl29125.c b/drivers/iio/light/isl29125.c
index e2945a2..a6b9d66 100644
--- a/drivers/iio/light/isl29125.c
+++ b/drivers/iio/light/isl29125.c
@@ -50,7 +50,6 @@
 
 struct isl29125_data {
struct i2c_client *client;
-   struct mutex lock;
u8 conf1;
u16 buffer[8]; /* 3x 16-bit, padding, 8 bytes timestamp */
 };
@@ -128,11 +127,11 @@ static int isl29125_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-   mutex_lock(>lock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
ret = isl29125_read_data(data, chan->scan_index);
-   mutex_unlock(>lock);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ret;
@@ -259,7 +258,6 @@ static int isl29125_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   mutex_init(>lock);
 
indio_dev->dev.parent = >dev;
indio_dev->info = _info;
-- 
2.1.4

linux-next: Tree for Jun 7

[Stephen Rothwell]

Hi all,

Changes since 20160606:

New tree: bcm2835
Removed trees: devicetree, devicetree-current (maintainer change)
bcm2835-dt, bcm2835-soc, bcm2835-drivers, bcm2835-defconfig
(merged into bcm2835 tree)
Renamed tree: dt-rh to devicetree

Dropped tree: amlogic (build failure)

My fixes tree contains:

  of: silence warnings due to max() usage

The amlogic tree still had its build failure so I dropped it for today.

The drm-misc tree gained a conflict against Linus' tree.

The clockevents tree gained conflicts against the arm-soc and Linus'
trees and a build failure so I used the version from next-20160606.

The akpm-current tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1809
 1718 files changed, 71965 insertions(+), 32005 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 233 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (3613a6245b9f Merge tag 'edac_fixes_for_4.7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp)
Merging fixes/master (b31033aacbd0 of: silence warnings due to max() usage)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (ed6aefed726a Revert "ARCv2: 
spinlock/rwlock/atomics: Delayed retry of failed SCOND with exponential 
backoff")
Merging arm-current/fixes (e2dfb4b88014 ARM: fix PTRACE_SETVFPREGS on SMP 
systems)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8a934efe9434 powerpc/pseries: Fix PCI config 
address for DDW)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (1957598840f4 soreuseport: add compat case for setsockopt 
SO_ATTACH_REUSEPORT_CBPF)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (3ec10d3a2ba5 ipvs: update real-server binding of outgoing 
connections in SIP-pe)
Merging wireless-drivers/master (182fd9eecb28 MAINTAINERS: Add file patterns 
for wireless device tree bindings)
Merging mac80211/master (6fe04128f158 mac80211: fix fast_tx header alignment)
Merging sound-current/for-linus (0358ccc8ffd8 ALSA: uapi: Add three missing 
header files to Kbuild file)
Merging pci-current/for-linus (1a695a905c18 Linux 4.7-rc1)
Merging driver-core.current/driver-core-linus (1a695a905c18 Linux 4.7-rc1)
Merging tty.current/tty-linus (1a695a905c18 Linux 4.7-rc1)
Merging usb.current/usb-linus (7b2c17f82954 usb: musb: Stop bulk endpoint while 
queue is rotated)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (1a695a905c18 Linux 4.7-rc1)
Merging char-misc.current/char-misc-linus (1a695a905c18 Linux 4.7-rc1)
Merging input-current/for-linus (540c26087bfb Input: xpad - fix rumble on Xbox 
One controllers with 2015 firmware)
Merging crypto-current/ma

linux-next: Tree for Jun 7

[Stephen Rothwell]

Hi all,

Changes since 20160606:

New tree: bcm2835
Removed trees: devicetree, devicetree-current (maintainer change)
bcm2835-dt, bcm2835-soc, bcm2835-drivers, bcm2835-defconfig
(merged into bcm2835 tree)
Renamed tree: dt-rh to devicetree

Dropped tree: amlogic (build failure)

My fixes tree contains:

  of: silence warnings due to max() usage

The amlogic tree still had its build failure so I dropped it for today.

The drm-misc tree gained a conflict against Linus' tree.

The clockevents tree gained conflicts against the arm-soc and Linus'
trees and a build failure so I used the version from next-20160606.

The akpm-current tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1809
 1718 files changed, 71965 insertions(+), 32005 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 233 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (3613a6245b9f Merge tag 'edac_fixes_for_4.7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp)
Merging fixes/master (b31033aacbd0 of: silence warnings due to max() usage)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (ed6aefed726a Revert "ARCv2: 
spinlock/rwlock/atomics: Delayed retry of failed SCOND with exponential 
backoff")
Merging arm-current/fixes (e2dfb4b88014 ARM: fix PTRACE_SETVFPREGS on SMP 
systems)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (8a934efe9434 powerpc/pseries: Fix PCI config 
address for DDW)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (1957598840f4 soreuseport: add compat case for setsockopt 
SO_ATTACH_REUSEPORT_CBPF)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (3ec10d3a2ba5 ipvs: update real-server binding of outgoing 
connections in SIP-pe)
Merging wireless-drivers/master (182fd9eecb28 MAINTAINERS: Add file patterns 
for wireless device tree bindings)
Merging mac80211/master (6fe04128f158 mac80211: fix fast_tx header alignment)
Merging sound-current/for-linus (0358ccc8ffd8 ALSA: uapi: Add three missing 
header files to Kbuild file)
Merging pci-current/for-linus (1a695a905c18 Linux 4.7-rc1)
Merging driver-core.current/driver-core-linus (1a695a905c18 Linux 4.7-rc1)
Merging tty.current/tty-linus (1a695a905c18 Linux 4.7-rc1)
Merging usb.current/usb-linus (7b2c17f82954 usb: musb: Stop bulk endpoint while 
queue is rotated)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (1a695a905c18 Linux 4.7-rc1)
Merging char-misc.current/char-misc-linus (1a695a905c18 Linux 4.7-rc1)
Merging input-current/for-linus (540c26087bfb Input: xpad - fix rumble on Xbox 
One controllers with 2015 firmware)
Merging crypto-current/ma

[PATCH v2 4/4] arm64: dts: rockchip: add rktimer device node for rk3399

[Caesar Wang]

From: Huang Tao 

Select rktimer0 as broadcast timer.

Signed-off-by: Huang Tao 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Tested-by: Jianqun Xu 

Signed-off-by: Caesar Wang 
---

Changes in v2:
- %s/ARM64/arm64.

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d331e80..f0d1935 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -542,6 +542,14 @@
interrupts = ;
};
 
+   rktimer: rktimer@ff85 {
+   compatible = "rockchip,rk3399-timer";
+   reg = <0x0 0xff85 0x0 0x1000>;
+   interrupts = ;
+   clocks = < PCLK_TIMER0>, < SCLK_TIMER00>;
+   clock-names = "pclk", "timer";
+   };
+
spdif: spdif@ff87 {
compatible = "rockchip,rk3399-spdif";
reg = <0x0 0xff87 0x0 0x1000>;
-- 
1.9.1

[PATCH v2 4/4] arm64: dts: rockchip: add rktimer device node for rk3399

[Caesar Wang]

From: Huang Tao 

Select rktimer0 as broadcast timer.

Signed-off-by: Huang Tao 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Tested-by: Jianqun Xu 

Signed-off-by: Caesar Wang 
---

Changes in v2:
- %s/ARM64/arm64.

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d331e80..f0d1935 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -542,6 +542,14 @@
interrupts = ;
};
 
+   rktimer: rktimer@ff85 {
+   compatible = "rockchip,rk3399-timer";
+   reg = <0x0 0xff85 0x0 0x1000>;
+   interrupts = ;
+   clocks = < PCLK_TIMER0>, < SCLK_TIMER00>;
+   clock-names = "pclk", "timer";
+   };
+
spdif: spdif@ff87 {
compatible = "rockchip,rk3399-spdif";
reg = <0x0 0xff87 0x0 0x1000>;
-- 
1.9.1

[PATCH v2 2/4] clocksource: rockchip: add dynamic irq flag to the timer

[Caesar Wang]

From: "Huang, Tao" 

The rockchip timer is broadcast timer. Add CLOCK_EVT_FEAT_DYNIRQ
flag and set cpumask to all possible cpus to save power by avoid
unnecessary wakeups and IPIs.

Signed-off-by: Huang Tao 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Tested-by: Jianqun Xu 
Signed-off-by: Caesar Wang 

---

Changes in v2:
- s/cpu_all_mask/cpu_possible_mask/, As Daniel comments on
  https://patchwork.kernel.org/patch/9135053/.

 drivers/clocksource/rockchip_timer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c 
b/drivers/clocksource/rockchip_timer.c
index b991b28..b510863 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -150,12 +150,13 @@ static void __init rk_timer_init(struct device_node *np)
}
 
ce->name = TIMER_NAME;
-   ce->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+   ce->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
+  CLOCK_EVT_FEAT_DYNIRQ;
ce->set_next_event = rk_timer_set_next_event;
ce->set_state_shutdown = rk_timer_shutdown;
ce->set_state_periodic = rk_timer_set_periodic;
ce->irq = irq;
-   ce->cpumask = cpumask_of(0);
+   ce->cpumask = cpu_possible_mask;
ce->rating = 250;
 
rk_timer_interrupt_clear(ce);
-- 
1.9.1

[PATCH v2 2/4] clocksource: rockchip: add dynamic irq flag to the timer

[Caesar Wang]

From: "Huang, Tao" 

The rockchip timer is broadcast timer. Add CLOCK_EVT_FEAT_DYNIRQ
flag and set cpumask to all possible cpus to save power by avoid
unnecessary wakeups and IPIs.

Signed-off-by: Huang Tao 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Tested-by: Jianqun Xu 
Signed-off-by: Caesar Wang 

---

Changes in v2:
- s/cpu_all_mask/cpu_possible_mask/, As Daniel comments on
  https://patchwork.kernel.org/patch/9135053/.

 drivers/clocksource/rockchip_timer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c 
b/drivers/clocksource/rockchip_timer.c
index b991b28..b510863 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -150,12 +150,13 @@ static void __init rk_timer_init(struct device_node *np)
}
 
ce->name = TIMER_NAME;
-   ce->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+   ce->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
+  CLOCK_EVT_FEAT_DYNIRQ;
ce->set_next_event = rk_timer_set_next_event;
ce->set_state_shutdown = rk_timer_shutdown;
ce->set_state_periodic = rk_timer_set_periodic;
ce->irq = irq;
-   ce->cpumask = cpumask_of(0);
+   ce->cpumask = cpu_possible_mask;
ce->rating = 250;
 
rk_timer_interrupt_clear(ce);
-- 
1.9.1

[PATCH v2 3/4] clocksource: rockchip: add support for rk3399 SoC

[Caesar Wang]

From: "Huang, Tao" 

The CONTROL register offset is different from old SoCs.
For Linux driver, there are not functional changes at all.
So add dedicated mapping for the CONTROL register.

Signed-off-by: Huang Tao 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Tested-by: Jianqun Xu 
Signed-off-by: Caesar Wang 

---

Changes in v2:
- As the Daniel suggests on https://patchwork.kernel.org/patch/9135061/,
  That will be better for the rockchip timer driver.

 drivers/clocksource/rockchip_timer.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c 
b/drivers/clocksource/rockchip_timer.c
index b510863..a3f22b0 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -19,7 +19,8 @@
 
 #define TIMER_LOAD_COUNT0  0x00
 #define TIMER_LOAD_COUNT1  0x04
-#define TIMER_CONTROL_REG  0x10
+#define TIMER_CONTROL_REG3288  0x10
+#define TIMER_CONTROL_REG3399  0x1c
 #define TIMER_INT_STATUS   0x18
 
 #define TIMER_DISABLE  0x0
@@ -31,6 +32,7 @@
 struct bc_timer {
struct clock_event_device ce;
void __iomem *base;
+   void __iomem *ctrl;
u32 freq;
 };
 
@@ -46,15 +48,20 @@ static inline void __iomem *rk_base(struct 
clock_event_device *ce)
return rk_timer(ce)->base;
 }
 
+static inline void __iomem *rk_ctrl(struct clock_event_device *ce)
+{
+   return rk_timer(ce)->ctrl;
+}
+
 static inline void rk_timer_disable(struct clock_event_device *ce)
 {
-   writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
+   writel_relaxed(TIMER_DISABLE, rk_ctrl(ce));
 }
 
 static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
 {
writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
-  rk_base(ce) + TIMER_CONTROL_REG);
+  rk_ctrl(ce));
 }
 
 static void rk_timer_update_counter(unsigned long cycles,
@@ -106,7 +113,7 @@ static irqreturn_t rk_timer_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static void __init rk_timer_init(struct device_node *np)
+static void __init rk_timer_init(struct device_node *np, u32 ctrl_reg)
 {
struct clock_event_device *ce = _timer.ce;
struct clk *timer_clk;
@@ -118,6 +125,7 @@ static void __init rk_timer_init(struct device_node *np)
pr_err("Failed to get base address for '%s'\n", TIMER_NAME);
return;
}
+   bc_timer.ctrl = bc_timer.base + ctrl_reg;
 
pclk = of_clk_get_by_name(np, "pclk");
if (IS_ERR(pclk)) {
@@ -180,4 +188,17 @@ out_unmap:
iounmap(bc_timer.base);
 }
 
-CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);
+static void __init rk3288_timer_init(struct device_node *np)
+{
+   rk_timer_init(np, TIMER_CONTROL_REG3288);
+}
+
+static void __init rk3399_timer_init(struct device_node *np)
+{
+   rk_timer_init(np, TIMER_CONTROL_REG3399);
+}
+
+CLOCKSOURCE_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer",
+  rk3288_timer_init);
+CLOCKSOURCE_OF_DECLARE(rk3399_timer, "rockchip,rk3399-timer",
+  rk3399_timer_init);
-- 
1.9.1

[PATCH v2 1/4] dt-bindings: document rk3399 rk-timer bindings

[Caesar Wang]

From: Huang Tao 

Add compatible string for rk3399 because which timer is a little
different from older SoCs. So rename the file name from
rockchip,rk3288-timer.txt to rockchip,rk-timer.txt.
Clarify rockchip,rk3288-timer supported SoCs.

Signed-off-by: Huang Tao 
Cc: Rob Herring 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Signed-off-by: Caesar Wang 
Acked-by: Rob Herring 

---

Changes in v2:
- Add the Rob' Ack.

 .../timer/{rockchip,rk3288-timer.txt => rockchip,rk-timer.txt}  | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/timer/{rockchip,rk3288-timer.txt => 
rockchip,rk-timer.txt} (75%)

diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk3288-timer.txt 
b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
similarity index 75%
rename from Documentation/devicetree/bindings/timer/rockchip,rk3288-timer.txt
rename to Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index 87f0b00..a41b184 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk3288-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -1,7 +1,9 @@
-Rockchip rk3288 timer
+Rockchip rk timer
 
 Required properties:
-- compatible: shall be "rockchip,rk3288-timer"
+- compatible: shall be one of:
+  "rockchip,rk3288-timer" - for rk3066, rk3036, rk3188, rk322x, rk3288, rk3368
+  "rockchip,rk3399-timer" - for rk3399
 - reg: base address of the timer register starting with TIMERS CONTROL register
 - interrupts: should contain the interrupts for Timer0
 - clocks : must contain an entry for each entry in clock-names
-- 
1.9.1

[PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399

[Caesar Wang]

This series patches had been tested on rockchip inside kernel.
In order to support the rk3399 SoC timer and turn off interrupts and IPIs to
save power in idle.
Okay, it still works bootup on rk3288/other SoCs, even though many socs hasn't 
used
the broadcast timer.

History version:
v1:
https://lkml.org/lkml/2016/5/25/186

Easy to test for my borad.
localhost / # cat /proc/interrupts
CPU0   CPU1   CPU2   CPU3   CPU4   CPU5
1:  0  0  0  0  0  0 GICv3  
29 Edge  arch_timer
...
5:  0  0  0  0  0  0 GICv3 
113 Level rk_timer
..

localhost / # cat /proc/timer_list | grep event_handler
get "event_handler:  hrtimer_interrupt"
event_handler:  tick_handle_oneshot_broadcast
event_handler:  hrtimer_interrupt

That should work for my board.


Changes in v2:
- Add the Rob' Ack.
- s/cpu_all_mask/cpu_possible_mask/, As Daniel comments on
  https://patchwork.kernel.org/patch/9135053/.
- As the Daniel suggests on https://patchwork.kernel.org/patch/9135061/,
  That will be better for the rockchip timer driver.
- %s/ARM64/arm64.

Huang Tao (2):
  dt-bindings: document rk3399 rk-timer bindings
  arm64: dts: rockchip: add rktimer device node for rk3399

Huang, Tao (2):
  clocksource: rockchip: add dynamic irq flag to the timer
  clocksource: rockchip: add support for rk3399 SoC

 ...chip,rk3288-timer.txt => rockchip,rk-timer.txt} |  6 ++--
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |  8 +
 drivers/clocksource/rockchip_timer.c   | 36 +-
 3 files changed, 41 insertions(+), 9 deletions(-)
 rename Documentation/devicetree/bindings/timer/{rockchip,rk3288-timer.txt => 
rockchip,rk-timer.txt} (75%)

-- 
1.9.1

[PATCH v2 3/4] clocksource: rockchip: add support for rk3399 SoC

[Caesar Wang]

From: "Huang, Tao" 

The CONTROL register offset is different from old SoCs.
For Linux driver, there are not functional changes at all.
So add dedicated mapping for the CONTROL register.

Signed-off-by: Huang Tao 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Tested-by: Jianqun Xu 
Signed-off-by: Caesar Wang 

---

Changes in v2:
- As the Daniel suggests on https://patchwork.kernel.org/patch/9135061/,
  That will be better for the rockchip timer driver.

 drivers/clocksource/rockchip_timer.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c 
b/drivers/clocksource/rockchip_timer.c
index b510863..a3f22b0 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -19,7 +19,8 @@
 
 #define TIMER_LOAD_COUNT0  0x00
 #define TIMER_LOAD_COUNT1  0x04
-#define TIMER_CONTROL_REG  0x10
+#define TIMER_CONTROL_REG3288  0x10
+#define TIMER_CONTROL_REG3399  0x1c
 #define TIMER_INT_STATUS   0x18
 
 #define TIMER_DISABLE  0x0
@@ -31,6 +32,7 @@
 struct bc_timer {
struct clock_event_device ce;
void __iomem *base;
+   void __iomem *ctrl;
u32 freq;
 };
 
@@ -46,15 +48,20 @@ static inline void __iomem *rk_base(struct 
clock_event_device *ce)
return rk_timer(ce)->base;
 }
 
+static inline void __iomem *rk_ctrl(struct clock_event_device *ce)
+{
+   return rk_timer(ce)->ctrl;
+}
+
 static inline void rk_timer_disable(struct clock_event_device *ce)
 {
-   writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
+   writel_relaxed(TIMER_DISABLE, rk_ctrl(ce));
 }
 
 static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
 {
writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
-  rk_base(ce) + TIMER_CONTROL_REG);
+  rk_ctrl(ce));
 }
 
 static void rk_timer_update_counter(unsigned long cycles,
@@ -106,7 +113,7 @@ static irqreturn_t rk_timer_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static void __init rk_timer_init(struct device_node *np)
+static void __init rk_timer_init(struct device_node *np, u32 ctrl_reg)
 {
struct clock_event_device *ce = _timer.ce;
struct clk *timer_clk;
@@ -118,6 +125,7 @@ static void __init rk_timer_init(struct device_node *np)
pr_err("Failed to get base address for '%s'\n", TIMER_NAME);
return;
}
+   bc_timer.ctrl = bc_timer.base + ctrl_reg;
 
pclk = of_clk_get_by_name(np, "pclk");
if (IS_ERR(pclk)) {
@@ -180,4 +188,17 @@ out_unmap:
iounmap(bc_timer.base);
 }
 
-CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);
+static void __init rk3288_timer_init(struct device_node *np)
+{
+   rk_timer_init(np, TIMER_CONTROL_REG3288);
+}
+
+static void __init rk3399_timer_init(struct device_node *np)
+{
+   rk_timer_init(np, TIMER_CONTROL_REG3399);
+}
+
+CLOCKSOURCE_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer",
+  rk3288_timer_init);
+CLOCKSOURCE_OF_DECLARE(rk3399_timer, "rockchip,rk3399-timer",
+  rk3399_timer_init);
-- 
1.9.1

[PATCH v2 1/4] dt-bindings: document rk3399 rk-timer bindings

[Caesar Wang]

From: Huang Tao 

Add compatible string for rk3399 because which timer is a little
different from older SoCs. So rename the file name from
rockchip,rk3288-timer.txt to rockchip,rk-timer.txt.
Clarify rockchip,rk3288-timer supported SoCs.

Signed-off-by: Huang Tao 
Cc: Rob Herring 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Heiko Stuebner 
Signed-off-by: Caesar Wang 
Acked-by: Rob Herring 

---

Changes in v2:
- Add the Rob' Ack.

 .../timer/{rockchip,rk3288-timer.txt => rockchip,rk-timer.txt}  | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/timer/{rockchip,rk3288-timer.txt => 
rockchip,rk-timer.txt} (75%)

diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk3288-timer.txt 
b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
similarity index 75%
rename from Documentation/devicetree/bindings/timer/rockchip,rk3288-timer.txt
rename to Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index 87f0b00..a41b184 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk3288-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -1,7 +1,9 @@
-Rockchip rk3288 timer
+Rockchip rk timer
 
 Required properties:
-- compatible: shall be "rockchip,rk3288-timer"
+- compatible: shall be one of:
+  "rockchip,rk3288-timer" - for rk3066, rk3036, rk3188, rk322x, rk3288, rk3368
+  "rockchip,rk3399-timer" - for rk3399
 - reg: base address of the timer register starting with TIMERS CONTROL register
 - interrupts: should contain the interrupts for Timer0
 - clocks : must contain an entry for each entry in clock-names
-- 
1.9.1

[PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399

[Caesar Wang]

This series patches had been tested on rockchip inside kernel.
In order to support the rk3399 SoC timer and turn off interrupts and IPIs to
save power in idle.
Okay, it still works bootup on rk3288/other SoCs, even though many socs hasn't 
used
the broadcast timer.

History version:
v1:
https://lkml.org/lkml/2016/5/25/186

Easy to test for my borad.
localhost / # cat /proc/interrupts
CPU0   CPU1   CPU2   CPU3   CPU4   CPU5
1:  0  0  0  0  0  0 GICv3  
29 Edge  arch_timer
...
5:  0  0  0  0  0  0 GICv3 
113 Level rk_timer
..

localhost / # cat /proc/timer_list | grep event_handler
get "event_handler:  hrtimer_interrupt"
event_handler:  tick_handle_oneshot_broadcast
event_handler:  hrtimer_interrupt

That should work for my board.


Changes in v2:
- Add the Rob' Ack.
- s/cpu_all_mask/cpu_possible_mask/, As Daniel comments on
  https://patchwork.kernel.org/patch/9135053/.
- As the Daniel suggests on https://patchwork.kernel.org/patch/9135061/,
  That will be better for the rockchip timer driver.
- %s/ARM64/arm64.

Huang Tao (2):
  dt-bindings: document rk3399 rk-timer bindings
  arm64: dts: rockchip: add rktimer device node for rk3399

Huang, Tao (2):
  clocksource: rockchip: add dynamic irq flag to the timer
  clocksource: rockchip: add support for rk3399 SoC

 ...chip,rk3288-timer.txt => rockchip,rk-timer.txt} |  6 ++--
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |  8 +
 drivers/clocksource/rockchip_timer.c   | 36 +-
 3 files changed, 41 insertions(+), 9 deletions(-)
 rename Documentation/devicetree/bindings/timer/{rockchip,rk3288-timer.txt => 
rockchip,rk-timer.txt} (75%)

-- 
1.9.1

Re: [PATCH V2] block: correctly fallback for zeroout

[Sitsofe Wheeler]

On Mon, Jun 06, 2016 at 03:33:58PM -0700, Shaohua Li wrote:
> blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
> fallback to regular write. The problem is discard/writesame doesn't
> return error for -EOPNOTSUPP, then zeroout can't do fallback and leave
> disk data not changed. zeroout should have guaranteed zero-fill
> behavior.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=118581
> 
> V2: move the return value policy to blkdev_issue_discard and
> delete the policy for blkdev_issue_write_same (Martin)
> 
> Cc: Sitsofe Wheeler 
> Cc: Mike Snitzer 
> Cc: Jens Axboe 
> Cc: Martin K. Petersen 
> Signed-off-by: Shaohua Li 
> ---
>  block/blk-lib.c | 49 +++--
>  1 file changed, 31 insertions(+), 18 deletions(-)
> 
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 23d7f30..a3a26c8 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -84,6 +84,28 @@ int __blkdev_issue_discard(struct block_device *bdev, 
> sector_t sector,
>  }
>  EXPORT_SYMBOL(__blkdev_issue_discard);
>  
> +static int do_blkdev_issue_discard(struct block_device *bdev, sector_t 
> sector,
> + sector_t nr_sects, gfp_t gfp_mask, unsigned long flags,
> + int *io_err)
> +{
> + int type = REQ_WRITE | REQ_DISCARD;
> + struct bio *bio = NULL;
> + struct blk_plug plug;
> + int ret;
> +
> + if (flags & BLKDEV_DISCARD_SECURE)
> + type |= REQ_SECURE;
> +
> + blk_start_plug();
> + ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
> + );
> + if (!ret && bio)
> + *io_err = submit_bio_wait(type, bio);
> + blk_finish_plug();
> +
> + return ret;
> +}
> +
>  /**
>   * blkdev_issue_discard - queue a discard
>   * @bdev:blockdev to issue discard for
> @@ -98,23 +120,12 @@ EXPORT_SYMBOL(__blkdev_issue_discard);
>  int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
>   sector_t nr_sects, gfp_t gfp_mask, unsigned long flags)
>  {
> - int type = REQ_WRITE | REQ_DISCARD;
> - struct bio *bio = NULL;
> - struct blk_plug plug;
> - int ret;
> + int ret, io_err;
>  
> - if (flags & BLKDEV_DISCARD_SECURE)
> - type |= REQ_SECURE;
> -
> - blk_start_plug();
> - ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
> - );
> - if (!ret && bio) {
> - ret = submit_bio_wait(type, bio);
> - if (ret == -EOPNOTSUPP)
> - ret = 0;
> - }
> - blk_finish_plug();
> + ret = do_blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask,
> + flags, _err);
> + if (!ret && io_err != -EOPNOTSUPP)
> + ret = io_err;

Because io_err is always consulted if ret is not true shouldn't it be
explicitly initialized to 0 before the call to do_blkdev_issue_discard
(as do_blkdev_issue_discard will only set io_err if bio returned true)?

Perhaps there's an argument that do_blkdev_issue_discard should always
set io_err on all its paths rather than just on errors in case the
caller hasn't initialized it - is there an existing kernel pattern for
this)?

>  
>   return ret;
>  }
> @@ -167,7 +178,7 @@ int blkdev_issue_write_same(struct block_device *bdev, 
> sector_t sector,
>  
>   if (bio)
>   ret = submit_bio_wait(REQ_WRITE | REQ_WRITE_SAME, bio);
> - return ret != -EOPNOTSUPP ? ret : 0;
> + return ret;
>  }
>  EXPORT_SYMBOL(blkdev_issue_write_same);
>  
> @@ -236,9 +247,11 @@ int blkdev_issue_zeroout(struct block_device *bdev, 
> sector_t sector,
>sector_t nr_sects, gfp_t gfp_mask, bool discard)
>  {
>   struct request_queue *q = bdev_get_queue(bdev);
> + int io_err = 0;
>  
>   if (discard && blk_queue_discard(q) && q->limits.discard_zeroes_data &&
> - blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, 0) == 0)
> + (do_blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, 0,
> +  _err) == 0 && io_err == 0))
>   return 0;
>  
>   if (bdev_write_same(bdev) &&
> -- 
> 2.8.0.rc2

-- 
Sitsofe | http://sucs.org/~sits/

Re: [PATCH V2] block: correctly fallback for zeroout

[Sitsofe Wheeler]

On Mon, Jun 06, 2016 at 03:33:58PM -0700, Shaohua Li wrote:
> blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
> fallback to regular write. The problem is discard/writesame doesn't
> return error for -EOPNOTSUPP, then zeroout can't do fallback and leave
> disk data not changed. zeroout should have guaranteed zero-fill
> behavior.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=118581
> 
> V2: move the return value policy to blkdev_issue_discard and
> delete the policy for blkdev_issue_write_same (Martin)
> 
> Cc: Sitsofe Wheeler 
> Cc: Mike Snitzer 
> Cc: Jens Axboe 
> Cc: Martin K. Petersen 
> Signed-off-by: Shaohua Li 
> ---
>  block/blk-lib.c | 49 +++--
>  1 file changed, 31 insertions(+), 18 deletions(-)
> 
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 23d7f30..a3a26c8 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -84,6 +84,28 @@ int __blkdev_issue_discard(struct block_device *bdev, 
> sector_t sector,
>  }
>  EXPORT_SYMBOL(__blkdev_issue_discard);
>  
> +static int do_blkdev_issue_discard(struct block_device *bdev, sector_t 
> sector,
> + sector_t nr_sects, gfp_t gfp_mask, unsigned long flags,
> + int *io_err)
> +{
> + int type = REQ_WRITE | REQ_DISCARD;
> + struct bio *bio = NULL;
> + struct blk_plug plug;
> + int ret;
> +
> + if (flags & BLKDEV_DISCARD_SECURE)
> + type |= REQ_SECURE;
> +
> + blk_start_plug();
> + ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
> + );
> + if (!ret && bio)
> + *io_err = submit_bio_wait(type, bio);
> + blk_finish_plug();
> +
> + return ret;
> +}
> +
>  /**
>   * blkdev_issue_discard - queue a discard
>   * @bdev:blockdev to issue discard for
> @@ -98,23 +120,12 @@ EXPORT_SYMBOL(__blkdev_issue_discard);
>  int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
>   sector_t nr_sects, gfp_t gfp_mask, unsigned long flags)
>  {
> - int type = REQ_WRITE | REQ_DISCARD;
> - struct bio *bio = NULL;
> - struct blk_plug plug;
> - int ret;
> + int ret, io_err;
>  
> - if (flags & BLKDEV_DISCARD_SECURE)
> - type |= REQ_SECURE;
> -
> - blk_start_plug();
> - ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
> - );
> - if (!ret && bio) {
> - ret = submit_bio_wait(type, bio);
> - if (ret == -EOPNOTSUPP)
> - ret = 0;
> - }
> - blk_finish_plug();
> + ret = do_blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask,
> + flags, _err);
> + if (!ret && io_err != -EOPNOTSUPP)
> + ret = io_err;

Because io_err is always consulted if ret is not true shouldn't it be
explicitly initialized to 0 before the call to do_blkdev_issue_discard
(as do_blkdev_issue_discard will only set io_err if bio returned true)?

Perhaps there's an argument that do_blkdev_issue_discard should always
set io_err on all its paths rather than just on errors in case the
caller hasn't initialized it - is there an existing kernel pattern for
this)?

>  
>   return ret;
>  }
> @@ -167,7 +178,7 @@ int blkdev_issue_write_same(struct block_device *bdev, 
> sector_t sector,
>  
>   if (bio)
>   ret = submit_bio_wait(REQ_WRITE | REQ_WRITE_SAME, bio);
> - return ret != -EOPNOTSUPP ? ret : 0;
> + return ret;
>  }
>  EXPORT_SYMBOL(blkdev_issue_write_same);
>  
> @@ -236,9 +247,11 @@ int blkdev_issue_zeroout(struct block_device *bdev, 
> sector_t sector,
>sector_t nr_sects, gfp_t gfp_mask, bool discard)
>  {
>   struct request_queue *q = bdev_get_queue(bdev);
> + int io_err = 0;
>  
>   if (discard && blk_queue_discard(q) && q->limits.discard_zeroes_data &&
> - blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, 0) == 0)
> + (do_blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, 0,
> +  _err) == 0 && io_err == 0))
>   return 0;
>  
>   if (bdev_write_same(bdev) &&
> -- 
> 2.8.0.rc2

-- 
Sitsofe | http://sucs.org/~sits/

Re: [LKP] [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

[Ye Xiaolong]

On Mon, Jun 06, 2016 at 04:53:07PM +0800, Ye Xiaolong wrote:
>On Fri, Jun 03, 2016 at 06:21:09PM -0400, Johannes Weiner wrote:
>>On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote:
>>> Hi,
>>> 
>>> On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
>>> > FYI, we noticed pixz.throughput -9.1% regression due to commit:
>>> > 
>>> > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd 
>>> > watermarks in proportion to memory")
>>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>> > 
>>> > in testcase: pixz
>>> > on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory 
>>> > with following parameters: cpufreq_governor=performance/nr_threads=100%
>>> 
>>> Xiaolong, thanks for the report.
>>> 
>>> It looks like the regression stems from a change in NUMA placement:
>>
>>Scratch that, I was misreading the test results. It's just fewer
>>allocations in general that happen during the fixed testing time.
>>
>>I'm stumped by this report. All this patch does other than affect page
>>reclaim (which is not involved here) is increase the size of the round
>>robin batches in the fair zone allocator. That should *reduce* work in
>>the page allocator, if anything.
>>
>>But I also keep failing to reproduce this - having tried it on the
>>third machine now - neither pixz nor will-it-scale/page_fault1 give me
>>that -8-9% regression:
>>
>>4.5.0-02574-g3ed3a4f:
>>PIXZ-good.log:throughput: 39908733.604941994
>>PIXZ-good.log:throughput: 37067947.25049969
>>PIXZ-good.log:throughput: 38604938.39131216
>>
>>4.5.0-02575-g795ae7a:
>> PIXZ-bad.log:throughput: 39489120.87179377
>> PIXZ-bad.log:throughput: 39307299.288432725
>> PIXZ-bad.log:throughput: 38795994.3329781
>>
>>Is this reliably reproducible with 3ed3a4f vs 795ae7ay?
>
>Yes, it can be stably reproduced in LKP environment, I've run 3ed3a4f0ddffece9 
>for 4 times, and 795ae7a0de6b834a0cc202aa55 for 7 times.
>
>3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
> --
>   fail:runs  %reproductionfail:runs
>   | | |
>   :4   50%   2:7 
> kmsg.Spurious_LAPIC_timer_interrupt_on_cpu
> %stddev %change %stddev
> \  |\
>  78505362 ±  0%  -9.2%   71298182 ±  0%  pixz.throughput
>
>
>>
>>Could I ask you to retry the test with Linus's current head as well as
>>with 795ae7a reverted on top of it? (It's a clean revert.)
>>
>
>Sure, I have queued the test tasks for them, will update the comparison
>once I get the results.

FYI, below is the comparison info between 3ed3a4f, 795ae7ay, v4.7-rc2 and the
revert commit (eaa7f0d).

=
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/testcase:
  gcc-4.9/performance/x86_64-rhel/100%/debian-x86_64-2015-02-07.cgz/ivb43/pixz

commit: 
  3ed3a4f0ddffece942bb2661924d87be4ce63cb7
  795ae7a0de6b834a0cc202aa55c190ef81496665
  v4.7-rc2
  eaa7f0d7239a9508c616f208527cd34eb10ec90f

3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55   v4.7-rc2 
eaa7f0d7239a9508c616f20852
 -- -- 
--
   fail:runs  %reproductionfail:runs  %reproductionfail:runs  
%reproductionfail:runs
   | | | | |
 | |
   :4   50%   2:70%:3   
33%   1:6 kmsg.Spurious_LAPIC_timer_interrupt_on_cpu
   :40%:70%:3   
33%   1:6 kmsg.igb#:#:#:exceed_max#second
 %stddev %change %stddev %change %stddev 
%change %stddev
 \  |\  |\  
|\
  78505362 ±  0%  -9.2%   71298182 ±  0% -11.4%   69554765 ±  0%  
-9.4%   71129419 ±  0%  pixz.throughput
   5586220 ±  2%  -1.6%5498492 ±  2%  +6.4%5942217 ±  2%  
+9.6%6122002 ±  0%  pixz.time.involuntary_context_switches
   6560113 ±  0%  -0.6%6518532 ±  0%  -0.6%6519065 ±  0%  
-1.3%6475587 ±  0%  pixz.time.maximum_resident_set_size
   4582198 ±  2%  -3.6%4416275 ±  2%  -9.0%4167645 ±  4%  
-6.7%4275069 ±  1%  pixz.time.minor_page_faults
  4530 ±  0%  +1.0%   4575 ±  0%  -1.7%   4454 ±  0%  
-1.5%   4463 ±  0%  pixz.time.percent_of_cpu_this_job_got
 92.03 ±  0%  +5.6%  97.23 ± 11% +30.5% 120.08 ±  1% 
+30.0% 119.61 ±  0%  pixz.time.system_time
 14911 ±  0%  +2.1%  15218 ±  0%  -1.1%  14753 ±  1%  
-1.1%  14743 ±  0%  pixz.time.user_time
   6586930 ±  0%  -8.4%6033444 ±  1%  -4.4%6298874 ±  

Re: [LKP] [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

[Ye Xiaolong]

On Mon, Jun 06, 2016 at 04:53:07PM +0800, Ye Xiaolong wrote:
>On Fri, Jun 03, 2016 at 06:21:09PM -0400, Johannes Weiner wrote:
>>On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote:
>>> Hi,
>>> 
>>> On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
>>> > FYI, we noticed pixz.throughput -9.1% regression due to commit:
>>> > 
>>> > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd 
>>> > watermarks in proportion to memory")
>>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>> > 
>>> > in testcase: pixz
>>> > on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory 
>>> > with following parameters: cpufreq_governor=performance/nr_threads=100%
>>> 
>>> Xiaolong, thanks for the report.
>>> 
>>> It looks like the regression stems from a change in NUMA placement:
>>
>>Scratch that, I was misreading the test results. It's just fewer
>>allocations in general that happen during the fixed testing time.
>>
>>I'm stumped by this report. All this patch does other than affect page
>>reclaim (which is not involved here) is increase the size of the round
>>robin batches in the fair zone allocator. That should *reduce* work in
>>the page allocator, if anything.
>>
>>But I also keep failing to reproduce this - having tried it on the
>>third machine now - neither pixz nor will-it-scale/page_fault1 give me
>>that -8-9% regression:
>>
>>4.5.0-02574-g3ed3a4f:
>>PIXZ-good.log:throughput: 39908733.604941994
>>PIXZ-good.log:throughput: 37067947.25049969
>>PIXZ-good.log:throughput: 38604938.39131216
>>
>>4.5.0-02575-g795ae7a:
>> PIXZ-bad.log:throughput: 39489120.87179377
>> PIXZ-bad.log:throughput: 39307299.288432725
>> PIXZ-bad.log:throughput: 38795994.3329781
>>
>>Is this reliably reproducible with 3ed3a4f vs 795ae7ay?
>
>Yes, it can be stably reproduced in LKP environment, I've run 3ed3a4f0ddffece9 
>for 4 times, and 795ae7a0de6b834a0cc202aa55 for 7 times.
>
>3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55
> --
>   fail:runs  %reproductionfail:runs
>   | | |
>   :4   50%   2:7 
> kmsg.Spurious_LAPIC_timer_interrupt_on_cpu
> %stddev %change %stddev
> \  |\
>  78505362 ±  0%  -9.2%   71298182 ±  0%  pixz.throughput
>
>
>>
>>Could I ask you to retry the test with Linus's current head as well as
>>with 795ae7a reverted on top of it? (It's a clean revert.)
>>
>
>Sure, I have queued the test tasks for them, will update the comparison
>once I get the results.

FYI, below is the comparison info between 3ed3a4f, 795ae7ay, v4.7-rc2 and the
revert commit (eaa7f0d).

=
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/testcase:
  gcc-4.9/performance/x86_64-rhel/100%/debian-x86_64-2015-02-07.cgz/ivb43/pixz

commit: 
  3ed3a4f0ddffece942bb2661924d87be4ce63cb7
  795ae7a0de6b834a0cc202aa55c190ef81496665
  v4.7-rc2
  eaa7f0d7239a9508c616f208527cd34eb10ec90f

3ed3a4f0ddffece9 795ae7a0de6b834a0cc202aa55   v4.7-rc2 
eaa7f0d7239a9508c616f20852
 -- -- 
--
   fail:runs  %reproductionfail:runs  %reproductionfail:runs  
%reproductionfail:runs
   | | | | |
 | |
   :4   50%   2:70%:3   
33%   1:6 kmsg.Spurious_LAPIC_timer_interrupt_on_cpu
   :40%:70%:3   
33%   1:6 kmsg.igb#:#:#:exceed_max#second
 %stddev %change %stddev %change %stddev 
%change %stddev
 \  |\  |\  
|\
  78505362 ±  0%  -9.2%   71298182 ±  0% -11.4%   69554765 ±  0%  
-9.4%   71129419 ±  0%  pixz.throughput
   5586220 ±  2%  -1.6%5498492 ±  2%  +6.4%5942217 ±  2%  
+9.6%6122002 ±  0%  pixz.time.involuntary_context_switches
   6560113 ±  0%  -0.6%6518532 ±  0%  -0.6%6519065 ±  0%  
-1.3%6475587 ±  0%  pixz.time.maximum_resident_set_size
   4582198 ±  2%  -3.6%4416275 ±  2%  -9.0%4167645 ±  4%  
-6.7%4275069 ±  1%  pixz.time.minor_page_faults
  4530 ±  0%  +1.0%   4575 ±  0%  -1.7%   4454 ±  0%  
-1.5%   4463 ±  0%  pixz.time.percent_of_cpu_this_job_got
 92.03 ±  0%  +5.6%  97.23 ± 11% +30.5% 120.08 ±  1% 
+30.0% 119.61 ±  0%  pixz.time.system_time
 14911 ±  0%  +2.1%  15218 ±  0%  -1.1%  14753 ±  1%  
-1.1%  14743 ±  0%  pixz.time.user_time
   6586930 ±  0%  -8.4%6033444 ±  1%  -4.4%6298874 ±  

RE: Re: Re: Re: [PATCH] usb: core: fix a double free in the usb driver

[Chung-Geol Kim]

>On Fri, 3 Jun 2016, Chung-Geol Kim wrote:
>
>> Yes, you are right, The presentational errors in order to obtain an 
>> understanding of the process.
>> Therefore, I will be happy to explain again the diagrammatic representation 
>> as shown below.
>> If using usb 3.0 storage(OTG), you can see as below.
>> 
>> ==
>> At *Insert USB(3.0) Storage
>> sequence <1> --> <5>
>> ==
>> VOLD   
>> =|
>>  (uevent)
>>__|___ 
>>   |<5>   |
>>   |  SCSI|
>>   |usb_get_hcd   |
>>   |shared_hcd(kref=3)|
>>   |__|
>>___ |_ 
>>   |<2>|   |<4>   |
>>   |dwc3_otg_sm_work   |   |dwc3_otg_sm_work  |
>>   |usb_get_hcd|   |usb_get_hcd   |
>>   |primary_hcd(kref=2)|   |shared_hcd(kref=2)|
>>   |___|   |__|
>>_|_ |_ 
>>   |<1>|   |<3>   |
>>   |New USB BUS #1 |   |New USB BUS #2|
>>   |usb_create_hcd |   |usb_create_hcd|
>>   |primary_hcd(kref=1)|   |shared_hcd(kref=1)|
>>   |   |   |  |
>>   |bandXX_mutex(alloc)|<-(Link)-bandXX_mutex |
>>   |___|   |__|
>> 
>
>When people present diagrams like this, the universal convention is to 
>show earlier times at the top and later times at the bottom.  That way 
>the order in which you read the diagram is the same as the order in 
>which the events are supposed to occur.
>
>Also, the convention is to put events next to each other if they happen 
>at the same time.  In your diagram, <1> and <3> are next to each other 
>but they don't happen at the same time.

Thank you for your kind explanation. It has been modified as shown below.
=
 At *Insert USB(3.0) Storage
 sequence <1> --> <5>
=
   ___
  |<1>|
  |New USB BUS #1 |
  |usb_create_hcd |
  |primary_hcd(kref=1)|
  |   |
  |bandXX_mutex(alloc)|<--
  |___|  |
   _|_   |
  |<2>|  |
  |dwc3_otg_sm_work   |  |
  |usb_get_hcd|  |
  |primary_hcd(kref=2)|  |
  |___|  |
 |  __
 | |<3>   |
 | |New USB BUS #2|
 | |usb_create_hcd|
 | |shared_hcd(kref=1)|
 | |  |
 --(Link)-bandXX_mutex|
   |__|
|_ 
   |<4>   |
   |dwc3_otg_sm_work  |
   |usb_get_hcd   |
   |shared_hcd(kref=2)|
   |__|
___|__ 
   |<5>   |
   |  SCSI|
   |usb_get_hcd   |
   |shared_hcd(kref=3)|
   |__|
|
(uevent)
---|
 VOLD
=


=
 At *remove USB(3.0) Storage
 sequence <1> --> <5> ((Normal Case))
=
   VOLD
|
(uevent)
  __|___
 |<1>   |
 |  SCSI|
 |usb_put_hcd   |
 |shared_hcd(kref=2)|
 |__|
  |_ 
 |<2>   |
 |dwc3_otg_sm_work  |
 |usb_put_hcd   |
 |shared_hcd(kref=1)|
 |__|
  |_ 
 |<3>   |
 |New USB BUS #2|
 |hcd_release   |
 |shared_hcd(kref=0)|
   

RE: Re: Re: Re: [PATCH] usb: core: fix a double free in the usb driver

[Chung-Geol Kim]

>On Fri, 3 Jun 2016, Chung-Geol Kim wrote:
>
>> Yes, you are right, The presentational errors in order to obtain an 
>> understanding of the process.
>> Therefore, I will be happy to explain again the diagrammatic representation 
>> as shown below.
>> If using usb 3.0 storage(OTG), you can see as below.
>> 
>> ==
>> At *Insert USB(3.0) Storage
>> sequence <1> --> <5>
>> ==
>> VOLD   
>> =|
>>  (uevent)
>>__|___ 
>>   |<5>   |
>>   |  SCSI|
>>   |usb_get_hcd   |
>>   |shared_hcd(kref=3)|
>>   |__|
>>___ |_ 
>>   |<2>|   |<4>   |
>>   |dwc3_otg_sm_work   |   |dwc3_otg_sm_work  |
>>   |usb_get_hcd|   |usb_get_hcd   |
>>   |primary_hcd(kref=2)|   |shared_hcd(kref=2)|
>>   |___|   |__|
>>_|_ |_ 
>>   |<1>|   |<3>   |
>>   |New USB BUS #1 |   |New USB BUS #2|
>>   |usb_create_hcd |   |usb_create_hcd|
>>   |primary_hcd(kref=1)|   |shared_hcd(kref=1)|
>>   |   |   |  |
>>   |bandXX_mutex(alloc)|<-(Link)-bandXX_mutex |
>>   |___|   |__|
>> 
>
>When people present diagrams like this, the universal convention is to 
>show earlier times at the top and later times at the bottom.  That way 
>the order in which you read the diagram is the same as the order in 
>which the events are supposed to occur.
>
>Also, the convention is to put events next to each other if they happen 
>at the same time.  In your diagram, <1> and <3> are next to each other 
>but they don't happen at the same time.

Thank you for your kind explanation. It has been modified as shown below.
=
 At *Insert USB(3.0) Storage
 sequence <1> --> <5>
=
   ___
  |<1>|
  |New USB BUS #1 |
  |usb_create_hcd |
  |primary_hcd(kref=1)|
  |   |
  |bandXX_mutex(alloc)|<--
  |___|  |
   _|_   |
  |<2>|  |
  |dwc3_otg_sm_work   |  |
  |usb_get_hcd|  |
  |primary_hcd(kref=2)|  |
  |___|  |
 |  __
 | |<3>   |
 | |New USB BUS #2|
 | |usb_create_hcd|
 | |shared_hcd(kref=1)|
 | |  |
 --(Link)-bandXX_mutex|
   |__|
|_ 
   |<4>   |
   |dwc3_otg_sm_work  |
   |usb_get_hcd   |
   |shared_hcd(kref=2)|
   |__|
___|__ 
   |<5>   |
   |  SCSI|
   |usb_get_hcd   |
   |shared_hcd(kref=3)|
   |__|
|
(uevent)
---|
 VOLD
=


=
 At *remove USB(3.0) Storage
 sequence <1> --> <5> ((Normal Case))
=
   VOLD
|
(uevent)
  __|___
 |<1>   |
 |  SCSI|
 |usb_put_hcd   |
 |shared_hcd(kref=2)|
 |__|
  |_ 
 |<2>   |
 |dwc3_otg_sm_work  |
 |usb_put_hcd   |
 |shared_hcd(kref=1)|
 |__|
  |_ 
 |<3>   |
 |New USB BUS #2|
 |hcd_release   |
 |shared_hcd(kref=0)|
   

Re: [PATCH net-next 2/3] arm64: bpf: optimize JMP_CALL

[Z Lim]

Hi Will,

On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon  wrote:
> On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
>> Remove superfluous stack frame, saving us 3 instructions for
>> every JMP_CALL.
>>
>> Signed-off-by: Zi Shen Lim 
>> ---
>>  arch/arm64/net/bpf_jit_comp.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
>> index 51abc97..7ae304e 100644
>> --- a/arch/arm64/net/bpf_jit_comp.c
>> +++ b/arch/arm64/net/bpf_jit_comp.c
>> @@ -578,11 +578,8 @@ emit_cond_jmp:
>>   const u64 func = (u64)__bpf_call_base + imm;
>>
>>   emit_a64_mov_i64(tmp, func, ctx);
>> - emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
>> - emit(A64_MOV(1, A64_FP, A64_SP), ctx);
>>   emit(A64_BLR(tmp), ctx);
>>   emit(A64_MOV(1, r0, A64_R(0)), ctx);
>> - emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
>>   break;
>>   }
>
> Is the jitted code intended to be unwindable by standard tools?

Before this patch:
bpf_prologue => push stack frame
...
jmp_call => push stack frame, call bpf_helper*, pop stack frame
...
bpf_epilogue => pop stack frame, ret

Now:
bpf_prologue => push stack frame
...
jmp_call => call bpf_helper*
...
bpf_epilogue => pop stack frame, ret

*Note: bpf_helpers in kernel/bpf/helper.c

So yes, it's still unwindable.

>
> Will

Re: [PATCH net-next 2/3] arm64: bpf: optimize JMP_CALL

[Z Lim]

Hi Will,

On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon  wrote:
> On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
>> Remove superfluous stack frame, saving us 3 instructions for
>> every JMP_CALL.
>>
>> Signed-off-by: Zi Shen Lim 
>> ---
>>  arch/arm64/net/bpf_jit_comp.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
>> index 51abc97..7ae304e 100644
>> --- a/arch/arm64/net/bpf_jit_comp.c
>> +++ b/arch/arm64/net/bpf_jit_comp.c
>> @@ -578,11 +578,8 @@ emit_cond_jmp:
>>   const u64 func = (u64)__bpf_call_base + imm;
>>
>>   emit_a64_mov_i64(tmp, func, ctx);
>> - emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
>> - emit(A64_MOV(1, A64_FP, A64_SP), ctx);
>>   emit(A64_BLR(tmp), ctx);
>>   emit(A64_MOV(1, r0, A64_R(0)), ctx);
>> - emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
>>   break;
>>   }
>
> Is the jitted code intended to be unwindable by standard tools?

Before this patch:
bpf_prologue => push stack frame
...
jmp_call => push stack frame, call bpf_helper*, pop stack frame
...
bpf_epilogue => pop stack frame, ret

Now:
bpf_prologue => push stack frame
...
jmp_call => call bpf_helper*
...
bpf_epilogue => pop stack frame, ret

*Note: bpf_helpers in kernel/bpf/helper.c

So yes, it's still unwindable.

>
> Will

Re: [PATCH 3.10 000/143] 3.10.102-stable review

[Guenter Roeck]

Hi Willy,

On 06/06/2016 09:09 PM, Willy Tarreau wrote:

Hi Guenter,

On Mon, Jun 06, 2016 at 08:46:57PM -0700, Guenter Roeck wrote:

On Sun, Jun 05, 2016 at 12:18:23PM +0200, Willy Tarreau wrote:

The whole patch series can be found in one patch at :
https://kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.102-rc1.gz



Hi Willy,

my auto-builder can not pick up a stable release candidate from a
tarball like this.


I guess you mean from a patch, since it's a patch and not a tarball :-)



Whatever it is :-)


Do you have a repository, either with the patch
series or with the to-be-tested branch, where the builder could
pick it up ?


I don't but I can set something up for you. Would you be OK with a
branch in my account (eg: "3.10-for-guenter") which I "git push -f"
from my local branch ? That way you always pull from the same branch
and we don't care if patches are removed during the process. Just let
me know. Otherwise let me know if a different form is desired.



Yes, that would be excellent. I would suggest to name it something like
stable-3.10-queue, though, to be a bit more generic. After all, other
testers will want to pick it up as well.

Thanks,
Guenter

Re: [PATCH 3.10 000/143] 3.10.102-stable review

[Guenter Roeck]

Hi Willy,

On 06/06/2016 09:09 PM, Willy Tarreau wrote:

Hi Guenter,

On Mon, Jun 06, 2016 at 08:46:57PM -0700, Guenter Roeck wrote:

On Sun, Jun 05, 2016 at 12:18:23PM +0200, Willy Tarreau wrote:

The whole patch series can be found in one patch at :
https://kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.102-rc1.gz



Hi Willy,

my auto-builder can not pick up a stable release candidate from a
tarball like this.


I guess you mean from a patch, since it's a patch and not a tarball :-)



Whatever it is :-)


Do you have a repository, either with the patch
series or with the to-be-tested branch, where the builder could
pick it up ?


I don't but I can set something up for you. Would you be OK with a
branch in my account (eg: "3.10-for-guenter") which I "git push -f"
from my local branch ? That way you always pull from the same branch
and we don't care if patches are removed during the process. Just let
me know. Otherwise let me know if a different form is desired.



Yes, that would be excellent. I would suggest to name it something like
stable-3.10-queue, though, to be a bit more generic. After all, other
testers will want to pick it up as well.

Thanks,
Guenter

Re: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features

[Tony Lindgren]

* Nishanth Menon  [160601 15:51]:
> On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> >>
> >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 
> >> 8d9166b519fd
> >> ("omap2/3/4: Add Kconfig option to compile in typical omap features")
> >> that can be enabled for most boards keystone platforms
> >> without needing to rediscover these in defconfig all over again -
> >> examples include multi_v7_defconfig base and optimizations done on top
> >> of them for keystone platform.
> > 
> > I'd rather remove the option for OMAP as well, it doesn't really fit in with
> > how we do things for other platforms, and selecting a lot of other Kconfig
> > symbols tends to cause circular dependencies.
> 
> Hmm, fair enough -> adding Tony as well if he sees an problem with
> dropping ARCH_OMAP2PLUS_TYPICAL.

Yes there's a problem. Removing that is going to make all the custom
.config files unbootable almost certainly. Just search around on
issues related to not having REGULATOR_FIXED_VOLTAGE selected.

I agree we should not force select things though. And the I2C selection
at least is wrong, we can have PMICs that are not on I2C bus.

Anybody got better ideas what we should do to make the configuration
options more intuitive?

Regards,

Tony

Re: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features

[Tony Lindgren]

* Nishanth Menon  [160601 15:51]:
> On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> >>
> >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 
> >> 8d9166b519fd
> >> ("omap2/3/4: Add Kconfig option to compile in typical omap features")
> >> that can be enabled for most boards keystone platforms
> >> without needing to rediscover these in defconfig all over again -
> >> examples include multi_v7_defconfig base and optimizations done on top
> >> of them for keystone platform.
> > 
> > I'd rather remove the option for OMAP as well, it doesn't really fit in with
> > how we do things for other platforms, and selecting a lot of other Kconfig
> > symbols tends to cause circular dependencies.
> 
> Hmm, fair enough -> adding Tony as well if he sees an problem with
> dropping ARCH_OMAP2PLUS_TYPICAL.

Yes there's a problem. Removing that is going to make all the custom
.config files unbootable almost certainly. Just search around on
issues related to not having REGULATOR_FIXED_VOLTAGE selected.

I agree we should not force select things though. And the I2C selection
at least is wrong, we can have PMICs that are not on I2C bus.

Anybody got better ideas what we should do to make the configuration
options more intuitive?

Regards,

Tony

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

[Viresh Kumar]

On 06-06-16, 23:56, Rafael J. Wysocki wrote:
> Since you are adding new code, you can write it so it doesn't do
> unnecessary checks from the start.

Hmm, I will do all that in this series only now.

> While at it, the "if ((freq < policy->min) || (freq > policy->max))"
> checks in cpufreq_find_index_l() and cpufreq_find_index_h() don't look
> good to me, because they very well may cause those function to return
> -EINVAL even when there's a valid table and that may cause
> acpi_cpufreq_fast_switch() to do bad things.

Hmm. So, the checks are for sure required here, otherwise we may end up
returning a frequency which we aren't allowed to. Also note that 'freq' here
isn't the target-freq, but the entry in the freq-table.

This routine should be returning a valid freq within the ranges specified by
policy->min/max.

Also note that these routines shall *never* return -EINVAL, otherwise it is
mostly a bug we are hitting.

We have enough checks in place to make sure that there is at least one valid
entry in the freq-table which is >= policy->min and <= policy->max.

I will take care of rest of the comments though. Thanks.

-- 
viresh

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

[Viresh Kumar]

On 06-06-16, 23:56, Rafael J. Wysocki wrote:
> Since you are adding new code, you can write it so it doesn't do
> unnecessary checks from the start.

Hmm, I will do all that in this series only now.

> While at it, the "if ((freq < policy->min) || (freq > policy->max))"
> checks in cpufreq_find_index_l() and cpufreq_find_index_h() don't look
> good to me, because they very well may cause those function to return
> -EINVAL even when there's a valid table and that may cause
> acpi_cpufreq_fast_switch() to do bad things.

Hmm. So, the checks are for sure required here, otherwise we may end up
returning a frequency which we aren't allowed to. Also note that 'freq' here
isn't the target-freq, but the entry in the freq-table.

This routine should be returning a valid freq within the ranges specified by
policy->min/max.

Also note that these routines shall *never* return -EINVAL, otherwise it is
mostly a bug we are hitting.

We have enough checks in place to make sure that there is at least one valid
entry in the freq-table which is >= policy->min and <= policy->max.

I will take care of rest of the comments though. Thanks.

-- 
viresh

[patch rfc] locking/rwsem: Add down_write_killable/killable_nested()

[Mike Galbraith]

v4.7 added down_write_killable/killable_nested(), add them to -rt.

Signed-off-by: Mike Galbraith 
---
 include/linux/rwsem_rt.h |   12 
 kernel/locking/rt.c  |   24 
 2 files changed, 36 insertions(+)

--- a/include/linux/rwsem_rt.h
+++ b/include/linux/rwsem_rt.h
@@ -52,8 +52,10 @@ do { \
 } while (0)
 
 extern void rt_down_write(struct rw_semaphore *rwsem);
+extern int __must_check rt_down_write_killable(struct rw_semaphore *rwsem);
 extern void rt_down_read_nested(struct rw_semaphore *rwsem, int subclass);
 extern void rt_down_write_nested(struct rw_semaphore *rwsem, int subclass);
+extern int __must_check rt_down_write_killable_nested(struct rw_semaphore 
*rwsem, int subclass);
 extern void rt_down_write_nested_lock(struct rw_semaphore *rwsem,
  struct lockdep_map *nest);
 extern void rt__down_read(struct rw_semaphore *rwsem);
@@ -100,6 +102,11 @@ static inline void down_write(struct rw_
rt_down_write(sem);
 }
 
+static inline int down_write_killable(struct rw_semaphore *sem)
+{
+   return rt_down_write_killable(sem);
+}
+
 static inline int down_write_trylock(struct rw_semaphore *sem)
 {
return rt_down_write_trylock(sem);
@@ -134,6 +141,11 @@ static inline void down_write_nested(str
 {
rt_down_write_nested(sem, subclass);
 }
+
+static inline int down_write_killable_nested(struct rw_semaphore *sem, int 
subclass)
+{
+   return rt_down_write_killable_nested(sem, subclass);
+}
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 static inline void down_write_nest_lock(struct rw_semaphore *sem,
struct rw_semaphore *nest_lock)
--- a/kernel/locking/rt.c
+++ b/kernel/locking/rt.c
@@ -358,6 +358,18 @@ void  rt_down_write(struct rw_semaphore
 }
 EXPORT_SYMBOL(rt_down_write);
 
+int  rt_down_write_killable(struct rw_semaphore *rwsem)
+{
+   int ret;
+
+   rwsem_acquire(>dep_map, 0, 0, _RET_IP_);
+   ret = rt_mutex_lock_killable(>lock);
+   if (ret)
+   rwsem_release(>dep_map, 1, _RET_IP_);
+   return ret;
+}
+EXPORT_SYMBOL(rt_down_write_killable);
+
 void  rt_down_write_nested(struct rw_semaphore *rwsem, int subclass)
 {
rwsem_acquire(>dep_map, subclass, 0, _RET_IP_);
@@ -365,6 +377,18 @@ void  rt_down_write_nested(struct rw_sem
 }
 EXPORT_SYMBOL(rt_down_write_nested);
 
+int  rt_down_write_killable_nested(struct rw_semaphore *rwsem, int subclass)
+{
+   int ret;
+
+   rwsem_acquire(>dep_map, subclass, 0, _RET_IP_);
+   ret = rt_mutex_lock_killable(>lock);
+   if (ret)
+   rwsem_release(>dep_map, 1, _RET_IP_);
+   return ret;
+}
+EXPORT_SYMBOL(rt_down_write_killable_nested);
+
 void rt_down_write_nested_lock(struct rw_semaphore *rwsem,
   struct lockdep_map *nest)
 {

[patch rfc] locking/rwsem: Add down_write_killable/killable_nested()

[Mike Galbraith]

v4.7 added down_write_killable/killable_nested(), add them to -rt.

Signed-off-by: Mike Galbraith 
---
 include/linux/rwsem_rt.h |   12 
 kernel/locking/rt.c  |   24 
 2 files changed, 36 insertions(+)

--- a/include/linux/rwsem_rt.h
+++ b/include/linux/rwsem_rt.h
@@ -52,8 +52,10 @@ do { \
 } while (0)
 
 extern void rt_down_write(struct rw_semaphore *rwsem);
+extern int __must_check rt_down_write_killable(struct rw_semaphore *rwsem);
 extern void rt_down_read_nested(struct rw_semaphore *rwsem, int subclass);
 extern void rt_down_write_nested(struct rw_semaphore *rwsem, int subclass);
+extern int __must_check rt_down_write_killable_nested(struct rw_semaphore 
*rwsem, int subclass);
 extern void rt_down_write_nested_lock(struct rw_semaphore *rwsem,
  struct lockdep_map *nest);
 extern void rt__down_read(struct rw_semaphore *rwsem);
@@ -100,6 +102,11 @@ static inline void down_write(struct rw_
rt_down_write(sem);
 }
 
+static inline int down_write_killable(struct rw_semaphore *sem)
+{
+   return rt_down_write_killable(sem);
+}
+
 static inline int down_write_trylock(struct rw_semaphore *sem)
 {
return rt_down_write_trylock(sem);
@@ -134,6 +141,11 @@ static inline void down_write_nested(str
 {
rt_down_write_nested(sem, subclass);
 }
+
+static inline int down_write_killable_nested(struct rw_semaphore *sem, int 
subclass)
+{
+   return rt_down_write_killable_nested(sem, subclass);
+}
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 static inline void down_write_nest_lock(struct rw_semaphore *sem,
struct rw_semaphore *nest_lock)
--- a/kernel/locking/rt.c
+++ b/kernel/locking/rt.c
@@ -358,6 +358,18 @@ void  rt_down_write(struct rw_semaphore
 }
 EXPORT_SYMBOL(rt_down_write);
 
+int  rt_down_write_killable(struct rw_semaphore *rwsem)
+{
+   int ret;
+
+   rwsem_acquire(>dep_map, 0, 0, _RET_IP_);
+   ret = rt_mutex_lock_killable(>lock);
+   if (ret)
+   rwsem_release(>dep_map, 1, _RET_IP_);
+   return ret;
+}
+EXPORT_SYMBOL(rt_down_write_killable);
+
 void  rt_down_write_nested(struct rw_semaphore *rwsem, int subclass)
 {
rwsem_acquire(>dep_map, subclass, 0, _RET_IP_);
@@ -365,6 +377,18 @@ void  rt_down_write_nested(struct rw_sem
 }
 EXPORT_SYMBOL(rt_down_write_nested);
 
+int  rt_down_write_killable_nested(struct rw_semaphore *rwsem, int subclass)
+{
+   int ret;
+
+   rwsem_acquire(>dep_map, subclass, 0, _RET_IP_);
+   ret = rt_mutex_lock_killable(>lock);
+   if (ret)
+   rwsem_release(>dep_map, 1, _RET_IP_);
+   return ret;
+}
+EXPORT_SYMBOL(rt_down_write_killable_nested);
+
 void rt_down_write_nested_lock(struct rw_semaphore *rwsem,
   struct lockdep_map *nest)
 {

Re: [PATCH 3.10 000/143] 3.10.102-stable review

[Willy Tarreau]

Hi Guenter,

On Mon, Jun 06, 2016 at 08:46:57PM -0700, Guenter Roeck wrote:
> On Sun, Jun 05, 2016 at 12:18:23PM +0200, Willy Tarreau wrote:
> > The whole patch series can be found in one patch at :
> >
> > https://kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.102-rc1.gz
> > 
> 
> Hi Willy,
> 
> my auto-builder can not pick up a stable release candidate from a
> tarball like this.

I guess you mean from a patch, since it's a patch and not a tarball :-)

> Do you have a repository, either with the patch
> series or with the to-be-tested branch, where the builder could
> pick it up ?

I don't but I can set something up for you. Would you be OK with a
branch in my account (eg: "3.10-for-guenter") which I "git push -f"
from my local branch ? That way you always pull from the same branch
and we don't care if patches are removed during the process. Just let
me know. Otherwise let me know if a different form is desired.

> Also, it would be helpful if you can copy me (li...@roeck-us.net)
> on release annoucements like this.

OK, noted.

Thanks,
Willy

Re: [PATCH 3.10 000/143] 3.10.102-stable review

[Willy Tarreau]

Hi Guenter,

On Mon, Jun 06, 2016 at 08:46:57PM -0700, Guenter Roeck wrote:
> On Sun, Jun 05, 2016 at 12:18:23PM +0200, Willy Tarreau wrote:
> > The whole patch series can be found in one patch at :
> >
> > https://kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.102-rc1.gz
> > 
> 
> Hi Willy,
> 
> my auto-builder can not pick up a stable release candidate from a
> tarball like this.

I guess you mean from a patch, since it's a patch and not a tarball :-)

> Do you have a repository, either with the patch
> series or with the to-be-tested branch, where the builder could
> pick it up ?

I don't but I can set something up for you. Would you be OK with a
branch in my account (eg: "3.10-for-guenter") which I "git push -f"
from my local branch ? That way you always pull from the same branch
and we don't care if patches are removed during the process. Just let
me know. Otherwise let me know if a different form is desired.

> Also, it would be helpful if you can copy me (li...@roeck-us.net)
> on release annoucements like this.

OK, noted.

Thanks,
Willy

Re: [PATCH 4.4 00/99] 4.4.13-stable review

[Guenter Roeck]

On 06/05/2016 02:40 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.13 release.
There are 99 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue Jun  7 21:38:29 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 148 pass: 131 fail: 17
Failed builds:
arm:allmodconfig
arm:davinci_all_defconfig
arm:keystone_defconfig
mips:defconfig
mips:allnoconfig
mips:defconfig
mips:allmodconfig
mips:allnoconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
mips:defconfig
Qemu test results:
total: 101 pass: 82 fail: 19
Failed tests:
arm:beagle:multi_v7_defconfig:omap3-beagle
arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
arm:overo:multi_v7_defconfig:omap3-overo-tobi
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
arm:midway:multi_v7_defconfig:ecx-2000
arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips:fuloong2e_defconfig:fulong2e

arm failures:
drivers/gpio/gpio-davinci.c: In function 'davinci_gpio_probe':
drivers/gpio/gpio-davinci.c:257:16: error: 'struct gpio_chip' has no member 
named 'parent'

Culprit is 'gpio: davinci: fix missed parent conversion'; reverting it appears 
to fix
the problem. Ok, I must be missing something. Off to Greg and Linus Walleij to 
sort out.

mips failures (affecting 4.4, 4.5, 4,6):

arch/mips/mm/cache.c: In function '__update_cache':
arch/mips/mm/cache.c:134:4: error: implicit declaration of function 
'kmap_atomic' [-Werror=implicit-function-declaration]
arch/mips/mm/cache.c:142:4: error: implicit declaration of function 
'__kunmap_atomic'

Seems to be casued by 'MIPS: Handle highmem pages in __update_cache', which can 
not
be easily reverted. The same problem was seen in 4.1; Sasha had solved it, but I
don't know how. Sasha, can you help out ?

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.4 00/99] 4.4.13-stable review

[Guenter Roeck]

On 06/05/2016 02:40 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.13 release.
There are 99 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue Jun  7 21:38:29 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 148 pass: 131 fail: 17
Failed builds:
arm:allmodconfig
arm:davinci_all_defconfig
arm:keystone_defconfig
mips:defconfig
mips:allnoconfig
mips:defconfig
mips:allmodconfig
mips:allnoconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
mips:defconfig
Qemu test results:
total: 101 pass: 82 fail: 19
Failed tests:
arm:beagle:multi_v7_defconfig:omap3-beagle
arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
arm:overo:multi_v7_defconfig:omap3-overo-tobi
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
arm:midway:multi_v7_defconfig:ecx-2000
arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips:fuloong2e_defconfig:fulong2e

arm failures:
drivers/gpio/gpio-davinci.c: In function 'davinci_gpio_probe':
drivers/gpio/gpio-davinci.c:257:16: error: 'struct gpio_chip' has no member 
named 'parent'

Culprit is 'gpio: davinci: fix missed parent conversion'; reverting it appears 
to fix
the problem. Ok, I must be missing something. Off to Greg and Linus Walleij to 
sort out.

mips failures (affecting 4.4, 4.5, 4,6):

arch/mips/mm/cache.c: In function '__update_cache':
arch/mips/mm/cache.c:134:4: error: implicit declaration of function 
'kmap_atomic' [-Werror=implicit-function-declaration]
arch/mips/mm/cache.c:142:4: error: implicit declaration of function 
'__kunmap_atomic'

Seems to be casued by 'MIPS: Handle highmem pages in __update_cache', which can 
not
be easily reverted. The same problem was seen in 4.1; Sasha had solved it, but I
don't know how. Sasha, can you help out ?

Details are available at http://kerneltests.org/builders.

Guenter

Re: kmemleak report after 9082e87bfbf8 ("block: remove struct bio_batch")

[Larry Finger]

On 06/06/2016 11:12 AM, Catalin Marinas wrote:

On Mon, Jun 06, 2016 at 04:13:34PM +0200, Christoph Hellwig wrote:

I've got a few reports of this over the weekend, but it still doesn't
make much sense to me.

Could it be that kmemleak can't deal with the bio_batch logic?  I've
tried to look at the various bio and biovec number entries in
/proc/slabinfo, and while they keep changing a bit during the
system runtime there doesn't seem to be a persistent increase
even after lots of mkfs calls.


I think the reported leaks settle after about 10-20min (2-3 kmemleak
periodic scans), so checking /proc/slabinfo may not be sufficient if
the leak is not growing. The leaks also do not seem to disappear,
otherwise kmemleak would no longer report them (e.g. after kfree, even
if they had been previously reported).


The leak is definitely not related to mkfs. At the moment, my system has been up 
about 26 hours, and has generated 162 of these leaks without ever doing a single 
mkfs. In addition, the box say idle for almost 12 of those hours.


Larry

Re: kmemleak report after 9082e87bfbf8 ("block: remove struct bio_batch")

[Larry Finger]

On 06/06/2016 11:12 AM, Catalin Marinas wrote:

On Mon, Jun 06, 2016 at 04:13:34PM +0200, Christoph Hellwig wrote:

I've got a few reports of this over the weekend, but it still doesn't
make much sense to me.

Could it be that kmemleak can't deal with the bio_batch logic?  I've
tried to look at the various bio and biovec number entries in
/proc/slabinfo, and while they keep changing a bit during the
system runtime there doesn't seem to be a persistent increase
even after lots of mkfs calls.


I think the reported leaks settle after about 10-20min (2-3 kmemleak
periodic scans), so checking /proc/slabinfo may not be sufficient if
the leak is not growing. The leaks also do not seem to disappear,
otherwise kmemleak would no longer report them (e.g. after kfree, even
if they had been previously reported).


The leak is definitely not related to mkfs. At the moment, my system has been up 
about 26 hours, and has generated 162 of these leaks without ever doing a single 
mkfs. In addition, the box say idle for almost 12 of those hours.


Larry

Re: [PATCH V3 1/2] thermal: max77620: Add DT binding doc for thermal driver

[Keerthy]

On Monday 06 June 2016 05:14 PM, Laxman Dewangan wrote:

Maxim Semiconductor MAX77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.

Add DT binding document to details out the DT property related
to MAX77620 thermal functionality.

Signed-off-by: Laxman Dewangan 
---
  .../bindings/thermal/thermal-max77620.txt  | 64 ++
  1 file changed, 64 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/thermal/thermal-max77620.txt

diff --git a/Documentation/devicetree/bindings/thermal/thermal-max77620.txt 
b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
new file mode 100644
index 000..5a500d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
@@ -0,0 +1,64 @@
+Thermal driver for MAX77620 Power management IC from Maxim Semiconductor.
+
+Maxim Semiconductor MAX77620 supports alarm interrupts when its
+die temperature crosses 120C and 140C. These threshold temperatures
+are not configurable. Device does not provide the real temperature
+of die other than just indicating whether temperature is above or
+below threshold level.
+
+Required properties:
+---
+#thermal-sensor-cells: Please refer 
+   for more details.
+   The value must be 0.
+
+For more details, please refer generic thermal DT binding document
+.
+
+Please refer  for mfd DT binding
+document for the MAX77620.
+
+Example:
+
+#include 
+#include 
+...
+
+i2c@7000d000 {
+   spmic: max77620@3c {
+   compatible = "maxim,max77620";
+   :
+   #thermal-sensor-cells = <0>;
+   :::
+   };
+};
+
+cool_dev: cool-dev {
+   compatible = "cooling-dev";
+   #cooling-cells = <2>;
+};
+
+thermal-zones {
+   PMIC-Die {
+   polling-delay = <0>;
+   polling-delay-passive = <0>;
+   thermal-sensors = <>;
+
+   trips {
+   die_temp_thresh: hot-die {
+   temperature = <12>;
+   type = "active";
+   hysteresis = <0>;
+   };
+   };


What about 140C? Isn't that a critical trip point?


+
+   cooling-maps {
+   map0 {
+   trip = <_temp_thresh>;
+   cooling-device = <_dev THERMAL_NO_LIMIT
+ THERMAL_NO_LIMIT>;
+   contribution = <100>;
+   };
+   };
+   };
+};

Re: [PATCH V3 1/2] thermal: max77620: Add DT binding doc for thermal driver

[Keerthy]

On Monday 06 June 2016 05:14 PM, Laxman Dewangan wrote:

Maxim Semiconductor MAX77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.

Add DT binding document to details out the DT property related
to MAX77620 thermal functionality.

Signed-off-by: Laxman Dewangan 
---
  .../bindings/thermal/thermal-max77620.txt  | 64 ++
  1 file changed, 64 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/thermal/thermal-max77620.txt

diff --git a/Documentation/devicetree/bindings/thermal/thermal-max77620.txt 
b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
new file mode 100644
index 000..5a500d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal-max77620.txt
@@ -0,0 +1,64 @@
+Thermal driver for MAX77620 Power management IC from Maxim Semiconductor.
+
+Maxim Semiconductor MAX77620 supports alarm interrupts when its
+die temperature crosses 120C and 140C. These threshold temperatures
+are not configurable. Device does not provide the real temperature
+of die other than just indicating whether temperature is above or
+below threshold level.
+
+Required properties:
+---
+#thermal-sensor-cells: Please refer 
+   for more details.
+   The value must be 0.
+
+For more details, please refer generic thermal DT binding document
+.
+
+Please refer  for mfd DT binding
+document for the MAX77620.
+
+Example:
+
+#include 
+#include 
+...
+
+i2c@7000d000 {
+   spmic: max77620@3c {
+   compatible = "maxim,max77620";
+   :
+   #thermal-sensor-cells = <0>;
+   :::
+   };
+};
+
+cool_dev: cool-dev {
+   compatible = "cooling-dev";
+   #cooling-cells = <2>;
+};
+
+thermal-zones {
+   PMIC-Die {
+   polling-delay = <0>;
+   polling-delay-passive = <0>;
+   thermal-sensors = <>;
+
+   trips {
+   die_temp_thresh: hot-die {
+   temperature = <12>;
+   type = "active";
+   hysteresis = <0>;
+   };
+   };


What about 140C? Isn't that a critical trip point?


+
+   cooling-maps {
+   map0 {
+   trip = <_temp_thresh>;
+   cooling-device = <_dev THERMAL_NO_LIMIT
+ THERMAL_NO_LIMIT>;
+   contribution = <100>;
+   };
+   };
+   };
+};

[PATCH] perf tools: Fix crash in build_id_cache__kallsyms_path()

[Wang Nan]

build_id_cache__kallsyms_path() accept string buffer but also alloc buffer
by itself using asnprintf. Unfortunately, the only user of it passes it
a stack-allocated buffer. Freeing it causes crash like this:

 $ perf script
 *** Error in `/home/wangnan/perf': free(): invalid pointer: 0x7fff9630 
***
 === Backtrace: =
 lib64/libc.so.6(+0x6eeef)[0x75dbaeef]
 lib64/libc.so.6(+0x78cae)[0x75dc4cae]
 lib64/libc.so.6(+0x79987)[0x75dc5987]
 /home/w00229757/perf(build_id_cache__kallsyms_path+0x6b)[0x49681b]
 /home/w00229757/perf[0x4bdd40]
 /home/w00229757/perf(dso__load+0xa3a)[0x4c048a]
 /home/w00229757/perf(map__load+0x6f)[0x4d561f]
 /home/w00229757/perf(thread__find_addr_map+0x235)[0x49e935]
 /home/w00229757/perf(machine__resolve+0x7d)[0x49ec6d]
 /home/w00229757/perf[0x4555a8]
 /home/w00229757/perf[0x4d9507]
 /home/w00229757/perf[0x4d9e80]
 /home/w00229757/perf(ordered_events__flush+0x354)[0x4dd444]
 /home/w00229757/perf(perf_session__process_events+0x3d0)[0x4dc140]
 /home/w00229757/perf(cmd_script+0x12b0)[0x4592e0]
 /home/w00229757/perf[0x4911f1]
 /home/w00229757/perf(main+0x68f)[0x4352ef]
 /lib64/libc.so.6(__libc_start_main+0xf5)[0x75d6dbd5]
 /home/w00229757/perf[0x435415]
 === Memory map: 

This patch simplify build_id_cache__kallsyms_path(), don't even consider
allocate string buffer, so never free anything. The caller of it should
management memory allocation.

Signed-off-by: Wang Nan 
Cc: Masami Hiramatsu 
Cc: Arnaldo Carvalho de Melo 
Fixes: 01412261d994 ("perf buildid-cache: Use path/to/bin/buildid/elf instead 
of path/to/bin/buildid")
---
 tools/perf/util/build-id.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 67f986c..20aef90 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -147,20 +147,17 @@ static int asnprintf(char **strp, size_t size, const char 
*fmt, ...)
 char *build_id_cache__kallsyms_path(const char *sbuild_id, char *bf,
size_t size)
 {
-   bool is_alloc = !!bf;
bool retry_old = true;
 
-   asnprintf(, size, "%s/%s/%s/kallsyms",
- buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
+   snprintf(bf, size, "%s/%s/%s/kallsyms",
+buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
 retry:
if (!access(bf, F_OK))
return bf;
-   if (is_alloc)
-   free(bf);
if (retry_old) {
/* Try old style kallsyms cache */
-   asnprintf(, size, "%s/%s/%s",
- buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
+   snprintf(bf, size, "%s/%s/%s",
+buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
retry_old = false;
goto retry;
}
-- 
1.8.3.4

[PATCH] perf tools: Fix crash in build_id_cache__kallsyms_path()

[Wang Nan]

build_id_cache__kallsyms_path() accept string buffer but also alloc buffer
by itself using asnprintf. Unfortunately, the only user of it passes it
a stack-allocated buffer. Freeing it causes crash like this:

 $ perf script
 *** Error in `/home/wangnan/perf': free(): invalid pointer: 0x7fff9630 
***
 === Backtrace: =
 lib64/libc.so.6(+0x6eeef)[0x75dbaeef]
 lib64/libc.so.6(+0x78cae)[0x75dc4cae]
 lib64/libc.so.6(+0x79987)[0x75dc5987]
 /home/w00229757/perf(build_id_cache__kallsyms_path+0x6b)[0x49681b]
 /home/w00229757/perf[0x4bdd40]
 /home/w00229757/perf(dso__load+0xa3a)[0x4c048a]
 /home/w00229757/perf(map__load+0x6f)[0x4d561f]
 /home/w00229757/perf(thread__find_addr_map+0x235)[0x49e935]
 /home/w00229757/perf(machine__resolve+0x7d)[0x49ec6d]
 /home/w00229757/perf[0x4555a8]
 /home/w00229757/perf[0x4d9507]
 /home/w00229757/perf[0x4d9e80]
 /home/w00229757/perf(ordered_events__flush+0x354)[0x4dd444]
 /home/w00229757/perf(perf_session__process_events+0x3d0)[0x4dc140]
 /home/w00229757/perf(cmd_script+0x12b0)[0x4592e0]
 /home/w00229757/perf[0x4911f1]
 /home/w00229757/perf(main+0x68f)[0x4352ef]
 /lib64/libc.so.6(__libc_start_main+0xf5)[0x75d6dbd5]
 /home/w00229757/perf[0x435415]
 === Memory map: 

This patch simplify build_id_cache__kallsyms_path(), don't even consider
allocate string buffer, so never free anything. The caller of it should
management memory allocation.

Signed-off-by: Wang Nan 
Cc: Masami Hiramatsu 
Cc: Arnaldo Carvalho de Melo 
Fixes: 01412261d994 ("perf buildid-cache: Use path/to/bin/buildid/elf instead 
of path/to/bin/buildid")
---
 tools/perf/util/build-id.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 67f986c..20aef90 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -147,20 +147,17 @@ static int asnprintf(char **strp, size_t size, const char 
*fmt, ...)
 char *build_id_cache__kallsyms_path(const char *sbuild_id, char *bf,
size_t size)
 {
-   bool is_alloc = !!bf;
bool retry_old = true;
 
-   asnprintf(, size, "%s/%s/%s/kallsyms",
- buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
+   snprintf(bf, size, "%s/%s/%s/kallsyms",
+buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
 retry:
if (!access(bf, F_OK))
return bf;
-   if (is_alloc)
-   free(bf);
if (retry_old) {
/* Try old style kallsyms cache */
-   asnprintf(, size, "%s/%s/%s",
- buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
+   snprintf(bf, size, "%s/%s/%s",
+buildid_dir, DSO__NAME_KALLSYMS, sbuild_id);
retry_old = false;
goto retry;
}
-- 
1.8.3.4

Re: [PATCH v13 04/10] arm64: Blacklist non-kprobe-able symbol

[David Long]

On 06/03/2016 11:40 PM, Masami Hiramatsu wrote:

Hi David,

On Thu,  2 Jun 2016 23:26:18 -0400
David Long  wrote:


From: Pratyush Anand 

Add all function symbols which are called from do_debug_exception under
NOKPROBE_SYMBOL, as they can not kprobed.


I see, but this patch should be applied after kprobes
are implemented on arm64.

And also, I have a comment below.


diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 5954881..4359ca8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -563,6 +563,7 @@ asmlinkage void __exception do_sp_pc_abort(unsigned long 
addr,
info.si_addr  = (void __user *)addr;
arm64_notify_die("Oops - SP/PC alignment exception", regs, , esr);
  }
+NOKPROBE_SYMBOL(do_debug_exception)


This seems at wrong place. Please correct it in this patch.

Thank you,




Hmm, yeah not sure how that happened.  It gets fixed in the next patch 
but it shouldn't be like this.


Thanks,
-dl

Re: [PATCH v13 04/10] arm64: Blacklist non-kprobe-able symbol

[David Long]

On 06/03/2016 11:40 PM, Masami Hiramatsu wrote:

Hi David,

On Thu,  2 Jun 2016 23:26:18 -0400
David Long  wrote:


From: Pratyush Anand 

Add all function symbols which are called from do_debug_exception under
NOKPROBE_SYMBOL, as they can not kprobed.


I see, but this patch should be applied after kprobes
are implemented on arm64.

And also, I have a comment below.


diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 5954881..4359ca8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -563,6 +563,7 @@ asmlinkage void __exception do_sp_pc_abort(unsigned long 
addr,
info.si_addr  = (void __user *)addr;
arm64_notify_die("Oops - SP/PC alignment exception", regs, , esr);
  }
+NOKPROBE_SYMBOL(do_debug_exception)


This seems at wrong place. Please correct it in this patch.

Thank you,




Hmm, yeah not sure how that happened.  It gets fixed in the next patch 
but it shouldn't be like this.


Thanks,
-dl

Re: [PATCH 08/14] drm/amdgpu: use drm_crtc_vblank_{get,put}()

[Michel Dänzer]

On 06.06.2016 23:41, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Replace the legacy drm_vblank_{get,put}() with the new helper functions.
> 
> Signed-off-by: Gustavo Padovan 

[...]

> @@ -268,7 +268,7 @@ int amdgpu_crtc_page_flip(struct drm_crtc *crtc,
>   return 0;
>  
>  vblank_cleanup:
> - drm_vblank_put(crtc->dev, amdgpu_crtc->crtc_id);
> + drm_crtc_vblank_put(_crtc->base);

Can just use crtc here instead of _crtc->base. Same for the
radeon patch.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH 08/14] drm/amdgpu: use drm_crtc_vblank_{get,put}()

[Michel Dänzer]

On 06.06.2016 23:41, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Replace the legacy drm_vblank_{get,put}() with the new helper functions.
> 
> Signed-off-by: Gustavo Padovan 

[...]

> @@ -268,7 +268,7 @@ int amdgpu_crtc_page_flip(struct drm_crtc *crtc,
>   return 0;
>  
>  vblank_cleanup:
> - drm_vblank_put(crtc->dev, amdgpu_crtc->crtc_id);
> + drm_crtc_vblank_put(_crtc->base);

Can just use crtc here instead of _crtc->base. Same for the
radeon patch.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

[Magnus Damm]

From: Magnus Damm 

Bump up the maximum numbers of micro-TLBS to 48.

Each IPMMU device instance get micro-TLB assignment via
the "iommus" property in DT. Older SoCs tend to use a
maximum number of 32 micro-TLBd per IPMMU instance however
newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.

At this point no SoC specific handling is done to validate
the maximum number of micro-TLBs, and because of that the
DT information is assumed to be within correct range for
each particular SoC.

If needed in the future SoC specific feature flags can be
added to handle the maximum number of micro-TLBs without
requiring DT changes, however at this point this does not
seem necessary.

Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0029/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2016-06-06 11:17:33.230607110 +0900
@@ -1115,7 +1115,7 @@ static int ipmmu_probe(struct platform_d
}
 
mmu->dev = >dev;
-   mmu->num_utlbs = 32;
+   mmu->num_utlbs = 48;
spin_lock_init(>lock);
bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
mmu->features = match->data;

[PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

[Magnus Damm]

From: Magnus Damm 

Bump up the maximum numbers of micro-TLBS to 48.

Each IPMMU device instance get micro-TLB assignment via
the "iommus" property in DT. Older SoCs tend to use a
maximum number of 32 micro-TLBd per IPMMU instance however
newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.

At this point no SoC specific handling is done to validate
the maximum number of micro-TLBs, and because of that the
DT information is assumed to be within correct range for
each particular SoC.

If needed in the future SoC specific feature flags can be
added to handle the maximum number of micro-TLBs without
requiring DT changes, however at this point this does not
seem necessary.

Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0029/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2016-06-06 11:17:33.230607110 +0900
@@ -1115,7 +1115,7 @@ static int ipmmu_probe(struct platform_d
}
 
mmu->dev = >dev;
-   mmu->num_utlbs = 32;
+   mmu->num_utlbs = 48;
spin_lock_init(>lock);
bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
mmu->features = match->data;

[PATCH 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code

[Magnus Damm]

From: Magnus Damm 

Support the r8a7796 IPMMU by sharing feature flags between
r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook
up the updated compat string.

Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- 0031/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2016-06-06 11:19:40.210607110 +0900
@@ -1074,7 +1074,7 @@ static const struct ipmmu_features ipmmu
.twobit_imttbcr_sl0 = false,
 };
 
-static const struct ipmmu_features ipmmu_features_r8a7795 = {
+static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
.use_ns_alias_offset = false,
.has_cache_leaf_nodes = true,
.has_eight_ctx = true,
@@ -1088,7 +1088,10 @@ static const struct of_device_id ipmmu_o
.data = _features_default,
}, {
.compatible = "renesas,ipmmu-r8a7795",
-   .data = _features_r8a7795,
+   .data = _features_rcar_gen3,
+   }, {
+   .compatible = "renesas,ipmmu-r8a7796",
+   .data = _features_rcar_gen3,
}, {
/* Terminator */
},
@@ -1268,6 +1271,8 @@ IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "r
 ipmmu_vmsa_iommu_of_setup);
 IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795",
 ipmmu_vmsa_iommu_of_setup);
+IOMMU_OF_DECLARE(ipmmu_r8a7796_iommu_of, "renesas,ipmmu-r8a7796",
+ipmmu_vmsa_iommu_of_setup);
 #endif
 
 MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");

[PATCH 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code

[Magnus Damm]

From: Magnus Damm 

Support the r8a7796 IPMMU by sharing feature flags between
r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook
up the updated compat string.

Signed-off-by: Magnus Damm 
---

 drivers/iommu/ipmmu-vmsa.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- 0031/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2016-06-06 11:19:40.210607110 +0900
@@ -1074,7 +1074,7 @@ static const struct ipmmu_features ipmmu
.twobit_imttbcr_sl0 = false,
 };
 
-static const struct ipmmu_features ipmmu_features_r8a7795 = {
+static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
.use_ns_alias_offset = false,
.has_cache_leaf_nodes = true,
.has_eight_ctx = true,
@@ -1088,7 +1088,10 @@ static const struct of_device_id ipmmu_o
.data = _features_default,
}, {
.compatible = "renesas,ipmmu-r8a7795",
-   .data = _features_r8a7795,
+   .data = _features_rcar_gen3,
+   }, {
+   .compatible = "renesas,ipmmu-r8a7796",
+   .data = _features_rcar_gen3,
}, {
/* Terminator */
},
@@ -1268,6 +1271,8 @@ IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "r
 ipmmu_vmsa_iommu_of_setup);
 IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795",
 ipmmu_vmsa_iommu_of_setup);
+IOMMU_OF_DECLARE(ipmmu_r8a7796_iommu_of, "renesas,ipmmu-r8a7796",
+ipmmu_vmsa_iommu_of_setup);
 #endif
 
 MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");