[PATCH, RFC 00/22] ARM randconfig bugs

[PATCH, RFC 00/22] ARM randconfig bugs

[Arnd Bergmann]

Hi subsystem maintainers,

This is a set of patches to to fix build errors I hit while trying to
build lots of randconfig kernels on linux-next.

Most of them are simple missing dependencies in Kconfig, but some are
more substantial. I would like to see at least the obvious patches
get merged for 3.10. If you are happy with the patches, feel free
to apply them directly, otherwise please provide feedback.

No single patch out of these is very important though, most of them
only concern corner cases and don't matter in practice.

	Arnd

Arnd Bergmann (22):
  can: move CONFIG_HAVE_CAN_FLEXCAN out of CAN_DEV
  cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY
  cpuidle: calxeda: select ARM_CPU_SUSPEND
  staging/drm: imx: add missing dependencies
  drm: always provide debugfs function prototypes
  gpu/drm: host1x: add dependency on Tegra
  drm/tilcd: select BACKLIGHT_LCD_SUPPORT
  OMAPDSS: DPI needs DSI
  crypto: lz4: don't build on ARM
  mfd: ab8500: debugfs code depends on gpadc
  iwlegacy: il_pm_ops is only provided for PM_SLEEP
  thermal: cpu_cooling: fix stub function
  staging/logger: use kuid_t internally
  oprofile: always enable IRQ_WORK
  USB: EHCI: remove bogus #error
  USB: UHCI: clarify Kconfig dependencies
  USB: OHCI: clarify Kconfig dependencies
  Xen: SWIOTLB is only used on x86
  staging/solo6x10: depend on CONFIG_FONTS
  media: coda: select GENERIC_ALLOCATOR
  davinci: vpfe_capture needs i2c
  radio-si4713: depend on SND_SOC

 arch/Kconfig                           |  1 +
 crypto/Kconfig                         |  2 ++
 drivers/cpufreq/Kconfig.arm            |  1 +
 drivers/cpuidle/Kconfig                |  1 +
 drivers/gpu/drm/tilcdc/Kconfig         |  1 +
 drivers/gpu/host1x/drm/Kconfig         |  1 +
 drivers/media/platform/Kconfig         |  1 +
 drivers/media/platform/davinci/Kconfig |  3 ++
 drivers/media/radio/Kconfig            |  1 +
 drivers/mfd/Kconfig                    |  2 +-
 drivers/net/can/Kconfig                |  6 ++--
 drivers/net/wireless/iwlegacy/common.h |  2 +-
 drivers/staging/android/logger.c       |  4 +--
 drivers/staging/android/logger.h       |  2 +-
 drivers/staging/imx-drm/Kconfig        |  4 +++
 drivers/staging/media/solo6x10/Kconfig |  1 +
 drivers/usb/host/Kconfig               | 65 +++++++++++++++++++++++++++++-----
 drivers/usb/host/Makefile              |  4 +--
 drivers/usb/host/ehci-hcd.c            | 17 ---------
 drivers/usb/host/ohci-hcd.c            | 19 ----------
 drivers/usb/host/uhci-hcd.c            |  4 +--
 drivers/video/console/Makefile         |  2 ++
 drivers/video/omap2/dss/Kconfig        |  1 +
 drivers/xen/Kconfig                    |  2 +-
 include/drm/drmP.h                     |  3 +-
 include/linux/cpu_cooling.h            |  2 +-
 26 files changed, 91 insertions(+), 61 deletions(-)

-- 
1.8.1.2

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Robert Richter <rric@kernel.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: cpufreq@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-can@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: oprofile-list@lists.sf.net

[PATCH, RFC 01/22] can: move CONFIG_HAVE_CAN_FLEXCAN out of CAN_DEV

[Arnd Bergmann]

CONFIG_HAVE_CAN_FLEXCAN is a silect symbol that is meant to be selected
by platforms that support this driver, but that is not possible without
also selecting CAN_DEV, unless we move it out of the "if CAN_DEV"
section of the Kconfig file.

warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 &&
 IMX_HAVE_PLATFORM_FLEXCAN && SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
 which has unmet direct dependencies (NET && CAN && CAN_DEV)

Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/can/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index e456b70..3941a7d 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -29,6 +29,9 @@ config CAN_SLCAN
 	  can be changed by the 'maxdev=xx' module option. This driver can
 	  also be built as a module. If so, the module will be called slcan.
 
+config HAVE_CAN_FLEXCAN
+	bool
+
 config CAN_DEV
 	tristate "Platform CAN drivers with Netlink support"
 	default y
@@ -102,9 +105,6 @@ config CAN_JANZ_ICAN3
 	  This driver can also be built as a module. If so, the module will be
 	  called janz-ican3.ko.
 
-config HAVE_CAN_FLEXCAN
-	bool
-
 config CAN_FLEXCAN
 	tristate "Support for Freescale FLEXCAN based chips"
 	depends on HAVE_CAN_FLEXCAN
-- 
1.8.1.2

Re: [PATCH, RFC 01/22] can: move CONFIG_HAVE_CAN_FLEXCAN out of CAN_DEV

[Marc Kleine-Budde]

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

On 05/02/2013 05:16 PM, Arnd Bergmann wrote:
> CONFIG_HAVE_CAN_FLEXCAN is a silect symbol that is meant to be selected
> by platforms that support this driver, but that is not possible without
> also selecting CAN_DEV, unless we move it out of the "if CAN_DEV"
> section of the Kconfig file.
> 
> warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 &&
>  IMX_HAVE_PLATFORM_FLEXCAN && SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
>  which has unmet direct dependencies (NET && CAN && CAN_DEV)

With the advent of multi platform kernels I like to get rid of
HAVE_CAN_FLEXCAN completely.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH, RFC 01/22] can: move CONFIG_HAVE_CAN_FLEXCAN out of CAN_DEV

[Arnd Bergmann]

On Friday 03 May 2013, Marc Kleine-Budde wrote:
> On 05/02/2013 05:16 PM, Arnd Bergmann wrote:
> > CONFIG_HAVE_CAN_FLEXCAN is a silect symbol that is meant to be selected
> > by platforms that support this driver, but that is not possible without
> > also selecting CAN_DEV, unless we move it out of the "if CAN_DEV"
> > section of the Kconfig file.
> > 
> > warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 &&
> >  IMX_HAVE_PLATFORM_FLEXCAN && SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
> >  which has unmet direct dependencies (NET && CAN && CAN_DEV)
> 
> With the advent of multi platform kernels I like to get rid of
> HAVE_CAN_FLEXCAN completely.

Yes, good idea. Are there any other dependencies we need to add then?
I assume FLEXCAN needs to depend on HAS_IOMEM and OF at least, but
there might be more.

	Arnd

Re: [PATCH, RFC 01/22] can: move CONFIG_HAVE_CAN_FLEXCAN out of CAN_DEV

[Marc Kleine-Budde]

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

On 05/03/2013 05:24 PM, Arnd Bergmann wrote:
> On Friday 03 May 2013, Marc Kleine-Budde wrote:
>> On 05/02/2013 05:16 PM, Arnd Bergmann wrote:
>>> CONFIG_HAVE_CAN_FLEXCAN is a silect symbol that is meant to be selected
>>> by platforms that support this driver, but that is not possible without
>>> also selecting CAN_DEV, unless we move it out of the "if CAN_DEV"
>>> section of the Kconfig file.
>>>
>>> warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 &&
>>>  IMX_HAVE_PLATFORM_FLEXCAN && SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
>>>  which has unmet direct dependencies (NET && CAN && CAN_DEV)
>>
>> With the advent of multi platform kernels I like to get rid of
>> HAVE_CAN_FLEXCAN completely.
> 
> Yes, good idea. Are there any other dependencies we need to add then?
> I assume FLEXCAN needs to depend on HAS_IOMEM and OF at least, but
> there might be more.

The driver compiles (tested on SH and blacksfin) and works without
CONFIG_OF (on non DT arm platforms).

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

[PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Arnd Bergmann]

The big.LITTLE cpufreq driver uses the CPU topology API, which
needs to be reflected in Kconfig to prevent broken configurations.

warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY)

Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/cpufreq/Kconfig.arm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f3af18b..3fd6bdf 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -10,6 +10,7 @@ config ARM_DT_BL_CPUFREQ
 	tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
 	select ARM_BIG_LITTLE_CPUFREQ
 	depends on OF && HAVE_CLK
+	depends on ARM_CPU_TOPOLOGY
 	help
 	  This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
 	  This gets frequency tables from DT.
-- 
1.8.1.2

Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Viresh Kumar]

On 2 May 2013 20:46, Arnd Bergmann <arnd@arndb.de> wrote:
> The big.LITTLE cpufreq driver uses the CPU topology API, which
> needs to be reflected in Kconfig to prevent broken configurations.
>
> warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
> has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY)
>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: cpufreq@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/cpufreq/Kconfig.arm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index f3af18b..3fd6bdf 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -10,6 +10,7 @@ config ARM_DT_BL_CPUFREQ
>         tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
>         select ARM_BIG_LITTLE_CPUFREQ
>         depends on OF && HAVE_CLK
> +       depends on ARM_CPU_TOPOLOGY
>         help
>           This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
>           This gets frequency tables from DT.

This Kconfig thing has always been confusing to me. This is how the code looks
currently.

config ARM_BIG_LITTLE_CPUFREQ
        tristate
        depends on ARM_CPU_TOPOLOGY

config ARM_DT_BL_CPUFREQ
        tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
        select ARM_BIG_LITTLE_CPUFREQ
        depends on OF && HAVE_CLK
        help
          This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
          This gets frequency tables from DT.

Because all ARM big LITTLE cpufreq stuff have dependency on
ARM_CPU_TOPOLOGY, i have added dependency at a common place. So that
we don't end up adding this in every glue layer driver. How should this be done?

Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Rafael J. Wysocki]

On Friday, May 03, 2013 10:21:45 AM Viresh Kumar wrote:
> On 2 May 2013 20:46, Arnd Bergmann <arnd@arndb.de> wrote:
> > The big.LITTLE cpufreq driver uses the CPU topology API, which
> > needs to be reflected in Kconfig to prevent broken configurations.
> >
> > warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
> > has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY)
> >
> > Cc: Rafael J. Wysocki <rjw@sisk.pl>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: cpufreq@vger.kernel.org
> > Cc: linux-pm@vger.kernel.org
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> >  drivers/cpufreq/Kconfig.arm | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index f3af18b..3fd6bdf 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -10,6 +10,7 @@ config ARM_DT_BL_CPUFREQ
> >         tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
> >         select ARM_BIG_LITTLE_CPUFREQ
> >         depends on OF && HAVE_CLK
> > +       depends on ARM_CPU_TOPOLOGY
> >         help
> >           This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
> >           This gets frequency tables from DT.
> 
> This Kconfig thing has always been confusing to me. This is how the code looks
> currently.
> 
> config ARM_BIG_LITTLE_CPUFREQ
>         tristate
>         depends on ARM_CPU_TOPOLOGY
> 
> config ARM_DT_BL_CPUFREQ
>         tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
>         select ARM_BIG_LITTLE_CPUFREQ
>         depends on OF && HAVE_CLK
>         help
>           This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
>           This gets frequency tables from DT.
> 
> Because all ARM big LITTLE cpufreq stuff have dependency on
> ARM_CPU_TOPOLOGY, i have added dependency at a common place. So that
> we don't end up adding this in every glue layer driver. How should this be done?

First, there's no rule of thumb here as far as I can say.

In this particular case I think it is OK to make both ARM_DT_BL_CPUFREQ and
ARM_BIG_LITTLE_CPUFREQ depend on ARM_CPU_TOPOLOGY, because (in theory?) the
latter may be set without the former (unless you want to make ARM_DT_BL_CPUFREQ
depend on ARM_BIG_LITTLE_CPUFREQ, but then it may be kind of confusing to
users).

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Viresh Kumar]

On 3 May 2013 17:45, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> In this particular case I think it is OK to make both ARM_DT_BL_CPUFREQ and
> ARM_BIG_LITTLE_CPUFREQ depend on ARM_CPU_TOPOLOGY, because (in theory?) the
> latter may be set without the former (unless you want to make ARM_DT_BL_CPUFREQ
> depend on ARM_BIG_LITTLE_CPUFREQ, but then it may be kind of confusing to
> users).

ARM_BIG_LITTLE_CPUFREQ is the core cpufreq code for big LITTLE SoC's and every
other driver will be a glue providing ops to it. So, ARM_DT_BL_CPUFREQ
does depend
on ARM_BIG_LITTLE_CPUFREQ and that's why i added depends on
ARM_CPU_TOPOLOGY in ARM_BIG_LITTLE_CPUFREQ only and depends on
ARM_BIG_LITTLE_CPUFREQ in ARM_DT_BL_CPUFREQ.

But the problem is if ARM_DT_BL_CPUFREQ isn't selected then we still get
ARM_DT_BL_CPUFREQ enabled in menuconfig but a warning just before compilation.
Which Arnd pointed to..

Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Rafael J. Wysocki]

On Friday, May 03, 2013 06:31:52 PM Viresh Kumar wrote:
> On 3 May 2013 17:45, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > In this particular case I think it is OK to make both ARM_DT_BL_CPUFREQ and
> > ARM_BIG_LITTLE_CPUFREQ depend on ARM_CPU_TOPOLOGY, because (in theory?) the
> > latter may be set without the former (unless you want to make ARM_DT_BL_CPUFREQ
> > depend on ARM_BIG_LITTLE_CPUFREQ, but then it may be kind of confusing to
> > users).
> 
> ARM_BIG_LITTLE_CPUFREQ is the core cpufreq code for big LITTLE SoC's and every
> other driver will be a glue providing ops to it. So, ARM_DT_BL_CPUFREQ
> does depend
> on ARM_BIG_LITTLE_CPUFREQ and that's why i added depends on
> ARM_CPU_TOPOLOGY in ARM_BIG_LITTLE_CPUFREQ only and depends on
> ARM_BIG_LITTLE_CPUFREQ in ARM_DT_BL_CPUFREQ.

I'm seeing "select" in there, which is kind of different from "depends on".

