RFC: don't aggravate kernel panics

When in a kernel panic, we try to turn on the backlight. Because
of the panic, preempt is disabled at that time. Unfortunately,
operating the backlight requires access to I2C, and I2C likes to
sleep.

All this results in the kernel unleashing a nearly endless flood
of complaints complete with stack traces, etc., which often
obscures the real issue.

This patch is one way to improve the situation: it just skips
touching the backlight if we're in an atomic context. However, it
isn't perfect: it would be desirable if the backlight did get
turned on also on a panic. To do so, we would need to use I2C in
a way that doesn't sleep.

So I wonder if this is good enough or if someone has any plans to
make a better solution ?

Signed-off-by: Werner Almesberger <werner@openmoko.org>

1 files changed, 16 insertions, 1 deletions

diff --git a/arch/arm/mach-s3c2440/mach-gta02.c b/arch/arm/mach-s3c2440/mach-gta02.c
index a32a11e3135..f419537f9af 100644
--- a/arch/arm/mach-s3c2440/mach-gta02.c
+++ b/arch/arm/mach-s3c2440/mach-gta02.c
@@ -1058,11 +1058,26 @@ static struct s3c2410_ts_mach_info gta02_ts_cfg = {
 static void gta02_bl_set_intensity(int intensity)
 {
 	struct pcf50633 *pcf = gta02_pcf_pdata.pcf;
-	int old_intensity = pcf50633_reg_read(pcf, PCF50633_REG_LEDOUT);
+	int old_intensity;
 	int ret;
 
 	intensity >>= 2;
 
+	/*
+	 * One code path that leads here is from a kernel panic. Trying to turn
+	 * the backlight on just gives us a nearly endless stream of complaints
+	 * and accomplishes nothing. We can't win. Just give up.
+	 *
+	 * In the unlikely event that there's another path leading here while
+	 * we're atomic, we print at least a warning.
+	 */
+	if (in_atomic()) {
+		printk(KERN_ERR
+		    "gta02_bl_set_intensity called while atomic\n");
+		return;
+	}
+
+	old_intensity = pcf50633_reg_read(pcf, PCF50633_REG_LEDOUT);
 	if (intensity == old_intensity)
 		return;