1. 13 12月, 2018 12 次提交
  2. 08 12月, 2018 20 次提交
    • A
      Input: elan_i2c - add support for ELAN0621 touchpad · 280d652e
      Adam Wong 提交于
      commit bf87ade0 upstream.
      
      Added the ability to detect the ELAN0621 touchpad found in some Lenovo
      laptops.
      Signed-off-by: NAdam Wong <adam@adamwong.me>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      280d652e
    • N
      Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR · 77dd91ca
      Noah Westervelt 提交于
      commit ad33429c upstream.
      
      Add ELAN061E to the ACPI table to support Elan touchpad found in Lenovo
      IdeaPad 330-15ARR.
      Signed-off-by: NNoah Westervelt <nwestervelt@outlook.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      77dd91ca
    • P
      Input: elan_i2c - add ELAN0620 to the ACPI table · 08a7e486
      Patrick Gaskin 提交于
      commit 3ed64da3 upstream.
      
      Add ELAN0620 to the ACPI table to support the elan touchpad in
      the Lenovo IdeaPad 130-15IKB.
      Signed-off-by: NPatrick Gaskin <patrick@pgaskin.net>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08a7e486
    • B
      Input: cros_ec_keyb - fix button/switch capability reports · 918cd7d1
      Brian Norris 提交于
      commit ac5722c1 upstream.
      
      The cros_ec_keyb_bs array lists buttons and switches together, expecting
      that its users will match the appropriate type and bit fields. But
      cros_ec_keyb_register_bs() only checks the 'bit' field, which causes
      misreported input capabilities in some cases. For example, tablets
      (e.g., Scarlet -- a.k.a. Acer Chromebook Tab 10) were reporting a SW_LID
      capability, because EC_MKBP_POWER_BUTTON and EC_MKBP_LID_OPEN happen to
      share the same bit.
      
      (This has comedic effect on a tablet, in which a power-management daemon
      then thinks this "lid" is closed, and so puts the system to sleep as
      soon as it boots!)
      
      To fix this, check both the 'ev_type' and 'bit' fields before reporting
      the capability.
      
      Tested with a lid (Kevin / Samsung Chromebook Plus) and without a lid
      (Scarlet / Acer Chromebook Tab 10).
      
      This error got introduced when porting the feature from the downstream
      Chromium OS kernel to be upstreamed.
      
      Fixes: cdd7950e ("input: cros_ec_keyb: Add non-matrix buttons and switches")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      918cd7d1
    • C
      Input: matrix_keypad - check for errors from of_get_named_gpio() · 25e78d05
      Christian Hoff 提交于
      commit d55bda1b upstream.
      
      "of_get_named_gpio()" returns a negative error value if it fails
      and drivers should check for this. This missing check was now
      added to the matrix_keypad driver.
      
      In my case "of_get_named_gpio()" returned -EPROBE_DEFER because
      the referenced GPIOs belong to an I/O expander, which was not yet
      probed at the point in time when the matrix_keypad driver was
      loading. Because the driver did not check for errors from the
      "of_get_named_gpio()" routine, it was assuming that "-EPROBE_DEFER"
      is actually a GPIO number and continued as usual, which led to further
      errors like this later on:
      
      WARNING: CPU: 3 PID: 167 at drivers/gpio/gpiolib.c:114
      gpio_to_desc+0xc8/0xd0
      invalid GPIO -517
      
      Note that the "GPIO number" -517 in the error message above is
      actually "-EPROBE_DEFER".
      
      As part of the patch a misleading error message "no platform data defined"
      was also removed. This does not lead to information loss because the other
      error paths in matrix_keypad_parse_dt() already print an error.
      Signed-off-by: NChristian Hoff <christian_hoff@gmx.net>
      Suggested-by: NSebastian Reichel <sre@kernel.org>
      Reviewed-by: NSebastian Reichel <sre@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25e78d05
    • L
      Input: synaptics - add PNP ID for ThinkPad P50 to SMBus · 16739005
      Lyude Paul 提交于
      commit 9df39bed upstream.
      
      Noticed the other day the trackpoint felt different on my P50, then
      realized it was because rmi4 wasn't loading for this machine
      automatically. Suspend/resume, hibernate, and everything else seem to
      work perfectly fine on here.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16739005
    • C
      Input: xpad - quirk all PDP Xbox One gamepads · 58a99d37
      Cameron Gutman 提交于
      commit a6754fae1e66e9a40fed406290d7ca3f2b4d227c upstream.
      
      Since we continue to find tons of new variants [0,1,2,3,4,5,6] that
      need the PDP quirk, let's just quirk all devices from PDP.
      
      [0]: https://github.com/paroj/xpad/pull/104
      [1]: https://github.com/paroj/xpad/pull/105
      [2]: https://github.com/paroj/xpad/pull/108
      [3]: https://github.com/paroj/xpad/pull/109
      [4]: https://github.com/paroj/xpad/pull/112
      [5]: https://github.com/paroj/xpad/pull/115
      [6]: https://github.com/paroj/xpad/pull/116
      
      Fixes: e5c9c6a8 ("Input: xpad - add support for PDP Xbox One controllers")
      Cc: stable@vger.kernel.org
      Signed-off-by: NCameron Gutman <aicommander@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58a99d37
    • M
      scsi: lpfc: fix block guard enablement on SLI3 adapters · c47bb7af
      Martin Wilck 提交于
      commit dfb75133 upstream.
      
      Since f44ac12f, BG enablement is tracked with the LPFC_SLI3_BG_ENABLED
      bit, which is set in lpfc_get_cfgparam before lpfc_sli_config_sli_port() is
      called. The bit shouldn't be cleared before checking the feature.  Based on
      problem analysis by David Bond.
      
      Fixes: f44ac12f "scsi: lpfc: Memory allocation error during driver start-up on power8"
      Tested-by: NDavid Bond <dbond@suse.com>
      Signed-off-by: NMartin Wilck <mwilck@suse.com>
      Cc: stable@vger.kernel.org # 4.17.x
      Cc: stable@vger.kernel.org # 4.18.x
      Cc: stable@vger.kernel.org # 4.19.x
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Acked-by: NJames Smart <jsmart2021@gmail.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c47bb7af
    • L
      i40e: Fix deletion of MAC filters · 2cb8d55b
      Lihong Yang 提交于
      commit eab077aa84331afbda071a213925d4cdbca58941 upstream.
      
      In __i40e_del_filter function, the flag __I40E_MACVLAN_SYNC_PENDING for
      the PF state is wrongly set for the VSI. Deleting any of the MAC filters
      has caused the incorrect syncing for the PF. Fix it by setting this state
      flag to the intended PF.
      
      CC: stable <stable@vger.kernel.org>
      Signed-off-by: NLihong Yang <lihong.yang@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2cb8d55b
    • L
      kgdboc: Fix warning with module build · e762e140
      Laura Abbott 提交于
      commit 1cd25cbb2fedbc777f3a8c3cb1ba69b645aeaa64 upstream.
      
      After 2dd453168643 ("kgdboc: Fix restrict error"), kgdboc_option_setup is
      now only used when built in, resulting in a warning when compiled as a
      module:
      
      drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but not used [-Wunused-function]
       static int kgdboc_option_setup(char *opt)
                  ^~~~~~~~~~~~~~~~~~~
      
      Move the function under the appropriate ifdef for builtin only.
      
      Fixes: 2dd453168643 ("kgdboc: Fix restrict error")
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e762e140
    • L
      kgdboc: Fix restrict error · 5eede3d0
      Laura Abbott 提交于
      commit 2dd45316 upstream.
      
      There's an error when compiled with restrict:
      
      drivers/tty/serial/kgdboc.c: In function ‘configure_kgdboc’:
      drivers/tty/serial/kgdboc.c:137:2: error: ‘strcpy’ source argument is the same
      as destination [-Werror=restrict]
        strcpy(config, opt);
        ^~~~~~~~~~~~~~~~~~~
      
      As the error implies, this is from trying to use config as both source and
      destination. Drop the call to the function where config is the argument
      since nothing else happens in the function.
      Signed-off-by: NLaura Abbott <labbott@redhat.com>
      Reviewed-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5eede3d0
    • L
      drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut() · 212ad3d7
      Lyude Paul 提交于
      commit 97b2a318 upstream.
      
      Currently on driver bringup with KASAN enabled, meson triggers an OOB
      memory access as shown below:
      
      [  117.904528] ==================================================================
      [  117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
      [  117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
      [  117.904601]
      [  118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
      [  118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [  118.099768] Call trace:
      [  118.102181]  dump_backtrace+0x0/0x3e8
      [  118.105796]  show_stack+0x14/0x20
      [  118.109083]  dump_stack+0x130/0x1c4
      [  118.112539]  print_address_description+0x60/0x25c
      [  118.117214]  kasan_report+0x1b4/0x368
      [  118.120851]  __asan_report_load4_noabort+0x18/0x20
      [  118.125566]  meson_viu_set_osd_lut+0x7a0/0x890
      [  118.129953]  meson_viu_init+0x10c/0x290
      [  118.133741]  meson_drv_bind_master+0x474/0x748
      [  118.138141]  meson_drv_bind+0x10/0x18
      [  118.141760]  try_to_bring_up_master+0x3d8/0x768
      [  118.146249]  component_add+0x214/0x570
      [  118.149978]  meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
      [  118.155404]  platform_drv_probe+0x98/0x138
      [  118.159455]  really_probe+0x2a0/0xa70
      [  118.163070]  driver_probe_device+0x1b4/0x2d8
      [  118.167299]  __driver_attach+0x200/0x280
      [  118.171189]  bus_for_each_dev+0x10c/0x1a8
      [  118.175144]  driver_attach+0x38/0x50
      [  118.178681]  bus_add_driver+0x330/0x608
      [  118.182471]  driver_register+0x140/0x388
      [  118.186361]  __platform_driver_register+0xc8/0x108
      [  118.191117]  meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
      [  118.198022]  do_one_initcall+0x12c/0x3bc
      [  118.201883]  do_init_module+0x1fc/0x638
      [  118.205673]  load_module+0x4b4c/0x6808
      [  118.209387]  __se_sys_init_module+0x2e8/0x3c0
      [  118.213699]  __arm64_sys_init_module+0x68/0x98
      [  118.218100]  el0_svc_common+0x104/0x210
      [  118.221893]  el0_svc_handler+0x48/0xb8
      [  118.225594]  el0_svc+0x8/0xc
      [  118.228429]
      [  118.229887] The buggy address belongs to the variable:
      [  118.235007]  eotf_33_linear_mapping+0x84/0xc0
      [  118.239301]
      [  118.240752] Memory state around the buggy address:
      [  118.245522]  ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.252695]  ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  118.259850] >ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
      [  118.267000]                                ^
      [  118.271222]  ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      [  118.278393]  ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
      [  118.285542] ==================================================================
      [  118.292699] Disabling lock debugging due to kernel taint
      
      It seems that when looping through the OSD EOTF LUT maps, we use the
      same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
      which means that we'll stop out of bounds on the EOTF maps.
      
      But, this whole thing is already confusing enough to read through as-is,
      so let's just replace all of the hardcoded sizes with
      OSD_(OETF/EOTF)_LUT_SIZE / 2.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: <stable@vger.kernel.org> # v4.10+
      Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.comSigned-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      212ad3d7
    • L
      drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config · ea6bb077
      Lyude Paul 提交于
      commit 995b278e upstream.
      
      Seeing as we use this registermap in the context of our IRQ handlers, we
      need to be using spinlocks for reading/writing registers so that we can
      still read them from IRQ handlers without having to grab any mutexes and
      accidentally sleep. We don't currently do this, as pointed out by
      lockdep:
      
      [   18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
      [   18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
      [   18.413864] INFO: lockdep is turned off.
      [   18.417675] irq event stamp: 12
      [   18.420778] hardirqs last  enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
      [   18.429510] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
      [   18.437345] softirqs last  enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
      [   18.446684] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [   18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
      [   18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [   18.480037] Workqueue: hci0 hci_power_on [bluetooth]
      [   18.487138] Call trace:
      [   18.494192]  dump_backtrace+0x0/0x1b8
      [   18.501280]  show_stack+0x14/0x20
      [   18.508361]  dump_stack+0xbc/0xf4
      [   18.515427]  ___might_sleep+0x140/0x1d8
      [   18.522515]  __might_sleep+0x50/0x88
      [   18.529582]  __mutex_lock+0x60/0x870
      [   18.536621]  mutex_lock_nested+0x1c/0x28
      [   18.543660]  regmap_lock_mutex+0x10/0x18
      [   18.550696]  regmap_read+0x38/0x70
      [   18.557727]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
      [   18.564804]  __handle_irq_event_percpu+0xac/0x410
      [   18.571891]  handle_irq_event_percpu+0x34/0x88
      [   18.578982]  handle_irq_event+0x48/0x78
      [   18.586051]  handle_fasteoi_irq+0xac/0x160
      [   18.593061]  generic_handle_irq+0x24/0x38
      [   18.599989]  __handle_domain_irq+0x60/0xb8
      [   18.606857]  gic_handle_irq+0x50/0xa0
      [   18.613659]  el1_irq+0xb4/0x130
      [   18.620394]  debug_lockdep_rcu_enabled+0x2c/0x30
      [   18.627111]  schedule+0x38/0xa0
      [   18.633781]  schedule_timeout+0x3a8/0x510
      [   18.640389]  wait_for_common+0x15c/0x180
      [   18.646905]  wait_for_completion+0x14/0x20
      [   18.653319]  mmc_wait_for_req_done+0x28/0x168
      [   18.659693]  mmc_wait_for_req+0xa8/0xe8
      [   18.665978]  mmc_wait_for_cmd+0x64/0x98
      [   18.672180]  mmc_io_rw_direct_host+0x94/0x130
      [   18.678385]  mmc_io_rw_direct+0x10/0x18
      [   18.684516]  sdio_enable_func+0xe8/0x1d0
      [   18.690627]  btsdio_open+0x24/0xc0 [btsdio]
      [   18.696821]  hci_dev_do_open+0x64/0x598 [bluetooth]
      [   18.703025]  hci_power_on+0x50/0x270 [bluetooth]
      [   18.709163]  process_one_work+0x2a0/0x6e0
      [   18.715252]  worker_thread+0x40/0x448
      [   18.721310]  kthread+0x12c/0x130
      [   18.727326]  ret_from_fork+0x10/0x1c
      [   18.735555] ------------[ cut here ]------------
      [   18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [<000000006265ec59>] wait_for_common+0x140/0x180
      [   18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
      [   18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
      btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
      brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
      dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
      leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
      meson_gxbb_wdt pwm_meson efivarfs ipv6
      [   18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
      [   18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
      [   18.818045] Workqueue: hci0 hci_power_on [bluetooth]
      [   18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
      [   18.829891] pc : __might_sleep+0x7c/0x88
      [   18.835722] lr : __might_sleep+0x7c/0x88
      [   18.841256] sp : ffff000008003cb0
      [   18.846751] x29: ffff000008003cb0 x28: 0000000000000000
      [   18.852269] x27: ffff00000938e000 x26: ffff800010283000
      [   18.857726] x25: ffff800010353280 x24: ffff00000868ef50
      [   18.863166] x23: 0000000000000000 x22: 0000000000000000
      [   18.868551] x21: 0000000000000000 x20: 000000000000038c
      [   18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
      [   18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
      [   18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
      [   18.889239] x13: 0000000000000001 x12: 00000000ffffffff
      [   18.894261] x11: ffff000008adfa48 x10: 0000000000000001
      [   18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
      [   18.904674] x7 : ffff00000812136c x6 : 0000000000000000
      [   18.909895] x5 : 0000000000000000 x4 : 0000000000000001
      [   18.915080] x3 : 0000000000000007 x2 : 0000000000000007
      [   18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
      [   18.925443] Call trace:
      [   18.929904]  __might_sleep+0x7c/0x88
      [   18.934311]  __mutex_lock+0x60/0x870
      [   18.938687]  mutex_lock_nested+0x1c/0x28
      [   18.943076]  regmap_lock_mutex+0x10/0x18
      [   18.947453]  regmap_read+0x38/0x70
      [   18.951842]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
      [   18.956269]  __handle_irq_event_percpu+0xac/0x410
      [   18.960712]  handle_irq_event_percpu+0x34/0x88
      [   18.965176]  handle_irq_event+0x48/0x78
      [   18.969612]  handle_fasteoi_irq+0xac/0x160
      [   18.974058]  generic_handle_irq+0x24/0x38
      [   18.978501]  __handle_domain_irq+0x60/0xb8
      [   18.982938]  gic_handle_irq+0x50/0xa0
      [   18.987351]  el1_irq+0xb4/0x130
      [   18.991734]  debug_lockdep_rcu_enabled+0x2c/0x30
      [   18.996180]  schedule+0x38/0xa0
      [   19.000609]  schedule_timeout+0x3a8/0x510
      [   19.005064]  wait_for_common+0x15c/0x180
      [   19.009513]  wait_for_completion+0x14/0x20
      [   19.013951]  mmc_wait_for_req_done+0x28/0x168
      [   19.018402]  mmc_wait_for_req+0xa8/0xe8
      [   19.022809]  mmc_wait_for_cmd+0x64/0x98
      [   19.027177]  mmc_io_rw_direct_host+0x94/0x130
      [   19.031563]  mmc_io_rw_direct+0x10/0x18
      [   19.035922]  sdio_enable_func+0xe8/0x1d0
      [   19.040294]  btsdio_open+0x24/0xc0 [btsdio]
      [   19.044742]  hci_dev_do_open+0x64/0x598 [bluetooth]
      [   19.049228]  hci_power_on+0x50/0x270 [bluetooth]
      [   19.053687]  process_one_work+0x2a0/0x6e0
      [   19.058143]  worker_thread+0x40/0x448
      [   19.062608]  kthread+0x12c/0x130
      [   19.067064]  ret_from_fork+0x10/0x1c
      [   19.071513] irq event stamp: 12
      [   19.075937] hardirqs last  enabled at (11): [<ffff000008a4f57c>] _raw_spin_unlock_irq+0x2c/0x60
      [   19.083560] hardirqs last disabled at (12): [<ffff000008a48914>] __schedule+0xc4/0xa60
      [   19.091401] softirqs last  enabled at (0): [<ffff0000080b55e0>] copy_process.isra.4.part.5+0x4d8/0x1c50
      [   19.100801] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [   19.108135] ---[ end trace 38c4920787b88c75 ]---
      
      So, fix this by enabling the fast_io option in our regmap config so that
      regmap uses spinlocks for locking instead of mutexes.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: 3f68be7d ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-amlogic@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: <stable@vger.kernel.org> # v4.12+
      Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.comSigned-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea6bb077
    • N
      drm/meson: Fixes for drm_crtc_vblank_on/off support · 736f0421
      Neil Armstrong 提交于
      commit 2bcd3eca upstream.
      
      Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get
      a warning when ctrc is disabled :
      " driver forgot to call drm_crtc_vblank_off()"
      
      But, the vsync IRQ was not totally disabled due the transient hardware
      state and specific interrupt line, thus adding proper IRQ masking from
      the HHI system control registers.
      
      The last change fixes a race condition introduced by calling the added
      drm_crtc_vblank_on/off when an HPD event occurs from the HDMI connector,
      triggering a WARN_ON() in the _atomic_begin() callback when the CRTC
      is disabled, thus also triggering a WARN_ON() in drm_vblank_put() :
      
      WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/meson/meson_crtc.c:157 meson_crtc_atomic_begin+0x78/0x80
      [...]
      Call trace:
        meson_crtc_atomic_begin+0x78/0x80
        drm_atomic_helper_commit_planes+0x140/0x218
        drm_atomic_helper_commit_tail+0x38/0x80
        commit_tail+0x7c/0x80
        drm_atomic_helper_commit+0xdc/0x150
        drm_atomic_commit+0x54/0x60
        restore_fbdev_mode_atomic+0x198/0x238
        restore_fbdev_mode+0x6c/0x1c0
        drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xf0
        drm_fb_helper_set_par+0x34/0x60
        drm_fb_helper_hotplug_event.part.28+0xb8/0xc8
        drm_fbdev_client_hotplug+0xa4/0xe0
        drm_client_dev_hotplug+0x90/0xe0
        drm_kms_helper_hotplug_event+0x3c/0x48
        drm_helper_hpd_irq_event+0x134/0x168
        dw_hdmi_top_thread_irq+0x3c/0x50
      [...]
      WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/drm_vblank.c:1026 drm_vblank_put+0xb4/0xc8
      [...]
       Call trace:
        drm_vblank_put+0xb4/0xc8
        drm_crtc_vblank_put+0x24/0x30
        drm_atomic_helper_wait_for_vblanks.part.9+0x130/0x2b8
        drm_atomic_helper_commit_tail+0x68/0x80
      [...]
      
      The issue is that vblank need to be enabled in any occurrence of :
      - atomic_enable()
      - atomic_begin() and state->enable == true, which was not the case
      
      Moving the CRTC enable code to a common function and calling in one of
      these occurrence solves this race condition and makes sure vblank is
      enabled in each call to _atomic_begin() from the HPD event leading to
      drm_atomic_helper_commit_planes().
      
      To Summarize :
      - Make sure that the CRTC code will call the drm_crtc_vblank_on()/off()
      - *Really* mask the Vsync IRQ
      - Initialize and enable vblank at the first
        atomic_begin()/_atomic_enable()
      
      Cc: stable@vger.kernel.org # 4.17+
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: NLyude Paul <lyude@redhat.com>
      [fixed typos+added cc for stable]
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181122160103.10993-1-narmstrong@baylibre.comSigned-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      736f0421
    • S
      drm: set is_master to 0 upon drm_new_set_master() failure · c952979a
      Sergio Correia 提交于
      commit 23a336b34258aba3b50ea6863cca4e81b5ef6384 upstream.
      
      When drm_new_set_master() fails, set is_master to 0, to prevent a
      possible NULL pointer deref.
      
      Here is a problematic flow: we check is_master in drm_is_current_master(),
      then proceed to call drm_lease_owner() passing master. If we do not restore
      is_master status when drm_new_set_master() fails, we may have a situation
      in which is_master will be 1 and master itself, NULL, leading to the deref
      of a NULL pointer in drm_lease_owner().
      
      This fixes the following OOPS, observed on an ArchLinux running a 4.19.2
      kernel:
      
      [   97.804282] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      [   97.807224] PGD 0 P4D 0
      [   97.807224] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [   97.807224] CPU: 0 PID: 1348 Comm: xfwm4 Tainted: P           OE     4.19.2-arch1-1-ARCH #1
      [   97.807224] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./AB350 Pro4, BIOS P5.10 10/16/2018
      [   97.807224] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
      [   97.807224] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
      [   97.807224] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
      [   97.807224] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
      [   97.807224] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
      [   97.807224] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
      [   97.807224] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
      [   97.807224] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
      [   97.807224] FS:  00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
      [   97.807224] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   97.807224] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
      [   97.807224] Call Trace:
      [   97.807224]  drm_is_current_master+0x1a/0x30 [drm]
      [   97.807224]  drm_master_release+0x3e/0x130 [drm]
      [   97.807224]  drm_file_free.part.0+0x2be/0x2d0 [drm]
      [   97.807224]  drm_open+0x1ba/0x1e0 [drm]
      [   97.807224]  drm_stub_open+0xaf/0xe0 [drm]
      [   97.807224]  chrdev_open+0xa3/0x1b0
      [   97.807224]  ? cdev_put.part.0+0x20/0x20
      [   97.807224]  do_dentry_open+0x132/0x340
      [   97.807224]  path_openat+0x2d1/0x14e0
      [   97.807224]  ? mem_cgroup_commit_charge+0x7a/0x520
      [   97.807224]  do_filp_open+0x93/0x100
      [   97.807224]  ? __check_object_size+0x102/0x189
      [   97.807224]  ? _raw_spin_unlock+0x16/0x30
      [   97.807224]  do_sys_open+0x186/0x210
      [   97.807224]  do_syscall_64+0x5b/0x170
      [   97.807224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   97.807224] RIP: 0033:0x7f4147b07976
      [   97.807224] Code: 89 54 24 08 e8 7b f4 ff ff 8b 74 24 0c 48 8b 3c 24 41 89 c0 44 8b 54 24 08 b8 01 01 00 00 89 f2 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 77 30 44 89 c7 89 44 24 08 e8 a6 f4 ff ff 8b 44
      [   97.807224] RSP: 002b:00007ffcced96ca0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
      [   97.807224] RAX: ffffffffffffffda RBX: 00005619d5037f80 RCX: 00007f4147b07976
      [   97.807224] RDX: 0000000000000002 RSI: 00005619d46b969c RDI: 00000000ffffff9c
      [   98.040039] RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000000
      [   98.040039] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000024
      [   98.040039] R13: 0000000000000012 R14: 00005619d5035950 R15: 0000000000000012
      [   98.040039] Modules linked in: nct6775 hwmon_vid algif_skcipher af_alg nls_iso8859_1 nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common arc4 videodev media snd_usb_audio snd_hda_codec_hdmi snd_usbmidi_lib snd_rawmidi snd_seq_device mousedev input_leds iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec edac_mce_amd kvm_amd snd_hda_core kvm iwlwifi snd_hwdep r8169 wmi_bmof cfg80211 snd_pcm irqbypass snd_timer snd libphy soundcore pinctrl_amd rfkill pcspkr sp5100_tco evdev gpio_amdpt k10temp mac_hid i2c_piix4 wmi pcc_cpufreq acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) msr sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto uas usb_storage dm_crypt hid_generic usbhid hid
      [   98.040039]  dm_mod raid1 md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel aes_x86_64 libata crypto_simd cryptd glue_helper ccp xhci_pci rng_core scsi_mod xhci_hcd nvidia_drm(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart nvidia_uvm(POE) nvidia_modeset(POE) nvidia(POE) ipmi_devintf ipmi_msghandler
      [   98.040039] CR2: 0000000000000080
      [   98.040039] ---[ end trace 3b65093b6fe62b2f ]---
      [   98.040039] RIP: 0010:drm_lease_owner+0xd/0x20 [drm]
      [   98.040039] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44
      [   98.040039] RSP: 0018:ffffb8cf08e07bb0 EFLAGS: 00010202
      [   98.040039] RAX: 0000000000000000 RBX: ffff9cf0f2586c00 RCX: ffff9cf0f2586c88
      [   98.040039] RDX: ffff9cf0ddbd8000 RSI: 0000000000000000 RDI: 0000000000000000
      [   98.040039] RBP: ffff9cf1040e9800 R08: 0000000000000000 R09: 0000000000000000
      [   98.040039] R10: ffffdeb30fd5d680 R11: ffffdeb30f5d6808 R12: ffff9cf1040e9888
      [   98.040039] R13: 0000000000000000 R14: dead000000000200 R15: ffff9cf0f2586cc8
      [   98.040039] FS:  00007f4145513180(0000) GS:ffff9cf10ea00000(0000) knlGS:0000000000000000
      [   98.040039] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   98.040039] CR2: 0000000000000080 CR3: 00000003d7548000 CR4: 00000000003406f0
      Signed-off-by: NSergio Correia <sergio@correia.cc>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181122053329.2692-1-sergio@correia.ccSigned-off-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c952979a
    • L
      drm/amd/dm: Don't forget to attach MST encoders · 8a8effbe
      Lyude Paul 提交于
      commit c9e0ab86 upstream.
      
      The change fixed huge delay in SST daisy chain and S3 soft hang
      observed in 4.19 kernel rebase.
      
      Regression point in drm:
      drm/fb-helper: Eliminate the .best_encoder() usage
      
      The aux sequence is altered due to the failure in
      drm_connector_for_each_possible_encoder(). The failure is
      caused by missing attached encoder in the process of adding
      MST connector.
       
      drm_dp_send_enum_path_resources() aux transaction is pushed after
      mode probe, which causes conflict to drm_dp_mst_i2c_xfer(),
      leading to the transaction timeout.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NJerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a8effbe
    • S
      drm/ast: Fix incorrect free on ioregs · 94be4764
      Sam Bobroff 提交于
      commit dc25ab06 upstream.
      
      If the platform has no IO space, ioregs is placed next to the already
      allocated regs. In this case, it should not be separately freed.
      
      This prevents a kernel warning from __vunmap "Trying to vfree()
      nonexistent vm area" when unloading the driver.
      
      Fixes: 0dd68309 ("drm/ast: Try to use MMIO registers when PIO isn't supported")
      Signed-off-by: NSam Bobroff <sbobroff@linux.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94be4764
    • M
      IB/mlx5: Avoid load failure due to unknown link width · a9907564
      Michael Guralnik 提交于
      commit db7a691a upstream.
      
      If the firmware reports a connection width that is not 1x, 4x, 8x or 12x
      it causes the driver to fail during initialization.
      
      To prevent this failure every time a new width is introduced to the RDMA
      stack, we will set a default 4x width for these widths which ar unknown to
      the driver.
      
      This is needed to allow to run old kernels with new firmware.
      
      Cc: <stable@vger.kernel.org> # 4.1
      Fixes: 1b5daf11 ("IB/mlx5: Avoid using the MAD_IFC command under ISSI > 0 mode")
      Signed-off-by: NMichael Guralnik <michaelgur@mellanox.com>
      Reviewed-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a9907564
    • F
      mtd: nand: Fix memory allocation in nanddev_bbt_init() · 86e42924
      Frieder Schrempf 提交于
      commit 40b41289 upstream.
      
      Fix the size of the buffer allocated to store the in-memory BBT.
      This bug was previously hidden by a different bug, that was fixed in
      commit d098093b ("mtd: nand: Fix nanddev_neraseblocks()").
      
      Fixes: 9c3736a3 ("mtd: nand: Add core infrastructure to deal with NAND devices")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
      Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86e42924
    • S
      iser: set sector for ambiguous mr status errors · 61c963ab
      Sagi Grimberg 提交于
      commit 24c3456c8d5ee6fc1933ca40f7b4406130682668 upstream.
      
      If for some reason we failed to query the mr status, we need to make sure
      to provide sufficient information for an ambiguous error (guard error on
      sector 0).
      
      Fixes: 0a7a08ad ("IB/iser: Implement check_protection")
      Cc: <stable@vger.kernel.org>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61c963ab
  3. 06 12月, 2018 8 次提交