[PATCH 1/4] staging: atomisp: fix unsigned int comparison with less than zero

[Daeseok Youn]

Fix warnings from the smatch tool

atomisp_cmd.c:2649
  atomisp_set_array_res() warn:
  unsigned 'config->width' is never less than zero.

atomisp_cmd.c:2650
  atomisp_set_array_res() warn:
  unsigned 'config->height' is never less than zero.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 1ee99d0..9c3ba11 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -2646,8 +2646,7 @@ int atomisp_set_array_res(struct atomisp_sub_device *asd,
 struct atomisp_resolution  *config)
 {
dev_dbg(asd->isp->dev, ">%s start\n", __func__);
-   if (config == NULL || config->width < 0
-   || config->height < 0) {
+   if (!config) {
dev_err(asd->isp->dev, "Set sensor array size is not valid\n");
return -EINVAL;
}
-- 
1.9.1

[PATCH 1/4] staging: atomisp: fix unsigned int comparison with less than zero

[Daeseok Youn]

Fix warnings from the smatch tool

atomisp_cmd.c:2649
  atomisp_set_array_res() warn:
  unsigned 'config->width' is never less than zero.

atomisp_cmd.c:2650
  atomisp_set_array_res() warn:
  unsigned 'config->height' is never less than zero.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 1ee99d0..9c3ba11 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -2646,8 +2646,7 @@ int atomisp_set_array_res(struct atomisp_sub_device *asd,
 struct atomisp_resolution  *config)
 {
dev_dbg(asd->isp->dev, ">%s start\n", __func__);
-   if (config == NULL || config->width < 0
-   || config->height < 0) {
+   if (!config) {
dev_err(asd->isp->dev, "Set sensor array size is not valid\n");
return -EINVAL;
}
-- 
1.9.1

[PATCH v3] tpm_crb: request and relinquish locality 0

[Jarkko Sakkinen]

From: Jarkko Sakkinen 

This commit adds support for requesting and relinquishing locality 0 in
tpm_crb for the course of command transmission.

In order to achieve this, two new callbacks are added to struct
tpm_class_ops:

- request_locality
- relinquish_locality

These are called before sending and receiving data from the TPM.  We
update also tpm_tis_core to use these callbacks. A small modification to
request_locality() is done so that it returns -EBUSY instead of locality
number when check_locality() fails in order to return something
meaningful to the user space.

With CRB interface you first set either requestAccess or relinquish bit
from TPM_LOC_CTRL_x register and then wait for locAssigned and
tpmRegValidSts bits to be set in the TPM_LOC_STATE_x register.

The reason why were are doing this is to make sure that the driver
will work properly with Intel TXT that uses locality 2. There's no
explicit guarantee that it would relinquish this locality. In more
general sense this commit enables tpm_crb to be a well behaving
citizen in a multi locality environment.

Signed-off-by: Jarkko Sakkinen 
---
v2:
- TPM driver level calllbacks
v3:
- Call ops->relinquish_locality only if ops->request_locality has been
  successful.
- Do not reserve locality in nested tpm_transmit calls.
- Check for tpmRegValidSts to make sure that the value in TPM_LOC_STATE_x is
  stable.
 drivers/char/tpm/tpm-interface.c | 10 ++
 drivers/char/tpm/tpm.h   |  3 ++-
 drivers/char/tpm/tpm2-space.c| 15 +--
 drivers/char/tpm/tpm_crb.c   | 41 
 drivers/char/tpm/tpm_tis_core.c  | 12 
 include/linux/tpm.h  |  3 ++-
 6 files changed, 68 insertions(+), 16 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 95c6f98..4cd216f 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -384,6 +384,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct 
tpm_space *space,
ssize_t len = 0;
u32 count, ordinal;
unsigned long stop;
+   bool no_locality = !(flags & TPM_TRANSMIT_HAS_LOCALITY);
 
if (!tpm_validate_command(chip, buf, bufsiz))
return -EINVAL;
@@ -407,6 +408,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct 
tpm_space *space,
if (chip->dev.parent)
pm_runtime_get_sync(chip->dev.parent);
 
+   if (no_locality && chip->ops->request_locality)  {
+   rc = chip->ops->request_locality(chip, 0);
+   if (rc)
+   goto out_no_locality;
+   }
+
rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
goto out;
@@ -466,6 +473,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct 
tpm_space *space,
rc = tpm2_commit_space(chip, space, ordinal, buf, );
 
 out:
+   if (no_locality && chip->ops->relinquish_locality)
+   chip->ops->relinquish_locality(chip, 0, false);
+out_no_locality:
if (chip->dev.parent)
pm_runtime_put_sync(chip->dev.parent);
 
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 5eacb3f..ba2c00d 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -521,7 +521,8 @@ extern const struct file_operations tpmrm_fops;
 extern struct idr dev_nums_idr;
 
 enum tpm_transmit_flags {
-   TPM_TRANSMIT_UNLOCKED   = BIT(0),
+   TPM_TRANSMIT_UNLOCKED   = BIT(0),
+   TPM_TRANSMIT_HAS_LOCALITY   = BIT(1),
 };
 
 ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index d36d81e..43d05ab 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -19,6 +19,9 @@
 #include 
 #include "tpm.h"
 
+#define TPM_TRANSMIT_NESTED \
+   (TPM_TRANSMIT_UNLOCKED | TPM_TRANSMIT_HAS_LOCALITY)
+
 enum tpm2_handle_types {
TPM2_HT_HMAC_SESSION= 0x0200,
TPM2_HT_POLICY_SESSION  = 0x0300,
@@ -39,7 +42,7 @@ static void tpm2_flush_sessions(struct tpm_chip *chip, struct 
tpm_space *space)
for (i = 0; i < ARRAY_SIZE(space->session_tbl); i++) {
if (space->session_tbl[i])
tpm2_flush_context_cmd(chip, space->session_tbl[i],
-  TPM_TRANSMIT_UNLOCKED);
+  TPM_TRANSMIT_NESTED);
}
 }
 
@@ -84,7 +87,7 @@ static int tpm2_load_context(struct tpm_chip *chip, u8 *buf,
tpm_buf_append(, [*offset], body_size);
 
rc = tpm_transmit_cmd(chip, NULL, tbuf.data, PAGE_SIZE, 4,
- TPM_TRANSMIT_UNLOCKED, NULL);
+ TPM_TRANSMIT_NESTED, NULL);
if (rc < 0) {
dev_warn(>dev, "%s: failed with a system error %d\n",

[PATCH v3] tpm_crb: request and relinquish locality 0

[Jarkko Sakkinen]

From: Jarkko Sakkinen 

This commit adds support for requesting and relinquishing locality 0 in
tpm_crb for the course of command transmission.

In order to achieve this, two new callbacks are added to struct
tpm_class_ops:

- request_locality
- relinquish_locality

These are called before sending and receiving data from the TPM.  We
update also tpm_tis_core to use these callbacks. A small modification to
request_locality() is done so that it returns -EBUSY instead of locality
number when check_locality() fails in order to return something
meaningful to the user space.

With CRB interface you first set either requestAccess or relinquish bit
from TPM_LOC_CTRL_x register and then wait for locAssigned and
tpmRegValidSts bits to be set in the TPM_LOC_STATE_x register.

The reason why were are doing this is to make sure that the driver
will work properly with Intel TXT that uses locality 2. There's no
explicit guarantee that it would relinquish this locality. In more
general sense this commit enables tpm_crb to be a well behaving
citizen in a multi locality environment.

Signed-off-by: Jarkko Sakkinen 
---
v2:
- TPM driver level calllbacks
v3:
- Call ops->relinquish_locality only if ops->request_locality has been
  successful.
- Do not reserve locality in nested tpm_transmit calls.
- Check for tpmRegValidSts to make sure that the value in TPM_LOC_STATE_x is
  stable.
 drivers/char/tpm/tpm-interface.c | 10 ++
 drivers/char/tpm/tpm.h   |  3 ++-
 drivers/char/tpm/tpm2-space.c| 15 +--
 drivers/char/tpm/tpm_crb.c   | 41 
 drivers/char/tpm/tpm_tis_core.c  | 12 
 include/linux/tpm.h  |  3 ++-
 6 files changed, 68 insertions(+), 16 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 95c6f98..4cd216f 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -384,6 +384,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct 
tpm_space *space,
ssize_t len = 0;
u32 count, ordinal;
unsigned long stop;
+   bool no_locality = !(flags & TPM_TRANSMIT_HAS_LOCALITY);
 
if (!tpm_validate_command(chip, buf, bufsiz))
return -EINVAL;
@@ -407,6 +408,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct 
tpm_space *space,
if (chip->dev.parent)
pm_runtime_get_sync(chip->dev.parent);
 
+   if (no_locality && chip->ops->request_locality)  {
+   rc = chip->ops->request_locality(chip, 0);
+   if (rc)
+   goto out_no_locality;
+   }
+
rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
goto out;
@@ -466,6 +473,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct 
tpm_space *space,
rc = tpm2_commit_space(chip, space, ordinal, buf, );
 
 out:
+   if (no_locality && chip->ops->relinquish_locality)
+   chip->ops->relinquish_locality(chip, 0, false);
+out_no_locality:
if (chip->dev.parent)
pm_runtime_put_sync(chip->dev.parent);
 
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 5eacb3f..ba2c00d 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -521,7 +521,8 @@ extern const struct file_operations tpmrm_fops;
 extern struct idr dev_nums_idr;
 
 enum tpm_transmit_flags {
-   TPM_TRANSMIT_UNLOCKED   = BIT(0),
+   TPM_TRANSMIT_UNLOCKED   = BIT(0),
+   TPM_TRANSMIT_HAS_LOCALITY   = BIT(1),
 };
 
 ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index d36d81e..43d05ab 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -19,6 +19,9 @@
 #include 
 #include "tpm.h"
 
+#define TPM_TRANSMIT_NESTED \
+   (TPM_TRANSMIT_UNLOCKED | TPM_TRANSMIT_HAS_LOCALITY)
+
 enum tpm2_handle_types {
TPM2_HT_HMAC_SESSION= 0x0200,
TPM2_HT_POLICY_SESSION  = 0x0300,
@@ -39,7 +42,7 @@ static void tpm2_flush_sessions(struct tpm_chip *chip, struct 
tpm_space *space)
for (i = 0; i < ARRAY_SIZE(space->session_tbl); i++) {
if (space->session_tbl[i])
tpm2_flush_context_cmd(chip, space->session_tbl[i],
-  TPM_TRANSMIT_UNLOCKED);
+  TPM_TRANSMIT_NESTED);
}
 }
 
@@ -84,7 +87,7 @@ static int tpm2_load_context(struct tpm_chip *chip, u8 *buf,
tpm_buf_append(, [*offset], body_size);
 
rc = tpm_transmit_cmd(chip, NULL, tbuf.data, PAGE_SIZE, 4,
- TPM_TRANSMIT_UNLOCKED, NULL);
+ TPM_TRANSMIT_NESTED, NULL);
if (rc < 0) {
dev_warn(>dev, "%s: failed with a system error %d\n",
 __func__, rc);
@@ -132,7 +135,7 @@ static int 

[PATCH] irqchip: gic-v3-its: Don't assume GICv3 hardware supports 16bit INTID

[Shanker Donthineni]

The current ITS driver is assuming every ITS hardware implementation
supports minimum of 16bit INTID. But this is not true, as per GICv3
specification, INTID field is IMPLEMENTATION DEFINED in the range of
14-24 bits. We might see an unpredictable system behavior on systems
where hardware support less than 16bits and software tries to use
64K LPI interrupts.

On Qualcomm Datacenter Technologies QDF2400 platform, boot log shows
confusing information about number of LPI chunks as shown below. The
QDF2400 ITS hardware supports 24bit INTID.

This patch allocates the memory resources for PEND/PROP tables based
on discoverable value which is specified in GITS_TYPER.IDbits. Also
taking this opportunity to increase number of LPI/MSI(x) to 128K if
the hardware is capable, and show log message that reflects the
correct number of LPI chunks.

ITS@0xff7efe: allocated 524288 Devices @3c040 (indirect, esz 8, psz 
64K, shr 1)
ITS@0xff7efe: allocated 8192 Interrupt Collections @3c013 (flat, esz 8, 
psz 64K, shr 1)
ITS@0xff7efe: allocated 8192 Virtual CPUs @3c014 (flat, esz 8, psz 64K, 
shr 1)
ITS: Allocated 524032 chunks for LPIs
PCI/MSI: ITS@0xff7efe domain created
Platform MSI: ITS@0xff7efe domain created

Signed-off-by: Shanker Donthineni 
---
 drivers/irqchip/irq-gic-v3-its.c | 34 --
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index f77f840..0ac9f7b 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -688,9 +688,11 @@ static void its_irq_compose_msi_msg(struct irq_data *d, 
struct msi_msg *msg)
  */
 #define IRQS_PER_CHUNK_SHIFT   5
 #define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define ITS_MAX_LPI_NRBITS (17) /* 128K LPIs */
 
 static unsigned long *lpi_bitmap;
 static u32 lpi_chunks;
+static u32 lpi_nrbits;
 static DEFINE_SPINLOCK(lpi_lock);
 
 static int its_lpi_to_chunk(int lpi)
@@ -786,26 +788,19 @@ static void its_lpi_free(struct event_lpi_map *map)
 }
 
 /*
- * We allocate 64kB for PROPBASE. That gives us at most 64K LPIs to
+ * We allocate memory for PROPBASE to cover 2 ^ lpi_nrbits LPIs to
  * deal with (one configuration byte per interrupt). PENDBASE has to
  * be 64kB aligned (one bit per LPI, plus 8192 bits for SPI/PPI/SGI).
  */
-#define LPI_PROPBASE_SZSZ_64K
-#define LPI_PENDBASE_SZ(LPI_PROPBASE_SZ / 8 + SZ_1K)
-
-/*
- * This is how many bits of ID we need, including the useless ones.
- */
-#define LPI_NRBITS ilog2(LPI_PROPBASE_SZ + SZ_8K)
 
 #define LPI_PROP_DEFAULT_PRIO  0xa0
 
 static int __init its_alloc_lpi_tables(void)
 {
+   u32 size = ALIGN(BIT(lpi_nrbits), SZ_64K);
phys_addr_t paddr;
 
-   gic_rdists->prop_page = alloc_pages(GFP_NOWAIT,
-  get_order(LPI_PROPBASE_SZ));
+   gic_rdists->prop_page = alloc_pages(GFP_NOWAIT, get_order(size));
if (!gic_rdists->prop_page) {
pr_err("Failed to allocate PROPBASE\n");
return -ENOMEM;
@@ -817,10 +812,10 @@ static int __init its_alloc_lpi_tables(void)
/* Priority 0xa0, Group-1, disabled */
memset(page_address(gic_rdists->prop_page),
   LPI_PROP_DEFAULT_PRIO | LPI_PROP_GROUP1,
-  LPI_PROPBASE_SZ);
+  size);
 
/* Make sure the GIC will observe the written configuration */
-   gic_flush_dcache_to_poc(page_address(gic_rdists->prop_page), 
LPI_PROPBASE_SZ);
+   gic_flush_dcache_to_poc(page_address(gic_rdists->prop_page), size);
 
return 0;
 }
@@ -1092,12 +1087,14 @@ static void its_cpu_init_lpis(void)
pend_page = gic_data_rdist()->pend_page;
if (!pend_page) {
phys_addr_t paddr;
+   u32 size;
/*
-* The pending pages have to be at least 64kB aligned,
-* hence the 'max(LPI_PENDBASE_SZ, SZ_64K)' below.
+* The pending pages have to be at least 64kB aligned
+* hence the 'ALIGN(BIT(lpi_nrbits)/8, SZ_64K)' below.
 */
+   size = ALIGN(BIT(lpi_nrbits)/8, SZ_64K);
pend_page = alloc_pages(GFP_NOWAIT | __GFP_ZERO,
-   get_order(max(LPI_PENDBASE_SZ, 
SZ_64K)));
+   get_order(size));
if (!pend_page) {
pr_err("Failed to allocate PENDBASE for CPU%d\n",
   smp_processor_id());
@@ -1105,7 +1102,7 @@ static void its_cpu_init_lpis(void)
}
 
/* Make sure the GIC will observe the zero-ed page */
-   gic_flush_dcache_to_poc(page_address(pend_page), 
LPI_PENDBASE_SZ);
+   gic_flush_dcache_to_poc(page_address(pend_page), size);
 
paddr = page_to_phys(pend_page);
   

[PATCH] irqchip: gic-v3-its: Don't assume GICv3 hardware supports 16bit INTID

[Shanker Donthineni]

The current ITS driver is assuming every ITS hardware implementation
supports minimum of 16bit INTID. But this is not true, as per GICv3
specification, INTID field is IMPLEMENTATION DEFINED in the range of
14-24 bits. We might see an unpredictable system behavior on systems
where hardware support less than 16bits and software tries to use
64K LPI interrupts.

On Qualcomm Datacenter Technologies QDF2400 platform, boot log shows
confusing information about number of LPI chunks as shown below. The
QDF2400 ITS hardware supports 24bit INTID.

This patch allocates the memory resources for PEND/PROP tables based
on discoverable value which is specified in GITS_TYPER.IDbits. Also
taking this opportunity to increase number of LPI/MSI(x) to 128K if
the hardware is capable, and show log message that reflects the
correct number of LPI chunks.

ITS@0xff7efe: allocated 524288 Devices @3c040 (indirect, esz 8, psz 
64K, shr 1)
ITS@0xff7efe: allocated 8192 Interrupt Collections @3c013 (flat, esz 8, 
psz 64K, shr 1)
ITS@0xff7efe: allocated 8192 Virtual CPUs @3c014 (flat, esz 8, psz 64K, 
shr 1)
ITS: Allocated 524032 chunks for LPIs
PCI/MSI: ITS@0xff7efe domain created
Platform MSI: ITS@0xff7efe domain created

Signed-off-by: Shanker Donthineni 
---
 drivers/irqchip/irq-gic-v3-its.c | 34 --
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index f77f840..0ac9f7b 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -688,9 +688,11 @@ static void its_irq_compose_msi_msg(struct irq_data *d, 
struct msi_msg *msg)
  */
 #define IRQS_PER_CHUNK_SHIFT   5
 #define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define ITS_MAX_LPI_NRBITS (17) /* 128K LPIs */
 
 static unsigned long *lpi_bitmap;
 static u32 lpi_chunks;
+static u32 lpi_nrbits;
 static DEFINE_SPINLOCK(lpi_lock);
 
 static int its_lpi_to_chunk(int lpi)
@@ -786,26 +788,19 @@ static void its_lpi_free(struct event_lpi_map *map)
 }
 
 /*
- * We allocate 64kB for PROPBASE. That gives us at most 64K LPIs to
+ * We allocate memory for PROPBASE to cover 2 ^ lpi_nrbits LPIs to
  * deal with (one configuration byte per interrupt). PENDBASE has to
  * be 64kB aligned (one bit per LPI, plus 8192 bits for SPI/PPI/SGI).
  */
-#define LPI_PROPBASE_SZSZ_64K
-#define LPI_PENDBASE_SZ(LPI_PROPBASE_SZ / 8 + SZ_1K)
-
-/*
- * This is how many bits of ID we need, including the useless ones.
- */
-#define LPI_NRBITS ilog2(LPI_PROPBASE_SZ + SZ_8K)
 
 #define LPI_PROP_DEFAULT_PRIO  0xa0
 
 static int __init its_alloc_lpi_tables(void)
 {
+   u32 size = ALIGN(BIT(lpi_nrbits), SZ_64K);
phys_addr_t paddr;
 
-   gic_rdists->prop_page = alloc_pages(GFP_NOWAIT,
-  get_order(LPI_PROPBASE_SZ));
+   gic_rdists->prop_page = alloc_pages(GFP_NOWAIT, get_order(size));
if (!gic_rdists->prop_page) {
pr_err("Failed to allocate PROPBASE\n");
return -ENOMEM;
@@ -817,10 +812,10 @@ static int __init its_alloc_lpi_tables(void)
/* Priority 0xa0, Group-1, disabled */
memset(page_address(gic_rdists->prop_page),
   LPI_PROP_DEFAULT_PRIO | LPI_PROP_GROUP1,
-  LPI_PROPBASE_SZ);
+  size);
 
/* Make sure the GIC will observe the written configuration */
-   gic_flush_dcache_to_poc(page_address(gic_rdists->prop_page), 
LPI_PROPBASE_SZ);
+   gic_flush_dcache_to_poc(page_address(gic_rdists->prop_page), size);
 
return 0;
 }
@@ -1092,12 +1087,14 @@ static void its_cpu_init_lpis(void)
pend_page = gic_data_rdist()->pend_page;
if (!pend_page) {
phys_addr_t paddr;
+   u32 size;
/*
-* The pending pages have to be at least 64kB aligned,
-* hence the 'max(LPI_PENDBASE_SZ, SZ_64K)' below.
+* The pending pages have to be at least 64kB aligned
+* hence the 'ALIGN(BIT(lpi_nrbits)/8, SZ_64K)' below.
 */
+   size = ALIGN(BIT(lpi_nrbits)/8, SZ_64K);
pend_page = alloc_pages(GFP_NOWAIT | __GFP_ZERO,
-   get_order(max(LPI_PENDBASE_SZ, 
SZ_64K)));
+   get_order(size));
if (!pend_page) {
pr_err("Failed to allocate PENDBASE for CPU%d\n",
   smp_processor_id());
@@ -1105,7 +1102,7 @@ static void its_cpu_init_lpis(void)
}
 
/* Make sure the GIC will observe the zero-ed page */
-   gic_flush_dcache_to_poc(page_address(pend_page), 
LPI_PENDBASE_SZ);
+   gic_flush_dcache_to_poc(page_address(pend_page), size);
 
paddr = page_to_phys(pend_page);
pr_info("CPU%d: 

ATENCIÓN;

[administrador]

ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por 
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser 
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su
buzón de correo electrónico. Para revalidar su buzón de correo, envíe la 
siguiente información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017

¡gracias
Sistemas administrador 

ATENCIÓN;

[administrador]

ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por 
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser 
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su
buzón de correo electrónico. Para revalidar su buzón de correo, envíe la 
siguiente información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017

¡gracias
Sistemas administrador 

man-pages-4.10 is released

[Michael Kerrisk (man-pages)]

The Linux man-pages maintainer proudly announces:

man-pages-4.10 - man pages for Linux

This release resulted from patches, bug reports, reviews, and comments
from over 40 contributors. The release sees a large number of changes:
over 600 commits changing around 160 pages. The changes include the
addition of 11 pages, significant rewrites of 3 other pages, and
enhancements to many other pages.

Tarball download:
http://www.kernel.org/doc/man-pages/download.html
Git repository:
https://git.kernel.org/cgit/docs/man-pages/man-pages.git/
Online changelog:
http://man7.org/linux/man-pages/changelog.html#release_4.10

A short summary of the release is blogged at:
http://linux-man-pages.blogspot.com/2017/03/man-pages-410-is-released.html

The current version of the pages is browsable at:
http://man7.org/linux/man-pages/

A selection of changes in this release that may be of interest
to readers on LKML is shown below.

Cheers,

Michael

 Changes in man-pages-4.10 


New and rewritten pages
---

add_key.2
Michael Kerrisk  [Eugene Syromyatnikov, David Howells]
Major improvements and additions
The page has doubled in length.

ioctl_iflags.2
Michael Kerrisk
New page describing inode flags and ioctl() operations

ioctl_ns.2
Michael Kerrisk
New page created by splitting ioctl(2) operations out of namespaces(7)

keyctl.2
Michael Kerrisk, Eugene Syromyatnikov  [David Howells, Mat Martineau]
 A vast number of additions and improvements
 The page has gone from somewhat over 100 lines to well over
 1000 lines and now more or less documents the complete interface
 provided by this system call.

getentropy.3
Michael Kerrisk
New page documenting getentropy(3)
getentropy(3) is added to glibc in version 2.25.

keyrings.7
David Howells
New page (written by David Howells) adopted from keyutils
Michael Kerrisk  [Eugene Syromyatnikov, David Howells]
Very many additions and improvements

persistent-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Since this page documents kernel-user-space interfaces,
it makes sense to have it as part of man-pages, rather
than the keyutils package.
Michael Kerrisk
Various clean-ups and additions

process-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Since this page documents kernel-user-space interfaces,
it makes sense to have it as part of man-pages, rather
than the keyutils package.
Michael Kerrisk
Various additions and improvements

request_key.2
Michael Kerrisk, Eugene Syromyatnikov  [David Howells]
Very many additions and improvements
 The page is now three times its former length.

session-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various reworking and additions

signal-safety.7
Michael Kerrisk
New page created by migrating the signal-safety discussion from
signal(7). Along the way some more details got added.
Michael Kerrisk  [KASAKI Motohiro]
Note async-signal-safety problems caused by pthread_atfork()
See https://bugzilla.kernel.org/show_bug.cgi?id=25292
Michael Kerrisk  [KASAKI Motohiro]
Note glibc deviations from POSIX requirements
See https://bugzilla.kernel.org/show_bug.cgi?id=25292

thread-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various rewordings and additions

user-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various reworking and improvements

user-session-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various rewordings and additions


Newly documented interfaces in existing pages
-

bzero.3
Michael Kerrisk
Document explicit_bzero() (new in glibc 2.25)
Also, reword the description of bzero somewhat.

proc.5
Michael Kerrisk
Document /proc/sys/vm/user_reserve_kbytes
Michael Kerrisk
Document /proc/sys/vm/admin_reserve_kbytes
Michael Kerrisk
Document /proc/sys/fs/mount-max
Michael Kerrisk
Document /proc/PID/status 'NoNewPrivs' field


Changes to individual pages
---

clone.2
Michael Kerrisk
clone() does not execute fork handlers

execve.2
Michael Kerrisk
File capabilities can be ignored for the same reasons as set-UID/set-GID
Michael Kerrisk
The 'no_new_privs' bit inhibits transformations of the 

man-pages-4.10 is released

[Michael Kerrisk (man-pages)]

The Linux man-pages maintainer proudly announces:

man-pages-4.10 - man pages for Linux

This release resulted from patches, bug reports, reviews, and comments
from over 40 contributors. The release sees a large number of changes:
over 600 commits changing around 160 pages. The changes include the
addition of 11 pages, significant rewrites of 3 other pages, and
enhancements to many other pages.

Tarball download:
http://www.kernel.org/doc/man-pages/download.html
Git repository:
https://git.kernel.org/cgit/docs/man-pages/man-pages.git/
Online changelog:
http://man7.org/linux/man-pages/changelog.html#release_4.10

A short summary of the release is blogged at:
http://linux-man-pages.blogspot.com/2017/03/man-pages-410-is-released.html

The current version of the pages is browsable at:
http://man7.org/linux/man-pages/

A selection of changes in this release that may be of interest
to readers on LKML is shown below.

Cheers,

Michael

 Changes in man-pages-4.10 


New and rewritten pages
---

add_key.2
Michael Kerrisk  [Eugene Syromyatnikov, David Howells]
Major improvements and additions
The page has doubled in length.

ioctl_iflags.2
Michael Kerrisk
New page describing inode flags and ioctl() operations

ioctl_ns.2
Michael Kerrisk
New page created by splitting ioctl(2) operations out of namespaces(7)

keyctl.2
Michael Kerrisk, Eugene Syromyatnikov  [David Howells, Mat Martineau]
 A vast number of additions and improvements
 The page has gone from somewhat over 100 lines to well over
 1000 lines and now more or less documents the complete interface
 provided by this system call.

getentropy.3
Michael Kerrisk
New page documenting getentropy(3)
getentropy(3) is added to glibc in version 2.25.

keyrings.7
David Howells
New page (written by David Howells) adopted from keyutils
Michael Kerrisk  [Eugene Syromyatnikov, David Howells]
Very many additions and improvements

persistent-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Since this page documents kernel-user-space interfaces,
it makes sense to have it as part of man-pages, rather
than the keyutils package.
Michael Kerrisk
Various clean-ups and additions

process-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Since this page documents kernel-user-space interfaces,
it makes sense to have it as part of man-pages, rather
than the keyutils package.
Michael Kerrisk
Various additions and improvements

request_key.2
Michael Kerrisk, Eugene Syromyatnikov  [David Howells]
Very many additions and improvements
 The page is now three times its former length.

session-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various reworking and additions

signal-safety.7
Michael Kerrisk
New page created by migrating the signal-safety discussion from
signal(7). Along the way some more details got added.
Michael Kerrisk  [KASAKI Motohiro]
Note async-signal-safety problems caused by pthread_atfork()
See https://bugzilla.kernel.org/show_bug.cgi?id=25292
Michael Kerrisk  [KASAKI Motohiro]
Note glibc deviations from POSIX requirements
See https://bugzilla.kernel.org/show_bug.cgi?id=25292

thread-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various rewordings and additions

user-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various reworking and improvements

user-session-keyring.7
Michael Kerrisk
New page (written by David Howells) adopted from keyutils
Michael Kerrisk
Various rewordings and additions


Newly documented interfaces in existing pages
-

bzero.3
Michael Kerrisk
Document explicit_bzero() (new in glibc 2.25)
Also, reword the description of bzero somewhat.

proc.5
Michael Kerrisk
Document /proc/sys/vm/user_reserve_kbytes
Michael Kerrisk
Document /proc/sys/vm/admin_reserve_kbytes
Michael Kerrisk
Document /proc/sys/fs/mount-max
Michael Kerrisk
Document /proc/PID/status 'NoNewPrivs' field


Changes to individual pages
---

clone.2
Michael Kerrisk
clone() does not execute fork handlers

execve.2
Michael Kerrisk
File capabilities can be ignored for the same reasons as set-UID/set-GID
Michael Kerrisk
The 'no_new_privs' bit inhibits transformations of the 

Re: [PATCH] drivers/pcmcia: NO_IRQ removal for electra_cf.c

[Michael Ellerman]

Arnd Bergmann  writes:

> On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman  
> wrote:
>> Michael Ellerman  writes:
>>
>>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it
>>> from electra_cf.c which is a powerpc-only driver.
>>>
>>> Signed-off-by: Michael Ellerman 
>>> ---
>>>  drivers/pcmcia/electra_cf.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Ping anyone?
>>
>> Or should I merge this via the powerpc tree?
>
> That's what I would recommend for a powerpc specific pcmcia driver, yes.

Suits me.

> Looking at the bigger picture of powerpc drivers using NO_IRQ, I also
> see these others:
>
> drivers/ata/pata_mpc52xx.c: if (ata_irq == NO_IRQ) {
> drivers/ata/sata_dwc_460ex.c:#ifndef NO_IRQ
> drivers/ata/sata_dwc_460ex.c:#define NO_IRQ 0
> drivers/ata/sata_dwc_460ex.c:   if (hsdev->dma->irq == NO_IRQ) {
> drivers/ata/sata_dwc_460ex.c:   if (irq == NO_IRQ) {
> drivers/iommu/fsl_pamu.c:   if (irq == NO_IRQ) {
> drivers/iommu/fsl_pamu.c:   if (irq != NO_IRQ)
> drivers/media/platform/fsl-viu.c:   if (viu_irq == NO_IRQ) {
> drivers/mtd/nand/mpc5121_nfc.c: if (prv->irq == NO_IRQ) {
> drivers/pcmcia/electra_cf.c:cf->irq = NO_IRQ;
> drivers/pcmcia/electra_cf.c:if (cf->irq != NO_IRQ)
> drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
> no interrupt is pending. */
> drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
> drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
> no interrupt is pending. */
> drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
> drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_low == NO_IRQ) {
> drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_high != NO_IRQ &&
> drivers/spi/spi-mpc52xx.c:  if (status && (irq != NO_IRQ))
> drivers/tty/ehv_bytechan.c: if (stdout_irq == NO_IRQ) {
> drivers/tty/ehv_bytechan.c: if ((bc->rx_irq == NO_IRQ) ||
> (bc->tx_irq == NO_IRQ)) {
> drivers/tty/serial/cpm_uart/cpm_uart_core.c:if (pinfo->port.irq == 
> NO_IRQ) {
> drivers/uio/uio_fsl_elbc_gpcm.c:if (irq != NO_IRQ) {
> drivers/uio/uio_fsl_elbc_gpcm.c:irq = NO_IRQ;
> drivers/uio/uio_fsl_elbc_gpcm.c: irq != NO_IRQ ? irq : -1);
> drivers/usb/host/ehci-grlib.c:  if (irq == NO_IRQ) {
> drivers/usb/host/ehci-ppc-of.c: if (irq == NO_IRQ) {
> drivers/usb/host/fhci-hcd.c:if (usb_irq == NO_IRQ) {
> drivers/usb/host/ohci-ppc-of.c: if (irq == NO_IRQ) {
> drivers/usb/host/uhci-grlib.c:  if (irq == NO_IRQ) {
> drivers/video/fbdev/mb862xx/mb862xxfbdrv.c: if (par->irq == NO_IRQ) {
> drivers/virt/fsl_hypervisor.c:  if (!handle || (irq == NO_IRQ)) {
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq == NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
>
> Did you have other pending patches for those?

No. I stayed away from anything FSL related as I was under the
impression some of them were being ported to arch/arm, which uses -1 for
NO_IRQ IIUIC.

eg. all of include/soc/fsl and drivers/soc/fsl was moved from
arch/powerpc in commit 7aa1aa6ecec2, which said:

QE: Move QE from arch/powerpc to drivers/soc

ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm

But looking at the Kconfigs it looks like they're still only selectable
on PPC. So that's a bit annoying.

I'll do patches for everything above that's not drivers/soc or
include/soc and hopefully we can hear from someone at NXP on the plans
for getting the soc parts enabled on arm.

cheers

Re: [PATCH] drivers/pcmcia: NO_IRQ removal for electra_cf.c

[Michael Ellerman]

Arnd Bergmann  writes:

> On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman  
> wrote:
>> Michael Ellerman  writes:
>>
>>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it
>>> from electra_cf.c which is a powerpc-only driver.
>>>
>>> Signed-off-by: Michael Ellerman 
>>> ---
>>>  drivers/pcmcia/electra_cf.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Ping anyone?
>>
>> Or should I merge this via the powerpc tree?
>
> That's what I would recommend for a powerpc specific pcmcia driver, yes.

Suits me.

> Looking at the bigger picture of powerpc drivers using NO_IRQ, I also
> see these others:
>
> drivers/ata/pata_mpc52xx.c: if (ata_irq == NO_IRQ) {
> drivers/ata/sata_dwc_460ex.c:#ifndef NO_IRQ
> drivers/ata/sata_dwc_460ex.c:#define NO_IRQ 0
> drivers/ata/sata_dwc_460ex.c:   if (hsdev->dma->irq == NO_IRQ) {
> drivers/ata/sata_dwc_460ex.c:   if (irq == NO_IRQ) {
> drivers/iommu/fsl_pamu.c:   if (irq == NO_IRQ) {
> drivers/iommu/fsl_pamu.c:   if (irq != NO_IRQ)
> drivers/media/platform/fsl-viu.c:   if (viu_irq == NO_IRQ) {
> drivers/mtd/nand/mpc5121_nfc.c: if (prv->irq == NO_IRQ) {
> drivers/pcmcia/electra_cf.c:cf->irq = NO_IRQ;
> drivers/pcmcia/electra_cf.c:if (cf->irq != NO_IRQ)
> drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
> no interrupt is pending. */
> drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
> drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
> no interrupt is pending. */
> drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
> drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_low == NO_IRQ) {
> drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_high != NO_IRQ &&
> drivers/spi/spi-mpc52xx.c:  if (status && (irq != NO_IRQ))
> drivers/tty/ehv_bytechan.c: if (stdout_irq == NO_IRQ) {
> drivers/tty/ehv_bytechan.c: if ((bc->rx_irq == NO_IRQ) ||
> (bc->tx_irq == NO_IRQ)) {
> drivers/tty/serial/cpm_uart/cpm_uart_core.c:if (pinfo->port.irq == 
> NO_IRQ) {
> drivers/uio/uio_fsl_elbc_gpcm.c:if (irq != NO_IRQ) {
> drivers/uio/uio_fsl_elbc_gpcm.c:irq = NO_IRQ;
> drivers/uio/uio_fsl_elbc_gpcm.c: irq != NO_IRQ ? irq : -1);
> drivers/usb/host/ehci-grlib.c:  if (irq == NO_IRQ) {
> drivers/usb/host/ehci-ppc-of.c: if (irq == NO_IRQ) {
> drivers/usb/host/fhci-hcd.c:if (usb_irq == NO_IRQ) {
> drivers/usb/host/ohci-ppc-of.c: if (irq == NO_IRQ) {
> drivers/usb/host/uhci-grlib.c:  if (irq == NO_IRQ) {
> drivers/video/fbdev/mb862xx/mb862xxfbdrv.c: if (par->irq == NO_IRQ) {
> drivers/virt/fsl_hypervisor.c:  if (!handle || (irq == NO_IRQ)) {
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq == NO_IRQ)
> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
>
> Did you have other pending patches for those?

No. I stayed away from anything FSL related as I was under the
impression some of them were being ported to arch/arm, which uses -1 for
NO_IRQ IIUIC.

eg. all of include/soc/fsl and drivers/soc/fsl was moved from
arch/powerpc in commit 7aa1aa6ecec2, which said:

QE: Move QE from arch/powerpc to drivers/soc

ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm

But looking at the Kconfigs it looks like they're still only selectable
on PPC. So that's a bit annoying.

I'll do patches for everything above that's not drivers/soc or
include/soc and hopefully we can hear from someone at NXP on the plans
for getting the soc parts enabled on arm.

cheers

Re: [PATCH] iio: 104-quad-8: Fix off-by-one error when addressing flag register

[Greg KH]

On Tue, Mar 14, 2017 at 11:00:43AM -0400, William Breathitt Gray wrote:
> On Mon, Mar 13, 2017 at 09:33:45PM +, Jonathan Cameron wrote:
> >On 13/03/17 13:33, William Breathitt Gray wrote:
> >> On Sat, Feb 11, 2017 at 09:37:35AM +, Jonathan Cameron wrote:
> >>> On 09/02/17 15:03, William Breathitt Gray wrote:
>  The flag register is offset by 1 from the respective channel data
>  register. This patch fixes an off-by-one error when attempting to read a
>  channel flag register where the base address was not properly offset.
> 
>  Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 
>  104-QUAD-8")
>  Signed-off-by: William Breathitt Gray 
> >>> Applied to the fixes-togreg-post-rc1 branch of iio.git
> >>> Clue to when this will go upstream is in the name ;)
> >>>
> >>> Thanks,
> >>>
> >>> Jonathan
> >> 
> >> Hi Jonathan,
> >> 
> >> I see that this fix made it into 4.11-rc1 but not the 4.10.2 release.
> >> Is this patch on track to appear in stable, or should I explicitly CC
> >> sta...@vger.kernel.org to pick this up?
> >I was half asleep and failed to tag this in the first place.
> >
> >Send an email to sta...@vger.kernel.org with the commit ID and a request
> >that it is picked up.  Cc me.
> >
> >Jonathan
> >> 
> >> Thanks,
> >> 
> >> William Breathitt Gray
> >> 
> 
> Hello,
> 
> This patch was merged into Linus' tree as commit ca8d8e03b4c9 ("iio:
> 104-quad-8: Fix off-by-one error when addressing flag register"). This
> fix should be merged into the 4.10 stable tree as well to fix an
> off-by-one error which causes garbage data to be read as count values --
> effectively preventing proper usage of the driver.
> 
> This patch fixes commit 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support
> for the ACCES 104-QUAD-8").

Now queued up, thanks.

greg k-h

Re: [PATCH] iio: 104-quad-8: Fix off-by-one error when addressing flag register

[Greg KH]

On Tue, Mar 14, 2017 at 11:00:43AM -0400, William Breathitt Gray wrote:
> On Mon, Mar 13, 2017 at 09:33:45PM +, Jonathan Cameron wrote:
> >On 13/03/17 13:33, William Breathitt Gray wrote:
> >> On Sat, Feb 11, 2017 at 09:37:35AM +, Jonathan Cameron wrote:
> >>> On 09/02/17 15:03, William Breathitt Gray wrote:
>  The flag register is offset by 1 from the respective channel data
>  register. This patch fixes an off-by-one error when attempting to read a
>  channel flag register where the base address was not properly offset.
> 
>  Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 
>  104-QUAD-8")
>  Signed-off-by: William Breathitt Gray 
> >>> Applied to the fixes-togreg-post-rc1 branch of iio.git
> >>> Clue to when this will go upstream is in the name ;)
> >>>
> >>> Thanks,
> >>>
> >>> Jonathan
> >> 
> >> Hi Jonathan,
> >> 
> >> I see that this fix made it into 4.11-rc1 but not the 4.10.2 release.
> >> Is this patch on track to appear in stable, or should I explicitly CC
> >> sta...@vger.kernel.org to pick this up?
> >I was half asleep and failed to tag this in the first place.
> >
> >Send an email to sta...@vger.kernel.org with the commit ID and a request
> >that it is picked up.  Cc me.
> >
> >Jonathan
> >> 
> >> Thanks,
> >> 
> >> William Breathitt Gray
> >> 
> 
> Hello,
> 
> This patch was merged into Linus' tree as commit ca8d8e03b4c9 ("iio:
> 104-quad-8: Fix off-by-one error when addressing flag register"). This
> fix should be merged into the 4.10 stable tree as well to fix an
> off-by-one error which causes garbage data to be read as count values --
> effectively preventing proper usage of the driver.
> 
> This patch fixes commit 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support
> for the ACCES 104-QUAD-8").

Now queued up, thanks.

greg k-h

[PATCH v2] vTPM: Fix missing NULL check

[Hon Ching(Vicky) Lo]

The current code passes the address of tpm_chip as the argument to
dev_get_drvdata() without prior NULL check in
tpm_ibmvtpm_get_desired_dma.  This resulted an oops during kernel
boot when vTPM is enabled in Power partition configured in active
memory sharing mode.

The vio_driver's get_desired_dma() is called before the probe(), which
for vtpm is tpm_ibmvtpm_probe, and it's this latter function that
initializes the driver and set data.  Attempting to get data before
the probe() caused the problem.

This patch adds a NULL check to the tpm_ibmvtpm_get_desired_dma.

fixes: 9e0d39d8a6a0 ("tpm: Remove useless priv field in struct 
tpm_vendor_specific")
Cc: 
Signed-off-by: Hon Ching(Vicky) Lo 
---
 drivers/char/tpm/tpm_ibmvtpm.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 1b9d61f..f01d083 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -299,6 +299,8 @@ static int tpm_ibmvtpm_remove(struct vio_dev *vdev)
}
 
kfree(ibmvtpm);
+   /* For tpm_ibmvtpm_get_desired_dma */
+   dev_set_drvdata(>dev, NULL);
 
return 0;
 }
@@ -313,14 +315,16 @@ static int tpm_ibmvtpm_remove(struct vio_dev *vdev)
 static unsigned long tpm_ibmvtpm_get_desired_dma(struct vio_dev *vdev)
 {
struct tpm_chip *chip = dev_get_drvdata(>dev);
-   struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(>dev);
+   struct ibmvtpm_dev *ibmvtpm;
 
/*
 * ibmvtpm initializes at probe time, so the data we are
 * asking for may not be set yet. Estimate that 4K required
 * for TCE-mapped buffer in addition to CRQ.
 */
-   if (!ibmvtpm)
+   if (chip)
+   ibmvtpm = dev_get_drvdata(>dev);
+   else
return CRQ_RES_BUF_SIZE + PAGE_SIZE;
 
return CRQ_RES_BUF_SIZE + ibmvtpm->rtce_size;
-- 
1.7.1

[PATCH v2] vTPM: Fix missing NULL check

[Hon Ching(Vicky) Lo]

The current code passes the address of tpm_chip as the argument to
dev_get_drvdata() without prior NULL check in
tpm_ibmvtpm_get_desired_dma.  This resulted an oops during kernel
boot when vTPM is enabled in Power partition configured in active
memory sharing mode.

The vio_driver's get_desired_dma() is called before the probe(), which
for vtpm is tpm_ibmvtpm_probe, and it's this latter function that
initializes the driver and set data.  Attempting to get data before
the probe() caused the problem.

This patch adds a NULL check to the tpm_ibmvtpm_get_desired_dma.

fixes: 9e0d39d8a6a0 ("tpm: Remove useless priv field in struct 
tpm_vendor_specific")
Cc: 
Signed-off-by: Hon Ching(Vicky) Lo 
---
 drivers/char/tpm/tpm_ibmvtpm.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 1b9d61f..f01d083 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -299,6 +299,8 @@ static int tpm_ibmvtpm_remove(struct vio_dev *vdev)
}
 
kfree(ibmvtpm);
+   /* For tpm_ibmvtpm_get_desired_dma */
+   dev_set_drvdata(>dev, NULL);
 
return 0;
 }
@@ -313,14 +315,16 @@ static int tpm_ibmvtpm_remove(struct vio_dev *vdev)
 static unsigned long tpm_ibmvtpm_get_desired_dma(struct vio_dev *vdev)
 {
struct tpm_chip *chip = dev_get_drvdata(>dev);
-   struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(>dev);
+   struct ibmvtpm_dev *ibmvtpm;
 
/*
 * ibmvtpm initializes at probe time, so the data we are
 * asking for may not be set yet. Estimate that 4K required
 * for TCE-mapped buffer in addition to CRQ.
 */
-   if (!ibmvtpm)
+   if (chip)
+   ibmvtpm = dev_get_drvdata(>dev);
+   else
return CRQ_RES_BUF_SIZE + PAGE_SIZE;
 
return CRQ_RES_BUF_SIZE + ibmvtpm->rtce_size;
-- 
1.7.1

[PATCH v2 06/10] mm: remove SWAP_AGAIN in ttu

[Minchan Kim]

In 2002, [1] introduced SWAP_AGAIN.
At that time, try_to_unmap_one used spin_trylock(>page_table_lock)
so it's really easy to contend and fail to hold a lock so SWAP_AGAIN
to keep LRU status makes sense.

However, now we changed it to mutex-based lock and be able to block
without skip pte so there is few of small window to return SWAP_AGAIN
so remove SWAP_AGAIN and just return SWAP_FAIL.

[1] c48c43e, minimal rmap
Signed-off-by: Minchan Kim 
---
 mm/rmap.c   | 11 +++
 mm/vmscan.c |  2 --
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index a5af1e1..612682c 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1499,13 +1499,10 @@ static int page_mapcount_is_zero(struct page *page)
  * Return values are:
  *
  * SWAP_SUCCESS- we succeeded in removing all mappings
- * SWAP_AGAIN  - we missed a mapping, try again later
  * SWAP_FAIL   - the page is unswappable
  */
 int try_to_unmap(struct page *page, enum ttu_flags flags)
 {
-   int ret;
-
struct rmap_walk_control rwc = {
.rmap_one = try_to_unmap_one,
.arg = (void *)flags,
@@ -1525,13 +1522,11 @@ int try_to_unmap(struct page *page, enum ttu_flags 
flags)
rwc.invalid_vma = invalid_migration_vma;
 
if (flags & TTU_RMAP_LOCKED)
-   ret = rmap_walk_locked(page, );
+   rmap_walk_locked(page, );
else
-   ret = rmap_walk(page, );
+   rmap_walk(page, );
 
-   if (!page_mapcount(page))
-   ret = SWAP_SUCCESS;
-   return ret;
+   return !page_mapcount(page) ? SWAP_SUCCESS : SWAP_FAIL;
 }
 
 static int page_not_mapped(struct page *page)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2a208f0..7727fbe 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1145,8 +1145,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
case SWAP_FAIL:
nr_unmap_fail++;
goto activate_locked;
-   case SWAP_AGAIN:
-   goto keep_locked;
case SWAP_SUCCESS:
; /* try to free the page below */
}
-- 
2.7.4

[PATCH v2 06/10] mm: remove SWAP_AGAIN in ttu

[Minchan Kim]

In 2002, [1] introduced SWAP_AGAIN.
At that time, try_to_unmap_one used spin_trylock(>page_table_lock)
so it's really easy to contend and fail to hold a lock so SWAP_AGAIN
to keep LRU status makes sense.

However, now we changed it to mutex-based lock and be able to block
without skip pte so there is few of small window to return SWAP_AGAIN
so remove SWAP_AGAIN and just return SWAP_FAIL.

[1] c48c43e, minimal rmap
Signed-off-by: Minchan Kim 
---
 mm/rmap.c   | 11 +++
 mm/vmscan.c |  2 --
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index a5af1e1..612682c 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1499,13 +1499,10 @@ static int page_mapcount_is_zero(struct page *page)
  * Return values are:
  *
  * SWAP_SUCCESS- we succeeded in removing all mappings
- * SWAP_AGAIN  - we missed a mapping, try again later
  * SWAP_FAIL   - the page is unswappable
  */
 int try_to_unmap(struct page *page, enum ttu_flags flags)
 {
-   int ret;
-
struct rmap_walk_control rwc = {
.rmap_one = try_to_unmap_one,
.arg = (void *)flags,
@@ -1525,13 +1522,11 @@ int try_to_unmap(struct page *page, enum ttu_flags 
flags)
rwc.invalid_vma = invalid_migration_vma;
 
if (flags & TTU_RMAP_LOCKED)
-   ret = rmap_walk_locked(page, );
+   rmap_walk_locked(page, );
else
-   ret = rmap_walk(page, );
+   rmap_walk(page, );
 
-   if (!page_mapcount(page))
-   ret = SWAP_SUCCESS;
-   return ret;
+   return !page_mapcount(page) ? SWAP_SUCCESS : SWAP_FAIL;
 }
 
 static int page_not_mapped(struct page *page)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2a208f0..7727fbe 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1145,8 +1145,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
case SWAP_FAIL:
nr_unmap_fail++;
goto activate_locked;
-   case SWAP_AGAIN:
-   goto keep_locked;
case SWAP_SUCCESS:
; /* try to free the page below */
}
-- 
2.7.4

[PATCH v2 04/10] mm: make the try_to_munlock void function

[Minchan Kim]

try_to_munlock returns SWAP_MLOCK if the one of VMAs mapped
the page has VM_LOCKED flag. In that time, VM set PG_mlocked to
the page if the page is not pte-mapped THP which cannot be
mlocked, either.

With that, __munlock_isolated_page can use PageMlocked to check
whether try_to_munlock is successful or not without relying on
try_to_munlock's retval. It helps to make try_to_unmap/try_to_unmap_one
simple with upcoming patches.

Cc: Vlastimil Babka 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  2 +-
 mm/mlock.c   |  6 ++
 mm/rmap.c| 17 +
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index b556eef..1b0cd4c 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -235,7 +235,7 @@ int page_mkclean(struct page *);
  * called in munlock()/munmap() path to check for other vmas holding
  * the page mlocked.
  */
-int try_to_munlock(struct page *);
+void try_to_munlock(struct page *);
 
 void remove_migration_ptes(struct page *old, struct page *new, bool locked);
 
diff --git a/mm/mlock.c b/mm/mlock.c
index 02f1382..9660ee5 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -123,17 +123,15 @@ static bool __munlock_isolate_lru_page(struct page *page, 
bool getpage)
  */
 static void __munlock_isolated_page(struct page *page)
 {
-   int ret = SWAP_AGAIN;
-
/*
 * Optimization: if the page was mapped just once, that's our mapping
 * and we don't need to check all the other vmas.
 */
if (page_mapcount(page) > 1)
-   ret = try_to_munlock(page);
+   try_to_munlock(page);
 
/* Did try_to_unlock() succeed or punt? */
-   if (ret != SWAP_MLOCK)
+   if (!PageMlocked(page))
count_vm_event(UNEVICTABLE_PGMUNLOCKED);
 
putback_lru_page(page);
diff --git a/mm/rmap.c b/mm/rmap.c
index bdc7310..2f1fbd9 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1547,18 +1547,10 @@ static int page_not_mapped(struct page *page)
  * Called from munlock code.  Checks all of the VMAs mapping the page
  * to make sure nobody else has this page mlocked. The page will be
  * returned with PG_mlocked cleared if no other vmas have it mlocked.
- *
- * Return values are:
- *
- * SWAP_AGAIN  - no vma is holding page mlocked, or,
- * SWAP_AGAIN  - page mapped in mlocked vma -- couldn't acquire mmap sem
- * SWAP_FAIL   - page cannot be located at present
- * SWAP_MLOCK  - page is now mlocked.
  */
-int try_to_munlock(struct page *page)
-{
-   int ret;
 
+void try_to_munlock(struct page *page)
+{
struct rmap_walk_control rwc = {
.rmap_one = try_to_unmap_one,
.arg = (void *)TTU_MUNLOCK,
@@ -1568,9 +1560,10 @@ int try_to_munlock(struct page *page)
};
 
VM_BUG_ON_PAGE(!PageLocked(page) || PageLRU(page), page);
+   VM_BUG_ON_PAGE(PageMlocked(page), page);
+   VM_BUG_ON_PAGE(PageCompound(page) && PageDoubleMap(page), page);
 
-   ret = rmap_walk(page, );
-   return ret;
+   rmap_walk(page, );
 }
 
 void __put_anon_vma(struct anon_vma *anon_vma)
-- 
2.7.4

[PATCH v2 04/10] mm: make the try_to_munlock void function

[Minchan Kim]

try_to_munlock returns SWAP_MLOCK if the one of VMAs mapped
the page has VM_LOCKED flag. In that time, VM set PG_mlocked to
the page if the page is not pte-mapped THP which cannot be
mlocked, either.

With that, __munlock_isolated_page can use PageMlocked to check
whether try_to_munlock is successful or not without relying on
try_to_munlock's retval. It helps to make try_to_unmap/try_to_unmap_one
simple with upcoming patches.

Cc: Vlastimil Babka 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  2 +-
 mm/mlock.c   |  6 ++
 mm/rmap.c| 17 +
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index b556eef..1b0cd4c 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -235,7 +235,7 @@ int page_mkclean(struct page *);
  * called in munlock()/munmap() path to check for other vmas holding
  * the page mlocked.
  */
-int try_to_munlock(struct page *);
+void try_to_munlock(struct page *);
 
 void remove_migration_ptes(struct page *old, struct page *new, bool locked);
 
diff --git a/mm/mlock.c b/mm/mlock.c
index 02f1382..9660ee5 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -123,17 +123,15 @@ static bool __munlock_isolate_lru_page(struct page *page, 
bool getpage)
  */
 static void __munlock_isolated_page(struct page *page)
 {
-   int ret = SWAP_AGAIN;
-
/*
 * Optimization: if the page was mapped just once, that's our mapping
 * and we don't need to check all the other vmas.
 */
if (page_mapcount(page) > 1)
-   ret = try_to_munlock(page);
+   try_to_munlock(page);
 
/* Did try_to_unlock() succeed or punt? */
-   if (ret != SWAP_MLOCK)
+   if (!PageMlocked(page))
count_vm_event(UNEVICTABLE_PGMUNLOCKED);
 
putback_lru_page(page);
diff --git a/mm/rmap.c b/mm/rmap.c
index bdc7310..2f1fbd9 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1547,18 +1547,10 @@ static int page_not_mapped(struct page *page)
  * Called from munlock code.  Checks all of the VMAs mapping the page
  * to make sure nobody else has this page mlocked. The page will be
  * returned with PG_mlocked cleared if no other vmas have it mlocked.
- *
- * Return values are:
- *
- * SWAP_AGAIN  - no vma is holding page mlocked, or,
- * SWAP_AGAIN  - page mapped in mlocked vma -- couldn't acquire mmap sem
- * SWAP_FAIL   - page cannot be located at present
- * SWAP_MLOCK  - page is now mlocked.
  */
-int try_to_munlock(struct page *page)
-{
-   int ret;
 
+void try_to_munlock(struct page *page)
+{
struct rmap_walk_control rwc = {
.rmap_one = try_to_unmap_one,
.arg = (void *)TTU_MUNLOCK,
@@ -1568,9 +1560,10 @@ int try_to_munlock(struct page *page)
};
 
VM_BUG_ON_PAGE(!PageLocked(page) || PageLRU(page), page);
+   VM_BUG_ON_PAGE(PageMlocked(page), page);
+   VM_BUG_ON_PAGE(PageCompound(page) && PageDoubleMap(page), page);
 
-   ret = rmap_walk(page, );
-   return ret;
+   rmap_walk(page, );
 }
 
 void __put_anon_vma(struct anon_vma *anon_vma)
-- 
2.7.4

[PATCH v2 07/10] mm: make ttu's return boolean

[Minchan Kim]

try_to_unmap returns SWAP_SUCCESS or SWAP_FAIL so it's suitable for
boolean return. This patch changes it.

Cc: "Kirill A. Shutemov" 
Cc: Naoya Horiguchi 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  4 ++--
 mm/huge_memory.c |  6 +++---
 mm/memory-failure.c  | 26 --
 mm/rmap.c|  8 +++-
 mm/vmscan.c  |  7 +--
 5 files changed, 21 insertions(+), 30 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 3630d4d..6028c38 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -191,7 +191,7 @@ static inline void page_dup_rmap(struct page *page, bool 
compound)
 int page_referenced(struct page *, int is_locked,
struct mem_cgroup *memcg, unsigned long *vm_flags);
 
-int try_to_unmap(struct page *, enum ttu_flags flags);
+bool try_to_unmap(struct page *, enum ttu_flags flags);
 
 /* Avoid racy checks */
 #define PVMW_SYNC  (1 << 0)
@@ -281,7 +281,7 @@ static inline int page_referenced(struct page *page, int 
is_locked,
return 0;
 }
 
-#define try_to_unmap(page, refs) SWAP_FAIL
+#define try_to_unmap(page, refs) false
 
 static inline int page_mkclean(struct page *page)
 {
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 2b4120f..033ccee 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2139,15 +2139,15 @@ static void freeze_page(struct page *page)
 {
enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS |
TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
-   int ret;
+   bool unmap_success;
 
VM_BUG_ON_PAGE(!PageHead(page), page);
 
if (PageAnon(page))
ttu_flags |= TTU_MIGRATION;
 
-   ret = try_to_unmap(page, ttu_flags);
-   VM_BUG_ON_PAGE(ret, page);
+   unmap_success = try_to_unmap(page, ttu_flags);
+   VM_BUG_ON_PAGE(!unmap_success, page);
 }
 
 static void unfreeze_page(struct page *page)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index f85adfe5..3d3cf6a 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -322,7 +322,7 @@ static void add_to_kill(struct task_struct *tsk, struct 
page *p,
  * wrong earlier.
  */
 static void kill_procs(struct list_head *to_kill, int forcekill, int trapno,
- int fail, struct page *page, unsigned long pfn,
+ bool fail, struct page *page, unsigned long pfn,
  int flags)
 {
struct to_kill *tk, *next;
@@ -904,13 +904,13 @@ EXPORT_SYMBOL_GPL(get_hwpoison_page);
  * Do all that is necessary to remove user space mappings. Unmap
  * the pages and send SIGBUS to the processes if the data was dirty.
  */
-static int hwpoison_user_mappings(struct page *p, unsigned long pfn,
+static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
  int trapno, int flags, struct page **hpagep)
 {
enum ttu_flags ttu = TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
struct address_space *mapping;
LIST_HEAD(tokill);
-   int ret;
+   bool unmap_success;
int kill = 1, forcekill;
struct page *hpage = *hpagep;
 
@@ -919,20 +919,20 @@ static int hwpoison_user_mappings(struct page *p, 
unsigned long pfn,
 * other types of pages.
 */
if (PageReserved(p) || PageSlab(p))
-   return SWAP_SUCCESS;
+   return true;
if (!(PageLRU(hpage) || PageHuge(p)))
-   return SWAP_SUCCESS;
+   return true;
 
/*
 * This check implies we don't kill processes if their pages
 * are in the swap cache early. Those are always late kills.
 */
if (!page_mapped(hpage))
-   return SWAP_SUCCESS;
+   return true;
 
if (PageKsm(p)) {
pr_err("Memory failure: %#lx: can't handle KSM pages.\n", pfn);
-   return SWAP_FAIL;
+   return false;
}
 
if (PageSwapCache(p)) {
@@ -971,8 +971,8 @@ static int hwpoison_user_mappings(struct page *p, unsigned 
long pfn,
if (kill)
collect_procs(hpage, , flags & MF_ACTION_REQUIRED);
 
-   ret = try_to_unmap(hpage, ttu);
-   if (ret != SWAP_SUCCESS)
+   unmap_success = try_to_unmap(hpage, ttu);
+   if (!unmap_success)
pr_err("Memory failure: %#lx: failed to unmap page 
(mapcount=%d)\n",
   pfn, page_mapcount(hpage));
 
@@ -987,10 +987,9 @@ static int hwpoison_user_mappings(struct page *p, unsigned 
long pfn,
 * any accesses to the poisoned memory.
 */
forcekill = PageDirty(hpage) || (flags & MF_MUST_KILL);
-   kill_procs(, forcekill, trapno,
- ret != SWAP_SUCCESS, p, pfn, flags);
+   kill_procs(, forcekill, trapno, !unmap_success, p, pfn, flags);
 
-   return ret;
+   return unmap_success;
 }
 

[PATCH v2 08/10] mm: make rmap_walk void function

[Minchan Kim]

There is no user of return value from rmap_walk friend so this
patch makes them void function.

Signed-off-by: Minchan Kim 
---
 include/linux/ksm.h  |  5 ++---
 include/linux/rmap.h |  4 ++--
 mm/ksm.c | 16 ++--
 mm/rmap.c| 32 +---
 4 files changed, 23 insertions(+), 34 deletions(-)

diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index e1cfda4..78b44a0 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -61,7 +61,7 @@ static inline void set_page_stable_node(struct page *page,
 struct page *ksm_might_need_to_copy(struct page *page,
struct vm_area_struct *vma, unsigned long address);
 
-int rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc);
+void rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc);
 void ksm_migrate_page(struct page *newpage, struct page *oldpage);
 
 #else  /* !CONFIG_KSM */
@@ -94,10 +94,9 @@ static inline int page_referenced_ksm(struct page *page,
return 0;
 }
 
-static inline int rmap_walk_ksm(struct page *page,
+static inline void rmap_walk_ksm(struct page *page,
struct rmap_walk_control *rwc)
 {
-   return 0;
 }
 
 static inline void ksm_migrate_page(struct page *newpage, struct page *oldpage)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 6028c38..1d7d457c 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -264,8 +264,8 @@ struct rmap_walk_control {
bool (*invalid_vma)(struct vm_area_struct *vma, void *arg);
 };
 
-int rmap_walk(struct page *page, struct rmap_walk_control *rwc);
-int rmap_walk_locked(struct page *page, struct rmap_walk_control *rwc);
+void rmap_walk(struct page *page, struct rmap_walk_control *rwc);
+void rmap_walk_locked(struct page *page, struct rmap_walk_control *rwc);
 
 #else  /* !CONFIG_MMU */
 
diff --git a/mm/ksm.c b/mm/ksm.c
index 19b4f2d..6edffb9 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1933,11 +1933,10 @@ struct page *ksm_might_need_to_copy(struct page *page,
return new_page;
 }
 
-int rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc)
+void rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc)
 {
struct stable_node *stable_node;
struct rmap_item *rmap_item;
-   int ret = SWAP_AGAIN;
int search_new_forks = 0;
 
VM_BUG_ON_PAGE(!PageKsm(page), page);
@@ -1950,7 +1949,7 @@ int rmap_walk_ksm(struct page *page, struct 
rmap_walk_control *rwc)
 
stable_node = page_stable_node(page);
if (!stable_node)
-   return ret;
+   return;
 again:
hlist_for_each_entry(rmap_item, _node->hlist, hlist) {
struct anon_vma *anon_vma = rmap_item->anon_vma;
@@ -1978,23 +1977,20 @@ int rmap_walk_ksm(struct page *page, struct 
rmap_walk_control *rwc)
if (rwc->invalid_vma && rwc->invalid_vma(vma, rwc->arg))
continue;
 
-   ret = rwc->rmap_one(page, vma,
-   rmap_item->address, rwc->arg);
-   if (ret != SWAP_AGAIN) {
+   if (SWAP_AGAIN != rwc->rmap_one(page, vma,
+   rmap_item->address, rwc->arg)) {
anon_vma_unlock_read(anon_vma);
-   goto out;
+   return;
}
if (rwc->done && rwc->done(page)) {
anon_vma_unlock_read(anon_vma);
-   goto out;
+   return;
}
}
anon_vma_unlock_read(anon_vma);
}
if (!search_new_forks++)
goto again;
-out:
-   return ret;
 }
 
 #ifdef CONFIG_MIGRATION
diff --git a/mm/rmap.c b/mm/rmap.c
index 04d5355..987b0d2 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1603,13 +1603,12 @@ static struct anon_vma *rmap_walk_anon_lock(struct page 
*page,
  * vm_flags for that VMA.  That should be OK, because that vma shouldn't be
  * LOCKED.
  */
-static int rmap_walk_anon(struct page *page, struct rmap_walk_control *rwc,
+static void rmap_walk_anon(struct page *page, struct rmap_walk_control *rwc,
bool locked)
 {
struct anon_vma *anon_vma;
pgoff_t pgoff_start, pgoff_end;
struct anon_vma_chain *avc;
-   int ret = SWAP_AGAIN;
 
if (locked) {
anon_vma = page_anon_vma(page);
@@ -1619,7 +1618,7 @@ static int rmap_walk_anon(struct page *page, struct 
rmap_walk_control *rwc,
anon_vma = rmap_walk_anon_lock(page, rwc);
}
if (!anon_vma)
-   return ret;
+   return;
 
pgoff_start = page_to_pgoff(page);
pgoff_end = pgoff_start + hpage_nr_pages(page) - 1;
@@ -1633,8 +1632,7 @@ static int rmap_walk_anon(struct page 

[PATCH v2 07/10] mm: make ttu's return boolean

[Minchan Kim]

try_to_unmap returns SWAP_SUCCESS or SWAP_FAIL so it's suitable for
boolean return. This patch changes it.

Cc: "Kirill A. Shutemov" 
Cc: Naoya Horiguchi 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  4 ++--
 mm/huge_memory.c |  6 +++---
 mm/memory-failure.c  | 26 --
 mm/rmap.c|  8 +++-
 mm/vmscan.c  |  7 +--
 5 files changed, 21 insertions(+), 30 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 3630d4d..6028c38 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -191,7 +191,7 @@ static inline void page_dup_rmap(struct page *page, bool 
compound)
 int page_referenced(struct page *, int is_locked,
struct mem_cgroup *memcg, unsigned long *vm_flags);
 
-int try_to_unmap(struct page *, enum ttu_flags flags);
+bool try_to_unmap(struct page *, enum ttu_flags flags);
 
 /* Avoid racy checks */
 #define PVMW_SYNC  (1 << 0)
@@ -281,7 +281,7 @@ static inline int page_referenced(struct page *page, int 
is_locked,
return 0;
 }
 
-#define try_to_unmap(page, refs) SWAP_FAIL
+#define try_to_unmap(page, refs) false
 
 static inline int page_mkclean(struct page *page)
 {
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 2b4120f..033ccee 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2139,15 +2139,15 @@ static void freeze_page(struct page *page)
 {
enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS |
TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
-   int ret;
+   bool unmap_success;
 
VM_BUG_ON_PAGE(!PageHead(page), page);
 
if (PageAnon(page))
ttu_flags |= TTU_MIGRATION;
 
-   ret = try_to_unmap(page, ttu_flags);
-   VM_BUG_ON_PAGE(ret, page);
+   unmap_success = try_to_unmap(page, ttu_flags);
+   VM_BUG_ON_PAGE(!unmap_success, page);
 }
 
 static void unfreeze_page(struct page *page)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index f85adfe5..3d3cf6a 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -322,7 +322,7 @@ static void add_to_kill(struct task_struct *tsk, struct 
page *p,
  * wrong earlier.
  */
 static void kill_procs(struct list_head *to_kill, int forcekill, int trapno,
- int fail, struct page *page, unsigned long pfn,
+ bool fail, struct page *page, unsigned long pfn,
  int flags)
 {
struct to_kill *tk, *next;
@@ -904,13 +904,13 @@ EXPORT_SYMBOL_GPL(get_hwpoison_page);
  * Do all that is necessary to remove user space mappings. Unmap
  * the pages and send SIGBUS to the processes if the data was dirty.
  */
-static int hwpoison_user_mappings(struct page *p, unsigned long pfn,
+static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
  int trapno, int flags, struct page **hpagep)
 {
enum ttu_flags ttu = TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS;
struct address_space *mapping;
LIST_HEAD(tokill);
-   int ret;
+   bool unmap_success;
int kill = 1, forcekill;
struct page *hpage = *hpagep;
 
@@ -919,20 +919,20 @@ static int hwpoison_user_mappings(struct page *p, 
unsigned long pfn,
 * other types of pages.
 */
if (PageReserved(p) || PageSlab(p))
-   return SWAP_SUCCESS;
+   return true;
if (!(PageLRU(hpage) || PageHuge(p)))
-   return SWAP_SUCCESS;
+   return true;
 
/*
 * This check implies we don't kill processes if their pages
 * are in the swap cache early. Those are always late kills.
 */
if (!page_mapped(hpage))
-   return SWAP_SUCCESS;
+   return true;
 
if (PageKsm(p)) {
pr_err("Memory failure: %#lx: can't handle KSM pages.\n", pfn);
-   return SWAP_FAIL;
+   return false;
}
 
if (PageSwapCache(p)) {
@@ -971,8 +971,8 @@ static int hwpoison_user_mappings(struct page *p, unsigned 
long pfn,
if (kill)
collect_procs(hpage, , flags & MF_ACTION_REQUIRED);
 
-   ret = try_to_unmap(hpage, ttu);
-   if (ret != SWAP_SUCCESS)
+   unmap_success = try_to_unmap(hpage, ttu);
+   if (!unmap_success)
pr_err("Memory failure: %#lx: failed to unmap page 
(mapcount=%d)\n",
   pfn, page_mapcount(hpage));
 
@@ -987,10 +987,9 @@ static int hwpoison_user_mappings(struct page *p, unsigned 
long pfn,
 * any accesses to the poisoned memory.
 */
forcekill = PageDirty(hpage) || (flags & MF_MUST_KILL);
-   kill_procs(, forcekill, trapno,
- ret != SWAP_SUCCESS, p, pfn, flags);
+   kill_procs(, forcekill, trapno, !unmap_success, p, pfn, flags);
 
-   return ret;
+   return unmap_success;
 }
 
 static void set_page_hwpoison_huge_page(struct page *hpage)
@@ -1230,8 

[PATCH v2 08/10] mm: make rmap_walk void function

[Minchan Kim]

There is no user of return value from rmap_walk friend so this
patch makes them void function.

Signed-off-by: Minchan Kim 
---
 include/linux/ksm.h  |  5 ++---
 include/linux/rmap.h |  4 ++--
 mm/ksm.c | 16 ++--
 mm/rmap.c| 32 +---
 4 files changed, 23 insertions(+), 34 deletions(-)

diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index e1cfda4..78b44a0 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -61,7 +61,7 @@ static inline void set_page_stable_node(struct page *page,
 struct page *ksm_might_need_to_copy(struct page *page,
struct vm_area_struct *vma, unsigned long address);
 
-int rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc);
+void rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc);
 void ksm_migrate_page(struct page *newpage, struct page *oldpage);
 
 #else  /* !CONFIG_KSM */
@@ -94,10 +94,9 @@ static inline int page_referenced_ksm(struct page *page,
return 0;
 }
 
-static inline int rmap_walk_ksm(struct page *page,
+static inline void rmap_walk_ksm(struct page *page,
struct rmap_walk_control *rwc)
 {
-   return 0;
 }
 
 static inline void ksm_migrate_page(struct page *newpage, struct page *oldpage)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 6028c38..1d7d457c 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -264,8 +264,8 @@ struct rmap_walk_control {
bool (*invalid_vma)(struct vm_area_struct *vma, void *arg);
 };
 
-int rmap_walk(struct page *page, struct rmap_walk_control *rwc);
-int rmap_walk_locked(struct page *page, struct rmap_walk_control *rwc);
+void rmap_walk(struct page *page, struct rmap_walk_control *rwc);
+void rmap_walk_locked(struct page *page, struct rmap_walk_control *rwc);
 
 #else  /* !CONFIG_MMU */
 
diff --git a/mm/ksm.c b/mm/ksm.c
index 19b4f2d..6edffb9 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1933,11 +1933,10 @@ struct page *ksm_might_need_to_copy(struct page *page,
return new_page;
 }
 
-int rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc)
+void rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc)
 {
struct stable_node *stable_node;
struct rmap_item *rmap_item;
-   int ret = SWAP_AGAIN;
int search_new_forks = 0;
 
VM_BUG_ON_PAGE(!PageKsm(page), page);
@@ -1950,7 +1949,7 @@ int rmap_walk_ksm(struct page *page, struct 
rmap_walk_control *rwc)
 
stable_node = page_stable_node(page);
if (!stable_node)
-   return ret;
+   return;
 again:
hlist_for_each_entry(rmap_item, _node->hlist, hlist) {
struct anon_vma *anon_vma = rmap_item->anon_vma;
@@ -1978,23 +1977,20 @@ int rmap_walk_ksm(struct page *page, struct 
rmap_walk_control *rwc)
if (rwc->invalid_vma && rwc->invalid_vma(vma, rwc->arg))
continue;
 
-   ret = rwc->rmap_one(page, vma,
-   rmap_item->address, rwc->arg);
-   if (ret != SWAP_AGAIN) {
+   if (SWAP_AGAIN != rwc->rmap_one(page, vma,
+   rmap_item->address, rwc->arg)) {
anon_vma_unlock_read(anon_vma);
-   goto out;
+   return;
}
if (rwc->done && rwc->done(page)) {
anon_vma_unlock_read(anon_vma);
-   goto out;
+   return;
}
}
anon_vma_unlock_read(anon_vma);
}
if (!search_new_forks++)
goto again;
-out:
-   return ret;
 }
 
 #ifdef CONFIG_MIGRATION
diff --git a/mm/rmap.c b/mm/rmap.c
index 04d5355..987b0d2 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1603,13 +1603,12 @@ static struct anon_vma *rmap_walk_anon_lock(struct page 
*page,
  * vm_flags for that VMA.  That should be OK, because that vma shouldn't be
  * LOCKED.
  */
-static int rmap_walk_anon(struct page *page, struct rmap_walk_control *rwc,
+static void rmap_walk_anon(struct page *page, struct rmap_walk_control *rwc,
bool locked)
 {
struct anon_vma *anon_vma;
pgoff_t pgoff_start, pgoff_end;
struct anon_vma_chain *avc;
-   int ret = SWAP_AGAIN;
 
if (locked) {
anon_vma = page_anon_vma(page);
@@ -1619,7 +1618,7 @@ static int rmap_walk_anon(struct page *page, struct 
rmap_walk_control *rwc,
anon_vma = rmap_walk_anon_lock(page, rwc);
}
if (!anon_vma)
-   return ret;
+   return;
 
pgoff_start = page_to_pgoff(page);
pgoff_end = pgoff_start + hpage_nr_pages(page) - 1;
@@ -1633,8 +1632,7 @@ static int rmap_walk_anon(struct page *page, struct 

[PATCH v2 01/10] mm: remove unncessary ret in page_referenced

[Minchan Kim]

Anyone doesn't use ret variable. Remove it.

Acked-by: Hillf Danton 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 mm/rmap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 7d24bb9..9dbfa6f 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -807,7 +807,6 @@ int page_referenced(struct page *page,
struct mem_cgroup *memcg,
unsigned long *vm_flags)
 {
-   int ret;
int we_locked = 0;
struct page_referenced_arg pra = {
.mapcount = total_mapcount(page),
@@ -841,7 +840,7 @@ int page_referenced(struct page *page,
rwc.invalid_vma = invalid_page_referenced_vma;
}
 
-   ret = rmap_walk(page, );
+   rmap_walk(page, );
*vm_flags = pra.vm_flags;
 
if (we_locked)
-- 
2.7.4

[PATCH v2 10/10] mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

[Minchan Kim]

There is no user for it. Remove it.

Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 13ed232..43ef2c3 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -295,11 +295,4 @@ static inline int page_mkclean(struct page *page)
 
 #endif /* CONFIG_MMU */
 
-/*
- * Return values of try_to_unmap
- */
-#define SWAP_SUCCESS   0
-#define SWAP_AGAIN 1
-#define SWAP_FAIL  2
-
 #endif /* _LINUX_RMAP_H */
-- 
2.7.4

[PATCH v2 10/10] mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

[Minchan Kim]

There is no user for it. Remove it.

Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 13ed232..43ef2c3 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -295,11 +295,4 @@ static inline int page_mkclean(struct page *page)
 
 #endif /* CONFIG_MMU */
 
-/*
- * Return values of try_to_unmap
- */
-#define SWAP_SUCCESS   0
-#define SWAP_AGAIN 1
-#define SWAP_FAIL  2
-
 #endif /* _LINUX_RMAP_H */
-- 
2.7.4

[PATCH v2 01/10] mm: remove unncessary ret in page_referenced

[Minchan Kim]

Anyone doesn't use ret variable. Remove it.

Acked-by: Hillf Danton 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 mm/rmap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 7d24bb9..9dbfa6f 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -807,7 +807,6 @@ int page_referenced(struct page *page,
struct mem_cgroup *memcg,
unsigned long *vm_flags)
 {
-   int ret;
int we_locked = 0;
struct page_referenced_arg pra = {
.mapcount = total_mapcount(page),
@@ -841,7 +840,7 @@ int page_referenced(struct page *page,
rwc.invalid_vma = invalid_page_referenced_vma;
}
 
-   ret = rmap_walk(page, );
+   rmap_walk(page, );
*vm_flags = pra.vm_flags;
 
if (we_locked)
-- 
2.7.4

[PATCH v2 02/10] mm: remove SWAP_DIRTY in ttu

[Minchan Kim]

If we found lazyfree page is dirty, try_to_unmap_one can just
SetPageSwapBakced in there like PG_mlocked page and just return
with SWAP_FAIL which is very natural because the page is not swappable
right now so that vmscan can activate it.
There is no point to introduce new return value SWAP_DIRTY
in try_to_unmap at the moment.

Acked-by: Hillf Danton 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h | 1 -
 mm/rmap.c| 4 ++--
 mm/vmscan.c  | 3 ---
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index fee10d7..b556eef 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -298,6 +298,5 @@ static inline int page_mkclean(struct page *page)
 #define SWAP_AGAIN 1
 #define SWAP_FAIL  2
 #define SWAP_MLOCK 3
-#define SWAP_DIRTY 4
 
 #endif /* _LINUX_RMAP_H */
diff --git a/mm/rmap.c b/mm/rmap.c
index 9dbfa6f..e692cb5 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1431,7 +1431,8 @@ static int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
 * discarded. Remap the page to page table.
 */
set_pte_at(mm, address, pvmw.pte, pteval);
-   ret = SWAP_DIRTY;
+   SetPageSwapBacked(page);
+   ret = SWAP_FAIL;
page_vma_mapped_walk_done();
break;
}
@@ -1501,7 +1502,6 @@ static int page_mapcount_is_zero(struct page *page)
  * SWAP_AGAIN  - we missed a mapping, try again later
  * SWAP_FAIL   - the page is unswappable
  * SWAP_MLOCK  - page is mlocked.
- * SWAP_DIRTY  - page is dirty MADV_FREE page
  */
 int try_to_unmap(struct page *page, enum ttu_flags flags)
 {
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a3656f9..b8fd656 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1142,9 +1142,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (page_mapped(page)) {
switch (ret = try_to_unmap(page,
ttu_flags | TTU_BATCH_FLUSH)) {
-   case SWAP_DIRTY:
-   SetPageSwapBacked(page);
-   /* fall through */
case SWAP_FAIL:
nr_unmap_fail++;
goto activate_locked;
-- 
2.7.4

[PATCH v2 02/10] mm: remove SWAP_DIRTY in ttu

[Minchan Kim]

If we found lazyfree page is dirty, try_to_unmap_one can just
SetPageSwapBakced in there like PG_mlocked page and just return
with SWAP_FAIL which is very natural because the page is not swappable
right now so that vmscan can activate it.
There is no point to introduce new return value SWAP_DIRTY
in try_to_unmap at the moment.

Acked-by: Hillf Danton 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h | 1 -
 mm/rmap.c| 4 ++--
 mm/vmscan.c  | 3 ---
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index fee10d7..b556eef 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -298,6 +298,5 @@ static inline int page_mkclean(struct page *page)
 #define SWAP_AGAIN 1
 #define SWAP_FAIL  2
 #define SWAP_MLOCK 3
-#define SWAP_DIRTY 4
 
 #endif /* _LINUX_RMAP_H */
diff --git a/mm/rmap.c b/mm/rmap.c
index 9dbfa6f..e692cb5 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1431,7 +1431,8 @@ static int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
 * discarded. Remap the page to page table.
 */
set_pte_at(mm, address, pvmw.pte, pteval);
-   ret = SWAP_DIRTY;
+   SetPageSwapBacked(page);
+   ret = SWAP_FAIL;
page_vma_mapped_walk_done();
break;
}
@@ -1501,7 +1502,6 @@ static int page_mapcount_is_zero(struct page *page)
  * SWAP_AGAIN  - we missed a mapping, try again later
  * SWAP_FAIL   - the page is unswappable
  * SWAP_MLOCK  - page is mlocked.
- * SWAP_DIRTY  - page is dirty MADV_FREE page
  */
 int try_to_unmap(struct page *page, enum ttu_flags flags)
 {
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a3656f9..b8fd656 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1142,9 +1142,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
if (page_mapped(page)) {
switch (ret = try_to_unmap(page,
ttu_flags | TTU_BATCH_FLUSH)) {
-   case SWAP_DIRTY:
-   SetPageSwapBacked(page);
-   /* fall through */
case SWAP_FAIL:
nr_unmap_fail++;
goto activate_locked;
-- 
2.7.4

[PATCH v2 05/10] mm: remove SWAP_MLOCK in ttu

[Minchan Kim]

ttu don't need to return SWAP_MLOCK. Instead, just return SWAP_FAIL
because it means the page is not-swappable so it should move to
another LRU list(active or unevictable). putback friends will
move it to right list depending on the page's LRU flag.

Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  1 -
 mm/rmap.c|  3 +--
 mm/vmscan.c  | 20 +++-
 3 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 1b0cd4c..3630d4d 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -297,6 +297,5 @@ static inline int page_mkclean(struct page *page)
 #define SWAP_SUCCESS   0
 #define SWAP_AGAIN 1
 #define SWAP_FAIL  2
-#define SWAP_MLOCK 3
 
 #endif /* _LINUX_RMAP_H */
diff --git a/mm/rmap.c b/mm/rmap.c
index 2f1fbd9..a5af1e1 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1324,7 +1324,7 @@ static int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
 */
mlock_vma_page(page);
}
-   ret = SWAP_MLOCK;
+   ret = SWAP_FAIL;
page_vma_mapped_walk_done();
break;
}
@@ -1501,7 +1501,6 @@ static int page_mapcount_is_zero(struct page *page)
  * SWAP_SUCCESS- we succeeded in removing all mappings
  * SWAP_AGAIN  - we missed a mapping, try again later
  * SWAP_FAIL   - the page is unswappable
- * SWAP_MLOCK  - page is mlocked.
  */
 int try_to_unmap(struct page *page, enum ttu_flags flags)
 {
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b8fd656..2a208f0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -982,7 +982,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
sc->nr_scanned++;
 
if (unlikely(!page_evictable(page)))
-   goto cull_mlocked;
+   goto activate_locked;
 
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1147,8 +1147,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
goto activate_locked;
case SWAP_AGAIN:
goto keep_locked;
-   case SWAP_MLOCK:
-   goto cull_mlocked;
case SWAP_SUCCESS:
; /* try to free the page below */
}
@@ -1290,20 +1288,16 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
list_add(>lru, _pages);
continue;
 
-cull_mlocked:
-   if (PageSwapCache(page))
-   try_to_free_swap(page);
-   unlock_page(page);
-   list_add(>lru, _pages);
-   continue;
-
 activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
-   if (PageSwapCache(page) && mem_cgroup_swap_full(page))
+   if (PageSwapCache(page) && (mem_cgroup_swap_full(page) ||
+   PageMlocked(page)))
try_to_free_swap(page);
VM_BUG_ON_PAGE(PageActive(page), page);
-   SetPageActive(page);
-   pgactivate++;
+   if (!PageMlocked(page)) {
+   SetPageActive(page);
+   pgactivate++;
+   }
 keep_locked:
unlock_page(page);
 keep:
-- 
2.7.4

[PATCH v2 05/10] mm: remove SWAP_MLOCK in ttu

[Minchan Kim]

ttu don't need to return SWAP_MLOCK. Instead, just return SWAP_FAIL
because it means the page is not-swappable so it should move to
another LRU list(active or unevictable). putback friends will
move it to right list depending on the page's LRU flag.

Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  1 -
 mm/rmap.c|  3 +--
 mm/vmscan.c  | 20 +++-
 3 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 1b0cd4c..3630d4d 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -297,6 +297,5 @@ static inline int page_mkclean(struct page *page)
 #define SWAP_SUCCESS   0
 #define SWAP_AGAIN 1
 #define SWAP_FAIL  2
-#define SWAP_MLOCK 3
 
 #endif /* _LINUX_RMAP_H */
diff --git a/mm/rmap.c b/mm/rmap.c
index 2f1fbd9..a5af1e1 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1324,7 +1324,7 @@ static int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
 */
mlock_vma_page(page);
}
-   ret = SWAP_MLOCK;
+   ret = SWAP_FAIL;
page_vma_mapped_walk_done();
break;
}
@@ -1501,7 +1501,6 @@ static int page_mapcount_is_zero(struct page *page)
  * SWAP_SUCCESS- we succeeded in removing all mappings
  * SWAP_AGAIN  - we missed a mapping, try again later
  * SWAP_FAIL   - the page is unswappable
- * SWAP_MLOCK  - page is mlocked.
  */
 int try_to_unmap(struct page *page, enum ttu_flags flags)
 {
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b8fd656..2a208f0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -982,7 +982,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
sc->nr_scanned++;
 
if (unlikely(!page_evictable(page)))
-   goto cull_mlocked;
+   goto activate_locked;
 
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1147,8 +1147,6 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
goto activate_locked;
case SWAP_AGAIN:
goto keep_locked;
-   case SWAP_MLOCK:
-   goto cull_mlocked;
case SWAP_SUCCESS:
; /* try to free the page below */
}
@@ -1290,20 +1288,16 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
list_add(>lru, _pages);
continue;
 
-cull_mlocked:
-   if (PageSwapCache(page))
-   try_to_free_swap(page);
-   unlock_page(page);
-   list_add(>lru, _pages);
-   continue;
-
 activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
-   if (PageSwapCache(page) && mem_cgroup_swap_full(page))
+   if (PageSwapCache(page) && (mem_cgroup_swap_full(page) ||
+   PageMlocked(page)))
try_to_free_swap(page);
VM_BUG_ON_PAGE(PageActive(page), page);
-   SetPageActive(page);
-   pgactivate++;
+   if (!PageMlocked(page)) {
+   SetPageActive(page);
+   pgactivate++;
+   }
 keep_locked:
unlock_page(page);
 keep:
-- 
2.7.4

[PATCH v2 00/10] make try_to_unmap simple

[Minchan Kim]

Currently, try_to_unmap returns various return value(SWAP_SUCCESS,
SWAP_FAIL, SWAP_AGAIN, SWAP_DIRTY and SWAP_MLOCK). When I look into
that, it's unncessary complicated so this patch aims for cleaning
it up. Change ttu to boolean function so we can remove SWAP_AGAIN,
SWAP_DIRTY, SWAP_MLOCK.

* from v1
  * add some acked-by
  * add description about rmap_one's return - Andrew

* from RFC
- http://lkml.kernel.org/r/1488436765-32350-1-git-send-email-minc...@kernel.org
  * Remove RFC tag
  * add acked-by to some patches
  * some of minor fixes
  * based on mmotm-2017-03-09-16-19.


Minchan Kim (10):
  mm: remove unncessary ret in page_referenced
  mm: remove SWAP_DIRTY in ttu
  mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu
  mm: make the try_to_munlock void function
  mm: remove SWAP_MLOCK in ttu
  mm: remove SWAP_AGAIN in ttu
  mm: make ttu's return boolean
  mm: make rmap_walk void function
  mm: make rmap_one boolean function
  mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

 include/linux/ksm.h  |  5 ++-
 include/linux/rmap.h | 25 ++
 mm/huge_memory.c |  6 ++--
 mm/ksm.c | 16 -
 mm/memory-failure.c  | 26 +++---
 mm/migrate.c |  4 +--
 mm/mlock.c   |  6 ++--
 mm/page_idle.c   |  4 +--
 mm/rmap.c| 98 
 mm/vmscan.c  | 32 +
 10 files changed, 85 insertions(+), 137 deletions(-)

-- 
2.7.4

[PATCH v2 09/10] mm: make rmap_one boolean function

[Minchan Kim]

rmap_one's return value controls whether rmap_work should contine to
scan other ptes or not so it's target for changing to boolean.
Return true if the scan should be continued. Otherwise, return false
to stop the scanning.

This patch makes rmap_one's return value to boolean.

Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  6 +-
 mm/ksm.c |  2 +-
 mm/migrate.c |  4 ++--
 mm/page_idle.c   |  4 ++--
 mm/rmap.c| 30 +++---
 5 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 1d7d457c..13ed232 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -257,7 +257,11 @@ int page_mapped_in_vma(struct page *page, struct 
vm_area_struct *vma);
  */
 struct rmap_walk_control {
void *arg;
-   int (*rmap_one)(struct page *page, struct vm_area_struct *vma,
+   /*
+* Return false if page table scanning in rmap_walk should be stopped.
+* Otherwise, return true.
+*/
+   bool (*rmap_one)(struct page *page, struct vm_area_struct *vma,
unsigned long addr, void *arg);
int (*done)(struct page *page);
struct anon_vma *(*anon_lock)(struct page *page);
diff --git a/mm/ksm.c b/mm/ksm.c
index 6edffb9..d9fc0e4 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1977,7 +1977,7 @@ void rmap_walk_ksm(struct page *page, struct 
rmap_walk_control *rwc)
if (rwc->invalid_vma && rwc->invalid_vma(vma, rwc->arg))
continue;
 
-   if (SWAP_AGAIN != rwc->rmap_one(page, vma,
+   if (!rwc->rmap_one(page, vma,
rmap_item->address, rwc->arg)) {
anon_vma_unlock_read(anon_vma);
return;
diff --git a/mm/migrate.c b/mm/migrate.c
index e0cb4b7..8e9f1e8 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -194,7 +194,7 @@ void putback_movable_pages(struct list_head *l)
 /*
  * Restore a potential migration pte to a working pte entry
  */
-static int remove_migration_pte(struct page *page, struct vm_area_struct *vma,
+static bool remove_migration_pte(struct page *page, struct vm_area_struct *vma,
 unsigned long addr, void *old)
 {
struct page_vma_mapped_walk pvmw = {
@@ -250,7 +250,7 @@ static int remove_migration_pte(struct page *page, struct 
vm_area_struct *vma,
update_mmu_cache(vma, pvmw.address, pvmw.pte);
}
 
-   return SWAP_AGAIN;
+   return true;
 }
 
 /*
diff --git a/mm/page_idle.c b/mm/page_idle.c
index b0ee56c..1b0f48c 100644
--- a/mm/page_idle.c
+++ b/mm/page_idle.c
@@ -50,7 +50,7 @@ static struct page *page_idle_get_page(unsigned long pfn)
return page;
 }
 
-static int page_idle_clear_pte_refs_one(struct page *page,
+static bool page_idle_clear_pte_refs_one(struct page *page,
struct vm_area_struct *vma,
unsigned long addr, void *arg)
 {
@@ -84,7 +84,7 @@ static int page_idle_clear_pte_refs_one(struct page *page,
 */
set_page_young(page);
}
-   return SWAP_AGAIN;
+   return true;
 }
 
 static void page_idle_clear_pte_refs(struct page *page)
diff --git a/mm/rmap.c b/mm/rmap.c
index 987b0d2..aa25fde 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -719,7 +719,7 @@ struct page_referenced_arg {
 /*
  * arg: page_referenced_arg will be passed
  */
-static int page_referenced_one(struct page *page, struct vm_area_struct *vma,
+static bool page_referenced_one(struct page *page, struct vm_area_struct *vma,
unsigned long address, void *arg)
 {
struct page_referenced_arg *pra = arg;
@@ -736,7 +736,7 @@ static int page_referenced_one(struct page *page, struct 
vm_area_struct *vma,
if (vma->vm_flags & VM_LOCKED) {
page_vma_mapped_walk_done();
pra->vm_flags |= VM_LOCKED;
-   return SWAP_FAIL; /* To break the loop */
+   return false; /* To break the loop */
}
 
if (pvmw.pte) {
@@ -776,9 +776,9 @@ static int page_referenced_one(struct page *page, struct 
vm_area_struct *vma,
}
 
if (!pra->mapcount)
-   return SWAP_SUCCESS; /* To break the loop */
+   return false; /* To break the loop */
 
-   return SWAP_AGAIN;
+   return true;
 }
 
 static bool invalid_page_referenced_vma(struct vm_area_struct *vma, void *arg)
@@ -849,7 +849,7 @@ int page_referenced(struct page *page,
return pra.referenced;
 }
 
-static int page_mkclean_one(struct page *page, struct vm_area_struct *vma,
+static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma,
unsigned long address, void 

[PATCH v2 03/10] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

[Minchan Kim]

If the page is mapped and rescue in try_to_unmap_one,
page_mapcount(page) == 0 cannot be true so page_mapcount check
in try_to_unmap is enough to return SWAP_SUCCESS.
IOW, SWAP_MLOCK check is redundant so remove it.

Signed-off-by: Minchan Kim 
---
 mm/rmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index e692cb5..bdc7310 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1530,7 +1530,7 @@ int try_to_unmap(struct page *page, enum ttu_flags flags)
else
ret = rmap_walk(page, );
 
-   if (ret != SWAP_MLOCK && !page_mapcount(page))
+   if (!page_mapcount(page))
ret = SWAP_SUCCESS;
return ret;
 }
-- 
2.7.4

[PATCH v2 00/10] make try_to_unmap simple

[Minchan Kim]

Currently, try_to_unmap returns various return value(SWAP_SUCCESS,
SWAP_FAIL, SWAP_AGAIN, SWAP_DIRTY and SWAP_MLOCK). When I look into
that, it's unncessary complicated so this patch aims for cleaning
it up. Change ttu to boolean function so we can remove SWAP_AGAIN,
SWAP_DIRTY, SWAP_MLOCK.

* from v1
  * add some acked-by
  * add description about rmap_one's return - Andrew

* from RFC
- http://lkml.kernel.org/r/1488436765-32350-1-git-send-email-minc...@kernel.org
  * Remove RFC tag
  * add acked-by to some patches
  * some of minor fixes
  * based on mmotm-2017-03-09-16-19.


Minchan Kim (10):
  mm: remove unncessary ret in page_referenced
  mm: remove SWAP_DIRTY in ttu
  mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu
  mm: make the try_to_munlock void function
  mm: remove SWAP_MLOCK in ttu
  mm: remove SWAP_AGAIN in ttu
  mm: make ttu's return boolean
  mm: make rmap_walk void function
  mm: make rmap_one boolean function
  mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

 include/linux/ksm.h  |  5 ++-
 include/linux/rmap.h | 25 ++
 mm/huge_memory.c |  6 ++--
 mm/ksm.c | 16 -
 mm/memory-failure.c  | 26 +++---
 mm/migrate.c |  4 +--
 mm/mlock.c   |  6 ++--
 mm/page_idle.c   |  4 +--
 mm/rmap.c| 98 
 mm/vmscan.c  | 32 +
 10 files changed, 85 insertions(+), 137 deletions(-)

-- 
2.7.4

[PATCH v2 09/10] mm: make rmap_one boolean function

[Minchan Kim]

rmap_one's return value controls whether rmap_work should contine to
scan other ptes or not so it's target for changing to boolean.
Return true if the scan should be continued. Otherwise, return false
to stop the scanning.

This patch makes rmap_one's return value to boolean.

Signed-off-by: Minchan Kim 
---
 include/linux/rmap.h |  6 +-
 mm/ksm.c |  2 +-
 mm/migrate.c |  4 ++--
 mm/page_idle.c   |  4 ++--
 mm/rmap.c| 30 +++---
 5 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 1d7d457c..13ed232 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -257,7 +257,11 @@ int page_mapped_in_vma(struct page *page, struct 
vm_area_struct *vma);
  */
 struct rmap_walk_control {
void *arg;
-   int (*rmap_one)(struct page *page, struct vm_area_struct *vma,
+   /*
+* Return false if page table scanning in rmap_walk should be stopped.
+* Otherwise, return true.
+*/
+   bool (*rmap_one)(struct page *page, struct vm_area_struct *vma,
unsigned long addr, void *arg);
int (*done)(struct page *page);
struct anon_vma *(*anon_lock)(struct page *page);
diff --git a/mm/ksm.c b/mm/ksm.c
index 6edffb9..d9fc0e4 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1977,7 +1977,7 @@ void rmap_walk_ksm(struct page *page, struct 
rmap_walk_control *rwc)
if (rwc->invalid_vma && rwc->invalid_vma(vma, rwc->arg))
continue;
 
-   if (SWAP_AGAIN != rwc->rmap_one(page, vma,
+   if (!rwc->rmap_one(page, vma,
rmap_item->address, rwc->arg)) {
anon_vma_unlock_read(anon_vma);
return;
diff --git a/mm/migrate.c b/mm/migrate.c
index e0cb4b7..8e9f1e8 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -194,7 +194,7 @@ void putback_movable_pages(struct list_head *l)
 /*
  * Restore a potential migration pte to a working pte entry
  */
-static int remove_migration_pte(struct page *page, struct vm_area_struct *vma,
+static bool remove_migration_pte(struct page *page, struct vm_area_struct *vma,
 unsigned long addr, void *old)
 {
struct page_vma_mapped_walk pvmw = {
@@ -250,7 +250,7 @@ static int remove_migration_pte(struct page *page, struct 
vm_area_struct *vma,
update_mmu_cache(vma, pvmw.address, pvmw.pte);
}
 
-   return SWAP_AGAIN;
+   return true;
 }
 
 /*
diff --git a/mm/page_idle.c b/mm/page_idle.c
index b0ee56c..1b0f48c 100644
--- a/mm/page_idle.c
+++ b/mm/page_idle.c
@@ -50,7 +50,7 @@ static struct page *page_idle_get_page(unsigned long pfn)
return page;
 }
 
-static int page_idle_clear_pte_refs_one(struct page *page,
+static bool page_idle_clear_pte_refs_one(struct page *page,
struct vm_area_struct *vma,
unsigned long addr, void *arg)
 {
@@ -84,7 +84,7 @@ static int page_idle_clear_pte_refs_one(struct page *page,
 */
set_page_young(page);
}
-   return SWAP_AGAIN;
+   return true;
 }
 
 static void page_idle_clear_pte_refs(struct page *page)
diff --git a/mm/rmap.c b/mm/rmap.c
index 987b0d2..aa25fde 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -719,7 +719,7 @@ struct page_referenced_arg {
 /*
  * arg: page_referenced_arg will be passed
  */
-static int page_referenced_one(struct page *page, struct vm_area_struct *vma,
+static bool page_referenced_one(struct page *page, struct vm_area_struct *vma,
unsigned long address, void *arg)
 {
struct page_referenced_arg *pra = arg;
@@ -736,7 +736,7 @@ static int page_referenced_one(struct page *page, struct 
vm_area_struct *vma,
if (vma->vm_flags & VM_LOCKED) {
page_vma_mapped_walk_done();
pra->vm_flags |= VM_LOCKED;
-   return SWAP_FAIL; /* To break the loop */
+   return false; /* To break the loop */
}
 
if (pvmw.pte) {
@@ -776,9 +776,9 @@ static int page_referenced_one(struct page *page, struct 
vm_area_struct *vma,
}
 
if (!pra->mapcount)
-   return SWAP_SUCCESS; /* To break the loop */
+   return false; /* To break the loop */
 
-   return SWAP_AGAIN;
+   return true;
 }
 
 static bool invalid_page_referenced_vma(struct vm_area_struct *vma, void *arg)
@@ -849,7 +849,7 @@ int page_referenced(struct page *page,
return pra.referenced;
 }
 
-static int page_mkclean_one(struct page *page, struct vm_area_struct *vma,
+static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma,
unsigned long address, void *arg)
 {
struct 

[PATCH v2 03/10] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

[Minchan Kim]

If the page is mapped and rescue in try_to_unmap_one,
page_mapcount(page) == 0 cannot be true so page_mapcount check
in try_to_unmap is enough to return SWAP_SUCCESS.
IOW, SWAP_MLOCK check is redundant so remove it.

Signed-off-by: Minchan Kim 
---
 mm/rmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index e692cb5..bdc7310 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1530,7 +1530,7 @@ int try_to_unmap(struct page *page, enum ttu_flags flags)
else
ret = rmap_walk(page, );
 
-   if (ret != SWAP_MLOCK && !page_mapcount(page))
+   if (!page_mapcount(page))
ret = SWAP_SUCCESS;
return ret;
 }
-- 
2.7.4

Re: [PATCH] doc: ABI: vdso: update parse_vdso.c reference

[Baruch Siach]

Hi Jonathan,

On Mon, Mar 13, 2017 at 05:13:38PM -0600, Jonathan Corbet wrote:
> On Wed,  8 Mar 2017 21:50:31 +0200
> Baruch Siach  wrote: 
> > Since commit f9b6b0ef603 ("selftests: move vDSO tests from 
> > Documentation/vDSO")
> > parse_vdso.c moved under selftests. Update the reference to match.
> 
> Applied to the docs tree, thanks.

Thanks.

Are you looking after Documentation/ABI/ as well? The MAINTAINERS 
documentation entry explicitly excludes Documentation/ABI/. I CCed you only 
because you acked f9b6b0ef603.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH] doc: ABI: vdso: update parse_vdso.c reference

[Baruch Siach]

Hi Jonathan,

On Mon, Mar 13, 2017 at 05:13:38PM -0600, Jonathan Corbet wrote:
> On Wed,  8 Mar 2017 21:50:31 +0200
> Baruch Siach  wrote: 
> > Since commit f9b6b0ef603 ("selftests: move vDSO tests from 
> > Documentation/vDSO")
> > parse_vdso.c moved under selftests. Update the reference to match.
> 
> Applied to the docs tree, thanks.

Thanks.

Are you looking after Documentation/ABI/ as well? The MAINTAINERS 
documentation entry explicitly excludes Documentation/ABI/. I CCed you only 
because you acked f9b6b0ef603.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

[Juergen Gross]

On 14/03/17 22:22, Stefano Stabellini wrote:
> Hi Juergen,
> 
> thank you for the review!
> 
> On Tue, 14 Mar 2017, Juergen Gross wrote:
>> On 14/03/17 00:50, Stefano Stabellini wrote:
>>> Implement functions to handle the xenbus handshake. Upon connection,
>>> allocate the rings according to the protocol specification.
>>>
>>> Initialize a work_struct and a wait_queue. The work_struct will be used
>>> to schedule work upon receiving an event channel notification from the
>>> backend. The wait_queue will be used to wait when the ring is full and
>>> we need to send a new request.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> CC: Eric Van Hensbergen 
>>> CC: Ron Minnich 
>>> CC: Latchesar Ionkov 
>>> CC: v9fs-develo...@lists.sourceforge.net
>>> ---

>> Did you think about using request_threaded_irq() instead of a workqueue?
>> For an example see e.g. drivers/scsi/xen-scsifront.c
> 
> I like workqueues :-)  It might come down to personal preferences, but I
> think workqueues are more flexible and a better fit for this use case.
> Not only it is easy to schedule work in a workqueue from the interrupt
> handler, but also they can be used for sleeping in the request function
> if there is not enough room on the ring. Besides, they can easily be
> configured to share a single thread or to have multiple independent
> threads.

I'm fine with the workqueues as long as you have decided to use them
considering the alternatives. :-)

>> Can't you use xenbus_read_unsigned() instead of xenbus_read()?
> 
> I can use xenbus_read_unsigned in the other cases below, but not here,
> because versions is in the form: "1,3,4"

Is this documented somewhere?

Hmm, are any of the Xenstore entries documented? Shouldn't this be done
in xen_9pfs.h ?


Juergen

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

[Juergen Gross]

On 14/03/17 22:22, Stefano Stabellini wrote:
> Hi Juergen,
> 
> thank you for the review!
> 
> On Tue, 14 Mar 2017, Juergen Gross wrote:
>> On 14/03/17 00:50, Stefano Stabellini wrote:
>>> Implement functions to handle the xenbus handshake. Upon connection,
>>> allocate the rings according to the protocol specification.
>>>
>>> Initialize a work_struct and a wait_queue. The work_struct will be used
>>> to schedule work upon receiving an event channel notification from the
>>> backend. The wait_queue will be used to wait when the ring is full and
>>> we need to send a new request.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> CC: Eric Van Hensbergen 
>>> CC: Ron Minnich 
>>> CC: Latchesar Ionkov 
>>> CC: v9fs-develo...@lists.sourceforge.net
>>> ---

>> Did you think about using request_threaded_irq() instead of a workqueue?
>> For an example see e.g. drivers/scsi/xen-scsifront.c
> 
> I like workqueues :-)  It might come down to personal preferences, but I
> think workqueues are more flexible and a better fit for this use case.
> Not only it is easy to schedule work in a workqueue from the interrupt
> handler, but also they can be used for sleeping in the request function
> if there is not enough room on the ring. Besides, they can easily be
> configured to share a single thread or to have multiple independent
> threads.

I'm fine with the workqueues as long as you have decided to use them
considering the alternatives. :-)

>> Can't you use xenbus_read_unsigned() instead of xenbus_read()?
> 
> I can use xenbus_read_unsigned in the other cases below, but not here,
> because versions is in the form: "1,3,4"

Is this documented somewhere?

Hmm, are any of the Xenstore entries documented? Shouldn't this be done
in xen_9pfs.h ?


Juergen

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

[Pushkar Jambhlekar]

Thanks. I will rewrite patch according to the suggestions.

On Tue, Mar 14, 2017 at 9:52 PM, Greg Kroah-Hartman
 wrote:
> On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote:
>> Description:
>
> No need for that line.
>
>> in file 'vc04_services/interface/vchiq_arm/vchiq_shim.c', making changes 
>> to make code according to 'checkpath.pl'.
>
> Why indent?  Also, you need to be specific as to what type of changes
> you made.
>
>> Also, fixing logical issue, i.e. removing break after goto statement.
>
> Don't do multiple things in the same patch, break it up into
> one-patch-per-thing, and no, "checkpatch.pl cleanups" is not "one
> thing" :)
>
> thanks,
>
> greg k-h



-- 
Jambhlekar Pushkar Arun
M.Tech IIT Roorkee

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

[Pushkar Jambhlekar]

Thanks. I will rewrite patch according to the suggestions.

On Tue, Mar 14, 2017 at 9:52 PM, Greg Kroah-Hartman
 wrote:
> On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote:
>> Description:
>
> No need for that line.
>
>> in file 'vc04_services/interface/vchiq_arm/vchiq_shim.c', making changes 
>> to make code according to 'checkpath.pl'.
>
> Why indent?  Also, you need to be specific as to what type of changes
> you made.
>
>> Also, fixing logical issue, i.e. removing break after goto statement.
>
> Don't do multiple things in the same patch, break it up into
> one-patch-per-thing, and no, "checkpatch.pl cleanups" is not "one
> thing" :)
>
> thanks,
>
> greg k-h



-- 
Jambhlekar Pushkar Arun
M.Tech IIT Roorkee

Re: net/sctp: recursive locking in sctp_do_peeloff

[Cong Wang]

On Fri, Mar 10, 2017 at 12:04 PM, Dmitry Vyukov  wrote:
> On Fri, Mar 10, 2017 at 8:46 PM, Marcelo Ricardo Leitner
>  wrote:
>> On Fri, Mar 10, 2017 at 4:11 PM, Dmitry Vyukov  wrote:
>>> Hello,
>>>
>>> I've got the following recursive locking report while running
>>> syzkaller fuzzer on net-next/9c28286b1b4b9bce6e35dd4c8a1265f03802a89a:
>>>
>>> [ INFO: possible recursive locking detected ]
>>> 4.10.0+ #14 Not tainted
>>> -
>>> syz-executor3/5560 is trying to acquire lock:
>>>  (sk_lock-AF_INET6){+.+.+.}, at: [] lock_sock
>>> include/net/sock.h:1460 [inline]
>>>  (sk_lock-AF_INET6){+.+.+.}, at: []
>>> sctp_close+0xcd/0x9d0 net/sctp/socket.c:1497
>>>
>>> but task is already holding lock:
>>>  (sk_lock-AF_INET6){+.+.+.}, at: [] lock_sock
>>> include/net/sock.h:1460 [inline]
>>>  (sk_lock-AF_INET6){+.+.+.}, at: []
>>> sctp_getsockopt+0x450/0x67e0 net/sctp/socket.c:6611
>>>
>>> other info that might help us debug this:
>>>  Possible unsafe locking scenario:
>>>
>>>CPU0
>>>
>>>   lock(sk_lock-AF_INET6);
>>>   lock(sk_lock-AF_INET6);
>>>
>>>  *** DEADLOCK ***
>>>
>>>  May be due to missing lock nesting notation
>>
>> Pretty much the case, I suppose. The lock held by sctp_getsockopt() is
>> on one socket, while the other lock that sctp_close() is getting later
>> is on the newly created (which failed) socket during peeloff
>> operation.
>
>
> Does this mean that never-ever lock 2 sockets at a time except for
> this case? If so, it probably suggests that this case should not do it
> either.
>

Yeah, actually for the error path we don't even need to lock sock
since it is newly allocated and no one else could see it yet.

Instead of checking for the status of the sock, I believe the following
one-line fix should do the trick too. Can you give it a try?

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 0f378ea..4de62d4 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1494,7 +1494,7 @@ static void sctp_close(struct sock *sk, long timeout)

pr_debug("%s: sk:%p, timeout:%ld\n", __func__, sk, timeout);

-   lock_sock(sk);
+   lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
sk->sk_shutdown = SHUTDOWN_MASK;
sk->sk_state = SCTP_SS_CLOSING;

Re: net/sctp: recursive locking in sctp_do_peeloff

[Cong Wang]

On Fri, Mar 10, 2017 at 12:04 PM, Dmitry Vyukov  wrote:
> On Fri, Mar 10, 2017 at 8:46 PM, Marcelo Ricardo Leitner
>  wrote:
>> On Fri, Mar 10, 2017 at 4:11 PM, Dmitry Vyukov  wrote:
>>> Hello,
>>>
>>> I've got the following recursive locking report while running
>>> syzkaller fuzzer on net-next/9c28286b1b4b9bce6e35dd4c8a1265f03802a89a:
>>>
>>> [ INFO: possible recursive locking detected ]
>>> 4.10.0+ #14 Not tainted
>>> -
>>> syz-executor3/5560 is trying to acquire lock:
>>>  (sk_lock-AF_INET6){+.+.+.}, at: [] lock_sock
>>> include/net/sock.h:1460 [inline]
>>>  (sk_lock-AF_INET6){+.+.+.}, at: []
>>> sctp_close+0xcd/0x9d0 net/sctp/socket.c:1497
>>>
>>> but task is already holding lock:
>>>  (sk_lock-AF_INET6){+.+.+.}, at: [] lock_sock
>>> include/net/sock.h:1460 [inline]
>>>  (sk_lock-AF_INET6){+.+.+.}, at: []
>>> sctp_getsockopt+0x450/0x67e0 net/sctp/socket.c:6611
>>>
>>> other info that might help us debug this:
>>>  Possible unsafe locking scenario:
>>>
>>>CPU0
>>>
>>>   lock(sk_lock-AF_INET6);
>>>   lock(sk_lock-AF_INET6);
>>>
>>>  *** DEADLOCK ***
>>>
>>>  May be due to missing lock nesting notation
>>
>> Pretty much the case, I suppose. The lock held by sctp_getsockopt() is
>> on one socket, while the other lock that sctp_close() is getting later
>> is on the newly created (which failed) socket during peeloff
>> operation.
>
>
> Does this mean that never-ever lock 2 sockets at a time except for
> this case? If so, it probably suggests that this case should not do it
> either.
>

Yeah, actually for the error path we don't even need to lock sock
since it is newly allocated and no one else could see it yet.

Instead of checking for the status of the sock, I believe the following
one-line fix should do the trick too. Can you give it a try?

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 0f378ea..4de62d4 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1494,7 +1494,7 @@ static void sctp_close(struct sock *sk, long timeout)

pr_debug("%s: sk:%p, timeout:%ld\n", __func__, sk, timeout);

-   lock_sock(sk);
+   lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
sk->sk_shutdown = SHUTDOWN_MASK;
sk->sk_state = SCTP_SS_CLOSING;

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

[Greg Kroah-Hartman]

On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote:
> Description:

No need for that line.

> in file 'vc04_services/interface/vchiq_arm/vchiq_shim.c', making changes 
> to make code according to 'checkpath.pl'.

Why indent?  Also, you need to be specific as to what type of changes
you made.

> Also, fixing logical issue, i.e. removing break after goto statement.

Don't do multiple things in the same patch, break it up into
one-patch-per-thing, and no, "checkpatch.pl cleanups" is not "one
thing" :)

thanks,

greg k-h

Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR

[Michael Kerrisk]

[CC += linux-...@vger.kernel.org]

Filip,

Since this is a kernel-user-space API change, please CC linux-api@
(and on future iterations of this patch). The kernel source file
Documentation/SubmitChecklist notes that all Linux kernel patches that
change userspace interfaces should be CCed to
linux-...@vger.kernel.org, so that the various parties who are
interested in API changes are informed. For further information, see
https://www.kernel.org/doc/man-pages/linux-api-ml.html

Thanks,

Michael



On Tue, Mar 14, 2017 at 12:02 AM, Filip Štědronský  wrote:
> Fanotify currently does not report directory modification events
> (rename, unlink, etc.). But these events are essential for about half of
> concievable fanotify use cases, especially:
>
>   - file system indexers / desktop search tools
>   - file synchronization tools (like Dropbox, Nextcloud, etc.),
> online backup tools
>
> and pretty much any app that needs to maintain and up-to-date internal
> representation of current contents of the file system.
>
> All applications of the above classes that I'm aware of currently use
> recursive inotify watches, which do not scale (my home dir has ~200k
> directories, creating all the watches takes ~2min and eats several tens
> of MB of kernel memory).
>
> There have been many calls for such a feature, pretty much since the
> creation of fanotify in 2009:
>   * By GNOME developers:
> https://wiki.gnome.org/BastienNocera/KernelWishlist#VFS.2C_filesystems
>   * By KDE developers:
> http://lkml.kernel.org/r/201211011352.42476.Martin%40lichtvoll.de
> 'Better support for (desktop) file search / indexing applications'
>   * And others:
> 
> http://lkml.kernel.org/r/AANLkTi=owK=WZW4oNtpm5WpAZhqCQUdTR2K5gzJ_MqZ+%40mail.gmail.com
> 'Fanotify mv/rename?'
> http://lkml.kernel.org/r/1238158043.23703.20.camel%40fatty
> 'Issues with using fanotify for a filesystem indexer'
>
> Add a new fanotify event, FAN_MODIFY_DIR, that is emitted whenever the
> contents of a directory change (a directory entry is added, removed or
> renamed). This covers all the currently missing events: rename, unlink,
> mknod, mkdir, rmdir, etc.
>
> Included with the event is a file descriptor to the modified directory
> but no further info. The userspace application is expected to rescan the
> whole directory and update its model accordingly. This needs to be done
> carefully to prevent race conditions. A cross-directory rename generates
> two FAN_MODIFY_DIR events.
>
> This minimalistic approach has several advantages:
>   * Does not require changes to the fanotify userspace API or the
> fsnotify in-kernel framework, apart from adding a new event.
> Especially doesn't complicate it by adding string fields.
>   * Has simple and clear semantics, even with multiple renames occurring
> in parallel etc. In case of any inconsistencies, one can simply wait
> for a while and rescan again.
>   * FAN_MODIFY_DIR events are easily merged in case of multiple
> operations on a directory (e.g. deleting all files).
>
> Signed-off-by: Filip Štědronský 
>
> ---
>
> An alternative might be to create wrapper functions like
> vfs_path_(rename|unlink|...). They could also take care of calling
> security_path_(rename|unlink|...), which is currently also up to
> the indvidual callers (possibly with a flag because it might not
> be always desired).
>
> An alternative was proposed by Amir Goldstein in several long series of
> patches that add superblock-scoped (as opposed to vfsmount-scoped)
> fanotify watches and specific dentry manipulation events with filenames:
>
> 
> http://lkml.kernel.org/r/1481984434-13293-1-git-send-email-amir73il%40gmail.com
> 
> http://lkml.kernel.org/r/1482247207-4424-1-git-send-email-amir73il%40gmail.com
> 
> http://lkml.kernel.org/r/1476126784-12520-1-git-send-email-amir73il%40gmail.com
> 
> http://lkml.kernel.org/r/1489411223-12081-1-git-send-email-amir73il%40gmail.com
>
> There is large but not complete overlap between that proposal and
> mine (which is was originally created over a year ago, before Amir's
> work, but never posted).
>
> I think the superblock watch idea is very interesting because it might
> in the future allow reporing fsnotify events from remote and virtual
> filesystems. So I'm posting this more as a potential source of more
> ideas for discussion, or a fallback proposal in case Amir's patches
> don't make it.
> ---
>  fs/notify/fanotify/fanotify.c|  1 +
>  include/linux/fsnotify.h | 17 +
>  include/linux/fsnotify_backend.h |  1 +
>  include/uapi/linux/fanotify.h|  5 -
>  4 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index bbc175d4213d..5178b06c338c 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -186,6 +186,7 @@ static int fanotify_handle_event(struct 

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

[Greg Kroah-Hartman]

On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote:
> Description:

No need for that line.

> in file 'vc04_services/interface/vchiq_arm/vchiq_shim.c', making changes 
> to make code according to 'checkpath.pl'.

Why indent?  Also, you need to be specific as to what type of changes
you made.

> Also, fixing logical issue, i.e. removing break after goto statement.

Don't do multiple things in the same patch, break it up into
one-patch-per-thing, and no, "checkpatch.pl cleanups" is not "one
thing" :)

thanks,

greg k-h

Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR

[Michael Kerrisk]

[CC += linux-...@vger.kernel.org]

Filip,

Since this is a kernel-user-space API change, please CC linux-api@
(and on future iterations of this patch). The kernel source file
Documentation/SubmitChecklist notes that all Linux kernel patches that
change userspace interfaces should be CCed to
linux-...@vger.kernel.org, so that the various parties who are
interested in API changes are informed. For further information, see
https://www.kernel.org/doc/man-pages/linux-api-ml.html

Thanks,

Michael



On Tue, Mar 14, 2017 at 12:02 AM, Filip Štědronský  wrote:
> Fanotify currently does not report directory modification events
> (rename, unlink, etc.). But these events are essential for about half of
> concievable fanotify use cases, especially:
>
>   - file system indexers / desktop search tools
>   - file synchronization tools (like Dropbox, Nextcloud, etc.),
> online backup tools
>
> and pretty much any app that needs to maintain and up-to-date internal
> representation of current contents of the file system.
>
> All applications of the above classes that I'm aware of currently use
> recursive inotify watches, which do not scale (my home dir has ~200k
> directories, creating all the watches takes ~2min and eats several tens
> of MB of kernel memory).
>
> There have been many calls for such a feature, pretty much since the
> creation of fanotify in 2009:
>   * By GNOME developers:
> https://wiki.gnome.org/BastienNocera/KernelWishlist#VFS.2C_filesystems
>   * By KDE developers:
> http://lkml.kernel.org/r/201211011352.42476.Martin%40lichtvoll.de
> 'Better support for (desktop) file search / indexing applications'
>   * And others:
> 
> http://lkml.kernel.org/r/AANLkTi=owK=WZW4oNtpm5WpAZhqCQUdTR2K5gzJ_MqZ+%40mail.gmail.com
> 'Fanotify mv/rename?'
> http://lkml.kernel.org/r/1238158043.23703.20.camel%40fatty
> 'Issues with using fanotify for a filesystem indexer'
>
> Add a new fanotify event, FAN_MODIFY_DIR, that is emitted whenever the
> contents of a directory change (a directory entry is added, removed or
> renamed). This covers all the currently missing events: rename, unlink,
> mknod, mkdir, rmdir, etc.
>
> Included with the event is a file descriptor to the modified directory
> but no further info. The userspace application is expected to rescan the
> whole directory and update its model accordingly. This needs to be done
> carefully to prevent race conditions. A cross-directory rename generates
> two FAN_MODIFY_DIR events.
>
> This minimalistic approach has several advantages:
>   * Does not require changes to the fanotify userspace API or the
> fsnotify in-kernel framework, apart from adding a new event.
> Especially doesn't complicate it by adding string fields.
>   * Has simple and clear semantics, even with multiple renames occurring
> in parallel etc. In case of any inconsistencies, one can simply wait
> for a while and rescan again.
>   * FAN_MODIFY_DIR events are easily merged in case of multiple
> operations on a directory (e.g. deleting all files).
>
> Signed-off-by: Filip Štědronský 
>
> ---
>
> An alternative might be to create wrapper functions like
> vfs_path_(rename|unlink|...). They could also take care of calling
> security_path_(rename|unlink|...), which is currently also up to
> the indvidual callers (possibly with a flag because it might not
> be always desired).
>
> An alternative was proposed by Amir Goldstein in several long series of
> patches that add superblock-scoped (as opposed to vfsmount-scoped)
> fanotify watches and specific dentry manipulation events with filenames:
>
> 
> http://lkml.kernel.org/r/1481984434-13293-1-git-send-email-amir73il%40gmail.com
> 
> http://lkml.kernel.org/r/1482247207-4424-1-git-send-email-amir73il%40gmail.com
> 
> http://lkml.kernel.org/r/1476126784-12520-1-git-send-email-amir73il%40gmail.com
> 
> http://lkml.kernel.org/r/1489411223-12081-1-git-send-email-amir73il%40gmail.com
>
> There is large but not complete overlap between that proposal and
> mine (which is was originally created over a year ago, before Amir's
> work, but never posted).
>
> I think the superblock watch idea is very interesting because it might
> in the future allow reporing fsnotify events from remote and virtual
> filesystems. So I'm posting this more as a potential source of more
> ideas for discussion, or a fallback proposal in case Amir's patches
> don't make it.
> ---
>  fs/notify/fanotify/fanotify.c|  1 +
>  include/linux/fsnotify.h | 17 +
>  include/linux/fsnotify_backend.h |  1 +
>  include/uapi/linux/fanotify.h|  5 -
>  4 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index bbc175d4213d..5178b06c338c 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -186,6 +186,7 @@ static int fanotify_handle_event(struct fsnotify_group 
> *group,
>
> 

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

[Inki Dae]

Merged.

Thanks,
Inki Dae

2017년 03월 15일 03:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> Printing raw kernel pointers might reveal information which sometimes we
> try to hide (e.g. with Kernel Address Space Layout Randomization).  Use
> the "%pK" format so these pointers will be hidden for unprivileged
> users.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 22 +++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  2 +-
>  6 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 812e2ec0761d..202526b20b64 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -979,7 +979,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   bool first = !xfer->tx_done;
>   u32 reg;
>  
> - dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> + dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
>   xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>  
>   if (length > DSI_TX_FIFO_SIZE)
> @@ -1177,7 +1177,7 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
>   spin_unlock_irqrestore(>transfer_lock, flags);
>  
>   dev_dbg(dsi->dev,
> - "> xfer %p, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
> + "> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
>   xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
>   xfer->rx_done);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 95871577015d..5b18b5c5fdf2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1695,7 +1695,7 @@ static int fimc_probe(struct platform_device *pdev)
>   goto err_put_clk;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   spin_lock_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c28f7ffcc4d..55a1579d11b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -218,7 +218,7 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct 
> drm_device *dev,
>   return ERR_PTR(ret);
>   }
>  
> - DRM_DEBUG_KMS("created file object = %p\n", obj->filp);
> + DRM_DEBUG_KMS("created file object = %pK\n", obj->filp);
>  
>   return exynos_gem;
>  }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index bef57987759d..0506b2b17ac1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1723,7 +1723,7 @@ static int gsc_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   mutex_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 9c84ee76f18a..3edda18cc2d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -208,7 +208,7 @@ static struct exynos_drm_ippdrv 
> *ipp_find_drv_by_handle(u32 prop_id)
>* e.g PAUSE state, queue buf, command control.
>*/
>   list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
> - DRM_DEBUG_KMS("count[%d]ippdrv[%p]\n", count++, ippdrv);
> + DRM_DEBUG_KMS("count[%d]ippdrv[%pK]\n", count++, ippdrv);
>  
>   mutex_lock(>cmd_lock);
>   list_for_each_entry(c_node, >cmd_list, list) {
> @@ -388,7 +388,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
> *drm_dev, void *data,
>   }
>   property->prop_id = ret;
>  
> - DRM_DEBUG_KMS("created prop_id[%d]cmd[%d]ippdrv[%p]\n",
> + DRM_DEBUG_KMS("created prop_id[%d]cmd[%d]ippdrv[%pK]\n",
>   property->prop_id, property->cmd, ippdrv);
>  
>   /* stored property information and ippdrv in private data */
> @@ -518,7 +518,7 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
>  {
>   int i;
>  
> - DRM_DEBUG_KMS("node[%p]\n", m_node);
> + DRM_DEBUG_KMS("node[%pK]\n", m_node);
>  
>   if (!m_node) {
>   DRM_ERROR("invalid dequeue node.\n");
> @@ -562,7 +562,7 @@ static struct 

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

[Inki Dae]

Merged.

Thanks,
Inki Dae

2017년 03월 15일 03:38에 Krzysztof Kozlowski 이(가) 쓴 글:
> Printing raw kernel pointers might reveal information which sometimes we
> try to hide (e.g. with Kernel Address Space Layout Randomization).  Use
> the "%pK" format so these pointers will be hidden for unprivileged
> users.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 22 +++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  2 +-
>  6 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 812e2ec0761d..202526b20b64 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -979,7 +979,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   bool first = !xfer->tx_done;
>   u32 reg;
>  
> - dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> + dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
>   xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>  
>   if (length > DSI_TX_FIFO_SIZE)
> @@ -1177,7 +1177,7 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
>   spin_unlock_irqrestore(>transfer_lock, flags);
>  
>   dev_dbg(dsi->dev,
> - "> xfer %p, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
> + "> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
>   xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
>   xfer->rx_done);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 95871577015d..5b18b5c5fdf2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1695,7 +1695,7 @@ static int fimc_probe(struct platform_device *pdev)
>   goto err_put_clk;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   spin_lock_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c28f7ffcc4d..55a1579d11b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -218,7 +218,7 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct 
> drm_device *dev,
>   return ERR_PTR(ret);
>   }
>  
> - DRM_DEBUG_KMS("created file object = %p\n", obj->filp);
> + DRM_DEBUG_KMS("created file object = %pK\n", obj->filp);
>  
>   return exynos_gem;
>  }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index bef57987759d..0506b2b17ac1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1723,7 +1723,7 @@ static int gsc_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
> + DRM_DEBUG_KMS("id[%d]ippdrv[%pK]\n", ctx->id, ippdrv);
>  
>   mutex_init(>lock);
>   platform_set_drvdata(pdev, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 9c84ee76f18a..3edda18cc2d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -208,7 +208,7 @@ static struct exynos_drm_ippdrv 
> *ipp_find_drv_by_handle(u32 prop_id)
>* e.g PAUSE state, queue buf, command control.
>*/
>   list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
> - DRM_DEBUG_KMS("count[%d]ippdrv[%p]\n", count++, ippdrv);
> + DRM_DEBUG_KMS("count[%d]ippdrv[%pK]\n", count++, ippdrv);
>  
>   mutex_lock(>cmd_lock);
>   list_for_each_entry(c_node, >cmd_list, list) {
> @@ -388,7 +388,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
> *drm_dev, void *data,
>   }
>   property->prop_id = ret;
>  
> - DRM_DEBUG_KMS("created prop_id[%d]cmd[%d]ippdrv[%p]\n",
> + DRM_DEBUG_KMS("created prop_id[%d]cmd[%d]ippdrv[%pK]\n",
>   property->prop_id, property->cmd, ippdrv);
>  
>   /* stored property information and ippdrv in private data */
> @@ -518,7 +518,7 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
>  {
>   int i;
>  
> - DRM_DEBUG_KMS("node[%p]\n", m_node);
> + DRM_DEBUG_KMS("node[%pK]\n", m_node);
>  
>   if (!m_node) {
>   DRM_ERROR("invalid dequeue node.\n");
> @@ -562,7 +562,7 @@ static struct drm_exynos_ipp_mem_node
>   

[PATCH v2 02/17] iio: mlx96014: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/temperature/mlx90614.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/temperature/mlx90614.c 
b/drivers/iio/temperature/mlx90614.c
index 4b645fc672aa..2077eef4095c 100644
--- a/drivers/iio/temperature/mlx90614.c
+++ b/drivers/iio/temperature/mlx90614.c
@@ -585,6 +585,12 @@ static const struct i2c_device_id mlx90614_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mlx90614_id);
 
+static const struct of_device_id mlx90614_of_match[] = {
+   { .compatible = "melexis,mlx90614" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mlx90614_of_match);
+
 #ifdef CONFIG_PM_SLEEP
 static int mlx90614_pm_suspend(struct device *dev)
 {
@@ -644,6 +650,7 @@ static const struct dev_pm_ops mlx90614_pm_ops = {
 static struct i2c_driver mlx90614_driver = {
.driver = {
.name   = "mlx90614",
+   .of_match_table = mlx90614_of_match,
.pm = _pm_ops,
},
.probe = mlx90614_probe,
-- 
2.9.3

[PATCH v2 02/17] iio: mlx96014: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/temperature/mlx90614.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/temperature/mlx90614.c 
b/drivers/iio/temperature/mlx90614.c
index 4b645fc672aa..2077eef4095c 100644
--- a/drivers/iio/temperature/mlx90614.c
+++ b/drivers/iio/temperature/mlx90614.c
@@ -585,6 +585,12 @@ static const struct i2c_device_id mlx90614_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mlx90614_id);
 
+static const struct of_device_id mlx90614_of_match[] = {
+   { .compatible = "melexis,mlx90614" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mlx90614_of_match);
+
 #ifdef CONFIG_PM_SLEEP
 static int mlx90614_pm_suspend(struct device *dev)
 {
@@ -644,6 +650,7 @@ static const struct dev_pm_ops mlx90614_pm_ops = {
 static struct i2c_driver mlx90614_driver = {
.driver = {
.name   = "mlx90614",
+   .of_match_table = mlx90614_of_match,
.pm = _pm_ops,
},
.probe = mlx90614_probe,
-- 
2.9.3

[PATCH v2 06/17] iio: light: tsl2563: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/light/tsl2563.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/iio/light/tsl2563.c b/drivers/iio/light/tsl2563.c
index 04598ae993d4..e7d4ea75e007 100644
--- a/drivers/iio/light/tsl2563.c
+++ b/drivers/iio/light/tsl2563.c
@@ -884,9 +884,19 @@ static const struct i2c_device_id tsl2563_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, tsl2563_id);
 
+static const struct of_device_id tsl2563_of_match[] = {
+   { .compatible = "amstaos,tsl2560" },
+   { .compatible = "amstaos,tsl2561" },
+   { .compatible = "amstaos,tsl2562" },
+   { .compatible = "amstaos,tsl2563" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, tsl2563_of_match);
+
 static struct i2c_driver tsl2563_i2c_driver = {
.driver = {
.name= "tsl2563",
+   .of_match_table = tsl2563_of_match,
.pm = TSL2563_PM_OPS,
},
.probe  = tsl2563_probe,
-- 
2.9.3

[PATCH v2 03/17] iio: magnetometer: bmc150_magn_i2c: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/magnetometer/bmc150_magn_i2c.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/iio/magnetometer/bmc150_magn_i2c.c 
b/drivers/iio/magnetometer/bmc150_magn_i2c.c
index ee05722587aa..57e40dd1222e 100644
--- a/drivers/iio/magnetometer/bmc150_magn_i2c.c
+++ b/drivers/iio/magnetometer/bmc150_magn_i2c.c
@@ -63,9 +63,18 @@ static const struct i2c_device_id bmc150_magn_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, bmc150_magn_i2c_id);
 
+static const struct of_device_id bmc150_magn_of_match[] = {
+   { .compatible = "bosch,bmc150_magn" },
+   { .compatible = "bosch,bmc156_magn" },
+   { .compatible = "bosch,bmm150_magn" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, bmc150_magn_of_match);
+
 static struct i2c_driver bmc150_magn_driver = {
.driver = {
.name   = "bmc150_magn_i2c",
+   .of_match_table = bmc150_magn_of_match,
.acpi_match_table = ACPI_PTR(bmc150_magn_acpi_match),
.pm = _magn_pm_ops,
},
-- 
2.9.3

[PATCH v2 06/17] iio: light: tsl2563: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/light/tsl2563.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/iio/light/tsl2563.c b/drivers/iio/light/tsl2563.c
index 04598ae993d4..e7d4ea75e007 100644
--- a/drivers/iio/light/tsl2563.c
+++ b/drivers/iio/light/tsl2563.c
@@ -884,9 +884,19 @@ static const struct i2c_device_id tsl2563_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, tsl2563_id);
 
+static const struct of_device_id tsl2563_of_match[] = {
+   { .compatible = "amstaos,tsl2560" },
+   { .compatible = "amstaos,tsl2561" },
+   { .compatible = "amstaos,tsl2562" },
+   { .compatible = "amstaos,tsl2563" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, tsl2563_of_match);
+
 static struct i2c_driver tsl2563_i2c_driver = {
.driver = {
.name= "tsl2563",
+   .of_match_table = tsl2563_of_match,
.pm = TSL2563_PM_OPS,
},
.probe  = tsl2563_probe,
-- 
2.9.3

[PATCH v2 03/17] iio: magnetometer: bmc150_magn_i2c: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/magnetometer/bmc150_magn_i2c.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/iio/magnetometer/bmc150_magn_i2c.c 
b/drivers/iio/magnetometer/bmc150_magn_i2c.c
index ee05722587aa..57e40dd1222e 100644
--- a/drivers/iio/magnetometer/bmc150_magn_i2c.c
+++ b/drivers/iio/magnetometer/bmc150_magn_i2c.c
@@ -63,9 +63,18 @@ static const struct i2c_device_id bmc150_magn_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, bmc150_magn_i2c_id);
 
+static const struct of_device_id bmc150_magn_of_match[] = {
+   { .compatible = "bosch,bmc150_magn" },
+   { .compatible = "bosch,bmc156_magn" },
+   { .compatible = "bosch,bmm150_magn" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, bmc150_magn_of_match);
+
 static struct i2c_driver bmc150_magn_driver = {
.driver = {
.name   = "bmc150_magn_i2c",
+   .of_match_table = bmc150_magn_of_match,
.acpi_match_table = ACPI_PTR(bmc150_magn_acpi_match),
.pm = _magn_pm_ops,
},
-- 
2.9.3

[PATCH v2 08/17] iio: imu: inv_mpu6050: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 38 +++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index 2c3f8964a3ea..a8e6330cb906 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "inv_mpu_iio.h"
 
 static const struct regmap_config inv_mpu_regmap_config = {
@@ -69,7 +70,8 @@ static int inv_mpu6050_deselect_bypass(struct i2c_mux_core 
*muxc, u32 chan_id)
return 0;
 }
 
-static const char *inv_mpu_match_acpi_device(struct device *dev, int *chip_id)
+static const char *inv_mpu_match_acpi_device(struct device *dev,
+enum inv_devices *chip_id)
 {
const struct acpi_device_id *id;
 
@@ -93,7 +95,8 @@ static int inv_mpu_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
struct inv_mpu6050_state *st;
-   int result, chip_type;
+   int result;
+   enum inv_devices chip_type;
struct regmap *regmap;
const char *name;
 
@@ -101,8 +104,13 @@ static int inv_mpu_probe(struct i2c_client *client,
 I2C_FUNC_SMBUS_I2C_BLOCK))
return -EOPNOTSUPP;
 
-   if (id) {
-   chip_type = (int)id->driver_data;
+   if (client->dev.of_node) {
+   chip_type = (enum inv_devices)
+   of_device_get_match_data(>dev);
+   name = client->name;
+   } else if (id) {
+   chip_type = (enum inv_devices)
+   id->driver_data;
name = id->name;
} else if (ACPI_HANDLE(>dev)) {
name = inv_mpu_match_acpi_device(>dev, _type);
@@ -176,6 +184,27 @@ static const struct i2c_device_id inv_mpu_id[] = {
 
 MODULE_DEVICE_TABLE(i2c, inv_mpu_id);
 
+static const struct of_device_id inv_of_match[] = {
+   {
+   .compatible = "invensense,mpu6050",
+   .data = (void *)INV_MPU6050
+   },
+   {
+   .compatible = "invensense,mpu6500",
+   .data = (void *)INV_MPU6500
+   },
+   {
+   .compatible = "invensense,mpu9150",
+   .data = (void *)INV_MPU9150
+   },
+   {
+   .compatible = "invensense,icm20608",
+   .data = (void *)INV_ICM20608
+   },
+   { }
+};
+MODULE_DEVICE_TABLE(of, inv_of_match);
+
 static const struct acpi_device_id inv_acpi_match[] = {
{"INVN6500", INV_MPU6500},
{ },
@@ -188,6 +217,7 @@ static struct i2c_driver inv_mpu_driver = {
.remove =   inv_mpu_remove,
.id_table   =   inv_mpu_id,
.driver = {
+   .of_match_table = inv_of_match,
.acpi_match_table = ACPI_PTR(inv_acpi_match),
.name   =   "inv-mpu6050-i2c",
.pm =   _mpu_pmops,
-- 
2.9.3

[PATCH v2 08/17] iio: imu: inv_mpu6050: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 38 +++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index 2c3f8964a3ea..a8e6330cb906 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "inv_mpu_iio.h"
 
 static const struct regmap_config inv_mpu_regmap_config = {
@@ -69,7 +70,8 @@ static int inv_mpu6050_deselect_bypass(struct i2c_mux_core 
*muxc, u32 chan_id)
return 0;
 }
 
-static const char *inv_mpu_match_acpi_device(struct device *dev, int *chip_id)
+static const char *inv_mpu_match_acpi_device(struct device *dev,
+enum inv_devices *chip_id)
 {
const struct acpi_device_id *id;
 
@@ -93,7 +95,8 @@ static int inv_mpu_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
struct inv_mpu6050_state *st;
-   int result, chip_type;
+   int result;
+   enum inv_devices chip_type;
struct regmap *regmap;
const char *name;
 
@@ -101,8 +104,13 @@ static int inv_mpu_probe(struct i2c_client *client,
 I2C_FUNC_SMBUS_I2C_BLOCK))
return -EOPNOTSUPP;
 
-   if (id) {
-   chip_type = (int)id->driver_data;
+   if (client->dev.of_node) {
+   chip_type = (enum inv_devices)
+   of_device_get_match_data(>dev);
+   name = client->name;
+   } else if (id) {
+   chip_type = (enum inv_devices)
+   id->driver_data;
name = id->name;
} else if (ACPI_HANDLE(>dev)) {
name = inv_mpu_match_acpi_device(>dev, _type);
@@ -176,6 +184,27 @@ static const struct i2c_device_id inv_mpu_id[] = {
 
 MODULE_DEVICE_TABLE(i2c, inv_mpu_id);
 
+static const struct of_device_id inv_of_match[] = {
+   {
+   .compatible = "invensense,mpu6050",
+   .data = (void *)INV_MPU6050
+   },
+   {
+   .compatible = "invensense,mpu6500",
+   .data = (void *)INV_MPU6500
+   },
+   {
+   .compatible = "invensense,mpu9150",
+   .data = (void *)INV_MPU9150
+   },
+   {
+   .compatible = "invensense,icm20608",
+   .data = (void *)INV_ICM20608
+   },
+   { }
+};
+MODULE_DEVICE_TABLE(of, inv_of_match);
+
 static const struct acpi_device_id inv_acpi_match[] = {
{"INVN6500", INV_MPU6500},
{ },
@@ -188,6 +217,7 @@ static struct i2c_driver inv_mpu_driver = {
.remove =   inv_mpu_remove,
.id_table   =   inv_mpu_id,
.driver = {
+   .of_match_table = inv_of_match,
.acpi_match_table = ACPI_PTR(inv_acpi_match),
.name   =   "inv-mpu6050-i2c",
.pm =   _mpu_pmops,
-- 
2.9.3

[PATCH v2 07/17] iio: pressure: hp03: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/pressure/hp03.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/pressure/hp03.c b/drivers/iio/pressure/hp03.c
index ac76515d5d49..8c7b3ec3d84a 100644
--- a/drivers/iio/pressure/hp03.c
+++ b/drivers/iio/pressure/hp03.c
@@ -297,9 +297,16 @@ static const struct i2c_device_id hp03_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, hp03_id);
 
+static const struct of_device_id hp03_of_match[] = {
+   { .compatible = "hoperf,hp03" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, hp03_of_match);
+
 static struct i2c_driver hp03_driver = {
.driver = {
.name   = "hp03",
+   .of_match_table = hp03_of_match,
},
.probe  = hp03_probe,
.remove = hp03_remove,
-- 
2.9.3

[PATCH v2 07/17] iio: pressure: hp03: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/pressure/hp03.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/pressure/hp03.c b/drivers/iio/pressure/hp03.c
index ac76515d5d49..8c7b3ec3d84a 100644
--- a/drivers/iio/pressure/hp03.c
+++ b/drivers/iio/pressure/hp03.c
@@ -297,9 +297,16 @@ static const struct i2c_device_id hp03_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, hp03_id);
 
+static const struct of_device_id hp03_of_match[] = {
+   { .compatible = "hoperf,hp03" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, hp03_of_match);
+
 static struct i2c_driver hp03_driver = {
.driver = {
.name   = "hp03",
+   .of_match_table = hp03_of_match,
},
.probe  = hp03_probe,
.remove = hp03_remove,
-- 
2.9.3

[PATCH v2 14/17] iio: accel: mma7455_i2c: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/accel/mma7455_i2c.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iio/accel/mma7455_i2c.c b/drivers/iio/accel/mma7455_i2c.c
index 3cab5fb4a3c4..73bf81a8ab14 100644
--- a/drivers/iio/accel/mma7455_i2c.c
+++ b/drivers/iio/accel/mma7455_i2c.c
@@ -41,12 +41,20 @@ static const struct i2c_device_id mma7455_i2c_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mma7455_i2c_ids);
 
+static const struct of_device_id mma7455_of_match[] = {
+   { .compatible = "fsl,mma7455" },
+   { .compatible = "fsl,mma7456" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mma7455_of_match);
+
 static struct i2c_driver mma7455_i2c_driver = {
.probe = mma7455_i2c_probe,
.remove = mma7455_i2c_remove,
.id_table = mma7455_i2c_ids,
.driver = {
.name   = "mma7455-i2c",
+   .of_match_table = mma7455_of_match,
},
 };
 module_i2c_driver(mma7455_i2c_driver);
-- 
2.9.3

[PATCH v2 17/17] iio: gyro: itg3200: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/iio/gyro/itg3200_core.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_core.c
index c102a6325bb0..cfa2db04a8ab 100644
--- a/drivers/iio/gyro/itg3200_core.c
+++ b/drivers/iio/gyro/itg3200_core.c
@@ -377,9 +377,16 @@ static const struct i2c_device_id itg3200_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, itg3200_id);
 
+static const struct of_device_id itg3200_of_match[] = {
+   { .compatible = "invensense,itg3200" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, itg3200_of_match);
+
 static struct i2c_driver itg3200_driver = {
.driver = {
.name   = "itg3200",
+   .of_match_table = itg3200_of_match,
.pm = _pm_ops,
},
.id_table   = itg3200_id,
-- 
2.9.3

[PATCH v2 16/17] iio: accel: mma7660: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/accel/mma7660.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/accel/mma7660.c b/drivers/iio/accel/mma7660.c
index 3a40774cca74..42fa57e41bdd 100644
--- a/drivers/iio/accel/mma7660.c
+++ b/drivers/iio/accel/mma7660.c
@@ -253,6 +253,12 @@ static const struct i2c_device_id mma7660_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mma7660_i2c_id);
 
+static const struct of_device_id mma7660_of_match[] = {
+   { .compatible = "fsl,mma7660" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mma7660_of_match);
+
 static const struct acpi_device_id mma7660_acpi_id[] = {
{"MMA7660", 0},
{}
@@ -264,6 +270,7 @@ static struct i2c_driver mma7660_driver = {
.driver = {
.name = "mma7660",
.pm = MMA7660_PM_OPS,
+   .of_match_table = mma7660_of_match,
.acpi_match_table = ACPI_PTR(mma7660_acpi_id),
},
.probe  = mma7660_probe,
-- 
2.9.3

[PATCH v2 14/17] iio: accel: mma7455_i2c: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/accel/mma7455_i2c.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iio/accel/mma7455_i2c.c b/drivers/iio/accel/mma7455_i2c.c
index 3cab5fb4a3c4..73bf81a8ab14 100644
--- a/drivers/iio/accel/mma7455_i2c.c
+++ b/drivers/iio/accel/mma7455_i2c.c
@@ -41,12 +41,20 @@ static const struct i2c_device_id mma7455_i2c_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mma7455_i2c_ids);
 
+static const struct of_device_id mma7455_of_match[] = {
+   { .compatible = "fsl,mma7455" },
+   { .compatible = "fsl,mma7456" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mma7455_of_match);
+
 static struct i2c_driver mma7455_i2c_driver = {
.probe = mma7455_i2c_probe,
.remove = mma7455_i2c_remove,
.id_table = mma7455_i2c_ids,
.driver = {
.name   = "mma7455-i2c",
+   .of_match_table = mma7455_of_match,
},
 };
 module_i2c_driver(mma7455_i2c_driver);
-- 
2.9.3

[PATCH v2 17/17] iio: gyro: itg3200: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/iio/gyro/itg3200_core.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_core.c
index c102a6325bb0..cfa2db04a8ab 100644
--- a/drivers/iio/gyro/itg3200_core.c
+++ b/drivers/iio/gyro/itg3200_core.c
@@ -377,9 +377,16 @@ static const struct i2c_device_id itg3200_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, itg3200_id);
 
+static const struct of_device_id itg3200_of_match[] = {
+   { .compatible = "invensense,itg3200" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, itg3200_of_match);
+
 static struct i2c_driver itg3200_driver = {
.driver = {
.name   = "itg3200",
+   .of_match_table = itg3200_of_match,
.pm = _pm_ops,
},
.id_table   = itg3200_id,
-- 
2.9.3

[PATCH v2 16/17] iio: accel: mma7660: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/accel/mma7660.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/accel/mma7660.c b/drivers/iio/accel/mma7660.c
index 3a40774cca74..42fa57e41bdd 100644
--- a/drivers/iio/accel/mma7660.c
+++ b/drivers/iio/accel/mma7660.c
@@ -253,6 +253,12 @@ static const struct i2c_device_id mma7660_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mma7660_i2c_id);
 
+static const struct of_device_id mma7660_of_match[] = {
+   { .compatible = "fsl,mma7660" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mma7660_of_match);
+
 static const struct acpi_device_id mma7660_acpi_id[] = {
{"MMA7660", 0},
{}
@@ -264,6 +270,7 @@ static struct i2c_driver mma7660_driver = {
.driver = {
.name = "mma7660",
.pm = MMA7660_PM_OPS,
+   .of_match_table = mma7660_of_match,
.acpi_match_table = ACPI_PTR(mma7660_acpi_id),
},
.probe  = mma7660_probe,
-- 
2.9.3

[PATCH v2 10/17] iio: light: apds9960: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/light/apds9960.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
index a4304edc3e0f..90bc98df362b 100644
--- a/drivers/iio/light/apds9960.c
+++ b/drivers/iio/light/apds9960.c
@@ -1122,9 +1122,16 @@ static const struct i2c_device_id apds9960_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, apds9960_id);
 
+static const struct of_device_id apds9960_of_match[] = {
+   { .compatible = "avago,apds9960" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, apds9960_of_match);
+
 static struct i2c_driver apds9960_driver = {
.driver = {
.name   = APDS9960_DRV_NAME,
+   .of_match_table = apds9960_of_match,
.pm = _pm_ops,
},
.probe  = apds9960_probe,
-- 
2.9.3

[PATCH v2 10/17] iio: light: apds9960: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/light/apds9960.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
index a4304edc3e0f..90bc98df362b 100644
--- a/drivers/iio/light/apds9960.c
+++ b/drivers/iio/light/apds9960.c
@@ -1122,9 +1122,16 @@ static const struct i2c_device_id apds9960_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, apds9960_id);
 
+static const struct of_device_id apds9960_of_match[] = {
+   { .compatible = "avago,apds9960" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, apds9960_of_match);
+
 static struct i2c_driver apds9960_driver = {
.driver = {
.name   = APDS9960_DRV_NAME,
+   .of_match_table = apds9960_of_match,
.pm = _pm_ops,
},
.probe  = apds9960_probe,
-- 
2.9.3

[PATCH v2 13/17] iio: magnetometer: mag3110: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/magnetometer/mag3110.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/magnetometer/mag3110.c 
b/drivers/iio/magnetometer/mag3110.c
index b4f643fb3b1e..dad8d57f7402 100644
--- a/drivers/iio/magnetometer/mag3110.c
+++ b/drivers/iio/magnetometer/mag3110.c
@@ -441,9 +441,16 @@ static const struct i2c_device_id mag3110_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mag3110_id);
 
+static const struct of_device_id mag3110_of_match[] = {
+   { .compatible = "fsl,mag3110" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mag3110_of_match);
+
 static struct i2c_driver mag3110_driver = {
.driver = {
.name   = "mag3110",
+   .of_match_table = mag3110_of_match,
.pm = MAG3110_PM_OPS,
},
.probe = mag3110_probe,
-- 
2.9.3

[PATCH v2 11/17] iio: dac: max5821: Set .of_match_table to OF device ID table

[Javier Martinez Canillas]

The driver has a OF device ID table but the struct i2c_driver
.of_match_table field is not set.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/dac/max5821.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/dac/max5821.c b/drivers/iio/dac/max5821.c
index 86e9e112f554..193fac3059a3 100644
--- a/drivers/iio/dac/max5821.c
+++ b/drivers/iio/dac/max5821.c
@@ -392,6 +392,7 @@ MODULE_DEVICE_TABLE(of, max5821_of_match);
 static struct i2c_driver max5821_driver = {
.driver = {
.name   = "max5821",
+   .of_match_table = max5821_of_match,
.pm = MAX5821_PM_OPS,
},
.probe  = max5821_probe,
-- 
2.9.3

[PATCH v2 12/17] iio: adc: ti-ads1015: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/adc/ti-ads1015.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
index 422b314f5a3f..f76d979fb7e8 100644
--- a/drivers/iio/adc/ti-ads1015.c
+++ b/drivers/iio/adc/ti-ads1015.c
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -55,7 +56,7 @@
 #define ADS1015_DEFAULT_DATA_RATE  4
 #define ADS1015_DEFAULT_CHAN   0
 
-enum {
+enum chip_ids {
ADS1015,
ADS1115,
 };
@@ -578,6 +579,7 @@ static int ads1015_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
struct ads1015_data *data;
int ret;
+   enum chip_ids chip;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
if (!indio_dev)
@@ -593,7 +595,11 @@ static int ads1015_probe(struct i2c_client *client,
indio_dev->name = ADS1015_DRV_NAME;
indio_dev->modes = INDIO_DIRECT_MODE;
 
-   switch (id->driver_data) {
+   if (client->dev.of_node)
+   chip = (enum chip_ids)of_device_get_match_data(>dev);
+   else
+   chip = id->driver_data;
+   switch (chip) {
case ADS1015:
indio_dev->channels = ads1015_channels;
indio_dev->num_channels = ARRAY_SIZE(ads1015_channels);
@@ -698,9 +704,23 @@ static const struct i2c_device_id ads1015_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ads1015_id);
 
+static const struct of_device_id ads1015_of_match[] = {
+   {
+   .compatible = "ti,ads1015",
+   .data = (void *)ADS1015
+   },
+   {
+   .compatible = "ti,ads1115",
+   .data = (void *)ADS1115
+   },
+   {}
+};
+MODULE_DEVICE_TABLE(of, ads1015_of_match);
+
 static struct i2c_driver ads1015_driver = {
.driver = {
.name = ADS1015_DRV_NAME,
+   .of_match_table = ads1015_of_match,
.pm = _pm_ops,
},
.probe  = ads1015_probe,
-- 
2.9.3

[PATCH v2 09/17] iio: accel: bma180: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/accel/bma180.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
index 0890934ef66f..e3f97757e72d 100644
--- a/drivers/iio/accel/bma180.c
+++ b/drivers/iio/accel/bma180.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +33,7 @@
 #define BMA180_DRV_NAME "bma180"
 #define BMA180_IRQ_NAME "bma180_event"
 
-enum {
+enum chip_ids {
BMA180,
BMA250,
 };
@@ -707,6 +708,7 @@ static int bma180_probe(struct i2c_client *client,
 {
struct bma180_data *data;
struct iio_dev *indio_dev;
+   enum chip_ids chip;
int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
@@ -716,7 +718,11 @@ static int bma180_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   data->part_info = _part_info[id->driver_data];
+   if (client->dev.of_node)
+   chip = (enum chip_ids)of_device_get_match_data(>dev);
+   else
+   chip = id->driver_data;
+   data->part_info = _part_info[chip];
 
ret = data->part_info->chip_config(data);
if (ret < 0)
@@ -844,10 +850,24 @@ static struct i2c_device_id bma180_ids[] = {
 
 MODULE_DEVICE_TABLE(i2c, bma180_ids);
 
+static const struct of_device_id bma180_of_match[] = {
+   {
+   .compatible = "bosch,bma180",
+   .data = (void *)BMA180
+   },
+   {
+   .compatible = "bosch,bma250",
+   .data = (void *)BMA250
+   },
+   { }
+};
+MODULE_DEVICE_TABLE(of, bma180_of_match);
+
 static struct i2c_driver bma180_driver = {
.driver = {
.name   = "bma180",
.pm = BMA180_PM_OPS,
+   .of_match_table = bma180_of_match,
},
.probe  = bma180_probe,
.remove = bma180_remove,
-- 
2.9.3

[PATCH v2 15/17] iio: pressure: mpl3115: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/pressure/mpl3115.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/pressure/mpl3115.c b/drivers/iio/pressure/mpl3115.c
index 525644a7442d..619b963714c7 100644
--- a/drivers/iio/pressure/mpl3115.c
+++ b/drivers/iio/pressure/mpl3115.c
@@ -321,9 +321,16 @@ static const struct i2c_device_id mpl3115_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mpl3115_id);
 
+static const struct of_device_id mpl3115_of_match[] = {
+   { .compatible = "fsl,mpl3115" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mpl3115_of_match);
+
 static struct i2c_driver mpl3115_driver = {
.driver = {
.name   = "mpl3115",
+   .of_match_table = mpl3115_of_match,
.pm = MPL3115_PM_OPS,
},
.probe = mpl3115_probe,
-- 
2.9.3

[PATCH v2 13/17] iio: magnetometer: mag3110: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/magnetometer/mag3110.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/magnetometer/mag3110.c 
b/drivers/iio/magnetometer/mag3110.c
index b4f643fb3b1e..dad8d57f7402 100644
--- a/drivers/iio/magnetometer/mag3110.c
+++ b/drivers/iio/magnetometer/mag3110.c
@@ -441,9 +441,16 @@ static const struct i2c_device_id mag3110_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mag3110_id);
 
+static const struct of_device_id mag3110_of_match[] = {
+   { .compatible = "fsl,mag3110" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mag3110_of_match);
+
 static struct i2c_driver mag3110_driver = {
.driver = {
.name   = "mag3110",
+   .of_match_table = mag3110_of_match,
.pm = MAG3110_PM_OPS,
},
.probe = mag3110_probe,
-- 
2.9.3

[PATCH v2 11/17] iio: dac: max5821: Set .of_match_table to OF device ID table

[Javier Martinez Canillas]

The driver has a OF device ID table but the struct i2c_driver
.of_match_table field is not set.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/dac/max5821.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/dac/max5821.c b/drivers/iio/dac/max5821.c
index 86e9e112f554..193fac3059a3 100644
--- a/drivers/iio/dac/max5821.c
+++ b/drivers/iio/dac/max5821.c
@@ -392,6 +392,7 @@ MODULE_DEVICE_TABLE(of, max5821_of_match);
 static struct i2c_driver max5821_driver = {
.driver = {
.name   = "max5821",
+   .of_match_table = max5821_of_match,
.pm = MAX5821_PM_OPS,
},
.probe  = max5821_probe,
-- 
2.9.3

[PATCH v2 12/17] iio: adc: ti-ads1015: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/adc/ti-ads1015.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
index 422b314f5a3f..f76d979fb7e8 100644
--- a/drivers/iio/adc/ti-ads1015.c
+++ b/drivers/iio/adc/ti-ads1015.c
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -55,7 +56,7 @@
 #define ADS1015_DEFAULT_DATA_RATE  4
 #define ADS1015_DEFAULT_CHAN   0
 
-enum {
+enum chip_ids {
ADS1015,
ADS1115,
 };
@@ -578,6 +579,7 @@ static int ads1015_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
struct ads1015_data *data;
int ret;
+   enum chip_ids chip;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
if (!indio_dev)
@@ -593,7 +595,11 @@ static int ads1015_probe(struct i2c_client *client,
indio_dev->name = ADS1015_DRV_NAME;
indio_dev->modes = INDIO_DIRECT_MODE;
 
-   switch (id->driver_data) {
+   if (client->dev.of_node)
+   chip = (enum chip_ids)of_device_get_match_data(>dev);
+   else
+   chip = id->driver_data;
+   switch (chip) {
case ADS1015:
indio_dev->channels = ads1015_channels;
indio_dev->num_channels = ARRAY_SIZE(ads1015_channels);
@@ -698,9 +704,23 @@ static const struct i2c_device_id ads1015_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ads1015_id);
 
+static const struct of_device_id ads1015_of_match[] = {
+   {
+   .compatible = "ti,ads1015",
+   .data = (void *)ADS1015
+   },
+   {
+   .compatible = "ti,ads1115",
+   .data = (void *)ADS1115
+   },
+   {}
+};
+MODULE_DEVICE_TABLE(of, ads1015_of_match);
+
 static struct i2c_driver ads1015_driver = {
.driver = {
.name = ADS1015_DRV_NAME,
+   .of_match_table = ads1015_of_match,
.pm = _pm_ops,
},
.probe  = ads1015_probe,
-- 
2.9.3

[PATCH v2 09/17] iio: accel: bma180: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/accel/bma180.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
index 0890934ef66f..e3f97757e72d 100644
--- a/drivers/iio/accel/bma180.c
+++ b/drivers/iio/accel/bma180.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +33,7 @@
 #define BMA180_DRV_NAME "bma180"
 #define BMA180_IRQ_NAME "bma180_event"
 
-enum {
+enum chip_ids {
BMA180,
BMA250,
 };
@@ -707,6 +708,7 @@ static int bma180_probe(struct i2c_client *client,
 {
struct bma180_data *data;
struct iio_dev *indio_dev;
+   enum chip_ids chip;
int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
@@ -716,7 +718,11 @@ static int bma180_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   data->part_info = _part_info[id->driver_data];
+   if (client->dev.of_node)
+   chip = (enum chip_ids)of_device_get_match_data(>dev);
+   else
+   chip = id->driver_data;
+   data->part_info = _part_info[chip];
 
ret = data->part_info->chip_config(data);
if (ret < 0)
@@ -844,10 +850,24 @@ static struct i2c_device_id bma180_ids[] = {
 
 MODULE_DEVICE_TABLE(i2c, bma180_ids);
 
+static const struct of_device_id bma180_of_match[] = {
+   {
+   .compatible = "bosch,bma180",
+   .data = (void *)BMA180
+   },
+   {
+   .compatible = "bosch,bma250",
+   .data = (void *)BMA250
+   },
+   { }
+};
+MODULE_DEVICE_TABLE(of, bma180_of_match);
+
 static struct i2c_driver bma180_driver = {
.driver = {
.name   = "bma180",
.pm = BMA180_PM_OPS,
+   .of_match_table = bma180_of_match,
},
.probe  = bma180_probe,
.remove = bma180_remove,
-- 
2.9.3

[PATCH v2 15/17] iio: pressure: mpl3115: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/pressure/mpl3115.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/pressure/mpl3115.c b/drivers/iio/pressure/mpl3115.c
index 525644a7442d..619b963714c7 100644
--- a/drivers/iio/pressure/mpl3115.c
+++ b/drivers/iio/pressure/mpl3115.c
@@ -321,9 +321,16 @@ static const struct i2c_device_id mpl3115_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mpl3115_id);
 
+static const struct of_device_id mpl3115_of_match[] = {
+   { .compatible = "fsl,mpl3115" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mpl3115_of_match);
+
 static struct i2c_driver mpl3115_driver = {
.driver = {
.name   = "mpl3115",
+   .of_match_table = mpl3115_of_match,
.pm = MPL3115_PM_OPS,
},
.probe = mpl3115_probe,
-- 
2.9.3

[PATCH v2 00/17] iio: Add OF device table to I2C drivers that are missing it

[Javier Martinez Canillas]

Hello,

This series add OF device ID tables to IIO I2C drivers whose devices are
either used in Device Tree source files or are listed in binding docs as
a compatible string.

That's done because the plan is to change the I2C core to report proper OF
modaliases instead of always reporting a MODALIAS=i2c: regardless if
a device was registered via DT or using the legacy platform data mechanism.

So these patches will make sure that IIO I2C drivers modules will continue
to be autoloaded once the I2C core is changed to report proper OF modalias.

Changes in v2:
- Avoid using of_match_ptr() macro which leads to build warnings when
  CONFIG_OF is not enabled (Arnd Bergmann).

Best regards,
Javier


Javier Martinez Canillas (17):
  iio: adc: ina2xx: Add OF device ID table
  iio: mlx96014: Add OF device ID table
  iio: magnetometer: bmc150_magn_i2c: Add OF device ID table
  iio: dac: mcp4725: Add OF device ID table
  iio: light: us5182d: Add OF device ID table
  iio: light: tsl2563: Add OF device ID table
  iio: pressure: hp03: Add OF device ID table
  iio: imu: inv_mpu6050: Add OF device ID table
  iio: accel: bma180: Add OF device ID table
  iio: light: apds9960: Add OF device ID table
  iio: dac: max5821: Set .of_match_table to OF device ID table
  iio: adc: ti-ads1015: Add OF device ID table
  iio: magnetometer: mag3110: Add OF device ID table
  iio: accel: mma7455_i2c: Add OF device ID table
  iio: pressure: mpl3115: Add OF device ID table
  iio: accel: mma7660: Add OF device ID table
  iio: gyro: itg3200: Add OF device ID table

 drivers/iio/accel/bma180.c | 24 +--
 drivers/iio/accel/mma7455_i2c.c|  8 +++
 drivers/iio/accel/mma7660.c|  7 ++
 drivers/iio/adc/ina2xx-adc.c   | 34 +-
 drivers/iio/adc/ti-ads1015.c   | 24 +--
 drivers/iio/dac/max5821.c  |  1 +
 drivers/iio/dac/mcp4725.c  | 24 +--
 drivers/iio/gyro/itg3200_core.c|  7 ++
 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c  | 38 ++
 drivers/iio/light/apds9960.c   |  7 ++
 drivers/iio/light/tsl2563.c| 10 
 drivers/iio/light/us5182d.c|  7 ++
 drivers/iio/magnetometer/bmc150_magn_i2c.c |  9 +++
 drivers/iio/magnetometer/mag3110.c |  7 ++
 drivers/iio/pressure/hp03.c|  7 ++
 drivers/iio/pressure/mpl3115.c |  7 ++
 drivers/iio/temperature/mlx90614.c |  7 ++
 17 files changed, 217 insertions(+), 11 deletions(-)

-- 
2.9.3

[PATCH v2 00/17] iio: Add OF device table to I2C drivers that are missing it

[Javier Martinez Canillas]

Hello,

This series add OF device ID tables to IIO I2C drivers whose devices are
either used in Device Tree source files or are listed in binding docs as
a compatible string.

That's done because the plan is to change the I2C core to report proper OF
modaliases instead of always reporting a MODALIAS=i2c: regardless if
a device was registered via DT or using the legacy platform data mechanism.

So these patches will make sure that IIO I2C drivers modules will continue
to be autoloaded once the I2C core is changed to report proper OF modalias.

Changes in v2:
- Avoid using of_match_ptr() macro which leads to build warnings when
  CONFIG_OF is not enabled (Arnd Bergmann).

Best regards,
Javier


Javier Martinez Canillas (17):
  iio: adc: ina2xx: Add OF device ID table
  iio: mlx96014: Add OF device ID table
  iio: magnetometer: bmc150_magn_i2c: Add OF device ID table
  iio: dac: mcp4725: Add OF device ID table
  iio: light: us5182d: Add OF device ID table
  iio: light: tsl2563: Add OF device ID table
  iio: pressure: hp03: Add OF device ID table
  iio: imu: inv_mpu6050: Add OF device ID table
  iio: accel: bma180: Add OF device ID table
  iio: light: apds9960: Add OF device ID table
  iio: dac: max5821: Set .of_match_table to OF device ID table
  iio: adc: ti-ads1015: Add OF device ID table
  iio: magnetometer: mag3110: Add OF device ID table
  iio: accel: mma7455_i2c: Add OF device ID table
  iio: pressure: mpl3115: Add OF device ID table
  iio: accel: mma7660: Add OF device ID table
  iio: gyro: itg3200: Add OF device ID table

 drivers/iio/accel/bma180.c | 24 +--
 drivers/iio/accel/mma7455_i2c.c|  8 +++
 drivers/iio/accel/mma7660.c|  7 ++
 drivers/iio/adc/ina2xx-adc.c   | 34 +-
 drivers/iio/adc/ti-ads1015.c   | 24 +--
 drivers/iio/dac/max5821.c  |  1 +
 drivers/iio/dac/mcp4725.c  | 24 +--
 drivers/iio/gyro/itg3200_core.c|  7 ++
 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c  | 38 ++
 drivers/iio/light/apds9960.c   |  7 ++
 drivers/iio/light/tsl2563.c| 10 
 drivers/iio/light/us5182d.c|  7 ++
 drivers/iio/magnetometer/bmc150_magn_i2c.c |  9 +++
 drivers/iio/magnetometer/mag3110.c |  7 ++
 drivers/iio/pressure/hp03.c|  7 ++
 drivers/iio/pressure/mpl3115.c |  7 ++
 drivers/iio/temperature/mlx90614.c |  7 ++
 17 files changed, 217 insertions(+), 11 deletions(-)

-- 
2.9.3

[PATCH v2 04/17] iio: dac: mcp4725: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/dac/mcp4725.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/dac/mcp4725.c b/drivers/iio/dac/mcp4725.c
index db109f0cdd8c..6ab1f23e5a79 100644
--- a/drivers/iio/dac/mcp4725.c
+++ b/drivers/iio/dac/mcp4725.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -199,7 +200,7 @@ static ssize_t mcp4725_write_powerdown(struct iio_dev 
*indio_dev,
return len;
 }
 
-enum {
+enum chip_id {
MCP4725,
MCP4726,
 };
@@ -406,7 +407,10 @@ static int mcp4725_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   data->id = id->driver_data;
+   if (client->dev.of_node)
+   data->id = (enum chip_id)of_device_get_match_data(>dev);
+   else
+   data->id = id->driver_data;
pdata = dev_get_platdata(>dev);
 
if (!pdata) {
@@ -525,9 +529,25 @@ static const struct i2c_device_id mcp4725_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mcp4725_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id mcp4725_of_match[] = {
+   {
+   .compatible = "microchip,mcp4725",
+   .data = (void *)MCP4725
+   },
+   {
+   .compatible = "microchip,mcp4726",
+   .data = (void *)MCP4726
+   },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mcp4725_of_match);
+#endif
+
 static struct i2c_driver mcp4725_driver = {
.driver = {
.name   = MCP4725_DRV_NAME,
+   .of_match_table = of_match_ptr(mcp4725_of_match),
.pm = MCP4725_PM_OPS,
},
.probe  = mcp4725_probe,
-- 
2.9.3

[PATCH v2 05/17] iio: light: us5182d: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/light/us5182d.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
index 18cf2e29e4d5..d571ad7291ed 100644
--- a/drivers/iio/light/us5182d.c
+++ b/drivers/iio/light/us5182d.c
@@ -972,10 +972,17 @@ static const struct i2c_device_id us5182d_id[] = {
 
 MODULE_DEVICE_TABLE(i2c, us5182d_id);
 
+static const struct of_device_id us5182d_of_match[] = {
+   { .compatible = "upisemi,usd5182" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, us5182d_of_match);
+
 static struct i2c_driver us5182d_driver = {
.driver = {
.name = US5182D_DRV_NAME,
.pm = _pm_ops,
+   .of_match_table = us5182d_of_match,
.acpi_match_table = ACPI_PTR(us5182d_acpi_match),
},
.probe = us5182d_probe,
-- 
2.9.3

[PATCH v2 05/17] iio: light: us5182d: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/light/us5182d.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
index 18cf2e29e4d5..d571ad7291ed 100644
--- a/drivers/iio/light/us5182d.c
+++ b/drivers/iio/light/us5182d.c
@@ -972,10 +972,17 @@ static const struct i2c_device_id us5182d_id[] = {
 
 MODULE_DEVICE_TABLE(i2c, us5182d_id);
 
+static const struct of_device_id us5182d_of_match[] = {
+   { .compatible = "upisemi,usd5182" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, us5182d_of_match);
+
 static struct i2c_driver us5182d_driver = {
.driver = {
.name = US5182D_DRV_NAME,
.pm = _pm_ops,
+   .of_match_table = us5182d_of_match,
.acpi_match_table = ACPI_PTR(us5182d_acpi_match),
},
.probe = us5182d_probe,
-- 
2.9.3

[PATCH v2 04/17] iio: dac: mcp4725: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/dac/mcp4725.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/dac/mcp4725.c b/drivers/iio/dac/mcp4725.c
index db109f0cdd8c..6ab1f23e5a79 100644
--- a/drivers/iio/dac/mcp4725.c
+++ b/drivers/iio/dac/mcp4725.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -199,7 +200,7 @@ static ssize_t mcp4725_write_powerdown(struct iio_dev 
*indio_dev,
return len;
 }
 
-enum {
+enum chip_id {
MCP4725,
MCP4726,
 };
@@ -406,7 +407,10 @@ static int mcp4725_probe(struct i2c_client *client,
data = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
data->client = client;
-   data->id = id->driver_data;
+   if (client->dev.of_node)
+   data->id = (enum chip_id)of_device_get_match_data(>dev);
+   else
+   data->id = id->driver_data;
pdata = dev_get_platdata(>dev);
 
if (!pdata) {
@@ -525,9 +529,25 @@ static const struct i2c_device_id mcp4725_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mcp4725_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id mcp4725_of_match[] = {
+   {
+   .compatible = "microchip,mcp4725",
+   .data = (void *)MCP4725
+   },
+   {
+   .compatible = "microchip,mcp4726",
+   .data = (void *)MCP4726
+   },
+   { }
+};
+MODULE_DEVICE_TABLE(of, mcp4725_of_match);
+#endif
+
 static struct i2c_driver mcp4725_driver = {
.driver = {
.name   = MCP4725_DRV_NAME,
+   .of_match_table = of_match_ptr(mcp4725_of_match),
.pm = MCP4725_PM_OPS,
},
.probe  = mcp4725_probe,
-- 
2.9.3

[PATCH v2 01/17] iio: adc: ina2xx: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/adc/ina2xx-adc.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
index 3263231276ca..db9838230257 100644
--- a/drivers/iio/adc/ina2xx-adc.c
+++ b/drivers/iio/adc/ina2xx-adc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -635,6 +636,7 @@ static int ina2xx_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
struct iio_buffer *buffer;
unsigned int val;
+   enum ina2xx_ids type;
int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*chip));
@@ -652,7 +654,11 @@ static int ina2xx_probe(struct i2c_client *client,
return PTR_ERR(chip->regmap);
}
 
-   chip->config = _config[id->driver_data];
+   if (client->dev.of_node)
+   type = (enum ina2xx_ids)of_device_get_match_data(>dev);
+   else
+   type = id->driver_data;
+   chip->config = _config[type];
 
mutex_init(>state_lock);
 
@@ -726,9 +732,35 @@ static const struct i2c_device_id ina2xx_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ina2xx_id);
 
+static const struct of_device_id ina2xx_of_match[] = {
+   {
+   .compatible = "ti,ina219",
+   .data = (void *)ina219
+   },
+   {
+   .compatible = "ti,ina220",
+   .data = (void *)ina219
+   },
+   {
+   .compatible = "ti,ina226",
+   .data = (void *)ina226
+   },
+   {
+   .compatible = "ti,ina230",
+   .data = (void *)ina226
+   },
+   {
+   .compatible = "ti,ina231",
+   .data = (void *)ina226
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ina2xx_of_match);
+
 static struct i2c_driver ina2xx_driver = {
.driver = {
   .name = KBUILD_MODNAME,
+  .of_match_table = ina2xx_of_match,
},
.probe = ina2xx_probe,
.remove = ina2xx_remove,
-- 
2.9.3

[PATCH v2 01/17] iio: adc: ina2xx: Add OF device ID table

[Javier Martinez Canillas]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/iio/adc/ina2xx-adc.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
index 3263231276ca..db9838230257 100644
--- a/drivers/iio/adc/ina2xx-adc.c
+++ b/drivers/iio/adc/ina2xx-adc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -635,6 +636,7 @@ static int ina2xx_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
struct iio_buffer *buffer;
unsigned int val;
+   enum ina2xx_ids type;
int ret;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*chip));
@@ -652,7 +654,11 @@ static int ina2xx_probe(struct i2c_client *client,
return PTR_ERR(chip->regmap);
}
 
-   chip->config = _config[id->driver_data];
+   if (client->dev.of_node)
+   type = (enum ina2xx_ids)of_device_get_match_data(>dev);
+   else
+   type = id->driver_data;
+   chip->config = _config[type];
 
mutex_init(>state_lock);
 
@@ -726,9 +732,35 @@ static const struct i2c_device_id ina2xx_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ina2xx_id);
 
+static const struct of_device_id ina2xx_of_match[] = {
+   {
+   .compatible = "ti,ina219",
+   .data = (void *)ina219
+   },
+   {
+   .compatible = "ti,ina220",
+   .data = (void *)ina219
+   },
+   {
+   .compatible = "ti,ina226",
+   .data = (void *)ina226
+   },
+   {
+   .compatible = "ti,ina230",
+   .data = (void *)ina226
+   },
+   {
+   .compatible = "ti,ina231",
+   .data = (void *)ina226
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ina2xx_of_match);
+
 static struct i2c_driver ina2xx_driver = {
.driver = {
   .name = KBUILD_MODNAME,
+  .of_match_table = ina2xx_of_match,
},
.probe = ina2xx_probe,
.remove = ina2xx_remove,
-- 
2.9.3

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

[Akshay Bhat]

Hi Wolfgang,

On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger  
wrote:
...snip
>> /disconnect cable
>>   can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{40}{0}}
>>   can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{88}{0}}
>>   can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{128}{0}}
>
>
> TX error warning is missing.
>

This support was missing in the driver, added in V4 patch.

>>   can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
>> controller-problem{tx-error-passive}
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{128}{0}}
>
>
> Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
> state change messages similar to:
>
>can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
> controller-problem{tx-error-warning}
> state-change{tx-error-warning}
> error-counter-tx-rx{{96}{0}}
>can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
> controller-problem{tx-error-passive}
> state-change{tx-error-passive}
> error-counter-tx-rx{{128}{0}
>
> They should always come, even with "berr-reporting off".
>

HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.

So here is my plan:
- Have the bus error interrupt always enabled
- If berr-reporting off, then have the isr checks/reports state changes
- if berr-reporting on, then have the isr checks/reports bus errors
and state changes (Does it make sense packing the error message, if
the ISR finds both bus and state changes?)

>> write: No buffer space available
>> root@imx6qrom5420b1:~# ip -s -d link show can0
>> 4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
>> mode DEFAULT group default qlen 10
>> link/can  promiscuity 0
>> can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
>> restart-ms 0
>>   bitrate 100 sample-point 0.750
>>   tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
>>   hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>   clock 1600
>>   re-started bus-errors arbit-lost error-warn error-pass bus-off
>>   0  6  0  1  1  0
>
>
> The error warning and passive counter increased , though. Also the bus error
> should come in at a rather hight rate. Looking to the code, maybe
> you need to test STATF to check for state changes (and not ERR).
>

Apologize, just realized In the above case some error packets were
lost, because I forgot to set the CPU frequency to max. Will resend
the log.

..snip...
>
> After some more messages there should be also:
>
> can0  2200  [8] 00 40 00 00 00 00 5F 00   ERRORFRAME
> state-change{back-to-error-active}
> error-counter-tx-rx{{95}{0}}
>
> For each message sent, the error counter decreases by 8.
>

The HI-3110 controller decrements the error counter by 1 for every message sent.
The error count increments by 8 when there is an error.

>
>>
>> root@imx6qrom5420b1:~# ip -s -d link show can0
>> 4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
>> mode DEFAULT group default qlen 10
>> link/can  promiscuity 0
>> can state ERROR-ACTIVE (berr-counter tx 117 rx 0) restart-ms 0
>>   bitrate 100 sample-point 0.750
>>   tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
>>   hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>   clock 1600
>>   re-started bus-errors arbit-lost error-warn error-pass bus-off
>>   0  1  0  0  0  0
>
>
> Strange, some counters got lost.
>

This was a bug introduced when adding berr-reporting, have fixed in v4 patch.

>>
>> I have not been able to check the bus-off condition by (short-circuiting
>> CAN low and high). The tec error count remains at 128 when I short the
>> CAN low and high pins and the status never goes BUSOFF.
>
>
> You also need to send a message and the short-circuit should be at the
> connector of the sending host. What tranceiver is used? Do you know?
>

ADM3054 transceiver is used with HI-3111. I connected the
HI-3111/ADM3054 board to kvaser leaf and ran "cangen -i can0" and
"candump -e any,0:0,#FFF" on the board. Removed the cable and
shorted the CAN_H/L pins coming out of ADM3054. I will try your
suggestion of using a different bit-rate on the Kvaser leaf instead.

I appreciate your continued feedback, it has helped significantly
improve the error handling of the driver. Looking back I should have
based it 

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

[Akshay Bhat]

Hi Wolfgang,

On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger  
wrote:
...snip
>> /disconnect cable
>>   can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{40}{0}}
>>   can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{88}{0}}
>>   can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{128}{0}}
>
>
> TX error warning is missing.
>

This support was missing in the driver, added in V4 patch.

>>   can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
>> controller-problem{tx-error-passive}
>> protocol-violation{{}{acknowledge-slot}}
>> bus-error
>> error-counter-tx-rx{{128}{0}}
>
>
> Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
> state change messages similar to:
>
>can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
> controller-problem{tx-error-warning}
> state-change{tx-error-warning}
> error-counter-tx-rx{{96}{0}}
>can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
> controller-problem{tx-error-passive}
> state-change{tx-error-passive}
> error-counter-tx-rx{{128}{0}
>
> They should always come, even with "berr-reporting off".
>

HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.

So here is my plan:
- Have the bus error interrupt always enabled
- If berr-reporting off, then have the isr checks/reports state changes
- if berr-reporting on, then have the isr checks/reports bus errors
and state changes (Does it make sense packing the error message, if
the ISR finds both bus and state changes?)

>> write: No buffer space available
>> root@imx6qrom5420b1:~# ip -s -d link show can0
>> 4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
>> mode DEFAULT group default qlen 10
>> link/can  promiscuity 0
>> can  state ERROR-PASSIVE (berr-counter tx 128 rx 0)
>> restart-ms 0
>>   bitrate 100 sample-point 0.750
>>   tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
>>   hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>   clock 1600
>>   re-started bus-errors arbit-lost error-warn error-pass bus-off
>>   0  6  0  1  1  0
>
>
> The error warning and passive counter increased , though. Also the bus error
> should come in at a rather hight rate. Looking to the code, maybe
> you need to test STATF to check for state changes (and not ERR).
>

Apologize, just realized In the above case some error packets were
lost, because I forgot to set the CPU frequency to max. Will resend
the log.

..snip...
>
> After some more messages there should be also:
>
> can0  2200  [8] 00 40 00 00 00 00 5F 00   ERRORFRAME
> state-change{back-to-error-active}
> error-counter-tx-rx{{95}{0}}
>
> For each message sent, the error counter decreases by 8.
>

The HI-3110 controller decrements the error counter by 1 for every message sent.
The error count increments by 8 when there is an error.

>
>>
>> root@imx6qrom5420b1:~# ip -s -d link show can0
>> 4: can0:  mtu 16 qdisc pfifo_fast state UNKNOWN
>> mode DEFAULT group default qlen 10
>> link/can  promiscuity 0
>> can state ERROR-ACTIVE (berr-counter tx 117 rx 0) restart-ms 0
>>   bitrate 100 sample-point 0.750
>>   tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 1
>>   hi3110: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
>>   clock 1600
>>   re-started bus-errors arbit-lost error-warn error-pass bus-off
>>   0  1  0  0  0  0
>
>
> Strange, some counters got lost.
>

This was a bug introduced when adding berr-reporting, have fixed in v4 patch.

>>
>> I have not been able to check the bus-off condition by (short-circuiting
>> CAN low and high). The tec error count remains at 128 when I short the
>> CAN low and high pins and the status never goes BUSOFF.
>
>
> You also need to send a message and the short-circuit should be at the
> connector of the sending host. What tranceiver is used? Do you know?
>

ADM3054 transceiver is used with HI-3111. I connected the
HI-3111/ADM3054 board to kvaser leaf and ran "cangen -i can0" and
"candump -e any,0:0,#FFF" on the board. Removed the cable and
shorted the CAN_H/L pins coming out of ADM3054. I will try your
suggestion of using a different bit-rate on the Kvaser leaf instead.

I appreciate your continued feedback, it has helped significantly
improve the error handling of the driver. Looking back I should have
based it on sja1000 or flexcan driver.

Thanks,
Akshay

Re: [PATCH v3 2/5] thermal: add trace events to the power allocator governor

[Viresh Kumar]

Hi Javi,

Sorry for picking up an old thread, but i had a question for you.

On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino  wrote:
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c

> @@ -588,12 +590,20 @@ static int cpufreq_get_requested_power(struct 
> thermal_cooling_device *cdev,
>u32 *power)
>  {
> unsigned long freq;
> -   int cpu, ret;
> +   int i = 0, cpu, ret;
> u32 static_power, dynamic_power, total_load = 0;
> struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
> +   u32 *load_cpu = NULL;
>
> freq = cpufreq_quick_get(cpumask_any(_device->allowed_cpus));
>
> +   if (trace_thermal_power_cpu_get_power_enabled()) {

You allocated load_cpu if cpu_get_power trace is enabled.

> +   u32 ncpus = cpumask_weight(_device->allowed_cpus);
> +
> +   load_cpu = devm_kcalloc(>device, ncpus, 
> sizeof(*load_cpu),
> +   GFP_KERNEL);
> +   }
> +
> for_each_cpu(cpu, _device->allowed_cpus) {
> u32 load;
>
> @@ -603,14 +613,29 @@ static int cpufreq_get_requested_power(struct 
> thermal_cooling_device *cdev,
> load = 0;
>
> total_load += load;
> +   if (trace_thermal_power_cpu_limit_enabled() && load_cpu)

But you store values to it only if cpu_limit trace is also enabled,
otherwise it is all zeros.

Why?

Re: [PATCH v3 2/5] thermal: add trace events to the power allocator governor

[Viresh Kumar]

Hi Javi,

Sorry for picking up an old thread, but i had a question for you.

On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino  wrote:
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c

> @@ -588,12 +590,20 @@ static int cpufreq_get_requested_power(struct 
> thermal_cooling_device *cdev,
>u32 *power)
>  {
> unsigned long freq;
> -   int cpu, ret;
> +   int i = 0, cpu, ret;
> u32 static_power, dynamic_power, total_load = 0;
> struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
> +   u32 *load_cpu = NULL;
>
> freq = cpufreq_quick_get(cpumask_any(_device->allowed_cpus));
>
> +   if (trace_thermal_power_cpu_get_power_enabled()) {

You allocated load_cpu if cpu_get_power trace is enabled.

> +   u32 ncpus = cpumask_weight(_device->allowed_cpus);
> +
> +   load_cpu = devm_kcalloc(>device, ncpus, 
> sizeof(*load_cpu),
> +   GFP_KERNEL);
> +   }
> +
> for_each_cpu(cpu, _device->allowed_cpus) {
> u32 load;
>
> @@ -603,14 +613,29 @@ static int cpufreq_get_requested_power(struct 
> thermal_cooling_device *cdev,
> load = 0;
>
> total_load += load;
> +   if (trace_thermal_power_cpu_limit_enabled() && load_cpu)

But you store values to it only if cpu_limit trace is also enabled,
otherwise it is all zeros.

Why?

Re: [PATCH 1/2] mm: Change generic FALLBACK zonelist creation process

[John Hubbard]

On 03/14/2017 06:33 AM, Anshuman Khandual wrote:

On 03/08/2017 04:37 PM, John Hubbard wrote:

[...]

There was a discussion, on an earlier version of this patchset, in which
someone pointed out that a slight over-allocation on a device that has
much more memory than the CPU has, could use up system memory. Your
latest approach here does not address this.


Hmm, I dont remember this. Could you please be more specific and point
me to the discussion on this.


That idea came from Dave Hansen, who was commenting on your RFC V2 patch:

https://lkml.org/lkml/2017/1/30/894

..."A device who got its memory usage off by 1% could start to starve the rest of 
the system..."





I'm thinking that, until oversubscription between NUMA nodes is more
fully implemented in a way that can be properly controlled, you'd


I did not get you. What does over subscription mean in this context ?
FALLBACK zonelist on each node has memory from every node including
it's own. Hence the allocation request targeted towards any node is
symmetrical with respect to from where the memory will be allocated.



Here, I was referring to the lack of support in the kernel today, for allocating X+N bytes on a NUMA 
node, when that node only has X bytes associated with it. Currently, the system uses a fallback node 
list to try to allocate on other nodes, in that case, but that's not idea. If it NUMA allocation 
instead supported "oversubscription", it could allow the allocation to succeed, and then fault and 
evict (to other nodes) to support a working set that is larger than the physical memory that the 
node has.


This is what GPUs do today, in order to handle work loads that are too large for GPU memory. This 
enables a whole other level of applications that the user can run.


Maybe there are other ways to get the same result, so if others have ideas, please chime in. I'm 
assuming for now that this sort of thing will just be required in the coming months.



probably better just not fallback to system memory. In other words, a
CDM node really is *isolated* from other nodes--no automatic use in
either direction.


That is debatable. With this proposed solution the CDM FALLBACK
zonelist contains system RAM zones as fallback option which will
be used in case CDM memory is depleted. IMHO, I think thats the
right thing to do as it still maintains the symmetry to some
extent.



Yes, it's worth discussing. Again, Dave's note applies here.



Also, naming and purpose: maybe this is a "Limited NUMA Node", rather
than a Coherent Device Memory node. Because: the real point of this
thing is to limit the normal operation of NUMA, just enough to work with
what I am *told* is memory-that-is-too-fragile-for-kernel-use (I remain
soemwhat on the fence, there, even though you did talk me into it
earlier, heh).


:) Naming can be debated later after we all agree on the proposal
in principle. We have already discussed about kernel memory on CDM
in detail.


OK.

thanks,
John Hubbard
NVIDIA





On process: it would probably help if you gathered up previous
discussion points and carefully, concisely addressed each one,
somewhere, (maybe in a cover letter). Because otherwise, it's too easy
for earlier, important problems to be forgotten. And reviewers don't
want to have to repeat themselves, of course.


Will do.

Re: [PATCH 1/2] mm: Change generic FALLBACK zonelist creation process

[John Hubbard]

On 03/14/2017 06:33 AM, Anshuman Khandual wrote:

On 03/08/2017 04:37 PM, John Hubbard wrote:

[...]

There was a discussion, on an earlier version of this patchset, in which
someone pointed out that a slight over-allocation on a device that has
much more memory than the CPU has, could use up system memory. Your
latest approach here does not address this.


Hmm, I dont remember this. Could you please be more specific and point
me to the discussion on this.


That idea came from Dave Hansen, who was commenting on your RFC V2 patch:

https://lkml.org/lkml/2017/1/30/894

..."A device who got its memory usage off by 1% could start to starve the rest of 
the system..."





I'm thinking that, until oversubscription between NUMA nodes is more
fully implemented in a way that can be properly controlled, you'd


I did not get you. What does over subscription mean in this context ?
FALLBACK zonelist on each node has memory from every node including
it's own. Hence the allocation request targeted towards any node is
symmetrical with respect to from where the memory will be allocated.



Here, I was referring to the lack of support in the kernel today, for allocating X+N bytes on a NUMA 
node, when that node only has X bytes associated with it. Currently, the system uses a fallback node 
list to try to allocate on other nodes, in that case, but that's not idea. If it NUMA allocation 
instead supported "oversubscription", it could allow the allocation to succeed, and then fault and 
evict (to other nodes) to support a working set that is larger than the physical memory that the 
node has.


This is what GPUs do today, in order to handle work loads that are too large for GPU memory. This 
enables a whole other level of applications that the user can run.


Maybe there are other ways to get the same result, so if others have ideas, please chime in. I'm 
assuming for now that this sort of thing will just be required in the coming months.



probably better just not fallback to system memory. In other words, a
CDM node really is *isolated* from other nodes--no automatic use in
either direction.


That is debatable. With this proposed solution the CDM FALLBACK
zonelist contains system RAM zones as fallback option which will
be used in case CDM memory is depleted. IMHO, I think thats the
right thing to do as it still maintains the symmetry to some
extent.



Yes, it's worth discussing. Again, Dave's note applies here.



Also, naming and purpose: maybe this is a "Limited NUMA Node", rather
than a Coherent Device Memory node. Because: the real point of this
thing is to limit the normal operation of NUMA, just enough to work with
what I am *told* is memory-that-is-too-fragile-for-kernel-use (I remain
soemwhat on the fence, there, even though you did talk me into it
earlier, heh).


:) Naming can be debated later after we all agree on the proposal
in principle. We have already discussed about kernel memory on CDM
in detail.


OK.

thanks,
John Hubbard
NVIDIA





On process: it would probably help if you gathered up previous
discussion points and carefully, concisely addressed each one,
somewhere, (maybe in a cover letter). Because otherwise, it's too easy
for earlier, important problems to be forgotten. And reviewers don't
want to have to repeat themselves, of course.


Will do.

Re: [PATCH V7 0/7] LPC: legacy ISA I/O support

[zhichang.yuan]

Hi, Arnd,

Many thanks for your review!

On 2017/3/14 16:39, Arnd Bergmann wrote:
> On Mon, Mar 13, 2017 at 3:42 AM, zhichang.yuan
>  wrote:
>> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
>> interface implemented on Hisilicon Hip06/Hip07 SoC.
>> ---
>> | LPC host|
>> | |
>> ---
>>  |
>> _V___LPC
>>   |   |
>>   V   V
>>  
>>  |  BT(ipmi)|
>>  
>>
>> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a 
>> specific
>> LPC driver is needed to make LPC host generate the standard LPC I/O cycles 
>> with
>> the target peripherals'I/O port addresses. But on curent arm64 world, there 
>> is
>> no real I/O accesses. All the I/O operations through in/out pair are based on
>> MMIO which is not satisfied the I/O mechanism on Hip06/Hip07 LPC.
>> To solve this issue and keep the relevant existing peripherals' driver
>> untouched, this patchset implements:
>>   - introduces a generic I/O space management framwork, LIBIO, to support I/O
>> operations of both MMIO buses and the host controllers which access their
>> peripherals with host local I/O addresses;
>>   - redefines the in/out accessors to provide unified interfaces for MMIO and
>> legacy I/O. Based on the LIBIO, the calling of in/out() from upper-layer
>> drivers, such as ipmi-si, will be redirected to the corresponding
>> device-specific I/O hooks to perfrom the I/O accesses.
>> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals
>> can be supported without any changes on the existing ipmi-si driver.
> 
> Thanks for reposting this. I have a few high-level comments first, based on
> the walk through the code I did with Gabriele and John last week:
> 
> - I think the libio framework is more generic than it needs to be, but as
>   Alex really liked it this way and it was done like this based on his earlier
>   comments, I think that's ok.
> 
> - after we went back and forth on the ACPI implementation, we concluded
>   that it is correct to do the same as on DT and completely abstract the
>   number space for I/O ports. No code should rely on a Linux port number
>   to have any particular relation to the physical address or the the address
>   on a PCI or LPC bus.
Thanks again for your helps in Linaro Connect!
I think we are heading for this direction, is it?

> 
> - The name "libio" still needs to be changed, this is way too generic, as
>   "I/O" can refer to many things in the kernel, and almost none of them
>   are related to x86 programmed I/O ports in any way. My suggestion
>   would be "generic_ioport", or possibly "libioport", "libpio" or "pci_io". 
> Any
>   of them would work for me, or someone else could come up with a better
>   name that describes what it is.

Ok. We will make a better name:)

> 
> - I'm pretty sure the current implementation is broken for the ioport_map
>   function that tries to turn an IORESOURCE_IO number into a pointer.
>   Forcing CONFIG_GENERIC_IOMAP on would solve this, but also
>   make all MMIO operations slower, which we probably don't want.
>   It's probably enough to add a check in ioport_map() to see if the range
>   is mapped into a virtual address or not.


Yes, I think our LIBIO will break the ioport_map() at this moment.
I try to solve this issue. Could you help to check the following ideas?
I am not deeper understanding the whole I/O framework, the following maybe not 
correct:(

ioport_map seems architecture-dependent. For our LIBIO, we don't want to 
replace the existing I/O
frameworks which support MMIO at this moment. Can we add these two revise to 
solve this issue?
1) Make LIBIO only target for non GENERIC_IOMAP platforms

config LIBIO
bool "Generic logical IO management"
depends on !GENERIC_IOMAP
def_bool y if PCI && (ARC || MN10300 || UNICORE32 || SPARC || 
MICROBLAZE || S390 || AVR32 || CRIS || BLACKFIN || XTENSA || ARM64)

2) Modify the ioport_map() defined in asm-generic/io.h
Add the checks to identify the input 'port' is MMIO, otherwise, return NULL;

Then is it enough to avoid the negative effect on the existing I/O framework?

> 
> - We could simplify the lookup a bit by using the trick from arch/ia64
>   of using an array instead of linked list for walking the port numbers.
>   There, the upper bits of the port number refer to an address space
>   number while the lower bits refer to the bus address within that
>   address space. This should work just as well as the current
>   implementation but would be a little easier to understand. Maybe
>   Bjorn can comment on this too, as 

Re: [PATCH V7 0/7] LPC: legacy ISA I/O support

[zhichang.yuan]

Hi, Arnd,

Many thanks for your review!

On 2017/3/14 16:39, Arnd Bergmann wrote:
> On Mon, Mar 13, 2017 at 3:42 AM, zhichang.yuan
>  wrote:
>> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
>> interface implemented on Hisilicon Hip06/Hip07 SoC.
>> ---
>> | LPC host|
>> | |
>> ---
>>  |
>> _V___LPC
>>   |   |
>>   V   V
>>  
>>  |  BT(ipmi)|
>>  
>>
>> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a 
>> specific
>> LPC driver is needed to make LPC host generate the standard LPC I/O cycles 
>> with
>> the target peripherals'I/O port addresses. But on curent arm64 world, there 
>> is
>> no real I/O accesses. All the I/O operations through in/out pair are based on
>> MMIO which is not satisfied the I/O mechanism on Hip06/Hip07 LPC.
>> To solve this issue and keep the relevant existing peripherals' driver
>> untouched, this patchset implements:
>>   - introduces a generic I/O space management framwork, LIBIO, to support I/O
>> operations of both MMIO buses and the host controllers which access their
>> peripherals with host local I/O addresses;
>>   - redefines the in/out accessors to provide unified interfaces for MMIO and
>> legacy I/O. Based on the LIBIO, the calling of in/out() from upper-layer
>> drivers, such as ipmi-si, will be redirected to the corresponding
>> device-specific I/O hooks to perfrom the I/O accesses.
>> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals
>> can be supported without any changes on the existing ipmi-si driver.
> 
> Thanks for reposting this. I have a few high-level comments first, based on
> the walk through the code I did with Gabriele and John last week:
> 
> - I think the libio framework is more generic than it needs to be, but as
>   Alex really liked it this way and it was done like this based on his earlier
>   comments, I think that's ok.
> 
> - after we went back and forth on the ACPI implementation, we concluded
>   that it is correct to do the same as on DT and completely abstract the
>   number space for I/O ports. No code should rely on a Linux port number
>   to have any particular relation to the physical address or the the address
>   on a PCI or LPC bus.
Thanks again for your helps in Linaro Connect!
I think we are heading for this direction, is it?

> 
> - The name "libio" still needs to be changed, this is way too generic, as
>   "I/O" can refer to many things in the kernel, and almost none of them
>   are related to x86 programmed I/O ports in any way. My suggestion
>   would be "generic_ioport", or possibly "libioport", "libpio" or "pci_io". 
> Any
>   of them would work for me, or someone else could come up with a better
>   name that describes what it is.

Ok. We will make a better name:)

> 
> - I'm pretty sure the current implementation is broken for the ioport_map
>   function that tries to turn an IORESOURCE_IO number into a pointer.
>   Forcing CONFIG_GENERIC_IOMAP on would solve this, but also
>   make all MMIO operations slower, which we probably don't want.
>   It's probably enough to add a check in ioport_map() to see if the range
>   is mapped into a virtual address or not.


Yes, I think our LIBIO will break the ioport_map() at this moment.
I try to solve this issue. Could you help to check the following ideas?
I am not deeper understanding the whole I/O framework, the following maybe not 
correct:(

ioport_map seems architecture-dependent. For our LIBIO, we don't want to 
replace the existing I/O
frameworks which support MMIO at this moment. Can we add these two revise to 
solve this issue?
1) Make LIBIO only target for non GENERIC_IOMAP platforms

config LIBIO
bool "Generic logical IO management"
depends on !GENERIC_IOMAP
def_bool y if PCI && (ARC || MN10300 || UNICORE32 || SPARC || 
MICROBLAZE || S390 || AVR32 || CRIS || BLACKFIN || XTENSA || ARM64)

2) Modify the ioport_map() defined in asm-generic/io.h
Add the checks to identify the input 'port' is MMIO, otherwise, return NULL;

Then is it enough to avoid the negative effect on the existing I/O framework?

> 
> - We could simplify the lookup a bit by using the trick from arch/ia64
>   of using an array instead of linked list for walking the port numbers.
>   There, the upper bits of the port number refer to an address space
>   number while the lower bits refer to the bus address within that
>   address space. This should work just as well as the current
>   implementation but would be a little easier to understand. Maybe
>   Bjorn can comment on this too, as I think he was involved 

Re: [PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

[kbuild test robot]

Hi mshan,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/mshan/Fixed-a-minor-coding-style-warning-Arguments-in-the-macros-should-be-coverd-in-brackets-to-aviod-any-precedence-issues/20170315-084955
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/staging/fwserial/fwserial.c:21:0:
   drivers/staging/fwserial/fwserial.c: In function 'fwtty_log_tx_error':
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:201:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "card busy\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:204:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "bad unit addr or write length\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:207:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "failed rx\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:210:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "missing ack\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, 

Re: [PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

[kbuild test robot]

Hi mshan,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/mshan/Fixed-a-minor-coding-style-warning-Arguments-in-the-macros-should-be-coverd-in-brackets-to-aviod-any-precedence-issues/20170315-084955
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/staging/fwserial/fwserial.c:21:0:
   drivers/staging/fwserial/fwserial.c: In function 'fwtty_log_tx_error':
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:201:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "card busy\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:204:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "bad unit addr or write length\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:207:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "failed rx\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^
   drivers/staging/fwserial/fwserial.c:210:3: note: in expansion of macro 
'fwtty_err_ratelimited'
  fwtty_err_ratelimited(port, "missing ack\n");
  ^
>> drivers/staging/fwserial/fwserial.c:101:33: error: expected identifier 
>> before '(' token
#define to_device(a, b)   ((a)->(b))
^
   include/linux/device.h:1377:13: note: in definition of macro 
'dev_level_ratelimited'
  dev_level(dev, fmt, ##__VA_ARGS__);   \
^~~
   drivers/staging/fwserial/fwserial.c:111:2: note: in expansion of macro 
'dev_err_ratelimited'
 dev_err_ratelimited(to_device(p, device), fmt, ##__VA_ARGS__)
 ^~~
   drivers/staging/fwserial/fwserial.c:111:22: note: in expansion of macro 
'to_device'
 dev_err_ratelimited(to_device(p, device), fmt, 

[PATCH] drivers/staging/goldfish/goldfish_nand.c: Fixed Coding style Warnings.

[mshan]

Embedded function names are less appropriate to use when
refactoring, can cause function renaming.  Prefer the use
of "%s", __func__ to embedded function names

Signed-off-by: mshan 
---
 drivers/staging/goldfish/goldfish_nand.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/goldfish/goldfish_nand.c 
b/drivers/staging/goldfish/goldfish_nand.c
index 76d60ee..8f92ff4 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -114,8 +114,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct 
erase_info *instr)
len = len / mtd->writesize * (mtd->writesize + mtd->oobsize);
 
if (goldfish_nand_cmd(mtd, NAND_CMD_ERASE, ofs, len, NULL) != len) {
-   pr_err("goldfish_nand_erase: erase failed, start %llx, len %x, 
dev_size %llx, erase_size %x\n",
-  ofs, len, mtd->size, mtd->erasesize);
+   pr_err("%s: erase failed, start %llx, len %x, dev_size %llx, 
erase_size %x\n",
+  __func__, ofs, len, mtd->size, mtd->erasesize);
return -EIO;
}
 
@@ -125,8 +125,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct 
erase_info *instr)
return 0;
 
 invalid_arg:
-   pr_err("goldfish_nand_erase: invalid erase, start %llx, len %x, 
dev_size %llx, erase_size %x\n",
-  ofs, len, mtd->size, mtd->erasesize);
+   pr_err("%s: invalid erase, start %llx, len %x, dev_size %llx, 
erase_size %x\n",
+  __func__, ofs, len, mtd->size, mtd->erasesize);
return -EINVAL;
 }
 
@@ -254,8 +254,8 @@ static int goldfish_nand_block_isbad(struct mtd_info *mtd, 
loff_t ofs)
return goldfish_nand_cmd(mtd, NAND_CMD_BLOCK_BAD_GET, ofs, 0, NULL);
 
 invalid_arg:
-   pr_err("goldfish_nand_block_isbad: invalid arg, ofs %llx, dev_size 
%llx, write_size %x\n",
-  ofs, mtd->size, mtd->writesize);
+   pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+  __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
 }
 
@@ -277,8 +277,8 @@ static int goldfish_nand_block_markbad(struct mtd_info 
*mtd, loff_t ofs)
return 0;
 
 invalid_arg:
-   pr_err("goldfish_nand_block_markbad: invalid arg, ofs %llx, dev_size 
%llx, write_size %x\n",
-  ofs, mtd->size, mtd->writesize);
+   pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+  __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
 }
 
-- 
2.7.4

[PATCH] drivers/staging/goldfish/goldfish_nand.c: Fixed Coding style Warnings.

[mshan]

Embedded function names are less appropriate to use when
refactoring, can cause function renaming.  Prefer the use
of "%s", __func__ to embedded function names

Signed-off-by: mshan 
---
 drivers/staging/goldfish/goldfish_nand.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/goldfish/goldfish_nand.c 
b/drivers/staging/goldfish/goldfish_nand.c
index 76d60ee..8f92ff4 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -114,8 +114,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct 
erase_info *instr)
len = len / mtd->writesize * (mtd->writesize + mtd->oobsize);
 
if (goldfish_nand_cmd(mtd, NAND_CMD_ERASE, ofs, len, NULL) != len) {
-   pr_err("goldfish_nand_erase: erase failed, start %llx, len %x, 
dev_size %llx, erase_size %x\n",
-  ofs, len, mtd->size, mtd->erasesize);
+   pr_err("%s: erase failed, start %llx, len %x, dev_size %llx, 
erase_size %x\n",
+  __func__, ofs, len, mtd->size, mtd->erasesize);
return -EIO;
}
 
@@ -125,8 +125,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct 
erase_info *instr)
return 0;
 
 invalid_arg:
-   pr_err("goldfish_nand_erase: invalid erase, start %llx, len %x, 
dev_size %llx, erase_size %x\n",
-  ofs, len, mtd->size, mtd->erasesize);
+   pr_err("%s: invalid erase, start %llx, len %x, dev_size %llx, 
erase_size %x\n",
+  __func__, ofs, len, mtd->size, mtd->erasesize);
return -EINVAL;
 }
 
@@ -254,8 +254,8 @@ static int goldfish_nand_block_isbad(struct mtd_info *mtd, 
loff_t ofs)
return goldfish_nand_cmd(mtd, NAND_CMD_BLOCK_BAD_GET, ofs, 0, NULL);
 
 invalid_arg:
-   pr_err("goldfish_nand_block_isbad: invalid arg, ofs %llx, dev_size 
%llx, write_size %x\n",
-  ofs, mtd->size, mtd->writesize);
+   pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+  __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
 }
 
@@ -277,8 +277,8 @@ static int goldfish_nand_block_markbad(struct mtd_info 
*mtd, loff_t ofs)
return 0;
 
 invalid_arg:
-   pr_err("goldfish_nand_block_markbad: invalid arg, ofs %llx, dev_size 
%llx, write_size %x\n",
-  ofs, mtd->size, mtd->writesize);
+   pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+  __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
 }
 
-- 
2.7.4