aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-09-13drm/i915/guc: Move fields protected by guc->contexts_lock into sub structureMatthew Brost5-67/+69
To make ownership of locking clear move fields (guc_id, guc_id_ref, guc_id_link) to sub structure guc_id in intel_context. Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-22-matthew.brost@intel.com
2021-09-13drm/i915/guc: Move GuC priority fields in context under guc_activeMatthew Brost3-37/+46
Move GuC management fields in context under guc_active struct as this is where the lock that protects theses fields lives. Also only set guc_prio field once during context init. v2: (Daniele) - set CONTEXT_SET_INIT Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-21-matthew.brost@intel.com
2021-09-13drm/i915/guc: Drop pin count check trick between sched_disable and re-pinMatthew Brost2-21/+34
Drop pin count check trick between a sched_disable and re-pin, now rely on the lock and counter of the number of committed requests to determine if scheduling should be disabled on the context. Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-20-matthew.brost@intel.com
2021-09-13drm/i915/guc: Proper xarray usage for contexts_lookupMatthew Brost1-15/+87
Lock the xarray and take ref to the context if needed. v2: (Checkpatch) - Add new line after declaration (Daniel Vetter) - Correct put / get accounting in xa_for_loops v3: (Checkpatch) - Extra new line Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-19-matthew.brost@intel.com
2021-09-13drm/i915/guc: Rework and simplify lockingMatthew Brost3-120/+90
Rework and simplify the locking with GuC subission. Drop sched_state_no_lock and move all fields under the guc_state.sched_state and protect all these fields with guc_state.lock . This requires changing the locking hierarchy from guc_state.lock -> sched_engine.lock to sched_engine.lock -> guc_state.lock. v2: (Daniele) - Don't check fields outside of lock during sched disable, check less fields within lock as some of the outside are no longer needed Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-18-matthew.brost@intel.com
2021-09-13drm/i915/guc: Move guc_blocked fence to struct guc_stateMatthew Brost3-14/+14
Move guc_blocked fence to struct guc_state as the lock which protects the fence lives there. s/ce->guc_blocked/ce->guc_state.blocked/g v2: (Daniele) - s/blocked_fence/blocked/g Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-17-matthew.brost@intel.com
2021-09-13drm/i915/guc: Release submit fence from an irq_workMatthew Brost2-3/+24
A subsequent patch will flip the locking hierarchy from ce->guc_state.lock -> sched_engine->lock to sched_engine->lock -> ce->guc_state.lock. As such we need to release the submit fence for a request from an IRQ to break a lock inversion - i.e. the fence must be release went holding ce->guc_state.lock and the releasing of the can acquire sched_engine->lock. v2: (Daniele) - Delete request from list before calling irq_work_queue Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-16-matthew.brost@intel.com
2021-09-13drm/i915/guc: Reset LRC descriptor if register returns -ENODEVMatthew Brost1-2/+4
Reset LRC descriptor if a context register returns -ENODEV as this means we are mid-reset. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-15-matthew.brost@intel.com
2021-09-13drm/i915/guc: Don't touch guc_state.sched_state without a lockMatthew Brost1-5/+17
Before we did some clever tricks to not use the a lock when touching guc_state.sched_state in certain cases. Don't do that, enforce the use of the lock. v2: (kernel test robo ) - Add __maybe_unused to sched_state_is_init() v3: rebase after the unused code path removal has been moved to an earlier patch. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-14-matthew.brost@intel.com
2021-09-13drm/i915/guc: Take context ref when cancelling requestMatthew Brost1-1/+4
A context can get destroyed after cancelling a request, if a context or GT reset occurs, so take a reference to context when cancelling a request. Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-13-matthew.brost@intel.com
2021-09-13drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2HMatthew Brost6-0/+185
While debugging an issue with full GT resets I went down a rabbit hole thinking the scrubbing of lost G2H wasn't working correctly. This proved to be incorrect as this was working just fine but this chase inspired me to write a selftest to prove that this works. This simple selftest injects errors dropping various G2H and then issues a full GT reset proving that the scrubbing of these G2H doesn't blow up. v2: (Daniel Vetter) - Use ifdef instead of macros for selftests v3: (Checkpatch) - A space after 'switch' statement v4: (Daniele) - A comment saying GT won't idle if G2H are lost Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-12-matthew.brost@intel.com
2021-09-13drm/i915/guc: Copy whole golden context, set engine state size of subsetMatthew Brost1-9/+17
When the GuC does a media reset, it copies a golden context state back into the corrupted context's state. The address of the golden context and the size of the engine state restore are passed in via the GuC ADS. The i915 had a bug where it passed in the whole size of the golden context, not the size of the engine state to restore resulting in a memory corruption. Also copy the entire golden context on init rather than just the engine state that is restored. v2 (Daniele): use defines to avoid duplicated const variables (John). Fixes: 481d458caede ("drm/i915/guc: Add golden context to GuC ADS") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-11-matthew.brost@intel.com
2021-09-13drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registeredMatthew Brost1-3/+19
When unblocking a context, do not enable scheduling if the context is banned, guc_id invalid, or not registered. v2: (Daniele) - Add helper for unblock Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-10-matthew.brost@intel.com
2021-09-13drm/i915/guc: Kick tasklet after queuing a requestMatthew Brost1-0/+1
Kick tasklet after queuing a request so it submitted in a timely manner. Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new inteface") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-9-matthew.brost@intel.com
2021-09-13Revert "drm/i915/gt: Propagate change in error status to children on unhold"Matthew Brost1-4/+0
Propagating errors to dependent fences is broken and can lead to errors from one client ending up in another. In commit 3761baae908a ("Revert "drm/i915: Propagate errors on awaiting already signaled fences""), we attempted to get rid of fence error propagation but missed the case added in commit 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children on unhold"). Revert that one too. This error was found by an up-and-coming selftest which triggers a reset during request cancellation and verifies that subsequent requests complete successfully. v2: (Daniel Vetter) - Use revert v3: (Jason) - Update commit message v4 (Daniele): - fix checkpatch error in commit message. References: '3761baae908a ("Revert "drm/i915: Propagate errors on awaiting already signaled fences"")' Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-8-matthew.brost@intel.com
2021-09-13drm/i915/guc: Workaround reset G2H is received after schedule done G2HMatthew Brost1-6/+35
If the context is reset as a result of the request cancellation the context reset G2H is received after schedule disable done G2H which is the wrong order. The schedule disable done G2H release the waiting request cancellation code which resubmits the context. This races with the context reset G2H which also wants to resubmit the context but in this case it really should be a NOP as request cancellation code owns the resubmit. Use some clever tricks of checking the context state to seal this race until the GuC firmware is fixed. v2: (Checkpatch) - Fix typos v3: (Daniele) - State that is a bug in the GuC firmware Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-7-matthew.brost@intel.com
2021-09-13drm/i915/guc: Process all G2H message at once in work queueMatthew Brost1-3/+3
Rather than processing 1 G2H at a time and re-queuing the work queue if more messages exist, process all the G2H in a single pass of the work queue. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-6-matthew.brost@intel.com
2021-09-13drm/i915/guc: Don't drop ce->guc_active.lock when unwinding contextMatthew Brost1-4/+0
Don't drop ce->guc_active.lock when unwinding a context after reset. At one point we had to drop this because of a lock inversion but that is no longer the case. It is much safer to hold the lock so let's do that. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-5-matthew.brost@intel.com
2021-09-13drm/i915/guc: Unwind context requests in reverse orderMatthew Brost1-4/+4
When unwinding requests on a reset context, if other requests in the context are in the priority list the requests could be resubmitted out of seqno order. Traverse the list of active requests in reverse and append to the head of the priority list to fix this. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-4-matthew.brost@intel.com
2021-09-13drm/i915/guc: Fix outstanding G2H accountingMatthew Brost1-42/+37
A small race that could result in incorrect accounting of the number of outstanding G2H. Basically prior to this patch we did not increment the number of outstanding G2H if we encoutered a GT reset while sending a H2G. This was incorrect as the context state had already been updated to anticipate a G2H response thus the counter should be incremented. As part of this change we remove a legacy (now unused) path that was the last caller requiring a G2H response that was not guaranteed to loop. This allows us to simplify the accounting as we don't need to handle the case where the send fails due to the channel being busy. Also always use helper when decrementing this value. v2 (Daniele): update GEM_BUG_ON check, pull in dead code removal from later patch, remove loop param from context_deregister. Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-3-matthew.brost@intel.com
2021-09-13drm/i915/guc: Fix blocked context accountingMatthew Brost1-1/+1
Prior to this patch the blocked context counter was cleared on init_sched_state (used during registering a context & resets) which is incorrect. This state needs to be persistent or the counter can read the incorrect value resulting in scheduling never getting enabled again. Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-2-matthew.brost@intel.com
2021-09-13cpufreq: intel_pstate: Override parameters if HWP forced by BIOSDoug Smythies1-8/+14
If HWP has been already been enabled by BIOS, it may be necessary to override some kernel command line parameters. Once it has been enabled it requires a reset to be disabled. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-09-13staging: vchiq_dev: cleanup code alignment issuesGaston Gonzalez1-62/+42
Fix code alignment issues. Reported by checkpatch.pl Signed-off-by: Gaston Gonzalez <gascoar@gmail.com> Link: https://lore.kernel.org/r/20210912133751.269885-2-gascoar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: vchiq_dev: remove braces from if blockGaston Gonzalez1-2/+1
Remove unnecessary braces from if block. Reported by checkpatch.pl Signed-off-by: Gaston Gonzalez <gascoar@gmail.com> Link: https://lore.kernel.org/r/20210912133751.269885-1-gascoar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: remove header file odm_reg.hMichael Straube3-16/+6
After removing unused register definitions from odm_reg.h there are only two definitions left. Move them into odm.h and remove odm_reg.h. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210913090831.13803-2-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: remove unused register definitions from odm_reg.hMichael Straube1-74/+0
Remove unused register definitions from odm_reg.h. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210913090831.13803-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: core: remove unused function rtw_set_tx_chksum_offloadSaurav Girepunje3-8/+0
Remove unused function rtw_set_tx_chksum_offload. Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com> Link: https://lore.kernel.org/r/YT4xcJvvlPSIS+T6@user Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: remove macro GET_EEPROM_EFUSE_PRIVMichael Straube6-14/+12
Replace and remove the macro GET_EEPROM_EFUSE_PRIV to get one step closer to remove hal_intf.h. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210912100836.4655-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: remove header file HalHWImg8188E_FW.hMichael Straube1-16/+0
The header file HalHWImg8188E_FW.h is not used in the driver. Remove it. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210911231844.16268-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: remove rtw_hw_suspendMartin Kaiser2-60/+0
The bHWPwrPindetect cleanup removed the only call to rtw_hw_suspend. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210911161019.26881-4-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: bHWPwrPindetect is always falseMartin Kaiser5-47/+2
The bHWPwrPindetect component of struct pwrctrl_priv is never initialised explicitly, it remains at its default value 0. Remove bHWPwrPindetect itself and code that depends on bHWPwrPindetect != 0. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210911161019.26881-2-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: remove write-only variable togMartin Kaiser2-5/+0
tog in struct pwrctrl_priv is never read. Remove it. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210911141521.24901-5-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: remove write-only variable cpwmMartin Kaiser2-7/+0
cpwm in struct pwrctrl_priv is never read. Remove it. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210911141521.24901-4-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: setting HW_VAR_SET_RPWM does nothingMartin Kaiser3-8/+0
Setting the HW_VAR_SET_RPWM "hardware variable" is an empty operation. Remove the call to set HW_VAR_SET_RPWM, the calculation of the value to be set and the definition of HW_VAR_SET_RPWM itself. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210911141521.24901-3-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: btcoex_rfon is always falseMartin Kaiser2-8/+0
btcoex_rfon is always false in this driver. Remove the variable and code that will never be executed. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210911141521.24901-2-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: r8188eu: make _rtw_init_queue a macroPavel Skripkin10-33/+31
While testing latest updates I hit lockdep warning: [ 42.694425] ============================================ [ 42.694785] WARNING: possible recursive locking detected [ 42.695120] 5.14.0+ #25 Tainted: G C [ 42.695422] -------------------------------------------- [ 42.695747] RTW_CMD_THREAD/317 is trying to acquire lock: [ 42.696078] ffffc900006c90b0 (&pqueue->lock){+.-.}-{3:3}, at: _rtw_alloc_network+0x1e/0x321 [r8188eu] [ 42.696686] [ 42.696686] but task is already holding lock: [ 42.697148] ffffc900006c9100 (&pqueue->lock){+.-.}-{3:3}, at: rtw_update_scanned_network+0x31/0x76b [r8188eu] [ 42.697758] [ 42.697758] other info that might help us debug this: [ 42.698326] Possible unsafe locking scenario: [ 42.698326] [ 42.698696] CPU0 [ 42.698847] ---- [ 42.698997] lock(&pqueue->lock); [ 42.699209] lock(&pqueue->lock); [ 42.699418] [ 42.699418] *** DEADLOCK *** [ 42.699418] [ 42.699768] May be due to missing lock nesting notation It's false positive, since all queue spinlocks are initialized via private API which has pqueue as agrument. Fix it by making _rtw_init_queue a macro instead of function + removed unneeded _ prefix. Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/20210908194309.9086-1-paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13staging: vchiq: Replace function typedefs with equivalent declarationOjaswin Mujoo4-10/+6
Replace function typedefs with the equivalent declarations to better align with the linux kenel coding style The following typedefs were changed: * VCHIQ_CONNECTED_CALLBACK_T * vchiq_userdata_term Signed-off-by: Ojaswin Mujoo <ojaswin98@gmail.com> Link: https://lore.kernel.org/r/a8e4e0457b5fcc88c7f297f9d669dfb7e7d91ed5.1631366317.git.ojaswin98@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-13clk: samsung: s5pv210-audss: Make use of devm_platform_ioremap_resource()Cai Huoqing1-3/+1
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210907085122.4305-1-caihuoqing@baidu.com
2021-09-13clk: samsung: exynos5433: Make use of devm_platform_ioremap_resource()Cai Huoqing1-3/+1
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210907085115.4254-1-caihuoqing@baidu.com
2021-09-13clk: samsung: exynos4412-isp: Make use of devm_platform_ioremap_resource()Cai Huoqing1-3/+1
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210907085107.4203-1-caihuoqing@baidu.com
2021-09-13clk: samsung: exynos-audss: Make use of devm_platform_ioremap_resource()Cai Huoqing1-3/+1
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210907085100.4152-1-caihuoqing@baidu.com
2021-09-13soc: qcom: socinfo: Fixed argument passed to platform_set_data()Antonio Martorana1-1/+1
Set qcom_socinfo pointer as data being stored instead of pointer to soc_device structure. Aligns with future calls to platform_get_data() which expects qcom_socinfo pointer. Fixes: efb448d0a3fc ("soc: qcom: Add socinfo driver") Signed-off-by: Antonio Martorana <amartora@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1629159879-95777-1-git-send-email-amartora@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-09-13rpmsg: glink: Replace strncpy() with strscpy_pad()Kees Cook1-1/+1
The use of strncpy() is considered deprecated for NUL-terminated strings[1]. Replace strncpy() with strscpy_pad() (as it seems this case expects the NUL padding to fill the allocation following the flexible array). This additionally silences a warning seen when building under -Warray-bounds: ./include/linux/fortify-string.h:38:30: warning: '__builtin_strncpy' offset 24 from the object at '__mptr' is out of the bounds of referenced subobject 'data' with type 'u8[]' {aka 'unsigned char[]'} at offset 24 [-Warray-bounds] 38 | #define __underlying_strncpy __builtin_strncpy | ^ ./include/linux/fortify-string.h:50:9: note: in expansion of macro '__underlying_strncpy' 50 | return __underlying_strncpy(p, q, size); | ^~~~~~~~~~~~~~~~~~~~ drivers/rpmsg/qcom_glink_native.c: In function 'qcom_glink_work': drivers/rpmsg/qcom_glink_native.c:36:5: note: subobject 'data' declared here 36 | u8 data[]; | ^~~~ [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: linux-remoteproc@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/lkml/20210728020745.GB35706@embeddedor Link: https://lore.kernel.org/r/20210818060533.3569517-4-keescook@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-09-13remoteproc: qcom: Loosen dependency on RPMSG_QCOM_SMDStephen Boyd1-5/+5
There doesn't seem to be any actual build time dependency on the RPMSG_QCOM_SMD, besides that these drivers should be a module if the smd rpmsg code is a module. Drop the compile test dependency so that these drivers can be used without RPMSG_QCOM_SMD being enabled. This is useful for the qcom SoCs that are using RPMSG_QCOM_GLINK_SMEM instead of RPMSG_QCOM_SMD and thus don't want to enable the SMD driver when it is never used. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210823235120.1203512-2-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-09-13remoteproc: qcom: wcnss: Drop unused smd includeStephen Boyd1-1/+0
This include isn't used anymore because the smd functions have been moved to the qcom_common.c file. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210823235120.1203512-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-09-13nvme: avoid race in shutdown namespace removalDaniel Wagner1-8/+7
When we remove the siblings entry, we update ns->head->list, hence we can't separate the removal and test for being empty. They have to be in the same critical section to avoid a race. To avoid breaking the refcounting imbalance again, add a list empty check to nvme_find_ns_head. Fixes: 5396fdac56d8 ("nvme: fix refcounting imbalance when all paths are down") Signed-off-by: Daniel Wagner <dwagner@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Tested-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-09-13nvmet: fix a width vs precision bug in nvmet_subsys_attr_serial_show()Dan Carpenter1-1/+1
This was intended to limit the number of characters printed from "subsys->serial" to NVMET_SN_MAX_SIZE. But accidentally the width specifier was used instead of the precision specifier so it only affects the alignment and not the number of characters printed. Fixes: f04064814c2a ("nvmet: fixup buffer overrun in nvmet_subsys_attr_serial()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-09-13net: wwan: iosm: firmware flashing and coredump collectionM Chetan Kumar14-31/+2055
This patch brings-in support for M.2 7560 Device firmware flashing & coredump collection using devlink. - Driver Registers with Devlink framework. - Register devlink params callback for configuring device params required in flashing or coredump flow. - Implements devlink ops flash_update callback that programs modem firmware. - Creates region & snapshot required for device coredump log collection. On early detection of device in boot rom stage. Driver registers with Devlink framework and establish transport channel for PSI (Primary Signed Image) injection. Once PSI is injected to device, the device execution stage details are read to determine whether device is in flash or exception mode. The collected information is reported to devlink user space application & based on this informationi, application proceeds with either modem firmware flashing or coredump collection. Signed-off-by: M Chetan Kumar <m.chetan.kumar@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-13drm/i915/gvt: fix the usage of ww lock in gvt scheduler.Zhi A Wang1-2/+2
As the APIs related to ww lock in i915 was changed recently, the usage of ww lock in GVT-g scheduler needs to be changed accrodingly. We noticed a deadlock when GVT-g scheduler submits the workload to i915. After some investigation, it seems the way of how to use ww lock APIs has been changed. Releasing a ww now requires a explicit i915_gem_ww_ctx_fini(). Fixes: 67f1120381df ("drm/i915/gvt: Introduce per object locking in GVT scheduler.") Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi A Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210826143834.25410-1-zhi.a.wang@intel.com Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-09-13nfc: mrvl: drop unneeded memory allocation fail messagesKrzysztof Kozlowski1-3/+1
nci_skb_alloc() already prints an error message on memory allocation failure. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.