1. 19 12月, 2017 2 次提交
  2. 17 12月, 2017 2 次提交
  3. 16 12月, 2017 15 次提交
  4. 15 12月, 2017 4 次提交
    • Y
      mlxsw: spectrum: Disable MAC learning for ovs port · fccff086
      Yuval Mintz 提交于
      Learning is currently enabled for ports which are OVS slaves -
      even though OVS doesn't need this indication.
      Since we're not associating a fid with the port, HW would continuously
      notify driver of learned [& aged] MACs which would be logged as errors.
      
      Fixes: 2b94e58d ("mlxsw: spectrum: Allow ports to work under OVS master")
      Signed-off-by: NYuval Mintz <yuvalm@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fccff086
    • A
      dmaengine: fsl-edma: disable clks on all error paths · 2610acf4
      Andreas Platschek 提交于
      Previously enabled clks are only disabled if clk_prepare_enable() fails.
      However, there are other error paths were the previously enabled
      clocks are not disabled.
      
      To fix the problem, fsl_disable_clocks() now takes the number of clocks
      that shall be disabled + unprepared. For existing calls were all clocks
      were already successfully prepared + enabled, DMAMUX_NR is passed to
      disable + unprepare all clocks.
      
      In error paths were only some clocks were successfully prepared +
      enabled the loop counter is passed, in order to disable + unprepare
      all successfully prepared + enabled clocks.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: NAndreas Platschek <andreas.platschek@opentech.at>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      2610acf4
    • C
      lib/rbtree,drm/mm: add rbtree_replace_node_cached() · 338f1d9d
      Chris Wilson 提交于
      Add a variant of rbtree_replace_node() that maintains the leftmost cache
      of struct rbtree_root_cached when replacing nodes within the rbtree.
      
      As drm_mm is the only rb_replace_node() being used on an interval tree,
      the mistake looks fairly self-contained.  Furthermore the only user of
      drm_mm_replace_node() is its testsuite...
      
      Testcase: igt/drm_mm/replace
      
      Link: http://lkml.kernel.org/r/20171122100729.3742-1-chris@chris-wilson.co.uk
      Link: https://patchwork.freedesktop.org/patch/msgid/20171109212435.9265-1-chris@chris-wilson.co.uk
      Fixes: f808c13f ("lib/interval_tree: fast overlap detection")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Acked-by: NDavidlohr Bueso <dbueso@suse.de>
      Cc: Jérôme Glisse <jglisse@redhat.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      338f1d9d
    • M
      virtio_mmio: fix devm cleanup · c2e90800
      Mark Rutland 提交于
      Recent rework of the virtio_mmio probe/remove paths balanced a
      devm_ioremap() with an iounmap() rather than its devm variant. This ends
      up corrupting the devm datastructures, and results in the following
      boot-time splat on arm64 under QEMU 2.9.0:
      
      [    3.450397] ------------[ cut here ]------------
      [    3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844)
      [    3.460534] WARNING: CPU: 1 PID: 1 at mm/vmalloc.c:1525 __vunmap+0x1b8/0x220
      [    3.475898] Kernel panic - not syncing: panic_on_warn set ...
      [    3.475898]
      [    3.493933] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc3 #1
      [    3.513109] Hardware name: linux,dummy-virt (DT)
      [    3.525382] Call trace:
      [    3.531683]  dump_backtrace+0x0/0x368
      [    3.543921]  show_stack+0x20/0x30
      [    3.547767]  dump_stack+0x108/0x164
      [    3.559584]  panic+0x25c/0x51c
      [    3.569184]  __warn+0x29c/0x31c
      [    3.576023]  report_bug+0x1d4/0x290
      [    3.586069]  bug_handler.part.2+0x40/0x100
      [    3.597820]  bug_handler+0x4c/0x88
      [    3.608400]  brk_handler+0x11c/0x218
      [    3.613430]  do_debug_exception+0xe8/0x318
      [    3.627370]  el1_dbg+0x18/0x78
      [    3.634037]  __vunmap+0x1b8/0x220
      [    3.648747]  vunmap+0x6c/0xc0
      [    3.653864]  __iounmap+0x44/0x58
      [    3.659771]  devm_ioremap_release+0x34/0x68
      [    3.672983]  release_nodes+0x404/0x880
      [    3.683543]  devres_release_all+0x6c/0xe8
      [    3.695692]  driver_probe_device+0x250/0x828
      [    3.706187]  __driver_attach+0x190/0x210
      [    3.717645]  bus_for_each_dev+0x14c/0x1f0
      [    3.728633]  driver_attach+0x48/0x78
      [    3.740249]  bus_add_driver+0x26c/0x5b8
      [    3.752248]  driver_register+0x16c/0x398
      [    3.757211]  __platform_driver_register+0xd8/0x128
      [    3.770860]  virtio_mmio_init+0x1c/0x24
      [    3.782671]  do_one_initcall+0xe0/0x398
      [    3.791890]  kernel_init_freeable+0x594/0x660
      [    3.798514]  kernel_init+0x18/0x190
      [    3.810220]  ret_from_fork+0x10/0x18
      
      To fix this, we can simply rip out the explicit cleanup that the devm
      infrastructure will do for us when our probe function returns an error
      code, or when our remove function returns.
      
      We only need to ensure that we call put_device() if a call to
      register_virtio_device() fails in the probe path.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Fixes: 7eb781b1 ("virtio_mmio: add cleanup for virtio_mmio_probe")
      Fixes: 25f32223 ("virtio_mmio: add cleanup for virtio_mmio_remove")
      Cc: Cornelia Huck <cohuck@redhat.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: weiping zhang <zhangweiping@didichuxing.com>
      Cc: virtualization@lists.linux-foundation.org
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NCornelia Huck <cohuck@redhat.com>
      c2e90800
  5. 14 12月, 2017 16 次提交
  6. 13 12月, 2017 1 次提交
    • K
      drm: Update edid-derived drm_display_info fields at edid property set [v2] · 4b4df570
      Keith Packard 提交于
      There are a set of values in the drm_display_info structure for each
      connector which hold information derived from EDID. These are computed
      in drm_add_display_info. Before this patch, that was only called in
      drm_add_edid_modes. This meant that they were only set when EDID was
      present and never reset when EDID was not, as happened when the
      display was disconnected.
      
      One of these fields, non_desktop, is used from
      drm_mode_connector_update_edid_property, the function responsible for
      assigning the new edid value to the application-visible property.
      
      Various drivers call these two functions (drm_add_edid_modes and
      drm_mode_connector_update_edid_property) in different orders. This
      means that even when EDID is present, the drm_display_info fields may
      not have been computed at the time that
      drm_mode_connector_update_edid_property used the non_desktop value to
      set the non_desktop property.
      
      I've added a public function (drm_reset_display_info) that resets the
      drm_display_info field values to default values and then made the
      drm_add_display_info function public. These two functions are now
      called directly from drm_mode_connector_update_edid_property so that
      the drm_display_info fields are always computed from the current EDID
      information before being used in that function.
      
      This means that the drm_display_info values are often computed twice,
      once when the EDID property it set and a second time when EDID is used
      to compute modes for the device. The alternative would be to uniformly
      ensure that the values were computed once before being used, which
      would require that all drivers reliably invoke the two paths in the
      same order. The computation is inexpensive enough that it seems more
      maintainable in the long term to simply compute them in both paths.
      
      The API to drm_add_display_info has been changed so that it no longer
      takes the set of edid-based quirks as a parameter. Rather, it now
      computes those quirks itself and returns them for further use by
      drm_add_edid_modes.
      
      This patch also includes a number of 'const' additions caused by
      drm_mode_connector_update_edid_property taking a 'const struct edid *'
      parameter and wanting to pass that along to drm_add_display_info.
      
      v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch>
      
      	Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and
      	drm_add_display_info.
      
      	Added FIXME in drm_mode_connector_update_edid_property about
      	potentially merging that with drm_add_edid_modes to avoid
      	the need for two driver calls.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213084427.31199-1-keithp@keithp.com
      (danvet: cherry picked from commit 12a889bf4bca ("drm: rework delayed
      connector cleanup in connector_iter") from drm-misc-next since
      functional conflict with changes in -next and we need to make sure
      both have the right version and nothing gets lost.)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4b4df570