[PATCH 00/22] Random ARM randconfig fixes in drivers

[PATCH 00/22] Random ARM randconfig fixes in drivers

[Arnd Bergmann]

These are a bunch of fixes I had to do to get all randconfig
configurations on ARM working. Most of these are really old
bugs, but there are also some new ones. I don't think any of
them require a backport to linux-stable.

I have checked that they are all still required on yesterday's
linux-next kernel. Please apply on the appropriate trees unless
there are objections.

Patch numbers are per subsystem, which I thought is less confusing
than numbering them 1-22 when they are all totall independent.

Arnd Bergmann (22):
  mdio_bus: fix devm_mdiobus_alloc_size export
  phy: kona2: use 'select GENERIC_PHY' in Kconfig
  phy: exynos: fix SATA phy license typo
  dmaengine: omap: hide filter_fn for built-in drivers
  dmaengine: sa11x0: remove broken #ifdef
  mtd/onenand: fix build warning for dma type
  mtd: orion-nand: fix build error with ARMv4
  clk/versatile: export symbols for impd1
  bus/omap_l3: avoid sync initcall for modules
  bus/arm-cci: add dependency on OF && CPU_V7
  watchdog: iop_wdt only builds for mach-iop13xx
  mpilib: use 'static inline' for mpi-inline.h
  ata: pata_at91 only works on sam9
  i2c/nuc900: fix ancient build error
  iio: always select ANON_INODES
  iio:adc: at91 requires the input subsystem
  pci: rcar host needs OF
  input: fix ps2/serio module dependency
  input: atmel-wm97xx: only build for AVR32
  misc: atmel_pwm: only build for supported platforms
  remoteproc: da8xx: don't select CMA on no-MMU
  regulator: arizona-ldo1: add missing #include

 drivers/ata/Kconfig               | 2 +-
 drivers/bus/Kconfig               | 2 +-
 drivers/bus/omap_l3_noc.c         | 4 ++++
 drivers/bus/omap_l3_smx.c         | 4 ++++
 drivers/clk/versatile/clk-icst.c  | 1 +
 drivers/clk/versatile/clk-impd1.c | 2 ++
 drivers/dma/sa11x0-dma.c          | 4 ----
 drivers/i2c/busses/i2c-nuc900.c   | 2 +-
 drivers/iio/Kconfig               | 1 +
 drivers/iio/adc/Kconfig           | 1 +
 drivers/input/keyboard/Kconfig    | 2 +-
 drivers/input/mouse/Kconfig       | 2 +-
 drivers/input/touchscreen/Kconfig | 2 +-
 drivers/misc/Kconfig              | 3 ++-
 drivers/mtd/nand/orion_nand.c     | 5 +++++
 drivers/mtd/onenand/samsung.c     | 8 ++++----
 drivers/net/phy/mdio_bus.c        | 2 +-
 drivers/pci/host/Kconfig          | 2 +-
 drivers/phy/Kconfig               | 2 +-
 drivers/phy/phy-exynos5250-sata.c | 2 +-
 drivers/regulator/arizona-ldo1.c  | 1 +
 drivers/remoteproc/Kconfig        | 2 +-
 drivers/watchdog/Kconfig          | 2 +-
 include/linux/omap-dma.h          | 2 +-
 lib/mpi/mpi-inline.h              | 2 +-
 lib/mpi/mpi-internal.h            | 8 --------
 26 files changed, 39 insertions(+), 31 deletions(-)

-- 
1.8.3.2

Cc: bhelgaas@google.com
Cc: dwmw2@infradead.org
Cc: dmitry.torokhov@gmail.com
Cc: balbi@ti.com
Cc: gregkh@linuxfoundation.org
Cc: plagnioj@jcrosoft.com
Cc: jic23@kernel.org
Cc: josh.wu@atmel.com
Cc: kishon@ti.com
Cc: linus.walleij@linaro.org
Cc: broonie@kernel.org
Cc: mturquette@linaro.org
Cc: nicolas.ferre@atmel.com
Cc: ohad@wizery.com
Cc: linux@arm.linux.org.uk
Cc: tony@atomide.com
Cc: vinod.koul@intel.com
Cc: wim@iguana.be
Cc: wsa@the-dreams.de
Cc: dmaengine@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: linux-watchdog@vger.kernel.org
Cc: netdev@vger.kernel.org

[PATCH] mdio_bus: fix devm_mdiobus_alloc_size export

[Arnd Bergmann]

commit 6d48f44b7b2 "mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free"
introduced a new function devm_mdiobus_alloc_size() but added an export
for a different function devm_mdiobus_alloc(), which was obviously
a simple mistake that leads to  build error whenever this function is
used from a loadable module:

ERROR: "devm_mdiobus_alloc_size" [drivers/net/ethernet/ti/davinci_mdio.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
 drivers/net/phy/mdio_bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 68a9a38..a628496 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -117,7 +117,7 @@ struct mii_bus *devm_mdiobus_alloc_size(struct device *dev, int sizeof_priv)
 
 	return bus;
 }
-EXPORT_SYMBOL_GPL(devm_mdiobus_alloc);
+EXPORT_SYMBOL_GPL(devm_mdiobus_alloc_size);
 
 /**
  * devm_mdiobus_free - Resource-managed mdiobus_free()
-- 
1.8.3.2

Re: [PATCH] mdio_bus: fix devm_mdiobus_alloc_size export

[Grygorii Strashko]

Hi Arnd,

On 05/08/2014 05:46 PM, Arnd Bergmann wrote:
> commit 6d48f44b7b2 "mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free"
> introduced a new function devm_mdiobus_alloc_size() but added an export
> for a different function devm_mdiobus_alloc(), which was obviously
> a simple mistake that leads to  build error whenever this function is
> used from a loadable module:
>
> ERROR: "devm_mdiobus_alloc_size" [drivers/net/ethernet/ti/davinci_mdio.ko] undefined!

Sorry for that, and thanks a lot for the fix.

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> ---
>   drivers/net/phy/mdio_bus.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 68a9a38..a628496 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -117,7 +117,7 @@ struct mii_bus *devm_mdiobus_alloc_size(struct device *dev, int sizeof_priv)
>
>   	return bus;
>   }
> -EXPORT_SYMBOL_GPL(devm_mdiobus_alloc);
> +EXPORT_SYMBOL_GPL(devm_mdiobus_alloc_size);
>
>   /**
>    * devm_mdiobus_free - Resource-managed mdiobus_free()
>

Regards,
-grygorii

Re: [PATCH] mdio_bus: fix devm_mdiobus_alloc_size export

[Prabhakar Lad]

On Thu, May 8, 2014 at 8:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> commit 6d48f44b7b2 "mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free"
> introduced a new function devm_mdiobus_alloc_size() but added an export
> for a different function devm_mdiobus_alloc(), which was obviously
> a simple mistake that leads to  build error whenever this function is
> used from a loadable module:
>
> ERROR: "devm_mdiobus_alloc_size" [drivers/net/ethernet/ti/davinci_mdio.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org

Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>

Thanks,
--Prabhakar Lad

> ---
>  drivers/net/phy/mdio_bus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 68a9a38..a628496 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -117,7 +117,7 @@ struct mii_bus *devm_mdiobus_alloc_size(struct device *dev, int sizeof_priv)
>
>         return bus;
>  }
> -EXPORT_SYMBOL_GPL(devm_mdiobus_alloc);
> +EXPORT_SYMBOL_GPL(devm_mdiobus_alloc_size);
>
>  /**
>   * devm_mdiobus_free - Resource-managed mdiobus_free()
> --
> 1.8.3.2
>

Re: [PATCH] mdio_bus: fix devm_mdiobus_alloc_size export

[David Miller]

From: Arnd Bergmann <arnd@arndb.de>
Date: Thu,  8 May 2014 16:46:52 +0200

> commit 6d48f44b7b2 "mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free"
> introduced a new function devm_mdiobus_alloc_size() but added an export
> for a different function devm_mdiobus_alloc(), which was obviously
> a simple mistake that leads to  build error whenever this function is
> used from a loadable module:
> 
> ERROR: "devm_mdiobus_alloc_size" [drivers/net/ethernet/ti/davinci_mdio.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied to net-next, thanks Arnd.

[PATCH 1/2] phy: kona2: use 'select GENERIC_PHY' in Kconfig

[Arnd Bergmann]

All other phy drivers use 'select', while this one is
the only one to use 'depends on'. This is not a bug, just
slightly inconsistent, so let's change it to do things the
same way as everyone else.

We may also want to turn GENERIC_PHY into a silent option
that only ever gets turned on if another driver needs it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Matt Porter <mporter@linaro.org>
Cc: Felipe Balbi <balbi@ti.com>
---
 drivers/phy/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 4906c27..071b763 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -89,8 +89,8 @@ config PHY_EXYNOS_DP_VIDEO
 
 config BCM_KONA_USB2_PHY
 	tristate "Broadcom Kona USB2 PHY Driver"
-	depends on GENERIC_PHY
 	depends on HAS_IOMEM
+	select GENERIC_PHY
 	help
 	  Enable this to support the Broadcom Kona USB 2.0 PHY.
 
-- 
1.8.3.2

[PATCH 2/2] phy: exynos: fix SATA phy license typo

[Arnd Bergmann]

If the license string doesn't match exactly, the module refuses
to load.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org
---
 drivers/phy/phy-exynos5250-sata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-exynos5250-sata.c b/drivers/phy/phy-exynos5250-sata.c
index c9361b7..0568945 100644
--- a/drivers/phy/phy-exynos5250-sata.c
+++ b/drivers/phy/phy-exynos5250-sata.c
@@ -246,6 +246,6 @@ static struct platform_driver exynos_sata_phy_driver = {
 module_platform_driver(exynos_sata_phy_driver);
 
 MODULE_DESCRIPTION("Samsung SerDes PHY driver");
-MODULE_LICENSE("GPL V2");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Girish K S <ks.giri@samsung.com>");
 MODULE_AUTHOR("Yuvaraj C D <yuvaraj.cd@samsung.com>");
-- 
1.8.3.2

Re: [PATCH 2/2] phy: exynos: fix SATA phy license typo

[Paul Bolle]

On Thu, 2014-05-08 at 16:46 +0200, Arnd Bergmann wrote:
> If the license string doesn't match exactly, the module refuses
> to load.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: linux-samsung-soc@vger.kernel.org
> ---
>  drivers/phy/phy-exynos5250-sata.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-exynos5250-sata.c b/drivers/phy/phy-exynos5250-sata.c
> index c9361b7..0568945 100644
> --- a/drivers/phy/phy-exynos5250-sata.c
> +++ b/drivers/phy/phy-exynos5250-sata.c
> @@ -246,6 +246,6 @@ static struct platform_driver exynos_sata_phy_driver = {
>  module_platform_driver(exynos_sata_phy_driver);
>  
>  MODULE_DESCRIPTION("Samsung SerDes PHY driver");
> -MODULE_LICENSE("GPL V2");
> +MODULE_LICENSE("GPL v2");
>  MODULE_AUTHOR("Girish K S <ks.giri@samsung.com>");
>  MODULE_AUTHOR("Yuvaraj C D <yuvaraj.cd@samsung.com>");

A bit of grepping the tree showed me
    Documentation/blackfin/gptimers-example.c:83:MODULE_LICENSE("BSD");
    drivers/dma/dma-jz4740.c:617:MODULE_LICENSE("GPLv2");
    drivers/input/misc/sirfsoc-onkey.c:216:MODULE_LICENSE("GPLv2");
    drivers/pci/host/pci-mvebu.c:1042:MODULE_LICENSE("GPLv2");
    drivers/pci/host/pci-tegra.c:1719:MODULE_LICENSE("GPLv2");
    drivers/power/reset/restart-poweroff.c:65:MODULE_LICENSE("GPLv2");

It seems these need to be changed too. But, except for dma-jz4740.c,
these are all files that can't be built as (part of) a module. Which
explains why no one noticed. Maybe I'll submit some trivial patches, in
a few days, to clean this up.


Paul Bolle

[PATCH 1/2] dmaengine: omap: hide filter_fn for built-in drivers

[Arnd Bergmann]

It is not possible to reference the omap_dma_filter_fn filter
function from a built-in driver if the dmaengine driver itself
is a loadable module, which is a valid configuration otherwise.

This provides only the dummy alternative if the function
is referenced by a built-in driver to allow a successful
build. The filter function is only required by ATAGS based
platforms, which will continue to be broken after this change
for the bogus configuration. When booting from DT, with the
dma channels correctly listed there, it will work fine.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: dmaengine@vger.kernel.org
---
 include/linux/omap-dma.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 0a1a2e2..c29a6de 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -10,7 +10,7 @@
 
 struct dma_chan;
 
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+#if defined(CONFIG_DMA_OMAP) || (defined(CONFIG_DMA_OMAP_MODULE) && defined(MODULE))
 bool omap_dma_filter_fn(struct dma_chan *, void *);
 #else
 static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-- 
1.8.3.2

[PATCH 2/2] dmaengine: sa11x0: remove broken #ifdef

[Arnd Bergmann]

The sa11x0_dma_pm_ops unconditionally reference sa11x0_dma_resume
and sa11x0_dma_suspend, which currently breaks if CONFIG_PM_SLEEP
is disabled.

There is probably a better way to remove the reference in this
case, but the safe choice is to have the suspend/resume code always
built in the driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: dmaengine@vger.kernel.org
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
---
 drivers/dma/sa11x0-dma.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/dma/sa11x0-dma.c b/drivers/dma/sa11x0-dma.c
index ab26d46..5ebdfbc 100644
--- a/drivers/dma/sa11x0-dma.c
+++ b/drivers/dma/sa11x0-dma.c
@@ -113,11 +113,9 @@ struct sa11x0_dma_phy {
 	struct sa11x0_dma_desc	*txd_load;
 	unsigned		sg_done;
 	struct sa11x0_dma_desc	*txd_done;
-#ifdef CONFIG_PM_SLEEP
 	u32			dbs[2];
 	u32			dbt[2];
 	u32			dcsr;
-#endif
 };
 
 struct sa11x0_dma_dev {
@@ -984,7 +982,6 @@ static int sa11x0_dma_remove(struct platform_device *pdev)
 	return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
 static int sa11x0_dma_suspend(struct device *dev)
 {
 	struct sa11x0_dma_dev *d = dev_get_drvdata(dev);
@@ -1054,7 +1051,6 @@ static int sa11x0_dma_resume(struct device *dev)
 
 	return 0;
 }
-#endif
 
 static const struct dev_pm_ops sa11x0_dma_pm_ops = {
 	.suspend_noirq = sa11x0_dma_suspend,
-- 
1.8.3.2

Re: [PATCH 2/2] dmaengine: sa11x0: remove broken #ifdef

[Shevchenko, Andriy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2466 bytes --]

On Thu, 2014-05-08 at 16:56 +0200, Arnd Bergmann wrote:
> The sa11x0_dma_pm_ops unconditionally reference sa11x0_dma_resume
> and sa11x0_dma_suspend, which currently breaks if CONFIG_PM_SLEEP
> is disabled.
> 
> There is probably a better way to remove the reference in this
> case, but the safe choice is to have the suspend/resume code always
> built in the driver.

Maybe you could create a macro in pm.h for *_noirq version of
suspend/resume? However, like we discussed with Vinod it's much better
to use suspend_late/resume_early for DMAC device drivers, though I have
no idea if it works for sa11x0.

> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: dmaengine@vger.kernel.org
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> ---
>  drivers/dma/sa11x0-dma.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/dma/sa11x0-dma.c b/drivers/dma/sa11x0-dma.c
> index ab26d46..5ebdfbc 100644
> --- a/drivers/dma/sa11x0-dma.c
> +++ b/drivers/dma/sa11x0-dma.c
> @@ -113,11 +113,9 @@ struct sa11x0_dma_phy {
>  	struct sa11x0_dma_desc	*txd_load;
>  	unsigned		sg_done;
>  	struct sa11x0_dma_desc	*txd_done;
> -#ifdef CONFIG_PM_SLEEP
>  	u32			dbs[2];
>  	u32			dbt[2];
>  	u32			dcsr;
> -#endif
>  };
>  
>  struct sa11x0_dma_dev {
> @@ -984,7 +982,6 @@ static int sa11x0_dma_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -#ifdef CONFIG_PM_SLEEP
>  static int sa11x0_dma_suspend(struct device *dev)
>  {
>  	struct sa11x0_dma_dev *d = dev_get_drvdata(dev);
> @@ -1054,7 +1051,6 @@ static int sa11x0_dma_resume(struct device *dev)
>  
>  	return 0;
>  }
> -#endif
>  
>  static const struct dev_pm_ops sa11x0_dma_pm_ops = {
>  	.suspend_noirq = sa11x0_dma_suspend,


-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 2/2] dmaengine: sa11x0: remove broken #ifdef

[Vinod Koul]

On Thu, May 08, 2014 at 09:38:37PM +0530, Shevchenko, Andriy wrote:
> On Thu, 2014-05-08 at 16:56 +0200, Arnd Bergmann wrote:
> > The sa11x0_dma_pm_ops unconditionally reference sa11x0_dma_resume
> > and sa11x0_dma_suspend, which currently breaks if CONFIG_PM_SLEEP
> > is disabled.
> > 
> > There is probably a better way to remove the reference in this
> > case, but the safe choice is to have the suspend/resume code always
> > built in the driver.
> 
> Maybe you could create a macro in pm.h for *_noirq version of
> suspend/resume? However, like we discussed with Vinod it's much better
> to use suspend_late/resume_early for DMAC device drivers, though I have
> no idea if it works for sa11x0.
It should work as the guidance is not client/controller specfic. But I think
thats not the point here as the fix is not related to how suspend is
implemented..

-- 
~Vinod

> 
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: dmaengine@vger.kernel.org
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > ---
> >  drivers/dma/sa11x0-dma.c | 4 ----
> >  1 file changed, 4 deletions(-)
> > 
> > diff --git a/drivers/dma/sa11x0-dma.c b/drivers/dma/sa11x0-dma.c
> > index ab26d46..5ebdfbc 100644
> > --- a/drivers/dma/sa11x0-dma.c
> > +++ b/drivers/dma/sa11x0-dma.c
> > @@ -113,11 +113,9 @@ struct sa11x0_dma_phy {
> >  	struct sa11x0_dma_desc	*txd_load;
> >  	unsigned		sg_done;
> >  	struct sa11x0_dma_desc	*txd_done;
> > -#ifdef CONFIG_PM_SLEEP
> >  	u32			dbs[2];
> >  	u32			dbt[2];
> >  	u32			dcsr;
> > -#endif
> >  };
> >  
> >  struct sa11x0_dma_dev {
> > @@ -984,7 +982,6 @@ static int sa11x0_dma_remove(struct platform_device *pdev)
> >  	return 0;
> >  }
> >  
> > -#ifdef CONFIG_PM_SLEEP
> >  static int sa11x0_dma_suspend(struct device *dev)
> >  {
> >  	struct sa11x0_dma_dev *d = dev_get_drvdata(dev);
> > @@ -1054,7 +1051,6 @@ static int sa11x0_dma_resume(struct device *dev)
> >  
> >  	return 0;
> >  }
> > -#endif
> >  
> >  static const struct dev_pm_ops sa11x0_dma_pm_ops = {
> >  	.suspend_noirq = sa11x0_dma_suspend,
> 
> 
> -- 
> Andy Shevchenko <andriy.shevchenko@intel.com>
> Intel Finland Oy

-- 

[PATCH 1/2] mtd/onenand: fix build warning for dma type

[Arnd Bergmann]

The samsung onenand driver passes around a dma address token
through a void pointer, which is incorrect and leads to
warnings like this one:

onenand/samsung.c:548:2: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast [enabled by default]
  writel(src, base + S5PC110_DMA_SRC_ADDR);
  ^

This patch makes it use dma_addr_t here, which is more appropriate.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: linux-mtd@lists.infradead.org
---
 drivers/mtd/onenand/samsung.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index b1a792f..efb819c 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -537,9 +537,9 @@ static int onenand_write_bufferram(struct mtd_info *mtd, int area,
 	return 0;
 }
 
-static int (*s5pc110_dma_ops)(void *dst, void *src, size_t count, int direction);
+static int (*s5pc110_dma_ops)(dma_addr_t dst, dma_addr_t src, size_t count, int direction);
 
-static int s5pc110_dma_poll(void *dst, void *src, size_t count, int direction)
+static int s5pc110_dma_poll(dma_addr_t dst, dma_addr_t src, size_t count, int direction)
 {
 	void __iomem *base = onenand->dma_addr;
 	int status;
@@ -605,7 +605,7 @@ static irqreturn_t s5pc110_onenand_irq(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
-static int s5pc110_dma_irq(void *dst, void *src, size_t count, int direction)
+static int s5pc110_dma_irq(dma_addr_t dst, dma_addr_t src, size_t count, int direction)
 {
 	void __iomem *base = onenand->dma_addr;
 	int status;
@@ -686,7 +686,7 @@ static int s5pc110_read_bufferram(struct mtd_info *mtd, int area,
 		dev_err(dev, "Couldn't map a %d byte buffer for DMA\n", count);
 		goto normal;
 	}
-	err = s5pc110_dma_ops((void *) dma_dst, (void *) dma_src,
+	err = s5pc110_dma_ops(dma_dst, dma_src,
 			count, S5PC110_DMA_DIR_READ);
 
 	if (page_dma)
-- 
1.8.3.2

Re: [PATCH 1/2] mtd/onenand: fix build warning for dma type

[Brian Norris]

On Thu, May 08, 2014 at 04:56:14PM +0200, Arnd Bergmann wrote:
> The samsung onenand driver passes around a dma address token
> through a void pointer, which is incorrect and leads to
> warnings like this one:
> 
> onenand/samsung.c:548:2: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast [enabled by default]
>   writel(src, base + S5PC110_DMA_SRC_ADDR);
>   ^
> 
> This patch makes it use dma_addr_t here, which is more appropriate.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Brian Norris <computersforpeace@gmail.com>
> Cc: linux-mtd@lists.infradead.org

Pushed this one to l2-mtd.git. Thanks!

I think the second MTD patch is still under discussion, right? I'll
follow up there if necessary.

Brian

[PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Arnd Bergmann]

orion_nand_read_buf uses an inline assembly with the "ldrd"
instruction, which is only available from ARMv5 upwards. This
used to be fine, since all users have an ARMv5 or ARMv7 CPU,
but now we can also build a multiplatform kernel with ARMv4
support enabled in addition to the "kirkwood" (mvebu) platform.

This provides an alternative to call the readsl() function that
is supposed to have the same effect and is also optimized for
performance.

This patch is untested, and it would be worthwhile to check
if there is any performance impact, especially in case the readsl
version is actually faster.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: linux-mtd@lists.infradead.org
---
 drivers/mtd/nand/orion_nand.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index dd7fe81..c7b5e8a 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -56,6 +56,7 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
 		*buf++ = readb(io_base);
 		len--;
 	}
+#if __LINUX_ARM_ARCH__ >= 5
 	buf64 = (uint64_t *)buf;
 	while (i < len/8) {
 		/*
@@ -68,6 +69,10 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
 		asm volatile ("ldrd\t%0, [%1]" : "=&r" (x) : "r" (io_base));
 		buf64[i++] = x;
 	}
+#else
+	readsl(io_base, buf, len/8);
+	i = len / 8 * 8;
+#endif
 	i *= 8;
 	while (i < len)
 		buf[i++] = readb(io_base);
-- 
1.8.3.2

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Ezequiel Garcia]

On 08 May 04:56 PM, Arnd Bergmann wrote:
> orion_nand_read_buf uses an inline assembly with the "ldrd"
> instruction, which is only available from ARMv5 upwards. This
> used to be fine, since all users have an ARMv5 or ARMv7 CPU,
> but now we can also build a multiplatform kernel with ARMv4
> support enabled in addition to the "kirkwood" (mvebu) platform.
> 
> This provides an alternative to call the readsl() function that
> is supposed to have the same effect and is also optimized for
> performance.
> 
> This patch is untested, and it would be worthwhile to check
> if there is any performance impact, especially in case the readsl
> version is actually faster.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Brian Norris <computersforpeace@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: linux-mtd@lists.infradead.org
> ---
>  drivers/mtd/nand/orion_nand.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> index dd7fe81..c7b5e8a 100644
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -56,6 +56,7 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
>  		*buf++ = readb(io_base);
>  		len--;
>  	}
> +#if __LINUX_ARM_ARCH__ >= 5
>  	buf64 = (uint64_t *)buf;
>  	while (i < len/8) {
>  		/*
> @@ -68,6 +69,10 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
>  		asm volatile ("ldrd\t%0, [%1]" : "=&r" (x) : "r" (io_base));
>  		buf64[i++] = x;
>  	}
> +#else
> +	readsl(io_base, buf, len/8);

I gave this a try in order to answer Arnd's performance question. First of all,
the patch seems wrong. I guess it's because readsl reads 4-bytes pieces, instead of
8-bytes.

This patch below is tested (but not completely, see below) and works:

diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index dd7fe81..7a78cc5 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -52,6 +52,7 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
 	uint64_t *buf64;
 	int i = 0;
 
+#if __LINUX_ARM_ARCH__ >= 5
 	while (len && (unsigned long)buf & 7) {
 		*buf++ = readb(io_base);
 		len--;
@@ -69,6 +70,14 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
 		buf64[i++] = x;
 	}
 	i *= 8;
+#else
+	while (len && (unsigned long)buf & 3) {
+		*buf++ = readb(io_base);
+		len--;
+	}
+	readsl(io_base, buf, len/4);
+	i = (len / 4 * 4) * 4;
+#endif
 	while (i < len)
 		buf[i++] = readb(io_base);
 }

However, all the reads are nicely aligned (in both the buffer and the
length) which means the only 'read' performed in the readsl() one.

In other words, the patch is still half-untested. Therefore, and given
this is meant only to coherce a build, maybe we'd rather just loop over
readb and stay on the safe side?

And now, answering Arnd's question:

# Using ldrd
# time nanddump /dev/mtd5 -f /dev/null -q
real	0m 5.90s
user	0m 0.22s
sys	0m 5.67s

# Using readsl
# time nanddump /dev/mtd5 -f /dev/null -q
real	0m 6.39s
user	0m 0.17s
sys	0m 6.20s

So I'd say, let's stick to the ldrd magic.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Geert Uytterhoeven]

On Fri, May 9, 2014 at 8:45 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -52,6 +52,7 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
>         uint64_t *buf64;
>         int i = 0;
>
> +#if __LINUX_ARM_ARCH__ >= 5
>         while (len && (unsigned long)buf & 7) {
>                 *buf++ = readb(io_base);
>                 len--;
> @@ -69,6 +70,14 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
>                 buf64[i++] = x;
>         }
>         i *= 8;
> +#else
> +       while (len && (unsigned long)buf & 3) {
> +               *buf++ = readb(io_base);
> +               len--;
> +       }
> +       readsl(io_base, buf, len/4);
> +       i = (len / 4 * 4) * 4;

Why multiply by 4 twice? "i" is supposed to be the number of bytes read,
right?

BTW, Arnd's version should just need s/8/4/g to make it work.

> +#endif
>         while (i < len)
>                 buf[i++] = readb(io_base);
>  }

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Arnd Bergmann]

On Friday 09 May 2014 15:45:05 Ezequiel Garcia wrote:
> On 08 May 04:56 PM, Arnd Bergmann wrote:
> 
> I gave this a try in order to answer Arnd's performance question.

Thanks a lot for testing!

> First of all,
> the patch seems wrong. I guess it's because readsl reads 4-bytes pieces, instead of
> 8-bytes.

Oops. I guess I was thinking of a 64-bit system and didn't even notice
the difference between 4 and 8 byte accesses here. I wonder where I have
my mind sometimes.

> In other words, the patch is still half-untested. Therefore, and given
> this is meant only to coherce a build, maybe we'd rather just loop over
> readb and stay on the safe side?

I guess that would be equal to calling memcpy_fromio().

> And now, answering Arnd's question:
> 
> # Using ldrd
> # time nanddump /dev/mtd5 -f /dev/null -q
> real	0m 5.90s
> user	0m 0.22s
> sys	0m 5.67s
> 
> # Using readsl
> # time nanddump /dev/mtd5 -f /dev/null -q
> real	0m 6.39s
> user	0m 0.17s
> sys	0m 6.20s
> 
> So I'd say, let's stick to the ldrd magic.

Ok, that is a noticeable difference. For scale, what is the size of that partition?
If this is something that actually affects people, it might be worth also trying
memcpy(), which should be better at saturating the bus, but might be wrong here
(if alignment the alignment requirements on the external bus are stricter than
what memcpy does) or it might not make a difference at all if the code is already
ideal.

	Arnd

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Jason Gunthorpe]

On Fri, May 09, 2014 at 03:45:05PM -0300, Ezequiel Garcia wrote:

> I gave this a try in order to answer Arnd's performance
> question. First of all, the patch seems wrong. I guess it's because
> readsl reads 4-bytes pieces, instead of 8-bytes.
> 
> This patch below is tested (but not completely, see below) and works:

Compilers are better now, I think you can just ditch the weirdness:

uint64_t *from;
uint64_t *to;
void foo()
{
	for (unsigned int I = 0; I != 1000; I++)
		*to++ = *from;
}

Using even gcc 4.6.3 gives good code:

(v6)
.L2:
        ldrd    r2, [ip]
        strd    r2, [r1], #8
        cmp     r1, r0

(v4)
.L2:
        ldmia   ip, {r0-r1}
        stmia   r3!, {r0-r1}
        cmp     r3, r2

For correctness this v4 version does require that the cpu executes the
ldmia reads in increasing address order, and never in any other
order. AFAIK the periphal is just a simple fifo that basically ignores
the address.

memcpy_fromio is not as good since it will never align if the buffer
is unaligned, while this version does.

The below gives:

  c8:   ea000002        b       d8 <orion_nand_read_buf+0x84>
  cc:   e5dc0000        ldrb    r0, [ip]
  d0:   e7c30001        strb    r0, [r3, r1]
  d4:   e2811001        add     r1, r1, #1
  d8:   e1510002        cmp     r1, r2

Which looks the same as the asm version to me.

diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index dc9d07f34b8a..fea1597f623e 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -95,16 +95,13 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
 	}
 	buf64 = (uint64_t *)buf;
 	while (i < len/8) {
-		/*
-		 * Since GCC has no proper constraint (PR 43518)
-		 * force x variable to r2/r3 registers as ldrd instruction
-		 * requires first register to be even.
-		 */
-		register uint64_t x asm ("r2");
-
-		asm volatile ("ldrd\t%0, [%1]" : "=&r" (x) : "r" (io_base));
-		buf64[i++] = x;
+#ifdef CONFIG_64BIT
+		buf64[i++] = readq_relaxed(io_base);
+#else
+		buf64[i++] = *(const volatile u64 __force *)io_base;
+#endif
 	}