> But the problem is if ARM_DT_BL_CPUFREQ isn't selected then we still get
> ARM_DT_BL_CPUFREQ enabled in menuconfig but a warning just before compilation.
> Which Arnd pointed to..

What do you mean by "enabled in menuconfig"?  Does it appear as an option to
select or is it actually selected?

In any case, I'm afraid adding ARM_CPU_TOPOLOGY to the "depends on" list in
ARM_DT_BL_CPUFREQ is the only way to avoid that particular warning.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Viresh Kumar]

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

On 2 May 2013 20:46, Arnd Bergmann <arnd@arndb.de> wrote:
> The big.LITTLE cpufreq driver uses the CPU topology API, which
> needs to be reflected in Kconfig to prevent broken configurations.
>
> warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
> has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY)
>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: cpufreq@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/cpufreq/Kconfig.arm | 1 +
>  1 file changed, 1 insertion(+)

With all the discussions we had, please see if you can replace your
patch with this one (Attached too for applying, copy/paste in gmail
will break it):

From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Sat, 4 May 2013 12:03:54 +0530
Subject: [PATCH] cpufreq: ARM big LITTLE: Fix Kconfig entries

This fixes usage of "depends on" and "select" options in Kconfig for ARM big
LITTLE cpufreq driver. Otherwise we get these warnings:

warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM &&
ARM_CPU_TOPOLOGY)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/Kconfig.arm | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 634e992..a924408 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -3,17 +3,17 @@
 #

 config ARM_BIG_LITTLE_CPUFREQ
-	tristate
-	depends on ARM_CPU_TOPOLOGY
-	select PM_OPP
+	tristate "Generic ARM big LITTLE CPUfreq driver"
+	depends on ARM_CPU_TOPOLOGY && PM_OPP && HAVE_CLK
+	help
+	  This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.

 config ARM_DT_BL_CPUFREQ
-	tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
-	select ARM_BIG_LITTLE_CPUFREQ
-	depends on OF && HAVE_CLK
+	tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
+	depends on ARM_BIG_LITTLE_CPUFREQ && OF
 	help
-	  This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
-	  This gets frequency tables from DT.
+	  This enables probing via DT for Generic CPUfreq driver for ARM
+	  big.LITTLE platform. This gets frequency tables from DT.

 config ARM_EXYNOS_CPUFREQ
 	bool "SAMSUNG EXYNOS SoCs"

[-- Attachment #2: 0001-cpufreq-ARM-big-LITTLE-Fix-Kconfig-entries.patch --]
[-- Type: application/octet-stream, Size: 1866 bytes --]

From b31d40aef18da91c5f933db6d68f8b32b20033a2 Mon Sep 17 00:00:00 2001
Message-Id: <b31d40aef18da91c5f933db6d68f8b32b20033a2.1367649473.git.viresh.kumar@linaro.org>
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Sat, 4 May 2013 12:03:54 +0530
Subject: [PATCH] cpufreq: ARM big LITTLE: Fix Kconfig entries

This fixes usage of "depends on" and "select" options in Kconfig for ARM big
LITTLE cpufreq driver. Otherwise we get these warnings:

warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/Kconfig.arm | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 634e992..a924408 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -3,17 +3,17 @@
 #
 
 config ARM_BIG_LITTLE_CPUFREQ
-	tristate
-	depends on ARM_CPU_TOPOLOGY
-	select PM_OPP
+	tristate "Generic ARM big LITTLE CPUfreq driver"
+	depends on ARM_CPU_TOPOLOGY && PM_OPP && HAVE_CLK
+	help
+	  This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
 
 config ARM_DT_BL_CPUFREQ
-	tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
-	select ARM_BIG_LITTLE_CPUFREQ
-	depends on OF && HAVE_CLK
+	tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
+	depends on ARM_BIG_LITTLE_CPUFREQ && OF
 	help
-	  This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
-	  This gets frequency tables from DT.
+	  This enables probing via DT for Generic CPUfreq driver for ARM
+	  big.LITTLE platform. This gets frequency tables from DT.
 
 config ARM_EXYNOS_CPUFREQ
 	bool "SAMSUNG EXYNOS SoCs"
-- 
1.7.12.rc2.18.g61b472e

Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Rafael J. Wysocki]

On Saturday, May 04, 2013 12:09:40 PM Viresh Kumar wrote:
> On 2 May 2013 20:46, Arnd Bergmann <arnd@arndb.de> wrote:
> > The big.LITTLE cpufreq driver uses the CPU topology API, which
> > needs to be reflected in Kconfig to prevent broken configurations.
> >
> > warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
> > has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY)
> >
> > Cc: Rafael J. Wysocki <rjw@sisk.pl>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: cpufreq@vger.kernel.org
> > Cc: linux-pm@vger.kernel.org
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> >  drivers/cpufreq/Kconfig.arm | 1 +
> >  1 file changed, 1 insertion(+)
> 
> With all the discussions we had, please see if you can replace your
> patch with this one (Attached too for applying, copy/paste in gmail
> will break it):
> 
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Date: Sat, 4 May 2013 12:03:54 +0530
> Subject: [PATCH] cpufreq: ARM big LITTLE: Fix Kconfig entries
> 
> This fixes usage of "depends on" and "select" options in Kconfig for ARM big
> LITTLE cpufreq driver. Otherwise we get these warnings:
> 
> warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
> has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM &&
> ARM_CPU_TOPOLOGY)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Queued up as a fix for v3.10.

Thanks,
Rafael


> ---
>  drivers/cpufreq/Kconfig.arm | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 634e992..a924408 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -3,17 +3,17 @@
>  #
> 
>  config ARM_BIG_LITTLE_CPUFREQ
> -	tristate
> -	depends on ARM_CPU_TOPOLOGY
> -	select PM_OPP
> +	tristate "Generic ARM big LITTLE CPUfreq driver"
> +	depends on ARM_CPU_TOPOLOGY && PM_OPP && HAVE_CLK
> +	help
> +	  This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
> 
>  config ARM_DT_BL_CPUFREQ
> -	tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
> -	select ARM_BIG_LITTLE_CPUFREQ
> -	depends on OF && HAVE_CLK
> +	tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
> +	depends on ARM_BIG_LITTLE_CPUFREQ && OF
>  	help
> -	  This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
> -	  This gets frequency tables from DT.
> +	  This enables probing via DT for Generic CPUfreq driver for ARM
> +	  big.LITTLE platform. This gets frequency tables from DT.
> 
>  config ARM_EXYNOS_CPUFREQ
>  	bool "SAMSUNG EXYNOS SoCs"
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH, RFC 03/22] cpuidle: calxeda: select ARM_CPU_SUSPEND

[Arnd Bergmann]

Like other ARM specific drivers, this one requires ARM_CPU_SUSPEND,
as shown by this linker error:

drivers/built-in.o: In function `calxeda_pwrdown_idle':
drivers/cpuidle/cpuidle-calxeda.c:84: undefined reference to `cpu_suspend'
drivers/cpuidle/cpuidle-calxeda.c:86: undefined reference to `cpu_resume'

Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/cpuidle/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index c4cc27e..e21cdfa 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -36,6 +36,7 @@ if CPU_IDLE
 config CPU_IDLE_CALXEDA
 	bool "CPU Idle Driver for Calxeda processors"
 	depends on ARCH_HIGHBANK
+	select ARM_CPU_SUSPEND
 	help
 	  Select this to enable cpuidle on Calxeda processors.
 
-- 
1.8.1.2

Re: [PATCH, RFC 03/22] cpuidle: calxeda: select ARM_CPU_SUSPEND

[Daniel Lezcano]

On 05/02/2013 05:16 PM, Arnd Bergmann wrote:
> Like other ARM specific drivers, this one requires ARM_CPU_SUSPEND,
> as shown by this linker error:
> 
> drivers/built-in.o: In function `calxeda_pwrdown_idle':
> drivers/cpuidle/cpuidle-calxeda.c:84: undefined reference to `cpu_suspend'
> drivers/cpuidle/cpuidle-calxeda.c:86: undefined reference to `cpu_resume'
> 
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>

> ---
>  drivers/cpuidle/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index c4cc27e..e21cdfa 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -36,6 +36,7 @@ if CPU_IDLE
>  config CPU_IDLE_CALXEDA
>  	bool "CPU Idle Driver for Calxeda processors"
>  	depends on ARCH_HIGHBANK
> +	select ARM_CPU_SUSPEND
>  	help
>  	  Select this to enable cpuidle on Calxeda processors.
>  
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH, RFC 03/22] cpuidle: calxeda: select ARM_CPU_SUSPEND

[Rob Herring]

On 05/02/2013 10:16 AM, Arnd Bergmann wrote:
> Like other ARM specific drivers, this one requires ARM_CPU_SUSPEND,
> as shown by this linker error:
> 
> drivers/built-in.o: In function `calxeda_pwrdown_idle':
> drivers/cpuidle/cpuidle-calxeda.c:84: undefined reference to `cpu_suspend'
> drivers/cpuidle/cpuidle-calxeda.c:86: undefined reference to `cpu_resume'
> 
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Rob Herring <rob.herring@calxeda.com>

> ---
>  drivers/cpuidle/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index c4cc27e..e21cdfa 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -36,6 +36,7 @@ if CPU_IDLE
>  config CPU_IDLE_CALXEDA
>  	bool "CPU Idle Driver for Calxeda processors"
>  	depends on ARCH_HIGHBANK
> +	select ARM_CPU_SUSPEND
>  	help
>  	  Select this to enable cpuidle on Calxeda processors.
>  
> 

[PATCH, RFC 04/22] staging/drm: imx: add missing dependencies

[Arnd Bergmann]

The imx DRM driver needs a couple of extra Kconfig dependencies
to avoid random build failures:

drivers/staging/imx-drm/ipuv3-crtc.c:448:
 undefined reference to `ipu_idmac_put'
 drivers/staging/imx-drm/ipuv3-crtc.c:450: undefined reference to
 `ipu_dmfc_put' drivers/staging/imx-drm/ipuv3-crtc.c:452:
 undefined reference to `ipu_dp_put'
 drivers/staging/imx-drm/ipuv3-crtc.c:454: undefined reference to
 `ipu_di_put'
drivers/built-in.o: In function `ipu_probe':
 :(.text+0x4b4174): undefined reference to `device_reset'
drivers/built-in.o: In function `imx_tve_probe':
 drivers/staging/imx-drm/imx-tve.c:648: undefined reference to
 `devm_regmap_init_mmio_clk'
drivers/built-in.o: In function
 `imx_pd_connector_get_modes':
 drivers/staging/imx-drm/parallel-display.c:78: undefined
 reference to `of_get_drm_display_mode'

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/staging/imx-drm/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 8c9e403..35ccda5 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -1,6 +1,7 @@
 config DRM_IMX
 	tristate "DRM Support for Freescale i.MX"
 	select DRM_KMS_HELPER
+	select VIDEOMODE_HELPERS
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_CMA_HELPER
 	depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM)
@@ -23,6 +24,7 @@ config DRM_IMX_PARALLEL_DISPLAY
 config DRM_IMX_TVE
 	tristate "Support for TV and VGA displays"
 	depends on DRM_IMX
+	select REGMAP_MMIO
 	help
 	  Choose this to enable the internal Television Encoder (TVe)
 	  found on i.MX53 processors.
@@ -30,6 +32,7 @@ config DRM_IMX_TVE
 config DRM_IMX_IPUV3_CORE
 	tristate "IPUv3 core support"
 	depends on DRM_IMX
+	depends on RESET_CONTROLLER
 	help
 	  Choose this if you have a i.MX5/6 system and want
 	  to use the IPU. This option only enables IPU base
@@ -38,5 +41,6 @@ config DRM_IMX_IPUV3_CORE
 config DRM_IMX_IPUV3
 	tristate "DRM Support for i.MX IPUv3"
 	depends on DRM_IMX
+	depends on DRM_IMX_IPUV3_CORE
 	help
 	  Choose this if you have a i.MX5 or i.MX6 processor.
-- 
1.8.1.2

Re: [PATCH, RFC 04/22] staging/drm: imx: add missing dependencies

[Shawn Guo]

On Thu, May 02, 2013 at 05:16:08PM +0200, Arnd Bergmann wrote:
> The imx DRM driver needs a couple of extra Kconfig dependencies
> to avoid random build failures:
> 
> drivers/staging/imx-drm/ipuv3-crtc.c:448:
>  undefined reference to `ipu_idmac_put'
>  drivers/staging/imx-drm/ipuv3-crtc.c:450: undefined reference to
>  `ipu_dmfc_put' drivers/staging/imx-drm/ipuv3-crtc.c:452:
>  undefined reference to `ipu_dp_put'
>  drivers/staging/imx-drm/ipuv3-crtc.c:454: undefined reference to
>  `ipu_di_put'
> drivers/built-in.o: In function `ipu_probe':
>  :(.text+0x4b4174): undefined reference to `device_reset'
> drivers/built-in.o: In function `imx_tve_probe':
>  drivers/staging/imx-drm/imx-tve.c:648: undefined reference to
>  `devm_regmap_init_mmio_clk'
> drivers/built-in.o: In function
>  `imx_pd_connector_get_modes':

