[PATCH 00/12] New warnings and build errors in linux-next

[PATCH 00/12] New warnings and build errors in linux-next

[Arnd Bergmann]

Hi everyone,

I've run my own build tests on the arm-soc tree, and now on linux-next
in order to find regressions on build warnings. These are a bunch of
patches that I came up with to address problems that were newly
introduced since 3.6 and that are not in the domain of the
arm-soc tree.

I'd hope to find someone for each patch to apply or rewrite it
in a better way. Sorry for any duplicates. I've made the patches
last week but had not gotten around to get them ready for submission,
it it may be possible that they are already fixed in one tree or
another.

	Arnd

Arnd Bergmann (12):
  mtd: atmel nand: build regression
  ata: mark probe function as __devinit rather than __init
  mmc: dw_mmc: fix building exynos driver as a module
  video: exynos: warnings in exynos_dp_core.c
  ARM: ixp4xx: use __iomem for MMIO
  sched: warnings in kernel/sched/fair.c
  staging/iio/lis3l02dq: fix building without irq_to_gpio
  dtc: be more quiet with "make -s"
  tty/console: fix warnings in drivers/tty/serial/kgdboc.c
  gpio: pcf857x: select IRQ_DOMAIN
  pinctrl: samsung: use __devinit section for init code
  time/jiffies: bring back unconditional LATCH definition

 arch/arm/mach-ixp4xx/include/mach/qmgr.h   |   12 ++++++------
 arch/arm/mach-ixp4xx/ixp4xx_qmgr.c         |    4 ++--
 drivers/ata/sata_highbank.c                |    2 +-
 drivers/gpio/Kconfig                       |    1 +
 drivers/mmc/host/dw_mmc-exynos.c           |    4 ++--
 drivers/mmc/host/dw_mmc-pltfm.c            |    2 +-
 drivers/mmc/host/dw_mmc-pltfm.h            |    2 +-
 drivers/mmc/host/dw_mmc.c                  |    2 +-
 drivers/mtd/nand/atmel_nand.c              |    8 ++++----
 drivers/pinctrl/pinctrl-samsung.c          |   10 +++++-----
 drivers/staging/iio/accel/lis3l02dq.h      |    1 +
 drivers/staging/iio/accel/lis3l02dq_core.c |   10 ++++++----
 drivers/staging/iio/accel/lis3l02dq_ring.c |    2 +-
 drivers/video/exynos/exynos_dp_core.c      |    2 +-
 include/linux/console.h                    |   10 ++++++++--
 include/linux/jiffies.h                    |    5 +++--
 include/linux/mmc/dw_mmc.h                 |    2 +-
 kernel/sched/fair.c                        |    2 +-
 scripts/Makefile.lib                       |    2 +-
 scripts/dtc/dtc.c                          |    5 +++--
 20 files changed, 50 insertions(+), 38 deletions(-)

-- 
1.7.10

[PATCH 00/12] New warnings and build errors in linux-next

[Arnd Bergmann]

Hi everyone,

I've run my own build tests on the arm-soc tree, and now on linux-next
in order to find regressions on build warnings. These are a bunch of
patches that I came up with to address problems that were newly
introduced since 3.6 and that are not in the domain of the
arm-soc tree.

I'd hope to find someone for each patch to apply or rewrite it
in a better way. Sorry for any duplicates. I've made the patches
last week but had not gotten around to get them ready for submission,
it it may be possible that they are already fixed in one tree or
another.

	Arnd

Arnd Bergmann (12):
  mtd: atmel nand: build regression
  ata: mark probe function as __devinit rather than __init
  mmc: dw_mmc: fix building exynos driver as a module
  video: exynos: warnings in exynos_dp_core.c
  ARM: ixp4xx: use __iomem for MMIO
  sched: warnings in kernel/sched/fair.c
  staging/iio/lis3l02dq: fix building without irq_to_gpio
  dtc: be more quiet with "make -s"
  tty/console: fix warnings in drivers/tty/serial/kgdboc.c
  gpio: pcf857x: select IRQ_DOMAIN
  pinctrl: samsung: use __devinit section for init code
  time/jiffies: bring back unconditional LATCH definition

 arch/arm/mach-ixp4xx/include/mach/qmgr.h   |   12 ++++++------
 arch/arm/mach-ixp4xx/ixp4xx_qmgr.c         |    4 ++--
 drivers/ata/sata_highbank.c                |    2 +-
 drivers/gpio/Kconfig                       |    1 +
 drivers/mmc/host/dw_mmc-exynos.c           |    4 ++--
 drivers/mmc/host/dw_mmc-pltfm.c            |    2 +-
 drivers/mmc/host/dw_mmc-pltfm.h            |    2 +-
 drivers/mmc/host/dw_mmc.c                  |    2 +-
 drivers/mtd/nand/atmel_nand.c              |    8 ++++----
 drivers/pinctrl/pinctrl-samsung.c          |   10 +++++-----
 drivers/staging/iio/accel/lis3l02dq.h      |    1 +
 drivers/staging/iio/accel/lis3l02dq_core.c |   10 ++++++----
 drivers/staging/iio/accel/lis3l02dq_ring.c |    2 +-
 drivers/video/exynos/exynos_dp_core.c      |    2 +-
 include/linux/console.h                    |   10 ++++++++--
 include/linux/jiffies.h                    |    5 +++--
 include/linux/mmc/dw_mmc.h                 |    2 +-
 kernel/sched/fair.c                        |    2 +-
 scripts/Makefile.lib                       |    2 +-
 scripts/dtc/dtc.c                          |    5 +++--
 20 files changed, 50 insertions(+), 38 deletions(-)

-- 
1.7.10

[PATCH 01/12] mtd: atmel nand: build regression

[Arnd Bergmann]

The atmel_nand driver was broken by b654a9a46fc2 "mtd: atmel nand: fix
gpio missing request". This is a rather helpless attempt to fix this,
probably messing up the error handling even further but getting the
build to work again, so please treat it as a bug report rather than
a fix to be applied.

Without this patch, building any at91 configuration results in:

drivers/mtd/nand/atmel_nand.c: In function 'atmel_nand_probe':
drivers/mtd/nand/atmel_nand.c:1451:4: error: label 'err_ecc_ioremap' used but not defined

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
 drivers/mtd/nand/atmel_nand.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 9144557..eba5b2a 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -1420,7 +1420,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request rdy gpio %d\n",
 				host->board.rdy_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 
 		res = gpio_direction_input(host->board.rdy_pin);
@@ -1428,7 +1428,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request input direction rdy gpio %d\n",
 				host->board.rdy_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 
 		nand_chip->dev_ready = atmel_nand_device_ready;
@@ -1440,7 +1440,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request enable gpio %d\n",
 				host->board.enable_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 
 		res = gpio_direction_output(host->board.enable_pin, 1);
@@ -1448,7 +1448,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request output direction enable gpio %d\n",
 				host->board.enable_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 	}
 
-- 
1.7.10

[PATCH 01/12] mtd: atmel nand: build regression

[Arnd Bergmann]

The atmel_nand driver was broken by b654a9a46fc2 "mtd: atmel nand: fix
gpio missing request". This is a rather helpless attempt to fix this,
probably messing up the error handling even further but getting the
build to work again, so please treat it as a bug report rather than
a fix to be applied.

Without this patch, building any at91 configuration results in:

drivers/mtd/nand/atmel_nand.c: In function 'atmel_nand_probe':
drivers/mtd/nand/atmel_nand.c:1451:4: error: label 'err_ecc_ioremap' used but not defined

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
 drivers/mtd/nand/atmel_nand.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 9144557..eba5b2a 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -1420,7 +1420,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request rdy gpio %d\n",
 				host->board.rdy_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 
 		res = gpio_direction_input(host->board.rdy_pin);
@@ -1428,7 +1428,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request input direction rdy gpio %d\n",
 				host->board.rdy_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 
 		nand_chip->dev_ready = atmel_nand_device_ready;
@@ -1440,7 +1440,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request enable gpio %d\n",
 				host->board.enable_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 
 		res = gpio_direction_output(host->board.enable_pin, 1);
@@ -1448,7 +1448,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request output direction enable gpio %d\n",
 				host->board.enable_pin);
-			goto err_ecc_ioremap;
+			goto err_no_card;
 		}
 	}
 
-- 
1.7.10

[PATCH 02/12] ata: mark probe function as __devinit rather than __init

[Arnd Bergmann]

Functions for hotplugging must be marked as __devinit so
they do not get discarded, as pointed out by a build time
warning from modpost.

Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Jeff Garzik <jgarzik@redhat.com>
---
 drivers/ata/sata_highbank.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c
index 0d7c4c2..36a141a 100644
--- a/drivers/ata/sata_highbank.c
+++ b/drivers/ata/sata_highbank.c
@@ -260,7 +260,7 @@ static const struct of_device_id ahci_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, ahci_of_match);
 
-static int __init ahci_highbank_probe(struct platform_device *pdev)
+static int __devinit ahci_highbank_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct ahci_host_priv *hpriv;
-- 
1.7.10

[PATCH 02/12] ata: mark probe function as __devinit rather than __init

[Arnd Bergmann]

Functions for hotplugging must be marked as __devinit so
they do not get discarded, as pointed out by a build time
warning from modpost.

Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Jeff Garzik <jgarzik@redhat.com>
---
 drivers/ata/sata_highbank.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c
index 0d7c4c2..36a141a 100644
--- a/drivers/ata/sata_highbank.c
+++ b/drivers/ata/sata_highbank.c
@@ -260,7 +260,7 @@ static const struct of_device_id ahci_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, ahci_of_match);
 
-static int __init ahci_highbank_probe(struct platform_device *pdev)
+static int __devinit ahci_highbank_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct ahci_host_priv *hpriv;
-- 
1.7.10

[PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Arnd Bergmann]

The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
points to the wrong symbol which results in a link error
when building as a loadable module.

Further, we get a warning about the driver_data being
marked constant, which requires annotating a few pointers
as const.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Ball <cjb@laptop.org>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Will Newton <will.newton@imgtec.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Seungwon Jeon <tgih.jun@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: linux-mmc@vger.kernel.org
---
 drivers/mmc/host/dw_mmc-exynos.c |    4 ++--
 drivers/mmc/host/dw_mmc-pltfm.c  |    2 +-
 drivers/mmc/host/dw_mmc-pltfm.h  |    2 +-
 drivers/mmc/host/dw_mmc.c        |    2 +-
 include/linux/mmc/dw_mmc.h       |    2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 660bbc5..32109a6 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -223,11 +223,11 @@ static const struct of_device_id dw_mci_exynos_match[] = {
 			.data = (void *)&exynos5250_drv_data, },
 	{},
 };
-MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
+MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
 
 int dw_mci_exynos_probe(struct platform_device *pdev)
 {
-	struct dw_mci_drv_data *drv_data;
+	const struct dw_mci_drv_data *drv_data;
 	const struct of_device_id *match;
 
 	match = of_match_node(dw_mci_exynos_match, pdev->dev.of_node);
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c960ca7..5e33156 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -24,7 +24,7 @@
 #include "dw_mmc.h"
 
 int dw_mci_pltfm_register(struct platform_device *pdev,
-				struct dw_mci_drv_data *drv_data)
+				const struct dw_mci_drv_data *drv_data)
 {
 	struct dw_mci *host;
 	struct resource	*regs;
diff --git a/drivers/mmc/host/dw_mmc-pltfm.h b/drivers/mmc/host/dw_mmc-pltfm.h
index 301f245..2ac37b8 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.h
+++ b/drivers/mmc/host/dw_mmc-pltfm.h
@@ -13,7 +13,7 @@
 #define _DW_MMC_PLTFM_H_
 
 extern int dw_mci_pltfm_register(struct platform_device *pdev,
-				struct dw_mci_drv_data *drv_data);
+				const struct dw_mci_drv_data *drv_data);
 extern int __devexit dw_mci_pltfm_remove(struct platform_device *pdev);
 extern const struct dev_pm_ops dw_mci_pltfm_pmops;
 
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a23af77..026cf92 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1973,7 +1973,7 @@ static void dw_mci_init_dma(struct dw_mci *host)
 	/* Determine which DMA interface to use */
 #ifdef CONFIG_MMC_DW_IDMAC
 	host->dma_ops = &dw_mci_idmac_ops;
-	dev_info(&host->dev, "Using internal DMA controller.\n");
+	dev_info(host->dev, "Using internal DMA controller.\n");
 #endif
 
 	if (!host->dma_ops)
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 7c6a113..0f62c8c 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -162,7 +162,7 @@ struct dw_mci {
 	u16			data_offset;
 	struct device		*dev;
 	struct dw_mci_board	*pdata;
-	struct dw_mci_drv_data	*drv_data;
+	const struct dw_mci_drv_data	*drv_data;
 	void			*priv;
 	struct clk		*biu_clk;
 	struct clk		*ciu_clk;
-- 
1.7.10

[PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Arnd Bergmann]

The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
points to the wrong symbol which results in a link error
when building as a loadable module.

Further, we get a warning about the driver_data being
marked constant, which requires annotating a few pointers
as const.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Ball <cjb@laptop.org>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Will Newton <will.newton@imgtec.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Seungwon Jeon <tgih.jun@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: linux-mmc at vger.kernel.org
---
 drivers/mmc/host/dw_mmc-exynos.c |    4 ++--
 drivers/mmc/host/dw_mmc-pltfm.c  |    2 +-
 drivers/mmc/host/dw_mmc-pltfm.h  |    2 +-
 drivers/mmc/host/dw_mmc.c        |    2 +-
 include/linux/mmc/dw_mmc.h       |    2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 660bbc5..32109a6 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -223,11 +223,11 @@ static const struct of_device_id dw_mci_exynos_match[] = {
 			.data = (void *)&exynos5250_drv_data, },
 	{},
 };
-MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
+MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
 
 int dw_mci_exynos_probe(struct platform_device *pdev)
 {
-	struct dw_mci_drv_data *drv_data;
+	const struct dw_mci_drv_data *drv_data;
 	const struct of_device_id *match;
 
 	match = of_match_node(dw_mci_exynos_match, pdev->dev.of_node);
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c960ca7..5e33156 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -24,7 +24,7 @@
 #include "dw_mmc.h"
 
 int dw_mci_pltfm_register(struct platform_device *pdev,
-				struct dw_mci_drv_data *drv_data)
+				const struct dw_mci_drv_data *drv_data)
 {
 	struct dw_mci *host;
 	struct resource	*regs;
diff --git a/drivers/mmc/host/dw_mmc-pltfm.h b/drivers/mmc/host/dw_mmc-pltfm.h
index 301f245..2ac37b8 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.h
+++ b/drivers/mmc/host/dw_mmc-pltfm.h
@@ -13,7 +13,7 @@
 #define _DW_MMC_PLTFM_H_
 
 extern int dw_mci_pltfm_register(struct platform_device *pdev,
-				struct dw_mci_drv_data *drv_data);
+				const struct dw_mci_drv_data *drv_data);
 extern int __devexit dw_mci_pltfm_remove(struct platform_device *pdev);
 extern const struct dev_pm_ops dw_mci_pltfm_pmops;
 
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a23af77..026cf92 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1973,7 +1973,7 @@ static void dw_mci_init_dma(struct dw_mci *host)
 	/* Determine which DMA interface to use */
 #ifdef CONFIG_MMC_DW_IDMAC
 	host->dma_ops = &dw_mci_idmac_ops;
