Re: [PATCH 14/26] clk: mvebu: Convert to clk_hw based provider APIs

[Thomas Petazzoni]

Hello,

Thanks for your feedback!

On Wed, 14 Oct 2015 11:21:38 -0700, Stephen Boyd wrote:

> > Stephen, what do you suggest to fix this issue?
> 
> Simplest fix is to revert this hunk.

Indeed, this is the simplest fix. But it's going backward with what you
were trying to do originally, so it isn't really nice either.

> Longer term, we should look into making of_clk_get_parent_name() use
> whatever string has been used when registering the clock,

I am not sure how of_clk_get_parent_name() can know the name of the
clock without clock-output-names in the DT. Without clock-output-names,
the only way to know the name of the parent clock is to actually ask
the driver of the parent clock, no?

> or completely change how we do parent child linkages so that strings
> aren't necessary.

Keep the reference to the DT node + "arguments". Not super simple
either.

> > The easiest solution is to add a clock-output-names property to the
> > coreclk node. This way, of_clk_get_parent_name() will properly
> > resolve the clock name to its correct name (i.e, "cpuclk" in our
> > case) and everything works fine (I've tested). The drawback of this
> > solution is that it breaks backward compatibility with old DTs: a
> > 4.2 DT for Armada XP would no longer work with a >= 4.3 kernel.
> > 
> > Do you have some other suggestions to make ?
> > 
> 
> How about this patch?

I'll give it a try tomorrow, but since it's essentially a revert of
your patch, I believe it should work.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Arnd Bergmann]

On Wednesday 14 October 2015 12:46:19 Scott Branden wrote:
> >
> > My patch fixes it by always selecting COMMON_CLK_IPROC from
> > ARCH_BCM_CYGNUS. I wasn't sure whether you want COMMON_CLK_IPROC
> > to still be user-selectable, so I left that in place. Normally
> > I'd expect it to be a silent option though, that just gets
> > implicitly enabled whenever a platform that needs it is built
> > into the kernel.
> COMMON_CLK_IPROC can be a silent option and selected as Arnd has done below.

Ok, please do that then. If you want to apply my patch directly,
you can remove that last paragraph from the description.

> > Signed-off-by: Arnd Bergmann 
> Acked-by: Scott Branden 

Thanks for taking a look!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.4-rc smpboot: do_boot_cpu failed(-1) to wakeup CPU#1

[Donald Parsons]

On Wed, 2015-10-14 at 12:20 -0400, shrybman wrote:
> All 3.4-rc kernels I have tried displayed this issue.

> This report looks similar https://lkml.org/lkml/2015/9/26/165.
> I also have a Core 2 cpu on a Asus P5B (not deluxe) board.

> ...
>  ACPI: Core revision 20150818
>  ACPI: 1 ACPI AML tables successfully acquired and loaded
>  Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
>  Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
>  CPU: Physical Processor ID: 0
>  CPU: Processor Core ID: 0
>  mce: CPU supports 6 MCE banks
>  CPU0: Thermal monitoring enabled (TM2)
>  process: using mwait in idle threads
>  Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
>  Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32, 1GB 0
>  Freeing SMP alternatives memory: 20K (819b5000 - 819ba000)
>  ftrace: allocating 18583 entries in 73 pages
>  ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
>  smpboot: CPU0: Intel(R) Core(TM)2 CPU  6400  @ 2.13GHz (fam: 06, 
> model: 0f, stepping: 06)
>  Performance Events: PEBS fmt0-, 4-deep LBR, Core2 events, Intel PMU driver.
>  perf_event_intel: PEBS disabled due to CPU errata
>  ... version:2
>  ... bit width:  40
>  ... generic registers:  2
>  ... value mask: 00ff
>  ... max period: 7fff
>  ... fixed-purpose events:   3
>  ... event mask: 00070003
>  x86: Booting SMP configuration:
>   node  #0, CPUs:  #1
>  smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
>  x86: Booted up 1 node, 1 CPUs
>  smpboot: Total of 1 processors activated (4272.42 BogoMIPS)
>  devtmpfs: initialized
> I took a guess and got lucky.
> Reverting "x86/smpboot: Remove APIC.wait_for_init_deassert and atomic 
> init_deasserted" resolved the issue.


As a followup, I updated compiler to gcc-5.2 (no help or change).
I also tried suggested /vmlinuz-4.3.0-rc3 parameter in grub: 
"cpu_init_udelay=1"
which did not help getting missing CPU back online.

So all linux-4.3.0-rc[15] lose the second CPU core.

Don


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 03/12] staging: fsl-mc: dpmcp opening/closing refactoring

[J. German Rivera]

Before, we were opening and closing a mc_io's dpmcp object
in fsl_mc_portal_reset(), since that was the only function that was
calling dpmcp MC operations. However, it is better for maintainability
to open the dpmcp object when it gets associated with an mc_io object,
and close it when this association is terminated. This way, we are free
to call dpmcp operations on a mc_io's dpmcp object at any time, without
having to check if the dpmcp object is opened or not.

Consequently, the creation/teardown of the association between
an mc_io object and a dpmcp is now encapsulated in two functions:
fsl_mc_io_set_dpmcp()/fsl_mc_io_unset_dpmcp(). Besides, setting
the corresponding pointers for the association, these functions
open and close the dpmcp object respectively.
---
CHANGE HISTORY

Changes in v2:
- Removed leftover code that needed to be removed as part of
  the refactoring done in this patch

 drivers/staging/fsl-mc/bus/mc-allocator.c | 15 +--
 drivers/staging/fsl-mc/bus/mc-sys.c   | 74 ---
 drivers/staging/fsl-mc/include/mc-sys.h   |  5 +++
 3 files changed, 73 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index c3222c6..33f5de4 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -373,30 +373,17 @@ EXPORT_SYMBOL_GPL(fsl_mc_portal_free);
 int fsl_mc_portal_reset(struct fsl_mc_io *mc_io)
 {
int error;
-   u16 token;
struct fsl_mc_device *dpmcp_dev = mc_io->dpmcp_dev;

if (WARN_ON(!dpmcp_dev))
return -EINVAL;

-   error = dpmcp_open(mc_io, 0, dpmcp_dev->obj_desc.id, );
-   if (error < 0) {
-   dev_err(_dev->dev, "dpmcp_open() failed: %d\n", error);
-   return error;
-   }
-
-   error = dpmcp_reset(mc_io, 0, token);
+   error = dpmcp_reset(mc_io, 0, dpmcp_dev->mc_handle);
if (error < 0) {
dev_err(_dev->dev, "dpmcp_reset() failed: %d\n", error);
return error;
}

-   error = dpmcp_close(mc_io, 0, token);
-   if (error < 0) {
-   dev_err(_dev->dev, "dpmcp_close() failed: %d\n", error);
-   return error;
-   }
-
return 0;
 }
 EXPORT_SYMBOL_GPL(fsl_mc_portal_reset);
diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c 
b/drivers/staging/fsl-mc/bus/mc-sys.c
index e53acfa..07848a0 100644
--- a/drivers/staging/fsl-mc/bus/mc-sys.c
+++ b/drivers/staging/fsl-mc/bus/mc-sys.c
@@ -75,6 +75,7 @@ int __must_check fsl_create_mc_io(struct device *dev,
  struct fsl_mc_device *dpmcp_dev,
  u32 flags, struct fsl_mc_io **new_mc_io)
 {
+   int error;
struct fsl_mc_io *mc_io;
void __iomem *mc_portal_virt_addr;
struct resource *res;
@@ -87,8 +88,6 @@ int __must_check fsl_create_mc_io(struct device *dev,
mc_io->flags = flags;
mc_io->portal_phys_addr = mc_portal_phys_addr;
mc_io->portal_size = mc_portal_size;
-   mc_io->dpmcp_dev = dpmcp_dev;
-   dpmcp_dev->mc_io = mc_io;
res = devm_request_mem_region(dev,
  mc_portal_phys_addr,
  mc_portal_size,
@@ -111,8 +110,18 @@ int __must_check fsl_create_mc_io(struct device *dev,
}

mc_io->portal_virt_addr = mc_portal_virt_addr;
+   if (dpmcp_dev) {
+   error = fsl_mc_io_set_dpmcp(mc_io, dpmcp_dev);
+   if (error < 0)
+   goto error_destroy_mc_io;
+   }
+
*new_mc_io = mc_io;
return 0;
+
+error_destroy_mc_io:
+   fsl_destroy_mc_io(mc_io);
+   return error;
 }
 EXPORT_SYMBOL_GPL(fsl_create_mc_io);

@@ -123,21 +132,72 @@ EXPORT_SYMBOL_GPL(fsl_create_mc_io);
  */
 void fsl_destroy_mc_io(struct fsl_mc_io *mc_io)
 {
+   struct fsl_mc_device *dpmcp_dev = mc_io->dpmcp_dev;
+
+   if (dpmcp_dev)
+   fsl_mc_io_unset_dpmcp(mc_io);
+
devm_iounmap(mc_io->dev, mc_io->portal_virt_addr);
devm_release_mem_region(mc_io->dev,
mc_io->portal_phys_addr,
mc_io->portal_size);

mc_io->portal_virt_addr = NULL;
-   if (mc_io->dpmcp_dev) {
-   WARN_ON(mc_io->dpmcp_dev->mc_io != mc_io);
-   mc_io->dpmcp_dev->mc_io = NULL;
-   }
-
devm_kfree(mc_io->dev, mc_io);
 }
 EXPORT_SYMBOL_GPL(fsl_destroy_mc_io);

+int fsl_mc_io_set_dpmcp(struct fsl_mc_io *mc_io,
+   struct fsl_mc_device *dpmcp_dev)
+{
+   int error;
+
+   if (WARN_ON(!dpmcp_dev))
+   return -EINVAL;
+
+   if (WARN_ON(mc_io->dpmcp_dev))
+   return -EINVAL;
+
+   if (WARN_ON(dpmcp_dev->mc_io))
+   return -EINVAL;
+
+   error = dpmcp_open(mc_io,
+  0,
+  

[PATCH v2 01/12] staging: fsl-mc: Naming cleanup in fsl_mc-portal_allocate

[J. German Rivera]

mc_adev is a local variable for the allocated dpmcp object.
Renamed mc_adev as dpmcp_dev for clarity.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-allocator.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index d087b4c..a4aa859 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -284,7 +284,7 @@ int __must_check fsl_mc_portal_allocate(struct 
fsl_mc_device *mc_dev,
struct fsl_mc_bus *mc_bus;
phys_addr_t mc_portal_phys_addr;
size_t mc_portal_size;
-   struct fsl_mc_device *mc_adev;
+   struct fsl_mc_device *dpmcp_dev;
int error = -EINVAL;
struct fsl_mc_resource *resource = NULL;
struct fsl_mc_io *mc_io = NULL;
@@ -304,16 +304,16 @@ int __must_check fsl_mc_portal_allocate(struct 
fsl_mc_device *mc_dev,
if (error < 0)
return error;

-   mc_adev = resource->data;
-   if (WARN_ON(!mc_adev))
+   dpmcp_dev = resource->data;
+   if (WARN_ON(!dpmcp_dev))
goto error_cleanup_resource;

-   if (WARN_ON(mc_adev->obj_desc.region_count == 0))
+   if (WARN_ON(dpmcp_dev->obj_desc.region_count == 0))
goto error_cleanup_resource;

-   mc_portal_phys_addr = mc_adev->regions[0].start;
-   mc_portal_size = mc_adev->regions[0].end -
-mc_adev->regions[0].start + 1;
+   mc_portal_phys_addr = dpmcp_dev->regions[0].start;
+   mc_portal_size = dpmcp_dev->regions[0].end -
+dpmcp_dev->regions[0].start + 1;

if (WARN_ON(mc_portal_size != mc_bus_dev->mc_io->portal_size))
goto error_cleanup_resource;
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 05/12] staging_fsl-mc: Changed types of flags, portal size in

[J. German Rivera]

Changed these two fields from 32-bit integers to 16-bit integers in
struct fsl_mc_io, as 32 bits is too much for these fields. This
change does not affect other components since fsl_mc_io is an opaque
type.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/include/mc-sys.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fsl-mc/include/mc-sys.h 
b/drivers/staging/fsl-mc/include/mc-sys.h
index d4fb602..7d44d8c 100644
--- a/drivers/staging/fsl-mc/include/mc-sys.h
+++ b/drivers/staging/fsl-mc/include/mc-sys.h
@@ -54,8 +54,8 @@ struct mc_command;
  */
 struct fsl_mc_io {
struct device *dev;
-   u32 flags;
-   u32 portal_size;
+   u16 flags;
+   u16 portal_size;
phys_addr_t portal_phys_addr;
void __iomem *portal_virt_addr;
struct fsl_mc_device *dpmcp_dev;
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 02/12] staging: fsl-mc: fsl_mc_io object refactoring

[J. German Rivera]

Each fsl_mc_io object is associated with an fsl_mc_device object
of type "dpmcp" representing the MC portal associated with the
fsl_mc_io object. Before, we were representing this association with
an fsl_mc_resource pointer. To enhance code clarity, it is more
straight forward to use an fsl_mc_device pointer instead.
So, this change replaces the 'resource' field in the fsl_mc_io
object with 'dpmcp_dev'. Also, it changes parameter 'resource' of
fsl_create_mc_io() to be an fsl_mc_device pointer instead.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-allocator.c | 34 ++-
 drivers/staging/fsl-mc/bus/mc-sys.c   | 16 +++
 drivers/staging/fsl-mc/include/mc-sys.h   |  8 +++-
 3 files changed, 35 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index a4aa859..c3222c6 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -320,7 +320,7 @@ int __must_check fsl_mc_portal_allocate(struct 
fsl_mc_device *mc_dev,

error = fsl_create_mc_io(_bus_dev->dev,
 mc_portal_phys_addr,
-mc_portal_size, resource,
+mc_portal_size, dpmcp_dev,
 mc_io_flags, _io);
if (error < 0)
goto error_cleanup_resource;
@@ -342,12 +342,22 @@ EXPORT_SYMBOL_GPL(fsl_mc_portal_allocate);
  */
 void fsl_mc_portal_free(struct fsl_mc_io *mc_io)
 {
+   struct fsl_mc_device *dpmcp_dev;
struct fsl_mc_resource *resource;

-   resource = mc_io->resource;
-   if (WARN_ON(resource->type != FSL_MC_POOL_DPMCP))
+   /*
+* Every mc_io obtained by calling fsl_mc_portal_allocate() is supposed
+* to have a DPMCP object associated with.
+*/
+   dpmcp_dev = mc_io->dpmcp_dev;
+   if (WARN_ON(!dpmcp_dev))
+   return;
+
+   resource = dpmcp_dev->resource;
+   if (WARN_ON(!resource || resource->type != FSL_MC_POOL_DPMCP))
return;
-   if (WARN_ON(!resource->data))
+
+   if (WARN_ON(resource->data != dpmcp_dev))
return;

fsl_destroy_mc_io(mc_io);
@@ -364,30 +374,26 @@ int fsl_mc_portal_reset(struct fsl_mc_io *mc_io)
 {
int error;
u16 token;
-   struct fsl_mc_resource *resource = mc_io->resource;
-   struct fsl_mc_device *mc_dev = resource->data;
+   struct fsl_mc_device *dpmcp_dev = mc_io->dpmcp_dev;

-   if (WARN_ON(resource->type != FSL_MC_POOL_DPMCP))
-   return -EINVAL;
-
-   if (WARN_ON(!mc_dev))
+   if (WARN_ON(!dpmcp_dev))
return -EINVAL;

-   error = dpmcp_open(mc_io, 0, mc_dev->obj_desc.id, );
+   error = dpmcp_open(mc_io, 0, dpmcp_dev->obj_desc.id, );
if (error < 0) {
-   dev_err(_dev->dev, "dpmcp_open() failed: %d\n", error);
+   dev_err(_dev->dev, "dpmcp_open() failed: %d\n", error);
return error;
}

error = dpmcp_reset(mc_io, 0, token);
if (error < 0) {
-   dev_err(_dev->dev, "dpmcp_reset() failed: %d\n", error);
+   dev_err(_dev->dev, "dpmcp_reset() failed: %d\n", error);
return error;
}

error = dpmcp_close(mc_io, 0, token);
if (error < 0) {
-   dev_err(_dev->dev, "dpmcp_close() failed: %d\n", error);
+   dev_err(_dev->dev, "dpmcp_close() failed: %d\n", error);
return error;
}

diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c 
b/drivers/staging/fsl-mc/bus/mc-sys.c
index b58b53f..e53acfa 100644
--- a/drivers/staging/fsl-mc/bus/mc-sys.c
+++ b/drivers/staging/fsl-mc/bus/mc-sys.c
@@ -34,10 +34,12 @@

 #include "../include/mc-sys.h"
 #include "../include/mc-cmd.h"
+#include "../include/mc.h"
 #include 
 #include 
 #include 
 #include 
+#include "dpmcp.h"

 /**
  * Timeout in jiffies to wait for the completion of an MC command
@@ -60,8 +62,8 @@
  * @dev: device to be associated with the MC I/O object
  * @mc_portal_phys_addr: physical address of the MC portal to use
  * @mc_portal_size: size in bytes of the MC portal
- * @resource: Pointer to MC bus object allocator resource associated
- * with this MC I/O object or NULL if none.
+ * @dpmcp-dev: Pointer to the DPMCP object associated with this MC I/O
+ * object or NULL if none.
  * @flags: flags for the new MC I/O object
  * @new_mc_io: Area to return pointer to newly created MC I/O object
  *
@@ -70,7 +72,7 @@
 int __must_check fsl_create_mc_io(struct device *dev,
  phys_addr_t mc_portal_phys_addr,
  u32 mc_portal_size,
- struct fsl_mc_resource *resource,
+ struct fsl_mc_device *dpmcp_dev,
  u32 flags, struct fsl_mc_io 

[PATCH v2 07/12] staging: fsl-mc: Fixed alignment of copyright comment

[J. German Rivera]

Whitespace cleanup-- add missing spaces in column 1 of copyright
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/include/dpcon-cmd.h | 60 +++---
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/fsl-mc/include/dpcon-cmd.h 
b/drivers/staging/fsl-mc/include/dpcon-cmd.h
index 2617024..536b2ef 100644
--- a/drivers/staging/fsl-mc/include/dpcon-cmd.h
+++ b/drivers/staging/fsl-mc/include/dpcon-cmd.h
@@ -1,34 +1,34 @@
 /* Copyright 2013-2015 Freescale Semiconductor Inc.
-*
-* Redistribution and use in source and binary forms, with or without
-* modification, are permitted provided that the following conditions are met:
-* * Redistributions of source code must retain the above copyright
-* notice, this list of conditions and the following disclaimer.
-* * Redistributions in binary form must reproduce the above copyright
-* notice, this list of conditions and the following disclaimer in the
-* documentation and/or other materials provided with the distribution.
-* * Neither the name of the above-listed copyright holders nor the
-* names of any contributors may be used to endorse or promote products
-* derived from this software without specific prior written permission.
-*
-*
-* ALTERNATIVELY, this software may be distributed under the terms of the
-* GNU General Public License ("GPL") as published by the Free Software
-* Foundation, either version 2 of that License or (at your option) any
-* later version.
-*
-* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
-* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-* POSSIBILITY OF SUCH DAMAGE.
-*/
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of the above-listed copyright holders nor the
+ * names of any contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
 #ifndef _FSL_DPCON_CMD_H
 #define _FSL_DPCON_CMD_H

--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 06/12] staging: fsl-mc: Removed unused DPMCP macros

[J. German Rivera]

The macros were a left-over from a previous implementation
of the dpmcp APIs and are no longer used.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/dpmcp-cmd.h | 79 --
 1 file changed, 79 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dpmcp-cmd.h 
b/drivers/staging/fsl-mc/bus/dpmcp-cmd.h
index 6cc0fed..a87e9f8 100644
--- a/drivers/staging/fsl-mc/bus/dpmcp-cmd.h
+++ b/drivers/staging/fsl-mc/bus/dpmcp-cmd.h
@@ -54,83 +54,4 @@
 #define DPMCP_CMDID_GET_IRQ_STATUS 0x016
 #define DPMCP_CMDID_CLEAR_IRQ_STATUS   0x017

-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_CREATE(cmd, cfg) \
-   MC_CMD_OP(cmd, 0, 0,  32, int,  cfg->portal_id)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_SET_IRQ(cmd, irq_index, irq_addr, irq_val, user_irq_id) \
-do { \
-   MC_CMD_OP(cmd, 0, 0,  8,  uint8_t,  irq_index);\
-   MC_CMD_OP(cmd, 0, 32, 32, uint32_t, irq_val);\
-   MC_CMD_OP(cmd, 1, 0,  64, uint64_t, irq_addr); \
-   MC_CMD_OP(cmd, 2, 0,  32, int,  user_irq_id); \
-} while (0)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_GET_IRQ(cmd, irq_index) \
-   MC_CMD_OP(cmd, 0, 32, 8,  uint8_t,  irq_index)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_RSP_GET_IRQ(cmd, type, irq_addr, irq_val, user_irq_id) \
-do { \
-   MC_RSP_OP(cmd, 0, 0,  32, uint32_t, irq_val); \
-   MC_RSP_OP(cmd, 1, 0,  64, uint64_t, irq_addr); \
-   MC_RSP_OP(cmd, 2, 0,  32, int,  user_irq_id); \
-   MC_RSP_OP(cmd, 2, 32, 32, int,  type); \
-} while (0)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_SET_IRQ_ENABLE(cmd, irq_index, en) \
-do { \
-   MC_CMD_OP(cmd, 0, 0,  8,  uint8_t,  en); \
-   MC_CMD_OP(cmd, 0, 32, 8,  uint8_t,  irq_index);\
-} while (0)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_GET_IRQ_ENABLE(cmd, irq_index) \
-   MC_CMD_OP(cmd, 0, 32, 8,  uint8_t,  irq_index)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_RSP_GET_IRQ_ENABLE(cmd, en) \
-   MC_RSP_OP(cmd, 0, 0,  8,  uint8_t,  en)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_SET_IRQ_MASK(cmd, irq_index, mask) \
-do { \
-   MC_CMD_OP(cmd, 0, 0,  32, uint32_t, mask);\
-   MC_CMD_OP(cmd, 0, 32, 8,  uint8_t,  irq_index);\
-} while (0)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_GET_IRQ_MASK(cmd, irq_index) \
-   MC_CMD_OP(cmd, 0, 32, 8,  uint8_t,  irq_index)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_RSP_GET_IRQ_MASK(cmd, mask) \
-   MC_RSP_OP(cmd, 0, 0,  32, uint32_t, mask)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_GET_IRQ_STATUS(cmd, irq_index) \
-   MC_CMD_OP(cmd, 0, 32, 8,  uint8_t,  irq_index)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_RSP_GET_IRQ_STATUS(cmd, status) \
-   MC_RSP_OP(cmd, 0, 0,  32, uint32_t, status)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_CMD_CLEAR_IRQ_STATUS(cmd, irq_index, status) \
-do { \
-   MC_CMD_OP(cmd, 0, 0,  32, uint32_t, status); \
-   MC_CMD_OP(cmd, 0, 32, 8,  uint8_t,  irq_index);\
-} while (0)
-
-/*cmd, param, offset, width, type, arg_name */
-#define DPMCP_RSP_GET_ATTRIBUTES(cmd, attr) \
-do { \
-   MC_RSP_OP(cmd, 0, 32, 32, int,  attr->id);\
-   MC_RSP_OP(cmd, 1, 0,  16, uint16_t, attr->version.major);\
-   MC_RSP_OP(cmd, 1, 16, 16, uint16_t, attr->version.minor);\
-} while (0)
-
 #endif /* _FSL_DPMCP_CMD_H */
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 00/12] staging: fsl-mc: Cleanup and bug fixes

[J. German Rivera]

This patch series includes the following code cleanup and
bug fixes for the fsl-mc bus driver:

Patch 1: Naming cleanup in fsl_mc-portal_allocate
Patch 2: fsl_mc_io object refactoring
Patch 3: dpmcp opening/closing refactoring
Patch 4: Changed dev_info() calls to dev_dbg()
Patch 5: Changed types of flags, portal size in
Patch 6: Removed unused DPMCP macros
Patch 7: Fixed alignment of copyright comment
Patch 8: Fixed bug in fsl_mc_allocator_remove
Patch 9: Refactored error exit in allocator probe/remove
Patch 10: Fixed WARN_ON() in fsl_mc_resource_pool_remove_device
Patch 11: Fixed bug in uninitialized root dprc irq count
Patch 12: Added missing initializer in fsl_mc_bus_driver

CHANGE HISTORY

Changes in v2
- Updated only patch 3. There was some leftover code that
  needed to be removed as part of the refactoring done
  in that patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 08/12] staging: fsl-mc: Fixed bug in fsl_mc_allocator_remove

[J. German Rivera]

Call fsl_mc_resource_pool_remove_device() only if mc_dev->resource
is not NULL.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-allocator.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index 527cb4b..e9c3dec 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -511,9 +511,11 @@ static int fsl_mc_allocator_remove(struct fsl_mc_device 
*mc_dev)
if (WARN_ON(!FSL_MC_IS_ALLOCATABLE(mc_dev->obj_desc.type)))
goto out;

-   error = fsl_mc_resource_pool_remove_device(mc_dev);
-   if (error < 0)
-   goto out;
+   if (mc_dev->resource) {
+   error = fsl_mc_resource_pool_remove_device(mc_dev);
+   if (error < 0)
+   goto out;
+   }

dev_dbg(_dev->dev,
"Allocatable MC object device unbound from fsl_mc_allocator 
driver");
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][v5] PM / hibernate: Print the possible panic reason when resuming with inconsistent e820 map

[kbuild test robot]

Hi Chen,

[auto build test ERROR on tip/x86/core -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Chen-Yu/PM-hibernate-Print-the-possible-panic-reason-when-resuming-with-inconsistent-e820-map/20151015-030054
config: m68k-sun3_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   In file included from drivers/tty/sysrq.c:34:0:
>> include/linux/suspend.h:11:25: fatal error: asm/suspend.h: No such file or 
>> directory
#include 
^
   compilation terminated.

vim +11 include/linux/suspend.h

 5  #include 
 6  #include 
 7  #include 
 8  #include 
 9  #include 
10  #include 
  > 11  #include 
12  
13  #ifdef CONFIG_VT
14  extern void pm_set_vt_switch(int);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2 12/12] staging: fsl-mc: Added missing initializer in fsl_mc_bus_driver

[J. German Rivera]

owner needs to be initialized as THIS_MOUDLE.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c 
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 4ac3d07..84db55b 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -790,6 +790,7 @@ MODULE_DEVICE_TABLE(of, fsl_mc_bus_match_table);
 static struct platform_driver fsl_mc_bus_driver = {
.driver = {
   .name = "fsl_mc_bus",
+  .owner = THIS_MODULE,
   .pm = NULL,
   .of_match_table = fsl_mc_bus_match_table,
   },
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 10/12] staging: fsl-mc: Fixed WARN_ON() in fsl_mc_resource_pool_remove_device

[J. German Rivera]

Check that resource is not NULL before de-referencing it.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-allocator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index a45293b..88d1857 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -111,7 +111,7 @@ static int __must_check 
fsl_mc_resource_pool_remove_device(struct fsl_mc_device
goto out;

resource = mc_dev->resource;
-   if (WARN_ON(resource->data != mc_dev))
+   if (WARN_ON(!resource || resource->data != mc_dev))
goto out;

mc_bus_dev = to_fsl_mc_device(mc_dev->dev.parent);
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Linus Torvalds]

On Wed, Oct 14, 2015 at 12:38 PM, Tejun Heo  wrote:
>
> Doesn't seem that way.  This is from 597d0275736d^ - right before
> TIMER_NOT_PINNED is introduced.  add_timer() eventually calls into
> __mod_timer().
>
> if (likely(base->running_timer != timer)) {
> /* See the comment in lock_timer_base() */
> timer_set_base(timer, NULL);
> spin_unlock(>lock);
> base = new_base;
> spin_lock(>lock);
> timer_set_base(timer, base);
>
> It looks like the timers for work items will be reliably queued on the
> local CPU.

.. unless they are running on another cpu at the time, yes.

Also, the new base is not necessarily the current cpu base, although I
think the exceptions to that are pretty rare (ie you have to enable
timer migration etc)

Which I guess might not actually happen with workqueue timers due to
the extra workqueue locking thing, but I'm not sure. It's going to be
very unlikely, regardless, I agree.

> Heh, I don't think much in this area is intended.  It's mostly all
> historical accidents and failures to get things cleaned up in time.

No argument there.

> So, the following two things bother me about this.
>
> * Given that this is the first reported case of breakage, I don't
>   think this is gonna cause lots of criticial issues; however, the
>   only thing this indicates is that there simply hasn't been enough
>   cases where timers actualy migrate.  If we end up migrating timers
>   more actively in the future, it's possible that we'll see more
>   breakages which will likely be subtler.

I agree that that's a real concern.

At the same time, some of the same issues that are pushing people to
move timers around (put idle cores to deeper sleeps etc) would also
argue for moving delayed work around to other cpus if possible.

So I agree that there is a push to make timer cpu targets more dynamic
in a way we historically didn't really have. At the same time, I think
the same forces that want to move timers around would actually likely
want to move delayed work around too...

> * This makes queue_delayed_work() behave differently from queue_work()
>   and when I checked years ago the local queueing guarantee was
>   definitely being depended upon by some users.

Yes. But the delayed work really is different. By definition, we know
that the current cpu is busy and active _right_now_, and so keeping
work on that cpu isn't obviously wrong.

But it's *not* obviously right to schedule something on that
particular cpu a few seconds from now, when it might be happily asleep
and there might be better cpus to bother..

> I do want to get rid of the local queueing guarnatee for all work
> items.  That said, I don't think this is the right way to do it.

Hmm. I guess that for being past rc5, taking your patch is the safe
thing. I really don't like it very much, though.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/7] ARM: Kconfig: Introduce MACH_STM32F429 flag

[Maxime Coquelin]

This patch introduces the MACH_STM32F429 to make possible to only select
STM32F429 pinctrl driver.

By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.

Signed-off-by: Maxime Coquelin 
---
 arch/arm/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724..bf94e54 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -988,6 +988,11 @@ config ARCH_STM32
help
  Support for STMicroelectronics STM32 processors.
 
+config MACH_STM32F429
+   bool "STMicrolectronics STM32F429"
+   depends on ARCH_STM32
+   default y
+
 # Definitions to make life easier
 config ARCH_ACORN
bool
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/7] Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings

[Maxime Coquelin]

Signed-off-by: Maxime Coquelin 
---
 .../bindings/pinctrl/st,stm32-pinctrl.txt  | 113 +
 1 file changed, 113 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
new file mode 100644
index 000..fe6df6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
@@ -0,0 +1,113 @@
+* STM32 GPIO and Pin Mux/Config controller
+
+STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware
+controller. It controls the input/output settings on the available pins and
+also provides ability to multiplex and configure the output of various on-chip
+controllers onto these pads.
+
+Pin controller node:
+Required properies:
+ - compatible: value should be one of the following:
+   (a) "st,stm32f429-pinctrl"
+ - #address-cells: The value of this property must be 1
+ - #size-cells : The value of this property must be 1
+ - ranges  : defines mapping between pin controller node (parent) to
+   gpio-bank node (children).
+ - pins-are-numbered: Specify the subnodes are using numbered pinmux to
+   specify pins.
+
+GPIO controller/bank node:
+Required properties:
+ - gpio-controller : Indicates this device is a GPIO controller
+ - #gpio-cells   : Should be two.
+   The first cell is the pin number
+   The second one is the polarity:
+   - 0 for active high
+   - 1 for active low
+ - reg   : The gpio address range, relative to the pinctrl range
+ - clocks: clock that drives this bank
+ - st,bank-name  : Should be a name string for this bank as specified 
in
+   the datasheet
+
+Optional properties:
+ - reset:: Reference to the reset controller
+
+Example:
+#include 
+...
+
+   pin-controller {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "st,stm32f429-pinctrl";
+   ranges = <0 0x4002 0x3000>;
+   pins-are-numbered;
+
+   gpioa: gpio@4002 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x0 0x400>;
+   resets = <_ahb1 0>;
+   st,bank-name = "GPIOA";
+   };
+   ...
+   pin-functions nodes follow...
+   };
+
+Contents of function subnode node:
+--
+Subnode format
+A pinctrl node should contain at least one subnode representing the
+pinctrl group available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, pullups, drive, output high/low and output speed.
+
+node {
+   pinmux = ;
+   GENERIC_PINCONFIG;
+};
+
+Required properties:
+- pinmux: integer array, represents gpio pin number and mux setting.
+Supported pin number and mux varies for different SoCs, and are defined
+as macros in dt-bindings/pinctrl/-pinfunc.h directly.
+
+Optional properties:
+- GENERIC_PINCONFIG: is the generic pinconfig options to use.
+  Available options are:
+   - bias-disable,
+   - bias-pull-down,
+   - bias-pull-up,
+   - drive-push-pull,
+   - drive-open-drain,
+   - output-low
+   - output-high
+   - slew-rate = , with x being:
+   < 0 > : Low speed
+   < 1 > : Medium speed
+   < 2 > : Fast speed
+   < 3 > : High speed
+
+Example:
+
+pin-controller {
+...
+   usart1_pins_a: usart1@0 {
+   pins1 {
+   pinmux = ;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = ;
+   bias-disable;
+   };
+   };
+};
+
+ {
+   pinctrl-0 = <_pins_a>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/7] ARM: dts: Add USART1 pin config to STM32F429 boards

[Maxime Coquelin]

This patch selects USART1 pin configuration on PA9/PA10 pins
for both Eval and Disco boards.

Signed-off-by: Maxime Coquelin 
---
 arch/arm/boot/dts/stm32429i-eval.dts  |  2 ++
 arch/arm/boot/dts/stm32f429-disco.dts |  2 ++
 arch/arm/boot/dts/stm32f429.dtsi  | 13 +
 3 files changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 6964fc9..71fe17a 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -71,5 +71,7 @@
 };
 
  {
+   pinctrl-0 = <_pins_a>;
+   pinctrl-names = "default";
status = "okay";
 };
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts 
b/arch/arm/boot/dts/stm32f429-disco.dts
index f0b731d..e3ce796 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -71,5 +71,7 @@
 };
 
  {
+   pinctrl-0 = <_pins_a>;
+   pinctrl-names = "default";
status = "okay";
 };
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 9e6e75c..eb3580e 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -263,6 +263,19 @@
clocks = < 0 266>;
st,bank-name = "GPIOK";
};
+
+   usart1_pins_a: usart1@0 {
+   pins1 {
+   pinmux = ;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = 
;
+   bias-disable;
+   };
+   };
};
 
