kernel/linux.git/include/linux/io.h, branch v3.16.61

x86/io: add interface to reserve io memtype for a resource range. (v1.1)

2018-10-03T03:10:01+00:00

commit 8ef4227615e158faa4ee85a1d6466782f7e22f2f upstream. A recent change to the mm code in: 87744ab3832b mm: fix cache mode tracking in vm_insert_mixed() started enforcing checking the memory type against the registered list for amixed pfn insertion mappings. It happens that the drm drivers for a number of gpus relied on this being broken. Currently the driver only inserted VRAM mappings into the tracking table when they came from the kernel, and userspace mappings never landed in the table. This led to a regression where all the mapping end up as UC instead of WC now. I've considered a number of solutions but since this needs to be fixed in fixes and not next, and some of the solutions were going to introduce overhead that hadn't been there before I didn't consider them viable at this stage. These mainly concerned hooking into the TTM io reserve APIs, but these API have a bunch of fast paths I didn't want to unwind to add this to. The solution I've decided on is to add a new API like the arch_phys_wc APIs (these would have worked but wc_del didn't take a range), and use them from the drivers to add a WC compatible mapping to the table for all VRAM on those GPUs. This means we can then create userspace mapping that won't get degraded to UC. v1.1: use CONFIG_X86_PAT + add some comments in io.h Cc: Toshi Kani Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Andy Lutomirski Cc: Denys Vlasenko Cc: Brian Gerst Cc: x86@kernel.org Cc: mcgrof@suse.com Cc: Dan Williams Acked-by: Ingo Molnar Reviewed-by: Thomas Gleixner Signed-off-by: Dave Airlie [bwh: Backported to 3.16: Memory types have type unsigned long, and the constant is named _PAGE_CACHE_WC instead of _PAGE_CACHE_MODE_WC.] Signed-off-by: Ben Hutchings

Kconfig: rename HAS_IOPORT to HAS_IOPORT_MAP

2014-04-07T23:36:11+00:00

If the renamed symbol is defined lib/iomap.c implements ioport_map and ioport_unmap and currently (nearly) all platforms define the port accessor functions outb/inb and friend unconditionally. So HAS_IOPORT_MAP is the better name for this. Consequently NO_IOPORT is renamed to NO_IOPORT_MAP. The motivation for this change is to reintroduce a symbol HAS_IOPORT that signals if outb/int et al are available. I will address that at least one merge window later though to keep surprises to a minimum and catch new introductions of (HAS|NO)_IOPORT. The changes in this commit were done using: $ git grep -l -E '(NO|HAS)_IOPORT' | xargs perl -p -i -e 's/\b((?:CONFIG_)?(?:NO|HAS)_IOPORT)\b/$1_MAP/' Signed-off-by: Uwe Kleine-König Acked-by: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

asmlinkage: Make __iowrite32_copy visible

2014-02-14T02:12:04+00:00

This is a assembler function on x86, so it should be visible. Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1391845930-28580-2-git-send-email-ak@linux.intel.com Signed-off-by: H. Peter Anvin

Add arch_phys_wc_{add, del} to manipulate WC MTRRs if needed

2013-05-31T03:02:52+00:00

Several drivers currently use mtrr_add through various #ifdef guards and/or drm wrappers. The vast majority of them want to add WC MTRRs on x86 systems and don't actually need the MTRR if PAT (i.e. ioremap_wc, etc) are working. arch_phys_wc_add and arch_phys_wc_del are new functions, available on all architectures and configurations, that add WC MTRRs on x86 if needed (and handle errors) and do nothing at all otherwise. They're also easier to use than mtrr_add and mtrr_del, so the call sites can be simplified. As an added benefit, this will avoid wasting MTRRs and possibly warning pointlessly on PAT-supporting systems. Reviewed-by: Daniel Vetter Signed-off-by: Andy Lutomirski Signed-off-by: Dave Airlie

powerpc: Disable /dev/port interface on systems without an ISA bridge

2012-07-11T08:22:32+00:00

Some power systems do not have legacy ISA devices. So, /dev/port is not a valid interface on these systems. User level tools such as kbdrate is trying to access the device using this interface which is causing the system crash. This patch will fix this issue by not creating this interface on these powerpc systems. Signed-off-by: Haren Myneni Signed-off-by: Benjamin Herrenschmidt

x86, ioremap: Fix incorrect physical address handling in PAE mode

2010-07-09T18:42:03+00:00

Current x86 ioremap() doesn't handle physical address higher than 32-bit properly in X86_32 PAE mode. When physical address higher than 32-bit is passed to ioremap(), higher 32-bits in physical address is cleared wrongly. Due to this bug, ioremap() can map wrong address to linear address space. In my case, 64-bit MMIO region was assigned to a PCI device (ioat device) on my system. Because of the ioremap()'s bug, wrong physical address (instead of MMIO region) was mapped to linear address space. Because of this, loading ioatdma driver caused unexpected behavior (kernel panic, kernel hangup, ...). Signed-off-by: Kenji Kaneshige LKML-Reference: <4C1AE680.7090408@jp.fujitsu.com> Signed-off-by: H. Peter Anvin

[POWERPC] devres: Add devm_ioremap_prot()

2008-05-05T06:47:14+00:00

We provide an ioremap_flags, so this provides a corresponding devm_ioremap_prot. The slight name difference is at Ben Herrenschmidt's request as he plans on changing ioremap_flags to ioremap_prot in the future. Signed-off-by: Emil Medve Signed-off-by: Kumar Gala Acked-by: Tejun Heo Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Paul Mackerras

devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-30T23:52:48+00:00

Use a resource_size_t instead of unsigned long since some arch's are capable of having ioremap deal with addresses greater than the size of a unsigned long. Signed-off-by: Kumar Gala Cc: Tejun Heo Cc: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

uninline check_signature()

2007-07-16T16:05:50+00:00

This is a rather bizarre thing to have inlined in io.h. Stick it in lib/ instead. While we're there, despaghetti it a bit, and fix its off-by-one behaviour when passed a zero length. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

nommu: add ioremap_page_range()

2007-05-15T15:54:00+00:00

lib/ioremap.c is presently only built in if CONFIG_MMU is set. While this is reasonable, platforms that support both CONFIG_MMU=y or n need to be able to call in to this regardless. As none of the current nommu platforms do anything special with ioremap(), we assume that it's always successful. This fixes the SH-4 build with CONFIG_MMU=n. Signed-off-by: Paul Mundt Cc: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds