1. 23 1月, 2017 3 次提交
  2. 07 1月, 2017 1 次提交
  3. 06 1月, 2017 9 次提交
    • A
      USB: fix problems with duplicate endpoint addresses · 0a8fd134
      Alan Stern 提交于
      When checking a new device's descriptors, the USB core does not check
      for duplicate endpoint addresses.  This can cause a problem when the
      sysfs files for those endpoints are created; trying to create multiple
      files with the same name will provoke a WARNING:
      
      WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
      sysfs: cannot create duplicate filename
      '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05'
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
       ffff88006bee64c8 ffffffff81f96b8a ffffffff00000001 1ffff1000d7dcc2c
       ffffed000d7dcc24 0000000000000001 0000000041b58ab3 ffffffff8598b510
       ffffffff81f968f8 ffffffff850fee20 ffffffff85cff020 dffffc0000000000
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff8168c88e>] panic+0x1cb/0x3a9 kernel/panic.c:179
       [<ffffffff812b80b4>] __warn+0x1c4/0x1e0 kernel/panic.c:542
       [<ffffffff812b8195>] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
       [<ffffffff819e70ca>] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30
       [<ffffffff819e7308>] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59
       [<     inline     >] create_dir lib/kobject.c:71
       [<ffffffff81fa1b07>] kobject_add_internal+0x227/0xa60 lib/kobject.c:229
       [<     inline     >] kobject_add_varg lib/kobject.c:366
       [<ffffffff81fa2479>] kobject_add+0x139/0x220 lib/kobject.c:411
       [<ffffffff82737a63>] device_add+0x353/0x1660 drivers/base/core.c:1088
       [<ffffffff82738d8d>] device_register+0x1d/0x20 drivers/base/core.c:1206
       [<ffffffff82cb77d3>] usb_create_ep_devs+0x163/0x260 drivers/usb/core/endpoint.c:195
       [<ffffffff82c9f27b>] create_intf_ep_devs+0x13b/0x200 drivers/usb/core/message.c:1030
       [<ffffffff82ca39d3>] usb_set_configuration+0x1083/0x18d0 drivers/usb/core/message.c:1937
       [<ffffffff82cc9e2e>] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172
       [<ffffffff82caa7fa>] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263
      
      This patch prevents the problem by checking for duplicate endpoint
      addresses during enumeration and skipping any duplicates.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a8fd134
    • P
      usb: ohci-at91: use descriptor-based gpio APIs correctly · 8f12dc24
      Peter Rosin 提交于
      The gpiod_get* function family does not want the -gpio suffix.
      Use devm_gpiod_get_index_optional instead of devm_gpiod_get_optional.
      The descriptor based APIs handle active high/low automatically.
      The vbus-gpios are output, request enable while getting the gpio.
      Don't try to get any vbus-gpios for ports outside num-ports.
      
      WTF? Big sigh.
      
      Fixes: 054d4b7b ("usb: ohci-at91: Use descriptor-based gpio APIs")
      Signed-off-by: NPeter Rosin <peda@axentia.se>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f12dc24
    • O
      usb: storage: unusual_uas: Add JMicron JMS56x to unusual device · 674aea07
      Oliver Neukum 提交于
      This device gives the following error on detection.
      xhci_hcd 0000:00:11.0: ERROR Transfer event for disabled endpoint or
      incorrect stream ring
      
      The same error is not seen when it is added to unusual_device
      list with US_FL_NO_REPORT_OPCODES passed.
      Signed-off-by: NGeorge Cherian <george.cherian@cavium.com>
      Signed-off-by: NOliver Neukum <oneukun@suse.com>
      CC: stable@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      674aea07
    • G
      usb: hub: Move hub_port_disable() to fix warning if PM is disabled · 3bc02bce
      Geert Uytterhoeven 提交于
      If CONFIG_PM=n:
      
          drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called
          drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here
      
      To fix this, move hub_port_disable() after
      hub_usb3_port_prepare_disable(), and adjust forward declarations.
      
      Fixes: 37be6676 ("usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices")
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3bc02bce
    • J
      usb: musb: blackfin: add bfin_fifo_offset in bfin_ops · 5563bb57
      Jérémy Lefaure 提交于
      The function bfin_fifo_offset is defined but not used:
      
      drivers/usb/musb/blackfin.c:36:12: warning: ‘bfin_fifo_offset’ defined
      but not used [-Wunused-function]
       static u32 bfin_fifo_offset(u8 epnum)
                   ^~~~~~~~~~~~~~~~
      
      Adding bfin_fifo_offset to bfin_ops fixes this warning and allows musb
      core to call this function instead of default_fifo_offset.
      
      Fixes: cc92f681 ("usb: musb: Populate new IO functions for blackfin")
      Signed-off-by: NJérémy Lefaure <jeremy.lefaure@lse.epita.fr>
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5563bb57
    • J
      usb: musb: fix compilation warning on unused function · c8bd2ac3
      Jérémy Lefaure 提交于
      The function musb_run_resume_work is called only when CONFIG_PM is
      enabled. So this function should not be defined when CONFIG_PM is
      disabled. Otherwise the compiler issues a warning:
      
      drivers/usb/musb/musb_core.c:2057:12: error: ‘musb_run_resume_work’ defined but
      not used [-Werror=unused-function]
       static int musb_run_resume_work(struct musb *musb)
                  ^~~~~~~~~~~~~~~~~~~~
      Signed-off-by: NJérémy Lefaure <jeremy.lefaure@lse.epita.fr>
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8bd2ac3
    • T
      usb: musb: Fix trying to free already-free IRQ 4 · 8c300fe2
      Tony Lindgren 提交于
      When unloading omap2430, we can get the following splat:
      
      WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8
      Trying to free already-free IRQ 4
      ...
      [<c01a8b78>] (free_irq) from [<bf0aea84>]
      (musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc])
      [<bf0aea84>] (musbhs_dma_controller_destroy [musb_hdrc]) from
      [<bf09f88c>] (musb_remove+0xf0/0x12c [musb_hdrc])
      [<bf09f88c>] (musb_remove [musb_hdrc]) from [<c056a384>]
      (platform_drv_remove+0x24/0x3c)
      ...
      
      This is because the irq number in use is 260 nowadays, and the dma
      controller is using u8 instead of int.
      
      Fixes: 6995eb68 ("USB: musb: enable low level DMA operation for Blackfin")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      [b-liu@ti.com: added Fixes tag]
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c300fe2
    • B
      usb: musb: dsps: implement clear_ep_rxintr() callback · c48400ba
      Bin Liu 提交于
      During dma teardown for dequque urb, if musb load is high, musb might
      generate bogus rx ep interrupt even when the rx fifo is flushed. In such
      case any of the follow log messages could happen.
      
          musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0
      
          musb_host_rx 1936: RX3 dma busy, csr 2020
      
      As mentioned in the current inline comment, clearing ep interrupt in the
      teardown path avoids the bogus interrupt, so implement clear_ep_rxintr()
      callback.
      
      This bug seems to be existing since the initial driver for musb support,
      but I only validated the fix back to v4.1, so only cc stable for v4.1+.
      
      cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c48400ba
    • B
      usb: musb: core: add clear_ep_rxintr() to musb_platform_ops · 6def85a3
      Bin Liu 提交于
      During dma teardown for dequque urb, if musb load is high, musb might
      generate bogus rx ep interrupt even when the rx fifo is flushed. In such
      case any of the follow log messages could happen.
      
      	musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0
      
      	musb_host_rx 1936: RX3 dma busy, csr 2020
      
      As mentioned in the current inline comment, clearing ep interrupt in the
      teardown path avoids the bogus interrupt.
      
      Clearing ep interrupt is platform dependent, so this patch adds a
      platform callback to allow glue driver to clear the ep interrupt.
      
      This bug seems to be existing since the initial driver for musb support,
      but I only validated the fix back to v4.1, so only cc stable for v4.1+.
      
      cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6def85a3
  4. 05 1月, 2017 16 次提交
  5. 04 1月, 2017 11 次提交
    • A
      vfio-pci: Handle error from pci_iomap · e19f32da
      Arvind Yadav 提交于
      Here, pci_iomap can fail, handle this case release selected
      pci regions and return -ENOMEM.
      Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      e19f32da
    • H
      iommu/amd: Fix the left value check of cmd buffer · 432abf68
      Huang Rui 提交于
      The generic command buffer entry is 128 bits (16 bytes), so the offset
      of tail and head pointer should be 16 bytes aligned and increased with
      0x10 per command.
      
      When cmd buf is full, head = (tail + 0x10) % CMD_BUFFER_SIZE.
      
      So when left space of cmd buf should be able to store only two
      command, we should be issued one COMPLETE_WAIT additionally to wait
      all older commands completed. Then the left space should be increased
      after IOMMU fetching from cmd buf.
      
      So left check value should be left <= 0x20 (two commands).
      Signed-off-by: NHuang Rui <ray.huang@amd.com>
      Fixes: ac0ea6e9 ('x86/amd-iommu: Improve handling of full command buffer')
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      432abf68
    • J
      iommu/vt-d: Fix pasid table size encoding · 65ca7f5f
      Jacob Pan 提交于
      Different encodings are used to represent supported PASID bits
      and number of PASID table entries.
      The current code assigns ecap_pss directly to extended context
      table entry PTS which is wrong and could result in writing
      non-zero bits to the reserved fields. IOMMU fault reason
      11 will be reported when reserved bits are nonzero.
      This patch converts ecap_pss to extend context entry pts encoding
      based on VT-d spec. Chapter 9.4 as follows:
       - number of PASID bits = ecap_pss + 1
       - number of PASID table entries = 2^(pts + 5)
      Software assigned limit of pasid_max value is also respected to
      match the allocation limitation of PASID table.
      
      cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      cc: Ashok Raj <ashok.raj@intel.com>
      Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
      Tested-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Fixes: 2f26e0a9 ('iommu/vt-d: Add basic SVM PASID support')
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      65ca7f5f
    • X
      iommu/vt-d: Flush old iommu caches for kdump when the device gets context mapped · aec0e861
      Xunlei Pang 提交于
      We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
      under kdump, it can be steadily reproduced on several different machines,
      the dmesg log is like:
      HP HPSA Driver (v 3.4.16-0)
      hpsa 0000:02:00.0: using doorbell to reset controller
      hpsa 0000:02:00.0: board ready after hard reset.
      hpsa 0000:02:00.0: Waiting for controller to respond to no-op
      DMAR: Setting identity map for device 0000:02:00.0 [0xe8000 - 0xe8fff]
      DMAR: Setting identity map for device 0000:02:00.0 [0xf4000 - 0xf4fff]
      DMAR: Setting identity map for device 0000:02:00.0 [0xbdf6e000 - 0xbdf6efff]
      DMAR: Setting identity map for device 0000:02:00.0 [0xbdf6f000 - 0xbdf7efff]
      DMAR: Setting identity map for device 0000:02:00.0 [0xbdf7f000 - 0xbdf82fff]
      DMAR: Setting identity map for device 0000:02:00.0 [0xbdf83000 - 0xbdf84fff]
      DMAR: DRHD: handling fault status reg 2
      DMAR: [DMA Read] Request device [02:00.0] fault addr fffff000 [fault reason 06] PTE Read access is not set
      hpsa 0000:02:00.0: controller message 03:00 timed out
      hpsa 0000:02:00.0: no-op failed; re-trying
      
      After some debugging, we found that the fault addr is from DMA initiated at
      the driver probe stage after reset(not in-flight DMA), and the corresponding
      pte entry value is correct, the fault is likely due to the old iommu caches
      of the in-flight DMA before it.
      
      Thus we need to flush the old cache after context mapping is setup for the
      device, where the device is supposed to finish reset at its driver probe
      stage and no in-flight DMA exists hereafter.
      
      I'm not sure if the hardware is responsible for invalidating all the related
      caches allocated in the iommu hardware before, but seems not the case for hpsa,
      actually many device drivers have problems in properly resetting the hardware.
      Anyway flushing (again) by software in kdump kernel when the device gets context
      mapped which is a quite infrequent operation does little harm.
      
      With this patch, the problematic machine can survive the kdump tests.
      
      CC: Myron Stowe <myron.stowe@gmail.com>
      CC: Joseph Szczypek <jszczype@redhat.com>
      CC: Don Brace <don.brace@microsemi.com>
      CC: Baoquan He <bhe@redhat.com>
      CC: Dave Young <dyoung@redhat.com>
      Fixes: 091d42e4 ("iommu/vt-d: Copy translation tables from old kernel")
      Fixes: dbcd861f ("iommu/vt-d: Do not re-use domain-ids from the old kernel")
      Fixes: cf484d0e ("iommu/vt-d: Mark copied context entries")
      Signed-off-by: NXunlei Pang <xlpang@redhat.com>
      Tested-by: NDon Brace <don.brace@microsemi.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      aec0e861
    • A
      video: fbdev: cobalt_lcdfb: Handle return NULL error from devm_ioremap · 4dcd19bf
      Arvind Yadav 提交于
      Here, If devm_ioremap will fail. It will return NULL.
      Kernel can run into a NULL-pointer dereference.
      This error check will avoid NULL pointer dereference.
      Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
      Acked-by: NYoichi Yuasa <yuasa@linux-mips.org>
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      4dcd19bf
    • J
      USB: serial: ti_usb_3410_5052: fix NULL-deref at open · ef079936
      Johan Hovold 提交于
      Fix NULL-pointer dereference in open() should a malicious device lack
      the expected endpoints:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000030
      ..
      [<bf06a6b0>] (ti_open [ti_usb_3410_5052]) from [<bf02e118>] (serial_port_activate+0x68/0x98 [usbserial])
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      ef079936
    • J
      USB: serial: spcp8x5: fix NULL-deref at open · cc090924
      Johan Hovold 提交于
      Fix NULL-pointer dereference in open() should the device lack the
      expected endpoints:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000030
      ...
      PC is at spcp8x5_open+0x30/0xd0 [spcp8x5]
      
      Fixes: 619a6f1d ("USB: add usb-serial spcp8x5 driver")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      cc090924
    • J
      USB: serial: quatech2: fix sleep-while-atomic in close · f09d1886
      Johan Hovold 提交于
      The write URB was being killed using the synchronous interface while
      holding a spin lock in close().
      
      Simply drop the lock and busy-flag update, something which would have
      been taken care of by the completion handler if the URB was in flight.
      
      Fixes: f7a33e60 ("USB: serial: add quatech2 usb to serial driver")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      f09d1886
    • J
      USB: serial: pl2303: fix NULL-deref at open · 76ab439e
      Johan Hovold 提交于
      Fix NULL-pointer dereference in open() should a type-0 or type-1 device
      lack the expected endpoints:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000030
      ...
      PC is at pl2303_open+0x38/0xec [pl2303]
      
      Note that a missing interrupt-in endpoint would have caused open() to
      fail.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      76ab439e
    • J
      USB: serial: oti6858: fix NULL-deref at open · 5afeef23
      Johan Hovold 提交于
      Fix NULL-pointer dereference in open() should the device lack the
      expected endpoints:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000030
      ...
      PC is at oti6858_open+0x30/0x1d0 [oti6858]
      
      Note that a missing interrupt-in endpoint would have caused open() to
      fail.
      
      Fixes: 49cdee0e ("USB: oti6858 usb-serial driver (in Nokia CA-42
      cable)")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      5afeef23
    • J
      USB: serial: omninet: fix NULL-derefs at open and disconnect · a5bc0194
      Johan Hovold 提交于
      Fix NULL-pointer dereferences at open() and disconnect() should the
      device lack the expected bulk-out endpoints:
      
      Unable to handle kernel NULL pointer dereference at virtual address 000000b4
      ...
      [c0170ff0>] (__lock_acquire) from [<c0172f00>] (lock_acquire+0x108/0x264)
      [<c0172f00>] (lock_acquire) from [<c06a5090>] (_raw_spin_lock_irqsave+0x58/0x6c)
      [<c06a5090>] (_raw_spin_lock_irqsave) from [<c0470684>] (tty_port_tty_set+0x28/0xa4)
      [<c0470684>] (tty_port_tty_set) from [<bf08d384>] (omninet_open+0x30/0x40 [omninet])
      [<bf08d384>] (omninet_open [omninet]) from [<bf07c118>] (serial_port_activate+0x68/0x98 [usbserial])
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000234
      ...
      [<bf01f418>] (omninet_disconnect [omninet]) from [<bf0016c0>] (usb_serial_disconnect+0xe4/0x100 [usbserial])
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      a5bc0194