rcc: rcc@40023810 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/7] ARM: dts: Add pinctrl node to STM32F429

[Maxime Coquelin]

The STM32F429 MCU has 11 GPIO banks, with 16 pins per bank.

Signed-off-by: Maxime Coquelin 
---
 arch/arm/boot/dts/stm32f429.dtsi | 97 
 1 file changed, 97 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index d78a481..9e6e75c 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -46,6 +46,7 @@
  */
 
 #include "armv7-m.dtsi"
+#include 
 
 / {
clocks {
@@ -168,6 +169,102 @@
status = "disabled";
};
 
+   pin-controller {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "st,stm32f429-pinctrl";
+   ranges = <0 0x4002 0x3000>;
+   pins-are-numbered;
+
+   gpioa: gpio@4002 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x0 0x400>;
+   clocks = < 0 256>;
+   st,bank-name = "GPIOA";
+   };
+
+   gpiob: gpio@40020400 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x400 0x400>;
+   clocks = < 0 257>;
+   st,bank-name = "GPIOB";
+   };
+
+   gpioc: gpio@40020800 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x800 0x400>;
+   clocks = < 0 258>;
+   st,bank-name = "GPIOC";
+   };
+
+   gpiod: gpio@40020c00 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0xc00 0x400>;
+   clocks = < 0 259>;
+   st,bank-name = "GPIOD";
+   };
+
+   gpioe: gpio@40021000 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x1000 0x400>;
+   clocks = < 0 260>;
+   st,bank-name = "GPIOE";
+   };
+
+   gpiof: gpio@40021400 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x1400 0x400>;
+   clocks = < 0 261>;
+   st,bank-name = "GPIOF";
+   };
+
+   gpiog: gpio@40021800 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x1800 0x400>;
+   clocks = < 0 262>;
+   st,bank-name = "GPIOG";
+   };
+
+   gpioh: gpio@40021c00 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x1c00 0x400>;
+   clocks = < 0 263>;
+   st,bank-name = "GPIOH";
+   };
+
+   gpioi: gpio@40022000 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x2000 0x400>;
+   clocks = < 0 264>;
+   st,bank-name = "GPIOI";
+   };
+
+   gpioj: gpio@40022400 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x2400 0x400>;
+   clocks = < 0 265>;
+   st,bank-name = "GPIOJ";
+   };
+
+   gpiok: gpio@40022800 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x2800 0x400>;
+   clocks = < 0 266>;
+   st,bank-name = "GPIOK";
+   };
+   };
+
rcc: rcc@40023810 {
#clock-cells = <2>;
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/7] pinctrl: Add support STM32 MCUs

[Maxime Coquelin]

This patch adds pinctrl and GPIO support to STMicroelectronic's STM32
family of MCUs.

While it only supports STM32F429 for now, it has been designed to enable
support of other MCUs of the family (e.g. STM32F746).

Signed-off-by: Maxime Coquelin 
---
 drivers/pinctrl/Kconfig   |1 +
 drivers/pinctrl/Makefile  |4 +-
 drivers/pinctrl/stm32/Kconfig |   16 +
 drivers/pinctrl/stm32/Makefile|5 +
 drivers/pinctrl/stm32/pinctrl-stm32.c |  856 +++
 drivers/pinctrl/stm32/pinctrl-stm32.h |   43 +
 drivers/pinctrl/stm32/pinctrl-stm32f429.c | 1598 +
 7 files changed, 2522 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pinctrl/stm32/Kconfig
 create mode 100644 drivers/pinctrl/stm32/Makefile
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 84dd2ed..5749cc4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -249,6 +249,7 @@ source "drivers/pinctrl/sunxi/Kconfig"
 source "drivers/pinctrl/uniphier/Kconfig"
 source "drivers/pinctrl/vt8500/Kconfig"
 source "drivers/pinctrl/mediatek/Kconfig"
+source "drivers/pinctrl/stm32/Kconfig"
 
 config PINCTRL_XWAY
bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index cad077c..6112e91 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -51,5 +51,7 @@ obj-$(CONFIG_PINCTRL_SH_PFC)  += sh-pfc/
 obj-$(CONFIG_PLAT_SPEAR)   += spear/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
 obj-$(CONFIG_ARCH_UNIPHIER)+= uniphier/
-obj-$(CONFIG_ARCH_VT8500)  += vt8500/
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
+obj-$(CONFIG_ARCH_VT8500)  += vt8500/
+obj-$(CONFIG_ARCH_STM32)   += stm32/
+
diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
new file mode 100644
index 000..0f28841
--- /dev/null
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -0,0 +1,16 @@
+if ARCH_STM32 || COMPILE_TEST
+
+config PINCTRL_STM32
+   bool
+   depends on OF
+   select PINMUX
+   select GENERIC_PINCONF
+   select GPIOLIB
+
+config PINCTRL_STM32F429
+   bool "STMicroelectronics STM32F429 pin control" if COMPILE_TEST && 
!MACH_STM32F429
+   depends on OF
+   default MACH_STM32F429
+   select PINCTRL_STM32
+
+endif
diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
new file mode 100644
index 000..fc17d42
--- /dev/null
+++ b/drivers/pinctrl/stm32/Makefile
@@ -0,0 +1,5 @@
+# Core
+obj-$(CONFIG_PINCTRL_STM32) += pinctrl-stm32.o
+
+# SoC Drivers
+obj-$(CONFIG_PINCTRL_STM32F429)+= pinctrl-stm32f429.o
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c 
b/drivers/pinctrl/stm32/pinctrl-stm32.c
new file mode 100644
index 000..4ebceaa
--- /dev/null
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -0,0 +1,856 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author:  Maxime Coquelin 
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * Heavily based on Mediatek's pinctrl driver
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../core.h"
+#include "../pinconf.h"
+#include "../pinctrl-utils.h"
+#include "pinctrl-stm32.h"
+
+#define STM32_GPIO_MODER   0x00
+#define STM32_GPIO_TYPER   0x04
+#define STM32_GPIO_SPEEDR  0x08
+#define STM32_GPIO_PUPDR   0x0c
+#define STM32_GPIO_IDR 0x10
+#define STM32_GPIO_ODR 0x14
+#define STM32_GPIO_BSRR0x18
+#define STM32_GPIO_LCKR0x1c
+#define STM32_GPIO_AFRL0x20
+#define STM32_GPIO_AFRH0x24
+
+#define STM32_GPIO_PINS_PER_BANK 16
+
+#define gpio_range_to_bank(chip) \
+   container_of(chip, struct stm32_gpio_bank, range)
+
+#define gpio_chip_to_bank(chip) \
+   container_of(chip, struct stm32_gpio_bank, gpio_chip)
+
+static const char * const stm32_gpio_functions[] = {
+   "gpio", "af0", "af1",
+   "af2", "af3", "af4",
+   "af5", "af6", "af7",
+   "af8", "af9", "af10",
+   "af11", "af12", "af13",
+   "af14", "af15", "analog",
+};
+
+struct stm32_pinctrl_group {
+   const char *name;
+   unsigned long config;
+   unsigned pin;
+};
+
+struct stm32_gpio_bank {
+   void __iomem *base;
+   struct clk *clk;
+   spinlock_t lock;
+   struct gpio_chip gpio_chip;
+   struct pinctrl_gpio_range range;
+};
+
+struct stm32_pinctrl {
+   struct device *dev;
+   struct pinctrl_dev *pctl_dev;
+   struct pinctrl_desc pctl_desc;
+   struct stm32_pinctrl_group *groups;
+   unsigned ngroups;
+   const char **grp_names;
+   struct stm32_gpio_bank *banks;
+  

[PATCH 5/7] ARM: mach-stm32: Select pinctrl

[Maxime Coquelin]

Signed-off-by: Maxime Coquelin 
---
 arch/arm/Kconfig  | 1 +
 drivers/pinctrl/stm32/pinctrl-stm32f429.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bf94e54..8b1afd4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -985,6 +985,7 @@ config ARCH_STM32
select ARMV7M_SYSTICK
select CLKSRC_STM32
select RESET_CONTROLLER
+   select PINCTRL
help
  Support for STMicroelectronics STM32 processors.
 
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f429.c 
b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
index 3535037..f34016b 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32f429.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
@@ -1564,7 +1564,7 @@ static const struct stm32_desc_pin stm32f429_pins[] = {
),
 };
 
-struct stm32_pinctrl_match_data stm32f429_match_data = {
+static struct stm32_pinctrl_match_data stm32f429_match_data = {
.pins = stm32f429_pins,
.npins = ARRAY_SIZE(stm32f429_pins),
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] sched: select_task_rq() should check cpu_active() like select_fallback_rq()

[Oleg Nesterov]

On 10/14, Peter Zijlstra wrote:
>
> On Mon, Oct 12, 2015 at 07:34:02PM +0200, Oleg Nesterov wrote:
> >
> > I simply can't understand... To me it looks as if we can simply remove
> > the cpu_active() check in select_fallback_rq().
> >
> > If we race with cpu_down(), cpu_active() is cleared by sched_cpu_inactive()
> > which is CPU_PRI_SCHED_INACTIVE  = INT_MIN + 1 priority, so it seems that
> > only cpuset_cpu_inactive() can be called after that and this check is
> > obviously racy anyway.
>
> Racy yes; however select_task_rq() is called with locks held, therefore
> preemption disabled. This serializes us against the sync_sched() in
> cpu_down().

Yes, I even mentioned this below. And this only means that if you see
cpu_active() == T you know that smpboot_park_threads() can't be called
until preempt_disable().

cpu_active() can become false right after the check, preempt_disable()
can't protect from __cpu_notify(CPU_DOWN_PREPARE).

> And note that smpboot_park_threads() runs until after the sync_sched().
> So you cannot add cpu_active() to select_task_rq() for it must allow
> per-cpu tasks to remain on the cpu.

Yes, yes, this is why this patch triggers BUG_ON() before ->park() in
smpboot_thread_fn().

> > So why we can't simply remove select_fallback_rq()->cpu_active() ?
>
> It would allow migration onto a CPU that's known to be going away. That
> doesn't make sense.

But this is not that bad? This is very unlikely and CPU_DYING will
migrate the woken task again.

> > OK, I don't understand the usage of cpu_active_mask in kernel/sched/,
> > and of course I could easily miss something else. But I doubt very
> > much this check can save us from something bad simply because it is
> > racy.
>
> But safely so; if we observe active, it must stay 'active' until we
> enable preemption again.

I don't undertand what "stay active" actually means here. cpu_active()
is not stable. But probably this doesn't matter.

> > Yes, we also have synchronize_sched() after CPU_DOWN_PREPARE, but
> > the only thing we do before stop_machine() is smpboot_park_threads().
> > So this can help (say) set_cpus_allowed_ptr() which uses active_mask,
> > but I don't see how this can connect to ttwu paths.
>
> Say you have a task A running on CPU4, it goes to sleep. We unplug CPU4.
> We then commence unplugging CPU3, concurrently we wake A. A finds that
> its old CPU (4) is no longer online and ends up in fallback looking for
> a new one.
>
> Without the cpu_active() test in fallback, we could place A on CPU3,
> which is on its way down, just not quite dead.

The same can happen with the cpu_active() check we currently have.
And note again that CPU_PRI_SCHED_INACTIVE == INT_MIN + 1. When
sched_cpu_inactive() clears cpu_active() all other callbacks (except
cpuset_cpu_inactive() were already fired.

> Even if this is not strictly buggy its a daft thing to do and tempting
> fate.

See above...

And if we remove this check from select_fallback_rq() we can revert
dd9d3843755da95f6 "sched: Fix cpu_active_mask/cpu_online_mask race".

And revert 875ebe94 "powerpc/smp: Wait until secondaries are active & online".
And a1307bba "s390/smp: wait until secondaries are active & online".

> > And again. If there is some reason we can not do this, say, because
> > ipi to non-active CPU can trigger a warning, or something else, then
> > we can hit the same problem because select_task_rq() does not check
> > cpu_active(). The kernel threads like stoppers/workers are probably
> > fine in any case, but userspace can trigger the race with cpu_up/down.
>
> So the only 'race' is observing active while we're stuck in
> sync_sched(),

Why? select_task_rq() will see cpu_online() == T after sync_sched().

> which is meant to be safe.

Yes, because that damn cpu_active() check doesn't look strictly necessary ;)
Or I misunderstood.

> It also provides us with a
> known spot after which we're sure no new tasks will come onto our dying
> CPU.

You mean that ttwu(task) can't migrate this task to the dying CPU
after synchronize_rcu() and before stop_machine(), this is true.

OK, lets keep this check if you dislike the idea to remove it. But to me
the very fact that select_task_rq() and select_fallback_rq() use different
checks looks just wrong. Even if everything happens to work.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/7] Add STM32 pinctrl/GPIO driver

[Maxime Coquelin]

Hi Linus, all,

As you suggested during the submission of the STM32 machine support,
I reworked the STM32 pinctrl driver to use the standardized pin config
bindings.

The STM32 family has 16 pins per GPIO bank, and the number of bank varies
depending on the model.

Pins can be multiplexed either in GPIO mode, alternate function (up to 15
functions per pin) or analog (for ADC/DAC).

Kind regards,
Maxime

Maxime Coquelin (7):
  ARM: Kconfig: Introduce MACH_STM32F429 flag
  includes: dt-bindings: Add STM32F429 pinctrl DT bindings
  Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings
  pinctrl: Add support STM32 MCUs
  ARM: mach-stm32: Select pinctrl
  ARM: dts: Add pinctrl node to STM32F429
  ARM: dts: Add USART1 pin config to STM32F429 boards

 .../bindings/pinctrl/st,stm32-pinctrl.txt  |  113 ++
 arch/arm/Kconfig   |6 +
 arch/arm/boot/dts/stm32429i-eval.dts   |2 +
 arch/arm/boot/dts/stm32f429-disco.dts  |2 +
 arch/arm/boot/dts/stm32f429.dtsi   |  110 ++
 drivers/pinctrl/Kconfig|1 +
 drivers/pinctrl/Makefile   |4 +-
 drivers/pinctrl/stm32/Kconfig  |   16 +
 drivers/pinctrl/stm32/Makefile |5 +
 drivers/pinctrl/stm32/pinctrl-stm32.c  |  856 +++
 drivers/pinctrl/stm32/pinctrl-stm32.h  |   43 +
 drivers/pinctrl/stm32/pinctrl-stm32f429.c  | 1598 
 include/dt-bindings/pinctrl/pinctrl-stm32.h|   12 +
 include/dt-bindings/pinctrl/stm32f429-pinfunc.h| 1241 +++
 14 files changed, 4008 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
 create mode 100644 drivers/pinctrl/stm32/Kconfig
 create mode 100644 drivers/pinctrl/stm32/Makefile
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h
 create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/7] includes: dt-bindings: Add STM32F429 pinctrl DT bindings

[Maxime Coquelin]

Signed-off-by: Maxime Coquelin 
---
 include/dt-bindings/pinctrl/pinctrl-stm32.h |   12 +
 include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1241 +++
 2 files changed, 1253 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h
 create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

diff --git a/include/dt-bindings/pinctrl/pinctrl-stm32.h 
b/include/dt-bindings/pinctrl/pinctrl-stm32.h
new file mode 100644
index 000..a2e7222
--- /dev/null
+++ b/include/dt-bindings/pinctrl/pinctrl-stm32.h
@@ -0,0 +1,12 @@
+#ifndef _DT_BINDINGS_PINCTRL_STM32_H
+#define _DT_BINDINGS_PINCTRL_STM32_H
+
+#define STM32_PIN_NO(x) ((x) << 8)
+#define STM32_GET_PIN_NO(x) ((x) >> 8)
+#define STM32_GET_PIN_FUNC(x) ((x) & 0xff)
+
+#define STM32_PIN_GPIO 0
+#define STM32_PIN_AF(x)((x) + 1)
+#define STM32_PIN_ANALOG   (STM32_PIN_AF(15) + 1)
+
+#endif /* _DT_BINDINGS_PINCTRL_STM32_H */
diff --git a/include/dt-bindings/pinctrl/stm32f429-pinfunc.h 
b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
new file mode 100644
index 000..979e4eb
--- /dev/null
+++ b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
@@ -0,0 +1,1241 @@
+#ifndef _DT_BINDINGS_STM32F429_PINFUNC_H
+#define _DT_BINDINGS_STM32F429_PINFUNC_H
+
+#include 
+
+#define STM32F429_PA0_FUNC_GPIO (STM32_PIN_NO(0) | STM32_PIN_GPIO)
+#define STM32F429_PA0_FUNC_TIM2_CH1 TIM2_ETR (STM32_PIN_NO(0) | 
STM32_PIN_AF(1))
+#define STM32F429_PA0_FUNC_TIM5_CH1 (STM32_PIN_NO(0) | STM32_PIN_AF(2))
+#define STM32F429_PA0_FUNC_TIM8_ETR (STM32_PIN_NO(0) | STM32_PIN_AF(3))
+#define STM32F429_PA0_FUNC_USART2_CTS (STM32_PIN_NO(0) | STM32_PIN_AF(7))
+#define STM32F429_PA0_FUNC_UART4_TX (STM32_PIN_NO(0) | STM32_PIN_AF(8))
+#define STM32F429_PA0_FUNC_ETH_MII_CRS (STM32_PIN_NO(0) | STM32_PIN_AF(11))
+#define STM32F429_PA0_FUNC_EVENTOUT (STM32_PIN_NO(0) | STM32_PIN_AF(15))
+#define STM32F429_PA0_FUNC_ANALOG (STM32_PIN_NO(0) | STM32_PIN_ANALOG)
+
+#define STM32F429_PA1_FUNC_GPIO (STM32_PIN_NO(1) | STM32_PIN_GPIO)
+#define STM32F429_PA1_FUNC_TIM2_CH2 (STM32_PIN_NO(1) | STM32_PIN_AF(1))
+#define STM32F429_PA1_FUNC_TIM5_CH2 (STM32_PIN_NO(1) | STM32_PIN_AF(2))
+#define STM32F429_PA1_FUNC_USART2_RTS (STM32_PIN_NO(1) | STM32_PIN_AF(7))
+#define STM32F429_PA1_FUNC_UART4_RX (STM32_PIN_NO(1) | STM32_PIN_AF(8))
+#define STM32F429_PA1_FUNC_ETH_MII_RX_CLK ETH_RMII_REF_CLK (STM32_PIN_NO(1) | 
STM32_PIN_AF(11))
+#define STM32F429_PA1_FUNC_EVENTOUT (STM32_PIN_NO(1) | STM32_PIN_AF(15))
+#define STM32F429_PA1_FUNC_ANALOG (STM32_PIN_NO(1) | STM32_PIN_ANALOG)
+
+#define STM32F429_PA2_FUNC_GPIO (STM32_PIN_NO(2) | STM32_PIN_GPIO)
+#define STM32F429_PA2_FUNC_TIM2_CH3 (STM32_PIN_NO(2) | STM32_PIN_AF(1))
+#define STM32F429_PA2_FUNC_TIM5_CH3 (STM32_PIN_NO(2) | STM32_PIN_AF(2))
+#define STM32F429_PA2_FUNC_TIM9_CH1 (STM32_PIN_NO(2) | STM32_PIN_AF(3))
+#define STM32F429_PA2_FUNC_USART2_TX (STM32_PIN_NO(2) | STM32_PIN_AF(7))
+#define STM32F429_PA2_FUNC_ETH_MDIO (STM32_PIN_NO(2) | STM32_PIN_AF(11))
+#define STM32F429_PA2_FUNC_EVENTOUT (STM32_PIN_NO(2) | STM32_PIN_AF(15))
+#define STM32F429_PA2_FUNC_ANALOG (STM32_PIN_NO(2) | STM32_PIN_ANALOG)
+
+#define STM32F429_PA3_FUNC_GPIO (STM32_PIN_NO(3) | STM32_PIN_GPIO)
+#define STM32F429_PA3_FUNC_TIM2_CH4 (STM32_PIN_NO(3) | STM32_PIN_AF(1))
+#define STM32F429_PA3_FUNC_TIM5_CH4 (STM32_PIN_NO(3) | STM32_PIN_AF(2))
+#define STM32F429_PA3_FUNC_TIM9_CH2 (STM32_PIN_NO(3) | STM32_PIN_AF(3))
+#define STM32F429_PA3_FUNC_USART2_RX (STM32_PIN_NO(3) | STM32_PIN_AF(7))
+#define STM32F429_PA3_FUNC_OTG_HS_ULPI_D0 (STM32_PIN_NO(3) | STM32_PIN_AF(10))
+#define STM32F429_PA3_FUNC_ETH_MII_COL (STM32_PIN_NO(3) | STM32_PIN_AF(11))
+#define STM32F429_PA3_FUNC_LCD_B5 (STM32_PIN_NO(3) | STM32_PIN_AF(14))
+#define STM32F429_PA3_FUNC_EVENTOUT (STM32_PIN_NO(3) | STM32_PIN_AF(15))
+#define STM32F429_PA3_FUNC_ANALOG (STM32_PIN_NO(3) | STM32_PIN_ANALOG)
+
+#define STM32F429_PA4_FUNC_GPIO (STM32_PIN_NO(4) | STM32_PIN_GPIO)
+#define STM32F429_PA4_FUNC_SPI1_NSS (STM32_PIN_NO(4) | STM32_PIN_AF(5))
+#define STM32F429_PA4_FUNC_SPI3_NSS I2S3_WS (STM32_PIN_NO(4) | STM32_PIN_AF(6))
+#define STM32F429_PA4_FUNC_USART2_CK (STM32_PIN_NO(4) | STM32_PIN_AF(7))
+#define STM32F429_PA4_FUNC_OTG_HS_SOF (STM32_PIN_NO(4) | STM32_PIN_AF(12))
+#define STM32F429_PA4_FUNC_DCMI_HSYNC (STM32_PIN_NO(4) | STM32_PIN_AF(13))
+#define STM32F429_PA4_FUNC_LCD_VSYNC (STM32_PIN_NO(4) | STM32_PIN_AF(14))
+#define STM32F429_PA4_FUNC_EVENTOUT (STM32_PIN_NO(4) | STM32_PIN_AF(15))
+#define STM32F429_PA4_FUNC_ANALOG (STM32_PIN_NO(4) | STM32_PIN_ANALOG)
+
+#define STM32F429_PA5_FUNC_GPIO (STM32_PIN_NO(5) | STM32_PIN_GPIO)
+#define STM32F429_PA5_FUNC_TIM2_CH1 TIM2_ETR (STM32_PIN_NO(5) | 
STM32_PIN_AF(1))
+#define STM32F429_PA5_FUNC_TIM8_CH1N (STM32_PIN_NO(5) | STM32_PIN_AF(3))
+#define STM32F429_PA5_FUNC_SPI1_SCK (STM32_PIN_NO(5) | STM32_PIN_AF(5))
+#define STM32F429_PA5_FUNC_OTG_HS_ULPI_CK (STM32_PIN_NO(5) | STM32_PIN_AF(10))
+#define STM32F429_PA5_FUNC_EVENTOUT 

[PATCH v2 09/12] staging: fsl-mc: refactored error exit in allocator probe/remove

[J. German Rivera]

Replaced error gotos with direct returns in fsl_mc_allocator_probe()
and fsl_mc_allocator_remove(), since the only error handling done
in those functions is to exit.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-allocator.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index e9c3dec..a45293b 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -474,30 +474,27 @@ static int fsl_mc_allocator_probe(struct fsl_mc_device 
*mc_dev)
enum fsl_mc_pool_type pool_type;
struct fsl_mc_device *mc_bus_dev;
struct fsl_mc_bus *mc_bus;
-   int error = -EINVAL;
+   int error;

if (WARN_ON(!FSL_MC_IS_ALLOCATABLE(mc_dev->obj_desc.type)))
-   goto error;
+   return -EINVAL;

mc_bus_dev = to_fsl_mc_device(mc_dev->dev.parent);
if (WARN_ON(mc_bus_dev->dev.bus != _mc_bus_type))
-   goto error;
+   return -EINVAL;

mc_bus = to_fsl_mc_bus(mc_bus_dev);
error = object_type_to_pool_type(mc_dev->obj_desc.type, _type);
if (error < 0)
-   goto error;
+   return error;

error = fsl_mc_resource_pool_add_device(mc_bus, pool_type, mc_dev);
if (error < 0)
-   goto error;
+   return error;

dev_dbg(_dev->dev,
"Allocatable MC object device bound to fsl_mc_allocator 
driver");
return 0;
-error:
-
-   return error;
 }

 /**
@@ -506,22 +503,20 @@ error:
  */
 static int fsl_mc_allocator_remove(struct fsl_mc_device *mc_dev)
 {
-   int error = -EINVAL;
+   int error;

if (WARN_ON(!FSL_MC_IS_ALLOCATABLE(mc_dev->obj_desc.type)))
-   goto out;
+   return -EINVAL;

if (mc_dev->resource) {
error = fsl_mc_resource_pool_remove_device(mc_dev);
if (error < 0)
-   goto out;
+   return error;
}

dev_dbg(_dev->dev,
"Allocatable MC object device unbound from fsl_mc_allocator 
driver");
-   error = 0;
-out:
-   return error;
+   return 0;
 }

 static const struct fsl_mc_device_match_id match_id_table[] = {
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 11/12] staging: fsl-mc: fixed bug in uninitialized root dprc irq count

[J. German Rivera]

When initializing the object attributes for the root dprc, the
irq_count was uninitialized. Initialize it to 1.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c 
b/drivers/staging/fsl-mc/bus/mc-bus.c
index fd13053..4ac3d07 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -749,6 +749,7 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
obj_desc.id = container_id;
obj_desc.ver_major = DPRC_VER_MAJOR;
obj_desc.ver_minor = DPRC_VER_MINOR;
+   obj_desc.irq_count = 1;
obj_desc.region_count = 0;

error = fsl_mc_device_add(_desc, mc_io, >dev, _bus_dev);
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 04/12] staging: fsl-mc: Changed dev_info() calls to dev_dbg()

[J. German Rivera]

Changed dev_info() calls to dev_dbg() in
fsl_mc_allocator_probe/fsl_mc_allocator_remove, as they
are useful only for debugging.
---
CHANGE HISTORY

Changes in v2: none

 drivers/staging/fsl-mc/bus/mc-allocator.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c 
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index 33f5de4..527cb4b 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -492,8 +492,8 @@ static int fsl_mc_allocator_probe(struct fsl_mc_device 
*mc_dev)
if (error < 0)
goto error;

-   dev_info(_dev->dev,
-"Allocatable MC object device bound to fsl_mc_allocator 
driver");
+   dev_dbg(_dev->dev,
+   "Allocatable MC object device bound to fsl_mc_allocator 
driver");
return 0;
 error:

@@ -515,8 +515,8 @@ static int fsl_mc_allocator_remove(struct fsl_mc_device 
*mc_dev)
if (error < 0)
goto out;

-   dev_info(_dev->dev,
-"Allocatable MC object device unbound from fsl_mc_allocator 
driver");
+   dev_dbg(_dev->dev,
+   "Allocatable MC object device unbound from fsl_mc_allocator 
driver");
error = 0;
 out:
return error;
--
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 01:13 PM, Tony Lindgren wrote:
> * Franklin S Cooper Jr.  [151014 09:27]:
>>
>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr.  [151014 07:37]:
 On 10/14/2015 09:11 AM, Roger Quadros wrote:
> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>> Franklin,
>>>
>>> On 14/10/15 14:36, Roger Quadros wrote:
 On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Switch from dma_request_channel to allow passing dma channel
> information from DT rather than hardcoding a value.
>
> Signed-off-by: Franklin S Cooper Jr 
 Acked-by: Roger Quadros 

> ---
>  drivers/mtd/nand/omap2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index d0f2620..957c32f 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
> platform_device *pdev)
>   dma_cap_zero(mask);
>   dma_cap_set(DMA_SLAVE, mask);
>   sig = OMAP24XX_DMA_GPMC;
> - info->dma = dma_request_channel(mask, 
> omap_dma_filter_fn, );
> + info->dma = dma_request_slave_channel_compat(mask,
> + omap_dma_filter_fn, , pdev->dev.parent, 
> "rxtx");
> +
>>> Just discovered that you are using the parent device node.
>>>
>>> How about moving the dma bindings to the nand node instead and using
>>> pdev->dev here?
>> Roger,
>>
>> From what I can tell the interrupt number and the dma channel will 
>> always be
>> the same no matter what. Doesn't matter if you have multiple nands or a
>> combination of nands and nors. Since that is the case I think it just 
>> makes
>> sense to leave it in the gpmc parent node and define it once.
> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> or only for NAND?
 The dma seems tied to the prefetch. From what I can tell the prefetch is 
 only
 used by nand.
> Let's also get Tony's inputs on this.
 Sure.
>>> Hmm so what would keep other devices from using the prefetch
>> Looking at the TRM any references to the prefetch are always with respect to
>> NAND.
>>
>> I also see the below mentioned in the TRM.
>> Pre-fetch and write posting engine associated with system DMA to get full 
>> performance from NAND
>> device with minimum impact on NOR/SRAM concurrent access.
> OK up to you guys to figure out if it may be usable in a generic way then :)
Ok I just got clarification from hw folks. DMA for GPMC can be used for any of 
the
various modes. But the prefetch is specific to NAND.
>
> Regards,
>
> Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

On 15-10-13 03:23 PM, Arnd Bergmann wrote:

On Tuesday 13 October 2015 18:04:50 Jon Mason wrote:



On a related note, I'm seeing problems when CONFIG_CYGNUS is set but
CONFIG_COMMON_CLK_IPROC is disabled, as that currently leads to a link
failure.


I can double check, but it should be on by default when Cygnus is
enabled.  If you send me the error, I'll be happy to fix it.



The problem is not that it's off by default but that it can be
disabled, so it breaks some 'make randconfig' builds with this
message:

drivers/built-in.o: In function `cygnus_armpll_init':
:(.init.text+0x1d290): undefined reference to `iproc_armpll_setup'
drivers/built-in.o: In function `cygnus_genpll_clk_init':
:(.init.text+0x1d2c4): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_lcpll0_clk_init':
:(.init.text+0x1d304): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_mipipll_clk_init':
:(.init.text+0x1d344): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_asiu_init':
:(.init.text+0x1d370): undefined reference to `iproc_asiu_setup'

My patch fixes it by always selecting COMMON_CLK_IPROC from
ARCH_BCM_CYGNUS. I wasn't sure whether you want COMMON_CLK_IPROC
to still be user-selectable, so I left that in place. Normally
I'd expect it to be a silent option though, that just gets
implicitly enabled whenever a platform that needs it is built
into the kernel.

COMMON_CLK_IPROC can be a silent option and selected as Arnd has done below.


Signed-off-by: Arnd Bergmann 

Acked-by: Scott Branden 



diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 1319c3c14327..35234e563cd8 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -29,6 +29,7 @@ config ARCH_BCM_IPROC
  config ARCH_BCM_CYGNUS
bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+   select COMMON_CLK_IPROC
help
  Enable support for the Cygnus family,
  which includes the following variants:



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] acpi: set return value to const char for some functions

[kbuild test robot]

Hi LABBE,

[auto build test ERROR on pm/linux-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/LABBE-Corentin/acpi-set-return-value-to-const-char-for-some-functions/20151015-030935
config: i386-randconfig-s1-201541 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/acpi/acpica/utdecode.c:414:13: error: conflicting types for 
>> 'acpi_ut_get_mutex_name'
const char *acpi_ut_get_mutex_name(u32 mutex_id)
^
   In file included from drivers/acpi/acpica/accommon.h:61:0,
from drivers/acpi/acpica/utdecode.c:45:
   drivers/acpi/acpica/acutils.h:187:7: note: previous declaration of 
'acpi_ut_get_mutex_name' was here
char *acpi_ut_get_mutex_name(u32 mutex_id);
  ^

vim +/acpi_ut_get_mutex_name +414 drivers/acpi/acpica/utdecode.c

   408  "ACPI_MTX_Caches",
   409  "ACPI_MTX_Memory",
   410  "ACPI_MTX_CommandComplete",
   411  "ACPI_MTX_CommandReady"
   412  };
   413  
 > 414  const char *acpi_ut_get_mutex_name(u32 mutex_id)
   415  {
   416  
   417  if (mutex_id > ACPI_MAX_MUTEX) {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v2 for-next] EDAC: use edac_debugfs_remove_recursive instead of debugfs_remove

[Borislav Petkov]

On Wed, Oct 14, 2015 at 09:49:24AM +0800, Tan Xiaojun wrote:
> debugfs_remove is used to remove a file or an empty directory from
> the debugfs filesystem, but mci->debugfs is not empty.
> 
> This is not easily discovered, because debugfs_remove return nothing
> when failed. It can be test like below:
> 
> 1)open EDAC config and open CONFIG_EDAC_DEBUG
> 2)insmod a edac_mc module (like i3000_edac or others in drivers/edac/)
> 3)rmmod this module
> 4)we can also see files under /sys/kernel/debug/edac/ like
>   "fake_inject"
> 
> Reported-by: Yun Wu (Abel) 
> Signed-off-by: Tan Xiaojun 

Applied,
thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] dt-bindings: Add new boards to bcm4708 DT bindings

[Scott Branden]

Hi Jon,

Yes, please only add SoC part number compatible strings, not board 
compatible strings.


On 15-10-14 08:34 AM, Jon Mason wrote:

On Tue, Oct 13, 2015 at 03:37:49PM -0700, Florian Fainelli wrote:

On 13/10/15 14:40, Jon Mason wrote:

On Sat, Oct 10, 2015 at 04:42:04PM +0200, Hauke Mehrtens wrote:

On 10/03/2015 12:22 AM, Jon Mason wrote:

Add the 4708, 4709, and 953012k SVKs to the the documentation for the
Broadcom Northstar device tree bindings.

Signed-off-by: Jon Mason 
---
  Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
index 6b0f49f..bdf4c06 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt


What should be documented in this file? This is more a question to the
guys more familiar with arm in Linux. Currently the Linux kernel only
supports brcm,bcm4708 and all goes back to that one.


I was under the impression that all boards should be added to these
files.  We have been doing so for Cygnus and NSP.


Tracking exactly which boards are supported by the brcm,bcm4708
compatible string might be tedious, I tend to agree with just listing
the supported SoCs, and leaving the specific board compatibles to the
individual DTS files instead.


Ok, I'll simply add entries for NS and 4709 to this.
Good - we have only been adding SoC compatible strings for Cygnus and 
NSP - not board compatibles.




Thanks,
Jon





Thanks,
Jon




@@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
properties:

  Required root node property:

+bcm94709
  compatible = "brcm,bcm4708";
+
+bcm94709
+compatible = "brcm,bcm4709", "brcm,bcm4708";
+
+bcm953012k
+compatible = "brcm,bcm5301k", "brcm,bcm4708";






--
Florian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCHv3 00/56] perf stat: Add scripting support

[Liang, Kan]

> 
> On Fri, Oct 09, 2015 at 06:31:23PM +, Liang, Kan wrote:
> 
> SNIP
> 
> > > could not reproduce this one.. any chance you could compile with
> > > DEBUG=1 and re-run in gdb for more details? like which of the frees
> > > got crazy.. ?
> > >
> > The crash is not caused by this patch set. It's also a bug in current perf.
> > I've submitted a patch for that.
> > https://lkml.org/lkml/2015/10/9/575
> >
> > Thanks,
> > Kan
> 
> I pushed fixed code into my perf/stat_script branch, could you please test?
> 

The new fixed code works well. I don't find any issues so far.

Kan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][v5] PM / hibernate: Print the possible panic reason when resuming with inconsistent e820 map

[kbuild test robot]

Hi Chen,

