- 17 1月, 2012 2 次提交
-
-
由 Huang Ying 提交于
On one of our testing machine, the following EINJ command lines: # echo 0x10000000 > param1 # echo 0xfffffffffffff000 > param2 # echo 0x8 > error_type # echo 1 > error_inject Will get: echo: write error: Input/output error The EIO comes from: rc = apei_exec_pre_map_gars(&trigger_ctx); The root cause is as follow. Normally, ACPI atomic IO support is used to access IO memory. But in EINJ of that machine, it is used to access RAM to trigger the injected error. And the ioremap() called by apei_exec_pre_map_gars() can not map the RAM. This patch add RAM mapping support to ACPI atomic IO support to satisfy EINJ requirement. Signed-off-by: NHuang Ying <ying.huang@intel.com> Tested-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Huang Ying 提交于
There is no 64bit read/write support in ACPI atomicio because readq/writeq is used to implement 64bit read/write, but readq/writeq is not available on i386. This patch implement 64bit read/write support in atomicio via two readl/writel. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 07 11月, 2011 1 次提交
-
-
由 Luck, Tony 提交于
Callers to __acpi_ioremap_fast() pass the bit_width that they found in the acpi_generic_address structure. Convert from bits to bytes when passing to __acpi_find_iomap() - as it wants to see bytes, not bits. cc: stable@kernel.org Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 01 11月, 2011 1 次提交
-
-
由 Paul Gortmaker 提交于
If a file is only exporting symbols and not using the core modular infrastructure, it can get by with just including the smaller export.h header, which is a lot smaller than the module.h header. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 25 5月, 2011 1 次提交
-
-
由 Roland Dreier 提交于
The presense of a writeq() implementation on 32-bit x86 that splits the 64-bit write into two 32-bit writes turns out to break the mpt2sas driver (and in general is risky for drivers as was discussed in <http://lkml.kernel.org/r/adaab6c1h7c.fsf@cisco.com>). To fix this, revert 2c5643b1 ("x86: provide readq()/writeq() on 32-bit too") and follow-on cleanups. This unfortunately leads to pushing non-atomic definitions of readq() and write() to various x86-only drivers that in the meantime started using the definitions in the x86 version of <asm/io.h>. However as discussed exhaustively, this is actually the right thing to do, because the right way to split a 64-bit transaction is hardware dependent and therefore belongs in the hardware driver (eg mpt2sas needs a spinlock to make sure no other accesses occur in between the two halves of the access). Build tested on 32- and 64-bit x86 allmodconfig. Link: http://lkml.kernel.org/r/x86-32-writeq-is-broken@mdm.bga.comAcked-by: NHitoshi Mitake <h.mitake@gmail.com> Cc: Kashyap Desai <Kashyap.Desai@lsi.com> Cc: Len Brown <lenb@kernel.org> Cc: Ravi Anand <ravi.anand@qlogic.com> Cc: Vikas Chaudhary <vikas.chaudhary@qlogic.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Jason Uhlenkott <juhlenko@akamai.com> Acked-by: NJames Bottomley <James.Bottomley@parallels.com> Acked-by: NIngo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: NRoland Dreier <roland@purestorage.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 30 9月, 2010 1 次提交
-
-
由 Jin Dongming 提交于
After we ioremap() a new region, we call __acpi_try_ioremap() to see whether another thread has already mapped the same region. This check clobbers "vaddr", so compute the return value of acpi_pre_map() using the ioremap() result "map->vaddr" instead. v2: Modified the unsuitable description of patch. v3: Removed unlikely() check and made description simpler. Signed-off-by: NJin Dongming <jin.dongming@np.css.fujitsu.com> Reviewed-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 6月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
Implicit slab.h inclusion via percpu.h is about to go away. Make sure gfp.h or slab.h is included as necessary. Signed-off-by: NTejun Heo <tj@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Len Brown <lenb@kernel.org> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
-
- 19 5月, 2010 1 次提交
-
-
由 Huang Ying 提交于
Some ACPI IO accessing need to be done in atomic context. For example, APEI ERST operations may be used for permanent storage in hardware error handler. That is, it may be called in atomic contexts such as IRQ or NMI, etc. And, ERST/EINJ implement their operations via IO memory/port accessing. But the IO memory accessing method provided by ACPI (acpi_read/acpi_write) maps the IO memory during it is accessed, so it can not be used in atomic context. To solve the issue, the IO memory should be pre-mapped during EINJ/ERST initializing. A linked list is used to record which memory area has been mapped, when memory is accessed in hardware error handler, search the linked list for the mapped virtual address from the given physical address. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-