On Mon, Sep 05, 2011 at 04:12:02PM +0530, Santosh wrote: > On Monday 05 September 2011 03:41 PM, Sergei Shtylyov wrote: >> Hello. >> >> On 04-09-2011 17:54, Santosh Shilimkar wrote: >> >>> OMAP4 L2X0 initialisation code uses BUG_ON() for the ioremap() >>> failure scenarios. >> >>> Use WARN_ON() instead and allow graceful function exits. >> >>> This was suggsted by Kevin Hilman<khilman@xxxxxx> during >>> OMAP4 PM code review. >> >>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@xxxxxx> >>> Cc: Kevin Hilman<khilman@xxxxxx> >>> --- >>> arch/arm/mach-omap2/omap4-common.c | 3 ++- >>> 1 files changed, 2 insertions(+), 1 deletions(-) >> >>> diff --git a/arch/arm/mach-omap2/omap4-common.c >>> b/arch/arm/mach-omap2/omap4-common.c >>> index 4791370..4904025 100644 >>> --- a/arch/arm/mach-omap2/omap4-common.c >>> +++ b/arch/arm/mach-omap2/omap4-common.c >>> @@ -121,7 +121,8 @@ static int __init omap_l2_cache_init(void) >>> >>> /* Static mapping, never released */ >>> l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K); >>> - BUG_ON(!l2cache_base); >>> + if (WARN_ON(!l2cache_base)) >>> + return -ENODEV; >> >> Rather ENOMEM... >> > Nope. Even though it's related to memory, it's > a memory controller so DEV is right. No it's not. The most likely reason ioremap() fails is because: 1. it's run out of memory for the metadata or page tables. 2. you passed it an invalid memory type (unlikely, you're using ioremap which uses a fixed known good type). 3. the address was >4GB but was not section aligned (also unlikely). Therefore, the error code should be "out of memory" not "no such device". -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
