Hi,
On Mon, Nov 25, 2013 at 09:08:51PM +0100, Daniel Mack wrote:
> 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 :/
I really don't think it should cause any issues with any other platform.
We can make to leave this soaking in linux-next for a long time and hope
people test it.
--
balbi
Attachment:
signature.asc
Description: Digital signature
