commit 4b333b9c99aec82a0ef41f23eb4cd2e3b3e46026
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat May 4 08:49:10 2019 +0200

    Linux 4.9.173

commit 4f97abd571ec3d56c50a2edfe0932059f4549afa
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Wed Apr 3 12:36:21 2019 -0600

    vfio/type1: Limit DMA mappings per container
    
    commit 492855939bdb59c6f947b0b5b44af9ad82b7e38c upstream.
    
    Memory backed DMA mappings are accounted against a user's locked
    memory limit, including multiple mappings of the same memory.  This
    accounting bounds the number of such mappings that a user can create.
    However, DMA mappings that are not backed by memory, such as DMA
    mappings of device MMIO via mmaps, do not make use of page pinning
    and therefore do not count against the user's locked memory limit.
    These mappings still consume memory, but the memory is not well
    associated to the process for the purpose of oom killing a task.
    
    To add bounding on this use case, we introduce a limit to the total
    number of concurrent DMA mappings that a user is allowed to create.
    This limit is exposed as a tunable module option where the default
    value of 64K is expected to be well in excess of any reasonable use
    case (a large virtual machine configuration would typically only make
    use of tens of concurrent mappings).
    
    This fixes CVE-2019-3882.
    
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Tested-by: Eric Auger <eric.auger@redhat.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    [groeck: Adjust for missing upstream commit]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b491c6f370eaac686161a0cb5cefc93a875dafed
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Sat Mar 9 00:04:11 2019 -0600

    leds: pca9532: fix a potential NULL pointer dereference
    
    [ Upstream commit 0aab8e4df4702b31314a27ec4b0631dfad0fae0a ]
    
    In case of_match_device cannot find a match, return -EINVAL to avoid
    NULL pointer dereference.
    
    Fixes: fa4191a609f2 ("leds: pca9532: Add device tree support")
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 13103fc1d59a2f8758882f0a29df853ba6d22bf0
Author: Changbin Du <changbin.du@gmail.com>
Date:   Mon Mar 25 15:16:47 2019 +0000

    kconfig/[mn]conf: handle backspace (^H) key
    
    [ Upstream commit 9c38f1f044080392603c497ecca4d7d09876ff99 ]
    
    Backspace is not working on some terminal emulators which do not send the
    key code defined by terminfo. Terminals either send '^H' (8) or '^?' (127).
    But currently only '^?' is handled. Let's also handle '^H' for those
    terminals.
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 9b972025208dd985770b972dd6ed63cb1a4b118d
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Mar 28 14:13:47 2019 +0100

    gpio: of: Fix of_gpiochip_add() error path
    
    [ Upstream commit f7299d441a4da8a5088e651ea55023525a793a13 ]
    
    If the call to of_gpiochip_scan_gpios() in of_gpiochip_add() fails, no
    error handling is performed.  This lead to the need of callers to call
    of_gpiochip_remove() on failure, which causes "BAD of_node_put() on ..."
    if the failure happened before the call to of_node_get().
    
    Fix this by adding proper error handling.
    
    Note that calling gpiochip_remove_pin_ranges() multiple times causes no
    harm: subsequent calls are a no-op.
    
    Fixes: dfbd379ba9b7431e ("gpio: of: Return error if gpio hog configuration failed")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit c919272598291545c9d6eed5fc6b628e0c4deaf0