+
 	i *= 8;
 	while (i < len)
 		buf[i++] = readb(io_base);

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Ezequiel Garcia]

On 09 May 03:28 PM, Jason Gunthorpe wrote:
> 
> > I gave this a try in order to answer Arnd's performance
> > question. First of all, the patch seems wrong. I guess it's because
> > readsl reads 4-bytes pieces, instead of 8-bytes.
> > 
> > This patch below is tested (but not completely, see below) and works:
> 
> Compilers are better now, I think you can just ditch the weirdness:
> 
[..]
> 
> The below gives:
> 
>   c8:   ea000002        b       d8 <orion_nand_read_buf+0x84>
>   cc:   e5dc0000        ldrb    r0, [ip]
>   d0:   e7c30001        strb    r0, [r3, r1]
>   d4:   e2811001        add     r1, r1, #1
>   d8:   e1510002        cmp     r1, r2
> 
> Which looks the same as the asm version to me.
> 

Nice! It wasn't really needed but since I have the board here:

# time nanddump /dev/mtd5 -f /dev/null -q
real	0m 5.82s
user	0m 0.20s
sys	0m 5.60s

Jason: Care to submit a proper patch?

On 08 May 04:56 PM, Arnd Bergmann wrote:
> Ok, that is a noticeable difference. For scale, what is the size of that partition?

The board is Openblocks A6, running mainline.

# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00090000 00004000 "uboot"
mtd1: 00044000 00004000 "env"
mtd2: 00024000 00004000 "test"
mtd3: 00400000 00004000 "conf"
mtd4: 01d20000 00004000 "linux"
mtd5: 01dec000 00004000 "user"

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Arnd Bergmann]

On Friday 09 May 2014 19:09:15 Ezequiel Garcia wrote:
> # time nanddump /dev/mtd5 -f /dev/null -q
> real    0m 5.82s
> user    0m 0.20s
> sys     0m 5.60s
> 
> Jason: Care to submit a proper patch?
> 
> On 08 May 04:56 PM, Arnd Bergmann wrote:
> > Ok, that is a noticeable difference. For scale, what is the size of that partition?
> 
> The board is Openblocks A6, running mainline.
> 
> # cat /proc/mtd 
> dev:    size   erasesize  name
> mtd0: 00090000 00004000 "uboot"
> mtd1: 00044000 00004000 "env"
> mtd2: 00024000 00004000 "test"
> mtd3: 00400000 00004000 "conf"
> mtd4: 01d20000 00004000 "linux"
> mtd5: 01dec000 00004000 "user"

Ok, so it takes 5.6 seconds in kernel mode to access 31MB, which comes down
to 5.60MB/s. That isn't very fast compared to the time the CPU should take
for those instructions, so I'm surprised it actually makes any difference
at all.

There isn't a usable slave DMA engine in Armada XP by chance?

	Arnd

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Ezequiel Garcia]

On 10 May 12:24 AM, Arnd Bergmann wrote:
> On Friday 09 May 2014 19:09:15 Ezequiel Garcia wrote:
> > # time nanddump /dev/mtd5 -f /dev/null -q
> > real    0m 5.82s
> > user    0m 0.20s
> > sys     0m 5.60s
> > 
> > Jason: Care to submit a proper patch?
> > 
> > On 08 May 04:56 PM, Arnd Bergmann wrote:
> > > Ok, that is a noticeable difference. For scale, what is the size of that partition?
> > 
> > The board is Openblocks A6, running mainline.
> > 
> > # cat /proc/mtd 
> > dev:    size   erasesize  name
> > mtd0: 00090000 00004000 "uboot"
> > mtd1: 00044000 00004000 "env"
> > mtd2: 00024000 00004000 "test"
> > mtd3: 00400000 00004000 "conf"
> > mtd4: 01d20000 00004000 "linux"
> > mtd5: 01dec000 00004000 "user"
> 
> Ok, so it takes 5.6 seconds in kernel mode to access 31MB, which comes down
> to 5.60MB/s. That isn't very fast compared to the time the CPU should take
> for those instructions, so I'm surprised it actually makes any difference
> at all.
>
> There isn't a usable slave DMA engine in Armada XP by chance?
> 

The Openblocks A6 is a Kirkwood, not Armada XP.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Jason Gunthorpe]

On Fri, May 09, 2014 at 07:09:15PM -0300, Ezequiel Garcia wrote:
> On 09 May 03:28 PM, Jason Gunthorpe wrote:
> > 
> > > I gave this a try in order to answer Arnd's performance
> > > question. First of all, the patch seems wrong. I guess it's because
> > > readsl reads 4-bytes pieces, instead of 8-bytes.
> > > 
> > > This patch below is tested (but not completely, see below) and works:
> > 
> > Compilers are better now, I think you can just ditch the weirdness:
> > 
> [..]
> > 
> > The below gives:
> > 
> >   c8:   ea000002        b       d8 <orion_nand_read_buf+0x84>
> >   cc:   e5dc0000        ldrb    r0, [ip]
> >   d0:   e7c30001        strb    r0, [r3, r1]
> >   d4:   e2811001        add     r1, r1, #1
> >   d8:   e1510002        cmp     r1, r2
> > 
> > Which looks the same as the asm version to me.
> > 
> 
> Nice! It wasn't really needed but since I have the board here:
> 
> # time nanddump /dev/mtd5 -f /dev/null -q
> real	0m 5.82s
> user	0m 0.20s
> sys	0m 5.60s
> 
> Jason: Care to submit a proper patch?

Sure, but did anyone (Arnd?) have thoughts on a better way to do this:

+#ifdef CONFIG_64BIT
+               buf64[i++] = readq_relaxed(io_base);
+#else
+               buf64[i++] = *(const volatile u64 __force *)io_base;
+#endif

IMHO, readq should exist on any platform that can issue a 64 bit bus
transaction, and I expect many ARM's qualify.

> On 08 May 04:56 PM, Arnd Bergmann wrote:

> Ok, so it takes 5.6 seconds in kernel mode to access 31MB, which
> comes down to 5.60MB/s. That isn't very fast compared to the time
> the CPU should take for those instructions, so I'm surprised it
> actually makes any difference at all.

Likely, what is happening is that the bus interface is holding off
returning the read data until it complets the bus cycles, then the
response travels to the CPU which turns around another.

This creates a dead time where the bus isn't do anything.

The larger bus transfer the CPU can do the less percentage of time the
turnaround takes as overhead.

If the cpu could pipeline two reads then it could be highest-possible,
but I guess the memory ordering for the mapping prevents that??

Regarding DMA, who knows if the interface can handle a burst
transfer..

Jason

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Arnd Bergmann]

On Tuesday 13 May 2014 14:55:48 Jason Gunthorpe wrote:
> On Fri, May 09, 2014 at 07:09:15PM -0300, Ezequiel Garcia wrote:
> > On 09 May 03:28 PM, Jason Gunthorpe wrote:
> > > 
> > > > I gave this a try in order to answer Arnd's performance
> > > > question. First of all, the patch seems wrong. I guess it's because
> > > > readsl reads 4-bytes pieces, instead of 8-bytes.
> > > > 
> > > > This patch below is tested (but not completely, see below) and works:
> > > 
> > > Compilers are better now, I think you can just ditch the weirdness:
> > > 
> > [..]
> > > 
> > > The below gives:
> > > 
> > >   c8:   ea000002        b       d8 <orion_nand_read_buf+0x84>
> > >   cc:   e5dc0000        ldrb    r0, [ip]
> > >   d0:   e7c30001        strb    r0, [r3, r1]
> > >   d4:   e2811001        add     r1, r1, #1
> > >   d8:   e1510002        cmp     r1, r2
> > > 
> > > Which looks the same as the asm version to me.
> > > 
> > 
> > Nice! It wasn't really needed but since I have the board here:
> > 
> > # time nanddump /dev/mtd5 -f /dev/null -q
> > real  0m 5.82s
> > user  0m 0.20s
> > sys   0m 5.60s
> > 
> > Jason: Care to submit a proper patch?
> 
> Sure, but did anyone (Arnd?) have thoughts on a better way to do this:
> 
> +#ifdef CONFIG_64BIT
> +               buf64[i++] = readq_relaxed(io_base);
> +#else
> +               buf64[i++] = *(const volatile u64 __force *)io_base;
> +#endif
>
> IMHO, readq should exist on any platform that can issue a 64 bit bus
> transaction, and I expect many ARM's qualify.

Well, the original problem happened specifically for the case that doesn't
have a 64-bit bus transaction (building for ARMv4). If we define
readq_relaxed, it has to be an inline assembly, in order to work for
drivers that require an atomic transaction, so that would have the
same problem. We are a bit inconsistent here though: most 32-bit
architectures have no readq, parisc has one that does two 32-bit accesses,
sh relies on the compiler, and tile apparently has a native instruction.

It seems reasonable to replace the inline assembly in this driver with
a new function as a cleanup, but then how do you want to solve the case
of building a combined armv4/v5 kernel?

	Arnd

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Geert Uytterhoeven]

On Wed, May 14, 2014 at 1:47 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> Sure, but did anyone (Arnd?) have thoughts on a better way to do this:
>>
>> +#ifdef CONFIG_64BIT
>> +               buf64[i++] = readq_relaxed(io_base);
>> +#else
>> +               buf64[i++] = *(const volatile u64 __force *)io_base;
>> +#endif
>>
>> IMHO, readq should exist on any platform that can issue a 64 bit bus
>> transaction, and I expect many ARM's qualify.
>
> Well, the original problem happened specifically for the case that doesn't
> have a 64-bit bus transaction (building for ARMv4). If we define
> readq_relaxed, it has to be an inline assembly, in order to work for
> drivers that require an atomic transaction, so that would have the
> same problem. We are a bit inconsistent here though: most 32-bit
> architectures have no readq, parisc has one that does two 32-bit accesses,
> sh relies on the compiler, and tile apparently has a native instruction.
>
> It seems reasonable to replace the inline assembly in this driver with
> a new function as a cleanup, but then how do you want to solve the case
> of building a combined armv4/v5 kernel?

Provide two helper functions, one for v4, one for v5, and call
them through a function pointer that's set up during driver probe?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4

[Arnd Bergmann]

On Wednesday 14 May 2014 14:35:28 Geert Uytterhoeven wrote:
> On Wed, May 14, 2014 at 1:47 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> Sure, but did anyone (Arnd?) have thoughts on a better way to do this:
> >>
> >> +#ifdef CONFIG_64BIT
> >> +               buf64[i++] = readq_relaxed(io_base);
> >> +#else
> >> +               buf64[i++] = *(const volatile u64 __force *)io_base;
> >> +#endif
> >>
> >> IMHO, readq should exist on any platform that can issue a 64 bit bus
> >> transaction, and I expect many ARM's qualify.
> >
> > Well, the original problem happened specifically for the case that doesn't
> > have a 64-bit bus transaction (building for ARMv4). If we define
> > readq_relaxed, it has to be an inline assembly, in order to work for
> > drivers that require an atomic transaction, so that would have the
> > same problem. We are a bit inconsistent here though: most 32-bit
> > architectures have no readq, parisc has one that does two 32-bit accesses,
> > sh relies on the compiler, and tile apparently has a native instruction.
> >
> > It seems reasonable to replace the inline assembly in this driver with
> > a new function as a cleanup, but then how do you want to solve the case
> > of building a combined armv4/v5 kernel?
> 
> Provide two helper functions, one for v4, one for v5, and call
> them through a function pointer that's set up during driver probe?

No, that won't help. It's a compile-time problem only: This driver
is never actually used on ARMv4, but if we build a kernel that supports
both ARMv4 and later, gcc passes -march=armv4 to the assembler, which
barfs on an invalid instruction. It would be fine to make that error
message just go away because we know it will only be used on CPUs that
do have this instruction.

	Arnd

[PATCH] clk/versatile: export symbols for impd1

[Arnd Bergmann]

The impd1 code on mach-integrator can be a loadable module,
so we have to export icst_clk_register, integrator_impd1_clk_init
and integrator_impd1_clk_exit.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/clk/versatile/clk-icst.c  | 1 +
 drivers/clk/versatile/clk-impd1.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/clk/versatile/clk-icst.c b/drivers/clk/versatile/clk-icst.c
index a820b0c..7f3868a 100644
--- a/drivers/clk/versatile/clk-icst.c
+++ b/drivers/clk/versatile/clk-icst.c
@@ -160,3 +160,4 @@ struct clk *icst_clk_register(struct device *dev,
 
 	return clk;
 }
+EXPORT_SYMBOL_GPL(icst_clk_register);
diff --git a/drivers/clk/versatile/clk-impd1.c b/drivers/clk/versatile/clk-impd1.c
index 31b44f0..264d8d5 100644
--- a/drivers/clk/versatile/clk-impd1.c
+++ b/drivers/clk/versatile/clk-impd1.c
@@ -133,6 +133,7 @@ void integrator_impd1_clk_init(void __iomem *base, unsigned int id)
 	for (i = 0; i < ARRAY_SIZE(imc->clks); i++)
 		clkdev_add(imc->clks[i]);
 }
+EXPORT_SYMBOL_GPL(integrator_impd1_clk_init);
 
 void integrator_impd1_clk_exit(unsigned int id)
 {
@@ -155,3 +156,4 @@ void integrator_impd1_clk_exit(unsigned int id)
 	kfree(imc->vco2name);
 	kfree(imc->vco1name);
 }
+EXPORT_SYMBOL_GPL(integrator_impd1_clk_exit);
-- 
1.8.3.2

Re: [PATCH] clk/versatile: export symbols for impd1

[Linus Walleij]

On Thu, May 8, 2014 at 4:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The impd1 code on mach-integrator can be a loadable module,
> so we have to export icst_clk_register, integrator_impd1_clk_init
> and integrator_impd1_clk_exit.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>

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

Yours,
Linus Walleij

Re: [PATCH] clk/versatile: export symbols for impd1

[Mike Turquette]

Quoting Arnd Bergmann (2014-05-08 07:56:16)
> The impd1 code on mach-integrator can be a loadable module,
> so we have to export icst_clk_register, integrator_impd1_clk_init
> and integrator_impd1_clk_exit.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>

Taken into clk-next.

Thanks!
Mike

> ---
>  drivers/clk/versatile/clk-icst.c  | 1 +
>  drivers/clk/versatile/clk-impd1.c | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/clk/versatile/clk-icst.c b/drivers/clk/versatile/clk-icst.c
> index a820b0c..7f3868a 100644
> --- a/drivers/clk/versatile/clk-icst.c
> +++ b/drivers/clk/versatile/clk-icst.c
> @@ -160,3 +160,4 @@ struct clk *icst_clk_register(struct device *dev,
>  
>         return clk;
>  }
> +EXPORT_SYMBOL_GPL(icst_clk_register);
> diff --git a/drivers/clk/versatile/clk-impd1.c b/drivers/clk/versatile/clk-impd1.c
> index 31b44f0..264d8d5 100644
> --- a/drivers/clk/versatile/clk-impd1.c
> +++ b/drivers/clk/versatile/clk-impd1.c
> @@ -133,6 +133,7 @@ void integrator_impd1_clk_init(void __iomem *base, unsigned int id)
>         for (i = 0; i < ARRAY_SIZE(imc->clks); i++)
>                 clkdev_add(imc->clks[i]);
>  }
> +EXPORT_SYMBOL_GPL(integrator_impd1_clk_init);
>  
>  void integrator_impd1_clk_exit(unsigned int id)
>  {
> @@ -155,3 +156,4 @@ void integrator_impd1_clk_exit(unsigned int id)
>         kfree(imc->vco2name);
>         kfree(imc->vco1name);
>  }
> +EXPORT_SYMBOL_GPL(integrator_impd1_clk_exit);
> -- 
> 1.8.3.2
> 

