[PATCH 05/10] debug-backtrace-not-choke-on-null-dev_blah.patch

Andy Green andy at openmoko.com
Mon Jun 16 12:51:37 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| On Monday 16 June 2008 00:17:33 Andy Green wrote:
|> Signed-off-by: Andy Green <andy at openmoko.com>
|> ---
|>
|>  drivers/base/core.c |    5 +++++
|>  1 files changed, 5 insertions(+), 0 deletions(-)
|>
|> diff --git a/drivers/base/core.c b/drivers/base/core.c
|> index 2683eac..49fdee2 100644
|> --- a/drivers/base/core.c
|> +++ b/drivers/base/core.c
|> @@ -42,6 +42,11 @@ int (*platform_notify_remove)(struct device * dev) =
|> NULL; */
|>  const char *dev_driver_string(struct device *dev)
|>  {
|> +	if (!dev) {
|> +		printk(KERN_ERR"Null dev to dev_driver_string\n");
|> +		dump_stack();
|> +		return "*NULL*";
|> +	}
|
| wow, where did we call this from a driver with no device attached? Is
that for
| 06 and the backlight resume?

No I added it because of Sean's failure to resume behaviours he
suspected are to do with dev_info(<expression>, ... inclusion in suspend
/ resume.  I checked the path for dev_info and it doesn't test for NULL
before dereference.  Since I found the i2c_get_clientdata() can return
NULL in early resume, AND we use that to store and retrieve pcf pointer
for example, I wondered if we were having an async pcf interrupt early
in resume, and crashing on NULL pointer panic when pcf was dereferenced
then.

Subsequently I disabled interrupt response from pcf suspend -> end of
pcf resume, but this doesn't do any harm since it represents a class of
issue we might get a clue out of.

| PS: Janitor comment: add a space after KERN_ERR

Ha, checkpatch doesn't agree it is needed, but I can see where you are
coming from.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhWRbkACgkQOjLpvpq7dMrEnACghmE6MI5znMeFDfiWXvjCqI62
LFEAniztFvkLsEsqltTpOxuSpVPXMC8L
=z/yH
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list