Author: raymond pang <raymondpangxd@gmail.com>
Date:   Thu Mar 28 12:19:25 2019 +0000

    libata: fix using DMA buffers on stack
    
    [ Upstream commit dd08a8d9a66de4b54575c294a92630299f7e0fe7 ]
    
    When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for
    a stack virtual address. Stack DMA buffers must be avoided.
    
    Signed-off-by: raymond pang <raymondpangxd@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 2807acfea7e6991ec560c34719884e8b43c01843
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Tue Mar 26 14:37:00 2019 +0100

    scsi: zfcp: reduce flood of fcrscn1 trace records on multi-element RSCN
    
    [ Upstream commit c8206579175c34a2546de8a74262456278a7795a ]
    
    If an incoming ELS of type RSCN contains more than one element, zfcp
    suboptimally causes repeated erp trigger NOP trace records for each
    previously failed port. These could be ports that went away.  It loops over
    each RSCN element, and for each of those in an inner loop over all
    zfcp_ports.
    
    The trigger to recover failed ports should be just the reception of some
    RSCN, no matter how many elements it has. So we can loop over failed ports
    separately, and only then loop over each RSCN element to handle the
    non-failed ports.
    
    The call chain was:
    
      zfcp_fc_incoming_rscn
        for (i = 1; i < no_entries; i++)
          _zfcp_fc_incoming_rscn
            list_for_each_entry(port, &adapter->port_list, list)
              if (masked port->d_id match) zfcp_fc_test_link
              if (!port->d_id) zfcp_erp_port_reopen "fcrscn1"   <===
    
    In order the reduce the "flooding" of the REC trace area in such cases, we
    factor out handling the failed ports to be outside of the entries loop:
    
      zfcp_fc_incoming_rscn
        if (no_entries > 1)                                     <===
          list_for_each_entry(port, &adapter->port_list, list)  <===
            if (!port->d_id) zfcp_erp_port_reopen "fcrscn1"     <===
        for (i = 1; i < no_entries; i++)
          _zfcp_fc_incoming_rscn
            list_for_each_entry(port, &adapter->port_list, list)
              if (masked port->d_id match) zfcp_fc_test_link
    
    Abbreviated example trace records before this code change:
    
    Tag            : fcrscn1
    WWPN           : 0x500507630310d327
    ERP want       : 0x02
    ERP need       : 0x02
    
    Tag            : fcrscn1
    WWPN           : 0x500507630310d327
    ERP want       : 0x02
    ERP need       : 0x00                 NOP => superfluous trace record
    
    The last trace entry repeats if there are more than 2 RSCN elements.
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Reviewed-by: Jens Remus <jremus@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 46b53c29f05611ef6960067a355910d34c043df1
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Tue Mar 26 01:38:58 2019 +0000

    ceph: fix use-after-free on symlink traversal
    
    [ Upstream commit daf5cc27eed99afdea8d96e71b89ba41f5406ef6 ]
    
    free the symlink body after the same RCU delay we have for freeing the
    struct inode itself, so that traversal during RCU pathwalk wouldn't step
    into freed memory.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 8293a6241b25a8939cef5cf08288b4f1aac681a0
