1. 05 Apr, 2019 40 commits
    • Akinobu Mita's avatar
      media: mt9m111: set initial frame size other than 0x0 · 7aaa76e8
      Akinobu Mita authored
      [ Upstream commit 29856308 ]
      
      This driver sets initial frame width and height to 0x0, which is invalid.
      So set it to selection rectangle bounds instead.
      
      This is detected by v4l2-compliance detected.
      
      Cc: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
      Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
      Cc: Marco Felsch <m.felsch@pengutronix.de>
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7aaa76e8
    • Tony Jones's avatar
      perf script python: Add trace_context extension module to sys.modules · fd400e96
      Tony Jones authored
      [ Upstream commit cc437642 ]
      
      In Python3, the result of PyModule_Create (called from
      scripts/python/Perf-Trace-Util/Context.c) is not automatically added to
      sys.modules.  See: https://bugs.python.org/issue4592
      
      Below is the observed behavior without the fix:
      
        # ldd /usr/bin/perf | grep -i python
      	libpython3.6m.so.1.0 => /usr/lib64/libpython3.6m.so.1.0 (0x00007f8e1dfb2000)
      
        # perf record /bin/false
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.015 MB perf.data (17 samples) ]
      
        # perf script -g python | cat
        generated Python script: perf-script.py
      
        # perf script -s ./perf-script.py
        Traceback (most recent call last):
          File "./perf-script.py", line 18, in <module>
            from perf_trace_context import *
        ModuleNotFoundError: No module named 'perf_trace_context'
        Error running python script ./perf-script.py
        #
      
      Committer notes:
      
      To build with python3 use:
      
        $ make -C tools/perf PYTHON=python3
      
      Use a non-const variable to pass the 'name' arg to
      PyImport_AppendInittab(), as python2.6 has that as 'char *', which ends
      up trowing this in some environments:
      
         CC       /tmp/build/perf/util/parse-branch-options.o
        util/scripting-engines/trace-event-python.c: In function 'python_start_script':
        util/scripting-engines/trace-event-python.c:1520:2: error: passing argument 1 of 'PyImport_AppendInittab' discards 'const' qualifier from pointer target type [-Werror]
          PyImport_AppendInittab("perf_trace_context", initfunc);
          ^
        In file included from /usr/include/python2.6/Python.h:130:0,
                         from util/scripting-engines/trace-event-python.c:22:
        /usr/include/python2.6/import.h:54:17: note: expected 'char *' but argument is of type 'const char *'
         PyAPI_FUNC(int) PyImport_AppendInittab(char *name, void (*initfunc)(void));
                         ^
        cc1: all warnings being treated as errors
      Signed-off-by: default avatarTony Jones <tonyj@suse.de>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jaroslav Škarvada <jskarvad@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Fixes: 66dfdff0 ("perf tools: Add Python 3 support")
      Link: http://lkml.kernel.org/r/20190124005229.16146-2-tonyj@suse.deSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fd400e96
    • Tony Jones's avatar
      perf script python: Use PyBytes for attr in trace-event-python · d90a375b
      Tony Jones authored
      [ Upstream commit 72e0b15c ]
      
      With Python3.  PyUnicode_FromStringAndSize is unsafe to call on attr and will
      return NULL.  Use _PyBytes_FromStringAndSize (as with raw_buf).
      
      Below is the observed behavior without the fix.  Note it is first necessary
      to apply the prior fix (Add trace_context extension module to sys,modules):
      
        # ldd /usr/bin/perf | grep -i python
                libpython3.6m.so.1.0 => /usr/lib64/libpython3.6m.so.1.0 (0x00007f8e1dfb2000)
      
        # perf record -e raw_syscalls:sys_enter /bin/false
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.018 MB perf.data (21 samples) ]
      
        # perf script -g python | cat
        generated Python script: perf-script.py
      
        # perf script -s ./perf-script.py
        in trace_begin
        Segmentation fault (core dumped)
      Signed-off-by: default avatarTony Jones <tonyj@suse.de>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jaroslav Škarvada <jskarvad@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Fixes: 66dfdff0 ("perf tools: Add Python 3 support")
      Link: http://lkml.kernel.org/r/20190124005229.16146-3-tonyj@suse.deSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d90a375b
    • Jérôme de Bretagne's avatar
      platform/x86: intel-hid: Missing power button release on some Dell models · f94e369f
      Jérôme de Bretagne authored
      [ Upstream commit e97a3456 ]
      
      Power button suspend for some Dell models was added in:
      
      commit 821b8536 ("platform/x86: intel-hid: Power button suspend on Dell Latitude 7275")
      
      by checking against the power button press notification (0xCE) to report
      the power button press event. The corresponding power button release
      notification (0xCF) was caught and ignored to stop it from being reported
      as an "unknown event" in the logs.
      
      The missing button release event is creating issues on Android-x86, as
      reported on the project mailing list for a Dell Latitude 5175 model, since
      the events are expected in down/up pairs.
      
      Report the power button release event to fix this issue.
      
      Link: https://groups.google.com/forum/#!topic/android-x86/aSwZK9Nf9RoTested-by: default avatarTristian Celestin <tristian.celestin@outlook.com>
      Tested-by: default avatarJérôme de Bretagne <jerome.debretagne@gmail.com>
      Signed-off-by: default avatarJérôme de Bretagne <jerome.debretagne@gmail.com>
      Reviewed-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      [dvhart: corrected commit reference format per checkpatch]
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f94e369f
    • Roger Quadros's avatar
      usb: dwc3: gadget: Fix OTG events when gadget driver isn't loaded · 1e55e3f6
      Roger Quadros authored
      [ Upstream commit 169e3b68 ]
      
      On v3.10a in dual-role mode, if port is in device mode
      and gadget driver isn't loaded, the OTG event interrupts don't
      come through.
      
      It seems that if the core is configured to be OTG2.0 only,
      then we can't leave the DCFG.DEVSPD at Super-speed (default)
      if we expect OTG to work properly. It must be set to High-speed.
      
      Fix this issue by configuring DCFG.DEVSPD to the supported
      maximum speed at gadget init. Device tree still needs to provide
      correct supported maximum speed for this to work.
      
      This issue wasn't present on v2.40a but is seen on v3.10a.
      It doesn't cause any side effects on v2.40a.
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1e55e3f6
    • Takashi Sakamoto's avatar
      ALSA: dice: add support for Solid State Logic Duende Classic/Mini · 2b20c29b
      Takashi Sakamoto authored
      [ Upstream commit b2e9e1c8 ]
      
      Duende Classic was produced by Solid State Logic in 2006, as a
      first model of Duende DSP series. The following model, Duende Mini
      was produced in 2008. They are designed to receive isochronous
      packets for PCM frames via IEEE 1394 bus, perform signal processing by
      downloaded program, then transfer isochronous packets for converted
      PCM frames.
      
      These two models includes the same embedded board, consists of several
      ICs below:
       - Texus Instruments Inc, TSB41AB3 for physical layer of IEEE 1394 bus
       - WaveFront semiconductor, DICE II STD ASIC for link/protocol layer
       - Altera MAX 3000A CPLD for programs
       - Analog devices, SHARC ADSP-21363 for signal processing (4 chips)
      
      This commit adds support for the two models to ALSA dice driver. Like
      support for the other devices, packet streaming is just available.
      Userspace applications should be developed if full features became
      available; e.g. program uploader and parameter controller.
      
      $ ./hinawa-config-rom-printer /dev/fw1
      { 'bus-info': { 'adj': False,
                      'bmc': False,
                      'chip_ID': 349771402425,
                      'cmc': True,
                      'cyc_clk_acc': 255,
                      'generation': 1,
                      'imc': True,
                      'isc': True,
                      'link_spd': 2,
                      'max_ROM': 1,
                      'max_rec': 512,
                      'name': '1394',
                      'node_vendor_ID': 20674,
                      'pmc': False},
        'root-directory': [ ['VENDOR', 20674],
                            ['DESCRIPTOR', 'Solid State Logic'],
                            ['MODEL', 112],
                            ['DESCRIPTOR', 'Duende board'],
                            [ 'NODE_CAPABILITIES',
                              { 'addressing': {'64': True, 'fix': True, 'prv': True},
                                'misc': {'int': False, 'ms': False, 'spt': True},
                                'state': { 'atn': False,
                                           'ded': False,
                                           'drq': True,
                                           'elo': False,
                                           'init': False,
                                           'lst': True,
                                           'off': False},
                                'testing': {'bas': False, 'ext': False}}],
                            [ 'UNIT',
                              [ ['SPECIFIER_ID', 20674],
                                ['VERSION', 1],
                                ['MODEL', 112],
                                ['DESCRIPTOR', 'Duende board']]]]}
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2b20c29b
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Enable vblank interrupt during CRC capture · 3abb3d04
      Nicholas Kazlauskas authored
      [ Upstream commit 428da2bd ]
      
      [Why]
      In order to read CRC events when CRC capture is enabled the vblank
      interrput handler needs to be running for the CRTC. The handler is
      enabled while there is an active vblank reference.
      
      When running IGT tests there will often be no active vblank reference
      but the test expects to read a CRC value. This is valid usage (and
      works on i915 since they have a CRC interrupt handler) so the reference
      to the vblank should be grabbed while capture is active.
      
      This issue was found running:
      
      igt@kms_plane_multiple@atomic-pipe-b-tiling-none
      
      The pipe-b is the only one in the initial commit and was not previously
      active so no vblank reference is grabbed. The vblank interrupt is
      not enabled and the test times out.
      
      [How]
      Keep a reference to the vblank as long as CRC capture is enabled.
      If userspace never explicitly disables it then the reference is
      also dropped when removing the CRTC from the context (stream = NULL).
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarHarry Wentland <Harry.Wentland@amd.com>
      Reviewed-by: default avatarSun peng Li <Sunpeng.Li@amd.com>
      Acked-by: default avatarLeo Li <sunpeng.li@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3abb3d04
    • Nathan Fontenot's avatar
      powerpc/pseries: Perform full re-add of CPU for topology update post-migration · 06af7dda
      Nathan Fontenot authored
      [ Upstream commit 81b61324 ]
      
      On pseries systems, performing a partition migration can result in
      altering the nodes a CPU is assigned to on the destination system. For
      exampl, pre-migration on the source system CPUs are in node 1 and 3,
      post-migration on the destination system CPUs are in nodes 2 and 3.
      
      Handling the node change for a CPU can cause corruption in the slab
      cache if we hit a timing where a CPUs node is changed while cache_reap()
      is invoked. The corruption occurs because the slab cache code appears
      to rely on the CPU and slab cache pages being on the same node.
      
      The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
      does not prevent us from hitting this scenario.
      
      Changing the device tree property update notification handler that
      recognizes an affinity change for a CPU to do a full DLPAR remove and
      add of the CPU instead of dynamically changing its node resolves this
      issue.
      Signed-off-by: default avatarNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael W. Bringmann <mwb@linux.vnet.ibm.com>
      Tested-by: default avatarMichael W. Bringmann <mwb@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      06af7dda
    • Manfred Schlaegl's avatar
      tty: increase the default flip buffer limit to 2*640K · 57f03bbd
      Manfred Schlaegl authored
      [ Upstream commit 7ab57b76 ]
      
      We increase the default limit for buffer memory allocation by a factor of
      10 to 640K to prevent data loss when using fast serial interfaces.
      
      For example when using RS485 without flow-control at speeds of 1Mbit/s
      an upwards we've run into problems such as applications being too slow
      to read out this buffer (on embedded devices based on imx53 or imx6).
      
      If you want to write transmitted data to a slow SD card and thus have
      realtime requirements, this limit can become a problem.
      
      That shouldn't be the case and 640K buffers fix such problems for us.
      
      This value is a maximum limit for allocation only. It has no effect
      on systems that currently run fine. When transmission is slow enough
      applications and hardware can keep up and increasing this limit
      doesn't change anything.
      
      It only _allows_ to allocate more than 2*64K in cases we currently fail to
      allocate memory despite having some.
      Signed-off-by: default avatarManfred Schlaegl <manfred.schlaegl@ginzinger.com>
      Signed-off-by: default avatarMartin Kepplinger <martin.kepplinger@ginzinger.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      57f03bbd
    • Chen-Yu Tsai's avatar
      backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state · 2142eba8
      Chen-Yu Tsai authored
      [ Upstream commit cec2b188 ]
      
      gpiod_get_value() gives out a warning if access to the underlying gpiochip
      requires sleeping, which is common for I2C based chips:
      
          WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500 gpiod_get_value+0xd0/0x100
          Modules linked in:
          CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted 4.14.0-rc3-00589-gf32897915d48-dirty #90
          Hardware name: Allwinner sun4i/sun5i Families
          Workqueue: events deferred_probe_work_func
          [<c010ec50>] (unwind_backtrace) from [<c010b784>] (show_stack+0x10/0x14)
          [<c010b784>] (show_stack) from [<c0797224>] (dump_stack+0x88/0x9c)
          [<c0797224>] (dump_stack) from [<c0125b08>] (__warn+0xe8/0x100)
          [<c0125b08>] (__warn) from [<c0125bd0>] (warn_slowpath_null+0x20/0x28)
          [<c0125bd0>] (warn_slowpath_null) from [<c037069c>] (gpiod_get_value+0xd0/0x100)
          [<c037069c>] (gpiod_get_value) from [<c03778d0>] (pwm_backlight_probe+0x238/0x508)
          [<c03778d0>] (pwm_backlight_probe) from [<c0411a2c>] (platform_drv_probe+0x50/0xac)
          [<c0411a2c>] (platform_drv_probe) from [<c0410224>] (driver_probe_device+0x238/0x2e8)
          [<c0410224>] (driver_probe_device) from [<c040e820>] (bus_for_each_drv+0x44/0x94)
          [<c040e820>] (bus_for_each_drv) from [<c040ff0c>] (__device_attach+0xb0/0x114)
          [<c040ff0c>] (__device_attach) from [<c040f4f8>] (bus_probe_device+0x84/0x8c)
          [<c040f4f8>] (bus_probe_device) from [<c040f944>] (deferred_probe_work_func+0x50/0x14c)
          [<c040f944>] (deferred_probe_work_func) from [<c013be84>] (process_one_work+0x1ec/0x414)
          [<c013be84>] (process_one_work) from [<c013ce5c>] (worker_thread+0x2b0/0x5a0)
          [<c013ce5c>] (worker_thread) from [<c0141908>] (kthread+0x14c/0x154)
          [<c0141908>] (kthread) from [<c0107ab0>] (ret_from_fork+0x14/0x24)
      
      This was missed in commit 0c9501f8 ("backlight: pwm_bl: Handle gpio
      that can sleep"). The code was then moved to a separate function in
      commit 7613c922 ("backlight: pwm_bl: Move the checks for initial power
      state to a separate function").
      
      The only usage of gpiod_get_value() is during the probe stage, which is
      safe to sleep in. Switch to gpiod_get_value_cansleep().
      
      Fixes: 0c9501f8 ("backlight: pwm_bl: Handle gpio that can sleep")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Acked-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2142eba8
    • Oleg Nesterov's avatar
      cgroup/pids: turn cgroup_subsys->free() into cgroup_subsys->release() to fix the accounting · d0bc74c5
      Oleg Nesterov authored
      [ Upstream commit 51bee5ab ]
      
      The only user of cgroup_subsys->free() callback is pids_cgrp_subsys which
      needs pids_free() to uncharge the pid.
      
      However, ->free() is called from __put_task_struct()->cgroup_free() and this
      is too late. Even the trivial program which does
      
      	for (;;) {
      		int pid = fork();
      		assert(pid >= 0);
      		if (pid)
      			wait(NULL);
      		else
      			exit(0);
      	}
      
      can run out of limits because release_task()->call_rcu(delayed_put_task_struct)
      implies an RCU gp after the task/pid goes away and before the final put().
      
      Test-case:
      
      	mkdir -p /tmp/CG
      	mount -t cgroup2 none /tmp/CG
      	echo '+pids' > /tmp/CG/cgroup.subtree_control
      
      	mkdir /tmp/CG/PID
      	echo 2 > /tmp/CG/PID/pids.max
      
      	perl -e 'while ($p = fork) { wait; } $p // die "fork failed: $!\n"' &
      	echo $! > /tmp/CG/PID/cgroup.procs
      
      Without this patch the forking process fails soon after migration.
      
      Rename cgroup_subsys->free() to cgroup_subsys->release() and move the callsite
      into the new helper, cgroup_release(), called by release_task() which actually
      frees the pid(s).
      Reported-by: default avatarHerton R. Krzesinski <hkrzesin@redhat.com>
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d0bc74c5
    • Nicolai Stange's avatar
      powerpc/64s: Clear on-stack exception marker upon exception return · b52681e6
      Nicolai Stange authored
      [ Upstream commit eddd0b33 ]
      
      The ppc64 specific implementation of the reliable stacktracer,
      save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
      trace" whenever it finds an exception frame on the stack. Stack frames
      are classified as exception frames if the STACK_FRAME_REGS_MARKER
      magic, as written by exception prologues, is found at a particular
      location.
      
      However, as observed by Joe Lawrence, it is possible in practice that
      non-exception stack frames can alias with prior exception frames and
      thus, that the reliable stacktracer can find a stale
      STACK_FRAME_REGS_MARKER on the stack. It in turn falsely reports an
      unreliable stacktrace and blocks any live patching transition to
      finish. Said condition lasts until the stack frame is
      overwritten/initialized by function call or other means.
      
      In principle, we could mitigate this by making the exception frame
      classification condition in save_stack_trace_tsk_reliable() stronger:
      in addition to testing for STACK_FRAME_REGS_MARKER, we could also take
      into account that for all exceptions executing on the kernel stack
        - their stack frames's backlink pointers always match what is saved
          in their pt_regs instance's ->gpr[1] slot and that
        - their exception frame size equals STACK_INT_FRAME_SIZE, a value
          uncommonly large for non-exception frames.
      
      However, while these are currently true, relying on them would make
      the reliable stacktrace implementation more sensitive towards future
      changes in the exception entry code. Note that false negatives, i.e.
      not detecting exception frames, would silently break the live patching
      consistency model.
      
      Furthermore, certain other places (diagnostic stacktraces, perf, xmon)
      rely on STACK_FRAME_REGS_MARKER as well.
      
      Make the exception exit code clear the on-stack
      STACK_FRAME_REGS_MARKER for those exceptions running on the "normal"
      kernel stack and returning to kernelspace: because the topmost frame
      is ignored by the reliable stack tracer anyway, returns to userspace
      don't need to take care of clearing the marker.
      
      Furthermore, as I don't have the ability to test this on Book 3E or 32
      bits, limit the change to Book 3S and 64 bits.
      
      Fixes: df78d3f6 ("powerpc/livepatch: Implement reliable stack tracing for the consistency model")
      Reported-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Signed-off-by: default avatarNicolai Stange <nstange@suse.de>
      Signed-off-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b52681e6
    • Stanislav Fomichev's avatar
      selftests/bpf: skip verifier tests for unsupported program types · 118d38a3
      Stanislav Fomichev authored
      [ Upstream commit 8184d44c ]
      
      Use recently introduced bpf_probe_prog_type() to skip tests in the
      test_verifier() if bpf_verify_program() fails. The skipped test is
      indicated in the output.
      
      Example:
      
      ...
      679/p bpf_get_stack return R0 within range SKIP (unsupported program
      type 5)
      680/p ld_abs: invalid op 1 OK
      ...
      Summary: 863 PASSED, 165 SKIPPED, 3 FAILED
      Signed-off-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      118d38a3
    • Valdis Kletnieks's avatar
      bpf: fix missing prototype warnings · ae92cf47
      Valdis Kletnieks authored
      [ Upstream commit 116bfa96 ]
      
      Compiling with W=1 generates warnings:
      
        CC      kernel/bpf/core.o
      kernel/bpf/core.c:721:12: warning: no previous prototype for ?bpf_jit_alloc_exec_limit? [-Wmissing-prototypes]
        721 | u64 __weak bpf_jit_alloc_exec_limit(void)
            |            ^~~~~~~~~~~~~~~~~~~~~~~~
      kernel/bpf/core.c:757:14: warning: no previous prototype for ?bpf_jit_alloc_exec? [-Wmissing-prototypes]
        757 | void *__weak bpf_jit_alloc_exec(unsigned long size)
            |              ^~~~~~~~~~~~~~~~~~
      kernel/bpf/core.c:762:13: warning: no previous prototype for ?bpf_jit_free_exec? [-Wmissing-prototypes]
        762 | void __weak bpf_jit_free_exec(void *addr)
            |             ^~~~~~~~~~~~~~~~~
      
      All three are weak functions that archs can override, provide
      proper prototypes for when a new arch provides their own.
      Signed-off-by: default avatarValdis Kletnieks <valdis.kletnieks@vt.edu>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ae92cf47
    • Paolo Valente's avatar
      block, bfq: fix in-service-queue check for queue merging · 06666a19
      Paolo Valente authored
      [ Upstream commit 058fdecc ]
      
      When a new I/O request arrives for a bfq_queue, say Q, bfq checks
      whether that request is close to
      (a) the head request of some other queue waiting to be served, or
      (b) the last request dispatched for the in-service queue (in case Q
      itself is not the in-service queue)
      
      If a queue, say Q2, is found for which the above condition holds, then
      bfq merges Q and Q2, to hopefully get a more sequential I/O in the
      resulting merged queue, and thus a possibly higher throughput.
      
      Case (b) is checked by comparing the new request for Q with the last
      request dispatched, assuming that the latter necessarily belonged to the
      in-service queue. Unfortunately, this assumption is no longer always
      correct, since commit d0edc247 ("block, bfq: inject other-queue I/O
      into seeky idle queues on NCQ flash").
      
      When the assumption does not hold, queues that must not be merged may be
      merged, causing unexpected loss of control on per-queue service
      guarantees.
      
      This commit solves this problem by adding an extra field, which stores
      the actual last request dispatched for the in-service queue, and by
      using this new field to correctly check case (b).
      Signed-off-by: default avatarPaolo Valente <paolo.valente@linaro.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      06666a19
    • Russell King's avatar
      ARM: avoid Cortex-A9 livelock on tight dmb loops · 30d503ba
      Russell King authored
      [ Upstream commit 5388a5b8 ]
      
      machine_crash_nonpanic_core() does this:
      
      	while (1)
      		cpu_relax();
      
      because the kernel has crashed, and we have no known safe way to deal
      with the CPU.  So, we place the CPU into an infinite loop which we
      expect it to never exit - at least not until the system as a whole is
      reset by some method.
      
      In the absence of erratum 754327, this code assembles to:
      
      	b	.
      
      In other words, an infinite loop.  When erratum 754327 is enabled,
      this becomes:
      
      1:	dmb
      	b	1b
      
      It has been observed that on some systems (eg, OMAP4) where, if a
      crash is triggered, the system tries to kexec into the panic kernel,
      but fails after taking the secondary CPU down - placing it into one
      of these loops.  This causes the system to livelock, and the most
      noticable effect is the system stops after issuing:
      
      	Loading crashdump kernel...
      
      to the system console.
      
      The tested as working solution I came up with was to add wfe() to
      these infinite loops thusly:
      
      	while (1) {
      		cpu_relax();
      		wfe();
      	}
      
      which, without 754327 builds to:
      
      1:	wfe
      	b	1b
      
      or with 754327 is enabled:
      
      1:	dmb
      	wfe
      	b	1b
      
      Adding "wfe" does two things depending on the environment we're running
      under:
      - where we're running on bare metal, and the processor implements
        "wfe", it stops us spinning endlessly in a loop where we're never
        going to do any useful work.
      - if we're running in a VM, it allows the CPU to be given back to the
        hypervisor and rescheduled for other purposes (maybe a different VM)
        rather than wasting CPU cycles inside a crashed VM.
      
      However, in light of erratum 794072, Will Deacon wanted to see 10 nops
      as well - which is reasonable to cover the case where we have erratum
      754327 enabled _and_ we have a processor that doesn't implement the
      wfe hint.
      
      So, we now end up with:
      
      1:      wfe
              b       1b
      
      when erratum 754327 is disabled, or:
      
      1:      dmb
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              wfe
              b       1b
      
      when erratum 754327 is enabled.  We also get the dmb + 10 nop
      sequence elsewhere in the kernel, in terminating loops.
      
      This is reasonable - it means we get the workaround for erratum
      794072 when erratum 754327 is enabled, but still relinquish the dead
      processor - either by placing it in a lower power mode when wfe is
      implemented as such or by returning it to the hypervisior, or in the
      case where wfe is a no-op, we use the workaround specified in erratum
      794072 to avoid the problem.
      
      These as two entirely orthogonal problems - the 10 nops addresses
      erratum 794072, and the wfe is an optimisation that makes the system
      more efficient when crashed either in terms of power consumption or
      by allowing the host/other VMs to make use of the CPU.
      
      I don't see any reason not to use kexec() inside a VM - it has the
      potential to provide automated recovery from a failure of the VMs
      kernel with the opportunity for saving a crashdump of the failure.
      A panic() with a reboot timeout won't do that, and reading the
      libvirt documentation, setting on_reboot to "preserve" won't either
      (the documentation states "The preserve action for an on_reboot event
      is treated as a destroy".)  Surely it has to be a good thing to
      avoiding having CPUs spinning inside a VM that is doing no useful
      work.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      30d503ba
    • Vladimir Murzin's avatar
      ARM: 8830/1: NOMMU: Toggle only bits in EXC_RETURN we are really care of · d8945878
      Vladimir Murzin authored
      [ Upstream commit 72cd4064 ]
      
      ARMv8M introduces support for Security extension to M class, among
      other things it affects exception handling, especially, encoding of
      EXC_RETURN.
      
      The new bits have been added:
      
      Bit [6]	Secure or Non-secure stack
      Bit [5]	Default callee register stacking
      Bit [0]	Exception Secure
      
      which conflicts with hard-coded value of EXC_RETURN:
      
      In fact, we only care of few bits:
      
      Bit [3]	 Mode (0 - Handler, 1 - Thread)
      Bit [2]	 Stack pointer selection (0 - Main, 1 - Process)
      
      We can toggle only those bits and left other bits as they were on
      exception entry.
      
      It is basically, what patch does - saves EXC_RETURN when we do
      transition form Thread to Handler mode (it is first svc), so later
      saved value is used instead of EXC_RET_THREADMODE_PROCESSSTACK.
      Signed-off-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d8945878
    • Stanislaw Gruszka's avatar
      mt7601u: bump supported EEPROM version · 66871349
      Stanislaw Gruszka authored
      [ Upstream commit 3bd1505f ]
      
      As reported by Michael eeprom 0d is supported and work with the driver.
      
      Dump of /sys/kernel/debug/ieee80211/phy1/mt7601u/eeprom_param
      with 0d EEPORM looks like this:
      
      RSSI offset: 0 0
      Reference temp: f9
      LNA gain: 8
      Reg channels: 1-14
      Per rate power:
      	 raw:05 bw20:05 bw40:05
      	 raw:05 bw20:05 bw40:05
      	 raw:03 bw20:03 bw40:03
      	 raw:03 bw20:03 bw40:03
      	 raw:04 bw20:04 bw40:04
      	 raw:00 bw20:00 bw40:00
      	 raw:00 bw20:00 bw40:00
      	 raw:00 bw20:00 bw40:00
      	 raw:02 bw20:02 bw40:02
      	 raw:00 bw20:00 bw40:00
      Per channel power:
      	 tx_power  ch1:09 ch2:09
      	 tx_power  ch3:0a ch4:0a
      	 tx_power  ch5:0a ch6:0a
      	 tx_power  ch7:0b ch8:0b
      	 tx_power  ch9:0b ch10:0b
      	 tx_power  ch11:0b ch12:0b
      	 tx_power  ch13:0b ch14:0b
      Reported-and-tested-by: default avatarMichael <ZeroBeat@gmx.de>
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarJakub Kicinski <kubakici@wp.pl>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      66871349
    • Alexey Khoroshilov's avatar
      soc: qcom: gsbi: Fix error handling in gsbi_probe() · a2479c40
      Alexey Khoroshilov authored
      [ Upstream commit 8cd09a3d ]
      
      If of_platform_populate() fails in gsbi_probe(),
      gsbi->hclk is left undisabled.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a2479c40
    • Ard Biesheuvel's avatar
      efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted · ce80ebf7
      Ard Biesheuvel authored
      [ Upstream commit 4e46c2a9 ]
      
      The UEFI spec revision 2.7 errata A section 8.4 has the following to
      say about the virtual memory runtime services:
      
        "This section contains function definitions for the virtual memory
        support that may be optionally used by an operating system at runtime.
        If an operating system chooses to make EFI runtime service calls in a
        virtual addressing mode instead of the flat physical mode, then the
        operating system must use the services in this section to switch the
        EFI runtime services from flat physical addressing to virtual
        addressing."
      
      So it is pretty clear that calling SetVirtualAddressMap() is entirely
      optional, and so there is no point in doing so unless it achieves
      anything useful for us.
      
      This is not the case for 64-bit ARM. The identity mapping used by the
      firmware is arbitrarily converted into another permutation of userland
      addresses (i.e., bits [63:48] cleared), and the runtime code could easily
      deal with the original layout in exactly the same way as it deals with
      the converted layout. However, due to constraints related to page size
      differences if the OS is not running with 4k pages, and related to
      systems that may expose the individual sections of PE/COFF runtime
      modules as different memory regions, creating the virtual layout is a
      bit fiddly, and requires us to sort the memory map and reason about
      adjacent regions with identical memory types etc etc.
      
      So the obvious fix is to stop calling SetVirtualAddressMap() altogether
      on arm64 systems. However, to avoid surprises, which are notoriously
      hard to diagnose when it comes to OS<->firmware interactions, let's
      start by making it an opt-out feature, and implement support for the
      'efi=novamap' kernel command line parameter on ARM and arm64 systems.
      
      ( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
        used, given that the physical memory map and the kernel virtual address
        map are not guaranteed to be non-overlapping like on arm64. However,
        having support for efi=novamap,noruntime on 32-bit ARM, combined with
        the recently proposed support for earlycon=efifb, is likely to be useful
        to diagnose boot issues on such systems if they have no accessible serial
        port. )
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Tested-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Tested-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ce80ebf7
    • Mathieu Malaterre's avatar
      ARM: dts: lpc32xx: Remove leading 0x and 0s from bindings notation · 240a9050
      Mathieu Malaterre authored
      [ Upstream commit 3e3380d0 ]
      
      Improve the DTS files by removing all the leading "0x" and zeros to fix
      the following dtc warnings:
      
      Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
      
      and
      
      Warning (unit_address_format): Node /XXX unit name should not have leading 0s
      
      Converted using the following command:
      
      find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +
      
      For simplicity, two sed expressions were used to solve each warnings
      separately.
      
      To make the regex expression more robust a few other issues were resolved,
      namely setting unit-address to lower case, and adding a whitespace before
      the opening curly brace:
      
      https://elinux.org/Device_Tree_Linux#Linux_conventions
      
      This will solve as a side effect warning:
      
      Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
      
      This is a follow up to commit 4c9847b7 ("dt-bindings: Remove leading 0x from bindings notation")
      Reported-by: default avatarDavid Daney <ddaney@caviumnetworks.com>
      Suggested-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMathieu Malaterre <malat@debian.org>
      [vzapolskiy: fixed commit message to pass checkpatch.pl test]
      Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      240a9050
    • Shayenne Moura's avatar
      drm/vkms: Bugfix extra vblank frame · b5c1dc9d
      Shayenne Moura authored
      [ Upstream commit def35e7c ]
      
      kms_flip tests are breaking on vkms when simulate vblank because vblank
      event sequence count returns one extra frame after arm vblank event to
      make a page flip.
      
      When vblank interrupt happens, userspace processes the vblank event and
      issues the next page flip command. Kernel calls queue_work to call
      commit_planes and arm the new page flip. The next vblank picks up the
      newly armed vblank event and vblank interrupt happens again.
      
      The arm and vblank event are asynchronous, then, on the next vblank, we
      receive x+2 from `get_vblank_timestamp`, instead x+1, although timestamp
      and vblank seqno matches.
      
      Function `get_vblank_timestamp` is reached by 2 ways:
      
        - from `drm_mode_page_flip_ioctl`: driver is doing one atomic
          operation to synchronize planes in the same output. There is no
          vblank simulation, the `drm_crtc_arm_vblank_event` function adds 1
          on vblank count, and the variable in_vblank_irq is false
        - from `vkms_vblank_simulate`: since the driver is doing a vblank
          simulation, the variable in_vblank_irq is true.
      
      Fix this problem subtracting one vblank period from vblank_time when
      `get_vblank_timestamp` is called from trace `drm_mode_page_flip_ioctl`,
      i.e., is not a real vblank interrupt, and getting the timestamp and
      vblank seqno when it is a real vblank interrupt.
      
      The reason for all this is that get_vblank_timestamp always supplies the
      timestamp for the next vblank event. The hrtimer is the vblank
      simulator, and it needs the correct previous value to present the next
      vblank. Since this is how hw timestamp registers work and what the
      vblank core expects.
      Signed-off-by: default avatarShayenne Moura <shayenneluzmoura@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: default avatarRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Signed-off-by: default avatarRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/171e6e1c239cbca0c3df7183ed8acdfeeace9cf4.1548856186.git.shayenneluzmoura@gmail.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      b5c1dc9d
    • Andrea Parri's avatar
      sched/core: Use READ_ONCE()/WRITE_ONCE() in move_queued_task()/task_rq_lock() · e8e0bd49
      Andrea Parri authored
      [ Upstream commit c546951d ]
      
      move_queued_task() synchronizes with task_rq_lock() as follows:
      
      	move_queued_task()		task_rq_lock()
      
      	[S] ->on_rq = MIGRATING		[L] rq = task_rq()
      	WMB (__set_task_cpu())		ACQUIRE (rq->lock);
      	[S] ->cpu = new_cpu		[L] ->on_rq
      
      where "[L] rq = task_rq()" is ordered before "ACQUIRE (rq->lock)" by an
      address dependency and, in turn, "ACQUIRE (rq->lock)" is ordered before
      "[L] ->on_rq" by the ACQUIRE itself.
      
      Use READ_ONCE() to load ->cpu in task_rq() (c.f., task_cpu()) to honor
      this address dependency.  Also, mark the accesses to ->cpu and ->on_rq
      with READ_ONCE()/WRITE_ONCE() to comply with the LKMM.
      Signed-off-by: default avatarAndrea Parri <andrea.parri@amarulasolutions.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul E. McKenney <paulmck@linux.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: https://lkml.kernel.org/r/20190121155240.27173-1-andrea.parri@amarulasolutions.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e8e0bd49
    • Ard Biesheuvel's avatar
      efi/memattr: Don't bail on zero VA if it equals the region's PA · b12a060a
      Ard Biesheuvel authored
      [ Upstream commit 5de0fef0 ]
      
      The EFI memory attributes code cross-references the EFI memory map with
      the more granular EFI memory attributes table to ensure that they are in
      sync before applying the strict permissions to the regions it describes.
      
      Since we always install virtual mappings for the EFI runtime regions to
      which these strict permissions apply, we currently perform a sanity check
      on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit
      is set, and that the virtual address has been assigned.
      
      However, in cases where a runtime region exists at physical address 0x0,
      and the virtual mapping equals the physical mapping, e.g., when running
      in mixed mode on x86, we encounter a memory descriptor with the runtime
      attribute and virtual address 0x0, and incorrectly draw the conclusion
      that a runtime region exists for which no virtual mapping was installed,
      and give up altogether. The consequence of this is that firmware mappings
      retain their read-write-execute permissions, making the system more
      vulnerable to attacks.
      
      So let's only bail if the virtual address of 0x0 has been assigned to a
      physical region that does not reside at address 0x0.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 10f0d2f5 ("efi: Implement generic support for the Memory ...")
      Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b12a060a
    • Hidetoshi Seto's avatar
      sched/debug: Initialize sd_sysctl_cpus if !CONFIG_CPUMASK_OFFSTACK · f056c90f
      Hidetoshi Seto authored
      [ Upstream commit 1ca4fa3a ]
      
      register_sched_domain_sysctl() copies the cpu_possible_mask into
      sd_sysctl_cpus, but only if sd_sysctl_cpus hasn't already been
      allocated (ie, CONFIG_CPUMASK_OFFSTACK is set).  However, when
      CONFIG_CPUMASK_OFFSTACK is not set, sd_sysctl_cpus is left
      uninitialized (all zeroes) and the kernel may fail to initialize
      sched_domain sysctl entries for all possible CPUs.
      
      This is visible to the user if the kernel is booted with maxcpus=n, or
      if ACPI tables have been modified to leave CPUs offline, and then
      checking for missing /proc/sys/kernel/sched_domain/cpu* entries.
      
      Fix this by separating the allocation and initialization, and adding a
      flag to initialize the possible CPU entries while system booting only.
      Tested-by: default avatarSyuuichirou Ishii <ishii.shuuichir@jp.fujitsu.com>
      Tested-by: default avatarTarumizu, Kohei <tarumizu.kohei@jp.fujitsu.com>
      Signed-off-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarMasayoshi Mizuma <m.mizuma@jp.fujitsu.com>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190129151245.5073-1-msys.mizuma@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f056c90f
    • wen yang's avatar
      ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe · 442caac9
      wen yang authored
      [ Upstream commit 11907e9d ]
      
      The of_find_device_by_node() takes a reference to the underlying device
      structure, we should release that reference.
      Signed-off-by: default avatarWen Yang <yellowriver2010@hotmil.com>
      Cc: Timur Tabi <timur@kernel.org>
      Cc: Nicolin Chen <nicoleotsuka@gmail.com>
      Cc: Xiubo Li <Xiubo.Lee@gmail.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      442caac9
    • Johannes Berg's avatar
      iwlwifi: mvm: fix RFH config command with >=10 CPUs · b4410c7d
      Johannes Berg authored
      [ Upstream commit dbf592f3 ]
      
      If we have >=10 (logical) CPUs, our command size exceeds the
      internal buffer size and the command fails; fix that by using
      IWL_HCMD_DFL_NOCOPY for the command that's allocated anyway.
      
      While at it, also fix the leak of cmd, and use struct_size()
      to calculate its size.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Fixes: 8edbfaa1 ("iwlwifi: mvm: configure multi RX queue")
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b4410c7d
    • Stefan Roese's avatar
      staging: spi: mt7621: Add return code check on device_reset() · 080e00c8
      Stefan Roese authored
      [ Upstream commit 46c33787 ]
      
      This patch adds a return code check on device_reset() and removes the
      compile warning.
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Sankalp Negi <sankalpnegi2310@gmail.com>
      Cc: Chuanhong Guo <gch981213@gmail.com>
      Cc: John Crispin <john@phrozen.org>
      Reviewed-by: default avatarNeilBrown <neil@brown.name>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      080e00c8
    • Thierry Reding's avatar
      i2c: of: Try to find an I2C adapter matching the parent · f0eb935c
      Thierry Reding authored
      [ Upstream commit e814e688 ]
      
      If an I2C adapter doesn't match the provided device tree node, also try
      matching the parent's device tree node. This allows finding an adapter
      based on the device node of the parent device that was used to register
      it.
      
      This fixes a regression on Tegra124-based Chromebooks (Nyan) where the
      eDP controller registers an I2C adapter that is used to read to EDID.
      After commit 993a815d ("dt-bindings: panel: Add missing .txt
      suffix") this stopped working because the I2C adapter could no longer
      be found. The approach in this patch fixes the regression without
      introducing the issues that the above commit solved.
      
      Fixes: 17ab7806 ("drm: don't link DP aux i2c adapter to the hardware device node")
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Tested-by: default avatarTristan Bastian <tristan-c.bastian@gmx.de>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f0eb935c
    • Rajneesh Bhardwaj's avatar
      platform/x86: intel_pmc_core: Fix PCH IP sts reading · 7c114e86
      Rajneesh Bhardwaj authored
      [ Upstream commit 0e68eeea ]
      
      A previous commit "platform/x86: intel_pmc_core: Make the driver PCH
      family agnostic <c977b98b>" provided
      better abstraction to this driver but has some fundamental issues.
      
      e.g. the following condition
      
      for (index = 0; index < pmcdev->map->ppfear_buckets &&
      	index < PPFEAR_MAX_NUM_ENTRIES; index++, iter++)
      
      is wrong because for CNL, PPFEAR_MAX_NUM_ENTRIES is hardcoded as 5 which
      is _wrong_ and even though ppfear_buckets is 8, the loop fails to read
      all eight registers needed for CNL PCH i.e. PPFEAR0 and PPFEAR1. This
      patch refactors the pfear show logic to correctly read PCH IP power
      gating status for Cannonlake and beyond.
      
      Cc: "David E. Box" <david.e.box@intel.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Fixes: c977b98b ("platform/x86: intel_pmc_core: Make the driver PCH family agnostic")
      Signed-off-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7c114e86
    • Kai-Heng Feng's avatar
      e1000e: Exclude device from suspend direct complete optimization · b9f257e2
      Kai-Heng Feng authored
      [ Upstream commit 59f58708 ]
      
      e1000e sets different WoL settings in system suspend callback and
      runtime suspend callback.
      
      The suspend direct complete optimization leaves e1000e in runtime
      suspended state with wrong WoL setting during system suspend.
      
      To fix this, we need to disable suspend direct complete optimization to
      let e1000e always use suspend callback to set correct WoL during system
      suspend.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b9f257e2
    • Konstantin Khlebnikov's avatar
      e1000e: fix cyclic resets at link up with active tx · c23242c3
      Konstantin Khlebnikov authored
      [ Upstream commit 0f9e980b ]
      
      I'm seeing series of e1000e resets (sometimes endless) at system boot
      if something generates tx traffic at this time. In my case this is
      netconsole who sends message "e1000e 0000:02:00.0: Some CPU C-states
      have been disabled in order to enable jumbo frames" from e1000e itself.
      As result e1000_watchdog_task sees used tx buffer while carrier is off
      and start this reset cycle again.
      
      [   17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
      [   17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
      [   22.936455] e1000e 0000:02:00.0 eth1: changing MTU from 1500 to 9000
      [   23.033336] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
      [   27.174495] 8021q: 802.1Q VLAN Support v1.8
      [   27.174513] 8021q: adding VLAN 0 to HW filter on device eth1
      [   30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation
      [   30.898564] netpoll: netconsole: local port 6666
      [   30.898566] netpoll: netconsole: local IPv6 address 2a02:6b8:0:80b:beae:c5ff:fe28:23f8
      [   30.898567] netpoll: netconsole: interface 'eth1'
      [   30.898568] netpoll: netconsole: remote port 6666
      [   30.898568] netpoll: netconsole: remote IPv6 address 2a02:6b8:b000:605c:e61d:2dff:fe03:3790
      [   30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0
      [   30.917747] console [netcon0] enabled
      [   30.917749] netconsole: network logging started
      [   31.453353] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   34.185730] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   34.321840] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   34.465822] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   34.597423] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   34.745417] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   34.877356] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   35.005441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   35.157376] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   35.289362] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   35.417441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames
      [   37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
      
      This patch flushes tx buffers only once when carrier is off
      rather than at each watchdog iteration.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c23242c3
    • Mathieu Poirier's avatar
      perf/aux: Make perf_event accessible to setup_aux() · efd85d83
      Mathieu Poirier authored
      [ Upstream commit 84001866 ]
      
      When pmu::setup_aux() is called the coresight PMU needs to know which
      sink to use for the session by looking up the information in the
      event's attr::config2 field.
      
      As such simply replace the cpu information by the complete perf_event
      structure and change all affected customers.
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Reviewed-by: default avatarSuzuki Poulouse <suzuki.poulose@arm.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-s390@vger.kernel.org
      Link: http://lkml.kernel.org/r/20190131184714.20388-2-mathieu.poirier@linaro.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      efd85d83
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Disconnect mpcc when changing tg · 355ffe6c
      Nicholas Kazlauskas authored
      [ Upstream commit 77476360 ]
      
      [Why]
      This fixes an mpc programming error for the following sequence of
      atomic commits when pipe split is enabled:
      
      Commit 1: CRTC0 (plane 4, plane 3)
      
      Pipe 0: old_plane_state = A0, new_plane_state = A1,   new_tg = T0
      Pipe 1: old_plane_state = B0, new_plane_state = B1,   new_tg = T0
      Pipe 2: old_plane_state = A0, new_plane_state = A1,   new_tg = T0
      Pipe 3: old_plane_state = B0, new_plane_state = B1,   new_tg = T0
      
      Commit 2: CRTC0 (plane 3), CRTC1 (plane 2)
      
      Pipe 0: old_plane_state = A1, new_plane_state = A2,   new_tg = T0
      Pipe 1: old_plane_state = B1, new_plane_state = B2,   new_tg = T1
      Pipe 2: old_plane_state = A1, new_plane_state = NULL, new_tg = NULL
      Pipe 3: old_plane_state = B1, new_plane_state = NULL, new_tg = NULL
      
      In the second commit the assertion for mpcc in use is hit because
      mpcc disconnect never occurs for pipe 1. This is because the stream
      changes for pipe 1 and the opp_list is empty.
      
      This sequence occurs when running the
      "igt@kms_plane_multiple@atomic-pipe-A-tiling-none" test with two
      displays connected.
      
      [How]
      Expand the reset condition to include:
      
      "old_pipe_ctx->stream_res.tg != new_pipe_ctx->stream_res.tg"
      
      ...but only when the plane state is non-NULL for both old and new.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
      Reviewed-by: default avatarTony Cheng <Tony.Cheng@amd.com>
      Acked-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      355ffe6c
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Don't re-program planes for DPMS changes · 6c68d165
      Nicholas Kazlauskas authored
      [ Upstream commit 5062b797 ]
      
      [Why]
      There are opt1c lock warnings and CRTC read timeouts when running the
      "igt@kms_plane@plane-position-hole-dpms-pipe-*" tests. These are
      caused by trying to reprogram planes that are not in the current
      context.
      
      DPMS off removes the stream from the context. In this case:
      
      new_crtc_state->active_changed = true
      new_crtc_state->mode_changed = false
      
      The planes are reprogrammed before the stream is removed from the
      context because stream_state->mode_changed = false.
      
      For DPMS adds the stream and planes back to the context:
      
      new_crtc_state->active_changed = true
      new_crtc_state->mode_changed = false
      
      The planes are also reprogrammed here before the stream is added to the
      context because stream_state->mode_changed = true. They were not
      previously in the current context so warnings occur here.
      
      [How]
      Set stream_state->mode_changed = true when
      new_crtc_state->active_changed = true too.
      
      This prevents reprogramming before the context is applied in DC. The
      programming will be done after the context is applied.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarSun peng Li <Sunpeng.Li@amd.com>
      Acked-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Acked-by: default avatarTony Cheng <Tony.Cheng@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6c68d165
    • Julia Lawall's avatar
      drm: rcar-du: add missing of_node_put · 322a55a5
      Julia Lawall authored
      [ Upstream commit 4c6d8fc2 ]
      
      Add an of_node_put when the result of of_graph_get_remote_port_parent is
      not available.
      
      Add a second of_node_put if no encoder is selected (encoder remains NULL).
      
      The semantic match that finds the first problem is as follows
      (http://coccinelle.lip6.fr):
      
      // <smpl>
      @r exists@
      local idexpression e;
      expression x;
      @@
      e = of_graph_get_remote_port_parent(...);
      ... when != x = e
          when != true e == NULL
          when != of_node_put(e)
          when != of_fwnode_handle(e)
      (
      return e;
      |
      *return ...;
      )
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reviewed-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      322a55a5
    • Guenter Roeck's avatar
      cdrom: Fix race condition in cdrom_sysctl_register · 924af499
      Guenter Roeck authored
      [ Upstream commit f25191bb ]
      
      The following traceback is sometimes seen when booting an image in qemu:
      
      [   54.608293] cdrom: Uniform CD-ROM driver Revision: 3.20
      [   54.611085] Fusion MPT base driver 3.04.20
      [   54.611877] Copyright (c) 1999-2008 LSI Corporation
      [   54.616234] Fusion MPT SAS Host driver 3.04.20
      [   54.635139] sysctl duplicate entry: /dev/cdrom//info
      [   54.639578] CPU: 0 PID: 266 Comm: kworker/u4:5 Not tainted 5.0.0-rc5 #1
      [   54.639578] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
      [   54.641273] Workqueue: events_unbound async_run_entry_fn
      [   54.641273] Call Trace:
      [   54.641273]  dump_stack+0x67/0x90
      [   54.641273]  __register_sysctl_table+0x50b/0x570
      [   54.641273]  ? rcu_read_lock_sched_held+0x6f/0x80
      [   54.641273]  ? kmem_cache_alloc_trace+0x1c7/0x1f0
      [   54.646814]  __register_sysctl_paths+0x1c8/0x1f0
      [   54.646814]  cdrom_sysctl_register.part.7+0xc/0x5f
      [   54.646814]  register_cdrom.cold.24+0x2a/0x33
      [   54.646814]  sr_probe+0x4bd/0x580
      [   54.646814]  ? __driver_attach+0xd0/0xd0
      [   54.646814]  really_probe+0xd6/0x260
      [   54.646814]  ? __driver_attach+0xd0/0xd0
      [   54.646814]  driver_probe_device+0x4a/0xb0
      [   54.646814]  ? __driver_attach+0xd0/0xd0
      [   54.646814]  bus_for_each_drv+0x73/0xc0
      [   54.646814]  __device_attach+0xd6/0x130
      [   54.646814]  bus_probe_device+0x9a/0xb0
      [   54.646814]  device_add+0x40c/0x670
      [   54.646814]  ? __pm_runtime_resume+0x4f/0x80
      [   54.646814]  scsi_sysfs_add_sdev+0x81/0x290
      [   54.646814]  scsi_probe_and_add_lun+0x888/0xc00
      [   54.646814]  ? scsi_autopm_get_host+0x21/0x40
      [   54.646814]  __scsi_add_device+0x116/0x130
      [   54.646814]  ata_scsi_scan_host+0x93/0x1c0
      [   54.646814]  async_run_entry_fn+0x34/0x100
      [   54.646814]  process_one_work+0x237/0x5e0
      [   54.646814]  worker_thread+0x37/0x380
      [   54.646814]  ? rescuer_thread+0x360/0x360
      [   54.646814]  kthread+0x118/0x130
      [   54.646814]  ? kthread_create_on_node+0x60/0x60
      [   54.646814]  ret_from_fork+0x3a/0x50
      
      The only sensible explanation is that cdrom_sysctl_register() is called
      twice, once from the module init function and once from register_cdrom().
      cdrom_sysctl_register() is not mutex protected and may happily execute
      twice if the second call is made before the first call is complete.
      
      Use a static atomic to ensure that the function is executed exactly once.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      924af499
    • Manfred Schlaegl's avatar
      fbdev: fbmem: fix memory access if logo is bigger than the screen · 6d293647
      Manfred Schlaegl authored
      [ Upstream commit a5399db1 ]
      
      There is no clipping on the x or y axis for logos larger that the framebuffer
      size. Therefore: a logo bigger than screen size leads to invalid memory access:
      
      [    1.254664] Backtrace:
      [    1.254728] [<c02714e0>] (cfb_imageblit) from [<c026184c>] (fb_show_logo+0x620/0x684)
      [    1.254763]  r10:00000003 r9:00027fd8 r8:c6a40000 r7:c6a36e50 r6:00000000 r5:c06b81e4
      [    1.254774]  r4:c6a3e800
      [    1.254810] [<c026122c>] (fb_show_logo) from [<c026c1e4>] (fbcon_switch+0x3fc/0x46c)
      [    1.254842]  r10:c6a3e824 r9:c6a3e800 r8:00000000 r7:c6a0c000 r6:c070b014 r5:c6a3e800
      [    1.254852]  r4:c6808c00
      [    1.254889] [<c026bde8>] (fbcon_switch) from [<c029c8f8>] (redraw_screen+0xf0/0x1e8)
      [    1.254918]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c070d5a0 r5:00000080
      [    1.254928]  r4:c6808c00
      [    1.254961] [<c029c808>] (redraw_screen) from [<c029d264>] (do_bind_con_driver+0x194/0x2e4)
      [    1.254991]  r9:00000000 r8:00000000 r7:00000014 r6:c070d5a0 r5:c070d5a0 r4:c070d5a0
      
      So prevent displaying a logo bigger than screen size and avoid invalid
      memory access.
      Signed-off-by: default avatarManfred Schlaegl <manfred.schlaegl@ginzinger.com>
      Signed-off-by: default avatarMartin Kepplinger <martin.kepplinger@ginzinger.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6d293647
    • Heiner Kallweit's avatar
      net: phy: consider latched link-down status in polling mode · 2dd69943
      Heiner Kallweit authored
      [ Upstream commit 93c09704 ]
      
      The link status value latches link-down events. To get the current
      status we read the register twice in genphy_update_link(). There's
      a potential risk that we miss a link-down event in polling mode.
      This may cause issues if the user e.g. connects his machine to a
      different network.
      
      On the other hand reading the latched value may cause issues in
      interrupt mode. Following scenario:
      
      - After boot link goes up
      - phy_start() is called triggering an aneg restart, hence link goes
        down and link-down info is latched.
      - After aneg has finished link goes up and triggers an interrupt.
        Interrupt handler reads link status, means it reads the latched
        "link is down" info. But there won't be another interrupt as long
        as link stays up, therefore phylib will never recognize that link
        is up.
      
      Deal with both scenarios by reading the register twice in interrupt
      mode only.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2dd69943
    • Raju Rangoju's avatar
      iw_cxgb4: fix srqidx leak during connection abort · 5203cf8e
      Raju Rangoju authored
      [ Upstream commit f368ff18 ]
      
      When an application aborts the connection by moving QP from RTS to ERROR,
      then iw_cxgb4's modify_rc_qp() RTS->ERROR logic sets the
      *srqidxp to 0 via t4_set_wq_in_error(&qhp->wq, 0), and aborts the
      connection by calling c4iw_ep_disconnect().
      
      c4iw_ep_disconnect() does the following:
       1. sends up a close_complete_upcall(ep, -ECONNRESET) to libcxgb4.
       2. sends abort request CPL to hw.
      
      But, since the close_complete_upcall() is sent before sending the
      ABORT_REQ to hw, libcxgb4 would fail to release the srqidx if the
      connection holds one. Because, the srqidx is passed up to libcxgb4 only
      after corresponding ABORT_RPL is processed by kernel in abort_rpl().
      
      This patch handle the corner-case by moving the call to
      close_complete_upcall() from c4iw_ep_disconnect() to abort_rpl().  So that
      libcxgb4 is notified about the -ECONNRESET only after abort_rpl(), and
      libcxgb4 can relinquish the srqidx properly.
      Signed-off-by: default avatarRaju Rangoju <rajur@chelsio.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5203cf8e