[auto build test ERROR on tip/x86/core -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Chen-Yu/PM-hibernate-Print-the-possible-panic-reason-when-resuming-with-inconsistent-e820-map/20151015-030054
config: i386-randconfig-s1-201541 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/kernel/asm-offsets.c:12:0:
>> include/linux/suspend.h:366:20: error: static declaration of 
>> 'arch_image_info_check' follows non-static declaration
static inline bool arch_image_info_check(const char *new,
   ^
   In file included from include/linux/suspend.h:11:0,
from arch/x86/kernel/asm-offsets.c:12:
   arch/x86/include/asm/suspend.h:8:13: note: previous declaration of 
'arch_image_info_check' was here
extern bool arch_image_info_check(const char *new, const char *old);
^
   In file included from arch/x86/kernel/asm-offsets.c:12:0:
>> include/linux/suspend.h:372:19: error: static declaration of 
>> 'arch_image_info_save' follows non-static declaration
static inline int arch_image_info_save(char *dst,
  ^
   In file included from include/linux/suspend.h:11:0,
from arch/x86/kernel/asm-offsets.c:12:
   arch/x86/include/asm/suspend.h:7:12: note: previous declaration of 
'arch_image_info_save' was here
extern int arch_image_info_save(char *dst, char *src, unsigned int 
limit_len);
   ^
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +/arch_image_info_check +366 include/linux/suspend.h

   360  static inline int hibernate(void) { return -ENOSYS; }
   361  static inline bool system_entering_hibernation(void) { return false; }
   362  static inline bool hibernation_available(void) { return false; }
   363  #endif /* CONFIG_HIBERNATION */
   364  
   365  #ifndef CONFIG_ARCH_RESUME_IMAGE_CHECKER
 > 366  static inline bool arch_image_info_check(const char *new,
   367   const char *old)
   368  {
   369  return true;
   370  }
   371  
 > 372  static inline int arch_image_info_save(char *dst,
   373  char *src,
   374  unsigned int limit_len)
   375  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled

[Javier Martinez Canillas]

On 10/14/2015 09:08 PM, Javier Martinez Canillas wrote:
> Hello Stephen,
> 
> On 10/14/2015 08:38 PM, Stephen Boyd wrote:
>> On 10/13, Javier Martinez Canillas wrote:
>>> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
>>> index 1530c9352a76..fc50b6264bed 100644
>>> --- a/drivers/clk/versatile/Kconfig
>>> +++ b/drivers/clk/versatile/Kconfig
>>> @@ -1,6 +1,6 @@
>>>  config COMMON_CLK_VERSATILE
>>> bool "Clock driver for ARM Reference designs"
>>> -   depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64
>>> +   depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 
>>> || COMPILE_TEST
>>
>> Have you compiled these drivers on an architecture that doesn't
>> have IOMEM? Perhaps tile or um? I'm all for more build coverage,
>> but it's not always as simple as just sprinkling some
>> COMPILE_TEST around the Kconfigs.
>>
> 
> No, I only build tested on arm32 and x86. The 0-day bot haven't reported a
> build error yet and I didn't see any platform dependent code in the drivers.
> 

BTW, all clk drivers depends on COMMON_CLK so these won't even be built in
tile or um since that symbol isn't selected there. Or did I misunderstand?

Having said that, I see that enabling COMPILE_TEST will attempt to build
in many archs [0] that I don't have a toolchain to test. So I'm OK if you
drop this patch and sorry for the inconvenience.

[0]:
$ git grep "select COMMON_CLK" arch/ | cut -d '/' -f2 | uniq 
arc
arm
arm64
h8300
microblaze
mips
powerpc
x86
xtensa

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Tejun Heo]

Hello, Linus.

On Wed, Oct 14, 2015 at 12:16:48PM -0700, Linus Torvalds wrote:
> On Wed, Oct 14, 2015 at 12:02 PM, Tejun Heo  wrote:
> >
> > But wasn't add_timer() always CPU-local at the time?  add_timer()
> > allowing cross-cpu migrations came way after that.
> 
> add_timer() has actually never been "local CPU only" either.
> 
> What add_timer() does is to keep the timer on the old CPU timer wheel
> if it was active, and if it wasn't, put it on the current CPU timer
> wheel.

Doesn't seem that way.  This is from 597d0275736d^ - right before
TIMER_NOT_PINNED is introduced.  add_timer() eventually calls into
__mod_timer().

static inline int
__mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
{
...
base = lock_timer_base(timer, );
...
new_base = __get_cpu_var(tvec_bases);

if (base != new_base) {
...
if (likely(base->running_timer != timer)) {
/* See the comment in lock_timer_base() */
timer_set_base(timer, NULL);
spin_unlock(>lock);
base = new_base;
spin_lock(>lock);
timer_set_base(timer, base);
}
}
...
internal_add_timer(base, timer);
...
}

It looks like the timers for work items will be reliably queued on the
local CPU.

> So again, by pure *accident*, if you don't end up ever modifying an
> already-active timer, then yes, it ended up being local. But even
> then, things like suspend/resume can move timers around, afaik, so
> even then it has never been a real guarantee.
> 
> And I see absolutely no sign that the local cpu case has ever been 
> intentional.

Heh, I don't think much in this area is intended.  It's mostly all
historical accidents and failures to get things cleaned up in time.

> Now, obviously, that said there is obviously at least one case that
> seems to have relied on it (ie the mm/vmstat.c case), but I think we
> should just fix that.
> 
> If it turns out that there really are *lots* of cases where
> "schedule_delayed_work()" expects the work to always run on the CPU
> that it is scheduled on, then we should probably take your patch just
> because it's too painful not to.
> 
> But I'd like to avoid that if possible.

So, the following two things bother me about this.

* Given that this is the first reported case of breakage, I don't
  think this is gonna cause lots of criticial issues; however, the
  only thing this indicates is that there simply hasn't been enough
  cases where timers actualy migrate.  If we end up migrating timers
  more actively in the future, it's possible that we'll see more
  breakages which will likely be subtler.

* This makes queue_delayed_work() behave differently from queue_work()
  and when I checked years ago the local queueing guarantee was
  definitely being depended upon by some users.

I do want to get rid of the local queueing guarnatee for all work
items.  That said, I don't think this is the right way to do it.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: octeon: fixed few coding style warnings

[Aaro Koskinen]

Hi,

On Wed, Oct 14, 2015 at 07:36:37PM +0530, Sakshi Bansal wrote:
> Fixed allignment issues and line over 80 characters

You are also doing many other things which are not mention in the
commit log.

>   /*
> -   printk_ratelimited("Port %d received 0xd5 
> preamble\n",
> -   port);
> +  * printk_ratelimited("Port %d received 0xd5 
> preamble\n"
> +  *port);
>*/

This is not really an improvement. Either the dead code should be deleted
altogether or converted to debug printk()s. (Probably the idea has been
that those printk()s can be "easily" enabled for debugging by removing
comment start/end marks.)

You also removed a comma there, breaking the syntax...

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered

[Chen, Yu C]

Hi,Javi

> -Original Message-
> From: Javi Merino [mailto:javi.mer...@arm.com]
> Sent: Thursday, October 15, 2015 1:08 AM
> To: Chen, Yu C
> Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
> 
> On Mon, Oct 12, 2015 at 09:23:28AM +, Chen, Yu C wrote:
> > Hi, Javi
> > Sorry for my late response,
> >
> > > -Original Message-
> > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > To: Chen, Yu C
> > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > Hi Yu,
> > >
> > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > Hi, Javi,
> > > >
> > > > > -Original Message-
> > > > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > To: Chen, Yu C
> > > > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > From: Zhang Rui 
> > > > > >
> > > > > >
> > > > >
> > > > > I think you need to hold cdev->lock here, to make sure that no
> > > > > thermal zone is added or removed from cdev->thermal_instances
> > > > > while
> > > you are looping.
> > > > >
> > > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > > AB-BA lock with thermal_zone_unbind_cooling_device?
> > >
> > > You're right, it could lead to a deadlock.  The locks can't be
> > > swapped because that won't work in step_wise.
> > >
> > > The best way that I can think of accessing thermal_instances
> > > atomically is by making it RCU protected instead of with mutexes.
> > > What do you think?
> > >
> > RCU would need extra spinlocks to protect the list, and need to
> > sync_rcu after we delete one instance from thermal_instance list,  I
> > think it is too complicated for me to rewrite: ( How about using
> thermal_list_lock instead of cdev ->lock?
> > This guy should be big enough to protect the device.thermal_instance list.
> 
> thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but it
> doesn't protect the thermal_instances list.  For example,
> thermal_zone_bind_cooling_device() adds a cooling device to the
> cdev->thermal_instances list without taking thermal_tz_list.
> 
Before thermal_zone_bind_cooling_device is invoked,
the thermal_list_lock will be firstly gripped:

static void bind_cdev(struct thermal_cooling_device *cdev)
{
mutex_lock(_list_lock);
either tz->ops->bind:   thermal_zone_bind_cooling_device
or __bind()  :   thermal_zone_bind_cooling_device
mutex_unlock(_list_lock);
}

And it is the same as in  passive_store.
So when code is trying to add/delete thermal_instance of cdev,
he has already hold thermal_list_lock IMO. Or do I miss anything?

Best Regards,
Yu

Re: [PATCH] Add USB hooks into NanoBone DTS file

[Tony Lindgren]

* Mark Jackson  [151014 06:35]:
> Add USB hooks into NanoBone DTS file

Hmm looking at things, we really should not set status = "disabled"
for any of the internal devices. Setting "disabled" makes the kernel
completely ignore the device and we're better off from PM point of
view to probe and idle the device. The devices are there for sure, and
typically just the pins are not configured for them.

How about just remove the status = "disabled" from am33xx.dtsi
instead?

Regards,

Tony

> Signed-off-by: Mark Jackson 
> ---
>  arch/arm/boot/dts/am335x-nano.dts | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-nano.dts 
> b/arch/arm/boot/dts/am335x-nano.dts
> index 5ed4ca6..b86937a 100644
> --- a/arch/arm/boot/dts/am335x-nano.dts
> +++ b/arch/arm/boot/dts/am335x-nano.dts
> @@ -375,6 +375,23 @@
>   wp-gpios = < 18 0>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
> +_ctrl_mod {
> + status = "okay";
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + dr_mode = "host";
> +};
> +
>  #include "tps65217.dtsi"
>  
>   {
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v10 2/5] gennvm: Generic NVM manager

[Matias Bjørling]

The implementation for Open-Channel SSDs is divided into media
management and targets. This patch implements a generic media manager
for open-channel SSDs. After a media manager has been initialized,
single or multiple targets can be instantiated with the media managed as
the backend.

Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/Kconfig  |   7 +
 drivers/lightnvm/Makefile |   1 +
 drivers/lightnvm/gennvm.c | 467 ++
 drivers/lightnvm/gennvm.h |  46 +
 4 files changed, 521 insertions(+)
 create mode 100644 drivers/lightnvm/gennvm.c
 create mode 100644 drivers/lightnvm/gennvm.h

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index d4f309f..2a27971 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -25,4 +25,11 @@ config NVM_DEBUG
 
It is required to create/remove targets without IOCTLs.
 
+config NVM_GENNVM
+   tristate "Generic NVM manager for Open-Channel SSDs"
+   ---help---
+   NVM media manager for Open-Channel SSDs that offload management
+   functionality to device, while keeping data placement and garbage
+   collection decisions on the host.
+
 endif # NVM
diff --git a/drivers/lightnvm/Makefile b/drivers/lightnvm/Makefile
index 38185e9..e2428e0 100644
--- a/drivers/lightnvm/Makefile
+++ b/drivers/lightnvm/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_NVM)  := core.o
+obj-$(CONFIG_NVM_GENNVM)   += gennvm.o
diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
new file mode 100644
index 000..b12c1b2
--- /dev/null
+++ b/drivers/lightnvm/gennvm.c
@@ -0,0 +1,467 @@
+/*
+ * Copyright (C) 2015 Matias Bjorling 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, write to
+ * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139,
+ * USA.
+ *
+ * Implementation of a generic nvm manager for Open-Channel SSDs.
+ */
+
+#include "gennvm.h"
+
+static void gennvm_blocks_free(struct nvm_dev *dev)
+{
+   struct gen_nvm *gn = dev->mp;
+   struct gen_lun *lun;
+   int i;
+
+   gennvm_for_each_lun(gn, lun, i) {
+   if (!lun->vlun.blocks)
+   break;
+   vfree(lun->vlun.blocks);
+   }
+}
+
+static void gennvm_luns_free(struct nvm_dev *dev)
+{
+   struct gen_nvm *gn = dev->mp;
+
+   kfree(gn->luns);
+}
+
+static int gennvm_luns_init(struct nvm_dev *dev, struct gen_nvm *gn)
+{
+   struct gen_lun *lun;
+   int i;
+
+   gn->luns = kcalloc(dev->nr_luns, sizeof(struct gen_lun), GFP_KERNEL);
+   if (!gn->luns)
+   return -ENOMEM;
+
+   gennvm_for_each_lun(gn, lun, i) {
+   spin_lock_init(>vlun.lock);
+   INIT_LIST_HEAD(>free_list);
+   INIT_LIST_HEAD(>used_list);
+   INIT_LIST_HEAD(>bb_list);
+
+   lun->reserved_blocks = 2; /* for GC only */
+   lun->vlun.id = i;
+   lun->vlun.lun_id = i % dev->luns_per_chnl;
+   lun->vlun.chnl_id = i / dev->luns_per_chnl;
+   lun->vlun.nr_free_blocks = dev->blks_per_lun;
+   }
+   return 0;
+}
+
+static int gennvm_block_bb(u32 lun_id, void *bb_bitmap, unsigned int nr_blocks,
+   void *private)
+{
+   struct gen_nvm *gn = private;
+   struct gen_lun *lun = >luns[lun_id];
+   struct nvm_block *block;
+   int i;
+
+   if (unlikely(bitmap_empty(bb_bitmap, nr_blocks)))
+   return 0;
+
+   i = -1;
+   while ((i = find_next_bit(bb_bitmap, nr_blocks, i + 1)) <
+   nr_blocks) {
+   block = >vlun.blocks[i];
+   if (!block) {
+   pr_err("gen_nvm: BB data is out of bounds.\n");
+   return -EINVAL;
+   }
+   list_move_tail(>list, >bb_list);
+   }
+
+   return 0;
+}
+
+static int gennvm_block_map(u64 slba, u64 nlb, u64 *entries, void *private)
+{
+   struct nvm_dev *dev = private;
+   struct gen_nvm *gn = dev->mp;
+   sector_t max_pages = dev->total_pages * (dev->sec_size >> 9);
+   u64 elba = slba + nlb;
+   struct gen_lun *lun;
+   struct nvm_block *blk;
+   u64 i;
+   int lun_id;
+
+   if (unlikely(elba > dev->total_pages)) {
+   pr_err("gen_nvm: L2P data from device is out of bounds!\n");
+   return -EINVAL;
+   }
+
+   for (i 

[PATCH v10 3/5] rrpc: Round-robin sector target with cost-based gc

[Matias Bjørling]

This target allows an Open-Channel SSD to be exposed asas a block
device.

It implements a round-robin approach for sector allocation,
together with a greedy cost-based garbage collector.

Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/Kconfig  |7 +
 drivers/lightnvm/Makefile |1 +
 drivers/lightnvm/rrpc.c   | 1308 +
 drivers/lightnvm/rrpc.h   |  239 +
 4 files changed, 1555 insertions(+)
 create mode 100644 drivers/lightnvm/rrpc.c
 create mode 100644 drivers/lightnvm/rrpc.h

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index 2a27971..a16bf56 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -32,4 +32,11 @@ config NVM_GENNVM
functionality to device, while keeping data placement and garbage
collection decisions on the host.
 
+config NVM_RRPC
+   tristate "Round-robin Hybrid Open-Channel SSD target"
+   ---help---
+   Allows an open-channel SSD to be exposed as a block device to the
+   host. The target is implemented using a linear mapping table and
+   cost-based garbage collection. It is optimized for 4K IO sizes.
+
 endif # NVM
diff --git a/drivers/lightnvm/Makefile b/drivers/lightnvm/Makefile
index e2428e0..7e0f42a 100644
--- a/drivers/lightnvm/Makefile
+++ b/drivers/lightnvm/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_NVM)  := core.o
 obj-$(CONFIG_NVM_GENNVM)   += gennvm.o
+obj-$(CONFIG_NVM_RRPC) += rrpc.o
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
new file mode 100644
index 000..7575fce
--- /dev/null
+++ b/drivers/lightnvm/rrpc.c
@@ -0,0 +1,1308 @@
+/*
+ * Copyright (C) 2015 IT University of Copenhagen
+ * Initial release: Matias Bjorling 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Implementation of a Round-robin page-based Hybrid FTL for Open-channel SSDs.
+ */
+
+#include "rrpc.h"
+
+static struct kmem_cache *rrpc_gcb_cache, *rrpc_rq_cache;
+static DECLARE_RWSEM(rrpc_lock);
+
+static int rrpc_submit_io(struct rrpc *rrpc, struct bio *bio,
+   struct nvm_rq *rqd, unsigned long flags);
+
+#define rrpc_for_each_lun(rrpc, rlun, i) \
+   for ((i) = 0, rlun = &(rrpc)->luns[0]; \
+   (i) < (rrpc)->nr_luns; (i)++, rlun = &(rrpc)->luns[(i)])
+
+static void rrpc_page_invalidate(struct rrpc *rrpc, struct rrpc_addr *a)
+{
+   struct rrpc_block *rblk = a->rblk;
+   unsigned int pg_offset;
+
+   lockdep_assert_held(>rev_lock);
+
+   if (a->addr == ADDR_EMPTY || !rblk)
+   return;
+
+   spin_lock(>lock);
+
+   pg_offset = a->addr % rrpc->dev->pgs_per_blk;
+   WARN_ON(test_and_set_bit(pg_offset, rblk->invalid_pages));
+   rblk->nr_invalid_pages++;
+
+   spin_unlock(>lock);
+
+   rrpc->rev_trans_map[a->addr - rrpc->poffset].addr = ADDR_EMPTY;
+}
+
+static void rrpc_invalidate_range(struct rrpc *rrpc, sector_t slba,
+   unsigned len)
+{
+   sector_t i;
+
+   spin_lock(>rev_lock);
+   for (i = slba; i < slba + len; i++) {
+   struct rrpc_addr *gp = >trans_map[i];
+
+   rrpc_page_invalidate(rrpc, gp);
+   gp->rblk = NULL;
+   }
+   spin_unlock(>rev_lock);
+}
+
+static struct nvm_rq *rrpc_inflight_laddr_acquire(struct rrpc *rrpc,
+   sector_t laddr, unsigned int pages)
+{
+   struct nvm_rq *rqd;
+   struct rrpc_inflight_rq *inf;
+
+   rqd = mempool_alloc(rrpc->rq_pool, GFP_ATOMIC);
+   if (!rqd)
+   return ERR_PTR(-ENOMEM);
+
+   inf = rrpc_get_inflight_rq(rqd);
+   if (rrpc_lock_laddr(rrpc, laddr, pages, inf)) {
+   mempool_free(rqd, rrpc->rq_pool);
+   return NULL;
+   }
+
+   return rqd;
+}
+
+static void rrpc_inflight_laddr_release(struct rrpc *rrpc, struct nvm_rq *rqd)
+{
+   struct rrpc_inflight_rq *inf = rrpc_get_inflight_rq(rqd);
+
+   rrpc_unlock_laddr(rrpc, inf);
+
+   mempool_free(rqd, rrpc->rq_pool);
+}
+
+static void rrpc_discard(struct rrpc *rrpc, struct bio *bio)
+{
+   sector_t slba = bio->bi_iter.bi_sector / NR_PHY_IN_LOG;
+   sector_t len = bio->bi_iter.bi_size / RRPC_EXPOSED_PAGE_SIZE;
+   struct nvm_rq *rqd;
+
+   do {
+   rqd = rrpc_inflight_laddr_acquire(rrpc, slba, len);
+   schedule();
+   } while (!rqd);
+
+   if (IS_ERR(rqd)) {
+   pr_err("rrpc: unable to acquire inflight IO\n");
+   

[PATCH v10 4/5] null_nvm: LightNVM test driver

[Matias Bjørling]

This driver implements the I/O flow for a LightNVM device driver. It
does no transfers. It can be used to test setup/teardown of devices and
evaluating performance of media managers and targets.

The framework of the driver is derived from the null_blk module.

Signed-off-by: Matias Bjørling 
---
 drivers/lightnvm/Kconfig|   6 +
 drivers/lightnvm/Makefile   |   1 +
 drivers/lightnvm/null_nvm.c | 463 
 3 files changed, 470 insertions(+)
 create mode 100644 drivers/lightnvm/null_nvm.c

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index a16bf56..970 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -39,4 +39,10 @@ config NVM_RRPC
host. The target is implemented using a linear mapping table and
cost-based garbage collection. It is optimized for 4K IO sizes.
 
+config NVM_NULL_NVM
+   tristate "Null test LightNVM driver"
+   ---help---
+   The null test driver can be used to evaluate targets without an
+   underlying device.
+
 endif # NVM
diff --git a/drivers/lightnvm/Makefile b/drivers/lightnvm/Makefile
index 7e0f42a..2f1287b 100644
--- a/drivers/lightnvm/Makefile
+++ b/drivers/lightnvm/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_NVM)  := core.o
 obj-$(CONFIG_NVM_GENNVM)   += gennvm.o
 obj-$(CONFIG_NVM_RRPC) += rrpc.o
+obj-$(CONFIG_NVM_NULL_NVM) += null_nvm.o
diff --git a/drivers/lightnvm/null_nvm.c b/drivers/lightnvm/null_nvm.c
new file mode 100644
index 000..27a29d2
--- /dev/null
+++ b/drivers/lightnvm/null_nvm.c
@@ -0,0 +1,463 @@
+/*
+ * derived from Jens Axboe's block/null_blk.c
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct kmem_cache *ppa_cache;
+struct nulln_cmd {
+   struct llist_node ll_list;
+   struct request *rq;
+};
+
+struct nulln {
+   struct list_head list;
+   unsigned int index;
+   struct request_queue *q;
+   struct blk_mq_tag_set tag_set;
+   struct hrtimer timer;
+   char disk_name[DISK_NAME_LEN];
+};
+
+static LIST_HEAD(nulln_list);
+static struct mutex nulln_lock;
+static int nulln_indexes;
+
+struct completion_queue {
+   struct llist_head list;
+   struct hrtimer timer;
+};
+
+/*
+ * These are per-cpu for now, they will need to be configured by the
+ * complete_queues parameter and appropriately mapped.
+ */
+static DEFINE_PER_CPU(struct completion_queue, null_comp_queues);
+
+enum {
+   NULL_IRQ_NONE   = 0,
+   NULL_IRQ_SOFTIRQ= 1,
+   NULL_IRQ_TIMER  = 2,
+};
+
+static int submit_queues;
+module_param(submit_queues, int, S_IRUGO);
+MODULE_PARM_DESC(submit_queues, "Number of submission queues");
+
+static int home_node = NUMA_NO_NODE;
+module_param(home_node, int, S_IRUGO);
+MODULE_PARM_DESC(home_node, "Home node for the device");
+
+static int null_param_store_val(const char *str, int *val, int min, int max)
+{
+   int ret, new_val;
+
+   ret = kstrtoint(str, 10, _val);
+   if (ret)
+   return -EINVAL;
+
+   if (new_val < min || new_val > max)
+   return -EINVAL;
+
+   *val = new_val;
+   return 0;
+}
+
+static int gb = 250;
+module_param(gb, int, S_IRUGO);
+MODULE_PARM_DESC(gb, "Size in GB");
+
+static int bs = 4096;
+module_param(bs, int, S_IRUGO);
+MODULE_PARM_DESC(bs, "Block size (in bytes)");
+
+static int nr_devices = 1;
+module_param(nr_devices, int, S_IRUGO);
+MODULE_PARM_DESC(nr_devices, "Number of devices to register");
+
+static int irqmode = NULL_IRQ_SOFTIRQ;
+
+static int null_set_irqmode(const char *str, const struct kernel_param *kp)
+{
+   return null_param_store_val(str, , NULL_IRQ_NONE,
+   NULL_IRQ_TIMER);
+}
+
+static const struct kernel_param_ops null_irqmode_param_ops = {
+   .set= null_set_irqmode,
+   .get= param_get_int,
+};
+
+device_param_cb(irqmode, _irqmode_param_ops, , S_IRUGO);
+MODULE_PARM_DESC(irqmode, "IRQ completion handler. 0-none, 1-softirq, 
2-timer");
+
+static int completion_nsec = 1;
+module_param(completion_nsec, int, S_IRUGO);
+MODULE_PARM_DESC(completion_nsec, "Time in ns to complete a request in 
hardware. Default: 10,000ns");
+
+static int hw_queue_depth = 64;
+module_param(hw_queue_depth, int, S_IRUGO);
+MODULE_PARM_DESC(hw_queue_depth, "Queue depth for each hardware queue. 
Default: 64");
+
+static bool use_per_node_hctx;
+module_param(use_per_node_hctx, bool, S_IRUGO);
+MODULE_PARM_DESC(use_per_node_hctx, "Use per-node allocation for hardware 
context queues. Default: false");
+
+static int num_channels = 1;
+module_param(num_channels, int, S_IRUGO);
+MODULE_PARM_DESC(num_channels, "Number of channels to be exposed. Default: 1");
+
+static enum hrtimer_restart null_cmd_timer_expired(struct hrtimer *timer)
+{
+   struct completion_queue *cq;
+   struct llist_node *entry;
+   struct nulln_cmd *cmd;
+
+   cq = 

[PATCH v10 0/5] Support for Open-Channel SSDs

[Matias Bjørling]

This patchset implements support for Open-Channel SSDs.

Applies against Jens' for-next and is available through the lkml_v10 branch at:

  https://github.com/OpenChannelSSD/linux

Sorry, missed the patch for nvme_nvm_unregister prototype definition update.

Changes since v9:
 - Fix compilation of the kernel without LightNVM selected.
 - Make static completion_queues variable unique so it doesn't collide with
   the null_blk module.

Changes since v8:
 - Specification was changed to define a SSD configuration using a single entry.
   This replaces the per-lun specification with a single configuration. Easing
   the access to global geometry values and simplifies address calculations.
 - Implement PPA addressing modes. Encode NAND flash structure into physical
   page addresses. An address now has bits reserved for each part of the flash
   units (sectors, page, block, plane, lun, channels), replacing the linear
   address space previously found in the LightNVM specification.
 - Rename bm_hb to gennvm (generic nvm manager). This part now covers any type
   of non-volatile memory media. Thus, it is not only a block manager, but
   manages several pieces of core information.
 - Add detection for CNEX Westlake controller.
 - Completion of I/Os was previously directly completed in the target. Push
   completion through the media manager first and then target.
 - Rebased on top of latest changes to the NVMe device driver architecture.
 - Various fixes and refactoring.

Changes since v7:
 - The IOCTL management interface have been created. Devices can now be
   managed through the lightnvm-adm tool (ladm). This is available from:
 https://github.com/OpenChannelSSD/lightnvm-adm.git
 - The debugging management interface is now only available if debugging
   is enabled. (/sys/module/lnvm/parameters/configure_debug)
 - GCC compatibility fixes (Dongsheng Yang)
 - Fix for BM initialization (Dongsheng Yang)
 - Fix for error during rrpc init (Javier Gonzalez)
 - Refactor NVMe driver to not expect non-standard behavior. Added PCI
   id identification for selected devices (qemu-nvme and cnex).
 - Enable NVMe metadata to be passed from target.
 - Create ioctl interface for management.
 - Add NVM_DEBUG flag to explicit enable/diskable parameter
   configure_debug access. The interface is only available if debugging
   is enabled.
 - Add support for physical block address commands.
 - Added uapi/lightnvm.h header to expose ioctl interface.
 - Fix qemu-nvme initialization extensions regarding L2P translation
   support.
 - Clean up of dead code.
 - Updated e-mails, copyrights, etc.

Changes since v6:
 - Multipage support (Javier Gonzalez)
 - General code cleanups
 - Fixed memleak on register failure

Changes since v5:
Feedback from Christoph Hellwig.
 - Created new null_nvm from null_blk to register itself as a lightnvm
   device.
 - Changed the interface of register/unregister to only take disk_name.
   The gendisk alloc in nvme is kept. Most instantiations will
   involve the device gendisk, therefore wait with refactoring to a
   later time.
 - Renamed global parameters in core.c and rrpc.c

Changes since v4:
 - Remove gendisk->nvm dependency
 - Remove device driver rq private field dependency.
 - Update submission and completion. The flow is now
 Target -> Block Manager -> Device Driver, replacing callbacks in
 device driver.
 - Abstracted out the block manager into its own module. Other block
   managers can now be implemented. For example to support fully
   host-based SSDs.
 - No longer exposes the device driver gendisk to user-space.
 - Management is moved into /sys/modules/lnvm/parameters/configure_debug

Changes since v3:

 - Remove dependency on REQ_NVM_GC
 - Refactor nvme integration to use nvme_submit_sync_cmd for
   internal commands.
 - Fix race condition bug on multiple threads on RRPC target.
 - Rename sysfs entry under the block device from nvm to lightnvm.
   The configuration is found in /sys/block/*/lightnvm/

Changes since v2:

 Feedback from Paul Bolle:
 - Fix license to GPLv2, documentation, compilation.
 Feedback from Keith Busch:
 - nvme: Move lightnvm out and into nvme-lightnvm.c.
 - nvme: Set controller css on lightnvm command set.
 - nvme: Remove OACS.
 Feedback from Christoph Hellwig:
 - lightnvm: Move out of block layer into /drivers/lightnvm/core.c
 - lightnvm: refactor request->phys_sector into device drivers.
 - lightnvm: refactor prep/unprep into device drivers.
 - lightnvm: move nvm_dev from request_queue to gendisk.

 New
 - Bad block table support (From Javier).
 - Update maintainers file.

Changes since v1:

 - Splitted LightNVM into two parts. A get/put interface for flash
   blocks and the respective targets that implement flash translation
   layer logic.
 - Updated the patches according to the LightNVM specification changes.
 - Added interface to add/remove targets for a block device.

Thanks to Jens Axboe, Christoph Hellwig, Keith Busch, Paul Bolle,
Javier Gonzalez and 

[PATCH v10 5/5] nvme: LightNVM support

[Matias Bjørling]

The first generation of Open-Channel SSDs is based on NVMe. The
integration requires that a NVMe device register itself as a LightNVM
device.

Detection is made through PCI IDs. Current supported devices are the
qemu nvme simulator and CNEX Labs Westlake SSD. The qemu nvme enables
support through vendor specific bits in the namespace identification and
the CNEX card is configured for LightNVM upon boot and does not need
detection other than PCI id.

After detection, vendor specific codes are used to identify the device
and enumerate supported features.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
---
 drivers/nvme/host/Makefile   |   2 +-
 drivers/nvme/host/lightnvm.c | 597 +++
 drivers/nvme/host/nvme.h |  10 +
 drivers/nvme/host/pci.c  |  39 ++-
 4 files changed, 636 insertions(+), 12 deletions(-)
 create mode 100644 drivers/nvme/host/lightnvm.c

diff --git a/drivers/nvme/host/Makefile b/drivers/nvme/host/Makefile
index cfb6679..219dc206 100644
--- a/drivers/nvme/host/Makefile
+++ b/drivers/nvme/host/Makefile
@@ -1,4 +1,4 @@
 
 obj-$(CONFIG_BLK_DEV_NVME) += nvme.o
 
-nvme-y += pci.o scsi.o
+nvme-y += pci.o scsi.o lightnvm.o
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
new file mode 100644
index 000..2d6f798
--- /dev/null
+++ b/drivers/nvme/host/lightnvm.c
@@ -0,0 +1,597 @@
+/*
+ * nvme-lightnvm.c - LightNVM NVMe device
+ *
+ * Copyright (C) 2014-2015 IT University of Copenhagen
+ * Initial release: Matias Bjorling 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, write to
+ * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139,
+ * USA.
+ *
+ */
+
+#include "nvme.h"
+
+#ifdef CONFIG_NVM
+
+#include 
+#include 
+#include 
+#include 
+
+enum nvme_nvm_opcode {
+   nvme_nvm_cmd_hb_write   = 0x81,
+   nvme_nvm_cmd_hb_read= 0x02,
+   nvme_nvm_cmd_ph_write   = 0x91,
+   nvme_nvm_cmd_ph_read= 0x92,
+   nvme_nvm_cmd_erase  = 0x90,
+};
+
+enum nvme_nvm_admin_opcode {
+   nvme_nvm_admin_identify = 0xe2,
+   nvme_nvm_admin_get_features = 0xe6,
+   nvme_nvm_admin_set_resp = 0xe5,
+   nvme_nvm_admin_get_l2p_tbl  = 0xea,
+   nvme_nvm_admin_get_bb_tbl   = 0xf2,
+   nvme_nvm_admin_set_bb_tbl   = 0xf1,
+};
+
+struct nvme_nvm_hb_rw {
+   __u8opcode;
+   __u8flags;
+   __u16   command_id;
+   __le32  nsid;
+   __u64   rsvd2;
+   __le64  metadata;
+   __le64  prp1;
+   __le64  prp2;
+   __le64  spba;
+   __le16  length;
+   __le16  control;
+   __le32  dsmgmt;
+   __le64  slba;
+};
+
+struct nvme_nvm_ph_rw {
+   __u8opcode;
+   __u8flags;
+   __u16   command_id;
+   __le32  nsid;
+   __u64   rsvd2;
+   __le64  metadata;
+   __le64  prp1;
+   __le64  prp2;
+   __le64  spba;
+   __le16  length;
+   __le16  control;
+   __le32  dsmgmt;
+   __le64  resv;
+};
+
+struct nvme_nvm_identify {
+   __u8opcode;
+   __u8flags;
+   __u16   command_id;
+   __le32  nsid;
+   __u64   rsvd[2];
+   __le64  prp1;
+   __le64  prp2;
+   __le32  chnl_off;
+   __u32   rsvd11[5];
+};
+
+struct nvme_nvm_l2ptbl {
+   __u8opcode;
+   __u8flags;
+   __u16   command_id;
+   __le32  nsid;
+   __le32  cdw2[4];
+   __le64  prp1;
+   __le64  prp2;
+   __le64  slba;
+   __le32  nlb;
+   __le16  cdw14[6];
+};
+
+struct nvme_nvm_bbtbl {
+   __u8opcode;
+   __u8flags;
+   __u16   command_id;
+   __le32  nsid;
+   __u64  

[PATCH v10 1/5] lightnvm: Support for Open-Channel SSDs

[Matias Bjørling]

Open-channel SSDs are devices that share responsibilities with the host
in order to implement and maintain features that typical SSDs keep
strictly in firmware. These include (i) the Flash Translation Layer
(FTL), (ii) bad block management, and (iii) hardware units such as the
flash controller, the interface controller, and large amounts of flash
chips. In this way, Open-channels SSDs exposes direct access to their
physical flash storage, while keeping a subset of the internal features
of SSDs.

LightNVM is a specification that gives support to Open-channel SSDs
LightNVM allows the host to manage data placement, garbage collection,
and parallelism. Device specific responsibilities such as bad block
management, FTL extensions to support atomic IOs, or metadata
persistence are still handled by the device.

The implementation of LightNVM consists of two parts: core and
(multiple) targets. The core implements functionality shared across
targets. This is initialization, teardown and statistics. The targets
implement the interface that exposes physical flash to user-space
applications. Examples of such targets include key-value store,
object-store, as well as traditional block devices, which can be
application-specific.

Contributions in this patch from:

  Javier Gonzalez 
  Dongsheng Yang 
  Jesper Madsen 

Signed-off-by: Matias Bjørling 
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 MAINTAINERS  |   8 +
 drivers/Kconfig  |   2 +
 drivers/Makefile |   1 +
 drivers/lightnvm/Kconfig |  28 ++
 drivers/lightnvm/Makefile|   5 +
 drivers/lightnvm/core.c  | 856 +++
 include/linux/lightnvm.h | 516 +
 include/uapi/linux/lightnvm.h| 130 ++
 9 files changed, 1547 insertions(+)
 create mode 100644 drivers/lightnvm/Kconfig
 create mode 100644 drivers/lightnvm/Makefile
 create mode 100644 drivers/lightnvm/core.c
 create mode 100644 include/linux/lightnvm.h
 create mode 100644 include/uapi/linux/lightnvm.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index df1b25e..8a44d44 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -149,6 +149,7 @@ Code  Seq#(hex) Include FileComments
 'K'all linux/kd.h
 'L'00-1F   linux/loop.hconflict!
 'L'10-1F   drivers/scsi/mpt2sas/mpt2sas_ctl.h  conflict!
+'L'20-2F   linux/lightnvm.h
 'L'E0-FF   linux/ppdd.hencrypted disk device driver


 'M'all linux/soundcard.h   conflict!
diff --git a/MAINTAINERS b/MAINTAINERS
index d104ec9..77ca434 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6243,6 +6243,14 @@ F:   drivers/nvdimm/pmem.c
 F: include/linux/pmem.h
 F: arch/*/include/asm/pmem.h
 
+LIGHTNVM PLATFORM SUPPORT
+M: Matias Bjorling 
+W: http://github/OpenChannelSSD
+S: Maintained
+F: drivers/lightnvm/
+F: include/linux/lightnvm.h
+F: include/uapi/linux/lightnvm.h
+
 LINUX FOR IBM pSERIES (RS/6000)
 M: Paul Mackerras 
 W: http://www.ibm.com/linux/ltc/projects/ppc
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e69ec82..3a5ab4d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -44,6 +44,8 @@ source "drivers/net/Kconfig"
 
 source "drivers/isdn/Kconfig"
 
+source "drivers/lightnvm/Kconfig"
+
 # input before char - char/joystick depends on it. As does USB.
 
 source "drivers/input/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 42f9dd5..7f1b7c5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_NUBUS)   += nubus/
 obj-y  += macintosh/
 obj-$(CONFIG_IDE)  += ide/
 obj-$(CONFIG_SCSI) += scsi/
+obj-$(CONFIG_NVM)  += lightnvm/
 obj-y  += nvme/
 obj-$(CONFIG_ATA)  += ata/
 obj-$(CONFIG_TARGET_CORE)  += target/
diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
new file mode 100644
index 000..d4f309f
--- /dev/null
+++ b/drivers/lightnvm/Kconfig
@@ -0,0 +1,28 @@
+#
+# Open-Channel SSD NVM configuration
+#
+
+menuconfig NVM
+   bool "Open-Channel SSD target support"
+   depends on BLOCK
+   help
+ Say Y here to get to enable Open-channel SSDs.
+
+ Open-Channel SSDs implement a set of extension to SSDs, that
+ exposes direct access to the underlying non-volatile memory.
+
+ If you say N, all options in this submenu will be skipped and disabled
+ only do this if you know what you are doing.
+
+if NVM
+
+config NVM_DEBUG
+   bool "Open-Channel SSD debugging support"
+   ---help---
+   Exposes a debug management interface to create/remove targets at:
+
+ 

RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered

[Chen, Yu C]

Hi Javi,


> -Original Message-
> From: Javi Merino [mailto:javi.mer...@arm.com]
> Sent: Thursday, October 15, 2015 1:08 AM
> To: Chen, Yu C
> Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
> 
> On Mon, Oct 12, 2015 at 09:23:28AM +, Chen, Yu C wrote:
> > Hi, Javi
> > Sorry for my late response,
> >
> > > -Original Message-
> > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > To: Chen, Yu C
> > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > Hi Yu,
> > >
> > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > Hi, Javi,
> > > >
> > > > > -Original Message-
> > > > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > To: Chen, Yu C
> > > > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > From: Zhang Rui 
> > > > > >
> > > > > >
> > > > >
> > > > > I think you need to hold cdev->lock here, to make sure that no
> > > > > thermal zone is added or removed from cdev->thermal_instances
> > > > > while
> > > you are looping.
> > > > >
> > > > Ah right, will add. If I add the cdev ->lock here, will there be a
> > > > AB-BA lock with thermal_zone_unbind_cooling_device?
> > >
> > > You're right, it could lead to a deadlock.  The locks can't be
> > > swapped because that won't work in step_wise.
> > >
> > > The best way that I can think of accessing thermal_instances
> > > atomically is by making it RCU protected instead of with mutexes.
> > > What do you think?
> > >
> > RCU would need extra spinlocks to protect the list, and need to
> > sync_rcu after we delete one instance from thermal_instance list,  I
> > think it is too complicated for me to rewrite: ( How about using
> thermal_list_lock instead of cdev ->lock?
> > This guy should be big enough to protect the device.thermal_instance list.
> 
> thermal_list_lock protects thermal_tz_list and thermal_cdev_list, but it
> doesn't protect the thermal_instances list.  For example,
> thermal_zone_bind_cooling_device() adds a cooling device to the
> cdev->thermal_instances list without taking thermal_tz_list.
> 

Before thermal_zone_bind_cooling_device is invoked, 
the thermal_list_lock will be firstly gripped:

static void bind_cdev(struct thermal_cooling_device *cdev)
{

mutex_lock(_list_lock);

either tz->ops->bind:   thermal_zone_bind_cooling_device

or __bind()  :   thermal_zone_bind_cooling_device
mutex_unlock(_list_lock);

}

And it is the same as in  passive_store.

So when code is trying to add/delete thermal_instance of cdev, he has
already hold thermal_list_lock IMO. Or do I miss anything?

Best Regards,
Yu


N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH] ata/pata_it821x: set array of const as const

[LABBE Corentin]

Some array of const char are not set as const.
This patch fix that.

Signed-off-by: LABBE Corentin 
---
 drivers/ata/pata_it821x.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/pata_it821x.c b/drivers/ata/pata_it821x.c
index a5088ec..7a21edf 100644
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -604,9 +604,9 @@ static void it821x_display_disk(int n, u8 *buf)
 {
unsigned char id[41];
int mode = 0;
-   char *mtype = "";
+   const char *mtype = "";
char mbuf[8];
-   char *cbl = "(40 wire cable)";
+   const char *cbl = "(40 wire cable)";
 
static const char *types[5] = {
"RAID0", "RAID1", "RAID 0+1", "JBOD", "DISK"
@@ -903,7 +903,7 @@ static int it821x_init_one(struct pci_dev *pdev, const 
struct pci_device_id *id)
};
 
const struct ata_port_info *ppi[] = { NULL, NULL };
-   static char *mode[2] = { "pass through", "smart" };
+   static const char *mode[2] = { "pass through", "smart" };
int rc;
 
rc = pcim_enable_device(pdev);
-- 
2.4.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Linus Torvalds]

On Wed, Oct 14, 2015 at 12:02 PM, Tejun Heo  wrote:
>
> But wasn't add_timer() always CPU-local at the time?  add_timer()
> allowing cross-cpu migrations came way after that.

add_timer() has actually never been "local CPU only" either.

What add_timer() does is to keep the timer on the old CPU timer wheel
if it was active, and if it wasn't, put it on the current CPU timer
wheel.

So again, by pure *accident*, if you don't end up ever modifying an
already-active timer, then yes, it ended up being local. But even
then, things like suspend/resume can move timers around, afaik, so
even then it has never been a real guarantee.

And I see absolutely no sign that the local cpu case has ever been intentional.

Now, obviously, that said there is obviously at least one case that
seems to have relied on it (ie the mm/vmstat.c case), but I think we
should just fix that.

If it turns out that there really are *lots* of cases where
"schedule_delayed_work()" expects the work to always run on the CPU
that it is scheduled on, then we should probably take your patch just
because it's too painful not to.

But I'd like to avoid that if possible.

 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] crypto: x86: Remove duplicate define of SHA1_DIGEST_SIZE

[LABBE Corentin]

The sha x86 crypto code use two define for the same thing:
NUM_SHA1_DIGEST_WORDS and SHA1_DIGEST_LENGTH
Replace them by SHA1_DIGEST_SIZE/4

Signed-off-by: LABBE Corentin 
---
 arch/x86/crypto/sha-mb/sha1_mb.c| 2 +-
 arch/x86/crypto/sha-mb/sha_mb_ctx.h | 1 -
 arch/x86/crypto/sha-mb/sha_mb_mgr.h | 6 ++
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c b/arch/x86/crypto/sha-mb/sha1_mb.c
index a841e97..791cbfa 100644
--- a/arch/x86/crypto/sha-mb/sha1_mb.c
+++ b/arch/x86/crypto/sha-mb/sha1_mb.c
@@ -104,7 +104,7 @@ static asmlinkage struct job_sha1* 
(*sha1_job_mgr_get_comp_job)(struct sha1_mb_m
 
 inline void sha1_init_digest(uint32_t *digest)
 {
-   static const uint32_t initial_digest[SHA1_DIGEST_LENGTH] = {SHA1_H0,
+   static const uint32_t initial_digest[SHA1_DIGEST_SIZE / 4] = {SHA1_H0,
SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4 };
memcpy(digest, initial_digest, sizeof(initial_digest));
 }
diff --git a/arch/x86/crypto/sha-mb/sha_mb_ctx.h 
b/arch/x86/crypto/sha-mb/sha_mb_ctx.h
index e36069d..9fd36eb5 100644
--- a/arch/x86/crypto/sha-mb/sha_mb_ctx.h
+++ b/arch/x86/crypto/sha-mb/sha_mb_ctx.h
@@ -94,7 +94,6 @@ enum hash_ctx_error {
 
 
 /* Hash Constants and Typedefs */
-#define SHA1_DIGEST_LENGTH  5
 #define SHA1_LOG2_BLOCK_SIZE6
 
 #define SHA1_PADLENGTHFIELD_SIZE8
diff --git a/arch/x86/crypto/sha-mb/sha_mb_mgr.h 
b/arch/x86/crypto/sha-mb/sha_mb_mgr.h
index 08ad1a9..3ff337c 100644
--- a/arch/x86/crypto/sha-mb/sha_mb_mgr.h
+++ b/arch/x86/crypto/sha-mb/sha_mb_mgr.h
@@ -54,11 +54,9 @@
 #ifndef __SHA_MB_MGR_H
 #define __SHA_MB_MGR_H
 
-
+#include 
 #include 
 
-#define NUM_SHA1_DIGEST_WORDS 5
-
 enum job_sts { STS_UNKNOWN = 0,
STS_BEING_PROCESSED = 1,
STS_COMPLETED = 2,
@@ -69,7 +67,7 @@ enum job_sts {STS_UNKNOWN = 0,
 struct job_sha1 {
u8  *buffer;
u32 len;
-   u32 result_digest[NUM_SHA1_DIGEST_WORDS] __aligned(32);
+   u32 result_digest[SHA1_DIGEST_SIZE / 4] __aligned(32);
enumjob_sts status;
void*user_data;
 };
-- 
2.4.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH-RFC 6/7] drivers: of: ifdef out cmdline section

[Daniel Walker]

On 10/14/2015 10:57 AM, Rob Herring wrote:

On Wed, Oct 14, 2015 at 9:48 AM, Daniel Walker  wrote:


There's one last little wrinkle .. In the current setup the defconfig
CONFIG_CMDLINE="" is used as a default in case the device tree has nothing
in it. In my changes, there is no identical functionality. The only similar
thing I have is the the CONFIG_CMDLINE_APPEND="" . The main difference is
that in the current implementation CONFIG_CMDLINE="" doesn't get added at
all if there is a device tree bootargs, but with my implementation this line
would be added unconditionally. It would represent a subtle change where
people would have to add into the DT bootargs something to override what
might be in the default command line.

So CMDLINE_EXTEND would be equivalent to your version, but it looks
like CMDLINE_EXTEND is not used in the DT case. Perhaps you can add
the option? You already have OVERRIDE which is equivalent to FORCE.


I have better than CONFIG_CMDLINE_EXTEND.. My changes allow the 
bootloader arguments to be appended or prepended to the default, which 
ever works for you. It works in a slightly different way, your appending 
or prepending the default values the bootloader arugments (or DT 
bootargs), opposed to the other way around.


This is what I was suggesting we do, i.e. to use something like 
CONFIG_CMDLINE_EXTEND. If we put everything from CONFIG_CMDLINE into 
something like CONFIG_CMDLINE_EXTEND, then it ends up setting default I 
think people won't expect.






For example,

if a config has CONFIG_CMDLINE_APPEND="debug" then they would have to add a
"loglevel=7" into the DT bootargs to get back to normal. I wouldn't think
people would want "debug" as the default, but oddly enough some of the
configs do have this. Some of them also have default ip address setting,
nfsroot= settings, and loglevel= settings.

Or they would have to remove the kernel default from their config.
That might be acceptable. You could have a case where you have 1
kernel binary and 2 different bootloaders where you expect the
bootloader's cmdline used in one case and the kernel's in the other.
Seems unlikely, but it would be an ABI break.




I suppose it would depend if it works or not with my changes. If we do 
the EXTEND thing, then people might end up with "nfsroot=" lines they 
didn't expend as defaults.


I'm not sure this is ABI breakage, because the kernel code isn't stuck 
on ABI's internally. If someone wants specific boot arguments in there 
kernel config this doesn't prevent it, it just changes the behavior.




What are your thoughts on this ? I think using the append type default makes
more sense because it's actually setting up global defaults. The current
complete replacement scheme seems to set the stage for people to make an
entirely custom default for a single development machine, which IMO doesn't
make sense. However, I'm not sure what the intent is with the current setup.

People will want a path to support up to the current 3 options (use
bootloader's cmdline, append bootloader cmdline to default, and force
kernel default) and you have to assume changing bootloader is not an
option.



Yeah we have those 3 with my changes. Maybe I'm drilling down too much 
on this and we should just do the CONFIG_CMDLINE_EXTEND equivalent and 
when they find there's a new "nfsroot=" line in there bootargs they can 
just send a patch.


Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] crypto: n2: set array of const as const

[LABBE Corentin]

Some array of const char are not set as const.
This patch fix that.

Signed-off-by: LABBE Corentin 
---
 drivers/crypto/n2_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 8ea6c32..febbd5e 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -34,7 +34,7 @@
 #define DRV_MODULE_VERSION "0.2"
 #define DRV_MODULE_RELDATE "July 28, 2011"
 
-static char version[] =
+static const char version[] =
DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
 
 MODULE_AUTHOR("David S. Miller (da...@davemloft.net)");
-- 
2.4.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] crypto: sahara: set array of const as const

[LABBE Corentin]

Some array of const char are not set as const.
This patch fix that.

Signed-off-by: LABBE Corentin 
---
 drivers/crypto/sahara.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 804c0f5..f68c24a 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -272,7 +272,7 @@ static u32 sahara_aes_data_link_hdr(struct sahara_dev *dev)
SAHARA_HDR_CHA_SKHA | SAHARA_HDR_PARITY_BIT;
 }
 
-static char *sahara_err_src[16] = {
+static const char *sahara_err_src[16] = {
"No error",
"Header error",
"Descriptor length error",
@@ -291,14 +291,14 @@ static char *sahara_err_src[16] = {
"DMA error"
 };
 
-static char *sahara_err_dmasize[4] = {
+static const char *sahara_err_dmasize[4] = {
"Byte transfer",
"Half-word transfer",
"Word transfer",
"Reserved"
 };
 
-static char *sahara_err_dmasrc[8] = {
+static const char *sahara_err_dmasrc[8] = {
"No error",
"AHB bus error",
"Internal IP bus error",
@@ -309,7 +309,7 @@ static char *sahara_err_dmasrc[8] = {
"DMA HW error"
 };
 
-static char *sahara_cha_errsrc[12] = {
+static const char *sahara_cha_errsrc[12] = {
"Input buffer non-empty",
"Illegal address",
"Illegal mode",
@@ -324,7 +324,7 @@ static char *sahara_cha_errsrc[12] = {
"Reserved"
 };
 
-static char *sahara_cha_err[4] = { "No error", "SKHA", "MDHA", "RNG" };
+static const char *sahara_cha_err[4] = { "No error", "SKHA", "MDHA", "RNG" };
 
 static void sahara_decode_error(struct sahara_dev *dev, unsigned int error)
 {
@@ -354,7 +354,7 @@ static void sahara_decode_error(struct sahara_dev *dev, 
unsigned int error)
dev_err(dev->device, "\n");
 }
 
-static char *sahara_state[4] = { "Idle", "Busy", "Error", "HW Fault" };
+static const char *sahara_state[4] = { "Idle", "Busy", "Error", "HW Fault" };
 
 static void sahara_decode_status(struct sahara_dev *dev, unsigned int status)
 {
-- 
2.4.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lib/mpi: clean unused SHA1_DIGEST_LENGTH

[LABBE Corentin]

The define SHA1_DIGEST_LENGTH is not used anywhere, so remove it.

Signed-off-by: LABBE Corentin 
---
 include/linux/mpi.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/linux/mpi.h b/include/linux/mpi.h
index 641b7d6..a792b38 100644
--- a/include/linux/mpi.h
+++ b/include/linux/mpi.h
@@ -32,12 +32,6 @@
 
 #include 
 
-/* DSI defines */
-
-#define SHA1_DIGEST_LENGTH   20
-
-/*end of DSI defines */
-
 #define BYTES_PER_MPI_LIMB (BITS_PER_LONG / 8)
 #define BITS_PER_MPI_LIMB  BITS_PER_LONG
 
-- 
2.4.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: pxa: fix pxa3xx DFI lockup hack

[Robert Jarzmik]

Arnd Bergmann  writes:

> On Monday 12 October 2015 19:03:44 Robert Jarzmik wrote:
>> Arnd Bergmann  writes:
>> 
>> > Some recently added code to avoid a bug introduced a build error
>> > when CONFIG_PM is disabled and a macro is hidden:
>> >
>> > arch/arm/mach-pxa/pxa3xx.c: In function 'pxa3xx_init':
>> > arch/arm/mach-pxa/pxa3xx.c:439:3: error: 'NDCR' undeclared (first use in 
>> > this function)
>> >NDCR = (NDCR & ~NDCR_ND_ARB_EN) | NDCR_ND_ARB_CNTL;
>> >^
>> >
>> > This moves the macro outside of the #ifdef so it can be
>> > referenced correctly.
>> >
>> > Signed-off-by: Arnd Bergmann 
>> > Fixes: adf3442cc890 ("ARM: pxa: fix DFI bus lockups on startup")
>> > ---
>> > We merged the patch that introduced this as a fix for 4.3, so we should
>> > probably add this one too.
>> Oh yes, didn't see that ifdef, and all my non-regression defconfigs have
>> CONFIG_PM ...
>> 
>> Acked-by: Robert Jarzmik 
>> 
>> So do you want to take it directly (my preferred solution) or do you want a
>> proper pull request for in the -rc5 timeframe ?
>
> Applied now.
>
>   Arnd
Thanks.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] s390: crypto: replace raw value by their coresponding define

[LABBE Corentin]

SHA_MAX_STATE_SIZE is just the number of u32 word for SHA512.
So replace the raw value "16" by their meaning (SHA512_DIGEST_SIZE / 4)

Signed-off-by: LABBE Corentin 
---
 arch/s390/crypto/sha.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/crypto/sha.h b/arch/s390/crypto/sha.h
index f4e9dc7..10f2007 100644
--- a/arch/s390/crypto/sha.h
+++ b/arch/s390/crypto/sha.h
@@ -19,7 +19,7 @@
 #include 
 
 /* must be big enough for the largest SHA variant */
-#define SHA_MAX_STATE_SIZE 16
+#define SHA_MAX_STATE_SIZE (SHA512_DIGEST_SIZE / 4)
 #define SHA_MAX_BLOCK_SIZE  SHA512_BLOCK_SIZE
 
 struct s390_sha_ctx {
-- 
2.4.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Linus Torvalds]

On Wed, Oct 14, 2015 at 11:59 AM, Christoph Lameter  wrote:
> On Wed, 14 Oct 2015, Linus Torvalds wrote:
>
>> And "schedule_delayed_work()" uses WORK_CPU_UNBOUND.
>
> Uhhh. Someone changed that?

It always did.  This is from 2007:

int fastcall schedule_delayed_work(struct delayed_work *dwork,
unsigned long delay)
{
timer_stats_timer_set_start_info(>timer);
return queue_delayed_work(keventd_wq, dwork, delay);
}
...
int fastcall queue_delayed_work(struct workqueue_struct *wq,
struct delayed_work *dwork, unsigned long delay)
{
timer_stats_timer_set_start_info(>timer);
if (delay == 0)
return queue_work(wq, >work);

return queue_delayed_work_on(-1, wq, dwork, delay);
}
...
int queue_delayed_work_on(int cpu, struct workqueue_struct *wq,
struct delayed_work *dwork, unsigned long delay)
{

timer->function = delayed_work_timer_fn;

if (unlikely(cpu >= 0))
add_timer_on(timer, cpu);
else
add_timer(timer);
}
...
void delayed_work_timer_fn(unsigned long __data)
{
int cpu = smp_processor_id();
...
__queue_work(per_cpu_ptr(wq->cpu_wq, cpu), >work);
}


so notice how it always just used "add_timer()", and then queued it on
whatever cpu workqueue the timer ran on.

Now, 99.9% of the time, the timer is just added to the current CPU
queues, so yes, in practice it ended up running on the same CPU almost
all the time. There are exceptions (timers can get moved around, and
active timers end up staying on the CPU they were scheduled on when
they get updated, rather than get moved to the current cpu), but they
are hard to hit.

But the code clearly didn't do that "same CPU" intentionally, and just
going by naming of things I would also say that it was never implied.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] timer: Reduce unnecessary sighand lock contention

[Jason Low]

It was found while running a database workload on large systems that
significant time was spent trying to acquire the sighand lock.

The issue was that whenever an itimer expired, many threads ended up
simultaneously trying to send the signal. Most of the time, nothing
happened after acquiring the sighand lock because another thread
had just already sent the signal and updated the "next expire" time.
The fastpath_timer_check() didn't help much since the "next expire"
time was updated after the threads exit fastpath_timer_check().

This patch addresses this by having the thread_group_cputimer structure
maintain a boolean to signify when a thread in the group is already
checking for process wide timers, and adds extra logic in the fastpath
to check the boolean.

Signed-off-by: Jason Low 
Reviewed-by: Oleg Nesterov 
---
 include/linux/init_task.h  |1 +
 include/linux/sched.h  |3 +++
 kernel/time/posix-cpu-timers.c |   26 --
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index c43b80f..810a34f 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -60,6 +60,7 @@ extern struct fs_struct init_fs;
.cputimer   = { \
.cputime_atomic = INIT_CPUTIME_ATOMIC,  \
.running= false,\
+   .checking_timer = false,\
},  \
INIT_PREV_CPUTIME(sig)  \
.cred_guard_mutex = \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 35a9c46..0f1ebec 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -625,6 +625,8 @@ struct task_cputime_atomic {
  * @cputime_atomic:atomic thread group interval timers.
  * @running:   true when there are timers running and
  * @cputime_atomic receives updates.
+ * @checking_timer:true when a thread in the group is in the
+ * process of checking for thread group timers.
  *
  * This structure contains the version of task_cputime, above, that is
  * used for thread group CPU timer calculations.
@@ -632,6 +634,7 @@ struct task_cputime_atomic {
 struct thread_group_cputimer {
struct task_cputime_atomic cputime_atomic;
bool running;
+   bool checking_timer;
 };
 
 #include 
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 2d58153..957fbae 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -975,6 +975,12 @@ static void check_process_timers(struct task_struct *tsk,
if (!READ_ONCE(tsk->signal->cputimer.running))
return;
 
+/*
+* Signify that a thread is checking for process timers.
+* Write access to this field is protected by the sighand lock.
+*/
+   sig->cputimer.checking_timer = true;
+
/*
 * Collect the current process totals.
 */
@@ -1029,6 +1035,8 @@ static void check_process_timers(struct task_struct *tsk,
sig->cputime_expires.sched_exp = sched_expires;
if (task_cputime_zero(>cputime_expires))
stop_process_timers(sig);
+
+   sig->cputimer.checking_timer = false;
 }
 
 /*
@@ -1142,8 +1150,22 @@ static inline int fastpath_timer_check(struct 
task_struct *tsk)
}
 
sig = tsk->signal;
-   /* Check if cputimer is running. This is accessed without locking. */
-   if (READ_ONCE(sig->cputimer.running)) {
+   /*
+* Check if thread group timers expired when the cputimer is
+* running and no other thread in the group is already checking
+* for thread group cputimers. These fields are read without the
+* sighand lock. However, this is fine because this is meant to
+* be a fastpath heuristic to determine whether we should try to
+* acquire the sighand lock to check/handle timers.
+* 
+* In the worst case scenario, if 'running' or 'checking_timer' gets
+* set but the current thread doesn't see the change yet, we'll wait
+* until the next thread in the group gets a scheduler interrupt to
+* handle the timer. This isn't an issue in practice because these
+* types of delays with signals actually getting sent are expected.
+*/
+   if (READ_ONCE(sig->cputimer.running) &&
+   !READ_ONCE(sig->cputimer.checking_timer)) {
struct task_cputime group_sample;
 
sample_cputime_atomic(_sample, 
>cputimer.cputime_atomic);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled

[Javier Martinez Canillas]

Hello Stephen,

On 10/14/2015 08:38 PM, Stephen Boyd wrote:
> On 10/13, Javier Martinez Canillas wrote:
>> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
>> index 1530c9352a76..fc50b6264bed 100644
>> --- a/drivers/clk/versatile/Kconfig
>> +++ b/drivers/clk/versatile/Kconfig
>> @@ -1,6 +1,6 @@
>>  config COMMON_CLK_VERSATILE
>>  bool "Clock driver for ARM Reference designs"
>> -depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64
>> +depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 
>> || COMPILE_TEST
> 
> Have you compiled these drivers on an architecture that doesn't
> have IOMEM? Perhaps tile or um? I'm all for more build coverage,
> but it's not always as simple as just sprinkling some
> COMPILE_TEST around the Kconfigs.
>

No, I only build tested on arm32 and x86. The 0-day bot haven't reported a
build error yet and I didn't see any platform dependent code in the drivers.

But you are right that COMPILE_TEST is a little tricky, so maybe is safest
to drop this patch.

Is just that it would be nice to build as much as possible to make sure that
subystemms or kernel wide changes don't introduce regressions since that is
also tricky even when using tools like coccinelle.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/4] timer: Convert cputimer->running to bool

[Jason Low]

In the next patch in this series, a new field 'checking_timer' will
be added to 'struct thread_group_cputimer'. Both this and the
existing 'running' integer field are just used as boolean values. To
save space in the structure, we can make both of these fields booleans.

This is a preparatory patch to convert the existing running integer
field to a boolean.

Suggested-by: George Spelvin 
Signed-off-by: Jason Low 
---
 include/linux/init_task.h  |2 +-
 include/linux/sched.h  |6 +++---
 kernel/fork.c  |2 +-
 kernel/time/posix-cpu-timers.c |4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index e38681f..c43b80f 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -59,7 +59,7 @@ extern struct fs_struct init_fs;
.rlim   = INIT_RLIMITS, \
.cputimer   = { \
.cputime_atomic = INIT_CPUTIME_ATOMIC,  \
-   .running= 0,\
+   .running= false,\
},  \
INIT_PREV_CPUTIME(sig)  \
.cred_guard_mutex = \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 23ca455..35a9c46 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -623,15 +623,15 @@ struct task_cputime_atomic {
 /**
  * struct thread_group_cputimer - thread group interval timer counts
  * @cputime_atomic:atomic thread group interval timers.
- * @running:   non-zero when there are timers running and
- * @cputime receives updates.
+ * @running:   true when there are timers running and
+ * @cputime_atomic receives updates.
  *
  * This structure contains the version of task_cputime, above, that is
  * used for thread group CPU timer calculations.
  */
 struct thread_group_cputimer {
struct task_cputime_atomic cputime_atomic;
-   int running;
+   bool running;
 };
 
 #include 
diff --git a/kernel/fork.c b/kernel/fork.c
index 83dea82..fe3f371 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1101,7 +1101,7 @@ static void posix_cpu_timers_init_group(struct 
signal_struct *sig)
cpu_limit = READ_ONCE(sig->rlim[RLIMIT_CPU].rlim_cur);
if (cpu_limit != RLIM_INFINITY) {
sig->cputime_expires.prof_exp = secs_to_cputime(cpu_limit);
-   sig->cputimer.running = 1;
+   sig->cputimer.running = true;
}
 
/* The timer lists. */
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 6f6e252..2d58153 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -249,7 +249,7 @@ void thread_group_cputimer(struct task_struct *tsk, struct 
task_cputime *times)
 * but barriers are not required because update_gt_cputime()
 * can handle concurrent updates.
 */
-   WRITE_ONCE(cputimer->running, 1);
+   WRITE_ONCE(cputimer->running, true);
}
sample_cputime_atomic(times, >cputime_atomic);
 }
@@ -918,7 +918,7 @@ static inline void stop_process_timers(struct signal_struct 
*sig)
struct thread_group_cputimer *cputimer = >cputimer;
 
/* Turn off cputimer->running. This is done without locking. */
-   WRITE_ONCE(cputimer->running, 0);
+   WRITE_ONCE(cputimer->running, false);
 }
 
 static u32 onecputick;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] timer: Check thread timers only when there are active thread timers

[Jason Low]

The fastpath_timer_check() contains logic to check for if any timers
are set by checking if !task_cputime_zero(). Similarly, we can do this
before calling check_thread_timers(). In the case where there
are only process-wide timers, this will skip all of the computations for
per-thread timers when there are no per-thread timers.

As suggested by George, we can put the task_cputime_zero() check in
check_thread_timers(), since that is more of an optization to the
function. Similarly, we move the existing check of cputimer->running
to check_process_timers().

Signed-off-by: Jason Low 
Reviewed-by: Oleg Nesterov 
---
 kernel/time/posix-cpu-timers.c |   22 --
 1 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index aa4b6f4..6f6e252 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -864,6 +864,13 @@ static void check_thread_timers(struct task_struct *tsk,
unsigned long long expires;
unsigned long soft;
 
+   /*
+* If cputime_expires is zero, then there are no active
+* per thread CPU timers.
+*/
+   if (task_cputime_zero(>cputime_expires))
+   return;
+
expires = check_timers_list(timers, firing, prof_ticks(tsk));
tsk_expires->prof_exp = expires_to_cputime(expires);
 
@@ -962,6 +969,13 @@ static void check_process_timers(struct task_struct *tsk,
unsigned long soft;
 
/*
+* If cputimer is not running, then there are no active
+* process wide timers (POSIX 1.b, itimers, RLIMIT_CPU).
+*/
+   if (!READ_ONCE(tsk->signal->cputimer.running))
+   return;
+
+   /*
 * Collect the current process totals.
 */
thread_group_cputimer(tsk, );
@@ -1169,12 +1183,8 @@ void run_posix_cpu_timers(struct task_struct *tsk)
 * put them on the firing list.
 */
check_thread_timers(tsk, );
-   /*
-* If there are any active process wide timers (POSIX 1.b, itimers,
-* RLIMIT_CPU) cputimer must be running.
-*/
-   if (READ_ONCE(tsk->signal->cputimer.running))
-   check_process_timers(tsk, );
+
+   check_process_timers(tsk, );
 
/*
 * We must release these locks before taking any timer's lock.
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] timer: Improve itimers scalability

[Jason Low]

While running a database workload on a 16 socket machine, there were
scalability issues related to itimers. The following link contains a
more detailed summary of the issues at the application level.

https://lkml.org/lkml/2015/8/26/737

Commit 1018016c706f addressed the issue with the thread_group_cputimer
spinlock taking up a significant portion of total run time.
This patch series addresses the secondary issue where a lot of time is
spent trying to acquire the sighand lock. It was found in some cases
that 200+ threads were simultaneously contending for the same sighand
lock, reducing throughput by more than 30%.

With this patch set (along with commit 1018016c706f mentioned above),
the performance hit of itimers almost completely goes away on the
16 socket system.

Jason Low (4):
  timer: Optimize fastpath_timer_check()
  timer: Check thread timers only when there are active thread timers
  timer: Convert cputimer->running to bool
  timer: Reduce unnecessary sighand lock contention

 include/linux/init_task.h  |3 +-
 include/linux/sched.h  |9 --
 kernel/fork.c  |2 +-
 kernel/time/posix-cpu-timers.c |   63 ---
 4 files changed, 54 insertions(+), 23 deletions(-)

-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] stop_machine: ensure that a queued callback will be called before cpu_stop_park()

[Oleg Nesterov]

On 10/14, Peter Zijlstra wrote:
>
> On Thu, Oct 08, 2015 at 04:51:31PM +0200, Oleg Nesterov wrote:
> > cpu_stop_queue_work() checks stopper->enabled before it queues the
> > work, but ->enabled == T can only guarantee cpu_stop_signal_done()
> > if we race with cpu_down().
> >
> > This is not enough for stop_two_cpus() or stop_machine(), they will
> > deadlock if multi_cpu_stop() won't be called by one of the target
> > CPU's. stop_machine/stop_cpus are fine, they rely on stop_cpus_mutex.
> > But stop_two_cpus() has to check cpu_active() to avoid the same race
> > with hotplug, and this check is very unobvious and probably not even
> > correct if we race with cpu_up().
> >
> > Change cpu_down() pass to clear ->enabled before cpu_stopper_thread()
> > flushes the pending ->works and returns with KTHREAD_SHOULD_PARK set.
> >
> > Note also that smpboot_thread_call() calls cpu_stop_unpark() which
> > sets enabled == T at CPU_ONLINE stage, so this CPU can't go away until
> > cpu_stopper_thread() is called at least once. This all means that if
> > cpu_stop_queue_work() succeeds, we know that work->fn() will be called.
>
> This hard relies on the fact that cpu_down uses stop machine, right?

Not really.

> IIRC part of the hotplug rework Thomas is doing is geared towards
> breaking away from stop machine. There is nothing fundamental about
> hot-unplug that requires stop machine.

cpu_down() should park/kill/whatever the percpu stopper thread anyway.
And this path should clear ->enabled, it can also flush the pending
works.

And we need this anyway even if cpu_down() won't use stop_machine(),
I think.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/4] timer: Optimize fastpath_timer_check()

[Jason Low]

In fastpath_timer_check(), the task_cputime() function is always
called to compute the utime and stime values. However, this is not
necessary if there are no per-thread timers to check for. This patch
modifies the code such that we compute the task_cputime values only
when there are per-thread timers set.

Signed-off-by: Jason Low 
Reviewed-by: Oleg Nesterov 
Reviewed-by: Frederic Weisbecker 
Reviewed-by: Davidlohr Bueso 
---
 kernel/time/posix-cpu-timers.c |   11 +++
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 892e3da..aa4b6f4 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -1117,17 +1117,12 @@ static inline int task_cputime_expired(const struct 
task_cputime *sample,
 static inline int fastpath_timer_check(struct task_struct *tsk)
 {
struct signal_struct *sig;
-   cputime_t utime, stime;
-
-   task_cputime(tsk, , );
 
if (!task_cputime_zero(>cputime_expires)) {
-   struct task_cputime task_sample = {
-   .utime = utime,
-   .stime = stime,
-   .sum_exec_runtime = tsk->se.sum_exec_runtime
-   };
+   struct task_cputime task_sample;
 
+   task_cputime(tsk, _sample.utime, _sample.stime);
+   task_sample.sum_exec_runtime = tsk->se.sum_exec_runtime;
if (task_cputime_expired(_sample, >cputime_expires))
return 1;
}
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] acpi: set return value to const char for some functions

[LABBE Corentin]

This patch set some array of const char as const.
In the same time, some function return pointer to thoses array without
properly giving the information that the data is const.
This patch set the return type of thoses functions as const char *

Signed-off-by: LABBE Corentin 
---
 drivers/acpi/acpica/acutils.h  | 12 ++--
 drivers/acpi/acpica/utdecode.c | 24 
 drivers/acpi/acpica/uthex.c|  4 ++--
 drivers/acpi/tables.c  |  6 --
 4 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index fb2aa50..e5d9d4f 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -189,21 +189,21 @@ char *acpi_ut_get_mutex_name(u32 mutex_id);
 const char *acpi_ut_get_notify_name(u32 notify_value, acpi_object_type type);
 #endif
 
-char *acpi_ut_get_type_name(acpi_object_type type);
+const char *acpi_ut_get_type_name(acpi_object_type type);
 
 char *acpi_ut_get_node_name(void *object);
 
-char *acpi_ut_get_descriptor_name(void *object);
+const char *acpi_ut_get_descriptor_name(void *object);
 
 const char *acpi_ut_get_reference_name(union acpi_operand_object *object);
 
-char *acpi_ut_get_object_type_name(union acpi_operand_object *obj_desc);
+const char *acpi_ut_get_object_type_name(union acpi_operand_object *obj_desc);
 
-char *acpi_ut_get_region_name(u8 space_id);
+const char *acpi_ut_get_region_name(u8 space_id);
 
-char *acpi_ut_get_event_name(u32 event_id);
+const char *acpi_ut_get_event_name(u32 event_id);
 
-char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
+const char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
 
 u8 acpi_ut_ascii_char_to_hex(int hex_char);
 
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 988e23b..e08cdb1 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -114,7 +114,7 @@ const char 
*acpi_gbl_region_types[ACPI_NUM_PREDEFINED_REGIONS] = {
"PCC"   /* 0x0A */
 };
 
-char *acpi_ut_get_region_name(u8 space_id)
+const char *acpi_ut_get_region_name(u8 space_id)
 {
 
if (space_id >= ACPI_USER_REGION_BEGIN) {
@@ -127,7 +127,7 @@ char *acpi_ut_get_region_name(u8 space_id)
return ("InvalidSpaceId");
}
 
-   return (ACPI_CAST_PTR(char, acpi_gbl_region_types[space_id]));
+   return (ACPI_CAST_PTR(const char, acpi_gbl_region_types[space_id]));
 }
 
 
/***
@@ -152,14 +152,14 @@ static const char 
*acpi_gbl_event_types[ACPI_NUM_FIXED_EVENTS] = {
"RealTimeClock",
 };
 
-char *acpi_ut_get_event_name(u32 event_id)
+const char *acpi_ut_get_event_name(u32 event_id)
 {
 
if (event_id > ACPI_EVENT_MAX) {
return ("InvalidEventID");
}
 
-   return (ACPI_CAST_PTR(char, acpi_gbl_event_types[event_id]));
+   return (ACPI_CAST_PTR(const char, acpi_gbl_event_types[event_id]));
 }
 
 
/***
@@ -220,17 +220,17 @@ static const char *acpi_gbl_ns_type_names[] = {
/* 30 */ "Invalid"
 };
 
-char *acpi_ut_get_type_name(acpi_object_type type)
+const char *acpi_ut_get_type_name(acpi_object_type type)
 {
 
if (type > ACPI_TYPE_INVALID) {
-   return (ACPI_CAST_PTR(char, acpi_gbl_bad_type));
+   return (ACPI_CAST_PTR(const char, acpi_gbl_bad_type));
}
 
-   return (ACPI_CAST_PTR(char, acpi_gbl_ns_type_names[type]));
+   return (ACPI_CAST_PTR(const char, acpi_gbl_ns_type_names[type]));
 }
 
-char *acpi_ut_get_object_type_name(union acpi_operand_object *obj_desc)
+const char *acpi_ut_get_object_type_name(union acpi_operand_object *obj_desc)
 {
 
if (!obj_desc) {
@@ -318,7 +318,7 @@ static const char *acpi_gbl_desc_type_names[] = {
/* 15 */ "Node"
 };
 
-char *acpi_ut_get_descriptor_name(void *object)
+const char *acpi_ut_get_descriptor_name(void *object)
 {
 
if (!object) {
@@ -329,7 +329,7 @@ char *acpi_ut_get_descriptor_name(void *object)
return ("Not a Descriptor");
}
 
-   return (ACPI_CAST_PTR(char,
+   return (ACPI_CAST_PTR(const char,
  acpi_gbl_desc_type_names[ACPI_GET_DESCRIPTOR_TYPE
   (object)]));
 
@@ -400,7 +400,7 @@ const char *acpi_ut_get_reference_name(union 
acpi_operand_object *object)
 
 /* Names for internal mutex objects, used for debug output */
 
-static char *acpi_gbl_mutex_names[ACPI_NUM_MUTEX] = {
+static const char *acpi_gbl_mutex_names[ACPI_NUM_MUTEX] = {
"ACPI_MTX_Interpreter",
"ACPI_MTX_Namespace",
"ACPI_MTX_Tables",
@@ -411,7 +411,7 @@ static char *acpi_gbl_mutex_names[ACPI_NUM_MUTEX] = {
"ACPI_MTX_CommandReady"
 };
 
-char *acpi_ut_get_mutex_name(u32 mutex_id)
+const char *acpi_ut_get_mutex_name(u32 

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Tejun Heo]

Hello, Linus.

On Wed, Oct 14, 2015 at 10:36:50AM -0700, Linus Torvalds wrote:
> > For both delayed and !delayed work items on per-cpu workqueues,
> > queueing without specifying a specific CPU always meant queueing on
> > the local CPU.
> 
> That's just not true, as far as I can tell.
> 
> I went back in the history to 2012, and it does
> 
>   if (unlikely(cpu != WORK_CPU_UNBOUND))
>   add_timer_on(timer, cpu);
>   else
>   add_timer(timer);
>
> so this whole WORK_CPU_UNBOUND means "add_timer()" without specifying
> a CPU has been true for at least the last several years.
> 
> So the documentation, the code, and the name all agree:

But wasn't add_timer() always CPU-local at the time?  add_timer()
allowing cross-cpu migrations came way after that.

commit 597d0275736dad9c3bda6f0a00a1c477dc0f37b1
Author: Arun R Bharadwaj 
Date:   Thu Apr 16 12:13:26 2009 +0530

timers: Framework for identifying pinned timers

> WORK_CPU_UNBOUND does *not* mean that it's guaranteed to be the local
> CPU. The documentation says "preferred", the code clearly doesn't
> specify the CPU, and the name says "not bound to a particular CPU".

The name and documentation were mostly me being too hopeful and then
being lazy after realizing it wouldn't work.

> > I wish this were an ad-hoc thing but this has been the guaranteed
> > behavior all along.  Switching the specific call-site to
> > queue_work_on() would still be a good idea tho.
> 
> I really don't see who you say that it has been guaranteed behavior all along.

The behavior was just like that from the beginning.  Workqueues were
always CPU-affine and timers too and we never properly distinguished
CPU affinity for the purpose of correctness from optimization.

> It clearly has not at all been guaranteed behavior. The fact that you
> had to change the code to do that should have made it clear.

It wasn't like that before the timer change.

> The code has *always* done that non-cpu-specific "add_timer()", as far
> as I can tell. Even back when that non-bound CPU was indicated by a
> negative CPU number, and the code did
> 
> if (unlikely(cpu >= 0))
> add_timer_on(timer, cpu);
> else
> add_timer(timer);
> 
> (that's from 2007, btw).

At the time, it was just an alternative way to writing.

if (cpu < 0)
cpu = raw_smp_processor_id();
add_timer_on(timer, cpu);

> So I really don't see your "guaranteed behavior" argument. It seems to
> be downright pure bullshit. The lack of a specific CPU has _always_
> (where "always" means "at least since 2007") meant "non-specific cpu",
> rather than "local cpu".
>
> If some particular interface ended up then actually using "local cpu"
> instead, that was neither guaranteed nor implied - it was just a
> random implementation detail, and shouldn't be something we guarantee
> at all.
>
> We strive to maintain user-space ABI issues even in the face of
> unintentional bugs and misfeatures. But we do *not* keep broken random
> in-kernel interfaces alive. We fix breakage and clean up code rather
> than say "some random in-kernel user expects broken behavior".
> 
> And it seems very clear that WORK_CPU_UNBOUND does *not* mean "local
> cpu", and code that depends on it meaning local cpu is broken.
> 
> Now, there are reasons why the *implementation* might want to choose
> the local cpu for things - avoiding waking up other cpu's
> unnecessarily with cross-cpu calls etc - but at the same time I think
> it's quite clear that mm/vmstat.c is simply broken in using a
> non-bound interface and then expecting/assuming a particular CPU.

I don't think I'm confused about the timer behavior.  At any rate, for
!delayed work items, the failure to distinguish bound for correctness
and optimization has been for quite a while.  I'd be happy to ditch
that but I don't think it'd be a good idea to do this at -rc5 w/o
auditing or debug mechanisms to detect errors.

> >> (That said, it's not obvious to me why we don't just specify the cpu
> >> in the work structure itself, and just get rid of the "use different
> >> functions to schedule the work" model. I think it's somewhat fragile
> >> how you can end up using the same work in different "CPU boundedness"
> >> models like this).
> >
> > Hmmm... you mean associating a delayed work item with the target
> > pool_workqueue on queueing and sharing the queueing paths for both
> > delayed and !delayed work items?
> 
> I wouldn't necessarily even go that far. That's more of an
> implementation detail.
> 
> I just wonder if we perhaps should add the CPU boundedness to the init
> stage, and hide it away in the work structure. So if you just want to
> do work (delayed or not), you'd continue to do
> 
> INIT_DELAYED_WORK(, ...);
> 
> schedule_delayed_work(, delay);
> 
> but if you want a percpu thing, you'd do
> 
> 

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Linus Torvalds]

On Wed, Oct 14, 2015 at 11:37 AM, Linus Torvalds
 wrote:
>
> Yes, yes, it so _happens_ that "add_timer()" preferentially uses the
> current CPU etc, so in practice it may have happened to work. But
> there's absolutely zero reason to think it should always work that
> way.

Side note: even in practice, I think things like off-lining CPU's etc
(which some mobile environments seem to do as a power saving thing)
can end up moving timers to other CPU's even if they originally got
added on a particular cpu.

So I really think that the whole "schedule_delayed_work() ends up
running on the CPU" has actually never "really" been true. It has at
most been a "most of the time" thing, making it hard to see the
problem in practice.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Christoph Lameter]

On Wed, 14 Oct 2015, Linus Torvalds wrote:

> And "schedule_delayed_work()" uses WORK_CPU_UNBOUND.

Uhhh. Someone changed that?

> In this email you seem to even agree that its' bogus, but then you
> wrote another email saying that the code isn't confused, because it
> uses "schedule_delayed_work()" on the CPU that it wants to run the
> code on.
>
> I'm saying that mm/vmstat.c should use "schedule_delayed_work_on()".

Then that needs to be fixed. Could occur in more places.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Christoph Lameter]

On Wed, 14 Oct 2015, Linus Torvalds wrote:

> On Wed, Oct 14, 2015 at 10:57 AM, Christoph Lameter  wrote:
> >
> > Well yes the schedule_delayed_work_on() call is from another cpu and the
> > schedule_delayed_work() from the same. No confusion there.
>
> So "schedule_delayed_work()" does *not* guarantee that the work will
> run on the same CPU.

That is news to me. As far as I know: The only workqueue that is not
guaranteed to run on the same cpu is an unbound workqueue.

> If you want the scheduled work to happen on a particular CPU, then you
> should use "schedule_delayed_work_on()"  It shouldn't matter which CPU
> you call it from.

Ok then lets audit the kernel for this if that assumption is no longer
true.

> At least that's how I think the rules should be. Very simple, very
> clear: if you require a specific CPU, say so. Don't silently depend on
> "in practice, lots of times we tend to use the local cpu".

As far as I can remember this was guaranteed and not just practice.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][v5] PM / hibernate: Print the possible panic reason when resuming with inconsistent e820 map

[Chen Yu]

On some platforms, there is occasional panic triggered when trying to
resume from hibernation, a typical panic looks like:

"BUG: unable to handle kernel paging request at 880085894000
IP: [] load_image_lzo+0x8c2/0xe70"

This is because e820 map has been changed by BIOS before/after
hibernation, and one of the page frames from first kernel
is right located in second kernel's unmapped region, so panic
comes out when accessing unmapped kernel address.

In order to tell user why this happeneded, and for scalability,
we introduce a framework to compare the e820 maps before/after
hibernation. If these two e820 maps are not compatible with
each other, we will print the first corrupt e820 entry's information
(there might be more than one broken e820 entries) once system
goes into panic, for example:

BUG: unable to handle kernel paging request at 8800a9688000
IP: [] load_image_lzo+0x8c2/0xe70
PM: Hibernation Caution! Oops might be due to inconsistent e820 table.
PM: mem [0xa963b000-0xa963d000][ACPI Table] is an invalid old e820 region.
PM: Inconsistent with current [mem 0xa963b000-0xa963e000][ACPI Table].
PM: Please update your BIOS, or do not use hibernation on this machine.

The following e820 entries will be regarded as invalid ones:
1.E820_RAM:  old region is not a subset of any current region.
2.E820_ACPI: old region is not strictly the same as any current
 region(example above).

Signed-off-by: Chen Yu 
---
v5:
 - Rewrite this patch to just warn user of the broken BIOS
   when panic.
v4:
 - Add __attribute__ ((unused)) for swsusp_page_is_valid,
   to eliminate the warnning of:
   'swsusp_page_is_valid' defined but not used
   on non-x86 platforms.

v3:
 - Adjust the logic to exclude the end_pfn boundary in pfn_mapped
   when invoking mark_valid_pages, because the end_pfn is not
   a mapped page frame, we should not regard it as a valid page.

   Move the sanity check of valid pages to a early stage in resuming
   process(moved to mark_unsafe_pages), in this way, we can avoid
   unnecessarily accessing these invalid pages in later stage(yes,
   move to the original position Joey once introduced in:
   Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820
   reserved regions")

   With v3 patch applied, I did 30 cycles on my problematic platform,
   no panic triggered anymore(50% reproducible before patched, by
   plugging/unplugging memory peripheral during hibernation), and it
   just warns of invalid pages.
   
v2:
 - According to Ingo's suggestion, rewrite this patch.

   New version just checks each page frame according to pfn_mapped array.
   So that we do not need to touch existing code related to
   E820_RESERVED_KERN. And this method can naturely guarantee
   that the system before/after hibernation do not need to be of
   the same memory size on x86_64.
---
 arch/x86/Kconfig   |   4 +
 arch/x86/include/asm/suspend.h |   3 +
 arch/x86/power/Makefile|   2 +-
 arch/x86/power/hibernate.c | 229 +
 include/linux/suspend.h|  16 +++
 kernel/power/power.h   |   8 ++
 kernel/power/snapshot.c|   8 ++
 7 files changed, 269 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/power/hibernate.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 96d058a..0b2f10c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2132,6 +2132,10 @@ config ARCH_HIBERNATION_HEADER
def_bool y
depends on X86_64 && HIBERNATION
 
+config ARCH_RESUME_IMAGE_CHECKER
+   def_bool y
+   depends on HIBERNATION
+
 source "kernel/power/Kconfig"
 
 source "drivers/acpi/Kconfig"
diff --git a/arch/x86/include/asm/suspend.h b/arch/x86/include/asm/suspend.h
index 2fab6c2..63bc53e 100644
--- a/arch/x86/include/asm/suspend.h
+++ b/arch/x86/include/asm/suspend.h
@@ -3,3 +3,6 @@
 #else
 # include 
 #endif
+
+extern int arch_image_info_save(char *dst, char *src, unsigned int limit_len);
+extern bool arch_image_info_check(const char *new, const char *old);
diff --git a/arch/x86/power/Makefile b/arch/x86/power/Makefile
index a6a198c..47596e2 100644
--- a/arch/x86/power/Makefile
+++ b/arch/x86/power/Makefile
@@ -4,4 +4,4 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_cpu.o   := $(nostackp)
 
 obj-$(CONFIG_PM_SLEEP) += cpu.o
-obj-$(CONFIG_HIBERNATION)  += hibernate_$(BITS).o hibernate_asm_$(BITS).o
+obj-$(CONFIG_HIBERNATION)  += hibernate_$(BITS).o hibernate_asm_$(BITS).o 
hibernate.o
diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
new file mode 100644
index 000..d90b7ed
--- /dev/null
+++ b/arch/x86/power/hibernate.c
@@ -0,0 +1,229 @@
+/*
+ * Hibernation common support for x86
+ *
+ * Distribute under GPLv2
+ *
+ * Copyright (c) 2015 Chen Yu 
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * The following section is to check whether the old e820 map
+ * (system before hibernation) is compatible with current
+ * e820 map(system for 

[PATCH 1/1] Revert "kmod: handle UMH_WAIT_PROC from system unbound workqueue"

[Oleg Nesterov]

This reverts commit bb304a5c6fc63d8506cd9741a3a5f35b73605625.

Because this patch leads to kthread zombies.

call_usermodehelper_exec_sync() does fork() + wait() with "unignored"
SIGCHLD. What we have missed is that this worker thread can have other
children previously forked by call_usermodehelper_exec_work() without
UMH_WAIT_PROC. If such a child exits in between it becomes a zombie
and nobody can reap it (unless/until this worker thread exits too).

Signed-off-by: Oleg Nesterov 
---
 kernel/kmod.c | 44 
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index da98d05..d38b2da 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -265,9 +265,15 @@ out:
do_exit(0);
 }
 
-/* Handles UMH_WAIT_PROC.  */
-static void call_usermodehelper_exec_sync(struct subprocess_info *sub_info)
+/*
+ * Handles UMH_WAIT_PROC. Our parent (unbound workqueue) might not be able to
+ * run enough instances to handle usermodehelper completions without blocking
+ * some other pending requests. That's why we use a kernel thread dedicated for
+ * that purpose.
+ */
+static int call_usermodehelper_exec_sync(void *data)
 {
+   struct subprocess_info *sub_info = data;
pid_t pid;
 
/* If SIGCLD is ignored sys_wait4 won't populate the status. */
@@ -281,9 +287,9 @@ static void call_usermodehelper_exec_sync(struct 
subprocess_info *sub_info)
 * Normally it is bogus to call wait4() from in-kernel because
 * wait4() wants to write the exit code to a userspace address.
 * But call_usermodehelper_exec_sync() always runs as kernel
-* thread (workqueue) and put_user() to a kernel address works
-* OK for kernel threads, due to their having an mm_segment_t
-* which spans the entire address space.
+* thread and put_user() to a kernel address works OK for kernel
+* threads, due to their having an mm_segment_t which spans the
+* entire address space.
 *
 * Thus the __user pointer cast is valid here.
 */
@@ -298,21 +304,19 @@ static void call_usermodehelper_exec_sync(struct 
subprocess_info *sub_info)
sub_info->retval = ret;
}
 
-   /* Restore default kernel sig handler */
-   kernel_sigaction(SIGCHLD, SIG_IGN);
-
umh_complete(sub_info);
+   do_exit(0);
 }
 
 /*
- * We need to create the usermodehelper kernel thread from a task that is 
affine
+ * This function doesn't strictly needs to be called asynchronously. But we
+ * need to create the usermodehelper kernel threads from a task that is affine
  * to an optimized set of CPUs (or nohz housekeeping ones) such that they
  * inherit a widest affinity irrespective of call_usermodehelper() callers with
  * possibly reduced affinity (eg: per-cpu workqueues). We don't want
  * usermodehelper targets to contend a busy CPU.
  *
- * Unbound workqueues provide such wide affinity and allow to block on
- * UMH_WAIT_PROC requests without blocking pending request (up to some limit).
+ * Unbound workqueues provide such wide affinity.
  *
  * Besides, workqueues provide the privilege level that caller might not have
  * to perform the usermodehelper request.
@@ -322,18 +326,18 @@ static void call_usermodehelper_exec_work(struct 
work_struct *work)
 {
struct subprocess_info *sub_info =
container_of(work, struct subprocess_info, work);
+   pid_t pid;
 
-   if (sub_info->wait & UMH_WAIT_PROC) {
-   call_usermodehelper_exec_sync(sub_info);
-   } else {
-   pid_t pid;
-
+   if (sub_info->wait & UMH_WAIT_PROC)
+   pid = kernel_thread(call_usermodehelper_exec_sync, sub_info,
+   CLONE_FS | CLONE_FILES | SIGCHLD);
+   else
pid = kernel_thread(call_usermodehelper_exec_async, sub_info,
SIGCHLD);
-   if (pid < 0) {
-   sub_info->retval = pid;
-   umh_complete(sub_info);
-   }
+
+   if (pid < 0) {
+   sub_info->retval = pid;
+   umh_complete(sub_info);
}
 }
 
-- 
2.4.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/1] Revert "kmod: handle UMH_WAIT_PROC from system unbound workqueue"

[Oleg Nesterov]

Hello,

I noticed by accident the kworker zombies on my testing machine.
Can't reproduce (although I think it won't be hard to make a
test-case), but I think the reason is clear, see the changelog.

We could fix this by using kthread_create() if !UMH_WAIT_PROC,
but imo it would be better to revert this change at least for
now. If we really want to avoid the extra kernel_thread(), we
can make another patch which also avoids sys_wait4() and the
games with SIGCHLD; we can rely on wait_chldexit.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] watchdog: Compile possible drivers with COMPILE_TEST

[Luis de Bethencourt]

These drivers have depends that aren't build dependencies, so it's
a good idea to allow these drivers to always be built when the
COMPILE_TEST option is enabled.

That way, the drivers can be built with a config generated by make
allyesconfig and check if a patch would break the build.

Signed-off-by: Luis de Bethencourt 
---

Hi,

I have removed the COMPILE_TEST for SIRFSOC_WATCHDOG, since the kbuild test
robot complained with warnings about it.

Thanks,
Luis

 drivers/watchdog/Kconfig | 46 +++---
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 79e1aa1..b3d69c3 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -190,7 +190,7 @@ config AT91SAM9X_WATCHDOG
 
 config SAMA5D4_WATCHDOG
tristate "Atmel SAMA5D4 Watchdog Timer"
-   depends on ARCH_AT91
+   depends on ARCH_AT91 || COMPILE_TEST
select WATCHDOG_CORE
help
  Atmel SAMA5D4 watchdog timer is embedded into SAMA5D4 chips.
@@ -261,7 +261,7 @@ config HAVE_S3C2410_WATCHDOG
 
 config S3C2410_WATCHDOG
tristate "S3C2410 Watchdog"
-   depends on HAVE_S3C2410_WATCHDOG
+   depends on HAVE_S3C2410_WATCHDOG || COMPILE_TEST
select WATCHDOG_CORE
select MFD_SYSCON if ARCH_EXYNOS5
help
@@ -299,7 +299,7 @@ config DW_WATCHDOG
 
 config EP93XX_WATCHDOG
tristate "EP93xx Watchdog"
-   depends on ARCH_EP93XX
+   depends on ARCH_EP93XX || COMPILE_TEST
select WATCHDOG_CORE
help
  Say Y here if to include support for the watchdog timer
@@ -310,7 +310,7 @@ config EP93XX_WATCHDOG
 
 config OMAP_WATCHDOG
tristate "OMAP Watchdog"
-   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || COMPILE_TEST
select WATCHDOG_CORE
help
  Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog. 
 Say 'Y'
@@ -346,7 +346,7 @@ config IOP_WATCHDOG
 
 config DAVINCI_WATCHDOG
tristate "DaVinci watchdog"
-   depends on ARCH_DAVINCI || ARCH_KEYSTONE
+   depends on ARCH_DAVINCI || ARCH_KEYSTONE || COMPILE_TEST
select WATCHDOG_CORE
help
  Say Y here if to include support for the watchdog timer
@@ -380,7 +380,7 @@ config RN5T618_WATCHDOG
 
 config SUNXI_WATCHDOG
tristate "Allwinner SoCs watchdog support"
-   depends on ARCH_SUNXI
+   depends on ARCH_SUNXI || COMPILE_TEST
select WATCHDOG_CORE
help
  Say Y here to include support for the watchdog timer
@@ -409,7 +409,7 @@ config TWL4030_WATCHDOG
 
 config STMP3XXX_RTC_WATCHDOG
tristate "Freescale STMP3XXX & i.MX23/28 watchdog"
-   depends on RTC_DRV_STMP
+   depends on RTC_DRV_STMP || COMPILE_TEST
select WATCHDOG_CORE
help
  Say Y here to include support for the watchdog timer inside
@@ -419,7 +419,7 @@ config STMP3XXX_RTC_WATCHDOG
 
 config NUC900_WATCHDOG
tristate "Nuvoton NUC900 watchdog"
-   depends on ARCH_W90X900
+   depends on ARCH_W90X900 || COMPILE_TEST
help
  Say Y here if to include support for the watchdog timer
  for the Nuvoton NUC900 series SoCs.
@@ -428,7 +428,7 @@ config NUC900_WATCHDOG
 
 config TS72XX_WATCHDOG
tristate "TS-72XX SBC Watchdog"
-   depends on MACH_TS72XX
+   depends on MACH_TS72XX || COMPILE_TEST
help
  Technologic Systems TS-7200, TS-7250 and TS-7260 boards have
  watchdog timer implemented in a external CPLD chip. Say Y here
@@ -446,7 +446,7 @@ config MAX63XX_WATCHDOG
 
 config IMX2_WDT
tristate "IMX2+ Watchdog"
-   depends on ARCH_MXC
+   depends on ARCH_MXC || COMPILE_TEST
select REGMAP_MMIO
select WATCHDOG_CORE
help
@@ -484,7 +484,7 @@ config RETU_WATCHDOG
 
 config MOXART_WDT
tristate "MOXART watchdog"
-   depends on ARCH_MOXART
+   depends on ARCH_MOXART || COMPILE_TEST
help
  Say Y here to include Watchdog timer support for the watchdog
  existing on the MOXA ART SoC series platforms.
@@ -503,7 +503,7 @@ config SIRFSOC_WATCHDOG
 
 config ST_LPC_WATCHDOG
tristate "STMicroelectronics LPC Watchdog"
-   depends on ARCH_STI
+   depends on ARCH_STI || COMPILE_TEST
depends on OF
select WATCHDOG_CORE
help
@@ -539,7 +539,7 @@ config QCOM_WDT
 
 config MESON_WATCHDOG
tristate "Amlogic Meson SoCs watchdog support"
-   depends on ARCH_MESON
+   depends on ARCH_MESON || COMPILE_TEST
select WATCHDOG_CORE
help
  Say Y here to include support for the watchdog timer
@@ -549,7 +549,7 @@ config MESON_WATCHDOG
 
 config MEDIATEK_WATCHDOG
tristate "Mediatek SoCs watchdog support"
-   depends on ARCH_MEDIATEK
+   depends on ARCH_MEDIATEK || COMPILE_TEST
select WATCHDOG_CORE
help
  Say Y here to include 

Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management

[James Bottomley]

On Wed, 2015-10-14 at 11:34 -0700, Lee Duncan wrote:
> On 10/14/2015 06:55 AM, James Bottomley wrote:
> > On Wed, 2015-10-07 at 16:51 -0700, Lee Duncan wrote:
> >> Update the SCSI hosts module to use the ida_simple*() routines
> >> to manage its host_no index instead of an ATOMIC integer. This
> >> means that the SCSI host number will now be reclaimable.
> > 
> > OK, but why would we want to do this?  We do it for sd because our minor
> > space for the device nodes is very constrained, so packing is essential.
> > For HBAs, there's no device space density to worry about, they're
> > largely statically allocated at boot time and not reusing the numbers
> > allows easy extraction of hotplug items for the logs (quite useful for
> > USB) because each separate hotplug has a separate and monotonically
> > increasing host number.
> > 
> > James
> > 
> 
> Good question, James. Apologies for not making the need clear.
> 
> The iSCSI subsystem uses a host structure for discovery, then throws it
> away. So each time it does discovery it gets a new host structure. With
> the current approach, that number is ever increasing. It's only a matter
> of time until some user with a hundreds of disks and perhaps thousands
> of LUNs, that likes to do periodic discovery (think super-computers)
> will run out of host numbers. Or, worse yet, get a negative number
> number (because the value is signed right now).
> 
> And this use case is a real one right now, by the way.

Um, so even if you do discovery continuously, say one every second, it
still will take 68 years before we wrap the sign.

> As you can see from the patch, it's a small amount of code to ensure
> that the host number management is handled more cleanly.

Well, I'm a bit worried about the loss of a monotonically increasing
host number from the debugging perspective.  Right now, if you look at
any log, hostX always refers to one and only one incarnation throughout
the system lifetime for any given value of X.  With your patch, the
lowest host number gets continually reused ... probably for every hot
plug event.  If the USB and other hotplug system people don't mind this,
I suppose I can live with it, but I'd like to hear their view before
making this change.

James



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

[Andy Lutomirski]

On Wed, Oct 14, 2015 at 11:34 AM, Stas Sergeev  wrote:
> 14.10.2015 21:06, Andy Lutomirski пишет:
>>> Also it doesn't seem to be saying what happens if CS is 32-bit
>>> and SS is invalid (the flag is not set).
>>
>> A new signal will be delivered.  sigreturn doesn't modify its behavior
>> in this case -- it does the default thing, which is to honor the SS in
>> the saved context.
> Hmm, no, it didn't do this in the past for sure.
> It simply ignored SS, no matter to what mode it returns.
>

What I mean is: it has the behavior it would have normally on a new
kernel, which is to honor the saved SS.  I'll try to improve the
comment.

>>  So it will actually try to use that saved SS
>> value, which will fail, causing SIGSEGV.
> So it seems this logic assumes that when dosemu returns to 32bit,
> the previous SS is always still valid, am I right with the understanding?
> I.e. the one that kernel have saved on a signal delivery (because
> old dosemu does not overwrite it).
> If it is so, I'd say this assumption is very risky and will likely
> not hold. But maybe I am missing the point.
>

That's the assumption.  If I understand correctly, though, old DOSEMU
never actually returns to 32-bit using sigreturn in the first place,
since old kernels gave no control over SS.  Doesn't old DOSEMU always
return to the 64-bit IRET trampoline?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] debugfs: Add debugfs_create_ulong()

[Stephen Boyd]

On 10/09, Viresh Kumar wrote:
> +struct dentry *debugfs_create_xlong(const char *name, umode_t mode,
> + struct dentry *parent, unsigned long *value)
> +{
> + return debugfs_create_file(name, mode, parent, value, _xlong);

Were you going to refresh this on my debugfs_create_mode()
patches? Otherwise the patch looks fine to me.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v2 6/6] net: dsa: remove port_fdb_getnext

[Florian Fainelli]

On 13/10/15 09:46, Vivien Didelot wrote:
> No driver implements port_fdb_getnext anymore, and port_fdb_dump is
> preferred anyway, so remove this function from DSA.
> 
> Signed-off-by: Vivien Didelot 

Acked-by: Florian Fainelli 
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v2 1/6] net: dsa: add port_fdb_dump function

[Florian Fainelli]

On 13/10/15 09:46, Vivien Didelot wrote:
> Not all switch chips support a Get Next operation to iterate on its FDB.
> So add a more simple port_fdb_dump function for them.
> 
> Signed-off-by: Vivien Didelot 

Acked-by: Florian Fainelli 
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] usb: dwc2: host: Fix use after free w/ simultaneous irqs

[Douglas Anderson]

While plugging / unplugging on a DWC2 host port with "slub_debug=FZPUA"
enabled, I found a crash that was quite obviously a use after free.

It appears that in some cases when we handle the various sub-cases of
HCINT we may end up freeing the QTD.  If there is more than one bit set
in HCINT we may then end up continuing to use the QTD, which is bad.
Let's be paranoid and check for this after each sub-case.  We only do
this if there are still further bits to process, so the overhead should
be small.  This should be safe since we officially have the
"hsotg->lock" (it was grabbed in dwc2_handle_hcd_intr).

The specific crash I found was:
 Unable to handle kernel paging request at virtual address 6b6b6b9f

At the time of the crash, the kernel reported:
 (dwc2_hc_nak_intr+0x5c/0x198)
 (dwc2_handle_hcd_intr+0xa84/0xbf8)
 (_dwc2_hcd_irq+0x1c/0x20)
 (usb_hcd_irq+0x34/0x48)

Popping into kgdb found that "*qtd" was filled with "0x6b", AKA qtd had
been freed and filled with slub_debug poison.

kgdb gave a little better stack crawl:
 0 dwc2_hc_nak_intr (hsotg=hsotg@entry=0xec42e058,
 chan=chan@entry=0xec546dc0, chnum=chnum@entry=4,
 qtd=qtd@entry=0xec679600) at drivers/usb/dwc2/hcd_intr.c:1237
 1 dwc2_hc_n_intr (chnum=4, hsotg=0xec42e058) at
 drivers/usb/dwc2/hcd_intr.c:2041
 2 dwc2_hc_intr (hsotg=0xec42e058) at drivers/usb/dwc2/hcd_intr.c:2078
 3 dwc2_handle_hcd_intr (hsotg=0xec42e058) at
 drivers/usb/dwc2/hcd_intr.c:2128
 4 _dwc2_hcd_irq (hcd=) at drivers/usb/dwc2/hcd.c:2837
 5 usb_hcd_irq (irq=, __hcd=) at
 drivers/usb/core/hcd.c:2353

Popping up to frame #1 (dwc2_hc_n_intr) found:
 (gdb) print /x hcint
 $12 = 0x12

AKA:
 #define HCINTMSK_CHHLTD  (1 << 1)
 #define HCINTMSK_NAK (1 << 4)

Further debugging found that by simulating receiving those two
interrupts at the same time it was trivial to replicate the
use-after-free.  See  for a patch and
instructions.  This lead to getting the following stack crawl of the
actual free:
 0  arch_kgdb_breakpoint () at arch/arm/include/asm/outercache.h:103
 1  kgdb_breakpoint () at kernel/debug/debug_core.c:1054
 2  dwc2_hcd_qtd_unlink_and_free (hsotg=, qh=, qtd=0xe4479a00) at drivers/usb/dwc2/hcd.h:488
 3  dwc2_deactivate_qh (free_qtd=, qh=0xe5efa280,
  hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:671
 4  dwc2_release_channel (hsotg=hsotg@entry=0xed424618,
  chan=chan@entry=0xed5be000, qtd=,
  halt_status=) at drivers/usb/dwc2/hcd_intr.c:742
 5  dwc2_halt_channel (hsotg=0xed424618, chan=0xed5be000, qtd=, halt_status=) at
  drivers/usb/dwc2/hcd_intr.c:804
 6  dwc2_complete_non_periodic_xfer (chnum=,
  halt_status=, qtd=, chan=, hsotg=) at drivers/usb/dwc2/hcd_intr.c:889
 7  dwc2_hc_xfercomp_intr (hsotg=hsotg@entry=0xed424618,
  chan=chan@entry=0xed5be000, chnum=chnum@entry=6,
  qtd=qtd@entry=0xe4479a00) at drivers/usb/dwc2/hcd_intr.c:1065
 8  dwc2_hc_chhltd_intr_dma (qtd=0xe4479a00, chnum=6, chan=0xed5be000,
  hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:1823
 9  dwc2_hc_chhltd_intr (qtd=0xe4479a00, chnum=6, chan=0xed5be000,
  hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:1944
 10 dwc2_hc_n_intr (chnum=6, hsotg=0xed424618) at
  drivers/usb/dwc2/hcd_intr.c:2052
 11 dwc2_hc_intr (hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:2097
 12 dwc2_handle_hcd_intr (hsotg=0xed424618) at
  drivers/usb/dwc2/hcd_intr.c:2147
 13 _dwc2_hcd_irq (hcd=) at drivers/usb/dwc2/hcd.c:2837
 14 usb_hcd_irq (irq=, __hcd=) at
  drivers/usb/core/hcd.c:2353

Though we could add specific code to handle this case, adding the
general purpose code to check for all cases where qtd might be freed
seemed safer.

Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/hcd_intr.c | 80 +++--
 1 file changed, 70 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index f70c970..57e71f9d 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -1949,6 +1949,25 @@ static void dwc2_hc_chhltd_intr(struct dwc2_hsotg *hsotg,
}
 }
 
+/*
+ * Check if the given qtd is still the top of the list (and thus valid).
+ *
+ * If dwc2_hcd_qtd_unlink_and_free() has been called since we grabbed
+ * the qtd from the top of the list, this will return NULL.  Otherwise
+ * it will be passed back qtd.
+ */
+struct dwc2_qtd *dwc2_check_qtd_still_ok(struct dwc2_qtd *qtd,
+   struct list_head *qtd_list)
+{
+   struct dwc2_qtd *cur_head;
+
+   cur_head = list_first_entry(qtd_list, struct dwc2_qtd, qtd_list_entry);
+   if (cur_head == qtd)
+   return qtd;
+
+   return NULL;
+}
+
 /* Handles interrupt for a specific Host Channel */
 static void dwc2_hc_n_intr(struct dwc2_hsotg *hsotg, int chnum)
 {
@@ -2031,26 +2050,67 @@ static void dwc2_hc_n_intr(struct dwc2_hsotg *hsotg, 
int chnum)
 */
hcint &= ~HCINTMSK_NYET;
   

[PATCH v2] thermal: db8500_cpufreq_cooling: Compile with COMPILE_TEST

[Luis de Bethencourt]

This driver only has runtime but no build time dependencies, so it can be
built for testing purposes if the Kconfig COMPILE_TEST option is enabled.

This is useful to have more build coverage and make sure that drivers are
not affected by changes that could cause build regressions.

Signed-off-by: Luis de Bethencourt 
---

Hi,

This is the second version of:
https://lkml.org/lkml/2015/10/14/691

After removing COMPILE_TEST for INTEL_QUARK_DTS_THERMAL, only
DB8500_CPUFREQ_COOLING remains. Which is why I have changed the subject line
of the commit message.

Sorry for the kbuild test robot failure in the first version.

Thanks,
Luis

 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a94ebb5..cdaf469 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -252,7 +252,7 @@ config TEGRA_SOCTHERM
 
 config DB8500_CPUFREQ_COOLING
tristate "DB8500 cpufreq cooling"
-   depends on ARCH_U8500
+   depends on ARCH_U8500 || COMPILE_TEST
depends on CPU_THERMAL
default y
help
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Linus Torvalds]

On Wed, Oct 14, 2015 at 11:03 AM, Christoph Lameter  wrote:
> On Wed, 14 Oct 2015, Linus Torvalds wrote:
>>
>> So why is this a bugfix? If cpu == WORK_CPU_UNBOUND, then things
>> _shouldn't_ care which cpu it gets run on.
>
> UNBOUND means not fixed to a processor.

That's exactly what I'm saying.

And "schedule_delayed_work()" uses WORK_CPU_UNBOUND.

YOUR code assumes that means "local CPU".

And I say that's bogus.

In this email you seem to even agree that its' bogus, but then you
wrote another email saying that the code isn't confused, because it
uses "schedule_delayed_work()" on the CPU that it wants to run the
code on.

I'm saying that mm/vmstat.c should use "schedule_delayed_work_on()".

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled

[Stephen Boyd]

On 10/13, Javier Martinez Canillas wrote:
> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
> index 1530c9352a76..fc50b6264bed 100644
> --- a/drivers/clk/versatile/Kconfig
> +++ b/drivers/clk/versatile/Kconfig
> @@ -1,6 +1,6 @@
>  config COMMON_CLK_VERSATILE
>   bool "Clock driver for ARM Reference designs"
> - depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64
> + depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 
> || COMPILE_TEST

Have you compiled these drivers on an architecture that doesn't
have IOMEM? Perhaps tile or um? I'm all for more build coverage,
but it's not always as simple as just sprinkling some
COMPILE_TEST around the Kconfigs.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] workqueue fixes for v4.3-rc5

[Linus Torvalds]

On Wed, Oct 14, 2015 at 10:57 AM, Christoph Lameter  wrote:
>
> Well yes the schedule_delayed_work_on() call is from another cpu and the
> schedule_delayed_work() from the same. No confusion there.

So "schedule_delayed_work()" does *not* guarantee that the work will
run on the same CPU.

Yes, yes, it so _happens_ that "add_timer()" preferentially uses the
current CPU etc, so in practice it may have happened to work. But
there's absolutely zero reason to think it should always work that
way.

If you want the scheduled work to happen on a particular CPU, then you
should use "schedule_delayed_work_on()"  It shouldn't matter which CPU
you call it from.

At least that's how I think the rules should be. Very simple, very
clear: if you require a specific CPU, say so. Don't silently depend on
"in practice, lots of times we tend to use the local cpu".

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 4/5] null_nvm: LightNVM test driver

[kbuild test robot]

Hi Matias,

[auto build test ERROR on block/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Matias-Bj-rling/Support-for-Open-Channel-SSDs/20151014-224617
config: mips-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> drivers/lightnvm/built-in.o:(.discard+0x0): multiple definition of 
>> `__pcpu_unique_completion_queues'
   drivers/block/built-in.o:(.discard+0x0): first defined here

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

[Stas Sergeev]

14.10.2015 21:06, Andy Lutomirski пишет:
>> Also it doesn't seem to be saying what happens if CS is 32-bit
>> and SS is invalid (the flag is not set).
> 
> A new signal will be delivered.  sigreturn doesn't modify its behavior
> in this case -- it does the default thing, which is to honor the SS in
> the saved context.
Hmm, no, it didn't do this in the past for sure.
It simply ignored SS, no matter to what mode it returns.

>  So it will actually try to use that saved SS
> value, which will fail, causing SIGSEGV.
So it seems this logic assumes that when dosemu returns to 32bit,
the previous SS is always still valid, am I right with the understanding?
I.e. the one that kernel have saved on a signal delivery (because
old dosemu does not overwrite it).
If it is so, I'd say this assumption is very risky and will likely
not hold. But maybe I am missing the point.

 - with siglongjmp()
>>>
>>> siglongjmp is a glibc thing.  It should work the same way it always
>>> did.  If it internally does a syscall (sigprocmask or whatever), that
>>> will override SS.
>> IMHO this side-effect needs to be documented somewhere.
>> I was scared about using it because I thought SS could be left bad.
>> Why I think it IS the kernel's problem is because in an ideal world
>> the sighandler should not run with LDT SS at all, so there will be no
>> fear about a bad SS after siglongjmp().
> 
> I agree, but that ship sailed quite a few years ago :(
Please, once again you are claiming there were no solutions proposed
in that area. :(
If you didn't repeatedly ignore the SA_hyz solution, there will be the
chance to do exactly that. But whatever.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management

[Lee Duncan]

On 10/14/2015 06:55 AM, James Bottomley wrote:
> On Wed, 2015-10-07 at 16:51 -0700, Lee Duncan wrote:
>> Update the SCSI hosts module to use the ida_simple*() routines
>> to manage its host_no index instead of an ATOMIC integer. This
>> means that the SCSI host number will now be reclaimable.
> 
> OK, but why would we want to do this?  We do it for sd because our minor
> space for the device nodes is very constrained, so packing is essential.
> For HBAs, there's no device space density to worry about, they're
> largely statically allocated at boot time and not reusing the numbers
> allows easy extraction of hotplug items for the logs (quite useful for
> USB) because each separate hotplug has a separate and monotonically
> increasing host number.
> 
> James
> 

Good question, James. Apologies for not making the need clear.

The iSCSI subsystem uses a host structure for discovery, then throws it
away. So each time it does discovery it gets a new host structure. With
the current approach, that number is ever increasing. It's only a matter
of time until some user with a hundreds of disks and perhaps thousands
of LUNs, that likes to do periodic discovery (think super-computers)
will run out of host numbers. Or, worse yet, get a negative number
number (because the value is signed right now).

And this use case is a real one right now, by the way.

As you can see from the patch, it's a small amount of code to ensure
that the host number management is handled more cleanly.

-- 
Lee Duncan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 1/2] clk: samsung: exynos5250: Add DISP1 clocks

[Stephen Boyd]

On 10/14, Tomeu Vizoso wrote:
> When the DISP1 power domain is powered off, there's two clocks that need
> to be temporarily reparented to OSC, and back to their original parents
> when the domain is powered on again.
> 
> We expose these two clocks in the DT bindings so that the DT node of the
> power domain can reference them.
> 
> Signed-off-by: Tomeu Vizoso 
> ---

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sched, x86: Fix typo in comments in __switch_to()

[Chuck Ebbert]

Fix obvious mistake: FS/GS should be DS/ES.

Signed-off-by: Chuck Ebbert 

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index d7f1d5c..e835d26 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -332,7 +332,7 @@ __switch_to(struct task_struct *prev_p, struct task_struct 
*next_p)
/*
 * Switch FS and GS.
 *
-* These are even more complicated than FS and GS: they have
+* These are even more complicated than DS and ES: they have
 * 64-bit bases are that controlled by arch_prctl.  Those bases
 * only differ from the values in the GDT or LDT if the selector
 * is 0.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: max77802: Update MODULE_AUTHOR() email address

[Stephen Boyd]

On 10/14, Javier Martinez Canillas wrote:
> The email address listed in MODULE_AUTHOR() no longer exist so to prevent
> people to send emails to the old address, replace it with my current one.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal: kconfig: When possible, compile drivers with COMPILE_TEST

[kbuild test robot]

Hi Luis,

[auto build test ERROR on thermal/next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Luis-de-Bethencourt/thermal-kconfig-When-possible-compile-drivers-with-COMPILE_TEST/20151015-001830
config: arm64-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> drivers/thermal/intel_quark_dts_thermal.c:64:31: fatal error: 
>> asm/cpu_device_id.h: No such file or directory
#include 
  ^
   compilation terminated.

vim +64 drivers/thermal/intel_quark_dts_thermal.c

8c187693 Ong, Boon Leong 2015-04-15  48   * LIMITED TO, PROCUREMENT OF 
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
8c187693 Ong, Boon Leong 2015-04-15  49   * DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY
8c187693 Ong, Boon Leong 2015-04-15  50   * THEORY OF LIABILITY, WHETHER IN 
CONTRACT, STRICT LIABILITY, OR TORT
8c187693 Ong, Boon Leong 2015-04-15  51   * (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING IN ANY WAY OUT OF THE USE
8c187693 Ong, Boon Leong 2015-04-15  52   * OF THIS SOFTWARE, EVEN IF ADVISED 
OF THE POSSIBILITY OF SUCH DAMAGE.
8c187693 Ong, Boon Leong 2015-04-15  53   *
8c187693 Ong, Boon Leong 2015-04-15  54   * Quark DTS thermal driver is 
implemented by referencing
8c187693 Ong, Boon Leong 2015-04-15  55   * intel_soc_dts_thermal.c.
8c187693 Ong, Boon Leong 2015-04-15  56   */
8c187693 Ong, Boon Leong 2015-04-15  57  
8c187693 Ong, Boon Leong 2015-04-15  58  #define pr_fmt(fmt) KBUILD_MODNAME ": 
" fmt
8c187693 Ong, Boon Leong 2015-04-15  59  
8c187693 Ong, Boon Leong 2015-04-15  60  #include 
8c187693 Ong, Boon Leong 2015-04-15  61  #include 
8c187693 Ong, Boon Leong 2015-04-15  62  #include 
8c187693 Ong, Boon Leong 2015-04-15  63  #include 
8c187693 Ong, Boon Leong 2015-04-15 @64  #include 
8c187693 Ong, Boon Leong 2015-04-15  65  #include 
8c187693 Ong, Boon Leong 2015-04-15  66  
8c187693 Ong, Boon Leong 2015-04-15  67  #define X86_FAMILY_QUARK   0x5
8c187693 Ong, Boon Leong 2015-04-15  68  #define X86_MODEL_QUARK_X1000  0x9
8c187693 Ong, Boon Leong 2015-04-15  69  
8c187693 Ong, Boon Leong 2015-04-15  70  /* DTS reset is programmed via 
QRK_MBI_UNIT_SOC */
8c187693 Ong, Boon Leong 2015-04-15  71  #define QRK_DTS_REG_OFFSET_RESET   
0x34
8c187693 Ong, Boon Leong 2015-04-15  72  #define QRK_DTS_RESET_BIT  
BIT(0)

:: The code at line 64 was first introduced by commit
:: 8c1876939663191b5044807230fa295f35462215 thermal: intel Quark SoC X1000 
DTS thermal driver

:: TO: Ong, Boon Leong 
:: CC: Zhang Rui 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH RESEND 3/4] Staging: rtl8712: Coding style warnings fix for block comments

[Punit Vara]

This patch is to the rtl871x_ioctl_linux.c file that fixes up following
warnings reported by checkpatch.pl :

-Block comments use * on subsequent lines
-Block comments use a trailing */ on a separate line

Signed-off-by: Punit Vara 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 1c9092e..fc1028a 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -797,13 +797,13 @@ static int r871x_wx_set_pmkid(struct net_device *dev,
int intReturn = false;
 
 /*
-   There are the BSSID information in the bssid.sa_data array.
-   If cmd is IW_PMKSA_FLUSH, it means the wpa_supplicant wants to clear
-   all the PMKID information. If cmd is IW_PMKSA_ADD, it means the
-   wpa_supplicant wants to add a PMKID/BSSID to driver.
-   If cmd is IW_PMKSA_REMOVE, it means the wpa_supplicant wants to
-   remove a PMKID/BSSID from driver.
-*/
+ * There are the BSSID information in the bssid.sa_data array.
+ * If cmd is IW_PMKSA_FLUSH, it means the wpa_supplicant wants to clear
+ * all the PMKID information. If cmd is IW_PMKSA_ADD, it means the
+ * wpa_supplicant wants to add a PMKID/BSSID to driver.
+ * If cmd is IW_PMKSA_REMOVE, it means the wpa_supplicant wants to
+ * remove a PMKID/BSSID from driver.
+ */
if (pPMK == NULL)
return -EINVAL;
memcpy(strIssueBssid, pPMK->bssid.sa_data, ETH_ALEN);
@@ -818,7 +818,8 @@ static int r871x_wx_set_pmkid(struct net_device *dev,
if (!memcmp(psecuritypriv->PMKIDList[j].Bssid,
strIssueBssid, ETH_ALEN)) {
/* BSSID is matched, the same AP => rewrite
-* with new PMKID. */
+* with new PMKID.
+*/
netdev_info(dev, "r8712u: %s: BSSID exists in 
the PMKList.\n",
__func__);
memcpy(psecuritypriv->PMKIDList[j].PMKID,
@@ -850,7 +851,8 @@ static int r871x_wx_set_pmkid(struct net_device *dev,
if (!memcmp(psecuritypriv->PMKIDList[j].Bssid,
strIssueBssid, ETH_ALEN)) {
/* BSSID is matched, the same AP => Remove
-* this PMKID information and reset it. */
+* this PMKID information and reset it.
+*/

eth_zero_addr(psecuritypriv->PMKIDList[j].Bssid);
psecuritypriv->PMKIDList[j].bUsed = false;
break;
@@ -1587,7 +1589,8 @@ static int r8711_wx_set_enc(struct net_device *dev,
} else {
wep.KeyLength = 0;
if (keyindex_provided == 1) { /* set key_id only, no given
-  * KeyMaterial(erq->length==0).*/
+  * KeyMaterial(erq->length==0).
+  */
padapter->securitypriv.PrivacyKeyIndex = key;
switch (padapter->securitypriv.DefKeylen[key]) {
case 5:
@@ -2240,7 +2243,8 @@ static iw_handler r8711_handlers[] = {
r8711_wx_set_wap,   /* SIOCSIWAP */
r8711_wx_get_wap,   /* SIOCGIWAP */
r871x_wx_set_mlme,  /* request MLME operation;
-*  uses struct iw_mlme */
+*  uses struct iw_mlme
+*/
dummy,  /* SIOCGIWAPLIST -- deprecated */
r8711_wx_set_scan,  /* SIOCSIWSCAN */
r8711_wx_get_scan,  /* SIOCGIWSCAN */
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()

[Punit Vara]

This patch is to the rtl871x_ioctl_linux.c file that fixes up following
warning reported by checkpatch.pl :

-Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()

bssid and pnetwork->network.MacAddress both are 6 byte
array which aligned with u16

Signed-off-by: Punit Vara 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 143be0f..b19556a 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -2008,7 +2008,7 @@ static int r871x_get_ap_info(struct net_device *dev,
return -EINVAL;
}
netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
-   if (!memcmp(bssid, pnetwork->network.MacAddress, ETH_ALEN)) {
+   if (ether_addr_equal(bssid, pnetwork->network.MacAddress)) {
/* BSSID match, then check if supporting wpa/wpa2 */
pbuf = r8712_get_wpa_ie(>network.IEs[12],
   _ielen, pnetwork->network.IELength-12);
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] Staging: rtl8712: fix warning for placing constant on the right side of test

[Punit Vara]

Put constant on the right side of a test.Problem found using checkpatch: 

Warning:Comparisons should place the constant on the right side of the test

Signed-off-by: Punit Vara 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index fc1028a..e9852ae 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -959,7 +959,7 @@ static int r871x_wx_set_priv(struct net_device *dev,
if (IS_ERR(ext))
return PTR_ERR(ext);
 
-   if (0 == strcasecmp(ext, "RSSI")) {
+   if (strcasecmp(ext, "RSSI") == 0) {
/*Return received signal strength indicator in -db for */
/* current AP */
/* Rssi xx */
@@ -976,7 +976,7 @@ static int r871x_wx_set_priv(struct net_device *dev,
} else {
sprintf(ext, "OK");
}
-   } else if (0 == strcasecmp(ext, "LINKSPEED")) {
+   } else if (strcasecmp(ext, "LINKSPEED") == 0) {
/*Return link speed in MBPS */
/*LinkSpeed xx */
union iwreq_data wrqd;
@@ -984,30 +984,30 @@ static int r871x_wx_set_priv(struct net_device *dev,
int mbps;
 
ret_inner = r8711_wx_get_rate(dev, info, , extra);
-   if (0 != ret_inner)
+   if (ret_inner != 0)
mbps = 0;
else
mbps = wrqd.bitrate.value / 100;
sprintf(ext, "LINKSPEED %d", mbps);
-   } else if (0 == strcasecmp(ext, "MACADDR")) {
+   } else if (strcasecmp(ext, "MACADDR") == 0) {
/*Return mac address of the station */
/* Macaddr = xx:xx:xx:xx:xx:xx */
sprintf(ext, "MACADDR = %pM", dev->dev_addr);
-   } else if (0 == strcasecmp(ext, "SCAN-ACTIVE")) {
+   } else if (strcasecmp(ext, "SCAN-ACTIVE") == 0) {
/*Set scan type to active */
/*OK if successful */
struct mlme_priv *pmlmepriv = >mlmepriv;
 
pmlmepriv->passive_mode = 1;
sprintf(ext, "OK");
-   } else if (0 == strcasecmp(ext, "SCAN-PASSIVE")) {
+   } else if (strcasecmp(ext, "SCAN-PASSIVE") == 0) {
/*Set scan type to passive */
/*OK if successful */
struct mlme_priv *pmlmepriv = >mlmepriv;
 
pmlmepriv->passive_mode = 0;
sprintf(ext, "OK");
-   } else if (0 == strncmp(ext, "DCE-E", 5)) {
+   } else if (strncmp(ext, "DCE-E", 5) == 0) {
/*Set scan type to passive */
/*OK if successful */
r8712_disconnectCtrlEx_cmd(padapter
@@ -1017,7 +1017,7 @@ static int r871x_wx_set_priv(struct net_device *dev,
, 5000 /*u32 firstStageTO */
);
sprintf(ext, "OK");
-   } else if (0 == strncmp(ext, "DCE-D", 5)) {
+   } else if (strncmp(ext, "DCE-D", 5) == 0) {
/*Set scan type to passive */
/*OK if successfu */
r8712_disconnectCtrlEx_cmd(padapter
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND 1/4] Staging: rtl8712: Fix warning prefer eth_broadcast_addr() over memset()

[Punit Vara]

This patch is to the rtl871x_ioctl_linux.c that fixes up following
warning by checkpatch.pl:

-Prefer eth_broadcast_addr() over memset()

Signed-off-by: Punit Vara 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 143be0f..2ba055d 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1811,8 +1811,7 @@ static int r871x_wx_set_enc_ext(struct net_device *dev,
if (param == NULL)
return -ENOMEM;
param->cmd = IEEE_CMD_SET_ENCRYPTION;
-   memset(param->sta_addr, 0xff, ETH_ALEN);
-
+   eth_broadcast_addr(param->sta_addr);
strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
if (pext->ext_flags & IW_ENCODE_EXT_GROUP_KEY)
param->u.crypt.set_tx = 0;
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND 0/4] Staging: rtl8712: Fix coding style warnings

[Punit Vara]

This set of patch fixes following warnings reported by checkpatch.pl:

-Prefer eth_broadcast_addr() over memset()
-Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()
-Block comments use * on subsequent lines
-Block comments use a trailing */ on a separate line
-Comparisons should place the constant on the right side of the test

v2: Fixed API suggested by : Larry Finger  larry.fin...@lwfinger.net
Improved patch description suggested by Julia julia.law...@lip6.fr
Punit Vara (4):
  Staging: rtl8712: Fix warning prefer eth_broadcast_addr() over
memset()
  Staging: rtl8712: Use ether_addr_equal() over memcmp()
  Staging: rtl8712: Coding style warnings fix for block comments
  Staging: rtl8712: fix warning for placing constant on the right side
of test

 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 47 ++-
 1 file changed, 25 insertions(+), 22 deletions(-)

--
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] gpio/xilinx: enable for MIPS

[Moritz Fischer]

On Wed, Oct 14, 2015 at 10:33 AM, Sören Brinkmann
 wrote:
> On Wed, 2015-10-14 at 07:24PM +0200, Lars-Peter Clausen wrote:
>> On 10/14/2015 06:54 PM, Sören Brinkmann wrote:
>> > On Wed, 2015-10-14 at 05:57PM +0200, Lars-Peter Clausen wrote:
>> >> On 10/14/2015 05:18 PM, Sören Brinkmann wrote:
>> >>> On Wed, 2015-10-14 at 01:51PM +0100, Zubair Lutfullah Kakakhel wrote:
>>  MIPSfpga uses the axi gpio controller. Enable the driver for MIPS.
>> 
>>  Signed-off-by: Zubair Lutfullah Kakakhel 
>>  ---
>>   drivers/gpio/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>>  diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>>  index 8949b3f..58e9afd 100644
>>  --- a/drivers/gpio/Kconfig
>>  +++ b/drivers/gpio/Kconfig
>>  @@ -508,7 +508,7 @@ config GPIO_XGENE_SB
>> 
>>   config GPIO_XILINX
>>   tristate "Xilinx GPIO support"
>>  -depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86)
>>  +depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 
>>  || MIPS)
>> >>>
>> >>> Hmm, in general, this driver is hopefully generic enough that it doesn't
>> >>> have any real architecture dependencies. And I suspect, we want to
>> >>> enable this driver for ARM64 for ZynqMP soon too. Should we probably
>> >>> drop these arch dependencies completely? It seems to become quite a long 
>> >>> list.
>> >>
>> >> I've been thinking about this a while ago. This is certainly not the only
>> >> driver affected by this problem. But the thing is people always complain 
>> >> if
>> >> new symbols become visable in Kconfig that don't apply to their platform.
>> >>
>> >> Maybe we should introduce a HAS_REPROGRAMABLE_LOGIC (or similar) feature
>> >> Kconfig symbol and let platforms which have a FPGA select it and let 
>> >> drivers
>> >> for FPGA peripherals depend on it.
>> >
>> > Sounds like a good idea to me. But, does that work for all use-cases.
>> > E.g. if you plug some PCIe card with an FPGA into an x86(_64) machine.
>> > That would allow you to use those drivers, but I'm not sure how that
>> > could pull in the new config symbol.
>>
>> Hm, right. We could also make it a user-selectable config symbol. In that
>> case you only need to disable one symbol when you don't have FPGA support
>> rather than one for each driver. Although I'm not quite sure where to put
>> such a symbol.
>
> Eventually, the FPGA manager subsystem could probably provide some high
> level config symbols. Though, it is probably also not given that every
> FPGA-enabled platform needs the FPGA manager.

I agree. I suspect most platforms will not actually runtime reload the
FPGA using
FPGA manager they probably use onboard flash or something similar.

>
> Sören
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 14/26] clk: mvebu: Convert to clk_hw based provider APIs

[Stephen Boyd]

On 10/14, Thomas Petazzoni wrote:
> On Fri, 31 Jul 2015 10:03:54 -0700, Stephen Boyd wrote:
> > @@ -209,9 +208,8 @@ static void __init of_cpu_clk_setup(struct device_node 
> > *node)
> > goto bail_out;
> >  
> > sprintf(clk_name, "cpu%d", cpu);
> > -   parent_clk = of_clk_get(node, 0);
> >  
> > -   cpuclk[cpu].parent_name = __clk_get_name(parent_clk);
> > +   cpuclk[cpu].parent_name = of_clk_get_parent_name(node, 0);
> > cpuclk[cpu].clk_name = clk_name;
> > cpuclk[cpu].cpu = cpu;
> > cpuclk[cpu].reg_base = clock_complex_base;
> 
> Sorry to chime in only right now, but this patch causes a regression on
> Armada XP: the cpu clocks are no longer seen as child of their parent
> and therefore their rate is always 0. This breaks cpufreq on this
> platform.
> 
[...]
> 
> Stephen, what do you suggest to fix this issue?

Simplest fix is to revert this hunk. Longer term, we should look
into making of_clk_get_parent_name() use whatever string has been
used when registering the clock, or completely change how we do
parent child linkages so that strings aren't necessary.

> 
> The easiest solution is to add a clock-output-names property to the
> coreclk node. This way, of_clk_get_parent_name() will properly resolve
> the clock name to its correct name (i.e, "cpuclk" in our case) and
> everything works fine (I've tested). The drawback of this solution is
> that it breaks backward compatibility with old DTs: a 4.2 DT for Armada
> XP would no longer work with a >= 4.3 kernel.
> 
> Do you have some other suggestions to make ?
> 

How about this patch?

---8<
diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index 5837eb8a212f..85da8b983256 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -197,6 +197,7 @@ static void __init of_cpu_clk_setup(struct device_node 
*node)
for_each_node_by_type(dn, "cpu") {
struct clk_init_data init;
struct clk *clk;
+   struct clk *parent_clk;
char *clk_name = kzalloc(5, GFP_KERNEL);
int cpu, err;
 
@@ -208,8 +209,9 @@ static void __init of_cpu_clk_setup(struct device_node 
*node)
goto bail_out;
 
sprintf(clk_name, "cpu%d", cpu);
+   parent_clk = of_clk_get(node, 0);
 
-   cpuclk[cpu].parent_name = of_clk_get_parent_name(node, 0);
+   cpuclk[cpu].parent_name = __clk_get_name(parent_clk);
cpuclk[cpu].clk_name = clk_name;
cpuclk[cpu].cpu = cpu;
cpuclk[cpu].reg_base = clock_complex_base;
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] SCSI: Fix hard lockup in scsi_remove_target()

[Christoph Hellwig]

On Wed, Oct 14, 2015 at 08:45:56AM -0700, James Bottomley wrote:
> OK, so I really need you to separate the problems.  Fixing the bug
> you're reporting does not require a complete rework of the locking
> infrastructure; it just requires replacing the traversal macro with the
> safe version, can you verify that and it can go into fixes?

_safe only protects against deletions from yourself, it does not protect
against other threads once a lock is dropped.  After auditing the
target reap code I fear the list_move trick isn't safe either, as
scsi_target_alloc relies on a being able to find a target that is
currently in the process of being deleted.  So the only safe variant
we have is to keep the same sequence we currently have and restart the
loop once we've deleted the target.  Given that we'd normally only
ever delete a single target anyway (not sure when we'd even get a second
one ever) this does not seem to be a major efficieny problem.

Johannes, can you test the patch below?

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index b89f..d3b34d8 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1158,31 +1158,23 @@ static void __scsi_remove_target(struct scsi_target 
*starget)
 void scsi_remove_target(struct device *dev)
 {
struct Scsi_Host *shost = dev_to_shost(dev->parent);
-   struct scsi_target *starget, *last = NULL;
+   struct scsi_target *starget;
unsigned long flags;
 
-   /* remove targets being careful to lookup next entry before
-* deleting the last
-*/
+restart:
spin_lock_irqsave(shost->host_lock, flags);
list_for_each_entry(starget, >__targets, siblings) {
if (starget->state == STARGET_DEL)
continue;
if (starget->dev.parent == dev || >dev == dev) {
-   /* assuming new targets arrive at the end */
kref_get(>reap_ref);
spin_unlock_irqrestore(shost->host_lock, flags);
-   if (last)
-   scsi_target_reap(last);
-   last = starget;
__scsi_remove_target(starget);
-   spin_lock_irqsave(shost->host_lock, flags);
+   scsi_target_reap(starget);
+   goto restart;
}
}
spin_unlock_irqrestore(shost->host_lock, flags);
-
-   if (last)
-   scsi_target_reap(last);
 }
 EXPORT_SYMBOL(scsi_remove_target);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Tony Lindgren]

* Franklin S Cooper Jr.  [151014 09:27]:
> 
> 
> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> > * Franklin S Cooper Jr.  [151014 07:37]:
> >>
> >> On 10/14/2015 09:11 AM, Roger Quadros wrote:
> >>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>  On 10/14/2015 06:52 AM, Roger Quadros wrote:
> > Franklin,
> >
> > On 14/10/15 14:36, Roger Quadros wrote:
> >> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> >>> Switch from dma_request_channel to allow passing dma channel
> >>> information from DT rather than hardcoding a value.
> >>>
> >>> Signed-off-by: Franklin S Cooper Jr 
> >> Acked-by: Roger Quadros 
> >>
> >>> ---
> >>>  drivers/mtd/nand/omap2.c | 4 +++-
> >>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>> index d0f2620..957c32f 100644
> >>> --- a/drivers/mtd/nand/omap2.c
> >>> +++ b/drivers/mtd/nand/omap2.c
> >>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
> >>> platform_device *pdev)
> >>>   dma_cap_zero(mask);
> >>>   dma_cap_set(DMA_SLAVE, mask);
> >>>   sig = OMAP24XX_DMA_GPMC;
> >>> - info->dma = dma_request_channel(mask, 
> >>> omap_dma_filter_fn, );
> >>> + info->dma = dma_request_slave_channel_compat(mask,
> >>> + omap_dma_filter_fn, , pdev->dev.parent, 
> >>> "rxtx");
> >>> +
> > Just discovered that you are using the parent device node.
> >
> > How about moving the dma bindings to the nand node instead and using
> > pdev->dev here?
>  Roger,
> 
>  From what I can tell the interrupt number and the dma channel will 
>  always be
>  the same no matter what. Doesn't matter if you have multiple nands or a
>  combination of nands and nors. Since that is the case I think it just 
>  makes
>  sense to leave it in the gpmc parent node and define it once.
> >>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> >>> or only for NAND?
> >> The dma seems tied to the prefetch. From what I can tell the prefetch is 
> >> only
> >> used by nand.
> >>> Let's also get Tony's inputs on this.
> >> Sure.
> > Hmm so what would keep other devices from using the prefetch
> Looking at the TRM any references to the prefetch are always with respect to
> NAND.
> 
> I also see the below mentioned in the TRM.
> Pre-fetch and write posting engine associated with system DMA to get full 
> performance from NAND
> device with minimum impact on NOR/SRAM concurrent access.

OK up to you guys to figure out if it may be usable in a generic way then :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: nvec: fixed few coding style warnings

[Dan Carpenter]

On Wed, Oct 14, 2015 at 07:38:22PM +0530, Sakshi Bansal wrote:
> Fixed allignmnet issues and block comments usage
> 

Split it apart by type of fix.

> @@ -617,7 +618,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>   } else {
>   nvec->rx = nvec_msg_alloc(nvec, NVEC_MSG_RX);
>   /* Should not happen in a normal world */
> - if (unlikely(nvec->rx == NULL)) {
> + if (!unlikely(nvec->rx)) {

This isn't right.  You intented to say:

if (unlikely(!nvec->rx)) {

But even better to just remove the unlikely entirely.

if (!nvec->rx) {

>   nvec->state = 0;
>   break;
>   }

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

[Andy Lutomirski]

On Wed, Oct 14, 2015 at 10:40 AM, Stas Sergeev  wrote:
> 14.10.2015 19:40, Andy Lutomirski пишет:
 + *
 + * Kernels that set UC_SIGCONTEXT_SS will also set UC_STRICT_RESTORE_SS
 + * when delivering a signal that came from 64-bit code.
 + *
 + * Sigreturn modifies its behavior depending on the UC_STRICT_RESTORE_SS
 + * flag.  If UC_STRICT_RESTORE_SS is set, then the SS value in the
 + * signal context is restored verbatim.  If UC_STRICT_RESTORE_SS is not
 + * set, the CS value in the signal context refers to a 64-bit code
 + * segment, and the signal context's SS value is invalid, it will be
 + * replaced by an flat 32-bit selector.
> Is this correct?
> It says "64-bit code segment will use the 32-bit SS".
> I guess you mean 64-bit SS instead of a 32-bit?

There is no such thing as a 64-bit SS.  The case this is guarding against is:

void handler(...) {
  ctx->cs = [some 64-bit value];
  modify_ldt(zap the old SS);
  return;
}

Old DOSEMU does this IIUC.  It's trying to switch back to 64-bit mode,
and the value of SS that gets loaded into the SS selector doesn't
matter, but something *valid* needs to be loaded.  (Remember the weird
ISA design: the SS descriptor is basically irrelevant in 64-bit mode,
but it still has to be valid.)  On old kernels, this works, because
sigreturn zaps SS unconditionally.  On new kernels, it'll be
interpreted as an attempt to change CS and restore the old SS, but
that SS is no longer valid.  The fixup is to avoid sending a new
signal and to instead do what DOSEMU expected.

> Also it doesn't seem to be saying what happens if CS is 32-bit
> and SS is invalid (the flag is not set).

A new signal will be delivered.  sigreturn doesn't modify its behavior
in this case -- it does the default thing, which is to honor the SS in
the saved context.  So it will actually try to use that saved SS
value, which will fail, causing SIGSEGV.

>
 This is a bit risky, and another option would be to do nothing at
 all.
>>> Andy, could you please stop pretending there are no other solutions?
>>> You do not have to like them. You do not have to implement them.
>>> But your continuous re-assertions that they do not exist, make me
>>> feel a bit uncomfortable after I spelled them many times.
>>>
 Stas, what do you think?  Could you test this?
>>> I think I'll get to testing this only at a week-end.
>>> In a mean time, the question about a safety of leaving LDT SS
>>> in 64bit mode still makes me wonder. Perhaps, instead of re-iterating
>>> this here, you can describe this all in the patch comments? Namely:
>>> - How will LDT SS interact with nested signals
>>
>> The kernel doesn't think about nested signals.  If the inner signal is
>> delivered while SS is in the LDT, the kernel will try to keep it as is
>> and will stick whatever was in SS when the signal happened in the
>> inner saved context.  On return to the outer signal, it'll restore it
>> following the UC_STRICT_RESTORE_SS rules.
> Good.
>
>>> - with syscalls
>>
>> 64-bit syscalls change SS to some default flat value as a side-effect.
>> (Actually, IIRC, 64-bit syscalls change it specifically to __USER_DS,
>> but, on Xen, 64-bit fast syscall returns may silently flip it to a
>> different flat selector.)
> Do we need this?
> Maybe it should stop doing so?
>

It's a performance trick IIUC.  I don't know enough about Xen's
innards to know whether this could be cleaned up without incurring
nasty overheads.  As a guess, Xen doesn't want to change the MSR
controlling the SYSRET selector layout when switching guests, so it
uses a default value that doesn't match Linux's.  Linux mostly ignores
this, and it only really matters if user code cares which flat
selector gets loaded.

This shouldn't have much effect on segmented programs, as they don't
use SYSRET in segmented contexts.

>>> - with siglongjmp()
>>
>> siglongjmp is a glibc thing.  It should work the same way it always
>> did.  If it internally does a syscall (sigprocmask or whatever), that
>> will override SS.
> IMHO this side-effect needs to be documented somewhere.
> I was scared about using it because I thought SS could be left bad.
> Why I think it IS the kernel's problem is because in an ideal world
> the sighandler should not run with LDT SS at all, so there will be no
> fear about a bad SS after siglongjmp().

I agree, but that ship sailed quite a few years ago :(

> And if the sigprocmask() will
> sometime stop validating SS, this can lead to surprises.

Not possible without ISA changes.  The SYSCALL instruction itself
forgets the old SS value.

In any event, there's not much the kernel can do about this.  You
could ask the glibc people to document some well-defined behavior in
their man pages.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at