- 09 Jun, 2014 20 commits
-
-
Aristeu Rozanski authored
commit d2c2b11c upstream. [PATCH v3 1/2] device_cgroup: check if exception removal is allowed When the device cgroup hierarchy was introduced in bd2953eb - devcg: propagate local changes down the hierarchy a specific case was overlooked. Consider the hierarchy bellow: A default policy: ALLOW, exceptions will deny access \ B default policy: ALLOW, exceptions will deny access There's no need to verify when an new exception is added to B because in this case exceptions will deny access to further devices, which is always fine. Hierarchy in device cgroup only makes sure B won't have more access than A. But when an exception is removed (by writing devices.allow), it isn't checked if the user is in fact removing an inherited exception from A, thus giving more access to B. Example: # echo 'a' >A/devices.allow # echo 'c 1:3 rw' >A/devices.deny # echo $$ >A/B/tasks # echo >/dev/null -bash: /dev/null: Operation not permitted # echo 'c 1:3 w' >A/B/devices.allow # echo >/dev/null # This shouldn't be allowed and this patch fixes it by making sure to never allow exceptions in this case to be removed if the exception is partially or fully present on the parent. v3: missing '*' in function description v2: improved log message and formatting fixes Cc: cgroups@vger.kernel.org Cc: Li Zefan <lizefan@huawei.com> Signed-off-by:
Aristeu Rozanski <arozansk@redhat.com> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Aristeu Rozanski authored
commit 79d71974 upstream. Whenever a device file is opened and checked against current device cgroup rules, it uses the same function (may_access()) as when a new exception rule is added by writing devices.{allow,deny}. And in both cases, the algorithm is the same, doesn't matter the behavior. First problem is having device access to be considered the same as rule checking. Consider the following structure: A (default behavior: allow, exceptions disallow access) \ B (default behavior: allow, exceptions disallow access) A new exception is added to B by writing devices.deny: c 12:34 rw When checking if that exception is allowed in may_access(): if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { if (behavior == DEVCG_DEFAULT_ALLOW) { /* the exception will deny access to certain devices */ return true; Which is ok, since B is not getting more privileges than A, it doesn't matter and the rule is accepted Now, consider it's a device file open check and the process belongs to cgroup B. The access will be generated as: behavior: allow exception: c 12:34 rw The very same chunk of code will allow it, even if there's an explicit exception telling to do otherwise. A simple test case: # mkdir new_group # cd new_group # echo $$ >tasks # echo "c 1:3 w" >devices.deny # echo >/dev/null # echo $? 0 This is a serious bug and was introduced on c39a2a30 devcg: prepare may_access() for hierarchy support To solve this problem, the device file open function was split from the new exception check. Second problem is how exceptions are processed by may_access(). The first part of the said function tries to match fully with an existing exception: list_for_each_entry_rcu(ex, &dev_cgroup->exceptions, list) { if ((refex->type & DEV_BLOCK) && !(ex->type & DEV_BLOCK)) continue; if ((refex->type & DEV_CHAR) && !(ex->type & DEV_CHAR)) continue; if (ex->major != ~0 && ex->major != refex->major) continue; if (ex->minor != ~0 && ex->minor != refex->minor) continue; if (refex->access & (~ex->access)) continue; match = true; break; } That means the new exception should be contained into an existing one to be considered a match: New exception Existing match? notes b 12:34 rwm b 12:34 rwm yes b 12:34 r b *:34 rw yes b 12:34 rw b 12:34 w no extra "r" b *:34 rw b 12:34 rw no too broad "*" b *:34 rw b *:34 rwm yes Which is fine in some cases. Consider: A (default behavior: deny, exceptions allow access) \ B (default behavior: deny, exceptions allow access) In this case the full match makes sense, the new exception cannot add more access than the parent allows But this doesn't always work, consider: A (default behavior: allow, exceptions disallow access) \ B (default behavior: deny, exceptions allow access) In this case, a new exception in B shouldn't match any of the exceptions in A, after all you can't allow something that was forbidden by A. But consider this scenario: New exception Existing in A match? outcome b 12:34 rw b 12:34 r no exception is accepted Because the new exception has "w" as extra, it doesn't match, so it'll be added to B's exception list. The same problem can happen during a file access check. Consider a cgroup with allow as default behavior: Access Exception match? b 12:34 rw b 12:34 r no In this case, the access didn't match any of the exceptions in the cgroup, which is required since exceptions will disallow access. To solve this problem, two new functions were created to match an exception either fully or partially. In the example above, a partial check will be performed and it'll produce a match since at least "b 12:34 r" from "b 12:34 rw" access matches. Cc: cgroups@vger.kernel.org Cc: Tejun Heo <tj@kernel.org> Cc: Serge Hallyn <serge.hallyn@canonical.com> Cc: Li Zefan <lizefan@huawei.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit 98b0f811 upstream. The English and Korean translations were updated, the Chinese and Japanese weren't. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Russell King authored
commit 39236901 upstream. When probing with DT, we add each LED one at a time. If we find a LED without a PWM device (because it is not available yet) we fail the initialisation, unregister previous LEDs, and then by way of managed resources, we free the structure. The problem with this is we may have a scheduled and active work_struct in this structure, and this results in a nasty kernel oops. We need to cancel this work_struct properly upon cleanup - and the cleanup we require is the same cleanup as we do when the LED platform device is removed. Rather than writing this same code three times, move it into a separate function and use it in all three places. Fixes: c971ff18 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep") Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Bryan Wu <cooloney@gmail.com> Signed-off-by:
-
Martin Peres authored
commit 61679fe1 upstream. This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: <stable@vger.kernel.org> # 3.9+ Reported-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Tested-by:
Timothée Ravier <tim@siosm.fr> Tested-by: Boris Fersing (IRC nick fersingb, no public email address) Signed-off-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Jani Nikula authored
commit 05adaf1f upstream. Media force wake get hangs the machine when the system is booted without displays attached. The assumption is that (at least some versions of) the firmware has skipped some initialization in that case. Empirical evidence suggests we need to reset the media force wake request register in addition to the render one to avoid hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895Reported-by:
Imre Deak <imre.deak@intel.com> Reported-by:
Darren Hart <dvhart@linux.intel.com> Tested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
commit 806cbc50 upstream. Fixes a regression introduced by 060810d7 "drm/nouveau: fix locking issues in page flipping paths". chan->cli->mutex is unlocked a second time in the fail_unreserve path, fix this by moving mutex_unlock down. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by:
-
Ilia Mirkin authored
commit a3d0b121 upstream. There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Ben Hutchings authored
commit 3234f5b0 upstream. Fixes: a53268be ('rtlwifi: rtl8192cu: Fix too long disable of IRQs') Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Liu Hua authored
commit 8fad87bc upstream. When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will overflow if pfn >= 0x100000 in copy_oldmem_page. So use __pfn_to_phys for converting. Signed-off-by:
Liu Hua <sdu.liu@huawei.com> Signed-off-by:
-
Leif Lindholm authored
commit bfaed5ab upstream. The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for its memory node, relying on an old ppc quirk in order to discover its memory. Fix the data so that all parsing code can handle it correctly. Signed-off-by:
Leif Lindholm <leif.lindholm@linaro.org> Acked-by:
Lee Jones <lee.jones@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Cc: devicetree@vger.kernel.org Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Grant Likely <grant.likely@linaro.org> Signed-off-by:
-
Thomas Petazzoni authored
commit 6e20bae8 upstream. The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit a7d4f818 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') which was merged in v3.10. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com Fixes: a7d4f818 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') Acked-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Thomas Petazzoni authored
commit f3aec8f3 upstream. The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP DB Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit b484ff42 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board') which was merged in v3.11. Signed-off-by:
-
Thomas Petazzoni authored
commit 1a88f809 upstream. The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP GP Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit da8d1b38 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board') which was merged in v3.10. Signed-off-by:
-
Sascha Hauer authored
commit 6d66da89 upstream. The IPU register space is 128MB, not 2GB. Fixes: abed9a6b 'ARM i.MX53: Add IPU support' Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
Shawn Guo <shawn.guo@freescale.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Sebastian Hesselbarth authored
commit 788296b2 upstream. Commit 54397d85 ("ARM: kirkwood: Relocate PCIe device tree nodes") moved the pcie-controller nodes for the Kirkwood SoCs to the mbus bus node. For some reason, two boards were not properly converted and have their pci-controller nodes still in the ocp bus node. As the corresponding SoC pcie-controller does not exist anymore, it is likely that pcie is broken on those boards since above commit. Fix it by moving the pcie related nodes to the correct location. Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Fixes: 54397d85 ("ARM: kirkwood: Relocate PCIe device tree nodes") Acked-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.comSigned-off-by:
-
Thomas Petazzoni authored
commit 1cc9d481 upstream. In commit 4ca2c040 ('ARM: orion5x: Move to ID based window creation'), the mach-orion5x code was changed to use the new mvebu-mbus API. However, in the process, a mistake was made on the crypto SRAM window target ID: it should have been 0x9 (verified in the datasheet) and not 0x0. Signed-off-by:
-
Rik van Riel authored
commit d5c9fde3 upstream. It is possible for "limit - setpoint + 1" to equal zero, after getting truncated to a 32 bit variable, and resulting in a divide by zero error. Using the fully 64 bit divide functions avoids this problem. It also will cause pos_ratio_polynom() to return the correct value when (setpoint - limit) exceeds 2^32. Also uninline pos_ratio_polynom, at Andrew's request. Signed-off-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Christoph Hellwig authored
commit 50c6e282 upstream. Various filesystems don't bother checking for a NULL ACL in posix_acl_equiv_mode, and thus can dereference a NULL pointer when it gets passed one. This usually happens from the NFS server, as the ACL tools never pass a NULL ACL, but instead of one representing the mode bits. Instead of adding boilerplat to all filesystems put this check into one place, which will allow us to remove the check from other filesystems as well later on. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Ben Greear <greearb@candelatech.com> Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>, Cc: Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Mohammed Habibulla authored
commit 1fb4e09a upstream. Add support for the AR9462 chip T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3007 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Mohammed Habibulla <moch@chromium.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
- 06 Jun, 2014 20 commits
-
-
Johan Hedberg authored
commit 9eb1fbfa upstream. Commit 1c2e0041 introduced an event handler for the encryption key refresh complete event with the intent of fixing some LE/SMP cases. However, this event is shared with BR/EDR and there we actually want to act only on the auth_complete event (which comes after the key refresh). If we do not do this we may trigger an L2CAP Connect Request too early and cause the remote side to return a security block error. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Clemens Ladisch authored
commit 7040b6d1 upstream. The TEAC UD-H01 firmware sends wrong feedback frequency values, thus causing the PC to send the samples at a wrong rate, which results in clicks and crackles in the output. Add a workaround to detect and fix the corruption. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> [mick37@gmx.de: use sender->udh01_fb_quirk rather than ep->udh01_fb_quirk in snd_usb_handle_sync_urb()] Reported-and-tested-by:
Mick <mick37@gmx.de> Reported-and-tested-by:
Andrea Messa <andr.messa@tiscali.it> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Stanislaw Gruszka authored
commit 8834d360 upstream. When disable beaconing we clear register with beacon and newer set it back, what make we stop send beacons infinitely. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Daniele Forsi authored
commit 6ed07d45 upstream. Signed-off-by:
Daniele Forsi <dforsi@gmail.com> Signed-off-by:
-
Victor A. Santos authored
commit f0ef5d41 upstream. Signed-off-by:
Victor A. Santos <victoraur.santos@gmail.com> Signed-off-by:
-
Daniele Forsi authored
commit df602c2d upstream. Even if the USB-to-ATAPI converter supported multiple LUNs, this driver would always detect the same physical device or media because it doesn't use srb->device->lun in any way. Tested with an Hewlett-Packard CD-Writer Plus 8200e. Signed-off-by:
-
Alan Stern authored
commit c1db30a2 upstream. Some OHCI controllers from ATI/AMD seem to have difficulty with "global" USB suspend, that is, suspending an entire USB bus without setting the suspend feature for each port connected to a device. When we try to resume the child devices, the controller gives timeout errors on the unsuspended ports, requiring resets, and can even cause ohci-hcd to hang; see http://marc.info/?l=linux-usb&m=139514332820398&w=2 and the following messages. This patch fixes the problem by adding a new quirk flag to ohci-hcd. The flag causes the ohci_rh_suspend() routine to suspend each unsuspended, enabled port before suspending the root hub. This effectively converts the "global" suspend to an ordinary root-hub suspend. There is no need to unsuspend these ports when the root hub is resumed, because the child devices will be resumed anyway in the course of a normal system resume ("global" suspend is never used for runtime PM). This patch should be applied to all stable kernels which include commit 0aa2832d (USB: use "global suspend" for system sleep on USB-2 buses) or a backported version thereof. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Peter Münster <pmlists@free.fr> Tested-by:
-
Jean-Jacques Hiblot authored
commit 886c7c42 upstream. When using dt resources retrieval (interrupts and reg properties) there is no predefined order for these resources in the platform dev resource table. Also don't expect the number of resource to be always 2. Signed-off-by:
Jean-Jacques Hiblot <jjhiblot@traphandler.com> Acked-by:
Boris BREZILLON <b.brezillon@overkiz.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Nikita Yushchenko authored
commit d183c819 upstream. Per reference manuals of Freescale P1020 and P2020 SoCs, USB controller present in these SoCs has bit 17 of USBx_CONTROL register marked as Reserved - there is no PHY_CLK_VALID bit there. Testing for this bit in ehci_fsl_setup_phy() behaves differently on two P1020RDB boards available here - on one board test passes and fsl-usb init succeeds, but on other board test fails, causing fsl-usb init to fail. This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on controller version 1.6 that (per manual) does not have this bit. Signed-off-by:
Nikita Yushchenko <nyushchenko@dev.rtsoft.ru> Signed-off-by:
-
Atilla Filiz authored
commit b9b3a418 upstream. The driver segfaults when the kernel boots with device tree as the platform data is then not present and the pointer is deferenced without checking it is not null. This patch introduces such a check avoiding the crash. Signed-off-by:
Atilla Filiz <atilla.filiz@essensium.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Tuomas Tynkkynen authored
commit d2c834ab upstream. The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Signed-off-by:
Tuomas Tynkkynen <ttynkkynen@nvidia.com> Tested-by:
Mikko Perttunen <mperttunen@nvidia.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Tested-by:
Mike Turquette <mturquette@linaro.org> [mturquette@linaro.org: improved changelog] Signed-off-by:
-
Thierry Reding authored
commit cbfbbabb upstream. The version of the drm_tegra_submit structure that was merged all the way back in 3.10 contains a pad field that was originally intended to properly pad the following __u64 field. Unfortunately it seems like a different field was dropped during review that caused this padding to become unnecessary, but the pad field wasn't removed at that time. One possible side-effect of this is that since the __u64 following the pad is now no longer properly aligned, the compiler may (or may not) introduce padding itself, which results in no predictable ABI. Rectify this by removing the pad field so that all fields are again naturally aligned. Technically this is breaking existing userspace ABI, but given that there aren't any (released) userspace drivers that make use of this yet, the fallout should be minimal. Fixes: d43f81cb ("drm/tegra: Add gr2d device") Signed-off-by:
-
Leo Liu authored
commit 695daf1a upstream. Signed-off-by:
Leo Liu <leo.liu@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Christian König authored
commit f5d636d2 upstream. Testing the update pending bit directly after issuing an update is nonsense cause depending on the pixel clock the CRTC needs a bit of time to execute the flip even when we are in the VBLANK period. This is just a non invasive patch to solve the problem at hand, a more complete and cleaner solution should follow in the next merge window. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76564 v2: fix source IDs for CRTC2-6 Signed-off-by:
-
Christian König authored
commit e4518762 upstream. Some RV7xx generation hardware crashes after you raise the UVD clocks for the first time. Try to avoid this by using the lower clocks to boot these. Workaround for: https://bugzilla.kernel.org/show_bug.cgi?id=71891 v2: lower clocks on IB test as well Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 7e95cfb0 upstream. Should be 5 rather than 4. Noticed-by:
Mathias Fröhlich <Mathias.Froehlich@gmx.net> Signed-off-by:
-
Alex Deucher authored
commit 3ed9a335 upstream. Avoids a crash in certain cases when thermal irqs are generated before the display structures have been initialized. v2: fix the vblank and vrefresh helpers as well bug: https://bugzilla.kernel.org/show_bug.cgi?id=73931Signed-off-by:
-
Alex Deucher authored
commit e9a4099a upstream. Some newer PX laptops have the pci device class set to DISPLAY_OTHER rather than DISPLAY_VGA. This properly detects ATPX on those laptops. Based on a patch from: Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit 8c79bae6 upstream. Avoid a possible segfault. Noticed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Alex Deucher authored
commit 1ebe9280 upstream. May fix stability issues with some newer cards. v2: print out mc firmware version used and size Signed-off-by:
-
