1. 12 12月, 2011 12 次提交
  2. 29 11月, 2011 6 次提交
  3. 18 11月, 2011 1 次提交
  4. 16 11月, 2011 3 次提交
  5. 15 11月, 2011 15 次提交
    • S
      powerpc/usb: fix type cast for address of ioremap to compatible with 64-bit · 8981d76a
      Shaohui Xie 提交于
      Below are codes for accessing usb sysif_regs in driver:
      
      usb_sys_regs = (struct usb_sys_interface *)
      	((u32)dr_regs + USB_DR_SYS_OFFSET);
      
      these codes work in 32-bit, but in 64-bit, use u32 to type cast the address
      of ioremap is not right, and accessing members of 'usb_sys_regs' will cause
      call trace, so use (void *) for both 32-bit and 64-bit.
      Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8981d76a
    • M
      USB: ci13xxx_msm: add module license · 4703d2e9
      Marc Kleine-Budde 提交于
      Since commit "193ab2a6 usb: gadget: allow multiple gadgets to be built"
      the udc controllers can be compiled as a module. The ci13xxx_msm driver
      is missing the MODULE_LICENSE statement, so loading fails with:
      
      ci13xxx_msm: module license 'unspecified' taints kernel.
      ci13xxx_msm: Unknown symbol dev_set_name (err 0)
      ci13xxx_msm: Unknown symbol platform_get_irq (err 0)
      ci13xxx_msm: Unknown symbol device_unregister (err 0)
      ci13xxx_msm: Unknown symbol usb_add_gadget_udc (err 0)
      ci13xxx_msm: Unknown symbol put_device (err 0)
      ci13xxx_msm: Unknown symbol platform_driver_register (err 0)
      ci13xxx_msm: Unknown symbol platform_get_resource (err 0)
      ci13xxx_msm: Unknown symbol device_register (err 0)
      ci13xxx_msm: Unknown symbol usb_del_gadget_udc (err 0)
      
      This patch adds the missing MODULE_LICENSE statement with GPL v2 according
      to the header of the driver.
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4703d2e9
    • M
      USB: ci13xxx_udc: fix debug trace code · 194fa47e
      Marc Kleine-Budde 提交于
      This patch fixes the following compile errors that show up if switching
      on the debug trace code:
      
      drivers/usb/gadget/ci13xxx_udc.c: In function 'ci13xxx_wakeup':
      drivers/usb/gadget/ci13xxx_udc.c:2517:3: error: 'dev' undeclared (first use in this function)
      drivers/usb/gadget/ci13xxx_udc.c:2517:3: note: each undeclared identifier is reported only once for each function it appears in
      drivers/usb/gadget/ci13xxx_udc.c: In function 'udc_probe':
      drivers/usb/gadget/ci13xxx_udc.c:2867:2: error: 'name' undeclared (first use in this function)
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      194fa47e
    • M
      USB: ci13xxx_udc: fix deadlock during rmmod · fd537c04
      Marc Kleine-Budde 提交于
      The inline documentation of _gadget_stop_activity() states that the
      function should be called holding the udc->lock. This however will
      result in a deadlock, because _gadget_stop_activity() takes the udc->lock.
      
      During normal operation _gadget_stop_activity() is always called unlocked,
      but in ci13xxx_stop() it's called locked, this results in the following
      deadlock during rmmod of a gadget driver.
      
      This patch fixes the deadlock by calling _gadget_stop_activity() always
      unlocked, the inline documentation is adjusted accordingly.
      
      =============================================
      [ INFO: possible recursive locking detected ]
      3.1.0-rc6+ #159
      ---------------------------------------------
      rmmod/121 is trying to acquire lock:
       (udc_lock){-.-...}, at: [<c0229048>] _gadget_stop_activity+0x18/0x154
      
      but task is already holding lock:
       (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(udc_lock);
        lock(udc_lock);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      2 locks held by rmmod/121:
       #0:  (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
       #1:  (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164
      
      stack backtrace:
      [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4)
      [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4) from [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc)
      [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc) from [<c0059bac>] (__lock_acquire+0x494/0x8f0)
      [<c0059bac>] (__lock_acquire+0x494/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
      [<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0)
      [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
      [<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
      [<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
      [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
      [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
      [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
      BUG: spinlock lockup on CPU#0, rmmod/121, c05b1644
      [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c01da000>] (do_raw_spin_lock+0x128/0x144)
      [<c01da000>] (do_raw_spin_lock+0x128/0x144) from [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0)
      [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
      [<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
      [<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
      [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
      [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
      [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fd537c04
    • M
      USB: ci13xxx_udc: fix logic to mark request dma addresses as invalid · 954aad8c
      Michael Grzeschik 提交于
      The current driver sets the request's dma addr (mReq->req.dma) to 0 to
      mark the DMA address as not valid. However some gadget drivers
      (e.g. gadgetfs) set the request's dma addr to DMA_ADDR_INVALID to mark
      the address as invalid. This leads to bogus data send because the
      ci13xxx_udc driver assumes the request has already been mapped.
      
      This patch fixes the problem, by using DMA_ADDR_INVALID instead of 0
      to mark the request's DMA address as invalid.
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      954aad8c
    • M
      USB: gadgetfs: gadgetfs_disconnect: fix inconsistent lock state · 001428e4
      Marc Kleine-Budde 提交于
      Under certain circumstances lockdep finds an inconsistent lock state in
      gadgetfs. The problem can be reproduced with a hardware using the
      ci13xxx_udc driver and the gadgetfs test program (needs a patch to support
      the ci13xxx_udc, though):
      	http://www.linux-usb.org/gadget/usb.c
      Start the test program, wait to initialize, then press Ctrl+c.
      
      This patch fixes the following problem by using spin_lock_irqsave()
      instead of spin_lock().
      
      =================================
      [ INFO: inconsistent lock state ]
      3.1.0-rc6+ #158
      ---------------------------------
      inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      usb/113 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&dev->lock)->rlock){?.....}, at: [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
      {IN-HARDIRQ-W} state was registered at:
        [<c00596b8>] mark_irqflags+0x14c/0x1ac
        [<c0059bf8>] __lock_acquire+0x4e0/0x8f0
        [<c005a698>] lock_acquire+0x98/0x1a8
        [<c02f10e0>] _raw_spin_lock+0x54/0x8c
        [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
        [<c0229104>] _gadget_stop_activity+0xd4/0x154
        [<c022b130>] isr_reset_handler+0x34/0x1c0
        [<c022c320>] udc_irq+0x204/0x228
        [<c0069018>] handle_irq_event_percpu+0x64/0x3a0
        [<c0069390>] handle_irq_event+0x3c/0x5c
        [<c006ae5c>] handle_level_irq+0x8c/0x10c
        [<c0068a34>] generic_handle_irq+0x30/0x44
        [<c0009b2c>] handle_IRQ+0x30/0x84
        [<c0008ef8>] __irq_svc+0x38/0x60
        [<c0009c58>] default_idle+0x30/0x34
        [<c0009e30>] cpu_idle+0x9c/0xd8
        [<c04056f4>] start_kernel+0x278/0x2bc
      irq event stamp: 6412
      hardirqs last  enabled at (6412): [<c02f1cd0>] _raw_spin_unlock_irqrestore+0x30/0x5c
      hardirqs last disabled at (6411): [<c02f1278>] _raw_spin_lock_irqsave+0x20/0xa0
      softirqs last  enabled at (6381): [<c002833c>] irq_exit+0xa0/0xa8
      softirqs last disabled at (6372): [<c002833c>] irq_exit+0xa0/0xa8
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&dev->lock)->rlock);
        <Interrupt>
          lock(&(&dev->lock)->rlock);
      
       *** DEADLOCK ***
      
      1 lock held by usb/113:
       #0:  (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
      
      stack backtrace:
      [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0058e98>] (print_usage_bug+0x144/0x1c4)
      [<c0058e98>] (print_usage_bug+0x144/0x1c4) from [<c0059144>] (mark_lock_irq+0x22c/0x274)
      [<c0059144>] (mark_lock_irq+0x22c/0x274) from [<c00592d4>] (mark_lock+0x148/0x3e0)
      [<c00592d4>] (mark_lock+0x148/0x3e0) from [<c0059668>] (mark_irqflags+0xfc/0x1ac)
      [<c0059668>] (mark_irqflags+0xfc/0x1ac) from [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0)
      [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
      [<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f10e0>] (_raw_spin_lock+0x54/0x8c)
      [<c02f10e0>] (_raw_spin_lock+0x54/0x8c) from [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs])
      [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs]) from [<c0229104>] (_gadget_stop_activity+0xd4/0x154)
      [<c0229104>] (_gadget_stop_activity+0xd4/0x154) from [<c0229240>] (ci13xxx_stop+0xbc/0x17c)
      [<c0229240>] (ci13xxx_stop+0xbc/0x17c) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
      [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
      [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs])
      [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs]) from [<c00cc158>] (__fput+0xa4/0x1f0)
      [<c00cc158>] (__fput+0xa4/0x1f0) from [<c00c7f28>] (filp_close+0x5c/0x74)
      [<c00c7f28>] (filp_close+0x5c/0x74) from [<c00c7fe8>] (sys_close+0xa8/0x150)
      [<c00c7fe8>] (sys_close+0xa8/0x150) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      001428e4
    • D
      usb: gadget: fix MIDI gadget jack allocation · 74203de0
      Daniel Mack 提交于
      The dynamic jack allocation of the MIDI gadget currently links all
      external jacks to one single instance of an embedded jack. According to
      the spec, this is only valid if these streams always carry the same data
      stream, as described in the USB MIDI 1.0 spec, chapter 3.3.1.
      
      Also, genius Windows 7(tm) terminates it's life cycle instantly with a
      blue screen of death once a device with more than one input and output
      port with the current implementation is connected.
      
      While at it, and because it grew again by this change, allocate the
      temporary function pointer list on the heap, not on the stack.
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      74203de0
    • P
      usb: gadget: storage: check for valid USB_BULK_RESET_REQUEST wLength · ce7b6121
      Paul Zimmerman 提交于
      The USB-IF CV compliance tester is getting stricter, and it would
      be valid for it to fail a mass-storage device that accepts an
      invalid USB_BULK_RESET_REQUEST request. Although it doesn't do
      that yet, let's be proactive and fix that now.
      
      Suggested by Alan Stern.
      Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ce7b6121
    • P
      usb: gadget: storage: check for valid USB_BULK_GET_MAX_LUN_REQUEST · db332bc9
      Paul Zimmerman 提交于
      The latest USB-IF CV tester checks for a valid length for this
      request.
      Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      db332bc9
    • A
      usb: gadget: fsl_udc_core: fix compile error. · 0e042be3
      Alexander Aring 提交于
      Fix compile error in file drivers/usb/gadget/fsl_udc_core.c.
      
      drivers/usb/gadget/fsl_udc_core.c: In function 'portscx_device_speed':
      drivers/usb/gadget/fsl_udc_core.c:1720: error: 'speed' undeclared (first
      use in this function)
      
      Introduced in commit e538dfda
      (usb: Provide usb_speed_string() function)
      Signed-off-by: NAlexander Aring <a.aring@phytec.de>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0e042be3
    • Y
      usb: gadget: r8a66597-udc: fix flush fifo handling · 05bb7013
      Yoshihiro Shimoda 提交于
      The "BCLR" in CFIFOCTR/DnFIFOCTR can flush the fifo of "CPU side" only.
      To flush the fifo of "SIE side", we have to use the "ACLRM" in PIPEnCTR.
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      05bb7013
    • Y
      usb: gadget: r8a66597-udc: fix for udc-newstyle · b8cbbf80
      Yoshihiro Shimoda 提交于
      The udc-newstyle needs device_register in probe() of platform_device.
      If it doesn't call, kernel panic happens in the sysfs_create_dir() when
      we run modprobe a gadget driver.
      
      [ balbi@ti.com : fix compile warning introduced by this patch ]
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b8cbbf80
    • F
      usb: gadget: core: allow everybody to read sysfs attributes · 59d81f81
      Felipe Balbi 提交于
      Those are simply giving information about the current
      state of the UDC, nothing really fancy. We can let
      everybody read those.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      59d81f81
    • F
      usb: gadget: core: fix bug when removing gadget drivers · 6f39504d
      Felipe Balbi 提交于
      usb_gadget_disconnect() is responsible of removing
      data pullups. Before doing that we must, first, tell
      gadget driver we're disconnecting (by calling disconnect
      method on gadget driver structure), unbind the gadget
      driver and stop the controller.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6f39504d
    • F
      usb: gadget: udc-core: fix bug on soft_connect and srp interfaces · 1d91a962
      Felipe Balbi 提交于
      We should not be using dev_get_drvdata() because we
      never call dev_set_drvdata(). Let's use container_of()
      as all other sysfs attributes.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1d91a962
  6. 01 11月, 2011 2 次提交
  7. 19 10月, 2011 1 次提交