On 11/25/2013 08:44 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
>> It appears not all platforms featuring a musb core need to save the musb
>> core registers at suspend time and restore them on resume.
>>
>> The dsps platform does, however. So add a bit in struct
>> musb_hdrc_platform_data to let platforms specify their need of such
>> action being taken.
>>
>> Signed-off-by: Daniel Mack <zonque@xxxxxxxxx>
>> ---
>> drivers/usb/musb/musb_core.c | 17 ++++++++++++++++-
>> include/linux/usb/musb.h | 3 +++
>> 2 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> index 0a43329..a8ded57 100644
>> --- a/drivers/usb/musb/musb_core.c
>> +++ b/drivers/usb/musb/musb_core.c
>> @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
>> {
>> struct musb *musb = dev_to_musb(dev);
>> unsigned long flags;
>> + struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
>
> we don't want to have platform_data on DT-based boot. It's best to just
> save those registers unconditionally as it doesn't hurt.
>
My concern about doing it unconditionally from the core is simply that I
fear regressions for other platforms. I can of course drop it if you're
certain that that's correct.
I can only test this on a dsps glue layer, and I have no documentation
for the musb core. All I'm left with here is fishing in muddy waters :/
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
