- 15 1月, 2013 3 次提交
-
-
由 Jerome Glisse 提交于
Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Marek Olšák 提交于
Probably not a candidate for stable kernels because of conflicts in DRM versioning. Signed-off-by: NMarek Olšák <maraeo@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Fixes a hard lock in the gpu reset code after the rework for DMA support (0ecebb9e "drm/radeon: switch to a finer grained reset for evergreen") due to not bailing before the MC shutdown if the relevant engines are idle. Discussion: http://lists.freedesktop.org/archives/dri-devel/2013-January/032985.htmlReported-by: NEldad Zack <eldad@fogrefinery.com> Tested-by: NEldad Zack <eldad@fogrefinery.com> Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 14 1月, 2013 3 次提交
-
-
由 Hans de Goede 提交于
This is a left-over from when udl_get_edid returned the amount of bytes successfully read, which it no longer does. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Hans de Goede 提交于
The buffer passed to usb_control_msg may end up in scatter-gather list, and may thus not be on the stack. Having it on the stack usually works on x86, but not on other archs. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Hans de Goede 提交于
udldrmfb only reads the main EDID block, and if that advertises extensions the drm_edid code expects them to be present, and starts reading beyond the buffer udldrmfb passes it. Although it may be possible to read more EDID info with the udl we simpy don't know how, and even if trial and error gets it working on one device, that is no guarantee it will work on other revisions. So this patch does a simple fix in the form of patching the EDID info to report 0 extension blocks, this fixes udldrmfb only doing 1024x768 on monitors with EDID extension blocks. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 1月, 2013 11 次提交
-
-
由 Aleksi Torhamo 提交于
Fixes regression introduced in commit 861d2107 "drm/nouveau/fb: merge fb/vram and port to subdev interfaces" nv50_fb_vram_{new,del} functions were changed to use nouveau_subdev->mutex instead of the old nouveau_mm->mutex. nvc0_fb_vram_new still uses the nouveau_mm->mutex, but nvc0 doesn't have its own fb_vram_del function, using nv50_fb_vram_del instead. Because of this, on nvc0 a different mutex ends up being used to protect additions and deletions to the same list. This patch is a -stable candidate for 3.7. Signed-off-by: NAleksi Torhamo <aleksi@torhamo.net> Reported-by: NRoy Spliet <r.spliet@student.tudelft.nl> Tested-by: NRoy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Aleksi Torhamo 提交于
Fixes regression introduced in commit 70790f4f "drm/nouveau/clock: pull in the implementation from all over the place" When code was moved from nv50_crtc_set_clock to nvc0_clock_pll_set, the PLLs it is used for got limited to only the first two VPLLs. nv50_crtc_set_clock was only called to change VPLLs, so it didn't limit what it was used for in any way. Since nvc0_clock_pll_set is used for all PLLs, it has to specify which PLLs the code is used for, and only listed the first two VPLLs. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58735 This patch is a -stable candidate for 3.7. Signed-off-by: NAleksi Torhamo <aleksi@torhamo.net> Tested-by: NAleksi Torhamo <aleksi@torhamo.net> Tested-by: NSean Santos <quantheory@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Marcin Slusarz 提交于
Analog output number was overwritten by value from digital output path. Fix it. Fixes resume from s2ram: https://bugs.freedesktop.org/show_bug.cgi?id=58729 (as stumbled on by J Binder, Pontus Fuchs and me) Fixes blank screen on module load (reported by Sune Mølgaard). Fixes regression from commit 186ecad2 ("drm/nv50/disp: move remaining interrupt handling into core"). Reported-by: NJ Binder <wheel@herr-der-mails.de> Reported-by: NPontus Fuchs <pontus.fuchs@gmail.com> Reported-by: NSune Mølgaard <sune@molgaard.org> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Tested-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Tested-by: NSune Mølgaard <sune@molgaard.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Since commit 5e120f6e "drm/nouveau/fence: convert to exec engine, and improve channel sync" nouveau fence sync implementation for nv17-50 and nvc0+ started to rely on state of fence buffer left by previous sync operation. But as pinned bo's (where fence state is stored) are not saved+restored across suspend/resume, we need to do it manually. nvc0+ was fixed by commit d6ba6d21 "drm/nvc0/fence: restore pre-suspend fence buffer context on resume". Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Marcin Slusarz 提交于
Commit 2a44e499 ("drm/nouveau/disp: introduce proper init/fini, separate from create/destroy") started to call display init routines on pre-nv50 hardware on module load. But LVDS init code sets driver state in a way which prevents modesetting code from operating properly. nv04_display_init calls nv04_dfp_restore, which sets encoder->last_dpms to NV_DPMS_CLEARED. drm_crtc_helper_set_mode nv04_dfp_prepare nv04_lvds_dpms(DRM_MODE_DPMS_OFF) nv04_lvds_dpms checks last_dpms mode (which is NV_DPMS_CLEARED) and wrongly assumes it's a "powersaving mode", the new one (DRM_MODE_DPMS_OFF) is too, so it skips calling some crucial lvds scripts. Reported-by: NChris Paulson-Ellis <chris@edesix.com> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Marcin Slusarz 提交于
Depending on the point of failure, freed object would be returned or memory leak would happen. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
If we return freed vm, nouveau_drm_open will happily call nouveau_cli_destroy, which will try to free it again. Reported-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Fixes memory corruptions, oopses, etc. when multiple gpuobjs are simultaneously created or destroyed. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Ben Skeggs 提交于
This fix was put in place to fix a bug where the eDP panel on certain laptops fails to respond over the aux channel after suspend. It appears that on some systems (Dell M6600, with LVDS panel) there's a very bad interaction with the eDP init table that causes the SOR to get very confused and not drive the panel correctly, leading to bleed. A DPMS off/on cycle is enough to bring it back, but, this will avoid the problem by not touching the panel GPIOs at times we're not meant to. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Fixes ACPI backlight control after suspend on some systems. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 11 1月, 2013 6 次提交
-
-
由 Jerome Glisse 提交于
We were checking the index against the size of the relocation buffer instead of against the last index. This fix kernel segfault when userspace submit ill formated command stream/relocation buffer pair. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jerome Glisse 提交于
Those rn50 chip are often connected to console remoting hw and load detection often fails with those. Just don't try to load detect and report connect. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Ilija Hadzic 提交于
Index into chunks[] array doesn't look right. Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Ilija Hadzic 提交于
parser->chunks[.].kpage[.] is not always kmalloc-ed by the parser initialization, so parser_fini should not try to kfree it if it didn't allocate it. This patch fixes a kernel oops that can be provoked in UMS mode. Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Ilija Hadzic 提交于
In UMS mode parser->rdev is NULL, so dereferencing will cause an oops. Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Daniel Vetter 提交于
This partially reverts commit 6c085a72 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 20 11:40:46 2012 +0200 drm/i915: Track unbound pages Closer inspection of that patch revealed a bunch of unrelated changes in the shrinker: - The shrinker count is now in pages instead of objects. - For counting the shrinkable objects the old code only looked at the inactive list, the new code looks at all bounds objects (including pinned ones). That is obviously in addition to the new unbound list. - The shrinker cound is no longer scaled with sysctl_vfs_cache_pressure. Note though that with the default tuning value of vfs_cache_pressue = 100 this doesn't affect the shrinker behaviour. - When actually shrinking objects, the old code first dropped purgeable objects, then normal (inactive) objects. Only then did it, in a last-ditch effort idle the gpu and evict everything. The new code omits the intermediate step of evicting normal inactive objects. Safe for the first change, which seems benign, and the shrinker count scaling, which is a bit a different story, the endresult of all these changes is that the shrinker is _much_ more likely to fall back to the last-ditch resort of idling the gpu and evicting everything. The old code could only do that if something else evicted lots of objects meanwhile (since without any other changes the nr_to_scan will be smaller than the object count). Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only dentry/inode object caches should scale their shrinker counts with vfs_cache_pressure. Originally I've had that change reverted, too. But Chris Wilson insisted that it's too bogus and shouldn't again see the light of day. Hence revert all these other changes and restore the old shrinker behaviour, with the minor adjustment that we now first scan the unbound list, then the inactive list for each object category (purgeable or normal). A similar patch has been tested by a few people affected by the gen4/5 hangs which started to appear in 3.7, which some people bisected to the "drm/i915: Track unbound pages" commit. But just disabling the unbound logic alone didn't change things at all. Note that this patch doesn't fix the referenced bugs, it only hides the underlying bug(s) well enough to restore pre-3.7 behaviour. The key to achieve that is to massively reduce the likelyhood of going into a full gpu stall and evicting everything. v2: Reword commit message a bit, taking Chris Wilson's comment into account. v3: On Chris Wilson's insistency, do not reinstate the rather bogus vfs_cache_pressure change. Tested-by: NGreg KH <gregkh@linuxfoundation.org> Tested-by: NDave Kleikamp <dave.kleikamp@oracle.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=55984 References: https://bugs.freedesktop.org/show_bug.cgi?id=57122 References: https://bugs.freedesktop.org/show_bug.cgi?id=56916 References: https://bugs.freedesktop.org/show_bug.cgi?id=57136 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 1月, 2013 2 次提交
-
-
由 Chris Wilson 提交于
This fixes an original bug in the sprite code that miscomputed the source offset into a linear YUV packed framebuffer, that was magnified into an oops with commit 5a35e99e Author: Damien Lespiau <damien.lespiau@intel.com> Date: Fri Oct 26 18:20:12 2012 +0100 drm/i915: adjust sprite base address Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
This proves to be very useful when investigating why code suddenly started failing. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 1月, 2013 15 次提交
-
-
由 Chris Wilson 提交于
This fixes a regression from commit 57779d06 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Oct 31 17:50:14 2012 +0200 drm/i915: Fix display pixel format handling (which even says that they are supported on Ironlake, and then promptly rejects then...) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Avoid clobbering adjacent blocks if they happen to expire earlier and amalgamate together to form the requested hole. In passing this fixes a regression from commit ea7b1dd4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Feb 18 17:59:12 2011 +0100 drm: mm: track free areas implicitly which swaps the end address for size (with a potential overflow) and effectively causes the eviction code to clobber almost all earlier buffers above the evictee. v2: Check the original hole not the adjusted as the coloring may confuse us when later searching for the overlapping nodes. Also make sure that we do apply the range restriction and color adjustment in the same order for both scanning, searching and insertion. v3: Send the version that was actually tested. Note that this seems to be ducttape of decent quality ot paper over some of our unbind related gpu hangs reported since 3.7. It is not fully effective though, and certainly doesn't fix the underlying bug. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Added note plus bugzilla link and tested-by.] Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984Tested-by: NNorbert Preining <preining@logic.at> Acked-by: Dave Airlie <airlied@gmail.com Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Heiko Carstens 提交于
Partially revert ae289dc1 "s390/3215: fix tty close handling", since this leads sometimes to hanging agetty processes and therefore systems that get stuck while starting. This was magically fixed (bisected) by a common code patch from Alan Cox: 36b3c070 "tty: Move the handling of the tty release logic", however it was unrelated. Since the removed code worked for a decade, nobody knows anymore why it was in there in the first place and debugging the observed hang is non-trivial (at least for me :) ), let's just re-add the removed code before we see other side effects. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
-
由 Heiko Carstens 提交于
Now that irq sum accounting for /proc/stat's "intr" line works again we have the oddity that the sum field (first field) contains only the sum of the second (external irqs) and third field (I/O interrupts). The reason for that is that these two fields are already sums of all other fields. So if we would sum up everything we would count every interrupt twice. This is broken since the split interrupt accounting was merged two years ago: 052ff461 "[S390] irq: have detailed statistics for interrupt types". To fix this remove the split interrupt fields from /proc/stat's "intr" line again and only have them in /proc/interrupts. This restores the old behaviour, seems to be the only sane fix and mimics a behaviour from other architectures where /proc/interrupts also contains more than /proc/stat's "intr" line does. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Heiko Carstens 提交于
For more than two years, since f2c66cd8 "/proc/stat: scalability of irq num per cpu" the output of /proc/stat is broken. The first field in the "intr" line should contain the sum of all interrupts, however since the above mentioned change it is always zero. The reason for that is that a per cpu irq sum variable had been introduced which got incremented when calling kstat_incr_irqs_this_cpu(). However on s390 we directly incremented only the per cpu per irq counter by accessing the array element via kstat_cpu(smp_processor_id()).irqs[...]. So fix this and use the kstat_incr_irqs_this_cpu() wrapper which increments both: the per cpu per irq counter and the per cpu irq sum counter. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Daniel Vetter 提交于
Noticed while reviewing the fence locking in the radeon pageflip handler. v2: Instead of grabbing the bdev->fence_lock in object_transfer just move the single callsite of that function a few lines, so that it is protected by the fence_lock. Suggested by Jerome Glisse. v3: Fix typo in commit message. Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Seung-Woo Kim 提交于
Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem makes memory leak. release function of dma-buf cannot be called because f_count of dma-buf increased by importing gem and gem ref count cannot be decrease because of exported dma-buf. So I add dma_buf_put() for imported gem come from its own gem into each drivers having prime_import and prime_export capabilities. With this, only gem ref count is increased if importing gem exported from gem of same driver. Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: NKyungmin.park <kyungmin.park@samsung.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rob Clark <rob.clark@linaro.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ian Campbell 提交于
Using RX_COPY_THRESHOLD is incorrect if the SKB is actually smaller than that. We have already accounted for this in NETFRONT_SKB_CB(skb)->pull_to so use that instead. Fixes WARN_ON from skb_try_coalesce. Signed-off-by: NIan Campbell <ian.campbell@citrix.com> Cc: Sander Eikelenboom <linux@eikelenboom.it> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: annie li <annie.li@oracle.com> Cc: xen-devel@lists.xen.org Cc: netdev@vger.kernel.org Cc: stable@kernel.org # 3.7.x only Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Matthew Garrett 提交于
The 0-day build testing backend noticed that a string could be dereferenced without validation. Fix that. Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Ben Hutchings 提交于
Since commit 8871e99f ('asus-laptop: HRWS/HWRS typo'), module initialisation is very slow on the Asus UL30A. The HWRS method takes about 12 seconds to run, and subsequent initialisation also seems to be delayed. Since we don't really need the result, don't bother calling it on init. Those who are curious can still get the result through the 'infos' device attribute. Update the comment about HWRS in show_infos(). Reported-by: Nryan <draziw+deb@gmail.com> References: http://bugs.debian.org/692436Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Mattia Dongili 提交于
SN06 in some cases returns an Integer instead of a buffer. While the code handling the return value was trying to cope with the difference, the memcpy call was not making any difference between the two types of acpi_object union. This regression was introduced in 3.5. While there also rework the return value logic to improve readability. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=48671 Cc: <stable@vger.kernel.org> Cc: Fabrizio Narni <shibotto@gmail.com> Cc: <mus.svz@gmail.com> Signed-off-by: NMattia Dongili <malattia@linux.it> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Seth Forshee 提交于
BugLink: http://bugs.launchpad.net/bugs/1086921 Cc: stable@vger.kernel.org # v3.4+ Signed-off-by: NSeth Forshee <seth.forshee@canonical.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Sergey Senozhatsky 提交于
Add Aspire 5741G KEY_TOUCHPAD_TOGGLE to wmi keymap, preventing "acer_wmi: Unknown key number - 0x85" error. Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Lee, Chun-Yi 提交于
KEY_TOUCHPAD_TOOGLE key is for notice userland change touchpad state via xf86-input-synaptics on the machine that don't toggle touchpad in hardware. But, acer laptop actually toggle touchpad in hardware. So, this patch change to emit KEY_TOUCHPAD_ON/OFF key when acer-wmi grab device state of touchpad. Reference: brc#848270 https://bugzilla.redhat.com/show_bug.cgi?id=848270Tested-by: NNathanael Noblet <nathanael@gnat.ca> Cc: Carlos Corbacho <carlos@strangeworlds.co.uk> Cc: Matthew Garrett <mjg@redhat.com> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: NLee, Chun-Yi <jlee@suse.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Lee, Chun-Yi 提交于
Fengguang Wu run coccinelle and warns about: drivers/platform/x86/acer-wmi.c:1200:17-21: ERROR: obj is NULL but dereferenced. drivers/platform/x86/acer-wmi.c:891:17-21: ERROR: obj is NULL but dereferenced. drivers/platform/x86/acer-wmi.c:1953:17-21: ERROR: obj is NULL but dereferenced. It causes by the code in patch 987dfbaa doesn't check obj variable should not be NULL. There have risk for dereference a NULL obj, so add this patch to fix. Cc: Carlos Corbacho <carlos@strangeworlds.co.uk> Cc: Matthew Garrett <mjg@redhat.com> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: NLee, Chun-Yi <jlee@suse.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-