- 27 Jul, 2016 40 commits
-
-
Gregor Boirie authored
commit d43a4115 upstream. Temperature channels report scaled samples in Celsius although expected as milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio. Gains are not implemented at all for LPS001WP pressure and temperature channels. This patch ensures that proper offsets and scales are exposed to userpace for both pressure and temperature channels. Also fix a NULL pointer exception when userspace reads content of sysfs scale attribute when gains are not defined. Signed-off-by:
Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Crestez Dan Leonard authored
commit 99543823 upstream. When attaching a pollfunc iio_trigger_attach_poll_func will allocate a virtual irq and call the driver's set_trigger_state function. Fix error handling to undo previous steps if any fails. In particular this fixes handling errors from a driver's set_trigger_state function. When using triggered buffers a failure to enable the trigger used to make the buffer unusable. Signed-off-by:
Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by:
-
Ross Lagerwall authored
commit 842775f1 upstream. Fix a declared-but-not-defined warning when building with XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by commit dfd74a1e ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE"). Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
David Miller authored
commit ef0dab4a upstream. The save/restore buffers for VC state is first composed of a 2-byte control register, then a bunch of 4-byte words. This causes unaligned accesses which trap on platform such as sparc. This is easy to fix by simply moving the buffer pointer forward by 4 bytes instead of 2 after dealing with the control register. The length adjustment needs to be changed likewise as well. Fixes: 5f8fc432 ("PCI: Include pci/pcie/Kconfig directly from pci/Kconfig") Reported-by:
Meelis Roos <mroos@linux.ee> Reported-by:
Anatoly Pugachev <matorola@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Ocquidant, Sebastien authored
commit 8f50b8e5 upstream. In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY is overwritten by the WEEXTRADELAY value from the device tree and GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device tree. As a consequence, the memory accesses cannot be configured properly when the extra delay are needed for OE and WE. Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the device tree file and prevents GPMC_CONFIG4_OEXTRADELAY being overwritten by the WEXTRADELAY value from the device tree. Signed-off-by:
Ocquidant, Sebastien <sebastienocquidant@eaton.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Sinclair Yeh authored
commit 58541f7a upstream. Rather than returning immediately, make sure to unlock the mutexes first. Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
Charmaine Lee <charmainel@vmware.com> Reported-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Thomas Hellstrom authored
commit beca4cf5 upstream. When the surface backing a framebuffer doesn't match the framebuffer's dimensions, the screen target code would test the framebuffer dimensions rather than the surface dimensions when deciding whether to bind the surface as a screen target directly. This causes a screen target - surface dimension mismatch and a subsequent device error. Fix this by testing against the surface dimension. v2: Fix review comments by Sinclair Yeh. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Sinclair Yeh authored
commit d5f1a291 upstream. For the Screen Object display unit, we need to reserve a guest-invisible region equal to the size of the framebuffer for the host. This region can only be reserved in VRAM, whereas the guest-visible framebuffer can be reserved in either VRAM or GMR. As such priority should be given to the guest-invisible region otherwise in a limited VRAM situation, we can fail to allocate this region. This patch makes it so that vmw_sou_backing_alloc() is called before the framebuffer is pinned. Signed-off-by:
-
Sinclair Yeh authored
commit 4ed7e224 upstream. In certain scenarios, e.g. when fbdev is enabled, we can get into a situation where a vmw_framebuffer_pin() is called on a buffer that is already pinned. When this happens, ttm_bo_validate() will unintentially remove the TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way to actually pin the buffer again. To prevent this, if a buffer is already pinned, then instead of calling ttm_bo_validate(), just make sure the proposed placement is compatible with the existing placement. Signed-off-by:
-
Sinclair Yeh authored
commit 7c20d213 upstream. In a low-memory 2D VM, fbdev can take up a large percentage of available memory, making them unavailable for other DRM clients. Since we do not take fbdev into account when filtering modes, we end up claiming to support more modes than we actually do. As a result, users get a black screen when setting a mode too large for current available memory. In a low-memory VM configuration, users can get a black screen for a mode as low as 1024x768. The current mode filtering mechanism keys off of SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount of surface memory we have. Since this value is a performance suggestion, not a hard limit, and since there should not be much of a performance impact for a 2D VM, rather than filtering out more modes, we will just allow ourselves to exceed the SVGA's performance suggestion. Also changed assumed bpp to 32 from 16 to make sure we can actually support all the modes listed. Signed-off-by:
-
Sinclair Yeh authored
commit 04319d89 upstream. Offer an option for advanced users who want larger modes at 16bpp. This becomes necessary after the fix: "Work around mode set failure in 2D VMs." Without this patch, there would be no way for existing advanced users to get to a high res mode, and the regression is they will likely get a black screen after a software update on their current VM. Signed-off-by:
-
Sinclair Yeh authored
commit 94477bff upstream. There are cases where it is desired to see if a proposed placement is compatible with a buffer object before calling ttm_bo_validate(). Signed-off-by:
-
Maarten Lankhorst authored
commit 81e257e9 upstream. Atomic updates may acquire more state than initially locked through drm_modeset_lock_crtc, running with heavy stress can cause a WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc: [ 601.491296] ------------[ cut here ]------------ [ 601.491366] WARNING: CPU: 0 PID: 2411 at drivers/gpu/drm/drm_modeset_lock.c:191 drm_modeset_lock_crtc+0xeb/0xf0 [drm] [ 601.491369] Modules linked in: drm i915 drm_kms_helper [ 601.491414] CPU: 0 PID: 2411 Comm: kms_cursor_lega Tainted: G U 4.7.0-rc4-patser+ #4798 [ 601.491417] Hardware name: Intel Corporation Skylake Client [ 601.491420] 0000000000000000 ffff88044d153c98 ffffffff812ead28 0000000000000000 [ 601.491425] 0000000000000000 ffff88044d153cd8 ffffffff810868e6 000000bf58058030 [ 601.491431] ffff880088b415e8 ffff880458058030 ffff88008a271548 ffff88008a271568 [ 601.491436] Call Trace: [ 601.491443] [<ffffffff812ead28>] dump_stack+0x4d/0x65 [ 601.491447] [<ffffffff810868e6>] __warn+0xc6/0xe0 [ 601.491452] [<ffffffff81086968>] warn_slowpath_null+0x18/0x20 [ 601.491472] [<ffffffffc00d4ffb>] drm_modeset_lock_crtc+0xeb/0xf0 [drm] [ 601.491491] [<ffffffffc00c5526>] drm_mode_cursor_common+0x66/0x180 [drm] [ 601.491509] [<ffffffffc00c91cc>] drm_mode_cursor_ioctl+0x3c/0x40 [drm] [ 601.491524] [<ffffffffc00bc94d>] drm_ioctl+0x14d/0x530 [drm] [ 601.491540] [<ffffffffc00c9190>] ? drm_mode_setcrtc+0x520/0x520 [drm] [ 601.491545] [<ffffffff81176aeb>] ? handle_mm_fault+0x106b/0x1430 [ 601.491550] [<ffffffff81108441>] ? stop_one_cpu+0x61/0x70 [ 601.491556] [<ffffffff811bb71d>] do_vfs_ioctl+0x8d/0x570 [ 601.491560] [<ffffffff81290d7e>] ? security_file_ioctl+0x3e/0x60 [ 601.491565] [<ffffffff811bbc74>] SyS_ioctl+0x74/0x80 [ 601.491571] [<ffffffff810e321c>] ? posix_get_monotonic_raw+0xc/0x10 [ 601.491576] [<ffffffff8175b11b>] entry_SYSCALL_64_fastpath+0x13/0x8f [ 601.491581] ---[ end trace 56f3d3d85f000d00 ]--- For good measure, test mode_config.acquire_ctx too, although this should never happen. Testcase: kms_cursor_legacy Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Boris Brezillon authored
commit 1b7e38b9 upstream. The driver is only enabling scaling, but never disabling it, thus, if you enable the scaling feature once it stays enabled forever. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by:
Alex Vazquez <avazquez.dev@gmail.com> Reviewed-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 1a396789 ("drm: add Atmel HLCDC Display Controller support") Signed-off-by:
-
Huang Rui authored
commit 1dfefee8 upstream. Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Rex Zhu authored
commit 4b242760 upstream. '0' means true. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Rex Zhu authored
commit 1d7b84d1 upstream. the error lead powerplay can't get display info in DGPU case. store_cc6_data just implement in APU. Signed-off-by:
-
Rex Zhu authored
commit 0a4fef55 upstream. before request performance state. Signed-off-by:
Ken Wang <Qingqing.Wang@amd.com> Signed-off-by:
-
Rex Zhu authored
commit 576b4401 upstream. Wrong value passed to acpi_pcie_perf_request. Signed-off-by:
-
Chris Wilson authored
commit afe705be upstream. Since the introduction of (struct_mutex) lockless GEM bo freeing, there are a pair of driver vfuncs for freeing the GEM bo, of which the driver may choose to only implement driver->gem_object_free_unlocked (and so avoid taking the struct_mutex along the free path). However, the CMA GEM helpers were still calling driver->gem_free_object directly, now NULL, and promptly dying on the fancy new lockless drivers. Oops. Robert Foss bisected this to b82caafc (drm/vc4: Use lockless gem BO free callback) on his vc4 device, but that just serves as an enabler for 9f0ba539 (drm/gem: support BO freeing without dev->struct_mutex). Reported-by:
Robert Foss <robert.foss@collabora.com> Fixes: 9f0ba539 (drm/gem: support BO freeing without dev->struct_mutex) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Robert Foss <robert.foss@collabora.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Eric Anholt <eric@anholt.net> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
-
Tomi Valkeinen authored
commit 6709887c upstream. drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so old data may be left there when a new mode is set, possibly causing odd issues. This patch improves the situation by always clearing the state->mode first. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
-
Tomi Valkeinen authored
commit b201e743 upstream. When setting mode via MODE_ID property, drm_atomic_set_mode_prop_for_crtc() does not call drm_mode_set_crtcinfo() which possibly causes: "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't calculate constants, dotclock = 0!" Whether the error is seen depends on the previous data in state->mode, as state->mode is not cleared when setting new mode. This patch adds drm_mode_set_crtcinfo() call to drm_mode_convert_umode(), which is called in both legacy and atomic paths. This should be fine as there's no reason to call drm_mode_convert_umode() without also setting the crtc related fields. drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as that is no longer needed. Signed-off-by:
-
Chris Wilson authored
commit b1924006 upstream. In commit 7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when appropriate") the owner field in the mutex was updated from being dependent upon CONFIG_SMP to using optimistic spin. Update our peek function to suite. Fixes:7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...") Reported-by:
Hong Liu <hong.liu@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> (cherry picked from commit 4f074a53) Signed-off-by:
-
Ville Syrjälä authored
commit 664a84d2 upstream. During hibernation the cached DP port register value will be left with whatever value we have there when we create the hibernation image. Currently that means the port (and eDP PLL) will be off in the cached value. However when we resume there is no guarantee that the value in the actual register will match the cached value. If i915 isn't loaded in the kernel that loads the hibernation image, the port may well be on (eg. left on by the BIOS). The encoder state readout does the right thing in this case and updates our encoder state to reflect the actual hardware state. However the post-resume modeset will then use the stale cached port register value in intel_dp_link_down() and potentially confuse the hardware. This was caught by the following assert WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915] eDP PLL state assertion failure (expected on, current off) on account of the eDP PLL getting prematurely turned off when shutting down the port, since the DP_PLL_ENABLE bit wasn't set in the cached register value. Presumably I introduced this problem in commit 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") as before that we didn't update the cached value after shuttting the port down. That's assuming the port got enabled at least once prior to hibernating. If that didn't happen then the cached value would still have been totally out of sync with reality (eg. first boot w/o eDP on, then hibernate, and then resume with eDP on). So, let's fix this properly and refresh the cached register value from the hardware register during resume. DDI platforms shouldn't use the cached value during port disable at least, so shouldn't have this particular issue. They might still have issues if we skip the initial modeset and then try to retrain the link or something. But untangling this DP vs. DDI mess is a bigger topic, so let's jut punt on DDI for now. Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463162036-27931-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com> (cherry picked from commit 64989ca4) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Lyude authored
commit 1e3fa0ac upstream. >From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : This was kind of a difficult bug to track down. If you're using a Haswell system running GNOME and you have fbc completely enabled and working, playing videos can result in video artifacts. Steps to reproduce: - Run GNOME - Ensure FBC is enabled and active - Download a movie, I used the ogg version of Big Buck Bunny for this - Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin ! glimagesink` in a terminal - Watch for about over a minute, you'll see small horizontal lines go down the screen. For the time being, disable FBC for Haswell by default. Stefan Richter reported kernel freezes (no video artifacts) when fbc is on. (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE applications, thread begins at https://lkml.org/lkml/2016/4/26/813). We also got reports from Steven Honeyman on openbox+roxterm. v2 (From Paulo): - Add extra information to the commit message - Add Fixes tag - Rebase Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464 Fixes: a98ee793 ("drm/i915/fbc: enable FBC by default on HSW and BDW") Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
-
Lyude authored
commit 476490a9 upstream. Thanks to Ville Syrjälä for pointing me towards the cause of this issue. Unfortunately one of the sideaffects of having the refclk for a DPLL set to SSC is that as long as it's set to SSC, the GPU will prevent us from powering down any of the pipes or transcoders using it. A couple of BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL configurations. This causes issues on the first modeset, since we don't expect SSC to be left on and as a result, can't successfully power down the pipes or the transcoders using it. Here's an example from this Dell OptiPlex 990: [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled [drm:intel_modeset_init] 2 display pipes available. [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [drm:intel_crt_reset] crt adpa set to 0xf40000 [drm:intel_dp_init_connector] Adding DP connector on port C [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1 [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0 [drm:ironlake_init_pch_refclk] Disabling SSC entirely … later we try committing the first modeset … [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A [drm:intel_dump_pipe_config] cpu_transcoder: A … [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07 [drm:intel_dump_pipe_config] planes on this crtc [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258 [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600 [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0 [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0 [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A [drm:intel_disable_pipe] disabling pipe A ------------[ cut here ]------------ WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915] pipe_off wait timed out … ---[ end trace 94fc8aa03ae139e8 ]--- [drm:intel_dp_link_down] [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A Later modesets succeed since they reset the DPLL's configuration anyway, but this is enough to get stuck with a big fat warning in dmesg. A better solution would be to add refcounts for the SSC source, but for now leaving the source clock on should suffice. Changes since v4: - Fix calculation of final for systems with LVDS panels (fixes BUG() on CI test suite) Changes since v3: - Move temp variable into loop - Move checks for using_ssc_source to after we've figured out has_ck505 - Add using_ssc_source to debug output Changes since v2: - Fix debug output for when we disable the CPU source Changes since v1: - Leave the SSC source clock on instead of just shutting it off on all of the DPLL configurations. Reviewed-by:
-
Ben Skeggs authored
commit 21721504 upstream. Fixes a regression caused by a stupid thinko from "disp/sor/gf119: both links use the same training register". Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Dmitrii Tcvetkov authored
commit 52dfcc5c upstream. Hello, after this commit: commit f045f459 Author: Ben Skeggs <bskeggs@redhat.com> Date: Thu Jun 2 12:23:31 2016 +1000 drm/nouveau/fbcon: fix out-of-bounds memory accesses kernel started to oops when loading nouveau module when using GTX 780 Ti video adapter. This patch fixes the problem. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=120591Signed-off-by:
Dmitrii Tcvetkov <demfloro@demfloro.ru> Suggested-by:
Ilia Mirkin <imirkin@alum.mit.edu> Fixes: f045f459 ("nouveau_fbcon_init()") Signed-off-by:
-
Ben Skeggs authored
commit 4691409b upstream. Signed-off-by:
-
Ben Skeggs authored
commit f045f459 upstream. Reported by KASAN. Signed-off-by:
-
Ben Skeggs authored
commit 9057c8d7 upstream. Signed-off-by:
-
Ben Skeggs authored
commit 383d0a41 upstream. Signed-off-by:
-
Ben Skeggs authored
commit a8953c52 upstream. It appears that, for whatever reason, both link A and B use the same register to control the training pattern. It's a little odd, as the GPUs before this (Tesla/Fermi1) have per-link registers, as do newer GPUs (Maxwell). Fixes the third DP output on NVS 510 (GK107). Signed-off-by:
-
Ben Skeggs authored
commit bc9139d2 upstream. As it turns out, a value of 0xff means "any protocol" and not "VGA". Signed-off-by:
-
Michael S. Tsirkin authored
commit 87c9403b upstream. Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Reported-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
-
Andrey Grodzovsky authored
commit fd2d2bac upstream. Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch. Fixes: 91a25e46 ("drm/dp/mst: deallocate payload on port destruction") Signed-off-by:
Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Reviewed-by:
-
Oded Gabbay authored
commit bc4755a4 upstream. amdkfd need to destroy the debug manager in case amdkfd's notifier function is called before the unbind function, because in that case, the unbind function will exit without destroying debug manager. Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Oded Gabbay authored
commit 121b78e6 upstream. When unbinding a process from a device (initiated by amd_iommu_v2), the driver needs to make sure that process still exists in the process table. There is a possibility that amdkfd's own notifier handler - kfd_process_notifier_release() - was called before the unbind function and it already removed the process from the process table. v2: Because there can be only one process with the specified pasid, and because *p can't be NULL inside the hash_for_each_rcu macro, it is more reasonable to just put the whole code inside the if statement that compares the pasid value. That way, when we exit hash_for_each_rcu, we simply exit the function as well. Signed-off-by:
-
Richard Weinberger authored
commit 972228d8 upstream. recover_peb() was never power cut aware, if a power cut happened right after writing the VID header upon next attach UBI would blindly use the new partial written PEB and all data from the old PEB is lost. In order to make recover_peb() power cut aware, write the new VID with a proper crc and copy_flag set such that the UBI attach process will detect whether the new PEB is completely written or not. We cannot directly use ubi_eba_atomic_leb_change() since we'd have to unlock the LEB which is facing a write error. Reported-by:
Jörg Pfähler <pfaehler@isse.de> Reviewed-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Nicolas Iooss authored
commit 29b9c528 upstream. amdgpu_cgs_acpi_eval_object() returned the value of variable "result" without initializing it first. This bug has been found by compiling the kernel with clang. The compiler complained: drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: error: variable 'result' is used uninitialized whenever 'for' loop exits because its condition is false [-Werror,-Wsometimes-uninitialized] for (i = 0; i < count; i++) { ^~~~~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:1011:9: note: uninitialized use occurs here return result; ^~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: note: remove the condition if it is always true for (i = 0; i < count; i++) { ^~~~~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:864:12: note: initialize the variable 'result' to silence this warning int result; ^ = 0 Fixes: 3f1d35a0 ("drm/amdgpu: implement new cgs interface for acpi function") Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
-
