Suspend/Resume oversight wrt GSM handling

Andy Green andy at
Thu May 15 17:02:40 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
| ...
|> By all means send out a patch on the list and it will be read by at
|> least one pair of interested eyes.
| Let me just toss this part of the set of patches out.  It's not the
| final one; there's some additional logic required to integrate in the
| modem-control stuff for Qtopia, assuming I correctly understood how that
| software expects things to work.

| @@ -214,6 +277,12 @@ static int gta01_gsm_resume(struct platf
|         if (machine_is_neo1973_gta02())
|                 s3c2410_gpio_setpin(GTA02_GPIO_nDL_GSM,
| gta01_gsm.gpio_ndl_gsm);
| +       /* We must defer the auto flowcontrol because we resume before
| +        * the serial driver */
| +       if (! schedule_work(&gsmwork))
| +               dev_err(&pdev->dev,
| +                       "Unable to schedule GSM wakeup work\n");
| +
|         return 0;

Ah I see... not the first problem caused by resume ordering misery...
maybe better than msleep for >= the requested time, the work function
can loop sleeping and snooping on a register state that is definitively
changed when the serial driver is up?  If not then fine I guess... I
also guess other folks that have an interest in the serial subsystem can
have other opinions...

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list