1. 06 4月, 2019 40 次提交
    • J
      iwlwifi: mvm: fix RFH config command with >=10 CPUs · b4410c7d
      Johannes Berg 提交于
      [ Upstream commit dbf592f3d14fb7d532cb7c820b1065cf33e02aaa ]
      
      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: NJohannes Berg <johannes.berg@intel.com>
      Fixes: 8edbfaa1 ("iwlwifi: mvm: configure multi RX queue")
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b4410c7d
    • S
      staging: spi: mt7621: Add return code check on device_reset() · 080e00c8
      Stefan Roese 提交于
      [ Upstream commit 46c337872f34bc6387b0c29a4964f562c70139e3 ]
      
      This patch adds a return code check on device_reset() and removes the
      compile warning.
      Signed-off-by: NStefan 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: NNeilBrown <neil@brown.name>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      080e00c8
    • T
      i2c: of: Try to find an I2C adapter matching the parent · f0eb935c
      Thierry Reding 提交于
      [ Upstream commit e814e688413aabd7b0d75e2a8ed1caa472951dec ]
      
      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 993a815dcbb2 ("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: NThierry Reding <treding@nvidia.com>
      Tested-by: NTristan Bastian <tristan-c.bastian@gmx.de>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f0eb935c
    • R
      platform/x86: intel_pmc_core: Fix PCH IP sts reading · 7c114e86
      Rajneesh Bhardwaj 提交于
      [ Upstream commit 0e68eeea9894feeba2edf7ec63e4551b87f39621 ]
      
      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: NRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7c114e86
    • K
      e1000e: Exclude device from suspend direct complete optimization · b9f257e2
      Kai-Heng Feng 提交于
      [ Upstream commit 59f58708c5047289589cbf6ee95146b76cf57d1e ]
      
      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: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b9f257e2
    • K
      e1000e: fix cyclic resets at link up with active tx · c23242c3
      Konstantin Khlebnikov 提交于
      [ Upstream commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61 ]
      
      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: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c23242c3
    • M
      perf/aux: Make perf_event accessible to setup_aux() · efd85d83
      Mathieu Poirier 提交于
      [ Upstream commit 840018668ce2d96783356204ff282d6c9b0e5f66 ]
      
      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: NMathieu Poirier <mathieu.poirier@linaro.org>
      Reviewed-by: NSuzuki Poulouse <suzuki.poulose@arm.com>
      Acked-by: NPeter 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: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      efd85d83
    • N
      drm/amd/display: Disconnect mpcc when changing tg · 355ffe6c
      Nicholas Kazlauskas 提交于
      [ Upstream commit 77476360f173c127c191bfe8ca8113130ef283b8 ]
      
      [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: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
      Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
      Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      355ffe6c
    • N
      drm/amd/display: Don't re-program planes for DPMS changes · 6c68d165
      Nicholas Kazlauskas 提交于
      [ Upstream commit 5062b797db4103218fa00ee254417b8ecaab7401 ]
      
      [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: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
      Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Acked-by: NTony Cheng <Tony.Cheng@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6c68d165
    • J
      drm: rcar-du: add missing of_node_put · 322a55a5
      Julia Lawall 提交于
      [ Upstream commit 4c6d8fc20b09f9684743afd72e4dbc3f15524479 ]
      
      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: NJulia Lawall <Julia.Lawall@lip6.fr>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      322a55a5
    • G
      cdrom: Fix race condition in cdrom_sysctl_register · 924af499
      Guenter Roeck 提交于
      [ Upstream commit f25191bb322dec8fa2979ecb8235643aa42470e1 ]
      
      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: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      924af499
    • M
      fbdev: fbmem: fix memory access if logo is bigger than the screen · 6d293647
      Manfred Schlaegl 提交于
      [ Upstream commit a5399db139cb3ad9b8502d8b1bd02da9ce0b9df0 ]
      
      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: NManfred Schlaegl <manfred.schlaegl@ginzinger.com>
      Signed-off-by: NMartin Kepplinger <martin.kepplinger@ginzinger.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6d293647
    • H
      net: phy: consider latched link-down status in polling mode · 2dd69943
      Heiner Kallweit 提交于
      [ Upstream commit 93c0970493c71f264e6c3c7caf1ff24a9e1de786 ]
      
      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: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2dd69943
    • R
      iw_cxgb4: fix srqidx leak during connection abort · 5203cf8e
      Raju Rangoju 提交于
      [ Upstream commit f368ff188ae4b3ef6f740a15999ea0373261b619 ]
      
      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: NRaju Rangoju <rajur@chelsio.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5203cf8e
    • R
      net: marvell: mvpp2: fix stuck in-band SGMII negotiation · a78aae93
      Russell King 提交于
      [ Upstream commit 316734fdcf70900a83065360cff11a5826919067 ]
      
      It appears that the mvpp22 can get stuck with SGMII negotiation.  The
      symptoms are that in-band negotiation never completes and the partner
      (eg, PHY) never reports SGMII link up, or if it supports negotiation
      bypass, goes into negotiation bypass mode (which will happen when the
      PHY sees that the MAC is alive but gets no response.)
      
      Triggering the PHY end of the link to re-negotiate results in the
      bypass bit clearing on the PHY, and then re-setting - indicating that
      the problem is at the mvpp22 GMAC end.
      
      Asserting the GMAC reset and de-asserting it resolves the issue.
      Arrange to assert the GMAC reset at probe time, and deassert it only
      after we have configured the GMAC for the appropriate mode.  This
      resolves the issue.
      Tested-by: NSven Auhagen <sven.auhagen@voleatech.de>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a78aae93
    • C
      bcache: improve sysfs_strtoul_clamp() · 98eddc19
      Coly Li 提交于
      [ Upstream commit 596b5a5dd1bc2fa019fdaaae522ef331deef927f ]
      
      Currently sysfs_strtoul_clamp() is defined as,
       82 #define sysfs_strtoul_clamp(file, var, min, max)                   \
       83 do {                                                               \
       84         if (attr == &sysfs_ ## file)                               \
       85                 return strtoul_safe_clamp(buf, var, min, max)      \
       86                         ?: (ssize_t) size;                         \
       87 } while (0)
      
      The problem is, if bit width of var is less then unsigned long, min and
      max may not protect var from integer overflow, because overflow happens
      in strtoul_safe_clamp() before checking min and max.
      
      To fix such overflow in sysfs_strtoul_clamp(), to make min and max take
      effect, this patch adds an unsigned long variable, and uses it to macro
      strtoul_safe_clamp() to convert an unsigned long value in range defined
      by [min, max]. Then assign this value to var. By this method, if bit
      width of var is less than unsigned long, integer overflow won't happen
      before min and max are checking.
      
      Now sysfs_strtoul_clamp() can properly handle smaller data type like
      unsigned int, of cause min and max should be defined in range of
      unsigned int too.
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      98eddc19
    • C
      bcache: fix potential div-zero error of writeback_rate_i_term_inverse · b468e000
      Coly Li 提交于
      [ Upstream commit c3b75a2199cdbfc1c335155fe143d842604b1baa ]
      
      dc->writeback_rate_i_term_inverse can be set via sysfs interface. It is
      in type unsigned int, and convert from input string by d_strtoul(). The
      problem is d_strtoul() does not check valid range of the input, if
      4294967296 is written into sysfs file writeback_rate_i_term_inverse,
      an overflow of unsigned integer will happen and value 0 is set to
      dc->writeback_rate_i_term_inverse.
      
      In writeback.c:__update_writeback_rate(), there are following lines of
      code,
            integral_scaled = div_s64(dc->writeback_rate_integral,
                            dc->writeback_rate_i_term_inverse);
      If dc->writeback_rate_i_term_inverse is set to 0 via sysfs interface,
      a div-zero error might be triggered in the above code.
      
      Therefore we need to add a range limitation in the sysfs interface,
      this is what this patch does, use sysfs_stroul_clamp() to replace
      d_strtoul() and restrict the input range in [1, UINT_MAX].
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b468e000
    • C
      bcache: fix input overflow to sequential_cutoff · c7b687eb
      Coly Li 提交于
      [ Upstream commit 8c27a3953e92eb0b22dbb03d599f543a05f9574e ]
      
      People may set sequential_cutoff of a cached device via sysfs file,
      but current code does not check input value overflow. E.g. if value
      4294967295 (UINT_MAX) is written to file sequential_cutoff, its value
      is 4GB, but if 4294967296 (UINT_MAX + 1) is written into, its value
      will be 0. This is an unexpected behavior.
      
      This patch replaces d_strtoi_h() by sysfs_strtoul_clamp() to convert
      input string to unsigned integer value, and limit its range in
      [0, UINT_MAX]. Then the input overflow can be fixed.
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c7b687eb
    • C
      bcache: fix input overflow to cache set sysfs file io_error_halflife · 16975f04
      Coly Li 提交于
      [ Upstream commit a91fbda49f746119828f7e8ad0f0aa2ab0578f65 ]
      
      Cache set sysfs entry io_error_halflife is used to set c->error_decay.
      c->error_decay is in type unsigned int, and it is converted by
      strtoul_or_return(), therefore overflow to c->error_decay is possible
      for a large input value.
      
      This patch fixes the overflow by using strtoul_safe_clamp() to convert
      input string to an unsigned long value in range [0, UINT_MAX], then
      divides by 88 and set it to c->error_decay.
      Signed-off-by: NColy Li <colyli@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      16975f04
    • J
      usb: f_fs: Avoid crash due to out-of-scope stack ptr access · ad02fb6a
      John Stultz 提交于
      [ Upstream commit 54f64d5c983f939901dacc8cfc0983727c5c742e ]
      
      Since the 5.0 merge window opened, I've been seeing frequent
      crashes on suspend and reboot with the trace:
      
      [   36.911170] Unable to handle kernel paging request at virtual address ffffff801153d660
      [   36.912769] Unable to handle kernel paging request at virtual address ffffff800004b564
      ...
      [   36.950666] Call trace:
      [   36.950670]  queued_spin_lock_slowpath+0x1cc/0x2c8
      [   36.950681]  _raw_spin_lock_irqsave+0x64/0x78
      [   36.950692]  complete+0x28/0x70
      [   36.950703]  ffs_epfile_io_complete+0x3c/0x50
      [   36.950713]  usb_gadget_giveback_request+0x34/0x108
      [   36.950721]  dwc3_gadget_giveback+0x50/0x68
      [   36.950723]  dwc3_thread_interrupt+0x358/0x1488
      [   36.950731]  irq_thread_fn+0x30/0x88
      [   36.950734]  irq_thread+0x114/0x1b0
      [   36.950739]  kthread+0x104/0x130
      [   36.950747]  ret_from_fork+0x10/0x1c
      
      I isolated this down to in ffs_epfile_io():
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065
      
      Where the completion done is setup on the stack:
        DECLARE_COMPLETION_ONSTACK(done);
      
      Then later we setup a request and queue it, and wait for it:
        if (unlikely(wait_for_completion_interruptible(&done))) {
          /*
          * To avoid race condition with ffs_epfile_io_complete,
          * dequeue the request first then check
          * status. usb_ep_dequeue API should guarantee no race
          * condition with req->complete callback.
          */
          usb_ep_dequeue(ep->ep, req);
          interrupted = ep->status < 0;
        }
      
      The problem is, that we end up being interrupted, dequeue the
      request, and exit.
      
      But then the irq triggers and we try calling complete() on the
      context pointer which points to now random stack space, which
      results in the panic.
      
      Alan Stern pointed out there is a bug here, in that the snippet
      above "assumes that usb_ep_dequeue() waits until the request has
      been completed." And that:
      
          wait_for_completion(&done);
      
      Is needed right after the usb_ep_dequeue().
      
      Thus this patch implements that change. With it I no longer see
      the crashes on suspend or reboot.
      
      This issue seems to have been uncovered by behavioral changes in
      the dwc3 driver in commit fec9095bdef4e ("usb: dwc3: gadget:
      remove wait_end_transfer").
      
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Zeng Tao <prime.zeng@hisilicon.com>
      Cc: Jack Pham <jackp@codeaurora.org>
      Cc: Thinh Nguyen <thinh.nguyen@synopsys.com>
      Cc: Chen Yu <chenyu56@huawei.com>
      Cc: Jerry Zhang <zhangjerry@google.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Vincent Pelletier <plr.vincent@gmail.com>
      Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linux USB List <linux-usb@vger.kernel.org>
      Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ad02fb6a
    • R
      ath10k: fix shadow register implementation for WCN3990 · 126f2f6a
      Rakesh Pillai 提交于
      [ Upstream commit 1863008369ae0407508033b4b00f98b985adeb15 ]
      
      WCN3990 supports shadow registers write operation support
      for copy engine for regular operation in powersave mode.
      
      Since WCN3990 is a 64-bit target, the shadow register
      implementation needs to be done in the copy engine handlers
      for 64-bit target. Currently the shadow register implementation
      is present in the 32-bit target handlers of copy engine.
      
      Fix the shadow register copy engine write operation
      implementation for 64-bit target(WCN3990).
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      
      Fixes: b7ba83f7 ("ath10k: add support for shadow register for WNC3990")
      Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      126f2f6a
    • H
      ACPI / video: Refactor and fix dmi_is_desktop() · 2df541d0
      Hans de Goede 提交于
      [ Upstream commit cecf3e3e0803462335e25d083345682518097334 ]
      
      This commit refactors the chassis-type detection introduced by
      commit 53fa1f6e ("ACPI / video: Only default only_lcd to true on
      Win8-ready _desktops_") (where desktop means anything without a builtin
      screen).
      
      The DMI chassis_type is an unsigned integer, so rather then doing a
      whole bunch of string-compares on it, convert it to an int and feed
      the result to a switch case.
      
      Note the switch case uses hex values, this is done because the spec
      uses hex values too. This changes the check for "Main Server Chassis"
      from checking for 11 decimal to 11 hexadecimal, this is a bug fix,
      the original check for 11 decimal was wrong.
      
      Fixes: 53fa1f6e ("ACPI / video: Only default only_lcd to true ...")
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      [ rjw: Drop redundant return statements ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2df541d0
    • S
      iwlwifi: pcie: fix emergency path · d6310584
      Sara Sharon 提交于
      [ Upstream commit c6ac9f9fb98851f47b978a9476594fc3c477a34d ]
      
      Allocator swaps the pending requests with 0 when it starts
      working. This means that relying on it n RX path to decide if
      to move to emergency is not always a good idea, since it may
      be zero, but there are still a lot of unallocated RBs in the
      system. Change allocator to decrement the pending requests on
      real time. It is more expensive since it accesses the atomic
      variable more times, but it gives the RX path a better idea
      of the system's status.
      Reported-by: NIlan Peer <ilan.peer@intel.com>
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Fixes: 868a1e863f95 ("iwlwifi: pcie: avoid empty free RB queue")
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d6310584
    • M
      leds: lp55xx: fix null deref on firmware load failure · 5658279f
      Michal Kazior 提交于
      [ Upstream commit 5ddb0869bfc1bca6cfc592c74c64a026f936638c ]
      
      I've stumbled upon a kernel crash and the logs
      pointed me towards the lp5562 driver:
      
      > <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2
      > <4>[306013.894990] lp5562 0-0030: Falling back to user helper
      > ...
      > <3>[306073.924886] lp5562 0-0030: firmware request failed
      > <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      > <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58
      > <4>[306074.255539] LR is at release_firmware+0x6c/0x138
      > ...
      
      After taking a look I noticed firmware_release()
      could be called with either NULL or a dangling
      pointer.
      
      Fixes: 10c06d17 ("leds-lp55xx: support firmware interface")
      Signed-off-by: NMichal Kazior <michal@plume.com>
      Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5658279f
    • H
      HID: intel-ish-hid: avoid binding wrong ishtp_cl_device · b13eb524
      Hong Liu 提交于
      [ Upstream commit 0d28f49412405d87d3aae83da255070a46e67627 ]
      
      When performing a warm reset in ishtp bus driver, the ishtp_cl_device
      will not be removed, its fw_client still points to the already freed
      ishtp_device.fw_clients array.
      
      Later after driver finishing ishtp client enumeration, this dangling
      pointer may cause driver to bind the wrong ishtp_cl_device to the new
      client, causing wrong callback to be called for messages intended for
      the new client.
      
      This helps in development of firmware where frequent switching of
      firmwares is required without Linux reboot.
      Signed-off-by: NHong Liu <hong.liu@intel.com>
      Tested-by: NHongyan Song <hongyan.song@intel.com>
      Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b13eb524
    • O
      xen/gntdev: Do not destroy context while dma-bufs are in use · 7273c2b1
      Oleksandr Andrushchenko 提交于
      [ Upstream commit fa13e665e02874c0a5f4d06d6967ae34a6cb3d6a ]
      
      If there are exported DMA buffers which are still in use and
      grant device is closed by either normal user-space close or by
      a signal this leads to the grant device context to be destroyed,
      thus making it not possible to correctly destroy those exported
      buffers when they are returned back to gntdev and makes the module
      crash:
      
      [  339.617540] [<ffff00000854c0d8>] dmabuf_exp_ops_release+0x40/0xa8
      [  339.617560] [<ffff00000867a6e8>] dma_buf_release+0x60/0x190
      [  339.617577] [<ffff0000082211f0>] __fput+0x88/0x1d0
      [  339.617589] [<ffff000008221394>] ____fput+0xc/0x18
      [  339.617607] [<ffff0000080ed4e4>] task_work_run+0x9c/0xc0
      [  339.617622] [<ffff000008089714>] do_notify_resume+0xfc/0x108
      
      Fix this by referencing gntdev on each DMA buffer export and
      unreferencing on buffer release.
      Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
      Reviewed-by: Boris Ostrovsky@oracle.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7273c2b1
    • L
      mt76: usb: do not run mt76u_queues_deinit twice · e9cd7f54
      Lorenzo Bianconi 提交于
      [ Upstream commit b3098121c42caaf3aea239b8655cf52d45be116f ]
      
      Do not call mt76u_queues_deinit routine in mt76u_alloc_queues error path
      since it will be run in mt76x0u_register_device or
      mt76x2u_register_device error path. Current implementation triggers the
      following kernel warning:
      
      [   67.005516] WARNING: CPU: 2 PID: 761 at lib/refcount.c:187 refcount_sub_and_test_checked+0xa4/0xb8
      [   67.019513] refcount_t: underflow; use-after-free.
      [   67.099872] Hardware name: BCM2835
      [   67.106268] Backtrace:
      [   67.111584] [<8010c91c>] (dump_backtrace) from [<8010cc00>] (show_stack+0x20/0x24)
      [   67.124974]  r6:60000013 r5:ffffffff r4:00000000 r3:a50bade6
      [   67.132226] [<8010cbe0>] (show_stack) from [<807ca5f4>] (dump_stack+0xc8/0x114)
      [   67.141225] [<807ca52c>] (dump_stack) from [<8011e65c>] (__warn+0xf4/0x120)
      [   67.149849]  r9:000000bb r8:804d0138 r7:00000009 r6:8099dc84 r5:00000000 r4:b66c7b58
      [   67.160767] [<8011e568>] (__warn) from [<8011e6d0>] (warn_slowpath_fmt+0x48/0x50)
      [   67.171436]  r9:7f65e128 r8:80d1419c r7:80c0bac4 r6:b97b3044 r5:b7368e00 r4:00000000
      [   67.182433] [<8011e68c>] (warn_slowpath_fmt) from [<804d0138>] (refcount_sub_and_test_checked+0xa4/0xb8)
      [   67.195221]  r3:80c91c25 r2:8099dc94
      [   67.200370]  r4:00000000
      [   67.204397] [<804d0094>] (refcount_sub_and_test_checked) from [<804d0164>] (refcount_dec_and_test_checked+0x18/0x1c)
      [   67.218046]  r4:b7368e00 r3:00000001
      [   67.223125] [<804d014c>] (refcount_dec_and_test_checked) from [<805db49c>] (usb_free_urb+0x20/0x4c)
      [   67.235358] [<805db47c>] (usb_free_urb) from [<7f639804>] (mt76u_buf_free+0x98/0xac [mt76_usb])
      [   67.247302]  r4:00000001 r3:00000001
      [   67.252468] [<7f63976c>] (mt76u_buf_free [mt76_usb]) from [<7f639ef8>] (mt76u_queues_deinit+0x44/0x100 [mt76_usb])
      [   67.266102]  r8:b8fe8600 r7:b5dac480 r6:b5dace20 r5:00000001 r4:00000000 r3:00000080
      [   67.277132] [<7f639eb4>] (mt76u_queues_deinit [mt76_usb]) from [<7f65c040>] (mt76x0u_cleanup+0x40/0x4c [mt76x0u])
      [   67.290737]  r7:b5dac480 r6:b8fe8600 r5:ffffffea r4:b5dace20
      [   67.298069] [<7f65c000>] (mt76x0u_cleanup [mt76x0u]) from [<7f65c564>] (mt76x0u_probe+0x1f0/0x354 [mt76x0u])
      [   67.311174]  r4:b5dace20 r3:00000000
      [   67.316312] [<7f65c374>] (mt76x0u_probe [mt76x0u]) from [<805e0b6c>] (usb_probe_interface+0x104/0x240)
      [   67.328915]  r7:00000000 r6:7f65e034 r5:b6634800 r4:b8fe8620
      [   67.336276] [<805e0a68>] (usb_probe_interface) from [<8056a8bc>] (really_probe+0x224/0x2f8)
      [   67.347965]  r10:b65f0a00 r9:00000019 r8:7f65e034 r7:80d3e124 r6:00000000 r5:80d3e120
      [   67.359175]  r4:b8fe8620 r3:805e0a68
      [   67.364384] [<8056a698>] (really_probe) from [<8056ab60>] (driver_probe_device+0x6c/0x180)
      [   67.375974]  r10:b65f0a00 r9:7f65e2c0 r8:b8fe8620 r7:00000000 r6:7f65e034 r5:7f65e034
      [   67.387170]  r4:b8fe8620 r3:00000000
      [   67.392378] [<8056aaf4>] (driver_probe_device) from [<8056ad54>] (__driver_attach+0xe0/0xe4)
      [   67.404097]  r9:7f65e2c0 r8:7f65d22c r7:00000000 r6:b8fe8654 r5:7f65e034 r4:b8fe8620
      [   67.415122] [<8056ac74>] (__driver_attach) from [<8056880c>] (bus_for_each_dev+0x68/0xa0)
      [   67.426628]  r6:8056ac74 r5:7f65e034 r4:00000000 r3:00000027
      [   67.434017] [<805687a4>] (bus_for_each_dev) from [<8056a1cc>] (driver_attach+0x28/0x30)
      [   67.445394]  r6:80c6ddc8 r5:b7368f80 r4:7f65e034
      [   67.451703] [<8056a1a4>] (driver_attach) from [<80569c24>] (bus_add_driver+0x194/0x21c)
      [   67.463081] [<80569a90>] (bus_add_driver) from [<8056b504>] (driver_register+0x8c/0x124)
      [   67.474560]  r7:80c6ddc8 r6:7f65e034 r5:00000000 r4:7f65e034
      [   67.481964] [<8056b478>] (driver_register) from [<805df510>] (usb_register_driver+0x74/0x140)
      [   67.493901]  r5:00000000 r4:7f65e000
      [   67.499131] [<805df49c>] (usb_register_driver) from [<7f661024>] (mt76x0_driver_init+0x24/0x1000 [mt76x0u])
      [   67.512258]  r9:00000001 r8:7f65e308 r7:00000000 r6:80c08d48 r5:7f661000 r4:7f65e2c0
      [   67.523404] [<7f661000>] (mt76x0_driver_init [mt76x0u]) from [<80102f6c>] (do_one_initcall+0x4c/0x210)
      [   67.536142] [<80102f20>] (do_one_initcall) from [<801ae63c>] (do_init_module+0x6c/0x21c)
      [   67.547639]  r8:7f65e308 r7:80c08d48 r6:b65f0ac0 r5:7f65e2c0 r4:7f65e2c0
      [   67.556129] [<801ae5d0>] (do_init_module) from [<801ad68c>] (load_module+0x1d10/0x2304)
      
      Fixes: b40b15e1 ("mt76: add usb support to mt76 layer")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e9cd7f54
    • E
      media: mtk-jpeg: Correct return type for mem2mem buffer helpers · 5cde7721
      Ezequiel Garcia 提交于
      [ Upstream commit 1b275e4e8b70dbff9850874b30831c1bd8d3c504 ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5cde7721
    • E
      media: mx2_emmaprp: Correct return type for mem2mem buffer helpers · 745cdc34
      Ezequiel Garcia 提交于
      [ Upstream commit 8d20dcefe471763f23ad538369ec65b51993ffff ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      745cdc34
    • E
      media: s5p-g2d: Correct return type for mem2mem buffer helpers · 73a4cc59
      Ezequiel Garcia 提交于
      [ Upstream commit 30fa627b32230737bc3f678067e2adfecf956987 ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      73a4cc59
    • E
      media: rockchip/rga: Correct return type for mem2mem buffer helpers · 3c6cd079
      Ezequiel Garcia 提交于
      [ Upstream commit da2d3a4e4adabc6ccfb100bc9abd58ee9cd6c4b7 ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3c6cd079
    • E
      media: s5p-jpeg: Correct return type for mem2mem buffer helpers · 55919fc2
      Ezequiel Garcia 提交于
      [ Upstream commit 4a88f89885c7cf65c62793f385261a6e3315178a ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      55919fc2
    • E
      media: sh_veu: Correct return type for mem2mem buffer helpers · a23fd268
      Ezequiel Garcia 提交于
      [ Upstream commit 43c145195c7fc3025ee7ecfc67112ac1c82af7c2 ]
      
      Fix the assigned type of mem2mem buffer handling API.
      Namely, these functions:
      
       v4l2_m2m_next_buf
       v4l2_m2m_last_buf
       v4l2_m2m_buf_remove
       v4l2_m2m_next_src_buf
       v4l2_m2m_next_dst_buf
       v4l2_m2m_last_src_buf
       v4l2_m2m_last_dst_buf
       v4l2_m2m_src_buf_remove
       v4l2_m2m_dst_buf_remove
      
      return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
      
      Fixing this is necessary to fix the mem2mem buffer handling API,
      changing the return to the correct struct vb2_v4l2_buffer instead
      of a void pointer.
      Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a23fd268
    • A
      media: ov7740: fix runtime pm initialization · 635fabdd
      Akinobu Mita 提交于
      [ Upstream commit 12aceee1f412c3ddc7750155fec06c906f14ab51 ]
      
      The runtime PM of this device is enabled after v4l2_ctrl_handler_setup(),
      and this makes this device's runtime PM usage count a negative value.
      
      The ov7740_set_ctrl() tries to do something only if the device's runtime
      PM usage counter is nonzero.
      
      ov7740_set_ctrl()
      {
      	if (!pm_runtime_get_if_in_use(&client->dev))
      		return 0;
      
      	<do something>;
      
      	pm_runtime_put(&client->dev);
      
      	return ret;
      }
      
      However, the ov7740_set_ctrl() is called by v4l2_ctrl_handler_setup()
      while the runtime PM of this device is not yet enabled.  In this case,
      the pm_runtime_get_if_in_use() returns -EINVAL (!= 0).
      
      Therefore we can't bail out of this function and the usage count is
      decreased by pm_runtime_put() without increment.
      
      This fixes this problem by enabling the runtime PM of this device before
      v4l2_ctrl_handler_setup() so that the ov7740_set_ctrl() is always called
      when the runtime PM is enabled.
      
      Cc: Wenyou Yang <wenyou.yang@microchip.com>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Tested-by: NEugen Hristev <eugen.hristev@microchip.com>
      Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      635fabdd
    • B
      mwifiex: don't advertise IBSS features without FW support · 801b8d8c
      Brian Norris 提交于
      [ Upstream commit 6f21ab30469d670de620f758330aca9f3433f693 ]
      
      As it is, doing something like
      
        # iw phy phy0 interface add foobar type ibss
      
      on a firmware that doesn't have ad-hoc support just yields failures of
      HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code
      (-EPERM? not really right...) and sometimes may even crash the firmware
      along the way.
      
      Let's parse the firmware capability flag while registering the wiphy, so
      we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP
      from nl80211 instead.
      
      Fixes: e267e71e ("mwifiex: Disable adhoc feature based on firmware capability")
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      801b8d8c
    • N
      drm/amd/display: Clear stream->mode_changed after commit · 345c7757
      Nicholas Kazlauskas 提交于
      [ Upstream commit d8d2f174bcc2c26c3485c70e0c6fe22b27bce739 ]
      
      [Why]
      The stream->mode_changed flag can persist in the following sequence
      of atomic commits:
      
      Commit 1:
      Enable CRTC0 (mode_changed = true), Enable CRTC1 (mode_changed = true)
      
      Commit 2:
      Disable CRTC1 (mode_changed = false)
      
      In this sequence we want to keep the exiting CRTC0 but it's not in the
      atomic state for the commit since it hasn't been modified. In this case
      the stream->mode_changed flag persists as true and we don't re-program
      the planes for the existing stream.
      
      [How]
      The flag needs to be cleared and it makes the most sense to do it within
      DC after the state has been committed. Nothing following dc_commit_state
      should think that the stream's mode has changed.
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: NLeo Li <sunpeng.li@amd.com>
      Acked-by: NTony Cheng <Tony.Cheng@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      345c7757
    • S
      scsi: fcoe: make use of fip_mode enum complete · 1ef1b20f
      Sedat Dilek 提交于
      [ Upstream commit 8beb90aaf334a6efa3e924339926b5f93a234dbb ]
      
      commit 1917d42d ("fcoe: use enum for fip_mode") introduces a separate
      enum for the fip_mode that shall be used during initialisation handling
      until it is passed to fcoe_ctrl_link_up to set the initial fip_state.  That
      change was incomplete and gcc quietly converted in various places between
      the fip_mode and the fip_state enum values with implicit enum conversions,
      which fortunately cannot cause any issues in the actual code's execution.
      
      clang however warns about these implicit enum conversions in the scsi
      drivers. This commit consolidates the use of the two enums, guided by
      clang's enum-conversion warnings.
      
      This commit now completes the use of the fip_mode: It expects and uses
      fip_mode in {bnx2fc,fcoe}_interface_create and fcoe_ctlr_init, and it calls
      fcoe_ctrl_set_set() with the correct values in fcoe_ctlr_link_up().  It
      also breaks the association between FIP_MODE_AUTO and FIP_ST_AUTO to
      indicate these two enums are distinct.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/151
      Fixes: 1917d42d ("fcoe: use enum for fip_mode")
      Reported-by: NDmitry Golovin <dima@golovin.in>
      Original-by: NLukas Bulwahn <lukas.bulwahn@gmail.com>
      CC: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      CC: Nick Desaulniers <ndesaulniers@google.com>
      CC: Nathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Tested-by: NNathan Chancellor <natechancellor@gmail.com>
      Suggested-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: NHannes Reinecke <hare@suse.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1ef1b20f
    • J
      scsi: megaraid_sas: return error when create DMA pool failed · 8032fc91
      Jason Yan 提交于
      [ Upstream commit bcf3b67d16a4c8ffae0aa79de5853435e683945c ]
      
      when create DMA pool for cmd frames failed, we should return -ENOMEM,
      instead of 0.
      In some case in:
      
          megasas_init_adapter_fusion()
      
          -->megasas_alloc_cmds()
             -->megasas_create_frame_pool
                create DMA pool failed,
              --> megasas_free_cmds() [1]
      
          -->megasas_alloc_cmds_fusion()
             failed, then goto fail_alloc_cmds.
          -->megasas_free_cmds() [2]
      
      we will call megasas_free_cmds twice, [1] will kfree cmd_list,
      [2] will use cmd_list.it will cause a problem:
      
      Unable to handle kernel NULL pointer dereference at virtual address
      00000000
      pgd = ffffffc000f70000
      [00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003,
      *pmd=0000001fbf894003, *pte=006000006d000707
      Internal error: Oops: 96000005 [#1] SMP
       Modules linked in:
       CPU: 18 PID: 1 Comm: swapper/0 Not tainted
       task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000
       PC is at megasas_free_cmds+0x30/0x70
       LR is at megasas_free_cmds+0x24/0x70
       ...
       Call trace:
       [<ffffffc0005b779c>] megasas_free_cmds+0x30/0x70
       [<ffffffc0005bca74>] megasas_init_adapter_fusion+0x2f4/0x4d8
       [<ffffffc0005b926c>] megasas_init_fw+0x2dc/0x760
       [<ffffffc0005b9ab0>] megasas_probe_one+0x3c0/0xcd8
       [<ffffffc0004a5abc>] local_pci_probe+0x4c/0xb4
       [<ffffffc0004a5c40>] pci_device_probe+0x11c/0x14c
       [<ffffffc00053a5e4>] driver_probe_device+0x1ec/0x430
       [<ffffffc00053a92c>] __driver_attach+0xa8/0xb0
       [<ffffffc000538178>] bus_for_each_dev+0x74/0xc8
        [<ffffffc000539e88>] driver_attach+0x28/0x34
       [<ffffffc000539a18>] bus_add_driver+0x16c/0x248
       [<ffffffc00053b234>] driver_register+0x6c/0x138
       [<ffffffc0004a5350>] __pci_register_driver+0x5c/0x6c
       [<ffffffc000ce3868>] megasas_init+0xc0/0x1a8
       [<ffffffc000082a58>] do_one_initcall+0xe8/0x1ec
       [<ffffffc000ca7be8>] kernel_init_freeable+0x1c8/0x284
       [<ffffffc0008d90b8>] kernel_init+0x1c/0xe4
      Signed-off-by: NJason Yan <yanaijie@huawei.com>
      Acked-by: NSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8032fc91
    • S
      s390/ism: ignore some errors during deregistration · 2c6e3ec8
      Sebastian Ott 提交于
      [ Upstream commit 0ff06c44efeede4acd068847d3bf8cf894b6c664 ]
      
      Prior to dma unmap/free operations the ism driver tries to ensure
      that the memory is no longer accessed by the HW. When errors
      during deregistration of memory regions from the HW occur the ism
      driver will not unmap/free this memory.
      
      When we receive notification from the hypervisor that a PCI function
      has been detached we can no longer access the device and would never
      unmap/free these memory regions which led to complaints by the DMA
      debug API.
      
      Treat this kind of errors during the deregistration of memory regions
      from the HW as success since it is already ensured that the memory
      is no longer accessed by HW.
      Reported-by: NKarsten Graul <kgraul@linux.ibm.com>
      Reported-by: NHans Wippel <hwippel@linux.ibm.com>
      Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2c6e3ec8
    • R
      efi: cper: Fix possible out-of-bounds access · d60f458e
      Ross Lagerwall 提交于
      [ Upstream commit 45b14a4ffcc1e0b5caa246638f942cbe7eaea7ad ]
      
      When checking a generic status block, we iterate over all the generic
      data blocks. The loop condition only checks that the start of the
      generic data block is valid (within estatus->data_length) but not the
      whole block. Because the size of data blocks (excluding error data) may
      vary depending on the revision and the revision is contained within the
      data block, ensure that enough of the current data block is valid before
      dereferencing any members otherwise an out-of-bounds access may occur if
      estatus->data_length is invalid.
      
      This relies on the fact that struct acpi_hest_generic_data_v300 is a
      superset of the earlier version.  Also rework the other checks to avoid
      potential underflow.
      Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Tested-by: NTyler Baicar <baicar.tyler@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d60f458e