>  drivers/staging/imx-drm/parallel-display.c:78: undefined
>  reference to `of_get_drm_display_mode'

There is a patch [1] from Marek fixing this one.

Shawn

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/233449

> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/staging/imx-drm/Kconfig | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
> index 8c9e403..35ccda5 100644
> --- a/drivers/staging/imx-drm/Kconfig
> +++ b/drivers/staging/imx-drm/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_IMX
>  	tristate "DRM Support for Freescale i.MX"
>  	select DRM_KMS_HELPER
> +	select VIDEOMODE_HELPERS
>  	select DRM_GEM_CMA_HELPER
>  	select DRM_KMS_CMA_HELPER
>  	depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM)
> @@ -23,6 +24,7 @@ config DRM_IMX_PARALLEL_DISPLAY
>  config DRM_IMX_TVE
>  	tristate "Support for TV and VGA displays"
>  	depends on DRM_IMX
> +	select REGMAP_MMIO
>  	help
>  	  Choose this to enable the internal Television Encoder (TVe)
>  	  found on i.MX53 processors.
> @@ -30,6 +32,7 @@ config DRM_IMX_TVE
>  config DRM_IMX_IPUV3_CORE
>  	tristate "IPUv3 core support"
>  	depends on DRM_IMX
> +	depends on RESET_CONTROLLER
>  	help
>  	  Choose this if you have a i.MX5/6 system and want
>  	  to use the IPU. This option only enables IPU base
> @@ -38,5 +41,6 @@ config DRM_IMX_IPUV3_CORE
>  config DRM_IMX_IPUV3
>  	tristate "DRM Support for i.MX IPUv3"
>  	depends on DRM_IMX
> +	depends on DRM_IMX_IPUV3_CORE
>  	help
>  	  Choose this if you have a i.MX5 or i.MX6 processor.
> -- 
> 1.8.1.2
> 

Re: [PATCH, RFC 04/22] staging/drm: imx: add missing dependencies

[Arnd Bergmann]

On Friday 03 May 2013, Shawn Guo wrote:
> On Thu, May 02, 2013 at 05:16:08PM +0200, Arnd Bergmann wrote:
> > The imx DRM driver needs a couple of extra Kconfig dependencies
> > to avoid random build failures:
> > 
> > drivers/staging/imx-drm/ipuv3-crtc.c:448:
> >  undefined reference to `ipu_idmac_put'
> >  drivers/staging/imx-drm/ipuv3-crtc.c:450: undefined reference to
> >  `ipu_dmfc_put' drivers/staging/imx-drm/ipuv3-crtc.c:452:
> >  undefined reference to `ipu_dp_put'
> >  drivers/staging/imx-drm/ipuv3-crtc.c:454: undefined reference to
> >  `ipu_di_put'
> > drivers/built-in.o: In function `ipu_probe':
> >  :(.text+0x4b4174): undefined reference to `device_reset'
> > drivers/built-in.o: In function `imx_tve_probe':
> >  drivers/staging/imx-drm/imx-tve.c:648: undefined reference to
> >  `devm_regmap_init_mmio_clk'
> > drivers/built-in.o: In function
> >  `imx_pd_connector_get_modes':
> 
> >  drivers/staging/imx-drm/parallel-display.c:78: undefined
> >  reference to `of_get_drm_display_mode'
> 
> There is a patch [1] from Marek fixing this one.
> 
> Shawn
> 
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/233449
> 

That patch only addresses one of the four missing dependencies.
I originally had four separate patches, but did not want to
bother everyone with those so I combined them into one.

	Arnd

Re: [PATCH, RFC 04/22] staging/drm: imx: add missing dependencies

[Shawn Guo]

On Fri, May 03, 2013 at 05:21:37PM +0200, Arnd Bergmann wrote:
> On Friday 03 May 2013, Shawn Guo wrote:
> > On Thu, May 02, 2013 at 05:16:08PM +0200, Arnd Bergmann wrote:
> > > The imx DRM driver needs a couple of extra Kconfig dependencies
> > > to avoid random build failures:
> > > 
> > > drivers/staging/imx-drm/ipuv3-crtc.c:448:
> > >  undefined reference to `ipu_idmac_put'
> > >  drivers/staging/imx-drm/ipuv3-crtc.c:450: undefined reference to
> > >  `ipu_dmfc_put' drivers/staging/imx-drm/ipuv3-crtc.c:452:
> > >  undefined reference to `ipu_dp_put'
> > >  drivers/staging/imx-drm/ipuv3-crtc.c:454: undefined reference to
> > >  `ipu_di_put'
> > > drivers/built-in.o: In function `ipu_probe':
> > >  :(.text+0x4b4174): undefined reference to `device_reset'
> > > drivers/built-in.o: In function `imx_tve_probe':
> > >  drivers/staging/imx-drm/imx-tve.c:648: undefined reference to
> > >  `devm_regmap_init_mmio_clk'
> > > drivers/built-in.o: In function
> > >  `imx_pd_connector_get_modes':
> > 
> > >  drivers/staging/imx-drm/parallel-display.c:78: undefined
> > >  reference to `of_get_drm_display_mode'
> > 
> > There is a patch [1] from Marek fixing this one.
> > 
> > Shawn
> > 
> > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/233449
> > 
> 
> That patch only addresses one of the four missing dependencies.
> I originally had four separate patches, but did not want to
> bother everyone with those so I combined them into one.

Yea, I agree we can address all of them in one patch.  But it seems
people agreed that there is a more correct way [1] to fix
of_get_drm_display_mode one, and that's how v2 of Marek's patch comes.

Shawn

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/232861/focus=232898

[PATCH, RFC 05/22] drm: always provide debugfs function prototypes

[Arnd Bergmann]

It is generally considered bad style to enclose function prototypes
in header files in #ifdef. This case illustrates why that is:
The tegra host1x driver calls into the debugfs functions if
CONFIG_DEBUG_FS is enabled, but that code is otherwise already
discarded by the compiler, so leaving the prototype in place
actually makes everything work.

drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_init':
drivers/gpu/host1x/drm/dc.c:1004:2: error: implicit declaration of function 'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_exit': drivers/gpu/host1x/drm/dc.c:1026:2: error: implicit declaration of function 'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]

Cc: Ben Gamari <bgamari@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/drm/drmP.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 6119659..f780d62 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1550,7 +1550,7 @@ extern int drm_proc_init(struct drm_minor *minor, struct proc_dir_entry *root);
 extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry *root);
 
 				/* Debugfs support */
-#if defined(CONFIG_DEBUG_FS)
+
 extern int drm_debugfs_init(struct drm_minor *minor, int minor_id,
 			    struct dentry *root);
 extern int drm_debugfs_create_files(struct drm_info_list *files, int count,
@@ -1558,7 +1558,6 @@ extern int drm_debugfs_create_files(struct drm_info_list *files, int count,
 extern int drm_debugfs_remove_files(struct drm_info_list *files, int count,
                                     struct drm_minor *minor);
 extern int drm_debugfs_cleanup(struct drm_minor *minor);
-#endif
 
 				/* Info file support */
 extern int drm_name_info(struct seq_file *m, void *data);
-- 
1.8.1.2

[PATCH, RFC 06/22] gpu/drm: host1x: add dependency on Tegra

[Arnd Bergmann]

While we try to make drivers platform independent, this driver currently
calls into an exported interface that is only provided on its own
platform, so we have to add the dependency.

drivers/built-in.o: In function `tegra_crtc_prepare':
 drivers/gpu/host1x/drm/dc.c:650: undefined reference to `tegra_periph_reset_deassert'
drivers/built-in.o: In function `tegra_output_hdmi_disable':
 drivers/gpu/host1x/drm/hdmi.c:840: undefined reference to `tegra_periph_reset_assert'
drivers/built-in.o: In function `tegra_output_hdmi_enable':
 drivers/gpu/host1x/drm/hdmi.c:651: undefined reference to `tegra_periph_reset_assert'
 drivers/gpu/host1x/drm/hdmi.c:653: undefined reference to `tegra_periph_reset_deassert'

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Arto Merilainen <amerilainen@nvidia.com>
Cc: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/gpu/host1x/drm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
index 69853a4..5a6a5cd 100644
--- a/drivers/gpu/host1x/drm/Kconfig
+++ b/drivers/gpu/host1x/drm/Kconfig
@@ -1,6 +1,7 @@
 config DRM_TEGRA
 	bool "NVIDIA Tegra DRM"
 	depends on DRM
+	depends on ARCH_TEGRA
 	select DRM_KMS_HELPER
 	select FB_SYS_FILLRECT
 	select FB_SYS_COPYAREA
-- 
1.8.1.2

Re: [PATCH, RFC 06/22] gpu/drm: host1x: add dependency on Tegra

[Thierry Reding]

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

On Thu, May 02, 2013 at 05:16:10PM +0200, Arnd Bergmann wrote:
> While we try to make drivers platform independent, this driver currently
> calls into an exported interface that is only provided on its own
> platform, so we have to add the dependency.
> 
> drivers/built-in.o: In function `tegra_crtc_prepare':
>  drivers/gpu/host1x/drm/dc.c:650: undefined reference to `tegra_periph_reset_deassert'
> drivers/built-in.o: In function `tegra_output_hdmi_disable':
>  drivers/gpu/host1x/drm/hdmi.c:840: undefined reference to `tegra_periph_reset_assert'
> drivers/built-in.o: In function `tegra_output_hdmi_enable':
>  drivers/gpu/host1x/drm/hdmi.c:651: undefined reference to `tegra_periph_reset_assert'
>  drivers/gpu/host1x/drm/hdmi.c:653: undefined reference to `tegra_periph_reset_deassert'
> 
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> Cc: Arto Merilainen <amerilainen@nvidia.com>
> Cc: Terje Bergstrom <tbergstrom@nvidia.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/gpu/host1x/drm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
> index 69853a4..5a6a5cd 100644
> --- a/drivers/gpu/host1x/drm/Kconfig
> +++ b/drivers/gpu/host1x/drm/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_TEGRA
>  	bool "NVIDIA Tegra DRM"
>  	depends on DRM
> +	depends on ARCH_TEGRA
>  	select DRM_KMS_HELPER
>  	select FB_SYS_FILLRECT
>  	select FB_SYS_COPYAREA

This was solved by a patch that went into Dave's DRM pull request for
3.10 by adding:

	depends on ARCH_TEGRA || ARCH_MULTIPLATFORM

to the Kconfig entry for TEGRA_HOST1X. The plan was to eventually remove
ARCH_TEGRA from that condition after 3.10 since ARCH_MULTIPLATFORM will
include ARCH_TEGRA anyway. I'm not sure why that patch hasn't made it
into linux-next yet, though.

Thierry

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

Re: [PATCH, RFC 06/22] gpu/drm: host1x: add dependency on Tegra

[Arnd Bergmann]

On Friday 03 May 2013 15:45:39 Thierry Reding wrote:
> > diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
> > index 69853a4..5a6a5cd 100644
> > --- a/drivers/gpu/host1x/drm/Kconfig
> > +++ b/drivers/gpu/host1x/drm/Kconfig
> > @@ -1,6 +1,7 @@
> >  config DRM_TEGRA
> >       bool "NVIDIA Tegra DRM"
> >       depends on DRM
> > +     depends on ARCH_TEGRA
> >       select DRM_KMS_HELPER
> >       select FB_SYS_FILLRECT
> >       select FB_SYS_COPYAREA
> 
> This was solved by a patch that went into Dave's DRM pull request for
> 3.10 by adding:
> 
>         depends on ARCH_TEGRA || ARCH_MULTIPLATFORM
> 
> to the Kconfig entry for TEGRA_HOST1X. The plan was to eventually remove
> ARCH_TEGRA from that condition after 3.10 since ARCH_MULTIPLATFORM will
> include ARCH_TEGRA anyway. I'm not sure why that patch hasn't made it
> into linux-next yet, though.

I saw the problem with ARCH_MULTIPLATFORM enabled, so I don't understand
how adding the dependency above would help. A possible alternative
would be to define an empty alternative for the interface used here,
as the patch below.

	Arnd

diff --git a/include/linux/clk/tegra.h b/include/linux/clk/tegra.h
index 642789b..1397190 100644
--- a/include/linux/clk/tegra.h
+++ b/include/linux/clk/tegra.h
@@ -120,8 +120,13 @@ static inline void tegra_cpu_clock_resume(void)
 }
 #endif
 
+#ifdef ARCH_TEGRA
 void tegra_periph_reset_deassert(struct clk *c);
 void tegra_periph_reset_assert(struct clk *c);
+#else
+static inline void tegra_periph_reset_deassert(struct clk *c) {}
+static inline void tegra_periph_reset_assert(struct clk *c) {}
+#endif
 void tegra_clocks_init(void);
 void tegra_clocks_apply_init_table(void);
 

[PATCH, RFC 07/22] drm/tilcd: select BACKLIGHT_LCD_SUPPORT

[Arnd Bergmann]

The dependecies for BACKLIGHT_CLASS_DEVICE are defined a bit
strange, but it seems one has to always select both BACKLIGHT_CLASS_DEVICE
and BACKLIGHT_LCD_SUPPORT to avoid this error:

drivers/gpu/drm/tilcdc/tilcdc_panel.c:396:
 undefined reference to `of_find_backlight_by_node'

Cc: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/gpu/drm/tilcdc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index e461e99..7a4d101 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -6,6 +6,7 @@ config DRM_TILCDC
 	select DRM_GEM_CMA_HELPER
 	select VIDEOMODE_HELPERS
 	select BACKLIGHT_CLASS_DEVICE
+	select BACKLIGHT_LCD_SUPPORT
 	help
 	  Choose this option if you have an TI SoC with LCDC display
 	  controller, for example AM33xx in beagle-bone, DA8xx, or
-- 
1.8.1.2

[PATCH, RFC 08/22] OMAPDSS: DPI needs DSI

[Arnd Bergmann]

The dpi.c file cannot be build correctly when the dsi.c file is
disabled in Kconfig. This clarifies the dependency in Kconfig
to avoid build errors:

drivers/video/omap2/dss/dpi.c: In function 'dpi_calc_pll_cb':
drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
drivers/video/omap2/dss/dpi.c: In function 'dpi_dsi_clk_calc':
drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/video/omap2/dss/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index cb0f145..4b30084 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -35,6 +35,7 @@ config OMAP2_DSS_COLLECT_IRQ_STATS
 
 config OMAP2_DSS_DPI
 	bool "DPI support"
+	depends on OMAP2_DSS_DSI
 	default y
 	help
 	  DPI Interface. This is the Parallel Display Interface.
-- 
1.8.1.2

Re: [PATCH, RFC 08/22] OMAPDSS: DPI needs DSI

[Tomi Valkeinen]

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

Hi Arnd,

On 05/02/2013 06:16 PM, Arnd Bergmann wrote:
> The dpi.c file cannot be build correctly when the dsi.c file is
> disabled in Kconfig. This clarifies the dependency in Kconfig
> to avoid build errors:
> 
> drivers/video/omap2/dss/dpi.c: In function 'dpi_calc_pll_cb':
> drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
> drivers/video/omap2/dss/dpi.c: In function 'dpi_dsi_clk_calc':
> drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]

