1. 17 Aug, 2019 1 commit
  2. 15 Aug, 2019 11 commits
    • Christoph Hellwig's avatar
      usb: add a hcd_uses_dma helper · edfbcb32
      Christoph Hellwig authored
      
      
      The USB buffer allocation code is the only place in the usb core (and in
      fact the whole kernel) that uses is_device_dma_capable, while the URB
      mapping code uses the uses_dma flag in struct usb_bus.  Switch the buffer
      allocation to use the uses_dma flag used by the rest of the USB code,
      and create a helper in hcd.h that checks this flag as well as the
      CONFIG_HAS_DMA to simplify the caller a bit.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Link: https://lore.kernel.org/r/20190811080520.21712-3-hch@lst.de
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edfbcb32
    • Christoph Hellwig's avatar
      usb: don't create dma pools for HCDs with a localmem_pool · dd3ecf17
      Christoph Hellwig authored
      If the HCD provides a localmem pool we will never use the DMA pools, so
      don't create them.
      
      Fixes: b0310c2f
      
       ("USB: use genalloc for USB HCs with local memory")
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Link: https://lore.kernel.org/r/20190811080520.21712-2-hch@lst.de
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd3ecf17
    • André Draszik's avatar
      usb: chipidea: imx: fix EPROBE_DEFER support during driver probe · 141822aa
      André Draszik authored
      If driver probe needs to be deferred, e.g. because ci_hdrc_add_device()
      isn't ready yet, this driver currently misbehaves badly:
          a) success is still reported to the driver core (meaning a 2nd
             probe attempt will never be done), leaving the driver in
             a dysfunctional state and the hardware unusable
      
          b) driver remove / shutdown OOPSes:
          [  206.786916] Unable to handle kernel paging request at virtual address fffffdff
          [  206.794148] pgd = 880b9f82
          [  206.796890] [fffffdff] *pgd=abf5e861, *pte=00000000, *ppte=00000000
          [  206.803179] Internal error: Oops: 37 [#1] PREEMPT SMP ARM
          [  206.808581] Modules linked in: wl18xx evbug
          [  206.813308] CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 4.19.35+gf345c93b4195 #1
          [  206.821053] Hardware name: Freescale i.MX7 Dual (Device Tree)
          [  206.826813] PC is at ci_hdrc_remove_device+0x4/0x20
          [  206.831699] LR is at ci_hdrc_imx_remove+0x20/0xe8
          [  206.836407] pc : [<805cd4b0>]    lr : [<805d62cc>]    psr: 20000013
          [  206.842678] sp : a806be40  ip : 00000001  fp : 80adbd3c
          [  206.847906] r10: 80b1b794  r9 : 80d5dfe0  r8 : a8192c44
          [  206.853136] r7 : 80db93a0  r6 : a8192c10  r5 : a8192c00  r4 : a93a4a00
          [  206.859668] r3 : 00000000  r2 : a8192ce4  r1 : ffffffff  r0 : fffffdfb
          [  206.866201] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
          [  206.873341] Control: 10c5387d  Table: a9e0c06a  DAC: 00000051
          [  206.879092] Process systemd-shutdow (pid: 1, stack limit = 0xb271353c)
          [  206.885624] Stack: (0xa806be40 to 0xa806c000)
          [  206.889992] be40: a93a4a00 805d62cc a8192c1c a8170e10 a8192c10 8049a490 80d04d08 00000000
          [  206.898179] be60: 00000000 80d0da2c fee1dead 00000000 a806a000 00000058 00000000 80148b08
          [  206.906366] be80: 01234567 80148d8c a9858600 00000000 00000000 00000000 00000000 80d04d08
          [  206.914553] bea0: 00000000 00000000 a82741e0 a9858600 00000024 00000002 a9858608 00000005
          [  206.922740] bec0: 0000001e 8022c058 00000000 00000000 a806bf14 a9858600 00000000 a806befc
          [  206.930927] bee0: a806bf78 00000000 7ee12c30 8022c18c a806bef8 a806befc 00000000 00000001
          [  206.939115] bf00: 00000000 00000024 a806bf14 00000005 7ee13b34 7ee12c68 00000004 7ee13f20
          [  206.947302] bf20: 00000010 7ee12c7c 00000005 7ee12d04 0000000a 76e7dc00 00000001 80d0f140
          [  206.955490] bf40: ab637880 a974de40 60000013 80d0f140 ab6378a0 80d04d08 a8080470 a9858600
          [  206.963677] bf60: a9858600 00000000 00000000 8022c24c 00000000 80144310 00000000 00000000
          [  206.971864] bf80: 80101204 80d04d08 00000000 80d04d08 00000000 00000000 00000003 00000058
          [  206.980051] bfa0: 80101204 80101000 00000000 00000000 fee1dead 28121969 01234567 00000000
          [  206.988237] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000
          [  206.996425] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6 60000030 fee1dead 00000000 00000000
          [  207.004622] [<805cd4b0>] (ci_hdrc_remove_device) from [<805d62cc>] (ci_hdrc_imx_remove+0x20/0xe8)
          [  207.013509] [<805d62cc>] (ci_hdrc_imx_remove) from [<8049a490>] (device_shutdown+0x16c/0x218)
          [  207.022050] [<8049a490>] (device_shutdown) from [<80148b08>] (kernel_restart+0xc/0x50)
          [  207.029980] [<80148b08>] (kernel_restart) from [<80148d8c>] (sys_reboot+0xf4/0x1f0)
          [  207.037648] [<80148d8c>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54)
          [  207.045308] Exception stack(0xa806bfa8 to 0xa806bff0)
          [  207.050368] bfa0:                   00000000 00000000 fee1dead 28121969 01234567 00000000
          [  207.058554] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000
          [  207.066737] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6
          [  207.071799] Code: ebffffa8 e3a00000 e8bd8010 e92d4010 (e5904004)
          [  207.078021] ---[ end trace be47424e3fd46e9f ]---
          [  207.082647] Kernel panic - not syncing: Fatal exception
          [  207.087894] ---[ end Kernel panic - not syncing: Fatal exception ]---
      
          c) the error path in combination with driver removal causes
             imbalanced calls to the clk_*() and pm_()* APIs
      
      a) happens because the original intended return value is
         overwritten (with 0) by the return code of
         regulator_disable() in ci_hdrc_imx_probe()'s error path
      b) happens because ci_pdev is -EPROBE_DEFER, which causes
         ci_hdrc_remove_device() to OOPS
      
      Fix a) by being more careful in ci_hdrc_imx_probe()'s error
      path and not overwriting the real error code
      
      Fix b) by calling the respective cleanup functions during
      remove only when needed (when ci_pdev != NULL, i.e. when
      everything was initialised correctly). This also has the
      side effect of not causing imbalanced clk_*() and pm_*()
      API calls as part of the error code path.
      
      Fixes: 7c8e8909
      
       ("usb: chipidea: imx: add HSIC support")
      Signed-off-by: default avatarAndré Draszik <git@andred.net>
      Cc: stable <stable@vger.kernel.org>
      CC: Peter Chen <Peter.Chen@nxp.com>
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      CC: Shawn Guo <shawnguo@kernel.org>
      CC: Sascha Hauer <s.hauer@pengutronix.de>
      CC: Pengutronix Kernel Team <kernel@pengutronix.de>
      CC: Fabio Estevam <festevam@gmail.com>
      CC: NXP Linux Team <linux-imx@nxp.com>
      CC: linux-usb@vger.kernel.org
      CC: linux-arm-kernel@lists.infradead.org
      CC: linux-kernel@vger.kernel.org
      Link: https://lore.kernel.org/r/20190810150758.17694-1-git@andred.net
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      141822aa
    • Hans Ulli Kroll's avatar
      usb: host: fotg2: restart hcd after port reset · 77775888
      Hans Ulli Kroll authored
      
      
      On the Gemini SoC the FOTG2 stalls after port reset
      so restart the HCD after each port reset.
      Signed-off-by: default avatarHans Ulli Kroll <ulli.kroll@googlemail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20190810150458.817-1-linus.walleij@linaro.org
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      77775888
    • Oliver Neukum's avatar
      USB: CDC: fix sanity checks in CDC union parser · 54364278
      Oliver Neukum authored
      A few checks checked for the size of the pointer to a structure
      instead of the structure itself. Copy & paste issue presumably.
      
      Fixes: e4c6fb77
      
       ("usbnet: move the CDC parser into USB core")
      Cc: stable <stable@vger.kernel.org>
      Reported-by: syzbot+45a53506b65321c1fe91@syzkaller.appspotmail.com
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Link: https://lore.kernel.org/r/20190813093541.18889-1-oneukum@suse.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54364278
    • Oliver Neukum's avatar
      usb: cdc-acm: make sure a refcount is taken early enough · c52873e5
      Oliver Neukum authored
      destroy() will decrement the refcount on the interface, so that
      it needs to be taken so early that it never undercounts.
      
      Fixes: 7fb57a01
      
       ("USB: cdc-acm: Fix potential deadlock (lockdep warning)")
      Cc: stable <stable@vger.kernel.org>
      Reported-and-tested-by: syzbot+1b2449b7b5dc240d107a@syzkaller.appspotmail.com
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Link: https://lore.kernel.org/r/20190808142119.7998-1-oneukum@suse.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c52873e5
    • Bob Ham's avatar
      USB: serial: option: add the BroadMobi BM818 card · e5d8badf
      Bob Ham authored
      
      
      Add a VID:PID for the BroadMobi BM818 M.2 card
      
      T:  Bus=01 Lev=03 Prnt=40 Port=03 Cnt=01 Dev#= 44 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=2060 Rev=00.00
      S:  Manufacturer=Qualcomm, Incorporated
      S:  Product=Qualcomm CDMA Technologies MSM
      C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      I:  If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=(none)
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      Signed-off-by: default avatarBob Ham <bob.ham@puri.sm>
      Signed-off-by: default avatarAngus Ainslie (Purism) <angus@akkea.ca>
      Cc: stable <stable@vger.kernel.org>
      [ johan: use USB_DEVICE_INTERFACE_CLASS() ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      e5d8badf
    • Tony Lindgren's avatar
      USB: serial: option: Add Motorola modem UARTs · 6caf0be4
      Tony Lindgren authored
      
      
      On Motorola Mapphone devices such as Droid 4 there are five USB ports
      that do not use the same layout as Gobi 1K/2K/etc devices listed in
      qcserial.c. So we should use qcaux.c or option.c as noted by
      Dan Williams <dan.j.williams@intel.com>.
      
      As the Motorola USB serial ports have an interrupt endpoint as shown
      with lsusb -v, we should use option.c instead of qcaux.c as pointed out
      by Johan Hovold <johan@kernel.org>.
      
      The ff/ff/ff interfaces seem to always be UARTs on Motorola devices.
      For the other interfaces, class 0x0a (CDC Data) should not in general
      be added as they are typically part of a multi-interface function as
      noted earlier by Bjørn Mork <bjorn@mork.no>.
      
      However, looking at the Motorola mapphone kernel code, the mdm6600 0x0a
      class is only used for flashing the modem firmware, and there are no
      other interfaces. So I've added that too with more details below as it
      works just fine.
      
      The ttyUSB ports on Droid 4 are:
      
      ttyUSB0 DIAG, CQDM-capable
      ttyUSB1 MUX or NMEA, no response
      ttyUSB2 MUX or NMEA, no response
      ttyUSB3 TCMD
      ttyUSB4 AT-capable
      
      The ttyUSB0 is detected as QCDM capable by ModemManager. I think
      it's only used for debugging with ModemManager --debug for sending
      custom AT commands though. ModemManager already can manage data
      connection using the USB QMI ports that are already handled by the
      qmi_wwan.c driver.
      
      To enable the MUX or NMEA ports, it seems that something needs to be
      done additionally to enable them, maybe via the DIAG or TCMD port.
      It might be just a NVRAM setting somewhere, but I have no idea what
      NVRAM settings may need changing for that.
      
      The TCMD port seems to be a Motorola custom protocol for testing
      the modem and to configure it's NVRAM and seems to work just fine
      based on a quick test with a minimal tcmdrw tool I wrote.
      
      The voice modem AT-capable port seems to provide only partial
      support, and no PM support compared to the TS 27.010 based UART
      wired directly to the modem.
      
      The UARTs added with this change are the same product IDs as the
      Motorola Mapphone Android Linux kernel mdm6600_id_table. I don't
      have any mdm9600 based devices, so I have only tested these on
      mdm6600 based droid 4.
      
      Then for the class 0x0a (CDC Data) mode, the Motorola Mapphone Android
      Linux kernel driver moto_flashqsc.c just seems to change the
      port->bulk_out_size to 8K from the default. And is only used for
      flashing the modem firmware it seems.
      
      I've verified that flashing the modem with signed firmware works just
      fine with the option driver after manually toggling the GPIO pins, so
      I've added droid 4 modem flashing mode to the option driver. I've not
      added the other devices listed in moto_flashqsc.c in case they really
      need different port->bulk_out_size. Those can be added as they get
      tested to work for flashing the modem.
      
      After this patch the output of /sys/kernel/debug/usb/devices has
      the following for normal 22b8:2a70 mode including the related qmi_wwan
      interfaces:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=22b8 ProdID=2a70 Rev= 0.00
      S:  Manufacturer=Motorola, Incorporated
      S:  Product=Flash MZ600
      C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=8a(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=8b(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=8c(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=08(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan
      E:  Ad=8d(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
      E:  Ad=8e(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=09(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      
      In 22b8:900e "qc_dload" mode the device shows up as:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=22b8 ProdID=900e Rev= 0.00
      S:  Manufacturer=Motorola, Incorporated
      S:  Product=Flash MZ600
      C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      
      And in 22b8:4281 "ram_downloader" mode the device shows up as:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=22b8 ProdID=4281 Rev= 0.00
      S:  Manufacturer=Motorola, Incorporated
      S:  Product=Flash MZ600
      C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=fc Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      
      Cc: Bjørn Mork <bjorn@mork.no>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Lars Melin <larsm17@gmail.com>
      Cc: Marcel Partap <mpartap@gmx.net>
      Cc: Merlijn Wajer <merlijn@wizzup.org>
      Cc: Michael Scott <hashcode0f@gmail.com>
      Cc: NeKit <nekit1000@gmail.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Sebastian Reichel <sre@kernel.org>
      Tested-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      6caf0be4
    • Lyude Paul's avatar
      drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes · db1231dd
      Lyude Paul authored
      
      
      I -thought- I had fixed this entirely, but it looks like that I didn't
      test this thoroughly enough as we apparently still make one big mistake
      with nv50_msto_atomic_check() - we don't handle the following scenario:
      
      * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4
        which is attached to encoder #1. enabled=y active=n
      * CRTC #1 is changed from DP-4 to DP-5, causing:
        * DP-4 crtc=#1→NULL (VCPI n→0)
        * DP-5 crtc=NULL→#1
        * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5
        * CRTC #1 maintains the same mode as before, just with a different
          connector
      * mode_changed=n connectors_changed=y
        (we _SHOULD_ do VCPI 0→n here, but don't)
      
      Once the above scenario is repeated once, we'll attempt freeing VCPI
      from the connector that we didn't allocate due to the connectors
      changing, but the mode staying the same. Sigh.
      
      Since nv50_msto_atomic_check() has broken a few times now, let's rethink
      things a bit to be more careful: limit both VCPI/PBN allocations to
      mode_changed || connectors_changed, since neither VCPI or PBN should
      ever need to change outside of routing and mode changes.
      
      Changes since v1:
      * Fix accidental reversal of clock and bpp arguments in
        drm_dp_calc_pbn_mode() - William Lewis
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reported-by: default avatarBohdan Milar <bmilar@redhat.com>
      Tested-by: default avatarBohdan Milar <bmilar@redhat.com>
      Fixes: 232c9eec ("drm/nouveau: Use atomic VCPI helpers for MST")
      References: 412e85b6
      
       ("drm/nouveau: Only release VCPI slots on mode changes")
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: David Airlie <airlied@redhat.com>
      Cc: Jerry Zuo <Jerry.Zuo@amd.com>
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Juston Li <juston.li@intel.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Karol Herbst <karolherbst@gmail.com>
      Cc: Ilia Mirkin <imirkin@alum.mit.edu>
      Cc: <stable@vger.kernel.org> # v5.1+
      Acked-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190809005307.18391-1-lyude@redhat.com
      db1231dd
    • Y.C. Chen's avatar
      drm/ast: Fixed reboot test may cause system hanged · 05b43971
      Y.C. Chen authored
      
      
      There is another thread still access standard VGA I/O while loading drm driver.
      Disable standard VGA I/O decode to avoid this issue.
      Signed-off-by: default avatarY.C. Chen <yc_chen@aspeedtech.com>
      Reviewed-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1523410059-18415-1-git-send-email-yc_chen@aspeedtech.com
      05b43971
    • Lubomir Rintel's avatar
      of: irq: fix a trivial typo in a doc comment · 83f82d7a
      Lubomir Rintel authored
      Diverged from what the code does with commit 530210c7
      
       ("of/irq: Replace
      of_irq with of_phandle_args").
      Signed-off-by: default avatarLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      83f82d7a
  3. 14 Aug, 2019 5 commits
    • Christian König's avatar
      drm/scheduler: use job count instead of peek · e1b4ce25
      Christian König authored
      
      
      The spsc_queue_peek function is accessing queue->head which belongs to
      the consumer thread and shouldn't be accessed by the producer
      
      This is fixing a rare race condition when destroying entities.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Acked-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Reviewed-by: Monk.liu@amd.com
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      e1b4ce25
    • Nishad Kamdar's avatar
      i2c: stm32: Use the correct style for SPDX License Identifier · 90865a3d
      Nishad Kamdar authored
      This patch corrects the SPDX License Identifier style
      in header file related to STM32 Driver for I2C hardware
      bus support.
      For C header files Documentation/process/license-rules.rst
      mandates C-like comments (opposed to C source files where
      C++ style should be used)
      
      Changes made by using a script provided by Joe Perches here:
      https://lkml.org/lkml/2019/2/7/46
      
      Suggested-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarNishad Kamdar <nishadkamdar@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      90865a3d
    • Wolfram Sang's avatar
      i2c: emev2: avoid race when unregistering slave client · d7437fc0
      Wolfram Sang authored
      After we disabled interrupts, there might still be an active one
      running. Sync before clearing the pointer to the slave device.
      
      Fixes: c31d0a00
      
       ("i2c: emev2: add slave support")
      Reported-by: default avatarKrzysztof Adamski <krzysztof.adamski@nokia.com>
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: default avatarKrzysztof Adamski <krzysztof.adamski@nokia.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      d7437fc0
    • Wolfram Sang's avatar
      i2c: rcar: avoid race when unregistering slave client · 7b814d85
      Wolfram Sang authored
      After we disabled interrupts, there might still be an active one
      running. Sync before clearing the pointer to the slave device.
      
      Fixes: de20d185
      
       ("i2c: rcar: add slave support")
      Reported-by: default avatarKrzysztof Adamski <krzysztof.adamski@nokia.com>
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: default avatarKrzysztof Adamski <krzysztof.adamski@nokia.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      7b814d85
    • Fabio Estevam's avatar
      Revert "i2c: imx: improve the error handling in i2c_imx_dma_request()" · e8c220fa
      Fabio Estevam authored
      Since commit e1ab9a46 ("i2c: imx: improve the error handling in
      i2c_imx_dma_request()") when booting with the DMA driver as module (such
      as CONFIG_FSL_EDMA=m) the following endless clk warnings are seen:
      
      [  153.077831] ------------[ cut here ]------------
      [  153.082528] WARNING: CPU: 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24
      [  153.093077] i2c0 already disabled
      [  153.096416] Modules linked in:
      [  153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G        W         5.2.0+ #321
      [  153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
      [  153.113772] Workqueue: events deferred_probe_work_func
      [  153.118979] [<c0019560>] (unwind_backtrace) from [<c0014734>] (show_stack+0x10/0x14)
      [  153.126778] [<c0014734>] (show_stack) from [<c083f8dc>] (dump_stack+0x9c/0xd4)
      [  153.134051] [<c083f8dc>] (dump_stack) from [<c0031154>] (__warn+0xf8/0x124)
      [  153.141056] [<c0031154>] (__warn) from [<c0031248>] (warn_slowpath_fmt+0x38/0x48)
      [  153.148580] [<c0031248>] (warn_slowpath_fmt) from [<c040fde0>] (clk_core_disable_lock+0x18/0x24)
      [  153.157413] [<c040fde0>] (clk_core_disable_lock) from [<c058f520>] (i2c_imx_probe+0x554/0x6ec)
      [  153.166076] [<c058f520>] (i2c_imx_probe) from [<c04b9178>] (platform_drv_probe+0x48/0x98)
      [  153.174297] [<c04b9178>] (platform_drv_probe) from [<c04b7298>] (really_probe+0x1d8/0x2c0)
      [  153.182605] [<c04b7298>] (really_probe) from [<c04b7554>] (driver_probe_device+0x5c/0x174)
      [  153.190909] [<c04b7554>] (driver_probe_device) from [<c04b58c8>] (bus_for_each_drv+0x44/0x8c)
      [  153.199480] [<c04b58c8>] (bus_for_each_drv) from [<c04b746c>] (__device_attach+0xa0/0x108)
      [  153.207782] [<c04b746c>] (__device_attach) from [<c04b65a4>] (bus_probe_device+0x88/0x90)
      [  153.215999] [<c04b65a4>] (bus_probe_device) from [<c04b6a04>] (deferred_probe_work_func+0x60/0x90)
      [  153.225003] [<c04b6a04>] (deferred_probe_work_func) from [<c004f190>] (process_one_work+0x204/0x634)
      [  153.234178] [<c004f190>] (process_one_work) from [<c004f618>] (worker_thread+0x20/0x484)
      [  153.242315] [<c004f618>] (worker_thread) from [<c0055c2c>] (kthread+0x118/0x150)
      [  153.249758] [<c0055c2c>] (kthread) from [<c00090b4>] (ret_from_fork+0x14/0x20)
      [  153.257006] Exception stack(0xdde43fb0 to 0xdde43ff8)
      [  153.262095] 3fa0:                                     00000000 00000000 00000000 00000000
      [  153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [  153.278520] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      [  153.285159] irq event stamp: 3323022
      [  153.288787] hardirqs last  enabled at (3323021): [<c0861c4c>] _raw_spin_unlock_irq+0x24/0x2c
      [  153.297261] hardirqs last disabled at (3323022): [<c040d7a0>] clk_enable_lock+0x10/0x124
      [  153.305392] softirqs last  enabled at (3322092): [<c000a504>] __do_softirq+0x344/0x540
      [  153.313352] softirqs last disabled at (3322081): [<c00385c0>] irq_exit+0x10c/0x128
      [  153.320946] ---[ end trace a506731ccd9bd703 ]---
      
      This endless clk warnings behaviour is well explained by Andrey Smirnov:
      
      "Allocating DMA after registering I2C adapter can lead to infinite
      probing loop, for example, consider the following scenario:
      
          1. i2c_imx_probe() is called and successfully registers an I2C
             adapter via i2c_add_numbered_adapter()
      
          2. As a part of i2c_add_numbered_adapter() new I2C slave devices
             are added from DT which results in a call to
             driver_deferred_probe_trigger()
      
          3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which
             due to lack of proper DMA driver returns -EPROBE_DEFER
      
          4. i2c_imx_probe() fails, removes I2C adapter and returns
             -EPROBE_DEFER, which places it into deferred probe list
      
          5. Deferred probe work triggered in #2 above kicks in and calls
             i2c_imx_probe() again thus bringing us to step #1"
      
      So revert commit e1ab9a46
      
       ("i2c: imx: improve the error handling in
      i2c_imx_dma_request()") and restore the old behaviour, in order to
      avoid regressions on existing setups.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Reported-by: default avatarRussell King <linux@armlinux.org.uk>
      Fixes: e1ab9a46
      
       ("i2c: imx: improve the error handling in i2c_imx_dma_request()")
      Signed-off-by: default avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      e8c220fa
  4. 13 Aug, 2019 3 commits
  5. 12 Aug, 2019 11 commits
    • Nishka Dasgupta's avatar
      of: resolver: Add of_node_put() before return and break · 60d437bb
      Nishka Dasgupta authored
      
      
      Each iteration of for_each_child_of_node puts the previous node, but in
      the case of a return or break from the middle of the loop, there is no
      put, thus causing a memory leak. Hence add an of_node_put before the
      return or break in three places.
      Issue found with Coccinelle.
      Signed-off-by: default avatarNishka Dasgupta <nishkadg.linux@gmail.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      60d437bb
    • Alan Stern's avatar
      USB: core: Fix races in character device registration and deregistraion · 303911cf
      Alan Stern authored
      
      
      The syzbot fuzzer has found two (!) races in the USB character device
      registration and deregistration routines.  This patch fixes the races.
      
      The first race results from the fact that usb_deregister_dev() sets
      usb_minors[intf->minor] to NULL before calling device_destroy() on the
      class device.  This leaves a window during which another thread can
      allocate the same minor number but will encounter a duplicate name
      error when it tries to register its own class device.  A typical error
      message in the system log would look like:
      
          sysfs: cannot create duplicate filename '/class/usbmisc/ldusb0'
      
      The patch fixes this race by destroying the class device first.
      
      The second race is in usb_register_dev().  When that routine runs, it
      first allocates a minor number, then drops minor_rwsem, and then
      creates the class device.  If the device creation fails, the minor
      number is deallocated and the whole routine returns an error.  But
      during the time while minor_rwsem was dropped, there is a window in
      which the minor number is allocated and so another thread can
      successfully open the device file.  Typically this results in
      use-after-free errors or invalid accesses when the other thread closes
      its open file reference, because the kernel then tries to release
      resources that were already deallocated when usb_register_dev()
      failed.  The patch fixes this race by keeping minor_rwsem locked
      throughout the entire routine.
      
      Reported-and-tested-by: syzbot+30cf45ebfe0b0c4847a1@syzkaller.appspotmail.com
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908121607590.1659-100000@iolanthe.rowland.org
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      303911cf
    • Dan Carpenter's avatar
      RDMA/core: Fix error code in stat_get_doit_qp() · 932727c5
      Dan Carpenter authored
      We need to set the error codes on these paths.  Currently the only
      possible error code is -EMSGSIZE so that's what the patch uses.
      
      Fixes: 83c2c1fc
      
       ("RDMA/nldev: Allow get counter mode through RDMA netlink")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190809101311.GA17867@mwanda
      
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      932727c5
    • Dan Carpenter's avatar
      RDMA/siw: Fix a memory leak in siw_init_cpulist() · 17c19287
      Dan Carpenter authored
      The error handling code doesn't free siw_cpu_info.tx_valid_cpus[0].  The
      first iteration through the loop is a no-op so this is sort of an off
      by one bug.  Also Bernard pointed out that we can remove the NULL
      assignment and simplify the code a bit.
      
      Fixes: bdcf26bf
      
       ("rdma/siw: network and RDMA core interface")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarBernard Metzler <bmt@zurich.ibm.com>
      Reviewed-by: default avatarBernard Metzler <bmt@zurich.ibm.com>
      Link: https://lore.kernel.org/r/20190809140904.GB3552@mwanda
      
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      17c19287
    • Yishai Hadas's avatar
      IB/mlx5: Fix use-after-free error while accessing ev_file pointer · e9eec6a5
      Yishai Hadas authored
      Call to uverbs_close_fd() releases file pointer to 'ev_file' and
      mlx5_ib_dev is going to be inaccessible. Cache pointer prior cleaning
      resources to solve the KASAN warning below.
      
      BUG: KASAN: use-after-free in devx_async_event_close+0x391/0x480 [mlx5_ib]
      Read of size 8 at addr ffff888301e3cec0 by task devx_direct_tes/4631
      CPU: 1 PID: 4631 Comm: devx_direct_tes Tainted: G OE 5.3.0-rc1-for-upstream-dbg-2019-07-26_01-19-56-93 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
      Call Trace:
      dump_stack+0x9a/0xeb
      print_address_description+0x1e2/0x400
      ? devx_async_event_close+0x391/0x480 [mlx5_ib]
      __kasan_report+0x15c/0x1df
      ? devx_async_event_close+0x391/0x480 [mlx5_ib]
      kasan_report+0xe/0x20
      devx_async_event_close+0x391/0x480 [mlx5_ib]
      __fput+0x26a/0x7b0
      task_work_run+0x10d/0x180
      exit_to_usermode_loop+0x137/0x160
      do_syscall_64+0x3c7/0x490
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7f5df907d664
      Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f
      80 00 00 00 00 8b 05 6a cd 20 00 48 63 ff 85 c0 75 13 b8
      03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 f3 c3 66 90
      48 83 ec 18 48 89 7c 24 08 e8
      RSP: 002b:00007ffd353cb958 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
      RAX: 0000000000000000 RBX: 000056017a88c348 RCX: 00007f5df907d664
      RDX: 00007f5df969d400 RSI: 00007f5de8f1ec90 RDI: 0000000000000006
      RBP: 00007f5df9681dc0 R08: 00007f5de8736410 R09: 000056017a9d2dd0
      R10: 000000000000000b R11: 0000000000000246 R12: 00007f5de899d7d0
      R13: 00007f5df96c4248 R14: 00007f5de8f1ecb0 R15: 000056017ae41308
      
      Allocated by task 4631:
      save_stack+0x19/0x80
      kasan_kmalloc.constprop.3+0xa0/0xd0
      alloc_uobj+0x71/0x230 [ib_uverbs]
      alloc_begin_fd_uobject+0x2e/0xc0 [ib_uverbs]
      rdma_alloc_begin_uobject+0x96/0x140 [ib_uverbs]
      ib_uverbs_run_method+0xdf0/0x1940 [ib_uverbs]
      ib_uverbs_cmd_verbs+0x57e/0xdb0 [ib_uverbs]
      ib_uverbs_ioctl+0x177/0x260 [ib_uverbs]
      do_vfs_ioctl+0x18f/0x1010
      ksys_ioctl+0x70/0x80
      __x64_sys_ioctl+0x6f/0xb0
      do_syscall_64+0x95/0x490
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 4631:
      save_stack+0x19/0x80
      __kasan_slab_free+0x11d/0x160
      slab_free_freelist_hook+0x67/0x1a0
      kfree+0xb9/0x2a0
      uverbs_close_fd+0x118/0x1c0 [ib_uverbs]
      devx_async_event_close+0x28a/0x480 [mlx5_ib]
      __fput+0x26a/0x7b0
      task_work_run+0x10d/0x180
      exit_to_usermode_loop+0x137/0x160
      do_syscall_64+0x3c7/0x490
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff888301e3cda8
      which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 280 bytes inside of 512-byte region
      [ffff888301e3cda8, ffff888301e3cfa8)
      The buggy address belongs to the page:
      page:ffffea000c078e00 refcount:1 mapcount:0
      mapping:ffff888352811300 index:0x0 compound_mapcount: 0
      flags: 0x2fffff80010200(slab|head)
      raw: 002fffff80010200 ffffea000d152608 ffffea000c077808 ffff888352811300
      raw: 0000000000000000 0000000000250025 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      Memory state around the buggy address:
      ffff888301e3cd80: fc fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3ce00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3ce80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3cf00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3cf80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
      Disabling lock debugging due to kernel taint
      
      Cc: <stable@vger.kernel.org> # 5.2
      Fixes: 75973853
      
       ("IB/mlx5: Enable subscription for device events over DEVX")
      Signed-off-by: default avatarYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Link: https://lore.kernel.org/r/20190808081538.28772-1-leon@kernel.org
      
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      e9eec6a5
    • Wenwen Wang's avatar
      xen/blkback: fix memory leaks · ae78ca3c
      Wenwen Wang authored
      
      
      In read_per_ring_refs(), after 'req' and related memory regions are
      allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
      etc. However, if this mapping process fails, no cleanup is performed,
      leading to memory leaks. To fix this issue, invoke the cleanup before
      returning the error.
      Acked-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      ae78ca3c
    • Rafael J. Wysocki's avatar
      nvme-pci: Allow PCI bus-level PM to be used if ASPM is disabled · 4eaefe8c
      Rafael J. Wysocki authored
      One of the modifications made by commit d916b1be ("nvme-pci: use
      host managed power state for suspend") was adding a pci_save_state()
      call to nvme_suspend() so as to instruct the PCI bus type to leave
      devices handled by the nvme driver in D0 during suspend-to-idle.
      That was done with the assumption that ASPM would transition the
      device's PCIe link into a low-power state when the device became
      inactive.  However, if ASPM is disabled for the device, its PCIe
      link will stay in L0 and in that case commit d916b1be is likely
      to cause the energy used by the system while suspended to increase.
      
      Namely, if the device in question works in accordance with the PCIe
      specification, putting it into D3hot causes its PCIe link to go to
      L1 or L2/L3 Ready, which is lower-power than L0.  Since the energy
      used by the system while suspended depends on the state of its PCIe
      link (as a general rule, the lower-power the state of the link, the
      less energy the system will use), putting the device into D3hot
      during suspend-to-idle should be more energy-efficient that leaving
      it in D0 with disabled ASPM.
      
      For this reason, avoid leaving NVMe devices with disabled ASPM in D0
      during suspend-to-idle.  Instead, shut them down entirely and let
      the PCI bus type put them into D3.
      
      Fixes: d916b1be ("nvme-pci: use host managed power state for suspend")
      Link: https://lore.kernel.org/linux-pm/2763495.NmdaWeg79L@kreacher/T/#t
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarKeith Busch <keith.busch@intel.com>
      4eaefe8c
    • Rafael J. Wysocki's avatar
      PCI/ASPM: Add pcie_aspm_enabled() · accd2dd7
      Rafael J. Wysocki authored
      
      
      Add a function checking whether or not PCIe ASPM has been enabled for
      a given device.
      
      It will be used by the NVMe driver to decide how to handle the
      device during system suspend.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarKeith Busch <keith.busch@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      accd2dd7
    • Benjamin Herrenschmidt's avatar
      usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt · 4a56a478
      Benjamin Herrenschmidt authored
      
      
      If fsg_disable() and fsg_set_alt() are called too closely to each
      other (for example due to a quick reset/reconnect), what can happen
      is that fsg_set_alt sets common->new_fsg from an interrupt while
      handle_exception is trying to process the config change caused by
      fsg_disable():
      
      	fsg_disable()
      	...
      	handle_exception()
      		sets state back to FSG_STATE_NORMAL
      		hasn't yet called do_set_interface()
      		or is inside it.
      
       ---> interrupt
      	fsg_set_alt
      		sets common->new_fsg
      		queues a new FSG_STATE_CONFIG_CHANGE
       <---
      
      Now, the first handle_exception can "see" the updated
      new_fsg, treats it as if it was a fsg_set_alt() response,
      call usb_composite_setup_continue() etc...
      
      But then, the thread sees the second FSG_STATE_CONFIG_CHANGE,
      and goes back down the same path, wipes and reattaches a now
      active fsg, and .. calls usb_composite_setup_continue() which
      at this point is wrong.
      
      Not only we get a backtrace, but I suspect the second set_interface
      wrecks some state causing the host to get upset in my case.
      
      This fixes it by replacing "new_fsg" by a "state argument" (same
      principle) which is set in the same lock section as the state
      update, and retrieved similarly.
      
      That way, there is never any discrepancy between the dequeued
      state and the observed value of it. We keep the ability to have
      the latest reconfig operation take precedence, but we guarantee
      that once "dequeued" the argument (new_fsg) will not be clobbered
      by any new event.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      4a56a478
    • Benjamin Herrenschmidt's avatar
      usb: gadget: composite: Clear "suspended" on reset/disconnect · 602fda17
      Benjamin Herrenschmidt authored
      
      
      In some cases, one can get out of suspend with a reset or
      a disconnect followed by a reconnect. Previously we would
      leave a stale suspended flag set.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      602fda17
    • Yoshihiro Shimoda's avatar
      usb: gadget: udc: renesas_usb3: Fix sysfs interface of "role" · 5dac665c
      Yoshihiro Shimoda authored
      Since the role_store() uses strncmp(), it's possible to refer
      out-of-memory if the sysfs data size is smaller than strlen("host").
      This patch fixes it by using sysfs_streq() instead of strncmp().
      
      Fixes: cc995c9e
      
       ("usb: gadget: udc: renesas_usb3: add support for usb role swap")
      Cc: <stable@vger.kernel.org> # v4.12+
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      5dac665c
  6. 10 Aug, 2019 9 commits
    • Christoph Hellwig's avatar
      dma-mapping: fix page attributes for dma_mmap_* · 33dcb37c
      Christoph Hellwig authored
      All the way back to introducing dma_common_mmap we've defaulted to mark
      the pages as uncached.  But this is wrong for DMA coherent devices.
      Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment as that
      flag is only treated special on the alloc side for non-coherent devices.
      
      Introduce a new dma_pgprot helper that deals with the check for coherent
      devices so that only the remapping cases ever reach arch_dma_mmap_pgprot
      and we thus ensure no aliasing of page attributes happens, which makes
      the powerpc version of arch_dma_mmap_pgprot obsolete and simplifies the
      remaining ones.
      
      Note that this means arch_dma_mmap_pgprot is a bit misnamed now, but
      we'll phase it out soon.
      
      Fixes: 64ccc9c0
      
       ("common: dma-mapping: add support for generic dma_mmap_* calls")
      Reported-by: default avatarShawn Anastasio <shawn@anastas.io>
      Reported-by: default avatarGavin Li <git@thegavinli.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: Catalin Marinas <catalin.marinas@arm.com> # arm64
      33dcb37c
    • Viresh Kumar's avatar
      cpufreq: dev_pm_qos_update_request() can return 1 on success · e61a4125
      Viresh Kumar authored
      dev_pm_qos_update_request() can return 1 on success, so don't treat
      it as an error.
      
      Fixes: 18c49926
      
       ("cpufreq: Add QoS requests for userspace constraints")
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e61a4125
    • Gustavo A. R. Silva's avatar
      scsi: fas216: Mark expected switch fall-throughs · fccf01b6
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      Fix the following warnings (Building: rpc_defconfig arm):
      
      drivers/scsi/arm/fas216.c: In function ‘fas216_disconnect_intr’:
      drivers/scsi/arm/fas216.c:913:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (fas216_get_last_msg(info, info->scsi.msgin_fifo) == ABORT) {
            ^
      drivers/scsi/arm/fas216.c:919:2: note: here
        default:    /* huh?     */
        ^~~~~~~
      drivers/scsi/arm/fas216.c: In function ‘fas216_kick’:
      drivers/scsi/arm/fas216.c:1959:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
         fas216_allocate_tag(info, SCpnt);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/scsi/arm/fas216.c:1960:2: note: here
        case TYPE_OTHER:
        ^~~~
      drivers/scsi/arm/fas216.c: In function ‘fas216_busservice_intr’:
      drivers/scsi/arm/fas216.c:1413:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
         fas216_stoptransfer(info);
         ^~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/scsi/arm/fas216.c:1414:2: note: here
        case STATE(STAT_STATUS, PHASE_SELSTEPS):/* Sel w/ steps -> Status       */
        ^~~~
      drivers/scsi/arm/fas216.c:1424:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
         fas216_stoptransfer(info);
         ^~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/scsi/arm/fas216.c:1425:2: note: here
        case STATE(STAT_MESGIN, PHASE_COMMAND): /* Command -> Message In */
        ^~~~
      drivers/scsi/arm/fas216.c: In function ‘fas216_funcdone_intr’:
      drivers/scsi/arm/fas216.c:1573:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if ((stat & STAT_BUSMASK) == STAT_MESGIN) {
            ^
      drivers/scsi/arm/fas216.c:1579:2: note: here
        default:
        ^~~~~~~
      drivers/scsi/arm/fas216.c: In function ‘fas216_handlesync’:
      drivers/scsi/arm/fas216.c:605:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
         info->scsi.phase = PHASE_MSGOUT_EXPECT;
         ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
      drivers/scsi/arm/fas216.c:607:2: note: here
        case async:
        ^~~~
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      fccf01b6
    • Gustavo A. R. Silva's avatar
      pcmcia: db1xxx_ss: Mark expected switch fall-throughs · 5f163f33
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warnings (Building: db1xxx_defconfig mips):
      
      drivers/pcmcia/db1xxx_ss.c:257:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/pcmcia/db1xxx_ss.c:269:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      5f163f33
    • Gustavo A. R. Silva's avatar
      video: fbdev: omapfb_main: Mark expected switch fall-throughs · 70a2783c
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warning (Building: omap1_defconfig arm):
      
      drivers/watchdog/wdt285.c:170:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/watchdog/ar7_wdt.c:237:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:449:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:1549:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:1547:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:1545:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:1543:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:1540:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:1538:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      drivers/video/fbdev/omap/omapfb_main.c:1535:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      70a2783c
    • Gustavo A. R. Silva's avatar
      watchdog: riowd: Mark expected switch fall-through · 40ad2de3
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warnings (Building: sparc64):
      
      drivers/watchdog/riowd.c: In function ‘riowd_ioctl’:
      drivers/watchdog/riowd.c:136:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
         riowd_writereg(p, riowd_timeout, WDTO_INDEX);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/watchdog/riowd.c:139:2: note: here
        case WDIOC_GETTIMEOUT:
        ^~~~
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      40ad2de3
    • Gustavo A. R. Silva's avatar
      s390/net: Mark expected switch fall-throughs · 7b733151
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warnings (Building: s390):
      
      drivers/s390/net/ctcm_fsms.c: In function ‘ctcmpc_chx_attnbusy’:
      drivers/s390/net/ctcm_fsms.c:1703:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (grp->changed_side == 1) {
            ^
      drivers/s390/net/ctcm_fsms.c:1707:2: note: here
        case MPCG_STATE_XID0IOWAIX:
        ^~~~
      
      drivers/s390/net/ctcm_mpc.c: In function ‘ctc_mpc_alloc_channel’:
      drivers/s390/net/ctcm_mpc.c:358:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (callback)
            ^
      drivers/s390/net/ctcm_mpc.c:360:2: note: here
        case MPCG_STATE_XID0IOWAIT:
        ^~~~
      
      drivers/s390/net/ctcm_mpc.c: In function ‘mpc_action_timeout’:
      drivers/s390/net/ctcm_mpc.c:1469:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if ((fsm_getstate(rch->fsm) == CH_XID0_PENDING) &&
            ^
      drivers/s390/net/ctcm_mpc.c:1472:2: note: here
        default:
        ^~~~~~~
      drivers/s390/net/ctcm_mpc.c: In function ‘mpc_send_qllc_discontact’:
      drivers/s390/net/ctcm_mpc.c:2087:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (grp->estconnfunc) {
            ^
      drivers/s390/net/ctcm_mpc.c:2092:2: note: here
        case MPCG_STATE_FLOWC:
        ^~~~
      
      drivers/s390/net/qeth_l2_main.c: In function ‘qeth_l2_process_inbound_buffer’:
      drivers/s390/net/qeth_l2_main.c:328:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
          if (IS_OSN(card)) {
             ^
      drivers/s390/net/qeth_l2_main.c:337:3: note: here
         default:
         ^~~~~~~
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      7b733151
    • Gustavo A. R. Silva's avatar
      crypto: ux500/crypt: Mark expected switch fall-throughs · 3d86c7ad
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warning (Building: arm):
      
      drivers/crypto/ux500/cryp/cryp.c: In function ‘cryp_save_device_context’:
      drivers/crypto/ux500/cryp/cryp.c:316:16: warning: this statement may fall through [-Wimplicit-fallthrough=]
         ctx->key_4_r = readl_relaxed(&src_reg->key_4_r);
      drivers/crypto/ux500/cryp/cryp.c:318:2: note: here
        case CRYP_KEY_SIZE_192:
        ^~~~
      drivers/crypto/ux500/cryp/cryp.c:320:16: warning: this statement may fall through [-Wimplicit-fallthrough=]
         ctx->key_3_r = readl_relaxed(&src_reg->key_3_r);
      drivers/crypto/ux500/cryp/cryp.c:322:2: note: here
        case CRYP_KEY_SIZE_128:
        ^~~~
      drivers/crypto/ux500/cryp/cryp.c:324:16: warning: this statement may fall through [-Wimplicit-fallthrough=]
         ctx->key_2_r = readl_relaxed(&src_reg->key_2_r);
      drivers/crypto/ux500/cryp/cryp.c:326:2: note: here
        default:
        ^~~~~~~
      In file included from ./include/linux/io.h:13:0,
                       from drivers/crypto/ux500/cryp/cryp_p.h:14,
                       from drivers/crypto/ux500/cryp/cryp.c:15:
      drivers/crypto/ux500/cryp/cryp.c: In function ‘cryp_restore_device_context’:
      ./arch/arm/include/asm/io.h:92:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
       #define __raw_writel __raw_writel
                            ^
      ./arch/arm/include/asm/io.h:299:29: note: in expansion of macro ‘__raw_writel’
       #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c)
                                   ^~~~~~~~~~~~
      drivers/crypto/ux500/cryp/cryp.c:363:3: note: in expansion of macro ‘writel_relaxed’
         writel_relaxed(ctx->key_4_r, &reg->key_4_r);
         ^~~~~~~~~~~~~~
      drivers/crypto/ux500/cryp/cryp.c:365:2: note: here
        case CRYP_KEY_SIZE_192:
        ^~~~
      In file included from ./include/linux/io.h:13:0,
                       from drivers/crypto/ux500/cryp/cryp_p.h:14,
                       from drivers/crypto/ux500/cryp/cryp.c:15:
      ./arch/arm/include/asm/io.h:92:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
       #define __raw_writel __raw_writel
                            ^
      ./arch/arm/include/asm/io.h:299:29: note: in expansion of macro ‘__raw_writel’
       #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c)
                                   ^~~~~~~~~~~~
      drivers/crypto/ux500/cryp/cryp.c:367:3: note: in expansion of macro ‘writel_relaxed’
         writel_relaxed(ctx->key_3_r, &reg->key_3_r);
         ^~~~~~~~~~~~~~
      drivers/crypto/ux500/cryp/cryp.c:369:2: note: here
        case CRYP_KEY_SIZE_128:
        ^~~~
      In file included from ./include/linux/io.h:13:0,
                       from drivers/crypto/ux500/cryp/cryp_p.h:14,
                       from drivers/crypto/ux500/cryp/cryp.c:15:
      ./arch/arm/include/asm/io.h:92:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
       #define __raw_writel __raw_writel
                            ^
      ./arch/arm/include/asm/io.h:299:29: note: in expansion of macro ‘__raw_writel’
       #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c)
                                   ^~~~~~~~~~~~
      drivers/crypto/ux500/cryp/cryp.c:371:3: note: in expansion of macro ‘writel_relaxed’
         writel_relaxed(ctx->key_2_r, &reg->key_2_r);
         ^~~~~~~~~~~~~~
      drivers/crypto/ux500/cryp/cryp.c:373:2: note: here
        default:
        ^~~~~~~
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      3d86c7ad
    • Gustavo A. R. Silva's avatar
      watchdog: wdt977: Mark expected switch fall-through · d51c6163
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warning (Building: arm):
      
      drivers/watchdog/wdt977.c: In function ‘wdt977_ioctl’:
        LD [M]  drivers/media/platform/vicodec/vicodec.o
      drivers/watchdog/wdt977.c:400:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
         wdt977_keepalive();
         ^~~~~~~~~~~~~~~~~~
      drivers/watchdog/wdt977.c:403:2: note: here
        case WDIOC_GETTIMEOUT:
        ^~~~
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      d51c6163