* [PATCH 8/8] drm/exynos: don't include plat/gpio-cfg.h
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
Patch 9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM"
allowed building the exynos hdmi driver on non-samsung platforms,
which unfortunately broke compilation in combination with 22c4f42897
"drm: exynos: hdmi: add support for exynos5 hdmi", which added
an inclusion of the samsung-specific plat/gpio-cfg.h header file.
Fortunately, that header file is not required any more here, so
we can simply revert the inclusion in order to build the ARM
allyesconfig again without getting this error:
drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rahul Sharma <rahul.sharma@samsung.com>
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..7f0fc4e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,6 @@
#include <linux/regulator/consumer.h>
#include <linux/io.h>
#include <linux/of_gpio.h>
-#include <plat/gpio-cfg.h>
#include <drm/exynos_drm.h>
--
1.7.10
^ permalink raw reply related
* [PATCH 7/8] ata: highbank: mark ahci_highbank_probe as __devinit
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
The ahci_highbank_probe function is incorrectly marked as __init,
which means it can get discarded at boot time, which might be
a problem if for some reason the device only becomes operational
after loading another module.
Using __devinit instead avoids seeing this warning for every build:
WARNING: vmlinux.o(.data+0xf7b0): Section mismatch in reference from the
variable ahci_highbank_driver to the function .init.text:ahci_highbank_probe()
The variable ahci_highbank_driver references
the function __init ahci_highbank_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Jeff Garzik <jgarzik@redhat.com>
---
drivers/ata/sata_highbank.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c
index 0d7c4c2..36a141a 100644
--- a/drivers/ata/sata_highbank.c
+++ b/drivers/ata/sata_highbank.c
@@ -260,7 +260,7 @@ static const struct of_device_id ahci_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
-static int __init ahci_highbank_probe(struct platform_device *pdev)
+static int __devinit ahci_highbank_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct ahci_host_priv *hpriv;
--
1.7.10
^ permalink raw reply related
* [PATCH 6/8] mmc: dw_mmc: constify dw_mci_idmac_ops in exynos back-end
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
The of_device_id match data is now marked as const and
must not be modified. This changes the dw_mmc to mark
all pointers passing the dw_mci_drv_data or dw_mci_dma_ops
structures as const, and also marks the static definitions
as const.
drivers/mmc/host/dw_mmc-exynos.c: In function 'dw_mci_exynos_probe':
drivers/mmc/host/dw_mmc-exynos.c:234:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Will Newton <will.newton@imgtec.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/host/dw_mmc-exynos.c | 6 +++---
drivers/mmc/host/dw_mmc-pltfm.c | 2 +-
drivers/mmc/host/dw_mmc-pltfm.h | 2 +-
drivers/mmc/host/dw_mmc.c | 2 +-
include/linux/mmc/dw_mmc.h | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 0147ac3a..4d50da6 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -208,7 +208,7 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
MMC_CAP_CMD23,
};
-static struct dw_mci_drv_data exynos5250_drv_data = {
+static const struct dw_mci_drv_data exynos5250_drv_data = {
.caps = exynos5250_dwmmc_caps,
.init = dw_mci_exynos_priv_init,
.setup_clock = dw_mci_exynos_setup_clock,
@@ -220,14 +220,14 @@ static struct dw_mci_drv_data exynos5250_drv_data = {
static const struct of_device_id dw_mci_exynos_match[] = {
{ .compatible = "samsung,exynos5250-dw-mshc",
- .data = (void *)&exynos5250_drv_data, },
+ .data = &exynos5250_drv_data, },
{},
};
MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
int dw_mci_exynos_probe(struct platform_device *pdev)
{
- struct dw_mci_drv_data *drv_data;
+ const struct dw_mci_drv_data *drv_data;
const struct of_device_id *match;
match = of_match_node(dw_mci_exynos_match, pdev->dev.of_node);
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c960ca7..5e33156 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -24,7 +24,7 @@
#include "dw_mmc.h"
int dw_mci_pltfm_register(struct platform_device *pdev,
- struct dw_mci_drv_data *drv_data)
+ const struct dw_mci_drv_data *drv_data)
{
struct dw_mci *host;
struct resource *regs;
diff --git a/drivers/mmc/host/dw_mmc-pltfm.h b/drivers/mmc/host/dw_mmc-pltfm.h
index 301f245..2ac37b8 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.h
+++ b/drivers/mmc/host/dw_mmc-pltfm.h
@@ -13,7 +13,7 @@
#define _DW_MMC_PLTFM_H_
extern int dw_mci_pltfm_register(struct platform_device *pdev,
- struct dw_mci_drv_data *drv_data);
+ const struct dw_mci_drv_data *drv_data);
extern int __devexit dw_mci_pltfm_remove(struct platform_device *pdev);
extern const struct dev_pm_ops dw_mci_pltfm_pmops;
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 250aa18..4f01f9f 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -434,7 +434,7 @@ static int dw_mci_idmac_init(struct dw_mci *host)
return 0;
}
-static struct dw_mci_dma_ops dw_mci_idmac_ops = {
+static const struct dw_mci_dma_ops dw_mci_idmac_ops = {
.init = dw_mci_idmac_init,
.start = dw_mci_idmac_start_dma,
.stop = dw_mci_idmac_stop_dma,
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 7c6a113..b611f32 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -137,7 +137,7 @@ struct dw_mci {
dma_addr_t sg_dma;
void *sg_cpu;
- struct dw_mci_dma_ops *dma_ops;
+ const struct dw_mci_dma_ops *dma_ops;
#ifdef CONFIG_MMC_DW_IDMAC
unsigned int ring_size;
#else
@@ -162,7 +162,7 @@ struct dw_mci {
u16 data_offset;
struct device *dev;
struct dw_mci_board *pdata;
- struct dw_mci_drv_data *drv_data;
+ const struct dw_mci_drv_data *drv_data;
void *priv;
struct clk *biu_clk;
struct clk *ciu_clk;
--
1.7.10
^ permalink raw reply related
* [PATCH 5/8] mmc: dw_mmc: fix modular build for exynos back-end
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
The MODULE_DEVICE_TABLE entry for dw_mci_exynos_match
was incorrectly copied from the platform back-end, which
causes this error when building the driver as a loadable
module:
drivers/mmc/host/dw_mmc-exynos.c: At top level:
drivers/mmc/host/dw_mmc-exynos.c:226:34: error: '__mod_of_device_table' aliased to undefined symbol 'dw_mci_pltfm_match'
This patch fixes the problem by just using the correct
string.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Will Newton <will.newton@imgtec.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/host/dw_mmc-exynos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 660bbc5..0147ac3a 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -223,7 +223,7 @@ static const struct of_device_id dw_mci_exynos_match[] = {
.data = (void *)&exynos5250_drv_data, },
{},
};
-MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
+MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
int dw_mci_exynos_probe(struct platform_device *pdev)
{
--
1.7.10
^ permalink raw reply related
* [PATCH 4/8] sched: warnings in kernel/sched/fair.c
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
a4c96ae319 "sched: Unthrottle rt runqueues in __disable_runtime()"
turned the unthrottle_offline_cfs_rqs function into a static symbol,
which now triggers a warning about it being potentially unused:
kernel/sched/fair.c:2055:13: warning: 'unthrottle_offline_cfs_rqs' defined but not used [-Wunused-function]
Marking it __maybe_unused shuts up the gcc warning and lets the
compiler safely drop the function body when it's not being used.
To reproduce, build the ARM bcm2835_defconfig.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Boonstoppel <pboonstoppel@nvidia.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Turner <pjt@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6b800a1..9f52728 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2052,7 +2052,7 @@ static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
hrtimer_cancel(&cfs_b->slack_timer);
}
-static void unthrottle_offline_cfs_rqs(struct rq *rq)
+static void __maybe_unused unthrottle_offline_cfs_rqs(struct rq *rq)
{
struct cfs_rq *cfs_rq;
--
1.7.10
^ permalink raw reply related
* [PATCH 3/8] mtd: uninitialized variable warning in map.h
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
The map_word_load() function initializes exactly
as many words in the buffer as required, but gcc
cannot figure this out and gives a misleading
warning. Marking the local variable as
uninitialized_var shuts up that warning.
Without this patch, building acs5k_defconfig results in:
drivers/mtd/chips/cfi_cmdset_0002.c: In function 'cfi_amdstd_panic_write':
include/linux/mtd/map.h:331:11: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
drivers/mtd/chips/cfi_cmdset_0002.c: In function 'cfi_amdstd_write_words':
include/linux/mtd/map.h:331:11: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words':
include/linux/mtd/map.h:331:11: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: linux-mtd at lists.infradead.org
---
include/linux/mtd/map.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 3595a02..e3559ba 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -328,7 +328,7 @@ static inline int map_word_bitsset(struct map_info *map, map_word val1, map_word
static inline map_word map_word_load(struct map_info *map, const void *ptr)
{
- map_word r;
+ map_word uninitialized_var(r);
if (map_bankwidth_is_1(map))
r.x[0] = *(unsigned char *)ptr;
--
1.7.10
^ permalink raw reply related
* [PATCH 2/8] mtd: diskonchip: use inline functions for DocRead/DocWrite
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
The diskonchip drivers traditionally use home-grown macros for
doing MMIO accesses, which cause a lot of warnings, at least
on ARM machines:
drivers/mtd/devices/doc2000.c: In function 'doc_write':
drivers/mtd/devices/doc2000.c:854:5: warning: value computed is not used [-Wunused-value]
drivers/mtd/devices/doc2000.c: In function 'doc_erase':
drivers/mtd/devices/doc2000.c:1123:5: warning: value computed is not used [-Wunused-value
drivers/mtd/nand/diskonchip.c: In function 'doc2000_read_byte':
drivers/mtd/nand/diskonchip.c:318:3: warning: value computed is not used [-Wunused-value]
A nicer solution is to use the architecture-defined I/O accessors.
Here, we use the __raw_readl/__raw_writel style, instead of the
proper readl/writel ones, in order to preserve the odd semantics
of the existing macros that have their own barrier implementation
and no byte swap. It would be nice to fix this properly and use
the correct accessors as well as make the word size independent
from the architecture, but I guess the hardware is obsolete
enough that we should better not mess the driver an more than
necessary.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: linux-mtd at lists.infradead.org
---
include/linux/mtd/doc2000.h | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/linux/mtd/doc2000.h b/include/linux/mtd/doc2000.h
index 0f6fea7..407d1e5 100644
--- a/include/linux/mtd/doc2000.h
+++ b/include/linux/mtd/doc2000.h
@@ -92,12 +92,26 @@
* Others use readb/writeb
*/
#if defined(__arm__)
-#define ReadDOC_(adr, reg) ((unsigned char)(*(volatile __u32 *)(((unsigned long)adr)+((reg)<<2))))
-#define WriteDOC_(d, adr, reg) do{ *(volatile __u32 *)(((unsigned long)adr)+((reg)<<2)) = (__u32)d; wmb();} while(0)
+static inline u8 ReadDOC_(u32 __iomem *addr, unsigned long reg)
+{
+ return __raw_readl(addr + reg);
+}
+static inline void WriteDOC_(u8 data, u32 __iomem *addr, unsigned long reg)
+{
+ __raw_writel(data, addr + reg);
+ wmb();
+}
#define DOC_IOREMAP_LEN 0x8000
#elif defined(__ppc__)
-#define ReadDOC_(adr, reg) ((unsigned char)(*(volatile __u16 *)(((unsigned long)adr)+((reg)<<1))))
-#define WriteDOC_(d, adr, reg) do{ *(volatile __u16 *)(((unsigned long)adr)+((reg)<<1)) = (__u16)d; wmb();} while(0)
+static inline u8 ReadDOC_(u16 __iomem *addr, unsigned long reg)
+{
+ return __raw_readw(addr + reg);
+}
+static inline void WriteDOC_(u8 data, u16 __iomem *addr, unsigned long reg)
+{
+ __raw_writew(data, addr + reg);
+ wmb();
+}
#define DOC_IOREMAP_LEN 0x4000
#else
#define ReadDOC_(adr, reg) readb((void __iomem *)(adr) + (reg))
--
1.7.10
^ permalink raw reply related
* [PATCH 1/8] mtd: diskonchip: don't warn about ARM architecture
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-1-git-send-email-arnd@arndb.de>
Enabling the diskonchip drivers on most architectures results
in a pointless warning "#warning Unknown architecture for
DiskOnChip. No default probe locations defined". The driver
can in fact handle the default location already through the
CONFIG_MTD_DOCPROBE_ADDRESS, which gets set on the platforms
that need it, and we get a run-time error if this is not
set correctly.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: linux-mtd at lists.infradead.org
---
drivers/mtd/devices/docprobe.c | 2 --
drivers/mtd/nand/diskonchip.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/mtd/devices/docprobe.c b/drivers/mtd/devices/docprobe.c
index 706b847..88b3fd3 100644
--- a/drivers/mtd/devices/docprobe.c
+++ b/drivers/mtd/devices/docprobe.c
@@ -70,8 +70,6 @@ static unsigned long __initdata doc_locations[] = {
0xe0000, 0xe2000, 0xe4000, 0xe6000,
0xe8000, 0xea000, 0xec000, 0xee000,
#endif /* CONFIG_MTD_DOCPROBE_HIGH */
-#else
-#warning Unknown architecture for DiskOnChip. No default probe locations defined
#endif
0xffffffff };
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 256eb30..81fa578 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -53,8 +53,6 @@ static unsigned long __initdata doc_locations[] = {
0xe0000, 0xe2000, 0xe4000, 0xe6000,
0xe8000, 0xea000, 0xec000, 0xee000,
#endif /* CONFIG_MTD_DOCPROBE_HIGH */
-#else
-#warning Unknown architecture for DiskOnChip. No default probe locations defined
#endif
0xffffffff };
--
1.7.10
^ permalink raw reply related
* [PATCH 0/8] warning fixes for v3.7-rc4
From: Arnd Bergmann @ 2012-11-06 21:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
Here are a few patches for remaining or newly introduced build
warnings in the ARM defconfig builds. The MTD patches have
been around for some time, but I had not submitted them because
I had to redo most of them first.
The only build error in this series is the exynos drm patch,
which is a very recent regression.
Please apply in to the respective maintainer trees.
Arnd
Arnd Bergmann (8):
mtd: diskonchip: don't warn about ARM architecture
mtd: diskonchip: use inline functions for DocRead/DocWrite
mtd: uninitialized variable warning in map.h
sched: warnings in kernel/sched/fair.c
mmc: dw_mmc: fix modular build for exynos back-end
mmc: dw_mmc: constify dw_mci_idmac_ops in exynos back-end
ata: highbank: mark ahci_highbank_probe as __devinit
drm/exynos: don't include plat/gpio-cfg.h
drivers/ata/sata_highbank.c | 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
drivers/mmc/host/dw_mmc-exynos.c | 8 ++++----
drivers/mmc/host/dw_mmc-pltfm.c | 2 +-
drivers/mmc/host/dw_mmc-pltfm.h | 2 +-
drivers/mmc/host/dw_mmc.c | 2 +-
drivers/mtd/devices/docprobe.c | 2 --
drivers/mtd/nand/diskonchip.c | 2 --
include/linux/mmc/dw_mmc.h | 4 ++--
include/linux/mtd/doc2000.h | 22 ++++++++++++++++++----
include/linux/mtd/map.h | 2 +-
kernel/sched/fair.c | 2 +-
12 files changed, 30 insertions(+), 21 deletions(-)
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
Cc: Paul Turner <pjt@google.com>
Cc: Peter Boonstoppel <pboonstoppel@nvidia.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rahul Sharma <rahul.sharma@samsung.com>
Cc: Rob Clark <rob@ti.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Will Newton <will.newton@imgtec.com>
Cc: linux-mtd at lists.infradead.org
--
1.7.10
^ permalink raw reply
* [PATCHv9 2/8] ARM: OMAP4: PM: add errata support
From: Kevin Hilman @ 2012-11-06 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zk2vekye.fsf@deeprootsystems.com>
Kevin Hilman <khilman@deeprootsystems.com> writes:
> Tero Kristo <t-kristo@ti.com> writes:
>
>> Added similar PM errata flag support as omap3 has. This should be used
>> in similar manner, set the flags during init time, and check the flag
>> values during runtime.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>
> These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going
> to queue these up as fixes.
>
> However, since they're not technically regressions, it may be too late
> to get them in for v3.7, but they'll be in for v3.8 for sure.
To be more specific, I'm planning on queuing patches 2, 3 and 6 as fixes
for v3.8 (branch: for_3.8/fixes/pm).
Paul has already queued patch 1, so that leaves patches 4, 5, 7 & 8.
I think we can get this series in for v3.8 if we drop the functional
pwrst dependency. To test, I dropped patches 5 & 7, and tested on
4430/Panda and 4460/Panda-ES (with latest mainline u-boot) and CORE
is hitting retention just fine in suspend.
If you can respin patch 8 based on the feedback from Felipe, I'll queue
up patches 4 & 8 for v3.8 as well, then we'll at least have CORE
retention in suspend in mainline. Then, the rest can be done when
functional pwrsts are ready.
Kevin
P.S. do you have any patches to add any OMAP4 CPUidle support for CORE
retention?
Paul has already queued patch 1, and that leaves the
^ permalink raw reply
* [PATCHv3 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Michal Nazarewicz @ 2012-11-06 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1352237765.git.mina86@mina86.com>
From: Michal Nazarewicz <mina86@mina86.com>
The File-backed Storage Gadget (g_file_storage) is being removed, since
it has been replaced by Mass Storage Gadget (g_mass_storage). This commit
changes defconfigs point to the new gadget.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> (fort AT91)
Acked-by: Tony Lindgren <tony@atomide.com> (for omap1)
---
arch/arm/configs/afeb9260_defconfig | 2 +-
arch/arm/configs/at91sam9260_defconfig | 2 +-
arch/arm/configs/at91sam9261_defconfig | 2 +-
arch/arm/configs/at91sam9263_defconfig | 2 +-
arch/arm/configs/at91sam9g20_defconfig | 2 +-
arch/arm/configs/corgi_defconfig | 2 +-
arch/arm/configs/davinci_all_defconfig | 2 +-
arch/arm/configs/h7202_defconfig | 3 +--
arch/arm/configs/magician_defconfig | 2 +-
arch/arm/configs/mini2440_defconfig | 2 +-
arch/arm/configs/omap1_defconfig | 3 +--
arch/arm/configs/prima2_defconfig | 1 -
arch/arm/configs/spitz_defconfig | 2 +-
arch/arm/configs/stamp9g20_defconfig | 2 +-
arch/arm/configs/viper_defconfig | 2 +-
arch/arm/configs/zeus_defconfig | 2 +-
arch/avr32/configs/atngw100_defconfig | 2 +-
arch/avr32/configs/atngw100_evklcd100_defconfig | 2 +-
arch/avr32/configs/atngw100_evklcd101_defconfig | 2 +-
arch/avr32/configs/atngw100_mrmt_defconfig | 2 +-
arch/avr32/configs/atngw100mkii_defconfig | 2 +-
.../avr32/configs/atngw100mkii_evklcd100_defconfig | 2 +-
.../avr32/configs/atngw100mkii_evklcd101_defconfig | 2 +-
arch/avr32/configs/atstk1002_defconfig | 2 +-
arch/avr32/configs/atstk1003_defconfig | 2 +-
arch/avr32/configs/atstk1004_defconfig | 2 +-
arch/avr32/configs/atstk1006_defconfig | 2 +-
arch/avr32/configs/favr-32_defconfig | 2 +-
arch/avr32/configs/hammerhead_defconfig | 2 +-
arch/blackfin/configs/CM-BF527_defconfig | 2 +-
arch/blackfin/configs/CM-BF548_defconfig | 2 +-
arch/blackfin/configs/CM-BF561_defconfig | 2 +-
arch/mips/configs/bcm47xx_defconfig | 2 +-
arch/mips/configs/mtx1_defconfig | 2 +-
arch/sh/configs/ecovec24_defconfig | 2 +-
arch/sh/configs/se7724_defconfig | 2 +-
36 files changed, 35 insertions(+), 38 deletions(-)
diff --git a/arch/arm/configs/afeb9260_defconfig b/arch/arm/configs/afeb9260_defconfig
index c285a9d..a8dbc1e 100644
--- a/arch/arm/configs/afeb9260_defconfig
+++ b/arch/arm/configs/afeb9260_defconfig
@@ -79,7 +79,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_RTC_CLASS=y
CONFIG_RTC_DEBUG=y
diff --git a/arch/arm/configs/at91sam9260_defconfig b/arch/arm/configs/at91sam9260_defconfig
index 505b376..0ea5d2c 100644
--- a/arch/arm/configs/at91sam9260_defconfig
+++ b/arch/arm/configs/at91sam9260_defconfig
@@ -75,7 +75,7 @@ CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_AT91SAM9=y
diff --git a/arch/arm/configs/at91sam9261_defconfig b/arch/arm/configs/at91sam9261_defconfig
index 1e8712e..c87beb9 100644
--- a/arch/arm/configs/at91sam9261_defconfig
+++ b/arch/arm/configs/at91sam9261_defconfig
@@ -125,7 +125,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_MMC_ATMELMCI=m
diff --git a/arch/arm/configs/at91sam9263_defconfig b/arch/arm/configs/at91sam9263_defconfig
index d2050ca..c5212f4 100644
--- a/arch/arm/configs/at91sam9263_defconfig
+++ b/arch/arm/configs/at91sam9263_defconfig
@@ -133,7 +133,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_SDIO_UART=m
diff --git a/arch/arm/configs/at91sam9g20_defconfig b/arch/arm/configs/at91sam9g20_defconfig
index e1b0e80..3b18810 100644
--- a/arch/arm/configs/at91sam9g20_defconfig
+++ b/arch/arm/configs/at91sam9g20_defconfig
@@ -96,7 +96,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_MMC_ATMELMCI=m
diff --git a/arch/arm/configs/corgi_defconfig b/arch/arm/configs/corgi_defconfig
index 4b8a25d..1fd1d1d 100644
--- a/arch/arm/configs/corgi_defconfig
+++ b/arch/arm/configs/corgi_defconfig
@@ -218,7 +218,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_MMC_PXA=y
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 67b5abb6..4ea7c95 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -144,7 +144,7 @@ CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_USB_CDC_COMPOSITE=m
diff --git a/arch/arm/configs/h7202_defconfig b/arch/arm/configs/h7202_defconfig
index 69405a7..e16d3f3 100644
--- a/arch/arm/configs/h7202_defconfig
+++ b/arch/arm/configs/h7202_defconfig
@@ -34,8 +34,7 @@ CONFIG_FB_MODE_HELPERS=y
CONFIG_USB_GADGET=m
CONFIG_USB_ZERO=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
-CONFIG_USB_FILE_STORAGE_TEST=y
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_EXT2_FS=y
CONFIG_TMPFS=y
diff --git a/arch/arm/configs/magician_defconfig b/arch/arm/configs/magician_defconfig
index a691ef4..557dd29 100644
--- a/arch/arm/configs/magician_defconfig
+++ b/arch/arm/configs/magician_defconfig
@@ -136,7 +136,7 @@ CONFIG_USB_PXA27X=y
CONFIG_USB_ETH=m
# CONFIG_USB_ETH_RNDIS is not set
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_USB_GPIO_VBUS=y
diff --git a/arch/arm/configs/mini2440_defconfig b/arch/arm/configs/mini2440_defconfig
index 00630e6..a07948a 100644
--- a/arch/arm/configs/mini2440_defconfig
+++ b/arch/arm/configs/mini2440_defconfig
@@ -240,7 +240,7 @@ CONFIG_USB_GADGET_S3C2410=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index dde2a1a..42eab9a 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -214,8 +214,7 @@ CONFIG_USB_TEST=y
CONFIG_USB_GADGET=y
CONFIG_USB_ETH=m
# CONFIG_USB_ETH_RNDIS is not set
-CONFIG_USB_FILE_STORAGE=m
-CONFIG_USB_FILE_STORAGE_TEST=y
+CONFIG_USB_MASS_STORAGE=m
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
diff --git a/arch/arm/configs/prima2_defconfig b/arch/arm/configs/prima2_defconfig
index 807d4e2..6a936c7 100644
--- a/arch/arm/configs/prima2_defconfig
+++ b/arch/arm/configs/prima2_defconfig
@@ -37,7 +37,6 @@ CONFIG_SPI_SIRF=y
CONFIG_SPI_SPIDEV=y
# CONFIG_HWMON is not set
CONFIG_USB_GADGET=y
-CONFIG_USB_FILE_STORAGE=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
diff --git a/arch/arm/configs/spitz_defconfig b/arch/arm/configs/spitz_defconfig
index df77931..2e0419d 100644
--- a/arch/arm/configs/spitz_defconfig
+++ b/arch/arm/configs/spitz_defconfig
@@ -214,7 +214,7 @@ CONFIG_USB_GADGET_DUMMY_HCD=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_MMC_PXA=y
diff --git a/arch/arm/configs/stamp9g20_defconfig b/arch/arm/configs/stamp9g20_defconfig
index 52f1488..b845f55 100644
--- a/arch/arm/configs/stamp9g20_defconfig
+++ b/arch/arm/configs/stamp9g20_defconfig
@@ -97,7 +97,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=m
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_MMC_ATMELMCI=y
diff --git a/arch/arm/configs/viper_defconfig b/arch/arm/configs/viper_defconfig
index 1d01ddd..d36e0d3 100644
--- a/arch/arm/configs/viper_defconfig
+++ b/arch/arm/configs/viper_defconfig
@@ -139,7 +139,7 @@ CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_GADGET=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_RTC_CLASS=y
diff --git a/arch/arm/configs/zeus_defconfig b/arch/arm/configs/zeus_defconfig
index 547a3c1..731d4f9 100644
--- a/arch/arm/configs/zeus_defconfig
+++ b/arch/arm/configs/zeus_defconfig
@@ -143,7 +143,7 @@ CONFIG_USB_GADGET=m
CONFIG_USB_PXA27X=y
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atngw100_defconfig b/arch/avr32/configs/atngw100_defconfig
index a06bfcc..f4025db 100644
--- a/arch/avr32/configs/atngw100_defconfig
+++ b/arch/avr32/configs/atngw100_defconfig
@@ -109,7 +109,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atngw100_evklcd100_defconfig b/arch/avr32/configs/atngw100_evklcd100_defconfig
index d8f1fe8..c76a49b 100644
--- a/arch/avr32/configs/atngw100_evklcd100_defconfig
+++ b/arch/avr32/configs/atngw100_evklcd100_defconfig
@@ -125,7 +125,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atngw100_evklcd101_defconfig b/arch/avr32/configs/atngw100_evklcd101_defconfig
index d4c5b19..2d8ab08 100644
--- a/arch/avr32/configs/atngw100_evklcd101_defconfig
+++ b/arch/avr32/configs/atngw100_evklcd101_defconfig
@@ -124,7 +124,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atngw100_mrmt_defconfig b/arch/avr32/configs/atngw100_mrmt_defconfig
index 77ca4f9..b189e0c 100644
--- a/arch/avr32/configs/atngw100_mrmt_defconfig
+++ b/arch/avr32/configs/atngw100_mrmt_defconfig
@@ -99,7 +99,7 @@ CONFIG_SND_ATMEL_AC97C=m
# CONFIG_SND_SPI is not set
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_DEBUG_FILES=y
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_MMC_ATMELMCI=y
diff --git a/arch/avr32/configs/atngw100mkii_defconfig b/arch/avr32/configs/atngw100mkii_defconfig
index 6e0dca4..2e4de42 100644
--- a/arch/avr32/configs/atngw100mkii_defconfig
+++ b/arch/avr32/configs/atngw100mkii_defconfig
@@ -111,7 +111,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atngw100mkii_evklcd100_defconfig b/arch/avr32/configs/atngw100mkii_evklcd100_defconfig
index 7f2a344..fad3cd2 100644
--- a/arch/avr32/configs/atngw100mkii_evklcd100_defconfig
+++ b/arch/avr32/configs/atngw100mkii_evklcd100_defconfig
@@ -128,7 +128,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atngw100mkii_evklcd101_defconfig b/arch/avr32/configs/atngw100mkii_evklcd101_defconfig
index 085eeba..2998623 100644
--- a/arch/avr32/configs/atngw100mkii_evklcd101_defconfig
+++ b/arch/avr32/configs/atngw100mkii_evklcd101_defconfig
@@ -127,7 +127,7 @@ CONFIG_USB_GADGET_VBUS_DRAW=350
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atstk1002_defconfig b/arch/avr32/configs/atstk1002_defconfig
index d1a887e..a582465 100644
--- a/arch/avr32/configs/atstk1002_defconfig
+++ b/arch/avr32/configs/atstk1002_defconfig
@@ -126,7 +126,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atstk1003_defconfig b/arch/avr32/configs/atstk1003_defconfig
index 956f281..57a79df 100644
--- a/arch/avr32/configs/atstk1003_defconfig
+++ b/arch/avr32/configs/atstk1003_defconfig
@@ -105,7 +105,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atstk1004_defconfig b/arch/avr32/configs/atstk1004_defconfig
index 40c69f3..1a49bd8 100644
--- a/arch/avr32/configs/atstk1004_defconfig
+++ b/arch/avr32/configs/atstk1004_defconfig
@@ -104,7 +104,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/atstk1006_defconfig b/arch/avr32/configs/atstk1006_defconfig
index 511eb8a..206a1b6 100644
--- a/arch/avr32/configs/atstk1006_defconfig
+++ b/arch/avr32/configs/atstk1006_defconfig
@@ -129,7 +129,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/favr-32_defconfig b/arch/avr32/configs/favr-32_defconfig
index 19973b0..0421498 100644
--- a/arch/avr32/configs/favr-32_defconfig
+++ b/arch/avr32/configs/favr-32_defconfig
@@ -117,7 +117,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_CDC_COMPOSITE=m
CONFIG_MMC=y
diff --git a/arch/avr32/configs/hammerhead_defconfig b/arch/avr32/configs/hammerhead_defconfig
index 6f45681..82f24eb 100644
--- a/arch/avr32/configs/hammerhead_defconfig
+++ b/arch/avr32/configs/hammerhead_defconfig
@@ -127,7 +127,7 @@ CONFIG_USB_GADGET=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=m
CONFIG_MMC_ATMELMCI=m
diff --git a/arch/blackfin/configs/CM-BF527_defconfig b/arch/blackfin/configs/CM-BF527_defconfig
index c280a50..f59c80e 100644
--- a/arch/blackfin/configs/CM-BF527_defconfig
+++ b/arch/blackfin/configs/CM-BF527_defconfig
@@ -106,7 +106,7 @@ CONFIG_MUSB_PIO_ONLY=y
CONFIG_USB_STORAGE=m
CONFIG_USB_GADGET=m
CONFIG_USB_ETH=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_RTC_CLASS=y
diff --git a/arch/blackfin/configs/CM-BF548_defconfig b/arch/blackfin/configs/CM-BF548_defconfig
index 349922b..e961483 100644
--- a/arch/blackfin/configs/CM-BF548_defconfig
+++ b/arch/blackfin/configs/CM-BF548_defconfig
@@ -107,7 +107,7 @@ CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
# CONFIG_USB_ETH_RNDIS is not set
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_MMC=m
diff --git a/arch/blackfin/configs/CM-BF561_defconfig b/arch/blackfin/configs/CM-BF561_defconfig
index 0456dea..24936b9 100644
--- a/arch/blackfin/configs/CM-BF561_defconfig
+++ b/arch/blackfin/configs/CM-BF561_defconfig
@@ -83,7 +83,7 @@ CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_USB_GADGET=m
CONFIG_USB_ETH=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_MMC=y
diff --git a/arch/mips/configs/bcm47xx_defconfig b/arch/mips/configs/bcm47xx_defconfig
index b6fde2b..4ca8e5c 100644
--- a/arch/mips/configs/bcm47xx_defconfig
+++ b/arch/mips/configs/bcm47xx_defconfig
@@ -473,7 +473,7 @@ CONFIG_USB_GADGET_NET2280=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_MIDI_GADGET=m
CONFIG_LEDS_CLASS=y
diff --git a/arch/mips/configs/mtx1_defconfig b/arch/mips/configs/mtx1_defconfig
index 46c61edc..a0277d4 100644
--- a/arch/mips/configs/mtx1_defconfig
+++ b/arch/mips/configs/mtx1_defconfig
@@ -661,7 +661,7 @@ CONFIG_USB_GADGET_NET2280=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_MIDI_GADGET=m
CONFIG_MMC=m
diff --git a/arch/sh/configs/ecovec24_defconfig b/arch/sh/configs/ecovec24_defconfig
index 911e30c9..c6c2bec 100644
--- a/arch/sh/configs/ecovec24_defconfig
+++ b/arch/sh/configs/ecovec24_defconfig
@@ -112,7 +112,7 @@ CONFIG_USB_MON=y
CONFIG_USB_R8A66597_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_MMC=y
CONFIG_MMC_SPI=y
CONFIG_MMC_SDHI=y
diff --git a/arch/sh/configs/se7724_defconfig b/arch/sh/configs/se7724_defconfig
index ed35093..1faa788 100644
--- a/arch/sh/configs/se7724_defconfig
+++ b/arch/sh/configs/se7724_defconfig
@@ -109,7 +109,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
-CONFIG_USB_FILE_STORAGE=m
+CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_MMC=y
CONFIG_MMC_SPI=y
--
1.7.7.3
^ permalink raw reply related
* [RFC PATCH 2/4] ARM: kernel: add cpu logical map DT init in setup_arch
From: Will Deacon @ 2012-11-06 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-3-git-send-email-lorenzo.pieralisi@arm.com>
On Tue, Oct 16, 2012 at 02:21:46PM +0100, Lorenzo Pieralisi wrote:
> As soon as the device tree is unflattened the cpu logical to physical
> mapping is carried out in setup_arch to build a proper array of MPIDR and
> corresponding logical indexes.
>
> The mapping could have been carried out using the flattened DT blob and
> related primitives, but since the mapping is not needed by early boot
> code it can safely be executed when the device tree has been uncompressed to
> its tree data structure.
>
> This patch adds the arm_dt_init_cpu maps() function call in setup_arch().
>
> If the kernel is not compiled with DT support the function is empty and
> no logical mapping takes place through it; the mapping carried out in
> smp_setup_processor_id() is left unchanged.
> If DT is supported the mapping created in smp_setup_processor_id() is overriden.
> The DT mapping also sets the possible cpus mask, hence platform
> code need not set it again in the respective smp_init_cpus() functions.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> arch/arm/kernel/setup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index da1d1aa..20c530b 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -758,6 +758,7 @@ void __init setup_arch(char **cmdline_p)
>
> unflatten_device_tree();
>
> + arm_dt_init_cpu_maps();
> #ifdef CONFIG_SMP
> if (is_smp()) {
> smp_set_ops(mdesc->smp);
> --
> 1.7.12
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [RFC PATCH 1/4] ARM: kernel: add device tree init map function
From: Will Deacon @ 2012-11-06 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-2-git-send-email-lorenzo.pieralisi@arm.com>
On Tue, Oct 16, 2012 at 02:21:45PM +0100, Lorenzo Pieralisi wrote:
> When booting through a device tree, the kernel cpu logical id map can be
> initialized using device tree data passed by FW or through an embedded blob.
>
> This patch adds a function that parses device tree "cpu" nodes and
> retrieves the corresponding CPUs hardware identifiers (MPIDR).
> It sets the possible cpus and the cpu logical map values according to
> the number of CPUs defined in the device tree and respective properties.
>
> The primary CPU is assigned cpu logical number 0 to keep the current
> convention valid.
>
> Current bindings documentation is included in the patch:
>
> Documentation/devicetree/bindings/arm/cpus.txt
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
[...]
> +void __init arm_dt_init_cpu_maps(void)
> +{
> + struct device_node *dn = NULL;
> + int i, cpu = 1;
> +
> + while ((dn = of_find_node_by_type(dn, "cpu")) && cpu <= nr_cpu_ids) {
> + const u32 *hwid;
> + int len;
> +
> + pr_debug(" * %s...\n", dn->full_name);
> +
> + hwid = of_get_property(dn, "reg", &len);
> +
> + if (!hwid || len != 4) {
> + pr_err(" * %s missing reg property\n", dn->full_name);
> + continue;
> + }
> + /*
> + * We want to assign the boot CPU logical id 0.
> + * Boot CPU checks its own MPIDR and if matches the current
> + * cpu node "reg" value it sets the logical cpu index to 0
> + * and stores the physical id accordingly.
> + * If MPIDR does not match, assign sequential cpu logical
> + * id (starting from 1) and increments it.
> + */
> + i = (be32_to_cpup(hwid) == (read_cpuid_mpidr() & 0xffffff))
> + ? 0 : cpu++;
> +
> + if (!i)
> + printk(KERN_INFO "Booting Linux on CPU HWID 0x%x\n",
> + be32_to_cpup(hwid));
I don't think we should bother with this print -- we already print something
in smp_setup_processor_id, which cannot differ for the boot CPU, If you want
the full mpidr, we could change that code to include it as well.
We might also want some sanity checking that we do indeed end up with
logical id 0 for the boot CPU. If not, I think we should scream and fall
back on the simple mapping created earlier.
Will
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Will Deacon @ 2012-11-06 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061610070.21033@xanadu.home>
On Tue, Nov 06, 2012 at 09:12:27PM +0000, Nicolas Pitre wrote:
>
> ... instead of flush_cache_all(). The later unconditionally flushes
> the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
> is costly and unnecessary in some scenarios where setup_mm_for_reboot()
> is used. If L2 has to be flushed as well, it should already be done
> separately on other architectures anyway.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index ab88ed4f8e..2c61085a10 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -104,7 +104,7 @@ early_initcall(init_static_idmap);
> void setup_mm_for_reboot(void)
> {
> /* Clean and invalidate L1. */
> - flush_cache_all();
> + flush_cache_louis();
>
> /* Switch to the identity mapping. */
> cpu_switch_mm(idmap_pgd, &init_mm);
We could probably even predicate this on the half-implemented
TLB_CAN_READ_FROM_L1_CACHE option, but that can come later.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] gpiolib: iron out include ladder mistakes
From: Stephen Warren @ 2012-11-06 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352218863-2037-1-git-send-email-linus.walleij@stericsson.com>
On 11/06/2012 09:21 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The <*/gpio.h> includes are updated again: now we need to account
> for the problem introduced by commit:
> 595679a8038584df7b9398bf34f61db3c038bfea
> "gpiolib: fix up function prototypes etc"
>
> Actually we need static inlines in include/asm-generic/gpio.h
> as well since we may have GPIOLIB but not PINCTRL.
>
> And we need to keep the static inlines in <linux/gpio.h>
> but here for the !CONFIG_GENERIC_GPIO case, and then we
> may as well throw in a few warnings like the other
> prototypes there, if someone would have the bad taste
> of compiling without GENERIC_GPIO even.
Hmm. Is there way to avoid the duplication of the dummy implementations?
Having a prototype and a truly dummy implementation in one place, but a
WARNing/failing dummy implementation elsewhere, seems like it'll cause
issues.
Does this patch mean the previous series causes "git bisect" failures?
^ permalink raw reply
* [PATCH 5/5] gpiolib: separation of pin concerns
From: Stephen Warren @ 2012-11-06 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352215028-30381-1-git-send-email-linus.walleij@stericsson.com>
On 11/06/2012 08:17 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The fact that of_gpiochip_add_pin_range() and
> gpiochip_add_pin_range() share too much code is fragile and
> will invariably mean that bugs need to be fixed in two places
> instead of one.
>
> So separate the concerns of gpiolib.c and gpiolib-of.c and
> have the latter call the former as back-end. This is necessary
> also when going forward with other device descriptions such
> as ACPI.
> diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
> @@ -115,7 +114,6 @@ struct pinctrl_dev *of_pinctrl_add_gpio_range(struct device_node *np,
> if (!pctldev)
> return NULL;
>
> - pinctrl_add_gpio_range(pctldev, range);
> return pctldev;
> }
I think that collapses to just:
return pctldev;
Aside from that, the series,
Reviewed-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Sören Moch @ 2012-11-06 21:28 UTC (permalink / raw)
To: linux-arm-kernel
resent as plain text, sorry.
> For Armada 370/XP we have the same problem that for the commit
> cb01b63, so we applied the same solution: "The default 256 KiB
> coherent pool may be too small for some of the Kirkwood devices, so
> increase it to make sure that devices will be able to allocate their
> buffers with GFP_ATOMIC flag"
I see a regression from linux-3.5 to linux-3.6 and think there might be
a fundamental problem
with this patch. On my Kirkwood system (guruplug server plus) with
linux-3.6.2 I see following
errors and corresponding malfunction even with further increased (2M,
4M) pool size:
Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent pool is
too small!
Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
kernel parameter!
So I had to downgrade to linux-3.5 which is running without problems.
I use SATA and several DVB sticks (em28xx / drxk and dib0700).
I already sent this bug report to m.szyprowski and
gregory.clementearlier, but
Sebastian suggested to send it to the mailing list and the responsible
maintainers, too.
Please write to my e-mail directly if you have further questions or
patches for me to test.
Regards,
Soeren
^ permalink raw reply
* [PATCHv9 0/8] ARM: OMAP4: core retention support
From: Kevin Hilman @ 2012-11-06 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352193483.8788.43.camel@sokoban>
Tero Kristo <t-kristo@ti.com> writes:
> Hi Kevin,
>
> On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
>> Hi Tero,
>>
>> Tero Kristo <t-kristo@ti.com> writes:
>>
>> > Hi,
>> >
>> > Changes compared to previous version:
>> > - rebased on top of 3.7-rc1
>> > - applies on top of latest func pwrst code (v6)
>> > - added back patch #1 to this set (it wasn't queued yet after all)
>> > - added patch #7 for fixing a bug in the functional pwrst code
>> > - added patch #8 for fixing a regression with MUSB PHY power handling
>> > (not quite sure if this is the correct way to fix this or not)
>> >
>> > Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle +
>> > suspend.
>> >
>> > Branch also available here:
>> > git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
>> > branch: mainline-3.7-rc1-omap4-ret-v9
>>
>> I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing
>> several domains not hitting target power state in suspend[1].
>>
>> Am I missing some other fixes? Using omap2plus_defconfig, I tried your
>> branch alone, and merged with v3.7-rc4, and I get the same errors.
[...]
> This looks like a combination of boot loader/kernel problems. My guess
> is that l3init is probably held on by the USB, and both ivahd / tesla
> are held on by some DSP/IVA modules which are not idling properly.
>
> The last patch in this set should fix the USB problems at least
> partially, but also the USB DPLL itself might be in wrong state,
> attached patch might help for that one and get l3init to idle.
>
> For DSP I don't have a patch right now, what is the boot loader you are
> using? (Can you provide git / commit / config info?)
I was using mainline u-boot at tag v2012.04.01 when I saw the errors.
To check the bootloader, I upgraded to the latest mainline tag
(v2012.10) and the problems are gone on both 4430/Panda and
4460/Panda-ES... Interesting.
That suggests that there's still some kernel assumptions/dependencies on
the bootloader that need to be addressed.
Kevin
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Arnd Bergmann @ 2012-11-06 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061533490.21033@xanadu.home>
On Tuesday 06 November 2012, Nicolas Pitre wrote:
> Maybe you are confused by CONFIG_ARCH_MTD_XIP where special support is
> needed in order to make writable MTD devices compatible with a XIP
> kernel located on them. That is indeed only available for ARCH_PXA and
> ARCH_SA1100.
Ok, I see.
> I really think that it makes no sense at all to support !MMU kernels in
> a multi-platform kernel build, even if the set of included platforms
> were all !MMU. The kernel has to be linked for the physical address of
> the target and not a common invariant virtual address.
There are two separate aspects here: One is to run a kernel on !MMU that is
built to support multiple platforms. I agree that this is rather pointless
and not interesting.
The other point is being able to build such a kernel, and this is what Will
seems to be interested in more. We have made VEXPRESS depend on
MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel,
and I think we should fix that. The two options are either to make
vexpress be single-platform when building for !MMU, or to allow multiplatform
kernels to be built without MMU support in principle. I think the second
option is more logical and avoids complex Kconfig constructs.
Arnd
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Nicolas Pitre @ 2012-11-06 21:12 UTC (permalink / raw)
To: linux-arm-kernel
... instead of flush_cache_all(). The later unconditionally flushes
the L2 cache on ARMv7 architectures such as Cortex A15 and A7 which
is costly and unnecessary in some scenarios where setup_mm_for_reboot()
is used. If L2 has to be flushed as well, it should already be done
separately on other architectures anyway.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index ab88ed4f8e..2c61085a10 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -104,7 +104,7 @@ early_initcall(init_static_idmap);
void setup_mm_for_reboot(void)
{
/* Clean and invalidate L1. */
- flush_cache_all();
+ flush_cache_louis();
/* Switch to the identity mapping. */
cpu_switch_mm(idmap_pgd, &init_mm);
^ permalink raw reply related
* ARM: idle sleep time for hotplugged cpu
From: Russell King - ARM Linux @ 2012-11-06 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509971F4.4060604@codeaurora.org>
On Tue, Nov 06, 2012 at 12:24:20PM -0800, Steve Muckle wrote:
> On 11/05/12 01:15, Russell King - ARM Linux wrote:
> > On Mon, Nov 05, 2012 at 09:23:38AM +0530, Taniya Das wrote:
> >> I was looking at the arch/arm/process.c:cpu_die, I was wondering why we
> >> do not exit from NOHZ for a hotplugged/offline cpu?
> >
> > Offlined CPUs are not supposed to just 'return' from cpu_die(), and
> > in actual fact they can't.
>
> Although an offline CPU will not come back into the idle thread by
> returning from cpu_die(), I believe the question about exiting nohz mode
> before cpu_die() still stands.
Well, that depends on the design of all that. I don't know that, but
what I do know is we're doing exactly the same as x86 which I presume
is correct.
> >From arch/arm/process.c:cpu_idle() it appears a CPU could enter
> pm_idle() for a while (in nohz mode), then execute the inner loop again
> and call cpu_die(). Is there the potential for cpu idle time accounting
> to get messed up here by not exiting nohz mode prior to the cpu dying,
> so that missed ticks from nohz are properly accounted for?
Why does the idle time matter if the CPU has been taken offline?
In any case, I think this is a question for the CPU idle people; it's not
a feature that I've ever knowingly used or have any interest in using at
the moment.
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Nicolas Pitre @ 2012-11-06 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211061733.44781.arnd@arndb.de>
On Tue, 6 Nov 2012, Arnd Bergmann wrote:
> On Tuesday 06 November 2012, Will Deacon wrote:
> > nommu-XIP kernels are a different kettle
> > of fish, but we don't care about a decompressor there.
>
> XIP is only supported on ARCH_PXA and ARCH_SA1100. I don't see either
> of them moving to CONFIG_MULTIPLATFORM any time soon, given how much
> work that would be. ARCH_MMP should be possible in the future, but
> has never supported XIP so far.
XIP kernels (CONFIG_XIP_KERNEL) are supported on any architecture.
This doesn't require any platform specific support. You just need a
range of physical memory addresses where to get the kernel text from
(that could even be unmapped RAM if you wanted to play with it on a
platform with no NOR flash). The prospect of PRAM usage might renew
interest in a XIP kernel.
Maybe you are confused by CONFIG_ARCH_MTD_XIP where special support is
needed in order to make writable MTD devices compatible with a XIP
kernel located on them. That is indeed only available for ARCH_PXA and
ARCH_SA1100.
> > The real problem will hit with things like CONFIG_DRAM_BASE, where !MMU
> > can't realistically support multiple platforms, so allowing
> > ARCH_MULTIPLATFORM doesn't feel quite right either...
>
> Anybody who wants to build a !MMU kernel already needs to tweak the
> configuration quite a lot and usually knows more about the system than
> a typical end user. Having to pick the correct DRAM_BASE probably
> isn't too bad in that case, as long as the kernels actually build.
I really think that it makes no sense at all to support !MMU kernels in
a multi-platform kernel build, even if the set of included platforms
were all !MMU. The kernel has to be linked for the physical address of
the target and not a common invariant virtual address.
Nicolas
^ permalink raw reply
* [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Tony Lindgren @ 2012-11-06 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106203226.GB6291@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [121106 12:40]:
> Hi,
>
> On Tue, Nov 06, 2012 at 10:42:27AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [121106 10:41]:
> > > * Felipe Balbi <balbi@ti.com> [121106 03:40]:
> > > > Hi,
> > > >
> > > > On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote:
> > > > > From: Michal Nazarewicz <mina86@mina86.com>
> > > > >
> > > > > The File-backed Storage Gadget (g_file_storage) is being removed, since
> > > > > it has been replaced by Mass Storage Gadget (g_mass_storage). This commit
> > > > > changes defconfigs point to the new gadget.
> > > > >
> > > > > Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
> > > >
> > > > I need more Acks here. Only got one from Nicolas. Anyone else ?
> > >
> > > For omaps:
> > >
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> >
> > Heh I guess no omap changes there, so probably not
> > worth adding then.
>
> omap1 is old, but it's still omap :-)
>
> arch/arm/configs/omap1_defconfig | 3 +--
Oh OK so it was not a spurious ack after all :)
Tony
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Arnd Bergmann @ 2012-11-06 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106183444.GJ30931@mudshark.cambridge.arm.com>
On Tuesday 06 November 2012, Will Deacon wrote:
> ARM: nommu: remove MMU dependency from ARCH_MULTIPLATFORM
>
> ARCH_MULTIPLATFORM is the only way to select ARCH_VEXPRESS, so remove
> the dependency on MMU and instead use it to predicate the selection of
> ARM_PATCH_PHYS_VIRT.
>
> Although running a multi-platform kernel on a selection of MMU-less
> targets might not yet be possible, the thing should build and targetting
> a nommu platform is already a fairly involved exercise.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Pawel Moll <Pawel.Moll@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Before we apply this, I should probably do a round of randconfig tests. Right now,
I have a series that fixes all build errors we currently get from randconfig
(which always selects MULTIPLATFORM since it doesn't randomize choice statements),
but I am pretty sure that adding NOMMU into the mix gives us a lot of new errors.
Arnd
^ permalink raw reply
* [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Felipe Balbi @ 2012-11-06 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106184227.GK6801@atomide.com>
Hi,
On Tue, Nov 06, 2012 at 10:42:27AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [121106 10:41]:
> > * Felipe Balbi <balbi@ti.com> [121106 03:40]:
> > > Hi,
> > >
> > > On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote:
> > > > From: Michal Nazarewicz <mina86@mina86.com>
> > > >
> > > > The File-backed Storage Gadget (g_file_storage) is being removed, since
> > > > it has been replaced by Mass Storage Gadget (g_mass_storage). This commit
> > > > changes defconfigs point to the new gadget.
> > > >
> > > > Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
> > >
> > > I need more Acks here. Only got one from Nicolas. Anyone else ?
> >
> > For omaps:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> Heh I guess no omap changes there, so probably not
> worth adding then.
omap1 is old, but it's still omap :-)
arch/arm/configs/omap1_defconfig | 3 +--
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/76039d0b/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox