- 07 Jun, 2014 40 commits
-
-
Yan, Zheng authored
commit 0a8a70f9 upstream. When creating a file, ceph_set_dentry_offset() puts the new dentry at the end of directory's d_subdirs, then set the dentry's offset based on directory's max offset. The offset does not reflect the real postion of the dentry in directory. Later readdir reply from MDS may change the dentry's position/offset. This inconsistency can cause missing/duplicate entries in readdir result if readdir is partly satisfied by dcache_readdir(). The fix is clear directory's completeness after creating/renaming file. It prevents later readdir from using dcache_readdir(). Fixes: http://tracker.ceph.com/issues/8025Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Reviewed-by:
Sage Weil <sage@inktank.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Ertman authored
commit b20a7744 upstream. In commit da1e2046, the flow for enabling/disabling an Si errata workaround (e1000_lv_jumbo_workaround_ich8lan) was changed to fix a problem with iAMT connections dropping on interface down with jumbo frames set. Part of this change was to move the function call disabling the workaround to e1000e_down() from the e1000_setup_rctl() function. The mechanic for disabling of this workaround involves writing several MAC and PHY registers back to hardware defaults. After this commit, when the driver is loaded with the cable out, the PHY registers are not programmed with the correct default values. This causes the device to be capable of transmitting packets, but is unable to recieve them until this workaround is called. The flow of e1000e's open code relies upon calling the above workaround to expicitly program these registers either with jumbo frame appropriate settings or h/w defaults on 82579 and newer hardware. Fix this issue by adding logic to e1000_setup_rctl() that not only calls e1000_lv_jumbo_workaround_ich8lan() when jumbo frames are set, to enable the workaround, but also calls this function to explicitly disable the workaround in the case that jumbo frames are not set. Signed-off-by:
Dave Ertman <davidx.m.ertman@intel.com> Tested-by:
Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Hans de Goede authored
commit 43e19888 upstream. Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD property for for touchpads with top button areas. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Hans de Goede authored
commit f37c0134 upstream. On some newer laptops with a trackpoint the physical buttons for the trackpoint have been removed to allow for a larger touchpad. On these laptops the buttonpad has clearly marked areas on the top which are to be used as trackpad buttons. Users of the event device-node need to know about this, so that they can properly interpret BTN_LEFT events as being a left / right / middle click depending on where on the button pad the clicking finger is. This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers for such buttonpads will use to signal to the user that this buttonpad not only has the normal bottom button area, but also a top button area. Signed-off-by:
-
Hans de Goede authored
commit a7c5868c upstream. Fill in the new serio firmware_id sysfs attribute for pnp instantiated 8042 serio ports. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
-
Hans de Goede authored
commit 0456c66f upstream. serio devices exposed via platform firmware interfaces such as ACPI may provide additional identifying information of use to userspace. We don't associate the serio devices with the firmware device (we don't set it as parent), so there's no way for userspace to make use of this information. We cannot change the parent for serio devices instantiated though a firmware interface as that would break suspend / resume ordering. Therefore this patch adds a new firmware_id sysfs attribute so that userspace can get a string from there with any additional identifying information the firmware interface may provide. Signed-off-by:
-
Chew, Kean ho authored
commit 1b31e9b7 upstream. Add Device ID of Intel BayTrail SMBus Controller. Signed-off-by:
Chew, Kean ho <kean.ho.chew@intel.com> Signed-off-by:
Chew, Chiau Ee <chiau.ee.chew@intel.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: "Chang, Rebecca Swee Fun" <rebecca.swee.fun.chang@intel.com> Signed-off-by:
-
Salva Peiró authored
commit e6a62346 upstream. This fixes CVE-2014-1739. Signed-off-by:
Salva Peiró <speiro@ai2.upv.es> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Dan Carpenter authored
commit 6b4ed8b0 upstream. If the allocation fails then we dereference the NULL in the error path. Just return directly. Fixes: ed27ff1d ('clk: Versatile Express clock generators ("osc") driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Pawel Moll <pawel.moll@arm.com> Signed-off-by:
-
Tim Chen authored
commit 130fa5bc upstream. The crypto algorithm modules utilizing the crypto daemon could be used early when the system start up. Using module_init does not guarantee that the daemon's work queue is initialized when the cypto alorithm depending on crypto_wq starts. It is necessary to initialize the crypto work queue earlier at the subsystem init time to make sure that it is initialized when used. Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
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:
-
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:
-
Emil Goode authored
commit 8fc1e8c2 upstream. When brcm80211 firmware is not installed networking hangs. A deadlock happens because we call ieee80211_unregister_hw() from the .start callback of struct ieee80211_ops. When .start is called we are under rtnl lock and ieee80211_unregister_hw() tries to take it again. Function call stack: dev_change_flags() __dev_change_flags() __dev_open() ASSERT_RTNL() <-- Assert rtnl lock ops->ndo_open() .ndo_open = ieee80211_open, ieee80211_open() ieee80211_do_open() drv_start() local->ops->start() .start = brcms_ops_start, brcms_ops_start() brcms_remove() ieee80211_unregister_hw() rtnl_lock() <-- Here we deadlock Introduced by: commit 25b5632f ("brcmsmac: request firmware in .start() callback") This patch fixes the bug by removing the call to brcms_remove() and moves the brcms_request_fw() call to the top of the .start callback to not initiate anything unless firmware is installed. Signed-off-by:
Emil Goode <emilgoode@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> 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:
-
Christoph Paasch authored
commit b709323d upstream. Prior to cd14ef54 (igb: Change to use statically allocated array for MSIx entries), having msix_entries different from NULL was an indicator that MSIX is enabled. In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to the above patch msix_entries was set to NULL by igb_reset_interrupt_capability. However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the stack gets completly confused: [ 42.659791] ------------[ cut here ]------------ [ 42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb() [ 42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out [ 42.923253] Modules linked in: [ 42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437 [ 43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 [ 43.119215] 0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108 [ 43.208165] ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8 [ 43.297120] ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008 [ 43.386071] Call Trace: [ 43.415303] <IRQ> [<ffffffff81487847>] dump_stack+0x49/0x62 [ 43.484174] [<ffffffff81034e7d>] warn_slowpath_common+0x77/0x91 [ 43.556049] [<ffffffff813fff10>] ? dev_watchdog+0x15c/0x1fb [ 43.623759] [<ffffffff81034f2b>] warn_slowpath_fmt+0x41/0x43 [ 43.692511] [<ffffffff813fff10>] dev_watchdog+0x15c/0x1fb [ 43.758141] [<ffffffff813ffdb4>] ? __netdev_watchdog_up+0x64/0x64 [ 43.832091] [<ffffffff8103cd04>] call_timer_fn+0x17/0x6f [ 43.896682] [<ffffffff8103cebe>] run_timer_softirq+0x162/0x1a2 [ 43.967511] [<ffffffff81038520>] __do_softirq+0xcd/0x1cc [ 44.032104] [<ffffffff81038689>] irq_exit+0x3a/0x48 [ 44.091492] [<ffffffff81026d43>] smp_apic_timer_interrupt+0x43/0x50 [ 44.167525] [<ffffffff8148c24a>] apic_timer_interrupt+0x6a/0x70 [ 44.239392] <EOI> [<ffffffff8100992c>] ? default_idle+0x6/0x8 [ 44.310343] [<ffffffff81009b31>] arch_cpu_idle+0x13/0x18 [ 44.374934] [<ffffffff81066126>] cpu_startup_entry+0xa7/0x101 [ 44.444724] [<ffffffff81025660>] start_secondary+0x1b2/0x1b7 [ 44.513472] ---[ end trace a5a075fd4e7f854f ]--- [ 44.568753] igb 0000:04:00.0 eth0: Reset adapter [ 46.206945] random: nonblocking pool is initialized [ 46.465670] irq 44: nobody cared (try booting with the "irqpoll" option) [ 46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G W 3.14.0-rc2-mptcp #437 [ 46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 [ 46.716641] ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d [ 46.805598] ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400 [ 46.894539] ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8 [ 46.983484] Call Trace: [ 47.012714] <IRQ> [<ffffffff81487847>] dump_stack+0x49/0x62 [ 47.081585] [<ffffffff81068489>] __report_bad_irq+0x35/0xc1 [ 47.149295] [<ffffffff81068683>] note_interrupt+0x16e/0x1ea [ 47.217006] [<ffffffff8106679e>] handle_irq_event_percpu+0x116/0x12e [ 47.294075] [<ffffffff810667e9>] handle_irq_event+0x33/0x4f [ 47.361787] [<ffffffff81068c95>] handle_fasteoi_irq+0x83/0xd1 [ 47.431577] [<ffffffff81003d5b>] handle_irq+0x1f/0x28 [ 47.493047] [<ffffffff81003567>] do_IRQ+0x4e/0xd4 [ 47.550358] [<ffffffff8148b06a>] common_interrupt+0x6a/0x6a [ 47.618066] <EOI> [<ffffffff8100992c>] ? default_idle+0x6/0x8 [ 47.689016] [<ffffffff81009b31>] arch_cpu_idle+0x13/0x18 [ 47.753605] [<ffffffff81066126>] cpu_startup_entry+0xa7/0x101 [ 47.823397] [<ffffffff81025660>] start_secondary+0x1b2/0x1b7 [ 47.892146] handlers: [ 47.919301] [<ffffffff812fbd7d>] igb_intr So, this patch unsets the flag to indicate that we are not using MSIX. This patch does exactly this: Unsetting the flag when falling back to MSI. Fixes: cd14ef54 (igb: Change to use statically allocated array for MSIx entries) Cc: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by:
Christoph Paasch <christoph.paasch@uclouvain.be> Tested-by:
-
Christoph Paasch authored
commit cb06d102 upstream. When igb_set_interrupt_capability() calls igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset), num_q_vectors has been set but no vector has yet been allocated. igb_reset_interrupt_capability() will then call igb_reset_q_vector, which assumes that the vector is allocated. As this is not the case, we are accessing a NULL-pointer. This patch fixes it by checking that q_vector is indeed different from NULL. Fixes: 02ef6e1d (igb: Fix queue allocation method to accommodate changing during runtime) Cc: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by:
-
Dan Carpenter authored
commit c243e963 upstream. If "vf_id" is smaller than hw->func_caps.vf_base_id then it leads to an array underflow of the pf->vf[] array. This is unlikely to happen unless the hardware is bad, but it's a small change and it silences a static checker warning. Fixes: 7efa84b7 ('i40e: support VFs on PFs other than 0') Signed-off-by:
Sibai Li <sibai.li@intel.com> Signed-off-by:
-
Aaron Lu authored
commit 721e82c0 upstream. When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491Reported-by:
Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.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:
-
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:
-
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:
-
Thomas Gleixner authored
commit cf7eb979 upstream. This is another great example of trainwreck engineering: commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support) added support for using EDMA on peripherals which have no direct EDMA event mapping. The code compiles and does not explode in your face, but that's it. 1) Reading an u16 array from an u32 device tree array simply does not work. Even if the function is named "edma_of_read_u32_to_s16_array". It merily calls of_property_read_u16_array. So the resulting 16bit array will have every other entry = 0. 2) The DT entry for the xbar registers related to xbar has length 0x10 instead of the real length: 0xfd0 - 0xf90 = 0x40. Not a real problem as it does not cross a page boundary, but wrong nevertheless. 3) But none of this matters as the mapping never happens: After reading nonsense edma_of_read_u32_to_s16_array() invalidates the first array entry pair, so nobody can ever notice the braindamage by immediate explosion. Seems the QA criteria for this code was solely not to explode when someone adds edma-xbar-event-map entries to the DT. Goal achieved, congratulations! Not really helpful if someone wants to use edma on a device which requires a xbar mapping. Fix the issues by: - annotating the device tree entry with "/bits/ 16" as documented in the of_property_read_u16_array kernel doc - make the size of the xbar register mapping correct - invalidating the end of the array and not the start This convoluted mess wants to be completely rewritten as there is no point to keep the xbar_chan array memory and the iomapping of the xbar regs around forever. Marking the xbar mapped channels as used should be done right there. But that's a different issue and this patch is small enough to make it work and allows a simple backport for stable. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> 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:
-
Johannes Weiner authored
commit 62376251 upstream. This reverts commit 0bf1457f ("mm: vmscan: do not swap anon pages just because free+file is low") because it introduced a regression in mostly-anonymous workloads, where reclaim would become ineffective and trap every allocating task in direct reclaim. The problem is that there is a runaway feedback loop in the scan balance between file and anon, where the balance tips heavily towards a tiny thrashing file LRU and anonymous pages are no longer being looked at. The commit in question removed the safe guard that would detect such situations and respond with forced anonymous reclaim. This commit was part of a series to fix premature swapping in loads with relatively little cache, and while it made a small difference, the cure is obviously worse than the disease. Revert it. Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Reported-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Rafael Aquini <aquini@redhat.com> Cc: Rik van Riel <riel@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Vlastimil Babka authored
commit 49e068f0 upstream. The compaction freepage scanner implementation in isolate_freepages() starts by taking the current cc->free_pfn value as the first pfn. In a for loop, it scans from this first pfn to the end of the pageblock, and then subtracts pageblock_nr_pages from the first pfn to obtain the first pfn for the next for loop iteration. This means that when cc->free_pfn starts at offset X rather than being aligned on pageblock boundary, the scanner will start at offset X in all scanned pageblock, ignoring potentially many free pages. Currently this can happen when a) zone's end pfn is not pageblock aligned, or b) through zone->compact_cached_free_pfn with CONFIG_HOLES_IN_ZONE enabled and a hole spanning the beginning of a pageblock This patch fixes the problem by aligning the initial pfn in isolate_freepages() to pageblock boundary. This also permits replacing the end-of-pageblock alignment within the for loop with a simple pageblock_nr_pages increment. Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Reported-by:
Heesub Shin <heesub.shin@samsung.com> Acked-by:
Minchan Kim <minchan@kernel.org> Cc: Mel Gorman <mgorman@suse.de> Acked-by:
Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Christoph Lameter <cl@linux.com> Acked-by:
Rik van Riel <riel@redhat.com> Cc: Dongjun Shin <d.j.shin@samsung.com> Cc: Sunghwan Yun <sunghwan.yun@samsung.com> 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:
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:
-
Fabian Frederick authored
commit d353efd0 upstream. Commit 842a859d ("affs: use ->kill_sb() to simplify ->put_super() and failure exits of ->mount()") adds .kill_sb which frees sbi but doesn't remove sbi free in case of parse_options error causing double free+random crash. Signed-off-by:
Fabian Frederick <fabf@skynet.be> Cc: Alexander Viro <viro@zeniv.linux.org.uk> 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:
-
Marcel Holtmann authored
commit 3c49aa85 upstream. This reverts commit d2bee8fb. Enabling autosuspend for Intel Bluetooth devices has been shown to not work reliable. It does work for some people with certain combinations of USB host controllers, but for others it puts the device to sleep and it will not wake up for any event. These events can be important ones like HCI Inquiry Complete or HCI Connection Request. The events will arrive as soon as you poke the device with a new command, but that is not something we can do in these cases. Initially there were patches to the xHCI USB controller that fixed this for some people, but not for all. This could be well a problem somewhere in the USB subsystem or in the USB host controllers or just plain a hardware issue somewhere. At this moment we just do not know and the only safe action is to revert this patch. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.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:
-
