2013-05-02 15:17:23

by Arnd Bergmann

[permalink] [raw]
Subject: [PATCH, RFC 00/22] ARM randconfig bugs

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 <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: John W. Linville <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Oliver Hartkopp <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Robert Richter <[email protected]>
Cc: Samuel Ortiz <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: Zhang Rui <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]


2013-05-02 15:16:24

by Arnd Bergmann

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

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 <[email protected]>
Cc: Stefano Stabellini <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:33

by Arnd Bergmann

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

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 <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:40

by Arnd Bergmann

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

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 <[email protected]>
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:46

by Arnd Bergmann

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

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 <[email protected]>
Cc: [email protected]
Cc: Dave Airlie <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:50

by Arnd Bergmann

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

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 <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Philippe LANGLAIS <[email protected]>
Cc: Samuel Ortiz <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:58

by Arnd Bergmann

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

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 <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:53

by Arnd Bergmann

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

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 <[email protected]>
Cc: Zhang Rui <[email protected]>
Cc: Amit Daniel kachhap <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:56

by Arnd Bergmann

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

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 <[email protected]>
Cc: Herbert Xu <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:17:41

by Arnd Bergmann

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

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 <[email protected]>
Cc: John W. Linville <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:18:18

by Arnd Bergmann

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

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 <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Philipp Zabel <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:18:16

by Arnd Bergmann

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

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 <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:19:29

by Arnd Bergmann

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

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 <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:39

by Arnd Bergmann

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

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 <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:31

by Arnd Bergmann

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

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 <[email protected]>
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:22

by Arnd Bergmann

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

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 <[email protected]>
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:20:30

by Arnd Bergmann

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

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 <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:19

by Arnd Bergmann

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

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 <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:20:53

by Arnd Bergmann

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

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 <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:21:16

by Arnd Bergmann

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

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 <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:16:17

by Arnd Bergmann

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

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 <[email protected]>
Cc: Dave Airlie <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:21:55

by Arnd Bergmann

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

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

2013-05-02 15:16:16

by Arnd Bergmann

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

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 <[email protected]>
Cc: Arto Merilainen <[email protected]>
Cc: Terje Bergstrom <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
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

2013-05-02 15:24:21

by Eduardo Valentin

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

Arnd,

On Thu, May 2, 2013 at 11:16 AM, Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---

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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html



--
Eduardo Bezerra Valentin

2013-05-02 15:36:30

by Lee Jones

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

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 <[email protected]>
> Cc: Lee Jones <[email protected]>
> Cc: Philippe LANGLAIS <[email protected]>
> Cc: Samuel Ortiz <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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

2013-05-02 15:38:58

by Stefano Stabellini

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

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 <[email protected]>
> Cc: Stefano Stabellini <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>

Acked-by: Stefano Stabellini <[email protected]>


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

2013-05-02 15:43:09

by Tomi Valkeinen

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

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



Attachments:
signature.asc (901.00 B)
OpenPGP digital signature

2013-05-02 15:46:59

by Eduardo Valentin

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

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 <[email protected]>
> Cc: Zhang Rui <[email protected]>
> Cc: Amit Daniel kachhap <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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;
> }
>



Attachments:
signature.asc (295.00 B)
OpenPGP digital signature

2013-05-02 16:24:27

by Arnd Bergmann

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

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

2013-05-02 16:25:39

by Arnd Bergmann

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

On Thursday 02 May 2013, [email protected] wrote:
> On Thu, May 2, 2013 at 11:16 AM, Arnd Bergmann <[email protected]> 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 <[email protected]>
> > Cc: [email protected]
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > ---
>
> 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

2013-05-02 16:27:10

by Arnd Bergmann

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

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

2013-05-02 16:30:30

by Arnd Bergmann

[permalink] [raw]
Subject: [PATCH v2] thermal: cpu_cooling: fix stub function

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 <[email protected]>
Cc: Zhang Rui <[email protected]>
Cc: Amit Daniel kachhap <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

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;
}

2013-05-02 16:55:14

by Eduardo Valentin

[permalink] [raw]
Subject: Re: [PATCH v2] thermal: cpu_cooling: fix stub function

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 <[email protected]>
> Cc: Zhang Rui <[email protected]>
> Cc: Amit Daniel kachhap <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>

Acked-by: Eduardo Valentin <[email protected]>

>
> 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;
> }
>
>
>

>



Attachments:
signature.asc (295.00 B)
OpenPGP digital signature

2013-05-02 17:21:35

by Alexander Shiyan

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

> 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 <[email protected]>
> Cc: Fabio Estevam <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?Ý¢j"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?

2013-05-02 17:30:21

by Alan Stern

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

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"

2013-05-02 17:34:56

by Alan Stern

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

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 <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>

Acked-by: Alan Stern <[email protected]>

2013-05-02 17:38:02

by Mauro Carvalho Chehab

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

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 <[email protected]>
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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 <[email protected]>

2013-05-02 17:52:43

by Arnd Bergmann

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

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

2013-05-02 17:55:37

by Arnd Bergmann

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

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

2013-05-02 17:58:00

by Arnd Bergmann

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

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

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

Arnd

2013-05-02 18:14:08

by Konrad Rzeszutek Wilk

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

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 <[email protected]>
> > Cc: Stefano Stabellini <[email protected]>
> > Signed-off-by: Arnd Bergmann <[email protected]>
>
> Acked-by: Stefano Stabellini <[email protected]>

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

