Skip to contentSkip to conversation

ARM: OMAP: Fix kernel panic in dmtimer probe

PATCH New Jon Hunter 2 participants 3 messages Nov 9, 2012

Subsystems (2)
lore
Share & tools
lore

Jon Hunter

author
#0 lore raw

PATCH 1/1 ARM: OMAP: Fix kernel panic in dmtimer probe

When booting with device-tree the kernel is panicing in the probe of the DMTIMER driver. The panic is caused because the pointer to platform_data structure is NULL when booting with device-tree and the driver is attempting to access the structure without checking if the pointer is valid.

Fix this by moving the code that accesses the platform data structure under the "else" clause of the "if (dev->of_node)" statement because here the pointer to platform_data is guaranteed to be valid. The code accessing the "timer_capability" member of the platform data is simply removed as this is already handled under the else clause.

This regression was introduced while integrating commit "ARM: OMAP: Add DT support for timer driver" to add device-tree support to the DMTIMER driver and commit "ARM: OMAP: Move omap-pm-noop.c local to mach-omap2" to prepare for single zImage support.

---
 arch/arm/plat-omap/dmtimer.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
arch/arm/plat-omap/dmtimer.c +1 -2
index 38c12ef..9dca23e 100644
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
 		timer->id = pdev->id;
 		timer->capability = pdata->timer_capability;
 		timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
+		timer->get_context_loss_count = pdata->get_context_loss_count;
 	}
 
 	timer->irq = irq->start;
 	timer->pdev = pdev;
-	timer->capability = pdata->timer_capability;
-	timer->get_context_loss_count = pdata->get_context_loss_count;
 
 	/* Skip pm_runtime_enable for OMAP1 */
 	if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
Signature · 1 line
1.7.9.5
author
#1 lore raw

PATCH 1/1 ARM: OMAP: Fix kernel panic in dmtimer probe

Quoted 12 lines · Jon Hunter

When booting with device-tree the kernel is panicing in the probe of the DMTIMER driver. The panic is caused because the pointer to platform_data structure is NULL when booting with device-tree and the driver is attempting to access the structure without checking if the pointer is valid.

Fix this by moving the code that accesses the platform data structure under the "else" clause of the "if (dev->of_node)" statement because here the pointer to platform_data is guaranteed to be valid. The code accessing the "timer_capability" member of the platform data is simply removed as this is already handled under the else clause.

Quoted 4 lines

This regression was introduced while integrating commit "ARM: OMAP: Add DT support for timer driver" to add device-tree support to the DMTIMER driver and commit "ARM: OMAP: Move omap-pm-noop.c local to mach-omap2" to prepare for single zImage support.

By the way, I meant to add ...

Jon

Quoted 24 lines
---
 arch/arm/plat-omap/dmtimer.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
arch/arm/plat-omap/dmtimer.c +1 -2
index 38c12ef..9dca23e 100644
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
 		timer->id = pdev->id;
 		timer->capability = pdata->timer_capability;
 		timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
+		timer->get_context_loss_count = pdata->get_context_loss_count;
 	}
 
 	timer->irq = irq->start;
 	timer->pdev = pdev;
-	timer->capability = pdata->timer_capability;
-	timer->get_context_loss_count = pdata->get_context_loss_count;
 
 	/* Skip pm_runtime_enable for OMAP1 */
 	if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
#2 lore raw

PATCH 1/1 ARM: OMAP: Fix kernel panic in dmtimer probe

In reply to Jon Hunter
Quoted 12 lines · Jon Hunter

When booting with device-tree the kernel is panicing in the probe of the DMTIMER driver. The panic is caused because the pointer to platform_data structure is NULL when booting with device-tree and the driver is attempting to access the structure without checking if the pointer is valid.

Fix this by moving the code that accesses the platform data structure under the "else" clause of the "if (dev->of_node)" statement because here the pointer to platform_data is guaranteed to be valid. The code accessing the "timer_capability" member of the platform data is simply removed as this is already handled under the else clause.

Quoted 4 lines

This regression was introduced while integrating commit "ARM: OMAP: Add DT support for timer driver" to add device-tree support to the DMTIMER driver and commit "ARM: OMAP: Move omap-pm-noop.c local to mach-omap2" to prepare for single zImage support.

Thanks, looks like this needs to be fixed in the merge, so I'll merge omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3 into omap-for-v3.8/dt and resolve the conflict according to your patch.

Regards,

Tony

Quoted 26 lines
---
 arch/arm/plat-omap/dmtimer.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
arch/arm/plat-omap/dmtimer.c +1 -2
index 38c12ef..9dca23e 100644
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
 		timer->id = pdev->id;
 		timer->capability = pdata->timer_capability;
 		timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
+		timer->get_context_loss_count = pdata->get_context_loss_count;
 	}
 
 	timer->irq = irq->start;
 	timer->pdev = pdev;
-	timer->capability = pdata->timer_capability;
-	timer->get_context_loss_count = pdata->get_context_loss_count;
 
 	/* Skip pm_runtime_enable for OMAP1 */
 	if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
Signature · 1 line
1.7.9.5