[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] 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 --]

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