- 15 5月, 2012 1 次提交
-
-
由 Vinod Koul 提交于
for cyclic dma, dont makr the descriptor as complte. Fix the remaining users of cyclic dma which do so Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com> Tested-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Tested-by: NMika Westerberg <mika.westerberg@iki.fi>
-
- 11 5月, 2012 1 次提交
-
-
由 Vinod Koul 提交于
the cookie updates completed the cyclic dma descriptor wrongly. This caused the BUG_ON to be hit as submit is called for completed descriptor Fix this by not marking the cyclic descriptor as complete Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com> Tested-by: NThomas Abraham <thomas.abraham@linaro.org>
-
- 25 4月, 2012 2 次提交
-
-
由 Davide Ciminaghi 提交于
When a client calls pl08x_control with DMA_TERMINATE_ALL, it is correct to terminate and release the phy channel currently in use (if one is in use), but the phychan_hold counter must also be reset (otherwise it could get trapped in an unbalanced state). Signed-off-by: NDavide Ciminaghi <ciminaghi@gnudd.com> Reviewed-by: NViresh Kumar <viresh.kumar@st.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
由 Olof Johansson 提交于
Move a couple of tests and do a minor refactor to avoid: drivers/dma/pl330.c: In function 'pl330_probe': drivers/dma/pl330.c:2929:215: warning: comparison of distinct pointer types lacks a cast [enabled by default] drivers/dma/pl330.c: In function 'pl330_tasklet': drivers/dma/pl330.c:2250:8: warning: 'pch' may be used uninitialized in this function [-Wuninitialized] drivers/dma/pl330.c:2228:25: note: 'pch' was declared here drivers/dma/pl330.c:2277:130: warning: 'pch' may be used uninitialized in this function [-Wuninitialized] drivers/dma/pl330.c:2260:25: note: 'pch' was declared here Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
- 23 4月, 2012 3 次提交
-
-
由 Linus Walleij 提交于
A small fallout from Vinod's conversions to dma_transfer_direction, this small comparison was done with a dma_data_direction instead. Fix it by comparing against the correct enum. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
由 Linus Walleij 提交于
The patch "ARM: amba: Remove AMBA level regulator support" breaks the DMA40 driver since the <linux/amba/bus.h> header implicitly included the regulator consumer header. So include it explicitly and fix the build error. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
由 Narayanan G 提交于
can be directly stopped by issuing a SUSPEND_REQ on the EE bits. There is no need to suspend the physical channel and restart it. Also, the support for pre-V2 hw is discontinued. EE bits for writing: 00: disable only if AS=11 or AS=00 01: enable 10: suspend_req only if AS=01 & EE=01 or EE=11 11: round / no change for writing Signed-off-by: NNarayanan G <narayanan.gopalakrishnan@stericsson.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
- 20 4月, 2012 3 次提交
-
-
由 Nicolas Ferre 提交于
This loop on EBCISR register was designed to clear IRQ sources before enabling a DMA channel. This register is clear-on-read so a race condition can appear if another channel is already active and has just finished its transfer. Removing this read on EBCISR is fixing the issue as there is no case where an IRQ could be pending: we already make sure that this register is drained at probe() time and during resume. Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
由 Shawn Guo 提交于
Enable channel in device_issue_pending call, so that the order between cookie assignment and channel enabling can be ensured naturally. It fixes the mxs gpmi-nand breakage which is caused by the incorrect order of cookie assigning and channel enabling. Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Tested-by: NHuang Shijie <b32955@freescale.com> Tested-by <samgandhi9@gmail.com> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
由 Vinod Koul 提交于
the cookie updates completed the cyclic dma descriptor wrongly. This caused the BUG_ON to be hit as submit is called for completed descriptor Fix this by not marking the cyclic descriptor as complete Tested-by: NJavier Martin <javier.martin@vista-silicon.com> Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
-
- 01 4月, 2012 2 次提交
-
-
由 Al Viro 提交于
... and mtdchar_notifier along with it; just have ->drop_inode() that will unconditionally get evict them instead of dances on mtd device removal and use simple_pin_fs() instead of kern_mount() Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Matthew Garrett 提交于
Since 3.2.12 and 3.3, some systems are failing to boot with a BUG_ON. Some other systems using the pata_jmicron driver fail to boot because no disks are detected. Passing pcie_aspm=force on the kernel command line works around it. The cause: commit 4949be16 ("PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled") changed the behaviour of pcie_aspm_sanity_check() to always return 0 if aspm is disabled, in order to avoid cases where we changed ASPM state on pre-PCIe 1.1 devices. This skipped the secondary function of pcie_aspm_sanity_check which was to avoid us enabling ASPM on devices that had non-PCIe children, causing trouble later on. Move the aspm_disabled check so we continue to honour that scenario. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42979 and http://bugs.debian.org/665420 Reported-by: Romain Francoise <romain@orebokech.com> # kernel panic Reported-by: Chris Holland <bandidoirlandes@gmail.com> # disk detection trouble Signed-off-by: NMatthew Garrett <mjg@redhat.com> Cc: stable@vger.kernel.org Tested-by: Hatem Masmoudi <hatem.masmoudi@gmail.com> # Dell Latitude E5520 Tested-by: janek <jan0x6c@gmail.com> # pata_jmicron with JMB362/JMB363 [jn: with more symptoms in log message] Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 31 3月, 2012 10 次提交
-
-
由 Amit Shah 提交于
Use the SET_SYSTEM_SLEEP_PM_OPS macro to initialise the suspend/resume functions in the new PM API. Signed-off-by: NAmit Shah <amit.shah@redhat.com>
-
由 Amit Shah 提交于
There's no difference in supporting S3 and S4 for virtio devices: the vqs have to be re-created as the device has to be assumed to be reset at restore-time. Since S4 already handles this situation, we can directly use the same code and callbacks for S3 support. Signed-off-by: NAmit Shah <amit.shah@redhat.com>
-
由 Amit Shah 提交于
restore_common() was shared between restore and thaw callbacks. With thaw gone, we don't need restore_common() anymore. Signed-off-by: NAmit Shah <amit.shah@redhat.com>
-
由 Amit Shah 提交于
The thaw operation was used by the balloon driver, but after the last commit there's no reason to have separate thaw and restore callbacks. Signed-off-by: NAmit Shah <amit.shah@redhat.com>
-
由 Amit Shah 提交于
There's no reason stats update after restore can't work. If a host requested for stats, and before servicing the request, the guest entered S4, upon restore, the stats request can still be processed and sent off to the host. Signed-off-by: NAmit Shah <amit.shah@redhat.com>
-
由 Lucas De Marchi 提交于
Usage of /etc/modprobe.conf file was deprecated by module-init-tools and is no longer parsed by new kmod tool. References to this file are replaced in Documentation, comments and Kconfig according to the context. There are also some references to the old /etc/modules.conf from 2.4 kernels that are being removed. Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi> Acked-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dan Carpenter 提交于
Using a u64 here creates an endian bug. We store a u32 number in the top byte which is a larger number than intended on big endian systems. There is no reason to use a 64 bit data type here, I guess it was just an oversight. I removed the initialization to zero as well. It's needed with a u64 but with a u32, the variable gets initialized properly inside the call to acpi_os_read_port(). Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Andi Kleen 提交于
On a system on the thermal limit these are quite noisy and flood the logs. Better would be a counter anyways. But given that we don't even have anything for normal throttling this doesn't seem to be urgent either. Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Igor Murzov 提交于
Quoth Dmitry Torokhov: In addition to bus notifier we do install device notifier explicitly so it might fire up early. The easiest fox would be to move acpi_video_bus_start_devices() after input_allocate_device() but before input_register_device() - unregistered input devices can handle input_event() calls just fine. May fix crashes reported in: https://bugzilla.kernel.org/show_bug.cgi?id=40672Signed-off-by: NIgor Murzov <e-mail@date.by> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Igor Murzov 提交于
It is always better to check return values, so add some new checks and correct existing ones. v2: Be consistent and don't mix errors from -E* and AE_* namespaces. Signed-off-by: NIgor Murzov <e-mail@date.by> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 3月, 2012 18 次提交
-
-
由 Matthew Garrett 提交于
ACPI 5.0 adds the BGRT, a table that contains a pointer to the firmware boot splash and associated metadata. This simple driver exposes it via /sys/firmware/acpi in order to allow bootsplash applications to draw their splash around the firmware image and reduce the number of jarring graphical transitions during boot. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Matthew Garrett 提交于
Drivers may wish to add entries to /sys/firmware/acpi, so export acpi_kobj in order to let them do that. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
Make sure the removal of mappings uses the same logic that put the mappings in place. Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Jiang Liu 提交于
The function apei_estatus_print() and apei_estatus_check() forget to move ahead the gdata pointer when dealing with multiple generic error data sections. Signed-off-by: NJiang Liu <jiang.liu@huawei.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex He 提交于
Clean the redundant codes of apci_bus_get_power_flags(). Signed-off-by: NAlex He <alex.he@amd.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Paul E. McKenney 提交于
The acpi_processor_cst_has_changed() function is invoked from a CPU_ONLINE or CPU_DEAD function, which might well execute on CPU 0 even though the CPU being hotplugged is some other CPU. In addition, acpi_processor_cst_has_changed() invokes smp_processor_id() without protection, resulting in splats when onlining CPUs. This commit therefore changes the smp_processor_id() to pr->id, as is used elsewhere in the code, for example, in acpi_processor_add(). Signed-off-by: NPaul E. McKenney <paul.mckenney@linaro.org> Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Tested-by: NYong Zhang <yong.zhang0@gmail.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Jan Beulich 提交于
... so that acpi_unmap()'s behavior gets in sync with acpi_map()'s. Signed-off-by: NJan Beulich <jbeulich@suse.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Yinghai Lu 提交于
During testing pci root bus removal, found some root bus bridge is not freed. If booting with pnpacpi=off, those hostbridge could be freed without problem. It turns out that some devices reference are not released during acpi_pnp_match. that match should not hold one device ref during every calling. Add pu_device calling before returning. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Julia Lawall 提交于
The function acpi_processor_add is stored in the ops.add field of a acpi_driver structure. This function is then called in acpi_bus_driver_init. On failure, this function clears the field device->driver_data, but does not free its contents. Thus the free has to be done by the add function. In acpi_processor_add, the corresponding value is pr. This value is currently freed on failure before storing it in device->driver_data, but not after. This free is added in the error handling code at the end of the function. The per_cpu variable processors is also cleared so that it does not refer to a dangling pointer. Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Gary Hade 提交于
The current code incorrectly assumes that (1) the APEI register bit width is always 8, 16, 32, or 64 and (2) the APEI register bit width is always equal to the APEI register access width. ERST serialization instructions entries such as: [030h 0048 1] Action : 00 [Begin Write Operation] [031h 0049 1] Instruction : 03 [Write Register Value] [032h 0050 1] Flags (decoded below) : 01 Preserve Register Bits : 1 [033h 0051 1] Reserved : 00 [034h 0052 12] Register Region : [Generic Address Structure] [034h 0052 1] Space ID : 00 [SystemMemory] [035h 0053 1] Bit Width : 03 [036h 0054 1] Bit Offset : 00 [037h 0055 1] Encoded Access Width : 03 [DWord Access:32] [038h 0056 8] Address : 000000007F2D7038 [040h 0064 8] Value : 0000000000000001 [048h 0072 8] Mask : 0000000000000007 break this assumption by yielding: [Firmware Bug]: APEI: Invalid bit width in GAR [0x7f2d7038/3/0] I have found no ACPI specification requirements corresponding with the above assumptions. There is even a good example in the Serialization Instruction Entries section (ACPI 4.0 section 17.4,1.2, ACPI 4.0a section 2.5.1.2, ACPI 5.0 section 18.5.1.2) that mentions a serialization instruction with a bit range of [6:2] which is 5 bits wide, _not_ 8, 16, 32, or 64 bits wide. Compile and boot tested with 3.3.0-rc7 on a IBM HX5. Signed-off-by: NGary Hade <garyhade@us.ibm.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Chen Gong 提交于
Some APEI firmware implementation will access injected address specified in param1 to trigger the error when injecting memory error, which means if one SRAR error is injected, the crash always happens because it is executed in kernel context. This new parameter can disable trigger action and control is taken over by the user. In this way, an SRAR error can happen in user context instead of crashing the system. This function is highly depended on BIOS implementation so please ensure you know the BIOS trigger procedure before you enable this switch. v2: notrigger should be created together with param1/param2 Tested-by: NTony Luck <tony.luck@lintel.com> Signed-off-by: NChen Gong <gong.chen@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Chen Gong 提交于
On the platforms with ACPI4.x support, parameter extension is not always doable, which means only parameter extension is enabled, einj_param can take effect. v2->v1: stopping early in einj_get_parameter_address for einj_param Signed-off-by: NChen Gong <gong.chen@linux.intel.com> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Jiang Liu 提交于
This fixes a trivial copy & paste error in ERST header length check. It's just for future safety because sizeof(struct acpi_table_einj) equals to sizeof(struct acpi_table_erst) with current ACPI5.0 specification. It applies to v3.3-rc6. Signed-off-by: NJiang Liu <jiang.liu@huawei.com> Acked-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Boris Ostrovsky 提交于
power_usage is always assigned a negative value and should be declared a signed integer Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@amd.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Boris Ostrovsky 提交于
Currently when a CPU is off-lined it enters either MWAIT-based idle or, if MWAIT is not desired or supported, HLT-based idle (which places the processor in C1 state). This patch allows processors without MWAIT support to stay in states deeper than C1. Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@amd.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Toshi Kani 提交于
acpi_processor_install_hotplug_notify() registers processor objects to receive ACPI CPU hotplug event notifications. This patch additionally registers processor device objects (ACPI0007) to receive the notifications as well. Signed-off-by: NToshi Kani <toshi.kani@hp.com> Reviewed-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Print physical address info in a style consistent with the %pR style used elsewhere in the kernel. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Matthew Garrett 提交于
An HP laptop (Pavilion G4-1016tx) has the following code in _TMP: Store (\_SB.PCI0.LPCB.EC0.RTMP, Local0) If (LGreaterEqual (Local0, S4TP)) { Store (One, HTS4) } S4TP is initialised at 0 and not programmed further until either _HOT or _CRT is called. If we evaluate _TMP before the trip points then HTS4 will always be set, causing the firmware to generate a message on boot complaining that the system shut down because of overheating. The simplest solution is just to reverse the checking of trip points and _TMP in thermal init. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-