2013-05-02 18:16:33

by Arnd Bergmann

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

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 <[email protected]>
> > > Cc: Stefano Stabellini <[email protected]>
> > > Signed-off-by: Arnd Bergmann <[email protected]>
> >
> > Acked-by: Stefano Stabellini <[email protected]>
>
> 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

2013-05-02 18:27:57

by Alan Stern

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

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

2013-05-02 18:45:35

by Rafael J. Wysocki

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

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

> 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.

2013-05-02 19:13:10

by Arnd Bergmann

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

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

2013-05-02 19:53:59

by Arnd Bergmann

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

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

2013-05-02 21:31:14

by Daniel Lezcano

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

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 <[email protected]>
> Cc: Daniel Lezcano <[email protected]>
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>

Acked-by: Daniel Lezcano <[email protected]>

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

2013-05-02 23:52:15

by Chanho Min

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


>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


Attachments:
mime.txt (1.35 kB)

2013-05-03 02:17:18

by Shawn Guo

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

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 <[email protected]>
> Cc: Shawn Guo <[email protected]>
> Cc: Philipp Zabel <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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
>

2013-05-03 02:34:00

by Shawn Guo

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

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

2013-05-03 04:51:48

by Viresh Kumar

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

On 2 May 2013 20:46, Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: Viresh Kumar <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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?

2013-05-03 09:53:52

by Marc Kleine-Budde

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

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 |


Attachments:
signature.asc (263.00 B)
OpenPGP digital signature

2013-05-03 11:00:53

by Prabhakar

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

Hi Arnd,

Thanks for the patch.

On Thu, May 2, 2013 at 8:46 PM, Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>

Acked-by: Lad, Prabhakar <[email protected]>

Regards,
--Prabhakar Lad

2013-05-03 11:53:38

by Robert Richter

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

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 <[email protected]>
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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
>

2013-05-03 12:07:41

by Rafael J. Wysocki

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

On Friday, May 03, 2013 10:21:45 AM Viresh Kumar wrote:
> On 2 May 2013 20:46, Arnd Bergmann <[email protected]> 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 <[email protected]>
> > Cc: Viresh Kumar <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > ---
> > 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.

2013-05-03 13:01:55

by Viresh Kumar

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

On 3 May 2013 17:45, Rafael J. Wysocki <[email protected]> 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..

2013-05-03 13:30:22

by Steven Rostedt

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

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


2013-05-03 13:45:44

by Thierry Reding

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

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 <[email protected]>
> Cc: Arto Merilainen <[email protected]>
> Cc: Terje Bergstrom <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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


Attachments:
(No filename) (1.80 kB)
(No filename) (836.00 B)
Download all attachments

2013-05-03 14:02:04

by Arnd Bergmann

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

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);

2013-05-03 15:14:58

by Steven Rostedt

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

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

2013-05-03 15:21:43

by Arnd Bergmann

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

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

2013-05-03 15:25:32

by Arnd Bergmann

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

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

2013-05-03 15:29:28

by Arnd Bergmann

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

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&amp;m=136748861811956&amp;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

2013-05-03 19:18:58

by Rafael J. Wysocki

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

On Friday, May 03, 2013 06:31:52 PM Viresh Kumar wrote:
> On 3 May 2013 17:45, Rafael J. Wysocki <[email protected]> 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.

2013-05-03 21:26:57

by Arnd Bergmann

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

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

2013-05-04 06:39:42

by Viresh Kumar

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

On 2 May 2013 20:46, Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: Viresh Kumar <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
---
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"


Attachments:
0001-cpufreq-ARM-big-LITTLE-Fix-Kconfig-entries.patch (1.82 kB)

2013-05-04 12:36:06

by Shawn Guo

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

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

2013-05-05 20:26:52

by Borislav Petkov

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

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 <[email protected]>
> Cc: John W. Linville <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> 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.
--

2013-05-07 09:19:03

by Marc Kleine-Budde

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

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 |


Attachments:
signature.asc (263.00 B)
OpenPGP digital signature

2013-05-07 21:42:12

by Rob Herring

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

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 <[email protected]>
> Cc: Daniel Lezcano <[email protected]>
> Cc: [email protected]
> Signed-off-by: Arnd Bergmann <[email protected]>

Acked-by: Rob Herring <[email protected]>

> ---
> 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.
>
>

2013-05-08 00:18:12

by Rafael J. Wysocki

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

On Saturday, May 04, 2013 12:09:40 PM Viresh Kumar wrote:
> On 2 May 2013 20:46, Arnd Bergmann <[email protected]> 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 <[email protected]>
> > Cc: Viresh Kumar <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > ---
> > 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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Viresh Kumar <[email protected]>

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.

2013-05-08 12:12:24

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH v2] thermal: cpu_cooling: fix stub function

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 <[email protected]>
> > Cc: Zhang Rui <[email protected]>
> > Cc: Amit Daniel kachhap <[email protected]>
> > Signed-off-by: Arnd Bergmann <[email protected]>
>
> Acked-by: Eduardo Valentin <[email protected]>

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

2013-05-23 20:15:41

by Geert Uytterhoeven

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

On Thu, May 2, 2013 at 5:16 PM, Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>

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

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

2013-05-23 21:47:56

by Arnd Bergmann

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

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&amp;m=136861809223875

Right, that sounds like a better solution.

Arnd