Author: Mukesh Ojha <mojha@codeaurora.org>
Date:   Tue Mar 26 13:42:22 2019 +0530

    usb: u132-hcd: fix resource leak
    
    [ Upstream commit f276e002793cdb820862e8ea8f76769d56bba575 ]
    
    if platform_driver_register fails, cleanup the allocated resource
    gracefully.
    
    Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit a3d1c9bc1416500bc6d7105de3d28a91f2f99fee
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Thu Mar 14 01:30:59 2019 -0500

    scsi: qla4xxx: fix a potential NULL pointer dereference
    
    [ Upstream commit fba1bdd2a9a93f3e2181ec1936a3c2f6b37e7ed6 ]
    
    In case iscsi_lookup_endpoint fails, the fix returns -EINVAL to avoid NULL
    pointer dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Acked-by: Manish Rangankar <mrangankar@marvell.com>
    Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 9842f4cea9f25eb4fe3e9fbaf2be79b43c926635
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Fri Mar 22 11:04:09 2019 +0800

    net: ethernet: ti: fix possible object reference leak
    
    [ Upstream commit 75eac7b5f68b0a0671e795ac636457ee27cc11d8 ]
    
    The call to of_get_child_by_name returns a node pointer with refcount
    incremented thus it must be explicitly decremented after the last
    usage.
    
    Detected by coccinelle with the following warnings:
    ./drivers/net/ethernet/ti/netcp_ethss.c:3661:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function.
    ./drivers/net/ethernet/ti/netcp_ethss.c:3665:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function.
    
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Cc: Wingman Kwok <w-kwok2@ti.com>
    Cc: Murali Karicheri <m-karicheri2@ti.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit a6989d3df8b432a9af71f1e9dd43251256279dc1
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Fri Mar 22 11:04:08 2019 +0800

    net: ibm: fix possible object reference leak
    
    [ Upstream commit be693df3cf9dd113ff1d2c0d8150199efdba37f6 ]
    
    The call to ehea_get_eth_dn returns a node pointer with refcount
    incremented thus it must be explicitly decremented after the last
    usage.
    
    Detected by coccinelle with the following warnings:
    ./drivers/net/ethernet/ibm/ehea/ehea_main.c:3163:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3154, but without a corresponding object release within this function.
    
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Cc: Douglas Miller <dougmill@linux.ibm.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 4cfa26b870faf322bb4ceab4eb8bcd630f75f9f0
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Fri Mar 22 11:04:07 2019 +0800

    net: xilinx: fix possible object reference leak
    
    [ Upstream commit fa3a419d2f674b431d38748cb58fb7da17ee8949 ]
    
    The call to of_parse_phandle returns a node pointer with refcount
    incremented thus it must be explicitly decremented after the last
    usage.
    
    Detected by coccinelle with the following warnings:
    ./drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1624:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1569, but without a corresponding object release within this function.
    
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    Cc: Anirudha Sarangi <anirudh@xilinx.com>
    Cc: John Linn <John.Linn@xilinx.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: netdev@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 986fa92bc3a0a0aa9e5516a525e689230d81b0c3
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Mar 21 17:57:56 2019 -0400

    NFS: Fix a typo in nfs_init_timeout_values()
    
    [ Upstream commit 5a698243930c441afccec04e4d5dc8febfd2b775 ]
    
    Specifying a retrans=0 mount parameter to a NFS/TCP mount, is
    inadvertently causing the NFS client to rewrite any specified
    timeout parameter to the default of 60 seconds.
    
    Fixes: a956beda19a6 ("NFS: Allow the mount option retrans=0")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 63bbfd0631c9745b9d855caa6630f0c7c89e538e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Mar 21 09:26:38 2019 +0300

    staging: rtl8712: uninitialized memory in read_bbreg_hdl()
    
    [ Upstream commit 22c971db7dd4b0ad8dd88e99c407f7a1f4231a2e ]
    
    Colin King reported a bug in read_bbreg_hdl():
    
            memcpy(pcmd->rsp, (u8 *)&val, pcmd->rspsz);
    
    The problem is that "val" is uninitialized.
    
    This code is obviously not useful, but so far as I can tell
    "pcmd->cmdcode" is never GEN_CMD_CODE(_Read_BBREG) so it's not harmful
    either.  For now the easiest fix is to just call r8712_free_cmd_obj()
    and return.
    
    Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit a3c43491f7dbebfd3e4d2223faf8363ccc5c08cd
Author: Lukas Wunner <lukas@wunner.de>
Date:   Wed Mar 20 15:02:00 2019 +0100

    net: ks8851: Set initial carrier state to down
    
    [ Upstream commit 9624bafa5f6418b9ca5b3f66d1f6a6a2e8bf6d4c ]
    
    The ks8851 chip's initial carrier state is down. A Link Change Interrupt
    is signaled once interrupts are enabled if the carrier is up.
    
    The ks8851 driver has it backwards by assuming that the initial carrier
    state is up. The state is therefore misrepresented if the interface is
    opened with no cable attached. Fix it.
    
    The Link Change interrupt is sometimes not signaled unless the P1MBSR
    register (which contains the Link Status bit) is read on ->ndo_open().
    This might be a hardware erratum. Read the register by calling
    mii_check_link(), which has the desirable side effect of setting the
    carrier state to down if the cable was detached while the interface was
    closed.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: Frank Pavlic <f.pavlic@kunbus.de>
    Cc: Ben Dooks <ben.dooks@codethink.co.uk>
    Cc: Tristram Ha <Tristram.Ha@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit d138939d4a7d80f3b15d2c2555553f163620d389