-	dev_info(&host->dev, "Using internal DMA controller.\n");
+	dev_info(host->dev, "Using internal DMA controller.\n");
 #endif
 
 	if (!host->dma_ops)
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 7c6a113..0f62c8c 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -162,7 +162,7 @@ struct dw_mci {
 	u16			data_offset;
 	struct device		*dev;
 	struct dw_mci_board	*pdata;
-	struct dw_mci_drv_data	*drv_data;
+	const struct dw_mci_drv_data	*drv_data;
 	void			*priv;
 	struct clk		*biu_clk;
 	struct clk		*ciu_clk;
-- 
1.7.10

[PATCH 04/12] video: exynos: warnings in exynos_dp_core.c

[Arnd Bergmann]

Something is wrong with the exynos_dp_core logic, and gcc
emits a warning about this. An array is declared in
exynos_dp_process_equalizer_training with length '2',
and exynos_dp_channel_eq_ok tries to access the third
element of it.

This patch is certainly not correct, but hopefully helps
highlight the actual problem. The problem apparently was
introduced by d5c0eed01 "video: exynos_dp: adjust voltage
swing and pre-emphasis during Link Training".

This is what we get in exynos_defconfig:
drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_process_equalizer_training':
drivers/video/exynos/exynos_dp_core.c:341:13: warning: array subscript is above array bounds [-Warray-bounds]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
 drivers/video/exynos/exynos_dp_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index cdc1398..358b595 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -542,7 +542,7 @@ reduce_link_rate:
 
 static int exynos_dp_process_equalizer_training(struct exynos_dp_device *dp)
 {
-	u8 link_status[2];
+	u8 link_status[3];
 	u8 link_align[3];
 	int lane;
 	int lane_count;
-- 
1.7.10

[PATCH 04/12] video: exynos: warnings in exynos_dp_core.c

[Arnd Bergmann]

Something is wrong with the exynos_dp_core logic, and gcc
emits a warning about this. An array is declared in
exynos_dp_process_equalizer_training with length '2',
and exynos_dp_channel_eq_ok tries to access the third
element of it.

This patch is certainly not correct, but hopefully helps
highlight the actual problem. The problem apparently was
introduced by d5c0eed01 "video: exynos_dp: adjust voltage
swing and pre-emphasis during Link Training".

This is what we get in exynos_defconfig:
drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_process_equalizer_training':
drivers/video/exynos/exynos_dp_core.c:341:13: warning: array subscript is above array bounds [-Warray-bounds]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
 drivers/video/exynos/exynos_dp_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index cdc1398..358b595 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -542,7 +542,7 @@ reduce_link_rate:
 
 static int exynos_dp_process_equalizer_training(struct exynos_dp_device *dp)
 {
-	u8 link_status[2];
+	u8 link_status[3];
 	u8 link_align[3];
 	int lane;
 	int lane_count;
-- 
1.7.10

[PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Arnd Bergmann]

The ixp4xx queue manager uses "const struct qmgr_regs __iomem *" as the
type for a pointer that is passed to __raw_writel, which is not
allowed because of the const-ness.

Dropping the 'const' keyword fixes the problem. While we're here,
let's also drop the useless type cast.

Without this patch, building ixp4xx_defconfig results in:

In file included from arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:15:0:
arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry':
arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'
In file included from drivers/net/ethernet/xscale/ixp4xx_eth.c:41:0:
arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry':
arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c: In function 'qmgr_set_irq':
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:41:9: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
---

Krzysztof, please apply in your next branch so this problem goes away in
3.8. I realize it won't make 3.7 any more since the base patches are not
in arm-soc, but it's bad if linux-next is broken.

 arch/arm/mach-ixp4xx/include/mach/qmgr.h |   12 ++++++------
 arch/arm/mach-ixp4xx/ixp4xx_qmgr.c       |    4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/include/mach/qmgr.h b/arch/arm/mach-ixp4xx/include/mach/qmgr.h
index 0a88d3b..4de8da5 100644
--- a/arch/arm/mach-ixp4xx/include/mach/qmgr.h
+++ b/arch/arm/mach-ixp4xx/include/mach/qmgr.h
@@ -86,7 +86,7 @@ void qmgr_release_queue(unsigned int queue);
 
 static inline void qmgr_put_entry(unsigned int queue, u32 val)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 #if DEBUG_QMGR
 	BUG_ON(!qmgr_queue_descs[queue]); /* not yet requested */
 
@@ -99,7 +99,7 @@ static inline void qmgr_put_entry(unsigned int queue, u32 val)
 static inline u32 qmgr_get_entry(unsigned int queue)
 {
 	u32 val;
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	val = __raw_readl(&qmgr_regs->acc[queue][0]);
 #if DEBUG_QMGR
 	BUG_ON(!qmgr_queue_descs[queue]); /* not yet requested */
@@ -112,14 +112,14 @@ static inline u32 qmgr_get_entry(unsigned int queue)
 
 static inline int __qmgr_get_stat1(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	return (__raw_readl(&qmgr_regs->stat1[queue >> 3])
 		>> ((queue & 7) << 2)) & 0xF;
 }
 
 static inline int __qmgr_get_stat2(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	BUG_ON(queue >= HALF_QUEUES);
 	return (__raw_readl(&qmgr_regs->stat2[queue >> 4])
 		>> ((queue & 0xF) << 1)) & 0x3;
@@ -145,7 +145,7 @@ static inline int qmgr_stat_empty(unsigned int queue)
  */
 static inline int qmgr_stat_below_low_watermark(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	if (queue >= HALF_QUEUES)
 		return (__raw_readl(&qmgr_regs->statne_h) >>
 			(queue - HALF_QUEUES)) & 0x01;
@@ -172,7 +172,7 @@ static inline int qmgr_stat_above_high_watermark(unsigned int queue)
  */
 static inline int qmgr_stat_full(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	if (queue >= HALF_QUEUES)
 		return (__raw_readl(&qmgr_regs->statf_h) >>
 			(queue - HALF_QUEUES)) & 0x01;
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
index 7c0584e..9d1b6b7 100644
--- a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
+++ b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
@@ -14,7 +14,7 @@
 #include <linux/module.h>
 #include <mach/qmgr.h>
 
-static const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+static struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 static struct resource *mem_res;
 static spinlock_t qmgr_lock;
 static u32 used_sram_bitmap[4]; /* 128 16-dword pages */
@@ -32,7 +32,7 @@ void qmgr_set_irq(unsigned int queue, int src,
 
 	spin_lock_irqsave(&qmgr_lock, flags);
 	if (queue < HALF_QUEUES) {
-		const u32 __iomem *reg;
+		u32 __iomem *reg;
 		int bit;
 		BUG_ON(src > QUEUE_IRQ_SRC_NOT_FULL);
 		reg = &qmgr_regs->irqsrc[queue >> 3]; /* 8 queues per u32 */
-- 
1.7.10

[PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Arnd Bergmann]

The ixp4xx queue manager uses "const struct qmgr_regs __iomem *" as the
type for a pointer that is passed to __raw_writel, which is not
allowed because of the const-ness.

Dropping the 'const' keyword fixes the problem. While we're here,
let's also drop the useless type cast.

Without this patch, building ixp4xx_defconfig results in:

In file included from arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:15:0:
arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry':
arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'
In file included from drivers/net/ethernet/xscale/ixp4xx_eth.c:41:0:
arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry':
arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c: In function 'qmgr_set_irq':
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:41:9: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
---

Krzysztof, please apply in your next branch so this problem goes away in
3.8. I realize it won't make 3.7 any more since the base patches are not
in arm-soc, but it's bad if linux-next is broken.

 arch/arm/mach-ixp4xx/include/mach/qmgr.h |   12 ++++++------
 arch/arm/mach-ixp4xx/ixp4xx_qmgr.c       |    4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/include/mach/qmgr.h b/arch/arm/mach-ixp4xx/include/mach/qmgr.h
index 0a88d3b..4de8da5 100644
--- a/arch/arm/mach-ixp4xx/include/mach/qmgr.h
+++ b/arch/arm/mach-ixp4xx/include/mach/qmgr.h
@@ -86,7 +86,7 @@ void qmgr_release_queue(unsigned int queue);
 
 static inline void qmgr_put_entry(unsigned int queue, u32 val)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 #if DEBUG_QMGR
 	BUG_ON(!qmgr_queue_descs[queue]); /* not yet requested */
 
@@ -99,7 +99,7 @@ static inline void qmgr_put_entry(unsigned int queue, u32 val)
 static inline u32 qmgr_get_entry(unsigned int queue)
 {
 	u32 val;
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	val = __raw_readl(&qmgr_regs->acc[queue][0]);
 #if DEBUG_QMGR
 	BUG_ON(!qmgr_queue_descs[queue]); /* not yet requested */
@@ -112,14 +112,14 @@ static inline u32 qmgr_get_entry(unsigned int queue)
 
 static inline int __qmgr_get_stat1(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	return (__raw_readl(&qmgr_regs->stat1[queue >> 3])
 		>> ((queue & 7) << 2)) & 0xF;
 }
 
 static inline int __qmgr_get_stat2(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	BUG_ON(queue >= HALF_QUEUES);
 	return (__raw_readl(&qmgr_regs->stat2[queue >> 4])
 		>> ((queue & 0xF) << 1)) & 0x3;
@@ -145,7 +145,7 @@ static inline int qmgr_stat_empty(unsigned int queue)
  */
 static inline int qmgr_stat_below_low_watermark(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	if (queue >= HALF_QUEUES)
 		return (__raw_readl(&qmgr_regs->statne_h) >>
 			(queue - HALF_QUEUES)) & 0x01;
@@ -172,7 +172,7 @@ static inline int qmgr_stat_above_high_watermark(unsigned int queue)
  */
 static inline int qmgr_stat_full(unsigned int queue)
 {
-	const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+	const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 	if (queue >= HALF_QUEUES)
 		return (__raw_readl(&qmgr_regs->statf_h) >>
 			(queue - HALF_QUEUES)) & 0x01;
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
index 7c0584e..9d1b6b7 100644
--- a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
+++ b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
@@ -14,7 +14,7 @@
 #include <linux/module.h>
 #include <mach/qmgr.h>
 
-static const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT;
+static struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT;
 static struct resource *mem_res;
 static spinlock_t qmgr_lock;
 static u32 used_sram_bitmap[4]; /* 128 16-dword pages */
@@ -32,7 +32,7 @@ void qmgr_set_irq(unsigned int queue, int src,
 
 	spin_lock_irqsave(&qmgr_lock, flags);
 	if (queue < HALF_QUEUES) {
-		const u32 __iomem *reg;
+		u32 __iomem *reg;
 		int bit;
 		BUG_ON(src > QUEUE_IRQ_SRC_NOT_FULL);
 		reg = &qmgr_regs->irqsrc[queue >> 3]; /* 8 queues per u32 */
-- 
1.7.10

[PATCH 06/12] sched: warnings in kernel/sched/fair.c

[Arnd Bergmann]

a4c96ae319 "sched: Unthrottle rt runqueues in __disable_runtime()"
turned the unthrottle_offline_cfs_rqs function into a static symbol,
which now triggers a warning about it being potentially unused:

kernel/sched/fair.c:2055:13: warning: 'unthrottle_offline_cfs_rqs' defined but not used [-Wunused-function]

Marking it __maybe_unused shuts up the gcc warning and lets the
compiler safely drop the function body when it's not being used.

To reproduce, build the ARM bcm2835_defconfig.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Boonstoppel <pboonstoppel@nvidia.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Turner <pjt@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/fair.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6b800a1..9f52728 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2052,7 +2052,7 @@ static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
 	hrtimer_cancel(&cfs_b->slack_timer);
 }
 
-static void unthrottle_offline_cfs_rqs(struct rq *rq)
+static void __maybe_unused unthrottle_offline_cfs_rqs(struct rq *rq)
 {
 	struct cfs_rq *cfs_rq;
 
-- 
1.7.10

[PATCH 06/12] sched: warnings in kernel/sched/fair.c

[Arnd Bergmann]

a4c96ae319 "sched: Unthrottle rt runqueues in __disable_runtime()"
turned the unthrottle_offline_cfs_rqs function into a static symbol,
which now triggers a warning about it being potentially unused:

kernel/sched/fair.c:2055:13: warning: 'unthrottle_offline_cfs_rqs' defined but not used [-Wunused-function]

Marking it __maybe_unused shuts up the gcc warning and lets the
compiler safely drop the function body when it's not being used.

To reproduce, build the ARM bcm2835_defconfig.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Boonstoppel <pboonstoppel@nvidia.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Turner <pjt@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/fair.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6b800a1..9f52728 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2052,7 +2052,7 @@ static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
 	hrtimer_cancel(&cfs_b->slack_timer);
 }
 
-static void unthrottle_offline_cfs_rqs(struct rq *rq)
+static void __maybe_unused unthrottle_offline_cfs_rqs(struct rq *rq)
 {
 	struct cfs_rq *cfs_rq;
 
-- 
1.7.10

[PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Arnd Bergmann]

The driver has not been building for some time after the
irq_to_gpio function has been removed from the kernel.

The only board in the upstream kernel that provides
this device is the "Stargate 2", which is also maintained
by Jonathan Cameron. Rather than working around the problem
by adding new platform data for this driver, this patch
uses the of_gpio framework to get to the gpio number.

However, the stargate2 code does not (yet) use DT based
probing, so it is still broken, but at least building
allyesconfig works again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/iio/accel/lis3l02dq.h      |    1 +
 drivers/staging/iio/accel/lis3l02dq_core.c |   10 ++++++----
 drivers/staging/iio/accel/lis3l02dq_ring.c |    2 +-
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/accel/lis3l02dq.h b/drivers/staging/iio/accel/lis3l02dq.h
index f9bcd41..2bac722 100644
--- a/drivers/staging/iio/accel/lis3l02dq.h
+++ b/drivers/staging/iio/accel/lis3l02dq.h
@@ -158,6 +158,7 @@ struct lis3l02dq_state {
 	struct spi_device		*us;
 	struct iio_trigger		*trig;
 	struct mutex			buf_lock;
+	int				gpio;
 	bool				trigger_on;
 
 	u8	tx[LIS3L02DQ_MAX_RX] ____cacheline_aligned;
diff --git a/drivers/staging/iio/accel/lis3l02dq_core.c b/drivers/staging/iio/accel/lis3l02dq_core.c
index 21b0469..d13c7e9 100644
--- a/drivers/staging/iio/accel/lis3l02dq_core.c
+++ b/drivers/staging/iio/accel/lis3l02dq_core.c
@@ -15,6 +15,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/gpio.h>
+#include <linux/of_gpio.h>
 #include <linux/mutex.h>
 #include <linux/device.h>
 #include <linux/kernel.h>
@@ -690,6 +691,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
 	spi_set_drvdata(spi, indio_dev);
 
 	st->us = spi;
+	st->gpio = of_get_gpio(spi->dev.of_node, 0);
 	mutex_init(&st->buf_lock);
 	indio_dev->name = spi->dev.driver->name;
 	indio_dev->dev.parent = &spi->dev;
@@ -711,7 +713,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
 		goto error_unreg_buffer_funcs;
 	}
 
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0) {
+	if (spi->irq) {
 		ret = request_threaded_irq(st->us->irq,
 					   &lis3l02dq_th,
 					   &lis3l02dq_event_handler,
@@ -738,10 +740,10 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
 	return 0;
 
 error_remove_trigger:
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)))
+	if (spi->irq)
 		lis3l02dq_remove_trigger(indio_dev);
 error_free_interrupt:
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
+	if (spi->irq)
 		free_irq(st->us->irq, indio_dev);
 error_uninitialize_buffer:
 	iio_buffer_unregister(indio_dev);
@@ -790,7 +792,7 @@ static int __devexit lis3l02dq_remove(struct spi_device *spi)
 	lis3l02dq_disable_all_events(indio_dev);
 	lis3l02dq_stop_device(indio_dev);
 
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
+	if (spi->irq)
 		free_irq(st->us->irq, indio_dev);
 
 	lis3l02dq_remove_trigger(indio_dev);
diff --git a/drivers/staging/iio/accel/lis3l02dq_ring.c b/drivers/staging/iio/accel/lis3l02dq_ring.c
index fa4190d..13c0b4b 100644
--- a/drivers/staging/iio/accel/lis3l02dq_ring.c
+++ b/drivers/staging/iio/accel/lis3l02dq_ring.c
@@ -263,7 +263,7 @@ static int lis3l02dq_trig_try_reen(struct iio_trigger *trig)
 	/* If gpio still high (or high again)
 	 * In theory possible we will need to do this several times */
 	for (i = 0; i < 5; i++)
-		if (gpio_get_value(irq_to_gpio(st->us->irq)))
+		if (gpio_get_value(st->gpio))
 			lis3l02dq_read_all(indio_dev, NULL);
 		else
 			break;
-- 
1.7.10

[PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Arnd Bergmann]

The driver has not been building for some time after the
irq_to_gpio function has been removed from the kernel.

The only board in the upstream kernel that provides
this device is the "Stargate 2", which is also maintained
by Jonathan Cameron. Rather than working around the problem
by adding new platform data for this driver, this patch
uses the of_gpio framework to get to the gpio number.

However, the stargate2 code does not (yet) use DT based
probing, so it is still broken, but at least building
allyesconfig works again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/iio/accel/lis3l02dq.h      |    1 +
 drivers/staging/iio/accel/lis3l02dq_core.c |   10 ++++++----
 drivers/staging/iio/accel/lis3l02dq_ring.c |    2 +-
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/accel/lis3l02dq.h b/drivers/staging/iio/accel/lis3l02dq.h
index f9bcd41..2bac722 100644
--- a/drivers/staging/iio/accel/lis3l02dq.h
+++ b/drivers/staging/iio/accel/lis3l02dq.h
@@ -158,6 +158,7 @@ struct lis3l02dq_state {
 	struct spi_device		*us;
 	struct iio_trigger		*trig;
 	struct mutex			buf_lock;
+	int				gpio;
 	bool				trigger_on;
 
 	u8	tx[LIS3L02DQ_MAX_RX] ____cacheline_aligned;
diff --git a/drivers/staging/iio/accel/lis3l02dq_core.c b/drivers/staging/iio/accel/lis3l02dq_core.c
index 21b0469..d13c7e9 100644
--- a/drivers/staging/iio/accel/lis3l02dq_core.c
+++ b/drivers/staging/iio/accel/lis3l02dq_core.c
@@ -15,6 +15,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/gpio.h>
+#include <linux/of_gpio.h>
 #include <linux/mutex.h>
 #include <linux/device.h>
 #include <linux/kernel.h>
@@ -690,6 +691,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
 	spi_set_drvdata(spi, indio_dev);
 
 	st->us = spi;
+	st->gpio = of_get_gpio(spi->dev.of_node, 0);
 	mutex_init(&st->buf_lock);
 	indio_dev->name = spi->dev.driver->name;
 	indio_dev->dev.parent = &spi->dev;
@@ -711,7 +713,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
 		goto error_unreg_buffer_funcs;
 	}
 
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0) {
+	if (spi->irq) {
 		ret = request_threaded_irq(st->us->irq,
 					   &lis3l02dq_th,
 					   &lis3l02dq_event_handler,
@@ -738,10 +740,10 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
 	return 0;
 
 error_remove_trigger:
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)))
+	if (spi->irq)
 		lis3l02dq_remove_trigger(indio_dev);
 error_free_interrupt:
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
+	if (spi->irq)
 		free_irq(st->us->irq, indio_dev);
 error_uninitialize_buffer:
 	iio_buffer_unregister(indio_dev);
@@ -790,7 +792,7 @@ static int __devexit lis3l02dq_remove(struct spi_device *spi)
 	lis3l02dq_disable_all_events(indio_dev);
 	lis3l02dq_stop_device(indio_dev);
 
-	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
+	if (spi->irq)
 		free_irq(st->us->irq, indio_dev);
 
 	lis3l02dq_remove_trigger(indio_dev);
diff --git a/drivers/staging/iio/accel/lis3l02dq_ring.c b/drivers/staging/iio/accel/lis3l02dq_ring.c
index fa4190d..13c0b4b 100644
--- a/drivers/staging/iio/accel/lis3l02dq_ring.c
+++ b/drivers/staging/iio/accel/lis3l02dq_ring.c
@@ -263,7 +263,7 @@ static int lis3l02dq_trig_try_reen(struct iio_trigger *trig)
 	/* If gpio still high (or high again)
 	 * In theory possible we will need to do this several times */
 	for (i = 0; i < 5; i++)
-		if (gpio_get_value(irq_to_gpio(st->us->irq)))
+		if (gpio_get_value(st->gpio))
 			lis3l02dq_read_all(indio_dev, NULL);
 		else
 			break;
-- 
1.7.10

[PATCH 08/12] dtc: be more quiet with "make -s"

[Arnd Bergmann]

On a normal build, we get output from both make and from dtc
about each file that is being processed.

  DTC     arch/arm/boot/vexpress-v2p-ca5s.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca5s.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca9.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca9.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca15-tc1.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca15_a7.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts"

When both lines refer to the same action. When building with "make -s",
the "DTC: dts->dtb ..." line is the only output we currently get.

This patch makes dtc not output the message when the "-q" flag is passed,
and ensures that we pass it in both cases.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: David Gibson <dwg@au1.ibm.com>
---
 scripts/Makefile.lib |    2 +-
 scripts/dtc/dtc.c    |    5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0be6f11..662528a 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -264,7 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
 	$(call cmd,dt_S_dtb)
 
 quiet_cmd_dtc = DTC     $@
-cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile) $<
+cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -q -d $(depfile) $<
 
 # Bzip2
 # ---------------------------------------------------------------------------
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index 2ef5e2e..a1586ff 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -188,8 +188,9 @@ int main(int argc, char *argv[])
 	if (minsize)
 		fprintf(stderr, "DTC: Use of \"-S\" is deprecated; it will be removed soon, use \"-p\" instead\n");
 
-	fprintf(stderr, "DTC: %s->%s  on file \"%s\"\n",
-		inform, outform, arg);
+	if (!quiet)
+		fprintf(stderr, "DTC: %s->%s  on file \"%s\"\n",
+			inform, outform, arg);
 
 	if (depname) {
 		depfile = fopen(depname, "w");
-- 
1.7.10

[PATCH 08/12] dtc: be more quiet with "make -s"

[Arnd Bergmann]

On a normal build, we get output from both make and from dtc
about each file that is being processed.

  DTC     arch/arm/boot/vexpress-v2p-ca5s.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca5s.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca9.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca9.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca15-tc1.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca15_a7.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts"

When both lines refer to the same action. When building with "make -s",
the "DTC: dts->dtb ..." line is the only output we currently get.

This patch makes dtc not output the message when the "-q" flag is passed,
and ensures that we pass it in both cases.

Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Michal Marek <mmarek-AlSwsSmVLrQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: David Gibson <dwg-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
---
 scripts/Makefile.lib |    2 +-
 scripts/dtc/dtc.c    |    5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0be6f11..662528a 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -264,7 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
 	$(call cmd,dt_S_dtb)
 
 quiet_cmd_dtc = DTC     $@
-cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile) $<
+cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -q -d $(depfile) $<
 
 # Bzip2
 # ---------------------------------------------------------------------------
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index 2ef5e2e..a1586ff 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -188,8 +188,9 @@ int main(int argc, char *argv[])
 	if (minsize)
 		fprintf(stderr, "DTC: Use of \"-S\" is deprecated; it will be removed soon, use \"-p\" instead\n");
 
-	fprintf(stderr, "DTC: %s->%s  on file \"%s\"\n",
-		inform, outform, arg);
+	if (!quiet)
+		fprintf(stderr, "DTC: %s->%s  on file \"%s\"\n",
+			inform, outform, arg);
 
 	if (depname) {
 		depfile = fopen(depname, "w");
-- 
1.7.10

[PATCH 08/12] dtc: be more quiet with "make -s"

[Arnd Bergmann]

On a normal build, we get output from both make and from dtc
about each file that is being processed.

  DTC     arch/arm/boot/vexpress-v2p-ca5s.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca5s.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca9.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca9.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca15-tc1.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts"
  DTC     arch/arm/boot/vexpress-v2p-ca15_a7.dtb
DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts"

When both lines refer to the same action. When building with "make -s",
the "DTC: dts->dtb ..." line is the only output we currently get.

This patch makes dtc not output the message when the "-q" flag is passed,
and ensures that we pass it in both cases.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: David Gibson <dwg@au1.ibm.com>
---
 scripts/Makefile.lib |    2 +-
 scripts/dtc/dtc.c    |    5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0be6f11..662528a 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -264,7 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
 	$(call cmd,dt_S_dtb)
 
 quiet_cmd_dtc = DTC     $@
-cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile) $<
+cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -q -d $(depfile) $<
 
 # Bzip2
 # ---------------------------------------------------------------------------
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index 2ef5e2e..a1586ff 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -188,8 +188,9 @@ int main(int argc, char *argv[])
 	if (minsize)
 		fprintf(stderr, "DTC: Use of \"-S\" is deprecated; it will be removed soon, use \"-p\" instead\n");
 
-	fprintf(stderr, "DTC: %s->%s  on file \"%s\"\n",
-		inform, outform, arg);
+	if (!quiet)
+		fprintf(stderr, "DTC: %s->%s  on file \"%s\"\n",
+			inform, outform, arg);
 
 	if (depname) {
 		depfile = fopen(depname, "w");
-- 
1.7.10

[PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c

[Arnd Bergmann]

The con_debug_leave/con_debug_enter functions are stubbed out
by defining them to (0), which causes harmless build warnings.
Using proper inline functions is the normal way to deal with
this.

Without this patch, building the ARM bcm2835_defconfig results in:

drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 include/linux/console.h |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/console.h b/include/linux/console.h
index 7201ce4..dedb082 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -83,8 +83,14 @@ void give_up_console(const struct consw *sw);
 int con_debug_enter(struct vc_data *vc);
 int con_debug_leave(void);
 #else
-#define con_debug_enter(vc) (0)
-#define con_debug_leave() (0)
+static inline int con_debug_enter(struct vc_data *vc)
+{
+	return 0;
+}
+static inline int con_debug_leave(void)
+{
+	return 0;
+}
 #endif
 
 /* scroll */
-- 
1.7.10

[PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c

[Arnd Bergmann]

The con_debug_leave/con_debug_enter functions are stubbed out
by defining them to (0), which causes harmless build warnings.
Using proper inline functions is the normal way to deal with
this.

Without this patch, building the ARM bcm2835_defconfig results in:

drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 include/linux/console.h |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/console.h b/include/linux/console.h
index 7201ce4..dedb082 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -83,8 +83,14 @@ void give_up_console(const struct consw *sw);
 int con_debug_enter(struct vc_data *vc);
 int con_debug_leave(void);
 #else
-#define con_debug_enter(vc) (0)
-#define con_debug_leave() (0)
+static inline int con_debug_enter(struct vc_data *vc)
+{
+	return 0;
+}
+static inline int con_debug_leave(void)
+{
+	return 0;
+}
 #endif
 
 /* scroll */
-- 
1.7.10

[PATCH 10/12] gpio: pcf857x: select IRQ_DOMAIN

[Arnd Bergmann]

Patch 6e20a0a4 "gpio: pcf857x: enable gpio_to_irq() support"
added IRQ domain support to the pcf857x driver, but some configurations
(e.g. davinci_all_defconfig) don't already enable CONFIG_IRQ_DOMAIN.

Always selecting it from the Kconfig in this case is what other
such drivers do as well, and avoids these build errors:

Without this patch, building davinci_all_defconfig results in:

drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_to_irq':
drivers/gpio/gpio-pcf857x.c:167:2: error: implicit declaration of function 'irq_create_mapping'
drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_demux_work':
drivers/gpio/gpio-pcf857x.c:183:3: error: implicit declaration of function 'irq_find_mapping'
drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_domain_cleanup':
drivers/gpio/gpio-pcf857x.c:218:3: error: implicit declaration of function 'irq_domain_remove'
drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_domain_init':
drivers/gpio/gpio-pcf857x.c:230:2: error: implicit declaration of function 'irq_domain_add_linear'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0c05532..d055cee 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -336,6 +336,7 @@ config GPIO_PCA953X_IRQ
 config GPIO_PCF857X
 	tristate "PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders"
 	depends on I2C
+	select IRQ_DOMAIN
 	help
 	  Say yes here to provide access to most "quasi-bidirectional" I2C
 	  GPIO expanders used for additional digital outputs or inputs.
-- 
1.7.10

[PATCH 10/12] gpio: pcf857x: select IRQ_DOMAIN

[Arnd Bergmann]

Patch 6e20a0a4 "gpio: pcf857x: enable gpio_to_irq() support"
added IRQ domain support to the pcf857x driver, but some configurations
(e.g. davinci_all_defconfig) don't already enable CONFIG_IRQ_DOMAIN.

Always selecting it from the Kconfig in this case is what other
such drivers do as well, and avoids these build errors:

Without this patch, building davinci_all_defconfig results in:

drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_to_irq':
drivers/gpio/gpio-pcf857x.c:167:2: error: implicit declaration of function 'irq_create_mapping'
drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_demux_work':
drivers/gpio/gpio-pcf857x.c:183:3: error: implicit declaration of function 'irq_find_mapping'
drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_domain_cleanup':
drivers/gpio/gpio-pcf857x.c:218:3: error: implicit declaration of function 'irq_domain_remove'
drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_domain_init':
drivers/gpio/gpio-pcf857x.c:230:2: error: implicit declaration of function 'irq_domain_add_linear'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0c05532..d055cee 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -336,6 +336,7 @@ config GPIO_PCA953X_IRQ
 config GPIO_PCF857X
 	tristate "PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders"
 	depends on I2C
+	select IRQ_DOMAIN
 	help
 	  Say yes here to provide access to most "quasi-bidirectional" I2C
 	  GPIO expanders used for additional digital outputs or inputs.
-- 
1.7.10

[PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Arnd Bergmann]

The samsung pinctrl driver has a probe function that is
__devinit and that calls a lot of other functions that are
marked __init, which kbuild complains about.

Marking everything __devinit means that the code does not
discarded when CONFIG_HOTPLUG is set, which is a little
more wasteful, but also more consistent

Without this patch, building exynos_defconfig results in:

WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
The function __devinit samsung_pinctrl_probe() references
a function __init samsung_gpiolib_register().
If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
annotate samsung_gpiolib_register with a matching annotation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
---
 drivers/pinctrl/pinctrl-samsung.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index dd108a9..861cd5f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -513,7 +513,7 @@ static int samsung_gpio_direction_output(struct gpio_chip *gc, unsigned offset,
  * Parse the pin names listed in the 'samsung,pins' property and convert it
  * into a list of gpio numbers are create a pin group from it.
  */
-static int __init samsung_pinctrl_parse_dt_pins(struct platform_device *pdev,
+static int __devinit samsung_pinctrl_parse_dt_pins(struct platform_device *pdev,
 			struct device_node *cfg_np, struct pinctrl_desc *pctl,
 			unsigned int **pin_list, unsigned int *npins)
 {
@@ -560,7 +560,7 @@ static int __init samsung_pinctrl_parse_dt_pins(struct platform_device *pdev,
  * from device node of the pin-controller. A pin group is formed with all
  * the pins listed in the "samsung,pins" property.
  */
-static int __init samsung_pinctrl_parse_dt(struct platform_device *pdev,
+static int __devinit samsung_pinctrl_parse_dt(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct device *dev = &pdev->dev;
@@ -655,7 +655,7 @@ static int __init samsung_pinctrl_parse_dt(struct platform_device *pdev,
 }
 
 /* register the pinctrl interface with the pinctrl subsystem */
-static int __init samsung_pinctrl_register(struct platform_device *pdev,
+static int __devinit samsung_pinctrl_register(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct pinctrl_desc *ctrldesc = &drvdata->pctl;
@@ -729,7 +729,7 @@ static int __init samsung_pinctrl_register(struct platform_device *pdev,
 }
 
 /* register the gpiolib interface with the gpiolib subsystem */
-static int __init samsung_gpiolib_register(struct platform_device *pdev,
+static int __devinit samsung_gpiolib_register(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct gpio_chip *gc;
@@ -762,7 +762,7 @@ static int __init samsung_gpiolib_register(struct platform_device *pdev,
 }
 
 /* unregister the gpiolib interface with the gpiolib subsystem */
-static int __init samsung_gpiolib_unregister(struct platform_device *pdev,
+static int __devinit samsung_gpiolib_unregister(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	int ret = gpiochip_remove(drvdata->gc);
-- 
1.7.10

[PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Arnd Bergmann]

The samsung pinctrl driver has a probe function that is
__devinit and that calls a lot of other functions that are
marked __init, which kbuild complains about.

Marking everything __devinit means that the code does not
discarded when CONFIG_HOTPLUG is set, which is a little
more wasteful, but also more consistent

Without this patch, building exynos_defconfig results in:

WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
The function __devinit samsung_pinctrl_probe() references
a function __init samsung_gpiolib_register().
If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
annotate samsung_gpiolib_register with a matching annotation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
---
 drivers/pinctrl/pinctrl-samsung.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index dd108a9..861cd5f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -513,7 +513,7 @@ static int samsung_gpio_direction_output(struct gpio_chip *gc, unsigned offset,
  * Parse the pin names listed in the 'samsung,pins' property and convert it
  * into a list of gpio numbers are create a pin group from it.
  */
-static int __init samsung_pinctrl_parse_dt_pins(struct platform_device *pdev,
+static int __devinit samsung_pinctrl_parse_dt_pins(struct platform_device *pdev,
 			struct device_node *cfg_np, struct pinctrl_desc *pctl,
 			unsigned int **pin_list, unsigned int *npins)
 {
@@ -560,7 +560,7 @@ static int __init samsung_pinctrl_parse_dt_pins(struct platform_device *pdev,
  * from device node of the pin-controller. A pin group is formed with all
  * the pins listed in the "samsung,pins" property.
  */
-static int __init samsung_pinctrl_parse_dt(struct platform_device *pdev,
+static int __devinit samsung_pinctrl_parse_dt(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct device *dev = &pdev->dev;
@@ -655,7 +655,7 @@ static int __init samsung_pinctrl_parse_dt(struct platform_device *pdev,
 }
 
 /* register the pinctrl interface with the pinctrl subsystem */
-static int __init samsung_pinctrl_register(struct platform_device *pdev,
+static int __devinit samsung_pinctrl_register(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct pinctrl_desc *ctrldesc = &drvdata->pctl;
@@ -729,7 +729,7 @@ static int __init samsung_pinctrl_register(struct platform_device *pdev,
 }
 
 /* register the gpiolib interface with the gpiolib subsystem */
-static int __init samsung_gpiolib_register(struct platform_device *pdev,
+static int __devinit samsung_gpiolib_register(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct gpio_chip *gc;
@@ -762,7 +762,7 @@ static int __init samsung_gpiolib_register(struct platform_device *pdev,
 }
 
 /* unregister the gpiolib interface with the gpiolib subsystem */
-static int __init samsung_gpiolib_unregister(struct platform_device *pdev,
+static int __devinit samsung_gpiolib_unregister(struct platform_device *pdev,
 				struct samsung_pinctrl_drv_data *drvdata)
 {
 	int ret = gpiochip_remove(drvdata->gc);
-- 
1.7.10

[PATCH 12/12] time/jiffies: bring back unconditional LATCH definition

[Arnd Bergmann]

Patch a7ea3bbf5d "time/jiffies: Allow CLOCK_TICK_RATE to be undefined"
breaks the compilation of targets that rely on the LATCH definition,
because of recursive header file inclusion not defining CLOCK_TICK_RATE
before it is checked here.

This fixes the problem by moving LATCH back to where it was, but it
seems that there are still cases where SHIFTED_HZ is defined incorrectly
because of the same problem. Need to investigate further.

Without this patch, building h7201_defconfig results in:

arch/arm/mach-h720x/common.c: In function 'h720x_gettimeoffset':
arch/arm/mach-h720x/common.c:50:73: error: 'LATCH' undeclared (first use in this function)
arch/arm/mach-h720x/common.c:50:73: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/mach-h720x/common.c:51:1: warning: control reaches end of non-void function [-Wreturn-type]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
---
 include/linux/jiffies.h |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 05e3c2c7..d229ada 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -51,9 +51,10 @@
 #define SH_DIV(NOM,DEN,LSH) (   (((NOM) / (DEN)) << (LSH))              \
                              + ((((NOM) % (DEN)) << (LSH)) + (DEN) / 2) / (DEN))
 
-#ifdef CLOCK_TICK_RATE
 /* LATCH is used in the interval timer and ftape setup. */
-# define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
+#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
+
+#ifdef CLOCK_TICK_RATE
 
 /*
  * HZ is the requested value. However the CLOCK_TICK_RATE may not allow
-- 
1.7.10

[PATCH 12/12] time/jiffies: bring back unconditional LATCH definition

[Arnd Bergmann]

Patch a7ea3bbf5d "time/jiffies: Allow CLOCK_TICK_RATE to be undefined"
breaks the compilation of targets that rely on the LATCH definition,
because of recursive header file inclusion not defining CLOCK_TICK_RATE
before it is checked here.

This fixes the problem by moving LATCH back to where it was, but it
seems that there are still cases where SHIFTED_HZ is defined incorrectly
because of the same problem. Need to investigate further.

Without this patch, building h7201_defconfig results in:

arch/arm/mach-h720x/common.c: In function 'h720x_gettimeoffset':
arch/arm/mach-h720x/common.c:50:73: error: 'LATCH' undeclared (first use in this function)
arch/arm/mach-h720x/common.c:50:73: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/mach-h720x/common.c:51:1: warning: control reaches end of non-void function [-Wreturn-type]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
---
 include/linux/jiffies.h |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 05e3c2c7..d229ada 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -51,9 +51,10 @@
 #define SH_DIV(NOM,DEN,LSH) (   (((NOM) / (DEN)) << (LSH))              \
                              + ((((NOM) % (DEN)) << (LSH)) + (DEN) / 2) / (DEN))
 
-#ifdef CLOCK_TICK_RATE
 /* LATCH is used in the interval timer and ftape setup. */
-# define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
+#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
+
+#ifdef CLOCK_TICK_RATE
 
 /*
  * HZ is the requested value. However the CLOCK_TICK_RATE may not allow
-- 
1.7.10

Re: [PATCH 02/12] ata: mark probe function as __devinit rather than __init

[Mark Langsdorf]

On 09/28/2012 04:36 PM, Arnd Bergmann wrote:
> Functions for hotplugging must be marked as __devinit so
> they do not get discarded, as pointed out by a build time
> warning from modpost.
> 
> Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Jeff Garzik <jgarzik@redhat.com>
> ---
>  drivers/ata/sata_highbank.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c
> index 0d7c4c2..36a141a 100644
> --- a/drivers/ata/sata_highbank.c
> +++ b/drivers/ata/sata_highbank.c
> @@ -260,7 +260,7 @@ static const struct of_device_id ahci_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, ahci_of_match);
>  
> -static int __init ahci_highbank_probe(struct platform_device *pdev)
> +static int __devinit ahci_highbank_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
>  	struct ahci_host_priv *hpriv;

Thanks. I just ran into this today and couldn't figure out the error
message.

Acked-by: Mark Langsdorf <mark.langsdorf@calxeda.com>

--Mark Langsdorf
Calxeda, Inc.

[PATCH 02/12] ata: mark probe function as __devinit rather than __init

[Mark Langsdorf]

On 09/28/2012 04:36 PM, Arnd Bergmann wrote:
> Functions for hotplugging must be marked as __devinit so
> they do not get discarded, as pointed out by a build time
> warning from modpost.
> 
> Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Jeff Garzik <jgarzik@redhat.com>
> ---
>  drivers/ata/sata_highbank.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c
> index 0d7c4c2..36a141a 100644
> --- a/drivers/ata/sata_highbank.c
> +++ b/drivers/ata/sata_highbank.c
> @@ -260,7 +260,7 @@ static const struct of_device_id ahci_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, ahci_of_match);
>  
> -static int __init ahci_highbank_probe(struct platform_device *pdev)
> +static int __devinit ahci_highbank_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
>  	struct ahci_host_priv *hpriv;

Thanks. I just ran into this today and couldn't figure out the error
message.

Acked-by: Mark Langsdorf <mark.langsdorf@calxeda.com>

--Mark Langsdorf
Calxeda, Inc.

Re: [PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c

[Jason Wessel]

On 09/28/2012 04:36 PM, Arnd Bergmann wrote:
> The con_debug_leave/con_debug_enter functions are stubbed out
> by defining them to (0), which causes harmless build warnings.
> Using proper inline functions is the normal way to deal with
> this.
>
> Without this patch, building the ARM bcm2835_defconfig results in:
>
> drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
> drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
> drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
> drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]


Thanks Arnd!

I'll put this in kgdb-next for the upcoming merge window, unless Greg pulls it into his queue first.

Acked-by: Jason Wessel <jason.wessel@windriver.com>

Cheers,
Jason.

[PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c

[Jason Wessel]

On 09/28/2012 04:36 PM, Arnd Bergmann wrote:
> The con_debug_leave/con_debug_enter functions are stubbed out
> by defining them to (0), which causes harmless build warnings.
> Using proper inline functions is the normal way to deal with
> this.
>
> Without this patch, building the ARM bcm2835_defconfig results in:
>
> drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
> drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
> drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
> drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]


Thanks Arnd!

I'll put this in kgdb-next for the upcoming merge window, unless Greg pulls it into his queue first.

Acked-by: Jason Wessel <jason.wessel@windriver.com>

Cheers,
Jason.

Re: [PATCH 08/12] dtc: be more quiet with "make -s"

[Stephen Warren]

On 09/28/2012 03:36 PM, Arnd Bergmann wrote:
> On a normal build, we get output from both make and from dtc
> about each file that is being processed.
> 
>   DTC     arch/arm/boot/vexpress-v2p-ca5s.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca5s.dts"
>   DTC     arch/arm/boot/vexpress-v2p-ca9.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca9.dts"
>   DTC     arch/arm/boot/vexpress-v2p-ca15-tc1.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts"
>   DTC     arch/arm/boot/vexpress-v2p-ca15_a7.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts"
> 
> When both lines refer to the same action. When building with "make -s",
> the "DTC: dts->dtb ..." line is the only output we currently get.
> 
> This patch makes dtc not output the message when the "-q" flag is passed,
> and ensures that we pass it in both cases.

Just as an FYI, the upstream dtc no longer prints this message, and I
just posted a patch to pull that whole upstream dtc into the kernel.

[PATCH 08/12] dtc: be more quiet with "make -s"

[Stephen Warren]

On 09/28/2012 03:36 PM, Arnd Bergmann wrote:
> On a normal build, we get output from both make and from dtc
> about each file that is being processed.
> 
>   DTC     arch/arm/boot/vexpress-v2p-ca5s.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca5s.dts"
>   DTC     arch/arm/boot/vexpress-v2p-ca9.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca9.dts"
>   DTC     arch/arm/boot/vexpress-v2p-ca15-tc1.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts"
>   DTC     arch/arm/boot/vexpress-v2p-ca15_a7.dtb
> DTC: dts->dtb  on file "/git/arnd/linux-arm/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts"
> 
> When both lines refer to the same action. When building with "make -s",
> the "DTC: dts->dtb ..." line is the only output we currently get.
> 
> This patch makes dtc not output the message when the "-q" flag is passed,
> and ensures that we pass it in both cases.

Just as an FYI, the upstream dtc no longer prints this message, and I
just posted a patch to pull that whole upstream dtc into the kernel.

Re: [PATCH 12/12] time/jiffies: bring back unconditional LATCH definition

[John Stultz]

On 09/28/2012 02:36 PM, Arnd Bergmann wrote:
> Patch a7ea3bbf5d "time/jiffies: Allow CLOCK_TICK_RATE to be undefined"
> breaks the compilation of targets that rely on the LATCH definition,
> because of recursive header file inclusion not defining CLOCK_TICK_RATE
> before it is checked here.
>
> This fixes the problem by moving LATCH back to where it was, but it
> seems that there are still cases where SHIFTED_HZ is defined incorrectly
> because of the same problem. Need to investigate further.
>
> Without this patch, building h7201_defconfig results in:
>
> arch/arm/mach-h720x/common.c: In function 'h720x_gettimeoffset':
> arch/arm/mach-h720x/common.c:50:73: error: 'LATCH' undeclared (first use in this function)
> arch/arm/mach-h720x/common.c:50:73: note: each undeclared identifier is reported only once for each function it appears in
> arch/arm/mach-h720x/common.c:51:1: warning: control reaches end of non-void function [-Wreturn-type]

Hrrm. Ok. I had a patch for 3.7 that tried to get rid of the generic 
CLOCK_TICK_RATE derived users, but that may not fly if there's still 
LATCH users around.  I guess I'll tweak it so we keep LATCH around, 
probably by mering your change into my tree.

I suspect the long term fix is to push the LATCH definition up into arch 
specific code that is using it, so it can be made dynamic instead of a 
compile time constant. Otherwise it might be hard to get a unified 
zImage working.  But for now I guess your current fix is good short-term.

thanks
-john

[PATCH 12/12] time/jiffies: bring back unconditional LATCH definition

[John Stultz]

On 09/28/2012 02:36 PM, Arnd Bergmann wrote:
> Patch a7ea3bbf5d "time/jiffies: Allow CLOCK_TICK_RATE to be undefined"
> breaks the compilation of targets that rely on the LATCH definition,
> because of recursive header file inclusion not defining CLOCK_TICK_RATE
> before it is checked here.
>
> This fixes the problem by moving LATCH back to where it was, but it
> seems that there are still cases where SHIFTED_HZ is defined incorrectly
> because of the same problem. Need to investigate further.
>
> Without this patch, building h7201_defconfig results in:
>
> arch/arm/mach-h720x/common.c: In function 'h720x_gettimeoffset':
> arch/arm/mach-h720x/common.c:50:73: error: 'LATCH' undeclared (first use in this function)
> arch/arm/mach-h720x/common.c:50:73: note: each undeclared identifier is reported only once for each function it appears in
> arch/arm/mach-h720x/common.c:51:1: warning: control reaches end of non-void function [-Wreturn-type]

Hrrm. Ok. I had a patch for 3.7 that tried to get rid of the generic 
CLOCK_TICK_RATE derived users, but that may not fly if there's still 
LATCH users around.  I guess I'll tweak it so we keep LATCH around, 
probably by mering your change into my tree.

I suspect the long term fix is to push the LATCH definition up into arch 
specific code that is using it, so it can be made dynamic instead of a 
compile time constant. Otherwise it might be hard to get a unified 
zImage working.  But for now I guess your current fix is good short-term.

thanks
-john

Re: [PATCH 08/12] dtc: be more quiet with "make -s"

[Arnd Bergmann]

On Friday 28 September 2012, Stephen Warren wrote:
> On 09/28/2012 03:36 PM, Arnd Bergmann wrote:
> > This patch makes dtc not output the message when the "-q" flag is passed,
> > and ensures that we pass it in both cases.
> 
> Just as an FYI, the upstream dtc no longer prints this message, and I
> just posted a patch to pull that whole upstream dtc into the kernel.

Ok, excellent!

Michal, please ignore my patch then.

	Arnd

[PATCH 08/12] dtc: be more quiet with "make -s"

[Arnd Bergmann]

On Friday 28 September 2012, Stephen Warren wrote:
> On 09/28/2012 03:36 PM, Arnd Bergmann wrote:
> > This patch makes dtc not output the message when the "-q" flag is passed,
> > and ensures that we pass it in both cases.
> 
> Just as an FYI, the upstream dtc no longer prints this message, and I
> just posted a patch to pull that whole upstream dtc into the kernel.

Ok, excellent!

Michal, please ignore my patch then.

	Arnd

Re: [PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Jonathan Cameron]

On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
> The driver has not been building for some time after the
> irq_to_gpio function has been removed from the kernel.
> 
> The only board in the upstream kernel that provides
> this device is the "Stargate 2", which is also maintained
> by Jonathan Cameron. Rather than working around the problem
> by adding new platform data for this driver, this patch
> uses the of_gpio framework to get to the gpio number.
> 
> However, the stargate2 code does not (yet) use DT based
> probing, so it is still broken, but at least building
> allyesconfig works again.
Will be optimistic to think anyone will convert a platform
that no one still makes (stargate 2 was pretty much intel
research only + some they gave to accademics - imote2 has
been dropped by memsic for a while now.)  If nothing else
there is little chance anyone will bother porting a remotely
up to date bootloader to these boards given how few people
are still using them for anything.

I'm happy enough with this patch.  Would prefer to
take it post merge window as a fix than now given timing.

Long run this driver will hopefully get replaced by the
unified driver for all the st accelerometers (assuming that
ever gets back to this long obsolete part).

Thanks for the patch Arnd, I've been ignoring this one on
the basis it would go away for far too long. Sorry about that!

> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/staging/iio/accel/lis3l02dq.h      |    1 +
>  drivers/staging/iio/accel/lis3l02dq_core.c |   10 ++++++----
>  drivers/staging/iio/accel/lis3l02dq_ring.c |    2 +-
>  3 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/lis3l02dq.h b/drivers/staging/iio/accel/lis3l02dq.h
> index f9bcd41..2bac722 100644
> --- a/drivers/staging/iio/accel/lis3l02dq.h
> +++ b/drivers/staging/iio/accel/lis3l02dq.h
> @@ -158,6 +158,7 @@ struct lis3l02dq_state {
>  	struct spi_device		*us;
>  	struct iio_trigger		*trig;
>  	struct mutex			buf_lock;
> +	int				gpio;
>  	bool				trigger_on;
>  
>  	u8	tx[LIS3L02DQ_MAX_RX] ____cacheline_aligned;
> diff --git a/drivers/staging/iio/accel/lis3l02dq_core.c b/drivers/staging/iio/accel/lis3l02dq_core.c
> index 21b0469..d13c7e9 100644
> --- a/drivers/staging/iio/accel/lis3l02dq_core.c
> +++ b/drivers/staging/iio/accel/lis3l02dq_core.c
> @@ -15,6 +15,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
>  #include <linux/gpio.h>
> +#include <linux/of_gpio.h>
>  #include <linux/mutex.h>
>  #include <linux/device.h>
>  #include <linux/kernel.h>
> @@ -690,6 +691,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
>  	spi_set_drvdata(spi, indio_dev);
>  
>  	st->us = spi;
> +	st->gpio = of_get_gpio(spi->dev.of_node, 0);
>  	mutex_init(&st->buf_lock);
>  	indio_dev->name = spi->dev.driver->name;
>  	indio_dev->dev.parent = &spi->dev;
> @@ -711,7 +713,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
>  		goto error_unreg_buffer_funcs;
>  	}
>  
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0) {
> +	if (spi->irq) {
>  		ret = request_threaded_irq(st->us->irq,
>  					   &lis3l02dq_th,
>  					   &lis3l02dq_event_handler,
> @@ -738,10 +740,10 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
>  	return 0;
>  
>  error_remove_trigger:
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)))
> +	if (spi->irq)
>  		lis3l02dq_remove_trigger(indio_dev);
>  error_free_interrupt:
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
> +	if (spi->irq)
>  		free_irq(st->us->irq, indio_dev);
>  error_uninitialize_buffer:
>  	iio_buffer_unregister(indio_dev);
> @@ -790,7 +792,7 @@ static int __devexit lis3l02dq_remove(struct spi_device *spi)
>  	lis3l02dq_disable_all_events(indio_dev);
>  	lis3l02dq_stop_device(indio_dev);
>  
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
> +	if (spi->irq)
>  		free_irq(st->us->irq, indio_dev);
>  
>  	lis3l02dq_remove_trigger(indio_dev);
> diff --git a/drivers/staging/iio/accel/lis3l02dq_ring.c b/drivers/staging/iio/accel/lis3l02dq_ring.c
> index fa4190d..13c0b4b 100644
> --- a/drivers/staging/iio/accel/lis3l02dq_ring.c
> +++ b/drivers/staging/iio/accel/lis3l02dq_ring.c
> @@ -263,7 +263,7 @@ static int lis3l02dq_trig_try_reen(struct iio_trigger *trig)
>  	/* If gpio still high (or high again)
>  	 * In theory possible we will need to do this several times */
>  	for (i = 0; i < 5; i++)
> -		if (gpio_get_value(irq_to_gpio(st->us->irq)))
> +		if (gpio_get_value(st->gpio))
>  			lis3l02dq_read_all(indio_dev, NULL);
>  		else
>  			break;
> 

[PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Jonathan Cameron]

On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
> The driver has not been building for some time after the
> irq_to_gpio function has been removed from the kernel.
> 
> The only board in the upstream kernel that provides
> this device is the "Stargate 2", which is also maintained
> by Jonathan Cameron. Rather than working around the problem
> by adding new platform data for this driver, this patch
> uses the of_gpio framework to get to the gpio number.
> 
> However, the stargate2 code does not (yet) use DT based
> probing, so it is still broken, but at least building
> allyesconfig works again.
Will be optimistic to think anyone will convert a platform
that no one still makes (stargate 2 was pretty much intel
research only + some they gave to accademics - imote2 has
been dropped by memsic for a while now.)  If nothing else
there is little chance anyone will bother porting a remotely
up to date bootloader to these boards given how few people
are still using them for anything.

I'm happy enough with this patch.  Would prefer to
take it post merge window as a fix than now given timing.

Long run this driver will hopefully get replaced by the
unified driver for all the st accelerometers (assuming that
ever gets back to this long obsolete part).

Thanks for the patch Arnd, I've been ignoring this one on
the basis it would go away for far too long. Sorry about that!

> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/staging/iio/accel/lis3l02dq.h      |    1 +
>  drivers/staging/iio/accel/lis3l02dq_core.c |   10 ++++++----
>  drivers/staging/iio/accel/lis3l02dq_ring.c |    2 +-
>  3 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/lis3l02dq.h b/drivers/staging/iio/accel/lis3l02dq.h
> index f9bcd41..2bac722 100644
> --- a/drivers/staging/iio/accel/lis3l02dq.h
> +++ b/drivers/staging/iio/accel/lis3l02dq.h
> @@ -158,6 +158,7 @@ struct lis3l02dq_state {
>  	struct spi_device		*us;
>  	struct iio_trigger		*trig;
>  	struct mutex			buf_lock;
> +	int				gpio;
>  	bool				trigger_on;
>  
>  	u8	tx[LIS3L02DQ_MAX_RX] ____cacheline_aligned;
> diff --git a/drivers/staging/iio/accel/lis3l02dq_core.c b/drivers/staging/iio/accel/lis3l02dq_core.c
> index 21b0469..d13c7e9 100644
> --- a/drivers/staging/iio/accel/lis3l02dq_core.c
> +++ b/drivers/staging/iio/accel/lis3l02dq_core.c
> @@ -15,6 +15,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
>  #include <linux/gpio.h>
> +#include <linux/of_gpio.h>
>  #include <linux/mutex.h>
>  #include <linux/device.h>
>  #include <linux/kernel.h>
> @@ -690,6 +691,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
>  	spi_set_drvdata(spi, indio_dev);
>  
>  	st->us = spi;
> +	st->gpio = of_get_gpio(spi->dev.of_node, 0);
>  	mutex_init(&st->buf_lock);
>  	indio_dev->name = spi->dev.driver->name;
>  	indio_dev->dev.parent = &spi->dev;
> @@ -711,7 +713,7 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
>  		goto error_unreg_buffer_funcs;
>  	}
>  
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0) {
> +	if (spi->irq) {
>  		ret = request_threaded_irq(st->us->irq,
>  					   &lis3l02dq_th,
>  					   &lis3l02dq_event_handler,
> @@ -738,10 +740,10 @@ static int __devinit lis3l02dq_probe(struct spi_device *spi)
>  	return 0;
>  
>  error_remove_trigger:
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)))
> +	if (spi->irq)
>  		lis3l02dq_remove_trigger(indio_dev);
>  error_free_interrupt:
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
> +	if (spi->irq)
>  		free_irq(st->us->irq, indio_dev);
>  error_uninitialize_buffer:
>  	iio_buffer_unregister(indio_dev);
> @@ -790,7 +792,7 @@ static int __devexit lis3l02dq_remove(struct spi_device *spi)
>  	lis3l02dq_disable_all_events(indio_dev);
>  	lis3l02dq_stop_device(indio_dev);
>  
> -	if (spi->irq && gpio_is_valid(irq_to_gpio(spi->irq)) > 0)
> +	if (spi->irq)
>  		free_irq(st->us->irq, indio_dev);
>  
>  	lis3l02dq_remove_trigger(indio_dev);
> diff --git a/drivers/staging/iio/accel/lis3l02dq_ring.c b/drivers/staging/iio/accel/lis3l02dq_ring.c
> index fa4190d..13c0b4b 100644
> --- a/drivers/staging/iio/accel/lis3l02dq_ring.c
> +++ b/drivers/staging/iio/accel/lis3l02dq_ring.c
> @@ -263,7 +263,7 @@ static int lis3l02dq_trig_try_reen(struct iio_trigger *trig)
>  	/* If gpio still high (or high again)
>  	 * In theory possible we will need to do this several times */
>  	for (i = 0; i < 5; i++)
> -		if (gpio_get_value(irq_to_gpio(st->us->irq)))
> +		if (gpio_get_value(st->gpio))
>  			lis3l02dq_read_all(indio_dev, NULL);
>  		else
>  			break;
> 

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

Arnd Bergmann <arnd@arndb.de> writes:

> Krzysztof, please apply in your next branch so this problem goes away in
> 3.8.

Right, I'll look at it.

> I realize it won't make 3.7 any more since the base patches are not
> in arm-soc, but it's bad if linux-next is broken.

Well, I'm not aware of any requirement to push my IXP4xx changes
exclusively through arm-soc. I believe I can still send my tree straight
to Linus.

My tree is fairly isolated (with one trivial patch in need of ack from
Russell, but I can remove that) and, to be honest, I can't see any
benefit to anyone, caused by sending through intermediate trees. In
fact, now that I have at last a bit of spare time to work on IXP4xx
again (acquired some IXP435 devices), such requirement would only mean
extra workload to me.

Could you please point me to a statement requiring eg. my changes to go
through arm-soc?

Thanks.
-- 
Krzysztof Halasa

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

Arnd Bergmann <arnd@arndb.de> writes:

> Krzysztof, please apply in your next branch so this problem goes away in
> 3.8.

Right, I'll look at it.

> I realize it won't make 3.7 any more since the base patches are not
> in arm-soc, but it's bad if linux-next is broken.

Well, I'm not aware of any requirement to push my IXP4xx changes
exclusively through arm-soc. I believe I can still send my tree straight
to Linus.

My tree is fairly isolated (with one trivial patch in need of ack from
Russell, but I can remove that) and, to be honest, I can't see any
benefit to anyone, caused by sending through intermediate trees. In
fact, now that I have at last a bit of spare time to work on IXP4xx
again (acquired some IXP435 devices), such requirement would only mean
extra workload to me.

Could you please point me to a statement requiring eg. my changes to go
through arm-soc?

Thanks.
-- 
Krzysztof Halasa

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Arnd Bergmann]

On Saturday 29 September 2012, Krzysztof Halasa wrote:
> > I realize it won't make 3.7 any more since the base patches are not
> > in arm-soc, but it's bad if linux-next is broken.
> 
> Well, I'm not aware of any requirement to push my IXP4xx changes
> exclusively through arm-soc. I believe I can still send my tree straight
> to Linus.

No, we don't do that any more, all ARM related changes go either
through arm-soc (for mach-* and plat-* as well as a few related bits)
or through Russell's arm tree (for everything else).

We can make exceptions for stuff that has interdependencies with other
subsystems and can Ack patches if you want to have them included in
another subsystem tree.

> My tree is fairly isolated (with one trivial patch in need of ack from
> Russell, but I can remove that) and, to be honest, I can't see any
> benefit to anyone, caused by sending through intermediate trees. In
> fact, now that I have at last a bit of spare time to work on IXP4xx
> again (acquired some IXP435 devices), such requirement would only mean
> extra workload to me.
> 
> Could you please point me to a statement requiring eg. my changes to go
> through arm-soc?


We've been doing it like this for some time. Stephen Warren replied
to your request to add your tree to linux-next in

http://comments.gmane.org/gmane.linux.kernel/1356118

explaining how it works. Olof sent a mail last week in 

http://lkml.org/lkml/2012/9/21/31

explaining that we're closing the window for 3.7 except for a
few things that were already submitted earlier.

You are definitely welcome to send your pull request for arm-soc
after the merge window so we can integrate it into the 3.8 series,
and please send any bug fixes you have for immediate integration
at any time to arm@kernel.org. There may be a few other things 
in the process that are new to you, but we can work that out.

The arm-soc process is definitely meant to make your life easier
as well as help Linus understand what's going on with all of ARM
to the degree that he needs to know, but it only works if everyone
participates.

	Arnd

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Arnd Bergmann]

On Saturday 29 September 2012, Krzysztof Halasa wrote:
> > I realize it won't make 3.7 any more since the base patches are not
> > in arm-soc, but it's bad if linux-next is broken.
> 
> Well, I'm not aware of any requirement to push my IXP4xx changes
> exclusively through arm-soc. I believe I can still send my tree straight
> to Linus.

No, we don't do that any more, all ARM related changes go either
through arm-soc (for mach-* and plat-* as well as a few related bits)
or through Russell's arm tree (for everything else).

We can make exceptions for stuff that has interdependencies with other
subsystems and can Ack patches if you want to have them included in
another subsystem tree.

> My tree is fairly isolated (with one trivial patch in need of ack from
> Russell, but I can remove that) and, to be honest, I can't see any
> benefit to anyone, caused by sending through intermediate trees. In
> fact, now that I have at last a bit of spare time to work on IXP4xx
> again (acquired some IXP435 devices), such requirement would only mean
> extra workload to me.
> 
> Could you please point me to a statement requiring eg. my changes to go
> through arm-soc?


We've been doing it like this for some time. Stephen Warren replied
to your request to add your tree to linux-next in

http://comments.gmane.org/gmane.linux.kernel/1356118

explaining how it works. Olof sent a mail last week in 

http://lkml.org/lkml/2012/9/21/31

explaining that we're closing the window for 3.7 except for a
few things that were already submitted earlier.

You are definitely welcome to send your pull request for arm-soc
after the merge window so we can integrate it into the 3.8 series,
and please send any bug fixes you have for immediate integration
at any time to arm at kernel.org. There may be a few other things 
in the process that are new to you, but we can work that out.

The arm-soc process is definitely meant to make your life easier
as well as help Linus understand what's going on with all of ARM
to the degree that he needs to know, but it only works if everyone
participates.

	Arnd

Re: [PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Arnd Bergmann]

On Saturday 29 September 2012, Jonathan Cameron wrote:
> On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
> > The driver has not been building for some time after the
> > irq_to_gpio function has been removed from the kernel.
> > 
> > The only board in the upstream kernel that provides
> > this device is the "Stargate 2", which is also maintained
> > by Jonathan Cameron. Rather than working around the problem
> > by adding new platform data for this driver, this patch
> > uses the of_gpio framework to get to the gpio number.
> > 
> > However, the stargate2 code does not (yet) use DT based
> > probing, so it is still broken, but at least building
> > allyesconfig works again.
> Will be optimistic to think anyone will convert a platform
> that no one still makes (stargate 2 was pretty much intel
> research only + some they gave to accademics - imote2 has
> been dropped by memsic for a while now.)  If nothing else
> there is little chance anyone will bother porting a remotely
> up to date bootloader to these boards given how few people
> are still using them for anything.

The way are converting most ARM platforms to DT, we should be
able to replace the board files with .dts files once all
device drivers have been converted over. This is taking a
bit longer for mmp/pxa than for some of the other platforms,
Updating the boot loader makes it easier to deploy a DT
version, but you can also append a DT blob to the kernel
if that's not possible, and we will in the future allow
appending multiple DT blobs and let the early boot stages
pick the right one based on the board ID.

> I'm happy enough with this patch.  Would prefer to
> take it post merge window as a fix than now given timing.

Ok, fair enough. It has been broken for a while, so there
is no hurry now. I just stumbled over it when doing an
"allyesconfig" build.

> Long run this driver will hopefully get replaced by the
> unified driver for all the st accelerometers (assuming that
> ever gets back to this long obsolete part).

Ok.

	Arnd

[PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Arnd Bergmann]

On Saturday 29 September 2012, Jonathan Cameron wrote:
> On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
> > The driver has not been building for some time after the
> > irq_to_gpio function has been removed from the kernel.
> > 
> > The only board in the upstream kernel that provides
> > this device is the "Stargate 2", which is also maintained
> > by Jonathan Cameron. Rather than working around the problem
> > by adding new platform data for this driver, this patch
> > uses the of_gpio framework to get to the gpio number.
> > 
> > However, the stargate2 code does not (yet) use DT based
> > probing, so it is still broken, but at least building
> > allyesconfig works again.
> Will be optimistic to think anyone will convert a platform
> that no one still makes (stargate 2 was pretty much intel
> research only + some they gave to accademics - imote2 has
> been dropped by memsic for a while now.)  If nothing else
> there is little chance anyone will bother porting a remotely
> up to date bootloader to these boards given how few people
> are still using them for anything.

The way are converting most ARM platforms to DT, we should be
able to replace the board files with .dts files once all
device drivers have been converted over. This is taking a
bit longer for mmp/pxa than for some of the other platforms,
Updating the boot loader makes it easier to deploy a DT
version, but you can also append a DT blob to the kernel
if that's not possible, and we will in the future allow
appending multiple DT blobs and let the early boot stages
pick the right one based on the board ID.

> I'm happy enough with this patch.  Would prefer to
> take it post merge window as a fix than now given timing.

Ok, fair enough. It has been broken for a while, so there
is no hurry now. I just stumbled over it when doing an
"allyesconfig" build.

> Long run this driver will hopefully get replaced by the
> unified driver for all the st accelerometers (assuming that
> ever gets back to this long obsolete part).

Ok.

	Arnd

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

Arnd Bergmann <arnd@arndb.de> writes:

>> Could you please point me to a statement requiring eg. my changes to go
>> through arm-soc?
>
> We've been doing it like this for some time. Stephen Warren replied
> to your request to add your tree to linux-next in
>
> http://comments.gmane.org/gmane.linux.kernel/1356118
>
> explaining how it works. Olof sent a mail last week in 
>
> http://lkml.org/lkml/2012/9/21/31
>
> explaining that we're closing the window for 3.7 except for a
> few things that were already submitted earlier.

No offense, but... You say how does it work for YOU but that's not
exactly what I'm asking for. I'm asking for a statement that it's not OK
for me to push my IXP4xx changes straight to Linus.

> The arm-soc process is definitely meant to make your life easier
> as well as help Linus understand what's going on with all of ARM
> to the degree that he needs to know, but it only works if everyone
> participates.

I'd like to know how is it easier for me. Actually, I think it would
only make things worse for everyone (mostly for me). Also, I can't see
how "it only works if everyone participates" is true.

I'm currently supporting (for our internal needs) hw platforms based
on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required
so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current
tree since it's the next stable. The hw is e.g. Gateworks' platforms
with code taken from e.g. OpenWRT. I hope to have most of this in Linus'
tree when it's eventually ready. Unfortunately, I'm just one man, and
the above is only a slim part of my work. Egoistically, I don't think
I'm currently willing to spend time with arm-soc tree, if I can't see
any real technical benefit to anyone.

It would be different if my tree included e.g. core ARM changes - but it
doesn't. What's the _real_ reason for asking me to push my changes
indirectly?

Also, not that it's the most important, but how is it better for anyone
to delay changes - which are completely orthogonal to arm-soc - for
additional months? Doesn't "release early, release often" make sense
anymore?
-- 
Krzysztof Halasa

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

Arnd Bergmann <arnd@arndb.de> writes:

>> Could you please point me to a statement requiring eg. my changes to go
>> through arm-soc?
>
> We've been doing it like this for some time. Stephen Warren replied
> to your request to add your tree to linux-next in
>
> http://comments.gmane.org/gmane.linux.kernel/1356118
>
> explaining how it works. Olof sent a mail last week in 
>
> http://lkml.org/lkml/2012/9/21/31
>
> explaining that we're closing the window for 3.7 except for a
> few things that were already submitted earlier.

No offense, but... You say how does it work for YOU but that's not
exactly what I'm asking for. I'm asking for a statement that it's not OK
for me to push my IXP4xx changes straight to Linus.

> The arm-soc process is definitely meant to make your life easier
> as well as help Linus understand what's going on with all of ARM
> to the degree that he needs to know, but it only works if everyone
> participates.

I'd like to know how is it easier for me. Actually, I think it would
only make things worse for everyone (mostly for me). Also, I can't see
how "it only works if everyone participates" is true.

I'm currently supporting (for our internal needs) hw platforms based
on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required
so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current
tree since it's the next stable. The hw is e.g. Gateworks' platforms
with code taken from e.g. OpenWRT. I hope to have most of this in Linus'
tree when it's eventually ready. Unfortunately, I'm just one man, and
the above is only a slim part of my work. Egoistically, I don't think
I'm currently willing to spend time with arm-soc tree, if I can't see
any real technical benefit to anyone.

It would be different if my tree included e.g. core ARM changes - but it
doesn't. What's the _real_ reason for asking me to push my changes
indirectly?

Also, not that it's the most important, but how is it better for anyone
to delay changes - which are completely orthogonal to arm-soc - for
additional months? Doesn't "release early, release often" make sense
anymore?
-- 
Krzysztof Halasa

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Olof Johansson]

On Sat, Sep 29, 2012 at 10:02 AM, Krzysztof Halasa <khc@pm.waw.pl> wrote:

> It would be different if my tree included e.g. core ARM changes - but it
> doesn't. What's the _real_ reason for asking me to push my changes
> indirectly?

The reason is that when all ARM platform maintainers pushed code
straight to Linus, no one was making sure that the code meets a
quality bar and each vendor only focused on just their own stuff.

As an end result, over the years lots of crap got pushed straight to
Linus, code that we have now spent about a year and a half doing
massive cleanups and restructurings of. No vendors really talked to
each other, all of them solved their own problems their own way
without figuring out how to work better together and build
infrastructure for their common requirements. Linus finally lost his
patience with the massive churn of duplicated reinvented code and
there was a huge blow up about it. See http://lwn.net/Articles/439326/
for background.

> Also, not that it's the most important, but how is it better for anyone
> to delay changes - which are completely orthogonal to arm-soc - for
> additional months? Doesn't "release early, release often" make sense
> anymore?

Nothing is delayed by going through arm-soc. We're closing down our
tree for new (large) pull requests around the same time where you
should no longer add them to your -next branch either (-rc6/-rc7 time
frame).

Small fixups, and of course bugfixes, are welcome closer to the merge
window but the major chances should all have landed by then.


-Olof

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Olof Johansson]

On Sat, Sep 29, 2012 at 10:02 AM, Krzysztof Halasa <khc@pm.waw.pl> wrote:

> It would be different if my tree included e.g. core ARM changes - but it
> doesn't. What's the _real_ reason for asking me to push my changes
> indirectly?

The reason is that when all ARM platform maintainers pushed code
straight to Linus, no one was making sure that the code meets a
quality bar and each vendor only focused on just their own stuff.

As an end result, over the years lots of crap got pushed straight to
Linus, code that we have now spent about a year and a half doing
massive cleanups and restructurings of. No vendors really talked to
each other, all of them solved their own problems their own way
without figuring out how to work better together and build
infrastructure for their common requirements. Linus finally lost his
patience with the massive churn of duplicated reinvented code and
there was a huge blow up about it. See http://lwn.net/Articles/439326/
for background.

> Also, not that it's the most important, but how is it better for anyone
> to delay changes - which are completely orthogonal to arm-soc - for
> additional months? Doesn't "release early, release often" make sense
> anymore?

Nothing is delayed by going through arm-soc. We're closing down our
tree for new (large) pull requests around the same time where you
should no longer add them to your -next branch either (-rc6/-rc7 time
frame).

Small fixups, and of course bugfixes, are welcome closer to the merge
window but the major chances should all have landed by then.


-Olof

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Russell King - ARM Linux]

On Sat, Sep 29, 2012 at 07:02:36PM +0200, Krzysztof Halasa wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > explaining that we're closing the window for 3.7 except for a
> > few things that were already submitted earlier.
> 
> No offense, but... You say how does it work for YOU but that's not
> exactly what I'm asking for. I'm asking for a statement that it's
> not OK for me to push my IXP4xx changes straight to Linus.

If you bypass arm-soc, then you may find you have more problems - if
the arm-soc goes in before you, and your tree conflicts with arm-soc.
There are major changes going through at the present time which could
very well mean that you miss something and IXP4xx gets broken because
you're not participating.

If you wish to find out about those breakages after the event, and
play constant catch up, then pushing straight to Linus is what you
should do.

If you wish to know about the breakages, and fix them up ahead of time,
then participate in the established process.

> > The arm-soc process is definitely meant to make your life easier
> > as well as help Linus understand what's going on with all of ARM
> > to the degree that he needs to know, but it only works if everyone
> > participates.
> 
> I'd like to know how is it easier for me. Actually, I think it would
> only make things worse for everyone (mostly for me). Also, I can't see
> how "it only works if everyone participates" is true.
> 
> I'm currently supporting (for our internal needs) hw platforms based
> on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required
> so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current
> tree since it's the next stable.

That makes no sense what so ever.  The tree which is used for the next
stable tree will be Linus' tree, which will be the result of merging all
those other trees into Linus' tree.  If you base your changes off only
Linus' tree on the run up to the next merge window, then you are preparing
your changes against an _older_ kernel than if you base them off a tree
containing the changes which will be _included_ in the next merge window.

So, in the long run, you'll end up doing the same amount of work, but
you'll end up having to do the "fix it for the merge window" hoops _after_
your tree has been merged into mainline, rather than before.

> Also, not that it's the most important, but how is it better for anyone
> to delay changes - which are completely orthogonal to arm-soc - for
> additional months? Doesn't "release early, release often" make sense
> anymore?

Err, no idea what you're getting at here, but take a moment to think about
it.

If you want to work in total isolation, that's your choice, but in the
long run you will be playing catch-up rather than being prepared early
for the changes which will happen at the next merge window.  If you want
-rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to
fixing up the merge window breakage, then go ahead.

Otherwise, participate and be part of the community, and get your changes
into arm-soc, so that others can see what's going on.

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Russell King - ARM Linux]

On Sat, Sep 29, 2012 at 07:02:36PM +0200, Krzysztof Halasa wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > explaining that we're closing the window for 3.7 except for a
> > few things that were already submitted earlier.
> 
> No offense, but... You say how does it work for YOU but that's not
> exactly what I'm asking for. I'm asking for a statement that it's
> not OK for me to push my IXP4xx changes straight to Linus.

If you bypass arm-soc, then you may find you have more problems - if
the arm-soc goes in before you, and your tree conflicts with arm-soc.
There are major changes going through at the present time which could
very well mean that you miss something and IXP4xx gets broken because
you're not participating.

If you wish to find out about those breakages after the event, and
play constant catch up, then pushing straight to Linus is what you
should do.

If you wish to know about the breakages, and fix them up ahead of time,
then participate in the established process.

> > The arm-soc process is definitely meant to make your life easier
> > as well as help Linus understand what's going on with all of ARM
> > to the degree that he needs to know, but it only works if everyone
> > participates.
> 
> I'd like to know how is it easier for me. Actually, I think it would
> only make things worse for everyone (mostly for me). Also, I can't see
> how "it only works if everyone participates" is true.
> 
> I'm currently supporting (for our internal needs) hw platforms based
> on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required
> so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current
> tree since it's the next stable.

That makes no sense what so ever.  The tree which is used for the next
stable tree will be Linus' tree, which will be the result of merging all
those other trees into Linus' tree.  If you base your changes off only
Linus' tree on the run up to the next merge window, then you are preparing
your changes against an _older_ kernel than if you base them off a tree
containing the changes which will be _included_ in the next merge window.

So, in the long run, you'll end up doing the same amount of work, but
you'll end up having to do the "fix it for the merge window" hoops _after_
your tree has been merged into mainline, rather than before.

> Also, not that it's the most important, but how is it better for anyone
> to delay changes - which are completely orthogonal to arm-soc - for
> additional months? Doesn't "release early, release often" make sense
> anymore?

Err, no idea what you're getting at here, but take a moment to think about
it.

If you want to work in total isolation, that's your choice, but in the
long run you will be playing catch-up rather than being prepared early
for the changes which will happen at the next merge window.  If you want
-rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to
fixing up the merge window breakage, then go ahead.

Otherwise, participate and be part of the community, and get your changes
into arm-soc, so that others can see what's going on.

Re: [PATCH 01/12] mtd: atmel nand: build regression

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:36 Fri 28 Sep     , Arnd Bergmann wrote:
> The atmel_nand driver was broken by b654a9a46fc2 "mtd: atmel nand: fix
> gpio missing request". This is a rather helpless attempt to fix this,
> probably messing up the error handling even further but getting the
> build to work again, so please treat it as a bug report rather than
> a fix to be applied.
> 
> Without this patch, building any at91 configuration results in:
> 
> drivers/mtd/nand/atmel_nand.c: In function 'atmel_nand_probe':
> drivers/mtd/nand/atmel_nand.c:1451:4: error: label 'err_ecc_ioremap' used but not defined

for the record the error come from the merge of the pmecc and the commit you
mention
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
I already have seach path in my quere from Josh

Best Regards,
J.

[PATCH 01/12] mtd: atmel nand: build regression

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:36 Fri 28 Sep     , Arnd Bergmann wrote:
> The atmel_nand driver was broken by b654a9a46fc2 "mtd: atmel nand: fix
> gpio missing request". This is a rather helpless attempt to fix this,
> probably messing up the error handling even further but getting the
> build to work again, so please treat it as a bug report rather than
> a fix to be applied.
> 
> Without this patch, building any at91 configuration results in:
> 
> drivers/mtd/nand/atmel_nand.c: In function 'atmel_nand_probe':
> drivers/mtd/nand/atmel_nand.c:1451:4: error: label 'err_ecc_ioremap' used but not defined

for the record the error come from the merge of the pmecc and the commit you
mention
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
I already have seach path in my quere from Josh

Best Regards,
J.

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

I realize my work flow is probably suboptimal, though I can't see
an easy solution.

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> That makes no sense what so ever.  The tree which is used for the next
> stable tree will be Linus' tree, which will be the result of merging all
> those other trees into Linus' tree.  If you base your changes off only
> Linus' tree on the run up to the next merge window, then you are preparing
> your changes against an _older_ kernel than if you base them off a tree
> containing the changes which will be _included_ in the next merge
> window.

Yes. I have to fix my tree and ask for pull before the end of merge
window (fixes could follow, but it's best when there are no fixes
needed). I know it's not a great plan. Fortunately I'm not doing heavy,
conflicting development on this.

Note I'm not only doing ARM, but also X86 and MIPS, with additional code
shared between them, and the "stable" part of it is what I'm paid for.
I can't simply work with arm-soc, none of my platforms will even boot
with pure arm-soc.

> If you want to work in total isolation, that's your choice, but in the
> long run you will be playing catch-up rather than being prepared early
> for the changes which will happen at the next merge window.  If you want
> -rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to
> fixing up the merge window breakage, then go ahead.
>
> Otherwise, participate and be part of the community, and get your changes
> into arm-soc, so that others can see what's going on.

Unfortunately this seems to require more time on my part, time I don't
have. Perhaps I'm missing something?
I.e., I can dedicate some time around the merge window (not every one,
but this may improve), but not much more.

I don't think there are any "others" interested in what's going on on
IXP4xx. Simply, there isn't anything of importance here. It won't cause
severe conflicts (and "next" helps here), and I post my patches to the
list just like all people do.

Of course if you can see a better way (given the limitations), I'm open.

BTW I still think I'm a part of the community, even if I don't submit
code through arm-soc :-)
-- 
Krzysztof Halasa

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

I realize my work flow is probably suboptimal, though I can't see
an easy solution.

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> That makes no sense what so ever.  The tree which is used for the next
> stable tree will be Linus' tree, which will be the result of merging all
> those other trees into Linus' tree.  If you base your changes off only
> Linus' tree on the run up to the next merge window, then you are preparing
> your changes against an _older_ kernel than if you base them off a tree
> containing the changes which will be _included_ in the next merge
> window.

Yes. I have to fix my tree and ask for pull before the end of merge
window (fixes could follow, but it's best when there are no fixes
needed). I know it's not a great plan. Fortunately I'm not doing heavy,
conflicting development on this.

Note I'm not only doing ARM, but also X86 and MIPS, with additional code
shared between them, and the "stable" part of it is what I'm paid for.
I can't simply work with arm-soc, none of my platforms will even boot
with pure arm-soc.

> If you want to work in total isolation, that's your choice, but in the
> long run you will be playing catch-up rather than being prepared early
> for the changes which will happen at the next merge window.  If you want
> -rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to
> fixing up the merge window breakage, then go ahead.
>
> Otherwise, participate and be part of the community, and get your changes
> into arm-soc, so that others can see what's going on.

Unfortunately this seems to require more time on my part, time I don't
have. Perhaps I'm missing something?
I.e., I can dedicate some time around the merge window (not every one,
but this may improve), but not much more.

I don't think there are any "others" interested in what's going on on
IXP4xx. Simply, there isn't anything of importance here. It won't cause
severe conflicts (and "next" helps here), and I post my patches to the
list just like all people do.

Of course if you can see a better way (given the limitations), I'm open.

BTW I still think I'm a part of the community, even if I don't submit
code through arm-soc :-)
-- 
Krzysztof Halasa

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Russell King - ARM Linux]

On Sat, Sep 29, 2012 at 11:38:31PM +0200, Krzysztof Halasa wrote:
> Note I'm not only doing ARM, but also X86 and MIPS, with additional code
> shared between them, and the "stable" part of it is what I'm paid for.
> I can't simply work with arm-soc, none of my platforms will even boot
> with pure arm-soc.

I'm assuming that Linus' -rc kernels work for you, yes?

So, that suggests there's something in arm-soc which is breaking your
platforms, which means that you'll need to cook up a fix after or
during the next merge window.

You could instead cook that fix up _now_ before the merge window and
have it ready, _or_ send the fix to arm-soc or even report the regression
so that we don't end up with IXP4xx breaking at the next merge window.

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Russell King - ARM Linux]

On Sat, Sep 29, 2012 at 11:38:31PM +0200, Krzysztof Halasa wrote:
> Note I'm not only doing ARM, but also X86 and MIPS, with additional code
> shared between them, and the "stable" part of it is what I'm paid for.
> I can't simply work with arm-soc, none of my platforms will even boot
> with pure arm-soc.

I'm assuming that Linus' -rc kernels work for you, yes?

So, that suggests there's something in arm-soc which is breaking your
platforms, which means that you'll need to cook up a fix after or
during the next merge window.

You could instead cook that fix up _now_ before the merge window and
have it ready, _or_ send the fix to arm-soc or even report the regression
so that we don't end up with IXP4xx breaking at the next merge window.

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

>> Note I'm not only doing ARM, but also X86 and MIPS, with additional code
>> shared between them, and the "stable" part of it is what I'm paid for.
>> I can't simply work with arm-soc, none of my platforms will even boot
>> with pure arm-soc.
>
> I'm assuming that Linus' -rc kernels work for you, yes?

No, but it's OK :-)

I meant I need additional code for a) ARM and MIPS-based boards (off the
shelf by Ubiquity, Gateworks etc., support ported mostly from OpenWRT),
b) custom hardware used only by us.

I hope to eventually submit a) upstream, then arm-soc and Linus' trees
would work for me. I know it's a mess, but for now I have no options.

BTW the situation with hardware supported only by OpenWRT is a part of
the equation.
-- 
Krzysztof Halasa

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

>> Note I'm not only doing ARM, but also X86 and MIPS, with additional code
>> shared between them, and the "stable" part of it is what I'm paid for.
>> I can't simply work with arm-soc, none of my platforms will even boot
>> with pure arm-soc.
>
> I'm assuming that Linus' -rc kernels work for you, yes?

No, but it's OK :-)

I meant I need additional code for a) ARM and MIPS-based boards (off the
shelf by Ubiquity, Gateworks etc., support ported mostly from OpenWRT),
b) custom hardware used only by us.

I hope to eventually submit a) upstream, then arm-soc and Linus' trees
would work for me. I know it's a mess, but for now I have no options.

BTW the situation with hardware supported only by OpenWRT is a part of
the equation.
-- 
Krzysztof Halasa

Re: [PATCH 10/12] gpio: pcf857x: select IRQ_DOMAIN

[Linus Walleij]

On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> Patch 6e20a0a4 "gpio: pcf857x: enable gpio_to_irq() support"
> added IRQ domain support to the pcf857x driver, but some configurations
> (e.g. davinci_all_defconfig) don't already enable CONFIG_IRQ_DOMAIN.

Excellent patch Arnd thanks for this!
Applied to my GPIO tree (where the offending patch is queued).

Yours,
Linus Walleij

[PATCH 10/12] gpio: pcf857x: select IRQ_DOMAIN

[Linus Walleij]

On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> Patch 6e20a0a4 "gpio: pcf857x: enable gpio_to_irq() support"
> added IRQ domain support to the pcf857x driver, but some configurations
> (e.g. davinci_all_defconfig) don't already enable CONFIG_IRQ_DOMAIN.

Excellent patch Arnd thanks for this!
Applied to my GPIO tree (where the offending patch is queued).

Yours,
Linus Walleij

Re: [PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Linus Walleij]

On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The samsung pinctrl driver has a probe function that is
> __devinit and that calls a lot of other functions that are
> marked __init, which kbuild complains about.
>
> Marking everything __devinit means that the code does not
> discarded when CONFIG_HOTPLUG is set, which is a little
> more wasteful, but also more consistent
>
> Without this patch, building exynos_defconfig results in:
>
> WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
> The function __devinit samsung_pinctrl_probe() references
> a function __init samsung_gpiolib_register().
> If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
> annotate samsung_gpiolib_register with a matching annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Stephen Warren <swarren@nvidia.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

I think the Samsing pinctrl driver has landed into next from some
branch in ARM SoC so you probably know better than me
where this thing should be merged...

Yours,
Linus Walleij

[PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Linus Walleij]

On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The samsung pinctrl driver has a probe function that is
> __devinit and that calls a lot of other functions that are
> marked __init, which kbuild complains about.
>
> Marking everything __devinit means that the code does not
> discarded when CONFIG_HOTPLUG is set, which is a little
> more wasteful, but also more consistent
>
> Without this patch, building exynos_defconfig results in:
>
> WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
> The function __devinit samsung_pinctrl_probe() references
> a function __init samsung_gpiolib_register().
> If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
> annotate samsung_gpiolib_register with a matching annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Stephen Warren <swarren@nvidia.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

I think the Samsing pinctrl driver has landed into next from some
branch in ARM SoC so you probably know better than me
where this thing should be merged...

Yours,
Linus Walleij

Re: [PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Will Newton]

On Fri, Sep 28, 2012 at 10:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
> points to the wrong symbol which results in a link error
> when building as a loadable module.
>
> Further, we get a warning about the driver_data being
> marked constant, which requires annotating a few pointers
> as const.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Will Newton <will.newton@imgtec.com>
> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> Cc: Seungwon Jeon <tgih.jun@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: linux-mmc@vger.kernel.org
> ---
>  drivers/mmc/host/dw_mmc-exynos.c |    4 ++--
>  drivers/mmc/host/dw_mmc-pltfm.c  |    2 +-
>  drivers/mmc/host/dw_mmc-pltfm.h  |    2 +-
>  drivers/mmc/host/dw_mmc.c        |    2 +-
>  include/linux/mmc/dw_mmc.h       |    2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)

This looks ok to me, but I'll let one of the Exynos guys ack those
specific changes as I don't have the hardware.

There's already a patch for the dev_info warning in dw_mmc.c frm
Seungwon Jeon, and it seems to me like a separate change but I don't
really mind how it gets merged.

[PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Will Newton]

On Fri, Sep 28, 2012 at 10:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
> points to the wrong symbol which results in a link error
> when building as a loadable module.
>
> Further, we get a warning about the driver_data being
> marked constant, which requires annotating a few pointers
> as const.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Will Newton <will.newton@imgtec.com>
> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> Cc: Seungwon Jeon <tgih.jun@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: linux-mmc at vger.kernel.org
> ---
>  drivers/mmc/host/dw_mmc-exynos.c |    4 ++--
>  drivers/mmc/host/dw_mmc-pltfm.c  |    2 +-
>  drivers/mmc/host/dw_mmc-pltfm.h  |    2 +-
>  drivers/mmc/host/dw_mmc.c        |    2 +-
>  include/linux/mmc/dw_mmc.h       |    2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)

This looks ok to me, but I'll let one of the Exynos guys ack those
specific changes as I don't have the hardware.

There's already a patch for the dev_info warning in dw_mmc.c frm
Seungwon Jeon, and it seems to me like a separate change but I don't
really mind how it gets merged.

Re: [PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Arnd Bergmann]

On Monday 01 October 2012, Linus Walleij wrote:
> On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > The samsung pinctrl driver has a probe function that is
> > __devinit and that calls a lot of other functions that are
> > marked __init, which kbuild complains about.
> >
> > Marking everything __devinit means that the code does not
> > discarded when CONFIG_HOTPLUG is set, which is a little
> > more wasteful, but also more consistent
> >
> > Without this patch, building exynos_defconfig results in:
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 
> I think the Samsing pinctrl driver has landed into next from some
> branch in ARM SoC so you probably know better than me
> where this thing should be merged...
> 

Sorry, I was too late for this one. Can you pick it up now that the
driver is merged?

	Arnd

[PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Arnd Bergmann]

On Monday 01 October 2012, Linus Walleij wrote:
> On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > The samsung pinctrl driver has a probe function that is
> > __devinit and that calls a lot of other functions that are
> > marked __init, which kbuild complains about.
> >
> > Marking everything __devinit means that the code does not
> > discarded when CONFIG_HOTPLUG is set, which is a little
> > more wasteful, but also more consistent
> >
> > Without this patch, building exynos_defconfig results in:
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 
> I think the Samsing pinctrl driver has landed into next from some
> branch in ARM SoC so you probably know better than me
> where this thing should be merged...
> 

Sorry, I was too late for this one. Can you pick it up now that the
driver is merged?

	Arnd

Re: [PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Linus Walleij]

On Tue, Oct 2, 2012 at 1:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 01 October 2012, Linus Walleij wrote:
>> On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> > The samsung pinctrl driver has a probe function that is
>> > __devinit and that calls a lot of other functions that are
>> > marked __init, which kbuild complains about.
>> >
>> > Marking everything __devinit means that the code does not
>> > discarded when CONFIG_HOTPLUG is set, which is a little
>> > more wasteful, but also more consistent
>> >
>> > Without this patch, building exynos_defconfig results in:
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> I think the Samsing pinctrl driver has landed into next from some
>> branch in ARM SoC so you probably know better than me
>> where this thing should be merged...
>>
>
> Sorry, I was too late for this one. Can you pick it up now that the
> driver is merged?

Sure I've queued it for my -rc fixes.

Thanks,
Linus Walleij

[PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Linus Walleij]

On Tue, Oct 2, 2012 at 1:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 01 October 2012, Linus Walleij wrote:
>> On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> > The samsung pinctrl driver has a probe function that is
>> > __devinit and that calls a lot of other functions that are
>> > marked __init, which kbuild complains about.
>> >
>> > Marking everything __devinit means that the code does not
>> > discarded when CONFIG_HOTPLUG is set, which is a little
>> > more wasteful, but also more consistent
>> >
>> > Without this patch, building exynos_defconfig results in:
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> I think the Samsing pinctrl driver has landed into next from some
>> branch in ARM SoC so you probably know better than me
>> where this thing should be merged...
>>
>
> Sorry, I was too late for this one. Can you pick it up now that the
> driver is merged?

Sure I've queued it for my -rc fixes.

Thanks,
Linus Walleij

Re: [PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Fri, Sep 28, 2012 at 11:36:16PM +0200, Arnd Bergmann wrote:
> The samsung pinctrl driver has a probe function that is
> __devinit and that calls a lot of other functions that are
> marked __init, which kbuild complains about.
> 
> Marking everything __devinit means that the code does not
> discarded when CONFIG_HOTPLUG is set, which is a little
> more wasteful, but also more consistent
> 
> Without this patch, building exynos_defconfig results in:
> 
> WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
> The function __devinit samsung_pinctrl_probe() references
> a function __init samsung_gpiolib_register().
> If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
> annotate samsung_gpiolib_register with a matching annotation.

Note that work is underway to remove HOTPLUG altogether (see commit
45f035a, "CONFIG_HOTPLUG should be always on" in linux-next), so it
may make more sense to just drop the __init markings.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 11/12] pinctrl: samsung: use __devinit section for init code

[Thierry Reding]

On Fri, Sep 28, 2012 at 11:36:16PM +0200, Arnd Bergmann wrote:
> The samsung pinctrl driver has a probe function that is
> __devinit and that calls a lot of other functions that are
> marked __init, which kbuild complains about.
> 
> Marking everything __devinit means that the code does not
> discarded when CONFIG_HOTPLUG is set, which is a little
> more wasteful, but also more consistent
> 
> Without this patch, building exynos_defconfig results in:
> 
> WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
> The function __devinit samsung_pinctrl_probe() references
> a function __init samsung_gpiolib_register().
> If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
> annotate samsung_gpiolib_register with a matching annotation.

Note that work is underway to remove HOTPLUG altogether (see commit
45f035a, "CONFIG_HOTPLUG should be always on" in linux-next), so it
may make more sense to just drop the __init markings.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121002/619651cc/attachment-0001.sig>

RE: [PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Seungwon Jeon]

Monday, October 01, 2012, Will Newton <will.newton@gmail.com> wrote:
> On Fri, Sep 28, 2012 at 10:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
> > points to the wrong symbol which results in a link error
> > when building as a loadable module.
> >
> > Further, we get a warning about the driver_data being
> > marked constant, which requires annotating a few pointers
> > as const.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: Thomas Abraham <thomas.abraham@linaro.org>
> > Cc: Will Newton <will.newton@imgtec.com>
> > Cc: Jaehoon Chung <jh80.chung@samsung.com>
> > Cc: Seungwon Jeon <tgih.jun@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: linux-mmc@vger.kernel.org
> > ---
> >  drivers/mmc/host/dw_mmc-exynos.c |    4 ++--
> >  drivers/mmc/host/dw_mmc-pltfm.c  |    2 +-
> >  drivers/mmc/host/dw_mmc-pltfm.h  |    2 +-
> >  drivers/mmc/host/dw_mmc.c        |    2 +-
> >  include/linux/mmc/dw_mmc.h       |    2 +-
> >  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> This looks ok to me, but I'll let one of the Exynos guys ack those
> specific changes as I don't have the hardware.
> 
> There's already a patch for the dev_info warning in dw_mmc.c frm
> Seungwon Jeon, and it seems to me like a separate change but I don't
> really mind how it gets merged.

Looks good to me.
I don't mind it about including 'dev_info warning'.

Acked-by: Seungwon Jeon<tgih.jun@samsung.com>

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

[PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module

[Seungwon Jeon]

Monday, October 01, 2012, Will Newton <will.newton@gmail.com> wrote:
> On Fri, Sep 28, 2012 at 10:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
> > points to the wrong symbol which results in a link error
> > when building as a loadable module.
> >
> > Further, we get a warning about the driver_data being
> > marked constant, which requires annotating a few pointers
> > as const.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: Thomas Abraham <thomas.abraham@linaro.org>
> > Cc: Will Newton <will.newton@imgtec.com>
> > Cc: Jaehoon Chung <jh80.chung@samsung.com>
> > Cc: Seungwon Jeon <tgih.jun@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: linux-mmc at vger.kernel.org
> > ---
> >  drivers/mmc/host/dw_mmc-exynos.c |    4 ++--
> >  drivers/mmc/host/dw_mmc-pltfm.c  |    2 +-
> >  drivers/mmc/host/dw_mmc-pltfm.h  |    2 +-
> >  drivers/mmc/host/dw_mmc.c        |    2 +-
> >  include/linux/mmc/dw_mmc.h       |    2 +-
> >  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> This looks ok to me, but I'll let one of the Exynos guys ack those
> specific changes as I don't have the hardware.
> 
> There's already a patch for the dev_info warning in dw_mmc.c frm
> Seungwon Jeon, and it seems to me like a separate change but I don't
> really mind how it gets merged.

Looks good to me.
I don't mind it about including 'dev_info warning'.

Acked-by: Seungwon Jeon<tgih.jun@samsung.com>

> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/12] video: exynos: warnings in exynos_dp_core.c

[Jingoo Han]

On Saturday, September 29, 2012 6:36 AM Arnd Bergmann wrote
> 
> Something is wrong with the exynos_dp_core logic, and gcc
> emits a warning about this. An array is declared in
> exynos_dp_process_equalizer_training with length '2',
> and exynos_dp_channel_eq_ok tries to access the third
> element of it.
> 
> This patch is certainly not correct, but hopefully helps
> highlight the actual problem. The problem apparently was
> introduced by d5c0eed01 "video: exynos_dp: adjust voltage
> swing and pre-emphasis during Link Training".
> 
> This is what we get in exynos_defconfig:
> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_process_equalizer_training':
> drivers/video/exynos/exynos_dp_core.c:341:13: warning: array subscript is above array bounds [-Warray-
> bounds]

Hi Arnd Bergmann,

This problem was fixed. So, this patch is not necessary.

As you mentioned, this problem was introduced by d5c0eed01
"video: exynos_dp: adjust voltage swing and pre-emphasis
during Link Training".

However, this problem was resolved by e75478b "video: exynos_dp:
replace link_status with link_align to check channel equalization".

The patch was merged to 'fbdev-next', and will be merged to
'3.7-rc1', soon. Thank you.

Best regards,
Jingoo Han


> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> ---
>  drivers/video/exynos/exynos_dp_core.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index cdc1398..358b595 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -542,7 +542,7 @@ reduce_link_rate:
> 
>  static int exynos_dp_process_equalizer_training(struct exynos_dp_device *dp)
>  {
> -	u8 link_status[2];
> +	u8 link_status[3];
>  	u8 link_align[3];
>  	int lane;
>  	int lane_count;
> --
> 1.7.10

[PATCH 04/12] video: exynos: warnings in exynos_dp_core.c

[Jingoo Han]

On Saturday, September 29, 2012 6:36 AM Arnd Bergmann wrote
> 
> Something is wrong with the exynos_dp_core logic, and gcc
> emits a warning about this. An array is declared in
> exynos_dp_process_equalizer_training with length '2',
> and exynos_dp_channel_eq_ok tries to access the third
> element of it.
> 
> This patch is certainly not correct, but hopefully helps
> highlight the actual problem. The problem apparently was
> introduced by d5c0eed01 "video: exynos_dp: adjust voltage
> swing and pre-emphasis during Link Training".
> 
> This is what we get in exynos_defconfig:
> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_process_equalizer_training':
> drivers/video/exynos/exynos_dp_core.c:341:13: warning: array subscript is above array bounds [-Warray-
> bounds]

Hi Arnd Bergmann,

This problem was fixed. So, this patch is not necessary.

As you mentioned, this problem was introduced by d5c0eed01
"video: exynos_dp: adjust voltage swing and pre-emphasis
during Link Training".

However, this problem was resolved by e75478b "video: exynos_dp:
replace link_status with link_align to check channel equalization".

The patch was merged to 'fbdev-next', and will be merged to
'3.7-rc1', soon. Thank you.

Best regards,
Jingoo Han


> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> ---
>  drivers/video/exynos/exynos_dp_core.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index cdc1398..358b595 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -542,7 +542,7 @@ reduce_link_rate:
> 
>  static int exynos_dp_process_equalizer_training(struct exynos_dp_device *dp)
>  {
> -	u8 link_status[2];
> +	u8 link_status[3];
>  	u8 link_align[3];
>  	int lane;
>  	int lane_count;
> --
> 1.7.10

Re: [PATCH 04/12] video: exynos: warnings in exynos_dp_core.c

[Arnd Bergmann]

On Friday 05 October 2012, Jingoo Han wrote:
> This problem was fixed. So, this patch is not necessary.
> 
> As you mentioned, this problem was introduced by d5c0eed01
> "video: exynos_dp: adjust voltage swing and pre-emphasis
> during Link Training".
> 
> However, this problem was resolved by e75478b "video: exynos_dp:
> replace link_status with link_align to check channel equalization".
> 
> The patch was merged to 'fbdev-next', and will be merged to
> '3.7-rc1', soon. Thank you.

Ok, thanks for letting know. I'll drop my patch then.

	Arnd

[PATCH 04/12] video: exynos: warnings in exynos_dp_core.c

[Arnd Bergmann]

On Friday 05 October 2012, Jingoo Han wrote:
> This problem was fixed. So, this patch is not necessary.
> 
> As you mentioned, this problem was introduced by d5c0eed01
> "video: exynos_dp: adjust voltage swing and pre-emphasis
> during Link Training".
> 
> However, this problem was resolved by e75478b "video: exynos_dp:
> replace link_status with link_align to check channel equalization".
> 
> The patch was merged to 'fbdev-next', and will be merged to
> '3.7-rc1', soon. Thank you.

Ok, thanks for letting know. I'll drop my patch then.

	Arnd

Re: [PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Jonathan Cameron]

On 09/29/2012 04:03 PM, Arnd Bergmann wrote:
> On Saturday 29 September 2012, Jonathan Cameron wrote:
>> On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
>>> The driver has not been building for some time after the
>>> irq_to_gpio function has been removed from the kernel.
>>>
>>> The only board in the upstream kernel that provides
>>> this device is the "Stargate 2", which is also maintained
>>> by Jonathan Cameron. Rather than working around the problem
>>> by adding new platform data for this driver, this patch
>>> uses the of_gpio framework to get to the gpio number.
>>>
>>> However, the stargate2 code does not (yet) use DT based
>>> probing, so it is still broken, but at least building
>>> allyesconfig works again.
>> Will be optimistic to think anyone will convert a platform
>> that no one still makes (stargate 2 was pretty much intel
>> research only + some they gave to accademics - imote2 has
>> been dropped by memsic for a while now.)  If nothing else
>> there is little chance anyone will bother porting a remotely
>> up to date bootloader to these boards given how few people
>> are still using them for anything.
> 
> The way are converting most ARM platforms to DT, we should be
> able to replace the board files with .dts files once all
> device drivers have been converted over. This is taking a
> bit longer for mmp/pxa than for some of the other platforms,
> Updating the boot loader makes it easier to deploy a DT
> version, but you can also append a DT blob to the kernel
> if that's not possible, and we will in the future allow
> appending multiple DT blobs and let the early boot stages
> pick the right one based on the board ID.
Sounds good.

> 
>> I'm happy enough with this patch.  Would prefer to
>> take it post merge window as a fix than now given timing.
> 
> Ok, fair enough. It has been broken for a while, so there
> is no hurry now. I just stumbled over it when doing an
> "allyesconfig" build.
Added to togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git

> 
>> Long run this driver will hopefully get replaced by the
>> unified driver for all the st accelerometers (assuming that
>> ever gets back to this long obsolete part).
> 
> Ok.
> 
> 	Arnd
> 

[PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio

[Jonathan Cameron]

On 09/29/2012 04:03 PM, Arnd Bergmann wrote:
> On Saturday 29 September 2012, Jonathan Cameron wrote:
>> On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
>>> The driver has not been building for some time after the
>>> irq_to_gpio function has been removed from the kernel.
>>>
>>> The only board in the upstream kernel that provides
>>> this device is the "Stargate 2", which is also maintained
>>> by Jonathan Cameron. Rather than working around the problem
>>> by adding new platform data for this driver, this patch
>>> uses the of_gpio framework to get to the gpio number.
>>>
>>> However, the stargate2 code does not (yet) use DT based
>>> probing, so it is still broken, but at least building
>>> allyesconfig works again.
>> Will be optimistic to think anyone will convert a platform
>> that no one still makes (stargate 2 was pretty much intel
>> research only + some they gave to accademics - imote2 has
>> been dropped by memsic for a while now.)  If nothing else
>> there is little chance anyone will bother porting a remotely
>> up to date bootloader to these boards given how few people
>> are still using them for anything.
> 
> The way are converting most ARM platforms to DT, we should be
> able to replace the board files with .dts files once all
> device drivers have been converted over. This is taking a
> bit longer for mmp/pxa than for some of the other platforms,
> Updating the boot loader makes it easier to deploy a DT
> version, but you can also append a DT blob to the kernel
> if that's not possible, and we will in the future allow
> appending multiple DT blobs and let the early boot stages
> pick the right one based on the board ID.
Sounds good.

> 
>> I'm happy enough with this patch.  Would prefer to
>> take it post merge window as a fix than now given timing.
> 
> Ok, fair enough. It has been broken for a while, so there
> is no hurry now. I just stumbled over it when doing an
> "allyesconfig" build.
Added to togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git

> 
>> Long run this driver will hopefully get replaced by the
>> unified driver for all the st accelerometers (assuming that
>> ever gets back to this long obsolete part).
> 
> Ok.
> 
> 	Arnd
> 

Re: [PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c

[Greg Kroah-Hartman]

On Fri, Sep 28, 2012 at 04:45:37PM -0500, Jason Wessel wrote:
> On 09/28/2012 04:36 PM, Arnd Bergmann wrote:
> > The con_debug_leave/con_debug_enter functions are stubbed out
> > by defining them to (0), which causes harmless build warnings.
> > Using proper inline functions is the normal way to deal with
> > this.
> >
> > Without this patch, building the ARM bcm2835_defconfig results in:
> >
> > drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
> > drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
> > drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
> > drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]
> 
> 
> Thanks Arnd!
> 
> I'll put this in kgdb-next for the upcoming merge window, unless Greg pulls it into his queue first.
> 
> Acked-by: Jason Wessel <jason.wessel@windriver.com>

Feel free to take it in through your kgdb tree.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[PATCH 09/12] tty/console: fix warnings in drivers/tty/serial/kgdboc.c

[Greg Kroah-Hartman]

On Fri, Sep 28, 2012 at 04:45:37PM -0500, Jason Wessel wrote:
> On 09/28/2012 04:36 PM, Arnd Bergmann wrote:
> > The con_debug_leave/con_debug_enter functions are stubbed out
> > by defining them to (0), which causes harmless build warnings.
> > Using proper inline functions is the normal way to deal with
> > this.
> >
> > Without this patch, building the ARM bcm2835_defconfig results in:
> >
> > drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
> > drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
> > drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
> > drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]
> 
> 
> Thanks Arnd!
> 
> I'll put this in kgdb-next for the upcoming merge window, unless Greg pulls it into his queue first.
> 
> Acked-by: Jason Wessel <jason.wessel@windriver.com>

Feel free to take it in through your kgdb tree.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>