I've sent a patch for this to DRM maintainer, hopefully merged soon.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH, RFC 08/22] OMAPDSS: DPI needs DSI

[Arnd Bergmann]

On Thursday 02 May 2013, Tomi Valkeinen wrote:
> On 05/02/2013 06:16 PM, Arnd Bergmann wrote:
> > The dpi.c file cannot be build correctly when the dsi.c file is
> > disabled in Kconfig. This clarifies the dependency in Kconfig
> > to avoid build errors:
> > 
> > drivers/video/omap2/dss/dpi.c: In function 'dpi_calc_pll_cb':
> > drivers/video/omap2/dss/dpi.c:181:2: error: implicit declaration of function 'dsi_hsdiv_calc' [-Werror=implicit-function-declaration]
> > drivers/video/omap2/dss/dpi.c: In function 'dpi_dsi_clk_calc':
> > drivers/video/omap2/dss/dpi.c:201:2: error: implicit declaration of function 'dsi_get_pll_clkin' [-Werror=implicit-function-declaration]
> 
> I've sent a patch for this to DRM maintainer, hopefully merged soon.
> 

Ok, thanks!

	Arnd

[PATCH, RFC 09/22] crypto: lz4: don't build on ARM

[Arnd Bergmann]

It is not currently possible to build the LZ4 code on ARM, so let's
remove that option in Kconfig for now.

lib/built-in.o: In function `lz4_compress64kctx':
 lib/lz4/lz4_compress.c:339: undefined reference to `__ctzsi2'
lib/built-in.o: In function `lz4_compressctx':
 lib/lz4/lz4_compress.c:157: undefined reference to `__ctzsi2'
lib/built-in.o: In function `lz4hc_commonlength':
 lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
 lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
lib/built-in.o: In function `lz4hc_insertandgetwidermatch':
 lib/lz4/lz4hc_compress.c:230: undefined reference to `__ctzsi2'

Cc: Chanho Min <chanho.min@lge.com>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 crypto/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index aa3a349..1cd134b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1361,6 +1361,7 @@ config CRYPTO_842
 
 config CRYPTO_LZ4
 	tristate "LZ4 compression algorithm"
+	depends on !ARM
 	select CRYPTO_ALGAPI
 	select LZ4_COMPRESS
 	select LZ4_DECOMPRESS
@@ -1369,6 +1370,7 @@ config CRYPTO_LZ4
 
 config CRYPTO_LZ4HC
 	tristate "LZ4HC compression algorithm"
+	depends on !ARM
 	select CRYPTO_ALGAPI
 	select LZ4HC_COMPRESS
 	select LZ4_DECOMPRESS
-- 
1.8.1.2

[PATCH, RFC 10/22] mfd: ab8500: debugfs code depends on gpadc

[Arnd Bergmann]

The AB8500_DEBUG code specifically requires access to the gpadc code,
not just the common ab8500 driver.

drivers/built-in.o: In function `ab8500_gpadc_bat_ctrl_print':
 mfd/ab8500-debugfs.c:1733: undefined reference to `ab8500_gpadc_get'
 mfd/ab8500-debugfs.c:1734: undefined reference to `ab8500_gpadc_read_raw'
 mfd/ab8500-debugfs.c:1736: undefined reference to `ab8500_gpadc_ad_to_voltage'

Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Philippe LANGLAIS <philippe.langlais@stericsson.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/mfd/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9b4703e..bf785db 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -580,7 +580,7 @@ config AB8500_CORE
 
 config AB8500_DEBUG
        bool "Enable debug info via debugfs"
-       depends on AB8500_CORE && DEBUG_FS
+       depends on AB8500_GPADC && DEBUG_FS
        default y if DEBUG_FS
        help
          Select this option if you want debug information using the debug
-- 
1.8.1.2

Re: [PATCH, RFC 10/22] mfd: ab8500: debugfs code depends on gpadc

[Lee Jones]

On Thu, 02 May 2013, Arnd Bergmann wrote:

> The AB8500_DEBUG code specifically requires access to the gpadc code,
> not just the common ab8500 driver.
> 
> drivers/built-in.o: In function `ab8500_gpadc_bat_ctrl_print':
>  mfd/ab8500-debugfs.c:1733: undefined reference to `ab8500_gpadc_get'
>  mfd/ab8500-debugfs.c:1734: undefined reference to `ab8500_gpadc_read_raw'
>  mfd/ab8500-debugfs.c:1736: undefined reference to `ab8500_gpadc_ad_to_voltage'
> 
> Cc: Linus Walleij <linus.walleij@stericsson.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Philippe LANGLAIS <philippe.langlais@stericsson.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/mfd/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 9b4703e..bf785db 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -580,7 +580,7 @@ config AB8500_CORE
>  
>  config AB8500_DEBUG
>         bool "Enable debug info via debugfs"
> -       depends on AB8500_CORE && DEBUG_FS
> +       depends on AB8500_GPADC && DEBUG_FS
>         default y if DEBUG_FS
>         help
>           Select this option if you want debug information using the debug

Did you find this with ALLCONFIG out of interest.

Applied by the way.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH, RFC 10/22] mfd: ab8500: debugfs code depends on gpadc

[Arnd Bergmann]

On Thursday 02 May 2013, Lee Jones wrote:
> > @@ -580,7 +580,7 @@ config AB8500_CORE
> >  
> >  config AB8500_DEBUG
> >         bool "Enable debug info via debugfs"
> > -       depends on AB8500_CORE && DEBUG_FS
> > +       depends on AB8500_GPADC && DEBUG_FS
> >         default y if DEBUG_FS
> >         help
> >           Select this option if you want debug information using the debug
> 
> Did you find this with ALLCONFIG out of interest.

I used "make randconfig" with this KCONFIG_ALLCONFIG file:

CONFIG_MMU=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_PROC_FS=y
 
> Applied by the way.

Thanks!

	Arnd

[PATCH, RFC 11/22] iwlegacy: il_pm_ops is only provided for PM_SLEEP

[Arnd Bergmann]

This makes sure the conditionals for the declaration match the
definition, so we provide the alternative

 #else
 #define IL_LEGACY_PM_OPS NULL
 #endif

in the correct cases.

drivers/built-in.o:(.data+0x57974): undefined reference to `il_pm_ops'

Cc: Johannes Berg <johannes.berg@intel.com>
Cc: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wireless/iwlegacy/common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index f8246f2..734f1b4 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1832,7 +1832,7 @@ u32 il_usecs_to_beacons(struct il_priv *il, u32 usec, u32 beacon_interval);
 __le32 il_add_beacon_time(struct il_priv *il, u32 base, u32 addon,
 			  u32 beacon_interval);
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 extern const struct dev_pm_ops il_pm_ops;
 
 #define IL_LEGACY_PM_OPS	(&il_pm_ops)
-- 
1.8.1.2

Re: [PATCH, RFC 11/22] iwlegacy: il_pm_ops is only provided for PM_SLEEP

[Borislav Petkov]

