- 03 Apr, 2014 9 commits
-
-
Scott Wood authored
commit 5f12c5ec upstream. Fixes a build break due to the undeclared use of irq_of_parse_and_map() and of_iomap(). This build break was apparently introduced while the driver was unbuildable due to the bug fixed by 62c19c9d ("i2c: Remove usage of orphaned symbol OF_I2C"). When 62c19c was added in v3.14-rc7, the driver was enabled again, breaking the powerpc mpc85xx_defconfig and mpc85xx_smp_defconfig. 62c19c is marked for stable, so this should go there as well. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Vrabel authored
commit 5926f87f upstream. This reverts commit a9c8e4be. PTEs in Xen PV guests must contain machine addresses if _PAGE_PRESENT is set and pseudo-physical addresses is _PAGE_PRESENT is clear. This is because during a domain save/restore (migration) the page table entries are "canonicalised" and uncanonicalised". i.e., MFNs are converted to PFNs during domain save so that on a restore the page table entries may be rewritten with the new MFNs on the destination. This canonicalisation is only done for PTEs that are present. This change resulted in writing PTEs with MFNs if _PAGE_PROTNONE (or _PAGE_NUMA) was set but _PAGE_PRESENT was clear. These PTEs would be migrated as-is which would result in unexpected behaviour in the destination domain. Either a) the MFN would be translated to the wrong PFN/page; b) setting the _PAGE_PRESENT bit would clear the PTE because the MFN is no longer owned by the domain; or c) the present bit would not get set. Symptoms include "Bad page" reports when munmapping after migrating a domain. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Acked-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Wei Liu authored
commit 09ed3d5b upstream. Xen balloon driver will update ballooned out pages' P2M entries to point to scratch page for PV guests. In 24f69373 ("xen/balloon: don't alloc page while non-preemptible", kmap_flush_unused was moved after updating P2M table. In that case for 32 bit PV guest we might end up with P2M X -----> S (S is mfn of balloon scratch page) M2P Y -----> X (Y is mfn in persistent kmap entry) kmap_flush_unused() iterates through all the PTEs in the kmap address space, using pte_to_page() to obtain the page. If the p2m and the m2p are inconsistent the incorrect page is returned. This will clear page->address on the wrong page which may cause subsequent oopses if that page is currently kmap'ed. Move the flush back between get_page and __set_phys_to_machine to fix this. Signed-off-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
Hans de Goede authored
commit 6797b39e upstream. The cypress PS/2 trackpad models supported by the cypress_ps2 driver emulate BTN_RIGHT events in firmware based on the finger position, as part of this no motion events are sent when the finger is in the button area. The INPUT_PROP_BUTTONPAD property is there to indicate to userspace that BTN_RIGHT events should be emulated in userspace, which is not necessary in this case. When INPUT_PROP_BUTTONPAD is advertised userspace will wait for a motion event before propagating the button event higher up the stack, as it needs current abs x + y data for its BTN_RIGHT emulation. Since in the cypress_ps2 pads don't report motion events in the button area, this means that clicks in the button area end up being ignored, so INPUT_PROP_BUTTONPAD actually causes problems for these touchpads, and removing it fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76341Reported-by:
Adam Williamson <awilliam@redhat.com> Tested-by:
Peter Hutterer <peter.hutterer@who-t.net> 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 8a0435d9 upstream. This extends Benjamin Tissoires manual min/max quirk table with support for the ThinkPad X240. Signed-off-by:
-
Benjamin Tissoires authored
commit 421e08c4 upstream. The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad. However, these new Synaptics devices report bad axis ranges. Under Windows, it is not a problem because the Windows driver uses RMI4 over SMBus to talk to the device. Under Linux, we are using the PS/2 fallback interface and it occurs the reported ranges are wrong. Of course, it would be too easy to have only one range for the whole series, each touchpad seems to be calibrated in a different way. We can not use SMBus to get the actual range because I suspect the firmware will switch into the SMBus mode and stop talking through PS/2 (this is the case for hybrid HID over I2C / PS/2 Synaptics touchpads). So as a temporary solution (until RMI4 land into upstream), start a new list of quirks with the min/max manually set. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Dmitry Torokhov authored
commit e4dbedc7 upstream. We should not be using static variable mousedev_mix in methods that can be called before that singleton gets assigned. While at it let's add open and close methods to mousedev structure so that we do not need to test if we are dealing with multiplexor or normal device and simply call appropriate method directly. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551Reported-by:
GiulioDP <depasquale.giulio@gmail.com> Tested-by:
-
Al Viro authored
commit b37199e6 upstream. We can get false negative from __lookup_mnt() if an unrelated vfsmount gets moved. In that case legitimize_mnt() is guaranteed to fail, and we will fall back to non-RCU walk... unless we end up running into a hard error on a filesystem object we wouldn't have reached if not for that false negative. IOW, delaying that check until the end of pathname resolution is wrong - we should recheck right after we attempt to cross the mountpoint. We don't need to recheck unless we see d_mountpoint() being true - in that case even if we have just raced with mount/umount, we can simply go on as if we'd come at the moment when the sucker wasn't a mountpoint; if we run into a hard error as the result, it was a legitimate outcome. __lookup_mnt() returning NULL is different in that respect, since it might've happened due to operation on completely unrelated mountpoint. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Theodore Ts'o authored
commit 00a1a053 upstream. Use cmpxchg() to atomically set i_flags instead of clearing out the S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race where an immutable file has the immutable flag cleared for a brief window of time. Reported-by:
John Sullivan <jsrhbz@kanargh.force9.co.uk> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 31 Mar, 2014 31 commits
-
-
Greg Kroah-Hartman authored
-
Ilya Dryomov authored
commit f2be82b0 upstream. The check that makes sure that we have enough memory allocated to read in the entire header of the message in question is currently busted. It compares front_len of the incoming message with iov_len field of ceph_msg::front structure, which is used primarily to indicate the amount of data already read in, and not the size of the allocated buffer. Under certain conditions (e.g. a short read from a socket followed by that socket's shutdown and owning ceph_connection reset) this results in a warning similar to [85688.975866] libceph: get_reply front 198 > preallocated 122 (4#0) and, through another bug, leads to forever hung tasks and forced reboots. Fix this by comparing front_len with front_alloc_len field of struct ceph_msg, which stores the actual size of the buffer. Fixes: http://tracker.ceph.com/issues/5425Signed-off-by:
Ilya Dryomov <ilya.dryomov@inktank.com> Reviewed-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Ilya Dryomov authored
commit 3f0a4ac5 upstream. Rename front local variable to front_len in get_reply() to make its purpose more clear. Signed-off-by:
-
Ilya Dryomov authored
commit 3cea4c30 upstream. Rename front_max field of struct ceph_msg to front_alloc_len to make its purpose more clear. Signed-off-by:
-
Michele Baldessari authored
commit 2b6e0ca1 upstream. In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received different reports of e100 throwing the following warning: [<c06a0ba5>] ? pci_disable_device+0x85/0x90 [<c044a153>] warn_slowpath_fmt+0x33/0x40 [<c06a0ba5>] pci_disable_device+0x85/0x90 [<f7fdf7e0>] __e100_shutdown+0x80/0x120 [e100] [<c0476ca5>] ? check_preempt_curr+0x65/0x90 [<f7fdf8d6>] e100_suspend+0x16/0x30 [e100] [<c06a1ebb>] pci_legacy_suspend+0x2b/0xb0 [<c098fc0f>] ? wait_for_completion+0x1f/0xd0 [<c06a2d50>] ? pci_pm_poweroff+0xb0/0xb0 [<c06a2de4>] pci_pm_freeze+0x94/0xa0 [<c0767bb7>] dpm_run_callback+0x37/0x80 [<c076a204>] ? pm_wakeup_pending+0xc4/0x140 [<c0767f12>] __device_suspend+0xb2/0x1f0 [<c076806f>] async_suspend+0x1f/0x90 [<c04706e5>] async_run_entry_fn+0x35/0x140 [<c0478aef>] ? wake_up_process+0x1f/0x40 [<c0464495>] process_one_work+0x115/0x370 [<c0462645>] ? start_worker+0x25/0x30 [<c0464dc5>] ? manage_workers.isra.27+0x1a5/0x250 [<c0464f6e>] worker_thread+0xfe/0x330 [<c0464e70>] ? manage_workers.isra.27+0x250/0x250 [<c046a224>] kthread+0x94/0xa0 [<c0997f37>] ret_from_kernel_thread+0x1b/0x28 [<c046a190>] ? insert_kthread_work+0x30/0x30 This patch removes pci_disable_device() from __e100_shutdown(). pci_clear_master() is enough. Signed-off-by:
Michele Baldessari <michele@acksyn.org> Tested-by:
Mark Harig <idirectscm@aim.com> Signed-off-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Sarah Sharp authored
commit 1aa9578c upstream. Don Zickus <dzickus@redhat.com> writes: Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. Those ports did not resume correctly (the driver would timeout communicating and fail). This led to frustration as suspend/resume is a common use for laptops. Poking around, I applied the reset on resume quirk to this chipset and the resume started working. Reloading the xhci_hcd module had been the temporary workaround. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by:
Don Zickus <dzickus@redhat.com> Tested-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
-
Ping Cheng authored
commit 961794a0 upstream. New Intuos series models added a hardware switch to turn touch data on/off. The state of the switch is reported periodically from the tablet. To report the state the driver will emit SW_MUTE_DEVICE events. Reviewed_by: Chris Bagwell <chris@cnpbagwell.com> Acked-by:
Jason Gerecke <killertofu@gmail.com> Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
-
Ping Cheng authored
commit b5fd2a3e upstream. Two tablets in this series support both pen and touch. One (Intuos S) only supports pen. This patch also updates the driver to process wireless devices that do not support touch interface. Tested-by:
Chris Bagwell <chris@cnpbagwell.com> Signed-off-by:
-
Ping Cheng authored
commit 1d0d6df0 upstream. Old single touch Tablet PCs do not have touch_max set at wacom_features. Since touch device at lease supports one finger, assign touch_max to 1 when touch usage is defined in its HID Descriptor and touch_max is not pre-defined. Tested-by:
-
Marcelo Tosatti authored
commit 26a865f4 upstream. After free_loaded_vmcs executes, the "loaded_vmcs" structure is kfreed, and now vmx->loaded_vmcs points to a kfreed area. Subsequent free_loaded_vmcs then attempts to manipulate vmx->loaded_vmcs. Switch the order to avoid the problem. https://bugzilla.redhat.com/show_bug.cgi?id=1047892Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Marcelo Tosatti authored
commit 37f6a4e2 upstream. Rom Freiman <rom@stratoscale.com> notes other code paths vulnerable to bug fixed by 989c6b34. Signed-off-by:
-
Marcelo Tosatti authored
commit 989c6b34 upstream. It is possible for __direct_map to be called on invalid root_hpa (-1), two examples: 1) try_async_pf -> can_do_async_pf -> vmx_interrupt_allowed -> nested_vmx_vmexit 2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit Then to load_vmcs12_host_state and kvm_mmu_reset_context. Check for this possibility, let fault exception be regenerated. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Hans de Goede authored
commit c15bdfd5 upstream. The current assumption in the elantech driver that hw version 3 touchpads are never clickpads and hw version 4 touchpads are always clickpads is wrong. There are several bug reports for this, ie: https://bugzilla.redhat.com/show_bug.cgi?id=1030802 http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux I've spend a couple of hours wading through various bugzillas, launchpads and forum posts to create a list of fw-versions and capabilities for different laptop models to find a good method to differentiate between clickpads and versions with separate hardware buttons. Which shows that a device being a clickpad is reliable indicated by bit 12 being set in the fw_version. I've included the gathered list inside the driver, so that we've this info at hand if we need to revisit this later. Signed-off-by:
-
Dave Jones authored
commit c1d867a5 upstream. Distribution kernels might want to build in support for /proc/device-tree for kernels that might end up running on hardware that doesn't support openfirmware. This results in an empty /proc/device-tree existing. Remove it if the OFW root node doesn't exist. This situation actually confuses grub2, resulting in install failures. grub2 sees the /proc/device-tree and picks the wrong install target cf. http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/4300/util/grub-install.in#L311 grub should be more robust, but still, leaving an empty proc dir seems pointless. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=818378. Signed-off-by:
Dave Jones <davej@redhat.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Paul Mackerras <paulus@samba.org> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Gavin Shan authored
commit af87d2fe upstream. As Ben suggested, the patch prints PHB diag-data with multiple fields in one line and omits the line if the fields of that line are all zero. With the patch applied, the PHB3 diag-data dump looks like: PHB3 PHB#3 Diag-data (Version: 1) brdgCtl: 00000002 RootSts: 0000000f 00400000 b0830008 00100147 00002000 nFir: 0000000000000000 0030006e00000000 0000000000000000 PhbSts: 0000001c00000000 0000000000000000 Lem: 0000000000100000 42498e327f502eae 0000000000000000 InAErr: 8000000000000000 8000000000000000 0402030000000000 0000000000000000 PE[ 8] A/B: 8480002b00000000 8000000000000000 [ The current diag data is so big that it overflows the printk buffer pretty quickly in cases when we get a handful of errors at once which can happen. --BenH ] Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Gavin Shan authored
commit 94716604 upstream. The PHB diag-data is important to help locating the root cause for EEH errors such as frozen PE or fenced PHB. However, the EEH core enables IO path by clearing part of HW registers before collecting this data causing it to be corrupted. This patch fixes this by dumping the PHB diag-data immediately when frozen/fenced state on PE or PHB is detected for the first time in eeh_ops::get_state() or next_error() backend. Signed-off-by:
-
Gavin Shan authored
commit 7e4e7867 upstream. For one PCI error relevant OPAL event, we possibly have multiple EEH errors for that. For example, multiple frozen PEs detected on different PHBs. Unfortunately, we didn't cover the case. The patch enumarates the return value from eeh_ops::next_error() and change eeh_handle_special_event() and eeh_ops::next_error() to handle all existing EEH errors. As Ben pointed out, we needn't list_for_each_entry_safe() since we are not deleting any PHB from the hose_list and the EEH serialized lock should be held while purging EEH events. The patch covers those suggestions as well. Signed-off-by:
-
Gavin Shan authored
commit 93aef2a7 upstream. Prior to the completion of PCI enumeration, we actively detects EEH errors on PCI config cycles and dump PHB diag-data if necessary. The EEH backend also dumps PHB diag-data in case of frozen PE or fenced PHB. However, we are using different functions to dump the PHB diag-data for those 2 cases. The patch merges the functions for dumping PHB diag-data to one so that we can avoid duplicate code. Also, we never dump PHB3 diag-data during PCI config cycles with frozen PE. The patch fixes it as well. Signed-off-by:
-
Markus Pargmann authored
commit 66fda75f upstream. There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit 608cfbe4 upstream. The call to clamp_t() first truncates the variable signed 8 bit and as a result, the actual clamp is a no-op. Fixes: 0d78156e ('p54: improve site survey') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Guenter Roeck authored
commit 63238f2c upstream. The following build error is seen if CONFIG_32BIT is undefined, CONFIG_64BIT is defined, and CONFIG_MIPS32_O32 is undefined. asm/syscall.h: In function 'mips_get_syscall_arg': arch/mips/include/asm/syscall.h:32:16: error: unused variable 'usp' [-Werror=unused-variable] cc1: all warnings being treated as errors Fixes: c0ff3c53 ('MIPS: Enable HAVE_ARCH_TRACEHOOK') Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
David Daney <david.daney@cavium.com> Signed-off-by:
John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6160/Signed-off-by:
-
Ben Hutchings authored
commit f8ce239d upstream. builddeb generates a control file that says the linux-headers package can only be built for the build system primary architecture. This breaks cross-building configurations. We should use $debarch for this instead. Since $debarch is not yet set when generating the control file, set Architecture: any and use control file variables to fill in the description. Fixes: cd8d60a2 ('kbuild: create linux-headers package in deb-pkg') Reported-and-tested-by:
"Niew, Sh." <shniew@gmail.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Ben Hutchings authored
commit c5e318f6 upstream. These commands will mysteriously fail: $ make ARCH=arm versatile_defconfig [...] $ make ARCH=arm deb-pkg [...] make[1]: *** [deb-pkg] Error 1 make: *** [deb-pkg] Error 2 The Debian architecture selection for these kernel architectures does 'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this aborts the script if grep does not find the given config symbol. Fixes: 10f26fa6 ('build, deb-pkg: select userland architecture based on UTS_MACHINE') Signed-off-by:
-
Peter Zijlstra authored
commit f428ebd1 upstream. Someone got the load and store barriers mixed up for AAAAARGH64. Turn them the right side up. Reported-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Fixes: a94d342b ("tools/perf: Add required memory barriers") Cc: Ingo Molnar <mingo@kernel.org> Cc: Will Deacon <will.deacon@arm.com> Link: http://lkml.kernel.org/r/20140124154002.GF31570@twins.programming.kicks-ass.netSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Russell King authored
commit e83b3664 upstream. We must use a 64-bit for this, otherwise overflowed bits get lost, and that can result in a lower than intended value set. Fixes: 8e0cb8a1 ("ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations") Fixes: 7d35496d ("ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations") Tested-Acked-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Linus Torvalds authored
commit e4178d80 upstream. This is not a buffer overflow in the traditional sense: we don't overflow any *kernel* buffers, but we do mis-count the amount of data we copy back to user space for the SYSLOG_ACTION_READ_ALL case. In particular, if the user buffer is too small to hold everything, and *if* there is a continuation line at just the right place, we can end up giving the user more data than he asked for. The reason is that we first count up the number of bytes all the log records contains, then we walk the records again until we've skipped the records at the beginning that won't fit, and then we walk the rest of the records and copy them to the user space buffer. And in between that "skip the initial records that won't fit" and the "copy the records that *will* fit to user space", we reset the 'prev' variable that contained the record information for the last record not copied. That meant that when we started copying to user space, we now had a different character count than what we had originally calculated in the first record walk-through. The fix is to simply not clear the 'prev' flags value (in both cases where we had the same logic: syslog_print_all and kmsg_dump_get_buffer: the latter is used for pstore-like dumping) Reported-and-tested-by:
Debabrata Banerjee <dbanerje@akamai.com> Acked-by:
Kay Sievers <kay@vrfy.org> Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Alexei Starovoitov authored
commit fdfaf64e upstream. Commit a998d434 claimed to introduce negative offset support to x86 jit, but it couldn't be working, since at the time of the execution of LD+ABS or LD+IND instructions via call into bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func) had junk value instead of access size in bytes (1 or 2 or 4). Store size into %edx instead of %ecx (what original commit intended to do) Fixes: a998d434 ("bpf jit: Let the x86 jit handle negative offsets") Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Cc: Jan Seiffert <kaffeemonster@googlemail.com> Cc: Eric Dumazet <edumazet@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Trond Myklebust authored
commit e9776d0f upstream. In gss_alloc_msg(), if the call to gss_encode_v1_msg() fails, we want to release the reference to the pipe_version that was obtained earlier in the function. Fixes: 9d3a2260 (SUNRPC: Fix buffer overflow checking in...) Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Ben Peddell authored
commit 4c235cb9 upstream. Commit 65939301 (arm: set initrd_start/initrd_end for fdt scan) caused the FDT initrd_start and initrd_end to override the phys_initrd_start and phys_initrd_size set by the initrd= kernel parameter. With this patch initrd_start and initrd_end will be overridden if phys_initrd_start and phys_initrd_size are set by the kernel initrd= parameter. Fixes: 65939301 (arm: set initrd_start/initrd_end for fdt scan) Signed-off-by:
Ben Peddell <klightspeed@killerwolves.net> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Ben Hutchings authored
commit d9317aea upstream. As part of a workaround for a hardware erratum in the SFC9100 family (SF bug 35388), the TX_DESC_UPD_DWORD register address is also used for communicating with the event block, and only descriptor pointer values < 2048 are valid. If the TX DMA ring size is increased to 4096 descriptors (which the firmware still allows) then we may write a descriptor pointer value >= 2048, which has entirely different and undesirable effects! Limit the TX DMA ring size correctly when this workaround is in effect. Fixes: 8127d661 ('sfc: Add support for Solarflare SFC9100 family') Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
Shradha Shah <sshah@solarflare.com> Signed-off-by:
-
Peter Zijlstra authored
commit 177c53d9 upstream. We must use smp_call_function_single(.wait=1) for the irq_cpu_stop_queue_work() to ensure the queueing is actually done under stop_cpus_lock. Without this we could have dropped the lock by the time we do the queueing and get the race we tried to fix. Fixes: 7053ea1a ("stop_machine: Fix race between stop_two_cpus() and stop_cpus()") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
