- Apr 18, 2023
-
-
Martin Kepplinger authored
-
Martin Kepplinger authored
-
- Apr 11, 2023
-
-
Martin Kepplinger authored
-
Martin Kepplinger authored
Whether the device is powered or suspended, is all taken care of by runtime pm. Replace the state enum with a bool that preserves the streaming state during system suspend. Simplify the suspend/resume functions into one pair of function only, for all cases. Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm>
-
Martin Kepplinger authored
power_off() is called during suspend() unconditionally. That would set the internal "streaming" state to 0. Fix that by not doing that and leaving it up to the callers to decide. That way, the "streaming" state is preserved during system suspend and if streaming is on, it continues after resuming. The driver's power state is now handled correctly, but the actual stream of frames is not continuing after system resume. Let's fix that later.
-
Martin Kepplinger authored
The hi846 driver changed the "streaming" state inside of "start/stop_streaming". The problem is that inside of the (system) suspend callback, it calls "stop_streaming" unconditionally. So streaming would always be stopped when suspending. That makes sense with runtime pm for example, after s_stream(..., 0) but does not preserve the "streaming" state during system suspend when currently streaming. Fix this by simply setting the streaming state outside of "start/stop_streaming" which is s_stream(). While at it, improve things a bit by not assigning "1", but the "enable" value we later compare against, and fix one error handling path in resume(). Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm>
-
Martin Kepplinger authored
pm_runtime_get_if_in_use() does not only return nonzero values when the device is in use, it can return a negative errno too. And especially during resuming from system suspend, when runtime pm is not yet up again, this can very well happen. And in such a case the subsequent pm_runtime_put() call would result in a refcount underflow! Fix it by correctly using pm_runtime_get_if_in_use(). Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm>
-
Martin Kepplinger authored
Clean up the driver a bit by inlining the imx8mq_mipi_csi_system_enable() function to the callsites and removing the hs_settle variable from the driver state. Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Martin Kepplinger authored
Simplify the driver by using the V4L2 subdev active state API to store the active format. Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Martin Kepplinger authored
This is the 6.2.10 stable release
-
Otherwise USB2642 goes into reset and USB devices require reenumeration on resume from suspend. Signed-off-by:
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
-
Although imx8mq doesn't support system wakeup from USB, we still want to use it on Librem 5 in order to keep USB link on during suspend, as otherwise BM818 loses its QMI state. Signed-off-by:
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
-
Although imx8mq doesn't support system wakeup from USB, we still want to use it on Librem 5 in order to keep USB link on during suspend, as otherwise BM818 loses its QMI state. Signed-off-by:
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
-
- Apr 06, 2023
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20230403140416.015323160@linuxfoundation.org Tested-by:
Ronald Warsow <rwarsow@gmx.de> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Conor Dooley <conor.dooley@microchip.com> Tested-by:
Chris Paterson (CIP) <chris.paterson2@renesas.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Markus Reichelt <lkt+2023@mareichelt.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20230405100309.298748790@linuxfoundation.org Tested-by:
Ronald Warsow <rwarsow@gmx.de> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Markus Reichelt <lkt+2023@mareichelt.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Kelsey Steele <kelseysteele@linux.microsoft.com> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Allen Pais <apais@linux.microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sasha Levin authored
This reverts commit dca64f4b which was upstream commit 6d9c7f51. Lockdep warnings on boot that are not seen with Linus's tree. Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Beulich authored
commit aadbd07f upstream. In the commit referenced below I failed to pay attention to this code also being buildable as 32-bit. Adjust the type of "ret" - there's no real need for it to be wider than 32 bits. Fixes: 934ef33e ("x86/PVH: obtain VGA console info in Dom0") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/2d2193ff-670b-0a27-e12d-2c5c4c121c79@suse.com Signed-off-by:
Juergen Gross <jgross@suse.com>
-
Matthieu Baerts authored
commit 1b0120e4 upstream. Recently, when automatically merging -net and net-next in MPTCP devel tree, our CI reported [1] a conflict in hsr, the same as the one reported by Stephen in netdev [2]. When looking at the conflict, I noticed it is in fact the v1 [3] that has been applied in -net and the v2 [4] in net-next. Maybe the v1 was applied by accident. As mentioned by Jakub Kicinski [5], the new condition makes more sense before the net_ratelimit(), not to update net_ratelimit's state which is unnecessary if we're not going to print either way. Here, this modification applies the v2 but in -net. Link: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/4423171069 [1] Link: https://lore.kernel.org/netdev/20230315100914.53fc1760@canb.auug.org.au/ [2] Link: https://lore.kernel.org/netdev/20230307133229.127442-1-koverskeid@gmail.com/ [3] Link: https://lore.kernel.org/netdev/20230309092302.179586-1-koverskeid@gmail.com/ [4] Link: https://lore.kernel.org/netdev/20230308232001.2fb62013@kernel.org/ [5] Fixes: 28e8cabe ("net: hsr: Don't log netdev_err message on unknown prp dst node") Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Reviewed-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/r/20230315-net-20230315-hsr_framereg-ratelimit-v1-1-61d2ef176d11@tessares.net Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Xiaogang Chen authored
commit 8eeddc0d upstream. During miration to vram prange->offset is valid after vram buffer is located, either use old one or allocate a new one. Move svm_range_vram_node_new before migrate for each vma to get valid prange->offset. v2: squash in warning fix Fixes: b4ee9606 ("drm/amdkfd: Fix BO offset for multi-VMA page migration") Signed-off-by:
Xiaogang Chen <Xiaogang.Chen@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andrii Nakryiko authored
[ Upstream commit 4fb877aa ] Fix bug in btf_dump's logic of determining if a given struct type is packed or not. The notion of "natural alignment" is not needed and is even harmful in this case, so drop it altogether. The biggest difference in btf_is_struct_packed() compared to its original implementation is that we don't really use btf__align_of() to determine overall alignment of a struct type (because it could be 1 for both packed and non-packed struct, depending on specifci field definitions), and just use field's actual alignment to calculate whether any field is requiring packing or struct's size overall necessitates packing. Add two simple test cases that demonstrate the difference this change would make. Fixes: ea2ce1ba ("libbpf: Fix BTF-to-C converter's padding logic") Reported-by:
Eduard Zingerman <eddyz87@gmail.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20221215183605.4149488-1-andrii@kernel.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andrii Nakryiko authored
[ Upstream commit b148c8b9 ] Add few hand-crafted cases and few randomized cases found using script from [0] that tests btf_dump's padding logic. [0] https://lore.kernel.org/bpf/85f83c333f5355c8ac026f835b18d15060725fcb.camel@ericsson.com/ Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20221212211505.558851-7-andrii@kernel.org Stable-dep-of: 4fb877aa ("libbpf: Fix btf_dump's packed struct determination") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andrii Nakryiko authored
[ Upstream commit ea2ce1ba ] Turns out that btf_dump API doesn't handle a bunch of tricky corner cases, as reported by Per, and further discovered using his testing Python script ([0]). This patch revamps btf_dump's padding logic significantly, making it more correct and also avoiding unnecessary explicit padding, where compiler would pad naturally. This overall topic turned out to be very tricky and subtle, there are lots of subtle corner cases. The comments in the code tries to give some clues, but comments themselves are supposed to be paired with good understanding of C alignment and padding rules. Plus some experimentation to figure out subtle things like whether `long :0;` means that struct is now forced to be long-aligned (no, it's not, turns out). Anyways, Per's script, while not completely correct in some known situations, doesn't show any obvious cases where this logic breaks, so this is a nice improvement over the previous state of this logic. Some selftests had to be adjusted to accommodate better use of natural alignment rules, eliminating some unnecessary padding, or changing it to `type: 0;` alignment markers. Note also that for when we are in between bitfields, we emit explicit bit size, while otherwise we use `: 0`, this feels much more natural in practice. Next patch will add few more test cases, found through randomized Per's script. [0] https://lore.kernel.org/bpf/85f83c333f5355c8ac026f835b18d15060725fcb.camel@ericsson.com/ Reported-by:
Per Sundström XP <per.xp.sundstrom@ericsson.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20221212211505.558851-6-andrii@kernel.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans de Goede authored
commit 0482c34e upstream. ucsi_init() which runs from a workqueue sets ucsi->connector and on an error will clear it again. ucsi->connector gets dereferenced by ucsi_resume(), this checks for ucsi->connector being NULL in case ucsi_init() has not finished yet; or in case ucsi_init() has failed. ucsi_init() setting ucsi->connector and then clearing it again on an error creates a race where the check in ucsi_resume() may pass, only to have ucsi->connector free-ed underneath it when ucsi_init() hits an error. Fix this race by making ucsi_init() store the connector array in a local variable and only assign it to ucsi->connector on success. Fixes: bdc62f2b ("usb: typec: ucsi: Simplified registration and I/O API") Cc: stable@vger.kernel.org Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230308154244.722337-3-hdegoede@redhat.com Signed-off-by:
Joakim Tjernlund <joakim.tjernlund@infinera.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marc Zyngier authored
commit 8c2e8ac8 upstream. On page fault, we find about the VMA that backs the page fault early on, and quickly release the mmap_read_lock. However, using the VMA pointer after the critical section is pretty dangerous, as a teardown may happen in the meantime and the VMA be long gone. Move the sampling of the MTE permission early, and NULL-ify the VMA pointer after that, just to be on the safe side. Signed-off-by:
Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230316174546.3777507-3-maz@kernel.org Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marc Zyngier authored
commit e86fc1a3 upstream. We walk the userspace PTs to discover what mapping size was used there. However, this can race against the userspace tables being freed, and we end-up in the weeds. Thankfully, the mm code is being generous and will IPI us when doing so. So let's implement our part of the bargain and disable interrupts around the walk. This ensures that nothing terrible happens during that time. We still need to handle the removal of the page tables before the walk. For that, allow get_user_mapping_size() to return an error, and make sure this error can be propagated all the way to the the exit handler. Signed-off-by:
Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230316174546.3777507-2-maz@kernel.org Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Matlack authored
commit 13ec9308 upstream. Read mmu_invalidate_seq before dropping the mmap_lock so that KVM can detect if the results of vma_lookup() (e.g. vma_shift) become stale before it acquires kvm->mmu_lock. This fixes a theoretical bug where a VMA could be changed by userspace after vma_lookup() and before KVM reads the mmu_invalidate_seq, causing KVM to install page table entries based on a (possibly) no-longer-valid vma_shift. Re-order the MMU cache top-up to earlier in user_mem_abort() so that it is not done after KVM has read mmu_invalidate_seq (i.e. so as to avoid inducing spurious fault retries). This bug has existed since KVM/ARM's inception. It's unlikely that any sane userspace currently modifies VMAs in such a way as to trigger this race. And even with directed testing I was unable to reproduce it. But a sufficiently motivated host userspace might be able to exploit this race. Fixes: 94f8e641 ("KVM: ARM: Handle guest faults in KVM") Cc: stable@vger.kernel.org Reported-by:
Sean Christopherson <seanjc@google.com> Signed-off-by:
David Matlack <dmatlack@google.com> Reviewed-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230313235454.2964067-1-dmatlack@google.com Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Reiji Watanabe authored
commit f6da81f6 upstream. Presently, when a guest writes 1 to PMCR_EL0.{C,P}, which is WO/RAZ, KVM saves the register value, including these bits. When userspace reads the register using KVM_GET_ONE_REG, KVM returns the saved register value as it is (the saved value might have these bits set). This could result in userspace setting these bits on the destination during migration. Consequently, KVM may end up resetting the vPMU counter registers (PMCCNTR_EL0 and/or PMEVCNTR<n>_EL0) to zero on the first KVM_RUN after migration. Fix this by not saving those bits when a guest writes 1 to those bits. Fixes: ab946834 ("arm64: KVM: Add access handler for PMCR register") Cc: stable@vger.kernel.org Reviewed-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20230313033234.1475987-1-reijiw@google.com Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Reiji Watanabe authored
commit 9228b261 upstream. Have KVM_GET_ONE_REG for vPMU counter (vPMC) registers (PMCCNTR_EL0 and PMEVCNTR<n>_EL0) return the sum of the register value in the sysreg file and the current perf event counter value. Values of vPMC registers are saved in sysreg files on certain occasions. These saved values don't represent the current values of the vPMC registers if the perf events for the vPMCs count events after the save. The current values of those registers are the sum of the sysreg file value and the current perf event counter value. But, when userspace reads those registers (using KVM_GET_ONE_REG), KVM returns the sysreg file value to userspace (not the sum value). Fix this to return the sum value for KVM_GET_ONE_REG. Fixes: 051ff581 ("arm64: KVM: Add access handler for event counter register") Cc: stable@vger.kernel.org Reviewed-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20230313033208.1475499-1-reijiw@google.com Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ville Syrjälä authored
commit a8e03e00 upstream. SKL/GLK CSC unit suffers from a nasty issue where a CSC coeff/offset register read or write between DC5 exit and PSR exit will undo the CSC arming performed by DMC, and then during PSR exit the hardware will latch zeroes into the active CSC registers. This causes any plane going through the CSC to output all black. We can sidestep the issue by making sure the PSR exit has already actually happened before we touch the CSC coeff/offset registers. Easiest way to guarantee that is to just move the CSC programming back into the .color_commir_arm() as we force a PSR exit (and crucially wait for it to actually happen) prior to touching the arming registers. When PSR (and thus also DC states) are disabled we don't have anything to worry about, so we can keep using the more optional _noarm() hook for writing the CSC registers. Cc: <stable@vger.kernel.org> #v5.19+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8283 Fixes: d13dde44 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-3-ville.syrjala@linux.intel.com Reviewed-by:
Imre Deak <imre.deak@intel.com> (cherry picked from commit 80a892a4) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ville Syrjälä authored
commit 76b767d4 upstream. We're going to want different behavior for skl/glk vs. icl in .color_commit_noarm(), so split the hook into two. Arguably we already had slightly different behaviour since csc_enable/gamma_enable are never set on icl+, so the old code was perhaps a bit confusing as well. Cc: <stable@vger.kernel.org> #v5.19+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-2-ville.syrjala@linux.intel.com Reviewed-by:
Imre Deak <imre.deak@intel.com> (cherry picked from commit f161eb01) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ville Syrjälä authored
commit a2b6e99d upstream. Keeping DC states enabled is incompatible with the _noarm()/_arm() split we use for writing pipe/plane registers. When DC5 and PSR are enabled, all pipe/plane registers effectively become self-arming on account of DC5 exit arming the update, and PSR exit latching it. What probably saves us most of the time is that (with PIPE_MISC[21]=0) all pipe register writes themselves trigger PSR exit, and then we don't re-enter PSR until the idle frame count has elapsed. So it may be that the PSR exit happens already before we've updated the state too much. Also the PSR1 panel (at least on this KBL) seems to discard the first frame we trasmit, presumably still scanning out from its internal framebuffer at that point. So only the second frame we transmit is actually visible. But I suppose that could also be panel specific behaviour. I haven't checked out how other PSR panels behave, nor did I bother to check what the eDP spec has to say about this. And since this really is all about DC states, let's switch from the MODESET domain to the DC_OFF domain. Functionally they are 100% identical. We should probably remove the MODESET domain... And for good measure let's toss in an assert to the place where we do the _noarm() register writes to make sure DC states are in fact off. v2: Just use intel_display_power_is_enabled() (Imre) Cc: <stable@vger.kernel.org> #v5.17+ Cc: Manasi Navare <navaremanasi@google.com> Cc: Drew Davenport <ddavenport@chromium.org> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Fixes: d13dde44 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Fixes: f8a005eb ("drm/i915: Optimize icl+ universal plane programming") Fixes: 890b6ec4 ("drm/i915: Split skl+ plane update into noarm+arm pair") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320183532.17727-1-ville.syrjala@linux.intel.com (cherry picked from commit 41b4c7fe) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ville Syrjälä authored
commit 3413881e upstream. Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... Cc: stable@vger.kernel.org Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Imre Deak <imre.deak@intel.com> Fixes: 0dc987b6 ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320090522.9909-2-ville.syrjala@linux.intel.com Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit 779cb5ba) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chris Wilson authored
commit d032ca43 upstream. i915_gem_object_create_lmem_from_data() lacks the flush of the data written to lmem to ensure the object is marked as dirty and the writes flushed to the backing store. Once created, we can immediately release the obj->mm.mapping caching of the vmap. Fixes: 7acbbc7c ("drm/i915/guc: put all guc objects in lmem when available") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Chris Wilson <chris.p.wilson@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.16+ Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316165918.13074-1-nirmoy.das@intel.com (cherry picked from commit e2ee1047) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Fangzhi Zuo authored
commit 68dc1846 upstream. 8b/10b encoding needs to add 3% fec overhead into the pbn. In the Synapcis Cascaded MST hub, the first stage MST branch device needs the information to determine the timeslot count for the second stage MST branch device. Missing this overhead will leads to insufficient timeslot allocation. Cc: stable@vger.kernel.org Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by:
Fangzhi Zuo <Jerry.Zuo@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Fangzhi Zuo authored
commit f4f3b7de upstream. Traditional synaptics hub has one MST branch device without virtual dpcd. Synaptics cascaded hub has two chained MST branch devices. DSC decoding is performed via root MST branch device, instead of the second MST branch device. Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by:
Fangzhi Zuo <Jerry.Zuo@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tim Huang authored
commit 2fec9dc8 upstream. Skip mode2 reset only for IMU enabled APUs when do S4. This patch is to fix the regression issue https://gitlab.freedesktop.org/drm/amd/-/issues/2483 It is generated by commit b5896266 ("drm/amdgpu: skip ASIC reset for APUs when go to S4"). Fixes: b5896266 ("drm/amdgpu: skip ASIC reset for APUs when go to S4") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2483 Tested-by:
Yuan Perry <Perry.Yuan@amd.com> Signed-off-by:
Tim Huang <tim.huang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lucas Stach authored
commit 963b2e8c upstream. drm_gem_prime_mmap() takes a reference on the GEM object, but before that drm_gem_mmap_obj() already takes a reference, which will be leaked as only one reference is dropped when the mapping is closed. Drop the extra reference when dma_buf_mmap() succeeds. Cc: stable@vger.kernel.org Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby (SUSE) authored
commit 7bb2107e upstream. Expolines depend on scripts/basic/fixdep. And build of expolines can now race with the fixdep build: make[1]: *** Deleting file 'arch/s390/lib/expoline/expoline.o' /bin/sh: line 1: scripts/basic/fixdep: Permission denied make[1]: *** [../scripts/Makefile.build:385: arch/s390/lib/expoline/expoline.o] Error 126 make: *** [../arch/s390/Makefile:166: expoline_prepare] Error 2 The dependence was removed in the below Fixes: commit. So reintroduce the dependence on scripts. Fixes: a0b0987a ("s390/nospec: remove unneeded header includes") Cc: Joe Lawrence <joe.lawrence@redhat.com> Cc: stable@vger.kernel.org Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: linux-s390@vger.kernel.org Signed-off-by:
Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230316112809.7903-1-jirislaby@kernel.org Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heiko Carstens authored
commit 89aba4c2 upstream. Add missing earlyclobber annotation to size, to, and tmp2 operands of the __clear_user() inline assembly since they are modified or written to before the last usage of all input operands. This can lead to incorrect register allocation for the inline assembly. Fixes: 6c2a9e6d ("[S390] Use alternative user-copy operations for new hardware.") Reported-by:
Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/all/20230321122514.1743889-3-mark.rutland@arm.com/ Cc: stable@vger.kernel.org Reviewed-by:
Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Geert Uytterhoeven authored
commit a56cde41 upstream. SPI EEPROMs typically support both SPI Mode 0 (CPOL=CPHA=0) and Mode 3 (CPOL=CPHA=1). However, using the latter is currently flagged as an error by "make dtbs_check", e.g.: arch/arm/boot/dts/r8a7791-koelsch.dtb: flash@0: Unevaluated properties are not allowed ('spi-cpha', 'spi-cpol' were unexpected) From schema: Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml Fix this by documenting support for CPOL=CPHA=1. Fixes: 233363ab ("spi/panel: dt-bindings: drop CPHA and CPOL from common properties") Cc: stable@vger.kernel.org Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/afe470603028db9374930b0c57464b1f6d52bdd3.1676384304.git.geert+renesas@glider.be Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Douglas Raillard authored
commit d18a0415 upstream. Fix the rcutorturename field so that its size is correctly reported in the text format embedded in trace.dat files. As it stands, it is reported as being of size 1: field:char rcutorturename[8]; offset:8; size:1; signed:0; Signed-off-by:
Douglas Raillard <douglas.raillard@arm.com> Reviewed-by:
Mukesh Ojha <quic_mojha@quicinc.com> Cc: stable@vger.kernel.org Fixes: 04ae87a5 ("ftrace: Rework event_create_dir()") Reviewed-by:
Steven Rostedt (Google) <rostedt@goodmis.org> [ boqun: Add "Cc" and "Fixes" tags per Steven ] Signed-off-by:
Boqun Feng <boqun.feng@gmail.com> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-