On Thu, May 02, 2013 at 05:16:15PM +0200, Arnd Bergmann wrote:
> This makes sure the conditionals for the declaration match the
> definition, so we provide the alternative
> 
>  #else
>  #define IL_LEGACY_PM_OPS NULL
>  #endif
> 
> in the correct cases.
> 
> drivers/built-in.o:(.data+0x57974): undefined reference to `il_pm_ops'

Yep, I see this too here.

> 
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: John W. Linville <linville@tuxdriver.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/net/wireless/iwlegacy/common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
> index f8246f2..734f1b4 100644
> --- a/drivers/net/wireless/iwlegacy/common.h
> +++ b/drivers/net/wireless/iwlegacy/common.h
> @@ -1832,7 +1832,7 @@ u32 il_usecs_to_beacons(struct il_priv *il, u32 usec, u32 beacon_interval);
>  __le32 il_add_beacon_time(struct il_priv *il, u32 base, u32 addon,
>  			  u32 beacon_interval);
>  
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
>  extern const struct dev_pm_ops il_pm_ops;
>  
>  #define IL_LEGACY_PM_OPS	(&il_pm_ops)

Btw, you might want to adjust the macro comments for consistency too,
like so. Alternatively, you could simply remove them since they only
clutter two-liner and one can see what it encloses.

--
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index f8246f2d88f9..4caaf52986a4 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1832,16 +1832,16 @@ u32 il_usecs_to_beacons(struct il_priv *il, u32 usec, u32 beacon_interval);
 __le32 il_add_beacon_time(struct il_priv *il, u32 base, u32 addon,
 			  u32 beacon_interval);
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 extern const struct dev_pm_ops il_pm_ops;
 
 #define IL_LEGACY_PM_OPS	(&il_pm_ops)
 
-#else /* !CONFIG_PM */
+#else /* !CONFIG_PM_SLEEP */
 
 #define IL_LEGACY_PM_OPS	NULL
 
-#endif /* !CONFIG_PM */
+#endif /* !CONFIG_PM_SLEEP */
 
 /*****************************************************
 *  Error Handling Debugging
--

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH, RFC 12/22] thermal: cpu_cooling: fix stub function

[Arnd Bergmann]

The function stub for cpufreq_cooling_get_level introduced
in 57df81069 "Thermal: exynos: fix cooling state translation"
is not syntactically correct C and needs to be fixed to avoid
this error:

In file included from drivers/thermal/db8500_thermal.c:20:0:
 include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level':
include/linux/cpu_cooling.h:57:1:
 error: parameter name omitted  unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)  ^
 include/linux/cpu_cooling.h:57:1: error: parameter name omitted

Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Amit Daniel kachhap <amit.daniel@samsung.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/linux/cpu_cooling.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index 282e270..cf03111 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -54,7 +54,7 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 	return;
 }
 static inline
-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq)
 {
 	return THERMAL_CSTATE_INVALID;
 }
-- 
1.8.1.2

Re: [PATCH, RFC 12/22] thermal: cpu_cooling: fix stub function

[Eduardo Valentin]

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

On 02-05-2013 11:16, Arnd Bergmann wrote:
> The function stub for cpufreq_cooling_get_level introduced
> in 57df81069 "Thermal: exynos: fix cooling state translation"
> is not syntactically correct C and needs to be fixed to avoid
> this error:
> 
> In file included from drivers/thermal/db8500_thermal.c:20:0:
>  include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level':
> include/linux/cpu_cooling.h:57:1:
>  error: parameter name omitted  unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)  ^
>  include/linux/cpu_cooling.h:57:1: error: parameter name omitted
> 
> Cc: Eduardo Valentin <eduardo.valentin@ti.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Amit Daniel kachhap <amit.daniel@samsung.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  include/linux/cpu_cooling.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
> index 282e270..cf03111 100644
> --- a/include/linux/cpu_cooling.h
> +++ b/include/linux/cpu_cooling.h
> @@ -54,7 +54,7 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>  	return;
>  }
>  static inline
> -unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)
> +unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq)

While there, could you please also include the following (same, but on
the function declaration on line 44), just to keep the header in same style?
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index 282e270..c023afa 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -41,7 +41,7 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus);
  */
 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);

-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int);
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int
freq);
 #else /* !CONFIG_CPU_THERMAL */
 static inline struct thermal_cooling_device *
 cpufreq_cooling_register(const struct cpumask *clip_cpus)


>  {
>  	return THERMAL_CSTATE_INVALID;
>  }
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[PATCH v2] thermal: cpu_cooling: fix stub function

[Arnd Bergmann]

The function stub for cpufreq_cooling_get_level introduced
in 57df81069 "Thermal: exynos: fix cooling state translation"
is not syntactically correct C and needs to be fixed to avoid
this error:

In file included from drivers/thermal/db8500_thermal.c:20:0:
 include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level':
include/linux/cpu_cooling.h:57:1:
 error: parameter name omitted  unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)  ^
 include/linux/cpu_cooling.h:57:1: error: parameter name omitted

Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Amit Daniel kachhap <amit.daniel@samsung.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index 282e270..a5d52ee 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -41,7 +41,7 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus);
  */
 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);
 
-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int);
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq);
 #else /* !CONFIG_CPU_THERMAL */
 static inline struct thermal_cooling_device *
 cpufreq_cooling_register(const struct cpumask *clip_cpus)
@@ -54,7 +54,7 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 	return;
 }
 static inline
-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq)
 {
 	return THERMAL_CSTATE_INVALID;
 }

Re: [PATCH v2] thermal: cpu_cooling: fix stub function

[Eduardo Valentin]

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

Rui, Arnd,

On 02-05-2013 12:29, Arnd Bergmann wrote:
> The function stub for cpufreq_cooling_get_level introduced
> in 57df81069 "Thermal: exynos: fix cooling state translation"
> is not syntactically correct C and needs to be fixed to avoid
> this error:
> 
> In file included from drivers/thermal/db8500_thermal.c:20:0:
>  include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level':
> include/linux/cpu_cooling.h:57:1:
>  error: parameter name omitted  unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)  ^
>  include/linux/cpu_cooling.h:57:1: error: parameter name omitted
> 
> Cc: Eduardo Valentin <eduardo.valentin@ti.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Amit Daniel kachhap <amit.daniel@samsung.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Eduardo Valentin <eduardo.valentin@ti.com>

> 
> diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
> index 282e270..a5d52ee 100644
> --- a/include/linux/cpu_cooling.h
> +++ b/include/linux/cpu_cooling.h
> @@ -41,7 +41,7 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus);
>   */
>  void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);
>  
> -unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int);
> +unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq);
>  #else /* !CONFIG_CPU_THERMAL */
>  static inline struct thermal_cooling_device *
>  cpufreq_cooling_register(const struct cpumask *clip_cpus)
> @@ -54,7 +54,7 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>  	return;
>  }
>  static inline
> -unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)
> +unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq)
>  {
>  	return THERMAL_CSTATE_INVALID;
>  }
> 
> 
> 

> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

Re: [PATCH v2] thermal: cpu_cooling: fix stub function

[Arnd Bergmann]

On Thursday 02 May 2013, Eduardo Valentin wrote:
> Rui, Arnd,
> 
> On 02-05-2013 12:29, Arnd Bergmann wrote:
> > The function stub for cpufreq_cooling_get_level introduced
> > in 57df81069 "Thermal: exynos: fix cooling state translation"
> > is not syntactically correct C and needs to be fixed to avoid
> > this error:
> > 
> > In file included from drivers/thermal/db8500_thermal.c:20:0:
> >  include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level':
> > include/linux/cpu_cooling.h:57:1:
> >  error: parameter name omitted  unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)  ^
> >  include/linux/cpu_cooling.h:57:1: error: parameter name omitted
> > 
> > Cc: Eduardo Valentin <eduardo.valentin@ti.com>
> > Cc: Zhang Rui <rui.zhang@intel.com>
> > Cc: Amit Daniel kachhap <amit.daniel@samsung.com>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Acked-by: Eduardo Valentin <eduardo.valentin@ti.com>

Rui,

Could you please merge that into your thermal/next tree?  Right now,
linux-next fails to build because of this, and you probably don't
want to send the current version to Linus without fixing it.

	Arnd

[PATCH, RFC 13/22] staging/logger: use kuid_t internally

[Arnd Bergmann]

This is probably wrong but lets us build the driver with
CONFIG_UIDGID_STRICT_TYPE_CHECKS enabled. Without it, we get
these errors:

drivers/staging/android/logger.c: In function 'logger_read':
drivers/staging/android/logger.c:316:4: error: incompatible type for argument 3 of 'get_next_entry_by_uid'
drivers/staging/android/logger.c:244:15: note: expected 'uid_t' but argument is of type 'kuid_t'
drivers/staging/android/logger.c: In function 'logger_aio_write':
drivers/staging/android/logger.c:483:14: error: incompatible types when assigning to type 'uid_t' from type 'kuid_t'

which tells us that the driver is not compatible with user namespaces.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/staging/android/logger.c | 4 ++--
 drivers/staging/android/logger.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index b040200..9bd8747 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -242,7 +242,7 @@ static ssize_t do_read_log_to_user(struct logger_log *log,
  * 'log->buffer' which contains the first entry readable by 'euid'
  */
 static size_t get_next_entry_by_uid(struct logger_log *log,
-		size_t off, uid_t euid)
+		size_t off, kuid_t euid)
 {
 	while (off != log->w_off) {
 		struct logger_entry *entry;
@@ -251,7 +251,7 @@ static size_t get_next_entry_by_uid(struct logger_log *log,
 
 		entry = get_entry_header(log, off, &scratch);
 
-		if (entry->euid == euid)
+		if (uid_eq(entry->euid, euid))
 			return off;
 
 		next_len = sizeof(struct logger_entry) + entry->len;
diff --git a/drivers/staging/android/logger.h b/drivers/staging/android/logger.h
index cc6bbd9..70af7d8 100644
--- a/drivers/staging/android/logger.h
+++ b/drivers/staging/android/logger.h
@@ -66,7 +66,7 @@ struct logger_entry {
 	__s32		tid;
 	__s32		sec;
 	__s32		nsec;
-	uid_t		euid;
+	kuid_t		euid;
 	char		msg[0];
 };
 
-- 
1.8.1.2

[PATCH, RFC 14/22] oprofile: always enable IRQ_WORK

[Arnd Bergmann]

oprofile fails to build if CONFIG_IRQ_WORK is not already enabled,
because of the dependency on the RING_BUFFER code that now uses
the irq work library.

kernel/built-in.o: In function `ring_buffer_unlock_commit':
:(.text+0x5b8f0): undefined reference to `irq_work_queue'
kernel/built-in.o: In function `ring_buffer_write':
:(.text+0x5bd10): undefined reference to `irq_work_queue'

Cc: Robert Richter <rric@kernel.org>
Cc: oprofile-list@lists.sf.net
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index a6b1056..434a8dc 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -8,6 +8,7 @@ config OPROFILE
 	depends on HAVE_OPROFILE
 	select RING_BUFFER
 	select RING_BUFFER_ALLOW_SWAP
+	select IRQ_WORK
 	help
 	  OProfile is a profiling system capable of profiling the
 	  whole system, include the kernel, kernel modules, libraries,
-- 
1.8.1.2

Re: [PATCH, RFC 14/22] oprofile: always enable IRQ_WORK

[Robert Richter]

On 02.05.13 17:16:18, Arnd Bergmann wrote:
> oprofile fails to build if CONFIG_IRQ_WORK is not already enabled,
> because of the dependency on the RING_BUFFER code that now uses
> the irq work library.
> 
> kernel/built-in.o: In function `ring_buffer_unlock_commit':
> :(.text+0x5b8f0): undefined reference to `irq_work_queue'
> kernel/built-in.o: In function `ring_buffer_write':
> :(.text+0x5bd10): undefined reference to `irq_work_queue'

Shouldn't this be fixed in the ring_buffer implementation?

I also do not see, where this comes from. I was successfully compiling
a kernel with OPROFILE and RING_BUFFER enabled but IRQ_WORK disabled.
Do you have that config still available?

Thanks,

-Robert

> 
> Cc: Robert Richter <rric@kernel.org>
> Cc: oprofile-list@lists.sf.net
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index a6b1056..434a8dc 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -8,6 +8,7 @@ config OPROFILE
>  	depends on HAVE_OPROFILE
>  	select RING_BUFFER
>  	select RING_BUFFER_ALLOW_SWAP
> +	select IRQ_WORK
>  	help
>  	  OProfile is a profiling system capable of profiling the
>  	  whole system, include the kernel, kernel modules, libraries,
> -- 
> 1.8.1.2
> 

Re: [PATCH, RFC 14/22] oprofile: always enable IRQ_WORK

[Steven Rostedt]

On Fri, 2013-05-03 at 13:53 +0200, Robert Richter wrote:
> On 02.05.13 17:16:18, Arnd Bergmann wrote:
> > oprofile fails to build if CONFIG_IRQ_WORK is not already enabled,
> > because of the dependency on the RING_BUFFER code that now uses
> > the irq work library.
> > 
> > kernel/built-in.o: In function `ring_buffer_unlock_commit':
> > :(.text+0x5b8f0): undefined reference to `irq_work_queue'
> > kernel/built-in.o: In function `ring_buffer_write':
> > :(.text+0x5bd10): undefined reference to `irq_work_queue'
> 
> Shouldn't this be fixed in the ring_buffer implementation?

Hmm, I thought I had ring buffer select irq work. I must have not have
done that.

> 
> I also do not see, where this comes from. I was successfully compiling
> a kernel with OPROFILE and RING_BUFFER enabled but IRQ_WORK disabled.
> Do you have that config still available?
> 

The ring buffer code can now wake up waiters, and to do so it requires
irq_work. I'll send a patch.

Thanks,

-- Steve

Re: [PATCH, RFC 14/22] oprofile: always enable IRQ_WORK

[Steven Rostedt]

On Fri, 2013-05-03 at 13:53 +0200, Robert Richter wrote:
> On 02.05.13 17:16:18, Arnd Bergmann wrote:
> > oprofile fails to build if CONFIG_IRQ_WORK is not already enabled,
> > because of the dependency on the RING_BUFFER code that now uses
> > the irq work library.
> > 
> > kernel/built-in.o: In function `ring_buffer_unlock_commit':
> > :(.text+0x5b8f0): undefined reference to `irq_work_queue'
> > kernel/built-in.o: In function `ring_buffer_write':
> > :(.text+0x5bd10): undefined reference to `irq_work_queue'
> 
> Shouldn't this be fixed in the ring_buffer implementation?

Does this patch fix it?

-- Steve

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 5e9efd4..015f85a 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -71,6 +71,7 @@ config TRACE_CLOCK
 config RING_BUFFER
 	bool
 	select TRACE_CLOCK
+	select IRQ_WORK
 
 config FTRACE_NMI_ENTER
        bool
@@ -107,7 +108,6 @@ config TRACING
 	select BINARY_PRINTF
 	select EVENT_TRACING
 	select TRACE_CLOCK
-	select IRQ_WORK
 
 config GENERIC_TRACER
 	bool

Re: [PATCH, RFC 14/22] oprofile: always enable IRQ_WORK

[Arnd Bergmann]

On Friday 03 May 2013, Steven Rostedt wrote:
> On Fri, 2013-05-03 at 13:53 +0200, Robert Richter wrote:
> > On 02.05.13 17:16:18, Arnd Bergmann wrote:
> > > oprofile fails to build if CONFIG_IRQ_WORK is not already enabled,
> > > because of the dependency on the RING_BUFFER code that now uses
> > > the irq work library.
> > > 
> > > kernel/built-in.o: In function `ring_buffer_unlock_commit':
> > > :(.text+0x5b8f0): undefined reference to `irq_work_queue'
> > > kernel/built-in.o: In function `ring_buffer_write':
> > > :(.text+0x5bd10): undefined reference to `irq_work_queue'
> > 
> > Shouldn't this be fixed in the ring_buffer implementation?
> 
> Does this patch fix it?
> 


Yes, this works, and looks much nicer than my version. Thanks!

	Arnd

[PATCH, RFC 15/22] USB: EHCI: remove bogus #error

[Arnd Bergmann]

The EHCI host controller driver can be built standalone now,
without enabling any of the available bus glue drivers, so
there is not really a reason to error out here:

drivers/usb/host/ehci-hcd.c:1303:2: error:
 #error "missing bus glue for ehci-hcd"  #error "missing bus glue for ehci-hcd"

The alternative would be to change the Kconfig code to build
the ehci-hcd module only if any of the symbols below are
in fact enabled.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/usb/host/ehci-hcd.c | 17 -----------------
 1 file changed, 17 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 312fc10..246e124 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1286,23 +1286,6 @@ MODULE_LICENSE ("GPL");
 #define	PLATFORM_DRIVER		ehci_hcd_sead3_driver
 #endif
 
-#if !IS_ENABLED(CONFIG_USB_EHCI_PCI) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) && \
-	!IS_ENABLED(CONFIG_USB_CHIPIDEA_HOST) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_MXC) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_HCD_AT91) && \
-	!IS_ENABLED(CONFIG_USB_EHCI_MSM) && \
-	!defined(PLATFORM_DRIVER) && \
-	!defined(PS3_SYSTEM_BUS_DRIVER) && \
-	!defined(OF_PLATFORM_DRIVER) && \
-	!defined(XILINX_OF_PLATFORM_DRIVER)
-#error "missing bus glue for ehci-hcd"
-#endif
-
 static int __init ehci_hcd_init(void)
 {
 	int retval = 0;
-- 
1.8.1.2

Re: [PATCH, RFC 15/22] USB: EHCI: remove bogus #error

[Alan Stern]

On Thu, 2 May 2013, Arnd Bergmann wrote:

> The EHCI host controller driver can be built standalone now,
> without enabling any of the available bus glue drivers, so
> there is not really a reason to error out here:

On the other hand, there's no reason to build the driver without any 
bus glue.  It wouldn't do anything.

> drivers/usb/host/ehci-hcd.c:1303:2: error:
>  #error "missing bus glue for ehci-hcd"  #error "missing bus glue for ehci-hcd"
> 
> The alternative would be to change the Kconfig code to build
> the ehci-hcd module only if any of the symbols below are
> in fact enabled.
> 
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Re: [PATCH, RFC 15/22] USB: EHCI: remove bogus #error

[Arnd Bergmann]

On Thursday 02 May 2013, Alan Stern wrote:
> On Thu, 2 May 2013, Arnd Bergmann wrote:
> 
> > The EHCI host controller driver can be built standalone now,
> > without enabling any of the available bus glue drivers, so
> > there is not really a reason to error out here:
> 
> On the other hand, there's no reason to build the driver without any 
> bus glue.  It wouldn't do anything.

Yes, as I mention below, we could also use Kconfig logic to prevent
that case, as the OHCI and UHCI patches from this series do, but I felt
that would be a lot of unnecessary churn, and having just ehci-hci.ko
enabled without a bus glue is not an error, it's just as pointless
as most of the other drivers we get with "make randconfig".

> > drivers/usb/host/ehci-hcd.c:1303:2: error:
> >  #error "missing bus glue for ehci-hcd"  #error "missing bus glue for ehci-hcd"
> > 
> > The alternative would be to change the Kconfig code to build
> > the ehci-hcd module only if any of the symbols below are
> > in fact enabled.

	Arnd

[PATCH, RFC 16/22] USB: UHCI: clarify Kconfig dependencies

[Arnd Bergmann]

The UHCI driver currently gives a build error if the base driver is
enabled but none of the three bus glues are turned on:

drivers/usb/host/uhci-hcd.c:857:2: error: #error "missing bus glue for uhci-hcd"

A better solution for this is to change the Kconfig statements to
prevent getting into this situation. This adds a new USB_UHCI_CORE
symbol in Kconfig, which is selected by each of the three bus glues.
This way, the driver never gets built if all three of them are disabled.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/usb/host/Kconfig    | 36 +++++++++++++++++++++++++++---------
 drivers/usb/host/Makefile   |  2 +-
 drivers/usb/host/uhci-hcd.c |  4 ++--
 3 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7b176bc..656af4d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -525,28 +525,46 @@ config USB_UHCI_HCD
 	  To compile this driver as a module, choose M here: the
 	  module will be called uhci-hcd.
 
-config USB_UHCI_SUPPORT_NON_PCI_HC
-	bool
-	depends on USB_UHCI_HCD
-	default y if (SPARC_LEON || ARCH_VT8500)
+if USB_UHCI_HCD
+
+config USB_UHCI_PCI
+	tristate
+	default USB_UHCI_HCD
+	depends on PCI
+	select USB_UHCI_CORE
+
+config USB_UHCI_GRLIB
+	tristate
+	default USB_UHCI_HCD
+	depends on SPARC_LEON
+	select USB_UHCI_CORE
+	select USB_UHCI_SUPPORT_NON_PCI_HC
+	select USB_UHCI_BIG_ENDIAN_MMIO
+	select USB_UHCI_BIG_ENDIAN_DESC
 
 config USB_UHCI_PLATFORM
 	bool "Generic UHCI Platform Driver support"
-	depends on USB_UHCI_SUPPORT_NON_PCI_HC
 	default y if ARCH_VT8500
+	select USB_UHCI_SUPPORT_NON_PCI_HC
+	select USB_UHCI_CORE
 	---help---
 	  Enable support for generic UHCI platform devices that require no
 	  additional configuration.
 
+config USB_UHCI_CORE
+	tristate
+	depends on USB_UHCI_HCD
+
+config USB_UHCI_SUPPORT_NON_PCI_HC
+	bool
+
 config USB_UHCI_BIG_ENDIAN_MMIO
 	bool
-	depends on USB_UHCI_SUPPORT_NON_PCI_HC && SPARC_LEON
-	default y
 
 config USB_UHCI_BIG_ENDIAN_DESC
 	bool
-	depends on USB_UHCI_SUPPORT_NON_PCI_HC && SPARC_LEON
-	default y
+
+endif
 
 config USB_FHCI_HCD
 	tristate "Freescale QE USB Host Controller support"
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 4fb73c1..1441d42 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
 obj-$(CONFIG_USB_ISP1362_HCD)	+= isp1362-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD)	+= ohci-hcd.o
-obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
+obj-$(CONFIG_USB_UHCI_CORE)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
 obj-$(CONFIG_USB_XHCI_HCD)	+= xhci-hcd.o
 obj-$(CONFIG_USB_SL811_HCD)	+= sl811-hcd.o
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..612b792 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -838,12 +838,12 @@ static int uhci_count_ports(struct usb_hcd *hcd)
 
 static const char hcd_name[] = "uhci_hcd";
 
-#ifdef CONFIG_PCI
+#ifdef CONFIG_USB_UHCI_PCI
 #include "uhci-pci.c"
 #define	PCI_DRIVER		uhci_pci_driver
 #endif
 
-#ifdef CONFIG_SPARC_LEON
+#ifdef CONFIG_USB_UHCI_GRLIB
 #include "uhci-grlib.c"
 #define PLATFORM_DRIVER		uhci_grlib_driver
 #endif
-- 
1.8.1.2

Re: [PATCH, RFC 16/22] USB: UHCI: clarify Kconfig dependencies

[Alan Stern]

On Thu, 2 May 2013, Arnd Bergmann wrote:

> The UHCI driver currently gives a build error if the base driver is
> enabled but none of the three bus glues are turned on:
> 
> drivers/usb/host/uhci-hcd.c:857:2: error: #error "missing bus glue for uhci-hcd"
> 
> A better solution for this is to change the Kconfig statements to
> prevent getting into this situation. This adds a new USB_UHCI_CORE
> symbol in Kconfig, which is selected by each of the three bus glues.
> This way, the driver never gets built if all three of them are disabled.

I had already worked out a patch on my own for this (below).  It is
different from yours in several ways:

	It relies more on "depends" than "select".  I don't know how 
	important this is in the end.

	It doesn't add a new USB_UHCI_GRLIB symbol; instead it uses
	SPARC_LEON in several places.  I tend to think the new symbol
	is nicer.

	It doesn't add a new USB_UHCI_PCI symbol.

	It improves the dependency list for USB_UHCI_HCD.

	It removes the help text for USB_UHCI_PLATFORM, thereby making
	that symbol not user-configurable.  I don't see any reason why
	the user should need to worry about this -- the choice should
	be a very simple one: build UHCI support or don't build it.  If
	the user chooses to build it then it should include support for
	all the compatible bus glues.  (This last decision may need to 
	be changed if more bus glues get added.)

	It prevents situations where USB_UHCI_HCD is enabled but the
	driver doesn't get built.

	It creates a bunch of USB_UHCI_* symbols even when USB_UHCI_HCD
	is disabled.  This is a disadvantage, but I don't see any way
	around it.  Basically, we have to consider two separate but
	related questions:

		Does the supported hardware configuration allow for 
		UHCI?

		Which types of UHCI bus glue support should be included 
		in the kernel?

	If the answer to the first is Yes then creating these symbols
	seems unavoidable, even when the answer to the second is None.

Maybe the ideal solution is some sort of combination of the two
patches.

What do you think of my patch as compared to yours?  And what do you
think of the "depends" vs. "select" issue?

Alan Stern



Index: usb-3.9/drivers/usb/host/Kconfig
===================================================================
--- usb-3.9.orig/drivers/usb/host/Kconfig
+++ usb-3.9/drivers/usb/host/Kconfig
@@ -507,7 +507,7 @@ endif # USB_OHCI_HCD
 
 config USB_UHCI_HCD
 	tristate "UHCI HCD (most Intel and VIA) support"
-	depends on PCI || SPARC_LEON || ARCH_VT8500
+	depends on PCI || USB_UHCI_SUPPORT_NON_PCI_HC
 	---help---
 	  The Universal Host Controller Interface is a standard by Intel for
 	  accessing the USB hardware in the PC (which is also called the USB
@@ -524,26 +524,19 @@ config USB_UHCI_HCD
 
 config USB_UHCI_SUPPORT_NON_PCI_HC
 	bool
-	depends on USB_UHCI_HCD
-	default y if (SPARC_LEON || ARCH_VT8500)
+	default y if (SPARC_LEON || USB_UHCI_PLATFORM)
 
 config USB_UHCI_PLATFORM
-	bool "Generic UHCI Platform Driver support"
-	depends on USB_UHCI_SUPPORT_NON_PCI_HC
+	bool
 	default y if ARCH_VT8500
-	---help---
-	  Enable support for generic UHCI platform devices that require no
-	  additional configuration.
 
 config USB_UHCI_BIG_ENDIAN_MMIO
 	bool
-	depends on USB_UHCI_SUPPORT_NON_PCI_HC && SPARC_LEON
-	default y
+	default y if SPARC_LEON
 
 config USB_UHCI_BIG_ENDIAN_DESC
 	bool
-	depends on USB_UHCI_SUPPORT_NON_PCI_HC && SPARC_LEON
-	default y
+	default y if SPARC_LEON
 
 config USB_FHCI_HCD
 	tristate "Freescale QE USB Host Controller support"

Re: [PATCH, RFC 16/22] USB: UHCI: clarify Kconfig dependencies

[Arnd Bergmann]

On Thursday 02 May 2013, Alan Stern wrote:
> On Thu, 2 May 2013, Arnd Bergmann wrote:
> 
> 	It relies more on "depends" than "select".  I don't know how 
> 	important this is in the end.

'select' is sometimes problematic, but the only use that I try to
avoid is having one Kconfig symbol that is both user-selectable
standalone and selected by something else.

> 	It doesn't add a new USB_UHCI_GRLIB symbol; instead it uses
> 	SPARC_LEON in several places.  I tend to think the new symbol
> 	is nicer.
> 
> 	It doesn't add a new USB_UHCI_PCI symbol.
> 
> 	It improves the dependency list for USB_UHCI_HCD.
> 
> 	It removes the help text for USB_UHCI_PLATFORM, thereby making
> 	that symbol not user-configurable.  I don't see any reason why
> 	the user should need to worry about this -- the choice should
> 	be a very simple one: build UHCI support or don't build it.  If
> 	the user chooses to build it then it should include support for
> 	all the compatible bus glues.  (This last decision may need to 
> 	be changed if more bus glues get added.)
>
> What do you think of my patch as compared to yours? 

I think in the end it comes down to the question where you want to
head with your driver. The way I did my version was going towards
making it similar to EHCI, with stand-alone bus glue drivers
and a core that is just a library module but does not register
a device_driver by itself.

Given that there are just three bus glues from UHCI, and at most
two of them enabled at the same time, I don't see a direct need
for UHCI to go down the same route as EHCI. If you want to just
leave this driver alone, your patch is simpler and has the same
effect in the end. Otherwise I think my patch avoids changing it
all again once the driver gets reworked.

Things might also get a little messy if we are seeing a lot
of other platforms beside VIA VT8500 use UHCI, but I think that
is rather unlikely.

	Arnd

Re: [PATCH, RFC 16/22] USB: UHCI: clarify Kconfig dependencies

[Alan Stern]

On Thu, 2 May 2013, Arnd Bergmann wrote:

> > What do you think of my patch as compared to yours? 
> 
> I think in the end it comes down to the question where you want to
> head with your driver. The way I did my version was going towards
> making it similar to EHCI, with stand-alone bus glue drivers
> and a core that is just a library module but does not register
> a device_driver by itself.
> 
> Given that there are just three bus glues from UHCI, and at most
> two of them enabled at the same time, I don't see a direct need
> for UHCI to go down the same route as EHCI. If you want to just
> leave this driver alone, your patch is simpler and has the same
> effect in the end. Otherwise I think my patch avoids changing it
> all again once the driver gets reworked.

Okay then, I'll submit my patch to Greg after the merge window closes.

> Things might also get a little messy if we are seeing a lot
> of other platforms beside VIA VT8500 use UHCI, but I think that
> is rather unlikely.

Indeed.  UHCI is the oldest of the host controller standards; people
aren't about to start creating a whole bunch of new implementations of 
it.  Even Intel no longer uses UHCI on their more recent motherboards.

Alan Stern

Re: [PATCH, RFC 16/22] USB: UHCI: clarify Kconfig dependencies

[Arnd Bergmann]

On Thursday 02 May 2013, Alan Stern wrote:
> On Thu, 2 May 2013, Arnd Bergmann wrote:
> 
> > > What do you think of my patch as compared to yours? 
> > 
> > I think in the end it comes down to the question where you want to
> > head with your driver. The way I did my version was going towards
> > making it similar to EHCI, with stand-alone bus glue drivers
> > and a core that is just a library module but does not register
> > a device_driver by itself.
> > 
> > Given that there are just three bus glues from UHCI, and at most
> > two of them enabled at the same time, I don't see a direct need
> > for UHCI to go down the same route as EHCI. If you want to just
> > leave this driver alone, your patch is simpler and has the same
> > effect in the end. Otherwise I think my patch avoids changing it
> > all again once the driver gets reworked.
> 
> Okay then, I'll submit my patch to Greg after the merge window closes.

Ok, thanks!

	Arnd

[PATCH, RFC 17/22] USB: OHCI: clarify Kconfig dependencies

[Arnd Bergmann]

The OHCI driver currently gives a build error if the base driver is
enabled but none of its bus glues are turned on:

drivers/usb/host/ohci-hcd.c:1209:2: error:
 #error "missing bus glue for ohci-hcd"  #error "missing bus glue for ohci-hcd"

A better solution for this is to change the Kconfig statements to
prevent getting into this situation. This adds a new USB_UHCI_CORE
symbol in Kconfig, which is selected by each of the bus glues.
This way, the driver never gets built if all of them are disabled.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/usb/host/Kconfig    | 29 +++++++++++++++++++++++++++++
 drivers/usb/host/Makefile   |  2 +-
 drivers/usb/host/ohci-hcd.c | 19 -------------------
 3 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 656af4d..46d1b9e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -368,9 +368,30 @@ config USB_OHCI_HCD
 
 if USB_OHCI_HCD
 
+config USB_OHCI_CORE
+	tristate
+	depends on USB_OHCI_HCD
+	default y if PCI
+	default y if ARCH_SA1100 && SA1111
+	default y if ARCH_S3C24XX
+	default y if ARCH_S3C64XX
+	default y if PXA27x
+	default y if PXA3xx
+	default y if ARCH_EP93XX
+	default y if ARCH_AT91
+	default y if ARCH_LPC32XX
+	default y if ARCH_DAVINCI_DA8XX
+	default y if PLAT_SPEAR
+	default y if PPC_PS3
+	default y if MFD_SM501
+	default y if MFD_TC6393XB
+	default y if MACH_JZ4740
+	default y if TILE_USB
+
 config USB_OHCI_HCD_OMAP1
 	bool "OHCI support for OMAP1/2 chips"
 	depends on ARCH_OMAP1
+	select USB_OHCI_CORE
 	default y
 	---help---
 	  Enables support for the OHCI controller on OMAP1/2 chips.
@@ -378,6 +399,7 @@ config USB_OHCI_HCD_OMAP1
 config USB_OHCI_HCD_OMAP3
 	bool "OHCI support for OMAP3 and later chips"
 	depends on (ARCH_OMAP3 || ARCH_OMAP4)
+	select USB_OHCI_CORE
 	default y
 	---help---
 	  Enables support for the on-chip OHCI controller on
@@ -398,6 +420,7 @@ config USB_OHCI_ATH79
 config USB_OHCI_HCD_PPC_OF_BE
 	bool "OHCI support for OF platform bus (big endian)"
 	depends on PPC_OF
+	select USB_OHCI_CORE
 	select USB_OHCI_BIG_ENDIAN_DESC
 	select USB_OHCI_BIG_ENDIAN_MMIO
 	---help---
@@ -407,6 +430,7 @@ config USB_OHCI_HCD_PPC_OF_BE
 config USB_OHCI_HCD_PPC_OF_LE
 	bool "OHCI support for OF platform bus (little endian)"
 	depends on PPC_OF
+	select USB_OHCI_CORE
 	select USB_OHCI_LITTLE_ENDIAN
 	---help---
 	  Enables support for little-endian USB controllers present on the
@@ -421,6 +445,7 @@ config USB_OHCI_HCD_PCI
 	bool "OHCI support for PCI-bus USB controllers"
 	depends on PCI && (STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF)
 	default y
+	select USB_OHCI_CORE
 	select USB_OHCI_LITTLE_ENDIAN
 	---help---
 	  Enables support for PCI-bus plug-in USB controller cards.
@@ -458,6 +483,7 @@ config USB_OHCI_SH
 config USB_OHCI_EXYNOS
 	boolean "OHCI support for Samsung EXYNOS SoC Series"
 	depends on ARCH_EXYNOS
+	select USB_OHCI_CORE
 	help
 	 Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
 
@@ -465,6 +491,7 @@ config USB_CNS3XXX_OHCI
 	bool "Cavium CNS3XXX OHCI Module (DEPRECATED)"
 	depends on ARCH_CNS3XXX
 	select USB_OHCI_HCD_PLATFORM
+	select USB_OHCI_CORE
 	---help---
 	  This option is deprecated now and the driver was removed, use
 	  USB_OHCI_HCD_PLATFORM instead.
@@ -475,6 +502,7 @@ config USB_CNS3XXX_OHCI
 config USB_OHCI_HCD_PLATFORM
 	bool "Generic OHCI driver for a platform device"
 	default n
+	select USB_OHCI_CORE
 	---help---
 	  Adds an OHCI host driver for a generic platform device, which
 	  provides a memory space and an irq.
@@ -487,6 +515,7 @@ config USB_OCTEON_OHCI
 	default USB_OCTEON_EHCI
 	select USB_OHCI_BIG_ENDIAN_MMIO
 	select USB_OHCI_LITTLE_ENDIAN
+	select USB_OHCI_CORE
 	help
 	  Enable support for the Octeon II SOC's on-chip OHCI
 	  controller.  It is needed for low-speed USB 1.0 device
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 1441d42..2697bd9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -37,7 +37,7 @@ obj-$(CONFIG_USB_EHCI_MSM)	+= ehci-msm.o
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
 obj-$(CONFIG_USB_ISP1362_HCD)	+= isp1362-hcd.o
-obj-$(CONFIG_USB_OHCI_HCD)	+= ohci-hcd.o
+obj-$(CONFIG_USB_OHCI_CORE)	+= ohci-hcd.o
 obj-$(CONFIG_USB_UHCI_CORE)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
 obj-$(CONFIG_USB_XHCI_HCD)	+= xhci-hcd.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 9e6de95..2bb1b06 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1190,25 +1190,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		ohci_platform_driver
 #endif
 
-#if	!defined(PCI_DRIVER) &&		\
-	!defined(PLATFORM_DRIVER) &&	\
-	!defined(OMAP1_PLATFORM_DRIVER) &&	\
-	!defined(OMAP3_PLATFORM_DRIVER) &&	\
-	!defined(OF_PLATFORM_DRIVER) &&	\
-	!defined(SA1111_DRIVER) &&	\
-	!defined(PS3_SYSTEM_BUS_DRIVER) && \
-	!defined(SM501_OHCI_DRIVER) && \
-	!defined(TMIO_OHCI_DRIVER) && \
-	!defined(S3C2410_PLATFORM_DRIVER) && \
-	!defined(EXYNOS_PLATFORM_DRIVER) && \
-	!defined(EP93XX_PLATFORM_DRIVER) && \
-	!defined(AT91_PLATFORM_DRIVER) && \
-	!defined(NXP_PLATFORM_DRIVER) && \
-	!defined(DAVINCI_PLATFORM_DRIVER) && \
-	!defined(SPEAR_PLATFORM_DRIVER)
-#error "missing bus glue for ohci-hcd"
-#endif
-
 static int __init ohci_hcd_mod_init(void)
 {
 	int retval = 0;
-- 
1.8.1.2

[PATCH, RFC 18/22] Xen: SWIOTLB is only used on x86

[Arnd Bergmann]

Enabling SWIOTLB_XEN on ARM results in build errors because the
underlying SWIOTLB is only available on X86:

drivers/xen/swiotlb-xen.c: In function 'is_xen_swiotlb_buffer':
drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/xen/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index dd4d9cb..f03bf50 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -141,7 +141,7 @@ config XEN_GRANT_DEV_ALLOC
 
 config SWIOTLB_XEN
 	def_bool y
-	depends on PCI
+	depends on PCI && X86
 	select SWIOTLB
 
 config XEN_TMEM
-- 
1.8.1.2

Re: [PATCH, RFC 18/22] Xen: SWIOTLB is only used on x86

[Stefano Stabellini]

On Thu, 2 May 2013, Arnd Bergmann wrote:
> Enabling SWIOTLB_XEN on ARM results in build errors because the
> underlying SWIOTLB is only available on X86:
> 
> drivers/xen/swiotlb-xen.c: In function 'is_xen_swiotlb_buffer':
> drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn
> 
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  drivers/xen/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index dd4d9cb..f03bf50 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -141,7 +141,7 @@ config XEN_GRANT_DEV_ALLOC
>  
>  config SWIOTLB_XEN
>  	def_bool y
> -	depends on PCI
> +	depends on PCI && X86
>  	select SWIOTLB
>  
>  config XEN_TMEM
> -- 
> 1.8.1.2
> 

Re: [PATCH, RFC 18/22] Xen: SWIOTLB is only used on x86

[Konrad Rzeszutek Wilk]

On Thu, May 02, 2013 at 04:38:50PM +0100, Stefano Stabellini wrote:
> On Thu, 2 May 2013, Arnd Bergmann wrote:
> > Enabling SWIOTLB_XEN on ARM results in build errors because the
> > underlying SWIOTLB is only available on X86:
> > 
> > drivers/xen/swiotlb-xen.c: In function 'is_xen_swiotlb_buffer':
> > drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn
> > 
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked as well. Should I pull this in or Arnd are you OK with taking
with my our Acks?

Thanks.
> 
> 
> >  drivers/xen/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index dd4d9cb..f03bf50 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -141,7 +141,7 @@ config XEN_GRANT_DEV_ALLOC
> >  
> >  config SWIOTLB_XEN
> >  	def_bool y
> > -	depends on PCI
> > +	depends on PCI && X86
> >  	select SWIOTLB
> >  
> >  config XEN_TMEM
> > -- 
> > 1.8.1.2
> > 

Re: [PATCH, RFC 18/22] Xen: SWIOTLB is only used on x86

[Arnd Bergmann]

On Thursday 02 May 2013, Konrad Rzeszutek Wilk wrote:
> On Thu, May 02, 2013 at 04:38:50PM +0100, Stefano Stabellini wrote:
> > On Thu, 2 May 2013, Arnd Bergmann wrote:
> > > Enabling SWIOTLB_XEN on ARM results in build errors because the
> > > underlying SWIOTLB is only available on X86:
> > > 
> > > drivers/xen/swiotlb-xen.c: In function 'is_xen_swiotlb_buffer':
> > > drivers/xen/swiotlb-xen.c:105:2: error: implicit declaration of function 'mfn_to_local_pfn
> > > 
> > > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked as well. Should I pull this in or Arnd are you OK with taking
> with my our Acks?

I'd prefer you to take it through your tree.

Thanks,

	Arnd

[PATCH, RFC 19/22] staging/solo6x10: depend on CONFIG_FONTS

[Arnd Bergmann]

The new SOLO6X10 driver needs the built-in console fonts, specifically
the VGA8x16 font and building it without console support results in
a link error error.

drivers/built-in.o: In function `solo_osd_print':
 :(.text+0x7d3424): undefined reference to `find_font'

This adds a dependency on the CONFIG_FONTS symbol and changes the
console code to always build the base driver even if there are
no specific fonts built-in.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/staging/media/solo6x10/Kconfig | 1 +
 drivers/video/console/Makefile         | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig
index ec32776..df6569b 100644
--- a/drivers/staging/media/solo6x10/Kconfig
+++ b/drivers/staging/media/solo6x10/Kconfig
@@ -1,6 +1,7 @@
 config SOLO6X10
 	tristate "Softlogic 6x10 MPEG codec cards"
 	depends on PCI && VIDEO_DEV && SND && I2C
+	depends on FONTS
 	select VIDEOBUF2_DMA_SG
 	select VIDEOBUF2_DMA_CONTIG
 	select SND_PCM
diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
index a862e91..48da25c 100644
--- a/drivers/video/console/Makefile
+++ b/drivers/video/console/Makefile
@@ -18,6 +18,8 @@ font-objs-$(CONFIG_FONT_MINI_4x6)  += font_mini_4x6.o
 
 font-objs += $(font-objs-y)
 
+obj-$(CONFIG_FONTS) += font.o
+
 # Each configuration option enables a list of files.
 
 obj-$(CONFIG_DUMMY_CONSOLE)       += dummycon.o
-- 
1.8.1.2

Re: [PATCH, RFC 19/22] staging/solo6x10: depend on CONFIG_FONTS

[Geert Uytterhoeven]

On Thu, May 2, 2013 at 5:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The new SOLO6X10 driver needs the built-in console fonts, specifically
> the VGA8x16 font and building it without console support results in
> a link error error.
>
> drivers/built-in.o: In function `solo_osd_print':
>  :(.text+0x7d3424): undefined reference to `find_font'
>
> This adds a dependency on the CONFIG_FONTS symbol and changes the
> console code to always build the base driver even if there are
> no specific fonts built-in.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Sorry for only noticing this now, but CONFIG_FONTS is not about font support.
It's about allowing the user to override the default list of builtin fonts.
I know it's a bad name, but changing this would break make oldconfig.
Or is this allowed?

My fix for the solo6x10 build breakage is
http://marc.info/?l=linux-kernel&m=136861809223875

> ---
>  drivers/staging/media/solo6x10/Kconfig | 1 +
>  drivers/video/console/Makefile         | 2 ++
>  2 files changed, 3 insertions(+)
>
> diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig
> index ec32776..df6569b 100644
> --- a/drivers/staging/media/solo6x10/Kconfig
> +++ b/drivers/staging/media/solo6x10/Kconfig
> @@ -1,6 +1,7 @@
>  config SOLO6X10
>         tristate "Softlogic 6x10 MPEG codec cards"
>         depends on PCI && VIDEO_DEV && SND && I2C
> +       depends on FONTS
>         select VIDEOBUF2_DMA_SG
>         select VIDEOBUF2_DMA_CONTIG
>         select SND_PCM
> diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
> index a862e91..48da25c 100644
> --- a/drivers/video/console/Makefile
> +++ b/drivers/video/console/Makefile
> @@ -18,6 +18,8 @@ font-objs-$(CONFIG_FONT_MINI_4x6)  += font_mini_4x6.o
>
>  font-objs += $(font-objs-y)
>
> +obj-$(CONFIG_FONTS) += font.o
> +
>  # Each configuration option enables a list of files.
>
>  obj-$(CONFIG_DUMMY_CONSOLE)       += dummycon.o

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, RFC 19/22] staging/solo6x10: depend on CONFIG_FONTS

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> Sorry for only noticing this now, but CONFIG_FONTS is not about font support.
> It's about allowing the user to override the default list of builtin fonts.
> I know it's a bad name, but changing this would break make oldconfig.
> Or is this allowed?
> 
> My fix for the solo6x10 build breakage is
> http://marc.info/?l=linux-kernel&m=136861809223875

Right, that sounds like a better solution.

	Arnd

[PATCH, RFC 20/22] media: coda: select GENERIC_ALLOCATOR

[Arnd Bergmann]

The coda driver uses the generic allocator to get at the
"iram" memory, so add the necessary dependency to avoid:

drivers/built-in.o: In function `coda_remove':
 :(.text+0x2ab680): undefined reference to `gen_pool_free'
drivers/built-in.o: In function `coda_probe':
:(.text+0x2ad168): undefined reference to `of_get_named_gen_pool'
:(.text+0x2ad188): undefined reference to `dev_get_gen_pool'
:(.text+0x2ad220): undefined reference to `gen_pool_alloc'
:(.text+0x2ad2ec): undefined reference to `gen_pool_virt_to_phys'

Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/media/platform/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0494d27..4608d03 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -145,6 +145,7 @@ config VIDEO_CODA
 	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
 	select VIDEOBUF2_DMA_CONTIG
 	select V4L2_MEM2MEM_DEV
