Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux