1. 27 2月, 2012 5 次提交
  2. 24 2月, 2012 2 次提交
    • P
      usb: fsl_udc_core: Fix scheduling while atomic dump message · c5cc5ed8
      Peter Chen 提交于
      When loading g_ether gadget, there is below message:
      
      Backtrace:
      [<80012248>] (dump_backtrace+0x0/0x10c) from [<803cb42c>] (dump_stack+0x18/0x1c)
      r7:00000000 r6:80512000 r5:8052bef8 r4:80513f30
      [<803cb414>] (dump_stack+0x0/0x1c) from [<8000feb4>] (show_regs+0x44/0x50)
      [<8000fe70>] (show_regs+0x0/0x50) from [<8004c840>] (__schedule_bug+0x68/0x84)
      r5:8052bef8 r4:80513f30
      [<8004c7d8>] (__schedule_bug+0x0/0x84) from [<803cd0e4>] (__schedule+0x4b0/0x528)
      r5:8052bef8 r4:809aad00
      [<803ccc34>] (__schedule+0x0/0x528) from [<803cd214>] (_cond_resched+0x44/0x58)
      [<803cd1d0>] (_cond_resched+0x0/0x58) from [<800a9488>] (dma_pool_alloc+0x184/0x250)
       r5:9f9b4000 r4:9fb4fb80
       [<800a9304>] (dma_pool_alloc+0x0/0x250) from [<802a8ad8>] (fsl_req_to_dtd+0xac/0x180)
      [<802a8a2c>] (fsl_req_to_dtd+0x0/0x180) from [<802a8ce4>] (fsl_ep_queue+0x138/0x274)
      [<802a8bac>] (fsl_ep_queue+0x0/0x274) from [<7f004328>] (composite_setup+0x2d4/0xfac [g_ether])
      [<7f004054>] (composite_setup+0x0/0xfac [g_ether]) from [<802a9bb4>] (fsl_udc_irq+0x8dc/0xd38)
      [<802a92d8>] (fsl_udc_irq+0x0/0xd38) from [<800704f8>] (handle_irq_event_percpu+0x54/0x188)
      [<800704a4>] (handle_irq_event_percpu+0x0/0x188) from [<80070674>] (handle_irq_event+0x48/0x68)
      [<8007062c>] (handle_irq_event+0x0/0x68) from [<800738ec>] (handle_level_irq+0xb4/0x138)
       r5:80514f94 r4:80514f40
       [<80073838>] (handle_level_irq+0x0/0x138) from [<8006ffa4>] (generic_handle_irq+0x38/0x44)
       r7:00000012 r6:80510b1c r5:80529860 r4:80512000
       [<8006ff6c>] (generic_handle_irq+0x0/0x44) from [<8000f4c4>] (handle_IRQ+0x54/0xb4)
      [<8000f470>] (handle_IRQ+0x0/0xb4) from [<800085b8>] (tzic_handle_irq+0x64/0x94)
       r9:412fc085 r8:00000000 r7:80513f30 r6:00000001 r5:00000000
       r4:00000000
       [<80008554>] (tzic_handle_irq+0x0/0x94) from [<8000e680>] (__irq_svc+0x40/0x60)
      
      The reason of above dump message is calling dma_poll_alloc with can-schedule
      mem_flags at atomic context.
      
      To fix this problem, below changes are made:
      - fsl_req_to_dtd doesn't need to be protected by spin_lock_irqsave,
      as struct usb_request can be access at process context. Move lock
      to beginning of hardware visit (fsl_queue_td).
      - Change the memory flag which using to allocate dTD descriptor buffer,
      the memory flag can be from gadget layer.
      
      It is tested at i.mx51 bbg board with g_mass_storage, g_ether, g_serial.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Acked-by: NLi Yang <leoli@freescale.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c5cc5ed8
    • I
      usb: gadget: Clear usb_endpoint_descriptor inside the struct usb_ep on disable · f9c56cdd
      Ido Shayevitz 提交于
      This fix a bug in f_serial, which expect the ep->desc to be NULL after
      disabling an endpoint.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NIdo Shayevitz <idos@codeaurora.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      f9c56cdd
  3. 23 2月, 2012 1 次提交
  4. 15 2月, 2012 3 次提交
  5. 09 2月, 2012 6 次提交
  6. 30 1月, 2012 1 次提交
  7. 24 1月, 2012 19 次提交
  8. 13 1月, 2012 1 次提交
  9. 09 1月, 2012 2 次提交
    • A
      ... and the same for gadgetfs · 87da5b32
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      87da5b32
    • A
      functionfs: unfuck failure exits on mount · 5b5f9560
      Al Viro 提交于
      * if you do dput() of root dentry, do *not* follow that with iput() of root
      inode.
      * while we are at it, don't do that dput() at all - you are leaving the pointer
      in ->s_root and your ->kill_sb() will be very unhappy with that.  It will do
      proper dput(), though, so the easiest way is to leave that to it entirely.
      * freeing ->s_fs_info is also best left to ->kill_sb() (which will do it
      anyway), especially since we leave the pointer in place.
      * that xchg() in ->kill_sb() is not a bug per se, but it's a plain and simple
      masturbation with fewer excuses than Onan had...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      5b5f9560