- 14 Apr, 2015 7 commits
-
-
Lv Zheng authored
ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT and ACPI_FORMAT_UINT64() instead of ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT(). This patch also removes above replaced macros as there are no users. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/b6061237Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lv Zheng authored
ACPICA commit 7f06739db43a85083a70371c14141008f20b2198 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to convert the %p formats. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/7f06739dSigned-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lv Zheng authored
ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf There are code pieces converting pointers using "(acpi_physical_address) x" or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them. Known issues: 1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field For the conversions around the table fields, it is better to fix it with alignment also fixed. So this patch doesn't modify such code. There should be no functional problem by leaving them unchanged. Link: https://github.com/acpica/acpica/commit/154f6d07Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lv Zheng authored
ACPICA commit c327986430b7eb170c17d0f45735fe71bb62a810 The conversion converts an acpi_physical_address to acpi_physical_address, this patch thus removes such useless conversion. Link: https://github.com/acpica/acpica/commit/c3279864Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lv Zheng authored
ACPICA commit 9e2d8180f4d5e61949b17513bae8aff6412f62dd The offset calculation needn't convert a pointer to a special integer type. So this patch uses ACPI_TO_INTEGER() instead. This patch only affects acpidump tool. Link: https://github.com/acpica/acpica/commit/9e2d8180Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lv Zheng authored
ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lv Zheng authored
This patch reduces source code differences between the Linux kernel and the ACPICA upstream so that the linuxized ACPICA 20150410 release can be applied with reduced human intervention. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 12 Apr, 2015 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs and fs fixes from Al Viro: "Several AIO and OCFS2 fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: ocfs2: _really_ sync the right range ocfs2_file_write_iter: keep return value and current position update in sync [regression] ocfs2: do *not* increment ->ki_pos twice ioctx_alloc(): fix vma (and file) leak on failure fix mremap() vs. ioctx_kill() race
-
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermalLinus Torvalds authored
Pull last minute thermal-SoC management fixes from Eduardo Valentin: "Specifics: - Minor fixes on ST and RCAR thermal drivers. - Avoid flooding kernel log when driver returns -EAGAIN. Note: I am sending this pull on Rui's behalf while he fixes issues in his Linux box" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal: drivers: thermal: st: remove several sparse warnings thermal: constify of_device_id array thermal: Do not log an error if thermal_zone_get_temp returns -EAGAIN thermal: rcar: Fix typo in r8a73a4 SoC name
-
- 11 Apr, 2015 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/soundLinus Torvalds authored
Pull last-minute ASoC fix from Mark Brown: "This patch backs out a change that came in during the merge window which selects a configuration for GPIO4 on pcm512x CODECs that may not be suitable for all systems using the device. Changes for v4.1 will make this properly configurable but for now it's safest to revert to the v3.19 behaviour and leave the pin configuration alone. Sorry for sending this direct at the last minute but due to the GPIO misuse it'd be really good to get it in the release and I'd not realised it hadn't been sent yet - between some travel, a job change and other non-urgent fixes coming in I'd lost track of the urgency. It's been in -next for several weeks now, is isolated to the driver and fairly clear to inspection" * tag 'asoc-fix-v4.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound: ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4
-
Howard Mitchell authored
Currently GPIO4 is hardcoded to output the pll-lock signal. Unfortunately this is after the pll-out GPIO is configured which is selectable in the device tree. Therefore it is not possible to use GPIO4 for pll-out. Therefore this patch removes the configuration of GPIO4. Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Linus Torvalds authored
This reverts commit ecc19d17. It added a new warning to try to encourage driver writers to set the device capabities properly, but drivers haven't been updated and in the meantime it just generaters a scary message that users cannot actually do anything about. Warnings like these are appropriate if you actually expect to fix the code that causes them. They are not appropriate for releases. Requested-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Jan Engelhardt reports a strange oops with an invalid ->sense_buffer pointer in scsi_init_cmd_errh() with the blk-mq code. The sense_buffer pointer should have been initialized by the call to scsi_init_request() from blk_mq_init_rq_map(), but there seems to be some non-repeatable memory corruptor. This patch makes sure we initialize the whole struct request allocation (and the associated 'struct scsi_cmnd' for the SCSI case) to zero, by using __GFP_ZERO in the allocation. The old code initialized a couple of individual fields, leaving the rest undefined (although many of them are then initialized in later phases, like blk_mq_rq_ctx_init() etc. It's not entirely clear why this matters, but it's the rigth thing to do regardless, and with 4.0 imminent this is the defensive "let's just make sure everything is initialized properly" patch. Tested-by: Jan Engelhardt <jengelh@inai.de> Acked-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds authored
Pull dmaengine fix from Vinod Koul: "I have one more fix to fix the boot warning on cppi driver due to missing capabilities" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: cppi41: add missing bitfields
-
git://git.code.sf.net/p/openipmi/linux-ipmiLinus Torvalds authored
Pull late ipmi fixes from Corey Minyard: "Some annoying issues in the IPMI driver that would be good to have fixed before 4.0 is released. These got reported or discovered late, but they will avoid some situations that would cause lots of log spam and in one case a deadlock" * tag 'for-linus-4.0-1' of git://git.code.sf.net/p/openipmi/linux-ipmi: ipmi_ssif: Use interruptible completion for waiting in the thread ipmi/powernv: Fix minor locking bug ipmi: Handle BMCs that don't allow clearing the rcv irq bit
-
Felipe Balbi authored
Add missing directions, residue_granularity, srd_addr_widths and dst_addr_widths bitfields. Without those we will see a kernel WARN() when loading musb on am335x devices. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Corey Minyard authored
The code was using an normal completion, but that caused stuck task errors after a while. Use an interruptible one to avoid that. Signed-off-by: Corey Minyard <cminyard@mvista.com>
-
Alistair Popple authored
If ipmi_powernv_recv(...) is called without a current message it prints a warning and returns. However it fails to release the message lock causing the system to dead lock during any subsequent IPMI operations. This error path should never normally be taken unless there are bugs elsewhere in the system. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
-
Corey Minyard authored
Some BMCs don't let you clear the receive irq bit in the global enables. This is kind of silly, but they give an error if you try to clear it. Compensate for this by detecting the situation and working around it. Signed-off-by: Corey Minyard <cminyard@mvista.com> Tested-by: Thomas D <whissi@whissi.de> Reviewed-by: Thomas D <whissi@whissi.de>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "This is our remaining set of three fixes for 4.0: two oops fixes(one for cable pulls triggering oopses and the other be2iscsi specific) and one warn on in sysfs on multipath devices using enclosures" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: Defer processing of REQ_PREEMPT requests for blocked devices be2iscsi: Fix kernel panic when device initialization fails enclosure: fix WARN_ON removing an adapter in multi-path devices
-
- 10 Apr, 2015 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pendingLinus Torvalds authored
Pull SCSI target fixes from Nicholas Bellinger: "Just a few small fixes: Two from Andy, the first addresses a v4.0 target specific regression to a user visible configfs attribute, and the second adds a set of missing brackets around IPv6 discovery portal information within iscsi-target. And one from Mike that fixes an OOPs regression in traditional iscsi-target when an iovec allocation fails, that has been present since v3.10.y code. (CC'd to stable)" * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: iscsi target: fix oops when adding reject pdu iscsi-target: TargetAddress in SendTargets should bracket ipv6 addresses target: Allow userspace to write 1 to attrib/emulate_fua_write
-
Mike Christie authored
This fixes a oops due to a double list add when adding a reject PDU for iscsit_allocate_iovecs allocation failures. The cmd has already been added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call iscsit_reject_cmd. Note that for ERL0 the reject PDU is not actually sent, so this patch is not completely tested. Just verified we do not oops. The problem is the add reject functions return -1 which is returned all the way up to iscsi_target_rx_thread which for ERL0 will drop the connection. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
Pull sound fixes from Takashi Iwai: "Here are fixes gathered for 4.0-final; one FireFire endian fix, two USB-audio quirks, and three HD-audio quirks. All relatively small and device-specific fixes, should be pretty safe to apply" * tag 'sound-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support ALSA: hda - Fix headphone pin config for Lifebook T731 ALSA: bebob: fix to processing in big-endian machine for sending cue ALSA: hda/realtek - Make more stable to get pin sense for ALC283 ALSA: usb-audio: don't try to get Benchmark DAC1 sample rate ALSA: hda/realtek - Support Dell headset mode for ALC256
-
git://git.rocketboards.org/linux-socfpga-nextLinus Torvalds authored
Pull arch/nios2 fixes from Ley Foon Tan: "There are 3 arch/nios2 fixes for 4.0 final: - fix cache coherency issue when debugging with gdb - move restart_block to struct task_struct (aligned with other architectures) - fix for missing registers defines for ptrace" * tag 'nios2-fixes-v4.0-final' of git://git.rocketboards.org/linux-socfpga-next: nios2: fix cache coherency issue when debug with gdb nios2: add missing ptrace registers defines nios2: signal: Move restart_block to struct task_struct
-
Ley Foon Tan authored
Remove the end address checking for flushda function. We need to flush each address line for flushda instruction, from start to end address. This is because flushda instruction only flush the cache if tag and line fields are matched. Change to use ldwio instruction (bypass cache) to load the instruction that causing trap. Our interest is the actual instruction that executed by the processor, this should be uncached. Note, EA address might be an userspace cached address. Signed-off-by: Ley Foon Tan <lftan@altera.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management and ACPI fixes from Rafael Wysocki: "These are stable-candidate fixes of some recently reported issues in the cpufreq core, cpuidle core, the ACPI cpuidle driver and the hibernate core. Specifics: - Revert a 3.17 hibernate commit that was supposed to fix an issue related to e820 reserved regions, but broke resume from hibernation on Lenovo x230 (Rafael J Wysocki). - Prevent the ACPI cpuidle driver from overwriting the name and description of the C0 state set by the core when the list of C-states changes (Thomas Schlichter). - Remove the no longer needed state_count field from struct cpuidle_device which prevents the list of C-states shown by the sysfs interface from becoming incorrect when the current number of them is different from the number of C-states on boot (Bartlomiej Zolnierkiewicz). - The cpufreq core updates the policy object of the only online CPU during system resume to make it reflect the current hardware state, but it always assumes that CPU to be CPU0 which need not be the case, so fix the code to avoid that assumption (Viresh Kumar)" * tag 'pm+acpi-4.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions" cpuidle: ACPI: do not overwrite name and description of C0 cpuidle: remove state_count field from struct cpuidle_device cpufreq: Schedule work for the first-online CPU on resume
-
- 09 Apr, 2015 5 commits
-
-
Rafael J. Wysocki authored
* pm-sleep: Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions" * pm-cpufreq: cpufreq: Schedule work for the first-online CPU on resume * pm-cpuidle: cpuidle: ACPI: do not overwrite name and description of C0 cpuidle: remove state_count field from struct cpuidle_device
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fixes from Bjorn Helgaas: "Here are some fixes for v4.0. I apologize for how late they are. We were hoping for some better fixes, but couldn't get them polished in time. These fix: - a Xen domU oops with PCI passthrough devices - a sparc T5 boot failure - a STM SPEAr13xx crash (use after initdata freed) - a cpcihp hotplug driver thinko - an AER thinko that printed stack junk Details: Enumeration - Don't look for ACPI hotplug parameters if ACPI is disabled (Bjorn Helgaas) Resource management - Revert "sparc/PCI: Clip bridge windows to fit in upstream windows" (Bjorn Helgaas) AER - Avoid info leak in __print_tlp_header() (Rasmus Villemoes) PCI device hotplug - Add missing curly braces in cpci_configure_slot() (Dan Carpenter) ST Microelectronics SPEAr13xx host bridge driver - Drop __initdata from spear13xx_pcie_driver (Matwey V. Kornilov) * tag 'pci-v4.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: Revert "sparc/PCI: Clip bridge windows to fit in upstream windows" PCI: Don't look for ACPI hotplug parameters if ACPI is disabled PCI: cpcihp: Add missing curly braces in cpci_configure_slot() PCI/AER: Avoid info leak in __print_tlp_header() PCI: spear: Drop __initdata from spear13xx_pcie_driver
-
Dmitry M. Fedin authored
Adds an entry for Creative USB X-Fi to the rc_config array in mixer_quirks.c to allow use of volume knob on the device. Adds support for newer X-Fi Pro card, known as "Model No. SB1095" with USB ID "041e:3237" Signed-off-by: Dmitry M. Fedin <dmitry.fedin@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Al Viro authored
"ocfs2 syncs the wrong range" had been broken; prior to it the code was doing the wrong thing in case of O_APPEND, all right, but _after_ it we were syncing the wrong range in 100% cases. *ppos, aka iocb->ki_pos is incremented prior to that point, so we are always doing sync on the area _after_ the one we'd written to. Spotted by Joseph Qi <joseph.qi@huawei.com> back in January; unfortunately, I'd missed his mail back then ;-/ Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Ley Foon Tan authored
These are all register available in nios2. Signed-off-by: Ley Foon Tan <lftan@altera.com>
-
- 08 Apr, 2015 8 commits
-
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Final drm fixes: one core locking imbalance regression, and a bunch of i915 baytrail s/r fixes" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm: fix drm_mode_getconnector() locking imbalance regression drm/i915/vlv: remove wait for previous GFX clk disable request drm/i915/chv: Remove Wait for a previous gfx force-off drm/i915/vlv: save/restore the power context base reg
-
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds authored
Pull ceph revert from Sage Weil: "This corrects a recent misadventure with __GFP_MEMALLOC and PF_MEMALLOC; it turns out it's not a good fit for RBD and we're better off relying on dirty page throttling" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: Revert "libceph: use memalloc flags for net IO"
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "Three fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mm: numa: disable change protection for vma(VM_HUGETLB) include/linux/dmapool.h: declare struct device mm: move zone lock to a different cache line than order-0 free page lists
-
Linus Torvalds authored
Unlike most (all?) other copies from user space, kernel module loading is almost unlimited in size. So we do a potentially huge "copy_from_user()" when we copy the module data from user space to the kernel buffer, which can be a latency concern when preemption is disabled (or voluntary). Also, because 'copy_from_user()' clears the tail of the kernel buffer on failures, even a *failed* copy can end up wasting a lot of time. Normally neither of these are concerns in real life, but they do trigger when doing stress-testing with trinity. Running in a VM seems to add its own overheadm causing trinity module load testing to even trigger the watchdog. The simple fix is to just chunk up the module loading, so that it never tries to copy insanely big areas in one go. That bounds the latency, and also the amount of (unnecessarily, in this case) cleared memory for the failure case. Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
The rule for 'copy_from_user()' is that it zeroes the remaining kernel buffer even when the copy fails halfway, just to make sure that we don't leave uninitialized kernel memory around. Because even if we check for errors, some kernel buffers stay around after thge copy (think page cache). However, the x86-64 logic for user copies uses a copy_user_generic() function for all the cases, that set the "zerorest" flag for any fault on the source buffer. Which meant that it didn't just try to clear the kernel buffer after a failure in copy_from_user(), it also tried to clear the destination user buffer for the "copy_in_user()" case. Not only is that pointless, it also means that the clearing code has to worry about the tail clearing taking page faults for the user buffer case. Which is just stupid, since that case shouldn't happen in the first place. Get rid of the whole "zerorest" thing entirely, and instead just check if the destination is in kernel space or not. And then just use memset() to clear the tail of the kernel buffer if necessary. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
three commits, all cc: stable, to address Baytrail suspend/resume issues. * tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel: drm/i915/vlv: remove wait for previous GFX clk disable request drm/i915/chv: Remove Wait for a previous gfx force-off drm/i915/vlv: save/restore the power context base reg
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
generic_file_direct_write() already does that. Broken by "ocfs2: do not fallback to buffer I/O write if appending" Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-