+	select GENERIC_ALLOCATOR
 	---help---
 	   Coda is a range of video codec IPs that supports
 	   H.264, MPEG-4, and other video formats.
-- 
1.8.1.2

Re: [PATCH, RFC 20/22] media: coda: select GENERIC_ALLOCATOR

[Alexander Shiyan]

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

> The coda driver uses the generic allocator to get at the
> "iram" memory, so add the necessary dependency to avoid:
> 
> drivers/built-in.o: In function `coda_remove':
>  :(.text+0x2ab680): undefined reference to `gen_pool_free'
> drivers/built-in.o: In function `coda_probe':
> :(.text+0x2ad168): undefined reference to `of_get_named_gen_pool'
> :(.text+0x2ad188): undefined reference to `dev_get_gen_pool'
> :(.text+0x2ad220): undefined reference to `gen_pool_alloc'
> :(.text+0x2ad2ec): undefined reference to `gen_pool_virt_to_phys'
> 
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/media/platform/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 0494d27..4608d03 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -145,6 +145,7 @@ config VIDEO_CODA
>  	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
>  	select VIDEOBUF2_DMA_CONTIG
>  	select V4L2_MEM2MEM_DEV
> +	select GENERIC_ALLOCATOR
>  	---help---
>  	   Coda is a range of video codec IPs that supports
>  	   H.264, MPEG-4, and other video formats.

Again?

---
ÿôèº{.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, RFC 20/22] media: coda: select GENERIC_ALLOCATOR

[Arnd Bergmann]

On Thursday 02 May 2013, Alexander Shiyan wrote:
> > The coda driver uses the generic allocator to get at the
> > "iram" memory, so add the necessary dependency to avoid:
> > 

> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 0494d27..4608d03 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -145,6 +145,7 @@ config VIDEO_CODA
> >       depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> >       select VIDEOBUF2_DMA_CONTIG
> >       select V4L2_MEM2MEM_DEV
> > +     select GENERIC_ALLOCATOR
> >       ---help---
> >          Coda is a range of video codec IPs that supports
> >          H.264, MPEG-4, and other video formats.
> 
> Again?
> 

Ah, now I remember where I saw this before -- you sent the same patch, and
Fabio commented that Shawn had already queued up a different solution.

Unfortunately, linux-next as of today is still broken. Shawn, did I
miss a pull request from you?

	Arnd

Re: [PATCH, RFC 20/22] media: coda: select GENERIC_ALLOCATOR

[Shawn Guo]

On Thu, May 02, 2013 at 09:53:19PM +0200, Arnd Bergmann wrote:
> Unfortunately, linux-next as of today is still broken. Shawn, did I
> miss a pull request from you?

No, I haven't sent you a pull request for that.  I have queued it for
3.10-rc but am still waiting for a stable base (3.10-rc1 where
coda and genalloc changes should be merged together) to send it out.

Shawn

[PATCH, RFC 21/22] davinci: vpfe_capture needs i2c

[Arnd Bergmann]

The vpfe_capture driver is implicitly built for three of the davinci
capture drivers but depends on i2c, so we need to add the dependency
in Kconfig for each driver using this.

 drivers/media/platform/davinci/vpfe_capture.c: In function 'vpfe_probe':
 drivers/media/platform/davinci/vpfe_capture.c:1934:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration]
 drivers/media/platform/davinci/vpfe_capture.c:1934:11: warning: assignment makes pointer from integer without a cast [enabled by default]

Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/media/platform/davinci/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/davinci/Kconfig b/drivers/media/platform/davinci/Kconfig
index afb3aec..02da88b 100644
--- a/drivers/media/platform/davinci/Kconfig
+++ b/drivers/media/platform/davinci/Kconfig
@@ -27,6 +27,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE
 config VIDEO_DM6446_CCDC
 	tristate "TI DM6446 CCDC video capture driver"
 	depends on VIDEO_V4L2 && (ARCH_DAVINCI || ARCH_OMAP3)
+	depends on I2C
 	select VIDEOBUF_DMA_CONTIG
 	help
 	   Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces
@@ -41,6 +42,7 @@ config VIDEO_DM6446_CCDC
 config VIDEO_DM355_CCDC
 	tristate "TI DM355 CCDC video capture driver"
 	depends on VIDEO_V4L2 && ARCH_DAVINCI
+	depends on I2C
 	select VIDEOBUF_DMA_CONTIG
 	help
 	   Enables DM355 CCD hw module. DM355 CCDC hw interfaces
@@ -55,6 +57,7 @@ config VIDEO_DM355_CCDC
 config VIDEO_DM365_ISIF
 	tristate "TI DM365 ISIF video capture driver"
 	depends on VIDEO_V4L2 && ARCH_DAVINCI
+	depends on I2C
 	select VIDEOBUF_DMA_CONTIG
 	help
 	   Enables ISIF hw module. This is the hardware module for
-- 
1.8.1.2

Re: [PATCH, RFC 21/22] davinci: vpfe_capture needs i2c

[Prabhakar Lad]

Hi Arnd,

Thanks for the patch.

On Thu, May 2, 2013 at 8:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The vpfe_capture driver is implicitly built for three of the davinci
> capture drivers but depends on i2c, so we need to add the dependency
> in Kconfig for each driver using this.
>
>  drivers/media/platform/davinci/vpfe_capture.c: In function 'vpfe_probe':
>  drivers/media/platform/davinci/vpfe_capture.c:1934:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration]
>  drivers/media/platform/davinci/vpfe_capture.c:1934:11: warning: assignment makes pointer from integer without a cast [enabled by default]
>
> Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

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

Regards,
--Prabhakar Lad

[PATCH, RFC 22/22] radio-si4713: depend on SND_SOC

[Arnd Bergmann]

It is not possible to select SND_SOC_SI476X if we have not also
enabled SND_SOC.

warning: (RADIO_SI476X) selects SND_SOC_SI476X which has unmet
	 direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC)

Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/media/radio/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index c0beee2..d529ba7 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -22,6 +22,7 @@ config RADIO_SI476X
 	tristate "Silicon Laboratories Si476x I2C FM Radio"
 	depends on I2C && VIDEO_V4L2
 	depends on MFD_SI476X_CORE
+	depends on SND_SOC
 	select SND_SOC_SI476X
 	---help---
 	  Choose Y here if you have this FM radio chip.
-- 
1.8.1.2

Re: [PATCH, RFC 22/22] radio-si4713: depend on SND_SOC

[edubezval]

Arnd,

On Thu, May 2, 2013 at 11:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> It is not possible to select SND_SOC_SI476X if we have not also
> enabled SND_SOC.
>
> warning: (RADIO_SI476X) selects SND_SOC_SI476X which has unmet
>          direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC)
>
> Cc: Hans Verkuil <hverkuil@xs4all.nl>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---

Note on your patch title, this change is against si476X, not on *si4713*.



>  drivers/media/radio/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> index c0beee2..d529ba7 100644
> --- a/drivers/media/radio/Kconfig
> +++ b/drivers/media/radio/Kconfig
> @@ -22,6 +22,7 @@ config RADIO_SI476X
>         tristate "Silicon Laboratories Si476x I2C FM Radio"
>         depends on I2C && VIDEO_V4L2
>         depends on MFD_SI476X_CORE
> +       depends on SND_SOC
>         select SND_SOC_SI476X
>         ---help---
>           Choose Y here if you have this FM radio chip.
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Eduardo Bezerra Valentin

Re: [PATCH, RFC 22/22] radio-si4713: depend on SND_SOC

[Arnd Bergmann]

On Thursday 02 May 2013, edubezval@gmail.com wrote:
> On Thu, May 2, 2013 at 11:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > It is not possible to select SND_SOC_SI476X if we have not also
> > enabled SND_SOC.
> >
> > warning: (RADIO_SI476X) selects SND_SOC_SI476X which has unmet
> >          direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC)
> >
> > Cc: Hans Verkuil <hverkuil@xs4all.nl>
> > Cc: linux-media@vger.kernel.org
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> 
> Note on your patch title, this change is against si476X, not on *si4713*.
> 

Sorry about that, I must have copied the wrong prefix from an older patch
then. I'll fix it up locally in case I need to resend.

	Arnd

Re: [PATCH, RFC 22/22] radio-si4713: depend on SND_SOC

[Mauro Carvalho Chehab]

Em 02-05-2013 12:16, Arnd Bergmann escreveu:
> It is not possible to select SND_SOC_SI476X if we have not also
> enabled SND_SOC.
>
> warning: (RADIO_SI476X) selects SND_SOC_SI476X which has unmet
> 	 direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC)
>
> Cc: Hans Verkuil <hverkuil@xs4all.nl>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>   drivers/media/radio/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> index c0beee2..d529ba7 100644
> --- a/drivers/media/radio/Kconfig
> +++ b/drivers/media/radio/Kconfig
> @@ -22,6 +22,7 @@ config RADIO_SI476X
>   	tristate "Silicon Laboratories Si476x I2C FM Radio"
>   	depends on I2C && VIDEO_V4L2
>   	depends on MFD_SI476X_CORE
> +	depends on SND_SOC
>   	select SND_SOC_SI476X
>   	---help---
>   	  Choose Y here if you have this FM radio chip.
>

Do you prefer to send it via your tree or via mine? Either way works for me.

If you're willing to send it via your tree:

Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Re: [PATCH, RFC 22/22] radio-si4713: depend on SND_SOC

[Arnd Bergmann]

On Thursday 02 May 2013, Mauro Carvalho Chehab wrote:
> Do you prefer to send it via your tree or via mine? Either way works for me.
> 
> If you're willing to send it via your tree:
> 
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

I'd prefer your tree, because the patch does not apply on 3.9.

	Arnd

Re: [PATCH, RFC 00/22] ARM randconfig bugs

[Rafael J. Wysocki]

On Thursday, May 02, 2013 05:16:04 PM Arnd Bergmann wrote:
> Hi subsystem maintainers,
> 
> This is a set of patches to to fix build errors I hit while trying to
> build lots of randconfig kernels on linux-next.
> 
> Most of them are simple missing dependencies in Kconfig, but some are
> more substantial. I would like to see at least the obvious patches
> get merged for 3.10. If you are happy with the patches, feel free
> to apply them directly, otherwise please provide feedback.
> 
> No single patch out of these is very important though, most of them
> only concern corner cases and don't matter in practice.

For cpufreq and cpuidle:

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

> Arnd Bergmann (22):
>   can: move CONFIG_HAVE_CAN_FLEXCAN out of CAN_DEV
>   cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY
>   cpuidle: calxeda: select ARM_CPU_SUSPEND
>   staging/drm: imx: add missing dependencies
>   drm: always provide debugfs function prototypes
>   gpu/drm: host1x: add dependency on Tegra
>   drm/tilcd: select BACKLIGHT_LCD_SUPPORT
>   OMAPDSS: DPI needs DSI
>   crypto: lz4: don't build on ARM
>   mfd: ab8500: debugfs code depends on gpadc
>   iwlegacy: il_pm_ops is only provided for PM_SLEEP
>   thermal: cpu_cooling: fix stub function
>   staging/logger: use kuid_t internally
>   oprofile: always enable IRQ_WORK
>   USB: EHCI: remove bogus #error
>   USB: UHCI: clarify Kconfig dependencies
>   USB: OHCI: clarify Kconfig dependencies
>   Xen: SWIOTLB is only used on x86
>   staging/solo6x10: depend on CONFIG_FONTS
>   media: coda: select GENERIC_ALLOCATOR
>   davinci: vpfe_capture needs i2c
>   radio-si4713: depend on SND_SOC
> 
>  arch/Kconfig                           |  1 +
>  crypto/Kconfig                         |  2 ++
>  drivers/cpufreq/Kconfig.arm            |  1 +
>  drivers/cpuidle/Kconfig                |  1 +
>  drivers/gpu/drm/tilcdc/Kconfig         |  1 +
>  drivers/gpu/host1x/drm/Kconfig         |  1 +
>  drivers/media/platform/Kconfig         |  1 +
>  drivers/media/platform/davinci/Kconfig |  3 ++
>  drivers/media/radio/Kconfig            |  1 +
>  drivers/mfd/Kconfig                    |  2 +-
>  drivers/net/can/Kconfig                |  6 ++--
>  drivers/net/wireless/iwlegacy/common.h |  2 +-
>  drivers/staging/android/logger.c       |  4 +--
>  drivers/staging/android/logger.h       |  2 +-
>  drivers/staging/imx-drm/Kconfig        |  4 +++
>  drivers/staging/media/solo6x10/Kconfig |  1 +
>  drivers/usb/host/Kconfig               | 65 +++++++++++++++++++++++++++++-----
>  drivers/usb/host/Makefile              |  4 +--
>  drivers/usb/host/ehci-hcd.c            | 17 ---------
>  drivers/usb/host/ohci-hcd.c            | 19 ----------
>  drivers/usb/host/uhci-hcd.c            |  4 +--
>  drivers/video/console/Makefile         |  2 ++
>  drivers/video/omap2/dss/Kconfig        |  1 +
>  drivers/xen/Kconfig                    |  2 +-
>  include/drm/drmP.h                     |  3 +-
>  include/linux/cpu_cooling.h            |  2 +-
>  26 files changed, 91 insertions(+), 61 deletions(-)
> 
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re : [PATCH, RFC 09/22] crypto: lz4: don't build on ARM

[Chanho Min]

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


>It is not currently possible to build the LZ4 code on ARM, so let's
>remove that option in Kconfig for now.
>
>lib/built-in.o: In function `lz4_compress64kctx':
> lib/lz4/lz4_compress.c:339: undefined reference to `__ctzsi2'
>lib/built-in.o: In function `lz4_compressctx':
> lib/lz4/lz4_compress.c:157: undefined reference to `__ctzsi2'
>lib/built-in.o: In function `lz4hc_commonlength':
> lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
> lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
>lib/built-in.o: In function `lz4hc_insertandgetwidermatch':
> lib/lz4/lz4hc_compress.c:230: undefined reference to `__ctzsi2'

