Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Thu, Apr 24, 2014 at 08:29:17AM -0300, Ezequiel Garcia wrote: > Felipe, > > On Apr 22, Greg KH wrote: > > On Tue, Apr 22, 2014 at 10:26:13AM -0500, Felipe Balbi wrote: > > > On Tue, Apr 22, 2014 at 12:19:16PM -0300, Ezequiel Garcia wrote: > > > > > > > > That way silly grass-hoppers like me won't have to go through the > > > > find-bisect-fix bug cycle, only to discover someone else already fixed > > > > it but the patch is floating around :-) > > > > > > yeah, maybe.. I don't want to merge my fixes into next though. Maybe > > > Stephen could just merge both my branches on next. Greg, are you merging > > > your usb-linus into linux-next ? > > > > Yes, both of my branches get merged into linux-next. > > > > Well, if it's not too much trouble, I'd really appreciate that you can > find a way to include these -rc fixes in the branches that get merged > in -next. done -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
Felipe, On Apr 22, Greg KH wrote: > On Tue, Apr 22, 2014 at 10:26:13AM -0500, Felipe Balbi wrote: > > On Tue, Apr 22, 2014 at 12:19:16PM -0300, Ezequiel Garcia wrote: > > > > > > That way silly grass-hoppers like me won't have to go through the > > > find-bisect-fix bug cycle, only to discover someone else already fixed > > > it but the patch is floating around :-) > > > > yeah, maybe.. I don't want to merge my fixes into next though. Maybe > > Stephen could just merge both my branches on next. Greg, are you merging > > your usb-linus into linux-next ? > > Yes, both of my branches get merged into linux-next. > Well, if it's not too much trouble, I'd really appreciate that you can find a way to include these -rc fixes in the branches that get merged in -next. Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Tue, Apr 22, 2014 at 10:26:13AM -0500, Felipe Balbi wrote: > On Tue, Apr 22, 2014 at 12:19:16PM -0300, Ezequiel Garcia wrote: > > On Apr 22, Felipe Balbi wrote: > > > On Tue, Apr 22, 2014 at 11:01:28AM -0300, Ezequiel Garcia wrote: > > > > On Apr 02, Felipe Balbi wrote: > > > > > Hi, > > > > > > > > > > On Wed, Apr 02, 2014 at 06:16:23PM +0200, Daniel Mack wrote: > > > > > > On 04/02/2014 06:05 PM, Felipe Balbi wrote: > > > > > > > On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: > > > > > > > > > > > > >> diff --git a/drivers/usb/musb/musb_dsps.c > > > > > > >> b/drivers/usb/musb/musb_dsps.c > > > > > > >> index 3372ded..e2fd263 100644 > > > > > > >> --- a/drivers/usb/musb/musb_dsps.c > > > > > > >> +++ b/drivers/usb/musb/musb_dsps.c > > > > > > >> @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) > > > > > > >> struct dsps_glue *glue = dev_get_drvdata(dev->parent); > > > > > > >> > > > > > > >> del_timer_sync(&glue->timer); > > > > > > >> - > > > > > > >> usb_phy_shutdown(musb->xceiv); > > > > > > >> +debugfs_remove_recursive(glue->dbgfs_root); > > > > > > >> + > > > > > > >> return 0; > > > > > > >> } > > > > > > >> > > > > > > >> @@ -708,8 +709,6 @@ static int dsps_remove(struct > > > > > > >> platform_device *pdev) > > > > > > >> pm_runtime_put(&pdev->dev); > > > > > > >> pm_runtime_disable(&pdev->dev); > > > > > > >> > > > > > > >> -debugfs_remove_recursive(glue->dbgfs_root); > > > > > > > > > > > > > > I don't think this is the right fix. debugfs_remove_recursive is > > > > > > > supposed to remove the directory as well. Why isn't > > > > > > > dsps_musb_exit() > > > > > > > called ? > > > > > > > > > > > > dsps_musb_exit() is called, hence my fix works :) The question is > > > > > > rather > > > > > > why dsps_remove() isn't called. > > > > > > > > > > > > For me, the fix looked obvious, as resources that are claimed in > > > > > > dsps_musb_init() should obviously be freed in its counterpart > > > > > > function, > > > > > > dsps_musb_exit(). For reasons of readability if not for any other :) > > > > > > > > > > you're correct, for whatever reason I read it as moving the lines the > > > > > other way around (from _exit() to _remove()). > > > > > > > > > > I'll queue this once -rc1 is tagged. > > > > > > > > > > > > > Felipe: > > > > > > > > This fix didn't land on -rc2, and it's not even in -next. > > > > Am I missing something? Is it possible to queue this as urgently as > > > > possible? > > > > > > Grass hopper, please... :-) > > > > > > http://marc.info/?l=linux-usb&m=139809466025568&w=2 > > > > > > > Oh, nice. Thanks for taking care of this! > > > > Is there any strong reason for the fixes branch not being part of -next? > > Or maybe you should push the patches to your next branch, instead? > > > > I found functionality breaks *very* frequently on early -rc, and it's > > usually quicker to take a peek at -next and see if somebody already fixed > > it. > > > > That way silly grass-hoppers like me won't have to go through the > > find-bisect-fix bug cycle, only to discover someone else already fixed > > it but the patch is floating around :-) > > yeah, maybe.. I don't want to merge my fixes into next though. Maybe > Stephen could just merge both my branches on next. Greg, are you merging > your usb-linus into linux-next ? Yes, both of my branches get merged into linux-next. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Tue, Apr 22, 2014 at 12:19:16PM -0300, Ezequiel Garcia wrote: > On Apr 22, Felipe Balbi wrote: > > On Tue, Apr 22, 2014 at 11:01:28AM -0300, Ezequiel Garcia wrote: > > > On Apr 02, Felipe Balbi wrote: > > > > Hi, > > > > > > > > On Wed, Apr 02, 2014 at 06:16:23PM +0200, Daniel Mack wrote: > > > > > On 04/02/2014 06:05 PM, Felipe Balbi wrote: > > > > > > On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: > > > > > > > > > > >> diff --git a/drivers/usb/musb/musb_dsps.c > > > > > >> b/drivers/usb/musb/musb_dsps.c > > > > > >> index 3372ded..e2fd263 100644 > > > > > >> --- a/drivers/usb/musb/musb_dsps.c > > > > > >> +++ b/drivers/usb/musb/musb_dsps.c > > > > > >> @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) > > > > > >>struct dsps_glue *glue = dev_get_drvdata(dev->parent); > > > > > >> > > > > > >>del_timer_sync(&glue->timer); > > > > > >> - > > > > > >>usb_phy_shutdown(musb->xceiv); > > > > > >> + debugfs_remove_recursive(glue->dbgfs_root); > > > > > >> + > > > > > >>return 0; > > > > > >> } > > > > > >> > > > > > >> @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device > > > > > >> *pdev) > > > > > >>pm_runtime_put(&pdev->dev); > > > > > >>pm_runtime_disable(&pdev->dev); > > > > > >> > > > > > >> - debugfs_remove_recursive(glue->dbgfs_root); > > > > > > > > > > > > I don't think this is the right fix. debugfs_remove_recursive is > > > > > > supposed to remove the directory as well. Why isn't dsps_musb_exit() > > > > > > called ? > > > > > > > > > > dsps_musb_exit() is called, hence my fix works :) The question is > > > > > rather > > > > > why dsps_remove() isn't called. > > > > > > > > > > For me, the fix looked obvious, as resources that are claimed in > > > > > dsps_musb_init() should obviously be freed in its counterpart > > > > > function, > > > > > dsps_musb_exit(). For reasons of readability if not for any other :) > > > > > > > > you're correct, for whatever reason I read it as moving the lines the > > > > other way around (from _exit() to _remove()). > > > > > > > > I'll queue this once -rc1 is tagged. > > > > > > > > > > Felipe: > > > > > > This fix didn't land on -rc2, and it's not even in -next. > > > Am I missing something? Is it possible to queue this as urgently as > > > possible? > > > > Grass hopper, please... :-) > > > > http://marc.info/?l=linux-usb&m=139809466025568&w=2 > > > > Oh, nice. Thanks for taking care of this! > > Is there any strong reason for the fixes branch not being part of -next? > Or maybe you should push the patches to your next branch, instead? > > I found functionality breaks *very* frequently on early -rc, and it's > usually quicker to take a peek at -next and see if somebody already fixed it. > > That way silly grass-hoppers like me won't have to go through the > find-bisect-fix bug cycle, only to discover someone else already fixed > it but the patch is floating around :-) yeah, maybe.. I don't want to merge my fixes into next though. Maybe Stephen could just merge both my branches on next. Greg, are you merging your usb-linus into linux-next ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Apr 22, Felipe Balbi wrote: > On Tue, Apr 22, 2014 at 11:01:28AM -0300, Ezequiel Garcia wrote: > > On Apr 02, Felipe Balbi wrote: > > > Hi, > > > > > > On Wed, Apr 02, 2014 at 06:16:23PM +0200, Daniel Mack wrote: > > > > On 04/02/2014 06:05 PM, Felipe Balbi wrote: > > > > > On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: > > > > > > > > >> diff --git a/drivers/usb/musb/musb_dsps.c > > > > >> b/drivers/usb/musb/musb_dsps.c > > > > >> index 3372ded..e2fd263 100644 > > > > >> --- a/drivers/usb/musb/musb_dsps.c > > > > >> +++ b/drivers/usb/musb/musb_dsps.c > > > > >> @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) > > > > >> struct dsps_glue *glue = dev_get_drvdata(dev->parent); > > > > >> > > > > >> del_timer_sync(&glue->timer); > > > > >> - > > > > >> usb_phy_shutdown(musb->xceiv); > > > > >> +debugfs_remove_recursive(glue->dbgfs_root); > > > > >> + > > > > >> return 0; > > > > >> } > > > > >> > > > > >> @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device > > > > >> *pdev) > > > > >> pm_runtime_put(&pdev->dev); > > > > >> pm_runtime_disable(&pdev->dev); > > > > >> > > > > >> -debugfs_remove_recursive(glue->dbgfs_root); > > > > > > > > > > I don't think this is the right fix. debugfs_remove_recursive is > > > > > supposed to remove the directory as well. Why isn't dsps_musb_exit() > > > > > called ? > > > > > > > > dsps_musb_exit() is called, hence my fix works :) The question is rather > > > > why dsps_remove() isn't called. > > > > > > > > For me, the fix looked obvious, as resources that are claimed in > > > > dsps_musb_init() should obviously be freed in its counterpart function, > > > > dsps_musb_exit(). For reasons of readability if not for any other :) > > > > > > you're correct, for whatever reason I read it as moving the lines the > > > other way around (from _exit() to _remove()). > > > > > > I'll queue this once -rc1 is tagged. > > > > > > > Felipe: > > > > This fix didn't land on -rc2, and it's not even in -next. > > Am I missing something? Is it possible to queue this as urgently as > > possible? > > Grass hopper, please... :-) > > http://marc.info/?l=linux-usb&m=139809466025568&w=2 > Oh, nice. Thanks for taking care of this! Is there any strong reason for the fixes branch not being part of -next? Or maybe you should push the patches to your next branch, instead? I found functionality breaks *very* frequently on early -rc, and it's usually quicker to take a peek at -next and see if somebody already fixed it. That way silly grass-hoppers like me won't have to go through the find-bisect-fix bug cycle, only to discover someone else already fixed it but the patch is floating around :-) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Tue, Apr 22, 2014 at 11:01:28AM -0300, Ezequiel Garcia wrote: > On Apr 02, Felipe Balbi wrote: > > Hi, > > > > On Wed, Apr 02, 2014 at 06:16:23PM +0200, Daniel Mack wrote: > > > On 04/02/2014 06:05 PM, Felipe Balbi wrote: > > > > On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: > > > > > > >> diff --git a/drivers/usb/musb/musb_dsps.c > > > >> b/drivers/usb/musb/musb_dsps.c > > > >> index 3372ded..e2fd263 100644 > > > >> --- a/drivers/usb/musb/musb_dsps.c > > > >> +++ b/drivers/usb/musb/musb_dsps.c > > > >> @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) > > > >>struct dsps_glue *glue = dev_get_drvdata(dev->parent); > > > >> > > > >>del_timer_sync(&glue->timer); > > > >> - > > > >>usb_phy_shutdown(musb->xceiv); > > > >> + debugfs_remove_recursive(glue->dbgfs_root); > > > >> + > > > >>return 0; > > > >> } > > > >> > > > >> @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device > > > >> *pdev) > > > >>pm_runtime_put(&pdev->dev); > > > >>pm_runtime_disable(&pdev->dev); > > > >> > > > >> - debugfs_remove_recursive(glue->dbgfs_root); > > > > > > > > I don't think this is the right fix. debugfs_remove_recursive is > > > > supposed to remove the directory as well. Why isn't dsps_musb_exit() > > > > called ? > > > > > > dsps_musb_exit() is called, hence my fix works :) The question is rather > > > why dsps_remove() isn't called. > > > > > > For me, the fix looked obvious, as resources that are claimed in > > > dsps_musb_init() should obviously be freed in its counterpart function, > > > dsps_musb_exit(). For reasons of readability if not for any other :) > > > > you're correct, for whatever reason I read it as moving the lines the > > other way around (from _exit() to _remove()). > > > > I'll queue this once -rc1 is tagged. > > > > Felipe: > > This fix didn't land on -rc2, and it's not even in -next. > Am I missing something? Is it possible to queue this as urgently as > possible? Grass hopper, please... :-) http://marc.info/?l=linux-usb&m=139809466025568&w=2 > By the way, I'd like to complain a bit about the debugfs patch :-) > > First, was it really necessary to error out in case the debugfs files failed > to be created? Maybe we can simply omit the error check, unless there's some > reason and we *need* to know if is succeeded. we *need* the error check, what we do with it can be different. Patches are welcome. > Also, should we add a compile time option for that so that the debugfs can > be disabled? why ? just disable CONFIG_DEBUG_FS -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Apr 02, Felipe Balbi wrote: > Hi, > > On Wed, Apr 02, 2014 at 06:16:23PM +0200, Daniel Mack wrote: > > On 04/02/2014 06:05 PM, Felipe Balbi wrote: > > > On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: > > > > >> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > > >> index 3372ded..e2fd263 100644 > > >> --- a/drivers/usb/musb/musb_dsps.c > > >> +++ b/drivers/usb/musb/musb_dsps.c > > >> @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) > > >> struct dsps_glue *glue = dev_get_drvdata(dev->parent); > > >> > > >> del_timer_sync(&glue->timer); > > >> - > > >> usb_phy_shutdown(musb->xceiv); > > >> +debugfs_remove_recursive(glue->dbgfs_root); > > >> + > > >> return 0; > > >> } > > >> > > >> @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) > > >> pm_runtime_put(&pdev->dev); > > >> pm_runtime_disable(&pdev->dev); > > >> > > >> -debugfs_remove_recursive(glue->dbgfs_root); > > > > > > I don't think this is the right fix. debugfs_remove_recursive is > > > supposed to remove the directory as well. Why isn't dsps_musb_exit() > > > called ? > > > > dsps_musb_exit() is called, hence my fix works :) The question is rather > > why dsps_remove() isn't called. > > > > For me, the fix looked obvious, as resources that are claimed in > > dsps_musb_init() should obviously be freed in its counterpart function, > > dsps_musb_exit(). For reasons of readability if not for any other :) > > you're correct, for whatever reason I read it as moving the lines the > other way around (from _exit() to _remove()). > > I'll queue this once -rc1 is tagged. > Felipe: This fix didn't land on -rc2, and it's not even in -next. Am I missing something? Is it possible to queue this as urgently as possible? By the way, I'd like to complain a bit about the debugfs patch :-) First, was it really necessary to error out in case the debugfs files failed to be created? Maybe we can simply omit the error check, unless there's some reason and we *need* to know if is succeeded. Also, should we add a compile time option for that so that the debugfs can be disabled? Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
Hi, On Wed, Apr 02, 2014 at 06:16:23PM +0200, Daniel Mack wrote: > On 04/02/2014 06:05 PM, Felipe Balbi wrote: > > On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: > > >> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > >> index 3372ded..e2fd263 100644 > >> --- a/drivers/usb/musb/musb_dsps.c > >> +++ b/drivers/usb/musb/musb_dsps.c > >> @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) > >>struct dsps_glue *glue = dev_get_drvdata(dev->parent); > >> > >>del_timer_sync(&glue->timer); > >> - > >>usb_phy_shutdown(musb->xceiv); > >> + debugfs_remove_recursive(glue->dbgfs_root); > >> + > >>return 0; > >> } > >> > >> @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) > >>pm_runtime_put(&pdev->dev); > >>pm_runtime_disable(&pdev->dev); > >> > >> - debugfs_remove_recursive(glue->dbgfs_root); > > > > I don't think this is the right fix. debugfs_remove_recursive is > > supposed to remove the directory as well. Why isn't dsps_musb_exit() > > called ? > > dsps_musb_exit() is called, hence my fix works :) The question is rather > why dsps_remove() isn't called. > > For me, the fix looked obvious, as resources that are claimed in > dsps_musb_init() should obviously be freed in its counterpart function, > dsps_musb_exit(). For reasons of readability if not for any other :) you're correct, for whatever reason I read it as moving the lines the other way around (from _exit() to _remove()). I'll queue this once -rc1 is tagged. -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On 04/02/2014 06:05 PM, Felipe Balbi wrote: > On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: >> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c >> index 3372ded..e2fd263 100644 >> --- a/drivers/usb/musb/musb_dsps.c >> +++ b/drivers/usb/musb/musb_dsps.c >> @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) >> struct dsps_glue *glue = dev_get_drvdata(dev->parent); >> >> del_timer_sync(&glue->timer); >> - >> usb_phy_shutdown(musb->xceiv); >> +debugfs_remove_recursive(glue->dbgfs_root); >> + >> return 0; >> } >> >> @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) >> pm_runtime_put(&pdev->dev); >> pm_runtime_disable(&pdev->dev); >> >> -debugfs_remove_recursive(glue->dbgfs_root); > > I don't think this is the right fix. debugfs_remove_recursive is > supposed to remove the directory as well. Why isn't dsps_musb_exit() > called ? dsps_musb_exit() is called, hence my fix works :) The question is rather why dsps_remove() isn't called. For me, the fix looked obvious, as resources that are claimed in dsps_musb_init() should obviously be freed in its counterpart function, dsps_musb_exit(). For reasons of readability if not for any other :) Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: > When the platform initialization fails due to missing resources, it will > return -EPROBE_DEFER after dsps_musb_init() has been called. > > dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs > nodes. At a later point in time, the probe will be retried, and > dsps_musb_dbg_init() will be called again. debugfs_create_dir() will > fail this time, as the node already exists, and so the entire device > probe will fail with -ENOMEM. > > Fix this by moving debugfs_remove_recursive() from dsps_remove() to the > plaform's exit function, so it will be cleanly torn down when the probe > fails. It also feels more natural this way, as .exit is the counterpart > to .init. > > Signed-off-by: Daniel Mack > --- > Only the current 'next' branch which will be merged into 3.15 is affected. > > drivers/usb/musb/musb_dsps.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > index 3372ded..e2fd263 100644 > --- a/drivers/usb/musb/musb_dsps.c > +++ b/drivers/usb/musb/musb_dsps.c > @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) > struct dsps_glue *glue = dev_get_drvdata(dev->parent); > > del_timer_sync(&glue->timer); > - > usb_phy_shutdown(musb->xceiv); > + debugfs_remove_recursive(glue->dbgfs_root); > + > return 0; > } > > @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) > pm_runtime_put(&pdev->dev); > pm_runtime_disable(&pdev->dev); > > - debugfs_remove_recursive(glue->dbgfs_root); I don't think this is the right fix. debugfs_remove_recursive is supposed to remove the directory as well. Why isn't dsps_musb_exit() called ? I can see it being called from musb_remove() -> musb_shutdown() -> musb_platform_exit(). Looks like the problem is elsewhere. -- balbi signature.asc Description: Digital signature
[PATCH] USB: musb: dsps: move debugfs_remove_recursive()
When the platform initialization fails due to missing resources, it will return -EPROBE_DEFER after dsps_musb_init() has been called. dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs nodes. At a later point in time, the probe will be retried, and dsps_musb_dbg_init() will be called again. debugfs_create_dir() will fail this time, as the node already exists, and so the entire device probe will fail with -ENOMEM. Fix this by moving debugfs_remove_recursive() from dsps_remove() to the plaform's exit function, so it will be cleanly torn down when the probe fails. It also feels more natural this way, as .exit is the counterpart to .init. Signed-off-by: Daniel Mack --- Only the current 'next' branch which will be merged into 3.15 is affected. drivers/usb/musb/musb_dsps.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..e2fd263 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) struct dsps_glue *glue = dev_get_drvdata(dev->parent); del_timer_sync(&glue->timer); - usb_phy_shutdown(musb->xceiv); + debugfs_remove_recursive(glue->dbgfs_root); + return 0; } @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) pm_runtime_put(&pdev->dev); pm_runtime_disable(&pdev->dev); - debugfs_remove_recursive(glue->dbgfs_root); - return 0; } -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
