1. 09 Mar, 2016 40 commits
    • Vittorio Alfieri's avatar
      USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder · 1f249cfb
      Vittorio Alfieri authored
      commit 3c4c615d upstream.
      
      The Parrot NMEA GPS Flight Recorder is a USB composite device
      consisting of hub, flash storage, and cp210x usb to serial chip.
      It is an accessory to the mass-produced Parrot AR Drone 2.
      The device emits standard NMEA messages which make the it compatible
      with NMEA compatible software. It was tested using gpsd version 3.11-3
      as an NMEA interpreter and using the official Parrot Flight Recorder.
      Signed-off-by: default avatarVittorio Alfieri <vittorio88@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f249cfb
    • Peter Chen's avatar
      usb: chipidea: otg: change workqueue ci_otg as freezable · 0ba460a5
      Peter Chen authored
      commit d144dfea upstream.
      
      If we use USB ID pin as wakeup source, and there is a USB block
      device on this USB OTG (ID) cable, the system will be deadlock
      after system resume.
      
      The root cause for this problem is: the workqueue ci_otg may try
      to remove hcd before the driver resume has finished, and hcd will
      disconnect the device on it, then, it will call device_release_driver,
      and holds the device lock "dev->mutex", but it is never unlocked since
      it waits workqueue writeback to run to flush the block information, but
      the workqueue writeback is freezable, it is not thawed before driver
      resume has finished.
      
      When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it
      tries to get its device lock "dev->mutex", but it can't get it forever,
      then the deadlock occurs. Below call stacks show the situation.
      
      So, in order to fix this problem, we need to change workqueue ci_otg
      as freezable, then the work item in this workqueue will be run after
      driver's resume, this workqueue will not be blocked forever like above
      case since the workqueue writeback has been thawed too.
      
      Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb.
      
      [  555.178869] kworker/u2:13   D c07de74c     0   826      2 0x00000000
      [  555.185310] Workqueue: ci_otg ci_otg_work
      [  555.189353] Backtrace:
      [  555.191849] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0)
      [  555.198912]  r10:ee471ba0 r9:00000000 r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4
      [  555.206867]  r4:ee470000
      [  555.209453] [<c07dec24>] (schedule) from [<c07e2fc4>] (schedule_timeout+0x15c/0x1e0)
      [  555.217212]  r4:7fffffff r3:edc2b000
      [  555.220862] [<c07e2e68>] (schedule_timeout) from [<c07df6c8>] (wait_for_common+0x94/0x144)
      [  555.229140]  r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 r4:7fffffff
      [  555.235980] [<c07df634>] (wait_for_common) from [<c07df790>] (wait_for_completion+0x18/0x1c)
      [  555.244430]  r10:00000001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00
      [  555.252383]  r4:00000000
      [  555.254970] [<c07df778>] (wait_for_completion) from [<c0043cb8>] (flush_work+0x19c/0x234)
      [  555.263177] [<c0043b1c>] (flush_work) from [<c0043fac>] (flush_delayed_work+0x48/0x4c)
      [  555.271106]  r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c
      [  555.277958] [<c0043f64>] (flush_delayed_work) from [<c00eae18>] (bdi_unregister+0x84/0xec)
      [  555.286236]  r4:eea43520 r3:20000153
      [  555.289885] [<c00ead94>] (bdi_unregister) from [<c02c2154>] (blk_cleanup_queue+0x180/0x29c)
      [  555.298250]  r5:eea43808 r4:eea43400
      [  555.301909] [<c02c1fd4>] (blk_cleanup_queue) from [<c0417914>] (__scsi_remove_device+0x48/0xb8)
      [  555.310623]  r7:00000000 r6:20000153 r5:ededa950 r4:ededa800
      [  555.316403] [<c04178cc>] (__scsi_remove_device) from [<c0415e90>] (scsi_forget_host+0x64/0x68)
      [  555.325028]  r5:ededa800 r4:ed5b5000
      [  555.328689] [<c0415e2c>] (scsi_forget_host) from [<c0409828>] (scsi_remove_host+0x78/0x104)
      [  555.337054]  r5:ed5b5068 r4:ed5b5000
      [  555.340709] [<c04097b0>] (scsi_remove_host) from [<c04cdfcc>] (usb_stor_disconnect+0x50/0xb4)
      [  555.349247]  r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:00000008
      [  555.355025] [<c04cdf7c>] (usb_stor_disconnect) from [<c04b3bc8>] (usb_unbind_interface+0x78/0x25c)
      [  555.363997]  r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c
      [  555.371892] [<c04b3b50>] (usb_unbind_interface) from [<c03dc248>] (__device_release_driver+0x8c/0x118)
      [  555.381213]  r10:00000001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c
      [  555.389167]  r4:edd3c020
      [  555.391752] [<c03dc1bc>] (__device_release_driver) from [<c03dc2fc>] (device_release_driver+0x28/0x34)
      [  555.401071]  r5:edd3c020 r4:edd3c054
      [  555.404721] [<c03dc2d4>] (device_release_driver) from [<c03db304>] (bus_remove_device+0xe0/0x110)
      [  555.413607]  r5:edd3c020 r4:ef17f04c
      [  555.417253] [<c03db224>] (bus_remove_device) from [<c03d8128>] (device_del+0x114/0x21c)
      [  555.425270]  r6:edd3c028 r5:edd3c020 r4:ee551c00 r3:00000000
      [  555.431045] [<c03d8014>] (device_del) from [<c04b1560>] (usb_disable_device+0xa4/0x1e8)
      [  555.439061]  r8:edd3c000 r7:eded8000 r6:00000000 r5:00000001 r4:ee551c00
      [  555.445906] [<c04b14bc>] (usb_disable_device) from [<c04a8e54>] (usb_disconnect+0x74/0x224)
      [  555.454271]  r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:00000001
      [  555.462156] [<c04a8de0>] (usb_disconnect) from [<c04a8fb8>] (usb_disconnect+0x1d8/0x224)
      [  555.470259]  r10:00000001 r9:edd90000 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400
      [  555.478213]  r4:00000001
      [  555.480797] [<c04a8de0>] (usb_disconnect) from [<c04ae5ec>] (usb_remove_hcd+0xa0/0x1ac)
      [  555.488813]  r10:00000001 r9:ee471eb0 r8:00000000 r7:ef3d9500 r6:eded810c r5:eded80b0
      [  555.496765]  r4:eded8000
      [  555.499351] [<c04ae54c>] (usb_remove_hcd) from [<c04d4158>] (host_stop+0x28/0x64)
      [  555.506847]  r6:eeb50010 r5:eded8000 r4:eeb51010
      [  555.511563] [<c04d4130>] (host_stop) from [<c04d09b8>] (ci_otg_work+0xc4/0x124)
      [  555.518885]  r6:00000001 r5:eeb50010 r4:eeb502a0 r3:c04d4130
      [  555.524665] [<c04d08f4>] (ci_otg_work) from [<c00454f0>] (process_one_work+0x194/0x420)
      [  555.532682]  r6:ef086000 r5:eeb502a0 r4:edc44480
      [  555.537393] [<c004535c>] (process_one_work) from [<c00457b0>] (worker_thread+0x34/0x514)
      [  555.545496]  r10:edc44480 r9:ef086000 r8:c0b1a100 r7:ef086034 r6:00000088 r5:edc44498
      [  555.553450]  r4:ef086000
      [  555.556032] [<c004577c>] (worker_thread) from [<c004bab4>] (kthread+0xdc/0xf8)
      [  555.563268]  r10:00000000 r9:00000000 r8:00000000 r7:c004577c r6:edc44480 r5:eddc15c0
      [  555.571221]  r4:00000000
      [  555.573804] [<c004b9d8>] (kthread) from [<c000fef0>] (ret_from_fork+0x14/0x24)
      [  555.581040]  r7:00000000 r6:00000000 r5:c004b9d8 r4:eddc15c0
      
      [  553.429383] sh              D c07de74c     0   694    691 0x00000000
      [  553.435801] Backtrace:
      [  553.438295] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0)
      [  553.445358]  r10:edd3c054 r9:edd3c078 r8:edddbd50 r7:edcbbc00 r6:c1377c34 r5:60000153
      [  553.453313]  r4:eddda000
      [  553.455896] [<c07dec24>] (schedule) from [<c07deff8>] (schedule_preempt_disabled+0x10/0x14)
      [  553.464261]  r4:edd3c058 r3:0000000a
      [  553.467910] [<c07defe8>] (schedule_preempt_disabled) from [<c07e0bbc>] (mutex_lock_nested+0x1a0/0x3e8)
      [  553.477254] [<c07e0a1c>] (mutex_lock_nested) from [<c03e927c>] (dpm_complete+0xc0/0x1b0)
      [  553.485358]  r10:00561408 r9:edd3c054 r8:c0b4863c r7:edddbd90 r6:c0b485d8 r5:edd3c020
      [  553.493313]  r4:edd3c0d0
      [  553.495896] [<c03e91bc>] (dpm_complete) from [<c03e9388>] (dpm_resume_end+0x1c/0x20)
      [  553.503652]  r9:00000000 r8:c0b1a9d0 r7:c1334ec0 r6:c1334edc r5:00000003 r4:00000010
      [  553.511544] [<c03e936c>] (dpm_resume_end) from [<c0079894>] (suspend_devices_and_enter+0x158/0x504)
      [  553.520604]  r4:00000000 r3:c1334efc
      [  553.524250] [<c007973c>] (suspend_devices_and_enter) from [<c0079e74>] (pm_suspend+0x234/0x2cc)
      [  553.532961]  r10:00561408 r9:ed6b7300 r8:00000004 r7:c1334eec r6:00000000 r5:c1334ee8
      [  553.540914]  r4:00000003
      [  553.543493] [<c0079c40>] (pm_suspend) from [<c0078a6c>] (state_store+0x6c/0xc0)
      
      [  555.703684] 7 locks held by kworker/u2:13/826:
      [  555.708140]  #0:  ("%s""ci_otg"){++++.+}, at: [<c0045484>] process_one_work+0x128/0x420
      [  555.716277]  #1:  ((&ci->work)){+.+.+.}, at: [<c0045484>] process_one_work+0x128/0x420
      [  555.724317]  #2:  (usb_bus_list_lock){+.+.+.}, at: [<c04ae5e4>] usb_remove_hcd+0x98/0x1ac
      [  555.732626]  #3:  (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224
      [  555.740403]  #4:  (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224
      [  555.748179]  #5:  (&dev->mutex){......}, at: [<c03dc2f4>] device_release_driver+0x20/0x34
      [  555.756487]  #6:  (&shost->scan_mutex){+.+.+.}, at: [<c04097d0>] scsi_remove_host+0x20/0x104
      
      Cc: Jun Li <jun.li@nxp.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ba460a5
    • Takashi Iwai's avatar
      ALSA: timer: Fix broken compat timer user status ioctl · 48ad515e
      Takashi Iwai authored
      commit 3a72494a upstream.
      
      The timer user status compat ioctl returned the bogus struct used for
      64bit architectures instead of the 32bit one.  This patch addresses
      it to return the proper struct.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48ad515e
    • Takashi Iwai's avatar
      ALSA: hdspm: Fix zero-division · 8a358d00
      Takashi Iwai authored
      commit c1099c32 upstream.
      
      HDSPM driver contains a code issuing zero-division potentially in
      system sample rate ctl code.  This patch fixes it by not processing
      a zero or invalid rate value as a divisor, as well as excluding the
      invalid value to be passed via the given ctl element.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a358d00
    • Takashi Iwai's avatar
      ALSA: hdsp: Fix wrong boolean ctl value accesses · eb390c30
      Takashi Iwai authored
      commit eab3c4db upstream.
      
      snd-hdsp driver accesses enum item values (int) instead of boolean
      values (long) wrongly for some ctl elements.  This patch fixes them.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb390c30
    • Takashi Iwai's avatar
      ALSA: hdspm: Fix wrong boolean ctl value accesses · 7483d67f
      Takashi Iwai authored
      commit 537e4813 upstream.
      
      snd-hdspm driver accesses enum item values (int) instead of boolean
      values (long) wrongly for some ctl elements.  This patch fixes them.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7483d67f
    • Takashi Iwai's avatar
      ALSA: seq: oss: Don't drain at closing a client · 93e93ec1
      Takashi Iwai authored
      commit 197b958c upstream.
      
      The OSS sequencer client tries to drain the pending events at
      releasing.  Unfortunately, as spotted by syzkaller fuzzer, this may
      lead to an unkillable process state when the event has been queued at
      the far future.  Since the process being released can't be signaled
      any longer, it remains and waits for the echo-back event in that far
      future.
      
      Back to history, the draining feature was implemented at the time we
      misinterpreted POSIX definition for blocking file operation.
      Actually, such a behavior is superfluous at release, and we should
      just release the device as is instead of keeping it up forever.
      
      This patch just removes the draining call that may block the release
      for too long time unexpectedly.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93e93ec1
    • Takashi Iwai's avatar
      ALSA: pcm: Fix ioctls for X32 ABI · f9ed7db1
      Takashi Iwai authored
      commit 513ace79 upstream.
      
      X32 ABI uses the 64bit timespec in addition to 64bit alignment of
      64bit values.  This leads to incompatibilities in some PCM ioctls
      involved with snd_pcm_channel_info, snd_pcm_status and
      snd_pcm_sync_ptr structs.  Fix the PCM compat ABI for these ioctls
      like the previous commit for ctl API.
      Reported-by: default avatarSteven Newbury <steve@snewbury.org.uk>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9ed7db1
    • Takashi Iwai's avatar
      ALSA: timer: Fix ioctls for X32 ABI · 7c0fe28f
      Takashi Iwai authored
      commit b24e7ad1 upstream.
      
      X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
      incompatible with IA32.  This results in NOTTY error when the ioctl is
      issued.
      
      Meanwhile, this struct in X32 is essentially identical with the one in
      X86-64, so we can just bypassing to the existing code for this
      specific compat ioctl.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c0fe28f
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix ioctls X32 ABI · 8a1faa9c
      Takashi Iwai authored
      commit 2251fbbc upstream.
      
      Like the previous fixes for ctl and PCM, we need a fix for
      incompatible X32 ABI regarding the rawmidi: namely, struct
      snd_rawmidi_status has the timespec, and the size and the alignment on
      X32 differ from IA32.
      
      This patch fixes the incompatible ioctl for X32.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a1faa9c
    • Simon South's avatar
      ALSA: hda - Fix mic issues on Acer Aspire E1-472 · b422823d
      Simon South authored
      commit 02322ac9 upstream.
      
      This patch applies the microphone-related fix created for the Acer
      Aspire E1-572 to the E1-472 as well, as it uses the same Realtek ALC282
      CODEC and demonstrates the same issues.
      
      This patch allows an external, headset microphone to be used and limits
      the gain on the (quite noisy) internal microphone.
      Signed-off-by: default avatarSimon South <simon@simonsouth.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b422823d
    • Takashi Iwai's avatar
      ALSA: ctl: Fix ioctls for X32 ABI · c223c645
      Takashi Iwai authored
      commit 6236d8bb upstream.
      
      The X32 ABI takes the same alignment like x86-64, and this may result
      in the incompatible struct size from ia32.  Unfortunately, we hit this
      in some control ABI: struct snd_ctl_elem_value differs between them
      due to the position of 64bit variable array.  This ends up with the
      unknown ioctl (ENOTTY) error.
      
      The fix is to add the compat entries for the new aligned struct.
      Reported-and-tested-by: default avatarSteven Newbury <steve@snewbury.org.uk>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c223c645
    • Dennis Kadioglu's avatar
      ALSA: usb-audio: Add a quirk for Plantronics DA45 · 020615e8
      Dennis Kadioglu authored
      commit 17e2df46 upstream.
      
      Plantronics DA45 does not support reading the sample rate which leads
      to many lines of "cannot get freq at ep 0x4" and "cannot get freq at
      ep 0x84". This patch adds the USB ID of the DA45 to quirks.c and
      avoids those error messages.
      Signed-off-by: default avatarDennis Kadioglu <denk@post.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      020615e8
    • Hans Verkuil's avatar
      adv7604: fix tx 5v detect regression · f7591f1a
      Hans Verkuil authored
      commit 0ba4581c upstream.
      
      The 5 volt detect functionality broke in 3.14: the code reads IO register 0x70
      again after it has already been cleared. Instead it should use the cached
      irq_reg_0x70 value and the io_write to 0x71 to clear 0x70 can be dropped since
      this has already been done.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7591f1a
    • Robert Jarzmik's avatar
      dmaengine: pxa_dma: fix cyclic transfers · 7abfb63f
      Robert Jarzmik authored
      commit f1692127 upstream.
      
      While testing audio with pxa2xx-ac97, underrun were happening while the
      user application was correctly feeding the music. Debug proved that the
      cyclic transfer is not cyclic, ie. the last descriptor did not loop on
      the first.
      
      Another issue is that the descriptor length was always set to 8192,
      because of an trivial operator issue.
      
      This was tested on a pxa27x platform.
      
      Fixes: a57e16cf ("dmaengine: pxa: add pxa dmaengine driver")
      Reported-by: default avatarVasily Khoruzhick <anarsoul@gmail.com>
      Tested-by: default avatarVasily Khoruzhick <anarsoul@gmail.com>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7abfb63f
    • David Woodhouse's avatar
      Fix directory hardlinks from deleted directories · 3ef98fde
      David Woodhouse authored
      commit be629c62 upstream.
      
      When a directory is deleted, we don't take too much care about killing off
      all the dirents that belong to it — on the basis that on remount, the scan
      will conclude that the directory is dead anyway.
      
      This doesn't work though, when the deleted directory contained a child
      directory which was moved *out*. In the early stages of the fs build
      we can then end up with an apparent hard link, with the child directory
      appearing both in its true location, and as a child of the original
      directory which are this stage of the mount process we don't *yet* know
      is defunct.
      
      To resolve this, take out the early special-casing of the "directories
      shall not have hard links" rule in jffs2_build_inode_pass1(), and let the
      normal nlink processing happen for directories as well as other inodes.
      
      Then later in the build process we can set ic->pino_nlink to the parent
      inode#, as is required for directories during normal operaton, instead
      of the nlink. And complain only *then* about hard links which are still
      in evidence even after killing off all the unreachable paths.
      Reported-by: default avatarLiu Song <liu.song11@zte.com.cn>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ef98fde
    • David Woodhouse's avatar
      jffs2: Fix page lock / f->sem deadlock · 17d919c7
      David Woodhouse authored
      commit 49e91e70 upstream.
      
      With this fix, all code paths should now be obtaining the page lock before
      f->sem.
      Reported-by: default avatarSzabó Tamás <sztomi89@gmail.com>
      Tested-by: default avatarThomas Betker <thomas.betker@rohde-schwarz.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17d919c7
    • Thomas Betker's avatar
      Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin" · 17f95016
      Thomas Betker authored
      commit 157078f6 upstream.
      
      This reverts commit 5ffd3412
      ("jffs2: Fix lock acquisition order bug in jffs2_write_begin").
      
      The commit modified jffs2_write_begin() to remove a deadlock with
      jffs2_garbage_collect_live(), but this introduced new deadlocks found
      by multiple users. page_lock() actually has to be called before
      mutex_lock(&c->alloc_sem) or mutex_lock(&f->sem) because
      jffs2_write_end() and jffs2_readpage() are called with the page locked,
      and they acquire c->alloc_sem and f->sem, resp.
      
      In other words, the lock order in jffs2_write_begin() was correct, and
      it is the jffs2_garbage_collect_live() path that has to be changed.
      
      Revert the commit to get rid of the new deadlocks, and to clear the way
      for a better fix of the original deadlock.
      Reported-by: default avatarDeng Chao <deng.chao1@zte.com.cn>
      Reported-by: default avatarMing Liu <liu.ming50@gmail.com>
      Reported-by: default avatarwangzaiwei <wangzaiwei@top-vision.cn>
      Signed-off-by: default avatarThomas Betker <thomas.betker@rohde-schwarz.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17f95016
    • Filipe Manana's avatar
      Btrfs: fix loading of orphan roots leading to BUG_ON · c8421505
      Filipe Manana authored
      commit 909c3a22 upstream.
      
      When looking for orphan roots during mount we can end up hitting a
      BUG_ON() (at root-item.c:btrfs_find_orphan_roots()) if a log tree is
      replayed and qgroups are enabled. This is because after a log tree is
      replayed, a transaction commit is made, which triggers qgroup extent
      accounting which in turn does backref walking which ends up reading and
      inserting all roots in the radix tree fs_info->fs_root_radix, including
      orphan roots (deleted snapshots). So after the log tree is replayed, when
      finding orphan roots we hit the BUG_ON with the following trace:
      
      [118209.182438] ------------[ cut here ]------------
      [118209.183279] kernel BUG at fs/btrfs/root-tree.c:314!
      [118209.184074] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [118209.185123] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic ppdev xor raid6_pq evdev sg parport_pc parport acpi_cpufreq tpm_tis tpm psmouse
      processor i2c_piix4 serio_raw pcspkr i2c_core button loop autofs4 ext4 crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic virtio_scsi ata_piix libata
      virtio_pci virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
      [118209.186318] CPU: 14 PID: 28428 Comm: mount Tainted: G        W       4.5.0-rc5-btrfs-next-24+ #1
      [118209.186318] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
      [118209.186318] task: ffff8801ec131040 ti: ffff8800af34c000 task.ti: ffff8800af34c000
      [118209.186318] RIP: 0010:[<ffffffffa04237d7>]  [<ffffffffa04237d7>] btrfs_find_orphan_roots+0x1fc/0x244 [btrfs]
      [118209.186318] RSP: 0018:ffff8800af34faa8  EFLAGS: 00010246
      [118209.186318] RAX: 00000000ffffffef RBX: 00000000ffffffef RCX: 0000000000000001
      [118209.186318] RDX: 0000000080000000 RSI: 0000000000000001 RDI: 00000000ffffffff
      [118209.186318] RBP: ffff8800af34fb08 R08: 0000000000000001 R09: 0000000000000000
      [118209.186318] R10: ffff8800af34f9f0 R11: 6db6db6db6db6db7 R12: ffff880171b97000
      [118209.186318] R13: ffff8801ca9d65e0 R14: ffff8800afa2e000 R15: 0000160000000000
      [118209.186318] FS:  00007f5bcb914840(0000) GS:ffff88023edc0000(0000) knlGS:0000000000000000
      [118209.186318] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [118209.186318] CR2: 00007f5bcaceb5d9 CR3: 00000000b49b5000 CR4: 00000000000006e0
      [118209.186318] Stack:
      [118209.186318]  fffffbffffffffff 010230ffffffffff 0101000000000000 ff84000000000000
      [118209.186318]  fbffffffffffffff 30ffffffffffffff 0000000000000101 ffff880082348000
      [118209.186318]  0000000000000000 ffff8800afa2e000 ffff8800afa2e000 0000000000000000
      [118209.186318] Call Trace:
      [118209.186318]  [<ffffffffa042e2db>] open_ctree+0x1e37/0x21b9 [btrfs]
      [118209.186318]  [<ffffffffa040a753>] btrfs_mount+0x97e/0xaed [btrfs]
      [118209.186318]  [<ffffffff8108e1c0>] ? trace_hardirqs_on+0xd/0xf
      [118209.186318]  [<ffffffff8117b87e>] mount_fs+0x67/0x131
      [118209.186318]  [<ffffffff81192d2b>] vfs_kern_mount+0x6c/0xde
      [118209.186318]  [<ffffffffa0409f81>] btrfs_mount+0x1ac/0xaed [btrfs]
      [118209.186318]  [<ffffffff8108e1c0>] ? trace_hardirqs_on+0xd/0xf
      [118209.186318]  [<ffffffff8108c26b>] ? lockdep_init_map+0xb9/0x1b3
      [118209.186318]  [<ffffffff8117b87e>] mount_fs+0x67/0x131
      [118209.186318]  [<ffffffff81192d2b>] vfs_kern_mount+0x6c/0xde
      [118209.186318]  [<ffffffff81195637>] do_mount+0x8a6/0x9e8
      [118209.186318]  [<ffffffff8119598d>] SyS_mount+0x77/0x9f
      [118209.186318]  [<ffffffff81493017>] entry_SYSCALL_64_fastpath+0x12/0x6b
      [118209.186318] Code: 64 00 00 85 c0 89 c3 75 24 f0 41 80 4c 24 20 20 49 8b bc 24 f0 01 00 00 4c 89 e6 e8 e8 65 00 00 85 c0 89 c3 74 11 83 f8 ef 75 02 <0f> 0b
      4c 89 e7 e8 da 72 00 00 eb 1c 41 83 bc 24 00 01 00 00 00
      [118209.186318] RIP  [<ffffffffa04237d7>] btrfs_find_orphan_roots+0x1fc/0x244 [btrfs]
      [118209.186318]  RSP <ffff8800af34faa8>
      [118209.230735] ---[ end trace 83938f987d85d477 ]---
      
      So fix this by not treating the error -EEXIST, returned when attempting
      to insert a root already inserted by the backref walking code, as an error.
      
      The following test case for xfstests reproduces the bug:
      
        seq=`basename $0`
        seqres=$RESULT_DIR/$seq
        echo "QA output created by $seq"
        tmp=/tmp/$$
        status=1	# failure is the default!
        trap "_cleanup; exit \$status" 0 1 2 3 15
      
        _cleanup()
        {
            _cleanup_flakey
            cd /
            rm -f $tmp.*
        }
      
        # get standard environment, filters and checks
        . ./common/rc
        . ./common/filter
        . ./common/dmflakey
      
        # real QA test starts here
        _supported_fs btrfs
        _supported_os Linux
        _require_scratch
        _require_dm_target flakey
        _require_metadata_journaling $SCRATCH_DEV
      
        rm -f $seqres.full
      
        _scratch_mkfs >>$seqres.full 2>&1
        _init_flakey
        _mount_flakey
      
        _run_btrfs_util_prog quota enable $SCRATCH_MNT
      
        # Create 2 directories with one file in one of them.
        # We use these just to trigger a transaction commit later, moving the file from
        # directory a to directory b and doing an fsync against directory a.
        mkdir $SCRATCH_MNT/a
        mkdir $SCRATCH_MNT/b
        touch $SCRATCH_MNT/a/f
        sync
      
        # Create our test file with 2 4K extents.
        $XFS_IO_PROG -f -s -c "pwrite -S 0xaa 0 8K" $SCRATCH_MNT/foobar | _filter_xfs_io
      
        # Create a snapshot and delete it. This doesn't really delete the snapshot
        # immediately, just makes it inaccessible and invisible to user space, the
        # snapshot is deleted later by a dedicated kernel thread (cleaner kthread)
        # which is woke up at the next transaction commit.
        # A root orphan item is inserted into the tree of tree roots, so that if a
        # power failure happens before the dedicated kernel thread does the snapshot
        # deletion, the next time the filesystem is mounted it resumes the snapshot
        # deletion.
        _run_btrfs_util_prog subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/snap
        _run_btrfs_util_prog subvolume delete $SCRATCH_MNT/snap
      
        # Now overwrite half of the extents we wrote before. Because we made a snapshpot
        # before, which isn't really deleted yet (since no transaction commit happened
        # after we did the snapshot delete request), the non overwritten extents get
        # referenced twice, once by the default subvolume and once by the snapshot.
        $XFS_IO_PROG -c "pwrite -S 0xbb 4K 8K" $SCRATCH_MNT/foobar | _filter_xfs_io
      
        # Now move file f from directory a to directory b and fsync directory a.
        # The fsync on the directory a triggers a transaction commit (because a file
        # was moved from it to another directory) and the file fsync leaves a log tree
        # with file extent items to replay.
        mv $SCRATCH_MNT/a/f $SCRATCH_MNT/a/b
        $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/a
        $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
      
        echo "File digest before power failure:"
        md5sum $SCRATCH_MNT/foobar | _filter_scratch
      
        # Now simulate a power failure and mount the filesystem to replay the log tree.
        # After the log tree was replayed, we used to hit a BUG_ON() when processing
        # the root orphan item for the deleted snapshot. This is because when processing
        # an orphan root the code expected to be the first code inserting the root into
        # the fs_info->fs_root_radix radix tree, while in reallity it was the second
        # caller attempting to do it - the first caller was the transaction commit that
        # took place after replaying the log tree, when updating the qgroup counters.
        _flakey_drop_and_remount
      
        echo "File digest before after failure:"
        # Must match what he got before the power failure.
        md5sum $SCRATCH_MNT/foobar | _filter_scratch
      
        _unmount_flakey
        status=0
        exit
      
      Fixes: 2d9e9776 ("Btrfs: use btrfs_get_fs_root in resolve_indirect_ref")
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarQu Wenruo <quwenruo@cn.fujitsu.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8421505
    • Gabor Juhos's avatar
      pata-rb532-cf: get rid of the irq_to_gpio() call · 5667d50c
      Gabor Juhos authored
      commit 01836176 upstream.
      
      The RB532 platform specific irq_to_gpio() implementation has been
      removed with commit 832f5dac ("MIPS: Remove all the uses of
      custom gpio.h"). Now the platform uses the generic stub which causes
      the following error:
      
        pata-rb532-cf pata-rb532-cf: no GPIO found for irq149
        pata-rb532-cf: probe of pata-rb532-cf failed with error -2
      
      Drop the irq_to_gpio() call and get the GPIO number from platform
      data instead. After this change, the driver works again:
      
        scsi host0: pata-rb532-cf
        ata1: PATA max PIO4 irq 149
        ata1.00: CFA: CF 1GB, 20080820, max MWDMA4
        ata1.00: 1989792 sectors, multi 0: LBA
        ata1.00: configured for PIO4
        scsi 0:0:0:0: Direct-Access     ATA      CF 1GB           0820 PQ: 0\
        ANSI: 5
        sd 0:0:0:0: [sda] 1989792 512-byte logical blocks: (1.01 GB/971 MiB)
        sd 0:0:0:0: [sda] Write Protect is off
        sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't\
        support DPO or FUA
         sda: sda1 sda2
        sd 0:0:0:0: [sda] Attached SCSI disk
      
      Fixes: 832f5dac ("MIPS: Remove all the uses of custom gpio.h")
      Cc: Alban Bedel <albeu@free.fr>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5667d50c
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Do not have 'comm' filter override event 'comm' field · 180c86a4
      Steven Rostedt (Red Hat) authored
      commit e57cbaf0 upstream.
      
      Commit 9f616680 "tracing: Allow triggers to filter for CPU ids and
      process names" added a 'comm' filter that will filter events based on the
      current tasks struct 'comm'. But this now hides the ability to filter events
      that have a 'comm' field too. For example, sched_migrate_task trace event.
      That has a 'comm' field of the task to be migrated.
      
       echo 'comm == "bash"' > events/sched_migrate_task/filter
      
      will now filter all sched_migrate_task events for tasks named "bash" that
      migrates other tasks (in interrupt context), instead of seeing when "bash"
      itself gets migrated.
      
      This fix requires a couple of changes.
      
      1) Change the look up order for filter predicates to look at the events
         fields before looking at the generic filters.
      
      2) Instead of basing the filter function off of the "comm" name, have the
         generic "comm" filter have its own filter_type (FILTER_COMM). Test
         against the type instead of the name to assign the filter function.
      
      3) Add a new "COMM" filter that works just like "comm" but will filter based
         on the current task, even if the trace event contains a "comm" field.
      
      Do the same for "cpu" field, adding a FILTER_CPU and a filter "CPU".
      
      Fixes: 9f616680 "tracing: Allow triggers to filter for CPU ids and process names"
      Reported-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      180c86a4
    • Manuel Lauss's avatar
      ata: ahci: don't mark HotPlugCapable Ports as external/removable · a55479ab
      Manuel Lauss authored
      commit dc8b4afc upstream.
      
      The HPCP bit is set by bioses for on-board sata ports either because
      they think sata is hotplug capable in general or to allow Windows
      to display a "device eject" icon on ports which are routed to an
      external connector bracket.
      
      However in Redhat Bugzilla #1310682, users report that with kernel 4.4,
      where this bit test first appeared, a lot of partitions on sata drives
      are now mounted automatically.
      
      This patch should fix redhat and a lot of other distros which
      unconditionally automount all devices which have the "removable"
      bit set.
      Signed-off-by: default avatarManuel Lauss <manuel.lauss@gmail.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Fixes: 8a3e33cf ("ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior)
      Link: http://lkml.kernel.org/g/56CF35FA.1070500@redhat.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a55479ab
    • Todd E Brandt's avatar
      PM / sleep / x86: Fix crash on graph trace through x86 suspend · af2d87ae
      Todd E Brandt authored
      commit 92f9e179 upstream.
      
      Pause/unpause graph tracing around do_suspend_lowlevel as it has
      inconsistent call/return info after it jumps to the wakeup vector.
      The graph trace buffer will otherwise become misaligned and
      may eventually crash and hang on suspend.
      
      To reproduce the issue and test the fix:
      Run a function_graph trace over suspend/resume and set the graph
      function to suspend_devices_and_enter. This consistently hangs the
      system without this fix.
      Signed-off-by: default avatarTodd Brandt <todd.e.brandt@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af2d87ae
    • Ard Biesheuvel's avatar
      arm64: vmemmap: use virtual projection of linear region · e75c4b65
      Ard Biesheuvel authored
      commit dfd55ad8 upstream.
      
      Commit dd006da2 ("arm64: mm: increase VA range of identity map") made
      some changes to the memory mapping code to allow physical memory to reside
      at an offset that exceeds the size of the virtual mapping.
      
      However, since the size of the vmemmap area is proportional to the size of
      the VA area, but it is populated relative to the physical space, we may
      end up with the struct page array being mapped outside of the vmemmap
      region. For instance, on my Seattle A0 box, I can see the following output
      in the dmesg log.
      
         vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
                   0xffffffbfc0000000 - 0xffffffbfd0000000   (   256 MB actual)
      
      We can fix this by deciding that the vmemmap region is not a projection of
      the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
      linear region. This way, we are guaranteed that the vmemmap region is of
      sufficient size, and we can even reduce the size by half.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e75c4b65
    • Alexandra Yates's avatar
      Adding Intel Lewisburg device IDs for SATA · 419a2cd1
      Alexandra Yates authored
      commit f5bdd66c upstream.
      
      This patch complements the list of device IDs previously
      added for lewisburg sata.
      Signed-off-by: default avatarAlexandra Yates <alexandra.yates@linux.intel.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      419a2cd1
    • Tejun Heo's avatar
      writeback: flush inode cgroup wb switches instead of pinning super_block · c5cbbec5
      Tejun Heo authored
      commit a1a0e23e upstream.
      
      If cgroup writeback is in use, inodes can be scheduled for
      asynchronous wb switching.  Before 5ff8eaac ("writeback: keep
      superblock pinned during cgroup writeback association switches"), this
      could race with umount leading to super_block being destroyed while
      inodes are pinned for wb switching.  5ff8eaac fixed it by bumping
      s_active while wb switches are in flight; however, this allowed
      in-flight wb switches to make umounts asynchronous when the userland
      expected synchronosity - e.g. fsck immediately following umount may
      fail because the device is still busy.
      
      This patch removes the problematic super_block pinning and instead
      makes generic_shutdown_super() flush in-flight wb switches.  wb
      switches are now executed on a dedicated isw_wq so that they can be
      flushed and isw_nr_in_flight keeps track of the number of in-flight wb
      switches so that flushing can be avoided in most cases.
      
      v2: Move cgroup_writeback_umount() further below and add MS_ACTIVE
          check in inode_switch_wbs() as Jan an Al suggested.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarTahsin Erdogan <tahsin@google.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com
      Fixes: 5ff8eaac ("writeback: keep superblock pinned during cgroup writeback association switches")
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Tested-by: default avatarTahsin Erdogan <tahsin@google.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5cbbec5
    • Ming Lei's avatar
      block: bio: introduce helpers to get the 1st and last bvec · 7adb5cc0
      Ming Lei authored
      commit 7bcd79ac upstream.
      
      The bio passed to bio_will_gap() may be fast cloned from upper
      layer(dm, md, bcache, fs, ...), or from bio splitting in block
      core.
      
      Unfortunately bio_will_gap() just figures out the last bvec via
      'bi_io_vec[prev->bi_vcnt - 1]' directly, and this way is obviously
      wrong.
      
      This patch introduces two helpers for getting the first and last
      bvec of one bio for fixing the issue.
      Reported-by: default avatarSagi Grimberg <sagig@dev.mellanox.co.il>
      Reviewed-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7adb5cc0
    • Harvey Hunt's avatar
      libata: Align ata_device's id on a cacheline · cea2cbff
      Harvey Hunt authored
      commit 4ee34ea3 upstream.
      
      The id buffer in ata_device is a DMA target, but it isn't explicitly
      cacheline aligned. Due to this, adjacent fields can be overwritten with
      stale data from memory on non coherent architectures. As a result, the
      kernel is sometimes unable to communicate with an ATA device.
      
      Fix this by ensuring that the id buffer is cacheline aligned.
      
      This issue is similar to that fixed by Commit 84bda12a
      ("libata: align ap->sector_buf").
      Signed-off-by: default avatarHarvey Hunt <harvey.hunt@imgtec.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cea2cbff
    • Arnd Bergmann's avatar
      libata: fix HDIO_GET_32BIT ioctl · b693f2ad
      Arnd Bergmann authored
      commit 287e6611 upstream.
      
      As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
      work correctly in compat mode with libata.
      
      I have investigated the issue further and found multiple problems
      that all appeared with the same commit that originally introduced
      HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
      also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
      a 'long' variable containing either 0 or 1 to user space.
      
      The problems with this are:
      
      * On big-endian machines, this will always write a zero because it
        stores the wrong byte into user space.
      
      * In compat mode, the upper three bytes of the variable are updated
        by the compat_hdio_ioctl() function, but they now contain
        uninitialized stack data.
      
      * The hdparm tool calling this ioctl uses a 'static long' variable
        to store the result. This means at least the upper bytes are
        initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
        would fill them with data that remains stale when the low byte
        is overwritten. Fortunately libata doesn't implement any of the
        affected ioctl commands, so this would only happen when we query
        both an IDE and an ATA device in the same command such as
        "hdparm -N -c /dev/hda /dev/sda"
      
      * The libata code for unknown reasons started using ATA_IOC_GET_IO32
        and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
        while the ioctl commands that were added later use the normal
        HDIO_* names. This is harmless but rather confusing.
      
      This addresses all four issues by changing the code to use put_user()
      on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
      does, and by clarifying the names of the ioctl commands.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarSoohoon Lee <Soohoon.Lee@f5.com>
      Tested-by: default avatarSoohoon Lee <Soohoon.Lee@f5.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b693f2ad
    • Arindam Nath's avatar
      drm/amdgpu: return from atombios_dp_get_dpcd only when error · f17a7e40
      Arindam Nath authored
      commit 0b39c531 upstream.
      
      In amdgpu_connector_hotplug(), we need to start DP link
      training only after we have received DPCD. The function
      amdgpu_atombios_dp_get_dpcd() returns non-zero value only
      when an error condition is met, otherwise returns zero.
      So in case the function encounters an error, we need to
      skip rest of the code and return from amdgpu_connector_hotplug()
      immediately. Only when we are successfull in reading DPCD
      pin, we should carry on with turning-on the monitor.
      Signed-off-by: default avatarArindam Nath <arindam.nath@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f17a7e40
    • Chunming Zhou's avatar
      drm/amdgpu/gfx8: specify which engine to wait before vm flush · 624a59a5
      Chunming Zhou authored
      commit 9cac5373 upstream.
      
      Select between me and pfp properly.
      Signed-off-by: default avatarChunming Zhou <David1.Zhou@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      624a59a5
    • Christian König's avatar
      drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well · a46a700a
      Christian König authored
      commit feebe91a upstream.
      
      We never ported that back to CIK, so we could run into VM faults here.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a46a700a
    • Alex Deucher's avatar
      drm/amdgpu/pm: update current crtc info after setting the powerstate · 3b0809af
      Alex Deucher authored
      commit eda1d1cf upstream.
      
      On CI, we need to see if the number of crtcs changes to determine
      whether or not we need to upload the mclk table again.  In practice
      we don't currently upload the mclk table again after the initial load.
      The only reason you would would be to add new states, e.g., for
      arbitrary mclk setting which is not currently supported.
      Acked-by: default avatarJordan Lazare <Jordan.Lazare@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b0809af
    • Alex Deucher's avatar
      drm/radeon/pm: update current crtc info after setting the powerstate · 80e726c7
      Alex Deucher authored
      commit 5e031d9f upstream.
      
      On CI, we need to see if the number of crtcs changes to determine
      whether or not we need to upload the mclk table again.  In practice
      we don't currently upload the mclk table again after the initial load.
      The only reason you would would be to add new states, e.g., for
      arbitrary mclk setting which is not currently supported.
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80e726c7
    • Timothy Pearson's avatar
      drm/ast: Fix incorrect register check for DRAM width · 598fc9b7
      Timothy Pearson authored
      commit 2d02b8bd upstream.
      
      During DRAM initialization on certain ASpeed devices, an incorrect
      bit (bit 10) was checked in the "SDRAM Bus Width Status" register
      to determine DRAM width.
      
      Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.
      Signed-off-by: default avatarTimothy Pearson <tpearson@raptorengineeringinc.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      598fc9b7
    • Mike Christie's avatar
      target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors · 3028963a
      Mike Christie authored
      commit 8a9ebe71 upstream.
      
      In a couple places we are not converting to/from the Linux
      block layer 512 bytes sectors.
      
      1.
      
      The request queue values and what we do are a mismatch of
      things:
      
      max_discard_sectors - This is in linux block layer 512 byte
      sectors. We are just copying this to max_unmap_lba_count.
      
      discard_granularity - This is in bytes. We are converting it
      to Linux block layer 512 byte sectors.
      
      discard_alignment - This is in bytes. We are just copying
      this over.
      
      The problem is that the core LIO code exports these values in
      spc_emulate_evpd_b0 and we use them to test request arguments
      in sbc_execute_unmap, but we never convert to the block size
      we export to the initiator. If we are not using 512 byte sectors
      then we are exporting the wrong values or are checks are off.
      And, for the discard_alignment/bytes case we are just plain messed
      up.
      
      2.
      
      blkdev_issue_discard's start and number of sector arguments
      are supposed to be in linux block layer 512 byte sectors. We are
      currently passing in the values we get from the initiator which
      might be based on some other sector size.
      
      There is a similar problem in iblock_execute_write_same where
      the bio functions want values in 512 byte sectors but we are
      passing in what we got from the initiator.
      Signed-off-by: default avatarMike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ kamal: backport to 4.4-stable: no unmap_zeroes_data ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3028963a
    • Joerg Roedel's avatar
      iommu/vt-d: Use BUS_NOTIFY_REMOVED_DEVICE in hotplug path · 00548ecf
      Joerg Roedel authored
      commit e6a8c9b3 upstream.
      
      In the PCI hotplug path of the Intel IOMMU driver, replace
      the usage of the BUS_NOTIFY_DEL_DEVICE notifier, which is
      executed before the driver is unbound from the device, with
      BUS_NOTIFY_REMOVED_DEVICE, which runs after that.
      
      This fixes a kernel BUG being triggered in the VT-d code
      when the device driver tries to unmap DMA buffers and the
      VT-d driver already destroyed all mappings.
      Reported-by: default avatarStefani Seibold <stefani@seibold.net>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00548ecf
    • Suravee Suthikulpanit's avatar
      iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered · 44792d5c
      Suravee Suthikulpanit authored
      commit 38e45d02 upstream.
      
      The setup code for the performance counters in the AMD IOMMU driver
      tests whether the counters can be written. It tests to setup a counter
      for device 00:00.0, which fails on systems where this particular device
      is not covered by the IOMMU.
      
      Fix this by not relying on device 00:00.0 but only on the IOMMU being
      present.
      Signed-off-by: default avatarSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44792d5c
    • Jay Cornwall's avatar
      iommu/amd: Apply workaround for ATS write permission check · ad0f9dad
      Jay Cornwall authored
      commit 358875fd upstream.
      
      The AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's
      Guide omitted part of the BIOS IOMMU L2 register setup specification.
      Without this setup the IOMMU L2 does not fully respect write permissions
      when handling an ATS translation request.
      
      The IOMMU L2 will set PTE dirty bit when handling an ATS translation with
      write permission request, even when PTE RW bit is clear. This may occur by
      direct translation (which would cause a PPR) or by prefetch request from
      the ATC.
      
      This is observed in practice when the IOMMU L2 modifies a PTE which maps a
      pagecache page. The ext4 filesystem driver BUGs when asked to writeback
      these (non-modified) pages.
      
      Enable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not.
      Signed-off-by: default avatarJay Cornwall <jay@jcornwall.me>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad0f9dad
    • Michael S. Tsirkin's avatar
      arm/arm64: KVM: Fix ioctl error handling · d1c623c9
      Michael S. Tsirkin authored
      commit 4cad67fc upstream.
      
      Calling return copy_to_user(...) in an ioctl will not
      do the right thing if there's a pagefault:
      copy_to_user returns the number of bytes not copied
      in this case.
      
      Fix up kvm to do
      	return copy_to_user(...)) ?  -EFAULT : 0;
      
      everywhere.
      Acked-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1c623c9