[PATCH] bus/omap_l3: avoid sync initcall for modules

[Arnd Bergmann]

The postcore_initcall_sync() macro is only defined for built-in
code, but the omap_l3 bus code can be built as a module, which
currently causes a build failure.

This works around the problem by using #ifdef MODULE to decide
whether to use a regular module_init() function or not.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
---
 drivers/bus/omap_l3_noc.c | 4 ++++
 drivers/bus/omap_l3_smx.c | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae..648f158 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -257,7 +257,11 @@ static int __init omap4_l3_init(void)
 {
 	return platform_driver_register(&omap4_l3_driver);
 }
+#ifdef MODULE
+module_init(omap4_l3_init);
+#else
 postcore_initcall_sync(omap4_l3_init);
+#endif
 
 static void __exit omap4_l3_exit(void)
 {
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc2164..f752d1b 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -288,7 +288,11 @@ static int __init omap3_l3_init(void)
 {
 	return platform_driver_probe(&omap3_l3_driver, omap3_l3_probe);
 }
+#ifdef MODULE
+module_init(omap3_l3_init);
+#else
 postcore_initcall_sync(omap3_l3_init);
+#endif
 
 static void __exit omap3_l3_exit(void)
 {
-- 
1.8.3.2

Re: [PATCH] bus/omap_l3: avoid sync initcall for modules

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140508 07:57]:
> The postcore_initcall_sync() macro is only defined for built-in
> code, but the omap_l3 bus code can be built as a module, which
> currently causes a build failure.
> 
> This works around the problem by using #ifdef MODULE to decide
> whether to use a regular module_init() function or not.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Felipe Balbi <balbi@ti.com>
> ---
>  drivers/bus/omap_l3_noc.c | 4 ++++
>  drivers/bus/omap_l3_smx.c | 4 ++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
> index feeecae..648f158 100644
> --- a/drivers/bus/omap_l3_noc.c
> +++ b/drivers/bus/omap_l3_noc.c
> @@ -257,7 +257,11 @@ static int __init omap4_l3_init(void)
>  {
>  	return platform_driver_register(&omap4_l3_driver);
>  }
> +#ifdef MODULE
> +module_init(omap4_l3_init);
> +#else
>  postcore_initcall_sync(omap4_l3_init);
> +#endif
>  
>  static void __exit omap4_l3_exit(void)
>  {
> diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
> index acc2164..f752d1b 100644
> --- a/drivers/bus/omap_l3_smx.c
> +++ b/drivers/bus/omap_l3_smx.c
> @@ -288,7 +288,11 @@ static int __init omap3_l3_init(void)
>  {
>  	return platform_driver_probe(&omap3_l3_driver, omap3_l3_probe);
>  }
> +#ifdef MODULE
> +module_init(omap3_l3_init);
> +#else
>  postcore_initcall_sync(omap3_l3_init);
> +#endif
>  
>  static void __exit omap3_l3_exit(void)
>  {

How about instead let's add this into include/linux/module.h
like we have for other initcalls:

#define postcore_initcall(fn)		module_init(fn)

There may be others missing too from there. BTW, this driver
might be few of the drivers that actually might need to be
initialized early for debugging to catch bad access from
other drivers.

Regards,

Tony

Re: [PATCH] bus/omap_l3: avoid sync initcall for modules

[Arnd Bergmann]

On Monday 12 May 2014 15:20:07 Tony Lindgren wrote:
> 
> How about instead let's add this into include/linux/module.h
> like we have for other initcalls:
> 
> #define postcore_initcall(fn)           module_init(fn)
> 
> There may be others missing too from there. BTW, this driver
> might be few of the drivers that actually might need to be
> initialized early for debugging to catch bad access from
> other drivers.

There is a comment above those defines saying:

/* Don't use these in loadable modules, but some people do... */

so I'm not sure if adding more would be appreciated.

	Arnd

Re: [PATCH] bus/omap_l3: avoid sync initcall for modules

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140513 08:13]:
> On Monday 12 May 2014 15:20:07 Tony Lindgren wrote:
> > 
> > How about instead let's add this into include/linux/module.h
> > like we have for other initcalls:

I mean include/linux/init.h naturally..
 
> > #define postcore_initcall(fn)           module_init(fn)
> > 
> > There may be others missing too from there. BTW, this driver
> > might be few of the drivers that actually might need to be
> > initialized early for debugging to catch bad access from
> > other drivers.
> 
> There is a comment above those defines saying:
> 
> /* Don't use these in loadable modules, but some people do... */
> 
> so I'm not sure if adding more would be appreciated.
> 
> 	Arnd

Well "some" in that comment is probably an understatement :)

$ git grep _initcall drivers/ | wc -l
737

I did not look what percentage has tristate in the Kconfig,
but that might keep some people from making loadable drivers.

Greg, is the following patch something you may want to
consider picking up?

Regards,

Tony


8< ---------------------------
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 13 May 2014 09:05:26 -0700
Subject: [PATCH] init.h: Update initcall_sync variants to fix build errors

We are getting randconfig build errors on device drivers with
tristate Kconfig option if they are using custom initcall
levels. Rather than add ifdeffery into the drivers, let's add
the missing initcall_sync variants.

As the comment in init.h has kept people from updating the
list of initcalls that can be just module_init when the driver
is loaded as a loadable module, let's also update the comment
a bit to describe valid use cases custom initcall levels.

While most drivers should nowadays use just regular module_init
because of the deferred probe, we do have quite a few custom
initcall levels left that we cannot remove until tested properly.

There are also still few valid cases where a custom initcall
level might make sense that I'm aware of.

For example a bus snooping driver can provide information about
invalid bus access and is handy loader early when built in. But
there's no hard dependency to have it necessarily built in and
a loadable module is a valid option.

Another example is a driver implementing a Linux framework like
pinctrl framework. That driver may be needed early on some
platforms because of legacy reasons, while it can be just a
regular module_init on most platforms.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -297,16 +297,28 @@ void __init parse_early_options(char *cmdline);
 
 #else /* MODULE */
 
-/* Don't use these in loadable modules, but some people do... */
+/*
+ * In most cases loadable modules do not need custom
+ * initcall levels. There are still some valid cases where
+ * a driver may be needed early if built in, and does not
+ * matter when built as a loadable module. Like bus
+ * snooping debug drivers.
+ */
 #define early_initcall(fn)		module_init(fn)
 #define core_initcall(fn)		module_init(fn)
+#define core_initcall_sync(fn)		module_init(fn)
 #define postcore_initcall(fn)		module_init(fn)
+#define postcore_initcall_sync(fn)	module_init(fn)
 #define arch_initcall(fn)		module_init(fn)
 #define subsys_initcall(fn)		module_init(fn)
+#define subsys_initcall_sync(fn)	module_init(fn)
 #define fs_initcall(fn)			module_init(fn)
+#define fs_initcall_sync(fn)		module_init(fn)
 #define rootfs_initcall(fn)		module_init(fn)
 #define device_initcall(fn)		module_init(fn)
+#define device_initcall_sync(fn)	module_init(fn)
 #define late_initcall(fn)		module_init(fn)
+#define late_initcall_sync(fn)		module_init(fn)
 
 #define console_initcall(fn)		module_init(fn)
 #define security_initcall(fn)		module_init(fn)

Re: [PATCH] bus/omap_l3: avoid sync initcall for modules

[Greg KH]

On Tue, May 13, 2014 at 09:27:33AM -0700, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [140513 08:13]:
> > On Monday 12 May 2014 15:20:07 Tony Lindgren wrote:
> > > 
> > > How about instead let's add this into include/linux/module.h
> > > like we have for other initcalls:
> 
> I mean include/linux/init.h naturally..
>  
> > > #define postcore_initcall(fn)           module_init(fn)
> > > 
> > > There may be others missing too from there. BTW, this driver
> > > might be few of the drivers that actually might need to be
> > > initialized early for debugging to catch bad access from
> > > other drivers.
> > 
> > There is a comment above those defines saying:
> > 
> > /* Don't use these in loadable modules, but some people do... */
> > 
> > so I'm not sure if adding more would be appreciated.
> > 
> > 	Arnd
> 
> Well "some" in that comment is probably an understatement :)
> 
> $ git grep _initcall drivers/ | wc -l
> 737
> 
> I did not look what percentage has tristate in the Kconfig,
> but that might keep some people from making loadable drivers.
> 
> Greg, is the following patch something you may want to
> consider picking up?

Sure, is this needed to fix issues in 3.15-final, or is 3.16-rc1 ok?

thanks,

greg k-h

Re: [PATCH] bus/omap_l3: avoid sync initcall for modules

[Arnd Bergmann]

On Wednesday 14 May 2014 10:39:31 Greg KH wrote:
> On Tue, May 13, 2014 at 09:27:33AM -0700, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [140513 08:13]:
> > 
> > I did not look what percentage has tristate in the Kconfig,
> > but that might keep some people from making loadable drivers.
> > 
> > Greg, is the following patch something you may want to
> > consider picking up?
> 
> Sure, is this needed to fix issues in 3.15-final, or is 3.16-rc1 ok?

I don't think anyone cares about it outside of randconfig builds,
so 3.16-rc1 is ok.

	Arnd

Re: [PATCH] bus/omap_l3: avoid sync initcall for modules

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140514 11:16]:
> On Wednesday 14 May 2014 10:39:31 Greg KH wrote:
> > On Tue, May 13, 2014 at 09:27:33AM -0700, Tony Lindgren wrote:
> > > * Arnd Bergmann <arnd@arndb.de> [140513 08:13]:
> > > 
> > > I did not look what percentage has tristate in the Kconfig,
> > > but that might keep some people from making loadable drivers.
> > > 
> > > Greg, is the following patch something you may want to
> > > consider picking up?
> > 
> > Sure, is this needed to fix issues in 3.15-final, or is 3.16-rc1 ok?
> 
> I don't think anyone cares about it outside of randconfig builds,
> so 3.16-rc1 is ok.

Yeah thanks.

Tony

[PATCH] bus/arm-cci: add dependency on OF && CPU_V7

[Arnd Bergmann]

The arm-cci code uses device tree helpers for initialization
that don't work on kernels built without CONFIG_OF. Further,
it contains an inline assembly in cci_enable_port_for_self()
that uses ARMv7 instructions and fails to build when targetting
other ARM instruction set versions.

This works around both issues by limiting the scope of the
Kconfig symbol to platforms that can actually build this driver
cleanly.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 drivers/bus/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 552373c..d53417e 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -37,7 +37,7 @@ config OMAP_INTERCONNECT
 
 config ARM_CCI
 	bool "ARM CCI driver support"
-	depends on ARM
+	depends on ARM && OF && CPU_V7
 	help
 	  Driver supporting the CCI cache coherent interconnect for ARM
 	  platforms.
-- 
1.8.3.2

Re: [PATCH] bus/arm-cci: add dependency on OF && CPU_V7

[Lorenzo Pieralisi]

On Thu, May 08, 2014 at 03:56:18PM +0100, Arnd Bergmann wrote:
> The arm-cci code uses device tree helpers for initialization
> that don't work on kernels built without CONFIG_OF. Further,
> it contains an inline assembly in cci_enable_port_for_self()
> that uses ARMv7 instructions and fails to build when targetting
> other ARM instruction set versions.
> 
> This works around both issues by limiting the scope of the
> Kconfig symbol to platforms that can actually build this driver
> cleanly.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
>  drivers/bus/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 552373c..d53417e 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -37,7 +37,7 @@ config OMAP_INTERCONNECT
>  
>  config ARM_CCI
>  	bool "ARM CCI driver support"
> -	depends on ARM
> +	depends on ARM && OF && CPU_V7
>  	help
>  	  Driver supporting the CCI cache coherent interconnect for ARM
>  	  platforms.

The dependency on CPU_V7 will need reworking, since we might want to
enable the driver on arm64 platforms too (eg CCI PMUs), other than that:

Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

[PATCH] watchdog: iop_wdt only builds for mach-iop13xx

[Arnd Bergmann]

All three iop variants we support in Linux (iop32x, iop33x and
iop13xx) seem to have support for the watchdog hardware, but this
driver fails to build for the first two of these because it
uses the IOP13XX_WDTCR_IB_RESET macro that is only defined for
iop13xx.

This clarifies the dependency in Kconfig to avoid randconfig
build errors. It is unlikely that anyone will ever miss support
for this driver on the ancient iop3xx platforms, so we don't
need to bother trying to fix it properly.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: linux-watchdog@vger.kernel.org
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2b4c1fc..e244548 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -272,7 +272,7 @@ config PNX4008_WATCHDOG
 
 config IOP_WATCHDOG
 	tristate "IOP Watchdog"
-	depends on PLAT_IOP
+	depends on ARCH_IOP13XX
 	select WATCHDOG_NOWAYOUT if (ARCH_IOP32X || ARCH_IOP33X)
 	help
 	  Say Y here if to include support for the watchdog timer
-- 
1.8.3.2

Re: [PATCH] watchdog: iop_wdt only builds for mach-iop13xx

[Guenter Roeck]

On Thu, May 08, 2014 at 04:56:19PM +0200, Arnd Bergmann wrote:
> All three iop variants we support in Linux (iop32x, iop33x and
> iop13xx) seem to have support for the watchdog hardware, but this
> driver fails to build for the first two of these because it
> uses the IOP13XX_WDTCR_IB_RESET macro that is only defined for
> iop13xx.
> 
> This clarifies the dependency in Kconfig to avoid randconfig
> build errors. It is unlikely that anyone will ever miss support
> for this driver on the ancient iop3xx platforms, so we don't
> need to bother trying to fix it properly.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> Cc: linux-watchdog@vger.kernel.org

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

Re: [PATCH] watchdog: iop_wdt only builds for mach-iop13xx

[Wim Van Sebroeck]

Hi Arnd,

> All three iop variants we support in Linux (iop32x, iop33x and
> iop13xx) seem to have support for the watchdog hardware, but this
> driver fails to build for the first two of these because it
> uses the IOP13XX_WDTCR_IB_RESET macro that is only defined for
> iop13xx.
> 
> This clarifies the dependency in Kconfig to avoid randconfig
> build errors. It is unlikely that anyone will ever miss support
> for this driver on the ancient iop3xx platforms, so we don't
> need to bother trying to fix it properly.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> Cc: linux-watchdog@vger.kernel.org
> ---
>  drivers/watchdog/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 2b4c1fc..e244548 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -272,7 +272,7 @@ config PNX4008_WATCHDOG
>  
>  config IOP_WATCHDOG
>  	tristate "IOP Watchdog"
> -	depends on PLAT_IOP
> +	depends on ARCH_IOP13XX
>  	select WATCHDOG_NOWAYOUT if (ARCH_IOP32X || ARCH_IOP33X)
>  	help
>  	  Say Y here if to include support for the watchdog timer

Patch has been added to linux-watchdog-next.

Kind regards,
Wim.

[PATCH] mpilib: use 'static inline' for mpi-inline.h

[Arnd Bergmann]

Four functions of mpilib are defined as 'extern inline' at the
moment, which is generally not the correct way to do inline functions
using gcc.

While this is usually harmless, it shows up as a warning in combination
with the CONFIG_PROFILE_ALL_BRANCHES, resulting in very many lines
like:

/git/arm-soc/lib/mpi/mpi-inline.h:70:182: warning: '______f' is static but declared in inline function 'mpihelp_add' which is not static [enabled by default]

