From mboxrd@z Thu Jan 1 00:00:00 1970 From: dromede@gmail.com (=?UTF-8?B?TWFya28gS2F0acSH?=) Date: Fri, 19 Oct 2012 13:37:25 +0200 Subject: pxa:spitz_pm.c: commit b6eede11 breaks spitz resume under certain conditions. In-Reply-To: References: Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Oct 18, 2012 at 11:28 AM, Marko Kati? wrote: >> Almost there, but I guess we could do this better and less confusing by having >> another array, e.g. tosa_gpio18_config[], which is tosa specific, and only >> initialize that MFP setting in the tosa path. >> >>> >>> I also looked at the original sharp kernel sources. >>> Only tosa used the RDY signal for it's tc6393tx chip, other machines simply >>> configured gpio18 as output in their suspend routines. > > > Actually, tosa doesn't use sharpsl_pm. Tosa uses the pda-power framework. > I said that only tosa uses the RDY signal to point out that we > probably don't need > the mfp-config line in postsuspend. That being said, i still think > that the array ordering > fix is adequate. Maybe later we may remove the mfp-config line from > postsuspend when > we're absolutely sure it isn't necessary for devices that use spitz_pm.c. So Eric what do you think, is the simple gpio array reordering patch an adequate fix for this bug?