Author: Lukas Wunner <lukas@wunner.de>
Date:   Wed Mar 20 15:02:00 2019 +0100

    net: ks8851: Delay requesting IRQ until opened
    
    [ Upstream commit d268f31552794abf5b6aa5af31021643411f25f5 ]
    
    The ks8851 driver currently requests the IRQ before registering the
    net_device.  Because the net_device name is used as IRQ name and is
    still "eth%d" when the IRQ is requested, it's impossibe to tell IRQs
    apart if multiple ks8851 chips are present.  Most other drivers delay
    requesting the IRQ until the net_device is opened.  Do the same.
    
    The driver doesn't enable interrupts on the chip before opening the
    net_device and disables them when closing it, so there doesn't seem to
    be a need to request the IRQ already on probe.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: Frank Pavlic <f.pavlic@kunbus.de>
    Cc: Ben Dooks <ben.dooks@codethink.co.uk>
    Cc: Tristram Ha <Tristram.Ha@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 6f5cfdeb089d673beb52a1ac38fd99ca43840ae4
Author: Lukas Wunner <lukas@wunner.de>
Date:   Wed Mar 20 15:02:00 2019 +0100

    net: ks8851: Reassert reset pin if chip ID check fails
    
    [ Upstream commit 761cfa979a0c177d6c2d93ef5585cd79ae49a7d5 ]
    
    Commit 73fdeb82e963 ("net: ks8851: Add optional vdd_io regulator and
    reset gpio") amended the ks8851 driver to briefly assert the chip's
    reset pin on probe. It also amended the probe routine's error path to
    reassert the reset pin if a subsequent initialization step fails.
    
    However the commit misplaced reassertion of the reset pin in the error
    path such that it is not performed if the check of the Chip ID and
    Enable Register (CIDER) fails. The error path is therefore slightly
    asymmetrical to the probe routine's body. Fix it.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: Frank Pavlic <f.pavlic@kunbus.de>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
    Cc: Nishanth Menon <nm@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 3098a8b56f1391a23b489d5b93994eb0f380459a
Author: Lukas Wunner <lukas@wunner.de>
Date:   Wed Mar 20 15:02:00 2019 +0100

    net: ks8851: Dequeue RX packets explicitly
    
    [ Upstream commit 536d3680fd2dab5c39857d62a3e084198fc74ff9 ]
    
    The ks8851 driver lets the chip auto-dequeue received packets once they
    have been read in full. It achieves that by setting the ADRFE flag in
    the RXQCR register ("Auto-Dequeue RXQ Frame Enable").
    
    However if allocation of a packet's socket buffer or retrieval of the
    packet over the SPI bus fails, the packet will not have been read in
    full and is not auto-dequeued. Such partial retrieval of a packet
    confuses the chip's RX queue management:  On the next RX interrupt,
    the first packet read from the queue will be the one left there
    previously and this one can be retrieved without issues. But for any
    newly received packets, the frame header status and byte count registers
    (RXFHSR and RXFHBCR) contain bogus values, preventing their retrieval.
    
    The chip allows explicitly dequeueing a packet from the RX queue by
    setting the RRXEF flag in the RXQCR register ("Release RX Error Frame").
    This could be used to dequeue the packet in case of an error, but if
    that error is a failed SPI transfer, it is unknown if the packet was
    transferred in full and was auto-dequeued or if it was only transferred
    in part and requires an explicit dequeue. The safest approach is thus
    to always dequeue packets explicitly and forgo auto-dequeueing.
    
    Without this change, I've witnessed packet retrieval break completely
    when an SPI DMA transfer fails, requiring a chip reset. Explicit
    dequeueing magically fixes this and makes packet retrieval absolutely
    robust for me.
    
    The chip's documentation suggests auto-dequeuing and uses the RRXEF
    flag only to dequeue error frames which the driver doesn't want to
    retrieve. But that seems to be a fair-weather approach.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: Frank Pavlic <f.pavlic@kunbus.de>
    Cc: Ben Dooks <ben.dooks@codethink.co.uk>
    Cc: Tristram Ha <Tristram.Ha@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 63aa211ce24f5a8cb5d4ca176378779bb9fee8cb
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Mon Mar 4 11:49:40 2019 +0100

    ARM: dts: pfla02: increase phy reset duration
    
    [ Upstream commit 032f85c9360fb1a08385c584c2c4ed114b33c260 ]
    
    Increase the reset duration to ensure correct phy functionality. The
    reset duration is taken from barebox commit 52fdd510de ("ARM: dts:
    pfla02: use long enough reset for ethernet phy"):
    
      Use a longer reset time for ethernet phy Micrel KSZ9031RNX. Otherwise a
      small percentage of modules have 'transmission timeouts' errors like
    
      barebox@Phytec phyFLEX-i.MX6 Quad Carrier-Board:/ ifup eth0
      warning: No MAC address set. Using random address 7e:94:4d:02:f8:f3
      eth0: 1000Mbps full duplex link detected
      eth0: transmission timeout
      T eth0: transmission timeout
      T eth0: transmission timeout
      T eth0: transmission timeout
      T eth0: transmission timeout
    
    Cc: Stefan Christ <s.christ@phytec.de>
    Cc: Christian Hemp <c.hemp@phytec.de>
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Fixes: 3180f956668e ("ARM: dts: Phytec imx6q pfla02 and pbab01 support")
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 3cd83b5927dd8d4c8c87130a8ff362cb1f628419
Author: Guido Kiener <guido@kiener-muenchen.de>
Date:   Mon Mar 18 09:18:34 2019 +0100

    usb: gadget: net2272: Fix net2272_dequeue()
    
    [ Upstream commit 091dacc3cc10979ab0422f0a9f7fcc27eee97e69 ]
    
    Restore the status of ep->stopped in function net2272_dequeue().
    
    When the given request is not found in the endpoint queue
    the function returns -EINVAL without restoring the state of
    ep->stopped. Thus the endpoint keeps blocked and does not transfer
    any data anymore.
    
    This fix is only compile-tested, since we do not have a
    corresponding hardware. An analogous fix was tested in the sibling
    driver. See "usb: gadget: net2280: Fix net2280_dequeue()"
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Guido Kiener <guido.kiener@rohde-schwarz.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 56b961175f49b1bb27d324795719150ff7414bda
Author: Guido Kiener <guido@kiener-muenchen.de>
Date:   Mon Mar 18 09:18:33 2019 +0100

    usb: gadget: net2280: Fix net2280_dequeue()
    
    [ Upstream commit f1d3fba17cd4eeea20397f1324b7b9c69a6a935c ]
    
    When a request must be dequeued with net2280_dequeue() e.g. due
    to a device clear action and the same request is finished by the
    function scan_dma_completions() then the function net2280_dequeue()
    does not find the request in the following search loop and
    returns the error -EINVAL without restoring the status ep->stopped.
    Thus the endpoint keeps blocked and does not receive any data
    anymore.
    This fix restores the status and does not issue an error message.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Guido Kiener <guido.kiener@rohde-schwarz.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit ebb7790426711b3b398d17e6ad75255bf94377ad
Author: Guido Kiener <guido@kiener-muenchen.de>
Date:   Tue Mar 19 19:12:03 2019 +0100

    usb: gadget: net2280: Fix overrun of OUT messages
    
    [ Upstream commit 9d6a54c1430647355a5e23434881b2ca3d192b48 ]
    
    The OUT endpoint normally blocks (NAK) subsequent packets when a
    short packet was received and returns an incomplete queue entry to
    the gadget driver. Thereby the gadget driver can detect a short packet
    when reading queue entries with a length that is not equal to a
    multiple of packet size.
    
    The start_queue() function enables receiving OUT packets regardless of
    the content of the OUT FIFO. This results in a race: With the current
    code, it's possible that the "!ep->is_in && (readl(&ep->regs->ep_stat)
    & BIT(NAK_OUT_PACKETS))" test in start_dma() will fail, then a short
    packet will be received, and then start_queue() will call
    stop_out_naking(). That's what we don't want (OUT naking gets turned
    off while there is data in the FIFO) because then the next driver
    request might receive a mixture of old and new packets.
    
    With the patch, this race can't occur because the FIFO's state is
    tested after we know that OUT naking is already turned on, and OUT
    naking is stopped only when both of the conditions are met.  This
    ensures that all received data is delivered to the gadget driver,
    which can detect a short packet now before new packets are appended
    to the last short packet.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Guido Kiener <guido.kiener@rohde-schwarz.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 21cc1fcf9b379fdf7e07e2dfd917919e8d4ac96f
Author: Petr Å tetiar <ynezz@true.cz>
Date:   Wed Mar 6 17:54:03 2019 +0100

    serial: ar933x_uart: Fix build failure with disabled console
    
    [ Upstream commit 72ff51d8dd262d1fef25baedc2ac35116435be47 ]
    
    Andrey has reported on OpenWrt's bug tracking system[1], that he
    currently can't use ar93xx_uart as pure serial UART without console
    (CONFIG_SERIAL_8250_CONSOLE and CONFIG_SERIAL_AR933X_CONSOLE undefined),
    because compilation ends with following error:
    
     ar933x_uart.c: In function 'ar933x_uart_console_write':
     ar933x_uart.c:550:14: error: 'struct uart_port' has no
                                   member named 'sysrq'
    
    So this patch moves all the code related to console handling behind
    series of CONFIG_SERIAL_AR933X_CONSOLE ifdefs.
    
    1. https://bugs.openwrt.org/index.php?do=details&task_id=2152
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: Andrey Batyiev <batyiev@gmail.com>
    Reported-by: Andrey Batyiev <batyiev@gmail.com>
    Tested-by: Andrey Batyiev <batyiev@gmail.com>
    Signed-off-by: Petr Å tetiar <ynezz@true.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit e88ec72ec4337300ef44e1f8e76aa363fa3f127a
Author: Mao Wenan <maowenan@huawei.com>
Date:   Fri Mar 8 22:08:31 2019 +0800

    sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()
    
    [ Upstream commit ac0cdb3d990108df795b676cd0d0e65ac34b2273 ]
    
    Add the missing uart_unregister_driver() and i2c_del_driver() before return
    from sc16is7xx_init() in the error handling case.
    
    Signed-off-by: Mao Wenan <maowenan@huawei.com>
    Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 1ca3379d9613a4ec261c1e8f7aafa64039147d7b
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed Mar 13 16:33:29 2019 +0800

    netfilter: bridge: set skb transport_header before entering NF_INET_PRE_ROUTING
    
    [ Upstream commit e166e4fdaced850bee3d5ee12a5740258fb30587 ]
    
    Since Commit 21d1196a35f5 ("ipv4: set transport header earlier"),
    skb->transport_header has been always set before entering INET
    netfilter. This patch is to set skb->transport_header for bridge
    before entering INET netfilter by bridge-nf-call-iptables.
    
    It also fixes an issue that sctp_error() couldn't compute a right
    csum due to unset skb->transport_header.
    
    Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code")
    Reported-by: Li Shuang <shuali@redhat.com>
    Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 54fa5832c0e34b734d90576ca48cc01e52942d82
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Mar 12 12:10:59 2019 +0100

    netfilter: nft_set_rbtree: check for inactive element after flag mismatch
    
    [ Upstream commit 05b7639da55f5555b9866a1f4b7e8995232a6323 ]
    
    Otherwise, we hit bogus ENOENT when removing elements.
    
    Fixes: e701001e7cbe ("netfilter: nft_rbtree: allow adjacent intervals with dynamic updates")
    Reported-by: Václav Zindulka <vaclav.zindulka@tlapnet.cz>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit aba0a087a00096c3831b6524852a972df5f5f3d9
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Thu Mar 14 15:31:40 2019 -0500

    qlcnic: Avoid potential NULL pointer dereference
    
    [ Upstream commit 5bf7295fe34a5251b1d241b9736af4697b590670 ]
    
    netdev_alloc_skb can fail and return a NULL pointer which is
    dereferenced without a check. The patch avoids such a scenario.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit aa70f06710411f75a399505c32e2e273164b7577
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Mar 4 12:33:28 2019 +0100

    s390: limit brk randomization to 32MB
    
    [ Upstream commit cd479eccd2e057116d504852814402a1e68ead80 ]
    
    For a 64-bit process the randomization of the program break is quite
    large with 1GB. That is as big as the randomization of the anonymous
    mapping base, for a test case started with '/lib/ld64.so.1 <exec>'
    it can happen that the heap is placed after the stack. To avoid
    this limit the program break randomization to 32MB for 64-bit and
    keep 8MB for 31-bit.
    
    Reported-by: Stefan Liebler <stli@linux.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 9ab5cd3180d4a281bbae0be45b8f7ed4828e2d8a
Author: Helen Koike <helen.koike@collabora.com>
Date:   Mon Mar 4 18:48:37 2019 -0300

    ARM: dts: bcm283x: Fix hdmi hpd gpio pull
    
    [ Upstream commit 544e784188f1dd7c797c70b213385e67d92005b6 ]
    
    Raspberry pi board model B revison 2 have the hot plug detector gpio
    active high (and not low as it was in the dts).
    
    Signed-off-by: Helen Koike <helen.koike@collabora.com>
    Fixes: 49ac67e0c39c ("ARM: bcm2835: Add VC4 to the device tree.")
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 8598e3f6cee0d2a443eb45b66a2a0f9e0d3fa98e
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Mon Feb 12 06:45:32 2018 -0500

    media: vivid: check if the cec_adapter is valid
    
    commit ed356f110403f6acc64dcbbbfdc38662ab9b06c2 upstream.
    
    If CEC is not enabled for the vivid driver, then the adap pointer is NULL
    and 'adap->phys_addr' will fail.
    
    Cc: <stable@vger.kernel.org>      # for v4.12 and up
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    [ Naresh: Fixed rebase conflict ]
    Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa06083d3d3326393238d7f9d3c056c626e6b9d3
Author: Gustavo A. R. Silva <garsilva@embeddedor.com>
Date:   Fri Nov 17 14:02:09 2017 -0600

    usbnet: ipheth: fix potential null pointer dereference in ipheth_carrier_set
    
    commit 61c59355e0154a938b28710dfa6c1d8be2ddcefa upstream.
    
    _dev_ is being dereferenced before it is null checked, hence there
    is a potential null pointer dereference.
    
    Fix this by moving the pointer dereference after _dev_ has been null
    checked.
    
    Addresses-Coverity-ID: 1462020
    Fixes: bb1b40c7cb86 ("usbnet: ipheth: prevent TX queue timeouts when device not ready")
    Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea7d6be58c2e6c1f426b48994bb22b2393c90963
Author: Alexander Kappner <agk@godking.net>
Date:   Mon Nov 13 17:44:20 2017 -0800

    usbnet: ipheth: prevent TX queue timeouts when device not ready
    
    commit bb1b40c7cb863f0800a6410c7dcb86cf3f28d3b1 upstream.
    
    iOS devices require the host to be "trusted" before servicing network
    packets. Establishing trust requires the user to confirm a dialog on the
    iOS device.Until trust is established, the iOS device will silently discard
    network packets from the host. Currently, the ipheth driver does not detect
    whether an iOS device has established trust with the host, and immediately
    sets up the transmit queues.
    
    This causes the following problems:
    
    - Kernel taint due to WARN() in netdev watchdog.
    - Dmesg spam ("TX timeout").
    - Disruption of user space networking activity (dhcpd, etc...) when new
    interface comes up but cannot be used.
    - Unnecessary host and device wakeups and USB traffic
    
    Example dmesg output:
    
    [ 1101.319778] NETDEV WATCHDOG: eth1 (ipheth): transmit queue 0 timed out
    [ 1101.319817] ------------[ cut here ]------------
    [ 1101.319828] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x20f/0x220
    [ 1101.319831] Modules linked in: ipheth usbmon nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) iwlmvm mac80211 iwlwifi btusb btrtl btbcm btintel qmi_wwan bluetooth cfg80211 ecdh_generic thinkpad_acpi rfkill [last unloaded: ipheth]
    [ 1101.319861] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P           O    4.13.12.1 #1
    [ 1101.319864] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W (1.35 ) 11/10/2016
    [ 1101.319867] task: ffffffff81e11500 task.stack: ffffffff81e00000
    [ 1101.319873] RIP: 0010:dev_watchdog+0x20f/0x220
    [ 1101.319876] RSP: 0018:ffff8810a3c03e98 EFLAGS: 00010292
    [ 1101.319880] RAX: 000000000000003a RBX: 0000000000000000 RCX: 0000000000000000
    [ 1101.319883] RDX: ffff8810a3c15c48 RSI: ffffffff81ccbfc2 RDI: 00000000ffffffff
    [ 1101.319886] RBP: ffff880c04ebc41c R08: 0000000000000000 R09: 0000000000000379
    [ 1101.319889] R10: 00000100696589d0 R11: 0000000000000378 R12: ffff880c04ebc000
    [ 1101.319892] R13: 0000000000000000 R14: 0000000000000001 R15: ffff880c2865fc80
    [ 1101.319896] FS:  0000000000000000(0000) GS:ffff8810a3c00000(0000) knlGS:0000000000000000
    [ 1101.319899] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1101.319902] CR2: 00007f3ff24ac000 CR3: 0000000001e0a000 CR4: 00000000003406f0
    [ 1101.319905] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1101.319908] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 1101.319910] Call Trace:
    [ 1101.319914]  <IRQ>
    [ 1101.319921]  ? dev_graft_qdisc+0x70/0x70
    [ 1101.319928]  ? dev_graft_qdisc+0x70/0x70
    [ 1101.319934]  ? call_timer_fn+0x2e/0x170
    [ 1101.319939]  ? dev_graft_qdisc+0x70/0x70
    [ 1101.319944]  ? run_timer_softirq+0x1ea/0x440
    [ 1101.319951]  ? timerqueue_add+0x54/0x80
    [ 1101.319956]  ? enqueue_hrtimer+0x38/0xa0
    [ 1101.319963]  ? __do_softirq+0xed/0x2e7
    [ 1101.319970]  ? irq_exit+0xb4/0xc0
    [ 1101.319976]  ? smp_apic_timer_interrupt+0x39/0x50
    [ 1101.319981]  ? apic_timer_interrupt+0x8c/0xa0
    [ 1101.319983]  </IRQ>
    [ 1101.319992]  ? cpuidle_enter_state+0xfa/0x2a0
    [ 1101.319999]  ? do_idle+0x1a3/0x1f0
    [ 1101.320004]  ? cpu_startup_entry+0x5f/0x70
    [ 1101.320011]  ? start_kernel+0x444/0x44c
    [ 1101.320017]  ? early_idt_handler_array+0x120/0x120
    [ 1101.320023]  ? x86_64_start_kernel+0x145/0x154
    [ 1101.320028]  ? secondary_startup_64+0x9f/0x9f
    [ 1101.320033] Code: 20 04 00 00 eb 9f 4c 89 e7 c6 05 59 44 71 00 01 e8 a7 df fd ff 89 d9 4c 89 e6 48 c7 c7 70 b7 cd 81 48 89 c2 31 c0 e8 97 64 90 ff <0f> ff eb bf 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
    [ 1101.320103] ---[ end trace 0cc4d251e2b57080 ]---
    [ 1101.320110] ipheth 1-5:4.2: ipheth_tx_timeout: TX timeout
    
    The last message "TX timeout" is repeated every 5 seconds until trust is
    established or the device is disconnected, filling up dmesg.
    
    The proposed patch eliminates the problem by, upon connection, keeping the
    TX queue and carrier disabled until a packet is first received from the iOS
    device. This is reflected by the confirmed_pairing variable in the device
    structure. Only after at least one packet has been received from the iOS
    device, the transmit queue and carrier are brought up during the periodic
    device poll in ipheth_carrier_set. Because the iOS device will always send
    a packet immediately upon trust being established, this should not delay
    the interface becoming useable. To prevent failed UBRs in
    ipheth_rcvbulk_callback from perpetually re-enabling the queue if it was
    disabled, a new check is added so only successful transfers re-enable the
    queue, whereas failed transfers only trigger an immediate poll.
    
    This has the added benefit of removing the periodic control requests to the
    iOS device until trust has been established and thus should reduce wakeup
    events on both the host and the iOS device.
    
    Signed-off-by: Alexander Kappner <agk@godking.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [groeck: Fixed context conflict seen because 45611c61dd50 was applied first]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>