Using static inline makes the code behave as expected and gets
rid of the warning

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
---
 lib/mpi/mpi-inline.h   | 2 +-
 lib/mpi/mpi-internal.h | 8 --------
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/lib/mpi/mpi-inline.h b/lib/mpi/mpi-inline.h
index e2b3985..c245ea3 100644
--- a/lib/mpi/mpi-inline.h
+++ b/lib/mpi/mpi-inline.h
@@ -30,7 +30,7 @@
 #define G10_MPI_INLINE_H
 
 #ifndef G10_MPI_INLINE_DECL
-#define G10_MPI_INLINE_DECL  extern inline
+#define G10_MPI_INLINE_DECL  static inline
 #endif
 
 G10_MPI_INLINE_DECL mpi_limb_t
diff --git a/lib/mpi/mpi-internal.h b/lib/mpi/mpi-internal.h
index 60cf765..54c1e97 100644
--- a/lib/mpi/mpi-internal.h
+++ b/lib/mpi/mpi-internal.h
@@ -168,20 +168,12 @@ void mpi_rshift_limbs(MPI a, unsigned int count);
 int mpi_lshift_limbs(MPI a, unsigned int count);
 
 /*-- mpihelp-add.c --*/
-mpi_limb_t mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
-			 mpi_size_t s1_size, mpi_limb_t s2_limb);
 mpi_limb_t mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
 			 mpi_ptr_t s2_ptr, mpi_size_t size);
-mpi_limb_t mpihelp_add(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
-		       mpi_ptr_t s2_ptr, mpi_size_t s2_size);
 
 /*-- mpihelp-sub.c --*/
-mpi_limb_t mpihelp_sub_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
-			 mpi_size_t s1_size, mpi_limb_t s2_limb);
 mpi_limb_t mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
 			 mpi_ptr_t s2_ptr, mpi_size_t size);
-mpi_limb_t mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
-		       mpi_ptr_t s2_ptr, mpi_size_t s2_size);
 
 /*-- mpihelp-cmp.c --*/
 int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size);
-- 
1.8.3.2

Re: [PATCH] mpilib: use 'static inline' for mpi-inline.h

[Steven Rostedt]

On Thu,  8 May 2014 16:56:20 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> Four functions of mpilib are defined as 'extern inline' at the
> moment, which is generally not the correct way to do inline functions
> using gcc.

I think clang would appreciate this too.

-- Steve

> 
> While this is usually harmless, it shows up as a warning in combination
> with the CONFIG_PROFILE_ALL_BRANCHES, resulting in very many lines
> like:
> 
> /git/arm-soc/lib/mpi/mpi-inline.h:70:182: warning: '______f' is static but declared in inline function 'mpihelp_add' which is not static [enabled by default]
> 
> Using static inline makes the code behave as expected and gets
> rid of the warning
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> ---
>  lib/mpi/mpi-inline.h   | 2 +-
>  lib/mpi/mpi-internal.h | 8 --------
>  2 files changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/lib/mpi/mpi-inline.h b/lib/mpi/mpi-inline.h
> index e2b3985..c245ea3 100644
> --- a/lib/mpi/mpi-inline.h
> +++ b/lib/mpi/mpi-inline.h
> @@ -30,7 +30,7 @@
>  #define G10_MPI_INLINE_H
>  
>  #ifndef G10_MPI_INLINE_DECL
> -#define G10_MPI_INLINE_DECL  extern inline
> +#define G10_MPI_INLINE_DECL  static inline
>  #endif
>  
>  G10_MPI_INLINE_DECL mpi_limb_t
> diff --git a/lib/mpi/mpi-internal.h b/lib/mpi/mpi-internal.h
> index 60cf765..54c1e97 100644
> --- a/lib/mpi/mpi-internal.h
> +++ b/lib/mpi/mpi-internal.h
> @@ -168,20 +168,12 @@ void mpi_rshift_limbs(MPI a, unsigned int count);
>  int mpi_lshift_limbs(MPI a, unsigned int count);
>  
>  /*-- mpihelp-add.c --*/
> -mpi_limb_t mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
> -			 mpi_size_t s1_size, mpi_limb_t s2_limb);
>  mpi_limb_t mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
>  			 mpi_ptr_t s2_ptr, mpi_size_t size);
> -mpi_limb_t mpihelp_add(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
> -		       mpi_ptr_t s2_ptr, mpi_size_t s2_size);
>  
>  /*-- mpihelp-sub.c --*/
> -mpi_limb_t mpihelp_sub_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
> -			 mpi_size_t s1_size, mpi_limb_t s2_limb);
>  mpi_limb_t mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
>  			 mpi_ptr_t s2_ptr, mpi_size_t size);
> -mpi_limb_t mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
> -		       mpi_ptr_t s2_ptr, mpi_size_t s2_size);
>  
>  /*-- mpihelp-cmp.c --*/
>  int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size);

Re: [PATCH] mpilib: use 'static inline' for mpi-inline.h

[Behan Webster]

On 05/08/14 08:30, Steven Rostedt wrote:
> On Thu,  8 May 2014 16:56:20 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> Four functions of mpilib are defined as 'extern inline' at the
>> moment, which is generally not the correct way to do inline functions
>> using gcc.
> I think clang would appreciate this too.
Indeed. Saves me writing the same patch. :)

Behan

-- 
Behan Webster
behanw@converseincode.com

[PATCH] ata: pata_at91 only works on sam9

[Arnd Bergmann]

The smc driver used by pata_at91 is at91sam9 specific, so building
this driver on another at91 platform results in this error:

ERROR: "sam9_smc_configure" [drivers/ata/pata_at91.ko] undefined!
ERROR: "sam9_smc_write_mode" [drivers/ata/pata_at91.ko] undefined!
ERROR: "sam9_smc_read_mode" [drivers/ata/pata_at91.ko] undefined!

This patch changes the Kconfig dependency to ensure it always works.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
 drivers/ata/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a91bf47..7671dba 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -824,7 +824,7 @@ config PATA_AT32
 
 config PATA_AT91
 	tristate "PATA support for AT91SAM9260"
-	depends on ARM && ARCH_AT91
+	depends on ARM && SOC_AT91SAM9
 	help
 	  This option enables support for IDE devices on the Atmel AT91SAM9260 SoC.
 
-- 
1.8.3.2

Re: [PATCH] ata: pata_at91 only works on sam9

[Tejun Heo]

On Thu, May 08, 2014 at 04:56:21PM +0200, Arnd Bergmann wrote:
> The smc driver used by pata_at91 is at91sam9 specific, so building
> this driver on another at91 platform results in this error:
> 
> ERROR: "sam9_smc_configure" [drivers/ata/pata_at91.ko] undefined!
> ERROR: "sam9_smc_write_mode" [drivers/ata/pata_at91.ko] undefined!
> ERROR: "sam9_smc_read_mode" [drivers/ata/pata_at91.ko] undefined!
> 
> This patch changes the Kconfig dependency to ensure it always works.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: linux-ide@vger.kernel.org
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Applied to libata/for-3.15-fixes.

Thanks.

-- 
tejun

[PATCH] i2c/nuc900: fix ancient build error

[Arnd Bergmann]

As far as I can tell, this driver must have produced this error
for as long as it has been merged into the mainline kernel, but
it was never part of the normal build tests:

drivers/i2c/busses/i2c-nuc900.c: In function 'nuc900_i2c_probe':
drivers/i2c/busses/i2c-nuc900.c:601:17: error: request for member 'apbfreq' in something not a structure or union
  ret = (i2c->clk.apbfreq)/(pdata->bus_freq * 5) - 1;
                 ^

This is an attempt to get the driver to build and possibly
work correctly, although I do wonder whether we should just
remove it, as it has clearly never worked.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org
Cc: Wan ZongShun <mcuos.com@gmail.org>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
---
 drivers/i2c/busses/i2c-nuc900.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-nuc900.c b/drivers/i2c/busses/i2c-nuc900.c
index 36394d7..e3e9f95 100644
--- a/drivers/i2c/busses/i2c-nuc900.c
+++ b/drivers/i2c/busses/i2c-nuc900.c
@@ -598,7 +598,7 @@ static int nuc900_i2c_probe(struct platform_device *pdev)
 
 	clk_get_rate(i2c->clk);
 
-	ret = (i2c->clk.apbfreq)/(pdata->bus_freq * 5) - 1;
+	ret = clk_get_rate(i2c->clk)/(pdata->bus_freq * 5) - 1;
 	writel(ret & 0xffff, i2c->regs + DIVIDER);
 
 	/* find the IRQ for this unit (note, this relies on the init call to
-- 
1.8.3.2

Re: [PATCH] i2c/nuc900: fix ancient build error

[Mark Roszko]

"[PATCH] NUC900: patch for implement clk_get_rate"
https://lkml.org/lkml/2010/6/15/147

This patch would have fixed the apbfreq not being a real struct member
and would also explain why clk_get_rate is called without using it's
return value in the line above what you have.

>From 2010, so it got dropped somewhere and ignored/abandoned

Re: [PATCH] i2c/nuc900: fix ancient build error

[Wolfram Sang]

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

On Thu, May 08, 2014 at 04:56:22PM +0200, Arnd Bergmann wrote:
> As far as I can tell, this driver must have produced this error
> for as long as it has been merged into the mainline kernel, but
> it was never part of the normal build tests:
> 
> drivers/i2c/busses/i2c-nuc900.c: In function 'nuc900_i2c_probe':
> drivers/i2c/busses/i2c-nuc900.c:601:17: error: request for member 'apbfreq' in something not a structure or union
>   ret = (i2c->clk.apbfreq)/(pdata->bus_freq * 5) - 1;
>                  ^
> 
> This is an attempt to get the driver to build and possibly
> work correctly, although I do wonder whether we should just
> remove it, as it has clearly never worked.

I'd go for removing. For this platform, the last patch which was not a
generic cleanup seems to be from late 2011?


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

Re: [PATCH] i2c/nuc900: fix ancient build error

[Arnd Bergmann]

On Wednesday 14 May 2014 18:27:25 Wolfram Sang wrote:
> On Thu, May 08, 2014 at 04:56:22PM +0200, Arnd Bergmann wrote:
> > As far as I can tell, this driver must have produced this error
> > for as long as it has been merged into the mainline kernel, but
> > it was never part of the normal build tests:
> > 
> > drivers/i2c/busses/i2c-nuc900.c: In function 'nuc900_i2c_probe':
> > drivers/i2c/busses/i2c-nuc900.c:601:17: error: request for member 'apbfreq' in something not a structure or union
> >   ret = (i2c->clk.apbfreq)/(pdata->bus_freq * 5) - 1;
> >                  ^
> > 
> > This is an attempt to get the driver to build and possibly
> > work correctly, although I do wonder whether we should just
> > remove it, as it has clearly never worked.
> 
> I'd go for removing. For this platform, the last patch which was not a
> generic cleanup seems to be from late 2011?

Ah, you mean removing the entire platform? I guess we could do that
as well, but I was really thinking of just removing the i2c driver.

For the moment, I'd leave this up to Wan ZongShun. He has in the past
at least replied to emails about the platform, even though there hasn't
been any new development.

	Arnd

Re: [PATCH] i2c/nuc900: fix ancient build error

[Wolfram Sang]

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


> For the moment, I'd leave this up to Wan ZongShun. He has in the past
> at least replied to emails about the platform, even though there hasn't
> been any new development.

Agreed. Let's wait for his response. If there is none, I'll think about
removing the driver.


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

Re: [PATCH] i2c/nuc900: fix ancient build error

[Wolfram Sang]

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

On Wed, May 14, 2014 at 09:17:49PM +0200, Wolfram Sang wrote:
> 
> > For the moment, I'd leave this up to Wan ZongShun. He has in the past
> > at least replied to emails about the platform, even though there hasn't
> > been any new development.
> 
> Agreed. Let's wait for his response. If there is none, I'll think about
> removing the driver.
> 

Wan ZongShun, final call before this driver gets removed next week.


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

[PATCH 1/2] iio: always select ANON_INODES

[Arnd Bergmann]

Without ANON_INODES, we get this build error:

drivers/built-in.o: In function `iio_event_getfd':
:(.text+0x14bf18): undefined reference to `anon_inode_getfd'

All other users explicitly select this symbol, so we should
do the same thing here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
---
 drivers/iio/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 743485e..345395e 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -4,6 +4,7 @@
 
 menuconfig IIO
 	tristate "Industrial I/O support"
+	select ANON_INODES
 	help
 	  The industrial I/O subsystem provides a unified framework for
 	  drivers for many different types of embedded sensors using a
-- 
1.8.3.2

Re: [PATCH 1/2] iio: always select ANON_INODES

[Jonathan Cameron]

On 08/05/14 15:56, Arnd Bergmann wrote:
> Without ANON_INODES, we get this build error:
>
> drivers/built-in.o: In function `iio_event_getfd':
> :(.text+0x14bf18): undefined reference to `anon_inode_getfd'
>
> All other users explicitly select this symbol, so we should
> do the same thing here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: linux-iio@vger.kernel.org
Applied to the togreg branch of iio.git.

Thanks,
> ---
>   drivers/iio/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 743485e..345395e 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -4,6 +4,7 @@
>
>   menuconfig IIO
>   	tristate "Industrial I/O support"
> +	select ANON_INODES
>   	help
>   	  The industrial I/O subsystem provides a unified framework for
>   	  drivers for many different types of embedded sensors using a
>

[PATCH 2/2] iio:adc: at91 requires the input subsystem

[Arnd Bergmann]

Building the at91 adc driver with CONFIG_INPUT disabled results in this
build error:

ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!

To make sure we can build random configurations, this turns on CONFIG_INPUT
whenever CONFIG_AT91_ADC is enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-iio@vger.kernel.org
Cc: Josh Wu <josh.wu@atmel.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/iio/adc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 90f596d..a80d236 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -110,6 +110,7 @@ config AD799X
 config AT91_ADC
 	tristate "Atmel AT91 ADC"
 	depends on ARCH_AT91
+	depends on INPUT
 	select IIO_BUFFER
 	select IIO_TRIGGERED_BUFFER
 	select SYSFS
-- 
1.8.3.2

Re: [PATCH 2/2] iio:adc: at91 requires the input subsystem

[Alexandre Belloni]

Hi,

On 08/05/2014 at 16:56:24 +0200, Arnd Bergmann wrote :
> Building the at91 adc driver with CONFIG_INPUT disabled results in this
> build error:
> 
> ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
> 
> To make sure we can build random configurations, this turns on CONFIG_INPUT
> whenever CONFIG_AT91_ADC is enabled.
> 

I'm wondering wether we should make part of the driver compile only if
CONFIG_INPUT is defined. Maybe some user will want to use the ADC and
not have any input on their board.

What do you think ?

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 2/2] iio:adc: at91 requires the input subsystem

[Lars-Peter Clausen]

On 05/08/2014 07:22 PM, Alexandre Belloni wrote:
> Hi,
>
> On 08/05/2014 at 16:56:24 +0200, Arnd Bergmann wrote :
>> Building the at91 adc driver with CONFIG_INPUT disabled results in this
>> build error:
>>
>> ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>
>> To make sure we can build random configurations, this turns on CONFIG_INPUT
>> whenever CONFIG_AT91_ADC is enabled.
>>
>
> I'm wondering wether we should make part of the driver compile only if
> CONFIG_INPUT is defined. Maybe some user will want to use the ADC and
> not have any input on their board.
>
> What do you think ?
>

This typically just leads to more build errors. E.g. if INPUT is defined as 
a module, but AT91_ADC is build in. I think it is very rare to see a 
configuration without INPUT set, other then a randconfig.

- Lars

Re: [PATCH 2/2] iio:adc: at91 requires the input subsystem

[Nicolas Ferre]

On 08/05/2014 16:56, Arnd Bergmann :
> Building the at91 adc driver with CONFIG_INPUT disabled results in this
> build error:
> 
> ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
> 
> To make sure we can build random configurations, this turns on CONFIG_INPUT
> whenever CONFIG_AT91_ADC is enabled.

Isn't it a "select" instead of "depends" that is required then?

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-iio@vger.kernel.org
> Cc: Josh Wu <josh.wu@atmel.com>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/iio/adc/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 90f596d..a80d236 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -110,6 +110,7 @@ config AD799X
>  config AT91_ADC
>  	tristate "Atmel AT91 ADC"
>  	depends on ARCH_AT91
> +	depends on INPUT
>  	select IIO_BUFFER
>  	select IIO_TRIGGERED_BUFFER
>  	select SYSFS
> 


-- 
Nicolas Ferre

[PATCH v2 2/2] iio:adc: at91 requires the input subsystem

[Arnd Bergmann]

On Friday 09 May 2014 12:01:48 Nicolas Ferre wrote:
> On 08/05/2014 16:56, Arnd Bergmann :
> > Building the at91 adc driver with CONFIG_INPUT disabled results in this
> > build error:
> > 
> > ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
> > ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
> > ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
> > ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
> > ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
> > ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
> > 
> > To make sure we can build random configurations, this turns on CONFIG_INPUT
> > whenever CONFIG_AT91_ADC is enabled.
> 
> Isn't it a "select" instead of "depends" that is required then?

It seems I fixed the patch at some point but didn't update the message.

In general, we should not mix 'depends on' and 'select' for the same symbol,
since that causes extra confusion.

In case of CONFIG_INPUT, almost all the users do 'depends on INPUT', with
a few exceptions that seem to be done in error.
Updated patch below.

	Arnd

8<----

>From 4679d63b24a681d9c6afcfdde266bae0f940e90b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 9 Apr 2014 17:18:10 +0200
Subject: [PATCH] [SUBMITTED] iio:adc: at91 requires the input subsystem

Building the at91 adc driver with CONFIG_INPUT disabled results in this
build error:

ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!

To make sure we can build random configurations, this adds a Kconfig
dependency on CONFIG_INPUT, as we do for other similar drivers.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-iio@vger.kernel.org
Cc: Josh Wu <josh.wu@atmel.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 90f596d..a80d236 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -110,6 +110,7 @@ config AD799X
 config AT91_ADC
 	tristate "Atmel AT91 ADC"
 	depends on ARCH_AT91
+	depends on INPUT
 	select IIO_BUFFER
 	select IIO_TRIGGERED_BUFFER
 	select SYSFS

Re: [PATCH v2 2/2] iio:adc: at91 requires the input subsystem

[Nicolas Ferre]

On 09/05/2014 13:43, Arnd Bergmann :
> On Friday 09 May 2014 12:01:48 Nicolas Ferre wrote:
>> On 08/05/2014 16:56, Arnd Bergmann :
>>> Building the at91 adc driver with CONFIG_INPUT disabled results in this
>>> build error:
>>>
>>> ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
>>> ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>> ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>> ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>> ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
>>> ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>>
>>> To make sure we can build random configurations, this turns on CONFIG_INPUT
>>> whenever CONFIG_AT91_ADC is enabled.
>>
>> Isn't it a "select" instead of "depends" that is required then?
> 
> It seems I fixed the patch at some point but didn't update the message.
> 
> In general, we should not mix 'depends on' and 'select' for the same symbol,
> since that causes extra confusion.
> 
> In case of CONFIG_INPUT, almost all the users do 'depends on INPUT', with
> a few exceptions that seem to be done in error.

Ok, that makes sense.


> Updated patch below.

Thanks Arnd.

> 	Arnd
> 
> 8<----
> 
>>From 4679d63b24a681d9c6afcfdde266bae0f940e90b Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Wed, 9 Apr 2014 17:18:10 +0200
> Subject: [PATCH] [SUBMITTED] iio:adc: at91 requires the input subsystem
> 
> Building the at91 adc driver with CONFIG_INPUT disabled results in this
> build error:
> 
> ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
> ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
> 
> To make sure we can build random configurations, this adds a Kconfig
> dependency on CONFIG_INPUT, as we do for other similar drivers.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-iio@vger.kernel.org
> Cc: Josh Wu <josh.wu@atmel.com>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>


Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Bye,

> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 90f596d..a80d236 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -110,6 +110,7 @@ config AD799X
>  config AT91_ADC
>  	tristate "Atmel AT91 ADC"
>  	depends on ARCH_AT91
> +	depends on INPUT
>  	select IIO_BUFFER
>  	select IIO_TRIGGERED_BUFFER
>  	select SYSFS
> 
> 
> 


-- 
Nicolas Ferre

Re: [PATCH v2 2/2] iio:adc: at91 requires the input subsystem

[Jonathan Cameron]

On 09/05/14 13:57, Nicolas Ferre wrote:
> On 09/05/2014 13:43, Arnd Bergmann :
>> On Friday 09 May 2014 12:01:48 Nicolas Ferre wrote:
>>> On 08/05/2014 16:56, Arnd Bergmann :
>>>> Building the at91 adc driver with CONFIG_INPUT disabled results in this
>>>> build error:
>>>>
>>>> ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
>>>> ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>>> ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>>> ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>>> ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
>>>> ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>>>
>>>> To make sure we can build random configurations, this turns on CONFIG_INPUT
>>>> whenever CONFIG_AT91_ADC is enabled.
>>>
>>> Isn't it a "select" instead of "depends" that is required then?
>>
>> It seems I fixed the patch at some point but didn't update the message.
>>
>> In general, we should not mix 'depends on' and 'select' for the same symbol,
>> since that causes extra confusion.
>>
>> In case of CONFIG_INPUT, almost all the users do 'depends on INPUT', with
>> a few exceptions that seem to be done in error.
>
> Ok, that makes sense.
>
>
>> Updated patch below.
>
> Thanks Arnd.
>
>> 	Arnd
>>
>> 8<----
>>
>> >From 4679d63b24a681d9c6afcfdde266bae0f940e90b Mon Sep 17 00:00:00 2001
>> From: Arnd Bergmann <arnd@arndb.de>
>> Date: Wed, 9 Apr 2014 17:18:10 +0200
>> Subject: [PATCH] [SUBMITTED] iio:adc: at91 requires the input subsystem
>>
>> Building the at91 adc driver with CONFIG_INPUT disabled results in this
>> build error:
>>
>> ERROR: "input_event" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_unregister_device" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_free_device" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_register_device" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_set_abs_params" [drivers/iio/adc/at91_adc.ko] undefined!
>> ERROR: "input_allocate_device" [drivers/iio/adc/at91_adc.ko] undefined!
>>
>> To make sure we can build random configurations, this adds a Kconfig
>> dependency on CONFIG_INPUT, as we do for other similar drivers.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: linux-iio@vger.kernel.org
>> Cc: Josh Wu <josh.wu@atmel.com>
>> Cc: Jonathan Cameron <jic23@kernel.org>
>> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
Applied to the togreg branch of iio.git.  Thanks,

Jonathan
> Bye,
>
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 90f596d..a80d236 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -110,6 +110,7 @@ config AD799X
>>   config AT91_ADC
>>   	tristate "Atmel AT91 ADC"
>>   	depends on ARCH_AT91
>> +	depends on INPUT
>>   	select IIO_BUFFER
>>   	select IIO_TRIGGERED_BUFFER
>>   	select SYSFS
>>
>>
>>
>
>

[PATCH] pci: rcar host needs OF

[Arnd Bergmann]

The pci-rcar driver is enabled for compile tests, and this has
now shown that the driver cannot build without CONFIG_OF,
following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF
interrupt mapping when possible":

drivers/built-in.o: In function `rcar_pci_map_irq':
:(.text+0x1cc7c): undefined reference to `of_irq_parse_and_map_pci'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Magnus Damm <damm@opensource.se>
Cc: linux-pci@vger.kernel.org
Cc: linux-sh@vger.kernel.org
---
 drivers/pci/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index fbbef0b..4675f47 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -27,7 +27,7 @@ config PCI_TEGRA
 
 config PCI_RCAR_GEN2
 	bool "Renesas R-Car Gen2 Internal PCI controller"
-	depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
+	depends on ARCH_SHMOBILE || (ARM && OF && COMPILE_TEST)
 	help
 	  Say Y here if you want internal PCI support on R-Car Gen2 SoC.
 	  There are 3 internal PCI controllers available with a single
-- 
1.8.3.2

Re: [PATCH] pci: rcar host needs OF

[Ben Dooks]

On 08/05/14 15:56, Arnd Bergmann wrote:
> The pci-rcar driver is enabled for compile tests, and this has
> now shown that the driver cannot build without CONFIG_OF,
> following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF
> interrupt mapping when possible":
>
> drivers/built-in.o: In function `rcar_pci_map_irq':
> :(.text+0x1cc7c): undefined reference to `of_irq_parse_and_map_pci'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Magnus Damm <damm@opensource.se>
> Cc: linux-pci@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> ---
>   drivers/pci/host/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index fbbef0b..4675f47 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -27,7 +27,7 @@ config PCI_TEGRA
>
>   config PCI_RCAR_GEN2
>   	bool "Renesas R-Car Gen2 Internal PCI controller"
> -	depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
> +	depends on ARCH_SHMOBILE || (ARM && OF && COMPILE_TEST)
>   	help
>   	  Say Y here if you want internal PCI support on R-Car Gen2 SoC.
>   	  There are 3 internal PCI controllers available with a single
>

This driver /should/ be able to be built for just the platform case
so it sounds like f8f2fe7355fb stopped this but no-one has yet to
notice.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: [PATCH] pci: rcar host needs OF

[Geert Uytterhoeven]

On Thu, May 8, 2014 at 5:06 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> On 08/05/14 15:56, Arnd Bergmann wrote:
>>
>> The pci-rcar driver is enabled for compile tests, and this has
>> now shown that the driver cannot build without CONFIG_OF,
>> following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF
>> interrupt mapping when possible":
>>
>> drivers/built-in.o: In function `rcar_pci_map_irq':
>> :(.text+0x1cc7c): undefined reference to `of_irq_parse_and_map_pci'
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>> Cc: Magnus Damm <damm@opensource.se>
>> Cc: linux-pci@vger.kernel.org
>> Cc: linux-sh@vger.kernel.org
>> ---
>>   drivers/pci/host/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index fbbef0b..4675f47 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -27,7 +27,7 @@ config PCI_TEGRA
>>
>>   config PCI_RCAR_GEN2
>>         bool "Renesas R-Car Gen2 Internal PCI controller"
>> -       depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
>> +       depends on ARCH_SHMOBILE || (ARM && OF && COMPILE_TEST)
>>         help
>>           Say Y here if you want internal PCI support on R-Car Gen2 SoC.
>>           There are 3 internal PCI controllers available with a single
>>
>
> This driver /should/ be able to be built for just the platform case
> so it sounds like f8f2fe7355fb stopped this but no-one has yet to
> notice.

You mean include/linux/of_pci.h should provide a dummy version of
of_irq_parse_and_map_pci() returning 0 in case OF=n?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] pci: rcar host needs OF

[Arnd Bergmann]

On Thursday 08 May 2014 17:16:32 Geert Uytterhoeven wrote:
> On Thu, May 8, 2014 at 5:06 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> > On 08/05/14 15:56, Arnd Bergmann wrote:
> >>
> >> The pci-rcar driver is enabled for compile tests, and this has
> >> now shown that the driver cannot build without CONFIG_OF,
> >> following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF
> >> interrupt mapping when possible":
> >>
> >> drivers/built-in.o: In function `rcar_pci_map_irq':
> >> :(.text+0x1cc7c): undefined reference to `of_irq_parse_and_map_pci'
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> Cc: Bjorn Helgaas <bhelgaas@google.com>
> >> Cc: Magnus Damm <damm@opensource.se>
> >> Cc: linux-pci@vger.kernel.org
> >> Cc: linux-sh@vger.kernel.org
> >> ---
> >>   drivers/pci/host/Kconfig | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> >> index fbbef0b..4675f47 100644
> >> --- a/drivers/pci/host/Kconfig
> >> +++ b/drivers/pci/host/Kconfig
> >> @@ -27,7 +27,7 @@ config PCI_TEGRA
> >>
> >>   config PCI_RCAR_GEN2
> >>         bool "Renesas R-Car Gen2 Internal PCI controller"
> >> -       depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
> >> +       depends on ARCH_SHMOBILE || (ARM && OF && COMPILE_TEST)
> >>         help
> >>           Say Y here if you want internal PCI support on R-Car Gen2 SoC.
> >>           There are 3 internal PCI controllers available with a single
> >>
> >
> > This driver /should/ be able to be built for just the platform case
> > so it sounds like f8f2fe7355fb stopped this but no-one has yet to
> > notice.
> 
> You mean include/linux/of_pci.h should provide a dummy version of
> of_irq_parse_and_map_pci() returning 0 in case OF=n?

Good idea, I'll give this patch some testing in the randconfig builder,
replacing the one above.

	Arnd

diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 1a1f5ff..b6f2621 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -7,7 +7,6 @@
 struct pci_dev;
 struct of_phandle_args;
 int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq);
-int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 
 struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -19,11 +18,14 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_pci_msi_chip_add(struct msi_chip *chip);
 void of_pci_msi_chip_remove(struct msi_chip *chip);
 struct msi_chip *of_pci_find_msi_chip_by_node(struct device_node *of_node);
+int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 #else
 static inline int of_pci_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
 static inline void of_pci_msi_chip_remove(struct msi_chip *chip) { }
 static inline struct msi_chip *
 of_pci_find_msi_chip_by_node(struct device_node *of_node) { return NULL; }
+static inline int
+of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin) { return 0; }
 #endif
 
 #endif

Re: [PATCH] pci: rcar host needs OF

[Arnd Bergmann]

On Thursday 08 May 2014 17:21:54 Arnd Bergmann wrote:
> On Thursday 08 May 2014 17:16:32 Geert Uytterhoeven wrote:
> > On Thu, May 8, 2014 at 5:06 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> > >> @@ -27,7 +27,7 @@ config PCI_TEGRA
> > >>
> > >>   config PCI_RCAR_GEN2
> > >>         bool "Renesas R-Car Gen2 Internal PCI controller"
> > >> -       depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
> > >> +       depends on ARCH_SHMOBILE || (ARM && OF && COMPILE_TEST)
> > >>         help
> > >>           Say Y here if you want internal PCI support on R-Car Gen2 SoC.
> > >>           There are 3 internal PCI controllers available with a single
> > >>
> > >
> > > This driver /should/ be able to be built for just the platform case
> > > so it sounds like f8f2fe7355fb stopped this but no-one has yet to
> > > notice.
> > 
> > You mean include/linux/of_pci.h should provide a dummy version of
> > of_irq_parse_and_map_pci() returning 0 in case OF=n?
> 
> Good idea, I'll give this patch some testing in the randconfig builder,
> replacing the one above.

The first version was flawed, I submitted a new patch "[PATCH] of/irq:
provide int of_irq_parse_and_map_pci wrapper" now.

	Arnd

Re: [PATCH] pci: rcar host needs OF

[Bjorn Helgaas]

On Thu, May 08, 2014 at 04:56:25PM +0200, Arnd Bergmann wrote:
> The pci-rcar driver is enabled for compile tests, and this has
> now shown that the driver cannot build without CONFIG_OF,
> following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF
> interrupt mapping when possible":
> 
> drivers/built-in.o: In function `rcar_pci_map_irq':
> :(.text+0x1cc7c): undefined reference to `of_irq_parse_and_map_pci'
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Magnus Damm <damm@opensource.se>
> Cc: linux-pci@vger.kernel.org
> Cc: linux-sh@vger.kernel.org

If I understand correctly, this patch was superceded by this one:

    "[PATCH] of/irq: provide int of_irq_parse_and_map_pci wrapper"

and you aren't expecting me to do anything.  Let me know if otherwise.

> ---
>  drivers/pci/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index fbbef0b..4675f47 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -27,7 +27,7 @@ config PCI_TEGRA
>  
>  config PCI_RCAR_GEN2
>  	bool "Renesas R-Car Gen2 Internal PCI controller"
> -	depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
> +	depends on ARCH_SHMOBILE || (ARM && OF && COMPILE_TEST)
>  	help
>  	  Say Y here if you want internal PCI support on R-Car Gen2 SoC.
>  	  There are 3 internal PCI controllers available with a single
> -- 
> 1.8.3.2
> 

Re: [PATCH] pci: rcar host needs OF

[Jingoo Han]

On Wednesday, May 28, 2014 7:54 AM, Bjorn Helgaas wrote:
> On Thu, May 08, 2014 at 04:56:25PM +0200, Arnd Bergmann wrote:
> > The pci-rcar driver is enabled for compile tests, and this has
> > now shown that the driver cannot build without CONFIG_OF,
> > following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF
> > interrupt mapping when possible":
> >
> > drivers/built-in.o: In function `rcar_pci_map_irq':
> > :(.text+0x1cc7c): undefined reference to `of_irq_parse_and_map_pci'
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Magnus Damm <damm@opensource.se>
> > Cc: linux-pci@vger.kernel.org
> > Cc: linux-sh@vger.kernel.org
> 
> If I understand correctly, this patch was superceded by this one:
> 
>     "[PATCH] of/irq: provide int of_irq_parse_and_map_pci wrapper"
> 
> and you aren't expecting me to do anything.  Let me know if otherwise.

Yes, right. I checked that the build error was resolved by the above
mentioned patch.

Best regards,
Jingoo Han

> 
> > ---
> >  drivers/pci/host/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > index fbbef0b..4675f47 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -27,7 +27,7 @@ config PCI_TEGRA
> >
> >  config PCI_RCAR_GEN2
> >  	bool "Renesas R-Car Gen2 Internal PCI controller"
> > -	depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
> > +	depends on ARCH_SHMOBILE || (ARM && OF && COMPILE_TEST)
> >  	help
> >  	  Say Y here if you want internal PCI support on R-Car Gen2 SoC.
> >  	  There are 3 internal PCI controllers available with a single
> > --
> > 1.8.3.2
> >

[PATCH 1/2] input: fix ps2/serio module dependency

[Arnd Bergmann]

The ps2 mouse and keyboard drivers use the "serio" framework that
they correctly select in Kconfig, and that in turn depends on the
i8042 driver, which is also allowed to be disabled for architectures
that don't have an i8042.

However, Kconfig also allows i8042 to be built as a module while
the serio framework is built-in, which causes this link error:

drivers/built-in.o: In function `ps2_begin_command':
:(.text+0x26b6cc): undefined reference to `i8042_check_port_owner'
:(.text+0x26b6d4): undefined reference to `i8042_lock_chip'
drivers/built-in.o: In function `ps2_end_command':
:(.text+0x26b734): undefined reference to `i8042_check_port_owner'
:(.text+0x26b73c): undefined reference to `i8042_unlock_chip'

On x86, a specific 'select SERIO_I8042' takes care of it, but
not on the other architecture that potentially have a u8042.

This patch changes the Kconfig logic to ensure that whenever
there is an i8042, it does get used for the serio driver, avoiding
the link error above.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
---
 drivers/input/keyboard/Kconfig | 2 +-
 drivers/input/mouse/Kconfig    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4f115db..dd2435a 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
 	default y
 	select SERIO
 	select SERIO_LIBPS2
-	select SERIO_I8042 if X86
+	select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
 	select SERIO_GSCPS2 if GSC
 	help
 	  Say Y here if you want to use a standard AT or PS/2 keyboard. Usually
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index effa9c5..cf534ee 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -17,7 +17,7 @@ config MOUSE_PS2
 	default y
 	select SERIO
 	select SERIO_LIBPS2
-	select SERIO_I8042 if X86
+	select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
 	select SERIO_GSCPS2 if GSC
 	help
 	  Say Y here if you have a PS/2 mouse connected to your system. This
-- 
1.8.3.2

Re: [PATCH 1/2] input: fix ps2/serio module dependency

[Dmitry Torokhov]

Hi Arnd,

On Thu, May 08, 2014 at 04:56:26PM +0200, Arnd Bergmann wrote:
> @@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
>  	default y
>  	select SERIO
>  	select SERIO_LIBPS2
> -	select SERIO_I8042 if X86
> +	select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO

x86 also selects ARCH_MIGHT_HAVE_PC_SERIO so shouldn't this be

	select SERIO_I8042 if ARCH_MIGHT_HAVE_PC_SERIO

?

I can fix it up on my side if you agree.

Thanks.

-- 
Dmitry

Re: [PATCH 1/2] input: fix ps2/serio module dependency

[Arnd Bergmann]

On Thursday 08 May 2014 08:59:31 Dmitry Torokhov wrote:
> Hi Arnd,
> 
> On Thu, May 08, 2014 at 04:56:26PM +0200, Arnd Bergmann wrote:
> > @@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
> >       default y
> >       select SERIO
> >       select SERIO_LIBPS2
> > -     select SERIO_I8042 if X86
> > +     select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
> 
> x86 also selects ARCH_MIGHT_HAVE_PC_SERIO so shouldn't this be
> 
>         select SERIO_I8042 if ARCH_MIGHT_HAVE_PC_SERIO
> 
> ?
> 
> I can fix it up on my side if you agree.

Yes, sounds good, thanks!

	Arnd

[PATCH 2/2] input: atmel-wm97xx: only build for AVR32

[Arnd Bergmann]

Building this driver on ARM/at91 always gives us this error message:

drivers/input/touchscreen/atmel-wm97xx.c:63:2: error: #error Unknown CPU, this driver only supports AT32AP700X CPUs.

Clearly this configuration is not meant to work, so let's just prevent
it in Kconfig. If we ever want to use it on another platform, we should
also pass proper resources for GPIO, IRQ and memory, which are hardcoded
to AT32AP700X at the moment.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
---
 drivers/input/touchscreen/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index e2f0264..fe4c264 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -640,7 +640,7 @@ config TOUCHSCREEN_WM9713
 
 config TOUCHSCREEN_WM97XX_ATMEL
 	tristate "WM97xx Atmel accelerated touch"
-	depends on TOUCHSCREEN_WM97XX && (AVR32 || ARCH_AT91)
+	depends on TOUCHSCREEN_WM97XX && AVR32
 	help
 	  Say Y here for support for streaming mode with WM97xx touchscreens
 	  on Atmel AT91 or AVR32 systems with an AC97C module.
-- 
1.8.3.2

Re: [PATCH 2/2] input: atmel-wm97xx: only build for AVR32

[Nicolas Ferre]

On 08/05/2014 16:56, Arnd Bergmann :
> Building this driver on ARM/at91 always gives us this error message:
> 
> drivers/input/touchscreen/atmel-wm97xx.c:63:2: error: #error Unknown CPU, this driver only supports AT32AP700X CPUs.
> 
> Clearly this configuration is not meant to work, so let's just prevent
> it in Kconfig. If we ever want to use it on another platform, we should
> also pass proper resources for GPIO, IRQ and memory, which are hardcoded
> to AT32AP700X at the moment.

Yes it seems so:

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Liam Girdwood <lrg@slimlogic.co.uk>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input@vger.kernel.org
> ---
>  drivers/input/touchscreen/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index e2f0264..fe4c264 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -640,7 +640,7 @@ config TOUCHSCREEN_WM9713
>  
>  config TOUCHSCREEN_WM97XX_ATMEL
>  	tristate "WM97xx Atmel accelerated touch"
> -	depends on TOUCHSCREEN_WM97XX && (AVR32 || ARCH_AT91)
> +	depends on TOUCHSCREEN_WM97XX && AVR32
>  	help
>  	  Say Y here for support for streaming mode with WM97xx touchscreens
>  	  on Atmel AT91 or AVR32 systems with an AC97C module.
> 


-- 
Nicolas Ferre

[PATCH] misc: atmel_pwm: only build for supported platforms

[Arnd Bergmann]

There is architecture code in mach-at91 that depends on the
CONFIG_ATMEL_PWM symbol in order to call the soc-specific
at91_add_device_pwm function. While all of this is about code
that will be removed in the future, using DT probing and
the PWM framework, we currently get a build failure:

arch/arm/mach-at91/built-in.o: In function `at91_pwm_leds':
arch/arm/mach-at91/leds.c:88: undefined reference to `at91_add_device_pwm'

This patch ensures we only try to build this driver on
platforms on which it will build and work.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/misc/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fe2230c..ce29342 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -53,7 +53,8 @@ config AD525X_DPOT_SPI
 
 config ATMEL_PWM
 	tristate "Atmel AT32/AT91 PWM support"
-	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
+	depends on HAVE_CLK
+	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
 	help
 	  This option enables device driver support for the PWM channels
 	  on certain Atmel processors.  Pulse Width Modulation is used for
-- 
1.8.3.2

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Nicolas Ferre]

On 08/05/2014 16:56, Arnd Bergmann :
> There is architecture code in mach-at91 that depends on the
> CONFIG_ATMEL_PWM symbol in order to call the soc-specific
> at91_add_device_pwm function. While all of this is about code
> that will be removed in the future, using DT probing and
> the PWM framework, we currently get a build failure:
> 
> arch/arm/mach-at91/built-in.o: In function `at91_pwm_leds':
> arch/arm/mach-at91/leds.c:88: undefined reference to `at91_add_device_pwm'
> 
> This patch ensures we only try to build this driver on
> platforms on which it will build and work.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Thanks,

> ---
>  drivers/misc/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index fe2230c..ce29342 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -53,7 +53,8 @@ config AD525X_DPOT_SPI
>  
>  config ATMEL_PWM
>  	tristate "Atmel AT32/AT91 PWM support"
> -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> +	depends on HAVE_CLK
> +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
>  	help
>  	  This option enables device driver support for the PWM channels
>  	  on certain Atmel processors.  Pulse Width Modulation is used for
> 


-- 
Nicolas Ferre

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Paul Bolle]

On Fri, 2014-05-09 at 12:03 +0200, Nicolas Ferre wrote:
> On 08/05/2014 16:56, Arnd Bergmann :
> > There is architecture code in mach-at91 that depends on the
> > CONFIG_ATMEL_PWM symbol in order to call the soc-specific
> > at91_add_device_pwm function. While all of this is about code
> > that will be removed in the future, using DT probing and
> > the PWM framework, we currently get a build failure:
> > 
> > arch/arm/mach-at91/built-in.o: In function `at91_pwm_leds':
> > arch/arm/mach-at91/leds.c:88: undefined reference to `at91_add_device_pwm'
> > 
> > This patch ensures we only try to build this driver on
> > platforms on which it will build and work.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

It seems this one just landed in linux-next (in next-20140528).

> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index fe2230c..ce29342 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -53,7 +53,8 @@ config AD525X_DPOT_SPI
> >  
> >  config ATMEL_PWM
> >  	tristate "Atmel AT32/AT91 PWM support"
> > -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> > +	depends on HAVE_CLK
> > +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45

Symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not seem to exist in
next-20140528. Should these perhaps be SOC_AT91SAM9263, SOC_AT91SAM9RL,
and SOC_AT91SAM9G45 and/or ARCH_AT91SAM9263, ARCH_AT91SAM9RL, and
ARCH_AT91SAM9G45?

> >  	help
> >  	  This option enables device driver support for the PWM channels
> >  	  on certain Atmel processors.  Pulse Width Modulation is used for
> > 


Paul Bolle

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Alexandre Belloni]

Hi,

On 28/05/2014 at 14:24:27 +0200, Paul Bolle wrote :
> > >  config ATMEL_PWM
> > >  	tristate "Atmel AT32/AT91 PWM support"
> > > -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> > > +	depends on HAVE_CLK
> > > +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
> 
> Symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not seem to exist in
> next-20140528. Should these perhaps be SOC_AT91SAM9263, SOC_AT91SAM9RL,
> and SOC_AT91SAM9G45 and/or ARCH_AT91SAM9263, ARCH_AT91SAM9RL, and
> ARCH_AT91SAM9G45?
> 

I wouldn't bother too much fixing that, this will definitely be remove
in 3.17. I was too late for 3.16 because my series was waiting on
another patch set.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Paul Bolle]

On Wed, 2014-05-28 at 17:59 +0200, Alexandre Belloni wrote:
> On 28/05/2014 at 14:24:27 +0200, Paul Bolle wrote :
> > > >  config ATMEL_PWM
> > > >  	tristate "Atmel AT32/AT91 PWM support"
> > > > -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> > > > +	depends on HAVE_CLK
> > > > +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
> > 
> > Symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not seem to exist in
> > next-20140528. Should these perhaps be SOC_AT91SAM9263, SOC_AT91SAM9RL,
> > and SOC_AT91SAM9G45 and/or ARCH_AT91SAM9263, ARCH_AT91SAM9RL, and
> > ARCH_AT91SAM9G45?
> 
> I wouldn't bother too much fixing that, this will definitely be remove
> in 3.17. 

Are you talking about: 1) the problem this patch tried to fix; or 2) the
problem it created?

> I was too late for 3.16 because my series was waiting on
> another patch set.

We're already too late to fix stuff for v3.16-rc1 (which will probably
only be released about three to four weeks from now)? Is that correct?


Paul Bolle

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Alexandre Belloni]

On 28/05/2014 at 18:09:43 +0200, Paul Bolle wrote :
> On Wed, 2014-05-28 at 17:59 +0200, Alexandre Belloni wrote:
> > On 28/05/2014 at 14:24:27 +0200, Paul Bolle wrote :
> > > > >  config ATMEL_PWM
> > > > >  	tristate "Atmel AT32/AT91 PWM support"
> > > > > -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> > > > > +	depends on HAVE_CLK
> > > > > +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
> > > 
> > > Symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not seem to exist in
> > > next-20140528. Should these perhaps be SOC_AT91SAM9263, SOC_AT91SAM9RL,
> > > and SOC_AT91SAM9G45 and/or ARCH_AT91SAM9263, ARCH_AT91SAM9RL, and
> > > ARCH_AT91SAM9G45?
> > 
> > I wouldn't bother too much fixing that, this will definitely be remove
> > in 3.17. 
> 
> Are you talking about: 1) the problem this patch tried to fix; or 2) the
> problem it created?
> 

I'm removing the whole atmel_pwm driver so the CONFIG_ATMEL_PWM symbol
will be gone.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Paul Bolle]

On Wed, 2014-05-28 at 19:55 +0200, Alexandre Belloni wrote:
> On 28/05/2014 at 18:09:43 +0200, Paul Bolle wrote :
> > On Wed, 2014-05-28 at 17:59 +0200, Alexandre Belloni wrote:
> > > On 28/05/2014 at 14:24:27 +0200, Paul Bolle wrote :
> > > > > >  config ATMEL_PWM
> > > > > >  	tristate "Atmel AT32/AT91 PWM support"
> > > > > > -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> > > > > > +	depends on HAVE_CLK
> > > > > > +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
> > > > 
> > > > Symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not seem to exist in
> > > > next-20140528. Should these perhaps be SOC_AT91SAM9263, SOC_AT91SAM9RL,
> > > > and SOC_AT91SAM9G45 and/or ARCH_AT91SAM9263, ARCH_AT91SAM9RL, and
> > > > ARCH_AT91SAM9G45?
> > > 
> > > I wouldn't bother too much fixing that, this will definitely be remove
> > > in 3.17. 
> > 
> > Are you talking about: 1) the problem this patch tried to fix; or 2) the
> > problem it created?
> > 
> 
> I'm removing the whole atmel_pwm driver so the CONFIG_ATMEL_PWM symbol
> will be gone.

So the patch we're discussing here will never be included in a release?


Paul Bolle

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Greg Kroah-Hartman]

On Wed, May 28, 2014 at 07:59:08PM +0200, Paul Bolle wrote:
> On Wed, 2014-05-28 at 19:55 +0200, Alexandre Belloni wrote:
> > On 28/05/2014 at 18:09:43 +0200, Paul Bolle wrote :
> > > On Wed, 2014-05-28 at 17:59 +0200, Alexandre Belloni wrote:
> > > > On 28/05/2014 at 14:24:27 +0200, Paul Bolle wrote :
> > > > > > >  config ATMEL_PWM
> > > > > > >  	tristate "Atmel AT32/AT91 PWM support"
> > > > > > > -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> > > > > > > +	depends on HAVE_CLK
> > > > > > > +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
> > > > > 
> > > > > Symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not seem to exist in
> > > > > next-20140528. Should these perhaps be SOC_AT91SAM9263, SOC_AT91SAM9RL,
> > > > > and SOC_AT91SAM9G45 and/or ARCH_AT91SAM9263, ARCH_AT91SAM9RL, and
> > > > > ARCH_AT91SAM9G45?
> > > > 
> > > > I wouldn't bother too much fixing that, this will definitely be remove
> > > > in 3.17. 
> > > 
> > > Are you talking about: 1) the problem this patch tried to fix; or 2) the
> > > problem it created?
> > > 
> > 
> > I'm removing the whole atmel_pwm driver so the CONFIG_ATMEL_PWM symbol
> > will be gone.
> 
> So the patch we're discussing here will never be included in a release?

So, should I just remove it right now?  I like deleting files :)

thanks,

greg k-h

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Alexandre Belloni]

On 28/05/2014 at 11:42:17 -0700, Greg Kroah-Hartman wrote :
> On Wed, May 28, 2014 at 07:59:08PM +0200, Paul Bolle wrote:
> > So the patch we're discussing here will never be included in a release?
> 

As it hit linux-next, I guess it will be in 3.16

> So, should I just remove it right now?  I like deleting files :)
> 

I also like doing that, let me resend my series, rebased on linux-next
because of the dependency on the PWM tree. Then I will let you and
Nicolas decide what you want to do with it.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Paul Bolle]

Greg,

On Wed, 2014-05-28 at 11:42 -0700, Greg Kroah-Hartman wrote:
> On Wed, May 28, 2014 at 07:59:08PM +0200, Paul Bolle wrote:
> > On Wed, 2014-05-28 at 19:55 +0200, Alexandre Belloni wrote:
> > > On 28/05/2014 at 18:09:43 +0200, Paul Bolle wrote :
> > > > On Wed, 2014-05-28 at 17:59 +0200, Alexandre Belloni wrote:
> > > > > On 28/05/2014 at 14:24:27 +0200, Paul Bolle wrote :
> > > > > > > >  config ATMEL_PWM
> > > > > > > >  	tristate "Atmel AT32/AT91 PWM support"
> > > > > > > > -	depends on HAVE_CLK && (AVR32 || ARCH_AT91 || COMPILE_TEST)
> > > > > > > > +	depends on HAVE_CLK
> > > > > > > > +	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
> > > > > > 
> > > > > > Symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not seem to exist in
> > > > > > next-20140528. Should these perhaps be SOC_AT91SAM9263, SOC_AT91SAM9RL,
> > > > > > and SOC_AT91SAM9G45 and/or ARCH_AT91SAM9263, ARCH_AT91SAM9RL, and
> > > > > > ARCH_AT91SAM9G45?
> > > > > 
> > > > > I wouldn't bother too much fixing that, this will definitely be remove
> > > > > in 3.17. 
> > > > 
> > > > Are you talking about: 1) the problem this patch tried to fix; or 2) the
> > > > problem it created?
> > > > 
> > > 
> > > I'm removing the whole atmel_pwm driver so the CONFIG_ATMEL_PWM symbol
> > > will be gone.
> > 
> > So the patch we're discussing here will never be included in a release?
> 
> So, should I just remove it right now?  I like deleting files :)

This has landed unchanged in v3.16-rc1. Should I submit the trivial
patch to remove these pointless references to the unknown symbols
AT91SAM9263, AT91SAM9RL, and AT91SAM9G45?

Thanks,


Paul Bolle

Re: [PATCH] misc: atmel_pwm: only build for supported platforms

[Alexandre Belloni]

Hi,

On 18/06/2014 at 11:19:30 +0200, Paul Bolle wrote :
> This has landed unchanged in v3.16-rc1. Should I submit the trivial
> patch to remove these pointless references to the unknown symbols
> AT91SAM9263, AT91SAM9RL, and AT91SAM9G45?
> 

Because of dependencies, the pull request was delayed until after
3.16-rc1. It has been resent and this should be solved for 3.16-rc2:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/264181.html

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH] misc: atmel_pwm: fix Kconfig symbols

[Nicolas Ferre]

AT91 symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not exist and this
patch change them their correct ARCH_* version.
These symbols are chosen instead of the SOC_* one because this driver is not
converted to DT.
Anyway, the ATMEL_PWM symbol and the associated driver will be removed soon
during the move to the PWM sub-system.

Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
Guys,

The rework is delayed to 3.17. So, in the meantime, I send this little patch
as a fix for 3.16.

Bye,

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

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a43d0c467274..ee9402324a23 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -54,7 +54,7 @@ config AD525X_DPOT_SPI
 config ATMEL_PWM
 	tristate "Atmel AT32/AT91 PWM support"
 	depends on HAVE_CLK
-	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
+	depends on AVR32 || ARCH_AT91SAM9263 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45
 	help
 	  This option enables device driver support for the PWM channels
 	  on certain Atmel processors.  Pulse Width Modulation is used for
-- 
1.8.2.2

Re: [PATCH] misc: atmel_pwm: fix Kconfig symbols

[Alexandre Belloni]

On 25/06/2014 at 11:43:56 +0200, Nicolas Ferre wrote :
> AT91 symbols AT91SAM9263, AT91SAM9RL, and AT91SAM9G45 do not exist and this
> patch change them their correct ARCH_* version.
> These symbols are chosen instead of the SOC_* one because this driver is not
> converted to DT.
> Anyway, the ATMEL_PWM symbol and the associated driver will be removed soon
> during the move to the PWM sub-system.
> 
> Reported-by: Paul Bolle <pebolle@tiscali.nl>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

> ---
> Guys,
> 
> The rework is delayed to 3.17. So, in the meantime, I send this little patch
> as a fix for 3.16.
> 
> Bye,
> 
>  drivers/misc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index a43d0c467274..ee9402324a23 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -54,7 +54,7 @@ config AD525X_DPOT_SPI
>  config ATMEL_PWM
>  	tristate "Atmel AT32/AT91 PWM support"
>  	depends on HAVE_CLK
> -	depends on AVR32 || AT91SAM9263 || AT91SAM9RL || AT91SAM9G45
> +	depends on AVR32 || ARCH_AT91SAM9263 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45
>  	help
>  	  This option enables device driver support for the PWM channels
>  	  on certain Atmel processors.  Pulse Width Modulation is used for
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH] remoteproc: da8xx: don't select CMA on no-MMU

[Arnd Bergmann]

We can only use CMA on systems that have an MMU, because of
the requirement to use memory migration. NOMMU systems are
rather constrained to start with, but it seems reasonable
to assume that DMA allocations can still succeed in the
constrained case for remoteproc on NOMMU, so this patch
changes the da8xx implementation to not rely on CMA when
the MMU is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Robert Tivy <rtivy@ti.com>
---
 drivers/remoteproc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index ce1743d..5e343ba 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -44,7 +44,7 @@ config STE_MODEM_RPROC
 config DA8XX_REMOTEPROC
 	tristate "DA8xx/OMAP-L13x remoteproc support"
 	depends on ARCH_DAVINCI_DA8XX
-	select CMA
+	select CMA if MMU
 	select REMOTEPROC
 	select RPMSG
 	help
-- 
1.8.3.2

Re: [PATCH] remoteproc: da8xx: don't select CMA on no-MMU

[Ohad Ben-Cohen]

Hi Arnd,

On Thu, May 8, 2014 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> We can only use CMA on systems that have an MMU, because of
> the requirement to use memory migration. NOMMU systems are
> rather constrained to start with, but it seems reasonable
> to assume that DMA allocations can still succeed in the
> constrained case for remoteproc on NOMMU, so this patch
> changes the da8xx implementation to not rely on CMA when
> the MMU is disabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Robert Tivy <rtivy@ti.com>
> ---

Would you like me to pick this via the remoteproc tree or are you
planning to route this set elsewhere anyway?

Thanks,
Ohad.

Re: [PATCH] remoteproc: da8xx: don't select CMA on no-MMU

[Arnd Bergmann]

On Monday 12 May 2014 16:09:56 Ohad Ben-Cohen wrote:
> 
> On Thu, May 8, 2014 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > We can only use CMA on systems that have an MMU, because of
> > the requirement to use memory migration. NOMMU systems are
> > rather constrained to start with, but it seems reasonable
> > to assume that DMA allocations can still succeed in the
> > constrained case for remoteproc on NOMMU, so this patch
> > changes the da8xx implementation to not rely on CMA when
> > the MMU is disabled.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Ohad Ben-Cohen <ohad@wizery.com>
> > Cc: Robert Tivy <rtivy@ti.com>
> > ---
> 
> Would you like me to pick this via the remoteproc tree or are you
> planning to route this set elsewhere anyway?

I'd prefer if you could pick it up into your tree.

	Arnd

Re: [PATCH] remoteproc: da8xx: don't select CMA on no-MMU

[Ohad Ben-Cohen]

On Mon, May 12, 2014 at 9:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> I'd prefer if you could pick it up into your tree.

Sure thing.

Thanks,
Ohad.

[PATCH] regulator: arizona-ldo1: add missing #include

[Arnd Bergmann]

commit 2cce4be9e6b8 "regulator: arizona-ldo1: Add processing of init_data
from device tree" added a call to of_get_child_by_name() but
did not add an #include to the header file declaring that function.

I got a build error when doing randconfig testing on this, which
is fixed by this patch to include of.h.

drivers/regulator/arizona-ldo1.c:192:2: error: implicit declaration of function 'of_get_child_by_name' [-Werror=implicit-function-declaration]
drivers/regulator/arizona-ldo1.c:193:2: error: implicit declaration of function 'of_parse_phandle' [-Werror=implicit-function-declaration]
drivers/regulator/arizona-ldo1.c:213:2: error: implicit declaration of function 'of_node_put' [-Werror=implicit-function-declaration]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: Mark Brown <broonie@linaro.org>
---
 drivers/regulator/arizona-ldo1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index d3787e1..04f262a 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 #include <linux/bitops.h>
 #include <linux/err.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
-- 
1.8.3.2

Re: [PATCH] regulator: arizona-ldo1: add missing #include

[Charles Keepax]

On Thu, May 08, 2014 at 04:56:30PM +0200, Arnd Bergmann wrote:
> commit 2cce4be9e6b8 "regulator: arizona-ldo1: Add processing of init_data
> from device tree" added a call to of_get_child_by_name() but
> did not add an #include to the header file declaring that function.
> 
> I got a build error when doing randconfig testing on this, which
> is fixed by this patch to include of.h.
> 
> drivers/regulator/arizona-ldo1.c:192:2: error: implicit declaration of function 'of_get_child_by_name' [-Werror=implicit-function-declaration]
> drivers/regulator/arizona-ldo1.c:193:2: error: implicit declaration of function 'of_parse_phandle' [-Werror=implicit-function-declaration]
> drivers/regulator/arizona-ldo1.c:213:2: error: implicit declaration of function 'of_node_put' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> Cc: Mark Brown <broonie@linaro.org>
> ---

Thanks, yeah seems that is getting implicitly through another
header included in my config. Will need a similar fix for
arizona-micsupp, I will get one out for that.

Reviewed-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>

Thanks,
Charles

Re: [PATCH 1/2] dmaengine: omap: hide filter_fn for built-in drivers

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140508 07:57]:
> It is not possible to reference the omap_dma_filter_fn filter
> function from a built-in driver if the dmaengine driver itself
> is a loadable module, which is a valid configuration otherwise.
> 
> This provides only the dummy alternative if the function
> is referenced by a built-in driver to allow a successful
> build. The filter function is only required by ATAGS based
> platforms, which will continue to be broken after this change
> for the bogus configuration. When booting from DT, with the
> dma channels correctly listed there, it will work fine.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: dmaengine@vger.kernel.org

Re: [PATCH 1/2] dmaengine: omap: hide filter_fn for built-in drivers

[Vinod Koul]

On Thu, May 08, 2014 at 04:56:12PM +0200, Arnd Bergmann wrote:
> It is not possible to reference the omap_dma_filter_fn filter
> function from a built-in driver if the dmaengine driver itself
> is a loadable module, which is a valid configuration otherwise.
> 
> This provides only the dummy alternative if the function
> is referenced by a built-in driver to allow a successful
> build. The filter function is only required by ATAGS based
> platforms, which will continue to be broken after this change
> for the bogus configuration. When booting from DT, with the
> dma channels correctly listed there, it will work fine.

Applied, both thanks

-- 
~Vinod

Re: [PATCH 00/22] Random ARM randconfig fixes in drivers

[Guenter Roeck]

On Thu, May 08, 2014 at 04:46:51PM +0200, Arnd Bergmann wrote:
> These are a bunch of fixes I had to do to get all randconfig
> configurations on ARM working. Most of these are really old
> bugs, but there are also some new ones. I don't think any of
> them require a backport to linux-stable.
> 
> I have checked that they are all still required on yesterday's
> linux-next kernel. Please apply on the appropriate trees unless
> there are objections.
> 
Is this series of patches also going to fix arm:allmodconfig ?

Thanks,
Guenter

Re: [PATCH 00/22] Random ARM randconfig fixes in drivers

[Arnd Bergmann]

On Thursday 08 May 2014, Guenter Roeck wrote:
> On Thu, May 08, 2014 at 04:46:51PM +0200, Arnd Bergmann wrote:
> > These are a bunch of fixes I had to do to get all randconfig
> > configurations on ARM working. Most of these are really old
> > bugs, but there are also some new ones. I don't think any of
> > them require a backport to linux-stable.
> > 
> > I have checked that they are all still required on yesterday's
> > linux-next kernel. Please apply on the appropriate trees unless
> > there are objections.
> > 
> Is this series of patches also going to fix arm:allmodconfig ?

Possibly, I haven't checked in a while. I'm unfortunately sitting on
about 200 other patches in the same branch, which together fix all
build errors in any configuration I encountered.

I should really do some allmodconfig/allnoconfig/allyesconfig
builds without my series again, and prioritize sending out the
ones required for that.

	Arnd