Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()

2014-04-24 Thread Ezequiel Garcia
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()

2014-04-24 Thread Felipe Balbi
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()

2014-04-22 Thread Felipe Balbi
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-usbm=139809466025568w=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()

2014-04-22 Thread Felipe Balbi
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-usbm=139809466025568w=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()

2014-04-02 Thread Felipe Balbi
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 zon...@gmail.com
 ---
 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


Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()

2014-04-02 Thread Daniel Mack
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()

2014-04-02 Thread Felipe Balbi
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