[PATCH] Fix build with no CONFIG_MMC.
mwester at dls.net
Thu Oct 2 03:27:15 CEST 2008
Thomas White wrote:
> Andy Green <andy at openmoko.com> 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:
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
> 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
:) 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?
More information about the openmoko-kernel