summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-06-04usb: typec: tcpm: Correct the responses in SVDM Version 2.0 DFPKyle Tso
In USB PD Spec Rev 3.1 Ver 1.0, section "6.12.5 Applicability of Structured VDM Commands", DFP is allowed and recommended to respond to Discovery Identity with ACK. And in section "6.4.4.2.5.1 Commands other than Attention", NAK should be returned only when receiving Messages with invalid fields, Messages in wrong situation, or unrecognize Messages. Still keep the original design for SVDM Version 1.0 for backward compatibilities. Fixes: 193a68011fdc ("staging: typec: tcpm: Respond to Discover Identity commands") Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Kyle Tso <kyletso@google.com> Link: https://lore.kernel.org/r/20210601123151.3441914-2-kyletso@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-04drm/i915/guc: Use guc_class instead of engine_class in fw interfaceDaniele Ceraolo Spurio
GuC has its own defines for the engine classes. They're currently mapping 1:1 to the defines used by the driver, but there is no guarantee this will continue in the future. Given that we've been caught off-guard in the past by similar divergences, we can prepare for the changes by introducing helper functions to convert from engine class to GuC class and back again. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-21-matthew.brost@intel.com
2021-06-04drm/i915/guc: Early initialization of GuC send registersMichal Wajdeczko
Base offset and count of the GuC scratch registers, used for sending MMIO messages to GuC, can be initialized earlier with other GuC members that also depends on platform. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-20-matthew.brost@intel.com
2021-06-04drm/i915/guc: Always copy CT message to new allocationMichal Wajdeczko
Since most of future CT traffic will be based on G2H requests, instead of copying incoming CT message to static buffer and then create new allocation for such request, always copy incoming CT message to new allocation. Also by doing it while reading CT header, we can safely fallback if that atomic allocation fails. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-19-matthew.brost@intel.com
2021-06-04drm/i915/guc: Don't receive all G2H messages in irq handlerMichal Wajdeczko
In irq handler try to receive just single G2H message, let other messages to be received from tasklet. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-18-matthew.brost@intel.com
2021-06-04Revert "usb: dwc3: core: Add shutdown callback for dwc3"Alexandru Elisei
This reverts commit 568262bf5492a9bb2fcc4c204b8d38fd6be64e28. The commit causes the following panic when shutting down a rockpro64-v2 board: [..] [ 41.684569] xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered [ 41.686301] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 41.687096] Mem abort info: [ 41.687345] ESR = 0x96000004 [ 41.687615] EC = 0x25: DABT (current EL), IL = 32 bits [ 41.688082] SET = 0, FnV = 0 [ 41.688352] EA = 0, S1PTW = 0 [ 41.688628] Data abort info: [ 41.688882] ISV = 0, ISS = 0x00000004 [ 41.689219] CM = 0, WnR = 0 [ 41.689481] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000073b2000 [ 41.690046] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [ 41.690654] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 41.691143] Modules linked in: [ 41.691416] CPU: 5 PID: 1 Comm: shutdown Not tainted 5.13.0-rc4 #43 [ 41.691966] Hardware name: Pine64 RockPro64 v2.0 (DT) [ 41.692409] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 41.692937] pc : down_read_interruptible+0xec/0x200 [ 41.693373] lr : simple_recursive_removal+0x48/0x280 [ 41.693815] sp : ffff800011fab910 [ 41.694107] x29: ffff800011fab910 x28: ffff0000008fe480 x27: ffff0000008fe4d8 [ 41.694736] x26: ffff800011529a90 x25: 00000000000000a0 x24: ffff800011edd030 [ 41.695364] x23: 0000000000000080 x22: 0000000000000000 x21: ffff800011f23994 [ 41.695992] x20: ffff800011f23998 x19: ffff0000008fe480 x18: ffffffffffffffff [ 41.696620] x17: 000c0400bb44ffff x16: 0000000000000009 x15: ffff800091faba3d [ 41.697248] x14: 0000000000000004 x13: 0000000000000000 x12: 0000000000000020 [ 41.697875] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : 6f6c746364716e62 [ 41.698502] x8 : 7f7f7f7f7f7f7f7f x7 : fefefeff6364626d x6 : 0000000000000440 [ 41.699130] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000000a0 [ 41.699758] x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000000000a0 [ 41.700386] Call trace: [ 41.700602] down_read_interruptible+0xec/0x200 [ 41.701003] debugfs_remove+0x5c/0x80 [ 41.701328] dwc3_debugfs_exit+0x1c/0x6c [ 41.701676] dwc3_remove+0x34/0x1a0 [ 41.701988] platform_remove+0x28/0x60 [ 41.702322] __device_release_driver+0x188/0x22c [ 41.702730] device_release_driver+0x2c/0x44 [ 41.703106] bus_remove_device+0x124/0x130 [ 41.703468] device_del+0x16c/0x424 [ 41.703777] platform_device_del.part.0+0x1c/0x90 [ 41.704193] platform_device_unregister+0x28/0x44 [ 41.704608] of_platform_device_destroy+0xe8/0x100 [ 41.705031] device_for_each_child_reverse+0x64/0xb4 [ 41.705470] of_platform_depopulate+0x40/0x84 [ 41.705853] __dwc3_of_simple_teardown+0x20/0xd4 [ 41.706260] dwc3_of_simple_shutdown+0x14/0x20 [ 41.706652] platform_shutdown+0x28/0x40 [ 41.706998] device_shutdown+0x158/0x330 [ 41.707344] kernel_power_off+0x38/0x7c [ 41.707684] __do_sys_reboot+0x16c/0x2a0 [ 41.708029] __arm64_sys_reboot+0x28/0x34 [ 41.708383] invoke_syscall+0x48/0x114 [ 41.708716] el0_svc_common.constprop.0+0x44/0xdc [ 41.709131] do_el0_svc+0x28/0x90 [ 41.709426] el0_svc+0x2c/0x54 [ 41.709698] el0_sync_handler+0xa4/0x130 [ 41.710045] el0_sync+0x198/0x1c0 [ 41.710342] Code: c8047c62 35ffff84 17fffe5f f9800071 (c85ffc60) [ 41.710881] ---[ end trace 406377df5178f75c ]--- [ 41.711299] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 41.712084] Kernel Offset: disabled [ 41.712391] CPU features: 0x10001031,20000846 [ 41.712775] Memory Limit: none [ 41.713049] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- As Felipe explained: "dwc3_shutdown() is just called dwc3_remove() directly, then we end up calling debugfs_remove_recursive() twice." Reverting the commit fixes the panic. Fixes: 568262bf5492 ("usb: dwc3: core: Add shutdown callback for dwc3") Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Link: https://lore.kernel.org/r/20210603151742.298243-1-alexandru.elisei@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-04drm/i915/guc: Stop using mutex while sending CTB messagesMichal Wajdeczko
We are no longer using descriptor to hold G2H replies and we are protecting access to the descriptor and command buffer by the separate spinlock, so we can stop using mutex. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-17-matthew.brost@intel.com
2021-06-04drm/i915/guc: Ensure H2G buffer updates visible before tail updateMatthew Brost
Ensure H2G buffer updates are visible before descriptor tail updates by inserting a barrier between the H2G buffer update and the tail. The barrier is simple wmb() for SMEM and is register write for LMEM. This is needed if more than 1 H2G can be inflight at once. If this barrier is not inserted it is possible the descriptor tail update is scene by the GuC before H2G buffer update which results in the GuC reading a corrupt H2G value. This can bring down the H2G channel among other bad things. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-16-matthew.brost@intel.com
2021-06-04drm/i915/guc: Start protecting access to CTB descriptorsMichal Wajdeczko
We want to stop using guc.send_mutex while sending CTB messages so we have to start protecting access to CTB send descriptor. For completeness protect also CTB receive descriptor. Add spinlock to struct intel_guc_ct_buffer and start using it. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-15-matthew.brost@intel.com
2021-06-04drm/i915/guc: Update sizes of CTB buffersMichal Wajdeczko
Future GuC will require CTB buffers sizes to be multiple of 4K. Make these changes now as this shouldn't impact us too much. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603230408.54856-2-matthew.brost@intel.com
2021-06-04drm/i915/guc: Replace CTB array with explicit membersMichal Wajdeczko
Upcoming GuC firmware will always require just two CTBs and we also plan to configure them with different sizes, so definining them as array is no longer suitable. v2: Use %p for ptrdiff print v3: Use %tx for ptrdiff print Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603230408.54856-1-matthew.brost@intel.com
2021-06-04drm/i915: Initialize the mbus_offset to fix Klockwork issueManasi Navare
Static analysis identified an issue in skl_crtc_allocate_ddb where mbus_offset may be used uninitialized. This patch fixes it. Fixes: 835c176cb1c4 ("drm/i915: Introduce MBUS relative dbuf offsets") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210603215338.13804-1-manasi.d.navare@intel.com
2021-06-04drm/mediatek: dpi: Add bus format negotiationRex-BC Chen
Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negotiate the possible output and input formats for the current mode and monitor, and use the negotiated formats in a basic atomic_check callback. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2021-06-04drm/mediatek: dpi: Add output bus formats to driver dataRex-BC Chen
For each SoC, dpi support different output bus formats, so add these information into driver data. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2021-06-04Merge tag 'drm/tegra/for-5.13-rc5' of ↵Dave Airlie
ssh://git.freedesktop.org/git/tegra/linux into drm-fixes drm/tegra: Fixes for v5.13-rc5 The most important change here fixes a race condition that causes either HDA or (more frequently) display to malfunction because they race for enabling the SOR power domain at probe time. Other than that, there's a couple of build warnings for issues introduced in v5.13 as well as some minor fixes, such as reference leak plugs. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210603144624.788861-1-thierry.reding@gmail.com
2021-06-04drm/mediatek: dpi: Add dual edge sample mode supportRex-BC Chen
To support RGB888_2X12_LE and RGB888_2X12_BE, dpi should sample on dual edge which could recude half data io pins. For RGB888_1X24, dpi just sample on single edge (rising or falling edge). Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2021-06-04Merge tag 'amd-drm-fixes-5.13-2021-06-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.13-2021-06-02: amdgpu: - Display fixes - FRU EEPROM error handling fix - RAS fix - PSP fix - Releasing pinned BO fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210603040410.4080-1-alexander.deucher@amd.com
2021-06-03Merge tag 'for-net-2021-06-03' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth bluetooth pull request for net: - Fixes UAF and CVE-2021-3564 - Fix VIRTIO_ID_BT to use an unassigned ID - Fix firmware loading on some Intel Controllers Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-03virtio-net: fix for skb_over_panic inside big modeXuan Zhuo
In virtio-net's large packet mode, there is a hole in the space behind buf. hdr_padded_len - hdr_len We must take this into account when calculating tailroom. [ 44.544385] skb_put.cold (net/core/skbuff.c:5254 (discriminator 1) net/core/skbuff.c:5252 (discriminator 1)) [ 44.544864] page_to_skb (drivers/net/virtio_net.c:485) [ 44.545361] receive_buf (drivers/net/virtio_net.c:849 drivers/net/virtio_net.c:1131) [ 44.545870] ? netif_receive_skb_list_internal (net/core/dev.c:5714) [ 44.546628] ? dev_gro_receive (net/core/dev.c:6103) [ 44.547135] ? napi_complete_done (./include/linux/list.h:35 net/core/dev.c:5867 net/core/dev.c:5862 net/core/dev.c:6565) [ 44.547672] virtnet_poll (drivers/net/virtio_net.c:1427 drivers/net/virtio_net.c:1525) [ 44.548251] __napi_poll (net/core/dev.c:6985) [ 44.548744] net_rx_action (net/core/dev.c:7054 net/core/dev.c:7139) [ 44.549264] __do_softirq (./arch/x86/include/asm/jump_label.h:19 ./include/linux/jump_label.h:200 ./include/trace/events/irq.h:142 kernel/softirq.c:560) [ 44.549762] irq_exit_rcu (kernel/softirq.c:433 kernel/softirq.c:637 kernel/softirq.c:649) [ 44.551384] common_interrupt (arch/x86/kernel/irq.c:240 (discriminator 13)) [ 44.551991] ? asm_common_interrupt (./arch/x86/include/asm/idtentry.h:638) [ 44.552654] asm_common_interrupt (./arch/x86/include/asm/idtentry.h:638) Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom") Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Reported-by: Corentin Noël <corentin.noel@collabora.com> Tested-by: Corentin Noël <corentin.noel@collabora.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-03Merge tag 'ieee802154-for-davem-2021-06-03' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan Stefan Schmidt says: ==================== An update from ieee802154 for your *net* tree. This time we have fixes for the ieee802154 netlink code, as well as a driver fix. Zhen Lei, Wei Yongjun and Yang Li each had a patch to cleanup some return code handling ensuring we actually get a real error code when things fails. Dan Robertson fixed a potential null dereference in our netlink handling. Andy Shevchenko removed of_match_ptr()usage in the mrf24j40 driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-03Merge tag 'wireless-drivers-2021-06-03' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for v5.13 We have only mt76 fixes this time, most important being the fix for A-MSDU injection attacks. mt76 * mitigate A-MSDU injection attacks (CVE-2020-24588) * fix possible array out of bound access in mt7921_mcu_tx_rate_report * various aggregation and HE setting fixes * suspend/resume fix for pci devices * mt7615: fix crash when runtime-pm is not supported ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-03cxgb4: fix regression with HASH tc prio value updateRahul Lakkireddy
commit db43b30cd89c ("cxgb4: add ethtool n-tuple filter deletion") has moved searching for next highest priority HASH filter rule to cxgb4_flow_rule_destroy(), which searches the rhashtable before the the rule is removed from it and hence always finds at least 1 entry. Fix by removing the rule from rhashtable first before calling cxgb4_flow_rule_destroy() and hence avoid fetching stale info. Fixes: db43b30cd89c ("cxgb4: add ethtool n-tuple filter deletion") Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-03drm/i915/guc: Don't repeat CTB layout calculationsMichal Wajdeczko
We can retrieve offsets to cmds buffers and descriptor from actual pointers that we already keep locally. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-11-matthew.brost@intel.com
2021-06-03drm/i915/guc: Only rely on own CTB sizeMichal Wajdeczko
In upcoming GuC firmware, CTB size will be removed from the CTB descriptor so we must keep it locally for any calculations. While around, improve some debug messages and helpers. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-10-matthew.brost@intel.com
2021-06-03drm/i915: Promote ptrdiff() to i915_utils.hMichal Wajdeczko
Generic helpers should be placed in i915_utils.h. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-9-matthew.brost@intel.com
2021-06-03drm/i915/guc: Stop using fence/status from CTB descriptorMichal Wajdeczko
Stop using fence/status from CTB descriptor as future GuC ABI will no longer support replies over CTB descriptor. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-8-matthew.brost@intel.com
2021-06-03drm/i915/guc: Drop guc->interrupts.enabledMatthew Brost
Drop the variable guc->interrupts.enabled as this variable is just leading to bugs creeping into the code. e.g. A full GPU reset disables the GuC interrupts but forgot to clear guc->interrupts.enabled, guc->interrupts.enabled being true suppresses interrupts from getting re-enabled and now we are broken. It is harmless to enable interrupt while already enabled so let's just delete this variable to avoid bugs like this going forward. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-7-matthew.brost@intel.com
2021-06-03drm/i915/guc: Keep strict GuC ABI definitionsMichal Wajdeczko
Our fwif.h file is now mix of strict firmware ABI definitions and set of our helpers. In anticipation of upcoming changes to the GuC interface try to keep them separate in smaller maintainable files. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-6-matthew.brost@intel.com
2021-06-03drm/i915/guc: Remove sample_forcewake h2g actionRodrigo Vivi
This action is no-op in the GuC side for a few versions already and it is getting entirely removed soon, in an upcoming version. Time to remove before we face communication issues. Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-5-matthew.brost@intel.com
2021-06-03drm/i915/guc: enable only the user interrupt when using GuC submissionDaniele Ceraolo Spurio
In GuC submission mode the CS is owned by the GuC FW, so all CS status interrupts are handled by it. We only need the user interrupt as that signals request completion. Since we're now starting the engines directly in GuC submission mode when selected, we can stop switching back and forth between the execlists and the GuC programming and select directly the correct interrupt mask. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-4-matthew.brost@intel.com
2021-06-03drm/i915/guc: use probe_error log for CT enablement failureDaniele Ceraolo Spurio
We have a couple of failure injection points in the CT enablement path, so we need to use i915_probe_error() to select the appropriate log level. A new macro (CT_PROBE_ERROR) has been added to the set of CT logging macros to be used in this scenario and upcoming ones. While adding the new macros, fix the underlying logging mechanics used by the existing ones (DRM_DEV_* -> drm_*) and move the inlines to before they're used inside the macros. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-3-matthew.brost@intel.com
2021-06-03drm/i915/guc: skip disabling CTBs before sanitizing the GuCDaniele Ceraolo Spurio
If we're about to sanitize the GuC, something might have going wrong beforehand, so we should avoid trying to talk to it. Even if GuC is still running fine, the sanitize will reset its internal state and clear the CTB registration, so there is still no need to explicitly do so. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2469 Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-2-matthew.brost@intel.com
2021-06-04Merge tag 'drm-intel-fixes-2021-06-03' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.13-rc5: - Revert conversion to io_mapping_map_user() which lead to BUG_ON() - Fix check for error valued returns in a selftest Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87lf7rpcmp.fsf@intel.com
2021-06-03Bluetooth: btusb: Fix failing to init controllers with operation firmwareLuiz Augusto von Dentz
Some firmware when operation don't may have broken versions leading to error like the following: [ 6.176482] Bluetooth: hci0: Firmware revision 0.0 build 121 week 7 2021 [ 6.177906] bluetooth hci0: Direct firmware load for intel/ibt-20-0-0.sfi failed with error -2 [ 6.177910] Bluetooth: hci0: Failed to load Intel firmware file intel/ibt-20-0-0.sfi (-2) Since we load the firmware file just to check if its version had changed comparing to the one already loaded we can just skip since the firmware is already operation. Fixes: ac0565462e330 ("Bluetooth: btintel: Check firmware version before download") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-06-03i2c: tegra-bpmp: Demote kernel-doc abusesLee Jones
Fixes the following W=1 kernel build warning(s): drivers/i2c/busses/i2c-tegra-bpmp.c:86: warning: Function parameter or member 'i2c' not described in 'tegra_bpmp_serialize_i2c_msg' drivers/i2c/busses/i2c-tegra-bpmp.c:86: warning: Function parameter or member 'request' not described in 'tegra_bpmp_serialize_i2c_msg' drivers/i2c/busses/i2c-tegra-bpmp.c:86: warning: Function parameter or member 'msgs' not described in 'tegra_bpmp_serialize_i2c_msg' drivers/i2c/busses/i2c-tegra-bpmp.c:86: warning: Function parameter or member 'num' not described in 'tegra_bpmp_serialize_i2c_msg' drivers/i2c/busses/i2c-tegra-bpmp.c:86: warning: expecting prototype for The serialized I2C format is simply the following(). Prototype was for tegra_bpmp_serialize_i2c_msg() instead drivers/i2c/busses/i2c-tegra-bpmp.c:130: warning: Function parameter or member 'i2c' not described in 'tegra_bpmp_i2c_deserialize' drivers/i2c/busses/i2c-tegra-bpmp.c:130: warning: Function parameter or member 'response' not described in 'tegra_bpmp_i2c_deserialize' drivers/i2c/busses/i2c-tegra-bpmp.c:130: warning: Function parameter or member 'msgs' not described in 'tegra_bpmp_i2c_deserialize' drivers/i2c/busses/i2c-tegra-bpmp.c:130: warning: Function parameter or member 'num' not described in 'tegra_bpmp_i2c_deserialize' drivers/i2c/busses/i2c-tegra-bpmp.c:130: warning: expecting prototype for The data in the BPMP(). Prototype was for tegra_bpmp_i2c_deserialize() instead Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-06-03i2c: altera: Fix formatting issue in struct and demote unworthy kernel-doc ↵Lee Jones
headers Fixes the following W=1 kernel build warning(s): drivers/i2c/busses/i2c-altera.c:74: warning: cannot understand function prototype: 'struct altr_i2c_dev ' drivers/i2c/busses/i2c-altera.c:180: warning: Function parameter or member 'idev' not described in 'altr_i2c_transfer' drivers/i2c/busses/i2c-altera.c:180: warning: Function parameter or member 'data' not described in 'altr_i2c_transfer' drivers/i2c/busses/i2c-altera.c:193: warning: Function parameter or member 'idev' not described in 'altr_i2c_empty_rx_fifo' drivers/i2c/busses/i2c-altera.c:209: warning: Function parameter or member 'idev' not described in 'altr_i2c_fill_tx_fifo' Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-06-04Merge tag 'amd-drm-next-5.14-2021-06-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.14-2021-06-02: amdgpu: - GC/MM register access macro clean up for SR-IOV - Beige Goby updates - W=1 Fixes - Aldebaran fixes - Misc display fixes - ACPI ATCS/ATIF handling rework - SR-IOV fixes - RAS fixes - 16bpc fixed point format support - Initial smartshift support - RV/PCO power tuning fixes for suspend/resume - More buffer object subclassing work - Add new INFO query for additional vbios information - Add new placement for preemptable SG buffers amdkfd: - Misc fixes radeon: - W=1 Fixes - Misc cleanups UAPI: - Add new INFO query for additional vbios information Useful for debugging vbios related issues. Proposed umr patch: https://patchwork.freedesktop.org/patch/433297/ - 16bpc fixed point format support IGT test: https://lists.freedesktop.org/archives/igt-dev/2021-May/031507.html Proposed Vulkan patch: https://github.com/kleinerm/pal/commit/a25d4802074b13a8d5f7edc96ae45469ecbac3c4 - Add a new GEM flag which is only used internally in the kernel driver. Userspace is not allowed to set it. drm: - 16bpc fixed point format fourcc Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210602214009.4553-1-alexander.deucher@amd.com
2021-06-03Merge tag 'vfio-v5.13-rc5' of git://github.com/awilliam/linux-vfioLinus Torvalds
Pull VFIO fixes from Alex Williamson: - Fix error path return value (Zhen Lei) - Add vfio-pci CONFIG_MMU dependency (Randy Dunlap) - Replace open coding with struct_size() (Gustavo A. R. Silva) - Fix sample driver error path (Wei Yongjun) - Fix vfio-platform error path module_put() (Max Gurtovoy) * tag 'vfio-v5.13-rc5' of git://github.com/awilliam/linux-vfio: vfio/platform: fix module_put call in error flow samples: vfio-mdev: fix error handing in mdpy_fb_probe() vfio/iommu_type1: Use struct_size() for kzalloc() vfio/pci: zap_vma_ptes() needs MMU vfio/pci: Fix error return code in vfio_ecap_init()
2021-06-03Merge tag 'block-5.13-2021-06-03' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block fixes from Jens Axboe: "NVMe fixes from Christoph: - Fix corruption in RDMA in-capsule SGLs (Sagi Grimberg) - nvme-loop reset fixes (Hannes Reinecke) - nvmet fix for freeing unallocated p2pmem (Max Gurtovoy)" * tag 'block-5.13-2021-06-03' of git://git.kernel.dk/linux-block: nvmet: fix freeing unallocated p2pmem nvme-loop: do not warn for deleted controllers during reset nvme-loop: check for NVME_LOOP_Q_LIVE in nvme_loop_destroy_admin_queue() nvme-loop: clear NVME_LOOP_Q_LIVE when nvme_loop_configure_admin_queue() fails nvme-loop: reset queue count to 1 in nvme_loop_destroy_io_queues() nvme-rdma: fix in-casule data send for chained sgls
2021-06-03regulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULLAxel Lin
devm_gpiod_get_array_optional may return NULL if no GPIO was assigned. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210603094944.1114156-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-03usb: dwc3: debugfs: Add and remove endpoint dirs dynamicallyJack Pham
The DWC3 DebugFS directory and files are currently created once during probe. This includes creation of subdirectories for each of the gadget's endpoints. This works fine for peripheral-only controllers, as dwc3_core_init_mode() calls dwc3_gadget_init() just prior to calling dwc3_debugfs_init(). However, for dual-role controllers, dwc3_core_init_mode() will instead call dwc3_drd_init() which is problematic in a few ways. First, the initial state must be determined, then dwc3_set_mode() will have to schedule drd_work and by then dwc3_debugfs_init() could have already been invoked. Even if the initial mode is peripheral, dwc3_gadget_init() happens after the DebugFS files are created, and worse so if the initial state is host and the controller switches to peripheral much later. And secondly, even if the gadget endpoints' debug entries were successfully created, if the controller exits peripheral mode, its dwc3_eps are freed so the debug files would now hold stale references. So it is best if the DebugFS endpoint entries are created and removed dynamically at the same time the underlying dwc3_eps are. Do this by calling dwc3_debugfs_create_endpoint_dir() as each endpoint is created, and conversely remove the DebugFS entry when the endpoint is freed. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@vger.kernel.org> Reviewed-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210529192932.22912-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03RDMA/mlx4: Do not map the core_clock page to user space unless enabledShay Drory
Currently when mlx4 maps the hca_core_clock page to the user space there are read-modifiable registers, one of which is semaphore, on this page as well as the clock counter. If user reads the wrong offset, it can modify the semaphore and hang the device. Do not map the hca_core_clock page to the user space unless the device has been put in a backwards compatibility mode to support this feature. After this patch, mlx4 core_clock won't be mapped to user space on the majority of existing devices and the uverbs device time feature in ibv_query_rt_values_ex() will be disabled. Fixes: 52033cfb5aab ("IB/mlx4: Add mmap call to map the hardware clock") Link: https://lore.kernel.org/r/9632304e0d6790af84b3b706d8c18732bc0d5e27.1622726305.git.leonro@nvidia.com Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-03RDMA/mlx5: Use different doorbell memory for different processesMark Zhang
In a fork scenario, the parent and child can have same virtual address and also share the uverbs fd. That causes to the list_for_each_entry search return same doorbell physical page for all processes, even though that page has been COW' or copied. This patch takes the mm_struct into consideration during search, to make sure that VA's belonging to different processes are not intermixed. Resolves the malfunction of uverbs after fork in some specific cases. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://lore.kernel.org/r/feacc23fe0bc6e1088c6824d5583798745e72405.1622726212.git.leonro@nvidia.com Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Mark Zhang <markzhang@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-03drm/i915/adlp: Fix AUX power well -> PHY mappingImre Deak
On ADL_P the power well->PHY mapping doesn't follow the mapping on previous platforms, fix this up. While at it remove the redundant dev_priv param from icl_tc_phy_aux_ch(). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526143729.2563672-3-imre.deak@intel.com
2021-06-03drm/i915: Fix incorrect assert about pending power domain async-put workImre Deak
It's possible that an already dequeued put_async_work() will release the reference (*) that was put asynchronously after the dequeue happened. This leaves an async-put work pending, without any reference to release. A subsequent async-put may trigger the drm_WARN_ON(!queue_delayed_work(&power_domains->async_put_work)); warn due to async_put_work() still pending. To avoid the warn, cancel the pending async_put_work() when releasing the reference at (*) above. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3421 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2289 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526143729.2563672-2-imre.deak@intel.com
2021-06-03drm/i915/ddi: Flush encoder power domain ref puts during driver unloadImre Deak
An async-put on an encoder specific power domain (for instance the AUX PW domain) may be pending when removing the encoder. Make sure any such async-puts are complete while the corresponding encoder is still in place since at least AUX power wells require this to do a power well->PHY lookup. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526143729.2563672-1-imre.deak@intel.com
2021-06-03ice: track AF_XDP ZC enabled queues in bitmapMaciej Fijalkowski
Commit c7a219048e45 ("ice: Remove xsk_buff_pool from VSI structure") silently introduced a regression and broke the Tx side of AF_XDP in copy mode. xsk_pool on ice_ring is set only based on the existence of the XDP prog on the VSI which in turn picks ice_clean_tx_irq_zc to be executed. That is not something that should happen for copy mode as it should use the regular data path ice_clean_tx_irq. This results in a following splat when xdpsock is run in txonly or l2fwd scenarios in copy mode: <snip> [ 106.050195] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 106.057269] #PF: supervisor read access in kernel mode [ 106.062493] #PF: error_code(0x0000) - not-present page [ 106.067709] PGD 0 P4D 0 [ 106.070293] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 106.074721] CPU: 61 PID: 0 Comm: swapper/61 Not tainted 5.12.0-rc2+ #45 [ 106.081436] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 106.092027] RIP: 0010:xp_raw_get_dma+0x36/0x50 [ 106.096551] Code: 74 14 48 b8 ff ff ff ff ff ff 00 00 48 21 f0 48 c1 ee 30 48 01 c6 48 8b 87 90 00 00 00 48 89 f2 81 e6 ff 0f 00 00 48 c1 ea 0c <48> 8b 04 d0 48 83 e0 fe 48 01 f0 c3 66 66 2e 0f 1f 84 00 00 00 00 [ 106.115588] RSP: 0018:ffffc9000d694e50 EFLAGS: 00010206 [ 106.120893] RAX: 0000000000000000 RBX: ffff88984b8c8a00 RCX: ffff889852581800 [ 106.128137] RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffff88984cd8b800 [ 106.135383] RBP: ffff888123b50001 R08: ffff889896800000 R09: 0000000000000800 [ 106.142628] R10: 0000000000000000 R11: ffffffff826060c0 R12: 00000000000000ff [ 106.149872] R13: 0000000000000000 R14: 0000000000000040 R15: ffff888123b50018 [ 106.157117] FS: 0000000000000000(0000) GS:ffff8897e0f40000(0000) knlGS:0000000000000000 [ 106.165332] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 106.171163] CR2: 0000000000000030 CR3: 000000000560a004 CR4: 00000000007706e0 [ 106.178408] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 106.185653] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 106.192898] PKRU: 55555554 [ 106.195653] Call Trace: [ 106.198143] <IRQ> [ 106.200196] ice_clean_tx_irq_zc+0x183/0x2a0 [ice] [ 106.205087] ice_napi_poll+0x3e/0x590 [ice] [ 106.209356] __napi_poll+0x2a/0x160 [ 106.212911] net_rx_action+0xd6/0x200 [ 106.216634] __do_softirq+0xbf/0x29b [ 106.220274] irq_exit_rcu+0x88/0xc0 [ 106.223819] common_interrupt+0x7b/0xa0 [ 106.227719] </IRQ> [ 106.229857] asm_common_interrupt+0x1e/0x40 </snip> Fix this by introducing the bitmap of queues that are zero-copy enabled, where each bit, corresponding to a queue id that xsk pool is being configured on, will be set/cleared within ice_xsk_pool_{en,dis}able and checked within ice_xsk_pool(). The latter is a function used for deciding which napi poll routine is executed. Idea is being taken from our other drivers such as i40e and ixgbe. Fixes: c7a219048e45 ("ice: Remove xsk_buff_pool from VSI structure") Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Kiran Bhandare <kiranx.bhandare@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-03igc: add correct exception tracing for XDPMagnus Karlsson
Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: 73f1071c1d29 ("igc: Add support for XDP_TX action") Fixes: 4ff320361092 ("igc: Add support for XDP_REDIRECT action") Reported-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-03ixgbevf: add correct exception tracing for XDPMagnus Karlsson
Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: 21092e9ce8b1 ("ixgbevf: Add support for XDP_TX action") Reported-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Tested-by: Vishakha Jambekar <vishakha.jambekar@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-03igb: add correct exception tracing for XDPMagnus Karlsson
Add missing exception tracing to XDP when a number of different errors can occur. The support was only partial. Several errors where not logged which would confuse the user quite a lot not knowing where and why the packets disappeared. Fixes: 9cbc948b5a20 ("igb: add XDP support") Reported-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Tested-by: Vishakha Jambekar <vishakha.jambekar@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
generated by cgit (git 2.34.1) at 2025-10-03 14:18:37 +0000