1. 04 11月, 2020 1 次提交
  2. 03 11月, 2020 4 次提交
  3. 02 11月, 2020 6 次提交
    • J
      drm: Remove SCATTERLIST_MAX_SEGMENT · 7a60c2dd
      Jason Gunthorpe 提交于
      Since commit 9a40401c ("lib/scatterlist: Do not limit max_segment to
      PAGE_ALIGNED values") the max_segment input to sg_alloc_table_from_pages()
      does not have to be any special value. The new algorithm will always
      create something less than what the user provides. Thus eliminate this
      confusing constant.
      
      - vmwgfx should use the HW capability, not mix in the OS page size for
        calling dma_set_max_seg_size()
      
      - i915 uses i915_sg_segment_size() both for sg_alloc_table_from_pages
        and for some open coded sgl construction. This doesn't change the value
        since rounddown(size, UINT_MAX) == SCATTERLIST_MAX_SEGMENT
      
      - drm_prime_pages_to_sg uses it as a default if max_segment is zero,
        UINT_MAX is fine to use directly.
      
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Cc: Qian Cai <cai@lca.pw>
      Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
      Suggested-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/0-v1-44733fccd781+13d-rm_scatterlist_max_jgg@nvidia.com
      7a60c2dd
    • B
      gpu/drm: delete same check in if condition · 95d7a1a6
      Bernard Zhao 提交于
      In function drm_bridge_connector_get_modes_edid, drm_edid_is_valid
      will check weather (!edid), no need to check again in the if
      branch.
      Signed-off-by: NBernard Zhao <bernard@vivo.com>
      Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201102030736.3833-1-bernard@vivo.com
      95d7a1a6
    • K
      drm/ast: Support 1600x900 with 108MHz PCLK · 9bb7b689
      KuoHsiang Chou 提交于
      [New] Create the setting for 1600x900 @60Hz refresh rate
            by 108MHz pixel-clock.
      Signed-off-by: NKuoHsiang Chou <kuohsiang_chou@aspeedtech.com>
      Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201030074212.22401-1-kuohsiang_chou@aspeedtech.com
      9bb7b689
    • M
      drm/atomic: Pass the full state to CRTC atomic begin and flush · f6ebe9f9
      Maxime Ripard 提交于
      The current atomic helpers have either their object state being passed as
      an argument or the full atomic state.
      
      The former is the pattern that was done at first, before switching to the
      latter for new hooks or when it was needed.
      
      Let's start convert all the remaining helpers to provide a consistent
      interface, starting with the CRTC's atomic_begin and atomic_flush.
      
      The conversion was done using the coccinelle script below, built tested on
      all the drivers and actually tested on vc4.
      
      virtual report
      
      @@
      struct drm_crtc_helper_funcs *FUNCS;
      identifier old_crtc_state, old_state;
      identifier crtc;
      identifier f;
      @@
      
       f(struct drm_crtc_state *old_crtc_state)
       {
      	...
       	struct drm_atomic_state *old_state = old_crtc_state->state;
      	<...
      -	FUNCS->atomic_begin(crtc, old_crtc_state);
      +	FUNCS->atomic_begin(crtc, old_state);
      	...>
       }
      
      @@
      struct drm_crtc_helper_funcs *FUNCS;
      identifier old_crtc_state, old_state;
      identifier crtc;
      identifier f;
      @@
      
       f(struct drm_crtc_state *old_crtc_state)
       {
      	...
       	struct drm_atomic_state *old_state = old_crtc_state->state;
      	<...
      -	FUNCS->atomic_flush(crtc, old_crtc_state);
      +	FUNCS->atomic_flush(crtc, old_state);
      	...>
       }
      
      @@
      struct drm_crtc_helper_funcs *FUNCS;
      struct drm_crtc *crtc;
      struct drm_crtc_state *crtc_state;
      identifier dev, state;
      identifier f;
      @@
      
       f(struct drm_device *dev, struct drm_atomic_state *state, ...)
       {
      	<...
      -	FUNCS->atomic_begin(crtc, crtc_state);
      +	FUNCS->atomic_begin(crtc, state);
      	...>
       }
      
      @@
      struct drm_crtc_helper_funcs *FUNCS;
      struct drm_crtc *crtc;
      struct drm_crtc_state *crtc_state;
      identifier dev, state;
      identifier f;
      @@
      
       f(struct drm_device *dev, struct drm_atomic_state *state, ...)
       {
      	<...
      -	FUNCS->atomic_flush(crtc, crtc_state);
      +	FUNCS->atomic_flush(crtc, state);
      	...>
       }
      
      @@
      identifier crtc, old_state;
      @@
      
       struct drm_crtc_helper_funcs {
      	...
      -	void (*atomic_begin)(struct drm_crtc *crtc, struct drm_crtc_state *old_state);
      +	void (*atomic_begin)(struct drm_crtc *crtc, struct drm_atomic_state *state);
      	...
      -	void (*atomic_flush)(struct drm_crtc *crtc, struct drm_crtc_state *old_state);
      +	void (*atomic_flush)(struct drm_crtc *crtc, struct drm_atomic_state *state);
      	...
      }
      
      @ crtc_atomic_func @
      identifier helpers;
      identifier func;
      @@
      
      (
      static struct drm_crtc_helper_funcs helpers = {
      	...,
      	.atomic_begin = func,
      	...,
      };
      |
      static struct drm_crtc_helper_funcs helpers = {
      	...,
      	.atomic_flush = func,
      	...,
      };
      )
      
      @ ignores_old_state @
      identifier crtc_atomic_func.func;
      identifier crtc, old_state;
      @@
      
      void func(struct drm_crtc *crtc,
      		struct drm_crtc_state *old_state)
      {
      	... when != old_state
      }
      
      @ adds_old_state depends on crtc_atomic_func && !ignores_old_state @
      identifier crtc_atomic_func.func;
      identifier crtc, old_state;
      @@
      
      void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
      {
      +	struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, crtc);
      	...
      }
      
      @ depends on crtc_atomic_func @
      identifier crtc_atomic_func.func;
      expression E;
      type T;
      @@
      
      void func(...)
      {
      	...
      -	T state = E;
      +	T crtc_state = E;
      	<+...
      -	state
      +	crtc_state
      	...+>
      
      }
      
      @ depends on crtc_atomic_func @
      identifier crtc_atomic_func.func;
      type T;
      @@
      
      void func(...)
      {
      	...
      -	T state;
      +	T crtc_state;
      	<+...
      -	state
      +	crtc_state
      	...+>
      
      }
      
      @@
      identifier old_state;
      identifier crtc;
      @@
      
       void vc4_hvs_atomic_flush(struct drm_crtc *crtc,
      -			   struct drm_crtc_state *old_state
      +			   struct drm_atomic_state *state
      			   )
      {
      +	struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, crtc);
      	...
      }
      
      @@
      identifier old_state;
      identifier crtc;
      @@
      
       void vc4_hvs_atomic_flush(struct drm_crtc *crtc,
      -			   struct drm_crtc_state *old_state
      +			   struct drm_atomic_state *state
      			   );
      
      @@
      identifier old_state;
      identifier crtc;
      @@
      
       void vmw_du_crtc_atomic_begin(struct drm_crtc *crtc,
      -			   struct drm_crtc_state *old_state
      +			   struct drm_atomic_state *state
      			   )
      {
      	...
      }
      
      @@
      identifier old_state;
      identifier crtc;
      @@
      
       void vmw_du_crtc_atomic_begin(struct drm_crtc *crtc,
      -			   struct drm_crtc_state *old_state
      +			   struct drm_atomic_state *state
      			   );
      
      @@
      identifier old_state;
      identifier crtc;
      @@
      
       void vmw_du_crtc_atomic_flush(struct drm_crtc *crtc,
      -			   struct drm_crtc_state *old_state
      +			   struct drm_atomic_state *state
      			   )
      {
      	...
      }
      
      @@
      identifier old_state;
      identifier crtc;
      @@
      
       void vmw_du_crtc_atomic_flush(struct drm_crtc *crtc,
      -			   struct drm_crtc_state *old_state
      +			   struct drm_atomic_state *state
      			   );
      
      @ depends on crtc_atomic_func @
      identifier crtc_atomic_func.func;
      identifier old_state;
      identifier crtc;
      @@
      
      void func(struct drm_crtc *crtc,
      -	       struct drm_crtc_state *old_state
      +	       struct drm_atomic_state *state
      	       )
      		{ ... }
      
      @ include depends on adds_old_state @
      @@
      
       #include <drm/drm_atomic.h>
      
      @ no_include depends on !include && adds_old_state @
      @@
      
      + #include <drm/drm_atomic.h>
        #include <drm/...>
      Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201028123222.1732139-2-maxime@cerno.tech
      f6ebe9f9
    • M
      drm/atomic: Pass the full state to CRTC atomic_check · 29b77ad7
      Maxime Ripard 提交于
      The current atomic helpers have either their object state being passed as
      an argument or the full atomic state.
      
      The former is the pattern that was done at first, before switching to the
      latter for new hooks or when it was needed.
      
      Let's start convert all the remaining helpers to provide a consistent
      interface, starting with the CRTC's atomic_check.
      
      The conversion was done using the coccinelle script below,
      built tested on all the drivers and actually tested on vc4.
      
      virtual report
      
      @@
      struct drm_crtc_helper_funcs *FUNCS;
      struct drm_crtc *crtc;
      struct drm_crtc_state *crtc_state;
      identifier dev, state;
      identifier ret, f;
      @@
      
       f(struct drm_device *dev, struct drm_atomic_state *state)
       {
      	<...
      -	ret = FUNCS->atomic_check(crtc, crtc_state);
      +	ret = FUNCS->atomic_check(crtc, state);
      	...>
       }
      
      @@
      identifier crtc, new_state;
      @@
      
       struct drm_crtc_helper_funcs {
       	...
      -	int (*atomic_check)(struct drm_crtc *crtc, struct drm_crtc_state *new_state);
      +	int (*atomic_check)(struct drm_crtc *crtc, struct drm_atomic_state *state);
       	...
      }
      
      @ crtc_atomic_func @
      identifier helpers;
      identifier func;
      @@
      
      static struct drm_crtc_helper_funcs helpers = {
      	...,
      	.atomic_check = func,
      	...,
      };
      
      @ ignores_new_state @
      identifier crtc_atomic_func.func;
      identifier crtc, new_state;
      @@
      
       int func(struct drm_crtc *crtc,
      		struct drm_crtc_state *new_state)
       {
      	... when != new_state
       }
      
      @ adds_new_state depends on crtc_atomic_func && !ignores_new_state @
      identifier crtc_atomic_func.func;
      identifier crtc, new_state;
      @@
      
       int func(struct drm_crtc *crtc, struct drm_crtc_state *new_state)
       {
      +	struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc);
       	...
       }
      
      @ depends on crtc_atomic_func @
      identifier crtc_atomic_func.func;
      expression E;
      type T;
      @@
      
       int func(...)
       {
      	...
      -	T state = E;
      +	T crtc_state = E;
       	<+...
      -	state
      +	crtc_state
       	...+>
       }
      
      @ depends on crtc_atomic_func @
      identifier crtc_atomic_func.func;
      type T;
      @@
      
       int func(...)
       {
       	...
      -	T state;
      +	T crtc_state;
       	<+...
      -	state
      +	crtc_state
       	...+>
       }
      
      @ depends on crtc_atomic_func @
      identifier crtc_atomic_func.func;
      identifier new_state;
      identifier crtc;
      @@
      
       int func(struct drm_crtc *crtc,
      -	       struct drm_crtc_state *new_state
      +	       struct drm_atomic_state *state
      	       )
       { ... }
      
      @@
      identifier new_state;
      identifier crtc;
      @@
      
       int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
      -                             struct drm_crtc_state *new_state
      +                             struct drm_atomic_state *state
                     )
       {
      +       struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc);
      	...
       }
      
      @@
      identifier new_state;
      identifier crtc;
      @@
      
       int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
      -                             struct drm_crtc_state *new_state
      +                             struct drm_atomic_state *state
                     );
      
      @ include depends on adds_new_state @
      @@
      
       #include <drm/drm_atomic.h>
      
      @ no_include depends on !include && adds_new_state @
      @@
      
      + #include <drm/drm_atomic.h>
        #include <drm/...>
      Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201028123222.1732139-1-maxime@cerno.tech
      29b77ad7
    • M
      drm/nouveau/ttm: Add limits.h · 95f4f40a
      Maxime Ripard 提交于
      It seems that a recent commit broke the nouveau compilation when swiotlb is
      disabled (which is the case on our ARM defconfig for example).
      
      Daniel says
      
      """
      Since the proper fix is maybe stuck in the usual "drm abuses swiotlb
      internals" bikeshed, maybe best if we push a fix to including limits.h
      in nouveau and call it done?
      """
      
      So let's go down the simplest path to fix our build, and goes back to it
      later if needed.
      
      Link: https://patchwork.freedesktop.org/patch/397835/
      Fixes: 4dbafbd3 ("drm/nouveu: fix swiotlb include")
      Acked-by: NDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
      95f4f40a
  4. 01 11月, 2020 1 次提交
  5. 31 10月, 2020 1 次提交
  6. 02 11月, 2020 1 次提交
  7. 31 10月, 2020 3 次提交
  8. 30 10月, 2020 23 次提交
    • S
      drm/panfrost: Don't corrupt the queue mutex on open/close · a17d609e
      Steven Price 提交于
      The mutex within the panfrost_queue_state should have the lifetime of
      the queue, however it was erroneously initialised/destroyed during
      panfrost_job_{open,close} which is called every time a client
      opens/closes the drm node.
      
      Move the initialisation/destruction to panfrost_job_{init,fini} where it
      belongs.
      
      Fixes: 1a11a88c ("drm/panfrost: Fix job timeout handling")
      Signed-off-by: NSteven Price <steven.price@arm.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201029170047.30564-1-steven.price@arm.com
      a17d609e
    • R
      drm/panfrost: Support cache-coherent integrations · 268af50f
      Robin Murphy 提交于
      When the GPU's ACE-Lite interface is fully wired up and capable of
      snooping CPU caches, it may be described as "dma-coherent" in
      devicetree, which will already inform the DMA layer not to perform
      unnecessary cache maintenance. However, we still need to ensure that
      the GPU uses the appropriate cacheable outer-shareable attributes in
      order to generate the requisite snoop signals, and that CPU mappings
      don't create a mismatch by using a non-cacheable type either.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/7024ce18c1cb1a226e918037d49175571db0b436.1600780574.git.robin.murphy@arm.com
      268af50f
    • R
      iommu/io-pgtable-arm: Support coherency for Mali LPAE · 728da60d
      Robin Murphy 提交于
      Midgard GPUs have ACE-Lite master interfaces which allows systems to
      integrate them in an I/O-coherent manner. It seems that from the GPU's
      viewpoint, the rest of the system is its outer shareable domain, and so
      even when snoop signals are wired up, they are only emitted for outer
      shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does
      indeed get coherent pagetable walks working nicely for the coherent
      T620 in the Arm Juno SoC.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Acked-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/8df778355378127ea7eccc9521d6427e3e48d4f2.1600780574.git.robin.murphy@arm.com
      728da60d
    • L
      vdpasim: allow to assign a MAC address · 0c86d774
      Laurent Vivier 提交于
      Add macaddr parameter to the module to set the MAC address to use
      Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
      Link: https://lore.kernel.org/r/20201029122050.776445-3-lvivier@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      0c86d774
    • L
      vdpasim: fix MAC address configuration · 4a6a42db
      Laurent Vivier 提交于
      vdpa_sim generates a ramdom MAC address but it is never used by upper
      layers because the VIRTIO_NET_F_MAC bit is not set in the features list.
      
      Because of that, virtio-net always regenerates a random MAC address each
      time it is loaded whereas the address should only change on vdpa_sim
      load/unload.
      
      Fix that by adding VIRTIO_NET_F_MAC in the features list of vdpa_sim.
      
      Fixes: 2c53d0f6 ("vdpasim: vDPA device simulator")
      Cc: jasowang@redhat.com
      Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
      Link: https://lore.kernel.org/r/20201029122050.776445-2-lvivier@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      4a6a42db
    • Z
      vdpa: handle irq bypass register failure case · e01afe36
      Zhu Lingshan 提交于
      LKP considered variable 'ret' in vhost_vdpa_setup_vq_irq() as
      a unused variable, so suggest we remove it. Actually it stores
      return value of irq_bypass_register_producer(), but we did not
      check it, we should handle the failure case.
      
      This commit will print a message if irq bypass register producer
      fail, in this case, vqs still remain functional.
      Signed-off-by: NZhu Lingshan <lingshan.zhu@intel.com>
      Reported-by: Nkernel test robot <lkp@intel.com>
      Link: https://lore.kernel.org/r/20201023104046.404794-1-lingshan.zhu@intel.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      e01afe36
    • L
      vdpa_sim: Fix DMA mask · 1eca16b2
      Laurent Vivier 提交于
      Since commit f959dcd6
      ("dma-direct: Fix potential NULL pointer dereference")
      an error is reported when we load vdpa_sim and virtio-vdpa:
      
      [  129.351207] net eth0: Unexpected TXQ (0) queue failure: -12
      
      It seems that dma_mask is not initialized.
      
      This patch initializes dma_mask() and calls dma_set_mask_and_coherent()
      to fix the problem.
      
      Full log:
      
      [  128.548628] ------------[ cut here ]------------
      [  128.553268] WARNING: CPU: 23 PID: 1105 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x14c/0x1d0
      [  128.562139] Modules linked in: virtio_net net_failover failover virtio_vdpa vdpa_sim vringh vhost_iotlb vdpa xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun bridge stp llc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rfkill intel_rapl_msr intel_rapl_common isst_if_common sunrpc skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm mgag200 i2c_algo_bit irqbypass drm_kms_helper crct10dif_pclmul crc32_pclmul syscopyarea ghash_clmulni_intel iTCO_wdt sysfillrect iTCO_vendor_support sysimgblt rapl fb_sys_fops dcdbas intel_cstate drm acpi_ipmi ipmi_si mei_me dell_smbios intel_uncore ipmi_devintf mei i2c_i801 dell_wmi_descriptor wmi_bmof pcspkr lpc_ich i2c_smbus ipmi_msghandler acpi_power_meter ip_tables xfs libcrc32c sd_mod t10_pi sg ahci libahci libata megaraid_sas tg3 crc32c_intel wmi dm_mirror dm_region_hash dm_log
      [  128.562188]  dm_mod
      [  128.651334] CPU: 23 PID: 1105 Comm: NetworkManager Tainted: G S        I       5.10.0-rc1+ #59
      [  128.659939] Hardware name: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.8.1 06/30/2020
      [  128.667419] RIP: 0010:dma_map_page_attrs+0x14c/0x1d0
      [  128.672384] Code: 1c 25 28 00 00 00 0f 85 97 00 00 00 48 83 c4 10 5b 5d 41 5c 41 5d c3 4c 89 da eb d7 48 89 f2 48 2b 50 18 48 89 d0 eb 8d 0f 0b <0f> 0b 48 c7 c0 ff ff ff ff eb c3 48 89 d9 48 8b 40 40 e8 2d a0 aa
      [  128.691131] RSP: 0018:ffffae0f0151f3c8 EFLAGS: 00010246
      [  128.696357] RAX: ffffffffc06b7400 RBX: 00000000000005fa RCX: 0000000000000000
      [  128.703488] RDX: 0000000000000040 RSI: ffffcee3c7861200 RDI: ffff9e2bc16cd000
      [  128.710620] RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
      [  128.717754] R10: 0000000000000002 R11: 0000000000000000 R12: ffff9e472cb291f8
      [  128.724886] R13: ffff9e2bc14da780 R14: ffff9e472bc20000 R15: ffff9e2bc1b14940
      [  128.732020] FS:  00007f887bae23c0(0000) GS:ffff9e4ac01c0000(0000) knlGS:0000000000000000
      [  128.740105] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  128.745852] CR2: 0000562bc09de998 CR3: 00000003c156c006 CR4: 00000000007706e0
      [  128.752982] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  128.760114] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  128.767247] PKRU: 55555554
      [  128.769961] Call Trace:
      [  128.772418]  virtqueue_add+0x81e/0xb00
      [  128.776176]  virtqueue_add_inbuf_ctx+0x26/0x30
      [  128.780625]  try_fill_recv+0x3a2/0x6e0 [virtio_net]
      [  128.785509]  virtnet_open+0xf9/0x180 [virtio_net]
      [  128.790217]  __dev_open+0xe8/0x180
      [  128.793620]  __dev_change_flags+0x1a7/0x210
      [  128.797808]  dev_change_flags+0x21/0x60
      [  128.801646]  do_setlink+0x328/0x10e0
      [  128.805227]  ? __nla_validate_parse+0x121/0x180
      [  128.809757]  ? __nla_parse+0x21/0x30
      [  128.813338]  ? inet6_validate_link_af+0x5c/0xf0
      [  128.817871]  ? cpumask_next+0x17/0x20
      [  128.821535]  ? __snmp6_fill_stats64.isra.54+0x6b/0x110
      [  128.826676]  ? __nla_validate_parse+0x47/0x180
      [  128.831120]  __rtnl_newlink+0x541/0x8e0
      [  128.834962]  ? __nla_reserve+0x38/0x50
      [  128.838713]  ? security_sock_rcv_skb+0x2a/0x40
      [  128.843158]  ? netlink_deliver_tap+0x2c/0x1e0
      [  128.847518]  ? netlink_attachskb+0x1d8/0x220
      [  128.851793]  ? skb_queue_tail+0x1b/0x50
      [  128.855641]  ? fib6_clean_node+0x43/0x170
      [  128.859652]  ? _cond_resched+0x15/0x30
      [  128.863406]  ? kmem_cache_alloc_trace+0x3a3/0x420
      [  128.868110]  rtnl_newlink+0x43/0x60
      [  128.871602]  rtnetlink_rcv_msg+0x12c/0x380
      [  128.875701]  ? rtnl_calcit.isra.39+0x110/0x110
      [  128.880147]  netlink_rcv_skb+0x50/0x100
      [  128.883987]  netlink_unicast+0x1a5/0x280
      [  128.887913]  netlink_sendmsg+0x23d/0x470
      [  128.891839]  sock_sendmsg+0x5b/0x60
      [  128.895331]  ____sys_sendmsg+0x1ef/0x260
      [  128.899255]  ? copy_msghdr_from_user+0x5c/0x90
      [  128.903702]  ___sys_sendmsg+0x7c/0xc0
      [  128.907369]  ? dev_forward_change+0x130/0x130
      [  128.911731]  ? sysctl_head_finish.part.29+0x24/0x40
      [  128.916616]  ? new_sync_write+0x11f/0x1b0
      [  128.920628]  ? mntput_no_expire+0x47/0x240
      [  128.924727]  __sys_sendmsg+0x57/0xa0
      [  128.928309]  do_syscall_64+0x33/0x40
      [  128.931887]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  128.936937] RIP: 0033:0x7f88792e3857
      [  128.940518] Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48
      [  128.959263] RSP: 002b:00007ffdca60dea0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
      [  128.966827] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f88792e3857
      [  128.973960] RDX: 0000000000000000 RSI: 00007ffdca60def0 RDI: 000000000000000c
      [  128.981095] RBP: 00007ffdca60def0 R08: 0000000000000000 R09: 0000000000000000
      [  128.988224] R10: 0000000000000001 R11: 0000000000000293 R12: 0000000000000000
      [  128.995357] R13: 0000000000000000 R14: 00007ffdca60e0a8 R15: 00007ffdca60e09c
      [  129.002492] CPU: 23 PID: 1105 Comm: NetworkManager Tainted: G S        I       5.10.0-rc1+ #59
      [  129.011093] Hardware name: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.8.1 06/30/2020
      [  129.018571] Call Trace:
      [  129.021027]  dump_stack+0x57/0x6a
      [  129.024346]  __warn.cold.14+0xe/0x3d
      [  129.027925]  ? dma_map_page_attrs+0x14c/0x1d0
      [  129.032283]  report_bug+0xbd/0xf0
      [  129.035602]  handle_bug+0x44/0x80
      [  129.038922]  exc_invalid_op+0x13/0x60
      [  129.042589]  asm_exc_invalid_op+0x12/0x20
      [  129.046602] RIP: 0010:dma_map_page_attrs+0x14c/0x1d0
      [  129.051566] Code: 1c 25 28 00 00 00 0f 85 97 00 00 00 48 83 c4 10 5b 5d 41 5c 41 5d c3 4c 89 da eb d7 48 89 f2 48 2b 50 18 48 89 d0 eb 8d 0f 0b <0f> 0b 48 c7 c0 ff ff ff ff eb c3 48 89 d9 48 8b 40 40 e8 2d a0 aa
      [  129.070311] RSP: 0018:ffffae0f0151f3c8 EFLAGS: 00010246
      [  129.075536] RAX: ffffffffc06b7400 RBX: 00000000000005fa RCX: 0000000000000000
      [  129.082669] RDX: 0000000000000040 RSI: ffffcee3c7861200 RDI: ffff9e2bc16cd000
      [  129.089803] RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
      [  129.096936] R10: 0000000000000002 R11: 0000000000000000 R12: ffff9e472cb291f8
      [  129.104068] R13: ffff9e2bc14da780 R14: ffff9e472bc20000 R15: ffff9e2bc1b14940
      [  129.111200]  virtqueue_add+0x81e/0xb00
      [  129.114952]  virtqueue_add_inbuf_ctx+0x26/0x30
      [  129.119399]  try_fill_recv+0x3a2/0x6e0 [virtio_net]
      [  129.124280]  virtnet_open+0xf9/0x180 [virtio_net]
      [  129.128984]  __dev_open+0xe8/0x180
      [  129.132390]  __dev_change_flags+0x1a7/0x210
      [  129.136575]  dev_change_flags+0x21/0x60
      [  129.140415]  do_setlink+0x328/0x10e0
      [  129.143994]  ? __nla_validate_parse+0x121/0x180
      [  129.148528]  ? __nla_parse+0x21/0x30
      [  129.152107]  ? inet6_validate_link_af+0x5c/0xf0
      [  129.156639]  ? cpumask_next+0x17/0x20
      [  129.160306]  ? __snmp6_fill_stats64.isra.54+0x6b/0x110
      [  129.165443]  ? __nla_validate_parse+0x47/0x180
      [  129.169890]  __rtnl_newlink+0x541/0x8e0
      [  129.173731]  ? __nla_reserve+0x38/0x50
      [  129.177483]  ? security_sock_rcv_skb+0x2a/0x40
      [  129.181928]  ? netlink_deliver_tap+0x2c/0x1e0
      [  129.186286]  ? netlink_attachskb+0x1d8/0x220
      [  129.190560]  ? skb_queue_tail+0x1b/0x50
      [  129.194401]  ? fib6_clean_node+0x43/0x170
      [  129.198411]  ? _cond_resched+0x15/0x30
      [  129.202163]  ? kmem_cache_alloc_trace+0x3a3/0x420
      [  129.206869]  rtnl_newlink+0x43/0x60
      [  129.210361]  rtnetlink_rcv_msg+0x12c/0x380
      [  129.214462]  ? rtnl_calcit.isra.39+0x110/0x110
      [  129.218908]  netlink_rcv_skb+0x50/0x100
      [  129.222747]  netlink_unicast+0x1a5/0x280
      [  129.226672]  netlink_sendmsg+0x23d/0x470
      [  129.230599]  sock_sendmsg+0x5b/0x60
      [  129.234090]  ____sys_sendmsg+0x1ef/0x260
      [  129.238015]  ? copy_msghdr_from_user+0x5c/0x90
      [  129.242461]  ___sys_sendmsg+0x7c/0xc0
      [  129.246128]  ? dev_forward_change+0x130/0x130
      [  129.250487]  ? sysctl_head_finish.part.29+0x24/0x40
      [  129.255368]  ? new_sync_write+0x11f/0x1b0
      [  129.259381]  ? mntput_no_expire+0x47/0x240
      [  129.263478]  __sys_sendmsg+0x57/0xa0
      [  129.267058]  do_syscall_64+0x33/0x40
      [  129.270639]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  129.275689] RIP: 0033:0x7f88792e3857
      [  129.279268] Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48
      [  129.298015] RSP: 002b:00007ffdca60dea0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
      [  129.305581] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f88792e3857
      [  129.312712] RDX: 0000000000000000 RSI: 00007ffdca60def0 RDI: 000000000000000c
      [  129.319846] RBP: 00007ffdca60def0 R08: 0000000000000000 R09: 0000000000000000
      [  129.326978] R10: 0000000000000001 R11: 0000000000000293 R12: 0000000000000000
      [  129.334109] R13: 0000000000000000 R14: 00007ffdca60e0a8 R15: 00007ffdca60e09c
      [  129.341249] ---[ end trace c551e8028fbaf59d ]---
      [  129.351207] net eth0: Unexpected TXQ (0) queue failure: -12
      [  129.360445] net eth0: Unexpected TXQ (0) queue failure: -12
      [  129.824428] net eth0: Unexpected TXQ (0) queue failure: -12
      
      Fixes: 2c53d0f6 ("vdpasim: vDPA device simulator")
      Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
      Link: https://lore.kernel.org/r/20201027175914.689278-1-lvivier@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Cc: stable@vger.kernel.org
      Acked-by: NJason Wang <jasowang@redhat.com>
      1eca16b2
    • M
      Revert "vhost-vdpa: fix page pinning leakage in error path" · 5e1a3149
      Michael S. Tsirkin 提交于
      This reverts commit 7ed9e3d9.
      
      The patch creates a DoS risk since it can result in a high order memory
      allocation.
      
      Fixes: 7ed9e3d9 ("vhost-vdpa: fix page pinning leakage in error path")
      Cc: stable@vger.kernel.org
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      5e1a3149
    • J
      vdpa/mlx5: Fix error return in map_direct_mr() · 7ba08e81
      Jing Xiangfeng 提交于
      Fix to return the variable "err" from the error handling case instead
      of "ret".
      
      Fixes: 94abbccd ("vdpa/mlx5: Add shared memory registration code")
      Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
      Link: https://lore.kernel.org/r/20201026070637.164321-1-jingxiangfeng@huawei.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NEli Cohen <elic@nvidia.com>
      Cc: stable@vger.kernel.org
      Acked-by: NJason Wang <jasowang@redhat.com>
      7ba08e81
    • D
      vhost_vdpa: Return -EFAULT if copy_from_user() fails · 7922460e
      Dan Carpenter 提交于
      The copy_to/from_user() functions return the number of bytes which we
      weren't able to copy but the ioctl should return -EFAULT if they fail.
      
      Fixes: a127c5bb ("vhost-vdpa: fix backend feature ioctls")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Link: https://lore.kernel.org/r/20201023120853.GI282278@mwandaSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Cc: stable@vger.kernel.org
      Acked-by: NJason Wang <jasowang@redhat.com>
      7922460e
    • P
      usb: cdns3: gadget: own the lock wrongly at the suspend routine · e11d2bf2
      Peter Chen 提交于
      When the system goes to suspend, if the controller is at device mode with
      cable connecting to host, the call stack is: cdns3_suspend->
      cdns3_gadget_suspend -> cdns3_disconnect_gadget, after cdns3_disconnect_gadget
      is called, it owns lock wrongly, it causes the system being deadlock after
      resume due to at cdns3_device_thread_irq_handler, it tries to get the lock,
      but can't get it forever.
      
      To fix it, we delete the unlock-lock operations at cdns3_disconnect_gadget,
      and do it at the caller.
      
      Fixes: b1234e3b ("usb: cdns3: add runtime PM support")
      Acked-by: NPawel Laszczak <pawell@cadence.com>
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      e11d2bf2
    • P
      usb: cdns3: Fix on-chip memory overflow issue · 52d39677
      Pawel Laszczak 提交于
      Patch fixes issue caused setting On-chip memory overflow bit in usb_sts
      register. The issue occurred because EP_CFG register was set twice
      before USB_STS.CFGSTS was set. Every write operation on EP_CFG.BUFFERING
      causes that controller increases internal counter holding the number
      of reserved on-chip buffers. First time this register was updated in
      function cdns3_ep_config before delegating SET_CONFIGURATION request
      to class driver and again it was updated when class wanted to enable
      endpoint.  This patch fixes this issue by configuring endpoints
      enabled by class driver in cdns3_gadget_ep_enable and others just
      before status stage.
      
      Cc: stable@vger.kernel.org#v5.8+
      Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
      Reported-and-tested-by: NPeter Chen <peter.chen@nxp.com>
      Signed-off-by: NPawel Laszczak <pawell@cadence.com>
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      52d39677
    • L
      drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid() · d7787cc0
      Lyude Paul 提交于
      While I thought I had this correct (since it actually did reject modes
      like I expected during testing), Ville Syrjala from Intel pointed out
      that the logic here isn't correct. max_clock refers to the max data rate
      supported by the DP encoder. So, limiting it to the output of ds_clock (which
      refers to the maximum dotclock of the downstream DP device) doesn't make any
      sense. Additionally, since we're using the connector's bpc as the canonical BPC
      we should use this in mode_valid until we support dynamically setting the bpp
      based on bandwidth constraints.
      
      https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html
      
      For more info.
      
      So, let's rewrite this using Ville's advice.
      
      v2:
      * Ville pointed out I mixed up the dotclock and the link rate. So fix that...
      * ...and also rename all the variables in this function to be more appropriately
        labeled so I stop mixing them up.
      * Reuse the bpp from the connector for now until we have dynamic bpp selection.
      * Use use DIV_ROUND_UP for calculating the mode rate like i915 does, which we
        should also have been doing from the start
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: 409d3813 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation")
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d7787cc0
    • L
      drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid() · 2d831155
      Lyude Paul 提交于
      Ville also pointed out that I got a lot of the logic here wrong as well, whoops.
      While I don't think anyone's likely using 3D output with nouveau, the next patch
      will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get
      rid of it and open-code it like before, while taking care to move the 3D frame
      packing calculations on the dot clock into the right place.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: d6a9efec ("drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST")
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v5.8+
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      2d831155
    • K
      drm/nouveau/device: fix changing endianess code to work on older GPUs · dcd292c1
      Karol Herbst 提交于
      With this we try to detect if the endianess switch works and assume LE if
      not. Suggested by Ben.
      
      Fixes: 51c05340 ("drm/nouveau/device: detect if changing endianness failed")
      Signed-off-by: NKarol Herbst <kherbst@redhat.com>
      Cc: <stable@vger.kernel.org> # v5.8+
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      dcd292c1
    • K
      drm/nouveau/gem: fix "refcount_t: underflow; use-after-free" · 92568145
      Karol Herbst 提交于
      we can't use nouveau_bo_ref here as no ttm object was allocated and
      nouveau_bo_ref mainly deals with that. Simply deallocate the object.
      Signed-off-by: NKarol Herbst <kherbst@redhat.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      92568145
    • L
      drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps · 24d9422e
      Lyude Paul 提交于
      Not entirely sure why this never came up when I originally tested this
      (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
      appears to cause the display engine to throw an exception on driver
      init, at least on my ThinkPad P72:
      
      nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
      
      This is magic nvidia speak for "You need to have the DMA notifier offset
      programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
      this by doing that, and also perform an update afterwards to prevent
      racing with the GPU when reading capabilities.
      
      v2:
      * Don't just program the DMA notifier offset, make sure to actually
        perform an update
      v3:
      * Don't call UPDATE()
      * Actually read the correct notifier fields, as apparently the
        CAPABILITIES_DONE field lives in a different location than the main
        NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different
        CAPABILITIES_DONE field then pre-907d cards.
      v4:
      * Don't forget to check the return value of core507d_read_caps()
      v5:
      * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY
      * Disable notifier after calling GetCapabilities()
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: 4a2cb418 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support")
      Cc: <stable@vger.kernel.org> # v5.8+
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      24d9422e
    • R
      drm/nouveau/nouveau: fix the start/end range for migration · cfa736f5
      Ralph Campbell 提交于
      The user level OpenCL code shouldn't have to align start and end
      addresses to a page boundary. That is better handled in the nouveau
      driver. The npages field is also redundant since it can be computed
      from the start and end addresses.
      Signed-off-by: NRalph Campbell <rcampbell@nvidia.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      cfa736f5
    • G
      scsi: target: tcmu: Replace zero-length array with flexible-array member · 8fdaabe1
      Gustavo A. R. Silva 提交于
      There is a regular need in the kernel to provide a way to declare having a
      dynamically sized set of trailing elements in a structure. Kernel code should
      always use “flexible array members”[1] for these cases. The older style of
      one-element or zero-length arrays should no longer be used[2].
      
      [1] https://en.wikipedia.org/wiki/Flexible_array_member
      [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      8fdaabe1
    • G
      enetc: Replace zero-length array with flexible-array member · bfe124d1
      Gustavo A. R. Silva 提交于
      There is a regular need in the kernel to provide a way to declare having a
      dynamically sized set of trailing elements in a structure. Kernel code should
      always use “flexible array members”[1] for these cases. The older style of
      one-element or zero-length arrays should no longer be used[2].
      
      [1] https://en.wikipedia.org/wiki/Flexible_array_member
      [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      bfe124d1
    • C
      drm: Quieten [zero] EDID carping · fa3bfa35
      Chris Wilson 提交于
      We have a few displays in CI that always report their EDID as a bunch of
      zeroes. This is consistent behaviour, so one assumes intentional
      indication of an "absent" EDID. Flagging these consistent warnings
      detracts from CI.
      
      One option would be to ignore the zero EDIDs as intentional behaviour,
      but Ville would like to keep the information available for debugging.
      The simple alternative then is to reduce the loglevel for all the EDID
      dumping from WARN to DEBUG so the information is present but not annoy
      CI. Note that the bad EDID dumping is already only shown if
      drm.debug=KMS, it's just the loglevel chosen was set to be caught by CI
      if it ever occurred as it was expected to be an internal error not
      external.
      
      Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2203Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201029213042.11672-1-chris@chris-wilson.co.uk
      fa3bfa35
    • T
      soc: ti: ti_sci_pm_domains: check for proper args count in xlate · 3d696f42
      Tero Kristo 提交于
      K2G devices still only use single parameter for power-domains property,
      so check for this properly in the driver. Without this, every peripheral
      fails to probe resulting in boot failure.
      
      Link: https://lore.kernel.org/r/20201029093337.21170-1-t-kristo@ti.com
      Fixes: efa5c01c ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one")
      Reported-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Acked-by: NNishanth Menon <nm@ti.com>
      Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      3d696f42
    • S
      coresight: cti: Initialize dynamic sysfs attributes · 80624263
      Suzuki K Poulose 提交于
      With LOCKDEP enabled, CTI driver triggers the following splat due
      to uninitialized lock class for dynamically allocated attribute
      objects.
      
      [    5.372901] coresight etm0: CPU0: ETM v4.0 initialized
      [    5.376694] coresight etm1: CPU1: ETM v4.0 initialized
      [    5.380785] coresight etm2: CPU2: ETM v4.0 initialized
      [    5.385851] coresight etm3: CPU3: ETM v4.0 initialized
      [    5.389808] BUG: key ffff00000564a798 has not been registered!
      [    5.392456] ------------[ cut here ]------------
      [    5.398195] DEBUG_LOCKS_WARN_ON(1)
      [    5.398233] WARNING: CPU: 1 PID: 32 at kernel/locking/lockdep.c:4623 lockdep_init_map_waits+0x14c/0x260
      [    5.406149] Modules linked in:
      [    5.415411] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.9.0-12034-gbbe85027 #51
      [    5.418553] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
      [    5.426453] Workqueue: events amba_deferred_retry_func
      [    5.433299] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
      [    5.438252] pc : lockdep_init_map_waits+0x14c/0x260
      [    5.444410] lr : lockdep_init_map_waits+0x14c/0x260
      [    5.449007] sp : ffff800012bbb720
      ...
      
      [    5.531561] Call trace:
      [    5.536847]  lockdep_init_map_waits+0x14c/0x260
      [    5.539027]  __kernfs_create_file+0xa8/0x1c8
      [    5.543539]  sysfs_add_file_mode_ns+0xd0/0x208
      [    5.548054]  internal_create_group+0x118/0x3c8
      [    5.552307]  internal_create_groups+0x58/0xb8
      [    5.556733]  sysfs_create_groups+0x2c/0x38
      [    5.561160]  device_add+0x2d8/0x768
      [    5.565148]  device_register+0x28/0x38
      [    5.568537]  coresight_register+0xf8/0x320
      [    5.572358]  cti_probe+0x1b0/0x3f0
      
      ...
      
      Fix this by initializing the attributes when they are allocated.
      
      Fixes: 3c5597e3 ("coresight: cti: Add connection information to sysfs")
      Reported-by: NLeo Yan <leo.yan@linaro.org>
      Tested-by: NLeo Yan <leo.yan@linaro.org>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Link: https://lore.kernel.org/r/20201029164559.1268531-2-mathieu.poirier@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80624263