Please, let me know the gcc version and tested defconfig.
I didn't have any problem to build with gcc 4.6.4 on armv7.
Some architecture need libgcc functions for __builtin_clz/ctz.
Porting them to lib is in progress:
http://marc.info/?l=linux-kernel&m=136748861811956&w=2
But, It doesn't happen on ARM, PowerPC and x86.

Thanks
Chanho Min

[-- Attachment #2: mime.txt --]
[-- Type: application/octet-stream, Size: 1378 bytes --]

It is not currently possible to build the LZ4 code on ARM, so let's
remove that option in Kconfig for now.

lib/built-in.o: In function `lz4_compress64kctx':
 lib/lz4/lz4_compress.c:339: undefined reference to `__ctzsi2'
lib/built-in.o: In function `lz4_compressctx':
 lib/lz4/lz4_compress.c:157: undefined reference to `__ctzsi2'
lib/built-in.o: In function `lz4hc_commonlength':
 lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
 lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
lib/built-in.o: In function `lz4hc_insertandgetwidermatch':
 lib/lz4/lz4hc_compress.c:230: undefined reference to `__ctzsi2'

Cc: Chanho Min <chanho.min@lge.com>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 crypto/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index aa3a349..1cd134b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1361,6 +1361,7 @@ config CRYPTO_842
 
 config CRYPTO_LZ4
 	tristate "LZ4 compression algorithm"
+	depends on !ARM
 	select CRYPTO_ALGAPI
 	select LZ4_COMPRESS
 	select LZ4_DECOMPRESS
@@ -1369,6 +1370,7 @@ config CRYPTO_LZ4
 
 config CRYPTO_LZ4HC
 	tristate "LZ4HC compression algorithm"
+	depends on !ARM
 	select CRYPTO_ALGAPI
 	select LZ4HC_COMPRESS
 	select LZ4_DECOMPRESS
-- 
1.8.1.2

Re: Re : [PATCH, RFC 09/22] crypto: lz4: don't build on ARM

[Arnd Bergmann]

On Friday 03 May 2013, Chanho Min wrote:
> >It is not currently possible to build the LZ4 code on ARM, so let's
> >remove that option in Kconfig for now.
> >
> >lib/built-in.o: In function `lz4_compress64kctx':
> > lib/lz4/lz4_compress.c:339: undefined reference to `__ctzsi2'
> >lib/built-in.o: In function `lz4_compressctx':
> > lib/lz4/lz4_compress.c:157: undefined reference to `__ctzsi2'
> >lib/built-in.o: In function `lz4hc_commonlength':
> > lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
> > lib/lz4/lz4hc_compress.c:102: undefined reference to `__ctzsi2'
> >lib/built-in.o: In function `lz4hc_insertandgetwidermatch':
> > lib/lz4/lz4hc_compress.c:230: undefined reference to `__ctzsi2'
> 
> Please, let me know the gcc version and tested defconfig.
> I didn't have any problem to build with gcc 4.6.4 on armv7.
> Some architecture need libgcc functions for __builtin_clz/ctz.
> Porting them to lib is in progress:
> http://marc.info/?l=linux-kernel&m=136748861811956&w=2
> But, It doesn't happen on ARM, PowerPC and x86.

I tested with gcc-4.8 and random configurations. I've tried it
again now and can't reproduce it at the moment. I'll try building
more random configurations until I have nailed down the problem.

Sorry about this, I should have been more careful about my
original conclusion here.

	Arnd