1. 20 2月, 2014 3 次提交
    • J
      usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP · e7d613d1
      Josh Cartwright 提交于
      Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
      msm_otg_{suspend,resume} routines, however these routines are only being
      built when CONFIG_PM_SLEEP.  In addition, msm_otg_{suspend,resume} also
      depends on msm_hsusb_config_vddcx(), which is only built when
      CONFIG_PM_SLEEP.
      
      Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
      preprocessor conditional, and moving msm_hsusb_config_vddcx().
      
      While we're here, eliminate the CONFIG_PM conditional for setting
      up the dev_pm_ops.
      
      This address the following errors Russell King has hit doing randconfig
      builds:
      
      drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
      drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
      drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
      drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'
      
      Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NJosh Cartwright <joshc@codeaurora.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      e7d613d1
    • A
      usb: gadget: fix NULL pointer dereference · f0f42204
      Andrzej Pietrasiewicz 提交于
      Fix possible NULL pointer dereference introduced in
      commit 219580e6 (usb: f_fs: check quirk to pad epout
      buf size when not aligned to maxpacketsize)
      
      In cases we do wait with:
      
      wait_event_interruptible(epfile->wait, (ep = epfile->ep));
      
      for endpoint to be enabled, functionfs_bind() has not been called yet
      and epfile->ffs->gadget is still NULL and the automatic variable 'gadget'
      has been initialized with NULL at the point of its definition.
      Later on it is used as a parameter to:
      
      usb_ep_align_maybe(gadget, ep->ep, len)
      
      which in turn dereferences it.
      
      This patch fixes it by moving the actual assignment to the local 'gadget'
      variable after the potential waiting has completed.
      Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      f0f42204
    • P
      usb: gadget: printer: using gadget_is_otg to check otg support at runtime · 8679059e
      Peter Chen 提交于
      We need to use gadget_is_otg to check if the gadget is really
      otg support at runtime, other composite gadget drivers have already
      followed this method.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      8679059e
  2. 19 2月, 2014 5 次提交
    • F
      usb: gadget: bcm63xx_udc: fix build failure on DMA channel code · 2d1f7af3
      Florian Fainelli 提交于
      Commit 3dc6475c ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
      changed the ENETDMA[CS] macros such that they are no longer macros, but
      actual register offset definitions. The bcm63xx_udc driver was not
      updated, and as a result, causes the following build error to pop up:
      
       CC      drivers/usb/gadget/u_ether.o
      drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write':
      drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not
      a function
      drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel':
      drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not
      a function
      drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not
      a function
      
      Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to
      take an extra channel argument, and use the channel width
      (ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence
      doing again what the macro implicitely did for us.
      
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Jonas Gorski <jogo@openwrt.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2d1f7af3
    • D
      usb: musb: do not sleep in atomic context · 30d361bf
      Daniel Mack 提交于
      musb_port_reset() is called from musb_hub_control() which in turn holds
      a spinlock, so musb_port_reset() is not allowed to call msleep().
      
      With the asynchronous work helpers in place, this is fortunately easy to
      fix by rescheduling the reset deassertion function to after the time
      when the wait period is finished.
      
      Note, however, that the MUSB_POWER_RESUME bit is only set on AM33xx
      processors under rare conditions such as when to another driver
      reporting an error during suspend. Hence, this didn't hit me yet in
      normal operation.
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      30d361bf
    • S
      usb: gadget: s3c2410_udc: Fix build error · d246c9d5
      Sachin Kamat 提交于
      Pass value instead of address as expected by 'usb_ep_set_maxpacket_limit'.
      Fixes the following compilation error introduced by commit e117e742
      ("usb: gadget: add "maxpacket_limit" field to struct usb_ep"):
      
      drivers/usb/gadget/s3c2410_udc.c: In function ‘s3c2410_udc_reinit’:
      drivers/usb/gadget/s3c2410_udc.c:1632:3: error:
      cannot take address of bit-field ‘maxpacket’
         usb_ep_set_maxpacket_limit(&ep->ep, &ep->ep.maxpacket);
      Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
      Reviewed-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      d246c9d5
    • R
      usb: musb: core: Fix remote-wakeup resume · 33f8d75f
      Roger Quadros 提交于
      During resume don't touch SUSPENDM/RESUME bits of POWER register
      while restoring controller context. These bits might be changed
      by the controller during resume operation and so will be different
      than what they were during suspend.
      
      e.g. SUSPENDM bit is set by software during USB global suspend but
      automatically cleared by the controller during remote wakeup or
      during resume. Setting this bit back while restoring context
      causes undesired behaviour. i.e. Babble interrupt is generated
      and USB is broken.
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      33f8d75f
    • A
      usb: musb: host: Fix SuperSpeed hub enumeration · 3c4653c1
      Ajay Kumar Gupta 提交于
      Disables PING on status phase of control transfer.
      PING token is not mandatory in status phase of control transfer
      and so some high speed USB devices don't support it. If such devices
      are connected to MUSB then they would not respond to PING token
      causing delayed or failed enumeration.
      
      [Roger Q] Fixes enumeration issues with some Super-Speed USB hubs
      e.g. Dlink DUB-1340
      Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      3c4653c1
  3. 18 2月, 2014 1 次提交
    • F
      usb: musb: fix obex in g_nokia.ko causing kernel panic · 30a70b02
      Felipe Balbi 提交于
      phy_power_off() can, depending on the PHY being used,
      start I2C transactions which shouldn't happen in
      atomic context.
      
      Current call to phy_power_off() inside omap2430_runtime
      callbacks causes the following dump, as a fix, just don't
      power off the PHY in runtime.
      
      [   18.606414] [<c037eac0>] (__schedule+0x5c/0x50c) from [<c037d3bc>] (schedule_timeout+0x1f4/0x25c)
      [   18.623809] [<c037d3bc>] (schedule_timeout+0x1f4/0x25c) from [<c037f12c>] (wait_for_common+0xc8/0x1ac)
      [   18.649291] [<c037f12c>] (wait_for_common+0xc8/0x1ac) from [<c028c1c0>] (omap_i2c_xfer+0x338/0x488)
      [   18.674499] [<c028c1c0>] (omap_i2c_xfer+0x338/0x488) from [<c0288144>] (__i2c_transfer+0x40/0x74)
      [   18.692047] [<c0288144>] (__i2c_transfer+0x40/0x74) from [<c0288a2c>] (i2c_transfer+0x6c/0x90)
      [   18.709320] [<c0288a2c>] (i2c_transfer+0x6c/0x90) from [<c02351c8>] (regmap_i2c_read+0x48/0x68)
      [   18.726715] [<c02351c8>] (regmap_i2c_read+0x48/0x68) from [<c023161c>] (_regmap_raw_read+0x128/0x220)
      [   18.752685] [<c023161c>] (_regmap_raw_read+0x128/0x220) from [<c02317b4>] (regmap_raw_read+0xa0/0x130)
      [   18.779052] [<c02317b4>] (regmap_raw_read+0xa0/0x130) from [<c023193c>] (regmap_bulk_read+0xf8/0x16c)
      [   18.805694] [<c023193c>] (regmap_bulk_read+0xf8/0x16c) from [<c0238ea8>] (twl_i2c_read+0xa4/0xe0)
      [   18.823730] [<c0238ea8>] (twl_i2c_read+0xa4/0xe0) from [<c0274d34>] (__twl4030_phy_power.isra.12+0x1c/0x58)
      [   18.850921] [<c0274d34>] (__twl4030_phy_power.isra.12+0x1c/0x58) from [<c0274df0>]
      (twl4030_phy_power.part.14+0x80/0xc8)
      [   18.879699] [<c0274df0>] (twl4030_phy_power.part.14+0x80/0xc8) from [<c0274f9c>]
      (twl4030_set_suspend+0x54/0x1e8)
      [   18.908325] [<c0274f9c>] (twl4030_set_suspend+0x54/0x1e8) from [<c027c8c4>]
      (omap2430_runtime_resume+0x5c/0x64)
      [   18.937042] [<c027c8c4>] (omap2430_runtime_resume+0x5c/0x64) from [<c0225dd0>]
      (pm_generic_runtime_resume+0x2c/0x38)
      [   18.966461] [<c0225dd0>] (pm_generic_runtime_resume+0x2c/0x38) from [<c0229fe0>] (__rpm_callback+0x54/0x80)
      [   18.995117] [<c0229fe0>] (__rpm_callback+0x54/0x80) from [<c022a04c>] (rpm_callback+0x40/0x74)
      [   19.013610] [<c022a04c>] (rpm_callback+0x40/0x74) from [<c022b3c8>] (rpm_resume+0x448/0x63c)
      [   19.031921] [<c022b3c8>] (rpm_resume+0x448/0x63c) from [<c022b2e4>] (rpm_resume+0x364/0x63c)
      [   19.050140] [<c022b2e4>] (rpm_resume+0x364/0x63c) from [<c022b874>] (__pm_runtime_resume+0x48/0x74)
      [   19.077728] [<c022b874>] (__pm_runtime_resume+0x48/0x74) from [<c027b4fc>] (musb_gadget_pullup+0x1c/0xb4)
      [   19.105895] [<c027b4fc>] (musb_gadget_pullup+0x1c/0xb4) from [<bf025c14>] (usb_function_deactivate+0x54/0xa4
      [libcomposite])
      [   19.135955] [<bf025c14>] (usb_function_deactivate+0x54/0xa4 [libcomposite]) from [<bf05b3b8>]
      (obex_bind+0x124/0x1d8 [usb_f_obex])
      [   19.166870] [<bf05b3b8>] (obex_bind+0x124/0x1d8 [usb_f_obex]) from [<bf025794>] (usb_add_function+0x58/0xf4
      [libcomposite])
      [   19.197143] [<bf025794>] (usb_add_function+0x58/0xf4 [libcomposite]) from [<bf037420>]
      (nokia_bind_config+0x204/0x250 [g_nokia])
      [   19.227905] [<bf037420>] (nokia_bind_config+0x204/0x250 [g_nokia]) from [<bf0263fc>] (usb_add_config+0x28/0xc0
      [libcomposite])
      [   19.258483] [<bf0263fc>] (usb_add_config+0x28/0xc0 [libcomposite]) from [<bf03709c>] (nokia_bind+0x9c/0x21c
      [g_nokia])
      [   19.288421] [<bf03709c>] (nokia_bind+0x9c/0x21c [g_nokia]) from [<bf0275bc>] (composite_bind+0x74/0x180
      [libcomposite])
      [   19.318420] [<bf0275bc>] (composite_bind+0x74/0x180 [libcomposite]) from [<c027d658>]
      (udc_bind_to_driver+0x2c/0xc4)
      [   19.348114] [<c027d658>] (udc_bind_to_driver+0x2c/0xc4) from [<c027d764>] (usb_gadget_probe_driver+0x74/0x94)
      [   19.377166] [<c027d764>] (usb_gadget_probe_driver+0x74/0x94) from [<c00086f8>] (do_one_initcall+0x94/0x138)
      [   19.406005] [<c00086f8>] (do_one_initcall+0x94/0x138) from [<c007a460>] (load_module+0x113c/0x13c4)
      [   19.434051] [<c007a460>] (load_module+0x113c/0x13c4) from [<c007a7b4>] (SyS_init_module+0xcc/0xec)
      [   19.462127] [<c007a7b4>] (SyS_init_module+0xcc/0xec) from [<c000dd40>] (ret_fast_syscall+0x0/0x30)
      [   19.490753] Code: 0a00002e e1a00004 eb001438 e598300c (e5d3202c)
      [   19.506805] ---[ end trace 060b62ec0d68a78b ]---
      [   19.523132] Kernel panic - not syncing: Fatal exception in interrupt
      
      dump is from 3.12-rc5 kernel
      Reported-by: NPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      30a70b02
  4. 12 2月, 2014 2 次提交
    • R
      usb: option: blacklist ZTE MF667 net interface · 3635c7e2
      Raymond Wanyoike 提交于
      Interface #5 of 19d2:1270 is a net interface which has been submitted to the
      qmi_wwan driver so consequently remove it from the option driver.
      Signed-off-by: NRaymond Wanyoike <raymond.wanyoike@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3635c7e2
    • G
      Merge tag 'for-usb-linus-2014-02-11' of... · 2991942f
      Greg Kroah-Hartman 提交于
      Merge tag 'for-usb-linus-2014-02-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
      
      Sarah writes:
      
      xhci: Revert TD fragment hacks.
      
      Hi Greg,
      
      Recently, we found that commit "35773dac "usb: xhci: Link TRB must not
      occur within a USB payload burst" causes a userspace regression.  It will
      cause larger transfers submitted through usbfs that would have succeeded
      on older kernels to be rejected.
      
      Commit 35773dac was designed to address an issue where an ASIX USB
      ethernet device would get wedged when it was connected to a 1.0 xHCI
      host.  Only this particular ethernet device was impacted, because only the
      ax88179_178a driver implemented scatter-gather in 3.12.  The xHCI driver
      doesn't currently support TD fragment rules, and commit 35773dac was a
      quick hack that partially implemented one of the rules.
      
      This is the third regression this patch has caused.  There's yet another
      quick hack to work around the issue, but I really want to support TD
      fragments properly, rather than hacking around it.  It will take us a
      kernel release or two to get it implemented, since it is a big
      architectural change.
      
      This patchset backs out commit 35773dac, and the two bug fix patches
      for it.  The first patch limits arbitrarily aligned scatter-gather under
      xHCI 1.0 hosts.
      
      As a result of this patchset:
      
      1. usb-storage and uas will still be able to use scatter-gather, since
         they submit max packet sized aligned transfers.
      2. usbfs will behave exactly as before, no more userspace regressions.
      3. The ax88179_178a driver works fine without scatter-gather (Mark Lord
         confirms this).
      
      Users of the ASIX chipset may still see occasional packet loss on 1.0 xHCI
      hosts, if the xHCI driver needs to split a TRB across 64-KB boundaries,
      and a link TRB happens to fall between those two TRBs.  I expect this
      corner case to be infrequent.
      
      Sarah Sharp
      2991942f
  5. 08 2月, 2014 5 次提交
    • S
      Revert "usb: xhci: Link TRB must not occur within a USB payload burst" · 3d4b81ed
      Sarah Sharp 提交于
      This reverts commit 35773dac.  It's a
      hack that caused regressions in the usb-storage and userspace USB
      drivers that use usbfs and libusb.  Commit 70cabb7d992f "xhci 1.0: Limit
      arbitrarily-aligned scatter gather." should fix the issues seen with the
      ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org # 3.12
      3d4b81ed
    • S
      Revert "xhci: Avoid infinite loop when sg urb requires too many trbs" · 9cf00d91
      Sarah Sharp 提交于
      This reverts commit d6c9ea90.
      
      We are ripping out commit 35773dac "usb:
      xhci: Link TRB must not occur within a USB payload burst" because it's a
      hack that caused regressions in the usb-storage and userspace USB
      drivers that use usbfs and libusb.  This commit attempted to fix the
      issues with that patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org # 3.12
      9cf00d91
    • S
      Revert "xhci: Set scatter-gather limit to avoid failed block writes." · 1386ff75
      Sarah Sharp 提交于
      This reverts commit f2d9b991.
      
      We are ripping out commit 35773dac "usb:
      xhci: Link TRB must not occur within a USB payload burst" because it's a
      hack that caused regressions in the usb-storage and userspace USB
      drivers that use usbfs and libusb.  This commit attempted to fix the
      issues with that patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org #3.12
      1386ff75
    • S
      xhci 1.0: Limit arbitrarily-aligned scatter gather. · 247bf557
      Sarah Sharp 提交于
      xHCI 1.0 hosts have a set of requirements on how to align transfer
      buffers on the endpoint rings called "TD fragment" rules.  When the
      ax88179_178a driver added support for scatter gather in 3.12, with
      commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a:
      enable tso if usb host supports sg dma", it broke the device under xHCI
      1.0 hosts.  Under certain network loads, the device would see an
      unexpected short packet from the host, which would cause the device to
      stop sending ethernet packets, even through USB packets would still be
      sent.
      
      Commit 35773dac "usb: xhci: Link TRB must not occur within a USB
      payload burst" attempted to fix this.  It was a quick hack to partially
      implement the TD fragment rules.  However, it caused regressions in the
      usb-storage layer and userspace USB drivers using libusb.  The patches
      to attempt to fix this are too far reaching into the USB core, and we
      really need to implement the TD fragment rules correctly in the xHCI
      driver, instead of continuing to wallpaper over the issues.
      
      Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0
      hosts.  Only the ax88179_178a driver checks the no_sg_constraint flag,
      so don't set it for 1.0 hosts.  This should not impact usb-storage or
      usbfs behavior, since they pass down max packet sized aligned sg-list
      entries (512 for USB 2.0 and 1024 for USB 3.0).
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NMark Lord <mlord@pobox.com>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Bjørn Mork <bjorn@mork.no>
      Cc: Freddy Xin <freddy@asix.com.tw>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: stable@vger.kernel.org # 3.12
      247bf557
    • J
      Modpost: fixed USB alias generation for ranges including 0x9 and 0xA · 03b56329
      Jan Moskyto Matejka 提交于
      Commit afe2dab4 ("USB: add hex/bcd detection to usb modalias generation")
      changed the routine that generates alias ranges. Before that change, only
      digits 0-9 were supported; the commit tried to fix the case when the range
      includes higher values than 0x9.
      
      Unfortunately, the commit didn't fix the case when the range includes both
      0x9 and 0xA, meaning that the final range must look like [x-9A-y] where
      x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced.
      
      Modprobe doesn't complain as it sees no difference between no-match and
      bad-pattern results of fnmatch().
      
      Fixing this simple bug to fix the aliases.
      Also changing the hardcoded beginning of the range to uppercase as all the
      other letters are also uppercase in the device version numbers.
      
      Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK.
      Signed-off-by: NJan Moskyto Matejka <mq@suse.cz>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03b56329
  6. 06 2月, 2014 3 次提交
  7. 05 2月, 2014 10 次提交
  8. 03 2月, 2014 11 次提交