1. 13 1月, 2017 1 次提交
  2. 12 1月, 2017 1 次提交
    • T
      drm: Fix broken VT switch with video=1366x768 option · fdf35a6b
      Takashi Iwai 提交于
      I noticed that the VT switch doesn't work any longer with a Dell
      laptop with 1366x768 eDP when the machine is connected with a DP
      monitor.  It behaves as if VT were switched, but the graphics remain
      frozen.  Actually the keyboard works, so I could switch back to VT7
      again.
      
      I tried to track down the problem, and encountered a long story until
      we reach to this error:
      
      - The machine is booted with video=1366x768 option (the distro
        installer seems to add it as default).
      - Recently, drm_helper_probe_single_connector_modes() deals with
        cmdline modes, and it tries to create a new mode when no
        matching mode is found.
      - The drm_mode_create_from_cmdline_mode() creates a mode based on
        either CVT of GFT according to the given cmdline mode; in our case,
        it's 1366x768.
      - Since both CVT and GFT can't express the width 1366 due to
        alignment, the resultant mode becomes 1368x768, slightly larger than
        the given size.
      - Later on, the atomic commit is performed, and in
        drm_atomic_check_only(), the size of each plane is checked.
      - The size check of 1366x768 fails due to the above, and eventually
        the whole VT switch fails.
      
      Back in the history, we've had a manual fix-up of 1368x768 in various
      places via c09dedb7 ("drm/edid: Add a workaround for 1366x768 HD
      panel"), but they have been all in drm_edid.c at probing the modes
      from EDID.  For addressing the problem above, we need a similar hack
      to the mode newly created from cmdline, manually adjusting the width
      when the expected size is 1366 while we get 1368 instead.
      
      Fixes: eaf99c74 ("drm: Perform cmdline mode parsing during...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.deReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      fdf35a6b
  3. 10 1月, 2017 1 次提交
  4. 09 1月, 2017 1 次提交
    • M
      drm/bridge: analogix dp: Fix runtime PM state on driver bind · f0a8b49c
      Marek Szyprowski 提交于
      Analogix_dp_bind() can be called from component framework, which doesn't
      guarantee proper runtime PM state of the device during bind operation,
      so ensure that device is runtime active before doing any register access.
      This ensures that the power domain, to which DP module belongs, is turned
      on. While at it, also fix the unbalanced call to phy_power_on() in
      analogix_dp_bind() function.
      
      This patch solves the following kernel oops on Samsung Exynos5250 Snow
      board:
      
      Unhandled fault: imprecise external abort (0x406) at 0x00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: : 406 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 75 Comm: kworker/0:2 Not tainted 4.9.0 #1046
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events deferred_probe_work_func
      task: ee272300 task.stack: ee312000
      PC is at analogix_dp_enable_sw_function+0x18/0x2c
      LR is at analogix_dp_init_dp+0x2c/0x50
      ...
      [<c03fcb38>] (analogix_dp_enable_sw_function) from [<c03fa9c4>] (analogix_dp_init_dp+0x2c/0x50)
      [<c03fa9c4>] (analogix_dp_init_dp) from [<c03fab6c>] (analogix_dp_bind+0x184/0x42c)
      [<c03fab6c>] (analogix_dp_bind) from [<c03fdb84>] (component_bind_all+0xf0/0x218)
      [<c03fdb84>] (component_bind_all) from [<c03ed64c>] (exynos_drm_load+0x134/0x200)
      [<c03ed64c>] (exynos_drm_load) from [<c03d5058>] (drm_dev_register+0xa0/0xd0)
      [<c03d5058>] (drm_dev_register) from [<c03d66b8>] (drm_platform_init+0x58/0xb0)
      [<c03d66b8>] (drm_platform_init) from [<c03fe0c4>] (try_to_bring_up_master+0x14c/0x188)
      [<c03fe0c4>] (try_to_bring_up_master) from [<c03fe188>] (component_add+0x88/0x138)
      [<c03fe188>] (component_add) from [<c0403a38>] (platform_drv_probe+0x50/0xb0)
      [<c0403a38>] (platform_drv_probe) from [<c0402470>] (driver_probe_device+0x1f0/0x2a8)
      [<c0402470>] (driver_probe_device) from [<c0400a54>] (bus_for_each_drv+0x44/0x8c)
      [<c0400a54>] (bus_for_each_drv) from [<c04021f8>] (__device_attach+0x9c/0x100)
      [<c04021f8>] (__device_attach) from [<c04018e8>] (bus_probe_device+0x84/0x8c)
      [<c04018e8>] (bus_probe_device) from [<c0401d1c>] (deferred_probe_work_func+0x60/0x8c)
      [<c0401d1c>] (deferred_probe_work_func) from [<c012fc14>] (process_one_work+0x120/0x318)
      [<c012fc14>] (process_one_work) from [<c012fe34>] (process_scheduled_works+0x28/0x38)
      [<c012fe34>] (process_scheduled_works) from [<c0130048>] (worker_thread+0x204/0x4ac)
      [<c0130048>] (worker_thread) from [<c01352c4>] (kthread+0xd8/0xf4)
      [<c01352c4>] (kthread) from [<c0107978>] (ret_from_fork+0x14/0x3c)
      Code: e59035f0 e5935018 f57ff04f e3c55001 (f57ff04e)
      ---[ end trace 3d1d0d87796de344 ]---
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/1483091866-1088-1-git-send-email-m.szyprowski@samsung.com
      f0a8b49c
  5. 07 1月, 2017 10 次提交
  6. 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
  7. 05 1月, 2017 16 次提交
  8. 04 1月, 2017 1 次提交