Thomas White wrote: > Andy Green <[EMAIL PROTECTED]> wrote: > >> Somebody in the thread at some point said: >> >>> I hit this when updating to 2.6.26. Also if CONFIG_MMC is enabled >>> this patch converts this horrible horrible hack into a horrible >>> hack by using dev->resume() (untested). >> Thanks for that, it is much neater. Sent it on to stable. > > I find that this patch causes resume not to work, reproducibly, on my > GTA02. That is to say: I was trying to build a kernel from the tip of > the 'stable' branch and ran into problems (unresponsive black screen > when trying to resume via the power button). I did a 'git bisect' and > isolated it to this commit, and reverting this commit (only) caused the > problem to go away for me. > > Is it possible that "dev->resume()" is not properly initialised somehow?
I duplicated that code for the GTA01, so at one point apparently I understood what that stuff was doing. Today I'm lost in dev structures... but as near as I can see, the problem is that the dev structure referred to by the argument to gta02_glamo_mci_suspending() is not the dev structure containing the pointer to glamo_mci_resume(). In other words, (void *)dev->dev.driver->resume != glamo_mci_resume; it points to some other resume handler altogether. I put some printk's in the kernel to confirm this; from dmesg: Suspending console(s) pcf50633 0-0073: pcf50633_suspend GTA02 PATCHCHECK: dev.driver->resume is 0xc01a9144 GTA02 PATCHCHECK: glamo_mci_resume() is 0xc01af74c glamo-mci glamo-mci.0: faking cmd 7 during suspend mmc_set_power(power_mode=0, vdd=0 > As far as I can see, this patch isn't meant to be anything more than a > tidy-up. I'd love to have a go at tracking this down myself, but my > weekend reading on Linux Kernel Development is still in the post from > Amazon... :) I don't think you'll find that bit of code in the book! I don't know of a good way to keep the code clean-up, perhaps someone else knows a better way than the original code? Mike (mwester)
